2 Flashcards
Describe the role of an architect, analyst, and network administrator. What kind of
architectural reasoning do they perform in their job?
Architect
Role
Responsible for the development of the architecture and its documentation, i.e. make sure appropriate patterns are used,…
Architectural reasoning
* Negotiating and making trade-offs among competing requirements and design approaches, i.e. reconcile the different stakeholders’ wishes
* A vessel for recording design decisions, i.e. explain and document why certain decisions have been made
* Providing evidence that the architecture satisfies its requirements
Analyst
Role
Responsible for analyzing the architecture to ensure that it meets critical quality attribute requirements.
Often specialized: performance, safety (e.g. in health care) and security analysts.
Architectural reasoning
Analyzing satisfaction of quality attribute requirements based on a system’s architecture
Network administrator
Role
Responsible for the maintenance and oversight of computer hardware and software in a computer network. This may include the deployment, configuration, maintenance, and monitoring of network components.
Architectural reasoning
* Determining network loads during various usage scenarios
* Determining appropriate network security zoning
Which architectural structures enable this reasoning?
- Module structures:
Show how a system is to be structured as a set of code or data units (modules) that have to be constructed or procured - Component-and-connector structures:
Show how the system is to be structured as a set of elements that have runtime behavior (components) and interactions (connectors) - Allocation structures:
Show how the system will relate to non-software structures in its environment (e.g. CPUs, file systems, networks, development teams,…)
What is the difference between an architectural structure and an architectural view?
An architectural structure are the elements held together by relations that support reasoning about the system’s properties. These elements are the actual elements as they exist in software and hardware, e.g. a module structure is the set of the system’s modules and their organization.
An architectural view is a representation of an architectural structure according to a template in a chosen notation and used by some system stakeholders. It is a representation of a coherent set of architectural elements and their relations, as written and read by system stakeholders, e.g. a module view is the representation of the module structure as documented by and used by some system stakeholders.
Is there always a one-to-one mapping between the modules in a module view and the components in a component-and-connector view?
No. Mappings between the elements of structures are many-to-many in general!
Example:
…
The depicted client-server system consists of two modules, but eleven components.
Another example could be having 1 server as a component, but this server is modularized, i.e., its functionalities are divided over multiple submodules.
What kind of view could support a maintainer in a change impact analysis?
A module view that shows the dependencies among modules indicates which modules might be impacted when another module that they depend on is modified (e.g., Dependency Structure Matrix).
This is usable in a change impact analysis.
Give an example of a typical use for a module view of your choosing and an example of a typical use for a component-and-connector view of your choosing.
Module view
* Construction
- Blueprint for the source code:
Using views that map modules closely to physical structures such as directories,
classes,…
- Planning incremental development:
Using views that show dependencies among modules, e.g., developing the modules with the least dependencies first,…
- Defining work assignments, implementation schedules, and budget estimates
* Analysis
- Change-impact analysis:
Using views that show dependencies among modules, i.e., which modules are impacted if a module they depend on is modified
- Requirements traceability analysis:
As modules partition a system, it should be possible to determine which functional
requirements are met by which module responsibilities
* Communication
- Communicating the functionality of a system, the structure of its code base and the data it manages:
Using views at various levels of granularity of module decomposition - provided they are up-to-date which is often not the case in practice (co-evolution problems:
implementation and documentation evolve separately)
Component-and-connector view
* Communication:
C&C views help answer questions such as
o Which parts of the system are replicated?
o Which parts of the system can run in parallel?
o Can the system’s structure change as it executes and, if so, how?
(e.g., clients going online/offline, failover backup server,…)
o How does data progress through the system?
o What are the major executing components and how do they interact at runtime?
o What are the major shared data stores?
* Analysis:
C&C views are crucial to reasoning about the system’s runtime properties such as performance, security, availability,…
Give two example properties documented about the elements in a module view and in a component-and-connector view respectively.
Documented properties in Module view
* Name
o May suggest something about the module’s role (e.g. account_mgr)
o May reflect its position in the decomposition hierarchy (e.g. A.B.C)
* Mapping to source code units
o e.g. module Account: IAccount.java, AccountImpl.java, AccountOrmMapping.xml,…
* Visibility of interfaces
o When a module has submodules, some interfaces of the submodules may have internal
purposes. The interfaces are used only by the submodules within the enclosing parent.
Encapsulation and selective exposition are possible.
Documented properties in Component-and-connector view
* Reliability
o What is the likelihood of failure for a given component or connector?
* Performance
o What kinds of response times will the component provide under what loads?
o What kinds of latencies and throughputs can be expected for a given connector?
* Resource requirements.
o What are the processing and storage needs of a component or a connector?
* Functionality
o What functions does an element perform?
* Security
o Does a component or a connector enforce or provide security features, such as
encryptions, audit trails, or authentication?
* Concurrency
o Does this component execute as a separate process or thread (Asynchronous or
synchronous communication,…)
* Tier
o For a tiered topology, what tier does the component reside in?
This property helps to define the build and deployment procedures, as well as platform requirements for each tier.
It is clear that the properties that are documented about are very different in both views. In a module view documentation is about static properties while in a component-and-connector view documentation is about dynamic (runtime) properties.
Explain the difference between complete encapsulation and selective exposition of submodule interfaces using an example view.
a) In this module view we see complete encapsulation: Module C provides its own interface, hiding the interfaces of modules A and B. All interfaces of C’s submodules A and B have internal purposes and can only be used by other submodules within the enclosing parent.
b) In this module view we see selective exposition: Module C exposes a subset of the interfaces of modules A and B as its interface. The other interfaces have internal purposes and can only be used by other submodules within the enclosing parent.
For example, an Account module that only makes certain interface functionalities publicly available while others are only meant for internal use in the Account module itself and shouldn’t be used directly from another (external) module.
What is depicted in the columns, rows and cells of a dependency structure matrix view?
A Dependency Structure Matrix is a type of module view notation:
…
- Rows and columns contain the modules where the column heading defines the module that you’re using and the row heading the modules that are used by other modules
- If a cell (i,j) contains a 1, the module in column j uses/depends on the module in row i. If a cell contains a 0, the module in column j does not depend on the module in row i.
Sometimes higher values than 1 are used in which case the value used represents the strength of the dependency. A higher value means the module is more heavily used, so the dependency is stronger. - In case of the Layer Pattern we expect a triangular matrix if the modules are sorted from high-level to low-level modules because of the unidirectional design of the pattern.
What is the difference between a “rich” and a “simple” connector notation in component and connector views?
A “rich” connector notation means the connector is represented as a component itself, e.g., a PublishSubscribe event bus is represented as a component which is connected to the “real” components using that connector.
A “simple” connector simply connects the ports of the “real” components with a line and maybe adds a stereotype to further explain the type of connection it is.
Most of the time it’s better to use a “simple” connector to avoid having a mixture of entities of different granularity and thus having a clearer design. Otherwise you might get a mixture of software system elements (Account Server,…) and infrastructure elements (Publish-Subscribe event bus).
Can you enumerate three different types of connectors from the example views?
- Client-server connectors:
Allow a set of concurrent clients to retrieve data synchronously via service requests. A variant of the client-server style supporting transparent failover to a backup server is possible. - Database access connectors:
Support transactional, authenticated access for reading, writing, and monitoring the database - Publish-subscribe connectors:
Support asynchronous event announcement and notification (over an event bus)
Give an example of how architecture can influence an organization’s business goals.
The architecture can provide opportunities for the efficient production and deployment of similar systems, and the organization may adjust its goals to take advantage of its newfound expertise to plumb the market.
Example:
An architecture that was developed has a lot of interesting variation points that allow a company to create multiple software product lines, i.e. a PRO version, an enterprise version,…
