Computer Aided Software Engineering Tool

Using CASE Tools for Database Design

Jan L. Harrington , in Relational Database Design (Third Edition), 2009

Publisher Summary

A computer-aided software engineering (CASE) tool is a software package that provides support for the design and implementation of information systems. It can document a database design and provide invaluable help in maintaining the consistency of a design. By integrating many of the techniques used to document a system design—including the data dictionary, data flows, and entity relationships—CASE software can increase the consistency and accuracy of a database design. It can also ease the task of creating the diagrams that accompany a system design. There are many CASE tools on the market. The actual look of the diagrams is specific to each particular package. However, it should always be kept in mind that although some current CASE tools can verify the integrity of a data model, they cannot design the database. There is no software in the world that can examine a database environment and identify the entities, attributes, and relationships that should be represented in a database. The model created with CASE software is therefore only as good as the analysis of the database environment provided by the people using the tool.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123747303000127

Using CASE Tools for Database Design

Jan L. Harrington , in Relational Database Design and Implementation (Fourth Edition), 2016

CASE Capabilities

Most CASE tools organize the documents pertaining to a single system into a "project." As you can see in Figure 12.1, by default, a typical project supports the following types of documents:

Figure 12.1. CASE software project documents.
■

Data dictionary: In most CASE tools, the data dictionary forms the backbone of the project, providing a single repository for all processes, entities, attributes, and domains used anywhere throughout the project.

■

Requirements: CASE tool requirements documents store the text descriptions of product specifications. They also make it possible to arrange requirements in a hierarchy, typically from general to specific.

■

Data flow diagrams (DFD): As you read in Chapter 4, DFDs document the way in which data travel throughout an organization, indicating who handles the data. Although it isn't necessary to create a DFD, if your only goal with the project is to document a database design DFDs can often be useful in documenting the relationships between multiple organization units and the data they handle. Data flow diagrams can, for example, help you determine whether an organization needs a single database or a combination of databases.

■

Structure charts: Structure charts are used to model the structure of application programs that will be developed using structured programming techniques. The charts show the relationship between program modules.

■

Data models: Data models are the ER diagrams about which you have been reading. The ER diagram on which the examples in this chapter are based can be found in Figure 12.2.

Figure 12.2. ER diagram created with the sample CASE tool for Antique Opticals.

■

Screen prototypes: Drawings of sample screen layouts are typically most useful for documenting the user interface of application programs. However, they can also act as a crosscheck to ensure that a database design is complete by allowing you to verify that everything needed to generate the sample screen designs is present in the database.

■

State models: State models, documented in state transition diagrams, indicate the ways in which data change as they move through the information system.

■

Task diagrams: Task diagrams are used to help plan application programs in which multiple operations (tasks) occur at the same time. They are therefore not particularly relevant to the database design process.

■

Class diagrams: Class diagrams are used when performing object-oriented, rather than structured, analysis and design. They can also be used to document an object-oriented database design.

■

Object diagrams: Object diagrams are used during object-oriented analysis to indicate how objects communicate with one another by passing messages.

Many of the diagrams and reports that a CASE tool can provide are designed to follow a single theoretical model. For example, the ER diagrams that you have seen earlier in this book might be based on the Chen model, or the Information Engineering model. Any given CASE tool will support some selection of diagramming models. You must therefore examine what a particular product supports before you purchase it to ensure that it provides exactly what you need.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780128043998000120

Business process and system modeling tools and packages

In Practical E-Manufacturing and Supply Chain Management, 2004

5.5 Computer-aided software engineering tools

Tools designed to support specific business modeling techniques are often referred to as computer aided software engineering (CASE) tools. A CASE tool is a product that helps to analyze, model and document business processes. It is a tool or a toolset that supports the underlying principles and methods of analysis. Some tools are specifically designed to support a particular technique while other tools are more general in nature.

5.5.1 What is a CASE tool?

A software package can be classified as a CASE tool according to the following definition: A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development environment (refer Figure 5.16).

Figure 5.16. Business modeling tool

CASE tools are used for:

•

Diagramming

•

Computer display and report generation

•

Analysis tools

•

Central repository

•

Document generation

•

Code generation.

Computer-aided software engineering is used especially to organize and control the development of software on large complex projects, involving many software components and people. It allows designers, code writers, testers, planners and managers to share a common view about the project position (stage wise). It helps to ensure a disciplined, check-pointed process. It may also serve as a repository for or be linked to document and programme libraries containing the project's business plans, design requirements, design specifications, detailed code specifications, the coded units, test cases and results, and marketing and service plans. It encourages code and design re-use, reducing time and cost and improving quality.

Many CASE tools are based on UML, the industry-standard language for specifying, visualizing, constructing and documenting the components of software systems. It simplifies the complex process of software design, generating a 'blueprint' for development.

Before buying a CASE tool, one has to look objectively at such products and evaluate the benefits. The following questions should be answered before any decision:

•

Is there parity between advantages offered and cost?

•

Will a CASE tool stop the interactive nature of the current development life cycle and the continuous development associated with work duplication?

•

Will the CASE tool improve the overall development process when choosing a certain tool?

5.5.2 Products

There are several hundred business- and process modeling tools and toolsets available. These range from integrated development tools to specific, single function tools. The tools do not all provide the same functionality and some are based on different technologies and techniques/methodologies.

Some of the main classifications used to evaluate the tools are the ability to handle:

Workflow

After the process models and the object models have been developed, workflow is the basis for an understanding of what an organization is doing and why, along with a shell that can be used to implement the processes as an IT solution. Traditional workflow is the answer to the controls required that ensures that the process is executed correctly with a mixture of manual and automated tasks. Development of a workflow helps to identify the obvious flaws in the automation that may exist such as, where data is not managed properly and where there are unnecessary waits for parallel steps to complete. The workflow should define and describe (refer Figure 5.17):

Figure 5.17. Workflow
•

The activities which are to be performed at each stage of a project

•

The correct sequence of applying the techniques and any dependencies which exist between them

•

Information which ensures that the application of a technique is repeatable, measurable and can be improved over time.

We have defined two different types of workflow:

1.

Core workflows which guide the application of a specific technique

2.

Product workflows, which define the activities required to produce a particular business-modeling end product.

Simulation

Simulation is a key part of any business modeling solution and offers an organization the opportunity to optimize processes in a variety of ways. The most obvious requirement is to minimize the elapsed time required for the process to complete, but it is also common for optimization to be based on cost or resource usage. For process simulation all the key information is included in each step of the process – how long it takes, the costs involved and the resources used. Then a workload is applied to the model to see how smoothly the operation works. Steps that take too long will result in a backlog and inefficiencies further down the chain. It should be possible to make modifications to the model quickly so that fine-tuning can be carried out online. In complex environments with multiple geographic locations and distributed processes, the whole process of modeling comes to life within simulation. There is often a balancing act to be achieved between the cost of the process and the time it takes to complete.

Activity-based costing

Many business modeling products have implemented accounting methods for analyzing the value of business processes, and the most popular of these is activity-based costing (ABC). It assigns costs to each step in the process according to the amount of resource consumed. These costs are then associated with the end product of the process along with any overhead costs. The purpose of ABC is to arrive at the true cost of a product and each of the steps within the process that creates it. It assists in calculating competitive pricing for any product based on accurate information, for developing budgets and also just to measure the overall performance of the business processes. It identifies the origin of the costs, how effectively resources are being used and where resources add the most value. The ABC fits very well into the business modeling environment as it requires the cooperation of all levels of a business to understand how things are done and why.

Object-orientated methodologies

Object-oriented analysis and design methodologies take full advantage of the object approach when it comes to modeling the objects in a system. However, system behavior continues to be modeled using essentially the same tools as in traditional systems analysis such as state diagrams and dataflow diagrams (DFDs).

State diagrams

State diagrams are often used to represent the dynamic behavior of systems. The circles in a state diagram correspond to states of the system being modeled, and the arcs connecting those circles correspond to the events, which result in transitions between those states. The state diagram thus defines a set of possible sequences of events and states. Each state diagram must include at least one initial state and one final state (double circle). All sequences must begin with an initial state and continue until they terminate with a final state.

The set of states included in a state diagram can be thought of as a one-dimensional attribute space where the single attribute has values, which correspond to the possible states. A system behavior corresponds to a sequence of these states and each state diagram defines a process, that is, a set of such behaviors. For example, the state diagram permits the event sequences ac, abac, ababac, abababac, and so on. This entire set of sequences can be described by the regular expression a(ba)*c (refer Figure 5.18).

Figure 5.18. State diagram as a class of possible event sequences
Dataflow diagrams

Dataflow diagrams are intended to show the functionality of a system: the various processes, and the flows of information and material which link them to each other, to inventories (data stores) and to various agents external to the system. A DFD consists of a collection of processes, stores and terminators linked by flows (refer Figure 5.19).

Figure 5.19. Dataflow diagram (order processing)

Processes, shown as circles in the DFD, are the component actions or sub processes which together constitute the overall process or system being represented in the diagram. Each process transforms a set of inputs into outputs or outgoing flows e.g. receive order as input (a flow of orders) and produces (as outputs) order detail, billing information, and notification of invalid orders.

Stores, represented by pairs of parallel lines in the DFD, are repositories of the data or material carried in the flows. An incoming flow represents an update to a store (additional data or material), a modification to existing data or the deletion of data. An outgoing flow represents access to the data or material in a store. In the case of physical material, an outgoing flow represents an actual transfer of material from the store. In the case of information, an outgoing flow is a non-destructive read of the data in the store. The invoices store is updated by a flow of billing information from the receive order process and is a source of customer and invoice information for the collect payments process.

Terminators, shown as rectangles in the DFD, represent the actors, which interact with the various system processes. Terminators may be sources of information and material which flow into the system, and may also receive information and material, which flow out of the system. For example, customers are a source of orders, payments and payment inquiries. Customers also receive invoices, statements and notification of invalid orders.

Flows, shown as arrows in the DFD, represent the movement of information or material between processes, terminators and stores. A flow can diverge into several sub-flows (duplicate data/material is being carried in each sub-flow, or the data/material has been split into separate components each of which is carried in a sub-flow) and several flows can converge into a single super-flow (carries an aggregate of the data/material contained in the individual flows). A typical flow is 'orders' which carries orders from customers to the receive order process.

Based on specific requirements one can choose suitable products. When multiple functionalities are required, products must be chosen carefully so that it will provide the benefit of an integrated CASE tool.

Some of the well-known business process modeling tool products includes:

Product Supplier
ARIS IDS Prof Scheer
BPWin Computer associates
Provision Winsoft
Visio 2000 Microsoft
Designer 2000 Oracle

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780750662727500087

Database Development Process

Ming Wang , Russell K. Chan , in Encyclopedia of Information Systems, 2003

I.G. Case Tools

CASE stands for computer-aided software engineering. CASE tools can be applied to support database development. There are three types of CASE tools: upper-CASE, lower-CASE, and integrated CASE tools:

1.

The upper-CASE tool supports database planning and design including data collection and analysis, data model generation and application design.

2.

The lower-CASE tool supports database implementation including data conversion, report generation, application code generation, prototyping, and testing.

3.

The integrated CASE tool supports all phases of database development and provides the functionality of both upper-CASE and lower-CASE in one tool.

CASE tools were created to improve the productivity and quality of database development. The advantages of using them are:

•

Promoting the standards for database development for data, diagrams, documentation, and projects, making them easy to reuse and maintain

•

Keeping data linked, consistent and integrated for the organization

•

Reducing database development time since some CASE tools can automatically generate diagrams and application of an executable code based on the design

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B0122272404000265

Automatic synthesis of SDL models in Use Case Methodology

N. Mansurov , D. Zhukov , in SDL '99, 1999

Formal description techniques (FDT's) supported by computer-aided software engineering (CASE) tools are rapidly evolving as a response to the new challenges of the telecommunications industry, especially the need to improve "time-to-market" of software products. In this paper we summarize our experience in using automatic synthesis of formal models in ITU-T standard Specification and Description Language (SDL) to speed-up the software development process. Suggested accelerated methodology requires formalization of functional scenarios (use cases) using another ITU-T standard - Message Sequence Charts (MSC) extended with data operations. Our Moscow Synthesizer Tool (MOST-SDL) provides a bridge from MSC models to SDL executable specifications which can be simulated using SDL tools to provide an early feedback for the phases of requirements analysis, system analysis or system design. We present our synthesis algorithm, provide comparison with related work and discuss the results of a few case studies where the Moscow Synthesizer Tool was used together with Telelogic SDL tools for an accelerated MSC-based prototyping which involved incremental synthesis, validation and simulation of the formal model.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780444502285500163

Database Auditing

Craig Wright , in The IT Regulatory and Standards Compliance Handbook, 2008

Tools

The tools used to audit databases range from CASE (Computer Aided Software Engineering) Tools through to the more familiar network and system test tools covered throughout the book. In addition to the database itself, it is important to test:

1

File system controls and permission

2

Service initialization files

3

The connection to the database (such as access rights and encryption).

Specialized Audit software

Three popular database auditing solutions include:

▪

DB Audit (SoftTree Technologies)

▪

Audit DB (Lumigent Technologies)

▪

DbProtect (Application Security)

DB Audit (www.softtreetech.com/) is easy to tailor and does not require installation of any additional software or services on the database server or network. It supports Oracle, Microsoft SQL Server, Sybase ASE, Sybase ASA and IBM DB2. It is implemented on the database back-end to reduce the risk of back door access that would be unrecorded.

Lumigent Audit DB (www.lumigent.com/) provides comprehensive monitoring and auditing of data access and modifications. It provides an audit trail of who has accessed or modified what data, and supports best auditing practices including segregation of duties. Audit DB supports IBM DB2, Microsoft SQL Server, Oracle and Sybase databases.

DbProtect by Application Security (www.appsecinc.com/products/dbprotect/) uses a network-based, vulnerability assessment scanner to test database applications. It also provides structured risk mitigation, and real-time intrusion monitoring, coupled with centralized management and reporting. DbProtect provides security and auditing capabilities for complex, diverse enterprise database environments.

CASE (Computer-Aided Software Engineering) Tools

Case tools can be a great aid to auditing database systems. CASE or Computer Assisted Software Engineering tools not only help in the development of software and database structures but can be used to reverse engineer existing databases and check them against a predefined schema. There are a variety of both open source and commercial CASE tools. In this chapter we'll be looking at Xcase (www.xcase.com/).

Many commercial databases can run into the gigabyte or terabyte in size. Standard command line SQL coding is unlikely to find all of the intricate relationships between these tables, stored procedures and other database functions. A CASE tool on the other hand can reverse engineer existing databases to produce diagrams that represent the database. These can first of all be compared with existing schema diagrams to ensure that the database matches the architecture that it is originally built from and to be able to quickly zoom in on selected areas.

Visual objects, colors and better diagrams may all be introduced to further enhance the auditor's capacity to analyze the structure. Reverse engineering a database will enable the auditor to find out the various structures that have been created within the database. Some of these include:

▪

The indexes

▪

Fields

▪

Relationships

▪

Sub-categories

▪

Views

▪

Connections

▪

Primary keys and alternate keys

▪

Triggers

▪

Constraints

▪

Procedures and functions

▪

Rules

▪

Table space and storage details associated with the database

▪

Sequences used and finally the entities within the database

Each of the tables will also display detailed information concerning the structure of each of the fields that may be viewed at a single glance. In large databases a graphical view is probably the only method that will adequately determine if relationships between different tables and functions within a database actually meet the requirements (see Figure 15.1). It may be possible in smaller databases to determine the referential integrity constraints between different fields, but in a larger database containing thousands of tables, there is no way to do this in a simple manner using manual techniques.

Figure 15.1. Display Database Schema

When you are conducting an audit of a database for compliance purposes, it is not just security functions such as cross-site scripting and sequel injection that need to be considered. Relationships between various entities and the rights and associated privileges that are associated with various tables and roles also need to be considered. The CASE tools allow us to visualize the most important security features associated with a database. These are:

1

Schemas restrict the views of the database for users,

2

Domains, assertions, checks and other integrity controls defined as database objects which may be enforced using the DBMS in the process of database queries and updates,

3

Authorization rules. These are rules which identify the users and roles associated with the database and may be used to restrict the actions that a user can take against any of the database features such as tables or individual fields,

4

Authentication schemes. These are schemes which can be used to identify users attempting to gain access to the database or individual features within the database.

5

User defined procedures which may define constraints or limitations on the use of the database,

6

Encryption processes. Many compliance regimes call for the encryption of selected data on the database. Most modern databases include encryption processes that can be used to ensure that the data is protected.

7

Other features such as backup, check point capabilities and journaling help to ensure recovery processes for the database. These controls aid in database availability and integrity, two of the three legs of security.

CASE tools also contain other functions that are useful when auditing a database. One function that is extremely useful is model comparison. Figure 15.2 is an example of reverse engineering databases into diagrams.

Figure 15.2. Reverse Engineer Existing Databases into Presentation-Quality Diagrams in Minutes

Case tools allow the auditor to:

▪

Present clear data models at various levels of detail using visual objects, colors and embedded diagrams to organize database schemas,

▪

Synchronize models with the database,

▪

Compare a baseline model to the actual database (or to another model),

Case tools can generate code automatically and also store this for review and baselining. This includes:

▪

DDL Code to build and change the database structure

▪

Triggers and Stored Procedures to safeguard data integrity

▪

Views and Queries to extract data

The auditor can also document the database design using multiple reporting options. This allows for the printing of diagrams and reports and the addition of comments to the reports and user defined attributes to the model.

Data management features allow the auditor to validate the data in the database being reviewed against the business rules and constraints defined in the model and generate detailed integrity reports. This can be extended further to access and edit the data relationally using automatic parent/child browsers and lookups and then to locate faulty data subsets using automatically generated SQL statements. These provide valuable sources of errors and help in database maintenance – making the audit all the more valuable.

Model comparison involves comparing the model of the database with the actual database on the system. This can be used to ensure change control or to ensure that no unauthorized changes have been made for other purposes. To do this, a baseline of the database structure will be taken at some point in time. At a later time the database could be reverse engineered to create another model and these two models could be compared. Any differences, variations or discrepancies between these would represent a change. Any changes should be authorized changes and if not, should be investigated. Many of the tools also have functions that provide detailed reports of all discrepancies.

Many modern databases run into the terabytes and contain tens of thousands of tables. A baseline and automated report of any differences, variations or discrepancies makes the job of auditing change on these databases much simpler. Triggers and stored procedures can be stored within the CASE tool itself. These can be used to safeguard data integrity. Selected areas within the database can be set up such as honeytoken styled fields or views that can be checked against a hash at different times to ensure that no-one has altered any of these areas of the database. Further in database tables it should not change. Tables of hashes may be maintained and validated using the offline model that has stored these hash functions already. Any variation would be reported in the discrepancy report.

Next the capability to create a complex ERD or Entity Relationship Diagram in itself adds value to the audit. Many organizations do not have a detailed structure of the database and these are grown organically over time with many of the original designers having left the organization. In this event it is not uncommon for the organization to have no idea about the various tables that they have on their own database.

Another benefit of CASE tools is their ability to migrate data. CASE tools have the ability to create detailed SQL statements and to replicate through reverse engineering the data structures. They can then migrate these data structures to a separate database. This is useful as the data can be copied to another system. That system may be used to interrogate tables without fear of damaging the data. In particular the data that has migrated to the tables does not need to be the actual data, meaning that the auditor does not have access to sensitive information but will know the defenses and protections associated with the database. This is useful as the auditor can then perform complex interrogations of the database that may result in damage to the database if it was running on the large system. This provides a capability for the auditor to validate the data in the database against the business rules and constraints that have been defined by the models and generate detailed integrity reports. This capability gives an organization advanced tools that will help them locate faulty data subsets through the use of automatically generated SQL statements.

Vulnerability Assessment Tools

Any database sits on top of another operating system. As such tools such as NMAP may be used to check for open ports on the database system and determine if there are other services running on the host. This is important as standards (such as PCI-DSS) call for the restriction of other services to the host allowing only those that are necessary. This means that the database has to be a bastion.

That is the system needs to be built for purpose and should not be shared with other applications. Next vulnerability and assessment tools ranging from Nessus through to commercial assessment tools such as CORE IMPACT may be used to check the database for a variety of vulnerabilities. Nessus for instance has a variety of plug-ins associated with Oracle, Microsoft SQL and My SQL databases. These plug ins allow Nessus to check for vulnerabilities associated with these particular database systems as well as also checking for application vulnerabilities and operating system vulnerabilities that may be associated with the system and may affect the database. Further, many of the database vendors also provide free tools. Microsoft SQL server comes with the SQL server analyzer. This product looks at the best practices for the SQL database and can analyze against these best practice statements.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9781597492669000151

Introduction

Carol Britton , Jill Doake , in A Student Guide to Object-Oriented Development, 2005

UML and CASE tools.

One of the advantages of a standardized language for producing diagrams during system development is that a number of CASE tools have been developed to provide automated support for developers.

CASE (Computer Aided Software Engineering) refers to any piece of software that has been designed to help people develop systems. In theory, a CASE tool can be a simple drawing program or basic debugger, but today almost all CASE tools cover the whole of the system life cycle, and provide automated support for all development activities, both technical and managerial. For object-oriented systems, tools such as Rational Rose™ and Together™ allow developers to produce UML models of the system which are syntactically correct, consistent with each other and which can be refined and developed to produce executable code. The diagrams in this book were originally produced using both Rational Rose™ and Together™, but the code has been written from scratch in order to show how the system develops from diagrams to code, and to emphasize certain points that we think are important when you are learning about object-oriented development. However, it would have been perfectly possible to generate the skeleton of a running program from the diagrams shown here. Even though we did not use this facility, we still benefited from the 'nanny' characteristics of the CASE tools, which remembered details of previous diagrams, allowed us to navigate between diagrams that were related, and pointed out when we made stupid mistakes.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780750661232500013

Normalization

Toby Teorey , ... H.V. Jagadish , in Database Modeling and Design (Fifth Edition), 2011

Boyce-Codd Normal Form

Third normal form, which eliminates most of the anomalies known in databases today, is the most common standard for normalization in commercial databases and computer-aided software engineering (CASE) tools. The few remaining anomalies can be eliminated by the Boyce-Codd normal form. Boyce-Codd normal form is considered to be a strong variation of 3NF.

A table R is in Boyce-Codd normal form (BCNF) if for every nontrivial FD X ->A, X is a superkey.

BCNF is a stronger form of normalization than 3NF because it eliminates the second condition for 3NF, which allowed the right side of the FD to be a prime attribute. Thus, every left side of an FD in a table must be a superkey. Every table that is BCNF is also 3NF, 2NF, and 1NF, by the previous definitions.

The following example shows a 3NF table that is not BCNF. Such tables have delete anomalies similar to those in the lower normal forms.

Assertion 1: For a given team, each employee is directed by only one leader. A team may be directed by more than one leader.

emp_name, team_name -> leader_name

Assertion 2: Each leader directs only one team.

leader_name -> team_name

The following table is 3NF with a composite candidate key (emp_name, team_name).

team: emp_name team_name leader_name
Sutton Hawks Wei
Sutton Condors Bachmann
Niven Hawks Wei
Niven Eagles Makowski
Wilson Eagles DeSmith

The team table has the following delete anomaly: If Sutton drops out of the Condors team, then we have no record of Bachmann leading the Condors team. As shown by Date (2003), this type of anomaly cannot have a lossless decomposition and preserve all FDs. A lossless decomposition requires that when you decompose the table into two smaller tables by projecting the original table over two overlapping subsets of that table, the natural join of those subset tables must result in the original table without any extra unwanted rows. The simplest way to avoid the delete anomaly for this kind of situation is to create a separate table for each of the two assertions. These two tables are partially redundant, enough so to avoid the delete anomaly. This decomposition is lossless (trivially) and preserves functional dependencies, but it also degrades update performance due to redundancy, and necessitates additional storage space. The trade-off is often worth it because the delete anomaly is avoided.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123820204000100

Perceptions of strategic value and adoption of e-Commerce: a theoretical framework and empirical test

Elizabeth E. Grandón , J. Michael Pearson , in Value Creation from E-Business Models, 2004

CASE

Adoption of CASE has also been addressed in the IT adoption literature. Premkumar and Potter (1995) examined the impact of various organizational and technology characteristics on the adoption of CASE tools. Within the organizational factors, they considered top management support, product champion, and IS expertise. The variables included in the technical factor were relative advantage, cost, complexity, technical compatibility, and organizational compatibility. Ninety IS managers participated in the field survey. Results revealed that the existence of a product champion, strong top management support, lower IS expertise, relative advantage of CASE technology over other alternatives, and a conviction of the cost effectiveness of the technology were found to be strong indicators of the adoption of CASE tools.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780750661409500102

Model-Driven Reverse Engineering of COBOL-Based Applications

Franck Barbier , ... Eric Cariou , in Information Systems Transformation, 2010

Lessons learned

The first phase (the extraction phase) required 4 man-months (2 persons). This was to design and perfect the reverse engineering method while making slight implementation amendments in the CASE tool possible. To obtain appropriate knowledge, support, and any kind of access to the SCAFRUITS application, a half man-month support was provided by STIME. Minor modifications of the REVERSE component of BLU AGE® occurred during this first stage. The unique result of this phase was a beta "industrial" version of this component. The application-independent nature of the process leads to success, even though a functional subset of SCAFRUITS was used for the experimentation.

The second phase is an ongoing phase (3 months). This phase covers the interpretation and publication phases. This last phase includes BLU AGE® training and the construction of BLU AGE® models within Eclipse to be reverse engineered and implemented in Java or .NET for the product referencing and product ordering use cases. Each TP requires 2 man-days of support and each batch process requires 1 man-day of support from each side (BLU AGE® expert group and STIME).

Even though the manual building of models within BLU AGE® is strongly inspired by the success of the commented output of the reverse engineering process, a significant gap in research and development remains. The goal is to obtain maximum automation.

Read full chapter

URL:

https://www.sciencedirect.com/science/article/pii/B9780123749130000111