graphical control interface for 3g radio base stations - kth · pdf filegraphical control...

Graphical Control Interface for 3G Radio Base Stations

T O B I A S H Ä R D E M A N

Master of Science Thesis Stockholm, Sweden 2006

Graphical Control Interface for 3G Radio Base Stations

T O B I A S H Ä R D E M A N

Master’s Thesis in Computer Science (20 credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2006 Supervisor at CSC was Henrik Eriksson Examiner was Stefan Arnborg TRITA-CSC-E 2006:029 ISRN-KTH/CSC/E--06/029--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.csc.kth.se

Graphical control interface for 3G radio base stationsAbstractNodeB Integrated Test Environment (NITE) is a program used by testers at Ericssonwhen verifying Radio Base Station (RBS) funcionality. The program is beingdeveloped by Ericsson’s own employees and is to replace the currently used LabVIEWenvironment.

The Graphical User Interface (GUI) of the program has not been able to keep upwith other parts of NITE. It is starting to get much too complicated for developersto implement new functionality in the GUI and therefore the program cannot beused to its full potential. The goal for this project was to develop a completely newinterface for NITE so that it could keep up with the rest of the system. It should beeasy for developers to implement and change functionality. The GUI was to receivea face-lift in terms of look and feel in the process as well, the current graphics leavesmuch to be desired.

Some prerequisites for a scalable and dynamic solution to be achievable were foundalong with some pit-falls. At the time of the master’s project’s completion the GUIwas not completely finished. Some implementation still remains but when this isdone the new GUI should be a much more pleasant experience for both the usersand developers of NITE.

Grafiskt styrinterface för 3G radiobasstationerSammanfattningNodeB Intergrated Test Environment (NITE) är ett program som används av testarepå Ericsson för att verifiera Radio Base Station (RBS) funktionalitet. Programmetutvecklas av anställda på Ericsson och är menat att ersätta LabVIEWs nuvarandetestmiljö.

Programmets Graphical User Interface (GUI) har inte hållit jämna steg med deandra delarna i NITE. Det börjar bli alldeles för komplicerat att implementera nyfunktionalitet i GUI’t och därför kan inte programmet nyttjas till sin fylla kapacitet.Målet för detta projekt var att utveckla ett helt nytt gränssnitt för NITE så attdet ligger i fas med resten av programmet. Det skulle vara enkelt för utvecklareatt implementera och ändra funktionalitet. Under denna process skulle GUI’t ävenfå en ansiktlyftning gällande utseénde och känsla, den nuvarande grafiken lämnarmycket att önska.

Några förutsättningar för att en dynamisk och skalbar lösning skall vara möjlighar identifierats liksom några fallgropar. När detta projekt var slutfört var inteGUI’t helt färdigt . Lite implementation kvarstår men när denna är genomförd såborde det nya GUI’t vara en mycket mer behaglig upplevelse för både användareoch utvecklare.

AcknowledgementsFirst of all I would like to thank my supervisor at NADA, Henrik Eriksson. Hehelped me during the entire project with any questions raised along the the way.He also proofread the entire report even though it is not required for the supervisorto do this. Secondly, I must thank Fredrik Fornstad at Ericsson who made thismaster’s thesis possible. He helped me in finding a suitable assignment and wasalso responsible in making Ericsson hire me to carry it out. Graham Crowe andJohannes Jansson at Ericsson helped me with everything NITE related. BitteIsaksson, guidance counselor at my institution, has helped me with everythingadmnistrative needed during my entire time at KTH in general and the master’sthesis in particular.

Contents

1 History 11.1 3G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Ericsson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Radio base stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 NITE 72.1 Hardware environment . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2 Software architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.1 Hardware layer . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2.2 Command layer . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 Service layer . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.4 Application layer . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.5 User layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Finite State Machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4 Strengths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5 Shortcomings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6 The near future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3 Assignment 193.1 Requirements and ideas . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 The approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Graphics 234.1 The look of yesterday . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Toolkits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 The look of tomorrow . . . . . . . . . . . . . . . . . . . . . . . . . . 27

5 Architecture 335.1 Rules and recommendations . . . . . . . . . . . . . . . . . . . . . . . 345.2 Finding solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.2.1 Code repetition . . . . . . . . . . . . . . . . . . . . . . . . . . 365.2.2 Knowledge intensive . . . . . . . . . . . . . . . . . . . . . . . 375.2.3 Decentralised . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2.4 Static log parsing . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.2.5 Non standardised test environment . . . . . . . . . . . . . . . 41

6 Error handling 436.1 Lack of reason . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2 Errors explained . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7 Results 457.1 Look and feel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2 Scalability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.3 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

8 Future improvements 49

9 Conclusions 519.1 Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 519.2 All in all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Bibliography 53

Chapter 1

History

Telecommunication is omnipresent in our lives today, from making a simple telephonecall to browsing the Internet. What began in the 19th century with the demonstrationof the telegraph has now advanced into the 21st century with the possibilities ofhigh speed data communications, video conferencing etc. During recent years thetelecommunications industry faced a new challenge with the introduction of the thirdgeneration mobile network in the mainstream market. This represents a relativelynew field for the developers and is, even today, ever changing. Companies have ahard time keeping up with new functionality and rigorous testing has to be carriedout in order to make sure that old functionality is maintained and improved. Duringall of this, Ericsson [1] has managed to keep their key role both as a market resellerand technological entrepreneur.

Today, the word telecommunication can refer to a vast amount of different things.Everything from telegraphs to Internet connections and cable TV is containedwithin this concept and it is constantly growing in terms of new technologies andimplementations.

It all started during the 1830’s when Gauss and Weber developed a small scaletelegraph system in Gottingen [2]. The technology was developed and introducedfor practical use by Morse when in 1844 he set up a 40 mile long telegraph connectionbetween Washington DC and Baltimore. The next step in this development camewith Alexander Graham Bell and Thomas A. Watson and the invention of thetelephone, a technology implemented by the Bell Telephone Company in 1878 whena switching office was installed in New Haven, CT. Things started to pick upspeed and a lot of progress was made in the following years with the inventionsand introductions of things like man-made radio waves, automatic circuit switches,wireless telegraph systems and the first commercial radio telephone service, operatingbetween the US and Britain from 1927.

Regular telephony was being implemented at a large scale over Europe and North

1

1.1. 3G

America and the development of telephone network was aimed towards more mobilesolutions. The PCM (Pulse Code Modulation) technique had already been inventedand was to become the basis for digitized voice transmission and in 1946 the firstcar-based mobile telephone was set up in St. Louis. Soon to follow were two seminalpapers published by Claude Shannon on data compression and error detection andcorrection. After these major advancements, the race for the future was on.

During the 1950’s and 60’s a lot of new technologies were taken into use. Amongothers the first mobile systems for the police, the first modem using FSK (FrequencyShift Keying) and the launch of the first communication satellite, Telstart. Followingthis was the launch of several communication satellites as well as the standardisednumbering system for area codes and the likes. One of the single most importantlaunches during this period was that of ARPANET by DARPA and BBN, whichwas later to be developed and introduced as the modern Internet.

The mobile networks were breaking new ground as well with the introduction of theNMT mobile network and later on the GSM mobile network in 1991. These newtechnologies were to revolutionize the way people thought on communication andinteraction since they had a whole new world at their disposal. Services such as beingreachable almost anywhere and sharing information with the help of SMS (ShortMessage Service) made people adopt these new technologies in a quick fashion.Alongside these mobile network developments there were constant speed increaseswhen it came to Internet connections and other means of communication. Thetelecommunications industry saw the need for a new technology that meant vastspeed increases for the mobile user as well, hence the idea for the third generationmobile network was born.

1.1 3G

During the period of 1991 through 1995 two research projects were started, CodeDivision Test-bed (CODIT) and Advanced Time Division Multiple Access (ATDMA).These two projects were aimed at investigating the stability of wide-band CodeDivision Multiple Access (CDMA) and Time Division Multiple Access (TDMA)based radio access technology for 3G systems. This work became the basis for thefurther development of 3G technologies [3].

In December 1996 the Universal Mobile Telecommunications System (UMTS) Forumwas established in Zürich, Switzerland. It was actually the planned "European"WCDMA standard that was to be known as WCDMA. After this things startedprogressing at a much quicker rate and frequency band allocations were made inregards to the UMTS standard as well as some trial attempts at using this newstandard. In 1998 the first actual call from a WCDMA terminal was made atNokia’s Research And Development unit near Tokyo, Japan.

2

1.2. ERICSSON

After these initial efforts had been made the 3GPP was launched in Copenhagen,Denmark, and the first meeting of the 3GPP technical specification group soonfollowed in Sophia Antipolis, France. At this time governments that were membersof the European Union (EU) were required by the European Parliament and Councilof Ministers to prepare for a coordinated and progressive introduction of UMTSservices no later than the 1st of January 2002.

In 1999 Nokia claimed to have made the first WCDMA call through the publicswitched telephone network from their test center in Finland, something shortlyfollowed by Finland giving out the first WCDMA licenses to telephone operators.Radio interfaces for third generation mobile networks were approved by ITU atthe same time as Ericsson and Qualcomm shared access to each others technology,ending a two year patent dispute. In April 1999 NTT DoCoMo announced whichsuppliers had been chosen to deliver equipment for their next-generation wirelessnetwork, the first announced WCDMA infrastructure deal. Among the supplierswere Ericsson, which later in 2001 together with Vodafone UK claimed to havemade the first WCDMA voice call over the public network.

In October 2001, nine months later than the planned release in January 2001,DoCoMo launches the first commercial WCDMA 3G mobile network. This isfollowed by a large scale introduction of WCDMA networks throughout Europe,among others Telenor launched its WCDMA network in Norway on the 1st ofDecember 2001. There was a shortage of mobile phones operating in UMTS modeduring this time and the first product came from Motorola in February 2002 andwas named A820. Nokia later claimed to have produced the world’s first handsetfor WCDMA and GSM networks, the 6650.

In October 2002 Ericsson announced the milestone of 10 000 commercial WCDMAmacro base stations shipped and in January 2003 conducted the first demonstrationof Internet Protocol version 6 (IPv6) over 3G WCDMA. Handset manufacturers,such as Samsung, soon showed mobile phones with the ability to display colorTV while system developers showed speeds of up to 9 Mbps in the WCDMAnetworks with the help of High Speed Downlink Packet Access (HSDPA). HSPDAis a packet-based data service in WCDMA downlink available since 3GPP Release5 specifications.

1.2 Ericsson

What role did and does Ericsson play in the development of these new technologiesapart from the involvement already mentioned. It all began in a small telegraphequipment repair shop at Drottninggatan 15, Stockholm, which was started by LarsMagnus Ericsson and his associate Carl Johan Andersson in 1876, coincidently the

3

1.3. RADIO BASE STATIONS

same year as Bell filed a patent application for the telephone [4]. Bell telephones arereleased in the next year and following this Ericsson starts selling improved versionsof these phones in the shop. The business grew and soon Ericsson had sold his firstswitchboard in Sweden, followed by landing major contracts in Oslo, St.Petersburgand Gävle. Ericsson started to produce handsets and in 1889 telephone numbertwenty thousand left the Ericsson factory.

The year 1894 marked the registration of the LM Ericsson’s trademark and the logowas the 1892 telephone. In 1896 LM Ericsson converted to joint stock companynamed LM Ericsson & Co. A year later the first foreign manufacturing operationopened in St.Petersburg and three years Ericsson was active on several continents,such as Europe, Africa and North America. In the next thirty years Ericssoncontinues to grow and also enters new markets, such as railway systems. LarsMagnus Ericsson dies in 1926.

Ericsson maintains its successful development and in 1956 the six millionth phonefrom Ericsson is sold. When the first mobile network was taken into operationduring the 1960’s the market leaders started to invest more time and money intonew mobile technologies and in 1977 the first NMT field trials were carried out.NMT nets were taken into operation all over the world but was soon to be succeeded,the beginning of this marked by the forming of the Standardisation Groupe SpecialMobile (GSM). In 1983 Ericsson opens a new mobile telephone laboratory in Lund,changes its logo and the LM Ericsson trademark is changed to Ericsson. Later inthe 1980’s telephones became a separate business unit within Ericsson and the firsthand-held mobile phone for the NMT 900 net is produced. At the end of the decadeEricsson had 30 percent of the US cellular systems market, was to contribute to thedesign of the Japanese digital mobile system (PDC) and had a joint venture withUS based General Electrics to handle mobile telephones worldwide.

GSM takes more and more market shares from NMT but is soon to be followedby the next generation mobile technology, WCDMA. At the end of the century theWCDMA standard, largely developed by Ericsson, is adopted by ETSI and proposedto the ITU as a world standard. Ericsson also starts developing the blue-toothtechnology and the blue-tooth consortium is founded and takes about 50 percent ofthe orders for GPRS. Up until today Ericsson is still in absolute top when it comesto developing new technologies and improving already existing systems. Ericssonare pioneers in the fields of HSPDA and fourth generation mobile network.

1.3 Radio base stations

Regardless if you consider GSM or WCDMA systems there are Radio Base Stations(RBS) present in the infrastructure, not to be confused with masts. Masts arefreestanding structures used to transmit and receive radio waves while an RBS is

4


Figure 1.1. Relative sizes of different cell types

a site that enables mobile phones to work properly. RBS can come in a varietyof sizes and shapes and can be customised for placement on rooftops, the ground,street lamps etc.

A mobile telephone is a low-powered two-way radio that converts sound and datainto radio waves for transmission to the nearest RBS. The waves are then transmittedover the main telephone network to the desired destination. In order for the phoneoperators to cover a desired area it is split into several cells. In the center of eachcell an RBS is placed in order to get coverage in that area. The zones also overlap tomake sure that there are no "dead" areas. The three types of cells are macro-cells,micro-cells and pico-cells. Their relative sizes can be seen in Figure 1.1. Macro-cellsprovide the main coverage for the network while micro-cells increase the capacityin user-dense areas, such as crowded areas in major cities. Pico-cells are mostlyused within buildings where there is bad coverage or a lot of users; airports, trainstations and shopping centers. The cells used in 3G systems are smaller than inprevious networks due to the higher radio frequency used. These cells are alsomore dynamic in the sense that they can expand and contract to accommodate thecurrent amount of users, this means that the cells in 3G have to overlap more thanbefore. The RBS can be called the heart of the system and stable operation istruly a vital part if you want a good infrastructure in the net. This means that thesystem manufacturers put a lot of money into making the base stations stable and

5


effective in order for them to gain advantages in the market. This also means thatmost of the development in the network is aimed towards the RBS, new software aswell as new hardware is constantly being manufactured. When new technology isintroduced into the systems they have to be tested thoroughly and this constitutesa large part of the system developers work load. Since the number of users inthe 3G networks are increasing steadily there is little room for failure, the existingcustomer base will not accept lesser functionality than at present. This meansthat new functionality has to be implemented without impeding the performanceof already existing services.

6

Chapter 2

NITE

As mentioned before a lot of effort is put into implementing new and improving oldfunctionality in the RBS. Whether the test is integration, verification, regression orsomething else there has to be an efficient way of testing in order to maintain lowcosts. Due to the extent of testing being performed the costs could easily become a realproblem. At Ericsson the tester is presented with two different options when it comesto working against the RBS, LabVIEW [5] and NITE. LabVIEW has been used formany years in the Ericsson organisation but doubts have been raised concerning itsusability and that started the development of NodeB Integrated Test Environment(NITE).

When a new piece of hardware or new software is to be taken into use by theoperators in the field, extensive testing has to be carried out in order for themanufacturers to be sure of its functionality. There is very little room for anymistakes as this could mean major down-time for the operators and consequently,noticeable economic losses. But since the 3G systems are relatively new there area lot of technical advancements that need to be made in order for the systemproviders to stay on top of the game. This means that in spite of a stable systemthat is in use you have to constantly introduce new factors which can contributeto the destabilisation of the system. In other words, testing is one of the mostimportant aspects when it comes to seamlessly merging new technology with aworking infrastructure.

At Ericsson software created with LabVIEW has been used when doing regressiontests etc. There are a lot of different programs that need to be used in parallel inorder for the tester to be able to perform the necessary commands on the RBS. Oneof the concerns raised during recent years was that of LabVIEW’s learning curve -you have to aquire quite a lot of experience before being able to perform any actualtesting. Most of the time you had to maintain several advanced programs at oncewhile running simple tests. Some of this critique is said to have its explanation inthe fact that the software was developed by people who had not worked as tester

7

at Ericsson. They simply could not tailor the program to the needs of the testersbut rather followed a fixed specification, and even though the requirements weremet maybe the program was not that tester friendly. Even so, the program is reallypowerful and useful with regards to featusoores and advanced control of the RBS.The flaws are there even if it had to be rather complex when it comes to performingsimpler tasks.

Another major thing that needed improvement was that of automated testing, theprograms in LabVIEW did not support this functionality in any significant way.There are a lot of different tests defined within Ericsson that are to be run ondifferent hardware and software configurations to ensure their functionality. Thesetests have to be performed whenever a fix or something is introduced in the basestation to ensure that no previous functionality is lost as well as ensuring that thegoal of the introduction was achieved. A lot of the testing could be performed in anautomatic way by batching these scripts and selecting an RBS to run them againstand by doing so, money could be saved. This functionality is highly desirable foroperators and manufacturers since it could take a lot of work of the testers andincrease efficiency.

The thought of NITE was born. It started out as an enthusiast project by GrahamCrowe who grew tired of the shortcomings of the LabVIEW test environment – hewanted something that was as powerful but without the difficulties. He then beganwork on a new testing tool that was later to be named NodeB Integrated TestEnvironment (NITE). The program was written in Python [6] and at first GrahamCrowe was the sole maintainer. Work continued for almost a year and then aworking system was emerging from this development work. During the summer of2004 the program could be used to perform tests against the base station but itwas still console based, something that needed change. So at that time I was hiredto develop a functional Graphical User Interface (GUI) for NITE, something thatwould encourage the testers to make use of this new environment. The developmentof both the engine and GUI of NITE was at this time developed rather ad-hoc inthe sense that new functionality was thought up at a daily basis and needed to beimplemented into the environment within a couple of days.

Substantial progress was made with NITE in the following months, although theactual code left a lot to be desired. As new functions were implemented and time wasof importance a lot of code was copied and little thought was put into scalabilityand maintainability. This posed no problem at the time since there were onlytwo people working on the program and they both knew how things worked. Theprogram grew, and with it the code, and the environment was growing into a realalternative to LabVIEW’s counterpart. The GUI was now in place and the enginehad a lot of the necessary functions to perform base station testing.

After this a snowball effect began as the users started using NITE for their testing,

8

2.1. HARDWARE ENVIRONMENT

it didn’t take long for the program to grow out of its original suit. More peoplestarted to participate in the development of NITE and with this the code needed tobe improved. The need for standards arose as new functionality had to be added ascheaply as possible. The dependencies were all over the place in the early days andbecause of this implementing new functionality took a lot of effort. In the followingyear effort was put into improving NITE’s engine. Progress was made and an APIwas developed along with a structure that was followed by the different parts ofthe program. The program became more scalable in terms of the system and newfunctionality could be implemented more easily.

NITE is constantly growing, both in terms of functionality and users, and improvementsare made to the system. The general idea is that NITE is to take over more ofLabVIEW’s areas of use. Whether or not it is to take over as the sole testingenvironment cannot be said as of today, the systems will probably live alongside fora long time. The increasing number of NITE users increases the demands on theprogram and developers are constantly keeping this in the back of their head.

However, even though the system has improved considerably lately the GUI is stillbehind. The code has been growing with the functions of the system but no efforthas been made when it comes to making the GUI scalable or easy to maintain.This recently changed as it needed to be easier to implement the new features ofthe engine into the GUI. It also needed to look more modern and stylish in orderfor it to be more presentable and appealing to the user.

2.1 Hardware environment

The test environment used when testing the RBS is defined by the hardware availableto the tester while performing different tests. There is a lot of different hardwarethat can be used by the tester depending on the different test cases requirements.The central from where everything is controlled is the users terminal which runsNITE. This workstation needs to be able to control a vast amount of differenthardware at once in order for the environment to represent the field scenario to betested. Some of the equipment is truly advanced and new hardware is being addedall the time. A graphical representation of a simple environment can be seen inFigure 2.1.

As an example, the RBS can have several different combinations of software versionsalong with a lot of different Rural Automatic Exchange (RAX) boards, used forswithcing, among other things. So, there are several setups possible for the RBSalready because of this component. And there are others. Along with the RBSthere has to be a Radio Network Controller (RNC) simulator present in order tocontrol the base station. In real world scenarios the RNC handles a number of basestations connected to it and routes calls, handles data and keeps track of available

9

2.1. HARDWARE ENVIRONMENT

Figure 2.1. NITE test environment hardware and communication protocols

channels. In this test environment however the RNC-sim is used to control the RBSin the way the user requests. Some tests also need a User Equipment (UE) simulatorthat simulates mobile phones setting up calls, sending packet data etc. There aredifferent types of UE simulators available today and new ones are being developed.Measuring equipment can also be used in conjunction with this environment. It canbe placed in different places in accordance with the desired measurement.

All of the communication in the system is IP-based, connections are made on anIP-level to different hardware. The tester sets up NITE to reflect the environmentto be tested, with different parameters in the software that is. The environmenthas to be set up correctly with simulators connected to the right hardware as well.Testers have their own physical system set up in the laboratory and therefore needto make the changes to their RBS for it to apply to a certain test case. When all ofthese premises are put together it means that each tester needs to keep track of andmake changes in three different places. The idea for the future is to make the testpositions less stale and instead have the testers book the test environment neededfor each specific test.

10

2.2. SOFTWARE ARCHITECTURE

Figure 2.2. NITE’s software layer architecture and examples of what is included ineach.

2.2 Software architectureThe architecture of NITE is layered and there is a set of rules that the system issupposed to be designed around, see Figure 2.2. This is found to be more truewhen looking at newer parts of the program. The different layers are not supposedto communicate directly with a non-adjacent layer, meaning that communication isto pass through all layers in between two layers wishing to communicate. It couldbe restricted even more by saying that layers only know how to make calls to layersthat are directly adjacent, although this is not entirely true in NITE. Some of theolder parts still make use of layers further away from them, this is something thatis meant to be changed and lots of work has been put into this.

2.2.1 Hardware layerThe lowest layer in the system is the hardware layer which contains the physicaldevices that are to be controlled. Here you find the RBS, RNC and UE simulator.The communication used here is mainly decided by the manufacturers of the equipmentand even if this manufacturer is Ericsson, it is made by another department. Thereforethe NITE developers can only follow the already established protocols.

As mentioned before it is this layer that defines the test environment for the user and

11

2.2. SOFTWARE ARCHITECTURE

has to match the required environment stated in a test case. NITE is also supposedto import modules only for the hardware present in the system in order to gainmaximum performance and user-friendliness by removing features not available.

2.2.2 Command layerAbove the hardware layer is the command layer. This layer in the system isresponsible for setting up the different connections necessary to control the system,most of which are regular telnet connections. This layer functions as a glue betweenthe software system on the testers computer and the hardware environment availablein the lab, as the name indicates its main task is to control the hardware.

2.2.3 Service layerThe service layer of NITE is responsible for the translation of the human readablemessages sent from the application layer into a format readable by the hardwarewhen sent by the command layer. This layer is the smallest in NITE but one of themore complicated to actually comprehend due to the different standards in differenthardware.

2.2.4 Application layerThe application layer is the most comprehensive in the NITE architecture andcontains a lot of different classes that are used to represent and communicate withthe different hardware available. With the help of the different instances of theseclasses along with the user layer the testers can control the environment in thedesired way. This layer is where most of the work has to be done when it comes toupgrades and the likes.

Every instance in this layer implements a Finite State Machine (FSM) class andsets up the correct states in order for the control of the system to be consistent,more on this later.

2.2.5 User layerThe topmost in this system is the user layer which gives the tester the possibilityto control the test environment present. This report focuses mainly on this layerand the work carried out was meant to improve the performance and workings ofthe Graphical User Interface (GUI).

Actually, there are three parts to this layer; the GUI, the text UI and the scripts-mode available to the user. The GUI part is pretty straight-forward in its description,it is a graphical interface presented to the user offering control over the environmentas well as information on the system. The UI works in the same way with theexception that it is console based. The reason is that it is used when running

12

2.3. FINITE STATE MACHINE

Figure 2.3. Overview of how NITE functions with the help of Finite State Machinesand a Message Queue. The supervisor thread that is to be implemented is in the figureas well.

scripts and it also facilitates simple tests for newly added features etc.

The script mode could be seen as a separate part in the system but is insteadconsidered a part of the user layer. There are scripts available today but the systemfor running these is not as useful as it could be. The main reason for the use ofscript mode is that you can run a predefined series of events, a batch of scripts,when new software or hardware needs to be tested. This is made a lot easier withthe help of scripts since expected results can be defined in the same easy way asyou control them. A batch of scripts can be run over-night and by that the costsof labour can be minimised and the efficiency of tests maximised. This is a verypowerful and welcome feature of NITE that has a high priority.

2.3 Finite State Machine

Earlier in this report it was said that each of the classes in the application layer usesan FSM to make sure that the system and the calls within are consistent. No illegaltransitions can occur in the system and this ensures that the system is as stableas possible. The general idea behind this system, besides providing stability, is tomimic the behaviour of most telecommunications hardware which is state machine

13

2.4. STRENGTHS

based. The system is queue-based and similar methods are often used when real-time is important but not decisive. A simple representation of this idea can be seenin Figure 2.3.

Since a queue is present in the system, all calls to an instance generate an eventto be carried out in the queue. This queue is First In First Out (FIFO) and allof the messages have the same priority. The concurrency and synchronisation ofthe system is further ensured by the use of a run to completion method used bythe queue. What this means is that each message in the queue runs until finishedand then the next one gets its turn, this in opposition to other techniques such asRound Robin where each object in the queue gets a predefined time-slice and thequeue is looped instead.

So the flow of the program is user layer, message queue and then the state machinetransitions. The choice of using blocking or non-blocking functionality in themessage queue exists, blocking meaning that a certain response has to be receivedbefore the next message can be processed and carried out. There is also thepossibility of running the program in debug mode in which the state machinesand the queue are kept track of more closely. If something goes wrong you get astack-trace and stack-dump readout.

Surrounding all of this is a watchdog thread meant to oversee that no errors occurwithin the message queue or FSMs. If this happens the watchdog will make sure thata fatal error results in either a clean exit from the program or a warning being sentto the supervisor thread of the UI, which handles it accordingly. The functionalityfor this is not fully implemented yet but plans have been made for the future.

2.4 Strengths

NITE is still a fairly young program in terms of man-hours spent on the project.It is just recently that the software group grew into a team of full-time developers.Though the program has its share of flaws the most appealing aspect of NITE isthe underlying potential. The program is being developed by people who knowthe environment in which the tests are to be performed. They know about thedifferent procedures often used in RBS testing, what information is relevant todisplay in different situations and what flexibility is needed in order to make thetesting as efficient as possible. This was not the case when the software environmentwas developed in LabVIEW since an external company was hired to develop thedifferent tools. As mentioned before the program lacks some functionality and it isunnecessarily difficult to use when it comes to some of the more simple functionality.

The software provided by NITE supports most of the equipment today and thesupport for new hardware is added in a simpler way when being introduced into the

14

2.5. SHORTCOMINGS

test environment. There is support for common hardware, such as the RBS and MSsimulator, as well as some newer features such as HSDPA. But the main advantageis that it is easier to adapt the environment to hardware and software introductions,new features, bug reports etc. This is due to the fact that the software is maintainedfrom within the labs; the people using and the people developing NITE are locatedwithin the same department in Ericsson, they are often very close geographically aswell. Tester can go directly to the development team and ask if something is notworking the way it is supposed to and problems can be resolved in a shorter periodof time, although a Trouble Report (TR) still has to be filled in.

As mentioned earlier emphasis is being put on the script part of the program,something that is expected to increase productivity in a major way in comparisonwith how it works today. The plan is that a batch of scripts are queued to berun on a specific machine whenever something is to be tested. So there could bepredefined tests that are to be run in order for Ericsson to make sure that the RBSpasses a regression test. What this means is that the testing will get more and moreautomated and the actual input or interaction from the tester is kept to a minimum.If successful, this would yield an extreme upswing in the test procedures, reducingtest costs for Ericsson.

Summary of strengths in NITE:

• Developed by the same (kind of) people that use it

• Easy to operate

• Support for new hardware and software is fast

• Developed from within the company

• Script mode

2.5 ShortcomingsDespite a good idea and two years in the making, NITE has its share of flaws. Thedevelopment team has grown over time and they brought new ideas of softwareengineering into the project. There was also a lack of standards, something thatshowed as the program grew over time. A lack of time, or rather a too tightlyplanned release schedule, influenced the environment in a non-positive way, quantitywas preferred over quality so to speak. New functions had to be made available allthe time, thus inducing the developers to produce "quick and dirty" code instead ofthe slower and more thought through code.

The above, eventually led to decay in code quality. It became hard to introducechanges in the system; if one part was fixed another one broke instead. A sort of

15

2.5. SHORTCOMINGS

catch 22 introduced itself into the system. Fixes or functions were not generic andintroduced more errors than they resolved. The main problem in the layers belowthe UL is that of inconsistency. Information to be used is not structured in a neatway and some of the functions do not follow the same syntax as the rest of thesoftware. The GUI is also to hard to update, mainly due code repetition. Not muchthought has been put into reuse of the code, something that in particular makesthe GUI part unnecessarily huge. Adding new functions is a major hassle and thistends to make the GUI out of date. Some functions are even implemented only inthe console user interface in order to test or make use of them.

One thing that leaves you wanting more from the GUI is the look and feel ofit. As the interface is based on Tkinter [7] and this is an old graphical toolkit theGUI unfortunately inherits the shortcomings of the toolkit. Since NITE is to befavoured over the current LabVIEW environment it is important that the testersthink of it as a newer alternative and not a step backwards. As NITE is a risingstar it has to be presented to executives on a regular basis, funding for the teamcomes from above. This aspect is not to be ignored when producing software, inthe end you always need funding. In order for the developers to be able to make anappealing presentation there is no room for old looking software. The more strikingthe presentation, the more resources is put into NITE - a reversed catch 22. Thisleads us to the conclusion that updating the look and feel of the program should beone of the main focuses in this report. NITE has to achieve a more modern look.

Negative scenarios in the system have to be handled in a neater way, whether it beintentional negative testing or an error occurring in the software. There is no actualsoftware support for these kind of things and NITE might just hang and crash forno apparent reason, from the testers point of view at least. Having a python traceas your only clue to what went wrong is seldom the ideal scenario if you are nota developer but rather a user. And as hinted above, sometimes you want to trythings that should not work in the hardware just to see how it is handled. Thereis some functionality for this in the underlying layers of NITE but it is not used asintended yet, more on this later.

Everything that is available to the user when using LabVIEW is not implemented inNITE yet. A lot of the basic functionality is present and the testers can choose NITEover LabVIEW for many test cases. However, when it comes to more advanced testcases or when something out of the ordinary has to be performed, in the RBS orRNC-SIM especially, the tester has no choice but to revert back to LabVIEW. Thetask of implementing every function found in LabVIEW into NITE is an on-goingone, new functionality is announced on a regular basis. In some cases, concerning allnew hardware and software, NITE even has the edge over LabVIEW and supportsthese introductions on an earlier stage than LabVIEW. This report does not reallytake into account the process of making NITE as able as LabVIEW in terms offunctions since this does not affect the suggested general improvements. On a side

16

2.6. THE NEAR FUTURE

note, this could be as important or even more important than updating the lookand feel of the program when it comes to the future success of NITE.

There are some minor errors, found to be tolerable, present in NITE as well. Thingsthat fall in this category would be considered rare in their extent or non-critical intheir severity. An example of such a bug is that if you restart the environmentseveral times without restarting NITE the software might become unstable. Asthese bugs do not affect the systems architecture etc, they are not to be handled inthis report.

Summary of weaknesses in NITE:

• Lack of standardisation

• Stale environment

• Code repetition

• Look and feel of GUI

• Error handling

• Lack of functions

• Minor issues

2.6 The near futureWhen the entire situation is considered the future of NITE looks bright. Thereare things that need to be worked out but the potential is greater than that ofLabVIEW it seems. So what could be predicted in the near future then.

Even today NITE is considered the first choice among several of the testers, themajor shortcoming being that of absent functionality. As more things are found inboth LabVIEW and NITE, the tendency is that of the tester favouring the latter.The general idea behind NITE was to make a more versatile and intuitive interfacefor the tester. If this is achieved a lot of money could be saved by Ericsson dueto the fact that tests could be performed in a faster manner without reducing thequality of the tests.

If the trend continues and NITE expands into being the preferred tool for testers,regardless of the task at hand, the system will expand in a more rapid fashion.This will be true at least for the initial stage in which a lot of people will beconcentrating on making all functionality from LabVIEW available as well as takingcare of the bugs. The main point to note is that a larger group will be involved in thedevelopment of NITE. But then a standardised way of developing and implementing

17

2.6. THE NEAR FUTURE

code must be used. Otherwise the program will become unmaintainable and eventuallyvirtually useless as that it will be impossible to introduce changes in the system.

18

Chapter 3

Assignment

As mentioned in previous sections the GUI part of NITE has its share of discrepancies.The main reason for this master’s project to be carried out was to fix and improvethe GUI as presented above. The task given was to make the GUI function properly,be easy to extend and basically look good. A side track to all of this was that ofmaking the GUI as platform independent as possible.

One of the things found in the section regarding weaknesses was that of coderepetition and inconsistencies in the GUI. The energy here should be concentratedon creating a new architecture for the GUI, and perhaps the system, that allowedfor reuse of existing code instead of repetition. A general way of implementing newfeatures in the GUI has to be present as well.

The GUI has to appeal to both managers and testers in terms of graphics andlayout. This means that an alternative to the Tkinter graphical toolkit used todayhad to be found.

The last part of the assignment was to improve the stability, and therefore theprogram’s error handling. This task was considered a low priority and was only tobe carried out if possible within the time frame given.

3.1 Requirements and ideas

There were requirements on what the GUI needs to be able to do and some generalideas. Together they make up the base for the implementation to be carried out.

The program should be able to record scripts from the users interaction with theGUI so that these "recordings" can be used as a base for building automated testscripts. This makes it easier for testers to depict the wanted test case and reducesthe need for programming skills among the testers. This is more a matter of callingfunctions in the right manner since the functionality for this type of recording is

19

3.2. THE APPROACH

already present in NITE.

You should be able to operate NITE with a mouse alone. The keyboard mustbe used by the tester in order to set up the system but normal operation couldbe carried out without it. Of course the use of a keyboard might speed up theoperation, there is no speed requirement when it comes to using the mouse. Thispart falls into the graphical section of the GUI, all of the inputs needs to havesupport for them to be operated by the use of a mouse only.

While this project was carried out at Ericsson, the developers working on NITEwere starting to make use of SQL when setting up the system. The idea is tohave a database shared by all testers which contains representations of the differenthardware environments available. This would eliminate the need for a tester tochange his own environment and testers would instead book time to run against asuitable environment available in the lab. This could also further improve automatedtesting since you could put a batch of test in a queue for a certain system withoutthe need of actually being physically present. As mentioned before a lot of effort isbeing put into actually automating the testing procedures. If the GUI had supportfor retrieving information from the database instead of the user having to inputeverything, they would learn to use this new way of thinking.

The GUI has to be dynamic in the sense that equipment not present in the hardwareenvironment are not being represented graphically. Menus are presented to thetester in the order which they are made available in the environment. As an exampleyou start off only with the possibility of performing an audit on the RBS. Thisperforms a scan of the RBS to see what cells are available on so on. The menus forthese cells and the likes are presented to the user. If the user has configured a UEthen this menu is presented as well. This procedure makes the GUI more intuitiveand straight forward. The module loading way of constructing the GUI makes itmore scalable as well.

3.2 The approach

Since the resulting software of this project should be easy to understand, dynamicand generic the approach had to obey these requirements as well. The process usedduring development was the waterfall method, see Figure 3.1. It is an iterativemethod and allows for a lot of back-tracking in the process, something needed inorder to correct earlier mistakes. As said before we are not interested in quick fixesfor problems found but rather general solutions that might even improve other partsof the system as a result. Everything had to be as general as possible, somethingquite hard to achieve since making things general often means that they do not solvea specific task a hand but rather something similar. This idea was kept throughoutthe program despite this dilemma, if this is to be changed in the future it will be

20

3.2. THE APPROACH

Figure 3.1. The waterfall method used during this project.

done by the team developing NITE. All of these prerequisites made the waterfallmethod a very suitable one, a lot of setbacks were met along the way and thismeant going back in the process to approach the problem in another way altogetherin some cases.

Since the work with the GUI could be divided into three different parts, architecture,graphics and error handling, so was the actual effort put into improving them. Atfirst the graphics of the program was handled. This did not actually affect any ofthe other parts since it was merely a task of choosing and understanding a bettergraphical toolkit than Tkinter. Next, the architecture was to be worked over fromthe ground and up. This part of the development affects the error handling andtherefore the architecture needed to be taken care of before the error handling. Alsothe architecture is more of interest from the point of view of this thesis as well asof the developers. The program would function despite the lack of error handlingbut not without an architecture.

21

Chapter 4

Graphics

The first part of a GUI you get in contact with is the graphics. The old saying thatfirst impressions last is important to keep in mind here. No program is consideredgood if it has bad graphics. Choosing a good graphical toolkit and making somechanges to the layout of the GUI can make a huge difference as will be shown inthis chapter.

A fair description of the existing GUI of NITE is saying that it looks old. Thecolor schemes used as well as some of the solutions for the layout feel outdated andless professional than what is desired. The look of software is essential when youwant users to switch from one program to another. Better looking graphics, even ifnot the main concern of the user, gives one of the programs an edge over the other.If the layout is made more intuitive both the program and the users will benefitfrom this. Since NITE is developed by people who have worked as testers there ismore understanding on how it needs to look in order for it to be intuitive to testersworking with it.

As mentioned earlier, NITE is looking to get as much funding as possible frommanagement. As the program is still in development, there are regular demonstrationsin order for the NITE team to try to convince the management that these findingsare a good investment for the future. At least some of the managers have not workedas testers prior to being management and this means that it might be hard for themto see advantages aside from those pointed out by the software team. The graphicshowever can be judged by anyone, maybe not the usefulness but at least the actuallook.

One thing that was desired for the graphics was platform independence. If a toolkitthat could be easily used in both Solaris and Windows was a possible choice, itwould have precedence over one that could not. There are some toolkits which areused widely in the software development community today. Choosing one of thesetoolkits is recommended since there is a wider support base as well as continuing

23

4.1. THE LOOK OF YESTERDAY

development being carried out.

4.1 The look of yesterdayThe GUI today uses Tkinter and this is an outdated toolkit. The colors used whenprogramming with this toolkit has to be specified in the code or a separate file.There is a lack of widgets since there is no apparent development being carriedout. Some widgets considered to be standard in todays software, such as tabbedwindows, were not available in Tkinter. This all makes for a pretty stale and boringlooking GUI.

When starting NITE the GUI presented itself looking grey and old, see Figure 4.1.The basic functionality in the form of important logs as well as the menus wasclearly visible from the beginning. Some of the menu options are greyed out sinceyou cannot access these features to begin with. One thing that you soon find outis the lack of resizing abilities. The GUI can not be maximised or actually changedin any way, it is fixed in size.

As you use the program the two log windows start to fill up with informationand different menu options become available depending on what you tell the systemto do, see Figure 4.2. The logs that are not visible from the first window can beopened in new window which are then opened in the background while you proceedto use the software, see Figure 4.3. Making some of the logs open in their ownwindow can lead to a lot of windows being open at the same time and can thereforeclutter your desktop.

When you are to do input the GUI presents you with a kind of field that has thesame feel of grey boredom. This whether it be text, see Figure 4.4, or numeric, seeFigure 4.5. One thing found here was the impossibility of inputing numbers withouta keyboard. Of course a keyboard will speed up the task of entering numbers butthe choice of doing it with the help of a mouse should exist. Also, all of the buttonslooked like a grey block with no sense of modernism.

Clearly there were some areas of improvement. Mostly when it came to the actuallook of NITE but also concerning the layout, the separate log windows included.

4.2 ToolkitsThere are several toolkits available to software developers these days. Some ofthem have better support in some programming languages than others and someof them are more platform independent. The first task when making the graphicalimprovements in NITE is that of selecting what toolkit to use. After consideringthat it had to support NITE and should work on both Solaris and Windows without

24

4.2. TOOLKITS

Figure 4.1. NITE’s old GUI. Notice that this is the fixed size, it cannot be resized.

too much effort, three candidates remained. These three were PyGTK [8], PyQt [9],and wxPython [10]. These three toolkits gives a you the ability to use the GTK+[11], Qt [12] and wxWidgets [13] widget libraries respectively.

All of the above toolkits have support for Windows and Solaris and presenteda modern and sleek widget library. While installing the different toolkits on aWindows machine it was found that Qt turned out to be a little more of a hassle toget working. Qt also had a bit more restrictive licensing agreement than the othertwo. Thus, Qt was cut from the group.

The choice now stood between PyGTK and wxPython, two strong candidates. Aquick search on the Internet provides you with a picture saying that PyGTK isa bit more widely used than wxPython. This could mean that it is easier to findsolutions to problems related to PyGTK as well as finding examples or tutorials [14]when implementing a widget. The scales were tipped slightly in favour of PyGTK.

25

4.2. TOOLKITS

Figure 4.2. The menu when NITE is just started compared to when the environmenthas been initialised in the old GUI.

After some more extensive comparison between the two it was found that one thingthat differed between the two was the depth of the library stack [15]. The followinglibrary stacks were found for the two candidates;

• wxPython on Windows machinewxPython -> wxWindows (MFC) -> Win API

• wxPython on X-windows machinewxPython -> wxGTK -> GTK -> XWin API

• PyGTK on Windows machinePyGTK -> GTK -> XWin API

These findings in conjunctions with PyGTK being more readily used led to choiceof PyGTK.

26

4.3. THE LOOK OF TOMORROW

Figure 4.3. Log window in old GUI.

4.3 The look of tomorrowAs the toolkit was chosen the actual task of implementing it became the next orderof business. During this phase a lot of smaller test programs were written in orderto test different widgets and settings. These test programs were not representativeof what NITE looked like when PyGTK was in use and the layout was improved,therefore the screen-shots shown here will be from when the GUI was in its finalstages. This means that the new architecture is present in the screen-shots as wellbut this is necessary in order to point to relevant changes when it came to updatingthe graphics.

The window presented to user when the GUI starts at this points is more modernand brighter looking, see Figure 4.6. There is only one menu item available to startwith since you have to start the environment to commence testing. Now there isalso the option of scaling and maximising the window, this without the interfacebecoming distorted.

27


Figure 4.4. Text input field in the old GUI.

Figure 4.5. Numeric input field in the old GUI.

28


Figure 4.6. NITE’s new GUI.

When the tester starts using NITE the different logs fill up with information anddifferent menu alternatives become available, see Figure 4.7. The different menualternatives are loaded dynamically to reflect the equipment available in the testenvironment, more on this in the next chapter. Also notice that the two main logsare still visible in the main window so that an easy overview of the most importantinformation is given. Below these two logs the secondary logs are located andtabbed. This means that you can quickly switch between the different logs andthey are available through one click without cluttering the desktop.

When inputting text, you are still forced to use a keyboard for obvious reasons,see Figure 4.8, but apart from this kind of input the GUI can be controlled by usingthe mouse alone. Numeric inputs make use of so called spin-buttons which presentyou with the option of increasing or decreasing a value with a click of the mouse, seeFigure 4.9. However, it can still be a problem when the range of a certain input orthe number of numeric inputs is great, see Figure 4.10. Having a keyboard handy is

29


Figure 4.7. The menu when NITE is just started compared to when the environmenthas been initialised in the new GUI. Notice that the RNC menu item is made availableonly after the environment is started.

still recommended. The grey block buttons are also gone and replaced by a task-barsporting some nice icons which add to the overall feel of a more modern GUI.

Since the effort needed in order to improve graphics is not that great, you shouldreally take the time to do it. It is an easy way of making a program look moreprofessional and appealing to the people who are to use it, or in this case finance it.

30


Figure 4.8. Text input field in the new GUI.

Figure 4.9. Numeric input field in the new GUI.

31


Figure 4.10. Some functions require a lot of numeric inputs.

32

Chapter 5

Architecture

The task of improving the structure of the program was the most time consumingand tedious one. Coming up with a structure that is dynamic, scalable and easy tounderstand is desired in almost all software development. Some prerequisites andguidelines were found while attempting to do this for NITE, the most important onebeing the time factor.

NITE has been developed on an ad hoc basis. No real planning was put into thestructure in the beginning and it was not long before the program grew out of itsoriginal skin. As this happened while there was constant time pressure being puton the developers, a lot of "dirty" code was created. Quick solutions and nongeneralapproaches are evident all around in the system. When the team started to growand testers actually started to migrate towards NITE this needed to be fixed. Inorder for more than one person to be able to work with the development of NITEat the same time, there had to be some sort of general architecture that could befollowed and implemented by everyone. Time and effort was put into making thiscome true and progress has been made, although it is an on-going struggle. AnAPI that was to be used in-between layers was worked out and the structure of theinformation was starting to be standardised as well. Despite this there are a lotof functions which do not follow the general pattern as well as information beingfound and cross-referenced all over the place.

When it comes to the GUI part of NITE, the major problems are those of coderepetition and that the code is hard to follow. None of the code used when defining,for example, a window is reused anywhere else. This means that there is a lot ofredundant code in the GUI part. This also makes it really hard to get an overviewof the code and therefore you need to learn the entire GUI if you want to add orchange something. Changing things might break others parts in the GUI and ifsomething is to be changed for all function calls you will be forced to do this inmany different places.

33

5.1. RULES AND RECOMMENDATIONS

The task here is really to develop a GUI from scratch and have a different approachall together. No (or as few as possible) quick and dirty solutions are to be usedand people should be able to extend or make changes in the GUI without too muchknowledge of the user layers workings.

5.1 Rules and recommendations

There is an enourmous literature on dynamic programming, scalable GUIs and such.Almost everyone making a GUI for something other than a really small applicationwants to make the GUI future proof in the sense of not having to rewrite the codeeach time something is updated in the program. Having made a GUI that canwithstand constant changes in the system it is to control can be very rewarding.This is even more important if your program is to be used by a company or customerand is not just an enthusiast’s project for the open source community. If people aredepending on you to have the program up and running as well as to give them thelatest feature they require, you have to make sure that something you did beforewill not come back and bite you. It might take a bit longer to do it in the "correct"way, at least in a short perspective, but more on this later.

Many of the documents concerning dynamic programming state what you shouldavoid rather than what needs to be done exactly. This raises certain suspicions onhow easy it is to achieve perfection, if possible. The first thing to have in mindwhen developing the architecture is that it should be as platform independent aspossible. This is not an easy task and there will probably be some minor modulesloaded according to which operating system is in use, this in order for it to workwith directories and such. The network file shares look different in the Windowsand Solaris environments found at Ericsson. There are however some other factorsto take into account here. The key is to keep the interaction going on between theuser and application layer as simple as possible [16]. The main idea is also to keepthe intelligence of the system away from the GUI part, it should only know thatwhich is absolutely necessary for it to function. This is of course a trade off but willensure a minimum amount of work needed for porting the GUI.

The above idea of keeping the intelligence out of the GUI goes hand in hand forwhat is needed in this assignment. The system should hold all the vital informationconcerning NITE at least. The GUI can be smart in itself but should not be neededin order for the lower layers to work. This way we also make sure that work beingmade in the GUI does not have to be copied to the console user interface, everythingof importance is below this layer. As mentioned previously the GUI itself can besmart in many ways, as long as it does not do any of the lower layers job. Wewanted this GUI to function with an already existing system and since it is not aone man job to redesign NITE from the ground up, what is already there must betaken into consideration.

34

5.1. RULES AND RECOMMENDATIONS

There is a lot of talk these days on the Model View Controller (MVC) [17] designpattern when coding GUIs. The general idea here is to divide the GUI or programinto three different parts, each of which with a specific set of tasks. Functions,information and the likes are then grouped into these parts according to their specifictask. A brief explanation could be the following.

• A model is an object representing data or even activity, a database table oreven some plan-floor production-machine process.

• A view is some form of visualisation of the state of the model.

• A controller offers facilities to change the state of the model.

This way of thinking is rather complex and might be hard to follow. Some peopleadvocate this solution [18] while others do not think it belongs in the object orientedprogramming world at least [19]. The task of actually following this principle isharder than one might first think. The lines quickly get blurred and the programgrows out of being manageable by this way of thinking. One of solving this problemcould be that of recursive MVC [20]. This might work for some time but whiledeveloping the GUI for NITE the advantages of using MVC way of thinking werenot clear. Rather it seemed to add to the things to keep in mind while developingthe software. You can, however, find some traces of MVC in the way most programswork. This might be more of a sign saying that the idea is abstract and generalrather than useful though.

There were some interesting papers on what is to be considered good and badcode. One of these is the one dealing with the dependency inversion principle [21].This paper states that code should be designed so that the different level modulesshould not be mutually dependent. The main thing here being that if the modulesbecome too intertwined they will be useless to others or other parts of the programat the same time. The ideas brought forward here have little to do with the wayPython is coded, since interfaces are not used in the same way as in C for example.There was a list that was of interest though, stating what criteria to use if youwanted to characterize software ill-designed. If the program exhibits any or moreof the following three traits it is to be considered poorly designed;

1. RigidityIt is hard to change because every change affects too many other parts of thesystem.

2. FragilityWhen you make a change, unexpected parts of the system breaks.

3. ImmobilityIt is hard to reuse in another application because it cannot be disentangledfrom the current application.

35

5.2. FINDING SOLUTIONS

When looking at the above traits it would have to be said that NITE on the wholesuffers from all three. Thus, it is poorly designed. The GUI suffers at least from badrigidity and immobility. That being said the need for a rewrite is obvious. When thenew GUI was designed these three traits were taken into the highest consideration.As always it might be hard to follow them exactly but they do give a good directionin which to start the planning of the GUI.

A lot of the papers dealing with this subject said the same thing when it cameto approaching the implementation. You should keep it as generic as possible. Thisseemed to be the general consensus but it might be difficult to determine to whichextent you can actually do this. It might seem that a program that could be usedfor everything is ideal. The answer is both yes and no. A program that could beeverywhere but does nothing is useless. On the other hand, a program that does thesame thing as another but is more generic and easy to implement in other systemtends to be preferred. So the question is rather to find a good balance between howsimple and generic the program is.

5.2 Finding solutionsThe approach to all of the above described problems was that of simplicity andscalability. It should be possible for anyone with NITE and programming knowledgeto understand the basics of the software. It should also be easy to extend the GUIto include new things without the previous features breaking in the process.

5.2.1 Code repetitionThis would have to be the part in this project in which most time was spent. It wasthe hardest and least straightfor"even so"ward part due to the fact that there arefew, if any, absolute truths in this area. The basic concept of reusing code insteadof repeating is not hard to grasp but knowing where to put boundaries is.

As described above, the code for the GUI contains a lot of repetition for the differentwindows, buttons and inputs that are to be presented to the user. This means thatthere is a lot of redundant code and also that it is hard to change the way thingsare done. If you want change the way GUI handles function calls you would mostlikely have to traverse the whole code looking for explicit changes needed for it towork. In other words, it is a time consuming task and is not likely to be performed.

The first question when trying to make use of inheritance is that of figuring outwhich parts of the system to generalise. In the GUI an obvious one was the windows.All windows spawned from the main GUI window shared attributes of certain types.The program could make use of this, a class for the windows were created. Thecontents of the individual windows were described in the different classes with whichthe window was to interact, more about this in the next section. The window then

36


had things like buttons, inputs etc. based on what was needed for the currentoperation.

This work then continued recursively. As soon as two similar classes shared commonfeatures a superclass was created for them to extend. This meant that as much ofthe settings and inner working as possible was as high up in the structure as possible,see Figure 5.1. A finger of warning could be raised here if the future of the programis a bit dim. This way of actually implementing inheritance as soon as somethingis to be gained, no matter how insignificant, could very well lead to an explosion ofdifferent classes. This is not desirable from a software point of view and should bewatched out for. The reason that it works in this this project is that the structure ofNITE is not all that dynamic. The way the new features of the RBS are controlledresembles or maps directly the working of the current features. The scope of NITEcompared to a program such as a word processor is a lot smaller and can be definedwith smaller constraints. If this is not the case for the software in development itwould be wise to structure the inheritance model in a different way to lower thenumber of small, very specific classes.

The section describing how to make the GUI more intelligent is closely relatedto this section since there was a need to dynamically specify which inputs wereavailable in a certain window. This had to be reflected by the function call madeby this window as well since the parameters used by the function call had to be arepresentation of the different inputs. This was also possible through the use of astandardised function in the GUI for calling functions in the application layer. Hadthis not been the case the values would have to be hard-coded in the program codeof the GUI. More on how this was solved in the next section.

5.2.2 Knowledge intensive

The main concern here was that of the programmers’ need for knowledge about theGUI. They should not have to be concerned with this part of the code if they are notdeveloping something GUI specific. Information on what is to be included in theGUI could be simplified and then made human readable. This would in turn requireless GUI knowledge from the developers as well as more intelligence in the GUI.

Everything displayed in the old GUI was hard-coded in the program code. Youtherefore needed to know about the inner working of the GUI and also familiariseyourself with the code before attempting to add new features. This meant thatpeople working on the layers below the GUI, such as the application layer had tohave an understanding on both the layer they wanted to change as well as the userlayer. This requirement will slow down introduction of improvements and featuresas well as increase the responsibility of each programmer involved in the upperlayers of NITE.

37


Figure 5.1. A simplified view of an extract of the different classes used in the GUI.Notice the hierachical structure.

38


Figure 5.2. View of how the GUI aquires information from the different classes itis to interact with in the NITE system. The GUI builds itself up accordingly.

The approach here was to move the information describing what needed to bedisplayed for each function to the application layer. This way the programmerswould not need to go outside their comfort zone when making changes to thefunctionality of the GUI. Ideally the code describing the GUI would be humanreadable and thereby decrease the requirements on the programmers even more. Ifthis was to be accomplished a more intelligent GUI was required.

The particular issue was solved by requiring each of the classes that were to beaccessed via the GUI to have a dictionary describing different parts of the window tobe displayed. In this dictionary things like different inputs as well as buttons wouldbe contained. The GUI would then traverse this dictionary looking for differentkeywords in order to figure out what window and functionality is to be displayed,see Figure 5.2. Since a dictionary in Python is basically a hash-table the time forlookups is in the order of O(1).

This idea was then further developed so that each class had a separate list of validinputs. This list could also describe an input as optional so that the GUI wouldpresent a small check-box if the value was to be used in the function call. Thedifferent functions of the particular class could then just say which values were ofinterest and the GUI would then check to see their validity in the main input list.If the input was described in a correct manner it would be added. The GUI alsochecked the currently selected instance in order to get the current value for theinput. When the actual function in the application layer was called the input was

39


a dictionary built by the GUI containing all of the requested inputs.

5.2.3 Decentralised

One of the major inconsistencies in NITE’s architecture is that of the information.Due to the fact that it has been developed ad-hoc without any real plan and undertime pressure the way information is spread all over the system is unreasonable. Itis both hard and tedious to find the information you want and you can not be surethat you will not break other parts in the system if changing the way this is done.

Since everything links to everywhere in terms of information it is hard to find theexact piece of information you are looking for. The answer itself could be dividedinto many parts of the system and this makes for a fragile system. It also makes ithard to change since most parts of the system have come to depend on this specificarchitecture and therefore it needs to kept for the time being. The only possiblesolution here would be that of a complete overhaul of the code. It would take a lotof time and effort but would probably be worth it in the long run.

Since this problem is not GUI related, not much effort was put into suggestinga solution. The problem should be handled by the system developers. On one handthey are aware of the problem but on the other they are also aware of the workneeded in order to fix it. As mentioned above no actual solution to this problemwas conceived but there are some general approaches that could be used. Therehas to be a specific way of structuring information. It must also be specified in ageographical way were information is to go. Should it be available through a specificinformation class or should each class be responsible for a smaller part. Thesequestions need to be answered by the development team and then they need tomake the executives aware of the importance in remaking the information structureof NITE. Predictions of the future are not absolute but it would seem that thisinvestment would pay off in the long run.

5.2.4 Static log parsing

There is no generic way when making or parsing logs in NITE today. Each log hasits own pattern and needs to be parsed accordingly. This ensures the use of non-generic functions and a lot of if-statements in the code. A generic way of doing thisis preferable.

Since each log in NITE has its own syntax, number of field etc. the GUI has aseparate parsing procedure for each of the existing logs. This means that the GUIhas to have a mapping from filename to parsing procedure to be able to display thelogs. So if either the format of the log or the filename changes the logging will notwork until something has been corrected in the GUI. It would be desirable to havea solution that is backwards compatible as well as making it possible to add new

40


features.

A simple solution here is spelled XML. If the log files were to be generated asXML code instead of text lines with defined separators you would have a moregeneric solution. All of the logs could share the same parser and the GUI wouldonly have to have one parser for all of the logs, even if it had to be rather complex.When parsing each file the GUI would use tags to understand how to display thelog. This way you would have backwards-compatibility when adding new featuresas well since the old tags need not be removed.

If this was to be implemented work had to be done both in the GUI and in thelogging facilities in NITE. This probably would not take too much effort if thepeople making the transition were familiar with XML and had come up with a goodstructure. So we put it on our wish list for the ultimate scalable and maintainableprogram.

5.2.5 Non standardised test environment

Today the test positions in the labs are static. In order to decrease the time each testtakes, a system for sharing stations needs to be developed. If a database containingthe configuration of each test space was available, you could simply acquire theappropriate station for a specific amount of time.

Each tester in the lab is more or less bound to a test position. When changesare needed in the system in order to perform a test, the tester will make theconfigurations in the environment by hand. This means that performing a testthat requires change in the environmental specifications takes longer to performthan one that does not. This way of thinking also means that there might be morethan one test environment set up the same way. This could be a waste of resourcesif the case is that one of the stations could be used for another test in the meantime instead.

A solution for this problem was begun while this masters project was performedat Ericsson. The idea was that of keeping track of the different test positions in aSQL-database. This way the testers could look for a suitable environment on whichto perform a certain test. That position could then be booked by the tester for acertain amount of time. As the testers no longer have a fixed position in the lab,there is less risk for the need of manual hardware configuration. All in all it willprobably speed up the testing procedure considerably.

In the future the plan is for the testers to acquire different test positions and thenprovide a batch of test scripts to be run. This is a big step towards automated,although supervised, testing. As this way of testing matures the testers would alsobe able to run all of the scripts from a remote location. A tester in Stockholm

41


might find a suitable test environment set up in Luleå which she can then useremotely. This is a lot more resource and time efficient. Making all of these stepswork satisfactorily is a huge undertaking and so smooth operation is not expectedshortly.

42

Chapter 6

Error handling

This part of the assignment was to implement a better error handling in NITE.There was some support for this already implemented in the system but the timeframe for the project did not allow for any improvements to be made. The problemand a proposed implementation will be discussed however.

NITE’s error handling was next to non-existent in the old GUI. If something wentwrong in the program it could hang for no apparent reason to the user. This neededto be improved. If the most information a tester could get out of the program crashis Python’s native error reporting it is not likely that an Trouble Report (TR) willbe filled out. The output will more likely be seen as gibberish by the tester andtherefore it will be discarded.

The tester has to get some sort of indication of what went wrong. This mightmake the tester more inclined to actually follow up on the problem. If this worksthe way it is supposed more TRs will be filed and corrected. It might even help thetester rectify the problem without the help of the development team. (Only for aninteraction error though since the testers are not to touch the actual NITE code.)

6.1 Lack of reason

As pointed out above NITE might crash without an indication of what went wrong.This is not the only problem though. There is also the possibility of the programcrashing or hanging without the problem causing this being fatal. There should besome internal way of classifying different errors which can occur in the system. Ifthe problem is not fatal with respect to the continued functionality of the programit should not quit. A fatal problem, however, should end the program.

The third deficiency is that of human readable error outputs. The testers might noteven know if the error was caused by them or the program. It could also be hard toexplain what exactly went wrong when writing a TR that is to be handled by the

43

6.2. ERRORS EXPLAINED

NITE development team. Even if they copy-paste the Python output it might notbe enough for the person trying to fix the error. And if it is, it could still take a lotof time to locate and reproduce the error.

6.2 Errors explainedThe way this is supposed to be handled in the "new" NITE architecture is by theuse of a watch-dog thread. This thread is to have an overview of what is going on inthe system and react if necessary. React in this context means that it is to contacta supervisor thread in the GUI that can display information to the user and alsotake certain precautions. The watch-dog thread monitors the Message Queue (MQ)and checks to see if things go wrong either here or in the Finite State Machines(FSMs). If this is the case the error is to be graded and labelled and then reportedto the supervisor thread.

The user would see something like a pop-up window telling them that somethingwent wrong in the system. Ideally it would also give a brief explanation on whatwent wrong along with reporting the severity of the occurred error. If it is fatal theGUI should quit after receiving an OK from the user. If it is a non-fatal error theprogram should resume operations after receiving the OK from the user. This waythe error reporting could also be automated as in many programs available on themarket today. NITE could generate an e-mail and send it so some address that ismaintained and checked by the development team.

44

Chapter 7

Results

The end product after the completion of this project is described in this section.A lot of the proposed solutions were implemented although some had to be cut dueto time constraints. A new GUI that could almost replace the old one in terms offunctionality was developed. Some work remains in order to make it surpass the oldGUI in this sense. In other areas such as graphics and architecture the new GUI isalready way ahead.

The end result was quite pleasing and it seemed that the problems in the GUI wereworked out when the redesign was carried out. The suggested approaches worked asthey should. Some minor modification to the original plans had to be made but thisis to be expected. When moving the new software from a Windows developmentenvironment to the live Solaris environment some things had to be changed. Truthbe told, they were fever than expected. After one day of implementation in thenew environment the move had been made from development to live usage. Thetesters in the lab did not get to use the new GUI before the end of this project. Butas it was handed over to the development team it was near completion and shouldtherefore have been introduced shortly after.

Some of the changes will not be noticeable to the testers. Most of the changesare there in order to make life easier for the people responsible for the furtherdevelopment of NITE. Although it must be said that just the graphical face-liftthe GUI got during this project is enough to justify this development. And this issomething the testers are bound to notice and hopefully appreciate.

7.1 Look and feel

A simple comparison on the some of changes might be sufficient to show the tuning ofthe graphics when using another graphical tool-kit. A lot changed such as the mainwindow and inputs, see Chapter 4. The new look is more modern and hopefully willappeal more to the testers. Easily solved problems such as being able to maximise

45

7.2. SCALABILITY

the window is also a great advantage in the new GUI.

Windows are more generic and are described in the basic parts of NITE. They alluse the same base code when being created and then this is expanded by inheritanceso that the window is customised to the programmers desires. The inputs also followthis principle. If an input as said to be optional it will have a check-box beside itthat will indicate if the GUI is to use this parameter. The specification of buttons,windows and inputs have been simplified in a way that will probably please thedevelopers and also make them more inclined towards introducing new features inthe GUI as soon as they are available in the system.

Since GTK+ and PyGTK are available on Solaris, Windows and *NIX machinesthe program is more platform independent and there is also a lot of support forcustomising the look of GTK+ widgets. You could make a special theme that is tobe used with NITE and use with the different OSs to get a consistent look. Youcould also let the look vary depending on the machine running NITE.

One thing that is currently standing in the way of using multiple locations andplatforms when testing with NITE is the structure of the labs and file systems. Thelab is located on a network separated from the office network. All of the machinesin the labs are running Solaris and therefore platform independence is of no gaintoday. If the office workstations were to be able to connect to the lab networkthey would still have to configured with GTK+ and PyGTK, as is already true forthe environment in the lab. Last but not least the file systems differs between thedifferent OSs. This could be solved quite easily by creating different file handlermodules for the different OSs that are loaded accordingly.

7.2 Scalability

The goal here was not to supply the GUI with any new functionality compared tothe old but rather make it easier to do so in the future. At the time of this project’spractical completion, the new GUI had implemented most of the functionality foundin the previous one but still lacked some features. This is not to be considered afailure since it was not the goal to begin with. The architecture of the GUI wasimproved considerably and this will hopefully make the task of adding new featuresand functions in the GUI an easy one.

Since the system is module based, it should be quite easy to extend the GUI toinclude new hardware and so on. Less resources are wasted as only the necessarymodules are loaded. This also makes it easier to make changes in the different partsof the system without breakage occurring somewhere else.

If a programmer is to introduce a new input or a new function in the GUI there

46

7.3. ERROR HANDLING

is no need for knowledge about the actual GUI code. An understanding of howthe description in the class file should be is still necessary though. This format,on the other hand, is designed to be human readable and is most certainly easierto understand and grasp than the actual GUI code. The downside here is that ofcustomising the looks of the GUI since everything is pretty standardised. Thisis a conscious choice and the trade-off is well worth it when striving towardsa manageable GUI. Efforts have been made to actually make the descriptionsadvanced in this respect. If a specific design is wanted the programmer has thechoice to actually write more detailed specifications for the GUI to follow. Thisis however not a requirement and the default minimal description will probably besufficient in most cases.

In the end the architecture consists of only two types of windows. One of thembeing the "main" window and the other ones being the windows spawned due to userinteraction. The "main" window is that which displays logs and the configuration forthis window is in the same format as the other windows but with more advancedconfigurations. This window keeps track of spawned windows, logs, menu itemsloaded etc. The spawned windows all follow the same way of parsing informationfrom dictionaries to define themselves. The supported keywords in these dictionariescan be increased as the need for new definitions arise and this will not brakebackwards compatibility.

The actual dictionaries are contained within the different classes in NITE thatthe user is to interact with. This means that each menu item in the "main" windowrepresents the different operations available for a certain class. You could definedescriptions which would allow for the class to add itself to another menu item. Thisentry would however still be known by the GUI to handle interactions with it originalparent class. This way of storing information also means that the programmer neverneeds to "leave" the file being worked on. The information needed by the GUI fora specific function is found in the same location as the function itself.

7.3 Error handlingUnfortunately there was no time to implement the thoughts on how to improvethe error handling in NITE. Some ideas were thought out and time will tell if theyprove to be worth implementing. There is some support for the error handling inthe system as it is today so something should be done in order for the GUI to takeadvantage of this.

47

Chapter 8

Future improvements

As this was a master’s project with a fixed time limit, the GUI was not finished atthe time of the master’s project’s completion. There is still a things to be done andthe software needs to go live among testers as well as developers.

Much on the GUI still remains. Bugs need to be worked out and tweaks needto be made. The main part of this process is actually launching the system in thelabs so that the testers can start using and abusing it. This is the best form offeed-back for a user interface. There is some minor functionality missing from theGUI but this should take less than a month to implement.

One major improvement that is to be implemented in the GUI is that of SQLsupport. As this project was carried out there were tests being performed by otherson configuring NITE through SQL. This work continued alongside the developmentof the GUI and therefore the GUI does not implement this functionality at themoment. The development of SQL support in NITE was in the same early stages asdeveloping the GUI and they would together have introduced to many uncertaintiesfor it to be worth it right now. Of course it should be implemented as soon as eitherof the two parts has proven to be stable.

If the GUI could also include support for scripting it would be the obvious choicefor the majority of the testers. It would automate a lot of their tedious work andalso increase throughput in the labs. This in combination with the SQL-databasefor configuration would probably introduce a major economical benefit for Ericssonas well.

49

Chapter 9

Conclusions

The process of making scalable and manageable software is not an easy or quick one.It takes a lot of patience and it requires the developer to stop developing things adhoc. There are also a lot of trapdoors along the way.

It is highly possible to develop scalable software that is relatively easy to understand.This is especially true if the system which is being developed is a smaller one. Thereare lot of things to consider and you should absolutely be ready to admit defeat acouple of times during development. The key to victory is not falling into temptationand taking the easy way out by making specific workarounds.

9.1 Prerequisites

It is important that the structure of different parts of the program looks like oris to look like each-other. If this is not the case and every part is highly uniquethere is little to gain from this way of thinking and programming. As an example,the different windows in NITE could be modelled by the same class and this yieldsa great improvement in performance and maintainability. On the other hand, ifeverything needs to have its special methods and displays etc, then there would beas many exceptions as there are windows. The gain here would be marginal, if any.

The people funding the development and the persons involved must be aware thatthe development will be slower in the beginning. It takes a lot longer getting aprogram that is to be thought-through up and running. There will probably be along planning phase in the beginning during which no code is written. And whenthe programming actually commences, there is a high probability that some thingsneed to go back to the drawing board to be re-written. The gain is to be expectedlater on when the stable, scalable and manageable system is up and running. Thenimplementing new features and fixing problems will be cheaper and hopefully thiswill in time make it all worth while. This is a real problem since the benefits mighttake long to show and therefore management might not be willing to pursue this

51

9.2. ALL IN ALL

idea - it could be considered more risky.

After this project the conclusion would have to be that a remake from scratchis recommended over a tune-up of existing code. This might seem faster at firstbut will soon prove to be a more time demanding task. You will not have fullcontrol either, something of the utmost importance when trying to make the codemanageable. So the way to go is scratching the code and starting over again if thischange in architecture is to be introduced.

Using a good graphical toolkit is priceless. You get so much for free when writinggraphical interfaces using these that you have almost no choice. They are both freeand readily documented.

9.2 All in allDeveloping scalable, manageable and efficient software is a major undertaking. Aswith so many other things in life there has to be trade-offs between what is desiredand what is possible. But in a constrained environment the benefits can be huge.If the prerequisites are right it could make or brake the successful development ofa specific software. Making a scalable software within a specific framework is moredefinable and therefore more likely to be successful.

The question should not be if scalable, manageable and efficient software is easy toaccomplish. Not when you always find yourself choosing which trade-offs to make.It should rather be that asking if such software even exists.

52

Bibliography

[1] Ericsson Sverige AB.http://www.ericsson.se. Last visited October 12, 2005.

[2] Webb & Associates - Telecommunications History.http://www.webbconsult.com/history.html. Last visited September 15,2005.

[3] The history of UMTS and 3G development.http://www.umtsworld.com/umts/history.htm. Last visited September15, 2005.

[4] Ericsson - the world-leading supplier in telecommunications.http://www.ericsson.com. Last visited September 20, 2005.

[5] National Instruments - Test and Measurement.http://www.labview.com. Last visited September 10, 2005.

[6] Python Programming Language.http://www.python.org. Last visited July 15, 2005.

[7] TkInter - PythonInfo Wiki.http://wiki.python.org/moin/TkInter. Last visited July 15, 2005.

[8] PyGTK.http://www.pygtk.org. Last visited August 20, 2005.

[9] Riverbank : PyQt : Overview.http://www.riverbankcomputing.co.uk/pyqt. Last visited December 7,2005.

[10] wxPython.http://www.wxpython.org. Last visited June 24, 2005.

[11] GTK+ - The GIMP Toolkit.http://www.gtk.org. Last visited August 20, 2005.

[12] Trolltech - Qt Product Overview.http://www.trolltech.com/products/qt/index.html. Last visited June24, 2005.

53

[13] wxWidgets Home.http://wxwidgets.org. Last visited June 24, 2005.

[14] PyGTK 2.0 Tutorial.http://moeraki.com/pygtktutorial/pygtk2-tut.pdf. Last visited August17, 2005.

[15] dBforums - pygtk vs. wxPython.http://dbforums.com/archive/97/2002/05/3/382414. Last visitedOctober 12, 2005.

[16] Cross-Platform Applications With Graphical User Interface.http://ootips.org/porting-gui.html. Last visited June 10, 2005.

[17] Model View Controller.http://c2.com/cgi/wiki?ModelViewController. Last visited June 28,2005.

[18] Model-View-Controller.http://ootips.org/mvc-pattern.html. Last visited June 28, 2005.

[19] Mvc Is Not Object Oriented.http://c2.com/cgi/wiki?MvcIsNotObjectOriented. Last visited July22, 2005.

[20] Recursive Model View Controller.http://c2.com/cgi/wiki?RecursiveModelViewController. Last visitedJuly 22, 2005.

[21] The Dependency Inversion Principle.http://www.objectmentor.com/publications/dip.pdf. Last visitedOctober 12, 2005.

54

TRITA-CSC-E 2006:029 ISRN-KTH/CSC/E--06/029--SE

ISSN-1653-5715

www.kth.se

graphical control interface for 3g radio base stations - kth · pdf filegraphical control...

Documents