Unit - 4
Computer Aided Software Engineering (CASE) Tools
Q1) Define CASE?
A1) CASE
CASE stands for Engineering with Computer Assisted Applications. This implies, with the assistance of various automated development tools, designing and managing software projects.
CASE instruments may assist engineers with the work of evaluating, designing, coding and checking. Software engineering is hard work and there are major benefits to instruments that minimize the effort needed to create a work product or achieve a milestone.
CASE is used to verify that software is of high quality and free of defects. CASE helps designers, developers, testers, managers, and others recognise project milestones during development by ensuring a check-pointed and disciplined approach.
CASE can also serve as a repository for project papers such as business plans, requirements, and design specifications. One of the fundamental benefits of employing CASE is that the end product is more likely to match real-world needs because clients are kept informed throughout the process.
CASE depicts a wide range of time-saving tools used in software development. It creates a structure for project management and is useful for increasing productivity. Years ago, there was more interest in the concept of CASE tools; but, as the tools have evolved into other purposes, frequently in response to software developer needs, there is less interest today. CASE's premise was likewise heavily criticised after its initial release.
Q2) Write the advantages and disadvantages of CASE?
A2) Advantages
● The servicing cost of a product over its estimated lifetime is significantly lowered since extra emphasis is spent on redesign and testing.
● As a result of the systematic approach employed during the development phase, the overall quality of the product improves.
● With a computer-aided software engineering technique, meeting real-world criteria is more likely and easier.
● By assisting in the development of high-quality products, CASE gives a company an indirect competitive edge.
Disadvantages
● Cost: Using a case tool is extremely expensive. The majority of small businesses that build software do not invest in CASE tools because they believe that the benefits of CASE are only justified in the creation of large systems.
● Learning Curve: Because users need time to master the technology, programmers' productivity may suffer in the early stages of implementation. Many consultants provide training and on-site services, which can help speed up the learning process as well as the creation and application of CASE tools.
● Tool Mix: To gain a cost advantage, it's critical to create an optimal selection tool mix. The importance of CASE integration and data integration across all platforms cannot be overstated.
Q3) Write the parts of CASE tools?
A3) Based on their use at a specific SDLC stage, CASE tools can be broadly divided into the following parts:
● Central Repository - A central repository is required for CASE tools and can serve as a source of common, integrated and consistent information. The central repository is a central storage location where product specifications, requirement records, related reports and diagrams are stored, as well as other valuable management material. The central repository also acts as a data dictionary.
Fig 1: case tools
● Upper Case Tools - In the preparation, study and design phases of SDLC, the Upper-CASE instruments are used.
● Lower Case Tools - In deployment, monitoring and maintenance, Lower CASE tools are used.
● Integrated Case Tools - In all the phases of SDLC, from the selection of specifications to testing and documentation, integrated CASE resources are beneficial.
Q4) What are the steps of case tools implementation?
A4) Implementation features provided by CASE tools include:
● Visual representation of a system and its components is possible with diagramming tools.
● Allow for the representation of process flows.
● Assist in the implementation of data and programme structures.
● Support the production of system forms and reports automatically.
● Generation of ready-to-use prototypes.
● Both technical and user documentation is created.
● Create master templates for verifying documentation and its compliance with the Software Development Life Cycle (SDLC) at all stages .
● Enable the automatic development of programmes and databases from the repository's design papers, diagrams, forms, and reports.
Q5) Explain integrated case environments?
A5) The software process is supported by an environment, which is a collection of CASE tools and workbenches. The focus/basis of integration is used to classify CASE environments. These are, in order:
1. Toolkits
2. Language-centered
3. Integrated
4. Fourth generation
5. Process-centered
Toolkits:
Toolkits are loosely coupled collections of goods that can be quickly expanded by combining various tools and workbenches.
Language-centered:
The environment is written in the programming language for which it was created, making it easy for users to reuse, alter, and expand it.
Integrated:
By providing uniform, consistent, and coherent tool and workbench interfaces, these environments accomplish presentation integration. The repository concept is used to achieve data integration: they have a dedicated database that manages all information produced and retrieved in the environment. The ICL CADESsystem, IBM AD/Cycle, and DEC Cohesion are examples of integrated environments.
Fourth-generation:
The first integrated environments were fourth-generation environments. They're a collection of tools and workbenches for creating a certain type of programme: electronic data processing and business-oriented applications.
Process-centered:
This category of environments focuses on process integration as a starting point for additional integration dimensions. A process-centered environment interprets a process model generated by specialist software.
Integrated CASE (I-CASE) has a number of advantages.
(1) a smooth transfer of information (models, programmes, documents, and data) from one tool to another and from one software engineering step to the next;
(2) a decrease in the effort required to perform umbrella activities like software configuration management, quality assurance, and document production;
(3) an increase in project control achieved through better planning, monitoring, and communication; and
(4) improved coordination among staff members who are working on the same project.
However, I-CASE has a number of drawbacks. Integration necessitates consistent representations of software engineering data, standardized tool interfaces, a unified mechanism for communication between the software engineer and each tool, and a method that allows I-CASE to migrate between different hardware platforms and operating systems. Comprehensive I-CASE environments have taken longer to emerge than anticipated. Integrated environments, on the other hand, do exist and are becoming more powerful as time passes.
Both combination and closure are implied by the phrase integration. I-CASE brings together a number of technologies and a wide range of data in a way that allows communication between tools, across people, and throughout the software development process to be closed. Tools are integrated so that software engineering information is available to each tool that requires it; usage is integrated so that all tools have a consistent look and feel; and a development philosophy is integrated, implying a standardized software engineering approach based on modern practise and proven methods.
To define integration in the context of the software engineering process, a set of I-CASE requirements must be established: A CASE environment that is integrated should
● Create a system for all tools in the environment to share software engineering information.
● Allow a change to one piece of data to be tracked to other associated data points.
● Manage all software engineering information using version control and comprehensive configuration management.
● Allow non-sequential, direct access to any tool in the environment.
● Integrate CASE tools and software configuration items (SCIs) into a standard work breakdown structure to provide automatic support for the software process model chosen.
● Provide an uniform appearance and feel at the human/computer interface for each tool's users.
● Encourage software engineers to communicate with one another.
● Collect management as well as technical metrics that can be used to improve the process and product.
Q6) Describe the architecture of case tools?
A6) A typical modern CASE (Computer-assisted software package Engineering) environment is depicted graphically below. A computer application, toolset, object management system (OMS), and repository are all essential components of a modern CASE environment. The characteristics of a toolkit have already been highlighted.
Fig 2: architecture of CASE environment
User Interface:
The user interface establishes a consistent framework for accessing the various tools, making it easier for users to interact with them and lowering the overhead of learning how to use them.
Object Management System (OMS) and Repository:
The thing management system transfers these logical entities into the underlying storage management system. Different case tools depict the product as a group of entities such as specification, design, text data, project arrange, and so on (repository).
Large amounts of data are formatted as simple, comparatively short records, and industrial on-line database management systems are geared toward supporting them. There are certain types of entities, but there are a lot of them. CASE tools, on the other hand, generate a large number of different entity and relation types, with just a few examples of each. As a result, the thing management system is responsible for mapping appropriately into the underlying storage management system.
Q7) Write the components of case enviornment?
A7) Components of CASE environment
The following are significant elements of the CASE environment:
1. Project Management Tools: An organization attempting to improve a business process must first comprehend the process. It is used to illustrate the important aspects of a business process in order to make it more understandable.
2. Risk Analysis Tool: It aids in the identification of hazards while creating a strategy, designing it, and then putting it into action.
3. Analysis and Design Tool: It allows the software to be built as a collection of modules. The analysis tool aids in the analysis of the user's needs in order to establish their practicality. The design tool aids in the transformation of requirements into a thorough and manageable design.
4. Quality Assurance Tool: Quality assurance tools are metrics that audit source code to determine whether or not it complies with standards.
5. Testing Tool: Testing tools are mostly used to make software testing more efficient.
Q8) Define software reengineering?
A8) Software Reengineering
Software re-engineering is the process of updating software to keep it current in the market without affecting its functionality. It is a lengthy procedure in which the software design is altered and programs are rewritten.
Legacy apps can't keep up with the most up-to-date technologies on the market. When hardware becomes outdated, software updates become a headache. And if software becomes obsolete over time, the functionality remains unchanged.
Unix, for example, was created in assembly language at first. Unix was re-engineered in C when the language C was created because working in assembly language was difficult.
Aside from that, programmers can find that some parts of software need more maintenance than others, as well as re-engineering.
Fig 3: Re-engineering process
Process of Reengineering
● Determine what needs to be re-engineered. Is it the whole program or just a portion of it?
● Reverse engineering is a technique for obtaining requirements for current applications.
● If necessary, restructure the program. Changing function-oriented programs to object-oriented programs, for example.
● Reorganize data as needed.
● Fill out an application To get re-engineered applications, use forward engineering principles.
Q9) What do you mean by Software Maintenance Problems?
A9) The following are some of the most common causes of software maintenance issues:
● Lack of Traceability
● Lack of Code Comments
● Obsolete Legacy Systems
Lack of Traceability
● Rarely can codes be traced back to requirements and design specifications.
● It's quite tough for a programmer to notice and fix a severe flaw that has an impact on client operations.
● The programmer examines the software as if he were a detective, looking for clues.
● Even as part of a development effort, Life Cycle Documents are not usually produced.
Lack of Code Comments
The majority of software system codes are devoid of suitable comments. In some cases, decreasing comments may be counterproductive.
Obsolete Legacy Systems
● The legacy systems that supply the backbone of the nation's key industries, such as telecommunications, medical, and transportation utility services, were not developed with maintenance in mind in most countries throughout the world.
● They weren't supposed to endure a quarter-century or longer!
● As a result, the code that supports these systems lacks traceability to the requirements, conforms to design and programming standards, and frequently contains dead, superfluous, and uncommented code, making maintenance nearly hard.
Q10) What are the challenges in software maintenance?
A10) Challenges in Software Maintenance
The following are some of the issues in software maintenance:
● Any software program's popular age is taken into account for ten to fifteen years. Because software programme renovation is an open-ended process that might last for decades, it is exceedingly costly.
● Older software programmes, which were designed to run on slow machines with limited recollection and storage, are unable to compete with newer, more powerful software on modern technology.
● Changes are typically left unreported, which might lead to increased dispute in the future.
● The cost of preserving ancient software programmes rises as time passes.
● Frequently, changes performed can unintentionally affect the software program's original design, making future revisions impossible.
Q11) Explain Business Process Reengineering?
A11) Business process re-engineering isn't just a tweak; it's a significant change with significant improvements. Only through overhauling organizational structures, job descriptions, performance management, training, and, most crucially, the usage of IT (Information Technology) can this be accomplished.
BPR initiatives have occasionally fallen short of lofty expectations. Many failed BPR initiatives are due to a lack of understanding of what BPR is and how it should be done. It becomes a trial-and-error procedure.
Fig 4: business process reengineering
Q12) Write the objective of business process reengineering?
A12) Objectives of BPR
The BPR's objectives are as follows:
● To drastically lower costs.
● To lessen the amount of time required.
● To drastically increase customer service.
● To rewrite the business's fundamental rules, such as The airline business is a huge industry.
● Customer satisfaction is important.
● Learning in the workplace.
Q13) What are the advantages and disadvantages of BPR?
A13) Advantages of BPR
The following are some of the benefits of BPR:
● BPR allows for seamless integration of various modules.
● It provides the business with the same views, such as the same database, consistent reporting, and analysis.
● It has a process orientation feature, which allows you to streamline procedures.
● It has a lot of features, such as templates and reference models.
● It is adaptable.
● It's adaptable.
● It can be expanded.
Disadvantages of BPR
The following are BPR's drawbacks:
● It is dependent on a number of criteria, including the size of the organization and the availability of resources. As a result, it will not be appropriate for every firm.
● It will not be able to provide a quick answer.
Q14) Describe Software Reengineering Process Model?
A14) In the software engineering re-engineering process, there are six steps:
1. Inventory analysis
2. Document restructuring
3. Reverse Engineering
4. Code restructuring
5. Data restructuring
6. Forward engineering
Fig 5: software engineering process model
Inventory analysis
● Every organization should create an inventory to store all of its apps.
● The inventory can be a spreadsheet model that contains data that gives a complete description of each active application.
● Candidates for re-engineering emerge after sifting this data according to business criticality, lifespan, current maintainability, and other significant factors.
● Candidate applications for re-engineering work can be given resources.
Document restructuring
● A system's documentation might assist in describing how it works or how to utilize it.
● It is necessary to update the documentation.
● It's possible that a complete re-documentation of an application isn't required. Rather, the parts of the system that are changing right now are thoroughly documented.
● A collection of valuable and relevant documentation will emerge over time.
Reverse engineering
● Reverse engineering is the process of recovering a design.
● From an existing software, reverse engineering tools retrieve data, architectural, and procedural design information.
Code restructuring
● A restructuring tool is used to analyze the source code in order to accomplish code restructuring. Structured programming constructs are broken, and the code gets restructured as a result.
● The rearranged code is then inspected and tested to ensure that no problems have arisen. The documentation for the internal code has been updated.
Data restructuring
● Reverse engineering is the first step in data rearrangement.
● The current data architecture is examined, and data models that are required are defined.
● Existing data structures are reviewed for quality, and data objects and attributes are identified.
Forward engineering
● Forward engineering, often known as renovation or reclamation, is the process of recovering design data from current software.
● It uses this information to improve the overall quality of the system by altering or reconstituting it.
Q15) Write the principles of BPR?
A15) Principles of Business Process Reengineering
In many aspects, BPR and business process engineering are very similar in terms of focus and scope. BPR should be done in a top-down way in an ideal world, starting with the identification of major business objectives and goals and ending with a much more precise specification of the tasks that constitute a specific business process.
When BPR initiatives start at the highest (business) level, Hammer advocates following a few guidelines:
Organize results rather than tasks. Many businesses have compartmentalized their operations such that no single individual (or organization) is responsible for (or in charge of) a certain business outcome. In such instances, determining the status of work is tough, and debugging process faults, if they occur, is considerably more complex. BPR should create procedures to avoid this issue.
Allow people who will be using the process's output to run it. The goal of this advice is to give people who require business output complete control over all of the variables that enable them to receive the output on time. The fewer parties involved in a process, the easier it is to reach a quick conclusion.
Incorporate data processing tasks into the actual work that generates the raw data. As IT becomes more distributed, most information processing may be done within the enterprise that generates the raw data. This centralizes control, minimizes communication time, and concentrates computational power in the hands of people with a stake in the information provided.
Treat resources that are spread geographically as if they were centralized. Computer-based communications have advanced to the point where organizations from all over the world can work together in the same "virtual office." A worldwide corporation, for example, can perform one engineering shift in Europe, a second shift in North America, and a third shift in Asia instead of three engineering shifts at a single location. Engineers will work during daytime hours and communicate using high-bandwidth networks in each situation.
Instead of integrating the results of parallel activity, link them together. When multiple stakeholders work at the same time, it's critical to build a process that requires constant communication and collaboration. Otherwise, integration issues are almost certain to arise.
Build control into the process and place the decision point where the work is done. This notion, in software design lingo, advocates a flatter organizational architecture with less factoring.
Data should only be captured once, at the source. Data should be stored online so that it does not have to be entered again once it has been obtained.
Q16) Write the difference between reverse engineering and forward engineering?
A16) Here is a list of the differences between forward engineering and reverse engineering
Parameters | Forward Engineering | Reverse Engineering |
Basics | Forward engineering aims at re-developing an application with the provided resources according to the current requirements. | Reverse engineering aims at deducing the resources and requirements that went into developing an application in the first place. |
Nature | It is perceptive in nature. | It is adaptive in nature. |
Certainty | It always leads to the production of applications that implement the specified requirements. | Using this type of engineering, a user can easily yield a lot of ideas associated with the requirements of the implementation and development of the application. |
Skills Needed | It requires high-proficiency skills. | It works even with a low level of expertise. |
Total Time Required | It takes more time. | It takes comparatively less time. |
Accuracy | The model in engineering must be complete and precise. | An inexact model can also yield partial information about the initial requirements and resources that went into its development. |
Examples | A few examples of forward engineering are the construction of a DC motor, constructing kits (electronic), etc. | Performing research on various instruments is a commendable example of backward engineering. |