1 / 61

SEng 5861: Software Architecture

SEng 5861: Software Architecture. Dr. Michael Whalen Fall 2010. Topics for Today. Course Overview Instructor and teaching model What you should already know What to Expect Questions Software Architecture. Class Info. Professor Mike Whalen Office: 6-254 Keller Hall (EE/CS Building)

thanos
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 Dr. Michael Whalen Fall 2010 SEng 5861 - Mike Whalen

  2. Topics for Today • Course Overview • Instructor and teaching model • What you should already know • What to Expect • Questions • Software Architecture SEng 5861 - Mike Whalen

  3. Class Info • Professor Mike Whalen • Office: 6-254 Keller Hall (EE/CS Building) • E-mail: whalen@cs.umn.edu • Office hour: 4:00 – 5:00 Friday • Phone: 612-624-5130 • TA • RupaTiwari: rupa.tiwari@gmail.com • Office hour: 11:30 on class days • Class information: http://www-users.cselabs.umn.edu/classes/Fall-2010/seng5861/ SEng 5861 - Mike Whalen

  4. Who Am I? • PhD University of Minnesota, 2005 • Research work in testing and formal methods • Work experience: SEng 5861 - Mike Whalen

  5. Who are you? • Where do you work? • What kinds of software do you develop? • What do you hope to get from this course? SEng 5861 - Mike Whalen

  6. Group Discussions Lecture Learning Modes Textbooks Projects and Writing Assignments SEng 5861 - Mike Whalen

  7. Prerequisites • Understanding of software design & patterns • Understanding of UML notation • Used throughout the book • Ability to read/understand source code in multiple languages • For project, you will be explaining the architecture of an existing system; this will probably require examination of source code. SEng 5861 - Mike Whalen

  8. Assignments and Grading • Tests: midterm and final • In class – open book • Go to lecture • Keep up with the readings • Project • Understand and document an existing architecture • Can be work-related; can be open-source • Document and contrast alternative architectures • Describe likely extensions • Evolve the architecture: either extend it or refactor it. SEng 5861 - Mike Whalen

  9. Expected Workload • The project will be a large amount of work • Builds on previous coursework • This class is traditionally quite time consuming • We are trying to make it easy on you, but… • Planning and scheduling your time is essential • Make sure you spread out the work • You will have problems trying to “cram” • We are available to help SEng 5861 - Mike Whalen

  10. Communicating • Problems with course material • Talk to Rupa • Talk to me • Problems with TA, problems with TA explanation, or just want to talk to the instructor • Talk to me • Problem with me • Contact TA an she/he will voice your complaints (anonymously) • Contact UMSEC and they will help you SEng 5861 - Mike Whalen

  11. Lecture Plan • Overview of architecture [3 weeks] • Architecture as artifact and process • Role of architect and stakeholders • System scope and documentation • Modeling and analysis [3 weeks] • Modeling, Architecture Description Languages, and AADL • Architectural viewpoints [3 weeks] • Construction, Deployment, and Operations • Architectural patterns/styles [3 weeks] • General patterns, REST, and SOA • Final exam SEng 5861 - Mike Whalen

  12. Architecture Overview SEng 5861 - Mike Whalen

  13. What is Architecture? • [Garlan & Perry]: Software architecture is "the structure of the components of a program/system, their interrelationships, and principles and guidelines governing their design and evolution over time." • [Bass, Clements, and Kazman]: The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them. • [IEEE 1471]: Software architecture is the fundamental organization of a system, embodied in its components, their relationships to one another and the environment, and the principles governing its design and evolution. SEng 5861 - Mike Whalen

  14. Why Should You Care? • Good Things are Well Architected • Internet • World Wide Web • Airplanes • ATMs • Good architecture is hard! SEng 5861 - Mike Whalen

  15. Why Should You Care? SEng 5861 - Mike Whalen www.despair.com

  16. Project Failure Rate (by Size) Data: Scott Ambler “The July 2010 State of the IT Union Survey” SEng 5861 - Mike Whalen

  17. Why is IT team size growing? Note: Accurate to within +/-6.5% SEng 5861 - Mike Whalen

  18. SEng 5861 - Mike Whalen

  19. What is Architecture to me? • Software architecture is primarily concerned with partitioning large systems into smaller ones that can be created separately, that individually have business value, and that can be straightforwardly integrated with one another and with existing systems. SEng 5861 - Mike Whalen

  20. Architecture as artifact • Static and Dynamic Structures SEng 5861 - Mike Whalen

  21. Architectural Qualities Ease of Maintenance Performance Security Testability Usability SEng 5861 - Mike Whalen

  22. Stakeholders Ops manager; needs to know how to back up system data for disaster recovery Security and compliance: needs to know how data is logically and physically secured User: How is this going to make my life better? Developer: What are the system interfaces I need to respect? Management: what is the business case for the system? SEng 5861 - Mike Whalen

  23. Role of Software Architect • Define the functional interface of the system • Determine important qualities of the system • Especially, acceptance criteria • Revise architecture as implementation issues arise • Explain and Persuade different stakeholders on architectural details you, the architect SEng 5861 - Mike Whalen

  24. What architects do, diagramatically SEng 5861 - Mike Whalen

  25. What we will do • Culmination of three course series • Software Engineering, Design, and Architecture • Expect you to use, and build on concepts learned in these courses • Requirements, Patterns, System Scoping • Examine, critique and modify a “large” system • Choose an existing system • Discuss architectural alternatives • Re-factor or extend the system SEng 5861 - Mike Whalen

  26. Marshmallow challenge SEng 5861 - Mike Whalen

  27. Build the Tallest Freestanding Structure: • The winning team is the one that has the tallest structure measured from the table top surface to the top of the marshmallow. That means the structure cannot be suspended from a higher structure, like a chair, ceiling or chandelier. SEng 5861 - Mike Whalen

  28. Things to Understand • Build the Tallest Freestanding Structure: The winning team is the one that has the tallest structure measured from the table top surface to the top of the marshmallow. That means the structure cannot be suspended from a higher structure, like a chair, ceiling or chandelier. • The Entire Marshmallow Must be on Top: The entire marshmallow needs to be on the top of the structure. Cutting or eating part of the marshmallow disqualifies the team.  • Use as Much or as Little of the Kit: The team can use as many or as few of the 20 spaghetti sticks, as much or as little of the string or tape. The team cannot use the bag as part of their structure. • Break up the Spaghetti, String or Tape: Teams are free to break the spaghetti, cut up the tape and string to create new structures. • The Challenge Lasts 18 minutes: Teams cannot hold on to the structure when the time runs out. Those touching or supporting the structure at the end of the exercise will be disqualified. • Ensure Everyone Understands the Rules: Don’t worry about repeating the rules too many times. Repeat them at least three times. Ask if anyone has any questions before starting. SEng 5861 - Mike Whalen

  29. So…Go! • Materials are in bags SEng 5861 - Mike Whalen

  30. AND THE TALLEST STRUCTURE IS SEng 5861 - Mike Whalen

  31. Lessons from this exercise • http://www.ted.com/talks/tom_wujec_build_a_tower.html • Importance of: • Prototyping, especially when the domain is not well understood • Team Coherence and Facilitation • Experience • Much easier 2nd time around • Especially if study (postmortem) occurs in between SEng 5861 - Mike Whalen

  32. Garlan and Shaw SEng 5861 - Mike Whalen

  33. Architectural Styles SEng 5861 - Mike Whalen

  34. Pipe and Filter SEng 5861 - Mike Whalen

  35. Pipe and Filter Architecture Target Data Transformation Program Source Data … … … … SEng 5861 - Mike Whalen

  36. X Object-Oriented Style SEng 5861 - Mike Whalen

  37. Object-Based Style SEng 5861 - Mike Whalen

  38. Object-Based Style • “Default” in UML • Component-Level View • Interface-Based • Many OO Patterns still apply • As long as no inheritance required across component boundaries • Interface-based programming • Dependency Injection is (should be) the default across components SEng 5861 - Mike Whalen

  39. Dependency Inversion Principle • Higher level modules should not depend on lower level modules • Both should depend on abstractions • Interfaces or Abstract classes • Abstractions should not depend on details (Not to be confused with Dependency Injection and Inversion of Control) SEng 5861 - Mike Whalen

  40. Why DIP • Increase loose coupling • Abstract interfaces don't change • Concrete classes implement interfaces • Concrete classes easy to throw away and replace • Increase mobility • Increase isolation • decrease rigidity • Increase testability • Increase maintainablity • Closely related to LSP SEng 5861 - Mike Whalen

  41. Reminder - Procedural Design SEng 5861 - Mike Whalen

  42. DIP SEng 5861 - Mike Whalen

  43. DIP implications • Layers • Interface based programming • Separated Interface • put interface in separate package than implementation • Dependency Injection SEng 5861 - Mike Whalen

  44. Old Way public class MyApp { public MyApp() { authenticator = new Authenticator(); database = new Database(); logger = new Logger(); errorHandler = new ErrorHandler(); } // More code here... } SEng 5861 - Mike Whalen

  45. Dependency Injection • DIP says we should depend on an interface • how do we get the concrete instance? SEng 5861 - Mike Whalen

  46. New Way? public class MyApp { public MyApp() { authenticator = new IAuthenticator(); database = new IDatabase(); logger = new ILogger(); errorHandler = new IErrorHandler(); } // More code here... } OOPS SEng 5861 - Mike Whalen

  47. Dependency Injection • Option 1 – Factory • User depends on factory • Factory depends on destination • Option 2 – Locator/Registry/Directory • The component still controls the wiring • Instantiation Sequence • Dependency on the Locator • Option 3 – Dependency Injection • An assembler controls the wiring SEng 5861 - Mike Whalen

  48. DI Options • Setter Injection • The component is passive • Someone injects the dependency SEng 5861 - Mike Whalen

  49. DI Options • Setter Injection • Constructor Injection • “Always” initialized • Better dependency visibility SEng 5861 - Mike Whalen

  50. Other DI Options • Interface Injection • Variation on setter injection • Getter Injection • Needs AOP (not clean) SEng 5861 - Mike Whalen

More Related