1、ECMA EUROPEAN COMPUTER MANUFACTURERS ASSOCIATION REFERENCE MODEL FOR FRAMEWORKS OF SOFTWARE ENGINEERING ENVIRONMENTS ECMA TRES NIST Special Publication 500-211 This publication is a revision of Technical Report ECMA TR/55, first published in December 1990, and has been prepared jointly by the ECMA T
2、C33 Task Group on the Reference Model and the ISEE Working Group of the National Institute of Standards and Technology (NIST) of the United States Department of Commerce. This report is also published as NIST Special Publication 500-21 1. 3rd Edition, June 1993 Free copies of this document are avail
3、able from ECMA, European Computer Manufacturers Association, 114 Rue du Rhne - CH-124 Geneva (Switzerland) Phone: +4122 735 36 34 Fax: 41 22 786 52 31 X.400: C=ch, A=arcom, P=ecma, (kgenevanet, OU 1 =ma, S=helpdesk Internet: helpdeskecma.ch ECMA EUROPEAN COMPUTER MANUFACTURERS ASSOCIATION REFERENCE
4、MODEL FOR FRAMEWORKS OF SOFTWARE ENGINEERING ENVIRONMENTS ECMA TR/55 NIST Special Publication 500-211 This publication is a revision of Technical Report ECMA TR/55, first published in December 1990, and has been prepared jointly by the ECMA TC33 Task Group on the Reference Model and the ISEE Working
5、 Group of the National Institute of Standards and Technology (NIST) of the United States Department of Commerce. This report is also published as NIST Special Publication 500-2 1 1. 3rd Edition, June 1993 . 111 Brief History Work on a reference model for Software Engineering Environments (SEEs) has
6、been in progress for the past years on both sides of the Atlantic. A key objective of the work in reference models for SEEs has been to find better ways to describe SEES and to assist the SEE architectural standardisation process. The reference model has gained increasing interest in the software en
7、vironments community. It is hoped that the concepts described within the reference model can guide the evolution of SEE environment architectures. When the European Computer Manufacturers Association (ECMA) Technical Committee for Portable Com- mon Tool Environment (PCTE) standardisation was formed,
8、 one aim was to create an environment framework reference model (RM) to assist the standardization process. A Task Group on the Reference Model (TGRM) wan formed in 1988 to develop a complete reference model. During 1989 the first full version of the reference model was created, and during 1990 the
9、model was evaluated by using it to describe a number of environment frameworks. That version of the reference model was published as an ECMA technical report in December 1990. The model covers the set of services needed to describe environment frameworks. The particular services of the model are des
10、cribed to a degree of detail that ia complete enough for the model to be used to describe existing systems and proposals. Although ECMA TC33 created ECMA TC33/TGRM to develop a model that could be used to describe PCTE, subsequent work on the reference model was totally independent of PCTE and was n
11、ot intentionally biased towards it. Beginning in 1989, the NIST Integrated Software Engineering Environment (ISEE) Working Group has also been developing a reference model for SEEs. This Working Group decided to adopt the ECMA RM as a basis for its own work and has enhanced and extended the model to
12、 support NIST goals. To test the model, it was used by NIST ISEE and ECMA TC33/TGRM to map several existing products to the RM in order to test the effectiveness and coverage of the Services specified (CAIS-A 30, PCTE 35, SLCSE 80, AD/cycle 49, ATIS 26, Emeraude PCTE, and COHESION 14). Edition 2 of
13、this document, published December 1991, represents the results of discussions held at various NIST ISEE workshops and comments provided by the participants of these workshops, as well as a review by the members of ECMA TC33/TGRM. During 1992, a Reference Model Change Control Board, consisting of mem
14、bers of ECMA TC33/TGRM and the NIST ISEE Working Group, met several times to prepare this third edition of this document in response to receipt of approximately 200 requested changes. The U.S. Navys NGCR PSESWG program was particularly helpful in pointing out issues that needed clarification. Major
15、changes for this third edition include the addition of operating system services, enhanced user interface services, a rewritten policy enforcement clause, and replacement of the graphic describing the model. This report is published jointly as an ECMA Technical Report and a NIST Special Publication.
16、 Accepted as an ECMA Technical Report by the General Assembly of June, 1993. Certain commercial products are identified in this report. Such identification does not imply recommendation or endorsement by the National Institute of Standards and Technology or the European Computer Manufac- turers Asso
17、ciation, nor does it imply that the product, publication, or service identified is necessarily the best available for the purpose. V Table of Contents Section I . Software Engineering Environment Frameworks 1 1 Scope 1 Scope of Software Engineering Environments (SEE) and SEE Frameworks 1.2 Scope of
18、the SEE Frameworks Reference Model . 2 1.3 Aims of the Reference Model . 2 1.4 List of Acronyms 5 1.1 1 2 SEE Frameworks Reference Model 7 . 2.1 Frameworks 7 2.2 SEE Reference Model Structure 7 2.3 Reference Model Dimensions . 14 3 SEE Issues 16 16 3.1 Integration . 3.2 Process Support 18 Section II
19、 . Framework Service Descriptions 21 4 Object Management Services 21 4.2 Data Storage and Persistence Service . 23 4.3 Relationship Service 25 4.4 NameService 26 4.5 Distribution and Location Service . 28 4.6 Data Transaction Service . 30 4.7 Concurrency Service 4.8 OS Process Support Service 33 4.9
20、 Archive Service . 34 4.10 Backup Service . 35 4.11 Derivation Service . 36 4.12 Replication and Synchronization Service . 4.13 Access Control and Security Service . 39 4.14 Function Attachment Service . 40 4.15 Common Schema Service . 42 4.1 Metadata Service 21 31 38 . 4.16 Version Service 43 vi 4.
21、17 Composite Object Service . 45 4.18 Query Service 46 4.19 State Monitoring and Triggering Service . 4.20 Data Subsetting Service 49 4.21 Data Interchange Service . 51 47 5 Process Management Services 53 5.1 Process Development Service . 53 5.2 Process Enactment Service 57 5.3 Process Visibility Se
22、rvice . 59 5.4 Process Monitoring Service 61 5.5 Process Transaction Service 62 5.6 Process Resource Service 64 6 Communication Services 66 6.1 Data Sharing Service 66 6.2 Interprocess Communication Service . 67 6.3 Network Service 67 6.4 Measage Service . 68 6.5 Event Notification Service . 70 7 Op
23、erating System Services 71 7.1 Operating System Process Management . 71 7.2 Operating System Environment Service . 72 7.3 Operating System Synchronization Service 73 7.4 Generalized Input and Output 74 7.5 File Storage Service 75 7.6 Asynchronous Event Service 76 7.7 Interval Timing Service 77 7.0 M
24、emory Management Service . 78 7.9 Physical Device Service 79 7.10 Operating System Resource Management Service 80 8 User Interface Services 81 8.1 User Interface Metadata Service 02 0.2 Session Service . 03 8.3 Text Input Service . 84 vii 8.4 Dialog Service 85 8.5 Display Management Service . 87 8.6
25、 Presentation Service 88 8.7 U1 Security Service . 8.8 User Interface Name and Location service 89 8.9 Internationalization Service 90 8.10 User Assistance Service 92 89 9 Policy Enforcement Services 93 9.1 Security Information Service 94 9.2 Identification and Authentication Service 95 9.3 Mandator
26、y Access Control Service 96 9.4 Discretionary Access Control Service . 98 9.5 Mandatory Integrity Service 99 9.6 Discretionary Integrity Service 100 9.7 Secure Object Exportation and Importation Service 102 9.8 Audit Service 103 10 Framework Administration Services 104 10.1 Registration Service 104
27、10.2 Resource Management Service . 106 10.3 Metrication Service . 107 10.4 SubEnvironment Service . 109 10.5 Self-Configuration Management Service . 110 10.6 License Management Service . 111 A Bibliography 113 B Reference Model Structure 118 1 Section I. Software Engineering Environment Frameworks 1
28、 Scope This document describes a reference model (RM) for Software Engineering Environment (SEE) Frameworks. This clause provides some motivation for the work presented in this document. It then provides the key aims of the SEE RM. Following clauses describe the structure of the SEE RM and the servi
29、ces that comprise it. 1.1 Scope of Software Engineering Environments (SEE) and SEE Frameworks Soflware Engineering means the planned process of producing well-structured, reliable, good-quality, main- tainable software systems within reasonable time frames76. Soflwore Engineerng Environment means th
30、e systemi5 which provides automated support of the engineering of software systems and the management of the software process. Alternative equivalent names for an SEE are IPSE (Integrated Project Support Environment), CASE (Com- puter Assisted Software Engineering), SDE (Software Development Environ
31、ment), ISEE (Integrated Software Engineering Environment), and ISF (Integrated Software Factory). No distinction is made between these terms in this document. A Software Engineering Environment deals with information about: a) the software under development (e.g., specifications, design data, source
32、 code, test data, and project plans); b) project resources (e.g., costs, computer resources, and people working on the production of software and their assignments and management duties); and c) organisation policy, standards and guidelines on the production of software. An SEE may store information
33、 about target hardware for which software is being developed, but it typically does not store information about the design or development of the hardware. An SEE typically does not deal with company finances or marketing information because these do not relate directly to software engineering. SEES
34、are typically built on hardware and operating system platforms. Current SEE architectures distinguish between the set of facilities in support of the life cycle project, usually denoted Tools, and a set of (relatively) fixed infrastructure capabilities which provide support for processes, objects, o
35、r user interfaces, denoted SEE hmework 54. A major purpose of frameworks ia to simplify the construction of tools by providing a set of commonly needed facilities, key integration components, and support for higher level constructs than those found in typical operating systems. Another purpose may b
36、e to support the porting of environments across a variety of hardware configurations and native operating systems. Tools may also use services provided by other tools, and framework components may use services from other framework components. Groups needing access to framework components include the
37、 following: Platform suppliers. They need to provide the hardware and operating system platforms to access the resources of the environment and provide the primitive functionality used by the framework. Environment suppliers. They need to provide the framework components for interfacing between the
38、user and the resources of the platform and provide most of the functionality described by this reference model. Tool suppliers. The work of producing SEE components (e.g., additional framework components, tools, and generic utilities) is typically carried out by environment and tool builders. This l
39、evel provides the “value added” needed to make the framework into an effective environment for solving environment user needs. Users. They use the environment for solving various application problems. Designers, developers, managers, environment administrators, configuration controllers, and secreta
40、ries use the customized environment to build target systems according to the customers software requirements. Some classes of users will inevitably use certain framework services directly (e.g., query and backup on the projects environment 2 database), analogous to direct usage of OS command on many
41、 systems in the past, rather than always using higher level functional abstractions which are tools. In addition, SEEs may be adapted or instantiated by environment adaptors in order to produce specific environments. SEEs may also be extended or customized according to a defined process produced by
42、process developera to support one or more processes or software engineering methodologies. 1.2 Scope of the SEE Frameworks Reference Model The SEE frameworks reference model is neither an architecture nor a standard. By itself, it cannot be used to evaluate the effectiveness of an SEE for a particul
43、ar application; other criteria and measurements need to be defined for that purpose. This document provides a reference model for SEE frameworks and describes the role that the framework plays in an entire SEE. Therefore, some of the discussions may mention environments as a whole in addition to fra
44、meworks specifically. It does address tools and makes some statements about them. It does not, however, attempt to classify all types of tools or to relate the use of tools to particular methods of software development. Of particular concern in an SEE is the degree of integration among the various c
45、omponents in the environment. Clause 3.1 briefly introduces these integration issues. The RM may also be expanded to include non-service aspects of SEES, such as models, properties, and characteristics. 1.3 Aims of the Reference Model An SEE frameworks reference model is a conceptual (and functional
46、) basis for describing and comparing existing SEEs or SEE components (including framework components). The purpose of this clause is to describe and provide rationale for the main requirements and aims of this reference model. The objective is to keep these aims in mind while the reference model is
47、developed and discussed. Description and Comparison o The reference model should be suitable to describe, compare, and contrast existing and proposed envi- ronment frameworks. This requirement enables validation that the reference model has the correct scope for addressing issues con- cerned with bu
48、ilding environment frameworks. The area of SEEs is constantly evolving together with its related concepts and terminology. Much effort is often wasted through misunderstandings and misinterpreta- tions when different groups meet to discuss problems and potential solutions or new approaches to proble
49、ms. The aim of the reference model is not to determine whether one system is better than another nor to define problems or impose solutions. One of its major contributions is to provide the necessary basis for discussing SEE frameworks, i.e., to be used as a vehicle to explore environments and to identify their capabilities, strengths, and weaknesses 13 89. Standard Identification and Relationship o The reference model should provide a basis for the identification of existing and emerging SEE interface standards and their relationships. There are various groups cu
