OOAD
OOAD
Module-I:
Introduction:
BASIC CONCEPTS
1. Class
2. Object
3. Method and method passing
4. Pillars of OOPs Abstraction, Encapsulation, Inheritance, Polymorphism
1. Modifiers: A class can be public or have default access (Refer to this for
details).
2. Class name: The class name should begin with the initial letter
capitalized by convention.
3. Superclass (if any): The name of the class’s parent (superclass), if any,
preceded by the keyword extends. A class can only extend (subclass) one
parent.
4. Interfaces (if any): A comma-separated list of interfaces implemented by
the class, if any, preceded by the keyword implements. A class can
implement more than one interface.
5. Body: The class body is surrounded by braces, { }.
1
2. Behavior: It is represented by the methods of an object. It also reflects the
response of an object to other objects.
3. Identity: It is a unique name given to an object that enables it to interact
with other objects.
ABSTRACTION
Data Abstraction is the property by virtue of which only the essential details are
displayed to the user. The trivial or non-essential units are not displayed to the
user. Ex: A car is viewed as a car rather than its individual components.
Data Abstraction may also be defined as the process of identifying only the
required characteristics of an object, ignoring the irrelevant details. The
properties and behaviors of an object differentiate it from other objects of similar
type and also help in classifying/grouping the object.
Consider a real-life example of a man driving a car. The man only knows that
pressing the accelerators will increase the car speed or applying brakes will stop
the car, but he does not know how on pressing the accelerator, the speed is
actually increasing. He does not know about the inner mechanism of the car or
the implementation of the accelerators, brakes etc. in the car. This is what
abstraction is.
In Java, abstraction is achieved by interfaces and abstract classes. We can achieve
100% abstraction using interfaces.
ENCAPSULATION
2
• Encapsulation can be achieved by declaring all the variables in a class as
private and writing public methods in the class to set and get the values
of the variables.
INHERITANCE
POLYMORPHISM
ABSTRACTION
Data Abstraction- is the property by virtue of which only the essential details
are displayed to the user. The trivial or the non-essential units are not displayed
to the user. Ex: A car is viewed as a car rather than its individual components.
3
5. Any class that contains one or more abstract methods must also be
declared with an abstract keyword.
6. There can be no object of an abstract class. That is, an abstract class
can not be directly instantiated with the new operator.
7. An abstract class can have parameterized constructors and the default
constructor is always present in an abstract class.
Advantages of Abstraction
ENCAPSULATION
4
end-user or the world without providing any details behind
implementation using the abstraction concept, so it is also known as
a combination of data-hiding and abstraction.
• Encapsulation can be achieved by Declaring all the variables in the class
as private and writing public methods in the class to set and get the
values of variables.
• It is more defined with the setter and getter method.
Advantages of Encapsulation:
class Area {
int length;
int breadth;
this.length = length;
this.breadth = breadth;
5
int area = length * breadth;
class Main {
rectangle.getArea();
}
Output
Area: 32
INFORMATION HIDING
Data hiding is a technique of hiding internal object details, i.e., data members. It
is an object-oriented programming technique. Data hiding ensures, or we can say
guarantees to restrict the data access to class members. It maintains data
integrity.
Data hiding means hiding the internal data within the class to prevent its direct
access from outside the class.
If we talk about data encapsulation so, Data encapsulation hides the private
methods and class data parts, whereas Data hiding only hides class data
components. Both data hiding and data encapsulation are essential concepts of
object-oriented programming. Encapsulation wraps up the complex data to
present a simpler view to the user, whereas Data hiding restricts the data use to
assure data security.
Data hiding also helps to reduce the system complexity to increase the robustness
by limiting the interdependencies between software components. Data hiding is
achieved by using the private access specifier.
6
Example:
Now, let's discuss the access specifiers to understand the data hiding. Access
specifiers define how the member's functions and variables can be accessed from
outside the class. So, there are three access specifiers available within a class that
are stated as follows:
Example
In this example, there is a class with a variable and two functions. Here, the
variable "num" is private so, it can be accessed only by the members of the same
class, and it can't be accessed anywhere else. Hence, it is unable to access this
variable outside the class, which is called data hiding.
(encapsulatiin)
INHERITANCE
7
• Sub Class: The class that inherits the other class is known as a
subclass(or a derived class, extended class, or child class). The subclass
can add its own fields and methods in addition to the superclass fields
and methods.
• Reusability: Inheritance supports the concept of “reusability”, i.e. when
we want to create a new class and there is already a class that includes
some of the code that we want, we can derive our new class from the
existing class. By doing this, we are reusing the fields and methods of
the existing class.
Syntax :
DYNAMIC BINDING
EXAMPLE
8
1. class Animal
2. {
3. void eat(){System.out.println("animal is eating...");}
4. {
5. class Dog extends Animal{
6. void eat(){System.out.println("dog is eating...");}
7. public static void main(String args[]){
8. Animal a=new Dog();
9. a.eat();
10. }
11. }
In the above example object type cannot be determined by the compiler,
because the instance of Dog is also an instance of Animal. So compiler
doesn't know its type, only its base type.
DYNAMIC MODELLING describes those aspect of the system that are concerned
with time and sequencing of the operations. It is used to specify and implement
the control aspect of the system. Dynamic model is represented graphically with
the help of state diagrams. It is also known as state modelling. State model
consist of multiple state diagrams, one for each class with temporal behavior
that is important to an application. State diagram relates with events and states.
Events represents external functional activity and states represents values
objects.
Events:
An event is something that happen at a particular point in particular time such
as a person press button or train 15930 departs from Amritsar. Event conveys
information from one object to another.
The events are of three types: Signal event, Change event, and Time event.
These are explained as following below.
1. Signal event :
A signal event is an particular occurrence in time. A signal is a explicit
one-way transmission of information from one object to another.A
signal event is the event of sending or receiving signal.When an object
send signal to another object it await for acknowledgement but
acknowledgement signal is the separate signal under the control of
second object, which may or may not choose to send it.The UML
notation is (<>) written inside the name at top of the box and in another
section list all the signal attributes.Eg:
9
2. Change event :
It is caused by the satisfaction of a boolean expression.The intent of the
change event is that the expression is tested continually whenever the
expression changes from false to true.The UML notation for a change
event is the keyword when followed by a parenthesized boolean
expression.
Eg:
3. when(battery power < lower limit)
when(room temperature < heating/cooling point )
4. Time event :
It is caused by occurrence of an absolute or the elapse of time
interval.The UML notation for absolute time is the keyword when
followed by a parenthesized expression involving time and for the time
interval is keyword after followed by a parenthesized expression that
evaluates time duration.
Eg:
5. when(Date = mar 2, 2005)
after(50 seconds)
State :
A state is an abstraction of attribute values and links of an object. Values and
links are combined together into a state according to their entire behavior. The
response of object according to input event is called state. A state corresponds
to the interval between two events received by an object. The state of the event
depends on the past event. So basically, state represents intervals of time. The
UML notation for the state is a round box containing an optional state name list,
list the name in boldface, center the name near the top of the box, capitalize the
first letter. Eg:
The following are the important points needs to be remember about state.
1. Ignore attributes that do not affect the behavior of object.
2. The objects in the class have finite number of possible states.
3. Each object can be in one state at a time.
10
4. ALL events are ignored in a state, except those for which behavior is
explicitly prescribed.
5. Both events and states depend upon level of abstraction.
POLYMORPHISM
The word polymorphism means having many forms. In simple words, we can
define polymorphism as the ability of a message to be displayed in more than
one form.
Real-life Illustration:
A person at the same time can have different characteristics. Like a man at the
same time is a father, a husband, an employee. So the same person possesses
different behavior in different situations. This is called polymorphism.
Polymorphism is considered one of the important features of Object-Oriented
Programming. Polymorphism allows us to perform a single action in different
ways. In other words, polymorphism allows you to define one interface and have
multiple implementations. The word “poly” means many and “morphs” means
forms, So it means many forms.
Types of polymorphism
11
METHOD OVERLOADING:
When there are multiple functions with the same name but different parameters
then these functions are said to be overloaded. Functions can be overloaded by
change in the number of arguments or/and a change in the type of arguments.
OVERVIEW OF OOAD
In the system analysis or object-oriented analysis phase of software development,
the system requirements are determined, the classes are identified and the
relationships among classes are identified.
The three analysis techniques that are used in conjunction with each other for
object-oriented analysis are object modelling, dynamic modelling, and functional
modelling.
Object Modelling
Object modelling develops the static structure of the software system in terms of
objects. It identifies the objects, the classes into which the objects can be
grouped into and the relationships between the objects. It also identifies the main
attributes and operations that characterize each class.
The process of object modelling can be visualized in the following steps −
12
Dynamic Modelling
After the static behavior of the system is analyzed, its behavior with respect to
time and external changes needs to be examined. This is the purpose of dynamic
modelling.
Dynamic Modelling can be defined as “a way of describing how an individual
object responds to events, either internal events triggered by other objects, or
external events triggered by the outside world”.
The process of dynamic modelling can be visualized in the following steps −
• Feasibility Study
• Requirement Analysis and Specification
• System Design
• Implementation
• Post-implementation Review
13
Now, we will look at the relative advantages and disadvantages of structured
analysis approach and object-oriented analysis approach.
Advantages/Disadvantages of Object Oriented Analysis
Advantages Disadvantages
Advantages Disadvantages
14
It is based upon functionality. The The initial cost of constructing
overall purpose is identified and then the system is high, since the
functional decomposition is done for whole system needs to be
developing the software. The designed at once leaving very
emphasis not only gives a better little option to add
understanding of the system but also functionality later.
generates more complete systems.
Module-II
The UML was developed in 1994-95 by Grady Booch, Ivar Jacobson, and James
Rumbaugh at the Rational Software. In 1997, it got adopted as a standard by the
Object Management Group (OMG).
Characteristics of UML
15
UML VIEWS
There are five different views that the UML aims to visualize through different
modeling diagrams. These five views are:
1. User's View
2. Structural Views
3. Behavioral Views
4. Environmental View
5. Implementation View
1) User's view
This contains the diagrams in which the user's part of interaction with the
software is defined. No internal working of the software is defined in this model.
The diagrams contained in this view are:
2) Structural view
In the structural view, only the structure of the model is explained. This gives an
estimate of what the software consists of. However, internal working is still not
defined in this model. The diagram that this view includes are:
• Class Diagrams
• Object Diagrams
3) Behavioral view
The behavioral view contains the diagrams which explain the behavior of the
software. These diagrams are:
• Sequence Diagram
• Collaboration Diagram
• State chart Diagram
• Activity Diagram
4) Environmental view
The environmental view contains the diagram which explains the after
deployment behavior of the software model. This diagram usually explains the
user interactions and software effects on the system. The diagrams that the
environmental model contain are:
16
• Deployment diagram
5) Implementation view
• Component Diagram
The following diagram well explains the distribution of these 9 software diagrams
according to the five mentioned views:
UML DIAGRAMS
17
1. STRUCTURAL DIAGRAMS
o Class Diagram: Class diagrams are one of the most widely used diagrams. It
is the backbone of all the object-oriented software systems. It depicts the
static structure of the system. It displays the system's class, attributes, and
methods. It is helpful in recognizing the relation between different objects
as well as classes.
o Composite Structure Diagram: The composite structure diagrams show
parts within the class. It displays the relationship between the parts and
their configuration that ascertain the behavior of the class. It makes full use
of ports, parts, and connectors to portray the internal structure of a
structured classifier. It is similar to class diagrams, just the fact it
represents individual parts in a detailed manner when compared with class
diagrams.
o Object Diagram: It describes the static structure of a system at a particular
point in time. It can be used to test the accuracy of class diagrams. It
represents distinct instances of classes and the relationship between them
at a time.
18
o Component Diagram: It portrays the organization of the physical
components within the system. It is used for modeling execution details. It
determines whether the desired functional requirements have been
considered by the planned development or not, as it depicts the structural
relationships between the elements of a software system.
o Deployment Diagram: It presents the system's software and its hardware
by telling what the existing physical components are and what software
components are running on them. It produces information about system
software. It is incorporated whenever software is used, distributed, or
deployed across multiple machines with dissimilar configurations.
o Package Diagram: It is used to illustrate how the packages and their
elements are organized. It shows the dependencies between distinct
packages. It manages UML diagrams by making it easily understandable. It is
used for organizing the class and use case diagrams.
2. BEHAVIORAL DIAGRAMS:
19
3. INTERACTION DIAGRAMS
The main purpose of a use case diagram is to portray the dynamic aspect of a
system.
1. It gathers the system's needs.
2. It depicts the external view of the system.
3. It recognizes the internal as well as external factors that influence the
system.
4. It represents the interaction between the actors.
20
Example
A use case diagram depicting the Online Shopping website is given below.
Here the Web Customer actor makes use of any online shopping website to
purchase online. The top-level uses are as follows; View Items, Make Purchase,
Checkout, Client Register. The View Items use case is utilized by the customer
who searches and view products. The Client Register use case allows the
customer to register itself with the website for availing gift vouchers, coupons, or
getting a private sale invitation. It is to be noted that the Checkout is an included
use case, which is part of Making Purchase, and it is not available by itself.
The View Items is further extended by several use cases such as; Search Items,
Browse Items, View Recommended Items, Add to Shopping Cart, Add to Wish list.
All of these extended use cases provide some functions to customers, which
allows them to search for an item. The View Items is further extended by several
use cases such as; Search Items, Browse Items, View Recommended Items, Add to
Shopping Cart, Add to Wish list. All of these extended use cases provide some
functions to customers, which allows them to search for an item.
Following are some important tips that are to be kept in mind while drawing a use
case diagram:
21
2. A use case diagram should represent the most significant interaction among
the multiple interactions.
3. At least one module of a system should be represented by the use case
diagram.
4. If the use case diagram is large and more complex, then it should be drawn
more generalized.
Class diagrams
22
HOW TO DRAW A CLASS DIAGRAM?
Example
Class Relations
23
of logical connections. The following are such types of logical connections that
are possible in UML:
• Association
• Directed Association
• Reflexive Association
• Multiplicity
• Aggregation
• Composition
• Inheritance/Generalization
• Realization
Association
Reflexive Association
Multiplicity
Aggregation
24
books will remain so even when the library is dissolved. To show aggregation in a
diagram, draw a line from the parent class to the child class with a diamond shape
near the parent class.
To show aggregation in a diagram, draw a line from the parent class to the child
class with a diamond shape near the parent class.
Composition
Inheritance / Generalization
Realization
Association
Association is the semantic relationship between classes that shows how one
instance is connected or merged with others in a system.
25
b. {ordered}: It describes that the set of entities is in a particular way at one
end in an association.
c. {changeable}: The changeable constraint ensures that the connections
between several objects within a system are added, improved, and
detached, as and when required.
d. {addOnly}: It specifies that any new connection can be added from an object
located at the other end in an association.
e. {frozen}: The frozen constraint specifies that whenever a link is added
between objects, it cannot be altered by the time it is activated over the
connection or given link.
Reflexive Association
In the reflexive associations, the links are between the objects of the same
classes. In other words, it can be said that the reflexive
association consists of the same class at both ends. An
object can also be termed as an instance.
DIRECTED ASSOCIATION
The directed association is concerned with the direction of flow inside association
classes. The flow of association can be shown by employing a directed
association. The directed association between two classes is represented by a line
with an arrowhead, which indicates the navigation direction. The flow of
association from one class to another is always in one direction.
It can be said that there is an association between a person and the company. The
person works for the company. Here the person works for the company, and not
the company works for a person.
26
Inheritance
AGGREGATION
For example:
Here we are considering a car and a wheel example. A car cannot move without a
wheel. But the wheel can be independently
used with the bike, scooter, cycle, or any
other vehicle. The wheel object can exist
without the car object, which proves to be an
aggregation relationship.
COMPOSITION
Inheritance,
DEPENDENCY
Dependency depicts how various things within a system are dependent on each
other. In UML, a dependency relationship is the kind of relationship in which a
client (one element) is dependent on the supplier (another element). It is used in
class diagrams, component diagrams, deployment diagrams, and use-case
diagrams, which indicates that a change to the supplier necessitates a change to
the client.
27
Types of Dependency Relationship
28
o <<include>> -It describes the source element, which can include the
behavior of another element at a specific location, just like a function call in
C/C++.
o <<become>> -It states that target is similar to the source with distinct roles
and values.
o <<call>> -It specifies that the target object can be invoked by the source.
o <<copy>> -It states that the target is an independent replica of a source
object.
o <<parameter>> -It describes that the supplier is a parameter of the client's
actions.
o <<send>> -The client act as an operation, which sends some unspecified
targets to the supplier.
OBJECT DIAGRAM
Object diagrams are dependent on the class diagram as they are derived from the
class diagram. It represents an instance of a class diagram. The objects help in
portraying a static view of an object-oriented system at a specific instant.
Both the object and class diagram are similar to some extent; the only difference
is that the class diagram provides an abstract view of a system. It helps in
visualizing a particular functionality of a system.
The object diagram is actually similar to the concrete (actual) system behavior.
The main purpose is to depict a static view of a system.
29
o It is used to understand object behavior and their relationships practically.
o It is used to get a static view of a system.
o It is used to represent an
instance of a system.
Example
The following are the application areas where the object diagrams can be used.
30
2. Dynamic changes are not included in Dynamic changes are captured in
the class diagram. the object diagram.
PACKAGES
INTERACTION DIAGRAMS
the interaction diagram portrays the interactions between distinct entities present
in the model. It amalgamates both the activity and sequence diagrams. The
communication is nothing but units of the behavior of a classifier that provides
context for interactions.
A set of messages that are interchanged between the entities to achieve certain
specified tasks in the system is termed as interaction. It may incorporate any
feature of the classifier of which it has access. In the interaction diagram, the
critical component is the messages and the lifeline.
In UML, the interaction overview diagram initiates the interaction between the
objects utilizing message passing. While drawing an interaction diagram, the
entire focus is to represent the relationship among different objects which are
available within the system boundary and the message exchanged by them to
communicate with each other.
31
Following are the purpose of an interaction diagram given below:
32
6. The interaction diagram models the system as a time-ordered sequence of a
system.
7. The interaction diagram systemizes the structure of the interactive
elements.
SEQUENCE DIAGRAMS
The sequence diagram represents the flow of messages in the system and is also
termed as an event diagram. It helps in envisioning several dynamic scenarios. It
portrays the communication between any two lifelines as a time-ordered sequence
of events, such that these lifelines took part at the run time. In UML, the lifeline is
represented by a vertical bar, whereas the message flow is represented by a
vertical dotted line that extends across the bottom of the page. It incorporates the
iterations as well as branching.
Lifeline
ACTOR
33
Activation
Messages
The messages depict the interaction between the objects and are
represented by arrows. They are in the sequential order on the lifeline. The core
of the sequence diagram is formed by messages and lifelines.
34
Note
Fragments
Sequence Fragments
1. Sequence fragments have been introduced by UML 2.0, which makes it quite
easy for the creation and maintenance of an accurate sequence diagram.
2. It is represented by a box called a combined fragment, encloses a part of
interaction inside a sequence diagram.
3. The type of fragment is shown by a fragment
operator.
Types of fragments
alt Alternative multiple fragments: The only fragment for which the
condition is true, will execute.
opt Optional: If the supplied condition is true, only then the fragments will
execute. It is similar to alt with only one trace.
loop Loop: Fragments are run multiple times, and the basis of interaction is
shown by the guard.
region Critical region: Only one thread can execute a fragment at once.
35
neg Negative: A worthless communication is shown by the fragment.
Communication diagram
Communication diagrams are a type of interaction diagram that you can use to
explore the dynamic behavior of a system or software application. They provide
an alternate view of the same information as sequence diagrams. In sequence
diagrams, the focus is the ordering of the messages over time; in communication
diagrams the focus is the structure of the messages that pass between the objects
in the interaction. These diagrams illustrate the flow of messages between objects
and the implied relationships between classes.
36
banking scenario, lifelines can represent objects such as a bank system or
customer. Each instance in an interaction is represented by a lifeline.
• Message pathways in
communication diagrams
In communication diagrams, a
message pathway is a connector
between the roles or objects
represented by lifelines in the
diagram. The pathway identifies
the objects that can pass
messages in the interaction.
• Messages in UML diagrams
A message is an element in a
Unified Modeling Language (UML)
diagram that defines a specific
kind of communication between
instances in an interaction. A
message conveys information
from one instance, which is
represented by a lifeline, to another instance in an interaction.
State diagram
A state diagram is used to represent the condition of the system or part of the
system at finite instances of time. It’s a behavioral diagram and it represents
the behavior using finite state transitions. State diagrams are also referred to
as State machines and State-chart Diagrams. These terms are often used
interchangeably. So simply, a state diagram is used to model the dynamic
behavior of a class in response to time and changing external stimuli.
37
The state diagram above shows the different states in which the verification sub-
system or class exist for a particular system.
1. Initial state – We use a black filled circle represent the initial state of a
System or a class.
Figure – transition
3. State – We use a rounded rectangle to represent a state. A state
represents the conditions or circumstances of an object of a class at an
instant of time.
38
common goal state. We use the join notation when two or more states
concurrently converge into one on the occurrence of an event or events.
6. Self transition – We use a solid arrow pointing back to the state itself to
represent a self transition. There might be scenarios when the state of
the object does not change upon the occurrence of an event. We use self
transitions to represent such cases.
39
example of how an online ordering system might look like :
1. On the event of an order being received, we transit from our initial state
to Unprocessed order state.
2. The unprocessed order is then checked.
3. If the order is rejected, we transit to the Rejected Order state.
4. If the order is accepted and we have the items available we transit to
the fulfilled order state.
5. However if the items are not available we transit to the Pending Order
state.
6. After the order is fulfilled, we transit to the final state. In this example,
we merge the two states i.e. Fulfilled order and Rejected order into one
final state.
EVENTS
The event state diagram shows possible event states and describes how
transitions occur between these states based on the values in the alerts.status
Severity and Tally fields. The diagram also shows how different event types are
handled.
The event state diagram is shown below. Each event is assigned one of these
states as it passes through the Event Gateway. Each state transition corresponds
to an updated event received from the ObjectServer. The event states are shown
with an associated color as follows:
Concurrent states
A Concurrent State is partitioned into regions, which are separated by a dashed
line. Each region represents a Concurrent Substate into which you can add States.
By default, a Concurrent State is created with two concurrent substates.
Concurrency modeling is used to simplify state models, where there are separate
areas of concern. This is done by splitting a Concurrent State into partitions. It
40
should not be confused with parallel execution, described as tasks on the
concurrency diagram
Create a Concurrent State through a Modeler explorer pane or a State Diagram:
• In a Modeler pane, right-click a State Machine or Sequential State, point to New,
and then click Concurrent State.
• On a State Diagram, click the Concurrent State toolbar button, and then click the
diagram background (within the frame) or within a Sequential State.
On a Concurrent State you can create doActivities that are continuous performed
by the Concurrent State. A doActivity terminates when the Concurrent State is
complete, or when the Concurrent State is exited. A
doActivity can be an Activity, Operation or State Machine.
When used on a State Diagram, a Concurrent State's
notation is as follows.
history state
Component diagram
a) A component b) A node
41
Purpose of a Component Diagram
Following are some reasons for the requirement of the component diagram:
AD
Following are some artifacts that are needed to be identified before drawing a
component diagram:
42
Following are some points that are needed to be kept in mind after the artifacts
are identified:
1. Using a meaningful name to ascertain the component for which the diagram
is about to be drawn.
2. Before producing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.
Deployment diagram.
Deployment diagrams are used for describing the hardware components, where
software components are deployed. Component diagrams and deployment
diagrams are closely related.
Purpose of Deployment Diagrams
UML is mainly designed to focus on the software artifacts of a system. However,
these two diagrams are special diagrams used to focus on software and hardware
components.
The purpose of deployment diagrams can be described as −
• Visualize the hardware topology of a system.
• Describe the hardware components used to deploy software
components.
• Describe the runtime processing nodes.
43
Draw a Deployment Diagram
GUARDS
To model conditions we use guards in UML. They are used when we need to restrict the
flow of messages on the pretext of a condition being met. Guards play an important role
44
in letting software developers know the constraints attached to a system or a particular
process. For example: In order to be able to withdraw cash, having a balance greater than
zero is a condition that must be met as shown below. Figure –
sequence diagram using a guard
COMPOSITE STATE
We use a rounded rectangle to represent a composite state also.We represent a state with
internal activities using a composite state.
45
Here we begin by doing an authorization. The "check payment" activity finishes
by signaling that the payment is approved. If the payment is OK, the given order
waits in the Authorized state until the "deliver" event occurs. Otherwise, the order
enters the Rejected state.
The Order object exhibits a combination of the behaviors shown in Figure 8-1 and
Figure 8-2. The associated states and the Cancelled state discussed earlier can be
combined on a concurrent state diagram.
46
concurrent state diagrams for an object, you should consider splitting the object
into separate objects.
HISTORY STATES
A history state is used to remember the previous state of a state machine when it
was interrupted. The following diagram illustrates the use of history states. The
example is a state machine belonging to a washing machine.
In this state machine, when a washing machine is running, it will progress from
"Washing" through "Rinsing" to "Spinning". If there is a power cut, the washing
machine will stop running and will go to the "Power Off" state. Then when the
power is restored, the Running state is entered at the "History State" symbol
meaning that it should resume where it last left-off.
47
show the message flow from one object to another but activity diagram is used to
show message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only
used for visualizing the dynamic nature of a system, but they are also used to
construct the executable system by using forward and reverse engineering
techniques. The only missing thing in the activity diagram is the message part.
It does not show any message flow from one activity to another. Activity diagram
is sometimes considered as the flowchart. Although the diagrams look like a
flowchart, they are not. It shows different flows such as parallel, branched,
concurrent, and single.
The purpose of an activity diagram can be described as −
• Draw the activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.
How to Draw an Activity Diagram?
Activity diagrams are mainly used as a flowchart that consists of activities
performed by the system. Activity diagrams are not exactly flowcharts as they
have some additional capabilities. These additional capabilities include
branching, parallel flow, swimlane, etc.
Before drawing an activity diagram, we must have a clear understanding about the
elements used in activity diagram. The main element of an activity diagram is the
activity itself. An activity is a function performed by the system. After identifying
the activities, we need to understand how they are associated with constraints
and conditions.
Before drawing an activity diagram, we should identify the following elements −
• Activities
• Association
• Conditions
• Constraints
Once the above-mentioned parameters are identified, we need to make a mental
layout of the entire flow. This mental layout is then transformed into an activity
diagram.
Following is an example of an activity diagram for order management system. In
the diagram, four activities are identified which are associated with conditions.
One important point should be clearly understood that an activity diagram cannot
be exactly matched with the code. The activity diagram is made to understand the
flow of activities and is mainly used by the business users
Following diagram is drawn with the four main activities −
• Send order by the customer
48
• Receipt of the order
• Confirm the order
• Dispatch the order
After receiving the order request, condition checks are performed to check if it is
normal or special order. After the type of order is identified, dispatch activity is
performed and that is marked as the termination of the process.
49
• Modeling work flow by using activities.
• Modeling business requirements.
• High level understanding of the system's functionalities.
• Investigating business requirements at a later stage.
The Activity diagrams in Object Oriented Design are just like the flow carts that show
the sequence of steps that make up a complex process, such as an algorithm or
workflow. Activity diagram are most useful during the initial stages of the design phase.
Example:
An example of the activity diagram for “TICKET VENDING MACHINE” is as shown below:
50
The above activity diagram does not show which organisation performs a particular
activity
Swim Lanes:
Swimlanes are used to show which activities are performed by which organisation in the
activity diagram. The lanes are boundaries are drawn and the activities of a particular
organisation are drawn in the same lane as that of the organisation. Swimlanes have to be
ordered in a Logical Manner. It is suggested to have less than five swimlanes in an
activity diagram. Swimlanes are good in that they combine the activity diagram’s
51
The above activity diagram for “TICKET VENDING MACHINE” with the swimlanes is
shown below:
52
OBJECT FLOWS IN ACTIVITY DIAGRAMS
In Activity diagrams, there are several ways to define the flow of data between
objects.
This diagram depicts a simple Object Flow between two actions, Fill Order and
Ship Order, both accessing order information.
53
UML COMPONENT DIAGRAM
a) A component
b) A node
The component diagram also describes the static view of a system, which
includes the organization of components at a particular instant. The collection of
component diagrams represents a whole system.
54
2. It constructs the executable by incorporating forward and reverse
engineering.
3. It depicts the relationships and organization of components.
Following are some reasons for the requirement of the component diagram:
55
Once the system is designed employing different UML diagrams, and the artifacts
are prepared, the component diagram is used to get an idea of implementation. It
plays an essential role in implementing applications efficiently.
Following are some artifacts that are needed to be identified before drawing a
component diagram:
Following are some points that are needed to be kept in mind after the artifacts
are identified:
1. Using a meaningful name to ascertain the component for which the diagram
is about to be drawn.
2. Before producing the required tools, a mental layout is to be made.
3. To clarify the important points, notes can be incorporated.
56
components of a system, or we can say it portrays the organization of the
components inside a system. The components, such as libraries, files,
executables, etc. are first needed to be organized before the implementation.
The deployment diagram visualizes the physical hardware on which the software
will be deployed. It portrays the static deployment view of a system. It involves
the nodes and their relationships.
Both the deployment diagram and the component diagram are closely interrelated
to each other as they focus on software and hardware components. The
component diagram represents the components of a system, whereas the
deployment diagram describes how they are actually deployed on the hardware.
The deployment diagram does not focus on the logical components of the system,
but it put its attention on the hardware topology.
57
3. To describe the processing of nodes at the runtime.
1. A component
2. An artifact
3. An interface
4. A node
The deployment diagram portrays the deployment view of the system. It helps in
visualizing the topological view of a system. It incorporates nodes, which are
physical hardware. The nodes are used to execute the artifacts. The instances of
artifacts can be deployed on the instances of nodes.
Since it plays a critical role during the administrative process, it involves the
following parameters:
1. High performance
2. Scalability
3. Maintainability
4. Portability
5. Easily understandable
58
One of the essential elements of the deployment diagram is the nodes and
artifacts. So it is necessary to identify all of the nodes and the relationship
between them. It becomes easier to develop a deployment diagram if all of the
nodes, artifacts, and their relationship is already known.
The iTunes setup can be downloaded from the iTunes website, and also it can be
installed on the home computer. Once the installation and the registration are
done, iTunes application can easily interconnect with the Apple iTunes store.
Users can purchase and download music, video, TV serials, etc. and cache it in the
media library.
Devices like Apple iPod Touch and Apple iPhone can update its own media library
from the computer with iTunes with the help of USB or simply by downloading
media directly from the Apple iTunes store using wireless protocols, for example;
Wi-Fi, 3G, or EDGE.
59
When to use a Deployment Diagram?
The software applications are quite complex these days, as they are standalone,
distributed, web-based, etc. So, it is very necessary to design efficient software.
Module 3
60
• Context − The context of a system has a static and a dynamic part. The
static context of the system is designed using a simple block diagram
of the whole system which is expanded into a hierarchy of
subsystems. The subsystem model is represented by UML packages.
The dynamic context describes how the system interacts with its
environment. It is modelled using use case diagrams.
• System Architecture − The system architecture is designed on the
basis of the context of the system in accordance with the principles of
architectural design as well as domain knowledge. Typically, a system
is partitioned into layers and each layer is decomposed to form the
subsystems.
OBJECT-ORIENTED DECOMPOSITION
Decomposition means dividing a large complex system into a hierarchy of smaller
components with lesser complexities, on the principles of divide–and–conquer.
Each major component of the system is called a subsystem. Object-oriented
decomposition identifies individual autonomous objects in a system and the
communication among these objects.
The advantages of decomposition are −
• The individual components are of lesser complexity, and so more
understandable and manageable.
• It enables division of workforce having specialized skills.
• It allows subsystems to be replaced or modified without affecting
other subsystems.
IDENTIFYING CONCURRENCY
Concurrency allows more than one objects to receive events at the same time and
more than one activity to be executed simultaneously. Concurrency is identified
and represented in the dynamic model.
To enable concurrency, each concurrent element is assigned a separate thread of
control. If the concurrency is at object level, then two concurrent objects are
assigned two different threads of control. If two operations of a single object are
concurrent in nature, then that object is split among different threads.
Concurrency is associated with the problems of data integrity, deadlock, and
starvation. So a clear strategy needs to be made whenever concurrency is
required. Besides, concurrency requires to be identified at the design stage itself,
and cannot be left for implementation stage.
IDENTIFYING PATTERNS
While designing applications, some commonly accepted solutions are adopted for
some categories of problems. These are the patterns of design. A pattern can be
defined as a documented set of building blocks that can be used in certain types
of application development problems.
61
Some commonly used design patterns are −
• Façade pattern
• Model view separation pattern
• Observer pattern
• Model view controller pattern
• Publish subscribe pattern
• Proxy pattern
CONTROLLING EVENTS
During system design, the events that may occur in the objects of the system
need to be identified and appropriately dealt with.
An event is a specification of a significant occurrence that has a location in time
and space.
There are four types of events that can be modelled, namely −
• Signal Event − A named object thrown by one object and caught by
another object.
• Call Event − A synchronous event representing dispatch of an
operation.
• Time Event − An event representing passage of time.
• Change Event − An event representing change in state.
HANDLING BOUNDARY CONDITIONS
The system design phase needs to address the initialization and the termination
of the system as a whole as well as each subsystem. The different aspects that are
documented are as follows −
• The start–up of the system, i.e., the transition of the system from non-
initialized state to steady state.
• The termination of the system, i.e., the closing of all running threads,
cleaning up of resources, and the messages to be sent.
• The initial configuration of the system and the reconfiguration of the
system when needed.
• Foreseeing failures or undesired termination of the system.
Boundary conditions are modelled using boundary use cases.
OBJECT DESIGN
After the hierarchy of subsystems has been developed, the objects in the system
are identified and their details are designed. Here, the designer details out the
strategy chosen during the system design. The emphasis shifts from application
domain concepts toward computer concepts. The objects identified during
analysis are etched out for implementation with an aim to minimize execution
time, memory consumption, and overall cost.
62
Object design includes the following phases −
• Object identification
• Object representation, i.e., construction of design models
• Classification of operations
• Algorithm design
• Design of relationships
• Implementation of control for external interactions
• Package classes and associations into modules
OBJECT IDENTIFICATION
The first step of object design is object identification. The objects identified in
the object–oriented analysis phases are grouped into classes and refined so that
they are suitable for actual implementation.
The functions of this stage are −
• Identifying and refining the classes in each subsystem or package
• Defining the links and associations between the classes
• Designing the hierarchical associations among the classes, i.e., the
generalization/specialization and inheritances
• Designing aggregations
OBJECT REPRESENTATION
Once the classes are identified, they need to be represented using object
modelling techniques. This stage essentially involves constructing UML diagrams.
There are two types of design models that need to be produced −
• Static Models − To describe the static structure of a system using
class diagrams and object diagrams.
• Dynamic Models − To describe the dynamic structure of a system and
show the interaction between classes using interaction diagrams and
state–chart diagrams.
CLASSIFICATION OF OPERATIONS
In this step, the operation to be performed on objects are defined by combining
the three models developed in the OOA phase, namely, object model, dynamic
model, and functional model. An operation specifies what is to be done and not
how it should be done.
The following tasks are performed regarding operations −
• The state transition diagram of each object in the system is developed.
• Operations are defined for the events received by the objects.
• Cases in which one event triggers other events in same or different
objects are identified.
63
• The sub–operations within the actions are identified.
• The main actions are expanded to data flow diagrams.
ALGORITHM DESIGN
DESIGN OF RELATIONSHIPS
The strategy to implement the relationships needs to be chalked out during the
object design phase. The main relationships that are addressed comprise of
associations, aggregations, and inheritances.
The designer should do the following regarding associations −
• Identify whether an association is unidirectional or bidirectional.
• Analyze the path of associations and update them if necessary.
• Implement the associations as a distinct object, in case of many–to-
many relationships; or as a link to other object in case of one–to-one
or one–to-many relationships.
Regarding inheritances, the designer should do the following −
• Adjust the classes and their associations.
• Identify abstract classes.
• Make provisions so that behaviors are shared when needed.
IMPLEMENTATION OF CONTROL
The object designer may incorporate refinements in the strategy of the state–
chart model. In system design, a basic strategy for realizing the dynamic model is
made. During object design, this strategy is aptly embellished for appropriate
implementation.
64
The approaches for implementation of the dynamic model are −
• Represent State as a Location within a Program − This is the
traditional procedure-driven approach whereby the location of control
defines the program state. A finite state machine can be implemented
as a program. A transition forms an input statement, the main control
path forms the sequence of instructions, the branches form the
conditions, and the backward paths form the loops or iterations.
• State Machine Engine − This approach directly represents a state
machine through a state machine engine class. This class executes the
state machine through a set of transitions and actions provided by the
application.
• Control as Concurrent Tasks − In this approach, an object is
implemented as a task in the programming language or the operating
system. Here, an event is implemented as an inter-task call. It
preserves inherent concurrency of real objects.
PACKAGING CLASSES
In any large project, meticulous partitioning of an implementation into modules
or packages is important. During object design, classes and objects are grouped
into packages to enable multiple groups to work cooperatively on a project.
The different aspects of packaging are −
• Hiding Internal Information from Outside View − It allows a class to
be viewed as a “black box” and permits class implementation to be
changed without requiring any clients of the class to modify code.
• Coherence of Elements − An element, such as a class, an operation, or
a module, is coherent if it is organized on a consistent plan and all its
parts are intrinsically related so that they serve a common goal.
• Construction of Physical Modules − The following guidelines help
while constructing physical modules −
o Classes in a module should represent similar things or
components in the same composite object.
o Closely connected classes should be in the same module.
o Unconnected or weakly connected classes should be placed
in separate modules.
o Modules should have good cohesion, i.e., high cooperation
among its components.
o A module should have low coupling with other modules,
i.e., interaction or interdependence between modules
should be minimum.
65
DESIGN OPTIMIZATION
The analysis model captures the logical information about the system, while the
design model adds details to support efficient information access. Before a design
is implemented, it should be optimized so as to make the implementation more
efficient. The aim of optimization is to minimize the cost in terms of time, space,
and other metrics.
However, design optimization should not be excess, as ease of implementation,
maintainability, and extensibility are also important concerns. It is often seen that
a perfectly optimized design is more efficient but less readable and reusable. So
the designer must strike a balance between the two.
The various things that may be done for design optimization are −
Optimization of Algorithms
In object-oriented systems, optimization of data structure and algorithms are
done in a collaborative manner. Once the class design is in place, the operations
and the algorithms need to be optimized.
Optimization of algorithms is obtained by −
66
Saving and Storing of Derived Attributes
Derived attributes are those attributes whose values are computed as a function
of other attributes (base attributes). Re-computation of the values of derived
attributes every time they are needed is a time–consuming procedure. To avoid
this, the values can be computed and stored in their computed forms.
However, this may pose update anomalies, i.e., a change in the values of base
attributes with no corresponding change in the values of the derived attributes.
To avoid this, the following steps are taken −
• With each update of the base attribute value, the derived attribute is
also re-computed.
• All the derived attributes are re-computed and updated periodically in
a group rather than after each update.
DESIGN DOCUMENTATION
Documentation is an essential part of any software development process that
records the procedure of making the software. The design decisions need to be
documented for any non–trivial software system for transmitting the design to
others.
Usage Areas
Though a secondary product, a good documentation is indispensable, particularly
in the following areas −
67
The features of a good documentation are −
• Concise and at the same time, unambiguous, consistent, and complete
• Traceable to the system’s requirement specifications
• Well-structured
• Diagrammatic instead of descriptive
MODULE 3-
DOMAIN MODELING-
-Boundary objects
-Controller objects
-Entity objects
The boundary and controller objects are consistently known from the employment case
diagram whereas the identification of entity objects needs to apply. So, the crux of the
domain modeling activity is to spot the entity models
The different styles of objects known throughout domain analysis and the area of their
relationship unit as follows:
The boundary objects area unit those with that the actors move. These embrace screens,
menus, forms, dialogs, etc. The boundary objects area unit is chiefly answerable for user
interaction. Therefore, they ordinarily don’t embrace any process logic. However, they
will be answerable for confirming inputs, formatting, outputs, etc. The boundary objects
were earlier known as because of the interface objects. However, the term interface
category is getting used for Java, COM/DCOM, and UML with completely different means.
A recommendation for the initial identification of the boundary categories is to outline
one boundary category per actor/use case try.
Entity objects: These ordinarily hold info like information tables and files that require
to outlast use case execution, e.g. Book, BookRegister, LibraryMember, etc. several of the
entity objects area unit “dumb servers”. they’re ordinarily answerable for storing
68
information, winning information, and performing some elementary styles of operation
that don’t amendment usually.
Controller objects: The controller objects coordinate the activities of a collection of
entity objects and interface with the boundary objects to produce the general behavior of
the system. The responsibilities appointed to a controller object area unit are closely
associated with the belief of a particular use case. The controller objects effectively
decouple the boundary and entity objects from each other creating a system tolerant to
changes in the computer program and process logic.
The controller objects embody most of the logic committed to the employment case
realization (this logic might amendment time to time). A typical interaction of a controller
object with boundary and entity objects is shown below(figure) Normally, every use case
is complete victimization of one controller object. However, some use cases are complete
while not victimization any controller object, i.e. through boundary and entity objects
solely. This is often true to be used cases that win just some easy manipulation of the
hold on info.
For example, let’s take into account the “query book availability” use case of the Library
data system (LIS). Realization of the employment case involves solely matching the given
book name against the books offered within the catalog. additional complicated use
cases might need quite one controller object to understand the employment case. a fancy
use case will have many controller objects like group action manager, resource arranger,
and error handler. there’s another state of affairs wherever a use case will have quite one
controller object. generally, the employment cases need the controller object to transit
through a variety of states. In such cases, one controller object may need to be created
for every execution of the employment case.
MODULE 4
69
many benefits of using OOD but every developer should also have the knowledge
of the SOLID principle for good object-oriented design in programming. The
SOLID principle was introduced by Robert C. Martin, also known as Uncle
Bob and it is a coding standard in programming. This principle is an acronym of
the five principles which is given below…
The SOLID principle helps in reducing tight coupling. Tight coupling means a
group of classes are highly dependent on one another which you should avoid in
your code. Opposite of tight coupling is loose coupling and your code is
considered as a good code when it has loosely-coupled classes. Loosely coupled
classes minimize changes in your code, helps in making code more reusable,
maintainable, flexible and stable. Now let’s discuss one by one these principles…
70
not supposed to modify the class directly. Using this principle separates the
existing code from the modified code so it provides better stability,
maintainability and minimizes changes as in your code.
71
High-level modules/classes should not depend on low-level modules/classes. Both
should depend upon abstractions.
Abstractions should not depend upon details. Details should depend upon
abstractions.
The above lines simply state that if a high module or class will be dependent
more on low-level modules or class then your code would have tight coupling and
if you will try to make a change in one class it can break another class which is
risky at the production level. So always try to make classes loosely coupled as
much as you can and you can achieve this through abstraction. The main motive
of this principle is decoupling the dependencies so if class A changes the class B
doesn’t need to care or know about the changes.
You can consider the real-life example of a TV remote battery. Your remote needs
a battery but it’s not dependent on the battery brand. You can use any XYZ brand
that you want and it will work. So we can say that the TV remote is loosely
coupled with the brand name. Dependency Inversion makes your code more
reusable.
• Instability (I)
• Abstractness (A)
72
Efferent Coupling (Ce)
In the pic.1 it can be seen that class A has outgoing dependencies to 3 other classes, that is
why metric Ce for this class is 3.
The high value of the metric Ce> 20 indicates instability of a package, change in any of the
numerous external classes can cause the need for changes to the package. Preferred values
for the metric Ce are in the range of 0 to 20, higher values cause problems with care and
development of code.
This metric is an addition to metric Ce and is used to measure another type of dependencies
between packages, i.e. incoming dependencies. It enables us to measure the sensitivity of
remaining packages to changes in the analysed package.
in the pic.2 it can be seen that class A has only 1 incoming dependency (from class X), that is
why the value for metrics Ca equals 1.
73
High values of metric Ca usually suggest high component stability. This is due to the fact that
the class depends on many other classes. Therefore, it can’t be modified significantly
because, in this case, the probability of spreading such changes increases.
Instability (I)
This metric is used to measure the relative susceptibility of class to changes. According to the
definition instability is the ration of outgoing dependencies to all package dependencies and
it accepts value from 0 to 1.
Pic. 3 – Instability
In the pic.3 it can be seen that class A has 3 outgoing and 1 incoming dependencies, therefore
according to the formula value of metric I will equal 0,75.
74
• The ones having many outgoing dependencies and not many of incoming ones (value I
is close to 1), which are rather unstable due to the possibility of easy changes to these
packages;
• The ones having many incoming dependencies and not many of outgoing ones (value I
is close to 0), therefore they are rather more difficult in modifying due to their greater
responsibility.
Preferred values for the metric I should fall within the ranges of 0 to 0.3 or 0.7 to 1. Packages
should be very stable or unstable, therefore we should avoid packages of intermediate
stability.
Abstractness (A)
This metric is used to measure the degree of abstraction of the package and is somewhat
similar to the instability. Regarding the definition, abstractness is the number of abstract
classes in the package to the number of all classes.
Where: T abstract – number of abstract classes in a package, T concrete – number of concrete classes in a
package
Preferred values for the metric A should take extreme values close to 0 or 1. Packages that are
stable (metric I close to 0), which means they are dependent at a very low level on other
75
packages, should also be abstract (metric A close to 1). In turn, the very unstable packages
(metric I close to 1) should consist of concrete classes (A metric close to 0).
Additionally, it is worth mentioning that combining abstractness and stability enabled Martin
to formulate thesis about the existence of main sequence (Pic. 4).
In the optimal case, the instability of the class is compensated by its abstractness, there is an
equation I + A = 1. Classes that were well designed should group themselves around this
graph end points along the main sequence.
This metric is used to measure the balance between stability and abstractness and is
calculated using the following formula:
The value of metric D may be interpreted in the following way; if we put a given class on a
graph of the main sequence (Pic. 5) its distance from the main sequence will be proportional
to the value of D.
76
Pic. 5 – Normalized distance from Main Sequence
The value of the metric D should be as low as possible so that the components were located
close to the main sequence. In addition, the two extremely unfavourable cases are considered:
Summary
Using Martin’s metrics we can easily assess the relationships between the packages in the
project and determine whether it is necessary to carry out the changes so as to avoid any
possible problems in the future. All metrics discussed in this article can be measured for
projects in .NET using NDepend tool.
CK metrics
The Chidamber & Kemerer metrics suite originally consists of 6 metrics calculated
for each class: WMC, DIT, NOC, CBO, RFC and LCOM1.
77
WMC Weighted Methods Per Class
Despite its long name, WMC is simply the method count for a class.
Keep WMC down. A high WMC has been found to lead to more faults. Classes with
many methods are likely to be more more application specific, limiting the
possibility of reuse. WMC is a predictor of how much time and effort is required
to develop and maintain the class. A large number of methods also means a
greater potential impact on derived classes, since the derived classes inherit
(some of) the methods of the base class. Search for high WMC values to spot
classes that could be restructured into several smaller classes
The deeper a class is in the hierarchy, the more methods and variables it is likely
to inherit, making it more complex. Deep trees as such indicate greater design
complexity. Inheritance is a tool to manage complexity, really, not to not increase
it. As a positive factor, deep trees promote reuse because of method inheritance.
NOC equals the number of immediate child classes derived from a base class. In Visual Basic .NET
one uses the Inherits statement to derive sub-classes. In classic Visual Basic inheritance is not
available and thus NOC is always zero.
A high NOC, a large number of child classes, can indicate several things:
Two classes are coupled when methods declared in one class use methods or instance variables
defined by the other class. The uses relationship can go either way: both uses and used-by
relationships are taken into account, but only once.
78
RFC and RFC´ Response for a Class
The response set of a class is a set of methods that can potentially be executed in response to a
message received by an object of that class. RFC is simply the number of methods in the set.
A given method is counted only once in R (and R’) even if it is executed by several methods M.
The 6th metric in the Chidamber & Kemerer metrics suite is LCOM (or LOCOM), the lack of
cohesion of methods. This metric has received a great deal of critique and several alternatives
have been developed. In Project Metrics we call the original Chidamber & Kemerer metric LCOM1
to distinguish it from the alternatives.
MODULE 5-
Best Practices
Design patterns have been evolved over a long period of time and they provide
best solutions to certain problems faced during software development. Learning
these patterns helps unexperienced developers to learn software design in an
easy and faster way.
Types of Design Patterns
As per the design pattern reference book Design Patterns - Elements of Reusable
Object-Oriented Software , there are 23 design patterns which can be classified
in three categories: Creational, Structural and Behavioral patterns. We'll also
discuss another category of design pattern: J2EE design patterns.
1 Creational Patterns
These design patterns provide a way to create objects while hiding
the creation logic, rather than instantiating objects directly using
new operator. This gives program more flexibility in deciding which
objects need to be created for a given use case.
2 Structural Patterns
These design patterns concern class and object composition.
Concept of inheritance is used to compose interfaces and define
ways to compose objects to obtain new functionalities.
3 Behavioral Patterns
These design patterns are specifically concerned with
communication between objects.
4 J2EE Patterns
These design patterns are specifically concerned with the
presentation tier. These patterns are identified by Sun Java Center.
80
-
A set of components(eg: a database, computational modules) that will
perform a function required by the system.
- The set of connectors will help in coordination, communication, and
cooperation between the components.
- Conditions that how components can be integrated to form the system.
- Semantic models that help the designer to understand the overall properties
of the system.
- The use of architectural styles is to establish a structure for all the
components of the system.
TAXONOMY OF ARCHITECTURAL STYLES:
81
- This kind of architecture is used when input data to be transformed into
output data through a series of computational manipulative components.
- The figure represents pipe-and-filter architecture since it uses both pipe and
filter and it has a set of components called filters connected by pipes.
- Pipes are used to transmit data from one component to the next.
- Each filter will work independently and is designed to take data input of a
certain form and produces data output to the next filter of a specified form.
The filters don’t require any knowledge of the working of neighboring
filters.
- If the data flow degenerates into a single line of transforms, then it is termed
as batch sequential. This structure accepts the batch of data and then
applies a series of sequential components to transform it.
Advantage of Data Flow architecture
Advantages of DataFlow Architecture:
- It encourages upkeep, repurposing, and modification.
- With this design, concurrent execution is supported.
Disadvantage of Data Flow architecture
Disadvantages of DataFlow Architecture:
- It frequently degenerates to batch sequential system
- Data flow architecture does not allow applications that require greater user
engagement.
- It is not easy to coordinate two different but related streams
82
invoke other components.
2. LAYERED ARCHITECTURE:
- A number of different layers are defined with each layer performing a
well-defined set of operations. Each layer will do some operations that
becomes closer to machine instruction set progressively.
- At the outer layer, components will receive the user interface
operations and at the inner layers, components will perform the
operating system interfacing(communication and coordination with
OS)
- Intermediate layers to utility services and application software
functions.
- One common example of this architectural style is OSI-ISO (Open
Systems Interconnection-International Organisation for
Standardisation) communication system.
83
• GRASP
•
General Responsibility Assignment Software Patterns (or
Principles), abbreviated
• GRASP, consists of guidelines for assigning responsibility to
classes and objects in object-oriented design.
•
• The different patterns and principles used in GRASP are:
Information Expert, Creator, Controller, Low Coupling, High
Cohesion, Polymorphism, Pure Fabrication, Indirection, Protected
Variations. All these patterns answer some software problem,
and in almost every case these problems are common to almost
every software development project. These techniques have not
been invented to create new ways of working but to better
document and standardize old, tried-and-tested programming
principles in object oriented design.
•
• It has been said that "the critical design tool for software
development is a mind well educated in design principles. It is
not the UML or any other technology". Thus, GRASP is really a
mental toolset, a learning aid to help in the design of object
oriented software.
Creator
Creation of objects is one of the most common activities in an
object-oriented system. Which class is responsible for creating
objects is a fundamental property of the relationship between
objects of particular classes.
84
Instances of B have the initializing information for instances of A
and pass it on creation.
INFORMATION EXPERT
LOW COUPLING
CONTROLLER
High Cohesion
High Cohesion is an evaluative pattern that attempts to keep objects
appropriately focused, manageable and understandable. High
cohesion is generally used in support of Low Coupling.
Polymorphism
Pure Fabrication
Indirection
86
The Indirection pattern supports low coupling (and reuse
potential) between two elements by assigning the responsibility
of mediation between them to an intermediate object. An
example of this is the introduction of a controller component for
mediation between data (model) and its representation (view) in
the Model-view-controller pattern.
Protected Variations
VISIBILITY
87
may add additional visibilities, or it may not support the UML-
defined visibilities
+ Public
# Protected
- Private
~ Package
88
for some mysterious reason. The Gang of Four describes 23
design patterns.
With patterns you don't have to reinvent the wheel and get proven
solutions for frequently encountered problems. Many books and
articles have been written on this subject. This means that design
patterns are becoming common knowledge, which leads to better
communication. To summarize design patterns save time, energy
while making your life easier.
Singleton
The singleton pattern deals with situations where only one instance of
a class must be created. Take the case of a system administrator or
superuser. This person has the right to do everything in a computer
system. In addition we will also have classes representing normal
users. Therefore we must ensure that these classes have no access to
the super user constructor. The solution to this problem in C++ and
Java is to declare the superuser constructor private.
The super user class itself has a private static attribute sysadmin,
which is initialised using the class constructor. Now we get an
instance of the super user class with a public static method that
returns sysadmin. Here is the class diagram:
Factory Method
Adapter
Sometimes it will have two classes that can in principle work well
together, but they can't interface with each other for some
reason. This kind of problem occurs when travelling abroad and
you carry an electric shaver with you.
Although it will work perfectly when you are at home. There can
be problems in a foreign country, because of a different standard
voltage. The solution is to use an adapter. Let's turn our
attention back to the software domain. Here we will have an
interface which defines new methods for example getElectricity2.
An adapter class will wrap around the Shaver class. The adapter
class will implement the interface with the new method.
90
Proxy
The stub acts as a body double. This is the strategy used by the
Java Remote Method Invocation API. The reason to use the proxy
pattern in this case is that the object is on a remote server
causing network overhead. Other reasons to use the proxy can be
restricted access (Java applets for example) or time consuming
calculations.
Decorator
91
the Decorator pattern is to add or improve the capabilities of the
super class.
Composite
92
HTML in the client's browser and we will have a Servlets as
Controllers.
Template
In the good old days before OOP writing functions was the
recommended thing to do. A sort algorithm would be implement
by half dozen of functions, one sort function for integers, one
sort function for floating points, one sort function for doubles
etc.
93
Strategy
Summary
94
3. Improve communication
1. Erich Gamma
2. Ralph Johnson
95
3. John Vlissides
4. Richard Helm
Overview
I am not gonna describe complete book here but a small picture to
develop your interest in reading this book.
1. Creational Patterns
2. Structural Patterns
3. Behavioral Patterns
96
• Factory Method: Define an interface for creating an object, but
let subclasses decide which class to instantiate. Factory Method
lets a class defer instantiation to subclasses.
97
• Facade: Provide a unified interface to a set of interfaces in a
subsystem. A facade defines a higher-level interface that makes
the subsystem easier to use.
98
• Mediator: Define an object that encapsulates how a set of
objects interact. Mediator promotes loose coupling by keeping
objects from referring to each other explicitly, and it lets you
vary their interaction independently.
• State: Allow an object to alter its behavior when its internal state
changes. The object will appear to change its class
99
CASE support
1. Diagramming Tools:
It helps in diagrammatic and graphical representations of the data and
system processes. It represents system elements, control flow and data
flow among different software components and system structure in a
pictorial form.
For example, Flow Chart Maker tool for making state-of-the-art
flowcharts.
3. Analysis Tools:
It focuses on inconsistent, incorrect specifications involved in the
diagram and data flow. It helps in collecting requirements,
100
automatically check for any irregularity, imprecision in the diagrams,
data redundancies or erroneous omissions.
For example,
• (i) Accept 360, Accompa, CaseComplete for requirement
analysis.
4. Central Repository:
It provides the single point of storage for data diagrams, reports and
documents related to project management.
5. Documentation Generators:
It helps in generating user and technical documentation as per
standards. It creates documents for technical users and end users.
For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
6. Code Generators:
It aids in the auto generation of code, including definitions, with the
help of the designs, documents and diagrams.
101
• Learning Curve: In most cases, programmers productivity may fall in
the initial phase of implementation , because user need time to learn
the technology. Many consultants offer training and on-site services
that can be important to accelerate the learning curve and to the
development and use of the CASE tools.
• Tool Mix: It is important to build an appropriate selection tool mix to
urge cost advantage CASE integration and data integration across all
platforms is extremely important.
102