Exploring the Intentional Dimension during Software Architecture Design

Exploring the Intentional Dimension during Software (Architecture) Design adding the “why” and the “who/where” to the “what” and the “how” Conceptual meta modeling through prototyping based on case study material The First Tropos Workshop Nov. 2001, Trento-Italy Daniel Gross Faculty of Information Studies University of Toronto

Presentation Objective • Illustrate a research method for conceptual meta modeling to represent the intentional dimension (intents & know-how) – borrowing from the (qualitative) social science grounded theory research methodology (Glasser & Strauss, 1976; Corbin & Strauss, 1990) • Illustrate an integrated research environment for prototyping (tool) meta model & modeling methods – as an integral part of the research method – illustrate the use of a meta-case tool (Meta-Edit+) as such an environment

Research questions • Conceptual meta modeling question: – Are i* concepts adequate/sufficient to capture software design intents, know-how and reusable knowledge from project documentation? If not, what extensions are needed? • Modeling methodology question: Note: focus on postmortem-capturing – What methods for capturing & reusing intents and know-how from project documentation can be proposed? • Research methodology question: This presentation focus – Using case study material, how can we systematically explore i* expressiveness and suggest further extensions and modeling-methodology support?

Grounded theory method “meta-model” Developing concepts/categori es based on data Initial “meta model” for basic social processes Based on (Strauss & Corbin, 1990)

Conceptual meta modeling with case study material (in the spirit of grounded theory research methodology (Glasser & Strauss, 1976)) Start with a theory (basic ontology)*: “Intentionality is making deliberate design decision to achieve stakeholders’ goals” “Intentionality is distributed among stakeholders and within the system during software design and evolution” * Grounded theory purists don’t like to start with a theory – others argue we inevitably start with one Refine theory concepts analyzing & prototyping with case study material Theory guides to know what to look for in the research data Initial meta model & method Conceptual meta model based on concepts/classifications, relationships Design knowledge capturing & reuse needs Computational analysis support needs Design guidance support needs Note: theory concepts need to be found in the actual data, otherwise they don’t make sense (at least in the analyzed case study) Case study material New modeling concepts emerge from research data

Start with preliminary agent and goal meta model & method steps Research Cycle Analyzing documentation Conceptual modeling & analysis (prototyping meta model & method) “Research method” Modeling Capture intent & solution knowledge with existing modeling constructs, Identify limitations Document rationales, notes, research issues & relate constructs to research data Method modeling Meta modeling Use Meta case facilities Refine method steps and/or specify new analysis & tool capabilities Analyze documentation Draw distinctions among meta model constructs and relationships Specify operational “design process” semantics Knowledge based meta modeling Specify instantiations and/or bindings semantics Abstract, classify and parameterize knowledge

Meta modeling with Meta-Edit+ Intended use Daniel’s extensions Meta model under design Method model under design Research data capturing & linking Meta-meta model based on GOPRR (Graph-Object-Property-Relationship-Role concepts) Meta-model under design based on actor and goal concepts conceptual model instances capturing intentional design Method steps meta model (basically a flow-chart meta model) Meta-modeling design, objectives, rationales, definitions & notes methods instances methodsinstances Missing: process-orientation & knowledge-level support, Meta modeling design rationales meta modeling design rationales rationale instances

Lets experiment with a meta model that captures design options and goals Meta relationships Meta concepts

Capturing meta model design rationale Reference to document location is captured Declaring meta model construct Capturing meta model construct rationales & source

Initial capturing method

Captured information with current meta model and capturing method Based on Mitel’s System Operation, Administration, Maintenance, Provision reusable platform architecture documentation

Identifying potential meta model extensions • Analyzing the data we realize that some design options depend on preceding ones. – we note this for potential meta model extensions … may be useful for tracing impact when retracting design decisions. – we also note a new meta design goal “achieving change impact traceability. ” • In the text some design options are discussed for the future. – we note the potential need for a new meta-attribute for “design. Option” : “potential. Future. Design. Option. ” • The need to cluster goals and design decisions into actors. – May need method & process-support extensions to guide the clustering. • Some decisions relate to product classes (“reusable platforms”) while others are “instantiations” of these (“OAMP reusable platform). – We identify the need to distinguish between actor Classes and instances (“a-system” vs. “this-system”).

e. g. “precedence” a new meta model relationship Capturing meta concept rationale and elicitation question

New precedence links method extended to include step for capturing precedence

Taking notes, adding meta modeling “design” goals Meta model “design” goals Precedence links allows for change impact analysis Note: meta modeling goals are related to meta model constructs Research notes. Note can also be attached to meta modeling constructs

Meta-Edit+ vs. Concept-base / Telos • Meta-Edit+ limitation. – Unlike Concept-Base only two meta-levels, no cross-meta level support (“w-strata”). • Flattening the meta-space creates duplication of concept data. • Can’t link method steps to meta constructs to be instantiate. • Cant provide adequate knowledge-capturing & parameterization support (needs more meta levels). – Might also need some sort of scripting support (available in concept base? ). • Meta-Edit+ strengths. – Easy to use graphical user interface for quick prototyping iterations. – Dynamic user-interface generation based on meta-construct definitions. – Easy to use graphical notation definition support including hierarchical decompositions and “explosions. ” – Runs on Windows (and Linux) platform.

Conclusion Tool requirements for research into conceptual meta-modeling • Prototyping support – Prototype emergent i* meta model & modeling method with research data to learn about meta-model expressive abilities and limitations – Executable modeling method • Research traceability support – Capture & refine “modeling theory”, research objectives as knowledge of domain increases – Link theory & objectives to emerging meta model – Link emergent meta model to research data • Research process support – Capture research issues, goals & notes as they arise – Link issues & notes to meta model, modeling diagrams and/or research data • Documentation support – Use research data as examples for modeling examples & tutorials

Future methodology work How to relate intentional meta model to “classes” & “instances” of software system product & process models – How do actors, goals, design Options etc. relate to • UML type of concepts • Architecture type of concepts • etc. . – extending GRL work • Rework research method and tool support within concept-base / Telos environment