1. www.ischool.drexel.edu INFO 425 Week 31 INFO 425 Design Problem I Week 3 – SDS Improvements Glenn Booker

2. 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 32

3. 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 33

4. www.ischool.drexel.edu 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 34

5. 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 35

6. 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 36

7. 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 37

8. 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 38

9. 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 39

10. 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) 10INFO 424 Week 5

11. 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 11INFO 424 Week 5

12. 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 fulfills requirement 2.3 [or UC3] Description –Describe the design – how does it work? –Don’t just repeat the requirement 12INFO 424 Week 5

13. 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 313