This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
sysml-roadmap:structure_behavior_concepts_modeling_core_team_wiki_page [2017-03-08 21:54] sfriedenthal [Limitations of SysML v1] |
sysml-roadmap:structure_behavior_concepts_modeling_core_team_wiki_page [2017-04-26 10:55] (current) hpdekoning Added presentation and state of RFP requirements per 26 April 2017 |
||
---|---|---|---|
Line 1: | Line 1: | ||
Back to the[[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:systems_engineering_concept_model_workgroup| Systems Engineering Concept Model (SECM) Working Group Wiki]] | Back to the[[http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:systems_engineering_concept_model_workgroup| Systems Engineering Concept Model (SECM) Working Group Wiki]] | ||
- | ====== Structure/Behavior Concepts Modeling Focus Team ====== | + | ====== Structure Concepts Modeling Focus Team ====== |
===== Team ===== | ===== Team ===== | ||
Line 22: | Line 22: | ||
===== Limitations of SysML v1 ===== | ===== Limitations of SysML v1 ===== | ||
- Lack of integration of how flows are captured in terms of item flows, flow properties, object flows, operation parameters, … (Sandy) | - Lack of integration of how flows are captured in terms of item flows, flow properties, object flows, operation parameters, … (Sandy) | ||
- | **Response:** Integrating structure and interface concepts. Need to integrate behavior concepts. | + | - **Response:** Integrating structure and interface concepts. Need to integrate behavior concepts. |
- Integration of operations on blocks including how parameters of operations align with flows and triggers on state machines (Marc) | - Integration of operations on blocks including how parameters of operations align with flows and triggers on state machines (Marc) | ||
+ | - **Response:** Integrating structure and interface concepts. Need to integrate behavior concepts. | ||
- Lack of precision of how property specific types and initial values compartments on usages/ibd’s are defined (Roger) | - Lack of precision of how property specific types and initial values compartments on usages/ibd’s are defined (Roger) | ||
+ | - **Response:** Addressed property specific types. Value properties can have initial values which can be over-rided. | ||
- Limitations of capturing deeply nested properties (and other features) in the model such that a right wheel can be differentiated from a left wheel of a vehicle (Sandy, Hans Peter) | - Limitations of capturing deeply nested properties (and other features) in the model such that a right wheel can be differentiated from a left wheel of a vehicle (Sandy, Hans Peter) | ||
+ | - **Response:** This has been addressed. | ||
- Differences in the way port and part are modeled leading to inability to seamlessly evolve a port to become a part and vice versa (Hans Peter) | - Differences in the way port and part are modeled leading to inability to seamlessly evolve a port to become a part and vice versa (Hans Peter) | ||
+ | - **Response:** Both port and part are applying the same structural modeling patterns. The concept of a black box port (proxy) will be a distinct concept. A white box port (full) is a part that is exposed on the boundary (may be able to be addressed by visibility). | ||
- Port complexity and associated interface complexity (Roger) | - Port complexity and associated interface complexity (Roger) | ||
+ | - **Response:** Common patterns are being applied, and the concepts for port and part are being integrated. | ||
- Lack of geometric concepts such as shape and coordinate system and topologies (Sandy, Conrad) | - Lack of geometric concepts such as shape and coordinate system and topologies (Sandy, Conrad) | ||
+ | - **Response:** This will be addressed by a 2D/3D Library of geometric shapes. Hans Peter can share a library that he has developed to illustrate the approach. | ||
- Limitations in ability to over-ride values and type for a particular usage including redefinition at nested levels of inheritance (Roger) and at realization levels (Hans Peter) | - Limitations in ability to over-ride values and type for a particular usage including redefinition at nested levels of inheritance (Roger) and at realization levels (Hans Peter) | ||
+ | - **Response:** This has been addressed. | ||
- Limitations in ability to represent as-defined versus as-realized (Hans Peter). | - Limitations in ability to represent as-defined versus as-realized (Hans Peter). | ||
- | - Inability to easily represent instances with time varying property values and differentiate instances from snapshots at a point in time (Sandy) | + | - **Response:** This has been addressed (configuration vs individual model) |
- | - Example: thrust versus time for an aircraft with a particular tail number | + | - Inability to easily represent instances with time varying property values and differentiate instances from snapshots at a point in time. Example: thrust versus time for an aircraft with a particular tail number (Sandy) |
+ | - **Response:** Structure models can have properties with time varying values. Time is a property (i.e., value element) with a time scale supported by QUDV | ||
- Ambiguity in the meaning of a property and its value (Conrad) | - Ambiguity in the meaning of a property and its value (Conrad) | ||
+ | - **Response:** TBD | ||
- Need for more engineering friendly terms for initial values, constants (vs read only) (Roger) | - Need for more engineering friendly terms for initial values, constants (vs read only) (Roger) | ||
- | - Limitations in being able to model logical operations (e.g., and, or, nor, not) on structural relationships such as whole part and specialization (Sandy) | + | - **Response:** Constant is defined in properties and expressions. Initial values has not been addressed. |
- | - Supports variant modeling and different configurations | + | - Limitations in being able to model logical operations (e.g., and, or, nor, not) on structural relationships such as whole part and specialization. Support for variant modeling and different configurations (Sandy) |
+ | - **Response:** Can apply a logical constraint to deeply nested parts of a system. | ||
- Inability to clarify that multiple symbols can represent the same element on the same diagram (e.g., proxy port) (Conrad) | - Inability to clarify that multiple symbols can represent the same element on the same diagram (e.g., proxy port) (Conrad) | ||
+ | - **Response:** TBD | ||
- State dependent properties (e.g., stowed vs deployed antenna of a spacecraft, power consumption in different states) (Hans Peter) | - State dependent properties (e.g., stowed vs deployed antenna of a spacecraft, power consumption in different states) (Hans Peter) | ||
+ | - **Response:** Properties can be state dependent. Hans Peter will make this explicit in the Properties & Expressions Model. | ||
- Time varying structure/topology such as changing compositions and interconnections (John) | - Time varying structure/topology such as changing compositions and interconnections (John) | ||
+ | - **Response:** Time varying structure will be based on having a behavior that creates or destroys usage elements including parts and connectors. This behavior can be performed on a state transition. This would support the change in structure for a staged rocket. | ||
- Limited support (concepts and notation) for real-time software architecture modeling concepts for structure and behavior that include the following (Note: Ron Townsend identified this limitation): | - Limited support (concepts and notation) for real-time software architecture modeling concepts for structure and behavior that include the following (Note: Ron Townsend identified this limitation): | ||
- Thread | - Thread | ||
Line 46: | Line 59: | ||
- Application, Library, or Service Boundary | - Application, Library, or Service Boundary | ||
- Other concepts that are behavior oriented such as thread creation, etc. | - Other concepts that are behavior oriented such as thread creation, etc. | ||
+ | - **Response:** This will be deferred until we have the initial behavior concepts. | ||
+ | - Use of adjunct property to map the properties associated with an activity decomposition to actions in an activity diagram requires double book-keeping. | ||
+ | - **Response:** The proposed structure modeling concepts and pattern can be applied to decompose activities and blocks in the same way, thus avoiding the need for adjunct properties and double book-keeping. | ||
+ | - Use of connector property to enable simulation with connectors typed by association blocks requires double book-keeping. | ||
+ | - **Response:** The proposed structure modeling concepts and pattern eliminates this double book-keeping by making the connector usage element a specialization of the property usage element. | ||
===== Driving Requirements ===== | ===== Driving Requirements ===== | ||
Line 56: | Line 74: | ||
The concept model for Structure has evolved with integration of basic interface concepts as per BDD below. | The concept model for Structure has evolved with integration of basic interface concepts as per BDD below. | ||
- | {{ :sysml-roadmap:generic_structure_models_temporary_v2_2017-03-01.png?direct |}} | + | {{ :sysml-roadmap:generic_structure_v6-2017-03-22.png?direct |}} |
===== Derived Requirements ===== | ===== Derived Requirements ===== | ||
+ | Requirements as presented 26 April 2017: | ||
+ | |||
+ | {{ :sysml-roadmap:2017-04-26-sysml-v2-structure-properties-values-and-expressions.pdf |}} | ||
+ | |||
+ | {{ :sysml-roadmap:requirements_on_structure-2017-04-26.xlsx |{{ :sysml-roadmap:requirements_on_structure-2017-04-26.xlsx |}}}} | ||
===== References ===== | ===== References ===== |