Design activity & its objectives – Function Oriented and Object Oriented Design- Modularization techniques - module structure and its representation, interface and information hiding, categories, specific techniques to accommodate change, stepwise refinement, top-down and bottom-up design - Handling anomalies.

1. 1
Module - IV
Design activity & its objectives – Function Oriented and Object Oriented Design- Modularization
techniques - module structure and its representation, interface and information hiding, categories,
specific techniques to accommodate change, stepwise refinement, top-down and bottom-up
design - Handling anomalies.
1.Software Design
Software design is a process to transform user requirements into some suitable form, which helps
the programmer in software coding and implementation.or Software design is the process of
implementing software solutions to one or more set of problems. One of the important parts
of software design is the software requirements analysis (SRA). It is a part of the
software development process that lists specifications used in software engineering.
Software design has two meanings:
1. It is the activity that bridges the gap between requirements and implementation.
2. It is the activity that gives structure to a software artifact.
Software design is a special case of engineering design.
The output of the software design activity is a software design in the form of a system
decomposition into modules that specifies:
1. The interface and implementation of each module.
2. The relationship the modules have with each other.
Designphase transforms SRS document:
– To a form easily implementable in some programming language.

2. 2
2 Designactivity and its objectives
• Design activity begins when requirement document for the software to be developed is
made available.
• Design of the system is a blueprint or a plan for a solution for the system.
The goal of the design process is to produce a representation of the system, which can be used
later to build that system
What are the steps?
Design begins with the requirements model. We work to transform this model into four
levels of design detail: the data structure, the system architecture, the interface representation, and
the component level detail. During each design activity, we apply basic concepts and principles
that lead to high quality.
Software DesignLevels
A software design is usually composed of several levels of abstraction.
 The data design transforms the information domain model created during analysis into the
data structures that will be required to implement the software. The data objects and
relationships defined in the entity relationship diagram and the detailed data content
depicted in the data dictionary provide the basis for the data design activity.Part of data
design may occur in conjunction with the design of software architecture.

3. 3
 Architectural Design - The architectural design is the highest abstract version of the
system. It identifies the software as a system with many components interacting with each
other. At this level, the designers get the idea of proposed solution domain .it describes
What modules does a system need and how do they interact with each other?
 The interface design describes how the software communicates within itself, 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. Therefore, data and
control flow diagrams provide much of the information required for interface design.
 The component-level design transforms structural elements of the software architecture
into a procedural description of software components. Detailed Design- Detailed design
deals with the implementation part of what is seen as a system and its sub-systems in the
previous two designs. It is more detailed towards modules and their implementations. It
defines logical structure of each module and their interfaces to communicate with other
modules. What services does each individual module need to provide?
Designactivities are usually classified into two stages:
1) Preliminary (or high-level, system) design.
• focus is on deciding which modules are needed for the system,
specification of the modules and how the modules should be
interconnected.
2) Detailed design.(logic design)
• deals with internal design of the modules, how the specification can be
satisfied, is decided.
Meaning and scope of the two stages: Vary considerably from one methodology to another.
2.1 High-Level Design
Identify the following:
– Modules
– Control relationships among modules
– Interfaces among modules.
• The outcome of high-level design is:
– Program structure (or software architecture).
• Several notations are available to represent high-level design:

4. 4
– Usually a tree-like diagram called structure chart is used.
2.2 Detailed Design
• For each module, design:
– Data structure
– Algorithms
• Outcome of detailed design:
– Module specification.
A Classification of Design Methodologies
• Procedural (Function-oriented)
• Object-oriented
2.3 Designobjectives
1) The main goal of the design phase is to produce best possible design within the limitations
imposed by the requirements and the physical environment in which the system will
operate.
2) Design fills the gap between specification and coding.
3) Correctness : if the system built according to the design ,satisfies the requirements of the
system.
4) Design should be verifiable : verifiability is how easily the correctness of the design can
be checked.
5) Completeness: All relevant data structures ,modules, external interfaces , and module
interconnections are specified.
6) Traceable : entire design element must be traceable to the requirements.
7) The most important properties that concern designers are efficiency and simplicity.
8) Efficiency: proper use of scarce resources from the system.
9) Simplicity :if design is simple enough then the it can support maintainability.
10) The principles used in design are same as those in problem analysis, but in problem
analysis we are constructing a model of the problem domain, while in design we are
constructing a model of the solution domain.

5. 5
3 DesignStrategies
1. Top down.
1. Module decomposition.
2. Refinement: A design is successively refined by adding details to it.
3. Transformation: A high-level design is transformed in a series of steps to a low-level
design.
2. Bottom up.
1. Module composition.
3. Design for change.
4. Product families.
5. Little languages.
3.3Design for Change: What Changes?
1. Algorithms.
2. Data representation.
3. Underlying abstract machine.
 Hardware.
 Operating system.
 Programming languages.
 Software libraries.
 Database management systems (DBMSs).
4. Physical environment (peripheral devices).
5. Social environment.
6. Software development process.
3.4 Product Families
A product family is a set of versions of a software product.
 Some versions are successors of other versions.
 Versions may differ from each other by the mix of services they provide.
 Versions may differ from each other by the environments in which they are intended to be
used.
A product family should be designed as one system, not as a set of separate systems.
Sequential completion is the wrong way to design a product family.
Version 1
Version 2
1
2
3
5
1
2
3
4

6. 6
A better approach is to implement product family :
 Anticipate what family members will be needed.
 Identify what structure is common to all members.
 Delay decisions that differentiate members
4 Characteristics of a Good Software Design
1. Correctness: A good design should correctly implement all the functionalities
identified in the SRS document.
2. Understandability: A good design is easily understandable.
3. Efficiency: Efficiency of a system deal with the Efficient use of scarce resource .
4. Completeness: requires that all the component of the design model should be
verified
5. Traceability
6. Verifiability
7. Maintainability: It should be easily amenable to change.
8. Simplicity
9. High cohesion and low coupling
5 DESIGN PRINCIPLES
Basic design principles enable the software engineer to navigate the design process. Davis
suggests a set1 of principles for software design, which have been adapted and extended in the
following list:
1. The design process should not suffer from “tunnel vision.” A good designer
should consider alternative approaches, judging each based on the requirements of
the problem, the resources available to do the job
2. The design should be traceable to the analysis model. Because a single element
of the design model often traces to multiple requirements, it is necessary to have a
means for tracking how requirements have been satisfied by the design model
3. The design should not reinvent the wheel. Systems are constructed using a set of
design patterns, many of which have likely been encountered before. These
patterns should always be chosen as an alternative to reinvention. Time is short
and resources are limited! Design time should be invested in representing truly
new ideas and integrating those patterns that already exist.
4. The design should “minimize the intellectual distance” between the software
and the problem as it exists in the real world. That is, the structure of the

7. 7
software design should (whenever possible) mimic the structure of the problem
domain.
5. The design should exhibit uniformity and integration. A design is uniform if it
appears that one person developed the entire thing. Rules of style and format
should be defined for a design team before design work begins. A design is
integrated if care is taken in defining interfaces between design components.
6. The design should be structured to accommodate change. The design concepts
discussed in the next section enable a design to achieve this principle.
7. The design should be structured to degrade gently, even when aberrant data,
events, or operating conditions are encountered. Well designed software should
never “bomb.” It should be designed to accommodate unusual circumstances, and
if it must terminate processing, do so in a graceful manner.
8. Design is not coding, coding is not design. Even when detailed procedural
designs are created for program components, the level of abstraction of the design
model is higher than source code. The only design decisions made at the coding
level address the small implementation details that enable the procedural design to
be coded.
9. The design should be assessed for quality as it is being created, not after the
fact. A variety of design concepts and design measures are available to assist the
designer in assessing quality.
10. The design should be reviewed to minimize conceptual (semantic) errors.
There is sometimes a tendency to focus on minutiae when the design is reviewed,
missing the forest for the trees. A design team should ensure that major conceptual
elements of the design (omissions, ambiguity, inconsistency) have been addressed
before worrying about the syntax of the design model.
6 DESIGN CONCEPTS
1. Abstraction
2. Refinement
3. Modularity
4. Software Architecture
5. Control Hierarchy
6. Structural Partitioning
7. Data Structure
8. Software Procedure
9. Information Hiding
10. Coupling and cohesion
6.1 Abstraction
It is a tool that permits a developer to consider a component in terms of the services it provides
without worrying about the details of its implementation
Different levels of abstraction
1. A procedural abstraction is a named sequence of instructions that has a specific and
limited function. functional abstraction: a module is specified by the functions it
performs.An example of a procedural abstraction would be the word open for a door.

8. 8
Open implies a long sequence of procedural steps (e.g., walk to the door, reach out and
grasp knob, turn knob and pull door, step away from moving door, etc.).
2. A data abstraction:a data structure is manipulated in terms of pre-defined operations; the
implementation of the data structure is hidden from its users .In the context of the
procedural abstraction open, we can define a data abstraction called door. Like any data
object, the data abstraction for door would encompass a set of attributes that describe the
door (e.g., door type, swing direction, opening mechanism, weight, dimensions). It follows
that the procedural abstraction open would make use of information contained in the
attributes of the data abstraction door.
3. Control abstraction is the third form of abstraction used in software design. Like
procedural and data abstraction, control abstraction implies a program control mechanism
without specifying internal details. An example of a control abstraction is the
synchronization semaphore used to coordinate activities in an operating system
6.2 .Refinement
Stepwise refinement is a top-down design strategy originally proposed by Niklaus Wirth. 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.We 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. Refinement causes the
designer to elaborate on the original statement, providing more and more detail as each successive
refinement (elaboration) occurs. Abstraction and refinement are complementary concepts.
Abstraction enables a designer to specify procedure and data and yet suppress low-level details.
Refinement helps the designer to reveal low-level details as design progresses. Both concepts aid
the designer in creating a complete design model as the design evolves.
6.3.Modularization
Modularization is a technique to divide a software system into multiple discrete and independent
modules, which are expected to be capable of carrying out task(s) independently. These modules
may work as basic constructs for the entire software. Designers tend to design modules such that
they can be executed and/or compiled separately and independently.
Modular design unintentionally follows the rules of ‘divide and conquer’ problem-solving
strategy this is because there are many other benefits attached with the modular design of a
Jalote says: Modularity is where abstraction and partitioning come together.software.
Meyer defines five criteria that enable us to evaluate a design method with respect to its ability to
define an effective modular
system:

9. 9
1. Modular decomposability. If a design method provides a systematic mechanism for
decomposing the problem into subproblems, it will reduce the complexity of the overall
problem, thereby achieving an effective modular solution.
2. Modular composability. If a design method enables existing (reusable) design
components to be assembled into a new system, it will yield a modular solution that does
not reinvent the wheel.
3. Modular understandability. If a module can be understood as a standalone unit (without
reference to other modules), it will be easier to build and easier to change.
4. Modular continuity. If small changes to the system requirements result in changes to
individual modules, rather than systemwide changes, the impact of change-induced side
effects will be minimized.
5. Modular protection. If an aberrant condition occurs within a module and its effects are
constrained within that module, the impact of error-induced side effects will be
minimized.
Finally, it is important to note that a system may be designed modularly, even if its
implementation must be "monolithic."
Advantage of modularization:
 Smaller components are easier to maintain
 Program can be divided based on functional aspects
 Desired level of abstraction can be brought in the program
 Components with high cohesion can be re-used again
 Concurrent execution can be made possible
 Desired from security aspect
Two Questions are to be asked:
1. What kind of structure does a modular system have?
2. What are the desirable properties of this structure?
Properties of modular designs
 Cohesion
 Coupling
6.4 .Software Architecture
Software architecture alludes to “the overall structure of the software and the ways in which that
structure provides conceptual integrity for a system”. In its simplest form, architecture is the
hierarchical structure of program components (modules), the manner in which these components
interact and the structure of data that are used by the components. In a broader sense, however,
components can be generalized to represent major system elements and their interactions.
Shaw and Garlan describe a set of properties that should be specified aspart of an architectural
design:

10. 10
1. 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.
For example, objects are packaged to encapsulate both data and the processing that
manipulates the data and interact via the invocation of methods.
2. 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.
3. Families of related systems. The architectural design should draw upon repeatable
patternsthat are commonly encountered in the design of families of similar systems. In
essence, the design should have the ability to reuse architectural building blocks.
6.5 .Control Hierarchy
Control hierarchy, also called program structure, represents the organization of program
components (modules) and implies a hierarchy of control. It does not represent procedural aspects
of software such as sequence of processes, occurrence or order of decisions, or repetition of
operations; nor is it necessarily applicable to all architectural styles. Different notations are used
to represent control hierarchy for those architecturalstyles that are amenable to this representation.
The most common is the treelike diagram that represents hierarchical control for call and return
architectures, depth and width provide an indication of the number of levels of control and
overall span of control, respectively. Fan-out is a measure of the number of modules that are
directly controlled by another module. Fan-in indicates how many modules directly control a
given module.
The control relationship among modules is expressed in the following way: A module that
controls another module is said to be superordinate to it, and conversely, a module controlled by
another is said to be subordinate to the controller. module M is superordinate to modules a, b, and
c. Module h is subordinate to module e and is ultimately subordinate to module M. Width-

11. 11
oriented relationships (e.g., between modules d and e) although possible to express in practice,
need not be defined with explicit terminology
The control hierarchy also represents two subtly different characteristics of the software
architecture: visibility and connectivity. Visibility indicates the set of program components that
may be invoked or used as data by a given component, even when this is accomplished indirectly.
For example, a module in an object-oriented system may have access to a wide array of data
objects that it has inherited, but makes use of only a small number of these data objects. All of the
objects are visible to the module. Connectivity indicates the set of components that are directly
invoked or used as data by a given component. For example, a module that directly causes
another module to begin execution is connected to it
6. 6 . Structural Partitioning
If the architectural style of a system is hierarchical, the program structure can be partitioned both
horizontally and vertically.
1. horizontal partitioning defines separate branches of the modular hierarchy for each major
program function. Control modules, represented in a darker shade are used to coordinate
communication between and execution of the functions. The simplest approach to
horizontal partitioning defines three partitions—input, data transformation (often called
processing) and output.
2. Partitioning the architecture horizontally provides a number of distinct benefits:
• software that is easier to test
• software that is easier to maintain
• propagation of fewer side effects
• software that is easier to extend
Because major functions are decoupled from one another, change tends to be less
complex and extensions to the system (a common occurrence) tend to be easier to
accomplish without side effects. On the negative side, horizontal partitioning often causes
more data to be passed across module interfaces and can complicate the overall control of
program flow (if processing requires rapid movement from one function to another).

12. 12
3 Vertical partitioning (Figure b), often called factoring, suggests that control (decision
making) and work should be distributed top-down in the program structure. Toplevel
modules should perform control functions and do little actual processing work.
Modules that reside low in the structure should be the workers, performing all input, computation,
and output tasks.
The nature of change in program structures justifies the need for vertical partitioning. Referring to
Figure b, it can be seen that a change in a control module (high in the structure) will have a higher
probability of propagating side effects to modules that are subordinate to it. A change to a worker
module, given its low level in the structure, is less likely to cause the propagation of side effects.
In general, changes to computer programs revolve around changes to input, computation or
transformation, and output. The overall control structure of the program (i.e., its basic behavior is
far less likely to change). For this reason vertically partitioned structures are less likely to be
susceptible to side effects when changes are made and will therefore be more maintainable—a
key quality factor.
6.7 Data Structure
Data structure is a representation of the logical relationship among individual elements of data.
Because the structure of information will invariably affect the final procedural design, data
structure is as important as program structure to the representation of software architecture
1. A scalar item is the simplest of all data structures. As its name implies, a scalar item
represents a single element of information that may be addressed by an identifier; that is,
access may be achieved by specifying a single address in memory. The size and format of
a scalar item may vary within bounds that are dictated by a programminglanguage.
2. The most common n-dimensional space is the two-dimensional matrix. In many
programming languages, an ndimensional space is called an array.
3. A linked list is a data structure that organizes noncontiguous scalar items, vectors, or
spaces in a manner (called nodes) that enables them to be processed as a list.
4. a stack is a conceptual model of a data structure that can be implemented as a vecto
6.8 Software Procedure
Program structure defines control hierarchy without regard to the sequence of processing and
decisions. Software procedure focuses on the processing details of each module individually.
Procedure must provide a precise specification of processing, including sequence of events, exact
decision points, repetitive operations, and even data organization and structure. There is, of
course, a relationship between structure and procedure. The processing indicated for each module
must include a reference to all modules subordinate to the module being described.

13. 13
6.9 Information Hiding
The concept of modularity leads every software designer to a fundamental question:
"How do we decompose a software solution to obtain the best set of modules?" 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
(procedure 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. Abstraction helps to define the procedural (or informational) entities
that make up the software. Hiding defines and enforces access constraints to both procedural
detail within a module and any local data structure used by the module 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
procedure are hidden from other parts of the software, inadvertent errors introduced during
modification are less likely to propagate to other locations within the software.
6.10 Cohesion
Cohesion is a measure of functional strength of a module. A module having high cohesion and
low coupling is said to be functionally independent of other modules. By the term functional
independence, we mean that a cohesive module performs a single task or function.

14. 14
1. Coincidental cohesion(weak): A module is said to have coincidental cohesion, if it
performs a set of tasks that relate to each other very loosely .Parts of a component are
simply bundled together.
2. Logical cohesion(weak): A module is said to be logically cohesive, if all elements of the
module perform similar operations, Components which perform similar functions are
grouped.
Eg:printf
3. Temporal cohesion: When a module contains functions that are related by the fact that all
the functions must be executed in the same time span, Components which are activated
at the same time are grouped
Eg:shut down
4. Procedural cohesion: A module is said to possess procedural cohesion, if the set of
functions of the module are all part of a procedure (algorithm) in which a certain sequence
of steps have to be carried out for achieving an objective
Eg :palindrome
5. Communicational cohesion (medium): A module is said to have communicational
cohesion, if all functions of the module refer to or update the same data structure, e.g. the
set of functions defined on an array or a stack. All the elements of a component operate on
the same input or produce the same output.
6. Sequential cohesion: A module is said to possess sequential cohesion, if the elements of a
module form the parts of sequence, where the output from one element of the sequence is
input to the next.
7. Functional cohesion: Functional cohesion is said to exist, if different elements of a
module cooperate to achieve a single function.
Eg,:a module containing all the functions required to manage employees’ pay-roll
displays functional cohesion. Suppose a module displays functional cohesion, and
we are asked to describe what the module does, then we would be able to describe
it using a single sentence.
Coupling
Coupling between two modules is a measure of the degree of interdependence or interaction
between the two modules. A module having high cohesion and low coupling is said to be
functionally independent of other modules. If two modules interchange large amounts of data,
then they are highly interdependent. The degree of coupling between two modules depends on
their interface complexity. The interface complexity is basically determined by the number of
types of parameters that are interchanged while invoking the functions of the module. Even if no
techniques to precisely and quantitatively estimate the coupling between two modules exist today,
classification of the different types of coupling will help to quantitatively estimate the degree of
coupling between two modules.

15. 15
1. Data Coupling: It is low degree of coupling. The connection involves either simple data
items or aggregate structures all of whose elements are used by the receiving object. This
should be the goal of an architectural design.It is exhibited in the portion of structure.
2. Stamp Coupling: Two modules are stamped coupled, if they communicate using a
composite data item
Eg:a structure in C.
3. Control coupling: Control coupling exists between two couples, if data from one module
is used to direct the order of instructions execution in another. An example of control
coupling is a flag set in one module and tested in another module.
4. Common coupling: Two modules are common coupled, if they share some global data
items.
5. Content coupling: Content coupling exists between two modules, if their code is shared,
e.g. a branch from one module into another module
Module A Module B
Module C Module D
Shared data
area

16. 16
Modularity In detail:
EFFECTIVE MODULAR DESIGN
1. Functional IndependenceThe concept of functional independence is a direct outgrowth of
modularity and the concepts of abstraction and information hidingFunctional
independence is achieved by developing modules with "single-minded" function and an
"aversion" to excessive interaction with other modules. Stated another way, we want to
design software so that each module addresses a specific subfunction of requirements and
has a simple interface when viewed from other parts of the program structure. It is fair to
ask why independence is important. Software with effective modularity, that is,
independent modules, is easier to develop because function may be compartmentalized
and interfaces are simplified (consider the ramifications when development is conducted
by a team). Independent modules are easierto maintain (and test) because secondary
effects caused by design or code modification are limited, error propagation is reduced,
and reusable modules are possible. To summarize, functional independence is a key to
good design, and design is the key to software quality
2. Evaluate the "first iteration" of the program structure to reduce coupling and improve
cohesion
Independence is measured using two qualitative criteria:
1. cohesion and
2. coupling.
3 Attempt to minimize structures with high fan-out; strive for fan-in as depth increases
4 Keep the scope of effect of a module within the scope of control of that module.
5 Evaluate module interfaces to reduce complexity and redundancy and improve
consistency. Module interface complexity is a prime cause of software errors. Interfaces
should be designed to pass information simply and should be consistent with the function
of a module.
6 Define modules whose function is predictable, but avoid modules that are overly
restrictive. A module is predictable when it can be treated as a black box; that is, the same
external data will be produced regardless of internal processing details.7 Modules that
have internal "memory" can be unpredictable unless care is taken in their use
7 Avoid cycles in the module hierarchy
.The structure can be viewed as various relations on the set of modules in the system:
 Uses relation.
 Is-component-of relation.
The structure should include levels of abstraction:
 Architectural design: What modules does a system need and how do they interact with
each other?
 Detailed design: What services does each individual module need to provide?
Uses Relation
A module M1 uses a module M2 if M1 requires a service provided by the interface of M2.
1. The uses relation R is defined by M1 R M2 iff M1 uses M2.
2. In this situation, M1 is the client and M2 is the server.
The uses relation is defined at design time.

17. 17
The user relation R determines a directed graph G called the uses graph.
 G is defined by
There is an edge from M1 to M2 in G iff M1 R M2.
Desirable Property 1
The uses relation should be a hierarchy, i.e., the uses graph should be a directed acyclic graph
(DAG).
A hierarchy makes the software easy to understand, implement, and test.
The presence of cycles in the uses graph implies that there is strong coupling between modules
and that there is not a full separation of concerns.
A system of modules with a hierarchical structure divides the system into levels of abstraction.
A module M has level k in a hierarchy R is defined inductively by:
1. Suppose that there is no module M’ in R such that M’ R M. Then M has level 0.
2. Otherwise suppose k is the maximum level of all modules M’ in R such that M0 R M.
Then M has level k + 1.
The fan-in of a module M in the uses graph G is the number of edges coming into M.
The fan-out of a module M in the uses graph G is the number of edges going out of M.
A good design tends to have high fan-in and low fan-out.
Is-component-of Relation
1. A module M is composed of set S of submodules of M if M is the union of the modules in
S.
 I S is a module decomposition of M.

18. 18
2. A module M’ is a component of a module M if M’ a member of a module decomposition
of M.
 The is-component-of relation R is defined by M1 R M2 iff M1 is a component of
M2.
3. The is-component-of relation determines a hierarchy.
 The modules that are leaf nodes in the hierarchy are physical modules composed of
code.
 The other modules are conceptual modules used to describe the physical modules
in a hierarchical way.
Modularization Techniques
• Modularization – systemconsist of discrete components and can be implemented
separately.
• Change to one component has minimal impact on the other component.
Properties /advantages of a modular system
• Each module/ function should have a well defined purpose.
• Modular systems are easierto document.
• Easier to understand
• Programming individual modules are easier
• Testing and debugging individual modules are easier.
• Bugs easily isolated
• Increase reusability.
• Modules created during modularization are:
• Process support modules

19. 19
• All the functions and data items that are required to support a
particular business process are grouped together.
• Functional modules
• Closely related task are grouped together
• Hardware modules.
• All functions which control on particular hardware are grouped
together
Steps for modularization
1. Designstructure chart
The module structure of a software and the interaction among different
modules are represented easily by means of a structure chart.
- explain the notations in structure chart.
- explain different kinds of modules.
- draw a sample structure chart.
2. Pseudo-Code (detailed module structure)
a. Pseudo code is a combination of algorithm written in simple language
and programming language statements.
b. The designer describes the systemcharacteristics structured by keywords
such as IF-THEN -ELSE
– Write E.g for pseudo code
– Advantages
– Converting pseudo code to a programming language is much easier
– Takes less time
– Easier to write
3. Flow Chart
4. Coupling and cohesion

20. 20
Categories of modules
• Modules can be classified into standard categories.
• Such a categorization is necessary to make the design more standard and uniform.
• More ever categorization of module is a step towards the development of standard
software engineering components.
• This also help in retrieval of the module from a component library.
• The standard categories are : procedural abstractions, libraries, and common pools of data.
• Two more general and abstract categories are abstract objects , abstract data types.
Modules can be classified into standard categories; such a categorization is helpful, for retrieval
from a component library and also for documentation.
Categorization of modules is a step towards the development of standard software engineering
components.
Basically 3 standard categories: procedural abstractions, libraries and common pools of data.
1. Procedural abstraction Module/ Functional modules: A commonly used type of module which
provide justaprocedure or functionthatimplement some abstract operation. Typical examples
are sorting modules, modules that perform translation from one language into another.
– traditional form of modularization
– provide a procedural abstraction
– encapsulate an algorithm
2. Library Modules: A module may contain group of related procedural abstractions. A typical and
successful example is represented by libraries of mathematical routines. Such libraries provide
solutiontomostcommonlyencounteredmathematical problems.Anotherexample is the library
of routines that provide algebraic operations on matrices. Modules of this type are used to
package together a related set of routines. We use the term library to denote this class of
modules.

21. 21
3. Commonpool of data: Once the need of sharing data among several modules is recognized, we
can group suchdata togetherin a common pool that is imported by all client modules. They are
then allowed to manipulate the data directly.
There are 3 other categories of modules; they are abstract objects, abstract data types and generic
modules.
1. Abstract objects: A module that hides a data structure as the secret, and exports routines that
may be usedas operationstoaccessthe hiddendatastructure and modifythe valuesstoredinit.
Abstract objects: an example
• A calculator of expressions expressed in Polish postfix form
a*(b+c)  abc+*
• a module implements a stack where the values of operands are shifted until an operator is
encountered in the expression
(assume only binary operators)
Interface of the abstract object STACK
exports
procedure PUSH (VAL: in integer);
procedure POP_2 (VAL1, VAL2: out integer);
Design assessment
How does the design anticipate change in type of expressions to be evaluated?

22. 22
– e.g., it does not adapt to unary operators
2. Abstract data types: This is a module that exports a type, along with the operations needed to
access and manipulate objects of that type; it hides the representation of the type and
algorithms used in the operations. Instances of abstract data type are abstract objects. In
Abstractdata type module howdatais representedisnotknown by the outside objects that use
that module. ExamplePUSH(X) ,objectwanttopushthat data into the stack, but what algorithm
is used or which type of data structure is used is unknown by the object.
– Many instances of abstract objects may be generated
Abstract data types (ADTs)
• Correspond to Java and C++ classes
• Concept may also be implemented by Ada private types and Modula-2 opaque types
• May add notational details to specify if certain built-in operations are available by default
on instance objects of the ADT
– e.g., type A_TYPE: ? (:=, =) indicates that assignment and equality check are
available
Generic Module: This provides a powerful tool for writing reusable components.
A template is created for the similar modules containing abstract object. A generic module
consists of a generic definition module and a generic implementation module, each prefixed by
the reserved word GENERIC. The generic definition module is a template from which a specific
definition module may be refined. The generic implementation module is a template from which a
specific implementation module may be refined.

23. 23
generic module GENERIC_STACK_2
. . .
exports
procedure PUSH (VAL : in T);
procedure POP_2 (VAL1, VAL2 : out T);
…
end GENERIC_STACK_2
Top –down and bottom up strategies
Top down
Bottom up

24. 24
• Top- down design approach starts by identifying the major components of the system,
decomposing them into lower level components and iterating until desired level of detail is
achieved.
• Top down design methods often results in some form of step wise refinement.
• Starting from abstract design ,in each step the design is refined to a more concrete level ,
until we reach a level where no more refinement is needed and the design can be
implemented directly.
• Bottom up design begins the design with the lowest level modules or subsystems, and
progresses upward to the main program, module, or subsystem, and the development of
drivers is necessary to complete the bottom up approach.
• A mix of top-down and bottom-up approaches are normally used:
• Top-down design is almost always needed to give the system a good structure.
• Bottom-up design is normally useful so that reusable components can be created
• Top down design is most often used in designing brand new systems, while bottom
up design is sometimes used when one is reverse engineering a design.
• Top-down approach: In this an overview of the system is first formulated, specifying but
not detailing any first-level subsystems. Each subsystem is then refined in yet greater
detail, sometimes in many additional subsystem levels, until the entire specification is
reduced to base elements.
• Bottom-up approach: In this approach the individual base elements of the system are first
specified in great detail. These elements are then linked together to form larger
subsystems, which then in turn are linked, sometimes in many levels, until a complete top-
level system is formed.
• Module level concepts
A module is a logically separable part of a program.
• Two modularization criteria's are there.
1 coupling
2. Cohesion

25. 25
specific techniques for design for change
Techniques for implementing modules that accommodate change easily.
1. Configuration constants
– The difficulty with software modification is that specific information which is
going to change may be difficult to code or spread through out the program.
– E.g. an array size may be initially set to 10, but now it is required to become 50
– The systemmay contain declarations such as
a: array (1….10) of integer;
the program may contain statements like ,
if k>=1 and k<=10 then
perform indexing
else
do other action;
end if;
Changing the upper bound of array to 50 requires changing the declarations and the
statements
1. The required changes in software can be factored out into a set of constants called
configuration constants, the problem may be solved by changing the value of those
constants and then recompiling the program.
2. Symbolic constant is the solution to the problem of making programs easily adaptable
to change.
3. It is a simple way of representing multiple version software.
2 Conditional compilation
a. All versions of the same family are represented by one single source copy.
b. The difference between various version are taken into account by conditional
compilation.
c. Lines of source code that may be sometimes desired in the program and other
times not, are surrounded by #ifdef, #endif directive pairs as follows:

26. 26
#ifdef DEBUG
printf("debug:x = %d, y = %fn", x, y); ...
#endif
The #ifdef directive specifies that if DEBUG exists as a defined macro, i.e. is
defined by means of a #define directive then the statements between the #ifdef
directive and the #endif directive are retained in the source file passed to the compiler.
3 Software generation
a. Generate automatically a new solution for each requested change.
 A system consists of a set of components, which have (sub)components of their own
 The highest level component is the system itself, a concept we have seen when
discussing context diagrams
 The lowest level components are highly cohesive, loosely coupled implementation
units written in some form of programming language
 We can design such a hierarchy using either a top-down approach or a bottom-up
approach
 In reality, we use both approaches and meet in the middle
 A top-down approach starts with the system as a whole, and using stepwise refinement,
decomposes it into sub-components that exist at lower levels of abstraction
 A bottom-up approach starts with primitive components that provide foundational services
and using layers of abstraction builds the functionality the system needs until the entire
system has been realized
 A top-down approach is typically more useful in situations in which an application is
being built from scratch
A bottom-up approach is thus more useful in situations in which a new application
is being created from an existing (legacy) system

27. 27
Designnotations
Dynamic
1. Data flowdiagrams(DFDs).
2. State transitiondiagrams(STDs).
3. Statecharts.
4. Structure diagrams.
Static
1. EntityRelationshipDiagrams(ERDs).
2. Classdiagrams.
3. Structure charts.
4. Objectdiagrams.
Textual desiginnotation
Graphical design notation
Interface vs. Implementation
module X
uses Y, Z
exports var A : integer;
type B : array (1. .10) of real;
procedure C ( D: in out B; E:in integer; F: in real);
Here is an optional natural-language description of what
A, B, and C actually are, along with possible constraints
or properties that clients need to know; for example, we
might specify that objects of type B sent to procedure C
should be initialized by the client and should never
contain all zeroes.
implementation
If needed, here are general comments about the rationale
of the modularization, hints on the implementation, etc.
is composed of R, T
end X

28. 28
• May be used to specify the protocol to be followed by the clients so that exported
services are correctly provided
– e.g., a certain operation which does the initialization of the module should be
called before any other operation
– e.g., an insert operation cannot be called if the table is full
Benefits
• Notation helps describe a design precisely
• Designcan be assessedfor consistency
– having defined module X, modules R and T must be defined eventually
• if not  incompleteness
– R, T replace X
•  either one or both must use Y, Z
GDN description of module X
module R
uses Y
exports var K : record . . .end;
type B : array (1. .10)of real;
procedure C (D: in out B; E:in integer; F:in real);
implementation
.
.
.
end R
module T
uses Y, Z, R
exports var A : integer;
implementation
.
.
.
end T
X
Y
Z
A B
R T
ModuleModule
Module
Module
Module
C

29. 29
X's decomposition
Function Oriented Design
In function-oriented design, the system is comprised of many smaller sub-systems known as
functions. These functions are capable of performing significant task in the system. The
system is considered as top view of all functions.
Function oriented design inherits some properties of structured design where divide and
conquer methodology is used.
This design mechanism divides the whole system into smaller functions, which provides
means of abstraction by concealing the information and their operation. These functional
modules can share information among themselves by means of information passing and using
information available globally.
Another characteristic of functions is that when a program calls a function, the function
changes the state of the program, which sometimes is not acceptable by other modules.
Function oriented design works well where the system state does not matter and
program/functions work on input rather than on a state.
DesignProcess
The whole system is seen as how data flows in the system by means of data
flow diagram.
DFD depicts how functions change the data and state of entire system.
The entire system is logically broken down into smaller units known as functions on
X
Y
Z
B C
R T
ModuleModule
Module
Module
Module
A
K

30. 30
the basis of their operation in the system.
Each function is then described at large.
Function-oriented design techniques: start with the functional requirements specified in the
SRS document.
During the design process: high-level functions are successively decomposed: into more detailed
functions. f inally the detailed functions are mapped to a module structure.
SA/SD (Structured Analysis/Structured Design)
SA/SD methodology consists of two distinct activities:
1. Structured Analysis (SA)
2. Structured Design (SD)
1)During structured analysis:functional decomposition takes place.
Transforms a textual problem description into a graphic model.done using data flow
diagrams (DFDs).DFDs graphically represent the results of structured analysis.
Please write about dfd here, how you decompose dft how you balance dfd .
2)During structured design:module structure is formalized.
All the functions represented in the DFD:mapped to a module structure. The module
structure:also called as the software architecture:
Software architecture:refined through detailed design.Detailed design can be directly
implemented: using a conventional programming language.
The aim of structured design is to transform the results of the structured analysis (i.e. a DFD
representation) into a structure chart. Structured design provides two strategies to guide
transformation of a DFD into a structure chart.
• Transform analysis
• Transaction analysis
Normally, one starts with the level 1 DFD, transforms it into module representation using either
the transform or the transaction analysis and then proceeds towards the lower-level DFDs. At
each level of transformation, it is important to first determine whether the transform or the
transaction analysis is applicable to a particular DFD. These are discussed in the subsequent
sub- sections.
Structure Chart
A structure chart represents the software architecture, i.e. the various modules making up the
system, the dependency (which module calls which other modules), and the parameters that are
passed among the different modules. Hence, the structure chart representation can be easily
implemented using some programming language. Since the main focus in a structure chart

31. 31
representation is on the module structure of the software and the interactions among different
modules, the procedural aspects (e.g. how a particular functionality is achieved) are not
represented.
The basic building blocks which are used to design structure charts are the following:
 Rectangular boxes: Represents a module.
 Module invocation arrows: Control is passed from on one module to another
module in the direction of the connecting arrow.
 Data flow arrows: Arrows are annotated with data name; named data passes
from one module to another module in the direction of the arrow.
 Library modules: Represented by a rectangle with double edges.
 Selection: Represented by a diamond symbol.
 Repetition: Represented by a loop around the control flow arrow.
Structure Chart vs. Flow Chart
We are all familiar with the flow chart representation of a program. Flow chart is a convenient
technique to represent the flow of control in a program. A structure chart differs from a flow
chart in three principal ways:
• It is usually difficult to identify the different modules of the software from its flow
chart representation.
• Data interchange among different modules is not represented in a flow chart.
• Sequential ordering of tasks inherent in a flow chart is suppressed in a structure chart.
Transform Analysis
Transform analysis identifies the primary functional components (modules) and the high level
inputs and outputs for these components. The first step in transform analysis is to divide the
DFD into 3 types of parts:
• Input
• Logical processing
• Output
The input portion of the DFD includes processes that transform input data from physical (e.g.
character from terminal) to logical forms (e.g. internal tables, lists, etc.). Each input portion is
called an afferent branch.
The output portion of a DFD transforms output data from logical to physical form. Each output
portion is called an efferent branch. The remaining portion of a DFD is called the central

32. 32
transform.
In the next step of transform analysis, the structure chart is derived by drawing one functional
component for the central transform, and the afferent and efferent branches.
These are drawn below a root module, which would invoke these modules. Identifying the
highest level input and output transforms requires experience and skill. One possible approach
is to trace the inputs until a bubble is found whose output cannot be deduced from its inputs
alone. Processes which validate input or add information to them are not central transforms.
Processes which sort input or filter data from it are. The first level structure chart is produced
by representing each input and output unit as boxes and each central transform as a single box.
In the third step of transform analysis, the structure chart is refined by adding sub-functions
required by each of the high-level functional components. Many levels of functional
components may be added. This process of breaking functional components into
subcomponents is called factoring. Factoring includes adding read and write modules, error-
handling modules, initialization and termination process, identifying customer modules, etc.
The factoring process is continued until all bubbles in the DFD are represented in the structure
chart.
Example: Structure chart for the RMS software
For this example, the context diagram was drawn earlier.
To draw the level 1 DFD (fig.11.1), from a cursory analysis of the problem
description, we can see that there are four basic functions that the system needs to
perform – accept the input numbers from the user, validate the numbers, calculate
the root mean square of the input numbers and, then display the result.
Fig. 11.1: Level 1
DFD
By observing the level 1 DFD, we identify the validate-input as the afferent branch and write-

33. 33
output as the efferent branch. The remaining portion (i.e. compute-rms) forms the central
transform. By applying the step 2 and step 3 of transform analysis, we get the structure chart
shown in fig.11.2.
Fig. 11.2: Structure Chart
Transaction Analysis
A transaction allows the user to perform some meaningful piece of work. Transaction
analysis is useful while designing transaction processing programs. In a transaction-driven
system, one of several possible paths through the DFD is traversed depending upon the input
data item. This is in contrast to a transform centered system which is characterized by
similar processing steps for each data item. Each different way in which input data is
handled is a transaction. A simple way to identify a transaction is to check the input data.
The number of bubbles on which the input data to the DFD are incident defines the number
of transactions. However, some transaction may not require any input data. These
transactions can be identified from the experience of solving a large number of examples.
For each identified transaction, trace the input data to the output. All the traversed bubbles
belong to the transaction. These bubbles should be mapped to the same module on the
structure chart. In the structure chart, draw a root module and below this module draw each
identified transaction a module. Every transaction carries a tag, which identifies its
type.
Transaction analysis uses this tag to divide the system into transaction modules and a
transaction-center module.
The structure chart for the supermarket prize scheme software is shown in fig. 11.3.

34. 34
Fig. 11.3: Structure Chart for the supermarket prize scheme
Object Oriented Design
Object oriented design works around the entities and their characteristics instead of functions
involved in the software system. This design strategy focuses on entities and its
characteristics. The whole concept of software solution revolves around the engaged entities.
Let us see the important concepts of Object Oriented Design:
Objects - All entities involved in the solution design are known as objects. For
example, person, banks, company and customers are treated as objects. Every entity
has some attributes associated to it and has some methods to perform on the attributes.
Classes - A class is a generalized description of an object. An object is an instance of a
class. Class defines all the attributes, which an object can have and methods, which
defines the functionality of the object.
In the solution design, attributes are stored as variables and functionalities are defined
by means of methods or procedures.
Data Abstraction - Data abstraction means that each object hides (abstracts away)

35. 35
from other objects the exact way in which its internal information is organized and
manipulated. It only provides a set of methods, which other objects can use for
accessing and manipulating this private information of the object. Other objects can not
directly access the private data of an object. For example, a stack object might store its
internal data either in the form of an array of values or in the form of a linked list.
Other objects would not know how exactly this object has stored its data and how it
manipulates its data. What they would know is the set of methods such as push, pop,
and top-ofstack that it provides to the other objects for accessing and manipulating the
data.
Advantages of Data Abstraction
An important advantage of the principle of data abstraction is that it reduces coupling
among the objects. Therefore, it reduces the overall complexity of a design, and helps
in maintenance and code reuse.
Encapsulation - In OOD, the attributes (data variables) and methods (operation on the
data) are bundled together is called encapsulation. The data of an object are
encapsulated within its methods and are available only through message-based
communication. Encapsulation not only bundles important information of an object
together, but also restricts access of the data and methods from the outside world. This
is called information hiding.
Advantages Of Encapsulation
Encapsulation offers three important advantages: • It protects an object’s internal data
from corruption by other objects. This protection includes protection from
unauthorized access and protection from different types of problems that arise from
concurrent access of data such as deadlock and inconsistent values. • Encapsulation
hides the internal structure of an object so that interaction with the object is simple and
standardized. This facilitates reuse of objects across different projects. Furthermore, if
the internal structure or procedures of an object are modified, other objects are not
affected. This results in easy maintenance. • Since objects communicate among each
other using messages only, they are weakly coupled. The fact that objects are
inherently weakly coupled enhances understanding of design since each object can be
studied and understood almost in isolation from other objects
Inheritance - OOD allows similar classes to stack up in hierarchical manner where the
lower or sub-classes can import, implement and re-use allowed variables and methods
from their immediate super classes. This property of OOD is known as inheritance.
This makes it easier to define specific class and to create generalized classes from
specific ones. The inheritance feature allows us to define a new class by extending or
modifying an existing class. The original class is called the base class (or super class)
and the new class obtained through inheritance is called as the derived class (or sub
class). A base class is a generalization of its derived classes. This means that the base

36. 36
class contains only those properties that are common to all the derived classes. Again
each derived class is a specialization of its base class because it modifies or extends the
basic properties of the base class in certain ways. Thus, the inheritance relationship can
be viewed as a generalization-specialization relationship. In addition to inheriting all
properties of the base class, a derived class can define new properties. That is, it can
define new data and methods. It can even give new definitions to methods which
already exist in the base class. Redefinition of methods which existed in the base class
is called as method overriding
Advantages of Inheritance
An important advantage of the inheritance mechanism is code reuse. If certain methods
or data are similar in asset of classes, then instead of defining these methods and data
each of these classes separately, these methods and data are defined only once in the
base class and are inherited by each of its subclasses.
Multiple Inheritance Multiple inheritance is a mechanism by which a sub class can
inherit attributes and methods from more than one base class.
Polymorphism - OOD languages provide a mechanism where methods performing
similar tasks but vary in arguments, can be assigned same name. This is called
polymorphism, which allows a single interface performing tasks for different types.
Depending upon how the function is invoked, respective portion of the code gets
executed.
The same message can result in different actions when received by different objects.
This is also referred to as static binding. This occurs when multiple methods with the
same operation name exist.
An example of static binding is the following. Suppose a class named Circle has three
definitions for the create operation. One definition does not take any argument and
creates a circle with default parameters. The second definition takes the center point
and radius as its parameters. In this case, the fill style values for the circle would be set
to default “no fill”. The third takes the centre point, the radius, and the fill style as its
input. When the create method is invoked, depending on the parameters given in the
invocation, the appropriate method will be called. If create is invoked with no
parameters, then a default circle would be created. If only the centre and the radius are
supplied, then an appropriate circle would be created with no fill type, and so on. A
class definition of the Circle class with the overloaded create method is shown in fig.
37.6. When the same operation (e.g. create) is implemented by multiple methods, the
method name is said to be overloaded.
Class Circle
{
private: float x, y, radius;
int fillType; public: create();
create (float x, float y, float centre);

37. 37
create (float x, float y, float centre, int fillType);
}
Fig. 37.6 Circle class with overloaded create method
When we have an inheritance hierarchy, an object can be assigned to another object of
its ancestor class. When such an assignment occurs, a method call to the ancestor
object would result in the invocation of the appropriate method of the object of the
derived class. The exact method to which a method call would be bound cannot be
known at compile time, and is dynamically decided at the runtime. This is also known
as dynamic binding.
Dynamic Binding Using dynamic binding a programmer can send a generic message to
a set of objects which may be of different types (i.e., belonging to different classes) and
leave the exact way in which the message would be handled to the receiving objects.
Suppose we have a class hierarchy of different geometric objects in a drawing as
shown in fig. 37.7. Now, suppose the display method is declared in the shape class and
is overridden in each derived class. If the different types of geometric objects making
up a drawing are stored in an array of type shape, then a single call to the display
method for each object would take care to display the appropriate drawing element.
That is, the same draw call to a shape object would take care of drawing the
appropriate shape. This code segment is shown below
Traditional Code
if(shape == Circle) then
draw_circle();
else if(shape == Rectangle)
then draw_rectangle();
Object-oriented
shape.draw();
DesignProcess
Software design process can be perceived as series of well-defined steps. Though it varies
according to design approach (function oriented or object oriented, yet It may have the
following steps involved:
A solution design is created from requirement or previous used system and/or system
sequence diagram.
Objects are identified and grouped into classes on behalf of similarity in attribute
characteristics.
Class hierarchy and relation among them are defined.
Application framework is defined.

38. 38
Advantages of the Object-Oriented Design
In the last few years that OOD has come into existence, it has found widespread acceptance in
industry as well as in academics.
The main reason for the popularity of OOD is that it holds the following promises:
• Code and design reuse.
• Increased productivity.
• Ease of testing and maintenance.
• Better code and design understandability.
Out of all these advantages, the chief advantage of OOD is improved productivity – which comes
about due to a variety of factors, such as
• Code reuse by the use of predefined class libraries.
• Code reuse due to inheritance.
• Simpler and more intuitive abstraction, i.e. better organization of inherent complexity.
• Better problem decomposition.
• OO terminology -procedures are called methods.
• OO design can be easily represented by means of UML notations.
• OO design insist on identifying classes and relation among classes.
OBJECT MODELLING USING UML
Model
A model captures aspects important for some application while omitting (or abstracting) the
rest. A model in the context of software development can be graphical, textual, mathematical,
or program code-based. Models are very useful in documenting the design and analysis results.
Models also facilitate the analysis and design procedures themselves. Graphical models are
very popular because they are easy to understand and construct. UML is primarily a graphical
modeling tool. However, it often requires text explanations to accompany the graphical models.

39. 39
Need fora model
An important reason behind constructing a model is that it helps manage complexity. Once
models of a system have been constructed, these can be used for a variety of purposes during
software development, including the following:
• Analysis
• Specification
• Code generation
• Design
• Visualize and understand the problem and the working of a system
• Testing, etc.
In all these applications, the UML models can not only be used to document the results but also
to arrive at the results themselves. Since a model can be used for a variety of purposes, it is
reasonable to expect that the model would vary depending on the purpose for which it is being
constructed. For example, a model developed for initial analysis and specification should be
very different from the one used for design. A model that is being used for analysis and
specification would not show any of the design decisions that would be made later on during
the design stage. On the other hand, a model used for design purposes should capture all the
design decisions. Therefore, it is a good idea to explicitly mention the purpose for which a
model has been developed, along with the model.
UnifiedModelingLanguage(UML)
UML, as the name implies,isamodelinglanguage.Itmaybe usedto visualize,specify,construct,and
documentthe artifactsof a software system.Itprovidesasetof notations(e.g.rectangles,lines,ellipses,
etc.) to create a visual model of the system.Like any otherlanguage,UML hasits ownsyntax (symbols
and sentence formationrules)andsemantics(meaningsof symbolsandsentences).Also,we should
clearlyunderstandthatUML isnot a systemdesignordevelopmentmethodology,butcanbe usedto
documentobject-orientedandanalysisresultsobtainedusingsome methodology
UML Diagrams
UML can be used to construct nine different types of diagrams to capture five different views
of a system. Just as a building can be modeled from several views (or perspectives) such as
ventilation perspective, electrical perspective, lighting perspective, heating perspective, etc.; the
different UML diagrams provide different perspectives of the software system to be developed
and facilitate a comprehensive understanding of the system. Such models can be refined to get
the actual implementation of the system.
The UML diagrams can capture the following five views of a system:
• User’s view
• Structural view
• Behavioral view

40. 40
• Implementation view
• Environmental view
Fig. 12.1: Different types of diagrams and views supported in UML
1.Generalization and specialization
• OOD allows abstract data types to be organized in a hierarchy through
generalization and specialization relations.
• Generalization is the process of extracting shared characteristics from two or more
classes, and combining them into a generalized super class. Shared characteristics
can be attributes or methods.
• In contrast to generalization, specialization means creating new subclasses from an
existing class. If it turns out that certain attributes or methods only apply to some of
the objects of the class, a subclass can be created.
EMPLOYEE
TECHNICAL_STAFFADMINISTRATIVE_STAFF

41. 41
• The most inclusive class in a generalization/specialization is called the super class
and is generally located at the top of the diagram. The more specific classes are
called subclasses and are generally placed below the super class.
• Anything that can be done with an object of the super class can also be done with an
object of the subclass.
• In the example the administrative staff and technical staff inherits all methods and
attributes defined from employee.
• The UML notations:- classes are represented by boxes divided into 3 parts –class
name, attributes and methods .
– Generalization- specialization relation is represented by triangular connectors
between classes.
2. Associations
• Association is a relationship between two objects.
Association defines the multiplicity between objects. one-to-one, one-to-many, many-to-one,
many-to-many all these words define an association between objects
• An object oriented systemcan be designed in several ways:

42. 42
– Drawing the class diagram
• Contain: classes ,dependency ,generalization and associations.
• Which represent the static view of an application.
• Represent the type of object in the system.
• Represent the relationship between the objects.
• Also represents the constraints.
Also called structural diagram
Activity diagram
State chart diagram

43. 43
A class diagram describes the static structure of a system. It shows how a system is structured
rather than how it behaves. The static structure of a system comprises of a number of class
diagrams and their dependencies. The main constituents of a class diagram are classes and their
relationships: generalization, aggregation, association, and various kinds of dependencies.
Classes
The classes represent entities with common features, i.e. attributes and operations. Classes are
represented as solid outline rectangles with compartments. Classes have a mandatory name
compartment where the name is written centered in boldface. The class name is usually written
using mixed case convention and begins with an uppercase. The class names are usually chosen to
be singular nouns. Classes have optional attributes and operations compartments. A class may
appear on several diagrams. Its attributes and operations are suppressed on all but one diagram.
Attributes
An attribute is a named property of a class. It represents the kind of data that an object might
contain. Attributes are listed with their names, and may optionally contain specification of their
type, an initial value, and constraints. The type of the attribute is written by appending a colon
and the type name after the attribute name. Typically, the first letter of a class name is a small
letter. An example for an attribute is given.

44. 44
bookName : String
Operation
Operation is the implementation of a service that can be requested from any object of the class to
affect behaviour. An object’s data or state can be changed by invoking an operation of the object.
A class may have any number of operations or no operation at all. Typically, the first letter of an
operation name is a small letter. Abstract operations are written in italics. The parameters of an
operation (if any), may have a kind specified, which may be ‘in’, ‘out’ or ‘inout’. An operation may
have a return type consisting of a single return type expression. An example for an operation is
given.
issueBook(in bookName):Boolean
Association
Associations are needed to enable objects to communicate with each other. An association
describes a connection between classes. The association relation between two objects is called
object connection or link. Links are instances of associations. A link is a physical or conceptual
connection between object instances. For example, suppose Amit has borrowed the book Graph
Theory. Here,borrowed is the connection between the objects Amit and Graph Theory book.
Mathematically, a link can be considered to be a tuple, i.e. an ordered list of object instances. An
association describes a group of links with a common structure and common semantics. For
example, consider the statement that Library Member borrows Books. Here, borrows is the
association between the class LibraryMember and the class Book. Usually, an association is a
binary relation (between two classes). However, three or more different classes can be involved in
an association. A class can have an association relationship with itself (called recursive
association). In this case, it is usually assumed that two different objects of the class are linked by
the association relationship. Association between two classes is represented by drawing a straight
line between the concerned classes.
Fig. 14.1 illustrates the graphical representation of the association relation. The name of the
association is written alongside the association line. An arrowhead may be placed on the
association line to indicate the reading direction of the association. The arrowhead should not be
misunderstood to be indicating the direction of a pointer implementing an association. On each
side of the association relation, the multiplicity is noted as an individual number or as a value
range. The multiplicity indicates how many instances of one class are associated with each other.
Value ranges of multiplicity are noted by specifying the minimum and maximum value, separated
by two dots, e.g.
An asterisk is a wild card and means many (zero or more). The association of fig.

45. 45
14.1 should be read as “Many books may be borrowed by a Library Member”. Observe
that associations (and links) appear as verbs in the problem statement.
Fig. 14.1: Association betweentwo classes
Associations are usually realized by assigning appropriate reference attributes to the classes
involved. Thus, associations can be implemented using pointers from one object class to another.
Links and associations can also be implemented by using a separate class that stores which objects
of a class are linked to which objects of another class. Some CASE tools use the role names of the
association relation for the corresponding automatically generated attribute.
Aggregation
Aggregation is a special type of association where the involved classes represent a whole -part
relationship. The aggregate takes the responsibility of forwarding messages to the appropriate
parts. Thus, the aggregate takes the responsibility of delegation and leadership. When an instance
of one object contains instances of some other objects, then aggregation (or composition)
relationship exists between the composite object and the component object. Aggregation is
represented by the diamond
symbol at the composite end of a relationship. The number of instances of the component class
aggregated can also be shown as in fig. 14.2
Fig. 14.2: Representation of aggregation

46. 46
Aggregation relationship cannot be reflexive (i.e. recursive). That is, an object cannot contain
objects of the same class as itself. Also, the aggregation relation is not symmetric. That is, two
classes A and B cannot contain instances of each other. However, the aggregation relationship can
be transitive. In this case, aggregation may consist of an arbitrary number of levels.
Composition
Composition is a stricter form of aggregation, in which the parts are existence-dependent on the
whole. This means that the life of the parts closely ties to the life of the whole. When the whole is
created, the parts are created and when the whole is destroyed, the parts are destroyed. A typical
example of composition is an invoice object with invoice items. As soon as the invoice object is
created, all the invoice items in it are created and as soon as the invoice object is destroyed, all
invoice items in it are also destroyed. The composition relationship is represented as a filled
diamond drawn at the composite-end. An example of the composition relationship is shown in fig.
14.3
Fig 14.3: Representation of composition
Associationvs.Aggregationvs.Composition
 Association is the most general (m:n) relationship. Aggregation is a stronger
relationship where one is a part of the other. Composition is even stronger than
aggregation, ties the lifecycle of the part and the whole together.
 Association relationship can be reflexive (objects can have relation to itself), but
aggregation cannot be reflexive. Moreover, aggregation is anti-symmetric (If B is a
part of A, A cannot be a part of B).
 Composition has the property of exclusive aggregation i.e. an object can be a part
of only one composite at a time. For example, a Frame belongs to exactly one
Window
whereas in simple aggregation, a part may be shared by several objects. For
example,a Wall may be a part of one or more Room objects.
 In addition, in composition, the whole has the responsibilityfor the disposition of
all its parts, i.e. for their creation and destruction.

47. 47
in general, the lifetime of parts and composite coincides
parts with non-fixedmultiplicitymay be created after composite itself
parts might be explicitlyremoved before the death of the composite
For example,when a Frame is created, it has to be attached to an enclosing
Window. Similarly,when the Window is destroyed, it must in turn destroy its
Frame parts.
Inheritancevs. Aggregation/Composition
 Inheritance describes ‘is a’ / ‘is a kind of’ relationship between classes (base class - derived
class) whereas aggregation describes ‘has a’ relationship between classes. Inheritance
means that the object of the derived class inherits the properties of the base class;
aggregation means that the object of the whole has objects of the part. For example, the
relation “cash payment is a kind of payment” is modeled using inheritance; “purchase
order has a few items” is modeled using aggregation.
 Inheritance is used to model a “generic-specific” relationship between classes whereas
aggregation/composition is used to model a “whole-part” relationship betweenclasses.
 Inheritance means that the objects of the subclass can be used anywhere the super class
may appear, but not the reverse; i.e. wherever we could use instances of ‘payment’ in the
system, we could substitute it with instances of ‘cash payment’, but the reverse cannot be
done.
 Inheritance is defined statically. It cannot be changed at run-time. Aggregation is defined
dynamically and can be changed at run-time. Aggregation is used when the type of the
object can change over time.
For example, consider this situation in a business system. A BusinessPartner might be a
Customer or a Supplier or both. Initially we might be tempted to model it as in Fig 14.4(a).
But in fact, during its lifetime, a business partner might become a customer as well as a
supplier, or it might change from one to the other. In such cases, we prefer aggregation
instead (see Fig 14.4(b). Here, a business partner is a Customer if it has an aggregated
Customer object, a Supplier if it has an aggregated Supplier object and a
"Customer_Supplier" if it has both. Here, we have only two types. Hence, we are able to
model it as inheritance. But what if there were several different types and combinations
thereof? The inheritance tree would be absolutely incomprehensible.
Also, the aggregation model allows the possibility for a business partner to be neither - i.e.
has neither a customer nor a supplier object aggregated withit.

48. 48
Fig. 14.4 a) Representation of BusinessPartner, Customer, Supplier relationshipusing
inheritance
Fig. 14.4 b) Representation of BusinessPartner, Customer, Supplier relationship using
aggregation

49. 49
• The advantage of aggregation is the integrity of encapsulation. The operations of an object are
the interfaces of other objects which imply low implementation dependencies. The significant
disadvantage of aggregation is the increase in the number of objects and their relationships. On
the other hand, inheritance allows for an easy way to modify implementation for reusability. But
the significant disadvantage is that it breaks encapsulation, which implies implementation
dependence.