Ljubljana,2021 UsingObject-OrientedDesigntoDevelopLabVIEWComponentsofanAcceleratorControlSystem AdiSubaˇsi´c UniversityofLjubljana

(1)

Adi Subaˇsi´c

Using Object-Oriented Design to Develop LabVIEW Components of an Accelerator Control System

Master thesis

Master study program second cycle of Electrical Engineering

Mentor: prof. dr. Saˇso Blaˇ ziˇ c

Ljubljana, 2021

(2)

(3)

Adi Subaˇsi´c

Uporaba objektno usmerjenega naˇ crtovanja pri razvoju

LabVIEW-komponent sistema vodenja pospeˇ sevalnika

Magistrsko delo

Magistrski ˇstudijski program druge stopnje Elektrotehnika

Mentor: prof. dr. Saˇso Blaˇ ziˇ c

Ljubljana, 2021

(4)

(5)

development of accelerator components and allowing me to present the results in this work. I would like to thank my colleague and friend Erik who worked with me during the development of software components of this work and was very helpful and supportive during the writing process. I would also like to thank my friend Sebastian for helping to translate some parts of this work into Slovene. Finally, I would like to thank my family and friends, without whom this work would still be unfinished. Particularly in the presence of the global pandemic, the ongoing communication and encouragement really helped to preserve my motivation and keep moving forward.

v

(6)

vi

(7)

naˇcrtovanja programske opreme, hkrati pa poskuˇsamo ohraniti preglednost in razumljivost tudi za ˇsirˇse obˇcinstvo. Omenjene so tehnike naˇcrtovanja, ki se uporabljajo v programskem okolju LabVIEW, bolj podrobno pa je predstavljen pristop, ki temelji na objektno usmerjenem programiranju. V delu smo podali pregled fiziˇcnih struktur in arhitektur programske opreme sistema za vodenje po- speˇsevalnika ter kratek uvod v fizikalne osnove delovanja pospeˇsevalnika. Objek- tno usmerjena naˇcela naˇcrtovanja se uporabljajo za razvoj programskih komponent za vodenje naprav, ki nadzorujejo moˇc magnetov za usmerjanje in oblikova- nje snopa delcev, zagotavljanje moˇci pospeˇsevalnim stebrom in upravljanje snopa delcev pred zaˇcetkom pospeˇsevanja. Delovanje naprav je preizkuˇseno s simula- torji, zasnovo pa smo ovrednotili z uporabo ˇstevilnih objektno usmerjenih metrik naˇcrtovanja.

V prvem poglavju obravnavamo kompleksnost sistema in njen vpliv na razvoj programske opreme. Najprej obravnavamo kompleksne sisteme v fiziˇcnem svetu in podajamo nekatere pogosto uporabljane lastnosti za opisovanje kompleksnosti.

Poudarek je na analizi vzrokov za poveˇcanje kompleksnosti digitalnih sistemov.

Drugo poglavje obravnava razliˇcne pristope naˇcrtovanja programske opreme, ki jih je mogoˇce uporabiti za laˇzji in uˇcinkovitejˇsi razvoj programske opreme. Ana- liziramo atribute kakovosti programskih sistemov, s ˇcimer ˇzelimo doseˇci sistem naˇcrtovanja uˇcinkovite programske opreme. Na podlagi teh lastnosti kakovosti se nato uvede nekaj osnovnih pravil naˇcrtovanja programske opreme. Nato obravnavamo proces razvoja programske opreme in raziskujemo razliˇcne strategije njenega vii

(8)

viii Povzetek

naˇcrtovanja. Predstavljen je koncept programskega sloga, ki predstavlja okvir za naˇcrtovanje in razvoj, v okviru katerega lahko uporabljamo razliˇcne strategije naˇcrtovanja. Po opisu razliˇcnih pristopov k naˇcrtovanju se drugo poglavje osre- dotoˇca na objektno usmerjen slog naˇcrtovanja. Predstavljeni so osnovni elementi, ki tvorijo konceptualni okvir objektno usmerjenega modela. Kasneje podrobneje analiziramo osrednje koncepte objektov in razredov, njihove relacije in medse- bojno delovanje.

Potem sledi opis lastnosti kakovosti objektno usmerjenega naˇcrtovanja in predstavitev nekaterih vodilnih naˇcel naˇcrtovanja. Nato predstavimo moˇznosti naˇcrtovanja komponent v okolju LabVIEW. Predstavimo tudi zgodnji pristop, v katerem so bila uporabljena vodilna naˇcela objektno usmerjenega modela, ˇ

ceprav je bil razvit pred podporo objektno usmerjenemu programiranju v programskem okolju LabVIEW. Nato analiziramo konceptualni in implementacijski vidik pristopa ter predstavimo nekatere sploˇsne standarde za naˇcrtovanje programske opreme v okolju LabVIEW. Na koncu poglavja je predstavljen objektno usmerjen pristop k naˇcrtovanju v okolju LabVIEW. Analiziramo objektno usmer- jene lastnosti LabVIEW in obravnavamo razlike v primerjavi z drugimi objektno usmerjenimi programi.

Tretje poglavje predstavi osnovne pojme fizikalnega ozadja pospeˇsevalnika in podaja pregled sistema za nadzor pospeˇsevalnika. Opisane so glavne komponente pospeˇsevalnega sistema ter fizikalne enaˇcbe, ki opisujejo vedenje delcev v po- speˇsevalnih sistemih. Linearni pospeˇsevalniki pospeˇsujejo snop delcev po linearni poti. Razdelimo jih na osnovne tipe glede na naˇcin pospeˇsevanja delcev. Analizi- ramo vpliv elektromagnetnih potencialov in polj na dinamiko ˇzarka ter opiˇsemo glavne vrste magnetov v pospeˇsevalnih sistemih. Najpomembnejˇsi so upogibni (dipolni) magneti in fokusni (kvadropolni) magneti, ki spremenijo smer delcev in fokusirajo ˇzarek. Veˇcpolni magneti viˇsjega reda se uporabljajo za bolj zaple- tene pospeˇsevalnike in bolj fine nastavitve. Nato so v poglavju opisane fiziˇcne zgradbe pospeˇsevalnika, naˇcelo pospeˇsevanja in sestavni deli, ki se uporabljajo na snopu delcev. Predstavljeno je naˇcrtovano delovanje sistema za pospeˇsevanje od toˇcke vbrizgavanja delcev do izhoda pospeˇsevalnika in opisan sploˇsni namen pospeˇsevalnika. Nato v poglavju razpravljamo o fiziˇcni arhitekturi sistema vodenja za pospeˇsevanje in opiˇsemo, kje so nameˇsˇcene razliˇcne naprave za vodenje sistema, kako se vzpostavi komunikacija med njimi in kako se ukazi poˇsiljajo

(9)

v tem delu. Opiˇsemo sploˇsni pristop k naˇcrtovanju razredov in objektov ter znotraj vsake komponente in metode obravnavo napak v sistemu. Predstavljeni so naˇcini komunikacije z razvitimi komponentami, seznam operacij, ki jih je mogoˇce izvesti na vsaki od komponent, in nabor podatkov, ki jih je moˇzno pridobiti.

Prikaˇzemo postopek doseganja osnovne funkcionalnosti vsake od komponent, pri ˇ

cemer opiˇsemo izvedbo razredov in objektov, ki sestavljajo komponento. Pri vsaki od komponent posebej razloˇzimo obravnavo napak. Na koncu je predstavljen postopek preverjanja funkcionalnosti vsake komponente z uporabo simulatorjev.

V petem poglavju ocenimo izvedeno zasnovo na podlagi ˇstevilnih kazalnikov oz. metrik objektno usmerjenega programiranja. Opisana so teoretiˇcna izhodiˇsˇca in pomen vsake metrike ter formule, uporabljene pri izraˇcunih. Vsaka od teh metrik se izraˇcuna za vsako komponento posebej in za vse tri komponente kot celoto (obiˇcajno z iskanjem aritmetiˇcne sredine vrednosti posameznih rezultatov).

Nato se rezultati analizirajo z vsako metriko in oceni kakovost zasnove.

V ˇsestem poglavju vrednotimo rezultate in na podlagi ocenjenih kazalnikov ocenimo kakovost zasnove komponent sistema. Na podlagi ocenjenih kazalnikov analiziramo atribute kakovosti objektno usmerjenega sistema. Rezultati so pokazali, da je bil sistem v sploˇsnem dobro zasnovan. Sistem je modularen, ohla- pno povezan in vkljuˇcuje kohezivne razrede. Prednost opravljene analize je, da lahko razrede, ki izkazujejo ugodne kazalnike, ponovno uporabimo kot predloge za razvoj novih programskih komponent. Rezultati analize kaˇzejo na moˇznost za izboljˇsanje ponovne uporabnosti z dedovanjem na osnovi globljih dednih dreves.

Vendar ta naˇcin za trenutni sistem izvedbe sistema vodenja pospeˇsevalnika ni priporoˇcljiv, saj je zelo drag za izvedbo in ne bi bistveno pripomogel k lastnostim konˇcnega izdelka. Tudi v prihodnosti je treba pri podobnih projektih previdno pristopiti k veˇcji ponovni uporabi z dedovanjem.

Kljuˇcne besede: naˇcela naˇcrtovanja programske opreme, objektno usmerjeno naˇcrtovanje, razvoj v okolju LabVIEW, sistem vodenja pospeˇsevalnika

(10)

x Povzetek

(11)

ics readable and understandable to a more general audience. Design techniques applicable in LabVIEW are introduced and the final object-oriented approach is presented. An overview of the physical structure and the software architecture of an accelerator control system is provided, along with a brief introduction to accelerator physics. Object-oriented design principles are utilized to develop software components for regulating devices that control the strength of magnets used for directing and focusing the particle beam, provide power for the accelerating column and manage the flow of particles before the start of acceleration. The operation of the devices is tested with simulators and the design is evaluated using a number of object-oriented design metrics.

The performance evaluation of the system analyzed the object-oriented quality attributes based on the results from the design metrics. The performance results showed that the system was generally well designed. The system is modular, loosely coupled and incorporates cohesive classes. The system features usability in the form of template reuse, where new components can be developed by using the existing components presented in this work as a template. There is a potential for improvement of reusability through inheritance, which can be increased by making deeper inheritance trees. However, this avenue is not recommended for the current system as it is costly to implement and does no benefit the final product. Even in the future, for similar projects, increasing reusability through inheritance should be approached with caution.

xi

(12)

xii Abstract

Key words:software design principles, object-oriented design, LabVIEW development, accelerator control system

(13)

1.2 The Attributes of a Complex System . . . 5

2 Software Design Principles 7 2.1 Quality of Design . . . 7

2.1.1 Software Quality Attributes . . . 9

2.1.2 Quality Attributes of Software Design . . . 12

2.2 Basic Rules of Software Design . . . 15

2.3 Software Design Process . . . 17

2.3.1 Software Development Process . . . 17

2.3.2 Generic Design Process . . . 19

2.3.3 Design Strategies . . . 21

2.3.3.1 Decompositional Methods . . . 21

2.3.3.2 Compositional Methods . . . 22

2.3.3.3 Design Template and Design Reuse . . . 22 xiii

(14)

xiv Contents

2.3.3.4 Incremental and Evolutionary Strategies . . . 23

2.3.4 Programming Styles . . . 23

2.4 The Object Model . . . 27

2.4.1 Elements of the Object Model . . . 27

2.4.1.1 Major Elements . . . 28

2.4.1.2 Minor Elements . . . 31

2.4.2 Objects . . . 34

2.4.2.1 State . . . 34

2.4.2.2 Behavior . . . 35

2.4.2.3 Identity . . . 36

2.4.2.4 Relationships Between Objects . . . 38

2.4.3 Classes . . . 40

2.4.3.1 Interface and Implementation . . . 40

2.4.3.2 Relationships between Classes . . . 42

2.4.4 The Interaction of Classes and Objects . . . 51

2.4.5 Quality of Classes and Objects . . . 52

2.4.5.1 Measuring the Quality of Abstractions . . . 52

2.4.5.2 Choosing Operations . . . 54

2.4.5.3 Choosing Relationships . . . 56

2.4.5.4 Choosing Implementations . . . 57

2.5 LabVIEW Component-Oriented Design . . . 59

(15)

2.5.1.2 Information Hiding and Encapsulation . . . 62

2.5.1.3 Abstraction . . . 64

2.5.2 Component . . . 65

2.5.3 Implementation . . . 66

2.5.3.1 Message Sending . . . 67

2.5.3.2 Persistent Local Storage . . . 70

2.5.3.3 The Basic Structure of a Component . . . 70

2.5.3.4 Error Handling . . . 72

2.5.4 Style and Standards . . . 74

2.5.4.1 Block Diagram . . . 76

2.5.4.2 Front Panel . . . 78

2.6 Object-oriented Design in LabVIEW . . . 80

2.6.1 Object-oriented Features . . . 81

2.6.1.1 Access by Value or by Reference . . . 81

2.6.1.2 Constructors and Destructors . . . 82

2.6.1.3 Static Data . . . 83

2.6.1.4 Relationships . . . 83

2.6.1.5 Friends . . . 85

2.6.1.6 Function Overloading and Overriding . . . 85

(16)

xvi Contents

2.6.2 Implementation and Quality . . . 86

3 Accelerator Control System Overview 89 3.1 Introduction to Accelerator Physics . . . 89

3.1.1 Main Components of Accelerator Systems . . . 90

3.1.2 Principles of Particle-Beam Dynamics . . . 93

3.1.2.1 Maxwell’s Equations . . . 93

3.1.2.2 Lorentz Transformation . . . 94

3.1.2.3 Particle Collisions at High Energies . . . 95

3.1.2.4 Induction . . . 95

3.1.2.5 Vector and Scalar Potential . . . 96

3.1.2.6 Lorentz Force . . . 96

3.1.3 Linear Accelerators . . . 97

3.1.3.1 Electrostatic Accelerators . . . 97

3.1.3.2 Acceleration by RF Fields . . . 100

3.1.4 Electromagnetic Potentials and Fields for Beam Dynamics 102 3.1.5 Main Magnets for Beam Dynamics . . . 104

3.1.5.1 Bending Magnets . . . 104

3.1.5.2 Focusing Magnets . . . 105

3.1.5.3 Higher Order Multipole Magnets . . . 107

3.2 Physical Structure of the Accelerator System . . . 107

(17)

4 Component Development 115

4.1 General Design Approach . . . 115

4.2 Error Handling in the System . . . 118

4.3 Magnet Power Supply Development . . . 120

4.3.1 Component Communication . . . 121

4.3.1.1 Commands . . . 121

4.3.1.2 Shared Variables . . . 122

4.3.2 Driver Implementation . . . 123

4.3.2.1 Interface . . . 123

4.3.2.2 Driver . . . 125

4.3.3 Thread Implementation . . . 130

4.3.3.1 Initialization . . . 130

4.3.3.2 The Core Loop . . . 134

4.3.3.3 Termination . . . 138

4.3.4 Error Handling . . . 138

4.4 High Voltage Power Supply Development . . . 140

4.4.1.1 Commands . . . 142

(18)

xviii Contents

4.4.2.1 Interface . . . 143

4.4.2.2 Driver . . . 143

4.4.3.2 The Core Loop . . . 150

4.4.3.3 Termination . . . 153

4.5 Flow Controller Development . . . 157

4.5.1.1 Commands . . . 159

4.5.3.2 The Core Loop . . . 164

4.5.3.3 Termination . . . 166

4.6 Testing and Operation . . . 170

4.7 The Testing Process . . . 172

(19)

5.2 Performance Evaluation . . . 178

6 Conclusion 187

(20)

xx Contents

(21)

2.3 The ’V’ model of software development process [1] . . . 18

2.4 The spiral model of software development life-cycle [1] . . . 19

2.5 A general design process model [1] . . . 20

2.6 An illustration of the decompositional design strategy [1] . . . 21

2.7 An illustration of the compositional design strategy [1] . . . 22

2.8 An illustration of the incremental design strategy [1] . . . 24

2.9 Association example . . . 43

2.10 Unidirectional association example . . . 43

2.11 Single inheritance example . . . 45

2.12 Multiple inheritance example . . . 48

2.13 Aggregation example . . . 50

2.14 VI example . . . 60

2.15 An indicator of tight coupling [2] . . . 62 xxi

(22)

xxii List of Figures

2.16 An example of loose coupling [2] . . . 62 2.17 Word control VI [2] . . . 62 2.18 Word control usage [2] . . . 63 2.19 Bad information hiding . . . 64 2.20 Control Device component . . . 64 2.21 Good information hiding . . . 64 2.22 Control Device component implementation . . . 65 2.23 Component illustration [2] . . . 66 2.24 Working with enumerated type labels [2] . . . 68 2.25 The use of case structure with enumerated types [2] . . . 68 2.26 An example of a state machine [2] . . . 69 2.27 Basic component [2] . . . 70 2.28 Component states [2] . . . 71 2.29 Basic component public interface [2] . . . 72 2.30 Pass through error handling [2] . . . 73 2.31 An example of a badly made VI [2] . . . 75 2.32 An example of a crowded VI [2] . . . 75 2.33 VI description [2] . . . 78 2.34 Connector standard [2] . . . 80 2.35 Example of forking an object wire . . . 82 3.1 Principle of electrostatic accelerators [3] . . . 98

(23)

3.4 Schematic of the Wideroe linac structure [3] . . . 101 3.5 Electric-field lines in an accelerating gap [4] . . . 102 3.6 Stable (S) and unstable (U), early (E) and late (L) beam alignment

with the RF field [4] . . . 103 3.7 Pole shape of upright and skewed quadrupoles [3] . . . 106 3.8 Pole shape of upright sextupoles and octupoles [3] . . . 108 3.9 Beamline schematic . . . 109 3.10 Control system architecture . . . 110 3.11 Software architecture for the CompactRIOs . . . 112

4.1 Generic thread design . . . 116 4.2 Asynchronous thread design . . . 117 4.3 The VI that starts an asynchronous thread: Start.vi . . . 118 4.4 The VI for logging messages within threads: LogMessage.vi . . . . 119 4.5 The VI for error logging within threads: LogError.vi . . . 119 4.6 Interface to the magnet PS driver . . . 124 4.7 Structure of the interface VIs . . . 125 4.8 Structure of the interface VI that initializes the driver: Init.vi . . 125 4.9 Private data cluster of the Modbus DCPS class . . . 126 4.10 The driver VIs that initialize and close the connection with the PS 127

(24)

xxiv List of Figures

4.11 Configuring and reading the reference current of the PS . . . 128 4.12 Conversion VIs of the Modbus DCPS class . . . 128 4.13 The VI That reads the internal operating state of the PS: Read

state.vi . . . 128 4.14 Generating the register input for the Arm.vi . . . 129 4.15 Methods of the Modbus DCPS class . . . 129 4.16 The VI that reads and packages different parameters into a variant:

Parameter status.vi . . . 129 4.17 Private data of the magnet PS thread . . . 131 4.18 The VI that extracts the configuration parameters of the entire

system from a config file: ParseConfiguration.vi . . . 131 4.19 The VI that initializes parameters of the A thread parent class

and updates the configuration parameters of the MagnetPS thread:

Constructor.vi . . . 131 4.20 Cluster of data for each PS . . . 132 4.21 The VI that initializes all the connected PS and parameters of the

MagnetPS thread: Init.vi . . . 133 4.22 The VI that creates references to all the shared variables for the

selected PS of the MagnetPS thread: Create Variable References.vi 134 4.23 The VI that publishes the connection status of each PS: Publish

Connected.vi . . . 134 4.24 The main running VI that responds to recieved MagnetPS com-

mands: Run.vi . . . 135 4.25 The VI that reads the commands sent through the MagnetPS mes-

sage queue: Read PS Queue Message.vi . . . 135

(25)

4.27 Case for handling commands . . . 136 4.28 Recovering a lost connection with the reconnect command . . . . 136 4.29 Publishing status information for the connected PS . . . 137 4.30 The VI that reads all the parameters of the selected PS and pub-

lishes them to the corresponding shared variables: Publish Param- eters.vi . . . 137 4.31 The VI which prepares the MagnetPS thread to be safely closed:

Close.vi . . . 138 4.32 Closes the connection to all the shared variables of the MagnetPS

thread: Close Variable References.vi . . . 139 4.33 Handling driver connection issues . . . 140 4.34 Handling inappropriate commands . . . 141 4.35 Interface to the HVPS driver . . . 144 4.36 Structure of the VIs in the interface: Read Voltage.vi . . . 144 4.37 Private data cluster of the Fug HVPS class . . . 146 4.38 The driver VIs that initialize and close the connection with the

HVPS . . . 146 4.39 An example of a command and status method of the HVPS driver 147 4.40 Helper VIs for sending commands . . . 147 4.41 The VI that reads the names and values of the status parameters

from the device: Read status.vi . . . 147 4.42 Private data of the HVPS thread . . . 149

(26)

xxvi List of Figures

4.43 The VI that initializes parameters of the A thread parent class and updates the configuration parameters of the HVPS thread:

Constructor.vi . . . 150 4.44 The VI that initializes the connected HVPS and parameters of the

HVPS thread: Init.vi . . . 151 4.45 The VI that opens references to all the shared variables of the

HVPS thread: Open Variable References.vi . . . 151 4.46 The VI that configures the initial parameters of the HVPS: Con-

figure device.vi . . . 152 4.47 Run.vi . . . 152 4.48 Case for handling commands . . . 152 4.49 Recovering a lost connection with the reconnect command . . . . 153 4.50 Publishing status information if the HVPS is connected . . . 153 4.51 The VI that reads all the parameters of the HVPS and publishes

them to the corresponding shared variables: Publish Parameters.vi 154 4.52 The VI which prepares the HVPS thread to be safely closed: Close.vi154 4.53 The driver VI that handles and packages the errors recieved during

communication with the HVPS: Handle error.vi . . . 156 4.54 Handling connection and driver issues . . . 157 4.55 Handling inappropriate commands . . . 158 4.56 Flow controller VIs used by the thread . . . 161 4.57 Driver wrapping of the VIs . . . 161 4.58 Private data of the FlowController thread . . . 163

(27)

4.60 The VI that opens the connection with the flow meter: Open ELFLOW Connection.vi . . . 164 4.61 Configuring the device settings . . . 164 4.62 Run.vi . . . 165 4.63 Case for handling commands . . . 165 4.64 Recovering a lost connection with the reconnect command . . . . 165 4.65 Publishing status information if the flow meter is connected . . . 166 4.66 The VI that reads all the parameters of the flow meter and pub-

lishes them to the corresponding shared variables: Publish Param- eters.vi . . . 166 4.67 The VI which prepares the FlowController thread to be safely

closed: Close.vi . . . 167 4.68 The VI that handles the errors recieved from the flow meter by the

FlowController thread: Handle Device Error.vi . . . 168 4.69 Handling inappropriate commands . . . 169 4.70 The main VI used for running and testing the MagnetPS thread:

Main.vi (in the completed system every device thread is started in parallel inside the same main VI) . . . 171 4.71 Magnet PS simulator . . . 173 4.72 Magnet PS GUI . . . 173 4.73 Testing GUIs for the HVPS and flow controller . . . 174

(28)

xxviii List of Figures

(29)

4.3 Error codes for the Flow Controller thread . . . 168 5.1 Method pairs for the magnet PS thread . . . 181 5.2 Method pairs for the HVPS thread . . . 182 5.3 Method pairs for the flow controller thread . . . 183 5.4 Performance metrics for the accelerator controller system . . . 183

xxix

(30)

xxx List of Tables

(31)

Name Symbol Name Symbol

time t second s

length l metre m

mass m kilogram kg

electric current q ampere A electric charge q coulomb C

voltage U volt V

speed v - m/s

force F newton N

electric field E - V/m

magnetic flux ϕ - Vm

xxxi

(32)

xxxii List of Used Symbols

(33)

guarantee for success. Even if the system is successfully developed, the ad-hoc approach will likely make the system difficult to maintain and incomprehensible to anyone other than the original developer.

In order to develop reliable software efficiently, making a design of the software solution is essential. A good design provides a clear path to the solution, separates the complex problem into simpler and more manageable pieces, improves the efficiency of development, makes the system more adaptable to potential changes, etc. This work examines the importance of design and analyzes different design approaches and employs the object-oriented model to develop software components and demonstrate how design can be applied.

1.1 The Complexity of Software Development

Software development is an inherently complex and time-consuming process. Any given problem can have a multitude of different solutions, most of which will cause unexpected problems during the course of development. These problems are unavoidable, as Brooks suggested decades ago: “The complexity of software is an essential property, not an accidental one” [5]. Indeed, the “silver bullet” that Brooks mentions does not exist to this day; a singular approach that removes all complexity from software development. However, with the use of good design principles the complexity can be mitigated, managed and with forward planning 1

(34)

2 Introduction

potential problems can be anticipated.

Before diving into the problems of complexity plaguing digital applications, let us first analyze the nature of complexity within the physical world. Find- ing examples of complexity is relatively simple, as practically any segment of reality is capable of containing an astonishing amount of complex structures or behavior. Every living organism is composed of tiny cells containing different structures which perform separate and unique functions necessary for life. A cell can independently seek to provide all the materials needed for performing all the different operations or join multiple cells to distribute some of the responsibility.

This collection of cells can contain different specialized groups that are responsible for providing some of the different materials and distributing these materials among all the members of the collective, allowing every cell to function properly.

With enough cells, complex organisms like plants and animals are formed which are capable of achieving behavior completely unimaginable in the cellular world.

However, the desire for cooperation does not have to be the driving factor for complex systems to form. Complex systems can result from seemingly simple interactions. The gravitational interactions cause materials to collide and merge into larger objects. As these objects grow they attract more and more material. Eventually over time and with enough material, stars are born leading up to star systems and eventually entire galaxies. When observed over a long pe- riod of time, these galaxies demonstrate very complex motion, where each of the smaller elements has its own sphere of influence. Finally, complexity can easily be observed in the world of human interactions. Similarly to cells, humans can decide to form tribes and organizations to solve some of their collective problems. These communities will often choose a leader to coordinate the actions of different members and keep everyone handling different aspects of the issue they are facing. As these groups grow, different subgroups may form specializing in specific tasks. This leads to the formation of different levels of leadership which coordinate between the specialized units and the head of the community. Each of these complex systems forms a type of hierarchical structure where most interactions occur within each level of the hierarchy and between the neighboring levels.

Thus, animals have most of their interactions within their pack, planets are in- fluenced by their neighboring planets and the sun, and a person communicates the most with their immediate coworkers within a group.

(35)

principle responsible for the observed behavior. Software development on the other hand, offers no such guarantee and most of the encountered complexity is rather arbitrary [5]. Booch et al. [6] suggest that this inherent complexity of software development can be derived from four different elements: the complexity of the problem domain, the difficulty of managing the development process, the flexibility possible through software and the problem of characterizing the behavior of discrete systems.

The complexity of the problem domain contains many nonfunctional requirements in addition to the complex raw functionality the system may need to achieve. Requirements like usability, performance, reliability and cost are often implicit but can be difficult to achieve. A lot of problems are caused by the innate inability of achieving perfect communication between users and developers. Users may only have vague ideas about what the system should be and have great difficulty forming these into requirements the developers can understand.

On the other hand, the developers might create applications that realize the functionality on a technical level but are incredibly difficult to use. This is simply a result of both parties having different domain expertise and understanding relat- ing to the nature of the problem, thus making different assumptions about the solution. Additionally, the requirements often change during development as the early designs and prototypes help the user to get a clearer picture of his needs.

Ultimately, even a working software system is not truly complete, often requiring some degree of maintenance and sometimes even evolving to meet new demands.

The difficulty of managing the development process is affected by the difficulty of decomposing the problem and coordinating between different people. Modern systems can often have millions if not billions of lines of code which is incomprehensible to any single person in its entirety. Even meaningfully decomposed, a system can contain hundreds or thousands of modules. These types of systems require larger and larger teams of developers, complicating the communication and coordination aspects significantly. The greatest challenge in this process is to maintain the unity and integrity of the design.

(36)

4 Introduction

The flexibility possible through software allows the expression of any kind of abstraction to the developer. When preparing a meal for their customers a restaurant generally does not farm their own beef operating, catch their own fish, nor mine their own salt. In the software industry this is commonly the case. The software needs to be built from the ground up and with its great flexibility any kind of elementary building block can be made. However, there few standards regarding the quality of these primitive blocks and using the lower quality ones can make the whole system unstable.

The problem of characterizing the behavior of discrete systems lies in the inherent unpredictability of a system that is capable of reaching millions of different discrete states. Interacting with a physical system by, for example, throwing a ball in the field is a reasonably predictable process. It is highly unlikely that said ball will stop in midair, shoot straight down and disappear into the ground.

However, while simulating this motion in software, these type of issues can easily occur. Falling through the ground is not an uncommon occurrence even in modern real-world simulations. The discrete nature of digital systems contributes greatly to the overall unpredictability where the complex interwoven structures can propagate the error to the most unlikely of places. Generally in continuous systems, a small change in the input will cause a small change of the output ¹, while in digital systems even the smallest change has the possibility of overflowing a variable from its maximum value to its minimum value and vice versa. This is a consequence of how the data is stored in a digital system. Each type of data is represented as a combination of bits that can have only two states. Even smaller systems can easily use tens of thousands if not millions of bits. Each combination of bits represents a different state of the system and as the system grows, the number of combinations grows exponentially with a 2ⁿ growth function, making the prediction of every possible outcome for even moderately sized systems nearly impossible [6].

1There are exceptions to this assumption including unstable systems or marginally stable ones like for instance a ball on a hill. With a small push the ball can remain on top of the hill, while a slightly larger push would lead it off the mountain. This behavior can still be predicted though if given enough information about the state and environment of the ball. The presence of chaos can also make continuous systems unpredictable, like predicting the trajectories of individual air particles. However, there is an order to them in the form of attractors.

(37)

From the nature of complex systems, Booch et al. point out a number of attributes common to many of them: a hierarchic structure, relative primitives, separation of concerns, common patterns and stable intermediate forms [6].

1. Hierarchic structure: Courtois, while building on the work of Simon and Ando, states that: “Frequently, complexity takes the form of a hierarchy, whereby a complex system is composed of interrelated subsystems that have in turn their own subsystems, and so on, until some lowest level of elementary components is reached” [7]. The nearly decomposable, hierarchic structure of many complex systems may be the only reason we can understand, observe and analyze them. If a complex system without this structure exists it may be well beyond our comprehension. The detailed knowledge and calculations required to understand the interaction between its elementary parts would likely exceed both computational and storage capabilities currently available [8].

2. Relative primitives: The choice of primitive components that make up a complex system can be rather arbitrary. A primitive component for some can be a much higher abstraction for others. Therefore, primitive con- stituents are a relative concept that depends greatly on the observer. Re- gardless of how they’re defined, it is hard to imagine a complex system that cannot be in some way decomposed into more primitive elements.

3. Separation of concerns: Continuing his statement about hierarchic systems, Courtois mentions that: “In general, interactions inside subsystems are stronger and/or more frequent than interactions among subsystems” [7], suggesting a clear separation of concerns between different parts of a system.

4. Common patterns: Hierarchical systems tend to be composed of only a few different kinds of subsystems in various combinations and arrangements, as suggested by Simon [7]. Considering the fact that different complex systems can use similar or exactly the same subsystems there must exist some common patterns between them.

(38)

6 Introduction

5. Stable intermediate forms: Complex systems have a tendency of evolving over time. Starting as simple systems they evolve much more quickly if there exist stable intermediate forms which lead up to the final complex system.

(39)

and makes it easier to evaluate progress. The purpose of design, as described by Mostow, is to construct a structure which [9]:

1. satisfies a given (perhaps informal) functional specification, 2. conforms to limitations of the target medium,

3. meets implicit or explicit requirements and resource usage,

4. satisfies implicit or explicit design criteria on the form of the artifact, 5. satisfies restrictions on the design process itself, such as its length or cost,

or the tools available for doing the design.

Essentially the purpose is to ensure that both the final product and the development process itself satisfy all the necessary requirements.

2.1 Quality of Design

Software quality is an important property that must be addressed through the whole process of development but is of particular importance in the design phase.

Because it represents such an early phase of development, errors made during the 7

(40)

8 Software Design Principles

design process can be costly or even impossible to be rectified in the later stages.

Additionally, design decisions can greatly impact the quality of the final product.

While quality is certainly a concept of great importance, it can be rather tricky to define as it largely depends on the observer. Different people will have different views on what they consider to be of quality and even individual viewpoints may shift over time. In general, there are five major views on the definition of quality, identified by Garvin [10]. These include the transcendental view where quality is an innate property, both absolute and universally recognizable, but one that cannot be defined. The product-based view, on the other hand, suggests quality as a precise and measurable quantity that reflects the inherent attributes of the product. This contrasts the user-based view where quality represents how well the product meets the needs and desires of the user. The manufacturing-based view is focused on the development and construction process where quality is defined as adherence to specification, and as such, the quality assessment is virtually independent of the product itself. Finally the value-based approach suggests that quality is reflected in the performance of the product as compared to the price, where a quality product meets the user’s needs at an affordable price.

There are many quality attributes that have been identified for software prod- ucts. They are often presented in a hierarchical structure in order to highlight the relationships between them. One such example is McCall’s model of software quality which divides the attributes into three different groups: product revision, product transition and product operations [11]. This model was illustrated by Zhu [1] in Figure 2.1. These hierarchical models represent quality attributes and their broad categories in a simple manner. However, as Zhu points out, these models are unable to represent the full complexity of the relationships between the attributes. In particular, they fail to express negative relationships in which improving on one attribute will lead to a loss in another [1]. These shortcomings are addressed by relational models which compare the relationships of the attributes directly. One such model was proposed by Perry [12], who analyzed twelve pairs of quality attributes and assigned one of three different relationships for each pair. Within this model, a pair of attributes can have direct, inverse or neutral relationships. Direct pairs of variables have a positive correspondence meaning that improvement of one attribute should lead to improvement on the other, while the opposite is the case for inverse pairs. Neutral pairs are normally

(41)

Figure 2.1: McCall’s model of software quality [1]

independent from one another. Figure 2.2 shows the attributes and their relationships of Perry’s model presented in a gridlike fashion. While these models do improve on hierarchical models by showing more complex relationships between quality attributes, they have their own shortcomings. Zhu points out that these relationships are simplified to be binary and stereotypes. The model cannot express the strength of relationships between attributes and presents only a stereotypical view of how the attributes interact which does not apply to all systems. Additionally, both types of models are generic and ignore domain-specific issues. They treat all of the attributes to be of equal importance, which generally is not true for real-world systems and the importance of specific attributes may change over time [1].

2.1.1 Software Quality Attributes

Before addressing the attributes of good design it is important to explain some of the key quality attributes of the software itself which include efficiency, correctness, reliability, portability, maintainability, reusability and interoperability while discussing how different aspects of development affect each property [1].

Efficiency describes the overall responsiveness of the system or the time necessary to process a series of events. This time can be divided into three parts.

(42)

Figure 2.2: Perry’s relational model of software quality [1]

The first consists of the time required to communicate between different components required to process an event. In general good designs will try to minimize the communication between components in favor of processing internally within components as the external communication is slower and can have additional physical limitations. The second part is the time required to synchronize between different components that have overlapping execution. A good design will try to maximize the parallel execution of tasks and minimize the time spent on synchronization and waiting between components. Finally, the third part is the time spent on computation for each component. The performance here depends on the choice of data structures, algorithms, programming languages as well as the implementation itself which is outside the scope of design. The design of the interface can also affect efficiency by adding time needed for user interaction with the software, however this is less significant for efficiency when compared to other design aspects.

Correctness and reliability are two different attributes that are interconnected.

Correctness is a property that describes software that has implemented the specified user requirements and reliability as the possibility that the system performs user-requested functionality correctly in a specified environment for a given pe- riod of time. Incorrect software can never be reliable, as it does not meet the users expectation in the first place. Therefore, it is imperative that design at every level correctly implements the specified requirements otherwise it would be impossible

(43)

issues down to specific code and implementation errors. A good architectural design will decompose a complicated problem into simpler sub-problems with an understandable solution to the whole problem, thus reducing the error probability made as part of lower-level design and implementation. The well-structured design also helps to make testing easier ensuring that more faults are found and fixed. Another important aspect is the interface design, as human operation errors constitute a large proportion of software failures [1].

Portability is the attribute that describes how difficult it is to transport the system from one hardware or software platform to another. This transportation usually requires replacing aspects of the code which require platform-specific features, like system calls for example. Well-designed software will try to compart- mentalize and minimize the number of components with environment dependent code, avoiding a high dependency on platform-specific features in the design of the algorithms and data structures as well as the interface.

Maintainability describes the ease of performing maintenance on a software system. It consists of corrective maintenance where software is modified to correct bugs and adaptive maintenance where modifications are made in response to environmental changes like software system upgrades. Good designs help en- gineers to understand the system, thus making it easier to fix issues and respond to changes. The most important aspect in this regard is the architectural design.

Reusability is an attribute that describes how easily the components of the software system can be used for developing other systems. It depends on the generality of the components and the extent to which they’re parameterised and configurable. Architectural design plays a major role here, as it determines how the components are organized and interconnected. Detailed design also plays a role as the choice of algorithms and data structures determines how easily components can be parametrised and made configurable.

Interoperability describes how easy it is to use the software solution with other software systems. For example, the interoperation of a video editing system and a

(44)

video hosting service requires that the edited video content can be exported into a format supported by the hosting website. This attribute mostly depends on the interface between the software system and the environment which requires that implementation adheres to certain interface standards and coding conventions and has little to do with architectural or detailed design [1].

2.1.2 Quality Attributes of Software Design

In order to identify which attributes describe good design it is important to consider the objective of the design itself. As mentioned previously, the goal is to produce a good software system and ensure the quality of development.

Therefore, quality is usually described either from the product-based or process- based point of view. From the product-based side, Witt, Baker and Merritt have proposed the following design objectives which can be considered as attributes [13]:

1. Modularity: The design should be composed of replaceable, self-contained assemblies of elementary parts, thereby aiding both the initial development and the later maintenance.

2. Portability: Individual parts of the design, as well as the design as a whole, should be capable of reuse in different environments. When the designed product is moved from a test environment to an operational environment or moved between operational environments, it should still work properly.

3. Malleability: The design should facilitate adaptation to changing end-user requirements. The user might uncover new problems or a need for additional information that was not previously expected or included in the original specification. This property is also widely known as flexibility or modifiability.

4. Conceptual integrity: The design should exhibit harmony, symmetry and predictability. The system should appear to reflect the mind of a single person, and to faithfully adhere to a single concept. There should be no surprises for its users or its maintainers; knowledge gained in one use or change should be immediately transferable to the next.

(45)

to be under intellectual control if it is deeply understood by those responsible for its correctness, regardless of its complexity. This attribute does not relate either to the product or the development process, but is rather a quality attribute of the design process itself. As such it is more of a guideline for good design rather than a measurement of it.

Another set of attributes from the product view are proposed by Parnass and Weiss. They stated that a design should be [14]:

1. Well structured: The design should be consistent with chosen principles, such as the principle of information hiding.

2. Simple: To paraphrase a statement often attributed to Einstein, the design should be as simple as possible, but no simpler.

3. Efficient: The functions provided by the design should be computable with the available computing resources, and the design should not interfere with meeting space and time requirements.

4. Adequate: The design should satisfy present requirements.

5. Flexible: The design should make it as easy as possible to respond to requirements changes.

6. Practical: Module interfaces should be sufficient for the job, neither providing unneeded capability nor requiring the user to perform functions that properly belong to the module being used.

7. Implementable: The functions offered by the design should be theoretically computable with the information available.

8. Standardized: The design should be represented using a standard organization for design documentation.

(46)

Most of these attributes are related to the quality of the product, with only one being concerned with the development process. The aspects of design related to the development process are usually studied under different subjects like process models, risk and configuration management, the economics of software development. These subjects can focus on a different aspect of development or view the process from a different scope, but the attributes are still important for software designers. A number of these attributes were described by Zhu [1]:

1. Feasibility: The designed process of bringing about the product should be executable.

2. Simplicity: The production (i.e., the development) of the designed software should be as simple and straightforward as possible without unnecessary complication.

3. Manageability: The development process should be easy to manage, for example, enable managers to check the progress against the schedule.

4. Quality product: The designed development process should lead to a software system of the required quality.

5. Reliability: The designed development process should with high probability be successful rather than fail to achieve its goal.

6. Productivity: Following the designed development process, software engi- neers should be able to work productively.

7. Time to market: Following the designed process, the software is developed within the required time to market.

8. Risk: The development process should have a minimal risk, i.e., the lowest probability of failure and the minimal consequences if it fails.

9. Resourcefulness: The designed process should use resources economically and with the minimal cost.

10. Technical requirements: It refers to the degree and extent to which the designed process relies on expensive equipment and tools and requires in- tensive training to obtain the required technical skills for the people to develop the system.

(47)

12. Legitimacy: The development process and the product should be allowable according to law and conformant to applicable standards and regulations.

13. Environment friendliness: The development process should cause minimal harm to the environment, such as pollution.

These types of attributes are affected by many additional factors including the organization’s production and resource capabilities, time limitations, hardware and software availability, etc.

2.2 Basic Rules of Software Design

With the understanding of the difficulties of software development and the qual- itative attributes of software we can arrive at some basic design rules which can then be expanded in different methodological approaches. In their book, Witt et al. have presented a few statements which aim to explain why a certain principle can lead to a good design. These statements were listed as axioms and consist of [13]:

1. The axiom of separation of concerns: A complex problem can best be solved by initially devising an intermediate solution in terms of simpler independent problems. This statement implies that the simple intermediate problems need to collectively solve the original one. The simple problems must also be mostly independent as significant dependencies between them may only serve to complicate the original problem. The axiom also implies that the solution to the simpler problems needs to be found, but this concern is separate from the simplification of the main problem.

2. The axiom of comprehension: The mind cannot easily manipulate more than seven things at once. This axiom stems from the discovery in psy- chology from the 1950s, known widely as the “Rule of seven plus or minus

(48)

two”, which asserts that humans have a natural limit on short-term mem- ory and can only keep track of seven (plus or minus two) random numbers in mind [15]. While the extent to which this discovery applies to software design is unclear, the general assertion is that we as humans can easily be overwhelmed by large numbers of independent bits of information.

3. The axiom of translation: Design correctness is unaffected by movement between equivalent contexts. This axiom suggests that a correct design that fulfills the requirements in one environment will continue to do so in a new environment if the new environment provides the same services.

Similarly, a program tested in a simulated environment during development should have similar performance in the real environment if the simulated environment is accurate.

4. The axiom of transformation: Design correctness is unaffected by the replacement of equivalent components. This axiom asserts that a completed design with several components will continue to meet its requirements if one of its components is replaced as long as the replacement meets the interface and behavior requirements of the original component.

These axioms highlight the separation of concerns and abstraction as two powerful tools for overcoming complexity in software design. To effectively use them Witt et al. have proposed five design principles that correspond to their design objectives mentioned in Section 2.1.2. These principles include [13]:

1. The principle of modular designs: Modularity can be achieved by dividing large aggregates of components into units having loose inter-unit coupling and high internal cohesion, by abstracting each unit’s behavior so that its collective purpose can be known, by recording each unit’s interface so that it can be employed, and by hiding its design so that it can be changed.

2. The principle of portable designs: Portability can be achieved by employing abstract context interfaces.

3. The principle of malleable designs: Malleability can be achieved with designs that model the end-user’s view of the external environment.

(49)

5. The principle of intellectual control: Intellectual control can be achieved by recording designs (after developing a design strategy) as hierarchies of increasingly detailed abstractions.

In relation to these principles Zhu proposed an additional one in order to address the difficulties in software design caused by invisibility [1]:

6. The Principle of visualization: Visibility can be achieved (or partially achieved) by representing designs in visual notations such as diagrams, pic- tures and figures, etc. to express the characteristics of the behavior of system components and the relationships between the components.

2.3 Software Design Process

The process of software design consists of a wide range of activities, each of which performs a certain action, involves different participants, processes input information and outputs the result of the activity. In order to describe these activities and the relationships between them a process model is used. We will first take a look at a generic design process and then focus on the design of software systems.

2.3.1 Software Development Process

Before explaining the general process model, we need to consider the context in which these design activities take place within the wider context of software development. For this purpose, two different models of the software development process will be considered.

Figure 2.3 shows the ’V’ model of software development, which represents an industrial standardized version of the ’waterfall’ model. With this model each

(50)

Figure 2.3: The ’V’ model of software development process [1]

aspect of development is performed linearly one after another until the system is built, tested and operational. Within this context, the input to the design phase includes the functional and non-functional requirements, while the output provides the software architecture and module design which describes the components of the software. This is then used by programmers to implement the modules, then later by testers to perform testing of the software.

Figure 2.4 depicts the spiral model of the software development life-cycle. In contrast to the ’V’ model, the actions here are performed in a cyclical manner where similar activities are performed in each stage building on the results of previous stages. Firstly, in each stage the objectives are identified, the options and constraints are explored, followed by risk evaluation between these options and finally a plan is made which determines how to proceed to the next stage possibly including the development of a prototype.

Both of these models separate the design process into the architectural and detailed design phase. Architectural design is concerned with structural issues of software design an includes things like the organization of a system, the as- signment of functionality to components, the choice of global control structures,

(51)

Figure 2.4: The spiral model of software development life-cycle [1]

selection of protocols for communication, synchronization and data access, etc.

While the detailed design is focused on the choice of data structures and algorithms which are needed to implement the functionality of each system component, but it also addresses the details of the user interface, input/output formats and other issues related to the implementation. This work puts more emphasis on detailed design and the aspects which relate to the design of the components, while touching on some architectural design ideas.

2.3.2 Generic Design Process

A generic design process, shown in Figure 2.5, is based on a model from Budgen’s textbook [16] extended by Zhu with activities for producing multiple solutions and their comparison. It shows the key activities of the design process to be [1]:

• postulating a number of solutions,

• building a model of each solution,

(52)

Figure 2.5: A general design process model [1]

• evaluating the models against the original requirements,

• comparing the validated solutions and selecting one for further development,

• elaborating the model to produce a detailed specification of the solution in the form of a ‘blueprint’.

The model highlights the iterative nature of the design process. When developing a design solution new constraints can be discovered, which leads to the postulation of another solution that accounts for the new constraints. This postulation is then followed up with evaluation and revision. These three processes are repeated iteratively until the evaluation shows that the design satisfies all the requirements. Model building is a key step here, as it allows the evaluation of each design solution. It is possible to perform the postulation, evaluation and revision of many different designs in parallel, which could create multiple validated designs. At this point the designer would then pick the most appropriate design for further development. This approach with multiple solutions allows the designer to test different design approaches and choose a style that best suits the problem. However, it is not always necessary to make multiple designs, as a designer might already have a preferred style for the project.

(53)

Figure 2.6: An illustration of the decompositional design strategy [1]

2.3.3 Design Strategies

As model building represents a major part of the design process, many different strategies have been developed to guide it. The well-known strategies include:

decompositional, compositional, template-based and evolutionary strategies.

2.3.3.1 Decompositional Methods

Decompositional methods approach the design problem from the top-down perspective. This strategy, as illustrated by Figure 2.6, starts with the original description of the problem. The original problem is then decomposed into simpler sub-problems which are solved separately. If a sub-problem is still too complex it is further decomposed until its components become simple enough to be directly solvable. Finally, the solutions of the sub-problems are composed and form the solution of the original problem. A typical method that uses the decompositional strategy is stepwise refinement from structured programming [1].

(54)

Figure 2.7: An illustration of the compositional design strategy [1]

2.3.3.2 Compositional Methods

Compositional strategy, depicted in Figure 2.7, starts the model building process by identifying a set of elements or objects related to the problem. These elements are described, classified and grouped together, while relationships between them are identified and formed within each group. The groups are called components of the model and are further classified and bigger groups are formed. The relationships between components are then established to make even bigger components and the process continues until a complete model is formed. Compositional design strategy is used in Jackson’s structured programming (JSP), object-oriented design and other methods [1].

2.3.3.3 Design Template and Design Reuse

Researching certain types of problems in a specific domain over a number of years, one can discover a great many similarities between effective solutions. Abstracting these similarities into a design template, assuming it is possible, makes future attempts at solving the same type of problem relatively trivial. Using a design

(55)

[1].

2.3.3.4 Incremental and Evolutionary Strategies

One of the most basic approaches to all designs involves the use of trial and error.

In this process a design is created and evaluated based on the requirements. If all the requirements have not been met, the design is altered and a new design is made. This process of creation and evaluation is repeated until a sufficient design is reached. However, there is no guarantee that this will ever happen.

For better results, a systematic approach is needed. This starts by making a design that satisfies only the most basic and important requirements. The design is then tested on other requirements and modifications are made to meet the unsatisfied requirements while preserving the required attributes that have been met. This strategy is called evolutionary design and a typical example of its use is program transformation.

Another form of evolutionary design involves careful analysis of the requirements and is called incremental design. Figure 2.8 shows this design process, which involves finding groups of requirements that can be satisfied without im- pacting the other groups. Then a solution is developed which satisfies one of these groups of requirements, which is incrementally expanded to cover more groups of requirements [1].

2.3.4 Programming Styles

A programming style was defined as “a way of organizing programs on the basis of some conceptual model of programming and an appropriate language to make programs written in the style clear” by Bobrow and Stefik [17].

During software development, programmers tend to opportunistically switch

(56)

Figure 2.8: An illustration of the incremental design strategy [1]

(57)

Similarly, in regards to way-finding, Kato and Takeuchi found that participants with a good sense of direction used more effective strategies and were more flexible to changing strategies [19]. It was also observed by Green et al. that programmers do not generate code sequentially [20], nor examine a file sequentially while trying to understand a program, as described by Mosemann and Wiedenbeck [21].

This process of moving through the source file is called software navigation.

Both selection and change of strategies, software navigation, choice of programming language and other factors have an influence on programming style.

Many of these factors were studied by Cox and Fisher as part of a contextual framework [22]. They concluded that numerous individual factors play a role in a programmer’s style and that the programmer’s behavior ca not be modeled without considering the situation and the task at hand. Nevertheless, Bobrow and Stefik suggest that programming styles can be separated into five main categories [17]:

1. Procedure-oriented: The style is based on the use of algorithms. The two separate primitive elements of this style are data structures and subroutines.

The code is primarily composed of subroutine calls. The subroutines are able to carry out the same algorithm regardless of where they’re called from and can reference the data structures. It’s also possible to create modules that represent a collection of subroutines and procedures whose elements can be described by interfaces.

2. Object-oriented: The base of this style is the object which combines both state and behavior. Each object can hold data, receive/send messages from/to other objects and form different relationships with other objects.

A lot of the challenge of this style lies in structuring and organizing the various objects and establishing effective interactions between them.

3. Logic-oriented: The style is often expressed in predicate calculus where goals are achieved by checking from a database of logic statements. These logic statements assert rules that the actors within follow, the most basic

(58)

of which is a relationship (e.g., John [Actor 1] is a brother [relationship]

of Andy [Actor 2]). The system can then be queried to find if a new logic statement is valid (Is George a brother of Andy?) or to find all actors who fulfill a new statement (Who are Andy’s brothers?). The system will then search extensively through all the rules from the database to find the answer to the query. This style of programming completely separates statements from the goals, allowing new methods to be added without the need to change the goal statements, but also making it difficult to understand the system’s behavior.

4. Rule-oriented: This style is used to support the building knowledge bases and it is based on if-then rules. Rule-based development environments are able to generate explanations for program behavior, answer questions as well as acquire and integrate new rules into the knowledge base. They are able to process uncertain information which is not usually the case for logic- based systems. Their ability to provide explanations of results, by keeping track of which rules have been invoked gives them an additional advantage over logic-based systems.

5. Constraint-oriented: This style uses the concept of constraint satisfaction where programmers only need to declare certain relations among variables, without specifying the details on how to achieve them. The system then uses implicit, automatic constraint satisfaction techniques to calculate the answer (ex. the relation x+y = 10 can be viewed as a constraint, the relation is then tested based on other constraints forx, yvariables). These types of systems have always been specialized to exploit specific types of constraints and as such they have not been considered general purpose.

Naturally these style types can only be used in programming languages that support them. While some languages may support multiple styles, few if any support all of them.

(59)

The object-oriented paradigm has had the widest appeal in recent years. The style is centered around the idea of objects which Stefik and Bobrow defined as

“entities that combine the properties of procedures and data since they perform computations and save local state” [23]. Each object represents an instance of a class that might have inheritance relationships with other classes. The class defines the types of data an object can hold and the methods that can be applied to it.

The process of developing software in this paradigm consists of three parts: object-oriented analysis (OOA), object-oriented design (OOD) and object- oriented programming (OOP). Object-oriented analysis and design (OOAD) can be performed together or separately and represents aspects of the compositional design strategy shown in Figure 2.7. Object-oriented analysis is a method that examines the requirements in the context of classes and objects and generates a conceptual model of a system focusing on the functional requirements. The object-oriented design then takes the analytical model and refines it with consid- eration for implementation constraints [24]. Finally, object-oriented programming uses the design model as a blueprint to implement the whole system.

2.4.1 Elements of the Object Model

Each style of programming is based on its own conceptual framework. Booch et al. pointed out four major and three minor elements of this model [6]. For a model to be considered object-oriented it must include all of the major elements.

The major elements are:

1. abstraction, 2. encapsulation, 3. modularity, and 4. hierarchy.

(60)

The minor elements are useful, but not an essential part of the object model.

They are:

1. typing,

2. concurrency, and 3. persistence.

2.4.1.1 Major Elements

Abstraction Abstraction is one of the key tools people use to handle complexity. It was given the following definition by Booch et al. which combines several different viewpoints: “An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer” [6]. Ab- straction allows us to take an external view of an object and thus separates its essential behavior from the implementation. This separation was named the abstract barrier by Abelson and Sussman and is formed by applying the principle of least commitment where the interface of an object provides only the essential behavior [25]. Booch et al. suggest adding an additional principle called the principle of least astonishment with which an abstraction would capture the entire behavior of an object and offer no surprises beyond its scope [6].

Encapsulation Abstraction and encapsulation are complementary concepts.

While abstraction focuses on the external object behavior, encapsulation captures the implementation which enables the behavior. This is often achieved through the process of information hiding, where all the details which do not contribute to the objects essential characteristics are hidden. This includes hiding both the internal structure of an object, as well as the implementation of its methods.

Encapsulation thus creates distinct boundaries between different abstractions, ensuring that no part of the system depends on the internal details of another part [26], and leads to a clear separation of concerns.