Models are used for several purposes. We believe that some of the most important are:

Transcription

1 Course: Objekt orientated programming, extending course Supervisor: Authors: Marc Mikael Karlsson, Sandberg Fredrik Fahlman and Martin Mileros Mälardalens Högskola, spring-2000 UML Contents 1. Introduction... 3

2 1.1 Purpose and outline Models UML History Goals of UML Scope of UML Structure of UML Structural views Static view Class diagram Object diagram Use case view Use case diagrams Implementation view Component diagram Deployment diagram Dynamic views State-machine view Statechart diagrams State Events and Signals Transitions Activity view Activity diagram States and Transitions Decisions, Forking and Joining Swimlanes Object flow Interaction view Collaboration and Interaction Sequence diagram Collaboration diagram Pattern structure Model Management view Packages Relationships Subsystems Extension Mechanisms Constraints Tagged values Stereotypes Notation Example Use case diagram Class diagram Component diagram Deployment diagram Interaction diagrams Statechart diagram Activity diagram Packages Authors reflection References Abstract When building software systems the need for precise models have become increasingly important, especially when large systems are to be implemented. The development of modelling languages to provide useful models 2

3 have resulted in a number of languages supporting different aspects in different ways. In the mid 90 s the three of the developers, Grady Booch, James Rumbaugh and Ivar Jacobsen, to form a uniform languages out of their respective languages. This was the start for the development of the Unified Modelling Language (UML). This document describes the different parts of the language and how it is used to model a system. 1 Introduction 1.1 Purpose and outline As a part of the course Object oriented programming, continuation course, we were to collect information and write a report within the subject. We choose to enter deeply into the world of UML. Since we had used a limited part of the UML in previous software design issues and found it useful and simple to use, we thought it to be interesting to learn more about it. The purpose of this document from our point of view is to provide an introduction to the modelling language UML. It is intended mainly for people who have little or no experience of modelling languages and want/need to learn how it is used in designing software. The reader is supposed to have at least some knowledge in object oriented concepts to fully understand the information presented in this document. This document is divided into six sections. The first gives a brief description of modelling and the history of UML. Following sections is mainly concerned with the different parts of UML. This includes describing the major areas; structural, dynamic, model management and extensibility. The next section shows an example of how to use UML to design a system. Finally we share our opinion on UML. This document is not intended as a complete manual of UML. To get a more detailed view of UML we recommend the reader to search among the publications listed in the reference section. 1.2 Models At almost every time something is to be built ( e.g. a house or a car) the engineers or developers make drawings to describe the looks and behaviour of the construction. These drawings will act as models for a specific thing. Rumbaugh, Jacobson and Booch describes [1] a model as...a representation in a certain medium of something in the same or another medium. This may seem cryptic and is best described with an example. At a construction site the blueprint will be equivalent to the model. Another example is the creation of a 3D-Chess game. In this case the model could be a real chessboard including it s pieces. A model is often broken down into several parts, called views, describing different structural and dynamic properties. To increase the understanding of a model, most of the elements in a model is described graphically, with symbols or pictures. Models are used for several purposes. We believe that some of the most important are: to make a project more easily foreseeable and comprehensible for all involved parts. to simplify large and/or complex systems. to being able to examine different solutions at a low cost. helps visualizing a project/system. A model contain two major aspects, semantics and notation. The semantics describes the properties of the parts that a model consists of. An example of this could be a part of a model that specifies where you may put a lightswitch in a house. The notation in this case would be how to draw a lightswitch on the blueprint, i.e. the notation define how to visualize a specific part of a model. A modelling language is the way to create models. As any other language a modelling language has its own vocabulary describing the different elements that can be used and grammar to tie these elements together to form 3

4 a model. To define a correct language, the use of a model might be necessary to get it precise and unambiguous, this model of the model is called meta-model. The probably most widely used modelling language today is the UML, and this is the subject for the rest of this report. 1.3 UML History Object-oriented modelling languages first were explored in mid-70 s. But it was in the late 80 s and 90 s that it really became popular because during that time the object-oriented methods increased explosively. Although many different modelling languages were defined it was hard to find one that met the demands of many different uses. Most notably of these were Booch, Ivar Jacobson s OOSE and Rumbaugh s OMT, each of which were a complete method. It was when these three joined forces in the mid 90 s that the development of UML began. The motivation to create UML was initially for three reasons. As their independent work were already evolving towards each other it seemed more reasonable to work together. Also, for engineering-projects this would simplify the development by only using one modelling language instead of several for different parts of a system. The last reason was that experience from the three languages would decrease the problems they d had in developing each language, and also to provide new features that none of the previous had handled. The first version (0.9) of the UML was released in 1996 and continuously new and improved versions have been established. The up to date version is UML Goals of UML The following list describe the primary goals set, in designing and creating the UML: 1. Provide a visual modelling language, so that development and exchange of models will be easy and meaningful. It should be suitable for use with a variety of applications. 2. Provide mechanisms for extensibility and specialization to extend the main concept. Add new concepts and notation that the main definition do not support, without changing the core unnecessarily. 3. Provide a modelling language independent of programming languages and development processes. 4. Provide a detailed and formal definition of the language, to prevent users from developing models in different ways. 5. Encourage the development and growth of object-oriented tools. 6. Support concepts such as patterns, frameworks, components and collaborations. 7. Take advantage of approved methods and best practices in the industry. 1.5 Scope of UML UML is a modelling language for: Specifying - What is required of a system and how a system may be realized. Visualizing - To describe a system visually before it is realized. This can be of great importance to fully understand a system or hierarchy, especially for people who are not directly connected to the construction. Constructing - Similar to a blueprint. A model created from the UML can be generated into a programming language. Documenting - Continuously gather experience and knowledge about a system during the development. The UML is primarily constructed to be used in large software systems such as, banking services, science projects and telecommunication. Although the main purpose is to make software engineering easier, UML is detailed and precise enough to be used in other systems as well. Examples of such applications could be the modelling of workflow at a car factory or designing hardware. 4

5 1.6 Structure of UML The UML building blocks can be sorted into three categories; (1)things, which are tied together by (2)relationships to form (3)diagrams. These blocks can be used to form different structures, which we have chosen to group into four main categories; structural views, dynamic views, model management and extension mechanisms. Each of these include a number of concepts, including blocks (1) - (3) and rules for their use. There are mainly nine diagrams in the UML describing different aspects of a model. These are: Class diagram Use Case diagram Component diagram Deployment diagram Object diagram Statechart diagram Activity diagram Sequence diagram Collaboration diagram structural dynamic There is also a kind of diagram that is not mentioned as a diagram in the UML specification [3], consisting of packages tied together. This is a part of model management. The extension mechanisms include ways to extend the language without changing the fundamental structure of the language. Although this is a part of UML the use of them will create a dialect of the language. Some of the building blocks in UML, such as diagrams, can describe part of another and some blocks can be composed of one or several other blocks. The following sections will describe the views mentioned above and their corresponding things, relationships and diagrams in detail. 5

6 2. Structural views Describes the things in the system and their relationships together. The classifier describe things in a system. One of the most important detail in specifying the attributes and methods of a classifier is the visibility. With visibility you know if a classifier can be used by other classifiers. There are three kinds of visibility. We have chosen to give an example with classes. Public Protected Private Any outside class have access to the attributes and methods that are declared public within a class. This visibility is displayed by a + before the attributes/methods. Any offspring of a class have access. This visibility is displayed by a # before the attributes/methods. Only the class itself have access. This visibility is displayed by a - before the attributes/methods. Fig Displaying the visibility of a class Some of the relationships are different for different views, but some are the same, so we describes the relationships here and only list them in each view. All diagrams in the structural part contains notes and constraints. A note is simply used to give information about an element. A constraint is an extension of the semantics of an element that allows a user to add new rules or to modify existing ones. Constraints is described more detailed in the extension section. Fig Note notation. Relationships There are four kinds of relationships. Dependency. Dependency is a relationship between two things and if one thing is changed then it will affect the other. One example of this would be the class event, which may affect other things (a window perhaps). Dependency is most often used to show that one class uses another class as an argument in a method. A dependency is drawn as a dashed line and sometimes with a label connected to it that shows which dependency it is. The arrow is pointed to the thing that affects the other thing. Association. Association shows the link between things. An association that describe exactly two things is called a binary association. The most information of an association relationship is attached to its ends. This 6

7 information can be a * (means 0..many), a number (1 means one) or an interval (0..1 means zero to one). This information is called multiplicity. Association that connect more than two things is called n-ary association, but this is very uncommon. An n-ary association is displayed as a large diamond (compared to aggregate and composition) with a path to each class that participate in the association. A special case of association is aggregate. Aggregate describes that a thing has another thing and the representation of an aggregate looks like a diamond. A special form of aggregate is composition, that is more limited than aggregate. Composition is drawn as a filled diamond. The diamonds are drawn nearest the thing that has the other. Generalisation. Generalisation describes that a child shares a behaviour with its parent. The parent gives a general description while the child gives a more specific description. This is called that the child inherit the parent. This relationship is displayed by a line with a triangle (like an arrow) that is pointing towards the parent. Realisation. Realisation describes relationships between two things where one of the things decide what to do and the other thing make sure that it will be done. There are two places where realisation occur. The first place is between an interface and a component or a class. The second place is between a use case and the collaborations that realise it. Realisation is graphically displayed as a dashed line and a triangle (like an arrow) that is pointing towards the thing that is deciding what to do that. This form of relationship is usually used with interfaces. The relationships are graphically displayed here. 1. Dependency 2. Association Aggregate Composition 3. Generalisation 4. Realisation 2.1 Static view The main part of the static view are classes and their relationships. This view supports the services the system should provide to its end users Class diagram A class diagram is a graph of classifiers connected by their relationships. The classifiers in a class diagram are classes, interfaces and data types. Class diagrams are the most used diagram to model object-oriented systems. The use of class diagrams is to model the static view of a system. This involves modelling the vocabulary of the system, modelling collaboration or modelling schedules. To model the vocabulary is the same as making a decision about which abstractions that are a part of a system. Modelling collaborations is to show how the vocabulary work together, since a class not stands alone. The use of modelling schedules could be to model schedules for storing blueprints in an object-oriented database. Classifier Class. A class is a descriptor for similar kinds of objects. The class defines the state and the behaviour of these objects. State is described by attributes and associations. The attributes represents some property that is 7

8 shared by all objects of a class. For example, every wall has a height weight and thickness. The data values for the object of a specific class are the objects attributes. The associations are used for connections between objects. The objects behaviour are described by the implementation of an operation called method. There are three ways of displaying a class. The one to use in an early stadium is the notation which only display a box and the class name in it. The second is the one that is shown in figure 2.3 and the third displays a class with implementation details. The class name should begin with an uppercase letter and the attributes and methods should begin with a lowercase letter. If there is an abstract class, then the class name should be displayed in italics. Fig Class notation Interface. An interface gives the description of an objects behaviour. It is a named collection of methods used to specify a service of a class. An interface most often only specifies a part of the behaviour of a class. An interface do not have attributes or states. It only has methods. Class/Classes implements the methods that the interface give. The interface itself have no implementation. An interface is displayed by a circle attached to a classifier with a solid line. This indicates that the class provides all of the methods that the interface gives. A class that uses or requires the methods of an interface are attached by a dashed arrow pointing at the circle. This class do not have to use all of the interface methods. Figure 2.4 shows the notation of an interface. Another way of displaying an interface is a rectangle with the keyword <<interface>>. This shows a more detailed form of the interface (i.e. displaying its methods). Interfacename Fig Interface notation Data type. Data types are numbers, strings and enumerated values. The enumeration values are true or false. Relationships The relationships on a class diagram are dependency, association and generalisation Object diagram An object diagram shows the instances that can be made of a class and the relationships among the instances (at a certain point in time). Object diagram are mainly used when you wish to illustrate complicated data structures. The object diagram is a special case of a class diagram. Object An object is an instance of a class. The notation for an object is similar to the notation for a class except that the name of the instance is to be underlined. 8

9 2.2 Use case view The use case view shows the functionality within a system from the outside Use case diagram Use Case Diagram shows the relationships between an actor and a use case. The use case represent the behaviour of a system. There are typically two ways of using use case diagrams. The first is to model the context of the system and the second is to model the requirements of a system. To model the context of a system means to show things that is in a system and things that is outside the system and their relationships. For example, in a credit card system, the things in the system are accounts and transactions. A thing outside the system might be the credit card owner. To model the requirements of a system is to specify what a system should do, not how the system should do it. It s like a black box where you can see what s outside the system and how the system reacts on the things outside, but you can t see what s inside the black box. Classifier Use case. A use case is a unit of functionality that is provided by a system. This unit is expressed by sequences of messages exchanged by the unit itself or an actor/actors. A use case does something that an actor can benefit by, such as calculate a result, generate a new object or change the state of another object. One example of a use case would be a part of a banks issues, to process loans, for instance. The notation of a use case is an ellipse containing the name of the use case(fig. 2.5). The name could be placed under the ellipse and the name of an abstract use case may be shown in italics. Fig use case notation Actor. An actor represents a part that interact with the use cases. The actor interacts with the use cases by exchanging messages. An example of an actor would be the customer in the bank. The notation of an actor is like a person drawn by lines(fig. 2.6). An actor may also be represented as a rectangle with the keyword <<actor>>. Actor name Fig actor notation Relationships There are three relationships on a use case diagram. These relationships are dependency, generalisation and association. The dependency relationships is between use cases and is either an include or extend relationship. An include relationship from use case A to use case B indicates that A will have all the behaviour that B contains. The dependency relationship is labelled with the keyword <<include>>. The extend relationship between use 9

10 cases is used when a use case may be extended with the behaviour of another use case. The dependency relationship is labelled with the keyword <<extend>>. 2.3 Implementation view The implementation view shows the source code structure and the run-time implementation structure. The source code structure is shown in component diagram and the run-time structure is shown in deployment diagram Component diagram The component diagram shows the dependencies among a set of components. There are three kinds of components, source code components, binary code components and executable components. Classifier Component. A component is a physical part of a system that is replaceable. The name of the component must have a unique name so that it can be separated from other components. The name alone is called a simple name. A path name shows the components name and where that component lies (i.e. the packet) separated by two colon. A component is represented by a rectangle with two small rectangles intersecting the left side of the rectangle. The components name is located in the rectangle. An executable components notation is shown by figure 2.7. Simple name - Mymail Path name - Mymail : Mailer Fig executable component notation Relationships There are four relationships in a component diagram. These are Dependency, generalisation, realisation and association Deployment diagram A deployment diagram shows the configuration of run-time processing elements and the components that live on them. You use deployment diagram when you want to show the topology of a hardware on which your system executes. Classifier Node. A node is an object that represent a processing resource. It generally has its own memory. Every node must have a name that separates it from other nodes. The name can be a simple name or a path name. A node is much like a component, both have names, may be nested, may be participants in interactions. There are some significant differences though. The most important one is that components are things that take part in the execution of a system, while nodes are the things that executes the component. A node is displayed as a 3- dimensional cube (figure 2.8). 10

11 Fig node notation Relationships The relationship that is used with nodes is the association relationship. This relation would represent a connection among nodes, such as an Ethernet connection or a shared bus. 11

12 3. Dynamic views There are three views that describe dynamic behaviour of elements in UML. These are; state-machine view, activity view and interaction view. The corresponding diagrams for which are statechart diagram, activity diagram and collaboration/sequence diagrams respectively. The diagrams describe behaviour of elements, such as objects but also larger units as part-whole constructions. They also describe how different elements interact and collaborate to provide given functionality. 3.1 State-machine view This view describes the dynamic behaviour of an object or a method. In UML this view is illustrated with statechart diagrams Statechart diagram A state-machine is built with states and transitions. Together they create a graph which correspond to outside events with a behaviour described by the different states. The statechart diagram is the graphical representation of a state-machine in UML. The most common graphical parts of a statechart diagram is state and transition State A state represents a certain condition in an elements (e.g. an object) life-cycle. The notation for a state is a rectangle with rounded corners(see figure 3.1). A state includes one or more identifiers (a.k.a. compartments). These can be one of the following: a name compartment which describes the name of the state. a internal state compartment which holds information about internal actions. The format for this is: action-label / action-expression In addition some special actions may be added to an internal state compartment. These include actions performed on entry and exit of the state. There is also a label for actions performed during the time in state or until it is finished. The syntax for these are: entry / action-expression, for action on entry. exit / action-expression, for action on exit. do / action-expression, for ongoing activity. Fig.3.1 State symbol with name compartment and internal state compartment. A state can be a composite of substates to provide a more detailed view of the states structure. The notation for this is to extend the state with an extra compartment in which the substate diagram is shown. If several concurrent substates (that is states that will execute in parallel) are to be represented the compartment is divided into subcompartments using dashed lines, indicating which states are concurrent. An initial state(i. e. start-state) is represented with filled circle and an ending state(i. e. stop-state) is shown as an initial state with an additional circle surrounding it Events and Signals 12

13 An event can in this context be described as an occurrence of stimuli that triggers a transition to be executed. This may appear in different forms such as signals, call events and time/change events. A signal is an object that is thrown, asynchronously, by an object and caught by another. A constantly recurring example of this would be an exception. In UML a signal can be declared using a class symbol. The keyword <<signal>> indicates that a specific class symbol describes a signal, and parameters are shown as attributes. A declared signal can be a generalization of another signal. This is done using the notation as a regular generalization. A call event unlike a signal is a synchronous event that represents the dispatch of an operation. While a call event is invoked on demand, time and change events are not. They are instead invoked in the presence of a certain condition, for example after 3 minutes(time event) or when temperature is 20 degrees (change event). In UML the following strings is used to indicate what event that triggers a transition: event-name ( comma-separated-parameter-list) is used for call events and signals. Each parameter is described using a string on the format: parameter-name : type-expression. after(time-expression)/action is used for time events. when ( boolean-expression) / action is used for change events Transitions A simple transition is a relationship between two states that indicates that an object may switch from one state to the other if specified conditions are full-filled. The initiator of a change of state is an event which triggers the current transition. The notation for such a transition is a solid arrow drawn from the preceding state to the following. The cause of transition is expressed in the following way: event-signature [ guard-condition ] / action-expression ^ send-clause There are also more complex transitions. These describe transactions that have multiple sources or destinations. Complex transitions are shown in a diagram as a short line at right angles to the transition splitting it up in two or more transition-arrows pointing at their corresponding states. This fork is used to make a transition to concurrent states, which then will be initiated and activated at the event. Fig.3.2. Complex transitions, start and stop states and concurrent states. When transitions are drawn to composite or/and complex states the transition-arrow can either be drawn to the composite state boundary, an initial state within it or directly to a substate included. For transitions exiting a composite state have the similar notation. An abstraction of this may be made if the internal states are not to be shown. Transitions to the state boundary will still look the same as described above, but transitions directly to internal states will be ended with a short line at right angles to the transition at a point inside the composite state. 13

14 3.2 Activity view The activity view is in some ways similar to the state-machine view, but instead of representing states in an object the activity view is concerned with representing states of workflow and computions in activity graphs. The activity view is implemented in activity diagrams Activity diagram An activity diagram consists of symbols similar to those used in a regular statechart diagram, but some slight changes. There are activity states, (also referred to as action states), transitions, decisions and fork / synchronization points. The transitions in an activity diagram is triggered by the completion of the preceding state. Much of the notation for activity diagram can be seen in figure States and Transitions There are mainly two kinds of states used in an activity diagram; action states and activity states. An action state represents the execution of an atomic action. It has at least an entry action and one transition going out of the state. An action state is shown as a rectangle with rounded ends. Inside the symbol the action of the state is written. This may be expressed in natural language, but also pseudo code or programming languages may be used. A distinction between action states and activity states (a.k.a. subactivity states ) is that the latter may be further decomposed, i.e. the activity may be represented by another activity diagram, providing a more detailed view of the state. The notation is similar to action states, except that it may introduce additional diagrams. This is often indicated by a pair of parenthesis (), following the activity expression. Another and better way is to indicate the composite with an additional icon in the lower right corner representing the subactivity. The completion of the entry action and possibly other actions is the initiator of a transition. Transitions, internal or not should not be triggered by outside events but by the completion of an activity/action. The notation for regular transitions is similar to a statechart diagram Decisions, Forking and Joining A decision is used to indicate that there is more than one possible transition after the completion of an activity state. In the choice of path(transition) a guard condition is used (usually a Boolean expression) to separate the possible ways. The notation for decisions are a diamond-shaped box that has one in going and two or more paths going out of it. The symbol can also be used to merge decision branches together. In this case they are referred to as merges. The decision may be clarified by conditions indicating which path to choose. Almost always concurrent flows will appear that has to be modelled in some way. In an activity diagram forking and synchronization(two or more transitions join) is shown as a thick horizontal line to/from which flows go. A fork indicates that that following activities are done in parallel, while a join indicates that Fig.3.3. Activity diagram two or more activities result in the same following activity Swimlanes 14

15 Organizing activities into swimlanes is a way to make the diagram more foreseeable. The purpose of using swimlanes is to put together activities that is closely related (e. g. belong to the same class or object). Every state should belong to exactly one swimlane. Visually this is done by splitting the activity diagram with vertical lines so that every swimlane is separated from each other. Each swimlane represents one part of the whole activity diagram. A name should be associated with every swimlane. There are no restrictions about how the swimlanes should be organized. Transitions may cross swimlanes Object Flow Actions operate on or by an object. This may be shown in an activity diagram. An object either is initiated by an action or is used by an action. Objects are shown as a rectangle including name, and usually also the current state of the object. This is particularly important when the same object appear more than once in a diagram. To illustrate the flow using objects a dashed arrow is drawn from a state to an object or from the object to a state. An important aspect is that when an object flow tie together two states the regular solid arrow between the states is left out. 3.3 Interaction view Interaction is used to implement behaviour into objects. There are several ways to describe the interaction of objects. One is used in a state-machine, which is concerned with describing interaction within a specific object. An other way is to refer to the interaction among a set of objects. It is this second approach that is described in this view. Unlike a state machine which describe a very detailed view, this view provides more of an overview. The interaction view is shown with interaction diagrams. They consists of to kinds of diagrams; sequence diagrams and collaboration diagrams Collaboration and Interaction A collaboration describes a set of objects that interact to achieve a specific behaviour, within some part of a system. It consists of slots that at run-time contain objects and links. These slots are referred to as roles. There are two kinds of roles; classifier roles and association roles. The first mentioned describe conceivable objects which may participate in the execution of a collaboration, while association roles describe the links that can participate. Collaborations consists of both structural and behavioural aspects. The structural part describe the set of elements and relationships within a system. The behavioural part is referred to as interaction. Interaction describes the different messages that is exchange within a collaboration Sequence diagram A sequence diagram describes how different classifier roles interact e.g. exchange messages, to produce a specific behaviour. The notation for a sequence diagram can be more or less detailed, but common for all is that the diagram has two dimensions; time and classifiers(objects). Usually the vertical axis represent time and the horizontal represent roles, but the axis may be inverted. The time axis is usually not graded, but in certain applications this is important(e.g. real-time systems.) In a sequence diagram an object is shown as a vertical column. If the object exists it is represented with a dashed vertical line(a.k.a. lifeline). If it is active it is shown as a thin vertical rectangle, that start at activation time and stops at time for deactivation. An object is identified by a rectangle-shaped box on top of the vertical representation, including its name. Messages are among others used to invoke operations and create/destroy objects. A message is shown as a solid arrow from an objects lifeline to another objects lifeline or its own. The arrow is labelled with the operation and its arguments. There may also be a sequence number but this is most often left out because the diagram in itself give an order. 15

16 Different arrowheads can be used to indicate specific messages: A solid filled arrowhead is used for regular procedure calls and nested flow control. A stick arrowhead is used for flat flow control. Each arrow show step to next step in sequence. A half stick arrowhead is used to indicate asynchronous communication. A dashed arrow with stick head is used to indicate a return from a procedure call. There exists some variations of these but they are not covered in this work. Fig.3.4. Sequence Diagram An object/role that is created during the time covered by a diagram is shown as any object but the whole representation including the object box will be drawn from the time of creation. If another object initiate the creation, an arrow is drawn from this objects lifeline to the top box of the created object. An object being destroyed during the time shown in a diagram, is shown as a thick-lined cross drawn on the end of the lifeline/activation. There is also a representation for recursive calls in sequence diagrams. Such a call is drawn as another activation symbol overlapping the existing as shown in fig Collaboration diagram Collaboration diagrams are used to represent a Collaboration which consists of a number of roles at executiontime played by objects and the relationships between these roles. The diagrams may also describe interactions/communication, i.e. a set of messages used to carry out a specific result. There are two forms in which a collaboration diagram can be given: Instance level, that shows instances, links and stimuli. The instances are shown as a set of objects tied together with lines representing links and/or stimuli. Arrows may indicate the communication over a specific link. The description of links may include procedure arguments, local variables and self links. Specification level, that shows roles(association/classifier) and messages. Roles are shown as class boxes, tied together with lines the same way instance level diagrams are. Arrows will in this case represent messages. In a collaboration diagram a role or an object is shown as a class symbol or an object symbol. Normally only the name compartment is used, but others may be if needed. In the case of a role being described the name compartment shall include a string on the following format: / ClassifierRoleName : ClassifierName [, ClassifierName]* In the case of an object being described the string would look quite similar: ObjectName / ClassifierRoleName : ClassifierName [, ClassifierName]* 16

17 There are some choices that can be made omitting part of these strings. One example of this is that the role name can be left out. The object name can be omitted as well. Association lines are used to represent relationships. Arrows used to represent stimuli/messages can have different looks depending on what its specific task is. The symbols and meaning of these are similar to the ones used in sequence diagrams(see 3.3.2). Fig.3.5 Collaboration Diagram - Specification Level Unlike sequence diagrams a collaboration diagram provide a full context of an interaction. This includes showing the relationships between objects. The sequencing in collaboration diagrams are shown with sequence numbers. This is because it is fairly impossible to import a time-axis in this kind of diagram. A multiobject representation can be used in a collaboration diagram to represent a many end of an association. An arrow(message) to a multiobject can be seen as a message to all of the contained objects rather than to a specific object. A specific object from the set of objects presented by a multiobject may be linked with the multiobject symbol with a composition, to show that it belong to the specified set. Multiobject is shown as two rectangles, one on top of the other. One of them is slightly shifted both vertically and horizontly so that they appear as a stack of symbols. Active objects can be used to represent objects that owns a thread of control, such as processes and tasks. In a collaboration diagram it is used to model the objects that are active during execution. Active objects are shown as rectangular boxes with heavy border Pattern structure Collaborations can be used to specify and reveal design patterns within a construction. This is useful because one can model design patterns so the use of them can be viewed with classes that is used at the moment. A collaboration that is in use is shown as a dashed ellipse containing the name of the collaboration. Between participating objects and the collaboration dashed lines are drawn to indicate the relationship. The lines are labelled with the role of each participant. These roles correspond to elements within the collaboration. There can also be generalization relationships between different collaborations. This is shown with generalization symbols(see Class Diagram). If the collaboration is a generalization of a classifier the generalization symbol is shown with a dashed line. This can also be shown by a string within the collaboration. Fig.3.6. Diagram shows how collaborations can be used with design patterns. 17

18 4. Model Management view 4.1 Packages A package is mainly used for gathering elements. A packet can hold another package (which means that it is nested), or it can contain UML specified element, such as a class or a component. A package may not be nested more than two to three levels. Packages only contain top-level elements, that is elements that are not contained in other elements. You can not place a class attribute in a package since the attribute is an element in a class. Elements of the same kind must have unique names within the same package. You can not, for instance, have two classes named circle, in the same package, but you can have a class named circle in package pack1 and another class (and different) named circle in package pack2. Elements of different kind can have the same name within a package. For example, a class named clock and a component called clock. This is to be avoided in practice though so that confusion not occur. The elements in a package can be controlled with visibility in the same way that you control the attributes and the methods in a class. Most often an element in a package have the public visibility, which means that any other contents in another package can see it. Protected elements can only be seen by children and private elements can only be seen within the package. A package is usually drawn as a rectangle with a smaller rectangle attached to its upper left corner and with only its name in it. You can, however, draw a package with details like you do with classes. The fig 3.1 illustrates the regular notation of a package. Fig 4.1 notation for a package Relationships There are two relationships between packages. These are generalization and dependency. Generalization is similar to the generalization between classes. There are two kinds of dependency and they are import and access. This means that the dependency arrow(a dashed line with an arrow) is extended with the keyword <<import>> or <<access>>. Importing means that elements in one package have permission to use elements in another package, but not the other way around. The main difference between <<import>> and <<access>> is that <<import>> adds the imported packages namespace. That can make conflicts if you have the same name in both packages. The elements that are imported or accessed can be drawn outside the package symbol. A public package can however be drawn inside the package. Fig 4.2 shows the dependency among packages 18

19 4.2 Subsystems A subsystem represents the behavioural unit in the model and not the organisation part as the package does. The subsystem can be made of packages. It is divided into specification and realization elements. The specification part contains operations and the specification elements. The subsystem is noted in the same way as a package, but it contains a fork (can be replaced with the keyword <<subsystem>>) symbol in the right corner of the large rectangle. The name of the subsystem is also placed in the large rectangle. The fork and the subsystem name can be showed in the small rectangle if the contents of the subsystem is shown in the large rectangle. The large rectangle is divided by a vertical line and the left part is divided with a horizontal line. The upper left part contains the operations, the lower part contains the specification elements, and the right part the realization elements. subsystem with packages and their dependencies Fig. 4.3 show a 19

20 5. Extension Mechanisms While modelling using the UML, there might be a need for extending the language with application specific details. The UML provide ways to do this without violating the rules of the language. This is done with mainly three kinds of mechanisms; constraints, tagged values and stereotypes. These are sometimes referred to as general extension mechanisms, because they can be used with any of the modelling elements defined in UML. 5.1 Constraints The use of Constraints allow the user to change or/and extend the existing semantic. A Constraint express a relationship condition or restriction attached to one or several model elements. It is represented with a text string enclosed by a pair of braces. The text string can be on the form of a formal constraint language, such as OCL, but programming languages or natural languages may be used as well. This string can be added to an element, a dependency or a note depending on how many elements that are involved. If there is only one graphical symbol to which a constraint will be attached then it is just placed near the symbol (and the name if present). If there are two elements(symbols) involved, a dashed line drawn between them indicates which elements the constraint applies to. In the presence of three or more symbols affected by the constraint, a note including the constraint is drawn and attached to the symbols using dashed lines. Some constraints are defined in UML( e.g. xor), and other may be defined by the modeler. Internet Corporation {secure} BankAccount {or} Person Gender:{female,male} 0..1 wife OCL notation 0..1 husband {self.wife.gender = female and self.husband.gender = male} Fig 5.1 Show some notations for constraints. 5.2 Tagged Values Tagged values introduces a way to add information/property to a model element. For example one might want to add information about creation date and author of an object. Tagged values can also be used to add implementation details to provide guidance for code generators. A tagged value is defined as a pair of strings; the first is a keyword (often referred to as tag ) describing a name of the property one would like to add, and the second defines a value for the property on the particular element. The notation for tagged values is the two strings described above separated by an equal sign; keyword = value. If several tagged values may be assigned to an element they are separated with comma signs. They may be written on separate lines or not. There is also choices how to distinguish the tagged values from other properties. The standard notation is to enclose them with braces, but other notations that clearly distinguish them from other statements may be used as well. 20

21 Tagged value Server {processors = 3} Fig 5.2 Show an example how tagged values can be used in a Server object. 5.3 Stereotypes Stereotypes are used when there is a need or wish to tailor the modelling language, but it still should be universally understandable. A stereotyped element is a variation or more specific type of an existing UML model element. This means that using stereotypes introduces a way to create new modelling elements, that might be needed in a specific application. Stereotypes are showed as text strings containing the stereotype name and it is enclosed by guillemets; <<name>>. The stereotype is placed above the name of another element. If there is no name specified the stereotype is placed within or inside the element. When creating a stereotype a new symbol may be added to it. This icon can either be shown inside the symbol of the stereotyped element or it can used instead of the one specified by the base class. Each stereotype can provide its own set of tagged values, semantics, and notations. Named stereotype Client <<ethernet>> Server <<exception>> Overflow Named stereotype with icon Fig. 5.3 Shows a stereotyped association(ethernet ) and a stereotyped class(exception class). 21

22 6. Notation Example In this section we show the UML in use. The purpose is to give the reader a better understanding of how the language can be used to model different parts of a system, and how a system can be modelled to show different views of it. The object used in the examples is a bank system, of which some parts are modelled here. The examples of the different views are not supposed to work as complete and correct views of a bank system, but to show concrete examples on how a model on a an existing thing could look like. Details have deliberately been left out to make the examples simple. 6.1 Use case diagram This diagram shows a simple view of an account and how it can be used. The only thing you can do from a cash-machine is to withdraw money (we only compare withdraw and deposit). From inside the bank you can either withdraw or deposit. Either if you deposit or withdraw money, the account must be updated and this is illustrated by the keyword <<include>>. Fig. 6.1 use case diagram that displays how an account can be manipulated. 6.2 Class diagram This diagram shows a customer and his/her accounts and stocks. The association between the customer and the account means that one customer have many accounts. The association between the customer and the stocks are the same. The customer have to accounts: a savings account for example the race-car and a salary account for the ordinary months payments. 22

23 Account money:double deposit(size) withdraw(size) * * 1 Customer 1 * Savingsaccount Salaryaccount Stock Fig. 6.2 class diagram that shows a customers account and what things do to with it. It also displays that the customer have several stockings. 6.3 Component diagram This diagram illustrates two users interface: one for an account holder that uses the cash-machine interface and one for a bank employee that uses the bank employee interface (terminal). An account manager gives interfaces that can be used from the cash-machine and by a bank employee. The only thing to do from a cash-machine is to withdraw money and if a customer wants to deposit or set up a new account he/her have to go into the bank and talk to the employee. The relationship between an account holder and a bank employee is not illustrated in this diagram though. When the errand is done, the account will have to be updated and therefore the account gives an interface that the account manager can use to make the transaction. Fig. 6.3 component diagram that illustrates two users interface. 23

24 6.4 Deployment diagram This diagram display the nodes in the system and the components that lives in them. One bank server can have several cash-machines and employee terminals but it can t be the other way around (i.e. several cash-machines or terminals can only have one bank server), this is shown with the association relationship. Fig. 6.4 deployment diagram that shows how the components are gathered. 6.5 Interaction diagrams The Sequence diagram in figure 5.5 shows a somewhat simplified chain of occurrences when using a cashmachine to withdraw money from a bank account. The notation used in naming of the elements just says that there are objects with the proposed names seen in figure. The cash-machine object asks the account manager to withdraw an amount of money from a specified account. Continuously this object uses the received information to make the requested transaction. The lifelines implies that the participating objects are active during the whole operation. The solid arrows show procedure calls on an object and the dashed arrows shows return from procedure call. cashmachine withdraw(amount,account) accountmanage account Fig.6.5 Sequence diagram of withdrawal. The other form of check(availability) interaction diagram is Collaboration diagrams. The two forms are said to be isomorphic, that is, if you have a availability diagram of one of the forms it can be translated into the substract(amount) other. To show relationship this has been done to create the following example of a Collaboration diagram. As can be seen in figure 5.6 the same updated() communication strings are used to describe the interactions within this diagram. Short arrows indicate direction and form of communication. An 24