1. ANALYSIS MODELING

2. Analysis
bridges the gap between system level requirement engineering and software design
Term originally coined by Douglas Ross and popularized by DeMarco
If you don’t analyze problem, its highly likely that you will build a highly elegant software that solves the wrong problem

3. System Models

4. Analysis MODELS Functional Models Behavioral Models:
Software transforms information
To accomplish this, it must perform at least three generic functions
Input
Processing
Output
Behavioral Models:
Most softwares responds to events from outside world
This response characteristic forms the basis of the behavioral model

5. Analysis Models Process Specification Data object description
State-transition
Diagram
Data object description
Process Specification
Entity
Relationship
diagram
Data flow
diagram
Data
Dictionary
Control Specification

6. Data Flow Diagram (DFD) – It serves two purposes:
Data Dictionary – A repository that contains description of all data objects consumed or produced by the software
Entity Relationship Diagram (ERD) – depicts relationship between data objects
Data Flow Diagram (DFD) – It serves two purposes:
Provide an indication of how data is transformed
To depict the functions that transform the data flow
State Transition Diagram (STD) – It indicates how the system behaves as a consequence of external events

7. Product Specification: description of each function presented in DFD is contained in process specification (PSPEC)
Control Specification: Additional information about control aspects of software are contained in control specification

8. DATA MODEL

9. Data Model
An analysis method that models data objects and their relationships
Data modeling is a process by which
The data requirements within a given scope are grouped into objects called entities
Relationships between those entities are documented
A graphical representation called an entity-relationship diagram is produced.

10. Entity
A data entity is anything real or abstract about which we want to store data.
Entity types fall into five classes:
roles, events, locations, tangible things or concepts.
e.g. employee, payment, campus, book.
Specific examples of an entity are called instances.

11. Concepts
Data Objects
Attributes
Relationships
Cardinality and Modality

12. Data Modeling
Data objects – Any composite information that must be understood by the software
External entity
Thing
Occurrence
Role
Organizational unit
Place
Structure

13. ENTITY TYPES Strong Entity Weak Entity Associative Entity
Exist independently of other entity types
Weak Entity
Whose existence depends on some other entity type
The entity type on which the weak entity type depends is known as “identifying owner”
Associative Entity
described in “relationships”

14. Define the properties of a data object They can be used to
Attributes
Define the properties of a data object
They can be used to
Name an instance of the data object
Describe the instance
Make reference to another instance in another table

15. identifier
An attribute or combination of attributes that uniquely identifies individual instances of an entity type
Has properties of
Unique
Not null
Cannot change

16. Attribute Types Simple Attribute Composite attribute
Cannot be broken down e.g. vehicle_color
Composite attribute
Some attributes can be broken down into meaningful component parts E.g. Address

17. Attribute Types Single valued attribute Multivalued attributes
An attribute that take on more than one value for a given entity instance (e.g. skill)
Stored attribute
Derived attribute
Whose value can be calculated from other information

18. Relationships
It depicts the association between one or more data objects e.g: A bookstore displays books
Associative Entities: presence of one or more attributes on a relationship
Weak entities are identified through an “identifying relationship” with their owner entity

19. Basic Symbols Associative Entity Strong Entity Weak Entity Attribute
Relationship
Multivalued Attribute
Derived Attribute
Identifying Relationship

20. Cardinality Cardinality defines
It is the specification of the number of occurrences of one object that can be related to the number of occurrences of another object 
One-to-one
One-to-many
Many-to-many

21. Modality
Defines the need for the relationship to occur
Modality = Optional
Modality = Mandatory

22. Entity Relationship Diagram(ERD)–Notation
One common form:
(0, m)
object
relationship
object 1 2
(1, 1)
attribute
Another common form:
object
relationship
object 1 2
(0, m)
(1, 1)

23. Example: ERD
places
Member
Order
setup_for
Product

24. The ERD: An Example request for service Customer places (1,1) (1,m)
standard
task table
(1,n)
work
order
generates
(1,1)
(1,1)
(1,1)
work
tasks
(1,w)
selected
from
consists of
(1,w)
(1,i)
materials
lists

25. Functional Modeling Every computer-based system is an
information transform ....
computer
based
system
input
output

26. Data Flow Diagram
Data flow diagramming shows business processes and the data that flows between them
Data flow diagrams illustrate how data is processed by a system in terms of inputs and outputs.
The Data Flow Diagram shows the flow of data or information.

27. Four Basic Elements A dataflow diagram consists of External Entities
Processes
Data Flow
Data Stores

28. DFD Elements

29. DFD Shapes from Visio

30. External Entities
Represent people or organizations outside of the system being studied
Shows the initial source and final recipient of data and information
Should be named with a noun, describing that entity

31. External Entities External entities may be
A person, such as CUSTOMER or STUDENT
A company or organization, such as BANK or SUPPLIER
Another department within the company, such as ORDER FULFILLMENT
Another system or subsystem, such as the INVENTORY CONTROL SYSTEM

32. Processes Represent either: A whole system A subsystem
Work being done, an activity
Names should be in the form verb-adjective-noun

33. Data Stores Name with a noun, describing the data
Data stores are usually given a unique reference number, such as D1, D2, D3
Include any data stored, such as:
A computer file or database
A transaction file
A set of tables
A manual file of records
sensor #
sensor #, type,
location, age
look-up
sensor
data
report required
type,
location, age
sensor number
sensor data

34. Data Flow
Shows the data about a person, place, or thing that moves through the system
Names should be a noun that describes the data moving through the system
Arrowhead indicates the flow direction
Use double headed-arrows only when a process is reading data and updating the data on the same table or file
compute
triangle
area
base
area
height

35. Developing Data Flow Diagrams
Use the following guidelines:
Create the context level diagram, including all external entities and the major data flow to or from them
Create Diagram 1 by analyzing the major activities within the context process
Include the external entities and major data stores
Create a child diagram for each complex process on Diagram 1

36. Creating Data Flow Diagrams
Detailed data flow diagrams may be developed by
Making a list of business activities
Analyzing what happens to an input data flow from an external entity
Analyzing what is necessary to create an output data flow to an external entity
Examining the data flow to or from a data store
Analyzing a well-defined process for data requirements and the nature of the information produced
Unclear areas of a data flow diagram should be noted and investigated

37. Data Flow Diagram Levels
Data flow diagrams are built in layers
The top level is the Context level
Each process may explode to a lower level
The lower level diagram number is the same as the parent process number
Processes that do not create a child diagram are called primitive

38. Context Level Data Flow Diagram
The level 0 DFD should depict the software/system as a single bubble
Contains only one process, representing the entire system
The process is given the number zero
All external entities are shown on the context diagram as well as major data flow to and from them
The diagram does not contain any data stores

39. Several Common Modeling Rules
All processes must have at least one data flow in and one data flow out.
All processes should modify the incoming data, producing new forms of outgoing data.
Each data store must be involved with at least one data flow
Each external entity must be involved with at least one data flow
A data flow must be attached to at least one process.

40. Key Definitions
Decomposition is the process of modeling the system and its components in increasing levels of detail
Balancing involves ensuring that information presented at one level of a DFD is accurately represented in the next level DFD.

41. A data flow diagram

42. Context Level DFD

43. Level 1 DFD

45. Behavioral Model
events
behavior
Outside
world
Application

46. Behavioral Modeling make a list of the different states of a system
(How does the system behave?)
indicate how the system makes a transition from one state to another (How does the system change state?)
indicate event
indicate action
draw a state transition diagram

47. State Transition Diagram (STD)
It highlights the time-dependent behavior of a system.
It shows ‘what’ happens ‘when’
Major components
States
Transitions between states
Useful for describing behavior of
real-time systems, interactive systems

48. The States of a System
State — a set of observable circum-stances that characterizes the behavior of a system at a given time
State Transition — the movement from one state to another
Event — an occurrence that causes the system to exhibit some predictable form of behavior
Action — process that occurs as a consequence of making a transition

49. Example: State Transition Diagram
RButton-down
/ display PopUp Menu
Idle
Menu visible
RButton-up
/ erase PopUp Menu
Cursor-moved
/ highlight Menu item

50. State Transition Diagram Notation
event causing transition
action that occurs
new state

51. Example

52. The Control Specification (CSPEC)
Describes the behavior of a system by identifying its states; identify how each state is reached and define the transition between states
focuses on possible omissions ... a very common error in specifying control, e.g., ask: "Is there any other way I can get to this state or exit from it?"
The CSPEC contains
A State Transition Diagram
A Process Activation Table

53. The Process Specification (PSPEC)
It is used to describe all the flow model processes that appear at the final level of refinement
PSPEC
narrative
pseudocode (PDL)
equations
tables
diagrams and/or charts
bubble

54. Creating Mini-Specs
Software
Specification

55. The Data Dictionary (DD)
The data dictionary is an organized listing of all data elements that are relevant to the system
with precise rigorous definitions so that both the user and the system analyst will have a common understanding of inputs, outputs, components of stores and [even] intermediate calculations

56. Information contained in DD
Name:
the primary name of the composite data item
Aliases:
other names for the data item
Where used:
data transforms (processes) that use the
composite data item
How used:
the role of the data item (input, output,
temporary storage, etc.)
Content
Description:
a notation for representing content (presented
on next slide)
Supplementary
information:
specific information about data types

57. Data Construct
Notation
Meaning =
Is composed of
Sequence +
And
Selection
[|]
Either-or
Repetition
{}n
n repetitions of ()
Optional data
*…*
Delimits comments

58. Name: Telephone number Aliases: none
Where used/how used: assess against set-up (output)
dial phone (input)
Description:
telephone number = [local number | long distance number]
local number = prefix + access number
long distance number = 1 + area code + local number
area code = [800 | 888 | 561]
prefix = *a three digit number that never starts with 0 or 1*
access number = *any four number string *

59. The Data Dictionary
The data dictionary is an organized listing of all data elements pertinent to the system with precise rigorous definitions so that both user and SA will have common understanding of all data elements.
It describes:
meaning and composition of data flows,
data stores
relevant values and units of elementary data elements
details of relationships between stores that are highlighted in a ERD

60. Data Dictionary Notation
Example: customer-name = title + first-name + (middle-name) + last-name title = [Mr. | Miss | Ms. | Mrs.| Dr. | Prof. ] first-name = {legal-character} order = customer-name + shipping-addr + {item}

61. Credits:
Chapter 8 : Software Engineering - A practitioner’ s Approach by Roger S. Pressman (6th Edition)
Chapter 3: A Modern Database Management by Fred R. mcFadden, Jeffrey A. Hoffer, Mary B. Prescott (5th Edition)
Lecture Slides, Dr. Fakhar Lodhi VU CS504