CHAPTER 11 — Unit A

1. An Introduction toObject-Oriented Systems Analysis and Design with UML and the Unified ProcessMcGraw-Hill, 2004Stephen R. Schachsrs@vuse.vanderbilt.edu

2. CHAPTER 11 — Unit A CASE

3. Chapter Overview • Taxonomy of CASE • The Scope of CASE • Versions • Configuration Control • Build Tools • CASE Environments • Environments for Information Systems • Potential Problems with Environments • Productivity Gains with CASE Technology • CASE and Aesthetics

4. CASE • A computer cannot automatically develop an information system—yet • But computer programs can assist information technology professionals • These programs are termed CASEtools • (CASE stands for computer-aided software engineering, that is, the development and maintenance of software with the help of computers)

5. CASE (contd) • Computers can assist by carrying out much of the drudge work including: • The creation and organization of artifacts of all kinds, such as • Plans, contracts, specification documents, designs, source code, management information, and other documentation • Maintaining diagrams on the computer, including UML diagrams • Changes to a diagram can be made easily without having to redraw the entire diagram

6. CASE (contd) • CASE is not restricted to assisting with documentation • In particular, computers can assist with the complexity of information system development • Especially in managing all the details

7. Taxonomy of CASE • Tool, workbench, environment

8. Taxonomy of CASE (contd) • 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 • 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. Data Dictionaries • 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) • Typical data dictionary entries for the Osbert Oglesby case study are shown in the next slide

10. Data Dictionaries (contd) • Typical data dictionary entries

11. Data Dictionary (contd) • 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. Data Dictionaries (contd) • 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 • Using such generators can speed up the construction of information systems

13. Data Dictionaries (contd) • Combining a • Data dictionary • UML drawing tool • Consistency checker • Report generator yields a requirements, analysis, and design workbench • Example: • Software through Pictures

14. Taxonomy of CASE (contd) • A CASE workbench • A collection of tools that together support one or two activities • (See diagram (b) on earlier slide) • 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. Taxonomy of CASE (contd) • 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. Taxonomy of CASE (contd) • 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. The Scope of CASE • Accurate and up-to-date documentation must be available at all times • This is a primary reason for implementing CASE technology • There is no way to tell which manually produced version of a set of artifacts is the current one • 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. The Scope of CASE (contd) • Programmers need online documentation for the • Operating system • Text editor • Programming language • 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. The Scope of CASE (contd) • 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. The Scope of CASE (contd) • Coding tools such as text editors and debuggers are designed to simplify the programmer’s task • 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 • 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. Versions • Whenever an information system is maintained, there are at least two versions • The old version and the new version • 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. Revisions • A revision is a version constructed to fix a fault • 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. Revisions (contd) • When perfective and adaptive maintenance are performed, the old versions must be retained, too • Schematically, revisions all but overlap one another, to indicate that a revision is intended to replace its predecessor

24. Revisions and Variations • Schematic representation of revisions and variations

25. Variations • Variations are versions written for different operating systems and hardware • Versions are designed to coexist • Example: Printer drivers on a personal computer for • An inkjet printer, and • A laser printer • Versions are schematically portrayed as in the previous slide • This is to show that they coexist

26. Versions (contd) • A complicating factor is that, in general, there will be multiple revisions of each variation • To avoid drowning in a swamp of multiple versions, a CASE tool is needed

27. Version-Control Tools • 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. Version-Control Tools • Executable load image

29. Configurations • When generating an executable load image, the programmer must specify the version of each module • 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. Configurations (contd) • 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? • The obvious way: • Look at the executable load image and compare it to the compiled code

31. Configurations (contd) • An executable load image is in binary format • Grouping binary digits (bits) into groups of • Three bits yields octalformat • Four bits yields hexadecimalformat

32. Executable Load Images • (a) Binary format • (b) Octal format • (c) Hexadecimal format

33. Executable Load Images (contd) • Comparing binary images by hand is an extremely laborious and error-prone task • When comparing hundreds of modules, each with multiple versions, the task is near impossible

34. Executable Load Images (contd) • 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. Version-Control Tool • To distinguish between versions, a version-control tool is needed

36. Version-Control Tool (contd) • 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. Version-Control Tool (contd) • Naming of modules

38. Version-Control Tool (contd) • Additional problems arise when an information system is developed by a team • All nontrivial information systems are developed by teams! • More than just version control is therefore needed

39. Configuration Control • A configuration-control tool is needed when more than one information technology professional is simultaneously working on an information system

40. Configuration Control Example • Systems analyst P starts to fix a fault in artifact Compute Tax Class / 16, finds the fault, and fixes it • The artifact, now called Compute Tax Class / 17, is replaced in the version control system • At the same time as P, systems analyst Q starts to fix a different fault in Compute Tax Class / 16 • She locates the fault and fixes it a day later than P

41. Configuration Control Example (contd) • Artifact Compute Tax Class / 18 is then installed in the version control system • Revision 17 contains only P’s changes • Revision 18 contains only Q’s changes • All of P’s changes have been lost • What is needed is a mechanism that allows only one user at a time to change an artifact

42. Configuration Control (contd) • All the artifacts of an information systems should be under the control of a configuration control tool • When an information technology professional wants to change an artifact • He or she must check out that artifact

43. Configuration Control (contd) • After making changes • He or she must check in the modified artifact • The manager must set up a baseline • A configuration (set of versions) of all the artifacts in the information system

44. Configuration Control (contd) • When working on an artifact, a systems analyst makes copies of any needed artifacts and puts them into his or her privateworkspace • Changes to these private copies cannot affect the baseline versions • 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. Configuration Control (contd) • After the systems analyst has made changes to the artifact • And after the changes have been tested by the quality assurance group • The new version of the artifact is installed • Thereby modifying the baseline • The previous version, now frozen, is retained because it may be needed in the future • However, it can never ever be altered

46. Configuration Control (contd) • This scheme solves the problem with artifact Compute Tax Class • 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 • P decides what changes to make and freezes Compute Tax Class / 16

47. Configuration Control (contd) • The resulting revision, Compute Tax Class / 17, becomes the baseline version • 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 • The baseline version is now Compute Tax Class / 17 • Any changes to the artifact must be made to that version

48. Configuration Control (contd) • Q now freezes Compute Tax Class / 17 and changes it • The resulting artifact is tested, then installed as Compute Tax Class / 18 • This version incorporates the changes of P and Q • Revisions Compute Tax Class / 16 and Compute Tax Class / 17 must retained, but can never be altered

49. Configuration Control (contd) • Every artifact is subject to configuration control • Otherwise, management cannot monitor development • When configuration control is properly applied, management is aware of the status of every module • 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. Build Tools • 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 • Version-control tools distinguish among different versions of modules of source code