Unified Modelling Language OOA/OOD a summary of the book: Applying UML and Patterns, Craig Larman

1. Unified Modelling LanguageOOA/OODa summary of the book:Applying UML and Patterns, Craig Larman D. Dranidis October 2000 CITY College

2. Introduction • Owing a hammer doesn’t make one an architect • Analysingand 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Typical Course of Events Alternative courses Line 2: Invalid item identifier entered. Indicate error. Line 7: Customer could not pay. Cancel sales transaction.

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

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 Development Cycle 2 Development Cycle 3 Buy Items version 1 Buy Items version 2 Refund Log In

15. Building a Conceptual Model Analysis • 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

16. Finding Concepts Analysis • 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, ... • containers (Store, Bin), • things in a container (Item), • organizations (SalesDepartment), • events (Sale), • catalogs (ProductCatalog),...

17. Adding associations Analysis • 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

18. Adding Attributes Analysis • 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!

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

20. System sequence diagrams Analysis • 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

21. System Behaviour - Contracts Analysis • 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 wascreated and wasassociated with the POST • A SalesLineItem wascreated and associated with the Sale • Attribute SalesLineItem.quantity wasset to quantity • The SalesLineItem wasassociated with a ProductSpecification, based on UPC match

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. Collaboration Diagrams Design • 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.

24. 1: enterItem(upc, qty) : POST Choosing the Controller Class Design • 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

25. Creating a new sale Design • if a new sale, a Sale wascreated and wasassociated 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 enterItem(upc, qty) 1: [new sale] create() : POST : Sale 1.1: create() : Sales LineItem

26. Creating a new SalesLineItem Design • A SalesLineItem wascreated 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 wasset to quantity • POST must pass the quantity along to Sale, which must pass it along as a parameter in the create message • The SalesLineItem wasassociated 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)

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

28. Design Class Diagrams Design • 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.

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

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