IEEE 1471-2000 en Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Computer Society)《体系结构描述的推荐规程》.pdf

《IEEE 1471-2000 en Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Computer Society)《体系结构描述的推荐规程》.pdf》由会员分享，可在线阅读，更多相关《IEEE 1471-2000 en Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Computer Society)《体系结构描述的推荐规程》.pdf（34页珍藏版）》请在麦多课文档分享上搜索。

1、 Reference numberISO/IEC 42010:2007(E)IEEEStd 1471-2000INTERNATIONAL STANDARD ISO/IEC42010IEEEStd 1471-2000First edition2007-07-15Systems and software engineering Recommended practice for architectural description of software-intensive systems Ingnierie des logiciels et des systmes Pratique recomman

2、de pour la description architecturale des systmes exigeant beaucoup de logiciels The Institute of Electrical and Electronics Engineers, Inc.3 Park Avenue, New York, NY 10016-5997, USACopyright 2000 by the Institute of Electrical and Electronics Engineers, Inc.All rights reserved. Published 9 October

3、 2000. Printed in the United States of America.Print:ISBN 0-7381-2518-0 SH94869PDF:ISBN 0-7381-2519-9 SS94869No 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 Std 1471-2000IEEE Recomme

4、nded Practice for Architectural Description ofSoftware-Intensive Systems SponsorSoftware Engineering Standards Committeeof theIEEE Computer SocietyApproved 21 September 2000IEEE-SA Standards BoardAbstract:This recommended practice addresses the activities of the creation, analysis, and sus-tainment

5、of architectures of software-intensive systems, and the recording of such architectures interms of architectural descriptions. A conceptual framework for architectural description is estab-lished. The content of an architectural description is defined. Annexes provide the rationale for keyconcepts a

6、nd terminology, the relationships to other standards, and examples of usage.Keywords:architectural description, architecture, software-intensive system, stakeholder con-cerns, system stakeholder, view, viewpointISO/IEC 42010:2007(E) IEEE Std 1471-2000 PDF disclaimer This PDF file may contain embedde

7、d typefaces. In accordance with Adobes licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In downloading this file, parties accept therein the responsibility of not

8、 infringing Adobes licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation parameters wer

9、e optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below. ISO Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749

10、 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org ii International Organization for Standardization/International Electrotechnical Commission Case postale 56 CH-1211 Genve 20 Switzerland International Standard ISO/IEC 42010:2007(E) ISO (the International Organization for Standardi

11、zation) and IEC (the International Electrotechnical Commission) form the specialized system for worldwide standardization. National bodies that are members of ISO or IEC participate in the development of International Standards through technical committees established by the respective organization

12、to deal with particular fields of technical activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the work. In the field of information technology, ISO

13、and IEC have established a joint technical committee, ISO/IEC JTC 1. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of the joint technical committee is to prepare International Standards. Draft International Standards adopted b

14、y the joint technical committee are circulated to national bodies for voting. Publication as an International Standard requires approval by at least 75 % of the national bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject of pate

15、nt rights. ISO and IEC shall not be held responsible for identifying any or all such patent rights. ISO/IEC 42010 was prepared by IEEE (as IEEE Std 1471-2000) and was adopted, under a special “fast-track procedure”, by Joint Technical Committee ISO/IEC JTC 1, Information technology, Subcommittee SC

16、7, Software and systems engineering, in parallel with its approval by national bodies of ISO and IEC. The IEEE Computer Society will cooperate in the maintenance of this International Standard as a Category A liaison to SC 7. ISO/IEC 42010:2007(E) IEEE Std 1471-2000 IEEE Standardsdocuments are devel

17、oped within the IEEE Societies and the Standards Coordinating Com-mittees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees servevoluntarily and without compensation. They are not necessarily members of the Institute. The standardsdeveloped within IEEE represent

18、a consensus of the broad expertise on the subject within the Institute aswell as those activities outside of IEEE that have expressed an interest in participating in the development ofthe standard.Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that ther

19、eare no other ways to produce, test, measure, purchase, market, or provide other goods and services related tothe scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved andissued is subject to change brought about through developments in the state of the

20、art and commentsreceived from users of the standard. Every IEEE Standard is subjected to review at least every ve years forrevision or reafrmation. When a document is more than ve years old and has not been reafrmed, it is rea-sonable to conclude that its contents, although still of some value, do n

21、ot wholly reect the present state ofthe 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 membershipafliation with IEEE. Suggestions for changes in documen

22、ts should be in the form of a proposed change oftext, together with appropriate supporting comments.Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as theyrelate to specic applications. When the need for interpretations is brought to the attention of

23、IEEE, theInstitute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus ofall concerned interests, it is important to ensure that any interpretation has also received the concurrence of abalance of interests. For this reason, IEEE and the members of its s

24、ocieties and Standards CoordinatingCommittees are not able to provide an instant response to interpretation requests except in those cases wherethe matter has previously received formal consideration. Comments on standards and requests for interpretations should be addressed to:Secretary, IEEE-SA St

25、andards Board445 Hoes LaneP.O. Box 1331Piscataway, NJ 08855-1331USAIEEE is the sole entity that may authorize the use of certication marks, trademarks, or other designations toindicate compliance with the materials set forth herein.Authorization to photocopy portions of any individual standard for i

26、nternal or personal use is granted by theInstitute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to CopyrightClearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Cus-tomer Service, 222 Rosewood Drive, Danvers

27、, MA 01923 USA; (978) 750-8400. Permission to photocopyportions of any individual standard for educational classroom use can also be obtained through the Copy-right Clearance Center.Note: Attention is called to the possibility that implementation of this standard mayrequire use of subject matter cov

28、ered by patent rights. By publication of this standard,no position is taken with respect to the existence or validity of any patent rights inconnection therewith. The IEEE shall not be responsible for identifying patents forwhich a license may be required by an IEEE standard or for conducting inquir

29、ies intothe legal validity or scope of those patents that are brought to its attention.Copyright 2000 IEEE. All rights reserved.iiiIEEE Introduction(This introduction is not part of IEEE Std 1471-2000, IEEE Recommended Practice for Architectural Description ofSoftware-Intensive Systems.)It has long

30、been recognized that “architecture” has a strong inuence over the life cycle of a system. In thepast, hardware-related architectural aspects were dominant, whereas software-related architectural integrity,when it existed, often was to be sacriced rst in the course of system development. Today, softw

31、are-intensive systems are pervasive. The cost of software development and the increasing complexity of softwaresystems have changed the relative balance. Software technology is maturing rapidly. The practice of systemdevelopment can benet greatly from adherence to architectural precepts.However, the

32、 concepts of architecture have not been consistently dened and applied within the life cycle ofsoftware-intensive systems. Despite signicant industrial and research activity in this area, there is no single,accepted framework for codifying architectural thinking, thereby facilitating the common appl

33、ication andevolution of available and emerging architectural practices.The IEEE Architecture Planning Group (APG) was formed in August 1995 to address this need. The APGwas chartered by the IEEE Software Engineering Standards Committee (SESC) to set a direction for incor-porating architectural think

34、ing into IEEE standards. The result of the APGs deliberations was to recommendan IEEE activity with the following goals: To dene useful terms, principles and guidelines for the consistent application of architectural pre-cepts to systems throughout their life cycle To elaborate architectural precept

35、s and their anticipated benets for software products, systems, andaggregated systems (i.e., “systems of systems”) To provide a framework for the colilection and consideration of architectural attributes and relatedinformation for use in IEEE standards To provide a useful road map for the incorporati

36、on of architectural precepts in the generation, revi-sion, and application of IEEE standardsIn April 1996 SESC created the Architecture Working Group (AWG) to implement those recommendations.ivCopyright 2000 IEEE. All rights reserved.ParticipantsAt the time this recommended practice was completed, t

37、he Architecture Working Group had the followingmembership. Basil Sherlund, ChairRonald L. Wade, Vice ChairDavid Emery, Vice Chair for LiaisonRich Hilliard, Secretary and EditorThe following members of the balloting committee voted on this standard:Frank C. BelzS. Jeromy CarriereMark DehlinVerlynda D

38、obbsNancy EickelmannWalter J. EllisWilliam GessVladan V. JovanovicJudith S. KernerDwayne L. KnirkRon KohlAlexei E. KotovPhilippe KruchtenSimon LiuMark W. MaierBill McMullenFatima MiliGlenn PlonkPeter T. PoonDave RayfordAnn ReedyIra SachsThomas F. SaundersM. Wayne ShiveleyLouise TamresEdward A. AddyM

39、ario R. BarbacciEdward E. BartlettLeo BeltracchiFrank C. BelzRichard E. BiehlEdward R. ByrneLawrence CatchpoleLeslie ChambersKeith ChowAntonio M. CicuSylvain ClermontRosemary ColemanDarrell CookseyPaul R. CrollGregory T. DaichBostjan K. DergancPerry R. DeWeeseVerlynda DobbsFranz D. EngelmannWilliam

40、EventoffJonathan H. FaircloughJohn W. FendrichJohn H. FowlerEva FreundAndrew GabbJuan Garbajosa-SopenaHiranmay GhoshMarilyn Ginsberg-FinnerJulio Gonzalez-SanzLewis GrayL. M. GuntherJohn HarauzHerbert HechtMark HenleyJohn W. HorchGeorge JackelenFrank V. JorgensenVladan V. JovanovicWilliam S. JunkJudi

41、th S. KernerThomas M. KuriharaHelmut KurzdorferKyoung-In KwonJ. Dennis LawrenceThomas B. LindahlJim J. LoganHenry A. MalecTomoo MatsubaraIan R. McChesneyJames W. MooreFrederick I. MoxleyFrancisco Navas PlanoPavol NavratGerald L. OuradaAlex PolackR. RazoukAnnette D. ReillyHelmut SandmayrFrederico Sou

42、sa SantosRobert J. SchaafCarl A. SingerRichard S. SkyMitchell W. SmithFred J. StraussSandra SwearingenToru TakeshitaRichard H. ThayerBooker ThomasLeonard L. TrippTheodore J. UrbanowiczTom VaiskunasRonald L. WadeRandall K. WaltersLarry L. WearCharles J. WertzScott A. WhitmirePaul R. WorkNatalie C. Yo

43、pconkaGeraldine ZimmermanCopyright 2000 IEEE. All rights reserved.vWhen the IEEE-SA Standards Board approved this standard on 21 September 2000, it had the followingmembership:Donald N. Heirman,ChairJames T. Carlo,Vice ChairJudith Gorman,Secretary*Member EmeritusAlso included is the following nonvot

44、ing IEEE-SA Standards Board liaison:Alan Cookson, NIST RepresentativeDonald R. Volzka, TAB RepresentativeNoelle D. HumenickIEEE Standards Project EditorSatish K. AggarwalMark D. BowmanGary R. EngmannHarold E. EpsteinH. Landis FloydJay Forster*Howard M. FrazierRuben D. GarzonJames H. GurneyRichard J.

45、 HollemanLowell G. JohnsonRobert J. KennellyJoseph L. Koepnger*Peter H. LipsL. Bruce McClungDaleep C. MohlaJames W. MooreRobert F. MunznerRonald C. PetersenGerald H. PetersonJohn B. PoseyGary S. RobinsonAkio TojoDonald W. ZipseviCopyright 2000 IEEE. All rights reserved.Contents1. Overview11.1 Scope1

46、1.2 Purpose.11.3 Intended users21.4 Conformance to this recommended practice32. References33. Definitions34. Conceptual framework.44.1 Architectural description in context.44.2 Stakeholders and their roles.64.3 Architectural activities in the life cycle.64.4 Uses of architectural descriptions85. Arc

47、hitectural description practices85.1 Architectural documentation85.2 Identification of stakeholders and concerns.95.3 Selection of architectural viewpoints.95.4 Architectural views105.5 Consistency among architectural views.115.6 Architectural rationale.115.7 Example use.11Annex A (informative) Bibl

48、iography.13Annex B (informative) Notes on terminology.14Annex C (informative) Examples of viewpoints.17Annex D (informative) Relationship to other standards20Copyright 2000 IEEE. All rights reserved.1IEEE Recommended Practice for Architectural Description ofSoftware-Intensive Systems 1. Overview1.1

49、ScopeThis recommended practice addresses the architectural description of software-intensive systems. Asoftware-intensive systemis any system where software contributes essential inuences to the design,construction, deployment, and evolution of the system as a whole. The scope of this recommended practice encompasses those products of system development that capturearchitectural information. This includes architectural descriptions that are used for the following:a) Expression of the system and its evolutionb) Communication among the system