Object-Oriented Design Lecture 14: Design Workflow Sharif University - - PowerPoint PPT Presentation

Department of Computer Engineering

Object-Oriented Design

Lecture 14: Design Workflow

Sharif University of Technology 1

UP iterations and workflow

Sharif University of Technology 2

Preliminary Iteration(s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m +1

Inception Elaboration Construction Transition

Phases Workflows

An iteration in the elaboration phase Requirements Design Implementation Test Analysis

Iterations

Design Workflow

• The design workflow is about determining how the functionality

specified in the analysis model will be implemented.

• The design workflow is the primary modeling activity in the last part of

the Elaboration phase and the first part of the Construction phase.

• The design model contains:
• design subsystems;
• design classes;
• interfaces;
• use case realizations-design;
• a deployment diagram (first-cut).

Sharif University of Technology 3

Trace Relationships

Sharif University of Technology 4

Design Workflow: Design a Class

• The Design Workflow consists of the following activities:
• Architectural Design
• Design a Use Case
• Design a Class
• Design a Subsystem

Sharif University of Technology 5

Design Classes

• Design classes are the building blocks of the design model.
• Design classes are developed during the USDP activity Design a

Class.

• Design classes are classes whose specifications have been

completed to such a degree that they can be implemented.

Sharif University of Technology 6

Design Classes: Sources

• Design classes come from two sources:
• the problem domain:
• a refinement of analysis classes;
• one analysis class may become one or more design classes;
• the solution domain:
• utility class libraries;
• middleware;
• GUI libraries;
• reusable components;
• implementation-specific details.

Sharif University of Technology 7

Design Classes: Sources

• Most of the classes in the Analysis class diagram can be found in the Design class

diagram as well.

• some of the differences between the analysis and the design class

diagrams:

• Controllers
• Objects to implement associations and aggregations
• Objects for performance, persistence, concurrency, interface to other

subsystems, etc.

• Collections for finding objects based on a key value (that comes from the UI,

for example).

Sharif University of Technology 8

Design Classes: Sources

• Some of the classes in the analysis class diagram may not show up

in the design

• They may be outside the system
• The may become attributes of other objects because they don’t have

enough behavior of their own.

• What looked like inheritance at analysis time might be better implemented

another way (e.g., as flag attributes) in the design.

Sharif University of Technology 9

Design Classes: Sources

Sharif University of Technology 10

Design Classes: Anatomy

• Design classes have complete specifications:
• complete set of attributes including:
• name;
• type;
• default value when appropriate;
• visibility;
• perations:
• name;
• names and types of all parameters;
• optional parameter values if appropriate;
• return type;
• visibility.

Sharif University of Technology 11

Design Classes: Anatomy

Sharif University of Technology 12

• TheTrace relationship is a specialization of a Dependency
• connecting model elements or sets of elements that represent the

same concept across models

• Traces are often used to track requirements and model changes

Design Classes: Well-formedness

• The public operations of the class define a contract with its clients.
• Completeness - the class does no less than its clients may

reasonably expect.

• Sufficiency - the class does no more than its clients may reasonably

expect.

• Primitiveness - services should be simple, atomic, and unique.

Sharif University of Technology 13

Design Classes: Well-formedness (Contd.)

• High cohesion:
• each class should embody a single, well-defined abstract concept;
• all the operations should support the intent of the class.
• Low coupling:
• a class should be coupled to just enough other classes to fulfill its responsibilities;
• only couple two classes when there is a true semantic relationship between

them;

• avoid coupling classes just to reuse some code.

Sharif University of Technology 14

Inheritance

• Only use inheritance when there is a clear "is a" relationship

between two classes or to reuse code.

• Disadvantages:
• it is the strongest possible coupling between two classes;
• encapsulation is weak within an inheritance hierarchy, leading to the

"fragile base class" problem: changes in the base class ripple down the hierarchy;

• very inflexible in most languages - the relationship is decided at compile

time and fixed at runtime.

Sharif University of Technology 15

fragile base class

• The base class is the class you are inheriting from
• Often called fragile because changes to this class can have

unexpected results in the classes that inherit from it.

• A best practice to avoid
• label all classes as final unless you are specifically intending to inherit

from them.

• For those to intend to inherit from, design them as if you were designing

an API

• hide all the implementation details
• be strict about what you emit and careful about what you accept
• document the expected behaviour of the class in detail.

Sharif University of Technology 16

Inheritance and Aggregation

• There are two schools of thought on how to best extend, enhance,

and reuse code in an object-oriented system:

• Inheritance: extend the functionality of a class by creating a subclass.

Override superclass members in the subclasses to provide new functionality.

• Aggregation: create new functionality by taking other classes and

combining them into a new class. Attach an common interface to this new class for interoperability with other code.

Sharif University of Technology 17

Inheritance and Aggregation

• we need inheritance or aggregation?
• If The new class is more or less as the original class, Use inheritance. The

new class is now a subclass of the original class.

• If the new class must have the original class, Use aggregation. The new class

has now the original class as a member.

Sharif University of Technology 18

Inheritance and Aggregation

• If we have used inheritance
• but we only use part of the interface
• Or we are forced to override a lot of functionality to keep the correlation

logical

• Then we have a big nasty smell that indicates that we had to use

aggregation.

• If we have used aggregation
• but we find out we need to copy almost all of the functionality
• Then we have a smell that points in the direction of inheritance.

Sharif University of Technology 19

Inheritance and Aggregation

• We should use aggregation if
• part of the interface is not used or has to be changed to avoid an illogical

situation.

• We only need to use inheritance if
• we need almost all of the functionality without major changes.
• when in doubt, use Aggregation.
• The case that we have an class that needs part of the functionality
• split the original class in a root class and a sub class
• let the new class inherit from the root class
• But take care not to create an illogical separation.

Sharif University of Technology 20

Inheritance and Aggregation

• At the beginning of GOF they state:
• "Favor object composition over class inheritance."
• Inheritance should be used only if the relationship is-a is

unequivocally maintained throughout the lifetime of the objects

• otherwise, aggregation is the best choice
• role is often confused with an is-a relationship.
• For example: given the class Employee
• not a good idea to model the roles an employee can play (such as a

manager or a cashier) by inheritance if these roles change

Sharif University of Technology 21

Inheritance and Aggregation

• Subclasses should always represent "is kind of" rather than "is role played by" -

always use aggregation to represent "is role played by".

Sharif University of Technology 22

Multiple Inheritance

• Multiple inheritance allows a class to have more than one parent.
• Of all the common OO languages only C++ has multiple inheritance.
• Design guidelines:
• the multiple parent classes must all be semantically disjoint;
• there must be an "is kind of" relationship between a class and all of its parents;
• the substitutability principle must apply to the class and its parents;
• the parents should themselves have no parent in common;
• use mixins - a mixin is a simple class designed to be mixed in with others in multiple

inheritance; this is a safe and powerful idiom.

Sharif University of Technology 23

Inheritance versus Interface Realization

• Inheritance:
• you get interface - the public operations;
• you get implementation - the attributes, associations, protected and

private members.

• Interface realization: you only get interface.
• Use inheritance when you want to inherit some implementation.
• Use interface realization when you want to define a contract .

Sharif University of Technology 24

Inheritance versus Interface Realization

• Inheritance describes an is-a relationship.
• Implementing an interface describes a can-do relationship.
• general recommendations are as follows:
• Do favor defining classes over interfaces.
• Do use abstract classes instead of interfaces to decouple the contract from
• implementations. Abstract classes, if defined correctly, allow for the same

degree of decoupling between contract and implementation.

• Do define an interface if you need to provide a polymorphic hierarchy of

value types.

• Consider defining interfaces to achieve a similar effect to that of multiple

inheritance.

Sharif University of Technology 25

Templates

• Templates allow you to "parameterize" a type
• create a template by defining a type in terms of formal parameters;
• instantiate the template by binding specific values for the parameters.
• Of all the commonly used OO languages, only C++ and Java

currently support templates.

• Explicit binding uses a dependency stereotyped «bind»:
• show the actual values on the relationship;
• each template instantiation can be named.

Sharif University of Technology 26

Templates: Example

Sharif University of Technology 27

Templates: Implicit Binding

• Implicit binding:
• specify the actual values on the class inside angle brackets « »;
• template instantiations cannot be named - names are constructed from

the template name and the argument list.

Sharif University of Technology 28

Nested Classes

• Defined as a class inside another class.
• The nested class exists in the namespace of the outer class - only the outer class

can create and use instances of the nested class.

• Nested classes are known as inner classes in Java, and are used extensively for

event handling in GUI classes.

Sharif University of Technology 29

Reference

• Arlow, J., Neustadt, I., UML 2 and the Unified Process: Practical Object-

Oriented Analysis and Design, 2nd Ed. Addison-Wesley, 2005.

Sharif University of Technology 30