Describing a system from multiple viewpoints – using ISO/RM-ODP with OOram role modelling and UML

Lasse Bjerde, Arne-Jørgen Berre, Jon Oldevik

Numerica Taskon Ullevål Stadion, Sognsveien 75a, P.O.Box 3803, Ullevål Hageby N-0805 Oslo, Norway

SINTEF Telecom and Informatics, P.O.Box 124, Blindern, N-0314 Oslo, NORWAY

{Jon.Oldevik|Arne-Jorgen.Berre}@informatics.sintef.no

Abstract

This paper describes a methodology based on the ISO Reference Model for Open Distributed Processing (ISO RM ODP)[1-4] and the UML 1.1[5] notation. This methodology has been developed in the context of several projects concerned with methodology development: DISGIS[1][6], MAGMA[2][7] and OBOE[3][8]. ODP provides the overall framework and a foundation for describing distributed systems. UML provides a flexible notation for describing them. The methodology will be described in relation with experiences and specialisations within different application areas like geographical information systems, production-surveillance systems, finance and administrative systems.

Page 1 of 1

1.Introduction

There has been developed a number of software system development methodologies over the years. These methodologies have different foci; some are directed towards developing real-time applications while others focus on administrative systems. However, common to most is the goal of developing a software system, meaning one software system that meets certain needs or solves certain problems. The organisational trends on downsizing and virtual enterprises give the need for development of flexible, often distributed, systems supporting these new structures. The problem often arises when the needs change during or after the development, meaning that the software system must change. Traditionally this would mean a new development cycle, or at least a redesign, often involving basic restructuring of the existing systems. This is the reason for focusing on systems having a flexible architecture, meaning they are able to change more easily than would otherwise be the case.

The international standard ITU-T Rec. X.901 | ISO/IEC 10746 Information Technology – Open Distributed Processing – Reference Model (RM-ODP) [1-4] provides frameworks for specifying open, flexible and distributed systems. It defines a set of viewpoints with associated viewpoint languages defining the concepts of each viewpoint. The RM-ODP viewpoints provide a useful abstraction for reasoning about distributed systems.

UML 1.1 (Unified Modelling Language) has been adopted by the Object Management Group (OMG) as an object-modelling facility, and although the OMG request for proposals initially targeted analysis and design metamodels, both the UML metamodel and notation are accepted as part of the standard. Being a product of the three major players in the methodology industry, Booch, Rumbaugh and Jacobson, UML has succeeded in positioning itself as the market leader in the methodology field.

Chapter 2 gives an overview of the RM ODP framework, and chapter 3 describes the methodology.

2.ISO RM ODP

ISO RM-ODP defines a set of frameworks within which support for distribution, interworking, interoperability and portability can be integrated. ODP standardisation considers distributed systems spanning many organisations and technological boundaries. These typically lack any central point of control, and therefore show additional characteristics, such as heterogeneity, autonomy, evolution and mobility. In order to deal with these characteristics ODP standardisation aims to enable the building of systems with the following properties: openness, integration, flexibility, modularity, federation, manageability, provision of quality of service, security and transparency.

The RM ODP standards consists of four parts:

  • Part 1 Reference [1], which contains overview of the standards and the concepts within the standards.
  • Part 2 Foundations [2], which defines the concepts and analytic framework for the description of ODP systems, including a general framework for the assessment of conformance.
  • Part 3 Architecture [3], which defines how ODP systems are specified and the infrastructure providing transparencies.
  • Part 4 Architectural semantics [4], which complements part two and three by providing a formal interpretation of modelling concepts and viewpoint languages in terms of existing formal description techniques.

In general, an ODP system can be described in terms of related, interacting objects. The foundation of the ODP standards is defined by a set of basic modelling concepts, specification concepts and structuring concepts. The basic modelling concepts define the general object-model of ODP and include the notions of object, interface, action and interaction. The specification concepts define concepts for reasoning about specifications, including composition, decomposition, type and class, templates and roles. The structuring concepts address recurrent structures in distributed systems, e.g. groups, policies, naming, behaviour and communication.

The ODP part 3 defines an architectural framework for structuring ODP systems in terms of viewpoint specifications and distribution transparencies. An ODP system is specified in terms of a set of related but separated viewpoints. ODP defines five viewpoints; enterprise, information, computational, engineering and technology. ODP defines a viewpoint as an abstraction that provides a specification of the complete system related to a specific set of concerns. For each viewpoint there is an associated viewpoint language which defines a set of concepts for each viewpoint. Figure 1 shows the logical structure of the frameworks and concepts of ODP.

Figure 1 Structure of ODP

The foundation of ODP defines the concepts on which the viewpoints, the viewpoint languages, the conformance framework and the distribution framework with transparencies and supportive functions are based.

2.1ODP viewpoints

The enterprise viewpoint is concerned about the purpose, scope and policies of the enterprise/business related to the specified system/service. An enterprise specification of a service is a model of the service and the environment with which the service interacts. It covers the role of the service in the business, and the human user roles and business policies related to the service.

An enterprise specification is modelled in terms of one or more enterprise objects within a community of enterprise objects that represent the enterprise, and the roles in which these objects are involved. These roles can represent for example the users, owners and providersof information processed by the system. One of the key concepts of the enterprise viewpoint is that of a contract, which links various roles together in communities and expresses their mutual obligations. One particular kind of community is a federation, which is a grouping of objects answering to different authorities, i.e. representatives of different domains. A domain represents groupings of enterprise objects that are controlled by the same authority in a specific context. For example, a security domain can represent a set of objects controlled by security policies defined by the same security authority. The purpose is to allow interworking between different domains in the same or different enterprises by specifying the objectives and rules for interworking. Policies governing operation of a federation involve policies governing interworking. Thus, specification of federation may relate to and put requirements on the engineering specification. The specification of communities and federations define explicit distribution requirements for the system, in terms of distribution of various resources. The enterprise viewpoint can be described in terms of UML use case diagrams, activity diagrams and rolemodel diagrams.

The information viewpoint is concerned with the semantics of information and information processing. An information specification of an ODP system is a model of the information that it holds and of the information processing that it carries out. An information specification is modelled in terms of different related schemas; invariant, static and dynamic schemas. The invariant schema describes information that must always be true. The static schema describes assertions that must be true at a single point in time. The dynamic schema describes how information can evolve as the system operates. The information viewpoint can be described in terms of UML type/class diagrams with associated constrains described in OCL (Object Constraint Language [9].

The computational viewpoint is concerned with the interaction patterns between the components (services) of the system, described through their interfaces. A computational specification of a service is a model of the service interface seen from a client, and the potential set of other services that this service requires to have available, with the interacting services described as sources and sinks of information. The computational object model defines types of interfaces (operation, stream, signal), bindings of interfaces and legal actions for objects. The computational viewpoint can be described in terms of UML collaboration diagrams, rolemodel diagrams and interfaces. Invariants and pre- and post-conditions for invocations can be formalised in terms of OCL constraints.

The engineering viewpoint is concerned with the design of distribution-oriented aspects, i.e., the infrastructure required to support distribution. An engineering specification of an ODP system defines a networked computing infrastructure that supports the system structure defined in the computational specification and provides the distribution transparencies that it defines. The main concern is the support of interactions between computational objects. The engineering language defines concepts for supporting selective distribution transparent interactions between objects, rules for structuring communication channels between objects and rules for structuring systems for the purpose of management. The central concepts defined are channels, clusters, capsules and nodes. Channels represent communication. Nodes represent physical location and groupings of objects and processing resources and can be thought of as independently managed computing systems. Capsules represent units within a node that own storage and processing resources of the node. It can be thought of as a traditional protected process. Clusters represent objects grouped together to reduce the cost of manipulating them. The engineering viewpoint can be described in terms of UML collaboration diagrams, rolemodel diagrams and deployment diagrams.

The technology viewpoint is concerned with the provision of an underlying infrastructure. A technology specification defines how a system is structured in terms of hardware and software components, and underlying supporting infrastructure.

2.2Distribution transparencies

ODP defines a framework for defining infrastructures supporting distribution transparencies for applications. The goal is to mask complexity of distribution for applications. ODP defines the following transparencies:

  • Access transparency masks data representation and invocation mechanisms for services between systems
  • Failure transparency masks possible failure or recovery of objects to enable fault tolerance.
  • Location transparency masks the need for an application to know the location of a service in order to call it.
  • Migration transparency masks from an object the ability of a system to change the location of that object. Migration is often used to achieve load balancing and reduce latency.
  • Relocation transparency masks relocation of an interface from other interfaces bound to it.
  • Replication transparency masks the existence of several object copies for the purpose of stability, availability and performance.
  • Persistence transparency masks from an object the deactivation or reactivation of other objects.
  • Transaction transparency masks the activities amongst a configuration of objects to achieve consistency.

The definition of a transparency involves a set of requirements and a distribution transparency that satisfies it. The requirements state where the transparency is needed (i.e. which interactions it affects). Such a requirement can apply throughout the system or involving only specific interfaces. The requirement specification is solved by a set of rules for transforming the distribution requirements into a specification in which selected objects or interactions are expanded to include mechanisms that provide the required transparency.

2.3Conformance assessment

ODP defines a framework for assessment of a systems conformance to its specification. The goal is to ensure well-defined behaviour of ODP components possibly delivered from different vendors. A conformance assessment may consider the conformance between specifications and implementations and the compliance and consistency between specifications alone.

The basis for a conformance assessment is a set of conformance points that can be observed and tracked during execution. Conformance points are usually chosen from a number of potential conformance points (called reference points) identified in the ODP architecture. For example, an invariant for an information object in a banking system (e.g. the balance of a bank account must always be positive) can be related to a set of observations of the behaviour of the system at the engineering and technology viewpoint, and the consistency can be checked.

The ODP standards provide a set of frameworks and abstractions that are useful for specification of distributed systems. The following chapters will describe the methodology with RM-ODP as a supporting element. Chapter 3 will describe the methodology.

3.Methodology

The methodology consists of a development process, containing a set of activities that result in a set of specifications (deliverables). These specifications are described in terms of UML diagrams, prose text, sketches and code.

3.1Methodology overview

3.1.1Process

The methodology process encourages iterative development, by allowing the various modelling activities to provide input to each other. Four major complementary activities are defined, which are refined into finer grained activities. Figure 2 shows the high-level development activities and how they relate to RM-ODP.

Figure 2 Process activities

Business modelling covers the business requirements and goals, business organisation, business processes and enterprise distribution. It is related to the enterprise viewpoint.

Component modelling covers information, services, user interface and system architecture. It is related to the computational and information viewpoint.

Distribution modelling covers distribution infrastructure, communication mechanisms and transparencies. It is related to the engineering viewpoint.

The implementation activity covers implementation, system integration and testing. It is related to the technology viewpoint.

3.1.2Notation

UML 1.1 notation is used for modelling in the various activities. In addition, rolemodels and synthesis is added to enhance the analysis phase and traceability (assuming synthesis, role and rolemodel semantics similar to that defined in [10]) and prose text is used to add semantics to these models. OCL (Object Constraint Language) specifications are used to formalise semantics of objects and interfaces.

UML use case diagrams are used to capture business requirements. UML activity diagrams are used to capture business processes. UML collaboration diagrams and textual descriptions are used to capture explicit distribution in the enterprise.

UML collaboration diagrams are used to capture the configuration of system components (computational objects). Collaboration diagrams are interpreted as rolemodels, assuming role and rolemodel semantics similar to that defined in [10].

UML sequence diagrams are used to capture object interactions between computational objects.

UML type/class diagrams are used to capture information objects. OCL specifications are used to formalise constraints.

UML deployment diagrams are used to capture configuration of system hardware and software components.

UML Stereotyping may be used on several diagram types in order to capture semantics of e.g. distribution aspects. UML stereotyped classes can be used to describe rolemodels in terms of roles and interfaces.

OOram synthesis may be used to link diagrams in different viewpoints to ensure traceability throughout the model.

3.2Modelling process

3.2.1Business modelling

The business modelling concerns the business work processes and identification of goals and requirements. The results of the business modelling represent the ODP enterprise viewpoint. This activity is separated in four sub activities.

  • The analysis and requirements modelling concerns identification goals and expectations, areas of concern and identification of requirements. The requirements may be grouped into functional requirements, non-functional requirements and external constraints.
  • The organisation modelling concerns the description of organisational structures, roles and responsibilities.
  • The business process modelling concerns identification and analysis of activities and business processes. This also includes identification of roles and their responsibilities.
  • The enterprise distribution modelling concerns the distribution of the enterprise, for instance distribution of installations, workspaces, general resources, roles and so on.

Figure 3 shows the breakdown of the business modelling activities.

Figure 3 Business modelling

The business modelling activities will be further described below:

Business analysis and requirements modelling

During the business analysis, the business is analysed and business needs is identified. How to improve today’s situation and be competitive should be main discussions. Business analysis is an activity where creativity is important. New ways of accomplishing the business goals should be considered. Identification and clarification of goals are essential to understand and analyse the business. The goals should be the driving forces for every activity performed in the enterprise.

Requirements modelling results in specifications documenting the business requirements. The main tasks for achieving these specifications are to answer questions like: What are the customers needs? What can be improved from today’s situation? What shall the system do? The resulting specifications are:

  • Domain concept specifications describe concepts specific or important with the system domain.
  • Areas of concern (AoC) specifications describe the business problem the system should solve. They also describe the context of the problem. UML use case diagrams and rolemodels together with prose text can be used to describe AoC specifications.
  • Functional requirementspecifications describe the required functionality of the system. UML use case diagrams and rolemodels together with prose text can be used to describe functional requirements
  • Non-functional requirement specifications are the collection of system requirements that are not directly related to what the system should do, e.g. reliability, availability, security and performance requirements. Prose text can be used to describe non-functional requirements.
  • External constraint specifications areconditions, decisions, rules etc. that may have impact on the system development. Prose text can be used to describe external constraints.

Organisational modelling