Object-Oriented Design and Analysis

1. CSCI 383 Object-Oriented Programming & Design Lecture 7 Martin 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 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 CSCI 383 Lecture 7 M. van Bommel

15. Use case diagrams • A use case diagramis 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 CSCI 383 Lecture 7 M. van Bommel

16. Library system use case diagram Example: Use-case diagram for a course registration system CSCI 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 CSCI 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 CSCI 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 CSCI 383 Lecture 7 M. van Bommel

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