1 / 32

CMPE 135 Object-Oriented Analysis and Design September 12 Class Meeting

This text provides an analysis of the use case for an automatic dog door with a bark recognizer, focusing on nouns, class responsibilities, CRC cards, UML class diagrams, and state diagrams. It also explains the concepts of associations, dependencies, and control splits and synchronizations.

stewartm
Télécharger la présentation

CMPE 135 Object-Oriented Analysis and Design September 12 Class Meeting

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. CMPE 135Object-Oriented Analysis and DesignSeptember 12 Class Meeting Department of Computer EngineeringSan Jose State UniversityFall 2019Instructor: Ron Mak www.cs.sjsu.edu/~mak

  2. Textual Analysis Automatic dog door with bark recognizer: Use case for opening and closing the door. Head First Object-Oriented Analysis & Design by Brett D. McLaughlin, et al. O’Reilly, 2006.

  3. Textual Analysis, cont’d • Nouns • the (owner’s) dog • the owner • the button • bark recognizer • request • inside/outside • dog door • remote control • bark Head First Object-Oriented Analysis & Design by Brett D. McLaughlin, et al. O’Reilly, 2006.

  4. Textual Analysis, cont’d • Not all words are important in a document. • Some nouns refer to entities that areoutside of your system (application). • Examples: owner, dog • Some nouns refer to things you don’t have to model or create. • Example: request • How will the classes that you’ll create support the behavior that your use cases describe?

  5. Review: Class Responsibilities • Responsibilities correspond to verbsin the use cases. • Each responsibility should be owned by one and only one class. • Common mistakes: • Assigning a responsibility to an inappropriate class. • Assigning too many responsibilities to a class. • Ideally, each class should have a single primary responsibility.

  6. Class name Optional Responsibilities of this class Classes this class works with to perform its responsibilities CRC Cards Class, Responsibility, Collaboration Head First Object-Oriented Analysis & Design by Brett D. McLaughlin, et al. O’Reilly, 2006.

  7. CRC Cards for the Dog Door Use Case Head First Object-Oriented Analysis & Design by Brett D. McLaughlin, et al. O’Reilly, 2006.

  8. A B UML Class Diagram: Dependency • Class Auses class B. • This is generally a transient relationship. • Example: A method of class Ais passed a parameter of class B. • Example: A method of class Areturns a value of class B. • In UML diagrams, draw a dashed line with an open arrowhead from class A to class B.

  9. Mailbox msgQueue : Message[ ] UML Class Diagrams: Association • A relationship between class A and class Bthat lasts as long as class A objects and class B objects live at runtime. • Class A can have an attribute (field) that refers to class B.

  10. Mailbox Mailbox Message msgQueue : Message[ ] 1 * UML Class Diagrams: Association, cont’d • In UML class diagrams, draw a solid line with an open arrowhead from class A to class B. • Label the line with the name of the attribute. • Don’t repeat the attribute inside the class box. • To be more specific, use an aggregation or a composition rather than an association. Replace the attribute with the association. msgQueue

  11. Class Diagram Examples • What’s in the frontend package of a compiler? UML package diagram What information can you learn from these class diagrams? Access control + public – private # protected ~ package Writing Compilers and Interpreters, 3rd ed. by Ronald Mak John Wiley & Sons, 2009.

  12. Class Diagram Examples, cont’d • Implement the abstract base classes Parser and Scanner with language-specific subclasses. Writing Compilers and Interpreters, 3rd ed. by Ronald Mak John Wiley & Sons, 2009.

  13. UML State Diagram • A state diagram depicts the various states that a single object may be in at run time and the transitions between those states. • A state represents a stage in the runtimebehavior pattern of the object. • A state of an object is characterized by the values of its fields. • A transition is triggered by an internal or external event on the object.

  14. Basic State Diagram Symbols  • Represent a state with a rectangle. • A simple state • A state with internal activities. • An arrow from one state to another represents a transition between states. • A filled circle represents the object’s initial state. • A filled circle nested inside another circle represents the object’s final state. • There can be more than one final state. https://www.smartdraw.com/state-diagram/

  15. State Diagram Example: Undergraduate State changes of an undergraduate. https://www.lucidchart.com/pages/uml-state-machine-diagram

  16. State Diagram Example: College Class State changes of a college class. http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm

  17. State Diagram Example: Class During Enrollment State changes of a college class during the enrollment period. http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm

  18. State Diagram Example: Digital Clock State changes of a digital clock during time setting.

  19. State Diagram Example: CPU https://cloud.smartdraw.com/editor.aspx?templateId=011d3688-733e-44de-9b6a-176d4ac950e3

  20. Control Splits and Synchronization • A short heavy bar called a fork represents a control split, with several transitions leaving it: • A short heavy bar called a join represents a synchronization of control, where several concurrent transitions reduce back to one. https://www.smartdraw.com/state-diagram/

  21. State Diagram Example: Airline Passenger State changes of an airline passenger. https://www.lucidchart.com/pages/uml-state-machine-diagram

  22. Design Goals for Good Classes • Reliable • Robust • Flexible • Coherent • Loosely coupled • Easy to use (by other programmers) • Safe to use • Easy to test • Easy to extend • Easy to maintain Good design is not easy!

  23. A Proposed C++ Time Class • Enable programs to manipulate times. • Example: // Construct a Time object to represent // the current date and time. Time *now = new Time(); // Print out the time such as // Tue Sep 12 14:50:10 PST 2019 cout << now->time_string() << endl;

  24. Points in Time Object-Oriented Design & Patterns, 2nd ed. by Cay Horstmann John Wiley & Sons, 2006.

  25. Methods of the Time Class • Member functions Time::after() and Time::before() are convenience functions. • Not necessary, but nice to have. • A time value is represented as a scalar value. • The number of milliseconds since the epoch.

  26. The time_string Function • The time_string() member function of the Time class is primarily for debugging purposes. • It would be awkward to have to parse the string that it returns.

  27. What about Month, Day, and Year? • The Time class can delegate to a Calendar class the task of converting the number of milliseconds since the epoch to year, month, day, hour, minute, and second fields. • Example Calendar classes: • GregorianCalendar • LunarCalendar • MayanCalendar • etc.

  28. Calendar Classes • The specific Calendar class can encapsulate a changing part of an application’s design. • Make Calendar an abstract base class for the GregorianCalendar class and any other calendar classes you may write: Time Calendar Gregorian Calendar Lunar Calendar

  29. Some Functions of the Calendar Class

  30. What’s Wrong with this Code? • This code is permanently bound to the Gregorian calendar. • What if you decide later to switch to the lunar calendar? GregorianCalendar*g = new GregorianCalendar(); g->set(Calendar::YEAR, 2019); g->set(Calendar::MONTH, Calendar::FEBRUARY); g->set(Calendar::DATE, 14);

  31. What’s Wrong with this Code? cont’d • Instead, code to the interface. • In this case, the interface is the abstract Calendar class. • “Code to the interface” is an important design principle that increases flexibility. Calendar *cal= CalendarFactory::create(type); cal->set(Calendar::YEAR, 2019); cal->set(Calendar::MONTH, Calendar::SEPTEMBER); cal->set(Calendar::DATE, 12);

  32. A Static Factory Function • This code creates calendar objects with a static function in the CalendarFactory class. class CalendarFactory { public: static Calendar *create(int type) { switch (type) { case GREGORIAN: return new GregorianCalendar(); case LUNAR: return new LunarCalendar(); ... } } } Calendar *cal = CalendarFactory::create(type); cal->set(Calendar::YEAR, 2019); cal->set(Calendar::MONTH, Calendar::FEBRUARY); cal->set(Calendar::DATE, 14);

More Related