System Analysis: Case Study

System Analysis Overview It is one of the most important phases of the whole system development. Generally, the whole process consists of –System analysis (may include survey phase) –System design –System implementation (may include testing, coding, etc). During the analysis process, there are two phases: –Constructing Environmental model: It defines the interfaces between the system and the rest of the environment, i.e., determine what is outside of the system. It consists of three components: Statement of purpose Context diagram Event list –Constructing Behavioral model: It defines what the internal behavior of the system must be in order to deal successfully with the environment. The following tools are involved in this model: DFD ERD DD PS model consistency is the major issue when using the tools above together. This will be discussed in detail later.

Case study: YOURDON Press Information System (YPIS) 1 Statement of Purpose for YPIS: –Example statement of purpose: The purpose of the YOURDON Press Information (YPIS) is to maintain information needed to sell books to customers. This includes order entry, invoicing, generation of shipping documents, inventory control, and production of royalty reports and accounting reports. Context Diagram of YPIS

Case study: YOURDON Press Information System (YPIS) 2 Event list: There are 40 event lists in this case. The following is some of them. –1. Customer orders book (this includes special rush orders, too). –2. Customer sends payment. –3. Customer asks for book information (price,etc). –4. Customer asks permission to return a book. –5. Customer asks about status of a book order. –6. Customer asks about status of an invoice. –7. Customer needs (monthly) statement. (Temp) –8. Customer asks for credit memo. –9. Customer wants refund check. –10. Printer offers quotation. –11. Printer advises exact print quantity and delivery date. –12. Printer sends invoice for print job. –………..

Case study: YOURDON Press Information System (YPIS) 3 Drawing preliminary DFDs: –For each event list, build a DFD for every one of them. As there are 40 event lists in this case, there are 40 diagrams. Note to the example DFDs: –To be consistent with the textbook, the notations in the following DFDs should be standardized in several ways: Double-headed flow is prohibited. It should be replaced with two single-direction flow, representing input-flow and output-flow respectively. Data packets should be named explicitly for each data flow.

Case study: YOURDON Press Information System (YPIS) 4 Example of preliminary DFD for event 1,2,3. –Event 1: Customer orders book.

Case study: YOURDON Press Information System (YPIS) 5 –Event 2: Customer sends payment –Event 3: Customer asks for book information

Middle-out approach in behavioral model construction In contrast with a pure top-down and a pure bottom-up approach, this is a “middle-out” approach. After the initial DFD is developed (for each event, there is a DFD for it), some upward leveling is required, and some further downward partitioning may be necessary. Upward leveling of the preliminary DFD: –group related processes together into meaningful aggregates, each of which will represent in bubble in a higher-level diagram. –Look for opportunities to hide, or “bury”, stored data that appear at the lower level. Thus, if you see a group of processes in the preliminary DFD that refer to a common store, and no other processes in preliminary DFD refer to that store, then you can create a higher level bubble that hides the store. See figure on next page. –When the processes identified in the preliminary DFD may not turn out to be primitive processes, downward partitioning into lower-level DFDs may be needed.

Upward leveling the DFD

Case study: YOURDON Press Information System (YPIS) 6 Figure 0: The top-level DFD transformed from all event DFDs. This DFD should be further upward leveled subsequently.

Case study: YOURDON Press Information System (YPIS) 7 Figure 1

Case study: YOURDON Press Information System (YPIS) 8 Figure 1.1

Case study: YOURDON Press Information System (YPIS) 9

Case study: YOURDON Press Information System (YPIS) 10: The Entity-Relationship Diagram

Case study: YOURDON Press Information System (YPIS) 11 Note that the process specification is only needed for bottom leave bubbles.

Balancing the models (1) Balancing the model focus on model consistency. It is not only logically wrong but also dangerous. We will examine several major aspects of balancing: –Balancing the DFD against the DD (data dictionary) –Balancing the DFD against the PS (process specifications). –Balancing the process specifications against the DD. –Balancing the ERD against the DFD and PS. –Balancing the ERD against the DD.

Balancing the models (2) Balancing the DFD against the DD –Every dataflow and every data store must be defined in the data dictionary. –Conversely, every data element and every data store defined in the data dictionary must appear someplace on a DFD. –WinA&D support automatic check. Balancing the DFD against the PS –Every bubble in the DFD must be associated with a lower-level DFD or a process specification, but not both. Process specification is needed for bottom-level bubble only. –Every process specification must have an associated bottom-level bubble in the DFD. –Inputs and outputs must match. The DFD will show incoming and outgoing flows for each bubble, as well as connections to stores. These should be evident in the process specification, too: thus, we should expect to see a READ statement (or GET, INPUT, etc) corresponding to each incoming dataflow and a WRITE (or PUT, etc) for each outgoing dataflow.

Balancing the models (3) Balancing the PS against DFD and DD –each data reference in the process specification (typically a noun) must satisfy one of the following rules: It matches the name of a dataflow or data store connected to the bubble described by the PS, or It is a local term, explicitly defined the PS, or It appears as a component in a DD entry for a dataflow or data store connected to the bubble. Balancing the DD against the DFD and PS –DD is consistent with the rest of the model if it obeys the following rule: each entry in the data dictionary must be referenced by a PS, or a DFD, or another DD entry

Balancing the models (4) Balancing the ERD against the DFD and PS –Every store on the DFD must correspond to an object type, or a relationship, or a combination of an object type and relationship on the ERD. If there is a store on the DFD that does not appear on the ERD, something is wrong; and if there is an object or relationship on the ERD that does not appear on the DFD, something is wrong. –Object names on the ERD and data store names on the DFD must match. –The DD entries must apply to both the DFD model and the ERD model.