Data Development using RUP

1
Data Development Using Rational Unified Process
Nandan Dasgupta Wells Fargo nandan.dasgupta_at_wellsf
argo.com
TCOUG Thursday April 21st, 2005
2

• Agenda
• RUP Overview
• Object Oriented Development Approach
• Building Data Model
• Use cases in Development
• Data Model and Comparison to Object Model
• Data Development Activities - RUP Phases

3
RUP Overview

• What is RUP?
• RUP Overview
• RUP Characteristics (1/2)
• RUP Characteristics (2/2)

4
What is RUP?
5
RUP Overview

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

6
RUP Characteristics (1/ 2)

• Use case Driven - Build the system based on how
  it will be used
• Iterative Process - Increase understanding of
  the problem through successive refinements and
  multiple cycles
• Create and maintain models rather than paper
  documents
• Focus on the early development and baselining of
  Application and Data Architecture

7
RUP Characteristics (2/ 2)

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

8
Object Oriented Development Approach

• Object Oriented Approach Development (1/ 2)
• Object Oriented Approach Development (2/ 2)
• Why Use cases?
• Typical OO Data Development
• Why Iterations?
• General Application Architecture Layout

9
Object Oriented Approach - Development (1/ 2)

• Based on concepts of Encapsulation and
  Extensibility
• Encapsulates in an object some data and programs
  to operate on the data
• Data is state of the Object
• Code is the behavior of the Object
• Requires the invocation of the behavior of an
  Object via message passing to the Object through
  the interface defined for the behavior of the
  Object

10
Object Oriented Approach - Development (2/ 2)

• Extensibility refers to the ability to extend an
  existing system without introducing changes
• Behavioral extension
• Including additional programs
• Inheritance
• Reuse- Attributes defined for an object may be
  reused in the definition of more specialized
  Objects

11
Why Use cases ?
Many distractions v.s. How to USE the
application to do my Job
12
Typical OO Data Development
Legacy Database
data profiling investigations, analysis of source
Change Capture
Changes (staging)
E/R data model
mapping source to target
ETI Apply
Interactive Database
object model
data requirements
Web Application
use case requirements
Use case Info Flow
Physical Flow
13
WHY ITERATIONS ?
If you deliver a new database application
system, this changes the requirements
Wicked problem see http/www.poppendieck.com/wicke
d.htm
14
General Application Architecture Layout
15
Building Data Model

• Data Model
• Data Tasks (Model Driven) (1/ 2)
• Data Tasks (Model Driven) (2/ 2)

16
Data Model
Data Model is a Business View of how Data
is organized within an Enterprise
17
Data Tasks (Model Driven) (1/ 2)

• Understand the users requirements
• Analyze the requirements and construct Analysis
  Model (conceptual model)
• Perform Data Analysis
• Identify Entities and Relationships between
  Entities
• Identify Keys and Attributes of each Entity
• Build Logical Model

18
Data Tasks (Model Driven) (2/ 2)

• Perform Design and Build Object Model
• Conduct Data Profiling (against Data Source)
• Identify Keys and Attributes of each Entity
• Build Physical Data Model
• Implement Physical Data Model in the selected
  DBMS
• Develop Mapping Document
• Extract Data
• Load Data

19
Use Cases in
Development

• Use cases
• When are Use cases done
• Use case Driven
• Use case to Analysis (1/ 3)

• Use case to Analysis (2/ 3)
• Use case to Analysis (3/ 3)
• Use case to Design (1/ 2)
• Use case to Design (2/ 2)

20
Use cases
A sequence of transactions that a system
performs, yielding an observable result of value
to someone or something outside the system that
interacts with the system.

• A system is described by a finite set of Use
  cases and Supplementary specifications
• Is a part of the system
• Use case (s) describes transactions offered by a
  system
• Represents what the system must provide, rather
  than how
• How the system will provide a service is
  unimportant to the user

21
When are Use cases done

• Use cases and Actors are identified and briefly
  outlined during the early Inception Phase
• Identified architecturally significant Use cases
  are described in detail during the Elaboration
  Phase
• They are further enhanced/ edited during
  Construction Phase

22
Use case Driven
Product development is Use case driven

• Capture the users needs (requirements - in
  users context)
• - Helps in Project Scheduling
• Analyse to specify the needs
• Design to realize the needs
• Implement to implement the needs
• Test to verify the needs

23
Use case to Analysis (1/ 3)

• Include at least one boundary class per Use
  case/ Actor pair

• Entity Class - Key abstractions of a Use case

24
Use case to Analysis (2/ 3)

• Include one Control Class per Use case

25
Use case to Analysis (3/ 3)

• Identify Analysis Classes for Basic and
  Alternate flows
• Assign responsibilities to Classes
• Build Interactions Diagrams

26
Use case to Design (1/ 2)

• 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
• - Using
• -- Class Diagrams
• and
• -- Interaction Diagrams

• Design can be divided into two segments
• Architectural design
• Implementation Design

27
Use case to Design (2/ 2)
28
Data Model
Comparison to Object Model

• Data Model Concepts (1/ 4)
• Data Model Concepts (2/ 4)
• Data Model Concepts (3/ 4)
• Data Model Concepts (4/ 4)

• Data Design Overview
• Data Model - Components
• Object Model - Components
• Comparison Data Model to Object Model

29
Data Model Concepts (1/ 4)
Data Models are built to map Business Concepts
into Relational Object.
What is a Model? Models allow to Plan and flush
out true way to store Data

• Highlights important facts
• Promotes understanding of the whole

Why Model Data?

• Better match to requirements happier users,
  less maintenance
• More understandable solutions more
  utilization, less maintenance
• Fewer construction errors less debugging, less
  maintenance
• More system flexibility less maintenance
• Greater reusability of ideas less maintenance

What are the kinds of Data Models?

• Data models are usually categorized by levels of
  abstraction
• Conceptual
• Logical
• Physical

30
Data Model Concepts (2/ 4)
Conceptual Data Model
A Conceptual Data Model represents the overall
logical structure of a database, which is
independent of any software or data storage
structure. It gives a formal representation of
the data needed to run an enterprise or a
business activity. A Conceptual Data Model shows
data through business eyes.

• It suppresses technical details to emphasize
• All entities which have business meaning
• Important relationships (including many-to-many)
• A few significant attributes in the entities
• A few identifiers or candidate keys

Customer Logins
Contains
Entry of Cards
PINs
Respondent
Contains
Other Financial Customers
31
Data Model Concepts (3/ 4)
Logical Data Model
A Logical Data Model is a graphical
representation of the information requirements of
a business area.

• Replaces many-to-many relationships with
  associative entities
• Defines a full population of entity attributes
• Establishes entity identifiers
• Has no specifics for any RDBMS or configuration

Contains
Customer Logins
PIN
Case
PINs
Entry of Cards
Respondent
PIN
PIN
Other Financial Customers
Contains
PIN
32
Data Model Concepts (4/ 4)
Physical Data Model
A Physical Data Model specifies the physical
implementation of the database. It details the
actual physical implementation. It takes into
account both software or data storage structures.
A Physical Data Model is a database design for

• One DBMS product
• One site configuration

A Physical Data Model may include

• Referential integrity
• Indexes
• Views
• Alternate keys and other constraints
• Tablespaces and physical storage objects

33
Data Design Overview
34
Data Model - Components

• Data Model is composed of
• Entities
• Relations

Contains
Customer Logins
PIN
Case
PINs
Entry of Cards
Respondent
PIN
PIN
Other Financial Customers
Contains
PIN
35
Object Model - Components

• Object Model is composed of
• Classes (attributes)
• Associations

36
Comparison Data Model to Object Model

• Object Model
• Focus is behavior
• Better suited to handle state-specific behavior
  where data is secondary
• Hide data (encapsulation)

• Data Model
• Focus is on Data
• Better suited for ad-hoc relationships and
  reporting application
• Expose Data (Column values)

37
Data Development Activities - RUP
Phases

• Inception Phase
• Elaboration Phase (1/ 3)
• Elaboration Phase (2/ 3)

• Elaboration Phase (3/ 3)
• Construction Phase
• Transition Phase

• Overview

38
Inception Phase Project Initiation
Inception Phase Milestone Define the Problem,
Scope the Architecture, and Initiate the Project.

• Are the Business Analysts interacting with Data
  Analysts and Modelers on the Use cases and on
  Supplementary Specifications ?
• Do the Data Analysts understand the Use cases
  and Supplementary Specifications ?
• Are the Data Analysts part of Iterative Cycle of
  Inception Phase ?

39
Elaboration Phase (1/ 3) Requirements
Elaboration Phase Milestone Detailed analysis of
the problem resulting in the definition of an
architectural foundation for the project.

• Are the Business Analysts interacting with Data
  Analysts, Data Modelers on the Use cases and on
  Supplementary Specifications ?
• Do the Data Analysts understand the Use cases
  and Supplementary Specifications ?
• Are the Data Analysts part of Iterative Cycle of
  Elaboration Phase ?

40
Elaboration Phase (2/ 3) Analysis

• Has the Data Requirements being determined ?
• Identifying Data Elements
• Identifying Data Properties (Retention,
  Availability, Security, ..)
• Has the Data Sources being determined ?
• Comparing Target Data to Source Data
• Determine if any Data Transformation needed
• Did a first Logical Data Model got generated ?
• Has the Data Elements got mapped to Data
  Requirements and Business Requirements ?
• Did a high level estimate of Data needs got
  computed ?
• Is the Data Analysts is part of Iterative Cycle
  of Elaboration Phase ?
• Did they got apprised of changing requirements/
  scope

41
Elaboration Phase (3/ 3) Design

• Did a review of the Object Model take place
  between the Object Modeler and the Data Modeler ?
• Has the Final Logical Model generated ?
• Did a map of Object Model to Logical Data Model
  generated ?
• Has a Data Gap Analysis been performed ?
• Did the First Physical Data Model generated ?
• Has the conceptual design for Extract ,
  Transformation, and Load created ?
• Are the Data Analysts, Logical Data Modeler,
  Physical Data Modeler, and ETL Team is part of
  Iterative Cycle of Elaboration Phase ?
• Were they notified of changing requirements/
  scope ?

42
Construction Phase Implementation (Build)
Construction Phase Milestone Detailed design and
construction of source code.

• Has the schema built by the Database
  Administrator ?
• Has the Backup and Recovery Infrastructure
  assessed ?
• Did the Application Testers generate the Test
  Plan and Test cases ?
• Has the Physical Data Model implemented in the
  selected DBMS ?
• Has the ETL schedule created ?
• Are the Data Analysts, Logical Data Modeler,
  Physical Data Modeler, and ETL Team is part of
  Iterative Cycle of Construction Phase ?
• Were they notified of changing requirements/
  scope ?

43
Transition Phase Deployment
Transition Phase Milestone Delivery of the
system to the user community.

• Has the Loading of Data initiated ?
• Has the testing of data been initiated ?
• Did the application testing got initiated
• Are the Data Analysts, Logical Data Modeler,
  Physical Data Modeler, and ETL Team is part of
  Iterative Cycle of Transition Phase ?
• Were they notified of changing requirements/
  scope ?

44
Overview
Views
45
Data DevelopmentUsingRUPQ A
46
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
• Professional Java Data - Thomas Bishop, ...
• Object-Oriented Modeling and Design for Database
  Application - M. Blaha, and W. Premerlani
• UML for Data Design - Eric J. Naiburg, Robert
  A. Maksimchuk
• The Data Model Resource Book, Volume 1 2 - Len
  Silverston

47
Data Development Using
RUP
Please forward your valued comments to TCOUG.

• Thank You