Chapter 7 Model-Based software Architectures

1. Chapter 7Model-Based software Architectures Notes taken from Walker Royce’s textbook on Software Project Management

2. Introductory Comments • Software Architecture – essential to building software systems, as is ALL architecture. • When we speak about Architecture (not software) • can apply stable laws of physics and mathematics. • Software Architecture • not governed by complete laws of math; • no irrefutable first principles. • At best, many heuristics and vague guidelines • Goodness measurable only in certain situations

3. Introductory Comments • So, what do practitioners do?? • With no established theory, software architects must rely on experiences and trial and error in formulating software architectures. • We recognize that the transition to an iterative process, where the early stages emphasize and promote architecture through evolution through prototyping and demonstration has proven to be the way to proceed.

4. Introductory Comments • Years ago, early systems had a very simple architecture. had informal software architectures. • Block diagrams; Hierarchy charts; Structure charts; IPO charts; Many tools at the detail level – for program design; not much at the architectural level… • Nowadays, with the complexity of modern systems, we have many models and views to explain the many viewpoints of many different perspectives of modern software development. • Need to show higher level views from different perspectives of different stakeholders – since there are now soooo many. •  “A ‘model’ is a relatively independent abstraction of a system. A view is a subset of a model that abstracts a specific, relevant perspective. “ (p. 110)

5. Architecture: A Management Perspective • “The most critical technical product of a software project is its architecture: the infrastructure, control, and data interfaces that permit software components to cooperate as a system and software designers to cooperate efficiently as a team.” • With the complexity of modern systems, a basis of communications is essential, and ‘inter-project communications’ (different groups; different viewpoints) must be established and precise.

6. 7.1 Management Perspective • Three different aspects of an architecture: • 1. An architecture – that is, the design of a software system as opposed to a component. (intangible design concept) • Includes all engineering necessary to specify the materials needed (buy, reuse, custom, costs of construction…) • 2. An architecture baseline – (tangible artifacts) – a slice of information across engineering artifacts sufficient to satisfy all stakeholders that the vision (function and quality) can be achieved with in the parameters of the business case (cost, profit, time, people, technology, …) • Note: an architecture baseline contains more than just an architecturedescription (next slide)

7. 7.1 Management Perspective • 3. An architecture description – human-readable representation of the architecture, which is one of the components of an architecture baseline. • Is an organized subset of information extracted from the design set model(s). • More detailed; contains additional info in the models. • Indicates how the intangible concept is realized via the tangible artifacts.

8. Note that architecture takes on different meanings in different domains! • Levels of granularity can vary widely and depend largely on what is needed by stakeholders at that ‘level’ and what concerns they need to resolve.

9. Importance of Software Architecture • “Achieving a stable architecture represents a significant project milestone at which the critical make/buy decisions should have been resolved. This life-cycle event represents a transition from the engineering stage of a project, characterized by discovery and resolution of numerous unknowns, to the production stage, characterized by management to a predictable development plan.”

10. Importance of Software Architecture • Architecture and process encapsulate many of the important (high payoff or high risk) communications among individuals, teams, organizations and stakeholders. • Poorly conceived architectures (and hence poor inter-process communications) and a process that is not a mature one (not well defined, taught, supported by management, and implemented by development teams, especially with established histories…) are often reasons for project failure. • A process that is mature, a good understanding of all the primary requirements, and the development of an architecture that is demonstratable are essential requirements predictable planning – fundamental to management. • Architecture development and process definition are the intellectual steps that map the problem to a solution without violating the constraints; they require human intervention and cannot be automated.

11. 7.2 Architecture: A Technical Perspective. • Although progress has been made, there is still a lack of agreement on definitions and principles. • From Kruchten: • “Software architecture encompasses the structure of software systems (the selection of elements and the composition of elements into progressively larger subsystems), their behavior (collaborations among elements), and the patterns that guide these elements, their collaborations, and their composition.” (underlining and bold is mine).

12. An architectural framework is defined in terms of views that are abstractions of the UML models in the design set. • (Think of the 4+1 Architectural View of the RUP) • The Design Model includes the full breadth and depth of information. •  An architectural view (again, think of the five in the 4+1 architectural views of RUP) is an abstraction of the design model; • That is, a higher-level view of more detailed artifacts/activities… • it contains only the architecturally significant information. • Most real-world systems require four views: • Design, process, component, and deployment. • RUP added the Use Case View as ‘driving’ all the views and overall architecture. • Let’s look at the purposes of these views…

13. Models and Views – again • To keep our terminology straight: • A ‘model’ is a relatively independent abstraction of a system. (We can thus develop models – in general depicting / describing whatever it is we need to describe.) BUT a VIEW: • A view is a subset of a model that abstracts a specific, relevant perspective. “ (p. 110) • Remember, a view is developed to support a specific viewpoint or perspective or to support certain needs that certain groups of stakeholder have. • As stated, it is a tailored subset of a model – to capture a relevant perspective. • We have logical views, component views, deployment views,…

14. Views and their Purposes • Design View (logical view in RUP) describes the architecturally significant structures and functions of the design model. • Process View: describes concurrency and control thread relationships among the design, component, and deployment views. • Component View: describes the structure of the implementation set (Implementation View in RUP) • Deployment View: describes the structure of the deployment set. • Recall: each of these views is developed to support certain needs of stakeholders. • Design View (logical view in RUP) is developed to support analysts, programmers, architects, etc. Component View (Implementation View in RUP) is developed to support construction (programming and test) etc.

15. The Necessity of Views • Design view is clearly essential. All systems need this view. • Others are needed as necessary… • Distributed systems need a process view and a deployment view; • Large systems that might have custom and commercial components probably also need a component view.

16. The Design Set • The design set will include all UML design models describing the solution space. (Big Cookie!! • Depending on the complexity of a system itself, several models or partitions of other models (views) may need to be developed. • Use case, design (logical), and process models provide for visualization of the logical and behavioral aspects of the system. • Component view provides visualization of the implementation set; deployment model provides visualization of the deployment set.

17. The Design Set • Note that ‘architecture’ is an organized and abstracted view into design models….. • An architecture is captured through many views, which are extracts of design models and capture the significant structures, collaborations, and behaviors. • The architectural description, then, of a system is captured via portions of each model; • Part of the design model (design view) addresses architecture; • Part of the process model (process view) addresses architecture (as needed) • Part of the component model (implementation view) is part of the architectural view, etc. • The views are extracts of design models that capture significant structures, collaborations, and behaviors.

18. Architecture • The architectural descriptions are always kept electronically, but also maintained in a printable version. These engineering and architectural views are defined as collections of UML diagrams unlike text and basic graphics models of years past. • (Be careful: management may still want these. Educate them where possible…)

19. Architecture – Many Faces • Descriptions of an architecture is many things to many people in different application domains. • And, these take on many different forms. • Ideally, they can remain electronic, but … • So, given all this, and recognizing that the descriptions can vary a great deal, what constitutes a good architecture baseline? • That is, what is a good ‘critical mass’ of models / views in general? • Remember, we are after content that is architecturally-significant….

20. Heuristics for an Architectural Baseline • “Requirements: critical use cases, system-level quality objectives, and priority relationships among features and qualities. • “Design: names, attributes, structures, behaviors, groupings, and relationships of significant classes and components. • “Implementation: source component inventory and bill of materials (number name, purpose, cost) of all primitive components • “Deployment: executable components sufficient to demonstrate the critical use cases and the risk associated with achieving the system qualities.” p.114

21. Architectural Baseline – Comments • Project success is often dependent upon a architectural description in an architectural-first approach (like RUP). • Essential to the question of ‘balance.’ • (what is ‘in’ the architecture and what is not) • Key word: ‘balance.’ • Note that the architecturalbaseline is a subset of the architecturaldescription, which is totally contained in the Design Set.

22. The Old and the New • Conventional systems did not distinguish between the two (architectural description and architectural baseline) • No rigorous notations (normally block diagrams and text) • Little tie in to other engineering artifact sets for validation • Iterative development – an “architecture baseline is a partial realization of the architecture description that is sufficient to provide tangible evidence that the architecture is valid in the context of the requirements and plans.” • This is, thus, thee major ‘deliverable’ of the Elaboration phase, and hopefully we can readily see why this is so.

23. Architectural Baseline • Degree of detail and forms depends many factors. • Very skilled people developing a limited application may need only UML diagrams whereas a command-and-control system that is large scale and highly distributed will clearly require more details to validate a solid baseline!

24. Concluding Remarks • Note that the transition from engineering into production should not take place unless a stable architecture baseline is established. • Thus relevant stakeholders must agree that the original vision (supported by the requirements and and architecture) and represented in the design set and partially implemented in the implementation and deployment sets) can be achieved with a highly predictable cost and schedule. • Verification requires briefings and executable prototypes that demonstrate the evolving capabilities. • These will show the maturity of the process.