Unit- V: Object oriented System

Design

Brain storming
What is System Design?
What are the role of the
developers in System Design?
System design is:

• The transformation of analysis model into system design model.

• During system design, developers define the design goals of the project

and decompose the system into smaller subsystems that can be realized

by individual teams.

• Developers also select strategies for building the system, such as:

 The hardware/software strategy,

 The persistent data management strategy,

 The global control flow,

 The access control policy, and


• The result of system design is a model that includes a
subsystem decomposition and a clear description of each of
these strategies.
• System design is decomposed into several activities, each
addressing part of the overall problem of decomposing the
system:
 Identify design goals,

 Design the initial subsystem decomposition, and

 Refine the subsystem decomposition to address the

design goals
 Overview of system Design
• Analysis in the requirements model describes the following points:

 A set of Non- Functional requirements and constraints.

 Use case model

 Object model

 A sequence diagram

• The analysis model describes the system completely from the actors’ point of view

and serves as the basis of communication between the client and the developers.

• The analysis model, however, does not contain information about the internal

structure of the system, its hardware configuration, or more generally, how the

system should be realized.

System design is the first step in this direction. System design
results in the following products:

• Design goals, describing the qualities of the system that

developers should optimize

• Software architecture, describing the subsystem decomposition

in terms of subsystem responsibilities, dependencies among

subsystems, subsystem mapping to hardware, and major policy
decisions such as control flow, access control, and data storage

• boundary use cases, describing the system configuration, start-

up, shutdown, and exception handling issues.

The Activity Diagram of System Design
Non-functional
Analysis
Requirements
Dynamic Model

Analysis Object Model

System
Design
Design Goals

Sub System
Object
Decomposition
design

Object Design Model

 Subsystems and Classes
• A subsystem is a replaceable part of the system with
well-defined interfaces that encapsulates the state and
behaviour of its contained classes.
• A subsystem typically corresponds to the amount of
work that a single developer or a single development
team can tackle.
• By decomposing the system into relatively independent
subsystems, concurrent teams can work on individual
subsystems with minimal communication overhead.
For example, the accident management system we previously described can be

decomposed into:

• A DispatcherInterface subsystem, realizing the user interface for the

Dispatcher;

• A FieldOfficerInterface subsystem, realizing the user interface for the

FieldOfficer;

• An IncidentManagement subsystem, responsible for the creation,

modification, and storage of Incidents;

• A ResourceManagement subsystem, responsible for tracking available

• Resources (e.g., FireTrucks and Ambulances);

• A MapManagement for depicting Maps and Locations; and a Notification

subsystem, implementing the communication between FieldOfficer terminals

 FieldOfficerInterface DispactherInterface

MapManagement
IncidentManagemt

Notification
ResourceManagement

Subsystem decomposition for an accident management system (UML component diagram).

Subsystems are shown as UML components. Dashed arrows indicate dependencies between
subsystems.
 Services and Subsystem Interfaces
• A subsystem is characterized by the services it provides to other

subsystems.

• A service is a set of related operations that share a common purpose.

• A subsystem providing a notification service, for example, defines

operations to send notices, look up notification channels, and subscribe

and unsubscribe to a channel.

• The set of operations of a subsystem that are available to other subsystems

form the subsystem interface.

• The subsystem interface includes the name of the operations, their

parameters, their types, and their return values.

• System design focuses on defining the services
provided by each subsystem, that is, enumerating the
operations, their parameters, and their high-level
behaviour.
• Object design will focus on the application
programmer interface (API), which refines and
extends the subsystem interfaces.
• The API also includes the type of the parameters and
 Coupling and Cohesion

• Coupling is the number of dependencies between two subsystems.

• If two subsystems are loosely coupled, they are relatively independent, so

modifications to one of the subsystems will have little impact on the other.

• Cohesion is the number of dependencies within a subsystem.

• If a subsystem contains many objects that are related to each other and perform

similar tasks, its cohesion is high.

• If a subsystem contains a number of unrelated objects, its cohesion is low. A

desirable property of a subsystem decomposition is that it leads to subsystems

with high cohesion.

 Layers and Partitions
• A hierarchical decomposition of a system yields an ordered set of layers.

• A layer is a grouping of subsystems providing related services, possibly

realized using services from another layer.

• Layers are ordered in that each layer can depend only on lower level

layers and has no knowledge of the layers above it.

• The layer that does not depend on any other layer is called the bottom

layer, and the layer that is not used by any other is called the top layer .

• In a closed architecture, each layer can access only the layer

immediately below it.

• In an open architecture,1 a layer can also access layers at deeper levels.

 A:Subsystem

B:Subsystem C:Subsystem

D:Subsystem

G:Subsystem
E:Subsystem F:Subsystem
 Architectural Styles
• As the complexity of systems increases, the specification of system
decomposition is critical.

• It is difficult to modify or correct weak decomposition once development

has started, as most subsystem interfaces would have to change.

• In recognition of the importance of this problem, the concept of software

architecture has emerged.

• A software architecture includes system decomposition, global control

flow, handling of boundary conditions, and inter-subsystem
communication protocols [Shaw & Garlan, 1996].
 Repository architectural style
• In the repository architectural style ,subsystems access and modify a single

data structure called the central repository.

• Subsystems are relatively independent and interact only through the repository.

• Control flow can be dictated either by the central repository (e.g., triggers on the

data invoke peripheral systems) or by the subsystems (e.g., independent flow of

control and synchronization through locks in the repository).

• Repositories are typically used for database management systems, such as a

payroll system or a bank system.

• The central location of the data makes it easier to deal with concurrency and

integrity issues between subsystems.

 Model/View/Controller Architectural Style

• In the Model/View/Controller (MVC) architectural style , subsystems are

classified into three different types:

 Model subsystems maintain domain knowledge,

 View subsystems display it to the user, and

 Controller subsystems manage the sequence of interactions with the user.

• The model subsystems are developed such that they do not depend on

• any view or controller subsystem. Changes in their state are propagated to the

view subsystem via a subscribe/notify protocol.

• The MVC is a special case of the repository where Model implements the central

data structure and control objects dictate the control flow.

 Initiator repository
Controller Model

notifier

Subscriber

View
 Client/Server Architectural Style
• In the client/server architectural style, a subsystem, the server,

provides services to instances of other subsystems called the

clients, which are responsible for interacting with the user.

• The request for a service is usually done via a remote procedure

call mechanism or a common object broker (e.g., CORBA, Java

RMI, or HTTP).

• Control flow in the clients and the servers is independent except

for synchronization to manage requests or to receive results.

 Server
Client
<<provide interfaces>>
service1()
service1()
…
serviceN()
 Peer-to-Peer Architectural Style
• A peer-to-peer architectural style is a generalization of the client/ server
architectural style in which subsystems can act both as client or as servers,
in the sense that each subsystem can request and provide services.
• The control flow within each subsystem is independent from the others
except for synchronizations on requests.
• An example of a peer-to-peer architectural style is a database that both
accepts requests from the application and notifies to the application
whenever certain data are changed.
• Peer-to-peer systems are more difficult to design than client/server systems
because they introduce the possibility of deadlocks and complicate the
control flow.
 requester

Peer

service1()
service2()
service3()
….
serviceN()
*

provider
 Three-tier Architectural Style
• The three-tier architectural style organizes subsystems into
three layers.
 The interface layer includes all boundary objects that deal with

the user, including windows, forms, web pages, and so on.

 The application logic layer includes all control and entity

objects, realizing the processing, rule checking, and notification

required by the application.
 The storage layer realizes the storage, retrieval, and query of

persistent objects.
 Interface Form

Application Logic Connection

Query
Storage
 Four- Tier Architectural Style

• The four-tier architectural style is a three-tier architecture in which the

Interface layer is decomposed into a Presentation Client layer and a
Presentation Server layer.
• The Presentation Client layer is located on the user machines, whereas the
Presentation Server layer can be located on one or more servers.
• The four-tier architecture enables a wide range of different presentation clients
in the application, while reusing some of the presentation objects across clients.
• For example, a banking information system can include a host of different
clients, such as a Web browser interface for home users, an Automated Teller
Machine, and an application client for bank employees.
• Forms shared by all three clients can then be defined and processed in the
 Persistence Client Web Browser

Persistence Server Form

Application Logic Connection

Query
Storage
 Pipe and Filter Architectural Style
• In the pipe and filter architectural style, subsystems process data
received from a set of inputs and send results to other subsystems via a
set of outputs.

• The subsystems are called “filters,” and the associations between the
subsystems are called “pipes.”

• Each filter knows only the content and the format of the data received on
the input pipes, not the filters that produced them.

• Each filter is executed concurrently, and synchronization is

accomplished via the pipes.

• The pipe and filter architectural style is modifiable: filters can be

 Reading Assigment
Read and Present
• System Design Activities: From Objects to
Subsystems
• On Page 247 of your text book
 Starting Point: Analysis Model for a Route Planning System
• Using MyTrip, a driver can plan a trip from a home computer by contacting a trip-
planning service on the Web.

Use Case Name Plan Trip

Flow of Events 1. The driver activates her computer and logs into the trip-planning Web-
Services.
2. The driver enters constraints for a trip as a sequence of destinations.
3. Based on the database of maps, the planning service computes the
shortest ways of visiting the destinations in the order specified. The
result is sequence of segments binding a series of crossing and a list of
directions.
4. The driver can receive the trip by adding or removing destinations.
5. The driver saves the planned trip by name in the planning service
database for later retrieval.
• System design consists of transforming of
 Analysis model into Design Model

• System design which takes in account

 Non-functional requirement

 Constraints in statement problem

 requirement Analysis Document

 Identify design goals

• Definition of design goal is the step in system design.

• It defines the quality that the system should focus on.
• Many design goals inferred from
 Non- functional requirements
 Application domain
 Elicited from the client

• There are also criteria for design decisions. These are categorized into five groups. These
include: Performance Are from
 Performance Dependability Requirements
 Dependability End user criteria And
 Cost Application
Domain
 Maintenance
 End user criteria
Are from
Cost
Customer
Maintenance
And
criteria
supplier
 • Performance criteria include the speed and space requirements
imposed on the system.
 Should the system be responsive or should it accomplish a
maximum number of tasks?
 Is memory space available for speed optimizations or should
memory be
Table 2:-Performance used sparingly?
Criteria

Design criterion Definition

Response time How soon is a user request acknowledge after request has been
issued?
Throughput How many tasks can the system accomplish in a fixed period of
time?
Memory How much space is required for the system to run?
 • Dependability criteria determine how much effort should be expended in
minimizing system crashes and their consequences.
 How often can the system crash?

 How available to the user should the system be?

 Are there safety issues associated with system crashes?

 Are there security risks associated with the system environment?

Table 2:-Dependability Criteria

Design criterion Definition

Robustness Ability to survive individual user input.

Reliability Difference between specified and observed behaviour.

Availability Percentage of time system can be used to accomplish normal tasks.

Security Ability to withstand malicious attack

Safety Ability to not endanger human

• Cost criteria include the cost to develop the system, to deploy it, and to administer it.

• Note that cost criteria not only include design considerations but managerial ones as

well.

• When the system is replacing an older one, the cost of ensuring backward

compatibility or transitioning to the new system has to be taken into account.

• There are also trade-offs between different types of costs such as development cost,

end user training cost, transition costs and maintenance costs.

• Maintaining backward compatibility with a previous system can add to the

development cost while reducing the transition cost.

 Table 3:-Cost Criteria

Design criterion Definition

Development cost Cost for developing for the initial system,

Deployment cost Cost of installing the system training the users.

Upgrade cost Cost of translating data from the previous system. This criteria results
in backward compatibility requirements

Maintenance cost Cost required for bug fixes and enhancement to the system

Administration cost Money required to administer the system

• Maintenance criteria determine how difficult it is to change the system after deployment.

• How easily can new functionality be added?

• How easily can existing functions be revised? Can the system be adapted to a different

application domain?

• How much effort will be required to port the system to a different platform?
• These criteria are harder to optimize and plan for, as it is seldom

clear how long the system will be operational and how successful

the project will be.

Table 5:-Maintenance Criteria

Design criterion Definition

Extensibility How easy is it to add the functionality or new classes of the

system?

Modifiability How easy is it to change the functionality of the system?

Adaptability How easy it to port the system to different application domains?

Portability How easy is it to port the system to different platforms?

Readability How easy is it to understand the system from reading the code?

Traceability of requirements How easy is it to map the code to specific requirements?

• End user criteria include qualities that are desirable from a users’ point of view that have
not yet been covered under the performance and dependability criteria. These include:
 Usability (How difficult is the software to use and to learn?) and

 Utility (How well does the system support the user’s work?).

• Often these criteria do not receive much attention, especially when the client contracting
the system is distinct from the users of the system.

Table 5:-End User Criteria

Design criterion Definition

Utility How well does the system support the work of the user?

Usability How easy is it for the user to use the system?

• When defining design goals, only a small subset of these criteria can

be simultaneously taken into account.

• It is, for example, unrealistic to develop software that is safe, secure,

and cheap.

• Typically, developers need to prioritize design goals and trade them

off against each other as well as against managerial goals as the project
runs behind schedule or over budget. The following table lists several
possible trade-offs.
 Table 6:-Examples of design goal trade-offs

Trade-off Rationale

Space Vs. Speed If software does not meet response time or throughput requirements, more memory can
be expended to speed up the software (e.g. caching, more redundancy, etc.). If the
software does not meet memory space constraints, data can be compressed at cost of
speed.

Delivery time Vs. Functionality If the development runs behind schedule, a project manager can deliver less
functionality than specified and deliver on time, or deliver the full functionality at later
time. Contract software usually puts more emphasis on functionality, whereas off- the-
shelf software projects puts more emphasis on delivery date.

Delivery time Vs. Quality If the testing runs behind schedule, a project manager can deliver the software on time
with known bugs(and possibly provide l a later patch to fix serious bugs) or to deliver
the software late with more bugs fixed.

Delivery time Vs. Staffing If development runs behind schedule, a project manager can add resources to the project
in order to increase productivity. In most cases this option is only available early in the
project: Adding resources usually decreases productivity while new personnel is being
trained or brought up to date. Note that adding resources will also raise the cost of
development.
 Identifying Sub-Systems

• subsystem decomposition is constantly revised whenever new issues are

addressed:
 Subsystems are merged into one subsystem,
 a complex subsystem is split into parts, and
 some subsystems are added to take care of new functionality.

• The first iterations over the subsystem decomposition can introduce

drastic changes in the system design model.

• These are often best handled through brainstorming.

• The initial subsystem decomposition should be derived from the

functional requirements.
Example: Decomposing MyTrip System
 We identify two major groups of objects: those that are involved during

the PlanTrip use cases and those that are involved during the

ExecuteTrip use case.

 The Trip, Direction, Crossing, Segment, and Destination classes are

shared between both use cases.

 This set of classes is tightly coupled as they are used as a whole to

represent a Trip.

 We decide to assign them with PlanningService to the

PlanningSubsystem , and the remainder of the classes are assigned to the

RoutingSubsystem.
• This leads to only one association crossing subsystem boundaries.

• Note that this subsystem decomposition follows a repository architecture in

which the PlanningSubsystem is responsible for the central data structure.

Routing Subsystem
PlanningSubsystem

Trip PlanningService
RouteAssistant

Direction Destination

Location

Crossing Segment
PlanningSubsystem:

 The PlanningSubsystem is responsible for constructing a Trip connecting a sequence of

Destinations.

 The PlanningSubsystem is also responsible for responding to re-plan requests from

RoutingSubsystems.

RoutingSubsystem:

 The RoutingSubsystem is responsible for downloading a Trip from the PlanningService and

executing it by giving Directions to the driver based on its Location.

• Another heuristic for subsystem identification is to keep functionally related objects together.

• A starting point is to take the use cases and assign the participating objects that have been

identified in each of them to the subsystems.

 Heuristics for grouping objects into subsystems

Assign objects identified in one use case into the same subsystem.
Create a dedicated subsystem for objects used for moving data among

subsystems
Minimize the number of associations crossing subsystem boundaries
All objects in the same subsystem should be functionally related
 Encapsulating subsystems

• Subsystem decomposition reduces the complexity of the solution

domain by minimizing dependencies among classes.
• The Facade pattern allows us to further reduce dependencies
between classes by encapsulating a subsystem with a simple, unified
interface.
• For example, in f/g figure , the Compiler class is a Facade hiding the
classes CodeGenerator, Optimizer, ParseNode, Parser, and Lexer.
• The Facade provides access only to the public services offered by
the subsystem and hides all other details, effectively reducing
coupling between subsystems.
 Compiler Compiler

Compile(s)
CodeGenerator
Lexer

create() getToken()

Parser

Optimizer generateParseTree()

create() ParseNode

create()
• Subsystems identified during the initial subsystem decomposition
often result from grouping several functionally related classes.
• These subsystems are good candidates for the Facade patterns and
should be encapsulated under one class.
 Over view of Object design
During analysis:

• we describe the purpose of the system. This results in the identification of application

objects that represent user concepts.

During system design:

• We describe the system in terms of its architecture, such as its subsystem decomposition, its

global control flow, and its persistency management.

• We also define the hardware/software platform on which we build the system.

• This results in the selection of off-the-shelf components that provide a higher level of

abstraction than the hardware.

During object design:

• We close the gap between the application objects and the off-the-shelf components by

identifying additional solution objects and refining existing objects.

Object design includes:
• Conceptually, we think of system development as filling a gap between the
problem and the machine.
• The activities of system development incrementally close this gap by
identifying and defining objects that realize part of the system

• Analysis reduces the gap between the problem and the machine by
identifying objects representing user-visible concepts.
• During analysis, we describe the system in terms of external
behavior, such as its functionality (use case model), the application
domain concepts it manipulates (object model), its behavior in terms
of interactions (dynamic model), and its nonfunctional
requirements.
• System design reduces the gap between the problem and the machine by
defining a hardware/software platform that provides a higher level of
abstraction than the computer hardware.
• This is done by selecting off-the-shelf components for realizing standard
services, such as middleware, user interface toolkits, application
frameworks, and class libraries.
• During object design, we refine the analysis and system design models,
identify new objects, and close the gap between the application objects
and off-the-shelf components.
• This includes the identification of custom objects, the adjustment of off-
the-shelf components, and the precise specification of each subsystem
interface and class.
• As a result, the object design model can be partitioned into sets of classes
such that they can be implemented by individual developers.
1. Service specification
• It is specifying the subsystem services interms of class interfaces including:
o Operations
o Arguments
o Type of signature
o Exceptions
• It is also finding the missing operations and objects needed to transfer data among
the subsystems.
• The result of this activity complete interface specification for each subsystem.
• The subsystem system often called subsystem API

2. Component selection
• It use and adapt off-the-shelf component identified during system design to
realize each system
3. Object model restructuring
• It an activity to manipulate the system model to increase code reuse or meet other design
goals.
• Each restructuring activity can be seen as a graph transformation on subset of a particular
model.
• Typical activities includes:
o Transforming N-ary associations into binary associations.

o Implementing binary associations as references

o Merging two similar class from two d/t subsystems into single class.

o Collapsing class with no significant behaviour into attributes.

o Splitting complex classes into simple one.

o Rearranging class and operation to increase inheritance and packaging.

• During restructuring design goals such as

o Maintainability

o Readability

o Understand ability must be addressed.

• Object model optimization

• It address requirements of the system.

• These includes:
o Changing algorithms to respond to speed of memory requirements.
o Reducing multiplicities in associations to speed up queries.
o Add redundant association for efficiency.
o Rearrange execution orders.
o Adding derived attributes to improve access time to objects and
opening up the architecture.
o Adding access to lower layers because of performance
requirement.
 Object design concepts
• the principal object design concepts are:
o Application objects versus solution objects.
o Types, signatures, and visibility
o Preconditions, post conditions, and invariants
o UML’s Object onstraint Language(OCL).

• Application objects, also called domain objects, represent concepts of the domain that the
system manipulates.

• Solution objects represent support components that do not have a counterpart in the application
domain, such as persistent data stores, user interface objects, or middleware.

• During analysis, we identify application objects, their relationships, and attributes and
operations.

• During system design, we identify subsystems and most important solution objects.

• During object design, we refine and detail both sets of objects and identify any remaining
Types, signatures, and visibility revisited

• During analysis, we identified attributes and operations without

specifying their types or their parameters.

• During object design, we refine the analysis and system design models
by adding type and visibility information.

• Operation parameters and return values are typed in the same way as
attributes are.

• The type constrains the range of values the parameter or the return
value can take.

• Given an operation, the tuple made out of the types of its parameters
• The visibility of an attribute or an operation specifies whether it can be used by other

classes or not. UML defines three levels of visibility:

Private

• A private attribute can be accessed only by the class in which it is defined. Similarly, 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

• A protected attribute or operation can be accessed by the class in which it is defined and

on any descendant of the class.

Public

• A public attribute or operation can be accessed by any class.

• Visibility is denoted in UML by prefixing the symbol: – (private), # (protected), or +

(public) to the name of the attribute or the operation.

• Example:
Hashtable

-numElemets:int
Mapping into codes
+put(key:object, entry:object)
+get(key:object):object
+remove(key:Object)
+containsKey(key:Object):boolean class Hashtable {
+size():int
private int numElements;
/* Constructors omitted */
public void put (Object key, Object entry) {…};
public Object get(Object key) {…};
public void remove(Object key) {…};
public boolean containsKey(Object key) {…};
public int size() {…};
/* Other methods omitted */
}
Contracts: Invariants, preconditions, and post conditions
• Contracts are constraints on a class that enable caller and callee to share the same
assumptions about the class.
• A contract specifies constraints that the caller must meet before using the class as well as
constraints that are ensured by the callee when used.

• Contracts include three types of constraints:

An invariant is a predicate that is always true for all instances of a class. Invariants

are constraints associated with classes or interfaces. Invariants are used to specify

consistency constraints among class attributes.

A precondition is a predicate that must be true before an operation is invoked.

Preconditions are associated with a specific operation. Preconditions are used to

specify constraints that a caller must meet before calling an operation.

A post condition is a predicate that must be true after an operation is invoked. Post

conditions are associated with a specific operation. Post conditions are used to specify

constraints that the object must ensure after the invocation of the operation.
 Object Control Language

• OCL is a language that allows constraints to be formally specified on single model elements (e.g.,
attributes, operations, classes) or groups of model elements (e.g., associations and participating
classes).
• A constraint is expressed as an OCL expression returning the value True or False.
• OCL is not a procedural language and thus cannot be used to denote control flow.

<<precondition>> Hashtable <<invariants>>

!containsKey(key) self.numElements>=0
-numElemets:int
<<precondition>>
put(key:object, entry:object) <<postcondition>>
containsKey(key)
get(key:object):object get(Key)==key
remove(key:Object)
<<precondition>> containsKey(key:Object):boolean <<postcondition>>
containsKey(key) size():int !containsKey(key)
 Brain storming

• Discuss object design activities?

 Object design activities

As we have already mentioned in the introduction, object design includes four groups

of activities: specification, component selection, restructuring, and optimization.

• Specification activities include:

identifying missing attributes and operations

specifying type signatures and visibility

specifying constraints

specifying exceptions

• Component selection activities include:

identifying and adjusting class libraries

identifying and adjusting application frameworks

a framework example: WebObjects

• Restructuring activities include:

 realizing associations

increasing reuse

 removing implementation dependencies

• Optimization activities include:

revisiting access paths

collapsing objects: turning objects into attributes

 caching the result of expensive computations

delaying expensive computations

Identifying missing attributes and operations

• In this step:

 The service description of the system examined.

 Missing attributes and operations are identified.

• In the analysis:

 The system focused on it functionality which is described in Use case Model.

 b/c of this the system focused on the application domain may be many attributes

and operations missed.

Specifying type signatures and visibility

• During this step:

 The type of attributes will specified

 The signature of are identified

 The visibility of attributes and operation also identified.

 Layer LayerElement

+label: String +label: String

*
+layer(label: String) 1 elements +layerElement(polyline: Polyline)
+ getOutline(bbox:Rectangle2D, getOutline(bbox:Rectangle2D,
detail:double):Enumeration detail:double):Enumeration
1

polyline
1
Point

- x, y: double Polyline
- intDetailsLevels:Set points
- notDetailLevels:Set * +label: String
*
+polyline()
+point(x, y:double)
+ getPoints():Enumeration
+includeInLeveL(level:double)
+excludeFromLevel(level:double)
Adding type information to the object model of the GIS (UML class diagram). Only
selected classes shown for brevity.
 Specifying constraints
• During this step:
 Constraints attached to classes and operations to more
precisely specify their behavior and boundary cases.
 The main goal is to remove as much ambiguity from
the model as possible.
 We specify class contracts using three types of
constraints.
 Invariants.
 Preconditions.
 Post conditions.
• completed.
Specifying exceptions

• During this step:

• We specify constraints that the caller needs to satisfy before invoking an

• operation.

• In other words, we specify conditions that operations detect and treat as errors by

• raising an exception.

• Languages such as Java and Ada have built-in mechanisms for exception handling.

• Other languages, such as C and early versions of C++ do not support explicit

exception handling, so the developers need to establish conventions and mechanisms

for handling exceptions (e.g., return values or a specialized subsystem).

• Exceptional conditions are usually associated with the violation of preconditions.

 <<exception>>
Layer zeroBoundingBox

+label: String
<<precondition>>
+layer(label: String) bbox.width>0 and
+getOutline(bbox: Rectangle2D, bbox.height>0
detail:double): Enumeration

<<precondition>>
Detail>0

<<exception>>
ZeroDetail

Examples of preconditions and exceptions for the Layer class of the JEWEL GIS.
Component selection activities

• At this point in object design, focused on selecting the software/hardware platform

on which the system runs.

• This platform includes off-the-shelf components such as:

 database management systems,

 middleware frameworks,

 infrastructure frameworks, or

 enterprise application frameworks.

• The main objective in selecting off-the-shelf components is to reuse as many

objects as possible, thus minimizing the number of custom objects that need to be

developed.
 Identifying and adjusting application frameworks

• An application framework is a reusable partial application that can be

specialized to produce custom applications.

• In contrast to class libraries, frameworks are targeted to particular

technologies, such as data processing or cellular communications, or to
application domains, such as user interfaces or real-time avionics.

• The key benefits of application frameworks are reusability and

extensibility.

• Framework reusability leverages of the application domain knowledge

and prior effort of experienced developers to avoid the recreation and
revalidation of recurring solutions.
• An application framework enhances extensibility by
providing hook methods, which are overwritten by the
application to extend the application framework.

• Hook methods systematically decouple the interfaces and

behaviours of an application domain from the variations
required by an application in a particular context.

• Framework extensibility is essential to ensure timely

customization of new application services and features.
• Frameworks can be classified by their position in the software
development process.
 Infrastructure frameworks
 Middleware infrastructure
 Enterprise application frameworks
• Infrastructure and middleware frameworks are essential to rapidly
create high-quality software systems, but they are usually not
requested by external customers.
• Enterprise frameworks, however, support the development of end-user
applications.
• As a result, buying infrastructure and middleware frameworks is more
• Frameworks can also be classified by the techniques used to extend them.

White box frameworks

 Rely on inheritance and dynamic binding for extensibility.

 Existing functionality is extended by sub-classing framework base classes and

overriding predefined hook methods using patterns such as the template method

pattern.

Black box frameworks

 Support extensibility by defining interfaces for components that can be plugged

into the framework.

 Existing functionality is reused by defining components that conform to a

particular interface and integrating these components with the framework, using

delegation.
• Frameworks are closely related to design patterns, class libraries, and

components.
 Design patterns versus frameworks:- The main difference between

frameworks and patterns is that frameworks focus on reuse of concrete

designs, algorithms, and implementations in a particular programming
language.
 Class libraries versus frameworks:- Classes in a framework cooperate to

provide a reusable architectural skeleton for a family of related

applications.
 Component versus frameworks:- Components are self-contained

instances of classes that are plugged together to form complete

applications.
 Restructuring activities

• Realizing associations

• Associations are UML concepts that denote collections of bidirectional links between two

or more objects.
• Object-oriented programming languages, however, do not provide the concept of
association.
• Instead, they provide references, in which one object stores a handle to another object.
• References are unidirectional and take place between two objects.
• During object design, we realize associations in terms of references, taking into account
the multiplicity of the associations and their direction.

Unidirectional one-to-one associations.

Bidirectional one-to-one associations.

One-to- many associations.

Many-to – many associations.

Qualified Associations
 Increasing reuse
• Inheritance allows developers to reuse code across a number of similar classes, For

example, JFC, as do most user interface toolkits, provides four types of buttons:

 A push button (JButton), which triggers an action when the end user clicks on the

button

 A radio button (JRadioButton), which enables an end user to select one choice out of a

set of options

 A checkbox (JCheckBox), which enables an end user to turn an option on or off

 A menu item (JMenuItem), which triggers an action when selected from a pull down or

a popup menu AbstractButton

JButton JMenuItem JToggleButton

JRadioButton JCheckBox
• There are two main advantages to using a well-designed inheritance hierarchy.

1. Code is reused, leading to less redundancies and thus fewer opportunities for

defects.

2. Resulting code is extensible, including a well-documented interface for

creating future specializations.

• Developers must correctly anticipate which behavior should be shared and

which behavior should be refined by the specialization.

• There are two main approaches to designing an inheritance hierarchy for reuse.

 Examining a number of similar classes and abstract that have common

behavior.

 Decoupling a client class from an anticipated change by introducing a level

of abstraction.
 Optimization activities
• The direct translation of an analysis model results into a model that is often inefficient.

• During object design, the object model optimized according to design goals, such as

minimization of response time, execution time, or memory resources. The four simple

optimizations:

 The addition of associations for optimizing access paths

 Collapsing objects into attributes

 Caching the result of expensive computations

 Delaying expensive computations

• When applying optimizations, developers must strike a balance between efficiency and

clarity.

• Optimizations increase the efficiency of the system but also make it more complex and
 Managing object Design
• There are two primary management challenges
during object design:
• Increase communication complexity:-
• Consistency with prior decision and documents
Documenting object design

• Object design is documented in the Object Design Document (ODD).

• It describes:

 Object design trade-offs made by developers

 Guidelines they followed for subsystem interfaces

 the decomposition of subsystems into packages and classes, and the

class interfaces.

• The ODD is used to exchange interface information among teams and as

a reference during testing.

• The audience for the ODD includes system architects, (i.e., the developers
who participate in the system design), developers who implement each
• The ODD enables developers to understand the subsystem sufficiently
well that they can use it.
• Moreover, a good interface specification enables other developers to
implement classes concurrently.
• In general, an interface specification should satisfy the following
criteria:
 Restrictiveness
 Generality
 Clarity

• There are three main approaches to documenting object design.

 Self-contained ODD generated from model.

 ODD as extension of the RAD.

• Self-contained ODD generated from model.
• ODD as extension of the RAD.
• ODD embedded into source code.