1 / 49

IA330 Best Practices in Object-Oriented Modeling With PowerDesigner

IA330 Best Practices in Object-Oriented Modeling With PowerDesigner. Donald D. Clayton CEO Intertech Consulting, Inc. dclayton@intertech-us.com. Understand the ways modern systems are becoming increasingly complex

chaim
Télécharger la présentation

IA330 Best Practices in Object-Oriented Modeling With PowerDesigner

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. IA330 Best Practices in Object-Oriented Modeling With PowerDesigner Donald D. Clayton CEO Intertech Consulting, Inc. dclayton@intertech-us.com

  2. Understand the ways modern systems are becoming increasingly complex Review the differences between traditional client/server practices and three-tier and distributed computing. Learn practical design techniques for managing complexity Review the history of UML Objectives

  3. Brief History of UML Modern System Development Architectures Two Tier Systems Three Tier Systems Diverse Client Types System Architecture Partitions System Architecture Layers Service Based Architectures Topics

  4. A plethora of modeling approaches threatened to stymie the use of object-oriented systems development The OMG supported a standard notation for object-oriented systems, now called Unified Modeling Language, or UML UML has it’s origins in several Object-Oriented Methodologies Rumbaugh et al. OMT Booch methodology Jacobson's methodologies PowerDesigner OOMs use UML class diagram notation The Unified Modeling Language (UML)

  5. Enterprise systems have increased in sophistication from early days of Client/Server Today’s business systems need to support a variety of client types In this environment, it is not usually possible to “RAD” the application UML gives us the semantics to support these efforts PowerDesigner gives us the tool to support these efforts Modern System Development Architectures

  6. Two-Tier Architectures Database Server Client Vendor / Platform-Specific API • User interface • Some business logic • Data management • Some business logic

  7. Application Server • Business logic • Caching • Transaction management • Data location transparency • Load balancing Multitier (Distributed) Architectures Database Server Client • User interface • Data management

  8. Creating an enterprise system that will support diverse client types with shared business components requires Increased emphasis on analysis and design Increased usage of OO techniques to manage complexity Common Techniques include System Partitioning System Layering Service-based architectures Managing Complexity

  9. Overview System Architecture Partitions System Architecture Layers A Partitioned System Architecture System Architecture Partitions

  10. A design technique for separating your application into “partitions” and “layers” Partitions are logical groupings (categories) of classes Applications are abstracted into three basic types of classes: user interface, problem domain, and system management, or task classes Layering is accomplished using inheritance (generalization), and loose coupling What Is A System Architecture?

  11. System Partitions Problem Domain Partition User Interface Partition System Management Partition

  12. Partitioned classes are more reusable Partitioned classes encapsulate business rules Partitioned classes may be distributed to the middle tier more readily Partitioned classes make it easier to support diverse client types Benefits of Partitioning

  13. System Architecture Layers Layering is accomplished with generalization (inheritance)

  14. The System ArchitectureA Combined Perspective When designing classes, always know the layer you are designing for

  15. Service-based architectures are popular for both PowerBuilder and Java There are two main components Proxy objects are often used to distribute service-based architectures in a distributed computing environment The key concept here is the “Delegation” of behavior, instead of “Encapsulation” of behavior Service-based Architectures

  16. Requesters delegate work to services Services respond to requesters Contain predefined operations to enable services and call services Contain attributes that refer to the service classes Follow the client / server metaphor Service Class Requester and Service Classes Example Requester Class

  17. Service classes are built from a hierarchy of classes with no visual component Why use server classes? Partition functionality separate from GUI Instantiate only needed behaviors Distribute to a different physical tier Enhance reusability of behavior between objects in different hierarchies Can be maintained independently of clients (requesters) Service Classes

  18. Proxy classes are classes that serve as local substitutes for classes deployed elsewhere Proxy classes allow other local classes to maintain reference variables, while facilitating distributed computing by hiding the true location of the implementing class Proxies are used in both service-based architectures and as an aid in centralizing logic in the middle tier Examples of Proxy frameworks Microsoft DCOM JavaSoft RMI OMG CORBA Proxy Classes

  19. Local Proxy Object Remote ImplementationObject 9. Invokes implementation 1. Invokes method Stub Object Skeleton 8. Unmarshals 2. Marshals 5. Forwards request 3. Submits request 7. Invokes method ORB ORB 4. Locates target ORB 6. Identifies target object IIOP Proxy ExampleCORBA IIOP Method Invocation

  20. Distributed Application Development Client Middle Tier Data Web Server Browser Very Thin PageServer ProductionData FileSystem HTML Pages ProductionData Templates, Scripts Browser or C/S Thin TransactionServer ProductionData Components Components ProductionData Enterprise JavaBeans, COM, CORBA, PB NVOs Client/ServerApplication Rich ProductionData Components

  21. Java Clients HTML Clients PB Clients Enterprise Application Server PB EJB ActiveX Application Integrator CORBA Security IIOP CICS Java and Stored Procs Diverse Client Types With Enterprise Application Server 3.5

  22. The PowerDesigner program is a powerful tool that can be used by a variety of users with different backgrounds Business Analysts Database Administrators System Programmers Your role, the point in the systems development process, and the technology set you are using all determinants in using PowerDesigner So Where Does PowerDesigner Fit?

  23. The CDM, PDM, and OOM models are intended for different audiences with different needs How PowerDesigner is used depends partially on the background and role of the person using it. Conceptual Data Models Good for Business Analysts and DBAs Physical Data Models Good for DBAs and System Developers Object-Oriented Models Good for System Developers and DBAs Differences Between Model Types

  24. Least complex of the three model types Some familiarity with relational databases, SQL, and design methodology is helpful, but not required Uses Entity Relationship (ER) modeling notation, the Merise notation to link entities, or a combination of the two methodologies. The principal model objects are data items, entities and their relationships. These are easy to understand and to manipulate. Business Rules can be captured Forward engineers into PDMs and OOMs Data type translations are straightforward, but case sensitive Conceptual Data Models

  25. When you generate a Conceptual Data Model (CDM) from an Object-Oriented Model (OOM), PowerDesigner translates OOM objects and data types to CDM objects and data types. The current object language of an OOM has no effect on the generation to a CDM. There are several considerations before generating the CDM Upper/Lower/Mixed case issues for object names and codes Resolving data types between models Resolving OOM objects into CDM objects Dealing with what doesn’t get placed in the CDM Namespace issues Generating a CDM from an OOM

  26. You can generate a CDM from a global OOM or from a package within the model. The default model namespace in the CDM is the model, the default namespace in the OOM is the package, so beware! Generating a package results in an independent CDM.You generate a CDM from a diagram in the model. Limiting CDM generation to a single package is needed when OOM namespaces are resolved at the package level. Conceptually is easier to move from OOM to CDM when OOM namespaces are resolved at the model level Generating a CDM from an OOM

  27. OOM object CDM object after generation Domain Domain Class Entity (only if the Persistent and Generate checkboxes are selected in the class property sheet) Interface Not translated Attribute Attribute Identifier Identifier Operation Not translated Association Relationship or association Dependency Not translated Realization Not translated Generalization Inheritance OOM Model Objects to CDM Model Objects

  28. In the CDM workspace, you may want to enhance the model OOM generation translates conceptual objects into specified OOM objects as follows: Object in CDM Object generated in OOM Entity Class Attribute Attribute Association Relationship or association Inheritance Generalization Note: Association Dependency, an important concept in the CDM, is lost when generating to the OOM! Mandatory, or not null constraints, are also lost Altering the Model Design in the CDM

  29. Physical Data Models allow the model to be specialized and targeted at different databases, taking into account the strengths, weaknesses, and capabilities of that database PDMs Forward engineer to the physical database, including DDL, triggers, views, and stored procedures for over 30 different database types Can also reverse engineer database objects from the physical database Physical Data Models

  30. When you generate a Physical Data Model (PDM) from an Object-Oriented Model (OOM), PowerDesigner translates OOM objects and data types to PDM objects and data types. The current object language of an OOM has no effect on the generation to a PDM. There are several considerations before generating the PDM Upper/Lower/Mixed case issues for object names and codes Resolving data types between models Resolving OOM objects into PDM objects Namespace issues Generating OOM objects to a PDM

  31. OOM object PDM object after generation Domain Domain Class Table Interface Not translated Attribute Column Identifier Identifier Operation Stored-Procedure Association Reference or table Dependency Not translated Realization Not translated Generalization Reference OOM Model Objects to PDM Model Objects

  32. For a class to become an table the Persistent and Generate checkboxes must be selected in the property sheet of the class. The cardinality of a class becomes the number of records of a table. This allows database size to be calculated. Generating from Classes

  33. If the association has a many-to-many cardinality, that is, where both roles of the association have the * sign selected in their multiplicity dropdown listboxes, then the association is translated into a table in the generated PDM. If it has any other cardinality, that is, where one of the roles of the association does not have an * selected in its multiplicity dropdown listbox, then the association becomes a reference. A role name becomes a migrated foreign key after PDM generation. Generating from Associations

  34. You can generate a PDM from a global OOM or from a package within the model. Generating a package results in an independent PDM.You generate a PDM from a diagram in the package. The default model namespace in the PDM is the model, the default namespace in the OOM is the package, so again, beware! Limiting PDM generation to a single package is needed when OOM namespaces are resolved at the package level. Conceptually easier to move from OOM to PDM when OOM namespaces are resolved at the model level Generating a PDM from an OOM

  35. To generate OOM objects to a PDM, select Tools  Generate Physical Model… from the menu You can generate a New PDM or Update an existing PDM You can choose to update, delete, or add objects in the existing PDM based on any modifications made in the PDM. Generating Physical Data Models

  36. When updating a Physical model, PowerDesigner will go through a model translation process, and then a model merge process. When Preserve modifications is not selected, PowerDesigner replaces the selected target model (existing PDM) with the new PDM. If you want to choose which objects to add or delete, you must select Preserve Modifications to compare and merge into the PDM. If Preserve Modifications is selected, the Merge Models window appears. You can use the Merge window to select objects to be updated, deleted, or added to the target model. Updating Physical Models

  37. PDM generation options include checking the model, and saving generation dependencies. Saving Generation Dependencies: Leave this checked! PDM Generation Options

  38. Table prefix: Allows you to prefix table names with owner names Update Rule: Set update referential integrity for references Delete Rule: Set delete referential integrity for references PK Names: Primary key index names generated AK Names: Alternate key index names generated FK Names: Foreign key index names generated FK threshold: Minimum number of estimated records in a table that are necessary before a foreign key index can be created Other Model Options

  39. On the selection tab, you can select the classes that you want to generate to the PDM. Relationships, Domains, and Business Rules are all generated by default. You can also select a Package for PDM generation PDM Generation Options: Selection

  40. OOM generation translates Physical objects into specified OOM objects as follows: Object in PDM Object generated in OOM Domain Domain Table Class. The cardinality is the est. records in a table Column Attribute Key Identifier Primary key Primary identifier Stored-Procedure Operation Reference Association Note: Identifying foreign keys and not null constraints are lost when generating to the OOM! Altering the Model Design in the PDM

  41. Mapping objects to relational databases is challenging! There are (at least) three distinct ways to map objects to databases Map class attributes to table columns Map Java classes to table columns Use the Sybase DataWindow/Datastore Technology The Challenges of Persisting of Objects in Relational Databases

  42. This is the default approach when using PowerDesigner Classes, associations, and generalization will be mapped to tables Class attributes map to columns in a table Allows for indexing and querying on attributes using SQL Allows for conditional retrieval based on attributes Allows attributes to be retrieved without instantiating the classes, e.g., for reporting purposes Most complicated method for mapping objects to databases, but allows for fine control over query and access Map Class Attributes to Table Columns

  43. You can use Java classes as SQL user-defined data types: Store Java objects in database tables as a column By using a Java class as a data type for a column in a table, you can store data in your database in the form of Java objects. You can access Java operations and attributes of Java objects in SQL statements through JDBC. Map Java Classes to Table Columns

  44. The distinction between entity and attribute may sound clear, but a little reflection shows that it is commonly not at all clear in practice: An address may be seen as an attribute of a customer, but an address is also an entity, with its own attributes of street, city, and so on. A price may be seen as an attribute of a product, but may also be seen as an entity, with attributes of amount and currency. The utility of an object-relational database lies in exactly the fact that there are two ways of expressing entities. You can express some entities as tables, and some entities as classes in a table Entities and Attributes in the Real World

  45. Java classes are useful for abstracting at a level between that of the single relational column and the relational table. Data in a relational database can be categorized by its purpose. Which of this data belongs in a Java class, and which is best kept in simple data type columns? Referential data Columns that are commonly indexed Other descriptive data Computed Columns: With computed columns you can selectively index a Java attribute or operation. Levels of Abstraction for Relational Data

  46. Another approach is to use Sybase’s DataWindow technology to bridge the object/relational gap This is particularly useful for less capable databases or legacy databases, or when organizations have PowerBuilder or PowerJ developers. Approach: Replace class attributes with a single DataStore or DataWindow class variable Create Operations to manipulate classes Create DataWindow Objects for the database tables Use native DataWindow/DataStore Class methods to access relational data Sybase DataWindow/Datastore Technology

  47. If you are beginning a new design, you will want to start in the OOM, or perhaps the CDM if you are less technical If you are reverse engineering a database, you will start in the PDM and reverse the PDM to the OOM If you are reverse engineering a PowerBuilder or Java application, you will start in the OOM To maintain fine control over the generation of Identifying/Non-Identifying foreign keys, you will want to use the CDM on the way to the PDM. So Where do I Start?

  48. There are significant differences between model types OOMs, CDMs, and PDMs are appropriate for different technical roles Generating CDMs Generating OOMs from CDMs Generating PDMs Generating OOMs from PDMs There are several decisions to make in bridging the object/relational gap Where do I start? Thanks for attending this session! Summary

  49. Audience.Query()

More Related