Programming Design - PowerPoint PPT Presentation

software architecture n.
Skip this Video
Loading SlideShow in 5 Seconds..
Programming Design PowerPoint Presentation
Programming Design

play fullscreen
1 / 101
Download
Download Presentation

Programming Design

Presentation Transcript

  1. Software Architecture New wine in old bottles? (i.e., software architecture  global design?, architect  designer)

  2. Overview • What is it, why bother? • Architecture Design • Viewpoints and view models • Architectural styles • Architecture asssessment • Role of the software architect SE, Software Architecture, Hans van Vliet, ©2008

  3. The Role of the Architect SE, Software Architecture, Hans van Vliet, ©2008

  4. Pre-architecture life cycle stakeholders (few) requirements quality agreement development SE, Software Architecture, Hans van Vliet, ©2008

  5. Characteristics • Iteration mainly on functional requirements • Few stakeholders involved • No balancing of functional and quality requirements SE, Software Architecture, Hans van Vliet, ©2008

  6. stakeholders (few) requirements quality agreement development Adding architecture, the easy way architecture detailed design implementation SE, Software Architecture, Hans van Vliet, ©2008

  7. Architecture in the life cycle stakeholders (many) requirements quality architecture agreement development SE, Software Architecture, Hans van Vliet, ©2008

  8. Characteristics • Iteration on both functional and quality requirements • Many stakeholders involved • Balancing of functional and quality requirements SE, Software Architecture, Hans van Vliet, ©2008

  9. Why Is Architecture Important? • Architecture is the vehicle for stakeholder communication • Architecture manifests the earliest set of design decisions • Constraints on implementation • Dictates organizational structure • Inhibits or enable quality attributes • Architecture is a transferable abstraction of a system • Product lines share a common architecture • Allows for template-based development • Basis for training SE, Software Architecture, Hans van Vliet, ©2008

  10. Where did it start? • 1992: Perry & Wolf • 1987: J.A. Zachman; 1989: M. Shaw • 1978/79: David parnas, program families • 1972 (1969): Edsger Dijkstra, program families • 1969: I.P. Sharp @ NATO Software Engineering conference: • “I think we have something in addition to software engineering [..] This is the subject of software architecture. Architecture is different from engineering.” SE, Software Architecture, Hans van Vliet, ©2008

  11. Software architecture, definition (1) • The architecture of a software system defines that system in terms of computational components and interactions among those components. • (from Shaw and Garlan, Software Architecture, Perspectives on an Emerging Discipline, Prentice-Hall, 1996.) SE, Software Architecture, Hans van Vliet, ©2008

  12. Software Architecture statement  procedure  module  (design) pattern  architecture SE, Software Architecture, Hans van Vliet, ©2008

  13. Software Architecture, definition (2) • The software architecture of a 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. • (from Bass, Clements, and Kazman, Software Architecture in Practice, SEI Series in Software Engineering. Addison-Wesley, 2003.) SE, Software Architecture, Hans van Vliet, ©2008

  14. Software Architecture • Important issues raised in this definition: • multiple system structures; • externally visible (observable) properties of components. • The definition does not include: • the process; • rules and guidelines; • architectural styles. SE, Software Architecture, Hans van Vliet, ©2008

  15. Architectural Structures • module structure • conceptual, or logical structure • process, or coordination structure • physical structure • uses structure • calls structure • data flow • control flow • class structure SE, Software Architecture, Hans van Vliet, ©2008

  16. Software Architecture, definition (3) • Architecture is the fundamental organization of a system embodied in its components, their relationships to each other and to the environment and the principles guiding its design and evolution • (from IEEE Standard on the Recommended Practice for Architectural Descriptions, 2000.) SE, Software Architecture, Hans van Vliet, ©2008

  17. Software Architecture • Architecture is conceptual. • Architecture is about fundamental things. • Architecture exists in some context. SE, Software Architecture, Hans van Vliet, ©2008

  18. Other points of view • Architecture is high-level design • Architecture is overall structure of the system • Architecture is the structure, including the principles and guidelines governing their design and evolution over time • Architecture is components and connectors SE, Software Architecture, Hans van Vliet, ©2008

  19. Software Architecture & Quality • The notion of quality is central in software architecting: a software architecture is devised to gain insight in the qualities of a system at the earliest possible stage. • Some qualities are observable via execution: performance, security, availability, functionality, usability • And some are not observable via execution: modifiability, portability, reusability, integrability, testability SE, Software Architecture, Hans van Vliet, ©2008

  20. Overview • What is it, why bother? • Architecture Design • Viewpoints and view models • Architectural styles • Architecture asssessment • Role of the software architect SE, Software Architecture, Hans van Vliet, ©2008

  21. Attribute-Driven Design (Bass et al, Ch 7) • Choose module to decompose • Refine this module: • choose architectural drivers (quality is driving force) • choose pattern that satisfies drivers • apply pattern • Repeat steps SE, Software Architecture, Hans van Vliet, ©2008

  22. Example ADD iterations • Top-level: usability  separate user interface  Seeheim/three tier architecture • Lower-level, within user interface: security  authenticate users • Lower-level, within data layer: availability  active redundancy SE, Software Architecture, Hans van Vliet, ©2008

  23. Generalized model • Understand problem • Solve it • Evaluate solution SE, Software Architecture, Hans van Vliet, ©2008

  24. Global workflow in architecture design synthesis architecture context backlog evaluation evaluation results requirements SE, Software Architecture, Hans van Vliet, ©2008

  25. Generalized model (cont’d) assets architecture ideas synthesis backlog evaluation constraints eval results sign.reqs SE, Software Architecture, Hans van Vliet, ©2008

  26. Design issues, options and decisions A designer is faced with a series of design issues • These are sub-problems of the overall design problem. • Each issue normally has several alternative solutions (or design options) • The designer makes a design decision to resolve each issue. • This process involves choosing the best option from among the alternatives. SE, Software Architecture, Hans van Vliet, ©2008

  27. Design problem sub- problem (or issue) sub- problem (or issue) Decision = best option Design option Design option Design option Design option Decision = best option Alternative solutions Alternative solutions Taking decisions Problem space Decision space SE, Software Architecture, Hans van Vliet, ©2008

  28. fat-client client in a separate user interface layer Programmed in Java client-server client style Programmed in Visual Basic thin-client Programmed in C++ no separate user interface layer monolithic Decision space The space of possible designs that can be achieved by choosing different sets of alternatives. SE, Software Architecture, Hans van Vliet, ©2008

  29. fat-client client in a separate user interface layer flexibility client-server client style thin-client layered MVC no separate user interface layer monolithic Tree or graph? • Issues and options are not independent ... SE, Software Architecture, Hans van Vliet, ©2008

  30. More than just IT • Technical and non-techical issues and options are intertwined • Architects deciding on the type of database versus • Management deciding on new strategic partnership or • Management deciding on budget SE, Software Architecture, Hans van Vliet, ©2008

  31. Some (tacit) decisions are related to norms and values SE, Software Architecture, Hans van Vliet, ©2008

  32. Types of decisions • Implicit, undocumented • Unaware, tacit, of course knowledge • Explicit, undocumented • Vaporizes over time • Explicit, explicitly undocumented • Tactical, personal reasons • Explicit, documented • Preferred, exceptional situation SE, Software Architecture, Hans van Vliet, ©2008

  33. Why is documenting design decisions important? • Prevents repeating (expensive) past steps • Explains why this is a good architecture • Emphasizes qualities and criticality for requirements/goals • Provides context and background SE, Software Architecture, Hans van Vliet, ©2008

  34. Uses of design decisions • Identify key decisions for a stakeholder • Make the key decisions quickly available. E.g., introducing new people and make them up2date. • ..., Get a rationale, Validate decisions against reqs • Evaluate impact • If we want to change an element, what are the elements impacted (decisions, design, issues)? • ..., Cleanup the architecture, identify important architectural drivers SE, Software Architecture, Hans van Vliet, ©2008

  35. Elements of a design decision • Issues: design issues being addressed • Decision • Status: e.g., pending, approved • Assumptions: underlying assumptions • Alternatives • Rationale; the why of the decision taken • Implications: e.g. need for further decisions SE, Software Architecture, Hans van Vliet, ©2008

  36. Pointers on design decisions • Hofmeister et al, Generalizing a Model of Software Architecture Design from Five Industrial Approaches, Journal of Systems and Software, 2007 • Tyree and Ackerman, Architecture decisions: demystifying architecture, IEEE Software, vol. 22(2), 2005. • Kruchten, Lago and van Vliet, Building up and exploiting architectural knowledge, WICSA, 2005. • Lago and van Vliet, Explicit assumptions enrich architectural models, ICSE, 2005. SE, Software Architecture, Hans van Vliet, ©2008

  37. Overview • What is it, why bother? • Architecture Design • Viewpoints and view models • Architectural styles • Architecture asssessment • Role of the software architect SE, Software Architecture, Hans van Vliet, ©2008

  38. Software design in UML • Class diagrams, state diagrams, sequence diagram, etc • Who can read those diagrams? • Which type of questions do they answer? • Do they provide enough information? SE, Software Architecture, Hans van Vliet, ©2008

  39. Who can read those diagrams? • Designer, programmer, tester, maintainer, etc. • Client? • User? SE, Software Architecture, Hans van Vliet, ©2008

  40. Which type of questions do they answer? • How much will it cost? • How secure will the system be? • Will it perform? • How about maintenance cost? • What if requirement A is replaced by requirement B? SE, Software Architecture, Hans van Vliet, ©2008

  41. Analogy with building architecture • Overall picture of building (client) • Front view (client, “beauty” committee) • Separate picture for water supply (plumber) • Separate picture for electrical wiring (electrician) • etc SE, Software Architecture, Hans van Vliet, ©2008

  42. Architecture presentations in practice • By and large two flavors: • Powerpoint slides – for managers, users, consultants, etc • UML diagrams, for technicians • A small sample … SE, Software Architecture, Hans van Vliet, ©2008

  43. SE, Software Architecture, Hans van Vliet, ©2008

  44. SE, Software Architecture, Hans van Vliet, ©2008

  45. SE, Software Architecture, Hans van Vliet, ©2008

  46. SE, Software Architecture, Hans van Vliet, ©2008

  47. SE, Software Architecture, Hans van Vliet, ©2008

  48. So, … • Different representations • For different people • For different purposes • These representations are both descriptive and prescriptive SE, Software Architecture, Hans van Vliet, ©2008

  49. IEEE model for architectural descriptions SE, Software Architecture, Hans van Vliet, ©2008

  50. Some terms (from IEEE standard) • System stakeholder: an individual, team, or organization (or classes hereof) with interests in, or concerns relative to, a system. • View: a representation of a whole system from the perspective of a related set of concerns. • Viewpoint: A viewpoint establishes the purposes and audience for a view and the techniques or methods employed in constructing a view. SE, Software Architecture, Hans van Vliet, ©2008