Software Engineering, Lectures

1. SE-381
Software Engineering
BEIT-V
Lecture # 20
(Computer Aided Software Engineering (CASE) Tools)

2. Computer Aided Software
Engineering (CASE)
– Encompasses wide range of Software programs that
are used to support Sw Process activities such as
Requirements Analysis, System Modeling,
Debugging, Testing etc
– All methods/methodologies come with associated
CASE Technology such as
• Editors with specific notations,
• Analysis tools to check system models,
• Report Generators to create system documentation,
• Code generators to generate source/skeleton code from
system model
• Change Management tools to manage changes and system
configurations etc

3. CASE – Computer Aided (or
Assisted) Software Engineering
– Note – it is NOT ‘Computer Automated’
– Computers are to Assist, and especially in
creative activities like Software
Development, they cannot replace
humans, the can only aid or assist
– CASE tools are around since the inception of
SD arena, their form and shape is constantly
improving.
• Eg, these used to be Line or Text Editors for now
used context-sensitive Intelligent Editors

4. CASE Supports
– Software process activities such as
Requirements Engineering, Design, Program
Development, Testing, Documentation, Projec
t Management, Configuration Management
etc.
– CASE Tools include tools like
• Design (Textual and Graphical) Editors
• Data Dictionaries
• Compilers, Debuggers, IPDEs, Context Sensitive
and Structure Editors,
• System Building and Change management tools
• Resource and Project Management tools
• Reverse Engineering Tools etc

5. CASE Status [Som04]
– In 1980s and 1990s, it was hoped that CASE tools
will bring in 3-4 fold productivity enhancement, but
according to [Som04] this enhancement has been in
the range of 40%.
– The main impediments for the progress has been
• Software Development is a creative activity and still
computers and Sw will take a long time to do it without
human interaction.
• SD is a team activity and most of the time is spent in mutual
communication, CASE has still not addressed that domain
– The areas addressed by CASE are mostly the ones
where the recurring procedures have been
automated.

6. CASE Status [Sch07]
• Ref: Myers 1992
• Reifer investigated 45 companies in 10 industries.
50% in IS, 25% RT Aerospace and 25% related to
Scientific Areas
• Average Annual productivity gains 9% (RTA), 12%
(IS). And Costs $125K per user of introducing
CASE Technology

7. CASE Tools
• CASE Tools
• handle the repetitive rigor / drudgery of the software process
and in there SD activities eg Word Processors and Drawing
Systems facilitate software engineers to maintain up-to-date
documentation and design by facilitating Change and easy
Reproduction, but documentation is done by humans
• CASE tools help Sw Engineers to encounter complexity of
the SD Eg maintenance of a Data Dictionary even of a
moderate size software is manually not possible
• These are around since inception of software but their
functionality, UI, reliability, form, … has lot changed

8. Why CASE?
• To
– Enhance productivity of developers
– Introduce Consistency in deliverables coming from
different phases, stages and tools
– Counter rigor and drudgery involved in docum –
entation and analysis of complex software
– Intelligently check Consistency and balancing of
different artifacts and diagrams
– Support team work at analysis and design levels
– Integrate inputs and outputs generated by different
tools for different phases of software development

9. Various Categorizations of CASE
– Different authors have defined various
categories for CASE Tools, in general these
are
• Function Based CASE Categories [Som04]
• Process or Activities Based CASE Categories
[Som04]
• Coverage Based Categorization or classification
with Integration perspective [Som04, Sch02]
• Depth Base Categorization [Sch02, Bit92]
• Phase and Non-Phase wise Categorization and
1st and 2nd Generations of CASE tools [Mal05]

10. Function Based Classification of
CASE Tools [Sch02]

11. Activity Based Classification of
CASE Tools [Som04]

12. Taxonomy / Classification of
CASE (Depth Based)
– CASE tools can be specific to one or more
activities of SDLC. A number of activities can
constitute a Phase and vice versa
– There could be many tools to support the same
activity and in contrast the functionality of a Sw
tool can span to more than one activity
– Further an Activity Eg Coding, may comprise of
multiple Tasks, Eg Editing, Compiling, Linking and
Loading; and the boundaries of an activity and a
phase may not be same.
– Nature wise CASE Tools are categorized by
(Bitter 1992 and Schach 2004) as
• Upper CASE or Front-End Tools which support the
Requirements, Specification, Planning and Design
phases, and
• Lower CASE or Back-End Tools which assist in
Implementation, Integration, Testing and Maintenance

13. Ref: CASE in G G Bitter (Editor); Macmillan
Encyclopedia of Computers, 1991, Vol 1, Macmillan
Pub Co NY (1992), pp:185-193

14. Data Dictionary (DD)
• Keeps record of all data items i.e. system
variables, data structures - their variable
names, data types and locations where each one
of these is defined and used, Dimensions, Size etc
and enables other parts of the tool (or Tools) to
– Use them
– Check consistency of implementation of these data items
in different parts of the system
– Ensure completeness i.e. all data items needed by
design are defined in DD and are specified in
Specification document
– Provide data to different Report Generators (a
component that generates the code needed to produce
reports) and Screen Generators (which generate code to
assist the developers for generating their Data Capture
(input) screens and prototypes)

15. DD is
the back-bone of any CASE Tool as it integrates different
parts of the tool and enables them to share data items
unnoticeably and seamlessly
Workbenches
are combinations of various Sw tools to support one or
more phases of SDLC Eg DD combined with the set of
Graphical Representations, Screen & Report
Generators, Consistency Checkers can form a
workbench to Specification and Design phases
CASE Environments
are the integration of Workbenches that support the
whole or most part of the Software Process. Late 80s
and Early 90s Borland’s Turbo series SDEs or
Programming Environments to support
Implementation, Integration and Testing phases.
Some Examples:
ADW, Excelerator, Analyst/Designer, STP – Software
Through Pictures, System

16. Integration Based Classification

17. Tools, Workbenches and
Environments in CASE – Another View

18. CASE Environment [Mal05]

19. Architecture of Repository (DD) Based
Integrated CASE Tool [Som04]

20. CASE Architecture

21. Scope of CASE
• CASE Tools have been around since Software
– Programming-in-the-Small – in Single module
• Line-Editors to Page-Editors and Structure-Editors
– Programming-in-the-Large – at multi-Module or Code level
• Debuggers and Optimizing Compilers have replaced core dumps
and segmentation faults
• Dbx, Make – Unix utilities to debug and compile larger jobs
– Programming-in-the-Many – using teams
• On-line Interface Checking – to cure arguments and object file miss-
matches
• Non-Phase CASE Tools
– Project Management – MS Project, Prima Veirra
– Configuration Management - Versioning, SCCS

22. Graphical Tool
• Additional features
– Data dictionary
– Screen and report generators
– Consistency checker to ensure that various views
are always consistent
• Specifications and design workbench
• Online Documentation
– Problems with
• Manuals
• Updating
• Essential online documentation
– Help information
– Programming standards
– Manuals

23. CASE Tool for Structured and
OOA/D
ASCENT
Automated Strict CASE Environment at
Teesside
(Product of a University at UK)

26. Software Versions
– Software is composed of modules, each having
numerous versions
– Different versions of constituting modules lead to
different versions of Software
– For implementation, testing, operation one has to be
very specific, which version is being referred
– For User support, or bugs eradication, the respective
bugs are to be reproduced using respective versions
– During maintenance, at all times there are at least two
versions of the product:
• The old version, and
• The new version
– Two types of versions: revisions and variations

27. Revisions and Variations
• Revision
– Version to fix a fault in the module, replaces
its predecessor
– We cannot throw away an incorrect version
– Perfective and adaptive maintenance also
results in revisions
– Different versions are to be kept in repository
to reproduce the errors being received, and
to analyze and correct them

28. Revisions and Variations
(contd)
• Variation
– Version for different operating system–hardware
– Variations are designed to coexist in parallel

29. Configuration Control
• Every module
exists in three
forms
– Source code;
object code;
executable load
image
• Configuration
– Version of each
module from
which a given
version of a
product is built

30. Pareto Analysis
In any series of elements to be controlled, a
selected, small fraction, in terms of the
number of elements, always account for the
large fraction in terms of effect
Vilfredo Pareto (1848 – 1923)

31. References
1. Ian Sommerville (2004); Software Engineering, 7th
Ed, Pearson Education, New Delhi, Ch-4. (4.5)
Computer Aided Software Engineering, pp 108-111
2. Rajib Mall (2005); Fundamentals of SE, 2nd Ed,
Prentice-Hall of India, New Delhi, Ch-12 Computer
Aided Software Engineering pp 302-309
3. Stephen Schach (2007)l Software Engineering, 7th
Ed, Tata McGraw-Hill Publishing Company, New
Delhi, Ch-5 (5.4-9) CASE tools, pp 330-341
4. CASE in G G Bitter (Editor); Macmillan Encyclopedia
of Computers, 1991, Vol 1, Macmillan Pub Co NY
(1992), pp:185-193