So --- Why Software Architecture?

1. So --- Why Software Architecture? • As software systems continue to grow in size and complexity (both breadth and depth), just looking at algorithms and data structures is not enough. • “Large” systems, by definition, is made of many sub-components that interact with each other. So ---- to design “it,” we need to study the architecture/design behind it. Architecture Design Coding

2. “Progressive” Picture of Software More Progress Design to satisfy: -performance -consistency -reliability -usability -extensibility -etc. Some Progress early days Code Patterns & Algorithms (speed/space) Code Relative Complexity/Size/Concern growth

3. Software Architecture • Your Text: “ A system’s architectureis the set of principaldesign decisionsmade during its development and any subsequent evolution.” • Tsui modifies it to say: “ A system’s architectureis the result ofa setof principal design decisions made and expressed (in design document, code, etc.) during its development and subsequent evolution what ? As we develop/build software --- we make decisions and tradeoffs to satisfy ---- These decisions emerge as the design/architecture and also influence code.

4. Software Architecture (definitions) • From Roy Fielding’s PhD thesis (UC Irvine-2000): “A software architecture is an abstraction of the run-time elements of a software systemduring some phase of its operation. A system may be composed of many levels of abstractionand different phases of operations, each with its own software architecture.” • Software operational phases may be depicted as: • Start up • Initialization • Normal Processing • Error Processing • Possible re-initialization/re-process • Termination What is abstraction? If you describe these, do you have a design ?

5. Software Architecture Definitions • There is NO “standard” definition of software architecture, yet; there are more definitions in Chapter 3 of your text What do you all think --- ? At an earlier lecture (1/7/2014), a student said that a software design artifact was composed of a set of software “pieces/components” ---- how about a little more

6. A Definition from McMaster Univ. (Canada) • Architectural Designing (the designing activity --- verb) The process of i) identifying the components and ii) establishinga “framework” fora) control andb)communications of these components • Software Architecture (the product from designing) The documented output from the architectural design activities. (what is this framework?)

7. Architecture-Centric Development • Architecture-Centric approach to software development places an emphasis on “design” with an aim for: • Good quality (e.g. less defects) and many other product attributes (reliability, extensibility, usability, etc.) • Cost-effective development • High leveraging of past experiences (reuse) Prohibitive requirement for young/inexperienced developers

8. Analogyto Physical Building • Software architecture/design and physical building architecture have some similarities: • Architecture exist independently from, but strongly linked to, the (building) (code) • Properties of the (structures) (software component configuration) are induced by the design of their architecture • The architect needs to have “broad” skills beyond just (construction) (programming) • Architecture is more important than the “process”of (building activities) (software development process) • Architecture has matured into a discipline of its own with many architectural (building) design styles. (this one may be questionable for software)

9. One wayto “visualize” “software component configuration (building)” How is configuration specified here? Func 1 Func n . . . . . . . . “vertical” & “horizontal” functional structure is sometimes thought of as “Architecture” Common UI screen looks and icons Common error processing and messaging Only common “horizontal” features Sometimes --- Thought of as “Architecture” . . Common interface to Database Base

10. Some Differences from Physical Building • Buildings have been around for a much longer time than software; so a lot less is knownabout software • Software does not have a “medium” such as materials of wood, stone, etc. for physical building; so software is not as “visible” • Software is more malleable than a physical building; so software changes are more frequently requested, ---- changes that are later in development stage, the bigger are their magnitude of disruption.

11. Architectural “Style” • Styleis a set of “constraints” placed on the architecture to achieve certain properties • Recall architecture is a set of design decisions • Style is a characterization of a set of common features that resulted from a set of constraints on the architecture. So - - - - “style” results from placing constraints on design decisions

12. Architectural “Styles” • In physical building there are: Gothic style Ranch style Bavarian Chalet style Italian Villa style English Tudor style etc. • In software we have: Layered style Pipe & Filter style Model-View-Control etc.

13. from Roman Architect Vitruviusto Today’s Software Designer Mitch Kapor (not in your text) • Paraphrasing (Vitruvius): “ ---- well-designed buildings were those which exhibited firmness, commodity, and delight -----” • Paraphrasing (Mitch Kapor-lotus 1-2-3 ): for software we want similar characteristics as what Vitruvius said: firmness: No Bugs (or less bugs and reliable) commodity: functionalities that satisfy the requirements/users delight:“pleasurable” experience (exciting usage experience) • Paraphrasing (T. Winograd-Stanford U.): “ --- architects and designerswork with commodity and delight, and the engineersworks with firmness ----”

14. Why the Big emphasis on Architecture? • Giving architecture the deserved attention provides: • Conceptual integrity • A basis for reuse of ---- knowledge, experience, design, and code • Effective project communication • Management of “families” of systems • Architecture must be considered the “heart” of developing software system, even: • More than processes and methodologies • More than programming • More than requirements analysis (Tsui “objects” to this one; you?) Your thoughts on “architecture centric-ness”?

15. World Wide Web ---- Describe at Arch. Level ? • What is the web? • Multiple ways to describe it depending on the “view” which provided different design decisions (or architecture) • Set of independent resources, interconnected by computing systems, that provide some services • Set of computing programs that interact with each other according to a set of rules specified in standards and protocols such as HTTP, XML, etc. • Set of interactions of agents and servers through interconnected systems . • None of these “views,” even with diagrams, would give us a deep understanding of what the web is. But we can not get into all the details because it would need close to infinite amount ofdescriptions to explain all the programs, all protocols, all data, etc. • Thus we need to describe the “rules” (decisions) by which the main partswork and interact ---- use architectural style ?

16. Observations made in trying to describe the World Wide Web • The architecture of the Web is totally separate from the code that implements all the various parts. (One needs to describe the Web at an architectural level.) • There is no “single” piece of code that implements theweb, and thus neither its architecture --- mixed design • There are multiple, equivalent pieces of code that exist and implement various components of the Web. • The stylistic constraints that constitute the definition of the Web is not apparent in any one piece of the code, but the effects as implemented in all the piecesare evident in the Web ---- showing a mix of architecture/design styles.

17. a specific Architectural Style: Pipe and Filter • Main components: • Filter: processes a stream of input-data to produce some out- put data • Pipe: a conduit that allows the flow of data read input file process file This architecture style focuses on the dynamic (interaction) and forces a fairly simple, sequential structureand flow of data filter pipe * NOTE: Design/Architecture – components (filters) and relations (pipes) ; Style- constraint on architecture (flow is “sequential”)

18. Pipe and Filter : UNIX Influence • UNIX command line processing of the pipe symbol, l the output from the command to the left of the symbol, l, is to be sent as input to the command to the right of the pipe; this mechanism got rid of specifying a file as std output of a command and then specifying that same file as the std input to another command, including possibly removing this intermediate fileafterwards Example ( UNIX commands) : $ cat my.txt i live in the city of Atlanta $cat my.txt I sed “s/i/o/g” o love on the coty of Atlanta $ Example : Assume that in the file called my.txt is the following: i live in the city of Atlanta Note the pipe symbol, l First cat command outputs my.txt to screen. The second catcommand reads my.txt and sends it to sed command which search” for “i’ and “globally replace it with “o.” You can have more “l” and other processing commands, such as sort, to form a sophisticated software.

19. Architecture is critical for ---- Product Family • Software Product family is a set of “related” software components which has i) some common components and ii) some variable components • The variable components provide, for each product within the family, the differentiator by features, by cost (price), by time, etc. • Reuse and cost sharing is the big advantage of common components in Product Family (in reality ---- schedule also played a part)

20. General Requirements (Version 3) Product “Family” ---- and Versioning General Requirements (Version 2) US (common) code v3 General Requirements US (common) code v2 French ( version 3 ) If Fench Version 2.1 came after Version 3, we may need to build a French V3.1 US (common) code v1 French ( version 2 ) French ( version 1 ) French (version 2.1) Japanese ( version 3 ) Japanese ( version 2 ) Japanese ( version 1 ) Brazilian ( version 3) Relook at the “vertical and horizontal” design configuration with “product family” In mind Brazilian ( version 2 ) Brazilian ( version 1 )

21. Summarizing Arch & Design: We Should Ask • What are the major functional components of the architecture? • Decompose the requirements • Synthesize “similar” functionalities into major components • Decompose the major components (& data) into subcomponents • How are the components related? • Structure of relationship under static condition • Dynamic flow of control and flow of data during execution • What elements are needed to “facilitate” the architecture? • Connector elements introduced to bring in versatile interaction • Additional functional components introduced to improve a particular attribute (e.g. security, performance, availability) • How do we design and evaluate various non-functional & behavioral properties? • Performance, security, maintainability, availability, etc. needs to be defined,specified, measured. • What execution environment/platformneeds to be considered and resolved? • Is there any over-riding constraint (e.g. style) that should be invariant? What about data ? Do we need to worry about it ?