<- previous    index    next ->

Lecture 19, Software Architecture


 Make use of automation and test at every step


Much of this from "Software Engineering" by E.J.Braude  Ch 5.

"Software Architecture" similar to the architecture of
a building or other product, form follows function.

A clean, well designed, architecture facilitates minimizing
defects, meeting customer requirements, meeting cost and
schedule objectives, and can be extended and reused.

The software development industry has come a long way.
(There is always room for improvement and innovation.) 
We no longer have "programmers" who code up a program to
meet some requirement. We have professionals, often
called "Software Engineers" that use a disciplined process
to develop a computer program or total system of software
and data to meet, possibly complex requirements.

A software architecture starts with the big picture of
system requirements then successively refined the
architecture to the point where detailed design can
proceed with low risk.

Some top level architecture alternatives are:
1. Dataflow 
     Batch sequential
     Pipes and filters
2. Independent components
     Parallel communicating processes
     Client server systems
     Event driven systems
3. Virtual machines
     Interpreters
     Rule based systems
4. Repository 
     Database
     Hypertext systems
     Blackboards
     Cloud
5. User interface
     Graphical as local application or web based
       Point and click, drag and drop
       Menus, icons, combination
     Command line
6. Layered
     Combinations of the above



The chosen architecture for a product is typically in
the System Design Document and may use the format
of IEEE Standard 1016.
A snapshot of the 1016 SDD table of contents is:
1. Introduction
   1.1 Purpose
   1.2 Scope
   1.3 Definitions, acronyms, abbreviations
2. References
3. Decomposition description
   3.1 Module decomposition
       3.1.1 Module 1 description
       3.1.2 Module 2 ...
   3.2 Concurrent process decomposition
       3.2.1 Process 1 description
       3.2.2 Process 2 ...
   3.3 Data decomposition
       3.3.1 Data 1 description
       3.3.2 Data 2 ...
4. Dependency description
   4.1 Intermodule dependencies
   4.2 Interprocess dependencies
   4.3 Data dependencies
5. Interface description
   5.1 Module interface
       5.1.1 Module 1
       5.1.2 Module 2 ...
   5.2 Process interface
       5.2.1 Process 1
       5.2.2 Process 2 ...
6. Detailed design
   6.1 Module detailed design
       6.1.1 Module 1 detail
       6.1.2 Module 2 ...
   6.2 Data detailed design
       6.2.1 Data 1 detail
       6.2.2 Data 2 ...

Hmmmm? No 6.3 Process detailed design?
Processes may run concurrently as actual
operating system processes communicating
with messages, or as threads communicating
via the shared address space.

Moving into parallel programming of products, applications,
programs:

A modern computer will have many cores, each core
typically more powerful than a previous desktop
computer. A core runs a sequence of instructions
using an instruction cache, data cache, integer
and floating point arithmetic units. All cores
in a single processor share the RAM storage,
disk drives and input-output.

Multi processor computers are available that
may have a few to hundreds to thousands of processors.
The processors communicate over an interconnect
network, ethernet, infiniband, etc.
The largest super computer has over one million cores.

A process is a program or part of a program that
is scheduled by the operating system. Every process
has its private address space and typically uses
message passing to communicate with other processes.

A thread is an independent sequence of statements,
in a quality system, executed in a core, in a multi core
computer. All threads of any process, share a common
address space and must follow a discipline of
multiple read, single write, of shared data.

Programming languages typically have threads that
are reasonable to use. Multi processors use
tool kits such as Message Passing Interface, MPI,
or others to allow a single application to use
many processors that may have many cores each.


From tialert@ieee.org Tue Aug 27 10:34:05 2013
Subject: The Institute Online:
Did You Know? Edison Coined the Term "Bug"

You might think the phrase "computer bug" began in the 1940s
when programmer Grace Hopper and her colleagues found a dead
moth in a Harvard University computer. However, it was
actually coined much earlier, by Thomas Edison. With
the help of Paul Israel, editor of the Edison Papers,
the IEEE History Center traces the origins of the phrase.

We now use the term "defect" Rather than "bug" in
professional and quality assurance writing.

    <- previous    index    next ->

Other links

Go to top