®

IBM Software Group

RUP for Successful J2EE Projects

Peter Eeles
peter.eeles@uk.ibm.com
Agenda
Š An Overview of RUP
ƒ Rational Unified Process
Š An Overview of RCJD
ƒ RUP Configuration for Java Developers
Š An Overview of applying RCJD
ƒ To the development of an Online Auction application
For more info …
The RUP “Hump Chart”
RUP Key Concepts
Scope
Process
configurations
can be created

Support is
provided for a
browser-based
process
Process
content can be
defined

Process plugins are

available from
DeveloperWorks
(e.g. MS®.net, J2EE,
systems engineering)
Reduce Scrap/Rework: Avoid Sequential Process

Sequential Activities:
Symptoms of conventional
Requirements
waterfall process Design
Š Late design breakage
CodeŠ 40% Integration Test
effort on integration and test

100% Integration
Begins
Development Progress

Late Design
Breakage
(% coded)

Original Completion
Target Date Date

Project Schedule
Reduce Scrap/Rework: Use an Iterative Process

Prototypes Architecture Functional Product

Releases Release

100%
Modern
Project Profile
Development Progress
(% coded)

Waterfall
Project Profile

Project Schedule
Attack Significant Risks Early

Risk Risk Controlled risk management period

exploration resolution
period period
Waterfall
Iterative
Risk

Risk Reduction

Time
RCJD
Š A configuration of RUP
Š Targeted at developers using the J2EE platform
Š A subset of RUP
ƒ No Business Modeling or Deployment disciplines
Š An extension of RUP
ƒ User-Experience Modeling
ƒ J2EE-specific guidance
RCJD Disciplines
RCJD Key Artifacts
Š Requirements
ƒ Glossary
ƒ Supplementary Specification
ƒ Use-Case Model
Š Analysis and Design
ƒ Data Model
ƒ Deployment Model
ƒ Design Model
ƒ Software Architecture Document
ƒ User-Experience Model
Š Implementation
ƒ Implementation Model
What is a model?
Š “A complete description of a system from a particular
perspective” [RUP]
Why do we model?
ŠTo manage complexity
ŠTo clearly understand different concerns
ŠTo detect errors and omissions early in the lifecycle
ŠTo examine the relative merits of different options
ŠTo communicate with stakeholders
ŠTo drive implementation
ŠTo understand the impact of change
ŠTo ensure that resources are deployed efficiently
What is Model-Driven Development?

Analysis &
Requirements Implementation
Design

Testing
Why Model-Driven Development?
ŠTo speed up project delivery
ƒ In the absence of heroics, it is the fastest way to get from A to B
ŠTo improve the quality of the delivered system
ƒ Each model can act as a “quality gate”
ŠTo weave together multiple stakeholder views
ƒ Stakeholders have different, yet related, concerns
ŠTo improve team working
ƒ Models form the basis of a “contract” between project roles
ŠTo be more efficient
ƒ Reusing models (and model elements) throughout the lifecycle
RCJD Models
PearlCircle
Š An Online Auction application
Requirements Artifacts
Requirements – Glossary
Requirements – Use-Case Model
Requirements – Supplementary Specification
Analysis and Design Artifacts
Analysis (and Design) – Design Model
Š Multi-tier architecture employed
Analysis (and Design) – Design Model
Š Key
abstractions
Analysis (and Design) – User-Experience Elements
Š Key screens (and input forms)
Analysis (and Design) – Software Architecture Document

Š Analysis mechanisms
Analysis (and Design) – Design Model
Š Use-Case Realization (Basic flow)
Analysis (and Design) – Design Model
Š Use-Case Realization (Participants)
Analysis (and Design) – User-Experience Model
Š User-Experience Storyboard (Screen flows)
Analysis (and Design) – User-Experience Model
Š User-Experience Storyboard (Participants)
Analysis (and Design) – User-Experience Navigation Map

Š Auction
management
J2EE Architecture
Analysis and Design – Software Architecture Document

Š Design (and Implementation) Mechanisms

J2EE Patterns
Š Presentation Layer
ƒ Composite View
ƒ Front Controller
ƒ Service to Worker
ƒ View Helper
Š Business Layer
ƒ Business Delegate
ƒ Service Locator
ƒ Session Façade
ƒ Value Object
J2EE Patterns – Presentation Layer
J2EE Patterns – Business Layer
Artifact Granularities
Š Design Subsystem
ƒ Used to model an “Enterprise Component”
Š Enterprise Java Bean
ƒ For representing EJBs
Š Design Class
ƒ Used to model JSPs, servlets and Java classes
Analysis and Design – Design Subsystem
Š Enterprise Components
Analysis and Design – Design Subsystem
Š Enterprise Components
Analysis and Design – Enterprise Java Bean
Š E.g. Auction Manager elements
ƒ SessionFaçade and BusinessEntity EJBs
ƒ Represented as a UML 1.4 component
Analysis and Design – Design Class
Š E.g. Auction Manager SessionFaçade elements
Analysis and Design – Use-Case Realization
Š Create Auction use-case realization
Analysis and Design - Data Model
Analysis and Design – Design Model
Š Process view
Analysis and Design – Deployment Model
Implementation Artifacts
Implementation – J2EE Implementation Element Categories
Š Elements deployed in an EJB container
ƒ EJB elements, Java classes
ƒ Organized within Java packages
Š Java elements deployed in a web container
ƒ Servlets, Java classes
ƒ Organized within Java packages
Š Other elements deployed in a web container
ƒ JSPs, image files, HTML pages
ƒ Organized within directories relative to a “virtual directory”
Š Deployment elements
ƒ J2EE application (EAR)
ƒ J2EE modules (WAR, EJB-JAR)
ƒ Deployment descriptors
Implementation – Implementation Model
Š Virtual Directory Elements
(web container)

Š Java Code Elements

(web container)
Implementation – Implementation Model
Š Java Code Elements
(EJB container)
Implementation – Implementation Model
Š Deployment Elements
Summary
Š The “RUP Configuration for Java Developers” (RCJD) is
ƒ A subset of RUP
ƒ An extension of RUP
Š Specifically aimed at developers using the J2EE
platform