1. CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin van Bommel

2. Fall 2010CSCI 383 Lecture 7 M. van Bommel 2 Object-Oriented Design Why start our discussion with design? Object-oriented thinking begins with object-oriented design It is the easiest way to develop an appreciation of the problems of programming in the large (realistic modern software development) Without understanding programming in the large, one cannot understand the importance of OOP

3. Fall 2010CSCI 383 Lecture 7 M. van Bommel 3 Programming in the Small or Large Programming in the Small: One programmer, understands everything from top to bottom Major problem is the development of algorithms Programming in the Large: System is developed by large team of programmers Major problems are management of details and communication between programmers and between their respective software subsystems

4. Fall 2010CSCI 383 Lecture 7 M. van Bommel 4 Basis for Design Consider for the moment what aspects of a problem are known first: Data Structures Functions A Formal Specification Behavior A design technique based on behavior can be applied from the very beginning of a problem, whereas techniques based on more structural properties necessarily require more preliminary analysis

5. Fall 2010CSCI 383 Lecture 7 M. van Bommel 5 Responsibility Driven Design A design technique that has the following properties: Can deal with ambiguous and incomplete specifications Naturally flows from Analysis to Solution Easily integrates with various aspects of development

6. Fall 2010CSCI 383 Lecture 7 M. van Bommel 6 Object-Oriented Analysis Before you can build an object-oriented system, you have to define the classes (objects) that represent the problem to be solved, how the classes relate and interact, the inner workings of objects (attributes and operations), and communication mechanisms (messages) that allow them to work together Object-Oriented Analysis begins with a description of use- cases. Class-responsibility-collaborator (CRC) modeling transforms the information contained in use-cases into a representation of classes and their collaborations with other classes. The characteristics of classes are then modeled using UML

7. Fall 2010CSCI 383 Lecture 7 M. van Bommel 7 Scenarios People find it easier to relate to real-life examples than to abstract descriptions Scenarios are real-life examples of how a system can be used They should include A description of the starting situation A description of the normal flow of events A description of what can go wrong Information about other concurrent activities A description of the state when the scenario finishes

8. Fall 2010CSCI 383 Lecture 7 M. van Bommel 8 Use cases Use-cases are a scenario-based technique in the UML which identify the actors in an interaction and which describe the interaction itself You apply use cases to capture the intended behaviour of the system you are developing, without having to specify how that behaviour is implemented A set of use cases should describe all possible interactions with the system

9. Fall 2010CSCI 383 Lecture 7 M. van Bommel 9 Use cases A use case is a typical sequence of actions that a user performs in order to complete a given task The objective of use case analysis is to model the system From the point of view of how users interact with this system When trying to achieve their objectives A use case model consists of A set of use cases An optional description or diagram indicating how they are related

10. Fall 2010CSCI 383 Lecture 7 M. van Bommel 10 Use case analysis First step – determine the types of users or other systems that will use the facilities of the system. These are called actors An actor is a role that a user or some other system plays when interacting with the system Next step – determine the tasks that each actor will need to do with the system. Each task is called a use case because it represents a particular way of using the system

11. Fall 2010CSCI 383 Lecture 7 M. van Bommel 11 Use cases In general, a use case should cover the full sequence of steps from the beginning of a task until the end A use case should describe the user’s interaction with the system, not the computations the system performs A use case should be written so as to be as independent as possible from any particular user interface design A use case should only include actions in which the actor interacts with the system

12. Fall 2010CSCI 383 Lecture 7 M. van Bommel 12 Building a use case model To build a complete use case model we need to describe the use cases in more detail A use case model consists of a set of use cases, and optional descriptions or diagrams indicating how they are related

13. Fall 2010CSCI 383 Lecture 7 M. van Bommel 13 How to describe a single use case A. Name: Give a short, descriptive name to the use case B. Actors: List the actors who can perform this use case C. Goals: Explain what the actor or actors are trying to achieve D. Preconditions: State of the system before the use case E. Description: Give a short informal description F. Related use cases: List use cases that are generalizations, extensions, or inclusions G. Steps: Describe each step showing actions and responses H. Postconditions: State of the system in following completion

14. Fall 2010CSCI 383 Lecture 7 M. van Bommel 14 How to describe a single use case Example: Briefly describe a use case for leaving an automated car parking, paying cash

15. Fall 2010CSCI 383 Lecture 7 M. van Bommel 15 Use case diagrams A use case diagram is UML’s notation for showing the relationships among a set of use cases and actors A use case diagram can help the software engineer to convey a high-level picture of the functionality of the system

16. Fall 2010CSCI 383 Lecture 7 M. van Bommel 16 Library system use case diagram Example: Use-case diagram for a course registration system

17. Fall 2010CSCI 383 Lecture 7 M. van Bommel 17 Extensions Used to make optional interactions explicit or to handle exceptional cases By creating separate use case extensions, the description of the basic use case remains simple A use case extension must list all the steps from the beginning of the use case to the end Including the handling of the unusual situation

18. Fall 2010CSCI 383 Lecture 7 M. van Bommel 18 Generalizations Much like superclasses in a class diagram A generalized use case represents several similar use cases One or more specializations provides details of the similar use cases

19. Fall 2010CSCI 383 Lecture 7 M. van Bommel 19 Inclusions Allow one to express commonality between several different use cases Are included in other use cases Even very different use cases can share sequence of actions Enable you to avoid repeating details in multiple use cases

20. Fall 2010CSCI 383 Lecture 7 M. van Bommel 20 Example of generalization, extension and inclusion Example: Use-case diagram for a home security system