Upload
trinhduong
View
222
Download
1
Embed Size (px)
Citation preview
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
1 Dept: CE FSD ( 3341603) Piyush Bhut
REQUIREMENTS GATHERING AND ANALYSIS
The analyst starts requirement gathering activity by collecting all information that could be useful to
develop system.
In practice it is very difficult to gather all the necessary information from a large number of people and
documents and to form a clear understanding of a problem.
Availability of working model helps in gathering the requirement.
Studying the existing documentation
The analyst usually studies all existing documents regarding the system to be developed before visiting
the customer site.
These documents are about the basic purpose, the stakeholders etc.
Interview
All the different categories of users are interviewed to gather the different functionalities required by
them.
For example, to perform the requirements analysis of library automation software, the analyst might
interview the library members, the librarian, and the accountants.
In this technique, the analyst get the requirements as understood by him and then based on their
feedback, he filter his document. This procedure is repeated till the different users agree on the set of
requirements.
Task analysis
The users usually view software as a black box that provides a set of service is also called a task. For
each identified task, the analyst tries to create the different steps necessary to the service in guidance
with the users.
For example, for the issue book service, the steps may be: authenticate user, check the number of
books issued to the customer and determine if the maximum number of books that this member can
borrow has been reached, check whether the book has been reserved, post the book issue details in
the member’s record, and finally print out a book issue slip that can be presented at the security
counter to take out the book.
Scenario analysis
A task can have many scenarios of operation. The different scenarios of a task can occur when the task
is invoked under different situations.
For different types of scenarios of a task, the behavior of the system can be different.
For example, the different scenarios for the book issue task of a library automation software may be:
Book issue service is satisfactorily performed and the book issue slip is printed.
The book is reserved and cannot be issued to the member.
The maximum number of books that can be issued by the member is exceeded, and the book
cannot be issued to the member.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
2 Dept: CE FSD ( 3341603) Piyush Bhut
REQUIREMENTS ANALYSIS
After requirements gathering is completed the analyst analyzes the gathered requirements to clearly
understand the exact customer requirements and to check out any problems in the gathered
requirements.
The main purpose of the requirement analysis activity is to analyze the collected information to obtain
a clear understanding of the product to be developed, with a view to removing all ambiguities,
incompleteness and inconsistencies.
The following basic questions should be clearly understood by the analyst:
What is the problem?
Why is it important to solve the problem?
What are the possible solutions to the problem?
What exactly are the data input to the system and what exactly are the data output by the system?
What are the complexities that might arise while solving the problem?
If there are external software or hardware with which the developed software has to interface,
then what exactly would the data interchange formats with the external system be?
When the analyst detects any inconsistencies, anomalies or incompleteness in the gathered
requirements, he resolves them by carrying out further discussions with the end users and the
customers.
SOFTWARE REQUIREMENTS SPECIFICATION
After the analyst has gathered all the required information regarding the software to be developed and
has remove all incompleteness, inconsistencies, and anomalies from the specification he starts to
systematically organize the requirements in the form of an SRS document.
SRS document contains all the user requirements.
CHARACTERISTICS OF A GOOD SRS DOCUMENT
The important properties of a good SRS document are the following:
Correct
An SRS is correct if every requirement included in the SRS, required in the final system. Correctness
ensures that what is specified is done correctly.
Unambiguous
An SRS is unambiguous if and only if every requirement stated has one and only one interpretation.
Requirements are often written in natural language.
The SRS should be unambiguous both to those who create it and to those who use it.
Complete
The SRS is complete if, and only if, it includes the following elements:
All requirements, whether relating to functionality, performance, design constraints, attributes, or
external interfaces.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
3 Dept: CE FSD ( 3341603) Piyush Bhut
Definition of the response of the software in all situations. Note that it is important to specify the
response to both valid and invalid input values.
Consistent
A consistent requirement does not conflict with other requirements in the requirement specification.
It uses the same terminology throughout the requirement specification, and does not duplicate.
Ranked for importance
The SRS is ranked for importance if, and only if, has an identifier to indicate the importance of the
particular requirement. Typically, all of the requirements that relate to a software product are not
equally important. Some requirements may be essential, especially, while others may be desirable.
Each requirement in the SRS should be identified to make these differences clear and explicit.
Verifiable
A requirement is verifiable if, and only if, there exists some process with which a person or machine
can check that the software product meets the requirement.
Verifiable means that it can be tested by inspection or analysis.
Modifiable
The SRS is modifiable if, and only if, its structure and style are such that any changes to the
requirement can be made easily, completely, and consistently while retaining the structure and style.
Modifiability generally requires an SRS to
Have easy-to-use organization with a table of contents, and an index
Not be redundant (i.e., the same requirement should not appear in more than one place in the SRS)
Express each requirement separately, rather than intermixed with other requirements.
Structured
The SRS is structured if, and only if, it is moduled, and easy to understand and modify. Over the time
customer requirements changes, requirement specification also changes. In order to make
modification to SRS it is necessary that SRS should be well structured.
Traceable
A traceable requirement has a unique identity or number.
It cannot be separated or broken into smaller requirements.
It can easily be traced through to specification, design, and testing.
REQUIREMENTS SPECIFICATION TYPES
Requirement specification activity is translating the gathered information during the analysis phase
into a document that defines a set of requirements. Two types of requirements may be included in this
document:
1. Customer Requirement
2. System Requirement
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
4 Dept: CE FSD ( 3341603) Piyush Bhut
System Requirements are further classified into more two types.
i. Functional requirements
ii. Nonfunctional requirements
CUSTOMER (USER) REQUIREMENT
Customer requirements are high level abstract statements of the system requirement for the customer
and end user of the system.
These statements are in a natural language. It describes what services the system is expected to
provide to customer and the situation under which it must operate.
The customer requirement is quite general and simple.
SYSTEM REQUIREMENT
System requirements are a more detailed description of the functionality to be provided. It describes
what the system should do. The system requirements document should define exactly what is to be
implemented. The system requirements provide more specific information about the services and
function of the system.
Functional Requirements
The functional requirements discuss the functionalities expected from the system. These are
statements of services that provide how the system should react to particular inputs and how the
system should behave in particular situation. It describes the relationship between input and output. It
also state what the system should do if any situation occurs.
The system is considered to perform a set of high level functions. Each function of the system can be
considered as a transformation of set of input data to the corresponding set of output data. The user
can get some meaningful pieces of work done using a high level function.
Document the functional requirements of a system it is necessary to first learn to identify the high level
function of the system.
The high level function would be split into smaller sub requirement.
A high level function is one using which the user can get some useful piece of work done.
For example, the receipt printing work during withdrawal of money from an ATM is called a useful
piece of work? Receipt printing should not be considered a high-level requirement, because the user
does not specifically request for this activity. The receipt gets printed automatically as part of the
withdraw money function.
In a library automation software a high level functional requirement might be search-book. This
function involves accepting a book name or a set of keywords from the user running a matching
algorithm on the book list and finally outputting the matched books. The generated system response
can be in several form e.g. display on the terminal, a print out or transferred to the other system.
High level function usually involves a series of interactions between the system and one or more users.
For example as shown in figure user inputs have been represented by rectangles and the response
produced by the system by circles.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
5 Dept: CE FSD ( 3341603) Piyush Bhut
In figure the different scenarios occur depending on the amount entered for withdrawal. Different
behavior for different scenarios of the system for the same high level functions.
Nonfunctional requirements
Nonfunctional requirements deal with the characteristics of the system which cannot be expressed as
functions - such as the maintainability of the system, portability of the system, usability of the system,
maximum number of current users etc.
Nonfunctional requirements may include:
reliability issues
accuracy of results
human - computer interface issues
Constraints on the system implementation, etc.
Example of a non functional requirement can be that the user interface of software should be usable
by factory shop floor worker who may not even have a high school degree.
Select withdraw cash
Enter option
Enter amount
Display ac- count type
options
Prompt for amount to
be withdrawn
Insufficie-
nt balance
in account
receipt
Enter amount in multiple of 100
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
6 Dept: CE FSD ( 3341603) Piyush Bhut
Organization of the SRS Document
Organization of the SRS document depends on the system analyst, he is guided by the polices and
standard followed by the company.
It also depends on type of the product developed.
Three basic points that any SRS document should discuss are: functional requirement, non- functional
requirement and guidelines for system implementation.
Depending on the specific problem being specified some section can be omitted, introduce or
interchange as may be considered by the analyst.
The SRS document should be organized into the indicated sections and each of the section should
discuss the items mentioned under the respective section heading.
For example sample organization of an SRS document which can be used as a guideline to organize an
SRS document.
1. Introduction
a) Purpose
b) Overview
c) Environmental Characteristics
I. Hardware
II. People
2. Goals of Implementation
3. Functional requirement
a) User class 1
I. Functional requirement 1.1
II. Functional requirement 1.1
b) User class 2
I. Functional requirement 1.1
II. Functional requirement 1.1
4. Non-Functional requirement
a) External interface
b) User interface
c) Software interface
d) Communication interface
5. Behavioral description
a) System states
b) Events and actions
The introduction section describes the context in which the system is being developed, an overall
description of the system and the environmental characteristics.
The environmental characteristics subsection describes the properties of the environment with which
the system will interact. For example this may include the hardware that the system will run on, the
device that the system will interact.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
7 Dept: CE FSD ( 3341603) Piyush Bhut
Specification of the behavioral may not be necessary for all system. It is usually necessary for those
system in which the system behavior depends on the state in which the system is, and the system
transits among a set of states depending on some prespecified conditions and events.
DESIGN PROCESS
The design process is a sequence of steps that enable the designer to describe all aspects of the
software to be built. It describes how the system will be implemented and how it will work.
Software design deals with transforming the customer requirements, as described in the SRS
document, into appropriate form that is suitable for implementation in a programming language.
CLASSIFICATION OF DESIGN ACTIVITIES
The activities in the design process vary depending on the type of system being developed. The below
figure suggest that the stage of the design process are sequential.
Design Model Diagram
Database Design Data Dictionary, ER Diagram
Architectural Design
Data Flow Diagram
Interface Design Data Flow Diagram, State Transition Diagram
Component Design
State Transition Diagram
Architectural design, where you identify the overall structure of the system, the principal components
(sometimes called sub-systems or modules), and their relationships and how they are distributed.
Interface design, where you define the interfaces between system components. An interface involves a
flow of information (e.g. data and control) and a specific type of behaviour.
Component design, where you take each system component and design how it will operate. This is
defined the expected functionality to be implemented.
Database design, where you design the system data structures and how these are to be represented in
a database. The data objects and relationships defined in the ER diagram and the detailed data content
illustrated in the data dictionary.
CLASSIFICATION OF DESIGN METHODOLOGIES
A design methodology can be simply defined as a set of design procedure that one follows from the
beginning to the completion of the software development process.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
8 Dept: CE FSD ( 3341603) Piyush Bhut
The nature of the methodology is dependent on a number of factors including type of the software
being developed, requirements of the users, qualification and training of software development team,
available hardware and software resources.
There are fundamentally two different approaches:
1. Function oriented design: it can be further divided in two category
I. Structured Analysis
II. Structured Design
2. Object oriented design
Function oriented design (Top-Down approach) A function oriented design is viewed as something that performs a set of functions. Starting at this
high-level view of the system, each function is successively refined into more detailed functions. Each
of these sub-functions may be split into more detailed sub-functions and so on.
The term top-down decomposition is also used for function oriented design. This top-down design
directs designer to start with a top-level description of a system and then treat this view step by step.
With each improvement, the system is decomposed into lower-level and smaller modules.
Top-down decomposition requires identifying the major higher level system requirements and
functions and the breaking them down in sub modules. Thus this design approach reduces the size of
each module.
Some well established function oriented approaches are Jackson’s Structure Design and DFD.
Structured Analysis
It is used to transform a textual problem description into graphical form. It carry out functional
decomposition, each function that the system performs is analyzed and hierarchically decomposed into
more detailed function.
Structured analysis is based on the following philosophy: i) top-down decomposition, ii) decompose
each function individually, and iii) analyze result using graphical representation.
Graphical representations used for functional decomposition are DFD and ER Diagram.
Structured Design
During Structured design all functions identified during analysis mapped to module structure.
Structured design defines a structure of solution that is suitable to implement to programming
language.
The aim of structured design is to transform the results of the structured analysis (i.e. DFD) into a
structure chart. The structure chart is tree like diagram a popular way to represent the control
hierarchy in a high level design.
Object oriented design
In the Object oriented design approach the system is viewed as collection of objects (i.e. entities).
Object Oriented Design supports following object oriented concepts such as Abstraction, Information
Hiding, Functional Independence, and Modularity.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
9 Dept: CE FSD ( 3341603) Piyush Bhut
Design is the initial step in moving towards from the problem domain to the solution domain. A
detailed design includes specification of all the classes with its attributes, detailed interface. The
purpose of design is to specify a working solution that can be easily translated into a programming
language code.
UML modeling and Use Case are used in object oriented designing.
COHESION
Cohesion means the measure of the strength of function relatedness of elements within a module.
Elements include instructions, groups of instructions, data definition, and call of another module.
Cohesion means how closely the elements of a module are related to each other.
It represents how tightly bound the internal elements of the module are to one another.
The classification of cohesion are given beloved:
Coincidental cohesion
A module is said to have coincidental cohesion, if it performs a set of tasks that relate to each other
very loosely. In this case, the module contains a random collection of functions. It is likely that the
functions have been put in the module out of pure coincidence without any thought or design.
For example, in a transaction processing system (TPS), the get-input, print-error, and summarize-
members functions are grouped into one module. The grouping does not have any relevance to the
structure of the problem.
Logical cohesion
A module is said to be logically cohesive, if all elements of the module perform similar operations, e.g.
error handling, data input, data output, etc.
An example of logical cohesion is the case where a set of print functions generating different output
reports are arranged into a single module.
Temporal cohesion
When a module contains functions that are related by the fact that all the functions must be executed
in the same time span, the module is said to exhibit temporal cohesion. The set of functions
responsible for start-up, shutdown of some process, etc. exhibit temporal cohesion.
Procedural cohesion
A module is said to possess procedural cohesion, if the set of functions of the module are all part of a
procedure (algorithm) in which certain sequence of steps have to be carried out for achieving an
objective, e.g. the algorithm for decoding a message.
Communicational cohesion
A module is said to have communicational cohesion, if all functions of the module refer to or update
the same data structure, e.g. the set of functions defined on an array or a stack.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
10 Dept: CE FSD ( 3341603) Piyush Bhut
Sequential cohesion
A module is said to possess sequential cohesion, if the elements of a module form the parts of
sequence, where the output from one element of the sequence is input to the next.
For example, in a TPS, the get-input, validate-input, sort-input functions are grouped into one module.
Functional cohesion
Functional cohesion is said to exist, if different elements of a module cooperate to achieve a single
function.
In a functionally bound module, all the elements of the module are related to performing a single
function.
For example, a module containing all the functions required to manage employees’ pay-roll exhibits
functional cohesion.
COUPLING
Coupling between two modules is a measure of the degree of interdependence or interaction between
the two modules.
A module having high cohesion and low coupling is said to be functionally independent of other
modules. If two modules interchange large amounts of data, then they are highly interdependent. The
degree of coupling between two modules depends on their interface complexity.
The interface complexity is basically determined by the number of types of parameters that are
interchanged while invoking the functions of the module.
The classification of cohesion are given beloved:
Data coupling
Two modules are data coupled, if they communicate through a parameter. An example is an
elementary data item passed as a parameter between two modules, e.g. an integer, a float, a
character, etc.
This data item should be problem related and not used for the control purpose.
Stamp coupling
Two modules are stamp coupled, if they communicate using a composite data item such as a record in
PASCAL or a structure in C.
Control coupling
Control coupling exists between two modules, if data from one module is used to direct the order of
instructions execution in another.
An example of control coupling is a flag set in one module and tested in another module.
Common coupling
Two modules are common coupled, if they share data through some global data items.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
11 Dept: CE FSD ( 3341603) Piyush Bhut
Content coupling
Content coupling exists between two modules, if they share code. That is a jump from one module into
the code of another module can occur. e.g. a branch from one module into another module.
DATA MODELING CONCEPTS
ER diagram represent a set of real-world entities and the logical relationships among them. This
diagram depicts entities, the relationships between them, and the attributes pictorially in order to
provide a high-level description of conceptual data models.
Once an ER diagram is created, the information represented by it is stored in the database. Note that
the information depicted in an ER diagram is independent of the type of database and can later be
used to create database of any kind such as relational database, network database, or hierarchical
database.
An ER diagram comprises data objects and entities, data attributes, relationships, and cardinality and
modality.
Data object
Data object is a representation of composite information used by software. Composite information
refers to different features or attributes of a data object and this object can be in any of the following
forms.
External entity: Describes the data that produces or accepts information. For example, a report.
Occurrence: Describes an action of a process. For example, a telephone calls.
Event: Describes a happening that occurs at a specific place or time. For example, an alarm.
Role: Describes the activities assigned to an individual or object. For example, a systems analyst.
Place: Describes the location of objects or storage area. For example, CE Department.
Structure: Describes the arrangement and composition of objects. For example, a file.
An entity is the data that stores information about the system in a database. Examples of an entity
include real world objects, transactions, and persons.
Data attributes
Data attributes describe the properties of a data object. Attributes that identify entities are known
as key attributes. On the other hand, attributes that describe an entity are known as non-key
attributes. Generally, a data attribute is used to perform the following functions.
Naming an instance (occurrence) of data object
Description of the instance
Making reference to another instance in another table.
Data attributes help to identify and classify an occurrence of entity or a relationship. These attributes
represent the information required to develop software and there can be several attributes for a single
entity. For example, attributes of 'account' entity are 'number', 'balance', and so on.
Similarly, attributes of 'user' entity are 'name', 'address', and 'age'. However, it is important to consider
the maximum attributes during requirements gathering because with more attributes, it is easier for
the software development team to develop the software.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
12 Dept: CE FSD ( 3341603) Piyush Bhut
Relationships
Entities are linked to each other in different ways. This link or connection of data objects or entities
with each other is known as relationship. Note that there should be at least two entities to establish a
relationship between them.
Once the entities are identified, the software development team checks whether a relationship exists
between them.
Relationship is represented using diamond shape symbol with joined relationship name.
To understand entities, data attributes, and relationship, let us consider an example. Suppose in a
computerized banking system, one of the processes is to use a saving account,' which includes two
entities, namely, 'user' and 'account'. Each 'user' has a unique 'account number', which makes it easy
for the bank to refer to a particular registered user.
Depending upon the type and nature of transactions, it can be of various types such as current
account, saving account, or overdraft account. The relationship between the user and the account can
be described as 'user has account in a bank'.
Entities are represented by rectangles, attributes are represented by ellipses, and relationships are
represented by diamond symbols. A key attribute is also depicted by an ellipse but with a line below it.
This line below the text in the ellipse indicates the uniqueness of each entity.
Cardinality
Cardinality specifies the number of occurrences (instances) of one data object or entity that relates to
the number of occurrence of another data object or entity. It also specifies the number of entities that
are included in a relationship.
Different cardinalities are explained below:
One-to-one (1:1): Indicates that one instance of an entity is related only to one instance of another
entity. For example, in a bank, each user is related to only one account number.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
13 Dept: CE FSD ( 3341603) Piyush Bhut
One-to-many (1:M): Indicates that one instance of an entity is related to several instances of
another entity. For example, one user can have many accounts in different banks.
Many-to-many (M: M): Indicates that many instances of entities are related to several instances of
another entity. For example, many users can have their accounts in many banks.
Modality
Modality describes the possibility whether a relationship between two or more entities and data
objects is required. The modality of a relationship is 0 if the relationship is optional. However, the
modality is 1 if an occurrence of the relationship is essential.
To understand the concept of cardinality and modality properly, let us consider an example. User
entity is related to order entity. Here, cardinality for 'user' entity indicates that the user places an order
whereas modality for 'user' entity indicates that it is necessary for a user to place an order.
Cardinality for 'order' indicates that a single user can place many orders whereas modality for 'order'
entity indicates that a user can arrive without any 'order'.
DATA FLOW DIAGRAM (DFD)
The DFD (also known as a bubble chart) is a hierarchical graphical model of a system that shows the
different processing activities or functions that the system performs and the data interchange among
these functions.
Each function is considered as a processing station (or process) that consumes some input data and
produces some output data. The system is represented in terms of the input data to the system,
various processing carried out on these data, and the output data generated by the system.
PRIMITIVE SYMBOLS OF DFD
A DFD model uses a very limited number of primitive symbols as shown in figure to represent the
functions performed by a system and the data flow among these functions.
External entity: The external entities are those physical entities external to the software system which
interact with the system by inputting data to the system or by consuming the data produce by the
system. External entity is represented by a rectangle. For example librarian, library member.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
14 Dept: CE FSD ( 3341603) Piyush Bhut
Function: A function is represented using a circle. This symbol is called a process or a bubble.
Data flow: A directed arc or an arrow is used as a data flow symbol. A data flow represents the data
flow occurring between two processes or between an external entity and a process in the direction of
the data flow arrow.
Data store: A data store is represented using two parallel lines. It represents a logical file. It represents
data structure or a physical file on disk. Each data store is connected to a process. The direction of the
data flow arrows shows whether data is being read from or written into a data store.
Output: The output symbol is as shown in figure. The output symbol is used when a hard copy is
produced.
DEVELOP DFD MODEL OF SYSTEM
A DFD model of a system graphically depicts the transformation of the data input to the system to the
final result through a hierarchy of levels.
The top level DFD is called the level 0 DFD or the context diagram.
A DFD starts with the most abstract definition of the system (lowest level) and at each higher level
DFD, more details are successively introduced.
To develop a higher-level DFD model, processes are decomposed into their sub-processes and the data
flow among these sub-processes is identified.
To develop the data flow model of a system, first the most abstract representation of the problem is to
be worked out. The most abstract representation of the problem is also called the context diagram.
After, developing the context diagram, the higher-level DFDs have to be developed.
Context Diagram (Level 0)
The context diagram is the most abstract data flow representation of a system. It represents the entire
system as a single bubble. This bubble is labeled according to the main function of the system.
The various external entities with which the system interacts and the data flow occurring between the
system and the external entities are also represented. The data input to the system and the data
output from the system are represented as incoming and outgoing arrows. These data flow arrows
should be annotated with the corresponding data names.
The name ‘context diagram’ is well justified because it represents the context in which the system is to
exist, i.e. the external entities who would interact with the system and the specific data items they
would be supplying the system and the data items they would be receiving from the system.
External entity Process Output
Data flow
Data store
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
15 Dept: CE FSD ( 3341603) Piyush Bhut
The context diagram is also called as the level 0 DFD.
To develop the context diagram of the system, it is required to analyze the SRS document to identify
the different types of users who would be using the system and the kinds of data they would be
inputting to the system and the data they would be receiving the system. Here, the term “users of the
system” also includes the external systems which supply data to or receive data from the system.
Construction of the context diagram: Examine the SRS document to determine:
Different high level functions that the system needs to perform
Data input to every high level function
Data output from every high level function
Interactions (data flow) among the identified high level function
Level 1
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
16 Dept: CE FSD ( 3341603) Piyush Bhut
Include all entities and data stores that are directly connected by data flow to the one process you are
breaking down.
Show all other data stores that are shared by the processes in this breakdown.
Decomposition at further level 1 DFD have processes with label 1.0, 2.0, 3.0,… and so on.
Shortcoming (Disadvantage) of DFD Model
DFDs for large system can be become complex, difficult to understand and be time consuming in their
construction.
Data flow can become confusing to programmer if it is not well defined. DFD does not specify exactly in which order processes are executed. There are multiple possible ways
to execute processes. So several alternate presentations can be possible. In DFD which inputs are consumed and which outputs are produced are not specified.
DFD does not provide clear view about decomposition of any process to its sub-process.
SCENARIO BASED MODELING
UNIFIED MODELING LANGUAGE (UML)
UML, as the name implies, is a modeling language.
It provides a set of notations (e.g. rectangles, lines, ellipses, etc.) to create a visual model of the
system.
UML has its own syntax (symbols and sentence formation rules) and semantics (meanings of symbols
and sentences).
UML is not a system design or development methodology, but can be used to document object-
oriented and analysis results obtained using some methodology.
WRITING USE CASES
While developing software, it is essential for the development team to consider user satisfaction as a
top priority to make the software successful. For this, the development team needs to understand how
users will interact with the system.
This information helps the team to carefully characterize each user requirements and then create a
meaningful and relevant analysis model and design model. For this, the software engineer creates
scenarios in the form of use-cases to describe the system from the users' perspective.
In addition, use-cases describe the tasks or series of tasks in which the users will use the software
under a specific set of conditions.
Each use-case provides one or more scenarios in order to understand how a system should interact
with another system to accomplish the required task. Note that use-cases do not provide descriptions
about the implementation of software.
Use-cases are represented with the help of a use-case diagram, which depicts the relationships among
actors and use cases within a system.
A use-case diagram describes what exists outside the system (actors) and what should be performed
by the system (use-cases). The notations used to represent a use-case diagram are listed in Table.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
17 Dept: CE FSD ( 3341603) Piyush Bhut
Name Description
Actor Relates to the roles people play in an organization or a project. Actors are different
kinds of users who use the system in various ways. For example, one actor can be a
library user whereas another user can be part of the library staff.
Use-case Describes a specific instance of a system function.
Communication link Indicates the interaction between the actor and the system. Communication link is the
default line used in a use-case diagram.
Use link Indicates that one of the use-case uses the behavior described by another use-case.
Customer (actor) uses bank ATM to check balances of his/her bank accounts, deposit funds, withdraw
cash and transfer funds (use cases). ATM Technician provides maintenance and repairs. All these use
cases also involve Bank actor whether it is related to customer transactions or to the ATM servicing.
Generalization
Use case generalization can be used when one use case that is similar to another, but does something
slightly differently or something more.
Generalization works the same way with use cases as it does with classes.
The child use case inherits the behavior and meaning of the parent use case.
The notation for generalization is as shown in figure.
It is important to remember that the base and the derived use cases are separate use cases and should
have separate text descriptions.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
18 Dept: CE FSD ( 3341603) Piyush Bhut
Includes
The includes relationship involves one use case including the behavior of another use case in its
sequence of events and actions.
The includes relationship occurs when a part of behavior that is similar across a number of use cases.
The factoring of such behavior will help in not repeating the specification and implementation across
different use cases.
The includes relationship explores the issue of reuse by factoring out the commonality across use
cases.
It decomposes a large and complex use cases into more manageable parts.
As shown in figure, the includes relationship is represented using a predefined stereotype <<include>>.
In the includes relationship, a base use case compulsorily and automatically includes the behavior of
the common use cases.
As shown in example figure, deposit funds and withdraw cash both include customer authentication
use case. The base use case may include several use cases.
ACTIVITY DIAGRAM
An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from
activity to activity. An activity represents an operation on some class in the system that results in a
change in the state of the system.
Typically, activity diagrams are used to model workflow or business processes and internal operation.
Withdraw
cash
Customer
Authentication
Deposit
Funds
<<include>>
<<include>>
Pay membership
fee
Pay through
library pay card
Pay through
credit card
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
19 Dept: CE FSD ( 3341603) Piyush Bhut
Basic Activity Diagram Symbols and Notations
Action states
Action states represent the actions of objects. You can draw an action state using a rectangle with
rounded corners.
Action Flow
Action flow arrows illustrate the relationships among action states.
Initial State
A filled circle followed by an arrow represents the initial action state.
Final State
An arrow pointing to a filled circle nested inside another circle represents the final action state.
Branching
A diamond represents a decision with alternate paths. The outgoing alternates should be labeled with
a condition or guard expression. You can also label one of the paths "else."
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
20 Dept: CE FSD ( 3341603) Piyush Bhut
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
21 Dept: CE FSD ( 3341603) Piyush Bhut
Synchronization
A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking and
joining.
Swimlanes
Swimlanes group related activities into one column
.
For example, activity diagram of ATM machine
ARCHITECTURAL DESIGN DECISIONS
Design and implementation
Software design and implementation is the stage in the software engineering process at which an
executable software system is developed.
Software design is a creative activity in which you identify software components and their
relationships, based on a customer’s requirements.
Implementation is the process of realizing the design as a program.
Software Architecture
The design process for identifying the sub-systems making up a system and the framework for sub-
system control and communication is architectural design.
The output of this design process is a description of the software architecture.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
22 Dept: CE FSD ( 3341603) Piyush Bhut
Architectural design decisions
Architectural design is a creative process so the process differs depending on the type of system being
developed.
However, a number of common decisions span all design processes and these decisions affect the non-
functional characteristics of the system.
Is there a generic application architecture that can be used?
How will the system be distributed?
What architectural styles are appropriate?
What approach will be used to structure the system?
How will the system be decomposed into modules?
How should the architecture be documented?
ARCHITECTURAL VIEWS
What views or look are useful when designing and documenting a system’s architecture?
What notations should be used for describing architectural models?
Each architectural model only shows one view or look of the system.
It might show how a system is decomposed into modules, how the run-time processes interact or the
different ways in which system components are distributed across a network.
For both design and documentation, you usually need to present multiple views of the software
architecture.
4 + 1 view model of software architecture
1. A logical view, which shows the key abstractions in the system as objects or object classes.
2. A process view, which shows how, at run-time, the system, is composed of interacting processes.
3. A development view, which shows how the software is decomposed for development. Means it shows
the breakdown of software into modules.
4. A physical view, which shows the system hardware and how software components are distributed
across the processors in the system.
ARCHITECTURAL PATTERNS
Patterns are a means of representing, sharing and reusing knowledge.
An architectural pattern is a stylized description of good design practice, which has been tried and
tested in different environments.
Patterns should include information about when they are and when they are not useful.
MVC (Model-View-Controller) Pattern
Separates presentation and interaction from the system data. The system is structured into three
logical components that interact with each other. The Model component manages the system data and
associated operations on that data. The View component defines and manages how the data is
presented to the user. The Controller component manages user interaction (e.g., key presses, mouse
clicks, etc.) and passes these interactions to the View and the Model.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
23 Dept: CE FSD ( 3341603) Piyush Bhut
Used when there are multiple ways to view and interact with data. Also used when the future
requirements for interaction and presentation of data are unknown.
Allows the data to change independently of its representation and vice versa. Supports presentation of
the same data in different ways with changes made in one representation shown in all of them.
Can involve additional code and code complexity when the data model and interactions are simple.
Layered architecture Pattern
Organizes the system into layers with related functionality associated with each layer. A layer provides services to the layer above it so the lowest-level layers represent core services that are likely to be used throughout the system.
Darshan Institute of Engineering & Technology for Diploma Studies Unit-2
24 Dept: CE FSD ( 3341603) Piyush Bhut
Client-server
In client–server architecture, the functionality of the system is organized into services, with each
service delivered from a separate server. Clients are users of these services and access servers to make
use of them.
Used when data in a shared database has to be accessed from a range of locations. Because servers
can be replicated, may also be used when the load on a system is variable.
The principal advantage of this model is that servers can be distributed across a network. General
functionality (e.g., a printing service) can be available to all clients and does not need to be
implemented by all services.
APPLICATION ARCHITECTURES
Software application architecture is the process of defining a structured solution that meets all the
technical and operational requirements.
Application architecture is the organizational design of an entire software application including all sub
component and external applications.
Application architecture helps us to understand the operations of the system.
It describes the layout of application’s deployment.
Use of application architectures
As a starting point for architectural design.
As a way of organizing the work of the development team.
As a means of assessing components for reuse.
As a vocabulary for talking about application types.