UNIT III [14T] MODELING WITH UML: Concepts and Diagrams - Use Case Diagrams -

Class Diagrams - Interaction Diagrams - State chart Diagrams – Activity Diagrams - Package
Diagrams - Component Diagrams - Deployment Diagrams - Diagram Organization- Diagram
Extensions. Design Process- Design concepts: Abstraction, Architecture, patterns, Separation
of Concerns, Modularity, Information Hiding, Functional Independence, Refinement, Aspects,
Refactoring, Object Oriented Design Concepts, Design Classes- Design Model: Data,
Architectural, Interface, Component, Deployment Level Design Elements.

Introduction to UML

The Unified Modelling Language (UML) is a general-purpose, developmental, modelling

language for specifying, visualizing, constructing and documenting the artefacts of a software
system to visualize its design in a standard way.
UML offers a way to visualize a system’s architectural blueprints in a diagram, including
elements such as:
• Any activities (jobs)
• Individual components of the system and how they can interact with other software
components
• How the system will run
• How entities interact with others (components and interfaces)
• External user interface.

UML defines various kinds of diagrams to cover most of the aspects of a system. You can also
create your own set of diagrams to meet your requirements. Diagrams are generally made in
an incremental and iterative way. There are two broad categories of diagrams and they are
again divided into subcategories –
• Structural diagrams: The structural diagrams represent the static aspect of the
system. These static aspects represent those parts of a diagram, which forms the main
structure and are therefore stable. These static parts are represented by classes,
interfaces, objects, components, and nodes. It includes class diagrams, deployment
diagram and package diagrams, etc.

• Behavioral diagrams: Behavioral diagrams basically capture the dynamic aspect of

a system. Dynamic aspect can be further described as the changing/moving parts of a
system. It includes sequence diagrams, activity diagrams and state machine diagrams,
etc.
 Use Case Diagrams
This diagram is used to model the system or subsystem of an application. Use case diagrams
are drawn to capture the functional requirements of a system. A single use case diagram
captures a particular functionality of a system. The purpose of use case diagram is to get an
outside view of a system, gather the requirements and show the interaction among the
requirements of a system. It identifies the external and internal factors influencing the system.
The elements of a use case diagram include:

No Name Notation Description

1 System The scope of a system can be represented by
boundary
a system boundary. The use cases of the
system are placed inside the system
boundary, while the actors who interact with
the system are put outside the system. The
use cases in the system make up the total
requirements of the system.
2 Use case A use case represents a user goal that can be
achieved by accessing the system or software
application.
 3 Actor Actors are the entities that interact with a
system. Although in most cases, actors are
used to represent the users of system, actors
can actually be anything that needs to
exchange information with the system. So an
actor may be people, computer hardware,
other systems, etc. Note that actor represent a
role that a user can play, but not a specific
user.
4 Association Actor and use case can be associated to
indicate that the actor participates in that use
case. Therefore, an association corresponds
to a sequence of actions between the actor
and use case in achieving the use case.

6 Include An include relationship specifies how the

behavior for the inclusion use case is inserted into
the behavior defined for the base use case.
Example 1, Use case diagram of student management system

Example 2 :
 Class diagram
The class diagram is a static diagram.A class diagram describes the structure of a system in
terms of the classes that exist within the system by characterizing the objects in the system,
the relationship between the objects, and the attributes and operations for each class of objects.
Class diagram provide a graphical notation for modeling classes and their relationship.They are
concise, easy to understand, and work well in practice.
The main elements of a class diagram are boxes, which are the icons used to represent classes
and interfaces. Each box is divided into horizontal parts. The top part contains the name of the
class. The middle section lists the attributes of the class. An attribute refers to something that
an object of that class knows or can provide all the time. Attributes are usually implemented as
fields of the class. The third part represents operations. An operation refers to what objects of
the class can do. It is usually implemented as a method of the class. Each attribute can have a
name, a type, and a level of visibility. The type and visibility are optional. The type follows the
name and is separated from the name by a colon. The visibility is indicated by a preceding –,
#, ~, or +, indicating private, protected, package, or public respectively.
Example for class:

Class diagrams also provide provisions for representing other forms of relations like
inheritance, dependencies, aggregation and composition. Some of the relationships which can
be represented in a class diagram are:
Sr. Name Symbol Meaning
No.
1 Association An association represents
the relationship that exist
between various classes

2 Multiplicity Ex. 1 to 1 Multiplicity specifies the

number of instances of one
1 to *
class that may relate to a
* to * single instance of an
associated class.
* to 1
It is a constraint on the
1 to 0... 2 cardinality of a set.
 3 generalization Generalization organizes
classes by their super- class
and sub-class relationship.

4 aggregation It is a strong form of

association in which an
aggregate object is madeof
constituent parts.

The symbols used for different types of relationship are:

An abstract class or abstract method is indicated by the use of italics for the name in the class
diagram. A class that is a subclass of another class is connected to it by an arrow with a solid
line for its shaft and with a triangular hollow arrowhead. The arrow points from the subclass to
the superclass. In UML, such a relationship is called a generalization. An interface is
indicated by adding the phrase ―«interface»‖ (called a stereotype) above the name. An
interface can also be represented graphically by a hollow circle.
An association between two classes means that there is a structural relationship between them.
Associations are represented by solid lines. An association has many optional parts. It can be
labeled, as can each of its ends, to indicate the role of each class in the association. A
dependency relationship represents another connection between classes and is indicated by a
dashed line (with optional arrows at the ends and with optional labels). One class depends on
another if changes to the second class might require changes to the first class The multiplicity
of one end of an association means the number of objects of that class associated with the other
class. A multiplicity is specified by a nonnegative integer or by a range of integers. A
multiplicity specified by ―0..1 means that there are 0 or 1 objects on that end of the association.
An aggregation is a special kind of association indicated by a hollow diamond on one end of
the icon. It indicates a ―whole/part relationship, in that the class to which the arrow points is
considered a ―part of the class at the diamond end of the association. A composition is an
aggregation indicating strong ownership of the parts. Another common element of a class
diagram is a note, which is represented by a box with a dog-eared corner and is connected to
other icons by a dashed line. It can have arbitrary content (text and graphics) and is similar to
comments in programming languages.
Example,

Interaction diagrams
The interaction diagram is used to describe some type of interactions among the different
elements in the model. This interaction is a part of dynamic behaviour of the system. The
purpose of interaction diagram is to
• describe the message flow in the system
• describe structural organization of the objects
• describe interaction among objects
• capture the dynamic behaviour of a system.
Interaction diagrams can be used
• to model the flow of control by time sequence
 • to model the flow of control by structural organizations.
The following things are to be identified clearly before drawing the interaction diagram:
• Objects taking part in the interaction
• Message flows among the objects.
• The sequence in which the messages are flowing
• Object organization.
The interactive behavior is represented in UML by four diagrams. They are:
1. Sequence diagram
UML sequence diagrams are interaction diagrams that capture the interaction between
objects in a sequential order i.e., the order in which these interactions take place.
Sequence diagram emphasizes on time sequence of messages. It is used to capture the
order of messages flowing from one object to another. Message flow means the
sequence of control flow from one object to another. These diagrams are useful to
represent the details of a UML use case. Sequence diagrams are sometimes known as
event diagrams or event scenarios. The sequence diagram does not describe the object
organization. If the time sequence is important, then the sequence diagram is used.
There are many other special features that can be included in a sequence diagram.
1. You can distinguish between synchronous and asynchronous messages.
Synchronous messages are shown with solid arrowheads while asynchronous messages
are shown with stick arrowheads.
2. You can show an object sending itself a message with an arrow going out from the
object, turning downward, and then pointing back to the same object.
3. You can show object creation by drawing an arrow appropriately labeled (for
example, with a «create» label) to an object’s box. In this case, the box will appear
lower in the diagram than the boxes corresponding to objects already in existence when
the action begins.
4. You can show object destruction by a big X at the end of the object’s lifeline. Other
objects can destroy an object, in which case an arrow points from the other object to
the X. An X is also useful for indicating that an object is no longer usable and so is
ready for garbage collection.
Sequence diagram notations:
1. Lifelines represent an individual participant within an interaction. Lifelines are
represented by vertical dashed lines, connecting at
the top to an object or actor
 2. Actors represent the user, external hardware or other subject setting off a particular
sequence. They often appear as a stick figure icon and are placed to the left of the first
object on the horizonal axis.

3. Activation bars/ Activation box -- sometimes called focus of control -- are thin
rectangular boxes that sit vertically on top of an object's lifeline to indicate the
duration of a particular operation.

4. Messages /Call message represent communication from one actor or object to

another. The first message typically starts at the top left of the sequence diagram and
moves horizontally across lifelines from left to right, with each subsequent message
one step lower than the one before.

5. Acknowledgement / Return message : It is a kind of message that represents the pass

of information back to the caller of a corresponded former message.
<----------------------

6. Object : To represent an object /class. It is to be noted that an object should be

represented with an object name.

Bank server

7. Alternative symbol : It symbolizes a choice between two or more message sequences.

To represent alternatives, use the labelled rectangle shape with a dashed line inside.

Example for sequence diagram : ATM transaction

2. Collaboration diagram
UML collaboration diagrams (also known as communication diagrams), like the
sequence diagrams, is a kind of interaction diagram, that shows how objects interact.
The collaboration diagrams offer benefits similar to sequence diagrams, but they will
offer a better understanding of how components communicate and interact with each
other rather than solely emphasizing the sequence of events. It emphasizes on the
structural organization of the objects that send and receive messages. Structural
organization means the visual organization of the elements in a system. In the
collaboration diagram, the method call sequence is indicated by some numbering
technique. The number indicates how the methods are called one after another. These
diagram shows the object organization. If organization is required, then collaboration
diagram is used.

3. Timing diagram
In UML, the timing diagrams are a part of Interaction diagrams that do not incorporate
similar notations as that of sequence and collaboration diagram. It consists of a graph
or waveform that depicts the state of a lifeline at a specific point of time. It illustrates
how conditions are altered both inside and between lifelines alongside linear time axis.
The timing diagram describes how an object underwent a change from one form to
 another. A waveform portrays the flow among the software programs at several
instances of time.

4. Interaction overview diagram

Interaction Overview Diagram is one of the diagrams of the Unified Modeling
Language (UML), which can picture a control flow with nodes that can contain
interaction diagrams. The interaction overview diagram is similar to the activity
diagram, in that both visualize a sequence of activities. The difference is that, for an
interaction overview, each individual activity is pictured as a frame which can contain
a nested interaction diagram. This makes the interaction overview diagram useful to
"deconstruct a complex scenario that would otherwise require multiple if-then-else
paths to be illustrated as a single sequence diagram".

Activity diagram
An activity diagram is a type of flow chart with additional support for parallel behavior. This
diagram explains overall flow of control. Activity diagram is another important diagram in
UML to describe dynamic aspects of the system. Activity diagram represents the flow from
one activity to another activity. It is similar to a flowchart except that an activity diagram can
show concurrent flows.The activity can be described as an operation of the system. The control
flow is drawn from one operation to another. This flow can be sequential, branched or
concurrent. This distinction is important for a distributed system. Activity diagrams deals with
all type of flow control by using different elements like fork, join etc.
Activity diagram notations:
No. Name Symbol Description
1. Activity / The main component of an activity
Action node Activity diagram is an action node, represented
by a rounded rectangle,Represent
individual activity of system.
2. Transition Represents flow of data from one
activity to
another.
3. Decision Decision node is a control node that accepts
tokens on one or more incoming edges and
selects outgoing edge from two or more
outgoing flows. The notation for a decision
node is a diamond-shaped symbol.
4. Initial activity Initial node is a control node at which flow
starts when the activity is invoked. Activity
may have more than one initial node. Initial
nodes are shown as a small solid circle.
 5. Final activity Final node is a control final node that stops
all flows in an activity. Activity final nodes
are shown as a solid circle with a hollow
circle inside.

6. Fork A fork in the activity diagram has a single

incoming transition and multiple outgoing
transitions exhibiting parallel behavior. The
incoming transition triggers the parallel
outgoing transitions.
7. Join A join in the activity diagram synchronizes
the parallel behavior started at a fork. Join
ascertains that all the parallel sets of
activities (irrespective of the order) are
completed before the next activity starts. It
is a synchronization point in the diagram.
Each fork in an activity diagram has a
corresponding join where the parallel
behavior
terminates.
If you do want to indicate how the actions are divided among the participants, you can decorate
the activity diagram with swimlanes. Swimlanes, as the name implies, are formed by dividing
the diagram into strips or ―lanes, each of which corresponds to one of the participants. All
actions in one lane are done by the corresponding participant
Example:
 State chart diagram
State chart diagrams also referred to as state machine and state diagram. A state diagram is
a graph in which nodes correspond to states and directed arcs correspond to transitions
labeled with event names. A state diagram is a graph whose nodes are states and whose
directed arcs are transitions between states. The behavior of an object at a particular point in
time often depends on the state of the object, that is, the values of its variables at that time.
A UML state diagram models an object’s states, the actions that are performed depending on
those states, and the transitions between the states of the object
.A state diagram specifies the state sequence caused by event sequence. State names must be
unique within the scope of a state diagram. All objects in a class execute the state diagram
for that class, which models their common behavior. We can implement state diagrams by
direct interpretation or by converting the semantics into equivalent programming code.
State chart diagram describes dynamic behavior of the objects of the system. It specifies
the possible states, what transitions are allowed between states.
State diagram notations:

No. Name Notation Description

1 State A state diagram displays states using rounded

State
rectangles, each of which has a name in its
upper half. State models a situation during
which some (usually implicit) invariant
condition holds.
2 Transition A transition is a directed relationship between
a source state and a target state. Arrows from
one state to another state indicate transitions
or changes in the state of the object. It takes
the state machine from one state configuration
to another
3 Event A transition is an instantaneous change from
one to another state
Event
4 Initial state There is a black circle called the
point
―initial pseudo state. It shows the
starting state of object.
 5 Final state It shows the terminating state of object.
point

Example:

Package diagram
Package diagrams are structural diagrams used to show the organization and arrangement of
various model elements in the form of packages. A package is a grouping of related UML
elements, such as diagrams, documents, classes, or even other packages. Each element is nested
within the package, which is depicted as a file folder within the diagram, then arranged
hierarchically within the diagram. Package diagrams are most commonly used to provide a
visual organization of the layered architecture within any UML classifier, such as a software
system. A well-designed package diagram provides numerous benefits to those looking to
create a visualization of their UML system or project.
They provide a clear view of the hierarchical structure of the various UML elements within a
given system. These diagrams can simplify complex class diagrams into well-ordered visuals.
Each diagram includes the following :
• Packages appear as rectangles with small tabs at the top.
• The package name is on the tab or inside the rectangle.
• The dotted arrows are dependencies.
• One package depends on another if changes in the other could possibly force changes
in the first.
A package in the Unified Modelling Language helps:
• To group elements
 • To provide a namespace for the grouped elements
• A package may contain other packages, thus providing for a hierarchical organization
of packages.
Packages can be represented by the notations as shown below:

There are two sub-types involved in dependency. They are <<import>> & <<access>>.
<<import>>- one package imports the functionality of other package.

<<access>> - one package requires help from functions of other package.

Example for package diagram:

 Component diagrams
Component diagram is used to break down a large object-oriented system into the smaller
components, so as to make them more manageable. It models the physical view of a system
such as executables, files, libraries, etc. that resides within the node. It visualizes the
relationships as well as the organization between the components present in the system. It helps
in forming an executable system.
A component is a single unit of the system, which is replaceable and executable. The
implementation details of a component are hidden, and it necessitates an interface to execute a
function.
The following symbols are used in component diagram:
Component: It is a logical unit block of the system, a slightly higher abstraction than classes.
It is represented as a rectangle with a smaller rectangle in the upper right corner with tabs or
the word written above the name of the component to help distinguish it from a class.

Interface: An interface describes a group of operations used (required) or created (provided)

by components.

• Provided interface : A complete circle represent an interface that the component

provides. It is the service providing interface
• Required interface with only a half circle at the their end ( also known as sockets)
represent an interface that the component requires. It is the service receiving interface.
Dependencies : Draw dependencies among components using dashed arrows.
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.
Example:
Component diagram for online shopping system

Deployment diagram

It is a type of structural diagram. 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.
The main purpose of the deployment diagram is to represent how software is installed on the
hardware component. It depicts in what manner a software interacts with hardware to perform
its execution.
The deployment diagram does not focus on the logical components of the system, but it put its
attention on the hardware topology.
The following figure shows the deployment diagram for a package. In such a diagram,
hardware components are drawn in boxes labeled with “«device»”. Communication paths
between hardware components are drawn with lines with optional labels. The paths are
labeled with the communication protocol and the type of network used to connect the devices.
Each node in a deployment diagram can also be annotated with details about the device. For
example, in the Figure the browser client is depicted to show that it contains an artifact
consisting of the Web browser software.
An artifact is typically a file containing software running on a device. You can also specify
tagged values, as is shown in Figure in the Web server node. These values define the vendor
of the Web server and the operating system used by the server. Deployment diagrams can also
display execution environment nodes, which are drawn as boxes containing the label
“«execution environment»”. These nodes represent systems, such as operating systems, that
can host other software.
 Diagram organization
Models of complex systems quickly become complex as developers refine them. UML model
management provides a mechanism for diagram organization to deal with the complexity of
the models. They are:
1. Packages
• It is a mechanism for grouping of logically related UML elements.
• A package is a piece of model. Every part of a model must belong to one
package.
• UML does not impose a rule for composing packages, but a good decomposition
into packages will greatly enhance model maintainability.
• Packages contain top level model elements such as classes and their
relationships, state machines, use case graphs, interactions, and collaborations
• Packages may contain other packages.
• Packages are general purpose hierarchial organizational units of UML models
• They can be used for storage, access control,configuration management etc.
• A package is shown as a large rectangle with a small rectangle attached on one
corner
2. Dependencies on packages
• Dependencies arise among individual elements.
• Dependencies among packages summarize dependencies among elments in
them.
• Packages are drawn as rectangles with tabs on them. Dependencies are shown
as dashed arrows.
• A package cannot access the contents of another package. Packages are opaque
unless they are opened by an access or import dependency.
• The access dependency applies directly to packages and other containers.
• The import dependency is used to add names to the namespace of the client
package as aliases for the full pathnames.
 Diagram extensions
The extensibility mechanisms allow you to customize and extend the UML by adding new
building blocks, creating new properties and specifying new semantics in order to make the
language suitable for your specific problem domain. There are three extensibility mechanisms
that are defined by the UML:
1. Constraints
A constraint is a semantic restriction represented as a text expression. Constraints
specify semantics and/or conditions that must be held true at all times for the elements
of a model. Constraints can express restrictions and relationships that cannot be
expressed using UML notations. These are shown as the expression strings enclosed in
braces.

2. Tagged value
Tagged values or meta attributes are used to extend the properties of UML building
block so that you can add additional information in the specification of a model element.
Tagged values are shown in the form: tag=value where tag is the tag name and value
is a literal value.

3. Stereotypes
A stereotype is based on an existing element. The information content of the
stereotyped element is same as the existing model element. This permits a tool to store
and manipulate the new element the same way it does the existing element.
A stereotype is rended as a name enclosed by guillemets (<< >>) and placed above the
name of another element.

SOFTWARE DESIGN
Software design encompasses the set of principles, concepts, and practices that lead to the
development of a high-quality system or product. Design is pivotal to successful software
engineering. Design allows you to model the system or product that is to be built. This model
can be assessed for quality and improved before code is generated, tests are conducted, and end
users become involved in large numbers. Design is the place where software quality is
established. A design model that encompasses architectural, interface, component level, and
deployment representations is the primary work product that is produced during software
design. Beginning once software requirements have been analyzed and modeled, software
design is the last software engineering action within the modeling activity and sets the stage
for construction (code generation and testing).
The requirements model, manifested by scenario-based, class-based, flow-oriented, and
behavioral elements, feed the design task. Design produces a data/class design, an architectural
design, an interface design, and a component design. The data / class design transforms class
models into design class realizations and the requisite data structures required to implement
the software. The objects and relationships defined in the CRC diagram.
The architectural design defines the relationship between major structural elements of the
software, the architectural styles and design patterns that can be used to achieve the
requirements defined for the system, and the constraints that affect the way in which
architecture can be implemented.
The interface design describes how the software communicates with systems that interoperate
with it, and with humans who use it. An interface implies a flow of information (e.g., data
and/or control) and a specific type of behavior.
The component-level design transforms structural elements of the software architecture into a
procedural description of software components. Information obtained from the class-based
models, flow models, and behavioral models serve as the basis for component design.
The importance of software design can be stated with a single word—quality.

Design process
Software design is an iterative process through which requirements are translated into a
“blueprint” for constructing the software. Initially, the blueprint depicts a holistic view of
software. That is, the design is represented at a high level of abstraction— a level that can be
directly traced to the specific system objective and more detailed data, functional, and
behavioral requirements. As design iterations occur, subsequent refinement leads to design
representations at much lower levels of abstraction.
Software Quality Guidelines and Attributes
Throughout the design process, the quality of the evolving design is assessed with a series of
technical reviews. McGlaughlin [McG91] suggests three characteristics that serve as a guide
for the evaluation of a good design:
• The design must implement all of the explicit requirements contained in the requirements
model, and it must accommodate all of the implicit requirements desired by stakeholders.
• The design must be a readable, understandable guide for those who generate code and for
those who test and subsequently support the software.
• The design should provide a complete picture of the software, addressing the data, functional,
and behavioral domains from an implementation perspective.

Quality Guideline
In order to evaluate the quality of a design representation, the members of the software team
must establish technical criteria for good design. The guidelines are:
1. A design should exhibit an architecture that
(1) has been created using recognizable architectural styles or patterns,
(2) is composed of components that exhibit good design characteristics , and
(3) can be implemented in an evolutionary fashion,2 thereby facilitating implementation
and testing.
2. A design should be modular; that is, the software should be logically partitioned into
elements or subsystems.
3. A design should contain distinct representations of data, architecture, interfaces, and
components
4. A design should lead to data structures that are appropriate for the classes to be implemented
and are drawn from recognizable data patterns.
5. A design should lead to components that exhibit independent functional characteristics.
6. A design should lead to interfaces that reduce the complexity of connections between
components and with the external environment.
7. A design should be derived using a repeatable method that is driven by information obtained
during software requirements analysis.
8. A design should be represented using a notation that effectively communicates its meaning
Quality Attributes.
Hewlett-Packard [Gra87] developed a set of software quality attributes that has been given the
acronym FURPS—functionality, usability, reliability, performance, and supportability. The
FURPS quality attributes represent a target for all software design:
• Functionality is assessed by evaluating the feature set and capabilities of the program, the
generality of the functions that are delivered, and the security of the overall system
• Usability is assessed by considering human factors, overall aesthetics, consistency, and
documentation.
• Reliability is evaluated by measuring the frequency and severity of failure, the accuracy of
output results, the mean-time-to-failure (MTTF), the ability to recover from failure, and the
predictability of the program.
• Performance is measured by considering processing speed, response time, resource
consumption, throughput, and efficiency.
• Supportability combines the ability to extend the program (extensibility), adaptability,
serviceability—these three attributes represent a more common term, maintainability—and in
addition, testability, compatibility, configurability (the ability to organize and control elements
of the software configuration), the ease with which a system can be installed, and the ease with
which problems can be localized.

Design concepts
The software design concepts that span both traditional and object-oriented software
development are:
Abstraction
When you consider a modular solution to any problem, many levels of abstraction can be posed.
At the highest level of abstraction, a solution is stated in broad terms using the language of the
problem environment. At lower levels of abstraction, a more detailed description of the solution
is provided.

• A procedural abstraction refers to a sequence of instructions that have a specific and

limited function. The name of a procedural abstraction implies these functions, but
specific details are suppressed.
• A data abstraction is a named collection of data that describes a data object.
Architecture
Architecture is the structure or organization of program components (modules), the manner in
which these components interact, and the structure of data that are used by the components.
A set of properties that should be specified as part of an architectural design are:
 • Structural properties: This aspect of the architectural design representation defines the
components of a system (e.g., modules, objects, filters) and the manner in which those
components are packaged and interact with one another.
• Extra-functional properties: The architectural design description should address how
the design architecture achieves requirements for performance, capacity, reliability,
security, adaptability, and other system characteristics.
• Families of related systems: The architectural design should draw upon repeatable
patterns that are commonly encountered in the design of families of similar systems. In
essence, the design should have the ability to reuse architectural building blocks.
The architectural design can be represented using one or more of a number of different
models [Gar95].

• Structural models represent architecture as an organized collection of program

components.
• Framework models increase the level of design abstraction by attempting to
identify repeatable architectural design frameworks that are encountered in similar
types of applications.
• Dynamic models address the behavioral aspects of the program architecture,
indicating how the structure or system configuration may change as a function of
external events.
• Process models focus on the design of the business or technical process that the
system must accommodate.
• Functional models can be used to represent the functional hierarchy of a system
A number of different architectural description languages (ADLs) have been developed to
represent these models.
Patterns
A design pattern describes a design structure that solves a particular design problem within a
specific context and amid “forces” that may have an impact on the manner in which the pattern
is applied and used. The intent of each design pattern is to provide a description that enables a
designer to determine (1) whether the pattern is applicable to the current work, (2) whether the
pattern can be reused (hence, saving design time), and (3) whether the pattern can serve as a
guide for developing a similar, but functionally or structurally different pattern.
Separation of concerns
Separation of concerns is a design concept that suggests that any complex problem can be more
easily handled if it is subdivided into pieces that can each be solved and/or optimized
independently. A concern is a feature or behavior that is specified as part of the requirements
model for the software. By separating concerns into smaller, and therefore more manageable
pieces, a problem takes less effort and time to solve. It also follows that the perceived
complexity of two problems when they are combined is often greater than the sum of the
perceived complexity when each is taken separately. This leads to a divide-and-conquer
strategy—it’s easier to solve a complex problem when you break it into manageable pieces.
Modularity
Modularity refers to the extent to which a software application may be divided into smaller
modules. It is used primarily to reduce complexity by breaking a software system into multiple
discrete and independent modules, which are expected to be capable of carrying out tasks
independently. It is a practical application of the principle of “ separation of concerns” by
diving complex system into simpler and more manageable modules. There are many
advantages to using modularization, including:

• Development can be divided

• Readable programs
• Programming errors are easy to detect
• Allows reuse of codes
• Improves manageability
• Collaboration
Information hiding
The principle of information hiding suggests that modules be “characterized by design
decisions that (each) hides from all others.” In other words, modules should be specified and
designed so that information (algorithms and data) contained within a module is inaccessible
to other modules that have no need for such information. Hiding implies that effective
modularity can be achieved by defining a set of independent modules that communicate with
one another only that information necessary to achieve software function. The use of
information hiding as a design criterion for modular systems provides the greatest benefits
when modifications are required during testing and later during software maintenance. Because
most data and procedural detail are hidden from other parts of the software, inadvertent errors
introduced during modification are less likely to propagate to other locations within the
software.
Functional independence
The concept of functional independence is a direct outgrowth of separation of concerns,
modularity, and the concepts of abstraction and information hiding. Functional independence
is achieved by developing modules with “single minded” function and an “aversion” to
excessive interaction with other modules. Stated another way, you should design software so
that each module addresses a specific subset of requirements and has a simple interface when
viewed from other parts of the program structure. Functional independence is a key to good
design, and design is the key to software quality.
Independence is assessed using two qualitative criteria: cohesion and coupling. Cohesion is an
indication of the relative functional strength of a module. Coupling is an indication of the
relative interdependence among modules. Cohesion is a qualitative indication of the degree to
which a module focuses on just one thing. Coupling is a qualitative indication of the degree to
which a module is connected to other modules and to the outside world.
Cohesion is a natural extension of the information-hiding concept. A cohesive module performs
a single task, requiring little interaction with other components in other parts of a program.
Stated simply, a cohesive module should (ideally) do just one thing. Although you should
always strive for high cohesion (i.e., single-mindedness), it is often necessary and advisable to
have a software component perform multiple functions. However, “schizophrenic”
components (modules that perform many unrelated functions) are to be avoided if a good
design is to be achieved. Coupling is an indication of interconnection among modules in a
software structure. Coupling depends on the interface complexity between modules, the point
at which entry or reference is made to a module, and what data pass across the interface. In
software design, you should strive for the lowest possible coupling. Simple connectivity among
modules results in software that is easier to understand and less prone to a “ripple effect” caused
when errors occur at one location and propagate throughout a system.

Refinement
Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth
[Wir71]. A program is developed by successively refining levels of procedural detail. A
hierarchy is developed by decomposing a macroscopic statement of function (a procedural
abstraction) in a stepwise fashion until programming language statements are reached.
Refinement is actually a process of elaboration. You begin with a statement of function (or
description of information) that is defined at a high level of abstraction. That is, the statement
describes function or information conceptually but provides no information about the internal
workings of the function or the internal structure of the information. You then elaborate on the
original statement, providing more and more detail as each successive refinement (elaboration)
occurs. Abstraction and refinement are complementary concepts. Abstraction enables you to
specify procedure and data internally but suppress the need for “outsiders” to have knowledge
of low-level details. Refinement helps you to reveal low-level details as design progresses.
Both concepts allow you to create a complete design model as the design evolves.
Aspects
An aspect is a representation of a crosscutting concern. It is important to identify aspects so
that the design can properly accommodate them as refinement and modularization occur. In an
ideal context, an aspect is implemented as a separate module (component) rather than as
software fragments that are “scattered” or “tangled” throughout many components. To
accomplish this, the design architecture should support a mechanism for defining an aspect—
a module that enables the concern to be implemented across all other concerns that it crosscuts.
Refactoring
Refactoring is a reorganization technique that simplifies the design (or code) of a component
without changing its function or behavior. When software is refactored, the existing design is
examined for redundancy, unused design elements, inefficient or unnecessary algorithms,
poorly constructed or inappropriate data structures, or any other design failure that can be
corrected to yield a better design. For example, a first design iteration might yield a component
that exhibits low cohesion (i.e., it performs three functions that have only limited relationship
to one another). After careful consideration, you may decide that the component should be
refactored into three separate components, each exhibiting high cohesion. The result will be
software that is easier to integrate, easier to test, and easier to maintain.

Object-Oriented Design Concepts

Object oriented design concepts include the following:
1. Inheritance
Inheritance is one of the key differentiators between conventional and object-oriented
systems. A subclass Y inherits all of the attributes and operations associated with its
superclass X. This means that all data structures and algorithms originally designed and
implemented for X are immediately available for Y—no further work need be done.
Reuse has been accomplished directly. Any change to the attributes or operations
contained within a superclass is immediately inherited by all subclasses. Therefore, the
class hierarchy becomes a mechanism through which changes (at high levels) can be
immediately propagated through a system. It is important to note that at each level of
the class hierarchy new attributes and operations may be added to those that have been
inherited from higher levels in the hierarchy.
2. Objects
All entities involved in the solution design are known as objects. For example, person,
banks, company, and users are considered as objects. Every entity has some attributes
associated with it and has some methods to perform on the attributes.

3. Classes
A class is a generalized description of an object. An object is an instance of a class. A
class defines all the attributes, which an object can have and methods, which represents
the functionality of the object.

4. Messages
Objects communicate by message passing. Messages consist of the integrity of the
target object, the name of the requested operation, and any other action needed to
perform the function. Messages are often implemented as procedure or function calls.

5. Polymorphism
OOD languages provide a mechanism where methods performing similar tasks but
vary in arguments, can be assigned the same name. This is known as polymorphism,
which allows a single interface is performing functions for different types. Depending
upon how the service is invoked, the respective portion of the code gets executed.

6. Abstraction
 Abstraction means, showcasing only the required things to the outside world while
hiding the details. The concept of abstraction focuses on what an object does, instated
of how an object is represented or ―how it works.

7. Encapsulation
Encapsulation means that we want to hide unnecessary details from the user.

Design classes
As the design model evolves, you will define a set of design classes that refine the analysis
classes by providing design detail that will enable the classes to be implemented, and
implement a software infrastructure that supports the business solution. Five different types of
design classes, each representing a different layer of the design architecture, can be developed:
• User interface classes define all abstractions that are necessary for human computer
interaction (HCI).
• Business domain classes are often refinements of the analysis classes defined earlier. The
classes identify the attributes and services (methods) that are required to implement some
element of the business domain.
• Process classes implement lower-level business abstractions required to fully manage the
business domain classes.
• Persistent classes represent data stores (e.g., a database) that will persist beyond the
execution of the software.
• System classes implement software management and control functions that enable the system
to operate and communicate within its computing environment and with the outside world.
The four characteristics of a well-formed design class include the following:

• Complete and sufficient : A design class should be the complete encapsulation of all
attributes and methods that can reasonably be expected to exist for the class. The
property sufficiency ensures that the design class contains only those methods that are
sufficient to achieve the intent of the class, no more and no less
• Primitiveness: Methods associated with a design class should be focused on
accomplishing one service for the class. Once the service has been implemented with a
method, the class should not provide another way to accomplish the same thing.
• High cohesion : A cohesive design class has a small, focused set of responsibilities and
single-mindedly applies attributes and methods to implement those responsibilities.
• Low coupling : Within the design model, it is necessary for design classes to
collaborate with one another. However, collaboration should be kept to an acceptable
minimum. If a design model is highly coupled (all design classes collaborate with all
other design classes), the system is difficult to implement, to test, and to maintain over
time.
 Design model
The design model can be viewed in two different dimensions as:

• The process dimension indicates the evolution of the design model as design tasks are
executed as part of the software process
• The abstraction dimension represents the level of detail as each element of the analysis
model is transformed into a design equivalent and then refined iteratively.
The elements of the design model use many of the same UML diagrams that were used in
the analysis model.

The design model has four major elements: data, architecture, components, and interface.
1. Data Design Elements
Data design (sometimes referred to as data architecting) creates a model of data and/or
information that is represented at a high level of abstraction (the customer/user’s view
of data). This data model is then refined into progressively more implementation-
specific representations that can be processed by the computer-based system.
2. Architectural Design Elements
Architectural design elements give us an overall view of the software. The architectural
design element is usually depicted as a set of interconnected subsystems, often derived
from analysis packages within the requirements model. Each subsystem may have it’s
own architecture (e.g., a graphical user interface be structured according to a pre
existing architectural style for user interfaces).
3. Interface Design Elements
The interface design elements for software depict information flows into and out of the
system and how it is communicated among the components defined as part of the
architecture. There are three important elements of interface design: (1) the user
 interface (UI); (2) external interfaces to other systems, devices, networks, or other
producers or consumers of information; and (3) internal interfaces between various
design components. These interface design elements allow the software to
communicate externally and enable internal communication and collaboration among
the components that populate the software architecture. Usability design (UI design)
incorporates aesthetic elements (e.g., layout, color, graphics, interaction mechanisms),
ergonomic elements (e.g., information layout and placement, metaphors, UI
navigation), and technical elements (e.g., UI patterns, reusable components). In general,
the UI is a unique subsystem within the overall application architecture. The design of
external interfaces should incorporate error checking and (when necessary) appropriate
security features. The design of internal interfaces is closely aligned with component-
level design.

4. Component-Level Design Elements

The component-level design for software fully describes the internal detail of each
software component. To accomplish this, the component-level design defines data
structures for all local data objects and algorithmic detail for all processing that occurs
within a component and an interface that allows access to all component operations
(behaviors). Within the context of object-oriented software engineering, a component
is represented in UML diagrammatic form. The design details of a component can be
modeled at many different levels of abstraction. A UML activity diagram can be used
to represent processing logic. Detailed procedural flow for a component can be
represented using either pseudocode (a programming language-like representation or
some other diagrammatic form (e.g., flowchart or box diagram). Algorithmic structure
follows the rules established for structured programming (i.e., a set of constrained
procedural constructs). Data structures, selected based on the nature of the data objects
to be processed, are usually modeled using pseudocode or the programming language
to be used for implementation.

5. Deployment-Level Design Element

Deployment-level design elements indicate how software functionality and subsystems
will be allocated within the physical computing environment that will support the
software. The deployment diagram shows the computing environment but does not
explicitly indicate configuration details. Deployment diagrams begin in descriptor
form, where the deployment environment is described in general terms. Later, instance
form is used and elements of the configuration are explicitly described.

Questions:

• Explain various object-oriented concepts that are needed for conceptual modelling in
UML
• Explain software design concepts
• What is the purpose of class diagram? Explain with example.
• Illustrate deployment diagram with an example
• Explain package diagram with an example
• Explain activity diagram and state diagram
• Differentiate information hiding and functional independence
• Draw a use case diagram for library management system.
• Explain the term modularity
• Explain neatly about different design concepts.