1. 1 Unified Modelling Language OOA/OOD a summary of the book: Applying UML and Patterns, Craig Larman D. Dranidis October 2000 CITY College

2. 2 Introduction Owing a hammer doesn’t make one an architect –Analysing and designing a system from an object perspective is critical UML –“... a language for specifying, visualising and constructing the artefacts of software systems...” [BJR97] –a mainly diagrammatic notation for modelling systems using object- oriented concepts. Patterns –Problem-solution formulas that codify exemplary design principles Development process –order of activities in a development life-cycle Study of a simple case study

3. 3 Object oriented Analysis and Design Analysis –investigation of the problem: what the problem is about and what the system must do. OOA –finding and describing objects (concepts) in the problem domain. Design –logical solution: how the system fulfils the requirements OOD –defining logical software objects with attributes and methods

4. 4 What is UML? G. Booch and J. Rumbaugh (1994) and later I. Jacobson –Booch method –OMT (Object Modelling Technique) –OOSE (OO Software Engineering) De facto approval in industry Modelling language DOES NOT define a standard methodology process

5. 5 Sample Development Activities Disadvantages of Waterfall Life-cycle –complexity overload –delayed feedback –frozen specifications, while business environment changes Recommended development process [Booch96] –iterative and incremental –use case driven –early emphasis on defining the architecture: high level structure of subsystems and components Iterative –planned process of revisiting an area, each time enhancing the system Incremental –add functionality to a system during several release cycles An incremental release is composed of multiple iterative development cycles Time-boxing a Development cycle (between 2 weeks and two months).

6. 6 Case Study: Point-of-Sale-Terminal (POST) Computerised system used to record sales and handle payments. HW components: computer and bar code scanner Architectural layers: –Presentation: GUI –Application Logic: Problem Domain Objects –Application Logic: Service Objects - non problem domain objects, such as interfaces to a database –Storage: persistent storage mechanism. Iterative development strategy: –1st development cycle: simple core-functions application –2nd development cycle: expansion of the functionality

7. 7 Use Cases Use cases are dependent on having at least partial understanding of the requirements of the system. Use case: –narrative document that describes the sequence of events of an actor (external agent) using a system to complete a process. –story of using a system –illustrates and implies requirements in the story it tells Actors: –external entities to the system who participate in the story of a use case –roles that humans play, computer systems, devices

8. 8 Use Cases within a Development Process Plan and Elaborate Phase –Define system boundary. Identify actors and use cases –Write high-level use cases –Draw a use-case diagram –Write expanded use cases for the most critical, influential or risky use cases. Defer rest use cases. –Rank use-cases

9. 9 Identifying Use Cases Identify actors related to a system –Cashier –Customer For each actor, identify the processes they initiate or participate in –Log In, Cash Out, –Buy Items, Refund Items All system functions identified during the requirements specification should be allocated to use cases

10. 10 Example of a High-level Use Case: Buy Items Use Case: Buy Items Actors: Customer, Cashier Type: primary Description: –A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects payment. On completion, the Customer leaves with the items.

11. 11 Example of an Expanded Use Case: Buy Items Use Case: Buy Items Actors: Customer (initiator), Cashier Purpose:Capture a sale and its payment Type: primary Overview: –A Customer arrives at a checkout with items to purchase. The Cashier records the purchase items and collects a payment, which may be authorised. On completion, the Customer leaves with the items. Cross References: –Functions: R1.1, R1.2, etc –Use cases: Cashier must have completed the Log In use case. continues...

12. 12 Typical Course of Events Actor Action 1. This use case begins when a Customer arrives at the POST checkout with items to purchase. 2. The cashier records each item. If there is more than one of an item, the Cashier can enter the quantity as well. 4.On completion of item entry, the Cashier indicates to the POST that item entry is complete. 6.The Cashier tells the Customer the total. 7.Customer chooses payment type: a. If cash payment initiate Pay by Cash. b. if credit payment initiate Pay by Credit. 11.The Cashier gives the receipt to the Customer. 12. The Customer leaves with the items purchased. System Response 3. Determines the item price and adds the item information to the running sales transaction. The description and price of the current item are presented. 5.Calculates and presents the sale total. 8.Logs the completed sale. 9.Updates inventory levels. 10. Generates a receipt. Alternative courses Line 2: Invalid item identifier entered. Indicate error. Line 7: Customer could not pay. Cancel sales transaction.

13. 13 Use Case Diagram Partial use case diagram Buy Items Log In Cashier Pay By Cash Customer Pay By Credit POST

14. 14 Allocation of use cases to development cycles Buy Items version 1 is a simplified version of the original use case. Each development cycle consists of –Planning, Analysis, Design, Construction, Testing Development Cycle 1 Buy Items version 1 Development Cycle 2 Buy Items version 2 Development Cycle 3 Log In Refund

15. 15 Building a Conceptual Model Representation of concepts in a problem domain; of real-world things, not of software components Static structure diagrams (no operations) –concepts –associations between concepts –attributes of concepts It is better to overspecify a conceptual model with lots of fine-grained concepts, than to underspecify it! A good conceptual model –captures the essential abstractions and information required to understand the domain in the context of the current requirements, and –aids people in understanding the domain -- its concepts, terminology, and relationships Analysis

16. 16 Finding Concepts List of candidate concepts from Concept Category List: –physical objects (POST), –specifications (ProductSpecification), –places (Store), –transactions (Sale, Payment), –transaction line items (SalesLineItem), –roles of people (Cashier, Customer), List of candidate concepts from Noun Identification –Use cases can be used –List: Customer, POST, checkout, items, Cashier, item, quantity, item price, sales transaction, description, price,... Analysis –containers (Store, Bin), –things in a container (Item), –organizations (SalesDepartment), –events (Sale), –catalogs (ProductCatalog),...

17. 17 Adding associations Associations: –relationships between concepts that indicate some meaningful and interesting connection –structural relationships between objects of different types. Finding associations from common associations list: –A is a physical (or logical) part of B –A is physically (or logically) contained in/on B –A is recorded in B –A is a description for B –A is a member of B –A uses or manages or communicates or is related to B Finding concepts is much more important than finding associations Focus on –«need-to-know» associations (knowledge of the relationship needs to be preserved for some duration) Avoid redundant or derivable associations Analysis

18. 18 Adding Attributes Attribute: logical data value of an object Include those attributes suggested by the use cases. –for example: Sale needs a date and time attribute Attributes should be pure data values (value objects: number, string, Boolean, date, time) –otherwise represent as associations Relate concepts with an association, not with an attribute! Analysis

19. 19 Conceptual model 1..* * 1* Product Catalog 1 * 1 1..* Store address name 1 * Used By 11 Product Specification description price UPC 1..* 1 Contains * 1 Payment amount Sale date time 1 1 Initiated-by 1 1 Paid-by 1 1 POST 1 1..* Houses 1 Captured-on 1 1 Records-sales-on 1 1 1 1 Sales LineItem quantity 1 1..* Contained-in 1 * Described-by Item 1 * Describes *1 Stocks 1 0..1 Records-sale-of 1 0..1 Analysis Logs-completed 1 * Cashier Customer

20. 20 System sequence diagrams Define the behaviour of a system as a black box: what the system does, without explaining how. System sequence diagram is a picture that shows the events that external actors generate, their order and intersystem events (for a particular scenario of a use case) System sequence diagrams are strongly related to use cases Analysis

21. 21 System Behaviour - Contracts Contracts are created for each system operation Contracts describe the effect of operations upon the system by defining pre- and postconditions of operations. Contracts are declarative in style, emphasising what will happen rather than how it will be achieved. Example: –Name:enterItem ( upc: number, quantity: integer ) –Responsibilities: Enter sale of an item, add it to the sale, display the item description and price. –Pre-conditions: upc is known to the system –Post-conditions: if a new sale, a Sale was created and was associated with the POST A SalesLineItem was created and associated with the Sale Attribute SalesLineItem.quantity was set to quantity The SalesLineItem was associated with a ProductSpecification, based on UPC match Analysis

22. 22 From Analysis to Design Use Cases:What are the domain processes? Conceptual Model:What are the concepts, terms? System sequence diagrams:What are the system events and operations? Contracts:What do the system operations do?

23. 23 Collaboration Diagrams Contracts do not show a solution of how software objects are going to fulfil the post-conditions. Interaction diagrams illustrate how objects interact via messages to fulfils tasks. Starting point for the interactions is the fulfilment of the post- conditions of the operation contracts. Use cases may provide additional guidance Objects are chosen from the conceptual model. Design

24. 24 Choosing the Controller Class The first design decision involves choosing a controller for each system operation. Controller pattern: –assign the responsibility for handling a system event message to a class representing one of the following choices: the overall system the overall business or organisation something in the real world that is active (the role of a person) an artificial handler of all system events of a use case Possible choices for enterItem: –POST –Store –Cashier –BuyItemsHandler : POST 1: enterItem(upc, qty) Design

25. 25 Creating a new sale if a new sale, a Sale was created and was associated with the POST –Creator Pattern: assign the responsibility for creation to a class that aggregates, contains or records the class to be created –Candidate: POST POST creates Sale, and Sale is easily associated to POST since POST keeps a reference to created Sale Sale must create an empty collection to record all the future SalesLineItem instances that will be added : POST : Sale : Sales LineItem 1: [new sale] create()enterItem(upc, qty) 1.1: create() Design

26. 26 Creating a new SalesLineItem A SalesLineItem was created and associated with the Sale –By Creator: Sale creates SalesLineItem SalesLineItem is easily associated to Sale (by storing the new instance in its collection) Attribute SalesLineItem.quantity was set to quantity –POST must pass the quantity along to Sale, which must pass it along as a parameter in the create message The SalesLineItem was associated with a ProductSpecification, based on UPC match –Who is responsible for knowing a ProductSpecification based on a UPC match? –Expert Pattern: assign the responsibility to the object that has the information required to fulfil it. –Candidate: ProductCatalog –POST should ask ProductCatalog for ProductSpecification (Visibility) Design

27. 27 enterItem Collaboration Diagram : POST : Sale : Sales LineItem : Product Catalog : Product Specification sl : Sales LineItem 1: [new sale] create() 3: makeLineItem(spec, qty) 2: spec := specification(upc) enterItem(upc, qty) 1.1: create() 3.2: add(sl) 3.1: create(spec, qty) 2.1: spec:= find(upc) by Creator By Expert Design

28. 28 Design Class Diagrams A design class diagram illustrates the specifications for software classes and interfaces in an application: –classes, associations and attributes –methods –navigability –dependencies The creation of design class diagrams is dependent upon the prior creation of –Interaction diagrams : the designer identifies the software classes that participate in the solution, plus the methods of classes –Conceptual model: the designer adds details to the class definitions. Design

29. 29 Design Class Diagram Payment amount : Quantity POST endSale( ) enterItem( ) makePayment() ProductCatalog specification( ) Looks-in Store address name addSale() Uses Houses Sale date time becomeComplete( ) makeLineItem( ) makePayment( ) total( ) Captures Paid-by * Logs-completed SalesLineItem quantity : Integer 1..* Contains Product Specification description price UPC 1..* Contains * Describes 1..* * * Design

30. 30 Organising and refining the conceptual model Organising in Packages: –used to partition the conceptual model –organise elements depending on their subject area type hierarchy use cases participation strong associations Refining associations –associative types –aggregation and composition –association role names

31. 31 State Diagrams Usage: for concepts and use cases Illustrate interesting events and states of an object, and the behaviour of an object in reaction to an event Use case state diagrams –describe the legal sequence of external system events State diagrams for state- dependent types Features –transition actions –transition guard conditions –nested states