1. Domain Modeling (with Objects)

2. Motivation Programming classes teach – What an object is – How to create objects What is missing – Finding/determining which objects should you create? “Indeed given a set of requirements for an application and a development system like Smalltalk, ‘finding the objects’ is easily the most difficult task an experienced OO developer has to face. —Simon Lewis, The Art and Science of Smalltalk

3. How Hard Could this Be? You work for Otis Build a general purpose elevator system to control the movement of elevators in a building

4. Discussion – Elevator System

5. Without a Domain Model You start writing code without figuring out what needs to be expressed You would not understand the solution space clearly enough Would not understand the problem space clearly enough

6. The Process Software Development is an iterative activity – Start with Object-Oriented Analysis and Design – Move on to OO Programming – Return to OOA/OOD when necessary When creating new functionality To solve problems with the code OO Analysis is just another perspective – Good designers (in any field) shift perspective frequently to create a better design – The boundary between OOA and OOD is fuzzy.

7. Analysis vs. Design Analysis is mostly concerned with the DOMAIN MODEL. What are the objects in the domain and how do they collaborate. I want the iPod to play music (MusicPlayer class) In design, we need to integrate an APPLICATION MODEL What objects do I need to add to get this thing to run on a computer and to be realized in some programming language? The iPod should have a play button, rewind/ffwd done with the wheel (MusicPlayer needs to interact with PlayButton and Wheel classes)

8. Understanding Objects

9. What are Objects? What we came up with just now – Building – Elevator – Floor – Control Panel – … Things! Entities in the system Abstraction of a concept in the solution space

10. Objects have State Elevator – Direction of movement – Current Floor – Moving or at Rest? – Floors to visit

11. Objects have Behavior

12. Objects Collaborate

13. Key Ideas

14. Abstraction

15. Encapsulation

16. Composition

17. Inheritance

18. Modeling Technique – CRC Cards

19. Class-Responsibility-Collaboration Help understand the Domain as Objects – Language Independent – Force Developers to “think” in objects Steps 1.Brainstorm Candidate Classes 2.Create Initial CRC Cards 3.Come up with scenarios of use in the domain 4.Use scenarios to refine CRC Cards

20. Sample CRC Card Class Name (Base-class): Purpose: ResponsibilitiesCollaborators

21. Sample CRC Card Class: Document Purpose: Acts as a container for graphics and text ResponsibilitiesCollaborators Knows content Knows Storage location Insert and Remove Text, Graphics and other Elements

22. Library Automation

23. Step 1 - Candidate Classes Write down all the objects that relate – Domain Analysis – Focus on the nouns (objects are nouns) – Good objects will have attributes and services Now, filter and refine the candidates – Deal with the interface later (if it helps create a GUI class that is user interface) – Are some candidates attributes of others? – Are some subclasses of others? – Are some instances of others?

24. Candidate Class Has clear unambiguous name (from the domain) Has responsibilities (what NOT how) Remembers (knowledge) Is needed (collaborates) Actively participates

25. Tips Don’t forget the user All ideas are potentially good Analyze – make connections Think fast – ponder later

26. Exercise – Come up with Candidate Classes

27. Filter Candidate Classes Core Classes – Pretty sure these are in domain model Undecided Classes – Probably not classes – may be attributes Eliminated Classes – Outside scope of system – Application model classes like UI components tied to implementation

28. Exercise – Filter Classes

29. Step 1 - Result Candidate Classes Filtered Classes

30. Step 2 – Responsibilities and Collaborators Class Name (Base-class): Purpose: ResponsibilitiesCollaborators

31. Things that the class has knowledge about Things that the class can do with the knowledge it has Tips – Verb extractions in the problem or use case – What does the class know? – What is the class expected to do? – What information must be stored about the class to make it unique? Responsibilities

32. To fulfill a responsibility, a class may need to collaborate with another class This happens when the class needs – information that it does not have, or – to modify information that it does not have Tips – What does the class not know and need to know? – Who can provide that? Collaborators

33. Sample CRC Card Class: Document Purpose: Acts as a container for graphics and text ResponsibilitiesCollaborators Knows content Knows Storage location Insert and Remove Text, Graphics and other Elements

34. Exercise – Come up with CRC Cards

35. Step 3 - Scenarios Invent Scenarios – What should these objects do? – What if…? Play the Cards – Assign Roles – Go Through Scenario – Write down new responsibility – Add collaborator objects to help with that responsibility

36. Scenario Guidelines Concrete: – Bob tries to Login to the system with an incorrect password. – Sally creates a new Sorceress character and chooses auto-configuration. Focus on “must do” items first Start easy and move to complex

37. Exercise – Come up with Scenarios

38. What have we got

39. Major Questions Shouldn't there be collaborations in the opposite direction? – Collaborations in CRC cards are one-way relationships from the client to the server Who should do the checking out of the Book? – Librarian or Book itself? Who should tell Borrower to update its knowledge about outstanding Book? – Librarian or Book?

40. Do we need a collaboration between Book and Borrower for the know set of books responsibility? – Collaborations are not usually needed for responsibilities that simply hold information. – Collaboration is needed only for situations where an object actually sends a message to a Collaborator. – Borrower does not need Book's help to put a Book in a set More Questions

41. When to Stop Stable Model No new class discovery No C / R being added

42. Modeling Workshop