Unit-3

CASE Tools
CASE stands for Computer Aided Software Engineering. It means, development and maintenance of software
projects with help of various automated software tools.

CASE tools are set of software application programs, which are used to automate SDLC activities. CASE tools
are used by software project managers, analysts and engineers to develop software system.

There are number of CASE tools available to simplify various stages of Software Development Life Cycle such as
Analysis tools, Design tools, Project management tools, Database Management tools, Documentation tools are
to name a few.

Use of CASE tools accelerates the development of project to produce desired result and helps to uncover flaws
before moving ahead with next stage in software development.

Components of CASE Tools

CASE tools can be broadly divided into the following parts based on their use at a particular SDLC stage:

Central Repository - CASE tools require a central repository, which can serve as a source of common,
integrated and consistent information. Central repository is a central place of storage where product
specifications, requirement documents, related reports and diagrams, other useful information regarding
management is stored. Central repository also serves as data dictionary.

Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages of SDLC.

Lower Case Tools - Lower CASE tools are used in implementation, testing and maintenance.

1
 Unit-3

Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC, from Requirement gathering
to Testing and documentation.

Case Tools Types

Diagram tools

These tools are used to represent system components, data and control flow among various software
components and system structure in a graphical form. For example, Flow Chart Maker tool for creating state-
of-the-art flowcharts.

Process Modeling Tools

Process modeling is method to create software process model, which is used to develop the software. Process
modeling tools help the managers to choose a process model or modify it as per the requirement of software
product. For example, EPF Composer

Project Management Tools

These tools are used for project planning, cost and effort estimation, project scheduling and resource planning.
Managers have to strictly comply project execution with every mentioned step in software project
management. Project management tools help in storing and sharing project information in real-time
throughout the organization. For example, Creative Pro Office, Trac Project, Basecamp.

Documentation Tools

Documentation in a software project starts prior to the software process, goes throughout all phases of SDLC
and after the completion of the project.

Documentation tools generate documents for technical users and end users. Technical users are mostly in-
house professionals of the development team who refer to system manual, reference manual, training manual,
installation manuals etc. The end user documents describe the functioning and how-to of the system such as
user manual. For example, Doxygen, DrExplain, Adobe RoboHelp for documentation.

Analysis Tools

These tools help to gather requirements, automatically check for any inconsistency, inaccuracy in the
diagrams, data redundancies or erroneous omissions. For example, Accept 360, Accompa, CaseComplete for
requirement analysis, Visible Analyst for total analysis.

Design Tools

These tools help software designers to design the block structure of the software, which may further be
broken down in smaller modules using refinement techniques. These tools provides detailing of each module
and interconnections among modules. For example, Animated Software Design

Change Control Tools

These tools are considered as a part of configuration management tools. They deal with changes made to the
software after its baseline is fixed or when the software is first released. CASE tools automate change tracking,
file management, code management and more. It also helps in enforcing change policy of the organization.

2
 Unit-3

Programming Tools

These tools consist of programming environments like IDE (Integrated Development Environment), in-built
modules library and simulation tools. These tools provide comprehensive aid in building software product and
include features for simulation and testing. For example, Cscope to search code in C, Eclipse.

Prototyping Tools

Software prototype is simulated version of the intended software product. Prototype provides initial look and
feel of the product and simulates few aspect of actual product.

Prototyping CASE tools essentially come with graphical libraries. They can create hardware independent user
interfaces and design. These tools help us to build rapid prototypes based on existing information. In addition,
they provide simulation of software prototype. For example, Serena prototype composer, Mockup Builder.

Web Development Tools

These tools assist in designing web pages with all allied elements like forms, text, script, graphic and so on.
Web tools also provide live preview of what is being developed and how will it look after completion. For
example, Fontello, Adobe Edge Inspect, Foundation 3, Brackets.

Quality Assurance Tools

Quality assurance in a software organization is monitoring the engineering process and methods adopted to
develop the software product in order to ensure conformance of quality as per organization standards. QA
tools consist of configuration and change control tools and software testing tools. For example, SoapTest,
AppsWatch, JMeter.

Maintenance Tools

Software maintenance includes modifications in the software product after it is delivered. Automatic logging
and error reporting techniques, automatic error ticket generation and root cause Analysis are few CASE tools,
which help software organization in maintenance phase of SDLC. For example, Bugzilla for defect tracking, HP
Quality Center.

DFD(Data flow diagram)

A Data Flow Diagram (DFD) is a traditional visual representation of the information flows within a system. A
neat and clear DFD can depict the right amount of the system requirement graphically. It can be manual,
automated, or a combination of both.

It shows how data enters and leaves the system, what changes the information, and where data is stored.

The objective of a DFD is to show the scope and boundaries of a system as a whole. It may be used as a
communication tool between a system analyst and any person who plays a part in the order that acts as a
starting point for redesigning a system. The DFD is also called as a data flow graph or bubble chart.

The following observations about DFDs are essential:

3
 Unit-3

 All names should be unique. This makes it easier to refer to elements in the DFD.
 Remember that DFD is not a flow chart. Arrows is a flow chart that represents the order of events; arrows in
DFD represents flowing data. A DFD does not involve any order of events.
 Suppress logical decisions. If we ever have the urge to draw a diamond-shaped box in a DFD, suppress that
urge! A diamond-shaped box is used in flow charts to represents decision points with multiple exists paths of
which the only one is taken. This implies an ordering of events, which makes no sense in a DFD.
 Do not become bogged down with details. Defer error conditions and error handling until the end of the
analysis.

Standard symbols for DFDs are derived from the electric circuit diagram analysis and are shown in fig:

Circle: A circle (bubble) shows a process that transforms data inputs into data outputs.

Data Flow: A curved line shows the flow of data into or out of a process or data store.

Data Store: A set of parallel lines shows a place for the collection of data items. A data store indicates that the
data is stored which can be used at a later stage or by the other processes in a different order. The data store
can have an element or group of elements.

Source or Sink: Source or Sink is an external entity and acts as a source of system inputs or sink of system
outputs.

4
 Unit-3

Levels in Data Flow Diagrams (DFD)

The DFD may be used to perform a system or software at any level of abstraction. Infact, DFDs may be
partitioned into levels that represent increasing information flow and functional detail. Levels in DFD are
numbered 0, 1, 2 or beyond. Here, we will see primarily three levels in the data flow diagram, which are: 0-
level DFD, 1-level DFD, and 2-level DFD.

0-level DFD

It is also known as fundamental system model, or context diagram represents the entire software requirement
as a single bubble with input and output data denoted by incoming and outgoing arrows. Then the system is
decomposed and described as a DFD with multiple bubbles. Parts of the system represented by each of these
bubbles are then decomposed and documented as more and more detailed DFDs. This process may be
repeated at as many levels as necessary until the program at hand is well understood. It is essential to preserve
the number of inputs and outputs between levels, this concept is called leveling by DeMacro. Thus, if bubble
"A" has two inputs x1 and x2 and one output y, then the expanded DFD, that represents "A" should have
exactly two external inputs and one external output as shown in fig:

The Level-0 DFD, also called context diagram of the result management system is shown in fig. As the bubbles
are decomposed into less and less abstract bubbles, the corresponding data flow may also be needed to be
decomposed.

5
 Unit-3

1-level DFD

In 1-level DFD, a context diagram is decomposed into multiple bubbles/processes. In this level, we highlight the
main objectives of the system and breakdown the high-level process of 0-level DFD into subprocesses.

2-Level DFD

2-level DFD goes one process deeper into parts of 1-level DFD. It can be used to project or record the
specific/necessary detail about the system's functioning.

6
 Unit-3

Advantages of DFD

 It helps us to understand the functioning and the limits of a system.

 It is a graphical representation which is very easy to understand as it helps visualize contents.
 Data Flow Diagram represent detailed and well explained diagram of system components.
 It is used as the part of system documentation file.
 Data Flow Diagrams can be understood by both technical or nontechnical person because they are very
easy to understand.

Disadvantages of DFD

 At times DFD can confuse the programmers regarding the system.

 Data Flow Diagram takes long time to be generated, and many times due to this reasons analysts are
denied permission to work on it.

mixed language programming

1.There are times when programs need to call programs written in other languages referred as mixed
language programming. For example, when a particular subprogram is available in a language other than
language you are using, or when algorithms are described more naturally in a different language, you need
to use more than one language.

2.Mixed-language programming always involves a call to a function, procedure, or subroutine. Mixed-

language calls involve calling functions in separate modules. Instead of compiling all source programs with
same compiler, different compilers or assemblers are used as per the language used in the programs.

3.Microsoft C supports this mixed language programming. So it can combine assembly code routines in C
as a separate language.

4.C program calls assembly language routines that are separately assembled by-MASM(MASM Assembler).
These assembled modules are linked with the compiled C modules to get executable file.

Advantages of mixed language programming:

Programming languages are fundamentally Abstractions that assist in helping you tell a computer what to
do. As they are abstractions, this means that they hide some of the detail sand so simplify the overall task,
enabling you to comprehend how to do some particular piece of programming without having to
understand the whole thing at once. But that hiding also means that they restrict what you can do: going
outside the abstraction is hard, and so also is having to build a lot of new abstractions on top of the base
level provided by the language.

The net effect of this is to mean that a particular programming language has a range of programming tasks
that it is well suited to, but it is not going to be good for everything. A low-level programming language
allows you to do low-level work, often that happens to be performance critical.

The best way out of this situation where a programming language that can do one task isn't good for
others is to use multiple programming languages. Let each language focus on doing the tasks that it is good
at, and then transfer control to code written in another language for other parts. It's specialization(and
also componentization) and it is a good thing indeed.

7
 Unit-3

Disadvantages of mixed language programming:

Any time you are working in two languages there is the possibility for conflicts which can be tricky to
debug . You might use more memory resources than you can afford to spare carrying.

Call Semantics in RPC

This will go through the Call Semantics, its types, and the issues in RPC in distributed systems in detail. RPC
has the same semantics as a local procedure call, the calling process calls the procedure, gives inputs to it,
and then waits while it executes. When the procedure is finished, it can return results to the calling
process. If the distributed system is to achieve transparency, the following problems concerning the
properties of remote procedure calls must be considered in the design of an RPC system:

 Binding: Binding establishes a link between the caller process’s name and the remote procedure’s location.
 Communication Transparency: It should be unknown to the users that the process they are calling is remote.
 Concurrency: Communication techniques should not mix with concurrency mechanisms. When single-
threaded clients and servers are blocked while waiting for RPC results, considerable delays might occur.
Lightweight processes permit the server to handle concurrent calls from several clients.
 Heterogeneity: Separate machines may have distinct data representations, operate under different
operating systems, or have remote procedures written in different languages.

Reasons for failure in RPC:

RPC Runtime includes code for handling failures. Determine how frequently the remote operation can run
in the event of a failure.
 The caller/callee node has failed.
 The response message/ call is missing.

Types of Call Semantics:

 Perhaps or Possibly Call Semantics: It is the weakest one, here, the caller is waiting until a predetermined
timeout period and then continues with its execution. It is used in services where periodic updates are
required.
 Last-one Call Semantics: Based on timeout, retransmission of call message is made. After the elapsing of
the timeout period, the obtained result from the last execution is used by the caller. It sends out orphan
calls. It finds its application in designing simple RPC.
 Last-of-Many Call Semantics: It is like Last-one Call semantics but the difference here is that it neglects
orphan calls through call identifiers. A new call-id is assigned to the call whenever it is repeated. It is
accepted by the caller only if the caller id matches the most recent repeated call.
 At-least-once Call Semantics: The execution of the call is there for one or more times, but the results given
to the caller are not specified. Here also retransmissions rely on the time-out period without giving a
thought to orphan calls. In the case of nested calls, the result is taken from the first response message if
there are orphan calls and others are ignored irrespective of the accepted response is whether from
orphan or not.
 Exactly-once Call Semantics: No matter how many times the call is transmitted, the potential of the
procedure being conducted more than once is eliminated. When the server receives an acknowledgment
from the client then only it deletes information from the reply cache.

8
Unit-3

Re-engineering

Software Re-engineering is a process of software development which is done to improve the maintainability of a
software system. Re-engineering is the examination and alteration of a system to reconstitute it in a new form. This
process encompasses a combination of sub-processes like reverse engineering, forward engineering, reconstructing
etc.

Re-engineering, also known as reverse engineering or software re-engineering, is the process of analyzing,
designing, and modifying existing software systems to improve their quality, performance, and maintainability. This
can include updating the software to work with new hardware or software platforms, adding new features, or
improving the software’s overall design and architecture.

Re-engineering can be done for a variety of reasons, such as:

To improve the software’s performance and scalability: By analyzing the existing code and identifying bottlenecks,
re-engineering can be used to improve the software’s performance and scalability.

*To add new features: Re-engineering can be used to add new features or functionality to existing software.

*To support new platforms: Re-engineering can be used to update existing software to work with new hardware or
software platforms.

*To improve maintainability: Re-engineering can be used to improve the software’s overall design and
architecture, making it easier to maintain and update over time.

*To meet new regulations and compliance: Re-engineering can be done to ensure that the software is compliant
with new regulations and standards.

*Re-engineering can be a complex and time-consuming process, and it requires a thorough understanding of the
existing software system. It also requires a structured and disciplined approach to software development, similar to
software engineering.

*Re-engineering can be beneficial in many cases, it can help to improve the quality, performance, and
maintainability of existing software systems, but it also has its own drawbacks, such as:

*High costs: Re-engineering can be a resource-intensive process and can require a significant
investment in tools and training.

*Risk of introducing new bugs: Changing existing code can introduce new bugs and compatibility issues.

*High learning curve: Re-engineering can be complex, and it requires a lot of learning and training, which can be
challenging for new developers.

Objectives of Re-engineering:

*To describe a cost-effective option for system evolution.

9
Unit-3

*To describe the activities involved in the software maintenance process.

*To distinguish between software and data re-engineering and to explain the problems of data re-engineering.

Steps involved in Re-engineering:

*Inventory Analysis

*Document Reconstruction

*Reverse Engineering

*Code Reconstruction

*Data Reconstruction

*Forward Engineering

Re-engineering Cost Factors:

*The quality of the software to be re-engineered

*The tool support available for re-engineering

*The extent of the required data conversion

*The availability of expert staff for re-engineering

Re-engineering can be a costly process, and there are several factors that can affect the cost of re-engineering a
software system:

Size and complexity of the software: The larger and more complex the software system, the more time and
resources will be required to analyze, design, and modify it.

Number of features to be added or modified: The more features that need to be added or modified, the more time
and resources will be required.

10
 Unit-3

Tools and technologies used: The cost of re-engineering can be affected by the tools and technologies used, such
as the cost of software development tools and the cost of hardware and infrastructure.

Availability of documentation: If the documentation of the existing system is not available or is not accurate, then
it will take more time and resources to understand the system.

Team size and skill level: The size and skill level of the development team can also affect the cost of re-engineering.
A larger and more experienced team may be able to complete the project faster and with fewer resources.

Location and rate of the team: The location and rate of the development team can also affect the cost of re-
engineering. Hiring a team in a lower-cost location or with lower rates can help to reduce the cost of re-engineering.

Testing and quality assurance: Testing and quality assurance are important aspects of re-engineering, and they can
add significant costs to the project.

Post-deployment maintenance: The cost of post-deployment maintenance such as bug fixing, security updates, and
feature additions can also play a role in the cost of re-engineering.

Advantages of Re-engineering:
 *Reduced Risk: As the software is already existing, the risk is less as compared to new software development.
Development problems, staffing problems and specification problems are the lots of problems which may arise in
new software development.
 *Reduced Cost: The cost of re-engineering is less than the costs of developing new software.
 *Revelation of Business Rules: As a system is re-engineered , business rules that are embedded in the system are
rediscovered.
 *Better use of Existing Staff: Existing staff expertise can be maintained and extended accommodate new skills
during re-engineering.
 *Improved efficiency: By analyzing and redesigning processes, re-engineering can lead to significant improvements
in productivity, speed, and cost-effectiveness.
 *Increased flexibility: Re-engineering can make systems more adaptable to changing business needs and market
conditions.
 *Better customer service: By redesigning processes to focus on customer needs, re-engineering can lead to
improved customer satisfaction and loyalty.
 *Increased competitiveness: Re-engineering can help organizations become more competitive by improving
efficiency, flexibility, and customer service.
 *Improved quality: Re-engineering can lead to better quality products and services by identifying and eliminating
defects and inefficiencies in processes.
 *Increased innovation: Re-engineering can lead to new and innovative ways of doing things, helping organizations
to stay ahead of their competitors.
 *Improved compliance: Re-engineering can help organizations to comply with industry standards and regulations by
identifying and addressing areas of non-compliance.

11
 Unit-3

Disadvantages of Re-engineering:

*Practical limits to the extent of re-engineering.

*Major architectural changes or radical reorganizing of the systems data management has to be done manually.

*Re-engineered system is not likely to be as maintainable as a new system developed using modern software Re-
engineering methods.

*High costs: Re-engineering can be a costly process, requiring significant investments in time, resources, and
technology.

*Disruption to business operations: Re-engineering can disrupt normal business operations and cause inconvenience
to customers, employees and other stakeholders.

*Resistance to change: Re-engineering can encounter resistance from employees who may be resistant to change
and uncomfortable with new processes and technologies.

*Risk of failure: Re-engineering projects can fail if they are not planned and executed properly, resulting in wasted
resources and lost opportunities.

*Lack of employee involvement: Re-engineering projects that are not properly communicated and involve
employees, may lead to lack of employee engagement and ownership resulting in failure of the project.

*Difficulty in measuring success: Re-engineering can be difficult to measure in terms of success, making it difficult
to justify the cost and effort involved.

*Difficulty in maintaining continuity: Re-engineering can lead to significant changes in processes and systems,
making it difficult to maintain continuity and consistency in the organization.

Coding Standards and Guidelines

Different modules specified in the design document are coded in the Coding phase according to the module
specification. The main goal of the coding phase is to code from the design document prepared after the design
phase through a high-level language and then to unit test this code.

Good software development organizations want their programmers to maintain to some well-defined and standard
style of coding called coding standards. They usually make their own coding standards and guidelines depending on
what suits their organization best and based on the types of software they develop. It is very important for the
programmers to maintain the coding standards otherwise the code will be rejected during code review.

Purpose of Having Coding Standards:

12
Unit-3

A coding standard gives a uniform appearance to the codes written by different engineers.

 It improves readability, and maintainability of the code and it reduces complexity also.
 It helps in code reuse and helps to detect error easily.
 It promotes sound programming practices and increases efficiency of the programmers.

Some of the coding standards are given below:

1. Limited use of globals:

These rules tell about which types of data that can be declared global and the data that can’t be.

2. Standard headers for different modules:

For better understanding and maintenance of the code, the header of different modules should follow some
standard format and information. The header format must contain below things that is being used in various
companies:

 Name of the module

 Date of module creation
 Author of the module
 Modification history
 Synopsis of the module about what the module does
 Different functions supported in the module along with their input output parameters
 Global variables accessed or modified by the module

3. Naming conventions for local variables, global variables, constants and functions:

Some of the naming conventions are given below:

 Meaningful and understandable variables name helps anyone to understand the reason of using it.
 Local variables should be named using camel case lettering starting with small letter (e.g. localData)
whereas Global variables names should start with a capital letter (e.g. GlobalData). Constant names should
be formed using capital letters only (e.g. CONSDATA).
 It is better to avoid the use of digits in variable names.
 The names of the function should be written in camel case starting with small letters.
 The name of the function must describe the reason of using the function clearly and briefly.

4. Indentation:

Proper indentation is very important to increase the readability of the code. For making the code readable,
programmers should use White spaces properly. Some of the spacing conventions are given below:

 There must be a space after giving a comma between two function arguments.

13
Unit-3

 Each nested block should be properly indented and spaced.

 Proper Indentation should be there at the beginning and at the end of each block in the program.
 All braces should start from a new line and the code following the end of braces also start from a new line.
5. Error return values and exception handling conventions:

All functions that encountering an error condition should either return a 0 or 1 for simplifying the debugging.

On the other hand, Coding guidelines give some general suggestions regarding the coding style that to be followed
for the betterment of understandability and readability of the code. Some of the coding guidelines are given below

6.Avoid using a coding style that is too difficult to understand:

Code should be easily understandable. The complex code makes maintenance and debugging difficult and
expensive.

7. Avoid using an identifier for multiple purposes:

Each variable should be given a descriptive and meaningful name indicating the reason behind using it. This is not
possible if an identifier is used for multiple purposes and thus it can lead to confusion to the reader. Moreover, it
leads to more difficulty during future enhancements.

8. Code should be well documented:

The code should be properly commented for understanding easily. Comments regarding the statements increase
the understandability of the code.

9. Length of functions should not be very large:

Lengthy functions are very difficult to understand. That’s why functions should be small enough to carry out small
work and lengthy functions should be broken into small ones for completing small tasks.

10. Try not to use GOTO statement:

GOTO statement makes the program unstructured, thus it reduces the understandability of the program and also
debugging becomes difficult.

Advantages of Coding Guidelines:

 Coding guidelines increase the efficiency of the software and reduces the development time.
 Coding guidelines help in detecting errors in the early phases, so it helps to reduce the extra cost incurred
by the software project.
 If coding guidelines are maintained properly, then the software code increases readability and
understandability thus it reduces the complexity of the code.
 It reduces the hidden cost for developing the software.

14