Download presentation
Presentation is loading. Please wait.
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”
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.