Lecture 1 for Chapter 8, Object Design: Reusing Pattern Solutions

1
Chapter 8, Object Design Reuse and Patterns I
2
Introduction

• During requirements and analysis work, we
• Do the right thing
• Understand the domain
• Clarify and record the constraints and
  requirements
• Essentially ignore thinking about the design, and
  focus on understanding the problem.
• . . .
• During design, we
• Do the thing right
• Create a software (and hardware) solution that
  meets the wishes of the stakeholders.

3
From Requirements to Design

• A set of requirements-oriented artifacts (and
  thought) inspire design-oriented artifacts.

4
Changing Hats

• Until this time, we have been wearing an
  investigator hat, essentially ignoring what the
  solution should be.
• Do the right thing
• Now, we take off the investigator hat, and put on
  our designer hats.
• Do the thing right

5
Transition to Object Design

• Requirements Analysis The system is described in
  terms of external behavior, such as its
  functionality (use case model), the application
  domain concepts it manipulates (analysis object
  model), its behaviour in terms of interactions
  (dynamic model), and its non-functional
  requirements.
• System Design The system architecture is
  defined, such as its subsystem decomposition,
  global control flow, persistency management, and
  hardware/software platform.
• Object Design Iterates on the models (in
  particular the analysis object model) and refines
  the models generated during the requirements
  analysis phase. It serves as the basis of
  implementation.

6
Transition to 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.

7
Object Design Closing the Gap
8
Application Domain Objects versus Solution Domain
Objects

• Application domain objects represent concepts of
  the domain that are relevant to the system.
• They are identified by the application domain
  specialists and by the end users.
• Solution objects represent concepts that may not
  have a counterpart in the application domain,
• They are identified by the developers
• Examples Persistent data stores, user interface
  objects, and middleware.

9
Application Domain Objects versus Solution Domain
Objects
Requirements Analysis (Language of
Application Domain)
Object Design (Language of Solution Domain)
Incident Report
Incident Report
Text box
Menu
Scrollbar
10
Activities of Object Design

• The main activities of object design are
• Reuse
• Class libraries and additional components are
  selected for basic data structure and services.
• Design patterns are selected for solving common
  design problems.
• Interface specification
• Subsystem services identified during system
  design are specified in terms of class
  interfaces, including operations, arguments, type
  signatures, and exceptions.
• Application Programmer Interface (API) which is a
  complete interface specification for each
  subsystem is generated.

11
A More Detailed View of Object Design Activities
12
A Little Bit of Terminology Activities

• Object-Oriented methodologies use these terms
• System Design Activity
• Decomposition into subsystems
• .....
• Object Design Activity
• Implementation language chosen
• Data structures and algorithms chosen
• .....
• Structured analysis/structured design uses these
  terms
• Preliminary Design Activity
• Decomposition into subsystems
• Data structures are chosen
• Detailed Design Activity
• Algorithms are chosen
• Data structures are refined
• Implementation language is chosen
• Typically in parallel with preliminary design,
  not a separate activity

13
Object Oriented Design (OOD)

• What kind of methodology do we use during Object
  Oriented Design?
• After identifying the requirements and creating
  a domain model, add methods to the appropriate
  classes, and define messaging between the objects
  to fulfill the requirements
• ????????????????????????????????????????????????

14
Main OO Software Development Principles and
Patterns

• Coupling
• Cohesion
• Separation of Concerns
• Information Hiding

15
Coupling

• It is s a measure of how strongly one element is
  connected to, has knowledge of, or depends on
  other elements.
• If there is coupling or dependency, then when the
  dependent-upon element changes, the dependant may
  be affected.
• For example, a subclass is strongly coupled to a
  superclass. An object A that calls on the
  operations of object B has coupling to Bs
  services.
• We prefer low coupling to reduce the impact of
  change.
• Low coupling tends to reduce the time, effort,
  and defects in modifying software.

16
Cohesion

• Is a measure of how strongly related and focused
  the responsibilities of an element are.
• A class with low cohesion does many unrelated
  things so that it is hard to comprehend, hard to
  reuse, and hard to maintain.
• We prefer high cohesion.

17
Separation of Concerns (SoC)

• It modularizes or separates distinct concerns
  into different areas, so that each has a cohesive
  purpose.
• For example, the domain layer of software objects
  emphasizes relatively pure application logic
  responsibilities, whereas a different group of
  objects is responsible for the concern of
  connectivity to external systems.
• For example, MVC can separate content from
  presentation.

18
Information Hiding

• It conceals the details of implementation from
  its clients to minimize the coupling.
• Any details that clients do not need to know in
  order to use it properly should be hidden.

19
UML versus Design Principles

• UML is a standard visual modeling language,
  knowing its details does not teach how to think
  in objects.
• UML is sometimes described as a design tool.
• ???????????????????????????????????????
• Neither UML or any other technology can be a
  design tool.
• The critical design tool for software
  development is a mind well educated in design
  principles.
• Larman, Craig. Applying UML and Patterns - Third
  Edition

20
OO Design Principles

• Gang-of-For (GoF) Design Patterns
• http//en.wikipedia.org/wiki/Design_Patterns
• OO design modeling will be based on
  Responsibility-Driven Design (RDD) how to
  assign responsibilities to collaborating objects.

21
Responsibility-Driven Design (RDD)

• In RDD, objects have responsibilities an
  abstraction of what they do.
• There are two types of responsibilities
• DOING responsibilities of an object
• doing something itself, such as creating an
  object or doing a calculation
• initiating an action in other objects
• controlling and coordinating activities in other
  objects
• KNOWING responsibilities of an object
• knowing about private data
• knowing about related objects
• knowing about things it can drive or calculate

22
Responsibility-Driven Design (RDD)

• Responsibilities are assigned to classes of
  objects during object design.
• For example, a Sale class is responsible for
  creating SaleLineItems (a doing).
• For example, a Sale class is responsible for
  knowing its total (a knowing).

23
Responsibility-Driven Design (RDD)

• The translation of responsibilities into methods
  depends on the magnitude of the responsibility.
• Big responsibilities take hundreds of classes and
  methods.
• Little responsibilities might take one method.
• For example, the responsibility to provide
  access to relational databases may involve two
  hundred classes and thousands of methods packaged
  in a subsystem.
• For example, the responsibility to create a
  Sale may involve only one method in one class.

24
Responsibility-Driven Design (RDD)

• RDD also requires collaboration.
• Responsibilities are implemented by means of
  methods that either act alone or collaborate with
  other methods and objects.
• RDD leads to viewing an OO design as a community
  of collaborating objects.

25
Reuse Concepts During Analysis

• During analysis, we use inheritance to classify
  objects into taxonomies.
• This allows us to differentiate the common
  behavior of the general case, that is the
  superclass (base class), from the behavior that
  is specific to specialized objects, that is the
  subclasses (derived class).
• The focus of generalization (identifying a common
  superclass) and specialization (identifying new
  subclasses given an existing superclass) is to
  organize analysis objects into an understandable
  hierarchy.
• Readers can understand the core functionality.

26
Taxonomy Example
Mammal
Wale
Wolf
Tiger
27
Reuse Concepts During Object Design

• Inheritance
• The focus of inheritance during object design is
  to reduce redundancy and enhance extensibility.
• By factoring all redundant behavior into a single
  superclass, we reduce the risk of introducing
  inconsistencies during changes, such as bug fixes
  since we have to make changes only once for all
  subclasses.
• By providing abstract classes and interfaces, we
  can write new specialized behavior by writing new
  subclasses that comply with the abstract
  interfaces.
• For example, we can manipulate images in terms of
  an abstract Image class which defines all the
  operations that all Images should support
  (GIFImage, JPEGImage, etc.)

28
Reuse Concepts During Object Design

• Delegation
• Inheritance yields strong coupling along the
  inheritance hierarchy.
• Delegation is the alternative to inheritance that
  should be used when reuse is desired.
• A class is said to delegate to another class if
  it implements an operation by sending a message.
• When to use inheritance or delegation is not
  always clear, and it requires some experience and
  judgement on the part of the developers.
• Design patterns use both inheritance and
  delegation.

29
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

30
Delegation as an Alternative to Implementation
Inheritance

• Delegation is a way of making composition (for
  example aggregation) as powerful for reuse as
  inheritance
• In Delegation two objects are involved in
  handling a request
• A receiving object delegates operations to its
  delegate

Delegate
Receiver
Client
calls
Delegates to
31

• Many design patterns use a combination of
  inheritance and delegation

32
Design Patterns

• Experienced OO developers build up a repertoire
  of both general principles and formal solutions
  that guide them in the creation of the software.
• Design patterns are descriptions of communicating
  objects and classes that are customized to solve
  a general design problem.
• A design pattern identifies the participating
  classes, their roles and collaborations, and the
  distribution of responsibilities.
• Each design pattern focuses on a particular OO
  design problem.

33
Frameworks

• Frameworks also offer opportunities for reuse.
• Frameworks are partially completed software
  systems. They may be targeted at a specified type
  of application, for example GUI framework such as
  Javas Swing framework.
• A framework provides an implementation for the
  core functions and includes mechanism to allow
  developers to plug in the varying functions.
• For example, Javas Swing GUI framework provides
  many classes and interfaces for core GUI
  functions.
• Developers can add specialized widgets by
  subclassing from Swing classes.
• Middleware frameworks are used to integrate
  existing distributed applications and components,
  such as Microsoft DCOM, Java RMI, and CORBA.

34
Design Patterns versus Frameworks

• Patterns are more abstract and general than
  frameworks.
• A pattern is a description of the way that a type
  of problem can be solved, but the pattern is not
  itself a solution.
• Frameworks focus on reuse of concrete designs,
  algorithms, and implementations in a particular
  programming language.
• Patterns focus on reuse of abstract designs and
  small collection of cooperating classes.
• Patterns are more primitive than frameworks.
• A framework can employ several patterns, but a
  pattern cannot incorporate a framework.
• Patterns are building blocks of framework.

35
Frameworks versus Class Libraries

• Classes in a framework cooperate to provide a
  reusable architectural skeleton for a family of
  related applications.
• Class libraries are less domain specific and
  provide a smaller scope of reuse.
• For example, classes for strings and complex
  numbers can be used across many application
  domains.

36
Frameworks versus Class libraries

• Class Libraries
• Less domain specific
• Provide a smaller scope of reuse
• Class libraries are passive no constraint on
  control flow
• Framework
• Classes cooperate for a family of related
  applications
• Frameworks are active affect the flow of control
• In practice, developers often use both
• Frameworks often use class libraries internally
  to simplify the development of the framework.
• Framework event handlers use class libraries to
  perform basic tasks (e.g. string processing, file
  management, numerical analysis, etc.)

37
Design Patterns and Non-Functional Requirements

• Patterns address the non-functional requirements
• Maintainability ease with which errors is
  corrected
• Extensibility inclusion of new features and the
  replacement of existing components with new
  improved versions and removal of unwanted
  features
• Restructuring reorganizing of components and
  their relationships to provide increased
  flexibility
• Portability modifying the system so that it may
  execute in different operating environments, such
  as different operating systems and hardware

38
Specifying Interfaces

• Requirements analysis activities
• Identifying attributes and operations without
  specifying their types or their parameters.
• During Object Design, you have to specify the
  interfaces
• Add visibility information
• Add type signature information

39
Developers play different Roles during Object
Design
40
Class user versus Class Extender
Developers responsible for the implementation
of Game are class implementors
Developers responsible for the implementation of
League are class users of Game
1

The developer responsible for the
implementation of TicTacToe is a class extender
of Game
41
Visibility

• The visibility of an attribute or an operation is
  a mechanism for specifying whether the attribute
  or operation can be used by other classes or not.

42
Visibility

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

43
Implementation of UML Visibility in Java

• public class Tournament
• private int maxNumPlayers

public Tournament(League l, int
maxNumPlayers) public int getMaxNumPlayers()
public List getPlayers() public void
acceptPlayer(Player p) public void
removePlayer(Player p) public boolean
isPlayerAccepted(Player p)
44
Information Hiding Heuristics

• Carefully define the public interface for classes
  as well as subsystems
• 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

45
Information Hiding Design Principles

• Only the operations of a class are allowed to
  manipulate its attributes
• Access attributes only via operations.
• Hide external objects at subsystem boundary
• Define abstract class interfaces which mediate
  between system and external world as well as
  between subsystems.
• Do not apply an operation to the result of
  another operation.
• Write a new operation that combines the two
  operations.

46
Types

• The type of an attribute specifies the range of
  values the attribute can take and operations that
  can be applied to the attribute.
• Operation parameters and return values are typed
  in the same way as attributes are.
• The type constraints the range of values the
  parameter or return value can take
• For an operation, the types of its parameters and
  the type of return value is called the signature.

47
Type Signature Information
Attributes and operations without type
information are acceptable during analysis