1 / 64

ANNEX II

REVIEW OF RUP AND UML. ANNEX II. REVIEW OF RATIONAL UNIFIED PROCESS ( RUP ). The Rational Unified Process The Rational Unified Process is a generic process model t hat separates activities from phases. It is a modern process model derived from the work on the

mstroup
Download Presentation

ANNEX II

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

E N D

Presentation Transcript

  1. REVIEW OF RUP AND UML ANNEX II BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  2. REVIEW OF RATIONAL UNIFIED PROCESS ( RUP ) BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  3. The Rational Unified Process • The Rational Unified Process is a generic process model thatseparates activities from phases. • It is a modern process model derived from the work on the • UMLand associated process. • Normally described from 3 perspectives • - A dynamic perspective that shows phases over time; • - A static perspective that shows process activities; • - A practice perspective that suggests good practice. • Sommerville -7thEd Ch4Sl.37 BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  4. RUP phase model BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  5. Satzinger-Jackson-Burd, p.54 BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  6. The Unified Process Life Cycle • UP life cycle includes • - (4) phases which consist of iterations • - Iterations are “mini-projects” • Phases are: • - Inception: develop and refine system vision. Establish the • business case for the system. • - Elaboration: define requirements and core architecture. • Develop an understanding of the problem domain and the • system architecture. • - Construction: continue design and implementation, • namely, system design, programming and testing. • - Transition: move the system into operational mode. Deploy • the system in its operating environment. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  7. The Unified Process System Development Life Cycle SJB2005Ch2Sl13 BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  8. Some Models used in System Development SJB2005Ch2Sl18 BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  9. Referring to Booch-Rumbaugh-Jacobson,1999,UML includes 9 diagrams : • Class Diagram • Object D. • Use case D. • Sequence D. • Interaction diagram • Collaboration D. • Statechart D. • Activity D. • Component D. • Deployment D. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  10. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. • An object diagram shows a set of objects and their interrelationships. • A use case diagram shows a set of use cases and actors ( a special kind of class) and their relationships. • Both sequence diagrams and collaboration diagrams are kind of interaction diagrams. An interaction diagram shows an interaction , consisting of a set of objects and their relationships, including the messages that may be dispatched among them. Interaction diagrams address the dynamic view of a system. • - A sequence diagram is an interaction diagram that BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  11. emphasizes the time-ordering of messages; • - A colloboration diagram is an interaction diagram that • emphasizes the structural organization of the objects that • send and receive messages. • A statechart diagram shows a state machine , consisting of states, transitions, events and activities. • An activity diagram is a special kind of of a statechart diagram that shows the flow from activity to activity within a system. • A component diagram shows the organizations and dependencies among a set of components. • A deployment diagram shows the configuration of run-time processing nodes and the components that live on them. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  12. The Unified Process as a System Development Methodology • UP: object-oriented system development methodology • UP should be tailored to organizational and project needs • SJB2005Ch2Sl22 BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  13. The Unified Process as a System Development Methodology(continued) • Use case • - Activity that the system carries out • - Basis for defining requirements and designs • UP defines disciplines within each phase • Discipline: set of functionally related activities • Iterations concatenate activities from all disciplines • Activities in each discipline produce artifacts; models, • documents, source code, and executables • SJB2005Ch2Sl23 BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  14. UP Life Cycle with Phases, Iterations, and Disciplines • Six main UP development disciplines • - Business modeling, requirements, design,implementation, • testing, and deployment • Each iteration • - Similar to a mini-project • - Results in a completed portion of the system • Three additional support disciplines are : • Project management, configuration and change • management, and environment . BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  15. FUNDAMENTALS OF UML REF: Boggs&Boggs,”Mastering UML with Rational Rose”, SYBEX,2002 BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  16. The Unified Modeling Language ( UML ) • Several different notations for describing object-oriented designs were proposed in the 1980s and 1990s. • The Unified Modeling Language is an integration of these notations. • It describes notations for a number of different models that may be produced during OO analysis and design. • It is now a de facto standard for OO modelling. • Sommerville -7thEd.Ch14.Sl10 BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  17. REF: Boggs&Boggs,2002, Ch.1 • UML allows people to develop several different types of • visual diagrams that represent various aspects of the • system. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  18. Rational Rose supports the development of the • majority of these models, as follows: • Business Use Case diagram • Use Case diagram • Activity diagram • Sequence diagram • Collaboration diagram • Class diagram / Object diagram • Statechart diagram • Component diagram • Deployment diagram BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  19. Business Use Case Diagrams Business Use Case diagrams are used to represent the functionality provided by an organization as a whole. They answer the questions: - "What does the business do?" - "Why are we building the system?" BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  20. They are used extensively during business modeling activities to set the context for the system and to form a foundation for creating the use cases. An example of a simplified Business Use Case diagram for a financial institution is shown in Figure 1.8. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  21. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  22. Business Use Case diagrams are drawn from the organizational perspective. They do not differentiate between manual and automated processes. Use Case diagrams, which will be discussed next, focus on the automated processes. Business Use Case diagrams show the interactions between business use cases and business actors. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  23. Business use cases represent the processes that a business performs, and business actors represent roles with which the business interacts, such as customers or vendors. In other words, business actors represent anyone or anything outside the business that interacts with the business; they do not represent roles or workers within a business. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  24. Use Case Diagrams Use Case diagrams show the interactions between use cases and actors. Use cases represent system functionality, the requirements of the system from the user's perspective. Actors represent the people or systems that provide or receive information from the system; they are among the stakeholders of a system. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  25. Use Case diagram can illustrate the requirements of the system. While Business Use Case diagrams are not concerned with what is automated, Use Case diagrams focus on just the automated processes. An example of a Use Case diagram for an Automated Teller Machine (ATM) system is shown in Figure 1.9. This Use Case diagram shows the interactions between the use cases and actors of an ATM system. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  26. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  27. Much information can be gleaned from viewing Use Case diagrams. This one diagram shows the overall functionalityof the system. Users, project managers, analysts, developers, quality assurance engineers, and anyone else interested in the system as a whole can view these diagrams and understand what the system is supposed to accomplish. to glean : hasat etmek; sabırla işe yarayanları ayıklamak BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  28. Activity Diagrams Activity diagrams illustrate the flow of functionality in a system. They may be used in business modeling to show the business workflow. They may be used in requirements gathering to illustrate the flow of events through a use case. These diagrams define where the workflow starts, where it ends, what activities occur during the workflow, and in what order the activities occur. An activity is a task that is performed, during the workflow. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  29. An example of an activity diagram is shown in Figure 1.10. The activities in the diagram are represented by rounded cornered rectangles or rounded rectangles. These are the steps that occur as you progress through the work­flow. Classes / Objects that are affected by the workflow are represented by squares/rectangles. Class names are underlined and they have : in front. There is a start state, which represents the beginning of the workflow, and an end state, which represents the end. Decision points are represented by diamonds. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  30. You can see the classs/object flow through the diagram by examining the dashed lines. The class/object flow shows you which class/objects are used or created by an activity and how the class/object changes state as it progresses through the workflow. The solid lines, known as transitions, show how one activity leads to another in the process. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  31. The activity diagram may be divided into vertical swimlanes. Each swimlane represents a different role within the workflow. By looking at the activities within a given swimlane, you can find out the responsibility of that role. Activity diagrams do not need to be created for every workflow, but they are powerful communication tools, especially with large and complex workflows. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  32. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  33. Sequence Diagrams Sequence diagrams are used to show the flow of functionality through a use case . SD s show also time ordering of processes in the use case. Referring to Fig.1.11 which shows the flow of processing through a certain use case, say Withdraw Money use case, any actors involved in the use case are shown at the top of the diagram.The customer actor is shown in that example. The objects that the system needs in order to perform the Withdraw Money use case are also shown at the top of the diagram. Each arrow represents a message passedbetween actor and object or object and object to perform the needed functionality. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  34. A note about SD is that they display objects, not classes. Classes represent types of objects. Objects are specific; instead of just :customer, the Sequence Diagram shows Joe. Each object has a lifeline, drawn as a vertical dashed line ( or a slim rectangle ) below the object. The lifeline begins when the the object is instantiated and ends when the object is destroyed. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  35. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  36. This Sequence diagram illustrated the entire flow of processing for the Withdraw Money use case by showing a specific example of Joe withdrawing $20 from his account. Users can look at these diagrams to see the specifics of their business processing. Analysts see the flow of processing in the Sequence diagrams. Developers see objects that need to be developed and operations for those objects. Quality assurance engineers can see the details of the process and develop test cases based on the processing. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  37. Collaboration Diagrams Collaboration diagrams show exactly the same information as the Sequence diagrams. However, Collaboration diagrams show this information in a different way and with a different purpose. While Sequence diagrams are ordered by time,Collaboration diagrams focus more on the relationships between the objects. In this diagram it is easier to see the relationships between the objects. However it is a little more difficult to see the sequencing information. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  38. In this Collaboration diagram, the objects are represented as rectangles and the actors are stick figures, as before. Whereas the Sequence diagram illustrates the objects and actor interactions over time, the Collaboration diagram shows the objects and actor interactions without reference to time. The absence of a line means that no communication occurs directly between those two objects. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  39. Collaboration diagrams, therefore, show the same information as Sequence diagrams, but people look at collaboration diagrams for different reasons. Quality assurance engineers and system architects look at these to see the distribution of processing between objects. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  40. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  41. Class / Object Diagrams Class diagrams show the interactions between classes in the system. Classes can be seen as the blue­print for objects. An account is a class. Classes contain information and behavior that act on that information. A class on a Class diagram is created for each type of object in a Sequence or Collaboration diagram. The Class diagram for the system's Withdraw Money use case is illustrated in Figure 1.13. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  42. The Class diagram shows the relationships between the classes that implement the Withdraw Money use case. Each class on a Class diagram is represented by a rectangle divided into three sections. The first section shows the class name. The second section shows the attributes the class contains. An attribute is a piece of information that is associated with a class. The last section contains the operations of the class. An operation is some behavior that the class will provide. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  43. The lines connecting classes show the communication relationships between the classes. Another point of interest is that some attributes and operations have small padlocks to the left of them. The padlock indicates a private attribute or operation. Private attributes and operations can only be accessed from within the class that contains them. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  44. Developers use Class diagrams to actually develop the classes. Tools such as Rose generate skeletal code for classes, then developers flesh out the details in the language of their choice. Analysts use Class diagrams to show the details of the system. Architects also look at Class diagrams to see the design of the system. If one class contains too much functionality, an architect can see this in the Class diagram and split out the functionality into multiple classes. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  45. Class diagrams should be created to show the classes that work together in each use case, and comprehensive diagrams containing whole systems or subsystems can be created as well. A stereotype is a mechanism you can use to categorize your classes. << >> guillemets : also called angle quotes. Setting Class Visibility: The Visibility option determines whether or not a class can be seen outside of its package. There are three visibility options for a class: Public Suggests that the class can be seen by all of the other classes in the system. ( Symbol is + ) Protected or Private Suggests that the class can be seen in nested classes, friends, or within the same class. ( for Private symbol is - and for protection # symbol is used. ) Package or Implementation Suggests that the class can be seen only by other classes in the same package. No special symbol is used. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  46. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  47. Statechart Diagrams Statechart diagrams provide a way to model the various states in which an object can exist. While the Class diagrams show a static picture of the classes and their relationships, Statechart diagrams are used to model the more dynamic behavior of a system. These types of diagrams are extensively used in building real-time systems. Rose can even generate the full code for a real-time system from the Statechart diagrams. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  48. A Statechart diagram shows the behavior of an object. For example, a bank account can exist in several different states. It can be open, closed, or overdrawn. An account may behave differently when it is in each of these states. Statechart diagrams are used to show this information. Figure 1.14 shows an example of a Statechart diagram for a bank account. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  49. In this diagram, we can see the states in which an account can exist. The customer’s request is called the event and the event is what causes a transition from one state to another. A condition enclosed in square brackets is called a guard condition, and controls when a transition can or cannot occur. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

  50. There are two special states—the start state and the stop state. The start state is represented by a black dot on the diagram, and indicates what state the object is in when it is first created. The stop state is represented by a bull's-eye, and shows what state the object is in just before it is destroyed. On a State-chart diagram, there is one and only one .start state. On the other hand, you can have no stop state, or there can be as many stop states as you need. BİL 420 Practical UML /Spring2011/ Prof.Dr.Ziya Aktaş

More Related