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

Download Report

Transcript 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