Modern Systems Analysis and Design Sixth Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich

1
Modern Systems Analysisand DesignSixth
Edition Jeffrey A. Hoffer Joey F.
GeorgeJoseph S. Valacich

• Chapter 7
• Analysis Process Modeling Logic Modeling

2
Models Logical and Physical
A model is a representation of reality. Just as a
picture is worth a thousand words, most models
are pictorial representations of reality.

• Logical models show what a system is or does.
  They are implementation independent that is,
  they depict the system independent of any
  technical implementation.

• Physical models show not only what a system is or
  does, but also how the system is (to be)
  physically and technically implemented. They are
  implementation dependent because they reflect
  technology choices.

3
Phase 2 Analysis

• Determine system requirements
• Structure requirements
• Process modeling
• Logic modeling
• Data modeling
• Select best alternative

Milestone 3
4
Phase 2B Structure Requirements

• Create conceptual design that fulfills user
  requirements
• Use models to represent conceptual design
• Facts gathered and analyzed during analysis
  provide the basis
• Two broad techniques for modeling (design)
• Object-oriented design
• Structured design

5
Features of Structured Design

• Modularization
• Top-down decomposition
• Process driven
• Modeling tools
• Iteration
• Parallel activities
• Development automation

6
Types of Modeling Tools

• Data flow diagrams (DFD)
• Entity-relationship diagrams (ERD)
• Data dictionary (DD)
• Structure charts (SC)
• Structured English
• State transition diagrams (STD)
• Structured program flowchart
• Warnier-Orr diagram
• Jackson diagram
• Etc.

7
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
• Modeling a systems process
• Utilize information gathered during requirements
  determination
• Structure of the data is also modeled in addition
  to the processes

8
Data Flow Diagrams

• Process-oriented approach
• Examines inputs, outputs, and processes of a
  system
• Purpose is to show the flow of info through a
  system
• DFD is frequently used
• 4 Sets of DFDs
• Physical DFDs of current system show how the
  current system works (NOT USED MUCH)
• Logical DFDs of current system show what the
  system currently does
• Logical DFDs of proposed system show what the
  new system must do
• Physical DFDs of proposed system show how the
  new system works (NOT USED MUCH)

9
Symbols on a DFD

• Internal or External Agent Source or Sink
  External Entity
• Indicate the net inputs and net outputs
• Can be persons, organizations, departments, or
  other systems
• Define boundaries of the system being modeled
• Singular noun phrase

10
Symbols on a DFD

• Process
• Transform input into output
• Must have both an input and an output
• Can be manual or automated
• Verb phrase
• Examples
• Perform calculations (calculate net pay)
• Make decisions (determine financial aid)
• Split flows (orders approved orders rejected
  orders)
• Combine flows (requested courses available
  courses course schedule)
• Filter or summarize flows (accounts overdue
  accounts course enrollment high-demand
  courses)

11
Symbols on a DFD

• Data Store
• A file of any kind (paper, magnetic, optical,
  etc.)
• Only processes can connect to data stores
• Only processes can use or update data in data
  stores
• Plural noun phrase
• Data Flow
• Represents the transfer of data among data
  stores, sources/sinks, and processes
• Either initiates a process or is the result from
  a process
• Singular noun phrase

12
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 sources/sinks on a diagram

13
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
• Source/Sink
• Data cannot move directly from a source to a sink
• A source/sink has a noun phrase label

• Data Store
• Data cannot be moved directly from one store to
  another
• Data cannot move directly 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

14
Data Flow Diagramming Rules

• Data Flow
• A data flow has only one direction of flow
  between symbols
• A fork means that exactly the same data goes from
  a common location to two or more processes, data
  stores or sources/sinks
• A join means that exactly the same data comes
  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

15
Advanced Rules for DFDs

• A composite data flow can be split into two data
  flows on another level. (We will not be using
  this rule because it creates problems in our CASE
  tool.)
• The inputs to a process must be sufficient to
  produce the outputs.
• At the lowest level, new data flows can be added
  to represent data that are transmitted under
  exceptional conditions, such as error messages.
  (We will not be using this rule because it
  creates problems in our CASE tool.)
• To avoid data flow lines crossing, data stores
  and external entities may be repeated on a DFD.
• (Refer to page 213 for further details)

16
Common Process Errors on DFDs
17
Data Flow Diagramming Definitions

• Context Diagram (Level 0)
• 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

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
  the process on a level-0 diagram

19
Steps in Preparing DFDs

• Draw a context level diagram
• Defines the scope and boundary for the system
• Contains only one process
• Use composite data flows

20
Steps in Preparing DFDs

• Draw a decomposition diagram to outline DFDs
• Use the explosion approach
• The context DFD is exploded into its own DFD that
  reveals the underlying subsystem, which are shown
  as subprocesses. Each of these subprocesses may,
  in turn, be exploded into its own DFD to show
  more detailed processes.
• Need to plan a decomposition diagram, also
  called a hierarchy chart, shows the top-down
  functional decomposition or structure of the
  system. It provides an outline for drawing DFDs.
• Numbering
• Context 0
• Level 1 1, 2, 3
• Level 2 1.1, 1.2, 2.1, 2.2, etc.
• Level 3 1.1.1, 1.1.2, etc.
• Primitive 1.1P
• Factor each DFD into 2 to 7 processes
• 2 must explode into at least 2 processes
• 7 do not include more than 7 for readability

21
Decomposition Diagrams

• A decomposition diagram or hierarchy chart shows
  the top-down, functional decomposition of a
  system.

22
Steps in Preparing DFDs

• Identify data stores
• Can also do decomposition here, but not necessary
• Draw a Level 1 DFD
• Exploding should add detail while retaining the
  essence of the details from the more general
  diagram
• Sometimes external entities are not shown on the
  exploded diagram, only an arrow coming from or
  going to a source is shown. THIS IS CONFUSING!
  Always show the entities.
• Balancing the task of ensuring that no details
  are lost when a process on one DFD is exploded
  to a more detailed DFD. Balancing ensures
  consistency between different levels.
• Note more data flows can be added at an exploded
  level.
• Draw a Level 2 DFD
• Draw Primitive Level DFDs
• The lowest level of decomposition of a DFD

23
An unbalanced set of data flow diagrams(a)
Context diagram and (b) Level-1 diagram
24
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

25
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

26
Guidelines for Drawing DFDs

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

27
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
• 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 option

28
SA Rentals Example

• SA Rentals rents movies to club members. Club
  members rent movies by showing a valid membership
  card and paying appropriate fees.
• Movies are due back within 24 hours of rental.
  To return a movie, the club member drops the
  movie into the return box located inside the
  front door. At various times during the day,
  employees collect and check-in movies (i.e., show
  that the movies have been returned). At the end
  of each day, a report is prepared for the manager
  which shows those movies that are past due.

29
Computer-aided Software Engineering (CASE)

• Automated software tool used by systems analysts
  to develop information systems
• Used to support or automate activities throughout
  the systems development life cycle (SDLC)
• Increase productivity
• Improve overall quality of systems

30
The Use of CASE in Organizations

• Objectives of CASE
• Improve quality of systems developed
• Increase speed of development and design
• Ease and improve testing process through
  automated checking
• Improve integration of development activities via
  common methodologies
• Improve quality and completeness of documentation
• Help standardize the development process
• Improve project management
• Simplify program maintenance
• Promote reusability
• Improve software portability

31
Components of CASE

• Upper CASE
• CASE tools designed to support the information
  planning and the project identification and
  selection, project initiation and planning,
  analysis and design phases of the systems
  development life cycle
• Lower CASE
• CASE tools designed to support the implementation
  and maintenance phases of the systems development
  life cycle
• Cross life-cycle CASE
• CASE tools designed to support activities that
  occur across multiple phases of the systems
  development life cycle
• Most CASE tools utilize a repository to store all
  diagrams, forms, models and report definitions

32
Components of CASE

• Types of CASE tools
• Diagramming tools
• Computer display and report generators
• Analysis tools used to check for incomplete,
  inconsistent or incorrect specifications
• A central repository
• Documentation generators
• Code generators

33
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
• Logic modeling can also be used to show when
  processes on a DFD occur

34
Logic Modeling

• Structured English
• Decision Tables
• Decision Trees
• State-transition diagrams
• Sequence diagrams
• Activity diagrams
• Structure Charts

35
Structure Charts (aka, Hierarchy Charts)

• Used in conjunction with DFDs
• DFDs model the system SCs model the software
  needed to support the system
• SCs represent a hierarchy of software modules,
  including documentation of interfaces between the
  modules
• SCs are created from primitive DFD processes
• A completed structure chart is the software
  design that will be coded and tested for
  implementation.

36
Structure Chart Example
37
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
• Similar to programming language
• If conditions
• Case statements

38
Modeling Logic with Structured English

• No specific standards
• However, there are some general guidelines
• Use only data element names found in the data
  dictionary
• No undefined adjectives (such as good)
• Use indention
• Use strong verbs, such as UPDATE, WRITE,
  CALCULATE
• Use proper formula notation
• Use simple declarative sentences (avoid compound
  sentences)

39
Modeling Logic with Structured English

• Examples
• DO
• FIND matching CustomerID from Customer Data
  Store
• ENTER Update to Existing Customer Record
  (CustomerID, C_FirstName, C_LastName, C_Address,
  C_City, C_State, C_Zip, C_Phone, C_Email)
• UNTIL End-of-file
• DO
• READ next Inventory Record (list data element
  names here)
• BEGIN IF
• If Quantity-in-stock is less than
  Minimum-order-quantity
• THEN GENERATE Order (list data element names
  here)
• END IF
• UNTIL End-of-file

40
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
• Good for multiple conditions (when actions are
  required based on them)

41
Figure 8-4. Complete decision table for payroll
system ex.
42
Modeling Logic with Decision Trees

• A graphical representation of a decision
  situation
• Decision situation points are connected together
  by arcs and terminate in ovals
• Two main components
• Decision points represented by nodes
• Actions represented by ovals

43
Figure 8-9.Decision tree representation of the
decision logic in the decision tables in Figures
8-4 and 8-5, with only two choices per decision
point
44
Deciding Among Structured English, Decision
Tables and Decision Trees