software architecture
Download
Skip this Video
Download Presentation
SOFTWARE ARCHITECTURE

Loading in 2 Seconds...

play fullscreen
1 / 36

SOFTWARE ARCHITECTURE - PowerPoint PPT Presentation


  • 123 Views
  • Uploaded on

SOFTWARE ARCHITECTURE. Software Design:. the choice of algorithms and data structures for computation has previously been the focus of attention in application design. As size and complexity of software systems increased, system structure became a more significant issue.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' SOFTWARE ARCHITECTURE' - vanya


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
software architecture
SOFTWARE ARCHITECTURE

Software Design:

the choice of algorithms and data structures for computation has previously been the focus of attention in application design

As size and complexity of software systems increased, system structure became a more significant issue.

software architecture1
the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among themSOFTWARE ARCHITECTURE

Definition:

The intent of this definition is that a software architecture must abstract away some information from the system and yet provide enough information to be a basis for analysis, decision making, and hence risk reduction.

software architecture2
the organisation of a system as a composition of components

global control structures

the protocols for communication, synchronisation, and data access

the assignment of functionality of design elements

the composition of design elements

physical distribution; scaling and performance

dimensions of evolution

selection among design alternatives.

SOFTWARE ARCHITECTURE

Structural issues include:

This is the software architecture level of design

software architecture3

“Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers”

“We have chosen a distributed, object-oriented approach to managing information”

“The easiest way to make the canonical sequential compiler into a concurrent compiler is to pipeline the execution of the compiler phases over a number of processors….A more effective way is to split the source code into many segments, which are concurrently processed through the various phases of compilation by multiple compiler processors before a final, merging pass recombines the object code into a single program”

“Abstraction layering and system decomposition provide the appearance of system uniformity to clients, yet allow Helix to accommodate a diversity of autonomous devices. The architecture encourages a client-server model for the structuring of applications”

SOFTWARE ARCHITECTURE

Unfortunately, at the moment most systems are described in architectural terms using idiomatic language….

software architecture4
What is “pipeline” architecture
  • global rates of flow
  • patterns of communication
  • execution control structure
  • scalability
  • intended paths of system evolution

such as:

SOFTWARE ARCHITECTURE
  • and when should one choose it over a “layered” one?

Are there significant consequences of choosing one architecture over another?

Architectural structures convey nothing about the content of programs or modules but do provide a framework, the skeleton, to understand system-level arrangements

software architecture5
SOFTWARE ARCHITECTURE

Looking at the Hardware model….

Hardware systems have basically 4 levels:

Circuits (transistors, resistors, capacitors etc)

Logic designs – gates (flip-flops, register arrays, NAND etc)

Programs (instructions, controls, operators etc)

PMSs (Processors, Memories, Switches, Controls etc)

software architecture6
SOFTWARE ARCHITECTURE

Looking at the Software model….

Software has basically 3 levels:

Executables (memory maps, call stacks, register allocations etc)

Code (data structures, algorithms)

Architecture (overall association of system components or modules)

software architecture7
SOFTWARE ARCHITECTURE

increasing abstraction

The evolution of data typing ….

1950s: programming in machine language: data and instructions were explicitly placed in memory.

no abstraction: everything was explicit

Then certain patterns of execution were usefully automated: arithmetic expressions, loops, conditional statements

In Algol data typing moved on: it was a declaration of what you intended to do with each grouping of data

increasing level of abstraction

the black box idea for subroutines

Advantage: compiler then checked the integrity of these intentions

Further abstraction occurred by introduction of modules and separation of module specification from implementation

software architecture8
SOFTWARE ARCHITECTURE

Data structures to software architecture….

“Just as good programmers recognized useful data structures in the late 1960s, good software system designers now recognize useful system organisations.”

To build truly composable systems, we must allow flexible, high-level connections between existing systems in ways not foreseen by their original developers

software architecture9

Reuse of software is impeded by differences in component packaging

SOFTWARE ARCHITECTURE

Modern paradigms….

So that high-level relationships among systems can be understood we need to recognise modern paradigms

New systems can then be built as variations on old systems

Systems need to be described in a consistent manner

“Norman”

“Gothic”

software architecture10
SOFTWARE ARCHITECTURE

Modern paradigms….

Often, it is difficult to see if components can interact properly if taken for reuse

the same function may be built as filter or a procedure

they may interact through message passing or sharing data

Architectural descriptions may help with these problems

this may well carry over into maintenance when most effort usually goes into understanding the existing code

...

slide12

SOFTWARE ARCHITECTURE

Software architecture is also a lot about STANDARDISATION

That is: how to represent the varied forms of software out there in the commercial world in a few, consistent formats which could be automated

slide13

SOFTWARE ARCHITECTURE

“patterns”

Gamma, E., Helm, R., Johnson, R. & Vlissides, J. (1995). Design patterns: elements of reusable object-oriented software.

expert designers know not to solve every problem from first principles

they reuse solutions that have worked for them in the past

An analogy with novelists and playwrights helps illustrate the point: genre is important in constructing a plot - like the "tragically flawed hero" or "unrequited love breeds contempt and revenge"

slide14

SOFTWARE ARCHITECTURE

“patterns”

Gamma et al. (1995)...

a pattern has 4 essential elements:

1. NAME - a handle we can use to describe a design problem, solutions, and consequences in short form. Naming lets us design at a high level of abstraction, lets us talk and write about them.

2. PROBLEM DESCRIPTION - when to apply the pattern, its context, conditions or specific design problems. It might describe class or object structures that are symptomatic of an inflexible design.

slide15

SOFTWARE ARCHITECTURE

“patterns”

Gamma et al. (1995)...

a pattern has 4 essential elements:

3. SOLUTION - elements that make up the design, their relationships, responsibilities, and collaborations, but not a particular concrete design or implementation. It is an abstract description of a design problem and how a general arrangements of elements (classes, objects) solves it.

4. CONSEQUENCES - the results and trade-offs of applying the pattern. This is critical for evaluating design alternatives and for understanding the costs and benefits in terms of space and time. Reuse in O-O can affect system flexibility, extensibility, or portability -. needs evaluation.

slide16

SOFTWARE ARCHITECTURE

“patterns”

Gamma et al. (1995)...

patterns?

Points of view affect one\'s interpretation of what is and what isn\'t a pattern

One person\'s pattern can be another person\'s primitive building block

Volkswagen, Mercedes and Ferrari are design patterns which might apply to the car industry

These names conjure up designs which are generalised in our minds but are all different

Equally, though VW Sharon and Golf are valid pattern names which apply to the car industry - each conjures up a more detailed design pattern in our minds and differentiates more clearly the type of use and users

slide17

SOFTWARE ARCHITECTURE

“patterns”

Kimble and Selby (2000)

An interdisciplinary study of information systems: Christopher Alexander and IS failure (Proc. UKAIS, p256-265)

in IS terms a pattern is a solution to a software problem that has been captured and documented in a form others can understand and apply

to build complete applications

  • a pattern language
  • individual patterns
  • network of connections
  • (showing how they may be combined)
slide18

SOFTWARE ARCHITECTURE

“patterns”

Kimble and Selby (2000)…

Alexander’s argument is that an apparently creative process is governed by an underlying set of rules or constraints:

“once you admit that the rules are generative, then you have sort of got right to the heart of the creative core…”

in terms of functionality, the aim should be to incorporate just those functions which help users do what they want: basic functional patterns.

slide19

batch sequential

pipes and filters

dataflow systems

virtual machines

interpreters

ruled-based systems

data-centred systems (repositories)

databases

hypertext systems

blackboards

SOFTWARE ARCHITECTURE

Software organisational styles

main programme and sub-routine

0 0 systems

hierarchical layers

call and return systems

independent components

communicating processes

event systems

slide20

batch sequential

pipes and filters

dataflow systems

SOFTWARE ARCHITECTURE

each component has a set of inputs and a set of outputs

A degenerate case of pipeline architecture occurs when each filter processes all of its inputs data as a single entity. This is the batch sequential system.

Each component reads a stream of data on its inputs and produces a stream of data on its outputs

slide21

batch sequential

pipes and filters

dataflow systems

connectors are termed “pipes”

SOFTWARE ARCHITECTURE

some transformation happens

this may be incremental: output may begin before input has ceased

components are termed “filters”

slide22

batch sequential

pipes and filters

dataflow systems

=

they should not share the same state as each other

Specification simply restricts what appears on the input pipe or guarantees what appears on the output pipe

filter

input

output

SOFTWARE ARCHITECTURE

Filters must be independent entities

filters do not know the identity of the upstream and downstream filters

slide23

batch sequential

pipes and filters

dataflow systems

SOFTWARE ARCHITECTURE

Furthermore the network output should not depend on the order in which filters process

Unix supports pipe and filter architecture - run time mechanisms implement pipes

slide24

batch sequential

pipes and filters

dataflow systems

SOFTWARE ARCHITECTURE

Nice properties:

allow designers to understand the overall input/output behaviour of a system from a simple composition of the behaviours of the individual filters

They support reuse: any 2 filters can be hooked together provided they agree on the data that are being transmitted between them

Systems are easy to maintain and enhance: new filters can be added to existing systems and old filters can be replaced by improved ones.

supports concurrent execution

They support throughput and deadlock analysis

slide25

SOFTWARE ARCHITECTURE

LAYERED SYSTEMS

ORGANISED HIERARCHICALLY

each layer providing service to the one above it and serving as a client to the layer below

in some layered systems inner layers are hidden from all except the adjacent outer layer

in these systems the components implement a virtual machine

slide26

OSI ISO model for the Internet

Open Systems Interconnect

International Organization for Standardization

SOFTWARE ARCHITECTURE

LAYERED SYSTEMS

most widely known example

layered communication protocols

A seven layer model of network architecture and a suite of protocols (a protocol stack) to implement it, developed by ISO in 1978 as a framework for international standards in heterogeneous computer network architecture.

A voluntary, nontreaty organisation founded in 1946, responsible for creating international standards in many areas, including computers and communications.

slide27

SOFTWARE ARCHITECTURE

OSI ISO model for the Internet

LAYERED SYSTEMS

  • The OSI architecture is split between seven layers:
          • 1 physical layer
          • 2 data link layer
          • 3 network layer
          • 4 transport layer
          • 5 session layer
          • 6 presentation layer
          • 7 application layer
  • Each layer uses the layer immediately below it and provides a service to the layer above.
slide28

supports designs based on increasing levels of abstraction

supports enhancement

supports

reuse

SOFTWARE ARCHITECTURE

LAYERED SYSTEMS

DESIRABLE PROPERTIES

partition problems into a sequence of incremental steps

changes to a layer affects at most two other layers

layers interchangeable provided they have same interfaces to adjacent layers

slide29

other components in the system can register an interest in an event by associating a procedure with it

When an event is announced, the system invokes all procedures that have been registered for the event

SOFTWARE ARCHITECTURE

Event based implicit invocation

in implicit invocation a component can announce (or broadcast) one or more events

AN EVENT ANNOUNCEMENT IMPLICITLY CAUSES THE INVOCATION OF PROCEDURES IN OTHER MODULES

slide30

SOFTWARE ARCHITECTURE

Event based implicit invocation

For example

a debugger will stop at a break point in the code and announce an event

this allows an editor to scroll to the appropriate source line

slide31

SOFTWARE ARCHITECTURE

Event based implicit invocation

the components in an implicit invocation style are modules

interfaces provide both a collection of procedures

and a set of events

slide32

SOFTWARE ARCHITECTURE

Event based implicit invocation

principles:

announcers of events do not know which components will be affected by those events

thus components cannot make assumptions about the order of processing

or even about processing which will occur as a result of their events

slide33

SOFTWARE ARCHITECTURE

Event based implicit invocation

application examples:

in database management systems to ensure consistency constraints

in programming environments to integrate tools

in user interfaces to separate presentation of data from applications that manage the data

slide34

SOFTWARE ARCHITECTURE

Event based implicit invocation

One important benefit:

provides strong support for reuse

Any component can be introduced into a system simply by registering it for the events of the system

can replace components without affecting the interfaces of other components in the system

this significantly eases the evolution of the system

slide35

since the meaning of a procedure that announces events will depend on the context of bindings in which it is invoked

SOFTWARE ARCHITECTURE

Event based implicit invocation

Significant drawbacks:

components relinquish control over computation being carried out in the system

after an event is announced no knowing there is ANY response

data exchange can be problematic

reasoning about correctness can be very difficult

slide36

SOFTWARE ARCHITECTURE

The goal of Software architecture is to organise and express software design knowledge in a useful form

develop a vocabulary of well-understood, reusable design concepts and patterns

These will provide the mental building blocks

and help in predicting the properties of a design

This will then reduce the number of new concepts to be learned, thus help with understanding another designer’s work

ad