An example: Modifiability
• Goal: Control the time and cost to implement, test,
and deploy changes
– Localize modifications
– Prevent the ripple effect
– Defer binding time
9/14/2014 SEPS ZG651 Software Architectures 2
• There is not necessarily a precise relationship
between the number of modules affected by a set
of changes and the cost of implementing those
changes, restricting modifications to a small set of
modules will generally reduce the cost.
• The goal of tactics in this set is to assign
responsibilities to modules during design such that
anticipated changes will be limited in scope.
9/14/2014 SEPS ZG651 Software Architectures 4
• Maintain semantic coherence
– Semantic coherence refers to the relationships among
responsibilities in a module.
– The goal is to ensure that all of these responsibilities
work together without excessive reliance on other
– Examples of abstracting common services are the use of
application frameworks and the use of other middleware
9/14/2014 SEPS ZG651 Software Architectures 5
Prevent Ripple Effects
• A ripple effect from a modification is the necessity
of making changes to modules not directly affected
• For instance, if module A is changed to accomplish a
particular modification, then module B is changed
only because of the change to module A. B has to
be modified because it depends, in some sense, on
9/14/2014 SEPS ZG651 Software Architectures 6
Prevent Ripple Effects
• The various types of dependencies that one module can
have on another.
1. Syntax of
– data. For B to compile (or execute) correctly, the type (or format) of the data that is
produced by A and consumed by B must be consistent with the type (or format) of
data assumed by B.
– service. For B to compile and execute correctly, the signature of services provided by A
and invoked by B must be consistent with the assumptions of B.
2. Semantics of
– data. For B to execute correctly, the semantics of the data produced by A and
consumed by B must be consistent with the assumptions of B.
– service. For B to execute correctly, the semantics of the services produced by A and
used by B must be consistent with the assumptions of B.
9/14/2014 SEPS ZG651 Software Architectures 7
Prevent Ripple Effects
3. Sequence of
– data. For B to execute correctly, it must receive the data produced by A in a fixed
• For example, a data packet's header must precede its body in order of reception
– control. For B to execute correctly, A must have executed previously within certain
• For example, A must have executed no longer than 5ms before B executes
4. Identity of an interface of A.
– A may have multiple interfaces. For B to compile and execute correctly, the identity
(name or handle) of the interface must be consistent with the assumptions of B.
5. Location of A (runtime).
– For B to execute correctly, the runtime location of A must be consistent with the
assumptions of B. For example, B may assume that A is located in a different process
on the same processor.
9/14/2014 SEPS ZG651 Software Architectures 8
Prevent Ripple Effects
6. Quality of service/data provided by A
– For B to execute correctly, some property involving the quality of the data or service
provided by A must be consistent with B's assumptions.
• For example, data provided by a particular sensor must have a certain accuracy in order for the algorithms of
B to work correctly.
7. Existence of A.
– For B to execute correctly, A must exist.
• For example, if B is requesting a service from an object A, and A does not exist and cannot be dynamically
created, then B will not execute correctly.
8. Resource behavior of A.
– For B to execute correctly, the resource behavior of A must be consistent with B's
assumptions. This can be either resource usage of A (A uses the same memory as B) or
resource ownership (B reserves a resource that A believes it owns).
9/14/2014 SEPS ZG651 Software Architectures 9
Defer Binding Time
• It allows non developers to make changes at the time of
• The tactics used at defer binding time are :
– Runtime registration supports plug-and-play operation at the cost of
additional overhead to manage the registration. Publish/subscribe
registration, for example, can be implemented at either runtime or load
– Configuration files are intended to set parameters at startup.
– Polymorphism allows late binding of method calls.
– Component replacement allows load time binding.
– Adherence to defined protocols allows runtime binding of independent
9/14/2014 SEPS ZG651 Software Architectures 10
• The goal of performance tactics is to generate a response to
an event arriving at the system within some time constraint.
• The event can be single or a stream and is the trigger for a
request to perform computation.
• It can be the arrival of a message, the expiration of a time
interval, the detection of a significant change of state in the
9/14/2014 SEPS ZG651 Software Architectures 12
• After an event arrives, either the system is processing on
that event or the processing is blocked for some reason.
• This leads to the two basic contributors to the response time
– Resource consumption
– Blocked time
9/14/2014 SEPS ZG651 Software Architectures 13
• Resources include CPU, data stores, network communication
bandwidth, and memory, but it can also include entities
defined by the particular system under design.
– For example, buffers must be managed and access to critical sections
must be made sequential.
• Events can be of varying types, and each type goes through a
– For example, a message is generated by one component, is placed on
the network, and arrives at another component.
9/14/2014 SEPS ZG651 Software Architectures 14
• A computation can be blocked from using a resource because of
contention for it, because the resource is unavailable, or because the
computation depends on the result of other computations that are not
– Contention for resources : Shows events arriving at the system.
– Availability of resources: Even in the absence of contention, computation
cannot proceed if a resource is unavailable.
– Dependency on other computation : A computation may have to wait
because it must synchronize with the results of another computation or
because it is waiting for the results of a computation that it initiated.
• For example, it may be reading information from two different sources, if these two sources
are read sequentially, the latency will be higher than if they are read in parallel.
9/14/2014 SEPS ZG651 Software Architectures 15
• Event streams are the source of resource demand.
• Two characteristics of demand are the time
between events in a resource stream and how much
of a resource is consumed by each request.
9/14/2014 SEPS ZG651 Software Architectures 16
• The demand for resources may not be controllable, the
management of these resources affects response times.
• Some resource management tactics are:
– Maintain multiple copies of either data or computations.
– Increase available resources
9/14/2014 SEPS ZG651 Software Architectures 17
• Whenever there is contention for a resource, the resource
must be scheduled.
• Processors are scheduled, buffers are scheduled, and
networks are scheduled.
• The architect's goal is to understand the characteristics of
each resource's use and choose the scheduling strategy that
is compatible with it.
9/14/2014 SEPS ZG651 Software Architectures 18
• Some common scheduling policies are:
– Fixed-priority scheduling.
• Fixed-priority scheduling assigns each source of resource requests a particular
priority and assigns the resources in that priority order.
– Dynamic priority scheduling
• Round robin is a scheduling strategy that orders the requests and then, at every
assignment possibility, assigns the resource to the next request in that order.
• Earliest deadline first assigns priorities based on the pending requests with the
– Static scheduling. A cyclic executive schedule is a scheduling strategy where
the pre-emption points and the sequence of assignment to the resource are
9/14/2014 SEPS ZG651 Software Architectures 19
• Tactics for achieving security can be divided into
those concerned with
– resisting attacks,
– detecting attacks
– recovering from attacks.
9/14/2014 SEPS ZG651 Software Architectures 22
• The detection of an attack is usually through an intrusion
• Such systems work by comparing network traffic patterns to
• In the case of misuse detection, the traffic pattern is
compared to historic patterns of known attacks.
• In the case of anomaly detection, the traffic pattern is
compared to a historical baseline of itself.
9/14/2014 SEPS ZG651 Software Architectures 24
Recovering From Attacks
• Tactics involved in recovering from an attack can be
divided into :
– restoring state
– attacker identification
9/14/2014 SEPS ZG651 Software Architectures 25
• The goal of tactics for testability is to allow for easier testing
when an increment of software development is completed.
9/14/2014 SEPS ZG651 Software Architectures 27
• There are three tactics for managing input and output for
– Record/playback : It refers to both capturing information crossing an
interface and using it as input into the test harness.
– Separate interface from implementation: The implementation allows
substitution of implementations for various testing purposes.
– Specialize access routes/interfaces : It allows the capturing or
specification of variable values for a component through a test
harness as well as independently from its normal execution.
• For example, metadata might be made available through a specialized interface
that a test harness would use to drive its activities.
9/14/2014 SEPS ZG651 Software Architectures 28
• A component can implement tactics based on
internal state to support the testing process.
– Built-in monitors: The component can maintain
state, performance load, capacity, security, or
other information accessible through an
9/14/2014 SEPS ZG651 Software Architectures 29
• It is concerned with how easy it is for the user to
accomplish a desired task and the kind of support
the system provides to the user.
9/14/2014 SEPS ZG651 Software Architectures 31
9/14/2014 SEPS ZG651 Software Architectures 33
SOFTWARE ARCHITECTURE IN
Creating an Architecture
9/14/2014 SEPS ZG651 Software Architectures34
Designing the Architecture
• Architecture in the life cycle
• Designing the architecture
• Forming the team structure & its relationship
to the architecture
• Creating a skeletal system
9/14/2014 SEPS ZG651 Software Architectures 35
• Shaping requirements: functional, quality, & business
• Find them by:
1 Identify the highest priority business goals (relatively few).
2 Turn these into quality scenarios or use cases.
3 Choose the ones that will have the most impact on the
• These are the architectural drivers & should be < 10.
9/14/2014 SEPS ZG651 Software Architectures 37
Attribute Driven Design
• An extension of other methods.
• Bases the decomposition process on the quality
• Recursive decomposition:
– tactics & architectural patterns are chosen to
satisfy a set of quality scenarios
– functionality is allocated to instantiate the
– results in course-grained architecture
9/14/2014 SEPS ZG651 Software Architectures 38
A. Identify an initial set of architectural drivers
B. Choose the module to decompose (initially the entire
C. Refine the module:
1. Choose the specific architectural drivers
2. Choose an architectural pattern that satisfies the drivers, based on
the appropriate tactics. Identify child modules to implement the
3. Instantiate modules & allocate functionality: draw multiple views.
9/14/2014 SEPS ZG651 Software Architectures 39
ADD Steps, con’t
4. Define interfaces of the child modules. The decomposition
provides modules & constraints on the types of module
5. Verify & refine use cases & quality scenarios and make them
constraints for the child modules. Verification & preparation for
more decomposition or implementation.
D. Repeat C for every module that needs further
9/14/2014 SEPS ZG651 Software Architectures 40
Creating a Skeletal System
• Provide an underlying capability to implement a system’s
functionality in an effective order:
– Implement execution & interaction.
– Install the simplest of functions that instigates some rote
• Result: a running system that sits & hums to itself.
– Choose functionality: most problematic; available staff;
– Employ the uses structure to identify additional software
to support chosen functionality.
9/14/2014 SEPS ZG651 Software Architectures 41
– At no point is the integration & test overwhelming; easy to find
incremental source of errors.
– Budgets & schedules are more predictable with smaller increments,
providing management & marketing with more delivery options.
– Stubs adhere to the final version of interfaces:
• help with understanding & testing interactions
• producing hardcoded canned output or reading in output
• can generate synthetic load that aids early understanding of
performance, including interactions & bottlenecks.
9/14/2014 SEPS ZG651 Software Architectures 42
• Potential problem:
– The first development team to complete a portion of the
system gets to define the interfaces for everyone.
– This might be too simple, and penalize the complex parts
of the system.
– The effect would be to make they complex subsystems
• So, first negotiate the interfaces.
9/14/2014 SEPS ZG651 Software Architectures 43
• Architectural design must follow requirements
analysis, but should begin as soon as the
architectural drivers are determined.
• When a sufficient portion of the architecture has
been designed (but not completed), start building a
skeletal framework that is the basis of iterative
9/14/2014 SEPS ZG651 Software Architectures 44
• Among the most sophisticated software systems:
– Highly distributed
– Hard real-time performance requirements
– Modifiability: changes in requirements,
simulated vehicles & environment
– Scalability: continuous improvement of the
simulation of the real world
9/14/2014 SEPS ZG651 Software Architectures 45
• A driving concern in large systems
• Those developed by distributed teams or
• Definition: the ease with which separately
developed elements, including COTS, can be
made to work together to fulfill the system’s
9/14/2014 SEPS ZG651 Software Architectures 46
• Keep interfaces small, simple, and stable.
• Adhere to defined protocols.
• Loose coupling or minimal dependencies between
• Use a component framework.
• Use “versioned” interfaces that allow extensions
while permitting existing elements to work under
the original constraints.
9/14/2014 SEPS ZG651 Software Architectures 47
Pattern: a Structural Model
• With the emphasis on:
– Simplicity and similarity of system’s substructures
– Decoupling of data- and control-passing
strategies from computation
– Minimizing module types
– A small number of system-wide coordination
– Transparency of design
9/14/2014 SEPS ZG651 Software Architectures 48
Details, p. 181
• The pattern includes an object-oriented
design to model the subsystems and
controller children of the air vehicle. It
marries real-time scheduling to this OOD as a
mean of controlling the execution order of
the simulation’s subsystems so that fidelity
can be guaranteed.
9/14/2014 SEPS ZG651 Software Architectures 49
• Architectural solution:
– reference model Fig 8.3
• Treatment of time:
– Periodic Time Management (for real-time)
– Event-based Time Management (non-RT)
• Skeletal System: Architecture Prototype
– Flight Simulator has 6 module types!
– What are the benefits?
9/14/2014 SEPS ZG651 Software Architectures 50
• Both the data connections and the control
connections have been minimized.
– Integrating another controller has been reduced
to a problem that is linear, not exponential.
– Integrating two subsystems is again reduced to
ensuring that the two pass data consistently.
9/14/2014 SEPS ZG651 Software Architectures 51
• The cost is that the subsystem controllers often act
purely as data conduits, increasing complexity and
• In practice (for applicable) systems, the benefits far
outweigh the cost:
– Architectural skeleton allows incremental
development and easier integration.
– Every project that has used structural modeling
has reported easy, smooth integration.
9/14/2014 SEPS ZG651 Software Architectures 52