Unified Modelling Language-Software Engineering-Lecture 18 Slides-Computer Science, Slides of Software Engineering

Download Unified Modelling Language-Software Engineering-Lecture 18 Slides-Computer Science and more Slides Software Engineering in PDF only on Docsity! LECTURE 18: UML Software Engineering Mike Wooldridge Lecture 18 Software Engineering 1 What is UML? • In the mid 1980s, a number of techniques began to emerge for object-oriented-analysis and design. • Examples: – Coad & Yourdon; – Booch; – Rumbaugh (the OMT technique); – Coleman (FUSION). • All used similar techniques, but differed on details of notation, etc. •Mid 1990s: a move towards standardisation, driven by the Object Management Group (OMG): The Unified Modelling Language (UML). • UML is essentially a notation, and not a technique. Notation can be used in many different ways: we show one. Mike Wooldridge 1 Lecture 18 Software Engineering 3.1 Schema for Use Cases • Use case: [name of use case] • Actors: [list of actors that can participate, naming the initiator, and indicating key player] • Purpose: [one-line summary of purpose of the activity] • Overview: [short summary of the use case] • Type: [primary or secondary, essential or optional] • Cross references: [references to requirements document] • Course of events: [narrative summary of use case] Mike Wooldridge 4 Lecture 18 Software Engineering 3.2 Example Use Case 1 • Use case: Buy items with cash. • Actors: Customer (initiator), cashier • Purpose: Capture a sale and its cash payment • Overview: Customer arrives at checkout with items to purchase in cash. Cashier records the items and takes cash payment. On completion, customer leaves with items. • Type: Essential, primary. • Cross references: Buy items with credit card, buy items with cheque. Mike Wooldridge 5 Lecture 18 Software Engineering • Course of events: 1. Customer arrives at checkout with items. 2. Cashier records identifier of each item. 3. As each item is recorded, system responds with running total of cost of items. 4. Cashier indicates to system that there are no more items. 5. System responds with overall total cost of items. 6. Cashier takes cash payment from customer for total cost, and indicates this to system. 7. System prints receipt for amount tendered. Mike Wooldridge 6 Lecture 18 Software Engineering • Identifying use cases: – identify the actors involved in a system or organisation; – for each actor, identify the processes they initiate or act in; – refine processes into use cases; • Common mistakes with use cases: – making them too small; – identifying parts of activities, rather then entire activities. Mike Wooldridge 9 Lecture 18 Software Engineering 4 Conceptual Models • The next stage in UML development involves identifying the key concepts in the system, and documenting the relationships between these concepts. The resulting conceptual model will evolve into the object model. • A conceptual model documents: – the concepts in a system; – relationships between concepts; – attributes of concepts. • Conceptual models are not design models. So avoid such concepts as: – “database”; – “GUI” or “window”; • Key distinguishing feature of OO development: Understanding system in terms of concepts rather than functions. Mike Wooldridge 10 Lecture 18 Software Engineering •What are candidates for concepts? – physical or tangible things e.g., receipt, plane – specifications, designs, or descriptions of things; e.g., product specification – places e.g., airport, point of sale terminal – transactions e.g., deposit, withdrawal – roles of people e.g., casher, customer – containers of things e.g., plane, store room – things in a container e.g., passenger Mike Wooldridge 11 Lecture 18 Software Engineering Common types of relationship: • is a physical part of; e.g., wing-plane • is a logical part of e.g., module-course • is physically contained in e.g., passenger-plane • is logically contained in e.g., flight-flight schedule • is a description for e.g., flight description-flight • is reported/recorded in e.g., reservation-flight manifest Mike Wooldridge 14 Lecture 18 Software Engineering • is a member of e.g., pilot-airline • is an organisational subunit of e.g., department-store • uses or manages e.g., pilot-plane • communicates with e.g., customer-cashier • is related to a transaction e.g., passenger-ticket • is owned by e.g., plane-airline Mike Wooldridge 15 Lecture 18 Software Engineering 4.2 Concept Diagrams • Concepts and the relationships between them are documented in a concept diagram. • Basic notation for concepts: Name of concept Attribute 1 · · · Attribute n Mike Wooldridge 16 Lecture 18 Software Engineering • Possible annotations: 1 one n exactly n m..n between m and n ∗ zero or more m,n either m or n • Note that identifying concepts is much more important than relationships or multiplicities; Mike Wooldridge 19 Lecture 18 Software Engineering 4.4 Concept Attributes • Attributes should correspond to simple data types. • Common attributes: – address; – colour; – phone number; – serial number; – universal product code/barcode; – postal or ZIP code; • Attributes should not be composite! • Bad attributes: – URL is composed of three things – flight destination is an airport — a separate concept altogether; Mike Wooldridge 20 Lecture 18 Software Engineering 4.5 Generalisations • UML includes a special symbol for generalisations. • Thus: – rectangle is a generalisation of square; – shape is a generalisation of rectangle. Mike Wooldridge 21 Lecture 18 Software Engineering • The library conceptual model: •Missing concepts? Mike Wooldridge 24 Lecture 18 Software Engineering 5 Collaboration Diagrams • The conceptual model of a system will evolve into an object model, which captures the static aspects of a system. • To capture the dynamics of a system, we need a collaboration diagram. • A collaboration is: – a collection of linked objects; – which work together to achieve a task; – by invoking methods on each other. • A collaboration captures stereotypical control flows (method invocations) between collaborating objects. • NB: At least one collaboration diagram for each use case. Mike Wooldridge 25 Lecture 18 Software Engineering 5.1 Example Collaboration Diagram Mike Wooldridge 26 Lecture 18 Software Engineering • An object cannot “spontaneously” invoke a method: it can only invoke methods in response to methods being invoked on it. • In order for an object o1 to invoke a method on another object o2, it must have a handle on it: – o1 may have o2 as an instance variable; – o1 may have been passed o2 as an argument. There are clear implications for the implementation of objects. Mike Wooldridge 29 Lecture 18 Software Engineering 5.2 Object Creation • How to indicate creation of an object: Mike Wooldridge 30 Lecture 18 Software Engineering • Equivalent of following Java code: class Library extends Object { ... void newLibraryMember(details : Details) { LibraryMember newLibraryMember = new LibraryMember(details); addNewMember(newLibraryMember); } ... } Mike Wooldridge 31 Lecture 18 Software Engineering 6 Sequence Diagrams (Swimlanes) • An alternative to collaboration diagrams is sequence diagrams: Mike Wooldridge 34 Lecture 18 Software Engineering • The y axis is time; • Dotted line indicates the lifeline of an object • Horizontal arrows indicate method invocation; • Vertical blocks indicate periods of object activity. Mike Wooldridge 35 Lecture 18 Software Engineering 7 Statecharts • Statecharts, or state diagrams, illustrate the behaviour of an object — its lifecycle. • UML uses a finite state machine-like model of statecharts: – directed graph; – nodes correspond to states of the system; – arcs correspond to events that cause state changes; – start state: – end state: Mike Wooldridge 36 Lecture 18 Software Engineering 8 Class Diagrams • The final UML model we look at is the class diagram or object model. • This model is an elaboration of the conceptual model. • How to construct a class diagram: 1. using concept model and collaboration diagrams, identify the classes in your system; 2. using collaboration diagrams, name the methods; (if you invoke m on an object o of class C, then C must provide method m) 3. determine visibility of methods; 4. determine navigability. Mike Wooldridge 39 Lecture 18 Software Engineering • An example class diagram. Mike Wooldridge 40 Lecture 18 Software Engineering • The third compartment in concept boxes contains methods that the class corresponding to the concept must perform. • These methods are derived by studying the messages that are sent to the class in concept diagrams. • These methods are annotated as follows: + means public; - means private; # means protected. Mike Wooldridge 41