Difference between revisions of "System Modeling Concepts"
Wikiexpert (talk | contribs) m (Removed protection from "System Modeling Concepts") |
Wikiexpert (talk | contribs) |
||
| Line 57: | Line 57: | ||
[[Category:Part 2]][[Category:Topic]] | [[Category:Part 2]][[Category:Topic]] | ||
[[Category:Representing Systems with Models]] | [[Category:Representing Systems with Models]] | ||
| + | {{DISQUS}} | ||
Revision as of 18:44, 23 May 2012
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 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 , while 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 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.
View and Viewpoint
IEEE 1471, a standard for architecture modeling, defines "view" and "viewpoint" as follows:
- view : A representation of a whole system from the perspective of a related set of concerns
- 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
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.
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.
Concept 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 requirements , behavior , structure , and properties . 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 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 (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 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 . 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 concept model is sometimes referred to as a meta-model , 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.
References
Works Cited
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". 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. Seattle, WA: 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: 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
OMG. 2010. MDA Foundation Model. Needham, MA, USA: Object Management Group. Document number ORMSC/2010-09-06.
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.
SEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by DisqusSEBoK Discussion
Please provide your comments and feedback on the SEBoK below. You will need to log in to DISQUS using an existing account (e.g. Yahoo, Google, Facebook, Twitter, etc.) or create a DISQUS account. Simply type your comment in the text field below and DISQUS will guide you through the login or registration steps. Feedback will be archived and used for future updates to the SEBoK. If you provided a comment that is no longer listed, that comment has been adjudicated. You can view adjudication for comments submitted prior to SEBoK v. 1.0 at SEBoK Review and Adjudication. Later comments are addressed and changes are summarized in the Letter from the Editor and Acknowledgements and Release History.
If you would like to provide edits on this article, recommend new content, or make comments on the SEBoK as a whole, please see the SEBoK Sandbox.
blog comments powered by Disqus