1. 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 srs@vuse.vanderbilt.edu

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

3. 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

4. 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)

5. 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

6. 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

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

8. 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

9. 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

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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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)

17. 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

18. 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

19. 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 e-mail systems –Alternatively, e-mail is implemented via a Web browser –Other equally essential tools include spreadsheets and word processors

20. 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

21. 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

22. 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

23. 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

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

25. 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

26. 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

27. 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

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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. 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

45. 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

46. 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

47. 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

48. 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

49. 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

50. 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

51. 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

52. 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

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

54. 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

55. 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

56. 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

57. 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

58. 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)

59. 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

60. 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

61. 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

62. 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)

63. 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

64. 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

65. 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

66. 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

67. 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”

68. 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

69. 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

70. 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

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