This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Dynamic Model Agenda June 21 2007"
Jump to navigation
Jump to search
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | ====Thursday, June 21st | + | ==Dynamic Model Agenda :: June 21-22, 2007 Boston== |
| + | |||
| + | ===Call information=== | ||
| + | |||
| + | *https://www.gotomeeting.com/join/326498289 | ||
| + | **Conference Call: Dial (605) 772-3715, access code 812-364-851 | ||
| + | **Meeting ID: 812-364-851 | ||
| + | |||
| + | ===Thursday, June 21st=== | ||
---- | ---- | ||
| − | + | ====(Q1) 9:00-10:30 am EST ==== | |
'''Inventory of where we are with the dynamic model''' | '''Inventory of where we are with the dynamic model''' | ||
| − | *We will try to compile a comprehensive list of needs and issues with the current | + | *We will try to compile a comprehensive list of needs and issues with the current behavioral modeling. |
| − | *UML ''Activity diagrams'' were deemed too complex when they were suggestes as a means for documenting system behavior | + | *UML ''Activity diagrams'' were deemed too complex when they were suggestes as a means for documenting system behavior |
| + | *(Rene) I won't be present during Q1 (a conflict with the tail end of a conference I'll be attending). During discussion of the dynamic model in INM an action item was created to explore the use of the same diagramming method as used by IHE in its profiles, i.e. a high level Transaction Diagrams (in volume 1), detailed in one or more Interaction Diagrams (with optionalities, used in volume 2 of a profile). This method seems to work for IHE, so IMO we could/should let ourselves be inspired by its approach. | ||
| − | + | ====(Q2) 11:00-12:30 am EST ==== | |
| − | |||
'''Services and Application roles''' | '''Services and Application roles''' | ||
*In this session we will discuss how we relate operations (in interfaces) to interactions. | *In this session we will discuss how we relate operations (in interfaces) to interactions. | ||
| Line 15: | Line 23: | ||
*The common denominator between service specifications and application roles may be to represent both as [http://etna.int-evry.fr/COURS/UML/notation/notation5b.html#5.10 interfaces] | *The common denominator between service specifications and application roles may be to represent both as [http://etna.int-evry.fr/COURS/UML/notation/notation5b.html#5.10 interfaces] | ||
| − | + | ====(Q3) 1:00-2:30 am EST ==== | |
:'''Identify artifacts that will affected by changes''' to dynamic modeling notation, style guide, or methodology. | :'''Identify artifacts that will affected by changes''' to dynamic modeling notation, style guide, or methodology. | ||
*Documenting and specifying complex interaction patterns | *Documenting and specifying complex interaction patterns | ||
*Look for consensus on the mapping developed in the previous session | *Look for consensus on the mapping developed in the previous session | ||
| − | + | ====(Q4) 3:30-5:00 am EST ==== | |
'''Complex interaction patterns''' | '''Complex interaction patterns''' | ||
| Line 27: | Line 35: | ||
*We will not go into the solution for run-time representation of system (e.g. WS-CDL, WS-BPEL). | *We will not go into the solution for run-time representation of system (e.g. WS-CDL, WS-BPEL). | ||
**We will focus on the design time representation of interfaces not at the runtime realization. | **We will focus on the design time representation of interfaces not at the runtime realization. | ||
| + | **(Rene) Any design will also have to be implementable in low-tech environments such as MLLP over TCP. That's just meant as a reality check we have to keep in mind, not as an encouragement to shy away from using services. | ||
| − | + | ===Friday, June 22nd=== | |
---- | ---- | ||
| − | + | ====(Q1) 9:00-10:30 am EST ==== | |
Develop approaches to "make it real" | Develop approaches to "make it real" | ||
| Line 39: | Line 48: | ||
*Select the notation, tooling, and implementation technology | *Select the notation, tooling, and implementation technology | ||
| − | + | ====(Q2) 11:00-12:30 am EST ==== | |
'''Open session''' | '''Open session''' | ||
| + | |||
| + | --[[User:Ioana13|Ioana13]] 15:54, 15 June 2007 (CDT) | ||
Latest revision as of 12:27, 21 June 2007
Contents
Dynamic Model Agenda :: June 21-22, 2007 Boston
Call information
- https://www.gotomeeting.com/join/326498289
- Conference Call: Dial (605) 772-3715, access code 812-364-851
- Meeting ID: 812-364-851
Thursday, June 21st
(Q1) 9:00-10:30 am EST
Inventory of where we are with the dynamic model
- We will try to compile a comprehensive list of needs and issues with the current behavioral modeling.
- UML Activity diagrams were deemed too complex when they were suggestes as a means for documenting system behavior
- (Rene) I won't be present during Q1 (a conflict with the tail end of a conference I'll be attending). During discussion of the dynamic model in INM an action item was created to explore the use of the same diagramming method as used by IHE in its profiles, i.e. a high level Transaction Diagrams (in volume 1), detailed in one or more Interaction Diagrams (with optionalities, used in volume 2 of a profile). This method seems to work for IHE, so IMO we could/should let ourselves be inspired by its approach.
(Q2) 11:00-12:30 am EST
Services and Application roles
- In this session we will discuss how we relate operations (in interfaces) to interactions.
- Map our interaction concepts to operations and interfacesrespectively
- The common denominator between service specifications and application roles may be to represent both as interfaces
(Q3) 1:00-2:30 am EST
- Identify artifacts that will affected by changes to dynamic modeling notation, style guide, or methodology.
- Documenting and specifying complex interaction patterns
- Look for consensus on the mapping developed in the previous session
(Q4) 3:30-5:00 am EST
Complex interaction patterns
- In this session we will look at some concrete examples
- Service orchestration vs. choreography
- We will not go into the solution for run-time representation of system (e.g. WS-CDL, WS-BPEL).
- We will focus on the design time representation of interfaces not at the runtime realization.
- (Rene) Any design will also have to be implementable in low-tech environments such as MLLP over TCP. That's just meant as a reality check we have to keep in mind, not as an encouragement to shy away from using services.
Friday, June 22nd
(Q1) 9:00-10:30 am EST
Develop approaches to "make it real"
- The methodology will be linked back to the product lifecycle management project in the HDF
- Select the notation, tooling, and implementation technology
(Q2) 11:00-12:30 am EST
Open session
--Ioana13 15:54, 15 June 2007 (CDT)
