Difference between revisions of "Architecture (glossary)"
m (Text replace - "System of Interest" to "System-of-Interest") |
|||
| Line 14: | Line 14: | ||
===Discussion=== | ===Discussion=== | ||
A few definitions are presented here to provide illustrations of how some different authors define architecture. Note that many authors write extensively on architecture without ever defining what they mean by the term. | A few definitions are presented here to provide illustrations of how some different authors define architecture. Note that many authors write extensively on architecture without ever defining what they mean by the term. | ||
| + | |||
| + | The use of the word 'fundamental' (definitions (1) and (3)) is problematic, since it has no universal definition. In practice, the level of detail in an architecture depends on the context of use and purpose to which it is to be put. In the early (conceptual) stages it might only contain high-level description of the system as a whole, but in later stages the key features of all key subsystems would need to be mapped out. An architectural description should therefore also justify what is included and excluded. | ||
ISO/IEC/IEEE 15288 is normative - see above. The architecture associated with a System-of-Interest is conceptual, and is realized through an architectural description. | ISO/IEC/IEEE 15288 is normative - see above. The architecture associated with a System-of-Interest is conceptual, and is realized through an architectural description. | ||
Revision as of 15:05, 15 March 2013
(1) The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (ISO/IEC 2008, Section 4.5)
(2) The organizational structure of a system or component (ISO/IEC 2009, 1); the organizational structure of a system and its implementation guidelines. (ISO/IEC 2009, 1)
(3) Fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (ISO/IEC 2011, section 3.2)
Source
(1) ISO/IEC/IEEE. 2008. Systems and Software engineering — System Life Cycle Processes. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electronical Commission (IEC). ISO/IEC 15288:2008 (E).
(2) ISO/IEC/IEEE. 2009. Systems and Software Engineering — System and Software Engineering Vocabulary Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronic Engineers (IEEE) 2009 ISO/IEC/IEEE 24765:2009 [database online]. Available from http://pascal.computer.org/sev_display/index.action.
(3) ISO/IEC/IEEE. 2011. Systems and Software Engineering — Architectural Description. Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 42010:2011.
Discussion
A few definitions are presented here to provide illustrations of how some different authors define architecture. Note that many authors write extensively on architecture without ever defining what they mean by the term.
The use of the word 'fundamental' (definitions (1) and (3)) is problematic, since it has no universal definition. In practice, the level of detail in an architecture depends on the context of use and purpose to which it is to be put. In the early (conceptual) stages it might only contain high-level description of the system as a whole, but in later stages the key features of all key subsystems would need to be mapped out. An architectural description should therefore also justify what is included and excluded.
ISO/IEC/IEEE 15288 is normative - see above. The architecture associated with a System-of-Interest is conceptual, and is realized through an architectural description.
ISO/IEC/IEEE 42010 is normative - see above.
OMG.2010. is normative - “The organizational structure and associated behavior of a system. An architecture can be recursively decomposed into parts that interact through interfaces, relationships that connect parts, and constraints for assembling parts.”
Works Cited
UML 2010. Unified Modeling Language. Version 2.3. Needham, MA, USA: Object Management Group.
OMG. 2010. OMG Systems Modeling Language specification, version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.
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 Disqus