Software Engineering Tools and Environments

1. CSC 3910 Software Engineering Spring 2011 Time: 1:30 to 2:20 Meeting Days: MWF Location: Oxendine 1256 Textbook: Fundamentals of Software Engineering, Author: Carlo Ghezzi, et al, 2003, Pearson Software Engineering Tools and Environments Ch. 9

2. Outline • How did the field evolve? • How can tools and environments be classified and compared? • What are the main categories? • How can tools be integrated? • What motivates new tools/environments? Ch. 9

3. Historical evolution • Dominant factors affecting evolution • technological developments • made certain tools necessary or possible • better understanding of software engineering processes Ch. 9

4. Technological developments—examples— • Advances in graphical displays and user interfaces • graphical editors • graphical user interfaces (GUIs) • visual languages • Advances in distributed systems • tools supporting distributed configuration management and teams (groupware) Ch. 9

5. Evolution • Individual tools developed to support single activities (e.g.,compilation, debugging) • Integrated environments, i.e., tools that work together • e.g., environment supporting one programming language • Open environments • tools have public interfaces which allow them to communicate and cooperate with other tools which respect those interfaces Ch. 9

6. Dimensions for comparison (1) • Interaction mode • batch-oriented tools • interactive tools • Level of formality • syntax/semantics of documents produced • Dependency on phase of life cycle • Degree of standardization Ch. 9

7. Dimensions for comparison (2) • Static vs. dynamic • Development tools vs. end-product components • Single-user vs. multi-user • Single-machine vs. network-aware Ch. 9

8. Representative tools:Editors • Textual or graphical • Can follow a formal syntax, or can be used for informal text or free-form pictures • Monolingual (e.g., Java editor) or multilingual Ch. 9

9. Representative tools:Linkers • Combine object-code fragments into a larger program • can be monolingual or polylingual • In a broader sense, tools for linking specification modules, able to perform checking and binding across various specification modules Ch. 9

10. Representative tools:Interpreters • Traditionally at the programming language level • Also at the requirements specification level • requirements animation • Can be numeric or symbolic Ch. 9

11. Representative tools:Code generators • In a general sense, transform a high level description into a lower-level description • a specification into an implementation • Practical example • 4th Generation Languages Ch. 9

12. Representative tools:Debuggers • May be viewed as special kinds of interpreters where • execution state inspectable • execution mode definable • animation to support program understanding Ch. 9

13. Representative tools: Software testing (1) • Test documentation tools • support bookkeeping of test cases • forms for test case definition, storage, retrieval Ch. 9

14. Representative tools: Software testing (2) • Tools for test data derivation • e.g., synthesizing data from path condition • Tools for test evaluation • e.g., various coverage metrics • Tools for testing other software qualities Ch. 9

15. Representative tools:Static analyzers • Data and flow control analyzers • can point out possible flaws or suspicious-looking statements • e.g., detecting uninitialized variables Ch. 9

16. Representative tools:GUI tools • Graphical User Interfaces are now standard • Common abstractions include • windows and the desktop metaphor Ch. 9

17. User-Interface Management Systems • Provide a set of basic abstractions (windows, menus, scroll bars, etc.) that may be used to customize a variety of interfaces • Provide a library of run-time routines to be linked to the developed application in order to support input and output • UIMS fall both under the category of development tools and under the category of end-product components Ch. 9

18. Progr. language Run-time dialog component End user run-time support Dialog development tools Progr. Developer env.mt UIMS as development tool and end-product component Ch. 9

19. INTERNAL DATA STRUCTURE Person SCREEN First name Last name Birth date First name Last name Year Day Month day month Birth date Run-time year dialog component Run-time structure of a UIMS Ch. 9

20. Representative tools:Configuration Management • Repository • shared database of artifacts • Version management • versions stored, change history maintained • Work-space control • check-out into private work-space • check-in into shared work-space • Product modeling and building • facilities to (re)build products Ch. 9

21. 1.2 1.1 1.3 2.1 2.2 1.4 sequence of revisions 1.1 1.2 1.3 2.1 a branch and a later join 1.2.1.1 1.2.1.2 CVS Ch. 9

22. make aids in building and rebuilding a product helps keep a system in a consistent state after modifications 1. sys : mod1.o mod2.o 2. ld mod1.o mod2.o -o sys 3. mod1.o : mod1.c incl.h 4. cc -c mod1.c 5. mod2.o : mod2.c incl.h 6. cc -c mod2.c Ch. 9

23. Representative tools:Tracking tools • Used during entire process to maintain information about the process and track that information • The most important of these are defect-tracking tools • used to store information about reported defects in the software product and track that information Ch. 9

24. Representative tools:Reverse and reengineering • Program understanding systems • synthesize suitable abstractions from code • e.g., control and data flow graphs or use graphs • extract cross-references and other kinds of documentation material on the product • Reverse engineering tools also support the process of making the code and other artifacts consistent with each other Ch. 9

25. Representative tools:Process support • Maintain "to do" lists, reminding next activities in the process • Automate sequences of recurring actions • Full process support via PSEEs (Process-centered Software Engineering Environments) • driven by a process-modeling language Ch. 9

26. Representative tools:Management • Tools for Gantt and PERT charts • graphical interface • support to analysis • Cost estimation tools • based on models, such as COCOMO Ch. 9

27. Tool integration • Data integration approach • store all process artifacts in a repository • common data representation for artifacts that different tools can use to communicate with each other • Control integration approach • different tools can communicate with each other through control messages Ch. 9

28. Forces influencing tool evolution • To support new technology • To support new software processes • To support a particular method or methodology Ch. 9