Scribd
Upload
261 views

Software Systems Architecture: A-7E Avionic System: A Case Study in Utilizing Architectural Structures

This document describes the software architecture for the A-7E avionics system. The architecture is decomposed into three high-level modules: the Hardware-Hiding Module, Behavior-Hiding Module, and Software Decision Module. These modules are further decomposed into submodules. The architecture utilizes a layered structure based on the "uses" relationship between modules. The software is implemented using a process structure with cooperating processes that synchronize using signaling and waiting for events.

Uploaded by

ayushym
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
261 views

Software Systems Architecture: A-7E Avionic System: A Case Study in Utilizing Architectural Structures

This document describes the software architecture for the A-7E avionics system. The architecture is decomposed into three high-level modules: the Hardware-Hiding Module, Behavior-Hiding Module, and Software Decision Module. These modules are further decomposed into submodules. The architecture utilizes a layered structure based on the "uses" relationship between modules. The software is implemented using a process structure with cooperating processes that synchronize using signaling and waiting for events.

Uploaded by

ayushym
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 16

University of Palestine

Faculty of Applied Engineering and Urban


Planning
Software Engineering Department

Software Systems
Architecture
A-7E Avionic System:
A Case Study in Utilizing
Architectural Structures
Instructor: Tasneem Darwish

Outlines
Relationship to the Architecture Business Cycle
Requirements and Qualities
Architecture for the A-7E Avionics System

Instructor: Tasneem Darwish

A-7E Module Decomposition Structure


The decomposition tree is described beginning with the
three highest-level modules.
These are inspired by the observation that, in systems
like the A-7E, changes tend to come from three areas:
1. the hardware with which the software must interact,
2. the required externally visible behaviour of the system,
3. a decision only under the influence of a project's
software designer.

Instructor: Tasneem Darwish

A-7E Module Decomposition Structure


The decomposition tree is described beginning with the
three highest-level modules:
Hardware-Hiding Module
Behaviour-Hiding Module
Software Decision Module

Instructor: Tasneem Darwish

Hardware-Hiding Module

The Hardware-Hiding Module includes the procedures


that need to be changed if any part of the hardware is
replaced by a new unit with a different
hardware/software interface but with the same general
capabilities.
This module implements a set of abstract devices that
are used by the rest of the software.
The primary secrets of this module are the
hardware/software interfaces.
The secondary secrets of this module are the data
structures and algorithms used to implement the abstract
hardware.
One of the submodules of the Hardware-Hiding
Module is the Extended Computer Module that hides the
details of the processor.
Instructor: Tasneem Darwish

Behaviour-Hiding Module
The Behavior-Hiding Module includes procedures that
need to be changed if there are changes in requirements
affecting the required behaviour.
Those requirements are the primary secret of this
module.

These procedures determine the values to be sent to the


virtual output devices provided by the Hardware-Hiding
Module.

Instructor: Tasneem Darwish

Software Decision Module


The Software Decision Module hides software design
decisions that are based on mathematical theorems,
physical facts, and programming considerations such as
algorithmic efficiency and accuracy.
The secrets of this module are not described in the
requirements document. (design details)

This module differs from the other modules in that both


the secrets and the interfaces are determined by software
designers.
Changes in these modules are more likely to be
motivated by a desire to improve performance or
accuracy than by externally imposed changes.
Instructor: Tasneem Darwish

Software Decision Module


The following points describe the Decomposition of the
Software Decision Module:

Application Data Type Module


Data Banker Module
Filter Behaviour Module
Physical Models Module
Software Utility Module

System Generation Module

Instructor: Tasneem Darwish

A-7E
architecture
The figure shows the decomposition structure of the A7E architecture down to the third level

Instructor: Tasneem Darwish

USES STRUCTURE

the uses structure supplies the authoritative picture of


how the software interacts.
The concept behind the uses structure is the uses
relation. Procedure A is said to use procedure B if a
correctly functioning procedure B must be present in
order for procedure A to meet its requirements

Instructor: Tasneem Darwish

10

USES STRUCTURE
What we have is a picture of a system partitioned into
layers.
The Extended Computer Module is the bottommost
layer, and the Application Data Type Module is built
right on top of it
Layered architectures are a well-known architectural
pattern. Layering emerges from the uses structure, but is
not a substitute for it

Instructor: Tasneem Darwish

11

Process structure
Even though the underlying aircraft computer is a
uniprocessor, the Extended Computer Module presents a
virtual programming interface that features
multiprocessing capabilities.
This was to plan for if and when the A-7E computer was
replaced with an actual multi-processor

the software was implemented as a set of cooperating


sequential processes that synchronize with each other to
cooperatively use shared resources.

Instructor: Tasneem Darwish

12

Process structure
Processes are written for two purposes in the A-7E.
The first is for the function drivers to compute the
output values of the avionics software.
They are required to run periodically (e.g., to
continuously update a symbol position on the headsup display) or in response to some triggering event
(e.g., when the pilot presses the weapon release
button).
It is natural to implement these as processes.
Conceptually, function driver processes are
structured as follows:

Instructor: Tasneem Darwish

13

Process structure

Instructor: Tasneem Darwish

14

Process structure
Processes also occur as a way to implement certain
access procedures.
If the value returned by an access procedure is
expensive to compute, a programmer might meet the
timing requirements by continuously computing the
value in the background and simply returning the most
recent value immediately when the access procedure is
called. For example:

Instructor: Tasneem Darwish

15

Process structure
The process structure, then, consists of the set of
processes in the software.
The relation it contains is "synchronizes-with," which is
based on events that one process signals and one or
more processes await.
This relation is used as the primary input to the
scheduling activity, which includes deadlock avoidance

Instructor: Tasneem Darwish

16

You might also like