Base commonality of the Software Product Line (SPL) Engineering processes is to analyze commonality and variability of the product family though, SPLE defines many various processes in different abstraction levels. In this thesis, a new approach to configure (according to requirements) components as building blocks of the architecture is proposed. The main objective of this approach is to support domain design and application design processes in SPL context. Configuring the products is made into a semi-automatic operation by defining a Domain Specific Language (DSL) which is built on top of domain and feature-component binding model notions. In order to accomplish this goal, dependencies of the components are extracted from the software by using the dependency injection method and these dependencies are made definable in CASE tools which are developed in this work.

The aim of this thesis is to describe design patterns and other programming best practices used in the development of Android applications. The theoretical part analyzes design patterns, Kotlin programming language, dependency injection, reactive programming and automatic testing. The practical part deals with the design and implementation of a sample Android application, which demonstrates the advantages of using design patterns and other proven programming practices described in the theoretical part.

Data lineage forms an important aspect of today's enterprise environment. MANTA Flow is a data lineage analysis platform that already has basic support for analysis of Java programs, provided by one of its components called Bytecode Scanner. Neverthe- less, there are very few applications in today's enterprise environment that do not use dependency injection at least in a very limited way. Therefore, we present an extension of Bytecode Scanner in the MANTA Flow platform to support data lineage analysis of dependency injection frameworks as well. The extension is able to process even complex definitions of standard dependency injection containers. Since the dependency injec- tion influences a selection of method call targets, we also provide a description of call graph structure and its modification to support dependency injection. Last, we use this infrastructure to design and implement a plugin into Bytecode Scanner for the Spring Framework, a popular dependency injection framework targeting Java Platform. The plugin has been successfully tested on a small but realistic software system that can read data from a file, transform them, and write them into a database. 1

Inom en stor del av all systemutveckling sker testerna av systemet som sista punkt innan systemet sjösätts. Testdriven utveckling är en systemutvecklingsmetod där testerna istället skrivs först och också är det som driver utvecklingen framåt. Metoden höjs till skyarna av vissa och avfärdas omedelbart som onödigt omständig av andra. Vi vill med denna uppsats undersöka hur det ser ut i verkligheten och vilka faktorer som påverkar användandet, inlärningen och inställningen till testdriven utveckling. Vi genomförde intervjuer på tre stycken Örebrobaserade organisationer och tittade utifrån ramverket method-in-action på vilka faktorer som påverkade användningen och varför. Vi fann att utvecklarna närmade sig testdriven utveckling på väldigt olika sätt och grundade sin inställning mycket beroende på tidigare erfarenhet och inlärning – oavsett hur lång eller kort den varit. Utvecklarna förväntas ofta bedriva självstudier utanför arbetstid – något som inte alltid funkar som kunskaputvecklingsform då tiden utanför jobbet ser olika ut beroende på var i livet man är. Det finns inte heller något klart program eller best-practices att följa för att lära sig metoden i någon av organisationerna. Vi såg också att det finns tekniker utanför själva metoden som utvecklare ganska omgående behöver bli bekanta med för att kunna utveckla testdrivet: dependency injection och mock.

Amending old projects of legacy code to include agile practices such as extensive unit testing and refactoring has proven difficult. Since automated unit testing was not widely used a decade ago, much code has been written without unit testing in mind. This is especially true for C++ where RAII has been the dominant pattern .This has resulted in a lot of code that suffers from what best can be described as low testability. This also strongly impedes the creation of new unit tests to already existing code. Due to the lack of unit tests, refactoring is done sparsely and with great reluctance. This thesis work tries to remedy that and, in the scope of a limited case study on an existing code base, looks into different ways of creating and utilizing object seams in legacy C++ code to decouple dependencies to make isolated testing possible. This regards to: What are the impediments for code to be testable in an isolated setting? What are the steps for refactoring code to a testable state? The results can be summarized as to contain a list of factors affecting testability, among them: the use of asserts, global state, object instantiation, work in constructor and breaking Law of Demeter. Further with regards to patterns for refactoring code to a testable state, two types of patterns have crystallized: the injection of dependencies and the masking of dependencies using various techniques. The effect these two base patterns have on breaking dependencies on the base level and the Meta level is outlined. A catalogue of patterns has been compiled as part of the appendix.   Inversion of Control (IoC) is a principle used to decoupling classes and since strong dependences is often an attribute giving grievances with regard to testability, it was a central concern in this thesis. IoC can be simplified from a developer standpoint with the help of frameworks or what is usually referred to as IoC containers. Two IoC containers for C++ were evaluated: Autumn Framework PocoCapsule In the evaluation of the two IoC containers it was concluded that Autumn was not mature enough as of the time of the evaluation to be used in production setting. PocoCapsule, even though compelling for some of its powerful features with regard to DSM and HOT, its configuration sometimes require in-code workarounds, affecting its usability in some set of scenarios. However, the big difference was with regard to how the two containers approaches configuration. PocoCapsule uses static analysis of its XML configuration file making it truly declarative while Autumn does runtime parsing and dynamic invocations resulting in a situation closer to procedural scripting.

Cybercom Group AB har en kombinerad säkerhets- och integrationsplattform kallad CESP, Cybercom Enhanced Security Platform. I CESP finns bl.a. en autentiseringstjänst, åtkomstkontroll, loggning och logganalys. Det finns även ett webbaserat administrationsgränssnitt för att komma åt och administrera tjänsterna. Examensarbetet har gått ut på att utvärdera och omforma adminis-trationsgränssnittet för att göra gränssnittet mer enhetligt och lättarbetat. Examensarbetet har varit inriktat på att ge utvecklarna ett stöd för vidare utveckling med fokus på användbarhet och avslutades med en utvärdering mellan den »gamla« och »nya« administrationsportalen. Examensrapporten kommer ta upp hela arbetsprocessen indelat i dess fyra faser; undersökning, design, implementation och utvärdering. Examensarbetet har lett till en implementation av en begränsad del i en administrationsportal samt en omfattande pappersprototyp som visar hur en vidare implementation av administrationsportalen kan se ut. Resultatet av utvärderingen visade inte på någon signifikant skillnad mellan den »gamla« och »nya« administrationsportalen, detta till stor del p.g.a. felaktigt val av utvärderingsmetod som inte var lämpad att utvärdera två olika system.

Tato práce popisuje realizaci webové aplikace, která umožňuje centrální administraci služeb pro sbor umělců, jako je například komorní orchestr. Do této administrace patří zejména správa obsahu webové prezentace, umělců a jejich smluv a honorářů, koncertů, skladeb a rezervací a objednávek online vstupenek. Aplikace integruje vestavný Konfigurátor a rezervační systém koncertních síní (KORES), vytvořený v rámci bakalářské práce a spravuje dále jím vytvořené objednávky.

Software companies often choose to develop in C++ because of the high performance that the language offers. Facilitated by static compilation and powerful optimization options, runtime performance is paid for with compilation time. Although the trade-off is inevitable to some extent, building very large C++ programs from scratch can take up to several hours if extra care is not taken during development. This thesis analyzes compilation times for C++ programs and shows how they can be reduced with the help of design patterns, implementation hiding, and framework related fixes. The results presented prove that compilation times can be decreased significantly with no drawbacks to the maintainability of a program. An in-depth analysis of compilation times and dependencies has been conducted for two large software modules from a representative company. Both modules take over an hour of CPU time each to compile. The time consumption for different compiler activities, such as parsing, preprocessing, and runtime optimization tasks have been measured for the modules. The compilation times for unit tests and mocks which use the GoogleTest framework have been analyzed. A simple method that may reduce compilation times by up to 50% for programs that use GoogleTest is presented. A dependency metric has been created, based on the number of include statements found recursively throughout a program. The dependency metric was found to be connected to compilation time for the two analyzed modules. Other factors that can influence compilation times are also shown, such as runtime optimization options, and the use of templates. Experiments which show how a typical usage of templates can drastically increase compilation times are presented. In addition, a solution which allows templates to be used while avoiding code bloat across translation units is reviewed. The solution effectively rivals non-template code in terms of compilation time. The Pointer to Implementation (PImpl) and Dependency Injection design patterns have been used to refactor a small program. Both design patterns performed well, reducing the total compilation time and total compiler memory usage by 70%. A program that detects dependency cycles has been created, but no cycles were found in any of two modules from the representative company.

Práce se zabývá popisem tvorby mobilního systému pro monitoring zákaznické spokojenosti a sběr zpětné vazby od návštěvníků v restauracích s názvem Huerate. Komplexně jsou popsané všechny fáze vývoje systému. První část práce se zabývá analýzou existujících řešení a stavem na trhu. Následně jsou na základně komunikace s majiteli restaurací sestaveny požadavky na systém. Nakonec se práce věnuje samotnému návrhu systému, jeho implementaci a nasazení v restauracích. Systém Huerate běží jako webová aplikace a je dostupný na adrese http://huerate.cz.

[pt] Contexto Injeção de Dependência (DI) é um mecanismo comumente aplicado para desacoplar classes de suas dependências com o objetivo de prover uma melhor modularização do software. No contexto de Java, a existência de uma especificação de DI e frameworks populares, como o Spring, facilitam o emprego de DI em projetos de software. Entretanto, más práticas de implementação de DI podem trazer más consequências, como maior acoplamento, dificultando alcançar o principal objetivo de DI. Apesar de a literatura sugerir a existência de anti-padrões de DI, não há uma documentação detalhada de tais más práticas. Em adição, não há evidência da ocorrência e da percepção de utilidade dos mesmos do ponto de vista de desenvovedores. Objetivos Nosso objetivo é revisar os anti-padrões de DI reportados com o objetivo de analisar sua completude e propor um novo catálogo de anti-padrões de DI para Java. Método Nós propomos um catálogo contendo 12 anti-padrões de DI para Java. Nós selecionamos 4 projetos open-source e 2 projetos closed-source que adotam um framework de DI e desenvolvemos uma ferramenta que analisa estaticamente a ocorrência dos anti-padrões de DI candidatos no código fonte das aplicações. Em adição, nós conduzimos uma pesquisa por meio de entrevistas face a face com três desenvolvedores experientes que regularmente aplicam DI em seus projetos. Nós estendemos a pesquisa com o objetivo de obter a percepção de um conjunto de 15 desenvolvedores experientes e novatos por meio de um questionário online Resultados Ao menos 9 anti-padrões de DI apareceram frequentemente nos projetos de software analisados. Em adição, a avaliação recebida dos desenvolvedores confirmaram a relevância do catálogo. Por fim, os respondentes expressaram o desejo de refatorar as instâncias de antipadrões de DI propostas. Conclusões O catálogo contém anti-padrões de DI que ocorrem na prática e são úteis. Compartilhar com praticantes da indústria os permitirá evitar a introdução de anti-padrões em seus projetos de software. / [en] Background Dependency Injection (DI) is a commonly applied mechanism to decouple classes from their dependencies in order to provide better modularization of software. In the context of Java, the availability of a DI specification and popular frameworks, such as Spring, facilitate DI usage in software projects. However, bad DI implementation practices can have negative consequences, such as increasing coupling, hindering the achievement of DI s main goal. Even though the literature suggests the existence of DI anti-patterns, there is no detailed documentation of such bad practices. Moreover, there is no evidence on their occurrence and perceived usefulness from the developer s point of view. Aims Our goal is to review the reported DI anti-patterns in order to analyze their completeness and to propose and evaluate a novel catalog of Java DI anti-patterns. Method We propose a catalog containing 12 Java DI anti-patterns. We selected 4 opensource and 2 closed-source software projects that adopt a DI framework and developed a tool to statically analyze the occurrence of the candidate DI anti-patterns within their source code. Also, we conducted a survey through face to face interviews with three experienced developers that regularly apply DI. We extended the survey in order to gather the perception of a set of 15 expert and novice developers through an online questionnaire. Results At least 9 different DI anti-patterns appeared frequently in the analyzed projects. In addition, the feedback received from the developers confirmed the relevance of the catalog. Besides, the respondents expressed their willingness to refactor instances of anti-patterns from source code. Conclusions The catalog contains Java DI anti-patterns that occur in practice and are useful. Sharing it with practitioners may help them to avoid such anti-patterns.