UCMElementsBehaviour - JUCMNAV/projetseg-update GitHub Wiki
What do we have to do?
Mandatory - Urgent and Mandatory - Medium (and some lower priority stuff taken into consideration)
Note: this document is under construction.
List of elements
- Map
- Rename
- Title is to be more verbose; might be removed.
- UCMModelElement
- Add
- Move
- Delete
- Rename in properties view
- Change description in properties view
- Rename in editor(label)
- Move Label
-
Component
- Resize
- Bind to other component
- See Test Bind Unbind
- Unbind from other component
- Unbind enclosing elements
- We manipulate references to the same component.
- Dropdown in properties
-
Responsibility
- We manipulate references to the same Responsibility.
- Dropdown in properties
- 1 in, 1 out.
- We manipulate references to the same Responsibility.
-
Path
- Collection of NodeConnections
- Graph traversal functions must be supplied; not in model
- See Interaction Scenarios
- Path direction should be displayable.
- Must discuss deletion UI with forks/joins/etc.
- NodeConnection * can have conditions
- And Join
- UI discussed, to be formalized.
- visual appearance depends on path orientation
- 2-N in, 1 out
- And Fork
- UI discussed, to be formalized.
- visual appearance depends on path orientation
- 1 in, 2-N out
- Or Join
- UI discussed, to be formalized.
- visual appearance depends on path orientation
- Guard condition: string
- 2-N in, 1 out
- Or Fork
- UI discussed, to be formalized.
- visual appearance depends on path orientation
- 1 in, 2-N out
- Empty Point
- Can be converted into a model element.
- Mandatory-Low: Can be connected to timer, wait, start.
- End Point
- Can be connected to timer, wait, start
- Can be merged with a start point
- can have conditions
- 1 in, 0 out.
- Start Point
- Workload: ?
- can have conditions
- can be merged with an end point
- 0 in, 1 out
- Wait (Waiting Place)
- Can be connected to an end point.
- can have conditions
- 1 in, 1 out
- No abort/timeout paths.
- Timer
- Like wait
- Has possible timeout path.
- Stubs
- Dynamic or Static
- 1-N in, 1-N out
- interior plugins do not have to have the same amount of in/outs
- Must be able to create plugin.
- creates a new map
- positions editor at a new navigationlocation
- from contextual menu
- from views
- must be able to view plugin
- double click in editor
- from views
- positions editor at a new navigationlocation
- add plug-in
- if static and has no plug-ins, must be able to select maps from a list of possibilities
- if dynamic, should be able to add a map from al ist of possibilities to a list of plugins
- during execution, stub binding conditions are examined to know which plug-in to be used
- remove plugin
- inverse of previous operations
- rename plugin
- a plugin is just another map.
- bind plugin
- wizard or property page
- activated by contextual menu on stub
- select a plugin
- match stub inputs with plugin start points
- match stub outputs with plugin end points
- numbers do not need to match
- TBD: UI
- Connect element
- Invisible
- NodeConnection to EndPoint
- (Mandatory-low allows connection to Empty node as well)
- NodeConnection to Start/wait/timer
Different behaviour
- Binding/unbinding
- Components (all types)
- Path elements in components
- Resizing
- Components (all types)
- References andactual element
- Components (all types)
- Responsibilities
- Conditions
- start
- end
- wait
- timer
- or fork
- Possible connection to an end point. (UML: creates connect node)
- waiting point
- timer
- start point
- Mandatory-low: Possible connection to a blank point. (UML: creates connect node)
- waiting point
- timer
- start point
- Possible merger
- start with end (creates empty node)
- Timeout paths
- timer
- Path elements that end splines versus those that don't.
- I don't think connections should end splines as they are simply "connected".
- a spline passing through a timer should not stop the spline; even if a timeout path exists (which is its own spline)
- stubs/forks/joins end splines, rest should not.
- Deletion
- General concepts discussed. Must be formalized.
Behaviour that should be abstracted into "roles" known by the ?facade?
- Path behaviour
- with respect to the spline
- with respect with in/outs path numbers
- with respect to connections with end point
- with respect timeout/abort paths
- the rest can be, for now, derived from class hierarchy, unless
further analysis of future goals provide different clues.
- bind/unbind; only to elements that can be resized.
- high level plugin must be special cased because is so different from rest and has deep structural implications
- guard conditions
- merger is a bit like deletion
- what might be interesting is a 2d matrix combining all elements with all other ones; for each cell, list allowed behaviour when many are selected.
-- Main.JasonKealey - 15 Mar 2005