Submitted by Natalia de Souza Gonçalves (natalia.goncalves@ufpe.br) on 2016-09-28T12:45:56Z No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertação Helton_10_05_16.pdf: 2471864 bytes, checksum: 84ec1446c8bac02d76bd26a6c12e8896 (MD5) / Made available in DSpace on 2016-09-28T12:45:56Z (GMT). No. of bitstreams: 2 license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Dissertação Helton_10_05_16.pdf: 2471864 bytes, checksum: 84ec1446c8bac02d76bd26a6c12e8896 (MD5) Previous issue date: 2016-02-12 / O modelo Entidade-Relacionamento Estendido (EER) e o Diagrama de Classes (DC) da Unified Modeling Language (UML) são as notações gráficas mais utilizadas para a fase de projeto conceitual de banco de dados. Neste contexto, considerando que existem diferenças entre estas notações e poucos trabalhos que as comparem a partir de uma avaliação quantitativa, este trabalho busca evidências empíricas, por meio da execução de um survey, sobre a compreensão e preferência de uso dessas notações. Como resultado, constatou-se que as duas notações cumprem os requisitos em um ambiente de desenvolvimento de banco de dados, variando sua utilização conforme o perfil do usuário. Contudo, apesar da notação do DC ser a mais compreendida, a notação EER foi a mais preferida. / The Entity-Relationship Extended (EER) model and the Class Diagram (DC) of the Unified Modeling Language (UML) are the most used graphical notations during the conceptual design phase of a database development project. In this context, considering that there are significant differences between these two notations and few studies that compare them from a quantitative approach, this paper seeks empirical evidence through the execution of a survey on the understanding and preference of use of such notations. As a result, it was found that both notations meet the requirements in a database development environment, with their use varying according to the user profile. However, despite the DC notation be better understood, the EER notation was the most preferred among the survey participants

In this thesis we will examine a telecom industry case, where combining synchronous and asynchronous interfaces causes problems. A solution to the problem is being presented in form of an interface controller framework that is based on patterns of common functionality of interface controllers. The solution is implemented using four different implementation methods (Java, Erlang, XDE, Executable UML), and compared in lines of code, performance and throughput. / I rapporten undersöks ett fall i telekominudstrin, där kombinerandet av synkrona och asynkrona interface orsakar problem. En lösning på problemet är presenterat i form av ett framework för interface controllers som är baserat på mönster som beskriver den gemensamma funktionaliten i interface controllers. Lösningen är implementerad med hjälp av fyra olika implementeringsmetoder (Java, Erlang, XDE och Executable UML), där rader kod och prestanda jämförs. / pt00cbj@student.bth.se pt00psa@student.bth.se

Applying Rational Unified Process (RUP) in a project means to develop a set of models before the system could be implemented. The models depict the essentials of the system from requirements to detailed design. They facilitate getting a system that has appropriate and rich documentation (therefore highly maintainable) and addresses user needs. However, creation of the models may cause overheads since a lot of work has to be put to elaborate the artefacts. In this paper a method that makes RUP more efficient is proposed. The method makes use of the fact that every subsequent model is developed basing on the previous model. In other words, models are successively transformed from requirements up to executable code. In particular, design model bases on an analysis model. The proposed method applies automatic model transformation from an analysis model to a design model. Firstly, an approach for performing automatic transformation is chosen. Secondly, a tool applying this approach is implemented. Finally, the transformation tool is tested and evaluated in an empirical study. The results show that automation of model transformation may be beneficial, and therefore can help in getting better systems in shorten time.

The Model Driven Architecture is a proposition of the framework of software development process where main accent is put on system models, i.e. platform independent and platform dependent models, and transformations between them. Applying the MDA is related with preparation of these two types of assets. In the thesis, the EDOC and the EJB platform are considered as an examples of platform-independent and platform dependent models. In order to complete this picture, additionally transformations between these two models are required. The authors focus in the thesis on transformations. In particular, the authors present the transformation specification description, and specify set of transformations between the EDOC and EJB models. The transformations are narrowed to the subset of structural aspects of the EDOC models.

Abstract During object-oriented system development, programming should be preceded by analysis and design to assure that the system fulfils the demands of the customer and simplify during the development phase and documentation. When modeling the analysis and design phases, several different notations may be used. One of these is the UML (Unified Modeling Language) which this thesis will cover. The aim is to compare the use of the UML i practice versus what is said in the literature. The investigation is built upon interviews at different companies to receive their reflections about the UML. Questions at issue are why and when the selected companies use the UML and what diagrams they use. We also investigate whether they strictly follow the UML notation or complement it with another kind of notation. Moreover two companies not using the UML was interviewed to find out why they have chosen not to. The thesis starts with an introduction to object-oriented system development with analysis and design followed by the history of the UML and its most common diagrams according to Larman [1]. These diagrams are use case, conceptual model, system-sequence diagram, contract, interaction diagram, class diagram and state diagram. Each diagram is explained with text and graphics. The most important results are that the UML is considered being adequate to the system developers. They use a number of the most common diagrams. Furthermore the CASE-tools showed not to meet the demands of the developers. We believe that inadequate tools hinders the future diffusion of the UML on the market. Improved tools for modeling and documentation are desired for all of the interviewed companies.

Dagens dataloggare har många funktioner vilket avspeglas i programvaran som används för att kommunicera med dem. De har fler funktioner än vad enskilda företag och privatpersoner behöver vilket gör programvaran onödigt komplicerad. Genom att minska antalet inställningsmöjligheter kan programvaran göras mindre, snabbare och lättare att lära sig. Arbetet utfördes hos Inventech Europe AB som tillhandahöll dataloggare för temperatur- och fuktighetsmätning. De ville undersöka möjligheterna att utveckla ett program som personer med begränsad datorvana snabbt kunde lära sig att använda. Därför var syftet med detta arbete att utreda hur ett sådant program kunde se ut. Arbetets fokus låg på designprocessen. Genom olika UML-diagram visualiserades de olika momenten i processen. Då projektet var relativt litet valdes en utvecklingsprocess som följer vattenfallsmodellen där de olika stegen (specifikation, design, implementation, test) utförs i följd. Det förutsätter att ett steg är färdigt innan nästa steg påbörjas. Modellen fungerar bäst när projektet är mindre och väldefinierat. Tyvärr ändrades företagets krav på hur programmet skulle fungera flera gånger under arbetets gång. Därmed borde en mer flexibel utvecklingsprocess ha valts för att ge utrymme för förändringar som kunde uppkomma under projektets gång. Slutresultatet blev en funktionsprototyp som var lätt att använda och inte hade fler inställningsmöjligheter än nödvändigt. Funktionsprototyp kan användas som bas för att lägga till egen skräddarsydd funktionalitet. För att visa detta inkluderades ytterligare två funktioner. En av funktionerna var möjligheten att kunna spara insamlad data till en extern databas som sedan kunde användas som källa till andra program vilka exempelvis skulle kunna visualisera data med hjälp av olika grafer. För att lätt kunna identifiera olika inkopplade dataloggare inkluderades även möjligheten att namnge de olika enheterna. / Modern data loggers have many settings which is reflected in the application used to communicate with them. They have more settings than individual companies and people need which makes the application unnecessarily complicated. By reducing the number of settings, the application can be made smaller, faster and easier to learn. This bachelor thesis was done at Inventech Europe AB, who provided data loggers for temperature and moisture measurements. They wanted to explore opportunities to develop a program that people with limited computer experience could quickly learn to use. Therefore, the aim of this work is to investigate what such a program would look like. The thesis focus is on the design process. The different steps were visualized through various UML diagrams. Since the project was relatively small, a development process following the waterfall model was chosen. Following the model means completing each step (requirements specification, design, implementation, testing, etc.) in succession. It assumes that one step is completed before the next step is started. The model works best when the project is small and well defined. Unfortunately, the specification given by the company changed multiple times during development. With that in mind, a more flexible development process should have been chosen to allow for changes that may occur during the development. The end result was a program prototype that was easy to use and didn’t have more settings than necessary. The prototype can be used as a base for adding custom functionality. To show this, two additional functions was included. One of the features was the ability to save the collected data to an external database which later could be used as a data source for other application that could visualize the data using different graphs. In order to easily identify different connected data loggers, a second setting was included, enabling naming of the various loggers.

In the end of the 80´s the area of system development moved into a new era. As a consequence many new methods and development models emerged which in many cases resulted in problems when choosing system development models and methods. As a result of these problems the today standardized modeling language UML (Unified Modeling Language) was created. UML is tailored to support many different types of projects. This is possible because of UML’s capacity to be adjusted and adapted to a specific company environment. The purpose of this bachelor thesis is to investigate how and why companies use UML and what experiences and opinions those who use UML have of using UML in practice. To fulfill our purpose we have chosen to carry out a qualitative study with semistandardized interviews. The interviews were accomplished on four companies in Jönköping. The result of the research shows that the primary reason for companies to carry out modeling is because it results in good documentation which makes development, administration and operation easier. Furthermore, the study has shown that the reason that companies have chosen UML is because it is a standard which is suited for various different projects and also for the development model used in the company. The standardization is also, according to all companies, the primary strength with UML. Weaknesses in UML are considered to be the lack of process diagrams and standardized syntax in modeling tools. There was found to be an increase in the number of diagrams used the longer the companies have used UML. The diagrams applied by all companies are: use case diagram, class diagram and sequence diagram. Moreover, the use of diagrams for a specific project is dependent on the project type and size. However, none of the companies utilize the flexibility to adjust the syntax. All companies combine UML with RUP or business customized development models with characteristics from RUP. There is, however, a difference in how companies use the diagrams in combination with the development models. This probably depends on the companies’ iterative way of working where the diagrams are involved in the whole system development process. / I slutet av 80-talet gick systemutvecklingen in i ett nytt skede. Detta fick som följd att många nya metoder och utvecklingsmodeller för systemutveckling skapades vilket i flera fall ledde till problem vid val av systemutvecklingsmetod och modell. Till följd av detta skapades det idag standardiserade modelleringsspråket UML (Unified Modeling Language). UML är anpassat för att stödja många olika typer av projekt eftersom det tillåter företagsspecifika anpassningar och förändringar. Syftet med studien är att undersöka hur och varför företag använder sig av UML samt vilka erfarenheter och uppfattningar de som arbetar med UML har av att tillämpa det i praktiken. För att uppfylla syftet har vi valt att genomföra en kvalitativ studie med semistandardiserade intervjuer. Intervjuerna utfördes på fyra företag i Jönköpingsregionen. Resultatet av studien visar att den främsta anledningen till att företag modellerar är att det ger en bra dokumentation vilket underlättar utveckling, förvaltning och drift. Vidare har studien visat att UML har valts på grund av att det är en standard som lämpar sig för många olika projekt samt för att UML passar den utvecklingsmodell som tillämpas på företaget. Standardiseringen är även enligt samtliga företag den främsta styrkan med UML. Svagheter i UML anses vara avsaknaden av processdiagram samt bristen på standardiserad syntax i verktygen. Ju längre UML har använts på företagen desto fler diagram används. De diagram som tillämpas av samtliga företag är användningsfallsdiagram, klassdiagram och sekvensdiagram. I övrigt beror användningen av diagram för ett specifikt projekt på projektets typ och storlek. Däremot utnyttjar inget av företagen UML:s flexibilitet att anpassa syntaxen. Samtliga företag kombinerar i någon utsträckning UML med RUP eller egenutvecklade utvecklingsmodeller med liknande egenskaper som RUP. Det skiljer sig dock i hur företagen använder diagrammen i samband med utvecklingsmodellerna. Detta beror troligtvis på det iterativa sätt företagen arbetar efter där diagrammen följer med i hela systemutvecklingsprocessen.

En central del i ett systemutvecklingsprojekt är de tekniker som används för att strukturera organisationer och informationen i dessa. I flera årtionden har traditionella tekniker utvecklats. Exempel på tekniker som anses traditionella är ER-modellering och dataflödesdiagram. Idag används objektorienterade programspråk mer och mer för att implementera databaser. Det har dock inte funnits stöd för att analysera ett system objektorienterat förrän i början på 1990-talet. De tekniker och metoder som utvecklades då hade flera olika inriktningar och begreppsförvirringen var stor. 1997 kom en standard för objektorienterad modellering i form av Unified Modeling Language (UML). I och med denna standard försökte man klargöra vilka begrepp som skulle gälla och vilken typ av notation som kunde användas. Arbetet försöker att visa vad som kan ersätta de traditionella teknikerna med objektorienterade metoder och tekniker. Koncentrationen har lagts på att analysera vilka tekniker som används i de två första faserna av livscykelmodellen, förändringsanalys och systemering. Resultatet blev att en fullständig ersättning för de traditionella teknikerna inte finns i UML i livscykelmodellens två första faser.

I detta arbete har en undersökning genomförts angående hur spårbarhet upprätthålls vid användning av användarfall. Rapporten behandlar spårbarhet och användarfall separat för att belysa viktiga fakta inom båda områdena. Syftet med arbetet var att ta reda på hur olika tillvägagångssätt för att representera användarfall upprätthöll spårbarhet mellan olika krav, och mellan krav och dess ursprung. Informationen inom problemområdet samlades in genom en litteraturstudie. I undersökningen identifierades flera olika typer av spårbarhet, vilka sedan låg till underlag för identifiering av spårbarhet i användarfall. Undersökningen visade också att det finns flera olika sätt att representera användarfall, i allt från naturligt språk till formella diagram. Resultatet av undersökningen visade även att användningen av ett modelleringsspråk som Unified Modeling Language (UML), med inbyggda relationer och namnkonventioner, gjorde att spårbarhet kunde upprätthållas mellan olika krav, och mellan krav och dess ursprung. En begränsad spåbarhet identifierades i samband med att mindre formella representationer av användarfall använts.

Undersökningen behandlar problem som tidigare forskning har uppmärksammat kring användandet av standarden XMI. XMI är avsedd för utbyte av modeller mellan modelleringsverktyg. Problem som uppmärksammats i användningen av XMI är att information om modeller inte alltid utbyts korrekt mellan verktyg. Detta kan resultera i att viktig information om modellerna går förlorad. Undersökningen har till syfte att undersöka huruvida det är möjligt att extrahera data från modeller sparade i XMI-format utan tillgång till DTD eller XML-schema. En sådan möjlighet skulle kunna användas för att rädda information om modeller som annars skulle gå förlorad. Den metod som har används för undersökningen är litteraturstudie, experiment och implementation samt hypotesprövning. Studien har resulterat i en implementation som är avsedd för att extrahera och presentera information från XMI-dokument. Den slutsats som dras från undersökningen är att det går att extrahera data från modeller sparade i XMI-dokument förutsatt att sättet på vilken XMI-standarden har tillämpats är känt sedan tidigare.