Design Validation CSCI 5801: Software Engineering

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

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

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: