1. Requirements Analysis 2 What objects collaborate to achieve the goal of a use case?

2. Class Collaboration What classes do we need to realise a use case? What entity classes are involved? We will also need –a boundary class for the interface –a control class for the use case These are called : Analysis Class Stereotypes

3. What classes do we need to model a use case? Source: http://www.agilemodeling.com/artifacts/robustnessDiagram.htm

4. How would you relate these elements?

5. http://www.math-cs.gordon.edu/courses/cs211/ATMExample/AnalysisClasses.html

6. Classes and responsibilities What is the role of each object in realising the use case? Class Responsibility Cards – who does what?

7. 1. Entity Classes -used to model data and behaviour of some real life system concept or entity e.g. member, bank account, order, employee. These will sometimes require more persistent storage of information e.g. a student’s details are ultimately stored as a student record. Represent the more permanent aspects of an application so class descriptions are less likely to change e.g. members will always be added, updated and removed from a membership system.

8. 2. Boundary (interface) Classes - model the interaction and manage communication between the computer system and its users. but don’t directly represent the specific interface object used to identify the main logical interfaces with users and other systems (including e.g. other software packages, printers). main task is to translate information across system boundaries partition the system so that interface is kept separate from business logic These will end up as describing screens, reports, HTML pages, or other system interfaces that actors interact with.

9. 3.Control Class – approx 1 per use case glue between boundary elements and entity elements, describing the logic required to manage the various elements and their interactions Represent coordination, sequencing, transactions and control of other objects Represents the calculation and scheduling aspects if the logic of the use case i.e those bits of functionality that are not specific to the entity class but are specific to the use case.

10. What control classes do we need? Roughly one per use case. BUT Many controllers can be simple enough to be implemented as a method of an entity or boundary class.

11. Why do we do this? Stereotyping boundary classes means that the system is partitioned so that any changes to the interface or communication part are localised there. Stereotyping entity classes provide a model of the more permanent aspects of the application domain The control classes represent the calculation and scheduling aspects of the logic of the use case. If the functionality required changes, then the change can be localised.

12. Why do we use this model? Seperating the interface and control elements make it easier to change the software as change is localised. E.g. A new interface Minor changes in functionality

13. Example Agate (p246) Packages mark out related but distinct application areas: advert preparation, staff management, campaign management. campaign management Control staff management advert preparation User Interface

14. Drawing a Class Diagram 1.Think about the things and concepts in the application domain which are important to the goals of the system being developed, 2.Identify entities and relationships. 3.Look at the use cases and identify sets of classes that can interact to realise each use case. 4.Draw a robustness diagram to show this 5.Add detail – draw a communication diagram, use CRC cards

15. Example: Issue dvd Identify relevant entities :loan :dvd :customer attendant Which entities are involved in issuing a dvd? – check the use case template

16. Add boundary and control objects Issue dvd Issue dvd use case Issue dvd user interface Entities dvd Loan Customer Issue dvd :loan :issuedvd :issuedvdUI :dvd:customer

17. Collaboration Diagrams A collaboration can realise a specific use case. It identifies participating objects and the links between them Issue dvd :loan :issuedvd :issuedvdUI :member

18. Example : Make appointment 1. Entity Classes Doctor Appointment Patient 2. Interface class: Make_appointment_UI 3. Control class: Make_appointment

19. Robustness/Communication Diagram A collaboration can realise a use case. It identifies participating objects and the links between them Make Appointment (use case) :makeapt :makeaptUI :patient :appointment:doctor

20. Communication Diagrams A communication diagram shows: the internal details of the collaboration The details of interaction between objects in the form of messages passes between them e.g. the issue dvd object sends the UI object a message to start the interface. :issuedvd:issuedvdUI Start interface

21. Communication Diagram – show objects and message passing :loan :issuedvd :dvd 1.Request DVD customer ID 2. Get customer details 4. Get dvd details 5. Add loan details 3. Check overdue dvds :customer attendant :issuedvd_UI

22. Finding operations Nouns and action verbs in the use case template Locate the operation in the same class as the data it needs to update Imagine objects as independent actors (e.g. Bank account) Use e.g. class responsibility cards and act out use case.

23. Creating the Conditions for ReUse Using abstraction/generalisation/ (inheritance in c#) Through the encapsulation of composite structures/ components (polymorphism in c#) Focus on external behaviour, ignoring internal detail of how that behaviour is produced Composition involves encapsulating a group of classes that have the capacity ti be a reusable subassembly

24. Inheritance Hierarchies IS-A, IS-A-Kind-of relationship Abstract and concrete classes The generality of a superclass lets it be used by other systems Use common sense when identifying superclasses.

25. Multiple Inheritance Class inherits features from more than one class.

26. Working with your list of classes Is it beyond the scope of the system? Does it refer to the system as a whole? Does it duplicate another class? Is it too vague? Is it too specific? Is it too tied up with physical inputs and outputs? Is it really an attribute (e.g. name) ? Is it really an operation (e.g. sale or stockitem.sell)