chapter 5 Objectdesign

1.  Software designing
System designing
 Design goal
 System decomposition
 Persistency /Hw/Sw mapping
Object design
 Service specification.
 Component selection.
 Restructuring.
 Optimization.

2. What is Object Design?
 Object design is the process of adding details to the
requirements analysis and making implementation
decisions
 The object designer must choose among different ways to
implement the analysis model with the goal to minimize
execution time, memory and other measures of cost.
 Requirements Analysis: Use cases, functional and
dynamic model deliver operations for object model
 Object Design:
- Iterates on the models, in particular the object model
and refine the models;
- Serves as the basis of implementation

3. Object design….
 Object design includes four groups of activities
 Service specification:-specify the subsystem services
(identified during system design) in terms of class
interfaces, including operations, arguments, type
signatures, and exceptions. interface specification
 Component selection/Reuse:- use and adapt the off-the-
shelf components  class libraries and additional
components for basic data structures and services.
 Restructuring:- manipulate the system model to increase
code reuse or meet other design goals.
 Optimization. address performance requirements of the
system model.

4. 1. Reuse: Identification of existing solutions
 Use of inheritance
 Off-the-shelf components and additional solution objects
 Design patterns
2. Interface specification
 Describes precisely each class interface
3. Object model restructuring
 Transforms the object design model to improve its
understandability and extensibility
4. Object model optimization
 Transforms the object design model to address performance
criteria such as response time or memory utilization.

5. Object design activities

6. Object design activities …..

7.  Specifying Interfaces/service specification
 During Requirements analysis :-
The analysts Identifying attributes and operations without
specifying their types or their parameters.
 Object design: Three activities
Add visibility information
Add type signature information
Add contracts
Visibility Information
 Private
 Protected
 Public

8.  The three levels of visibility:
 Private (Class implementor):
 A private attribute can be accessed only by the class in which it
is defined.
 A private operation can be invoked only by the class in which it
is defined.
 Private attributes and operations cannot be accessed by
subclasses or other classes.
 Protected (Class extender):
 A protected attribute or operation can be accessed by the class
in which it is defined and on any descendent of the class.
 Public (Class user):
 A public attribute or operation can be accessed by any class.

9. Example

10.  Carefully define the public interface for classes as well
as subsystems (façade)
 Always apply the “Need to know” principle.
Only if somebody needs to access the information,
make it publicly possible, but then only through well
defined channels, so you always know the access.
 The fewer an operation knows
the less likely it will be affected by any changes
the easier the class can be changed
 Trade-off: Information hiding vs efficiency
Accessing a private attribute might be too slow (for
example in real-time systems or games)

11. Add Type Signature Information
Add contracts
 Contracts on a class enable caller and callee to share the same
assumptions about the class.
 Contracts include three types of constraints:
 Invariant:
 Precondition:
 Postcondition:
Type signature

12. Examples of Object Design Activities
 Identification of existing components
 Full definition of associations
 Full definition of classes:
 System Design => Service,
 Object Design => API
 Specifying the contract for each component
 Choosing algorithms and data structures
 Identifying possibilities of reuse
 Detection of solution-domain classes
 Optimization
 Increase of inheritance
 Decision on control
 (Re-)Packaging

13. The use of inheritance
 Inheritance is used to achieve two different goals
 Description of Taxonomies
 Interface Specification
 Identification of taxonomies
 Used during requirements analysis.
 Activity: identify application domain objects that are hierarchically
related
 Goal: make the analysis model more understandable
 Service specification
 Used during object design
 Activity:
 Goal: increase reusability, enhance modifiability and extensibility
 Inheritance is found either by specialization or generalization

14. Application Domain vs Solution Domain Objects
Incident
Report
Requirements Analysis
(Language of Application
Domain)
Incident
Report
Object Design
(Language of Solution Domain)
Text box Menu Scrollbar

15. Taxonomy Example
Mammal
Tiger Wolf Wale

16.  Problem with implementation inheritance:
Some of the inherited operations might exhibit unwanted behavior.
What happens if the Stack user calls Remove() instead of Pop()?
 Example: I have a List
class, I need a Stack
class. How about
subclassing the Stack
class from the List class
and providing three
methods, Push() and
Pop(), Top()?
Add ()
Remove()
List
Push ()
Pop()
Stack
Top()
“Already
implemented”
Implementation Inheritance
 A very similar class is already implemented that does almost
the same as the desired class implementation.

17. Implementation Inheritance vs Interface Inheritance
 Implementation inheritance
 Also called class inheritance
 Goal: Extend an applications’ functionality by reusing functionality
in parent class
 Inherit from an existing class with some or all operations already
implemented
 Interface inheritance
 Also called subtyping
 Inherit from an abstract class with all operations specified, but not
yet implemented

18. Client Receiver Delegate
Delegates to
calls
Delegation as alternative to Implementation Inheritance
 In Delegation two objects are involved in handling a request
 A receiving object delegates operations to its delegate.
 The developer can make sure that the receiving object does not
allow the client to misuse the delegate object

19. Delegation instead of Implementation Inheritance
 Inheritance: Extending a Base class by a new operation or
overwriting an operation.
 Delegation: Catching an operation and sending it to another
object.
 Which of the following models is better for implementing a
stack?
+Add()
+Remove()
List
Stack
+Push()
+Pop()
+Top()
+Push()
+Pop()
+Top()
Stack
Add()
Remove()
List

20. Component Selection
 Select existing
 off-the-shelf class libraries
 frameworks or
 components
 Adjust the class libraries, framework or components
 Change the API if you have the source code.
 Use the adapter or bridge pattern if you don’t have access
 Architecture Driven Design

21. Components and Frameworks
 Components
 Self-contained instances of classes
 Plugged together to form complete applications.
 Blackbox that defines a cohesive set of operations,
 Can be used based on the syntax and semantics of the interface.
 Components can even be reused on the binary code level.
 The advantage is that applications do not always have to be recompiled
when components change.
 Frameworks:
 Often used to develop components
 Components are often plugged into blackbox frameworks.

22. Design patterns
 Good designers know not to solve every problem from
first principles. They reuse solutions.
 Practitioners do not do a good job of recording experience
in software design for others to use.
 A Design Pattern systematically names ,explains, and
evaluates an important and recurring design.
 set of well-engineered design patterns that practitioners
can apply when crafting their applications.

23. Becoming a Master Designer
 First, One Must Learn the Rules:
 Algorithms
 Data Structures
 Languages
 Later, One Must Learn the Principles:
 Structured Programming
 Modular Programming
 OO Programming
 Finally
 Design patterns must be understood, memorized, and applied.
 Design patterns helps keep system models simple.

24. Patterns solve software structural problems
like:
 Abstraction,
 Encapsulation
 Information hiding
 Separation of concerns
 Coupling and cohesion
 Separation of interface and implementation
 Single point of reference
 Divide and conquer

25. Patterns also solve non-functional problems
like:
 Changeability
 Interoperability
 Efficiency
 Reliability
 Testability
 Reusability

26. Finding Objects
 The hardest problems in object-oriented system development
are:
 Identifying objects
 Decomposing the system into objects
 Requirements Analysis focuses on application domain:
 Object identification
 System Design addresses both, application and implementation
domain:
 Subsystem Identification
 Object Design focuses on implementation domain:
 Additional solution objects

27. Techniques for Finding Objects
 Requirements Analysis
 Start with Use Cases. Identify participating objects
 Textual analysis of flow of events (find nouns, verbs, ...)
 Extract application domain objects by interviewing client
(application domain knowledge)
 Find objects by using general knowledge
 Extract objects from Use Case scenarios (dynamic model)
 System Design
 Subsystem decomposition
 Try to identify layers and partitions
 Object Design
 Find additional objects by applying implementation domain
knowledge

28. Another Source for Finding Objects : Design Patterns
 Types of design pattern
 Composite Pattern:
 Models trees with dynamic width and dynamic depth
 Facade Pattern:
 Interface to a subsystem
 closed vs open architecture
 Adapter Pattern:
 Interface to reality
 Bridge Pattern:
 Interface to reality and prepare for future

29. Composite Pattern
 Models tree structures that represent part-whole hierarchies with
arbitrary depth and width.
 The Composite Pattern lets client treat individual objects and
compositions of these objects uniformly
Client Component
Leaf
Operation()
Composite
Operation()
AddComponent
RemoveComponent()
GetChild()
Children

30. Example: Graphic application
Client Graphic
Circle
Draw()
Picture
Draw()
Add(Graphic g)
RemoveGraphic)
GetChild(int)
Children
Line
Draw()
• The Graphic Class represents
both primitives (Line, Circle) and
their containers (Picture)

31. Adapter Pattern
 “Convert the interface of a class into another interface clients
expect.”
 The adapter pattern lets classes work together that couldn’t
otherwise because of incompatible interfaces
 Used to provide a new interface to existing legacy components
(Interface engineering, reengineering).
 Two adapter patterns:
 Class adapter:
 Uses multiple inheritance to adapt one interface to another
 Object adapter:
 Uses single inheritance and delegation

32. Adapter Pattern
ClientInterface
Request()
LegacyClass
ExistingRequest()
adaptee
Adapter
Request()
Client
Delegation
Inheritance
The adapter pattern uses inheritance as well as delegation:
- Interface inheritance is used to specify the interface of the Adapter class.
- Delegation is used to bind the Adapter and the Adaptee

33. A Bridge pattern
 The bridge pattern can be used to provide multiple
implementations under the same interface
 Decouples an abstraction from its implementation so that
the two can vary independently
 This allows to bind one from many different
implementations of an interface to a client dynamically
Example use of the Bridge Pattern:
Support multiple Database Vendors

34. Adapter vs Bridge
 Similarities:
 Both are used to hide the details of the underlying implementation.
 Difference:
 The adapter pattern is geared towards making unrelated components
work together
 Applied to systems after they’re designed (reengineering, interface
engineering).
 “Inheritance followed by delegation”
 A bridge, on the other hand, is used up-front in a design to let
abstractions and implementations vary independently.
 Green field engineering of an “extensible system”
 New “beasts” can be added to the “object zoo”, even if these are not
known at analysis or system design time.
 “Delegation followed by inheritance”

35. Facade Pattern
 Provides a unified interface to a set of objects in a subsystem.
 A facade defines a higher-level interface that makes the subsystem
easier to use (i.e. it abstracts out the gory details)
 Facades allow us to provide a closed architecture

36. Design Example
 Subsystem 1 can look into the Subsystem 2
(vehicle subsystem) and call on any
component or class operation at will.
 Why is this good?
 Efficiency
 Why is this bad?
 Can’t expect the caller to understand
how the subsystem works or the
complex relationships within the
subsystem.
Subsystem 2
Subsystem 1
AIM
Card
SA/RT
Seat

37. Read more about Design pattern