1 2 3 4
A Data Store can be in the form of either a file held on disk or a physical batch of documents.
An External Entity is an external source of data such as a group of people (e.g. customers).
The Process box shows any processes carried out on the data. The two horizontal lines inside the shape are optional but the spaces created by them can be used to label the process (top) or specify where it takes place (bottom).
One technique commonly used in analyzing a client's requirements is data modeling. The purpose of data modeling is to develop an accurate model, or graphical representation, of the client's information needs and business processes. The data model acts as a framework for the development of the new or enhanced application. There are almost as many methods of data modeling as there are application development methodologies.
As time goes by, applications tend to gain new "layers" of functions and features. Soon it gets to the point where the core of the application is obscured by all these "layers". Data modeling encourages both the developer and the client to tear off these excess layers and to explore the ultimate purpose of the application once more.
Logical Data Design
Data design selects logical representations for the data objects identified during the requirements definition and specification phase of analysis. A data dictionary is established and used to define both data objects and the relationships between them. A process of step-wise refinement of data structures is used to ensure anomalies and exclusions are catered for. For relational databases, this is the process of data normalisation identified and refined by Date and Codd. The resulting data structures must apply the concept of data hiding. Among the graphical representations used in data design are Jackson Structured diagrams and Warnier-Orr diagrams. (Both these are also used in process design, too.)
Logical Process Design
A process design is created which can then be transformed into a procedural description of the software. The early techniques of flowcharting were developed into the simple logical constructs of structured programming (sequence, selection and iteration). They have the advantage of limiting procedural design to structures consisting of a small number of predictable operations. Graphical notations used to express these structures include flowcharting, Nassi-Shneidermann diagrams, decision tables, program design language (PDL), sometimes referred to as pseudocode, and control structure diagrams.
Object oriented design creates a representation of a real-world problem domain and maps it into a software solution domain. The design interconnects data objects and processing operations that include information and processing modularisation. It builds on three software design concepts: abstraction, information hiding and modularity.
The notation invented by Grady Booch combines four distinct diagrams: a class diagram that depicts classes and their relationships; an object diagram shows specific instances of classes and the messages that pass between them; the module diagram illustrates the software components to which classes and objects are allocated; a process diagram depicts how processes are allocated to processors within the distributed processor system upon which the overall system executes.
This has subsequently been implemented in the UML (Unified Modelling Language). UML is a standard notation for modelling of real-world objects preparatory to developing an object-oriented design. Its notation is derived from three earlier object-oriented design and analysis methodologies:
When a detailed set of information regarding the input or output requirements of the required product is not available, then in order to clarify those requirements, a pilot model called a "prototype" is constructed. Prototypes allow the customer to experiment with the requirements and discover requirement errors and omissions early in the software development process. Other advantages of using this method are:
If a prototype system is implemented using the same tools as the final system, this can be very expensive. An argument against prototyping is that the cost of prototyping is very large compared to the total development cost, but since requirements and design decisions are clarified during the prototyping process, prototyping results in long-term savings.
In this type of prototyping, a working but incomplete system is delivered to the user. The developer is then employed in modifying it as the user's requirements become clear. It is the only realistic way to develop systems where it is difficult or impossible to establish a detailed system specification at the outset.
Some disadvantages to using this type of prototyping are:
This type of prototyping is used to discover the system specification so that the output of the prototype development is that (initially unknown) specification. The principal function of the prototype is to clarify requirements and provide additional information for assessing process risks. This approach substantially reduces overall lifecycle costs by not only saving the efforts in developing the final product but also the resources involved in the development of the final product. After evaluation, the prototype is thrown away. It is not used as a basis for further system development.
RAD is based upon the concept that products can be developed faster and of higher quality through: