1

>

Software Architecture

Dr. Anıl Koyuncu

 The story about kennel, architecture and
> modeling…

2
>

3
>
ØYou definitely need an
architect for planning a
skyscraper!

4
> Software Architecture
ØAs the size and complexity of a software system increase, the
design decisions and the global structure of a system become
more important than the selection of specific algorithms and data
structures.

5
> Context
ØSoftware Engineering
ØProgramming Languages
ØAlgorithms and Complexity
ØDatabases

ØSoftware Architecture

6
> Design Patterns

7
> Design Patterns

8
> Design Patterns

9
> Architecture

10
> Architecture

11
 Software Architecture
> and Software Development Life Cycle

- 12 -
> Waterfall Model

13
> Evolutionary Model

14
> System Lifecycle
ØArchitectural
decisions affect
the whole lifetime
of a system

15
> Bridge the Gap
> What is SW architecture?
ØDefinition:
“The set of principal design decisions about the system”

Architecture = {Principal Design Decision}

17
> Design Decisions
ØDesign decisions cover all aspects of the system:
• Structure
• Behavior
• Interaction
• Deployment
• Non-functional properties
• Implementation
ØPrincipal Design Decisions:
• the “important ones” depending on the goals of the stakeholders

18
> Defining Software Architecture
ØArchitecture is:
• All about communication.
• What ‘parts’ are there?
• How do the ‘parts’ fit together?
> The Stakeholders

standardization
Requirements middleware organization
engineers providers
architects

site
marketing administrators
Lawyers Security
officers

tool end users

component
component application vendors
developers
testers testers
20
> The Stakeholders
ØOne requirement can have many meanings depending on the
stakeholder’s perspective.

- 21 -
> Stakeholder Questions
ØManagement: are we on schedule?
ØDevelopers: who is responsible for what?
ØSales: can we claim it can do this task?
ØQA: what teams do we talk to about defects?
ØDevOps: where should this component be deployed?
ØSupport: which QA team signed off on this?
ØMaintenance: how can we add this feature?
> Stakeholder Conflicts
ØSystem requirements fall into two broad categories:
• Functional Properties: what the system is supposed to do (‘the system
shall do X’).
• Non-Functional Properties: what the system is supposed to be (‘the
system shall be Y’).
ØEach stakeholder will have their own opinion about what NFPs
matter most:
• ‣ e.g., the development team will care about maintainability more than the
customer
• ‣ e.g., QA will be more interested in the testability of the application than
sales

23
> Tradeoffs

24
> Typical tradeoffs
Øfunctionality vs. usability
Øcost vs. robustness
Ødevelopment velocity vs. functionality
Øefficiency vs. portability
Øcost vs. reusability
Øbackward compatibility vs. readability

25
> Architectural design decisions
ØSoftware architects must be aware of issues, such as
• How is the system distributed among machines?
• How are functionalities decomposed among components?
• How to evaluate an architecture according to non-functional requirements?
• Is there a general architecture to be used?
• How will the system be decomposed into modules?
• How should the architecture be documented?
• …

26
> Bad Architecture Impacts...
ØSystem performance
• Bottlenecks in the architectural design
ØSystem distribution
• Enterprise systems may execute in many machines
ØSoftware maintenance
• Components should to be pluggable

27
> Quality Attributes
ØWhat is Quality Attribute？
ü A quality attribute (QA) is a measurable or testable property of a system that is used to
indicate how well the system satisfies the needs of its stakeholders.
ØHow to express the Quality Attribute
ü Availability
ü Interoperability
ü Modifiability
ü Performance
ü Security
ü Testability
ü Usability
ü Other Quality attributes
> Quality Attributes
ØA quality property is an externally visible, nonfunctional
property(NFP).
• How does the system perform under load?
• How is information protected from unauthorized use?
• How long will it be down on a crash?
• How easy is it to manage, maintain, and enhance?

ØTell us how an observer views the behavior of a system.

- 29 -
> NFPs
ØNFPs are constraints on the manner in which the system
implements and delivers its functionality.
• Efficiency
• Scalability
• Complexity
• Heterogeneity
• Dependability
• Adaptability
• Security and usability
• …

30
> Design guidelines for NFPs
ØProvide guidelines that support various NFPs.
ØFocus on architectural level:
• Connectors
• Components
• Topologies

31
> Components
ØElements that encapsulate processing and data at an architectural
level.

ØAn architectural entity that:

• encapsulates a subset of functionality.
• restricts access via explicit interface.
• has explicit environmental dependencies.

32
> Software Component
ØLocus of computation and state in a system

33
> Black Box
ØComponents only accessible from the “outside”
ØEncapsulation
• Separate the content from the rest of the system
ØAbstraction
• Hide implementation details behind the interface
ØModularity
• Reusable unit of assembly
ØComposability
• Components are meant to be interconnected
• Components are made out of components

34
> Transparent Boxes
ØDifferent Degrees of Reusability
• Black Box - Components only accessible through its interface.
Implementation is kept hidden.
• Glass box – Implementation can be inspected, but not modified.
• Grey box – Implementation can be inspected, but only limited modification
is allowed
• White box – Implementation can be inspected and modified completely

35
> Abstraction Levels

36
> Component vs. Objects
ØComponent ØObjects
• Encapsulate state and • Encapsulate state and functionality
functionality
• Coarse-grained • Fine-grained
• Reusable unit of composition • Identifiable unit of instantiation
• Well-defined (documented, – • May not always provide a public
standardized) interface contract interface
with explicit dependencies
• Architecture Element: • Hard to reuse by itself (lots of
Implementation not important dependencies to other objects)
(Black Box)
• At run-time can “move” between
• High Quality components
• Object-Oriented Programming
Language Typing Construct 37
> Component Diagram
ØIt depicts how components are wired together to form larger
software systems
• Boxes to represent components
• Lines to represent communication channels between two components
• Inner boxes to represent composed components

38
>

39
>

40
>

41
> What are connectors?
ØAn architectural entity tasked with effecting and regulating
interactions between components.

ØConnectors facilitate communication among components

• May be fairly simple (Broadcast Bus)
• ...or complicated (Middleware-enabled)
• May be implicit (events)
• ...or explicit (procedure calls, ORBs, explicit communications bus)

42
> Connector Roles and Qualities

43
> Connector Examples
ØWrite Copy Watch Read
• A component writes a file, which is
then copied on a different host, and
fed as input into a different
component.
• The transfers can be batched with a
certain frequency

ØCreate Read Update Delete

• Components can communicate
by creating, updating and
reading entries in the database,
which can safely handle the
concurrency

44
> Connector Examples
• They take a basic programming language
construct and make it available across the
network (Remote Procedure Call) to
connect distributed components

ØPublish Subscribe Notify

• Components act as message sources by
publishing messages into the bus;
Components act as message sinks by
subscribing to message types

45
> Connector Examples

ØGet Put Delete Post

• Components reliably transfer state among
themselves using the GET, PUT, DELETE primitives.
POST is used for unsafe interactions.
• Components refer to each other with global
addresses (URI)

Web

46
> What are interfaces?
ØInterfaces are the connection points on components and
connectors
• They define where data may flow in and out of the components/connectors
• May be loosely specified (events go in, events go out)
• ...or highly specified

47
> What are configurations?
ØConfigurations are arrangements of components and connectors
to form an architecture

ØAn architectural configuration, or topology, is a set of specific

associations between the components and the connectors of the
system’s architecture.

48
> NFP: Efficiency
ØEfficiency is a quality that reflects a system’s ability to meet its
performance requirements.

49
> NFP: Efficiency
ØComponents:
• Keep them “small”.
• Simple and compact interfaces.
• Allow multiple interfaces to the same functionality.
• Separate data from processing components.
• Separate data from meta data.
ØConnectors:
• Carefully select connectors.
• Be careful of broadcast connectors.
• Encourage asynchronous interaction.
• Be wary of location/distribution transparency.
ØTopology:
• Keep frequent collaborators “close”.
• Consider the efficiency impact of selected styles.

50
> NFP: Complexity
ØComplexity is a property that is proportional to the size of a
system, its volume of constituent elements, their internal structure,
and their interdependencies.

51
> NFP: Complexity
ØComponents:
• Separate concerns.
• Isolate functionality from interaction.
• Ensure cohesiveness.
• Insulate processing from data format changes.
ØConnectors:
• Isolate interaction from functionality.
• Restrict interactions provided by each connector.
ØTopology:
• Eliminate unnecessary dependencies.
• Use hierarchical (de)composition.

52
> NFP: Scalability / Heterogeneity
ØScalability:
• The capability of a system to be adapted to meet new size / scope
requirements.

ØHeterogeneity:
• A system’s ability to be composed of, or execute within, disparate parts.

ØPortability:
• The ability of a system to execute on multiple platforms while retaining
their functional and non-functional properties.

53
> NFP: Scalability / Heterogeneity
ØComponents:
• Keep components focused
• Simplify interfaces
• Avoid unnecessary heterogeneity
• Distribute data sources
• Replicate data
ØConnectors:
• Use explicit connectors
• Choose the simplest connectors
• Direct vs. indirect connectors
ØTopology:
• Avoid bottlenecks
• Place data close to consumer
• Location transparency

54
> NFP: Evolvability
ØEvolvability: The ability to change to satisfy new requirements and
environments.

55
> NFP: Evolvability
ØComponents:
• Same as for complexity.
• Goal is to reduce risks by isolating modifications.
ØConnectors:
• Clearly define responsibilities.
• Make connectors flexible.
ØTopology:
• Avoid implicit connectors.
• Encourage location transparency.

56
> NFP: Dependability
ØReliability:
• The probability a system will perform within its design limits without failure over time.
ØAvailability:
• The probability the system is available at a particular instant in time.
ØRobustness:
• The ability of a system to respond adequately to unanticipated runtime conditions.
ØFault-tolerance:
• The ability of a system to respond gracefully to failures at runtime.
• Faults arise from: environment, components, connectors, component-connector mismatches.
ØSurvivability:
• The ability to resist, recover, and adapt to threats.
• Sources: attacks, failures, and accidents.
• Steps: resist, recognize, recover, adapt.
ØSafety:
• The ability to avoid failures that will cause loss of life, injury, or loss to property.

57
> NFP: Dependability
ØComponents:
• Control external component dependencies.
• Support reflection.
• Support exception handling.
ØConnectors:
• Use explicit connectors.
• Provide interaction guarantees.
ØTopology:
• Avoid single points of failure.
• Enable back-ups.
• Support system health monitoring.
• Support dynamic adaptation.

58
>

59