AM28 PowerDesigner, UML and Enterprise Java Bean (EJB) Generation

1

AM28 PowerDesigner, UML and Enterprise Java Bean
(EJB) Generation
David Dichmann PowerDesigner Product
Manager IAD dichman_at_sybase.com
2
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Day One
• Module 1 - Overview of UML
• Module 2 - Use Case Diagrams
• Module 3 - Sequence Diagrams

3
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Day Two
• Module 4 - Class Diagrams
• Module 5 - Object Modeling with PowerDesigner 7.5
• Module 6 - Persistence Modeling
• Module 7 - PowerDesigner 7.5 for
  Object/Relational Modeling
• Module 8 - Enterprise Java Bean (EJB) Generation
  with PowerDesigner 7.5
• Module 9 - A Process for Application Design

4
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Module 2 - Use Case Diagrams

5
Use Case Diagrams

• Capture the intended behavior of a system
• Independent of Implementation Details
• Analysis - Level view of the Application

6
Use Case Diagram - Purpose

• Model System Context
• Identifies what elements are external to the
  system/application and what are internal
• Defines Scope
• Communicate System Requirements
• What the system is responsible for doing
• Communication to users of the System
• Visually communicates
• How the system satisfies Business Rules
• How the system satisfies User Requirements

7
Use Case Diagram - Purpose

• Assist Analysis and Testing
• Validation (Analysis)
• Up front in lifecycle process
• Ensure that the system does what the user wants
  (validate user requirements)
• Verification (Test)
• When development is complete
• Ensure that the system operates the way the spec
  says (verify functional requirements)

8
Use Case Diagram - Elements

• Use Case Diagrams are
• Actors
• Use Cases
• Relationships
• Generalization
• Association
• Dependencies
• ltltincludegtgt and ltltextendgtgt

9
Use Case Diagram - Actors

• Role played by an object interacting with a
  system
• Human User, Hardware Component, External System

• Symbol is a Stick Figure
• Name appears beneath

10
Use Case Diagram - Use Cases

• Specifies functionality as seen by the Actor/User
• Describes behavior for the system

• Symbol is an Elipse
• Name appears inside
• PackageName
• Package is Optional
• This is the Place Order use case, found as part
  of the Order package

11
Use Case Diagram - Relationships

• Describe how Actors and Use Cases relate
• Main Flow Ordinary interaction with the System
• Exceptional Flow Exception handling (Ex
  Cancel button is pressed)
• Come in Three forms
• Generalization - Inheritance
• Association - Relate Actors to Use Cases
• Dependency - May be stereotyped as
• ltltextendgtgt - Use case will refine base use case
• ltltincludegtgt - Use case incorporates base use case

12
Use Case Diagram - Generalization

• You may create a specialized Actor or Use Case
  from a Base Object

• Symbol is a hollow arrow
• A corporate customer is a customer

• Placing a corporate order is a specialized
  version of placing an order

13
Use Case Diagram - Association

• Associations are the only link from an Actor to a
  Use Case
• Describes the Actors interaction with the Use
  Case and the System

• A Corporate Customer will Place Corporate Order

14
Use Case Diagram - Relationships

• One Use Case may be Dependent on Another
• Describes relationships between the Use Cases in
  the system or application

• Symbol is a Dashed-Line Arrow
• Stereotype appears in ltlt gtgt to qualify the
  dependency
• Extension Points shown textually - Describes when
  the extension is used

15
Use Case Diagram - Sample

• Use Case for a Corporate Customer placing an Order

16
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Module 3 - Sequence Diagrams

17
Sequence Diagram - A UML Interaction Diagram

• Describes how objects interact with each other
• Describes the timing and ordering of messages
• Represents the flow of control over time
• More detailed than Use Case
• Implementation independent

18
Sequence Diagram - Purpose

• Model the dynamics of
• Systems or subsystems
• A Class operation
• A Use Case
• Communicate System Behavior
• What the objects are expected to do
• How they are expected to communicate and react to
  each other
• Bring Use Cases closer to Design

19
Sequence Diagram - Elements

• Sequence Diagrams are
• Objects
• Messages - four types
• Synchronous (Call) - must receive a Return
• Return - Returns control to Synchronous
• Flat - No return required, new threads allowed
• Asynchronous - No return required, continue in
  current thread
• Lifeline with Focus of Control blocks

20
Sequence Diagram - Objects

• An Object
• Describes an Instance (Manifestation) of an
  Abstraction (Class)
• Exists within the context of a system, operation
  or transaction
• May be persistent - State saved after context
  expires

21
Sequence Diagram - Objects

• Different Elements of the Object Symbol

• c is an instance of Customer
• c represents the instance with a name attribute
  set as shown
• Customer is an anonymous instance - Generic
• SalesCustomer is also anonymous, includes the
  package containing the definition for Customer

22
Sequence Diagram - Messages

• Messages between Objects
• Message line distinctions are optional

• Synchronous (Call) - Solid line and arrowhead
• Return - Dashed line, open arrowhead
• Flat - Solid line, open arrowhead
• Asynchronous - Solid line, half arrowhead

23
Sequence Diagram - Messages

• Create
• Message creates object and begins its lifeline

• Destroy
• Message sends a signal telling the object to
  destroy itself (Free Resources) and ends its
  lifeline

24
Sequence Diagram - Lifeline

• Describes the existence of the object relative to
  other objects in the Sequence

• Lifelines may be infinite
• Object may create another, starting its lifeline
• Message lines are drawn from Lifeline to Lifeline
• An Object may send a message that destroys
  another Object, ending its lifeline

25
Sequence Diagram - Lifeline

• Lifelines give us a clue to Object Persistence
• Transient
• An Object that is created and destroyed in a
  Sequence is most likely a transient object
• We do not consider storing its state at any time
• Persistent
• An object that exists beyond the end of the
  sequence MAY be persistent
• We may consider storing its state
• It might still be destroyed elsewhere...

26
Sequence Diagram - Sample

• Sequence Diagram for a Customer Placing an Order.
  The order is shipped with a WayBill

27
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Module 4 - Class Diagrams

28
Class Diagrams

• Static structure of classes and their
  relationships within a system
• Links conceptual representation to actual code
• A class can be directly implemented in an O-O
  programming language like
• Java
• PowerBuilder
• XML (DTD, Schema, Data (BizTalk)
• etc.

29
Class Diagrams - Purpose

• Model the static Design of the system
• Classes, Interfaces, Components
• Implementation Dependent - Design
• Visually describe the Code
• Diagram shows the code in an abstract visual
  manner
• Understand and document the elements of a System
• Code Reuse
• Show how elements from another package are reused
  in the current application/package
• Abstract visualization of code shows reusable
  objects

30
Class Diagram - Elements

• Classes
• attributes, operations, constructors, accessors
• Abstract classes and Interfaces
• Relationships
• dependencies, generalizations/specializations,
  associations, realizations
• Stereotypes
• Describe extensions to UML
• Further classify or define objects
• Example ltltpersistentgtgt - State is preserved

31
Class Diagram - Classes

• Classes
• A class is a type definition
• class MyFirstClass
• A class contains Data Members and Methods
• You don't actually operate on classes. You
  create instances (objects) from those classes and
  then call the class fields (i.e. Data Members and
  Methods) in those objects

32
Class Diagram - Classes

• Classes vs. Objects
• An object is an instance of a class
• New objects must first be declared
• Object are created (instantiated) from a class
• Example In Java, you use the new operator
  (which calls a Class Constructor)

33
Class Diagram - Classes

• Class Attributes (Data Members)
• Data members make up the information (attributes)
  of a class
• Visibility (public, private, protected, package)
• Class Operations (Methods)
• Methods perform tasks on Data Members
• Methods cannot exist outside of a class
• Visibility (public, private, protected, package)

34
Class Diagram - Classes

• Classes in UML

• Class Name at the top
• Attributes in the top half
• Operations in the Lower Half
• () and (-) indicate visibility, public and
  private respectively

• Classes are an abstract representation of the
  applications static structures

35
Classes - Constructors

• Constructors
• Special-purpose methods that have the same name
  as the class, with no return type
• The instance of the class is the return type
• Allocate object resources and return an instance
  of the class
• Destructors
• De-allocate the resources that the Constructor
  allocated
• For many modern languages, this is taken care of
  by automatic garbage collection

36
Classes - Accessor Methods

• Accessor methods
• Provide a public interface to the class
• Keep the actual data storage private to that
  class
• You can change the data representation in the
  class without changing the methods that set those
  values
• Come in pairs
• Get and Set and conventionally use the private
  data members name with get and set as a prefix
• getAttr1()
• setAttr1(Value to set)

37
Class Diagram - Classes and Java

• Java Implementation

///////////////////////////////////////////// //
This file was generated by PowerDesigner /////////
//////////////////////////////////// public
class Item public int getItemNumber ()
return itemNumber public String
getItemName () return itemName
public double getItemPrice ()
return itemPrice public Order
hasManyItems private int itemNumber
private String itemName private double
itemPrice
38
Class Diagram - Abstract Classes

• An abstract class
• Can include data members and methods
• Cannot be instantiated, i.e., there is no
  implementation for the methods within that class
• Classes that extend (inherit from) an abstract
  class must provide method implementation

39
Class Diagram - Interfaces

• An interface is
• Similar to an abstract class except
• It does not include code,
• Only method signatures
• Static final data members aka named constants.
• An interface only outlines method behavior
• Classes using an interface must implement all the
  methods declared in that interface

40
Class Diagram - Interfaces

• Realizations
• Realizations are semantic relationships between
  classes whereby one class must realize what the
  other class defines
• Realizations are found between an Interface and
  the class that realizes it
• Realizations are rendered by a dotted, directed
  line (empty arrowhead) pointing toward the class
  to be realized

41
Class Diagram - Interfaces Java

• Interfaces with Java Implementation

public interface Peripheral abstract void
registerPeriph () abstract void testPort ()
abstract void testPwSupply () abstract void
testMotherBd ()
public class parallelPeripheral implements
Peripheral public void registerPeriph ()
public void testPort ()
public void testPwSupply ()
public void testMotherBd ()
private String periphId private String
periphCodeName private String vendorName
42
Class Diagram - Relationships

• Dependencies
• Dashed, directed line (arrow) pointing toward the
  entity being depended on
• Relationship that states that a change in the
  entity pointed to may affect another entity that
  uses it

43
Class Diagram - Relationships

• Generalizations / Specializations
• Solid, directed line (empty arrowhead) pointing
  toward a supertype
• Is-A relationship between a subtype and a
  supertype (e.g., Customer Is-A Person, where a
  Customer is generalized as a Person and a Person
  is specialized as a Customer)

44
Class Diagram - Generalizations and Java

• Generalizations with Java Implementation

///////////////////////////////////////////// //
This file was generated by PowerDesigner /////////
//////////////////////////////////// public
class Customer protected int customerCode
protected double creditStatus protected
double telNumber
///////////////////////////////////////////// //
This file was generated by PowerDesigner /////////
//////////////////////////////////// public
class Corporation extends Customer private
String companyName private String
contactName private double contactTelNumber

45
Class Diagram - Relationships

• Associations
• Associations are structural relationships that
  specify that a class is associated to another
  class (both at the same level)
• Associations have names, roles, and multiplicity
• Associations are assumed to be bi-directional by
  default
• Associations are made unidirectional using
  navigability

46
Class Diagram - Relationships

• Association Variations
• Aggregations (Hollow Triangle)
• Containment (Has-A) relationships
• One class is the Whole, the other one is a Part
• Compositions (Filled Triangle)
• Particular form of aggregation
• A part depends on the whole for its existence
• If the whole is deleted the parts are also deleted

47
Class Diagram - Relationships and Java

• Associations with Java Implementation
• Generated Code

///////////////////////////////////////////// //
This file was generated by PowerDesigner /////////
//////////////////////////////////// public
class Address public Customer has
private int addCode private String street1
private String street2 private String city
private String zipCode
48
Class Diagram - Sample

• A Class Diagram for a Simple Order Entry System

49
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Module 5 - Object Modeling
• with PowerDesigner 7.5

50
The PowerDesigner Object Model

• The PowerDesigner Object Model (OOM) uses the UML
  Class Diagram
• Classes and Interfaces
• Attributes and Operations
• Associations and Generalizations (Realizes)
• Packages
• An OOM targeting Java
• Java aware (Multiple Inheritance, etc.)
• Generates .java files from model definitions

51
Target Languages

• PowerDesigner OOM may represent implementations
  for
• Java
• PowerBuilder
• XML (DTD, Schema, and Data (BizTalk)
• There is another language target that is
  essentially syntax independent
• Analysis

52
PowerDesigners Object Model

• PowerDesigners Model Interface

53
PowerDesigners Object Model

• The Object Model in PowerDesigner

54
Generalizations in PowerDesigner

• PowerDesigner knows what is Inherited

55
Interfaces in PowerDesigner

• Interface operations to be Implemented

56
Generating Objects

• Operation Implementation Editor
• Add, edit or view Implementation Code right in
  the PowerDesigner OOM
• Code Preview
• Preview the code that will be generated for the
  entire class
• Takes into account relationships, inheritances,
  implementation code, etc.

57
Generating Java Code

• Generate Java Code
• Options control location and format of generated
  files
• Use the Package structure defined in the Model
• External Shortcuts do not generate code
• The shortcut may be to a Library object - the
  Class will already exist
• The shortcut may be to another application or
  project - the Class is outside the scope of the
  model
• If you own both models, generate code from both

58
Generating PowerBuilder Code

• Generate PowerBuilder Code
• Options allow generation directly to a .pbl via
  ORCA interface, or to a .sru file for import
  later
• External Shortcuts do not generate code
• The shortcut may be to a Library object - the
  Class will already exist
• The shortcut may be to another application or
  project - the Class is outside the scope of the
  model
• If you own both models, generate code from both

59
Reverse Engineering Java Code

• Recover Java code
• Reverse engineer from a .java or .class file
• Select from individual files, a directory or an
  archive
• PowerDesigner can create a new OOM or extend an
  existing one
• Understand existing Java applications
• Capture a library for reference in other models
• Synchronize a model with externally edited code
• Incorporate new objects into an existing design

60
Reverse Engineering PB Code

• Recover PowerBuilder Business Logic
• Reverse engineer from a .pbl or .sru file
• Custom Class
• Standard Class
• Custom Visual
• External Visual
• Standard Visual
• Shortcuts to the PCF Library Models
• PowerDesigner has PFC definitions as OOMs
• Create references if objects inherit from the PFC

61
Reverse Engineering PB Code

• PowerDesigner can create a new OOM or extend an
  existing one
• Understand existing PowerBuilder applications
• Capture a library for reference in other models
• Synchronize a model with externally edited code
• Incorporate new objects into an existing design

62
Iterative Round Trip Engineering

• Build and test as the Design matures
• Create an OOM
• Generate Application code and edit in an IDE
• Reverse engineer edits into the Model
• Synchronize with the model
• Modify the Model
• Changes to the model can be done in parallel with
  developer work outside PowerDesigner
• Generate new Model to code
• Synchronize prevents loss of developers work

63
Changing Target Language

• PowerDesigner can help move from one Object
  Language to Another
• May be useful to change business logic from one
  implementation language to another
• Code in Implementation Fields will remain in the
  original language
• PowerDesigner is not a syntax converter
• Helps keep design consistent between languages

64
Customizing the Language

• You may customize PowerDesigners Implementation
• Definition files for each language (Java,
  PowerBuilder)
• Stored in the PowerDesigner directory as a .XOL
  file (Object Language Definition file)
• Changes to this resource file control how
  PowerDesigner understands the language

65
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Module 6 - Persistence Modeling

66
Overview of Data Modeling

• Why Model the Data?
• Object-Oriented applications contain Persistent
  objects, we need to store their state somehow
• Flat Files OK for small amounts of Data
• Database Systems are more common for larger sets
  of data, more complex structures
• Databases are Relational
• Efficient and Performant storage and recovery
• UML is NOT relational
• We need a relational model to properly document
  the RDBMS implementation of persistent objects

67
Conceptual Data Models

• Conceptual Data Models (CDM)
• Implementation independent view of a database
• Entities, attributes and relationships in 3rd
  Normal Form
• Driven by Analysis of the application Domain,
  Business Rules, and expected behavior
• UML can be used to describe a Conceptual Data
  Model
• UML is a superset of Conceptual Data Modeling
• A pure CDM may still be interesting

68
Conceptual Data Models - Sample

• A Conceptual Model for an Order Entry System

69
Physical Data Models

• Physical Data Models (PDM)
• The UML is not sufficient to describe a Physical
  Database Implementation
• Describe data in terms of a specific RDBMS
  implementation
• Foreign Keys (folding?)
• Indexes, Physical Storage Options, Table
  Ownership, Stored Procedures
• Can be derived from a CDM or UML Class Diagram
• ltltpersistentgtgt classes map to Tables in the PDM

70
Physical Data Models

• Objects and Tables
• Do not always map 11
• Physical storage considers RDBMS performance
• Objects in Memory consider Application
  Performance
• Object/Relational Mapping
• Documents the relationships between a Class and
  its Table(s) in the database
• Drives save/load logic for managing object
  persistence

71
Physical Data Models - Sample

• A Physical Model for an Order Entry System

72
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Module 7 - PowerDesigner 7.5 for
  Object/Relational Modeling

73
UML and Database Design

• UML can be seen as a very large superset of ER
• Anything that can be done in ER can be done (even
  better) in UML and more!
• UML classes can be persisted in database tables
  at design time through object / relational
  mapping
• User-defined, complex data types (class instances)

74
UML and Database Design

• Relational models can be recovered in UML class
  diagrams to jumpstart object-oriented design
• UML classes can be used in the database
• Java stored procedures (static classes)
• User-defined, complex data types (class instances)

75
Persistence Mapping (RDBMS)

• PowerDesigner also models RDBMS
• PowerDesigner is also a very powerful Relational
  modeling tool
• Bi-level Database Design
• PowerDesigner Physical Data Model (PDM)
• Database Specific Generates DDL
• PowerDesigner Conceptual Data Model (CDM)
• Normalized, Implementation (RDBMS) independent

76
Persistence Mapping (RDBMS)

• Object/Relational Mapping
• UML Class Diagrams contain Entity/Relationship
  metadata as well
• Using identifiers, navigability, cardinality, we
  can derive a Physical structure for persistent
  objects
• PowerDesigner knows which classes are persistent,
  knows the cardinality, etc. and will generate a
  CDM or PDM for the persistent objects

77
Persistence Mapping (RDBMS)

• Use PowerDesigner to model the Applications
  Logic and Persistence
• Using the OOM Generate a PDM for your RDBMS
• Denormalize the PDM, add physical objects
• Triggers, Procedures, Views, Physical Options,
  Indexes, etc...
• Generate DDL for the Database (ODBC or Script)
• Iterative
• Changes to the OOM can be generated to the PDM
• The modified PDM can generate DDL and DML to
  modify the database without loosing existing data.

78
Java in the Database (RDBMS)

• Use PowerDesigner to model Java in the Database
• Create OOM for Java Stored Procedures and Java
  Data Types
• Create a PDM for the Database (Target your RDBMS)
• Reuse objects from the OOM in the PDM as Data
  Types
• Generate .java from the OOM to import to server
  to support Data Types and add Stored Procedures

79
Objects from Legacy Systems

• PowerDesigner captures existing database
  structures and translates them to Java
• Reverse engineer the Database to a PDM
• Generate an OOM from the PDM (Java)
• Gives Object Designers a view of existing
  database objects
• Jump-start to building Business Logic (new
  applications) around legacy data stores
• Iterative
• Build, generate and synchronize models as the
  application takes shape

80
PowerDesigner is Object and Relational Modeling

• Object/Relational Mapping
• Single source for Object and Relational Metadata
• Generation and synchronization between Object and
  Data models, improves consistency
• Object Models are UML Class Diagrams - Common
  Language for Application Designers
• Data Models are Relational Diagrams - Understood
  by Data Analysts and DBAs (They are not
  necessarily versant in UML)
• Resolves limitations in UMLs ability to describe
  Physical Data Structures (Implementation)

81
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Module 8 - Enterprise Java Bean (EJB) Generation
  with PowerDesigner 7.5

82
Enterprise Java Beans

• Enterprise Java Beans
• Standard way to build Application Server
  Components using Java
• Part of the Java 2 - Enterprise Edition (J2EE)
  standard
• May be transient (session beans) or Persistent
  (entity beans)

83
Enterprise Java Beans

• Object Model will capture the Java components
• Home Interface
• Remote Interface
• Bean Class
• javax library references
• Data Model will capture the Persistent Storage
• Table(s) to hold Entity Bean state
• Generate and Reverse Engineer into either of
  these two types of Models

84
Enterprise Java Beans

• Process
• Have a Bean, need a Data Model
• Generate PDM from OOM of Bean
• Have a Data Model, need to create a Bean
• Generate an OOM from PDM, create a Bean
• Have nothing, starting from Scratch
• Have an EJB Wizard in my IDE
• Generate the Bean from the Wizard, reverse
  engineer to create an OOM
• Have no Wizard
• Create the OOM and EJB from scratch

85
Enterprise Java Beans

• An EJB model for our Customer Entity Bean

86
Enterprise Java Beans

• Generated Java Code

public class CustomerBean extends Object
implements EntityBean private String name
private String address private long phone
private javax.ejb.EntityContext
_entityContext public void CustomerBean ()
// EJB constructors don't have a server
context. public void setEntityContext
(javax.ejb.EntityContext parm0)
throws java.rmi.RemoteException
this._entityContext parm0 // generated
helper code // method for interface
javax.ejb.EntityBean . . . //Code truncated
for brevity
public interface CUSTOMER extends EJBObject
Remote Interface Home Interface
public interface CustomerHome extends EJBHome
Customer findByPrimaryKey (java.lang.String
primkey) throws
java.rmi.RemoteException,
javax.ejb.FinderException
Entity Bean
87
Enterprise Java Beans

• The Physical Data Model, and DDL

• CUSTOMERBEAN table will hold data about instances
  of the CustomerBean object
• Indexes, Column Names, Data Types

/
/ / Table CUSTOMERBEAN
/ /
/ create table CUSTOMERBEAN
( ENTTCNTX varbinary(255)
not null, CUSTNAME text
null, CUSTADDR text
null, CUSTPHN int
null, constraint
PK_CUSTOMERBEAN primary key (ENTTCNTX) ) go

• Generated DDL will work for a Sybase ASE 12.0
  implementation

88
Enterprise Java Beans

• The PowerDesigner Connection
• Manage the Metadata for all Beans and Java
  Objects
• Manage the RDBMS implementation in PDM
• Generate OOM from PDM, or PDM from OOM
• Single tool for all EJB related metadata
• Enterprise class Repository
• Team development
• Generate and Reverse Engineer
• The EJB Java Code
• The RDBMS structures

89
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Module 9 - A Process for Application Design

90
Language VS. Process

• The UML is a Modeling Language
• Describes Syntax for Object Representation
• Common language for readability and understanding
• A Process describes how and when Modeling is done
• When and how is Analysis performed
• How is Analysis mapped to Design
• What is the workflow when building Applications
• Language Process Method
• The UML is NOT a Method

91
What is the Process?

• Collect information as
• Business Rules
• Domain Objects (Actors/Classes at high level)
• Perform Application Analysis
• Dynamic Analysis with Business Rules
• Use Case Diagrams
• Sequence Diagrams
• Domain Analysis
• Perform Object Design
• Extend Domain Model into Design Level detail

92
What is the Process?

• Implement Application
• Drive code from Design Complete in IDE
• Deploy Application
• Repeat
• Process is iterative
• Rapid Prototyping
• Unit Testing
• Enhancements to functionality
• Etc

93
Weaknesses in the Process

• Assumes new development only
• Lacks consideration for Data Structures
• You will persist objects somewhere RDBMS

94
Start Anywhere, Go Anywhere

• Begin a new Project
• Process is as above
• Have Legacy Data, need New Application
• Data-Driven Process
• Have existing Application and Data (refactoring)
• Refactoring for better design
• Enhancements to existing application, design
  details have been poorly documented or lost
• Synchronize Data Design and Object Design together

95
Start Anywhere, Go Anywhere

• Have existing application, need New Data
  Structures
• Reuse components (Java Classes, EJB), need to
  complete with Persistence Model
• Completed Application development without
  building Data Structures
• Change from Flat File to RDBMS?

96
Have Legacy Data, need New Application

• Capture Data Structures
• Data Model drives Object Model
• Domain Model generated from Physical Data Model
• Perform Business Analysis
• Reuse reverse engineered structures in
• Use Case Diagrams
• Sequence Diagrams
• Refine Domain Model
• Non-persistent analysis objects

97
Have Legacy Data, need New Application

• Perform Application Design
• Refine Domain Model (Class Diagram)
• Maintain Data Awareness
• RDBSM may not be changeable
• Use Physical Data Model as reference
• Implement Application
• Generate Code from Design Model
• Deploy New Application
• Repeat
• Process is Iterative

98
Have existing Application and Data (refactoring)

• Capture Data and Object structures
• Reverse Engineer Object Model
• Reverse Engineer Data Model
• Review Business Analysis (Optional)
• Reuse reverse engineered structures
• New Use Case diagrams
• New Sequence Diagrams
• Validate the Design vs. Requirements

99
Have existing Application and Data (refactoring)

• Update Design
• Update Design via
• Analysis of captured Objects
• Analysis of captured Data Elements
• Results of Business Analysis review
• Implement Application
• Generate new code from Object Model
• Update database through Physical Model
• Implement new Application

100
Have existing Application and Data (refactoring)

• Repeat
• Process is iterative
• May follow any other Process

101
Have existing application, need New Data
Structures

• Find, Extract or Capture Object Structures
• Search Repositories for reusable objects
• Reverse engineer Application/Component
• Review Business Analysis (Optional)
• Reuse Objects in
• New Use Case Diagrams
• New Sequence Diagrams
• Validate Design vs. Requirements
• Perform Database Design
• Object Model drives Data Model
• Denormalize and complete Data Model
• Triggers, Procedures, Views, Indexes

102
Have existing application, need New Data
Structures

• Implement Design
• Generate new database structures
• Generate new Object Structures (if necessary)
• Implement Application
• Repeat
• Process is iterative
• You may follow a different Process

103
PowerDesigner, UML and (EJB) Enterprise Java Bean
Generation

• Summary

104
Summary

• UML is an Object-Oriented Modeling Language
• Describes Objects in Static and Dynamic
  conditions
• Use Case Diagrams
• Describe Business Requirements
• Sequence Diagrams
• Describe Object Interactions over Time
• Class Diagrams
• Describe static structures
• Implementation details - Generate to Code

105
Summary

• Persistence is an important element of
  Application Design
• UML does not address Relational Modeling
• RDBMS most popular way to store an Objects state
  (Data)
• We can model an EJB with Class and Data Models
• Entity Beans needs Persistent Model

106
Summary

• PowerDesigner provides an environment to
• Create Object Models that generate Code
• Create Relational Models for the RDBMS
• Link Object and Relational Models and keep them
  synchronized
• PowerDesigner is Flexible
• Can work with any process
• Understands application development is not always
  a forward flow from Analysis to Implementation