64
administrator or end user to modify a system, but this is a common occurrence. In Figure 4.4
, the
modification is to be made by the developer.
Stimulus.
This portion specifies the changes to be made. A change can be the addition of a function,
the modification of an existing function, or the deletion of a function. It can also be made to the
qualities of the system—making it more responsive, increasing its availability, and so forth. The
capacity of the system may also change. Increasing the number of simultaneous users is a frequent
requirement. In our example, the stimulus is a request to make a modification, which can be to the
function, quality, or capacity.
Variation is a concept associated with software product lines (see Chapter 14
). When considering
variation, a factor is the number of times a given variation must be specified. One that must be made
frequently will impose a more stringent requirement on the response measures than one that is made
only sporadically.
Artifact.
This portion specifies what is to be changed—the functionality of a system, its platform, its
user interface, its environment, or another system with which it interoperates. In Figure 4.4
, the
modification is to the user interface.
Environment.
This portion specifies when the change can be made—design time, compile time, build
time, initiation time, or runtime. In our example, the modification is to occur at design time.
Response.
Whoever makes the change must understand how to make it, and then make it, test it
and deploy it. In our example, the modification is made with no side effects.
Response measure.
All of the possible responses take time and cost money, and so time and cost
are the most desirable measures. Time is not always possible to predict, however, and so less ideal
measures are frequently used, such as the extent of the change (number of modules affected). In
our example, the time to perform the modification should be less than three hours.
Table 4.2
presents the possible values for each portion of a modifiability scenario.
Table 4.2. Modifiability General Scenario Generation
Portion of
Scenario
Possible Values
Source
End user, developer, system administrator
Stimulus
Wishes to add/delete/modify/vary functionality, quality attribute, capacity
Artifact
System user interface, platform, environment; system that interoperates with target system
Environment At runtime, compile time, build time, design time
Response
Locates places in architecture to be modified; makes modification without affecting other
functionality; tests modification; deploys modification
Response
Measure
Cost in terms of number of elements affected, effort, money; extent to which this affects
other functions or quality attributes
PERFORMANCE
Performance is about timing. Events (interrupts, messages, requests from users, or the passage of time)
occur, and the system must respond to them. There are a variety of characterizations of event arrival and
the response but basically performance is concerned with how long it takes the system to respond when
an event occurs.
One of the things that make performance complicated is the number of event sources and arrival
patterns. Events can arrive from user requests, from other systems, or from within the system. A Web-
based financial services system gets events from its users (possibly numbering in the tens or hundreds of
thousands). An engine control system gets its requests from the passage of time and must control both
the firing of the ignition when a cylinder is in the correct position and the mixture of the fuel to maximize
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
94 / 463
41
power and minimize pollution.
For the Web-based financial system, the response might be the number of transactions that can be
processed in a minute. For the engine control system, the response might be the variation in the firing
time. In each case, the pattern of events arriving and the pattern of responses can be characterized, and
this characterization forms the language with which to construct general performance scenarios.
A performance scenario begins with a request for some service arriving at the system. Satisfying the
request requires resources to be consumed. While this is happening the system may be simultaneously
servicing other requests.
An arrival pattern for events may be characterized as either periodic or stochastic. For example, a periodic
event may arrive every 10 milliseconds. Periodic event arrival is most often seen in real-time systems.
Stochastic arrival means that events arrive according to some probabilistic distribution. Events can also
arrive sporadically, that is, according to a pattern not capturable by either periodic or stochastic
characterizations.
Multiple users or other loading factors can be modeled by varying the arrival pattern for events. In other
words, from the point of view of system performance, it does not matter whether one user submits 20
requests in a period of time or whether two users each submit 10. What matters is the arrival pattern at
the server and dependencies within the requests.
The response of the system to a stimulus can be characterized by latency (the time between the arrival of
the stimulus and the system's response to it), deadlines in processing (in the engine controller, for
example, the fuel should ignite when the cylinder is in a particular position, thus introducing a processing
deadline), the throughput of the system (e.g., the number of transactions the system can process in a
second), the jitter of the response (the variation in latency), the number of events not processed because
the system was too busy to respond, and the data that was lost because the system was too busy.
Notice that this formulation does not consider whether the system is networked or standalone. Nor does it
(yet) consider the configuration of the system or the consumption of resources. These issues are
dependent on architectural solutions, which we will discuss in Chapter 5
.
Performance General Scenarios
From these considerations we can see the portions of the performance general scenario, an example of
which is shown in Figure 4.5
: "Users initiate 1,000 transactions per minute stochastically under normal
operations, and these transactions are processed with an average latency of two seconds."
Figure 4.5. Sample performance scenario
Source of stimulus.
The stimuli arrive either from external (possibly multiple) or internal sources. In
our example, the source of the stimulus is a collection of users.
Stimulus.
The stimuli are the event arrivals. The arrival pattern can be characterized as periodic,
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
95 / 463
60
stochastic, or sporadic. In our example, the stimulus is the stochastic initiation of 1,000 transactions
per minute.
Artifact.
The artifact is always the system's services, as it is in our example.
Environment.
The system can be in various operational modes, such as normal, emergency, or
overload. In our example, the system is in normal mode.
Response.
The system must process the arriving events. This may cause a change in the system
environment (e.g., from normal to overload mode). In our example, the transactions are processed.
Response measure.
The response measures are the time it takes to process the arriving events
(latency or a deadline by which the event must be processed), the variation in this time (jitter), the
number of events that can be processed within a particular time interval (throughput), or a
characterization of the events that cannot be processed (miss rate, data loss). In our example, the
transactions should be processed with an average latency of two seconds.
Table 4.3
gives elements of the general scenarios that characterize performance.
Table 4.3. Performance General Scenario Generation
Portion of Scenario
Possible Values
Source
One of a number of independent sources, possibly from within system
Stimulus
Periodic events arrive; sporadic events arrive; stochastic events arrive
Artifact
System
Environment
Normal mode; overload mode
Response
Processes stimuli; changes level of service
Response Measure
Latency, deadline, throughput, jitter, miss rate, data loss
For most of the history of software engineering, performance has been the driving factor in system
architecture. As such, it has frequently compromised the achievement of all other qualities. As the
price/performance ratio of hardware plummets and the cost of developing software rises, other qualities
have emerged as important competitors to performance.
SECURITY
Security is a measure of the system's ability to resist unauthorized usage while still providing its services
to legitimate users. An attempt to breach security is called an attack
[1]
and can take a number of forms. It
may be an unauthorized attempt to access data or services or to modify data, or it may be intended to
deny services to legitimate users.
[1]
Some security experts use "threat" interchangeably with "attack."
Attacks, often occasions for wide media coverage, may range from theft of money by electronic transfer to
modification of sensitive data, from theft of credit card numbers to destruction of files on computer
systems, or to denial-of-service attacks carried out by worms or viruses. Still, the elements of a security
general scenario are the same as the elements of our other general scenarios—a stimulus and its source,
an environment, the target under attack, the desired response of the system, and the measure of this
response.
Security can be characterized as a system providing nonrepudiation, confidentiality, integrity, assurance,
availability, and auditing. For each term, we provide a definition and an example.
1. Nonrepudiation is the property that a transaction (access to or modification of data or services)
cannot be denied by any of the parties to it. This means you cannot deny that you ordered that item
over the Internet if, in fact, you did.
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
96 / 463
41
2. Confidentiality is the property that data or services are protected from unauthorized access. This
means that a hacker cannot access your income tax returns on a government computer.
3. Integrity is the property that data or services are being delivered as intended. This means that your
grade has not been changed since your instructor assigned it.
4. Assurance is the property that the parties to a transaction are who they purport to be. This means
that, when a customer sends a credit card number to an Internet merchant, the merchant is who the
customer thinks they are.
5. Availability is the property that the system will be available for legitimate use. This means that a
denial-of-service attack won't prevent your ordering
this
book.
6. Auditing is the property that the system tracks activities within it at levels sufficient to reconstruct
them. This means that, if you transfer money out of one account to another account, in Switzerland,
the system will maintain a record of that transfer.
Each of these security categories gives rise to a collection of general scenarios.
Security General Scenarios
The portions of a security general scenario are given below. Figure 4.6
presents an example. A correctly
identified individual tries to modify system data from an external site; system maintains an audit trail and
the correct data is restored within one day.
Source of stimulus.
The source of the attack may be either a human or another system. It may have
been previously identified (either correctly or incorrectly) or may be currently unknown. If the source
of the attack is highly motivated (say politically motivated), then defensive measures such as "We
know who you are and will prosecute you" are not likely to be effective; in such cases the motivation
of the user may be important. If the source has access to vast resources (such as a government),
then defensive measures are very difficult. The attack itself is unauthorized access, modification, or
denial of service.
The difficulty with security is allowing access to legitimate users and determining legitimacy. If the
only goal were to prevent access to a system, disallowing all access would be an effective defensive
measure.
Figure 4.6. Sample security scenario
Stimulus.
The stimulus is an attack or an attempt to break security. We characterize this as an
unauthorized person or system trying to display information, change and/or delete information,
access services of the system, or reduce availability of system services. In Figure 4.6
, the stimulus is
an attempt to modify data.
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
97 / 463
59
Artifact.
The target of the attack can be either the services of the system or the data within it. In our
example, the target is data within the system.
Environment.
The attack can come when the system is either online or offline, either connected to or
disconnected from a network, either behind a firewall or open to the network.
Response.
Using services without authorization or preventing legitimate users from using services is
a different goal from seeing sensitive data or modifying it. Thus, the system must authorize legitimate
users and grant them access to data and services, at the same time rejecting unauthorized users,
denying them access, and reporting unauthorized access. Not only does the system need to provide
access to legitimate users, but it needs to support the granting or withdrawing of access. One
technique to prevent attacks is to cause fear of punishment by maintaining an audit trail of
modifications or attempted accesses. An audit trail is also useful in correcting from a successful
attack. In Figure 4.6
, an audit trail is maintained.
Response measure.
Measures of a system's response include the difficulty of mounting various
attacks and the difficulty of recovering from and surviving attacks. In our example, the audit trail
allows the accounts from which money was embezzled to be restored to their original state. Of
course, the embezzler still has the money, and he must be tracked down and the money regained,
but this is outside of the realm of the computer system.
Table 4.4
shows the security general scenario generation table.
Table 4.4. Security General Scenario Generation
Portion of
Scenario
Possible Values
Source
Individual or system that is
correctly identified, identified incorrectly, of unknown identity
who is
internal/external, authorized/not authorized
with access to
limited resources, vast resources
Stimulus
Tries to
display data, change/delete data, access system services, reduce availability to
system services
Artifact
System services; data within system
Environment Either
online or offline, connected or disconnected, firewalled or open
Response
Authenticates user; hides identity of the user; blocks access to data and/or services;
allows access to data and/or services; grants or withdraws permission to access data
and/or services; records access/modifications or attempts to access/modify data/services
by identity; stores data in an unreadable format; recognizes an unexplainable high demand
for services, and informs a user or another system, and restricts availability of services
Response
Measure
Time/effort/resources required to circumvent security measures with probability of
success; probability of detecting attack; probability of identifying individual responsible for
attack or access/modification of data and/or services; percentage of services still available
under denial-of-services attack; restore data/services; extent to which data/services
damaged and/or legitimate access denied
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
98 / 463
52
TESTABILITY
Software testability refers to the ease with which software can be made to demonstrate its faults through
(typically execution-based) testing. At least 40% of the cost of developing well-engineered systems is
taken up by testing. If the software architect can reduce this cost, the payoff is large.
In particular, testability refers to the probability, assuming that the software has at least one fault, that it
will fail on its
next
test execution. Of course, calculating this probability is not easy and, when we get to
response measures, other measures will be used.
For a system to be properly testable, it must be possible to
control
each component's internal state and
inputs and then to
observe
its outputs. Frequently this is done through use of a
test harness
, specialized
software designed to exercise the software under test. This may be as simple as a playback capability for
data recorded across various interfaces or as complicated as a testing chamber for an engine.
Testing is done by various developers, testers, verifiers, or users and is the last step of various parts of
the software life cycle. Portions of the code, the design, or the complete system may be tested. The
response measures for testability deal with how effective the tests are in discovering faults and how long
it takes to perform the tests to some desired level of coverage.
Testability General Scenarios
Figure 4.7
is an example of a testability scenario concerning the performance of a unit test: A unit tester
performs a unit test on a completed system component that provides an interface for controlling its
behavior and observing its output; 85% path coverage is achieved within three hours.
Figure 4.7. Sample testability scenario
Source of stimulus.
The testing is performed by unit testers, integration testers, system testers, or
the client. A test of the design may be performed by other developers or by an external group. In our
example, the testing is performed by a tester.
Stimulus.
The stimulus for the testing is that a milestone in the development process is met. This
might be the completion of an analysis or design increment, the completion of a coding increment
such as a class, the completed integration of a subsystem, or the completion of the whole system. In
our example, the testing is triggered by the completion of a unit of code.
Artifact.
A design, a piece of code, or the whole system is the artifact being tested. In our example, a
unit of code is to be tested.
Environment.
The test can happen at design time, at development time, at compile time, or at
deployment time. In Figure 4.7
, the test occurs during development.
Response.
Since testability is related to observability and controllability, the desired response is that
the system can be controlled to perform the desired tests and that the response to each test can be
observed. In our example, the unit can be controlled and its responses captured.
This PDF file was converted by Atop CHM to PDF Converter free version! http://www.chmconverter.com/chm-to-pdf/
Addison Wesley : Software Architecture in Practice, Second Edition
99 / 463
Documents you may be interested
Documents you may be interested
