Rational Unified Process , Introduction to UML

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 • Develop software iteratively • Manage requirements • Use component-based architectures • Visually model software • Continuously verify software quality • Control changes to software

4. RUP

5. The X-axis: Time / Iterations 1. Inception Lifecycle Objectives Product Release 2. Elaboration 4. Transition milestones Initial Operational Capability Lifecycle Architecture 3. Construction

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 • Develop software iteratively • Manage requirements • Use component-based architectures • Visually model software • Continuously verify software quality • Control changes to software

15. RUP

16. The X-axis: Time / Iterations 1. Inception Lifecycle Objectives Product Release 2. Elaboration 4. Transition milestones Initial Operational Capability Lifecycle Architecture 3. Construction

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. Core Workflows • 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