Object Oriented Design

OBJECT-ORIENTED
SOFTWAREENGINEERING
UNIT 05 : Object Oriented Design
© 2019, PRAMOD PARAJULI

Disclaimer
These slides are part of teaching materials for Object Oriented
Software Engineering (OOSE). These slides do not cover all
aspect of learning OOSE, nor are these be taken as primary
source of information. As the core textbooks and reference
books for learning the subject has already been specified and
provided to the students, students are encouraged to learn
from the original sources.
Contents in these slides are copyrighted to the instructor and
authors of original texts where applicable.
OOSE UNIT 05 - Object Oriented Design

DECOMPOSINGTHESYSTEM
UNIT 05: Object-oriented Design
References:
Bruegge B., andDutoit A. H. 2010, Object-oriented Software Engineering using UML, Patterns and Java, 3rded., Prentice Hall(Chapter 6)
Pressman, R. S., 2001, Software Engineering - A Practitioner's Approach, FifthEd., McGrawHill (Chapter 22)

SYSTEMDESIGNACTIVITIES

SUBSYSTEMSANDCLASSES
 Decompose system into independent systems
 Abstract away one class from rest of the
subsystems
 Recursively apply this technique

COMPONENTSANDDEPENDENCIES
 Use component diagrams to represent different
subsystems and dashed arrow to indicate
dependencies

SERVICESANDCOMPONENTS
 Components provide different services through
interfaces

COHESIONANDCOUPLING
 Cohesion – number of dependencies between
components within a subsystem
 Coupling – number of dependencies between two
subsystems

COHESIONANDCOUPLING
 One of the design rule is to minimise coupling
and enhance cohesiveness

COHESIONANDCOUPLING

LAYERSANDPARTITIONS
 Hierarchical decomposition of a system results
into an ordered set of layers.

ARCHITECTURALSTYLES
 Subsystems can be organised in different ways.
 An architectural style provides a systematic method to
decompose a system. It includes;
– System decomposition,
– global control flow,
– handling boundary conditions, and
– intersubsystem communications

ARCHITECTURALSTYLES
 Repository
 Model-view-controller
 Client-server
 Peer-to-peer
 Four-tier
 Pipe and filter

REPOSITORYARCHITECTURALSTYLE
 Subsystems access and modify a single data structure
called the central repository.
 Subsystems are relatively independent, interact
through the repository.
 Repository may trigger events to control flow
 Used for – database management systems, centralised global
control flow, constantly changing complex data processing tasks
etc.

REPOSITORYARCHITECTURALSTYLE

MODEL-VIEW-CONTROLLER
 Three subsystems
– Model – contains domain knowledge, computation models etc.
– View – represent output to the user
– Controller – manage sequence of interactions with the user
 Useful where input/output representation changes are
required

MODEL-VIEW-CONTROLLER

CLIENT-SERVER
 Server – provides services to instances of other subsystems
called clients
 Clients – request for service via RPC or object broker such as
CORBA, Java RMI, HTTP etc.

PEER-TO-PEER

THREE-TIER
 Interface layer – includes all boundary objects that deal with
the user
 Application logic layer – includes all control and entity
objects
 Storage layer – realises
storage, retrieval,a and
query of persistent objects

FOUR-TIER

PIPE-FILTER
 Filters – subsystems, can run concurrently
 Pipes – associations between them, provide
synchronisation

From objects to subsystems
 Review analysis model
 Identify design goals – e.g. reliability, fault tolerant, security,
modifiability, etc.
 Define various criteria such as - performance, dependability, cost,
maintenance, and end user criteria
❃ Read the details of these criteria from Bruegge & Dutoit, pp.
249-252.

IDENTIFYINGSUBSYSTEMS
 Start with initial set of subsystems decomposed
according to functional requirements.
 Keep functionality related objects together

USINGFAÇADEDESIGNPATTERN
 Allows further reduce dependencies between classes by
encapsulating a subsystem with a simple, unified
interface

References:
Bruegge B., and DutoitA. H. 2010, Object-oriented Software Engineering using UML, Patterns and Java, 3rd ed., Prentice Hall (Chapter 7)
Pressman, R. S., 2001, SoftwareEngineering - A Practitioner's Approach, Fifth Ed., McGrawHill (Chapter 22)

CONCERNS
 Selection of off-the shelf and legacy components
 Mapping of subsystem to hardware
 Design of a persistent data management infrastructure
 Specification of an access control policy
 Design of the global control flow
 Handling of boundary conditions

SELFSTUDY
Since we’ve already covered various design modeling and
diagramming techniques, read following sections from Bruegge &
Dutoit on your own.
7.3 Concepts: UML Deployment Diagrams
7.6 ARENA Case study

ADDRESSINGDESIGNGOALS
Design goals - reliability, fault tolerance, security, modifiability
etc.
 Selecting a hardware config. and a platform – use
deployment diagrams
 Allocating objects and subsystems to nodes – revise the
deployment diagrams using component diagrams
 Identifying and storing persistent data – refine the
component diagrams for data storage

 Identifying persistent objects – determine which object is
persistent to the users e.g. Sensor
 Selecting a storage management strategy – flat fles,
relational databases, object-oriented databases. Ref. to table 7-7.
 Providing access control – detail authentication and
authorisation, global access table (actor, class, operation), use
access control lists (actor, operation), capability associates (class,
operation) paired with an actor

 Designing the global control flow
– Procedure-driven control flow
– Event-driven control flow
– Threads
 Identifying services

 Identifying boundary conditions
– Initial configuration
– Start-up and shutdown
– Exception handling (hardware failure, changes in the
operating environment, software fault etc.)

 Identifying boundary conditions

REVIEWINGSYSTEMDESIGN
Correctness
 Can every subsystem be traced back to a use case or a nonfunctional
requirement?
 Can every use case be mapped to a set of subsystems?
 Can every design goal be traced back to a nonfunctional requirement?
 Is every nonfunctional requirement addressed in the system design model?
 Does each actor have an access policy?
 Is every access policy consistent with the nonfunctional security requirement?

Completeness
 Have the boundary conditions been handled?
 Was there a walkthrough of the use cases to identify missing functionality
in the system design?
 Have all use cases been examined and assigned a control object?
 Have all aspects of system design (i.e., hardware allocation, persistent
storage, access control, legacy code, boundary conditions) been addressed?
 Do all subsystems have definitions?

Consistency
 Are conflicting design goals prioritized?
 Does any design goal violate a nonfunctional requirement?
 Are there multiple subsystems or classes with the same
name?
 Are collections of objects exchanged among subsystems in
a consistent manner?

Reality
 Are any new technologies or components included in the system?
Was the appropriateness or robustness of these technologies or
components evaluated? How?
 Have performance and reliability requirements been reviewed in
the context of subsystem decomposition?
 Have concurrency issues (e.g., contention, deadlocks) been
addressed?

Readability
 Are subsystem names understandable?
 Do entities (e.g., subsystems, classes) with similar names denote
similar concepts?
 Are all entities described at the same level of detail?

MANAGINGSYSTEMDESIGN
Assigning responsibilities
 The architect – ensures consistency in design decisions
and interface styles
 Architecture liaisons – representatives from different
subsystem teams, design subsystem services
 The document editor, configuration manager, and
reviewer

Challenges in design
 Size – no. of issues, objects,
components etc.
 Change – change in
specification of interfaces,
components
 Level of abstraction –
detail of the interfaces
 Reluctance to confront
problems – human
behavior, non
reproducibility
 Conflicting goals and
criteria – different design
goals

Best practices
 Identify and prioritise the design goals for system and make
them explicit
 Make the current version of the system decomposition available
to all concerns
 Maintain an up-to-date glossary
 Confront design problems
 Iterate over

❃ Read ‘7.6 ARENA Case Study’ from
Bruegge B., and Dutoit A. H. 2010, Object-oriented Software Engineering using
UML, Patterns and Java, 3rd ed., Prentice Hall (Chapter 7)

REUSINGPATTERNS
References:
Br
ueg g e B.
, and Dut
o it
A.H.2010, Obj
ec t
-
o r
ient
ed So ft
w ar
e Eng ineer
ing using UML
, Pat
t
er
ns and J
ava, 3r
d ed.
, Pr
ent
ic e Hal
l(
Chapt
er8 )
Pr
essm an, R.S.
, 2001, So ft
w ar
e Eng ineer
ing -APr
ac t
it
io ner
's Appr
o ac h, F ift
h Ed.
, Mc G r
aw Hil
l(
Chapt
er22)

OBJECTDESIGN
Includes four groups of activities
 Reuse – off-the-shelf or legacy subsystems, classes
 Interface/service specification – identifying subsystem services
 Restructuring of object model – for code reuse, high
cohesiveness, lower coupling
 Optimisation of object model – meet performance
requirements

REUSE
 Reuse existing objects/classes
 Inheritance – decouples classes using superclasses.
Strong coupling along the inheritance hierarchy.

REUSE

REUSE
 Delegation – an alternative to inheritance that should
be used when reuse is desired.
 A class delegates another one if it implements an
operation by sending message to another class.
 Extensibility – extend the functionality (e.g.
containsValue can extend function of containsKey())
 Subtyping – MySet does not inherit from Hashtable

THE LISKOVSUBSTITUTIONPRINCIPLE
If an object of type S can be substituted in all the places where
an object of type T is expected, then S is a subtype of T.
Interpretation
In object design, the Liskov Substitution Principle means that if all classes are subtypes of
their superclasses, all inheritance relationships are specification inheritance
relationships. In other words, a method written in terms of a superclass T must be able to
use instances of any subclass of T without knowing whether the instances are of a
subclass. Consequently, new subclasses of T can be added without modifying the
methods of T, hence leading to an extensible system. An inheritance relationship that
complies with the Liskov Substitution Principle is called strict inheritance.

DESIGNPATTERNS
Design patterns – template solutions for a range of recurring
problems. Contain;
 Name– unique identifier
 Problem description – situation where the pattern is used
 Solution– set of collaborating classes and interfaces
 Consequences– trade-offs, alternatives

DESIGNPATTERNS

DESIGNPATTERNS
Example – in previous example, Adapter pattern, the
participating classes are;
 Client class – accesses the pattern
 Pattern interface – realised by abstract class or an interface
 Implementor class – provides lower-level behavior
 Extender class – provides a different implementation or
extended behavior of the pattern

REUSEACTIVITIES
Selecting design patterns and components;
 To adapt to changes, design patterns help by
reducing amount of time and effort.

SELECTINGPATTERNS

❃ Read from
Bruegge B., and Dutoit A. H. 2010, Object-oriented Software Engineering using UML,
Patterns and Java, 3rd ed., Prentice Hall (Chapter 8)
8.4.1 Encapsulating data stores with the bridge pattern
8.4.2 Encapsulating legacy components with the adapter pattern
8.4.3 Encapsulating context with the strategy pattern
8.4.4 Encapsulating platforms with the abstract factory pattern
8.4.5 Encapsulating Control Flow with the Command Pattern
8.4.6 Encapsulating Hierarchies with the Composite Design Pattern
8.4.7 Heuristics for Selecting Design Patterns

IDENTIFYINGANDADJUSTINGAPPLICATIONFRAMEWORKS
 Application frameworks – reusable partial application that can
be specialised to produce custom applications.
 Different than class libraries, frameworks are trageted to
particular technologies such as data processing, cellular
communications, user interfaces, real-time components etc.

FRAMEWORKCLASSIFICATIONACCORDINGTOTHEIRPOSITION
INTHESOFTWAREDEV.PROCESS
 Infrastructure frameworks – operating systems, debuggers,
communication protocols, user interfaces etc.
 Middleware frameworks – used to integrate existing
distributed applications and components. E.g. Microsoft’s MFC,
DCOM, Java RMI, WebSphere, WebLogic, Corba, transactional
databases etc.
 Enterprise application frameworks – application specific, e.g.
JavaEE

FRAMEWORKEXAMPLE:WebObject

MANAGINGREUSE
Advantages
 Lower development effort
 Lower risk
 Widespread use of standard
terms
 Increased reliability
Challenges
 Not invented here (NIH)
syndrome
 Process support
 Training

DOCUMENTINGREUSE
 Reference to system using the solution
 Example of use
 Alternative solutions considered
 Encountered trade-offs

REUSEROLES
 Component expert
 Pattern expert
 Technical writer
 Configuration manager

SPECIFYINGINTERFACES
References:
Bruegge B., and DutoitA. H. 2010, Object-oriented Software Engineering using UML, Patterns and Java, 3rd ed., Prentice Hall (Chapter 9)
Pressman, R. S., 2001, SoftwareEngineering - A Practitioner's Approach, Fifth Ed., McGrawHill (Chapter 22)

ALLPREVIOUSMODELS
 Analysis object model – entity, boundary and control objects
visible to the user
 Subsystem decomposition – cohesive partitions
 Hardware/software mapping – classes, APIs etc.
 Boundary use cases – user’s point of view
 Design patterns – partial object design models

INTERFACESPECIFICATION
 Identify missing attributes and operations – examine each
subsystem service and each analysis object. Identify missing
operations and attributes that are needed to realise the subsystem
service.
 Specify visibility and signatures – define visibility, no. of
parameters etc.
 Specify contracts – services provided by each object, conditions
that must be met to invoke the services, return values

INTERFACESPECIFICATIONCONCEPTS
 Class Implementor, Class Extender, and Class User
 Types, Signatures, and Visibility
 Contracts: Invariants, Preconditions, and Postconditions
 Object Constraint Language
 OCL Collections: Sets, Bags, and Sequences
 OCL Qualifiers: forAll and exists

❃ Read from
 9.3.1 Class implementor, class extender, and class user
 9.3.2 Types, signatures and visibility
 9.3.3 Contracts: invariants, preconditions, and postconditions
 9.3.4 Object constraint language
 9.3.5 OCL collections: sets, bags, and sequences
 9.3.6 OCL qualifiers: forALL and exists

MANAGINGOBJECTDESIGN
Three approaches to document object design
 Self-contained ODD generated from model
 OOD as extension of the RAD
 OOD embedded into source code

EMBEDDED
ODD

OBJECTDESIGNDOCUMENT
1. Introduction
i. Object design trade-offs
ii. Interface documentation guidelines
iii. Definitions, acronyms, and abbreviations
iv. References
2. Packages
3. Class interfaces
Glossary

ROLES
1. The core architect
2. The architecture liaisons
3. The object designers
4. The configuration manager
5. Technical writers

CONTRACTSDURINGREQUIREMENTSANALYSIS
1. Communication among stakeholders
2. Level of detail and rate of change
3. Level of detail and elicitation effort
4. Testing requirements

End of Unit 05 : Object-oriented Design

Object Oriented Design

More Related Content

What's hot

Similar to Object Oriented Design

More from Pramod Parajuli

Recently uploaded

Object Oriented Design