Appendices
311
Appendix C
Essential Software Design
The examples provided below follow two different methodologies in design.
Example 1 is an object-oriented design using a UML approach, and Example 2
is a structural design approach.
Example 1: Essential Software Design—UML
Architectural Design A.
High-level architectural pattern: Layered, MVC, client server, and
so on. See Chapter 7.
Use-Case ScenariosB.
Expand the previous documentation of the initial use-case dia-
gram into use-case scenarios.
Sequence Diagrams (in concert with steps D and E)C.
The use-case scenarios developed in Step B would be developed
into the sequence diagram with the invention of the many classes
needed to support the action in the scenario. In parallel, the
class diagram begins to incorporate the classes invented in the
sequence diagram and the methods are added to the class dia-
gram as they are thought out by the team members.
Class DiagramD.
A class responsibility collaborator (CRC) model can also be devel-
oped.
91998_APPX_Tsui.indd 311 1/11/13 8:45:51 AM
Collaboration DiagramE.
When a class needs another class to perform a substep, those classes are
associated in the collaboration
Relational Database DesignF.
State Modeling (may be optional until detail design)G.
The major objects of the product are represented as the many states involved
with the state transitions for them.
User-Interface Design H.
Interaction screens are developed from the use cases. Navigation for the dif-
ferent screens are specified.
Design Validation—Customer Acceptance of the Low-Fidelity PrototypesI.
The initial screens drawings and navigational flow are presented to the cli-
ent or client’s specified user for acceptance, modification, and/or complete
revision.
NOTE: Steps C, D, and E are done in parallel.
Example 2: Essential Software Design—Structural
Architectural DesignA.
High-level architectural pattern: Layered, MVC, client server, and so on.
Context DiagramB.
This is the level 0 of the data flow diagram (DFD). It shows the system (with-
out decomposition) and the external entities. The system has flows of data to
the external entities. The scope of the product is defined with this diagram.
DFD Level 1C.
This diagram is the first decomposition of the entire system. Usually the pro-
cesses are numbered 1.0, 2.0, 3.0, and so on, and they are called subsystem.
For example:
1.0 Interface subsystem
2.0 Management subsystem
3.0 Error handling subsystem
4.0 XXX process subsystem
5.0 Report generator
DFD Level 2D.
These diagrams are the explosion of each of the subsystems in Level 1. Their
numbering will expand from their parent; so the Level 2 for 1.0 Interface
subsystem could be
1.1 Interface interaction
1.2 Input validations
1.3 Interface management
312 Appendices
91998_APPX_Tsui.indd 312 1/11/13 8:45:51 AM
DFD Level 3 to NE.
Continue to explode each of the processes into the next level.
Process Specification (PSPEC)F.
When a process does not need to explode, give the logic to the process.
Appendices 313
91998_APPX_Tsui.indd 313 1/11/13 8:45:51 AM
91998_APPX_Tsui.indd 314 1/11/13 8:45:51 AM
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.