You are on page 1of 72

Usage of Patterns,

RUP - J2EE Design, and

RUP Implementation (Build)

Nandan Dasgupta TCJUG

What is RUP?

RUP - Use case Driven

Product Development is Use case Driven:

Verified by




Implemented by Use cases Realized by



Specified by

Design2 Design4 Design3




RUP Risk Driven

Supplement with Non-Functional Requirements

Business Functional Requirements (Use cases)

1. Usability a. Aesthetics b. Consistency 2. Reliability a. Recoverability b. Predictability c. Accuracy 3. Performance a. Efficiency - Resource Consumption b. Throughput - Response Time 4. Supportability a. Testability b. Extensibility c. Adaptability d. Maintainability e. Compatibility f. Configurability g. Others

analysis, design, development

Quality Attribute Drivers

Software Architecture
possess this



System Development Overview


Vision feeds Requirements drive Architecture


Vision Document

Software Requirements


Use Case UI Specifications (Site Map, Use Case Storyboard)

Use Case Model

Use Case Use Case Supplementary Specifications

Use case Analysis analysis, decision, definition


Buy a Vendor Product

Modify an Usage of Existing System Developed Facility

usage of Legacy aligning with policy

availability of resources availability in market

Architecture ==Design Elements, Design Mechanisms, Run-Time Arch. analysis, decision, definition Implementation (Build/ Enhance, Integration and Testing) Deployment (Roll Out)


build executables

RUP Architecture Centric

Requirements question Architecture answer Use case Analysis Design blueprint

Implementation (Build/ Enhance, Integration and Testing) Build components which trace to design objects (and all the way back to use cases) To identify and ensure defects are addressed prior to deployment Deployment (Roll Out) Configuration of run-time processing elements and software components, processes, and objects that live on them


RUP Iterative and Incremental

Iterative: Repeat essentially the same process Incremental: Deliver usable functionality in chunks
Balancing Risks Across Multiple Releases Inception Iteration Transition Iteration Architectural Risks Could be Moved Forward Making Initial Releases Harder and Subsequent Releases Easier Transition Iteration

Elaboration Iteration (s)

Construction Iteration (s)

Inception Iteration

Elaboration Iteration (s)

Construction Iteration (s)

Production Risks Could be Moved Backwards Reducing The Business Benefits of Earlier Releases

Inception Iteration

Elaboration Iteration (s)

Construction Iteration (s)

Transition 7 Iteration

RUP Analysis & Design


RUP Analysis & Design: Purpose

Transform the requirements into a design of

the system to be Evolve a robust architecture of the system Adapt the design to match the implementation environment

Layered Architecture

User Interface

Responsible for presenting information to the actor and interpreting actors commands

Domain Infrastructure

Responsible for implementing application specific logic using domain objects

Responsible for representing core business concepts, business processes and business rules

Provides general technical capabilities that support the higher layers


J2EE Architecture
Middle Tier (Domain Logic Layer and Data Layer)
Presentation Tier Web Tier Business Tier Database Tier


J2EE Architecture - Sample

HTML Page Serv let Validate Session Bean Login Entity Bean Account Entity Bean dB Request for Withdrawal Passes Request Check Balance Check Logins

Av ailable W ithin Limit

Update Acccount

Update Logins Update Update

Updated Updated

New Balance Triggers Vending Cash

Displays Results


Model-Driven Design
The model and the design shape each other
The model is the backbone of a language

used by all team members The model is distilled knowledge


Model-Driven Design: Components

Knowledge crunching
Communication and the Use of Ubiquitous

Language Binding Model and Implementation


Knowledge Crunching

Design together with domain experts

Continuous learning Knowledge-Rich Design Deep Models


Communication and Use of Language

Ubiquitous Language
One Team, One Language Documents and Diagrams Written Design Documents Executable Models Overview Models


Ingredients of Effective Modeling

Binding the model and the implementation

Cultivating a language based on the model Developing a knowledge-rich model Distilling the model Brainstorming and experimenting

Using right tool


Design Building Blocks

Entities Objects identified by their identity Object definition focused on life cycle continuity and identity Value Objects When focused on the attributes of an element, classify it as Value Object Services Operation relates to a domain concept

Design Building Blocks (cont.)

Aggregate is a cluster of associated objects Each Aggregate has a root and boundary Boundary defines what is inside the Aggregate Root is a single Entity contained in the Aggregate Root Entity has global identity and is responsible for enforcing invariants Entities inside the boundaries have local identity Objects within the Aggregate can hold references to other Aggregate roots A delete operation must remove everything within the Aggregate Keep associations between Aggregates minimal Protect aggregate with Faade interface

Aggregate Rules:


Design Building Blocks (cont.)

Factories provide encapsulation of complex rules for creating

Objects or Aggregates Making client responsible for creating Objects and assembling the Aggregates to coupled design Shift responsibility for creating complex Objects to a separate object which is part of the domain design

A client needs a practical means of acquiring references to pre-

existing domain objects Low level technical details must hidden from client




Design Build


RUP Elaboration Phase

Proceed with J2EE up-front, not at the end Refine the architecture and select components Determine that Prototypes should include J2EE Ensure Executable architecture should have J2EE tools selected Determine Implementation Plan Determine how many tiers
Define boundaries and boundary rules Determine where J2EE components will be placed in packages/ subsystems

Design and programming guidelines should include J2EE specifics

Detail the Design

Model EJBs and other J2EE Technologies

Decide how to unit test EJBs


Choose only those J2EE technologies that are really needed

RUP Construction Phase

Refine/ Update the architecture and select components Detail/ Update the Design
Model EJBs and other J2EE technologies

Provide J2EE development environment for all developers Decide the right level of ceremony for the culture Ensure Detailed modeling on risk areas, medium on non-risky Implement J2EE patterns in first Iterations Address Deployment issues early Consider the importance of database design/ implementation


J2EE Technologies
RMI - Remote Method Invocation - Protocol for distributed
communication Servlets - Java code which serves up dynamic web pages JSP - Combination of HTML and Java which can be intermixed JNDI - Java Naming and Directory Interface - Provides a common interface to communicate with different naming and directory services

JDBC - Java Database Connectivity - Provides a common interface to heterogeneous data bases
25 EJB - Enterprise Java Beans - Distributed Java Components, Stateless, Stateful, Entity and Message Driven

J2EE Design Input from Analysis


J2EE Design Input from Analysis (Use case Diagram)

<<extends>> Customer Entry of Card Validation of PIN <<extends>>

Vends Cash Send response to customer

Bank Validation process

Check Balance


J2EE Design Input from Analysis (cont.) (Class Diagram)

Validate PIN

Failed Logins


Card Login

Card Entry

Customer Logins

Other Financial Customers


J2EE Design Input from Analysis (cont.) (Sequence Diagram)

: Actor : CardLogin : Validate : FailedLogins : CustomerLogins : OtherFinancialCustomers 1.0 Enter Card 1.1 Enter PIN

1.2 Submit Requests

1.3 Validate PIN

1.3.1 Determine Financial Institution

1.4 Asks Amount

1.5 Enters Amount

1.6 Submit Requests

1.7 Validates Balance

1.8 Logs Entry

1.9 Tenders Cash


Design Patterns

What is a pattern?
Problem/ Solution pairs in context

Patterns facilitate reuse of successful software architecture and design Not Code Reuse; But
Solution/ Strategy reuse

Interface reuse


Common Design Patterns

Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation

Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically

Provide a surrogate or placeholder for another object to control access to it

Creation Patterns
Creational Patterns prescribe the way that objects are created. These patterns are used when a decision must be made at the time a class is instantiated. Typically, the details of the classes that are instantiated -what exactly they are, how, and when they are created -- are encapsulated by an abstract superclass and hidden from the client class, which knows only about the abstract class or the interface it implements.

Ensure a class has one Instance, and provide a global point of access to it

Abstract Factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes 33

Structural Patterns
Structural Patterns prescribe the organization of classes and objects. These patterns are concerned with how classes inherit from each other or how they are composed from other classes.

Convert the interface of a class into another interface that clients expect Adapter lets classes work together that couldnt otherwise because of incompatible interfaces

Direct stand-in for another class, and it typically has the same interface as that of class because it implements a common interface

Extend the functionality of the original class in a way that is transparent to the client class

Behavioral Patterns
Behavioral Patterns prescribe the way objects interact with each other. They help make complex behavior manageable by specifying the responsibilities of objects and the ways they communicate with each other.

Allow an object to alter its behavior when its internal state changes

Represents an operation to be performed on the elements of an object structure Visitor lets one to define a new operation without changing the classes of the elements on which it operates

Concurrency Patterns
Concurrency Patterns prescribe the way access to shared resources is coordinated or sequenced.

Single Thread Execution

Prevent concurrent calls to Objects that are not in an appropriate state to execute the method call


Integrating Design Patterns for Designing an Application Framework


Design Patterns for J2EE

Model View Controller (MVC) Fundamental Pattern for J2EE applications with a GUI Three categories of patterns implement MVC: Presentation Business Integration


Presentation Tier Patterns

Intercepting Filter Front Controller Composite View View Helper Service to Worker Dispatcher View


Front Controller Pattern

Web application with complex navigation

Duplication of code if each view provides its own services Risk of mixing presentation and navigation code

Use of a Controller to handle all web requests

The controller works with a Dispatcher that handles navigation


Front Controller Pattern (cont.)

Client FrontController Dispatcher View Helper 1: Send Request 1.1: Delegate Request

1.1.1: Forward Request

2: Send Request

2.1: Forward Request

3: Send Request

3.1: Process Request


Service to Worker Pattern

Web application
Views are generated automatically from templates

Processing common to multiple requests (e.g.: authentication) should be centralized Generation of the view from the template should be made by a dedicated components

Combination of a Dispatcher with a Controller, the views and the Helpers 42 Dispatcher: responsible for view management and navigation

Service to Worker Pattern (cont.)

Client FrontController 1: Request Dispatcher View Helper BusinessService 2: Retrieve Content 2.1: Get Data

3: Delegate Request

4: Choose Next View

4.1: Get Data

5: Dispatch

5.1: Get Property


Business Tier Patterns

Business Delegate Service Locator Session Faade Value Object Composite Entity Value Object Assembler Value List Handler


Business Delegate Pattern

Application where the business APIs are completely exposed to clients

The whole API is exposed to client use Presentation layer is tightly coupled to business implementation

Use of a Business Delegate to hide Implementation Detail


Business Delegate Pattern (cont.)

1: Create with ID BusinessDelegate 1.1: Convert ID to Handle


Handle 1.1.1: Create

2: Invoke 2.1: Get Business Service

2.1.1: Connect

2.1.2: Return Business Service

2.2: Invoke


Session Faade Pattern

Session Bean provides unified approach
Faade hides Entity Bean Details


Integration Tier Patterns

Data Access Object
Service Activator User Workflow Integrator


Data Access Object

Business Object inherits accesses DataAcces sObject inherits


Oracle DAO


Sybase DAO




Oracle Database

DB2 Database

Sybase 49 Database

Value Object

Remote, coarse-grained access

EJB Object

Web Component


Local, fine-grained access

Value Object


Detail the Design (Elaboration and Construction)


Design shapes the system in a way that lives up to all requirements Results in a design model (s)

Input to Implementation
Create Design Class (es) that realizes the Use cases it is involved in and non-functional requirements defined in the Use cases - Account all technical implications and restrictions Assign the behavior of the Use cases to the Design Classes - Identify responsibilities and relationships Design can be divided into two segments Architectural design (Refine the Architecture)

Implementation Design (Detail the Design)

RUP - J2EE Design

Design Refine the Architecture Identify Design Mechanisms Identify what J2EE patterns are going to be used Identify what J2EE Technologies are going to be used Identify Design Elements Identify JSPs, Servlets, EJBs and other J2EE Elements Incorporate existing Design Elements None Describe Concurrency and Distribution Describe the use of threads and message-driven EJBs Map J2EE modules to Nodes Use case Design Subsystem Design Component Design Class design Database Design Describe the interaction between collaborating J2EE Elements Describe the subsystem in terms of their internal J2EE Elements Produce a detail design of EJBs Produce a detail design of JSPs, Servlets, and other Java Classes Define the mapping between entity EJBs and the underlying database 53

Detail the Design

Modeling Java Servlets in UML

Modeled as ordinary Java Classes
Use stereotypes to distinguish Servlet types
= <<HTTP _ Servlet>> = <<Generic_Servlet>>


Modeling JavaServer Pages in UML

Modeled as Two Logical Entities
A <<Server Page>> is a class stereotype that abstracts the Web Pages behavior on the Server A <<Client Page>> abstracts the behavior of a Web Page on the Client


Modeling EJBs in the UML (External View Example)

Home Interface <<EJBEntityHomeInterface>> AccountHome


Remote Interface

<<EJBRemoteInterface>> Account


Modeling EJBs in the UML (Internal View Example)

<<EJBRemoteInterface>> Account <<EJBRealizeRemote>> <<EJBEntity>> AccountBean

<<instantiate>> <<EJBRealizeHome>>

<<EJBEntityHomeInterface>> AccountHome


<<EJBPrimaryKey>> AccountKey


Design Component (Construction)


A component is a named physical and replaceable part of a system that represents
physical packaging of otherwise logical elements and that conforms to, and provides the realization of, one or more interfaces. A component type represents a piece of software code (source, binary, or executable) A component type has a type name A component instance represents a run-time code unit

A component instance has a name and a type (component-name : component-type)

A component is represented as a rectangle with two small rectangles protruding from its side




Physical packaging of model elements - Source, binary, executable, configuration, makefile, IDL bindings, etc.

- Aggregate of other components

Standard stereotypes - <<executable>> - a program that may run on a node - <<application>> - consists of several executables - <<file>> - file containing source code or data - <<library>> - static or dynamic library - <<document>> - a document - <<page>> - HTML page - technology specific <<ActiveX>>, <<JavaBean>>, <<Applet>>, <<DLL>>, <<CORBA Component>>

Modelling Elements: Components
Basic Class Object Interface Collaboration Use-case Active Class Component Node Composite Package
Classes are basic model elements. Class names are shown in boldface type. Abstract classes are shown in italic. Object (Class Instance) are shown by class elements with underlined names. Interfaces are indicated by lollipops. Collaborations are indicated by dashed ovals. (They realize use-cases). Use-case is shown by ellipse. Active classes are shown by thick bordered class boxes.(They represent independent thread of processing). A Component is a combination of one or more classes that forms a physical software element. A Node is a processor or hardware device. A Composite Model element is a package or a61 subsystem of base or composite elements.

Component Diagram
A component diagram shows the dependencies among software components, including source code components, binary code components, and executable components.

A component diagram has only a type form, not an instance form.

A component diagram is a graph of components connected by dependency relationships.

Component Diagram
Use cases are eventually realized as components (Code) Components of the Implementation
<<file>> Failed Login s

Components Implement Design Classes

<<page>> GUI/ Slide Entry

<<executable>> entry of cards

trace 63

Component Diagram Component Characteristics

Components trace to the model elements they implement (hence all the way back to use cases) A Component usually implements several elements Components provide the same interface as the model elements they implement Compilation dependencies denote which components are required to compile a specific component

Implement component stubs to ease compilation, integration and test


Design the Distribution (Construction)


Deployment Diagram

Deployment diagrams show the configuration of runtime processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestation of code units.
Components that do not exist as run-time entities do not appear in Deployment diagrams.


Deployment Diagram
A deployment diagram is a graph of nodes connected by communication associations. Nodes may contain component instances; indicates Component run on nodes.

Components may contain objects; indicates Objects is part of the component.

Components are connected to other components by dashed-arrow dependencies.

Deployment Diagram
A Deployment Diagram shows the actual Hardware configuration consisting of
Nodes (processors) Software - Components Processes Objects


Deployment Diagram
Sample Deployment Diagram This diagram shows 3 machines: 2 PC workstations running WebLogic and a Mainframe running the ODSs in DB2

<<Buildmaster Workstation>> PC:Win2000 on Intel <<WLS Instance: Port 8888>> Admin Domain:WLS 6.1 Admin Server

<<WIN2000 on 1 Ghz PIII>> WebLogic W(dev) Server: WLS Managed Server administer SSL administer <<WLS Instance: Port 8888>> Admin Domain:WLS 6.1 Admin Server <<WL Instance: Port 7001>> Team's Server: WLS 6.1

<<Web Browser>> IE 5.5

<<Mainframe>> DB2 UNT: SYS D <<database>> Claim:ODS get data <<database>> PA&R:ODS

<<Enterprise Application>> JDG.ear

<<database>> 69 Login:ODS


The Rational Unified Process-An Introduction - Philippe Kruchten Use Case Modeling - Kurt Bittner, Ian Spence, Foreword by Ivar

Jacobson Writing Effective Use Cases - Alistair Cockburn Design Patterns: Elements of Reusable Object-Oriented Software Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides Core J2EE Patterns - Deepak Alur, John Crupi, and Dan Malks Applying UML and Patterns - Craig Larman Building J2EE Applications with the Rational Unified Process Peter Eeles, Kelli Houston, Wojtek Kozaczymski Applied Java Patterns - Steven Stelting, and Olav Maasen EJB Design Patterns - Floyd Marinescu J2EE Web Services Design Patterns - Richard Katz 71

Thank You
Nandan Dasgupta