User Tools

Site Tools


sysml-roadmap:structure_behavior_concepts_modeling_core_team_wiki_page

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
sysml-roadmap:structure_behavior_concepts_modeling_core_team_wiki_page [2017-02-08 17:09]
hpdekoning Update after telecon 8 Feb 2017
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.
   - 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 timeExample: 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 45: 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 =====
  
 ===== Requirements Analysis ===== ===== Requirements Analysis =====
  
-The state of the concept model for Structure is captured in the annotated ​class diagram below.+The state of the concept model for Structure is captured in the annotated diagram below.
  
 {{ :​sysml-roadmap:​secm-structure-2017-02-08.png?​direct |}} {{ :​sysml-roadmap:​secm-structure-2017-02-08.png?​direct |}}
 +
 +The concept model for Structure has evolved with integration of basic interface concepts as per BDD below.
 +
 +{{ :​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 =====
sysml-roadmap/structure_behavior_concepts_modeling_core_team_wiki_page.1486591768.txt.gz · Last modified: 2017-02-08 17:09 by hpdekoning