UML WEEKEND CRASH COURSE phần 2 pptx

Session 1—What Is the UML? 11 QUIZ YOURSELF 1. Who sponsored the UML? (See “Some History behind the UML.”) 2. What part of systems development does the UML define? (See “What is and is not included in the UML Specification.”) 3. What part of systems development is not defined by the UML? (See “What is and is not included in the UML Specification.”) 4. What is a UML stereotype? (See “UML Extension Mechanisms.”) 5. What is a UML constraint? (See “UML Extension Mechanisms.”) 6. How are changes made to the UML standard? (See “The Continuing Refinement and Expansion of the UML.”) 044910-3 Ch01.F 5/31/02 2:03 PM Page 11 044910-3 Ch01.F 5/31/02 2:03 PM Page 12 Session Checklist ✔ Explaining methodology ✔ Examining some popular methodologies A methodology consists of a process, a vocabulary, and a set of rules and guidelines. The process defines a set of activities that together accomplish all the goals of the methodology. The vocabulary of the methodology is used to describe the process and the work products created during the application of the process. The rules and guidelines define the quality of the process and the work products. The part of all methodologies that can be standardized is the vocabulary, often expressed in a notation. The UML standard is a common notation that may be applied to many differ- ent types of software projects using very different methodologies. The variations appear in the use of the UML extensions, like stereotypes, and the emphasis placed on different dia- grams for different types of projects. One of the challenges inherent in defining a methodology is that it is difficult, if not impossible, to define a single process that works for all projects. For a software development methodology, this would mean a process that works equally well on projects as diverse as arcade games, device drivers, banking, rocket navigation, and life support. Consequently, even though the UML standardizes the notations gathered from a number of methodologies, the processes used to apply the UML notation are still as diverse as the environments in which they are used. Some Current Methodologies The rest of this session is devoted to a brief summary of four of the current methodologies: RUP, Shlaer-Mellor, CRC, and Extreme Programming. They represent the diversity of the cur- rent set of methodologies. I provide a brief summary and then try to point out what I see to SESSION UML and Development Methodologies 2 054910-3 Ch02.F 5/31/02 2:04 PM Page 13 Friday Evening14 be some strengths and weaknesses in each approach. This should give a fair idea of the opportunities available to you and the factors that may influence your choices. The list of all methodologies is far too long to cover here, so at the end of the session I’ll point you to a resource where you can check out many of the others and dig a little deeper into the methodologies presented here. I have selected these four methodologies because they represent the diversity inherent in system development. The Rational Unified Process works well in large projects where quality artifacts and communication are critical. The Shlaer-Mellor Method was developed primarily to address the unique needs of real-time systems long before the UML existed, but has since adopted the UML notation. CRC is almost more of a technique than a method- ology. It was designed as a tool to help people gain an understanding of objects and how they work. Extreme Programming tries to reduce many of the existing development practices to the bare essentials, attempting to optimize the relationship between developers and clients. The Rational Unified Process One method that has received a lot of interest recently is the Rational Unified Process (RUP). RUP is the latest version of a series of methodologies resulting from a blending of methodologies. You may have heard the names Objectory Process, the Rational Approach, the Rational Objectory Process, and the Unified Software Development Process. These were all predecessors and have been synthesized into the RUP. Actually, it gets a bit confusing because the Rational Unified Process was a proprietary process within Rational Software, Inc. The merged method was published in 1999 as The Unified Software Development Process. The method has since been made public and the name reverted to the Rational Unified Process (RUP). The hallmarks of RUP are the two terms incremental and iterative. These concepts are part of most current methods, but RUP places particular emphasis on their value and their associated artifacts. The goal of the methodology is to deliver an executable release of a product, an increment of the product for every pass, or iteration, through the process. The motivation for this approach is to keep delivery times short and deliveries frequent. This prevents the historical problem of projects that run for months or even years before they actually produce anything. It also supports early review and early problem detection. Note that in the very early increments, the concept of an executable release is a bit of a stretch. Typically, you might produce prototypes or layouts without anything executable until at least a few iterations into the project. The key is to produce some verifiable output for the clients. The process is built around the two concepts of project lifecycle phases and process work- flow. Figure 2-1 shows a two-dimensional matrix. The horizontal axis represents the progress of the project over time. The vertical axis represents the core process workflow. Using this visualization, you can see that in each iteration, or small step through the life of the pro- ject, the team is working through all the steps in the process workflow. In each subsequent iteration, the team digs deeper into each activity in the process workflow. The workflow consists of a set of activities, business modeling through defining the envi- ronment. Each activity is associated with a set of artifacts or work products. In most cases, the artifacts are UML diagrams, but they may also be items like requirements documents, test plans, risk assessments, deployment plans, and much more. 054910-3 Ch02.F 5/31/02 2:04 PM Page 14 Session 2—UML and Development Methodologies 15 Figure 2-1 The Rational Unified Process, phases and workflows For example, the case study presented in this book refers to an inventory control system. The first iteration on this project might focus heavily on requirements and result in a risk assessment, a glossary of inventory control terms, and some screen and forms layouts for receiving and shipping to help the users visualize their requirements. The second iteration might create the Use Case diagram and a set of one or more prototypes from the original screen layouts. A few iterations later you might take one Use Case and actually build the application to support a screen to set the standards for the screen look and feel and to test the basic architecture of the application. The iterative approach continues until all the requirements have been satisfied and the system is fully implemented. You may have the impression that the Rational Unified Process is a standard like the Unified Modeling Language. The choice of the name might have been a smart marketing ploy, but that does not make it a standard. There are many other valuable methodologies to consider. Strengths of the RUP ¼ The emphasis on iterative development and incremental deliveries is a time-tested and valuable approach that prevents many common project problems. However, it must be noted that this approach is common to most of the current methodologies. ¼ The process is well defined and supported by the Rational modeling tool. ¼ The artifacts and the roles of the project participants are also very well defined. ¼ The process combines many of the best practices from many successful methodologies. ¼ The process is comprehensive. Note Phases Workflows Business Modeling Requirements Analysis and Design Implementation Test Deployment Configuration and Change Mgmt Project Mgmt Environment Inception Elaboration Construction Transition Iter #1 Initial Iter #2 Iter #3 Iter #4 Iter #5 Iter #6 054910-3 Ch02.F 5/31/02 2:04 PM Page 15 Friday Evening16 Weaknesses of the RUP ¼ In trying to be comprehensive, the RUP becomes very large and difficult, both to learn and to manage. ¼ It is easy to get so caught up in the rules for using the RUP that you forget why you are using it (to deliver software). ¼ A substantial amount of time is spent trying to customize the RUP for each project. Here, too, you run the risk of becoming a slave to the process and losing sight of the reason for the process. ¼ Tool support for the process is limited to Rational’s own products, which are at the high end of the cost range. A few other vendors are now starting to provide limited support. Shlaer-Mellor Method The Shlaer-Mellor Method is based on an integrated set of models that can be executed for verification, and an innovative approach to design that produces a system design through a translation of the analysis models. The method is built on a set of well-defined rules for the construction of the diagrams and the translation of those diagrams from analysis to design and finally to implementation. In fact, the most recent generation of modeling tools, like BridgePoint ( www.projtech.com/prods/bp/info.html ), have created the ability to generate 100 percent of the code. This achievement is ahead of most other methodologies that generate the operation declarations but cannot provide the method code, the implementation for the operation. The rigorous set of rules also supports verification through simulation. The diagrams can actually be executed to see if they work properly. One of the primary concepts in Shlaer-Mellor is a domain. A domain is a subject area. Shlaer-Mellor defines three basic types of domains: the application domain, the service domains, and the architectural domain. Each domain has its own unique types of require- ments and diagrams. Together they represent the entire specification for the system. The Shlaer-Mellor process is broken down into the following steps: 1. Partition the system into domains. 2. Analyze the application domain using object information models, state models, and action specifications (action data flow diagrams — a non-UML diagram). 3. Confirm the analysis through static verification and dynamic verification (simulation). 4. Extract the requirements for the service domains. 5. Analyze the service domains. 6. Specify the components of the architectural domain. 7. Build the architectural components. 8. Translate the models of each domain using the architectural components. 054910-3 Ch02.F 5/31/02 2:04 PM Page 16 Session 2—UML and Development Methodologies 17 The progression from step to step follows a fairly strict set of rules to guide the transla- tion from each version of the diagram to the next. The process sets up a rhythm of build a little and test it, build a little more and test a little more, which helps prevent surprise problems from cropping up deep into the process. The Shlaer-Mellor Method also places a great emphasis on iterative and incremental development. But this methodology reduces and controls iteration in analysis by confining it to a single domain at a time. Iteration in design is similarly controlled: Modifications to the design are made entirely in the architectural domain and propagated to the entire system through the standardized diagrams. Reuse is yet another high priority. Because domains are kept completely separate from one another until the final construction steps, they can be transported intact to other sys- tems. This applies particularly to the architectural domain: This domain is commonly reused for other systems that have basically the same loading and performance characteristics. Strengths of Shlaer-Mellor ¼ By far the greatest strength of the Shlaer-Mellor Method is the ability to test your diagrams through simulation. You actually execute your diagrams. ¼ The process is extremely well defined in terms of rules that govern the construction and testing of the diagrams. ¼ The movement from one step in the process to the next (for example, from analysis- level diagrams to design-level diagrams) is also defined with enough precision to allow the generation of design diagrams directly from the analysis diagrams. This is a huge time saver and prevents mistakes in the translation. It also speeds up the process of applying changes because they can be propagated through the diagrams automatically. ¼ The method was developed for and maintains a strong emphasis on real-time sys- tems design. As such, it provides support that is largely lacking in other methodolo- gies that gloss over the unique demands of real time in favor of the more common business functionality. Weaknesses of Shlaer-Mellor ¼ The strengths of the methodology can also be its weaknesses. Like the RUP, the tool support is limited to vendors directly associated with the methodologists. This is changing, but don’t expect it to be quick. ¼ Learning the rules involves a definite learning curve and a serious investment of time and effort. Steve Mellor is currently leading an enhancement to the UML, called Action Semantics, to improve the definition of Statechart diagrams and build much of this knowledge into the UML 1.5 standard. Tool support for this enhance- ment should soon follow. ¼ The methodology was developed for real-time systems, so it places heavy emphasis on state modeling. Many business applications simply do not warrant a lot of work on state transitions. 054910-3 Ch02.F 5/31/02 2:04 PM Page 17 Friday Evening18 CRC CRC stands for Class, Responsibilities, and Collaborators. The CRC methodology was originally developed as a learning tool during the time when object-oriented programming was new; a lot of procedural programmers needed help making the transition to OO thinking. The goal was to provide the simplest possible conceptual introduction to OO modeling. The heart of the method is the CRC card. A CRC card is a 3-x-5" or 4-x-6" lined index card. The physical nature of the cards emphasizes the division of responsibility across objects. The physical size of the cards also helps to establish limits for the size and com- plexity of the classes. The CRC card technique does not use the UML. Instead it is used to discover information about classes that is then placed into a UML Class diagram. Figure 2-2 is a sample blank CRC card. The class name is written at the top of the card. The next two lines are reserved for the listing of superclasses and subclasses. The body of the card is divided in half. The left column or half lists the responsibilities of the class and the right column or half lists the other objects that it works with, the collaborators, to fulfill each responsibility. Figure 2-2 A CRC card sample The CRC process requires a team that includes people in two distinct roles: domain expert and object-oriented technology facilitator. The domain experts provide knowledge of the subject area, and the OO facilitator coaches the team through the development of the cards and the eventual model. The CRC process centers on working through scenarios. The process breaks down into four stages: class name subclasses: superclasses: Responsibilities Collaborators 054910-3 Ch02.F 5/31/02 2:04 PM Page 18 Session 2—UML and Development Methodologies 19 1. Before the Scenario Execution a. The Problem: Everyone agrees on the problem definition. b. Brainstorming for Classes: Based on the problem statement, the team identi- fies candidate classes using the vocabulary of the problem. c. Filtering Classes: The team works on definitions for each class, eliminating synonyms and conflicts. d. Assigning Cards: Each team member is assigned responsibility for one or more classes. 2. The Scenario Execution a. Each scenario expresses something that the system is supposed to do. The team walks through the scenario identifying the responsibilities of each class in the scenario. b. Each discovered responsibility is recorded on the card of the corresponding class. 3. During the Scenario Execution a. Grouping the Cards: The team identifies similar classes. b. Scenario List: The team reviews the scenario coverage for completeness. c. Collaboration Drawings: The cards are combined on a wall or white board to show how they cooperate in the execution of the scenarios. 4. After the Scenario Execution a. The team reviews the resulting model and plans the implementation. Strengths of CRC ¼ The simplicity of the method has remained a major selling point and the method has been incorporated into many different methodologies. It is still a valuable tool for helping a programmer transition from procedural to OO concepts. ¼ It is extremely easy to use and very visual. It is difficult for any participant to claim he didn’t know exactly what was going on. ¼ The technique is very responsibility-driven. It keeps the participants focused on the value of an object based on what that object contributes to the proper operation of the system. The result is a system with the minimum number of objects needed to make it work. ¼ The technique helps the participants think like objects and to understand why objects work well or work poorly. This understanding helps ensure a good design. Weaknesses of CRC ¼ The most significant limitation, however, is also its simplicity. It only really addresses the problem of finding and modeling classes. There is a lot more to com- plete systems development. So the bulk of the work still rests on the programmers. ¼ The success of the process is very dependent upon the participants and especially on the facilitator. The simplicity can be very deceptive. 054910-3 Ch02.F 5/31/02 2:04 PM Page 19 Friday Evening20 Extreme Programming Extreme Programming (XP) shocked a lot of people, including myself, when it first showed up. The goal of XP is much like that of CRC (that is, keep it simple). This is not surprising when you learn that the originator, Kent Beck, was also instrumental in the CRC method. XP does not advocate the UML. I present it here because the goal of this session is to provide you with an understanding of the diversity of methodologies and the views or attitudes that various methodologies hold toward the application of the UML standard. XP strives to strip away anything that is not essential. XP requires a complete and unwa- vering commitment from the clients to work side-by-side with the programmers. Working through stories or scenarios of how the system should work, the teams eventually develop the entire system. Every iteration of the project (typically one to four weeks each), the teams deliver something functional. The minimum deliverable is a set of tests. XP basically says that the code is everything, so there is a very heavy emphasis on cod- ing standards and design principles. The process includes numerous standup meetings to keep everyone on the same page. Furthermore, programmers work in pairs so that they can learn from one another, provide insights, share design alternatives, and generally help each other out. Because XP is completely devoted to the code, there is very little use of up-front model- ing. If modeling is used, it is usually thrown away when a decision is reached. XP does use the CRC method because of its simplicity and utility. Instead of design up front, the method encourages design through integration and refactoring. In other words, XP advocates believe that as you learn more about the code, you are in a better position to make the design decisions and update your code. In one sense, it could be seen as bottom-up design. Strengths of XP ¼ XP is the first that I know of that truly cared about the programming environment and its affects on the participants. The bibliography for Extreme Programming Explained, Embrace Change, by Kent Beck, reads more like a sociology text than a programming text. No one since Tom DeMarco, writing the book Peopleware, has devoted as much time to finding ways to make the programming job livable. ¼ XP encourages an extremely close relationship between clients and developers. ¼ XP faces the fact that change is inevitable and often uncontrollable and builds that fact into the development approach. ¼ Kent Beck has been brave enough to describe what it really takes to create a high- caliber development environment instead of bowing to the status quo of impossible deadlines, inadequate user involvement, ill-defined requirements, and programmer isolation. Weaknesses of XP ¼ XP relies heavily on setting up the ideal development environment. It starts from several questionable assumptions: ½ Highly committed clients will spend huge amounts of time working side by side with programmers. In my experience, projects are lucky to get access to true sub- ject matter experts because they are considered too valuable to release from their current responsibilities. 054910-3 Ch02.F 5/31/02 2:04 PM Page 20 [...]... preferences? (See “Avoiding early pitfalls.”) 084910-3 PR01.F 5/31/ 02 2:04 PM Page 45 PART # I Friday Evening Part Review 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 How would you describe the UML? What was the source for the initial UML draft? What did the Object-Oriented Analysis and Design Task Force RFP ask for? How can the UML be extended? What is included in the metamodel? What are the... management and client support 054910-3 Ch 02. F 5/31/ 02 2:04 PM Page 22 22 Friday Evening Each methodology has strengths and weaknesses Choosing a method requires understanding your own environment and matching those strengths and weaknesses to your specific needs QUIZ YOURSELF 1 What are the three key elements of a methodology? (See Session introduction.) 2 What are the two hallmarks of the RUP? (See...054910-3 Ch 02. F 5/31/ 02 2:04 PM Page 21 Session 2 UML and Development Methodologies 21 ½ Programmers work extremely well together In every shop I’ve worked in for over 20 years, programmers tend to be extremely individualistic and resist input from other programmers I’ve mediated too many fights... the system is supposed to work Figure 3 -2 shows that the Use Case diagram defines the functions that the system must provide The functions are expressed first as goals But then the goals are fleshed out in a narrative to describe what each Use Case is expected to do to achieve each goal 064910-3 Ch03.F 5/31/ 02 2:04 PM Page 25 Session 3—How to Approach the UML 25 System Name Assumptions Pre-conditions... Ch03.F 5/31/ 02 2:04 PM Page 26 26 Friday Evening Class diagram Shipment Product -date: Date=today -destination: Address=null -shipper: Vendor=null +authorize(empl: Employee) +seal(empl: Employee) +ship(shipper: Vendor) -desc: String=null -serialnbr: String=systemassigned -spec_handling: String=null delivers 0 1 1 * +reserve(order: Order) +stock(loc: Location) Object diagram 21 : Product 4 321 : Shipment... the XP approach (See “Extreme Programming.”) 064910-3 Ch03.F 5/31/ 02 2:04 PM Page 23 SESSION 3 How to Approach the UML Session Checklist ✔ Explaining the types of UML diagrams ✔ Explaining the concepts of views ✔ Organizing the diagrams into views by function ✔ Explaining the basic Object-Oriented concepts that support modeling T he UML includes specifications for nine different diagrams used to document... String=null delivers 0 1 1 * +reserve(order: Order) +stock(loc: Location) Object diagram 21 : Product 4 321 : Shipment date=01 -27 - 02 destination=Portland, OR shipper=Billy Bob's Trucking desc=CD Player XL 850 serialnbr= 123 456 spec_handling= 96 : Product desc=Speaker Set SS 420 serialnbr =23 4567 spec_handling=fragile Figure 3-3 Class diagram (top) and Object diagram (bottom) To support the Class diagram, you... the interactions between all those things on the blueprint, I would know that if I left the front door open on a cold winter day, my wife would yell at 064910-3 Ch03.F 5/31/ 02 2:04 PM Page 27 Session 3—How to Approach the UML 27 me, the dog would run out the door, the thermostat would send a signal to the furnace, and the furnace would turn on Now that’s dynamic Figure 3-4 shows the three types of... valid, but they don’t help me contact him Figure 3-5 shows Victor on the left, hard at work, and an object icon, my abstraction of Victor, on the right 064910-3 Ch03.F 5/31/ 02 2:04 PM Page 29 Session 3—How to Approach the UML 29 Victor : Person name : Victor phone : 555-555-5555 call(integer): boolean Figure 3-5 Victor on the left (hard at work); abstraction of Victor on the right (an object icon)... the UML diagrams is by using views A view is a collection of diagrams that describe a similar aspect of the project I very often use a set of three distinct yet complementary views that are called the Static View, Dynamic View, and Functional View Figure 3-1 illustrates the complementary nature of the three views and the diagrams that make up each view 064910-3 Ch03.F 5/31/ 02 2:04 PM Page 24 24 Friday . Set SS 420 serialnbr =23 4567 spec_handling=fragile 21 : Product desc=CD Player XL 850 serialnbr= 123 456 spec_handling= 064910-3 Ch03.F 5/31/ 02 2:04 PM Page 26 Session 3—How to Approach the UML 27 me,. responsibilities. 054910-3 Ch 02. F 5/31/ 02 2:04 PM Page 20 Session 2 UML and Development Methodologies 21 ½ Programmers work extremely well together. In every shop I’ve worked in for over 20 years, programmers. changes made to the UML standard? (See “The Continuing Refinement and Expansion of the UML. ”) 044910-3 Ch01.F 5/31/ 02 2:03 PM Page 11 044910-3 Ch01.F 5/31/ 02 2:03 PM Page 12 Session Checklist ✔ Explaining