Software architecture Letizia Jaccheri http www idi ntnu

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

Krav… Jeg ønsker at du fokuserer på typiske SWarkitekturer (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. 2

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

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

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

What (example) (2) 6

What (example) (3) 7

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

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. n Each view consists of components and connectors of different kind One responsible 9

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? 10

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

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

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

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

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 15

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

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

Abstraction Define a virtual machine which abstract the implementation n n 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 18

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

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

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

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

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

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