The Context of Software Architecture

1. The Context of Software Architecture

2. Fundamental Understanding • Architecture is a set of principal design decisions about a software system (domain, business, and technology) • Three fundamental understandings of software architecture • Every application has an architecture • Every application has at least one architect • Architecture is not a phase of development

3. Wrong View: Architecture as a Phase • Treating architecture as a phase denies its foundational role in software development • More than “high-level design” • Architecture is also represented, e.g., by object code, source code, …

4. Context of Software Architecture • Requirements • Design • Implementation • Analysis and Testing • Evolution • Development Process

5. Requirements Analysis • Traditional SE suggests requirements analysis should remain unsullied by any consideration for a design • However, without reference to existing architectures it becomes difficult to assess practicality, schedules, or costs • In building architecture we talk about specific rooms… • …rather than the abstract concept “means for providing shelter” • In engineering new products come from the observation of existing solution and their limitations

6. New Perspective on Requirements Analysis • Existing designs and architectures provide the solution vocabulary • Our understanding of what works now, and how it works, affects our wants and perceived needs • The insights from our experiences with existing systems • helps us imagine what might work and • enables us to assess development time and costs  Requirements analysis and consideration of design must be pursued at the same time

7. Non-Functional Properties (NFP) • NFPs are the result of architectural choices • NFP questions are raised as the result of architectural choices • Specification of NFP might require an architectural framework to even enable their statement • An architectural framework will be required for assessment of whether the properties are achievable

8. An Alternative Perspective:The Twin Peaks Model

9. Design and Architecture • Design is an activity that pervades software development • It is an activity that creates part of a system’s architecture • Typically in the traditional Design Phase decisions concern • A system’s structure • Identification of its primary components • Their interconnections • Architecture denotes the set of principal design decisions about a system • That is more than just structure

10. Architecture-Centric Design • Traditional design phase suggests translating the requirements into algorithms, so a programmer can implement them • Architecture-centric design • stakeholder issues • decision about use of COTS component • over arching style and structure • package and primary class structure • deployment issues • post implementation/deployment issues

11. Design Techniques • Basic conceptual tools • Separation of concerns • Abstraction • Modularity  Remember these from the first lecture • Two widely adapted strategies • Object-oriented design • Domain-specific software architectures (DSSA)

12. Object-Oriented Design (OOD) • Objects • Main abstraction entity in OOD • Encapsulations of state with functions for accessing and manipulating that state

13. Pros and Cons of OOD • Pros • UML modeling notation • Design patterns • Cons • Fail to address stakeholder concerns, deployment issues, security and trust • only one kind of encapsulation (the object) • OO programming language might dictate important design decisions • Requires more work in the upstream activities to determine architectural components, relations, interfaces • Certain problem domains do not benefit from OO approach

14. DSSA • Capturing and characterizing the best solutions and best practices from past projects within a domain • Production of new applications can focus on the points of novel variation • Reuse applicable parts of the architecture and implementation • Applicable for product lines  Recall the Philips Koala example discussed in the previous lecture

15. Implementation • The objective is to create machine-executable source code • That code should be faithful to the architecture • Alternatively, it may adapt the architecture • How much adaptation is allowed? • It must fully develop all outstanding details of the application

16. Faithful Implementation • All of the structural elements found in the architecture are implemented in the source code • Source code must not utilize major new computational elements that have no corresponding elements in the architecture • Source code must not contain new connections between architectural elements that are not found in the architecture • Is this realistic?Overly constraining? What if we deviate from this?

17. Unfaithful Implementation • The implementation does have an architecture • It is latent, as opposed to what is documented. • Failure to recognize the distinction between planned and implemented architecture • robs one of the ability to reason about the application’s architecture in the future • misleads all stakeholders regarding what they believe they have as opposed to what they really have • makes any development or evolution strategy that is based on the documented (but inaccurate) architecture doomed to failure

18. Implementation Strategies • Generative techniques • e.g. parser generators • Frameworks • collections of source code with identified places where the engineer must “fill in the blanks” • Middleware • CORBA, DCOM, RPC, … • Reuse-based techniques • COTS, open-source, in-house • Writing all code manually

19. How It All Fits Together

20. Analysis and Testing • Analysis and testing are activities undertaken to assess the qualities of an artifact • The earlier an error is detected and corrected the lower the aggregate cost • Rigorous representations are required for analysis, so precise questions can be asked and answered

21. Analysis of Architectural Models • Formal architectural model can be examined for internal consistency and correctness • An analysis on a formal model can reveal • Component mismatch • Incomplete specifications • Undesired communication patterns • Deadlocks • Security flaws • It can be used for size and development time estimations

22. Analysis of Architectural Models (cont.) • Architectural model • may be examined for consistency with requirements • may be used in determining analysis and testing strategies for source code • may be used to check if an implementation is faithful

23. Evolution and Maintenance • All activities that chronologically follow the release of an application • Software will evolve • Regardless of whether one is using an architecture-centric development process or not • The traditional software engineering approach to maintenance is largely ad hoc • Risk of architectural decay and overall quality degradation • Architecture-centric approach • Sustained focus on an explicit, substantive, modifiable, faithful architectural model

24. Architecture-Centric Evolution Process • Motivation e.g. new version of product • Evaluation or assessment • Design and choice of approach • Action • includes preparation for the next round of adaptation

25. Processes • Traditional software process discussions make the process activities the focal point; architecture often nowhere to be found! • In architecture-centric software engineering the product becomes the focal point • No single “right” software process for architecture-centric software engineering exists

26. Turbine– A New Visualization Model • Goals of the visualization • Provide an intuitive sense of • Project activities at any given time • Including concurrency of types of development activities • The “information space” of the project • Show centrality of the products • (Hopefully) Growing body of artifacts • Allow for the centrality of architecture • But work equally well for other approaches, including “dysfunctional” ones • Effective for indicating time, gaps, duration of activities • Investment (cost) indicators

27. time The Turbine Model “Core” of project artifacts Testing Gap between rotors indicates no project activity for that t Coding Radius of rotor indicates level of staffing at time t Design ti Requirements Simplistic Waterfall, Side perspective

28. Cross-section at time ti Design (activity) Requirements Design doc

29. time The Turbine Model Waterfall example, Angled perspective

30. time A Richer Example Assess/… Test/Build/ Deploy Build/Design/ Requirements/Test Design/Build/ Requirements S1 Requirements/Architecture assessment/Planning

31. A Sample Cross-Section

32. A Cross-Section at Project End

33. Volume Indicates Where Time was Spent Assess/… Test/Build/ Deploy Build/Design/ Requirements/Test Design/Build/ Requirements Requirements/Architecture assessment/Planning

34. A Technically Strong Product Line Project Deployment Capture of new work Other Parameterization Customization Assessment

35. Visualization Summary • It is illustrative, not prescriptive • It is an aid to thinking about what’s going on in a project • Can be automatically generated based on input of monitored project data • Can be extended to illustrate development of the information space (artifacts) • The preceding slides have focused primarily on the development activities

36. Processes Possible in This Model • Traditional, straight-line waterfall • Architecture-centric development • DSSA-based project • Agile development • Dysfunctional process

37. Summary (1) • A proper view of software architecture affects every aspect of the classical software engineering activities • The requirements activity is a co-equal partner with design activities • The design activity is enriched by techniques that exploit knowledge gained in previous product developments • The implementation activity • is centered on creating a faithful implementation of the architecture • utilizes a variety of techniques to achieve this in a cost-effective manner

38. Summary (2) • Analysis and testing activities can be focused on and guided by the architecture • Evolution activities revolve around the product’s architecture. • An equal focus on process and product results from a proper understanding of the role of software architecture