Deliverable D1.1.2: Analysis of UML

Deliverable D1.1.
2: Analysis of UML
REFERENCE DATE OF ISSUE ACCESS RIGHTS STATUS EDITOR AUTHOR[S]
: : : : : :
AMIDST/WP1/N006/V04 24 November1999 public final C. R. Guareis de Farias C. R. Guareis de Farias, N. Diakov, R. Poortinga
SYNOPSIS
This document presents an analysis of the Unified Modelling Language (UML). It includes an introduction to the different kinds of UML diagrams, an overview of the unified software development methodology, a survey concerning the availability of tools that support UML and an example of the use of UML.
ANALYSIS OF UML AND RELATED LANGUAGES
Document History
DATE VERSION MODIFICATION
30/06/1999 06/08/1999 20/10/1999 24/11/1999
01 02 03 04
Initial draft Modifications in the example, analysis and conclusion sessions. Modifications in sections 2, 3 and 4 due to comments received from Lus Ferreira Pires. Modifications due to comments received from Klaas van den Berg.
Abstract
This document presents an analysis of the Unified Modelling Language (UML). It includes an introduction to the different kinds of UML diagrams, an overview of the unified software development methodology, a survey concerning the availability of tools that support UML and an example of the use of UML.
ii
AMIDST/WP1/N006
Table of Contents
1. INTRODUCTION............................................................................................................... 1 2. UNIFIED MODELING LANGUAGE .............................................................................. 2 2.1 STRUCTURAL DIAGRAMS ............................................................................................... 2 2.1.1 Class diagram...................................................................................................... 3 2.1.2 Component diagram............................................................................................ 4 2.1.3 Deployment diagram........................................................................................... 4 2.2 BEHAVIOURAL DIAGRAMS ............................................................................................. 5 2.2.1 Use case diagram ................................................................................................ 6 2.2.2 Statechart diagram .............................................................................................. 6 2.2.3 Activity diagram ................................................................................................. 8 2.2.4 Sequence diagram ............................................................................................... 9 2.2.5 Collaboration diagram ...................................................................................... 10 2.3 UML 1.3 AND BEYOND................................................................................................ 11 3. THE UNIFIED SOFTWARE DEVELOPMENT PROCESS....................................... 13 3.1 OVERVIEW ................................................................................................................... 13 3.2 CONTENT ..................................................................................................................... 16 3.2.1 Workers............................................................................................................. 16 3.2.2 Activities........................................................................................................... 17 3.2.3 Artefacts............................................................................................................ 17 3.2.4 Workflows ........................................................................................................ 17 3.3 CORE WORKFLOWS ...................................................................................................... 18 3.3.1 Requirements .................................................................................................... 18 3.3.2 Analysis ............................................................................................................ 18 3.3.3 Design ............................................................................................................... 19 3.3.4 Implementation ................................................................................................. 20 3.3.5 Test.................................................................................................................... 21 3.4 TIMELINE ..................................................................................................................... 21 3.4.1 Inception phase ................................................................................................. 22 3.4.2 Lifecycle objectives milestone ......................................................................... 23 3.4.3 Elaboration phase.............................................................................................. 23 3.4.4 Lifecycle architecture milestone....................................................................... 24 3.4.5 Construction phase............................................................................................ 24 3.4.6 Initial operational capability milestone ............................................................ 24 3.4.7 Transition phase................................................................................................ 25 3.4.8 Product release milestone ................................................................................. 25 4. UML DESIGN AND ANALYSIS TOOLS ..................................................................... 26 4.1 CRITERIA ..................................................................................................................... 26 4.1.1 Functionality ..................................................................................................... 26 4.1.2 Qualitative aspects ............................................................................................ 30 4.2 RATIONAL ROSE 98 SR1 ............................................................................................. 31 4.2.1 Functionality ..................................................................................................... 31 4.2.2 Qualitative aspects ............................................................................................ 32 4.3 SELECT SOFTWARE ................................................................................................... 33 4.3.1 Functionality ..................................................................................................... 33 4.3.2 Qualitative aspects ............................................................................................ 35
iii
4.4 SYSTEM ARCHITECT/2001........................................................................................... 35 4.4.1 Functionality ..................................................................................................... 35 4.4.2 Qualitative aspects ............................................................................................ 37 4.5 TOGETHER J................................................................................................................. 37 4.5.1 Functionality ..................................................................................................... 37 4.5.2 Qualitative aspects ............................................................................................ 39 4.6 STRUCTURE BUILDER .................................................................................................. 39 4.6.1 Functionality ..................................................................................................... 39 4.6.2 Qualitative aspect.............................................................................................. 41 5. APPLYING UML A CASE STUDY ............................................................................ 42 5.1 PROBLEM DESCRIPTION ............................................................................................... 42 5.2 PROBLEM MODELLING ................................................................................................. 42 5.2.1 Requirements capturing .................................................................................... 42 5.2.2 Analysis ............................................................................................................ 44 6. ANALYSIS OF UML ....................................................................................................... 52 7. CONCLUSION ................................................................................................................. 55 REFERENCES....................................................................................................................... 56 ABBREVIATIONS AND ACRONYMS .............................................................................. 58 APPENDIX A: ELECTRONIC EXAMINING SYSTEM ................................................. 59 A1. USE CASE DIAGRAM ...................................................................................................... 59 A2. CONCEPTUAL DIAGRAM ............................................................................................... 63 A3. USE CASE REALISATION-ANALYSIS: ACCESS STUDENT PROFILE ............................... 64 A4. USE CASE REALISATION-ANALYSIS: ACCESS TEST REPOSITORY ............................... 70 A5. USE CASE REALISATION-ANALYSIS: ASSIGN TEST ..................................................... 72 A6. USE CASE REALISATION-ANALYSIS: CONSULT PROFILE ............................................. 73 A7. USE CASE REALISATION-ANALYSIS: DO TEST ............................................................ 78 A8. USE CASE REALISATION-ANALYSIS: EVALUATE TEST ................................................ 80 A9. USE CASE REALISATION-ANALYSIS: REGISTER TEST.................................................. 84
iv
AMIDST/WP1/N006
1. Introduction
The Unified Modelling Language (UML) is a standard modelling language for the specification, visualisation, construction and documentation of software systems artefacts [19]. UML has been standardised by the UML Partners Consortium, led by Rational Software Corporation, under the auspices of the Object Management Group (OMG). Models are tools used in the representation of a problem under investigation to abstract from unnecessary details and to provide a better understanding of the problem as a whole. A modelling language includes model elements, notation and guidelines. Model elements are the fundamental modelling concepts and their semantics, while a notation is a graphical representation of the model elements. Guidelines are a set of idioms of how to use the model elements. In the late 80s and early 90s the object-oriented community witnessed the appearance of a large number of design languages. Many of these languages were similar but still some differences could be found. Besides, none of these languages appeared to be complete enough. By the mid 90s, these languages evolved and began to incorporate each others techniques. So, few prominent design languages emerged. The development of UML started in 1994 when G. Booch and J. Rumbaugh joined forces to merge the Booch Method [1] and Object Modelling Technique (OMT) [21]. One year later I. Jacobson joined the unification efforts by merging the Object-Oriented Software Engineering (OOSE) [8] method with the other two. The primary goal of UML was to unify the different methodologies and to integrate the best practices present in industry. The design of UML also aimed at: (1) providing users with a ready-to-use and expressive visual modelling language; (2) providing extensibility and specialisation mechanisms to extend the core concepts; (3) being independent of particular programming languages and development processes; (4) providing a formal basis for understanding the modelling language; and finally, (5) bringing some stability to the objectoriented (OO) tools marketplace, encouraging its growth. The main reasons why UML should be considered as the AMIDST design language are the following: (1) we need some standard and well-known notation to document and exchange ideas and concepts; (2) UML incorporates several useful techniques (see Section 2); (3) UML has been widely accepted in the industry, and; (4) a lot of tools are currently available to UML (see Section 3). The remaining of this document is structured as follows. Section 2 outlines the different artefacts present in UML. Section 3 gives an overview of the unified software development process. Section 4 presents a survey on a number of UML related tools. Section 5 illustrates the use of UML in the analysis of an examining system. Section 6 discusses the pros and cons of UML. Finally, Section 7 draws some conclusions.
2. Unified Modeling Language

UML is the OMGs standard modelling language. The OMG UML 1.1 specification consists of the following documents: UML Proposal to OMG [16], which describes the motivation for UML standardisation and the structure of UML documentation. UML Summary [18], which describes the motivation for UML definition, the goals and scope of UML and its development history. UML Semantics [17], which defines the semantics of UML, i.e., defines the meaning or interpretation of the UML constructs. The UML semantics has been defined in this document using UML itself (UML class diagrams) and the Object Constraint Language (OCL). UML Notation Guide [15], which defines the UML notation and provides some examples. UML Extension for Objectory Process for Software Engineering [14], which defines UML extensions for the Objectory Process (now known as the Unified Software Development Process). UML Extension for Business Modelling [13], which defines UML extensions for business modelling. Object Constraint Language Specification [11], which describes OCL syntax, semantics and grammar. OA&D CORBAfacility [10], which provides CORBA IDL specifications for UMLconsistent tool interoperability.
UML basically provides a collection of diagrams used to model a system under different and often complementary perspectives. A diagram is a graphical presentation of a set of elements, frequently represented as a connected graph of vertices (things or abstractions) and arcs (relationships connecting things) [2]. The different UML diagrams can be roughly grouped into two categories, viz., structural and behavioural diagrams.
2.1 Structural diagrams

Structural diagrams are used to visualise, specify, construct and document the static aspects of a system. UML provides four types of structural diagrams, viz., class diagram, object diagram, component diagram and deployment diagram. Since an object diagram is an instance of a class diagram we do not consider object diagrams in this document. In the sequel the most important concepts of the remaining diagrams are presented.
AMIDST/WP1/N006
2.1.1 Class diagram Due to the large number of modelling concepts, the class diagram is considered the richest type of diagram in UML. In this document, we only introduce some basic concepts of UML class diagrams. Further details can be found in, for example, [2, 4]. A class diagram describes the types of objects (object classes, data types and interfaces) and the different kinds of static relationships that connect them. An object diagram describes an instance of a class diagram. An object class is a description of a set of objects that share the same attributes, operations, methods, relationships and semantics. Attributes describe a range of values that an instance of a class may hold, while operations are the services that an instance of a class may be requested to perform. A method is an implementation of an operation. There are two main kinds of static relationships, viz. association and generalisation. Associations represent static relationships between instances of classes. Associations are usually binary, although ternary or even higher order associations are also possible. A binary association is an association between two classes, including the possibility of a self association, i.e., an association between a class and itself. The ends of an association, the so-called association end, contain useful information related to this association. For example, an association end may contain one role, which describes the role played by the class attached to this end with respect to this association. An association end also contains the multiplicity of the association, which places constraints on the number of objects that may participate in a given association. The multiplicity of an association is a subset of the natural numbers. Two special kinds of associations are aggregation and composition. An aggregation association is a whole-part relationship between an aggregate class, called whole, and a component part. A composition is a special kind of aggregation, in which the part component may belong to only one role and has the same lifetime as the whole, i.e., the part component live and die with the whole. An association class is a modelling concept that combines an association with class properties (or the other way around), such that an association class can have attributes, operations and other features. The generalisation, or inheritance, relationship is the taxonomic relationship between a more general class, called superclass, and a more specific one, called subclass. The subclass is completely consistent with the superclass, i.e., the subclass has the same attributes and operations as the superclass, and adds additional information to it, possibly additional attributes and/or operations. Figure 2.1 depicts a generic class diagram. This figure shows four object classes and three different kinds of relationships between these classes, viz. association (between classes A and B), generalisation (between classes A and C) and aggregation (between classes B and D). The association between classes A and B two roles defines two roles, Role A and Role B. Furthermore, it defines that one instance of class A may be related with zero or more instance of class B. The generalisation between classes A and C defines that class A is the generic class, while class C is the specific class. The aggregation between classes B and D defines that class B is the whole, while class D is the part. In Figure 2.1, the annotations (gray arrows) are not part of the notation. They have been used just for explanatory purposes. This explanatory notation is used throughout section 2 of this document.
Association
Multiplicity (zero or more objects)
Class A
1 Role A
* Role B
Class B
1 Multiplicity (one object) Aggregation
Role Generalis ation Class 0..1
Multiplicity (one or zero objects)
Class C
Class D
Figure 2.1. Class diagram. 2.1.2 Component diagram A component diagram is a graph of components connected by dependency relationships. This diagram is used to model the static implementation view of a system and it captures dependencies among different kinds of components, such as source code, binary code and executable components. Interfaces and calling dependencies among components can also be captured using a component diagram. A calling dependency occurs when a component uses a given interface. In such case, dependency arrows from components to the interface on other component must be employed. Figure 2.2 shows a generic component diagram. This figure illustrates a diagram with three components. According to this diagram, Components 2 and 3 make use of Component 1 through Interface 1 (calling dependency).
Interface 1 Component 1
Interface
Dependency
Component
Component 2
Component 3
Figure 2.2. Component diagram. 2.1.3 Deployment diagram A deployment diagram consists of a graph of nodes connected by communication associations. A communication association represents a physical or indirect connection between nodes, such as an Ethernet connection, a serial line or a satellite link. A deployment diagram is used to capture the configuration of run-time processing elements and the components, processes and objects within these elements.
AMIDST/WP1/N006
A node is a run-time physical object that represents a processing resource, such as computing devices, human resources and mechanical processing resources. Nodes may contain component instances, which may contain objects themselves. A component within a node means that this component lives or runs on the node, while an object within a component means that this object belongs to the component. A component can be connected to other components using dependency arrows, just like in a component diagram. Stereotypes are an extensibility mechanism of UML that allows one to create new and specific kinds of modelling elements derived from existing ones. Two types of dependency stereotypes are often used in a deployment diagram, viz., supports and becomes. The former is used to show that a certain component may run on the node, while the latter is used to describe a component migrating from one node to another node or an object migrating from one component to another component. Figure 2.3 depicts a generic deployment diagram. This figure shows a diagram with two connected nodes (Node 1 and Node 2), each one containing two components. The unnamed component in Node 2 contains 2 objects. In Node 1 there is a dependency between Component 1 and Component 2, while in Node 2 there is also a dependency between the unnamed component and Component 2. Additionally, there is an internode calling dependency between the unnamed component (Node 2) and Component 1 (Node 2) through Interface 1. Figure 2.3 also illustrates the migration of Component 2 from Node 1 to Node 2.
Node 1 Component 1
Interface 1
Interface
Component 2
Dependency
Node
<<becomes>>
Component migration
Node 2 Object 1 Component 2 Object 2
Physical Connection
Component
Object
Figure 2.3. Deployment diagram.
2.2 Behavioural diagrams

Behavioural diagrams are used to visualise, specify, construct and document the dynamic aspects of a system. UML provides five types of behavioural diagrams, viz., use case diagram,
statechart diagram, activity diagram, sequence diagram and collaboration diagram. In the sequel the most important concepts of these diagrams are presented. 2.2.1 Use case diagram A use case is a unit of functionality representing sequences of actions that the system being developed perform to produce an observable result to one or more outside interactors, called actors. A use case diagram consists of a set of actors, use cases and their relationships. An actor is a role that a user plays with respect to the system. A single actor can perform many use cases, while a use case may have several actors performing it. Actors do not need to be humans; actors can also be external systems, either software or hardware, which need some information from the system being developed. An actor relates to a use case to perform it by means of a communication association. Optionally you can define the multiplicity between instances of an actor and instances of use cases in this association. Use cases can relate to each other according to three different types of relationship, viz. generalisation, extend and include. The generalisation relationship specifies that one use case is a specialisation of another. The extend relationship defines that one use case incorporates the behaviour of another use case, extending this behaviour to meet specific conditions, while an include relationship defines that the behaviour of one use case is included in the behaviour of another use case. Figure 2.4 presents a generic use case diagram. This diagram contains one actor and four use cases. Use case 1 is performed by Actor 1. This relationship is represented using the communication association between Actor 1 and Use case 1. Use case 4 is a specialisation of Use case 3 (generalisation relationship), which behaviour is included by Use case 1 (include relationship). Use case 2 incorporates and extends the behaviour of Use case 1 (extend relationship).
Actor Multiplicity Use case Extend relationship
<<extends>> Use case 1 Use case 2
Actor 1
Communication association
Generalis ation relationship
<<includes>>
Include relationship
Use case 4
Use case 3
Figure 2.4. Use case diagram. 2.2.2 Statechart diagram A statechart diagram is used to describe the behaviour of a system through the representation of a set of states and transitions connecting these states. Such a diagram represents all the
AMIDST/WP1/N006
possible states of a system and how these states changes in response to received stimuli. A statechart diagram can be directly mapped into a state machine, which can be attached to a class or a method. UML statechart diagrams are strongly based on Harels statecharts [6]. A state is a condition in the life of an object during which this object satisfies some condition, performs some action or waits for some event. A state may be decomposed into either concurrent substates or mutually exclusive disjoint substates. In such cases, the state is called composite state. Two particular states of a statechart diagram are the so-called initial and final states. The initial state indicates the default starting point for the state machine, while the final state indicates that the execution of the state machine has been completed. An activity may be associated with a state. This activity can be expressed as a composite state machine or represented by a sequence of actions. The execution of an action is atomic and non-interruptible, while the execution of a sequence of action may be interrupted by some event. There are two special kinds of actions that are executed whenever entering or leaving the state, viz. entry and exit actions, respectively. An event is an occurrence that may trigger a state transition. There may be different kinds of events, such as a designated condition becoming true, the receipt of an explicit signal from another object, the receipt of a call for an operation and the passage of a designated period of time after a designated event. A transition is a relationship between two states indicating a change in the state of an object, from the source to the target state, and the execution of a certain action when a specified event occurs if some specific conditions are met. These conditions, also called guard conditions, are a logical expression that evaluates to true or false. A transition is said to be a complex transition when multiple source states or multiple target states or both are involved in a single transition. A transition to the boundary of a composite state is equivalent to a transition to its initial state (sequential substate) or to the initial state of each one of its concurrent substates. A transition from a composite state is equivalent to a transition from each of the states within the state, at any depth. Transitions to substates of a composite state or from substates to states outside the composite state are also allowed. An internal transition is a transition in which the occurrence of an event that does not cause a change of state and consequently it does not cause the triggering of the entry and exit actions. An internal transition is not the same as a self-transition, which is a transition from the state to the state itself, which triggers the entry and exit actions of the state. Figure 2.5 illustrates a generic statechart diagram. This diagram consists of a composite state, State A, which is refined into an initial and final states and two sequential substates, viz., State B and State C. State B provides execution of the activity Activity1. State C represents a composite state that consists of two concurrent substates, each one containing an initial and final states and an additional substate State D or State E. The transition from State B to the boundary of State C, actually represents a transition to each of the initial states of State C. This transition is triggered by the occurrence of event Event1, provided that the condition Guard1 is true, and cause Action1 to happen.
Composite state
Sequential substate
State A
Concurrent substate
State C State B do / Activity1

Initial state Activity Composite state Transition
Event1 [Guard1] /Action1
State D
State E
Final state
Figure 2.5. Statechart diagram. 2.2.3 Activity diagram An activity diagram is a variation of a statechart diagram in which the states correspond to activities representing the execution of operations and the transitions are triggered by the completion of the operations. This diagram can be attached to either a class or a method or a use case. An activity is a state with an internal action representing a step in the execution of a procedure or algorithm and at least one outgoing transition representing the completion of the internal action. When more than one outgoing transition is present, guards should be used to assure that the proper transition is triggered. A guard is a logical expression that evaluates to true or false. Nested (compound) decisions are represented through the use of a special activity called decision activity. In the same way as statechart diagram, an activity diagram has start and end points, which are called start and stop states, respectivily. When the completion of an activity triggers two or more activities in parallel a synchronisation bar should be used. Conversely, when the completion of two or more parallel activities is a prerequisite to trigger another activity, i.e., these activities must synchronise, a synchronisation bar should be used as well. An activity can be further decomposed into a lower-level activity diagram. In such cases, a single start state must be used but many stop states are possible, viz. one for each outgoing trigger. Activities can be organised into swimlanes, which are responsibility zones separated by vertical solid lines. Each activity belongs to one swimlane, but transitions may cross lanes. Each responsibility zone can be implemented by one or more object classes. Figure 2.6 shows a generic activity diagram. This activity diagram basicly consists of four activities, viz., Activity A, Activity B, Activity C and Activity D, which are distributed accross the swimlanes Swimlane 1 and Swimlane 2. According to this diagram, Activity A is the first activity to be executed. Activity B follows the execution of Activity A. After the execution of Activity B if the guard condition Guard1 evaluates to true, the decision activity
AMIDST/WP1/N006
is enabled. Then, if the guard condition Guard3 evaluates to true Activity A is enabled again, otherwise, the guard condition Guard4 evaluates to true and the activity represented by the diagram finishes by reaching the stop state End2. However, if the guard condition Guard2 evaluates to true, a synchronisation bar triggers the activities Activity C and Activity D in parallel. Both activities must be completed before the overall activity reaches an end. This is accomplished through the use of another synchronisation bar followed by the stop state End1.
Swimlane
Swimlane 1
Swimlane 2
Activity A
Start state
[Guard3] [Guard1] Activity B

Transition
[Guard2]
Decision activity
[Guard4]
Guard Activity
Activity C
Activity D
Synchronisation bar
End1
Stop state
End2
Figure 2.6. Activity diagram. 2.2.4 Sequence diagram Sequence diagram is one of the interaction diagrams provided by UML (collaboration diagram is the other UML interaction diagram, see section 2.2.5). An interaction is a behavioural specification organised as a sequence of message exchanges among a set of objects within a particular context in order to achieve a specific intent. A sequence diagram describes the lifetime of an interaction, by showing the lifelines of the objects participating in an interaction and the messages they exchange. A sequence diagram has two dimensions. The vertical dimension represents time, while in the horizontal dimension different objects are represented as vertical bars. Each object is shown as a vertical dashed line called the lifeline, which represents the existence of the object at a particular time. If the object is created or destroyed during the period of time shown on the diagram, then its lifeline starts or stops at the appropriate point. Otherwise the object lifeline goes from the top to the bottom of the diagram. The lifeline may split into two or more lifelines to show different conditions, with each track corresponding to a conditional branch in the communication. The lifelines may merge together later.
A message is a communication between objects that carries some information, with the expectation that some action will follow the arrival of the message and some value will probably be returned afterwards. Sending a message from one object to itself, which is called selfdelegation, is also possible. A message may have a sending and a receiving time for the purpose of expressing timing constraints. However, these times can be the same if the sent message is considered as an atomic message, or different otherwise. The activation of an object, also called focus of control, shows the period during which an object is performing an action either directly or through another object. The activation of an object usually follows the arrival of a message and ends with either the termination of the object or a return message to the caller object. Figure 2.7 illustrates a generic sequence diagram. This diagram consists of the objects Object 1, Object 2, Object 3 and Object 4. Object 1 is active since the beginning. At a certain point in time Object 1 sends a message (Message 1) to Object 2. The arrival of Message 1 causes the activation of Object 2. Later on, Object 2 sends a message (Message 2) to Object 3. Object 3 is then created and becomes active. If the condition Condition1 holds true, Object 3 sends Message 3 to Object 4, otherwise if the condition Condition2 holds true, Object 3 sends Message 4 to Object 4. To accomplish these different conditions the lifeline of Object 4 is split into two branches. After Object 4 has processed the received message, this object sends a return message to Object 3, which sends a return message to Object 2 and terminates itself. Sometimes after Object 2 receives the return message from Object 3, Object 2 sends a return message to Object 1.
Object 1 Message 1 Object 2
Message Object Condition
Object 4
Message 2
Object 3
[Condition1] Message 3 [Condition2] Message 4
Activation
Creation
Return
Termination
Figure 2.7. Sequence diagram. 2.2.5 Collaboration diagram A collaboration diagram consists of a set of references to objects and links between these references with flow of messages attached to them. A collaboration diagram emphasizes the organization of the objects that participate in an interaction by showing how these objects relate to each other.
10
AMIDST/WP1/N006
A collaboration consists of a set of participants and relationships that are significant for a problem at hand. A collaboration shows the context in which one or more interactions occur. A collaboration diagram without messages describes a collaboration, while a collaboration diagram with messages describes an interaction. We identify an object in a collaboration diagram by the role played by this object in the diagram. A collaboration role describes the type of object that may play the role and its relationship to other roles. There are different types of messages, such as messages representing a synchronous procedure call, an asynchronous procedure call or a signal between threads. In order to represent the sequence of messages in the overall interaction, messages are numbered starting with number 1 and increasing the number for each new message (e.g., 2, 3, and so on). Nesting of messages is represented by using a decimal scheme (e.g., 1.1, 1.2, 1.2.1). Navigability is shown by using arrowheads on links. An arrow indicates a message flowing from an object to another in the given direction over a link. Different kinds of arrows are used to represent different types of messages. Figure 2.8 depicts a generic collaboration diagram. This diagram contains four objects, named Object 1, Object 2, Object 3 and Object 4. Object 1 is connected to Object 2 and Object 3 and Object 3 is further connected to Object 4. Object 1 starts the interaction by sending the Message 1 to Object 2. Object 2 replies sending Message 2 to Object 1. Then Object 1 sends Message 3 to Object 3. So, Object 3 sends Message 4 and Message 5 to Object 4. Message 4 and Message 5 are an example of nested messages. All the messages exchanged are asynchronous.
Sequence number Object
1: Message 1 Object 1 2: Message 2 Object 2
3: Message 3 3.1: Message 4 3.2: Message 5 Object 3
Message
Object 4
Figure 2.8. Collaboration diagram.
2.3 UML 1.3 and beyond

By the time the first versions of this document were released the available version UML was UML 1.1. Recently OMG released another version named UML1.3 [12]. This version incorporates some minor changes into UML in order to correct and clarify many of the problems noted in the original specification.
11
A short list of the most relevant changes incorporated into the UML 1.3 is the following [9]: Model management diagrams. The semantics and notation for models and subsystems were improved to better differentiate them from packages; Use cases relationships. In UML 1.1 there were two different types of relationships between use cases: extend and use. In UML 1.3 the use relationship is renamed to include and a third type of relationship is added, viz., generalisation. The use case diagram presented in section 2.2.1 is already in accordance with these changes; Static structure diagrams. UML 1.3 allows association between classes and interfaces and the declaration of signals in classes; Factored transition paths. UML 1.3 introduces the concept of compound transition, which describes chains of transitions that may be executed in the context of a single runto-completion step. Two different types of compound transitions are identified, viz., split and join. In the split compound transition a single transition is split into separate mutually exclusive path, while in the join compound transition two or more compound transitions come together and continue through a common path. Synch states. A synch state is used for synchronising concurrent regions of a state machine. Forks and joins are used together with a synch state in order to insure that one region leaves a particular state or states before another region can enter a particular state or states.
For additional information and examples concerning changes in the UML 1.3 notation, please refer to [12, Chapter 3: UML Notation Guide]. Additional changes to UML are already planned [9]. For 2000 (UML 1.4), another minor change is expected concerning the refinement of extension and profile mechanisms to improve support for user customisation and the simplification and clarification of collaboration modelling based on user feedback. A major change in UML is expected to occur in 2001 (UML 2.0). For this version, changes are expected in the UML architecture, customisation and extensibility mechanisms and model management, among others. However, the most relevant changes for AMIDST is related to component support, in which improvements will be made to support component-based development, including CORBA, Enterprise Java Beans and DCOM.
12
AMIDST/WP1/N006
3. The Unified Software Development Process

A software development process is a structured set of activities to develop a software system. A software development process defines who has to do what when and how to build a software system. This chapter gives an overview of the unified software development process [7], which is also referred to as the Rational Unified Process (RUP) or Unified Process. Although the unified process makes extensive use of UML, UML itself is independent of any development process.
3.1 Overview
A traditional approach to software development is the waterfall model. In the waterfall model a software system is developed in a fixed number of sequential stages. Although the number of stages and their names vary, the overall approach is as shown in Figure 3.1. First the requirements of a software system are collected. In the next stage the requirements are analysed. Then a design is made that meets those requirements, after which the design is implemented. After the implementation the design is tested. The software system is then delivered to the user and enters the maintenance stage where adjustments and bug-fixes are made. At the end of every stage there is a validation activity to determine whether the results are good enough to go to the next stage. The validation activity itself and the criteria for passing it depend on the stage and the project. If new requirements or issues come to light a step back in the process can be taken, shown in Figure 3.1 by arrows pointing up, but only if the impact of the new requirement on the software system is relatively small. If new requirements influence the design of the whole software system and it comes up in the testing stage the impact on the project is greater. The major disadvantage of the waterfall model is the development of the software system in one go; this has two negative consequences that enhance each other: The effort needed to deal with a changing requirement increases with every stage. Misinterpreted requirements or wrong assumptions come to light late in the process. If user requirements are misinterpreted, chances are they will come to light when the complete software system is delivered to the user
The combination of these disadvantages can form a considerable risk for a software development project.
13
Requirements
Analysis
Design
Implementation
Testing
Maintenance
Figure 3.1. The waterfall model for software development.
The disadvantages of the waterfall model can be dealt with by developing a software system in a number of increments. Each increment adds functionality to the software system. In the first release the requirements that are rated most important are implemented, later increments then add other requirements. This approach is called incremental or evolutionary development. For the development of each increment the waterfall model can be used. By dividing the development of the software system into mini-projects, risks can be managed better. New or changing requirements and user feedback can be dealt with in later increments and are less likely to put a project at risk. An example of incremental or evolutionary development is the spiral model as shown in Figure 3.2. As with the waterfall model shown in Figure 3.1, the number of stages and their names may vary. A software development project based on the spiral model passes the different stages continuously, with each pass the software system evolves, i.e. more functionality is added.
14
AMIDST/WP1/N006
Planning
Risk analysis
Evaluation
Engineering
Figure 3.2. The spiral model for software development. The unified process uses an incremental approach to software development. Although it is called a software development process, it is in fact a process template. The unified process has to be specialised for different domains and type of project to be applicable. The three key aspects of the unified process are: Use case driven Architecture-centric Iterative and incremental
The unified process considers requirements the driving factor for software development. Functional requirements are captured by use cases (see also section 3.3.1). [RPo.1] Nonfunctional requirements can be captured by textual descriptions. The combination of all use cases and textual descriptions forms the use case model of a software system; the use case model describes the software system. During the process other models of the software system are developed based on the use case model. The different models are representations of the software system from different perspectives and at different abstraction levels. The contents of a model can be structured using packages; a package is a grouping of model elements [2].[RPo.2] Core workflows specify the activities that have to be performed to develop the different models (section 3.3). Together the different models specify the architecture of the software system; i.e. they provide a complete view of the software system. Developing the models of the software system therefore means developing the architecture of the software system, making the unified process architecture-centric. Developing the models based on the use case model makes the unified process use case driven.
15
The unified process divides the development of a software system into a number of miniprojects, called iterations. An iteration is the set of activities that together lead to a new increment of the models. Iterations are grouped in phases and cycles, based on their focus (see section 3.4). The Unified Process can be represented in two dimensions, as shown in Figure 3.3. One dimension represents the dynamic aspects of the process and is divided into cycles, phases and iterations, discussed further in section 3.4. The other dimension represents the static aspects (contents) of the process: artefacts, workers, activities and workflows. These are discussed in section 3.2. Workflows that develop the different models are called core workflows. Core workflows are discussed in section 3.3 . The areas in Figure 3.3 represent the extent to which the workflows are carried out in each phase. For example: the emphasis of the requirement workflow is in the elaboration phase of the project.
Figure 3.3. Structuring of the Unified Software Development Process.
3.2 Content
The four primary elements in the static dimension of the Unified Process are workers, activities, artefacts and workflows. 3.2.1 Workers Workers represent the roles or responsibilities within the project. A worker does not necessarily represent one person; it may also represent a group of persons. One person can also play the role of different workers.
16
AMIDST/WP1/N006
3.2.2 Activities Activities are the units of work assigned to workers. An activity should have a well-defined goal. In order to track the progress of activities or the project as a whole, the goals set for activities should be neither trivial nor too complex. 3.2.3 Artefacts Artefacts are the tangible products within a project. Artefacts are produced by the activities defined in a project. Typical examples of artefacts are models, source code, design documents, and builds. A build is an executable version of (part of) the software system. During the development of a software system several builds will be produced. 3.2.4 Workflows A workflow determines the sequence of activities performed by workers that result in artefacts. In this way workflows link activities and workers to artefacts. The content of the process therefore defines which workers (who) are producing which artefacts (what) in which activities (how) in which workflows (when). The workflows that develop the different models of a software system are called core workflows. Figure 3.3 shows the six core workflows and three supporting workflows defined in the unified process. Figure 3.4 shows the different models produced as a result of the requirements, analysis, design, implementation and test workflows, as well as the relationships between them.
Requirements Use-case model

specified by realised by distributed by Implemented by verified by
Analysis Analysis model
Design Design model Implementation Implementation model Test Test model Deployment model
Figure 3.4. The Unified Process is a series of workflows that develop related models.
17
3.3 Core workflows

Core workflows develop the different related models of a system. The contents of a model can be structured using packages; a package is a grouping of model elements [2]. [RPo.3] 3.3.1 Requirements The goal of the requirement workflow is to describe what the software system should do and let the developers and the customer agree on that description. The requirement workflow leads to a use case model of the software system. The use case model describes the way users can interact with the software system; it specifies the externally observable behaviour of the software system. A use case model contains use case diagrams, their relationships and use case descriptions which may consist of statechart diagrams, activity diagrams, collaborations, and sequence diagrams. Typical activities in the requirement workflow are: Finding actors and use cases in order to define the borders between the software system and the environment (delimit the scope of the software system). This activity is also meant to define which actors (users or other software systems) use the software system and what functionality the software system should provide. Non-functional requirements can be specified using textual descriptions attached as comments in the use cases or as a separate document. Non-functional requirements define global constraints on a software system, such as development costs, operational costs, performance, reliability, maintainability, portability and robustness. Prioritising use cases to determine which use cases should be developed in early iterations (i.e. have a high priority) and which use cases can be addressed in later iterations. The prioritisation can be assigned by users or may follow from a risk analysis. Detailing a use case to give a precise description of a use case, including how the use case starts, ends and interacts with actors. Prototyping user interfaces to the software system in order to allow the users to perform the use cases in a structured and well-defined way. Designing a user interface is done in close interaction with the intended users. Structuring the use case model to find common functionality in the use cases. This leads to a structured use case model with generic use cases (shared by multiple use cases) and their extensions. Packages can be used to organise the use cases in manageable pieces.
3.3.2 Analysis The analysis workflow leads to an analysis model of the software system. The analysis model describes how the behaviour specified in the use case model can be realised. A description of how one specific use case can be realised is called a use case realisation-analysis. The analysis model provides an internal view of the software system in the language of the developer; the use case model provides an external view of the software system in the language of the customer. The analysis model can be viewed as a first cut at the design of a software system.
18
AMIDST/WP1/N006
Packages can be used to group parts of the analysis model into manageable pieces. Packages used in an analysis model are called analysis packages. The analysis model is composed of use case realisations-analysis. One use case realisationanalysis is composed of class diagrams, interaction diagrams, and additional textual descriptions of the interaction diagrams called flow-of-events descriptions. The analysis model is a conceptual model; it is an abstraction of the system and avoids implementation issues. The classes used in the different elements of an analysis model are called analysis classes. Analysis classes represent abstractions of one or several classes and/or subsystems in the design of the software system. Class diagrams and interaction diagrams show how analysis classes interact to realise a use case. An analysis class can be one of three stereotypes: Boundary class, Control Class or Entity class. A boundary class is used to model interactions between the software system and its actors. An entity class is used to model information that is long-lived and often persistent. Control classes represent co-ordination, sequencing, transactions, and control of other objects and are often used to encapsulate control related to a specific use case. Figure 3.5 shows the notation for different stereotypes of an analysis class.
Boundary Class
Control Class
Entity Class
Figure 3.5. Stereotypes of an analysis class. The main activities in the analysis workflow are: Architectural analysis to outline the analysis model and to find the appropriate analysis classes. Analysing a use case to translate a use case into interacting analysis classes; together the analysis classes realise the use case. The mapping from use cases to analysis classes can be represented using class diagrams or collaboration diagrams. Analysing an analysis class to identify its responsibilities, its attributes, its relationships and special requirements. Analysing an analysis package to ensure that it provides an appropriate decomposition, i.e. has weak couplings (limited dependencies) with other packages, and that the analysis classes contained in the analysis package have well defined responsibilities and functionality.
3.3.3 Design The design workflow results in a design model and a deployment model. The design model is composed of use case realisations-design. One use case realisationdesign describes how a use case can be realised. The difference between a use case realisa-
19
tion-analysis and a use case realisation-design is the level of abstraction. A use case realisation-design is composed of class diagrams, interaction diagrams, and additional textual descriptions of the interaction diagrams (flow-of-events descriptions). Together these model elements describe the interactions between the different design classes that realise a use case. The design model is the blueprint for an implementation of a software system; the analysis model is a conceptual model (an abstraction of the system that avoids implementation issues.) A design class is an abstraction of a class in the software systems implementation. Collaboration and sequence diagrams describe how the design classes interact to realise a use case. A design class is directly related to the implementation of a software system. Methods specified in a design class have a one-to-one relationship with the final implementation of the design. The deployment model describes how the functionality of the software system is distributed among the different computational nodes. The deployment model specifies responsibilities of the hardware and software components or subsystems and their relationships. A deployment diagram is the main diagram used in the deployment model. The main activities in the design workflow are: Architectural design to outline the design and deployment models by identifying computer nodes, subsystems and their interfaces, and top-level design classes. Designing a use case to identify the parts needed to perform a use case and to assign the behaviour of the use case to the different interacting objects or subsystems. The design of a use case can lead to implementation requirements. (example: if requirements exist for a maximum response time of a software system it might be necessary to implement parts of a software system using machine language) Designing a class to create a design class that realises the use cases it is involved in and non-functional requirements imposed by those use cases. This activity involves identifying operations, attributes, states, dependencies, and implementation requirements. Designing subsystems to organise the artefacts of the design model in manageable pieces. A subsystem can consist of design classes, use case realisations, interfaces, and other subsystems. Subsystems should be as independent as possible of other subsystems.
3.3.4 Implementation The implementation workflow results in an implementation model that describes how elements in the design model (such as design classes) are implemented in terms of components. The implementation model also specifies the dependencies of these different components. Dependencies may depend on the programming language and the implementation environment (e.g. operating system) used. Activities in the implementation workflow are: Architectural implementation to identify architecturally significant (executable) components and map them to computer nodes. System integration to create an integration build plan and to integrate each build before integration tests. An integration build plan specifies the functionality that is included in each build and which builds will be subject to integration tests (see section 3.3.5).
20
AMIDST/WP1/N006
Implementing a subsystem to ensure the subsystems exhibit correct behaviour in each build as specified in the build plan. Implementing a class to implement a design class in a file component. Implementing a class could include generating source files from a design class. The result of this activity is a component providing the same interfaces and operations as the design class it implements. Performing a unit test to test the implemented components with respect to their desired functionality and behaviour or other requirements.
3.3.5 Test The test workflow leads to a test model. A test model is formed by test cases, test procedures and test components. Activities in the test workflow are: Planning test to describe the strategy for testing and to estimate the requirements for testing in terms of (human and system) resources for each iteration. Designing a test to identify and describe the test cases and test procedures for each build. Typical tests are integration tests, system tests, and regression tests. Integration tests verify integration of a component in a build, system tests verify system functions, and regression tests check whether integration of new components corrupts the specified behaviour. Implementing a test to enable automatic testing. Not all testing can be automated. This activity can consist of developing scripts or programming test components by hand in case scripts are not supported. Performing an integration test as specified for an iteration, capturing the results for the test evaluation. Performing a system test as specified for an iteration after the integration tests have been considered successful. Results from system tests are captured for test evaluation. Evaluating a test to evaluate the results captured by the testing activities in order to determine the completeness and reliability of the software system.
3.4 Timeline
The time dimension is the dynamic organisation of the process. This is broken down into cycles, phases and iterations. One cycle is equivalent to a generation of the software product. An example is the Windows operating system. The different generations of this operating system are Windows 3, Windows 95, Windows 98, and Windows 2000. Generations are not limited to operating systems, they can be found in all software products. Another example could be Netscape Navigator, where Navigator 2, Navigator 3 and Navigator 4 can be recognised as different generations.
21
In the Unified Process every cycle is composed of four phases: inception, elaboration, construction and transition. Each phase has a different focus, for example the inception phase focuses on setting the scope of what the product should do and preparing the business case. Each phase consists of one or more iterations. Each iteration begins with a planning activity, passes all the five core workflows and concludes with an assessment where a go no-go decision is made. The assessment is called a milestone. Sections 3.4.1 through 3.4.8 give an overview the four phases of the unified process and their associated milestones. The outcome of the phases and the evaluation criteria of milestones are presented at a high level (such as: at this point in the process there should be a risk analysis). Determining the artefacts that should be present at the end of a phase and determining the evaluation criteria in detail are part of the specialisation of the unified process for a particular domain; this specialisation is outside the scope of this document. 3.4.1 Inception phase The inception phase is the starting phase for each cycle. The main purpose of the inception phase is to determine the business case and feasibility of the project. The main question this phase has to answer is whether the launch of a full-scale project is justified and what chance the project has of succeeding. The inception phase focuses on: Delimiting the scope of the proposed software system (what the software system should and should not do). Resolving ambiguous requirements. Describing the outline architecture or top-level use cases of the software system, focussing on the parts that are new to the participants involved in developing the software system. Identifying potential risks.
These activities all help to identify potential obstacles in the development of a software system early on and make it believable that the proposed software system can be built. The outcome of the inception phase is: An initial use case model (10%-20% complete) An initial business case An initial risk assessment A project plan showing phases and iterations One or several prototypes
22
AMIDST/WP1/N006
3.4.2 Lifecycle objectives milestone The lifecycle objectives milestone marks the end of the inception phase. The lifecycle objectives milestone is considered as reached if: Stakeholders agree on the scope of the software system and the estimates with respect to the schedule and costs. Primary use cases, describing the most basic functionality, indicate that users and developers understand and agree on the requirements. Cost, schedule, and risk estimates are credible. The actual cost of the inception phase can be compared to the cost estimates for the next phases to check the credibility of the cost estimates.
3.4.3 Elaboration phase The primary goal of the elaboration phase is to get a stable architecture. The basic ideas of the project, laid out in the inception phase, are worked out in the elaboration phase. The highest risks are identified and dealt with in this phase. The elaboration phase focuses on: Early versions of all the models of a system; called an architectural baseline. The architectural baseline addresses the top-level requirements. Identifying significant risks and determining how to deal with them. Non-functional requirements and requirements not associated with specific use cases (such as defect rates and response times) Ensuring all use cases and actors have been identified. schedule, staff needed and costs
The outcome of the elaboration phase is: A use case model (at least 80% complete) in which all use cases and actors have been identified, and most use case descriptions have been developed. Supplementary requirements capturing the non functional requirements and any requirements not associated with a specific use case. A software architecture description. An executable architectural prototype. A revised risk list and a revised business case. A development plan for the overall project, including the coarse-grained project plan, showing iterations and evaluation criteria for each iteration.
23
An updated development case specifying the process to be used. A preliminary user manual (optional).
3.4.4 Lifecycle architecture milestone The lifecycle architecture milestone marks the end of the elaboration phase. The lifecycle architecture milestone is considered as reached if: The vision and architecture of the product are stable. An executable demonstration addresses the major risk elements. The construction phase has been planned with enough detail and accuracy. All participants agree on the vision and the plan. The actual expenditure versus the planned expenditure is acceptable.
3.4.5 Construction phase In the construction phase, the architecture is expanded and refined. The parts of the software system that were not produced in previous phases are produced in the construction phase and integrated into the software system. The software system is thoroughly tested; the outcome is a product ready for (Beta) release. The primary goal of the construction phase is to build a software system the customers can use to give feedback. The construction phase focuses on: Completing all use cases. Maintaining integrity of the architecture. Monitoring critical and significant risks.
The outcome of the construction phase is a software system ready to put in the hands of the end-users. At minimum, it consists of: The software system integrated on the adequate platforms. The user manuals. A description of the current release.
3.4.6 Initial operational capability milestone The initial operational capability milestone marks the end of the construction phase. The initial operational capability milestone is considered as reached if:
24
AMIDST/WP1/N006
The product release is stable and mature enough. All parties involved are ready for the transition of the software system to the users. Actual expenditures versus planned expenditures are still acceptable.
3.4.7 Transition phase In the transition phase a release of the software system is handed over to the users. The users can evaluate the software system with respect to the requirements and use cases. The evaluation by the users should determine whether the software system performs the functions as desired by the users and conforms to the non-functional requirements. In the transition phase the users are trained to work with the software system if needed. The transition phase focuses on: Validation of the software system against user expectations. Training of users and maintainers. Rollout of the software system to the marketing, distribution, and sales teams. Parallel operation with a legacy system (if the software system is replacing a legacy system). Conversion of operational databases.
3.4.8 Product release milestone The product release milestone marks the end of the transition phase. The product release milestone is considered as reached if: The user is satisfied with the software system. The actual expenditures are in line with the planned expenditures.
Another development cycle may follow this phase.
25
4. UML design and analysis tools

This section presents a survey on several object-oriented analysis and design (OOAD) tools that support UML and are currently available on the market. First, we outline some criteria on which the survey is based. Then, every product is studied and evaluated with respect to the defined criteria. An overall analysis of the tools is presented in section 6, while some conclusions are presented in section 7. The goal of this survey is to measure the applicability of off-the-shelf OOAD products in the AMIDST project. In AMIDST such tools can be used at the conceptual level for generic and formal description of the results in the project and better management of the interactions between work packages. At software development level, OOAD products provide support for rapid prototype development.
4.1 Criteria
The criteria used to investigate and compare the different products are grouped into two categories: functional and qualitative. With functional criteria different aspects are taken into account, such as support for certain basic version of UML, support of repositories of models, round-trip engineering, support of advanced printing and presentation facilities, etc. Qualitative criteria include general impression about the ease of use of the products, computer resource consumption and price and availability. Furthermore, every criterion contains requirements (for desired product features) that can be categorized as "must-have" and "good-to-have". A "must-have" requirement responds to basic features in a product that have been identified as essential to the goals of the AMIDST project. If a product that does not fulfill this requirement is more likely to receive low mark during the analysis and comparison in section 6. A "good-to-have" requirement refers to features in a product that make it perform better, is quicker to learn, make it more flexible and divers in options and solutions when solving particular tasks with this product. In the criteria description, if a requirement is not explicitly defined as a "good-to-have" it is assumed a "musthave". The testing of the products has been performed on a PC computer with Intel Pentium II 350 MHz, 256M RAM, 17" monitor. The operating system is Windows NT 4.0 with service pack 4. Several examples were used to test the products, however the explicit representation of these examples is out of the scope of this document. 4.1.1 Functionality In general, a criterion related to functionality has been taken into account if it is essential to the effectiveness of the modeling process (e.g. pick lists, round-trip engineering), enables integration with other important technologies (e.g. component models), allows customizations of the design environment (scripting), and others.
26
AMIDST/WP1/N006
4.1.1.1 Repository support A large project usually produces a lot of conceptually complex model artefacts. Thus, a repository of models is necessary for organising and sharing model content between project members. Networking capabilities in the repository support of a product are highly appreciated. Changes in designs that are linked to other designs should automatically be propagated. Importing/exporting of whole models as well as parts of models should be available. As it may turn out that several OOAD tools from different vendors must be used in the AMIDST project, it is recommended these tools have support for interchanging model data. This can be achieved at repository level or through a common description format, e.g. OMGs XML Metadata Interchange (XMI). Support of XMI is a "good-to-have" feature. 4.1.1.2 Notation support UML 1.1 is the basic notation that should be supported, as it contains all necessary elements for the unified modelling process. If not all elements of the UML 1.1 are supported, at least the following diagrams should be: Use Case, Class, Collaboration, Sequence, Package and State diagrams. AMIDST project is using input from publications and other projects that may use different notations for describing concepts and designs, thus any support for additional formal notations in a OOAD product is welcomed. For example, the older notations, OMT and Booch, are similar to UML and have almost direct mapping into the UML notation. Support for OMT and Booch, as well as other notations, is a "good-to-have" feature. 4.1.1.3 Pick-lists A pick list is a feature of the graphics user interface (GUI) of OOAD product. It allows the designer to quickly access already defined elements of the currently open model from any view of the current model. A pick list can also be integrated with a repository, thus allowing quick access to the elements of other developers models, older projects or models that have become generic templates. Pick lists contribute significantly to the effective use of particular modelling tool and can be considered a "must-have" feature. Pick lists should be available in at least these two cases: Collaboration and Sequence Diagrams - The tool should allow an object to be assigned to a class from the pick list of classes already defined in the current model. It should be possible messages (or method calls) sent between objects to be chosen from a pick list of methods for selected object (class) that is receiving the message. Class Diagram - Pick list for already defined in the current model classes should be available. Pick lists for quick access of the classes defined in other models should also be available.
4.1.1.4 Round-trip Engineering The capability of a modelling tool to generate template source code from a model for a specific programming language is called forward engineering. The capability of a product to process source code and extract partial model information is called reverse engineering. Sup-
27
port for forward and reverse engineering throughout the software development process is called round-trip engineering. Round-trip engineering can also include cyclic repetitions of forward and reverse engineering, thus enhancing the iterative design and development process. This feature is essential for the collaboration between designers and developers, as developers might change the source code (e.g. speed of execution optimisations) and the modellers should incorporate these minor changes (if any) in the model through reverse engineering. The same applies to changes in the model and their reflection on the source code templates. Another essential usage of round-trip engineering is when incorporating legacy code into new models. At least, the modelling tool should support round-trip engineering for Java, C++ and IDL (for interfaces stereotypes and interfaces in component descriptions). The Java technology is one of the main choices in AMIDST with respect to the prototyping platform. Thus, any additional support for Java and related technologies in the surveyed products is considered a "good-to-have" feature. Furthermore, we can distinguish two aspects in the forward engineering: code generation from static UML diagram and from dynamic UML diagrams. Since it is a generally difficult task to generate source code from dynamic diagrams, this is considered as a "good-to-have" feature. One of the areas of research in AMIDST is design and implementation of middleware extensions, where reverse engineering will be essential, e.g. when building on the source code of free ORB implementations. 4.1.1.5 Data Modelling Integration The OOAD tool should maintain or allow integration with data modelling facilities. Data modelling emphasises on the organisation of the information in the designed system. Typically, data modelling is used with database management systems. UML can model data, for example by using class diagrams as conceptual models for the information in the system. Other notations can also be used, e.g. entity relationship (ER) diagrams. Support for data modelling is a "good-to-have" feature. Another aspect of the data modelling is generation of DDL (data definition language) that is a set of SQL statements necessary to describe and create a database structure conformant to the design. DDL can be fed to a tool that will create process and create the structure in a real DBMS system. 4.1.1.6 Component modelling UML 1.1 supports the notion of components in the component diagrams. However, components in UML represent software modules (source code, binary code, executable, DLL, etc.) with a well-defined interface. There other definitions for component, e.g., [23], that define an additional set of rules that a component must obey, as well as requirement on the environment that hosts components. As AMIDST is building an architecture, part of which defines a layer of generic application objects (or components) that can be reused upon demand (e.g. demand for service functionality or Quality of Service), it is essential that the component notation in UML is additionally supported by non-proprietary extensions of the modelling tool. The modelling tools must
28
AMIDST/WP1/N006
have notion about some of the major component standards as Enterprise Java Beans (EJB), ActiveX-DCOM, CORBA Components, etc. An example of such tool extension is a facility that can reengineer interfaces of a CORBA component by examining the binary image of an off-the-shelf component (no source code is available) or by examining an instance (runtime image) of a CORBA component using Dynamic Invocation Interface. 4.1.1.7 Versioning support Quite often it is the case that version support is necessary for the elements in a model. This is especially valid when several designers work together on one model, for example, through a shared network model repository. Thus, it is very important that support for version control is available in the design product. At the least, the modelling tool must provide means for integration with third-party source control management tools. In this case, version management basically consists of keeping track of versions on per file basis. 4.1.1.8 Scripting It is a common practice that customisation of software product environment is done by means of scripting. A script is a piece of code written and interpreted by the product scripting language, that allows access to the elements (menus, toolbars) of the products environment through well defined APIs. In case of OOAD tools, the scripting language should also provide access to the artefacts of the currently opened model. Examples of usage of scripting are generation of project management spreadsheets, customised documentation, reports, metrics, etc. In AMIDST, scripting is considered as a "good-to-have" feature. 4.1.1.9 Model Navigation Model navigation relates to all GUI features that assist the designer find his way through a complex model. Model navigation includes zooming, which means magnification of the view of small or densely situated elements from the model, or the other way around, reducing the detail of the view when a better overall picture of the model is needed. Panning is another feature that means the on-screen appearance of the product is organised in several resizable panels, each containing different type or representation of the model information. One possible solution for effective model navigation is to provide a panel in the design environment that is always present on screen (e.g. on the left-hand side of the screen) and contains a treelike structure of the model. Another solution is to provide facilities for switching between graphical view of the model and source code view of selected elements of the model. All these and other related features are categorised as "good-to-have" features. 4.1.1.10 Documentation Support As the model increases its size and complexity with the advancement of the development process, some of the diagrams in the model may become rather large. When documentation reports, presentations or banners are needed within a project, it must be possible to present these big diagrams on paper. The modelling tool should then provide facilities for printing in multiple-pages, fit-to-page scaling and others.
29
Another aspect of documentation generation is publishing to a web site. Report generation facility in HTML can be a solution to this problem. Quite often dedicated products do better work for documentation. Word processors have become complex programs that allow definition of project templates for documents. This is the case in AMIDST project where part of the project policy is to use MSWord together with an AMIDST document template. Thus, it is essential for the modelling tool to provide integration with such programs by means of the interchange of views for the model elements (e.g. diagrams). Exporting of model views to raster and vector images is one solution. Vector image formats should be a preference as it allows adjustments on the image to be made outside the modelling environments. Usage of operating system proprietary technologies like MS OLE objects and system clipboard, can be another solution for exchanging views. 4.1.2 Qualitative aspects A criterion enters the qualitative groups if it is related to the quality of the whole software package (availability, resource consumption) or is essential to the amount of time-to-learn (ease of use). 4.1.2.1 Ease of use An essential feature of a successful project manager is the ability to make accurate assessment of the time cost for completion of a specific task given certain manpower. The so-called learning curve when a new technology is introduced to the project members has direct impact on these assessments. The better appearance and performance one software product has the easier it is to learn how to work with it. The "ease of use" criterion is predominantly based on the general feeling the authors of this document get from their encounter with the different products. A product will be considered "easy to use", if it has intuitive graphics user interface, responds quickly and with reasonable amount of output to user input, allows customisation and personalisation of the working environment, have a nice colour scheme, has context sensitive help system, etc. 4.1.2.2 Resource consumption With the growth of the computer industry, the processing power of the desktop computers has risen considerably. Even as we speak, the fast pace of the IT technologies produces new computers that are cheaper and more powerful than their predecessors from several months ago. Badly written software however, can make any computer perform slowly. Upgrades of desktop machines in projects shared between several large organisations can be resource and time-consuming task that depending on the planning of the particular project can be even impossible. That is why in this section attention is paid to the performance of the software products being surveyed. Important aspects in this respect are memory consumption, disk space footprint, processor load, response time during heavy usage, etc. 4.1.2.3 Availability Whenever the information is available, this section will provide some pointers to prices and general availability of the different products with respect to type of the distribution package.
30
AMIDST/WP1/N006
4.2 Rational Rose 98 SR1

The results presented below have been obtained by testing the product and checking online information. The product version that has been used in this survey is Rational Rose 98 SR1 trial (RRose). 4.2.1 Functionality Repository support
RRose supports the external Microsoft Repository (MSR). A special add-in, the Visual component Manager 98 (VCM), extends the RRose modelling environment to allow the usage of the MSR for the purposes of OOAD. Through the VCM, RRose can import and export models from and to the repository. As MSR is a network application, the VCM of RRose also provides this functionality. The exchange of the data is on per model level, i.e., parts of the model cannot be easily imported (or exported). However, it is possible to save parts of the model under auxiliary data format and import into another model. RRose contains the Visual Differencing tool that allows comparison between models. It is possible to use the differencing tool to manage the content of models and to import/export parts of a model into another. However, the mapping between model artefacts with the same name is not very convenient as no global dictionary of predefined elements is used in RRose. RRose does not provide XMI support. Notation support
RRose fully supports UML 1.1 notation. RRose also supports Booch and OMT notations. Fast on-the-fly fully automatic conversion is possible between Booch, OMT and UML. Pick Lists
Pick lists for classes are available. In the Collaboration and Sequence diagrams there is no pick list for classes available. Instead, drag and drop from the model management window to the diagram window allows instances of already defined classes to be created. Round-trip Engineering
RRose supports round-trip engineering for C++, Java, and IDL. The Java 2 platform is not supported in the reverse engineering yet. There are problems with processing inner class definitions from Java source code. In this case, RRose cannot successfully reengineer the model from the source code. RRose generates code templates only from the static class diagrams. Data Modelling Integration
RRose supports DDL generation from class definitions. RRose provides special support for Oracle 8 integration.
31
Through the ERWin add-in to the RRose environment, support for entity relation diagrams is provided. Component modeling
RRose supports the UML notation for modelling components. RRose does not support any particular component technology nor any specific extensions to the notation are available in respect to component modelling. Versioning support
RRose supports Rational ClearCase and MSSource Safe configuration management and version control systems. ClearCase allows configuration management and version control within and outside a model. MSSource Safe allows version control on per model (file) basis. Scripting
RRose supports scripting of the modelling environment. With the RRose scripting, the modeller can automate sequences of repetitive actions. Some examples of such automation are scripts for diagram and class creation, model updates, and document generation. The scripting API exposes most of the RRose model artefacts. The script language syntax is similar to Microsoft Visual Basic. Model Navigation
Zooming is a generic feature of RRose diagram views. For quick access to model elements, there is always a panel with model navigation tree accessible on the left side of the product window. Documentation support
Large diagrams can be printed in a convenient multiple-paged tile-set style. The print wizard allows good level of customisation of the printing. For example, the modeller can choose which types of diagrams at which depth of complexity to print. Diagrams can be transferred to word processors through the system clipboard. The format of the transferred image is a vector format, which allows in document further manipulations as resizing and basic editing. Exporting of diagrams into images is not directly possible in RRose. The enterprise edition of RRose includes an HTML report generation add-in that assists the modeller in the process of web publishing of the model documentation. 4.2.2 Qualitative aspects Ease of use
RRose is relatively easy to work with. It contains example models that help the modeller understand how the notation is applied with RRose. The graphical user interface is simple and responds quickly to the user input. Customisations of the modelling environment are possible to a certain extend (panel layout, toolbars). There is a help system integrated with RRose, but sometimes it is difficult to use and does not provide detailed information about the topic.
32
AMIDST/WP1/N006
Resource consumption
RRose is a quick performing application (the Windows version). The occupied disk space by the core of the product is not significant. Additional documentation and tutorials however, may need more space to install. RRose will run on most desktop computer configurations (see products minimum requirements on the Rational web site for more details). Availability
Web site: http://www.rational.com The table bellow presents the three different packages under which RRose is available. The trial version that is used for the survey is compatible with the second package (modeller edition).
Product Rational Rose 98I Enterprise Edition, includes one year of support, supported platforms: Windows 95, NT Rational Rose 98I Modeller Edition, includes one year of support, supported platforms: Windows 95, NT Rational Rose 98I Professional Java or C++ or Visual Basic Edition, includes one year of support, supported platforms: Windows 95, NT
Price (US$)
$4155
$1812
$2588
4.3 SELECT Software

The results presented below have been obtained by testing the product and checking online information. The product version that has been used in this survey is SELECT 6.0 trial (SELECT6). SELECT6 includes server support as well. 4.3.1 Functionality Repository support
The server software of SELECT6 maintains an advanced repository of models. The repository integrates seamlessly with the Windows environment through using repository servers organised in a SELECT model network neighbourhood. Multiple repositories can be started. The designer can connect to a network repository, create/import/export models from/to the repository. The networking environment of the repository also supports user awareness, permissions, and offline work with later synchronisation with the repository. The client software of SELECT6 (the modeller) supports a model dictionary that contains all generic terms and definitions and serves as template for new models.
33
SELECT6 does not support XMI. UML 1.1 Support
SELECT6 fully supports UML 1.1. SELECT6 support OMGs MOF that can be used for model interchange. Pick Lists for Classes and Methods
Access to previously defined items in the diagrams can be performed through the model dictionary. Pick lists are considered a shortcut to accessing previously defined elements, however, through the dictionary direct picking of class names is not as quick as it would be from a pick list. Round-Trip Engineering
SELECT6 supports round-trip engineering for Fort, C++, Visual Basic and Java 1.1. SELECT6 defines a set of enterprise data types that are used during the engineering process. The consequences are twofold : first the model does not contain language dependent information, and second, reverse engineering is not accurate and forward engineering generates overhead for the enterprise data types instead of direct mapping to the implementation language data types. SELECT6 generates code only for the static class diagrams. Only Java 1.1 is supported. Data Modelling Integration
In SELECT the data model describes how storage information can be recorded in the dictionary and displayed on a class diagram. SELECT6 can map class diagrams onto a database structure. SELECT6 contains a storage mapping function, which allows you to automatically create tables, columns and relationships from information contained in a business object model. More complex data models as well as different notations are supported in a separate software package SELECT SE. Component modelling
Components defined with SELECT Enterprise can be published in the SELECT Component Manager (SCM). SCM allows development teams to catalogue, store and retrieve components across the enterprise or the Web. It also provides communication capabilities between different development groups, as a standardised way to identify and reuse components for true enterprise-scale development. The component manager support DCOM/ActiveX, JAVA/Beans, and MOF. Versioning support
Version support features in SELECT6 at model level, i.e. it keeps track of versions of models. Scripting
Scripting is not supported by SELECT6 environment.
34
AMIDST/WP1/N006
Model Navigation
Zooming is supported in the SELECT6 diagram views. The default layout of the panels of the environment is difficult to work with, however they can be rearranged. Documentation support
Printing tile sets of large diagrams is supported. Fit-to-page scaling is also an option. Exporting of diagram views is available through the system clipboard only in raster bitmap format. Report generation facility allows automatic generation of documentation. Integration with MSWord through OLE objects is supported. 4.3.2 Qualitative aspects Ease of use
SELECT6 offers good support for work in workgroups. The GUI is sometimes hard to work in the sense that functionality is not where the user expects to find it. There are no examples and only the good help information assists the novice designer. Resource consumption
Together with the backend support, SELECT6 is a big software package. For the trial version 300Mb of disk space are needed to install. Availability
Web site: http://www.selectst.com No pricing information is available on the web site. SELECT6 is available under several packages for Java, C++, Forte, and Visual Basic. The support for component modelling with SELECT Component Manager is situated in a separate software package.
4.4 System Architect/2001

The results presented below have been obtained by testing the product and checking online information. The product version that has been used in this survey is System Architect/2001 (SA) trial CD. 4.4.1 Functionality Repository support
SA provides a shared repository with networking support. Special "auditing" feature allows the designer to track propagated changes on a model done by other designers. In the design environment, SA organises all defined terms in a global dictionary. These definitions can be reused in any subsequent model.
35
SA does not support XMI or other model interchange format. Notation support
SA fully supports UML 1.1. SA also supports the following techniques and methods: Catalyst Business Process, IDEF0/3, UML, OMT, Booch, Entity Relationship, IDEF1X, Yourdon, Gane&Sarson, Ward&Mellor, SSADM, Information Engineering. The product aims at providing a single solution for enterprise-wide development with coverage of the areas of Business Process Modelling, Object-Oriented Modelling and Data Modelling. Pick-lists
SA offers pick lists for the defined classes and methods. The content of a pick list depends on the context (current class selection, etc). An example of the usage of the SA pick-list for methods is when the designer drags-and-drops methods to a text field from the new class or new object wizard. The value is then automatically accepted. Importing definition is also offered through the global dictionary. Round-trip Engineering
SA can generate source code for C++ and Java. SA supports reverse engineering of source code and it processes correctly Java inner class definitions. SA also supports reverse engineering for data descriptions through the Reverse Data Engineer tool. This tool offers support for the most widely used DBMS systems. SA generates code only for the static UML class diagrams, OMT Object model, Booch Class diagrams and Shlaer/Mellor Information model. Data Modelling Integration
SA provides relational data modelling through ER diagrams. Other techniques are separate physical data models and logical view diagrams. SA provides generation and reverse engineering of data structure for most of the leading RDBMS systems, including Oracle, Sybase, DB2, MSSQL Server, AS400 and PowerBuilder. Component modelling
Component modelling is supported through the UML notation. No special support for particular component technologies is offered. Versioning support
SA offers versioning support through the integrated product PVCA. Scripting
The SA modelling environment supports a scripting facility. The script language is similar to the MS Visual Basic and is called VBScript. The help system for the scripting that assists the designer is context sensitive. However, it does not provide enough information on the programming API.
36
AMIDST/WP1/N006
Model Navigation
The workspace of SA is organised in an efficient way. On the left hand side there is a navigation panel containing hierarchical structure of the whole model. A preview thumbnail panel is offered to the designer as a large diagram might take long time to load in the normal view panel. Zooming and panning is supported. SA also provides several options for automatic arrangement of the view panels. Documentation support
Large diagrams can be printed in two ways: actual size over a tile set of several pages or fitto-page. The SA printing wizard offers many options for additional adjustment. Exporting of objects is supported through the system clipboard in two formats: raster (bitmap) and vector (windows meta-file format). 4.4.2 Qualitative aspects Ease of use
SA is a robust modelling application that implements many modelling techniques and notations. SA requires more time to learn, but it is a powerful tool that once acquainted with, is relatively easy to use. Its screen space is well organised. The user interfaces are intuitive and respond quickly to the user interactions. Resource consumption
SA is a big application and when large models are opened, its performance becomes awkward (consumes both lots of CPU time and memory). In general, it is a robust application to work with. Availability
Web site: http://www.popkin.com No pricing information is available on the web site. System Architect/2001 integrates with a whole family of other products available at Popkin Software.
4.5 Together J
The results presented below have been obtained by testing the product and checking online information. The product version that has been used in this survey is TogetherJ (TJ) developer edition, which is a product with explicit support for Java. 4.5.1 Functionality Repository support
37
TJ does not maintain a repository of models. However, basic repository functionality can be obtained through an external version control system (see "Versioning support"). TJ organises the project class path using a list of directories. TJ includes a facility for the import/export of Rational Rose format of models that allows model data interchanges. Notation support
TJ supports UML 1.2 with class, sequence, collaboration, use case and state diagrams. Pick-lists
TJ supports pick-lists in the property window. When a reference to an existing artefact is needed, a pick-list can be invoked. Round-trip Engineering
TJ supports simultaneous round-trip engineering that keeps the model and source always upto-date. TJ generates Java, OMG IDL and IDL for COM. TJ integrates with several Java development environments (JBuilder, Symantec Visual Caf), allowing instant reengineering of the program code from the development environment into the TJ workspace. The other direction (update of the source code into the development environment) is also automated. TJ supports code generation for static class diagrams. Data Modelling Integration
TJ can generate DDL and CocoBase object-to-relational mapping. CocoBase is a rule-set for mapping object states to relational database. Component modelling
TJ supports only the JavaBeans component technology. Versioning support
Versioning support is available only through external tools. TJ can invoke check-in, checkout, and other standard version control system (VCS) commands from within the modelling environment. Scripting
TJ features Open Java API that allows integration of add-ins, generation of custom documents, etc. The script language is Phyton. The API and the scripting facilities are provided with access to all artefacts in the design environment. Model Navigation
TJ has extended view management that allows control over the current diagram view and position. Zooming/panning is supported. Documentation Support
TJ printing facilities include wall-chart printing, auto-layout for printing to avoid page breaks, fit-to-page and scaling.
38
AMIDST/WP1/N006
No exporting to images is possible with TJ. This is a major drawback. 4.5.2 Qualitative aspects Ease of use
TJ is very easy to work with as it has straightforward graphical user interface. The help system is in HTML and indexed search is not possible to be performed. Resource consumption
TJ is a pure Java application and as any interpreted language performs slower than a native compiled Win32 application, but it can also be run on different OS platforms (e.g. UNIX). TJ has a relatively small footprint, about 12M of disk space together with the documentation. Availability
Web site: www.objectuk.co.uk The table below presents the different availability packages of TJ.
Product Together/J Developer Edition Together/J Developer Edition with premium support and upgrades for one year
Price (US$) 3295.00 4090.00
4.6 Structure Builder

The results presented below have been obtained by testing the product and checking online information. The product version that has been used in this survey is Structure Builder (SB) Enterprise Pro-SM edition. Structure Builder is a product with explicit support for Java. 4.6.1 Functionality Repository support
SB does not support a repository of models and does not have a shared work-team management embedded in the product. Existing models can be imported. Any changes made in the new model are propagated inside the model and do not affect the models that have been imported. Model data interchange is not available in SB.
39
Notation support
SB supports UML 1.2 class and sequence diagrams. SB concentrates on these two types of diagrams and supports source code generation to and from them. Other diagram support is not provided. No other notations are supported. Pick Lists
Pick lists are available for both class and sequence diagrams. Drag-and-drop is available in every view of the product. Round-trip Engineering
SB is a powerful tool for synchronised round-trip engineering. The diagrams are never out of synchronism with the source files because both are updated on-the-fly. SB supports code generation for both static class diagrams and sequence diagrams. The generation of code for dynamic diagrams includes generation of statements for object instantiation, nested method calls, etc. Data Modelling Integration
Data modelling is not supported in SB. Component modelling
SB supports Java Beans and Enterprise Java Beans. SB supports visual definition, verification and generation of supporting code for EJB, as well as parsing, identification and extensions of existing components. Version support
SB does not integrate with any source control or version control system. However, this integration is possible through an external version control system or custom SB extension with the help of the SB API. The SBS file format allows seamless but limited sharing of diagrams between users and across platforms. Scripting
SB can be modified to suit particular development needs. A complete API is defined that allows access to the model data, the user interface and the code generation facilities. Model Navigation
SB supports zooming, snap to grid, selection band, helpful tool-tips, flexible line placement, auto-layout, etc. The model is organised in diagram sets. A panel on the right side of the screen shows the source code that corresponds to the currently selected elements for the active diagram. Documentation support
The printing support of SB offers print preview and printing of large diagrams in multiplepage wall-chart format.
40
AMIDST/WP1/N006
SB supports Javadoc, which generates documentation and API reference for the generated source code. SB automatically synchronises the Javadoc related tags (from the source code) with the documentation. SB also offers a documentation generator facility that generates documentation from diagrams and code comments into HTML-formatted document set. SB can export diagrams to PNG or BMP image file formats, which are both raster formats. There is no vector image format support, which is considered a drawback. 4.6.2 Qualitative aspect Ease of use
Designers with basic experience in OO design will learn how to work with SB in less than 15 minutes. Its interface is intuitive, simple and well organised. Resource consumption
SB is a pure Java application. In this way, SB can be used on any platform that supports a Java Virtual Machine (JVM). Because SB is an interpreted application, it needs more memory for better performance. SBs footprint is relatively small; installed SB occupies less than 9Mb of disk space. Availability
Web site: www.tendril.com SB comes in several packages as illustrated by the table below. Upgrade and support options are available for purchase.
Product StructureBuilder Standard StructureBuilder Enterprise StructureBuilder Enterprise Pro StructureBuilder Enterprise Pro-SM Maintenance Support Incident Upgrade Standard to Enterprise Upgrade Enterprise to Enterprise Pro Upgrade Enterprise Pro to Enterprise Pro-SM
Price (US$) $ 295 $ 695 $ 995 $1,990 15% $ 25 $ 400 $ 300 $ 995
41
5. Applying UML A case study

This section illustrates the use of UML in the design of an electronic examination system. The purpose of this case study is to get acquainted with the different UML diagrams and with some activities of the Unified Development Process.
5.1 Problem description

This case study comprises an electronic examining system. A teacher makes use of the system to give an examination to her/his students. We assume that creating an examination is a separate task performed out of the scope of the examining system. This system should be made available on the web, so that both the teacher and the students have remote access to it. A teacher creates a test and stores this test into a test repository. Afterwards the teacher can assign this test to a group of students. There can be different types of tests but all of them must have a deadline defined by the teacher. So, for example the teacher may propose an examination in which the students are requested to write an essay about a certain subject or to solve some questions. The former activity may take several days to be completed while the latter may take only a limited number of minutes. The teacher also evaluates a students test answer by attaching comments and grading it. When a student access the system, this student can consult his/her personal profile and do a test. A student personal profile contains his/her personal information, the list of tests to be done and the answers, grades and comments of completed tests. A student does a test by submitting the answers for this test. Once an answer is submitted it can not be resubmitted. All the student personal profiles are stored in a profile repository, however the access of a student is limited to his/her personal profile.
5.2 Problem modelling

This section reports the results of our case study modelling activities. Each of the following subsections presents some of the results of these activities, viz., requirements capturing and analysis. The complete UML documentation of this case study can be found in Appendix A. We have performed neither implementation nor test activities because the execution of such activities is not the intent of this case study. Ideally some design activities should have been performed as well. However, due to the shortage of time this activity was not performed either. The development of this case study was performed making use of Rational Rose as a modelling support tool. 5.2.1 Requirements capturing The requirements of the electronic examining system were captured by means of a use case diagram according to the following steps: 1. Identification of the actors;
42
AMIDST/WP1/N006
2. Identification of the use cases; 3. Description of each use case. The identification of the actors of the system was straightforward. We simply identified the roles of the potential users of the system. The identified actors are the following: Student, who is a person who takes exams and consults some personal and test related information that are stored in his/her profile. The student has limited access rights to the system; Teacher, who is a person that assigns tests to groups of students and grade the assigned tests. The teacher has full rights to the system.
The identification of the use cases was more complex. As a rule of thumb to identify a use case we considered the following criteria: a use case should represent a sequence of related actions that provide some functionality to the actor when successfully executed. Whenever a variation on a normal behaviour or a repetition of a separate use case were identified, the extends and uses relationships between use cases were used. The identified use cases are the following: Access Student Profile, which is used to access the student profiles. All student profiles are kept in a profile repository ordered according to the student groups that the student belongs. The teacher reads and writes the student profile, while the student reads the student profile. The student can write to his/her profile only the test results. Access Test Repository, which is used to access the test repository. The teacher can read and write to the test repository, while the student can read from the test repository only the tests that are assigned to his/her profile. Assign Test, which is used to select a test from the test repository and assign the selected test to a group of students. Consult Profile, which is used to consult a student personal profile. The student profile contains the student personal information, the tests to be done, the test answers and the grades received so far. The student profiles are stored in a profile repository. A student has access rights only to his/her personal profile. Do Test, which is used to do a test. The student selects one of the tests from his/her profile. The student retrieves this test from the test repository. Then, the student does the test and submits the test answers, which are stored in his/her profile. Evaluate Test, which is used to evaluate a performed test. The evaluation of a test consists of making comments concerning the answers provided and grading the test. The teacher first selects a test to be evaluated and then retrieves from the student profiles some or all the answers provided for that test. Register Test, which is used to register and store one test in the test repository.
Each use case was described briefly, by means of few sentences that summarises the actions (see previous use case descriptions), and in a step-by-step manner, by means of a detailed description of what the system needs to do when interacting with its actors. The detailed description of the identified use cases is presented in Appendix A.
43
Figure 5.1 depicts the use case diagram of the electronic examining system.
<<extends>>
Register Test
<<includes>> Assign Test
Teacher
<<includes>>
Access Test Repository
<<extends>> Evaluate Test <<extends>> <<includes>>
Consult Profile <<includes>>
Access Student Profile
Student
<<includes>>
Do Test
Figure 5.1. Use case diagram. 5.2.2 Analysis The analysis of the electronic examining system was performed based on the use cases identified previously. Such activity is called use case realisation-analysis and as a result of this activity an analysis model of the system is obtained. In the use case realisation-analysis three activities were performed: 1. Creation of a class diagram for each use case; 2. Creation of at least one collaboration diagram for each use case, and; 3. Creation of a conceptual diagram for the overall system. The creation of a class diagram for each use case is the first step towards obtaining an analysis model of the electronic examining system. To create a class diagram in the analysis phase, the so-called class diagram analysis, we primarily identify object classes and associations among these classes (including aggregation). Depending on the abstraction level of the diagram, attributes should be identified as well. The identification of object classes is carried out by first selecting some candidate classes. Candidate classes can be selected by looking for nouns in the use case description plus adding some other classes according to the knowledge of the application domain. Then we re-
44
AMIDST/WP1/N006
move any candidate class that is redundant, irrelevant or vague. Candidate classes that also resemble attributes, operations, roles or implementation constructs are also discarded. The identification of associations if carried out by looking for any kind of dependency between two or more classes. Again, depending on the abstraction level of the diagram, the identification of association roles and multiplicity is optional. The second step towards obtaining an analysis model of the electronic examining system is the development of at least one collaboration diagram of each use case. Each collaboration diagram created during the analysis, the so-called collaboration diagram analysis, is used to capture the dynamics of the use case in a high abstraction level. The elaboration of a collaboration diagram is based on the class diagram of the use case and on the use case description. The types of objects in the collaboration diagram comes from the classes identified in the class diagram of the use case, while the messages exchanged comes from the use case detailed description. Due to the impossibility of combining independent interactions into a collaboration diagram without compromising the understanding of the diagram, a separate collaboration diagram was created to capture each independent interaction in the use case. Last but not least, the final step of the analysis of the electronic examining system is the development of its conceptual class diagram. A conceptual class diagram is a class diagram in which no operations are defined. The purpose of such a diagram is merely to capture and represent the concepts present in a problem domain. In order to build the conceptual class diagram we just combined the class diagrams of the different use cases into one big diagram. In the sequel we present some of the results of the analysis of our case study. The use cases presented are a good example of a generic use case, i.e., an use case that is used by other use cases, a use case related with the teacher and a use case related with the student, respectively. Additionally, the presented diagrams are illustrative of different and complementary insights of the performed analysis. For each use case we present its class diagram and a collaboration diagram. The complete analysis documentation can be found in Appendix A. 5.2.2.1 Access Student Profile use case We started the analysis with the use case realisation of the generic use cases, viz., Access Student Profile and Access Test Repository. In this section, we briefly describe the realisation of the former use case, but the reasoning presented here is the same for both use cases. Besides the object classes that we identified through the use case description (nouns) we added some classes to represent the interfaces of the system (application domain knowledge). For each use case that makes use of the Access Student Profile use case and that is related with one of the users (actors) of the system, one object class is created to represent such user interface. In later stages of the development process two or more of these classes can be combined into one. However, during the analysis this is not relevant. Figure 5.2 illustrates the class diagram of the Access Student Profile use case. In order to avoid representing in the class diagram of a generic use case the same object classes as in the class diagram of use cases that make use generic ones, we represented only those classes and that are directly related with the intent of the use case. In this particular case, the object class Profile Repository and directly related classes. According to this criterion, the representation of the object class Test List is optional because this class is not directly associated with Profile Repository.
45
Because the Access Student Profile use case is a generic use case, it contains several interactions, each one initiated by a different user interface. Further, under the point of view of the use case itself it is not possible to know whether or not two or more interactions originated from the same interface are in fact dependent of each other. So, we decided to create a separate collaboration diagram for each interaction either independent or not. Figure 5.3 depicts one of the collaboration diagrams of the Access Student Profile use case. Once more and corroborating the idea of representing only objects directly related to the purpose of the use case, we avoided the complete representation of a same collaboration in both the generic use case collaboration diagram and the use case collaboration diagrams that make use of it.
Evaluate Test UI Assign Test UI Consult Profile Do Test UI
UI
Student Profile Access Rights I
Student Profile Access Rights II Profile Repository
Student Profile Access Rights
Student Group
Test List
Student Profile
Figure 5.2. Access Student Profile class diagram.
46
AMIDST/WP1/N006
: Consult Profile UI
: Do Tes t UI
: Assign Test UI
: Evaluate Test UI
: Student Profile Access Rights I
: Student Profile Access Rights II
4: test Answer
1: get Test Answer
: Profile Repository
3: test Answer 2: get Test Answer
: Student Group
: Student Profile
Figure 5.3. Access Student Profile collaboration diagram.
5.2.2.2 Evaluate Test use case Figure 5.4 shows the class diagram of the Evaluate Test use case. This diagram illustrates well the differences between a generic use case (see Section 5.2.2.1) and a specific one. While the class diagram of a generic use case shows only the object classes related with the main purpose of the use case, the class diagram of a specific use case shows all the object classes that are relevant to the use case.
47
Evaluate Test UI
Test Repository
Teacher
(from Use Case Vi ew)
Profile Repository Test
Student Group
Test List
Student Profile
Test Evaluation
Student Test Answer
Test Comment
Grade
Figure 5.4. Evaluate Test class diagram. Figure 5.5 depicts a collaboration diagram of the Evaluate Test use case. We decided to show the same interaction as showed in Figure 5.3. However, this diagram illustrates that interaction to its full extent. It is worth noting that the teacher accesses the student profile through the student group.
48
AMIDST/WP1/N006
1: get Test Answer : Evaluate Test UI : Teacher 9: test Answer 8: test Answer : Student Group 3: get Test Answer : Profile Repository 2: get Test Answers
4: get Test Answer : Student Profile 7: test Answer 5: get Test Answer 6: test Answer
: Test Evaluation
: Student Tes t Answer
Figure 5.5. Evaluate Test collaboration diagram.
5.2.2.3 Do Test use case Figure 5.6 depicts the class diagram of the Do Test use case. This class diagram also shows all the relevant object classes to the use case. This diagram is similar to some extent to the Evaluate Test class diagram (see Figure 5.4). However, the main difference resides in the fact that the access of a student to the system is restricted, which is not the case for the access of a teacher to the system. The restriction in the access is represented by the Student Profile Access Rights and Student Test Access Rights association classes.
49
Student Test Access Rights
Do Test UI
Test Repository
Student
(from Use Case View)
Student Profile Access Rights II Test
Profile Repository
Student Group
Test List
Student Profile
Test Evaluation
Student Test Answer
Test Comment
Grade
Figure 5.6. Do Test class diagram. Figure 5.7 shows the collaboration diagram of the Do Test use case. Due to the existence of only one interaction in this use case, it was possible to capture all the flow of messages in one collaboration diagram, in contrast to the other use case collaboration diagrams (see Figure 5.3 and Figure 5.5). Note that in contrast with a teacher, a student access his/her profile directly (not through Student Group).
50
AMIDST/WP1/N006
19: store Test Answer 12: do Test 1: select Test : Do Tes t UI : Student 2: select Test 11: selected Test 20: store Test Answer 16: test Body 15: get Test Body 13: get Test Body : Student Test Access Rights 18: test Body 17: test Body 14: get Test Body : Test Repository
: Test
3: select Test 10: selected Test 21: store Test Answer : Profile Repository 6: select Test : Student Group 7: selected Test 4: select Test 9: selected Test 22: store Test Answer 5: select Test : Test List
: Student Profile
8: selected Test 23: store Test Answer
Figure 5.7. Do Test collaboration diagram.
51
6. Analysis of UML
This section presents some results of the analysis performed over UML. It contains some observations regarding the UML notation, development process and supporting tools. The UML notation is very rich. It contains different types of diagrams that can be classified into structural and behavioural diagrams. The UML provides five different types of behavioural diagrams that cover different and often complementary insights of the behaviour of a system. However, in the modelling of systems with medium to high degrees of complexity we have the feeling that we can be overloaded with information, which can be very difficult to manage. Of course, we do not need to use all kinds of UML diagrams in every system we are modelling. Nonetheless, the more complex is a system, the more likely it is that one will need all the support to fully understand it. The proper combination of UML diagrams seems to be a matter of experience and subject to changes according to the problem at hand. An example of how the UML notation is sometimes inappropriate for managing the complexity of the system can be found in the use of collaboration diagrams. Collaboration diagrams can not handle independent sequences of messages in one diagram. This enforces the use of many, simple collaboration diagrams, leading to difficulties to manage the complexity of the development process. An alternative approach to deal with such problem can be found in, for example, Specification and Description Language (SDL) [3]. Figure 6.1 illustrates how SDL shows the sets of messages that are exchanged between several (SDL) blocks without carrying about their ordering.
getPersonalInformation, getTestList, getGradeList, getTestComments, selectTest, storeTestAnswers
personalInformation, testList, gradeList, testComments
Evaluate Test UI
getTestList getTestAnswers, addComment, setGrade,
Profile Repository
setAssignedTest
Assign Test UI
testAnswers testList
Figure 6.1. SDL diagram.
52
AMIDST/WP1/N006
The specification of complex behaviours using statechart and activity diagrams can also be problematic. These types of diagram provide roughly three kinds of constructs to describe the relationship between two elements of the diagram, either states or activities, viz., enabling, interleaving or parallelism and synchronisation. Guards are also provided in combination with the enabling construct, characterising some kind of deterministic choice. However, constructs such as non-deterministic choice and disabling are missing. The extension of statechart and activity diagrams with these two concepts could facilitate the design as a whole. These concepts have already proved being useful during the first phases of the design of complex systems, especially telematics systems and services (see for example [20]). A design methodology, as a prescription of how to apply the notations and to coordinate the activities during the development process, can be very specific to a particular task. Some methodologies for the development of market-oriented products, such as the Unified Process and Open Process [5], have been proved relevant. For the purpose of service design and development and component based modelling however, existing methodologies have to be adapted, as they do not fully meet the requirements of the design process. The Unified Process is specially designed to capture functional requirements. The modelling of Quality of Service (QoS) (or other non-functional) requirements within the Unified Process is handled by tagging them to the related use cases or mentioning them in a separate section. This can be done using a textual description since there is no special notation for representing QoS in UML. The Unified Process (or UML itself) lacks the ability to incorporate QoS requirements in the development of (distributed) services. Although attention is paid to non-functional requirements in the process by including them in use cases, this is not enough in situation where QoS requirements are pervasive throughout the whole system. If QoS requirements are more isolated within a sub-part of a system (for example: computational speed for a single use case) using simple textual descriptions can be an appropriate way of dealing with them. The UML notation is not equally well supported from different tools. This varies as we see tools that support only some of the diagrams (Structure Builder) or tools that do not fully support UML 1.1. Modelling tools do not always provide seamless integration with other categories of tools, such as development environments for Java and C++, for example. This feature is critical for projects that are intended to produce software in the form of prototypes or market product, and is essential to AMIDST. Table 1 presents a comparison among the analysis and design tools we have evaluated. The criteria are matched against the product by number of 'appreciation' checkmarks.
53
Table 1. Comparison between analysis and design tools.

Structure Builder Repository Notations Pick-lists Round-trip engineering Together J Rational Rose SELECT Enterprise System Architect
Functionality
Data modelling Component modelling Versioning Scripting Model navigation Documentation
Qualitative aspects
Ease of use Footprint/Resour ce consumption Availability
N/A
N/A
54
AMIDST/WP1/N006
7. Conclusion
This document presented an analysis of UML. To accomplish this task we focused in three different aspects. First, we briefly described the different UML diagrams: UML consists of a collection of diagrams and some guidelines to properly construct such diagrams. Then, we gave an overview of the Unified Process: the Unified Process was conceived based on UML, although UML itself is independent of any development process. Finally, we presented a survey concerning UML analysis and design tools. To glue all these aspects together we developed a case study in which UML was used in the development of an examining system. Although some problems may have been presented regarding the UML notation, it seems appropriated to be used within AMIDST. However, further investigation is still required with respect to the representation of QoS issues. The case study developed in this document used only a small part of the Unified Process: the requirement and analysis workflows. Additionally, due to small number of people involved in this exercise it is not possible to state that the Unified Process indeed provides the required functionality of a good development process: clear coordination between the persons involved in a development project and guidelines for work that has to be done. However, the Unified Process is more of a process template and flexible enough to be adapted according to the needs of any development project. More attention should be paid to QoS issues in the process as well. As we look at the different analysis and design tools with support of UML, we come to the conclusion that for best design performance in the AMIDST project we have to select several products. One of the most stable and fully supporting the UML notation tools is Rational Rose. One of the good tools that allow excellent integration with third party development environments is Together J. This product supports visual round-trip engineering that allows the developer to be a designer at the same time. Thus we nominate Rational Rose and Together J as our choices of UML supporting tools. We also have a very positive opinion on the most complex and encompassing design tool that we evaluated - System Architect/2001. It provides enterprise-wide modelling support, however it is heavy and too complex for the needs of AMIDST.
55
References
1. Booch, G., Object-oriented analysis and design. The Benjamin-Cunnings Publishing Company, Inc, California, USA, second edition, 1994. 2. Booch, G., Rumbaugh, J. and Jacobson, I. The Unified modelling language user guide. Addison Wesley (USA), 1998. 3. CCITT Z100, Functional Specification and Description Language (SDL), 1993. 4. Fowler, M. and Scott, K. UML distilled: applying the standard object modelling language. Addison Wesley (USA), 1997. 5. Graham, I., Henderson-Sellers, B. and Younessi, H. The Open Process Specification. Addison-Wesley, Harlow, 1997. 6. Harel, D. Statecharts: a Visual Formalis for Complex Systems. In Science of Computer Programming, Vol 8, pp. 231-274, 1987. 7. Jacobson, I., Booch, G. and Rumbaugh, J. The unified software development process. Addison Wesley (USA), 1999. 8. Jacobson, I., Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley, 1995. 9. Kobryn, C. UML 2001: a standardization odyssey. Communications of the ACM, 42(10) pp. 29-37, 1999. 10. OMG, OA&D CORBAfacility. OMG UML Specification v1.1, 1997. Available at http://www.omg.org/cgi-bin/doc?ad/97-08-09. 11. OMG, Object Constraint Language Specification. OMG UML Specification v1.1, 1997. Available at http://www.omg.org/cgi-bin/doc?ad/97-08-08. 12. OMG, OMG UML 1.3 specification, 1999. Available at http://www.omg.org/cgibin/doc?ad/99-06-09. 13. OMG, UML Extension for Business Modelling. OMG UML Specification v1.1, 1997. Available at http://www.omg.org/cgi-bin/doc?ad/97-08-07. 14. OMG, UML Extension for Objectory Process for Software Engineering. OMG UML Specification v1.1, 1997. Available at http://www.omg.org/cgi-bin/doc?ad/97-08-06. 15. OMG, UML Notation Guide. OMG UML Specification v1.1, 1997. Available at http://www.omg.org/cgi-bin/doc?ad/97-08-05. 16. OMG, UML Proposal to the Object Management Group. OMG UML Specification v1.1, 1997. Available at http://www.omg.org/cgi-bin/doc?ad/97-08-02.
56
AMIDST/WP1/N006
17. OMG, UML Semantics. OMG UML Specification v1.1, 1997. Available at http://www.omg.org/cgi-bin/doc?ad/97-08-04. 18. OMG, UML Summary. OMG UML Specification v1.1, 1997. Available at http://www.omg.org/cgi-bin/doc?ad/97-08-03. 19. OMG, What is OMG-UML and Why Is It Important? OMGs Press Releases, 1997. Available at http://www.omg.org/news/pr97/umlprimer.html. 20. Quartel, D. Action relations: basic design concepts for behaviour modelling and refinement. PhD thesis, University of Twente, Enschede, the Netherlands, 1998. 21. Rumbaugh, J., Blaham M., Premerlani, W., Eddy, F. and Lorensen, W. Object-oriented modelling and design. Prentice-Hall, Englewood Cliffs, 1991. 22. Rumbaugh, J., Jacobson, I. and Booch, G. The unified modelling language reference manual. Addison Wesley (USA), 1998. 23. Szyperski, C. Component Software: Beyond Object-Oriented Programming. AddisonWesley, 1998.
57
Abbreviations and acronyms

ER
JVM OCL OMG OMT
Entity Relationship
Java Virtual Machine Object Constraint Language Object Management Group
Object Modelling Technique Object-Oriented Softwate Engineering

Quality of Service Rational Unified Process Specification and Description Language Unified Modelling Language Version control system
OOSE
QoS RUP SDL UML VCS
58
AMIDST/WP1/N006
Appendix A: Electronic Examining System

This appendix contains the complete documentation of the electronic examining system. The structure of this appendix is as follows: Section A1 presents the use case diagram of the electronic examining system, while Section A2 depicts the conceptual diagram of the electronic examining system. Sections A3 until A9 show the use case realisation-analysis of the use cases presented in Section A1.
A1. Use case diagram

<<extends>>
Register Test
<<includes>> Assign Test
Teacher
<<includes>>
Access Test Repository
<<extends>> Evaluate Test <<extends>> <<includes>>
Consult Profile <<includes>>
Access Student Profile
Student
<<includes>>
Do Test
Actors
Student: A student is a person who takes exams and consults some personal and test related information that are stored in his/her profile. The student has limited access rights to the system. Teacher: A teacher is a person who assigns tests and grades the assigned tests. The teacher has full rights to the system.
59
Use cases
Access Student Profile: This use case is used to access the student profiles All student profiles are kept in a profile repository ordered according to the student groups that the student belongs. The teacher reads and writes the student profile, while the student reads the student profile. The student can write to his/her profile only the test results. ---------------------------------------------Detailed use case description (I): 1 - Teacher assigns a test to group of students. Detailed use case description (II): 1 - Teacher retrieves a student test answer 2 - Teacher adds a comment to the test answer. 3 - Teacher grades the test answer. PS: 2 is optional. 1/2/3 can be executed in any order. Detailed use case description (III): 1 - Student browses his/her personal information. 2 - Student browses his/her test list. 3 - Student browses his/her grade list. 4 - Student browses his/her test comments. PS: 1/2/3/4 can be executed in any order. Detailed use case description (IV): 1 - Student selects a test to do. 2 - Student does a test, storing the test result into his/her personal profile.
Access Test Repository: This use case is used to access the test repository. The teacher can read and write to the test repository, while the student can read from the test repository only the tests that are assigned to his/her profile. ---------------------------------------------Detailed use case description (I): 1 - Teacher stores a test into the test repository. Detailed use case description (II):
60
AMIDST/WP1/N006
1 - Teacher browses the tests available in the test repository. Detailed use case description (III): 1 - Teacher retrieves a test from the test repository. Detailed use case description (IV): 1 - Student reads a test from the test repository with restrictions.
Assign Test: This use case is used to select a test from the test repository and assign the selected test to a group of students. --------------------------------------------Detailed use case description: 1 - Teacher browses test list/repository 2 - Teacher select a test and assign it to a group of students. The selected test is added to the test list of the group of students.
Consult Profile: This use case is used to consult a student personal profile. The student profile contains the student personal information, the tests to be done, the test answers and the grades received so far. The student profiles are stored in a profile repository. A student has access rights only to his/her personal profile. ------------------------------------------Detailed description: 1 - Student browses his/her personal information. 2 - Student browses his/her assigned test. 3 - Student browses his/her grades. 4 - Student browses his/her test comments. PS: 1/2/3/4 can be executed in any order.
Do Test: This use case is used to do a test. The student selects one of the tests from his/her profile. The student retrieves this test from the test repository. Then, the student does the test and submits the test answers, which are stored in his/her profile. ---------------------------------------------Detailed use case description:
61
1 - Student selects a test from the test list. 2 - Selected test is loaded from the test repository. 3 - Student does the test. Test answers are stored stored in the student profile.
Evaluate Test: This use case is used to evaluate a performed test. The evaluation of a test consists of making comments concerning the answers provided and grading the test. The teacher first selects a test to be evaluated and then retrieves from the student profiles some or all the answers provided for that test. ---------------------------------------------Detailed description: 1 - Teacher retrieves the test from the test repository. 2 - Teacher retrieves student test answers from the profile repository. 3 - Teacher adds comment to the student test 4 - Teacher grades the student test PS: 3 is optional
Register Test: This use case is used to register and store a test into the test repository. -------------------------------------------Detailed use case description: 1 - Teacher registers a test to the test repository. The test is stored into the test repositor.
62
AMIDST/WP1/N006
A2. Conceptual Diagram
Teacher
Student
Register Test UI
Assign Test UI
Evaluate Test UI
Do Test UI
Consult Profile UI
Test Repository Student Profile Access Rights II
Student Test Access Rights Test
Profile Repository
Test List
Student Group
Student Profile
Personal Information
Test Evaluation
Student Test Answer
Test Comment
Grade
63
A3. Use Case Realisation-Analysis: Access Student Profile

Class diagram
Evaluate Test UI Assign Test UI Consult Profile Do Test UI
UI
Student Profile Access Rights II Profile Repository
Student Group
Test List
Student Profile
Collaboration diagram I
: Consult Profile UI : Do Tes t UI
: Assign Test UI
: Evaluate Test UI
1: set Assigned Test
2: set Assigned Test : Student Group : Student Profile
64
AMIDST/WP1/N006
Collaboration Diagram IIa

: Do Tes t UI
: Assign Test UI
: Evaluate Test UI
1: get Test List 4: test List
3: test List 2: get Test List
: Student Group
: Student Profile
Collaboration Diagram IIb

: Assign Test UI
: Evaluate Test UI
4: test Answer
1: get Test Answer
3: test Answer 2: get Test Answer
: Student Group
: Student Profile
65
Collaboration Diagram IIc

: Assign Test UI
: Evaluate Test UI
1: add Comment
2: add Comment : Student Group
: Student Profile
Collaboration Diagram IId

: Do Tes t UI
: Assign Test UI
: Evaluate Test UI
1: set Grade
2: set Grade : Student Group : Student Profile
66
AMIDST/WP1/N006
Collaboration Diagram IIIa

6: personal Information : Assign Test UI : Evaluate Test UI
1: get Personal Information
5: personal Information
3: get Personal Information 4: personal Information
: Student Group
: Student Profile
Collaboration Diagram IIIb

6: test List : Assign Test UI : Evaluate Test UI
1: get Test List
5: test List
2: get Test List
3: get Test List 4: test List
: Student Group
: Student Profile
67
Collaboration Diagram IIIc

6: grade List : Assign Test UI : Evaluate Test UI
1: get Grade List
5: grade List
2: get Grade List
3: get Grade List 4: grade List
: Student Group
: Student Profile
Collaboration Diagram IIId

: Do Tes t UI
6: test Comments : Assign Test UI : Evaluate Test UI
1: get Test Comments
5: test Comments
3: get Test Comments 4: test Comments
: Student Group
: Student Profile
68
AMIDST/WP1/N006
Collaboration Diagram IVa

6: selected Test : Assign Test UI : Evaluate Test UI
1: select Test
5: selected Test 2: select Test
3: select Test 4: selected Test
: Student Group
: Student Profile
Collaboration Diagram IVb

1: store Test Answer : Assign Test UI : Evaluate Test UI
2: store Test Answer : Profile Repository
3: store Test Answer
: Student Group
: Student Profile
69
A4. Use Case Realisation-Analysis: Access Test Repository

Class Diagram
Register Test UI
Assign Test UI Test Repository Evaluate Test UI
Do Test UI Test Student Test Access Rights
Collaboration Diagram I
: Register Test UI
1: store Test
: Assign Test UI
: Test Repository
: Evaluate Test UI : Test
: Do Tes t UI
: Student Test Access Rights
70
AMIDST/WP1/N006
Collaboration Diagram II
: Register Test UI
: Assign Test UI
1: browse Tests
: Test Repository
2: tests : Evaluate Test UI : Test
: Do Tes t UI
: Student Test Access Rights
Collaboration Diagram III

: Register Test UI
: Assign Test UI 1: get Test
: Test Repository
: Evaluate Test UI
4: test
3: test
2: get Test
: Test : Do Tes t UI : Student Test Access Rights
Collaboration Diagram IV
: Register Test UI
: Assign Test UI
: Test Repository
: Evaluate Test UI
2: get Test Body
4: test Body 5: test Body
3: get Test Body
: Do Tes t UI
1: get Test Body : Student Test Access Rights 6: test Body : Test
71
A5. Use Case Realisation-Analysis: Assign Test

Class Diagram
Assign Test UI Test Repository
Teacher
Test Profile Repository
Student Group
Test List
Student Profile
Collaboration Diagram
6: assign Test 1: browse Tests : Assign Test UI : Teacher 7: assign Test 4: tests 3: browse Tests 2: browse Tests : Test Repository
5: tests
: Test : Profile Repository
8: assign Test
9: assign Test : Student Group : Test List
72
AMIDST/WP1/N006
A6. Use Case Realisation-Analysis: Consult Profile

Class Diagram
Consult Profile UI
Profile Repository
Student
Student Group
Test List
Student Profile
Personal Information
Test Evaluation
Student Test Answer
Test Comment
Grade
73
1: browse Personal Information 2: get Personal Information : Consult Profile UI 9: personal Information : Student 8: personal Information 3: get Personal Information : Student Profile Access Rights I
: Student Group
7: personal Information
: Student Profile
6: personal Information 5: get Personal Information
: Personal Information
74
AMIDST/WP1/N006
1: browse Test List : Consult Profile UI 11: test List : Student 10: test List 3: get Test List 2: get Test List : Student Profile Access Rights I
7: test List : Test List 6: get Test List : Student Group : Profile Repository
9: test List
4: get Test List
8: test List : Student Profile 5: get Test List
75
1: browse Grade List : Consult Profile UI
2: get Grade List : Student Profile Access Rights I 11: grade List
: Student 10: grade List 3: get Grade List
: Student Group
9: grade List
4: get Grade List
: Student Profile
8: grade List
5: get Grade List
: Test Evaluation
6: get Grade 7: grade
: Test Comment
: Grade
76
AMIDST/WP1/N006
1: browse Test Comments : Consult Profile UI : Student
2: get Test Comments : Student Profile Access Rights I 11: test Comments 3: get Test Comments
10: test Comments
: Student Group
9: test Comments
: Student Profile
8: test Comments
: Test Evaluation
7: comments
6: get Comments
: Test Comment
: Grade
77
A7. Use Case Realisation-Analysis: Do Test

Class Diagram
Student Test Access Rights
Do Test UI
Test Repository
Student
Student Profile Access Rights II Test
Profile Repository
Student Group
Test List
Student Profile
Test Evaluation
Student Test Answer
Test Comment
Grade
78
AMIDST/WP1/N006
19: store Test Answer 12: do Test 1: select Test : Do Tes t UI : Student 2: select Test 11: selected Test 20: store Test Answer 16: test Body 15: get Test Body 13: get Test Body : Student Test Access Rights 18: test Body 14: get Test Body
: Test Repository
17: test Body
: Test
3: select Test 10: selected Test 21: store Test Answer : Profile Repository 6: select Test : Student Group 7: selected Test 4: select Test 9: selected Test 22: store Test Answer 5: select Test : Test List
: Student Profile
8: selected Test 23: store Test Answer
79
A8. Use Case Realisation-Analysis: Evaluate Test

Class Diagram
Evaluate Test UI
Test Repository
Teacher
(from Use Case Vi ew)
Profile Repository Test
Student Group
Test List
Student Profile
Test Evaluation
Student Test Answer
Test Comment
Grade
1: retrieve Test : Evaluate Test UI 5: test : Teacher 4: test 3: get Test 2: get Test : Test Repository
: Test
80
AMIDST/WP1/N006
1: get Test Answer : Evaluate Test UI : Teacher 9: test Answer 8: test Answer : Student Group 3: get Test Answer : Profile Repository 2: get Test Answers
4: get Test Answer : Student Profile 7: test Answer 5: get Test Answer 6: test Answer
: Test Evaluation
81

1: add Comment : Evaluate Test UI : Teacher 2: add Comment
: Student Group 3: add Comment
4: add Comment
: Student Profile
5: add Comment
: Test Evaluation
6: add Comment
: Test Comment
: Grade
82
AMIDST/WP1/N006
1: set Grade : Evaluate Test UI : Teacher 2: set Grade
: Student Group 3: set Grade
4: set Grade
: Student Profile
5: set Grade
: Test Evaluation
6: set Grade
: Test Comment
: Grade
83
A9. Use Case Realisation-Analysis: Register Test

Class Diagram
Register Test UI Test Repository
Teacher
Test
1: register Test : Register Test UI : Teacher 2: store Test : Test Repository
84
Page: 15
[RPo.1]Insert
reference to the section on use case diagrams. reference to the UML book here reference to the UML book here
Page: 15
[RPo.2]Insert
Page: 18
[RPo.3]Insert

Deliverable D1.1.2: Analysis of UML

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Deliverable D1.1.2: Analysis of UML

Uploaded by

Copyright:

Available Formats

Deliverable D1.1.

REFERENCE DATE OF ISSUE ACCESS RIGHTS STATUS EDITOR AUTHOR[S]

ANALYSIS OF UML AND RELATED LANGUAGES

30/06/1999 06/08/1999 20/10/1999 24/11/1999

ANALYSIS OF UML AND RELATED LANGUAGES

ANALYSIS OF UML AND RELATED LANGUAGES

2. Unified Modeling Language

2.1 Structural diagrams

ANALYSIS OF UML AND RELATED LANGUAGES

Multiplicity (zero or more objects)

Role Generalis ation Class 0..1

Multiplicity (one or zero objects)

Node 2 Object 1 Component 2 Object 2

Figure 2.3. Deployment diagram.

2.2 Behavioural diagrams

ANALYSIS OF UML AND RELATED LANGUAGES

<<extends>> Use case 1 Use case 2

Generalis ation relationship

ANALYSIS OF UML AND RELATED LANGUAGES

State C State B do / Activity1

Event1 [Guard1] /Action1

[Guard3] [Guard1] Activity B

ANALYSIS OF UML AND RELATED LANGUAGES

[Condition1] Message 3 [Condition2] Message 4

1: Message 1 Object 1 2: Message 2 Object 2

3: Message 3 3.1: Message 4 3.2: Message 5 Object 3

Figure 2.8. Collaboration diagram.

2.3 UML 1.3 and beyond

ANALYSIS OF UML AND RELATED LANGUAGES

3. The Unified Software Development Process

ANALYSIS OF UML AND RELATED LANGUAGES

Figure 3.1. The waterfall model for software development.

ANALYSIS OF UML AND RELATED LANGUAGES

Figure 3.3. Structuring of the Unified Software Development Process.

Requirements Use-case model

Analysis Analysis model

ANALYSIS OF UML AND RELATED LANGUAGES

3.3 Core workflows

ANALYSIS OF UML AND RELATED LANGUAGES

ANALYSIS OF UML AND RELATED LANGUAGES

ANALYSIS OF UML AND RELATED LANGUAGES

Another development cycle may follow this phase.

ANALYSIS OF UML AND RELATED LANGUAGES

4. UML design and analysis tools

ANALYSIS OF UML AND RELATED LANGUAGES

ANALYSIS OF UML AND RELATED LANGUAGES

4.2 Rational Rose 98 SR1

ANALYSIS OF UML AND RELATED LANGUAGES

4.3 SELECT Software

ANALYSIS OF UML AND RELATED LANGUAGES

SELECT6 does not support XMI. UML 1.1 Support

Scripting is not supported by SELECT6 environment.

4.4 System Architect/2001

ANALYSIS OF UML AND RELATED LANGUAGES

SA offers versioning support through the integrated product PVCA. Scripting

ANALYSIS OF UML AND RELATED LANGUAGES

TJ supports only the JavaBeans component technology. Versioning support

Price (US$) 3295.00 4090.00

4.6 Structure Builder

ANALYSIS OF UML AND RELATED LANGUAGES

Data modelling is not supported in SB. Component modelling

ANALYSIS OF UML AND RELATED LANGUAGES