P20CAT2001 – SOFTWARE ENGINEERING

& QUALITY ASSURANCE

Dr.V.Geetha
Department of Computer Applications
II. MODELING
Understanding Requirements – Scenario Based Requirements Modeling, Data Modeling
Concepts, Class Based Requirements Modeling.
 Learning Objectives
• After undergoing this course the student should:

CO 1 : Get an insight into the processes of software development.

CO 2 : Understand the problem domain and modeling.

CO 3 : Apply design techniques software products.

CO 4 : Implement software quality management concepts.

CO 5: Apply software testing techniques for information systems development

3
Requirements
• A requirement is something that a computer application must do for its
users.
• Requirements constitute part of the scope of a software development project.
• The requirements also dictate how the system should respond to user
interaction.
Understanding Requirements
• Understanding requirements is the most difficult tasks faced by the software
engineer
• They have the trouble understanding the requirements acquired from the
customer
• They record requirements in a disorganized manner
• They spend far too little time verifying what they do record
• They allow change to control us, rather than establishing mechanisms to control
change
• Most importantly, they fail to establish a solid foundation for the system or
software that the user wants built

5
Understanding Requirements Contd..
• Many software developers argue that
• Building software is so compelling that we want to jump right in (before having a
clear understanding of what is needed)
• Things will become clear as we build the software
• Project stakeholders will be able to better understand what they need only after
examining early iterations of the software
• Things change so rapidly that requirements engineering is a waste of time
• The bottom line is producing a working program and that all else is secondary
• All these arguments contain some truth, especially for small projects that take less than
one month to complete
• However, as software grows in size and complexity, these arguments begin to break
down and can lead to a failed software project

6
A Solution: Requirements Engineering
• The broad spectrum of tasks and techniques that lead to an understanding of
requirements is called requirements engineering.
• Begins during the communication activity and continues into the modeling
activity
• Builds a bridge from the system requirements into software design and
construction
• Allows the requirements engineer to examine
• the context of the software work to be performed
• the specific needs that design and construction must address
• the priorities that guide the order in which work is to be completed
• the information, function, and behavior that will have a profound impact on
the resultant design

7
A Bridge
Requirements - Examples
Functional Requirements
Functional Requirements Contd..
Nonfunctional Requirements

Nonfunctional Requirements (NFRs) define system attributes such as security, reliability,

performance, maintainability, scalability, and usability.
Requirements Engineering Tasks
• Seven distinct tasks
Inception
Elicitation
Elaboration
Negotiation
Specification
Validation
Requirements Management
• Some of these tasks may occur in parallel and all are adapted to the needs of the project
• All strive to define what the customer wants
• All serve to establish a solid foundation for the design and construction of the software

14
Example: Campus Information
Access Kiosk
• Both podium-high and desk-high terminals located throughout the campus in
all classroom buildings, admin buildings, labs, and dormitories
• Hand/Palm-login and logout (seamlessly)
• Voice input
• Optional audio/visual or just visual output
• Immediate access to all campus information plus
• E-mail
• Cell phone voice messaging

15
Inception Task
• Most projects begin when a business need is identifies
• Stakeholders define a business case (outlines the why, what, how, and who necessary to decide if it is
worthwhile continuing a project)
E.g. https://expertprogrammanagement.com/2017/06/project-business-case/
• During inception, the requirements engineer asks a set of questions to establish…
 A basic understanding of the problem
 The people who want a solution
 The nature of the solution that is desired
 The effectiveness of preliminary communication and collaboration between the customer and the
developer
• Through these questions, the requirements engineer needs to…
 Identify the stakeholders
 Recognize multiple viewpoints
 Work toward collaboration
 Break the ice and initiate the communication

16
The First Set of Questions
These questions focus on the customer, other stakeholders, the overall goals, and the
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 need?

17
The Next Set of Questions
These questions enable the requirements engineer to gain a better understanding of
the problem and allow the customer to voice his or her perceptions about a solution

• How would you characterize "good" output that would be generated by a

successful solution?
• What problem(s) will this solution address?
• Can you show me (or describe) the business environment in which the solution
will be used?
• Will special performance issues or constraints affect the way the solution is
approached?

18
 The Final Set of Questions
These questions focus on the effectiveness of the
communication activity itself

• Are you the right person to answer these questions? Are your answers
"official"?
• Are my questions relevant to the problem that you have?
• Am I asking too many questions?
• Can anyone else provide additional information?
• Should I be asking you anything else?

19
Elicitation Task ( Requirements gathering)
• Asking the customer, the users and others what are the objectives of the system, what is to be
accomplished, how the system fits into the needs of the business & how the system will be used
on a day-today basis.
• Eliciting requirements is difficult because of
• Problems of scope in identifying the boundaries of the system or specifying too much
technical detail rather than overall system objectives
• Problems of understanding what is wanted, what the problem domain is, and what the
computing environment can handle (Information that is believed to be "obvious" is often
omitted)
• Problems of volatility because the requirements change over time
• Elicitation may be accomplished through two activities
• Collaborative requirements gathering
• Quality function deployment

20
Basic Guidelines of Collaborative Requirements
Gathering
• Meetings are conducted and attended by both software engineers, customers, and other
interested stakeholders
• Rules for preparation and participation are established
• An agenda is suggested that is formal enough to cover all important points but
informal enough to encourage the free flow of ideas
• A "facilitator" (customer, developer, or outsider) controls the meeting
• A "definition mechanism" is used such as work sheets, flip charts, wall stickers,
electronic bulletin board, chat room, or some other virtual forum
• The goal is to identify the problem, propose elements of the solution, negotiate
different approaches, and specify a preliminary set of solution requirements

21
Quality Function Deployment (QFD)
• This is a technique that translates the needs of the customer into technical requirements
for software
• It emphasizes an understanding of what is valuable to the customer and then deploys
these values throughout the engineering process through functions, information, and tasks
• It identifies three types of requirements
• Normal requirements: These requirements are the objectives and goals stated for a
product or system during meetings with the customer. If these are present, customer
is satisfied.
E.g. Entry of marks, calculation of results ( in a result management system)
• Expected requirements: These requirements are implicit to the product or system
and may be so fundamental that the customer does not explicitly state them. Absence
will cause customer dissatisfaction.
E.g. Protection from unauthorized access , Ease of software installation
• Exciting requirements: These requirements are for features that go beyond the
customer's expectations and prove to be very satisfying when present
E.g. when unauthorized access is detected, it should backup and shutdown all processes
22
 Elicitation Work Products
The work products will vary depending on the system, but should
include one or more of the following items

• A statement of need and feasibility

• A bounded statement of scope for the system or product
• A list of customers, users, and other stakeholders who participated in requirements
elicitation
• A description of the system's technical environment
• A list of requirements (organized by function) and the domain constraints that apply to each
• A set of preliminary usage scenarios (in the form of use cases) that provide insight into the
use of the system or product under different operating conditions
• Any prototypes developed to better define requirements

23
UML Diagram for Eliciting Requirements
 Elaboration Task
• During elaboration, the software engineer takes the information obtained during
inception and elicitation and begins to expand and refine it
• Elaboration focuses on developing a refined technical model of software functions,
features, and constraints
• It is an analysis modeling task
• Use cases are developed
• Domain classes are identified along with their attributes and relationships
• State machine diagrams are used to capture the life on an object
• The end result is an analysis model that defines the functional, informational, and
behavioral domains of the problem

25
 Developing Use Cases
• Step One – Define the set of actors that will be involved in the story
• Actors are people, devices, or other systems that use the system or
product within the context of the function and behavior that is to be
described
• Actors are anything that communicate with the system or product and
that are external to the system itself
• Step Two – Develop use cases, where each one answers a set of questions

(More on next slide)

26
 Questions Commonly Answered by a
Use Case
• Who is the primary actor(s), the secondary actor(s)?
• What are the actor’s goals?
• What preconditions should exist before the scenario begins?
• What main tasks or functions are performed by the actor?
• What exceptions might be considered as the scenario is described?
• What variations in the actor’s interaction are possible?
• What system information will the actor acquire, produce, or change?
• Will the actor have to inform the system about changes in the external environment?
• What information does the actor desire from the system?
• Does the actor wish to be informed about unexpected changes?

27
 Elements of the Analysis Model
• Scenario-based elements
• Describe the system from the user's point of view using scenarios that are depicted in use
cases and activity diagrams
• Class-based elements
• Identify the domain classes for the objects manipulated by the actors, the attributes of
these classes, and how they interact with one another; they utilize class diagrams and
collaboration diagram to do this
• Behavioral elements
• Use state diagrams to represent the state of the system, the events that cause the system
to change state, and the actions that are taken as a result of a particular event; can also be
applied to each class in the system
• Flow-oriented elements
• Use data flow diagrams to show the input data that comes into a system, what functions
are applied to that data to do transformations, and what resulting output data are
produced

28
 Negotiation Task
• During negotiation, the software engineer reconciles the conflicts between what
the customer wants and what can be achieved given limited business resources
• Requirements are ranked (i.e., prioritized) by the customers, users, and other
stakeholders
• Risks associated with each requirement are identified and analyzed
• Rough guesses of development effort are made and used to assess the impact of
each requirement on project cost and delivery time
• Using an iterative approach, requirements are eliminated, combined and/or
modified so that each party achieves some measure of satisfaction

29
The Art of Negotiation
• Recognize that it is not competition
• Map out a strategy
• Listen actively
• Focus on the other party’s interests
• Don’t let it get personal
• Be creative
• Be ready to commit

30
 Specification Task
• A specification is the final work product produced by the requirements engineer
• It is normally in the form of a software requirements specification (SRS)
• It serves as the foundation for subsequent software engineering activities
• It describes the function and performance of a computer-based system and the
constraints that will govern its development
• It formalizes the informational, functional, and behavioral requirements of the
proposed software in both a graphical and textual format

31
Typical Contents of a Software Requirements
Specification
• Requirements
• Required states and modes
• Software requirements grouped by capabilities (i.e., functions, objects)
• Software external interface requirements
• Software internal interface requirements
• Software internal data requirements
• Other software requirements (safety, security, privacy, environment, hardware,
software, communications, quality, personnel, training, logistics, etc.)
• Design and implementation constraints
• Qualification provisions to ensure each requirement has been met
• Demonstration, test, analysis, inspection, etc.
• Requirements traceability
• Trace back to the system or subsystem where each requirement applies

32
Validation Task
• During validation, the work products produced as a result of requirements
engineering are assessed for quality
• The specification is examined to ensure that
• all software requirements have been stated unambiguously
• inconsistencies, omissions, and errors have been detected and corrected
• the work products conform to the standards established for the process, the
project, and the product
• The formal technical review serves as the primary requirements validation
mechanism
• Members include software engineers, customers, users, and other
stakeholders

33
 Questions to ask when Validating Requirements
• Is each requirement consistent with the overall objective for the system/product?
• Have all requirements been specified at the proper level of abstraction? That is,
do some requirements provide a level of technical detail that is inappropriate at
this stage?
• 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?
• Does each requirement have attribution? That is, is a source (generally, a specific
individual) noted for each requirement?

34
 Questions to ask when Validating Requirements
Contd….
• 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?
• Approaches: Demonstration, actual test, analysis, or inspection
• 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?

35
Requirements Management Task
• During requirements management, the project team performs a set of activities
to identify, control, and track requirements and changes to the requirements at
any time as the project proceeds
• Each requirement is assigned a unique identifier
• The requirements are then placed into one or more traceability tables
• These tables may be stored in a database that relate features, sources,
dependencies, subsystems, and interfaces to the requirements
• A requirements traceability table is also placed at the end of the software
requirements specification

36
Requirements Modeling
Requirements Modeling
• Uses a combination of text and diagrammatic representation to depict the
requirements in an easy way
Importance of Requirements Modeling
• To validate software requirements, it has to be examined them from a number of
different points of view.
• Requirements modeling is considered from three different perspectives:
scenario- based models, data(information) models, and class-based
models
• Each represents requirements in a different “dimension,” thereby increasing the
probability that errors will be found, that inconsistency will surface, and that
omissions will be uncovered.
Requirements Analysis
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”.
• Data models that depict the information domain for the problem.
•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.
Overall Objectives and Philosophy
In requirements modeling, 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 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
Analysis Rules of Thumb
Rules to be followed when creating the analysis model:

•The model should focus on requirements that are visible within the problem or
business domain. The level of abstraction should be relatively high.

•Each element of the requirements model should add to an overall understanding of

software requirements and provide insight into the information domain, function,
and behavior of the system.

•Delay consideration of infrastructure and other nonfunctional models until design.

•Minimize coupling throughout the system

•Be certain that the requirements model provides value to all stakeholders

•Keep the model as simple as it can be.

Requirements Modeling Approaches

Elements of the requirements model

Scenario-based Modeling
• Although the success of a computer-based system or product is measured in
many ways, user satisfaction is at the top of the list.

• If you understand how end users (and other actors) want to interact with a
system, your software team will be better able to properly characterize
requirements and build meaningful analysis and design models.

• Hence, requirements modeling with UML begins with the creation of

scenarios in the form of use cases, activity diagrams.
 Use Cases

• A simple but very effective model for analysing requirements through the process of exploring user interactions with the
system
• Specify the behaviour of the system or a part of the system
• Is a description of a set of sequences of actions
• Scenarios for understanding system requirements
• Capture the intended behaviour of the system without specifying how the behavior is implemented
• Helps to come to a common understanding with the system's end users and domain expert
• Represents a functional requirement of the system as a whole
• Involves the interaction of users (actors) and the system
• An Actor is outside or external the system.
• It can be a:
• Human
• Peripheral device (hardware)
• External system or subsystem
• Time or time-based event

• An actor is who or what initiates the events involved in the task of the use case
• Represented by stick figure
Use Cases Contd..
The USE CASE should contain
• How & WHEN the use case begins & ends
• The interaction between the use case and the actors ( When the interaction occurs & what is
exchanged)
• How and when the use case will need data stored in the system or will store the data in the
system
• Exception to the flow of events

Eg. SCENARIO
A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the
nearest empty time slot in the appointment book and schedules the appointment for that time slot.
The actor is a Patient
Use Cases Contd..
The use case is a summary
The Use Case is Make Appointment of scenarios for a single task or goal.
Labelled using a descriptive verb-noun phrase
Represented by an oval shape
Use Case Example
ATM System
Main Flow of Events
• The use case starts when the system prompts the customer for a PIN No.
• Customer can enter the PIN no. via Keyboard
• Customer presses the enter key to commit the entry
• The system then checks to see if this PIN no. is valid
• If PIN No. is valid , the system acknowledges the entry , thus ending the use case

Exceptional /Alternate Flow of Events

i) Customer can cancel the transaction at any time by pressing the cancel button, thus restarting the use
case. No changes are made to customer account.
ii) The customer can clear a PIN number anytime before committing it and reenter a new PIN number
iii) If the customer enters an invalid PIN number, the use case restarts. If this happens 3 times, the system
cancels the entire transaction preventing the customer interacting with the ATM for 1 day.
• This one use case actually describes a set of sequences in which each
sequence in the set represents one possible flow through these variations.
• Each sequence is called a Scenario
• A scenario is a specific set of actions that illustrates behaviour
• A scenario is basically one instance of a use case
• Every single use case should describe 1 main flow of event
• An exceptional /Additional flow of events could be added

Eg. A user interaction with a cash dispenser or ATM.

This system (a completely automated system, as opposed to a manual one)
provides the following functionality.

• Request Cash
• Request Balance
• Request Statement
• Request Cheque book
 Request Balance Request Statement

Customer

Request Cash Request Cheque Book

Request Statement

Printer

Request Cash

Customer
Request Cheque Book

Bank Central Computer

Request Balance
Use Case Diagram for ATM Withdrawal
Example : Library user Interaction - Use Cases

• As a user, you expect a library to offer you the following services and the
librarian, being a domain expert will know how to perform these tasks.

• Checking out a book for loan.

• Checking in a returned book.
• Checking if a book is in stock and where to find it.
• Reserving a book that is currently out on loan.
• Dealing with payment of overdue fines.
• Adding new members to the library.
• Deleting old members from the library.
• Dealing with changes of members details e.g. name address etc.
More Detailed Description Use Case Description “Borrow Book””

Use-Case: Borrow Book

• The borrower/member identifies himself or herself to the librarian using their membership card.
• The borrower/member presents one or more books to the Librarian.
• The Librarian checks the membership card to make sure it is valid.
• The Librarian checks the books to make sure they can be loaned.
• The Librarian looks up the member’s records in his/her card indexing system and checks that the
number of loaned books will be less than 6
(the maximum that can be loaned at any time to a library member).
• If acceptable, each book is then stamped with the appropriate return date (2 weeks from today).
• Each book has its identifying card removed from the inside cover.
• The Librarian updates the member’s loan details by placing the identifying cards into that members
record maintained by the library.
End
Use Cases – Types of relationships
Three types of relationships
• Generalization
• Include
• Extend

i) Generalization
• Generalization among classes
• The child use case inherits the behaviour and meaning of the parent use case
• Represented by a line and a hollow arrow from child to parent
Use Cases – Types of relationships
ii) Include
• Example of Delegation
• This relationship between use cases means that the base use case explicitly incorporates
the behavior of another use case
• The included use case never stands alone, but is only instantiated as a part of larger base
that includes it

iii) Extends
• The base use case implicitly incorporates the behavior of another use case
• The base use case may stand alone but under certain conditions its behavior may be
extended by the behaviour of another use case
• May be extended at certain points called extension point.
• Used to model the part of the use case that the user may see as optional system
behaviour
• Put the normal behavior in one use-case and the exceptional behavior
 Place Place rush
<< extend >> order
Order
(set priority)

<< include >>

Check
password
Check
order Validate
Generalization
user

<< include >> Retinal

Scan
Use Case Relationships

<<extends>> Place rush

(set priority) order

Check password
Place order <<uses>>
Extension points
set priority Vaildate user
Retinal scan
Creating a Preliminary Use Case
Creating a Preliminary Use Case Contd…
Creating a Preliminary Use Case
Homeowner actor:
•Select camera to view.
•Request thumbnails from all cameras.
•Display camera views in a PC window.
•Control pan and zoom for a specific camera.
•Selectively record camera output.
•Replay camera output.
•Access camera surveillance via the Internet.
conversations with the stakeholder (who plays the role of a homeowner)
Use case: Access camera surveillance via the Internet—display camera views
(ACS- DCV)
Actor: homeowner:
If I’m at a remote location, I can use any PC with appropriate browser software to log
on to the Safe Home Products website. I enter my user ID and two levels of passwords
and once I’m validated, I have access to all functionality for my installed Safe Home
system. To access a specific camera view, I select “surveillance” from the major
function buttons displayed. I then select “pick a camera” and the floor plan of the
house is displayed. I then select the camera that I’m interested in. Alternatively, I can
look at thumbnail snapshots from all cameras simultaneously by selecting “all
cameras” as my viewing choice. Once I choose a camera, I select “view” and a one-
frame-per-second view appears in a viewing window that is identified by the camera
ID. If I want to switch cameras, I select “pick a camera” and the original viewing
window disappears and the floor plan of the house is displayed again.
I then select the camera that I’m interested in. A new viewing window appears.
Use case: Access camera surveillance via the Internet—display camera views
(ACS-DCV)
Actor: homeowner
1.The homeowner logs onto the Safe Home 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.
Refining a Preliminary Use Case
• A description of alternative interactions is essential for a complete understanding
of the function that is being described by a use case.
• Therefore, 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?
 Refining a Preliminary Use Case
E.g.
Consider steps 6 and 7 in the primary scenario presented earlier:

6.The homeowner selects “pick a camera.”

7.The system displays the floor plan of the house.

Can the actor take some other action at this point? The answer is “yes.” Referring to the
free-flowing narrative, the actor may choose to view thumbnail snapshots of all cameras
simultaneously.
Hence, one secondary scenario might be “View thumbnail snapshots for all cameras.”
 Writing a Formal Use Case

• The informal use cases presented in the previous Section are sometimes
sufficient for requirements modeling.

• However, when a use case involves a critical activity or describes a

complex set of steps with a significant number of exceptions, a more
formal approach may be desirable.
Use Case Descriptions – High Level
Descriptions
Use case: Issue bike
Actors: Receptionist
Goal: To hire out a
bike
Description:
When a customer comes into the shop they choose a bike to
hire. The Receptionist looks up the bike on the system and
tells the customer how much it will cost to hire for a specified
period. The customer pays, is issued with a receipt, then
leaves with the bike.
Use case : Issue bike
Actors: Receptionist
Goal: To hire out a
Overview: bike
When a customer comes into the shop they choose a bike to hire. The receptionist looks
up the bike on the system and tells the customer how much it will cost to hire the bike for a
specified period. The customer pays, is issued with a receipt, then leaves with the bike.
Cross reference R3, R4, R5, R6, R7, R8, R9, R10
Typical course of events
Actor action System response

1. The customer chooses a bike

2.The Receptionist keys in the bike number 3. Displays the bike details

4. Customer specifies length of hire

5. Receptionist keys this in 6. Displays total hire cost
7. Customer agrees the price
8. Receptionist keys in the customer details 9. Displays customer details
10. Customer pays the total cost
11. Receptionist records amount paid 12. Prints a receipt

Alternative courses
Steps 8 and 9. The customer details are already in the system so the Receptionist needs only
to key in an identifier and the system will display the customer details. Steps 7 – 12. The
customer may not be happy with the price and may terminate the
transaction.
Activity Diagrams
• Activity diagram supplements the use case diagram
• Activity Diagrams are also useful for:
• analyzing a use case by describing what actions need to take place and
when they should occur;
• a complicated sequential algorithm; and
• modeling applications with parallel processes
• Provides the flow of interaction within a specific scenario
Activity Diagram Symbols
• Symbols used:
• Rounded rectangle for functions
• Arrow to represent the flow through the system
• Decision diamonds to depict a branching decision
• Solid horizontal lines to indicate parallel activities that are occuring

Activity Transition Decision

Developing an Activity Diagram
Activity Diagram for ATM
Authorization
Swimlane Diagrams
• Useful variation of an activity diagram
• Represents the flow of activities described by the use case and indicate
which actor/analysis class has the responsibility for the action
• Responsibilities are represented as parallel segments that divide the
diagram vertically ( like the lanes in the swimming pool)
 Swimlane
- partition an activity
diagram so that parts in
the swimlane relevant to
that activities in the
partition
- helpful in investigating
responsibilities for
interactions and
associations between
objects and actors

OOAD 73
 Data Modeling Concepts
• If software requirements include the need to create, extend, or
interface with a database or if complex data structures must be constructed
and manipulated, the software team may choose to create a data model as
part of overall requirements modeling.
• Data models are defined by the software engineer/analyst.
• Entity Relationship (ER) diagrams are used to show the relationship between
these data objects.
Data Objects
• A data object is a representation of composite information that must be
understood by software.
• Composite information - something that has a number of different properties
or attributes.
E.g. dimensions(incorporating height, width, and depth) could be defined as an object.
• A data object can be an external entity, a thing(a report/a display), an
occurrence( telephone call) or event( alarm) , a role(a salesperson), an
organizational unit( accounting department) , a place( warehouse) or a
structure ( a file).
E.g. A person, a car
• A data object encapsulates data only and can be represented as a table.
Data Attributes
• Data attributes define the properties of a data object
• It takes 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
 Relationships
• Data objects are connected to one another in different ways. Consider the
two data objects, person and car.
• A person owns a car.
• A person is insured to drive a car.
 Entity-Relationship Diagrams
• The object-relationship pair is the cornerstone ( most important ) of the
data model.
• These pairs can be represented graphically using the entity- relationship
diagram (ERD).
• A set of primary components is identified for the ERD:
 data objects
 attributes
 relationships
 various type indicators
• The primary purpose of the ERD is to represent data objects and their
relationships.
ER Diagram :Example
Class-Based Modeling
• Class-based modeling represents the objects that the system will manipulate,
the operations (also called methods or services) that will be applied to the
objects to effect the manipulation relationships.
• The collaborations that occur between the classes are defined.
• Elements include:
• Classes & Objects
• Attributes
• Operations
• CRC Models( Class-Responsibility-Collaborator)
• Collaboration diagrams
• Packages
Identifying Analysis Classes
•If you look around a room, there is a set of physical objects that can be easily
identified, classified, and defined (in terms of attributes and operations).
•Classes can be identified by
• examining the usage scenarios developed as a part of requirements model
• Performing a grammatical parse on the use cases.
•Underline each noun or noun phrase and enter it into a simple table
Identifying Analysis Classes Contd..

Analysis classes manifest them selves in one of the following ways:

• External entities(e.g.,other systems, devices, people) that produce or consume
information to be used by a computer-based system.
• Things(e.g., reports, displays, letters, signals) that are part of the information
domain for the problem.
• Occurrences or events(e.g., a property transfer or the completion of a series of
robot movements) that occur within the context of system operation. Roles(e.g.,
manager, engineer, salesperson) played by people who interact with the system.
• Organizationalunits(e.g., division, group, team) that are relevant to an
application.
• Places(e.g., manufacturing floor or loading dock) that establish the context of the
problem and the overall function of the system.
• Structures(e.g., sensors, four-wheeled vehicles, or computers) that define a class
of objects or related classes of objects.
Potential Classes Example
Selection characteristics for each potential
class
Coad and Yourdon suggest six selection characteristics that should be used as
you consider each potential class for inclusion in the analysis model:

• Retained information- Potential class will be useful during analysis only if information
about it must be remembered so that the system can function.
• Needed services- The potential class must have a set of identifiable operations that can
change the value of its attributes in some way.
• Multiple attributes- A class with a single attribute may be represented as an attribute of
another class rather than a class
• Common attributes- The attributes of the potential class should apply to all instances of
the class.
• Common operations – The operations of the potential class should apply to all instances
of the class.
• Essential requirements -
Specifying Attributes
• Attributes are the set of data objects that fully define the class
within the context of the problem
• Attributes describe a class that has been selected for inclusion in
the requirements model.
• To develop a meaningful set of attributes, each use case should
be studied and only those things that reasonably belong to the
class must be selected.
Defining Operations
• Operations define the behavior of an object.
• Operations can be divided into 4 categories:
• Operations that manipulate data in some way ( adding, deleting, reformatting, selecting)
• Operations that perform a computation
• Operations that inquire about the state of an object
• Operations that monitor an object for the occurrence of a controlling event
• When you define operations for an analysis class, focus on problem-oriented
behavior rather than behaviors required for implementation
• In addition to grammatical parsing, consider the communication that occurs
between objects.
• Objects communicate by passing messages to one another
Defining Operations
Class-Responsibility-Collaborator
(CRC) Modeling
Class-responsibility-collaborator (CRC) modeling provides a simple means for
identifying and organizing the classes that are relevant to system or product
requirements.
• It is collection of standard index cards that that represent classes.
• The cards are divided into 3 sections. Along the top of the card the name of
the class, the class responsibilities on the left of the card and the collaborators
on the right of the card (in the body of the card).
CRC Index Card

Clas
s:Clas
Class:
Descript ion
s:
Class:
: Descript ion FloorPlan
: Descript ion
Responsibility:
: Description:
Responsibility:
Responsibility:
Collaborator:
Responsibili
Collaborator: Collaborator:
Collaborator:
ty: floor plan name/type
defines
manages floor plan positioning
scales floor plan for display
scales floor plan for
displayporat es walls, doors and
incor Wall
windows shows position of video Camer
cameras a

91
CRC card Example
Taxonomy of class types
Entity Class (model or business class) are extracted directly from the
statement of the problem. These classes typically represent things that are to
be stored in the database and persist throughout the duration of the
application.

Boundary class – used to create an interface (interactive screen/printed

reports) that the user sees and interacts with as the software is used.

Controller Class – manage ‘a unit of work’ from start to finish.

Responsibilities

Guidelines for allocating responsibilities:

•System intelligence should be distributed across classes address
the needs of the problem.
• Each responsibility should be stated as generally as possible.
• Information and the behavior related to it should reside within the same class.
• Information about one thing should be localized with a single class not distributed across
multiple classes.
• Responsibilities should be shared among the related classes.
Collaborations
• Collaborations represent requests from a client to a server in fulfilment of a
client responsibility.
• Classes fulfil their responsibility in 2 ways:
• A class can use its own operations to manipulate its own attributes, thereby fulfilling a
particular responsibility
• A class can collaborate with other classes
• Collaborations are identified by determining whether a class can fulfill each
responsibility itself. If it cannot, then it needs to interact with other classes
( Collaboration)
• Three different generic relationships between classes :
 the is-part-of relationship
 the has-knowledge-of relationship
 the depends-upon relationship
Composite Aggregate Class
(is-part-of Example in
UML)
Playe
r

PlayerHead PlayerBody PlayerArms PlayerLegs

96
Associations & Dependencies

• An association defines a relationship between classes.

• Multiplicity defines how many of one class are related to how

many of another class
• In many instances, two analysis classes are related to one another
in some fashion, much like two data objects may be related
to one another.
• In UML these relationships are called associations.
• Associations can be refined by indicating multiplicity(the term
cardinality is used in data modeling)
• In many instances, a client-server relationship exists between
two analysis classes.
• In such cases, a client-class depends on the server- class in
some way and a dependency relationship is established
Multiplicity

Wall

1 1 1

is used to build is used to build

1.. 0..
0..* is used to build
* *
WallSegm Window Door
ent

98
Dependencies

DisplayWindow Camer
a
<<access>>

{password}

99
Analysis Packages
• Various elements of the analysis model (e.g., use-cases, analysis classes) are
categorized in a manner that packages them as a grouping
• The plus sign preceding the analysis class name in each package indicates
that the classes have public visibility and are therefore accessible from other
packages.
• Other symbols can precede an element within a package. A minus sign
indicates that an element is hidden from all other packages and a # symbol
indicates that an element is accessible only to packages contained within a
given package.

10
0
Analysis Packages

package name

10
1