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.
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.
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
1 Distributed Geographical Information Systems, Methods, Tools and Frameworks, ESPRIT Project No. 22.084
2 Modular architecture, reuse, object-oriented methodology and defined processes for development of softwareproducts.
3
Open Business Object Environment, ESPRIT Project No. 23.233
Page 1 of 10

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.
Conformance framework
Viewpoint languages enterprise information computational
Viewpoints object, action, interface, interaction composition, role, type, class engineering technology groups, policies, naming, behaviour
Basic modelling concepts
Specification concepts
Structuring concepts
ODP Foundation
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.
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 providers of 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 d omain 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
Page 2 of 10

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.
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
Page 3 of 10

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.
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.
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.1.1
Process
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.
Enterprise viewpoint
Business modelling
Component modelling
Computational viewpoint
Information viewpoint
Engineering viewpoint
Distribution modelling
Implementation
Technology viewpoint iterative process
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.
Page 4 of 10

3.1.2
Notation
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.2.1
Business 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, nonfunctional 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.
Business modelling Enterprise viewpoint
Analysis and
Requirements modelling
Organisation modelling
Business process modelling
Enterprise distribution modelling
Business
models
Component modelling
Distribution modelling
Figure 3 Business modelling
The business modelling activities will be further described below: iterative process
Page 5 of 10

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 requirement specifications 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 are conditions, decisions, rules etc. that may have impact on the system development. Prose text can be used to describe external constraints.
Organisational modelling
The organisation modelling identifies the organisational roles and their associated responsibilities. The result is a specification of an organisational chart described by sketches and prose text.
Business process modelling
The business process modelling identifies business processes and activities within the defined areas of concern.
The concerns are described in detail in response to the requirements and goals defined. During the business process analysis, business objects (high-level information objects) are identified. The resulting specifications are:

Business process specifications that describe the detailed processes with the areas of concern. The starting point is the requirements and goals from the requirement analysis. UML activity diagrams (or UML sequence diagrams) can be used to describe the business processes.

Collaboration structure specifications that describe the collaboration of business roles. This can be identified by associating business roles to activities in the business processes. The result can be specified in a set of collaboration rolemodels. UML collaboration diagrams can be used to describe these collaborations.

Business object specifications that describe high-level information objects discovered in the business processes. UML type/class diagrams can be used to describe these objects.
Enterprise distribution modelling
The distribution modelling identifies distribution aspects of the enterprise. The goal is to identify different communities within the enterprise and group enterprise resources within these communities. Enterprise resources like business roles , business activities and business objects are thus associated with the community representing the enterprise. Different enterprises can thus be modelled in terms of communities.
Federations represent a particular kind of community that defines a grouping of domains , i.e. the groups involved are answering to different authorities. Domains concerned in a federation may be administrative domains (e.g. security domain) and technology domains (software or hardware policy domain) . Federation of administrative domains relates to interworking between domains in order to provide sharing, integration or partitioning of resources and applications across different systems and locations in response to user needs.
Federation of technology domains is concerned with integration of different system architectures and of systems with different resources and performance. The two kinds of federation often coincide, since differences in administration can lead to differences in choice of technology. The resulting specifications of the enterprise distribution modelling are:

Specification of communities and grouping of enterprise resources into communities.
Page 6 of 10


Specification of domains and federation of domains. The result can be specified in a set of collaboration rolemodels. UML collaboration diagrams, class diagrams and prose text can be used to describe the enterprise distribution.
3.2.2
Component modelling
The component modelling concerns design of the logical system architecture and design of user interface, services, and information models. Prototypes are also part of the component modelling. The component modelling activity is separated in five underlying modelling activities:

The information modelling concerns identifying, classifying and designing the information objects.

The service modelling concerns description and design of services.

The user interface (UI) modelling concerns identification of tools and design of their user interfaces.
Prototyping is also part of the UI modelling.

The system architecture modelling concerns design of the logical system architecture. This design shows how the different kinds of components are tied together. The tires of the system are also identified.
A tool provides a set of services for a user though a UI. For example, if the tool is a word processor the spellchecker may be one service provided. The service is provided by a set of collaborating (computational) objects. Information objects represent the semantics flowing between services and between tools and services.
An English dictionary may be an information object that is used by the spellchecker. The component modelling results in specifications that correspond to RM-ODP information and computational viewpoint.
Figure 4 shows the breakdown of the component modelling activity.
Component modelling
Service modelling
User interface modelling
Computational viewpoint
System architecture modelling iterative process
Information modelling
Information viewpoint
Figure 4 Component modelling
The component modelling activities will be further described below:
User interface modelling
The UI modelling concerns identification of tools, UI design and prototyping. As oppose to service components, which offer a set of services, tools are users of services. Tools also provide user access to the services, which is the UI. The resulting specifications of this activity are:

Specification of tools . The identification of tools is based on the use cases from the business analysis. These can be grouped into on or more logical tools. Prose text, sketches and screen shots can be used to describe these.

UI design , which includes identifying graphical human interaction components and user interface design.
The identified tools and the business use cases are starting points for the design. This activity should be performed in close co-operation with the end users. GUI (graphical user interface) literature and GUI standards should be consulted. GUI components, screen shots and functionality descriptions should be used for documentation.
Service modelling
The service modelling identifies the tasks to be automated and describes the services required to automate these tasks. The use case models and business process models are used as a starting point when identifying these tasks and services. The resulting specifications are:

Specification of the tasks that shall be automated . These are the tasks the software system should support. A convenient way to identify the relevant tasks is to iterate the use cases and business process. The resulting tasklist can be described in a textual table.

Specification of required services and the service components that offer these services.
A service component fulfils the role of being responsible for a particular task or a set of tasks. It can be described in terms of its collaborations , interactions and interfaces.
The collaborations describe how the component (in the context
Page 7 of 10

of its role) co-operates with other components. The interfaces describe the protocols related to the component and the interactions describe a component’s interactions with its collaborators. The collaborations can be described in roles and interfaces. (They can also be described in terms of UML collaboration diagrams.) The interactions can be described in terms of UML sequence diagrams. The interfaces are described as interfaces if available in the tool (as they are in OOram), or in terms of UML classes stereotyped as interfaces or formalised in terms of IDL. OCL can be used to formalise the operations defined for a component, e.g. by adding pre- or post-conditions.
System architecture modelling
The system architecture modelling concerns the identification of the logical system architecture. The logical system architecture shows how the components are tied together and how they inter-operate. The tires of the system are also identified. The decision of what logical system architecture to use in a particular system is mainly based on the non-functional requirements and external constraints. The resulting specification of this activity is:

Logical system architecture , which can be described in graphical diagrams. UML does not support this kind of architecture modelling very well.
Information modelling
The information modelling results is a description of the information processed in the system and information passed between components in the system. Information is described in terms of information objects. These can be discovered by looking at the information-flow in the business processes. High-level information objects that have been discovered during business process analysis and can be detailed and formalised here. By analysing the business processes and the more detailed interactions identified during service modelling, the information objects should become apparent. The resulting specifications of this activity are:

A set of object models that describe the structure and properties of information objects. These models should be detailed with properties (associations and attributes) and constraints (invariants). Information objects may be behavioural objects in the sense that they will actively participate in interactions. In that case, the object will be discovered as a participant in a service interaction specification. These information objects will also have associated operations. UML type/class diagrams can be used to model information objects. OCL specifications can be used to formalise semantics of the information objects. Rolemodel diagrams can be used to describe metamodel extensions for the purpose of capturing domain concepts.

Dynamic specifications that describe the dynamic nature of the information objects. UML state diagrams can be used to model this.
3.2.3
Distribution modelling
The distribution modelling concerns identification of the infrastructure required to support functional distribution of the system. Distribution modelling results in specifications corresponding to the RM-ODP engineering viewpoint. This activity is divided into two underlying modelling activities.

The distribution functional modelling concerns identifying the functionality required to manage physical distribution, communication, processing and storage.

The distribution configuration modelling concerns identifying and describing the configuration and management of objects in order to support required distribution functionality.
Figure 5 shows the breakdown of the distribution modelling activity.
Distribution modelling Engineering viewpoint
Distribution functional modelling
Distribution configuration modelling iterative process
Figure 5 Distribution modelling
The distribution modelling activities will be further described below:
Distribution functional modelling
The distribution functional modelling concerns the functional requirements related to physical distribution.
These requirements are identified through the required transparencies for objects in the system. For example, if
Page 8 of 10

transparent replication is required for a set of objects, this should be provided by replication functions. An identified distribution requirement should be discussed with regard to its importance, impact in cost and impact in performance. How are the requirements identified? Some requirements can be derived from the distribution specification and requirements from the business models. Other requirements are driven by the configuration of computational objects into different clusters and nodes. Some requirements can be derived from performance requirements to the system. The resulting specification of this activity is:

A specification of the functional requirements for distribution , which can be described in terms of prose text.
Distribution configuration modelling
The distribution configuration modelling concerns the description of configuration of engineering objects, activities that occur within these objects and the interactions of those objects. Basic engineering objects are computational objects (from service and UI modelling). These objects can be grouped into clusters (for performance and management reasons) which are located in a capsule (a process). These are again grouped into nodes which represent individual managed computing systems (e.g. a server). Communication between basic engineering clusters is defined in terms of channels. This activity should describe the solution chosen for solving distribution in terms of configuration of services, functions and engineering objects. The resulting specifications of this activity are:

Specification of the grouping of objects into engineering concepts and the communication required by these objects. UML collaboration diagrams, rolemodel diagrams, deployment diagrams, prose text and additional sketches can be used to capture this.
3.2.4
Implementation
The implementation activity concerns the actual implementation. This includes mapping to the infrastructure, final implementation of the component specifications, mapping to databases, integration and testing. The implementation activity corresponds to RM-ODP technology viewpoint.
The mapping to underlying infrastructures like CORBA, DCOM/ActiveX, Java RMI and others should handle the physical distribution designed during distribution modelling. This mapping require that the infrastructure implementation (e.g. a particular CORBA implementation) support the required functionality for distribution.
This will not always be the case, however. For example, mechanisms supporting replication, migration or transaction transparencies may not be supported by the chosen technology.
The implementation activity will not be elaborated further here.
This paper has described a methodology based on RM-ODP concepts and UML 1.1 notation. The methodology is a result of methodology development work in several projects; DISGIS[6], MAGMA[7] and OBOE[8]. The results presented here represent only a subset of the results achieved in those projects, which covers broader aspects and more detail. The basis applied in these projects is among other things: RM-ODP concepts, OOram
[10] concepts, UML Objectory process ( http://www.rational.com/products/o_process/ ) , Microsoft Solution
Framework ( http ://www.microsoft.com/msf ), OPEN Modelling Language (OML)[11] and others.
RM-ODP provides a set of frameworks that are useful for reasoning about distributed systems. In particular, the viewpoint separation and the distribution transparencies provide a toolset for creating abstractions and specifications that help us understand and develop distributed systems. The UML notation provides a unifying language that can be used across all RM-ODP viewpoints, and thereby adding value to the standard. Applying
RM-ODP concepts and UML notation into a methodology framework, provides a powerful and flexible development environment. Depending on different problem domains and complexities, the concepts of RM-ODP will apply in various degrees. So also for the usage of UML notation, which provides a flexible notation that can be used for virtually anything, thus implying the importance of rules for usage of the different notations, which notational elements to use and the precise semantics of those elements. A number of books are being published these days that describe UML in different contexts [12-16].
The work presented here will be further refined and developed in several projects with the goal of achieving a better understanding of the various aspects of system development, with a focus on distributed information systems and components. RM-ODP will provide the basis for reasoning about system distribution and UML will provide the notation for describing these systems from different viewpoints. A more detailed presentation of the methodology can be found in [17].
Page 9 of 10

[5]
[6]
[7]
[8]
[9]
[1]
[2]
[3]
[4]
ISO/IEC, “ISO/IEC 10746-1 Information technology - Basic reference model of Open Distributed
Processing - Part 1: Overview,” ISO ITU-T X.901 - ISO/IEC DIS 10746-1, 1996.
ISO/IEC, “ISO/IEC 10746-2 Information technology - Open Distributed Processing - Reference
Model:Foundations,” , 1996.
ISO/IEC, “ISO/IEC 10746-3 Information technology - Open Distributed Processing - Reference Model:
Architecture,” , 1996.
ISO/IEC, “ISO/IEC DIS 10746-4 Information technology - Open Distributed Processing - Part 3:
Architectural semantics,” , 1996.
OMG/UML, “UML Notation,” . http://www.rational.com/uml/html/notation, 1997.
DISGIS, “DISGIS Methodology - Deliverable MD2.3,” , DISGIS project report MD 2.3, June 1997.
MAGMA, “Magma Software engineering handbook,” SINTEF, draft 1997.
OBOE, “Business Object Methodology Handbook,” SINTEF 1998.
OMG/UML, “OCL - Object Constraint Language Specification,” , version 1.1 ed. http://www.rational.com/uml/html/ocl/, 1997.
[10] T. Reenskaug, P. Wold, and O. A. Lehne, Working with Objects - The OOram Software Engineering
Method : Manning Publications, ISBN 1-884777-10-4, 1996.
[11] D.Firesmith, B. Henderson-Sellers, and I.Graham, OPEN Modelling Language (OML) Reference
Manual : SIGS books, ISBN 1-884842-75-5, 1997.
[12] P.-A. Muller, Instant UML : Wrox Press Ltd, ISBN 1-861000-87-1, 1997.
[13] M. Fowler and K. Scott, UML destilled - applying the standard object modelling language" : Addison
Wesley, ISBN 0-201-32563, 1997.
[14] P. Harmon and M. Watson, Understanding UML - the developers guide : Morgan Kaufmann Publishers
Inc, ISBN 1-55860-465-0, 1998.
[15] J. J. Odell, Advanced Object-Oriented Analysis and Design Using UML : SIGS Reference Library,
Cambridge University Press, ISBN 0-521064819-X, 1998.
[16] B. P. Douglass, Real-Time UML - developing efficient objects for embedded systems : Addson Wesley,
ISBN 0-201-32579-9, 1998.
[17] Jon Oldevik, Arne J. Berre “UML Based methodology for distributed systems”, EDOC’98, San Diego,
November 2-5, 1998
Page 10 of 10