1 / 64

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  move a little later in class Functional View Exercise Deployment View Operational View Concurrency View Performance Perspective. Updates.

gage
Download Presentation

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 •  move a little later in class • 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 Refer to Phase II Optional Put your proposed changes / extensions here Do this SEng 5861 - Mike Whalen

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

  7. Some Use Cases SEng 5861 - Mike Whalen

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

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

  10. 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 discrepancies in amount of functionality SEng 5861 - Mike Whalen

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

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

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

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

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

  16. My Version SEng 5861 - Mike Whalen

  17. midterm SEng 5861 - Mike Whalen

  18. Midterm • Grade range: 83-100 • Grading questions should be submitted in writing & we will address them SEng 5861 - Mike Whalen

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

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

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

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

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

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

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

  26. Runtime Platform Models SEng 5861 - Mike Whalen

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

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

  29. Network Model SEng 5861 - Mike Whalen

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

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

  32. 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 Image courtesy of: www.indianajones.com SEng 5861 - Mike Whalen

  33. Operations view SEng 5861 - Mike Whalen

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

  35. When do I need it? • Any time the system must be maintained after it is installed. • Installation and Migration • Configuration Management • System Administration • System Support SEng 5861 - Mike Whalen

  36. Installation • [Insert your installation 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

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

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

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

  40. Data Migration SEng 5861 - Mike Whalen

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

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

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

  44. Do not use operations documentation as an excuse for bad software! • Examples: • Los Angeles air traffic control: reboot system every 30 days to prevent a timer overflow or system will crash • Patriot missle system: reboot system every 12 hours or it won’t track incoming missles correctly • Therac 25: don’t press keys too quickly or use backspace key or system will give incorrect radiation dose • Operations documents can become a CYA tool for bad software SEng 5861 - Mike Whalen

  45. Support Model Documentation SEng 5861 - Mike Whalen

  46. Support Model Documentation • Groups needing support • How to support: User groups? E-mail? Telephone? On-Site? • Classes of incidents • Characteristics of incidents: what is the impact? • Where does the buck stop? • Support providers and responsibilities • Escalation process • How do we make sure that incidents are resolved in a timely and correct manner? SEng 5861 - Mike Whalen

  47. Pitfalls • Lack of engagement with Operations staff • Lack of backout planning • Lack of migration planning • Potentially twice the data! • Insufficient migration window • Missing management tools • Lack of integration into the production environment • Doesn’t play well with existing systems Image courtesy of: www.indianajones.com SEng 5861 - Mike Whalen

  48. Airport Parking System administration Image from: www.kilian-nakamura.com SEng 5861 - Mike Whalen

  49. Given requirements and model… SEng 5861 - Mike Whalen

  50. …Create Airport Parking System 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

More Related