Dept of Computer Science and Engineering

CML

Module 4 Topics
1. Design activity & its objectives
2. Modularization techniques
2.1 Module Structure and its Representation
2.2 Interface and Information Hiding
2.3 Categories of Modules
2.4 Specific Techniques to Accommodate Change
2.5 Stepwise Refinement
2.6 Top-Down And Bottom-Up Design
3. Handling anomalies.
4. Function Oriented and Object Oriented Design.
5. Case Study with UML and CASE Tool support.

1. Design activity & its objectives

Software design is the last software engineering action within modeling activity and sets the stage for
construction.
Software design is an iterative process through which requirements are translated into a blueprint for constructing
the software.
Output of design activity is a SOFTWARE DESIGN.
Software Design is defined as system decomposition into modules.
Often a software architecture is produced prior to a software design
Goal of architectural design activity is to define the Software architecture .
Goal of software design activity is definition of the software design according to the guidelines in Software
architecture. Both architectural design and software design are used interchangeably.
The Modularity principle is of great importance in design of the software.
Different components of a system are identified during design activity and they are called Modules.
When a Module M is decomposed into other modules, we can say that these are used to implement M.
Design Objectives of software is discussed under these topics:-
1. Design for change
2. Product families
1. Design for change
Designers tend to concentrate on current needs special effort needed to anticipate likely changes.
Design for change promotes a design that is flexible enough to accommodate changes easily.
Design for change can be:-
a. Change of Algorithm
To improve efficiency of some part of program, algorithm is changed. If the algorithm is confined to a well-
identified module, the change will be easy to apply. Eg:- replace inefficient sorting algorithm with a more
efficient one.
b.Change of data representation
Sometimes efficiency of a program can be increased if changes are made in representation of relevant data.
Eg:-from binary tree to a threaded tree. Refer Figure 4(a) each node of the tree has two pointer fields , one
pointing to its right sibling, if any, the other pointing to its first descendant , if any. Refer Figure4(b) one more

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:1 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

pointer may be added to make it more efficient to move along the data structure from the leaves towards the
root of the tree. The pointer we add connects any node to its parent node, if there is any.

(a) (b)
Figure 4:- Two sample data structures representing a tree
c. Change of underlying abstract machine
The programs we write are run by some abstract (or virtual machine).Underlying abstract machine changes, the
changes may affect application.This can be new release of operating system, new optimizing compiler, new
version of DBMS
d.Change of peripheral devices
A change of peripheral devices is strongly related to a change of the underlying abstract machine.
e. Change of social environment
Design also changes due to change in social environment. Eg:- new tax regime.
f. Change due to the development process
Software is developed incrementally .New and old parts must fit together properly.
2. Product families
Changes consists of building new versions of the same software; every version constitutes an individual
product, but set of versions constitute a family.
Different versions of the same system are referred to as a Product family.
A good example of product family is the mobile phone. Manufacturers want to sell their phones in different
countries. The basic software that controls the phone is the same, but its interface to the environment depends
on the geographic location.
Refer Figure1 nodes represented by circles stand for intermediate design descriptions and nodes represented
by squares represent a complete, executable version of the software.
Figure 1(a) shows version 1 of the product by translating the requirements into design stage 1, then stage 2.
Figure1(b) represents version 2 which is developed by modifying version 1, intially the application is put in
the intermediate design stage represented by node 4 by deleting parts of the code of version 1; then it is
transformed into a fully operational version represented by node 5.
Figure 1(c) represents a branch representing a different version(version 3) which starts from node 3.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:2 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

(a) (b) (c)

Figure 1:- Sequential design of a Product Family :a graphical view
1.1 Different types of Design Models
The design model can be viewed in two different dimensions
(Horizontally) The process dimension indicates the evolution of the parts of the design model as each
design task is executed
(Vertically) The abstraction dimension represents the level of detail as each element of the analysis model
is transformed into the design model and then iteratively refined
The design model has the following layered elements
Data/class design
Architectural design
Interface design
Component-level design
A fifth element that follows all of the others is deployment-level design

1. Data / class diagram

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.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:3 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

Part of data design may occur in conjunction with the design of software architecture. More detailed data design
occurs as each software component is designed.
Architectural design.
2. Architectural design
The architectural design defines the relationship between major structural elements of the software, the design
patterns that can be used to achieve the requirements that have been defined for the system, and the constraints
that affect the way in which architectural design patterns can be applied. The architectural design representation
the framework of a computer-based systemcan be derived from the system specification, the analysis
model, and the interaction of subsystems defined within the analysis model.
3. Interface design
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
4. Component-level design
The component-level design transforms structural elements of the software architecture
into a procedural description of software components.

2. Modularization techniques
2.1 Module Structure and its Representation
A module is a well-defined component of a software system.
A module can be a provider of computational resources or services.
When we decompose a system into modules , we must be able to describe the overall structure precisely.
It may be collection of routines, a collection of data , a collection of type definitions, or mixture of all of these.
Modular structure of a system can be described in terms of various types of mathematical relations. Let S be a
software system composed of modules M1, M2, . . ., Mn; that is
S = {M1, M2, . . ., Mn}
A relation r on S is a subset of S x S.
If two modules Mi and Mj are in S, we represent the fact that the pair <M i, Mj> is in r by using the infix notation
Mi r M j.
M
M1of a relation r on S is again a relation on S, written (r+ ). 1
Transitive closure
Mi r+ Mj iff Mi r Mj ( Mi and Mj are in S )
A relation is a hierarchy iff there are no cycles in the graph of the relation;
M1,2 this type of graph is called a directed
M1,1 M1,3
acyclic graph(DAG).
M2(a) M3
Figure 2 illustates generic graph and (b) represents a hierarchy, Directed acylic graph(DAG).

M1,2,1 M1,2,2

M4 M M1,2,1,1 M3 M2
5

M4
__________________________________________________________________________________________
M6
CS010 605 /SOFTWARE ENGINEERING Page No:4 Prepared By:
Merin Mary Philip
a) b)
 Dept of Computer Science and Engineering
CML

Figure 2:Graph representation of a relation amongh modules (a) General Graph (b) Directed acylic graph(DAG)

There are different kinds of relation for describing the modular structure of a software system , we have to study
these relations:-
1. USES relation
2. IS_COMPONENT_OF relation
1. USES relation
We say Mi USES Mj if Mj requires the presence of M j, because Mj provides the resources that M i needs to
accomplish its task.
If Mi USES Mj , we say that Mi is client of Mj , since Mi requires the services that M j provides. Conversely, Mj is
called the server.
We define level of a module in a hierarchy r as follows:-
1. Mi has level 0 if no Mj exists s.t. Mi r Mj
2. For each module Mi, let k be the maximum level of all nodes M j s.t. Mi r Mj. Then Mi has level k+1
USES relation provides a way to reason about coupling in a precise manner. With reference to the USES graph,
we can distinguish between the number of otgoing edges of a module(called the modules fan-out) and the number of
incoming edges (called fan-in).
A high fan-in is an indication of good design because a module with high fan-in represents a general abstraction
that is used heavily by other modules.
2. IS_COMPONENT_OF relation
IS_COMPONENT_OF relation is used to describe a higher level module as constituted by a number of lower
level modules
A IS_COMPONENT_OF B, if B consists of several modules, of which one is A,
Inverse of IS_COMPONENT_OF relation is COMPRISES.
If A IS_COMPONENT_OF B , then we can tell that B COMPRISES A.
Another relation is IS_COMPOSED_OF relation A IS_COMPOSED_OF {B,C} if A is made by
combining B and C.
Inverse of IS_COMPOSED_OF is IMPLEMENTS relation.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:5 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

Figure3:Graphical view of different relations

2.2 Interface and Information Hiding

Interface
The set of services that each module provides to its clients is called its interface. These services are said to be
exported by the module and imported by clients.The client imports the resources that are exported by its servers.
The way these services are accomplished by the module is its modules secret and is embedded in its
implementation.
The interface of a module M describes excatly what the client modules need to know in order to utilize the
services by M.
Information hiding
The clients of a module know about its services only through its interface;the implementation is hidden from
them.This means that the implementation may change without affecting the modules clients, provided that the
interface remains unchanged. Implementation secrets are hidden to clients.
Information should only be exposed to those parts of the program which need to access it. This involves the
creation of objects or abstract data types which maintain state and operations on that state.
The Modules should be designed specifically so that no information(Algorithm and data) contained within the
module is not accessible to the other module that have no need of that information.
Hiding implies that Effective modularity can be achieved by defining a set of independent modules that
communicate with one another only through information necessary to achieve software function.
2.2.1 How to design module interfaces?
A commonly used analogy to describe the concepts of an interface , an implementation, and information hiding is
illustrated in Figure 4 .
A module is like an iceberg, the interface- the visible part-is like the tip of the iceberg, and the implementation is
what is hidden by the surface of the sea. The tip is just a small part of the whole.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:6 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

Figure 4: The interface as the tip of the iceberg

2.2.2 Module secrets and design for change

To maximize the evolvability of a module implementation, its interface should export the minimum possible
amount of detail.
Another goal is to hide low level details and provide an abstract interface in order to make the design.
The changeable , hidden information becomes the secret of the module, we say that such information is
encapsulated within the module implementation.

2.3 Categories of Modules

Modules can often be designed to export any combination of resources. The nature of the exported resources also
depends on what the programming language used to implement the modules actullay supports.
Categorization of modules is a step towards the development of standard software engineering components.
There are three standard categories of modules , they are:-
1. Procedural Abstractions (Functional modules)
2. Libraries
3. Common pools of data
Two more general and abstract categories are:-
4. Abstract objects
5. Abstract data types
1. Functional modules(Procedural Abstractions)

Functional modules are traditional form of modularization. It provides just a procedure or a function that implements
some abstract operation.They are used to encapsulate an algorithm.Eg. sorting module, fast Fourier transform module
2. Libraries
A group of related procedural abstractions. 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.e.g., mathematical libraries.
3. Common pools of data

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:7 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

Another common type of module provides a common pool of data. Once the need for sharing data among several
modules is recongnized, we can group such data together in a common pool that is imported by all client modules, which
are then allowed to manipulate the data direclty, according to the structure used to represent the data, which is visible to
them.Eg:-the COMMON construct in FORTRAN.
4. Abstract objects
Data structure hidden to clients . They have a permanent , hidden , encapsulated data structure in their implementation
part.This implementation is visible to routines that are visible to routines that are internal to module but is hidden from
client modules. These hidden data structure provides these modules with state.
5. Abstract data types
An abstract data-type module 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 the algorithms used in the operations.
6. Generic modules (templates)
A generic module is not directly usable by clients.Its generally not a module but it can be described as a module
template.

2.4 Specific Techniques to Accommodate Change

We have to design modules in such a way that the changes we make can be accomadated easily. Three techniques that
enable us for easy design change are:-
1. Use of configuration constants
2. Conditional compilation
3. Software generation
1. Use of configuration constants
When required changes in software can be factored out into a set of constants they are known as configuration
constants. When we are changing constants in a program, then wherever it comes it needs to be changed. Solutions:-
1. factoring constant values into symbolic constants is a common implementation practice.
e.g., #define in C
#define MaxSpeed 5600;
2. Configuration constants may be grouped together into a module that provides common pool of data.When any
changes come this common pool of configuration constants can be changed.
2. Conditional compilation
All versions of a family are represented by one single source code. Source code that is relevant to only some versions is
bracketed by macro commands that are recognized by compiler. Conditional compilation when compiler is invoked ,
some parameters must be specified that describe which version of object code is to be produced; then the compiler
automatically ignores other source statements.
Example
# ifdef hardware-1
source fragment for hardware 1 ...
# endif

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:8 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

#ifdef hardware-2
...source fragment for hardware 2 ...
# endif
If , at compilation time, we specify switch D= hardware-1, only the code associated with hardware-1 will be compiled.
3. Software generation
Software generators are programs that build other programs. Example- A system for generating user interfaces that can be
found in most database management systems on personal computers.Changing the layout of screen according to users
taste can be accomplished quite easily and does not require coding. Compiler is another example of generators.There are
many generators inside a compiler. Input is Source program and output is Targeted Machine Code.

2.5 Stepwise Refinement

Stepwise refinement is an iterative process.

At each step the problem is decomposed into subproblems that are solved separately.
At each step, problem P decomposed into
sequence of subproblems: P1; P2; Pn
a selection:
if (cond) then
P1 ;
else
P2;
end if;
an iteration:
while (cond) loop
P1;
end loop
Decomposition tree:-Stepwise refinement process may be depicted by a decomposition tree (DT). Root
labeled by name of top problem.Subproblem nodes labeled as children of parent node corresponding to
problem.Children from left to right represent sequential order of execution. if and while nodes denoted by
suitable decoration.
Step 1
P; P problem to solve
Step 2
P1; P2; P3; P decomposed into sequence
Step 3
P1;
while C loop
P2,1; P2 decomposed into a loop
end loop;
P3;
Step 4

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:9 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

P1;
while C loop
if C1 then P2,1 decomposed into selection
P2,1,1;
else
P2,1,2;
end if;
end loop;
P3;
Figure 5 shows the decomposition tree.
P

P P P
1 2 3

C
P
2,1
C not C
1 1
P P
2,1, 1 2,1, 2
Figure 5: Decomposition tree of above program

2.5.1 An assessment of stepwise refinemen

Stepwise refinement is a programming technique, not a modularization technique.
Stepwise refinement is better for small programs but fails in large , problems related are:-
Subproblems tend to be analyzed in isolation
No emphasis is put by stepwise refinement is put by stepwise refinement on trying to generalize subproblems
in a way that would nake them reusable at different points within the derivation of the system.
No attention is paid to information hiding
Stepwise refinement does not draw the designers attention to the need for encapsulating changeable
information within modules.
No attention is paid to data
Stepwise refinement does not stress the use of information hiding modules.
Top-function may not exist
The method starts by stating the top problem, which is recursively detailed in terms of subproblems. In
stepwise refinement such top-function may not exist.
2.6 Top-Down And Bottom-Up Design

We can follow different strategies while we design a system.

Top-Down Strategy

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:10 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

In top-down strategy, we recursively apply decomposition through IS_COMPOSED_OF, until we break down the
system into manageable components.
Stepwise refinement is intrinsically top-down.

Bottom-Up Strategy

In bottom-up strategy, we start from what we wish to encapsulate within a module, recursively defining an
abstract interface, and then grouping together several modules to form a single new, higher level module that
comprises them.

Information hiding proceeds bottom-up.

We should first recognize what we wish to encapsulate within a module and then provide an abstract interface to
define the modules boundaries as seen from the clients.

Yo-yo design Strategy

A typical design strategy that may proceed partly from the top-down and partly from the bottom-up , depending
on the phase of the design of the nature of the application being designed. This design strategy is called Yo-yo design.
Organizing documentation as a top-down flow may be useful for reading purposes, even if the process followed
was not top-down.

Differences between Top-Down Strategy and Bottom-Up Strategy

Top-down design Bottom-up design

It starts by identifying the major components of the It starts with designing the most basic or primitive
system, decomposing them into their lower-level components and proceeds to higher-level components
components and iterating until the desired level of that use these lower-level components.
detail is achieved.

It starts from the highest level component of the It starts with the lowest level component of the
hierarchy and proceeds to lower levels. hierarchy and proceeds through progressively higher
levels.

It results in some form of stepwise refinement. It works with layers of abstraction.

Starting from an abstract design, in each step the Starting from the very bottom, operations that provide a
design is refined to a more concrete level, until we layer of abstraction are implemented, until the stage is
reach where no more refinement is needed and the reached where the operations supported by the layer are
design can be implemented directly. those desired by the system.

It is suitable only if the specifications are clearly It is suitable if a system is to be built from an existing
known. system.

It is suitable if a waterfall type of process model is It is suitable if an iterative enhancement type of process
being used. is being followed.

3. Handling anomalies

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:11 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

The designer must anticipate failures and plan to either avoid them or tolerate them. He must employ defensive
design.
Programs should continue to behave reasonably even in unexpected circumstances ie we should build robust
systems.
A module is anomalous if it fails to provide the service as expected and as specified in its interface.
The exceptions associated with a service denote the anomalies that may occur while that service is being
performed.
An exception must be raised when anomalous state is recognized.
Defensive design should distinguish between the correct behavior and the anamalous behavior of the module.
How can failures arise?
Module M should fail and raise an exception if
1. one of its clients does not satisfy the required protocol for invoking one of Ms services
2. M does not satisfy the required protocol when using one of its servers, and the server fails
3. hardware generated exception (e.g., division by zero)
What a module can do before failing?
Before failing, modules may try to recover from the anomaly by executing some exception handler (EH)
1. EH is a local piece of code that may try to recover from anomaly (if successful, module does not fail)
2. or may simply do some cleanup of the modules state and then let the module fail, signaling an exception
to its client.

4. Function Oriented and Object Oriented Design

4 .1 Object Oriented Design (OOD)

1. Object-oriented design transforms the analysis model created using object-oriented analysis into a design model
that serves as a blueprint for software construction.
2. The design of objectoriented software requires the definition of a multilayered software architecture, the
specification of subsystems that perform required functions and provide infrastructure support, a description of
objects (classes) that form the building blocks of the system, and a description of the communication mechanisms
that allow data to flow between layers, subsystems, and objects. Object-oriented design accomplishes all of these
things.
3. OOD is divided into two major activities: system design and object design. System design creates the product
architecture, defining a series of layers that accomplish specific system functions and identifying the classes that
are encapsulated by subsystems that reside at each layer. Object design focuses on the internal detail of individual
classes, defining attributes, operations, and message detail.
4.1.1 Design For Object-Oriented Systems
Four layers of the OO design pyramid are:-
1. The subsystem layer

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:12 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

It contains a representation of each of the subsystems that enable the software to achieve
its customer-defined requirements and to implement the technical infrastructure that
supports customer requirements.
2. The class and object layer
It contains the class hierarchies that enable the system to be created using generalizations
and increasingly more targeted specializations. This layer also contains representations of
each object.

3. The message layer

It contains the design details that enable each object to communicate with its collaborators.
This layer establishes the external and internal interfaces for the system.
4. The responsibilities layer
It contains the data structure and algorithmic design for all attributes and operations for
each object.

4.1.2 Conventional vs. OO Approaches

Figure 22.2 illustrates the relationship between the OO analysis model and design model that will be derived from it. The
subsystem design is derived by considering overall customer requirements (represented with use-cases) and the events
and states that are externally observable (the object-behavior model). Class and object design is mapped from the
description of attributes, operations, and collaborations contained in the CRC model. Message design is driven by the
object-relationship model, and responsibilities design is derived using the attributes, operations, and collaborations
described in the CRC model.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:13 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

4.1.3 Design Issues

Bertrand Meyer suggests five criteria for judging a design method's ability to achieve modularity and relates these to
object-oriented design:
1. Decomposabilitythe facility with which a design method helps the designer to decompose a large problem
into subproblems that are easier to solve.
2. Composabilitythe degree to which a design method ensures that program components (modules), once
designed and built, can be reused to create other systems.
3. Understandabilitythe ease with which a program component can be understood without reference to other
information or other modules.
4. Continuitythe ability to make small changes in a program and have these changes manifest themselves
with corresponding changes in just one or a very few modules.
5. Protectionan architectural characteristic that will reduce the propagation of side effects if an error does
occur in a given module.
4.1.4 OOD Landscape
A brief overview of the most important early OOD methods follows:
i. The Booch method- Booch method encompasses both a micro development process and a macro
development process.
ii. The Rumbaugh method- The object modeling technique encompasses a design activity that encourages
design to be conducted at two different levels of abstraction. System design focuses on the layout for the
components that are needed to construct a complete product or system.
iii. The Jacobson method- The design activity for OOSE (object-oriented software engineering) is a simplified
version of the proprietary objectory method, also developed by Jacobson. The design model emphasizes
traceability to the OOSE analysis model.
iv. The Coad and Yourdon method- The Coad and Yourdon method for OOD was developed by studying how
effective object-oriented designers do their design work. The design approach addresses not only the
application but also the infrastructure for the application and focuses on the representation of four major

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:14 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

system components: the problem domain component, the human interaction component, the task
management component, and the data management component.
v. The Wirfs-Brock method- Wirfs-Brock, Wilkerson, and Weiner define a continuum of technical tasks in
which analysis leads seamlessly into design. Protocols for each class are constructed by refining contracts
between objects.
4.2 Function Oriented Design
1. Design with functional units which transform inputs to outputs.
2. Function-Oriented Design is supported directly by most programming languages.
3. Most design methods are functional in their approach.
4. Main Function-Oriented Design concepts are cohesion and coupling.
5. Cohesion is the single-mindedness of a component.

6. It implies that a component or class encapsulates only attributes and operations that are closely related to one
another and to the class or component itself.
7. Kinds of cohesion
Sequential
Components or operations are grouped in a manner that allows the first to provide input to the next and so on in
order to implement a sequence of operations
Procedural
Components or operations are grouped in a manner that allows one to be invoked immediately after the preceding
one was invoked, even when no data passed between them
Temporal
Operations are grouped to perform a specific behavior
Utility
Components, classes, or operations are grouped within the same category because of similar general functions
but are otherwise unrelated to each other
8. Coupling is a qualitative measure of the degree to which operations and classes are connected to one another.
4.2.1 Components of Function-Oriented Design
1. Data-flow design
Model the data processing in the system using data-flow diagrams. Model the data processing in the
system using data-flow diagrams. They Are an integral part of many design methods

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:15 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

Figure:-Example of a simple Data Flow Diagram

2. Structural decomposition
Model how functions are decomposed to sub-functions using graphical structure charts. Structural
decomposition is concerned with developing a model of the design which shows the dynamic structure
i.e. function calls.
In essence, a data flow diagram is converted to a structure chart.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:16 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

3. Detailed design
The entities in the design and their interfaces are described in detail. These may be recorded in a data
dictionary.
Concerned with producing a short design specification (minispec) of each function. This should describe
the processing, inputs and outputs.

5. Case Study with UML and CASE Tool support

5. 1 Case Study with UML : Online Shopping Portal
1. Case Statement

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:17 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

In this case, we will be designing a simple online shopping portal .The site will provide a soothing shopping experience
for customers. The system will allow more than one categories and different brands under the segment. The case will
trace the following sequence.
2. Scenario
A customer visits the online shopping portal. A customer may buy item or just visit the page and logout. The customer
can select a segment, then a category, and brand to get the different products in the desired brand. The customer can
select the product for purchasing. The process can be repeated for more items. Once the customer finishes selecting the
product/s the cart can be viewed , If the customer wants to edit the final cart it can be done here. For final payment the
customer has to login the portal, if the customer is visiting for the first time he must register with the site, else the
customer must use the login page to proceed. Final cart is submitted for payment and card details and address(where
shipment has to bemade) are be confirmed by the customer .Customer is confirmed with a shipment Id and delivery of
goods within 15 days.
3. Actors
Customer
Administrator
4. Functionality
a. Portal
Allows the customer to view the different categories and further to different products within the brands.
The portal provides a bill and an shipmentId which can be used to track the delivery status of the goods purchased by
the customer.
b. Customer
Customers when enter the site and view the various products in different category.
Authentication of the customer is done for the payment of the shopping done
Customer can browses through the products available in the shop, can select some of them and put into the shopping cart.
Customer can anytime change the items in the cart either by adding new items or by removing existing items. Customer
proceeds towards the payment counter. Finalize product list of items he finally wish to buy and make the final payment.
c. Administrator
Updates the details of the different category ,segments etc
Verifies the customer card details and records the details for shipment of goods.

1. USE CASE DIAGRAM FOR ONLINE SHOPPING

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:18 Prepared By:
Merin Mary Philip
Dept of Computer Science and Engineering
CML

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:19 Prepared By:
Merin Mary Philip
Dept of Computer Science and Engineering
CML

2. CLASS- DIAGRAM FOR ONLINE SHOPPING

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:20 Prepared By:
Merin Mary Philip
Dept of Computer Science and Engineering
CML

3. ACTIVITY DIAGRAM FOR ONLINE SHOPPING

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:21 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

4. SEQUENCE DIAGRAM FOR ONLINE SHOPPING

5. STATE DIAGRAM FOR ONLINE SHOPPING

5.2 Case Study with CASE Tool support

(a) WHAT IS CASE?
Computer-aided software engineering (CASE) tools assist software engineering managers and
practitioners in every activity associated with the software process.
They automate project management activities, manage all work products produced throughout the
process, and assist engineers in their analysis, design, coding and test work.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:22 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

CASE tools can be integrated within a sophisticated environment.

The workshop for software engineering has been called an integrated project support environment and
the tools that fill the workshop are collectively called computer-aided software engineering.
CASE provides the software engineer with the ability to automate manual activities and to improve
engineering insight. Like computer-aided engineering and design tools that are used by engineers in
other disciplines, CASE tools help to ensure that quality is designed in before the product is built.
(b) BUILDING BLOCKS FOR CASE
Computer aided software engineering can be as simple as a single tool that supports a specific software
engineering activity or as complex as a complete "environment" that encompasses tools, a database,
people, hardware, a network, operating systems, standards, and myriad other components.
The building blocks for CASE are illustrated in Figure 10.1. Each building block forms a foundation for
the next, with tools sitting at the top of the heap.
Successful environments for software engineering are built on an environment architecture that
encompasses appropriate hardware and systems software. In addition, the environment architecture
must consider the human work patterns that are applied during the software engineering process.

Figure 10.1:-The building blocks for CASE

The environment architecture composed of the hardware platform and operating system support
lays the ground work for CASE.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:23 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

A set of portability services provides a bridge between CASE tools and their integration framework
and the environment architecture. Portability services allow CASE tools and their integration
framework to migrate across different hardware platforms and operating systems without significant
adaptive maintenance.
The integration framework is a collection of specialized programs that enables individual CASE tools
to communicate with one another, to create a project database, and to exhibit the same look and feel to
the end-user (the software engineer).
The relative levels of CASE integration are shown in Figure 10.2.
1 At the low end of the integration spectrum is the individual (point solution) tool. When
individual tools provide facilities for data exchange (most do), the integration level is improved
slightly. Such tools produce output in a standard format that should be compatible with other
tools that can read the format. In some cases, the builders of complementary CASE tools work
together to form a bridge between the tools (e.g., an analysis and design tool that is coupled with
a code generator). Using this approach, the synergy between the tools can produce end products
that would be difficult to create using either tool separately.
2 Single-source integration occurs when a single CASE tools vendor integrates a number of
different tools and sells them as a package. Although this approach is quite effective, the closed
architecture of most single-source environments precludes easy addition of tools from other
vendors.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:24 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

Figure 10.2:- Integration levels

3 At the high end of the integration spectrum is the integrated project support environment (IPSE).
Standards for each of the building blocks described previously have been created. CASE tool vendors
use IPSE standards to build tools that will be compatible with the IPSE and therefore compatible with
one another.
(c) A TAXONOMY OF CASE TOOLS
CASE tools can be classified by function, by their role as instruments for managers or technical people,
by their use in the various steps of the software engineering process, by the environment architecture
(hardware and software) that supports them, or even by their origin or cost . The taxonomy presented here
uses function as a primary criterion.
1 Business process engineering tools
Business process engineering tools provide a "meta-model" from which specific information
systems are derived.
Business information is modeled as it moves between various organizational entities within a
company.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:25 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

The primary objective for tools in this category is to represent business data objects, their
relationships, and how these data objects flow between different business areas within a
company.
2 Process modeling and management tools
Process modeling tools (also called process technology tools) are used to represent the key
elements of a process so that it can be better understood.
These tools can also provide links to process descriptions that help those involved in the process
to understand the work tasks that are required to perform it.
Process management tools provide links to other tools that provide support to defined process
activities.
3 Project planning tools
Tools in this category focus on two primary areas: software project effort and cost estimation
and project scheduling.
Estimation tools compute estimated effort, project duration, and recommended number of people
for a project.
Project scheduling tools enable the manager to define all project tasks, create a task network,
represent task interdependencies, and model the amount of parallelism possible for the project.
4 Risk analysis tools
Risk analysis tools enable a project manager to build a risk table by providing detailed guidance
in the identification and analysis of risks.

5 Project management tools

The project schedule and project plan must be tracked and monitored on a continuing basis. In
addition, a manager should use tools to collect metrics that will ultimately provide an indication
of software product quality.
Tools in the category are often extensions to project planning tools.
6 Requirements tracing tools
When large systems are developed, things "fall into the cracks." That is, the delivered system
does not fully meet customer specified requirements.
The objective of requirements tracing tools is to provide a systematic approach to the isolation
of requirements, beginning with the customer request for proposal or specification.
7 Metrics and management tools

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:26 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

Metrics or measurement tools focus on process and product characteristics. Management-

oriented tools capture project specific metrics (e.g., LOC/person-month, defects per function
point) that provide an overall indication of productivity or quality.
Technically oriented tools determine technical metrics that provide greater insight into the
quality of design or code.
8 Documentation tools
Document production and desktop publishing tools support nearly every aspect of software
engineering and represent a substantial "leverage" opportunity for all software developers.
Documentation tools provide an important opportunity to improve productivity.
9 System software tools
CASE is a workstation technology.
Therefore, the CASE environment must accommodate high-quality network system software,
object management services, distributed component support, electronic mail, bulletin boards,
and other communication capabilities.
10 Quality assurance tools
The majority of CASE tools that claim to focus on quality assurance are actually metrics tools
that audit source code to determine compliance with language standards. Other tools extract
technical metrics in an effort to project the quality of the software that is being built.
11 Database management tools
Database management software serves as a foundation for the establishment of a CASE database
(repository) that we have called the project database.
Database management tools for CASE are evolving from relational database management
systems to object oriented database management systems.

12 Software configuration management tools

Software configuration management lies at the kernel of every CASE environment.
Tools can assist in all five major SCM (Software Configuration Management) tasks
identification, version control, change control, auditing, and status accounting.
13 Analysis and design tools
Analysis and design tools enable a software engineer to create models of the system to be built.
The models contain a representation of data, function, and behavior (at the analysis level) and
characterizations of data, architectural, component-level, and interface design.
14 PRO/SIM tools

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:27 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

PRO/SIM (prototyping and simulation) tools provide the software engineer with the ability to
predict the behavior of a real-time system prior to the time that it is built.
In addition, these tools enable the software engineer to develop mock-ups of the real-time
system, allowing the customer to gain insight into the function, operation and response prior to
actual implementation.
15 Interface design and development tools
Interface design and development tools are actually a tool kit of software components (classes)
such as menus, buttons, window structures, icons, scrolling mechanisms, device drivers, and so
forth.
16 Prototyping tools
A variety of different prototyping tools can be used.
Screen painters enable a software engineer to define screen layout rapidly for interactive
applications.
A variety of fourth generation tools have prototyping features.
17 Programming tools
The programming tools category encompasses the compilers, editors, and debuggers that are
available to support most conventional programming languages.
18 Web development tools
The activities associated with Web engineering are supported by a variety of tools for WebApp
development.
These include tools that assist in the generation of text, graphics, forms, scripts, applets, and
other elements of a Web page.

19 Integration and testing tools

In their directory of software testing tools, Software Quality Engineering defines the following testing
tools categories:-
a) Data acquisitiontools that acquire data to be used during testing.
b) Static measurementtools that analyze source code without executing test cases.
c) Dynamic measurementtools that analyze source code during execution.
d) Simulationtools that simulate function of hardware or other externals.
e) Test managementtools that assist in the planning, development, and control of testing.
f) Cross-functional toolstools that cross the bounds of the preceding categories.
20 Static analysis tools
Static testing tools assist the software engineer in deriving test cases.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:28 Prepared By:
Merin Mary Philip
 Dept of Computer Science and Engineering
CML

Three different types of static testing tools are used in the industry: code based testing tools, specialized
testing languages, and requirements-based testing tools.
a) Code-based testing tools accept source code (or PDL) as input and perform a number of
analyses that result in the generation of test cases.
b) Specialized testing languages (e.g., ATLAS) enable a software engineer to write detailed
test specifications that describe each test case and the logistics for its execution.
c) Requirements-based testing tools isolate specific user requirements and suggest test
cases (or classes of tests) that will exercise the requirements.
21 Dynamic analysis tools
Dynamic testing tools interact with an executing program, checking path coverage, testing assertions
about the value of specific variables, and otherwise instrumenting the execution flow of the program.
Dynamic tools can be either intrusive or nonintrusive.
22 Test management tools
Test management tools are used to control and coordinate software testing for each of the major
testing steps.
Tools in this category manage and coordinate regression testing, perform comparisons that
ascertain differences between actual and expected output, and conduct batch testing of programs
with interactive human/computer interfaces.
23 Client/server testing tools
The c/s environment demands specialized testing tools that exercise the graphical user interface
and the network communications requirements for client and server.
24 Reengineering tools
The reengineering tools category can be subdivided into the following functions:
o Reverse engineering to specification tools take source code as input and generate
graphical structured analysis and design models, where-used lists, and other design
information.
o Code restructuring and analysis tools analyze program syntax, generate a control flow
graph, and automatically generate a structured program.
o On-line system reengineering tools are used to modify on-line database systems.

__________________________________________________________________________________________
CS010 605 /SOFTWARE ENGINEERING Page No:29 Prepared By:
Merin Mary Philip