1 / 16

So --- Why Software Architecture?

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.

demont
Download Presentation

So --- Why Software Architecture?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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. Architecture Design Coding

  2. Software Architecture • Your Text: “ A system’s architecture is the set of principaldesign decisions made during its development and any subsequent evolution.” • Tsui modifies it to say: “ A system’s architecture is the result ofa setof principal design decisions made and documented (in design document, code, etc.) during its development and subsequent evolution • There is no “standard” definition of software architecture, yet; there are more definitions in Chapter 3 of your text What do you all think ?

  3. A Definition from McMaster Univ. (Canada) • Architectural Design (the designing activity) The process of i) identifying the components and ii) establishinga framework forcontrol andcommunications of these components • Software Architecture (the product from designing) The documented output from the architectural design activities.

  4. Architecture-Centric • Architecture-Centric approach to software development places an emphasis on “design” with an aim for: • Good quality (e.g. defects) and many attributes • Cost-effective development • High leveraging of past experiences

  5. Analogy to Physical Building • Software architecture and physical building architecture similarities: • Architecture exist independently from, but strongly linked to, the (building) code • Properties of the (structures) software 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 activities • Architecture has matured into a discipline of its own with many architectural (building) design styles. (this one may be questionable)

  6. 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 etc. Style is a set of “constraints” placed on the design to achieve certain properties

  7. Some Differences from Physical Building • Buildings have been around for a much longer time than software; so a lot less is known about 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 frequent, later in development stage, bigger in magnitude.

  8. 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: firmness: No Bugs (or less bugs) commodity: functionalities that satisfy the requirements delight: pleasurable experience (usage experience) • Paraphrasing (Winograd-Stanford U.): “ --- architects and designers work with commodity and delight, and the engineersworks with firmness ----”

  9. 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?)

  10. World Wide Web ---- Needs Architectural Description • What is the web? • Multiple ways to describe it depending on the “view” • 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 ?

  11. 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. • 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.

  12. 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 filter This architecture style focuses on the dynamic (interaction) and forces a fairly simple, sequential structure; pipe

  13. 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” I 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.

  14. Architecture 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 Product Family (in reality ---- schedule also played a part)

  15. 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) Brazilian ( version 2 ) Brazilian ( version 1 )

  16. 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 into subcomponents • How are the components related? • Structure of relationship under static condition • Dynamic flow of control and 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, 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/platform needs to be considered and resolved? • Is there any over-riding constraint (e.g. style) that should be invariant?

More Related