Refactoring Guidelines for a UML-RT based Software System

Z I V E R K O C

Master of Science Thesis Stockholm, Sweden 2011

Refactoring Guidelines for a UML-RT based Software System

Z I V E R K O C

Master’s Thesis in Computer Science (30 ECTS credits) at the School of Computer Science and Engineering Royal Institute of Technology year 2011 Supervisor at CSC was Olof Hagsand Examiner was Stefan Arnborg TRITA-CSC-E 2011:131 ISRN-KTH/CSC/E--11/131--SE ISSN-1653-5715 Royal Institute of Technology School of Computer Science and Communication KTH CSC SE-100 44 Stockholm, Sweden URL: www.kth.se/csc

AbstractA large software system is not a static product that can be planned, implementedand then forgotten when �nished. Software systems are rather evolving entitiesthat need continuous maintenance and refactoring to improve their structure.This is a large and common problem in the software industry, as products agethey accumulate more features and large amounts of code that the initial ar-chitecture were not designed for. This leads to a fragmented code base and aslower development process.Overcoming software complexity can not be directly solved by a single solution.As the problem itself is not caused by a single issue or property, it rather con-sists of multiple issues that in combination cause the larger problem. This thesisgoes through some of the problems that where found in a large software sys-tem at Ericsson and di�erent types of solutions that might improve the overallstructure and development e�ciency of the system.The direction of this thesis has been to introduce development guidelines into thedevelopment of the system at Ericsson. The main goal of these guidelines is todecrease the need to do large refactorings and instead focus on more frequent andsmaller refactorings. The guidelines touch on di�erent areas of the developmentto improve the structure and the development e�ciency of the system. Theareas that are mainly focused on are the architecture, the visual UML diagramsand the source code. The main recommendations that have been concludedare the importance of using modern and iterative development processes thatinclude refactoring as an integral part of its phases and to use a more extensiblearchitecture for the system itself. As these recommendations are part of along term solution they are complemented by guidelines for the more dailydevelopment to improve the current source code from getting fragmented.

SammanfattningRefaktoriseringsriktlinjer för ett UML-RT-baserat mjukvarusystemDagens mjukvarusystem är inte objekt som endast kan planeras, implementerasoch sedan läggas upp på hyllan. De är snarare system som kontinuerligt behöverrefaktoreras och underhållas för att förbättra dess struktur. Detta är ett stortoch ett vanligt problem inom mjukvaruindustrin. När mjukvarusystem blir äldreså samlar de på sig nya funktioner och stora mängder ny kod som den ursprung-liga arkitekturen inte var avsedda för. Detta leder till att kodbaserna blir storaoch ohanterliga som då även ger långsammare utvecklingsprocesser.Det går inte att övervinna komplexiteten i mjukvarusystem genom en simpel lös-ning, då själva problemet inte orsakas av ett enda problem eller egendom utandet är snarare så att det är många mindre problem från olika områden som i kom-bination leder till det stora problemet. Detta examensarbete går igenom någraav de problemen som har upptäckts i ett stort mjukvarusystem som utvecklasav Ericsson, det ges också ett par lösningar till dessa problem. Denna rapportenkommer även gå igenom förslag som kan förbättra den övergripande strukturenav systemet för att då e�ektivisera och förenkla utvecklingen.Målet för detta examensarbete har varit att införa riktlinjer för utvecklingenav Ericssons mjukvarusystem. Huvudsyftet med dessa riktlinjer är att minskabehovet av stora omstruktureringar men istället fokusera på mindre och merfrekventa refaktoreringar. De föreslagna riktlinjerna berör olika delar av utveck-lingen av systemet men främst inom arkitekturen, visuella UML diagrammenoch själva källkoden. Några av de större slutsatserna som har konstaterats iexamensarbetet är vikten av att använda moderna och iterativa utvecklingspro-cesser som inkluderar någon typ av refaktorering i sina iterationer, men ävenbetydelsen av att använda en arkitektur som är �exibel och utbyggbar på ettbra sätt. Eftersom dessa rekommendationer är mer långsiktiga lösningar har dekompletterats med riktlinjer för den dagliga utvecklingen, dessa har införts föratt förbättra den nuvarande källkoden på kort sikt men även förhindra utökadfragmenteringen.

PrefaceI want �rst and foremost thank my handlers in this thesis project, ChristosAmigdalas (Ericsson), Eva K. Thor (Ericsson) and Olof Hagsand (Royal Insti-tute of Technology, KTH). You have been of great support and guidance to mein this project. I would also like to thank the people in the RNC departmentand specially the RNH section for welcoming me into the department.Lastly I would like to thank my family for there support during the project andalso my studies. I want especially to thank my dearest friends for their greatsupport and friendship during my studies at KTH. I would not been able tocomplete without you guys, Thank You!

Contents1 Introduction 11.1 Problem Background . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Background 42.1 Development platforms and Technologies . . . . . . . . . . . . . . 42.1.1 Modeling Languages . . . . . . . . . . . . . . . . . . . . . 42.1.2 UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 UML for Real-Time . . . . . . . . . . . . . . . . . . . . . 102.1.4 Rational RoseRT . . . . . . . . . . . . . . . . . . . . . . . 112.2 Software Engineering . . . . . . . . . . . . . . . . . . . . . . . . . 122.2.1 Software Design . . . . . . . . . . . . . . . . . . . . . . . 122.2.2 Software Refactoring . . . . . . . . . . . . . . . . . . . . . 122.2.3 Software Features . . . . . . . . . . . . . . . . . . . . . . . 142.2.4 Software Rewrite . . . . . . . . . . . . . . . . . . . . . . . 152.2.5 Code Smells . . . . . . . . . . . . . . . . . . . . . . . . . . 152.3 Software Development Processes . . . . . . . . . . . . . . . . . . 162.3.1 Waterfall . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3.2 RUP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.3.3 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.4 Code and Fix . . . . . . . . . . . . . . . . . . . . . . . . . 203 Analysis of RNH 223.1 RNC/RNH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.3 Code Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.3.3 Source Code . . . . . . . . . . . . . . . . . . . . . . . . . 293.4 Development Process Analysis . . . . . . . . . . . . . . . . . . . . 31

4 Evaluation of Analysis 344.1 Analysis Summary . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2 Solution Structure . . . . . . . . . . . . . . . . . . . . . . . . . . 354.3 The Development Process . . . . . . . . . . . . . . . . . . . . . . 354.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4.1 Maintainability . . . . . . . . . . . . . . . . . . . . . . . . 364.4.2 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . 374.5 Model and Visuals . . . . . . . . . . . . . . . . . . . . . . . . . . 394.5.1 Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . 404.5.2 Ports and Protocols . . . . . . . . . . . . . . . . . . . . . 434.6 Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.6.1 Data Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 444.6.2 Function parameter lengths . . . . . . . . . . . . . . . . . 454.6.3 Documentation . . . . . . . . . . . . . . . . . . . . . . . . 465 Guidelines 475.1 Guideline structure . . . . . . . . . . . . . . . . . . . . . . . . . . 475.2 Category 1: Coding guidelines . . . . . . . . . . . . . . . . . . . . 485.3 Category 2: Modeling guidelines . . . . . . . . . . . . . . . . . . 495.4 Category 3: Architecture guidelines . . . . . . . . . . . . . . . . . 516 Summary 536.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.2 Final Thoughts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54Bibliography 56Appendix A Dictionary 59Appendix B Guidelines 61

List of Figures2.1 Shows an example of a class diagram . . . . . . . . . . . . . . . . 62.2 An example of a deployment diagram . . . . . . . . . . . . . . . 62.3 An example of a activity diagram . . . . . . . . . . . . . . . . . . 72.4 An example of a state machine diagram . . . . . . . . . . . . . . 82.5 Shows an example of a use case diagram . . . . . . . . . . . . . . 82.6 This is an example of a sequence diagram . . . . . . . . . . . . . 92.7 Shows how the pro�les corresponds to the UML Speci�cation . . 102.8 Shows the Waterfall process . . . . . . . . . . . . . . . . . . . . . 172.9 Shows the Rational Uni�ed Process . . . . . . . . . . . . . . . . . 192.10 Shows the scrum process . . . . . . . . . . . . . . . . . . . . . . . 203.1 Shows an example of a WCDMA system. . . . . . . . . . . . . . 233.2 Shows the structure of the RNC and its subsystems. . . . . . . . 233.3 Shows the relationship between the CellHndl and the CellRo cap-sules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4 Shows the routing in the Cell block. The Local cell is an externalblock in a RBS that are connected to the actual Cell hardware. . 273.5 Shows the distribution of transitions . . . . . . . . . . . . . . . . 283.6 Shows the amount of states and state levels . . . . . . . . . . . . 293.7 Shows the distribution of di�erent properties in capsules and classes 303.8 Shows the Ericsson development process . . . . . . . . . . . . . . 324.1 Shows an example of a message �ow in an MSC architecture . . . 394.2 Shows an illustration of a current layer in the state machine ofthe CellRo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3 Shows an illustration of an improved state in the state machineof the CellRo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4 Shows an illustration of a state with common transitions . . . . . 42

Chapter 1IntroductionThis chapter will introduce the software system developed by Ericsson and de�nethe main problem that has been investigated in this thesis. The goals andlimitations will also be highlighted in this chapter.1.1 Problem BackgroundThe Radio Network Handler (RNH ) is a subsystem of a product called RadioNetwork Controller (RNC ) that Ericsson is developing for large telecommunica-tion operators. The development of RNC is mostly done in C++ and in RoseRTwhich is a model based development platform. The subsystem RNH is primar-ily used for controlling an RNC which is a node in a telecommunication system(UMTS) that is handling Radio Base Stations (RBS) and the radio network.The RNC is built upon multiple subsystems with each containing many di�er-ent blocks that handle di�erent functions of the system. The blocks themselvesare packages that contain a large amount of data classes and complex state ma-chines. Despite their size the blocks continue to grow for every added featurewhich makes the maintenance of the blocks di�cult and time consuming. Thesolution Ericsson implements today is to split larger blocks into smaller partsevery 3 or 5 years, this solution takes a large amount of time to complete andtemporarily halts the further development of that block. They are now look-ing for a better and a more active solution that will prevent the overgrowth ofthe blocks and in the process might make the code base cleaner and easier tooverview.1.2 Problem StatementAs described in the problem background (see Section 1.1) the main problemin the development of the RNH subsystem is the need to split the blocks intosmaller parts because of the overgrowth of the blocks. There is a need to improvethe design of the blocks to minimize the need for the block splits.1

1.3 GoalThe goal of this thesis is to evaluate the current architecture of the RNH Sub-system. To formulate recommendations for Ericsson of possible guidelines ormethods to actively decrease the overgrowth of the blocks.1.4 ApproachThe analysis of the current system is split into multiple di�erent sections thatgoes through and analyzes di�erent areas of the system. The di�erent areasinclude:• Problem: the problem is analyzed for a better insight into the situationin the development of the system.• Source code: the actual code in the system, parts of the C++ code andthe system model is evaluated. There is also a higher level analysis of thearchitecture of the code.• Development process: a small analysis over the development processthat are currently being used in the development of the system.These are the main areas that have been analyzed. The last point in the list,the analysis of the development process have a more general than an in-depthanalysis, the reason for this is time constraints and it is outside of the scope ofthis thesis.The approach of the analysis is a factor of di�erent observations. The mainobservation is my own experiences in the development of the system but alsoincludes other views and ideas from the actual development team. The viewsof the development team are mainly derived from discussions and interviewsconducted by me. The interviews focuses on the actual problem that the teamfeels is necessary to solve but also contains their thoughts of possible solutions.The analysis of the code is the main part of this thesis where problems inthe code are highlighted. The analysis section also examines the structure ofthe code and this is where the overall architecture is analyzed in more detail.The examination of the architecture is split into two di�erent sections; manage-ability and extensibility. The manageability analysis investigates the possibilityof maintaining the code as bug �xes and other types of changes are needed inthe existing code. The second section, extensibility analyzes the di�culty inimplementing new features in the current system source code and the e�ects ofnew external features have on the system.The last area of the analysis analyzes the development process. Because ofthe large scope of this area, the analysis is only a general view over how it worksand the impact it has on the code and the given problem.As the size of the RNC System is out of scope of this thesis, the analysishas been restricted to one of the blocks in the RNH Subsystem.2

1.5 LimitationsThe actual work in this thesis is limited to a speci�c block or a few classes in theRNH Subsystem. Because of the size of the system a reference implementationof the results was not possible to do in feasible time.All code and diagrams in the development of the RNC System are con�den-tial Ericsson properties this is why any source code or diagram in this thesis isan approximate illustration and does not represent actual code or models usedin the RNC System.

3

Chapter 2BackgroundThis chapter will introduce some technologies and applications that will be usedin this thesis and have been used by Ericsson at the time of writing this thesis.Later sections will go through some general software engineering topics and morein depth into software refactoring and strategies for refactoring larger softwaresystems.2.1 Development platforms and Technologies2.1.1 Modeling LanguagesA modeling language is a set of rules for interpreting a speci�cation. The speci-�cation can describe many di�erent things, a popular use is de�ning a softwaresystem but there are other areas that the speci�cations can be applied to. Thesoftware industry uses the modeling languages to plan and structure their soft-ware systems in an abstract way. This bene�ts the development by giving anabstract top level view over a whole system, which would be di�cult to getfrom only a code base. The modeling languages are often a part of a modelingmethod that consists of a language and a process.There are di�erent types of languages today that are either graphical ortextual. The graphical languages mostly use visual diagram techniques to de-scribe di�erent structures and relationships between structures. A very populargraphical modeling language today is UML which also has an accompanyingmodeling process called the Rational Uni�ed Process [1].2.1.2 UMLThe mid 90's was a time where there where a large number of modeling lan-guages. The amount of languages made the adoption of object technologies slow.This was the time when the company Rational Software[9] decided to create anopen uni�ed language to replace all proprietary and closed modeling languages.The task of developing the language was given to three employees of Rational4

Software, Grady Booch, Ivar Jacobson, and James Rumbaugh to create a in-dustry standard for object modeling which they called UML (Uni�ed ModelingLanguage). The initial version of UML was developed 1996 and standardized1997 by the Object Management Group (OMG), where the latest version of thestandard was released 2010 with version 2.3[10].UML is a modeling language for describing simple and complex object-oriented systems. It is an abstraction layer to help visualize the structure andenvironment over and inside a system. UML is mostly used as a developer toolto give a developer the ability to get a bigger picture over a whole system with-out the need to examine small details that might make the visualization moredi�cult. It is also used as an initial design tool for designing core architecturesfor a system. By designing a system in UML a developer gets the ability to eas-ier detect problems that may occur in the architecture early in the developmentprocess and then resolve them before any code has been written which savestime and money.UML has 14 di�erent types of diagrams that describe di�erent aspects ofa system. They are divided into two di�erent categories; structural (static)diagrams and behavioral (dynamic) diagrams. The diagrams are built on acouple of shapes that describes di�erent components of a system. The morecommonly used shapes are:• Boxes: these illustrate an entity (class, object etc).• Ovals: illustrates a state or a use case.• Arrows: there are multiple types of arrows, they can be identi�ed by theiredges, they indicate inheritance, dependencies, associations etc.• Stickmen: these illustrate actors (users or other components) in a system.Structure diagramsThe structure diagrams are models de�ning the core architecture and compo-nents that a system must contain. The diagrams that are part of this categoryare[2, 3]:• Class diagram: a model of classes (with �elds and methods) and theirsuper classes in a system. (see Figure 2.1)

5

Figure 2.1: Shows an example of a class diagram, the Animal box represents an ab-stract class with the �eld Age and the method getAge(), the Cat box represents a sub-class of the Animal class with its �elds lifes_left, housecat and the methods isHousecat,getCatLifeLeft.• Component diagram: a diagram that describes the connections anddependencies between di�erent modules in a system.• Deployment diagram: a deployment diagram describes the underlyinghardware or runtime environment the modeled system will be running on.(see Figure 2.2)

Figure 2.2: An example of a deployment diagram. The stick man indicates a userinteracting with a PC. The big boxes specify the physical hardware or runtime environ-ments, the inner boxes show the internal applications or services that runs on top ofthe environment.• Object diagram: a diagram specifying all or some of the objects in asystem at a speci�c time.• Composite structure diagram: a diagram describing the inner work-ings of a class, the diagram consists of parts and ports. The parts describethe instances of a class and the ports show the communication betweendi�erent ports in the class or its instances.6

• Package diagram: a diagram that describes how a system is dividedinto groups or packages. It also shows the dependencies between di�erentpackages. The package diagrams are mostly used to organize all the otherdiagrams into a more understandable and simpler structure.Behavior diagramsThese diagrams show the behavior of a modeled system. They show what asystem does in speci�c situations[2, 3].• Activity diagram: a diagram that describes the overall work�ow in aspeci�c part of a system. (see Figure 2.3)

Figure 2.3: An example of a activity diagram. It describes the �ow in a vendingmachine. The �ow begins at the black circle and follows the arrows. The oval shapesrepresent an action and the rhomb represents a condition and the black bar splits orjoins concurrent activities.• State machine diagram: describes the di�erent states that a systemgoes through under its execution. (see Figure 2.4)

7

Figure 2.4: An example of a state machine diagram. The diagram describes a simplelamp that can be turned on or o� by a button. The arrows represent events (buttonpushes) and the rounded boxes shows the state of the lamp.• Use case diagram: a diagram that describes the interaction betweenActors and a system. Actors can either be a user or another componentin the system. It is a high level de�nition of the functionality in a system.(see Figure 2.5)

Figure 2.5: Shows an example of a use case diagram. The stick man indicates anactor which in this case is a user that's using a vending machine. The inner circlesindicate a use case or function.The behavior diagrams also has a subtype called Interaction diagrams, thesediagrams speci�es the �ow of data or control in a system[2, 3].• Sequence diagram: a diagram that describes the lifespan and the inter-action between di�erent objects in a system. (see Figure 2.6)

8

Figure 2.6: This is an example of a sequence diagram and it continues the vendingmachine example. The boxes at the top describe the di�erent classes that are used.The arrows represent the interaction or control �ow between the classes.• Timing diagram: describes the time constraints and requirements indi�erent parts of a system.• Communication diagram: a diagram that shows the communicationbetween di�erent objects in a system as messages. It combines parts ofthe class diagram, sequence diagram and the state machine diagram toshow a bigger view over how the di�erent diagrams and components of asystem are interconnected and are communicating with each other.• Interaction overview diagram: a diagram that has similarities to theactivity diagram but with the di�erence of the activities in this diagrammay contain subsets of either a sequence diagram, communication dia-gram, another interaction diagram or a timing diagram.One popular feature of UML is its extensibility. UML has the ability to beextended with additional layers on top of the speci�cation (see Figure 2.7) withspecialized diagrams that better describes a special system. UML extensionsare more commonly referred to as UML Pro�les.

9

Figure 2.7: Shows how the pro�les correspond to the UML Speci�cation.2.1.3 UML for Real-TimeOne UML pro�le that is used in real-time systems is Real-Time Modeling Li-brary (UML-RT). It is an extension of the UML speci�cation targeting real-timeapplications. The di�erence between the standard UML and the UML-RT spec-i�cation is some additions to the Real-Time Modeling Library pro�le[4]:• Capsules: these are equivalent to ordinary classes but with the di�erenceof not having any public �elds or methods. All communication betweencapsules are made by messages, which are de�ned by protocols and sentthrough ports.• Protocols: de�nes the structure of the messages that a speci�c port canhandle.• Ports: these are gateways that receive and send messages between capsuleinstances. Each port is uniquely owned by a capsule instance.• Connectors: these are logical connections between ports. They can onlybe connected between ports that are compatible with each other (has thesame protocol).• Capsule structure diagram: this is an extension of the collaborationdiagram. It is used for describing the communication between di�erentcapsules. This diagram consists of capsules, protocols, ports and connec-tors.The bene�t of using capsules instead of classes is the property of every capsulehaving its own logical thread which gives a system the ability to easily run onmultiple physical threads on a CPU[4]. This functionality comes from the useof message-based communication between capsules instead of method calls asin ordinary classes. This gives the capsules an outside view of a black box[12].The message communication is a part of the capsules event based architec-ture. Every message that is received generates an event in a capsule-instancethat then is queued for processing. The capsule then takes the �rst event from10

the queue and processes it by generating appropriate responses, and due to therun-to-completion semantic of the capsule only one message will be processedat a time[12]. This work�ow of the capsules decouples the dependencies thatexists between ordinary classes, and automatically gives the ability to nativelyrun the system on multiple physical threads without any need of special codefor thread safety.2.1.4 Rational RoseRTRational RoseRT (Rose RealTime) is a software development environment forreal-time systems. It is a model based development platform that lets the devel-opers design complex software systems in UML (more speci�cally UML-RT) andthan gives the developers the ability to generate code and execute the model.RoseRT also has built in facilities to debug and automatically or manually verifyand test the models. As a model driven development platform RoseRT in it selfdoes not contain a compiler but gives the developers the freedom to choose acommercial compiler of their choice as it generates standard C, C++ or Javacode[5]. RoseRT only supports a subset of diagrams in the UML speci�cation:• Class diagram• State diagram• Capsule structure diagram• Collaboration diagram• Sequence diagram• Component diagram• Deployment diagram• Use case diagramRoseRT only needs the �rst three diagrams in the list to generate a executableapplication.Rose was initially developed by Rational Software for the Ada programminglanguage in 1992 and used a modeling language, one of the predecessors ofUML which was developed by Grady Booch (also one of the creators of UML).Later versions of Rose moved to UML as the main modeling language and alsoforked to another application (RoseRT) for more real-time speci�c systems.Rose became a part of IBM's portfolio in the beginning of 2003 when IBMacquired Rational software and have since then been developed and maintainedby IBMs Rational division.

11

2.2 Software Engineering2.2.1 Software DesignSoftware design is an initial design or planning stage in the development of asoftware system. It can be compared to a construction job, where software de-sign is the engineering drawing for a building and the coding is the constructionof the building from the engineering drawing[8]. Designing initial software ar-chitecture is a large research area, there are many di�erent types of designs andphilosophy's that exists today for designing a system, and they all have theirown areas and projects where they are better suitable. The initial design of asystem is an important step for larger companies and projects. There are someadvantages when designing the architecture in the beginning of an project butthere are also disadvantages[8]:Bene�ts:• The development will proceed more e�ectively when the developers havestrict guidelines to follow.• Problems that may occur in the future may be more easily be detectedand solved.Disadvantages:• It is di�cult and expansive to change the architecture or the design afterthe initial planning and designing phase of a project.One alternative to initial software design is software refactoring[8]. It is a morecommon alternative for developers in smaller projects to start by putting theidea of a system down in code and get it to work properly without any con-sideration of a design, and afterwards start to refactor the system into a goodarchitecture. This may be possible to do in smaller software project but are notpractical for larger ones.2.2.2 Software RefactoringThe purpose of software refactoring is to safely modify and improve existing codewithout changing the overall functionality and behavior to outside elements orsystems[6, 7]. Most of the more modern and iterative software developmentprocesses include software refactoring as a part of the development work.One important point of software refactoring is the fact that refactoring asystem does not include adding new features; it only covers rearranging andsimplifying the existing code. Refactoring is usually done in small incremen-tal steps to aid the developer and simplifying the refactoring process. Everyrefactoring step includes two activities:• Refactor a small bit of code. 12

• Test the refactored code.The more important part of a refactoring is the testing, it is vital to run a systemthrough multiple tests after each refactoring step to make sure that features andfunctions in the system are still intact and not broken. Otherwise there mightbe too many changes in the code base to e�ectively be debugged after problemsthat are detected.Software refactoring has also two di�erent approaches of execution, Code-First Refactoring and Test-First Refactoring[11]. The di�erence between thetwo is the order the testing and the refactoring parts are carried out. The �rstone, Code-First refactoring is a more code centric approach where the originalcode is retain as a safety net as the system is being refactored, and the test codeis incrementally changed as the refactoring process proceeds. While the secondapproach is a more test driven approach, where the developers will start bychanging the test code before the refactoring and afterwards do the refactoringuntil the tests are successfully run.As they are described in Martin Fowler's[8] and Joshua Kerievsky's[6] booksthere are many refactoring techniques that may clean up and better structurea code base. Here are some of the more common and recognizable ones:• Abstraction:

◦ Hide �elds in classes and force external classes to use accessor meth-ods (getters and setters) instead of direct access to the �elds.◦ Split large classes (God classes) into small hierarchies that makesextensibility easier.◦ Using polymorphism instead of conditions which make the code muchcleaner and simpler to overview.

• Breaking code into smaller parts:◦ Splitting large methods or functions into multiple smaller more man-ageable pieces.◦ Extracting code in a class to a new class. Should be used when thepurpose of a class starts to be unclear.

• Moving and renaming:◦ Renaming �elds or methods that has unclear names, makes the overviewof the class easier.◦ Pull up. Move �elds or methods that are more abstract or used bymultiple classes to a super class. By doing this the �eld or methodcan be used by all subclasses, which may remove duplicate code inthe subclasses.◦ Pull down. Same as above but you move a �eld or a method that aremore speci�c to a subclass from a super class.13

There are multiple bene�ts to refactoring of a system where the main ones are[8]:Maintainability: where bugs and software patches are easier to �nd and im-plement.Extensibility: to be able to add new features in the feature more easily bysimply being able to extend an existing class and not to be forced tochange existing classes or functions.What these have in common is that their are less time of troubleshooting andmore time for development in other areas of the system which bene�ts both thecostumers and the developers of the system.Large RefactoringRefactoring of larger systems is a more di�cult task then a standard refactoring.There are multiple factors that make these types of refactoring more complexto perform. One factor is the amount of work; a large refactoring can takefrom a month up to a couple of years depending on the size and the health of asystem[8]. In these kinds of systems there usually is a larger development teamthat also must be in a degree of agreement on the refactoring and be aware thata refactoring is in progress. It is important to have a strategy when refactoringin a larger scale, to minimize the downtime of the ordinary development. Hereare a couple of di�erent strategies for refactoring a larger system:• Rewrite and throw awayThis strategy breaks the system for a period of time while the system goesthrough extensive changes. And you have a new and improved system.This strategy can be di�cult to use as the system will be broken for a whileand other work on the code base might not be possible which introducesmore delays.• Refactor into submissionThe refactor into submission strategy splits a system into smaller parts.Then all the parts are slowly decoupled from each other, in a sense creatingsmaller islands of a bigger landmass. After a section of the system hasbeen decoupled it can be refactored safely.• StrangleThis strategy is based on a term �Strangler Application� which is an ap-plication that works as a wrapper around another application. It is asif the old code is slowly wrapped in by a shell as the refactoring processcontinues. This strategy has the bene�t of keeping the old code while newcode uses the more improved wrapper.2.2.3 Software FeaturesAs mentioned in (see Subsection 2.2.2), it is important to distinguish betweenrefactoring and the addition of new features to a code base. There are clear dif-ferences between the two, where refactoring is only intended to change existing14

code and not to add new functions. While adding new features is intended foradding new functions to a system and not to change any existing code or modi-fying the architecture[8]. They complement each other despite their di�erences.2.2.4 Software RewriteRewriting a software system is a serious task to take on. It is often a last resort,and sometimes not possible for larger software systems. The need for a rewritemostly occurs when the current code base contain many bugs and bug �xes leadsto even more bugs or when a software refactoring might be too time consumingor not practical to stabilize the system.Many companies have tried a software rewrite and most of them have failedwhich have led to loss of market share[13]. The main reason for failing a softwarerewrite is the time it takes to have a production quality application which givesthe competitors free rain over the market to improve and innovate in their ownproducts.The nature of a programmer is often to scrap an existing code base andrebuild it from the ground up. This might be a good decision in some casesbut it is mostly more time consuming than doing a refactoring(see Subsection2.2.2). As older code usually is more stable as it is been thoroughly used andtested. Whereas new code do not have the maturity of the old one.2.2.5 Code SmellsCode smells is a term used when the source code of a system or application ishard to overview and maintain. The term in it self is often a subjective judg-ment, it can drastically change between di�erent developers and developmentlanguages. Some of the more common code smells are[6]:• Duplicated code: when you have two code segments that has the samefunctionality.• Long methods: when the methods or functions are overgrown with manyattributes.• Large classes: when classes have overgrown and are hard to overview.Another word for these are �God objects�, they usually contain too muchdata or too much functionality for one single class.• Lazy classes: is the opposite of the large classes, these classes containinga very small amount of functionality or data.These are only a handful of possible code smells, the full list may be found inMartin Fowler's Refactoring: improving the design of existing code[8].The main motivation for software refactoring is when the code comes to thepoint where it is di�cult or time consuming to add new features. This is mostprobably caused by the code base containing code that smells.15

2.3 Software Development ProcessesSoftware development processes are methodologies that de�ne a work processwhen developing software systems. There are many di�erent types of processes;some are more oriented towards an iterative or incremental development stylewhile other processes are more planed and sequential. The processes does nothave to be used as a standalone model, they can be combined to form a largerdevelopment model for example in a big project a Waterfall process could beused as an overall process while SCRUM or RUP as an internal process forthe smaller teams. The development processes are structured by phases whichdivide all the work in a project into smaller and more de�ned parts that specifygoals that needs to be reached at the end of each part. The main motivationfor using a development process is to give a project a de�ned structure withspeci�c phases and small goals which gives the developers a sense of structureand improves the e�ciency of the development.2.3.1 WaterfallThe Waterfall process is one of the oldest processes used today, it is a sequentialprocess which means it goes through its phases in sequence and does not iter-ate between the phases(see Figure 2.8). It originated from the manufacturingindustries, in the physical production where work is mostly done in sequence be-cause iterations become very expensive when developing hardware. The processcontains six di�erent phases:1. Requirements speci�cationThis phase is where a speci�cation is written with the help of the clients orthe costumers of the project. The speci�cation de�nes the overall behaviorof the system.2. Software designThis phase is the planning stage of the process. This is where the archi-tecture of the system is decided.3. ImplementationThis phase is where the code gets implemented for the project.4. TestingThis phase contains an in depth testing of the code and corrections of bugsthat are found.5. DeploymentThis phase contains development of a deployment method and deployingthe project at the client.6. MaintenanceAdditional �xes of bugs or other types of issues found in the productioncode. 16

The waterfall process has a simple work�ow. The developers start by a longperiod of planning in the beginning. After the requirements from the client andthe architecture have been decided the implementation phase starts. The ideabehind the waterfall process is that later architectural changes are expensiveand therefore the software design phase should be extensive and �nal after thedesign phases.

Figure 2.8: Shows the Waterfall process from the begining (Requirements speci�ca-tion) to the end (Maintenance).2.3.2 RUPThe Rational Uni�ed Process (RUP) is an iterative development process. Itwas developed by Rational Software as a framework where developers couldcustomize the process for their speci�c project needs. The core of RUP wasdeveloped by observing successful software projects and incorporating their bestpractices.RUP is a two dimensional process(see Figure 2.9) where the �rst dimension isthe phase the project is currently in and the second dimension is the disciplines(the activity) in the project. The phases in RUP are:• InceptionThis phase include initial business analysis and validation, risk analy-sis and de�ning project descriptions, use cases and requirements for theproject.• ElaborationThis is the phase where the initial architecture is designed and the primaryrisks are mitigated. 17

• ConstructionThis is the phase where the code is written for the project. Every iterationof this phase should deliver an executable.• TransitionThis phase is the transition from development to deployment of the soft-ware system. The system is also validated against the requirements set inthe inception phase by the client.These phases are similar to the ones in the waterfall process. The di�erencebetween the waterfall phases and the RUP phases is the fact that the RUPphases have an iterative work�ow inside of them and at the end of each phaseare a couple of milestones and criteria that must be met to continue to the nextphase.The second dimension(see Figure 2.9) of a RUP based project is the dis-ciplines. This is the actual work that is being done. There are nine di�erentdisciplines[15]:• Business ModelingHandling the business side of the project, deciding strategies and analyzingthe business strategies.• RequirementsDeciding the scope of the project, understanding the requirements fromthe client or stakeholder.• Analysis and DesignAnalyzing the requirements and designing an architecture.• ImplementationTransforming the design and architecture to executable code and also dobasic testing.• TestIn depth testing, validation and quality control of the code.• DeploymentPlanning a delivery method for the project and deploying it at the enduser.• Con�guration and Change ManagementManaging versions and changes to the project. Handling change requestsetc.• Project ManagementManagement of the project, directing the developers in the right directionand making sure the project is delivered on time.• EnvironmentManaging hardware and software tools that are needed in the project andmaking sure they are available for the project team.18

One important property of RUP is that all of the disciplines are running inparallel as seen in Figure 2.9. This makes the process more dynamic to changesthat may occur in the project.

Figure 2.9: Shows the disciplines and phases in the Rational Uni�ed Process.2.3.3 ScrumThe scrum process is an agile and iterative process that is a bit more relaxedthan other development processes. The scrum process is more of an abstract de-velopment process, where it lets the team itself solve problems instead of forcingextensive project planning or project managers that decide what every membershould do. It instead lets the team decide together as a group where everymember has a voice. A scrum project has three di�erent roles that members inthe project can have:• Scrum Master: is the person who maintains the process (similar to acoach) and makes sure the project continues smoothly.• Product Owner: this role is the person or persons that represent theclients or stakeholders of the project.• Team: this role represents the team that will do the actual work. Theteam consists of about �ve to nine members.Scrum is built on two backlogs, Product Backlog and Sprint Backlog. TheProduct Backlog contains all the features that the developed system will contain19

which is decided by the team and the Product Owner. The features in theProduct Backlog are prioritized by there business value and development e�ortwhich is decided by the Product Owner. The second backlog, the Sprint Backlogis used as a short-term to-do list for the developers; it contains the highestprioritized features in the Product Backlog.Scrum has a couple of phases, a planning phase where the features are de-cided and a development phase which is called a sprint. It all starts with ascrum planning meeting where the team decides which of the features in theProduct Backlog to implement during the coming sprint. The chosen featuresare then broken down into smaller tasks and added to the Sprint Backlog whichacts as a task list to �nish at the end of a sprint. The Sprint Backlog is then�nalized before the sprint starts, which means new tasks will not be added tothe backlog until the sprint has �nished. A sprint can be between two to fourweeks long (see Figure 2.10). There is a progress meeting every morning whilethe sprint is running where every member in the team describes what they havedone this far and if there where any problems within the development. Thedaily meetings continue until the end of the sprint. At the end of a sprint, theteam delivers an executable of the system and tasks that where not �nished ismoved from the Sprint Backlog back to the Product Backlog and re-prioritizedfor the next sprint.

Figure 2.10: Shows the scrum process with its backlogs and iterations. Source: http:// commons. wikimedia. org/ wiki/ File: Scrum_ process. svg2.3.4 Code and FixThe Code and Fix process is the most basic and the more common of theprocesses. It is not a deliberate development processes but is more like humannature, less experienced developers or developers under pressure usually turnsto this type of development. The process starts by the developer writing codewithout any planning or initial work. Then in later stages comes the testing of20

the code and corrections of bugs that's been found in the testing and �nally isthe delivery of the system.

21

Chapter 3Analysis of RNHThis chapter will be going through the current state of a block in the RNHSubsystem. The results of the analysis is split into di�erent sections lookinginto di�erent areas of the subsystem such as the architecture, the UML model,the state of the current source code and the development process.3.1 RNC/RNHA RNC (Radio Network Controller) is an integral part of a telecommunicationsystem. There are di�erent types of telecommunication systems but the RNCis part of a system called WCDMA which is used as a 3G mobile telecommu-nications network. A WCDMA system consist of multiple di�erent layers, themain layers are the RAN (Radio Access Network) and the core network. Thecore network is the main communication backbone where data is transferredand handled between di�erent mobile phones. This is where all the administra-tion of a users subscription is done it also handles the communication betweendi�erent operators and the Internet.The RAN is the actual radio network where the RNC s and the RBS s (RadioBase Station) are placed as seen in Figure 3.1. The RAN handles the radiocommunication between mobile phones and the core network.

22

Figure 3.1: Shows an example of a WCDMA system.The job of an RNC is to keep track of a mobile phone so that it can trulybe mobile and move around and switch RBS s without any interruption in thedata �ow. It is also tasked with the job of handling resources in the connectedRadio Base Stations, resources as radio output power and user bandwidth.The RNC is built on many di�erent subsystems that each have there uniquefunctionality. One of these subsystems is the RNH (Radio Network Handler).The RNH is the subsystem that handles the con�guration of RBS s. As itis shown in Figure 3.2 the RNH is also divided into blocks that divide thesubsystem into smaller and more maintainable packages.

Figure 3.2: Shows the structure of the RNC and its subsystems.23

3.2 Problem AnalysisThe block that is being analyzed in this thesis is called the RnhCellBl or morecommonly known as the Cell block and it is one of the more severely a�ectedblock in the subsystem. The Cell bock is a package in the RNH Subsystemwhich contains representations of all the Cells that are connected to the RNC.The main job of the Cell blocks is to con�gure and keep track of the currentstates of all the Cells. Because of this the Cell block has a vary centralized rolein the system as each new con�guration change to a Cell must be done throughthe Cell block. Some of the current con�guration options that the Cell blockhandles are: adding and deleting a Cell, power control parameters, locking andunlocking a Cell, changing con�guration options of a Cell etc.The analysis of the problem was conducted by small interviews and discus-sions with some of the members of the development team. All of the interviewedsubjects where well versed into the subsystem, they all had �ve to six yearsof experience in the system but not all of them had worked directly with thespeci�cally analyzed Cell block. The main consensus in the interviews about theproblem was the size of the Cell block and its centralized role in the system. Asmany of the new features need to either read a state or change a con�gurationoption in a Cell new functions needs to be added to the Cell block to be able tohandle the new options. One of the main reasons for this is its centralized rolein the system and the time constraints on the development team. It is fasterfor a developer to add or change a piece of code or diagram in the Cell blockthan writing a more sustainable implementation. This causes the block and thecomponents in the block to be bloated and grow out of hand, this is a largeproblem.The impact of the overgrowth problem is quite costly. The large size ofthe block makes the development in it di�cult and more time consuming. Theextra time it takes to develop in the Cell block can in some cases generatelong queues for other developers to be able to access and develop in the block,this increases the overall development time of the system mainly caused by theblocks centralized role in the system. One of the more critical areas that area�ected by this is the testing of the Cell block. The testing of the blocks su�ersdue to the size and complexity of the block. It is di�cult to implement newtest cases for such a big block which in turn makes the testing incomplete andleads to more bugs in the code which are not detected earlier in the developmentwhich could save time and money.Another problem that some of the interviewed developers put forward is thefact that Ericsson is not a small company, in fact it is a multinational companywith many o�ces all over the world. So there are many di�erent cultures at playwhen developing such a large software system. With all these di�erent culturesand people comes di�erent views on how to write software which introducesinconsistencies in the code. But the inconsistencies does not only come fromthe di�erent cultures in the company but also from the block itself as it is acouple of years old and it has gone trough many changes and iterations that hasintroduced code that also needs to be backwards compatible with older parts of24

the system which in return introduces even more inconsistencies.3.3 Code Analysis3.3.1 ArchitectureThe Cell block is a quite dense package. It contains three capsules containing allthe logic for the block and about 30 data classes, where only two of the capsulesare the more important components in the block. The �rst of the two capsulesis a handler class which is called the CellHndl (Cell Handler). This capsule actsas a manager or container for the second capsule which is where the main logicis implemented and is called the CellRo. A CellRo object is an instance thatmaps to a single Cell, its job is to keep track of its state and its con�guration.The handler's job is to keep track of all the instances (see Figure 3.3) of theCellRo and route signals that come in to it to the right instance of the CellRo.

Figure 3.3: A UML object diagram. This diagram shows the relationship between theCellHndl and the CellRo capsules. The CellHndl is used for routing incoming signalsto di�erent CellRo instances.The reason for this structure is to have a central point where all the CellRoinstances can be accessed and to have a central point where global con�gurationoptions for the Cells can be set. Instead of requiring external classes to �nd acorrect instance of a CellRo, the handler class is used to route signals that arereceived to the correct instances of the CellRo. This structure is in a way similar25

to a client-server architecture where the outside capsule represents a client andthe CellHndl is the server that assigns a �thread� (CellRo) to handle signalsfrom clients.3.3.2 ModelThe model of the system is built in RoseRT with UML-RT. The UML is usedfor describing the structure and the architecture of a system. The UML alsodescribes how di�erent components and packages in a system are interconnected.This helps to abstract the development to a higher level and also simpli�es thedevelopment.The model of the capsules consists of two diagrams that describe the capsulein detail. The �rst diagram describes the behavior of a capsule by states andstate transitions. A states represents a snapshot of the current values in thecapsule and all its variables. It also shows the possible transitions that areavailable in the current time of execution. A state is in it self a new statediagram that can contain sub states and transitions. The state diagram is alsowhere the actual code is written as actions when a transition is executed.The second diagram in the capsule model is the structure diagram. This iswhere the static structure of a capsule is described and de�ned. It consists ofsub capsules, ports (and its protocols), connections between di�erent ports andend ports that sends signals in and out of a state chart.StructureThe CellHndl capsule is relative to the CellRo a bit smaller in complexity andcode size. The handler mostly contains logic for routing of signals or sendingcon�guration changes to CellRo instances and representing a central point fordistribution of con�guration data to other blocks. As it handles all the instancesof the CellRo capsule it needs to route all incoming signals to the correct CellRoinstance which gives it a set of duplicate ports of the CellRo capsule.The Cell block does not in it self have a visible function for normal phoneusers but is rather a backend management object with some part of a �functionrouter�. As the CellRo is the �rst point where messages from a Cell is received, ithas the job of analyzing and routing of those messages where the CellRo checksthe incoming messages from a single Cell and decide which block or subsystemto forward the message to (see Figure 3.4). It also contain logic for receivingstatus changes from a Cell in a RBS and sending con�guration changes back tothe Cell.26

Figure 3.4: Shows the routing in the Cell block. The Local cell is an external blockin a RBS that are connected to the actual Cell hardware.The growth of functionality in the Cell block has required many di�erentsplits over the years. The splits of the Cell block have often led to new blocksand capsules where larger functions have been moved to. These external cap-sules are now connected to the CellRo as sub capsules instead of being directlyimplemented in the Cell block. But the Cell block is now forced to route mes-sages for the speci�ed functions into correct sub capsules. In the current statethe CellRo has about 11 sub capsules that are part of functionality that hasbeen split of of the CellRo.The CellHndl and CellRo have combined over 100 ports. Some of theseports are similar where one port is in the CellHndl and is designed to receivesmessages for all instances of the CellRo. The CellHndl then routes the receivedmessages to the correct instance of the CellRo. The protocols used by the portsare di�erent from each other. Some protocols are larger than others and containa large amount of data. The data is categorised as signals where each signalis an instance of a single data type. The signals vary in type where some aresimple integers and others may be large data objects or pointers to di�erenttypes of data values.BehaviourThe behavior of a capsule is detailed in a state diagram with the help of transi-tions. The transitions consist of a trigger and an action code. The trigger is a27

signal that contains a data object that is speci�ed in the protocol. The signalitself is a message that is sent between di�erent connected ports. The triggersspecify which transition that will be run depending on what signals where re-ceived by the capsule. This is the core basis of a real-time system and createsan simple overview over the execution �ow in a capsule.One of problems with state diagrams is that it can easily become very com-plex. One of the reasons for this is because the state diagram being a visual tooland as such can easily be cluttered by many states and transitions. There areduplicate transitions that are in di�erent levels in the state diagram that havethe same functionality but are executed at di�erent states, this is another levelof complexity which introduces bugs when changes are needed in these types oftransitions where only one of the transitions are corrected. Because transitionsare private to a capsule it becomes easy to add new transitions without any ex-ternal consideration as the transitions don't have any external dependencies andare not visible to the outside. The current development direction of the transi-tions is to have a new transition for every trigger signal. This leads to a statediagrams being �lled with many transitions which makes the diagram harder tooverview and decreases the visibility. This is another problem that exist in boththe CellHndl and the CellRo capsules (see Figure 3.5). Other problems thathave been detected in the implementations of transitions are there names, theredoesn't seem to be a standard naming convention for the transitions. Some ofthe transitions have the name of the trigger signal that triggers the transitionothers have a mix of trigger signal, port name and port cardinality.

Figure 3.5: Shows the distribution of transitions in the CellHndl and the CellRo.Another issue that may arise as the development continues is the property28

of the states in a state diagram, as each state is in it self a state diagram it caneasily become a large tree of di�erent states nesting multiple new state diagrams.This can be very disorienting and increase the complexity of the capsule andprevents developers to gain a good overview, instead it creates uncertainties inthe development. The Cell capsules are at the border of having too many statelevels, where they each have three levels at the most as seen in the Figure (seeFigure 3.6).

Figure 3.6: Shows the amount of states and state levels.3.3.3 Source CodeThe �rst impression of the actual C++ code is that it has been written andmodi�ed by multiple developers with di�erent coding styles and backgrounds.Some of the code is easy to examine and get a good overview over and otherareas of the code are more di�cult and not as easy to understand.The most di�cult part for an outsider or a new developer to real time pro-gramming is the core idea of RoseRT, that is a UML based development tooland a real-time system development platform. The basic explanation is thatthe code in a sense is event driven. The code is directly connected to the UMLmodel that is drawn in RoseRT by the developers. The majority of the writtencode is the body code of functions and transition actions. This can make a de-veloper disconnected from the overall code of the system where the whole codebase is not directly visible but rather is wrapped around a GUI with tables ofparameters and attributes. 29

StructureOne of the �rst things that are seen in the structure of the CellRo is thatit contains a large amount of data �elds and functions (see Figure 3.7). Thefact that the majority of the internal �elds and functions are undocumentedintroduces more di�culties with developers not as familiar with the capsules.

Figure 3.7: Shows the distribution of di�erent properties in capsules and classes.Most of the �elds in the CellRo capsule are state values and con�gurationoptions of a single Cell. The CellHndl contain a couple of lists, a main list of allthe instances of CellRo capsule that it handles and multiple tables that containrouting information where speci�c values map to di�erent instances of CellRo.The Cell block also includes about 30 standard C++ classes that are usedas data classes internally. The majority of the data classes do not contain muchlogic for handling data besides storing of data values. Then there are over 40other simple data classes that are used in protocols for sending more than onedata value. These classes do not contain any function but only public �elds foreasy reading and changing of values in the code. The classes are used in about17 protocols that are speci�c to the Cell block.One of the problems detected in the Cell block is the lack of a centralizedcon�guration component. There is a con�guration block named ShareData thathave been created for this propose but is not widely used. The con�gurationvalues that are used are spread out in di�erent areas where some of the valuesare in ShareData and some are locally stored in a capsule. This creates aninconsistency that makes the code di�cult to read. There are many reasons whythis problem exists one of them is the lack of design rule for using a centralizedcon�guration component. There's also no easily accessible documentation for30

the use of the ShareData block which makes it more di�cult to utilize and mightdiscourage developers from using it.3.4 Development Process AnalysisThe use of a development process in larger projects is an important part ofmaking the implementation phase more organized and e�cient. The processesgive the developers a sense of structure and a reachable goal. The goals arespeci�c objectives that the team must meet at speci�ed time frames or at theend of a phase which helps to give a reachable milestone in a project. Theprocesses also help the project leaders to evaluate the progress and the scope ofa project.The development process that's currently used by the RNH department andthe rest of the RNC developers is a variation of the waterfall (see Subsection2.1.3) development process. This is a short and overall description of the phasesin the process:• The process starts with the project managers giving the go ahead for theproject with subsystem level speci�cations for all the new features that willbe included in the new version of the system. The speci�cations includesbesides a description of the new feature a sequence chart that describes inhigh level the interaction between the di�erent subsystems.• The speci�cations are then handed over to the subsystem teams that breakdown the speci�cations into smaller block level interactions. The teamsalso checks if there is a need for a refactoring in a speci�c block or if somecomponents should be moved to a common block.• The third phase is where the speci�cations and the change requests fromthe �rst phase is inspected and determined if they are su�cient and goodenough to continue in the process.• The fourth phase is the implementation stage and it is where the actualcode for the features is written. This phase should in some extent overlapthe development of the block test.• The �fth phase includes the analysis of how the block testing of the newfeatures will be done.• The sixth phase is where the test code of a block is written, this phaseis run in parallel with the implementation phase to interconnect the twodevelopment phases.• The seventh phase is where the block tests are executed. The test codethat has been previously written will be run to check that the implemen-tation of the features follows the speci�cations and errors that are found31

is corrected.• The eighth phase continues the testing but in a subsystem level. This isdone by an external team and not the actual subsystem teams. It beginswith the analysis of how the subsystem tests will be implemented.• The second part of the subsystem testing includes the implementation andexecution of those tests.• The ninth phase is where the subsystem teams update the documentationsfor the subsystems.• The last phase in the process is where the teams release their code tothe maintenance team. This phase starts when the project managers de-cides that the code base is stable enough for a release. The maintenanceteam maintains the released implementation while the development teamcontinues with the next version and starts the process again.

Figure 3.8: Shows the currently used development process at Ericsson.The Ericsson software development process is a milestone based process as thewaterfall process where each phase requires code or speci�c documents to bewritten to be able to continue to the next phase. But contrary to the waterfallprocess the Ericsson process also has some input requirements in each phase thatensure that the material needed are ready before a phase starts. This propertygives the Ericsson process the ability to run some of its phases in parallel as32

the main implementation phase and the block test implementation phase (seeFigure 3.8). The process runs in a higher level, as it does not only encompassa single team but rather multiple teams that each has speci�c phases that theyare assigned to. For example some of the teams are:• The project management team that decides the features that is includedin the new release of the software.• The development team that designs and implements the features.• The subsystem testing team that runs tests on the subsystem level.• The maintenance team that maintains the system after release.The main problem with the standard waterfall process is that it does not allowfor the evolution of a software system. The process has no iteration where thecode can be refactored and evolve into a better and cleaner structure. The pro-cess itself is good but is more suited for people that are not directly involved in aproject but still makes the big decisions as project managers where every phasein the process is documented with speci�cations that must be approved. Thisgives the upper level management a good birds eye view over the project butit also prevents the developers to be more creative and more agile where everyfeature and change in a project must be speci�ed and approved in the speci�-cation phases before any actual development is done. This is where the mainproblem of the waterfall process arises, the lack of iteration or refactoring in thedevelopment process. An e�ect of this is that problems in the speci�cations aredetected late in the implementation phase and they can not easily be changedbecause the design phase has already been completed and approved. In thiscase Ericsson have included a consideration in the �rst speci�cation phase if arefactoring is needed in a block. But this does not directly include refactoring inthe development but rather as an option. By having the refactoring as a optionit is often not considered because of di�erent time constraints that are neededfor delivering a new version of the system in time.

33

Chapter 4Evaluation of AnalysisThis chapter will go through the analysis from the previous chapter. There willbe discussions on some of problems in the current structure of the system. Therewill also be some suggestions and discussions on di�erent possible solutions thatmay be applicable to the problems. But the chapter will begin with a smallsummary of the analysis chapter.4.1 Analysis SummaryThe following summarizes some important points from Chapter 3:• New features in the system often require the introduction of new functionsand properties in the Cell block.• The testing of the Cell block su�ers due to the size and complexity of theblock.• Many sections in the system model and in the code are undocumented.• The Cell block is an overly dense package with a large amount of func-tionality which leads to information overload and code clutter.• The lack of a centralized data storage component leads to data and con-�guration options being spread around the code base.• Development in the Cell block can generate long queues for accessing theblock.• Time constraints hinder developers from writing good and clean code.• Di�erent development cultures and people lead to di�erent views on howsoftware should be written which introduces inconsistencies in the system.• The development process used (based on the waterfall process) has noiteration or refactoring included in its phases.34

4.2 Solution StructureThe analysis of the Cell block has described the current structure and state ofthe block. The current basis of the code has now been established and some ofthe problems that arise by using these coding styles have been mentioned. Itis now time to evaluate the problems found in the analysis and suggest di�er-ent solutions if any are possible. But before developing recommendations andsolutions there needs to be some basic foundation on how the solution will beimplemented.There are many ways of improving the Cell block. One of the more drasticways would be to completely halt the development and rewrite the entire blockfrom the ground up with a better and more long-term architecture. A rewriteis often the best solution for larger and older software projects. As with arewrite there is no need for any consideration for backward compatibility orother similar requirements. One problem with this would be the need to suspendthe development for a considerable amount of time while the block is beingrewritten. This is not a feasible solution for systems or products that are partof a market with large amounts of competition where a delay in the developmentcould mean a loss of market share.Another way of approaching the problems is to use the existing code but touse refactoring to improve it. This would not require a complete stop in thedevelopment but rather to be a part of the development process. Refactoringcan be integrated in many di�erent forms into a development project either as:• an explicit guideline• a core feature of the development process• or a more discrete part of the code review process.4.3 The Development ProcessThe development process that is currently used by Ericsson is quite old. Asdescribed in Section 3.4, it does not take into account the evolution of a softwaresystem. This is mainly caused by the lack of code prototyping. There are manynew development processes that try to solve this problem by using iteration.By integrating iteration into the process the development gets the bene�ts ofrefactoring in the process. Where the core idea of refactoring is to go back andreevaluate existing code and to apply the current requirements that might nothave existed at the time of writing the code. This is a necessary step for manylarger software systems that changes frequently where there is no certain wayof knowing the future use of a code segment.One of the reasons for the overgrowth of the blocks is the di�culty in know-ing the future of the code. As new features are introduced into the code basethe code grows but not always in the right direction because of the lack of refac-toring. With an iterative process a code growth could more easily be detected35

and handled appropriately much earlier in the development process of a featurewhich would lead to a better structure. The current practice at Ericsson includesa code review process where before an implementation of a feature is releasedit needs to be reviewed by another developer that is familiar with the Ericssoncoding guidelines. But as the code review is at the end of the development it ishard to do large changes as the development is at its end. This could be solvedby introducing incremental reviews based on time or sub goals other than the�nished implementation of the code. This could encourage the reviewer to pro-pose changes to the direction of the development. It would also encourage theauthor of the code to go back and recheck his code for improvements.A more radical solution would be to change the development process en-tirely. This would be the best long-term solution as there are more modernprocesses that have been created especially for software development. Wherethe new processes integrates some degree of mandatory refactoring by the wayof iterations (see Section 2.3) and prototyping.4.4 ArchitectureThe architecture is the foundation of a system and as a foundation it is the oneaspect that controls the success of a system. But how is a successful systemde�ned? There are di�erent types of views of a successful system, one of themain views is from an economical perspective, but as this thesis is more directedagainst the development perspective the actual structure of the system will bethe main area that will be looked at. So what are the factors in a successfulsystem from a development perspective?• Stability• Maintainability (see Subsection 2.2.2)• Extensibility (see Subsection 2.2.2)What does stability mean in the context of a software system? A stable systemis considered as an application that has reached a speci�c level of maturity. Thematurity is determined from the fact of the system being able to run withoutany major problems, this does not mean that the application is bug free ratherthat it contains an acceptable amount of bugs that do not interfere with criticalfunctions of the system. Stability is in itself not something that is part of anarchitecture but rather a result from an architecture that has been laid downfor the application.4.4.1 MaintainabilityMaintainability is an important part of an application. The maintainabilitydescribes the ability to maintain or troubleshoot problems that may occur inan application. This is an important part in an applications life after its releasephase where problems can be detected that where not found in the testing36

phases of the development. A big tool when maintaining a software systemis the documentation. As many developers have experienced the fact that it isdi�cult to return to code that was written some time ago and even more di�cultwithout any good documentation that describes the functionality behind thecode. The documentation is especially important when the development andthe maintenance of the code are handled by di�erent teams. This is one ofthe problems that exist in the Cell block where the majority of the �elds andfunctions do not have any overall documentation. The most common cause forthis is that the documentation is simply forgotten where only some of the codegets documented. This is also part of the di�erent cultures at Ericsson whereevery developer has its own coding style where some write large amounts ofdocumentation and others don't write at all. Another possible reason is fromthe development process where the documentation phase is run at the end ofthe development which makes it hard for a developer to go back into code for alarge feature where allot of code has been written.Other factors that can improve the maintainability of an application is thearchitecture, as maintainability mainly focuses on troubleshooting existing code,it introduces the need to have a good code structure where troubleshooting isin focus, so a developer can easily follow events in the code base, which couldbe solved by simplifying the capsules and their models as described in Section4.5. This is one of the areas where the CellRo needs the most work as describedin Subsection 3.3.2 the CellRo contains a large amount of information whichmakes the troubleshooting especially di�cult.The most important area for maintainability is consistency. As there aredi�erent teams that is handling di�erent phases of the development process,so there is a need for some standardized rules for writing code and designingdiagrams. This does not only apply to the architectures but also the lower leveldevelopment as component placements in diagrams and code structures. This iswhere Design patterns come to play. Design patterns are somewhat standardizedpatterns for solving structural problems. These patterns are normally used forarchitectural guidelines but can equally be used as micro architectural patternsin smaller scale for improving the design of code. The main property of thedesign patterns are that they are standardized so that every developer canrecognize the pattern used without the need to know more in-depth details ofthe code.4.4.2 ExtensibilityExtensibility is another important area of an applications success. Extensibil-ity is part of the applications evolution. There are always new features andfunctions that are implemented by the developers, sometimes by the request ofclients. Extensibility is the ease of adding new features to an existing systemwithout changing the existing code. This is an important point in a good ar-chitecture where everything is built in layers. The idea behind extensibility isto be able to add new features to a system by creating new classes on top ofthe existing structure without having the need to change any underlying code.37

There are many ways to achieve good extensibility in an architecture but one ofthe more signi�cant areas is to have a good hierarchy of classes. The Cell blockin its current state lacks a hierarchy where the CellRo is the only object thathas logic and data for handling a Cell and thereby needs to be altered quiteoften to adhere to new features.There are di�erent ways of improving the extensibility of the Cell block. Onepossible solution would be to radically split the CellRo capsule into multipledi�erent smaller classes that handle di�erent parts of a Cell. This is a possiblesolution because of the nature of a capsule where functions and data �elds in acapsule are all private, so there should not be any dependencies outside of theCell block itself. This would also make the state machine smaller and cleaner.The larger question is how this larger split or redesign of the Cell blockshould look like? There are many di�erent architectural patterns that are usedtoday in the software industry. A suitable architecture would be a modi�edversion of the widely used MVC (Model-View-Controller) architecture. TheMVC has been designed for applications that mostly focus on user interfaces,as this is not a requirement for the Cell block there needs to be some changes.So a new architecture is introduced, a new modi�ed version of the MVC calledMSC (Model-Switch-Controller). The MSC has the same structure as the MVCbut instead of having a view component (user interface) it has a switchingcomponent (a transmission layer).Here is a description of the MSC in a UML-RT system context:• ModeThe model consists of data components that contain all data and con�gu-ration options in a system. This can be a database or a collection of dataclasses for handling of data.• SwitchThis component is the initial point where messages and signals are re-ceived. The propose of this component is to switch or route signals toappropriate components as other switching components or to its own con-troller. This component would most likely be a capsule.• ControllerThe controller is the point where the signals are handled. The receivedsignals will initiate actions depending on the triggers. The actions willeither change values in the model or execute some internal tasks. Thecontroller should be a sub capsule of the switching component.As described by the components and in Figure 4.1, the �ow of a signal start in theswitching component. The switching component can be compared to a routeron the Internet, routing signals to the appropriate destination as a controlleror other switches. The second layer contains the controller component (whichin the Internet comparison can be seen as a host computer) that contains theactual logic for handling signal. When the controller receives a signal it willexecute speci�c code for handling the signal that may change values in themodel component. 38

Figure 4.1: Shows an example of a message �ow in an MSC architecture. Theexample is based on the Cell block with the CellHndl and the CellRo4.5 Model and VisualsThe models are in their core a visual medium. They are mainly used for sim-plifying structures to more human readable elements. This is a good mediumfor describing the structure of a system but it can also have drawbacks. Theproblem with source code is that it is di�cult to see a larger overview over asystem when looking at text, mainly because of the level of detail. The sourcecode describes the system in to much detail which makes it hard for a developerthat has a small amount of experience with the structure to understand theconnections between di�erent blocks and classes. This is why a model based de-velopment platform is used. It increases the visibility of a structure by splittingit into smaller and more abstract layers. Every layer describes a small part of asystem in an abstract way but it also has the ability to be more detailed whengoing deeper into the layers until you �nally reach the actual C++ source code.But there are problems with a visual model to. One of the problems is thesame as when only developing with source code and that is information overload.It is di�cult to examine a diagram that is cluttered, as seen in the analysischapter of this thesis the CellRo has this problem (see Subsection 3.3.2). Themain contributor to the problem in the CellRo case is the amount of transitionsand their uncategorized nature; Figure 4.2 shows an illustration of a state inthe state machine of the CellRo. The �gure clearly shows that such an amount39

of information is di�cult to examine when there is no clear and simple patternto the diagram. This is especially di�cult when troubleshooting, as the actof troubleshooting a problem involves following a speci�c path of signals thatinvokes code-segments that may contain some bugs.

Figure 4.2: Shows an illustration of a current layer in the state machine of theCellRo. The arrows in the �gure represent self transitions in a state. The transitionnames have been replaced with randomized names.4.5.1 TransitionsAs a visual medium there are many ways of improving the overall visual pre-sentation of the diagrams. As it is shown in Figure 4.2, on a �rst look there donot seem to be a structure behind the transitions. This immediately creates ahurdle for a viewer to get over. It can be compared to a dictionary where theorder of the words is random, it would be impossible to �nd a speci�c word.Fortunately this is not as extreme as a randomized dictionary but it su�ersfrom the same problem, there is no directly visible structure to the model. Thesolution is to create a prede�ned order for grouping the transitions. There aredi�erent possibilities for grouping transitions together either by:• Port name• Source Capsule name 40

• A feature group that the transition corresponds toThe most trivial of the listed groups is sorting by port name, the others arealso good for looking up transitions at certain moments but they are not assimple and generic as the �rst suggestion. By grouping the transitions togethera simple index is created which makes looking up a transition much easier asseen in Figure (see Figure 4.3).

Figure 4.3: Shows an illustration of an improved state in the state machine of theCellRo where the transitions have been grouped together by port names.Another option for grouping transitions is to group them by state level.Instead of having all transitions in the same state they would be distributedaround in di�erent nested states creating a stair like structure. This couldwork for a small amount of transitions but is not really scalable where it wouldintroduce more complexity rather than simplifying the model, it might also haveperformance implications.Other ways of improving and simplifying the state model would be to com-bine transitions together. By combining transitions the state diagrams gets asimpler and a cleaner structure with a decreased amount of components. Butthere is a catch, this will move a large amount of code into a handful of tran-sitions which would not solve the problem of information overload but rathermove the problem into the source code. This is why a balance needs to be41

reached between transitions and the amount of code in the transitions. Onepossibility is to introduce a common transition for each port that merges allthe smaller transitions containing a small amount of code (up to four lines).Internally in the source code the combined transition would execute a switchcase to identify the trigger to run the correct action code. This would decreasethe amount of transitions in a state as seen in Figure 4.4 but it goes against theprevious suggestion of keeping the transition codes as small as possible, as theamount of merged transitions will increase the size of the combined transition.

Figure 4.4: Shows an illustration of a state with common transitions which are tran-sitions combined of multiple smaller transitions.The introduction of port names as comments also helps with the naming oftransitions. Naming components is an important part of improving visibilityin diagrams, but most importantly improving the understandability of models.There is a large amount of literature that emphasizes the importance of namingconventions. It is imperative for the visibility of code to have short but strictnaming of �elds and variables. The same applies to the diagrams, but there ismore information that must be conveyed with a transition, information as: portname, port destination, protocol, trigger, action code etc. With the previoussuggestion of port names as comments solves one part of naming the transitions.One of the more important information to display for a transition would be thetrigger name as it de�nes the core event that will execute the transition and its42

code. The improvement of the trigger names also improves the maintenance ofthe model as it makes it possible to easily move from a structure diagram to astate diagram.The grouping and naming of transitions are part of a larger solution whichis visual documentation. The need for documentation is not only required insource code but is equally important in the state and structure diagrams. As thediagrams can become overly complex it leads to the importance of documentingthe behavior in the diagrams. It is also important to note that visual docu-mentation is a human tool and is completely transparent for a computer. Thismeans that there is no need for any performance or other application relatedconsiderations when adding documentation. Another area of visual documen-tation is the structure and visualization of the diagrams. As more componentsand transitions are added to a diagram the more important it gets to keep inmind the visual representation and structure. The improvement of the struc-ture is dependent on the arrangement of its components in such a way thatit simpli�es and clears up the diagram. An arrangement such as the connec-tions between components should not cross each other, where this would makea diagram easier to understand and overview to a viewer.4.5.2 Ports and ProtocolsPorts and protocols in UML-RT are the only publicly visible components in acapsule. They can be compared to public functions in standard C++ with thedi�erence of the ports only accepting signals from other ports. As the portsare the only visible component outside of a capsule they act as an interface forexternal capsules. As described in the analysis chapter (see Subsection 3.3.2), alarge portion of the components in the CellRo capsule is for switching signals toother sub capsules, most of these components are ports or relay ports (ports thatare used for relaying signals to sub capsules). Continuing the work of simplifyingthe diagrams the components used for switching could be move to a new capsuleby following the MSC architecture model (see Subsection 4.4.2) to split of thecomponents used for switching from the actual logic. This would clear up someof the complex logic from the CellRo capsule and might also improve throughputof the Cell block as the switched signals would not be delayed by execution ofslow logic code.4.6 CodeThe source code in a RoseRT project is not directly visible to a developer,as the actual C++ code is integrated into transitions, states and other typesof components. This makes all the code written in capsules private to otherclasses which in turn hinders the reusability of the code. This in turn leads tothe problem of the Cell block being to complex and dens. There are di�erentsolutions that can be applied here but the underlying principle is to simplifyand make the capsules more extensible.43

One solution would be to see a capsule as only a trigger component whichwould have a small amount of code that calls functions in standard C++ classesthat contain the actual logic. This is a good way of minimizing code in a capsulebut might not be suitable for a capsule with a large amount of signaling asstandard classes do not have access to ports and other types of components in acapsule. Another solution might be to use the MSC architecture(see Subsection4.4.2).By following the MSC the CellRo would be divided where a large amountof components would be in a switching capsule but without any code exceptfor special switching logic. The remaining logic would be placed in a controllercapsule that would contain the majority of the logic code for handling of signals.This would simplify the structure of the capsule but there are more improve-ments that can be made in the CellRo. As the current CellRo also containa large amount of con�guration options that can be moved to data classes asdescribed by the MSC, this would also move a large amount of functions thatare currently in the CellRo for handling of the internal variables. This structureshould improve the structure and the visibility in the CellRo capsule but notonly that it would also be more extensible as the data structures would not bedirectly implemented into the CellRo capsule.There are also smaller and more low level areas that can be improved in thesource code, some of these areas are public data �elds and long function names.The importance of consistency in the code is immediately realized whenlooking at the code of the Cell block. As di�erent developers have di�erentbackgrounds the need for a common ground is a critical part of the e�ciencyof a development team. This is where standard design patterns come to play.Standard design patterns can be the common ground where all the develop-ers can come together and �speak� the same language. This will improve thestability of the system as there will be fewer bugs because of unclear usage ofcomponents and code.There are also smaller and more low level areas that can be improved in thesource code, some of these areas are public data �elds and long function names.These areas may seem trivial and not as important but they are the main pointswhere bugs and sticky dependencies are introduced.4.6.1 Data FieldsAs described in the Analysis chapter the Cell block consists of about 70 dataclasses that are used for various tasks. Some of these classes are used as datacontainers for sending data with protocols trough ports. Others are simple C++data classes for handling of data in and outside of protocols. These data classesare where the di�erent programming cultures and where the time constraints areclearly visible as a large amount of the classes have publicly visible data �elds.Most notably is in the classes that are used in protocols that are structured asdumb data object. Dumb data classes are mostly discouraged in the softwaredevelopment industry because they go against Object Oriented Programming(OOP). The main reason for this is the usage of public �elds lead to the owning44

class giving up control of that �eld which gives any other component in thesystem the ability to change the �eld. This introduces dependencies that maybe di�cult to uphold in the future and also complicates the veri�cation of data,as there is no clear de�nition on who has the right to modify the value ofthe �eld. This can be improved by simply following the OOP guidelines thatrecommends the usage of accessors instead of public �elds, as by using accessorsthe class gets a much greater control over its �elds and can handle veri�cationsof data itself when the data is being modi�ed and therefore eliminate the needfor external code to verify the values.4.6.2 Function parameter lengthsThe amount of parameters in a function might seem trivial but it can increasethe clutter and the complexity of a code segment, which is why it is designatedas a code smell (see Subsection 2.2.5). The main reason for the parameterlength being a code smell is that a function name might not give a developerthe information needed to easily understand the propose of the input parametersand what they will be used for, RoseRT as a development platform does nothelp either in this area as it was not designed with usability in focus. As seen inListing 4.1 it is di�cult to parse the meaning of the parameters in the functionwithout looking deeper into the actual function and its documentation which isnot an ideal solution.Rectangle obj ;obj . draw( arg1 , arg2 , arg3 , arg4 ) ;Listing 4.1: Shows an example of a non optimal function structure. The examplefollows a rectangle object.One of the reasons the code pieces in Listing 4.1 becomes di�cult to under-stand is that there is no real designation of what the parameters are used for.There are multiple improvements that can be made to this code smell:• A simple alternative may be to name the input variables in a descriptiveway, but it is not always possible as the variables may not have the samepropose as it is used in the speci�c function.• Document all the parameters before use (see Listing 4.2). This is a goodway of explaining the parameters but is not optimal for when the functionneeds to be changed as all the comments referring to the function alsoneeds to be updated through the whole code base.Rectangle obj ;obj . draw( arg1 , // x coord ina t earg2 , // y coord ina t earg3 , // width o f the r e c t ang l earg4 ) ; // h e i g h t o f the r e c t ang l e45

Listing 4.2: Shows an improved example of the function with comments describingits parameters.• A more suitable solution would be to require a custom data class as aparameter or to split the function into smaller functions, where the namesof the functions describe the propose of the parameters in a better way(see Listing 4.3).Rectangle obj ;obj . setX ( arg1 ) ;obj . setY ( arg2 ) ;obj . setWidth ( arg3 ) ;obj . se tHe ight ( arg4 ) ;obj . draw ( ) ;Listing 4.3: Shows an improved example of a function by splitting the function intosmaller more descriptive pieces.4.6.3 DocumentationThe documentation of a code base is an integral part of the e�ciency of asoftware development project. This does not refer to documentation or speci-�cations from the projects development process; it rather refers to the actualdocumentation of and in the source code. The previous two sections 4.6.1 and4.6.2 are small parts of improving the visibility of the code. The documentationis also part of improving the overall visibility by describing the actual usage andrequirements of i.e a function header. Where the need for analyzing the sourcecode of a function decreases as a simpel documentation of the function exists.

46

Chapter 5GuidelinesThis chapter will go through the results of the thesis project. The structure ofthe guidelines will be described and the resulting guidelines will be shown andsummarized.5.1 Guideline structureThe guidelines are divided into three di�erent categories. The �rst categoryconsists of simple guidelines for programming in pure C++. These guidelineswill be small and able to be implemented directly without any long term consid-eration. The second category is more directed at the UML model of the system,these guidelines will also as the previous category be quite short but may needsome more work than the �rst category. The last category will mainly focuson architectural guidelines for the system and because of this they will be morelong term, which implies that they will not be able to be implemented directlybut rather in a longer time frame.Simplicity is a very important property for these guidelines, they need to beeasy to understand but more importantly easily remembered. There are a largeamount of internal documents at Ericsson that has many good guidelines fordesigning and programming in C++ and RoseRT but they can be overwhelmingand are mostly focused on general coding conventions. The guidelines in thisthesis is designed to be a subset of the more general internal guideline and otherrecommended guidelines from literature while these guidelines will be more spe-ci�c for the issue at hand which is preventing unmaintainable overgrowth of thecode base.The main focus of these guidelines is to provide a direction for the developersto follow to:• Prolong the quality of code over a longer time. This will lead to an in-creased e�ciency in the development and troubleshooting of the code.47

• Get a cleaner code base that would make it easier to overview and under-stand the code.• Prevent the need to do a large and complex block split. A block split is amajor task that in the current situation is necessary and must be executedevery other year to keep the block manageable.• Simplify a block split by having clear boundaries between features. Byhaving clear boundaries where a block can be split will decrease theamount of time invested into a block split and a split would not be asof a big problem.Some of these guidelines might not work for a speci�c code segment where somespecial properties are necessary. So these guidelines should be seen more asrecommendations when developing in a block.5.2 Category 1: Coding guidelines• Avoid using public �elds in data classes, use accessors instead.This is part of basic Object-Oriented Programming, that a class should be closedfor modi�cation but open for extension (see Subsection 4.6.1). What this meansis that no external class should be able to modify internal �elds. External classesshould instead use accessors to retain the values and change values in an object.This gives greater control to an object to ensure that its �eld has a valid valueand also gives the developers the ability to change the internals of the objectwithout any external dependencies.• Avoid functions with long parameter lists.Functions with many parameters can be di�cult to understand because you asa developer do not have the right context for the parameters. The functionparameter length is described in more detail in Subsection 4.6.2.• Add comments describing the functionality of �elds and functions.Documentation is a critical part of understanding complex code segments. It iseven more important in an environment where there are large amounts of devel-opers who work in the same code base, where �elds and functions are explainedand may also have references to speci�cations that are part of a developmentprocess. (see Subsection 4.6.3)• Avoid using complex solutions when a simpler one is possible.There are many special features in the C++ language to combine code intosmaller commands but it is important to note that these features are not alwaysknown by other developers, so it is crucial that the code that is written �rstly isconsistent and secondly is written in a level where every developer in the projectcan understand and modify it.

◦ Avoid recursive functions.Recursion is a great way of writing algorithms; it sometimes decreases theamount of code and might even lead to some performance improvements.But it also introduces complexity into a code segment. The complexity48

mainly comes from the di�culty of following the �ow of the execution.This can make the maintenance of a system very di�cult when issues arewrapped around many recursions.• Try to be consistent with the existing code.Consistency is a requirement for having a good code base. Consistency has manypractical applications as reusing code. It is easier to �nd segments where codecan be reused when there is consistency in the source code, where all the codelooks the same which also makes the developers more e�cient in there devel-opment.This guideline becomes a necessity when developing in a large softwareproject (see Section 3.2).

◦ Use standard design patterns as much as possible.This continues the improvements to consistency. By using standard anddocumented design patterns it's more likely that the next developer thatlooks at the written code will understand the structure (see Section 4.6).• Try to reuse as much code as possible.Reuse of code is a good way of improving source code. It makes the structuresimpler by decreasing the size of a code block so that the information becomesmore streamlined and increases the visibility. This leads to a cleaner code baseand an easy structure to overview. This implies that the reused code should bemoved out of a capsule to be able to be used by other capsules in.

◦ Separate code that will change often and try to reuse that codeas much as possible.This guideline implies that code that is often changed or modi�ed shouldbe prioritized to be moved to a central place where it could be reused byother objects.• Be sure to not use protected �elds/methods outside of a block, RoseRTand the C++ compiler does not check for this.Using protected elements in code is a good way of improving the extensibilityof a class but it is important to note that RoseRT does not uphold the require-ments of protected elements; it rather treats them as public elements. Thiscould introduce transparent dependencies if not used correctly.5.3 Category 2: Modeling guidelines• Try reusing protocols rather than creating new ones.This guideline is intended for normal capsules where current protocols couldbe combined and be reused. One important point when using this guideline isthat the protocols must be extensively documented to not create confusion. Itis also important to note that this guideline can be quite dangerous if used toomuch or in the wrong way as it could obfuscate transitions and other types ofcomponents.• Try to keep transitions short.As there can be a large amount of transitions in a state it is important to have49

a minimal amount of action code. Transitions are private entities as such thereis no possibility of reusing them or their code, hence the importance of keepingthe transitions as simple possible.◦ Move code from transitions to functions and classes.This guideline is mainly focused at big transitions that have a large amountof action code. One way of decreasing the size of an action code segmentis to move code to functions in data classes; this would also increase thereusability of that code.◦ Transitions should have a single trigger signal.In the same theme of simplifying transitions, a transition with multipletrigger signals can be di�cult to name and represent in a model.By re-quiring that a transition only should have a single trigger signal wouldeliminate this issue. But as a side e�ect it would instead lead to an in-creased amount of transitions as discussed in Subsection 4.5.1.

• Group self transitions from the same port together and mark withthe port name as a comment.This is a simple and e�ective way of categorizing and clearing up transitions.It improves the overall view of a state and gives a developer a better overviewover a big state containing a large amount of transitions.• Transitions should be named after the trigger signal.This guideline is mostly usable when using the previous two guidelines. Togroup transitions from the same port with a comment and to only use a singletrigger signal for a transition. When both of these guidelines are used it ispossible to only name a transition by its trigger signal. This would increase theconsistency in the models and also improve the ability to easily follow a signalfrom a structure diagram to a state diagram as explained in Subsection 4.5.1.• Avoid drawing overlapping components in the diagrams.This guideline is an important visual guide as a diagram with components thatare not structured correctly and have visually overlapping icons and transitionscan seem as cluttered and increase the complexity of a diagram.These next four guidelines are recommendations from IBM (the developers ofthe RoseRT development platform) and they are intended as a set of limits onthe sizes of di�erent components in a system. These guidelines may not beapplicable to all systems but they are good to have in mind as recommendedthresholds for writing and designing a system.• Max 5 public ports in a capsule. (IBM)This guideline is the one in these four that most probably might not be applicableas ports are the only public components in a capsule, but this guideline showsthe intended target size of a capsule. A capsule should not be larger than thisvalue, but there is once again a balance issue where too many capsules mayintroduce a large amount of overhead whereas a larger capsule would introducemore complexity at a single point. 50

• Max 10 incoming and 10 outgoing signals in a protocol. (IBM)This guideline sets a limit on the amount of signals that should be added toa protocol. Adding more signals can decrease the visibility and increase thecomplexity in a system.• Max 10 states at any level in a state diagram. (IBM)This guideline's main propose is to limit the amount of information displayedin a single state diagram. 10 states is a threshold that should not be exceededas it would dramatically increase the complexity in a state diagram. Insteadof adding new states to a state diagram investigate the possibility of combiningstates into a new nested state diagram but be aware of the level of the nesting.• Max 3 levels of nesting in a state diagram. (IBM)Nesting of states is a good way of improving the visibility in a state diagrambut it is important to be careful with the amount and level of nesting. A statediagram can become a large tree of state diagrams that one would easily get lostin which would increase the complexity.5.4 Category 3: Architecture guidelines• Use a standardized and a global con�guration object.This guideline is very unspeci�c but there are many ways this can be imple-mented. The important point of this guideline is to properly use a global con-�guration object so that con�guration options can be moved from individualclasses to a central point and can easily be accessed by other object whichwould decrease the dependencies.• Avoid circular dependencies between blocks.This is a very important guideline to have in mind as the development continues.As code is introduced to the block it is crucial to be aware of how di�erent blocksare dependent on each other. Circular dependencies can create problems as twodi�erent blocks depend on each other rather than having a one way dependencytree.• Add publicly used protocols to a common block.This guideline corresponds to the previous model guideline to reuse protocols.As the protocols become more abstract they should also be given a commonplace where all the abstract protocols can be placed. This is to have a centralplace for all the reusable protocols. This guideline originates from a thesisnamed �Evaluation and reconstruction of software dependencies� written 2011by Tommy Gunnarsson.• Group similar capsules into a new layer, and o�oad some of thetransitions from the main capsule.There needs to be a large amount of routing functionality in a capsule thatcontains many sub capsules. This guideline tries to decrease the amount ofrouting code in a single capsule. There is two di�erent approaches for thisguideline; either the root capsule is converted to a routing capsule (a capsulethat only routes signals) and the logic moved to a sub capsule (see Subsection4.4.2), or the root capsule can be split into smaller segments where the sub51

capsules are grouped to create a tree structure where routing and logic code issplit into smaller pieces.• Move �elds and logic from capsules into external classes.As capsules are closed objects it is di�cult to uphold object-oriented principlessuggested in previous guidelines. To be able to improve the extensibility of asystem there needs to be some sort of openness between classes. This can beaccomplished by moving logic from capsules to normal C++ data classes wherecode can be reused and extended for more functionality.• Use wrapper protocols to decrease the amount of ports.This guideline is similar to the reusing of protocols guideline whereas this onemostly focuses on the MSC (see Subsection 4.4.2) architecture where the switch-ing components could be implemented with abstract protocols for better exten-sibility for future additions. The core idea of this guideline is to create highwaysinstead of country roads between capsules. But this is not always possible as awrapper protocol requires some code to be able to identify signals, so there is aneed for balance between ports, protocols and lines of code.

52

Chapter 6SummaryThis chapter will go trough a summary of the conclusions made in this thesis.There will also be a section for �nal thoughts about the work itself and whatcould be done better. The last section in this chapter will talk about future workbeyond this thesis and how this work can be expand upon in the future.6.1 ConclusionsOvergrowth of a code base is a common problem when developing a large system.It is especially so with large multicultural development teams. Ericsson is onecompany that is in this situation where the source code grows to a point whereit becomes unmaintainable. The solution that is used today is a large and timeconsuming refactoring of the system. This has been the main focus of this thesis,where areas on how to avoid or minimize overgrowth of a source code packagehave been investigated.Current development practices has to this date no way of knowing the futureof a code segment, which leads to classes and other components growing as theyencompass more and more features and capabilities that make their proposalunclear. This in turn leads to the necessity of having large refactorings or splitsin the code base, to improve the visibility in the source code and the e�ciencyof the development. The approach to a solution for this problem has been toinvestigate the root causes for the overgrowth and to introduce guidelines forimproving the e�ciency and the ability to refactor the source code easier.Some of the improvements that can be made to this situation include de-creasing the size of the splits. To use smaller and more frequent refactoringsinstead of having the current large and extensive redesigns every other year.There is unfortunately no simple single way of doing this, but rather needsmultiple smaller changes in di�erent areas of the development. As such, theguidelines that have been suggested in this thesis are recommendations thatare part of multiple areas that needs to be improved. Some of these areas in-clude the development process, the architecture, the visual UML models and53

the actual source code.The development process that is currently used is built upon a quite oldfoundation (The Waterfall process) that was not initially designed with softwareevolution in mind. This is one of the areas that could be improved by eitherintroducing some kind of refactoring or prototyping into the process or switchingto a more modern and more iterative or agile process. This would improve thefuture development in the system. But the current structure of the system alsoneeds to be improved.The current architecture of the investigated block is not really designed withextensibility in mind. The block currently needs to be modi�ed regularly as newfeatures are introduced into the system. This creates problems as there is nogood solution for adding new components without editing an existing capsuleand the fact that the existing capsules are very complex leads to extendeddevelopment lengths. The immediate improvements that can be made are thesimpli�cation of the existing capsules by using the presented guidelines in Chap-ter 5. The simpli�cations should increase the visibility in the block and improvethe e�ciency of the development.A more long term solution would be to initiate a major redesign of thearchitecture in the Cell block. The current architecture needs to become moreabstract and extensible to allow for future additions to the block. A suggestedarchitecture in this thesis has been the MSC (see Subsection 4.4.2) with theaddition of more general ports which would allow for better extensibility.6.2 Final ThoughtsThere is no one simple solution to the given problem at Ericsson. There arehowever many smaller changes that must be made to be able to develop in a bet-ter and more e�ective way. One of the main challenges with this thesis projecthas been coming as an outsider to a new system and an unknown developmentplatform. As the RoseRT development platform is not really designed from ausability stand point, it is relatively hard to understand and become familiarwith under a short time. And the fact that the analyzed small block containsabout 40 000 lines of generated code gives you a view of the massive systemthat the block is a very small part of.6.3 Future WorkThis thesis has gone through many di�erent areas, development processes, smallrefactoring, large refactoring, UML modeling, state machines and many more.There is even more work that can be done in each speci�c area and in muchmore detail.The more important areas that work could be continued after this thesiswould be: 54

• A detailed look at the testing and especially the block tests and how theycould be improved and how they correlate to the speci�c problem statedin this thesis.• The a�ect of the development process to the actual code and a discussionaround why this is so.• Introducing refactoring into a waterfall model and comparing it to themore modern processes.• Refactoring of UML, this is a rather new concept in the software industry.• Refactoring of architecture, this can be a very large area and one of highimportance for large software systems.• The introduction of a centralized con�guration object in a real-time sys-tem. There needs to be a large consideration for how the object shouldbehave as it would be shared and accessed by multiple threads at the sametime.

55

Bibliography[1] Martin Fowler, UML Distilled SE, Published by Addison Wesley2000, ISBN 020165783X.[2] Dean Le�ngwell, Agile Software Requirements, Published byAddison-Wesley professional, ISBN 9780321635846.[3] Designing systems and software applications by using models,Published by IBM, URL: http://publib.boulder.ibm.com/infocenter/rsahelp/v8/topic/com.ibm.rsa_base.nav.doc/topics/trootdesignwithmodels.html, Visited 2011-04-07.[4] Bran Selic and Jim Rumbaugh, Using UML for Modeling Com-plex Real-Time Systems, March 11, 1999.[5] Rational Rose Real-Time Online Help documentation, version6.6.3409.0.[6] Joshua Kerievsky, Refactoring to Patterns, Published byAddison-Wesley 2005, ISBN 0-321-21335-1.[7] Lukasz Dobrzanski, UML Model Refactoring - Support for Main-tenance of Executable UML Models, Master Thesis at BlekingeInstitute of Technology, November 7, 2005.[8] Martin Fowler, Refactoring: Improving the design of existingcode, Published by Addison Wesley 1999, ISBN 0-201-48567-2.[9] Anders Johansson, Är objektorienterad modellering ett måste?(Is object-oriented modeling a must?), Thesis at the Universityof Skövde, October 9, 2009.[10] OMG (Object Management Group), URL: http://www.omg.org/, Visited 2011-04-19.[11] Martin Lippert and Stephen Roock, Refactoring in large softwareprojects, Published by John Wiley & Sons Ltd 2006, ISBN: 0-470-85892-3. 56

[12] Mats G I Carlsson and Lars G Johansson, Formal Veri�cationof UML-RT Capsules using Model Checking, A Master's Thesisat Chalmers University of Technology, 2009.[13] Joel Spolsky, Things You Should Never Do, Article URL: http://www.joelonsoftware.com/articles/fog0000000069.html,Published April 06 2000, Visited May 04 2011.[14] Brian Marick, Approaches to legacy code, ArticleURL: http://www.exampler.com/old-blog/2005/05/11/#fixing-legacy-code, Published May 11 2005, Visited May04 2011.[15] Scott W. Amble, A Manager's Introduction to The Rational Uni-�ed Process (RUP), White paper URL: http://www.ambysoft.com/downloads/managersIntroToRUP.pdf, Published Decem-ber 4, 2005

57

APPENDIX

58

Appendix ADictionaryAda: is a programming language which was standardised in 1983 and developedby the US Department of Defense. It was initially used for embedded andreal-time systems but has over the years expanded to other platformsaswell.Block: is another name for a package in the source code. It is used for structur-ing classes in a large system into smaller and more comprehensive package.C++: is a very popular programming language. It was developed by Bell Labsin 1979 as an enhancement to the C programming language.Cell: a RBS contains 6 cells that are single radio antennas that cover a speci�cgeographical area.Cell Block: this is a package in the RNH subsystem that con�gures and han-dles incoming data channels from radio base stations.Code smells: is a term used when the source code of system or application isvery hard to overview.Dumb class: is a class that contain no logic other than public �elds.Field: is a term used when describing a data class. It refers to a data variableowned by a class.God object: is classes that have to much functionality or data is called a Godobject.OMG: is a open non-for-pro�t consortium. It was founded 1989 by eleven com-panies(IBM, Apple, Sun, Hewlett-Packard, American Airlines and DataGeneral) but has over 800 members today. The consortium was initiallyfounded to provide open standards for object-oriented systems but hasshifted its focused to model-based standards.59

Package: is in the software development as a folder or category containing dataclasses. It's used for simplifying the structure of a larger software systeminto smaller components.Port Cardinality: refers to the direction of the port, if the port is for sendingor receiving signals.Ravioli Code: is code that are built on small and loosely coupled softwaremodules are often compared with ravioli, as small object that containboth function and data.RBS (Radio Base Station): a RBS is a radio tower that handle the directcommunication with mobile phones and other electronic devices wirelesslyby radio waves.RNC (Radio Network Controller): is a application that is used for operat-ing telephone nodes and radio towers for the di�erent telephone networksthat exists today. It is developed by Ericsson and is used by many largetelecommunication operators.RNH (Radio Network Handling subsystem): is a subsystem of RNC. Oneof its functions is the con�guration of Cells.RoseRT: is a model based software development solution for big and complexsystems. It is built by IBM and are mainly used at large companies.Signal: refers to a single message received by a port. It represents an instanceof a data type as an integer, object etc.Spaghetti Code: is code that are hard to overview and understand.WCDMA: is the technology used in the third generation telecommunicationsystems more commonly known as 3G.

60

Appendix BGuidelinesCategory 1: Coding guidelines• Avoid using public �elds in data classes, use accessors instead.• Avoid functions with long parameter lists.• Add comments describing the functionality of �elds and functions.• Avoid using complex solutions when a simpler one is possible.

◦ Avoid recursive functions.• Try to be consistent with the existing code.

◦ Use standard design patterns as much as possible.• Try to reuse as much code as possible.

◦ Separate code that will change often and try to reuse that code as much aspossible.• Be sure to not use protected �elds/methods outside of a block, RoseRT and the C++compiler does not check for this.Category 2: Modeling guidelines• Try reusing protocols rather than creating new ones.• Try to keep transitions short.

◦ Move code from transitions to functions and classes.◦ Transitions should have a single trigger signal.

• Group self transitions from the same port together and mark with the port name asa comment.• Transitions should be named after the trigger signal.61

• Avoid drawing overlapping components in the diagrams.• Max 5 public ports in a capsule. (IBM)• Max 10 incoming and 10 outgoing signals in a protocol. (IBM)• Max 10 states at any level in the state diagrams. (IBM)• Max 3 levels of nesting in the state diagrams. (IBM)Category 3: Architecture guidelines• Use a standardized and a global con�guration object.• Avoid circular dependencies between blocks.• Add publicly used protocols to a common block.• Group similar capsules into a new layer, and o�oad some of the transitions from themain capsule.• Move �elds and logic from capsules into external classes.• Use wrapper protocols to decrease the amount of ports.

62

TRITA-CSC-E 2011:131 ISRN-KTH/CSC/E--11/131-SE

ISSN-1653-5715

www.kth.se