The Unified Modelling Language

1. The Unified Modelling Language Introduction

2. Session One 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). Overview

3. Session One

4. 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

5. 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

6. 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. Some references included in slides at end of notes

7. Key Diagrams in UML Use Case Diagram Requirements Capture System Structure System Behaviour Class Diagram Interaction Diagrams Activity Diagrams State Charts (+ CRC cards)

8. 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.)

9. Introductory Case StudyThe 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.

10. Introductory Case StudyThe 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.

11. The Bank Case Study • Use Case Diagram • Examine and capture requirements • Class Diagram • Start to examine system structure • Activity Diagram • Illustrate dependencies in system • Interaction Diagrams • Express system dynamics

12. Use Case Modelling

13. This is one possibility Use Case model of the bank deposit withdraw transfer aCustomer statement teller add interest

14. 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

15. 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

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

17. 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.

18. Notes On The Description • The customer is the actor that initiates the deposit. • The inputsto 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.

19. Class Modelling

20. Object = Classes and Objects • An object is a means of partitioning the solution to a design problem. • Objects are similar to modules in some ways. 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.

21. Often termed methods So, how do we identify objects? What’s In An Object • An object has a public interface defining the operations it will support. • 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.

22. 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.

23. 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.

24. 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.

25. 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 intereston 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 onetransaction. 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.

26. 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

27. Now we need to consider some graphical way of expressing our class model Nouns Left • current account • savings account • customer • branch • statement • transfer

28. Associations between classes Customer 1 1 withdraws and deposits money with withdraws and deposits money with 1 1 Branch holds holds 0..* 0..* 0..* 0..* Current account Transfer Savings account moves money to moves money to 1 1 1 1 1 1 summarises Statement summarises 1 1 Class Diagram

29. Showing class details Customer 1 withdraws and deposits money with 1 withdraws and deposits money with 0..* Current Account 1 0..* 1 Branch holds holds 0..* 0..* Transfer Savings Account moves money to moves money to 1 1 1 1 1 1 Statement summarises 1 summarises 1 Class Diagram -balance : real +withdraw(a:Real) +deposit(a:Real) +curBal():Real

30. 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

31. 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

32. generalisation developer manager employee analyst specialisations 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

33. generalisation *or* parent class *or* super-class specialisation *or* child class *or* sub-class manager analyst employee developer Specialisations • Specialisations may have additionalattributesand/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

34. Also referred to as overloading of methods where can have same method name but different signatures printDetails() printDetails(int x) Polymorphism • A specialisation may also redefine operations which were implemented in its parent. employee printDetails() analyst manager developer printDetails() printDetails()

35. Customer 1 0..* Account 1 0..* Branch holds 1 moves money to 1 Transfer Current Account 1 Savings Account Statement summarises 1 Class Diagram using Specialisation

36. Account -balance : Real -rate : Real +deposit(a:Real) +curBal():Real +withdraw(a:Real) CurrentAccount SavingsAccount -chequeNo : Integer +withdraw(a:Real) +withdraw(a:Real) +newBook() An Example {abstract}

37. 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.

38. Interfaces In UML Exchange Exchange <<interface>> Transfer move cash <<interface>> Transfer Transfer move cash Account Account <<uses>>

39. CRC Cards

40. 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.

41. 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

42. 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.

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

44. 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.

45. Modelling InteractionsusingInteraction DiagramsActivity DiagramsState Charts

46. 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

47. Sequence Diagrams show sequences of messages with the emphasis on the order in which they are sent

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

49. 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 * Messages Synchronous (procedure) Flat (thread) Asynchronous (concurrent) Return from synchronous [v<30] Guard *[x>10] Iteration v=getval() [v>10]setval(v) * Repeated sequence [v>0]

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