INFO 425 Design Problem I Week 3 – SDS Improvements Glenn Booker INFO 425 Week 3 www.ischool.drexel.edu.
Download ReportTranscript INFO 425 Design Problem I Week 3 – SDS Improvements Glenn Booker INFO 425 Week 3 www.ischool.drexel.edu.
INFO 425 Design Problem I Week 3 – SDS Improvements Glenn Booker INFO 425 Week 3 1 www.ischool.drexel.edu 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 2 www.ischool.drexel.edu 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 3 www.ischool.drexel.edu 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 4 www.ischool.drexel.edu 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 5 www.ischool.drexel.edu 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 6 www.ischool.drexel.edu 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 7 www.ischool.drexel.edu 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 8 www.ischool.drexel.edu 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 9 www.ischool.drexel.edu 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 10 www.ischool.drexel.edu 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 11 www.ischool.drexel.edu 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 12 www.ischool.drexel.edu 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 13 www.ischool.drexel.edu