PowerBuilder Authors: Chris Pollach, Yeshim Deniz, Jayaram Krishnaswamy, Kevin Benedict, Avi Rosenthal

Related Topics: PowerBuilder

PowerBuilder: Article

Object-Oriented Analysis And Design With UML And PowerDesigner 8

Object-Oriented Analysis And Design With UML And PowerDesigner 8

PowerDesigner 8 recently shipped to production, and the new modeling features added in this release now enhance the tool to support the entire object-oriented analysis and design (OOAD) life cycle. During the last two product releases (versions 7 and 8), the development team at Sybase focused on bringing UML functionality to the tool and extending its usefulness as a development aid.

As version 8 comes to market with its new features, users will have to adopt a methodology for effective systems analysis and design. The following suggestions are culled from the OOAD literature regarding this topic, and thus constitute a set of best practices for modeling with this powerful tool.

The Unified Modeling Language (UML) was first proposed by the Object Management Group (OMG) as the successor to the wave of modeling techniques that appeared in the late 1980s and early '90s. The OMG is also famous for bringing developers CORBA and other important advances in distributed computing. The UML is a modeling language, not a process. It's a mainly graphical notation for expressing designs in general, not necessarily software designs. However, the software development community has embraced UML most readily.

A number of UML diagram types are generally divided into the following views: logical, use-case, component, concurrency, and deployment (see Figure 1). Each view illustrates different aspects of the design problem.

With PowerDesigner 8 we now have at least one diagram supported for each UML view. This is indeed an important event. The analysis and design process calls for the use of different modeling techniques during different phases of analysis and design. At a high level the UML defines the development process in four phases: inception, elaboration, construction, and transition. Likewise, PowerDesigner now supports each phase with at least one model type.

In the balance of this article, I look at how the five views and four phases (see Figure 2), as defined by UML, are supported in PowerDesigner. This constitutes what I consider to be the set of best practices for UML modeling with PowerDesigner 8.

In the inception phase the designer establishes the reasons for going ahead with the project and decides on its scope. In PowerDesigner 8 the best model diagram for the inception phase is the use-case diagram. Using these diagrams, the modeler can easily show what is in scope for the project and what is not.

Use-cases can also be utilized at a high level to convey information about the top-level processes that the system will perform. Typically, at the end of the inception phase there is a go/no-go decision regarding the subsequent development of the system. Typical analyst outputs at the end of the inception phase include a systems requirements document and a set of high-level use-cases to outline the problem domain.

In the analysis-rich elaboration phase, the goals of the system are fleshed out and serious analysis begins. During analysis, the analyst's focus should be on what the system is doing, not on how, so decisions regarding implementation language, and more, are premature here. The primary UML views used here are the use-case and logical, and the elaboration of the original high-level use-cases.

Use-cases are unique in their ability to focus on the functionality of the system from the perspective of an "actor" or user of the system. In use-case modeling, actors are the drivers of the system and the recipients of the system's functionality. Use-cases show an actor performing one or more use-cases, typically some process or function, and the subsequent outputs. A sample use-case is shown on Figure 3.

Use-cases have become widely used by analysts even if they're not doing full-blown OOAD because they're so intuitive. In fact, use-cases are replacing the more traditional data flow diagramming (DFD) as an analysis technique. What I like about use-cases is their ability to be "leveled," like data flow diagrams. Leveling is a process in which the model can be exploded into a series of submodels whose subprocesses can be further decomposed in increasingly greater detail until the level of model detail is appropriate for the complexity of the problem.

Two other important semantics in use-case modeling are the "Uses" and "Extends" cases, which allow a use-case to be incorporated by reference into a subsequent use-case, or made to extend another use-case. Extending a use-case is similar to class inheritance, as it allows the modeler to focus on the additional functionality found in the extended use-case without repeating information between use-cases.

In addition to the use-case diagram, each use-case typically has a brief narrative that includes information about it. A simple narrative structure can be created in either PowerDesigner or a text editor. A typical use-case structure is shown in Figure 4.

The use-case narrative text fleshes out the diagram and provides important context to the model, usually a short paragraph describing the use-case. The preconditions section lists required inputs and the main flow is the usual way the use-case would be performed.

Alternate flows list alternative means of accomplishing the use-case, post-conditions are the logical outputs from the process, and exceptions are all known error-causing scenarios. A typical use-case narrative like this is usually only a few pages, maximum, and can be constructed in PowerDesigner 8. You can then create custom report templates in PowerDesigner to output your use-case documentation in a variety of formats, including RTF and HTML.

After use-cases have been created, the typical next step of the elaboration phase is to perform a word-search exercise to find the "things" that make up the system, as well as their behaviors and properties. I say things because in the UML object model in PowerDesigner, things will become classes, in the PowerDesigner Conceptual Model (CDM) they will become entities, and in the PowerDesigner Physical Model (PDM) they will become tables. Luckily, PowerDesigner will transform these things between model types automatically.

During a word-search exercise, the analyst will search the requirements specification documents and use-case narratives to find the nouns and make a list of them. Duplicates and synonyms are removed, and a short list of the most important nouns is retained.

The next step is to find the adjectives, which are the ways these nouns are described in the system. The final word search is for verbs and verb phrases, which will become candidate methods for our classes that implement our use-cases.

At the end of the elaboration phase, the analyst will transfer the nouns found to a class diagram in PowerDesigner, and will begin the process of adding the adjectives and verbs as attributes and methods of the class respectively. The analyst will also begin the task of assigning some structure to the class diagram by creating associations, generalizations, and aggregation/composition relationships to the class model. Although other pundits may suggest additional deliverables at this point, to my mind, this concludes the elaboration phase in UML. You are ready for serious design in the construction phase.

The construction phase in UML marks the end of system analysis and the beginning of detailed system design. Design focuses on the "how" of the system, and thus implementation details such as development language (Java, PowerBuilder, etc.) will be made, as well as decisions regarding the use of object frameworks (JDK version, PFC, EAF, etc.) and deployment models (terminal server, client/server, or Web). Subsequent modifications to the models developed so far will take the chosen frameworks and technical architecture decisions into account.

The predominant PowerDesigner models used in the construction phase are the class diagrams in the OOM and the Physical Database Model (PDM). Focusing on class diagramming, the system will be modeled in a series of class diagrams depicting the classes and the relationships between them. A sample class diagram is depicted in Figure 5.

PowerDesigner 8 supports a number of object-oriented languages and technologies, including PowerBuilder, Java, C++, CORBA, Visual BASIC 6, and XML. During the construction phase, PowerDesigner can be used to generate class definitions in several of these languages and to reverse-engineer existing code.

Every system I have ever been involved in developing has had some aspect of the system in which the timing, dynamics, or object-event interaction was particularly complex. To aid in this problem during construction, UML offers concurrency view diagrams such as the sequence or activity diagram. One of the more welcome enhancements in PowerDesigner 8 is the addition of the UML sequence diagram, which shows the sequence of object interactions and the messages that pass between classes. The beauty of this in PowerDesigner is that once the classes and methods are defined in the model, these diagrams almost draw themselves!

One aspect of best practices in object-oriented modeling is to expend your modeling efforts in proportion to the overall complexity of the problem. In other words, don't spend too much time modeling trivial or simple aspects of the system. When you're faced with complicated event sequences or processes there's nothing better.

A typical sequence diagram for a complex sequence of events will document the events when triggered by an initiating class. An example of a typical UML sequence diagram is shown in Figure 6.

In the transition phase, system construction is concluded and testing and deployment are the primary issues. Other non-OO transition issues include data migration and cutover. Use-cases were discussed in an earlier phase, but they become valuable again in the transition phase because they can drive test scenarios (called use-case scenarios), which can be used when testing the system.

In fact, there is potential for reusing use-cases throughout the UML phases. Developers can refer to use-cases during construction, and during transition they can also be used to develop user manuals and training material as well. Remember that one of the key goals of effective OO techniques is to accomplish reuse, both in code and in design during the development process. So be sure to revisit your use-cases here.

One final, yet important, aspect of transition is deployment. UML has a special deployment diagram, called a package diagram. A package diagram is used to show functional dependencies in a system as well as physical dependencies during deployment. The typical approach is to group related classes together into higher-level units, called packages. Thus the concept of a package in UML was born.

Classes are packaged in PowerBuilder libraries, or .ZIP or .JAR files in Java, or as a DLL in C++. The principal elements in a package diagram are the packages and their related dependencies. Ideally, packages should be as decoupled from each other as possible, but there will always be some critical dependencies between them.

For example, a PowerBuilder PFC-based application depends on the PFC packages, including the Application Services, Window Services, and DataWindow Services. You may also develop some dependencies within the system you're developing; for example, the shipping package may depend on the order entry package. Package diagrams are also easily drawn in PowerDesigner 8. An example of a package diagram, with dependencies shown, is displayed in Figure 7.

PowerDesigner has always been a strong player in the database design space, and has had model types that allowed for functional and logical system design for some time. But the advent of PowerDesigner 8, with its support for UML diagrams throughout the OO system's development life cycle, brings PowerDesigner into a rare category of tools that can be used from project inception through delivery.

Users with different backgrounds will want to use PowerDesigner 8 in different ways. Analysts will want to use PowerDesigner use-case diagrams and conceptual models, DBAs will want to use the physical model, and more technical designers and object language developers will feel right at home with the object-oriented model. Which models you use and the order in which you employ them will depend on many things, including your location in the systems development life cycle.

PowerDesigner 8 provides the necessary tools for a logical progression through the OOAD process on a new project using state-of-the-art languages and UML for design notation.

More Stories By Don Clayton

Don Clayton is president of Intertech Consulting, Inc., which specializes in Sybase and Microsoft technologies. He's a CPD professional who has used PowerBuilder since version 1 beta and PowerDesigner for over five years. Don is a faculty member of the Jones Graduate School of Management at Rice University, where he teaches systems analysis, database design, and business process

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.