Software architecture: import/export
P.J. Drongowski
14 October 2004

Software architecture

  * Deals with the overall structure and communication behavior
    of a system
  * The interfaces between modules (software components) are agreements
    about expected behavior and how the modules will communicate
  * Correctness depends upon upholding these agreements between modules
  * Well-specified, controlled interfaces are good
    + Intended behavior is clear and can be tested and validated
    + Modules only communicate through these interfaces -- no "sneaky"
      communications or data sharing
    + Algorithms and data structures are hidden
  * Poorly specified, uncontrolled interfaces are bad
    + A module may not behave as intended
    + Modules communications may be "sneaky" and expose internal
      algorithms and data structures
    + Such systems are hard to maintain, difficult to extend and evolve
    + The architecture literally degrades over time such that future
      development is impeded
    + Example: A poorly architected PBX system

Principle: Uniformity of communication and construction

  * Example: Regularity/uniformity of communication in robot parade assignment
  * Each subpart is a class
    + Non-leaf parts
      - Have public constructor and draw_me method functions
      - Create instances of their subparts
      - draw_me calls the draw_me function of each subpart
    + Leaf parts
      - Have public constructor and draw_me method functions
      - Do not have subparts
      - Only draw geometric primitives

Ideal situation - Full, explicit control of module interfaces

  * Explicit import / export model
  * Export - "Module M exports function F to module N"
  * Import - "Module N imports function F from module M"
  * Explicit import / export specs can be checked automatically

C++ is the kindly, respectable Dr. Jekyll (Mario)

  * Classes provide interface control
  * A using module must at least include the interface declaration (.h file)
  * Programmer can hide functions and data members, if necessary
  * C++ provides features to selectively relax controls (e.g., friends)

C (or C-style coding) is the malevalent Mr. Hyde (Wario)

  * Programmer can define variables, data structures and functions
    outside of a class
  * These variables, etc. are visible (by default!) to any other
    module in the system
  * These entities are called "global" because they are visible
    everywhere in the system
  * All a using module needs to do is to:
    + Know the name of the variable, etc.
    + Declare the variable, etc. as "extern" and you can access it!
      No questions asked!
  * Consider these two scenarios
    + The "midnight cowboy"
      - Reads your code overnight
      - Decides to access your module's internal data structures
      - Uses "extern" to access those data structures
    + Private agreements between two programmers to "make things run better"
      - They decide to build a private interface
      - If tens or hundreds of developers act in such an undisciplined way,
        chaos reigns and the architecture degrades