OOSAD Chapter 6 Object Oriented Design.pptx

Chapter 6
Object Oriented Design
Determining How to Build

Outline of topics
Determining how to Build Your System: OO Design
(OOD)
 OO Design Goals
 Architectural Designs- subsystem decomposition, layering
 Design Class Modeling
 Applying Design Patterns effectively
 State Chart Modeling
 Collaboration Modeling
 Component Modeling
 Deployment Modeling
 Relational Persistence Modeling
 User Interface Design
3/25/2024 Chapter 5: Object Oriented Design
2

1. What is Software Design ?
 Design is a problem-solving process the objective of
which is to find and describe a way:
 To implement the system’s functional
requirements...
 while respecting the constraints imposed by
non-functional requirements...
 Such as performance, maintainability, security, persistence,
cost, reliability, portability, etc.…..(long list)
 Including also the budget, technologies, environment, legal
issues, deadlines, ...
 and while adhering to general principles of good
quality.
3

Software Design … Cont’d….
•Design is all about decisions.
 Have Approaches:
 Top down – start with the Blackbox architecture of the system
 Bottom up – start with utilities(reusable objects)
 Design Decisions are a number of very serious design
principles that
 lead to maintainable software that may persist for years
 Will look at satisfying functional requirements while
accommodating portability, reuse potential,
performance
 There are always TRADEOFFS! There is no free lunch!!!--
4

Software Design as Series of Design Issues
A designer is faced with a series of design issues
 These are sub-problems of the overall design problem.
 There are always several alternative solutions: design
options(Design Space).
 Designer makes design decisions to resolve each
issue.
 This process involves choosing the best option from
among the alternatives.
 Recognize that there may be a number of solutions –
in fact, there may be a number of good solutions for
the problem to be solved.
 We would like the “best” one.
5

Design Space- example consider choice of
thin client vs fat client options:
The space of possible designs that could be
achieved by choosing different sets of
alternatives is often called the design space
For example:
6
client-server
monolithic
separate
user interface
layer for
client
no
separate
user interface
layer for client
fat-client
thin-client
programmmed in Java
programmed in .Net
programmed in C++; C#?

Features of the Top-down and Bottom-up
Architectural Design Processes
 Top-down design
 First design the very high level structure of system.
 Then gradually work down to detailed decisions about
low-level constructs.
 Finally arrive at detailed decisions such as:
 the format of particular data items;
 the individual algorithms that will be used.
 Start with the software architecture and the type of
database that will be used (not ‘which’ database).
 Ultimately arrive at specific data items and detailed
algorithms.
7

Top-down and Bottom-Up Design
 Bottom-up design
 Make decisions about reusable low-level utilities.
 Then decide how these will be put together to create
high-level constructs.
 Often times, Mix of top-down and bottom-up approaches
are normally used:
 Top-down design is almost always needed to give the
system a good structure (architecture).
 Bottom-up design is normally useful so that reusable
components can be created.
8

Key Design Principles
 Separation of Concerns. Divide your application into distinct features
with as little overlap in functionality as possible.
 Single Responsibility Principle. Each component or module should
be responsible for only a specific feature or functionality, or
aggregation of cohesive functionality.
 Principle of Least Knowledge (also known as the Law of Demeter or
LOD). A component or object should not know about the internal
details of other components or objects.
 Don't repeat yourself (DRY). You should only need to specify intent
in one place.
 Minimize Upfront Design. Only design what is necessary
now(incremental design- emergent design). This principle is
sometimes known as YAGNI ("You ain't gonna need it").
3/25/2024
Chapter 5: Object Oriented Design
9

A Common Application Architectural Design
10

Design Practices
General Practices
 Keep design patterns consistent within each layer.
 Do not duplicate functionality within an application
 Prefer composition to inheritance.
 Establish a coding style and naming convention for development.
 Maintain system quality using automated QA techniques during
development.
Application Architecture - Layer practices
 Separate the areas of concern between each layer
 Be explicit about how layers communicate with each other.
 Do not mix different types of components in the same logical layer
 Keep the data format consistent within a layer or a component
 Use abstraction to implement loose coupling between layers
11

Design Practices Cont’d…
Component, Modules and Functions -Practices
 A component or an object should not rely on internal details of other
components or objects.
 Do not overload the functionality of a component-let it do single
coherent function.
 Understand how components will communicate with each other
 Keep crosscutting code abstracted from the application
business logic as far as possible (consider aspect oriented
programming).
 Define a clear contract for components. Components, modules,
and functions should define a contract or interface specification
that describes their usage and behavior clearly.
12

Key Design Considerations
 Determine the Application Type
 Mobile apps, rich client apps(on client pc), rich Internet Applications(deployed from
Internet), Service Applications(Apps for communication of loosely coupled
components), Web applications, mashups
 Also, whether you go for Hosted or cloud-based applications and services.
 Determine the Deployment Strategy
 Check deployment patterns
 Distributed and Non-distributed
 Balance the requirements of the application with the appropriate patterns that the
hardware can support and the constraints that the environment exerts on your
deployment options.
 Determine the Appropriate Technologies
 Type of application, preferred options for application deployment topology,
and architectural styles are important factors in selecting technology.
 Choice of technologies will also be governed by organization policies,
infrastructure limitations, resource skills, and so on
13

Key Design Considerations Cont’d…
 Determine the Quality Attributes
 Quality attributes—such as security, performance, and usability—can be used to
focus your thinking on the critical problems that your design should solve.
 There are two types of quality attributes: those that are measured at run time,
and those that can only be estimated through inspection.
 Analyze the tradeoffs between quality attributes
 Determine the Crosscutting Concerns
 Crosscutting concerns represent key areas of your design that
are not related to a specific layer in your application. Such
crosscutting concerns include;
 Event Logging Mechanism ,
 Authentication and Authorization,
 An exception management framework,
 A communication approach between layer,
 Common caching infrastructure (Identify what should be cached, and where to
cache, to improve your application's performance and responsiveness, allows to
cache data in the presentation layer, the business layer, and the data access
layer).
14

2. OO- Software Design
Object-Oriented Design
 Emphasizes a conceptual solution that fulfills the requirements.
 Need to define software objects and how they collaborate to fulfil the
requirements.
Designs are implemented in a programming language
The input for object-oriented design is provided by the
output of object-oriented analysis.
Some typical input artifacts for object-oriented design
are;
 Conceptual model(Analysis Class Model),
 System Use case,
 Sequences Diagram and
 User interface prototype.
15

Object-Oriented Development – a re-cap
Remember that, Object-oriented analysis, design
and programming are related but distinct.
 OOA is concerned with developing an object model of the application
domain.
 OOD is concerned with developing an object-oriented system model to
implement requirements.
 OOP or Implementation is concerned with realising an OOD using an OO
programming language such as Java or C++.
 Implementation is also known as Coding or Construction.
 Design ideas often exclude low-level or obvious details –
obvious to the intended consumers.
 There are subsets of design, including
 architectural design,
 object design,
 database design.
16

OO Software Design –The Process
• Designing of object oriented software requires
– the definition of a multilayered software architecture,
– the specification of subsystems that perform required functions and
provide infrastructure support,
– a description of objects (classes) that form the building blocks of the
system, and
– a description of the communication mechanisms that allow data to
flow between layers, subsystems, and objects.
17

OO Software Design - The Process Cont’d…
OO Design is defined as
 A meaningful engineering representation of something
that is to be built.
18

OO Software Design - The Process Cont’d…
More precisely, the result of a software design must
describe
 the software architecture  how software is
decomposed and organized into components and the
interfaces between those components.
 The components at a level of detail that enables their
construction.
In the software engineering context, design focuses
on four major areas of concern:
 Data, architecture, interfaces, and components.
19

How do we ensure we have good software
design?
At each stage of software design process, work
products are reviewed for ( the 4Cs)
Clarity,
Correctness,
Completeness, and
Consistency
with the requirements and with each other.
20

The OO software Design Steps
OO Software design is
 Is generally considered a two-step process:
i. Architectural design  describes how software is decomposed
and organized into components (the software architecture)
 Class type architecture, Component, Deployment, Persistence
diagrams
ii. Detailed design  describes the specific behavior of these
components.
 Refined class model, State machine, collaboration diagrams
Architectural design:
 The division into subsystems and components,
 How these will be connected.
 How they will interact.
 Their interfaces.
21

Architectural Design -Ways of Dividing a
System
A distributed system is divided into clients and
servers
A system is divided into subsystems
A subsystem can be divided into one or more
packages
A package is divided into classes
A class is divided into methods
22

OO Software Design Principles
The design should be traceable to the analysis model.
The design should not reinvent the wheel(must use
patterns).
The design should “minimize the intellectual distance”
between the software and the problem as it exists in the
real world. (understanding problem produces good
design)
The design should exhibit uniformity and integration.
The design should be structured to accommodate
change. (Extensible)
23

OO Software Design Principles Cont’d…
The design should be structured to be robust, even
when abnormal data, events, or operating conditions
are encountered.
Design is not coding, coding is not design.
The design should be assessed for quality as it is
being created, not after the fact.
The design should be reviewed to minimize
conceptual (semantic) errors.
24

3. Architectural Designs in OO Systems
 Software architecture design is the process of designing
the global organization of a software system, including:
 Dividing software into subsystems.
 Deciding how these will interact.
 Determining their interfaces.
 The architecture is the core of the design, so all software
engineers need to understand it.
 The architecture will often constrain the overall efficiency,
reusability and maintainability of the system.
25

Architectural Designs in OO Systems
 In other words, architecture is focused on organizing components
to support specific functionality. This organization of functionality
is often referred to as grouping components into "areas of
concern."
 Architectural design is the first stage in the software design process.
 But, why do we need to develop an architectural model?(
Their importance)
 To enable everyone better understand the system
 To allow people to work on individual pieces of the system in
isolation
 To prepare for extension of the system
 To facilitate reuse
26

Contents of a Good Architectural Model
A system’s architecture will often be expressed in terms
of several different views
 The logical breakdown into subsystems
 The interfaces among the subsystems
 The dynamics of the interaction among components at
run time
 The data that will be shared among the subsystems
 The components that will exist at run time, and the
machines or devices on which they will be located
27

Documenting Software Architecture
 The software architecture documentation provides an excellent overview of
the key aspects of the system and supports the confirmation that the system
meets its requirements.
 Software architecture involves multiple perspectives, so the architecture
description should also include multiple perspectives.
 The software architecture should be represented by using a set of relevant
views defined by viewpoints, where a viewpoint serves as a guide for a view.
 These architectural views include those development artifacts that are
considered architecturally significant(major elements of a system) from
a particular viewpoint.
 Kruchten’s 4+1 architecture view model is one such good model to
document architectural designs.
28

Architectural Views (Representing Architecture: The 4+1 View Model
)
3/25/2024 Chapter 5 Object Oriented Design
29
Process View Deployment
View
Logical View Implementation
View
Programmers
Software management
Performance
Scalability, Concurrency,
Throughput, Parallelism…
System Integrators
System topology
Delivery, installation
Communication
System Engineering
Use-Case
(scenario) View
Structure
Analysts/
Designers
End-user
Functionality
Functional requirements

Architectural Views Vs. Models
A View is a complete description (an
abstraction) of a system from a particular
view-point or perspective – covering particular
concerns and omitting others not relevant to this
perspective.
Different ‘views’ from different ‘stakeholders;
have different concerns.
A Model is a complete representation.
30

The 4+1 Architectural Views - description
 The End user Requirements (use case) View describes the architecturally significant
requirements, both functional and nonfunctional.
 The Logical View contains the architecturally significant analysis and design elements,
their relationships, and their organization into components, packages, and layers, as
well as a few selected realizations that illustrate how these architecturally significant
elements work together to provide the architecturally significant scenarios described in
the Requirements View.
 The Implementation View describes the key implementation elements (executables,
directories) and their relationships.
 The Process View describes the independent threads of control in the system and what
logical elements participate in these threads. (shows how, at run-time, the system is
composed of interacting processes).
 The Deployment View describes the various system nodes (such as computers,
routers, and virtual machines/containers) and the allocation of the architecturally
significant logical, implementation, or process elements to these nodes.
31

Architectural Design- Qualities (Booch)
 Good software architectures tend to have several attributes in common.
 They are constructed in well-defined layers of abstraction, each layer
representing a coherent abstraction, provided through a well-defined and
controlled interface, and built on equally well-defined and controlled facilities
at lower levels of abstraction.
 There is a clear separation of concerns between the interface and
implementation of each layer, making it possible to change the
implementation of a layer without violating the assumptions made by its
clients.
 The architecture is simple: Common behavior is achieved through common
abstractions and common mechanisms.
 Architectures constructed in this way tend to be less complex and more robust and
resilient. They also enable more effective reuse
32

Architectural Patterns
 Architectural pattern is a stylized, abstract description of good
practice, which has been tried and tested in different systems and
environments.
 Architectural style/patterns Examples
 Layered ( such as MVC) , Client/Server (2 or 3 tier), Repository, Pipe and Filter
 For-example, the well-known Model-View-Controller pattern is the
basis of interaction management in many web-based systems.
 Patterns have a :
 name,
 a brief description (with an associated graphical model), and
 an example of the type of system where the pattern is used (again, perhaps with a graphical
model)
 The following slide shows a conceptual and run-time view of the MVC pattern.
33

MVC Architectural pattern - Conceptual and Run-time
Views
34

Representing Architectural Design with UML
 All UML diagrams can be useful to describe aspects of the
architectural model
 Some UML diagrams are particularly suitable for architecture
modelling and for implementation issues:
 Class Type architecture (not in UML)-Layering Software
Components.
 Component diagrams (reusable/replaceable unit with a
coherent functionality and controlled interfaces)
 Deployment diagrams (Run-time elements’
Arrangement)
 Persistent diagram (Data)
 Package/subsystem diagram –system decomposition-
modularity
35

Basic tasks In OO Design - Modeling
Class Type Architecture (not in UML)
Class diagrams
State chart diagrams
Collaboration diagrams
Component models
Deployment diagrams
Persistent diagram
Evolving UI
36

4. Class Type Architecture( not in UML)
 A common architectural strategy, some might call it a pattern, is
to layer the architecture of a system into several layers
 Some strategies simply define N layers stacked on top of each
other where layer J interacts only with layers J-1 and J+1.
 That's an interesting theory, and it clearly makes sense from a
logical point of view, but in practice it is found that it isn't quite
so simple.
 The following slide presents a high-level layering strategy for a
software application.
 The various layers are represented by the rectangles and
collaboration between layers by the arrows.
 The primary name of a layer is indicated first, and other
common names in parenthesis
37

Layered Class Type Architecture
38

Layered Architecture Design ( the MVC)
39

Class Type Architecture - Layers Description
Interface:
 There are two categories of interface classes – user interface (UI)
classes that provide people access to your system and system
interface (SI) classes that provide access to external systems to
your system
Domain
 This layer implements the concepts pertinent to your business
domain such as Student or Seminar, focusing on the data aspects of
the business objects, plus behaviors specific to individual objects
40

Class Type Architecture - Layers Description
Cont’d…
 Process
 The process layer implements business logic that involves collaborating
with several domain classes or even other process classes
 Persistence
 Persistence layers encapsulate the capability to store, retrieve, and delete
objects/data permanently without revealing details of the underlying
storage technology. often implemented between your object schema
and your database schema and there are various tools available to you.
 Examples include ORM ( Object _Relational Mapping)
 System
 System classes provide operating-system-specific functionality for your
applications, isolating your software from the operating system (OS) by
wrapping OS-specific features, increasing the portability of your application
41

Common Application Architectural components
42

5. Design Class Modeling
 The class model at the design level will add some additional
details than that of the analysis level class model.
 Here the focus will be the solution domain rather than the
problem domain.
 In practice, the analysis level class model will evolve into a
design level class model.
 There will be changes to be introduced to the analysis class
model based on implementation technologies.
 This gives the developers the chance to make amendments and
modification to improve the quality of the system.
 Changes will also be forced into the class model due to the
implementation technology to be used.
43

Design Class Modeling cont’d…
The design level class model will concentrate on how
to implement attributes methods, inheritance,
association, aggregation, composition and the likes.
Modeling Methods
 Methods, also called operations( at higher level of abstraction) or
member functions, are the object-oriented equivalent of functions
and procedures.
 The design level will model more information about methods than
the analysis.
44

Design Class Modeling Cont’d…
Modeling Methods Cont’d…
 The design level may include:
 Visibility: the level of access that external objects have to a
method.
 To reduce the effect of coupling within a system, more restrictions
on access of methods should be set.
 In other words, if a method does not have to be public then make
it protected and if it does not have to be protected then make it
private.
45

Design Class Modeling – Method Visibility
Types
46

Modeling Methods Cont’d…
 Name: Descriptive name for the method. A good name is
the one that is capable of explaining the purpose of the
methods just by looking at its name.
 In giving a name to methods the designer needs to know what
programming language will be used for the development so that
the naming convention of that language will be used here.
 Parameters: The names of parameters, and optionally
their types and default values (if any);
 Return value type: The data type of the return value (if
available)
47

Modeling Attributes
Attributes are the data aspects of objects.
The design level will model more information about
methods than the analysis.
The design level may include:
Visibility: This is the level of access external
objects have to an attribute.
48

Design Class Modeling Attribute visibility
Cont’d…
49

Modeling Attributes Cont’d…
 Name: descriptive name to attributes.
 A good attribute name is the one that is capable of explaining the
purpose of the attribute just by looking at its name.
 naming convention !
 Attributes that are collections, such as arrays, should be given
names that are plural to indicate they represent multiple values,
the rest should be singular.
 The most important technique for designing and using attributes
effectively is not to access them directly in your code
50

Following are some of the recommendations for
attribute design:
 Assign private visibility to all attributes;
 Update attributes only in their setter methods;
 Directly access attributes only in their getter methods;
 enforce simple validation logic for an attribute in its setter
method;
 Implement complex validation logic in separate methods;
and
 Apply initialization in getter methods for attributes
51

Type: The data type of an attribute should be
determined (could be a primitive type, such as
string or int, or a class such as Address.)
Initial value: The initial value for an attribute should
also be indicated (if available).
52

Modeling Association
 Objects in any system cannot exist and work alone. For
this reason they need to depend one another or collaborate
with each other.
 The dependency and collaboration will help the development
team to define how they interact with each other.
 The collaboration is important as an object needs to know about
another object to work with it.
 For each association multiplicity should be modeled, one on
each end of the association line
 Model a dependency when one of the instances is
transient.
53

 Modeling Association
 In Design, Minimize coupling and Maximize cohesion.
 Coupling
 When one class interacts with another class, but does not know any of the
implementation details of the other class, we say they are loosely coupled.
 A class is coupled to another class when it has knowledge of that other class.
 Coupling is important because when Class A is coupled to Class B, a change
in B could necessitate a change in A.
 Cohesion
 Cohesion is a measure of how much an item, such as a class or method,
makes sense.
 A good measure of the cohesiveness of something is how long describing it
takes using only one sentence: the longer it takes, the less cohesive it likely
is. You want to design methods and classes that are highly cohesive.
54

Analysis Vs Design Class Modeling
55
Analysis Level Design Level

Sample Design Class Diagram-
What is missing?
+createAccount()
+activateAccount()
+deactivateAccount()
+alert()
+updateProfile()
-accountHolderId
-firstName
-fatherName
-email
-userName
-password
-userType
-status
User
+registerCourse()
+editCourse()
+deleteCourse()
-courseNo
-courseTitle
-creditHour
-semesterOffered
-yearLevel
Course
+evaluateInstructor()
+promote()
-yearLevel
Student
+evaluateColleague()
+viewResult()
-title
-academicRank
Instructor
+evaluateSubordinate()
+viewReport()
Supervisor
+registerDepartment()
+editDepartment()
+deleteDepartment()
-departmentId
-departmentName
-faculty
-location
Department
+displayResult()
-value
-year
-semester
Evaluation
+registerCriterion()
+editCriterion()
+deleteCriterion()
-criterionNo
-criterionText
-evaluationType
EvaluationCriterion
-makes
1
-is made for
1..*
1..* 1
has
1
1..*
makes
1
1..*
involves
1..*
1 makes
1..*
1..*
takes
0..*
1..*
instructs
1..*
1
belongs to
1..*
1 offered in
1..*
1
belongs to
56

Objects and Classes
Objects are entities with state and a defined set of
operations on that state.
 State is represented as a set of object attributes.
 Operations provide services to other objects when requested.
Object classes are templates for objects.
 An object class definition includes declarations of all attributes and
operations associated with an object of that class.
 They may inherit attributes and services from other object classes.
57

Employee Class
58
Employee
name: string
address: string
dateOfBirth: Date
employeeNo: integer
socialSecurityNo: string
department: Dept
manager: Employee
salary: integer
status: {current, left, retired}
taxCode: integer
. . .
join ()
leave ()
retire ()
changeDetails ()
Object
attributes
Services
to other
objects

A design strategy based on “information
hiding”…
 Another way to think about “information hiding”:
Potentially changeable design decisions are isolated
(i.e., “hidden”) to minimize the impact of change.
59

Object Diagrams
 UML object diagrams, sometimes referred to as instance
diagrams, are useful for exploring “real-world” examples of
objects and the relationships between them.
 Although UML class diagrams are very good at describing this
information, some people ﬁnd them too abstract—a UML object
diagram can be a good option for explaining complex relationships
between classes.
 Once we have explored the said complex relationships with
object diagrams, we will use whatever we have learned to update
our class models or source code as appropriate and then erase the
object diagram.
 Not really important to be documented.
60

UML Object(Instance Diagram).
61

Interacting Objects
62
state o3
o3:C3
state o4
o4: C4
state o1
o1: C1
state o6
o6: C1
state o5
o5:C5
state o2
o2: C3
ops1() ops3 () ops4 ()
ops3 () ops1 () ops5 ()

63
Example: From the class diagram given below,
you can get several instances of it.
name : String
Author
title : String
rating: Double
Book
wrote
name : String
Publisher
published by

64
name : “Margeret Mitchell”
: Author
title : “Gone With the Wind”
rating: 4.5
: Book
wrote
name : “Hawthorne”
AW: Publisher
published by
Object diagram

65
name : “Tim Burton”
: Author
title : “Burton on Burton”
rating: 4
: Book
wrote
name : “Barnes”
AW: Publisher
published by
Object diagram

6. Design Patterns
There are sets of proven design solutions to
problems, that are considered ‘best practices.’
 Certain ‘groupings’ of classes with specific responsibilities/interfaces.
 These provide specific solutions to specific problems.
 Called Design Patterns
Certain tried-and-true solutions to design
problems have been expressed as principles of best
practice, often in the form of Design Patterns.
A Design Pattern is a problem-solution formula that
applies excellent design principles.
66

Design Patterns Cont’d…
 There are too many design patterns out there that it is hard to discuss them all here.
 But the most common design patterns are categorized under.
 Creational Patterns
 Singleton pattern
 Abstract Factory
 Factory Method
 Builder
 …Etc.
 Structural Patterns
 Facade pattern
 Adapter
 Decorator
 Proxy
 …Etc.
 Behavioral Patterns
 Chain of Responsibility
 Iterator
 Observer
 Visitor
 Template Method
 …Etc.
67

Design Patterns- the Categories
 Creational design patterns
 They abstract the instantiation process.
 They help make a system independent of how its objects are created, composed, and
represented. A class creational pattern uses inheritance to vary the class that's instantiated,
whereas an object creational pattern will delegate instantiation to another object.
 Structural design patterns
 Are concerned with how classes and objects are composed to form larger structures.
Structural class patterns use inheritance to compose interfaces or implementations
 Behavioral patterns
 Are concerned with algorithms and the assignment of responsibilities between
objects.
 Behavioral patterns describe not just patterns of objects or classes but also the
patterns of communication between them.
 They shift the focus away from flow of control to let you concentrate just on the way
objects are interconnected.
68

Creational Design Patterns – the Singleton
pattern
 Singleton
 Discovering classes in your application that should only have one instance is
common.
 Perhaps there should only be one instance of a certain editing screen open at any
given time, perhaps you have conﬁguration information you want to store in one place
only, there should be only one file system and one window manager etc.
 Singleton is a design pattern that shows how to ensure that only one single
instance of a class exists at any one time.
 This pattern provides one of the best ways to create an object.
 Applicability
 Use the Singleton pattern when
 there must be exactly one instance of a class, and it must be accessible to clients
from a well-known access point.
 when the sole instance should be extensible by subclassing, and clients should be able
to use an extended instance without modifying their code.
69

Singleton pattern –example
 Note that a static attribute keeps track of the single instance, and a
class method creates the instance if it does not already exist.
70

Structural Design Patterns- The Facade Design
Pattern
 The purpose of the Facade design pattern is to provide a uniﬁed
interface to a subsystem or component, making it easier to use.
 The solution for the Façade pattern is that objects external to the
subsystem or component send messages to the facade class, which, in
turn, routes them to the appropriate “internal” classes and objects.
 The facade class implements the public interface of the
component and the internal classes implement the behaviors
provided by the component
Facade pattern hides the complexities of the system
and provides an interface to the client, through which
the client can access the system.
71

Facade pattern –the gist of the concept
72

Facade pattern – an example
We are going to create a Shape interface and
concrete classes implementing the Shape interface. A
facade class ShapeMaker is defined as a next step.
73

Behavioral Design Patterns – example –Chain of
Responsibility
Is used to achieve loose coupling in
software design where a request from the client is passed
to a chain of objects to process them.
Pattern creates a chain of receiver objects for a request.
The Chain of Responsibility pattern avoids coupling the
sender of a request to the receiver by giving more than
one object a chance to handle the request.
Multiple handlers could contribute to the handling of each
request.
 The request can be passed down the entire length of the chain, with the
last link being careful not to delegate to a "null next".
74

Chain of Responsibility - Example
75
ATM use the Chain of Responsibility in
money giving mechanism.

Error Logger Example- Chain of
Responsibility
 Each logger checks the level of message to its level and
print accordingly otherwise does not print and pass the
message to its next logger.
76

Check List for Chain of Responsibility pattern
 The following steps are common in chain of responsibility.
 The base class maintains a "next" pointer.
 Each derived class implements its contribution for handling the
request.
 If the request needs to be "passed on", then the derived class "calls
back" to the base class, which delegates to the "next" pointer.
 The client (or some third party) creates and links the chain
(which may include a link from the last node to the root node).
 Programs such as void main () we have seen earlier
 The client "launches and leaves" each request with the root of the
chain.
 Recursive delegation produces the illusion of magic.
77

Tips for Applying Patterns Effectively
 To apply patterns successfully;
 Read widely: hundreds, if not thousands, of design patterns have
been published.
 Understand the patterns: Most patterns describe both when and
when not to apply them, important information you need to
understand to use them successfully.
 Patterns are not the solution to everything
 Remember several types of patterns exist(Analysis, Design and
Process)
78

7. State chart(State machine) Modeling
 Objects have both behavior and state or, in other words, they do things and
they know things
 Some Objects have so complex states that it I hard to understand those
states and the transitions easily.
 UML state machine diagrams depict the various states that an object may be
in and the transitions between those states.
 In fact, in other modeling languages, it is common for this type of a diagram to
be called a state-transition diagram or even simply a state diagram
 A state represents a stage in the behavior pattern of an object, and like UML
activity diagrams it is possible to have initial states and final states.
 An initial state, also called a creation state, is the one that an object is in
when it is first created, whereas a final state is one in which no transitions
lead out of.
79

State chart(State machine) Modeling cont’d…
 A transition is a progression from one state to another and will
be triggered by an event that is either internal or external to
the object.
 The label on the transition can be event [guard] [/method list]
 Guard( specifies a condition) and methods( specifies actions to do) are optional
 The rounded rectangles represent states: for instance, a
seminar can be in different types of instances such as the
Proposed, Scheduled, Open For Enrollment, Full, and Closed to
Enrollment states.
 An object starts in an initial state, represented by the closed
circle, and can end up in a ﬁnal state, represented by the
bordered circle.
 The final state means that the object has actually been
destroyed and can no longer be accessed.
80

State machine diagram for the Seminar class during
registration.
81

8. Collaboration (Communication) Diagrams
 A fundamental concept of the UML is that you use different diagrams for
different purposes.
 Class diagrams are used to model the static nature of your system, sequence
diagrams are used to model sequential logic, and state machine diagrams are
used to model the behavior of complex classes.
 But what happens when you need to show the behavior of several objects
collaborating together to fulﬁll a common purpose?
 A UML diagram that shows instances of classes, their interrelationships, and the
message ﬂow between them.
 Communication diagrams typically focus on the structural organization of objects
that send and receive messages and
 These diagrams are used to get a “bird’s-eye view” of those collaborating objects.
82

Collaboration (Communication) Diagram
 The same notation for classes and objects used on UML sequence
diagrams are used on UML communication diagrams, another
example of the consistency of the UML.
 Messages are depicted as a labeled arrow that indicates the direction
of the message, using a notation similar to that used on sequence
diagrams.
 Optionally, you may indicate the sequence number in which the
message is sent, indicate an optional return value, or indicate the
method name and the parameters (if any) passed to it.
 Sequence numbers should be in the format A.B.C.D to indicate the
order in which the messages where sent.
83

Collaboration(Communication) Diagrams for
Displaying a seminar details
84

9. Component Modeling
Component Diagram
 Is another static model
 Particularly useful for large-sized development teams
 Is essentially a class diagram focusing on the system’s components
 It enables you to model the high-level software components, and
more importantly the interfaces to those components. Once the
interfaces are deﬁned and agreed to by your team, it is much easier
to organize the development effort between sub-teams.
85

Component Modeling Cont’d…
UML Component Diagrams are
 Used to represent the different high-level reusable parts of a
system.
 In addition to representing the high-level parts, the Component
diagram also captures the inter-relationships between these parts.
 The primary difference with other UML diagrams is that Component
diagrams represent the implementation perspective of a system.
 Hence, components in a Component diagram reflect grouping of the
different design elements of a system, for example, classes of the system.
86

Component Modelling Cont’d…
 Component modeling emphasizes the separation of
concerns with respect to the wide-ranging functionality
available throughout a given software system.
 An individual component is a software wrap up or a unit that
encapsulates a set of related functions (or data).
 All system processes are placed into separate components
so that all of the data and functions inside each component
are semantically related (just as with the contents of classes-
encapsulation).
 Because of this principle, it is often said that components are
modular and cohesive.
 Thus, the goal of component model is to distribute the classes
of a system into large scale cohesive components.
87

 Component diagrams as an architecture-level artifact, either
to model the business software architecture or the technical
software architecture.
 A component diagram in the UML depicts how components
are glued (attached) together to form larger components
and or software systems.
 A component diagram will also help to describe the
organization of the physical components in a system.
 UML component diagrams enable the development team to
model the high-level software components, and the
interfaces to those components.
 A component needs to be attached with user interface classes
to application components.
88

Component vs Class
89
 Similarities
 1) both may realize a set of
interfaces
 2) both may participate in
dependencies,
generalizations and
associations
 3) both may be nested
 4) both may have instances
 5) both may participate in
an interaction
 Differences
 1) classes represent logical abstraction
while components represent physical
things ( 4+ 1 view ?)
 2) components represent the physical
packaging of logical components and are
at a different level of abstraction
 3) classes may have attributes and
operations whereas components only
have operations reachable only through
their interfaces

90

 An interface is a collection of operations that are used to
specify a service of class or components. ( contracts)
 Interfaces:
 1) Represent the major joint of the system
 2) Are realized by components in implementation
 3) Promotes the deployment of systems whose services are location independent
and replaceable
 Types of Components
 1)Deployment Component:
 Component necessary and sufficient to form an executable system, such as
DDLs and EXEs
 2) Work product component:
 Rest of development process consisting of things like source code files and data
files from which deployment components are created
 3) Execution component:
 Created as a consequence of an executing system
91

Component Standard Stereotypes
«Entity» =A persistent information component
representing a business concept.
«Subsystem» : Subsystem is a component
representing unit of hierarchical decomposition for
large systems, and is used to model large scale
components
«Service» : Service is a stateless, functional
component.
92

Componentizing a System
One option to componentize your system
 Non-business/domain class – two different types of components.
 Assign a stereotype “application” by categorizing related UI classes
 Assign a stereotype “infrastructure” for persistence and security system
components
 Domain components
 Identify domain components which is a set of classes that collaborate among
themselves to support cohesiveness
93

Componentizing a System –The University Seminar
Management System –UML 2.x diagram
94

Componentizing a System -Example
95
UML Interface
UML Component
Scheduler
Planner
GUI
reservations
update

Component Dependency
96

Component Diagram for a Satellite System
97

10. Deployment Modeling
 Captures the configuration of the runtime elements of the
application.
 More useful when a system is built and ready to be deployed.
 Should start from the time your static design is being formalized
using class diagrams.
 This deployment diagram then evolves and is revised until the
system is built.
 To determine whether you need to create a deployment
model, ask yourself this: if you knew nothing about the
system and someone asked you to install it and/or maintain
and support it, would you want a description of how the
parts of the system ﬁt together?????
98

Component vs Deployment Diagrams
Essentially, the components in a component
diagram are contained in the deployment diagram
elements(Nodes), though indirectly.
Hence, while components provide the application
functionality, the deployment diagram elements
provide the necessary environment for the
components to execute in.
99

UML Deployment Diagram
Shows the physical relationships among software and
hardware components in the delivered system.
Is a good place to show how components and objects
are routed and move around in a distributed system.
Each node on a deployment diagram represents
some kind of computational unit—in most cases, a
piece of hardware.
The hardware may be a simple device or sensor, or it
could be a mainframe (Processor).
100

UML Deployment Diagram
UML Deployment Diagram shows the execution
architecture of systems that represent the assignment
(deployment) of software artifacts to deployment
targets (usually nodes).
Note, that components were directly deployed to
nodes in UML 1.x deployment diagrams.
 In UML 2.x artifacts are deployed to nodes, and artifacts could manifest
(implement) components.
 So components are now deployed to nodes indirectly through artifacts.
 Manifestation is an abstraction relationship that represents concrete
physical rendering (implementation) of one or more model elements by an
artifact or utilization of the model elements in the construction or
generation of the artifact
 An artifact could manifest one or more model elements(components)
101

Deployment Diagrams Cont’d… Manifestation
 A manifestation is notated in the
same way as abstraction, i.e. as a
dashed line with an open
arrowhead directed from artifact
to packageable element, (e.g. to
component or package) and is
labeled with the keyword
«manifest».
 E.g. EJB component UserService
and skeleton of web services
are manifested (implemented) by
EJB module user-service.jar
artifact.
102

Deployment Diagrams Cont’d…
 Artifacts are deployed to deployment targets.
 Deployment target is the location for a deployed artifact.
 Node is a deployment target which represents computational
resource upon which artifacts may be deployed for execution.
 Nodes can be interconnected with communication paths.
 Communication paths can be defined between nodes such as application server and
database server to define the possible communication paths between the nodes.
 Specific network topologies can then be defined through links between node
instances.
 Node is specialized by( i.e. a node can be ):
 device
 execution environment
103

 A device is a node which
represents a physical
computational resource with
processing capability upon which
artifacts may be deployed for
execution.
 A device is rendered as a node (perspective, 3-
dimensional view of a cube) annotated with keyword
«device».
 Execution environment is usually
part of a general node or «device»
(which represents the physical
hardware environment on which this
execution environment resides.)
 Execution environments can be nested (e.g., a database
execution environment may be nested in an operating
104

UML provides no standard stereotypes for devices.
Examples of non-normative stereotypes for devices are:
 «application server»
 «client workstation»
 «mobile device»
 «embedded device»
An execution environment is a (software) node that offers
an execution environment for specific types of
components that are deployed on it in the form of
executable artifacts.
Components of the appropriate type are deployed to
specific execution environments.
105

Deployment Diagrams Cont’d… deployment
targets
The stereotype «executionenvironment» is a lengthy
word to use. UML provides no other standard
stereotypes for execution environments. Examples of
reasonable non-normative stereotypes are:
 «OS»
 «workflow engine»
 «database system»
 «J2EE container»
 «web server»
 «web browser»
106

Deployment Diagrams Could be shown textually or
via the <<deploys>> dependency
 Deployment could be shown using textual
list of deployed artifacts within a
deployment target.
 The portfolio.ear, stocks.ear, weather.ear
artifacts deployed in J2EE 1.4 container.
 Good if you have a complex
deployment diagram
 Deployment could be also defined at
instance level - as allocation of specific
artifact instance to the specific instance of
a deployment target.
 Note also how deployment can be
indicated with the <<deploy>>
dependency.
 Dependency is shown by an arrow drawn from the artifact (supplier)
to the deployment target (client) and is labeled with «deploy».
 Note, that dependency usually points from the client to the supplier
107

Deployment Diagrams Cont’d… Communication
path
108
 When deployment targets
are execution environments,
communication path will
typically represent some
protocol.
 When deployment targets are
some physical devices,
communication path will
typically represent a
physical connection
between the nodes.
 Notice also the multiplicity.

UML Deployment Diagrams Cont’d….
Benefits
Deployment Diagrams help us to;
1)Show the configuration of run-time processing nodes
and the components that execute on them.
2) Model the distribution, delivery, and installation of
the parts that make up the physical system
3) Involve modeling the topology of the hardware on
which the system executes
4) Essentially focus on a system’s nodes, and include:
 a) Nodes
 b) Dependencies and associations relationships
 c) Components
 d) Packages(artifacts can manifest any packageable model elements)
109

Component Vs Node
110
 Components
 1)Participate in the
execution of a system.
 2)Represent the physical
packaging of otherwise
logical elements
 Nodes
 1) Execute components
 2)Represent the physical
deployment of components
Note: The relationship <<deploys>> between a node and
a component can be shown using a dependency
relationship.

UML Deployment Diagram – How?
Identify scope of the model (a part or a whole)
Identify the distribution architecture
(architectural style)
 Layered ( such as MVC) , Client/Server (2 or 3 tier),
Repository etc.
Distribute components to nodes
 In case of three tier Client/Server architecture for
example
 Application components (UI) to client machine
 Domain components to the application server
 Persistent components to the database server
111

Deployment an Example of the University System – complex
one
112

Deployment an Example of the University System – simpler(concise) one
read what the components are from Ambler 2004.
113

UML Package Diagrams
Use packages—to organize a large diagram into
several smaller ones. A good rule of thumb is that a
diagram should have 7 ± 2 bubbles on it, a bubble
being a use case or class.
 When a diagram has more bubbles than this, it starts to become
unwieldy and therefore difﬁcult to understand
 Packages should be cohesive. Anything you put into the package
should make sense when considered with the rest of the contents of
the package
114

Package Diagrams -Examples
115

11. Relational Persistence Modeling
Persistent data modeling is conceptually similar to
design class modeling in terms of content.
There are minor things to remove and add in
persistent modeling due to the nature of the DBMS to
be used for data management.
The model describes the internal schema of a
database, depicting the data tables, the data
columns of those tables, the unique nature of
some functional columns (attributes) and the
relationships between the tables.
116

Relational Persistence Modeling Cont’d…
Even though the design so far is object oriented, the data
management part is relational and needs the object
oriented class diagram to be converted to a persistent
diagram.
Mapping objects to tables
 A good start in developing a persistent diagram is to do a one-to-one
mapping of the classes in the system into data tables and attributes to
columns.
 In persistent diagram, while uniqueness of each object is maintained using
primary keys relationships are implemented via the use of foreign keys.
 The limitation with Relational data model is that it does not support many
to many relationships to be modeled as it is.
 For this reason any tables with many to many associations need to be
bridged via the addition of an associative table.
117

Relational databases do not support inheritance and
designers will be forced to map inheritance
structures within object schema to data schema.
There are three possible solutions for mapping
inheritance into a relational database:
 Map the entire class hierarchy to a single table.
 Map each concrete class to its own table.
 Map each class to its own table.
Rules of Mapping class hierarchy to
database tables holds here.
118

119

Persistence Data Model for the part of the
University System that we have seen
120

12. Evolving User Interface Design
 The User Interface Design at this stage should be the real feel
and look of the system - A working, high fidelity user interface.
 The user interface design at the system design level should be
based on the programming language sought to be used
during implementation.
 After evaluating the UI prototype you have developed at
analysis, you may ﬁnd you need to scrap parts of it, modify
parts, and even add brand-new parts.
 You want to stop the UI prototyping process when you ﬁnd
the evaluation process is no longer generating any new
ideas or it is generating a small number of not-so-important
ideas.
 Otherwise, return to exploring your stakeholder’s UI needs
121

UI Design Strategies
 Poor user interface design is the reason why so
many software systems are never used.
 A poorly designed interface can cause a user to make catastrophic
errors.
 Constantine and Lockwood (1999) describe a collection of
principles for improving the quality of your UI design.
 These principles are
 The purposeful UI structure principle.
 The simplicity principle
 The visibility principle
 The feedback principle -
 The tolerance(robustness) principle
 The reuse principle (reuse internal and external components and
behaviors in effect reducing the need for users to rethink and remember
the meaning of an element)
122

The UI Design Tips
 In addition to the strategies, the following are important tips
 Consistency, consistency, consistency
 Set standards and stick to them
 Be prepared to hold the line( Listen to the stakeholders but remember your
standards)
 Explain the rules, to your users once, of how the system works
 If an application works consistently
 Navigation between major user-interface items is important.
 Navigation within a screen is important
 Word your messages and labels appropriately
 Understand the UI widgets
 Look at other applications that have used the same UI Widgets
 Use color appropriately
 Follow the contrast rule
 Align ﬁelds effectively
 Expect your users to make mistakes
 Your design should be intuitable.
 Group things effectively
123

User Experience (UX) Design
 UX Design refers to the term User Experience Design, while
UI Design stands for User Interface Design.
 Both elements are crucial to a product and work closely
together.
 A great product experience starts with UX followed by UI.
Both are essential for the product’s success.
 User experience design (UXD or UED) is the process of
enhancing customer satisfaction and loyalty by improving
the usability, ease of use, and pleasure provided in the
interaction between the customer and the product.
 User Interface Design is the look and feel, the presentation
and interactivity of a product.
124

UX Focus
 While UI focus on the technical arrangement of basic
interaction elements such as menus, lists, images etc., UX
focus on the conceptual ease, satisfaction and usability of the
product to the user.
 UX Design needs to take into account:
 Who the users are
 Experience
 What activities are being carried out for what purpose
 Task and goals
 Where the interaction is taking place
 Context
 Need to optimize the interactions users have with a product
 So that they match the users’ activities and needs
 Usability / Habitability are main concerns.
125

User Experience (UX) Design Cont’d…
UI vs UX?
 Something that looks great but is difficult to use has great UI but
poor UX.
 Something that is easy to use and interact with but looks terrible has
great UX but poor UI.
 Great UX + Great UI=?
A UX design is concerned with the conceptual
aspects of the design process, leaving the UI
design to focus on the more tangible (technical)
elements.
126

UI Vs UX?
Which control is for which stove
ring Is this a better design ?
127
We have the same UI in both of the above but not the same UX

User Experience (UX) Design Cont’d…
Developing usable products ( involves UX)
 Usability means easy to learn, effective to use and provide an
enjoyable experience.
 Requires involving users in the design process
 A number of other terms used emphasizing what is being designed,
 user interface design, software design, user-centered design,
product design, web design, experience design, user
experience(UX)
 Interaction design is sometimes used as the umbrella term
covering all of these aspects
 Fundamental to all disciplines, fields, and approaches concerned
with researching and designing computer-based systems for
people
128

HCI and Interaction
129

Interaction styles
Direct manipulation
Menu selection
Form fill-in
Command language
Natural language
130

What is involved in the interaction design
Identifying needs and establishing requirements for
the user experience
Developing alternative designs to meet these
Building interactive prototypes that can be
communicated and assessed
Evaluating what is being built throughout the
process and the user experience it offers
131

Goals of Interaction Design
 Visibility -
 how easily a user can see what can be done and how to do it
• make relevant parts visible
• make what has to be done obvious (intuitive )
 Mappings -
 How a control and object are related
 Relationship between controls and their movements and the results in
the world
 Suffers when more functions than controls
 i.e. The number of controls and functions must match
132

Goals of Interaction Design Cont’d…
 Feedback –
 shows what has been done
 Sending information back to the user about what has been done
 Includes sound, highlighting, animation and combinations of these
 Suffers when delayed or not meaningful
 Cues and affordances - (‘perceived’ affordances of
Interfaces)
 learned expectations about visual forms
 Refers to an attribute of an object that allows people to know how to use it
 What do you know when you see the dust bean
 E.g. scrollbars to afford moving up and down, icons to afford to click-on
etc.
133

End of Chapter 5
134

OOSAD Chapter 6 Object Oriented Design.pptx

Recommended

Recommended

More Related Content

Similar to OOSAD Chapter 6 Object Oriented Design.pptx

Similar to OOSAD Chapter 6 Object Oriented Design.pptx (20)

Recently uploaded

Recently uploaded (20)

OOSAD Chapter 6 Object Oriented Design.pptx