Transcript Design Validation - YSU Computer Science & Information Systems

Design Validation
CSCI 5801: Software Engineering
Design Validation
Design Validation
• Does design match requirements?
– Are there components/objects/methods for each
step in scenarios?
– Are all nonfunctional requirements addressed?
• Is design “good”?
– Maximal cohesion within a component/class
– Minimal coupling between components/classes
– Maximum fault tolerance
Design Walkthroughs
• For each scenario in requirements, walk
through step by step
– Is there component for each step?
– Does that component have a method in its API for
the previous component to call? Is needed
information passed/returned?
– Does each component store the correct data to
perform its role in this scenario?
– Are there components/methods for each of the
exceptions that might occur?
Best Tool: Sequence Diagrams
Example Scenario
Add Scenario
Description:
• A student adds a course by entering a course number
and selecting a section.
Initial Assumption:
• Student has logged in and navigated to ADD screen,
and has selected a course to add.
Example Scenario
Normal Steps:
• System populates dropdown list of courses.
• Student selects a course from the list.
• A drop down with open sections (including their
times) is populated.
• The student selects on and presses ADD.
• The student is added to the course roster.
• An acknowledgement of the add is displayed.
• The student may add more courses, or exit to th
main menu.
Example Scenario
Exceptions:
• All sections of the selected course may be closed, in
which case a message is popped up instead of the
drop down being populated.
• The course may be closed before the student presses
ADD, due to other students adding, in which case a
message is displayed and the list of open sections
displayed again.
System State upon Completion:
• The student ID is added to the roster of the section
chosen.
Cohesion and Coupling
• Cohesion:
A component/class should have one purpose
– Easier for single design team to implement, maintain
• Coupling:
Different components should have minimal
communications
– Few public methods with few parameters
– Easier to implement/test interfaces
• Strong cohesion + weak coupling = modular design
Some Types of Cohesion
• Data cohesion
– Component has all responsibility for single major piece of data
– Example: All access to class roster
• Functional cohesion
– Component contains related functions
– Example: Math library
• Procedural cohesion
– Component handles all steps in single process
– Example: Payment component for registration handles all
billing steps (parking fees, billing info, payment…)
Some Types of Cohesion
• Communicational cohesion
– Component handles all access to external entity
– Example: InventoryDB component handles all communication
to Course Inventory, using SQL
• Temporal cohesion
– Component contains all code for specific stage of system
– Example: Startup module creates and links all components,
loads data from files
Registration Example
Registration Example
• Not cohesive
– Section information
– Section roster
Two different concepts
used in two different
scenarios
• Too much coupling
– Section component must call course component
for all information to display
Better Solution
Desired Non-functional Attributes
• Maintainability
– How hard will it be to make anticipated changes?
• Performance
– Can the scale to higher loads if necessary with minor
design changes (i.e, more servers)?
• Testability
– Can requirements be tested at component level?
– Can automated testing be used?
• Traceability
– Is this component related to some scenario in the
requirements?
Desired Non-functional Attributes
• Flexibility
– How easily can the system adapt to unusual conditions?
• Portability
– Could you get the system to run on a new platform?
• Reusability
– What parts of the system could you use in a new system?
• Interoperability
– Can the system talk to other relevant systems?
Fault-Tolerant Design
• Prevent things from going “horribly wrong”
1. Identify “bad things” that can happen
– Often involves data integrity/security
– Can assign degrees of risk to each
2. Determine whether they can occur in present
design
3. If so, improve design to minimize risk
Fault-tolerant Design
• Examples from registration system:
– Can roster database be deleted?
• High risk!
– Can intruder read files (in violation of FERPA)?
• Medium risk
– Can a student add a course but not be added to
the roster?
• Lower risk
Fault-tolerant Design
• Can roster database be deleted? Yes
• Possible causes:
– Database hacked through web
– Database server physically destroyed
• Design solutions:
Fault-tolerant Design
• Can student records be read? Yes
• Possible causes:
– Records stored in non-encrypted form
• Design solutions:
Fault-tolerant Design
• Can student add course but not be added to roster? Yes
• Possible causes:
– Database server crashes before updated with new course
• Design solutions: