|
|
Task/Activity Modeling in CMB
|
|
|
![Screen_Shot_2016-07-25_at_5.13.01_PM](/uploads/24f6771319bb97898dcb5a50350291a6/Screen_Shot_2016-07-25_at_5.13.01_PM.png)Task/Activity Modeling in CMB
|
|
|
===
|
|
|
A major missing piece in CMB V4 is the ability to explicitly define a task/activity. In V3 things were pretty simple - ModelBuilder could only be used to define a simulation while in V4 ModelBuilder's task of Simulation Construction is loosely modeled:
|
|
|
|
... | ... | @@ -61,8 +61,8 @@ Although the main workflow focus is for things CMB does, we should design the wo |
|
|
I think this question is best addressed after one or more use-cases have been examined. But to start, I would vote for an approach like Ansible, which uses a declarative specification (yml) at the top level, that can invoke programs and procedural scripts when processed by the Ansible runtime. In our case, for example, a user could "initialize" a new workflow by specifying a yml file to the workflow manager.
|
|
|
|
|
|
---
|
|
|
# from Yumin
|
|
|
### xml
|
|
|
# comments from Yumin
|
|
|
### xml prototype for workflow
|
|
|
```xml
|
|
|
<SMTK_AttributeManager Version="1">
|
|
|
<!--********** Workflows ***********-->
|
... | ... | @@ -88,6 +88,6 @@ I think this question is best addressed after one or more use-cases have been ex |
|
|
</Workflow>
|
|
|
</SMTK_AttributeManager>
|
|
|
```
|
|
|
### mockup
|
|
|
### UI mockup
|
|
|
|
|
|
![Screen_Shot_2016-07-25_at_1.31.47_PM](/uploads/2321a2d60ae084b3562d0f964c46eacd/Screen_Shot_2016-07-25_at_1.31.47_PM.png) |
|
|
\ No newline at end of file |