1 1 What is Software Architecture and Why It is important Ying Shen SSE, Tongji University Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
2 2 Architecting a dog house Can be built by one person Requires Minimal modeling Simple process Simple tools Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
3 3 Architecting a house Built most efficiently and timely by a team Requires Modeling Well-defined process Power tools Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
4 4 Why we need software architecture Why not just start coding and let things turn out somehow. • Software is increasingly complex. • Software is evolving, reused in new contexts. • The promise of off-the-shelf components with easy reuse o We need to adapt, wrap or modify the off-the-shelf components. o Too many components in software products. o Large number of connections/dependencies between these components. How to make sure that SW development reaches the intended goals of a project. Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
5 5 Why we need software architecture Software is complex: • >10KLOC (KLOC = 1000 lines of code): internal projects, tools, hobby projects, minimum viable products. • >100KLOC: small products, mobile apps. • >1MLOC: operating systems, native frameworks, typical desktop software applications, server side applications, typical everyday product. Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
6 6 Why we need software architecture How to understand software that has >1MLOC? How to reach >1MLOC and still understand software? How to reach >1MLOC without excessive complexity? How a >1MLOC software evolves into the next version? How a >1MLOC software or its components are reused? Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
7 7 Dimensions of software complexity Higher technical complexity - Embedded, real-time, distributed, fault-tolerant - Custom, unprecedented, architecture reengineering - High performance An average software project: - 5-10 people Defense - 10-15 month duration Telecom Weapon System - 3-5 external interfaces Switch National Air Traffic - Some unknowns & risks Commercial Control System Embedded Compiler Automotive Large-Scale Software Lower Higher CASE Tool Organization/Entity Simulation management management complexity complexity Small Scientific Simulation - Small scale - Large scale - Informal IS Application - Contractual Defense Enterprise IS Distributed Objects - Single stakeholder - Many stake holders MIS System (Family of IS (Order Entry) - “Products” - “Projects” Applications) IS Application GUI/RDB (Order Entry) Business Spreadsheet Lower technical complexity - Mostly 4GL, or component-based - Application reengineering Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering - Interactive performance
8 8 Architectural description has a natural position in system design and implementation Elements of a complete software system User Model User view of problem Requirement Software view of problem Modules and connections Architecture Code Algorithms & data structures Executable Data layouts, memory maps Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
9 9 What is Software Architecture? Definition from IEEE : 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. [ IEEE 1471] Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
10 10 What is Software Architecture? Definition from Kruchten: Rational Unified Process , 1999: An architecture is the set of significant decisions about the organization of a software system, the selection of structural elements and their interfaces by which the system is composed, together with their behavior as specified in the collaborations among those elements, the composition of these elements into progressively larger subsystems, and the architectural style that guides this organization -- these elements and their interfaces, their collaborations, and their composition. Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
11 11 What is Software Architecture? Definition from Bass et al.: SA in practice , 2012: The software architecture of a system is the set of structures needed to reason about the system, which comprise software elements , relations among them, and properties of both. The exact structures to consider and the ways to represent them vary according to engineering goals. Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
12 12 Implications of the definition Architecture is a set of software structures • Systems have many structures. o Module structures o Component-and-connector (C&C) structure: runtime, dynamic structure. Component is a runtime entity. o Allocation structures • No single structure can be the architecture. Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
13 13 Implications of the definition Architecture is a set of software structures • The set of candidate structures is not fixed or prescribed o whatever is useful for analysis, communication, or understanding. • Not all structures of the software are architectural o It should support reasoning about the system and the system’s properties Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
14 14 Implications of the definition Architecture is an abstraction • Architecture defines elements and how they interact. • Architecture suppresses purely local information about components o Private details are not architectural. Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
15 15 Implications of the definition Every software system has a software architecture. • Every system is composed of elements and relationships among them. • In the simplest case, a system is composed of a single element, related only to itself. Just having an architecture is different from having an architecture that is known to everyone. • architecture versus specification of the architecture • architecture recovery and conformance Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
16 16 Implications of the definition Architecture includes behavior • This means that box-and-line drawings alone are not architectures, but a starting point. • You might imagine the behavior of a box labeled “database” or “executive.” • You need to add specifications and properties. Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
17 17 Three kinds of structures Module structures embody decisions as to how the system is to be structured as a set of code or data units that have to be constructed or procured. • The elements are modules such as classes, layers. • Focus on the functional responsibility of each module, not emphasize runtime issue. Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
18 18 Three kinds of structures Useful module structures: • Decomposition structure Units: modules Relations: is a submodule of Used for: resource allocation and protect structuring and planning; information hiding, encapsulation; configuration control Affected attributes include: modifiability Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
19 19 Three kinds of structures Useful module structures: • Uses structure Units: modules Relations: uses, i.e. requires the correct presence of Used for: engineering subsets, engineering extensions Affected attributes include: “ subsetability ”, extensibility Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
20 20 Three kinds of structures Useful module structures: • Layer structure Units: layers Relations: requires the correct presence of, uses the services of, provides abstraction to Used for: incremental development, implementing systems on top of “virtual machines” Affected attributes include: portability Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
21 21 Three kinds of structures Useful module structures: • Class (or generalization) structure Units: classes, objects Relations: inherits from or is an instance of Used for: in object-oriented design systems, factoring out commonality; planning extensions of functionality Affected attributes include: modifiability and extensibility Software Architecture, Spring 2015 School of Software Engineering School of Software Engineering
Recommend
More recommend
