software engineering

 Chapter 4

Requirement Modeling

Introduction

Requirement modeling in software engineering is

essentially the planning stage of a software application or

system. The requirements can be obvious or hidden, known

or unknown, expected or unexpected from the client’s point of

view.

Requirement modeling uses a combination of text and

diagrammatic forms to depict requirements in a way that is

relatively easy to understand, and more important,

straightforward to review for correctness, completeness,

and consistency.

Requirements modeling comprises several stages, or

‘patterns’ like scenario-based modeling, data modeling,

flow-oriented modeling, class-based modeling and

behavioral modeling. Each of these stages/patterns

examines the same problem from a different perspective.

Requirement models (also called analysis

models) represent customer requirements by

depicting the software in three different domains

like the information domain, the functional domain,

and the behavioral domain.

Also, as the term ‘modeling’ implies, all of these

stages typically result in producing diagrams that

visually convey the concept they identify. The

most common method for creating these

diagrams are UML (Unified Modeling Language).

UML is a pictorial language used to make software

blueprints. UML can be described as a general

purpose visual modeling language to visualize,

specify, construct, and document software

system.

Views of requirements modeling include two

approaches namely, structured analysis and

object-oriented analysis.

Structured Analysis: Structured analysis approach of

requirement modeling considers data and the

processes that transform the data as separate

entities. Data objects are modeled in a way that

defines their attributes and relationships. Processes

that manipulate data objects are modeled in a

manner that shows how they transform data as data

objects flow through the system.

Object-oriented Analysis: Object-oriented Analysis,

focuses on the definition of classes and the manner

in which they collaborate with one another to effect

customer requirements. UML and the Unified Process

are predominantly object-oriented.

Introduction to UML

UML stands for Unified Modeling Language. UML is a

general-purpose modeling language, which is designed to

provide a standard way to visualize the design of a system.

The UML is a language for Visualizing, Specifying,

Constructing, Documenting the artifacts of a standard

software-intensive system.

Specifying means building models that are precise,

unambiguous, and complete. In particular, the UML

addresses the specification of all important analysis, design

and implementation decisions that must be made in

developing and deploying a software-intensive system.

The UML is not a visual programming language, but its

models can be directly connected to a variety of

programming languages. This means that it is possible to

map from a model in the UML to a programming language

such as java, C++, .NET or to relational table.

Conceptual Model of UML

To understand the conceptual model of UML, first we need

to clarify what is a conceptual model? and why a conceptual

model is required?

A conceptual model can be defined as a model which is

made of concepts and their relationships.

A conceptual model is the first step before drawing a UML

diagram. It helps to understand the entities in the real

world and how they interact with each other.

As UML describes the real-time systems, it is very important

to make a conceptual model and then proceed gradually.

The conceptual model of UML can be mastered by learning

the following three major elements −

UML’s basic building blocks

Rules to connect the building blocks

Common mechanisms of UML

Building Blocks of the UML

The vocabulary of the UML encompasses

three kinds of building blocks:

Things

Relationships

Diagrams

Things are the abstraction that are first class

citizens in a model; relationships tie these

things together; diagrams group interesting

collections of things.

Things in UML

Things are the basic elements in a

object-oriented model.

In UML, there are four kind of things as

follows:-

Structural things

Behavioral things

Grouping things

Annotational things

These things are the basic objects oriented

building blocks of the UML. You have to use

them to write well-formed models.

Structural Things

Structural things represent a conceptual or

physical element. These things are nouns of UML

models.

Structural things are the static parts of model.

Some structural things are listed below :

Class

Interface

Collaboration

Use Case

Active Class

Component

Artifacts

Node

Class : A class is description of a set of object

that shares the same attributes, operation,

relationship and semantics. A class

implements one or more interfaces.

Graphically, a class is represented with

rectangle. The rectangle includes name,

attributes and operations as shown below :

fruit

taste

colour

accept( )

display( )

classname

attributes

operations

Interface : It is a collection of operations that specify

the services of a class or component and is

represented by a circle.

An interface might represent the complete behavior

of a class or component or only a part of that

behavior.

The declaration of an interface looks like a class with

the keyword <<interface>> above the name.

An interface provided by a class to the outside world

is shown as a small circle attached to the class box by

a line.

An interface required by a class from some other

class is shown as a small semicircle attached to the

class box by a line.

Collaboration : Collaboration defines an interaction

between the elements that work together to provide

some cooperative behavior.

Collaboration have both structural as well as

behavioral dimension. A given class or object might

participate in several collaborations.

Use Case : A use case is a description of sequences of

action that a system performs that yield observable

results of value to a particular actor.

A use case is used to structure the behavioral things

in a model. A use case is realized by collaboration.

Graphically, a use case is rendered as an ellipse with

solid lines, usually including only its name.

Active Class : An active class is a class whose objects

own one or more processes or threads and

therefore, can initiate control activity.

An active class is just like class except that its objects

represent elements whose behavior is concurrent

with other elements.

Graphically, it is represented a class with double lines

(dark lines) on the left and right

Component : It is a modular part of a system that

can be replaced with a part of similar logical

behavior. Graphically, a component is represented as

a rectangle with tabs.

Artifacts : The artifacts represents physical things, whereas

the previous things represents conceptual or logical things.

An artifact is a physical and replaceable part of a system

that contains physical information.

In a system, you will encounter different kinds of

deployment artifacts, such as source code files, executable,

scripts etc. an artifacts typically represents the physical

packaging of source or run-time information.

Graphically, an artifact is a rectangle with the keyword

<<artifact>> above the name.

<<artifact>>

Window

dll

Node : a node is a physical element that exists at run

time and represents a computational resource,

generally having at least some memory and often

processing capability.

A set of components may reside on a node and may

also migrate from node to node. Graphically, a node

is shown as a cube, usually including only its