When should you use CASE tools 1 Use

When should you use CASE tools? 1

Use of CASE tools • There is a wide range of costs, as well as benefits, associated with CASE tools, so you should adopt one only when it actually is your best option. • On the surface, it is easy to assume that if you're an agile modeler that you aren't going to use a Computer Aided System Engineering (CASE) tool. • Poppycock!( ) ﻛﻼﻡ ﻓﺎﺭﻍ An agile modeler uses a tool, any tool, when that tool makes the most sense for that situation. 2

Agile Modeling (AM) • Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. • Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and lightweight manner 3

• Just like a carpenter( ) ﺍﻟﻨﺠﺎﺭ will use a manual screwdriver sometimes and other times an electric screwdriver, • sometimes an agile modeler will use an index card and other times a complex software design tool. 4

• Any tools, including CASE tools, should be used only when using the tool is the option that provides the maximal value for your investment. • This is basic investment theory -- if you can invest your money one way and get a 10 percent overall return, or if you can invest your money another way and get a 15 percent overall return, everything else being equal, you're better off with the second investment. 5

Modeling tools choices With respect to modeling tools, you always have several choices: • Use simple tools such as index cards and whiteboards. • Use a diagramming tool such as Microsoft Visio. • Use a more complicated tool such as Together. Soft's Together/J, Rational Rose, or Computer Associate's ERWin. 6

Calculate the expected value for your investment in a tool • So how do you calculate the expected value for your investment in a tool? we suggest that you don't, at least not from a strict accounting sense of the idea. • Yes, you could prepare a complex spreadsheet listing all the costs, both quantitative costs that have a clear dollar value and qualitative costs that need to be translated into a dollar value and then compare them with the expected quantitative and qualitative benefits. 7

Calculate the net present value • And of course, you naturally have to calculate the net present value (NPV) of all of those figures to ensure that you're comparing apples to apples. • There is a pretty good write-up of how to do all this in the book Process Patterns if you're really interested, but we strongly recommend against this sort of lengthy analysis. Why? Because it's a lot of work that is, more often than not, just a façade( ) ﺍﻟﻮﺍﺟﻬﺔ used to justify a political decision anyway. 8

Potential CASE tool costs • Initial training and education. • Evaluation costs. • Maintenance of the model over time. • Upgrade costs of the tool. • Time lost waiting for the tool to do its job 9

Potential CASE tool costs (cont. ) • Time lost over-using the tool (e. g. making your diagrams look pretty, and so on) • Migration costs to port models to another tool • CASE tools often promote syntax (in other words, your model looks good but doesn't necessarily work) 10

Potential CASE tool costs (cont. ) • Generated code is often too simplistic, or cluttered( ) ﺗﺸﻮﺵ with extraneous( ) ﺩﺧﻴﻠﺔ information required by the tool • Poor user interfaces often hamper( ) ﻳﻌﻴﻖ the modeling effort • Inadequate integration with other tools reduces productivity and/or requires integration work • Complex tools often prevent the inclusion of nondevelopers in your modeling efforts 11

Potential CASE tool benefits • Forward engineering (code generation) • Reverse engineering of existing code • Support for changing levels of abstraction (for example, from requirements to analysis to design to code) • Testing of the consistency and validity of your models • Synchronization of models with delivered code • Support for different views and/or potential solutions to a problem • Generation of documentation 12

Supporting software Alfonso Fuggetta classified CASE into 3 categories: • Tools support only specific tasks in the software process. • Workbenches support only one or a few activities( specifications, design, implementations, validations … ). • Environments support (a large part of) the software process. 13

Workbenches and environments CASE • Workbenches and environments are generally built as collections of tools. • Tools can therefore be either stand alone products or components of workbenches and environments. 14

Workbenches achievements Workbenches integrate several CASE tools into one application to support specific software-process activities. Hence they achieve: • a homogeneous and consistent interface. • easy control of integration. • access to a common data set managed in a centralized way (data integration). 15

Workbenches classes CASE workbenches can be further classified into following 8 classes: • Business planning and modeling • Analysis and design • User-interface development • Programming • Verification and validation • Maintenance and reverse engineering • Configuration management • Project management 16

Environments CASE environments are classified based on the focus/basis of integration to: • Toolkits • Language-centered • Integrated • Fourth generation • Process-centered 17

Toolkits • Toolkits are loosely integrated collections of products easily extended by aggregating different tools and workbenches. • Typically, the support provided by a toolkit is limited to programming, configuration management and project management. • And the toolkit itself is environments extended from basic sets of operating system tools, for example, the Unix Programmer's Work Bench. 18

Toolkits (cont. ) • The resulting files are unstructured and could be in different format, therefore the access of file from different tools may require explicit file format conversion. • However, since the only constraint for adding a new component is the formats of the files, toolkits can be easily and incrementally extended. [ 19

Language-centered • The environment itself is written in the programming language for which it was developed, thus enabling users to reuse, customize and extend the environment. • Integration of code in different languages is a major issue for language-centered environments. • Lack of process and data integration is also a problem. 20

Language-centered (cont. ) • The strengths of these environments include good level of presentation and control integration. • Interlisp, Smalltalk, Rational, and KEE are examples of language-centered environments. 21

Integrated • These environments achieve presentation integration by providing uniform, consistent, and coherent( ) ﻣﺘﻤﺎﺳﻚ tool and workbench interfaces. • Data integration is achieved through the repository concept: they have a specialized database managing all information produced and accessed in the environment. • Examples of integrated environment are IBM AD/Cycle and DEC Cohesion. 22

Fourth-generation • Fourth-generation environments were the first integrated environments. • They are sets of tools and workbenches supporting the development of a specific class of program: electronic data processing and business-oriented applications. • In general, they include programming tools, simple configuration management tools, document handling facilities and, sometimes, a code generator to produce code in lower level languages. Informix 4 GL, and Focus fall into this category. 23

Process-centered • Environments in this category focus on process integration with other integration dimensions as starting points. A process-centered environment operates by interpreting a process model created by specialized tools. They usually consist of tools handling two functions: – Process-model execution – Process-model production – Examples are East, Enterprise II, Process Wise, Process Weaver, and Arcadia. 24

Risks and associated controls Common CASE risks and associated controls include: • Inadequate standardization: Linking CASE tools from different vendors (design tool from Company X, programming tool from Company Y) may be difficult if the products do not use standardized code structures and data classifications. File formats can be converted, but usually not economically. 25

Risks and associated controls cont. Common CASE risks and associated controls include: (cont. ) • Controls include using tools from the same vendor, or using tools based on standard protocols and insisting on demonstrated compatibility. Additionally, if organizations obtain tools for only a portion of the development process, they should consider acquiring them from a vendor that has a full line of products to ensure future compatibility if they add more tools. 26

Risks and associated controls cont. • Unrealistic expectations: Organizations often implement CASE technologies to reduce development costs. • Implementing CASE strategies usually involves high start-up costs. Generally, management must be willing to accept a long-term payback period. • Controls include requiring senior managers to define their purpose and strategies for implementing CASE technologies. 27

Risks and associated controls cont. • Slow implementation: Implementing CASE technologies can involve a significant change from traditional development environments. • Typically, organizations should not use CASE tools the first time on critical projects or projects with short deadlines because of the lengthy training process. • Additionally, organizations should consider using the tools on smaller, less complex projects and gradually implementing the tools to allow more training time. 28

Risks and associated controls cont. • Weak repository controls: Failure to adequately control access to CASE repositories may result in security breaches or damage to the work documents, system designs, or code modules stored in the repository. • Controls include protecting the repositories with appropriate access, version, and backup controls. 29