Object-Oriented Analysis and Design lecture notes pdf

object-oriented analysis and design with the unified process and object oriented analysis and design important questions, object-oriented analysis and design (ooad) methodologies, what is object oriented analysis and design
Dr.MattWood Profile Pic
Dr.MattWood,United States,Teacher
Published Date:25-07-2017
Your Website URL(Optional)
Chapter 1 OBJECT-ORIENTED ANALYSIS AND DESIGN The shift of focus (to patterns) will have a profound and enduring effect on the way we write programs. —Ward Cunningham and Ralph Johnson Objectives • Compare and contrast analysis and design. • Define object-oriented analysis and design (OOA/D). • Illustrate a brief example. 1.1 Applying UML and Patterns in OOA/D What does it mean to have a good object design? This book is a tool to help devel- opers and students learn core skills in object-oriented analysis and design (OOA/D). These skills are essential for the creation of well-designed, robust, and maintainable software using object technologies and languages such as Java, C++, Smalltalk, and C. The proverb "owning a hammer doesn't make one an architect" is especially true with respect to object technology. Knowing an object-oriented language (such as Java) is a necessary but insufficient first step to create object systems. Knowing how to "think in objects" is also critical. This is an introduction to OOA/D while applying the Unified Modeling Lan- This is an guage (UML), patterns, and the Unified Process. It is not meant as an advanced introduction text; it emphasizes mastery of the fundamentals, such as how to assign respon- sibilities to objects, frequently used UML notation, and common design pat- 1 - OBJECT-ORIENTED ANALYSIS AND DESIGN terns. At the same time, primarily in later chapters, the material progresses to a few intermediate-level topics, such as framework design. Applying UML The book is not just about the UML. The UML is a standard diagramming nota- tion. As useful as it is to learn notation, there are more critical object-oriented things to learn; specifically, how to think in objects—how to design object-ori- ented systems. The UML is not OOA/D or a method, it is simply notation. It is not so helpful to learn syntactically correct UML diagramming and perhaps a UML CASE tool, but then not be able to create an excellent design, or evaluate and improve an existing one. This is the harder and more valuable skill. Conse- quently, this book is an introduction to object design. Yet, one needs a language for OOA/D and "software blueprints," both as a tool of thought and as a form of communication with others. Therefore, this book explores how to apply the UML in the service of doing OOA/D, and covers fre- quently used UML notation. But the emphasis is on helping people learn the art and science of building object systems, rather than notation. How should responsibilities be allocated to classes of objects? How should Applying patterns objects interact? What classes should do what? These are critical questions in and assigning the design of a system. Certain tried-and-true solutions to design problems can responsibilities be (and have been) expressed as best-practice principles, heuristics, or pat- terns—named problem-solution formulas that codify exemplary design princi- ples. This book, by teaching how to apply patterns, supports quicker learning and skillful use of these fundamental object design idioms. This introduction to OOA/D is illustrated in a single case study that is fol- One case study lowed throughout the book, going deep enough into the analysis and design so that some of the gory details of what must be considered and solved in a realistic problem are considered, and solved. OOA/D (and all software design) is strongly related to the prerequisite activity Use cases and of requirements analysis, which includes writing use cases. Therefore, the requirements case study begins with an introduction to these topics, even though they are not analysis specifically object-oriented. Given many possible activities from requirements through to implementation, An example how should a developer or team proceed? Requirements analysis and OOA/D iterative process— needs to be presented in the context of some development process. In this case, the Unified Process the well-known Unified Process is used as the sample iterative develop- ment process within which these topics are introduced. However, the analysis and design topics that are covered are common to many approaches, and learn- ing them in the context of the Unified Process does not invalidate their applica- bility to other methods. APPLYING UML AND PATTERNS IN OOA/D In conclusion, this book helps a student or developer: • Apply principles and patterns to create better object designs. • Follow a set of common activities in analysis and design, based on the Unified Process as an example. • Create frequently used diagrams in the UML notation. It illustrates this in the context of a single case study. OOA/D Patterns UML notation Topics and Skills Principles and Requirements guidelines analysis Iterative development with the Unified Process Figure 1.1 Topics and skills covered Many Other Skills Are Important Building software involves myriad skills and steps beyond requirements analy- sis, OOA/D, and object-oriented programming. For example, usability engineer- ing and user interface design are critical to success; so is database design. However, this introduction emphasizes OOA/D, and does not attempt to cover all topics in software development. It is one piece of a larger picture. 5 1 - OBJECT-ORIENTED ANALYSIS AND DESICN 1.2 Assigning Responsibilities There are many possible activities and artifacts in introductory OOA/D, and a wealth of principles and guidelines. Suppose we must choose a single practical skill from all the topics discussed here—a "desert island" skill. What would it be? A critical, fundamental ability in OOA/D is to skillfully assign responsibilities to software components. Why? Because it is one activity that must be performed—either while drawing a UML diagram or programming—and it strongly influences the robustness, maintainability, and reusability of software components. Of course, there are other necessary skills in OOA/D, but responsibility assign- ment is emphasized in this introduction because it tends to be a challenging skill to master, and yet vitally important. On a real project, a developer might not have the opportunity to perform any other analysis or design activities—the "rush to code" development process. Yet even in this situation, assigning respon- sibilities is inevitable. Consequently, the design steps in this book emphasize principles of responsibil- ity assignment. Nine fundamental principles in object design and responsibility assignment are presented and applied. They are organized in a learning aid called the GRASP patterns. 1.3 What Is Analysis and Design? Analysis emphasizes an investigation of the problem and requirements, rather than a solution. For example, if a new computerized library information system is desired, how will it be used? "Analysis" is a broad term, best qualified, as in requirements analysis (an inves- tigation of the requirements) or object analysis (an investigation of the domain objects). Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation. For example, a description of a database schema and software objects. Ultimately, designs can be implemented. 6 WHAT Is OBJECT-ORIENTED ANALYSIS AND DESIGN? As with analysis, the term is best qualified, as in object design or database design. Analysis and design have been summarized in the phase do the right thing (analysis), and do the thing right (design). 1.4 What Is Object-Oriented Analysis and Design? During object-oriented analysis, there is an emphasis on finding and describ- ing the objects—or concepts—in the problem domain. For example, in the case of the library information system, some of the concepts include Book, Library, and Patron. During object-oriented design, there is an emphasis on defining software objects and how they collaborate to fulfill the requirements. For example, in the library system, a Book software object may have a title attribute and a getChap-ter method (see Figure 1.2). Finally, during implementation or object-oriented programming, design objects are implemented, such as a Book class in Java. Book visualization of domain concept domain concept title public class Book representation in an private String title; object-oriented programming language public Chapter getChapter(int) ... Figure 1.2 Object-orientation emphasizes representation of objects. 1.5 An Example Before diving into the details of requirements analysis and OOA/D, this section presents a birds-eye view of a few key steps and diagrams, using a simple example—a "dice game" in which a player rolls two die. If the total is seven, they win; otherwise, they lose. 7 8 1 - OBJECT-ORIENTED ANALYSIS AND DESIGN Define Use Cases Requirements analysis may include a description of related domain processes; these can be written as use cases. Define Define domain Define design Define use cases interaction model class diagrams diagrams Use cases are not an object-oriented artifact—they are simply written stories. However, they are a popular tool in requirements analysis and are an important part of the Unified Process. For example, here is a brief version of the Play a Dice Game use case: Play a Dice Game: A player picks up and rolls the dice. If the dice face value total seven, they win; otherwise, they lose. Define a Domain Model Object-oriented analysis is concerned with creating a description of the domain from the perspective of classification by objects. A decomposition of the domain involves an identification of the concepts, attributes, and associations that are considered noteworthy. The result can be expressed in a domain model, which is illustrated in a set of diagrams that show domain concepts or objects. Define Define domain Define design Define use cases interaction model class diagrams diagrams For example, a partial domain model is shown in Figure 1.3. Player Die 1 2 Rolls name faceValue 1 2 Plays 1 DiceGame 1 Includes Figure 1.3 Partial domain model of the dice game. AN EXAMPLE This model illustrates the noteworthy concepts Player, Die, and DiceGame, with their associations and attributes. Note that a domain model is not a description of software objects; it is a visual- ization of concepts in the real-world domain. Define Interaction Diagrams Object-oriented design is concerned with defining software objects and their col- laborations. A common notation to illustrate these collaborations is the interac- tion diagram. It shows the flow of messages between software objects, and thus the invocation of methods. Define Define domain Define design Define use cases interaction model class diagrams diagrams For example, assume that a software implementation of the dice game is desired. The interaction diagram in Figure 1.4 illustrates the essential step of playing, by sending messages to instances of the DiceGame and Die classes. :DiceGame die1 : Die die2 : Die play() roll() fv1 := getFaceValue() roll() fv2 := getFaceValue() Figure 1.4 Interaction diagram illustrating messages between software objects. Notice that although in the real world a player rolls the dice, in the software design the DiceGame object "rolls" the dice (that is, sends messages to Die objects). Software object designs and programs do take some inspiration from real-world domains, but they are not direct models or simulations of the real world. 9 1 - OBJECT-ORIENTED ANALYSIS AND DESIGN Define Design Class Diagrams In addition to a dynamic view of collaborating objects shown in interaction dia- grams, it is useful to create a static view of the class definitions with a design class diagram. This illustrates the attributes and methods of the classes. Define Define domain Define design Define use cases interaction model class diagrams diagrams For example, in the dice game, an inspection of the interaction diagram leads to the partial design class diagram shown in Figure 1.5. Since a play message is sent to a DiceGame object, the DiceGame class requires a play method, while class Die requires a roll and getFaceValue method. In contrast to the domain model, this diagram does not illustrate real-world con- cepts; rather, it shows software classes. DiceGame Die 1 2 die1 : Die faceValue : int die2 : Die getFaceValue() : int play() roll() Figure 1.5 Partial design class diagram. Summary The dice game is a simple problem, presented to focus on a few steps and arti- facts in analysis and design. To keep the introduction simple, not all the illus- trated UML notation was explained. Future chapters explore analysis and design and these artifacts in closer detail. 1.6 The UML To quote: The Unified Modeling Language (UML) is a language for speci- fying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems OMG01. The UML has emerged as the de facto and de jure standard diagramming nota- tion for object-oriented modeling. It started as an effort by Grady Booch and Jim Rumbaugh in 1994 to combine the diagramming notations from their two popu- 10 FURTHER READINGS lar methods—the Booch and OMT (Object Modeling Technique) methods. They were later joined by Ivar Jacobson, the creator of the Objectory method, and as a group came to be known as the three amigos. Many others contributed to the UML, perhaps most notably Cris Kobryn, a leader in its ongoing refinement. The UML was adopted in 1997 as a standard by the OMG (Object Management Group, an industry standards body), and has continued to be refined in new OMG UML versions. This book does not cover every minute aspect of the UML, which is a large body 1 of notation (some say, too large ). It focuses on diagrams which are frequently used, the most commonly used features within those diagrams, and core nota- tion that is unlikely to change in future versions of the UML. Why Won't We See Much UML fora Few Chapters? This is not just a UML notation book, but one that explores the larger picture of applying the UML, patterns, and an iterative process in the context of software development. The UML is primarily applied during OOA/D, which is normally preceded by requirements analysis. Therefore, the initial chapters present an introduction to the important topics of use cases and requirements analysis, which are then followed by chapters on OOA/D and more UML details. 1.7 Further Readings A very readable and popular summary of essential UML notation is UML Dis- tilled, by Martin Fowler. A succinct and popular introduction to the Unified Process (and its refinement in the Rational Unified Process) is The Rational Unified Process—An Introduc- tion by Philippe Kruchten. For a detailed discussion of UML (version 1.3) notation, The Unified Modeling Language Reference Manual and The Unified Modeling Language User Guide, by Booch, Jacobson, and Rumbaugh are worthwhile. Note that these texts were not meant for learning how to do object modeling or OOA/D—they are UML dia- gram notation references. For a description of the current version of the UML, the on-line OMG Unified Modeling Language Specification at www.omg.org is necessary. UML revision work and soon-to-be released versions can be found at www.celigent.com/uml. There are many books on software patterns, but the seminal classic is Design Patterns, by Gamma, Helm, Johnson, and Vlissides. It is truly required reading 1. The UML 2.0 effort includes exploration of the goal of simplifying and reducing the notation. This book presents high-use UML likely to survive future simplification. 11 1 - OBJECT-ORIENTED ANALYSIS AND DESIGN for those studying object design. However, it is not an introductory text and is best read after developing comfort with the fundamentals of object design and programming. 12 Chapter 2 ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS People are more important than any process. Good people with a good process will outperform good people with no process every time. —Grady Booch Objectives • Provide motivation for the content and order of subsequent chapters. • Define an iterative and adaptive process. • Define fundamental concepts in the Unified Process. Introduction Iterative development is a skillful approach to software development, and lies at the heart of how OOA/D is presented in this book. The Unified Process is an example iterative process for projects using OOA/D, and it shapes the book's presentation. Consequently, it is useful to read this chapter so that these core concepts and their influence on the book's structure are clear. This chapter summarizes a few key ideas; please see Chapter 37 for further dis- cussion of the UP and iterative process practices. Informally, a software development process describes an approach to build- ing, deploying, and possibly maintaining software. The Unified Process JBR99 has emerged as a popular software development process for building object-oriented systems. In particular, the Rational Unified Process or RUP 13 2 - ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS KruchtenOO, a detailed refinement of the Unified Process, has been widely adopted. The Unified Process (UP) combines commonly accepted best practices, such as an iterative lifecycle and risk-driven development, into a cohesive and well-doc- umented description. Consequently, it is used in this book as the example pro- cess within which to introduce OOA/D. This book starts with an introduction to the UP for two reasons: 1. The UP is an iterative process. Iterative development is a valuable practice that influences how this book introduces OOA/D, and how it is best prac ticed. 2. UP practices provide an example structure to talk about how to do—and how to learn—OOA/D. This text presents an introduction to the UP, not complete coverage. It emphasizes common ideas and artifacts related to an introduction to OOA/D and requirements analysis. What If I Don't Care About the UP? The UP is used as an example process within which to explore requirements analysis and OOA/D, since it is necessary to introduce the subject in the context of some process, and the UP (or the RUP refinement) is relatively widely used. Also, the UP presents common activities and best practices. Nevertheless, the central ideas of this book—such as use cases and design patterns—are indepen- dent of any particular process, and apply to many. 2.1 The Most Important UP Idea: Iterative Development The UP promotes several best practices, but one stands above the others: itera- tive development. In this approach, development is organized into a series of short, fixed-length (for example, four week) mini-projects called iterations; the outcome of each is a tested, integrated, and executable system. Each iteration includes its own requirements analysis, design, implementation, and testing activities. The iterative lifecycle is based on the successive enlargement and refinement of a system through multiple iterations, with cyclic feedback and adaptation as core drivers to converge upon a suitable system. The system grows incremen- tally over time, iteration by iteration, and thus this approach is also known as iterative and incremental development (see Figure 2.1). 14 THE MOST IMPORTANT UP IDEA: ITERATIVE DEVELOPMENT Early iterative process ideas were known as spiral development and evolution- ary development Boehm.88, Gilb88. Feedback from Requirements Requirements iteration N leads to refinement and Design Design Time adaptation of the Implementation & requirements and Implementation & Test & Integration Test & Integration design in iteration N+1. & More Design & More Design Final Integration Final Integration & System Test & System Test 4 weeks (for example) Iterations are fixed in The system grows length, or timeboxed. incrementally. Figure 2.1 Iterative and incremental development. Example As an example (not a recipe), in a two-week iteration half-way through a project, perhaps Monday is spent primarily on distributing and clarifying the tasks and requirements of the iteration, while one person reverse-engineers the last iteration's code into UML diagrams (via a CASE tool), and prints and displays noteworthy diagrams. Tuesday is spent at whiteboards doing pair design work drawing rough UML diagrams captured on digital cameras, and writing some pseudocode and design notes. The remaining eight days are spent on implementation, testing (unit, acceptance, usability, ...), further design, integration, daily builds, system testing, and stabilization of the par- tial system. Other activities include demonstrations and evaluations with stakeholders, and planning for the next iteration. Notice in this example that there is neither a rush to code, nor a long drawn-out design step that attempts to perfect all details of the design before program- ming. A "little" forethought regarding the design with visual modeling using rough and fast UML drawings is done; perhaps a half or full day by developers doing design work in pairs. The result of each iteration is an executable but incomplete system; it is not ready to deliver into production. The system may not be eligible for production deployment until after many iterations; for example, 10 or 15 iterations. 15 2 - ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS The output of an iteration is not an experimental or throw-away prototype, and iterative development is not prototyping. Rather, the output is a production-grade subset of the final system. Although, in general, each iteration tackles new requirements and incremen- tally extends the system, an iteration may occasionally revisit existing software and improve it; for example, one iteration may focus on improving the perfor- mance of a subsystem, rather than extending it with new features. Embracing Change: Feedback and Adaptation The subtitle of one book that discusses iterative development is Embrace Change BeckOO. This phrase is evocative of a key attitude of iterative develop- ment: Rather than fighting the inevitable change that occurs in software devel- opment by trying (usually unsuccessfully) to fully and correctly specify, freeze, and "sign off" on a frozen requirement set and design before implementation, iterative development is based on an attitude of embracing change and adapta- tion as unavoidable and indeed essential drivers. This is not to say that iterative development and the UP encourages an uncon- trolled and reactive "feature creep"-driven process. Subsequent chapters explore how the UP balances the need—on the one hand—to agree upon and stabilize a set of requirements, with—on the other hand—the reality of changing require- ments, as stakeholders clarify their vision or the marketplace changes. Each iteration involves choosing a small subset of the requirements, and quickly designing, implementing, and testing. In early iterations the choice of require- ments and design may not be exactly what is ultimately desired. But the act of swiftly taking a small step, before all requirements are finalized, or the entire design is speculatively defined, leads to rapid feedback—feedback from the users, developers, and tests (such as load and usability tests). This early feedback is worth its weight in gold; rather than speculating on the correct requirements or design, the feedback from realistic building and testing something provides crucial practical insight and an opportunity to modify or adapt understanding of the requirements or design. End-users have a chance to quickly see a partial system and say, "Yes, that's what I asked for, but now that I 1 try it, what I really want is something slightly different." This "yes...but" pro- cess is not a sign of failure; rather, early and frequent structured cycles of "yes...buts" are a skillful way to make progress and discover what is of real value to the stakeholders. Yet, as mentioned, this is not an endorsement of chaotic and reactive development in which developers continually change direction—a mid- dle way is possible. In addition to requirements clarification, activities such as load testing will prove if the partial design and implementation are on the right path, or if in the 1. Or more likely, "You didn't understand what I wanted" 16 THE MOST IMPORTANT UP IDEA: ITERATIVE DEVELOPMENT next iteration, a change in the core architecture is required. Better to resolve and prove the risky and critical design decisions early rather than late—and iterative development provides the mechanism for this. Consequently, work proceeds through a series of structured build-feedback-adapt cycles. Not surprisingly, in early iterations the deviation from the "true path" of the system (in terms of its final requirements and design) will be larger than in later iterations. Over time, the system converges towards this path, as illustrated in Figure 2.2. Early iterations are farther from the "true In late iterations, a significant change in path" of the system. Via feedback and requirements is rare, but can occur. Such adaptation, the system converges towards late changes may give an organization a the most appropriate requirements and competitive business advantage. design. one iteration of design, implement, integrate, and test Figure 2.2 Iterative feedback and adaptation leads towards the desired system. The requirements and design instability lowers over time. Benefits of Iterative Development Benefits of iterative development include: • early rather than late mitigation of high risks (technical, requirements, objectives, usability, and so forth) • early visible progress • early feedback, user engagement, and adaptation, leading to a refined sys tem that more closely meets the real needs of the stakeholders • managed complexity; the team is not overwhelmed by "analysis paralysis" or very long and complex steps • the learning within an iteration can be methodically used to improve the development process itself, iteration by iteration 2 - ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS Iteration Length and Timeboxing The UP (and experienced iterative developers) recommends an iteration length between two and six weeks. Small steps, rapid feedback, and adaptation are central ideas in iterative development; long iterations subvert the core motiva- tion for iterative development and increase project risk. Much less than two weeks, and it is difficult to complete sufficient work to get meaningful through- put and feedback; much more than six or eight weeks, and the complexity becomes rather overwhelming, and feedback is delayed. A very long iteration misses the point of iterative development. Short is good. A key idea is that iterations are timeboxed, or fixed in length. For example, if the next iteration is chosen to be four weeks long, then the partial system should be integrated, tested, and stabilized by the scheduled date—date slippage is dis- couraged. If it seems that it will be difficult to meet the deadline, the recom- mended response is to remove tasks or requirements from the iteration, and include them in a future iteration, rather than slip the completion date. Chapter 37 summarizes reasons for timeboxing. Massive teams (for example, several hundred developers) may require longer than six-week iterations to compensate for the overhead of coordination and communication; but no more than three to six months is recommended. For example, the successful replacement in the 1990s of the Canadian air traffic control system was developed with an iterative lifecycle and other UP practices. 2 It involved 150 programmers and was organized into six-month iterations. But note that even in the case of an overall six-month project iteration, a subsystem team of 10 or 20 developers can break down their work into a series of six one-month iterations. A six-month iteration is the exception for massive teams, not the rule. To reiter- ate, the UP recommends that normally an iteration should be between two and six weeks in duration. 2.2 Additional UP Best Practices and Concepts The central idea to appreciate and practice in the UP is short timeboxed itera- tive, adaptive development. Another implicit, but core, UP idea is the use of object technologies, including OOA/D and object-oriented programming. 2. Philippe Kruchten, who also led the development of the RUP, served as chief architect for the project. 18 THE UP PHASES AND SCHEDULE-ORIENTED TERMS Some additional best practices and key concepts in the UP include: • tackle high-risk and high-value issues in early iterations • continuously engage users for evaluation, feedback, and requirements • build a cohesive, core architecture in early iterations • continuously verify quality; test early, often, and realistically • apply use cases • model software visually (with the UML) • carefully manage requirements • practice change request and configuration management See Chapter 37 for a more detailed description of these practices. 2.3 The UP Phases and Schedule-Oriented Terms A UP project organizes the work and iterations across four major phases: 1. Inception— approximate vision, business case, scope, vague estimates. 2. Elaboration—refined vision, iterative implementation of the core architec ture, resolution of high risks, identification of most requirements and scope, more realistic estimates. 3. Construction—iterative implementation of the remaining lower risk and easier elements, and preparation for deployment. 4. Transition—beta tests, deployment. These phases are more fully defined in subsequent chapters. This is not the old "waterfall" or sequential lifecycle of first defining all the requirements, and then doing all or most of the design. Inception is not a requirements phase; rather, it is a kind of feasibility phase, where just enough investigation is done to support a decision to continue or stop. Similarly, elaboration is not the requirements or design phase; rather, it is a phase where the core architecture is iteratively implemented, and high risk issues are mitigated. Figure 2.3 illustrates common schedule-oriented terms in the UP. Notice that one development cycle (which ends in the release of a system into production) is composed of many iterations. 19 2 - ITERATIVE DEVELOPMENT AND THE UNIFIED PROCESS development cycle phase iteration inc. elaboration construction transition increment final production milestone release release The difference An iteration end- A stable executable (delta) between the At this point, the point when some subset of the final releases of 2 system is released significant decision product. The end of subsequent for production use. or evaluation each iteration is a iterations. occurs. minor release. Figure 2.3 Schedule-oriented terms in the UP. 2.4 The UP Disciplines (was Workflows) The UP describes work activities, such as writing a use case, within disciplines 3 (originally called workflows). Informally, a discipline is a set of activities (and related artifacts) in one subject area, such as the activities within requirements analysis. In the UP, an artifact is the general term for any work product: code, Web graphics, database schema, text documents, diagrams, models, and so on. There are several disciplines in the UP; this book focuses on some artifacts in the following three: • Business Modeling—When developing a single application, this includes domain object modeling. When engaged in large-scale business analysis or business process reengineering, this includes dynamic modeling of the busi ness processes across the entire enterprise. • Requirements—Requirements analysis for an application, such as writing use cases and identifying non-functional requirements. • Design—All aspects of design, including the overall architecture, objects, databases, networking, and the like. 3. In 2001, the old UP term "workflow" was replaced by the new term "discipline" in order to harmonize with an international standardization effort called the OMG SPEM; because of its prior meaning in the UP, many continue to use the term work- flow to mean discipline, although this is not strictly correct. The term "workflow" took on a new but slightly different meaning within the UP: On a particular project, it is a particular sequence of activities (perhaps across disciplines)—a flow of work. 20 THE UP DISCIPLINES (WAS WORKFLOWS) A longer list of UP disciplines is shown in Figure 2.4. A four-week iteration (for example). A mini-project that includes work in most Note that disciplines, ending in a stable executable. although an iteration includes work in most Sample disciplines, the UP Disciplines relative effort and emphasis change Business Modeling over time. Focus Requirements of this This example is book suggestive, not Design literal. Implementation Test Deployment Configuration & Change Management Project Management Environment Iterations 4 Figure 2.4 UP disciplines. In the UP, Implementation means programming and building the system, not deployment. The Environment discipline refers to establishing the tools and customizing the process for the project—that is, setting up the tool and process environment. Disciplines and Phases As illustrated in Figure 2.4, during one iteration work goes on in most or all dis- ciplines. However, the relative effort across these disciplines changes over time. Early iterations naturally tend to apply greater relative emphasis to require- ments and design, and later ones less so, as the requirements and core design stabilize through a process of feedback and adaptation. Relating this to the UP phases (inception, elaboration, ...), Figure 2.5 illustrates the changing relative effort with respect to the phases; please note these are suggestive, not literal. In elaboration, for example, the iterations tend to have a 4. Diagram adapted from the RUP product.

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.