• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
S2047   arquitetura e os modelos ágeis

S2047 arquitetura e os modelos ágeis



Arquitetura e Modelos Ageis, extreme programming development, pair programming

Arquitetura e Modelos Ageis, extreme programming development, pair programming



Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    S2047   arquitetura e os modelos ágeis S2047 arquitetura e os modelos ágeis Document Transcript

    • focus software architectureSoftware Architecture-Centric Methods and AgileDevelopment Robert L. Nord and James E. Tomayko, Software Engineering Institute he agile software development paradigm and plan-driven ap- T Including proaches each have their strengths and shortcomings. The for- architecture-centric mer emphasizes rapid, flexible development, while the latter em- design and analysis phasizes project and process infrastructure. Many practitioners, methods in the particularly of agile methods, tend to view software architecture in light of Extreme the plan-driven side of the spectrum. They think that architecture-centric Programming methods are too much work, equating them with high-ceremony processes framework helps address quality emphasizing document production. But many Software architecture and XP elements make up a successful development In the XP development model (see figure 1a), attributes in an approach, including process, product, technol- the customer records the required system func- explicit, methodical, ogy, people, and tools. Software architecture is tionality at the beginning of each development it- engineering- part of product quality and isn’t tied to a par- eration in the form of user stories. During plan- ticular process, technology, culture, or tool. ning, the customer and developers determine principled way. For the past 10 years, the Software Archi- what functionality to develop for the current it- tecture Technology Initiative at Carnegie Mel- eration. User stories also contain descriptions of lon University’s Software Engineering Institute test situations. The customer and development has developed and promulgated a series of ar- team derive these tests from the specifications. chitecture-centric methods for architecture de- The developers design the programming inter- sign and analysis. These methods are now at face to match the tests’ needs, and they write the the point where the SEI is fitting them into code to match the tests and the interface. They popular software development processes. This refine the design to match the code’s needs. article explores the relationship and synergies The design that emerges is a product of the between architecture-centric design and analy- relevant user stories that have been identified. sis methods and the Extreme Programming But the architecture depends, for its shape and framework.1 We chose to focus on XP because quality, on the development team’s experience. it’s one of the most mature and best-known Architecture-centric activities (see figure 1b) agile practices. (For further information on ag- can inform and regularize the development ile methods, see the “Related Work on Agile process by emphasizing quality attributes and Approaches” sidebar on page 48.) focusing early on architectural decisions.0740-7459/06/$20.00 © 2006 IEEE March/April 2006 IEEE SOFTWARE 47
    • Related Work on Agile Approaches Recent work shows how you can use architecture-centric ac- ing method selection (personnel, dynamism, culture, size, andtivities to balance agile and plan-driven approaches, exploiting criticality). They partition the dimension space into two hometheir strengths while compensating for their weaknesses. In situ- grounds—agile and plan-driven approaches—within these di-ations where requirements change rapidly and an agile approach mensions, recognizing that hybrid approaches exist at the bound-is warranted, architectural concepts can enhance the process of ary.4 They demonstrate a solution for adapting XP to developdesigning a system that will meet its requirements. complex, large-scale applications by introducing elements of Students participating in studio projects in the masters of soft- plan-driven methods. These elements include high-level architec-ware engineering program at Carnegie Mellon University have tural plans to provide essential big-picture information and us-been using the Architecture-Centric Development Method,1 which ing design patterns and architectural solutions rather than sim-uses concepts from the SEI’s architecture-centric design and ple design to handle foreseeable change. Including architectureanalysis methods, in this way. When developing complex, large- in this way might also delay refactoring. However, investing inscale applications, many have reported that agile methods must architecture means that it will take longer to get to code, be-be adapted to include more kinds of architectural information. cause the first iteration is what some people call a zero-featureWe see evidence of this in the zero-feature release, the architec- release. In such a release, the architecture is in place, but thetural spike, and agile practices that recognize the architect role. organization doesn’t deliver any user-visible features to the Steve McConnell lists the evolutionary delivery life cycle as a customer.best practice.2 Evolutionary delivery recognizes an architecture Paul McMahon offers insights into extending agile approachesactivity and strikes a balance between the control a staged de- to large, distributed projects by employing an agile architecture.5livery life cycle offers and the flexibility of evolutionary proto- With Don Procuniar and Dennis Rushing, he demonstrates thistyping. The degree to which it moves in one direction depends approach’s success in a case study.6on the extent to which it accommodates customer change re-quests. An emphasis on the system features visible to the customer References 1. A.J. Lattanze, The Architecture Centric Development Method, tech. report CMU-moves it in the direction of evolutionary prototyping, while an em- ISRI-05-103, Inst. for Software Research Int’l, Carnegie Mellon Univ., 2005.phasis on the system’s core architecture (which customer feedback 2. S. McConnell, Rapid Development: Taming Wild Software Schedules, Mi-is unlikely to change) moves it in the direction of staged delivery. crosoft Press, 1996. Alistair Cockburn uses three indices (communication load, 3. A. Cockburn, Agile Software Development, Addison-Wesley, 2002.criticality, and project priorities) to characterize projects and 4. B. Boehm and R. Turner, Balancing Agility and Discipline: A Guide for the Perplexed, Addison-Wesley, 2004.recognizes that different project characteristics need different 5. P.E. McMahon, “Extending Agile Methods: A Distributed Project and Orga-methods.3 He characterizes Extreme Programming (XP) as being nizational Improvement Perspective,” CrossTalk: The J. Defense Softwaresuitable for projects with four to 14 people that have a criticality Eng., vol. 18, no. 5, May 2005, pp. 16–19.where defects won’t cause loss of life. For larger projects, Cock- 6. D. Procuniar, P. McMahon, and D. Rushing, “AVCATT-A: A Case Study of a Successful Collaborative Development Project,” Proc. 2001 Interservice/burn recognizes the architect role. Industry Training, Simulation and Education Conf. (I/ITSEC), Nat’l Defense Barry Boehm and Richard Turner use five dimensions affect- Industrial Assoc., 2001, pp. 920–930. The Quality Attribute Workshop (QAW)2 and getting early feedback on risks. The devel- can help the development team understand the opment team can use incremental design prac- problem by eliciting quality attribute require- tices to develop a detailed design and imple- ments in the form of scenarios. Basing the sce- mentation from the architecture. Architectural narios on business goals ensures that the de- conformance and reconstruction techniques velopers address the right problems. The ensure consistency between the architecture Attribute-Driven Design (ADD) method3 de- and implementation. fines a software architecture by basing the de- These SEI methods can enhance XP prac- sign process on the prioritized quality attri- tices. Using these methods results in an archi- bute scenarios that the software must fulfill. It tecture-centric approach: architecture connects helps identify the most important things to do business goals to the implementation, quality to ensure that the design is on track to meet- attributes inform the design, and architecture- ing key quality attribute concerns and deliver- centric activities drive the software system life ing value to the customer. The Architecture cycle. These methods make developing soft- Trade-off Analysis Method (ATAM)4 and ware easier and more consistent. Although de- Cost-Benefit Analysis Method (CBAM)3 pro- signing the architecture is integral to the ap- vide detailed guidance on analyzing the design proach, the level of detail can be flexible.48 IEEE SOFTWARE w w w . c o m p u t e r. o r g / s o f t w a r e
    • Figure 1. Development A B B pulls information from A models: (a) Extreme Programming and (b) Test architecture-centric. Stories Specification Design Implementation (a) Synthesis of B from A Quality attribute A B Evaluation of B relative to A Views and beyond scenarios Quality Attribute- Attribute Driven Workshop Design Business Design and Specification Architecture goals implementation Architecture Trade-off Architectural Analysis Method conformance and Cost-Benefit (b) Analysis MethodIdentifying requirements: user stories. Unless otherwise directed, stake-The Quality Attribute Workshop holders tend to focus on functionality, not on In an XP project, system analysts elicit, quality attributes. The QAW provides an ex-capture, document, and analyze requirements. plicit method for gathering quality attributeAfter examining user stories at each iteration’s information in a six-part scenario format:beginning, system analysts lead and coordi- stimulus, source of the stimulus, artifact, envi-nate requirements elicitation and modeling by ronment, response, and response measure.outlining the system’s functionality and delim- A QAW would be appropriate for an XPiting the system. The result is a specification of project’s first iteration, helping identify keydetails for the system’s functionality. quality attribute requirements. During a one- The QAW, held early in the development day workshop, participants brainstorm andprocess during XP story production, can help refine a set of scenarios. Stakeholders attend-show quality attribute requirements in the ing the workshop include the on-site customerform of scenarios. The QAW is a facilitated and others with an interest in the system—formethod that engages system stakeholders early example, end users, maintainers, project man-in the life cycle to discover a software-inten- agers, development team members, testers,sive system’s driving quality attribute require- and integrators. Facilitators who aren’t stake-ments. The QAW is system-centric, focuses on holders act as QAW analysis team members.stakeholders, and occurs before the software In subsequent iterations, the developers canarchitecture’s creation. collaborate with the on-site customer to elicit Quality attribute scenarios are much like and refine additional scenarios as needed. March/April 2006 IEEE SOFTWARE 49
    • This approach gives developers guidelines give them information, if not encourage them for being more precise about quality attributes. to build the test cases. This way of using theThe ADD method It also enhances the planning and story-genera- tion processes by emphasizing business goals, scenarios fits in with XP’s “test first” or “build for the test” philosophy; test cases are available focuses on stakeholders, and quality attributes’ role in to test whether or not the code implements the something XP shaping the architectural design. Business goals requirements, early in the development process. developers are elicited and refined during the QAW. The customer can use them to organize existing user Early design: The ADD methodoften ignore— stories, inspire additional ones, or prioritize re- XP developers grow systems incrementally. the overall quirements according to business needs. The scenarios can help determine what’s within and When a system doesn’t support new function- ality, they refactor the design. The first itera- system what’s outside the system’s scope and can lead tion plays a crucial role in defining the sys- structure that to the creation or refinement of a system con- tem’s overall structure, whether it’s implicit text diagram or its equivalent. Scenario genera- (the architecture emerges after implementing the quality tion can also lead to the creation of use cases. the first round of stories) or explicit. attributes The XP practice of using an on-site cus- The ADD method focuses on something XP shape. tomer is sometimes criticized. The idea is that keeping the customer on-site speeds communi- developers often ignore—the overall system structure that the quality attributes shape. This cation and provides a more accurate account- focus should occur in the first iteration and re- ing of changed requirements. Opponents figure cur in later iterations, as substantial changes to that anyone the customer is willing to give up the software architecture need to be explored. as a permanent loan to the development group The development team can keep the architec- is either junior level and lacking experience or ture, quality attributes, and constraints on a too technical. Stakeholders’ points of view whiteboard in the workroom where everyone aren’t always easy to obtain; although on-site, can see it. the customer is sometimes removed from ADD differs from XP’s core practices be- knowing end users’ and other stakeholders’ cause it emphasizes addressing quality attri- needs. Gathering stakeholders during the QAW bute requirements explicitly using architec- complements the on-site customer that XP pre- tural tactics. The quality attributes shape the scribes. To be successful, the workshop must architecture’s structure, and functionality is al- gather a wide group of stakeholders from the located to that structure. The architecture organization. The QAW engages those stake- helps localize the effects of design changes that holders to discover and prioritize the quality at- are caused by changing the functional require- tributes. The workshop setting facilitates open ments; the architecture is influenced by the communication among the stakeholders and quality attribute requirements and isn’t af- provides a forum where they can discuss con- fected by changing functional requirements. flicts or trade-offs among the requirements. The architecture represents the most impor- In addition to these more immediate benefits, tant design choices. Because this is the first ar- quality attribute scenarios continue to provide ticulation of the architecture, it’s necessarily benefits during later development phases. The coarse grained. More detailed XP design ac- development team should keep stakeholders’ tivities begin where ADD ends. concerns and any other rationale information ADD follows a recursive decomposition they capture in a format they can include in the process where, at each decomposition stage, architecture documentation—usually on a pub- the development team chooses architectural lic whiteboard. Stories provide input for analy- tactics and patterns to satisfy a set of quality sis throughout the system’s life and can drive the attribute scenarios. An architectural tactic is a system’s development. means of satisfying a quality-attribute-response Scenarios can also help the customer prepare measure (such as average latency or mean time the acceptance test suite that will grow with the to failure) by manipulating some aspect of a product. Typically, customers develop user sto- quality attribute model (such as performance- ries for requirements and then work on accept- queuing models or reliability Markov models) ance test cases for the end of development. through architectural design decisions. In this Many customers don’t know how to build these way, tactics provide a “generate and test” ar- test cases. The quality attribute scenarios can chitectural design model.50 IEEE SOFTWARE w w w . c o m p u t e r. o r g / s o f t w a r e
    • The ADD method supports both a breadth- on achieving business goals. The CBAM pro-first and a depth-first decomposition approach vides more details on architecture decisions’to design. The order of decomposition will varyon the basis of the business context, domain business consequences, letting the develop- ment team make informed choices among ar- The ATAMknowledge, and changing technology. For ex- chitectural options. assessesample, ADD supports an XP approach by al- Example architecturallowing an initial breadth-first decompositionfor the first decomposition level, followed by To understand how architecture concepts decisions’depth-first decompositions to explore the risks and methods complement XP and address some consequencesassociated with change through prototyping. The ADD method creates and documents a of its shortcomings, consider an automated teller machine that’s part of a bank automation in light ofsoftware architecture using views. The proj- system. The ATM’s feature requirements are quality attributeect’s nature determines the views—most com- those the customer desires and are part of the requirementsmonly, a module decomposition view, a con- XP user stories. However, other system quali-currency view, and/or a deployment view. The ties are important in addition to its functional- and business“Views and Beyond” approach to document- ity. For example, modifiability properties dic- goals.ing software architectures describes these tate that the system must be easily changeableviews.5 It also describes a process for choosing so that the customer can exploit new platformappropriate views on the basis of stakehold- capabilities, and it must be extensible to let theers’ needs. These views allow the developers customer add new functions and business rules.greater flexibility and the opportunity to defer In addition, performance requirements specifymaking more detailed decisions until the that ATM users must get a response from theproper time. The module view fits XP’s itera- system in less than 10 seconds.tive development quite well. Through the QAW process, we would refine vague requirements into several six-part scenar-Early analysis: ATAM and CBAM ios. For example, the following modifiability By this time, still early in the process, XP scenarios would be typical of an ATM system:practitioners will work on stories augmentedby scenarios and the architectures they devel- ■ A developer wants to add a new auditingoped following the ADD method. They can do business rule at design time in 10 person-ATAM and CBAM right after this to track days without affecting other functionality.technical and business risks early in the ■ A system administrator wants to employ aprocess and to help prioritize stories for the new database in 18 person-months with-next release. The ATAM and CBAM help out affecting other functionality.practitioners understand how design decisions ■ A developer needs to add a Web-basedthey make while creating a complex system ar- client in 90 person-days without affectingchitecture will interact. the existing ATM client’s functionality. The ATAM’s purpose is to assess architec-tural decisions’ consequences in light of qual- To achieve these requirements, XP empha-ity attribute requirements and business goals. sizes incremental design and relies on the ar-It helps stakeholders ask the right questions to chitect’s experience and knowledge to creatediscover potentially problematic architectural the design. The ADD method provides moredecisions. Developers can then make risks the details on how we’ll need to employ one orfocus of mitigation activities, such as further more architectural tactics. In the case of mod-design and analysis and prototyping. They can ifiability, relevant architectural tactics includeidentify and document trade-offs explicitly. Localize Changes and Use an Intermediary. The CBAM helps make the architectural de- The Localize Changes tactic suggests that wecision analysis performed during the ATAM should localize the business rules, database,part of a strategic roadmap for software design and client into components. The Use an Inter-and evolution by associating priorities, costs, mediary tactic suggests that we should sepa-and benefits with each architectural decision. rate these components to insulate them from The ATAM adds value by defining a step- each other’s potential changes. A three-tierby-step architecture-evaluation approach that client-server model would emerge from apply-produces risk themes and shows their impact ing the Localize Changes tactic; this architec- March/April 2006 IEEE SOFTWARE 51
    • Figure 2. A deploymentview of a candidatearchitecture using UML Web client <<XML>>notation. Web server (presentation) Transaction <<ODBC>> Load Database server balancer server (business rules) ATM client ture allocates the client, database, and busi- chitecture. When using ADD, tactics and a ness rules to their own tiers, localizing the ef- structured set of steps provide design guidance fects of any changes to a single tier. The Use an for each tier’s creation. In this way, we can cre- Intermediary tactic suggests that an abstract ate each architectural structure via an engineer- interface (such as a data access layer that uses ing process that codifies experience and best open database connectivity, or ODBC, be- practices. tween the business rules and the database) and Architectural decisions are complex and in- a translation layer between the business rules teract. For example, we must analyze the de- and the client that understands the Extensible gree to which changes in the database schema Markup Language (XML) should mediate will affect the business rules, Web server, or communication between the tiers. Such inter- client software. Each abstraction layer (XML mediaries simplify adding new databases or and ODBC) will mask some class of changes clients. For example, they enable us to add a and expose others. And each layer will impose Web-based client and server to the architec- a performance cost. Similarly, adding a load- ture without affecting the ATM client. balancing component will create additional To achieve the “10-second latency on a computation and communication overhead withdrawal” requirement, we employ a differ- but provide the ability to distribute the load ent set of architectural tactics. Because we can’t among a larger resource pool. control resource demand with an ATM (or, We need a way to understand how design more precisely, because doing so would be bad decisions made during the creation of a com- for business), we must look toward managing plex system architecture will interact. XP or arbitrating resources to meet performance doesn’t address evaluating the design explic- goals. By employing the Introduce Concurrency itly; code is tested continuously and offers and Increase Available Resources tactics, we feedback to the design. The ATAM provides can choose to deploy additional database software architects with a framework for un- servers and business rule servers or to make any derstanding the technical trade-offs and risks of them multithreaded so that they can execute they face as they make architectural design de- multiple requests in parallel. Once we have cisions. Additionally, the CBAM helps archi- multiple resources, we need some way of arbi- tects consider the return on investment of any trating among them. So, we introduce a new architectural decision and provides guidance component—a load balancer—that employs a on the economic trade-offs involved. resource arbitration tactic such as Fixed-Prior- ity Scheduling or First-In First-Out Scheduling. Summary This component will ensure that the processing Table 1 illustrates how the software architec- load is distributed among the system’s resources ture-centric concepts and methods complement according to a chosen scheduling policy. XP activities. Architecture-centric methods pro- This leads us to the design in figure 2. This vide explicit and detailed guidance on eliciting example isn’t to show a sophisticated architec- the architectural requirements, designing the ar- ture’s development in its entirety (clearly, we chitecture, and analyzing the resulting design. must do more work to turn this into a com- Including SEI methods addresses quality at- plete design specification for development), but tributes in an explicit, methodical, engineering- rather to emphasize how we arrived at the ar- principled way. Architecture-centric methods52 IEEE SOFTWARE w w w . c o m p u t e r. o r g / s o f t w a r e
    • Table 1 Extreme Programming and architecture-centric activities Extreme Programming Value added through software architecture-centric activities activities Planning and stories Business goals determine quality attributes (using the Quality Attribute Workshop): ■ User stories are supplemented by quality attribute scenarios that capture stakeholders’ concerns regarding quality attribute requirements. ■ Scenarios help stakeholders communicate quality attribute requirements to developers so that they can influence design. Scenario prioritization and refinement give the customer and developers additional information to help them choose stories for each iteration. ■ During a one-day workshop, additional stakeholders supplement the on-site customer. Cost-effective methods facilitate interaction among a diverse group of stakeholders. Designing Quality attributes drive design (using the Attribute-Driven Design Method): ■ A step-by-step approach to defining a software architecture supplements incremental design; the level of detail is flexible. Architecture allows better planning so that developers can better estimate requirement changes’ impact. They can plan for change that is foreseen and localize it in the design. ■ Developers do just enough architecting to ensure that the design will produce a system that will meet its quality attribute requirements and to mitigate risks. They defer all other architecture decisions until the appropriate time. ■ Architectural tactics aid refactoring, which is driven by quality attribute needs (such as making it faster or more secure). Analysis and testing Design analysis provides early feedback (using the Architecture Trade-off Analysis Method and Cost-Benefit Analysis Method): ■ The development team can use scenarios to evaluate the design and provide input for analysis during testing. ■ Architecture evaluation has a notion of triage to produce just enough information as needed and prioritizes on the basis of business importance and architectural difficulty to focus efforts. ■ Architecture evaluation provides early feedback for understanding the technical trade-offs, risks, and return on investment of architectural decisions. Risks are related back to technical decisions and business goals, giving developers justification for investing resources to mitigate them.use common concepts—quality attributes, ar-chitectural tactics, and a views-based approach About the Authorsto documentation—that lead to more efficient Robert L. Nord is a senior member of the technical staff in the Product Line Systems Program at the Software Engi-and synergistic use. They also help facilitate neering Institute, where he works to develop and communicate effective methods and practices for software architecture.communication. He received his PhD in computer science from Carnegie Mellon University. He is coauthor of Applied Software Architecture (Addison-Wesley, 1999) and Documenting Software Architectures: Views and Beyond (Addison-Wesley, 2002). He’s a member of the ACM and International Federation for Information Processing Working Group 2.10 Software Architecture. Contact him at the Software Eng. Inst., Carnegie Mellon Univ., 4500 Fifth Ave., Pittsburgh, PA 15213-3890; rn@sei.cmu.W e’ve found that architecture-cen- edu; www.sei.cmu.edu/staff/rn. tric methods are built on concepts and techniques that practitioners James E. Tomayko, recently deceased, was a teaching professor in Carnegie Mellon University’s School of Computer Science and director emeritus of its Master of Software Engi-can tailor to an agile approach. Architecture- neering program, as well as a visiting scientist at the Software Engineering Institute. He re-centric methods can add value to agile meth- ceived his PhD from the University of Kansas. He coauthored Human Aspects of Software Engi-ods by emphasizing quality attributes and neering (Charles River Media, 2004). See in memoriam on page 115.their role in shaping the architecture’s designand by making it possible to adapt agile meth- 2. M.R. Barbacci et al., Quality Attribute Workshopsods using a hybrid approach to handle larger, (QAWs), 3rd ed., tech. report CMU/SEI-2003-TR-016,more complex systems.6 Software Eng. Inst., Carnegie Mellon Univ., 2003; www.sei.cmu.edu/publications/documents/03.reports/ 03tr016.html.Acknowledgments 3. L. Bass, P. Clements, and R. Kazman, Software Archi- The Software Engineering Institute is a federally tecture in Practice, 2nd ed., Addison-Wesley, 2003.funded research and development center sponsored by 4. P. Clements, R. Kazman, and M. Klein, Evaluating Soft-the US Department of Defense. We thank our SEI col- ware Architectures: Methods and Case Studies, Addi-leagues Paul Clements, Rick Kazman, Mark Klein, and son-Wesley, 2002.Rob Wojcik for their insights and Amanda Bejot for 5. P. Clements et al., Documenting Software Architectures:help with clarity. Views and Beyond, Addison-Wesley, 2003. 6. R.L. Nord, J.E. Tomayko, and R. Wojcik, Integrating Software-Architecture-Centric Methods into Extreme Programming (XP), tech. report CMU/SEI-2004-TN-References 036, Software Eng. Inst., Carnegie Mellon Univ., 2004; 1. K. Beck, Extreme Programming Explained: Embrace www.sei.cmu.edu/publications/documents/04.reports/ Change, 2nd ed., Addison-Wesley, 2005. 04tn036.html. March/April 2006 IEEE SOFTWARE 53