SEng 5861: Software Architecture

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