Software architecture
This presentation is the property of its rightful owner.
Sponsored Links
1 / 36

SOFTWARE ARCHITECTURE PowerPoint PPT Presentation


  • 96 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

SOFTWARE ARCHITECTURE

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 them

SOFTWARE 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

...


Software architecture

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


Software architecture

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"


Software architecture

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.


Software architecture

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.


Software architecture

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


Software architecture

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)


Software architecture

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.


Software architecture

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


Software architecture

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


Software architecture

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”


Software architecture

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


Software architecture

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


Software architecture

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


Software architecture

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


Software architecture

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.


Software architecture

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.


  • Software architecture

    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


    Software architecture

    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


    Software architecture

    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


    Software architecture

    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


    Software architecture

    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


    Software architecture

    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


    Software architecture

    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


    Software architecture

    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


    Software architecture

    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


  • Login