Hi guys, If I were to snip in my two cents...
The further we (GastrOS team) delve into GUI generation from templates/archetypes, we're increasingly facing the question: "where is the line between the domain model and program behaviour?" I have a feeling that especially in modern software systems (clinical ones included) there is an increasing expectation for rich user experiences and basically a movement away from rigid CRUD-type interactions (where the choice of GUI elements are effectively driven by the underlying data model) to a more fluid set of interactions that essentially puts the user in charge (so almost every piece of functionality is accessible from another in one or two steps). So what this means in terms of modelling is that often having the domain model defined is nowhere near enough to define the complete set of program behaviour (and hence the working program itself). And often the two (model and behaviour) are intricately linked, especially from the user's perspective. In fact, my experience and intuition is that users nowadays tend to think more in terms of what they want the program to DO, than what the program should HAVE. So things like "I want it to pop up a dialog here, when I click this, and when I'm on this form I want to be able to edit this and that". What we have tried to do so far was to effectively include all of this "interaction" stuff into the template (as annotations) so as to retain the ability to completely and dynamically generate a fully functioning GUI from the model alone. So far we have managed it successfully, largely thanks to the relatively structured and uniform degree of user interaction mechanism that's sufficient for our system requirements. But yes, if we were to try building say a PMS just from our models, that'd be pretty crazy. I do think it's wise to separate the "behaviour" stuff out of the model, and come up with a solid formalism for expressing it. As Seref and others point out, the more we clutter the model with program-specific concepts, the less reusable they would be across different usage scenarios. But I think we do need to probe deeper into the question of, again, what's the distinction between data model and behaviour? In ADL we already have mechanisms for expressing ceratin kinds of constraints, and there would be a natural expectation for the GUI to filter out the user interactions so as to prevent the model from violating these contraints. E.g. disable an input field at certain times. So is that considered behaviour, or part of model? That's the kind of distinction I'm talking about. I hope I've articulated the issue clearly enough. all the best, Hong Yul On 29/03/2011 4:23 p.m., Koray Atalag wrote: > Hi Tom, others > I now see all points. I really like the idea of specialised templates > used for GUI hints (as well as for other usual purposes) and that we > have the usual shared templates without any of this. I am happy to put > our contributions and encourage others to do so. The thing is many of > the design decision we made were influenced by our lead developer, Dr. > Yang, who didn't really know much about openEHR in the beginning. But > he ws able to relate many existing software engineering practices and > theory to this world. I thing we need to engage more people who are > are really objective in this space. > Cheers, > -koray > ------------------------------------------------------------------------ > *From:* openehr-technical-bounces at openehr.org > [openehr-technical-bounces at openehr.org] On Behalf Of Thomas Beale > [thomas.beale at oceaninformatics.com] > *Sent:* Saturday, 26 March 2011 2:05 a.m. > *To:* openehr-technical at openehr.org > *Subject:* Re: GUI stuff in AOM/ADL? (Was: future ADL-versions) > > On 25/03/2011 03:05, Koray Atalag wrote: >> >> Hi Eric, good points...As you may remember we had this discussion on >> this list not so long ago and I don?t remember any action taken after >> that. I guess we should take lead and come up with some proposal. >> Perhaps it?d be good to have a wiki space - but I want to repeat >> myself: someone from core group must guide the group and provide >> early feedback whether we are on the right track or not. >> > > To all interested in this area: in terms of innovation and ideas, the > people in this discussion are the 'core group'. Advice from myself > and others historically working on the specifications is as I have > already posted, i.e. IMO, stick to the separation of concerns with > respect to artefacts. I personally would not include GUI-related hints > in templates either, because there will eventually emerge some > templates that are widely shared, e.g. national and international > (e.g. European) discharge summary, referral, e-prescription etc - but > whose GUI models are very unlikely to be shared. On that view of > things, you don't want to have to revise such a published resource due > to some particular GUI directives buried inside it. This doesn't mean > that the ADL (abstract or XML form) formalism can't be used, but I > still think a separation of the pieces will make dependency and > release management a lot easier. Erik may be right: if the GUI hints > can be expressed in a template, then by definition, it can be done in > a specialised template, and that can clearly be local. > > At the moment, we have to consider this area as 'industrial research', > and I for one would encourage all experimentation to be published and > flagged on this list, as a way of getting us all on the same page with > respect to lessons being learned. > > - thomas beale* > * -- Hong Yul Yang Research Programmer Department of Computer Science The University of Auckland Office (tamaki): 731-339 Phone: +649 373 7599 x88237 http://www.cs.auckland.ac.nz/~hongyul -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.openehr.org/mailman/private/openehr-technical_lists.openehr.org/attachments/20110403/0b602a14/attachment.html>
