Domain Modeling (with Objects)

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 • Brainstorm Candidate Classes • Create Initial CRC Cards • Come up with scenarios of use in the domain • Use scenarios to refine CRC Cards

20. Sample CRC Card

21. Sample CRC Card

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

31. Responsibilities • 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?

32. Collaborators • 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?

33. Sample CRC Card

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. More Questions • 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

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

42. Modeling Workshop