1. GROUP 2 CASE TOOLS Business Process Models using CASE tools Tebogo Mello, Iris Bokaba, Wisdom Maphosa, Pilalula Ndlovu 5/7/2012This paper introduces CASE tools. It examines how CASE tools affect organizations and also howCASE can be implemented in business models.
2. IntroductionCASE originated in the 1970s when information technology organisations began to borrowideas from the hardware manufacturing process so that they would apply them to softwaredevelopment.Case tools stands for “Computer Aided Software Engineering”, they are software programswhich automate or support tasks typically constituting information systems developmentpractice. There is no general agreement as to what functionality a CASE tool should provide,but most would agree that CASE tools comprise some subset of the following elements:screen and report design aids, text and diagram editors, data modelling tools, datadictionaries, code generators, testing and debugging tools.There is tremendous interest and investment in the automation of the systemsdevelopment process. This trend towards Computer-Aided Software Engineering (CASE)tools is an attempt to remedy the apparent lack of computer-based support for systemsdevelopers, a lack to which many of the ills of the systems building process have beenattributed.More recently, CASE tools have had to encompass or accommodate visual programmingtools and object-oriented programming. In organisations, a CASE tool may be part of aspectrum of processes designed to ensure quality in the system that is being developed.CASE toolsCASE permits effective communication with users as well as other members of thedevelopment team. They integrate the development done during each phase of a systemlife cycle and also assist in correctly assessing the effects and cost of changes so thatmaintenance cost can be estimated.CASE Tools reduce the amount of work that a developer has to do by allowing them to focustheir skills on other goals. Usable at all stages of the Software Development Life Cycle.They Increase the productivity of analysts as they are easy to use. Case Tools also permiteffective communication with users. The Cost can be estimated better because the toolsmake it easy.CASE has ability in building various kinds of document during analysis and designs thesystem. Furthermore some CASE tool can automatically generate source code tool. In systemmaintenance can use CASE tool to make the operation smoothly, quickly and correctly.CASE tool also help you to decrease the time in document improvement or source code
3. improvement. So at the present time CASE tools have an important role in systemdevelopment and system maintenance.CASE tools are aimed to address the difficulties of developing high quality, complex softwareon time and to budget. Consequently, CASE was thought to provide the solution and thesetools were hailed as the answer to the "software crisis" [Pressman 1997]. However, CASEhas not been the panacea promised by earlier hype [Gabel 1994]. Most studies show thatCASE tools do positively impact quality and productivity [Iivari 1996] despite having beenslow to be adopted by industry [Holt 1997];Cited reasons suggested for CASE tools not having been adopted include: CASE tools are complex and difficult Case tools require a steep learning curve Training on tools is often not available Training on tools is often not sought by companies Managerial attitudes to the use of tools needs to change 50% of industry do not follow a well defined process or methodology CASE tools are a sharp step forward for many organisations Case tools need a large investment in time, cost and effort Organisations often use "in house" techniques and CASE tools are not easily modified to individual requirements CASE tools are generally expensive. Tools do not perform as well as expected Tools do not cover enough of the SDLC
4. Impact of CASE Tools on Social RelationsAs development processes become automated, new challenges are introduced to theproduction work. An important issue rising from this concerns social relations among projectteam members.Information technology is influenced by the social context within which it operates.Therefore, we can expect that CASE tools deployed to automate systems will interact withthe organizational context, introducing a disturbance into the social relations surroundingtool development and use.Research shows that CASE tools caused structural changes within organisations due to themodification of the systems development division of labour and shifts in the patterns ofdependency among project team coalitions. These changes triggered division amongsystems developers which was evinced in acts of coercion and rebellion.Most project teams contain functional personnel and technical personnel. Functionalpersonnel refer to people who have knowledge of an industry and knowledge of functionalareas such as production, marketing or sales.Technical personnel refer to people who have knowledge of software products such asoperating systems or database management systems, and familiarity with various hardwareplatforms. 1. Interaction of project teams before CASE is implementedDepending on the size of the project, organisations have functional and technical personnelassigned to a project. Functional personnel are responsible for developing applicationsystems; this includes amongst others requirements gathering, planning and designing etc,while technical personnel supported their functional colleagues in the technical aspects ofapplication development. Technical personnel responsibilities include providing thetechnical feasibility of various proposed designs, performance tuning and so on.Technical personnel are not involved in the whole project, from start to finish but ratherthey are there to offer support when requested by the functional personnel. 2. Interaction of project teams after CASE tools is implementedWith the implementation of CASE tools, technical personnel had to develop capabilities(CASE tools) to support the rest of the project team. This represents somewhat of a shift in
5. the work performed by technical personnel on projects, changing from a purely advisoryrole, to one that builds a substantial portion of the application.The use of CASE tools radically changed the dependence relations of the project team.Whereas before, the technical personnel where called on an as-needed basis, now they hadto setup the tools before the functional personnel can perform any substantive work.The technical team, thus, began to assume more of a production role as opposed to itsprior, purely support role, which had not involved any direct involvement in applicationsdevelopment work.The responsibility of personnel on systems development projects had changed, withfunctional personnel relinquishing many technical tasks to the technical consultants, whoseinvolvement in project activities had shifted from the periphery to the center.Accompanying the increased visibility and activity of the technical team is increasedresponsibility and power, as the functional team became heavily dependent on the technicalteam, whose activities facilitated their productive work. 3. Structural changes due to CASE toolsWith the shift of responsibility and the increased dependence of project teams on CASEtools, social relation between project team members becomes polarized around two verydifferent perspectives: The technical and functional. Each of these perspectives represents aseparate subculture that has formed within an organisation, reflecting different perceptionof and interactions with clients, project goals, and systems development activities ingeneral. 3.1 Functional SubcultureFunctional personnel do not perceive themselves as “system developers” but as “businessanalysts” who develop functional solution for clients’ business problems through themedium of information technology.Functional personnel are more concerned with the functionality that an information systemmedium provides rather than the information system medium itself. Information technologyis regarded as the means through which valued ends are achieved, rather than an end initself.They view information technology as instruments, thus, functional personnel treat CASE as aneutral, abstract object, that facilitates rational and deliberate manipulation, and that canbe deployed across client contexts, application domains, and problem types. They focus onthe immediate client problem and focus on its completion.
6. 3.2 Technical SubcultureWhile technical personnel acknowledge that the purpose of projects is to solve functionalproblems, they often concentrate on the computer medium, and leave the business detailsto their functional counterparts.They regard information technology as more than just an instrument to achieve an end butas an end itself.Technical personnel are less focused on the immediate client problem and more interestedin finding a unique and elegant solution to the technical problems at hand. While their timeorientation is somewhat in the present, it also tends to look beyond the current project, to amore abstract, timeless level where technical architectures and CASE tools are perfectibleaccording to some absolute criteria.Technical personnel commonly rationalize why they spend inordinate amounts of timerecreating a routine or macro, by claiming that their products will be reused on futureprojects in other clients sites.ConclusionBy deploying information technology in production, traditional bases of expertise and powerin the existing production process are threatened. With the increased dependence ontechnical expertise, conflict arises between the newly-arrived technical experts and theestablished functional workers whose expertise and authority is challenged and changedthrough the mediation of production work by information technology. How this conflict isplayed out across various production arenas remains open to empirical elaboration. Thetechnical experts may triumph, institutionalizing their technocratic dominance, or technicalworkers may reassert control through their continued resistance to the technicaldependence that now inheres in their computer-mediated production tasks.
7. Case Handling: A New Paradigm for Business Process SupportIntroductionWorkflow management systems such as Staffware, IBM MQSeries Workflow, COSA, offergeneric modelling and enactment capabilities for structured business processes. By makinggraphical process definitions, i.e., models describing the life-cycle of a typical case orworkflow instance in isolation, one can configure these systems to support businessprocesses. Recently, besides pure workflow management systems many other softwaresystems have adopted workflow technology, for example ERP (Enterprise ResourcePlanning) systems such as SAP, PeopleSoft, Baan, Oracle, as well as CRM (CustomerRelationship Management) software. However, there appears to be a severe gap betweenthe promise of workflow technology and what systems really offer. Workflow managementsystems are too restrictive and have problems dealing with change.If the process model is kept simple, only a more or less idealized version of the preferredprocess is supported. As a result, the real run-time process is often much more variable thanthe process specified at design-time. In contemporary workflow technology, the only way tohandle changes is to go behind the systems’ back. If users are forced to bypass the workflowsystem quite frequently, the system is more a liability than an asset. If the process modelattempts to capture all possible exceptions, the resulting model becomes too complex tomanage and maintain. These and many other problems show that it is difficult to offerflexibility without losing control.TerminologyWorkflow management systems are case-driven, i.e., they focus on a single processinstance. This means that only business processes describing the handling of one workflowinstance in isolation are supported. Many cases can be handled in parallel. However, fromthe viewpoint of the workflow management system these cases are logically independent.To handle each case, the workflow management system uses the corresponding workflowprocess definition. The process definition describes the routing of the case by specifying theordering of activities. Activities are the logical units of work and correspond to atomic piecesof work, i.e., each activity is executed by one worker (or another type of resource) and theresult is either commit work or abort and roll back.van der Aalst, Weske and Grunbauer argue that the lack of flexibility and, as a result, thelack of usability of contemporary workflow management systems to a large extent stemsfrom the fact that routing is the only mechanism driving the case, i.e., work is moved from
8. one in-tray to another based on pre-specified causal relationships between activities. Thisfundamental property of the workflow approach causes the following problems:• Work needs to be straight-jacketed into activities. Although activities are considered to be atomic by the workflow system, they are not atomic for the user. Clustering atomic activities into workflow activities is required to distribute work. However, the actual work is done at a much more fine-grained level.• Routing is used for both work distribution and authorization. As a result, workers can see all the work they are authorized to do. Moreover, a worker is not authorized to do anything beyond the work-items in her in-tray. Clearly, work distribution and authorization should not coincide. For example, a group leader may be authorized to do the work offered to any of the group members, but this should not imply that all this work is put in his work list. Since distribution and authorization typically coincide in contemporary workflow management systems, only crude mechanisms can be used to align workflow and organization.• By focusing on control flow the context, i.e., data related to the entire case and not just the activity, is moved to be background. Typically, such context tunnelling results in errors and inefficiencies.• Routing focuses on what should be done instead of what can be done. This push- oriented perspective results in rigid inflexible workflows.van der Aalst, Weske and Grunbauer propose case handling as a new paradigm forsupporting knowledge intensive business processes. The core features of case handling are:• Avoid context tunnelling by providing all information available (i.e., present the case as a whole rather than showing just bits and pieces).• Decide which activities are enabled on the basis of the information available rather than the activities already executed.• Separate work distribution from authorization and allow for additional types of roles, not just the execute role.• Allow workers to view and add/modify data before or after the corresponding activities have been executed (e.g., information can be registered the moment it becomes available).
9. Case handling treats both data and processes as first-class citizens. This balance seems to behighly relevant for knowledge intensive business processes.The Case Handling ParadigmThe central concept for case handling is the case and not the activities or the routing. Thecase is the product which is manufactured, and at any time workers should be aware of thiscontext. To handle a case, activities need to be executed. Activities are logical units of work.Many workflow management systems impose the so-called ACID properties on activities.This means that an activity is considered to be atomic and either carried out completely ornot at all. Case handling uses a less rigid notion. Activities are simply chunks of work whichare recognized by workers, e.g., like filling out an electronic form. As a rule-of-thumb,activities are separated by points where a transfer of work from one worker to another islikely or possible.Clearly activities are related and cases follow typical patterns. A process is the recipe forhandling cases of a given type. In many workflow management systems, the specification ofa process fixes the routing of cases along activities, and workers have hardly any insight inthe whole. As a result exceptions are difficult to handle because they require unparalleleddeviations from the standard recipeSince in dynamic application environments exceptions are the rule, precedence relationsamong activities should be minimized. If the workflow is not exclusively driven byprecedence relations among activities and activities are not considered to be atomic, thenanother paradigm is needed to support the handling of cases. Workers will have morefreedom but need to be aware of the whole case. Moreover, the case should be consideredas a product with structure and state. For knowledge-intensive processes, the state andstructure of any case is based on a collection of data objects. A data object is a piece ofinformation which is present or not present and when it is present it has a value. In contrastto existing workflow management systems, the logistical state of the case are notdetermined by the control-flow status but by the presence of data objects. This is truly aparadigm shift: case handling is also driven by data-flow instead of exclusively by control-flow.
10. It is important that workers have insight in the whole case when they are executingactivities. Therefore, all relevant information should be presented to the worker. Moreover,workers should be able to look at other data objects associated to the case they are workingon (assuming proper authorization). Forms are used to present different views on the dataobjects associated to a given case. Activities can be linked to a form to present the mostrelevant data objects. Forms are only a way of presenting data objects. The link betweendata objects, activities, and processes is specified directly. Each data object is linked to aprocess. So-called free data objects can be changed while the case is being handled. Allother data objects are explicitly linked to one or more activities as a mandatory and/or arestricted data object. If a data object is mandatory for an activity, it is required to beentered in order to complete the corresponding activity. If a data object is restricted for anactivity, then it can only be entered in this activity or some other activity for which the dataobject is restricted.The Case Handling Meta ModelAn object-oriented approach is used for this endeavour, since it provides powerfulmodelling constructs which proved to be adequate for dealing with the complexity in casehandling. van der Aalst, Weske and Grunbauer use the de facto standard in object orientedanalysis and design, the Unified Modelling Language (UML); mainly its structural featuresare used. The case handling Meta model represents artifacts which are required to definecases and environments in which cases are executedCase definition is the central class of the case handling Meta model. Case definitions areeither complex (cases with internal structure) or atomic (cases without internal structure),referred to as complex case definitions and activity definitions, respectively. Complex casedefinitions consist of a number of case definitions, resulting in a hierarchical structuring ofcases in sub-cases and activities. In the case handling Meta model, this property isrepresented by a recursive association between complex case definition and case definition.Obviously each complex case definition consists of at least one case definition, and eachcase definition may occur in at most one complex case definitionSince case handling is a data-driven approach, activity definitions are associated with dataobject definitions. In particular, each activity definition is associated with at least one dataobject definition. This association is partitioned into two main types, i.e., mandatory andrestricted. If a data object definition is mandatory for an activity definition then therespective data value has to be entered before that activity can be completed; however, it
11. may also be entered in an earlier activity. A restricted association indicates that a data valuecan only be entered during a particular activity.Restricted and mandatory associations between activities and data are an importantimplementation vehicle for business process support, since an activity can only becompleted if and when values for the mandatory data objects are provided. Activitydefinitions are also associated with forms definitions. Forms are used to visualize dataobjects which are offered to the user. Forms are closely associated with activities, and theyare an important means to business process support. The fields displayed in a formassociated with an activity correspond to mandatory as well as restricted data objects forthat activity. In addition, the definition of forms may also contain data objects that aremandatory for subsequent activities. This feature allows flexible execution of businessprocesses, since data values can be entered at an early stage, if the knowledge workerdecides to do so. Data object definitions may also be free; free data objects are notassociated with particular activities; rather they are defined in the context of complex casedefinitions. Hence, they can be accessed at any time during the case execution. Free dataobjects are represented by an association of data object definition with complex casedefinition. The context of a case can be presented by such a form. As indicated above,providing the knowledge with as much information as possible is an important aspect ofcase handling systems.
12. ReferencesOrlikowski, Wanda J. "Information Technology and Post-Industrial Organizations: AnExploration of the Computer-Mediation of Production Work," Unpublished DoctoralDissertation, Stem School of Business, New York University, New York: 1988.Van der Aalst, WMP,Weske,M, Grunbauer, D, CAse Handling: A New Paradigm for BusinessProcess Support, pp 1-36, viewed 25 April 2012.http://nptel.iitm.ac.in/courses/Webcourse-contents/IISc-BANG/System%20Analysis%20and%20Design/pdf/Lecture_Notes/LNm14.pdf retrieved 07-05-2012http://www.scribd.com/doc/49760660/90/CATEGORIES-OF-CASE-TOOLS retrieved 29-04-2012Division among the ranks: the social implications of CASE tools for system developers, Orlikowski,Wanda J. Sloan School of Management. Cambridge, Alfred P. Sloan School of Management,Massachusetts Institute of Technology 1989 http://0-hdl.handle.net.innopac.up.ac.za/1721.1/47229Wanda J. Orlikowski. 1993. CASE tools as organizational change: investigating incremental andradical changes in systems development. MIS Q. 17, 3 (September 1993), 309-340.DOI=10.2307/249774 http://0-dx.doi.org.innopac.up.ac.za/10.2307/249774Diane Lending and Norman L. Chervany. 1998. The use of CASE tools. In Proceedings ofthe 1998 ACM SIGCPR conference on Computer personnel research (SIGCPR 98), RituAgarwal (Ed.). ACM, New York, NY, USA, 49-58. DOI=10.1145/279179.279187 http://0-doi.acm.org.innopac.up.ac.za/10.1145/279179.279187