Covariance

Software Architecture

Bertrand Meyer

ETH Zurich, February-May 2009Lecture 1: IntroductionChair of Software Engineering1Software architectureThe architecture of a software system is its structure and the documentation of that structure

#2Software architecture questions (examples)Software architecture answers questions such as:What are the modules (components) of this system?How are properties of a module known to developers?What kinds of relation exist between the modules?Should an inter-module link be replaced by a link of another kind (e.g. client inheritance)?How do modules A and B communicate?How does the structure of system X differ from that of system Y?How easy is it to adapt to adapt the structure to a change in requirements?#3Software architecture is notAlgorithms, Data structures(Except if they affect some of the previousproperties)Implementation techniquesSoftware documentation (except on structural aspects)Hardware considerations (except if they affect some of the previous properties, e.g. because of concurrency)#4Software architecture techniquesModularizationReuse techniquesAbstraction techniquesInformation hidingDesign patternsArchitectural styles (pipes, filters, )

#5Goal of the courseIntroduce you to the techniques of building large software systems of high quality, in particular:ReliabilityExtendibilityReusability

This includes in particular: Principles of software qualityObject technology principles and methods; the practice of object-oriented analysis, design and implementationDesign patternsPrinciples of building reusable softwareSome key techniques of concurrent programming#6Seven key topicsModularity and reusability

Abstract Data Types

Design by Contract and other O-O principles

Design Patterns

Software architecture styles

Component-Based Development

Introduction to concurrency

#7Practical information#8Course materialCourse page:http://se.inf.ethz.ch/teaching/2009-S/0050/ Check it at least twice a week

Lecture material:Lecture slides Textbook (see next):Object-Oriented Software Construction, 2nd edition -- Prentice Hall, 1997Available from Polybuchhandlung ( CHF 63 with Legi)

Exercise material:Exercise sheetsMaster solutions#9Recommended booksBertrand MeyerObject-OrientedSoftware Construction

Prentice Hall, 1997

#10Electronic forums Discussion forums:Inforum:http://forum.vis.ethz.chMailing list for each group Usual advice and rules:Use the forums and mailing lists! Take advantage of every help you can get.Dont be shy. There are no stupid questions.Criticism welcome, but always be polite to every participant and observe the etiquette.To email the whole teaching team (professor and assistants): soft-arch-assi@se.inf.ethz.ch #11Exam: end of semesterTuesday, 26 May 2009, 14-16 (normal class time) 2-hour examNo material allowed

Covers all material in the semester

#12Teaching staff#13Bertrand MeyerE-mail: Bertrand.Meyer@inf.ethz.chOffice: RZ J6Secretary: Claudia Gnthart, (01) 632 83 46#14Software Architecture

Bertrand Meyer

ETH Zurich, March-July 2009A basic architecture exampleChair of Software Engineering15Our first pattern exampleMulti-panel interactive systems

Plan of the rest of this lecture:Description of the problem: an exampleAn unstructured solutionA top-down, functional solutionAn object-oriented solution yielding a useful design patternAnalysis of the solution and its benefits#16A reservation panelFlight sought from:To:Depart no earlier than:No later than:18 Mar 2006Choose next action:0 Exit1 Help2 Further enquiry3 Reserve a seat18 Mar 2006Santa BarbaraZurichERROR: Choose a date in the future

#17A reservation panelChoose next action:0 Exit1 Help2 Further enquiry3 Reserve a seatAVAILABLE FLIGHTS: 2Flt# LH 425Dep 8:25Arr 7:45Thru: ShanghaiFlt# CP 082Dep 7:40Arr 9:15Thru: Hong Kong

Flight sought from:To: Depart no earlier than:No later than:18 Mar 200918 Mar 2009Santa BarbaraZurich#18The transition diagramHelpHelpInitialFlight_querySeat_queryConfirmationReservationHelpHelp112332222333111111#19A first attemptA program block for each state, for example:PFlight_query:

display enquiry on flights screenrepeatRead users answers and his exit choice Cif Error_in_answer then output_message enduntilnot Error_in_answerendprocess answer

inspect Cwhen 0 then goto PExit when 1 then goto PHelp ...when n then goto PReservation end#20Whats wrong with the previous scheme?Intricate branching structure (spaghetti bowl).

Extendibility problems: dialogue structure wired into program structure.

#21A functional, top-down solutionRepresent the structure of the diagram by a function transition (i, k)

giving the state to go to from state i for choice k.

This describes the transitions of any particular application.

Function transition may be implemented as a data structure, for example a two-dimensional array.#22The transition function0 (Initial)1 (Help)2 (Confirmation)3 (Reservation)4 (Seats)5 (Flights)0123ExitExitExitExitExitReturn234500234#23The transition diagramHelpHelpInitialFlight_querySeat_queryConfirmationReservationHelpHelp11112332222333111115243#24New system architecture execute_session initial transition execute_state is_final display read correct message processLevel 3Level 2Level 1#25New system architectureProcedure execute_session only defines graph traversal. It knows nothing about particular screens of a given application;it should be the same for all applications.execute_session -- Execute full session. local current_state, choice : INTEGER do current_state := initial repeat choice := execute_state (current_state) current_state := transition (current_state, choice) until is_final (current_state) end end#26To describe an applicationProvide transition function Define initial state

Define is_final function#27Actions in a stateexecute_state (current_state : INTEGER ): INTEGER-- Execute actions for current_state ; return users exit choice.localanswer : ANSWERgood : BOOLEANchoice : INTEGERdorepeatdisplay (current_state )[answer, choice] := read (current_state )good := correct (current_state, answer )if not good then message (current_state, answer ) enduntilgoodendprocess (current_state, answer )Result := choiceend#28Specification of the remaining routinesdisplay (s ) outputs the screen associated with state s.

[a, e] := read (s ) reads into a the users answer to the display screen of state s, and into e the users exit choice.

correct (s, a ) returns true if and only if a is a correct answer for the question asked in state s.

If so, process (s, a ) processes answer a.

If not, message (s, a ) outputs the relevant error message.

#29Going object-oriented: The law of inversionHow amenable is this solution to change and adaptation? New transition? New state? New application?

Routine signatures:

execute_state (state : INTEGER ): INTEGERdisplay (state : INTEGER )read (state : INTEGER ): [ANSWER, INTEGER]correct (state : INTEGER ; a : ANSWER ): BOOLEANmessage (state : INTEGER ; a : ANSWER )process (state : INTEGER ; a : ANSWER )is_final (state : INTEGER )#30Data transmissionAll routines share the state as input argument. They must discriminate on it, e.g. :

display (current_state : INTEGER ) doinspect current_state when state1 then ...when state2 then ...when staten then ...endend

Consequences: Long and complicated routines. Must know about one possibly complex application. To change one transition, or add a state, need to change all.#31The flow of controlUnderlying reason why structure is so inflexible: Too much DATA TRANSMISSION.

current_state is passed from execute_session (level 3) to all routines on level 2 and on to level 1

Worse: theres another implicit argument to all routines application. Cant define

execute_session, display, execute_state, ...

as library components, since each must know about all interactive applications that may use it.#32The visible architecture execute_session initial transition execute_state is_final display read correct message processLevel 3Level 2Level 1#33The real story execute_session initial transition execute_state is_final display read correct message processLevel 3Level 2Level 1statestate#34The law of inversionIf your routines exchange too much data,put your routines into your data.

In this example: the state is everywhere!

#35Going O-OUse STATE as the basic abstract data type (and class).

Among features of every state:

The routines of level 1 (deferred in class STATE )

execute_state, as above but without the argument current_state

#36Rearranging the modules by data abstractionsSTATE execute_sessionLevel 3Level 2Level 1 initial transition execute_state display read correct message process is_final#37Class STATEdeferred classSTATE featurechoice : INTEGER-- Users selection for next stepinput : ANSWER-- Users answer for this stepdisplay -- Show screen for this step.deferred endread-- Get users answer and exit choice, -- recording them into input and choice.deferredensureinput /= Voidend#38Class STATEcorrect : BOOLEAN -- Is input acceptable?deferredendmessage -- Display message for erroneous input.requirenot correctdeferredendprocess -- Process correct input.requirecorrectdeferredend#39Class STATE execute_state localgood : BOOLEANdofromuntil good loopdisplayreadgood := correctif not good then message endendprocesschoice := input.choiceendend#40Class structureSTATE*INITIALFLIGHT_QUERYRESERVATIONexecute_state +display +read +correct +message +process +display +read +correct +message +process +display +read +correct +message +process +display *read *correct *message *process *#41To describe a state of an applicationWrite a descendant of STATE :class FLIGHT_QUERY inheritSTATEfeaturedisplay do ... endread do ... endcorrect : BOOLEAN do ... endmessage do ... end

process do ... endend#42APPLICATIONRearranging the modules by data abstractionsSTATE execute_sessionLevel 3Level 2Level 1 initial transition execute_state display read correct message process is_final#43Describing a complete applicationNo main program but class representing a system.

Describe application by remaining features at levels1 and 2:

Function transition.State initial.Boolean function is_final.Procedure execute_session.

#44Implementation decisionsRepresent transition by an array transition : n rows (number of states), m columns (number of choices), given at creation

States numbered from 1 to n; array states yields the state associated with each index

(Reverse not needed: why?)

No deferred boolean function is_final, but convention: a transition to state 0 denotes termination.

No such convention for initial state (too constraining). Attribute initial_number.#45Describing an applicationclassAPPLICATION createmake

feature

initial : INTEGER

make (n, m : INTEGER )-- Allocate with n states and m possible choices.docreate transition.make (1, n, 1, m )create states.make (1, n )end

feature {NONE } -- Representation of transition diagram

transition : ARRAY2 [STATE ]-- State transitionsstates : ARRAY [STATE ]-- State for each index#46The array of statesSTATES (ENQUIRY_ ON_FLIGHTS) (ENQUIRY_ ON_SEATS)(INITIAL)(CONFIRMATION)(RESERVATION)12345A polymorphic data structure#47Executing a sessionexecute_session-- Run one session of applicationlocalcurrent_state : STATE-- Polymorphic! index : INTEGERdofromindex := initialuntil index = 0 loop

current_state := states [index ]

current_state.execute_state

index :=transition [index, current_state.choice ]endendDynamicbinding#48Class structureSTATE*INITIALFLIGHT_QUERYRESERVATIONexecute_state +display +read +correct +message +process +display +read +correct +message +process +display +read +correct +message +process +display *read *correct *message *process *#49Other features of APPLICATIONput_state ( s : STATE; number : INTEGER )-- Enter state s with index numberrequire1