People and Teams Design

 For me ◦ Team meetings ◦ Next week’s demos  For client ◦ Your responsibility to schedule ◦ Can invite to next week’s presentation  My checkpoint with clients coming up

 A useful site (with thanks to Sam) ◦  For your amusement For your amusement

 People are primary  Goal-driven human processes are self- healing ◦ Rule-driven processes are fragile  Space ◦ Cave and Commons  Stewart Brand, How Buildings Learn  Public communication

 Forming - polite but untrusting  Storming - testing others  Norming - valuing other types  Performing - flexibility from trust  Adjourning - disengagement Tuckman, Bruce. (1965). Developmental sequence in small groups. Psychological bulletin, 63, Developmental sequence in small groups.

 Core Competency: problem-solving ability  Personal Attributes  Openness  Supportiveness  Action orientation  Positive personal style

 Constructive ◦ for all team members  Productive ◦ brings out the best thinking in all team members  Mutual Understanding ◦ seeking to understand others’ perspectives.  Self Corrective

 Focus ◦ clear about what you are doing  Climate ◦ positive ◦ inclusive ◦ focus on the issue…not the person  Open Communication ◦ Issues identified, ◦ discussed, ◦ prioritized ◦ and acted on

 Collaborator ◦ Works to find a solution that satisfies all concerns  Accomodator ◦ Neglects own concerns to satisfy others  Compromisor ◦ Tries to satisfy others without giving up own concerns  Competitor ◦ Pursues own concerns at other’s expense  Avoider ◦ Evades the situation and never addresses

 Larson and LaFasto ◦ Teamwork: What Must Go Right/What Can Go Wrong ◦ When Teams Work Best  Accumulated information from 600 teams

 Concept (contract, intro on web site)  Requirements (use cases, requirements)  Architecture  Design  Implementation  Unit test  Integration  System test  Maintenance

 Two types of documentation ◦ How the system fits together  Critical to understanding  Not easily captured in the code  External documentation required ◦ The details of the implementation  Captured in the code  Components:  Inline comments  Doxygen Doxygen

 Start with a picture of your architecture  What other models are needed? ◦ Data flow? ◦ Data model? ◦ State transition?  Key considerations ◦ What are the hard parts of the work? ◦ What are the critical areas?

 Build on well understood patterns from the system design  Goal is to prepare the project for implementation  Includes ◦ Module definitions ◦ Processes (if relevant) ◦ Data definitions ◦ Design decisions

A Little Structure…

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.

 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

 Benefits ◦ Simplicity of mapping  Drawbacks ◦ Later changes  No worse off then if not matched ◦ May be too early for implementation decisions

 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

 Want to identify ◦ Classes ◦ Attributes ◦ Functions

 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

 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

 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

 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

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

 Correctness  Robustness  Flexibility  Reusability  Efficiency

 Always a goal. Others may be negotiable.  Definition: satisfies all of the application’s requirements ◦ How do we know the requirements are correct?  Approaches ◦ Inspections  Readable (“I didn’t have time to write a short letter, so I wrote a long one instead.”)  Modular ◦ Formal verification  Invariants, pre- and post-conditions  Usually used only in critical components

 Ability to handle anomalous situations  Techniques ◦ Verifying input ◦ Initialization ◦ Parameter checking  Range  Constraints  Husk and kernel

 Guided missile cruiser that suffered widespread system failure off the coast of Virginia  Dead in the water for more than two hours  Crew member mistakenly entered a zero in a data field of an application ◦ Divide by zero ◦ Buffer overflow ◦ Shut down the propulsion system

 Requirements changes ◦ Adding more of the same function  New type of member, account, question or game ◦ Adding new type of function  Printing what was only displayed, withdrawing when only depositing was allowed, creating a new game ◦ Changing function  Allowing reverse as well as forward, overdraft protection

 Design issues ◦ Encapsulating things that may change ◦ Late binding ◦ Separation of instruction and data  Examples ◦ Layout of your interface ◦ Description of changeable data

 How to make it reusable ◦ Match real world concepts ◦ Avoid unnecessary coupling ◦ Document  Complete specification (assertions, constraints)  Explanation of function and algorithm ◦ Generic names