Tools, CASE & Integration

Introduction

• Software tools.

• CASE tools.

• Categories of CASE tools.

• Integration of CASE tools.

• Public Tool Interfaces.

What is a software tool?

• A software tool is a program or application that

software developers use to create, debug, or

maintain other programs and applications.

• The term usually refers to relatively simple

programs that can be combined together to

accomplish a task.

• Similar to engineering where multiple tools are used

to build a physical object.

Generations of Software Tools

• 1st Generation (1950s - late 70s)

• 2nd generation (late 70s - mid 80s)

– Data Dictionary, RDBMS. – Multi diagrammers.

Generations of Software Tools

• 3rd Generation (mid 80s - late 80s)

– Intelligent diagrammers. – DB generators.

– Active Data Dictionaries. – I-CASE (Integrated CASE).

• 4th Generation (late 80s – late 90s)

– Software Engineering Environment frameworks. – Process-centred Software Engineering.

– Application Generators.

– Simulation and capacity planning. – Project management.

– Reverse Engineering. – Methods Engineering. – Object Orientation.

Tool developments

• Stem from advances in hardware/software.

• Also, new system environments.

• Has led to tool development for:

– Aspect-oriented development. – Web services.

– Open environments.

Common tools

• Revision control: SCM, SCCS, RCS, CVS, SVN, Git, Monotone, GNU arch, SourceSafe, PVCS, ClearCase, Bonsai

• Compilation and linking tools: GNU toolchain (Make, automake, gcc), Microsoft Visual Studio, CodeWarrior, Xcode, Intel compiler

• Lint: lint, Splint • Search: grep, find

• Text editors: emacs, vi • Scripts: Shell, Perl, REXX • Parsing: Lex, Yacc

• Bug Databases: gnats, Bugzilla, Trac • Debuggers: gdb, GNU Binutils

• Online Code Sharing Tools: Sourceforge, Krugle, ByteMyCode • Source code generation tools

Integrated Development

Environments (IDEs)

• So, if that’s what a software tool is, what is an IDE?

• IDEs are development applications that combine the

features of many tools in one place.

• Delphi

• C++ Builder

• Microsoft Visual Studio

• Xcode

• Eclipse

• NetBeans

• IntelliJ IDEA

so what’s a CASE tool?

• A software tool helps a developer perform a single

complex task.

• Tools can be combined into toolsets that are

typically offered by an IDE.

• A CASE tool helps a developer to perform some

aspect of the SDLC.

How do CASE tools help?

• Simplifies the task at hand.

• Serves several audiences (end users, developers

etc.)

• Saves time and money.

• Produces quantitative and verifiable designs

(requirements are traceable, performance criteria

held, etc.)

• Supports changes.

Example – The Data Dictionary

• Central Repository or Data Dictionary:

– used to ensure standard and consistent definitions. – related to Entity Analysis techniques.

– used for Impact Analysis.

– used throughout life cycle and beyond.

– always changing to accommodate latest objects.

– holds all details: ownership, security, validation, users of data/processes, storage, performance info, etc.

– holds text, diagrams, objects of all sorts.

– can be used as any other database - c,r,u,d; needs locking protocols, version control.

Example – The Data Dictionary

from Data

DATA PROCESSES from

Function Analysis CONCEPTUAL Entities Attributes Relationships Processes Events Analysis CONCEPTUAL PHYSICAL from Database data definitions Data Items Tables Records Files Sets Indexes Clusters etc. Systems Modules Programs Sub-routines PHYSICAL from Program Statements

Categories of CASE tools

1. Workbenches

• Aim to automate the structured methodologies.

• Tools are available for different stages of I.S. development:

– Planning, Analysis, Design and Construction.

• WIMP interface essential.

• Easy to use, on-line help, self documenting.

• Tools can cover different activities and cross these stages. • Often one or more methodology-based especially upper

CASE.

• Most workbenches can operate as standalone or be networked.

• Aim for seamless interface between tools. • Cheap entry point.

Categories of CASE tools

1.1 Planning Workbenches

• For project management, strategic overviews, BPR,

Enterprise model synchronisers etc.

• Support PERT, Critical Path Analysis, Enterprise

modelling, Organisation charts

– e.g. Microsoft Project.

• Support Business Processing Re-engineering,

structure diagrams, procedural diagrams, include

multimedia input.

– e.g. BP WIN, Oracle’s Business Process Modeller.

• Where many models have become fragmented and

duplicated a tool to compare and consolidate

Categories of CASE tools

1.2 Analyst Workbenches

• Known as Front-End or Upper-CASE.

• supports analysis and design tasks

– methodology and technique support

– graphics to support diagrammatic modelling:

• e.g. ERM, DFD, ELH etc.

– documentation support, report production – repository cross-checking

– database generation

Categories of CASE tools

1.3 Design & Construction WBs

• Known as Back-End or Lower-CASE.

• Used to design and construct programs:

– support design methods (JSP).

– graphics to support structure diagrams. – coding support.

– testing support.

– diagnostic and debug tools.

Categories of CASE tools

2. Integrated CASE (I-CASE)

• Features:

– Full coverage of life cycle, allows prototyping, RAD.

– Mixture of graphics and text to specify user and developer requirements.

– Fill-in-the-blanks, default options, intelligent defaults. – Tools fully integrated: any tool can employ info from

another - they share the same repository.

– All knowledge stored in repository checked automatically and meticulously ( to ensure integrity, consistency and completeness).

Categories of CASE tools

2. Integrated CASE (I-CASE)

• Features:

– Self documenting, robust, interactive and dynamic. – Re-Engineering and Reverse-Engineering.

Explanatory Diagram

(allegedly)

Categories of CASE tools

3. Component Case (C-CASE)

• Business needs are such that several

methodologies may be needed

• Also, implementation may need to be on different

platforms and in different languages.

• To accommodate these, components of CASE tools

are used as and when needed.

C-CASE Wishlist

• Diagramming tools:

– DFDs, ERDs, OOMs, Screens, Menus, Transactions and Report design.

• Syntax verifier:

– diagram checks for input /output.

– correct use of methods and techniques. – consistency checks.

• Central Repository/Encyclopaedia:

– storage of graphs, data definitions, objects.

– link between graphics, data definitions and code generation.

C-CASE Wishlist

•

Prototyping tools

– quick creation and modification – use repository definitions

•

Code Generation

) not all

– derived from repository ) offer – Project Management ) these

– Re-Engineering/Reverse-Engineering ) techniques

•

This list is still much too limiting and organisations

need much, much more!

C-CASE Wishlist

•

Configuration management.

•

Version control.

•

Impact analysis.

•

Access control.

•

Reusability.

•

Traceability/QA.

•

Common GUI.

•

Monitoring/metrics.

CASE Integration

• Incompatibility has slowed CASE progress – there

have been many attempts to standardise, but there

are usually many differing standards! Consider:

– hardware. – software.

– methodologies.

– validation and verification rules. – databases.

– user interfaces.

Types of Integration

• Horizontal Integration

– integration of different tools at a particular stage of the life cycle.

• Vertical Integration

– integration of tools between different stages of the life cycle - therefore results from one tool pass forward to another.

• Forward Integration

– from analysis/design to coding/testing.

• Reverse integration

CASE tool strategies

• Separate, unconnected tools for each task.

– e.g. Notepad, javac.

• Tools to carry out multiple tasks.

– e.g. JBuilder, MS Access.

• Tools which connect to specific other tools (p2p).

– e.g. MS Visual Studio and MS Visio.

• Tools which allow customization

– e.g. Eclipse is an open-source pluggable IDE.

CASE tool strategies

• Separate tools which share features.

– e.g. data repository, message server.

• Tools as part of a large suite covering much of the project life cycle.

– e.g. Oracle developer.

• Tools using a standard framework with common APIs, a central repository and a message server

• Any tool that conforms can be integrated.

– e.g. IBM’s AD/Cycle, DEC’s Cohesion and HP’s SoftBench of the late 1980s.

• Vendors publicise their tools’ architecture or API so other vendors can link.

– e.g. Oracle Designer 2000 had “bridges” to 12 products e.g. Select SSADM, Exelorator and others.

Levels of Integration

• Platform integration.

– different tools in the CASE environment should be able to run on different platforms and be interoperable.

• Presentation integration.

– User Interface should be consistent across all tools used.

• Control integration.

– a formal, standard mechanism for a tool to inform other tools of changes made.

• Process integration.

– the environment should be able to handle the formal Software Engineering techniques plus the supporting tasks.

• Data integration.

– sharing the data and its relationships between tools including objects, versions, access control.

Vendor specialisms

• Integration was also difficult as many vendors concentrated on tools for selected parts of the life cycle.

• Resulted in developers not seeing a standard across all the tools they used.

• Specialised tools are often better that those from the

vendors who did attempt a tool for all phases of the life cycle (Simon 1993).

• Interestingly in 2003 it was being suggested that specialisation can be a bonus.

• This takes for granted the levels of integration which are now achieved:

– (“Third-party tools in single-platform shops “ at

http://www.embarcadero.com/resources/tech_papers/thirdpartytools. html [30/4/04] ).

Aspects of Integration

• To be considered:

– Operating Systems. – Graphics interfaces. – Database, SQL.

– Tools interfaces (for Open environments). – Communications.

Operating systems

• Tied to existing OS? If buying new hardware and

software - much more choice…

• BUT:

– CASE only one component of strategy

– some tools for a specific op. sys e.g. Microsoft Visual Studio/Visio/Access etc.

– some tools run on several PC operating systems:

• Red Hat and SuSE Linux, • Sun Solaris (SPARC),

• Microsoft Windows (NT/2003/XP), • Apple Mac OS X

• May be single user (ref. Select SSADM) or

networked.

Graphics interface

• For simple tools = integral part.

• For I-CASE and open environments often part of the

Tools Interface (see Tools Interfaces).

• Most of these tools are Windows or Linux.

• Most have look and feel similar to Windows.

• If the intention is to integrate into Open

Environment, the Tools Interface may become more

important.

Database

• Underlying database is a key component; the more sophisticated the tool, the more important it is

• Workbenches tend to have proprietary database.

• I-CASE needs very sophisticated database for all tools to share.

• if an Open Environment is to use 3rd party tools needs highly sophisticated flexible database repository.

• SQL provides a common standard for accessing a relational database.

• Database vendors actively encourage 3rd party vendors to use their product as a common platform.

• 2 uses of database:

– for storing application information for later move to target machine/s. – for use in generating and manipulating applications throughout their life.

Tools interfaces

for Open Environments

• Structure and content of the data repository is a key

mechanism that enables 3rd party tools to be added

to Open Environment.

• User Interfaces must interact and be consistent.

• Validation and verification rules because objects

and models must be consistent.

• The trend was to specify the nature and mechanism

in great detail – problem is the architectures differ

greatly.

Standards for

Public Tool Interfaces (PTIs)

• Portable Common Tool Environment (PCTE+) funded by Esprit defined a common interface between an operating system and the tools on that system.

• Common Ada Interface Set (CAIS) similar to PCTE but for Ada.

• Information Resource Dictionary System (IRDS) is another standard for the repository backed by ANSI – aiming a

platform independence.

• Case Data Interchange Format (CDIF) is the furthest

advanced for import/export files (supporters: Oracle, LBMS, Sybase, Digital, Cadre, Intersolve).

• IBM attempted with its own products based on Systems Application Architecture (SAA) and AD/Cycle to set a de facto standard but it was too late into the market place. Moved away from the platform independence of IRDS.

Open Database Connectivity

• Part of Microsoft's Windows Open System Architecture. • Enables an application to maintain a consistent Windows

interface, regardless of the type or location of the target database.

• ODBC Driver Manager sits between Application and data source drivers.

• Built into new Windows applications.

– Office, Visual Studio etc.

• Connectivity issues hidden from the user. • SQL generated by the applications.

• Limitations:

– ODBC does not help with networking.

– database companies' products are targeted at their own database and network products.

Common Object Request Broker

CORBA

• What: allows multiple applications to work together

in a distributed, heterogeneous environment

• How:

– by abstracting requirements, designs and mechanisms common to many distributed systems.

– Uses OMG’s Interface Definition Language to define the interfaces to these abstractions.

– Client apps issue requests, the server-side Object Request Broker locates and activates the target and passes on request, returning any reply.

– The object adaptor isolates the interface from the underlying technology.

XML

• What: Standardises interoperable structured data.

• How:

– replaces traditional proprietary Electronic Document Interchange (EDI) systems, binary and simple text formats.

– utilises plain-text files and hierarchical tagging structure similar to HTML (stricter rules apply).

– standardised general method for file parsing:

• SAX – Simple API for XML.

• DOM – Document Object Model.

– tags are user-definable.

– validates data against user-defined schema (template). – XML documents can be transformed using stylesheets.

Communications

• Historical aim of CASE was at large, centralised

developments but the trend is towards

decentralisation with networking.

• N-tier developments mean there is a need for

increased communication between tiers:

– business logic layer, application servers and clients.

• International Standards Organisation (ISO) have

been instrumental in developing a set of protocols.

• Open Systems Interconnection (OSI) enables

conforming systems to communicate over LANs and

WANs.

Approaches to integrating

• Plug-in architecture.

• Web-services.

• Repository sharing.

• Distributed objects.

• Etc.

Relationship of CASE

to other technology movements

•

1. Open Systems.

– standards supported by many vendors enable

interoperability in critical areas such as communications, UI, database access, system utilities.

•

2. Enterprise Computing.

– these architectures include interoperability products such as gateways, multi-protocol routers to enable use of existing hardware and systems software.

– may be proprietary point-to-point interconnection or use open systems standards.

Relationship of CASE

to other technology movements

• 3. Client/Server Computing - separate application functions into communicating entities which request/provide a

service. May be proprietary point-to-point interconnection or use open systems standards.

• “Typical I-CASE products have moved from single-vendor, centralized environment to distributed, inter-connected

systems - maybe from multiple vendors.“

– (Alan R. Simon,The Integrated CASE Tools Handbook, Van Nostrand Reinhold, 1993)

– [note: the following was written by Simon in 1993 and is still valid!]

The CASE tool(s) should be a reflection of the state-of-the-art of the systems it is used to create.