Object-Oriented Design Lecture 14: Design Workflow Department of Computer Engineering Sharif University of Technology 1
UP iterations and workflow Workflows Requirements Analysis Phases Inception Elaboration Construction Transition An iteration in the elaboration phase Design Implementation Test Prelim inary Ite ration (s) iter. #1 iter. #2 iter. #n iter. #n+1 iter. #n+2 iter. #m iter. #m +1 Iterations Sharif University of Technology 2
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; operations: name; names and types of all parameters; optional parameter values if appropriate; return type; visibility. Sharif University of Technology 11
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 Sharif University of Technology 12
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, 2 nd Ed. Addison-Wesley, 2005. Sharif University of Technology 30