1 / 29

Configuration and Contextual Variability

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.

wilton
Download Presentation

Configuration and Contextual Variability

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Configuration and Contextual Variability Alexei Lapouchnian1 and John Mylopoulos2 1University of Toronto, Canada 2University of Trento, Italy

  2. 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

  3. 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

  4. 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

  5. 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

  6. Variation Points PoliMi’10,4.02.2010

  7. Configuration Option 1: Minimizing Cost PoliMi’10,4.02.2010

  8. Configuration Option 2: Performance & Customer Satisfaction PoliMi’10,4.02.2010

  9. 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

  10. 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

  11. 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

  12. BP Reconfiguration/Adaptation 1 2 3 4 9 8 5 7 6 PoliMi’10,4.02.2010

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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

  21. 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

  22. 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

  23. 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

  24. 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

  25. 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

  26. 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

  27. SomeExamples PoliMi’10,4.02.2010

  28. 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

  29. 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

More Related