MODULE 3

By, Anjana V
 Object-Oriented Design

After the analysis phase, the conceptual model is developed further into an object-
oriented model using object-oriented design (OOD).
• In OOD, the technology-independent concepts in the analysis model are mapped
onto implementing classes, constraints are identified, and interfaces are
designed, resulting in a model for the solution domain.
• In a nutshell, a detailed description is constructed specifying how the system is
to be built on concrete technologies
• In the object-oriented design method, the system is viewed as a collection of
objects (i.e., entities).
• The state is distributed among the objects, and each object handles its state
data.
• For example, in a Library Automation Software, each library representative may
be a separate object with its data and functions to operate on these data.
• The tasks defined for one purpose cannot refer or change data of other objects.
Objects have their internal data which represent their state.
• Similar objects create a class.
• In other words, each object is a member of some class. Classes may inherit
features from the superclass.
• The focus is on capturing the structure and behavior of information systems into
small modules that combines both data and process.
• The main aim of Object Oriented Design (OOD) is to improve the quality and
productivity of system analysis and design by making it more usable.
• In analysis phase, OO models are used to fill the gap between problem and
solution.
• It performs well in situation where systems are undergoing continuous design,
adaption, and maintenance.
• It identifies the objects in problem domain, classifying them in terms of data and
behavior.
1. Objects

All entities involved in the solution design are known as objects. For example,
person, banks, company, and users are considered as objects. Every entity has
some attributes associated with it and has some methods to perform on the
attributes.

2. Classes

A class is a generalized description of an object. An object is an instance of a

class. A class defines all the attributes, which an object can have and methods,
which represents the functionality of the object.

3. Messages

Objects communicate by message passing. Messages consist of the integrity of

the target object, the name of the requested operation, and any other action
needed to perform the function. Messages are often implemented as procedure
or function calls.

4. Abstraction
In object-oriented design, complexity is handled using abstraction. Abstraction is
the removal of the irrelevant and the amplification of the essential
 5. Encapsulation

Encapsulation is also called an information hiding concept. The data and

operations are linked to a single unit. Encapsulation not only bundles essential
information of an object together but also restricts access to the data and
methods from the outside world.

6. Inheritance

OOD allows similar classes to stack up in a hierarchical manner where the lower
or sub-classes can import, implement, and re-use allowed variables and
functions from their immediate [Link] property of OOD is called an
inheritance. This makes it easier to define a specific class and to create
generalized classes from specific ones.

7. Polymorphism

OOD languages provide a mechanism where methods performing similar tasks

but vary in arguments, can be assigned the same name. This is known as
polymorphism, which allows a single interface is performing functions for different
types. Depending upon how the service is invoked, the respective portion of the
code gets executed.

The stages for object–oriented design

• Definition of the context of the system
• Designing system architecture
• Identification of the objects in the system
• Construction of design models
• Specification of object interfaces

Benefits of OO Model
• It facilitates changes in the system at low cost.
• It promotes the reuse of components.
• It simplifies the problem of integrating components to configure large system.
• It simplifies the design of distributed systems.
Modularization
• Modularization is the process of dividing a software system into multiple
independent modules where each module works independently.
• There are many advantages of Modularization in software engineering.
▪ Easy to understand the system.
▪ System maintenance is easy.
▪ A module can be used many times as their requirements. No need to
write it again and again.
Coupling
• Coupling is the measure of the degree of interdependence between the modules.
• Two modules that are tightly coupled are strongly dependent on each other.
• However, two modules that are loosely coupled are not dependent on each
other.
• Uncoupled modules have no interdependence at all within them.
• A good software will have low coupling.

• Coupling is measured by the number of relations between the modules.

• That is, the coupling increases as the number of calls between modules increase
or the amount of shared data is large.
• Thus, it can be said that a design with high coupling will have more errors.
Types of Module Coupling

1. No direct Coupling

• There is no direct coupling between M1 and M2.

• In this case, modules are subordinates to different modules.
• Therefore, no direct coupling.

2. Data Coupling

• When data of one module is passed to another module, this is called data
coupling.
• In data coupling, the components are independent to each other and communicating
through data.
• Module communications don’t contain tramp data.
• Example-customer billing system.

3. Stamp Coupling

• Two modules are stamp coupled if they communicate using composite data
items such as structure, objects, etc.
• When the module passes non-global data structure or entire structure to another
module, they are said to be stamp coupled.
• For example, passing structure variable in C or object in C++ language to a
module.

4. Control Coupling

• Control Coupling exists among two modules if data from one module is used to
direct the structure of instruction execution in another.
• It can be bad if parameters indicate completely different behavior and good if parameters
allow factoring and reuse of functionality.
• Example- sort function that takes comparison function as an argument.

5. External Coupling

• External Coupling arises when two modules share an externally imposed data
format, communication protocols, or device interface.
• This is related to communication to external tools and devices.

6. Common Coupling

• Two modules are common coupled if they share information through some global
data items.
• The changes in global data mean tracing back to all modules which access that data to
evaluate the effect of the change.
• So it has got disadvantages like difficulty in reusing modules, reduced ability to control
data accesses and reduced maintainability.

7. Content Coupling

• Content Coupling exists among two modules if they share code, e.g., a branch
from one module into another module.
• This is the worst form of coupling and should be avoided.
Cohesion
• cohesion defines to the degree to which the elements of a module belong
together.
• Thus, cohesion measures the strength of relationships between pieces of
functionality within a given module.
• For example, in highly cohesive systems, functionality is strongly related.
• Basically, cohesion is the internal glue that keeps the module together.
• Cohesion is an ordinal type of measurement and is generally described as "high
cohesion" or "low cohesion."
• A good software design will have high cohesion.
Types of Modules Cohesion

1. Functional Cohesion

• Functional Cohesion is said to exist if the different elements of a module,

cooperate to achieve a single function.
• It is an ideal situation.

2. Sequential Cohesion

• A module is said to possess sequential cohesion if the element of a module form

the components of the sequence, where the output from one component of the
sequence is input to the next.
• . It occurs naturally in functional programming languages.

3. Communication Cohesion
• A module is said to have communicational cohesion, if all tasks of the module
refer to or update the same data structure.
• e.g., the set of functions defined on an array or a stack.

4. Procedural Cohesion

• A module is said to be procedural cohesion if the set of purpose of the module

are all parts of a procedure in which particular sequence of steps has to be
carried out for achieving a goal.
• Actions are still weakly connected and unlikely to be reusable.
• e.g., the algorithm for decoding a message, calculate student GPA, print student
record, calculate cumulative GPA, print cumulative GPA.

5. Temporal Cohesion

• When a module includes functions that are associated by the fact that all the
methods must be executed in the same time, the module is said to exhibit
temporal cohesion.
• This cohesion contains the code for initializing all the parts of the system.
• Lots of different activities occur, all at init time.

6. Logical Cohesion

• A module is said to be logically cohesive if all the elements of the module

perform a similar operation.
• All the code for these functions is in the same component.
• Operations are related, but the functions are significantly different.
• For example Error handling, data input and data output, etc.

7. Coincidental Cohesion

• A module is said to have coincidental cohesion if it performs a set of tasks that

are associated with each other very loosely, if at all.
• It is accidental and the worst form of cohesion.
• Eg. print next line and reverse the characters of a string in a single component.
 Coupling Cohesion

Coupling is also called Inter- Cohesion is also called Intra-Module Binding.

Module Binding.

Coupling shows the relationships Cohesion shows the relationship within the module.
between modules.

Coupling shows the Cohesion shows the module's

relative independence between relative functional strength.
the modules.

While creating, you should aim While creating you should aim for high cohesion, i.e., a
for low coupling, i.e., cohesive component/ module focuses on a single
dependency among modules function (i.e., single-mindedness) with little interaction
should be less. with other modules of the system.

In coupling, modules are linked In cohesion, the module focuses on a single thing.
to the other modules.
By, Minsha
 Functional independence

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. A functionally independent module has minimal interaction with other modules.

Need for functional independence

Functional independence is a key to any good design due to the following reasons:

 Error isolation: Functional independence reduces error propagation. The reason behind this
is that if a module is functionally independent, its degree of interaction with the other
modules is less. Therefore, any error existing in a module would not directly effect the other
modules.
 Scope of reuse: Reuse of a module becomes possible. Because each module does some well-
defined and precise function, and the interaction of the module with the other modules is
simple and minimal. Therefore, a cohesive module can be easily taken out and reused in a
different program.
 Understandability: Complexity of the design is reduced, because different modules can be
understood in isolation as modules are more or less independent of each other.
Unified Modeling Language (UML)
UML is a general purpose modelling language. The main aim of UML is to define a standard
way to visualize the way a system has been designed. It is quite similar to blueprints used in
other fields of engineering.
• UML is not a programming language, it is rather a visual language.
• UML is linked with object oriented design and analysis. UML makes the use of elements
and forms associations between them to form diagrams.

Diagrams in UML can be broadly classified as:

1. Structural Diagrams – Capture static aspects or structure of a system. Structural
Diagrams include: Component Diagrams, Object Diagrams, Class Diagrams and
Deployment Diagrams.
2. Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior
diagrams include: Use Case Diagrams, State Diagrams, Activity Diagrams and
Interaction Diagrams.
The hierarchy of diagrams according to UML :
 Object Oriented Concepts Used in UML –
• Class – A class defines the blue print i.e. structure and functions of an object.
• Objects – Objects help us to decompose large systems and help us to modularize
our system. Modularity helps to divide our system into understandable
components so that we can build our system piece by piece. An object is the
fundamental unit (building block) of a system which is used to depict an entity.
• Inheritance – Inheritance is a mechanism by which child classes inherit the
properties of their parent classes.
• Abstraction – Mechanism by which implementation details are hidden from user.
• Encapsulation – Binding data together and protecting it from the outer world is
referred to as encapsulation.
• Polymorphism – Mechanism by which functions or entities are able to exist in
different forms.

Structural UML Diagrams

1. Class Diagram – The most widely use UML diagram is the class diagram.
It is the building block of all object oriented software systems
 2. Composite Structure Diagram – We use composite structure diagrams
to represent the internal structure of a class and its interaction points
with other parts of the system.
3. Object Diagram – An Object Diagram can be referred to as a screenshot
of the instances in a system and the relationship that exists between
them.
4. Component Diagram – Component diagrams are used to represent the
how the physical components in a system have been organized. We use
them for modelling implementation details.
5. Deployment Diagram – Deployment Diagrams are used to represent
system hardware and its software.
6. Package Diagram – We use Package Diagrams to depict how packages
and their elements have been organized.

Behavior Diagrams
1. State Machine Diagrams – A state diagram is used to represent the
condition of the system or part of the system at finite instances of time.
2. Activity Diagrams – We use Activity Diagrams to illustrate the flow of
control in a system.
3. Use Case Diagrams – Use Case Diagrams are used to depict the
functionality of a system or a part of a system.
4. Sequence Diagram – A sequence diagram simply depicts interaction
between objects in a sequential order i.e. the order in which these
interactions take place.
5. Communication Diagram – A Communication Diagram(known as
Collaboration Diagram in UML 1.x) is used to show sequenced
messages exchanged between objects.
6. Interaction Overview Diagram – An Interaction Overview Diagram
models a sequence of actions and helps us simplify complex
interactions into simpler occurrences.
 7. Timing Diagram – Timing Diagram are a special form of Sequence
diagrams which are used to depict the behavior of objects over a time
frame.

Use-Case Model
A use-case model is a model of how different types of users
interact with the system to solve a problem. As such, it describes the goals of the
users, the interactions between the users and the system, and the required
behavior of the system in satisfying these goals.

A use-case model consists of a number of model elements. The most important

model elements are: use cases, actors and the relationships between them.

The use-case model may contain packages that are used to structure the model to
simplify analysis, communications, navigation, development, maintenance and
planning.

Basic model elements

The use-case model contains, as a minimum, the following basic model elements.

Actor
A model element representing each actor. Properties include the actors name and
brief description. See Concept: Actor for more information.

Use Case
A model element representing each use case. Properties include the use case
name and use case specification. See Artifact: Use Case and Concept: Use Case for
more information.

Associations
Associations are used to describe the relationships between actors and the use
cases they participate in. This relationship is commonly known as a
“communicates-association”.

Advanced model elements

The use-case model may also contain the following advanced model elements.

Subject
A model element that represents the boundary of the system of interest.

Use-Case Package
A model element used to structure the use case model to simplify analysis,
communications, navigation, and planning. If there are many use cases or actors,
you can use use-case packages to further structure the use-case model in much
the same manner you use folders or directories to structure the information on
your hard-disk.

You can partition a use-case model into use-case packages for several reasons,
including:

To reflect the order, configuration, or delivery units in the finished system thus
supporting iteration planning.

To support parallel development by dividing the problem into bite-sized pieces.

To simplify communication with different stakeholders by creating packages for

containing use cases and actors relevant to a particular stakeholder.

Generalizations
A relationship between actors to support re-use of common properties.
By, Denson C Lona
 UML
A UML diagram is a diagram based on the UML (Unified Modeling Language)
with the purpose of visually representing a system along with its main actors, roles,
actions, artifacts or classes, in order to better understand, alter, maintain, or
document information about the system
UML is an acronym that stands for Unified Modeling Language. Simply put, UML
is a modern approach to modeling and documenting software. In fact, it’s one of
the most popular business process modeling techniques.

class diagram
Class UML diagram is the most common diagram type for software
documentation. Since most software being created nowadays is still based on
the Object-Oriented Programming paradigm, using class diagrams to document the
software turns out to be a common-sense solution. This happens because OOP is
based on classes and the relations between them.

In a nutshell, class diagrams contain classes, alongside with their attributes (also
referred to as data fields) and their behaviors (also referred to as member
functions). More specifically, each class has 3 fields: the class name at the top, the
class attributes right below the name, the class operations/behaviors at the bottom.
The relation between different classes (represented by a connecting line), makes up
a class diagram.

How to Draw a Class Diagram

Class diagrams are the most popular UML diagrams used for construction of
software applications. It is very important to learn the drawing procedure of class
diagram.
Class diagrams have a lot of properties to consider while drawing but here the
diagram will be considered from a top level view.
Class diagram is basically a graphical representation of the static view of the
system and represents different aspects of the application. A collection of class
diagrams represent the whole system.
The following points should be remembered while drawing a class diagram −
• The name of the class diagram should be meaningful to describe the aspect
of the system.
• Each element and their relationships should be identified in advance.
• Responsibility (attributes and methods) of each class should be clearly
identified
• For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
• Use notes whenever required to describe some aspect of the diagram. At the
end of the drawing it should be understandable to the developer/coder.
• Finally, before making the final version, the diagram should be drawn on
plain paper and reworked as many times as possible to make it correct.
The following diagram is an example of an Order System of an application. It
describes a particular aspect of the entire application.
• First of all, Order and Customer are identified as the two elements of the
system. They have a one-to-many relationship because a customer can have
multiple orders.
• Order class is an abstract class and it has two concrete classes (inheritance
relationship) SpecialOrder and NormalOrder.
• The two inherited classes have all the properties as the Order class. In
addition, they have additional functions like dispatch () and receive ().
The following class diagram has been drawn considering all the points mentioned
above.
 Interaction diagram
From the term Interaction, it is clear that the diagram is used to describe some
type of interactions among the different elements in the model. This interaction is
a part of dynamic behavior of the system.
This interactive behavior is represented in UML by two diagrams known
as Sequence diagram and Collaboration diagram. The basic purpose of both the
diagrams are similar.
Sequence diagram emphasizes on time sequence of messages and collaboration
diagram emphasizes on the structural organization of the objects that send and
receive messages.
 Purpose of Interaction Diagrams

The purpose of interaction diagrams is to visualize the interactive behavior of the

system. Visualizing the interaction is a difficult task. Hence, the solution is to use
different types of models to capture the different aspects of the interaction.
Sequence and collaboration diagrams are used to capture the dynamic nature but
from a different angle.
The purpose of interaction diagram is −
• To capture the dynamic behaviour of a system.
• To describe the message flow in the system.
• To describe the structural organization of the objects.
• To describe the interaction among objects.

How to Draw an Interaction Diagram?

As we have already discussed, the purpose of interaction diagrams is to capture

the dynamic aspect of a system. So to capture the dynamic aspect, we need to
understand what a dynamic aspect is and how it is visualized. Dynamic aspect can
be defined as the snapshot of the running system at a particular moment
We have two types of interaction diagrams in UML. One is the sequence diagram
and the other is the collaboration diagram. The sequence diagram captures the
time sequence of the message flow from one object to another and the
collaboration diagram describes the organization of objects in a system taking part
in the message flow.
Following things are to be identified clearly before drawing the interaction
diagram
• Objects taking part in the interaction.
• Message flows among the objects.
• The sequence in which the messages are flowing.
• Object organization.
Following are two interaction diagrams modeling the order management system.
The first diagram is a sequence diagram and the second is a collaboration diagram
The Sequence Diagram
The sequence diagram has four objects (Customer, Order, SpecialOrder and
NormalOrder).
The following diagram shows the message sequence for SpecialOrder object and
the same can be used in case of NormalOrder object. It is important to understand
the time sequence of message flows. The message flow is nothing but a method
call of an object.
The first call is sendOrder () which is a method of Order object. The next call
is confirm () which is a method of SpecialOrder object and the last call
is Dispatch () which is a method of SpecialOrder object. The following diagram
mainly describes the method calls from one object to another, and this is also the
actual scenario when the system is running.
 The Collaboration Diagram
The second interaction diagram is the collaboration diagram. It shows the object
organization as seen in the following diagram. In the collaboration diagram, the
method call sequence is indicated by some numbering technique. The number
indicates how the methods are called one after another. We have taken the same
order management system to describe the collaboration diagram.
Method calls are similar to that of a sequence diagram. However, difference being
the sequence diagram does not describe the object organization, whereas the
collaboration diagram shows the object organization.
To choose between these two diagrams, emphasis is placed on the type of
requirement. If the time sequence is important, then the sequence diagram is used.
If organization is required, then collaboration diagram is used.
 Activity diagram
Activity diagram is another important diagram in UML to describe the dynamic
aspects of the system.
Activity diagram is basically a flowchart to represent the flow from one activity to
another activity. The activity can be described as an operation of the system.
The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent. Activity diagrams deal with all type of flow
control by using different elements such as fork, join, etc

Purpose of Activity Diagrams

The basic purposes of activity diagrams is similar to other four diagrams. It

captures the dynamic behavior of the system. Other four diagrams are used to
show the message flow from one object to another but activity diagram is used to
show message flow from one activity to another.
Activity is a particular operation of the system. Activity diagrams are not only
used for visualizing the dynamic nature of a system, but they are also used to
construct the executable system by using forward and reverse engineering
techniques. The only missing thing in the activity diagram is the message part.
It does not show any message flow from one activity to another. Activity diagram
is sometimes considered as the flowchart. Although the diagrams look like a
flowchart, they are not. It shows different flows such as parallel, branched,
concurrent, and single.
The purpose of an activity diagram can be described as −
• Draw the activity flow of a system.
• Describe the sequence from one activity to another.
• Describe the parallel, branched and concurrent flow of the system.

How to Draw an Activity Diagram?

Activity diagrams are mainly used as a flowchart that consists of activities
performed by the system. Activity diagrams are not exactly flowcharts as they
have some additional capabilities. These additional capabilities include branching,
parallel flow, swimlane, etc.
Before drawing an activity diagram, we must have a clear understanding about the
elements used in activity diagram. The main element of an activity diagram is the
activity itself. An activity is a function performed by the system. After identifying
the activities, we need to understand how they are associated with constraints and
conditions.
Before drawing an activity diagram, we should identify the following elements −
• Activities
• Association
• Conditions
• Constraints
Once the above-mentioned parameters are identified, we need to make a mental
layout of the entire flow. This mental layout is then transformed into an activity
diagram.
Following is an example of an activity diagram for order management system. In
the diagram, four activities are identified which are associated with conditions.
One important point should be clearly understood that an activity diagram cannot
be exactly matched with the code. The activity diagram is made to understand the
flow of activities and is mainly used by the business users
Following diagram is drawn with the four main activities −
• Send order by the customer
• Receipt of the order
• Confirm the order
• Dispatch the order
After receiving the order request, condition checks are performed to check if it is
normal or special order. After the type of order is identified, dispatch activity is
performed and that is marked as the termination of the process.
By, Mohamed Anas
 Statechart Diagrams
 Statechart diagrams are also used for forward and reverse engineering of a system.
 A Statechart diagram describes a state machine. State machine can be defined as a machine
which defines different states of an object and these states are controlled by external or internal
events.
 Statechart diagram describes the flow of control from one state to another state. States are
defined as a condition in which an object exists and it changes when some event is triggered.
The most important purpose of Statechart diagram is to model lifetime of an object from
creation to termination.

Following are the main purposes of using Statechart diagrams −

✓ To model the dynamic aspect of a system.
✓ To model the life time of a reactive system.
✓ To describe different states of an object during its life time.

Basic components of a statechart diagram –

Initial state – We use a black filled circle represent the initial state of a System or a class.

Figure – initial state notation

Transition – We use a solid arrow to represent the transition or change of control from one state
to another. The arrow is labelled with the event which causes the change in state.

Figure – transition
State – We use a rounded rectangle to represent a state. A state represents the conditions or

circumstances of an object of a class at an instant of time.

Figure – state notation
Fork – We use a rounded solid rectangular bar to represent a Fork notation with incoming arrow
from the parent state and outgoing arrows towards the newly created states. We use the fork
notation to represent a state splitting into two or more concurrent states.

1
Figure – a diagram using the fork notation
Join – We use a rounded solid rectangular bar to represent a Join notation with incoming arrows
from the joining states and outgoing arrow towards the common goal state. We use the join
notation when two or more states concurrently converge into one on the occurrence of an
event or events.

Figure – a diagram using join notation

Self transition – We use a solid arrow pointing back to the state itself to represent a self
transition. There might be scenarios when the state of the object does not change upon the
occurrence of an event. We use self transitions to represent such cases.

Figure – self transition notation

Composite state – We represent a state with internal activities using a composite state.

2
Figure – a state with internal activities
Final state – We use a filled circle within a circle notation to represent the final state in a state
machine diagram.

Figure – final state notation

Steps to draw a state diagram
➢ Identify the initial state and the final terminating states.
➢ Identify the possible states in which the object can exist (boundary values corresponding
to different attributes guide us in identifying different states).
➢ Label the events which trigger these transitions.
Example – – A State diagram for user

varification

Deployment diagram
 Deployment diagrams are used to visualize the topology of the physical components of a
system, where the software components are deployed.
 Deployment diagrams are used to describe the static deployment view of a system.
Deployment diagrams consist of nodes and their relationships
The purpose of deployment diagrams can be described as −

✓ Visualize the hardware topology of a system.

✓ Describe the hardware components used to deploy software components.
✓ Describe the runtime processing nodes.
Deployment diagrams are useful for system engineers. An efficient deployment diagram
is very important as it controls the following parameters −
• Performance

3
 • Scalability
• Maintainability
• Portability.
Here, we have shown nodes as −Monitor,Modem,Caching server,Server.
The application is assumed to be a web-based application, which is deployed in a
clustered environment using server 1, server 2, and server 3. The user connects to
the application using the Internet. The control flows from the caching server to the
clustered environment.

The following deployment diagram has been drawn considering all the points
mentioned above.

UML Deployment Diagram

Deployment diagrams can be used −

• To model the hardware topology of a system.
• To model the embedded system.
• To model the hardware details for a client/server system.
• To model the hardware details of a distributed application.
• For Forward and Reverse engineering.

Data Flow Diagram

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within
a system. A neat and clear DFD can depict the right amount of the system requirement
graphically. It can be manual, automated, or a combination of both.
The following observations about DFDs are essential
✓ All names should be unique. This makes it easier to refer to elements in the DFD.

4
 ✓ Remember that DFD is not a flow chart. Arrows is a flow chart that represents the
order of events; arrows in DFD represents flowing data. A DFD does not involve any
order of events.
✓ Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box
in a DFD, suppress that urge! A diamond-shaped box is used in flow charts to
represents decision points with multiple exists paths of which the only one is taken.
This implies an ordering of events, which makes no sense in a DFD.
✓ Do not become bogged down with details. Defer error conditions and error handling
until the end of the analysis.

Standard symbols for DFD

• Circle: A circle (bubble) shows a process that transforms data

• Data Flow: A curved line shows the flow of data into or out of a process or data
store.
• Data Store: A set of parallel lines shows a place for the collection of data items. A
data store indicates that the data is stored which can be used at a later stage or
by the other processes in a different order. The data store can have an element
or group of elements.
• Source or Sink: Source or Sink is an external entity and acts as a source of system
inputs or sink of system outputs.

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of [Link] in DFD are
numbered 0, 1, 2 or beyond. Here, we will see primarily three levels in the data flow diagram, which are:
0-level DFD, 1-level DFD, and 2-level DFD.

Level 0 or Context diagram--a basic overview of the system in general terms. It includes
all components of the system. Usually presented to a broad audience — such as customers,
analysts, and developers;

Level 1 -- slightly more detailed version of Level 0. It can be dedicated to the depiction of
specific elements of the system. The difference is in the breaking down of the items into sub-
elements.

5
Level 2 --further detailing of the processes. It can relate to particular
[Link] supplemented with extensive commentary to clarify individual bits;

Level 3-- and beyond is further elaboration. It can be applied to specify a particular process
through and through.

6
By, Mohamed Ajmal
REUSABILITY
Reusability is the use of existing assets in some form within the software product development
process; these assets are products and by-products of the software development life cycle and include
code, software components, test suites, designs and documentation.

INTEROPERABILITY
Interoperability is the property that allows for the unrestricted sharing of resources between
different systems. Approaches to improving or achieving interoperability include conducting
compatibility tests, engineering products with a common standard and using the same technology, coding
language or syntax across multiple systems when appropriate.

PORTABILITY
Portability in high-level computer programming is the usability of the same software in different
environments. The pre requirement for portability is the generalized abstraction between the application
logic and system interfaces. When software with the same functionality is produced for several computing
platforms, portability is the key issue for development cost reduction.

PORTABILITY AND INTEROPERABILITY

A portable application is not necessarily an interoperable one. Equally so, an interoperable
application is not necessarily portable. Experience dictates that you need the right blend of portability and
interoperability to create successful applications.

DESIGN WITH REUSE

Approach to development based on the reuse of existing software is now the norm for many types
of system development. A reuse-based approach is now widely used for web-based systems of all kinds,
scientific software, and, increasingly, in embedded systems engineering.
Software reuse is possible at a number of different levels, as shown

1. The abstraction level: At this level, we don’t reuse software directly but rather use knowledge of
successful abstractions in the design of your software.
2. The object level: At this level, we directly reuse objects from a library rather than writing the code
yourself. To implement this type of reuse, we have to find appropriate libraries and discover if the
objects and methods offer the functionality that you need.
3. The component level: Components are collections of objects and object classes that operate
together to provide related functions and services. We often have to adapt and extend the
component by adding some code of your own
4. The system level: At this level, you reuse entire application systems. This function usually involves
some kind of configuration of these systems. This may be done by adding and modifying code (if
reusing a software product line) or by using the system’s own configuration interface.
REUSE-BASED SOFTWARE ENGINEERING
● Application system reuse
The whole of an application system may be reused either by incorporating it without
change into other systems (COTS reuse) or by developing application families.
● Component reuse
Components of an application from sub-systems to single objects may be reused.
● Function reuse
Software components that implement a single well-defined function may be reused.
REUSE PRACTICE
● Application system reuse
Widely practised as software systems are implemented as application families. COTS
reuse is becoming increasingly common.
● Component reuse
Now seen as the key to effective and widespread reuse through component-based
software engineering. However, it is still relatively immature
● Function reuse
Common in some application domains (e.g. engineering) where domain-specific libraries
of reusable functions have been established
BENEFITS OF REUSE
● Increased reliability
Components exercised in working systems
● Reduced process risk
Less uncertainty in development costs
● Effective use of specialists
Reuse components instead of people
● Standards compliance
Embed standards in reusable components
● Accelerated development
Avoid original development and hence speed-up production
REUSE PROBLEMS
● Increased maintenance costs
● Lack of tool support
● Not-invented-here syndrome
● Maintaining a component library
● Finding and adapting reusable components
By, Limitha
Component-Level Design in software engineering
As soon as the first iteration of architectural design is complete, component-level design takes place. The
objective of this design is to transform the design model into functional software. To achieve this
objective, the component-level design represents -the internal data structures and processing details of all
the software components (defined during architectural design) at an abstraction level, closer to the actual
code. In addition, it specifies an interface that may be used to access the functionality of all the software
components.

The component-level design can be represented by using different approaches. One approach is to use a
programming language while other is to use some intermediate design notation such as graphical (DFD,
flowchart, or structure chart), tabular (decision table), or text-based (program design language) whichever
is easier to be translated into source code.

The component-level design provides a way to determine whether the defined algorithms, data structures,
and interfaces will work properly. Note that a component (also known as module) can be defined as a
modular building block for the software. However, the meaning of component differs according to how
software engineers use it. The modular design of the software should exhibit the following sets of
properties.

Provide simple interface: Simple interfaces decrease the number of interactions. Note that the number of
interactions is taken into account while determining whether the software performs the desired function.
Simple interfaces also provide support for reusability of components which reduces the cost to a greater
extent. It not only decreases the time involved in design, coding, and testing but the overall software
development cost is also liquidated gradually with several projects. A number of studies so far have
proven that the reusability of software design is the most valuable way of reducing the cost involved in
software development.

Ensure information hiding: The benefits of modularity cannot be achieved merely by decomposing a
program into several modules; rather each module should be designed and developed in such a way that
the information hiding is ensured. It implies that the implementation details of one module should not be
visible to other modules of the program. The concept of information hiding helps in reducing the cost of
subsequent design changes.

Modularity has become an accepted approach in every engineering discipline. With the introduction of
modular design, complexity of software design has considerably reduced; change in the program is
facilitated that has encouraged parallel development of systems. To achieve effective modularity, design
concepts like functional independence are considered to be very important.
Functional Independence

Functional independence is the refined form of the design concepts of modularity, abstraction, and
information hiding. Functional independence is achieved by developing a module in such a way that it
uniquely performs given sets of function without interacting with other parts of the system. The software
that uses the property of functional independence is easier to develop because its functions can be
categorized in a systematic manner. Moreover, independent modules require less maintenance and testing
activity, as secondary effects caused by design modification are limited with less propagation of errors. In
short, it can be said that functional independence is the key to a good software design and a good design
results in high-quality software. There exist two qualitative criteria for measuring functional
independence, namely, coupling and cohesion.

Coupling and Cohesion

Coupling

Coupling measures the degree of interdependence among the modules. Several factors like interface
complexity, type of data that pass across the interface, type of communication, number of interfaces per
module, etc. influence the strength of coupling between two modules. For better interface and well-
structured system, the modules should be loosely coupled in order to minimize the 'ripple effect' in which
modifications in one module results in errors in other modules. Module coupling is categorized into the
following types.

No direct coupling: Two modules are said to be 'no direct coupled' if they are independent of each other.

No Direct, Data, and Stamp Coupling

Data coupling: Two modules are said to be 'data coupled' if they use parameter list to pass data items for
communication.

Stamp coupling: Two modules are said to be 'stamp coupled' if they communicate by passing a data
structure that stores additional information than what is required to perform their functions.

Control coupling: Two modules are said to be 'control coupled' if they communicate (pass a piece of
information intended to control the internal logic) using at least one 'control flag'. The control flag is a
variable whose value is used by the dependent modules to make decisions.
Control Coupling

Content coupling: Two modules are said to be 'content coupled' if one module modifies data of some
other module or one module is under the control of another module or one module branches into the
middle of another module.

Content and Common Coupling

Common coupling: Two modules are said to be 'common coupled' if they both reference a common data
block.

Cohesion

Cohesion measures the relative functional strength of a module. It represents the strength of bond between
the internal elements of the modules. The tighter the elements are bound to each other, the higher will be
the cohesion of a module. In practice, designers should avoid a low level of cohesion when designing a
module. Generally, low coupling results in high cohesion and vice versa.

Various types of cohesion are listed below.

Functional cohesion: In this, the elements within the modules are concerned with the execution of a single
function.

Sequential cohesion: In this, the elements within the modules are involved in activities in such a way that
the output from one activity becomes the input for the next activity.

Communicational cohesion: In this, the elements within the modules perform different functions, yet each
function references the same input or output information.

Procedural cohesion: In this, the elements within the modules are involved in different and possibly
unrelated activities.

Temporal cohesion: In this, the elements within the modules contain unrelated activities that can be
carried out at the same time.

Logical cohesion: In this, the elements within the modules perform similar activities, which are executed
from outside the module.

Coincidental cohesion: In this, the elements within the modules perform activities with no meaningful
relationship to one another.

Types of Cohesion

After having discussed various types of cohesions, the procedure which can be used in determining the
types of module cohesion for software design.
Designing Class based components, traditional Components

An individual software component is a software package, a web service, a web resource, or a module that
encapsulates a set of related functions (or data).

All system processes are placed into separate components so that all of the data and functions inside each
component are semantically related (just as with the contents of classes). Because of this principle, it is
often said that components are modular and cohesive.

With regard to system-wide co-ordination, components communicate with each other via interfaces.
When a component offers services to the rest of the system, it adopts a provided interface that specifies
the services that other components can utilize, and how they can do so. This interface can be seen as a
signature of the component - the client does not need to know about the inner workings of the component
(implementation) in order to make use of it. This principle results in components referred to as
encapsulated. The UML illustrations within this article represent provided interfaces by a lollipop-symbol
attached to the outer edge of the component.

However, when a component needs to use another component in order to function, it adopts a used
interface that specifies the services that it needs. In the UML illustrations in this article, used interfaces
are represented by an open socket symbol attached to the outer edge of the component.

A simple example of several software components - pictured within a hypothetical holiday-reservation

system represented in UML 2.0.

Another important attribute of components is that they are substitutable, so that a component can replace
another (at design time or run-time), if the successor component meets the requirements of the initial
component (expressed via the interfaces). Consequently, components can be replaced with either an
updated version or an alternative without breaking the system in which the component operates.

As a general rule of thumb for engineers substituting components, component B can immediately replace
component A, if component B provides at least what component A provided and uses no more than what
component A used.

Software components often take the form of objects (not classes) or collections of objects (from object-
oriented programming), in some binary or textual form, adhering to some interface description language
(IDL) so that the component may exist autonomously from other components in a computer.

When a component is to be accessed or shared across execution contexts or network links, techniques
such as serialization or marshalling are often employed to deliver the component to its destination.
By, Sajil
COMPONENT BASED DEVELOPMENT
Definition -

Component-based development (CBD) is a procedure that accentuates the design and development of
computer-based systems with the help of reusable software components. With CBD, the focus shifts
from software programming to software system composing.

Component-based development is also known as component-based software engineering (CBSE).

Component-based development techniques consist of non-conventional development routines,

including component evaluation, component retrieval, etc. It is important that the CBD is carried out
within a middleware infrastructure that supports the process, for example, Enterprise Java Beans.

The key goals of CBD are as follows:

Save time and money when building large and complex systems: Developing complex software systems
with the help of off-the-shelf components helps reduce software development time substantially.
Function points or similar techniques can be used to verify the affordability of the existing method.

Enhance the software quality: The component quality is the key factor behind the enhancement of
software quality.

Detect defects within the systems: The CBD strategy supports fault detection by testing the components;
however, finding the source of defects is challenging in CBD.

Some advantages of CBD include:

Minimized delivery:

- Search in component catalogs

- Recycling of pre-fabricated components

Improved efficiency:

- Developers concentrate on application development

Improved quality:

- Component developers can permit additional time to ensure quality

- Minimized expenditures

The specific routines of CBD are:

1
 Component development

Component publishing

Component lookup as well as retrieval

Component analysis

Component assembly

User Interface Design

The visual part of a computer application or operating system through which a client interacts with a
computer or software. It determines how commands are given to the computer or the program and how
data is displayed on the screen.

Types of User Interface

There are two main types of User Interface:

- Text-Based User Interface or Command Line Interface

- Graphical User Interface (GUI)

Text-Based User Interface : This method relies primarily on the keyboard. A typical example of this is
UNIX.

Advantages

Many and easier to customizations options.

Typically capable of more important tasks.

Disadvantages

Relies heavily on recall rather than recognition.

Navigation is often more difficult.

Graphical User Interface (GUI) : GUI relies much more heavily on the mouse. A typical example of this
type of interface is any versions of the Windows operating systems.

GUI Characteristics

2
 Characteristics Descriptions

Windows Multiple windows allow different information to

be displayed simultaneously on the user's screen.

Icons Icons different types of information. On some

systems, icons represent files. On other icons
describes processes.

Menus Commands are selected from a menu rather than

typed in a command language.

Pointing A pointing device such as a mouse is used for

selecting choices from a menu or indicating items
of interests in a window

Graphics Graphics elements can be mixed with text or the

same display.

Advantages

Less expert knowledge is required to use it.

Easier to Navigate and can look through folders quickly in a guess and check manner.

The user may switch quickly from one task to another and can interact with several different
applications.

Disadvantages

Typically decreased options.

Usually less customizable. Not easy to use one button for tons of different variations.

3
UI Design Principles

Structure: Design should organize the user interface purposefully, in the meaningful and usual based on
precise, consistent models that are apparent and recognizable to users, putting related things together
and separating unrelated things, differentiating dissimilar things and making similar things resemble one
another. The structure principle is concerned with overall user interface architecture.

Simplicity: The design should make the simple, common task easy, communicating clearly and directly in
the user's language, and providing good shortcuts that are meaningfully related to longer procedures.

Visibility: The design should make all required options and materials for a given function visible without
distracting the user with extraneous or redundant data.

Feedback: The design should keep users informed of actions or interpretation, changes of state or
condition, and bugs or exceptions that are relevant and of interest to the user through clear, concise,
and unambiguous language familiar to users.

Tolerance: The design should be flexible and tolerant, decreasing the cost of errors and misuse by
allowing undoing and redoing while also preventing bugs wherever possible by tolerating varied inputs
and sequences and by interpreting all reasonable actions.

Commercial off-the-shelf(COTS)
Short for commercial off-the-shelf, an adjective that describes software or hardware products that are
ready-made and available for sale to the general public. For example, Microsoft Office is a COTS product
that is a packaged software solution for businesses. COTS products are designed to be implemented
easily into existing systems without the need for customization.

4
COTS software is usually less expensive than custom created software. This is because many such
packages are designed to be used by millions of users worldwide. Since a lot of time and effort has been
put into creating such software.

Another point is COTS software is usually very reliable. Developers of COTS components conduct
research into the most common types of business processes or problems solving techniques and
compress them into software packages that can be used across the board.

It is important to note that any software product that is bought as an “out of the box” product is COTS.
Inexpensive examples, like word processing or tax return software are easy to find and purchase from
retail stores.

COTS applications are easy to install, with instructions contained in the package that encloses the COTS
product. An electronic copy of the instructions is also usually included on the disc that contains the
installation files and resources and in several languages to boot.

Even though companies can make do with freeware or open source software, it is often a requirement
on their part to ensure that majority of the applications they rely on are COTS products. This is because,
other than having installation instructions, most of the COTS applications have a customer care section
that aids any organization that has bought their product.

When a problem is discovered with the COTS product, it will be usually taken care of using a patch, or
fix. A patch will cover the reported defect(s) that may make the product vulnerable to hackers or
operate incorrectly. A “fix”, on the other hand, usually addresses a small issue that gets in the way of
normal operation of the product.

When a COTS product is redesigned in any way to meet a specific user’s needs, it is sometimes called a
modified off-the shelf (MOTS) product. Unlike COTS software, MOTS is often accompanied with
modifiable source code that allows the owner, if they have enough knowledge, to change the product to
their choosing.

Usually, if a strictly COTS product is modified from the original version, that act “voids” any warranty
from the developing organization and so maintenance is left to the user. Any patches or fixes that may
not work are no longer the developer organization’s problems.