CS 458 - Week 10 Lecture 1 - 2016-10-25

*   Jalote Chapter 5 - *SOFTWARE* architecture!!

*   in a software system,
    composed of interacting subsystems,

    we care about IDENTIFYING...
    *   those subsystems,
    *   and the INTERFACES between those subsystems,
    *   and the RULES for INTERACTION between those subsystems

    ^ that's what SOFTWARE ARCHITECTURE aims to do;

    *   software architecture design can include:
        *   choosing middleware
        *   choosing a back-end DBMS or data store
        *   choosing server(s)
        *   choosing security components

*   Jalote Chapter 5 includes:
    *   ROLES of a sw-architectural description in a SW project 
    *   that a system can be described using
        MULTIPLE architectural views
    *   some CLASSIC sw-architecture views
    *   a bit about how the sw architecture of a system
        can be evaluated (and suggest future
	system performance)

*   NOTE/REMEMBER -
    there CAN be MULTIPLE sw-architectural views of 
    the SAME software!

    *   a VIEW consists of ELEMENTS,
        and RELATIONSHIPS between those elements,
	and DESCRIBES a STRUCTURE

	*   what elements?
	    depends on what that view is intended to highlight!

            different views expose different properties;
	    (and hide others, depending on the purpose
	    of the view)

    *   MANY views have been proposed --
        most belong to one of these three types:

	*   module
	*   component and connector
	*   allocation

        (these are categories of views, really...)

*   Module view category -
    *   view the system as a collection of *code*
        units (i.e., not representing runtime
	entities)

    *   elements in a module view are, well, modules
        (functions, tests, methods, classes, procedures,
        packages, etc.)

    *   relationships between the module elements
        tend to be code-based --
	part of, depends on, calls,
	   generalization/specialization, etc.

*   Component and Connector view category -
    *   elements in these views are *run-time* entities
        called components

        *   a component is a unit that has identity in
	    executing -- e.g., objects, processes, .exe, .dll, etc.

    *   connectors provide means of INTERACTION between the
        components -- pipes, shared memory, sockets, etc.

*   Allocation view category -
    *   focus on how software units are allocated to
        resources such as hardware, file systems, even people...!

    *   specifies the relationship between software
        elements and execution units in the runtime environment

    *   can expose structural properties such as which process
        runs on which processor, which files reside where,
	etc.

*   different systems may need different arch views depending
    on the needs of the project;

    BUT: amongst the different arch views of a single system,
    at least one component-and-connector view tends to be
    included, and is even sometimes considered a primary
    architectural view;

    *   after this point, Chapter 5 focuses mostly
        on different component-and-connector views;

	(module views are covered more in Chapter 6,
	high-level software design...)

*   MORE about the category of
    Component and Connector (C&C)

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

    *   describe a run-time structure;

    *   a C&C view tends to be a graph,
        often shown as a box-and-line drawing;

*   components
    *   units of computation or data stores
    *   have a name, rep'ing its role, and provides its identity
    *   components use connectors to communicate with other
        components
    *   shapes tend to be used,
        where the shape is based on the type of component --

	classic examples:
	*   oval for a client
	*   rectangle for a server
	*   cylinder for a database
	*   rounded-off rectangle for an application

*   connectors
    *   interaction btwn components happens through
        connectors

    *   a connector may be provided by the runtime environment;
        (e.g., a procedure call)

	OR they may be more complex
        (http, tcp/ip, ports, <-- and the software needed to support those

    *   need NOT be binary; consider a broadcas bus!

    *   connectors have a name and a type
    *   often represented as a protocol!

    *   better to use DIFFERENT notations for different
        types of connectors...!

*   SEE the example of the survey system in Chapter 5 --

    good example of how choice of sw architecture
    can affect a system!

*   there happen to be a whole set of
    C&C *architectural styles*

        ^ defines a family of archs that satisfy
	  the constraints of that style

    *   provide IDEAS for creating/determining
        suitable C&C views of a system...

    *   pipe-and-filter
    *   shared-data
    *   client-server
    *   publish-subscribe
    *   peer-to-peer, or object-oriented style
    *   communicating processes

    *   pipe-and-filter
        *   well suited for data transformations!
	*   component: filter <-- transforms and passes along data; independent
	*   connector: pipe <-- a unidirectional channel

        *   there's more to a pipe than might initially
	    meet the eye...!