http://blog.teachbook.com.au

A model describes the information system as it is, or will be, implemented by the users; it is in a graphical form. Models are a graphical method of representing a system rather than a narrative method (‘a picture paints a thousand words’). Building models of information systems helps analysts clarify whether or not they have accounted for all aspects of the sytem.

If you wre an architect designing a building you would construct a series of drawings: one showing room dimensions, one showing the plumbing required and one showing the electrical wiring. As a systems analyst you will construct a series of models depicting different aspects of the information system:

• A context diagram to system will fit into the physical processes/environment
• A Data Flow Diagram to show the processes carried out
• Entity-Relationship diagrams to describe the relationships within the data
• A Data Dictionary to describe the data used by the system and so on.

Context Diagram

One of the main modelling tools used in the data flow fiagram (DFD). The starting point or top level of the data flow diagrams is the context diagram.

A systems analyst draws a context diagram after he or she has collected a great deal of information about how the information system works. When the investigation phase (of the SDLC) is complete and the analysis phase is underway, at this point the context diagram is drawn. The context diagram is an attempt to clarify exactly how the information system interacts with its environment.

At the stage when the context diagram is drawn, the analyst is not interested in the detail of the actual processing that occurs within the information system – that comes later with the DFD. Just as an architect draws sketch of a building and shows how it fits onto a particular block, a systems analyst draws a context diagram and shows how it fits into its environment. The architect’s drawing does not show any detail of individual rooms and sizes, and neither does the context diagram show any detail of what processing takes place nor the data files required within the system.

Data Flow Diagrams

A data flow diagram (DFD) shows the procesess as well as the data flows that are used by and generated by the processes within an information system. As well as these, a DFD shows the external entities generating and receiving data from the information system and also the data stores where the data has to be stored long term in order for the information system to function.

When do you draw a DFD?

You draw a DFD after you have already drawn the context diagram and are convinced that you have correctly identified the system boundary, that is, the scope of the system.

DFDs can be drawn at the analysis phases as well as at the design phases of the systems development life cycle. At the analysis phase the DFD depicts the information system as it works at present, whereas at the design phase the DFD shows the information system after design changes have been made in order to make it more efficient.

A DFD is an excellent communication tool. When the system analyst draws the DFD at the analysis phase, missing elements which may otherwise have gone unnoticed may be highlighted. The DFD may even have to be revised if ‘new’ data flows or entities are discovered. This analysis-phase DFD is then an invaluable tool during the design phase; certain aspects of the information system might change but, unless the system is undergoing drastic alterations, the vast bulk of the processing will remain unchanged.

How do DFDs differ from context diagrams?

The symbols used for drawing DFDs are the same as for context diagrams (the context diagram is, after all, the starting point from which the DFD is developed).

There are however some additional features included in a DFD:

• the data store makes its appearance
• the system itself breaks down into a number of processes
• internal data flows make an appearance, both those between processes and those betweeen procesesses and data stores.

System Flow Charts

System flow charts are concrete models of information system. They depict the physical aspects of the information system rather than the logical aspects. They show the major inputs, outputs and porcessing as well as the interrelationships between them. They also depict the forms that these inputs and outputs take (such as printed report or manual input) as well the medium used to store the data files (disk or tape).

System flow charts also show the sequence of steps through which data passes: they have a starting point and an end point and each event is in some way related to each other event. System flow charts do not provide the detail of how inputs are converted to outputs, buy they do show whether the conversations are manual or electronic.

System flow charting was a popular modelling method in the past when most information systems were large batch processing one; this modelling methodology has mostly been replaced by the Process Modeling tootls. Organisations that still employ system flow carts use them to document the overall system and as a guide for computer operators to assist them outline operating procedures for executing systems.

System Flow Charts and DFDs

It is important to understand the differences between system flow charts and data flow diagrams (DFDs). Whereas system flow charts model a physical information system, DFDs are a logical model. The main characteristics of these different modelling techniques are compared below.

Data Dictionaries

The Data Dictionaries describe the model the elements of data used by the information system. It is essentially a dictionary of the names used int he specifying documentation and programs for a data-processing application or group of related applications. Against each entry there would typically be the type of object being named (that is, where it is a data itme or field, record, file, report, screen display, etc.), its precise specification, some explanatory description of its use, and a reference to all places in the documentation and programs where it is used.

For large-scale and complex systems a data dictionary is a vital tool for the central control of naming, and of semantics and syntax of the system. It is a tool widely used in database administration and increasingly to assist in the broader task of system design, many design methodologies being founded on the use of a data dictionary. The term system dictionary and data dictionary may be used synonymously in the case of the more ambitious software-based dictionary systems.

The term data dictionary is sometimes used misleadingly by software product vendors to refer to the alphabetical listings of names automatically produced when database schema and data manipulation coding is being processed and compiled, and it is important not to confuse this use with the accepted teachnical meaning of the term.

Entity Relationship Diagrams

Entity-Relationship (E-R) analysis uses three major abstractions to describe data.

These are:

1. Entities – which are distinct things in the enterprise
2. Relationships – which are meaningful interactions between objects
3. Attributes – which are the properties of the entities and relationships

Entity Relationship Diagrams (ERDs) illustrate the logical structure of databases. Although it is relatively easy to describe waht an ER diagram looks like, it is much harder to describe how one goes about developing an ER diagram for a particular system. There are some imporant points to consider here: how to choose entities, relationships, and attributes, how to choose names, and what steps should be followed in analysis.

One of the most important things to remember is that in analysis we are trying to capture the precise semantics of a system. To do so it is necessary to identify the fundamental components of a system and relationships between them. For this reason, each set in the E-R diagram should model only one concept. Thus, each entity set models only the one concept – that is, entities with some common properties. Each relationship set models the one concept of two entities, each from the same set interacting in the same way. If you adhere to this idea you can pace only things with the same properties into the same entity set. Thus, all persons would fall into one entity set named PERSONS, all parts into one entity set named PARTS, and so on. In any case, you would not place persons and parts into the one entity set.

What kinds of things are to be modeled as entity sets? The most common system entities are distinct physical things in the organisation, things such as persons, parts and invoices. However, other things that are not so clearly visible are also modeled departments, and budgets. Finally, things that happen, such as deliveries, faults, or examinations, may also be modeled as entities.