*   Jalote Chapter 5 - Software Architecture

*   what is "software architecture"?

    one definition: (that Jalote references from
    a *software* architecture text):

    "The software architecture of a system is the
    structure OR STRUCTURES of the system which
    comprise
    *   software elements,
    *   the externally visible properties of those
        elements, and
    *   the relationships among them."

...hopefully, provides for USEFUL abstraction of
   the system;
    
*   since software architecture partitions
    a system into LOGICAL parts,
    ... there can be MULTIPLE architectural views
        of the same system;
	(more than one way to logically partition
	it)

    ... (and for different purposes, such different
        views may reveal different insights about
	the system)

*   why might a software project team create and
    document such architectural structure?
    *   UNDERSTANDING and COMMUNICATION
        ...within the team
        ...amongst other stakeholders as well
	   (that software project team,
	   and the users who'll use the system,
	   the clients who commissioned the system,
           
    *   may help with potential reuse of components

    *   may help in planning construction and evolution

    *   may allow for additional analysis...!

*   Architecture views
    *   a view consists of elements and relationships
        between them, and describes a structure

    *   the elements of a view depend on what the view
        seeks to highlight

    *   many types of views have been proposed;
        most belong to one of these 3 types:	
        *   module
	*   component and connector
	*   allocation

	...not unrelated!
	.. but they are different views of the SAME
	   system, each representing the same system;

*   module view -
    *   looking at a system as a collection
        of (static) code units -- they do
	not represent runtime entities

    *   elements in this view may be
        modules such as: class, package, function,
	procedure, trigger, etc.

    *  relationships in this view are code-based --
       part of, depends on, calls,
       generalization-specialization

*   component and connector view
    *   elements are run-time entities called components
    *   that is, a component is a unit that has identity
        in an executing system -- objects, processes,
        .exe, .dll

    *   connectors provide a means of interaction
        between components -- pipes, shared memory,
	sockets

*   allocation view
    *   focuses on how software units are allocated
        to resources like hardware, file systems,
	people

    *   i.e., specifies the relationship between	
        software elements and execution units
	in the environment

    *   exposes structural properties such as
        which process runs on which processor,
	which file resides where, etc.

*   note how different views may be necessary for
    different goals --
    may need an allocation view for certain kinds
       of performance analysis, may need a module
       view for project implementation planning,
       may need component and connector (C&C) view for
       both analysis and planning, etc.

*   Jalote notes that the C&C view is almost always
    done, and has become the primary view

*   C&C in a little more detail:
    *   two main elements: components and connectors

    *   components: computational elements or data stores
    *   connectors: means of interaction between
        components

    *   a C&C view defines the components,
        and which components are connected
	through which connector(s)

    *   describing runtime structure!

    *   a C&C view is typically a graph;
        often shown as a box-and-line drawing