The Development of an Object-Oriented Software Development Methodologyce.sharif.edu/.../Object-Oriented-Design_Lecture-14.pdf · 2015. 12. 4. · Object-Oriented Design Lecture 14:

Department of Computer Engineering

Object-Oriented Design

Lecture 14: Design Workflow

Sharif University of Technology 1

UP iterations and workflow


Prelim inaryIteration (s)

iter.#1

iter.#2

iter.#n

iter.#n+1

ite r.#n+2

iter.#m

iter.#m +1

Inception Elaboration Construction Transition

Phases

Workflows

An iteration in theelaboration 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).


Trace Relationships


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


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.


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.



• 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).



• 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.




Design Classes: Anatomy

• Design classes have complete specifications:

• complete set of attributes including:

• name;

• type;

• default value when appropriate;

• visibility;

• operations:

• name;

• names and types of all parameters;

• optional parameter values if appropriate;

• return type;

• visibility.


Design Classes: Anatomy


• The Trace 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.


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.


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.


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.


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.



• 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.



• 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.



• 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.



• 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


http://rads.stackoverflow.com/amzn/click/0201633612


• Subclasses should always represent "is kind of" rather than "is role played by" -always use aggregation to represent "is role played by".


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.


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 .


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.


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.


Templates: Example


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.


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.


Reference

• Arlow, J., Neustadt, I., UML 2 and the Unified Process: Practical Object-Oriented Analysis and Design, 2nd Ed. Addison-Wesley, 2005.


Documents

The Development of an Object-Oriented Software Development Methodologyce.sharif.edu/.../Object-Oriented-Design_Lecture-14.pdf · 2015. 12. 4. · Object-Oriented Design Lecture 14: