1. 26 February Humpty Dumpty Presentations Software Architecture (cont)

2. If Programmers Had to Build Planes http://www.flixxy.com/if-programmers-had-to-build- planes.htm http://www.flixxy.com/if-programmers-had-to-build- planes.htm

3. Humpty Dumpty Considerations How far behind are the other two parts? Need for testing with one-of-a- kind hardware How closely related are the parts? Don’t underestimate your predecessor Use industry terminology Testing models Suggestions 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

4. Midterm Presentations: Purpose You don’t understand something until you’ve taught it Clarification of your thought process and understanding Sharpen your understanding of the project Facilitate sharing Learn from each other Practice presenting

5. Midterm Presentations: Logistics March 4 and 6 Assignments now 10 minute presentations (excluding set up) Copies of charts to be posted on website Email me attachment or link Full attendance is expected

6. Presentations: The Basics Speak loudly and clearly Stand up No chewing gum when speaking Speak, don’t read: you ARE the experts Practice, practice, practice Set up and test demos and laptops early – and again the day you present

7. Presentations Hints 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

8. Death by PowerPoint Google it and you can waste many hours One that I like… http://www.slideshare.net/thecroaker/death-by-powerpoint

9. Presentations Grading Content and style count Single grade for group Everyone does NOT need to present

10. Presentation Content Motivation Introduction to the area and project Key domain problems to be addressed “Use Cases” Who are the users What do they need to do Design System design and further detail as needed Key technical problems to be addressed Technologies being used (and why) Demo: what you present to your customer this week Any interesting “why”s

11. Motivation Tell the class about the problem Information about the group Similar websites or projects Things that you are building on How things are done today What are the problems being faced Why is the project being done

12. Design The first picture that you would draw for a new team member Sharing with other teams Technologies Major problems (solved or open)

13. Examples of Architecture Pictures Game Engine Sound File I/O Controller I/O Visual Interface Omega CONTROL MODEL Login VerifyUser Monster Breed VIEW Monster Combat Login

14. SOME WELL-KNOWN ARCHITECTURES

15. The Architectures 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

16. Independent Components Components operating in parallel and communicating occasionally Three types Client-server Browser-web server most familiar example Separate systems with narrow interface Sometimes expanded to three tiers (why?) Façade pattern (single unified interface) Parallel communicating processes Several processes executing at the same time Typically modeled with sequence diagrams Observer pattern (one-to-many dependencies) Event systems Set of components waiting for input Example: word processor waiting for user input State transition diagrams State pattern (alter behavior depending on state)

17. Parallel Communicating Processes Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Customer: customer n withdraw Customer: customer n+1 Session: session k Session: session m deposit create Account: customer n+1 saving Account: customer n checking create retrieve 3 types of processes, 2 instances of each Duration of process processes actions sequence diagram

18. Observer Design Pattern Gamma et al Source notify() Observer update() ConcreteSubject state ConcreteObserver observerState update() Client of this system 1 2 3 1..n Request others be notified Notify all observers Determines if change needed Single source of data with a number of clients that need to be updated

19. Event Systems and State Transition Diagrams Set of components waiting for input

20. Virtual machines 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 Interpreters Rule-based systems

21. Repository A system built around data Two types Databases Hypertext systems

22. A Typical Repository System Database DBMS GUI Analysis process 1 Analysis process n …... Control Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

23. Iterator pattern void setToFirst(); points to first element void increment(); causes the iterator to point to its next element C getcurrentElement(); return the element pointed to by the iterator boolean isDone(); true if all elements processed

24. Hypertext: Basis of the Web Motivated by Vannevar Bush in 1945Vannevar Bush “As We May Think” (Atlantic Monthly)As We May Think 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 1960sTed Nelson Popularized with HTML (Tim Berners-Lee)Tim Berners-Lee

25. Ted Nelson "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...“ Computer Lib/Dream Machines

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