1. Unit-3 Analysis Modeling

2. Requirements analysis results in the specification of software’s operational characteristics, indicates software’s interface with other system elements, and establishes constraints that software must meet.
Requirements analysis allows you (regardless of whether you’re called a software engineer, an analyst, or a modeler) to elaborate on basic requirements established during the inception, elicitation, and negotiation tasks that are part of requirements engineering

3. The requirements modeling action results in
Scenario-based models of requirements from the point of view of various system “actors”
Data models that depict the info 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”

4. The requirements model must achieve three primary objectives:
to describe what the customer requires,
to establish a basis for the creation of a software design,
to define a set of requirements that can be validated once the software is built.

5. The analysis model bridges the gap between a system-level description that describes overall system or business functionality as it is achieved by applying software, hardware, data, human, and other system elements and a software design that describes the software’s application architecture, user interface, and component-level structure

6. Analysis Rules of Thumb
The analysis 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 analysis model should add to an overall understanding of software requirements and provide insight into the following
Information domain, function, and behavior of the system
The model should delay the consideration of infrastructure and other non-functional models until the design phase
First complete the analysis of the problem domain

7. Analysis Rules of Thumb
The model should minimize coupling throughout the system
Reduce the level of interconnectedness among functions and classes
The model should provide value to all stakeholders
The model should be kept as simple as can be

8. Domain Analysis Definition
The identification, analysis, and specification of common, reusable capabilities within a specific application domain
Do this in terms of common objects, classes, subassemblies, and frameworks
Sources of domain knowledge
Technical literature
Existing applications
Customer surveys and expert advice
Current/future requirements
Outcome of domain analysis
Class taxonomies
Reuse standards
Functional and behavioral models
Domain languages

9. Requirements Modeling Approaches
Domain Analysis
Requirements Modeling Approaches

10. A Set of Models
Flow-oriented modeling – provides an indication of how data objects are transformed by a set of processing functions
Scenario-based modeling – represents the system from the user's point of view
Class-based modeling – defines objects, attributes, and relationships
Behavioral modeling – depicts the states of the classes and the impact of events on these states

11. Analysis Modeling Data modeling Object oriented analysis
Scenario-based modeling
Flow modeling
Class based modeling
Behavioral modeling

12. Goals of Analysis Modeling
Provides the first technical representation of a system
Is easy to understand and maintain
Deals with the problem of size by partitioning the system
Uses graphics whenever possible
Differentiates between essential information versus implementation information
Helps in the tracking and evaluation of interfaces
Provides tools other than narrative text to describe software logic and policy

13. Analysis Modeling Approaches
Structured analysis
Considers data and the processes that transform the data as separate entities
Data is modeled in terms of only attributes and relationships (but no operations)
Processes are modeled to show the 1) input data, 2) the transformation that occurs on that data, and 3) the resulting output data
Object-oriented analysis
Focuses on the definition of classes and the manner in which they collaborate with one another to fulfill customer requirements

14. Elements of the Analysis Model
Object-oriented Analysis
Structured Analysis
Use case text
Use case diagrams
Activity diagrams
Swim lane diagrams
Scenario-based
modeling
Data structure diagrams
Data flow diagrams
Control-flow diagrams
Processing narratives
Flow-oriented
modeling
Class diagrams
Analysis packages
CRC models
Collaboration diagrams
Class-based
modeling
State diagrams
Sequence diagrams
Behavioral
modeling

15. Data Modeling Concepts
The entity-relationship diagram (ERD) addresses these 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.
Example: width (a single value) would not be a valid data object, but dimensions (incorporating height, width, and depth) could be defined as an object.

16. A data object can be an. external entity (e. g
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), a structure (e.g., a file) 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. The description of the data object incorporates the data object and all of its attributes.

18. Data Attributes define the properties of a data object and take on one of three different
characteristics. They can be used to
name an instance of the data object,
Describe the instance, or
make reference to another instance in another table.

19. Relationship
Cardinality (number of occurrences)

20. Scenario based Modeling
User satisfaction
Properly characterize requirements
Actors Interaction with the system
Build meaningful analysis models
Requirements modeling
UML
Usecase
Activity diagrams
Swimlane diagrams

21. Creating a preliminary Use Case
Contract for behavior
what to write about (inception and elicitation)
Requirements gathering meeting, QFD, scope, functional requirements etc.
how much to write about it
how detailed to make your description
how to organize the description?

22. Writing Use Cases Use-case title: Actor: Description: I …
It is effective to use the first person “I” to describe how the actor interacts with the software
Format of the text part of a use case
Use-case title:
Actor:
Description: I …

23. Use Case

25. Example 1 Use Case Diagram

26. Example 2 Use Case Diagram
Make automated menu
selections
Expert Menu
System
Order food and drink
Cook
Notify customer that
food and drink are ready
Customer
Pay for food and drink
Payment
System

27. Refining a Preliminary Use Case
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?
Are there cases in which some “validation function” occurs during this use case?
Are there cases in which a supporting function (or actor) will fail to respond appropriately?
Can poor system performance result in unexpected or improper user actions?

28. Activity Diagrams
Supplements the use case by providing a graphical representation of the flow of interaction within a specific scenario
Uses flowchart-like symbols
Rounded rectangle - represent a specific system function/action
Arrow - represents the flow of control from one function/action to another
Diamond - represents a branching decision
Solid bar – represents the fork and join of parallel activities

30. Swimlane diagram
The UML swimlane diagram is a useful variation of the activity diagram and 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 (discussed later in this chapter) has 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.

32. Flow-Oriented Modeling
Represents how data objects are transformed at they move through the system
data flow diagram (DFD) – complement UML diagrams and provide additional insight into system requirements and flow
Considered by many to be an “old school” approach, but continues to provide a view of the system that is unique
Input –process-output view of the system
Data objects flow into the system- transformed by processing elements-resultant data objects flow out of the software
represented in hierarchical fashion

33. Data flow modeling is a core modeling activity in structured analysis
1st data model- level 0 DFD or context diagram
Represents the system as a whole
Subsequent data flow diagrams refine the context diagram, providing increasing detail with each subsequent level
The data flow diagram enables one to develop models of the information domain and functional domain

34. A few simple guidelines during the derivation of a data flow diagram:
the level 0 data flow diagram should depict the software/system as a single bubble
primary input and output should be carefully noted
Refinement should begin by isolating candidate processes, data objects, and data stores to be represented at the next level
all arrows and bubbles should be labeled with meaningful names
information flow continuity must be maintained from level to level
one bubble at a time should be refined.
There is a natural tendency to overcomplicate the data flow diagram. This occurs when you attempt to show too much detail too early or represent procedural aspects of the software in lieu of information flow.

35. Flow Modeling Notation
external entity
process
data flow
data store

36. External Entity A producer or consumer of data
Examples: a person, a device, a sensor
Another example: computer-based system
Data must always originate somewhere
and must always be sent to something

37. Process A data transformer (changes input to output)
Examples: compute taxes, determine area,
format report, display graph
Data must always be processed in some
way to achieve system function

38. Data Flow Data flows through a system, beginning
as input and transformed into output.
base
compute
triangle
area
area
height

39. Data Stores Data is often stored for later use. look-up sensor data
sensor #, type,
location, age
look-up
sensor
data
report required
type,
location, age
sensor number
sensor data

40. Level 0 DFD Example Context level DFD for Safe Home Security Function

41. Level 1 DFD for Safe Home Security Function

42. Level 2 DFD that refines the monitor
sensors process

43. Control Flow Modeling
Represents “events” and the processes that manage events
An “event” is a Boolean condition that can be ascertained by:
listing all sensors that are "read" by the software.
listing all interrupt conditions.
listing all "switches" that are actuated by an operator.
listing all data conditions.
recalling the noun/verb parse that was applied to the processing narrative, review all "control items" as possible CSPEC inputs/outputs.
Describe the behavior of the system by identifying its states, identify how each state is reached and define the transitions between states
Focus on possible omissions- a very common error in specifying control

44. Control Specification (CSPEC)
The CSPEC can be:
state diagram
(sequential spec)
state transition table
combinatorial spec
decision tables
activation tables

45. Data Flow and Control Flow
Data Flow Diagram
Depicts how input is transformed into output as data objects move through a system
Process Specification
Describes data flow processing at the lowest level of refinement in the data flow diagrams
Control Flow Diagram
Illustrates how events affect the behavior of a system through the use of state diagrams

46. State Diagram for Safe Home Security function

47. Process activation table for SafeHome
Security function

48. Object oriented Analysis
Design classes
User interface classes- abstractions necessary for HCI
Business domain classes- refinements
Process classes- low level business abstractions
Persistent classes- represent data stores
System classes- software management and control functions interacting with outside world

49. Four characteristics of classes
Complete and sufficient- encapsulation
Primitiveness- accomplishing one service completely
High cohesion- small, foccussed set of responsibility
Low coupling

50. 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 (some hierarchical) between the objects, and the collaborations that occur between the classes that are defined.
The elements of a class-based model include classes and objects, attributes, operations, class responsibility- collaborator (CRC) models, collaboration diagrams, and packages.

51. Identifying Analysis Classes
Perform a grammatical parse of the problem statement or use cases
Classes are determined by underlining each noun or noun clause
A class required to implement a solution is part of the solution space
A class necessary only to describe a solution is part of the problem space
A class should NOT have an imperative procedural name (i.e., a verb)
List the potential class names in a table and "classify" each class according to some taxonomy and class selection characteristics
A potential class should satisfy nearly all (or all) of the selection characteristics to be considered a legitimate problem domain class

52. Identifying Analysis Classes (continued)
Ways-General classifications for a potential class
External entity (e.g., another system, a device, a person)
Thing (e.g., report, screen display)
Occurrence or event (e.g., movement, completion)
Role (e.g., manager, engineer, salesperson)
Organizational unit (e.g., division, group, team)
Place (e.g., manufacturing floor, loading dock)
Structure (e.g., sensor, vehicle, computer)

53. Identifying Analysis Classes (continued)
Six class selection characteristics
Retained information
Information must be remembered about the system over time
Needed services
Set of operations that can change the attributes of a class
Multiple attributes
Whereas, a single attribute may denote an atomic variable rather than a class
Common attributes
A set of attributes apply to all instances of a class
Common operations
A set of operations apply to all instances of a class
Essential requirements
Entities that produce or consume information

54. Illustration

56. Defining Attributes of a Class
Attributes of a class are those nouns from the grammatical parse that reasonably belong to a class
Attributes hold the values that describe the current properties or state of a class
An attribute may also appear initially as a potential class that is later rejected because of the class selection criteria
In identifying attributes, the following question should be answered
What data items (composite and/or elementary) will fully define a specific class in the context of the problem at hand?
Usually an item is not an attribute if more than one of them is to be associated with a class

57. Illustration

58. Defining Operations of a Class
Operations define the behavior of an object
Four categories of operations
Operations that manipulate data in some way to change the state of an object (e.g., add, delete, modify)
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
An operation has knowledge about the state of a class and the nature of its associations
The action performed by an operation is based on the current values of the attributes of a class
Using a grammatical parse again, circle the verbs; then select the verbs that relate to the problem domain classes that were previously identified

59. Class diagram
for the system
class

60. Class diagram for floor plan

61. Class Responsibility Collaborator (CRC)
A CRC model is really a collection of standard index cards that represent classes. The cards are divided into three sections. Along the top of the card you write the name of the
class. In the body of the card you list the class responsibilities on the left and the collaborators on the right.
In reality, the CRC model may make use of actual or virtual index cards.
The intent is to develop an organized representation of classes.
Responsibilities are the attributes and operations that are relevant for the class.

62. A CRC model index card

63. Classes can be
Entity class/ model/ business classes (eg. Floor plan/sensors)
Boundary classes are used to create the interface (e.g., interactive screen or printed reports) that the user sees and interacts with as the software is used.
Controller classes manage a “unit of work” from start to finish. That is, controller classes can be designed to manage
the creation or update of entity objects,
the instantiation of boundary objects as they obtain information from entity objects,
complex communication between sets of objects,
validation of data communicated between objects or between the user and the application.

64. Responsibilities
System intelligence should be distributed across classes to best 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 related classes, when appropriate.

65. Association, Generalization
Represented by a solid line between two classes directed from the source class to the target class
Used for representing (i.e., pointing to) object types for attributes
May also be a part-of relationship (i.e., aggregation), which is represented by a diamond-arrow
Generalization
Portrays inheritance between a super class and a subclass
Is represented by a line with a triangle at the target end
Dependency
A dependency exists between two elements if changes to the definition of one element (i.e., the source or supplier) may cause changes to the other element (i.e., the client)
Examples
One class calls a method of another class
One class utilizes another class as a parameter of a method

66. Behavioral Modeling
The behavioral model indicates how software will respond to external events or stimuli.
To create the model, one should perform the following steps:
Evaluate all use cases to fully understand the sequence of interaction within the system
Identify events that drive 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 behavioral model to verify accuracy and consistency.

67. In the context of behavioral modeling, two different characterizations of states must be considered:
(1) the state of each class as the system performs its function and
(2) the state of the system as observed from the outside as the system performs its Function.
A passive state is simply the current status of all of an object’s attributes. For example, the passive state of the class would include the current position and orientation attributes of Player as well as other features of Player that are relevant to the game (e.g., an attribute that indicates magic wishes remaining).
The active state of an object indicates the current status of the object as it undergoes a continuing transformation or processing. The class Player might have the following active states: moving, at rest, injured, being cured; trapped, lost, and so forth. An event (sometimes called a trigger) must occur to force an object to make a transition from one active state to another.

68. State Diagram for Control Panel

69. Sequence diagram (partial) for the SafeHome security function

70. Building a State Diagram
A state is represented by a rounded rectangle
A transition (i.e., event) is represented by a labeled arrow leading from one state to another
Syntax: trigger-signature [guard]/activity
The active state of an object indicates the current overall status of the object as is goes through transformation or processing
A state name represents one of the possible active states of an object
The passive state of an object is the current value of all of an object's attributes
A guard in a transition may contain the checking of the passive state of an object