Software Architecture

1
Software Architecture

• T. TRUONG
• Team Meeting 7
• 27 February 2008

2
Agenda

• Architectural Goals
• Constraints and Strategies
• System Architecture
• Database Architecture
• GUI Architecture
• Toolchain

3
Architectural Goals

• Ranked in order of decreasing importance
• Performance
• Split-phased, active-message based architecture,
  improved database engine.
• Modular construction
• Component based architecture.
• Flexible composition
• Interface-driven, distributed architecture.
• Reliability
• No dynamic memory allocation after
  initialization.
• Extensibility
• Table driven command processor, component based
  architecture
• Maintainability
• Automated document generation similar to JavaDoc.

3
4
Architectural Constraints Strategies

• Within the schedule and budget constraints for
  2009 delivery.
• Reuse existing code wherever appropriate.
• Incorporate publicly available proven toolchains
  and libraries.
• Incremental delivery if necessary.

5
Software Context Overview
6
Architectural Highlights

• The PALM-3000 software architecture is
• Component-based
• Interface-driven
• Split-phased
• Distributed
• Active-message-based

7
Component-Based Architecture

• Similar to objects
• Define functions and allocate state.
• State variables are strictly private.
• Different from objects
• Components are singletons cant instantiate
  them.
• Modeled after hardware cant instantiate
  control regs and output pins.
• Code reuse via templates and parameterized
  interface.
• Use purely local namespace
• A calls C and B calls C. Yet A and B refer to
  different implementations of C.
• Encourage modular design

8
Interface-Driven Architecture

• Components interact via bidirectional interfaces
• An interface commands U events
• Command function to be implemented by the
  interfaces provider.
• Calls down the component graph.
• Event function to be implemented by the
  interfaces user.
• Calls up the component graph.
• A component must implement the events in order to
  call the commands of the interface.
• A component may use or provide multiple
  interfaces.
• Separate construction from composition.
• Enable dynamic composition.
• Allow underlying implementations to be replaced
  easily.

9
Split-Phased Architecture

• Invocation and completion split into two separate
  phases of execution
• For a long-running operation, the call returns
  immediately. The called abstraction issues a
  callback (event) when it completes.
• Fully event-driven
• Keep the system responsive
• There is never a situation when an application
  needs to take an action but all of its threads
  are tied up in blocking calls
• Save memory
• Determining the exact stack size is difficult in
  case of a blocking operation. The OS often
  chooses a very conservative and therefore large
  size.
• Creating large variables on the stack is rarely
  necessary.

10
Distributed Component Architecture

• Based on proxy components
• Shield the client/user components from the fact
  that the underlying components are remote.
• All components have proxy capability.
• Use common library to enable proxy capability.

11
Active-Message-Based Architecture

• Active Messages provide the enabling mechanism
  for low-latency remote procedural calls.
• Provide messaging functionality for proxy
  components.

12
Implementation View
13
Database Architectural Highlights

• Consists of two main components
• AODR Data recorder component.
• AODS Data server component.
• Provides publish-subscribe capability.
• Embeddable, in-memory, not client-server
• Components may link directly into the
  application.
• Run in the same address space as the application.
• No interprocess-communication required.

14
Database Architectural Highlights (Continued)

• Simple function-call API
• Simple key/value lookup and store.
• No query language (SQL) to parse.
• No execution plan to produce.
• Not a relational database
• API binding for C, Java,and IDL language.
• Data stored in application-native format
• No translation or mapping required.
• Configurable Cache
• Provides fast access to memory-resident data.
• Minimizes data stores to disk.
• Exploits temporal locality of reference.

15
Database Architectural Highlights (Continued)

• High concurrency
• Multiple processes (readers and writers) on a
  single machine, or multiple threads in a single
  process, can all use the same database
  concurrently.
• Transactions and recovery
• Permit multiple changes appear at once.
• Guarantee the database is complete and usable
  after a system or application crash.
• Hot backups
• Support backups while the database is in use,
  using standard Unix utilities (dump, tar, cpio,
  cp, )

Nothing more than key/value lookups with cache
management plus transaction and locking support
16
Graphical User Interface

• Support multiple GUI clients
• One controller with multiple viewers.
• Thin Java clients
• No automation logic.
• Decouple automation logic from GUI logic.
• XML-based user interface
• Develops much faster and more easily than in
  ordinary Java.
• Allows data binding (properties updated in
  real-time as values of expressions change).
• Supports powerful CSS stylesheet (enables
  skinning).
• Separates logic from presentation.

17
Open Source Toolchain

• nesC
• A component-oriented programming language,
  C-extension.
• Compiler is an extension of GCC.
• Compiler outputs C code or object code.
• nesdoc
• Generate code documentation using simple tags.
• Same concept as JavaDoc.
• Can generate a component graph using dot.
• Berkeley DB
• The most efficient, most scalable, and fastest
  database engine available today.