Software Engineering Tools and Environments Ch. 9 1 Outline How - PowerPoint PPT Presentation

Software Engineering Tools and Environments Ch. 9 1

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 2

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

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 4

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 5

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 6

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 7

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 8

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 9

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

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 11

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 12

Representative tools: Software testing (1) • Test documentation tools – support bookkeeping of test cases • forms for test case definition, storage, retrieval Project Name: Date of test: Tested function: Tested module: Test case description: Description of results: Comments: Ch. 9 13

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 14

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 15

Representative tools: GUI tools • Graphical User Interfaces are now standard • Common abstractions include – windows and the desktop metaphor Pole disks 1 3 2 0 3 0 Ch. 9 16

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 17

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

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

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 20

CVS 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 Ch. 9 21

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 22

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 23

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 24

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 25

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 26

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 27

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