1. CS 501: Software Engineering
Lecture 16
Object Oriented Design 1

2. Administration

3. The Waterfall Model Requirements Requirements Analysis System design
Program design
Implementation
Coding
Unit & Integration Testing
System Testing
Acceptance Testing
Operation & Maintenance

4. Program Design The task of program design is to represent the software
system functions in a form that can be transformed into
one or more executable programs.
Given a system architecture, the program design specifies:
programs, components, packages, classes and class hierarchies
interfaces, protocols
security mechanisms, operational procedures

5. The Unified Modeling Language
UML is a standard language for modeling software systems
• Serves as a bridge between the requirements specification and the implementation.
• Provides a means to specify and document the design of a software system.
• Is process and programming language independent.
• Is particularly suited to object-oriented program development.

6. UML Models A UML model consists of:
A diagram. This gives a general overview of the model, showing the principal elements and how they relate to each other.
A specification. This provides details about each element of the model. Specification for models used in program design should have sufficient detail that they can be used to write code from.
A diagram without a specification is not a complete model, but
may be very useful as a design tool.

7. Diagrams in UML A diagram is the graphical representation of a set of
elements, usually rendered as a connected graph of vertices
(things) and arcs (relationships).
• Class diagram shows a set of classes, interfaces, and collaborations with their relationships.
• Object diagram shows a set of objects and their relationships.
• Use case diagram shows a set of use cases and actors (a special kind of class) and their relationships.

8. Diagrams in UML (continued)
An interaction diagram shows an interaction, consisting of a set of objects and the relationships, including the messages that may be dispatched among them.
=> A sequence diagram emphasizes the time ordering.
=> A collaboration diagram emphasizes the structural
organization of the objects that send and receive
messages.

9. Diagrams in UML (continued)
• Statechart diagram shows a state machine consisting of states, transitions, events, and activities.
• Activity diagram is a statechart diagram that shows the flow from activity to activity within a system.
• Component diagram shows the organization and dependencies among a set of components.
• Deployment diagram shows the configuration of processing nodes and the components that live on them.

10. Annotation some text note
A note is a symbol for rendering constraints and comments attached to an element or a collection of elements.

11. Class Diagrams Window name origin attributes size open() operations
close()
move()
display()
name
attributes
operations
responsibilities (optional text)
A class is a description of a set of objects that share the same attributes, operations, relationships and semantics.

12. Notation: Grouping Business rules
A package is a general-purpose mechanism for organizing elements into groups.

13. Packaging Classes
java
applet
HelloWorld
package
awt
Graphics
lang

14. The "Hello, World!" Example
import java.awt.Graphics;
class HelloWorld extends java.applet.Applet {
public void paint (Graphics g) {
g.drawString ("Hello, World!", 10, 10); }
Example from: BJR

15. The HelloWorld Example
class
HelloWorld
paint()
name
operations

16. Abstraction for HelloWorld
class
HelloWorld
paint()
name
annotation
g.drawString ("HelloWorld", 0, 10)"
operations

17. Notation: Relationships
A dependency is a semantic relationship between two things in which a change to one may effect the semantics of the other. *
employer employee
An association is a structural relationship that describes a set of links, a link being a connection among objects.

18. Relationships
Parking 1
ParkingSpace
location
is_available()

19. Notation: Relationships (continued)
child
parent
A generalization is a specialization/generalization relationship is which objects of the specialized element (child) are substitutable for objects of the generalized element (parent).
A realization is a semantic relationship between classifiers, wherein one classifier specifies a contract that another classifier guarantees to carry out.

20. Generalization
Note that the Applet and Graphics classes are shown elided, i.e., just the name is shown, not the attributes or operations.
Applet
generalization
HelloWorld
paint()
dependency
Graphics

21. Notation: Interface ISpelling
An interface is a collection of operations that specify a service of a class or component, i.e., the externally visible behavior of that element.

22. Class Inheritance Diagram
Object
Panel
interface
Component
ImageObserver
Applet
Container
HelloWorld

23. Modeling Classes
Given a real-life system, how do you decide what classes to use?
• What terms do the users and implementers use to describe the system? They are candidates for classes.
• Is each candidate class crisply defined?
• For each class, what is its set of responsibilities? Are the responsibilities evenly balanced among the classes?
• What attributes and operations does each class need to carry out its responsibilities?
Aim for high cohesion within classes and weak coupling
between them.

24. Noun Identification: A Library Example
The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals.
The system must keep track of when books and journals are borrowed and returned and enforce the rules.

25. Noun Identification: A Library Example
The library contains books and journals. It may have several copies of a given book. Some of the books are reserved for short-term loans only. All others may be borrowed by any library member for three weeks. Members of the library can normally borrow up to six items at a time, but members of staff may borrow up to 12 items at one time. Only members of staff may borrow journals.
The system must keep track of when books and journals are borrowed and returned and enforce the rules.

26. Candidate Classes Library the name of the system Book Journal Copy
ShortTermLoan event
LibraryMember
Week measure
MemberOfLibrary repeat
Item book or journal
Time abstract term
MemberOfStaff
System general term
Rule general term

27. Relations between Classes
Book is an Item
Journal is an Item
Copy is a copy of a Book
LibraryMember
Item
MemberOfStaff is a LibraryMember
Is Item needed?

28. Operations LibraryMember borrows Copy LibraryMember returns Copy
MemberOfStaff borrows Journal
MemberOfStaff returns Journal
Item not needed yet.

29. Class Diagram MemberOfStaff LibraryMember 1 1 on loan on loan 0..*
0..12
Journal
Copy
is a copy of
1..*
Book

30. Rough Sketch: Wholesale System
A wholesale merchant supplies retail stores from stocks of goods in a warehouse.
What classes would you use to model this business?

31. Rough Sketch: Wholesale System
RetailStore
Order
Merchant
Product
Warehouse
Shipment
Invoice

32. Rough Sketch: Wholesale System
Merchant
RetailStore
name
address
contactInfo
financialInfo
Shipment
Responsibilities
-track status of shipped products
Warehouse
Order
Product
responsibility (text field)
Reversal
damaged()
return()
wrongItem()
Invoice

33. Expanding a Class: Modeling Financial Information
RetailStore
association *
Transaction
Which class is responsible for the financial records for a store?
Payment
Invoice

34. Modeling Invoice Shipment ??? RetailStore invoiceRecord goodsShipped
invoiceNumber
+goodsShipped()
-sendInvoice()
PartsList
adornments
+ public
- private

35. Lessons Learned
Design is empirical. There is no single correct design. During the design process:
• Eliding: Elements are hidden to simplify the diagram
• Incomplete: Elements may be missing.
• Inconsistency: The model may not be consistent
The diagram is not the whole design. Diagrams must be backed up with specifications.

36. Levels of Abstraction
The complexity of a model depends on its level of abstraction:
• High-levels of abstraction show the overall system.
• Low-levels of abstraction are needed for implementation.
Two approaches:
• Model entire system at same level of abstraction, but present diagrams with different levels of detail.
• Model parts of system at different levels of abstraction.