1 / 32

Software Architecture EECE417

Software Architecture EECE417. Lecture 1. Henrik Hybertsson Ship designer . Multi-deck battleship. Vasa is sinking after 30’. Story of ‘Vasa’ battleship (~1620). Gustavus Adolphus , King of Sweden 1611-32. Inquires concluded that the ship was “badly proportioned” .

brody
Download Presentation

Software Architecture EECE417

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. Software ArchitectureEECE417 Lecture 1

  2. Henrik Hybertsson Ship designer Multi-deck battleship Vasa is sinking after 30’ Story of ‘Vasa’ battleship (~1620) Gustavus Adolphus, King of Sweden 1611-32 Inquires concluded that the ship was “badly proportioned”

  3. This class is [amongst others] about techniques Hybertsson and his team could have used: • Case studies of successful architectures crafted to satisfy demanding requirements • Methods to asses the architecture before any system is built, so as to mitigate the risks of unprecedented designs • Techniques for incremental architecture-based development, so as to uncover design flaws before it is to late to repair them

  4. Administrativia Course webpage: http://www.ece.ubc.ca/~matei/EECE417/ Timeslot: Mon/Wed/Fri 11:00-12:00. Note: I may travel the week of February 10th we’ll schedule makeup class. Office hours: after each class or by appointment (email me) Email: matei @ ece.ubc.ca Office: KAIS 4033

  5. EECE 417: Course Goals • Gain a good understanding of fundamental software architecture issues • Functional versus non-functional requirements and their impact on architecture. • Designing an architecture • Documenting a software architecture • Analyzing an architecture

  6. What I’ll Assume You Know ... • Basic software engineering concepts • Procedural abstraction, encapsulation, polymorphism, … • UML notation (?) • Software patterns (?) • Basics of Internet architecture and network programming • Socket programming, TCP, DNS, HTTP

  7. Administravia: Grading • Assignments (Individual) + • Mini-Project (Group): 50% • Midterm/Final exam: 50% • Class and mailing list participation: 3% (bonus)

  8. Questions?

  9. What is Software Architecture? • It’s all about software design • Architecture is software design, but not all design is software architecture • [Gorton] Architecture focuses on ‘issues that will be difficult/impossible to change once the system is built’ • E.g., quality attributes like security, performance • E.g., non-functional requirements like cost, deployment hardware

  10. Definitions – Taylor et al. • [Software architecture is] the set of principal design decisions governing a system

  11. Omit information not related to structure  abstraction More than one structure! Provided services, Interfaces, Performance characteristics, Fault handling, Shared resource usage Implications: (1) any system has a structure; (2) does not say what’s a good or a bad architecture. Software Architecture Definition(source: Software Engineering Institute @ CMU) “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.”

  12. Definitions - ANSI/IEEE Std 1471-2000 • “Architecture is the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution.”

  13. Main point: Architecture Defines Structure • Decomposition of system in components/modules/subsystems • Architecture defines: • Component responsibilities • Precisely what each component does • Component interfaces • How to interact with a component • Component communications and dependencies • How multiple components interact to form a system

  14. Software Engineering Difficulties

  15. Software Engineering Difficulties 15 • Software engineers deal with unique set of problems • Young field with tremendous expectations • Building of vastly complex, but intangible systems • Often software is not useful on its own • (e.g., unlike a car) • thus it must conform to changes in other engineering areas • Some problems can be eliminated • “accidental difficulties” • Other problems can be lessened, but not eliminated • “essential difficulties”

  16. Accidental Difficulties • Solutions exist - Possibly waiting to be discovered • E.g. past productivity increases as the result of overcoming • Inadequate programming constructs & abstractions • Remedied by high-level programming languages • Increased productivity by factor of five • Complexity was never inherent in program at all • Inadequate tools: • E.g., assesing results of programming decisions took long time • Remedied by time–sharing • Turnaround time approaching limit of human perception • Difficulty of using heterogeneous programs • Addressed by integrated software development environments • Support task that was conceptually always possible

  17. Essential Difficulties • Only partial solutions exist, if any • Cannot be abstracted away • Complexity • Conformity • Changeability • Intangibility

  18. Complexity • No two software parts are alike • If they are, they are abstracted away into one • Complexity grows super-linearly with size • E.g., it is impossible to enumerate all states of program • Except perhaps “toy” programs

  19. Conformity • Software is required to conform to its • Operating environment • Hardware • Often “last kid on block” • Perceived as most conformable

  20. Changeability • Software is viewed as infinitely malleable • Change originates with • New applications, users, machines, standards, laws • Hardware problems

  21. Intangibility • Software is not embedded in space • Often no constraining physical laws • No obvious representation • E.g., familiar geometric shapes

  22. Promising Attacks On Complexity • Buy vs. Build • Requirements refinement & rapid prototyping • Hardest part is deciding what to build (or buy?) • Must show product to customer to get complete spec. • Need for iterative feedback

  23. Promising Attacks On Complexity (cont’d) • Incremental/Evolutionary/Spiral Development • Grow systems, don’t build them • Good for morale • Easy backtracking • Early prototypes • Great designers • Good design can be taught; great design cannot • Nurture great designers

  24. Analogy: Architecture of Buildings • We all live in them • (We think) We know how they are built • Requirements • Design (blueprints) • Construction • Use • This is similar (though not identical) to how we build software

  25. Some Obvious Parallels Satisfaction of customers’ needs Specialization of labor Multiple perspectives of the final product Intermediate points where plans and progress are reviewed

  26. Deeper Parallels Architecture is different from, but linked with the product/structure Properties of structures are induced by the architecture The architect has a distinctive role

  27. Deeper Parallels (cont’d) • The process is not as important as the architecture • Design and resulting qualities are at the forefront • Process is a means, not an end • Architecture has matured over time into a discipline • Architectural styles as sets of constraints • Styles also as wide range of solutions, techniques and palettes of compatible materials, colors, and sizes

  28. More about the Architect • A distinctive role in a project • Broad training • Amasses and leverages extensive experience • A keen sense of aesthetics • Deep understanding of the domain • Properties of structures, materials, and environments • Needs of customers

  29. More about the Architect (cont’d) • Even first-rate programming skills are insufficient for the creation of complex software applications • But are they even necessary?

  30. Limitations of the Analogy… • We know a lot about buildings, much less about software • The nature of software is different from that of building architecture • Software is much more malleable than physical materials • The two “construction industries” are very different • Software deployment has no counterpart in building architecture (or limited one at best)

  31. …But Still Very Real Power of Architecture • Giving preeminence to architecture offers the potential for • Intellectual control • Conceptual integrity • Effective basis for knowledge reuse • Realizing experience, designs, and code • Effective project communication • Management of a set of variant systems • Limited-term focus on architecture will not yield significant benefits!

  32. Parting thoughts:Why is software architecture important? • Communication with stakeholders • Manifests early design decisions • Transferable abstraction of a system

More Related