Difference between revisions of "System Modeling Concepts"

From SEBoK
Jump to navigation Jump to search
Line 2: Line 2:
  
 
==Abstraction==
 
==Abstraction==
Perhaps the most fundamental concept in systems modeling is [[Abstraction (glossary)]], which concerns hiding unimportant details in order to focus on essential characteristics. Systems worth modeling have many times more details than can reasonably be modeled.  Apart from the sheer size and structural complexity that a system may possess, a system may be behaviorally complex as well, with emergent properties, non-deterministic behavior, and other difficult to characterize properties. Consequently, models must focus on a vital few characteristics in order to be computationally and intellectually tractable.  Modeling techniques address complexity through various forms of abstraction. For example, a model may assume the structural and other characteristics of the many instances of a particular type of component are all they the same, ignoring small order differences between individual instances that occur in real life.  In that case, those differences are assumed to be unimportant to modeling the structural integrity of an aggregation of those components.  Of course, if that assumption is wrong, then the model could lead to false confidence in that structural integrity.  Two 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.
+
Perhaps the most fundamental concept in systems modeling is [[Abstraction (glossary)]], which concerns hiding unimportant details in order to focus on essential characteristics. Systems worth modeling have many times more details than can reasonably be modeled.  Apart from the sheer size and structural complexity that a system may possess, a system may be behaviorally complex as well, with emergent properties, non-deterministic behavior, and other difficult to characterize properties. Consequently, models must focus on a vital few characteristics in order to be computationally and intellectually tractable.  Modeling techniques address complexity through various forms of abstraction. For example, a model may assume the structural and other characteristics of many individual instances of a particular type of component are all they the same, ignoring small order differences between individual instances that occur in real life.  In that case, those differences are assumed to be unimportant to modeling the structural integrity of an aggregation of those components.  Of course, if that assumption is wrong, then the model could lead to false confidence in that structural integrity.  Two 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===
 
===View and Viewpoint===

Revision as of 21:14, 31 August 2011

A system model represents aspects of a system and its environment. As explained in the article Types of Models, there are many different types of models, reflecting the diverse purposes for which people build models. It is useful to have a common way to talk about the concepts underlying the many different types of models; e.g., many modeling techniques enable understanding system behavior ; others enable understanding system structure . This article highlights several common systems modeling concepts.

Abstraction

Perhaps the most fundamental concept in systems modeling is abstraction , which concerns hiding unimportant details in order to focus on essential characteristics. Systems worth modeling have many times more details than can reasonably be modeled. Apart from the sheer size and structural complexity that a system may possess, a system may be behaviorally complex as well, with emergent properties, non-deterministic behavior, and other difficult to characterize properties. Consequently, models must focus on a vital few characteristics in order to be computationally and intellectually tractable. Modeling techniques address complexity through various forms of abstraction. For example, a model may assume the structural and other characteristics of many individual instances of a particular type of component are all they the same, ignoring small order differences between individual instances that occur in real life. In that case, those differences are assumed to be unimportant to modeling the structural integrity of an aggregation of those components. Of course, if that assumption is wrong, then the model could lead to false confidence in that structural integrity. Two 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 system as a black-box , 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. A white-box model of a system shows the internal structure and behavior of the system. Black box and white-box modeling can be applied to the next level of design decomposition in order to create a black-box and white box model of each system component

System Concept Model

Sbe able to have a vocabulary to talk about the properties of system modeling languages. A system concept model (glossary) is the set of concepts used to describe models and the relationships between those concepts. It is, in effect, a language for talking about models. A system concept model includes its requirements , behavior , structure , and properties . In addition, the concept model is accompanied by a set of definitions for each concept. Often, models are typically defined using an Entity Relationship diagrams or a UML class diagrams. 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. 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 originally 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 1. 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.

System Concept Model-Top Level

Figure 1. Fragment of the Object Management Group System Concept Model

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.


References

Citations

Object Management Group. 2010. MDA Foundation Model. Document number ORMSC/2010-09-06. Object Management Group.

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)