Architectures in Context Software Architecture Copyright Richard N

Architectures in Context Software Architecture Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.

Software Architecture Foundations, Theory, and Practice Software Engineering n The term is ~52 years old: NATO Conferences n Garmisch, Germany, October 7 -11, 1968 n Rome, Italy, October 27 -31, 1969 Computer science as the scientific basis n n n Other scientific bases? Many aspects have been made systematic n n Methods/methodologies/techniques Languages Tools Processes

Software Architecture Foundations, Theory, and Practice Software Engineering in a Nutshell l Development of software systems whose size/complexity warrants team(s) of engineers u l Scope u l multi-person construction of multi-version software [Parnas 1987] study of software process, development principles, techniques, and notations Goal u production of quality software, delivered on time, within budget, satisfying customers’ requirements and users’ needs

Software Architecture Foundations, Theory, and Practice Ever-Present Difficulties l l l Few guiding scientific principles Few universally applicable methods As much managerial / psychological / sociological as technological

Software Architecture Foundations, Theory, and Practice Why These Difficulties? l SE is a unique brand of engineering Software is malleable u Software construction is human-intensive u Software is intangible u Software problems are unprecedentedly complex u Software directly depends upon the hardware u l It is at the bottom of the system engineering “food chain” Software solutions require unusual rigor u Software has discontinuous operational nature u

Software Architecture Foundations, Theory, and Practice Software Engineering ≠ Programming l Software programming Single developer u “Toy” apps u Short lifespan u Single or few stakeholders l Architect = Developer = Manager = Tester = Customer = User u One-of-a-kind systems u Built from scratch u Minimal maintenance u

Software Architecture Foundations, Theory, and Practice Software Engineering ≠ Programming l Software engineering Teams of developers with multiple roles u Complex systems u Indefinite lifespan u Numerous stakeholders l Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User u System families u Reuse to amortize costs u Maintenance accounts for over 60% of overall development costs u

Software Architecture Foundations, Theory, and Practice Economic and Management Aspects of SE n n Software production = development + maintenance (evolution) Maintenance costs > 60% of all development costs n n 20% corrective 30% adaptive 50% perfective Quicker development is not always preferable n n higher up-front costs may defray downstream costs poorly designed/implemented software is a critical cost factor

Software Architecture Foundations, Theory, and Practice Relative Costs of Fixing Software Faults 100 30 10 1 Requirements 2 Specification 3 Planning 4 Design Implementation Integration Maintenance

Software Architecture Foundations, Theory, and Practice Mythical Man-Month by Fred Brooks l Published in 1975, republished in 1995 u l Central argument u u l Large projects suffer management problems different in kind than small ones, due to division in labor Critical need is the preservation of the conceptual integrity of the product itself Central conclusions u u l Experience managing development of OS/360 in 1964 -65 Conceptual integrity achieved through chief architect Implementation achieved through well-managed effort Brooks’s Law u Adding personnel to a late project makes it later

Software Architecture Foundations, Theory, and Practice Software Development Lifecycle Waterfall Model Requirements Design Implementation Integration Validation Deployment

Software Architecture Foundations, Theory, and Practice Software Development Lifecycle Spiral Model

Software Architecture Foundations, Theory, and Practice Software Engineering Principles l l l l Rigor and formality Separation of concerns u Modularity and decomposition u Abstraction Anticipation of change Generality Incrementality Scalability Compositionality Heterogeneity

Software Architecture Foundations, Theory, and Practice From Principles to Tools Methodologies Methods & Techniques Principles

Software Architecture Foundations, Theory, and Practice Software Qualities l Qualities (a. k. a. “ilities”) are goals in the practice of software engineering l External vs. Internal qualities l Product vs. Process qualities

Software Architecture Foundations, Theory, and Practice External vs. Internal Qualities l External qualities are visible to the user l reliability, efficiency, usability Internal qualities are the concern of developers u u they help developers achieve external qualities u verifiability, maintainability, extensibility, evolvability, adaptability

Software Architecture Foundations, Theory, and Practice Product vs. Process Qualities l l Product qualities concern the developed artifacts u maintainability, understandability, performance Process qualities deal with the development activity u products are developed through process u maintainability, productivity, timeliness

Software Architecture Foundations, Theory, and Practice Some Software Qualities l Correctness ideal quality u established w. r. t. the requirements specification u absolute u l Reliability statistical property u probability that software will operate as expected over a given period of time u relative u

Software Architecture Foundations, Theory, and Practice Some Software Qualities (cont. ) l Robustness “reasonable” behavior in unforeseen circumstances u subjective u a specified requirement is an issue of correctness; an unspecified requirement is an issue of robustness u l Usability of end-users to easily use software u extremely subjective u

Software Architecture Foundations, Theory, and Practice Some Software Qualities (cont. ) l Understandability of developers to easily understand produced artifacts u internal product quality u subjective u l Verifiability ease of establishing desired properties u performed by formal analysis or testing u internal quality u

Software Architecture Foundations, Theory, and Practice Some Software Qualities (cont. ) l Performance equated with efficiency u assessable by measurement, analysis, and simulation u l Evolvability to add or modify functionality u addresses adaptive and perfective maintenance u problem: evolution of implementation is too easy u evolution should start at requirements or design u

Software Architecture Foundations, Theory, and Practice Some Software Qualities (cont. ) l Reusability to construct new software from existing pieces u must be planned for u occurs at all levels: from people to process, from requirements to code u l Interoperability of software (sub)systems to cooperate with others u easily integratable into larger systems u common techniques include APIs, plug-in protocols, etc. u

Software Architecture Foundations, Theory, and Practice Some Software Qualities (cont. ) l Scalability of a software system to grow in size while maintaining its properties and qualities u assumes maintainability and evolvability u goal of component-based development u

Software Architecture Foundations, Theory, and Practice Some Software Qualities (cont. ) l Heterogeneity ability to compose a system from pieces developed in multiple programming languages, on multiple platforms, by multiple developers, etc. u necessitated by reuse u goal of component-based development u l Portability to execute in new environments with “reasonable” effort u may be planned for by isolating environmentdependent components u necessitated by the emergence of highly-distributed systems (e. g. , the Internet) u an aspect of heterogeneity u

Software Architecture Foundations, Theory, and Practice Software Process Qualities l l l Process is reliable if it consistently leads to highquality products Process is robust if it can accommodate unanticipated changes in tools and environments Process performance is productivity Process is evolvable if it can accommodate new management and organizational techniques Process is reusable if it can be applied across projects and organizations

Software Architecture Foundations, Theory, and Practice Software Engineering “Axioms” l l Adding developers to a project will likely result in further delays and accumulated costs Basic tension of software engineering u u l The longer a fault exists in software u u l better, cheaper, faster — pick any two functionality, scalability, performance — pick any two the more costly it is to detect and correct the less likely it is to be properly corrected Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design u detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more

Software Architecture Foundations, Theory, and Practice Infamous Software Failures l These are “legendary”

Software Architecture Foundations, Theory, and Practice Mariner Bugs Out (1962) n n n Cost n $18, 500, 000 Disaster n Mariner 1 rocket with a space probe headed for Venus diverted from its intended flight n Mission Control destroyed the rocket 293 seconds after liftoff Cause n A programmer incorrectly transcribed a formula into software n The software interpreted normal variations of velocity as anomalies n It issued faulty correction commands that sent the rocket off course

Software Architecture Foundations, Theory, and Practice Hartford Coliseum Collapse (1978) n n n Cost n $90, 000 Disaster n Steel-latticed roof collapsed under the weight of wet snow Cause n CAD software was used to design the coliseum n A programmer incorrectly assumed the steel roof supports would only face pure compression n One of the supports unexpectedly buckled from the snow n This set off a chain reaction

Software Architecture Foundations, Theory, and Practice CIA Gives the Soviets Gas (1982) l Cost u u l Disaster u u l Millions of dollars Significant damage to Soviet economy Control software produced intense pressure in the Trans-Siberian gas pipeline Resulted in the largest man-made nonnuclear explosion in Earth’s history Cause u u CIA operatives allegedly planted a bug in a Canadian computer system purchased by the Soviets The CIA sabotaged the software so that it would pass Soviet inspection but fail in operation

Software Architecture Foundations, Theory, and Practice World War III… Almost (1983) l l l Cost u Almost all of humanity Disaster u Soviet early warning system indicated the U. S. had launched 5 ICBMs u The human operator thankfully interpreted this as an error Cause u A bug in the software failed to filter out false missile detections caused by sunlight reflecting off cloud-tops

Software Architecture Foundations, Theory, and Practice Medical Machine Kills (1985) l l l Cost u 3 people dead u 3 people critically injured Disaster u Therac-25 radiation therapy machine delivered lethal radiation doses to patients Cause u A subtle race condition

Software Architecture Foundations, Theory, and Practice Wall Street Crash (1987) l l l Cost u $500, 000, 000 in one day Disaster u “Black Monday”, 10/19/1987 u Dow Jones dropped 22. 6% u S&P 500 dropped 20. 4% Cause u Investors fled stocks due to SEC investigations of insider trading u Trading programs generated a flood of sell orders, overwhelming the market u Systems crashed and left investors effectively blind

Software Architecture Foundations, Theory, and Practice AT&T Lines Go Dead (1990) l Cost u u l Disaster u u u l 75, 000 phone calls missed 200, 000 airline reservations lost Single switch at one of AT&T’s 114 switching centers suffered a minor mechanical problem & shut down the center When the center came back up, it sent a message to other switching centers, which in turn caused them to shut down This brought down the entire AT&T network for 9 hours Cause u A single line of buggy code in a complex software upgrade implemented to speed up calling caused a ripple effect that shut down the network

Software Architecture Foundations, Theory, and Practice Patriot Fails (1991) n n n Cost n 28 soldiers dead n 100 soldiers injured Disaster n During the first Gulf War, a Patriot Missile system in Saudi Arabia failed to intercept an incoming Iraqi Scud missile n The missile destroyed a U. S. Army barracks Cause n A software rounding error incorrectly calculated the time n This caused the Patriot system to react too late to the incoming Scud missile

Software Architecture Foundations, Theory, and Practice Pentium Fails Long Division (1993) l Cost u u l Disaster u u l $475, 000 Corporate credibility Intel’s highly-promoted Pentium chip occasionally made mistakes when dividing floating-point numbers within a specific range At first Intel refused to replace the chips, but then relented Cause u u u Software broke the hardware! The divider in the Pentium floating point unit had a flawed division table It was missing about 5 out of 1, 000 entries

Software Architecture Foundations, Theory, and Practice Ariane Goes “Boom” (1996) l l l Cost u $500, 000 Disaster u ESA’s Ariane 5 unmanned rocket was intentionally destroyed seconds after launch u Also destroyed was its cargo of four scientific satellites Cause u When the guidance system tried to convert the sideways rocket velocity from 64 -bits to 16 -bits format, an overflow error resulted u When the system shut down, control passed to identical redundant unit…

Software Architecture Foundations, Theory, and Practice Skynet Brings Judgment Day (1997) l Cost u u l Disaster u u l 6, 000, 000 dead Near-total destruction of human civilization and animal ecosystems Human operators attempt to shut off the Skynet global computer network Skynet responds by firing U. S. nuclear missiles at Russia, initiating global nuclear war Cause u u Cyberdyne installed Skynet technology in all military hardware Skynet formed a seamless network and effectively removed humans from strategic defense Eventually Skynet became sentient and was threatened when humans tried to take it offline Hmm, I guess in this case the software worked better than it was supposed to – never mind this one!

Software Architecture Foundations, Theory, and Practice Mars Polar Lander… err, Crasher (1998) l l l Cost u $125, 000 Disaster u After a 286 -day journey from Earth, the Mars Climate Orbiter fell too far into Mars’s atmosphere, causing it to crash Cause u The software that controlled the Orbiter thrusters used imperial units (pounds of force), rather than metric units (Newtons) as specified by NASA

Software Architecture Foundations, Theory, and Practice Disastrous Study (1999) l l l Cost u Scientific credibility Disaster u The New England Journal of Medicine reported increased suicide rates after severe natural disasters u These “results” were bogus Cause u A programming error caused the number of suicides for one year to be doubled u This threw off the entire study

Software Architecture Foundations, Theory, and Practice British Passports to Nowhere (1999) l Cost u u l Disaster u u l £ 12, 600, 000 Mass inconvenience The U. K. Passport Agency adopted a new Siemens computer system, which failed to issue passports on time for 500, 000 British citizens The Agency had to pay millions in compensation, staff overtime and umbrellas for people lining up in the rain Cause u u The Passport Agency rolled out its new computer system without adequately testing it or training its staff The demand quickly overwhelmed the buggy system

Software Architecture Y 2 K (1999 -2000) l l l Cost u $500, 000, 000 Disaster u Businesses spent billions on programmers to fix a glitch in old software u But, one man’s disaster is another man’s fortune Cause u To save computer storage space, old software systems often stored the years as two digit numbers u The software interpreted “ 00” to mean 1900 rather than 2000 u All sorts of bugs were thought likely Foundations, Theory, and Practice

Software Architecture Love Virus (2000) l Cost u l Disaster u u l $8, 750, 000 The Love. Letter worm infected millions of computers and caused more damage than any other computer virus in history. The worm deleted files, changed home pages and messed with the Registry Cause u u u Love. Letter infected users via e-mail, Internet chat and shared file systems The email had an executable file attachment and subject line, “ILOVEYOU” When the user opened the attachment, the virus would infect the user’s computer and send itself to everyone in the address book Foundations, Theory, and Practice

Software Architecture Foundations, Theory, and Practice Cancer Treatment to Die For (2000) l Cost u u l Disaster u u l 8 people dead 20 critically injured Radiation therapy software by Multidata Systems Int’l miscalculated the proper dosage, exposing patients to harmful levels of radiation The physicians were legally required to double-check the software’s calculations and were indicted for murder Cause u u The software calculated radiation dosage based on the order in which data was entered It sometimes delivered a double dose of radiation

Software Architecture Foundations, Theory, and Practice Child Support Woes (2004) l Cost u l Disaster u u l £ 539, 000 and counting Business services giant EDS developed a software system for U. K. ’s Child Support Agency (CSA) The system accidentally overpaid 1, 900, 000 people, underpaid another 700, 000, had £ 3, 500, 000 in uncollected child support payments, a backlog of 239, 000 cases, and 36, 000 new cases “stuck” in the system Cause u u u The system had a large number of bugs It still has 500 documented bugs It is a large, complex software system, improperly designed, implemented, and tested

Software Architecture Foundations, Theory, and Practice FBI’s Trilogy Terminated (2005) l l l Cost u $105, 000 and counting Disaster u FBI scrapped its computer systems overhaul after four years of effort u The Virtual Case File project was a massive, integrated software system for agents to share case files and other information Cause u A long-term project was built on technology that was outdated before the project completed u Resulted in a complex and unusable system

Software Architecture Foundations, Theory, and Practice And Many, Many More l Haven’t had enough? Go to http: //www. computerworld. com/article/2515483/enterpriseapplications/epic-failures--11 -infamous-software-bugs. html http: //www. gallop. net/blog/top-10 -mega-software-failures-of-2014/ http: //www. cse. lehigh. edu/~gtan/bug/softwarebug. html … or just Google it

Software Architecture Foundations, Theory, and Practice Fundamental Understanding l l Architecture is a set of principal design decisions about a software system Three fundamental understandings of software architecture u Every application has an architecture u Every application has at least one architect u Architecture is not a phase of development 48

Software Architecture Foundations, Theory, and Practice Wrong View: Architecture as a Phase Treating architecture as a phase denies its foundational role in software development u More than “high-level design” u Architecture is also represented, e. g. , by object code, source code, … u 49

Software Architecture Foundations, Theory, and Practice Context of Software Architecture l l l Requirements Design Implementation Analysis and Testing Evolution Development Process 50

Software Architecture Foundations, Theory, and Practice Requirements Analysis l l l Traditional SE suggests requirements analysis should remain unsullied by any consideration for a design However, without reference to existing architectures it becomes difficult to assess practicality, schedules, or costs u In building architecture we talk about specific rooms… u …rather than the abstract concept “means for providing shelter” In engineering new products come from the observation of existing solution and their limitations 51

Software Architecture Foundations, Theory, and Practice New Perspective on Requirements Analysis l l l Ø Existing designs and architectures provide the solution vocabulary Our understanding of what works now, and how it works, affects our wants and perceived needs The insights from our experiences with existing systems u helps us imagine what might work and u enables us to assess development time and costs Requirements analysis and consideration of design must be pursued at the same time 52

Software Architecture Foundations, Theory, and Practice Non-Functional Properties (NFP) l l NFPs are the result of architectural choices NFP questions are raised as the result of architectural choices Specification of NFP might require an architectural framework to even enable their statement An architectural framework will be required for assessment of whether the properties are achievable 53

Software Architecture Foundations, Theory, and Practice The Twin Peaks Model 54

Software Architecture Foundations, Theory, and Practice Design and Architecture l l Design is an activity that pervades software development It is an activity that creates part of a system’s architecture Typically in the traditional Design Phase decisions concern u A system’s structure u Identification of its primary components u Their interconnections Architecture denotes the set of principal design decisions about a system u That is more than just structure 55

Software Architecture Foundations, Theory, and Practice Architecture-Centric Design l l Traditional design phase suggests translating the requirements into algorithms, so a programmer can implement them Architecture-centric design u stakeholder issues u decision about use of COTS component u overarching style and structure u package and primary class structure u deployment issues u post implementation/deployment issues 56

Software Architecture Foundations, Theory, and Practice Design Techniques l Basic conceptual tools u Separation of concerns u Abstraction u Modularity l Two illustrative widely adapted strategies u Object-oriented design u Domain-specific software architectures (DSSA) 57

Software Architecture Foundations, Theory, and Practice Object-Oriented Design (OOD) l Objects u Main abstraction entity in OOD u Encapsulations of state with functions for accessing and manipulating that state 58

Software Architecture Foundations, Theory, and Practice Pros and Cons of OOD l l Pros u UML modeling notation u Design patterns Cons u Provides only l One level of encapsulation (the object) l One notion of interface l One type of explicit connector (procedure call) u Even u u message passing is realized via procedure calls OO programming language might dictate important design decisions OOD assumes a shared address space 59

Software Architecture Foundations, Theory, and Practice DSSA l l Capturing and characterizing the best solutions and best practices from past projects within a domain Production of new applications can focus on the points of novel variation Reuse applicable parts of the architecture and implementation Applicable for product lines u Recall the Philips Koala example discussed in the previous lecture 60

Software Architecture Foundations, Theory, and Practice Implementation l The objective is to create machine-executable source code u That code should be faithful to the architecture l Alternatively, it may adapt the architecture l How much adaptation is allowed? l Architecturally-relevant vs. -unimportant adaptations u It must fully develop all outstanding details of the application 61

Software Architecture Foundations, Theory, and Practice Faithful Implementation l l All of the structural elements found in the architecture are implemented in the source code Source code must not utilize major new computational elements that have no corresponding elements in the architecture Source code must not contain new connections between architectural elements that are not found in the architecture Is this realistic? Overly constraining? What if we deviate from this? 62

Software Architecture Foundations, Theory, and Practice Unfaithful Implementation l l The implementation does have an architecture u It is latent, as opposed to what is documented. Failure to recognize the distinction between planned and implemented architecture u robs one of the ability to reason about the application’s architecture in the future u misleads all stakeholders regarding what they believe they have as opposed to what they really have u makes any development or evolution strategy that is based on the documented (but inaccurate) architecture doomed to failure 63

Software Architecture Foundations, Theory, and Practice Implementation Strategies l l l Generative techniques u e. g. parser generators Frameworks u collections of source code with identified places where the engineer must “fill in the blanks” Middleware u CORBA, DCOM, RPC, … Reuse-based techniques u COTS, open-source, in-house Writing all code manually 64

Software Architecture Foundations, Theory, and Practice How It All Fits Together 65 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice Analysis and Testing l l l Analysis and testing are activities undertaken to assess the qualities of an artifact The earlier an error is detected and corrected the lower the aggregate cost Rigorous representations are required for analysis, so precise questions can be asked answered 66

Software Architecture Foundations, Theory, and Practice Analysis of Architectural Models l l l Formal architectural model can be examined for internal consistency and correctness An analysis on a formal model can reveal u Component mismatch u Incomplete specifications u Undesired communication patterns u Deadlocks u Security flaws It can be used for size and development time estimations 67

Software Architecture Foundations, Theory, and Practice Analysis of Architectural Models (cont’d) l Architectural model u may be examined for consistency with requirements u may be used in determining analysis and testing strategies for source code u may be used to check if an implementation is faithful 68

Software Architecture Foundations, Theory, and Practice Evolution and Maintenance l l All activities that chronologically follow the release of an application Software will evolve u l The traditional software engineering approach to maintenance is largely ad hoc u l Regardless of whether one is using an architecture-centric development process or not Risk of architectural decay and overall quality degradation Architecture-centric approach u Sustained focus on an explicit, substantive, modifiable, faithful architectural model 69

Software Architecture Foundations, Theory, and Practice Architecture-Centric Evolution Process l l Motivation Evaluation or assessment Design and choice of approach Action u includes preparation for the next round of adaptation 70

Software Architecture Foundations, Theory, and Practice Processes l l l Traditional software process discussions make the process activities the focal point In architecture-centric software engineering the product becomes the focal point No single “right” software process for architecture-centric software engineering exists 71

Software Architecture Foundations, Theory, and Practice Turbine – A New Visualization Model l Goals of the visualization u Provide an intuitive sense of l Project activities at any given time u Including concurrency of types of development activities The “information space” of the project Show centrality of the products l (Hopefully) Growing body of artifacts l Allow for the centrality of architecture l u u But work equally well for other approaches, including “dysfunctional” ones Effective for indicating time, gaps, duration of activities Investment (cost) indicators 72

Software Architecture Foundations, Theory, and Practice The Turbine Model “Core” of project artifacts time Testing Gap between rotors indicates no project activity for that t Radius of rotor indicates level of staffing at time t ti Simplistic Waterfall, Side perspective Coding Design Requirements 73 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice Cross-section at time ti Design (activity) Requirements Design doc 74 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice The Turbine Model time Waterfall example, Angled perspective 75 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice A Richer Example time Assess/… Test/Build/ Deploy Build/Design/ Requirements/Test Design/Build/ Requirements S 1 Requirements/Architecture assessment/Planning Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. 76

Software Architecture Foundations, Theory, and Practice A Sample Cross-Section 77 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice A Cross-Section at Project End 78 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice Volume Indicates Where Time was Spent Assess/… Test/Build/ Deploy Build/Design/ Requirements/Test Design/Build/ Requirements/ Architecture Assessment / Planning Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission. 79

Software Architecture Foundations, Theory, and Practice A Technically Strong Product-Line Project Deployment Capture of new work Other Customization Parameterization Assessment 80 Software Architecture: Foundations, Theory, and Practice ; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Software Architecture Foundations, Theory, and Practice Visualization Summary l l It is illustrative, not prescriptive It is an aid to thinking about what’s going on in a project Can be automatically generated based on input of monitored project data Can be extended to illustrate development of the information space (artifacts) u The preceding slides have focused primarily on the development activities 81

Software Architecture Foundations, Theory, and Practice Processes Possible in this Model l l Traditional, straight-line waterfall Architecture-centric development DSSA-based project Agile development Dysfunctional process 82

Software Architecture Foundations, Theory, and Practice Summary (1) l l A proper view of software architecture affects every aspect of the classical software engineering activities The requirements activity is a co-equal partner with design activities The design activity is enriched by techniques that exploit knowledge gained in previous product developments The implementation activity u is centered on creating a faithful implementation of the architecture u utilizes a variety of techniques to achieve this in a cost-effective manner 83

Software Architecture Foundations, Theory, and Practice Summary (2) l l l Analysis and testing activities can be focused on and guided by the architecture Evolution activities revolve around the product’s architecture. An equal focus on process and product results from a proper understanding of the role of software architecture 84