Month Year

October 1998

Issue: 5

Editor's Notes: Now 99% Rant Free
by Scot A. Becker

UML Data Models from an ORM Perspective (Part 5)
by Dr. Terry Halpin

This paper is the fifth in a series of articles examining data modeling in the Unified Modeling Language (UML) from the perspective of Object Role Modeling (ORM). Part 1 discussed historical background, design criteria for modeling languages, object reference and single-valued attributes. Part 2 covered multi-valued attributes, basic constraints, and instantiation using UML object diagrams or ORM fact tables. Part 3 compared UML associations and related multiplicity constraints with ORM relationship types and related uniqueness, mandatory role and frequency constraints, as well as how associations may be instantiated. Part 4 contrasted ORM nesting with UML association classes, ORM co-referencing with UML qualified associations, and ORM exclusion constraints with UML or-constraints. Part 5 discusses ORM subset and equality constraints, and how these may be specified in UML.

Issues in Dealing with COBOL Data Structures
by Pat Hallock

As with most of my articles, which are motivated from issues I face in the field, this one occurs frequently. This article arises from difficulties faced when attempting to convert legacy data systems, maintained via COBOL code, to a new system. While COBOL was my initial programming language, I managed to avoid several of the problems addressed in this article because even in those days I used NIAM, a precursor to ORM, to design my data structures. I will present only a handful of issues, however, they illustrate why converting data structures can be complicated. While many mapping tools exist, I believe it would be difficult for a COBOL-to-relational-database tool to resolve all of these issues. I suppose they could get the basic structure correct, but the constraints at the conceptual level would be very difficult. Sometimes, I have trouble doing this as well.

Dr. John K. Sharp
Analysis Problem
Solution for Last Issue's Analysis Problem
Where is the "Engineering" in "Information Engineering"?

Accountability is the core parameter that allows an engineering discipline to consistently provide value to a corporation. Each engineering discipline has its own terminology and rules that must be understood and then followed. Accountability is enforced through engineering procedures that assign responsibilities to skilled participants during the phases of the production lifecycle.