|
|
1.1.1 Digging down into the bootstrap of TROST, it became increasingly clear that pattern languages are an important feature of the protocols by which evidence for trustworthiness is conveyed. TROST patterns arise in the performances and processes in the cycle of learning and improvement that system producers and adopters are mutually engaged in.
1.1.2 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 applied to habitat creation and structuring of spaces for performance and civil use.
1.1.3 Furthermore, the artifacts are different in the domain where TROST applies. The artifacts consist of documents, records, and software-deployment materials that have digital and printed forms and that serve as instruments of communication and support among producers and adopters. Code is a small part of it at this point.
1.1.4 As TROSTing was built up, numerous patterns stood out in the way that web materials are organized and coordinated. Some of these were old practices, but when revisited as patterns for trustworthiness, my perspective shifted and I became much more deliberate in their application. This also applied to other forms such as documentation templates and packaging of code and the procedures used to confirm the software also. As part of the bootstrap process, this material is now being revisited to have the patterns maintained as they have come to be recognized.
1.2.1 How can one characterize and convey those artifactual patterns in a way that fits the pattern-language spirit?
1.2.2 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 diagrams as navigational data models.
1.2.3 Since there is near-unanimous agreement that the world doesn’t need yet another data model, I have seriously questioned 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.
1.2.4 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:
1.2.5 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 diagrams are permitted to be incomplete and may be used for multiple patterns that, in practice, are manifest in a single, blended situation: pattern fusion.
- It is valuable to recognize how keys — identifying data elements — for entry into navigational material may have local and subordinated scopes of visibility.
- The identification of relationships by naming the converse perspectives of the two associated data entities is important (bonus: the associated data-entity types don’t have to be connected by lines and arrows – the dashed connections in the figure are solely for convenience)
- There are some useful practices around nomenclature that disrupt the tendency to confuse the data model with (non-data) entities that instances of the model are intended to carry data about. (Notice this in how the text at the beginning of 1.2.4 contrasts with the nomenclature and type style used in the diagram.)
1.2.6 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.
- i050809b: Navigational Data Model Diagramming [latest]
- i050809c: Navigational Data Model Diagramming 0.75
- i060809b: Navigational Data Model Job Jar & Diary
- see also:
- Professor von Clueless: Navigating Data Models (2005-09-02)
|
|
created 2005-08-21-16:31 -0700 (pdt) by
orcmid |
You are navigating