Complete report for CASE tools

1. GROUP 2
CASE TOOLS
Business Process Models using CASE tools
Tebogo Mello, Iris Bokaba, Wisdom Maphosa, Pilalula Ndlovu
5/7/2012
This paper introduces CASE tools. It examines how CASE tools affect organizations and also how
CASE can be implemented in business models.

2. Introduction
CASE originated in the 1970s when information technology organisations began to borrow
ideas from the hardware manufacturing process so that they would apply them to software
development.
Case tools stands for “Computer Aided Software Engineering”, they are software programs
which automate or support tasks typically constituting information systems development
practice. 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, data
dictionaries, code generators, testing and debugging tools.
There is tremendous interest and investment in the automation of the systems
development process. This trend towards Computer-Aided Software Engineering (CASE)
tools is an attempt to remedy the apparent lack of computer-based support for systems
developers, a lack to which many of the ills of the systems building process have been
attributed.
More recently, CASE tools have had to encompass or accommodate visual programming
tools and object-oriented programming. In organisations, a CASE tool may be part of a
spectrum of processes designed to ensure quality in the system that is being developed.
CASE tools
CASE permits effective communication with users as well as other members of the
development team. They integrate the development done during each phase of a system
life cycle and also assist in correctly assessing the effects and cost of changes so that
maintenance cost can be estimated.
CASE Tools reduce the amount of work that a developer has to do by allowing them to focus
their 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 permit
effective communication with users. The Cost can be estimated better because the tools
make it easy.
CASE has ability in building various kinds of document during analysis and designs the
system. Furthermore some CASE tool can automatically generate source code tool. In system
maintenance 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 system
development and system maintenance.
CASE tools are aimed to address the difficulties of developing high quality, complex software
on time and to budget. Consequently, CASE was thought to provide the solution and these
tools were hailed as the answer to the "software crisis" [Pressman 1997]. However, CASE
has not been the panacea promised by earlier hype [Gabel 1994]. Most studies show that
CASE tools do positively impact quality and productivity [Iivari 1996] despite having been
slow 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 Relations
As development processes become automated, new challenges are introduced to the
production work. An important issue rising from this concerns social relations among project
team 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 with
the organizational context, introducing a disturbance into the social relations surrounding
tool development and use.
Research shows that CASE tools caused structural changes within organisations due to the
modification of the systems development division of labour and shifts in the patterns of
dependency among project team coalitions. These changes triggered division among
systems developers which was evinced in acts of coercion and rebellion.
Most project teams contain functional personnel and technical personnel. Functional
personnel refer to people who have knowledge of an industry and knowledge of functional
areas such as production, marketing or sales.
Technical personnel refer to people who have knowledge of software products such as
operating systems or database management systems, and familiarity with various hardware
platforms.
1. Interaction of project teams before CASE is implemented
Depending on the size of the project, organisations have functional and technical personnel
assigned to a project. Functional personnel are responsible for developing application
systems; this includes amongst others requirements gathering, planning and designing etc,
while technical personnel supported their functional colleagues in the technical aspects of
application development. Technical personnel responsibilities include providing the
technical feasibility of various proposed designs, performance tuning and so on.
Technical personnel are not involved in the whole project, from start to finish but rather
they are there to offer support when requested by the functional personnel.
2. Interaction of project teams after CASE tools is implemented
With 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 advisory
role, 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 had
to 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 its
prior, purely support role, which had not involved any direct involvement in applications
development work.
The responsibility of personnel on systems development projects had changed, with
functional personnel relinquishing many technical tasks to the technical consultants, whose
involvement in project activities had shifted from the periphery to the center.
Accompanying the increased visibility and activity of the technical team is increased
responsibility and power, as the functional team became heavily dependent on the technical
team, whose activities facilitated their productive work.
3. Structural changes due to CASE tools
With the shift of responsibility and the increased dependence of project teams on CASE
tools, social relation between project team members becomes polarized around two very
different perspectives: The technical and functional. Each of these perspectives represents a
separate subculture that has formed within an organisation, reflecting different perception
of and interactions with clients, project goals, and systems development activities in
general.
3.1 Functional Subculture
Functional personnel do not perceive themselves as “system developers” but as “business
analysts” who develop functional solution for clients’ business problems through the
medium of information technology.
Functional personnel are more concerned with the functionality that an information system
medium provides rather than the information system medium itself. Information technology
is regarded as the means through which valued ends are achieved, rather than an end in
itself.
They view information technology as instruments, thus, functional personnel treat CASE as a
neutral, abstract object, that facilitates rational and deliberate manipulation, and that can
be deployed across client contexts, application domains, and problem types. They focus on
the immediate client problem and focus on its completion.

6. 3.2 Technical Subculture
While technical personnel acknowledge that the purpose of projects is to solve functional
problems, they often concentrate on the computer medium, and leave the business details
to their functional counterparts.
They regard information technology as more than just an instrument to achieve an end but
as an end itself.
Technical personnel are less focused on the immediate client problem and more interested
in finding a unique and elegant solution to the technical problems at hand. While their time
orientation is somewhat in the present, it also tends to look beyond the current project, to a
more abstract, timeless level where technical architectures and CASE tools are perfectible
according to some absolute criteria.
Technical personnel commonly rationalize why they spend inordinate amounts of time
recreating a routine or macro, by claiming that their products will be reused on future
projects in other clients' sites.
Conclusion
By deploying information technology in production, traditional bases of expertise and power
in the existing production process are threatened. With the increased dependence on
technical expertise, conflict arises between the newly-arrived technical experts and the
established functional workers whose expertise and authority is challenged and changed
through the mediation of production work by information technology. How this conflict is
played out across various production arenas remains open to empirical elaboration. The
technical experts may triumph, institutionalizing their technocratic dominance, or technical
workers may reassert control through their continued resistance to the technical
dependence that now inheres in their computer-mediated production tasks.

7. Case Handling: A New Paradigm for Business Process Support
Introduction
Workflow management systems such as Staffware, IBM MQSeries Workflow, COSA, offer
generic modelling and enactment capabilities for structured business processes. By making
graphical process definitions, i.e., models describing the life-cycle of a typical case or
workflow instance in isolation, one can configure these systems to support business
processes. Recently, besides pure workflow management systems many other software
systems have adopted workflow technology, for example ERP (Enterprise Resource
Planning) systems such as SAP, PeopleSoft, Baan, Oracle, as well as CRM (Customer
Relationship Management) software. However, there appears to be a severe gap between
the promise of workflow technology and what systems really offer. Workflow management
systems 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 preferred
process is supported. As a result, the real run-time process is often much more variable than
the process specified at design-time. In contemporary workflow technology, the only way to
handle changes is to go behind the systems’ back. If users are forced to bypass the workflow
system quite frequently, the system is more a liability than an asset. If the process model
attempts to capture all possible exceptions, the resulting model becomes too complex to
manage and maintain. These and many other problems show that it is difficult to offer
flexibility without losing control.
Terminology
Workflow management systems are case-driven, i.e., they focus on a single process
instance. This means that only business processes describing the handling of one workflow
instance in isolation are supported. Many cases can be handled in parallel. However, from
the viewpoint of the workflow management system these cases are logically independent.
To handle each case, the workflow management system uses the corresponding workflow
process definition. The process definition describes the routing of the case by specifying the
ordering of activities. Activities are the logical units of work and correspond to atomic pieces
of work, i.e., each activity is executed by one worker (or another type of resource) and the
result 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, the
lack of usability of contemporary workflow management systems to a large extent stems
from 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. This
fundamental 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 for
supporting 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 be
highly relevant for knowledge intensive business processes.
The Case Handling Paradigm
The central concept for case handling is the case and not the activities or the routing. The
case is the product which is manufactured, and at any time workers should be aware of this
context. 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 or
not at all. Case handling uses a less rigid notion. Activities are simply chunks of work which
are 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 is
likely or possible.
Clearly activities are related and cases follow typical patterns. A process is the recipe for
handling cases of a given type. In many workflow management systems, the specification of
a process fixes the routing of cases along activities, and workers have hardly any insight in
the whole. As a result exceptions are difficult to handle because they require unparalleled
deviations from the standard recipe
Since in dynamic application environments exceptions are the rule, precedence relations
among activities should be minimized. If the workflow is not exclusively driven by
precedence relations among activities and activities are not considered to be atomic, then
another paradigm is needed to support the handling of cases. Workers will have more
freedom but need to be aware of the whole case. Moreover, the case should be considered
as a product with structure and state. For knowledge-intensive processes, the state and
structure of any case is based on a collection of data objects. A data object is a piece of
information which is present or not present and when it is present it has a value. In contrast
to existing workflow management systems, the logistical state of the case are not
determined by the control-flow status but by the presence of data objects. This is truly a
paradigm 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 executing
activities. 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 working
on (assuming proper authorization). Forms are used to present different views on the data
objects associated to a given case. Activities can be linked to a form to present the most
relevant data objects. Forms are only a way of presenting data objects. The link between
data objects, activities, and processes is specified directly. Each data object is linked to a
process. So-called free data objects can be changed while the case is being handled. All
other data objects are explicitly linked to one or more activities as a mandatory and/or a
restricted data object. If a data object is mandatory for an activity, it is required to be
entered in order to complete the corresponding activity. If a data object is restricted for an
activity, then it can only be entered in this activity or some other activity for which the data
object is restricted.
The Case Handling Meta Model
An object-oriented approach is used for this endeavour, since it provides powerful
modelling constructs which proved to be adequate for dealing with the complexity in case
handling. van der Aalst, Weske and Grunbauer use the de facto standard in object oriented
analysis and design, the Unified Modelling Language (UML); mainly its structural features
are used. The case handling Meta model represents artifacts which are required to define
cases and environments in which cases are executed
Case definition is the central class of the case handling Meta model. Case definitions are
either complex (cases with internal structure) or atomic (cases without internal structure),
referred to as complex case definitions and activity definitions, respectively. Complex case
definitions consist of a number of case definitions, resulting in a hierarchical structuring of
cases in sub-cases and activities. In the case handling Meta model, this property is
represented by a recursive association between complex case definition and case definition.
Obviously each complex case definition consists of at least one case definition, and each
case definition may occur in at most one complex case definition
Since case handling is a data-driven approach, activity definitions are associated with data
object definitions. In particular, each activity definition is associated with at least one data
object definition. This association is partitioned into two main types, i.e., mandatory and
restricted. If a data object definition is mandatory for an activity definition then the
respective 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 value
can only be entered during a particular activity.
Restricted and mandatory associations between activities and data are an important
implementation vehicle for business process support, since an activity can only be
completed if and when values for the mandatory data objects are provided. Activity
definitions are also associated with forms definitions. Forms are used to visualize data
objects which are offered to the user. Forms are closely associated with activities, and they
are an important means to business process support. The fields displayed in a form
associated with an activity correspond to mandatory as well as restricted data objects for
that activity. In addition, the definition of forms may also contain data objects that are
mandatory for subsequent activities. This feature allows flexible execution of business
processes, since data values can be entered at an early stage, if the knowledge worker
decides to do so. Data object definitions may also be free; free data objects are not
associated with particular activities; rather they are defined in the context of complex case
definitions. Hence, they can be accessed at any time during the case execution. Free data
objects are represented by an association of data object definition with complex case
definition. 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 of
case handling systems.

12. References
Orlikowski, Wanda J. "Information Technology and Post-Industrial Organizations: An
Exploration of the Computer-Mediation of Production Work," Unpublished Doctoral
Dissertation, Stem School of Business, New York University, New York: 1988.
Van der Aalst, WMP,Weske,M, Grunbauer, D, 'CAse Handling: A New Paradigm for Business
Process 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-2012
http://www.scribd.com/doc/49760660/90/CATEGORIES-OF-CASE-TOOLS retrieved 29-04-
2012
Division 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/47229
Wanda J. Orlikowski. 1993. CASE tools as organizational change: investigating incremental and
radical 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/249774
Diane Lending and Norman L. Chervany. 1998. The use of CASE tools. In Proceedings of
the 1998 ACM SIGCPR conference on Computer personnel research (SIGCPR '98), Ritu
Agarwal (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