1. Software Tools and Environments
CS310 – Software Engineering

2. What happens when software is developed

3. Architecture of Eclipse

4. Historical evolution Dominant factors affecting evolution
technological developments – made certain tools necessary or possible
better understanding of software engineering needs and processes

5. 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)

6. Evolution of Software Tools
Individual tools developed to support single activities
e.g., compilation, debugging
Integrated environments are compositions of tools that work together
e.g., Eclipse, Visual Studio
Open environments
tools have public APIs which allow them to work with other tools

7. Lots of variations of tools
Breadth: tool, workbench, environment, …
Problem class: embedded, business, …
System size: small … large
User scale: individual, city, state, …
Number of sites
Process: product, people, or both
Process support: none, fixed, variable
Execution paradigm: state machine, Petri nets, …

8. Lots of variations of tools
Interaction mode
batch-oriented tools
interactive tools
Level of formality
syntax/semantics of artifacts produced
Dependency on phase of life cycle
Degree of standardization
Static vs. dynamic
Development tools vs. end-product components
Single-user vs. multi-user
Single-machine vs. network-aware

9. 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-specific editor) or multilingual

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

11. Representative tools: Code generators
Transform a high level description into a lower-level description
a specification into an implementation
Practical example
4th Generation Languages
also compilers!

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

13. Example Debugger

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

15. 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

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

17. Representative tools: GUI tools
Graphical User Interfaces are now standard
Common abstractions include windows and the desktop metaphor

18. Internal Model of UI View
SCREEN
First name
Last name
Birth date
day
month
year
Person
Day
Month
Year
Run-time
dialog
component
INTERNAL DATA STRUCTURE

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

21. Configuration Management
1.1
1.2
1.3
1.4
2.1
2.2
sequence of revisions
a branch and a
later join

22. System Building Tools Aid in building and rebuilding a product
Ensure consistent system 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

23. Representative tools: Reporting and 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

24. Representative tools: Reverse- and re-engineering
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
Support making the code and other artifacts consistent with each other

25. Representative tools: Process support
Maintain "to do" lists, remind of next activities in the process
Automate sequences of recurring actions
Full process support via PSEEs
Process-centered Software Engineering Environments

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

27. Tool integration into environments
UI integration
tools work separately but share common UI for accessing
Data integration
tools store all artifacts in a repository
common data representation
different tools use that data to communicate
Control integration approach
tools communicate through control messages
i.e., tools directly call each other
Process integration
all tools are built for a common purpose
each tool does a specific part of the overall task

28. Scope of integrated environments

29. Analyst workbench Focus on early phases: requirements and design
(“syntax-directed”) drawing of pictures
Analysis support, e.g. consistency
Managing information, e.g. set of requirements
Report generation

30. Programmer workbench Editing, analyzing, code
Debugging and instrumentation tools
Test coverage tools
Central tool: configuration control

31. Management workbench
Configuration control, including management of change requests
Work assignment
Effort estimation tools

32. Integration Mechanisms
Application programming interfaces (API)
Scripting languages
Plug-ins
Component/object architectures
Event interfaces

33. API-Based Integration

34. Plug-In Based Integration

35. Component/Object Integration

36. Scripting-Based Integration

37. Event-Based Integration

38. Android

39. Architectural Principles
Implicit in / imposed by Android’s Application Framework
Architecture building blocks
Hierarchical decomposition
Architectural styles
Architecture models
Implementation and deployment
Support for NFPs

40. Architecture Building Blocks
Components
Activity – UI screen-level component
Fragment – module handling events for specific UI portion
Service – background processing
Content Provider – storage and retrieval
Broadcast receiver – message router
Connectors
Explicit Message-Based – Intent via explicit recipient
Implicit Message-Based – Intent via Intent Filter
Data Access – Content Resolver
RPC – direct method invocation using IDL stubs
Configuration
XML Manifest

41. Hierarchical Decomposition
Top-level
Set of apps
App-level
Set of activities, services, etc.
Activity-level
Set of fragments

42. Architectural Styles Message-based implicit invocation
Message-based explicit invocation
Publish-subscribe
Shared state
Distributed objects

43. Implementation Android Development Framework (ADF)
Provides base classes that are extended with app-specific logic
Activity lifecycle
Android Runtime Environment (ART)
Provides implementation of Android’s connectors

44. Example Android App – K-9 Mail

45. K-9 Mail’s Manifest

46. K-9 Mail App’s Architecture
The app runs in its own “sandbox”