----- Original Message ----- From: Gregory Woodhouse To: hardhats-members at lists.sourceforge.net Sent: 2006-04-10 7:03 AM Subject: Re: [Hardhats-members] Software Archetypes - single vs double systems
On Apr 9, 2006, at 10:12 PM, Lorie Obal wrote: Can anyone clarify/comment on the architecture principles called "archetypes" and "two-level" methodologies used in the openEHR project and openVistA? See: http://www.openehr.org/publications/archetypes/archetypes_beale_oopsla_2002.pdf The openEHR docs imply that this is a significant departure from previous methodologies. I'm trying to compare/contrast this with vistA in a comparison framework. Any enlightenment appreciated. More info on openEHR & archetypes can be found at: http://www.openehr.org/publications/archetypes/t_archetypes.htm -Lorie I'm really mot familiar with this approach (frankly, I find the presentation hard to follow, though the longer paper http://www.deepthought.com.au/it/archetypes/archetypes.pdf, is easier to follow), but the problem is certainly a familiar one. A significant problem with VistA (and just about any other EHR) is that domain specific knowledge is embedded into code or intermixed with operational data all over the place.VistA has attempted (with some success) to add a layer of abstraction using mechanisms such as protocols, templates, or even options. Personally, I think VistA would very much benefit from a mechanism such as this (though from the technical side, I still have questions). This is my (quite possibly incorrect) take on archetypes: In many ways, they are similar to the class models familiar from object oriented languages like Java or Python, but go further. Classes, such as Person, LaboratoryTest, or Organization are traditionally defined in terms of attributes and methods (functions). Attributes are well understood (a person has a name, test results must be measured in some units), but that's not enough, we need to be able to express how these concepts or classes are interrelated. In traditional object oriented development, this kind of knowledge (!) is encoded in methods written in a conventional programming language. For example, 4 and 5 may be members of the Number class, but to deduce that 4 < 5 (4 is less than 5), you need to use something like a compareWith method, which will most likely just be a wrapper around the usual comparison operator in the underlying language, so you're back to using code to express relationships. Of course, ultimately, you do need to resort to writing code (programmer's jargon for writing programs in some language), but the question is whether you should do it sooner rather than later. In mathematics, for example, we have the concept of a total order. A relationship < is a total order if 1. It is not true that a < a (irreflexivity) 2. If a is not equal to be (often written a != b or a /= b), then either a < b or b < a (trichotomy) 3. If a < b and b < c, then a < c (transitivity) These rules (axioms) represent what a programmer might call a constraint. Constraints are usually enforced by requiring some bit of code to evaluate to true. But there are problems with this approach: it is not very reusable, it is typically hidden deep in the implementation, and perhaps most importantly, it is difficult to reason formally about code. It is by abstracting away from the (very general) concept of relationship and asking how constraints can actually be built (constructed) that we are able to reason more formally about them. In fact, this is just what programming language types are. Starting with basic types like Number, Boolean, Character, etc. we can use familiar type constructors like Pair, List, Function to get types like Pair(Number, Number), List(Character) or Function(Number,r Number), and it turns out that types provide a very powerful method of reasoning about computer programs that can generally be performed automatically (which has obvious implications for program reliability). Perhaps a more familiar example of the same concept is what is sometimes called dimensional analysis in chemistry or physics. We're all familiar with Newton's second law, F = ma. Can a given quantity be a force? Well, we know that mass is measured in kilograms (dimensions of mass) and acceleration is measured in units of meters per second squared (with dimensions of length/time^2), so the dimensions of force must be just the product mass*length/time^2. Now, suppose I work out that some number, say T, is the elapsed time between the moment I get up in the morning (guess what time of day it is here) and the time I arrive at the office. The dimensions of T are time, so if I write an equation setting it equal to a force, then something has obviously gone wrong. But despite all its usefulness, dimensional analysis is still only a special case of the more general concept of type inference. Another example of a constraint is that there a 24 hours in a day (unless you're a doctor, in which case it is 36). How can this be expressed? There are obviously several choices, and the correct one depends on what you're doing. or example, if you are trying to schedule appointments, then you only have a fixed number of time slots in day, and at some point, you need to say "Sorry, but my schedule is full." Placing a limit like that is an example of going from the knowledge that there is only a fixed amount of time available in a day for seeing patients, to the information that you can only see (say) 12 patients. On the other hand, suppose you have some activity that should be performed at the same time (!) each day. If it is 5 am, how long will it be until it is 5 am again? Of course, the answer is 24 hours, but that is an example of information. At the knowledge level, what you know is that days are of a fixed length, and the "time of day" cycles from one day to the next. In mathematics, this is an example of a congruence, and it is yet something else that falls outside the domain of type theory. Programmers have long known to avoid "magic numbers" in their code and that it is important to parametrize. That's why we have configuration files and system parameters in VistA, and it is why template are often used when creating documents, but these techniques don't go a s far as they could. Archetypes represent an attempt to both formalize and extend the way we deal with these types of regularities or patterns. Interestingly, this is a goal that has alluded software engineers for a long time. One approach that is in vogue right now (particularly in object oriented analysis and design) is the use of design patterns. But ultimately, design patterns are ideas that are expressed verbally, and as such, they generally serve as a useful heuristic. Many people (including me) think we ought to be able to do better, and that we can do better. Gregory Woodhouse gregory.woodhouse at sbcglobal.net "Those who are enamored of practice without theory are like a pilot who goes into a ship without rudder or compass." --Leonardo da Vinci (1452-1519) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20060410/e93df129/attachment.html>
