INFO 425 Design Problem I

1. INFO 425Design Problem I Week 3 – SDS Improvements Glenn Booker INFO 425 Week 3

2. SDS • The SDS builds on the SRS • Everything in the SDS should tie to a requirement in the SRS • Remember to address non-functional requirements when discussing your design • See INFO 424 week 5 lecture notes for review of SDS diagram notation and development guidance INFO 425 Week 3

3. SDS sections • Introduction • Architectural Description – very high level • Interface Description • Detailed design of interface elements • Detailed Design • Here’s where your (ERD and DFD) or (class diagram and sequence diagrams) go • Detailed design of everything else INFO 425 Week 3

4. Architectural Description • Architectural Description • Component or context diagram, for examples • Detailed design can follow either approach • OO approach • Class diagram • Sequence diagram for features implemented this cycle (and previous cycles) • Traditional approach • DFD and ERD • Include narrative description for all design entities INFO 425 Week 3

5. Scope of diagrams • The class diagram, ERD, and DFD all pertain to the entire system in its final form (cycle 4+) • Sequence diagrams pertain to one use case • The diagram aspects affected by current and previous cycle implementation should be very detailed • Design traits of the rest of the system can be less detailed, and filled in during later cycles INFO 425 Week 3

6. Class Diagram • If you do a class diagram it should show class names, attributes, and methods • Make sure classes and methods from your sequence diagrams appear in the class diagram • Associations should show a label (verb phrase) and multiplicity • Ok to assume bidirectional for cycle 1 INFO 425 Week 3

7. Sequence diagrams • If you’re using the OO approach, you should show sequence diagrams for each use case implemented in your system (this cycle and previous ones) • Each sequence diagram should be based on a detailed description of what the actor and system are doing during the use case INFO 425 Week 3

8. Data Flow Diagram • Processes should connect clearly to the requirements in your SRS • In discussing your DFD, cite specific requirement identifiers or use cases they’re implementing • Continuity checks are critical - look for miracles and black holes then fix them INFO 425 Week 3

9. ERD • Entities should include • Attributes • Do not need to show attribute data types • Primary keys • Foreign keys (where applicable) • Relationships should have a verb phrase and cardinalities (0, 1, many) INFO 425 Week 3

10. Interface Description • User interface • Screen hierarchy diagram • Screen shots or layouts (Menus, etc.) go in section 4 • Data interface • Databases or files shared with other applications • Programming interface • Services provided to other programs (APIs) INFO 424 Week 5

11. Detailed Design • This section should give detailed descriptions of the system elements discussed in the Architectural Design diagrams AND diagrams in this section • Define the parts that make up your system • No need to repeat interface elements • “Entity” is a generic term for system parts • Includes class or sequence diagrams, DFD, ERD INFO 424 Week 5

12. Detailed Design • Type – tell what type of part • Class, Procedure, module, database or DB table, DFD process, etc. • Requirement – always and only refers to the SRS • This <entity> fulfills requirement 2.3 [or UC3] • Description • Describe the design – how does it work? • Don’t just repeat the requirement INFO 424 Week 5

13. No figure orphans! • Annotate • No diagram stands by itself • Provide a label; cite and discuss it in the body of the document • Integrate!! Consistency is critical! • Diagrams must agree with the rest of the document • Correct and complete use matters most • Particular diagram choice can vary INFO 425 Week 3