Design 15 February

Software Engineering: Elaborated Steps Concept (contract, intro on web site) Requirements (use cases, requirements) Architecture Design Implementation Unit test Integration System test Maintenance

System Design Patterns Model-View-Controller Data flow systems Pipes and filters Batch sequential Independent components Client-server Parallel communicating processes Event systems Virtual machines Interpreters Rule-based systems Repositories Databases Hypertext systems Layered architectures

Layered Architecture Role-playing game layer Characters LayoutRolePlayingGame Encounter Characters Encounter Environment Encounter Game Application layer 3D engine layer «uses» Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Coherent collection of software artifacts, typically a package of classes

Documenting Your Design Two types of documentation The details of the implementation Less important Captured in the code Components: Inline comments Doxygen How the system fits together Critical to understanding Not easily captured in the code External documentation required

Think About How would you describe the work? What is the first picture that you will draw? That is probably the architecture How to proceed Pick a general model Specialize it to your project Draw the picture One of the few places that I REALLY want a picture

Next Step What other models are needed? Data flow? Data model? Almost always needed State transition? Key considerations What are the hard parts of the work? What are the critical areas?

Examples If you are in a repository model, the data model is probably key If you are building a complex game, the state transitions may be critical

Team Exercise (10 minutes) Draw your system design Report Out

Detailed Design Build on well understood patterns from the system design Goal is to prepare the project for implementation

What does it include? System design decomposition Modules Processes Data Detailed module definitions Detailed data definitions Design decisions

From System to Detailed Design

Relating Use Cases, System & Detailed Design 1.Use case3. System Design2. Domain classes 4. Detailed Design Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Domain Classes Object-oriented paradigm, not implementation Domain = application specific Classes defined in natural language Used to explain the architecture and design Classes derived from the requirements Need not match the implementation Hard to not fall into that trap

Domain Classes Matching Implementation Classes Benefits Simplicity of mapping Drawbacks Later changes No worse off then if not matched May be too early for implementation decisions

Defining Domain Classes Begin with Use Cases Identify nouns External agents are not domain classes Are these key classes for the application? Are there others? Identify attributes and functionality for each class Validate Walkthrough use cases Try changes and extensions Look for Missing attributes or functions Changes that reach every where

Bridge Example 1.Use case3. Architecture2. Domain classes 4. Detailed Design Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. “Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.” Auto Road

Class exercise: teacher portal Want to identify Classes Attributes Functions

Use Cases for a Teacher Portal teacher presented with view with his content read messages from other teachers and administrators schedule an assessment selects class selects test based on difficulty and subject create new test create new question type of question introductory text possible answers correct answer edit existing question edit full test post message content recipient view class content Classes Attributes Functions

Use Cases for a Teacher Portal teacher presented with view with his content read messages from other teachers and administrators schedule an assessment selects class selects test based on difficulty and subject create new test create new question type of question introductory text possible answers correct answer edit existing question edit full test post message content recipient view class content Classes Attributes Functions

Use Cases for a Teacher Portal teacher presented with view with his content read messages from other teachers and administrators schedule an assessment selects class selects test based on difficulty and subject create new test create new question type of question introductory text possible answers correct answer edit existing question edit full test post message content recipient view class content Classes Attributes Functions

Use Cases for a Teacher Portal teacher presented with view with his content read messages from other teachers and administrators schedule an assessment selects class selects test based on difficulty and subject create new test create new question type of question introductory text possible answers correct answer edit existing question edit full test post message content recipient view class content Classes Attributes Functions

Back to Detailed Design What are we starting with? Domain classes System design models Use cases What do we need to do? Define implementation classes that realize the domain classes within the architecture framework and implement the functions defined in the use cases

Bridge Example Completed 1. Use case “Cars should be able to travel from the top of Smith Hill at 65 mph, travel in a straight line, and arrive at Jones Hollow within 3 minutes.” 3. System Design 2. Domain classes Auto Road Auto Road 4. Detailed Design Smith Hill Cable Jones Hollow Cable Pylon Guardrail Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.