Khawab ki Tabeer

1
INTRODUCTION TO SOFTWARE DEVELOPMENT
2
STRUCTURED ANALYSIS

• The Elements of Analysis Model
• Functional Modeling and Information Flow Data
  Flow Diagrams
• Data Modeling - Entity / Relationship Diagrams
• Behavioral Modeling - State Transition Diagram
• The Data Dictionary
• The Control Specification
• The Process Specification

3
Analysis Modeling

• Analysis Model
• It is a set of models and is the first technical
  representation of a system or software.
• Analysis modeling uses a combination of text and
  diagrammatic forms to depict requirements for
  data, function and behavior which is easy to
  understand and more important, straightforward to
  review for correctness, completeness and
  consistency.
• There are two methods for analysis modeling
  Structured Analysis and Object Oriented
  Analysis.

4
STRUCTURED ANALYSIS

• Structured Analysis
• It is a model building activity in which data,
  functional and behavioral models are created.
• It was first introduced in 1974-78, due to the
  need of graphical representation of data and the
  processes that transformed it.
• During the research on Structured Analysis, the
  methods only focused on information system
  applications did not provide sufficient
  information of the control and behavioral aspects
  of real-time engineering problems.

5

• Object Oriented Analysis
• In this analysis classes (objects) are defined
  which represent problem to be solved, the manner
  in which the classes relate to and interact with
  one another, the inner workings of objects and
  the communication mechanisms that allow them to
  work together.

6
STRUCTURED ANALYSIS

• There are three primary objectives of Analysis
  model
• (1) To describe what the customer requires,
• (2) To establish a basis for the creation of a
  software design,
• (3) To define a set of requirements that can be
  validated once the software is built.

7
ELEMENTS OF ANALYSIS MODEL
Entity Relationship Diagram
Process Specification (PSPEC)
Data Dictionary
Data Flow Diagram
Data Object Description
State-transition Diagram
Control specification
8
ELEMENTS OF ANALYSIS MODEL

• Data Flow Diagram (DFD)
• It is used to
• (1) Provide an indication of how data are
  transformed as they move through the system.
• (2) Show the functions that transform the data
  flow.
• It also provides additional information that is
  used during the analysis of the information
  domain and serves as a basis for the modeling of
  a function.
• Description of each function that is presented in
  DFD is contained in Process Specification (PSPEC).

9
ELEMENTS OF ANALYSIS MODEL

• Data Dictionary
• It lies at the core of the model, it is the
  repository that contains description of all the
  data objects consumed or produced by the
  software.
• Entity Relationship Diagram (ERD)
• It shows the relationships between the data
  objects, it is a notation that is used to conduct
  the data modeling activity.
• Attributes of each object noted in ERD are
  described in a Data Object Description.

10
ELEMENTS OF ANALYSIS MODEL

• State Transition Diagram (STD)
• It represents the various modes (states) of
  behavior of the system and the manner in which
  transitions are made from state to state and is
  the basis for behavioral modeling.
• Additional information about the control aspects
  of the software is contained in the Control
  Specification (CSPEC).

11
DATA FLOW DIAGRAM (DFD)

• It is a graphical representation which shows
  information flow and the transforms applied as
  data move from input to output.
• It may be used to represent a system or software
  .
• It may be partitioned into levels that represent
  increasing information flow and functional
  detail.
• Therefore, DFD provides a mechanism for
  functional modeling as well as information flow
  modeling.

12
DATA FLOW DIAGRAM (DFD)

• Level 0 DFD called Fundamental system model or
  context model, represents entire software element
  as a single bubble with input and output data
  indicated by incoming and outgoing arrows.
• Level 0 is partitioned to reveal more detail by
  representing additional processes and information
  flow paths .
• Level 1 DFD may contain five or six bubbles with
  interconnected arrows.

13
DATA FLOW DIAGRAM (DFD)

• Each of the processes represented at level 1 is a
  sub - function of the overall system shown in the
  context model.
• Each of the bubble may be refined or layered to
  show more detail.

14
DATA FLOW DIAGRAM (DFD)
B
LEVEL 0
F
A
LEVEL 1
f2
X
V
f6
Z2
A
Z
Z1
B
f1
f4
W
f7
f5
Y
f3
Z3
LEVEL 2
X
X1
f41
f43
X2
Z
f45
Y
f42
f44
Y2
Y1
15
DATA FLOW DIAGRAM (DFD)

• In the figure, F model is refined into transforms
  f1 to f7, Information flow continuity must be
  maintained means input and output must remain the
  same during each refinement.
• The processing details implied by a bubble within
  a DFD are specified in Process Specification
  (PSPEC).
• It describes input to a function, the algorithm
  applied to transform the input and the output
  produced.

16
DATA FLOW DIAGRAM (DFD)

• It also indicates restrictions and limitations
  imposed on the process, performance
  characteristics, and design constraints which may
  affect the way in which process will be
  implemented.

17
CREATING A DATA FLOW MODEL

• The DFD enables the software engineer to develop
  models of the information domain and function
  domain at the same time.
• Functional decomposition is easier as the DFD is
  refined into levels of detail.
• Following are some guidelines for the derivation
  of a DFD
• (1) The level 0 DFD should show the software /
  system as a single bubble.

18
CREATING A DATA FLOW MODEL

• (2) Primary input and output should be noted
  carefully.
• (3) Refinement should begin by isolating
  candidate processes, data objects, and stores to
  be represented at the next level.
• (4) All arrows and bubbles should be labeled
  with meaningful names.
• (5) Information flow continuity should be
  maintained from level to level.
• (6) One bubble at a time should be refined.

19
CREATING A DATA FLOW MODEL

• Example SafeHome Software
• A level 0 DFD for the system is shown, primary
  external entities produce information for use by
  the system and consume information generated by
  the system.
• The labeled arrows represent data objects

20
CREATING A DATA FLOW MODEL
Control Panel display
Control Panel
User Commands and Data
Display information
Alarm Type
Safe Home Software
Alarm
Telephone number tones
Sensor status
Telephone Line
Sensors
Context level DFD for Safe Home
21
CREATING A DATA FLOW MODEL

• In the given figure, user commands and data
  encompasses all configuration commands, all
  activation/deactivation commands, all
  miscellaneous interactions and all data that are
  entered to qualify or expand a command.

22
CREATING A DATA FLOW MODEL

• Level 0 DFD is expanded to Level 1 DFD, firstly
  developer has to create a grammatical parse to
  do so, that is a narration which describes the
  context level model.
• All the verbs are SafeHome processes (represented
  as bubbles), all nouns are either external
  entities (boxes) or data or control objects
  (arrows) or data stores (double lines).
• By performing a grammatical parse one can
  generate useful information about how to proceed
  with the refinement to the next level.

23
CREATING A DATA FLOW MODEL

• Information flow continuity should be maintained
  between all the levels. The process monitor
  sensors is refined into a Level 2 DFD.
• The refinement of DFDs continues until each
  bubble performs a simple function (easily
  implemented as a program component).

24
CREATING A DATA FLOW MODEL
Control Panel
Configure system
Configuration data
User Commands and Data
Configure request
Configuration information
Configuration data
Interact with user
Configuration data
Start stop
Activate/ deactivate system
Password
A/D msg
Display messages and status
Control Panel display
Display information
Process password
Valid ID msg
Sensor information
Alarm
Alarm Type
Monitor sensors
Sensor status
Sensors
Telephone number tones
Telephone Line
Level 1 DFD for Safe Home
25
CREATING A DATA FLOW MODEL
Level 2 DFD that refines the monitor sensors
process
Sensor information
Format for display
Alarm Type
Configuration information
Generate alarm signal
Sensor ID, type location
Configuration data
Alarm data
Access against setup
Sensor ID, type
Telephone number
Read sensors
Dial phone
Sensor status
Telephone number tones
26
DATA MODELING

• Entity Relationship Diagram (ERD) is used to
  enables the developer to identify data objects
  and their relationships using a graphical
  notation.
• ERD defines all data that are entered, stored,
  transformed, and produced within an application.

27
DATA MODELING

• The data model consists of three types of
  information the data object, the attributes
  (describe the object), and the relationships
  (connects data objects to one another).

28
DATA MODELING

• Data Objects
• It is a representation of any composite
  information, something that has a number of
  different properties.
• It can be an external entity, a thing, an
  occurrence or event, a role, an organizational
  unit, a place, or a structure.
• The Data object description incorporates data
  object and all of its attributes.
• The data object can be represented as a table
  (headings are called attributes and body shows
  instances).

29
DATA MODELING

• Attributes
• Define the properties or characteristics of a
  data object. They can be used to
• (1) Name an instance of the data object
• (2) To describe the instance
• (3) Make reference to another instance in
  another table.
• One or more attributes must be defined as an
  identifier, which will be a key for finding an
  instance of the data object.

30
DATA MODELING

• Relationships
• Data objects are connected to one another in
  different ways, which is established when the two
  objects are related.
• One can define a set of object/relationship pairs
  that define the relevant relationships which are
  bi-directional as well.

31
DATA MODELING
Data Objects

Naming
Identifier
Descriptive
Referential
Make Model ID Body type Color Owner
Lexus LS400 AB123 Sedan White RSP
Chevy Corvette X456 Sports Red CCD
BMW 750il XZ765 Coupe White IJL
Instance
32
DATA MODELING
Relationships

Orders
Displays
Book
Bookstore
Stocks
Sells
Returns
33
DATA MODELING

• Cardinality
• It is the specification of the number of
  occurrences of one object that can be related to
  the number of occurrences of another object.
• It is expressed as one or many, which have
  different combinations as
• (1) One-to-one (11)
• (2) One-to-many (1N)
• (3) Many-to-many (MN)

34
DATA MODELING

• Modality
• It provides an indication of whether or not a
  particular data object must participate in the
  relationship.
• It is 0 if there is no need of relationship to
  occur (relationship is optional) and it is 1 if
  occurrence is mandatory.

35
DATA MODELING
CARDINALITY MODALITY
Cardinality Implies that there may be many
repair action(s)
Cardinality Implies that a single customer
awaits repair action(s)
is provided with
Customer
Repair action
Modality Mandatory, Implies that in order to
have a repair action(s) we must have a customer
Modality Optional, Implies that there may be a
situation in which a repair action is not
necessary
36
ENTITY/RELATIONSHIP DIAGRAM

• It is used to represent graphically the object /
  relationship pairs.
• Originally proposed in 1977 for the design of
  relational database systems.
• The primary components of ERD are data objects,
  attributes, relationships and various type
  indicators.
• Its primary purpose is to represent data objects
  and their relationships.
• Data objects are represented by a labeled
  rectangle and relationships are indicated with a
  labeled line connecting objects.

37
CREATING AN ENTITY/RELATIONSHIP
DIAGRAM

• The ERD enables a developer to fully specify the
  data objects that are input and output from a
  system, the attributes and relationships of these
  objects.
• Following are the steps required to build an ERD
• (1) During requirements elicitation, customers
  provide a list of things that is evolved into
  list of input and output data objects as well as
  external entities.
• (2) Taking the objects one at a time, the
  analyst and customer define whether or not a
  connection exists between the data objects.

38
CREATING AN ENTITY/RELATIONSHIP
DIAGRAM

• (3) If connection exists one or more object /
  relationship pairs are created.
• (4) For each object/relationship pair,
  cardinality and modality are explored.
• (5) Step 2 through 4 are continued iteratively
  until all object/ relationships have been
  defined.
• (6) The attributes of each object are defined.
• (7) An entity relationship diagram is formalized
  and reviewed.
• (8) Step 1 through 7 are repeated until data
  modeling is completed.

39
CREATING AN ENTITY/RELATIONSHIP
DIAGRAM

• Referring to the SafeHome Software, all the data
  objects are defined, their connections are
  explored, their object/relation- ship pairs are
  analyzed to determine cardinality and modality.

40
CREATING AN ENTITY/RELATIONSHIP
DIAGRAM
Homeowner
Sensor
Control panel
Security system
Monitoring services
Establishing Connections
41
CREATING AN ENTITY/RELATIONSHIP
DIAGRAM
Monitors
Enables/Disables
Security system
Sensor
Tests
Programs
Developing relationships and cardinality/modality
42
BEHAVIORAL MODELING STATE TRANSITION
DIAGRAM

• Behavioral modeling is an operational principle
  for all requirements analysis methods, STD is
  used for its notation.
• The STD represents the behavior of the system
  through its states (any observable mode of
  behavior) and events that cause the system to
  change state.
• STD indicates the actions which are taken as a
  consequence of a particular event and it also
  indicates how the system moves from state to
  state.

43
BEHAVIORAL MODELING STATE TRANSITION
DIAGRAM

• States for a monitoring and control system for
  pressure vessels might be of the form monitoring
  state, alarm state, pressure release state, and
  so on.
• A simplified STD for the photocopier is shown.
• The rectangles represent system states and the
  arrows represent transition between states.
• Each arrow is labeled with a ruled expression .
• The top value indicates the event(s) that cause
  the transition to occur.

44
BEHAVIORAL MODELING STATE TRANSITION
DIAGRAM

• The bottom value indicates the action that occurs
  as a consequence of events.
• When the paper tray is full and start button is
  pressed, the system moves from the reading
  commands state to making copies state.
• States do not necessarily corresponds to
  processes on a one-to-one basis.

45
BEHAVIORAL MODELING STATE TRANSITION
DIAGRAM
Full and Start
Idle
Invoke manage-copying
Invoke read-op-input
Reading Commands
Copies done
Full
Invoke read-op-input
Invoke read-op-input
Reloading Paper
Making Copies
Empty
Invoke reload paper
Jammed
Invoke perform problem diagnosis
Not jammed
Invoke read-op-input
Diagnosing Problem
46
CREATING A STATE TRANSITION DIAGRAM
Start/stop switch
Invoke monitor and control system
Reading user input
Time out
Invoke interact with user
Sensor event
Invoke monitor and control system
Monitoring system status
Acting on a sensor event
Sensor event
Invoke display messages status
Sensor event
Sensor event
Invoke display messages status
Invoke monitor and control system
Displaying user feed back
Blink flag
Display action status
Invoke interact with user
Invoke display messages status
47
THE DATA DICTIONARY

• Data dictionary is an organized listing of all
  data elements that are relevant to the system so
  that both user and system analyst will have a
  common understanding of inputs, outputs,
  components of stores and intermediate
  calculations.
• The format of data dictionary varies from tool to
  tool, most contain the information as Name,
  Alias, Where-used/how-used, Content description,
  and supplementary information.
• When a data object or control item name and its
  aliases are entered into the data dictionary, the
  CASE tool supporting the dictionary posts a
  warning to indicate duplicate names.

48
THE DATA DICTIONARY

• Where-used/how-used information is recorded
  automatically from the flow model, the CASE tool
  scans DFDs and CFDs to determine which processes
  use the data or control information and how it is
  used.
• For large computer-based systems, the data
  dictionary grows rapidly in size and complexity.
• It is difficult to maintain a dictionary
  manually, for this reason CASE tools should be
  used.

49
THE CONTROL SPECIFICATION

• It represents the behavior of the system in two
  different ways.
• It contains a state transition diagram (a
  sequential specification of behavior) and a
  program activation table (a combinatorial
  specification of behavior).
• A STD for the level 1 CFD model for SafeHome is
  shown, the labeled transition arrows indicate how
  the system responds to events as it traverses the
  four states defined at this level.

50
THE CONTROL SPECIFICATION

• A somewhat different mode of behavioral
  representation is the process activation table
  (PAT) which represents information contained in
  the STD in the context of processes, not states.
  

51
THE PROCESS SPECIFICATION

• PSPEC is used to describe all flow model
  processes that appear at the final level of
  refinement.
• The content of PSPEC can include narrative text,
  a program design language (PDL) description of
  the process algorithm, mathematical equations,
  tables, diagrams, or charts.
• Provision of PSPEC with each will help in the
  creation of Software requirements Specification.
• It will also guide in the designing of the
  software component that will implement the
  process.