SOFTWARE ENGINEERING

•MODULE 2

Dept. Of CSE, SVIT 1

 CHAPTER 1 – UNDERSTANDING REQUIREMENTS

 REQUIREMENTS ENGINEERING
 ESTABLISHING THE GROUND WORK
 ELICITING REQUIREMENTS
 DEVELOPING USE CASES
BUILDING THE REQUIREMENT MODEL
 NEGOTIATING REQUIREMENTS
 VALIDATING REQUIREMENTS

Dept. Of CSE, SVIT 2

Sowmya h n, ASSISTANT PROFESSOR
 TEXT BOOK REFERRED
• Roger S. Pressman: Software Engineering-A Practitioners approach, 7th
Edition, Tata McGraw Hill.
Chapter 5: 5.1 to 5.7
•
Chapter 6: 6.1 to 6.5

Dept. Of CSE, SVIT 3

Sowmya h n , ASSISTANT PROFESSOR
STAGES OF SDLC
It is a step by procedure to start a new project or to develop a new software.

• Requirement collection: business analyst/product analyst

• Feasibility study: project manager/ BA/ Finance team/ HR team
• Design: Architect
• Coding: developers
• Testing: Test engineers
• Installation: IT engineers/Installation engineers
• Maintenance: developer and tester

Dept. Of CSE, SVIT 4

 REQUIREMENTS ENGINEERING PROCESS
 Requirements engineering, is the process of gather all the software requirements from the
customer, analyze and document them is known as requirement engineering.

 It helps software engineer to better understand the problem.

 It is determining user expectations for a new or modified product.

 People involved in requirement engineering process

Software engineers
Managers
customers
 Understanding requirements( analyzing, feasibility, validating, managing)

5
 REQUIREMENTS ENGINEERING…
 Requirements engineering is a major software engineering action that begins during the
communication activity and continues into the modeling activity.

 Requirements engineering builds a bridge to design and construction.

 The task involved in requirement engineering process

1. Inception
2. Elicitation
3. Elaboration
4. Negotiation
5. Specification
6. Validation
7. Management

Dept. Of CSE, SVIT 6

 REQUIREMENTS ENGINEERING TASK
Requirements Engineering Task:

 Inception: It establishes a basic understanding of the problem, the people who want a solution, the nature of
the solution that is desired, and initiate the communication and collaboration between the other stakeholders
and the software team.

 Elicitation: In this stage, proper information is extracted to prepare and document the requirements. The
requirements are difficult because the following problems occur in elicitation.

 Problem of scope: The customer give the unnecessary technical detail rather than clarity of the overall
system objective.

 Problem of understanding: Poor understanding between the customer and the developer regarding
various aspect of the project like capability, limitation of the computing environment.

 Problem of volatility: In this problem, the requirements change from time to time and it is difficult
while developing the project.
7
Sowmya H N , ASSISTANT PROFESSOR DEPT. OF CSE, SVIT
 REQUIREMENTS ENGINEERING TASK
Requirements Engineering Task:

 Elaboration :In this task, the information taken from user during inception and elicitation are expanded and
refined in elaboration. Analyzing phase. Its main task is developing pure model of software using functions,
feature and constraints of a software.

 Negotiation: In negotiation task, Conflicts are identified and resolved. Customers, users, and other stakeholders
are asked to rank requirements and then discuss conflicts in priority. Using an iterative approach that
prioritizes requirements, assesses their cost and risk, and addresses internal conflicts, requirements are
eliminated, combined, and/or modified so that each party achieves some measure of satisfaction.

8
Sowmya H N, ASSISTANT PROFESSOR DEPT. OF CSE, SVIT
 REQUIREMENTS ENGINEERING TASK

• Specification: In this task, the requirement engineer constructs a final work product. The work
product is in the form of software requirement specification.
Requirements received from the clients are written in natural language.
After collecting, system analyst to document the requirement in technical language.
SRS include dataflow diagram, data dictionary, entity relationship diagram.
SRS defines
 How the intended software will interact with hardware.
 External interface/ GUI
 Response time of system
 Maintainability, portability
 Security, quality, limitations
Dept. Of CSE, SVIT 9
 REQUIREMENTS ENGINEERING TASK
 Validation :The work product is built as an output of the requirement engineering and that is accessed for the
quality through a validation step. The formal technical reviews from the software engineer, customer and
other stakeholders helps for the primary requirements validation mechanism.

 After SRS developed, the requirements discussed in this documents are validated or tested.
 Requirement validation done through reviews taken by customers.
 Requirements can be check against the following conditions
 If they can practically implement or possible to implement.
 If they are correct and as per the functionality and specially of software.
 If there are any ambiguities.
 if they can describe each and every requirements properly.
 Any changing or additional requirements

Dept. Of CSE, SVIT 10

Sowmya H N,, ASSISTANT PROFESSOR
 REQUIREMENTS ENGINEERING TASK
• Requirement management: It is a set of activities that help the project team to identify, control
and track the requirements and changes can be made to the requirements at anytime of the
ongoing project .
• Activities involved in requirement management
• Tracking and controlling changes: Handling changing requirements from the customer.
• Version control: keeping track of different versions of system.
• Communication: if changing requirements has any issues contact with clients within time and
communicate with the customer.
• Monitoring and reporting: monitoring development process and report the status.

Dept. Of CSE, SVIT 11

 ESTABLISHING THE GROUNDWORK
 There could be many issues to start Requirement Engineering Process:

 Customers or end users may be located in a different city/country.

 Customers do not have a clear idea of the requirements.
 Lack of technical knowledge or customers have limited time to interact with requirement engineer.

Hence by following the below steps we can start a requirement engineering process.

1. Identifying Stakeholders
2. Recognizing Multiple View Points
3. Working toward Collaboration

12
 ESTABLISHING THE GROUNDWORK
Identifying Stakeholders
 Stakeholder is the one who directly or indirectly benefits from the system.
 Software Engineers, Internal or external customers, End users, product engineers, marketing people,
support and maintenance engineers.
 Each stakeholders has a different view of the system.
 Stake holders face both different benefits and risks.

Recognizing Multiple View Points

 Software engineers should consider all the viewpoints of stakeholders.
 Every stake holders contribute different types data and different roles in REP
 Requirements explored from different points of views.
 Inconsistent and conflict requiremnets.
 Ex: marketing group- features that will excite the potential.
 Buisness manager –features that are built within budget
 End users- features easy to learn and use

 Decision makers will select consistent set of requirements for the system.
13
 ESTABLISHING THE GROUNDWORK
Working toward Collaboration
Stakeholders collaborate by providing their view of requirements.
To generate a successful or quality product all should work in collaboration.
Requirement engineers identify the areas of commonality and conflict requirement.
Project head and requirement engineer decide which requirements are accepted.

14
 ESTABLISHING THE GROUNDWORK
Asking the First Questions

 The first set of context - free questions focuses on the customer and other stakeholders, the overall project
goals and benefits. –

 Who is behind the request for this work?

 Who will use the solution?
 What will be the economic benefit of a successful solution?
 Is there another source for the solution that you nee?

• These questions help to identify all stakeholders who will have interest in the software to be built.
• In addition, the questions identify the measurable benefit of a successful implementation and possible
alternatives to custom software development.

15
MADHURA N , ASSISTANT PROFESSOR DEPT. OF CSE, SVIT
 ELICITING REQUIREMENTS
 Requirements elicitation is to collect requirements in a proper way by communicating with the
clients, end users, system users who are involved in the software development.
 It combines elements of problem solving, elaboration, negotiation, and specification.
 To encourage collaborative approach to requirements gathering, stakeholders work together to
identify the problems and solutions.

1. Collaborative Requirements Gathering

 Gathering the requirements by conducting the meetings between stakeholders and customer.
 Rules for preparation and participation.
 Agenda : formal and informal views.
 A “facilitator” (can be a customer, a developer) controls the meeting.
 A “definition mechanism” (can be work sheets, flip charts, or wall stickers or an electronic bulletin board, chat
room, or virtual forum) is used.

The main motive is to identify the problem, give the solutions for the elements, negotiate the different approaches
and specify the primary set of solution requirements in an environment which is valuable for achieving the goal.
16
 ELICITING REQUIREMENTS
1. Collaborative requirements gathering ----HOME SAFETY PROJECT

Step 1: Identify Stakeholders

•Clients
•End users- people using this system
•Developers: The team responsible for building the app
•Project manger, requirement engineers, software team.

Step 2: Conduct Initial Meetings

•Organize a kickoff meeting with all stakeholders to introduce the project and its goals.
•Use this meeting to explain the importance of gathering accurate requirements and how it will impact the final
product.
•FEATURES: Control pannel, smoke detector, window and door sensors, motion detectors, an alarm, a display, telephone
number, call.
•List of constraints: the system must recognize when sensors are not working, user friendly, interface directly to standard phone
line, sensor event should be recognized within one second.

17
DEPT. OF CSE, SVIT
 ELICITING REQUIREMENTS
• Step 3: Use Collaborative Techniques
• Develop mini specification about for entries on the list.
• Mini specification of safe home object is control pannel.
• Ex:
 Control pannel is approximately 9X5 inches.
 It
has wireless connectivity to sensors and pc
 User interaction occurs through keyboard

Dept. Of CSE, SVIT 18

 ELICITING REQUIREMENTS
2. Quality Function Deployment (QFD)

 Quality function deployment (QFD) is a quality management technique that translates the needs of
the customer into technical requirements for software.
 The QFD system designs software according to the demands of the customer.
 It concentrate on customer satisfaction

QFD consist of three types of requirement:

 Normal requirements

 The objective and goal are stated for the system through the meetings with the customer.
 For customer satisfaction these requirements should be there.
 Examples of normal requirements might be requested types of graphical displays.

19
 ELICITING REQUIREMENTS
 Expected requirements
 These requirements are implicit to the product or system and may be so fundamental that the customer does
not explicitly state them. Their absence will be a cause for significant dissatisfaction.
 These are the basic requirements that are not clearly told by the customer, but also the customer expects that
requirement.
 Examples of expected requirements are: ease of human/machine interaction, overall operational correctness
and reliability, and ease of software installation.

 Exciting requirements
 These features are beyond the expectation of the customer. Developer embedded some extra features in
software.
 The developer adds some additional features or unexpected features into the software to make the customer
more satisfied.
 For example, the mobile phone with standard features, but the developer adds few additional functionalities
like voice searching, multi-touch screen etc. then the customer is more excited about that feature.
20
 ELICITING REQUIREMENTS Continued..
3. Usage scenarios

 Until the software team does not understand how the features and function are used by the end users it is
difficult to move technical activities.
 To achieve the above problem the software team produces a set of structures that identify the usage for the
software.
 This structure is called 'Use Cases’ provide a description of how the system will be used.

4. Elicitation work product

The work product created as a result of requirement elicitation that is depending on the size of the system or
product to be built.
 The work product consists of a statement of need, feasibility, statement of scope for the system and
stakeholders.
 It also consists of a list of users participate in the requirement elicitation.

Each of these work products is reviewed by all people who have participated in requirements elicitation.

21
MADHURA N , ASSISTANT PROFESSOR DEPT. OF CSE, SVIT
 DEVELOPING USECASES
 A use case tells a story about how an end user interacts with the system under a specific set of situations.
 A Use Case depicts a system from the end users point of view.
 Use cases are defined from actors point of view.
 Actors could be people/ users / devices as they interact with the software.
 The first step in writing a use case is to define the set of “actors” that will be involved in the story.
 Every actor has one or more goals when using the system.
 Once actors have been identified, use cases can be developed.

 Primary actors interact to achieve required system function and derive the intended benefits from the
system. They work directly and frequently with the software.
 Secondary actors support the system so that primary actors can do their work.

22
 DEVELOPING USECASES
Basic bank locker or safe home requirements, it invovles four
actors:

• 1) home owner
• 2) Setup manager
• 3) Sensors (devices attached to the system or react with
software)
• 4)The monitoring and response subsystem. ex:- alarm.
The homeowner actor interacts with the home security
function in a number of different ways using either the
control panel or a PC:

MADHURA N , ASSISTANT PROFESSOR

DEVELOPING USECASES
• Considering the situation in which the homeowner uses the control panel, the basic use case for system
activation follows:
• 1.The homeowner checks the SafeHome control panel to determine if the system is ready for input. If the system
is not ready, a not ready message is displayed on the LCD display.
• 2. The homeowner uses the keypad to key in a four-digit password. The password is compared with the valid
password stored in the system. If the password is incorrect and reset itself for additional input. If the password is
correct, the control panel awaits further action.
• 3. The homeowner select the keys in stay or away to activate the system.
 Stay activates only perimeter(outside) sensors (inside motion detecting sensors are deactivated).
 Away activates all sensors.

• 4. When activation occurs, a red alarm light can be observed by the homeowner. The basic use case presents a
high-level story that describes the interaction between the actor and the system.
DEVELOPING USECASES
• DETAILED Description of Use Case OF ATM MACHINE:
USE CASE ATM MACHINE
Primary actor Customer
Goal in context Perform transaction
Preconditions: Insert card to the machine
Scenario: 1. Withdraw cash
2. Check balance
3. Change pin or set pin
4. Deposit
Exceptions: 1. NETWORK DOWN
2. BANK DATABASE NOT AVAILABLE
 DEVELOPING USECASES
USE CASE ATM machine
Priority: Essential, must be implemented
Frequency of use: Many times per day
Channel to actor ATM machine interface
Secondary actors: Bank employees, Support technician
Channels to secondary 1. Bank employes: cash , recover account.
actors: 2. Technical support:
Open issues: 1. Balance slip is not coming? At least display message on screen or send message to
mobile.
2. Out of cash, message should be displayed.
3. Pin is incorrect it should give atleast 3 chance to enter pin.

26
MADHURA N , ASSISTANT PROFESSOR
NEGOTIATING REQUIREMENTS
 The negotiation is to develop a project plan that meets stakeholder needs while at the same time reflecting the real-
world constraints (e.g., time, people, budget) that have been placed on the software team.
 Discussion between two parties to reach an agreement.

 That is, stakeholders win by getting the system or product that satisfies the majority of their needs and you (as a
member of the software team) win by working to realistic and achievable budgets and deadlines.

 The following activities are defined:

1. Identification of the system or subsystem’s key stakeholders.
2. Determination of the stakeholders’ “win conditions.”
3. Negotiation of the stakeholders’ win conditions to reconcile them into a set of win-win conditions for all
concerned (including the software team).

Dept. Of CSE, SVIT 30

 VALIDATING REQUIREMENTS
Validating requirements in software engineering is crucial to ensure that they are clear, complete, and consistent
before starting development.

 Is each requirement consistent with the overall objectives for the system/product?
 Is the requirement really necessary or does it represent an add-on feature that may not be essential to the objective
of the system?
 Is each requirement bounded and unambiguous?
 Do any requirements conflict with other requirements?
 Is each requirement achievable in the technical environment that will house the system or product?
 Is each requirement testable, once implemented?
 Does the requirements model properly reflect the information, function, and behavior of the system to be built?
 Has the requirements model been “partitioned” in a way that exposes progressively more detailed
information about the system?

These and other questions should be asked and answered to ensure that the requirements model is an accurate
reflection of stakeholder needs and that it provides a solid foundation for design.
Dept. Of CSE, SVIT 31
 CHAPTER 2 –REQUIREMENTS MODELLING SCENARIOS,
INFORMATION AND ANALYSIS CLASSES

 REQUIREMENTS ANALYSIS

 SCENARIO BASED MODELLING

UML MODELS THAT SUPPLIMENTS USE CASE
DATA MODELLING CONCEPTS
CLASS BASED MODELLING

Dept. Of CSE, SVIT 32

MADHURA N , ASSISTANT PROFESSOR
REQUIREMENTS ANALYSIS

 Requirements analysis allows you to elaborate on basic requirements established during the inception,
elicitation, and negotiation tasks that are part of requirements engineering.
 The requirements modeling action results in one or more of the following types of models:

 Scenario-based models of requirements from the point of view of various system “actors”

 Class-oriented models that represent object-oriented classes (attributes and operations) and the manner in which
classes collaborate to achieve system requirements.

 Flow-oriented models that represent the functional elements of the system and how they transform data as it
moves through the system.

 Behavioral models that depict how the software behaves as a consequence of external “events.

33
 REQUIREMENTS ANALYSIS

Dept. Of CSE, SVIT 34

MADHURA N , ASSISTANT PROFESSOR
 REQUIREMENTS ANALYSIS
 The analysis model is a snapshot of requirements at any given time.

 The primary focus is on what, not how. What user interaction occurs in a particular circumstance, what objects
does the system manipulate, what functions must the system perform, what behaviors does the system exhibit, what
interfaces are defined, and what constraints apply?

 The analysis model bridges the gap between a system-level

description and software design.

The requirements model must achieve three primary objectives:

(1) To describe what the customer requires,

(2) to establish a basis for the creation of a software design, and
(3) to define a set of requirements that can be validated once the
software is built.
Dept. Of CSE, SVIT 35
SCENARIO-BASED MODELLING

 Scenario-based elements depict how the user interacts with the system and the specific sequence of activities
that occur as the software is used.
 To capture details of the system from outside view.
What to write about
 The first two requirements engineering tasks inception and elicitation provide you with the information you’ll
need to begin writing use cases.
 Requirements gathering meetings, QFD, and other requirements engineering mechanisms are used to identify
stakeholders, define the scope of the problem, establish priorities, outline all known functional requirements,
and describe the things (objects) .
 To begin developing a set of use cases, list the functions or activities performed by a specific actor.

Dept. Of CSE, SVIT 36

1) Creating a Preliminary Use Case:

Home Surveillance Functions:

Actor: Home Owner

 Select Camera View

 Request Thumbnails from all cameras
 Display camera view in PC window
 Selectively record camera output
 Replay Camera output
 Access camera surveillance via Internet

Dept. Of CSE, SVIT 37

SCENARIO-BASED MODELLING

Use case: Access camera surveillance via the Internet—display camera views (ACS-DCV)
Actor: homeowner

1. The homeowner logs onto the SafeHome Products website.

2. The homeowner enters his or her user ID.
3. The homeowner enters two passwords (each at least eight characters in length).
4. The system displays all major function buttons.
5. The homeowner selects the “surveillance” from the major function buttons.
6. The homeowner selects “pick a camera.”
7. The system displays the floor plan of the house.
8. The homeowner selects a camera icon from the floor plan.
9. The homeowner selects the “view” button.
10. The system displays a viewing window that is identified by the camera ID.
11. The system displays video output within the viewing window at one frame per second.
Use cases of this type are sometimes referred to as primary scenarios.
Dept. Of CSE, SVIT 38
SCENARIO-BASED MODELLING

2) Refining a Preliminary Use Case:

Each step in the primary scenario is evaluated by asking the following questions:

 Can the actor take some other action at this point?

 Is it possible that the actor will encounter some error condition at this point? If so, what might it be?
 Is it possible that the actor will encounter some other behavior at this point (e.g., behavior that is invoked by
some event outside the actor’s control)? If so, what might it be?

Answers to these questions result in the creation of a set of secondary scenarios. (Considering 6 & 7 steps of primary
scenarios).

1. View thumbnail snapshots for all cameras.

2. No floor plan configured for this house.
3. Alarm condition encountered.
Dept. Of CSE, SVIT 39
 SCENARIO-BASED MODELING
3) Writing a Formal Use Case :

Formal usecase

 The goal in context identifies the overall scope of the use case.
 The precondition describes what is known to be true before the use case is
initiated.
 The trigger identifies the event or condition that “gets the use case started”
 The scenario lists the specific actions that are required by the actor and the
appropriate system responses.
Preliminary Use-Case diagram for
 Exceptions identify the situations uncovered as the preliminary use case is the Safe-Home Systems

refined.

Dept. Of CSE, SVIT 40

Dept. Of CSE, SVIT 41
 UML MODELS THAT SUPPLEMENTS THE USE CASE

Developing an Activity Diagram

It provides graphical representation of the flow of interaction within a specific scenario.

It helps in predicting the work flow from one activity to another.

An activity diagram uses:

 Rounded rectangles to imply a specific system function

 Arrows to represent flow through the system

 Decision diamonds to depict a branching decision.

 Solid horizontal lines to indicate that parallel

MADHURA N , ASSISTANT PROFESSOR
activities are occurring.
Dept. Of CSE, SVIT 42
 UML MODELS THAT SUPPLEMENTS THE USE CASE

Dept. Of CSE, SVIT 43

MADHURA N , ASSISTANT PROFESSOR
 UML MODELS THAT SUPPLEMENTS THE USE CASE
Swim Lane Diagram

 The UML swimlane diagram is a useful variation of the activity diagram.

 Allows you to represent the flow of activities described by the use case and at the same time indicate which
actor (if there are multiple actors involved in a specific use case) or analysis class as responsibility for the action
described by an activity rectangle.

 Responsibilities are represented as parallel segments that divide the diagram vertically, like the lanes in a
swimming pool.

 Three analysis classes—Homeowner, Camera, and Interface—have direct or indirect responsibilities in the
context of the activity diagram represented in Figure 6.5.

Dept. Of CSE, SVIT 44

MADHURA N , ASSISTANT PROFESSOR
UML MODELS THAT SUPPLEMENTS THE USE CASE

Dept. Of CSE, SVIT 45

Dept. Of CSE, SVIT 46
Dept. Of CSE, SVIT 47
 DATA MODELING CONCEPTS

 Data modeling is the process of documenting a complex software system design as an easily understood
diagram, using text and symbols to represent the way data needs to flow.

 The most widely used data Model by the Software engineers is Entity-Relationship Diagram (ERD), it
addresses the issues and represents all data objects that are entered, stored, transformed, and produced within an
application.

Data Objects :

 A data object is a representation of composite information that must be understood by software. Ex: width (a
single value) would not be a valid data object, but dimensions (height, width, and depth) could be defined as an
object.

 A data object can be an external entity (e.g., anything that produces or consumes information), a thing (e.g., a
report or a display), an occurrence (e.g., a telephone call) or event (e.g., an alarm), a role (e.g., salesperson), an
organizational unit (e.g., accounting department), a place (e.g., a warehouse), or a structure (e.g., a file).
Dept. Of CSE, SVIT 48
MADHURA N , ASSISTANT PROFESSOR
 DATA MODELING CONCEPTS

 For example, a person or a car can be viewed as a data object in the sense that either can be defined in terms of a
set of attributes.

Data attributes define the properties of a data object and take

on one of three different characteristics. They can be used to
(1) Name an instance of the data object,
(2) Describe the instance,
(3) Make reference to another instance in another table. In
addition, one or more of the attributes must be defined as an
identifier—that is, the identifier.

Dept. Of CSE, SVIT 49

MADHURA N , ASSISTANT PROFESSOR
 DATA MODELING CONCEPTS

Relationship : Data objects are connected to one another in

different ways. Consider the two data objects, person and car.

These objects can be represented using the following simple

notation and relationships are:

1) A person owns a car,

2) A person is insured to drive a car.

Dept. Of CSE, SVIT 50

MADHURA N , ASSISTANT PROFESSOR
Dept. Of CSE, SVIT 51
CLASS BASED MODELING
 Class-based modeling represents the objects that the system will manipulate, the
operations that will be applied to the objects to effect the manipulation, relationships
between the objects, and the collaborations that occur between the classes that are
defined.
 It defines structure of class we are developing.

 The elements of a class-based model include classes and objects, attributes, operations,
class responsibility collaborator (CRC) models, collaboration diagrams, and packages.

Class based modelling have four criteria

1. Identifying analysis classes
2. Specifying attributes
3. Defining operations
4. CRC modelling

Dept. Of CSE, SVIT 52

CLASS BASED MODELING
1) Identifying Analysis Classes
Classes are determined by examining the problem statement or underlining each noun or
noun phrase and entering it into a simple table.
Classes are necessary to implement a solution.
Classes are found in following forms:
• External entities: The system, people or the device.
• Things: The reports, displays, letter, signal are the part of the information domain or the problem.
• Occurrences or events: A property transfer or the completion of a series or robot movements.
• Roles: The people like manager, engineer, salesperson are interacting with the system.
• Organizational units: The division, group, team are suitable for an application.
• Places: The manufacturing floor or loading dock from the context of the problem and the overall function
of the system. Ex: warehouse
• Structures: The sensors, computers are defined a class of objects or related classes of objects.
53
CLASS BASED MODELING

2) Attributes

Attributes are the set of data objects that define a complete class within the context of the problem.
For example, 'employee' is a class and it consists of name, Id, department, designation and salary of the employee
are the attributes.

3) Defining Operations
Operations define the behavior of an object.

They are divided into 4 broad categories:

(1) Operations that manipulate data in some way (e.g., adding, deleting, selecting),
(2) Operations that perform a computation.
(3) Operations that inquire about the state of an object,
(4) Operations that monitor an object for the occurrence of a controlling event.

Class diagram for the System Class

Dept. Of CSE, SVIT 54

 CLASS BASED MODELING

Dept. Of CSE, SVIT 55

MADHURA N , ASSISTANT PROFESSOR
 CLASS BASED MODELING

4) Class-Responsibility-Collaborator (CRC) Modeling

 The CRC stands for Class-Responsibility-Collaborator.

 It provides a simple method for identifying and organizing the classes that are applicable to the system or
product requirement.
 A CRC model is a collection of standard index cards that represent classes. The cards are divided into three
sections:
Class name: card reader
• Top of the cards write class name
responsibility collaborator
• In the body, list the responsibility
• Collaborator on the right
Tell ATM – card inserted ATM
Read info Card
Eject card

Dept. Of CSE, SVIT 56

MADHURA N , ASSISTANT PROFESSOR
 CLASS BASED MODELING

• Collaborations represents request from client to server in fulfillment of a client responsibility.

• Classes can collaborate with other classes to fulfill the responsibility.

• Ex: one object collaborate with another if it needs to send some message to other objects.

• It identify relationships between objects

• Collaborations are identified by determining whether a class can fulfill each responsibility itself.
If it cannot, then it needs to interact with another class.

Dept. Of CSE, SVIT 57

 CLASS BASED MODELING

4) Class-Responsibility-Collaborator (CRC) Modeling Continued…

Ambler's CRC Model for SafeHome Example

Example: SafeHome System - FloorPlan Class

Let's consider a FloorPlan class in a home security system called
SafeHome.

The FloorPlan class is responsible for managing the layout of the house,
including walls and cameras.
Responsibilities:

1.Define floor plan name/type: Specify the name and type of

the floor plan (e.g., "Ground Floor", "Residential Layout").

2.Manage floor plan positioning: Handle the placement and

coordinates of elements within the floor plan, such as walls and
rooms.
Dept. Of CSE, SVIT 58
MADHURA N , ASSISTANT PROFESSOR
 CLASS BASED MODELING

4) Class-Responsibility-Collaborator (CRC) Modeling Continued…

Example: SafeHome System - FloorPlan Class

Responsibilities:

3. Scale floor plan for display: Adjust the floor plan to fit different display sizes or zoom levels, ensuring it is
viewable on various devices.
4. Show position of window cameras: Display the locations of window cameras within the floor plan, allowing
users to see camera coverage.

Collaborators:

1.Wall: Represents walls within the floor plan. The FloorPlan class interacts with the Wall class to define and
manage wall placements.
2.Camera: Represents cameras (specifically window cameras) within the floor plan. The FloorPlan class collaborates
with the Camera class to display camera positions.

Dept. Of CSE, SVIT 59

MADHURA N , ASSISTANT PROFESSOR
CLASS BASED MODELING

5) Associations and Dependencies:

 An association defines a relationship between classes or objects of another Each classes exchange information there
is a communication between them.
 An association may be further defined by indicating multiplicity.

 Multiplicity defines how many of one class are related to how many of another class.

Dependency- it is a relationship between two things in which change in one element also affects the other.
 Whenever there is a change in either the structure or the behavior of the class that affects the other class, such a
relationship is termed as a dependency. Or, simply, we can say a class contained in other class is known as
dependency.
Dept. Of CSE, SVIT 60
61
FLOW ORIENTED MODELING
• It shows how data objects are transformed by processing the functions.
• How information is transformed as it flows through the system.
Data flow diagram:
• Data flow diagram is a graphical representation of flow of data in an information system.
• It is capable of depicting incoming data flow, outgoing data flow and stored data.
• The data objects flow into the software, are transformed by processing elements and resultant data
objects flow out of the software.
• Data flow diagram may be used to represent a system or software at any level of abstraction
• DFDs are commonly used in the early stages of system development to analyze the current system
and design the new system.
• DFDs can also be used to communicate system requirements to developers, ensuring that
everyone has a clear understanding of how the system should function.
62
 FLOW ORIENTED MODELING

Components of DFD:
Level0- brief view of the system

Level 1- detail view of the system

Level 2 – more detail of the system

for specific task

Dept. Of CSE, SVIT 63

FLOW ORIENTED MODELING

• The level 0 DFD should depict the software system as a single unit.
• A Level 0 Data Flow Diagram (DFD) is a high-level representation of the system’s overall
structure, which shows how information flows between external entities and processes within the
system. It provides an overview of the system’s major processes and the interactions between
them.
• Primary input and output should be carefully noted.
• Refinement should begin by isolating candidate process data objects data stores to be represented
at next level.
• All arrows and bubbles should be labelled with meaningful names.
• Information flow continuity must be maintained from level to level.
• One bubble at a time should be refined.

Dept. Of CSE, SVIT 64

FLOW ORIENTED MODELING

Level o DFD

Dept. Of CSE, SVIT 65

FLOW ORIENTED MODELING

Grammatical parse
• Verbs- bubbles
• nouns – boxes
• Data/control objects- arrows
• Data stores- double lines

• Information flow should be maintained from level0 to level 1

• A Level 1 Data Flow Diagram (DFD) provides a more detailed view of the processes and data flows
identified in the Level 0 DFD. It breaks down the high-level processes into smaller sub-processes
and shows how they interact with each other via data flows.
• In a Level 1 DFD, each process represented in the Level 0 DFD is further decomposed into its sub-
processes or activities. The data flows between these processes are shown using arrows, indicating
the direction of data movement.

Dept. Of CSE, SVIT 66

FLOW ORIENTED MODELING

Level 1 DFD

Dept. Of CSE, SVIT 67

Level 1 DFD

• A Level 1 DFD for an online shopping system may show sub-processes such as
“Browse Products,” “Select Product,” “Add to Cart,” “Proceed to Checkout,” and
“Confirm Order.” Each of these sub-processes represents a specific task or activity
that is required to complete the overall process of online shopping.

Dept. Of CSE, SVIT 68

FLOW ORIENTED MODELING

Control flow model

Application which contains collection of classes are dependent on event rather than data,
produce control information rather than reports or displays.
Guidelines for control flow model
List all process(bubbles) that are performed by the software (alarm / telephone)
List all the interrupt conditions.
List all data conditions.
List all activities that are performed by operator or actor
Describe the behaviour of a system by identifying its states.

Dept. Of CSE, SVIT 69

 Control specification
• CSPEC represents the behaviour of the system in two different ways.
• It contains a state diagram- sequential specification of behaviour
• It contains program activation table- combinatorial specification of behaviour.

• By reviewing the state diagram, a software engineer can determine the behaviour of the system
and can discover whether there are “holes” in specified behaviour.

Dept. Of CSE, SVIT 70

State chart diagram

Dept. Of CSE, SVIT 71

 Process specification(PSEPC)
 PSEPC describe all flow model processes that appear at the final level of refinement

 It includes narrative text, a program design language(PDL) description of the process algorithm,
mathematical equations, table, diagrams or charts.

 When you make use of PSEPC , for each bubbles refined with in the flow model, this makes a list
of “ mini specification” , i.e list of activities embedded in the software these mini specification
acts as a guide for designing the software components, intern going to implement the process.

Dept. Of CSE, SVIT 72

BEHAVIOUR MODELING

It defines how software responds to external events .

Represent the behaviour of the system as a function of specific events and time.

To create model we should follow following steps

• Evaluate all use case to fully understand the sequence of interaction within the system.
• Identify the events that driven the interaction sequence and understand how these events relate
to specific objects.
• Create a sequence for each use case
• Build a state diagram for the system
• Review the behavioural model to verify accuracy and consistency

Dept. Of CSE, SVIT 73

 State Representation

• A state of a class takes on both active and passive characteristics.

• Passive State is simply the current status of all of an object’s attributes. Ex: Player –class
• Current position and orientation –attributes of players.
• Active State is current state of the object as it undergoes a continuous transformation or
processing. Ex: Player –class
• Active state –moving, injured, trapped, lost etc.
• An event must occur to force an object to make a transition from one active state to
another.
State diagram for analysis classes
This represents active states for each class and the events that cause changes between these active
states.
Figure illustrates a state diagram for the Control Panel object in the Safe Home security function.
Each arrow shown in Figure represents a transition from one active state of an object to another

Dept. Of CSE, SVIT 75

BEHAVIOUR MODELING – Sequence diagram
• A sequence diagram simply depicts interaction between objects in a sequential order i.e. the order
in which these interactions take place.
• We can also use the terms event diagrams or event scenarios to refer to a sequence diagram. How
events cause transitions from object to object.

Dept. Of CSE, SVIT 76