1. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.1 Software Engineering: Analysis and Design - CSE3308 Object-Oriented Analysis 2 CSE3308/CSC3080/DMS/1999/10 Monash University School of Computer Science and Software Engineering

2. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.2 Lecture Outline u Linking Use Cases and Class Diagrams u Interaction Diagrams v Sequence Diagrams v Collaboration Diagrams u Package Diagrams u State Diagrams u Activity Diagrams u A criticism of Use Cases

3. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.3 Linking Use Cases and Class Diagrams u Use Cases are a key tool in determining the concepts/classes in a system u One of the earliest methods of finding the classes was Noun Identification u Noun identification is both simple and deceptive v Simple to apply to requirements v Deceptive because natural language is ambiguous u Use cases (especially expanded use cases) provide a more focused view of the requirements and therefore can act as a very good source of inspiration

4. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.4 Example u Identifies both concepts and attributes. u Different nouns can mean the same thing u Often a question of experience Actor Action System Response 1. This use case begins when a Customer arrives at a checkout with items to purchase. 2. The Cashier records the Universal Product Code (UPC) from each item. If there is more than one of the same item, the Cashier can enter the quantity as well. 3. Determines the item price and adds the item information to the running sales transaction. The description and price of the current item are displayed.

5. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.5 Rejecting Classes u We will come up with many possible classes, some of which we will not need u Competing priorities: vSimplest set of classes to satisfy current needs vSet of classes which will easily accommodate future needs u Need to apply criteria to possible classes

6. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.6 Rejection criteria u Redundant classes ve.g. User and Customer of an ATM vretain the more descriptive name u Irrelevant classes vcontext dependent ve.g. Customer complaint is outside the scope of the ATM example u Vague classes vA class should be specific ve.g. ATM Death is not clearly defined in our material u Attributes »e.g. name, age, weight, address are not usually classes

7. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.7 Rejection criteria (2) u Functions va behaviour of a class rather than a class in itself ve.g. in a car system, acceleration is a function not a class u Roles vThe name of a class should reflect its intrinsic nature and not a role it plays in an association vCustomer confused with Car Owner, Car Driver and Car Renter u Implementation constructs vclasses which are extraneous to the real world ve.g. CPU, subroutine, array, linked list etc.

8. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.8 Interaction Diagrams u Models which show how groups of objects collaborate in some behaviour u Typically we describe how the behaviour of a single use case is implemented by a group of objects and the messages they pass between them u Two types of Interaction diagrams v Sequence v Collaboration u Both are useful, choice is a matter of personal/organisational preference

9. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.9 Filling an Order A real use case Name:Filling an Order Actors:Order Clerk Purpose: To fill an order for a customer Overview: Type: Primary and real Actor Action System Response 1. An order clerk enters an order in the entry window. 2. The Order Entry Window sends a prepare message to an Order. 3. The order then sends “prepare” to each Order Line on the Order. 4. Each Order Line checks the given Stock Item 5. Order Line removes the appropriate quantity of Stock Item from stock Typical Course of Events Alternative Course: Quantity of Stock Item below reorder level and that Stock Item requests a new delivery

10. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.10 Sequence Diagram

11. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.11 Collaboration Diagram

12. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.12 Comparing Sequence and Collaboration Diagrams u Sequence diagrams emphasise the sequences of events well u Collaboration diagrams show the relationships between the classes well u Keep both types of diagrams simple u They are not particularly good at defining behaviour precisely

13. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.13 Package Diagrams u Method to break down a large system into smaller systems u Basically lets us group classes into higher- level units u Group classes based upon dependencies u Dependency means a change in one group will cause a change in another group u Packages give us a way of depicting dependencies u Reducing dependencies is the key to building large systems u Can be implemented in Java directly (Packages)

14. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.14 A Package Diagram Order Capture UI AWT Mailing List UI Mailing List Application Customers Orders Order Capture Application dependency package

15. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.15 Another package diagram Order Capture UI AWT Mailing List UI Mailing List Application C ustomers Orders Order Capture Application Domain Quantity Money Date Range Common {global} Database Interface {abstract} Oracle Interface Sybase Interface

16. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.16 Package Diagrams (2) u You need to create a package diagram, if your class diagram is larger than a sheet of A4 paper u Dependencies are not transitive, they go one step only u You should aim to break cycles in the relationships between packages where possible (often difficult within the domain) u Are useful for testing, can do unit testing on a per package basis rather than per class

17. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.17 State Diagrams u Very similar to those in Structured Analysis u Describe the lifecycle of an object v All the possible states of an object v How the object’s state changes as a result of events that reach the object u Good at describing the behaviour of an object across several use cases u Not good at describing behaviour where several objects are interacting u Use state diagrams only for classes that exhibit interesting behaviour u If too much concurrent behaviour in an object’s state diagram, is probably more than one object

18. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.18 A Basic State Diagram for an Order Item Received [all items available] Waiting Delivered Cancelled Checking Dispatching cancelled [all items checked && all items available] [all items checked && some items not in stock] Item received [some items not in stock] cancelled do/initiate delivery do/check item start self-transition State transition /get first item activity guard condition [not all items checked] / get next item action event

19. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.19 Superstates Item Received [all items available] Waiting DeliveredCancelled Checking Dispatching [all items checked && all items available] [all items checked && some items not in stock] Item received [some items not in stock] cancelled do/initiate delivery do/check item get next item [not all items checked] /get first item Active

20. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.20 Concurrent States Checking Dispatching Waiting AuthorisedAuthorising Rejected Delivered Cancelled

21. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.21 Activity Diagrams u In a conceptual diagram, an activity is some task to be done u In a specification/implementation diagram, an activity is a method on a class u Each activity can be followed by another activity u Activities can span multiple use cases u Show the whole picture of behaviour just as a class diagram shows the whole picture of the static relationships

22. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.22 An Activity Diagram

23. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.23 Another Activity Diagram

24. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.24 Joining Activity Diagrams

25. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.25 Activity Diagrams (2) u Strength is their support for parallel behaviour u Ideal for describing workflow modelling and multi-threaded programming u Disadvantage is that the link between activities and objects is not very clear u Either use swimlanes or specifically indicate the object on the diagram u Not used for looking at how objects collaborate or how an object behaves over its lifetime

26. CSE3308/CSC3080 - Software Engineering: Analysis and DesignLecture 4B.26 A criticism of Use Cases u Meyer (1997) criticises use cases as a method for OO Analysis and Design especially as a tool for finding classes u Use cases emphasise ordering and thus harm the system’s reuseability and robustness u Use cases emphasise a current view of the system and reduce the possibility of new and better ways of doing things u Use cases favor a a functional approach based on processes, the reverse of OO’s concentration on data abstraction