26 February Humpty Dumpty Presentations Software Architecture cont
26 February Humpty Dumpty Presentations Software Architecture (cont)
If Programmers Had to Build Planes n http: //www. flixxy. com/if-programmers-had-to-buildplanes. htm
Humpty Dumpty Considerations n n n How far behind are the other two parts? Need for testing with one-of-akind hardware How closely related are the parts? Don’t underestimate your predecessor Use industry terminology Testing models Suggestions n n n n n Short checkpoints Inspections or reviews Tools, esp. testing Available software packages Common utilities Requirements review and reprioritization Protecting teams Chief designer Formal vs. informal channels
Midterm Presentations: Purpose n You don’t understand something until you’ve taught it n n n Facilitate sharing n n Clarification of your thought process and understanding Sharpen your understanding of the project Learn from each other Practice presenting
Midterm Presentations: Logistics n March 4 and 6 n n n 10 minute presentations (excluding set up) Copies of charts to be posted on website n n Assignments now Email me attachment or link Full attendance is expected
Presentations: The Basics n n n Speak loudly and clearly Stand up No chewing gum when speaking Speak, don’t read: you ARE the experts Practice, practice Set up and test demos and laptops early – and again the day you present
Presentations Hints n n n Cover all topics, but they don’t need equal time! Focus on what’s special about your project Don’t try to cover too much Keep it light (8 other presentations!) Give the audience something to look at
Death by Power. Point n n Google it and you can waste many hours One that I like… n http: //www. slideshare. net/thecroaker/death-by-powerpoint
Presentations Grading n n n Content and style count Single grade for group Everyone does NOT need to present
Presentation Content n n Motivation n Introduction to the area and project n Key domain problems to be addressed “Use Cases” n Who are the users n What do they need to do Design n System design and further detail as needed n Key technical problems to be addressed n Technologies being used (and why) Demo: what you present to your customer this week n Any interesting “why”s
Motivation Tell the class about the problem n Information about the group n Similar websites or projects n Things that you are building on n How things are done today n What are the problems being faced n Why is the project being done
Design n n The first picture that you would draw for a new team member Sharing with other teams n n Technologies Major problems (solved or open)
Examples of Architecture Pictures Sound Omega Visual Interface Game Engine File I/O CONTROL MODEL VIEW Login Controller I/O Monster Verify. User Combat Login Monster Breed
SOME WELL-KNOWN ARCHITECTURES
The Architectures n n Model-View-Controller Data flow systems n n n Independent components n n n Interpreters Rule-based systems Repositories n n n Client-server Parallel communicating processes Event systems Virtual machines n n Pipes and filters Batch sequential Databases Hypertext systems Layered architectures
Independent Components n n Components operating in parallel and communicating occasionally Three types n Client-server n n n Parallel communicating processes n n Browser-web server most familiar example Separate systems with narrow interface Sometimes expanded to three tiers (why? ) Façade pattern (single unified interface) Several processes executing at the same time Typically modeled with sequence diagrams Observer pattern (one-to-many dependencies) Event systems n n Set of components waiting for input Example: word processor waiting for user input State transition diagrams State pattern (alter behavior depending on state)
Parallel Communicating Processes processes Session: session m Customer: customer n create Customer: customer n+1 deposit Session: session k Account: customer n checking actions retrieve create retrieve Account: customer n+1 saving withdraw Duration of process 3 types of processes, 2 instances of each sequence diagram Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
Observer Design Pattern Single source of data with a number of clients that need to be updated Client of this system 1 Source notify() Request others be notified 2 1. . n Notify all observers Observer update() Concrete. Observer observer. State update() Concrete. Subject state 3 Determines if change needed Gamma et al
Event Systems and State Transition Diagrams Set of components waiting for input
Virtual machines n n n Treats an application as a program written in a special language Payoff is that the interpreter code is the basis for multiple applications Two types n n Interpreters Rule-based systems
Repository n n A system built around data Two types n n Databases Hypertext systems
A Typical Repository System GUI Analysis process 1 Control …. . . DBMS Database Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Analysis process n
Iterator pattern void set. To. First(); points to first element void increment(); causes the iterator to point to its next element C getcurrent. Element(); return the element pointed to by the iterator boolean is. Done(); true if all elements processed
Hypertext: Basis of the Web n Motivated by Vannevar Bush in 1945 n n “As We May Think” (Atlantic Monthly) Theoretical machine, "memex, " to enhance human memory by allowing the user to store and retrieve documents linked by associations Invented by Ted Nelson in the 1960 s Popularized with HTML (Tim Berners-Lee)
Ted Nelson n n "If computers are the wave of the future, displays are the surfboards. " Xanadu: 1974 "give you a screen in your home from which you can see into the world's hypertext libraries. . . offer high-performance computer graphics and text services at a price anyone can afford. . . allow you to send and receive written messages. . . [and] make you a part of a new electronic literature and art, where you can get all your questions answered. . . “ n Computer Lib/Dream Machines
Layered Architecture 3 D engine layer Role-playing game layer «uses» Role. Playing. Game Characters «uses» Application layer Encounter Characters Encounter Environment Layout Encounter Game Coherent collection of software artifacts, typically a package of classes Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.
- Slides: 26