1. CS 432 Object-Oriented Analysis and Design*
07/16/96
CS 432 Object-Oriented Analysis and Design
Week 3
The Design Model *

3. What is Object-Oriented Design?
The bridge between a user’s requirements and programming for the new system
“Blueprints”, or design models, are necessary to build systems
An adaptive approach to development
Requirements and design are done incrementally within an iteration
A complete set of designs may not be developed at one time

4. Overview of Object-Oriented Programs
Object-oriented programs consist of a set of computing objects that cooperate to accomplish a result
Each object has program logic and data encapsulated within it
Objects send each other messages to collaborate
Most object-oriented programs are event-driven
Instantiation of a class creates an object based on the template provided by the class definition

5. Object-Oriented Design Models
Identify all objects that must work together to carry out a use case
Divide objects into groups for a multilayer design
Interaction diagrams describe the messages that are sent between objects
Includes sequence and communication diagrams
Design class diagrams document and describe the programming classes

6. Object-Oriented Design Models (continued)
Statecharts capture information about the valid states and transitions of an object
Package diagrams denote which classes work together as a subsystem
Design information is primarily derived from
Domain model class diagrams
Interaction diagrams

7. Object-Oriented Design Process
Create a first-cut model of the design class diagrams
Develop interaction diagrams for each use case or scenario (communication or sequence)
Update the design class diagrams
Method names, method parameters, attributes, attribute data types, and relationship multiplicity
Partition the design class diagrams into related functions using package diagrams

8. Design Classes and Design Class Diagrams
Design class diagrams are extensions of domain or analysis class model diagrams
Elaborate on attribute details
Define parameters and return values of methods
Define the internal logic of methods
A first-cut design class diagram is based on the domain model and engineering design principles
Interaction diagrams are used to refine a design class diagram as development progresses

10. The Design Workflow
The input to the design workflow is the set of analysis workflow artifacts
These artifacts are iterated and incremented until they can be used by the programmers
A major aspect of this iteration and incrementation is
The identification of operations or methods
The identification of method parameters and parameter data types
The identification of attribute types, and
Their allocation to the appropriate classes
Relationships between classes – type and multiplicity

11. The Design Workflow (contd)
Many other decisions have to be made as part of the design workflow, including
Choice of programming language
Deciding how much of existing information systems to reuse in the new information system
Level of portability
The allocation of each software component to its hardware component

12. The Design Workflow (contd)
The case studies in this class are small-scale information systems
Under 5,000 lines of Java or C++ code in length
The Unified Process was designed for developing large-scale information systems
500,000 lines of code or more
These information systems are at least 100 times larger than the case studies presented in this class
Therefore, some aspects of the Unified Process are inapplicable to our case studies

13. The Design Workflow (contd)
During the analysis workflow, a large information system is partitioned into analysis packages
Each analysis package consists of a set of related classes that can be implemented as a single unit
Example:
Accounts payable, accounts receivable, and general ledger are typical analysis packages
The concept underlying analysis packages is:
It is easier to develop smaller information systems than larger information systems
A large information system will be easier to develop if it can be decomposed into independent packages

14. The Design Workflow (contd)
The idea of decomposing a large workflow into independent smaller workflows is carried forward to the design workflow
The objective is to break up the upcoming implementation workflow into manageable pieces
Subsystems

15. The Design Workflow (contd)
Reasons why subsystems are utilized
It is easier to implement a number of smaller subsystems than one large system
If the subsystems are independent, they can be implemented by programming teams working in parallel
The information system as a whole can then be delivered sooner

16. The Design Workflow (contd)
The architecture of an information system includes
The various component modules
How they fit together
The allocation of components to subsystems
The task of designing the architecture is specialized
It is performed by an information system architect

17. The Design Workflow (contd)
The architect needs to make trade-offs
Every information system must satisfy its functional requirements (the use cases)
It also must satisfy its nonfunctional requirements, including
Portability, reliability, robustness, maintainability, and security
It must do all these things within budget and within the time constraint
The architect must assist the client by laying out the trade-offs

18. The Design Workflow (contd)
It is usually impossible to satisfy all the requirements, functional and nonfunctional, within the cost and time constraints
Some sort of compromises have to be made
The client has to
Relax some of the requirements;
Increase the budget; and/or
Move the delivery deadline

19. The Design Workflow (contd)
The architecture of an information system is critical
The requirements workflow can be fixed during the analysis workflow
The analysis workflow can be fixed during the design workflow
The design workflow can be fixed during the implementation workflow
But there is no way to recover from suboptimal architecture
The architecture must immediately be redesigned

20. Traditional versus Object-Oriented Design
In the traditional paradigm, the design phase consists of
Architectural design
The information system is decomposed into modules
followed by
Detailed design
Algorithms and data structures are designed for each module

21. Traditional versus Object-Oriented Design (contd)
Classes are modules
Much of traditional architectural design is performed as part of class extraction in the object-oriented analysis workflow

22. Some Fundamental Design Principles
Encapsulation
Each object is a self-contained unit containing both data and program logic
Object reuse
Standard objects can be used over and over again within a system
Information hiding
Data associated with an object is not visible
Methods provide access to data

23. Some Fundamental Design Principles (contd)
Navigation visibility
Describes which objects can interact with each other
Coupling
Measures how closely classes are linked
Want LOW coupling
Cohesion
Measures the consistency of functions in a class
Want HIGH cohesion
Separation of responsibilities
Divides a class into several highly cohesive classes

24. University System Use Case Diagram

25. Analysis Class Diagram

26. How to Create Design-Level Class Diagrams
To create and evolve a design class diagram, you need to iteratively model:
Classes
Responsibilities
Associations
Inheritance relationships
Composition associations
Association classes
Interfaces

27. Classes
An object is any person, place, thing, concept, event, screen, or report applicable to your system.
Objects both know things (they have attributes) and they do things (they have methods).
A class is a representation of an object and, in many ways, it is simply a template from which objects are created.
Classes form the main building blocks of an object-oriented application. 
Although thousands of students attend the university, you would only model one class, called Student, which would represent the entire collection of students.

28. Classes
Classes are typically modeled as rectangles with three sections:
the top section for the name of the class,
the middle section for the attributes of the class,
and the bottom section for the methods of the class.

29. Attributes & Methods
Attributes are the information stored about an object (or at least information  temporarily maintained about an object)
Students have student numbers, names, addresses, and phone numbers.
Methods are the things an object or class do.
Students also enroll in courses, drop courses, and request transcripts.
You should think of methods as the object-oriented equivalent of functions and procedures.

30. Responsibilities or Methods
How to find responsibilities which are methods?
Ask these questions:
How am I going to be used?
How am I going to collaborate with other classes?
How am I described in the context of this system's responsibility?
What do I need to know?
What state information do I need to remember over time?
What states can I be in?

31. Identifying Responsibilities or Methods
Methods usually correspond to queries about attributes (and sometimes association) of the objects.
Methods are responsible for managing the value of attributes such as query, updating, reading and writing.

32. Level of Detail
An important consideration the appropriate level of detail.
Consider the Student class modeled which has an attribute called Address.
Notice how the Address class has been modeled to include an attribute for each piece of data it comprises and two methods have been added: one to verify it is a valid address and one to output it as a label (perhaps for an envelope).
By introducing the Address class, the Student class has become more cohesive.
The Address class could now be reused in other places, such as the Professor class, reducing your overall development costs.
A student may live in a different location than his permanent mailing address, such as a dorm¾information the system may need to track. Having a separate class to implement addresses should make the addition of this behavior easier to implement.

33. Level of Detail in a Design-Level Class Diagram
Class information: visibility and scope

34. Constructors
Constructor methods provide a way of initializing an object.
A constructor method has the same name as its class and is automatically invoked by the object-oriented programming environment (e.g., the Java Virtual Machine) when new instance objects of a class are created.
As the return type of the constructor is always the same as the class and the constructor’s name, the return type is often omitted from the UML visual representation of the constructor.
Since a constructor may also have parameters like any method, the parameters of a constructor can be used to assign initial values to the attributes of the object.

35. Constructor Example
In programming source code, new instance objects are created by using the new command, which executes any code in the constructor, and returns the new object.
// Create a new account object with id 12 and
// assign it to the acct variable. Account acct = new Account(12);
// Get the id of the new account object. int id = acct.getId();

36. Refactoring or Class Normalization
A process in which you refactor the behavior of classes to increase their cohesion and/or to reduce the coupling between classes.
A seminar is an offering of a course, for example, there could be five seminar offerings of the course "CS 208 Introduction to Computer Science." 
The attributes name and fees were moved to the Course class and courseNumber was introduced.

37. Course with Accessor and Mutator Methods
Depicts Course as it would appear with its getter and setter methods modeled

38. Associations (Binary Relationships)
Objects are often associated with, or related to, other objects.
Several associations exist:
Students are ON WAITING LIST for seminars
Professors INSTRUCT seminars
Seminars are an OFFERING OF courses
A professor LIVES AT an address
Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship.
When you model associations in UML class diagrams, you show them as a thin line connecting two classes
The label, which is optional, although highly recommended, is typically one or two words describing the association.
For example, professors instruct seminars.

39. Associations (contd) UML Notation:
You also need to identify the multiplicity of an association.
The multiplicity of the association is labeled on either end of the line, one multiplicity indicator for each direction

40. Multiplicity Indicators
Meaning
0..1
Zero or one 1
One only
0..*
Zero or more
1..*
One or more n
Only n (where n > 1)
0..n
Zero to n (where n > 1)
1..n
One to n (where n > 1)

41. Multiplicity: 1-to-1 (Bank Example)
This multiplicity simply indicates that one Customer object owns exactly one Account Object, and the Account is owned by exactly one customer object.

42. Multiplicity: Many-to-1 (University Example)

43. Inheritance Relationships
Similarities often exist between different classes.
Very often two or more classes will share the same attributes and/or the same methods.
Because you don’t want to have to write the same code repeatedly, you want a mechanism that takes advantage of these similarities.
Inheritance models “is a” and “is like” relationships, enabling you to reuse existing data and code easily.
When A inherits from B, we say A is the subclass of B and B is the superclass of A.
The UML modeling notation for inheritance is a line with a closed arrowhead pointing from the subclass to the superclass.

44. Inheritance hierarchy

45. Guidelines For Identifying Super-sub Relationships: Top-down
Look for noun phrases composed of various adjectives on class name.
Example, Military Aircraft and Civilian Aircraft.
Only specialize when the sub classes have significant behavior.

46. Guidelines For Identifying Super-sub Relationships: Bottom-up
Look for classes with similar attributes or methods.
Group them by moving the common attributes and methods to super class.
Do not force classes to fit a preconceived generalization structure.

47. Guidelines For Identifying Super-sub Relationships: Reusability
Move attributes and methods as high as possible in the hierarchy.
At the same time do not create very specialized classes at the top of hierarchy.
This balancing act can be achieved through several iterations.

48. Guidelines For Identifying Super-sub Relationships: Multiple inheritance
Avoid use of multiple inheritance.
It is also more difficult to understand programs written in multiple inheritance system.
Java does not support multiple inheritance but C++ does.

49. Multiple Inheritance
One way to achieve the benefits of multiple inheritance is to inherit from the most appropriate class and add an object of other class as an attribute.
In essence, a multiple inheritance can be represented as an aggregation of a single inheritance and aggregation. This meta model reflects this situation
Multiple Inheritance
Single Inheritance
Aggregation

50. Abstract Classes & Inheritance
The Person class is abstract: objects are not created directly from it, and it captures the similarities between the students and professors.
Abstract classes are modeled with their names in italics, as opposed to concrete classes, classes from which objects are instantiated, whose names are in normal text.
Both classes had a name, address, and phone number, so these attributes were moved into Person.
The Purchase Parking Pass method is also common between the two classes.
By introducing this inheritance relationship to the model, the amount of work to be performed was reduced.
Instead of implementing these responsibilities twice, they are implemented once, in the Person class, and reused by Student and Professor.

51. Aggregation Relation
An aggregation is an association that supports a loose relation between objects in which one object is considered a “part of” the other object in the relation.
Consider the relation between a Computer and a Printer.
“a Computer may be attached to 0 or more Printers;
at any one point in time a Printer is connected to 0 or 1 Computer;
over time, many Computers may use a given Printer;
the Printer may exist even if there are not attached Computers
the Printer is, in a very real sense, independent of the Computer.”

52. Composition Relation
A composition relation is a stronger form of aggregation that should be used when the part class has no independent existence from the whole.
For example, since a customer’s account would not exist in a system without the customer, it qualifies as a composite relation. In this capacity an Account should be though of as being part-of a customer.

53. Composition Relation (contd)
Another example:
A building is composed of one or more rooms, and then, in turn, that a room may be composed of several subrooms (you can have recursive composition)

54. Customer Order from a Retail Catalog

55. Video Store Example 1 1..* 1 0..1 Multiplicity Customer Simple
Aggregation
Class
Abstract
Class
Rental Invoice
Rental Item
1..* 1
0..1
Composition
Simple
Association
Generalization
Checkout Screen
DVD Movie
VHS Movie
Video Game

56. Association Classes
The association between the two classes may be modeled as a class
You use this when you have many-to-many relationships like the association class in an ERD

57. Interfaces
The C# and Java programming languages allow for the creation of interface entities that capture a collection of methods representing a public interface. (C++ uses abstract classes)
An interface is similar to an abstract class that does not have any concrete methods at all.
An interface is simply a collection of method signatures.
A List interface provides a nice example of the benefits of using interfaces.

58. Interfaces (contd)

59. Interfaces (contd)
Interfaces are implemented, “realized” in UML parlance, by classes and components
To realize an interface a class or component must implement the operations. 
Any given class or component may implement zero or more interfaces and one or more classes or components can implement the same interface.

60. Polymorphism
Polymorphism means many forms and concerns the ability of an object to dynamically take on a different form depending on the runtime context.
Although technically correct, this definition is a bit misleading since the object does not exactly change form, but instead the way in which it’s viewed by other objects changes.
We should also note that polymorphism involves the behavior of objects.

61. Polymorphism (contd)
Consider the following three class fragments taken from a graphical user interface application.
The abstract Component class represents a generic component that captures the common functionality of graphical widgets that can be displayed on a canvas/window.
The Button and TextField classes share the common functionality, having an (x, y) position in the window and responding to messages requesting them to paint themselves on the canvas, erase themselves, and move themselves from one location to another.

62. Polymorphism (contd)

63. Polymorphism (contd)
Assume we are given a List of component objects which we wish to draw on the screen. The following pseudo-code would accomplish this desire:
ForEach component In the list Do Send the component a paint() message;
Polymorphism concerns the fact that although we are sending messages to Component objects, the actual method that handles the message will be executed as part of a Button or TextField object.
When an object receives a message, the most specific method of it’s parent class or it’s ancestors will execute.
However, the key point isn’t what method executes, but what the type of object is receiving the message.

64. Signatures and Method Overloading
A significant difference between procedural functions and object-oriented methods concerns method overloading, which is based on the concept of signatures.
A method signature is the combination of its visibility, name, parameter cardinality (number of parameters), the types of these parameters, and its return type.
For example, all of the methods in the following list have different signatures:
+getId():int OR -getId():int // Visibility differs
+getBalance():int // Different name
+withdraw(amount:int):void // Different name
+withdraw(amount:float):void // Parameter type differs
+withdraw(id: int,amount:float):void// Different parameter cardinality
Note that current object-oriented programming languages require that all methods in the same class and with the same name have the same return type.

65. Overloading
An overloaded method occurs when two or more methods with the same name in the same class have different signatures.
For example, the Withdraw method in the following example class is overloaded.
In this example the withdraw method is overloaded since the parameter type of the single parameter is different in each method.
When an object of this Account class receives a withdraw method, the object-oriented execution environment (e.g., the Java Virtual Machine) will dynamically select and execute the withdraw method with the corresponding parameter type.