Vakgroep Informatietechnologie – IBCN

Software Architecture

Architectural Requirements

Quality Attributes

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 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.

Requirements DesignSoftware

Architecture

Dilbert on Software Requirements ...

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 3

Functional versus Non Functional

Functional Requirements: FR’s capture the intended behavior of the system

and describe what the systems should do. This behavior may be expressed as services, tasks or functions the system is required to perform.

Non Functional Requirements: NFR’s are not directly concerned with a specific

function delivered by the system. They typically come from the ABC (Architecture Business Cycle) and cover o.a. business, organisational, legal and quality requirements.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 4

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 5

Architecture and Functionality

Functionality defines what the system has to do. can be achieved through any number of

structures. is often the ONLY consideration at the start of

a project and leads to redesign, project cancelation,…

to slow hard to maintain

The mapping of the system’s functionality onto software structures is

critical for the support of quality .

Use Cases & Scenario’s / UML

Functional Requirements are documented with: Use cases:

define a goal-oriented set of interactions between external actors and the system under consideration.

Are graphically summarized in a UML use case diagram. They are documented using a use case template.

Scenario’s: A (black box or system ) scenario is an instance of a use

case, and represents a single path through the use case. Thus, one may construct a scenario for the main flow through the use case, and other scenarios for each possible variation.

Scenario’s are documented with UML sequence diagrams

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 6

Example : Use Case Diagram

Department of Information Technology – Broadband Communication Networks (IBCN) 7

System Sequence Diagrams

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 8

The origins of architecture complexity

Functionality needs to be mapped to software structures in order to support the quality

This mapping requires the collaboration, communication, synchronisation of these software elements in order to provide the functionality.

Example: caching

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 9

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 10

Software Quality Attributes

Software Architecture and ... Quality Attributes. Quality Attribute Tactics. Architecture Patterns

Quality is ‘value as perceived by the customer’. Over and above the definition of customer features, quality attributes clarify which items are most important to the customer's perception of the product's quality and performance.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 11

Qualities in Software Architecture

SystemQualities

Functionality

BusinessQualities

ArchitecturalQualities

Software

Architecture

• Modifiability

• Performance

• Testability

• Availability

• Security

• Usability

• Scalability

• Interoperability

• Portability

• Capabilities

• Functions

• Services

• Behaviour

• Cost

• Margins

• Time-to-market

• Target market

• System lifetime

• Conceptual Integrity

• Correctness

• Completeness

• Buildability

ISO/IEC CD 25010 SQuaRE

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 12

[1.] ISO/IEC CD 25010 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE), 2009

Quality Attributes in practice:

EXAMPLE : SLA - Service Level Agreement A service-level agreement (SLA) is a contract

between a service provider and a customer that specifies, usually in measurable terms, what services provider will furnish.

SLA’s may specify : What percentage of the time services will be available The number of users that can be served simultaneously Specific performance benchmarks to which actual

performance will be periodically compared. Help desk response time Usage statistics that will be provided.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 13

SLA terms (1/2)

Guaranteed uptime The expected availability of the Platform is 99.8%

or with periods of unavailability of maximum 2 (two) hours per month.

Recovery In case of system failure, the application and all

data shall be restored within 4 hours after problem fixation.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 14

SLA Terms (2/2)

Performance The target response time to any request should be

respected in 90% of all requests. New page download time inferior to 3 seconds

Capacity The installation will be planned for a maximum of

20.000 requests per day.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 15

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 16

Business Qualities (1/2)

Time to Market: Build or buy Re-use existing elements from previous

projects COTS/OSS :Time to market is often reduced

by using prebuilt elements such as commercial off-the-shelf or open source components.

Deploy a subset : The ability to insert or deploy a subset of the system depends on the decomposition of the system into elements. (roll-out schedule)

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 17

Business Qualities (2/2)

Cost and Benefit: The development budget must not be exceeded. Different architectures will yield different development

costs. Architectures based on new technology are more expensive Flexible architecture cost more to build but will be less costly

to maintain and modify

System Lifetime: If the system is intended to have a long lifetime,

modifiability, scalability, and portability become important. ( = more revenue)

Building in the additional infrastructure (such as a layer to support portability) will usually compromise time to market.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 18

The Quality state-of-mind

Quality is not the privilege of Architects: it needs to be considered throughout the entire

lifecycle (design, implementation, deployment)

But: Architecture is critical to the realisation of many

qualities.

And Architecture cannot achieve quality by itself. Qualities can never be achieved in isolation.

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 19

Quality Attribute Scenarios

Qualities are abstract and non-operational: What does it mean for a system to be modifiable ?

Quality attribute requirements are captured with quality attribute scenarios.

Generic scenarios (system independent) need to be translated into specific scenarios

Quality Attribute Scenarios

A Quality Attribute Scenario describes:

SOURCE: who or what STIMULUS: does something ARTIFACT: to the system or part of it ENVIRONMENT: under certain conditions RESPONES: how the system reacts MEASURE: how you can measure this

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 20

Example : Public Transport Signage

Vakgroep Informatietechnologie – Onderzoeksgroep IBCN p. 21

Availability QAS :

Q: What is the architectural impact of this requirement ?

SOURCE who or what A random event

STIMULUS does something ... causes a failure

ARTIFACT to the system or part of it ... to the communication system

ENVIRONMENT under certain conditions ...during normal operations

RESPONSE how the system reacts All displays must start showing scheduled arrival times for all buses

MEASURE how you can measure this ... Within 30 seconds of failure detection