RUP

1
RUP Implementation (Build) Design Patterns
Nandan Dasgupta
OTUG Tuesday August 17, 2004
2
What is RUP?
3
RUP Overview

• Iterative Approach
• Focus on risks - tackle items of highest risk
  first
• Defines roles for team members
• Produces many key artifacts

4
RUP Characteristics

• Use Case Driven - Emphasizing building systems
  based on how system will be used
• Iterative Process - Advocates an increasing
  understanding of the problem through successive
  refinements and multiple cycles
• Emphasizes the creation and maintenance of
  models rather than paper documents
• Focuses on the early development and baselining
  of Software Architecture

5
RUP Characteristics (cont.)

• Use Object Oriented techniques to create models
• Configurable to meet the needs of most projects
• Encourages ongoing quality control and risk
  management

6
RUP Analysis and Design
Analysis The part of the software development
process whose primary purpose is to formulate a
model of the problem domain (Domain - business
objects and real world concepts). Analysis
focuses on what to do.
Design The part of the software development
process whose primary purpose is to decide how
the system will be implemented. During design,
strategic and tactical decisions are made to meet
the required functional and quality requirements
of a system.
Verified by
Implemented by
Realized by
Test
Use cases
Specified by
Implementation
Design
Analysis
7
RUP Implementation
Implementation The implementation view of a
system captures the artifacts as seen by a
systems programmers, and serves to model the
executable components and corresponding source
files and content that form those executable
parts. This view is at the center of a projects
configuration management practice, for it is
these components that are assembled into
executable releases at each iteration.
Verified by
Implemented by
Realized by
Test
Use cases
Specified by
Implementation
Design
Analysis
8
RUP Analysis Design
9
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.

10
Layered Architecture
11
J2EE Architecture
Middle Tier (Domain Logic Layer and Data Layer)
Presentation Tier
Database Tier
Web Tier
Business Tier
12
J2EE Architecture - Sample
13
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.

14
Model-Driven Design Components

• Knowledge crunching
• Communication and the Use of Ubiquitous Language
• Binding Model and Implementation

15
Knowledge Crunching

• Design together with domain experts.
• Continuous learning.
• Knowledge-Rich Design.
• Deep Models.

16
Communication and Use of Language

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

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

18
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
• The interface is defined in terms of other
  elements of the domain model

19
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
• Aggregate Rules
• 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 Façade interface

20
Design Building Blocks (cont.)

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

21
RUP - J2EE
22
RUP - J2EE
23
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

24
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

25
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
• EJB - Enterprise Java Beans - Distributed Java
  Components, Stateless, Stateful, Entity and
  Message Driven

26
Design Patterns
27
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

28
Integrating Design Patterns for Designing an
Application Framework
29
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

30
Presentation Tier Patterns

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

31
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

32
Front Controller Pattern (cont.)
33
Business Tier Patterns

• Business Delegate
• Service Locator
• Session Façade
• Value Object
• Composite Entity
• Value Object Assembler
• Value List Handler

34
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

35
Business Delegate Pattern (cont.)
36
Session Façade Pattern

• Session Bean provides unified approach
• Façade hides Entity Bean Details

37
Integration Tier Patterns

• Data Access Object
• Service Activator
• User Workflow Integrator

38
Data Access Object
39
Value Object
40
J2EE Design Input from Analysis (Elaboration)
41
J2EE Design Input from Analysis (Use case Diagram)
42
J2EE Design Input from Analysis (cont.) (Class
Diagram)
43
J2EE Design Input from Analysis
(cont.) (Sequence Diagram)
44
Detail the Design (Elaboration and Construction)
45
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)
• Implementation Design (Detail the Design)

46
RUP - J2EE Design
47
UML Package to J2EE Components
48
Modeling Java Servlets in UML

• Modeled as ordinary Java Classes
• Use stereotypes to distinguish Servlet types
• ltltHTTP _ Servletgtgt
• ltltGeneric_Servletgtgt

49
Modeling JavaServer Pages in UML

• Modeled as Two Logical Entities
• A ltltServer Pagegtgt is a class stereotype that
  abstracts the Web Pages behavior on the Server
• A ltltClient Pagegtgt abstracts the behavior of a
  Web Page on the Client

50
Modeling EJBs in the UML (External View Example)
51
Modeling EJBs in the UML (Internal View Example)
52
Design Component (Construction)
53
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

54
Component

• Component
• Physical packaging of model elements
• - Source, binary, executable, configuration,
  makefile, IDL bindings, etc.
• - Aggregate of other components
• Standard stereotypes
• - ltltexecutablegtgt - a program that may run on a
  node
• - ltltapplicationgtgt - consists of several
  executables
• - ltltfilegtgt - file containing source code or
  data
• - ltltlibrarygtgt - static or dynamic library
• - ltltdocumentgtgt - a document
• - ltltpagegtgt - HTML page
• - technology specific
• ltltActiveXgtgt, ltltJavaBeangtgt, ltltAppletgtgt, ltltDLLgtgt,
  ltltCORBA Componentgtgt

55
Component
Modelling Elements Components

• Basic
• Class
• Object
• Interface
• Collaboration
• Use-case
• Active Class
• Component
• Node

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 a subsystem of base or composite
elements.

• Composite
• Package

56
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.
57
Use Case to Implementation

• Use Cases are eventually realized as components
  (Code)
• Components of the Implementation

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

59
Design the Distribution (Construction)
60
Deployment Diagram
Deployment diagrams show the configuration of
run-time 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.
61
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.
62
Deployment Diagram

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

63
Deployment Diagram
64
Q A
65
Bibliography

• The Rational Unified Process-An Introduction -
  Philippe Kruchten
• Use Case Modeling - Kurt Bittner, Ian Spence,
  Foreword by Ivar Jaconson
• 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

66
RUP Implementation Design Patterns
Please forward your valued comments to OTUG.

• Thank You

67
Appendix
68
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

69
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

70
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

71
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

72
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