CASE Tools

1. CASE Tools CIS 376 Bruce R. Maxim UM-Dearborn

2. CASE Tools • Computer-Aided Software Engineering • Prerequisites to tool use • Need a collection of useful tools that help in every step of building a product • Need an organized layout that enables tools to be found quickly and used efficiently • Need a Skilled craftsperson who understands how to use the tools effectively

3. Upper CASE requirements specification planning design Lower CASE implementation integration maintenance CASE Tools

4. CASE Building Blocks - 1 • CASE tools • Integration framework • specialized programs allowing CASE tools to communicate with one another • Portability services • allow CASE tools and their integration framework to migrate across different operating systems and hardware platforms without significant adaptive maintenance

5. CASE Building Blocks - 2 • Operating system • database and object management services • Hardware platform • Environmental architecture • hardware and system support

6. A Taxonomy of CASE Tools business systems planning project management support CASE analysis and design Database programming integration &testing prototyping/simulation tools re–engineering framework

7. CASE Tool Taxonomy - 1 • Business process engineering tools • represent business data objects, their relationships, and flow of the data objects between company business areas • Process modeling and management tools • represent key elements of processes and provide links to other tools that provide support to defined process activities • Project planning tools • used for cost and effort estimation, and project scheduling

8. CASE Tool Taxonomy - 2 • Risk analysis tools • help project managers build risk tables by providing detailed guidance in the identification and analysis of risks • Requirements tracing tools • provide systematic database-like approach to tracking requirement status beginning with specification

9. CASE Tool Taxonomy - 3 • Metrics and management tools • management oriented tools capture project specific metrics that provide an overall indication of productivity or quality, technically oriented metrics determine metrics that provide greater insight into the quality of design or code • Documentation tools • provide opportunities for improved productivity by reducing the amount of time needed to produce work products

10. CASE Tool Taxonomy - 4 • System software tools • network system software, object management services, distributed component support, and communications software • Quality assurance tools • metrics tools that audit source code to determine compliance with language standards or tools that extract metrics to project the quality of software being built

11. CASE Tool Taxonomy - 5 • Database management tools • RDMS and OODMS serve as the foundation for the establishment of the CASE repository • Software configuration management tools • uses the CASE repository to assist with all SCM tasks (identification, version control, change control, auditing, status accounting) • Analysis and design tools • enable the software engineer to create analysis and design models of the system to be built, perform consistency checking between models

12. CASE Tool Taxonomy - 6 • PRO/SIM tools • prototyping and simulation tools provide software engineers with ability to predict the behavior of real-time systems before they are built and the creation of interface mockups for customer review • Interface design and development tools • toolkits of interface components, often part environment with a GUI to allow rapid prototyping of user interface designs

13. CASE Tool Taxonomy - 7 • Prototyping tools • enable rapid definition of screen layouts, data design, and report generation • Programming tools • compilers, editors, debuggers, OO programming environments, fourth generation languages, graphical programming environments, applications generators, and database query generators • Web development tools • assist with the generation of web page text, graphics, forms, scripts, applets, etc.

14. CASE Tool Taxonomy - 8 • Integration and testing tools • Data acquisition • get data for testing • static measurement • analyze source code without using test cases • dynamic measurement • analyze source code during execution • Simulation • simulate function of hardware and other externals) • test management • cross-functional tools

15. CASE Tool Taxonomy - 9 • Static analysis tools • code-based testing tools, specialized testing languages, requirements-based testing tools • Dynamic analysis tools • intrusive tools modify source code by inserting probes to check path coverage, assertions, or execution flow, non-intrusive tools use a separate hardware processor running in parallel with processor containing the program being tested

16. CASE Tool Taxonomy - 10 • Test management tools • coordinate regression testing, compare actual and expected output, conduct batch testing, and serve as generic test drivers • Client/server testing tools • exercise the GUI and network communications requirements for the client and server

17. CASE Tool Taxonomy - 11 • Reengineering tools • reverse engineering to specification tools • generate analysis and design models from source code, where used lists, and other design information • code restructuring and analysis tools • analyze program syntax, generate control flow graph, and automatically generates a structured program • on-line system reengineering tools • used to modify on-line DBMS

18. The next 17 slides come from Sommerville’s book

19. Requirements validation • Concerned with demonstrating that the requirements define the system that the customer really wants • Requirements error costs are high so validation is very important • Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error

20. Requirements validation techniques • Requirements reviews • Systematic manual analysis of the requirements • Prototyping • Using an executable model of the system to check requirements. • Test-case generation • Developing tests for requirements to check testability • Automated consistency analysis • Checking the consistency of a structured requirements description

21. Automated consistency checking

22. Requirements management • Requirements management is the process of managing changing requirements during the requirements engineering process and system development • Requirements are inevitably incomplete and inconsistent • New requirements emerge during the process as business needs change and a better understanding of the system is developed • Different viewpoints have different requirements and these are often contradictory

23. Requirements Change • The priority of requirements from different viewpoints changes during the development process • System customers may specify requirements from a business perspective that conflict with end-user requirements • The business and technical environment of the system changes during its development

24. Requirements evolution

25. Requirements Management Planning • During the requirements engineering process, you have to plan: • Requirements identification • How requirements are individually identified • A change management process • The process followed when analysing a requirements change • Traceability policies • The amount of information about requirements relationships that is maintained • CASE tool support • The tool support required to help manage requirements change

26. Traceability • Traceability is concerned with the relationships between requirements, their sources and the system design • Source traceability • Links from requirements to stakeholders who proposed these requirements • Requirements traceability • Links between dependent requirements • Design traceability • Links from the requirements to the design

27. CASE tool support • Requirements storage • Requirements should be managed in a secure, managed data store • Change management • The process of change management is a workflow process whose stages can be defined and information flow between these stages partially automated • Traceability management • Automated retrieval of the links between requirements

28. Requirements Change Management • Should apply to all proposed changes to the requirements • Principal stages • Problem analysis. Discuss requirements problem and propose change • Change analysis and costing. Assess effects of change on other requirements • Change implementation. Modify requirements document and other documents to reflect change

29. CASE Workbenches • A coherent set of tools that is designed to support related software process activities such as analysis, design or testing • Analysis and design workbenches support system modelling during both requirements engineering and system design • These workbenches may support a specific design method or may provide support for a creating several different types of system models

30. An analysis and design workbench

31. Analysis workbench components • Diagram editors • Model analysis and checking tools • Repository and associated query language • Data dictionary • Report definition and generation tools • Forms definition tools • Import/export translators • Code generation tools

32. Testing Workbenches • Testing is an expensive process phase. • Testing workbenches provide a range of tools to reduce the time required and total testing costs • Most testing workbenches are open systems because testing needs are organization-specific • Difficult to integrate testing with closed design and analysis workbenches

33. Testing Workbench

34. Testing Workbench Adaptation • Scripts may be developed for user interface simulators and patterns for test data generators • Test outputs may have to be prepared manually for comparison • Special-purpose file comparators may be developed

35. Integrated CASE Environments -1 • Provide mechanism for sharing information among all tools contained in the environment • Enable changes to items to be tracked to other information items • Provide version control and overall configuration management • Allow direct access to any tool contained in the environment • Establish automated support for the chosen software process model, integrating CASE tools and SCI's into a standard work break down structure

36. Integrated CASE Environments -2 • Establish automated support for the chosen software process model, integrating CASE tools and SCI's into a standard work break down structure • Enable users of each tool to experience a consistent look and feel at the human-computer interface • Support communication among software engineers • Collect both management and technical metrics to improve the process and the product

37. The Challenge: Putting it Together

38. An Integration Framework user interface layer interface tool kit presentation protocol tools management services CASE tools layer tool object management layer integration services configuration management services shared repository layer CASE database access control functions

39. Integration Architecture - 1 • User Interface Layer • interface toolkit • contains software for UI management and library of display objects • common presentation protocol • guidelines that give all CASE tools the same look and feel (icons, mouse behavior, menu names, object names) • Tools Layer • tools management services • control behavior of tools inside environment • CASE tools themselves

40. Integration Architecture - 2 • Object management layer (OML) • performs the configuration management function, working with the CASE repository OML provides integration services • Shared repository layer • CASE database and access control functions enabling the OML to interact with the database

41. CASE Repository Functions - 1 • Data integrity • includes functions to validate entries to the repository and ensure consistency among related objects • Information sharing • provides mechanism for sharing information among multiple developers and multiple tools, controls modification of information • Data-tool integration • establishes shared data model and performs configuration management functions

42. CASE Repository Functions - 2 • Data-data integration • database management system allowing access to related objects so functions can be achieved • Methodology enforcement • E-R model used to define steps needed to be conducted to build the repository contents • Document standardization • definition of objects in the database leads directly to a standard approach for creation of engineering documents

43. Data Integration:The CASE Repository

44. CASE Repository Content Summary • Problem to be solved. • Problem domain. • Emerging solution. • Rules pertaining to software process methodology. • Project plan. • Organizational content.

45. DBMS Features Needed for CASE Repositories • Non-redundant data storage • High-level access • Data independence • Transaction control • Ad hoc data queries and reports • Openness • Multi-user support

46. CASE Repository Features - 1 • Storage of sophisticated data structures • diagrams • documents • files • simple variables • information model describing relationships and semantics of data stored in repository

47. CASE Repository Features - 2 • Integrity enforcement • business rules • policies, constraints • requirements on the information being entered into repository, triggers may be used to check the validity of the design models in real time

48. CASE Repository Features - 3 • Semantic-rich tool interface • repository meta-model contains semantics that enable a variety of tools to interpret meaning of data stored in the repository • Process/project management • contains information about the software application • characteristics of each project • organization's general process for software development - phases, tasks, deliverables

49. Configuration Management Features Need by CASE Tools • Versioning • Dependency tracking and change management • Requirements tracing • Configuration management • Audit trails

50. The next 3 slides come from Sommerville’s book