1. 1 Software architecture Letizia Jaccheri http://www.idi.ntnu.no/~letizia /swarchi-2001.ppt

2. 2 Krav… Jeg ønsker at du fokuserer på typiske SW- arkitekturer (f.eks to-lags, tre-lags og fler- lags klient - tjener arkitektur, web-arkitektur,....) og mellovare (f.eks corba) som brukes for å "lime" komponentene i arkitekturene sammen. Fint om du kan si noe om fordeler og ulemper med de forskjellige arkitekturene. Jeg ønsker en mest mulig praktisk vinkling slik at studentene kan få direkte nytte av forelesningen i de løsningene de lager i forbindelse med Kundestyrt prosjekt.

3. 3 Structure Software Architecture What/Who Examples and exercises Software Architecture How Examples and exercises Conclusions

4. 4 What (definition) Software architecture of a software system is a set of structure descriptions. Each description gives a view of the system in terms of components and connections between components.

5. 5 What (example) One view of a system So called 3-tier architecture

6. 6 What (example) (2)

7. 7 What (example) (3)

8. 8 Middleware Method invocation (java,.net, etc.) Queues (java, microsoft, etc.) Corba Http

9. 9 Exercise Define/Draw two / three structural views about your system. For each view, provide alternatives and try to list advantages and disadvantages with the different solutions. Each view consists of components and connectors of different kind One responsible

10. 10 How Which are the forces which drive architecture definition? How to obtain a software architecture? How to analyse a software architecture? How to change a software architecture?

11. 11 Some answers Styles dataflow, call-and-return, independent component, data-centered, object oriented Patterns 23 patterns in Gamma Operations Separation, abstraction, compression, resource sharing Qualities Technology features and constraints Java, microsoft (.net), corba,

12. 12 Qualities (Non functional requirements) Performance Maintenability Usability Security Reuse Availability

13. 13 Performance How much communication among components (architectural) What functionality has been allocated to which components (architectural) Choice of algorithms (not architectural) How algorithms are coded (not architectural)

14. 14 Modifiability How functionality is divided. A system is modifiable if changes do not involve a large number of distinct components. It is the quality attribute most closely aligned to the architecture of the system Extending or changing capabilities Deleting unwanted capabilities Adapting to new operating environments Restructuring (see product line, reuse)

15. 15 Usability Learnability Efficiency Memorability Error avoidance Error handling Satisfaction (does the system make the user’s job easy?) Many aspects of the quality of usability are not architectural

16. 16 Qualities Observable via execution Not observable via execution: how easy is the system to integrate, test, and modify?

17. 17 Separation Split functionality (parallelism for performance) Aggregation Is-a

18. 18 Abstraction Define a virtual machine which abstract the implementation Emulate functionality which is not native Layered systems Common interface to several implementations Add a layer to a single user system in a way it becomes multi user

19. 19 Compression Remove layers and/or interfaces. It is the opposite of separation. SE traditionally against it. Improve performance Eliminate layering which does not add needed services Speed development.

20. 20 Resource sharing Encapsulate data and/or services and make it sharable among different components Database Blackboard Tool integrator/bus Enhance integrability

21. 21 Abstrac tion Compr ession Part- whole decom positio n Is-a decom positio n Replica tion Resour ce sharing Scalabil ity + System modifia bility +-++ Integra bility +-+++ Portabil ity +- Sequen tial perfor mance -+---

22. 22 Abstracti on Compres sion Part- whole decompo sition Is-a decompo sition Replicatio n Resource sharing Concurre nt performa nce -+++ Fault tolerance + + Ease of system creation +-++ Compone nt modifiabil ity +-- Ease of compone nt creation +++ Reusabilit y +-+

23. 23 Exercise Everybody changes group (not the responsible). The responsible explains the architecture to the other and receive feedbacks and comments. Try to apply one or more operations. Suggestions for change/improvement are recorded. I keep your architectures, you can access them if you like.

24. 24 Conclusions Reason about your system, communicate decisions about your systems, work with alternatives designs Styles, patterns, technological issues, SIF8056 Programvarearkitektur