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