System Modeling Concepts

System modeling concepts enable system models to represent systems. These include concepts needed to describe systems, and concepts needed to create abstractions of systems, such as view and viewpoint.

System Concept Model

A system model represents aspects of a system and its environment. A system concept model (glossary) captures the key concepts for representing systems, including its requirements , behavior , structure , and properties . The concept model identifies the concepts and their relationship to other concepts. In addition, the concept model is accompanied by a set of definitions for each concept. The models are typically defined using an Entity Relationship diagram or a UML class diagram.

A preliminary Systems Engineering Concept Model was developed in support of the integration efforts between the development of the OMG Systems Modeling Language and the ISO AP233 Data Exchange Standard for systems engineering. The concept model was captured in an informal way, but the model and associated concepts were rigorously reviewed by a broad representation from the systems engineering community, including members from INCOSE, and the AP233 and SysML development teams.

A fragment from the top level Systems Engineering Concept Model is included in Figure 2. This model provides concepts for requirements, behavior, structure and properties of the system, as well as other concepts related to project management. The concept model is augmented by a well defined glossary of terms called the semantic dictionary. The concept model and glossary of terms served as a key input to the requirements for the OMG Systems Modeling Language that was called the UML for Systems Engineering Request for Proposal.

The concept model is sometimes referred to as a meta-model (glossary), domain meta-model, or schema, and can be used to specify the abstract syntax of a modeling language (refer to the MDA Foundation Model (Object Management Group 2010)). Several other system concept models have been developed but not standardized. Future standardization efforts should establish a standard systems concept model. The model can then evolve over time as the systems engineering community continues to formalize and advance the practice of systems engineering.

Abstraction – a Key Modeling Concept

In order to manage [complexity (glossary)], it is important for a model to represent different levels of abstraction and to present in a model only the information to communicate the particular intent, and hide other aspects that are not relevant to the intent. Some of the key concepts to model different levels of abstraction include the concept of view and viewpoint, and the concept of black-box and white-box models as described below. Different modeling languages and tools employ other techniques as well.

View and Viewpoint

IEEE 1471 defines and view and viewpoint as follows:

1. view - A representation of a whole system from the perspective of a related set of concerns.
2. viewpoint - A specification of the conventions for constructing and using a view. A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis.

The viewpoint specifies the stakeholders and their concerns, and provides the conventions for constructing a view to address those concerns. The view represents aspects of the system that address the stakeholder concerns. Models can be created to represent the different views of the system.

Typical System Views

A systems model should be able to represent multiple views of the system to address a range of stakeholder concerns. Standard views may include requirements, functional, structural, and parametric views, as well as a multitude of discipline specific views to address system reliability, safety, security, and other quality characteristics.

Black-box and White-box Models

A very common abstraction technique is to model the black-box of a system, which only exposes the features of the system that are visible from an external observer, and hide the internal details of the design. This includes stimulus response characteristics, and other black box physical characteristics such as the system mass or weight. The model of the white-box of a system shows the internal structure and behavior of the system. The black box and white-box modeling can be applied to the next level of design decomposition, to create a black-box and white box model of each system component.

References

Please make sure all references are listed alphabetically and are formatted according to the Chicago Manual of Style (15th ed). See the BKCASE Reference Guidance for additional information.

Citations

Object Management Group. 2010. MDA Foundation Model. Object Management Group (OMG), document number ORMSC/2010-09-06.

Primary References

ANSI/IEEE. 2000. Recommended Practice for Architectural Description for Software-Intensive Systems. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/IEEE 1471-2000.

Dori, D. 2002. Object-Process Methodology – A Holistic Systems Paradigm, Springer Verlag, Berlin, Heidelberg, New York, 2002 (ISBN 3-540-65471-2). http://www.amazon.com/Object-Process-Methodology-Dov-Dori/dp/3540654712

Guizzardi, G. 2007. On Ontology, Ontologies, Conceptualizations, Modeling Languages, and (Meta)Models. Proceeding of the 2007 conference on Databases and Information Systems IV. Available at http://portal.acm.org/citation.cfm?id=1565425.

INCOSE 2003. Systems Engineering Concept Model. Draft 12 Baseline. Available at http://syseng.omg.org/SE_Conceptual%20Model/SE_Conceptual_Model.htm

Object Management Group 2003. UML for Systems Engineering Request for Proposal. OMG document number ad/2003-3-41. Available at http://www.omg.org/cgi-bin/doc?ad/2003-3-41

Additional References

Object Management Group. 2010. MDA Foundation Model. Object Management Group (OMG), document number ORMSC/2010-09-06.

---

Article Discussion

Comment by Scott Jackson (reviewer):

Under the sub-heading Abstraction the word complexity is used. There are two definitions of complexity. See Glossary. One is called behavioral complexity and the other is structural complexity. Behavioral complexity has to do with the difficulty in understanding the system. Structual complexity has to do with the properties of the system itself that result in emergent properties. It is believed that complexity in this ocntext has to do with behavoral complexity. That is the system absraction is used to make the system more easily understood. A few extra words to make this clear might be in order.

Alice (reviewer): I think the term 'concept' needs to be defined before it is used in this section as it is not necessarily the generic use of the term but rather something specific. However, I'm not sure what the properties of a 'foundation concept' are. What I see is a mix of elements, views, inputs, context, activities all related to a system.

Which is it: system modeling concept, system concept model, systems engineering concept model, concept model.

Fix: [complexity (glossary)] Fix: and view and viewpoint

"Several other system concept models" is mentioned - need references here, a guide to that knowledge.

[Go to discussion page]

<- Previous Article | Parent Article | Next Article ->

Signatures

--Radcock 21:36, 10 August 2011 (UTC)