Design Validation

1
Design Validation

• CSCI 5801 Software Engineering

2
Design Validation
3
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

4
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?

5
Best Tool Sequence Diagrams
6
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.

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

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

9
Cohesion and Coupling

• Cohesion A component/class should have one
  purpose
• Easier for single design team to implement,
  maintain
• CouplingDifferent components should have
  minimal communications
• Few public methods with few parameters
• Easier to implement/test interfaces
• Strong cohesion weak coupling modular design

10
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)

11
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

12
Registration Example
13
Registration Example

• Not cohesive
• Section information
• Section roster
• Too much coupling
• Section component must call course component for
  all information to display

Two different concepts used in two different
scenarios
14
Better Solution
15
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?

16
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?

17
Fault-Tolerant Design

• Prevent things from going horribly wrong
• Identify bad things that can happen
• Often involves data integrity/security
• Can assign degrees of risk to each
• Determine whether they can occur in present
  design
• If so, improve design to minimize risk

18
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

19
Fault-tolerant Design

• Can roster database be deleted? Yes
• Possible causes
• Database hacked through web
• Database server physically destroyed
• Design solutions

20
Fault-tolerant Design

• Can student records be read? Yes
• Possible causes
• Records stored in non-encrypted form
• Design solutions

21
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