1. Rational Unified Process , Introduction to UML

2. What is RUP? The Rational Unified Model is a software engineering process Both process and product Provides a common project knowledge base that may be accessed by team members –Ensures consistency of communication –Commonality of project vision –Enhances productivity Focuses on the development and maintenance of models Reflect the best practices of software development

3. Software Development: Best Practices 1.Develop software iteratively 2.Manage requirements 3.Use component-based architectures 4.Visually model software 5.Continuously verify software quality 6.Control changes to software

4. RUP

5. The X-axis: Time / Iterations 1. Inception 3. Construction 4. Transition 2. Elaboration LifecycleObjectives LifecycleArchitecture Initial Operational Capability ProductRelease milestones

6. Phase 1: Inception Develop business case –Success criteria –Risk assessment –Estimate of resources needed –Phase plan (with dates) Deliverables –Vision document –Preliminary Use-case model –Initial project glossary –Business case –Possibly, some prototypes

7. Inception Milestone: Lifecycle Objectives Stakeholder agreement on project scope and cost/schedule estimates. Requirements understanding (based on quality of primary use cases). Credibility of the cost/schedule estimates, priorities, risks, and development process. Depth and breadth of any architectural prototype that was developed. Actual expenditures versus planned expenditures.

8. Phase 2: Elaboration Goals –Develop a “big picture” view of the project –Most of the analysis is done in this stage –Develop an architectural foundation for the system –A working, exploratory working prototype –Possibly the most important of the phases Deliverables (partial list) –More comprehensive use-case model –Supplementary requirements (not covered in use-case) –Revised risk assessment and business case –Working prototype –Development plan (with dates and number of iterations)

9. Elaboration Milestone: Lifecycle Architecture Is the vision of the product stable? Is the architecture stable? Does the executable demonstration show that the major risk elements have been addressed and credibly resolved? Is the plan for the construction phase sufficiently detailed and accurate? Do all stakeholders agree that the current vision can be achieved ? Is the actual resource expenditure versus planned expenditure acceptable?

10. Phase 3: Construction The manufacturing phase Goals –Develop and integrate all remaining components into product –Thorough testing of all features Deliverables –Actual product on the appropriate platform (beta release) –User manuals –Description of current release

11. Construction Milestone: Initial Operational Capability Is this product release stable and mature enough to be deployed in the user community? Are all stakeholders ready for the transition into the user community? Are the actual resource expenditures versus planned expenditures still acceptable?

12. Phase 4: Transition Involves “beta testing” Parallel conversion Convert operational databases Train users and support personnel Rollout the product to other functional areas (marketing, distribution, etc.) Typically involves several iterations (for purposes of fine tuning user manuals and the product)

13. Transition Milestone: Product Release Focuses on whether objectives were met –New development cycle needed? The questions - –Is the user satisfied? –Are the actual resources expenditures versus planned expenditures still acceptable?

14. Software Development: Best Practices 1.Develop software iteratively 2.Manage requirements 3.Use component-based architectures 4.Visually model software 5.Continuously verify software quality 6.Control changes to software

15. RUP

16. The X-axis: Time / Iterations 1. Inception 3. Construction 4. Transition 2. Elaboration LifecycleObjectives LifecycleArchitecture Initial Operational Capability ProductRelease milestones

17. RUP

18. Representing the RUP Processes involve –Who is doing –What, –How its being done –And when it was done RUP main model elements –Workers – the who –Activities – the what –Artifacts – the how –Workflows – the when worker activity

19. RUP Element: Workers “A worker defines the behavior and responsibilities of an individual, or a group of individuals working together as a team”. Not really referring to a person or team Refers to role individual plays in doing work Worker responsibilities include –Activities –Artifact ownership

20. Example of Workers

21. RUP Element: Activity An activity of a specific worker is a unit of work that an individual in that role may be asked to perform Activities –Have clear purpose –Assigned to specific worker –Limited time span (hours or days) –Affects limited number of artifacts

22. RUP Element: Artifacts An artifact is a piece of information that is produced, modified, or used by a process Artifacts –Tangible results of activities in the project –Outputs of activities –May be used as inputs for other activities Examples –Models or model elements –Documents –Code –Executable prototypes

23. RUP Element: Workflows A workflow is a sequence of activities that produces a result of observable value. –Describes a meaningful sequence that produces a useful result –Shows interaction between workers UML represents workflows through –Sequence diagram –Collaboration diagram –Activity diagram

24. Example of Workflows

25. Core Workflows

26. Nine core workflows –Divided into two groups Process workflows Supporting workflows –Based on workers and activities The activities in the workflow are revisited with each iteration Emphasis on the activity changes with each iteration

27. Core Workflows

28. Six Process Workflows Business Modeling –Communication problems arise between analysts and business –Document business processes Business use-cases –Artifact is a “business object model” –Ensures all stakeholders on same page –Not always done

29. Six Process Workflows contd. Requirements –Describe the desired system functionality –Involves eliciting, organizing, and documenting required functionality and constraints –Artifacts include Vision document Use-cases –The use-cases are the common thread for all workflows

30. Six Process Workflows contd. Analysis and Design –show how the system will be created in the implementation –Artifact is a Design Model Acts as blueprint for coding Presents organized classes, subsystems, and interfaces Based on architecture of system

31. Six Process Workflows contd. Implementation –To define the organization of the code –To implement classes and objects in terms of components –To test the developed components as units. –To integrate the results produced by individual implementers (or teams), into an executable system (a prototype)

32. Six Process Workflows contd. Testing –Objectives To verify the interaction between objects. To verify the proper integration of all components of the software. To verify that all requirements have been correctly implemented. To identify and ensure defects are addressed prior to the deployment of the software. –Based on reliability, functionality, application performance and system performance. –Continuous process throughout the development process

33. Six Process Workflows contd. Deployment –Aims to successfully produce product releases, and deliver the software to its end users –Includes Producing external releases of the software Packaging the software Distributing the software Installing the software Providing help and assistance to users

34. Core Workflows

35. Three Support Workflows Configuration and Change Management –control the numerous artifacts produced during project –Typical problems with managing large number of artifacts Simultaneous Update Limited notification Multiple versions –how to report defects, manage them through their lifecycle

36. Three Support Workflows contd. Project Management –Involves Balancing competing objectives Overcoming constraints deliver a product which meets the needs of both customers (the payers of bills) and the users –RUP provides A framework for managing software-intensive projects Practical guidelines for planning, staffing, executing, and monitoring projects A framework for managing risk

37. Three Support Workflows contd. Environment –provide software development environment-- both processes and tools--that are needed to support the development team. –focuses on the activities to configure the process in the context of a project –focus on activities to develop the guidelines needed to support a project.

38. Introduction to UML a language for specifying, visualizing, constructing, and documenting the artifacts of software systems Can also be used for non-software modeling represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems

39. Companies involved Rational Software, Microsoft, Hewlett- Packard, Oracle, Sterling, Software, MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam.

40. The Three Amigos Grady Booch James Rumbaugh Ivar Jacobson

41. Modeling Simplified version of reality Models are built from building blocks –Classes, interfaces, collaborations, associations, etc. Diagrams are graphical representations of those blocks Five views of a system –Use case view –Design view –Process view –Implementation view –Deployment view

42. UML supported models Class Model –Static structure State Model –Dynamic behavior Use Case Model –User requirements Interaction Model –Scenarios and message flows Implementation Model –Work units Deployment Model –Related to process allocation

43. UML supported diagrams Use Case Class Sequence Collaboration Object Statechart Activity Component Deployment

44. Types of Modeling UML’s nine diagrams used to assemble the views Structural Modeling (static parts of system) –Class –Object –Component –Deployment Behavioral Modeling (dynamic parts) –Use case –Sequence –Collaboration –Statechart –Activity

45. Use Case Analysis

46. The Use Case Basics Users perform behaviorally-related sequence of transactions Use cases model system by identifying and describing events –Use textual description –Graphical representation Each use case describes a single event System functionality defined by collection of all use cases

47. Use Case Elements Actors –The party that initiates a behavior of the system –Defined by roles Person (eg: member) Company (eg: bank) Another system (eg: inventory) Use Cases –Descriptive scenarios (how actor interacts with system) –Each is a complete event triggered by actor –Rule of thumb: A use case model will contain one or two dozen use cases

48. An example…office supplies Many possible use cases related to inventory and purchasing –Update stocks –Buy goods –Return goods –Pay by credit card –And more Consider the event of a customer buying a good…

49. Use Case example Questions to answer –What is the general information about the event? Goal, scope, preconditions, the triggering actor, the trigger, etc. –What is the main success scenario What is the chain of transactions that occur if the everything goes smoothly? –What are some of the possible extensions and sub- variations? –Any related information? Priority, frequency, superordinate use case, subordinate use case –Open issues and questions –Schedule (due date)

50. Next Class More about Use Case Modeling –Applying the modeling –Identifying actors –Developing high-level use cases –Expanded use cases –Documenting use cases –UML support for use cases