|
|
A Visio for Enterprise Architects Primer for Experienced VisioModeler Users
by Scot Becker
INTRODUCTION
Microsoft®
Visio® for Enterprise Architects, as part of Microsoft Visual Studio® .Net Enterprise Architect Edition,
has been released. Picking up where Visio Enterprise 2000 left off, this new tool now supports all of the features of the InfoModeler/VisioModeler tools, including all graphical (ORM) symbols.
This article is intended to introduce this new tool to experienced InfoModeler/VisioModeler users. It is hoped that this article will allow the reader to quickly become acquainted with the way the new tool operates. For a more detailed treatment of the functionality of this new tool, please see the references section [1, 2, 3, 4, 5]. Readers new to any ORM tool are encouraged to start with that series of articles instead.
SOURCE FILES
AND PROJECTS
The first thing one should now about the VEA ORM tool is that in contrast to VisioModeler, it has separated the the model from the diagram. In other words, it is now possible to have a complete ORM model with no diagram drawn. Further, it is now possible to repeat the display of a fact more than once in the diagram.
ORM facts are now stored in what are called "ORM Source Models"1 (herein refereed to as the slightly briefer "Source Models"). These Source Models are then included into a "Database Model Diagram". You can think of this as being similar to the IMO file for the ORM diagram and the IMD file for the ER diagram, but there are some differences. It is actually easier, in my opinion, to think of the Database Model diagram as being the "project" that includes source models as it's components (and thus, I will herein refer to these documents as "Projects" for brevity). In this manner:
You can have more than one Source Model per Project and that a given Source Model can be referenced by more than one Project.
You can combine ORM Source Models with ER Source Models (if you must) in a single project.
You can continue to synchronize changes between the Project and the Source Models2.
The Project model now becomes the basis for DDL/database generation, much like the IMD file of VisioModeler.
You can still generate the ER representation in the Project file from the model in the Source Files. This is now called a Project "Build".
VISIO ENVIRONMENT
Like its predecessor, Visio Enterprise 2000, the VEA database functionality is still housed in the Visio drawing environment. The stencils that you use to create the diagrams are linked to code that actually does the model housekeeping (e.g. stores the fact, object, table, column definition information). Further, this add-on has various dialogs that should be familiar to VisioModeler users (e.g. the fact editor and the verbalizer).
In fact, everything about the application works like Visio would with the exception of context sensitive right click menus specific to the add-on as well as the addition of a "database" menu option which controls other features of the add-on (discussed in more detail later).
Being housed in the Visio Environment now gives modelers a nice feature: you can put any shape you want on the diagrams. In the VisioModeler tool, you were limited to only put model shapes on the diagram page. Further, these model shapes were restricted to be actual model components used to build the database (instead of informational shapes) and thus were subject to the model validation rules.
In the VEA database tool, one can put any shape one would like on the diagram and have no effect on the model validation rules (remember, the picture is no longer the model definition). So, you can include other software modeling shapes for reference/informational purposes with the diagram (e.g. a use case symbol showing what use case this data model fragment is used by), process notations showing how some rule might be executed, or anything else (e.g. a highly detailed picture of a router, if you really, really wanted to).
ORM SOURCE MODELS
Being astute data architects, you will probably want to start by making an ORM source model. To do so, you select "ORM Source model (US units)3" from the "Choose Drawing Type" dialog.
To turn on various windows, select "Database | View" and then the window you want to see (e.g. Verbalizer, Fact Editor, Object Types"). Note that the "Database Properties Page" is essentially the same as the context sensitive properties page from VisioModeler; when you have an object highlighted, you see that object's properties, when you have a predicate highlighted, you see the properties of the fact, etc. As a side note, one thing that you should notice right away is that the dialogs, although they contain the same properties as their VisioModeler counterparts, are much more user friendly; messy tabbed pages have been replaced by the contents listing on the left, etc.
The other main thing that you will notice is that the ORM stencil contains only three shapes: object, predicate, and the subtype arrow. In VisioModeler, you could apply all the other shapes (e.g. constraint shapes) graphically. In the VEA tool, all constraints are applied only via the constraint editor.
In fact, I generally have found that it is now easier to enter facts via the fact editor than by dragging out the object and predicate shapes. I was a big user of the graphics in VisioModeler and seldom used its fact editor. I am grudgingly getting used to the fact editor in VEA, although I still feel it was faster to lay out a model by using the graphics in VisioModeler. You may feel differently.
Object types and facts are now shown in the Business Rules window (Database |View | Business Rules). You can add a new fact by double clicking in the business rules dialog where indicated or by selecting "Database | View | Fact Editor..." This is mostly like the fact editor in VisioModeler and is discussed in depth elsewhere [1, 2, 3, 4, 5], so I will omit discussion of it here.
Once you have created a fact, you can select it in the Fact Types page of the Business Rules window and drag it out onto the page. Note that, as I mentioned earlier, you can drag a given fact out as many times as you want, wherever you want and it will have no impact on the model per se (only changes the "picture"). This is a nice feature, in my opinion. I usually paginate my pictures into smaller subject areas/topics. In those subsets, it is often nice to refer to a major fact or to the fact that spawned an objectified predicate. In VisioModeler, you could not do this without violating the model validation rules (e.g. "duplicate" fact error). In the VEA tool, you can "repeat" facts all you want (graphically anyway, you still cannot create duplicate fact definitions).
You can drag object types to the diagram by either selecting it from the Object types page of the Business Rules window or from the Object Types window (Database | View | Object Types).
All constraints are either added from the Fact Editor or from the new Constraints dialog. If I am adding an internal constraint (one that affects only one fact, e.g. a simple uniqueness or mandatory constraint), I will do it from the constraints tab of the fact editor. However, if I am adding a constraint that affects more than one fact (e.g. exclusion, subset, equality, external uniqueness, et al.) I will select the affected facts, and then choose "Database | Add Constraint" to bring up that constraint editor. As the constraint editor is discussed in detail in [1, 2, 3, 4, 5], I don't want to go into it too much here except to say that it is easier to enter constraints this way than in VisioModeler, especially for set comparison constraints. For example, you no longer have to select role sequences and so forth (I always hated that).
Notice that once the affected facts are dragged onto a page, you get the constraint symbols as well; the new tool now supports all graphical constraints. This was the major problem with the Visio Enterprise 2000 implementation of the tool and has now been (thankfully) resolved.
There are some minor differences in how the constraints are displayed. Subset and equality constraints now have additional notation in the "constraint bubble". Like the exclusion constraint, which always had an "X" in the bubble, equality constraints now have a bubble with an "=" in it and subset constraints now have a "ê" in the bubble. I think that you will find this easier to read.
The other minor difference is that mandatory disjunctions are now shown with a constraint bubble (and the dot in it) attached to the affected roles rather than the object connector lines coming together to the same mandatory dot on the object. This too, is easier to read, in my opinion.
Also note that the "life buoy" symbol is now supported for exclusive-or constraints. Recall that an exclusive-or is the combination of a mandatory disjunction and an exclusion constraint across the same roles. This "life buoy" symbol is the mandatory disjunction symbol visually superimposed on the exclusion symbol. Alternately, you could say that it is the exclusion constraint with a dot in it. You can separate these two symbols by right clicking on the "life buoy" and selecting "Split X/OR Constraint". This will display two constraints, one for the exclusion and one for the mandatory disjunction. As a side note, I prefer this over the superimposed version because there are really two business rules in an exclusive-or constraint; and they both deserve to be thought about separately.
THE WHERE-TO-FIND-WHICH-PREFERENCE SECTION
We are now coming to the section that inspired this article. The various features, preferences, and options VisioModeler users have gotten used to are still largely there... but in different spots. In this section, I hope to alleviate frequently asked questions such as "where did Feature X go?"
The applicable application preferences in VisioModeler can be found at "Database | Options | Modeling..."
To configure which database driver you wish to use for physical generation and data type display, select "Database | Options | Drivers..." This is all pretty much the same as its VisioModeler counterpart. However, note that is includes support for more recent database versions (e.g. MS SQL Server 2000) and seems to have dropped DDL generation support for Sybase (you can select it as a driver, but it won't generate DDL).
The VisioModeler "Document Options" dialog can now be found at Database | Options | Document..." Recall that it is in this dialog that you can control various naming features (abbreviations, prefixes, suffixes, lengths, etc.)
As a tip to those of you who will be importing VisioModeler IMO's into the new tool, you will notice that the new tool doesn't automatically import your abbreviations settings. The workaround is:
1) Open the IMO in VisioModeler, right click on the white space of any page and select "Document Options".
2) Select the "Abbreviations" tab.
3) Click on the upper left square to highlight the whole abbreviations grid and type CTRL+C (copy).
4) In VEA tool, select "Database | Options | Document..." and then the "Abbreviations" tab.
5) Click on the upper left square to highlight the whole abbreviations grid and type CTRL+V (paste).
LAYOUT OPTIONS
Finally, some of the layout options have changed/are implemented differently in the VEA tool.
Predicate orientation (e.g. reverse roles, flip orientation) are controlled by the Visio shape Rotation options found in the "Shape | Rotate or Flip" menu options. Notice that the text orients correctly when you rotate a predicate and that if you flip a predicate, the direction you should read the sentence is indicated with a "<<" (i.e. to indicate that you should read from right to left).
Forward and inverse readings on predicates are displayed if the text is supplied and, unlike VisioModeler, you cannot choose to supply a reading but hide it from view.
You'll notice that there are no options indicating if the predicate text should be inside, above, or below the predicate. However, all text external to a shape can be freely positioned anywhere on the page. To do this, highlight a shape (say, a predicate or a nested predicate) and see that there is a yellow "handle" in the text. If you click and drag that handle, the text moves with it.
The graphic options for Object Types in VisioModeler were to limit the number of value/range entries (e.g. a Sex Code limited to "M" or "F") and to control their position. The position of the value/range options is controlled as discussed in the preceding paragraph. However, you will see no option in the database properties pages to control the number of entries it displays. This number was implemented as a shape property. To set it, right click on the object and select "Shape | Custom Properties..." and you will see a dialog box for controlling the number of entries displayed on the diagram (it defaults to 5).
CONCLUSION
I hope that I have given experienced VisioModeler users a helping hand in beginning to use the new tool. As a conclusion, I'd like to say that although the previous version (Visio Enterprise 2000) of the tool left much to be desired, this new version meets all of the needed functionality that was in VisioModeler. I have been using the tool in production environments since its beta; it is working fine "in the real world".
For those of you who dismissed the Visio platform as a viable tool due to the missing features in Visio Enterprise 2000, I encourage you to give this new version a try.
FOOTNOTES
1) There is a similar concept ("ER Source Models") for ER diagrams, but it is hoped that the astute readers of this article will prefer to use the ORM source models instead.
2) However, there seem to be some performance issues with synchronizing from the Project (ER) back to the Source (ORM) files. For that reason (not to mention the fact that it is conceptually cleaner to build from the ORM to the ER) I recommend that you synchronize from the Project to the Source as little as possible.
3) Presuming you are in the US and/or wish to see the ruler and other page properties in imperial units of measure, otherwise, you can select "ORM Source Model (Metric Units)".
REFERENCES
1) Halpin, Terry, "Microsoft's New Database Modeling Tool, Part One", www.orm.net
2) Halpin, Terry, "Microsoft's New Database Modeling Tool, Part Two", www.orm.net
3) Halpin, Terry, "Microsoft's New Database Modeling Tool, Part Three", www.orm.net
4) Halpin, Terry, "Microsoft's New Database Modeling Tool, Part Four", www.orm.net
5) Halpin, Terry, "Microsoft's New Database Modeling Tool, Part Five", www.orm.net
This is a revised version of an article originally published in Issue 21 of the Journal of Conceptual Modeling.
Microsoft Visio and Microsoft Visual Studio are registered trademarks of Microsoft Corporation.
|
|
 |