The COMPASS realization is based on a meta-tool allowing to build CASE-tools. ... given on the support of ODP modelling and specification concepts with the ...
COMPASS: A CASE development tool for distributed systems Linda Strick, Jenia Rosa, Stephan Paschke GMD FOKUS, Hardenbergplatz 2, D-10623 Berlin Tel. +49 (30) 254 99-224, Fax +49 (30) 254 99-202 email: {strick | rosa | paschke}@fokus.gmd.d
1. Introduction This paper presents the COMPASS (Composition of Management Applications and Services) tool, which provides a software development environment supporting an object-oriented analysis, design and implementation process. The tool can be used for the different phases of the Software Life Cycle as it offers user interfaces to system analysts of the enterprise, to system architects for the construction of the systems functionality and to the application programmers for the implementation of the system. To built the tool a framework called Design Architecture has been defined which serves as a blueprint for the design and implementation of distributed systems. The Design Architecture is approached by dividing distributed systems into viewpoints standardised by the Reference Model for Open Distributed Processing (RM-ODP[3]). The Design Architecture consists of five models, each specifying a certain level of abstraction in the process of services design. The Design Architecture integrates concepts as well from object-orientation, ODP and TINA-C for guiding the design and the implementation of systems and services. The tool itself is modelled according to the prescriptions given in the design architecture and supports the concepts identified there. The COMPASS realization is based on a meta-tool allowing to build CASE-tools. Special focus is given on the support of ODP modelling and specification concepts with the defined methods. Using the tool will improve both the productivity and quality of service development as it provides a comprehensive support for all aspects relevant to the design of distributed services. Additionally the tool supports reusability as it provides a repository of previously specified services.
2. Design Methods for Distributed Applications In order to support the development of services design methods are needed to guide the users of the COMPASS tool. Therefore, the concepts used for each viewpoint of the ODP-RM are related to the service development lifecycle. Furthermore, guidelines are given to lead through the phases of service development. 2.1. Development Lifecycle The service development lifecycle describes all activities necessary to define a distributed system together with its services. It is a complete description of both, stages and steps involved during the development of a distributed system. The lifecycle covers the analysis, design, and implementation phase in the process of system development. The process is not regarded as a top-down approach, but it is more an iterative use of each of the phases from an abstract level down to a detailed specification and implementation. The following relates the service development
1
lifecycle to the Design Architecture.
Enterprise Analysis Plane
Information
Design Plane Computational Technology
Engineering
Implementation Plane
Figure 1: The Development Lifecycle
The relationships between the lifecycle phases and the viewpoints of the Design Architecture are as follows. Analysis Plane • Enterprise model: Requirements capture in terms of involved roles, actors, contracts and domains; identification of functions/services resulting from requirements capture. Design Plane • Information model: Identification and specification of information objects in terms of object–oriented concepts and state–transition diagrams. • Computational model: System decomposition into data processing units (computational objects); computational objects are defined in terms of their interfaces and externally visible behavior and they communicate via interface bindings; sets of computational objects are bound to perform functions/services as identified in the enterprise viewpoint. Implementation Plane • Engineering model: Mapping of computational objects to engineering objects; provision of the infrastructure for transparency properties and communication needs; definition of the actual distribution of objects, code generation, object creation, deployment. • Technology model: How available products and implementations can be integrated is for further study. Although the Design Architecture is implementation independent, there is a need to relate the specifications to implemented distributed processing environments at some point in time. This is done in the final phase of the development process, where engineering modelling is used to support the different transparencies. In general, there is more than a single person involved in the development of a distributed system. There are analysts, designers, and implementors. If each of them would only use the models defined in their phase, they never could check consistency of their design nor could they check if the requirements are met by the system. Therefore statements of correspondence between the viewpoint entities are required to achieve the consistency and the completeness demanded of the design, and are expressed by mapping rules. Furthermore, guidelines are given to navigate from the analysis through design to implementation. The steps taken for the development of systems are summarized as follows: • The starting point is the requirements capture to identify the needs for the distributed system. From the requirements, distributed applications can be identified. Use Cases are defined to describe the activities necessary to fulfil a distributed service for each actor. • The information model is defined using information viewpoint concepts. To identify information objects the use cases of the Enterprise Viewpoint are used. The static and dynamic information model is defined using the OMT object model and state diagram notations. • The computational model is defined using the computational model concepts. The starting point is the Enter2
• •
prise Viewpoint’s requirements and distributed applications are described in the uses cases that help to identify Computational Objects and to identify computational activities. The engineering model is developed from the computational model, using the Enterprise Viewpoint’s requirements to design the distribution of the service functions. At the end, the results are consolidated and reviewed across all viewpoints. Anomalies and inconsistencies can be resolved and further iterative design work can be actioned. This consolidation step can take place at any stage throughout the design; it is essential to perform the consolidation once when the design has been completed for all viewpoints. Enterprise Viewpoint
Describe Systems Select and Assign Functions Computational Viewpoint
Information Viewpoint
Select / Specify the first Operation Signatures and Activities
Select / Specify Information Object Classes
Select / Specify Computational Object Classes and Interface Classes Engineering Viewpoint
Select / Specify Engineering Object Classes Define Communication Consolidation
Figure 2: The Modelling Process
3. Design Architecture The following chapter gives an overview of the concepts and notations being used in each viewpoint. 3.1. Enterprise Viewpoint The enterprise viewpoint addresses the business context of a distributed system. It examines the service in relation to its (business) environment and defines purpose, scope and policies. By scanning the requirements derived from the requirements capture process, enterprise objects representing real world entities can be identified. Organisational Model
Use Cases
Actors, Roles, Contracts, Domains Policies
Actors, Activity, System Actor 1
Role 1
Actor 2
Role 2
Actor 1
Actor 1 Contract Activity 3 Domain Activity 1
focus on enterprise objects and their relations
Activity 2
focus on interactions between enterprise objects to fulfil a common task
Figure 3: Enterprise Viewpoint Modelling
3
3.2. Information Viewpoint The information model provides notations to define information objects of the distributed system, as far as these are relevant for the design of services [9]. The static information model defines the static information, the unchangStatic Object Model
Dynamic Object Model
IO Class 4
IO, Attributes, State Transition Diagrams
IO Class, Relationship Class Attributes IO Class 2
IO Class 1
IO Class 5
LO Class 3
Figure 4: Information Viewpoint Modelling
ing (invariant) structure with respect to operations’ performance or relationships among the information entities and constraints on the information entities. A dynamic information model is used to specify how information objects change over time. It captures dynamic behavior and dynamic constraints of the information objects. 3.2.1. Static Information Modelling To define the static information model the following concepts are used: object, class, generalisation (inheritance), aggregation, association and ordering. These concepts are further detailed in [11]. 3.2.2. Dynamic Information Modelling There are several notations for defining dynamic information models. In COMPASS state transition diagrams are used to specify the different state transitions performed by an Information Object. A transition is always activated by the reception of a stimulus, i.e. either a signal or a message. The rest of the operation path consists of tasks, decisions, and stimulus outputs. A task is an activity performed by the object, e.g. a comparison of values. 3.3. Computational Viewpoint In the Computational Viewpoint the distributed service is described as a collection of interacting data processing entities, called Computational Objects (CO). Distributed applications are offered by a service and are described in terms of activities that cover several COs interacting through Computational Interfaces. The service designer focuses on how a particular functionality can be provided without taking into account what kind of computing or network infrastructure is used when the service is going to be implemented [10]. Object Model
Activity Model
CO Class, Interface Type, Behaviour, Attribute, Operation
Activity, CO, Interface, Operation, Precedence Rule
CO Class
Required Interface 1
CO 1
CO Class Supported Interface 2 CO 2 Interface 3 Behaviour
Behaviour
CO 1
1. Operation a
CO 2
2. Operation b Interface Type Interface 3 Attributes Operations
CO 3 Activity
Figure 5: Computational Viewpoint Modelling
4
3.4. Engineering Viewpoint The concepts defined in the engineering viewpoint allow the specification of the mechanisms for communication, distribution and processing of the distributed applications that are spread over heterogeneous distributed systems. Engineering Object Model
Engineering Interaction Model environ. look border type uid
Engineering Configuration Model
gate database keeper
User enters uid
prompt User enters password
type passw.
auth. insert
BEO
BEO Cluster Capsule Node
Figure 6: Engineering Notations
4. Tool Architecture The COMPASS (Composition of Management Applications and Services) tool will pro vide a software development environment supporting an oo-analysis, design and implementation process. The COMPASS tool is based on a meta-tool called ObjectMaker from MarkV Systems. It allows the extension and combination of different basic object-oriented techniques. The COMPASS tool differs from other CASE tools as it supports the development of distributed applications, e.g. distributed systems, specified according to the concepts defined in the standardized ODP-RM. Methods and concepts supported by COMPASS are not developed form scratch but existing object-oriented techniques, e.g. OMT, Use Cases, are used and enhanced where necessary, for example, in the Computational Viewpoint. For each model identified in the Design Architecture the tool provides a set of grammar modules reflecting the concepts defined and a graphical user interface supporting the graphical and textual notations. The following gives an overview of the implemented notations for each viewpoint and the tool support. Specification Repository
ar amm O Gr M mar D G Gram mmar del ase el ra C d e Mo G e o s i s e l r c U nM rp ode terfa M n I l Ente formatio a tion In odel puta el ing M Com Mod neer i g n o l gy E o n h Tec
GUI
Implementation Repository
Figure 7: The Tool Architecture
5. Conclusions This paper has presented one way to define a method for developing distributed services, how to relate the ODPRM to a service development lifecycle and how to define notations to support the ODP-RM modelling process. The
5
concepts and rules to specify the enterprise model, the static information model and parts of the computational model have been implemented. The other concepts and rules will be implemented until the end of this year. In the meantime further effort will be spend in the development of the Engineering Viewpoint concepts and the tool support to offer the capability to deploy the services into the runtime system (DPE). The tool will be evaluated by a project (called Tangram) concerned with the development of a multimedia communication service, where as well the multimedia services and the services will be developed using the tool. Additionally it is intended to extend the textual behavior description into formal description techniques, e.g SDL.
6. References [1] ETSI Technical Committee - Technical Report - Network Aspects NA601-09: Service Live Cycle Reference Model, ETSI, August 1994 [2] ITU Rec. X.701 (1992) | ISO/IEC 10040, Information Technology - Open System Interconnection (OSI) Systems Management Overview [3] ISO/IEC 10746-1-4 : ITU Recommendation X.900 ff.: Basic Reference Model of Open Distributed Processing - Parts 1-4, 1995 [4] TINA-C : Report TB_MDC.018_1.0_94, “Overall Concepts and Principles of TINA”, 1994 [5] TINA-C : Report TB_MDC.012_2.0_94, “Definition of Service Architecture”, 1994 [6] TINA-C : Report TP_JS_001_0.1_95, “TINA-C Service Design Guidelines”, 1995 [7] TINA-C : Report TP_DKB_010_0.1_94, “TINA-C Service Development Methodology”, 1994 [8] TINA-C : Report TR_NM_002_1.3_95, “TINA Object Definition Language (TINA-ODL) Manual”, 1995 [9] TINA-C : Report TB_EAC.001_3.0_94, “Information Modelling Concepts”, 1994 [10] TINA-C : Report TB_NAT.002_3.1_94, “Computational Modelling Concepts”, 1994 [11] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, “Object-Oriented Modeling and Design”, Prentice Hall, 1991 [12] I. Jacobson, et al., “Object Oriented Software Engineering - A Use Case Driven Approach”, Addison-Wesley/ ACM-Press, 1992
6
