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

AM28 PowerDesigner, UML and Enterprise Java Bean (EJB) Generation • David Dichmann • PowerDesigner Product Manager • IAD • dichman@sybase.com

PowerDesigner, UML and (EJB) Enterprise Java Bean Generation • Day One: • Module 1 - Overview of UML • Module 2 - Use Case Diagrams • Module 3 - Sequence Diagrams

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

PowerDesigner, UML and (EJB) Enterprise Java Bean Generation • Module 2 - Use Case Diagrams

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

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

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)

Use Case Diagram - Elements • Use Case Diagrams are: • Actors • Use Cases • Relationships • Generalization • Association • Dependencies • <<include>> and <<extend>>

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

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 • Package::Name • Package is Optional • This is the Place Order use case, found as part of the Order package

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: • <<extend>> - Use case will refine base use case • <<include>> - Use case incorporates base use case

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

Use Case Diagram - Association • Associations are the only link from an Actor to a Use Case • Describes the Actor’s interaction with the Use Case and the System • A Corporate Customer will Place Corporate Order

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 << >> to qualify the dependency • Extension Points shown textually - Describes when the extension is used

Use Case Diagram - Sample • Use Case for a Corporate Customer placing an Order

PowerDesigner, UML and (EJB) Enterprise Java Bean Generation • Module 3 - Sequence Diagrams

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

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

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

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

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 • :Sales::Customer is also anonymous, includes the package containing the definition for Customer

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

Sequence Diagram - Messages • Create: • Message creates object and begins it’s lifeline: • Destroy: • Message sends a signal telling the object to destroy itself (Free Resources) and ends it’s lifeline:

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 it’s lifeline • Message lines are drawn from Lifeline to Lifeline • An Object may send a message that destroys another Object, ending it’s lifeline

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 it’s state at any time • Persistent: • An object that exists beyond the end of the sequence MAY be persistent • We may consider storing it’s state • It might still be destroyed elsewhere...

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

PowerDesigner, UML and (EJB) Enterprise Java Bean Generation • Module 4 - Class Diagrams

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.

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

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: <<persistent>> - State is preserved

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

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)

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)

Classes in UML: Class Diagram - Classes • 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 application’s static structures

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

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 member’s name with get and set as a prefix getAttr1(); setAttr1(“Value to set”);

Java Implementation: Class Diagram - Classes and Java • ///////////////////////////////////////////// • // 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; • }

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

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

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

Interfaces with Java Implementation: Class Diagram - Interfaces & Java 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; }

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

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)

Generalizations with Java Implementation: Class Diagram - Generalizations and Java ///////////////////////////////////////////// // 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; }

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

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

Associations with Java Implementation: Generated Code: Class Diagram - Relationships and Java ///////////////////////////////////////////// // 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; }

A Class Diagram for a Simple Order Entry System Class Diagram - Sample

PowerDesigner, UML and (EJB) Enterprise Java Bean Generation • Module 5 - Object Modeling • with PowerDesigner 7.5

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 The PowerDesigner Object Model

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