Author: Sanjay Goel, http://in.linkedin.com/in/sgoel
In 2003, I introduced a simple design notation for undergraduate data structures course. It evolved over the years. Since 2003, this notation for conceptual modelling of software has been deployed in various data structures, advanced data structures , oops, and software engineering classes at JIIT. Many students and faculty members have found this very useful for developing software design thinking. It can be used as a supplement to existing standard UML notations.
In this notation, the sofware is conceived as a system of interconnected data-tanks through data pipes. The type and events of data flow among these tanks is controlled by the conditions and constraints. This notation provides a bird’s-eye view of a collection of interacting and collaborating data tanks and data items.
Please do not mix or confuse this concept mapping technique with any other diagramming technique like DFD or ER diagram and so on. There may be some similarities with some, but this notation is essentially very different.
1. Look at each collection of homogeneous (similarly structured) data items as a Data tank. These individual data items could be atomic or compound.
2. Identify the nouns and verbs of the systems description. Some nouns will become data tanks in Concept Map (CM). The nouns could be singular as well as plural. Verbs will represent the processing box in CM.
3. This Concept map is a diagram of inter-connected data tanks via processing units with boxes and arrows, marked labeled. It gives an indication of what, when, and how some data moves or changes in any data tank.
4. Write the properties and functional behavior for each data tank by giving a clear description of the content, and also permitted legal operations on each data tank and data item. This collection may or may not require some inter-data item organizational constraints.
5. Use double line boxes for data tanks containing several homogeneous data items, and single line boxes for single data item/packets, if any. Classify the data tanks in the following categories:
a. Input data: Add downward arrow above the top side of data box.
b. Output data: Add upward arrow above the top side of data box.
c. I/O data: Add downward & upward arrow above the top side of data box.
d. Processing data: No arrow above the top side of data box.
6. Name your data tanks as a set of … (e.g. set of trains, set of passengers, set of books, set of users, and so on) that contains many homogeneous items only.
7. Put the name of the data that flows in/out of data tanks.
8. Show Data copy transfer: directed links between data boxes.
9. Use elliptical boxes to show processing of chosen data items. Name your processing units as verbs, only representing the process.
10. Put a small circle on the top right corner of data tank boxes, if it represents dynamic data, i.e., the data can change as a result of valid operations.
11. Put a circle on the top left corner, if the data population size can change during processing because of insertions and deletions. This dynamic data (at 10 and 11) is not to be confused with dynamic data structure, as this higher-level of dynamism can be implemented with dynamic or static data structures at lower layer.
12. Draw four dotted horizontal lines and divide data tank into five sub-boxes.
13. Put the name of data tanks in the top (first) sub-box and give some examples of representative data items in the same sub-box. Mention the expected range of number of data items in the data tank.
14. Write the attributes (fields) in the second sub-box. First put, and also underline, the attribute(s) that are required to have unique values, e.g., ID No., etc. Mention the attribute constraints, if any.
15. Identify all the operations that are required to be performed on this data tank during the lifetime of a given application. Write these operations in the third sub-box. Mention the preconditions and post-conditions for each operation. Also mention the expected frequency for each operation.
16. If the data tank has limited life during processing, write the scope of the data tank in the fourth sub-box. Mention the event(s) that brings this tank to existence, or remove it from the systems using created on and destroyed on clauses.
17. If your data tank is compound, i.e., you need some additional ancillary and smaller data tanks (e.g., indices, and so on) to support efficient searching of appropriate data items in the principal data tank, include the names of these ancillary data tanks in the first sub-boxof the principal data tank itself by dividing the first box into two units by a vertical line, and list the names of ancillary tanks in the right half of first sub-box.
18. Later on, expand this compound data tank into a principal data tank inter-connected with ancillary data tanks in a different diagram.
19. Name your ancillary data tanks using the name of the principal data tank, followed by an underscore, and then by another plural noun, e.g., the ancillary data tanks for data tank ‘trains’ could be named as ‘set of trains_train-nos,’ ‘set of trains_destinations,’ and so on.
20. Vertically divide the fifth box into two parts.
21. See if the data tank is required to maintain some order on the elements or not. If no order is required, leave the fifth left and fifth right sub-boxes empty.
22. Check the type of order – Is it ordered chronologically, i.e., based on the time of insertion of records or ordered on attribute(s)/value(s). Also check if you need ascending or descending order. If ordered on value, identify the attribute(s) that control the order of records.
23. If ordered on time, then put ‘T’ in the top left corner of the fifth left sub-box, if the tank is ordered on time. Put an upward arrow for ascending order; put a downward arrow for descending order. If ordered on value, put ‘V’ and the attribute followed by appropriate arrow.
24. If the data tank is an ordered collection of X, see how the relative position of a specific data item is defined with respect to other similar data items. Indicate it in the fifth left sub-box. Some possible arrangements are as follows:
a. ——–> X (1:1) ——–>
b. ——–> X (1:n) ——–>
c. ——–> X (n:1) ——–>
d. ——–> X (m:n) ——–>
25. Relative position could be in terms of order of insertion or relative value of some data item.
26. Examine relative positional eligibility for accessing: All/only some strategic relative positions.
27. Examine relative positional eligibility for updation: All/None/only some strategic relative positions.
28. Examine relative positional eligibility for insertion: Any empty slot/only some strategic relative positions.
29. Examine relative positional eligibility for deletion: All/None/only some strategic positions.
30. If access, updation, insertion, and deletion are dependent on some well-defined strategic relative position within the data tank, observe, identify and define these positions. Indicate these positions in the fifth right sub-box. Some examples of strategic relative positions can be as follows:
a. Based on order of insertion: earliest, latest, after the latest insertion, before the earliest insertion, 3rd earliest, 4th latest, next relative to the current position as per insertion order, previous relative to the current position as per insertion order, and so on.
b. Based on the value: minimum, maximum, 3rd minimum in between a given range of values, in between an appropriate range of values, and so on
31. Your concept map should be hierarchical, i.e., it should gradually show more details in different diagrams rather than showing all the details in one diagram. Initially focus on the most critical aspects.
32. All the data tanks that have same abstractions of operations, ordering, strategic positions, pre-conditions, and post-conditions belong to same Abstract Data Type, e.g., stacks, queue, all binary tree, graph, table, data cube, octree, etc. (can be extended to the notion of ‘Class’).
If I recall correctly, the word ‘Data tank’ was used in 2003 by a 2nd year student, Abhishek Chauhan (2006 graduate).