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 ScenarioDescription: • 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

• Too much coupling– Section component must call course component

for all information to display

Two different conceptsused 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: