2. Software Architecture Definition
The Software Architecture of a program or
computing system is the structure or structures of
the system, which comprises software elements,
the external visible properties of those elements
and the relationships among them.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 2
3. Where do views come from ?
A software architecture is multi-dimensional & complex
entity that cannot be described in a simple one-
dimensional fashion.
To communicate meaningfully about an architecture, we
must make clear which structure or structures we are
discussing at the moment - which view we are taking of
the architecture.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3
4. Architectural views – Ph.Kruchten
A view is a set of coherent architectural elements.
Programmers
- Software management
End user
- Functionality
- Vocabulary
Design Component
view view
Use case
Analysts/Testers
- Behavior view
Process Deployment
view view
System integrators System engineering
- Performance - System topology
- Scalability - Delivery and installation
- Throughput - Communication
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4
5. Architecture Documentation Challenges
How do you decide which architectural views to
document?
What information do you record about an architectural
view beyond the box-and-line diagram?
How do you specify an architectural element's
software interface? What information do you record?
How do you specify an element's behavior?
What notations are available for documenting a view,
an interface or behavior?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5
6. Architecture Description Languages
Requirements
UML
Software
Architecture
An ADL is a language that provides features for modelling a software
system’s conceptual architecture.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6
7. Architecture Structures
STATIC view : What is the structure of the system ?
What is the primary functional responsibility assigned to each structure?
What other software elements is a module allowed to use?
What other software does it actually use?
DYNAMIC view: What is the runtime behavior of the system ?
What are the major components ? How do they interact , communicate ?
What are the major shared data stores? Which parts of the system are
replicated? How does data flow or progress through the system?
What are the system states ?
What parts of the system can run in parallel and are concurrent ?
DEPLOYMENT view : Allocation Structures.
Relation with external elements
What processor does each software element execute on?
In what files is each element stored during development, testing, and
system building?
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 7
9. STATIC Views & Modules Structures
Module
Decomposition Class
Uses
Layered
Modules are units of implementation.
with functional responsibility
is a sub module of and uses - relations
generalisation -> re-use & incremental development
associated products: test plan, interface specification,
code …etc.
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9
10. Module Structures in UML
Represented stereotyped packages, classes and interfaces
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10
12. Component Diagrams
A component is a modular, autonomous unit with well
defined interfaces.
They are particularly well suited for initial architectural
modeling.
Static View
Dynamic View
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN 12
13. DYNAMIC Views & Component-Connector
Component – Connector Structures
Communication
Shared data
Processes
Concurrency Client -
Server
Components are runtime units
computational units
parallelism, identify resource contention
Connectors are interaction mechanism among
components
communication & synchronisation mechanism
interaction, data flow (persistence).
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13
15. Interaction diagrams
Interaction diagrams show the communication behavior
between parts of the system
Four types of Interaction diagrams
Sequence diagram
Emphasis on the sequence of communications between parts
Communication diagram
Emphasis on structure and the communication paths between
parts
Timing diagram
Emphasis on change in state over time
Interaction overview diagram
Emphasis on flow of control between interactions
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN 15
19. DEPLOYMENT Views & Allocation structures
Allocation
Work
Deployment
Assignment
Implementation
Allocation structures show relations in the
external environment:
assignment to processors and communication
resources
mapping to file structures and build systems
who does the work
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19
21. Example WWW Client Server
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21
22. HTTP Client Module
UI manager :
Responsible for the look and feel of the UI (e.g., web browser)
Presentation manager
Delegates document types to viewers
external: QuickTime movies, MP3 audio, etc.
internal: HTML, GIFs to UI manager
Scenario:
UI manager captures user’s requests for URL and passes to
Access manager
Access manager determines if URL has been cached; if not, it
initiates retrieval through Protocol and Stream managers
Response stream sent to presentation manager for
appropriate display
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 22
23. HTTP Server Module
Hypertext Transfer Protocol (HTTP) server :
Receives URL request and passes that the Path resolver, which
determines the file location for the document (assuming local)
Checks the access list to see if access is permitted (may initiate
password authentication session) and then gets the document
from the file system and writes it to the output stream
Common Gateway Interface (CGI)
Special document type that allows customized access to other
data or programs
Also writes to output stream
HTML stream is sent to the client by the HTTP server
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 23
24. Common Gateway Interface (CGI)
HTTP server : transparent access to the file system
by:
Handling access directly for known types
Passing unknown types to a “proxy” server known as Common
Gateway Interface (CGI)
CGI
Most information returned by the server is “static”
CGI provides for the dynamic generation of responses e.g.
“looking something up in a database”
Virtual documents or dynamic documents
CGI Scripts: C, C++, Perl, Visual Basic, AppleScript, PHP,
Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 24
Editor's Notes
The neurologist, the orthopedist, the hematologist, and the dermatologist all have a different view of the structure of a human body. Ophthalmologists, cardiologists, and podiatrists concentrate on subsystems. The kinesiology's and psychiatrist are concerned with different aspects of the entire arrangement's behavior. Although these views are pictured differently and have very different properties, all are inherently related: Together they describe the architecture of the human body.So it is with software. Modern systems are more than complex enough to make it difficult to grasp them all at once. Instead, we restrict our attention at any one moment to one (or a small number) of the software system's structures. To communicate meaningfully about an architecture, we must make clear which structure or structures we are discussing at the moment-which view we are taking of the architecture.We will be using the related terms structure and view when discussing architecture representation. A view is a representation of a coherent set of architectural elements, as written by and read by system stakeholders. It consists of a representation of a set of elements and the relations among them. A structure is the set of elements itself, as they exist in software or hardware. For example, a module structure is the set of the system's modules and their organization. A module view is the representation of that structure, as documented by and used by some system stakeholders. These terms are often used interchangeably, but we will adhere to these definitions.Architectural structures can by and large be divided into three groups, depending on the broad nature of the elements they show. Module structures. Here the elements are modules, which are units of implementation. Modules represent a code-based way of considering the system. They are assigned areas of functional responsibility. There is less emphasis on how the resulting software manifests itself at runtime. Module structures allow us to answer questions such as What is the primary functional responsibility assigned to each module? What other software elements is a module allowed to use? What other software does it actually use? What modules are related to other modules by generalization or specialization (i.e., inheritance) relationships? Component-and-connector structures. Here the elements are runtime components (which are the principal units of computation) and connectors (which are the communication vehicles among components). Component-and-connector structures help answer questions such as What are the major executing components and how do they interact? What are the major shared data stores? Which parts of the system are replicated? How does data progress through the system? What parts of the system can run in parallel? How can the system's structure change as it executes? Allocation structures . Allocation structures show the relationship between the software elements and the elements in one or more external environments in which the software is created and executed. They answer questions such as What processor does each software element execute on? In what files is each element stored during development, testing, and system building? What is the assignment of software elements to development teams? These three structures correspond to the three broad types of decision that architectural design involves: How is the system to be structured as a set of code units (modules)?How is the system to be structured as a set of elements that have runtime behavior (components) and interactions (connectors)? How is the system to relate to non software structures in its environment (i.e., CPUs, file systems, networks, development teams, etc.)?
Component diagrams are particularly useful with larger teams. Your initial architectural modeling efforts during cycle 0 should focus on identifying the initial architectural landscape for your system. UML component diagrams are great for doing this as they enable you to model the high-level software components, and more importantly the interfaces to those components. Once the interfaces are defined, and agreed to by your team, it makes it much easier to organize the development effort between sub teams. You will discover the need to evolve the interfaces to reflect new requirements or changes to your design as your project progresses, changes that need to be negotiated between the sub teams and then implemented appropriately.
A component is a principal unit of runtime interaction or data storage; a connector is an interaction mechanism among components. For example, in a pipe-and-filter view, filters are components, and pipes are the connectors. In a shared-data view, the data repository and the accessory are the components, and the access mechanisms are the connectors. In a client-server view, the components are clients and servers, and the connectors are the protocol mechanisms by which they interact.
Deployment diagrams are mostly (and almost exclusively) used for distributed applications. These diagrams show on which machines which parts of the software is running (a physical mapping of software to hardware infrastructure). Also communication links between different computers are indicated. A deployment diagram node can represent any computational unit, i.e. any device having some information processing capability, ranging from a simple temperature sensor to a regular computer.
The user interface (UI) manager handles the look-and-feel of the client's user interface. However, given the open-ended set of resources that a WWW system can handle, another element, the presentation manager, can delegate information display to external programs (viewers) to view resources known by the system but that the UI manager does not directly support. For example, most Web viewers use an external program to view PostScript or .pdf files. This delegation is a compromise between the competing desires of user interface integration (which provides for a consistent look-and-feel and hence better usability) and extensibility. The UI manager captures a user's request for information retrieval in the form of a 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 UI or an external viewer. If it is not cached, the protocol manager determines the type of request and invokes the appropriate protocol suite to service it. The client stream manager uses this protocol for communicating the request to the server. Once it 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.) to help it map document types to external viewers. The HTTP server ensures transparent access to the file system-the source of the documents that the Web exists to transfer. It does this either by handling the access directly (for known resource types) or through a proxy known as common gateway interface (CGI). CGI handles resource types that a native server cannot handle and handles extension of server functionality, as will be discussed next. Before these extensions, the available WWW servers implemented a subset of defined HTTP requests, which allowed for the retrieval of documents, the retrieval of document meta-information, and server-side program execution via CGI. When a request is received by the server stream manager, its type 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 for access. It might initiate a password authentication session with the client to permit access to secured data. Assuming authentication, it accesses the file system (which is outside the server boundary) and writes the requested information to the output stream. If a program is to be executed, a process is made available (either new or polled) through CGI and the program is executed, with the output written by the server stream manager back to the client. In either case, CGI is one of the primary means by which servers provide extensibility, which is one of the most important requirements driving the evolution of Web software. CGI became such an important aspect of Web-based applications that we now discuss this topic at greater length.
