CIS 302 Introduction to Systems Analysis and Design

1
CIS 302 Introduction to Systems Analysis and
Design

• Structuring System Requirements
• Data Modeling

7.1
2
Learning Objectives

• Understand the logical modeling of processes
  through studying data flow diagrams
• How to draw data flow diagrams using rules and
  guidelines
• How to decompose data flow diagrams into
  lower-level diagrams
• Balancing of data flow diagrams

7.2
3
Learning Objectives

• Discuss the use of data flow diagrams as analysis
  tools
• Discuss Process Modeling for Internet
  Applications
• Represent processing logic using structured
  English and decision tables

7.3
4
Process Modeling

• Graphically represent the processes that capture,
  manipulate, store and distribute data between a
  system and its environment and among system
  components
• Data flow diagrams (DFD)
• Graphically illustrate movement of data between
  external entities and the processes and data
  stores within a system

7.4
5
Process Modeling

• Modeling a systems process
• Utilize information gathered during requirements
  determination
• Structure of the data is also modeled in addition
  to the processes
• Deliverables and Outcomes
• Set of coherent, interrelated data flow diagrams

7.5
6
Process Modeling

• Deliverables and outcomes (continued)
• Context data flow diagram (DFD)
• Scope of system
• DFDs of current system
• Enables analysts to understand current system
• DFDs of new logical system
• Technology independent
• Show data flows, structure and functional
  requirements of new system

7.6
7
Process Modeling

• Deliverables and outcomes (continued)
• Project dictionary and CASE repository
• Data flow diagramming mechanics
• Four symbols are used
• Square, Rounded Rectangle, Open-ended Rectangle,
  Flow arrow
• Developed by DeMarco and Yourdan

7.7
8
Data Flow Diagramming Mechanics

• Data Flow
• Depicts data that are in motion and moving as a
  unit from one place to another in the system.
• Drawn as an arrow
• Select a meaningful name to represent the data

7.8
9
Data Flow Diagramming Mechanics

• Data Store
• Depicts data at rest
• May represent data in
• File folder
• Computer-based file
• Notebook
• Drawn as two horizontal parallel lines
• The name of the store as well as the number are
  recorded in between lines

10
Data Flow Diagramming Mechanics

• Process
• Depicts work or action performed on data so that
  they are transformed, stored or distributed
• Drawn as a circle
• Number of process as well as name are recorded

7.10
11
Data Flow Diagramming Mechanics

• Source/Sink
• Depicts the origin and/or destination of the data
• Sometimes referred to as an external entity
• Drawn as a square symbol
• Name states what the external agent is
• Because they are external, many characteristics
  are not of interest to us

7.11
12
Data Flow Diagramming Definitions

• Context Diagram
• A data flow diagram (DFD) of the scope of an
  organizational system that shows the system
  boundaries, external entities that interact with
  the system and the major information flows
  between the entities and the system
• Level-O Diagram
• A data flow diagrams (DFD) that represents a
  systems major processes, data flows and data
  stores at a higher level

7.12
13
Developing DFDs An Example

• Context Diagram contains no data stores
• Next step is to expand the context diagram to
  show the breakdown of processes

7.13
14
Data Flow Diagramming Rules

• Basic rules that apply to all DFDs
• Inputs to a process are always different than
  outputs
• Objects always have a unique name
• In order to keep the diagram uncluttered, you can
  repeat data stores and data flows on a diagram

7.14
15
Data Flow Diagramming Rules

• Process
• No process can have only outputs (a miracle)
• No process can have only inputs (black hole)
• A process has a verb phrase label

• Data Store
• Data cannot be moved from one store to another.
• Data cannot move from an outside source to a data
  store
• Data cannot move directly from a data store to a
  data sink
• Data store has a noun phrase label

7.15
16
Data Flow Diagramming Rules

• Source/Sink
• Data cannot move directly from a source to a sink
• A source/sink has a noun phrase label

• Data Flow
• A data flow has only one direction of flow
  between symbols.
• A fork means that exactly the same data go from a
  common location to two or more processes, data
  stores or sources/sinks

7.16
17
Data Flow Diagramming Rules

• Data Flow (Continued)
• A join means that exactly the same data come from
  any two or more different processes, data stores
  or sources/sinks to a common location
• A data flow cannot go directly back to the same
  process it leaves
• A data flow to a data store means update
• A data flow from a data store means retrieve or
  use
• A data flow has a noun phrase label

7.17
18
Decomposition of DFDs

• Functional decomposition
• Act of going from one single system to many
  component processes
• Repetitive procedure
• Lowest level is called a primitive DFD
• Level-N Diagrams
• A DFD that is the result of n nested
  decompositions of a series of subprocesses from a
  process on a level-0 diagram

7.18
19
Balancing DFDs

• When decomposing a DFD, you must conserve inputs
  to and outputs from a process at the next level
  of decomposition
• This is called balancing

7.19
20
Guidelines for Drawing DFDs

• Completeness
• DFD must include all components necessary for
  system
• Each component must be fully described in the
  project dictionary or CASE repository
• Consistency
• The extent to which information contained on one
  level of a set of nested DFDs is also included on
  other levels

7.20
21
Guidelines for Drawing DFDs

• Timing
• Time is not represented well on DFDs
• Best to draw DFDs as if the system has never
  started and will never stop.
• Iterative Development
• Analyst should expect to redraw diagram several
  times before reaching the closest approximation
  to the system being modeled

7.21
22
Guidelines for Drawing DFDs

• Primitive DFDs
• Lowest logical level of decomposition
• Decision has to be made when to stop decomposition

7.22
23
Guidelines for Drawing DFDs

• Rules for stopping decomposition
• When each process has been reduced to a single
  decision, calculation or database operation
• When each data store represents data about a
  single entity
• When the system user does not care to see any
  more detail

7.23
24
Guidelines for Drawing DFDs

• Rules for stopping decomposition (continued)
• When every data flow does not need to be split
  further to show that data are handled in various
  ways
• When you believe that you have shown each
  business form or transaction, on-line display and
  report as a single data flow
• When you believe that there is a separate process
  for each choice on all lowest-level menu options

7.24
25
Using DFDs as Analysis Tools

• Gap Analysis
• The process of discovering discrepancies between
  two or more sets of data flow diagrams or
  discrepancies within a single DFD
• Inefficiencies in a system can often be
  identified through DFDs

7.25
26
Logic Modeling

• Data flow diagrams do not show the logic inside
  the processes
• Logic modeling involves representing internal
  structure and functionality of processes depicted
  on a DFD
• Two methods
• Structured English
• Decision Tables

7.26
27
Modeling Logic with Structured English

• Modified form of English used to specify the
  logic of information processes
• Uses a subset of English
• Action verbs
• Noun phrases
• No adjectives or adverbs
• No specific standards

7.27
28
Modeling Logic with Structured English

• Similar to programming language
• If conditions
• Case statements

7.28
29
Modeling Logic with Decision Tables

• A matrix representation of the logic of a
  decision
• Specifies the possible conditions and the
  resulting actions
• Best used for complicated decision logic

7.29
30
Modeling Logic withDecision Tables

• Consists of three parts
• Condition stubs
• Lists condition relevant to decision
• Action stubs
• Actions that result for a given set of conditions
• Rules
• Specify which actions are to be followed for a
  given set of conditions

7.30
31
Modeling Logic with Decision Tables

• Indifferent Condition
• Condition whose value does not affect which
  action is taken for two or more rules
• Standard procedure for creating decision tables
• Name the condition and values each condition can
  assume
• Name all possible actions that can occur
• List all rules
• Define the actions for each rule
• Simplify the table

7.31
32
Summary

• Data flow diagrams (DFD)
• Symbols
• Rules for creating
• Decomposition
• Balancing
• DFDs for Analysis
• DFDs for Business Process Reengineering (BPR)

7.32
33
Summary

• Logic Modeling
• Structured English
• Decision Tables

7.33
34
Conceptual Data Modeling

• The ER Model

7.34
35
Learning Objectives

• Define key data-modeling terms
• Conceptual data model
• Entity-Relationship (E-R) diagram
• Entity type
• Entity instance
• Attribute
• Candidate key
• Multivalued attributes
• Relationship
• Degree
• Cardinality
• Associative entity

7.35
36
Learning Objectives

• Ask the right kinds of questions to determine
  data requirements for an IS
• Learn to draw Entity-Relationship Diagrams (ERD)
• Review the role of conceptual data modeling in
  overall design and analysis of an information
  system
• Discuss relationships and associative entities
• Discuss relationship between data modeling and
  process modeling

7.36
37
Conceptual Data Modeling

• Representation of organizational data
• Purpose is to show rules about the meaning and
  interrelationships among data
• Entity-Relationship (E-R) diagrams are commonly
  used to show how data are organized
• Main goal of conceptual data modeling is to
  create accurate E-R diagrams
• Methods such as interviewing, questionnaires and
  JAD are used to collect information
• Consistency must be maintained between process
  flow, decision logic and data modeling
  descriptions

7.37
38
Process of Conceptual Data Modeling

• First step is to develop a data model for the
  system being replaced
• Next, a new conceptual data model is built that
  includes all the requirements of the new system
• In the design stage, the conceptual data model is
  translated into a physical design
• Project repository links all design and data
  modeling steps performed during SDLC

7.38
39
Deliverables and Outcome

• Primary deliverable is the entity-relationship
  diagram
• There may be as many as 4 E-R diagrams produced
  and analyzed during conceptual data modeling
• Covers just data needed in the projects
  application
• E-R diagram for system being replaced
• An E-R diagram for the whole database from which
  the new applications data are extracted
• An E-R diagram for the whole database from which
  data for the application system being replaced
  are drawn

7.39
40
Deliverables and Outcome

• Second deliverable is a set of entries about data
  objects to be stored in repository or project
  dictionary
• Repository links data, process and logic models
  of an information system
• Data elements that are included in the DFD must
  appear in the data model and conversely
• Each data store in a process model must relate to
  business objects represented in the data model

7.40
41
Gathering Information for Conceptual Data Modeling

• Two perspectives
• Top-down
• Data model is derived from an intimate
  understanding of the business
• Bottom-up
• Data model is derived by reviewing specifications
  and business documents

7.41
42
Introduction to Entity-Relationship (E-R) Modeling

• Notation uses three main constructs
• Data entities
• Relationships
• Attributes
• Entity-Relationship (E-R) Diagram
• A detailed, logical and graphical representation
  of the entities, associations and data elements
  for an organization or business

7.42
43
Entity-Relationship (E-R) ModelingKey Terms

• Entity
• A person, place, object, event or concept in the
  user environment about which the organization
  wishes to maintain data
• Represented by a rectangle in E-R diagrams
• Entity Type
• A collection of entities that share common
  properties or characteristic
• Attribute
• A named property or characteristic of an entity
  that is of interest to an organization

7.43
44
Entity-Relationship (E-R) ModelingKey Terms

• Candidate keys and identifiers
• Each entity type must have an attribute or set of
  attributes that distinguishes one instance from
  other instances of the same type
• Candidate key
• Attribute (or combination of attributes) that
  uniquely identifies each instance of an entity
  type

7.44
45
Entity-Relationship (E-R) ModelingKey Terms

• Identifier
• A candidate key that has been selected as the
  unique identifying characteristic for an entity
  type
• Selection rules for an identifier
• Choose a candidate key that will not change its
  value
• Choose a candidate key that will never be null
• Avoid using intelligent keys
• Consider substituting single value surrogate keys
  for large composite keys

7.45
46
Entity-Relationship (E-R) ModelingKey Terms

• Multivalued Attribute
• An attribute that may take on more than one value
  for each entity instance
• Represented on E-R Diagram in two ways
• double-lined ellipse
• weak entity

7.46
47
Entity-Relationship (E-R) ModelingKey Terms

• Relationship
• An association between the instances of one or
  more entity types that is of interest to the
  organization
• Association indicates that an event has occurred
  or that there is a natural link between entity
  types
• Relationships are always labeled with verb phrases

7.47
48
Conceptual Data Modeling and the E-R Diagram

• Goal
• Capture as much of the meaning of the data as
  possible
• Result
• A better design that is easier to maintain

7.48
49
Degree of Relationship

• Degree
• Number of entity types that participate in a
  relationship
• Three cases
• Unary
• A relationship between the instances of one
  entity type
• Binary
• A relationship between the instances of two
  entity types
• Ternary
• A simultaneous relationship among the instances
  of three entity types
• Not the same as three binary relationships

7.49
50
Cardinality

• The number of instances of entity B that can be
  associated with each instance of entity A
• Minimum Cardinality
• The minimum number of instances of entity B that
  may be associated with each instance of entity A
• Maximum Cardinality
• The maximum number of instances of entity B that
  may be associated with each instance of entity A

7.50
51
Associative Entity

• An entity type that associates the instances of
  one or more entity types and contains attributes
  that are peculiar to the relationship between
  those entity instances

7.51
52
Internet Development Conceptual Data Model

• Conceptual data modeling for Internet
  applications is no different than the processed
  followed for other types of applications
• Pine Valley Furniture WebStore
• Four entity types defined
• Customer
• Inventory
• Order
• Shopping cart

7.52
53
Summary

• Process of conceptual data modeling
• Deliverables
• Gathering information
• Entity-Relationship Modeling
• Entities
• Attributes
• Candidate keys and identifiers
• Multivalued attributes
• Degree of relationship

7.53
54
Summary

• Cardinality
• Associative entities
• Conceptual data modeling and Internet development

7.54