Beruflich Dokumente
Kultur Dokumente
Unit – 3
G. Roy Antony Arnold
y y
Asst. Professor / CSE
GRAA
• Computer‐Aided
Computer Aided Software Engineering (CASE)
Software Engineering (CASE)
is the scientific application of a set of tools
and methods to a software system which is
and methods to a software system which is
meant to result in high‐quality, defect‐free,
and maintainable software products
and maintainable software products.
• CASE tools automate methods for designing,
documenting and producing structured
documenting, and producing structured
computer code in the desired programming
language.
GRAA
• Architecture Management
– Model, design, and rapidly build Software, Systems, and
Computer Application Programs.
• Change and Release Management
Change and Release Management
– Improve software delivery and lifecycle traceability, from
requirements through deployment
requirements through deployment.
• Software Development Management
– Align projects for improved productivity and predictability.
Align projects for improved productivity and predictability
• Quality Management
– Ensure
Ensure software functionality, reliability and performance
software functionality, reliability and performance
throughout development and production.
GRAA
• 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.
• The term CASE was originally coined by software
g y y
company Nastec Corporation of Southfield,
Michigan in 1982 with their original integrated
g g g
graphics and text editor GraphiText
GRAA
• Supply basic functionality, do routine tasks
pp y y,
automatically
– Be able to support editing of code in the particular
programming language, supply refactoring tools
• Enhance productivity
– Generate code pieces automatically
• Increase software quality
• Intuitive use
g
• Integration with other tools
– For example, code editor works with code repository
GRAA
• They classified as Upper, Lower and Integrated CASE tools.
• Upper CASE Tools support strategic planning and construction
of concept‐level products and ignore the design aspect, such
as ER diagrams, Data flow diagram, Structure charts,
Decision Trees, Decision tables, etc. E.g. Excelerator
• Lower
L CAS Tools
CASE l concentrate on the
h back
b k end d activities
i i i off
the software life cycle, such as physical design, debugging,
construction testing,
construction, testing component integration,
integration maintenance,
maintenance
reengineering and reverse engineering. E.g. Telon
• Integrated CASE Tools aim to support the whole development
cycle. E.g. IEF (Information Engineering Facility)
GRAA
Requirement Operation &
System Design Coding Testing
Analysis Maintenance
Integrated CASE Tools (ICASE)
e.g. IEF
Upper CASE / Front End Lower CASE / Back End
e.g. Excelerator e.g. Telon
Upper CASE Mid CASE Lower CASE / Back End
GRAA
• It
It is also called as front end CASE Tools
is also called as front end CASE Tools
• They assist in requirement analysis & design
• They may be tied to a specific methodology or
may allow the use of the user’ss own
may allow the use of the user own
methodology.
• Example:
E l
• These tools are associated with analysis and
y
design methodologies such as SAM or SSADM
GRAA
• The typical responsibilities of an UpperCASE Tool are to
support the following tasks:
– Requirement Analysis:
• Application Visioning
Application Visioning
• Requirements Reuse
• Requirements Identification
• R
Requirements Analysis
i A l i
• Requirements Specification
– Design:
g
• Design Production
• Design Refactoring
• Design Reuse
Design Reuse
• Design Documentation
GRAA
• These
These tools are concerned with the
tools are concerned with the
implementation stages of the lifecycle,
typically coding testing and documentation
typically coding, testing and documentation.
• They aim to increase the reliability,
adaptability and productivity of the delivered
code.
• 4GLs may be considered as back‐end CASE
T l
Tools, such as Telon.
h T l
GRAA
• The typical responsibilities of a LowerCASE
The typical responsibilities of a owerCAS Tool
Tool is
is
to support the performance of the following
tasks:
– Implementation:
• Implementation Reuse
• Programming
• Debugging
– Integration Tasks:
• Integration Planning
• Component Integration
C tI t ti
• Integration Reporting
GRAA
• Aim
Aim to support the whole development cycle
to support the whole development cycle
and are linked to specific methodologies.
• They are often complex and expensive, but
They are often complex and expensive but
offer the developer the greatest integrity of all
approaches through the use of a single data
approaches through the use of a single data
encyclopaedia throughout the lifecycle.
• Example: IEF (Information Engineering
( f
Facility), IEW (Information Engineering
Workbench)
GRAA
• Help standardization of notations and diagrams
p g
• Productivity increases
• Help communication between development team
Help communication between development team
members
• Automates the methodology – gy this improves
p
consistency, but restricts creativity.
• Reduction of time and effort
• Automated tools are provided to prepare
documentation
• Complexity of maintenance decreases.
GRAA
• Cost Increases: Costs for purchase + training
Cost Increases: Costs for purchase + training
• Expertise needed
• Training issues
• Not mapping to current methods or
applications.
• May lead to restriction to the tool’s
p
capabilities
• Limitations in flexibility of documentation
• Common
Common CASE risks and associated controls
CASE risks and associated controls
include:
– Inadequate standardization
I d d di i
– Unrealistic expectations
– Slow implementation
– Weak repository controls
Weak repository controls
GRAA