SOFTWARE ARCHITECTURE

1. 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.

2. 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.

3. 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

4. “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….

5. 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

6. 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)

7. 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)

8. 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

9. 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

10. 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”

11. 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 ...

12. 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

13. 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"

14. 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.

15. 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.

16. 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

17. 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)

18. 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.

19. 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

20. 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

21. 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”

22. 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

23. 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

24. 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

25. 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

26. 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.

27. 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.

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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