Learn System Analyis and Design
Logical Design
   
Home
Logical Design
 
Conceptual Design

A conceptual design is an abstract or high level design which includes only the most important components and entities. The main goal of a conceptual design is to provide an understandable picture of the overall purpose of the proposed solution. Components may include major technology systems, external systems that are required for integration or overall functionality, high level data flow, and system functionality. Think of this as the "black box" diagram where portions of the diagram may be simply a technology component to-be-named-later but is identified with its role and purpose.
 
Logical Design
 
A logical design is a more detailed design which includes all major components and entities plus their relationships. The data flows and connections are detailed in this stage. The target audience is typically developers or other systems architects. However, it is possible to create logical designs for business purposes to ensure that all components and functionality is accounted and well understood. Logical designs do not include physical server names or addresses. They do include any business services, application names and details, and other relevant information for development purposes.
 
What is a Data Flow Diagram ?
 
Identifying the existing business processes, using a technique like data flow diagrams, is an essential step in Logical Design.
 
Data flow diagrams can be used to provide a clear representation of any business function. The technique starts with an overall picture of the business and continues by analyzing each of the functional areas of interest. This analysis can be carried out to precisely the level of detail required. The technique exploits a method called top-down expansion to conduct the analysis in a targeted way.
 
 


The result is a series of diagrams that represent the business activities in a way that is clear and easy to communicate. A business model comprises one or more data flow diagrams (also known as business process diagrams). Initially a context diagram is drawn, which is a simple representation of the entire system under investigation. This is followed by a level 1 diagram; which provides an overview of the major functional areas of the business.

Data Flow Diagrams – Diagram Notation There are five symbols that are used in the drawing of business process diagrams (data flow diagrams). 

 

This diagram represents a banking process, which maintains customer accounts. In this example, customers can withdraw or deposit cash, request information about their account or update their account details. The five different symbols used in this example represent the full set of symbols required to draw any business process diagram.

External Entity

An external entity is a source or destination of a data flow which is outside the area of study. Only those entities which originate or receive data are represented on a business process diagram. The symbol used is an oval containing a meaningful and unique identifier.

Process

A process shows a transformation or manipulation of data flows within the system. The symbol used is a rectangular box which contains 3 descriptive elements: Firstly an identification number appears in the upper left hand corner. This is allocated arbitrarily at the top level and serves as a unique reference. Secondly, a location appears to the right of the identifier and describes where in the system the process takes place. This may, for example, be a department or a piece of hardware. Finally, a descriptive title is placed in the centre of the box. This should be a simple imperative sentence with a specific verb, for example 'maintain customer records'.

Data Flow

A data flow shows the flow of information from its source to its destination. A data flow is represented by a line, with arrowheads showing the direction of flow. Information always flows to or from a process and may be written, verbal or electronic. Each data flow may be referenced by the processes or data stores at its head and tail, or by a description of its contents.

Data Store

A data store is a holding place for information within the system: It is represented by an open ended narrow rectangle. Data stores may be long-term files such as sales ledgers, or may be short-term accumulations: for example batches of documents that are waiting to be processed. Each data store should be given a reference followed by an arbitrary number.

Data Flow Diagrams – The Rules

External Entities :- It is normal for all the information represented within a system to have been obtained from, and/or to be passed onto, an external source or recipient. These external entities may be duplicated on a diagram, to avoid crossing data flow lines.

Processes :-  When naming processes, avoid glossing over them, without really understanding their role. Indications that this has been done are the use of vague terms in the descriptive title area - like 'process' or 'update'. The most important thing to remember is that the description must be meaningful to whoever will be using the diagram.

Data Flows :- Double headed arrows can be used (to show two-way flows) on all but bottom level diagrams. Furthermore, in common with most of the other symbols used, a data flow at a particular level of a diagram may be decomposed to multiple data flows at lower levels.

Data Stores :- Each store should be given a reference letter, followed by an arbitrary number. These reference letters are allocated as follows:

'D' - indicates a permanent computer file
'M' - indicates a manual file
'T' - indicates a transient store, one that is deleted after processing.

Data Flows - Rules

Data flows and resource flows are allowed between external entities and processes. Data flows are also allowed between different external entities. However, data flows and resource flows are not allowed between external entities and data stores.

Processes - Rules

Data flows and resource flows are allowed between processes and external entities and between processes and data stores. They are also allowed between different processes. In other words processes can communicate with all other areas of the business process diagram.

Data stores  - Rules 

Data flows and resource flows are allowed between data stores and processes. However, these flows are not allowed between data stores and external entities or between one data store and another. In practice this means that data stores cannot initiate a communication of information, they require a process to do this.

Data Flow Diagrams – Context Diagrams

The context diagram represents the entire system under investigation. This diagram should be drawn first, and used to clarify and agree the scope of the investigation.

The context diagram clearly shows the interfaces between the system under investigation and the external entities with which it communicates. Therefore, whilst it is often conceptually trivial, a context diagram serves to focus attention on the system boundary and can help in clarifying the precise scope of the analysis.

 

The context diagram shown on this screen represents a book lending library. The library receives details of books, and orders books from one or more book suppliers. Books may be reserved and borrowed by members of the public, who are required to give a borrower number. The library will notify borrowers when a reserved book becomes available or when a borrowed book becomes overdue. In addition to supplying books, a book supplier will furnish details of specific books in response to library enquiries. Note, that communications involving external entities are only included where they involve the 'system' process. Whilst a book supplier would communicate with various agencies, for example, publishers and other suppliers - these data flow are remote from the 'system' process and so this is not included on the context diagram.

Data Flow Diagrams – Level 1 Diagrams High Level Diagram

 
 
The level 1 diagram shows the main functional areas of the system under investigation. As with the context diagram, any system under investigation should be represented by only one level 1 diagram. There is no formula that can be applied in deciding what is, and what is not, a level 1 process. Level 1 processes should describe only the main functional areas of the system, and you should avoid the temptation of including lower level processes on this diagram. As a general rule no business process diagram should contain more than 12 process boxes. The level 1 diagram is surrounded by the outline of a process box that represents the boundaries of the system. Because the level 1 diagram depicts the whole of the system under investigation, it can be difficult to know where to start.

 Low Level Diagram

This level is a decomposition of a process shown in a level-1 diagram, as such there should be a level-2 diagram for each and every process shown in a level-1 diagram. In this example processes 1.1, 1.2 & 1.3 are all children of process 1, together they wholly and completely describe process 1, and combined must perform the full capacity of this parent process. As before, a level-2 diagram must be balanced with its parent level-1 diagram

 

 

 

 
 
   
All rights reserved