Goal modeling and analysis techniques help stakeholders consider possible tradeoff alternatives in their requirements and answer “what if” questions about those alternatives. Software projects today exist in an ephemeral state, and current goal modeling approaches do not answer questions about model evolution and changes in actors' intentionality. We have developed a technique [8] that allows stakeholders to explicate the dynamic nature of their intentional elements, and ask questions about how this dynamicity affects project outcomes. In this paper, we present GrowingLeaf , a new web-based goal modeling and analysis tool that implements this technique for iStar models. We discuss its support for modeling, simulation, and static analysis and illustrate it for a small example of making lunch.
Goal modeling and analysis techniques [
Running Example: Jake is interested in having a quick and inexpensive lunch. Generally, his lunch options consist of either making a sandwich or buying fancy pizza. If he makes a sandwich, he has to prepare one with bread and meat. Currently, Jake has bread that will expire soon, but does not have any beef or chicken, his favourite sandwich meats. With this information, Jake wants to answer the questions (1) “given that he currently has bread and can buy other items, what possible scenarios exist?”, and (2) “what possible scenarios exist that eventually result in him having lunch?”.
We have developed a technique [
In the remainder of this paper we give an overview of the tool and its features
(in Sect. 2), present the architecture (in Sect. 3), and discuss the tool’s usability and
development decisions/challenges (in Sect. 4).
1 See [
Copyright © 2016 for this paper by its authors. Copying permitted for private and academic purposes.
Using our running example, we describe how GrowingLeaf is used to both draw
iStar goal models and probe questions about model evolution and future evaluations of
a specified goal. See [
Modeling: We extend the static notion of an iStar model by allowing the qualitative
satisfaction evaluation label (i.e., , •, •, and in decreasing satisfaction order) of
each intentional element (i.e., goals, tasks, resources, and qualities/soft-goals) to change
over time. We capture this information by assigning each intentional element
(intention) a dynamic function type. Basic dynamic functions include increasing, decreasing,
constant, and stochastic. Compound functions consist of one or more basic functions
that occur sequentially over multiple time periods (called Epochs). For example, the
Denied-Satisfied (DS) function consists of two Epochs, a period of constant followed
by a period of constant , separated by an Epoch Boundary (EB). Monotonic Negative
(MN), another compound function, is a period of decreasing satisfaction followed by
a period of constant , again separated by an EB. We create a unique symbolic
constant for each combination of intention and EB. Users can also model more complex
dynamics using the User-Defined function type. This allows the user to define arbitrary
patterns of satisfaction, as well as model cyclic behaviour by creating functions with a
repeating segment. See [
GrowingLeaf allows users to build iStar strategic rationale models with actors, their intentions, dependencies, and intention links. The modeling view of GrowingLeaf is shown in Fig. 1 with Jake’s lunch model in the centre canvas. The left panel contains the stencil of model elements, while the right shows attributes for the clicked element. Jake’s top goal Have Lunch is decomposed into requisite tasks. He selects as the initial evaluation label for Buy Bread. All other leaf nodes in the model are set to (as shown). Using our dynamic function labels (appearing on the bottom left corner of each intention),he models Buy Bread as a MN function, while Buy Chicken, Buy Beef, and Prepare Sandwich are all modelled using the DS function. Since Buy Bread is currently clicked on the model, its attributes are shown in the right panel including a chart demonstrating the behaviour of the MN function.
Generally, users begin modeling by dragging actors and intentions (from the stencil on the left) onto the model canvas. When an intention is clicked, the right panel is populated and users can change the element’s name, qualitative satisfaction evaluation label, and dynamic function type (with a chart demonstrating the behaviour to make dynamic functions more intuitive). These updates are then shown on the canvas. Dependency and intention links are created by dragging the > icon from the source intention to the target intention. After selecting a link, its type can be changed in the right panel.
Analysis: With these dynamic functions, we generate simulation paths for goal models. A path is a series of models where between each step in the series intentions are updated based on their dynamics and new intention values are propagated throughout the model. We generate paths based on known initial satisfaction values, and desired intermediate/final satisfaction values (by encoding the model and dynamics as a Constraint Solving Problem). We use constraints to dictate relationships between symbolic constants (generated from intention EBs) for the purpose of improving analysis results.
GrowingLeaf’s analysis view allows users to generate and view simulation results.
To answer his first question about lunch, Jake selects Leaf Simulate in GrowingLeaf,
with the initial model in Fig. 1. Fig. 23 shows the analysis view of GrowingLeaf with
Jake’s simulation results in the centre canvas. The slider, which appears at the bottom
of the canvas, indicates that the model is showing time step 12 of the simulation. The
simulation is now listed in the History Log in the left panel. At time step 12, Jake can
3 Forward Analysis implements the analysis in [
Generally, in the analysis view the user clicks an analysis type from the right panel. The analysis type is then shown in the History Log and the resulting analysis is shown on the centre canvas as a series of models with a slider at the bottom allowing the user to step through each time point. In the right panel, the user can also change the maximum number of simulation steps. We encourage users to iteratively ask questions over their models and permit stacking analysis results in the History Log. When an additional simulation is performed from the selected point on the slider, all satisfaction values up to the current time point are saved, and new satisfaction values are appended. Users can choose to merge previous analysis results forming a new sequence, by selecting the Merge Analysis button in the right panel. At any point, the user can return to the modeling view from either the initial or currently viewed state of the model. The constraint view (not shown) looks similar to the modeling view, but with dependency and intention links removed to enable users to add constraints visually with directed edges. 3
GrowingLeaf uses a simple client-server architecture. The front-end (client-side) is built using Javascript and HTML; the back-end (server-side) is implemented in Java. For analysis, we connect the front-end with the back-end through a Python CGI script, and an Apache HTTP Server. A high level overview of the architecture is shown in Fig. 4.
The front-end is built on top of Rappid, a modeling framework by client IO [
The back-end analysis, consisting of 5000 lines of Java code, uses a modified
version of jUCMNav’s systems architecture [
Tool Usability: The tool is in its second version and has been used to model
several non-trivial examples including the ones presented in [
Design Decisions: Given the full array of iStar tools on the iStar wiki [
Design Challenges: In developing our tool we encountered two major challenges. Since we chose to build a web-based tool, the first challenge was dealing with the many browsers and their versions. Thus, we limited our development to ensure that our tool works in Google Chrome first. Although we have experimented with our tool on mobile platforms, we do not intend to support them at this time.
When we wanted to add constraints between EBs, we were not able to show them on the canvas because the data model only contained a single type of link which we were using for dependency, decomposition, and contribution links. We had to revamp the architecture to add a second type of link. Given our substantial development effort prior to this discovery, we had to significantly refactor our codebase.
Future Work: Further work is necessary to evaluate the usability of our interface
and the effectiveness of our tool with user studies. We want to make the tool compliant
with the new iStar 2.0 Language Guide [
Acknowledgements: We would like to thank Jake Fear and the Software Engineering Group at the University of Toronto for their contributions to this work.