Difference between revisions of "System Modeling Concepts"

From SEBoK
Jump to: navigation, search
m (Text replacement - "'''SEBoK v. 2.2, released 15 May 2020'''" to "'''SEBoK v. 2.3, released 30 October 2020'''")
 
(44 intermediate revisions by 12 users not shown)
Line 1: Line 1:
A system [[Model (glossary)|model (glossary)]] represents aspects of a system and its environment.  As explained in the article there are many different [[Types of Models | types of models]], reflecting the diverse purposes for which people build them. 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 (glossary)|behavior (glossary)]], while others enable understanding system [[Structure (glossary)|structure (glossary)]]). This article highlights several common systems modeling concepts.
+
----
 +
'''''Lead Author:''''' ''Sanford Friedenthal'', '''''Contributing Authors:''''' ''Dov Dori, Yaniv Mordecai''
 +
----
 +
A system {{Term|Model (glossary)|model}} represents aspects of a system and its environment.  There are many different [[Types of Models|types of models]], as there are a variety of purposes for which they are built. 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 the understanding of system {{Term|Behavior (glossary)|behavior}}, while others enable the understanding of system {{Term|Structure (glossary)|structure}}). This article highlights several concepts used for modeling systems.
  
 
==Abstraction==
 
==Abstraction==
Perhaps the most fundamental concept in systems modeling is [[Abstraction (glossary)|abstraction (glossary)]], which concerns hiding unimportant details in order to focus on essential characteristics. Systems worth modeling have 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 few vital characteristics in order to be computationally and intellectually tractable.  Modeling techniques address complexity through various forms of abstraction. For example, a model may assume that structural and other characteristics of many individual instances of a particular type of component are all 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 are (a) view and viewpoint and (b) black-box and white-box modeling, as described below. Different modeling languages and tools employ other techniques as well.
+
Perhaps the most fundamental concept in systems modeling is {{Term|Abstraction (glossary)|abstraction}}, which concerns hiding unimportant details in order to focus on essential characteristics. Systems that are worth modeling have too many details for all of them to 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 few vital characteristics in order to be computationally and intellectually tractable.  Modeling techniques address this complexity through various forms of abstraction. For example, a model may assume that structural characteristics of many individual components of a particular type are all the same, ignoring the small order differences between individuals in instances that occur in real life.  In that case, those differences are assumed to be unimportant to modeling the structural integrity of those components.  Of course, if that assumption is wrong, then the model could lead to false confidence in that structural integrity.  There are two key concepts that are applied in regard to modeling different levels of abstraction, which are: view and viewpoint, and black-box and white-box modeling, which are described below. Although these two modeling methods are the most widely recognized, different modeling languages and tools employ other techniques as well.
  
 
===View and Viewpoint===
 
===View and Viewpoint===
 
[[IEEE 1471]], a standard for architecture modeling, defines "view" and "viewpoint" as follows:
 
[[IEEE 1471]], a standard for architecture modeling, defines "view" and "viewpoint" as follows:
#[[View (glossary)]]: A representation of a whole system from the perspective of a related set of concerns
+
* {{Term|View (glossary)|View}} - A representation of a whole system from the perspective of a related set of concerns.
#[[Viewpoint (glossary)]]: 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
+
* {{Term|Viewpoint (glossary)|Viewpoint}} - A specification of the conventions necessary 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.
  
Even though IEEE 1471 is focused on architectural models, the concepts of view and viewpoint are general and could apply to models for other purposes as well. 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.  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.
+
Even though IEEE 1471 is focused on architecture models, the concepts of view and viewpoint are general and could apply to models for other purposes as well (IEEE 2000). The viewpoint addresses the concerns of the stakeholders and provides the necessary conventions for constructing a view to address those concerns; therefore, the view represents aspects of the system that address the concerns of the stakeholder.  Models can be created to represent the different views of the system.  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===
+
===Black-Box and White-Box Models===
A very common abstraction technique is to model the system as a [[Black-Box System (glossary) |black-box (glossary)]], 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 System (glossary)|white-box (glossary)]] 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.
+
A very common abstraction technique is to model the system as a {{Term|Black-Box System (glossary)|black-box}}, which only exposes the features of the system that are visible from an external observer and hides the internal details of the design. This includes externally visible behavior and other physical characteristics, such as the system’s mass or weight. A {{Term|White-Box System (glossary)|white-box}} model of a system, on the other hand, shows the internal structure and displays the 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.
  
==Concept Model==
+
==Conceptual Model==
A concept model is the set of concepts used to describe models and the relationships between those concepts (e.g., view and viewpoint). It is, in effect, a language for talking about models. A system concept model is used to describe models about systems and includes its [[Requirement (glossary)|requirements (glossary)]], [[Behavior (glossary)|behavior (glossary)]], [[Structure (glossary)|structure (glossary)]], and [[System Property (glossary)|properties (glossary)]]. In addition, a system concept model is accompanied by a set of definitions for each concept. Sometimes system concept models are defined using an Entity Relationship diagram or a UML class diagram.
+
A conceptual model is the set of concepts within a system and the relationships among those concepts (e.g., view and viewpoint). A system conceptual model describes, using one diagram type (such as in Object-Process Methodology (OPM)) or several diagram types (such as in Systems Modeling Language (SysML)), the various aspects of the system. The conceptual model might include its {{Term|Requirement (glossary)|requirements}}, {{Term|Behavior (glossary)|behavior}}, {{Term|Structure (glossary)|structure}}, and {{Term|System Property (glossary)|properties}}. In addition, a system conceptual model is accompanied by a set of definitions for each concept. Sometimes, system concept models are defined using an entity relationship diagram, an object-process diagram (OPD), or a Unified Modeling Language (UML) class diagram.
  
A preliminary concept model for systems engineering ([[Systems Engineering Concept Model]]) was developed in support of the integration efforts between the development of the OMG Systems Modeling Language ([[Acronyms|SysML]]) and the ISO AP233 Data Exchange Standard for systems engineering (ISO 2010). 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 the INCOSE, AP233 and [[Acronyms|SysML]] development teams.
+
A preliminary conceptual (or concept) model for systems engineering ([[Systems Engineering Concept Model]]) was developed in support of the integration efforts directed toward the development of the Object Management Group (OMG) SysML and the International Organization for Standardization (ISO) AP233 ''Data Exchange Standard for Systems Engineering'' (ISO 2010). The concept model was originally captured in an informal manner; however, the model and associated concepts were rigorously reviewed by a broad representation of the systems engineering community, including members from the International Council on Systems Engineering (INCOSE), 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 common to systems engineering and project management, such as [[Stakeholder (glossary)]]. The concept model is augmented by a well-defined glossary of terms called the semantic dictionary. The concept model and semantic dictionary 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]].
+
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 common to systems engineering and project management, such as the {{Term|Stakeholder (glossary)|stakeholder}}. The concept model is augmented by a well-defined glossary of terms called the semantic dictionary. The concept model and the semantic dictionary contributed greatly to the requirements for the OMG Systems Modeling Language written in the [[UML for Systems Engineering Request for Proposal]].
  
[[File:060611_SF_System_Conept_Model-Top_Levelnofig10.png|thumb|center|700px||thumb|Figure 1. Fragment of the object management group system concept model (Oliver 2003, Slide 3).  Permission granted by David Oliver.]]
+
[[File:060611_SF_System_Conept_Model-Top_Levelnofig10.png|thumb|center|700px||thumb|'''Figure 1. Fragment of the Object Management Group System Concept Model (Oliver 2003, Slide 3).''' Permission granted by David Oliver on behalf of INCOSE MDSD Working Group. All other rights are reserved by the copyright owner.]]
  
A concept model is sometimes referred to as a [[Meta-model (glossary)|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 (OMG 2010)). Several other systems engineering concept models have been developed but not standardized. Future standardization efforts should establish a standard systems engineering concept model. The model can then evolve over time as the systems engineering community continues to formalize and advance the practice of systems engineering.
+
A concept model is sometimes referred to as a {{Term|Meta-model (glossary)|meta-model}}, domain meta-model, or schema, and can be used to specify the {{Term|Abstract Syntax (glossary)|abstract syntax}} of a modeling language (refer to the Model Driven Architecture (MDA®) Foundation Model (OMG 2010)). Several other systems engineering concept models have been developed but not standardized. Future standardization efforts should establish a standard systems engineering 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==  
 
==References==  
 
===Works Cited===
 
===Works Cited===
 +
IEEE. 2000. ''Recommended Practice for Architectural Description for Software-Intensive Systems''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), [[IEEE 1471]]-2000.
 +
 
ISO. 2010. ''OMG System Modeling Language (OMG SysML),'' version 1.2. Needham, MA, USA: Object Management Group.
 
ISO. 2010. ''OMG System Modeling Language (OMG SysML),'' version 1.2. Needham, MA, USA: Object Management Group.
  
Line 36: Line 41:
 
Dori, D. 2002. ''[[Object-Process Methodology – A Holistic Systems Paradigm]]''. New York, NY, USA: Springer-Verlag.
 
Dori, D. 2002. ''[[Object-Process Methodology – A Holistic Systems Paradigm]]''. New York, NY, USA: Springer-Verlag.
  
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.
+
Guizzardi, G. 2007. "[[On Ontology, Ontologies, Conceptualizations, Modeling Languages, and (Meta)Models|On ontology, ontologies, conceptualizations, modeling languages, and (meta)models]]," Proceedings 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.'' Seattle, WA: ''International Council on Systems Engineering''. Available at http://syseng.omg.org/SE_Conceptual%20Model/SE_Conceptual_Model.htm.
+
IEEE. 2000. ''Recommended Practice for Architectural Description for Software-Intensive Systems''. New York, NY, USA: Institute of Electrical and Electronics Engineers (IEEE), [[IEEE 1471]]-2000.
  
OMG. 2003. ''[[UML for Systems Engineering Request for Proposal]]''.  Needham, MA: Object Management Group. OMG document number ad/2003-3-41. Available at http://www.omg.org/cgi-bin/doc?ad/2003-3-41.
+
INCOSE. 2003. ''[[Systems Engineering Concept Model]]. Draft 12 Baseline.'' Seattle, WA, USA: International Council on Systems Engineering. Available at: http://syseng.omg.org/SE_Conceptual%20Model/SE_Conceptual_Model.htm.
 +
 
 +
OMG. 2003. ''[[UML for Systems Engineering Request for Proposal]]''.  Needham, MA, USA: Object Management Group. OMG document number ad/2003-3-41. Available at: http://www.omg.org/cgi-bin/doc?ad/2003-3-41.
  
 
===Additional References===
 
===Additional References===
OMG. 2010. ''MDA Foundation Model''. Needham, MA, USA: Object Management Group. Document number ORMSC/2010-09-06.
+
None.
  
 
----
 
----
  
<center>[[Types of Models|< Previous Article]] | [[Representing Systems with Models|Parent Article]] | [[Modeling Standards|Next Article >]]</center>
+
<center>[[Types of Models|< Previous Article]] | [[Representing Systems with Models|Parent Article]] | [[Integrating_Supporting_Aspects_into_System_Models|Next Article >]]</center>
 
 
==Comments from SEBok 0.5 Wiki==
 
No comments were logged for this article in the SEBoK 0.5 wiki.  Because of this, it is especially important for reviewers to provide feedback on this article.  Please see the discussion prompts below.
 
 
 
{{DISQUS}}
 
  
 +
<center>'''SEBoK v. 2.3, released 30 October 2020'''</center>
  
 
[[Category:Part 2]][[Category:Topic]]
 
[[Category:Part 2]][[Category:Topic]]
 
[[Category:Representing Systems with Models]]
 
[[Category:Representing Systems with Models]]

Latest revision as of 08:00, 14 October 2020


Lead Author: Sanford Friedenthal, Contributing Authors: Dov Dori, Yaniv Mordecai


A system modelmodel represents aspects of a system and its environment. There are many different types of models, as there are a variety of purposes for which they are built. 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 the understanding of system behaviorbehavior, while others enable the understanding of system structurestructure). This article highlights several concepts used for modeling systems.

Abstraction

Perhaps the most fundamental concept in systems modeling is abstractionabstraction, which concerns hiding unimportant details in order to focus on essential characteristics. Systems that are worth modeling have too many details for all of them to 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 few vital characteristics in order to be computationally and intellectually tractable. Modeling techniques address this complexity through various forms of abstraction. For example, a model may assume that structural characteristics of many individual components of a particular type are all the same, ignoring the small order differences between individuals in instances that occur in real life. In that case, those differences are assumed to be unimportant to modeling the structural integrity of those components. Of course, if that assumption is wrong, then the model could lead to false confidence in that structural integrity. There are two key concepts that are applied in regard to modeling different levels of abstraction, which are: view and viewpoint, and black-box and white-box modeling, which are described below. Although these two modeling methods are the most widely recognized, different modeling languages and tools employ other techniques as well.

View and Viewpoint

IEEE 1471, a standard for architecture modeling, defines "view" and "viewpoint" as follows:

  • ViewView - A representation of a whole system from the perspective of a related set of concerns.
  • ViewpointViewpoint - A specification of the conventions necessary 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.

Even though IEEE 1471 is focused on architecture models, the concepts of view and viewpoint are general and could apply to models for other purposes as well (IEEE 2000). The viewpoint addresses the concerns of the stakeholders and provides the necessary conventions for constructing a view to address those concerns; therefore, the view represents aspects of the system that address the concerns of the stakeholder. Models can be created to represent the different views of the system. 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-boxblack-box, which only exposes the features of the system that are visible from an external observer and hides the internal details of the design. This includes externally visible behavior and other physical characteristics, such as the system’s mass or weight. A white-boxwhite-box model of a system, on the other hand, shows the internal structure and displays the 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.

Conceptual Model

A conceptual model is the set of concepts within a system and the relationships among those concepts (e.g., view and viewpoint). A system conceptual model describes, using one diagram type (such as in Object-Process Methodology (OPM)) or several diagram types (such as in Systems Modeling Language (SysML)), the various aspects of the system. The conceptual model might include its requirementsrequirements, behaviorbehavior, structurestructure, and propertiesproperties. In addition, a system conceptual model is accompanied by a set of definitions for each concept. Sometimes, system concept models are defined using an entity relationship diagram, an object-process diagram (OPD), or a Unified Modeling Language (UML) class diagram.

A preliminary conceptual (or concept) model for systems engineering (Systems Engineering Concept Model) was developed in support of the integration efforts directed toward the development of the Object Management Group (OMG) SysML and the International Organization for Standardization (ISO) AP233 Data Exchange Standard for Systems Engineering (ISO 2010). The concept model was originally captured in an informal manner; however, the model and associated concepts were rigorously reviewed by a broad representation of the systems engineering community, including members from the International Council on Systems Engineering (INCOSE), 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 common to systems engineering and project management, such as the stakeholderstakeholder. The concept model is augmented by a well-defined glossary of terms called the semantic dictionary. The concept model and the semantic dictionary contributed greatly to the requirements for the OMG Systems Modeling Language written in the UML for Systems Engineering Request for Proposal.

Figure 1. Fragment of the Object Management Group System Concept Model (Oliver 2003, Slide 3). Permission granted by David Oliver on behalf of INCOSE MDSD Working Group. All other rights are reserved by the copyright owner.

A concept model is sometimes referred to as a meta-modelmeta-model, domain meta-model, or schema, and can be used to specify the abstract syntaxabstract syntax of a modeling language (refer to the Model Driven Architecture (MDA®) Foundation Model (OMG 2010)). Several other systems engineering concept models have been developed but not standardized. Future standardization efforts should establish a standard systems engineering 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

Works Cited

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

ISO. 2010. OMG System Modeling Language (OMG SysML), version 1.2. Needham, MA, USA: Object Management Group.

OMG. 2010. MDA Foundation Model. Needham, MA, USA: Object Management Group. Document number ORMSC/2010-09-06.

Primary References

ANSI/IEEE. 2000. Recommended Practice for Architectural Description for Software-Intensive Systems. New York, NY, USA: 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. New York, NY, USA: Springer-Verlag.

Guizzardi, G. 2007. "On ontology, ontologies, conceptualizations, modeling languages, and (meta)models," Proceedings of the 2007 Conference on Databases and Information Systems IV. Available at: http://portal.acm.org/citation.cfm?id=1565425.

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

INCOSE. 2003. Systems Engineering Concept Model. Draft 12 Baseline. Seattle, WA, USA: International Council on Systems Engineering. Available at: http://syseng.omg.org/SE_Conceptual%20Model/SE_Conceptual_Model.htm.

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

Additional References

None.


< Previous Article | Parent Article | Next Article >
SEBoK v. 2.3, released 30 October 2020