THE USE OF PROLOG IN IBM FOR THE QUALITY ASSURANCE OF WORKPRODUCT-BASED DEVELOPMENT METHODOLOGIES Ralph Hodgson, Executive Consultant, IBM North America Java & Emerging Technology Services Voice: 303-924-7408, Fax: 425 955-5469, Internet:
[email protected] Guillermo Lois, Senior Consultant, IBM IT Consulting, Switzerland, Internet:
[email protected]
Abstract We are using Prolog in conjunction with a Lotus Notes Method Authoring environment to provide a number of analysis reports and translations of the method content, in particular, the definition and usage of work-products. This paper provides some concrete examples of the benefits that have derived from the use of Prolog in our method development work.
Introduction As background to understanding how Prolog has been useful, a brief description is provided of the meta-model of the method constructs. In the area of validation, we are using prolog to analyze the method content for incomplete, duplicate and inconsistent constructs. To assist with the harmonization of content across different efforts, Prolog is used to look for similar method constructs at each level of the process structure. For example, a task with the same inputs and outputs, irrespectiv e of its role specifications is flagged as a potential duplicate. Another use of Prolog is in the computing of the rollups of work -products and roles from tasks to the higher-level structures. One use of rollups is to discover erroneous dependencies on work-products that are required as inputs to an engagement model, or in some cases, an inner phase of the engagement model. These dependencies are used to look for missing or incompletely specified tasks. We are also using Prolog to generate 'where-used' reports on method elements and to translate method structures into other representations, notably data structures needed for tools such as visualization tools.
IBM’s Global Services Methodology IBM's consulting methods are work-product-based, that is, they emphasize a focus on the artifacts of the work that is being performed. Work-products are organized into domains according to the different disciplines of work that are required on a project. The work-product concept is used along side the more traditional view of hierarchical processes. Work-products are the artifacts that are produced and consumed by tasks, the leaf-level unit of work in the process decomposition.
At the highest level of this process decomposition, an Engagement Model defines the Phase structure for the method. Engagement models are organized into families according to their similarity within a consulting practice, such as 'Customer Application Development' or a technology domain, such as 'eBusiness'. Process decomposition is defined hierarchically from engagement model, phase, activity down to task - each phase is refined into an Activity Model, each activity is decomposed into a Task model. Work-products are only specified at the task level. The resources required to undertake a task are specified as the 'perform-roles' and 'assistroles' of the task. IBM’s Methods are formulated on the following principles and constructs:•
•
•
•
•
• • •
Work -Product (WP) Orientation –focus on what is being produced as opposed to a pure process-only view; Engagement Models – Work-Breakdown Structures (WBS) and work-product models for commonly found project types; Work -Breakdown Structure –process definition using phases, activities, tasks and sub-tasks to specify characteristic and exemplary process elements; Process Variability – support for different process model instances to express incremental and iterative work as appropriate to each project context; Discipline/Domain Orientation – the partitioning of work into domains of activity according to the nature of the wor k and the skills required; Engagement Templates for asset -based projects Technique Papers - detailed “How-To” guidance WP Dependency Models – expressing derivation and other types of dependency between work -products.
Work Product descriptions (WPD) form the basis of the method. These are the tangible artefacts produced during a project, such as models, reports, diagrams, plans, code and other documents. They can be regarded as the direct "stepping stones" to the final deliverable. Each has a specific purpos e in a project and describes specific work in a domain of interest using a predefined semantics and syntax.
Figure 1 shows how a WP Description (for an architecture WP called an ‘Operational Model’) relates to two individual WP instances. Wide Area Network Other Retailers
P OS Token Ring IBM 4680 4690 POS Controller In-Store Processor
MVS Mainframe Westmont Token-Ring IBM 3745 Wide Area Network
X-Terminal Token-Ring
10BaseT EthernetCentral Server Store Corporate
Other Retail Stores
Hughes VSAT Network 800 millisecond latency 30000 bps Shared witheffective multiple throughput other retail stores
POS Token-ring
IBM 4680
Topology diagram - Corp. network topology
4690 POS Controller TCP/IP 10BaseT NFS Ethernet In-Store Processor IBM RS/6000 AIX v3.2.5 -- 7011-250 2Adapter user 2GB 8 port Tape Asynch Drive 32GB MB memory 1 Hard Disk UPS X-Terminal 8 10BaseT Ethernet Printer Hub Tektronics 16port DB2/6000 Mbps Token v2.1 Ring Lexmark 10BaseT Ethernet Data Propagation/Apply Postscript v1.2compatible Touch enabled SNA Server/6000 1024 xScreen 768 10BaseT resolution Hcon v1.3 agent c2.1.2 14" color display Ethernet NvDM/6000 TCP/IP v1.0.2 System agent Monitor agent ADSM v1.2 Watchdog agent Terminal vDatahub 1.1 Portable AIX-Windows Xmodem Communications v1.2.3 Symbol 3100 Middleware Product Barcode Scanner Report Distribution No Product RF capability Xmodem Communications
Topology diagram store layout
Work-Product Description
Work-Product Instances
Figure 1: Work-Products Concept The work product description standard format contains fields to capture artefacts attributes such as purpose, notation, validation and verification, advice and guidance. Process guidance is provided via the process descriptions and Work Breakdown Structure (see Figure 2). The process guidance tells us how to organize a project and develop a solution. It contains constructs such as: phases, activities, tasks, techniques and roles.
Work Breakdown Structures (WBS) 1 1.1 1.1.1 1.1.2 1.1.3 1.2. 1.2.1
Process Guidance (how) Figure 2 : Work-Breakdown Structures In each Engagement Model, the WBS has a four level hierarchy: • • •
Phase Activity Task • Sub-task Tasks (and subtasks) translate into assignable units of work that can be used to create a default project schedule. Techniques provide additional guidance on both WPDs and processes. Engagement models are a starting point for creating a specific approach to a project.. They define how to run a specific type of engagement. An example, the phase structure for a ‘Systems Integration’ engagement, is shown in Figure 3.
Figure 3 : Example of an Engagement Model Phase Structure The work -products of an engagement model belong to distinct domains or disciplines of work. Figure 4 shows how these domains extend across the phase structure of the engagement model in a process independent way.
SIMethod Solution Outline
Macro Design
Micro Design
Build Cycle
Deployment
Business Domain Organization Domain Application Domain Architecture Domain Operations Domain Project Management Domain
Figure 4: SIMethod Phases and Disciplines Typically, one starts with an Engagement Model that references all the Work Product Descriptions needed for a specific type of engagement. The Engagement Model has an appropriate Work Breakdown Structure that can be used in the creation of the Work Products. The Work Breakdown Structure can be viewed according to the various Activities that must take place at each phase. These activities are made up of tasks that produce Work Products or deliverables. These work products are based on Work Product Descriptions. The Engagement Model identifies not only the work products, but also their dependencies. A simplified depiction of the above method constructs and their relationships is shown below using UML (Unified Modeling Language [ 1]) notation in the meta-model of Figure 5:
is derived from
* *
Method element
1 is defined in
8.
*
Engagement Family
*
*
is published in
Community
Before describing some of the Prolog code, it will be helpful to enumerate the structure of the Prolog facts that are used to represent the method elements.
1
*
Engagement Model 1 1 1
1
Work Product 1 Model
Process Model
Aggregation relationships, read as 'consists of' and 'is part of'
*
* *
Other relationship names are read left to right, (or top to bottom where vertical).
*
* is viewed in
WP Dependency Diagram
* Work Product Dependency
*
has subdomains
*
Domain depends on
*
1 impacts
Technique
classifies
*
1
*
*
performs
assists with
* * *
1
provides guidance on
Task
*
*
*
provides guidance on inputs
*
outputs
* *
*
* *
1
1
example:
0..1
Activity
*
Engagement Families family(ID,Family,Name,EngagementModels)
*
Phase
* *
Role
cbr - generates work-product cases in the CBR specification language CASUEL [ 3].
*
Work Product Description
family(mth51DE, 'CAD', 'Custom Application Development', [pth0015, pth0014, pth0016, pth0013]). Engagement Models
1
performs assists with
*
*
* Subtask
Figure 5: Simplified Method Meta-Model More on IBM’s work -product based approach to methods can be found published in “Developing Object-Oriented Software: An Experience Based Approach” [ 2]. With this brief coverage of the method architecture, it should be possible to understand how Prolog has been helpful for reporting, transforming and integrity checking the method models.
The Prolog Work
engagementModel(ID,Family,Name,Phases) example: engagementModel(pth0002, 'CDSC', 'Category Management ', [pha0005, pha0061, pha0060, pha0056, pha0055]). Phases phase(ID,Family,Name,Activities) example: phase(pha0005, 'SCI', 'Proposal', [acy0018, acy0019, acy0017, acy0016]). Activities activity(ID,Family,Name,Tasks)
A number of Prolog checkers, reporters and transformers have been written:
example:
1.
doRollups: computes rollups for specific families
activity(acy0005, 'SCI', 'Refine Plans (Configuration)', [tsk0179, tsk0184, tsk0060, tsk0047]).
2.
recordUnusedMethodElements : looks for orp haned method elements, reporting unused WPs
Tasks
3.
whereUsed(ME,WUlist): returns a list of process elements where a method element, ME, is used.
task(ID,Family,Name,SubTasks) example: task(tsk14896, 'FINANCE', 'Complete Total Web Content', [subC492, subC496, subC49A]).
4.
tasksInEngagementModel(EM,Tasks) : collates the tasks in an engagmentModel
5.
wbs: "work-breakdown structure" - generates the WBS for a selected engagement model
WP Inputs and Outputs
6.
wu: "where-used" - generates XML for each wp with the process elements where the wp is used
example: ip(wpd0015, tsk0117).
7.
tla: "task level analysis" - finds tasks with same inputs and same outputs
example: op(wpd2C0E, tskEAC6).
ip(WPID,TaskID)
op(WPID,TaskID).
Work -products wp(ID,Family,Name,WPtype,WPMID, Category,FullCategory) example: wp(wpd0065,'SCI','Server Environments', 'Work-product','OP209', 'Operational','Architecture\Operational'). Roles
activityHasTask(A,T):-activity(A,_,_,Tlist), member(T,Tlist). The predicates could be collapsed into one predicate passing goals as arguments. In the interests of clarity the code has not been changed.
Rollup Algorithm As discussed previously, the WBS is a composite pattern as illustrated in Figure 6 1..n
role(ID,Family,Name) ProcessElement
example: subordinates
1..n
1..n
1..n
inputs 1..n
1..n parents
outputs
Workproduct
role(rol0001, 'CAD', 'Project Manager (IGSI)'). These facts are provided to the Prolog system as consultable files that are batch -generated from a Method Authoring Environment. The first example of the Prolog is a checker for Unused Method Elements.
Unused Method Elements
Figure 6 : Object Model for Rollups The algorithm for promoting inputs and output work-products at the next level in the hierarchy needs to take account of work-products that are produced locally at the subordinate level.
The search for unused method elements is straightforward. Using negation, the predicates for finding orphaned method elements are as follows: -
Expressed formally, in the Object Constraint Language, OCL [ 4], with PEn denoting the ProcessElement at level n, the rollup algorithm is as follows.
unusedEngagementModel(EM):engagementModel(EM,Family,_,_), family(_,Family,_,_),!,fail.
The outputs of a composite process element are the union of all of the outputs of subordinate process elements:
unusedEngagementModel(EM):- true. unusedPhase(Phase):engagementModelHasPhase(EM,Phase), \+ unused(engagementModel,EM),!,fail. unusedPhase(Phase):- true. unusedActivity(Activity):phaseHasActivity(Phase,Activity), \+ unused(phase,Phas e),!,fail. unusedActivity(Activity):- true. unusedTask(Task):activityHasTask(Activity,Task), \+ unused(activity,Activity),!,fail. unusedTask(Task):- true. unusedWorkproduct(Wp):wpUsedByTask(Wp,T), \+ unused(task,T),!,fail. unusedWorkproduct(Wp):- true. wpUsedByTask(Wp,T):- ip(Wp,T) ; op(Wp,T). engagementModelHasPhase(EM,P): engagementModel(EM,_,_,Phases), member(P,Phases). phaseHasActivity(P,A):phase(P,_,_,Alist), member(A,Alist).
PEn.outputs-= PEn.subordinates ->iterate (element, result : Set | result->union(result, element->outputs) To compute the inputs at a composite level we n eed to consider ‘elaborated’ and ‘ produced’ workproducts. Elaborated work-products are those that are consumed and produced by the same process element. They should have a task upstream that initially creates them. P En.elaboratedWorkProducts = P En.subordinates->iterate ( element, result: Set | result->union(result, intersection(element ->inputs, elements >outputs)) Produced work-products only occur as outputs on a given process element. P En.producedWorkProducts = P En.subordinates->iterate ( element, result : Set | result-> union(result, symmetricDifference(element ->outputs, elements->inputs)) We will also need the set of all inputs over the contained elements:
Prolog Implementation of Rollups
P En.allInputs = PEn.subordinates->iterate ( element, result: Set | result->union(result, elements->inputs))
The computation of rollups in Prolog turns out to be much simpler than OCL. Consider the predicate below that determines if any task inputs need to be declared inputs of the activity:
The inputs of a composite process element are the work-products required as inputs that are not outputs of another process element at the same level, together with those elaborated work -products that are not produced by another (different) process element at the same level.
wpIsInputToActivity(W,A):activityHasTask(A,T), ip(W,T), \+ (activityHasTask(A,T1), ( T \= T1 -> (op(W,T1), \+ ip(W,T1)); fail) ).
P En.inputs = PEn.subordinates->iterate ( element, result: Set | result->union(result, symmetricDifference (PEn.allInputs , P En Outputs)) result->union(result, P En.elaboratedWorkProducts) result-> symmetricDifference (result, P En.producedWorkProducts)
The algorithm makes use of double negation. We look for those input work-products, W, which are not produced by another task of the activity that does not require the same work-product as input. The governing assumption being that an elaborated work-product has to start life somewhere else prior to the activity.
An example of rollups is given in the WBS of Figure 7, which shows an activity A1 composed of four tasks T1, T2, T3 and T4. a, b
a, b, c
T1
A1
The same double negation logic is used to compute inputs at other levels:-
a,c,d,e,f
wpIsInputToEngagementModel(W,EM):engagementModelHasPhase(EM,P), wpIsInputToPhase(W,P), \+ ( engagementModelHasPhase(EM,P1), ( P \= P1 -> (wpIsOutputForPhase(W,P1), \+ wpIsInputToPhase(W,P1)); fail) ).
a, d, e
d, f
T2
f
a
T3
c
a
T4
Figure 7: Example of Rollups The outputs of A1 are simply the composite outputs formed by the union of all elements, which is {a, c, d, e, f}. The algorithm, described above, determines the inputs of A1 as follows: A1.Outputs = { a, c, d, e, f} A1.ElaboratedWorkProducts = {a, f} A1.ProducedWorkProducts = {c, d, e, f } A1.allInputs = {a, b, c, d, f } A1.inputs = symmetricDifference (union ( symmetricDifference({a, b, c, d, f}, { a, c, d, e, f}),{a, f}),{c, d, e, f}) = symmetricDiffe rence (union({b}, a, f}),{c, d, e, f}) = symmetricDifference ({a, b, f}),{c, d, e, f}) = {a, b} From this it can be seen that only work -products ‘a’ and ‘b’ are required as inputs.
f
wpIsInputToPhase(W,P) : phaseHasActivity(P,A), wpIsInputToActivity(W,A), \+ (phaseHasActivity(P,A1), (A \= A1 -> (wpIsOutputForActivity(W,A1), \+ wpIsInputToActivity(W,A1)); fail) ). At any level of the process decomposition, the rollup is computed simply by doing a ‘findall’ over the appropriate ‘wpIsUsedBy’ predicate. For example, the rollup for Engagement Models is:rollupEngagementModel(EM,Inputs,Outputs): findall(WP, wpIsInputToEngagementModel(WP,EM),R), sort(R,Inputs), findall(WP, wpIsOutputForEngagementModel(WP,EM), R1), sort(R1,Outputs). Likewise, rollups for Phases are computed using:rollupPhase(Phase,Inputs,Outputs):findall(WP,wpIsInputToPhase(WP,Phase),R), sort(R,Inputs),
findall(WP, wpIsOutputForPhase(WP,Phase),R1), sort(R1,Outputs).
Object Technology Series)”, AddisonWesley Pub Co; ISBN: 0201571684, 1998 [ 2]
At any level, outputs always contribute to their parent levels:wpIsOutputForEngagementModel(W,EM) :engagementModelHasPhase(EM,P), wpIsOutputForPhase(W,P). wpIsOutputForPhase(W,P) :phaseHasActivity(P,A), wpIsOutputForActivity(W,A).
[ 3]
IBM’s Object-Oriented Technology Center, “Developing Object-Oriented Software: An Experience Based Approach”, ISBN 0-13737248-5, Prentice-Hall, 1997. Michel Manago et al, “CASUEL: A Common Case Representation Language”, ESPRIT project 6322, INRECA consortium,
[email protected], 1994
[ 4]
wpIsOutputForActivity(W,A) :activityHasTask(A,T), op(W,T).
Jos Warmer, Anneke Kleppe, “The Object Constraint Language – Precise Modeling With UML”, ISBN 0-201-37940-6, AddisonWesley, 1999
[ 5]
Assessment and Conclusions
[ 6]
LPA WinProlog, Logic Programming Associates, UK, http://www.lpa.co.uk Jessica Chen-Burger, Dave Robertson, Justine Stader , “A Case-Based Reasoning Framework for Enterprise Model Building, Sharing and Reusing”, Informatics Research Report EDI-INF-RR-0022, Division of Informatics, University of Edinburgh, June 2000
The system was implemented in standard Prolog using LPA’s WinProlog [ 5], version 4. We were able to handle fairly large models. The table below lists the number of method elements that were processed in typical runs of the checkers: Method Element
Count
Families
43
Engagement Models Phases
71 277
Activities
1527
Tasks Work-products
2987 1269
Inputs
7149
Outputs
3524
Roles
205
Perform Roles
1880
Assist Roles
2869
Performance of the system was also satisfactory with most computations completed in the order of seconds. In conclusion, Prolog was found to be extremely effective for the integrity checking of method process models. The benefits gained from using Prolog have encouraged us to consider more areas of application in the future. For example, inspired by work dis cussed with Jessica Chen-Burger at Edinburgh University, one area of investigation is the use of Case-Based Reasoning to look for similarities across process models [ 6] . We are also considering closer integration of Prolog with method authoring and method customization.
References [ 1]
Grady Booch, Ivar Jacobson, Jim Rumbaugh, “The Unified Modeling Language User Guide (The Addison-Wesley
