The Unified Modelling Language

The Unified Modelling Language
Introduction This part of the module will introduce a graphical modelling notation. The chosen notation is the Unified Modelling Language (UML) - which is an OMG standard for expressing object-oriented designs. Through the next two sessions in the System Partitioning module you will be introduced to this notation and see the relevance of it to your chosen discipline.

Overview Session One Lecture Tutorial Post Session Session Two Lecture
An introduction to the UML Bank account case study Tutorial Practical Exercise Post Session Reading Session Two Lecture UML for real-time systems Traffic Light Case Study Other bits of UML Tutorial Practical Exercise (assessed) Post Session Reading on further examples (2PC and transaction processing). There will be a balance of information conveyed through lectures, which will also include a few practical exercises for you as we go through the material. After each of the lecture sessions there will be a tutorial. This is basically a pencil and paper exercise that you will do in small groups (3-4 students) at your desks. There is also a post session article for you to read - one of many items freely available from the Internet. A selection of resources is included at the very end of this handout material. The tutorial after session two will also be group work - but this work will be collected in and used as a basis for assessed coursework. This is obviously important as you will receive a mark for this work, but you will also receive feedback on the coursework which will support your studies.

Session One

Aims of Session One Aims:
Provide an overview of the main components of UML Use Cases, Class Diagrams, Interaction Diagrams, Activity Diagrams and State Charts CRC cards will also be mentioned as a useful technique Cover basics of object-oriented concepts and terminology Encapsulation, Inheritance and Polymorphism This session will introduce key UML diagrams as listed above. Note that you will find references to other types of diagram if you read around the subject of the UML - you will find though that these other diagrams are generally based on one of the above variations i.e. making use of the same notation in a different context.

Managing Complexity System development is hampered by the complexity
Software and hardware engineering has developed techniques to manage this complexity These depend on hiding detail not essential to the task in hand Such an approach is known as abstraction

About the UML The Unified Modelling Language (UML) is an industry standard for object oriented design notation, supported by the Object Management Group (OMG). It is becoming widely adopted in many areas of the software and computer systems development community. The UML combines the best practice from a number of other techniques and notations; Booch, OMT, OOSE, Statecharts and others. In essence then there is nothing new about the UML in itself - it is a combination of best practice from existing notations/techniques. UML has been an OMG standard since The most recent standard version is 1.5, though work on 2.0 is underway. The UML can have a variety of purposes and applications - most simply it comes down to using it as a communication technique. The notation provides a standard for diagrammatic representation - in the same way that here we agree that the standard for text and language will be English. The old adage that a picture paints a thousand words is true for many of us - we respond more quickly and readily to a diagram than having to read lots of additional text in order to understand someone's problem or design. Think about the occasions when you have to resort to drawing a picture/diagram to explain. Some references included in slides at end of notes

Key Diagrams in UML Requirements Capture System Structure
System Behaviour Use Case Diagram Class Diagram This part of the course will give you an introduction to key elements of the UML notation - it is not a blow by blow account of all the standard notation - the latter would be neither particularly helpful nor interesting! Like many standards there is much more in it than you will ever really want to know - but it is important to know that it exists. The lectures we will cover do not tell you all there is to know about UML - all we are trying to do here is give you a way into the notation and gain some insight in what it has to offer. The above slide summarizes the parts of the UML that we will explore through the two sessions. There is also something called CRC cards that we will mention. The CRC cards are *not* part of the UML - but they are a useful technique to know about for reasons that we will discuss later. As a post-sessions exercise, if you search for CRC cards on the Internet you will see that they are a fairly common topic when developing and testing OO designs using the UML. Interaction Diagrams Activity Diagrams State Charts (+ CRC cards)

Activity Take a couple of minutes to read through the introductory Bank Account case study on the following two slides. The aim is to try and pull out the key things which we might want to represent in a model of the Bank as described. Focus on requirements Could also look for candidate classes and methods Think how you would most naturally express these requirements (written list, diagram etc.)

Introductory Case Study The Bank Account
You are asked to design a system to handle current and savings accounts for a bank. Accounts are assigned to one or more customers, who may make deposits or withdraw money. Each type of account earns interest on the current balance held in it. Current accounts may have negative balances (overdrafts) and then interest is deducted. Rates of interest are different for each type of account. On a savings account, there is a maximum amount that can be withdrawn in one transaction.

Introductory Case Study The Bank Account
Bank employees may check any account that is held at their branch. They are responsible for invoking the addition of interest and for issuing statements at the correct times. A money transfer is a short lived record of an amount which has been debited from one account and has to be credited to another. A customer may create such a transfer from their account to any other. Transfers within a branch happen immediately, while those between branches take three days.

The Bank Case Study Use Case Diagram Class Diagram Activity Diagram
Examine and capture requirements Class Diagram Start to examine system structure Activity Diagram Illustrate dependencies in system Interaction Diagrams Express system dynamics Through the bank account case study we will explore examples of the above. We will then go on to look at state charts as a separate issue i.e. outside the context of the case study.

Use Case Modelling Nearly all OO analysis and design methods now use Use Cases to represent requirements. Use Case Modelling was invented by one of the three main contributors to the UML development, Ivar Jacobson. This is a very simple model, which is expressed in very simple terms in the UML notation through a Use Case diagram. It provides us with an external view of the system. Let us now consider introducing an example Use Case Model of the bank example. We will do this using the UML notation of a Use Case Diagram.

Use Case model of the bank
deposit withdraw aCustomer transfer statement teller A use case model can be shown as a use case diagram - but note that the diagram is not the model. Such a diagram shows actors the roles adopted by those participating use cases high level activities to be supported by the system links which actors are involved in which use cases This is one possibility add interest

Actors An actor indicates an external person or system which is involved in a use case The same person or system may play the role of more than one actor, depending on the context An actor may be a set of roles, which are related An actor may be involved in more than one use case One actor is normally the initiator of each use case

Use Cases The use case symbol indicates an activity which will supply value to an actor Within each use case there must be a description of what this activity does for the actor Use cases can be described by English descriptions - active voice, present tense State charts Activity diagrams Any other means as preferred The use case diagram is not the full representation of the use case model - it will rarely stand on its own. There are many techniques for describing Use Cases; commonly English will suffice i.e. a text description. The use of active voice aims for clarity Active - Hazel eats an apple a day Passive - each day an apple is eaten by Hazel

Activity Take a minute to read through the following use case description. The example concerns making a Deposit.

Use Case Description - Deposit
The customer passes over to the bank an amount of money, in some combination of cash and cheques. The customer specifies which account is to be updated. The teller checks the money and authorises the updating of the relevant account. If the money is incorrect or the account does not exist the teller informs the customer, returns the money and the account is not updated.

Notes On The Description
The customer is the actor that initiates the deposit. The inputs to the use case are identified. The outcomes are identified. Two exceptions are identified and the alternative outcomes are given. The use case is adequate for the users to agree that it is accurate, without becoming a design. The main emphasis is on the user friendliness of the Use Case technique and the simplicity of the notation set. At first glance it perhaps seems too simple, but as with many simple techniques it can be very powerful and help to raise all manner of questions ... QUESTIONS Throughout the course as you sit there soaking up this information there will no doubt be many questions that come to mind. This is important - most learning is achieved through questioning what you are told! To help this process I have included a few questions to provoke some thought. We won’t go through this now, but it is worth mulling over during coffee and maybe important to return to in the tutorial or in follow up discussion with your colleagues (be aware that there are no definitive answers to many of these questions). Look back at the use case diagram for the bank account case study introduced earlier in the notes - what questions does it make you ask? Are the use cases well defined? Are they distinct? Do they share common parts? Is there always only one successful outcome? Can use cases really avoid some design decisions? Are Use Cases Object-Oriented?

Class Modelling

Classes and Objects An object is a means of partitioning the solution to a design problem. Objects are similar to modules in some ways. Object = Identity + State + Behaviour Objects provide encapsulation of data. An object is described by a class. A class may define a number of objects with identical properties. Remember that what we are basically trying to do is partition the solution to a problem - it should help structure our understanding. Terminology: Objects are similar to modules in some ways - there is a subdivision of something. Traditionally the modular split tended to focus on the functionality. Objects focus on the data and the functionality particular to that data. In this case we tend to talk about an objects behaviour. Object can be characterised by having Identity, State and Behaviour A bit more terminology - objects are described as encapsulating data. This is a form of data abstraction and hiding. The state of an object is hidden away from the outside world - a point we will return to … A class represents a group of objects - or may be referred to as the type of an object. In a more embedded system sense we can think about similarities between IP(Integrated Processors) and SoC (System on Chip). How does an object compare to an IP block? An IP block has public interface An IP block can have internal memory The memory can be structured: registers, FIFO queues, etc An IP block is linked to other blocks by a circuit or a bus

So, how do we identify objects?
What’s In An Object An object has a public interface defining the operations it will support. Often termed methods An object has private data, attributes, which only its own operations can access. An object can have private operations, for its own use. An object may know about other objects via associations. Consider our description of an objects characteristics; We said it had an identify (i.e. name), state and behaviour. The behaviour is in part described by the objects public interface. This interface informs the outside world what operations can be performed on the object. These operations are often called methods, particularly so with regard to an OO program implementation in C++ or Java for example. The state is represented by the internal data, or attributes, of the object. Ideally only the objects operations can act on the internal data. An object can also have internal operations which are solely for its own use. An object may know about other objects by associations. Apart from anything else, this has introduced more terminology. Lets move on by looking at how we identify objects ... So, how do we identify objects?

Identifying Objects A simple recipe
Step 1: We can identify objects in our problem statement by looking for nouns and noun phrases. Step 2: Each of these can be underlined and becomes a candidate for an object in our solution. Step 3: We can eliminate some objects by some simple rules. We must make sure that our objects fit in with our use cases. There is no single solution or approach to this - it is one of those things where intuition and experience account for a great deal. There are a number of approaches described. The most common is to consider the problem statement and scan for noun and noun phrases. In choosing objects we must ensure that they fit out use case requirements - we are therefore not looking for every object we can possibly consider.

Activity Take a couple of minutes to read through the case study description of the Bank Account introduced in the previous lecture. The aim is to have a go at identifying what you think may be candidate classes and objects based on the approach identified on the previous slide - i.e. identification of nouns and noun phrases.

Nouns in the bank account example
You are asked to design a system to handle current and savings accounts for a bank. Accounts are assigned to one or more customers, who may make deposits or withdraw money. Each type of account earns interest on the current balance held in it. Current accounts may have negative balances (overdrafts) and then interest is deducted. Rates of interest are different for each type of account. On a savings account, there is a maximum amount that can be withdrawn in one transaction. Bank employees may check any account that is held at their branch. They are responsible for invoking the addition of interest and for issuing statements at the correct times. A money transfer is a short lived record of an amount which has been debited from one account and has to be credited to another. A customer may create such a transfer from their account to any other. Transfers within a branch happen immediately, while those between branches take three days.

Rules for rejecting nouns
1. Redundant - overdraft, account 2. Vague - amount, money 3. An event or an operation - transaction, deposit 4. Outside scope of system - bank, days 5. Meta-language - transaction, correct times, record 6. An attribute - interest, rate of interest, maximum amount, current balance, overdraft Having marked all the candidates we can work through then and discount a number. There is again no formal approach which guarantees success. Though this slide provides a simple checklist which is worth considering. It is important to realise that finding candidate objects is not a one-pass process. It is likely, and more feasible that the final set of objects will not be determined in one go - the rule of thumb here, if you are not sure whether to include an object or not is ‘if in doubt leave an object in’.

expressing our class model
Nouns Left current account savings account customer branch statement transfer Now we need to consider some graphical way of expressing our class model This shows our current candidate list of objects. Now we need to turn to UML for a method to describe these objects … we do this in the form of a class model which is described in terms of a class diagram ...

withdraws and deposits money with
Class Diagram Associations between classes 1 0..* Current account Savings Statement Branch Customer Transfer withdraws and deposits money with holds moves money to summarises The basic rectangle is used to represent a class (called a classifier in UML) We draw lines between the classes to represent associations between objects of that class. We can attach labels to the association lines to ease reading - these give a name to an association. We can also add multiplicities to show the degree of association - very much like entity-relationship diagrams. Note how they are read a branch holds 0 or more current accounts. a current account may be held by a branch only.

withdraws and deposits money with
Class Diagram Showing class details 1 Transfer Savings Account Statement Branch Customer withdraws and deposits money with holds summarises moves money to 0..* Current -balance : real We can provide further detail in the class diagram about the state and behaviour of objects of a particular class. The rectangle is split into three sections. 1. Name at the top 2. Attributes in the middle protection + (public), # (protected) or - (private) label : type 3. Operations at the bottom protection +, # or - label(parameters) (parameter is label:type or just type) : type (optional return type) On this diagram we also show navigability on the association links between classes. The arrow shows the direction of navigation i.e. who knows about whom in the association. Ideally … Attributes are private and accessed via operations +withdraw(a:Real) +deposit(a:Real) +curBal():Real

Navigability Open arrow heads on the associations show navigability
This indicates which object needs to know about which other object to make an association work We try to keep navigability one way to reduce coupling Where no navigability is shown this can mean two way or not yet defined - be consistent QUESTIONS: These are more points to consider about our models so far ... How well chosen are the associations? Do we need a class Customer? If we do, why not a class Employee? Why is the association between Customer and each of the accounts two way? Is this right? How do the two types of Account differ? Do we need two classes for them? How do we decide if something is a class or an attribute?

Inheritance One obvious cause of additional costs and difficulties of maintenance is duplication of functionality Large, unstructured systems often contain large amounts of code performing the same tasks In structured methods modules and libraries of standard functions are used to reduce this Classes allow us to define a type of object once and duplicate it as needed in our programs Now we are going to look at something that is more of a design and implementation issue …

Generalisation and Specialisation
We can go further than classes which define identical objects in one place We often find that objects are very similar without being identical The parts of different classes which are the same can be factored out as a generalisation of all of them The differences can be added to this to form a family of specialisations employee manager analyst developer generalisation Objects give us greater flexibility than standard functional libraries - this is where the power of the object-oriented approach starts to appear ... specialisations

Specialisations generalisation *or* parent class *or* super-class employee manager analyst developer specialisation *or* child class *or* sub-class Specialisations may have additional attributes and/or operations Specialisations may have different implementations for operations In this case we show everything in the super-class and repeat the different operations in the sub-classes Confusion can easily be caused by variations in terminology ...

Polymorphism A specialisation may also redefine operations which were implemented in its parent. employee printDetails() Also referred to as overloading of methods where can have same method name but different signatures developer analyst printDetails() printDetails(int x) manager It may be that the parent class does indeed have an implementation of one or more operations, and that all the subclasses need to do is provided their own implementation. In this case the parent class is not abstract. The operation in the subclass is said to OVERRIDE the implementation in the parent class. This is know as polymorphism printDetails() printDetails()

Class Diagram using Specialisation
Account Statement Branch Customer Transfer holds moves money to summarises 1 0..* Current Account Savings Our initial list of noun clauses included account savings account current account What is the difference? We rejected account as adding nothing to the others - it was redundant

An Example Account {abstract} -balance : Real -rate : Real
CurrentAccount SavingsAccount {abstract} -balance : Real -rate : Real -chequeNo : Integer +withdraw(a:Real) +deposit(a:Real) +curBal():Real +newBook() Reason why this is shown as one possibility … Focus on relationship between the generalisation class Account and it’s specialisations CurrentAccount and SavingsAccount The specialisations INHERIT attributes and operations from the parent class. This is supplemented with their own attributes and/or operations The abstract class is marked with the property abstract in curly braces i.e. {abstract}. Anything in curly braces shown in such a way is a property or constraint on all objects of that class.

Interfaces Since we are only allowed to see the operations of a class, two classes with the same operations should be interchangeable. This gives us the most abstract view of an object - its interface. If someone else is developing the class from which some of our objects are derived, all they have is the interface. We can still build our part of the system. An interface is basically a class with no attributes and only method signatures - if it had attributes then it would just be an abstract class in the way already described. The signature promises the functionality of any class that then implements that interface - it is a form of a contract ...

Interfaces In UML Exchange Exchange <<interface>> Transfer
move cash <<interface>> Transfer Transfer move cash Account Account The Account relies on something that will implement the transfer interface. Java makes extensive use of these for event handling e.g. Java has a number of interfaces defined for handing events, such as mouse clicks and actions such as buttons being activated. If you want to trap these events then you must define a class which implements a specific interface defined by Java e.g. The actionListener interface has a single method actionPerformed(e ActionEvent) {} <<uses>>

CRC Cards

Linking Classes and Use Cases
Each use case will be carried out in terms of actors and objects. Objects are based on classes. Actors and objects send and receive messages. Messages invoke operations. An operation may send messages to invoke further operations. As stated early on in the lecture, a goal of UML is to unify the OO approach across the system lifecycle. In line with this we should consider how the classes we have determined todate are used in fulfilment of the use cases determined earlier … Each use case will be carried out in terms of actors and objects. The objects are based on the classes so far defined. Actors and objects interact by sending and receiving messages The messages they communicate result in operations being invoked on objects. An operation invoked on a particular object may invoke methods on other objects with which it has an association.

Interactions and Scenarios
A sequence of messages, possibly including alternatives, is called an interaction Each separate alternative for an interaction is called a scenario A use case will be implemented by a set of scenarios, making up all the outcomes of an initial message from the initiating actor The objects in the system must support all the operations required by all the use cases Interactions and scenarios will be covered in detail in the next lecture - but we need a few more words on them before we continue … A sequence of messages is referred to as an interaction. A scenario is one possible path through the system, and in this way considers an alternative set of interactions. A use case, being a requirement of the system, will be implemented by a set of scenarios, defining all possible outcomes from an initial input from an actor. The important point is that the objects we have defined MUST support all the operations required by the use cases defined - else we have something wrong somewhere and need to revise one or other of our models or thinking!

CRC Cards to Explore Use Cases
Class, Collaboration, Responsibility cards are a method of exploring how well a class model supports use cases (Wirfs-Brock). There is a card for each class. Each card has the name, the responsibilities and the collaborators of that class. They are used to role play the design and check if it is complete. CRC cards are not part of the UML standard, but are a useful technique so worth mentioning here … it is a very practical and hands-on technique.

CRC Card for Current Account
Class name Maintains an account’s balance. Allows transfers. Accumulates interest. Transfer Statement Collaborators Responsibilities

Playing the CRC cards Draw up a card for each class.
Allocate cards to people in the design team. Each person acts out their role, starting with the invocation of the use case. A card takes responsibility for its job in the interaction or passes responsibility to a collaborator.

Modelling Interactions using Interaction Diagrams Activity Diagrams State Charts

Showing Interactions Importance of exploring interactions
We particularly want to develop scenarios and check them. Key phrase to focus on “Scenarios of usage” Showing how static structure support dynamic behaviour There are two types of interaction diagram in UML: Sequence Diagram Collaboration Diagram These will both be examined through the following slides

Sequence Diagrams show sequences of messages with the emphasis on the order in which they are sent
Background to Sequence Diagrams Origin outside of the UML in message sequence charts (MSCs) MSC have international standard maintained by the International Telecommunications Union (ITU) MSCs are used on their own or in other design notations, such as the ITU System Design Language (SDL) Development of separate standards?

Sequence for a successful deposit
ac1:Account c:Customer b:Branch :aCustomer :Teller deposit(v,a,name) c:= getRec(name) ac1 := getAcc(a,c) addToBalance(v)

Synchronous (procedure)
Messages May be numbered and nested Parameters may be passed Values may be returned using assignment := Messages may be conditional - use of guards (expression in square brackets) Sub-sequences may be enclosed in a box - helpful? Messages or sub-sequences may be repeated * Synchronous (procedure) Flat (thread) Asynchronous (concurrent) Return from synchronous [v<30] Guard *[x>10] Iteration Note that all case tools do not necessarily support this range of message types - Rational Rose for example only supports one type of arrow - which interestingly corresponds to the flat message type ... v=getval() [v>10]setval(v) * Repeated sequence [v>0]

Synchronous Messages m(p1,p2) o1:C1 o2:C2 m(p1,p2) o1:C1 o2:C2

Asynchronous Messages
The sender is not blocked Messages may be sent in either direction Behaviour is genuinely concurrent Return values cannot be implied m1(p1,p2) o1:C1 o2:C2 m2(p3,p4) o3:C3

Flat Messages The sender stops and waits to receive a message
This does not imply that the next message is a direct reply to the one sent Java’s threads are typical examples m2(p3,p4) o1:C1 o2:C2 m3(p5) o3:C3 m1(p1,p2)

Collaboration Diagrams show how systems are built from objects and how messages get sent.
A collaboration is a collection of instances or objects which are associated with each other The classes from which the objects are derived must have associations There may be multiple instances of any class present Only those associations relevant to the current scenario need to be shown

Collaboration for a successful deposit
ac1:Account b:Branch c1:Customer 1.1:c:= getRec(name) 1:deposit(v,a,name) 1.2:ac1 := getAcc(a,c) :ACustomer :Teller 1.3:addToBalance(v) Message Numbering: Message numbering is a way of defining their order Procedural (synchronous) messages are ordered in a nested way to show cause and effect etc. Parallel or concurrent sequences are independent of each other. 1.1.1a and 1.1.1b represent the start of concurrent sequences. 1.1.1a a.2 etc. 1.1.1b b.2 etc. Other notation from class diagram: These add extra information about an association between classes Aggregation Composite

Activity Diagrams Limited capabilities of English language
Rich, but so complex! Advantage of more formal notations Clarity and simplicity? Two situations considered here: to define individual use cases to express dependencies among use cases

Activity Diagram for single Use Case
The example on the following slide is taken from the OMG UML notation guide and shows a single action sequence Possible single use case Get Beverage

[no coffee] [no coke] Find Beverage [found coffee] [found coke] Put Coffee in Filter Add Water to machine Get Cups Put Filter in machine Get Can of Coke Turn on machine /coffeePot.turnOn Brew Coffee Notation Summary: Activity Start State End State Transition Synchronization Decision point Guard (condition) [cond] light goes out Pour Coffee Drink

Dependencies between Use Cases
Consider the bank account case study … Initial requirements were fuzzy ... What about opening a new account? Consider the situation where a Manager needs to authorise the opening of a new account … What else does the Manager do?

Open Account Teller Manager Paper work Customer A possible revision to previous use case diagram?

Since the use case diagram shows only actors, not instances of actors, it is difficult to express the dependency in them We could show the Manager as a specialisation of the Teller … helpful? How to show the dependency between two use cases? complicated interaction diagram? More convenient to use an activity diagram with swimlanes Teller Manager

Open New Account Teller Manager Customer [no accounts to do] Done Free
Enter Free [accounts to do] Ready Doing Accounts Request Authorisation Complete Wait Teller Manager Customer

State Charts internal behaviour of an object
Now we are going to look at how objects behave. This concerns modelling dynamic behaviour at a lower level than we were able with interaction and activity diagrams - those types of diagram look at interactions BETWEEN objects. We are now looking inside the object … One way to do this (for software) is to give the code for the methods (functions) which support each operation. Another (for hardware) is to produce Verilog/VHDL In UML the general behaviour of an object can be shown in a statechart All objects of the same class (not just the same interface) have the same statechart.

An Example Statechart XtoMove XhasMoved YhasMoved YtoMove move(
r,c) / ^ umpire.validate(‘ X’,r,c) XtoMove XtoMove XtoMove XhasMoved invalid() / ^ xPlayer.makeAMove() valid() / ^ yPlayer.makeAMove() valid() / ^ xPlayer.makeAMove() move( r,c) / ^ umpire.validate(‘ Y’,r,c) ACTIVITY: Consider the start chart about - what is this a state chart for? YhasMoved YtoMove invalid() / ^ yPlayer.makeAMove()

Actions on Transitions
Once triggered, a transition is said to fire A transition may cause actions as part of its firing Some actions are changes to local or global variables count++ Some are output actions, sending messages to other objects ^umpire.validate(‘X’,r,c) Actions follow the / symbol

Kinds of trigger [ tries<6] ask(m) WantAnAnswer FindingAnswer
after(10secs) / tries++ tries :=0 ^reply(r) when(tries=6) / ^reply(“failed”) In addition to the receipt of a message, there are other kinds of trigger event that we can consider: A transition can be triggered by the passage of time after(10secs) A transition can be triggered by a condition becoming true when(tries=6) A transition can be triggered implicitly by the completion of the internal activity of a state A trigger can be guarded by a condition (guards) [tries<6]ask(m)

Nested States and Super States
when(checked) Check answer Get question requesting question(m) WantAnAnswer FindingAnswer [ tries<6]ask(m) after(10secs)/ tries++ ^ reply(r) when(tries=6)/^reply(“failed”) tries :=0 requesting A super state is one containing an internal state machine The internal state machine must have a start state and an end state The transitions arriving at a superstate all go to the internal start state The transitions leaving all come from its end state

Entry, exit and do actions
As well as labelling transitions with actions, it is possible to define actions within a state entry defines an action to be performed on entering a state exit defines an action to be performed when leaving a state do defines an action to be performed while in a state updating entry/checkBalance() do/addBalance() exit/tellBalance()

Concurrency, Synchronisation and Conditions
Conditional states Concurrency Notation is common with Activity Diagrams

Showing Fuller Behaviour
Waiting Thinking yPlayer:Player move( r,c)/^ umpire.validate(‘ X’,r,c) XtoMove XtoMove XtoMove XhasMoved invalid()/^ xPlayer.makeAMove() Waiting valid()/^ xPlayer.makeAMove() valid()/^ yPlayer.makeAMove() move( r,c)/^ umpire.validate(‘ Y’,r,c) Checking umpire:Checker YhasMoved YtoMove b:Board invalid()/^ yPlayer.makeAMove() The collaboration and statechart diagrams can be combined to get a complete model of behaviour Can you complete the picture for the players and umpire? What about start and end states? What about game logic? Waiting Thinking xPlayer:Player

Tutorial and Post Session Work
Tutorial Work: After a welcome coffee break, work in small groups (3-4): Review the lecture notes and consider any questions at this point Examine the tutorial exercise on the following slides

Tutorial and Post Session Work
Read back through session one notes and look at some of the questions posed in note text below slides. Read the provided hand out: The UML for Systems Engineers, Bruce Powel Douglass, I-Logix What other UML notation elements do you know about or can you find out about? What sources would you use?

Tutorial Session Exercise 1 - Use Case Diagram
A simple word processor is required to create new and edit existing documents. The word processor is required to support standard operations such as cut, paste and spell check. The ability to print is also required. Question : Prepare a use case diagram that captures the requirements of the word processor Exercise 2 - Use Case Diagram A CD shop requires a system to help manage sales and stock. The shop maintains a list of stock to track customer sales, returns of goods and deliveries of new stock. The stock list is also used to allow queries of items that are in stock in the event that they cannot be located on the shelves. Question: Prepare a use case diagram that captures the requirements of the CD shop.

Tutorial Session Exercise 3 - Class Diagram
A new company wishes to enter the computer board games market. They intend to produce a range of on-screen versions of well known two-player games, starting with noughts and crosses (also known as tic-tac-toe) and chess. The users share a screen and make moves in turn. The program makes sure that only legal moves are allowed and declares a winner at the appropriate point. To make the implementation of new games easy, and to ease the work of maintaining many different games, the company want to design a game framework, which can be reused as frequently as possible. The noughts and crosses game is played on a 3 by 3 square board between two players. The player who starts (PlayerX) chooses a square of the board and puts a cross in it. The other player (PlayerO) chooses an empty square and puts a nought in it. Thereafter players continue to alternate, placing their own token in empty squares. The winner is the first player to complete a straight line (horizontal, vertical or diagonal) of three of their own tokens. If the board is filled without either player achieving this then the game is a draw. Question: Find the classes and draw the class diagram for the above noughts and crosses game. If you are doing this as a group activity then make sure that all members do know how the game works before proceeding. Once you have this initial class diagram think how you might develop this into a more general game framework as outlined above.

Session Two

Overview Aims: Session Two Lecture Tutorial Post Session
Review of UML notation relating to real-time and embedded systems Learn about some other useful bits of UML! Session Two Lecture UML for real-time systems Traffic Light Case Study Other bits of UML Tutorial Practical Exercise (assessed) Post Session Reading on further examples (2PC and transaction processing). There will be a balance of information conveyed through lectures, which will also include a few practical exercises for you as we go through the material. After each of the lecture sessions there will be a tutorial. This is basically a pencil and paper exercise that you will do in small groups (3-4 students) at your desks. There is also a post session article for you to read - one of many items freely available from the Internet. A selection of resources is included at the very end of this handout material. The tutorial after session two will also be group work - but this work will be collected in and used as a basis for assessed coursework. This is obviously important as you will receive a mark for this work, but you will also receive feedback on the coursework which will support your studies.

Particulars of RT Domain
Two questions: What are we interested in modelling? What UML notations/diagrams can we use? Timing Information: Important for dependencies and synchronisations Interactions: Need to model message passing / communication Consider the above questions - this helps to put the UML standard in context of what you need to model in the real-time domain. This slide is trying to get you to ask questions about what it is that you need to be able to model, rather than just asking how to do something in UML. It is important that you see what needs to be modelled - then we can look at how. There are many issues concerning real-time and embedded applications concerning Quality of Service (QoS), low-level programming and safety/reliability. It is important that we model with these issues in mind. Existing Standard Diagrams: Activity diagrams, interaction diagrams, state charts plus all the other diagrams have their place Stereotypes and guards: Help to convey timing information

Activity Take a couple of minutes to read through the case study description of a traffic light junction on the following two slides. Convince yourself that you understand it and see if you agree that it describes a traffic light fully and accurately. If not, what other assumptions would you want to make?

Traffic Light Case Study
You are asked to design a system to control the traffic lights at a road junction. Lights are set to one or more colours, which determine what cars may do. Each combination of colours permits different actions for cars approaching it. Red means “stop”. Green means “carry on” or “start moving”. Amber means “slow down ready to stop”. Red and amber together mean “get ready to move off”. The lights change according to the following rules: the lights have not changed for 90 seconds they move through the sequence from green to red, via red and amber, or from red to green via amber if there are cars waiting at a red light and no cars approaching the green light, the change sequence occurs if a pedestrian pushes the crossing button on a light, the change sequence occurs if that light was on green There is one important additional aspect of this particular example, which causes us to look for new solutions. The problem supposes a junction with a number of roads meeting. Since these roads have to be controlled in a synchronised manner, there is a real time aspect to the problem. How do we ensure that the lights are not merely following their individual sequences, but that these sequences are in time with each other? For the purposes of this case study we will restrict our initial discussion to a classic cross-roads, which is shown in the illustration on the following slide. Each of the four roads which meet at the junction requires its own traffic light, which must work together with the others. The timing of changes of lights has very important consequences for two categories of user, since both drivers and pedestrians need to be able to gain safe passage across the junction. The overall state of the junction, which is made up of the combination of the states of the individual lights, has to ensure both progress and safety. If lights become out of synchronisation, safety will be compromised. If combinations allowing progress for any given potential user cannot be achieved repeatedly, the junction will not function as required.

Traffic Light Case Study
The above is a simple illustration of the traffic light junction (which may help you to focus your thinking!). Each traffic light is the standard configuration - having three coloured lights - one green, one amber and one red.

Activity Consider your thoughts developing on the traffic light case study. What requirements can you identify? Develop a use case diagram that captures the requirements. Perhaps start by identifying actors and then think in terms of what the resulting system must satisfy.

Use Case Diagram Is the level of detail represented in the above diagram appropriate/helpful? Remember that it is better to think in terms of an appropriate/helpful level of detail rather than trying to focus entirely on precision or accuracy. Does it help to add navigation details to the associations between actors and the use case?

Activity Consider your thoughts developing on the traffic light case study. Moving on from the requirements we are now going to examine a structure for the system. What classes can you identify? What associations can you form between them? Don’t go for too much detail at the moment - develop a basic class diagram that would support the requirements of the system. Think about the approach to identifying classes from the last lecture.

Simple Class Diagram Button TrafficLight Timer requests crossing
synchronises

Activity Considering the basic class diagram presented on the previous slide spend a few minutes to look at adding additional detail in terms of: navigation and multiplicities

Extra details Button TrafficLight Timer * 1 requests crossing
synchronises 1 *

Activity Considering the basic class diagram presented on the previous slide, look at adding additional detail inside the classes in terms of: attributes and operations Focus on the Timer and TrafficLight classes

Extra details Stereotype Constraints / Properties
Button requests crossing * 1 TrafficLight - setting:{ red,green,amber} + change():void RTtimer» Timer { isPeriodic = True, interval = 90} synchronises isPeriodic : Boolean interval:TimeInterval reset Constraints / Properties Stereotype Attributes and operation specified in profile

UML TM Profile for Schedulability, Performance, and Time Specification
The RFP called for “proposals for a UML profile that defines standard paradigms of use for modeling of time-, schedulability-, and performance-related aspects of real-time systems” that would: Enable the construction of models that could be used to make quantitative predictions regarding these characteristics Facilitate communication of design intent between developers in a standard way Enable interoperability between various analysis and design tools This is just the first part of a larger initiative created by the OMG Real-Time Analysis and Design Work Group to develop a comprehensive solution to the modeling of real-time systems. Submitters (in alphabetical order): – Artisan Software Tools, Inc. – I- Logix Inc. – Rational Software Corporation, Inc. – Telelogic AB – Timesys Corporation – TriPacific Software Subsequent parts are expected to deal with more general quality of service aspects (i.e., beyond time-related issues, including availability, reliability, etc.) and also with complex real-time systems. The profile identified and defines domain concepts (Clock, Timer, TimedEvent, TimedAction) and how to represent these in the UML. For the majority of you the basic modelling of time related issues is a good starting point, and may be all that you are interested in.

Do we need such profiles? Think what the alternatives are …
Why is this required? Do we need such profiles? Think what the alternatives are … Good points Consistency Standards Automation Weak Points Complexity! Overkill ACTIVITY: An earlier slide made the point about the needs of modelling real-time systems – and also commented that the UML already has mechanisms to support these needs – so why do we need such a profile? Think about this for a few moments … what does it give us?

General Resource Modeling Framework
<<profile>> RTresourceModeling RTconcurrencyModeling RTtimeModeling SAprofile PAprofile RSAprofile <<modelLibrary>> RealTimeCORBAModel Analysis Models General Resource Modeling Framework Infrastructure Models <<import>> Basic concepts to support modelling of resources and timing mechanisms/quantifiers Technology specific subprofile The diagram shown above is the formal representation of the RT profile structure. This is the best overall figure to illustrate the emphasis in the profile (though it will no doubt appear confusing to you!). This identifies the structure, content and dependencies within the profile in terms of a number of sub-profiles represented as UML packages (the UML is itself defined using UML). The modular structure of the RT profile allows users to use only the subset of the profile that they need. For example, a user interested in performance analysis, would need the PAprofile, RTtimeModeling, and RTresourceModeling packages. The general resource modeling framework, (GRM) is the part of the RT profile most people need to know about. At the core of the GRM framework is the notion of quality of service (QoS), which provides a uniform basis for attaching quantitative information to UML models. Specifically, QoS information represents, either directly or indirectly, the physical properties of the hardware and software environments of the application represented by the model. The GRM is envisaged as the foundation required for any quantitative analysis of UML models. The GRM comprises two closely related viewpoints. One is a domain viewpoint that captures, in a generic way, the common structural and behavioral concepts and patterns that characterize: (1) real-time systems and (2) real-time system analyses methods. The second viewpoint in the GRM is the UML viewpoint—a specification of how the elements of the domain model are realized in UML. This consists of a set of UML extensions (stereotypes, tagged values, constraints) and is supplemented by specifications of the mappings of the domain concepts to those extensions. Profile compliance points - profiles define tagged values and stereotypes for schedulability(SA) and performance(PA)

Sequence for Pedestrian Crossing
b1:Button :Pedestrian t1:TrafficLight :Timer t2:TrafficLight t3:TrafficLight t4:TrafficLight push( ) reset( ) {0 ms} {5 ms} {45 ms} timeout( ) Consider the scenario where a Pedestrian pushes Button b1. According to the description we are working from, if TrafficLight t1 is currently green, the change sequence is initiated. We consider that scenario in what follows. We might simply allow the Button to send a message to each TrafficLight object, starting the change. In a system where timing and synchronisation are not significant, that would work adequately. Unfortunately the scenario we wish to describe is not free of such constraints and we must deal with them. The Timer receives a reset() message from the Button (a standard operation for any class based on the RTtimer stereotype). It resets the Timer to its initial state, i.e. it starts it counting elapsed time from zero again. We assume that our particular timer also sends messages to each of the four TrafficLights in response to the reset message, forcing them to change. These messages will be of a special stereotype known as TimeOut signals, in the Profile. The need to reset the Timer whenever a pedestrian request causes the lights to change is hopefully apparent. If it did not happen that way, the Timer would force another change at the end of whatever remained of its timing interval. The consequence for the pedestrian could be catastrophic! Think about it – pedestrian gets part way across the road when the timer times out and the lights change! A further problem which we really should face up to is how to force all four lights to change simultaneously. Even if we ignore the possibility that one light’s timeout( ) might fail to arrive, due to faulty wiring, we certainly do not want one light to change even a short time before or after the others. Issues: How do we ensure that all four lights change simultaneously? System partitioning– interfacing synchronous and asynchronous systems. Where is the boundary in the above system?

Sequence for Pedestrian Crossing
In the model shown in the previous slide, the timing information is shown using timing marks. These are written as constraints inside braces {}, indicating the time at which events should happen. We see that the timeout( ) messages are all sent at time 0. This is chosen arbitrarily, since we want merely to show the elapsed time before each successive event which results. We note that all the messages are assumed to take 5 ms to arrive, which triggers the action sequence in each TrafficLight (shown by the overlaid rectangle on their lifeline). This sequence then completes after a further 40 ms. Hopefully looking at the diagram on the previous slide you are made to ask a great many questions about the way the system operates, the timings/delays implied and synchronisation issues. Remember that each diagram presented is one possible representation of the problem – these diagrams do not purport to be a correct solution. A point to remember is to identify an appropriate level of detail to explore and expose in a given diagram. Consider the alternative picture represented above. This sequence diagram side steps synchronisation and timing issues raised on the previous slide by making the four TrafficLights into a single Junction object. This disguises the problem, however, rather than solving it – though in some situations this might be an appropriate level at which to model.

Activity Look at the Sequence Diagram introduced for the traffic light case study and redraw it as a collaboration diagram. Focus on the structure of the diagram and representation of interactions.

Collaboration for Pedestrian Crossing
1:push ( ) : Pedestrian t1:TrafficLight b1:Button ( ) 1.1.1a:change 1.1.1b:change 1.1.1c:change 1.1.1d:change 1.1:reset ( ) t2:TrafficLight :Timer t3:TrafficLight It might help to look back at the previous session notes to remind yourself what a collaboration diagram looks like. These are not typically used to representing timing information – the diagram readily becomes unreadable. How do you think that such information could be represented? t4:TrafficLight

Collaboration for Pedestrian Crossing
l:Junction b1:Button :Pedestrian A collaboration can be partitioned into sub-groups - each sub-group can represent a component in the system. It is also possible to show an object in a collaboration as containing a group of sub-objects (in a similar manner to the sequence diagram we considered earlier). In this way we can think of our systems as being built of hierarchical collections of objects

Activity Think about a state chart for the traffic light.
Begin by considering what states are to be supported and what transitions between states are valid. What are valid start states – and it is sensible to show an end state?

State Chart for Traffic Light
XtoMove Red Red and Amber timeout() after(5secs) [ sequenceNo=1 or sequenceNo=3] [sequenceNo=2 or sequenceNo=4] Amber Green

State Chart for Timer

Other Bits of UML Packages Implementation Diagrams

Packages No elements showing - tabbed rectangle with a label in the larger rectangle. A package contents shown inside the larger rectangle has its label on the tab Subpackages can be shown attached to the owning package by a  headed line Bank use cases Bank classes Account Transfer Customer Branch Current Savings Bank interactions Packages are used to hold collections of model elements Bank sequences Bank collaborations

Implementation Diagrams
UML has implementation diagrams to show the overall construction of a system Representing Nodes - nodes represent physical parts of the system, such as processors Component Diagrams - components represent pieces of the software in the system Deployment Diagrams - Combine node and component information to show how software is deployed

Representing Nodes myPC:Pentium2 yourPC:Pentium3 «ethernet» wireb

Component Diagram Compilation Components Example
My App <<executable>> object source «compile» «link» library A component represents a piece of software Components are related by dependencies Here we show the compile time dependencies which are used in make files and project files

Component Diagram Runtime Components Example
Player Umpire Board

Deployment Diagram myPC:Pentium2 p1:Player u:Umpire b:Board «ethernet»
yourPC:Pentium3 «ethernet» wireb p2:Player u:Umpire b:Board p1:Player All dependencies between components must be matched by a means of sending message procedure calling on the same node physical communications link between nodes

Further Examples in the Real-time Domain Two Phase Commit Transaction processing

Two phase commit (2PC) 2PC is a means of minimising the risk of an inconsistent outcome where co-operating processes have to update global information. In a distributed database, a transaction may involve a number of tasks spread over a number of servers. The master process: divides the work of the transaction into sub-tasks and transmits requests to the corresponding servers sends a ready request to each of these tasks, to report as soon as they succeed or fail; this may be piggy backed on the initial request

Two phase commit (2PC) each task then proceeds as follows:
it requests locks for data that it will read or write; read locks can be shared, but write locks must be exclusive; if any lock is refused, the task sends back a failure response and does nothing until it receives an abort; if it is successful in acquiring the locks, it performs the computation; no locks are released here; once the computation is complete, the task sends a ready response and waits for an abort or commit; if the task receives a commit it updates the data affected by its computation, releases all its locks and ends; if it receives an abort it releases all its locks and ends without updating the global copy of its data

Two phase commit (2PC) the master process waits until it either receives any failure response, when it sends an abort to all its tasks and enters the aborted state, or it receives a ready response from all its tasks, when it sends a commit to all its tasks; in the aborted state, the master process will continue to send aborts to any tasks that send messages, since these will be stragglers or result from recovery by a task which failed.

2PC Class Diagram 1 Computation 1..* carries out runs on 1 1 spawns
executes on Transaction 1 Task 1 Server 1..* 1 1 1 are needed for is made to Lock request 1..* 1..*

2PC Collaboration Diagram
t1:Task s1:Server t:Transaction :User As an extra activity why not look at adding a series of possible interactions on the above diagram? t2:Task s2:Server

Transaction Processing
Starts by spawning all the tasks needed to perform it. These are passed a set of locks needed and a duration for their computations. The Transaction then enters the running state until it has either received ready messages from all its tasks, when it sends them all a commit message and terminates, or it receives one or more failed messages, when it sends abort messages to all its tasks and terminates. We assume that it does not need to wait after the aborts are sent to check for recovering stragglers

Transaction Processing
when(tasks<0)/^newTask(locks,d);locks++ needed := n;tasks := 0 spawning when(tasks>0)/^task[tasks].abort;tasks-- Transaction failed when(tasks=needed) when(tasks=0) when(suc+ref=tasks and ref>0) running Transaction succeeded ready(n)/suc++ when(suc=tasks) when(tasks=0) failed(n)/ref++ when(tasks>0)/^task[tasks].commit;tasks--

A Task Is initially in the locking state. From here it makes repeated transitions to the asking state, until the last lock has been granted. Each time it makes this transition it sends a message to its Server, s, asking for a lock. In the asking state, the lock is either granted, triggering a transition back to locking and incrementing locks, or refused, triggering a transition to failed and causing a fail message to be sent to the Transition, tr. If all locks granted, Task sends compute request to its Server and enters the computing state.

A Task It waits there until it receives a done message, when it sends a ready message to its Transition, tr, and enters the ready state. If the Task reaches the ready state and receives a commit message from its Transition, it commits, shown here as simply moving to the releasing state, but in a real system involving updating the current copies of its data. In either the failed or the ready states an abort message causes the Task to move to the releasing state. In the releasing state, all locks granted to this task are released.

Statechart for a Task

Server The Server receives messages for locks or computational tasks.
When it does so it increments the count of locks or tasks (used for state dependent probabilities and rates in the performance model) and creates a Request or Active as appropriate. When it receives a give or a finished message, this indicates success for one of these subsidiaries, as shown in their simple state diagrams. It may also receive a release from a committing or aborting Task.

Server statechart

Tutorial Session After a welcome coffee break you will work in small groups (3-4 students) Review the lecture notes and consider any questions at this point Examine the tutorial exercise on the following slides. This aims to give you some practise looking at interactions between objects and experience with UML class and interaction diagrams. This will be collected in at the end of the tutorial and marked as a piece of coursework contributing to your final module mark. An assessment/feedback sheet will be handed out during the tutorial session. You should clearly enter the names of all students in your group and submit the sheet with your coursework.

Tutorial Session (Coursework)
The card game switch works as follows. Step 1: The cards are dealt out to the players. The initial direction of play is clockwise. Step 2: The player on the dealers left is the first to play a card. Step 3: Players always keep their cards face downwards and play the top card from their pile. Step 4: After a player plays their top card, the next event depends on the values of that card. if an eight is played, the player two from the one who played the card, in the current direction of play, plays their next card, i.e. the normal next player is missed out; if a jack is played, the direction of play is reversed and the player next in the new direction of play plays their top card; if any other card is played, the next player in the direction of play plays their top card. Step 5: Step 4 is repeated until one player has played all of their cards. That player is the winner. Assume three players, Player1, Player2 and Player3, seated in that sequence clockwise. They take turns by sending messages such as play(jack) to the gameTable object. The gameTable object controls who plays next, in accordance with the rules described in step 4 above, by sending the message turn() to the appropriate player after it receives each play() message.

Tutorial Session (Coursework)
1. Identify classes that support the objects described above and draw the resulting UML class diagram. The class diagram should show detail boxes for the class name, attributes and operations. You need only complete sections for the class name and operations. Clearly state any assumptions you make. Clearly show direction and nature of associations and show appropriate multiplicity information. State any assumptions that you need to make. 2. Draw a UML sequence diagram to show how the following game would proceed, clearly showing which of the three players wins. Clearly state any assumptions that you make. Assume that Player3 has just dealt and the three players each have the following cards in their pile: Player1, from top to bottom of card pile: five, eight, three, ace. Player2, from top to bottom of card pile: four, two, jack, seven. Player3, from top to bottom of card pile: nine, queen, six, ten

Some General UML References
Stevens, P and Pooley, R. (2000). Using UML Software Engineering with Object and Components, Updated Edition. Pearson Education Limited. Pooley, R and Wilcox P (2004). Applying UML: Advanced Application. Butterworth-Heinmann Douglass, Bruce P., Doing Hard Time: Developing Real- Time Systems with UML, Objects, Frameworks, and Patterns, Addison- Wesley, 1999 Douglass, Bruce P., Real- Time Design Patterns: Robust Scalable Architectures for Real- Time Systems Addison- Wesley, 2002 Fowler and Scott, UML Distilled, Addison- Wesley 1997 Some good free references from the Internet for general UML material: OMG UML web pages via Rational white papers via Scott Amblers’ white papers via

Some More Related References
Response to the OMG RFP for Schedulability, Performance, and Time, Revised Submission, Monday, June , OMG document number: ad/ (224 pages). The Real- Time UML Standard: Definition and Application by Alan Moore, Bran Selic and Ben Watson (94 pages). UMLTM Profile for Schedulability,Performance, and Time Specification, I-Logix white papers (register via ) Real-Time Object Orientation, by Dr. Bruce Powel Douglass Real-Time Design Patterns, by Dr. Bruce Powel Douglass Capturing Requirements for Real-Time and Embedded Systems, by Dr. Bruce Powel Douglass Custom Embedded Communications Protocols, by Dr. Bruce Powel Douglass The UML for Systems Engineering, by Dr. Bruce Powel Douglass (your reading from session one)

And finally … A wide range of tools are available to support working with UML (some are freely available via the Internet). Many have support targeting modelling of real-time systems - a small example follows: Rational Rose: Artisan: ArgoUML: Poseidon (commercial version of argoUML): Ilogix: These lecture notes (including diagrams introduced during the lecture) and other material relating to this part of the Systems Partitioning module can be found at the following URL:

The Unified Modelling Language

Similar presentations

Presentation on theme: "The Unified Modelling Language"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

The Unified Modelling Language

Similar presentations

Presentation on theme: "The Unified Modelling Language"— Presentation transcript:

Similar presentations

About project

Feedback