1 / 67

Chapter 7 Analysis: Process Modeling

Modern Systems Analysis and Design Seventh Edition Jeffrey A. Hoffer Joey F. George Joseph S. Valacich. Chapter 7 Analysis: Process Modeling. Outline. Analysis (Milestone 3) Solutions Document DFDs ERD Structured English Data Dictionary Alternatives. Phase 2: Analysis.

dennis
Télécharger la présentation

Chapter 7 Analysis: Process Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Modern Systems Analysisand DesignSeventh Edition Jeffrey A. Hoffer Joey F. GeorgeJoseph S. Valacich Chapter 7 Analysis: Process Modeling

  2. Outline • Analysis (Milestone 3) • Solutions Document • DFDs • ERD • Structured English • Data Dictionary • Alternatives

  3. Phase 2: Analysis • Determine system requirements • Structure requirements • Process modeling • Logic modeling • Data modeling • Select best alternative Milestone 3

  4. Milestone 3 Milestone 3

  5. Solutions Document • List the problems identified in Milestone 2. • For each problem, identify how they will be solved with the new system design.

  6. 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

  7. Features of Structured Design • Modularization • Top-down decomposition • Process driven • Modeling tools • Iteration • Parallel activities • Development automation

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

  9. Models: Logical and Physical • Model • 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.

  10. 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 • 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

  11. Data Flow Diagrams • 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)

  12. DFD Symbols FIGURE 7-2 Comparison of DeMarco and Yourdon and Gane and Sarson DFD symbol sets

  13. 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

  14. 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)

  15. 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

  16. 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

  17. 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 Data Flow Diagramming Rules

  18. 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 Data Flow Diagramming Rules

  19. 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 199 for further details)

  20. Common Process Errors on DFDs

  21. Decomposition of DFDs • 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 • 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

  22. 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

  23. Steps in Preparing DFDs • Draw a decomposition diagram to outline DFDs • 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. • 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

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

  25. 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 between processes. • Draw a Level 2 DFD • Draw Primitive Level DFDs • The lowest level of decomposition of a DFD

  26. An unbalanced set of data flow diagrams(a) Context diagram and (b) Level-1 diagram

  27. Guidelines for Drawing DFDs • Completeness • DFD must include all components necessary for system • Consistency • The extent to which information contained on one level of a set of nested DFDs is also included on other levels • 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

  28. Guidelines for Drawing DFDs • Primitive DFDs • Lowest logical level of decomposition • 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

  29. 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.

  30. Modern Systems Analysisand DesignSeventh Edition Jeffrey A. Hoffer Joey F. GeorgeJoseph S. Valacich Chapters 8 and 9 Analysis: Data Modeling

  31. Data Modeling Data modeling • A technique for organizing and documenting a system’s data • Sometimes called database modeling because a data model is eventually implemented as a database • The actual model is frequently called an entity relationship diagram (ERD) because it depicts data in terms of the entities and relationships described by the data.

  32. Entity-Relationship Diagrams • Data-oriented approach • Uses the data and the relationships among data to model requirements • Purpose is to show the data used in the system • Good for modeling data stores from a DFD • ERD Symbols • Entity: a person, place or thing • Relationship: shows how entities interact and work together • Attribute: a named property or characteristic of an entity that is of interest to the organization

  33. Sample Entity Relationship Diagram (ERD)

  34. Steps to Preparing ERDs • Identify entities • Indicate relationships between entities • Define keys for each entity • Define and map data elements for each entity • Normalize the data model

  35. Data Modeling Concepts: Entity Entity • A class of persons, places, objects, events, or concepts about which we need to capture and store data. • Persons: agency, contractor, customer, department, division, employee, instructor, student, supplier. • Places: sales region, building, room, branch office, campus. • Objects: book, machine, part, product, raw material, software license, software package, tool, vehicle model, vehicle. • Events: application, award, cancellation, class, flight, invoice, order, registration, renewal, requisition, reservation, sale, trip. • Concepts: account, block of time, bond, course, fund, qualification, stock.

  36. Data Modeling Concepts: Entity Entity Instance • A single occurrence of an entity. Example: instances of the entity STUDENT may include: • Betty Arnold • John Taylor • Lisa Simmons • Bill Macy • Heather Leath • Tim Wrench

  37. Data Modeling Concepts: Attributes Attribute • A descriptive property or characteristic of an entity. Synonyms include element, property, and field. Compound Attribute • One that actually consists of other attributes

  38. Data Types and Domains Data attributes • Should be defined by data types and domains. Data Type • Defines what class of data can be stored in an attribute (e.g., character, integers, real numbers, dates, pictures, etc.) Domain • Defines what values or range of values an attribute can legitimately take on Default Value • The value that will be recorded if not specified by the user

  39. Data Modeling Concepts: Identification Primary Key (PK) • The field that will most commonly be used to uniquely identify a single entity instance. Composite Primary Key (CPK) • The use of more than one field to uniquely identify a single entity instance. Foreign Key (FK) • The primary key of one entity that is used in another entity to form a relationship.

  40. 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

  41. Degree of Relationship • Degree • Number of entity types that participate in a relationship • Three cases • Unary • A relationship between two 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

  42. Example Relationships of Different Degrees

  43. 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

  44. 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 • Results from the elimination of a many-to-many relationship

  45. Data Analysis & Normalization Data analysis • Process that prepares a data model for implementation as a simple, nonredundant, flexible, and adaptable database. • The specific technique is called normalization. Normalization • Data analysis technique that organizes data attributes such that they are grouped to form nonredundant, stable, flexible, and adaptive entities.

  46. Normalization: 1NF, 2NF, 3NF • First Normal Form (1NF) • No attributes can have more than one value for a single instance of the entity. • Any attributes that can have multiple values actually describe a separate entity, possibly an entity and relationship. • Second Normal Form (2NF) • Already in 1NF • Values of all nonprimary key attributes are dependent on the full primary key, not just part of it. • Any nonkey attributes that are dependent on only part of the primary key should be moved to any entity where that partial key is actually the full key. This may require creating a new entity and relationship on the model. • Third Normal Form (3NF) • Already in 2NF • Values of nonprimary key attributes are not dependent on any other non-primary key attributes. • Any nonkey attributes that are dependent on other nonkey attributes must be moved or deleted. Again, new entities and relationships may have to be added to the data model.

  47. ERD Example • Department has many instructors • Instructors have one department • College has many departments • Departments have one college • Students have many instructors but only one department

  48. Data Dictionary (aka, Project Repository) • Use information from DFDs and ERD to create the DD • DD details each of the data items, data flows, processes, etc. in a system • For example: DD entry for data items would show characteristics such as size, type, description, ranges, access privileges, security level, etc.

  49. Data Dictionary Requirements • Complete the Data Store report first • Create a document, in table format, that lists each data store alphabetically • Within each data store, identify all the data elements (i.e. attributes), alphabetically • Identify the PK or CPK, and FKs within each data store • Next, create a Data Element report • Create a document, in table format, that lists each data element that has been stored in the data stores, alphabetically by data element name • Also provide a one sentence description of each, along with the data type and size, etc.

  50. Data Dictionary Requirements (Cont.) • Processreport • Create a document, in table format, that lists each process alphabetically • Provide the process number and a short description of each process purpose • Source/Sink (External Entity) report • Create a document, in table format, that lists each external entity alphabetically • Provide a description of each external entity • Data Flow report • Create a document, in table format, that lists each data flow alphabetically • Indicate where the data flow is coming from and where it is going to for the primitive diagrams

More Related