http://www.intelligententerprise.com/010723/411products1_1.jhtml
Design Husbandry
Enterprise modeling benefits from harnessed power
By Rajan Chandras
| PRODUCT SPEC SHEET | |
|
When Fusaichi Pegasus won the 2000 Kentucky Derby, it came as no surprise. He had a good pedigree and was known to be among the best in his generation - a proven performer. On a different tack (and track), in the much less exciting world of enterprise modeling tools, pedigree and sustained performance are still the essential characteristics of a winner. And you would do well to place your bet on the latest thoroughbred from the stables of Sybase: PowerDesigner 8.0.
GOOD BREEDING
Like Fusaichi Pegasus, Sybase PowerDesigner 8.0 has an impressive lineage, one that you can trace back to the S-Designor product from Powersoft Corp., which acquired the product from SDP Technologies, a French company. With Sybase's PowerSoft acquisition in 1995, the S-Designor product - renamed PowerDesigner - joined the Sybase camp along with PowerBuilder, the flagship product of the erstwhile PowerSoft.
PowerDesigner has strong roots in the areas of logical and physical data modeling, and a keen rivalry with ERwin/ERX, now from Computer Associates. In fact, PowerDesigner and ERwin were both winners of the 1995 Readers' Choice Award at DBMS magazine, an earlier avatar of Intelligent Enterprise. While ERwin stayed put on the well-defined tracks of data modeling, PowerDesigner expanded coverage into the rocky terrain where relational modeling meets object modeling, and now stands in firm competition with products such as Rational Rose from Rational Corp. and System Architect from Popkin Software, in addition to ERwin.
BROAD SUPPORT
PowerDesigner supports conceptual data modeling, physical data modeling, and object-oriented (OO) modeling with the Unified Modeling Language (UML); the UML support extends to use cases, sequence diagrams and class diagrams. PowerDesigner also supports forward and reverse engineering for SQL scripts, ERwin files, ODBC data sources, XML, and object language sources, including Java, C++, and Visual Basic.
PowerDesigner has several additional capabilities, including a rudimentary but nontrivial ability to generate test data based on the model objects, a repository for managing and sharing design document versions, a business rules feature that lets you attach business rules to objects, and a powerful facility to compare and merge models, as well as compare and synchronize objects that have differing definitions.
THE WINNERS
So, what does all this mean to you? As a software architect or designer, these features let you carry out many activities in what I call the "software design life cycle" on a seamless platform, such that objects created in different settings (or "models," more formally) are aware of each other, work together, and can be managed together.
As a software development manager, you can now trace the path from the use cases and sequence diagrams that the business users help define (and can understand at a glance) to the software code that developers are working on and the tables in the database that your DBA manages.
As a CIO or CTO, you could perhaps save some costs on purchasing a separate test data generation tool and software version management tool, at least initially. More important, you will likely see shorter design and development time scales and better quality and manageability in the software development life cycle - a direct result of having empowered your software architects and designers.
INHERENT RISKS
While the benefits are many and real, there are also some real reasons for caution. Multifunctional tools, such as PowerDesigner and the Rational suite, offer functionality to many different types of users, including business users, business analysts, application and data architects, database administrators, developers and testers - practically the whole gamut of the software development team. Therefore, you potentially have several different people applying simultaneous changes to an interrelated set of documents, an inherently risky situation.
Second, such tools typically allow various process paths within the software design life cycle. Say for example you choose a process that starts with an OOM tool (the use case diagram), then goes into other tools, and ends with another OO modeling tool (the class diagram). Your architects and your team may prefer to go about it differently from you - and even differently from each other, which can affect the coherence of the overall software architecture. In other words, this flexibility will need to be tempered with process discipline.
Finally, whenever you generate code or code templates using automated tools, the developers are almost certain to manually change the generated code, thus creating a disconnect between the parent constructs in the design tool and the code these constructs generated. Notwithstanding the PowerDesigner compare-merge feature, in my experience, this disconnect can't easily be recovered, and sometimes is even acceptable - you just have to work around it. However, if you do not want such a disconnect, then you must have a very rigid process in place to prevent it.
CHOOSE YOUR PATH
As I stated earlier, given the mix of design tools, you can begin the application design in a number of different ways. I would usually prefer to start with the use case diagram in the PowerDesigner OOM (OO model), where it defines high-level services (a specific type of use case) that the application system provides, together with the actors (users, in this instance) that will interact with the system. (See Figure 1.) For example a customer (actor) that tries to log in through a Web browser into a Web application would interact with the Validate_User use case, which in turn would interact with the Customer_Profile use case.
These use cases and actors can then be dragged and dropped into sequence diagrams, which model more detailed interaction. The sequence diagram captures the messages that flow between the actors and use cases, arranged in chronological order. You can define messages as synchronous (the sending object waits for the message to return), or asynchronous (the object need not wait).
In my example, a Customer object may send a login_request message to the Validate_User object, which in turn sends a validate_customer_request message to the Customer_Profile object. On the return path, the Customer_Profile object sends a validate_customer_result message to the Validate_User object, which then sends out a login_response message to the Customer object.
NEXT "LOGICAL" STEP
The action then moves to the PowerDesigner CDM for conceptual data modeling. Here you construct a logical data model based on the knowledge gained in the previous diagrams. You'll note, for instance, that the actor Customer and use case Customer_Profile might translate to entities, and you'll identify potential data requirements for the remaining objects and messages.
The PowerDesigner CDM supports two notations for conceptual data modeling: Entity-relationship (otherwise known as "information engineering" notation) and Merise. A key difference between the two is that entity-relationship notation depicts an association or associative entity between entities with a joining line, whereas the Merise notation shows the association by means of a rounded box attached to the two entities by relationship lines. I was disappointed with the absence of support in PowerDesigner for the IDEF1X modeling notation, which is very simple yet very effective.
GET PHYSICAL
After you finish the conceptual model, you can either generate a physical data model (PDM) or a class diagram; my choice is the former. You can generate the PDM for a wide variety of databases, including IBM, Microsoft, Sybase, and Informix. PowerDesigner has a nice feature that lets you fold a conceptual subtype (inheritance) entity relationship from the CDM into a single table in the PDM with the subtype columns included in the parent table. This feature truly separates conceptual and physical design.
From the PDM, you can select the object language (say, C++ or Java) and generate the corresponding OO (class) diagram. Or, if you're going in the other direction, you could also generate a CDM. Model generation creates one class definition for each table, with class attributes (properties) for columns. You can create constructors and destructors and also generate get() and set() operations for each attribute. In addition, you can create links between the classes to represent the relationships of generalization, association, dependency, and realization.
POOR PLACEMENT
To test the PowerDesigner Repository feature, I created a repository on a local SQL Server 7 server. Creating the repository went smoothly, but I was startled to see that all the new repository tables appeared in the Master database because the ODBC connection used the default database (in this case, the Master database). I find this unacceptable. The Master database is a "system" database and best left alone; the repository should force the user to create a separate database or create a predefined database for its own consumption.
TAMED POWER
I touched only briefly on the various strengths of PowerDesigner here, but I hope it is clear that PowerDesigner is truly a powerful tool. Yet, for all its power, I find that PowerDesigner is reasonably simple to use. It has a good, clean interface, appears stable, and has good documentation. As an enterprise modeling tool it offers excellent value, and is certainly worth consideration in your enterprise toolkit.
Rajan Chandras [rchandras@hotmail.com] is a consultant for a large international consulting and systems integration firm. He has 14 years of software industry and consulting experience, and is based in New Jersey.
RESOURCES
Related Articles on IntelligentEnterprise.com:
Rational Rose 2001 two-part review, March 27 and April 16, 2001
Ontos ObjectSpark 4 review, May 7, 2001