300 likes | 437 Vues
Configuration and Contextual Variability. Alexei Lapouchnian 1 and John Mylopoulos 2 1 University of Toronto, Canada 2 University of Trento, Italy. Variability in Goal Modeling.
E N D
Configuration and Contextual Variability Alexei Lapouchnian1 and John Mylopoulos2 1University of Toronto, Canada 2University of Trento, Italy
Variability in Goal Modeling • Goal modelsare used to capture, refine, analyze stakeholder goals (both functional and non-functional) and produce system requirements. • Intentional variability: modeling and analysis (e.g., w.r.t. desired quality attributes) of different ways goals can be attained. • Can produce multiple solutions with possibly different properties • Customization/configuration • Creation of customized applications at design time (e.g., based on customer/user profiles). • Customization at instance creation time or at runtime. • Use at runtime for adaptation • Contextual variability: model and analyze the effects of contexts on requirements goal models PoliMi’10,4.02.2010
Part I - Variability for Customization and Configuration • Develop a method for requirements-driven specification, configuration, and adaptation of • Software systems • Business Processes (BPs) – our main focus. • Services • Requirements (Goals) => High-level Designs • High-variability requirements models => high-variability designs • Model quality constraints related to software, BPs • Identify and capture alternative ways of achieving goals and their effects on qualities • This allows us to create customizable and adaptable/adaptive designs that can be tailored to different preferences, settings, and conditions. PoliMi’10,4.02.2010
Supply Customer BP Example Root Goal Quality Goal (Softgoal) Control Flow Annota-tions Softgoal Contribution Help ( + ) Make (++) Hurt ( – ) Break (–– ) Variation Point Functional Goal PoliMi’10,4.02.2010
High-Level BP Configuration • Want to configure BPs based on preferences over quality attributes (softgoals) • Main mechanism to capture variability and to configure goal models: preference-driven OR decompositions orVariation Points • (vs. data-driven or event-driven process variations) • E.g., Ship Order: either Ship Standard or Ship Express • Alternatives achieve the same thing • Difference in softgoal contributions • Softgoals act as selection criteria for choosing BP configurations PoliMi’10,4.02.2010
Variation Points PoliMi’10,4.02.2010
Configuration Option 1: Minimizing Cost PoliMi’10,4.02.2010
Configuration Option 2: Performance & Customer Satisfaction PoliMi’10,4.02.2010
Towards High-Variability Designs: Generating Flexible BP Specifications • Generate WS-BPEL processes from goal models • High-variability goal model (HVGM) => High-Variability Executable Model (HVEM) • Semi-automatic • Structurally similar to the source goal models • Variability preservation PoliMi’10,4.02.2010
Mapping Variation Points • They are a tool to configure executable (and, possibly, deployed) BPs • Mapping to WS-BPEL • Generate switch (or if-elseif for BPEL 2.0) • Each switch branch corresponds to an alternative • Branch condition (XPath) checks if it is the current choice for the variation point • Activities in each branch are automatically generated based on the particular alternative in the goal model • All choices are to be implemented! • BPEL process skeleton is generated. It needs to be completed. • The result: High-Variability Executable Model (HVEM) of the business process – does not need to be redeployed based on preferences, just customized. PoliMi’10,4.02.2010
Configuring HVEMs at runtime • Prototype infrastructure • GUI for preference input • Configurator WS • Can come up with goal model configuration based on preferences • Can provide the configuration to deployed BPs • XML Representation for BP configuration PoliMi’10,4.02.2010
BP Reconfiguration/Adaptation 1 2 3 4 9 8 5 7 6 PoliMi’10,4.02.2010
Discussion - Part I • Benefits • Explicit representation of quality attributes • BP configuration at high level, in user-oriented terms • High-level visualization of BP alternatives through goal models • Drawbacks • Explicit representation of BP alternatives • Qualitative analysis PoliMi’10,4.02.2010
Part II: Beyond Intentional Variability • Intentional variability cannot capture all the details needed for flexible, adaptable and adaptive systems. More details needed! • How can we model the fact that automatic approval of large orders is very risky, while for others, its just risky? • …that international orders need customs clearance? PoliMi’10,4.02.2010
Goal Models and the Environment • Traditional goal models • Assume that the environment of the system is mostly uniform • Elicit/refine goals in a way that would be adequate for most instances of a problem in a domain • Domain influences are not captured • An important source of requirements variability is missing! • The view of requirements is simplistic • Environment (domain) characteristics and their dynamics affect the requirements and must be taken into consideration! PoliMi’10,4.02.2010
Aim of this Work • Develop an approach for producing high-variability context-enriched goal models • Model the effects of domain non-uniformity and variability on requirements and other models • Capture and refine stakeholder goals in ALL relevant contexts • Capability to display a version of the model for particular context(s) • Simplify the development of context-enriched models by exploiting inheritance among contexts PoliMi’10,4.02.2010
The Approach • A generic formal framework capturing the effects of external factors on model elements • For external context, viewpoints, versions, etc. • Allows to specify under which circumstances a model element is present (visible) in the model • Determines if an element is visible in the current circumstances • A method for using the formal framework with goal models • The context identification and modeling • Generation of the formal model from goal model • Analysis of goal model variants in context PoliMi’10,4.02.2010
The Formal Framework (1) • Generic – can be used with any modeling notation • Models are viewed as collections of elements • Visibility of model elements can be affected by external factors (contexts) • Contextual tags are assigned to model elements • Labels assigned to model elements to capture when the elements are visible in the model (possibly many alt. Conditions for visibility). • Tags represent domain properties, assumptions, etc. and are assigned definitions (Boolean expressions) that specify when they are active • Negated tags can be used, default tag signifies no conditions PoliMi’10,4.02.2010
The Formal Framework (2) • IS-A relationships among contexts make specifying effects of external factors easier • A tag can be substituted for its ancestor • Multiple inheritance is allowed • Non-monotonic inheritance is supported • Given the current state of the world the framework can: • Determine which tags are active (through tag definitions) • Determine which elements are visible, i.e., produce the visible subset of model elements for the current domain state. PoliMi’10,4.02.2010
The Formal Framework (3): Element Visibility • A context-dependent model element is visible when there exists a contextual tag assignment where all the tags are either active or their non-abnormal descendants are active • A subset of visible context-dependent elements is produced • Currently per element, but optimizations possible • Note: Since tag definitions refer to the real world phenomena, the visibility of elements will be dynamically changing if the framework is used at runtime by context-aware systems PoliMi’10,4.02.2010
Contextual Variability in Goal Models • Approach for creating context-dependent goal models • Capture ALL effects of domain variability in a single model • Produce a version for a particular context • Analyze if goals can be attained in the current context • Simple context model • Context entities (influence the requirements) and context dimensions (aspect of the domain along which it changes). • Context – property/characteristic of the environment that affects requirements PoliMi’10,4.02.2010
Capturing contexts • Domain • Context Entities • Things that the system works on (documents/data, supplies, etc.) or with (users, other systems, etc.) • Influence the system (management, owners, government regulators) • Other things (date, time, weather conditions, etc.) • Context entities have context dimensions • Properties that affect the requirements (e.g., size, location, importance, utilization). • Context – a particular value for a dimension (e.g., size(Order, $5000)) PoliMi’10,4.02.2010
Context refinement hierarchies • Contexts can be arranged in hierarchies • Structure the domain • Simplify the modeling of the effects that contexts have on the model • Leaf-level contexts are definedto determine when they are active. • Multiple and non-monotonic inheritance PoliMi’10,4.02.2010
Taking the Environment into Consideration • Domain characteristics influence the requirements and the behaviour of the system. In particular, they can: 1. Affect the requirements themselves: what is required of the system, i.e., system goals (e.g., a new goal may appear in a particular context). 2. Affect/constrain goal refinement, e.g., change the available alternatives to achieve system goals 3. Change how alternatives are evaluated w.r.t. softgoals PoliMi’10,4.02.2010
Using Contextual Annotations • Contextual annotations are used in goal models to present contextual tags assigned to model elements • Hierarchical nature of goal models is used – reduces the number of annotations! • An annotation applied to a node is automatically applied to the whole subtree rooted at that node PoliMi’10,4.02.2010
Analyzing Goal Models in Context 1. The formal context model is created based on the goal model • Process the inheritance hierarchies • Create tags with appropriate definitions • Process the goal model to create to associate contextual tags with goal model elements • Take context inheritance into consideration • Keep track of tags applied to ancestor model elements 2. Produce a version of the model based on the currently active contexts: binding contextual variability 3. Use standard goal analysis techniques to evaluate the resultant model • E.g., can top-level goals be achieved in the current context? PoliMi’10,4.02.2010
SomeExamples PoliMi’10,4.02.2010
Current/Future Work • Richer context modeling including: • Priorities • Conflicts • Case studies (BPM area) • Modeling internal context • Current state of the system and its effect on requirements • Context at runtime • Context-awareness requirements • Context monitoring • Context-driven adaptation PoliMi’10,4.02.2010
Based on: • A. Lapouchnian, Y. Yu, J. Mylopoulos. “Requirements-driven design and configuration management of business processes”, BPM 2007 • A. Lapouchnian, J. Mylopoulos. “Modeling domain variability in requirements engineering with contexts”, ER2009 alexei@cs.toronto.edu PoliMi’10,4.02.2010