Slide 11A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.

Slides:



Advertisements
Similar presentations
Configuration management
Advertisements

Configuration management
Lecture 1: Overview of Computers & Programming
Ch 3: Unified Process CSCI 4320: Software Engineering.
Case Tools Trisha Cummings. Our Definition of CASE  CASE is the use of computer-based support in the software development process.  A CASE tool is a.
1 The Tools of the Trade Xiaojun Qi. 2 Stepwise Refinement Stepwise refinement is a basic problem- solving principle underlying many software engineering.
Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill, 2011 Stephen R. Schach.
Slide 1.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 11D.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 10B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 8B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 9.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Fundamentals of Information Systems, Second Edition
Slide 5D.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 19.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 11B.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
About the Presentations The presentations cover the objectives found in the opening of each chapter. All chapter objectives are listed in the beginning.
Copyright © 2006 by The McGraw-Hill Companies, Inc. All rights reserved. McGraw-Hill Technology Education Copyright © 2006 by The McGraw-Hill Companies,
Slide 7E.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Slide 10C.52 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 Tools of Software Development l 2 types of tools used by software engineers:
Chapter 3 Software Two major types of software
Introduction to Information System Development.
Introduction to Systems Analysis and Design Trisha Cummings.
Program development & programming languages Chapter 13.
Systems Analysis – Analyzing Requirements.  Analyzing requirement stage identifies user information needs and new systems requirements  IS dev team.
Systems Analysis And Design © Systems Analysis And Design © V. Rajaraman MODULE 14 CASE TOOLS Learning Units 14.1 CASE tools and their importance 14.2.
Implementation & Integration Phase Implementation, then integration: Implementation, then integration:  Each module is implemented by member of programmer.
System Analysis and Design
Slide 5.1 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill,
1 SYS366 Lecture 1: Introduction to Systems. 2 What is Software Development? Software Development implies developing some software – but it does not involve.
Configuration Management (CM)
Program Development Life Cycle (PDLC)
Design and Programming Chapter 7 Applied Software Project Management, Stellman & Greene See also:
Testing Workflow In the Unified Process and Agile/Scrum processes.
Slide 10.1 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented and Classical Software Engineering Eighth Edition,
Note Excerpts from Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R. Schach
Slide 5.1 Copyright © 2008 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R.
THE DESIGN WORKFLOW  Object-oriented design  The design workflow  The test workflow: Design  CASE tools for design  Challenges of the design workflow.
Slide 20.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with.
Capabilities of Software. Object Linking & Embedding (OLE) OLE allows information to be shared between different programs For example, a spreadsheet created.
Chapter 6 CASE Tools Software Engineering Chapter 6-- CASE TOOLS
Slide 5B.18 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
Principles of Computer Security: CompTIA Security + ® and Beyond, Third Edition © 2012 Principles of Computer Security: CompTIA Security+ ® and Beyond,
Connecting with Computer Science2 Objectives Learn how software engineering is used to create applications Learn some of the different software engineering.
CASE (Computer-Aided Software Engineering) Tools Software that is used to support software process activities. Provides software process support by:- –
Slide 5.1 Copyright © 2011 by The McGraw-Hill Companies, Inc. All rights reserved. Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill,
Slide 5.1 © The McGraw-Hill Companies, 2002 CASE (Computer-Aided Software Engineering) l Scope of CASE –Can support the entire life-cycle l Graphical display.
Slide 5.1 Lecture 5 THE TOOLS OF THE TRADE. Slide 5.2 Overview l Stepwise refinement l Cost–benefit analysis l Divide-and-conquer l Separation of concerns.
CS451 Software Maintenance Yugi Lee STB #555 (816) Note: This lecture was designed based on Stephen Schach’s.
Configuration Management
Slide 12F.135 © The McGraw-Hill Companies, 2005 Object-Oriented and Classical Software Engineering Sixth Edition, WCB/McGraw-Hill, 2005 Stephen R. Schach.
1 SYS366 Week 1 - Lecture 1 Introduction to Systems.
Chapter – 8 Software Tools.
Object-Oriented and Classical Software Engineering Eighth Edition, WCB/McGraw-Hill Stephen R. Schach 1.
Object-Oriented and Classical Software Engineering Seventh Edition, WCB/McGraw-Hill, 2010 Stephen R. Schach
CASE (Computer-Aided Software Engineering) Tools
Programming Logic and Design Seventh Edition Chapter 1 An Overview of Computers and Programming.
Slide 10.1 CHAPTER 10 OVERVIEW OF THE PREVIOUS CHAPTERS.
8.4 Management of Postdelivery Maintenance
Fundamentals of Information Systems, Sixth Edition
CSCI-235 Micro-Computer Applications
Object-Oriented Software Engineering WCB/McGraw-Hill, 2008 Stephen R
Chapter 18 Maintaining Information Systems
Computer Aided Software Engineering (CASE)
Tools of Software Development
Chapter 1 Introduction(1.1)
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 8 Slide 1 Tools of Software Development l 2 types of tools used by software engineers:
Programming Logic and Design Eighth Edition
Presentation transcript:

Slide 11A.1 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. An Introduction to Object-Oriented Systems Analysis and Design with UML and the Unified Process McGraw-Hill, 2004 Stephen R. Schach

Slide 11A.2 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CHAPTER 11 — Unit A CASE

Slide 11A.3 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Chapter Overview l Taxonomy of CASE l The Scope of CASE l Versions l Configuration Control l Build Tools l CASE Environments l Environments for Information Systems l Potential Problems with Environments l Productivity Gains with CASE Technology l CASE and Aesthetics

Slide 11A.4 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE l A computer cannot automatically develop an information system—yet –But computer programs can assist information technology professionals l These programs are termed CASE tools –(CASE stands for computer-aided software engineering, that is, the development and maintenance of software with the help of computers)

Slide 11A.5 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE (contd) l Computers can assist by carrying out much of the drudge work including: l The creation and organization of artifacts of all kinds, such as –Plans, contracts, specification documents, designs, source code, management information, and other documentation l Maintaining diagrams on the computer, including UML diagrams –Changes to a diagram can be made easily without having to redraw the entire diagram

Slide 11A.6 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE (contd) l CASE is not restricted to assisting with documentation l In particular, computers can assist with the complexity of information system development –Especially in managing all the details

Slide 11A.7 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Taxonomy of CASE l Tool, workbench, environment

Slide 11A.8 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Taxonomy of CASE (contd) l A CASE tool –A software product that assists in just one aspect of the development and maintenance of an information system »Examples: Tools that assist with flowcharts or UML diagrams l Types of CASE tools –UpperCASE or front-end tools »CASE tools that assist during the earlier workflows of the process (requirements, analysis, and design workflows) –LowerCASE or back-end tools »CASE tools that assist with implementation and maintenance

Slide 11A.9 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Data Dictionaries l The data dictionary is an important CASE tool –A computerized list of all attributes, methods, and parameters defined within the information system »(A method is an implementation of an operation) »(A parameter is data transferred to a method when that method is invoked at run-time) l Typical data dictionary entries for the Osbert Oglesby case study are shown in the next slide

Slide 11A.10 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Data Dictionaries (contd) l Typical data dictionary entries

Slide 11A.11 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Data Dictionary (contd) l Combine a data dictionary with a consistency checker –The resulting tool can check that »Every data item in the specification document is reflected in the design and »Every item in the design has been defined in the specification document

Slide 11A.12 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Data Dictionaries (contd) l A data dictionary can provide the data for report generators and screen generators –A report generator generates the code for printing a report –A screen generator generates the code for a data capture screen l Using such generators can speed up the construction of information systems

Slide 11A.13 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Data Dictionaries (contd) l Combining a –Data dictionary –UML drawing tool –Consistency checker –Report generator yields a requirements, analysis, and design workbench –Example: »Software through Pictures

Slide 11A.14 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Taxonomy of CASE (contd) l A CASE workbench –A collection of tools that together support one or two activities –(See diagram (b) on earlier slide) l An activity is not the same thing as a workflow –Examples: »The coding activity includes editing, compiling, testing, and debugging »A project management workbench is used for every workflow of the project »A coding workbench can be used for rapid prototyping as well as for the implementation and maintenance workflows

Slide 11A.15 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Taxonomy of CASE (contd) l Another class of workbench –A requirements management workbench »It allows systems analysts to organize and track the requirements of an information system development project –Commercial example: »RequisitePro

Slide 11A.16 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Taxonomy of CASE (contd) l A CASE environment –An environment supports the complete information system development and maintenance life cycle –The term integrated development environment (IDE) is sometimes used –(See diagram (c) on earlier slide)

Slide 11A.17 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Scope of CASE l Accurate and up-to-date documentation must be available at all times –This is a primary reason for implementing CASE technology l There is no way to tell which manually produced version of a set of artifacts is the current one l If the artifacts are produced using a CASE tool, then at any time there is only one copy of those artifacts –The online version accessed via the CASE tool

Slide 11A.18 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Scope of CASE (contd) l Programmers need online documentation for the –Operating system –Text editor –Programming language l Manuals must also be available online –Ensures availability at all time –Easier to query –Easier to update »More likely to be up to date

Slide 11A.19 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Scope of CASE (contd) l Communication among team members is vital –Many CASE environments and some CASE workbenches incorporate systems –Alternatively, is implemented via a Web browser –Other equally essential tools include spreadsheets and word processors

Slide 11A.20 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. The Scope of CASE (contd) l Coding tools such as text editors and debuggers are designed to simplify the programmer’s task l A structure editor is a text editor that “understands” the implementation language –In the same way that the spelling checker and grammar checker of a word processor “understand” English l Structure editors often form part of workbenches –They incorporate a pretty printer (or formatter) to ensure that the code always has a good visual appearance »Examples: Visual C++, Jbuilder

Slide 11A.21 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Versions l Whenever an information system is maintained, there are at least two versions –The old version and the new version l An information system is composed of artifacts (including documents and modules) –So, there will also be at least two versions of each of the component artifacts that have been changed

Slide 11A.22 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Revisions l A revision is a version constructed to fix a fault l The old version cannot be thrown away –The “corrected” version may be as faulty as the original –Also, the new version may not have been installed at all sites »The old version is then needed to reconstruct the fault

Slide 11A.23 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Revisions (contd) l When perfective and adaptive maintenance are performed, the old versions must be retained, too l Schematically, revisions all but overlap one another, to indicate that a revision is intended to replace its predecessor

Slide 11A.24 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Revisions and Variations l Schematic representation of revisions and variations

Slide 11A.25 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Variations l Variations are versions written for different operating systems and hardware l Versions are designed to coexist –Example: Printer drivers on a personal computer for »An inkjet printer, and »A laser printer l Versions are schematically portrayed as in the previous slide –This is to show that they coexist

Slide 11A.26 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Versions (contd) l A complicating factor is that, in general, there will be multiple revisions of each variation l To avoid drowning in a swamp of multiple versions, a CASE tool is needed

Slide 11A.27 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Version-Control Tools l The code for every module exists in three forms: –The source code »Nowadays written in C++ or Java –The compiled code »Produced by translating (compiling) the source code into the binary code that is the only language a computer understands –The executable load image »Produced by combining (linking) the compiled code for each module with run-time routines to produce an executable load image

Slide 11A.28 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Version-Control Tools l Executable load image

Slide 11A.29 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configurations l When generating an executable load image, the programmer must specify the version of each module l The set of the specific versions of the modules from which a given version of the executable load image is developed is the configuration of that version of the information system

Slide 11A.30 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configurations (contd) l If an information system fails, the programmer first has to recreate the failure –How can the programmer determine which revisions of which variations went into the version that crashed? l The obvious way: –Look at the executable load image and compare it to the compiled code

Slide 11A.31 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configurations (contd) l An executable load image is in binary format l Grouping binary digits (bits) into groups of –Three bits yields octal format –Four bits yields hexadecimal format

Slide 11A.32 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Executable Load Images l (a) Binary format l (b) Octal format l (c) Hexadecimal format

Slide 11A.33 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Executable Load Images (contd) l Comparing binary images by hand is an extremely laborious and error-prone task l When comparing hundreds of modules, each with multiple versions, the task is near impossible

Slide 11A.34 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Executable Load Images (contd) l Two problems when dealing with multiple versions: –First, distinguish between versions so that the correct version of each module is compiled and linked to form the information system »This problem is solved by a version-control tool –Second, given an executable load image, determine which version of each of its components went into it

Slide 11A.35 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Version-Control Tool l To distinguish between versions, a version-control tool is needed

Slide 11A.36 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Version-Control Tool (contd) l A common approach –The name of each artifact consists of two pieces »The artifact name itself, and »The revision number –Example: »Revisions acknowledgeMessage / 1, acknowledgeMessage / 2 –A variation name appears in parentheses –Examples: »Variations printerDriver (inkJet) and printerDriver (laser) »Multiple revisions of each variation printerDriver (laser) / 12, printerDriver (laser) / 13, and printerDriver (laser) / 14

Slide 11A.37 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Version-Control Tool (contd) l Naming of modules

Slide 11A.38 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Version-Control Tool (contd) l Additional problems arise when an information system is developed by a team –All nontrivial information systems are developed by teams! l More than just version control is therefore needed

Slide 11A.39 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control l A configuration-control tool is needed when more than one information technology professional is simultaneously working on an information system

Slide 11A.40 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control Example l Systems analyst P starts to fix a fault in artifact Compute Tax Class / 16, finds the fault, and fixes it l The artifact, now called Compute Tax Class / 17, is replaced in the version control system l At the same time as P, systems analyst Q starts to fix a different fault in Compute Tax Class / 16 l She locates the fault and fixes it a day later than P

Slide 11A.41 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control Example (contd) l Artifact Compute Tax Class / 18 is then installed in the version control system l Revision 17 contains only P’s changes l Revision 18 contains only Q’s changes –All of P’s changes have been lost l What is needed is a mechanism that allows only one user at a time to change an artifact

Slide 11A.42 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control (contd) l All the artifacts of an information systems should be under the control of a configuration control tool l When an information technology professional wants to change an artifact –He or she must check out that artifact

Slide 11A.43 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control (contd) l After making changes –He or she must check in the modified artifact l The manager must set up a baseline –A configuration (set of versions) of all the artifacts in the information system

Slide 11A.44 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control (contd) l When working on an artifact, a systems analyst makes copies of any needed artifacts and puts them into his or her private workspace –Changes to these private copies cannot affect the baseline versions l Before changing the baseline version of an artifact, the systems analyst freezes the current version –No one may ever make changes to any frozen version

Slide 11A.45 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control (contd) l After the systems analyst has made changes to the artifact –And after the changes have been tested by the quality assurance group l The new version of the artifact is installed –Thereby modifying the baseline l The previous version, now frozen, is retained because it may be needed in the future –However, it can never ever be altered

Slide 11A.46 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control (contd) l This scheme solves the problem with artifact Compute Tax Class l Both P and Q make private copies of Compute Tax Class / 16 in their own computers –They use those copies to analyze the respective faults that they have been assigned to fix l P decides what changes to make and freezes Compute Tax Class / 16

Slide 11A.47 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control (contd) l The resulting revision, Compute Tax Class / 17, becomes the baseline version l In the meantime, Q has found the second fault by testing a private copy of Compute Tax Class / 16 –Changes cannot now be made to Compute Tax Class / 16 because it has been frozen by systems analyst P l The baseline version is now Compute Tax Class / 17 –Any changes to the artifact must be made to that version

Slide 11A.48 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control (contd) l Q now freezes Compute Tax Class / 17 and changes it l The resulting artifact is tested, then installed as Compute Tax Class / 18 l This version incorporates the changes of P and Q l Revisions Compute Tax Class / 16 and Compute Tax Class / 17 must retained, but can never be altered

Slide 11A.49 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Configuration Control (contd) l Every artifact is subject to configuration control –Otherwise, management cannot monitor development l When configuration control is properly applied, management is aware of the status of every module l Early corrective action can be taken if project deadlines seem to be slipping –Example of a commercial configuration control tool: »PVCS, SourceSafe –Example of an open-source configuration control tool: »CVS

Slide 11A.50 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools l A build tool selects the correct version of each source-code module to be compiled and then linked together to form a specific version of the information system l Version-control tools distinguish among different versions of modules of source code

Slide 11A.51 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools l Keeping track of compiled code is more difficult –Some version-control tools do not attach revision numbers to compiled versions –To ensure that all their compiled code always is up to date, some organizations automatically compile the latest version of each module every night

Slide 11A.52 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools (contd) l A build tool solves this problem l For each executable load image, the programmer sets up a file specifying the source and compiled modules for that particular configuration

Slide 11A.53 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools (contd) l Configuration

Slide 11A.54 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools (contd) l A build tool works by attaching a date and time stamp to each module l When invoked –It compares the date of each source code module with its corresponding compiled code module l If the date of the source code module is earlier than the compiled code module, then the latter is up to date

Slide 11A.55 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools (contd) l But if the date of the source code module is later than the compiled code module, then the source code module has been changed since the last compilation l The build tool then invokes the compiler to recompile the source code

Slide 11A.56 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools (contd) l Next, the build tool compares the date and time stamp on the executable load image to those on every compiled module in that configuration l If the executable load image was created later than all the compiled modules, then there is no need to relink

Slide 11A.57 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools (contd) l But if a compiled module has a later stamp than that of the executable load image, then the executable load image does not incorporate the latest version of that compiled module l The build tool then invokes the linker to construct an updated executable load image

Slide 11A.58 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Build Tools (contd) l A build tool –Avoids unneeded compilations and linkages –Simplifies constructing an executable load image »Only one command is needed to put together an information system consisting of hundreds of modules l Build tools have been incorporated into numerous programming environments –Including »Visual Java and Visual C++ –An example of an open-source build tool »Ant (part of the Apache project)

Slide 11A.59 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE Environments l Ideally, every information system development organization should utilize an environment l An environment costs money for –The package itself, and –The hardware on which to run it

Slide 11A.60 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE Environments (contd) l For a smaller organization –A workbench, or –Just a set of tools may be adequate l But, if at all possible, an environment should be used to support both development and maintenance

Slide 11A.61 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Environments for Information Systems l Environments (IDEs) for developing information systems stress ease of use l Standard screens are incorporated –They can be modified endlessly via a user-friendly graphical user interface (GUI) generator l There is a code generator that takes the detailed design and automatically generates code in C++ or Java –No manual coding is needed

Slide 11A.62 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Environments for Information Systems (contd) l Examples of commercial environments: –Foundation –Rational Rose and System Architect (object oriented) l Example of an open-source environment: –ArgoUML (object oriented)

Slide 11A.63 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Potential Problems with Environments l No one environment is ideal for all information systems and all organizations –Every environment has its strengths and its weaknesses l Choosing an inappropriate environment can be worse than using no environment at all l Many environments essentially automate a manual methodology –If the environment enforces an inappropriate methodology, use of that environment will be counterproductive

Slide 11A.64 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Productivity Gains with CASE Technology l A 1992 study showed productivity gains of between 9 and 12 percent –At a cost of $125,000 per user l This alone cannot justify the introduction of CASE technology l However, the companies surveyed reported –Increased productivity –Shorter development time, and –Improvement in information system quality

Slide 11A.65 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Productivity Gains with CASE Technology (contd) l Introducing CASE technology leads to –Faster development –Fewer faults –Better usability –Easier maintenance –Improved morale

Slide 11A.66 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Productivity Gains with CASE Technology (contd) l Newer results from Fortune 500 companies l When training was provided in –Information system development in general, and –CASE technology in particular then –User satisfaction increased –Development schedules were met –Performance increased by 50 percent

Slide 11A.67 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Productivity Gains with CASE Technology (contd) l When training was not provided –Information systems were delivered late –Users were less satisfied l “A fool with a tool is still a fool”

Slide 11A.68 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE and Aesthetics l A CASE tool does not store UML diagrams l It stores a description of the information system –The tool then uses the stored description to create UML diagrams

Slide 11A.69 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE and Aesthetics (contd) l This approach makes it easy to make changes to the information system l Example: A user changes the name of a class by editing the name where it appears in a UML diagram on the screen –The CASE tool changes the name where it is stored –Every affected UML diagram now reflects the new name

Slide 11A.70 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. CASE and Aesthetics (contd) l This ability to handle change is essential when the Unified Process is used –The CASE tool supports the continual iteration and incrementation l Unfortunately, storing descriptions of information systems, not diagrams, has consequences regarding the appearance of UML diagrams drawn by CASE tools

Slide 11A.71 Copyright © 2004 by The McGraw-Hill Companies, Inc. All rights reserved. Continued in Unit 11B