1. Slide 1 Software Architecture SSE

2. Slide 2 Typical description of software architectures l Descriptions of software systems often include a section on “the architecture of this system” l Usually informal prose plus box-and-line diagram l Lots of appeal to intuition l Little precision, rarely formal

3. Slide 3 Typical description of software architectures con ’ t l Project is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers l We have chosen a distributed, object-oriented approach to managing information

4. Slide 4 Typical description of software architectures con ’ t l 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 l The ARC network follows the general network architecture specified by the ISO in the Open Systems Interconnection Reference Manual

5. Slide 5 Objectives l Learn to design, understand, and evaluate systems at an architectural level of abstraction l After the course you should be able to recognize different architectural styles describe an architecture accurately generate architectural alternatives evaluate architectural alternatives

6. Slide 6 Aren ’ t programming languages good enough? l When orders-of-magnitude improvement is required, new technology may be necessary With a stair case one reaches the roof of a house, a seven-story building requires more, and if you want to reach the moon …

7. Slide 7 Aren ’ t programming languages good enough? l Structuring a large collection of modules to form a system is an essentially distinct and different intellectual activity from that of constructing the individual modules l Correspondingly, essentially distinct and different languages should be used for the two activities

8. Slide 8 Course outline l The course is concerned with the analysis of architectural styles Data flow architectures Procedure based architectures Object oriented architectures Event driven architectures Layered architectures Distributed architectures …

9. Slide 9 Course outline con ’ t l For a architectural style we discuss its Evolution Vocabulary Advantages Disadvantages Formal models

10. Slide 10 Course outline con ’ t l We also discuss the role of software architectures in the software life cycle: Requirements analysis Architecture reviews Architecture reuse

11. Slide 11 Placement l Programming courses Object orientation Design patterns, frameworks l Software process UML

12. Slide 12 Literature l The course is based on the following literature M. Shaw and D. Garlan, Software Architecture, Prentice Hall 1996 L. Bass, P. Clements, and R. Kazman, Software Architecture in Practice, Addison-Wesley 1998 C. Hofmeister, R. Nord and D. Soni, Applied Software Architecture, Addison-Wesley 2000 J. Boss, Product Line Architecture 2000 l and a number of articles

13. Slide 13 Software architecture l The software architecture of a program or computing system is the structure or structures of the system which comprise software components, the externally visible properties of those components, and the relationships among them l A description of the central parts of the software and their relationships on a high level of abstraction l The properties of software that concern its structure and behaviour which do not change over time

14. Slide 14 Why should one care? l Systems are getting more complex l Need for re-use l Problems with maintenance l Technologies that focus on architecture l Communications medium between different stakeholders l A basis for analysis in early stages l Helps to implement and maintain a system

15. Slide 15 Influences on the architect l Developing organisations management stakeholder Low cost, keeping people employed l Marketing stakeholder Neat features, short time to market, low cost, parity with competing products l End user stakeholder Behaviour, performance, security, reliability l Maintenance organisation stakeholder Modifiability l Customer stakeholder Low cost, timely delivery, not changes very often

16. Slide 16 Consequences of bad architectural design l System does not scale up l Poor performance l System is difficult to test l System is difficult to maintain l System is not portable

17. Slide 17 Reasons for bad architectural design l Bad communication l Unexperience l Preassure from the boss l Project organisation l Software process

18. Slide 18 Obs. about designers l They freely use informal patterns (idioms) Very informal, imprecise semantics Diagrams as well as prose, but no uniform rules Communication takes place anyhow l Vocabulary uses system-level abstractions Overall organisation (styles) Sort of components and interactions among them l They compose systems from subsystems Tend to think about system structure statically Often select organisation by default, not by design

19. Slide 19 Software architecture l The architecture of a software system Defines the system in terms of components and interactions among components Shows correspondence between requirements and elements of the constructed system Addresses system-level properties such as scale, capacity, throughput, consistence, compatibility

20. Slide 20 Software architecture l An architectural definition selects Components: define the locus of computation »Examples: filters, databases, objects, ADTs Connectors: mediate interactions of components »Examples: procedure calls, pipes, event broadcast Properties: specify info for construction and analysis »Examples: signatures, pre/post conds RT specs

21. Slide 21 Architectural design task Architecture l Interactions among parts l Structural properties l Declarative l Mostly static l System-level performance l Outside module boundary Programs l Implementations of parts l Computational prop. l Operational l Mostly dynamic l Algorithmic performance l Inside module boundary

22. Slide 22 Core ideas l Separate language for system description Domain includes modules and resources »Plus systems, if language has no closure rules Interconnection may be data or control Resources are namable entities Properties »Provide(export, synthesize) »Require(import, inherit) »Has-access-to and other ways to translate rights Separate ownership from visibility from use

23. Slide 23 Core ideas con ’ t l Static checking l Localise structural information l Version control, family control

24. Slide 24 Functions l Project management Structure first in design, consistemcy in terminology, interfaces l Design tool Establish program structure, engourage clean design l Testing and maintenance support Explicit definitions guide testing, support version control l Communication Discipline among subsystem developers l Documentation Clear, concise, formal, checkable description

25. Slide 25 BUT NOT … l Functionality, types, analysis, module implementation l Abstractions for system structures l Implementation vs. interaction

26. Slide 26 Putting SA in Context l Two main aspects of software architecture Provides a design plan (blueprint) Is an abstraction to help manage complexity

27. Slide 27 SA as a Design Plan l SA is a structural plan that describes The elements of the system How they fit together How they work together to fulfill the system’s requirements l SA is a bridge between system requirements and implementation As a design phase after the domain analysis, requirements analysisand risk analysis But before detailed design, coding, integration, and testing

28. Slide 28 SA as an Abstraction l SA should define and describe the elements of the system at a coarse granularity How do the elements fulfill the requirements Which elements are responsible for which functionality How they interact with each other How they interact with the outside world Dependencies on the execution platform

29. Slide 29 SA as an Abstraction con ’ t l The purpose of the SA is to describe the important aspects to others l The purpose is also to expose the important aspects so that the architect can reason about the system l Makes it easier to analyse trade-offs between conflicting requirements

30. Slide 30 SA terminology l Architectural style, architectural pattern Define element types and how they interact l Reference architecture, domain-specific software architecture Similar to the above, but apply to a particular domain l Product-line architecture Applies to a set of prpducts

31. Slide 31 Related terminology l Design pattern When a design pattern describes the interactions between architecture elements, it is part of SA When it describes the structure and interactions within architecture, it is part of detailed design l Framework A hybrid of architecture-level information and implementation »Architecture-level information is specified by giving a partial implementation