CS 151: Object-Oriented Design September 5 Class Meeting Department of Computer Science San Jose State University Spring 2013 Instructor: Ron Mak

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 2 Class Relationships: Dependency  Class C depends on class D : Some method of C manipulates objects of D Example: Mailbox objects manipulate Message objects.  Dependency is asymmetric. The Message class is not aware of the existence of the Mailbox class. Therefore, Message objects do not depend on Mailbox objects.  Loose coupling Minimize the number of dependency relationships. Another way for a design to handle change. _

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 3 Class Relationships: Aggregation  Class C aggregates class A : Objects of class C contains objects of class A over a period of time.  A special case of dependency. The “has-a” relationship. Example: An Inventory object has a list of Instrument objects.  Multiplicity 1:1 – Example: Each Person object has a single StreetAddress object. 1:n – Example: Each Inventory object has an array of multiple Instrument objects.

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 4 Class Relationships: Inheritance  Class C inherits from class S. The “is-a” relationship. All class C objects are special cases of class S objects. Class S is the superclass of class C. Class C is a subclass of class S. An object of class C is an object of class S.  Note Aggregation: A Mailbox object has a Message object. Inheritance: A ForwardedMessage object is a Message object. _

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 5  Class-Responsibilities-Collaborations  An effective technique to discover classes, responsibilities, and relationships.  CRC card is an index card that Describes one class. Lists its responsibilities. Lists its relationship with other classes. _ The CRC Technique

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 6  Example: class Mailbox The CRC Technique Mailbox ResponsibilitiesRelationships Manage passcodeMessageQueue Manage greeting Create new message

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 7 1. Write the class name on each index card. 2. Distribute the responsibilities among the classes. 3. Find out their relationships and list all dependencies of each classes. 4. Don't write the methods or instance fields. Just write the responsibilities at a high level language. _ The CRC Technique

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 8  A picture is worth a thousand words!  It is much easier to extract information from a graphical notation than reading a textual document.  Show your design in graphical UML diagrams. UML: Unified Modeling Language  There are several different types of UML diagrams. For now, we’ll use Class diagrams Sequence diagrams State diagrams UML Diagrams

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 9  A class diagram has three compartments: UML Class Diagram Class Name Attributes : types Methods(parms : types) : return type

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 10  Specify the most important attributes and methods.  If you have too many attributes in a class, check if you can group them into a new class.  Example: You have attributes that are specific to your class. You have attributes that are specific to your class. But you also have name, street, city, state, and zip attributes. But you also have name, street, city, state, and zip attributes. Create a new Address class to contain those attributes. Create a new Address class to contain those attributes. Then your class has an address. Then your class has an address. UML Class Diagram: Attributes and Methods

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 11 Example UML Class Diagram Mailbox newMessages : ArrayList savedMessages : ArrayList add(msg : Message) : boolean getCurrentMessage() : Message

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 12  Relationships among classes using arrows. UML Class Diagram: Relationships Dependency Aggregation Inheritance Composition Association Direct association Interface implementation

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 13  Multiplicity in a “has” relationship. UML Class Diagram: Multiplicities

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 14 UML Class Diagram: Aggregation  Aggregation A “has a” relationship. A “has a” relationship. The contained object can have an existence independent of its container. The contained object can have an existence independent of its container. Example Example  A mailbox has a set of messages.  A message can exist without a mailbox.  Therefore, a mailbox aggregates messages. Mailbox Message 1*

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 15 UML Class Diagram: Composition Mailbox MessageQueue 11  Composition A “has a” relationship. A “has a” relationship. The contained object cannot (logically) have an existence independent of its container. The contained object cannot (logically) have an existence independent of its container. Example Example  A mailbox has a message queue.  The message queue cannot (logically) exist without a mailbox.  Therefore, a mailbox composes a message queue.

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 16  A class diagram is static. It shows the classes that exist throughout the lifetime of the system.  A sequence diagram shows the dynamic relationships among the classes at run time. It describes interaction among objects over time during run time. _ UML Sequence Diagram

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 17 Customer Withdraw cashKeypadBank Account Display select notify display confirmation enter amount notify verify accept notify display bank ads notify dispense cash TIMETIME Withdraw Cash Sequence Diagram UML Sequence Diagram

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 18  Use underlined font for object names to distinguish between class and object names.  The dashed vertical lines are lifelines.  A rectangle on a lifeline is an activation bar.  It shows when a object has control executing a method.  The activation bar ends when the method returns.  The horizontal arrows are call arrows.  Use a sequence diagram to illustrate complex interactions among a set of objects.  Don't show loops or branches. _ UML Sequence Diagram

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 19  At run time, the state of an object is characterized by the values of its fields.  In some objects, different states can cause different behaviors.  Example: A voice mail system Caller dials voice mail number  the state is "Connected" Caller dials voice mail number  the state is "Connected" If caller dial a valid extension  the state is "Recording" If caller dial a valid extension  the state is "Recording"  If in "Recording" state the caller can type in the passcode  the state is "Main menu“ _ UML State Diagram

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 20 Connected Recording Main menu Main menu Change passcode Change passcode Passcode Entered Hang up # 3 Passcode Entered Extension Entered Hang up UML State Diagram

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 21 Free UML Design Tools  StarUML:  Violet: Dr. Horstmann’s product _ Dr. Horstmann’s product _

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 22  The javadoc utility creates a set of HTML pages for your classes.  It reads specially formatted comments in your code. Delimit comments for javadoc by /** and */ Delimit comments for javadoc by /** and */  It copies the first sentence of your comment to a summary table. Write the first sentence carefully. Write the first sentence carefully. It should start with an uppercase letter and end with a period. It should start with an uppercase letter and end with a period. javadoc

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 23 javadoc  Javadoc comment example: Method paramname explantion Method paramname explantion Function return explanation Function return explanation If the method throws an exceptionname explanation If the method throws an exceptionname explanation /** * Choose the test string with the highest score and return it. sequence the current sequence. store the sequence store. the chosen test string. */ private String chooseString(CurrentSequence sequence, SequenceStore store) {... }

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 24  On the command line: javadoc path /*.java  You can also run javadoc from within NetBeans or Eclipse. _ Run the javadoc Utility Demo

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 25  Write only the skeletons of your classes. No implementation initially. No implementation initially. Just include javadoc comments. Just include javadoc comments. The result is an outline summary of your design. The result is an outline summary of your design.  Example: Program Design and javadoc /** * Choose the test string with the highest score and return it. sequence the current sequence. store the sequence store. the chosen test string. */ private String chooseString(CurrentSequence sequence, SequenceStore store) { // To be implemented. }