Software Architecture

• During System Specification

• the concern is “what”, or “who”

• there (should be) no consideration of design

• During Architecture

• The concern shifts to “how”

• On systems that this is done well:

• Better understanding of pieces/parts and wholes

• Expanded/extended & reorganized new system

• Maintainable

• Testable

• It is the bridge to the actual implementation

• It’s a combination of skill and art

• The Architecture can be different in different parts of the project, or between iterations of a project

The “Macro” View

Module/Subsystem Approach

• Dividing the system into understandable/implementable pieces

• “Black Box” view

• Each unit is a functional piece in and of itself

• File management

• Error handling

• Flight model

• Free agent pool

• The “ins” and “outs” are well defined

• In: filename, error number, number of frames, collection of players to add

• Out: boolean flags, movement of plane in 3-space, reference to modified collection

• This leads to assignment of each box to a programmer or division

• If there needs to be a change, just “swap out” the black box

• Yeah, right

• Remeber “Why Number 1”: Things Change

• If you anticipate change during your design phase, then yes it becomes much easier to make those changes

• A Subsystem is usually a set of modules joined by some common functionality

• On a high-level design, subsystem interconnections are shown

Advantages

• Forces a well defined explanation of part of the problem

• The answer (hopefully) becomes understandable

• Execute parallel development

• I do my part (keeping track of the ins and outs)

• you do yours (also keeping track of the ins and outs)

• We’ll meet in the middle and everything will fit together perfectly and on time

The “Micro” View

Abstraction

• A relevant subset of reality

• What part of <item> do you need to know about and implement

• There was talk several years ago about “Software I.C.s”

• In hardware, an I.C. is Integrated Circuit

• It’s a part that does a very particular thing

• They’re easy to make, their interface is well defined

• But the theory is flawed

• What about “Chair”

• The attributes we care about depend upon the application we are building

• Number of legs

• Does it swivel

• Texture of the seat (leather, plastic)

• Model number

• Where in this room is it?

• Breakability

• Reflectivity

• So how can we sell an “software I.C.” called a “chair”

• The Standard Template Library tackles this idea somewhat

• Implements Strings, Arrays, Linked Lists, etc.

• Key to Architecture is finding and defining the “Key Abstractions” upon which the system is build

• The “Bank/ATM” problem

• The Usual suspects:

• Customer

• Waiting Line

• Teller

• Account

• Movement manager

• The missing abstraction

• Transaction

Class Responsibilities

• Think of what an object (class) is supposed to do, not how it will do it

• This is designing for interface, instead of implementation

• What functionality is beyond the scope of this class?

• What functionality should be handled by another class?

• Many authors describe this as a “contract”

• (In actuality, this is often discussed in terms of “first person”)

• What am I supposed to do when?

• I’ll pass to you…

• Responsibility is the collection of:

• Calling convention

• What is passed as parameters

• What are return values

• The setting of pre and post conditions

• The internal execution

• The calling of other objects

Information Hiding

• Other classes see only the interface I allow them to see

• How I actually get my work done is irrelevant to them

• Encourage the use of abstract base classes

• The actual implementation is left to a derived class

• A user has no idea about the implementation details

• A lot of “negative press” in C++ because of “slowness”

• It adds a level of indirection to the call

• But it really encourages a better design

• Especially for “Reason Number 1: Change”

• Example Design Pattern: Bridge

• Hides the implementation details of the object

• A Container

• Has interface:

• AddItem

• DeleteItem

• GetItem

• MergeWithOtherContainer

• All containers derive from this interface, but implement the functionality in their own way

• Linked List

• Array

• Binary Tree

• In a “Bridge” it contains a reference to an object that actually does the “dirty work”

• It’s then possible for a Linked List to become an Array, if it makes sense to do so, but the world doesn’t know this has happened

Class Interactions

• How do classes relate to one another?

• Is-A

• Class is derived from another

• Heirarchy

• Extends or Modifies the functionality of the base class

• The Classic Example

• Shape

• Draw ()

• Ellipse, Circle

• Rectangle, Square

• Again, it works really well with the Abstract Base Class idea

• Warning beware of confusing with the next one, Has-A

• Has-A

• Class contains a whole object, or a reference to it

• Big class becomes a composite or aggregate

• For Example:

• Airplane

• Collection of Wings

• Collection of Engines

• Collection of Aerodynamic properties

• Warning beware of confusing with IS-A

• An airplane IS-NOT an Aerodynamic property, or bigger wing (i.e. IS-A)

• But the temptation is there

• Poor Example:

• GUIObject

• GUIFile

• GUIRect

• x, y, w, h

• Draw ()

• Extent ()

• Merge (GUIRect &rRef)

• GUIHotSpot

• MouseOver ()

• MouseEvent ()

• DoAction ()

• What’s wrong here?

• A HotSpot is not a natural extension of a Rectangle

• Should be, contains a reference to a Shape

• Now you can have hotspots in the Shape of circle, polygon, anything

• Uses-A

• Class knows about another classes existence in the system, or more intimately, it’s interface

• Another class passed as a parameter

• This class may actually use the class

• May pass the class on to another class

• Example:

• PlayerGenerationAlgorythym

• League

• GeneratePlayers (PGA &pgaRef)

• Calls another’s method

• Instantiates a temporary (or permanent)

• The most common interaction

• Can lead to coupling that is unbreakable

• Want to use someone’s line-break mechanism

• Need to include their gui header file

• Need to include their math header file

• Which leads to other includes, and on and on

Guidelines for Interactions

• Think of the interface to the object, and not its implementation

• Try to write interfaces that don’t depend on implementation details (i.e. pass abstract base classes as parameters)

• Think of the GUI example

• HotSpot cared about (albeit only for it’s coordinates) Rectangle’s implementation. What if the implementation changed?

• Instead of x,y,w,h it became Pt1 and Pt2

• Now HotSpot’s code will have to be rewritten as well

For your projects:

• Tempting to skip altogether and use “Uses-A”

• Think about only using an interface approach