Software Tools and Environments CS310 – Software Engineering

What happens when software is developed

Architecture of Eclipse

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

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)

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

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, …

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

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

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

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!

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

Example Debugger

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

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

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

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

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

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

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

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

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

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

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

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

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

Scope of integrated environments

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

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

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

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

API-Based Integration

Plug-In Based Integration

Component/Object Integration

Scripting-Based Integration

Event-Based Integration

Android

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

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

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

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

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

Example Android App – K-9 Mail

K-9 Mail’s Manifest

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