Exploring New Territory: Powerdesigner Extensible Objects

Exploring New Territory: PowerDesigner Extensible Objects

Written by Kevan Shelden

Nielsen Media Research, Core IT Business Architecture

At Nielsen Media Research (NMR), the Core Business Architecture group recently completed a project to evaluate where systems support business processes poorly or not at all.Our first challenge was to determine the format to use in capturing the information. Typically, this would be text documents or spreadsheets, much like requirements are often documented, along with data and process models. Having used such approaches many times previously, we knew the frustration of managing multiple artifacts and trying to conduct analysis from them. Instead, we decided to boldly go where we’d never gone before and incorporate all the information we discovered and derived into a single model that would serve as our source of project knowledge and provide ongoing benefit after the project’s end.We chose a model, rather than another type of artifact, because of the graphical component and PowerDesigner’s extended object capability. In fact, it was the latter that started our thinking in this direction. I’ll take you through the steps and methods we used to develop a new, or extended, model type. They are applicable to creating any type of model, for any purpose.Next, I’ll give a brief overview on how to utilize PowerDesigner’s extended object capability and extend standard model definitions by creating your own object types. In conclusion, I’ll share my thoughts on the usefulness of traditional IT models and how modifying them yields more information, more rapidly, with greater flexibility and ease of management, which allows us to better support and respond to business needs.

So, we knew we wanted to use a model to collect all project information. There are three major decisions to make. First decision.“What type of things do we need to capture?” The answer to this will depend on the nature of your project. For our project: processes, resources, pain points (mismatch between system and business process), interviewees (who told us about the pain), project action (out of scope, IT addressable, business addressable), initiatives (wide scope work efforts to correct the root causes), and business needs (as opposed to what it is getting from systems). The latter five are certainly not standard; they were specific to our project. No object types[i] exist to capture that information, but we could create them using the Extended Object capability in PowerDesigner. This ability is the key to creating new types of models. Simply putting a graphic symbol on a model diagram with, maybe, a text box property is in no way sufficient. New object types must have a full set of properties and collections like standard object types. Since it is impossible to imagine what object types you might need to create, it is impossible to imagine what object types you might want to relate them to. Therefore, they must have the capability of being related to all other object types, standard and created. In short, they must be as robust as the standard types.

Second decision. “What type of model will support our needs?”The type of model you decide to use as the basis for your custom model will again depend on your specific needs. Our thoughts went like this. Data model? No, our focus wasn’t modeling data, although we would be identifying information entities. Process model? The business process was established and process re-engineering was beyond the project scope. UML diagrams in an Object Oriented model? We needed to see where business processes were not properly supported by systems. None of the numerous UML diagrams would show us that. Free model? No. We don’t want to have to create everything from scratch and some of the object types were already defined. Clearly, a new type of model was called for: a Business Process and System Assessment model. Only, that type of model didn’t exist. Rather than invent a new model type from scratch, we decided that since we were gathering information related to business processes and systems (resources), we wouldstart with a process model since it includes those object types and modify it to meet our needs by creating the object types listed above.

At this point knew the information we needed to capture and we had identified a means to accomplish that.Third decision. “How do we communicate what the new object types are, and how do we show the relationships between all object types?” To answer this one, wecreated a meta-model to define the relationships. For this, we used a PowerDesigner conceptual data model (cdm) since it enabled us to show optionality and cardinality. (Our BArc group routinely uses cdms to develop metamodels.) If you lean toward skipping this step—don’t. Don’t skip the documentation. You may know how the object types relate, but you’re going to get tired of explaining it again and again as people try to visualize it. Put the information in a metamodel: define the object types, make sure you state the optionality and cardinality, and use explanatory role names on the relationships (omitted in the diagram below for readability’s sake). I strongly advocate extracting the relationship statements out into text format so that people don’t have to be model gurus to understand them. You can write a VBScript to do this quite easily. (I’ll have more to say on that topic later.) Put them in a text box on the diagram. It’s much easier for someone to read the English statement, “A Pain Point must be associated with at least one and at most n Interviewees,” than to interpret the diagram symbols.

As you can see from the metamodel, we ended up with more “new” object types than ones that are standard to a process model. By extending the model, we were able to capture all the information necessary to determine where systems supported business processes poorly or not at all in one place. We knew—and could visually see and communicate—what processes had pain, what that pain was, the root cause of the pain, what the business needed (as opposed to what they were getting), how we were going to deal with the pain, and a list of less than ten initiatives that would address all the pain points. Pretty good for one model.

Once you reach this point, it’s time to actually extend the model. Any type of PowerDesigner modelcan be extended in the same way. Under Tools > Resources, create an Extended Model Definition for the type for of model you’re extending. You can do this with a model open or not. This is a separate file, with a .xem extension,that can be saved anywhere and will contain the new object types that you define At this point, it is an empty file. You can create new object types when you create the definition or after you’ve linked it to a model(s). To link the extended model definition to a model, open the model and go to Model > Extended Model Definitions. Select Import an Extended Model Definition and browse to the .xem file. Opting to share the file allows multiple models to use the same definition and insures that all changes to it are picked up. Copying it into the model does just that, but no connection is maintained to the .xem file. Any future changes to it will not be known. Since we had multiple people who would be working on the model, we elected to use a shared definition so everyone would be working with the same set of objects.

Opening the extended model definition’s property sheet allows you to create new object types as well as stereotypes of standard object types. From the Profile context menu (right-click on Profile), select Add Metaclass. You’ll see two tabs: one with object types common to all PD model types and one with object types specific to model type. To create a new object type, select Extended Object. Each new object type is going to be a stereotype of the Extended Object. To create one, select Stereotype from the Extended Object context menu. You can elect to use your new object type as a metaclass. If you elect to do so, objects in the browser tree will be grouped by type, then by name. Personally, I don’t find that useful, especially since you can go to Model > Extended Objects and sort by stereotype or apply a filter to show a specific stereotype. When you have more than two or three stereotypes of Extended Object and more than five or six instances of each, it’s painful to look through the list and find the object you want using the browser tree, especially if you don’t already know its stereotype. Of course, the corollary is that if you use created object types as metaclasses, you can go to Model > Extended Objects and sort by name without regard to stereotype. Two approaches; same result. Using Categories (which act like folders), you can organize created objects in the extended model definition. Since we knew we would have sub-types for some of our new object types, we created separate categories

Now for the fun part! Here’s your chance to be creative. There’s no button on the Palette for Extended Object because,except for the free model, it does not appear in a model by default. Sure, you can create one from model’s context menu in the tree structure, then open its property sheet and select the stereotype there but why not create a toolbar button for the stereotype? You will need to have the graphic you want displayed on the toolbar in a .ico or .cur file. There are a number of freeware programs that will import varying graphic file formats and save them in these formats. They will also allow you to create your own symbols. A search of the Internet should produce several choices. Select the Palette Custom Tool box, then browse to the desired .ico or .cur file (middle button next to Icon:). The symbol appears in the leftmost box. You can display the toolbar with the custom buttons by going to Tools > Customize Toolbars.

Creating custom symbols to display on the diagram is equally simple. From the context menu for a stereotype object definition, select New > Custom Symbol. This will show the extended object default symbol in the lower right of the window. To change the symbol, click the Modify button to display the standard Symbol Format window. You can modify size, line style, fill, shadow, and font, but let’s go beyond that. From the Custom Shape tab, you can select from a number of predefined symbols and modify their basic format, but let’s go beyond that too. Select the Enable Custom Shape box, browse to and select an image file of one of the following types: *.emf, *.wmf, *.bmp, *.dib, *.rle, *.jpg, *.jpeg, *.png, *.ico.

The Symbol Format window is also used to modify the appearance of standard symbols. Go to Tools > Display Preferences > Format. Select the Object Type and click the Modify button. To use the modified format for all new objects of that type, select Set as Default. Clicking the Apply To button will bring up the Select Diagrams window. By selecting diagrams, you can update existing symbols.Note that in all cases the symbol on the toolbar button can differ from the actual one used for objects in diagrams.

We created thirteen extended object stereotypes for pain points. Each represents a categorization of a pain point’s root cause, such as manual process, data quality, documentation, business rules. Because graphic representation was important to us, we defined custom symbols for each pain point stereotype object. Actually, we used the same graphic—a wicked looking syringe—done in varying colors. After all, they are only different flavors of the same type of object. The same-object-different-color trick was used again for project actions and for initiatives. A business need has no categorization, so there is only one symbol for it. Since we didn’t plan to show interviewees, we didn’t create a symbol for that object type.

Custom symbols are an excellent way to add visual interest to a diagram and communicate information that would otherwise be buried in object properties, or even lost. As an example, we also stereotyped the standard Resource object and created custom symbols. This allows us to look at a diagram and know just by the symbol if the object is a database, an application, paper document, computer file, etc. Non-technical people especially appreciate this. Not only does this increase a diagram’s visual appeal—a richly colored picture rather than a bare schematic—but it communicates increased information in a more easily understood way. After all, if a model doesn’t facilitate communication or people don’t use it, then it’s worthless, regardless of how correct it is. A final bit on custom symbols: keep them simple. What looks great on a screen may well become a meaningless blob when reduced in size and included on a diagram.

Now that we have our model and it contains all the information on our project, how do we analyze all that information? How do we get our hands around it and ask ‘what if’ questions, and group the data in different ways, and summarize it, and report on it at different levels of granularity? We turn to our old friend Excel and our new friend (I use the term loosely here) VBScript. One of my pet peeves, and a major PowerDesigner shortcoming, is the lack of an easy way to export object property data to Excel. Fortunately, VBScript is not difficult to write, although trying to debug a script may well drive you buggy. You will also need to understand object hierarchies, properties, and collections. The Scripting Object Help in PowerDesigner is fairly good once you get the hang of it and there is a strong chance that someone has already written a script to do what you need. Check the examples that ship with PowerDesigner and the scripts in the SDN CodeXchange at orask in the newsgroup at

For us, one script sufficed to produce a spreadsheet from which it is possible to perform over ninety percent of the analysis. If you thought about the three decisions above, correctly analyzed what type of model and model objects you needed, and related them in a useful manner, then you’ve got all the information you need. Extract it, twist and turn it, take it apart and put it back together. Use it!

Does the creation of new model types and objects mean that traditional ones are outdated? No! Keeping enterprise level atomic data and process models remains imperative. (UML diagrams are composite and not scalable to the enterprise level, but I’ll leave that discussion for another time.) However, I believe the types of IT models in use today are insufficient for today’s dynamic business environment. Whether data model, process model, or UML diagrams, too much analysis takes places outside of them. Too many artifacts in various formats are necessary to get a complete picture for analysis because none can contain all the necessary information. We need new types of models that can contain the information. What are these new types of models? What is the necessary information? I don’t know. The answers are not knowable. Situations are unique and require custom answers. Let me expand my prior statement on model insufficiency. We need the ability to create new types of models and model objects, on the fly, to meet specific situations. These models need to do more of the analysis work for us, allow us to do the remainder faster and easier, and they need to do it in a way that improves communication to non-IT individuals.

I visualize new model types being variations of data and process models, particularly the latter. The Business Process and System Assessment model we constructed could have been created in an existing business process model. (If we’d had one, we would have done just that.) Add the new object types as extended objects and create copies of process diagrams to show them. You can’t stereotype a diagram (yet), but you can use a naming construct that allows you to exclude certain diagrams from reports, without having to select each one individually. Thus, from the same model you could produce a standard process report with its diagramsthat do not show the pain point objects, and a ‘pain point’ process report with diagrams that do show them. Another approach would be to shortcut objects from an existing business process model into a new model and add the new object types there. The approach you take will be influenced by the types of models you keep and how they relate to each other. If you don’t have a metamodel of this already, run, don’t walk, back to your office and get started on it. With that, and an understanding of the specific needs of a new type of model, you’ll be ready to extend your models and explore new territory.In the words of John Zachman, “this afternoon would not be too soon.”