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

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
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

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
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

• UMLs 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 exampleoffice 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