Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards

Transcription

1 Fundamentals to Creating Architectures using ISO/IEC/IEEE Standards

2 What to Architect? How to Architect?

3 IEEE Goals and Objectives Chartered by IEEE Software Engineering Standards Committee to: Define direction for incorporating architectural thinking into IEEE standards Take a wide scope interpretation of architecture as applicable to software-intensive systems Establish a conceptual framework and vocabulary for talking about architectural issues of systems Identify and promulgate sound architectural practices Allow for the evolution of those practices as relevant technologies mature

4 Motivation Why Architecture? Why do some systems succeed? Explicitly architected systems seem to turn out faster, better and cheaper Architecture is recognized as a critical element in the successful development and evolution of software-intensive systems

5 Using the Standard The Standard is a recommended practice One kind of IEEE standard The Standard applies to Architectural Descriptions How to describe an architecture Not a standard architecture, or architectural process, or method The Standard is written in terms of shall, should and may ADs may be checked for conformance to the recommended practice The Standard does not define any conformance of systems, projects, organizations, processes, methods, or tools

6 Why should I use the Standard? Because there is a broad consensus that having a good architecture is critical to the success of a system or enterprise. The Standard reflects the current consensus of the systems and software community s best practices for describing architectures.

7 Purpose of IEEE 1471 According to IEEE 1471 an architecture description can be used for the following: Expression of the system and its evolution Communication among the system stakeholders Evaluation and comparison of architectures in a consistent manner Planning, managing, and executing the activities of system development Expression of the persistent characteristics and supporting principles of a system to guide acceptable change Verification of a system implementation s compliance with an architectural description Recording contributions to the body of knowledge of software-intensive systems architecture

8 History of the Current Standard August the IEEE Software Engineering Standards Committee (SESC) chartered an IEEE Architecture Planning Group (APG) to set direction for incorporating architectural thinking into IEEE standards. April the Architecture Working Group (AWG) was created to implement the recommendations made by APG to the SESC. The AWG had 25 members. Drafts of the specification were balloted and commented on by 130 international reviewers. In September 2000, the IEEE-SA Standards Board approved the specification as IEEE Std ISO/IEC Joint Technical Committee 1 (JTC1), Information technology / Subcommittee SC 7, Software and systems engineering, adopted the specification as ISO/IEC 42010, under a special fast-track procedure, in parallel with its approval by national bodies of ISO and IEC. A coordinated revision of this standard by ISO/IEC JTC1/SC7/WG42 and IEEE CS commenced in 2006, following the successful ISO/IEC fast-track ballot and in line with the IEEE standard 5-year review of the standard. November IEEE and ISO/IEC 42010:2007 was superseded by ISO/IEC/IEEE 42010:2011, Systems and software engineering Architecture description.

9 What kind of systems does the Standard cover? The focus of the Standard is on three classes of systems: software-intensive systems are systems in which software development and/or integration are dominant considerations (i.e., most complex systems these days). This includes computer-based systems ranging from individual software applications, information systems, embedded systems, software product lines and product families and systems-of-systems; general systems as defined in ISO/IEC 15288, Systems and software engineering Systems life cycle processes; and software products and services as defined in ISO/IEC 12207, Systems and software engineering Software life cycle processes.

10 Terminology According to IEEE Standard Glossary of Software Engineering Terminology, the following definitions are used: architect: The person, team, or organization responsible for designing systems architecture. architectural description (AD): A collection of products to document an architecture. Notation Independent. architecture: 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. designing: The activities of defining, documenting, maintaining, improving, and certifying proper implementation of an architecture. system: A collection of components organized to accomplish a specific function or set of functions. The term system encompasses individual applications, systems in the traditional sense, subsystems, systems of systems, product lines, product families, whole enterprises, and other aggregations of interest. system stakeholder: An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system. 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.

11 Architecture defined by Standard There are several key ideas in this definition: "Architecture" names that which is fundamental or unifying about a system as a whole; the set of essential properties of a system which determine its form, function, value, cost, and risk. An architecture is a conception of a system i.e., it is in the human mind. An architecture may exist without ever being written down. Therefore, the Standard distinguishes architectures and architecture descriptions: just as it is said, "the map is not the territory", an architecture description is not the architecture. An architecture description is what is written down as a concrete work product. An architecture description represents an attempt to express a conception of a system to share with others. The focus of the Standard is on requirements on architecture descriptions. An architecture is understood in context not in isolation. To understand a system s fundamental properties (i.e., architecture) is to understand how the system relates to, and is situated in, its environment. Often, the architect cannot know what is fundamental about a system without knowing fundamental to whom? Therefore "fundamental" is to be interpreted in the context of a system s stakeholders in its environment. Finally, there are some things that an architecture definitely is not. An architecture is not merely the overall structure of physical components that make up a system. While physical structure can be fundamental to a system, it need not be.

12 The Standard The Standard has several parts. The first part is a conceptual model of architecture descriptions (Ads). The conceptual model, sometimes called the metamodel, defines a set of terms and their relations. This metamodel has been widely used and discussed in industry and in the academic literature. The conceptual model establishes terms, their definitions and relations which are then used in expressing the requirements.

13 Architecture Descriptions (ADs) The second part of the Standard describes best practices for creating an architecture description. The best practices are specified in the Standard as 24 requirements (written as shalls ). An architecture description conforms to the Standard if it satisfies those requirements. Taken together, the shalls imply a process for preparing an AD. Templates for ADs and for documenting viewpoints are available.

14 Architecture Viewpoints At the core of the Standard is the idea of architecture viewpoints. A viewpoint is a way of looking at the architecture of a system or a set of conventions for a certain kind of architecture modeling. An architecture viewpoint is determined by: one or more concerns; typical stakeholders (interested in those concerns and therefore a potential audience for views resulting from this viewpoint); one or more model kinds; for each model kind (above), the conventions: languages, notations, modelling techniques, analytical methods and/or other operations to be used on models of this kind; sources.

15 Architecture Frameworks and ADLs The third part of the Standard specifies best practices for architecture frameworks. The Standard only specifies best practices on the documentation of architectures. It is intended to be used within a life cycle and/or within the context of a method or architecture framework used to develop Ads. The Standard may be used to structure an AD when applied with various architecture frameworks. For example, the Zachman framework matrix essentially identifies a set of stakeholders and concerns to be addressed, and the cell entries suggest the (viewpoint) notations, languages and models. The Standard also defines requirements on documenting an architecture framework. In a similar manner, the Standard can be used to specify Architecture Description Languages (ADLs).

16 Model and Meta Model is Important Since the initial publication of the Standard for Architecture Documentation, it has been built upon a conceptual model, often called a meta model, of the terms and concepts pertaining to Architecture Description. The revised 2011 Standard also established a specific requirement on architecture frameworks claiming conformance to the Standard that referred to the conceptual (or meta) model: An architecture framework shall establish its consistency with the provisions of the conceptual model. It is therefore, important to see, how various architecture frameworks (MODAF, DODAF, NAF, TRAK, TOGAF) use meta models. Jean Bézivin s On the Unification Power of Models offers a useful way of thinking about these matters. The diagram on next slide uses Bézivin s 3+1 MDA scheme from to sort out the concepts in the Standard.

17 3+1 MDA scheme Standard The left-hand side of the diagram depicts Bézivin s original scheme. The right-hand side shows where Standard constructs align with the levels. Level M0, the green level, depicts the real world of Systems, Architectures, their Stakeholders and Concerns.

18 Standard Level M1, the light blue level, is the world of models. Models represent things in the real world. Architecture Descriptions are models, consisting of other models: (Architecture) Views and (Architecture) Models, which represent Architectures. Level M1 is distinct from M0, as in the slogan: The map is not the territory. This distinction is useful to remember when talking to people who confuse Architectures and Architecture Descriptions (or do not use the latter term at all).

19 Standard Level M2 captures the conventions, or rules, that models on the M1 level conform, or adhere, to. This is the world of meta models. In the Standard, (Architecture) Viewpoints and Model Kinds are found at this level. Level M2 is distinct from M1; here the slogan could be: The map is not the legend. Often, the terms view and viewpoint are used interchangeably, or by folks who do not understand the difference. This explains that difference: viewpoints provide the conventions, the legends, for views.

20 Standard Level M3 is the world of meta meta models, where the rules for expressing conventions on models are located. Note that the Standard spans M2 and M3: it specifies both conventions on Architecture Descriptions, and conventions on specifying Viewpoints and Model Kinds (not shown: architecture frameworks and architecture description languages).

21 Architecture Frameworks The Standard defines architecture framework and specifies requirements on architecture frameworks. Architecture Framework: conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders Requirements on Frameworks An architecture framework conforms to the International Standard (IS) when it specifies: information identifying the framework; one or more concerns; one or more stakeholders having those concerns; one or more architecture viewpoints (and their specifications conforming to the IS); correspondence rules, integrating the viewpoints (as per IS); conditions on applicability (as per IS); consistency of the framework with the provisions of the Standard conceptual model.

22 A Conceptual Model of Architecture Description

23 About the Standard ISO/IEC/IEEE is based upon a conceptual model or meta model of the terms and concepts pertaining to Architecture Description. The conceptual model is presented in the Standard using UML class diagrams to represent classes of entities and their relationships.

24 In the Standard, architecture of a system is defined as: fundamental concepts or properties of a system in affordability, agility, its environment embodied in its elements, relationships, and in the principles of its design and evolution. The definition was chosen (1) to accommodate broad range of things listed above under System: the architecture of X is what is fundamental to X (whether X is an enterprise, system, system of systems, or some other entity); and (2) to emphasize that a system can have an architecture even if that architecture is not written down. Stakeholders have interests in a System; those interests are called Concerns. A system s Purpose is one very common Concern. Typical Stakeholders Client Acquirer Owner User Operator Architect System Engineer Developer Designer Builder Maintainer Service Provider Vendor Subcontractor Planner assurance, autonomy, behavior, business goals, business The Standard takes no position on Q. What is a system? strategies, complexity, In the Standard, the term system is used as a placeholder e.g., it could concurrency, refer to an enterprise, control, a system of systems, a product line, cost, a service, customer a subsystem, or software. Systems experience, can be man-made data or access, natural. Nothing in the Standard depends upon a particular definition of system. data accessibility, data Users of the Standard are free to employ whatever system theory they integrity, choose. deadlock, disposability, distribution, evolvability, feasibility, Systems exist. A System flexibility, is situated functionality, in its Environment. That environment could include other Systems. information assurance, inter-process communication, known limitations, maintainability, modifiability, modularity, openness, performance, persistence, privacy, quality of service, regulatory compliance, reliability, resource utilization, safety, schedule, security, state change, structure, subsystem integration, system features, system properties, system purposes, usability, and usage. Systems have Architectures. An Architecture Description is used to express an Architecture of a System. Context Architecture Description An Architecture Description (AD) is an artifact that expresses an Architecture. Architects and other system stakeholders use ADs to understand, analyze and compare Architectures, and often as blueprints for planning and construction. Every System inhabits its Environment. A System acts upon that Environment and vice versa. A system s Environment determines the range of influences upon the system. In the Standard, Environment is intended in the widest possible sense to include developmental, operational, technical, political, regulatory, and all other influences which can affect the architecture. These influences are categorized as Concerns. In original edition of the Standard, systems were said to have missions; in revision, Purpose was chosen as a more general replacement to this term. Premise of Standard is, for a system of interest to you, the Standard provides guidance for documenting an architecture for that system.

25 Core of Architecture Description Stakeholders are individuals, groups or organizations holding Concerns for the System of Interest. Examples of stakeholders: client, owner, user, consumer, supplier, designer, maintainer, auditor, CEO, certification authority, architect. An Architecture Description is a work product used to express the Architecture of some System Of Interest. The Standard specifies requirements on ADs. An AD describes one possible Architecture for a System Of Interest. An AD may take the form of a document, a set of models, a model repository, or some other form (AD format is not defined by the Standard). A Concern is any interest in the system. The term derives from the phrase separation of concerns as originally coined by Dijkstra. Examples of concerns: (system) purpose, functionality, structure, behavior, cost, supportability, safety, interoperability. An Architecture Viewpoint is a set of conventions for constructing, interpreting, using and analyzing one type of Architecture View. A viewpoint includes Model Kinds, viewpoint languages and notations, modeling methods and analytic techniques to frame a specific set of Concerns. Examples of viewpoints: operational, systems, technical, logical, deployment, process, information. A Model Kind defines the conventions for one type of Architecture Model. An Architecture View in an AD expresses the Architecture of the System of Interest from the perspective of one or more Stakeholders to address specific Concerns, using the conventions established by its viewpoint. An Architecture View consists of one or more Architecture Models. Each model is constructed in accordance with the conventions established by its Model Kind, typically defined as part of its governing viewpoint. Models provide a means for sharing details between views and for the use of multiple notations within a view. Standard is organized around terms & concepts of the diagram above. It depicts the contents of an AD and the relations between those content items when applying the Standard to produce an AD to express an Architecture for some System of Interest.

26 AD Elements and Correspondences Correspondences can be governed by Correspondence Rules. Correspondences capture relationships within or between AD Elements. Correspondences and Correspondence Rules are used to express and enforce architecture relations such as composition, refinement, consistency, traceability, dependency, constraint and obligation within or between ADs. Any item in an AD is considered an element. Architecture Descriptions are comprised of AD Elements. Every Stakeholder, Concern, Viewpoint, View, Model Kind in an AD is an AD Element. When a Viewpoint or Model Kind introduces constructs, these too are considered AD Elements.

27 Architecture Decisions and Rationale Architecture Rationale records the explanation, justification or reasoning about Architecture Decisions that have been made and architectural alternatives not chosen. An Architecture Decision affects AD Elements and pertains to one or more Concerns. By making a Decision, new Concerns may be raised. Creating an Architecture involves making Architecture Decisions. ISO/IEC/IEEE specifies requirements for capturing key decisions within an AD in terms of the concepts shown in the above diagram.

28 Architecture Frameworks and Architecture Description Languages An architecture framework establishes a common practice for creating, interpreting, analyzing and using architecture descriptions within a particular domain of application or stakeholder community. Examples of Architecture Frameworks: MODAF, TOGAF, Kruchten s 4+1 View Model, RM-ODP, Zackman. An ADL is any form of expression for use in ADs. An ADL might include a single Model Kind, a single viewpoint or multiple viewpoints. Diagram depicting contents of an Architecture Framework Examples of ADLs: Rapide, SysML, ArchiMate, ACME, xadl. Architecture frameworks and ADLs are two mechanisms widely used in architecting.

29 Elements of ADL

30 Some Important Questions

31 How does the Standard relate to the Unified Modeling Language? UML provides a family of notations; many of these notations can, and have, been used for architecture description. A number of organizations already use one or more of the UML notations to frame various system concerns. Using the Standard, these notations may be made part of a viewpoint and used to create an architecture description. By defining these practices through viewpoints, a organization can continue to use the UML while creating architecture descriptions that conforming to the Standard.

32 Does the Standard require a specific Architecting process? No, the Standard is process neutral. It defines what you should have when you claim to have an architecture description; it does not mandate how to produce one. There are many architecting processes and methods being used with the Standard. Processes and methods for Architecting may be areas for future standardization.

33 Does conforming with the Standard lead to better systems? We hope so, but we would not claim that system quality is an automatic, direct consequence of using the Standard by itself. The intended consequence of using it is more understandable ADs, which should contribute to better architectures, and thus to better systems.

34 Does the Standard require a particular ADL? If not, why not? No. There are numerous ADLs and other notations that are valuable for documenting various aspects of the architecture of a system. Using the Standard, the architect may pick one, or more than one, or make up her own. The Standard avoids choosing a particular ADL for the same reasons that it does not require a particular set of viewpoints: systems vary in the concerns that need to be addressed. The philosophy of the Standard is use the right tool for the job: choose notations appropriate to framing the relevant concerns that arise for the system at hand. If this can be accomplished with a single ADL; that s great. If other notations are needed; use them in a principled fashion within the organizing framework offered by the Standard.