Posts

Showing posts from April, 2012

UML Diagram

The Unified Modeling Language (UML) is a general-purpose visual modeling language that is used to specify, visualize, construct, and document the artifacts of a software system. It captures decisions and understanding about systems that must be constructed. It is used to understand, design, browse, configure, maintain, and control information about such systems. It is intended for use with all development methods, life cycle stages, application domains, and media. The modeling language is intended to unify past experience about modeling techniques and to incorporate current software best practices into a standard approach. UML includes semantic concepts, notation, and guidelines. It has static, dynamic, environmental, and organizational parts. It is intended to be supported by interactive visual modeling tools that have code generators and report writers. The UML specification does not define a standard process but is intended to be useful with an iterative development process. It is

Purpose of DFD

The purpose of Data Flow Diagrams is to show the “flow” and transformation of data through the system.  These diagrams are used as a visualization tool to help the audience get a better idea of what exactly is going on in the system.     A Context Diagram is shown next, which is the general overview of each of the different agents interacting with the system.    The Level 0 Diagram shows some more details about which processes each of the agents will be interacting with.  Arrows are drawn to show the flow of data between the agents and processes.    Following the Level 0 Diagram are Level 1, Level 2, Level 3 and Level 4 Diagrams.  These Diagrams further break down each of the processes that are involved with the system, each showing more detail the further down the level is.

Overview of DFD

A Data Flow Diagram ( DFD ) is a graphical representation of the "flow" of data through an information system. DFDs can also be used for the visualization of data processing. On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink, via an internal process. A DFD provides no information about the timing of processes, or about whether processes will operate in sequence or in parallel. It is therefore quite different from a flowchart, which shows the flow of control through an algorithm, allowing a reader to determine what operations will be performed, in what order, and under what circumstances, but not what kinds of data will be input to and output from the system, nor where the data will come from and go to, nor where the data will be stored (all of which are shown on a DFD). It is common practice to draw the context-level data flow diagram first, which shows the interaction between t

DFD Symbols

Data Flow Diagram (DFD) Summary Data Flow Symbols Unique Names for Data Flows.   No two data flows should ever have the same name.  (Remember, data is transformed by a process, so the input and output data flows from a process will have different names.) Data Flows should be consistent and cascade among levels. For example, if a “Student” EE provides an application to a process on a level 1 DFD (Figure 1 or Figure 2 or Figure 3), then it must appear on the Figure 0 DFD and the context diagram As a quick double-check before you turn in home work and projects: Count all the data flows on your context diagram from each EE.  On the level 0 diagram, the counts should be the same.  Cascade this rule for each subordinate level. NOTE: You should perform this same check for each data store. Process Symbols DFD Process symbols have 3-parts : a numeric id on top, a verb-object process label in th

Rules for Stopping the Decomposition Process in DFD

Rules for Stopping the Decomposition Process in DFD (1) when you have reduced each process to a single decision or calculation or to a single database operation;  (2) when each data store represents data about a single entity;  (3) when the system user does not care to see any more detail or when you and other analysts have documented sufficient detail to do subsequent systems development tasks;  (4) when every data flow does not need to be split further to show that different data are handled in different ways;  (5) when you believe that you have shown each business form or transaction, computer on-line display, and report as a single data flow;  (6) when you believe there is a separate process for each choice on all lowest-level menu options for the system.

Construct DFD

To construct a data flow diagram: Maintain a consistent level of detail with between five and nine symbols per page.  Data flow arrows do not cross each other. Label your data flow arrows first - these are the most important items - and your processes circles last Process circles may have several arrows flowing into and out of them An arrow from a data store always go to a process.  An arrow to a data store always comes from a process Include a descriptive narrative that explains the data flow diagram

Define Data Flow Diagram

DEFINING DATA FLOW DIAGRAMS (DFDs) When it comes to conveying how information data flows through systems (and how that data is transformed in the process), data flow diagrams (DFDs) are the method of choice over technical descriptions for three principal reasons. 1. DFDs are easier to understand by technical and nontechnical audiences 2. DFDs can provide a high level system overview, complete with boundaries and connections to other systems 3. DFDs can provide a detailed representation of system components DFDs help system designers and others during initial analysis stages visualize a current system or one that may be necessary to meet new requirements. Systems analysts prefer working with DFDs, particularly when they require a clear understanding of the boundary between existing systems and postulated systems. DFDs represent the following: 1. External devices sending and receiving data 2. Processes that change that data 3. Data flows themselves 4. Data storage locations

Structured Analysis

Structured analysis is a development method for the analysis of existing manual or automated systems, leading to the development of specifications for a new or modified system. The underlying objective in structured analysis is to organise the tasks associated with requirements determination to provide an accurate and complete understanding of a current situation. The word structure in structured analysis means: 1.The method attempts to structure the requirements determination process, beginning with documentation of the existing system. 2.The process is organised in such a way that it attempts to include all relevant details that describe the current system. 3. It is easy to verify when relevant details have been omitted. 4. The identification of requirements will be similar among individual analysts and will include the best solutions and strategies for systems development opportunities. 5. The working papers produced to document the existing and proposed systems are effecti

Physical DFD to Logical DFD

How to Derive Logical DFD from Physical DFD? Physical DFDs are a means to an end, not an end in themselves. They are drawn to describe an implementation of the existing system for two reasons: ·   to ensure a correct understanding of the current implementation (users are generally better able to discuss the physical system as they know it through people, workstations and days of the week.) ·   the implementation itself may be a problem or limiting factor; changing the implementation, rather than the system concept may provide the desired results. A logical view steps back from the actual implementation and provides a basis for examining the combination of processes, data flows, data stores, inputs and outputs without concern for the physical devices, people or control issues that characterise the implementation. A logical data flow diagram is derived from the physical version by doing the following: ·   Show actual data needed in a process, not the documents that contain them.