CASE Tools

Contents

1 Overview 2 History 3 Supporting software 3.1 Tools 3.2 Workbenches 3.3 Environments 4 Applications 5 Risks and associated controls 6 References 7 External links Computer-aided software engineering (CASE) is the scientific application of a set of tools and methods to a software system which is meant to result in high-quality, defect-free, and maintainable software products.[1] It also refers to methods for the development of information systems together with automated tools that can be used in the software development process.[2]

Overview
The term "Computer-aided software engineering" (CASE) can refer to the software used for the automated development of systems software, i.e., computer code. The CASE functions include analysis, design, and programming. CASE tools automate methods for designing, documenting, and producing structured computer code in the desired programming language. Computer Aided Software Engineering (CASE) software supports the software process activities such as requirement engineering, design, program development and testing. Therefore, CASE tools include design editors, data dictionaries, compilers, debuggers, system building tools, etc. Computer Aided Software Engineering (CASE) also refers to the methods dedicated to an engineering discipline for the development of information system using automated tools. The case is mainly used for the development of quality softwares which will perform effectively.
History

The ISDOS project at the University of Michigan initiated a great deal of interest in the whole concept of using computer systems to help analysts in the very difficult process of analysing requirements and developing systems. Several papers by Daniel Teichroew fired a whole generation of enthusiasts with the potential of automated systems development. His PSL/PSA tool was a CASE tool although it predated the term. His insights into the power of meta-meta-models was inspiring, particularly to a former student, Dr. Hasan Sayani, currently Professor, Program Director at University of Maryland University College. Another major thread emerged as a logical extension to the DBMS directory. By extending the range of meta-data held, the attributes of an application could be held within a dictionary

and used at runtime. This "active dictionary" became the precursor to the more modern "model driven execution" (MDE) capability. However, the active dictionary did not provide a graphical representation of any of the meta-data. It was the linking of the concept of a dictionary holding analysts' meta-data, as derived from the use of an integrated set of techniques, together with the graphical representation of such data that gave rise to the earlier versions of I-CASE. The term CASE was originally coined by software company Nastec Corporation of Southfield, Michigan in 1982 with their original integrated graphics and text editor GraphiText, which also was the first microcomputer-based system to use hyperlinks to crossreference text strings in documentsan early forerunner of today's web page link. GraphiText's successor product, DesignAid, was the first microprocessor-based tool to logically and semantically evaluate software and system design diagrams and build a data dictionary. Under the direction of Albert F. Case, Jr. vice president for product management and consulting, and Vaughn Frick, director of product management, the DesignAid product suite was expanded to support analysis of a wide range of structured analysis and design methodologies, notably Ed Yourdon and Tom DeMarco, Chris Gane & Trish Sarson, WardMellor (real-time) SA/SD and Warnier-Orr (data driven). The next entrant into the market was Excelerator from Index Technology in Cambridge, Mass. While DesignAid ran on Convergent Technologies and later Burroughs Ngen networked microcomputers, Index launched Excelerator on the IBM PC/AT platform. While, at the time of launch, and for several years, the IBM platform did not support networking or a centralized database as did the Convergent Technologies or Burroughs machines, the allure of IBM was strong, and Excelerator came to prominence. Hot on the heels of Excelerator were a rash of offerings from companies such as Knowledgeware (James Martin, Fran Tarkenton and Don Addington), Texas Instrument's IEF and Accenture's FOUNDATION toolset (METHOD/1, DESIGN/1, INSTALL/1, FCP). CASE tools were at their peak in the early 1990s. At the time IBM had proposed AD/Cycle, which was an alliance of software vendors centered around IBM's Software repository using IBM DB2 in mainframe and OS/2: The application development tools can be from several sources: from IBM, from vendors, and from the customers themselves. IBM has entered into relationships with Bachman Information Systems, Index Technology Corporation, and Knowledgeware, Inc. wherein selected products from these vendors will be marketed through an IBM complementary marketing program to provide offerings that will help to achieve complete life-cycle coverage.[3] With the decline of the mainframe, AD/Cycle and the Big CASE tools died off, opening the market for the mainstream CASE tools of today. Nearly all of the leaders of the CASE market of the early 1990s ended up being purchased by Computer Associates, including IEW, IEF, ADW, Cayenne, and Learmonth & Burchett Management Systems (LBMS).
Supporting software

Alfonso Fuggetta classified CASE into 3 categories:[4] 1. Tools support only specific tasks in the software process. 2. Workbenches support only one or a few activities. 3. Environments support (a large part of) the software process.

Workbenches and environments are generally built as collections of tools. Tools can therefore be either stand alone products or components of workbenches and environments. Tools CASE tools are a class of software that automate many of the activities involved in various life cycle phases. For example, when establishing the functional requirements of a proposed application, prototyping tools can be used to develop graphic models of application screens to assist end users to visualize how an application will look after development. Subsequently, system designers can use automated design tools to transform the prototyped functional requirements into detailed design documents. Programmers can then use automated code generators to convert the design documents into code. Automated tools can be used collectively, as mentioned, or individually. For example, prototyping tools could be used to define application requirements that get passed to design technicians who convert the requirements into detailed designs in a traditional manner using flowcharts and narrative documents, without the assistance of automated design software.[5] Existing CASE tools can be classified along 4 different dimensions: 1. 2. 3. 4. Life-Cycle Support Integration Dimension Construction Dimension Knowledge Based CASE dimension [6]

Let us take the meaning of these dimensions along with their examples one by one : Life-Cycle Based CASE Tools This dimension classifies CASE Tools on the basis of the activities they support in the information systems life cycle. They can be classified as Upper or Lower CASE tools. Upper CASE Tools: support strategic, planning and construction of conceptual level product and ignore the design aspect. They support traditional diagrammatic languages such as ER diagrams, Data flow diagram, Structure charts, Decision Trees, Decision tables, etc. Lower CASE Tools: concentrate on the back end activities of the software life cycle and hence support activities like physical design, debugging, construction, testing, integration of software components, maintenance, reengineering and reverse engineering activities. Integration dimension Three main CASE Integration dimensions have been proposed:[7] 1. CASE Framework 2. ICASE Tools 3. Integrated Project Support Environment(IPSE) Workbenches Workbenches integrate several CASE tools into one application to support specific softwareprocess activities. Hence they achieve: a homogeneous and consistent interface (presentation integration). easy invocation of tools and tool chains (control integration).

 access to a common data set managed in a centralized way (data integration). CASE workbenches can be further classified into following 8 classes:[4] 1. 2. 3. 4. 5. 6. 7. 8. Business planning and modeling Analysis and design User-interface development Programming Verification and validation Maintenance and reverse engineering Configuration management Project management

Environments An environment is a collection of CASE tools and workbenches that supports the software process. CASE environments are classified based on the focus/basis of integration[4] 1. 2. 3. 4. 5. Toolkits Language-centered Integrated Fourth generation Process-centered

Toolkits Toolkits are loosely integrated collections of products easily extended by aggregating different tools and workbenches. Typically, the support provided by a toolkit is limited to programming, configuration management and project management. And the toolkit itself is environments extended from basic sets of operating system tools, for example, the Unix Programmer's Work Bench and the VMS VAX Set. In addition, toolkits' loose integration requires user to activate tools by explicit invocation or simple control mechanisms. The resulting files are unstructured and could be in different format, therefore the access of file from different tools may require explicit file format conversion. However, since the only constraint for adding a new component is the formats of the files, toolkits can be easily and incrementally extended.[4] Language-centered The environment itself is written in the programming language for which it was developed, thus enabling users to reuse, customize and extend the environment. Integration of code in different languages is a major issue for language-centered environments. Lack of process and data integration is also a problem. The strengths of these environments include good level of presentation and control integration. Interlisp, Smalltalk, Rational, and KEE are examples of language-centered environments.[4] Integrated These environments achieve presentation integration by providing uniform, consistent, and coherent tool and workbench interfaces. Data integration is achieved through the repository concept: they have a specialized database managing all information produced and accessed in

the environment. Examples of integrated environment are IBM AD/Cycle and DEC Cohesion.[4] Fourth-generation Fourth-generation environments were the first integrated environments. They are sets of tools and workbenches supporting the development of a specific class of program: electronic data processing and business-oriented applications. In general, they include programming tools, simple configuration management tools, document handling facilities and, sometimes, a code generator to produce code in lower level languages. Informix 4GL, and Focus fall into this category.[4] Process-centered Environments in this category focus on process integration with other integration dimensions as starting points. A process-centered environment operates by interpreting a process model created by specialized tools. They usually consist of tools handling two functions: Process-model execution Process-model production Examples are East, Enterprise II, Process Wise, Process Weaver, and Arcadia.[4]
Applications

All aspects of the software development life cycle can be supported by software tools, and so the use of tools from across the spectrum can, arguably, be described as CASE; from project management software through tools for business and functional analysis, system design, code storage, compilers, translation tools, test software, and so on. However, tools that are concerned with analysis and design, and with using design information to create parts (or all) of the software product, are most frequently thought of as CASE tools. CASE applied, for instance, to a database software product, might normally involve: Modeling business / real-world processes and data flow Development of data models in the form of entity-relationship diagrams Development of process and function descriptions
Risks and Associated Controls

Common CASE risks and associated controls include: Inadequate Standardization: Linking CASE tools from different vendors (design tool from Company X, programming tool from Company Y) may be difficult if the products do not use standardized code structures and data classifications. File formats can be converted, but usually not economically. Controls include using tools from the same vendor, or using tools based on standard protocols and insisting on demonstrated compatibility. Additionally, if organizations obtain tools for only a portion of the development process, they should consider acquiring them from a vendor that has a full line of products to ensure future compatibility if they add more tools.[5] Unrealistic Expectations: Organizations often implement CASE technologies to reduce development costs. Implementing CASE strategies usually involves high startup costs. Generally, management must be willing to accept a long-term payback

period. Controls include requiring senior managers to define their purpose and strategies for implementing CASE technologies.[5] Slow Implementation: Implementing CASE technologies can involve a significant change from traditional development environments. Typically, organizations should not use CASE tools the first time on critical projects or projects with short deadlines because of the lengthy training process. Additionally, organizations should consider using the tools on smaller, less complex projects and gradually implementing the tools to allow more training time.[5] Weak Repository Controls: Failure to adequately control access to CASE repositories may result in security breaches or damage to the work documents, system designs, or code modules stored in the repository. Controls include protecting the repositories with appropriate access, version, and backup controls.[5]

References

1. Kuhn, D.L (1989). "Selecting and effectively using a computer aided software engineering tool". Annual Westinghouse computer symposium; 6-7 Nov 1989; Pittsburgh, PA (USA); DOE Project. 2. P. Loucopoulos and V. Karakostas (1995). System Requirements Engineering. McGraw-Hill. 3. AD/Cycle strategy and architecture, IBM Systems Journal, Vol 29, NO 2, 1990; page 172 4. Alfonso Fuggetta (December 1993). "A classification of CASE technology". Computer 26 (12): 2538. doi:10.1109/2.247645. http://www2.computer.org/portal/web/csdl/abs/mags/co/1993/12/rz025abs.htm. Retrieved 2009-03-14. 5. Software Development Techniques. In: FFIEC InfoBase. Retrieved 26 Oct 2008. 6. Software Engineering : Tools, Principles and Techniques by Sangeeta Sabharwal, Umesh Publications 7. Evans R. Rock. Case Analyst Workbenches : A Detailed Product Evaluation. Volume 1 pp 229-242 What is a CASE Tool? CASE Tool is a class of software that automates many of the activities involved in various life cycle phases. For example, when establishing the functional requirements of a proposed application, prototyping tools can be used to develop graphic models of application screens to assist end users to visualize how an application will look after development. Subsequently, system designers can use automated design tools to transform the prototyped functional requirements into detailed design documents. Programmers can then use automated code generators to convert the design documents into code. Automated tools can be used collectively, as mentioned, or individually. For example, prototyping tools could be used to define application requirements that get passed to design technicians who convert the requirements into detailed designs in a traditional manner using flowcharts and narrative documents, without the assistance of automated design software. UMBRELLO A UML MODELING TOOL

Umbrello UML Modeler is a Unified Modeling Language diagram program for KDE. Umbrellos website Let us start with the class diagram. From all the UML tools Ive tried, its Umbrello that does the best class diagram. Everything you see in the diagram was done using the menu. Umbrello offer a great integration with UML. Ive not manually typed + balance : Dollars = 0 in the edit box. Ive chosen to add an attribute, then selected its datatype (in this case, adding the custom Dollars datatype), and finally selected the default value. This is something that every UML modeling tool should have. In fact, every great UML modeling tool do it this way! Now the problems starts. For the component diagram, I couldnt add the ports connectors nor the actor. Even if the actor icon is available in the use-case diagrams, Umbrello doesnt allow you to use elements from other diagram types. This probably help Umbrello provide some great features (which will be discussed later), but this is a big show stopper for drawing the diagrams correctly. I didnt even tried to draw the composite structure diagram, because this isnt a diagram type offered by Umbrello. And since its impossible to combine elements from different diagrams into one, I dont know how I could do it. Again, problems occurred for the deployment diagram. First, it wasnt possible to add the actor. Second, which is the biggest issue, you cannot bring to front or push to back elements! This means that if you want to superpose elements, you need to create them in the right order. Otherwise, it wont display correctly. Like the MySQL database component and the Database Server node in my diagram, I cannot decide which one should be on top of the other. Umbrello does not offer an object diagram. The package diagram is doable, but its tricky. You cant create a new package directly. You must create a subsystem (which is a stereotype of a package diagram), then remove the stereotype from the properties of the package. I dont know why theyve done it this way. The other problem Ive encountered, is that you cant put the arrows (relations) where you want. I personally find that it create a clearer diagram when the arrows are in the middle of the elements, when possible. Unfortunately, Umbrello place the arrow for you and you cant move it. This is true in all the diagrams, not just in the package diagram. The activity diagram is OK, if we dont care about the arrow placement issue. The fork/join bar didnt displayed correctly. Instead, this black box was shown. I think that is may be a problem only with my configuration (KDE version, etc.). But this prevent me from using it anyway, which is a bad thing. Ive found another problem, again, related with the arrows. They dont follow the elements they are attached to. Normally, one would assume that if you move the final node, any arrow pointing to it would follow and stay connected, on both end. This isnt the case in Umbrello The arrow stand still. Again, this is true for all the diagrams. Another good example of how bad the arrows management is, its my state diagram. I cant move the arrow where I want. This result in an unreadable diagrams. Thats awfull. The use cases diagram was an easy one. But, dont move your elements!

I didnt tried to do the the last diagrams (communications, interaction overview and sequence). Since they arent available as-is in Umbrello, I dont think I could do them. So, even if Umbrello looked promising at first, there too many problems with the diagrams to be heavily used in day-to-day software development. This is unfortunate, since Umbrello include a couple of interesting features : Automatic code generation (Ada, C++, C#, Java, perl, PHP, Python, Ruby, etc.) Import classes Import project (Ada, C++, IDL, Java, Pascal and Python only)

REF: http://laurentparenteau.com/blog/2009/02/uml-modeling-tools-reviews-umbrello/