Software Architecture

1. Software Architecture School of Computer Science & Engineering • School of Software, UESTC Jianchuan Xing E-mail：xingjianchuan@sina.com

2. References • 软件体系结构. 刘真编著. 中国电力出版社. 2004.9. • Java软件体系结构设计模式标准指南=Software architecture design patterns in java. (美)Partha Kuchana著, 王卫军, 楚宁志等译. 北京:电子工业出版社. 2006. • 大型软件体系结构: 使用UML实践指南/(美)Jeff Garland，(美)Richard Anthony著;叶俊民，汪望珠等译。北京: 电子工业出版社,2004 • 电信运营支撑系统: 软件体系结构模式系统. 王君珂, 艾波著.北京: 人民邮电出版社, 2006. • 面向模式的软件体系结构 卷1 模式系统=Pattern-oriented software architecture, volume 1 : a system of patterns. (德)[F. 布希曼]Frank Buschmann等著, 贲可荣等译. 北京: 机械工业出版社. 2003. • 面向模式的软件体系结构 卷2 用于并发和网络化对象的模式=Pattern-Oriented software architecture·volume 2·patterns for concurrent and networked objects. [D. 施密特]Douglas Schmidt等著, 张志祥，任雄伟，肖斌等译. 北京: 机械工业出版社. 2003.8.

3. References (Cont.) • 面向模式的软件体系结构 卷3. [克车库]Michael Kircher，Prashant Jain著, 鲍志云译. 北京: 机械工业出版社, 2005.9. • 软件体系结构(第2版). 张友生等编著. 北京: 清华大学出版社. 2006. • 软件体系结构. Mary Shaw，David Garlan著, 牛振东，江鹏，金福生编译. 北京: 清华大学出版社. 2007. • 软件体系结构=Software architecture. 覃征等编著. 西安: 西安交通大学出版社. 2002.12. • 软件体系结构的艺术. (美)Stephen T.Albin著, 刘晓霞，郝玉洁等译. 北京: 机械工业出版社. 2003. • 软件体系结构的原理、组成与应用. 万建成，卢雷编著. 北京: 科学出版社. 2002. • 软件体系结构及实例分析. 余雪丽主编. 北京: 科学出版社. 2004. • 实用软件体系结构. (美)Christine Hofmeister等著, 王千祥等译. 北京: 电子工业出版社. 2004.

4. How to teach and how to exam? • Giving a class and discussing in the classroom • Exam+Homework+Discussing • Exam 60% • Homework 20% • Discussing 20%

5. Contents • Chapter 1 Introduction • Chapter 2 IS2000: The Advanced Imaging Solution • Chapter 3 Global Analysis • Chapter 4 Conceptual Architecture View • Chapter 5 Module Architecture View • Chapter 6 Execution Architecture View

6. Contents(Cont.) • Chapter 7 Code Architecture View • Chapter 8 Safety Vision • Chapter 9 Healthy Vision • Chapter 10 Central Vision • Chapter 11 Comm Vision • Chapter 12 The Role of the Software Architect

7. Chapter 1 Introduction

8. Outline • Putting Software Architecture in Context • Software Architecture as a Design Plan • Software Architecture as an Abstraction • Software Architecture Terminology • The Four Views • Loose Coupling Between Views • Different Engineering Concerns Addressed by Different Views • Using the Four Views • Notation

9. 1.1 Putting Software Architecture in Context • What is software architecture? • Software architecture is an art and an engineering discipline about software. • The history of software architecture is much shorter – the software industry began sometime after ENIAC started processing bits in the late 1940s. • Software architecture is still in its nascency although many architectural specializations are mature disciplines. • It is noteworthy that software architecture is also much less mature than its sibling, computer hardware architecture, which boasts Moore’s Law to predict regular improvements in performance.

10. 1.1 Putting Software Architecture in Context (Cont.) • The two main aspects of software architecture are that it provides a design plan – a blueprint – of a system, and that it is an abstraction to help manage the complexity of a system. In this section we discuss these two aspects, and some architecture terminology. This sets the stage for the rest of the chapter,which presents the four views of software architecture.

11. 1.1.1 Software Architecture as a Design Plan • The architect documents the architecture and makes sure it’s understood by the stakeholders(at the appropriate level of detail) and by the developers. • The design plan isn’t a project plan that describes activities and staffing for designing the architecture or developing the product. • Instead, it is a structural plan that describes the elements of the system, how they fit together,and how they work together to fulfill the system’s requirements.

12. 1.1.1 Software Architecture as a Design Plan (Cont.) • The architect reviews requirements and negotiates them. • The analysis tasks produce the require for the system, and may produce things like domain model, a requirements model, and an organizational model. • Although none of these are part of the software architecture,the requirements are a key input to the software architecture design. • As the architect or architecture team reviews the requirements and proceeds with the architecture design, they may need to return to the stakeholders to negotiate changes to the requirements.

13. 1.1.1 Software Architecture as a Design Plan (Cont.) Figure 1.1. Relation of software architecture to other development tasks

14. 1.1.1 Software Architecture as a Design Plan (Cont.) • The architect provides requirements to the system architect, who configures the hardware architecture. • The team also works closely with the system architect, who configures the hardware architecture. The hardware architecture is another key input to the software architecture design. • The software architect or team in turn gives requirements to the system architect, and may suggest modifications as the software architecture design progresses.

15. 1.1.1 Software Architecture as a Design Plan (Cont.) • The architect makes sure the architecture is followed. • The software architecture then guides the implementation tasks, including detailed design, coding, integration, and testing. • Although some people consider things like coding patterns and implementation templates to be part of the architecture, we think of these code-level artifacts as implementation mechanisms, not as the software architecture.

16. 1.1.2 Software Architecture as an Abstraction • The architect makes sure the architecture meets its requirements. • The software architecture should define and describe how the elements fulfill the system requirements, including which elements are responsible for which functionality, how the interact with each other, how they interact with the outside world, and their dependencies on the execution platform.

17. 1.1.2 Software Architecture as an Abstraction (Cont.) • The architect keeps up with innovations and technologies. • Although many of the nonfunctional requirements or qualities are explicitly given as requirements, there may be additional qualities that the system should have. The architect should consider the kinds of changes to which the system will need to adapt; for example, the modifiability and portability of the system. • Another quality to consider is the buildability and testability of the system.

18. 1.1.2 Software Architecture as an Abstraction (Cont.) • The architect develops a prototype, simulates, and gathers whatever information is necessary to identify, understand, and reduce risks. • The purpose of the software architecture is not only to describe the important aspects for others, but to expose them so that the architect can reason about the design. • The makes it easier to analyze trade-offs between conflicting requirements.

19. 1.1.2 Software Architecture as an Abstraction (Cont.) • The architect makes design trade-offs. • In the end these design trade-offs can only be resolved by sacrificing of compromising a requirement or other desired quality. The compromise could be in the form of • Renegotiating a requirement • Reducing the modifiability, portability, or other desired system quality • Sacrificing simplicity by using a more complex design or implementation, or additional optimizations

20. 1.1.3 Software Architecture Terminology • Architectural style, architectural pattern • Used in similar ways • Usually not domain specific • Defining element types • Defining how they interact

21. 1.1.3 Software Architecture Terminology (Cont.) • Reference architecture, domain-specific software architecture • Used in similar ways • Usually domain specific • Defining element types and allowed interactions • Defining how the domain functionality is mapped to the architecture elements

22. 1.1.3 Software Architecture Terminology (Cont.) • Product-line architecture • Generally applies to a set of products within an organization or company • Defining element types • Defining how they interact • Defining how the product functionality is mapped • Defining some of the instances of the architecture elements

23. Table 1.1. Comparison of Software Architecture Terms

24. 1.1.3 Software Architecture Terminology (Cont.) • Architecture description language • Providing a way of specifying the elements used in the architecture, generally both as types and instances. • Providing support for interconnecting element instances to form a configuration.

25. 1.1.3 Software Architecture Terminology (Cont.) • Design pattern • As a technology sometime relevant to architecture • Sometime relevant to detailed design • When describing the interactions between architecture element,  part of the software architecture • When describing the structure and interactions within architecture elements, part of the detailed design

26. 1.1.3 Software Architecture Terminology (Cont.) • Framework • Specify structure, and the flow of control and /or data • Architecture-level information • Also specified by giving a partial implementation—an implementation of infra-structure • So a hybrid of architecture-level information and implementation

27. 1.2 Where the Four Views Came From • Our goal in our original study was to discover the principles that guided the software architecture in these systems. More specifically, for each system,we wanted to • Understand the problem • Understand the software architecture and how it addresses the particular problem • Find out what approaches and methods the architects used in designing the software architecture • Find out how they used the architecture during development, maintenance, and evolution, and how they used it for other products in the same family or successors of the product

28. Table 1.2. Summary of the Case Study Systems

29. 1.2.1 Loose Coupling Between Views • Code View • Initially, the source code for a program resided in a single file. Today a system’s source code is usually split into many files, and many kinds of files. • The organization of the source code into object code,libraries,and binaries, then in turn into versions,files and directories strongly affects the reusability of the code and the build time for the system.

30. 1.2.1 Loose Coupling Between Views (Cont.) • Module View • As systems increased in size and in number of programmers, techniques arose for handling complexity due to size, and for partitioning work among programmers. • Although the design of individual classes or procedures is usually too fine grained to be considered part of software architecture design, the decomposition of the system and partitioning of modules into layers is the main purpose of the module view.

31. 1.2.1 Loose Coupling Between Views (Cont.) • Execution View • Systems have always had a dynamic aspect. Even when programs were strictly sequential, languages arose to describe the sequencing of programs, and the files that were read and written. • Now these issues are generally recognized as being architecture issues. They are better handled by the architect early on in the project, rather than being handled by the programmer as development processes. This is the work of the execution view.

32. 1.2.1 Loose Coupling Between Views (Cont.) • Conceptual View • Describing the system in terms of its major design elements and the relationships among them. • Some of today’s advanced systems were designed with an explicit conceptual view. • In a few systems, the conceptual view plays a primary role.

33. 1.2.2 Different Engineering Concerns Addressed by Different Views • Conceptual View • How does the system fulfill the requirement? • How are the commercial off-the shelf (COTS) components to be integrated and how do they interact (at the functional level) with the rest of the system? • How is domain-specific hardware and/or software incorporated into the system? • How is functionality partitioned into product releases? • How does the system incorporate portions of the prior generations of the product and how will it support future generations? • How are product lines supported? • How can the impact of changes in requirements or the domain be minimized?

34. 1.2.2 Different Engineering Concerns Addressed by Different Views (Cont.) • Module View • How is the product mapped to the software platform? • What system support/services does it use, and exactly where? • How can testing be supported? • How can dependencies between modules be minimized? • How can reuse of modules and subsystems be maximized? • What techniques can be used to insulate the product from changes in COTS software, in the software platform, or changes to standards?

35. 1.2.2 Different Engineering Concerns Addressed by Different Views (Cont.) • Execution View • How does the system meet its performance, recovery, and reconfiguration requirements? • How can one balance resource usage (e.g., load balancing)? • How can one achieve the necessary concurrency,replication, and distribution without adding too much complexity to the control algorithms? • How can the impact of changes in the runtime platform be minimized?

36. 1.2.2 Different Engineering Concerns Addressed by Different Views (Cont.) • Code View • How can the time effort for product upgrades be reduced? • How should product versions and releases be managed? • How can build time be reduced? • What tools are needed to support the development environment? • How are integration and testing supported?

37. 1.3 Using the Four Views • The basis for our design approach is the four views, their activities, and the dependencies among them. Figure 1.2 shows the views and their dependencies. • In addition, unless the new system poses no new challenges, the architect cannot finalize all decisions up front, before detailed design and implementation begins.

38. 1.3 Using the Four Views (Cont.) Figure 1.2. The four views of software architecture

39. 1.4 Notation • Boxes-and-lines notation • Originally we used boxes-and-lines notation to describe software architecture. • The Unified Modeling Language (UML) • Late in 1998, we began to replace this with the Unified Modeling Language (UML) • UML is a general-purpose modeling language with standardized graphical notation and associated semantics. • We chose UML because it supports most of what we need to describe. • One of our concerns was that UML emerged from object-oriented design, so it is most commonly used to describe things at the detailed-design level.

40. Summary • Regarding software architecture as a Design Plan • Regarding software architecture as an abstraction • Introducing software architecture terminology • Introducing the four views (conceptual, module,execution,code) • Notation(boxes-and-lines to UML)

41. Thanks!