2/21/03 – Intro to Software Eng – Lecture Notes


“Foundations for the Study of Software Architecture  (Perry, Wolf)

Software Architecture Discussion (continued from January)


** Why does a chicken coop have only two doors?  Because if it had 4, it would be a sedan.


Examples:  multi-phase compilers – sequential vs. parallel

·         Character/Token relationships



·         Each phase completes before the next phase, data elements are passed directly from on to the next

·         Form descriptions must include the relationships and constraints among the elements, including relative weightings and preferences

·         Current type-based schemes are insufficient

·         Natural interdependence between processing and data views


Parallel Process, Shared Data Structure Compiler Architecture

·         Connecting elements:  shared representation, parallel execution with eager evaluation

·         Application-oriented properties

o        >1 processing elements affecting the state of the internal representation, concurrently

o        tokens and phrases consumed

o        correlated phrases accumulated

·         Connector/Data View

o        Parallel path expressions for each data element

o        Parallel path expressions relating data elements


Research in Architecture:  FORM  (descriptions, approaches)

-          Configuration – the linking of different objects

-          Type – identifying components with a certain behavior

-          Patterns – decidable; describing connectors

-          Properties – undecidable; depends on people and tools


“Linux as a Case Study:  Its Extracted Software Architecture” (Bowman, Holt, and Brewster)

Linux was a good candidate because it was a fairly small manageable system, with little documentation in existence.



** When in doubt, reorganize



a type of UNIX (Bell Labs – based on Multix at MIT)

-          open source

-          10,000 to 1.5 million lines of code in 7 years

-          Documentation

o        individual subsystems and algorithms

o        no architectural spec

-          Prescription – conceptual (optative)

-          Description – concrete (indicative)


**A man in a hotel in Toronto went to wash his hands in the sink, and turned on the faucet marked “C”, only to scald his hand in hot water.  When he went to the desk to complain, the clerk informed him that the “C” stood for “chaud”, the French word for hot.  The guest went back to his room, and noticed that the other faucet was also marked “C”.  He questioned the clerk again, who replied, “That one stands for ‘cold’, we’re bilingual.”


Existing Documentation

·         Conceptual

o        Important relationships and concepts

o        Initial system structure

·         Concrete

o        Use directory structure, naming conventions, source code and comments

o        Extract dependencies from source

o        Use relationships and clustering to determine relationships between subsystems

o        Concrete yielded by


Major Subsystems:

                Process scheduler

                Memory Manager

                File System

                Network Interface

                Inter-Process Communication



** Why did AT&T remove all the comments from UNIX when they distributed?  They didn’t.  There just weren’t any.


·         File System

o        access to hardware devices

o        logical interface to physical locations

o        store data

o        Façade – abstract interface

§         Hide actual

o        Internal subsystems:  device drivers, logical file system, executable file formats, file quota, buffer cache, system call interface (façade), virtual file system (façade)

o        Dependencies:  device driver -> process scheduler, logical file system -> network interface, memory manager -> virtual file system

·         Extracting a Hierarchy

o        Source files – Function Call + Variable Access -> control and data flows

o        Manual clustering

o        Grok – extract relationships, visualization easy to understand

o        See figure 5

o        WHY is everything interconnected?

§         Performance, efficiency, hacks

§         Avoids logical interfaces

§         Expediency

** Lesson: conceptual simpler than concrete

Automated tools are useful, but human judgment is still necessary

Concrete architecture has substantially more dependencies than conceptual

Some dependencies for developer expediency

Some dependencies were missed in the conceptual model


** Problem with COTS usage – architectural level


“Architectural Mismatch or Why it’s hard to build systems out of existing parts” (Garlan, Allen, and Ockerbloom)


·         low-level interoperability

·         different tradeoffs


Aesop – given an architecture style, generate an environment for that style

·         architectural design vocabulary

·         visualizations of design elements suitable for manipulation by BUI

·         set of architectural analysis tools to be integrated into the environment



·         an object-oriented database

·         a toolkit (for GUIs)

·         an event-based tool integration mechanism

·         an RPC (remote procedure call) mechanism (a type of IPC)


Typical Problems:

·         excessive code (size)

·         poor performance

·         need to modify external packages

·         need to re-invent existing functions

·         unnecessarily complicated tools

·         error-prone construction process


Mismatched Assumptions

·         Components:  tools, databases, filters, servers, etc

·         Connectors:  client-server protocols, pipes, RPC, message passing, events, etc

Four main categories of mismatch

1)       Assumptions about the nature of the components

·         Infrastructure- substrate

·         Control- which component controls the sequencing of computations

·         Data- kind of data being communicated

2)       Assumptions about the nature of connectors

·         Protocols- the patterns of interaction

·         Data- the kind of data communicated

3)       Assumptions about the global architectural structure (topology)

4)       Assumptions about the construction process

·         order of instantiation

·         building blocks


How do we solve the Problem

·         make our architectural assumptions explicit

·         orthogonal components – i.e. make them neutral with respect to some of the major issues of control, data models, etc (may take us away from a solution that is shaped like the problem)

·         techniques for bridging mismatches

·         architectural design guidance – styles, templates, patterns

o        narrowing the solution space for leverage


“A Rational Design Process: How and Why to Fake It  (Parnas, Clements)

II. Why will a software design “process” always be an idealization

-          users don’t know what they want, can’t tell us

-          even if we have requirements, not sufficient by themselves; process of discovery causing backtrack

-          humans can’t comprehend details

-          external change

-          human errors

-          preconceived design ideas, favorite idea

-          software co-development, pre-existing software

III.                 Why is a Description of a rational idealized process useful anyway?

-          Designers need guidance

-          Effort to be less chaotic

-          Transfer people, ideas, software from one project to another

-          Easier to measure progress

IV.                 What should the description tell us?

-          what product we should work on next

-          what criteria the product must satisfy

-          what kind of persons should do the work

-          what information they should use in their work

V.                   What is the rational design process?

-          Requirements Document

o        Why?

§         Record behavior as described by user

§         Avoid inconsistency/duplication

§         Basis for work estimates

§         Knowledge

§         Basis for planning

§         Constraints for future change

§         Arbiter

** Version of system – families of programs – some stay constant, some are variant

o        Incompleteness explicitly documented

o        reference document

o        Organization

§         System context

§         i/o (spec of value)

§         constraints

·         timing

·         accuracy

§         undesired events (obstacles)

-          Module Structure

o        Intellectual tools

§         Abstraction (information hiding)

§         Encapsulation (relates pieces, separates concerns)

§         Modularity (separation into pieces)

-          Interfaces

o        Functions, procedures, parameters

o        Results of programs

o        Constraints – timing and accuracy

o        Undesired events

-          Uses Hierarchy

-          Module Internal Structures

o        Design decisions

o        Submodules – internal data structures (pseudocode for non-high level languages)

-          Write Programs

-          Maintain