1 CMPE 135: Object-Oriented Analysis and Design September 7 Class MeetingDepartment of Computer Engineering San Jose State University Fall 2017 Instructor: Ron Mak
2 Conclusions It takes a journey to achieve Good Design.iterative improvements wrong paths backtracking Developing Great Software can be a messy business! Be willing to fix your own bad design decisions.
3 Analysis Precedes DesignUnderstand the problem. The application is no good if it doesn’t do what it’s supposed to do. Gather requirements from the client. Talk to Rick! Ask him what he wants the software to do.
4 Some Key Points for SuccessThe best way to get good requirements is to understand what the application is supposed to do. Make sure the application works the way the client wants it to work, not necessarily how you would want it to work. To be a successful developer, you must understand the application better than your client. Know exactly what the application needs to do. Be able to anticipate problems.
5 Some Key Points for SuccessYou won’t be successful if your application doesn’t do what the client wants. Use cases are a tool to help you figure that out, before you start to do design.
6 The Only Thing that’s Constant ...... in Analysis and Design is CHANGE Clients (and other stakeholders) change their minds about purpose and requirements. Market conditions change. The environment changes.
7 But Avoid ... Paralysis by Analysis
8 Where Do Classes Come From?Textual analysis Look for nouns and verbs in your use cases. Nouns classes Some nouns are actors. Verbs functions Class names should be nouns in the singular form, such as Inventory, Instrument, InstrumentSpec.
9 Where Do Classes Come From? cont’dHow will the classes support the behaviors that your use cases describe? Focus on concepts, not implementation.
10 Categories of Classes Things AgentsExamples: Instrument, InstrumentSpec Agents Represent doers of tasks. Names often end in “er” or “or” Examples: Scanner, Paginator
11 Categories of Classes, cont’dEvents and transactions Model records of activities that describe what happened in the past or what needs to be done later Example: MouseEvent remembers when and where the mouse was moved or clicked. Users and roles Stand-in for the actual users of the application. Common in systems that are used by more than one person or where one person needs to perform distinct tasks. Examples: Administrator, Reviewer
12 Categories of Classes, cont’dSystem Model a subsystem or the overall system being built. Typical functions: initialize, shutdown, read input System interfaces and devices Interfaces to the host operating system, file system, etc. Foundation Typically the built-in classes. Examples: string, date
13 Class ResponsibilitiesResponsibilities correspond to verbs in 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.
14 Class Responsibilities Exampleclass Automobile start() stop() changeTires() drive() wash() displayOilLevel() checkOil() class Automobile start() stop() displayOilLevel() class Driver drive() class CarWash wash() class Mechanic changeTires() checkOil() Too many responsibilities! A cohesive class does one thing really well and does not try to be something else.
15 Class Relationships: DependencyClass C depends on class D. Some function 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.
16 Class Relationships: Dependency, cont’dLoose coupling Minimize the number of dependency relationships. A key way for a design to handle change.
17 Class Relationships: AggregationClass 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.
18 Class Relationships: Aggregation, cont’dMultiplicity 1:1 – Example: Each Person object has a single StreetAddress object. 1:n – Example: Each Inventory object has an array of multiple Instrument objects.
19 Class Relationships: InheritanceClass 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.
20 Class Relationships: Inheritance, cont’dAggregation: A Mailbox object has a Message object. Inheritance: A ForwardedMessage object is a Message object.
21 UML Diagrams 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
22 UML Diagrams There are several different types of UML diagrams.For now, we’ll mainly use: class diagrams sequence diagrams statechart diagrams
23 UML Class Diagram A class diagram has three compartments: Class NameAttributes : types Methods(parms : types) : return type
24 UML Class Diagram: Attributes and MethodsSpecify the key attributes (member variables) and methods (member functions). If you have too many attributes in a class, check if you can group them into a new class.
25 Example: Attributes and MethodsYou have attributes that are specific to your class. But you also have name, street, city, state, and zip attributes. Create a new Address class to contain those attributes. Then your class has an address.
26 Example UML Class DiagramMailbox new_messages : vector
27 UML Class Diagram: RelationshipsRelationships among classes using arrows. Dependency Aggregation Inheritance Composition Association Direct association Interface implementation
28 UML Class Diagram: MultiplicitiesMultiplicity in a “has” relationship. Sign Purpose * Zero or more 1..* One or more 0..1 Zero or one 1 Exactly one
29 UML Class Diagram: AggregationA “has a” relationship. The contained object can have an existence independent of its container. Example A mailbox has a set of messages. A message can exist without a mailbox. Therefore, a mailbox aggregates messages. Mailbox Message 1 *
30 UML Class Diagram: CompositionA “has a” relationship. The contained object cannot (logically) have an existence independent of its container. Example A mailbox has a message queue. The message queue cannot exist without a mailbox. Therefore, a mailbox composes a message queue. Mailbox MessageQueue 1
31 UML Sequence Diagram 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.
32 UML Sequence Diagram Withdraw Cash Sequence Diagram CustomerDisplay Keypad Bank Account select notify T I M E display confirmation enter amount notify notify display bank ads verify accept notify dispense cash Withdraw Cash Sequence Diagram
33 UML Sequence Diagram Underline object names to distinguish them from class 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 function. The activation bar ends when the function returns. The horizontal arrows are call arrows.
34 UML Sequence Diagram, cont’dUse a sequence diagram to illustrate complex interactions among a set of objects. Don’t show loops or branches.
35 Free UML Design Tools Violet: http://horstmann.com/violet/StarUML:
36 Assignment #2 Write the first draft of the Design Specification for your project. Identify the important classes (at least six). List the set of responsibilities for each class. What is the primary responsibility? Is each class cohesive? Draw UML class diagrams. Show attributes and methods. Show the relationships among the classes. Are they loosely coupled?
37 Assignment #2, cont’d Create a UML sequence diagram.Suggestion: Pick one of your use cases and illustrate the interactions of your objects during the execution of the use case. Create a PDF, name it after your team, and submit into Canvas: Assignment #2. Design Specification Due Friday, September 15 at 11:59 PM.