2D1363, Mjukvarukonstruktion, 8
poäng
Aktuell kursomgång: period 2-4
06/07
Kursledare: Rand Waltzman
Datorpostadress(er): rand@nada.kth.se
Overall Architecture Description
If you had to describe
your system to a technical manager and you had only one slide to do so, how
would you describe it? Typically, this would involve a box-and-line diagram of
the system, together with some prose stating something to the effect of,
"The system is divided up into x major components, as depicted in the
diagram." This high-level box-and-line diagram is what we will refer to as
the overall architecture of the system and it represents a decomposition
of the system into units, which we could call components, modules,
or subsystems. The lines in the diagram suggest communication paths
between the units, and those can be realized by
procedure calls, socket communication, accessing of global data or read/writes
to a file. In any event, there is some meaning associated to what goes on
inside a box and some meaning for what a line connecting two units. It is that
meaning which must be clear in your high-level decomposition. As an example,
here is an architectural representation of the client-server organization of a
vanilla-flavored WWW system:
But the
identification of the units in the architecture by means of a static
box-and-line diagram is only one part of the picture. It is also important to
have some information on the dynamic behavior of the system, or how the
communication/connections work and when. You will do this by providing
interaction diagrams that show how the various components interact under normal
usages (scenarios) over time in Section 5.4 of your Design Document.
In this section, I want you to provide a
high-level decomposition of your architecture in the form of a box-and-line
diagram accompanied by a natural language description of the dynamic behavior.
A sample of the kind of description I am looking for is the following used to
describe the architecture in above figure:
The Web is a distributed hypermedia system organized as a loosely
connected set of clients and servers that share a common set of communication
protocols and markup languages. Servers make Internet resources available to a
community of clients that speak a common protocol. In addition, WWW clients
typically understand a number of other protocols. The above figure depicts the WWW software
architecture. In this example, we only consider the connection between a WWW
client and WWW server, even though it is possible for a WWW client to natively
speak to other IISs (Gopher, FTP, etc.).
WWW clients
provide a User Interface Manager. This manager can be graphical or character
based. The User Interface Manager captures a user's request for information
retrieval in the form of a Uniform Resource Locator (URL) and passes the
information to the Access Manager. The Access Manager determines if the
requested URL exists in cache and also interprets history-based navigation,
e.g. `back'. If the file is cached, it is retrieved from the Cache Manager and
passed to the Presentation Manager for display to either the User Interface or
an external viewer. If the file is not cached, the Protocol Manager determines
the type of request and invokes the appropriate protocol suite to service the
request. This protocol is used by the client Stream Manager for communicating
the request to the server. Once the client Stream Manager receives a response
from the server in the form of a document, this information is passed to the
Presentation Manager for appropriate display. The Presentation Manager consults
a static View Control configuration file (mimerc, mailcap, etc.) that aids in the mapping of document types
to external viewers.
Currently, the
WWW servers available implement a subset of defined HTTP requests. This subset
allows for: the retrieval of documents; the retrieval of document
meta-information; and server-side program execution via the Common Gateway
Interface (CGI).
When a request
is received by the server Stream Manager, the type of request is determined and
the path of the URL is resolved via the Path Resolver. The HTTP Server consults
an Access List to determine if the requesting client is authorized to access
the data pointed to by the URL. The HTTP Server might initiate a password
authentication session with the client to permit access to secured data.
Assuming authentication succeeds, the HTTP Server accesses the File System
(which is outside the WWW Server boundary) and writes the requested information
to stream. If a program is to be executed, a process is made available (either
new or polled) through the CGI and the program is executed, with the output
written by the server Stream Manager back to the WWW Client.
Upp till Nadas kurser.
Sidansvarig: <rand@nada.kth.se>
Tekniskt stöd: <webmaster@nada.kth.se>