UML Overview UML Overview. Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005.

Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005

UML Overview UML Overview

UML This is how the UML developers see their brain child:
"The Unified Modeling Language (UML) provides system architects working on object analysis and design with one consistent language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling."

UML : What It Is …. A language for modeling systems :
Mechanical systems, electronic systems Software systems A combination But also business processes A language that helps to cope with complexity of systems : Abstracts from uninteresting details Provides different, but related views Reveals large scale structure (architecture) A language that helps to develop software systems : Modeling the problem domain Specifying desired system behavior Describe implementation

UML … What It Isn’t A description of a software development process ((R)UP is the “corresponding” process) A programming language (models are not always executable)

UML History The number of OO methods increased from 10 in 1989 …… … to more than 50 in 1994 The most notable (say popular) methods were : Booch's OOD Jacobson's OOSE Rumbaugh's OMT Fusion Shlaer-Mellor Coad and Yourdon No modeling language filled all needs completely

UML History Babylonian confusion:
Everybody invents and speaks his own modeling language Everybody has a different understanding of modeling concepts Tools all use a different language or dialect Interchange of models is not possible One popular language (and process) emerged: OMT (2) Grady Booch observed the need for an object esperanto! A comedy acted out in real life: the three amigos Around 1994 Booch convinced the other two famous methodologists to join him at rational : Jacobson, Rumbaugh

History UML UML 2.0 UML 1.5 UML 1.0 UML 0.9 OOSE Other Methods
2005? UML 2.0 OOSE Other Methods UML 0.9 Web - June ´96 public feedback UML 1.5 2003 UML approved by the OMG Nov ‘97 UML 1.0 Unified Method 0.8 OOPSLA ´95 Booch method OMT

OMG OMG stands for object management group, inc. (1989)
International industrial consortium with over 800 members The OMG promotes object-oriented technology E.G. CORBA and UML The OMG wants to provide a framework for software development Stimulate growth of object technology Increase interoperability of software of different vendors Reducing confusion by setting standards

Frameworks en patterns,
Contributions to UML Harel Statecharts Meyer Before and after conditions Gamma, et al Frameworks en patterns, HP Fusion Operation descriptions en message numbering Booch Booch methode Embley Singleton classes en high-level view Rumbaugh OMT Wirfs-Brock Responsibilities Jacobson OOSE Shlaer - Mellor Object lifecycles Odell Classification

UML and other OMG technologies

UML Diagrams The UML is constructed specifically to enable modeling of objects, their structure, behavior and interaction. With the UML it is possible to : Display the boundary of a system & its major modes of use as observed by external actors using Use Case Diagrams . Illustrate how particular use cases are realized through the interactions between objects in Interaction Diagrams: Sequence Diagrams; Communication Diagrams. Model the structure of objects with Class Diagrams. Model individual object behavior with State machine Diagrams. Describe the physical implementation architecture with Component & Deployment Diagrams.

UML Diagrams

Views Use Case View : Static View : Design View : State Machine View :
Use Cases capture a mode of use of the system as observed by an external actor. The Use Case view is a visual representation of such modes of use. Static View : captures static relationships between conceptual entities in a domain, abstracting from their physical representation or implementation. Design View : models the structure of the application itself (structured classifiers, collaborations, components and interfaces). State Machine View : Models the possible life histories of an object of a class.

Views Activity View : Interaction View : Model Management View :
Shows the flow of control among the computational activities involved in performing a calculation or a workflow. Interaction View : Describes sequences of message exchanges among the parts of a system. Model Management View : Models the organization of the model itself. A model comprises a set of packages that hold model elements (classes, state machines, use cases) or other packages. Deployment View : A description of the allocation of components to execution resources.

Views Major Area View Diagram structural static view class diagram
design view internal structure collaboration diagram component diagram use case view use case diagram

Views Major Area View Diagram dynamic state machine view
state machine diagram activity view activity diagram interaction view sequence diagram communication diagram physical deployment view deployment diagram model management model management view package diagram

Use-Case View Use-Case Diagrams model modes of use of a system :
Use Cases Actors

Static View Class Diagrams model structure of objects and their relationships Classes Objects Packages Lift system

Interaction View Interaction diagrams Objects Messages
Model interactions between objects Objects Messages

State machine View Door State machine Diagrams model behavior of individual objects States Transitions Events (messages)

Component View Component Diagrams Typical components:
Executables DLL’s Packages Database tables Show the component dependencies background.gif Building.java appletviewer.exe Building.html Lift Building.class JavaDevices Devices java.awt

Location of components
Deployment View Deployment Diagrams show the physical distribution of components over processors Location of components on nodes

Use Cases The Essentials Use Case s Essentials

Requirements Requirements specification : Importance of requirements :
High-level description of what should be implemented Importance of requirements : 25% of the projects fail due to problems with requirements Find out about requirements : Interview stakeholders to find out what they need system to do A requirement may be a description of : What behaviour the system should offer A specific property of the system A constraint on the system Before we can even begin to do OO analysis and design, we have to have some idea of what we are trying to achieve. For any given system, there may be many different stakeholders – many types of user, maintenance engineers, support staff, sales people, managers etc. Requirements engineering is about eliciting and prioritising the requirements that these stakeholders have for the system. It is a process of negotiation as there are often conflicting requirements which must be balanced. For example, one group might want to add many users which may result in unrealistic traffic on the existing database and communications infrastructure. This is a very common conflict at the moment as more and more companies are opening up parts of their system to a huge user base via the Internet. Many UML books state that the UML notion of use cases is the only way to capture requirements. However, this doesn’t really stand up to close examination. Use cases can only really capture functional requirements which are statements about what the system will do. However, there is another set of nonfunctional requirements that are statements about constraints on the system (performance, reliability etc.) which are not really suitable for capture by use cases.

Functional and Non-functional Requirements
What the system should do “The ATM system shall provide a facility for authenticating the identity of a system user” Non-functional Requirements : A constraint on how the functional requirements are implemented “The ATM system shall authenticate a customer in four seconds or less” It’s useful to divide requirements into functional and non-functional requirements. A functional requirement is a statement of what the system should do – it is a statement of system function. For example, if we were collecting requirements for an Automated Teller Machine (ATM), some functional requirements might be : 1. “The ATM system shall check the validity of the inserted ATM card.” 2. “The ATM system shall validate the PIN number.” 3. “The ATM system shall dispense no more than £250 against any ATM card in any 24 hour period.” A non-functional requirement is a constraint placed on the system. For our ATM system, non-functional requirements might be : 1. “The ATM system shall be written in C++.” 2. “The ATM system shall communicate with the bank using 256 bit encryption.” 3. “The ATM system shall validate an ATM card in three seconds or less.” 4. “The ATM system shall validate a PIN in three seconds or less.” You can see that non-functional requirements specify or constrain how the system will be implemented.

The glossary There is always a certain jargon in a business domain
Project glossary captures the language of the domain The aim of the glossary is : Define key terms Resolve synonyms and homonyms Project Glossary Term Definition Term Definition Term Definition … One of the most important documents in any project is the glossary. Every business domain has its own unique language, and the primary purpose of requirements engineering and analysis is to understand and capture that language. The glossary provides a dictionary of key business terms and definitions. It should be understandable by everyone in the project, including all the stakeholders. We can use the glossary to resolve the often sticky issue of synonyms and homonyms. Synonyms are different words that mean the same thing. As OO analysts we must choose one of these words (the one that seems to be most widely used) and stick with it. The other variants must be completely excluded from our models. This is because if we allow the use of synonyms, we may well end up with two classes that do more or less the same thing, but have different names. As well, if we allow the use of all the synonyms on an ad-hoc basis, then we can be sure that the actual semantics of the words will gradually diverge over time! Homonyms occur when the same word means different things to different people. This always gives rise to difficult communication problems as the various parties are quite literally speaking different languages, when they all believe that they are speaking the same language. Again, the way to resolve this is to choose one meaning for the term, and perhaps introduce new terms for the other homonyms. In the glossary, we should record the preferred term, and list any synonyms under the definition. It is often a hard task to get the business stakeholders to change their use of language,and yet with persistence, it can be done.

The system boundary Before we can build anything, we need to know :
Where the boundary of the system lies Who or what uses the system What functions the system should offer System boundary is identified in UML by a Use Case model The Use Case model contains : Actors – who or what uses the system Use Cases – things actors do with the system Relationships - between actors and use cases The first thing we need to do when we're thinking about building a system is to decide where the boundaries of the system are. In other words we need to define what is part of our system (inside the system boundary) and what is external to our system (outside the system boundary). Severe problems can arise from an uncertain system boundary. The positioning of the system boundary typically has an enormous impact on the functional (and sometimes non- functional) requirements. Incomplete and ill specified requirements are the primary reason that projects fail. The use case model has many uses : · It captures the boundary of the system. · It tells us who or what interacts with the system (actors). · It tells us what functions the system performs for those actors (use cases). · It is an alternative way of capturing requirements which is complementary to the System Requirements document. · It provides a source for objects and classes – it is the primary input to class modelling.

Use Case Diagram In the use case diagram, the system is represented by a box labelled with the name of the system. We show actors outside the system boundary (external to the system) and the use cases, which constitute the system behaviour, inside the system boundary (internal to the system). The relationship between an actor and a use case is shown using a solid line, which is actually the UML association symbol. We’ll see much more of associations later! There is always assumed to be an implicit «communication» stereotype on this association to indicate that the actor and the use case communicate in some way. This stereotype is never shown explicitly on the use case diagram.

Characteristics Use Case Modeling
Use Case Modeling is OO-independent There is no UML standard way of writing requirements! The UML does not provide any recommendations on writing requirements documents. In fact the UML deals with requirements by the mechanism of Use Cases, which we will examine later. However, many modellers believe that use cases are not enough, and that we still need requirements documents and requirements management tools. We recommend a very simple format for stating requirements. Each requirement has a unique identifier (usually a number), a keyword (shall) and a statement of function. The advantage of adopting a uniform structure is that requirements documents can be parsed more easily by requirements management tools such as DOORS.

Actors An actor is anything that interacts directly with the system
Actors identify who or what uses the system Actors indicate where the system boundary lies Actors are external to the system An Actor specifies a role that some external entity adopts when interfacing with the system The notion of an actor is essentially very simple – it is something that directly interacts with the system in some way. Essentially we are looking for user roles and other systems that touch the boundary of our system. But we are only concerned with things that interact with our system directly. It’s important to realise that actors are always external to our system. For example, if I am using an e-commerce system such as Amazon ( to buy a book, then I am always external to that system. However, it’s interesting to note that although actors themselves are always external to the system, systems often maintain some internal representation of one or more actors. In the case given above, the Amazon e-commerce system maintains a customer details record for most Amazon customers. This contains name, address etc. This is an internal system representation of the Customer actor. Now it’s important to be crystal clear about this difference – the Customer actor is external to the system, but the system might maintain a CustomerDetails class, which is an internal representation of individuals who play the role of Customer actor.

Identifying Actors When identifying actors ask : Actor symbol :
Who or what uses the system? What roles do they play in the interaction? What other systems use this system? Who gets and provides information to the system? Is there a dedicated time at which the system has to do something? Actor symbol : When identifying actors, remember the following points : · Actors are always external to the system. They are therefore outside our control. · Actors interact directly with the system. This is how they help to define the system boundary. · Actors represent roles that people and things play in relation to the system not specific people or specific things. · One person or thing may play many roles in relation to the system simultaneously or over time. · Each actor needs a short name that makes sense from the business perspective. · Each actor must have a short description (one or two lines) that describes what this actor is from a business perspective. · Like classes, actors may have compartments that show attributes of the actor and events that the actor may receive. Typically these compartments are not used that much and are rarely shown on use case diagrams. When we need to model things that happen to our system at a specific point in time but which don’t seem to be triggered by any specific actor, we can introduce an actor called Time. An example of this would be an automatic system backup that runs every evening. We can arrive at the roles that people and things play in relation to our system by a consideration of specific people and things and then generalising. Visitor

Use Cases A use case is something an actor wants to do with the system. It is a “case of use” of the system by a specific actor Use cases are always started by an actor Use cases are always written from the point of view of an actor Use Case symbol : Place order The UML Reference Manual defines a use case as: “A specification of sequences of actions, including variant sequences and error sequences, that a system, subsystem or class can perform by interacting with outside actors.” We usually think of use cases at the system level, but as the definition states, we may also use use cases to describe “cases of use” of a subsystem (part of a system) or even an individual class.

Steps in Use Case Modeling
Find actors and use cases Detail a use case : Specify the flow of events or scenario’s Specify pre- and postconditions Structure the use case model : Find relationships between use cases include extend generalization Having created our use case diagram and identified the actors and key use cases, we next need to begin to specify each use case in turn. It’s important to note that we typically don’t do things in an exact sequence, and we may choose to specify some, or all, of the use cases as we find them.

Use case specification
Uses case name Deposit VAT Preconditions : 1. It is the end of a business quarter Flow of events : 1. The use case starts when it is the end of the business quarter. 2. The system determines the amount of VAT owed to the government. 3. The system sends an electronic payment to the government. Postconditions : 1. The government receives the correct amount of VAT System state before the use case can begin Actual steps of the use case There is no UML standard for a use case specification. However, the template shown above is in common use. Each use case has a name, and a specification, and the specification consists of: · Preconditions: These are things that must be true before the use case can execute. They are constraints on the state of the system. · Flow of events : The steps in the use case. · Postconditions : Things that must be true at the end of the use case. In the example above, the government always gets its tax one way or another, and so we state this as a postcondition of the use case. System state when the use case is over

Pre and postconditions
Preconditions and postconditions are constraints Preconditions : Constrain the state of the system before the use case can start Postconditions : Constrain the state of the system after the use case has executed Place Order Preconditions: 1. A valid user has logged on to the system Postconditions: 1. The order has been marked confirmed and is saved by the system Preconditions and postconditions should be simple statements about the state of the system that will evaluate to true or false. These are known as boolean expressions. The preconditions specify what must be true before the use case can execute, and postconditions specify what will be true after the use case has executed. Pre and postconditions help us to design systems that will function correctly.

When to use use cases ? Use cases describe system behaviour from the point of view of one or more actors. Use cases are the best choice when : System is dominated by functional requirements System has many types of users to which it delivers different functionality Use cases are designed to capture functional requirements Uses cases are a poor choice when : The system is dominated by non-functional requirements The system has few users The system has few interfaces Develop test plan using use cases Because use cases capture system function from the point of view of the actors, they are clearly not very effective when the system has only one or even zero actors. Use cases capture functional requirements, and so they are not effective for systems dominated by non- functional requirements. Examples of systems where use cases may not be appropriate are embedded systems, and systems that are algorithmically complex but have few interfaces. For these systems, we may well be much better off falling back to more conventional requirements engineering techniques. It’s really just a matter of choosing the right tool for the job in hand.

Questions

Use Cases Advanced concepts Use Cases Advanced Concepts

Use case specification
Uses case name Deposit VAT Preconditions : 1. It is the end of a business quarter Flow of events : 1. The use case starts when it is the end of the business quarter. 2. The system determines the amount of VAT owed to the government. 3. The system sends an electronic payment to the government. Postconditions : 1. The government receives the correct amount of VAT System state before the use case can begin Actual steps of the use case There is no UML standard for a use case specification. However, the template shown above is in common use. Each use case has a name, and a specification, and the specification consists of: · Preconditions: These are things that must be true before the use case can execute. They are constraints on the state of the system. · Flow of events : The steps in the use case. · Postconditions : Things that must be true at the end of the use case. In the example above, the government always gets its tax one way or another, and so we state this as a postcondition of the use case. System state when the use case is over

Pre and postconditions
Preconditions and postconditions are constraints Preconditions : Constrain the state of the system before the use case can start Postconditions : Constrain the state of the system after the use case has executed Place Order Preconditions: 1. A valid user has logged on to the system Postconditions: 1. The order has been marked confirmed and is saved by the system Preconditions and postconditions should be simple statements about the state of the system that will evaluate to true or false. These are known as boolean expressions. The preconditions specify what must be true before the use case can execute, and postconditions specify what will be true after the use case has executed. Pre and postconditions help us to design systems that will function correctly.

Flow of events The flow of events lists the steps in a use case
It always begins by an actor doing something A good way to start a flow of events is : “1) The use case starts when an <actor> <function>” Flow of events should be a sequence of short steps which are: Declarative, numbered, time ordered Alternatives can be shown by branching or by listing under “Alternative paths” A good format for steps is : <number> The <something> <some action> Each step in the use case flow should be in the form : <number> The <something> <some action>.” For example: 1) The use case starts when the customer selects place order. 2) The customer enters his or her name and address into the form. These are well-formed steps. In both cases we have a simple declarative statement of some object performing some action. An example of an ill formed use case step would be : 2) Customer details are entered. This sentence actually contains three important deletions: 1. Who is it that enters the customer details? 2. Into what are the details entered? 3. What specifically are the “customer details”? It is important to recognise and avoid deletions when writing use case flows. Even though we may be able to tell by context or to guess what is meant, this is not really the point. The point is that the uses case should be a precise statement of a piece of system function! When you encounter vagueness, deletions or generalisations during the process of analysis, it is useful to ask the following questions: · Who specifically…? · What specifically…? · When specifically…? · Where specifically…?

Branching within a flow: If
Use the keyword if to indicate alternatives within the flow of events Use indentation and numbering to indicate the conditional part of the flow View Basket Flow of Events: 1. The use case starts when the customer selects “view basket”. 2. The customer selects an item. 3. The customer may delete an item from the basket, change the quantity of an item, exit “view basket” or proceed to checkout. 4. If the user selects “delete item” 4.1. The item is removed from the basket 5. If the customer types in a new quantity 5.1. The quantity of the item is updated 6. If the customer selects… We often need to indicate that there are many possibilities within the flow of events of a use case. A very good way to do this is to use “structured English” (or German or whatever your native language is!). We introduce a simple set of keywords that we can use to express branching, repetition and even alternative paths. We use the keyword “if” to indicate a branch in the flow of events. The example above shows a very nicely structured flow of events with three branches. Each branch is prefixed with the keyword “if”, and begins with a simple Boolean expression such as “If the user types in a new quantity”, which is true or false. The indented text under the “if” statement is what will happen if the Boolean expression is true.

Branching: Alternative paths
Alternative Paths are for things that can happen at any time Section in use case specification for each alternative path with : The flow of events for the alternative path postconditions for the alternative path (optional) Flow of Events: Basic Path 1. The use case starts when the customer selects “go to checkout”. 2. The system displays the customer order. 3. … Alternative Path 1 1. At any time the customer can select “cancel order” and the order is deleted from the system. Alternative Path 2 1. At any time, the customer can go back to shopping. Checkout Sometimes we can’t easily express branching using “If”. This is particularly true for things that can happen at any point in time. Where in the main flow could we put the “If” statement for such an event? It’s best to express this sort of branching as one or more alternative paths through the flow of events. We can do this as follows : 1. Specify the preconditions for the Use Case - these must be true for all possible paths through the use case. 2. Specify the normal flow of events. 3. Specify the postconditions for the normal flow of events. We can then append a new section to the end of the use case for each alternative path. This section must contain the following: 1. The flow of events for the alternative path. Normally, this should be kept very simple - just a few steps at most. 2. The postconditions for that flow of events.

Repetition within a flow: For
Use the keyword “For” to indicate the start of a repetition within the flow of events Expression immediately after “For” indicates the number of repetitions of the indented text beneath the “For” statement Find a Product Flow of Events: 1. The use case starts when the customer selects “find product”. 2. The customer enters a keyword and selects “find”. 3. For each product found 3.1. The system displays a thumbnail sketch of the product and the customer selects one of the products. 4. The system displays full product details and a larger picture. 5. … Find a Product Flow of Events: 1. The use case starts when the customer selects “find product”. 2. The customer enters a keyword and selects “find”. 3. For each product found 3.1. The system displays a thumbnail sketch of the product and the customer selects one of the products. 4. The system displays full product details and a larger picture. 5. … Sometimes we have to repeat an action several times within a flow of events. We can model this by using the keyword “For”. The format is: n) For (iteration expression) a) Do something b) Do something else c)… n+1) … The iteration expression is some expression that evaluates to a positive whole number of iterations. Each indented line after the “For” statement is repeated for the number of iterations specified in the iteration expression.

Repetition within flow: While
Use the keyword “While” to indicate that something repeats while some Boolean condition is true Show Company Details Flow of Events: 1. The use case starts when the customer selects “show company details”. 2. While the customer is browsing the company details 2.1. The system plays some background music. 2.2. The system displays special offers in a banner at the top of the page. 3. … We use the “While” keyword to mode a sequence of actions in the flow of events that is performed while some condition is true. The format is: n) While (Boolean condition) a) Do something b) Do something else c) … n+1)… The Boolean condition is some expression that evaluates to true or false. The sequence of indented lines after the “While” statement is repeated until the Boolean condition specified in the “While” clause becomes false.

Complex use cases Techniques up to now are fine for modeling average use cases However, when use cases are complex, and there are many branches within the flow of events, there is a better approach Scenarios As a rule of thumb, use cases should be kept as simple as possible. Occasionally, however, we encounter irreducible complexity and need to formulate complex use cases. The strategies we have seen up to now, branching and iteration, are fine for relatively simple cases, but for very complex use cases, the amount of branching can rapidly become unmanageable. It is at this point that we change our tactics and decide to model using scenarios..

Scenarios One specific path through a use case with no branching
Each use case has one primary scenario : This is the “happy day” or “perfect world” path through the flow Everything goes as expected and desired No errors, interrupts or branches Each use case has many secondary scenarios : Alternate paths through the flow Errors (exception scenarios) Interrupts to the main flow Scenarios are another way of looking at use cases. When we document a use case, if we tease out specific paths that can be taken through the use case flow of events, then each of these paths is a scenario. The important feature of scenarios is that they do not branch. Each possible branch in the use case flow of events generates a separate scenario. We only need to use this technique when the use case is very complex. Rather than trying to capture this complexity with lots of branching, it is often easier, and less error prone, to model the main flows through this branching network. It’s sometimes useful to think of a complex use case as being like a river delta with many branching channels. Every use case has exactly one Primary Scenario that is the main channel through the delta. This primary scenario is also known as the “happy day” scenario as we assume that everything goes perfectly according to plan and that there are no errors, deviations and no interruptions. The other, smaller, channels in our river delta are the Secondary Scenarios. These are alternate paths; error conditions or interrupts to the main flow.

Primary scenario Use the Primary Scenario as the use case flow of events List the Secondary Scenarios under a new section Provide a separate document for each secondary scenario Checkout Flow of Events: Primary Scenario 1. The use case starts when the customer selects “go to checkout”. 2. The system displays the customer order. 3. The customer enters a valid customer number. 4. The system retrieves and displays customer information. … Secondary Scenarios Invalid Customer Number. Invalid Credit Card Details. Credit Card Expired. When we use the scenario approach for documenting use cases, the use case specification contains the Primary Scenario and a list of the names of the Secondary Scenarios. The Secondary Scenarios are typically documented separately and in much the same way as we document use cases.

Checkout Secondary Scenario: Invalid Customer Number
Secondary scenarios One specific path through flow of events with no branching Always state how the scenario begins Checkout Secondary Scenario: Invalid Customer Number Flow of Events : 1. The scenario begins in step 3 of the use case “Checkout” when the customer enters an invalid customer number. 2. For three invalid entries 2.1. Prompt the customer to enter their customer number again 3. The system asks the customer to enter new customer details 4. The customer enters new customer details. 5. The system generates a new customer number 6. … Each Secondary Scenario must be traceable back to its use case. The simple naming convention shown above is a good way to do this. Notice that Secondary Scenarios can reference the Primary Scenario in their flow of events.

Finding Secondary Scenarios
Identify the Primary Scenarios Examine each step in the Primary Scenario and look for : Alternative flows Errors (exception scenarios) Interrupts – something that could happen at any time We identify secondary scenarios by inspection of the primary scenarios. At step in the primary scenario, we look for possible alternative flows, any errors that might be raised, and any interrupts that might occur to the flow. Each of these is a possible source of a secondary scenario.

How many scenarios? There is one Primary Scenario per use case
There may be many secondary scenarios per use case It would take far too long to document them all : Pick the most important ones to document Often there are groups of similar secondary scenarios : Document one of these as an exemplar Add notes to this explaining how the others differ from it Going back to the river delta analogy – apart from the main channel, there can be many branching and twisting alternate flows through the delta. We can’t really afford to map them all, so we just choose the main ones. As well, many of these branches flow in pretty much the same direction with only minor differences. We can therefore map one exemplar channel in detail, and just provide notes explaining how the other, smaller channels deviate from this. This is a very efficient and effective way of modelling a complex use case. The basic principle in use case modelling is to keep the amount of information captured to the necessary minimum. This means that many Secondary Scenarios cases may never be specified at all – the one line description of them in the use case may be enough detail to allow us to understand the functioning of the system. This is an important point – it is very easy to get swamped in scenarios, and more than one use case modelling activity has failed because of this! Remember that we are capturing use cases and scenarios to understand the desired behaviour of the system, and not just for the sake of creating a complete use case model. We therefore stop use case modelling when we feel that we have achieved that understanding.

Structuring the Use Case Model
Structure the Use Case Model by exploring relationships : Actor generalisation Use case generalisation «include» – between use cases «extend» – between use cases Here we look at some relationships that are possible between actors and actors and between use cases and use cases. It is very important to keep all models as simple as possible, so these relationships should be used with discretion only where they improve the overall clarity of the use case model. It can be very easy to go overboard with «include» and «extend» in particular, but this should be avoided.

Actor Generalisation Sales system Purchaser Customer Sales agent
List products Purchaser Order products Accept payment We can factor out common behaviour using actor generalisation as shown above. We create an abstract actor called Purchaser that interacts with the use cases Listproducts, Order products and Accept payment. Customer and Sales Agent are known as concrete actors as real people (or other systems) could fulfil those roles. However, Purchaser is an abstract actor, as it is an abstraction introduced simply to capture the common behaviour of the two concrete actors. Customer and Sales Agent inherit all of the roles and relationships to use cases of their abstract parent. So interpreting the above diagram, both Customer and Sales Agent have interactions with the use cases List products, Order products and Accept payment that they inherit from their parent, Purchaser. As well, Sales Agent has another interaction with the use case Calculate commission that is not inherited; it is specific to the Sales Agent actor. We can see that judicious use of abstract actors can simplify our use case diagrams. It’s worth pointing out that the parent actor in actor generalisation does not always have to be abstract – it may be a concrete role that a person or system could play. However, good style dictates that ancestor actors are usually abstract. Calculate commission Customer Sales agent

Actor generalisation semantics
Actors communicate with same set of use cases in same way : Express this as generalisation to another (possibly abstract) actor Descendent actors inherit from ancestor actor : Roles and relationships to use cases held by the ancestor actor Substitutability principle : We can substitute a descendent actor anywhere the ancestor actor is expected Whenever two or more actors interact with the same use cases in the same way, then we can consider using actor generalisation. An important test for correct use of generalisation with any classifier is the substitutability principle. This states that we should be able to substitute a child actor anywhere the parent is expected. In the previous example, it seems reasonable that we can substitute a Sales Agent or a Customer anywhere a Purchaser is expected (i.e. interacting with use cases List products, Order products and Accept payments) so actor generalisation would seem to be the correct strategy.

Use Case Generalisation
Security System Verify User The ancestor use case must be a more general case of one or more descendant use cases. Use case generalisation is used when we have one or more use cases that are really specialisations of a more general case. Just like actor generalisation, we should really only use this when it simplifies our use case diagrams. User Check Password Check Biometrics

Use case generalisation semantics
Child use cases represent more specific forms of the parent The children inherit from their parent : Preconditions, Flow of Events, Postconditions Relationships The children may add new features : New steps in the flow of events New preconditions and postconditions New relationships Child use cases inherit relationships, preconditions, postconditions and flow of events from their parent. The children may add new features of their own. If the parent use case has no flow of events, or a flow of events that is incomplete, then it is an abstract use case. Abstract use cases are quite common. They are useful for capturing behaviour at the highest levels of abstraction.

<<include>>
Personnel System Change Employee Details <<include>> View Employee Details <<include>> Find Employee Details Sometimes use cases share common behaviour. We can factor this out into a separate supplier use case and «include» this behaviour in the clients where we need it. Writing use cases can be very repetitive at times. Suppose we are writing a Personnel system. Almost anything we ask the system to do will first involve locating the details of a specific employee. If we had to write this sequence of events (involving user authentication, entering a user ID or some other unique identifier etc.) every time we needed employee details, then our use cases would become quite repetitive. The «include» relationship between use cases allows us to include the behaviour of a supplier use case into the flow of a client use case. Manager <<include>> Delete Employee Details

Clients include supplier behaviour
Change employee details Preconditions: 1. A valid manager is logged on to the system Flow of events: 1. The manager enters the employee’s ID number. 2. include (Find Employee Details). 3. The manager selects part of the employee details to change. 4. … View 3. The system displays the employee details. Delete 4. The manager deletes the 5. … Clients include supplier behaviour Delete employee details Preconditions: 1. A valid manager is logged on to the system Flow of events: 1. The manager enters the employee’s ID number. 2. include (Find Employee Details). 3. The system displays the employee details. 4. The manager deletes the 5. View employee details Preconditions: 1. A valid manager is logged on to the system Flow of events: 1. The manager enters the employee’s ID number. 2. include (Find Employee Details). 3. The system displays the employee details. 4. … Change employee details Preconditions: 1. A valid manager is logged on to the system Flow of events: 1. The manager enters the employee’s ID number. 2. include (Find Employee Details). 3. The manager selects part of the employee details to change. 4. … We must specify the exact point in the client use case where we need the behaviour of the supplier use case to be included as shown above. The syntax for include is a bit like a function call, and indeed it has somewhat similar semantics.

«include» semantics «include» works as follows :
The client use case executes until the point of inclusion include(X) Control passes to the supplier use case which executes When the supplier is finished, control passes back to the client use case which finishes execution Client use cases are incomplete without the included supplier use cases Supplier use cases may be complete use cases, or they may just specify a fragment of behaviour for inclusion elsewhere The actual semantics of «include» are very simple. The client use case executes until the point of inclusion is reached, then execution passes over to the supplier use case. When the supplier finishes, control returns to the client again. Note that the client use case is not complete without the included use cases. However, the included (supplier) use cases may or may not be complete. If a supplier use case is not complete, then it just contains a partial flow of events that will only make sense when it is included into a suitable client. In this case, we say that the supplier use case is not instantiable. This means that it can’t be triggered directly by actors, it can only execute when included in a suitable client. If, however, the supplier use cases are complete in themselves, then they act just like normal use cases and are instantiable. It is then quite reasonable to trigger them by actors.

<<extend>>
The client use case inserts behaviour into the base use case. The base use case provides extension points, but does not know about the extensions. «extend» is a way of adding new behaviour to an existing use case. The base use case provides a set of extension points which are hooks where new behaviour may be added, and the extension use case provides a set of insertion segments that can be inserted into the base use case at these hooks. The «extend» relationship itself can be used to specify exactly which extension points in the base use case are being extended.

«extend» semantics «extend» is a way of adding new behaviour to base use case by inserting behaviour from one or more extension use cases Base use case specifies extension points in its flow of events : Base use case does not know about the extension use cases Remains unchanged as new extension use cases are added Extension use case may contain several insertion segments The «extend» relationship specifies which of the base use case extension points it is extending So «extend» is just a way of inserting behaviour fragments (the insertion segments) from extension use cases into predetermined extension points in the base use case. Another way of looking at «extend» is that it provides a way for us to reuse behaviour fragments by placing them in insertion segments in extension use cases. This usage is a bit like «include», but «extend» is more flexible as the base use case does not have to know about and invoke specific extension use cases – it just provides a set of extension points.

Base use case Return book Preconditions:
1. A valid librarian is logged on to the system Flow of events: 1. The librarian enters the borrowers ID number 2. The system displays the borrower details including the list of borrowed books 3. The librarian finds the book to be returned in the list. <borrow date determined> 4. The librarian returns the book. 5. … The motivation behind «extend» is that sometimes we would like a use case to be extendible, but we don’t know in advance what all of the possible extensions might be. We would therefore like to specify extension points in the base use case where extensions can be inserted but without specifying in the use case the actual extensions themselves. An extension point is a point in the base use case flow of events where we can insert some new behaviour.The extension points are inserted into the flow of events of the base use case as shown above. We can also show extension points on the use case diagram by listing them in a new compartment in the base use case icon. Notice that extension points in the main flow are not numbered. Rather, they appear between the numbered steps of the flow. In fact, the UML explicitly states that extension points actually exist on an overlay on top of the main flow. They are therefore not really part of the main flow at all. In the example above, we see that the Return Book base use case has an extension point called <overdue book> which is just before step 4 in its flow of events. What we have done is specified a place in the base use case where extended behaviour can be inserted without the base use case knowing exactly what those extensions might be. Compare this with «include» where the base use case always explicitly has to invoke the included use cases. When we use «extend» the base use case acts as a modular framework into which we can plug extensions at predefined extension points. We can see that «extend» gives us a good way to deal with exceptional cases or cases where we need a flexible framework because we can’t predict all (or just don’t know) of the possible extensions in advance.

«include» and «extend»
«include» is used where we want to reuse the same behaviour again and again in many different use cases «extend» is used when we want to modify an existing use case by inserting some new behaviour at named extension points Extend also allows us to reuse behaviour fragments, but in a more flexible way

Class Diagrams The Essentials Interaction Diagram

Class diagrams Models the static design view of the system :
Involves modelling vocabulary of the system Involves modelling collaborations in the system Class diagrams show : Classes Interfaces Relationships between classes Constraints Adorned by navigational and multiplicity information Further described by the rules on the classes and associations The class diagram shows the first formal definition of a class Leads to specification of abstract data types, that can be used by the software engineer. Class diagrams are used to model the static design view of a system. For the most part, this involves modeling the vocabulary of the system and the existence of classes and their relationships in the logical design of a system. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. A class diagram may represent all or part of the class structure of a system. Class diagrams are also adorned by navigational and multiplicity (cardinality) information and is further described by the constraints on the classes and associations. Class diagrams that include active classes are used to address the static process view of a system.

Class diagram * * * 0..1 IsAt Floor LiftCage floorNumber : int
RequestToServiceFloor * The slide shows an example of a class diagram: There are two classes: Floor and LiftCage. Between these two classes are two associations: IsAt and RequestToServiceFloor. The multiplicity of the associations is shown. The explanation of the shown mutiplicity in words is : IsAt : a lift cage is at 1 or no floor and there can be any number of lift cages on a floor. RequestToServiceFloor: a request for service can be made by zero or more number of floors and a floor requests can be serviced by zero or more lift cages.

Classes and objects in UML
A class icon has compartments for attributes and operations simple name path name The UML notation for classes and objects are shown in the sheet above: A class icon is is represented by a rectangle comprised of three compartments: the first section shows the class name. the second section shows the class structure (attributes). the third section shows the class behavior (operations). While any compartment can be fully suppressed (except the name compartments), it can also have some subset of the values showing. An object icon is represented as a rectangle with underlined names. The example above shows a Window object with a name (SplashScreen). An object can be shown with the class name only (:Window), the object name only (SplashScreen), or class and object name both (see example) Every class must have a name that distinguishes it from other classes. A name is a textual string. A name alone is known as a simple name; a path name is the class name prefixed by the name of the package in which that class lives. An object icon has the object name underlined

Attributes An attribute is a property of a class
At a given moment an object of a class will have specific values for every one of its class’s attributes In the attribute compartment attributes can Be of different types Have different visibility : + for public, - for private, underlined for class scope (static) An attribute is a named property of a class that describes a range of values that instances of the property may hold. A class may have any number of attributes or none. An attribute is shared by all objects of that class. At a given moment an object of a class will have specific values for every one of its class’s attributes The graphical display of a class has a compartment for attributes and one for operations. Graphically, attributes are listed in the attribute compartment just below the class name. In the attribute compartment the attributes can be of a different type have a different visibility public + private - class scope (static) underlined Attributes may be drawn showing only their names. You can further specify an attribute by stating its type or class and possibly a default initial value.

Operations An operation is the implementation of a service.
Invoking an operation can change the data and the state of the object In the operation compartment operations can Be described with return type and parameters, signature + for public, - for private underlined for class scope (static operation) Operations are applied to objects of a class Operations are also called functions Operations describe what service a class offers Format for operations name (parameter-list) : return-type-expr Each parameter is specified with : name : type-expr = value Specifying value is optional An operation is the implementation of a service that can be requested from any object of the class to affect behavior. In other words, an operation is an abstraction of something you can do to an object and that is shared by all objects of that class. A class may have any number of operations or none. An operation is behavior shared by all objects of that class. Invoking an operation can change the the data and the state of the object. Graphically, operations are listed in the operations compartment below the attribute compartment. In the operations compartment operations are described with their return type, parameters (their signature) can be public (+) or private (-) operations are applied to objects of that class operations are also called functions the operations as a whole describe which sevice (interface) a class offers. Operations may be drawn by showing only their names. You can also specify an operation by stating its signature, covering the name, type and default value of all the parameters and a return type.

Attributes and operations example
The example on the slide shows the class box for a Circle class. Note that in the attribute compartment the Point class is used, indicating a dependency on the Point class. Note also the use of several stereotypes in the operation compartment. When drawing a class, you don’t have to show every attribute and every operation at once. You can choose to show only some or none of the class’s attributes and operations. You can explicitly specify that there are more attributes or properties than shown by ending each list with an ellipsis (“…”). To better organize long lists of attributes and operations, you can prefix each group with a descriptive category by using stereotypes (see the above example).

Class relationships Classes will in general have relations with other classes Objects may have other objects as parts Objects may be associated to other objects Three different kinds of relationships are the most important Generalization Specialized classes inherit from more generalized classes in a subclass/superclass or parent/child relationship Association A structural relationship between instances of classes Dependency Using relationship, one instance of a class depends on an instance of another class There may be constraints on class relations : Multiplicities are constraints A LiftCage may have 12 FloorRequestButtons The initial step in domain modeling is the identification of objects, the grouping of them into classes, as well as the initial identification of the associations between objects by identifying their responsibilities and collaborations. The next step is the further specification of the relationships between classes by categorization and adding further detail. The ways things are connected to one another, either logically or physically, are modeled as relationships. In object-oriented modeling there are three kinds of relationships that are most important: dependencies, generalizations and associations.

Types of class relationships
Association Is a connection between classes An instantiation of association is a link (between objects) Generalization A specialised subclass is derived from a superclass Shows that a subclass shares the structure and/or behavior defined in the superclass Dependency The client class depends on the supplier class to provide services Services include accessing attributes, operations or using types Realization A relationship between classes or components and interfaces An interface is a set of well-defined functions and their signatures Shows how a class realizes operations offered by the interface There are a number of different class relationships: An association is a structural relationship, specifying that objects of one thing are connected to objects of another. As such it is a connection between classes. A link between objects is an instantiation of an association. Generalization / specialization is a hierarchical connection between classes: a specialized subclass is derived from a super class. The subclass shares the structure and/or behavior of the super class (this is known as inheritance). Dependency exists when a client class depends on a supplier class to provide services. These services include such things as the accessing of attributes, the use of operations or using types. Realization is the relationship between classes or components and interfaces. An interface is a set of well-defined functions and their signatures that are used to specify a service of a class or a component. A class realizes the operations offered by the interface. Collectively, the interfaces realized by a class represent a complete specification of the behavior of that class

relationships Association Adornments Navigable association Aggregation
Composition Generalization Dependency Realization Association is modeled as a plain line connecting both classes. Navigable association is unidirectional, navigation is limited to just one direction. Specifying a direction of traversal does not necessarily mean that it is impossible to get from the object at one end to the object at the other end. Rather, navigation is a statement of efficiency of traversal. The direction of navigation is explicitly represented by adorning the association with an arrowhead pointing to the direction of traversal. Simple aggregation is a special kind of association with an extra semantical implication and is specified by adorning the end of the association with a diamond at the “whole”-side. Composition (composite aggregation or strong aggregation), the “has a” or “contains” relationship, is represented by an association with a filled diamond. Generalization, the “is a” relationship, is represented as an association with a large open arrowhead at the side of the super class. Dependency is a using relationship, specifying that a change in the specification of one thing may affect another thing that uses it, but not necessarily the reverse. It is rendered as a dashed line with an arrowhead directed to the thing that is depended on. Realization is a semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out. It is rendered as a dashed directed line with a large open arrowhead pointing to the classifier that specifies the contract.

Association, role, multiplicity
association name multiplicity Works for Company Person 1..* * employee employer An example of association is given for the classes Person and Company. It shows the association name (has), the multiplicity and the role names at both ends of the association. A role names a behavior of an entity participating in a particular context.The role is the face that the abstraction presents to the world. Consider for example an instance of the class Person. Depending on the context, that Person instance may play the role of Mother, Comforter, Employee, Customer and so on. When an object plays a particular role, it presents a face to the world and clients that interact with it expect a certain behavior depending on the role it plays at the time. For example, an instance of Person in the role of Manager would present a different set of properties than if the instance were playing the role of Mother. The UML notation of a role is in lower case letters, beside the class box of the class concerned, at the end of an association. role name

Multiplicity Multiplicity is defined as
Specification of a range of allowable cardinalities that a set may assume Multiplicity has meaning for associations It indicates how may objects relate to how many other objects Multiplicity info is indicated ‘at the end’ of an association. single integer : 1 [exactly one] range : [zero or one] : [two, three or four] range : 1 .. * / 1..n [one or more] single star : * (= 0 .. *) [zero or more] Whenever you use a class, it’s reasonable to assume that there may be any number of instances of that class. Sometimes, though, you will want to restrict the number of instances a class may have. Most often, you will want to specify zero or one instances, one instance (a singleton class), a specific number of instances or many instances. The number of instances a class may have is called its multiplicity. Multiplicity is a specification of the range of allowable cardinalities an entity may assume. In the UML you can specify the multiplicity of a class by writing a multiplicity expression in the upper-right corner of the class icon. Multiplicity can apply to attributes as well. You can specify the multiplicity of an attribute by writing a suitable expression in brackets just after the attribute name.

Navigation User Password * navigable association
Navigable association is unidirectional, navigation is limited to just one direction. Specifying a direction of traversal does not necessarily mean that it is impossible to get from the object at one end to the object at the other end. Rather, navigation is a statement of efficiency of traversal. The direction of navigation is explicitly represented by adorning the association with an arrowhead pointing to the direction of traversal.

Generalization/specialization
Generalization is a special kind of relationship The ‘is-a’ or ‘is a kind of’ relationship Generalization is called generalization/specialization An example is the relationship between a car and a truck : A car is a specialization of a vehicle A vehicle is a generalization of of a car In the design phase it is also called inheritance relationship A car has all properties of a vehicle and possibly more A car inherits from a vehicle A generalization relationship between classes shows that the subclass (specialized class) shares the structure and/or behavior defined in one or more superclasses (generalized classes). Use a generalization relationship to show a "is-a" relationship between classes. Graphically a generalize relationship is shown as a solid line with a hollow arrowhead pointing to the superclass: An inheritance tree is useful when a number of subclasses share the behavior and structure of a super class. Rather than creating a multitude of inheritance relationships pointing directly from the subclasses to the superclass, you can tie the relationships together to form one link to the superclass, thereby creating a tree structure.

Generalization/specialization example
The example on the slide shows two examples of generalization / specialization. Both examples show part of an inheritance tree. A vehicle is something that can be used for transportation on the road. Attributes that can be distinguished on a vehicle are its velocity, location, color and weight. Operations that can be distinguished are to drive, to accelerate, to stop and to steer. A truck is a special vehicle which has the potential to carry goods. It also has the attributes and operations of its base class vehicle, but adds special truck attributes and methods to them. A racing car is another special vehicle which has the potential to race. Like a truck it also has the attributes and operations of its base class vehicle, but adds special racing car attributes and methods to them. More specialized classes can be derived from the base class vehicle like bicycle and motor

Multiple inheritance Classes may have more then one base class
Avoid multiple inheritance in the analysis : May introduce problems in the design or programming phase If necessary use interfaces A class may have zero, one or more parents. A class that has no parents and one or more children is called a root class or base class. A class that has no children is called a leaf class. A class with exactly one parent is said to use single inheritance; a class with more than one parent is said to use multiple inheritance. In the case of multiple inheritance a subclass inherits directly from more than one super class. It may be used to capture behavior and attributes that are part of separate semantic domains. An example is a Employee class which may inherit from the Person class but also from the Sporters class. Or an Airplane class which may inherit from an Aircraft class but also from a PoweredVehicle class. A special form of multiple inheritance is repeated inheritance in which case a derived class inherits from a base class twice through different paths. An example is a hierarchy of employees. A SalesManager class might inherit from a Manager class which inherits from a generic Employee class. At the same time a SalesManager class might inherit from a SalesEmployee class which inherits from the same generic Employee class. As a result complications may occur by the presence of duplicate data members in SalesManager objects.

Aggregation A special kind of association is a “has a” (containment) relationship Models the whole-part relation Object of the whole has objects of the part Simple (weak) aggregation Whole ‘controls’ parts Composition (strong aggregation) Whole consists of parts Aggregation is a special kind of association. It is a familiar construct whereby software systems represent structures from real life. For example, a city is an aggregate of houses, a forest is an aggregate of trees, and a flock is an aggregate of sheep. In other words, aggregation is a group/member association. Normal association indicates that objects of one class are linked to objects of another class, it is a relationship of peers. It is bi-directional: navigation is possible in two directions. Simple aggregation is the modeling of a “whole/part” relationship, in which one class represents the “whole” which consists of “parts”. It represents a “has-a” relationship. This form of aggregation is entirely conceptual: it does not change the meaning of navigation across the association, nor does it link the lifetimes of the whole and its parts. It is a special kind of association.

Aggregation examples This figure shows the difference between aggregation and composition examples. An alternative way of showing composition is by graphically nesting the symbols of the parts within the symbol of the composite.

When to use class diagrams?
Always To model static structure of system There is one class diagram describing the structure Don’t go to implementation details too early.

Interaction Diagrams Interaction diagrams are used for modeling the dynamic aspects of a system. An interaction diagram shows an interaction between a set of objects, showing the objects themselves, their relationships and the messages sent between them. There are two types of interaction diagrams: sequence diagrams and communication diagrams. A sequence diagram is an interaction diagram that emphasizes the time ordering of messages; a communication diagram is an interaction diagram that emphasizes the structural organization of the objects that send and receive messages. Interaction Diagrams

Object Interaction Diagrams
An object interaction diagram shows two aspects Which objects and messages are involved in the interaction How objects and messages are involved in the interaction A Use Case is realised through a pattern of interactions Interaction models show how a Use Case (or part of it) is realised Usually one interaction diagram for each scenario in the Use Case

Sequence diagram Illustrates how objects interact with each other
The focus is on message sequences Reveals an interaction for a specific scenario It shows specific interaction between objects at some point in time Two axes present in sequence diagram The vertical axis shows time The horizontal axis shows a set of objects The objects are represented by An object rectangle A dashed line representing the object lifeline Shows communication between objects As horizontal message lines between object’s lifelines A sequence diagram shows a dynamic collaboration between a number of objects. The importance of this diagram diagram is the display of a series of messages that are sent between objects, with the emphasis on the temporal sequence of the messages. It also shows the interaction between objects that takes place at a certain point in the performance of a certain scenario. When creating a sequence diagram you first place the objects participating in the interaction at the top of the diagram, across the X-axis. The object that initiates the interaction (the actor) is placed at the left, and increasingly more subordinate objects are placed to the right. Next, the messages sent and received by these objects are placed along the Y-axis in order of timing from top to bottom.

Sequence diagram Object and timeline :
The diagram consists of a number of objects with vertical lines. The passage of time is shown along the vertical axis and the het diagram shows a set of objects along the horizontal axis between which messages are exchanged in a certain temporal sequence. Messages are represented by lines with message arrows between the object lifelines. Time specifications and other comments can be added in a text in the margin of the diagram. Creation and destruction of objects : Objects can be created and destroyed by messages. The object is drawn in the place where it is created. The object is marked with X if it is destroyed. Recursion is displayed as an activation of the object itself

Sequence diagram sample
The sheet shows an example of what a sequence diagram looks like. Most objects in the interaction diagram will be in existence for the duration of the interaction, so these objects are aligned to the top of the diagram. Objects may be created during the interaction. Their lifelines start with the receipt of the stereotyped message create. Objects may also be destroyed during the interaction. Their lifelines end with the receipt of the stereotyped destroy message, with a large X marking the end of their existence.

Analyze flows of control and time ordering
To further model a flow of control and time ordering on a sequence diagram: Set the context of interaction Identify the objects which play a role in the interaction Set the lifeline for each object Lay out the messages showing their properties (parameters) Adorn each object’s lifeline with its focus of control (optional) Adorn each message with a timing mark and attach time or space constraints (optional) Attach pre- and post-conditions to each message (optional) Define the sequence diagram in the following steps: Set the context of interaction: is it a system, subsystem, operation, class, or one scenario of a use case or collaboration. Identify which objects play a role in the interaction. Lay them out on the sequence diagram from left to right, placing the more important objects to the left and their neighboring objects to the right. Set the lifeline for each object. In most cases, objects will persist through the entire interaction. For those objects that are created and destroyed during the interaction, set their lifelines as appropriate, and explicitly indicate their birth and death with appropriately stereotyped messages. Starting with the message that initiates this interaction, lay out each subsequent message from top to bottom between the lifelines, showing each message’s properties (parameters), as necessary to explain the semantics of the interaction. If the nesting of messages or the points in time when actual computation takes place need to be visualized, adorn each object’s lifeline with its focus of control. If time or space constraints need to be specified, adorn each message with a timing mark and attach suitable time or space constraints. If the flow of control must be specified more formally, attach pre- and post-conditions to each message.

Frames new since UML 2.0 graphical boundary of a diagram
basis for many diagram elements

Sequence Diagram References
reference to sequence digram

Sequence Diagram References

Alternative (no messages)
optional element (‘if without else’)

Loops / conditionals loop loop condition guard conditon nested
alternate branches

Order and timing constraints on sequence diagrams
duration constraint message with duration Modeling the absolute time of an event, modeling the relative time between events, and modeling the time it takes to carry out an action are the three primary time-critical properties of real time systems with time constraints. To model time constraints: For each event in an interaction, consider whether it must start at some absolute time. Model that real time property as a timing constraint on the message For each interesting sequence of messages in interaction, consider whether there is an associated maximum relative time for that sequence. Model that real time property as a timing constraint on the sequence. For each time critical operation in each class, consider its time complexity. Model those semantics as time constraints on the operation. In the example the left-most constraint specifies the repeating start time of the call event refresh. Similarly, the center timing constraint specifies the maximum duration for calls to getImage. Finally the right-most constraint specifies the time complexity of the call event getImage. duration constraint expression

When to use sequence diagrams?
For each use case They show interaction between objects to realize use case. Alternative: communication diagram

Interaction overview diagram
decision interaction use fork join

Communication Diagram
A communication diagram basically only shows relations between objects that are involved in the realisation of a Use-case. If needed the sequence of messages can be specified using sequence number, but information about parallelism, timing and timing requirements are not shown as a specific dimension Useful when the emphasis is more on the static structure, which objects are involved in this interaction

Communication diagram
The sheet shows an example of what a communication diagram looks like. It models exactly the same situation as the first example of the sequence diagram. When creating a communication diagram you first place the objects participating in the interaction in the diagram. Next you render the links that connect these objects. Finally, you adorn these links with the messages that objects send and receive. A sequence diagram and an object diagram are semantically equivalent.

When to use communication diagram?
For each use case Shows interaction between objects to realize use case. Alternative: sequence diagram

Class Diagrams Advanced Concepts

Recursive Association
A class can be associated with itself. This means that there is a link between two objects from the same class.

Association Class In an association between two classes, the association itself might have properties. In UML this is modelled as an association class, which is a modelling element that has both association and class properties. An association class can be seen as an association that also has class properties, or as a class that also has association properties. An association class is rendered as a class symbol attached by a dashed line to an association.

Examples aggregation and association
The example on the slide shows an aggregation relation between a floor and the lift request buttons. Each floor has 2 lift request button. One to go up and one to go down (except of course the upper floor and the zeroth floor, see the Or constraint on a previous slide). The slide also shows an aggregation relation between a floor door and a floor. There are eight floors with each a floor door.

Examples aggregation and association
The slide shows an example of plain associations and aggregations : Aggregation: A building has 10 floors and 1 lift system. A lift system has 8 shafts. A shaft has 1 lift cage. Association: The lift system gets requests for a lift to go up from zero or more floors. The lift system gets requests for a lift to go down from zero or more floors. Lift cages get requests to go to zero or more floors.

Composition Strong form of aggregation is called composition in UML
Composition characteristics : Part lives only and as long as the whole lives Lifetimes of of whole and part are the same Part is owned by exactly one whole Multiplicity is one on the whole side Example of simple aggregation versus composition : School has teachers is aggregation School has classrooms is composition Composition (composite aggregation or strong aggregation) with strong ownership,and coincident lifetime as part of the whole. This means that the whole is responsible for the parts, the composite must manage the creation and destruction of its parts. Composition is common structure in software systems, object oriented or not, because many composite objects appear in everyday life. For example, a dog is a composite of a head, a body, a tail, and four legs. Other compositions are more conceptual or software specific. For example, an message is a composite of the sender’s name, the receiver’s name, the message title and some other e-stuff. The three most important characteristics of composition are as follows : The composite object does not exist without its components. For example, remove the bristles, the handle and the little rubber thingee from a toothbrush and you no longer have a toothbrush. Indeed, just remove the bristles from a toothbrush and it hardly qualifies as a toothbrush. In this sense, a composite object’s lifetime cannot transcend its component’s lifetimes. At any time, each given component object may be part of only one composite Composition is typically heteromeric. The components are likely to be of mixed types: some wheels, some axles, some bits of wood ..and there’s your wagon

Qualified Associations
association relation without qualification qualified class target class qualifier One of the most common modeling idioms encountered is the problem of the lookup. Given an object at one end of the association, how do you identify an object or set of objects at the other end? In UML this is modeled using a qualifier, which is an association attribute whose values partition the set of objects related to an object across an association. The qualifier is rendered as a small rectangle attached to the end of an association, placing the attribute(s) in the rectangle. In the example the qualifier is floorNumber. After the qualifier has been added the multiplicity between classes can change from many to many to effectively one to many. This is not the case in the example used. Multiplicity after qualification

Parameterised classes
Generic class of which actual class not known until runtime: Generic class has one or more formal parameters Actual class is parameter when generic class is instantiated Synonym: template class Typical use of parameterized classes are containers Generic container class Set with formal class T as argument: Actual class Car can be bound to T at run time by Set <Car> Each of the Set<Car> objects will represent set of cars A parameterized class is a template for creating any number of instantiated classes that follow its format. In its simplest form, you use parameterized classes to build container classes. Not all languages actively support parameterized classes. A parameterized class declares formal parameters. You can use other classes, types, and constant expressions as parameters. You cannot use the parameterized class itself as a parameter. You can also use parameterized classes to capture design decisions about the protocol of a class. The arguments of the parameterized class can be used to import classes or values that export a specific operation. In this form, a parameterized class denotes a family of classes whose structure and behavior are defined independently of its formal class parameters. Graphically a parameterized class is a class icon with a dashed-line box in the upper right corner.

Parameterised class example
explicit binding implicit binding class with an anonymous name The example on the slide shows Set, a typical container class, which takes a class formally named T as an argument. When an actual class, such as Car, is supplied for T (or put more formally, “bound to T”), each of the objects of that class will represent a set of cars. The name of the bound, parameterized class is then given as Set<Car>, which is shown on the left side of the slide. On the right side a class Fleet is shown. Here we see a specific binding of the actual class argument, Car, to Set’s formal class argument T. The dotted arrow, pointing upward explicitly and graphically depicts binding (indicated by the <<bind>> stereotype).

Interfaces Interface described by set of abstract operations
Class, package or component connected to interface : Implements or supports specific interface Interface represents contract that is implemented by object: Programming equivalents are COM en java interfaces Component can choose to implement interface An interface is a named collection of operations. An interface in UML is an abstract notion that cannot be instantiated. Instead, interfaces are realized by either logical elements (classes and packages) or run-time artifacts (components). Interfaces may define an operation and its signature but not its implementation. Neither may interfaces have attributes. A client class may depend on (use) an interface. Interfaces decouple the declaration of a set of services from the entities that provide them.

Interfaces: representation
full interface supplier and client required interface The most common interface notation is the so-called lollipop icon. Dependency arrows show the dependency of the client of the interfaces, class B, on the interfaces of class A and class C. When desired, the interface may be shown as a class box with the <<interface>> stereotype. In this notation, the operations are shown, as well as several classes that can realize the interface. provided interface

Realization Semantic relationship between classifiers :
One classifier specifies a contract Another classifier guarantees to carry it out Relationship often used in combination with interfaces : Interfaces specify a contract for a class Interfaces do not dictate any implementation Class may realize many interfaces : Class provides methods of the interface with implementation A realization is a semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out. Realization is sufficiently different from dependency, generalization and association relationships that it is treated as a separate kind of relationship. Semantically, realization is somewhat of a cross between dependency an generalization. Graphically realization is shown as a dashed directed line with a large open arrowhead pointing to the classifier that specifies the contract. It notation is a combination of the notation for dependency and generalization. Most of the time realization is used to specify the relationship between an interface and the class or component that provides an operation or service for it. Realization is also used to specify the relationship between a use case and the communication that realizes that use case.

Realization example The example on the slide shows a number of Adapter classes which realize the LiftSensorObserver interface. Each of the Adapter classes provide an implementation of the methods in the LiftSensorObserver interface.

Constraints Restrictions on usage or semantics of element
Example is association between Person and Group : Limit membership group on age attribute Number of pre-described constraints available A constraint is a restriction on the use of an element. A restriction can be declared in the tool and be used repeatedly in different diagrams or it can be defined in a diagram and used at will. A constraint is depicted between braces: {constraint}. In UML there are 14 standard constraints: association, global, local, parameter, self, complete, disjoint, incomplete, overlapping, implicit, or, ordered, vote (‘stem’) and broadcast. It is also possible to work with user-defined constraints. On generalisation 4 constraints are used: complete (all sub-classes are specificied), incomplete (not all sub-classes are specificied, standard), disjoint (non-overlapping inheritance) and overlapping (overlapping inheritance). Two standard constraints can be used for association: implicit and or. The implicit constraint indicates that an association is conceptual is instead of physical. The classes are associated but the objects do not have to be aware of each other, the objects have no physical links. In this case the association takes place via another means, for instance a query.

Constraints Example: Ordered association {ordered}
Constraint ordered means that the links ({LiftCage, FloorRequestButton} instances) are ordered. The FloorRequestButtons are positioned in order in the LiftCage A constraint can be applied to the structural relationships to add more meaning. If an association has objects with a multiplicity greater than one at one end, you can specify that they are ordered or unordered. The constraint {ordered} specifies that the objects at one end of the association are ordered. In the example the floor request buttons are positioned in order of floor. Other constraints are: implicit: the relationship is not manifest but conceptual. changeable: links between objects may be added, removed, and changed freely. addOnly: new links may be added from an object on the opposite end of the association frozen: a link, one added from an object on the opposite end of the association, may not be modified or deleted. xor: over a set of associations, exactly one is manifest for each associated object.

Constraints Specify conditions that must be true for a well formed model : Value constraints on class attributes Pre-postconditions and invariants Constraint modeling in UML : Free-form text between brackets More formally described by OCL (object constraint language) A number of constraints are predefined in UML A constraint is an extension of the semantics of a UML element, allowing you to add new rules or to modify existing ones. A constraint is some additional restriction, above the usual UML “well-formedness” rules, applied against a modeling element. Timing constraints can be shown on sequence diagrams, specifying the time between messages, for example. Graphically, a constraint is rendered as a string enclosed by brackets and placed near the associated element or connected to that element or elements by dependency relationship. As an alternative, you can render a constraint in a note.

Dependencies A modelelement A is dependant of modelelement B means that, when the interface of B changes, also A has to change. Most common dependency. One class uses another class as a parameter for an operation. Modeled by drawing a dependency to the class used as parameter. It is also possible to use a class as return type of an operation. A dependency is a using relationship that states that a change in specification of one thing may affect another thing that uses it, but not necessarily the reverse. Draw a dependency relationship between two classes, or between a class and an interface, to show that the client class depends on the supplier class/interface to provide certain services, such as : Client class accesses a value (constant / variable) defined in the supplier class/interface. Operations of the client class invoke operations of the supplier class/interface. Operations of the client class have signatures whose return class or arguments are instances of the supplier class/interface. Typical uses of dependency relations are : Using a parameter of some class type When objects are created Dependencies describe class relations, like generalizations. Associations however describe object relations. Both an association relation and a generalization relation imply a dependency relation. Dependency relations can also be drawn between logical packages.

Dependency example The slide shows a set of classes drawn from a system that manages the assignment of students and instructors to courses in a university. A dependency relation from CourseSchedule to Course is shown because Course is used in both the add and the remove operations of CourseSchedule. If the full signature of the operation is provided, as in the slide, it is not really necessary to show the dependency because the use of the class is already explicit in the signature. You will especially want to model this relationship if the operation signatures are invisible or if the model shows other relationships to the used class. The slide also shows another dependency. This one is not involving classes in operations but rather the modeling of a common C++ idiom. The dependency from Iterator shows that Iterator uses the CourseSchedule. The CourseSchedule knows nothing about the Iterator. The dependency is marked with a stereotype, which specifies that this is not a plain dependency, but, rather, it represents a friend, as in C++.

Dependency stereotypes
Packages access import Use Cases extend include Classes and objects access bind call create derive instantiate permit realize refine send substitute trace use Eight stereotypes apply to dependency relationships between classes and objects: bind: the source instantiates the target template using the given actual parameters derive: the source may be computed from the target friend: the source is given special visibility into the target instanceOf: the source object is an instance of the target classifier instantiate: the source creates instances of the target powertype: the target is a powertype of the source; a powertype is a classifier whose objects are all the children of a given parent refine: the source is a finer degree of abstraction than the target use: the semantics of the source depend on the semantics of the public part of the target Two stereotypes apply to dependency relationships between packages: access: the source package is granted right to reference elements of the target package import: the public contents of the target package enter the namespace of the source, as if they had been declared in the source

UML Overview UML Overview. Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005.

Similar presentations

Presentation on theme: "UML Overview UML Overview. Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

UML Overview UML Overview. Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005.

Similar presentations

Presentation on theme: "UML Overview UML Overview. Object georiënteerd Ontwerpen met UML Saxion Hogeschool Enschede, januari 2005."— Presentation transcript:

Similar presentations

About project

Feedback