IST 412

1
IST 412

• Software Architecture

Chapter 10
2
Architecture
The architecture is not the operational software.
Architecture constitutes a relatively small,
intellectually graspable model of how the system
is structured and how its components work
together It enables a software engineer to
(1) analyze the effectiveness of the design in
meeting its stated requirements, (2) consider
architectural alternatives at a stage when making
design changes is still relatively easy, (3)
reduce the risks associated with the construction
of the software.
3
Architectural Styles

• Each style describes a category that consists of
  
• a set of components (e.g., a database,
  computational modules) that perform a function
  required by a system,
• a set of connectors that enable communication,
  coordination and cooperation among components,
• constraints that define how components can be
  integrated to form the system
• semantic models that enable a designer to
  understand the overall properties of a system by
  analyzing the known properties of its constituent
  parts.

4
Data-Centered Architecture
5
Data Flow Architecture
6
Example
microphones
encoders for
near
microphone
sound
input
source
equalize
remove
transmit
cancel
cancel
dynamic
non-voice
compress
noise
echo
range
frequencies
TCP/IP Transmission
encoder for
ambient
encode
distant
receive
noise
decompress
speaker
microphone
output
7
Call and Return Architecture
8
Layered Architecture
9
Architectural Patterns

• Concurrencyapplications must handle multiple
  tasks in a manner that simulates parallelism
• operating system process management pattern
• task scheduler pattern
• PersistenceData persists if it survives past the
  execution of the process that created it. Two
  patterns are common
• a database management system pattern that applies
  the storage and retrieval capability of a DBMS to
  the application architecture
• an application level persistence pattern that
  builds persistence features into the application
  architecture
• Distribution the manner in which systems or
  components within systems communicate with one
  another in a distributed environment
• A broker acts as a middle-man between the
  client component and a server component.

10

• Design Patterns

http//www.dofactory.com/Patterns/Patterns.aspx
11
Design patterns

• a template solution to a recurring design
  problem
• reusable design knowledge
• an example of good design
• Learning to design starts by studying other
  designs

12
What makes a good design?

• Low coupling and high coherence
• Clear dependencies
• Explicit assumptions
• Design Patterns can help
• They are generalized from existing systems
• They provide a shared vocabulary to designers
• They provide examples of good designs

13
A Pattern Taxonomy
Adapter
Bridge
Facade
Proxy
14
Table Lookup A heuristic

• You dont send the message itself across the wire
  but an index value. E.g. The message is ALREADY
  present on the other machine.
• Optimize its much smaller to send a single in
  value that it is an entire string of several
  characters.

15
Table Lookup A heuristic

• public static final String MyStrings
  command1", command2"
• Send the index value so,
• 0 would be command1, etc.
• Your look up will be
• 0 for command1
• 1 for command2

16
Parameters that may change

• public static final String actorsNames
  "archemedis", "electra"
• public static final String actorsFiles
  "archemedis_multi.wsad", "electra_multi.wsad"
• Or put them in an XML, thus you can generalize
  your program and users can change these values
  without recompiling.

17
A Pattern Taxonomy
Adapter
Bridge
Facade
Proxy
18
Facade Pattern

• Provides a unified interface
• A facade defines a higher-level interface that
  makes the subsystem easier to use
• Facades allow us to provide a closed architecture

19
Open vs. Closed Architecture

• Open architecture
• Why is this good?
• Efficiency
• Why is this bad?
• Understandability
• Maintainability
• We can be assured that the subsystem will be
  misused, leading to non-portable code

Subsystem1
Subsystem2
obj2
obj3
obj1
obj4
20
Realizing a Closed Architecture with a Façade
Subsystem1

• The subsystem decides exactly how it is accessed.
  
• No need to worry about misuse by callers
• If a façade is used the subsystem can be used in
  an early integration test
• We need to write only a driver

Subsystem2 API

obj3
obj2
obj1
obj4
21
Adapter Design Pattern

• Convert the interface of a class into another
  interface clients expect. Adapter lets classes
  work together that couldn't otherwise because of
  incompatible interfaces.

22
Bridge Design Pattern

• Decouple an abstraction from its implementation
  so that the two can vary independently.

23
composite Design Pattern

• Compose objects into tree structures to
  represent part-whole hierarchies. Composite lets
  clients treat individual objects and compositions
  of objects uniformly.

24
Proxy Design Pattern

• Provide a surrogate or placeholder for another
  object to control access to it.

25
Strategy Design Pattern

• Define a family of algorithms, encapsulate each
  one, and make them interchangeable. Strategy lets
  the algorithm vary independently from clients
  that use it.

26
Template Method Design Pattern

• Define the skeleton of an algorithm in an
  operation, deferring some steps to subclasses.
  Template Method lets subclasses redefine certain
  steps of an algorithm without changing the
  algorithm's structure.