Replies: 7 comments
-
From the PR, i understand this is about generalizations for the system Blocks used in the structure viewpoints, correct ? So the only new concept would be the generalization "Reuse" ? Do you have the Idea how to capture the "what must be Changed" ? I believe you want to add two viewpoints, one fit the LD and one for the PD, with similar concerns. |
Beta Was this translation helpful? Give feedback.
-
The physical of these viewpoints could also capture top Level taxonomy Elements Like e.g. "hardware Item" with weight value properties and so on. |
Beta Was this translation helpful? Give feedback.
-
Indeed. I want to enhance reusability (specialisation) from a reference architecture or a library as a preliminary step before defining the structure. Thus we keep the Structure Viewpoint clean and simple. Incidentally tayloring from reference architecture or library to Project goes into the new Viewpoint. The generalisations within a project should also go into the new Viewpint for best consistency. |
Beta Was this translation helpful? Give feedback.
-
Yup. There are many subjects That benefit from a Taxonomy Viewpoint. In addition to the obvious ones like logical and physical systems and interfaces, that you want to specialize from a reference architecture, you may want to define a taxonomy of functions given that you pull functions from a library. You may want to have a taxonomy of actors, verifications, analysis or constrains too. Having a Viewpoint for the taxonomy let you bring all these topics under one roof. |
Beta Was this translation helpful? Give feedback.
-
Am 18. Oktober 2023 10:11:24 MESZ schrieb Hugo Ormo ***@***.***>:
> The physical of these viewpoints could also capture top Level taxonomy Elements Like e.g. "hardware Item" with weight value properties and so on.
>
>
Yup. There are many subjects That benefit from a Taxonomy Viewpoint. In addition to the obvious ones like logical and physical systems and interfaces, that you want to specialize from a reference architecture, you may want to define a taxonomy of functions given that you pull functions from a library. You may want to have a taxonomy of actors, verifications, analysis or constrains too. Having a Viewpoint for the taxonomy let you bring all these topics under one roof.
--
Reply to this email directly or view it on GitHub:
#21 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
Instead of having one viewpoint handling different classes of taxonomies, i think it should be several distinct vps.
Separation of concerns might guide here..
E.g, we May have a Physical System taxonomy, that allows reusing Systems from a library for System Elements and Context Elements by inheriting from Elements in library models.
But, for a Reuse of Interface definitions, we should use a different vp.
--
Gruß,
Alexander
|
Beta Was this translation helpful? Give feedback.
-
I agree. I meant to begin with a logical and a physical taxonomy for systems and interfaces. We could follow through with actors, functions,... |
Beta Was this translation helpful? Give feedback.
-
Interessant wäre es, die entsprechenden Bezüge / Aktivitäten m SE HB v5 zu zitieren. |
Beta Was this translation helpful? Give feedback.
-
Logical/ Physical Taxonomy Viewpoint
Purpose
The Logical/ Physical Taxonomy Viewpoint is used to model the taxonomy of logical/physical Elements of the system architecture. Elements being system elements, interfaces or connections making up the SOI. The Logical/Physical Taxonomy enhances re-usability within and across the SOI as well as the design of product lines by means of the virtues of specialization. The Logical/Physical Viewpoint support the identification of the taxonomic relationship between the architecture elements and their further use in the design process. It supports consistency when planning for changes in the design.
Applicability
The Logical/ Physical Taxonomy Viewpoint supports the “reuse of COTS” activity of the INCOSE SYSTEMS ENGINEERING HANDBOOK 2015 [§ 4.5.1.4], the “adaptation of system elements” activity of the INCOSE SYSTEMS ENGINEERING HANDBOOK 2015 [§ 4.7.2.1], and the “potential to justify the setting up of the evolution of a product line organization” activity of the INCOSE SYSTEMS ENGINEERING HANDBOOK 2015 [§ 8.3.1].
Stakeholder
Concern
Beta Was this translation helpful? Give feedback.
All reactions