Architecture Design

Instructor: Mehroze Khan

Achieving Quality Attributes
• Reflect the characteristics that users want to see in the products we build.
• Architectural styles provide general beneficial properties. Quality attributes also
need to be supported:
• Modifiability
• Performance
• Security
• Reliability
• Robustness
• Usability
• Business goals
Modifiability
• Design must be easy to change
• More than half of the full life-cycle cost of a system—including
development, problem fixing, enhancement, and evolution—is spent after
the first version of the software is developed and released, modifiability is
essential.
• Two classifications of affected software units:
• Directly affected
• Indirectly affected
Modifiability
• Directly affected units’ responsibilities change to accommodate a system
modification
• Anticipate expected changes
• Value cohesion
• Maintain generality
• Indirectly affected units’ responsibilities do not change, but
implementations must be revised
• Lower coupling
• Interact through interfaces
• Employ multiple interfaces
Performance
• Performance attributes describe constraints on system speed and
capacity:
• Response time: How fast does our software respond to requests?
• Throughput: How many requests can it process per minute?
• Load: How many users can it support before response time and throughput
start to suffer?
Performance
• Tactics for improving performance include:
• Improve utilization of resources
• Concurrency
• Replicate and distribute shared data
• Manage resource allocation more effectively
• First-come/first-served: Requests are processed in the order in which they are
received
• Explicit priority: Requests are processed in order of their assigned priorities
• Earliest deadline first: Requests are processed in order of their impending deadlines
• Pre-emptive Scheduling: Lower-priority request is preempted in favor of a higher-
priority request.
• Round Robin: Allocates resources to requests for fixed time interval.
• Reduce demand for resources
Security
• Two key architectural characteristics particularly relevant to security:
immunity and resilience
• Immunity: ability to thwart an attempted attack
• The architecture encourages immunity by:
• Ensuring all security features are included in the design
• Minimizing exploitable security weaknesses
• Resilience: ability to recover quickly and easily from an attack
• The architecture encourages resilience by:
• Segmenting functionality to contain attack
• Enabling the system to quickly restore functionality
Reliability
• A software system is reliable if it correctly performs its required
functions under assumed conditions
• Is the software internally free of errors?
• A fault is the result of human error, compared to a failure, which is an
observable departure from required behaviour
• Software is made more reliable by preventing or tolerating faults
Reliability
• Passive fault detection: wait until fault occurs during execution
• Active fault detection: periodically check for symptoms or try to anticipate when failures
will occur
• Exceptions: situations that cause the system to deviate from its desired behaviour
• Include exception handling in design to handle exception and return system to
acceptable state
• Typical exceptions include:
• Failing to provide a service
• Providing the wrong service
• Corrupting data
• Violating a system invariant (e.g.; security property)
• Deadlocking
Reliability
• Fault recovery: handling fault immediately to limit damage
• Fault recovery tactics:
• Undoing transactions: manage a series of actions as a single transaction that are
easily undone if a fault occurs midway through the transaction
• Checkpoint/rollback: software records a checkpoint of current state; rolls back to
that point if system gets in trouble
• Backup: system automatically substitutes faulty unit with backup unit
• Degraded service: returns to previous state, offers degraded version of the service
• Correct and continue: detects the problem (data consistency, stalled process) and
treats the symptoms
• Report: system returns to its previous state and reports the problem to an
exception-handling unit
Robustness
• A system is robust if it includes mechanisms for accommodating or recovering from
problems in the environment or in other unit
• Mutual suspicion: each software unit assumes that the other units contain faults
• Robustness tactics differ from reliability tactics because the source of problems is
different
• Recovery tactics are similar:
• Rollback to checkpoint state
• Abort a transaction
• Initiate a backup unit
• Provide reduced service
• Correct symptoms and continue processing
• Trigger an exception
Usability
• Usability reflects the ease with which a user is able to operate the
system
• User interface should reside in its own software unit
• Some user-initiated commands require architectural support
• There are some system-initiated activities for which the system should
maintain a model of its environment
Business Goals
• Business Goals are quality attributes the system is expected to exhibit (e.g., minimizing the
cost of development and time to market)
• Buy vs. Build
• Save development time, money
• More reliable
• Existing components create constraints; vulnerable to supplier
• Initial development vs. maintenance costs
• Save money by making system modifiable
• Increased complexity may delay release; lose market to competitors
• New vs. known technologies
• Acquiring expertise costs money, delays product release
• Either learn how to use the new technology or hire new personnel
• Eventually, we must develop the expertise ourselves