info 425 design problem i

www.ischool.drexel.eduINFO 425 Week 3 1

INFO 425Design Problem I

Week 3 – SDS Improvements

Glenn Booker

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


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


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


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 cyclesINFO 425 Week 3 5


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


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


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


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


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


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


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

12INFO 424 Week 5


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

info 425 design problem i

Documents