IEEE 1471 软件架构标准.pdf

发布时间：2022-06-14 发布人：admin 分类：说明书资料大小：0.28M 资料格式：pdf 举报版权申诉

d506c909-f050-49b4-a6a6-6b2fa1061ca5.pdf-第1页.png

第1页 / 共29页

d506c909-f050-49b4-a6a6-6b2fa1061ca5.pdf-第2页.png

第2页 / 共29页

d506c909-f050-49b4-a6a6-6b2fa1061ca5.pdf-第3页.png

第3页 / 共29页

d506c909-f050-49b4-a6a6-6b2fa1061ca5.pdf-第4页.png

第4页 / 共29页

d506c909-f050-49b4-a6a6-6b2fa1061ca5.pdf-第5页.png

第5页 / 共29页

d506c909-f050-49b4-a6a6-6b2fa1061ca5.pdf-第6页.png

第6页 / 共29页

d506c909-f050-49b4-a6a6-6b2fa1061ca5.pdf-第7页.png

第7页 / 共29页

d506c909-f050-49b4-a6a6-6b2fa1061ca5.pdf-第8页.png

第8页 / 共29页

IEEE Recommended Practice for Architectural Description of Software-Intensive Systems

Introduction

Participants

Contents

1. Overview

1.1 Scope

1.2 Purpose

1.3 Intended users

1.4 Conformance to this recommended practice

2. References

3. Definitions

4. Conceptual framework

4.1 Architectural description in context

4.2 Stakeholders and their roles

4.3 Architectural activities in the life cycle

4.4 Uses of architectural descriptions

5. Architectural description practices

5.1 Architectural documentation

5.2 Identification of stakeholders and concerns

5.3 Selection of architectural viewpoints

5.4 Architectural views

5.5 Consistency among architectural views

5.6 Architectural rationale

5.7 Example use

Annex A

Annex B

Annex C

Annex D

IEEE Std 1471-2000 IEEE Recommended Practice for Architectural Description of Software-Intensive Systems Sponsor Software Engineering Standards Committee of the IEEE Computer Society Approved 21 September 2000 IEEE-SA Standards Board architectural descriptions Abstract: This recommended practice addresses the activities of the creation, analysis, and sus- tainment of architectures of software-intensive systems, and the recording of such architectures in . A conceptual framework for architectural description is estab- terms of lished. The content of an architectural description is defined. Annexes provide the rationale for key concepts and terminology, the relationships to other standards, and examples of usage. Keywords: cerns, system stakeholder, view, viewpoint architectural description, architecture, software-intensive system, stakeholder con- The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright © 2000 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 9 October 2000. Printed in the United States of America. Print: PDF: ISBN 0-7381-2518-0 SH94869 ISBN 0-7381-2519-9 SS94869 No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior written permission of the publisher.

IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Com- mittees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve voluntarily and without compensation. They are not necessarily members of the Institute. The standards developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as well as those activities outside of IEEE that have expressed an interest in participating in the development of the standard. Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every ﬁve years for revision or reafﬁrmation. When a document is more than ﬁve years old and has not been reafﬁrmed, it is rea- sonable to conclude that its contents, although still of some value, do not wholly reﬂect the present state of the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership afﬁliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to speciﬁc applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE-SA Standards Board 445 Hoes Lane P.O. Box 1331 Piscataway, NJ 08855-1331 USA Note: Attention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. IEEE is the sole entity that may authorize the use of certiﬁcation marks, trademarks, or other designations to indicate compliance with the materials set forth herein. Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Cus- tomer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy portions of any individual standard for educational classroom use can also be obtained through the Copy- right Clearance Center.

Introduction (This introduction is not part of IEEE Std 1471-2000, Software-Intensive Systems .) IEEE Recommended Practice for Architectural Description of It has long been recognized that “architecture” has a strong inﬂuence over the life cycle of a system. In the past, hardware-related architectural aspects were dominant, whereas software-related architectural integrity, when it existed, often was to be sacriﬁced ﬁrst in the course of system development. Today, software- intensive systems are pervasive. The cost of software development and the increasing complexity of software systems have changed the relative balance. Software technology is maturing rapidly. The practice of system development can beneﬁt greatly from adherence to architectural precepts. However, the concepts of architecture have not been consistently deﬁned and applied within the life cycle of software-intensive systems. Despite signiﬁcant industrial and research activity in this area, there is no single, accepted framework for codifying architectural thinking, thereby facilitating the common application and evolution of available and emerging architectural practices. The IEEE Architecture Planning Group (APG) was formed in August 1995 to address this need. The APG was chartered by the IEEE Software Engineering Standards Committee (SESC) to set a direction for incor- porating architectural thinking into IEEE standards. The result of the APG’s deliberations was to recommend an IEEE activity with the following goals: — To deﬁne useful terms, principles and guidelines for the consistent application of architectural pre- cepts to systems throughout their life cycle — To elaborate architectural precepts and their anticipated beneﬁts for software products, systems, and aggregated systems (i.e., “systems of systems”) — To provide a framework for the colilection and consideration of architectural attributes and related information for use in IEEE standards — To provide a useful road map for the incorporation of architectural precepts in the generation, revi- sion, and application of IEEE standards In April 1996 SESC created the Architecture Working Group (AWG) to implement those recommendations. Copyright © 2000 IEEE. All rights reserved. iii

Participants At the time this recommended practice was completed, the Architecture Working Group had the following membership. Basil Sherlund, Chair Ronald L. Wade, Vice Chair David Emery, Rich Hilliard, Vice Chair for Liaison Secretary and Editor Frank C. Belz S. Jeromy Carriere Mark Dehlin Verlynda Dobbs Nancy Eickelmann Walter J. Ellis William Gess Vladan V. Jovanovic Judith S. Kerner Dwayne L. Knirk Ron Kohl Alexei E. Kotov Philippe Kruchten Simon Liu Mark W. Maier Bill McMullen Fatima Mili The following members of the balloting committee voted on this standard: Edward A. Addy Mario R. Barbacci Edward E. Bartlett Leo Beltracchi Frank C. Belz Richard E. Biehl Edward R. Byrne Lawrence Catchpole Leslie Chambers Keith Chow Antonio M. Cicu Sylvain Clermont Rosemary Coleman Darrell Cooksey Paul R. Croll Gregory T. Daich Bostjan K. Derganc Perry R. DeWeese Verlynda Dobbs Franz D. Engelmann William Eventoff Jonathan H. Fairclough John W. Fendrich John H. Fowler Eva Freund Andrew Gabb Juan Garbajosa-Sopena Hiranmay Ghosh Marilyn Ginsberg-Finner Julio Gonzalez-Sanz Lewis Gray L. M. Gunther John Harauz Herbert Hecht Mark Henley John W. Horch George Jackelen Frank V. Jorgensen Vladan V. Jovanovic William S. Junk Judith S. Kerner Thomas M. Kurihara Helmut Kurzdorfer Kyoung-In Kwon J. Dennis Lawrence Thomas B. Lindahl Jim J. Logan Henry A. Malec Tomoo Matsubara Ian R. McChesney James W. Moore Frederick I. Moxley Francisco Navas Plano Glenn Plonk Peter T. Poon Dave Rayford Ann Reedy Ira Sachs Thomas F. Saunders M. Wayne Shiveley Louise Tamres Pavol Navrat Gerald L. Ourada Alex Polack R. Razouk Annette D. Reilly Helmut Sandmayr Frederico Sousa Santos Robert J. Schaaf Carl A. Singer Richard S. Sky Mitchell W. Smith Fred J. Strauss Sandra Swearingen Toru Takeshita Richard H. Thayer Booker Thomas Leonard L. Tripp Theodore J. Urbanowicz Tom Vaiskunas Ronald L. Wade Randall K. Walters Larry L. Wear Charles J. Wertz Scott A. Whitmire Paul R. Work Natalie C. Yopconka Geraldine Zimmerman iv Copyright © 2000 IEEE. All rights reserved.

When the IEEE-SA Standards Board approved this standard on 21 September 2000, it had the following membership: Donald N. Heirman, Chair James T. Carlo, Vice Chair Judith Gorman, Secretary James H. Gurney Richard J. Holleman Lowell G. Johnson Robert J. Kennelly Joseph L. Koepﬁnger* Peter H. Lips L. Bruce McClung Daleep C. Mohla James W. Moore Robert F. Munzner Ronald C. Petersen Gerald H. Peterson John B. Posey Gary S. Robinson Akio Tojo Donald W. Zipse Satish K. Aggarwal Mark D. Bowman Gary R. Engmann Harold E. Epstein H. Landis Floyd Jay Forster* Howard M. Frazier Ruben D. Garzon *Member Emeritus Also included is the following nonvoting IEEE-SA Standards Board liaison: Alan Cookson, Donald R. Volzka, NIST Representative TAB Representative Noelle D. Humenick IEEE Standards Project Editor Copyright © 2000 IEEE. All rights reserved. v

Contents 1. Overview.............................................................................................................................................. 1 1.1 Scope............................................................................................................................................ 1 1.2 Purpose......................................................................................................................................... 1 1.3 Intended users .............................................................................................................................. 2 1.4 Conformance to this recommended practice................................................................................ 3 2. 3. 4. References............................................................................................................................................ 3 Definitions............................................................................................................................................ 3 Conceptual framework......................................................................................................................... 4 4.1 Architectural description in context............................................................................................. 4 4.2 Stakeholders and their roles ......................................................................................................... 6 4.3 Architectural activities in the life cycle ....................................................................................... 6 4.4 Uses of architectural descriptions ................................................................................................ 8 5. Architectural description practices ...................................................................................................... 8 5.1 Architectural documentation........................................................................................................ 8 5.2 Identification of stakeholders and concerns................................................................................. 9 5.3 Selection of architectural viewpoints........................................................................................... 9 5.4 Architectural views .................................................................................................................... 10 5.5 Consistency among architectural views..................................................................................... 11 5.6 Architectural rationale ............................................................................................................... 11 5.7 Example use ............................................................................................................................... 11 Annex A (informative) Bibliography............................................................................................................. 13 Annex B (informative) Notes on terminology ............................................................................................... 14 Annex C (informative) Examples of viewpoints ........................................................................................... 17 Annex D (informative) Relationship to other standards ................................................................................ 20 vi Copyright © 2000 IEEE. All rights reserved.

IEEE Recommended Practice for Architectural Description of Software-Intensive Systems 1. Overview 1.1 Scope This recommended practice addresses the architectural description of software-intensive systems. A is any system where software contributes essential inﬂuences to the design, software-intensive system construction, deployment, and evolution of the system as a whole. The scope of this recommended practice encompasses those products of system development that capture architectural information. This includes architectural descriptions that are used for the following: a) b) c) d) e) f) g) 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 Veriﬁcation of a system implementation’s compliance with an architectural description Recording contributions to the body of knowledge of software-intensive systems architecture 1.2 Purpose The purpose of this recommended practice is to facilitate the expression and communication of architectures and thereby lay a foundation for quality and cost gains through standardization of elements and practices for architectural description. Despite signiﬁcant efforts to improve engineering practices and technologies, software-intensive systems continue to present formidable risks and difﬁculties in their design, construction, deployment, and evolution. Recent attempts to address these difﬁculties have focused on the earliest period of design decision-making and evaluation, increasingly referred to as the archi- of system development. The phrases architectural level Copyright © 2000 IEEE. All rights reserved. 1

IEEE Std 1471-2000 IEEE RECOMMENDED PRACTICE FOR and level architecture are widely, if imprecisely, used. Their use reﬂects acceptance of an architec- tectural tural metaphor in the analysis and development of software-intensive systems. A key premise of this metaphor is that important decisions may be made early in system development in a manner similar to the early decision-making found in the development of civil architecture projects. Many innovations are resulting from this attention to the architectural level, among them architectural description languages and associated tools and environments; architectural frameworks, models, and patterns; and techniques for architectural analysis, evaluation, and architecture-based reuse. While these efforts differ considerably in important aspects, sufﬁcient commonality exists to warrant the development of a recommended practice to codify their common elements. architectural level of systems development These innovations are occurring, and maturing, rapidly within many research and application communities, and they reﬂect differing interests, inﬂuences, insights, and intentions. There is a general consensus on the , and that that level consists of early decision- importance of the making about overall design structure, goals, requirements, and development strategies. However, there has not yet emerged any reliable consensus on a precise deﬁnition of a system’s , i.e., how it should be described, what uses such a description may serve, or where and when it should be deﬁned. The bound- aries and relationships between architectural trends and practices, and other practices; and between architec- tural technology and other technology, are not yet widely recognized. architecture In such situations, progress often depends on mediating inﬂuences. Potential adopters of architectural practices and technology need a frame of reference within which to address implementation and adoption decisions. Technology developers need a frame of reference within which to communicate the motivating concepts of their technology, and to accumulate and appreciate feedback from early adoption. To these ends, this recommended practice is intended to reﬂect generally accepted trends in practices for architectural description and to provide a technical framework for further evolution in this area. Furthermore, it establishes a conceptual framework of concepts and terms of reference within which future developments in system architectural technology can be deployed. This recommended practice codiﬁes those elements on which there is consensus; speciﬁcally the use of multiple views, reusable speciﬁcations for models within views, and the relation of architecture to system context. 1.3 Intended users The principal class of users for this recommended practice comprises stakeholders in system development and evolution, including the following: — Those that use, own, and acquire the system (users, operators, and acquirers, or — Those that develop, describe, and document architectures (architects) — Those that develop, deliver, and maintain the system (architects, designers, programmers, maintain- ers, testers, domain engineers, quality assurance staff, conﬁguration management staff, suppliers, and project managers or ) developers ) clients — Those who oversee and evaluate systems and their development (chief information ofﬁcers, auditors, and independent assessors) A secondary class of users of this recommended practice comprises those involved in the enterprise-wide infrastructure activities that span multiple system developments, including methodologists, process and pro- cess-improvement engineers, researchers, producers of standards, tool builders, and trainers. 2 Copyright © 2000 IEEE. All rights reserved.

分享到：

赞收藏

资料库

IEEE 1471 软件架构标准.pdf

相关推荐

开发技术

热门标签

最新资料