Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Intent/Use Cases"

(Removing all content from page)
Line 1: Line 1:
Intent can be used in a lot of use cases, from Literate Modeling to ALM. We will try to present here typical use cases of Intent.
 
  
= Use Case 1 : Doc Driven Development =
 
 
Alice works in a ten people team in charge...
 
One of their customers wants a new feature (mostly IHM) : a ''customer page'' allowing to search through all customers with several parameters and filters.
 
 
Of course, Alice could directly modify the code, and Intent will then detect synchronization issues and propose quick-fixes for synchronizing code doc with code, but as we will see Doc Driven Development presents some major advantages.
 
 
== Documentation & metamodels ==
 
 
Presentation of the Intent document (meta-model, structure) used by the team to capture design choices.
 
 
== Step 1 : Getting the parts to update ==
 
 
In a regular development process, Alice would have had to determine the components to update, without many help. How many of you have used the Eclipse's ''Open Type'' wizard and search for Java Classes with a name that may indicate that it is doing what you are searching for ?
 
With Doc Driven Development, you first have to determine what parts of the documentation have to be changed/deleted/created.
 
 
To do so, Intent provides tools to enhance searches. Alice has two solutions :
 
* searching through the documentation as if it was a ''paper doc'' :
 
from the table of contents, she identifies the chapters/sections related to UI features. In some cases, it can be really quick, especially if the documentation has been well-structured.
 
* searching for all document parts related to a model element :
 
if Alice has some basicall knowledge of the meta-model, she should know that the UI feature should be added .... If she has not, she will have to quickly read the ''meta-model overview'' section.
 
 
== Step 2 : updating doc ==
 
 
Adding feature + justify and explain intents
 
what she had in mind before reading the doc was incorrect
 
 
== Step 3 : validation of the new feature ==
 
 
Automatic and useful : Alice made an design error that would have cost her a lot if she was directly modifying code. Quick-fix
 
 
== Step 4 : synchronization ==
 
Quick-fix and there it is
 
 
== Conclusion ==
 
By adding a few lines in the ''Document'', and '''justifying''' her design choices, Alice has quickly obtained a skeleton of the code, and is sure that her feature is valid, properly documented and can be understood by future readers who will have to maintain this feature. A lot quicker than ...
 
 
= Intent as a environment synchronizer ==
 
 
Sharing TP
 
 
= Intent & ALM =
 

Revision as of 07:19, 1 February 2011

Back to the top