 |
privacy |
||
|
Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2005-09-02Navigating Data Models Yet Another Data Model. As I dug my way down to the bootstrap of TROST: Templates for Open-System Trustworthiness, it became increasingly clear that pattern languages are an important feature of the protocols by which evidence for trustworthiness is conveyed. TROST patterns are in the area of performance and processes in the cycle of learning and improvement that system producers and adopters are mutually engaged in. Looking at system engagement/participation makes for a different kind of pattern than is employed for object-oriented design and programming. Patterns for processes and activities are more akin to the Christopher Alexander view of pattern languages as applied to activity around habitat and the structuring of spaces for performance and civil use. Furthermore, the artifacts are different in the domain where TROST applies. I have in mind the documents, records, and software-deployment artifacts that have digital form, print form, and serve as instruments of communication and support among producers and adopters. In building up TROSTing.org, I began to see numerous patterns in the way that I organized and coordinated web materials and also other forms such as documentation templates and packages of code and the procedures used to confirm the software. How can one characterize and convey those artifactual patterns in a way that fits the pattern language spirit? I automatically turned to a form of data-model diagramming that I have been using on-and-off since the mid 1970s as a way of abstracting what I was observing. At the time, I called these information-system models. Humbled somewhat by time and experience, I now refer to the approach as one of navigational data models. Since there is near-unanimous agreement that the world doesn’t need yet another data model, I have seriously considered why I keep returning to these rather than adopting ones that are already well-known. It is certainly a matter of familiarity and preference: I invariably use navigational data models as a way to explain other data models to myself. These are the models that come to mind naturally in my thinking. That is probably not how they will strike others who’ve internalized one of the well-known modeling approaches. Here, for example, is how I portray a classic example in data modeling: the organization of manufacturing product data about parts that may themselves be assemblies used as components of larger assemblies: Although I’ve given the biggest reason — personal preference — for pursuing this approach with TROST patterns, there are features of it that I am quite unwilling to give up:
The key test is whether it is easy to gain a sense of the import of one of these diagrams without first having to know how to create it. I don’t think it takes much to to get the sense of these diagrams. Of course, I’m not a fair test for achievement of that. I will have some illustrations in a variety of pattern that should test that hypothesis nicely. I’ll announce a catalog of examples when there are more. Then we can see how readily-understandable the diagrams are in the descriptions of commonly-used patterns.
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |