Object-Oriented Design: Starting with Design

1. CSCI-383 Object-Oriented Programming & Design Lecture 6

2. Chapter 3Object-Oriented Design

3. Why Start with Design • Why start our discussion with a chapter on 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

4. Programming in the Small and Programming in the 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

5. 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

6. 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 software development

7. 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

8. 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

9. 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

10. 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

11. Use cases • The first step in use case analysis is to 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 • The next step is to 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

12. 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

13. 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

14. 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

15. How to describe a single use case • Example: Briefly describe a use case for leaving an automated car parking, paying cash

16. 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

17. Library system use case diagram Example: Use-case diagram for a course registration system

18. 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

19. 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

20. 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

21. Example of generalization, extension and inclusion Example: Use-case diagram for a home security system