MnM Minutes DM 20070621

Dynamic Model Meeting - June 21, 2007

Present

Loyd, McKenzie, Singureanu, Connor, Beeler, Gallagher, Harding, Spronk

Noted

• Agenda from Wiki
• Inventory of Present status of Dynamic Model
• Description of interactions is variable
• Have discussed alternate modeling
• Alan Honey has proposed an UML 2.0 model in a way that would support both messaging and SOA specifications
• Looked at examples from HDF that were used with the early SOA work to "align" with existing V3 interactions
• What is "mapping" between old V3 Dynamic Model and UML

Requirements

Group agreed to the following requirements for a revised representation of the dynamic model:

1. Ability to document all of the various paths (Lab domain poses a good challenge) displayed and documented in a single place
2. Need ability to reflect a primary "system role" in the "high level" diagram with references to other roles which may be prsented in a companion diagram
3. Ability to refine these through constraint to an implementable Sequence (collaboration) diagram that can drive tools for generation(?)
4. Determine where to represent trigger events, types (messages)
5. How to assert (claim) conformance to portions (constrained sub-kinds?) of the overall HL7 diagram

Working Proposition for Trial

The group agreed to the following forms to be trialed using the Lab domain in Ballot2007Sep. The trial will allow M&M to revise the proposition further in the Fall 2007 WGM.

1. Overview diagram: Use a high-level IHE-Transaction diagram ("Volume 1"-type Sequence diagrams) to summarize all of the interactions for a domain or topic
2. Use Activity Diagrams with a single swim lane using "dangling" operations (to show receiver references) to document the totality of requirements for a business process (such as "Order management")
   • Swim lanes represent definitions of application roles
   • Label, where appropriate, receiving activities as operations
   • Show the operation being invoked (by ID, not on where the operations resides)
   • Label the line going in/out (data pin) with the "type" of the response
   • Activity (behavior) that is the TE can have an end state, but need a TE ID, too.
3. Use Sequence Diagrams as the primary definition of Interactions (as operations and types)
   • The pipes are "application roles"
   • Reflect TEs as self-invocations on the initiating role
   • Interactions are defined as operations on the receiving role
   • Message name is actually an operation name (that may be re-used) in multiple receiving roles
   • For purposes of creating these diagrams, assume that all interactions are in deferred mode, thereby assuring that all messages are named by operations. (Subsequent invocation of immediate mode simply picks up the type from the deferred operation.)

Trial questions

1. Which form (Activity Diagram/Sequence diagram/both) is better:
   • for development
   • specific documentation
   • annotation
   • readability
   • confusability
2. Use experience to determine which is required vs allowed and which is desired vs disliked

Trial Definition

1. Use Lab domain in 2007Sep ballot(under Patrick Loyd's loyal efforts) to trial a combo of all three with support from Len Gallagher
2. Create a style guide from the experience
3. Need readers guide to the notation (Ioanna Singureanu)

Notes captured by GW Beeler, Jr.