You will be preparing an SDS for this class I have designed a template (SDS below) that is suitable. It is not dissimilar to those used in practice.
. . . . . . . . . ( end of section Front sheet) <<Contents | End>>
. . . . . . . . . ( end of section Second Sheet) <<Contents | End>>
. . . . . . . . . ( end of section Executive Summary) <<Contents | End>>
You must include level 1 DFD expanding any level 0 process that is too big to be a single program. [ a4.html ]
You may include narratives, activity diagrams/flowcharts, ... describing any complex and/or interesting processes.
All data (flows and stores) should be named with names from the ERD. There must not be a store called "Data Base"!
Entity Relationship diagram -- -- --(ERD)
[ d3.html ]
Brief descriptions of two or three most interesting use cases.
You can include casual or fully-dressed uses cases for any really critical use case (one that needs to be done first to mitigate risks, for example).
In what sequence are the various use cases to be programmed? Why? How? When? Who?
. . . . . . . . . ( end of section Project 5 Deliverable -- Systems Design Specification) <<Contents | End>>
A small change to a system might be planned in hours and implemented soon after. For example, I change the software that runs my web site every week and typically an iteration takes less than two hours (if all goes well). A colleague spends several days talking about the problems and possible solutions in his compiler and run-time system before he implements them. This often takes a week chasing obscure bugs. Changing the look and feel of my web site to Web 2.0 started in Spring 2009 and is continuing as I write.
Large changes need more time to plan. The delay increases the risk of failure significantly. The system requirements change as you do the analysis and design.
My personal thought is that if the system takes longer than a few months to design (before starting to code) then it should be broken down into a series of small changes that can be done in one or two month cycles.
For example. The deployment diagram may show the need for a new web server that runs a LAMP stack. The implementation plan will show that you have to buy this first and then install and test the platform. An alternate plan would be to take a desktop machine from a redundant employee, move it to the server room, rip out Windows Vista and install LAMP.... A third plan, you tap a grant making body to finance a blade with an educational discount... and ask for the cost of the Windows installation back.
The deployment diagram describes the goal and the implementation plan shows the journey to the goal.
These days every body works bottom up -- unit tests first, integration tests as higher level modules are developed, acceptance tests of the system last. [ c2.html#Testing ]
However, you can argue that the popular "Test driven Development" is top-down in the sense that you write main programs to unit test modules before you write the modules.
DFDs are used to analyse and design systems. They show the dynamics: how data flows through the system from external entities, through processes, in and out of data stores, and out to external entities. DFDs do not show the structure of data. They must have a store called "Data Base"!
The two kinds of diagram are linked in that the data processed and stored in the DFD should be analysed and designed using an ERD.
You should, in theory, develop DFDs and ERDs in parallel -- but in practice you decide which to work on by what is most needed: clarify the structure of the data or the processing of the data.
Second there are Physical and Logical DFDs. A Physical DFD shows the implementation of the data flows and stores. For example it mentions forms, packets, signals, etc. A Physical DFD may also mention physical details of the processing: "stick stamp on envelope". A logical DFD is more abstract and merely names the data types -- not how they are encoded or manifested.
Finally there are "context DFDs", "Level 0 DFDs", "Level 1 DFDs", ... A context DFD has one process (typically numbered "0") surrounded by external entities. A level 0 DFD gives details of the processes and data inside the process of the context diagram. A Level 1 DFD takes one process in a level 0 DFD and expands it to show more internal processes and data. Similarly, each level 2 DFD expands a single level 1 DFD process.
It is easier to understand leveled DFDs if you use (1) Fish-eye diagrams and (2) number the processes. A fish eye diagram shows the details inside a large process symbol with the same number and name. It shows the components that are connected to the expanded process out side. The numbering is: Process 0 is the process in the context diagram, Processes 1,2,3,4,..... are processes in the level-0 DFD of Process 0. Process 1.2 is a process inside process 1 (inside process 0)... 126.96.36.199 is a process in a level 3 process....
Here is a figure showing how successive levels work:
(Note: I've used numbers rather than names to save space).
Here is a pair of DFDs describing the way we used to handle bills, checks, and bank statements when the bank returned checks to us
Later I will show you how I changed the system when the banked stopped sending us the checks with the statement.
You can also go back to [ a4.html ] for another example of leveled DFDs.
A good place to start a conceptual data model -- an ERD -- is with a list of the data stores in the DFDs. The ideal is for each store to hold a single type of entity and for this entity to have the same name in the ERD. The DFD shows how data moves and is processed. The ERD shows how it is structured.
Each name of a data store is the name of an entity in the ERD. The ERD will probably have extra "linking" entities and lots of relationships that do not appear on a DFD. Notice that only data stores should appear in the ERD. Processes do not appear on the ERD unless they depend on the existence of a secondary key, index, or operational master so that they can efficiently retrieve a subset of the entities of a given type. A classic example is making it easy to scan a college's database for candidates for a deans list, or for department honor's. This means searching in the Student table for large GPAs. You can instruct most DBMSs to keep an index of Student by GPA and so to make it quick and easy to extract the best students. Indeed such an index could also be used to find students who are having problems.
External entities do not appear on the ERD unless there is a data store that stores information about them.
There is another subtle link between ERDs and processes. A process will use the links in the ERD to move from entity type to entity type to compute its outputs from its inputs. It may also create and delete instances of relations between entities in the ERD.
Here is a case study starting from a Physical context DFD and level 0 DFD to a first physical ERD for the way we pay bills in my household after the banks stopped sending us the cancelled checks. This removes a useful data flow. Now we have to keep a memoranda of every check....
Also note: if your ERD entities don't have the same names as your data stores then you will need to document which Entities are in each store.
The worst smell (to my mind) is a system that sends data out to a user who must re-input into another process. This wastes user time and introduces a source of error and abuse.
You can go further within the UML by marking prime keys <<PK>> and foreign keys <<FK>> and following the usual 1NF, 2NF, 3NF sequence. However I find it quicker to do this outside the UML, and to draw the UML diagram later.
Example: the software sorts 3 million records successfully -- we say the software is functional. But if it takes 2 hours to do it and the user needs the sorted data in 2 minutes then the software fails a non-functional requirement.
High level nonfunctional requirements are typically adverbs. Examples: Securely, user-friendly, reliably, ... . They apply a constraint to functional requirements. They describe the qualities of the software. The non-functional requirements often determine the architecture.
You should always analyze high level requirements into low-level details. Functional requirements are probably best refined as use cases and nonfunctional as acceptance tests. Example: "In 99.9% of tests 3M items are sorted in less than 2 minutes", is a partial low-level specification of the high level non-functional requirement: "fast".
Use cases place requirements in context -- grouped around the users -- what they want to do and how well it needs to be done.
The detailed formats/templates for use-cases make sure you don't miss any important details that are show-stoppers.
These scenarios are the basis for designing software to help the user get what they want. They describe the main program directly. In CSCI375 we will learn how they also define the objects and classes needed to support the main program.
. . . . . . . . . ( end of section Online Resources) <<Contents | End>> on them to review them -- good luck!
|Name||Purpose||Form (diagram or text)||Includes||Excludes|
|scenario||list steps||text||steps, sequence, repetition||choices, parallelism|
|symbolic logic/math||show rules||text||formulas||actions, goals, choices, sequences|
. . . . . . . . . ( end of section Review Questions) <<Contents | End>>
. . . . . . . . . ( end of section System Specification and System Design) <<Contents | End>>
Notes -- Analysis [ a1.html ] [ a2.html ] [ a3.html ] [ a4.html ] [ a5.html ] -- Choices [ c1.html ] [ c2.html ] [ c3.html ] -- Data [ d1.html ] [ d2.html ] [ d3.html ] [ d4.html ] -- Rules [ r1.html ] [ r2.html ] [ r3.html ]
Projects [ project1.html ] [ project2.html ] [ project3.html ] [ project4.html ] [ project5.html ] [ projects.html ]
Field Trips [ F1.html ] [ F2.html ] [ F3.html ]
[ about.html ] [ index.html ] [ schedule.html ] [ syllabus.html ] [ readings.html ] [ review.html ] [ glossary.html ] [ contact.html ] [ grading/ ]