CASE and Automated Techniques

CASE and Automated Techniques

CASE Defined

We have mentioned CASE (Computer-Aided Software Engineering) in previous chapters. Although its meanings can vary, CASE is traditionally defined as “a comprehensive label for software designed to use computers in all phases of computer development, from planning and modeling through coding and documentation. CASE represents a working environment consisting of programs and other development tools that help managers, systems analysts, programmers, and others automate the design and implementation of programs and procedures for business, engineering, and scientific computer systems.”19 CASE became popular during the late 1970s as a way of automating and integrating modeling tools. It also allows for the creation and maintenance of data repositories which provide organizations with a tool to establish a central place to store all of their data elements. Figure 10.1 shows the common components of most integrated CASE products.

Data Repository Inputs

The design of CASE is based on inputs which create entries into the data repository. A data repository can be defined as a “robust data dictionary.” A data dictionary essentially provides the definition of the data element itself. A data repository, on the other hand, stores information relating to the data element’s behavior. This can include the element’s stored procedures, descriptions, and documentation about how and where it is used. Therefore, the data dictionary can actually be considered a subset of the data repository. Inputs to the data repository are typically the modeling tools discussed in Chapter 5: DFDs, ERDs, STDs, and process specifications as well as the object oriented analysis discussed in Chapter 11. These input capabilities can be summarized as follows.

 

Figure 10.1 Components of CASE.

Data Flow Diagrams (DFD)

Every named data flow will automatically require an entry into the data repository. This named flow may consist of other elements and therefore require functional decomposition down to the elementary data element level. Unique data elements that are components of data stores will also generate entries into the data repository. Figures 10.2 and 10.3 show these interfaces in the Popkin System Architect CASE product.

Entity Relational Diagrams (ERD)

The ERD interfaces with the data repository by mapping an element to particular tables (entities), that is, each unique data element within an entity points to a data repository definition (see Figure 10.4).

State Transition Diagram (STD)

The STD interfaces with the data repository via the “conditions that cause a change in state.” These condition arrows map to the data repository and allow component elements to be defined as shown in Figure 10.5.

Figure 10.2 CASE flow elements. The above diagram shows how a data flow is defined by its elementary data elements.

Figure 10.3 CASE data flow definition. The above diagram shows how the data compo- nents of the Vendor_Invoice flow define each data element in the repository.

Figure 10.4 CASE entity attributes. This figure reflects how the Orders entity is defined by its component data attributes. These attributes then point to their respective data elements in the data repository.

Figure 10.5 CASE STD data element definition. The above diagram shows how the condition-arrow “Enter Valid Bank Card” in an STD points to its component data attributes. These attributes are then defined as data elements in the data repository.

Process Specifications

Process Specifications are typically defined via the functional primitive process of the DFD or a particular state in an STD. The example in Figure 10.6 reflects how this is done using a DFD. Once the process specification is defined, data elements embedded in the application logic are mapped to the data repository.

The OO paradigm is also supported by CASE where objects can store both attributes and methods and point data element definitions into the data repository (Figure 10.7).

Data Repository Outputs

CASE outputs provide links to physical products and services. Its capabilities therefore allow for the storage of various design-specific features that can automatically produce output that can then be used by other products. The rest of this section describes the features in each of the areas shown in Figure 10.1 schema generation; product code generation; prototypes; and documentation and reports.

Figure 10.6 CASE process specification. The process specification above in System Architect is mapped to a process in a DFD called “Record and Pay Vendor Invoices.” The algorithm of the process is defined and any elements used in the process specification must point to its data element definition in the data repository.

Figure 10.7 CASE object. This figure diagrams the creation of an object/class which points to an attribute of an object that then points to the data repository definition of the element itself.

Schema Generation

The schema generation facility in CASE allows various interfaces with physical database products. These schemas include support for most of the popular database products such as Oracle, Sybase, Informix, Microsoft’s SQL_Server, and DB2. A schema is defined as the description of the data elements in the format necessary for a particular RDBMS product. Most of the databases just mentioned support SQL (Structured Query Language) data type identifiers as shown in Figure 10.8.

Product Code Generation

Product Code Generation relates to storing specific information needed by programming products such as Power builder and C++ (see Figure 10.9). This information, similar to the process in schema generation, allows the analyst to export information directly into the intended product. The ability to store multiple product definitions also provides a central capability to provide information about a data element for different product languages. This translates to providing a mechanism to support multiple development environments and languages without the need to have the definition given only in the programming language code.

Figure 10.8 CASE schema generation. This diagram shows the Orders entity and how definitions specific for Oracle schema generation can be stored.

Figure 10.9 CASE program interface. This is an example of how CASE can store data element information for the Powerbuilder programming product.

Prototypes

Prototypes are usually screens and reports that are produced so that users can get a visual view of the system. Prototypes do not actually work; they are like cars with no engines. CASE prototypes can range in capabilities from simple views of the way a screen or report will look to an actual demonstration of the application’s functional capabilities. These demonstration capabilities can provide a way of linking screens with the data repository to show the “look and feel” of the application to the user. In addition, certain CASE products allow screen and report information to be directly ported into a development language (see Figure 10.10).

Documentation and Reports

CASE provides both documentation and reports to reflect the information stored in the data repository. The information can range from a simple data element report to more sophisticated comparison information (e.g., missing data element descriptions), as Figure 10.11 illustrates.

Figure 10.10 CASE screen painter. The above diagram shows the screen painter properties of System Architect. The data elements contained in the screen are mapped to the data repository and therefore contain their appropriate definitions.

Figure 10.11 CASE report writer. The above screen shows the report menu from System Architect.

The data repository of CASE is therefore the central component of the product and serves to store all related information of a particular data element. A data element in the data repository does not necessarily need to belong to any entity, schema, prototype or program product, but rather it may be an independent piece of information. However, CASE provides an easier way to make a data element associated with an entity, schema, prototype, and so on, without losing this independence. The integration facility of CASE allows analysts to modify the definitions of a data element and have that change propagated throughout the data repository.

Why Does CASE Fail?

Unfortunately, many of the implementations of CASE during the 1980s were not successful. Information systems professionals began to shy away from its use. The reasons for this are very straightforward:

• Organizations were not properly trained how to use structured tools.

• CASE products did not comply with GUI (Graphic User Interface) and therefore were not robust.20

• CASE products were methodology driven, and therefore required the organization to commit to a particular approach. Such approaches did not typically conform to the organization’s culture.

• There were limited third party product interfaces to enable efficient

transfer from logical models to physical products and databases.

Perhaps the CASE transition was bound to occur in a slow and methodical manner. Many organizations could not afford to buy the popular CASE products then that included Knowledgeware, Excellerator and IEF (Information Engineering Facility). Those who did buy them still feel scarred, and even today CASE is considered a bad word in some circles.

A key factor in the success of CASE is understanding where and when to use it in the software implementation cycle. To determine this point, the table in Figure 8.3 is a replication of the table of the Tiers of Analysis and Software Application Development developed in Chapter 1. This table can also be used to compare or map the analyst’s proficiency level to that of the software development process being used.

The table shows that CASE should not be considered until tier 3, that is, until an analyst is proficient with the user interface and the structured tools. CASE can then be used as a way of automating the analysis process. By automating portions of the analysis functions, organizations can thus become more productive when modeling systems.

Why CASE Should Succeed

Using CASE is the only means of creating and maintaining any central storage of information for enterprise level systems. Today, the CASE products are far more robust, contain the GUI interface and allow for the handling of multiple analysis methodologies. Analysts can therefore create data repositories as they see fit for their organizations. In addition, there are many database and development third party products that can be linked to CASE. Many companies like Oracle now produce their own CASE products (Oracle Designer/2000) that are focused on creating even more interfaces between data repositories and the Oracle RDBMS. Frankly, an IT organization that does not consider CASE cannot provide the long-term support for many of the features and capabilities required by the applications of the future. These applications will be based on the OO paradigm and client/server computing. Perhaps the most significant advantage to CASE is in the area of maintenance. Definitions of quality software have included the word “maintenance” for decades: systems that are difficult to maintain will not be considered quality systems. When there is a central repos- itory of data as well as defined processes, the maintenance of both databases and applications becomes easier and more productive. The data repository also allows both analysts and developers to use CASE as a means of training and documenting existing systems. Having new programmers use an automated tool to see the contents of each entity and how the data is used in an application provides IT organizations with greater flexibility and productivity for future enhancements.

Open Systems Requirements and Client/Server

Perhaps the most significant support for today’s use of CASE is Open Systems architecture. Open systems architecture can be defined as a set of standards for both hardware and software that allows portability of applications and databases. Open systems architecture includes such operating systems as UNIX, LINUX, Windows and Windows NT, DOS and Netware. These operating systems support the standards in application software that allow such software to run across one another’s operating systems. Although this concept is not fully transparent, application developers have enjoyed more portability of their code than ever before. The software industry will continue to support open systems, especially through the use of OO technology. Essentially, without CASE it is impossible to support the open systems model. In order for an IS organization to be compliant with open systems, it must have the ability to store data elements free from specific hardware and software products, that is, it must not be proprietary.

Client/server even further strengthens the need to use CASE. Built on the basis of open systems and OO, client/server establishes the need for additional standards in the area of object interfaces across LANs and WANs. The use of the Internet as a key component of the future for IT processing is also constructed on the basis of OO and client/server concepts. The analysis proficiency skills tiers (Figure 10.12) showed us that CASE is a prerequisite for OO and client/server. Chapter 11 will demonstrate that OO is constructed via the structured tools and that client/server is developed after determining the appropriate objects and classes. None of these links can be accomplished without a central point of control, evaluation and reconciliation, all of which CASE provides to us.

We mentioned above that client/server established new needs for standards for communicating among and WANs. Much of this interface is called

Figure 10.12 Analyst Proficiency Skills Correlation.

middleware. Middleware contains the necessary APIs (application program interface), protocols, metadata, gateways and object messaging necessary to provide communication across client/server networks. The driving force behind middleware is that today’s applications must communicate with other appli- cations and databases without knowing one another’s hardware and software configurations. This means that the middleware must contain information for the client or server about what data is being sent or received respectively. For example, without knowing the receiving application’s programming language, middleware must provide the details of the layout of data being sent. This data layout is defined in the metadata (data about the data) facility of the middleware. The components of open systems and client/server architecture are shown below in the client/server three tier architecture depicted in Figure 10.13.

Our discussions of CASE can be mapped to every tier of the client/server architecture. CASE thus provides the underlying facility to record information and data to build such systems.

Types of CASE Tools

The CASE components which comprise analysis and design capabilities are typically known as Upper-CASE. Many CASE products may provide only the

Figure 10.13 Client/server three tier architecture.

input side that has been shown. CASE products that also provide for output to the physical product side are known as Lower-CASE. Once again, there are CASE products that do not provide the analysis tools but rather only a data repository to create outputs. These CASE products are also known as Code Generators. CASE products that do both the input analysis and output generation are known as I- CASE or Integrated CASE. I-CASE tools will continue to become more popular as open systems and client/server architectures become more widely used.

CASE tools should also support multiple data repositories. This means that some repositories can be either mutually exclusive or dependent as children in a tree structure. Mutually exclusive repositories simply mean that there are multiple libraries of data elements that have no relationship with each other. This situation can occur in organizations that have different business lines or subsidiaries that are in different businesses. Mutually exclusive libraries should be created only if the analyst is sure that there is no need for an enterprise model.

Tree structure libraries are used more often. The tree of repositories allows an organization to have a central parent repository with all common data elements of the enterprise. Child libraries inherit the global definitions. Locally defined data elements will become only global if they are needed by at least two entities in the organization. Another use of the tree structure repositories is work-in- process. Specifically this means that new projects may create potentially new data elements to be added to the global data repository. This allows the IT organization to properly control any new entries into the global data repository until the project is completed or the data element candidate is approved by the appropriate people in the organization. In any event, good CASE products allow for this versatility, and it is recommended that analysts utilize such capabilities.

Reverse Engineering

Analysts will often be confronted with a system that is not in any existing CASE product. The issue then becomes the chicken- and-egg paradox: how do I create a data repository if the product already exists? Advanced CASE products typically contain a module that allows for reverse engineering. “Reverse Engineering is the process of analyzing existing application programs and database code to create higher-level representations of the code. It is sometimes called design recovery.”21 For example, reverse engineering features would allow for the input of an existing Oracle table into the CASE product. This input would result in the creation of a logical ERD and the creation of all the data elements into the data repository. In addition foreign key links, triggering operations and other stored procedures would automatically populate the appropriate repository areas. Reverse engineering therefore allows analysts to “start somewhere” and eventually to get the organization into forward engineering, that is, building physical products and databases directly from the CASE tool.

Problems and Exercises

1. Define the applications of a CASE tool.

2. What are the benefits of the input facilities of CASE? Of the output facilities?

3. Explain the concept of a data repository. How does it relate to the dictionary?

4. What is schema generation? Why is this important for forward engineering?

5. How does the data repository assist in the development of screen proto- types?

6. What is I-CASE? Explain.

7. What are the most important issues to ensure the success of CASE?

8. What are the five analysis proficiencies?

9. How does CASE relate to the implementation of object and client/server system?

10. What is a three tiered architecture?

11. Why is reverse engineering so prevalent in most IS organizations?