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

Object-Oriented Design Lecture 14: Design Workflow Sharif University of Technology 1 Department of Computer Engineering

UP iterations and workflow Phases Workflows Inception Elaboration Construction Transition Requirements An iteration in the elaboration phase Analysis Design Implementation Test Preliminary iter. iter. iter. iter. iter. iter. iter. Iteration(s) #1 #2 #n #n+1 #n+2 #m #m +1 Iterations 2 Sharif University of Technology

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). 3 Sharif University of Technology

Trace Relationships 4 Sharif University of Technology

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 5 Sharif University of Technology

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. 6 Sharif University of Technology

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. 7 Sharif University of Technology

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). 8 Sharif University of Technology

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. 9 Sharif University of Technology

Design Classes: Sources 10 Sharif University of Technology

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. 11 Sharif University of Technology

Design Classes: Anatomy • 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 12 Sharif University of Technology

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. 13 Sharif University of Technology

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. 14 Sharif University of Technology

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. 15 Sharif University of Technology

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. 16 Sharif University of Technology

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. 17 Sharif University of Technology

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. 18 Sharif University of Technology

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. 19 Sharif University of Technology

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. 20 Sharif University of Technology

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 21 Sharif University of Technology

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". 22 Sharif University of Technology

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. 23 Sharif University of Technology

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 . 24 Sharif University of Technology