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

Test1

Test3

Test2

Implemented by Use cases Realized by

Design1

Test

Specified by

Design2 Design4 Design3

Implementation

Analysis

Design
3

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

Software

Risks

System Development Overview

Needs

Vision feeds Requirements drive Architecture

Features

Vision Document

Software Requirements

Actor

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

Use Case Model

Use Case Use Case Supplementary Specifications

Use case Analysis analysis, decision, definition

Develop

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)

Design

blueprint
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

E V A L U A T I O N
6

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

8

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

Application
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

10

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

11

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

12

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

13

Model-Driven Design: Components

Knowledge crunching
Communication and the Use of Ubiquitous

Language Binding Model and Implementation

14

Knowledge Crunching

Design together with domain experts

Continuous learning Knowledge-Rich Design Deep Models

15

Communication and Use of Language

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

16

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

17

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
18

Design Building Blocks (cont.)

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

19

Design Building Blocks (cont.)

Entities
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

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

existing domain objects Low level technical details must hidden from client

20

RUP J2EE
21

RUP - J2EE

Design Build

22

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

23

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

24

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

26

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

27

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

Validate PIN

Failed Logins

Customer

Card Login

Card Entry

Customer Logins

Other Financial Customers

28

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

29

Design Patterns
30

What is a pattern?
Patterns
Problem/ Solution pairs in context

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

Interface reuse

31

Common Design Patterns

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

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

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

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.

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

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

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

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

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.

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

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

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

36

Integrating Design Patterns for Designing an Application Framework

37

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

38

Presentation Tier Patterns

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

39

Front Controller Pattern

Context
Web application with complex navigation

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

Solution
Use of a Controller to handle all web requests

The controller works with a Dispatcher that handles navigation

40

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

41

Service to Worker Pattern

Context
Web application
Views are generated automatically from templates

Problem
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

Solution
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

43

Business Tier Patterns

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

44

Business Delegate Pattern

Context
Application where the business APIs are completely exposed to clients

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

Solution
Use of a Business Delegate to hide Implementation Detail
45

Client

Business Delegate Pattern (cont.)

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

BusinessService

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

46

Session Faade Pattern

Session Bean provides unified approach
Faade hides Entity Bean Details

47

Integration Tier Patterns

Data Access Object
Service Activator User Workflow Integrator

48

Data Access Object

Business Object inherits accesses DataAcces sObject inherits

inherits

Oracle DAO

DB2DAO

Sybase DAO

adapts

adapts

adapts

Oracle Database

DB2 Database

Sybase 49 Database

Value Object

Remote, coarse-grained access

EJB Object

Web Component

<<instantiates>>

Local, fine-grained access

Value Object

50

Detail the Design (Elaboration and Construction)

51

Design
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)
52

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

54

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

55

Modeling EJBs in the UML (External View Example)

Home Interface <<EJBEntityHomeInterface>> AccountHome

<<instantiate>>

Remote Interface

<<EJBRemoteInterface>> Account

56

Modeling EJBs in the UML (Internal View Example)

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

<<instantiate>> <<EJBRealizeHome>>

<<EJBEntityHomeInterface>> AccountHome

<<EJBPrimaryKey>>

<<EJBPrimaryKey>> AccountKey

57

Design Component (Construction)

58

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

Scheduler

Planner

59

Component
Component:
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>>
60

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

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

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

64

Design the Distribution (Construction)

65

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.

66

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

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

68

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
Text

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

<<Web Browser>> IE 5.5

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

<<Enterprise Application>> JDG.ear

<<database>> 69 Login:ODS

Q&A
70

Bibliography
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 nandan.dasgupta@wellsfargo.com

72