1 / 63

SEng 5861: Software Architecture

SEng 5861: Software Architecture. Lecture 8 Dr. Michael Whalen Fall 2010. Topics for Today. Questions / Comments from Last Week Midterm Recap Complete Functional View Exercise Deployment View Operational View Concurrency View Performance Perspective. Updates.

bunme
Télécharger la présentation

SEng 5861: Software Architecture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SEng 5861: Software Architecture Lecture 8 Dr. Michael Whalen Fall 2010 SEng 5861 - Mike Whalen

  2. Topics for Today • Questions / Comments from Last Week • Midterm Recap • Complete Functional View Exercise • Deployment View • Operational View • Concurrency View • Performance Perspective SEng 5861 - Mike Whalen

  3. Updates • Guest lecture next week on product families • Jeff Thompson: PhD 2001 on product families and reuse • Applied some of this work to products at Boston Scientific • Domain specific “patterns” for creating systems SEng 5861 - Mike Whalen

  4. Updates: Project Phase III • Not grading on identifying styles and patterns • We will cover that in more depth starting next week • Need to choose 2 systems within the architecture • One should be “top level” system • One should be an interesting subsystem • For each system, describe 2 viewpoints • One must be functional viewpoint • One is of your choosing SEng 5861 - Mike Whalen

  5. Updates: Project Phase III Do this 1.Version History 2.Table of Contents 3.Introduction 4.1Purpose and Scope 4.2Audience 4.3Status 4.4Architectural Design Approach 5.Glossary 6.System Context 6.1System Environment 6.2Overview of Requirements 6.3System Scenarios 7.Architectural Forces 7.1Goals 7.2Constraints 7.3Architectural Principles 8. Architectural Views for Top-Level System • Pick Two views 9. Architectural Views for Subsystem • Pick Two Views 10.Appendices 10.1Appendix: Decisions and Alternatives 10.3Appendix: References Do this Refer to Phase II Do this Optional Refer to Phase II Do this SEng 5861 - Mike Whalen

  6. Exercise: functional view of airport parking system SEng 5861 - Mike Whalen

  7. Airport Parking Controller • You are asked to build the automated parking system at MSP airport • Support ePark: • Also support ticketed parking: user receives a ticket and pays either by credit card or cash Simply insert your credit or debit card into the card reader at the ramp entrance. This will record the time you entered airport parking. Use the same credit or debit card to pay at an ePark® exit lane. The system is fully automated; there is no waiting in line for a cashier. SEng 5861 - Mike Whalen

  8. Airport Parking Controller • Basic functionality: users should be able to: • Enter the parking lot if space is available • Either via ticket or credit card • Exit the parking lot at any time • Pay either via cash or credit card • But there is much more to it! • What if user uses different credit card to enter/exit? • What if there are insufficient funds? • What if I am unable to reach VISA server? • Etc. etc. etc. SEng 5861 - Mike Whalen

  9. Some Use Cases SEng 5861 - Mike Whalen

  10. Airport Controller • Create the top-level component model • Use a UML diagram model • First describe components • Then describe interfaces • Does this app need to be distributed? • If so, would you use MOM, RPC, or both? SEng 5861 - Mike Whalen

  11. Examples SEng 5861 - Mike Whalen

  12. SEng 5861 - Mike Whalen

  13. SEng 5861 - Mike Whalen

  14. General Architectural Principles • Encapsulate components that are likely to change • Often, this is hardware • Define services that individually and collectively have value • High Coherence • Low Coupling SEng 5861 - Mike Whalen

  15. Common Artifacts Is there just one? One per gate? One per street entrance/exit? • Entry Manager • Exit Manager • Credit Card Billing • Lot Manager • Accounting Interface • Kiosk Interface • …and some differences Wide discrepencies in amount of functionality SEng 5861 - Mike Whalen

  16. Let’s focus on pricing • Many different price rates / policies • Single use / payment • Short term vs. extended parking • Event parking • Pay as you go in vs. pay as you go out • Contracts • Term: monthly / yearly / other • Flat fee • Billed by usage • Mechanism: parking pass? Credit card? SEng 5861 - Mike Whalen

  17. What do you have to track? • Upon entry? • Upon exit? • Where to store “completed” transactions • In system? • Via interface to accounting system? • For pricing? • When performing manual overrides? • Who can perform them? • How do you log them? SEng 5861 - Mike Whalen

  18. What do you need to control? • Physical gates for entry / exit • Entry kiosks • Credit card reader • Parking card dispenser • Exit kiosks • Automated: credit card / parking card reader • Optional: cash input • Attendant kiosks • Point of sale device: in or out of system? • Allow manual override of charges? SEng 5861 - Mike Whalen

  19. How do you want to report? • Revenue? • Partitioned by pricing type? • Current? Over time? • Card stock levels per entry kiosk? • Mechanical failures? • Ramp usage? Utilization over time? SEng 5861 - Mike Whalen

  20. So, Let’s Build It SEng 5861 - Mike Whalen

  21. My Version SEng 5861 - Mike Whalen

  22. Deployment view http://www.youtube.com/watch?v=T2PdyxMtiYM SEng 5861 - Mike Whalen

  23. …But it worked during test!?! • Having deployment documentation is key (but often overlooked) to a successful product rollout SEng 5861 - Mike Whalen

  24. When Do I Need It? • When system has: • Complex runtime dependencies (software) • Complex runtime environments (hardware) • Dependencies on unfamiliar HW/SW • When system will be deployed • in wildly varying software environments • E.g., consumer shrink-wrap software • in varying physical environments • Enterprise software, military software SEng 5861 - Mike Whalen

  25. Concerns: Hardware • Type of hardware required • CPU • Storage • Network • Quantity of hardware required • How many machines? • How much storage? SEng 5861 - Mike Whalen

  26. Concerns: 3rd Party Software • Third-party software requirements • OS • Drivers • Libraries • Internet Services • Messaging Systems • Application Servers • Middleware • Databases • Web servers • ..and more! SEng 5861 - Mike Whalen

  27. Concerns: : 3rd Party Software • Versioning • Can all components agree on versions of common dependencies? • Examples: C++ standard library, DLLs, OS revisions • These incompatibilities tend to be found during integration when it is expensive. • Hardware requirements for 3rd party software SEng 5861 - Mike Whalen

  28. Concerns: Networking • How much network capacity is required? • What kind of traffic is sent? • Is encryption required? • What is the required reliability of the network? SEng 5861 - Mike Whalen

  29. Runtime Platform Models SEng 5861 - Mike Whalen

  30. Offline storage Runtime Platform Models Online storage Specialized hardware Processing node Element to node mapping Network links Client node SEng 5861 - Mike Whalen

  31. Process {model = SL3000 mfr = StorageTek} {model = StorEdge450 mfr = Sun capacity=2TB} Estimate Hardware Requirements - What is current load on servers?- What are reqs for processing power, memory, disk, bandwidth? {memory = 1GB, model = V880 CPU 2 x 750MHz, mfr = Sun} {memory = 1GB, model = E420R CPU 2 x 450MHz, mfr = Sun} Map software to hardware - is capacity sufficient? - must services be colocated? - must services be separated? Conduct technical evaluation of deployment: - prototyping, - benchmarks, - compatibility tests Then assess constraints Design deployment environment - identify key servers - identify network connections - elaborate with storage, specialized hardware {memory = 1GB, model = V880 CPU 4 x 1.1GHz, mfr = Sun} {memory = 128MB, CPU 750 MHz} {memory = 512MB, CPU 1.2 GHz} SEng 5861 - Mike Whalen

  32. Network Model SEng 5861 - Mike Whalen

  33. Network Model Components Processing Nodes Network Connections with Constraints Network Nodes SEng 5861 - Mike Whalen

  34. Capturing Software Dependencies • Use tables to capture dependencies for each system • Use database to “roll up” all dependencies for a module • This step can check for inconsistencies SEng 5861 - Mike Whalen

  35. Pitfalls • Missing dependencies • Unproven technology • Use stuff you are familiar with, when possible • Allocate additional testing time for new HW • Lack of specialist technical knowledge • Late consideration of deployment environment SEng 5861 - Mike Whalen

  36. Operations view SEng 5861 - Mike Whalen

  37. What does it mean when the swap file is full? • Operational aspects of systems are often ignored during design • This is a significant contributor to unexpected system down time Apr 7 21:42:18 aga253distp209 genunix: [ID 470503 kern.warning] WARNING: Sorry, no swap space to grow stack for pid 18718 (httpd)Apr 7 21:42:18 aga253distp209 last message repeated 1 timeApr 8 07:54:28 aga253distp209 tmpfs: [ID 518458 kern.warning] WARNING: /zonas/sitesoutros/root/etc/svc/volatile: File system full, swap space limit exceededApr 8 07:54:28 aga253distp209 last message repeated 1 timeApr 8 07:59:28 aga253distp209 tmpfs: [ID 518458 kern.warning] WARNING: /zonas/sitesoutros/root/etc/svc/volatile: File system full, swap space limit exceededApr 8 07:59:28 aga253distp209 last message repeated 1 timeApr 8 08:04:28 aga253distp209 tmpfs: [ID 518458 kern.warning] WARNING: /zonas/sitesoutros/root/etc/svc/volatile: File system full, swap SEng 5861 - Mike Whalen

  38. When do I need it? • Any time the system must be maintained after it is installed. • Procedures for long term data storage • Procedures for how to manage the system under heavy load • Procedures for graceful system load / shutdown • Data migration procedures SEng 5861 - Mike Whalen

  39. Operations Activities • Installation and Migration • Configuration Management • System Administration • System Support SEng 5861 - Mike Whalen

  40. Installation • [Insert your horror story here] • Functional migration • Big bang:immediate switchover (often during offpeak times like weekends) • Parallel Run: new and old systems run side by side until confidence is gained • Staged Migration: parts of a process or system are swapped out over a period of time to minimize risk of failure • How do you back out if migration fails? SEng 5861 - Mike Whalen

  41. Data Migration • System transition may involve changing format of GBs or TBs of data • May not match new format exactly • May require conversion in parallel with live updates • Zeno’s conversion… • Extraction, Transformation, and Load (ETL) tools are designed to aid this conversion Courtesy of Merle and Kelly Cunningham SEng 5861 - Mike Whalen

  42. Slide on ETL tools • TBD SEng 5861 - Mike Whalen

  43. Documenting Installation and Migration • No standard modeling notation for describing functional and data migration • It may be best presented in prose with tables • Functional migration documentation should: • describe installation groups • describe dependencies • describe constraints: autocoding, autoconfig • describe backout approach SEng 5861 - Mike Whalen

  44. Example Installation Docs • Good example from R&W on page 334 • But, how should (do?) you test backout procedure? SEng 5861 - Mike Whalen

  45. Data Migration SEng 5861 - Mike Whalen

  46. Data Migration • Determine amount of data and format differences for migration • Define procedure for data transformation (if required) between old and new system • Define information synchronization procedure (if required) between old and new system • Define procedure for backout • May be difficult to reverse the data transformation when migrating SEng 5861 - Mike Whalen

  47. System Administration Document • Routine maintenance procedures • Likely error conditions • Logging facilities and use • Custom utilities necessary for administration • Key performance scenarios and how to monitor performance • Monitoring facilities to be provided to track system during runtime SEng 5861 - Mike Whalen

  48. System Administration Example • R&W Page 342 SEng 5861 - Mike Whalen

  49. Do not use operations documentation as an excuse for bad software! • Examples: • Los Angeles air traffic control • Patriot missle system • Therac 25 • Infusion pumps • Operations documents can become a CYA for bad software SEng 5861 - Mike Whalen

  50. Support Model Documentation • Image showing support SEng 5861 - Mike Whalen

More Related