Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
From Stakeholder Goals to High Variability Designs
Yijun Yu, John Mylopoulos, Alexei Lapouchnian, Sotirios Liaskos, Julio Cesar Sampaio do Prado Leite
The technical report is at ftp://ftp.cs.toronto.edu/csri-technical-reports/509/variability.pdf
@ The Early Requirements SeminarMar 29, 2005
Agenda
• Problem domain: Variability in goal models• Solution domain: Variability in designs
– Feature model: configuration variability– Statecharts: behavioural variability
– Components-connector: structural variability
• Patterns, algorithms and implementations• Case study: meeting scheduler• Summary
1. Background
• Why variability? Manage the complexity in software configurations and design customizable software that supports variabilities– High-level: stakeholder policies, various user
preferences, evolving capabilities– Low-level: configuration items, external changes
• Variability representations– Requirements: stakeholder goal models– Design:
• Feature models• Statecharts• Software architectures• And so on … (aspects, web services, … )
1.1 Variability in goal models
• OR goals: various alternatives• Softgoals: variable satisficing labels• OR/XOR: various combinations• AND goals: various controls• Goal/agent delegation: various boundary
among system/non-system goals• And so on … the more design
considerations, the more variabilities
OR++ + - --
XOROR ANDANDA AB BAND
A B
By system By environment (NOP)
……A
AA
A A
A
A A
A
OR
A goal model example
���������
����
�������
�������
�������
��������
��������� �������
�������� ����������
�������
�����
����������
�����
������ �
�����
������������
��������
�������
��������
�����
�����������
�����
������
��������
��������
����
����
���
���
���
���
��� ���
���
���
�
�
� ���
��
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� �
��
���������
����
�������
�������
�������
��������
��������� �������
�������� ����������
�������
�����
����������
�����
������ �
�����
������������
��������
�������
��������
�����
�����������
�����
������
��������
��������
����
����
���
���
���
���
��� ���
���
���
�
�
� ���
��
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� �
��
VP1VP2
VP3
Some variation points
1.2 Variability in Feature Models
• Feature model is the primary representation for the product-line family
• There are four kinds of feature compositions:– Mandatory versus Optional– Alternative versus Inclusive OR
• A feature graph is basically a tree• Feature Tradeoffs:
– Constraints: select feature A => not select feature B– Dependencies: select feature A => select feature B
An example of feature model -- captain feature 0.1
MANDATORY OPTIONAL
ALTERNATIVEINCLUSIVE-OR
Feature model example���������
����
�������
�������
�������
��������
������� ����������
�����������
� ���
������
���������
!���������"�����������������#
!���������"�����������������#
�����
������
��������
��������
��� ���
���
DEPENDENCIES
1.3 Variability in Statecharts
• Statecharts captures system behaviour more concisely than state machines– States– Transitions: event [condition] / action– + Super/sub states: hierarchical
• Behavioural variability in statecharts– AND/XOR decomposition of a superstate– Parallel versus Sequential substates (with/out
swimlanes)– Multiple entry, multiple exit
Swim-lane: AND/XOR decomposition of a superstate
�$ �%�$
�%
Statecharts example�������������
����������&�������
'''
"(�)*%#�����
������
"(�$*$#+��,������
���������������
"(�%*$#+�������
"(�%#*%+����������
�������
"(�)*$#+��������� ���
1.4 Variability in software architectures
• Software architectures use component/connectors to abstract the structural relations
• Architecture definition languages are proposed to represent architecture styles
• The bindings allows various connections between (interface) compatible components
• “Switch” in Koala/Darwin ADL
Software architecture exampleSWITCH
2. From problem to solutions
• What’s common in the above-mentioned variability representations?– Hierarchical refinements
• Goal model: AND/OR decomposition of goals• Feature model: AND/OR/XOR/optional decomposition of features• Statechart: AND/XOR decompositions of states• Software architecture: Decomposition of compound components
– Abstract views• Goal model: requirements• Feature model: configurations• Statechart: behaviours• Software architecture: structures
• Can one generate variability design views from the most abstract goal models?
How to generate feature model?
���������
����
�������
�������
�������
��������
��������� �������
�������� ����������
�������
�����
����������
�����
������ �
�����
������������
��������
�������
��������
�����
�����������
�����
������
��������
��������
����
����
���
���
���
���
��� ���
���
���
�
�
� ���
��
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� �
��
���������
����
�������
�������
�������
��������
������� ����������
�����������
� ���
������
���������
!���������"�����������������#
!���������"�����������������#
�����
������
��������
��������
��� ���
���
How to generate statecharts?
���������
����
�������
�������
�������
��������
��������� �������
�������� ����������
�������
�����
����������
�����
������ �
�����
������������
��������
�������
��������
�����
�����������
�����
������
��������
��������
����
����
���
���
���
���
��� ���
���
���
�
�
� ���
��
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� �
��
How to generate software architecture?
���������
����
�������
�������
�������
��������
��������� �������
�������� ����������
�������
�����
����������
�����
������ �
�����
������������
��������
�������
��������
�����
�����������
�����
������
��������
��������
����
����
���
���
���
���
��� ���
���
���
�
�
� ���
��
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� �
��
2.1 Enrichments
Enrichment is neededLight-weight enrichment is desired• What are missing in goal models for
– Feature models? • Mandatory or Optional: System/Non-System boundary (in i*
notations, decide whether an actor is system actor or not)• Inclusive or Alternatives: OR/XOR
– Statecharts?• If one knows data dependencies among leaf goals, control is
either sequential (;) or parallel (||).– Software architecture?
• Data bindings for inputs and outputs (corresponds to goal topics, cf. types)
Configuration enrichment example
���������
����
�������
�������
�������
��������
��������� ������� �������� ����������
�����
��������������
��������
�� �� ����
��� ���
��� ���
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� ���
-.�-.� �
��� ���
���
���������
����
�������
�������
�������
��������
��������� �������
�������� ����������
�������
�����
����������
�����
������ �
�����
������������
��������
�������
��������
�����
�����������
�����
������
��������
��������
����
����
���
���
���
���
��� ���
���
���
�
�
� ���
��
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� �
��
NONSYSTEM GOALS
ALTER-NATIVE
Control enrichment example
���������
����
�������
�������
�������
��������
��������� �������
�������� ����������
�������
�����
����������
�����
������ �
�����
������������
��������
�������
��������
�����
�����������
�����
������
��������
��������
����
����
���
���
���
���
��� ���
���
���
�
�
� ���
��
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� �
��
���������
����
�������
������� �������
��������
���
������
���
������������ ����������
�����
��������������
��������
�� ������
��� ���
��� ���
�����������
�����
�����������
� ���
����
-.�-.�
���
���
���
��
�
SEQUENTIAL
Data enrichment example
���������
����
�������
�������
�������
��������
��������� �������
�������� ����������
�������
�����
����������
�����
������ �
�����
������������
��������
�������
��������
�����
�����������
�����
������
��������
��������
����
����
���
���
���
���
��� ���
���
���
�
�
� ���
��
�����������
�����
�����������
� ���
����
�������
���������
������
����������
� �
��
���������
�����
�������
���������
�������
���������
���
��
���������
���
�����
����������
���������
����������
���������
���
����������
/���������
�������
���
���������
������
���
����������+�
�������
��������
����
��������
���0������
��������
�
��
����
������������
������� ��
������
������
���������
���
�����������
������� ��
����
���������
�������� ��
��������������
�������
������� ��
����������������
���������
�������� ��
��������������
�������������� ��
��������������
��������������
��������������
��������������
��������������
����
������������������
������� ���������
�
0����
����� ��
1���
����
������������������
����������������������
����
��������
.������
&����������
�����2����
��������
�����2����
��
��
��
��������������
��������������
��������������
��������������
��������������
��������������
��
��
�
�
�
2.2 Transformation patterns
Patterns are used to conduct the systematic transformations from enriched goal models
• Feature model generation patterns• Statecharts generation patterns• Component-connector generation patterns
2.2.1 From goal to feature
�$
�% �)
�$
�%
�$
�% �)
�$
�% �)
������� ������� ��������� ��
$
% )
��� ���
$
% -.�
�� ��
$
% )
�� ��
$
% )
�� ��3
4�5 4�5 4�5 4 5
2.2.2 From goal to state
1. Defining states 2. Transforming hierarchies
3. Treating dependencies 4. Simplifying leaf statecharts
2.2.3 From goal to interfaces
3. Algorithms and implementations
The process is semi-automatic: (1) Enrichment has to be done by designers(2) Transformations can be done automatically (3) The results are initial design, which allow designers to
make suitable changes based on design choicesDesign and implementations1. We designed the meta-model for enriched goals 2. We designed three algorithms using part of the
enriched goal model3. What’s New! We implemented the feature generation
algorithm in OpenOME
The meta model generates Java programs in Eclipse Modeling Framework
• ftp://ftp.cs.toronto.edu/csri-technical-reports/509/goal.mdl
enriched goal model
generated design views
Algorithm 1. Feature model
Algorithm 2. Statecharts
Algorithm 3. Components-connectors
view
Enrichment in OpenOME (q7)
Generating Feature model into CaptainFeature
4. Case study: Meeting Scheduler
4.1 Enriched goal model
4.2 Feature model generated
4.3 Statecharts generated
4.4 S/w architecture generated
5. Summary and future work
• Comparing with formal definition of goals, the enriching annotations are light-weight, thus the variability decompositions are mostly inherited from the goal models
• The generated software design views provide a starting point of the high-variability design
• The traceability between requirements and designs can be maintained in the model-driven development
Future work• Support more variability views such as aspects and web
services• Generating commented code from goal models (Q7)• Use goal models as the core knowledge in autonomic
elements
Major References• On Goal models in goal-oriented requirements engineering
– L. Chung, B.A. Nixon, E. Yu, J. Mylopoulos. Non-functional requirements in software engineering. Kluwer Academic Press. 1999.
– A. van Lamsweerde. “From systems goals to software architectures”. FSE. 2004.
• On Feature oriented (generative) programming and product-line family:– K. Czarnecki et al. Generative Programming: Methods, Tools, and
Applications. Addison-Wesley, 2000.– D. Batory et al. “Scaling Stepwise Refinements”. ICSE 2003.
• On Statecharts– D. Harel. “The STATEMATE Semantics of Statecharts”. TOSEM
5(4):293—333.• On Software architectures and ADL
– L. Bass et al. Software Architecture in Practice, 2nd Ed. Addison-Wesley, 1998.