www.Tutorialsforu.info

2.3 Tools for Process and Data Modeling

Technical methodologies for system development propose that the documents that result from the analysis phase serve as a base for the design phase. Therefore the more detailed, articulate, and clear the analysis documents, the more useful they will be in program design. One way to accomplish this is through the use of modeling tools that allow representing the essence of a system, usually in graphical terms. Many such tools have been proposed over the years and two have achieved widespread acceptance, namely, data flow diagrams and entity-relationship diagrams.

Data flow diagrams originated in, and are often associated with, structured analysis. Entity-relationship diagrams are linked with data base systems and with object-oriented methods. Nevertheless, we believe that either method is useful independently of the context or analysis school in which it originated. In fact, data flow diagrams and entity-relationship diagrams have been used in modeling processes and data flow in both the structured analysis and the object-oriented paradigms.

System modeling can be undertaken using varying degrees of abstraction. One type of model, sometimes called a physical or implementation model, addresses the technical details as well as the system’s essence. Program flowcharts are often considered as an implementation modeling tool since a flowchart defines how a particular process can be actually coded. Essential or conceptual models, on the other hand, are implementation independent. Their purpose is to depict what a system must do without addressing the issue of how it must do it.Although implementation models are useful in documenting and explaining existing systems, it is a general consensus among system analysis that conceptual models are to be preferred in the analysis phase. The following arguments are often listed in favor of conceptual models:

1. Some incorrect solutions that result from implementation-dependent models can be attributed to bias or ignorance on the part of the designers. A conceptual model, on the other hand, fosters creativity and promotes an independent and fresh approach to the problem’s solution.

2. Excessive concern with implementation details at system specification and analysis time takes our attention away from the fundamentals. This often leads to missing basic requirements in the specification.

3. Implementation-dependent models require a technical jargon that often constitutes a communications barrier between clients and developers.

The target of this modeling effort can be either an existing or a proposed system. In this respect we should keep in mind that the fundamental purpose of modeling an existing system is to learn from it. The learning experience can be boiled down to avoiding defects and taking advantage of desirable features.

2.3.1 Data Flow Diagrams

In his work on structured analysis DeMarco suggests that one of the additions required for the analysis phase is a graphical notation to model information flow. He then proceeds to create some of the essential graphical symbols and suggests a heuristic to be used with these symbols. A few years later Gane and Sarson refined this notation calling it a data flow diagram or DDF. A data flow diagram is a process modeling tool that graphically depicts the course of data thorough a system and the processing operations performed on this data. Figure 2.3 shows the basic symbols and notation used in data flow diagrams.
 

One variation often used in the Gane and Sarson notation is to represent processes by means of circles (sometimes called bubbles). A valid justification of this alternative is that circles are easier to draw than rounded rectangles. Processes are the core operation depicted in data flow diagrams. A process is often described as an action performed on incoming data in order to transform it. In this sense a process can be performed by a person, by a robot, or by software. Processes are usually labeled with action verbs, such as Pay, Deposit, or Transform, followed by a clause that describes the nature of the work performed. However, on higher level DFDs we sometimes see a general process described by a noun or noun phrase, such as accounting system, or image enhancement process. Routing processes that perform no operation on the data are usually omitted in essential DFDs. The operations performed by processes can be summarized as follows:

1. Perform computations or calculations

2. Make a decision

3. Modify a data flow by splitting, combining, filtering, or summarizing its original components

Internal or external agents or entities reside outside the system’s boundaries. They provide input and output into the system. In this sense they are often viewed as either sources or destinations. An agent is external if it is physically outside the system, for example, a customer or a supplier. Internal agents are located within the organization, but are logically outside of the system’s scope. For example, another department within the company can be considered as an internal agent. It is possible to vary the level of abstraction and magnification of details in a DFD. Some authors propose the designation of specific abstraction levels. In this sense a level 0 DFD, called a fundamental system model, consists of a single process bubble which represents the entire software system. A level I DFD could depict five or six processes which are included in the single process represented in the level 0 bubble. Although the notion that several DFDs can be used to represent different levels of abstraction is useful, the requirement that a specific number of processes be associated with each level could be too restrictive. Figure 2.4 shows an initial level of detail for representing a satellite imaging system.
Notice that in Figure 2.4 the process bubble has been refined with a header label that adds information regarding the process. In this case the header refers to who is to perform the process. Also notice that the processes are represented by noun phrases, which is consistent with the general nature of the diagram. Although this initial model provides some fundamental information about the system, it is missing many important details. For example, one satellite may be equipped with several sensing devices that generate different types of image data, each one requiring unique processing operations. Or a particular satellite may produce images that are secret; therefore, they should be tagged as such so that the delivery system does not make them available to unqualified customers. Figure 2.5 shows a second level refinement of the image processing system

 

The level of detail shown by the DDF in Figure 2.5 is much greater than that in Figure 2.4. From the refined model we can actually identify the various instruments on board the satellites and the operations that are performed on the image data produced by each instrument. However, the actual processing details are still omitted from the diagram, which are best postponed until the system design and implementation phases. Note that in Figure 2.5 the process names correct, format, and record are used as verbs, consistent with the greater level of detail shown by this model. Note that the names of satellites, instruments, and image formats do not exactly correspond to real ones.

Event Modeling
Many types of systems can be accurately represented by modeling data flow, but some cannot. For example, a burglar alarm system is event driven, as is the case with many real-time systems. First, Ward and Mellor, and later Hatley and Pribhai, introduced variations of the data flow diagram which are suitable for representing real-time systems or for the event-driven elements of conventional systems. The Ward and Mellor extensions to DFD symbols are shown in Figure 2.6.
The resulting model, called a control flow diagram or CFD, includes the symbols and functions of a conventional DFD plus others that allow the representation of control processes and continuous data flows required for modeling real-time systems. Equipped with this tool we are now able to model systems in which there is a combination of data and control elements. For example, a burglar alarm system as installed in a home or business includes a conventional data flow component as well as a control flow element. In this case the conventional data flow consists of user operations, such as activating and deactivating the system and installing or changing the password. The control flow elements are the signals emitted by sensors in windows and doors and the alarm mechanism that is triggered by these sensors. Figure 2.7 represents a CFD of a burglar alarm system.

2.3.2 Entity-Relationship Diagrams

Currently the most used tool in data modeling is the entity-relationship (E-R) diagram. This notation, first described in the early 1980s by Martin and later modified by Chen and Ross, is closely related to the entity-relationship model used in database design. E-R diagram symbols have been progressively refined and extended so that the method can be used to represent even the most minute details of the schema of a relational database. However, in the context of general system analysis we will restrict our discussion to the fundamental elements of the model. Since one of the fundamental operations of most computer systems is to manipulate and store data, data modeling is often a required step in the system analysis phase. E-R diagrams are often associated with database design; however, their fundamental purpose is the general representation of data objects and their relationship. Therefore the technique is quite suitable to data analysis and modeling in any context.

Furthermore, E-R notation can be readily used to represent objects and object-type hierarchies, which makes this technique useful in object-oriented analysis.

The entity-relationship model is quite easy to understand. An entity, or entity type, is a “thing” in the real world. It may be a person or a real or a conceptual object. For example, an individual, a house, an automobile, a department of a company, and a college course are all entity types. Each entity type is associated with attributes that describe it and apply to it. For example, the entity type company employee has the attribute’s name, address, job title, salary, and social security number; while the entity type college course has attribute’s name, number, credits, and class times. Notice that the entity employee is physical, while the entity college course is abstract or conceptual.

The entity-relationship model also includes relationships. A relationship is defined as an association between entities. In this sense we can say that the entity types employee and department are associated by the relationship works for since in the database schema every employee works for a department. By the same token we can say that the works on relationship associates an employee with a project, thus associating the entity types employee and project As shown in Figure 2.8, it is conventional practice to type entity and relationships in uppercase letters while attribute names have initial caps. Singular nouns are usually selected for entity types, and verbs for relationships. Attributes are also nouns that describe the characteristics of an entity type. An entity type usually has a key attribute which is unique and distinct for the entity. For example, the social security number would be a key attribute of the entity type employee, since no two employees can have the same social security number. By the same token, job title and salary would not be key attributes since several employees could share this characteristic. Notice that while some entities can have more than one key attribute, others have none. An entity type with no key attribute is sometimes called a weak entity. Key attributes are usually underlined in the E-R diagram.

In regards to relationships we can distinguish two degrees of participation: total and partial. For example, if the schema requires that every employee work for a department, then the works for relationship has a total participation. Otherwise, the degree of participation is a partial one. Cardinality constraints refer to the number of instances in which an entity can participate. In this sense we can say that the works for relationship for the types DEPARTMENT: EMPLOYEE has a cardinality ratio of 1:N; in this case an employee works for only one department but a department can have more than one employee. Figure 2.9 shows an entity-relationship diagram for a small company schema.

 
Figure 2.9 Entity-Relationship Diagram for a Company

The diagrams are read left to right or top to bottom. This convention is important: for example, when the diagram in Figure 2.9 is read left to right it is the department that controls the project, not vice versa.