Моделирование бизнес-процессов / Моделирование бизнес-процессов / ERwin_Insider

This is a very shallow comparison to dependencies and is only meant as rouge frame of reference. In the UML dependencies are used to show when one t hing uses another and can be semantically defined in terms of eleven classified functions. Further discussion is beyond the scope of this article.

Recursive Relationships

A recursive relationship is a cyclical structure where a relationship exists between an object or entity and itself. This useful and powerful type of relationship, where a parent can be a child of it self, is frequently used in relational modeling. However, it is almost ignored in the definitive UML texts often quoted in this article, and totally overlooked in the Paradigm Plus Object modeling tool. In fact, the term recursive does not seem to be a term used in the object paradigm. The recursive association is simply considered as any association with two interface specifiers.32 (A interface specifier is “a specification of the behavior required of an association class to satisfy the intent of the association. It consists of a reference to an interface, class or other classifier that specifies the required behavior,” In “relationalese” it is simply a verb phrase.

Figure 52 & 53 show recursive structures which depict the management hierarchy in an organization. These structures model each employee. Along with other pertinent attributes of the employee each employee occurrence in the table points to an occurance in the same table which contains data about the persons manager. In effect, contained within with one recursive relationship is an entire corporate hierarchy.

Figure 52 shows a recursive relation in IDEF1X. Figure 53 shows a recursive association in UML.

Figure 52

Dorsey and Hudicka document nine situations where recursive relationships/associations would properly model the business rule addressed. Each situation can be addresses almost equally in both IDEF1X and UML. 33 It is a powerful modeling tool in both paradigms.

32p 146 The Unified Modeling Language User Guide by G. Booch 1999 Addison Wesley

33p260 Oracle 8 Design Using UML Object Modeling by P. Dorsey & J.R. Hudicka 1999 Oracle Press Dorsey & Hudicka address UML in relation to Oracle’s data modeling methodology. However, the concepts can be easily understood in terms of IDEF1X.

Figure 53

Methods

One of the most, if not the most dramatic difference between the relational/IDEF1X paradigm and the object/UML paradigm is the introduction of methods or operations into the model topography. From day one of entity relationship modeling, we had to keep repeating to over to our selves that “data is not process and process is not data.” “Don’t let your model be affected by process.” I can’t tell you how many times I was reviewing models with applications programmers and had to remind them not to consider process when looking at a normalized ER diagram. With the addition of methods, and to a lesser extent embedded tables and arrays ,this has changed. Methods do not exist in the RDBMS paradigm and hence have no diagramming equivalent in IDEF1X. They are comparable, as pointed out earlier, to triggers and stored procedures. Figure 54 demonstrates how an object class contains both data attributes and processes which

Figure 54

act on the data.

IDEF1X VS IDEF4X VS DMT2

After this entire discussion you may ask; If there are so many parallels to draw between IDEF1X and UML, why bother having to learn a new language, why not create an extension of IDEF1X that can incorporate objects? There was an attempt, at one time, to extend IDEF1X and include object concepts. The object version of IDEF1X was

called DMT2 In Designing Quality Databases with IDEF1X Information Models 34 an entire section is devoted to it. Other than in that book, I have not heard or see anything more. I recently posted a message a popular data modeling and Erwin list server asking about it, and did not receive a single response from any of the hundreds of subscribers. I suspect that the emergence of UML smothered any will or attempt to make bring DMT2 into the lime light. Knowledge Based Systems, Inc. ( http://www.idef.com) has developed, what they call “the next generation IDEF methods”. These include, IDEF3 Process Flow and Object State Description Capture Method , IDEF4 ObjectOriented Design Method , and IDEF5 Ontology Description Capture Method. They have also developed automated tools to accompany these methodologies. It appears that they have generated only minimal interest.

34 p. 276 Designing Quality Databases with IDEF1X Information Models by T. Bruce 1992 Dorset House

Moving Attributes to Different Entities on Reverse Engineering

Terry Fitzpatrick, P.E.

Architect and Instructor

ALM Advanced Technology Group

COMPUTER ASSOCIATES INTERNATIONAL

Here's an undocumented trick I learned at www.infoadvisors.com <http://www.infoadvisors.com> . I put it together with keyboard macros. It's a big help for folks who use Report Browser to edit their models:

Attribute-level UDP's are handy for tracking source table and source column during reverse engineering. Storing the metadata as UDP values allows the modeler to move the attributes to different entities and even change the naming standards without losing track of the data source. However, there's a lot of typing to do if your model has several thousand columns. A keyboard macro program (Perfect Keyboard, Macro Express) can memorize a series of key presses and/or mouse clicks then repeat them upon some hot-key combination.

As soon as the reverse engineering is finished, and before moving any attributes, create a report with Table Name, Column Name, Source Table UDP, and Source Column UDP. Using one of the macro programs available, teach the macro to copy the Table Name and paste it into the Source Table UDP; then copy the Column Name and paste it into the Source Column UDP. Assign it to a hot key combination; e.g. <alt><u>. Now, just click on the next row in the result set, press <alt><u>, and watch the copy and paste happen at machine speed.

Note that Report Browser normally shows result sets grouped without duplicate names. This means that the table name will only appear once for the entire group of rows showing its columns. Here's the trick that makes it work. For any column that you want a value in every row (no grouping), rename the column header of a result set from this new report definition by inserting an exclamation point as the first character. Save the result set

as a Report View. Now, when you run the Report View, there will be an entry in every row of every column that you have prepared. This allows the macros to work.

Easy to do. You only have to do it once. It reduces TONS of typing to one mouse click and one keypress per row. This is the easiest way I've found for bulk entry of UDP values other than running SQL Insert's against the Dictionary Manager or ModelMart -- deadly dangerous, and it requires an extensive knowledge of the metamodel.

BPWIN IDEF External Agents

Doug Stone, Information Modeler

NUSCO (NU Service Co.) Berlin, CT.

New York Enterprise Modeling User Group

We miss our external agents that we use on DFD's that are not supported when using IDEF in BPwin. Sometimes we use DFD but other times we wish to use the IDEF for the ICOMs etc. but still would like external agents. Our trick is to create two activity boxes, a smaller superimposed on the larger, with the larger one hanging over to the right, so it

looks like a shadowed external agent. Then we draw arrows in from these to the real activities.

Macros Greater Than 130 Characters

Gary Gramm

When using macros in the domain editor to manipulate the column name (i.e enforce data naming standards) they can quickly get very long. The column name becomes, in effect, the macro code you create. In native ERwin this does not pose a problem. When placing the same model into Model Mart, if the length of the macro code is greater than 130 characters, MODELMART truncates it to 130 as it only supports a column length of 130, unlike native ERwin which is virtually unlimited, This renders the macro useless. To get around this you can do at least two things: 1. place the macro in an external text file and reference it in the column name space in the domain editor (not recommended - too slow and prone to problems if relocated) 2. Place the macro code in an unattached trigger template and reference the trigger

template name in the column name space in the domain editor. This is the approach I recommend (based on personal experience). However, there is a slight problem in that certain DBMS's (DB2) do not support triggers so ERwin greys out the trigger stuff in the server menu so you need to trick it too! In these cases, change the target server to one that does support triggers (e.g. SQL Server, create the trigger code, then switch it back to the original server type. Be aware though that you may have some data conversion problems in switching back and forth. I generally say

no to convert data type dialogue box and uncheck convert domain data types. Once you are back to 'normal' you still won't be able to see the trigger code, but it will be there and will work. This

is a case where what I consider to be a bug in ERwin actually turns out to be a feature! The last part of this tip is to remember to document, document, document what you have done. Sure as shootin' three months from now when someone has a question about how the names are being generated, you may remember macros, and you may remember triggers, but will have forgotten how to display them when they are 'invisible'.

Headers & Footers

ListMistress, ERwin Users Discussion Group

InfoAdvisors, Inc.

www.infoadvisors.com

Toronto, Ontario Canada

If you have changing information that would normally appear in a diagram header or footer, but you are frustrated by the time it takes to go to each Subject Area and change the header or footer, you might want to try the trick below.

Some background, first. I'm working on an standard data model that has release versioning numbers much like software (1.2, 2.1, 2.2 RFC1, etc.). I used to include this information in the page footers but every time there was a release I had to update those footers and headers in each of 50+ Subject Areas. With the trick below, now I only have to update it once.

1.Go to the Main Subject Area

2.Insert a text block with your base information (in my case, Version x.x, Copyright 2000 Mycompany, Inc.).

3.Move this text block to the upper left hand corner of the diagram.

4.Add this text block to every subject area in which you want this information to appear. You

need do this only once and when you create a new subject area. Because you placed this in the upper left hand corner of the main diagram, it will appear there in each new subject area.

When you need to update that information you can update it in one place and the change will appear everywhere. I use this technique for version numbers and copyright notices.

Using Subject Areas for Logical & Physical Displays

Karen Lopez

List Mistress, Erwin Web Board (www.infoadvisors.com)

InfoAdvisors, Toronto Canada

You can save yourself a whole lot of laying out, printing, and publishing time if you set up every Subject Area with two standard Displays: one named Logical and one named Physical.

By having to separate Displays for logical and physical views you will not have to spend hours re-laying out diagrams when you switch between the two displays. This will also allow you to easily select the proper displays when using WebPublisher.

Also, you can include the display macro word in the subject area headers so that each diagram is self-describing at print time. If you have the header set up as:

%File% -- %Display% / %SubjectArea%

your header will look like

DataModelFileName -- Logical / Vendor Maintenance

...just about all you need to know about the diagram you have printed. Add page numbers and timestamp to the footer and you are set.