Chapter Seven
Object Oriented Design
Contents
Layering your models :Class Type Architecture
Class Modeling
Applying Design Patterns effectively
State chart modeling
Collaboration Modeling
Relational Persistence Modeling
Component and Deployment Modeling
User Interface Design
2
Determining How to Build Your System: OO Design
After the analysis phase, the conceptual model is developed further into an
object-oriented model using object-oriented design (OOD).
The OOD process takes the conceptual systems model, use cases, system
relational model, user interface (UI) and other analysis data as input from the
OOA phase.
This is used in OOD to identify, define and design systems classes and objects, as
well as their relationship, interface and implementation.
Purpose of design is to determine how you are going to build your system.
Analysis and design are highly interrelated and iterative.
Your analysis class model evolves into your design class model
3
Layering your models
Organizing your software design into collections of classes or components that
fulfill a common purpose
Qualities of a good layer
You should be able to make modifications to any given layer without affecting
any other layers
Layers should be modularized
Rewriting layer or replacing
Collaboration between classes is allowed within a layer
By restricting the flow of messages to only one direction, you dramatically
increase the portability of your system by reducing the coupling between class
All types of classes may interact with system classes
Fundamental software features such as inter-process communication
4
Layering your models
User Interface Classes
Controller/
Process
Classes System
Classes
Business/Domain Classes
Persistence Classes
Persistent
Store
5
Layers
User Interface classes: implements the major UI element of your system
Business/domain classes: This class represents the core business logic and
processes. It models the system's real-world entities and handles business
rules.
Controller/ process classes: Manages the flow of control between the User
Interface Layer and the Business Domain Layer.
Persistence Classes: encapsulate the capability to store, retrieve and delete
object permanently without revealing details of the underlying storage
technology
System Classes: provide operating system specific functionality for your
applications, isolating your software from the operating system
6
User Interface Layer
Purpose: Handles interactions between the user and the system.
Responsibilities:
Displays information to users (e.g., forms, dashboards, reports).
Captures input from users (e.g., filling forms, clicking buttons).
Ensures usability, accessibility, and a seamless user experience.
Examples:
Front-end frameworks and technologies like HTML, CSS, JavaScript, Angular,
React.
Mobile app interfaces.
Desktop application GUIs.
7
Controller/Process Layer (or Application Layer)
Purpose: Manages the flow of control between the User Interface Layer and the
Business Domain Layer.
Responsibilities:
Processes user inputs and decides the next steps.
Acts as a mediator, interpreting user actions and calling appropriate business
logic.
Validates input data and manages user sessions.
Examples: Request handling components in web applications.
8
Business Domain Layer
Purpose: Contains the core logic and rules of the application.
Responsibilities:
Encapsulates the business rules and algorithms.
Defines entities, services, and operations that solve the business problem.
Ensures the integrity of the business processes.
Examples: For the shopping website, the domain/business class might include:
Product: Represents a product with attributes like name, price, and stock.
Order: Manages order details and processes payments.
9
Persistence Layer
Purpose: Manages data storage and retrieval.
Responsibilities:
Interacts with databases or other storage systems.
Implements Create, Read, Update, Delete (CRUD) operations.
Ensures data consistency and integrity.
Examples: For the shopping website, the persistence class might include:
DatabaseHandler: Saves and retrieves user data, product information,
and orders.
FileStorage: Handles file-based storage of user preferences.
10
System Layer
Purpose: Provides low-level system and technical support.
Responsibilities:
Handles infrastructure concerns like networking, and security.
Provides APIs for interaction with external systems.
Manages hardware and software resources.
Examples:
Operating system interactions.
Middleware
File storage, third-party APIs.
11
How They Work Together
User Interaction: The user interacts with the User Interface Layer.
Request Processing: The Controller/Process Layer interprets the request and
invokes the Business Domain Layer.
Business Logic Execution: The Business Domain Layer performs the core
logic and interacts with the Persistence Layer to fetch or store data.
Infrastructure Support: The System Layer ensures all underlying infrastructure
services are available and operational.
Response to User: The result is passed back through the layers
12
Class Modeling: UML Class Diagrams
The purpose of design is to model how the software will be built.
The purpose of design class modeling is to model the static structure of how your software
will be built.
Class modeling focus on the solution domain not on the problem domain.
Your analysis class model often evolves into your design class model—you simply
introduce changes to your class model based on implementation technologies.
When moving from an analysis class modeling mindset to a design mindset perhaps you
will do the following:
Implement business rules using business rules engine – your business class will invoke
the rule, instead of directly implementing them in methods.
Apply design patterns to improve the design quality of your models;
Decide to take advantage of features of your database.
13
Modeling Methods during Design
Methods, also called operations or member functions, are the object-oriented
equivalent of functions and procedures.
With the unified modeling language (UML), however, it is possible to model far
more information about a method's signature.
During design, you should consider indicating these items:
visibility name(param1:type1=default1, ...): returnType
<<stereotype>>
Con’d
Visibility (optional): This is the level of access that external objects have to a
method, on your class diagrams.
Name: Strategies for naming methods.
Parameters (optional): The names of parameters, and optionally their types and
default values (if any),
Return value type (optional): The type of the return value, if any, should be
indicated.
Stereotype(s) (optional): Any applicable stereotypes should be indicated.
Scope: Whether a method is a static method that works on the class or an
instance method that works on instances of the class should also be indicated.
Static methods are underlined; instance methods are not.
15
Con’d
16
Naming Methods During Design
In most C-based languages, such as Java and C#, it is common to name methods with a
full description, using mixed case with the first letter of any non initial word capitalized in
the format methodName().
Also common practice is for the first word of a member function name to be a strong,
active verb.
17
Method Visibility
How a method is accessed by objects is defined by its visibility. In the UML, you have
your choice of four levels of visibility: public, protected, private, and package.
To reduce the coupling within your system, the general rule of thumb is to be as
restrictive as possible when setting the visibility of a method.
In other words, if a method does not have to be public, then make it protected. If it
does not have to be protected, then make it private.
18
Con’d
19
Modeling Attributes During Design
Attributes are the data aspects of objects. During design you should indicate these items:
Visibility (optional): This is the level of access external objects have to an attribute, on
your class diagrams.
Name.
Type (optional): The type of an attribute may be a primitive type, such as string or int, or
a class such as Address.
Initial value (optional): The initial value (if any) for an attribute should also be indicated.
Repeats (optional): If the attribute repeats, it should be indicated with the "[*]" notation.
Scope: Static attributes, those with class scope, are underlined. Instance attributes are not
underlined.
20
Modeling Attributes During Design
The Student and StudentNumber classes with their attributes fully modeled. In the static attribute,
nextStudentNumber, you know it is static because it is underlined.
In the StudentNumber, class is an incremental value.
Each time an instance of StudentNumber is created, this static attribute is incremented by one, and
then its value is assigned to the object (the instance). The instance attribute averageMark of the
Student class is interesting because its type is long, one of Java's primitive types,
which is consistent to the parameter passed to the corresponding setter, as well as the return value
of the getter.
21
Inheritance Techniques
Similarities often exist between different classes. Quite often, two or more classes share the
same attributes and/or the same methods. Because you do not want to have to write the same
code repeatedly, you want a mechanism that takes advantage of these similarities. Inheritance is
that mechanism.
Inheritance models "is a" and "is like" relationships, enabling you to reuse existing data and
code easily.
The following techniques to be valuable for ensuring that I apply inheritance
Any kind of class can inherit from any other kind
You should be able to substitute an instance of a subclass or an instance of a super class
Beware of multiple inheritance
Beware of inheritance based on common data attributes
Super classes should know nothing of their subclasses
Factor commonality as high as possible in 22your class hierarchy
A subclass should inherit everything.
Association and Dependency Techniques
In the real world, objects have associations to other objects. The associations
between objects are important because they help us to define how they
interact with each other. For example, students take courses and professors
teach courses.
Associations between objects enable collaboration—an object needs to know
about another object to work with it.
When a persistent association does not exist between two objects, but they
need to collaborate with one another, you model a dependency relationship
between the two classes.
23
Association and Dependency Techniques
Multiplicity must be shown. The multiplicities of an association should be modeled.
Associations and dependencies are inherited. Because associations and dependencies are
implemented as a combination of attributes and methods, and because attributes and methods are
inherited, by implication, associations are also inherited.
Collaboration goes hand in hand with relationships
Model a unidirectional association when collaboration
Model a dependency when one of the instances is transient
Model a dependency when an object interacts only with a class, but not the instance
24
Aggregation and Composition
Sometimes an object is made up of other objects. For example, an airplane is
made up of a fuselage, wings, engines, landing gear, flaps, and so on.
During design, several considerations are specific to composition:
The advice for association applies to aggregation and composition.
The sentence rule should make sense for aggregation and composition
You should be interested in both the whole and the part.
You need to understand how the whole and the parts collaborate with each
other.
The majority of the interaction is from the whole to the part
Don’t confuse inheritance with aggregation
25
Aggregation and Composition
26
Applying Design Patterns effectively
Reusable solutions for typical software design challenges are known as design
patterns.
Expert object-oriented software engineers use these best practices to write
more structured, manageable, and scalable code.
Design patterns provide a standard terminology and are specific to particular
scenarios and problems.
Design patterns are not finished code but templates or blueprints only.
27
Key Characteristics of Design Patterns
Reusability: Patterns can be applied to different projects and problems, saving
time and effort in solving similar issues.
Standardization: They provide a shared language and understanding among
developers, helping in communication and collaboration.
Efficiency: By using these popular patterns, developers can avoid finding the
solution to same recurring problems, which leads to faster development.
Flexibility: Patterns are abstract solutions/templates that can be adapted to fit
various scenarios and requirements.
28
Tips for Applying Patterns Effectively
The following tips can help you to apply patterns successfully in your work:
[Link] widely. Although patterns became popular in the early to mid-1990s within the
object community, they have quickly gained prominence and significant work has been
accomplished in a few short years. The end result is hundreds, if not thousands, of
design patterns have been published.
[Link] the patterns. Simply reading about patterns is not enough; you also need
to understand them. Most patterns describe both when and when not to apply them,
important information you need to understand to use them successfully.
[Link] are not the solution to everything. Many patterns are out there at your
disposal, but not every design problem can be solved via the application of one or more
patterns. The secret is to have a good grasp of what patterns exist and to look them up
when you think you have a situation where they can be applied.
[Link] several types of patterns exist. As you have seen throughout this course,
analysis patterns, design patterns, and process patterns exist, to name a few.
29
State chart modeling
UML state machine diagram and activity diagram are both behavioral diagrams
but have different emphases.
Activity diagram is the flow of functions without trigger (event) mechanism,
state machine is consist of triggered states.
State chart diagram describes the flow of control from one state to another state.
Represent states of an object in a class.
A state chart diagram is a pictorial representation of such a system, with all it's
states, and different events that lead transition from one state to another.
A state is any "distinct" stage that an object (system) passes through in it's
lifetime. An object remains in a given state for finite time until "something"
happens, which makes it to move to another state
30
Con’d
To illustrate this, consider a computer. Some possible states that it could have
are: running, shutdown, hibernate. A transition from running state to
shutdown state occur when user presses the "Power off" switch, or clicks on the
"Shut down" button as displayed by the OS. Here, clicking on the shutdown
button, or pressing the power off switch act as external events causing the
transition.
State – represent stage in the behavioral pattern of an object. and like UML
activity diagrams it is possible to have initial states and final states.
Initial – a Creation state, is the one that an object is in when it is first
created
Transition – Progression from one state to another and will be triggered
by an event that is either internal or external to the object.
whereas a Final State is one in which no transitions lead out of
31
How to draw state diagrams
Specifically a state diagram describes the behavior of a single object in
response to a series of events in a system.
Identity the initial/creation state
Identify the final states
Identify as many other application, “Real world” states as possible
Identify potential sub states
Identify the transition leaving a state
Identify the target state to which a transition leads.
Note: Activity diagrams are graphical representations of workflows of stepwise
activities and actions with support for choice, iteration and concurrency. Flow
control form activity to activity. State chart shows the state machine consisting
of state, transition, event and activities 32
Con’d
States: States represent situations during the life of an object. You can easily
illustrate a state in SmartDraw by using a rectangle with rounded corners.
Transition: A solid arrow represents the path between different states of an object.
Label the transition with the event that triggered it and the action that results from
it. A state can have a transition that points back to itself.
33
Con’d
Initial State: A filled circle followed by an arrow represents the object's
initial state.
Final State: An arrow pointing to a filled circle nested inside another circle
represents the object's final state
34
Con’d
Synchronization and Splitting of Control
A short heavy bar with two transitions entering it represents a synchronization of control. The first
bar is often called a fork where a single transition splits into concurrent multiple transitions. The
second bar is called a join, where the concurrent transitions reduce back to one.
35
Example 1
The arrows in Fig. represent transitions, progressions from one state to another
Presents an example state machine diagram for the Seminar class during
registration. The rounded rectangles represent states: you see that instances of
Seminar can be in the Proposed, Scheduled, Open For Enrollment, Full, and
Closed to Enrollment states.
36
Example 2
37
Difference between Activity and State chart diagram
Both activity and state chart diagrams model the dynamic behavior of the
system. Activity diagram is essentially a flowchart showing flow of control from
activity to activity. A state chart diagram shows a state machine emphasizing the
flow of control from state to state.
An activity diagram is a special case of a state chart diagram in which all or
most of the states are activity states and all or most of the transitions are
triggered by completion of activities in the source state (An activity is an
ongoing non-atomic execution within a state machine).
Activity diagrams may stand alone to visualize, specify, and document the
dynamics of a society of objects or they may be used to model the flow of
control of an operation. State chart diagrams may be attached to classes, use
cases, or entire systems in order to visualize, specify, and document the
dynamics of an individual object.
38
Collaboration Diagrams
Collaboration diagrams are interaction diagrams that illustrate the structure of the
objects that send and receive messages.
It shows the message stream between objects in an OO application, additionally
suggests the fundamental affiliations (connections) between classes.
The main differences between sequence and collaboration diagrams is ,sequence
diagrams show time-based object interaction. But, collaboration diagrams show how
objects associate with each other. It shows objects, their links, and their messages.
Collaboration diagram has three elements,
Object: The interaction between objects takes put in a system.
Relation/Association: Association among objects.
Messages: An arrow that starting from one object to the destination object.
39
Con’d
The information in a collaboration diagram is similar to that in a
sequence diagram, but a sequence diagram is organized in
chronological sequence, and a collaboration diagram is not.
In the collaboration diagram the time element is removed.
The emphasis is on how objects collaborate with each other instead of
on their sequence.
Lines – represent the relationships (associations, aggregation,
composition, dependencies)
Optionally you may indicate the sequence number in which the
message
40
A collaboration diagram for a login
1.1:Request for Login 4. Validate
Home page Login
<<UI>> Controller
Store
Manager
and store
Keeper
Database
Login
<<UI>>
41 41
Persistent Database Diagram
A persistent database model stores persistent data in the form of objects, or
records that are durable when changing devices and software.
The most popular example of a database model is the relational model,
which uses a table-based format. It doesn’t use objects and their
relationships.
Objects have necessary features (like encapsulation, inheritance, persistence,
and polymorphism) that do not translate well into records and tables.
Thus, certain special databases like object-oriented database management
systems (OODBMS) to preserve persistency of objects.
Before we design RDBMS, we have to perform ERD(Entity relationship
diagram) and Normalization operation.
42
Keys and object identifiers
• A key uniquely identifies a row in a table
• Primary key – preferred key for a data entity
• Secondary key – alternate way to access rows within a
table
• Foreign key – used to maintain relationships between
rows
• Use stereotypes - <<primary key>>, <<foreign key>>
• Object Identifiers(OIDs) enable you to simplify your key
strategy within a RDB
• Enables you to automate the maintenance of
relationships between objects.
• OID should be unique within a class hierarchy
43
Mapping Objects to RDBs
• Mapping Attributes to Columns
– Attributes map to zero or more columns; zero or more
attributes map to a single column
• Mapping Classes to tables
– Not often direct
– Classes map to one or more tables; one or more classes
can map to a single table
• Implementing Inheritance in a Relational Database
– 3 basic choices when mapping inheritance
• Use one data entity for an entire class hierarchy
• Use one data entity per concrete class
• Use one data entity per class
44
Example
45
Component Diagrams
Component diagrams are different in terms of nature and behavior. Component
diagrams are used to model the physical aspects of a system.
Now the question is, what are these physical aspects? Physical aspects are the
elements such as executables, libraries, database file, files, documents, etc.
which reside in a node.
Component diagrams are used to visualize the organization and relationships
among components in a system.
Describes the organization and wiring of the physical components in a system.
In component diagram, nodes indicate components and edges indicate the
relationships.
Example: component A “uses services of” component B. Uses services of is
a relationship type.
46
Purpose of Component Diagrams
It does not describe the functionality of the system but it describes the
components used to make those functionalities.
A single component diagram cannot represent the entire system but a
collection of diagrams is used to represent the whole.
The purpose of the component diagram can be summarized as −
Visualize the components of a system.
Construct executables by using forward and reverse engineering.
Describe the organization and relationships of the components.
47
Notation of Component Diagrams
Component:- A component is a logical unit block of the system, a
slightly higher abstraction than classes.
Interface: An interface (small circle or semi-circle on a stick) describes a
group of operations used (required) or created (provided) by components.
48
Con’d
A full circle represents an interface created or provided by the component. A
semi-circle represent an interface that the component requires e.g.: someone’s
input. This shows that one component is providing the service that the other is
requiring.
A provided interface of a component is an interface that the component realizes.
Other components and classes interact with a component through its provided
interfaces .
A required interface of a component is an interface that the component needs to
function. More precisely, the component needs another class or component that
realizes that interface to function.
49
Con’d
Port: Ports are represented using a square along the edge of the system or a
component. A port is often used to help expose required and provided interfaces of
a component.
A Port is an interaction point between a classifier and an external environment. It
groups semantically cohesive set of provided and required interfaces.
A port can be used in UML without specifying the name of the port.
50
Example
Faciliities
Seminar Security
Management <<infrastructure>>
<<application
>> Student
Persistence
<<infrastructure>>
Seminar
Student
Administration
<<application>>
51
University DB
Schedule <<infrastructure>>
Deployment Diagrams
Deployment diagrams are used to visualize the hardware processors/ nodes/
devices of a system, the links of communication between them and the
placement of software files on that hardware.
Deployment diagrams are used for describing the hardware components where
software components are deployed.
Component diagrams are used to describe the components and deployment
diagrams shows how they are deployed in hardware.
The purpose of deployment diagrams can be described as:
Visualize hardware topology of a system.
Describe the hardware components used to deploy software components.
Describe runtime processing nodes
52
Deployment Diagram Notations
Node:- A node is the main tool in the deployment diagram. It describes the
execution of the codes and how the system components interact with one another.
A node can be a software or hardware object. Mostly, a node is a physical entity.
Nodes have two main types:
Device nodes are computing resources with processing capabilities and the ability
to execute programs. Some examples of device nodes include PCs, laptops, and
mobile phones.
An execution environment node, is any computer system that resides within a
device node. It could be an operating system, a JVM, or another servlet container.
53
Con’d
54
User Interface Design
User interface is the front-end application view to which user interacts
in order to use the software. User can manipulate and control the software
as well as hardware by means of user interface.
Today, user interface is found at almost every place where digital
technology exists, right from computers, mobile phones, cars, music
players, airplanes, ships etc.
User interface is part of software and is designed such a way that it is
expected to provide the user insight of the software. UI provides
fundamental platform for human-computer interaction.
UI can be graphical, text-based, audio-video based, depending upon the
underlying hardware and software combination. UI can be hardware or
software or a combination of both.
55
UID principles
• The structure principle
• The simplicity principle
• The visibility principle
• The feedback principle
• The tolerance principle
• The reuse principle
56
Techniques for improving your UID
• Consistency, Consistency, Consistency
• Set standards and stick to them
• Explain the rules
• Support both novices and experts
• Navigation between major user interface items is important
• Navigation within a screen is important
• Word your messages and labels appropriately
• Understand your widgets
57
Con’d
• Use color appropriately
• Follow the contrast rule
• Align field effectively
• Expect your users to make mistakes
• Justify data appropriately
• Your design should be intuitable
• Don't create busy user interfaces
• Group things effectively
58
UID Standards and Guideline
• Adopt and industry standard and modify it as needed
• Follow and enforce the guidelines
• Obtain training in user interface design and in the
guidelines
59
Design Tips
• Focus on the problem not the technique
• Don't forget your technical infrastructure
• Document your style guideline
• Develop a technical prototype
• Requirements then analysis then design and then code
• Use Computer Aided System Engineering (CASE) tools effectively
• Document complicated things
• Do not over document
• Design for change
• Design for your implementation environment judiciously
• Expect and act on feedback
• Indicate application of patterns
60
Thank y u…!