Kiến trúc máy tính và hợp ngữ - Chapter 4: Requirement analysis

DFD definition DFD components DFD Key definition DFD level Data flow diagram shows business processes and the data that flows between them. Data flow modeling takes a functional decomposition approach to systems analysis, breaking complex problems into progressive levels of detail. 2 type of DFD Logical process models describe processes without suggesting how they are conducted Physical models include information about how the processes are implemented The DFD is a diagram that consists principally of four symbols, namely the external entity, the data flow, the process and the data store Additionally, a physical flow can be shown on the DFD of the current system External entity: are those things that are identified as needing to interact with the system under consideration Gane and Sarson Symbol DeMarco and Yourdan Symbol Example Process: an activity that receives data and carries out some form of transformation or manipulation before outputting. Naming convention of a process: Name of a system Name of a subsystem A verb Process: an activity that receives data and carries out some form of transformation or manipulation before outputting Gane and Sarson Symbol DeMarco and Yourdan Symbol Data flow: Data move in a specific direction from an origin to a destination Gane and Sarson Symbol DeMarco and Yourdan Symbol Data store: places where data may be stored Gane and Sarson Symbol DeMarco and Yourdan Symbol Decomposition is the process of modeling the system and its components in increasing levels of detail. Balancing involves insuring that information presented at one level of a DFD is accurately represented in the next level DFD. DFDs exist in a hierarchy, beginning with the simplest, highest, system level and ending with the lower level diagrams with detailed processes Context diagram: DFD at the system level illustrates the cotext DFD level 0 DFD level 1 DFD level 2 Shows the context into which the business process fits Shows the overall business process as just one process Shows all the outside entities that receive information from or contribute information to the system Context Diagram can be drawn by following steps: Step 1 - List the documents used in the system. Step 2 - List all the sources & recipients Step 3 - Draw a box representing the system and show the flow of documents from these sources and recipients. Those areas which are known to be inside the system are hidden within the box. Example Shows all the processes that comprise the overall system Shows how information moves from and to each process Adds data stores Shows all the processes that comprise a single process on the level 0 diagram Shows how information moves from and to each of these processes Shows in more detail the content of higher level process Level 1 diagrams may not be needed for all level 0 processes  Shows all processes that comprise a single process on the level 1 diagram  Shows how information moves from and to each of these processes  Level 2 diagrams may not be needed for all level 1 processes  Correctly numbering each process helps the user understand where the process fits into the overall system  Build the context diagram  Create DFD fragments for each scenario  Organize DFD fragments into level 0  Decompose level 0 DFDs as needed  Validate DFDs with user Use case definition Use case diagram UML (Unified Modelling Language) provides a common vocabulary of object-oriented terms and diagramming techniques that is rich enough to model any systems development project from analysis through implementation Use cases are text stories that are useful for discovering and recording requirements. Use-case modeling is primarily an act of writing text, not drawing diagrams. UML defines a use case diagram to illustrate the names of use cases and actors, and their relationships. Process Sale: A customer arrives at a checkout with items to purchase. The cashier uses the POS system to record each purchased item. The system presents a running total and line- item details. The customer enters payment information, which the system validates and records. The system updates inventory. The customer receives a receipt from the system and then leaves with the items. A use case can be written in one of 3 notations: Brief: only the main scenario, with a short description. Casual: multiple scenarios described by short paragraphs. “Fully-dressed”: fully elaborated with supporting sections.  A fully-dressed use case has these sections: Use case name Scope Level Primary actor Stakeholders and interests Preconditions Success guarantee (postconditions) Main success scenario Extensions Special requirements Technology and data variations list Frequency of occurrence Miscellaneous Actor: something with behavior, outside the system under discussion Scenario: a specific sequence of actions and interactions. Sometimes called a use case instance. Use case: a collection of related success/failure scenarios. Primary actor: has a user goals filfilled through using services of the systems Supporting actor: provides service to the system Offstage: interested but not directly involved. Ex: the tax agency. Choose the system boundary Identify primary actors Identify goals for each primary actor Define use cases in terms of user goals The EBP (elementary business process) test: a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state, e.g. Approve Credit or Price Order. A common use case mistake  Defining many use cases at too low a levell that is as a signle step, subfunction, or subtask within an EBP The EBP (elementary business process) test: a task performed by one person in one place at one time, in response to a business event, which adds measurable business value and leaves the data in a consistent state, e.g. Approve Credit or Price Order. A common use case mistake  Defining many use cases at too low a levell that is as a signle step, subfunction, or subtask within an EBP Represents the scope of the subject, e.g., a system or an individual business process Includes the name of the subject inside or on top System name is a user or external system with which a system being modeled interacts. Are placed outside the system boundary > Actor/Role Represents a major piece of system functionality Is placed inside the system boundary Is labeled with a descriptive verb-noun phrase Use case Actor – Actor: Generalization Actor - use case: Association Use case – use case: Generalization Include Extend Actor – Actor: Generalization: An actor may specialize multiple actors, and an actor may be specialized by multiple actors. Sinh viên Sinh viên chưa tốt nghiệp Sinh viên đã tốt nghiệp Actor – Use case: Association: it indicates that the actor communicates with the system and participates in the use case. Use case – Use case: Extend : the extension use case will extend (or be inserted into) and augment the base use case base extending > Use case – Use case: Include: indicates that the base use case will include or call the inclusion use case. base included > Đăng ký HP Đăng nhập Use case – Use case: Generalization: address this situation by factoring out and reusing similar behavior from multiple use cases.