Week 8 Implementation Design Alex Baker Implementation Design
Week 8 Implementation Design Alex Baker
Implementation Design l System Design – l Describes what the system should do Implementation Design – Describes what the implementer should do Implementation System Design CGprofile vertex. Profile = cg. D 3 D 9 Get. Latest. Vertex. Profile(); const char *vertex. Options[] = {cg. D 3 D 9 Get. Optimal. Options( vertex. Profile ), NULL, }; const char* vertex. Options[] = {"-profileopts", "dcls", NULL, };
Implementation Design l System Design – l Describes what the system should do Implementation Design – Describes what the implementer should do Given what our system design tells us: What’s our plan?
Motivation: Why Bother with Implementation Design? l Suppose we code an object-oriented program – – l 16 implementers No Implementation Design What problems might arise?
Motivation: Why Bother with Implementation Design? l Suppose we code an object-oriented program – – l 16 implementers No Implementation Design What problems might arise? – – – Poorly chosen classes Multiple people on the same code Functionality in hidden, or multiple, places Inefficiencies and interaction problems emerge Bad match to the system design No common vision
3 Goals of Implementation Design l Provide a shared plan to follow – l Ensure the plan meets its recipients’ needs – l Consistency Helpfulness Ensure the solution is appropriate – Effectiveness
Goal: Consistency l As we mentioned in week 6, our audience is: – – – system designers implementation designers themselves programmers testers …
Goal: Consistency l As we mentioned in week 6, our audience is: – – – system designers implementation designers themselves programmers testers …
Goal: Consistency l As we mentioned in week 6, our audience is: – – – system designers implementation designers themselves programmers testers … Communication
Goal: Consistency l Ensuring implementers have the same plan – Every design is a plan, to some extent…
Goal: Consistency l Ensuring implementers have the same plan – Every design is a plan, to some extent…
Goal: Consistency l Ensuring implementers have the same plan – Every design is a plan, to some extent…
Goal: Consistency l Ensuring implementers have the same plan – Every design is a plan, to some extent…
Goal: Consistency l Ensuring implementers have the same plan – l Every design is a plan, to some extent… Division of Labor – – Separate parts to work on Ensuring they work together
Goal: Consistency l Ensuring implementers have the same plan – l Division of Labor – – l Every design is a plan, to some extent… Separate parts to work on Ensuring they work together A common vision (Ideas) – Will the developers “guesses” coincide?
Goal: Consistency
Communication isn’t enough l A good representation is important l What if we just communicate really well? – – l Some problems can’t be seen along the way Implementation design is a bird’s eye view Need a plan that… – – Supports the key work Will lead to an effective product upon completion
Role of the Implementation Design l As we mentioned in week 6, our audience is: – – – system designers implementation designers themselves programmers testers Reflective Conversation … with Materials
3 Goals of Implementation Design l Provide a shared plan to follow – l Ensure the plan meets its recipients’ needs – l Consistency Helpfulness Ensure the solution is appropriate – Effectiveness
Goals: Helpfulness l In a way, the implementer is our customer! l What are the implementer’s needs?
The Implementers’ Needs l Implementers must – Create code – Modify code – Reuse code
The Implementers’ Needs l Implementers must – Create code l – Modify code l – How can you find it? What else will it effect? Reuse code l l Subtle connections must be adjusted for How can you integrate new code? Reuse this code? The difficulty is in the interconnectivity
Spaghetti vs. The Ideal Program vs. …
Goals: High-Quality Implementation l Reducing interdependency (Low Coupling) – – – l Grouping functionality (High Cohesion) – – l Proper cooperation easier to maintain Changes don’t propagate Reuse is facilitated Easier to find things Metaphor guides decisions Both aid in dividing work
Design Notations l Assuming we have a supportive plan… – – How do we present it? What representation will we use? Class Diagrams l Interface specifications l Textual Descriptions l Sequence Diagrams l Data Flow Diagrams l Petri Nets + any of the notations from system design l
Design Notations l Each has its advantages and disadvantages l Diagrams can – – Help deal with complexity, abstract, give the big picture Visualize the invisible: code objects, interactions, timing, etc. l Text can explain l Depends on the needs of the system too…
Goal: Helpfulness l When designing, we must recognize the difficult work we are describing l A design must help implementers keep complexity under control l We must:
Goal: Helpfulness l When designing, we must recognize the difficult work we are describing l A design must help implementers keep complexity under control l We must: – provide a plan that meets implementers’ needs – present the plan in a way that the implementers can understand
3 Goals of Implementation Design l Provide a shared plan to follow – l Ensure the plan meets its recipients’ needs – l Consistency Helpfulness Ensure the solution is appropriate – Effectiveness
What makes a design effective? l Quality of Service Security Reliability Scalability Portability Minimal Hardware Requirements l Also still maintainability, testability, reusability l Remember your system design! l l l
Getting down to Business l Existing notations may suit your needs – Created with existing wisdom – Will be more familiar to your implementers
The Class Diagram
The Class Diagram Again: • Implementers must code, maintain, reuse • System’s needs
The Class Diagram Again: • Implementers must code, maintain, reuse • System’s needs l But what classes do I need? – – – System design provides hints Requirements’ emphasis can set priorities What parts are likely to change or be reused? l l Carefully apply information hiding Create classes with “secrets”
Context may also guide classes l Frames which classes to use l Suggests I/O, interfaces, places for converters
Further Existing Wisdom l Patterns provide insight into common issues l More next week…
Data Flow Diagrams l A more active depiction of the system 1. Context 2. Internal Processes
Sequence Diagrams l Can describe usage scenarios – Might be especially useful in some games… l Logic of services and transactions l Can suggest classes and methods
Sequence Diagrams & Communication
Petri Nets l Maybe communication is very dicey – A distributed system with concurrent processes l Petri nets are a notation designed for this l Not as common, but can be useful
User Interface Specification l l Could spend a whole year on it… May use existing components – – This will guide what is possible Needs to be determined early in some cases
User Interface Specification
User Interface Specification l Can explain: – UI layout itself, but… – Intended functionality User experience Simple sequences – – – Can imply specific implementation, given a particular API
Or something else entirely… l Overhead of learning
Summary l Must create an effective plan for implementers l And ensure they can readily – – – Create code Change code Reuse code l Must consider the system design’s needs l A tricky balancing act…
Implementation Design in Context Domain of Materials Domain of Use Representation Knowledge Ideas Activity Goal concern manipulates informs captures enhances
Next week l Specific Domain wisdom about tackling software design problems l Some walkthroughs l Implementation design drafts due Thusday
- Slides: 47