bc.pollub.plbc.pollub.pl/Content/13164/PDF/VOL6-2018.pdf · Redakcja JCSI e-mail: [email protected]...

Redakcja JCSI

e-mail: [email protected] www: jcsi.pollub.pl Instytut Informatyki Wydział Elektrotechniki i Informatyki Politechnika Lubelska

ul. Nadbystrzycka 36 b 20-618 Lublin

Redaktor naczelny: Tomasz Zientarski e-mail: [email protected] Redaktor techniczny: Beata Pańczyk, e-mail: [email protected] Recenzenci numeru:

dr inż. Jakub Smołka dr Beata Pańczyk dr inż. Maciej Pańczyk dr Mariusz Dzieńkowski dr inż. Grzegorz Kozieł dr inż. Piotr Kopniak dr inż. Elżbieta Miłosz dr inż. Piotr Muryjas dr inż. Maria Skublewska-Paszkowska dr inż. Dariusz Gutek Skład komputerowy: Piotr Misztal e-mail: [email protected]

Projekt okładki: Marta Zbańska

JCSI Editorial e-mail: [email protected] www: jcsi.pollub.pl Institute of Computer Science Faculty of Electrical Engineering and Computer Science

Lublin University of Technology

ul. Nadbystrzycka 36 b 20-618 Lublin, Poland

Editor in Chief: Tomasz Zientarski e-mail: [email protected] Assistant editor: Beata Pańczyk, e-mail: [email protected] Reviewers:

Jakub Smołka Beata Pańczyk Maciej Pańczyk Mariusz Dzieńkowski Grzegorz Kozieł Piotr Kopniak Elżbieta Miłosz Piotr Muryjas Maria Skublewska-Paszkowska Dariusz Gutek Computer typesetting: Piotr Misztal e-mail: [email protected]

Cover design: Marta Zbańska

ISSN 2544-0764

Spis treści

1. PORÓWNANIE TECHNOLOGII TWORZENIA APLIKACJI INTERNETOWYCH NA

PRZYKŁADZIE SPRING MVC I VAADIN ŁUKASZ TOMCZYK, BEATA PAŃCZYK ................................................................................................ 1

2. PORÓWNANIE WYTWARZANIA APLIKACJI WEBOWYCH Z UŻYCIEM JĘZYKA PHP

ORAZ PLATFORMY MAGENTO BARTOSZ DRAWDZIK, MARIA SKUBLEWSKA-PASZKOWSKA ...................................................... 6

3. ANALIZA WPŁYWU TECHNIK BEZPIECZNEGO PROGRAMOWANIA NA WYDAJNOŚĆ I

BEZPIECZEŃSTWO APLIKACJI TOMASZ KOBIAŁKA .............................................................................................................................. 12

4. WYKORZYSTANIE METODY EYE-TRACKINGU DO EWALUACJI RESPONSYWNEJ

APLIKACJI INTERNETOWEJ DARIUSZ MEKSUŁA, KONRAD MIKOŁAJCZYK, MAŁGORZATA PLECHAWSKA-WÓJCIK, MAGDALENA BORYS ............................................................................................................................. 20

5. PORÓWNANIE WYDAJNOŚCI SZKIELETÓW APLIKACJI MOBILNYCH

UMOŻLIWIAJĄCYCH PROGRAMOWANIE Z WYKORZYSTANIEM TECHNOLOGII

INTERNETOWYCH MARCIN MARTYNA, JAKUB SMOŁKA ............................................................................................... 28

6. BADANIE ZACHOWAŃ UŻYTKOWNIKÓW ORAZ METOD AUTORYZACJI W

KONTEKŚCIE BEZPIECZEŃSTWA URZĄDZEŃ MOBILNYCH PIOTR KRÓL, DAMIAN MAREK, JAKUB SMOŁKA ............................................................................ 34

7. PORÓWNANIE KONFIGURACJI I MOŻLIWOŚCI BIBLIOTEK ORM DLA SYSTEMU

ANDROID TOMASZ SERWIN .................................................................................................................................... 42

8. ANALIZA PORÓWNAWCZA WYBRANYCH SZKIELETÓW SŁUŻĄCYCH DO

WSTRZYKIWANIA ZALEŻNOŚCI RAFAŁ SZEWCZYK, MAŁGORZATA PLECHAWSKA-WÓJCIK ....................................................... 47

9. PORÓWNANIE MOŻLIWOŚCI BIBLIOTEK GTK+ ORAZ QT W PROGRAMOWANIU GIER KAMIL DRZAS, DOMINIK ALCHIMOWICZ, MACIEJ PAŃCZYK ..................................................... 55

10. TECHNOLOGIA BLOCKCHAIN I JEJ ZASTOSOWANIA HLIB DIKARIEV, MAREK MIŁOSZ ....................................................................................................... 59

11. PIĘĆ SPOSOBÓW WPROWADZENIA WSPÓŁBIEŻNOŚCI DO PROGRAMU W JĘZYKU C# PAWEŁ SZYSZKO, JAKUB SMOŁKA .................................................................................................... 62

12. ANALIZA WYDAJNOŚCI APLIKACJI MOBILNYCH PRZY ZASTOSOWANIU RÓŻNYCH

NARZĘDZI PROGRAMISTYCZNYCH DO ICH BUDOWY PAWEŁ KOTARSKI, KACPER ŚLEDŹ, JAKUB SMOŁKA ................................................................... 68

13. ANALIZA PORÓWNAWCZA NARZĘDZI ONLINE DO ZARZĄDZANIA I KOMUNIKACJI W

PROJEKTACH INFORMATYCZNYCH ŁUKASZ NAUMIUK, ELŻBIETA MIŁOSZ ............................................................................................ 73

14. PORÓWNANIE WYDAJNOŚCI EMULATORA I FIZYCZNEGO URZĄDZENIA Z SYSTEMEM

ANDROID W OPARCIU O ALGORYTM SZACHOWY KAMIL LITKOWSKI, JAKUB SMOŁKA ................................................................................................ 77

15. PORÓWNANIE SZKIELETÓW APLIKACJI ANGULARJS I REACT.JS NA PRZYKŁADZIE

APLIKACJI INTERNETOWEJ ŁUKASZ CAPAŁA, MARIA SKUBLEWSKA-PASZKOWSKA ............................................................ 82

16. PORÓWNANIE WYDAJNOŚCI WIELOPLATFORMOWEGO SZKIELETU APLIKACJI NA

PLATFORMACH ANDROID I WINDOWS 10 MOBILE. DAWID WIECZOREK, JAKUB SMOŁKA .............................................................................................. 87

17. PORÓWNANIE MOŻLIWOŚCI IMPLEMENTACJI USŁUG REST W JĘZYKU JAVA Z

WYKORZYSTANIEM POPULARNYCH FRAMEWORKÓW APLIKACJI INTERNETOWYCH RAFAŁ KWIATKOWSKI, PIOTR KOPNIAK ......................................................................................... 92

18. WYDAJNOŚĆ PRACY Z BAZAMI DANYCH W APLIKACJACH ASP.NET MVC PAWEŁ BORYS, BEATA PAŃCZYK ...................................................................................................... 97

Contents

1. COMPARISON OF WEB APPLICATIONS DEVELOPMENT USING SPRING MVC AND

VAADIN ŁUKASZ TOMCZYK, BEATA PAŃCZYK ................................................................................................ 1

2. COMPARISON OF WEB APPLICATION DEVELOPMENT USING PHP AND MAGENTO

PLATFORMS BARTOSZ DRAWDZIK, MARIA SKUBLEWSKA-PASZKOWSKA ...................................................... 6

3. AN ANALYSIS OF INFLUENCE OF SAFE PROGRAMMING TECHNIQUES ON

APPLICATIONS EFFICIENCY AND SECURITY TOMASZ KOBIAŁKA .............................................................................................................................. 12

4. THE USE OF EYE-TRACKING METHODS FOR EVALUATION OF RESPONSIVE WEB

APPLICATION DARIUSZ MEKSUŁA, KONRAD MIKOŁAJCZYK, MAŁGORZATA PLECHAWSKA-WÓJCIK, MAGDALENA BORYS ............................................................................................................................. 20

5. EFFICIENCY COMPARISON OF MOBILE APPLICATION FRAMEWORKS FOR

PROGRAMMING USING INTERNET TECHNOLOGIES MARCIN MARTYNA, JAKUB SMOŁKA ............................................................................................... 28

6. ANALYSIS OF USER BEHAVIOR AND AUTHORIZATION METHODS IN CONTEXT OF

MOBILE DEVICES SECURITY PIOTR KRÓL, DAMIAN MAREK, JAKUB SMOŁKA ............................................................................ 34

7. COMPARISON OF THE CONFIGURATION AND CAPABILITIES OF ORM LIBRARIES FOR

ANDROID TOMASZ SERWIN .................................................................................................................................... 42

8. COMPARATIVE ANALYSIS OF SELECTED SKELETONS FOR DEPENDENCY INJECTION RAFAŁ SZEWCZYK, MAŁGORZATA PLECHAWSKA-WÓJCIK ....................................................... 47

9. COMPARISON OF GTK+ AND QT LIBRARIES IN GAME DEVELOPMENT KAMIL DRZAS, DOMINIK ALCHIMOWICZ, MACIEJ PAŃCZYK ..................................................... 55

10. BLOCKCHAIN TECHNOLOGY AND ITS APPLICATION HLIB DIKARIEV, MAREK MIŁOSZ ....................................................................................................... 59

11. FIVE WAYS TO INSERT CONCURRENCY TO A PROGRAM WRITTEN IN C# PAWEŁ SZYSZKO, JAKUB SMOŁKA .................................................................................................... 62

12. ANALYSIS OF THE IMPACT OF DEVELOPMENT TOOLS USED ON THE PERFORMANCE

OF THE MOBILE APPLICATION PAWEŁ KOTARSKI, KACPER ŚLEDŹ, JAKUB SMOŁKA ................................................................... 68

13. COMPARATIVE ANALYSIS OF ONLINE TOOLS FOR MANAGEMENT AND

COMMUNICATION IN IT PROJECTS ŁUKASZ NAUMIUK, ELŻBIETA MIŁOSZ ............................................................................................ 73

14. PERFORMANCE COMPARISON OF AN EMULATOR AND PHYSICAL ANDROID MOBILE

DEVICE BASED ON CHESS ALGORITHM KAMIL LITKOWSKI, JAKUB SMOŁKA ................................................................................................ 77

15. COMPARISON OF ANGULARJS AND REACT.JS FRAMEWORKS BASED ON A WEB

APPLICATION ŁUKASZ CAPAŁA, MARIA SKUBLEWSKA-PASZKOWSKA ............................................................ 82

16. COMPARISON OF PERFORMANCE MULTI-PLATFORM APPLICATION CORE ON

ANDROID AND WINDOWS 10 MOBILE DAWID WIECZOREK, JAKUB SMOŁKA .............................................................................................. 87

17. COMPARISON OF CAPABILITIES TO IMPLEMENT REST SERVICES IN JAVA LANGUAGE

USING THE POPULAR WEB APPLICATION FRAMEWORKS RAFAŁ KWIATKOWSKI, PIOTR KOPNIAK ......................................................................................... 92

18. ASP.NET MVC DATABASE APPLICATIONS PERFORMANCE PAWEŁ BORYS, BEATA PAŃCZYK ...................................................................................................... 97

JCSI 6 (2018) 1-5

WysłaneŚ 2017-09-13

PrzyjęteŚ 2017-09-19

1

Porównanie technologii tworzenia aplikacji internetowych na przykładzie Spring MVC i Vaadin

Łukasz Tomczyk*, Beata Pańczyk

Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska

Streszczenie. W artykule przedstawiono wyniki porównania efektywno ci wytwarzania aplikacji internetowych na platformie Java w wersji 1.8

z zastosowaniem szkieletów programistycznych Spring MVC oraz Vaadin. Analiza porównawcza została przeprowadzona za pomocą autorskich aplikacji testowych, implementujących te same funkcjonalno ci w obu technologiach.

Słowa kluczowe: Spring MVC; Vaadin; aplikacje internetowe; framework

*Autor do korespondencji.

Adres e-mail: [email protected]

Comparison of web applications development using Spring MVC and Vaadin

Łukasz Tomczyk*, Beata Pańczyk

Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. The article presents the results of web application development effectiveness on Java platform in 1.8 version using Spring MVC and

Vaadin frameworks. The comparative analysis was conducted with test applications, implementing the same functionalities in both technologies.

Keywords: Spring MVC, Vaadin, web applications, framework

*Corresponding author.

E-mail address: [email protected]

1. Wstęp

Istnieje wiele różnych technologii, wykorzystywanych do tworzenia aplikacji internetowych w rodowisku języka Java

[1]. Można je podzielić na trzy grupy:

koncentrujące się tylko na wizualnej stronie interfejsu

użytkownika; sterujące całą logiką aplikacji i procesami biznesowymi; pozwalające na implementację strony wizualnej i logiki

aplikacji.

Każde z tych podej ć posiada swoje wady i zalety i bardzo

trudno jest wskazać najlepsze rozwiązania.

W artykule przeanalizowano dwa wybrane szkielety

programistyczne: najbardziej popularny Spring MVC [1]

oraz cieszące się coraz większą popularno cią Vaadin

(Rys. 1).

2. Cel, teza i metody badań

Celem badań było porównanie kodu oraz przetestowanie efektywno ci działania dwóch aplikacji (o takiej samej

funkcjonalno ci) utworzonych za pomocą Spring MVC i Vaadin.

W artykule postawiono następującą tezęŚ

Framework Vaadin jest bardziej efektywnym narzędziem wytwarzania aplikacji internetowych w porównaniu do Spring MVC.

Dla potwierdzenia przedstawionej tezy wykorzystano

metodę badań opartą na analizie porównawczej obu rozwiązań.

Rys. 1. Popularno ć wybranych frameworków Java w roku 2016 [2]

Journal of Computer Sciences Institute

2

3. Aplikacje testowe

Aplikacje Spring MVC oraz Vaadin:

stworzono w rodowisku programistycznym Eclipse [3]

z wykorzystaniem narzędzia do automatyzacji i budowy

projektów Mavenś współpracują z serwerem bazy danych Oracle [4],

realizując dostęp do danych za po rednictwem Hibernate; wykorzystują funkcje biblioteki jQuery.

Obie aplikacje testowe posiadają typowe funkcjonalno ci CRUD (ang. Create, Read, Update, Delete, Search), czyli

tworzenie, edycję oraz usuwanie informacji o studentach

z bazy danych (Rys. 2).

Rys. 2. Schemat bazy danych

Interfejs obu aplikacji jest bardzo podobny oraz

umożliwia pełny dostęp do wszystkich funkcjonalno ci. Został on przedstawiony na rysunku 3.

Rys. 3. Przykładowa strona aplikacji testowej

4. Analiza porównawcza

Najważniejsze cechy Spring MVC i Vaadin zostały zestawione w tabeli 1. W tabeli 2 przedstawiono parametry

sprzętowe komputera, na którym wykonano testy.

Do przeprowadzenia porównania obu aplikacji wykorzystane zostały następujące kryteriaŚ

ogólna struktura aplikacji; efektywno ć pracy z danymiś podstawowe metryki kodu; efektywno ć wczytywania zasobów aplikacji przez przeglądarkę internetową.

Tabela 1. Najważniejsze cechy Spring MVC i Vaadin

Spring MVC Vaadin

Twórca Pivotal Software Vaadin Ltd.

Pierwsza wersja 1 października

2002

Millstone 3 open

source Web

framework 2002

Wersja finalna 1 marca 2017

(4.3.7)

22 lutego 2017

(8.1)

Język programowania Java

SDK Java SE 8 SDK

Technologia widoku JSP Java

Inne możliwe technologie widoku

Thymeleaf,

Groovy Markup

Templates

Html

Serwery open-source Apache Tomcat, GlassFish, Jetty

Wsparcie Bogate wsparcie i dokumentacja, duża

baza użytkowników

Licencja Apache License 2.0

Niezależno ć platformy systemowej

Windows, Mac, Linux

Tabela 2. Parametry zestawu pomiarowego

Element Stan/Wersja

System operacyjny Windows 10 64-bitowy

Procesor Intel Core i7-4712 (2.3-3.3 GHz)

Pamięć RAM 12 GB

Wersja Java Java 8

4.1. Struktura aplikacji

Rys. 4 przedstawia strukturę obu aplikacji, opartych na projekcie Maven.

Rys. 4. Struktura projektu Spring MVC i Vaadin

Na rysunku wyróżniono kolorem elementy funkcjonalnie wspólne dla obu aplikacji:

Fioletowy - pakiety klas odpowiadających za realizację żądań oraz interakcji z użytkownikiem;


3

zielony - pakiety klas domenowych mapujących encje bazy danych za pomocą adnotacji JPA; brązowy - pakiety implementujące interfejsy warstw usług oraz repozytorium; niebieski - pakiet z parserem plików txt i csv; czerwony - pakiety warstwy repozytorium; pomarańczowy - pakiety warstwy usług; czarny - pakiety zawierające mechanizmy pomiaru czasów; żółty - foldery z plikami konfiguracyjnymi, m.in.

połączenia z bazą danych; szary - dodatkowe pliki (css, javascript, jsp, xml).

Dzięki zastosowaniu struktury Maven, elementy obu aplikacji są zbliżone. Główne różnice to pliki jsp, xml oraz

javascript, które zawiera Spring MVC.

4.2. Efektywno ć pracy z bazą danych

W celu porównania efektywno ci obu aplikacji, zmierzono czas pracy z danymi. Do testu przygotowano 9

scenariuszy testowych (Tabela 3.). Każdy scenariusz powtórzono 10 razy a wyniki pomiarów u redniono.

Tabela 3. Tabela 3. Scenariusze testowe

Scenariusz Opis

1 Zapis 10 studentów

2 Odczyt 10 studentów







9 Wyszukiwanie studentów losowo wybranymi słowami kluczowymi

Testowy zbiór studentów został wygenerowany przez prosty program własnego autorstwa. Czas mierzono

w milisekundach [ms]. Operacje na bazie realizowano za

pomocą Hibernate.

Fragment kodu z pomiarem czasu operacji dla scenariusza

1 oraz 2 pokazują odpowiednio przykłady 1 i 2.

W pozostałych scenariuszach pomiar odbywał się analogicznie.

Przykład 1. Pomiar czasu zapisu danych – Spring MVC

@RequestMapping(value = "/" +

StudentsAdminViewName, method = RequestMethod.POST) private String addStudentsFromFile(

@ModelAttribute("myFile") @Valid MyFile myFile, HttpServletRequest request) { calculator.begin(); MultipartFile multipartFile = myFile.getData(); List<Student> st = TextFileParser.getStudentsFromFile(multipartFile); studentsService.addStudents(st); calculator.end(); calculator.calculate(); students = studentsService.getStudents( elementsInPage, startPosition, Order.ASC);

studentsService.getAllStudents(); return "redirect:/" + StudentsAdminViewName;

}

Przykład 2. Pomiar czasu odczytu danych – Vaadin

private void updateList() { performenceCalculator.begin(); if (filter == null || filter.isEmpty()) { students = service.getStudents(elementsInPage, startPosition, Order.ASC); } else { students = service.getStudentsByFirstName(filter, elementsInPage, startPosition, Order.ASC); } grid.setItems(students); performenceCalculator.end(); performenceCalculator.calculate(); }

W tabelach 4 i 5 przedstawiono odpowiednio rezultaty

pomiarów dodawania i odczytu 10 studentów.

Tabela 4. Czasy dodawania jednocze nie 10 studentów.

Spring MVC Vaadin

Nr pomiaru Czas [ms]

1 89 111

2 61 83

3 72 87

4 88 93

5 65 88

6 74 87

7 70 89

8 63 90

9 76 84

10 80 87

redni czas 73 88

Tabela 5. Tabela 5. Czasy odczytu 10 studentów

Spring MVC Vaadin


1 309 9

2 327 10

3 302 14

4 304 7

5 306 8

6 311 11

7 301 13

8 309 12

9 317 8

10 326 9

redni czas 313 11

Na rysunku 5a i 5b zestawiono rednie czasy pomiarów dla wszystkich scenariuszy.

Porównując obie aplikacje, w kategorii pobierania

rekordów z bazy, Vaadin jest zdecydowanie szybszy od Spring MVC.

W przypadku zapisu danych, Spring MVC jest szybszy

dla małej liczby, natomiast Vaadin dla większej liczby danych.

W przypadku wyszukiwania (scenariusz 9) Spring MVC

jest szybszy od Vaadin rednio o 6 milisekund.


4

.

Rys. 5a. rednie czasy operacji dla wszystkich scenariuszy testowych dla Spring MVC i Vaadin

Rys. 5b. rednie czasy operacji dla wszystkich scenariuszy testowych dla Spring MVC i Vaadin

4.3. Efektywno ć wczytywania zasobów aplikacji w przeglądarce internetowej

Następnym ważnym pomiarem wydajno ci obu aplikacji jest czas od momentu wystąpienia żądania użytkownika. Czas ten został zmierzony za pomocą konsoli deweloperskiej Mozilla Firefox dla scenariusza 4. Wyniki pomiarów zostały przedstawione w tabeli 6. Na podstawie prezentowanych tam

wyników można stwierdzić, że aplikacja Vaadin jest znacznie

szybsza niż Spring MVC. Jest to spowodowane rozdzieleniem w Spring MVC warstwy prezentacji od warstwy kontrolera.

W Vaadin obie warstwy znajdują się w jednym miejscu w kodzie źródłowym.

4.4. Porównanie metryk aplikacji.

Ostatnim elementem porównania obu aplikacji jest analiza metryk kodu. Do tego celu wykorzystano narzędzie dostępne w Eclipse. Wyniki przedstawia tabela 7.

Generalnie liczba linii kodu dla Spring MVC jest mniejsza

od aplikacji napisanej w Vaadin. Jednak aplikacja w Spring


5

MVC zajmuje więcej pamięci dyskowej niż w przypadku

Vaadin, ponieważ zawiera w sobie więcej wbudowanych mechanizmów.

Tabela 6. Czas pobierania zasobów przez przeglądarkę Mozilla Firefox

Spring MVC Vaadin


1 568 39

2 602 21

3 589 22

4 563 34

5 612 32

6 538 27

7 513 29

8 558 33

9 503 28

10 613 31

redni czas 566 30

Tabela 7. Wybrane metryki kodu obu aplikacji.

Liczba linii kodu

Spring MVC Vaadin

Kod Java 1165 2081

Kod JSP 564 0

Kod JavaScript 57 0

Pliki konfiguracyjne 327 246

Razem linii kodu 2113 2327

Liczba bibliotek 43 36

Rozmiar projektu (MB) 61,8 48,4

5. Wnioski

Na podstawie przeprowadzonych badań można sformułować następujące wnioskiŚ

zastosowanie obydwu frameworków do tworzenia aplikacji internetowych wymaga znajomo ci podstaw języka Javaś Spring jest stabilną platformą deweloperską, która stale się rozwija i oferuje bogate możliwo ci przystosowania do różnych projektów [5]; patrząc na wykresy popularno ci frameworków, Spring MVC jest wykorzystywany najczę ciej. Wiąże się z tym fakt, że wiele projektów powstało dużo wcze niej niż same frameworki [6]. Aplikacje napisane w Springu nadal

są w nim utrzymywaneś Vaadin powstał głównie do tworzenia wyglądu. Dostarcza API, które jest dużym ułatwieniem dla programistów [7]; biorąc pod uwagę efekt końcowy, czyli działanie aplikacji, użytkownik nie powinien odczuć znacznej różnicy w szybko ci działania. Jedyną rzeczą, która może być widoczna, to podobieństwo wszystkich aplikacji pisanych

z wykorzystaniem frameworka Vaadin; Vaadin posiada dużą pulę standardowych komponentów, które w zupełno ci wystarczają nawet w przypadku

tworzenia zaawansowanych aplikacji. Pisanie własnych komponentów zdarza się bardzo rzadko, o czym można przeczytać w dokumentacji frameworka [7]; Vaadin jest znacznie szybszy je li chodzi o wyszukiwanie danych. Jest to spowodowane asynchronicznym

wykonywaniem zadań za pomocą AJAX. W tym

scenariuszu testowym framework Spring MVC korzysta

z tradycyjnych żądań, co ma wpływ na czas reakcjiś odczyt danych jest również mocniejszą stroną Vaadin. Jest to związane z brakiem separacji warstw aplikacji. Widok jest implementowany w kodzie Javy, podczas gdy

w Spring MVC tworzy się oddzielne pliki (np. jsp) oraz

w dodatkowym pliku konfiguruje się dopasowanie pliku

widoku do klasy kontrolera;

Je li chodzi o inne artykuły porównujące framework Spring MVC oraz Vaadin, istnieją w dużo mniej szczegółowej formie. Na portalu internetowym [8] można znaleźć porównanie tych dwóch frameworków. Przedstawia ono tylko opis słowny i ocenę użytkowników – nie zawiera porównania wydajno ciowego w postaci tabel i wykresów.

Literatura

[1] G. Amuthan, Spring MVC. Przewodnik dla początkujących, Helion, Gliwice, 2015.

[2] https://zeroturnaround.com/rebellabs/most-popular-java-

frameworks-tools-and-libraries-2016/ [09.04.2017]

[3] https://www.eclipse.org/ [07.05.2017]

[4] N. Greenberg, Oracle Database 10g: SQLFundamentals I,

Oracle, 2004.

[5] Gutierrez F.: Wprowadzenie do Spring Framework dla

programistów Java, Helion, Gliwice 2015

[6] https://spring.io/guides, [05.03.2017]

[7] https://vaadin.com/docs/, [02.04.2017]

[8] https://zeroturnaround.com/rebellabs/the-curious-coders-java-

web-frameworks-comparison-spring-mvc-grails-vaadin-gwt-

wicket-play-struts-and-jsf/2/

JCSI 6 (2018) 6-11

Wysłane: 2017-09-11

Przyjęte: 2017-09-14

6

Porównanie wytwarzania aplikacji webowych z użyciem języka PHP oraz platformy Magento

Bartosz Drawdzik*, Maria Skublewska-Paszkowska Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska

Streszczenie. Artykuł przedstawia proces tworzenia dwóch aplikacji w oparciu o dwie różne metody programowania, jedna z nich to aplikacja

PHP oparta na danych przechowywanych w relacyjnej bazie danych MySQL oraz aplikacja o analogicznej funkcjonalności zaimplementowana na platformie Magento 1.9. Głównym celem artykułu jest przetestowanie obu aplikacji oraz weryfikacja w jakim stopniu poszczególne funkcjonalności są odporne na błędy pojawiające się podczas korzystania z aplikacji. Uzyskane rezultaty pozwolą ocenić sposób programowania poprawiający czystość kodu oraz jego jakość.

Słowa kluczowe: Testy jednostkowe; Magento; Zend; PHP; MySQL.



Comparison of web application development using PHP and Magento platforms

Bartosz Drawdzik*, Maria Skublewska-Paszkowska


Abstract. The paper presents the process of creating two application using two different methods of programming. One of them is simple PHP

application based on data stored in a relational MySQL database and a application of the same functionality implemented on the Magento 1.9

platform. The main purpose of the paper is to test applications and verify them of the extent to which functionality is fault-tolerant. It means that

tests will be the - individuals function and their resistance to errors. The obtained results allow the authors to evaluate which kind of

programming is the best and improve clean code and it’s quality.

Keywords: Unit tests; Magento; Zend; PHP; MySQL.



1. Wstęp

Język PHP (ang. PHP Hypertext Preprocessor) znajduje

obecnie bardzo szerokie zastosowanie w dziedzinie

informatyki, ponieważ jest głównie wykorzystywany do komunikacji z serwerem i posiada narzędzia pozwalające na budowę każdego rodzaju stron internetowych oraz umożliwia komunikację z bazami danych. Te atuty sprawiają, że jest to najczęściej stosowany język do tworzenia stron internetowych oraz aplikacji webowych w czasie

rzeczywistym. Wynika to z faktu, że ponad trzy czwarte

społeczeństwa w Polsce posiada dostęp do Internetu (według Głównego Urzędu Statystycznego jest to 72,4 % w roku 2017, co jest i tak poniżej średniej unijnej która wynosi 84 %) [1]. Jednoznacznie można wywnioskować więc, że zdecydowana większość ludności na co dzień korzysta z zasobów oraz tego co oferuje język PHP.

Na całym świecie powstają coraz to nowocześniejsze oraz bardziej profesjonalne strony internetowe czy inne

aplikacje wykorzystujące to oprogramowanie. Nie można bowiem zapominać, że PHP to nie tylko strony internetowe, ale także wszelkiego rodzaju systemy które opierają się na zasadzie komunikacji z bazami danych czy też

programowanie opierające się na przetwarzaniu informacji pobranych z serwera. Jednakże w tej dziedzinie sprawdza się najlepiej ze względu na swoje ogromne atuty i zastosowanie w połączeniu z systemem do zarządzania relacyjnymi bazami danych MySQL [2]. PHP wyróżnia się przede wszystkim szybkością działania, niskim kosztem implementacji, stabilnością, szerokim wsparciem wśród użytkowników, łatwością nauki oraz przede wszystkim, co zostało wcześniej wspomniane, wysokimi wynikami podczas współpracy z różnymi typami serwerów i silnikami bazodanowymi, wyniki te to przede wszystkim bardzo dobra kompatybilność oraz niezwykła łatwość w implementacji kodu dla różnych systemów bazodanowych [3].

Z racji tak ogromnej popularności powstaje również wiele platform programistycznych (ang. Framework)

będących szkieletem budowy aplikacji, które definiują

strukturę aplikacji i ogólny mechanizm działania. Takie narzędzia zapewniają także szeroki zestaw bibliotek i komponentów. Najpopularniejszym wśród nich w stosunku do języka PHP jest Zend Framework [4]. Został on użyty w tej pracy do stworzenia nie zawodnego i szybkiego systemu

przy pomocy znanego i szeroko rozwiniętemu systemu zarządzania treścią jakim jest Magento [5].

Tworząc każdy system informatyczny należy patrzeć na niego z perspektywy produktu, musi on być jak najlepszy,

być konkurencyjny na rynku internetowym przy tak dużej liczbie innych podobnych serwisów, musi się wyróżniać na

ich tle. Dlatego należy dbać o poprawność działania każdego systemu. Tutaj naprzeciw każdemu programiście wychodzą testy, które pozwalają w łatwy i prosty sposób porównać

mailto:[email protected]


7

aplikacje, sprawdzić jakie ewentualne błędy mogą się pojawić [6].

Artykuł ten przedstawia zastosowanie testów jednostkowych przy porównaniu dwóch aplikacji internetowych. Wykorzystanie testów do tworzenia aplikacji pozwala na rozbicie każdego z systemów na poszczególne funkcjonalności i ich analizę. W tym przypadku porównaniu będą poddane wielkość kodu oraz szybkość działania każdej funkcjonalności. Natomiast analiza testów jednostkowych pozwoli na wyciągnięcie wniosków i odpowiedzenie na pytanie jak można poprawić jakość produktu jakim jest aplikacja internetowa pod kątem programowania w języku PHP oraz jaki wpływ na to może mieć zastosowanie tychże testów przy wytwarzaniu takiego oprogramowania.

2. Platformy

W pracy zostaną porównane dwie aplikacje. Pierwsza z nich jest zaimplementowana w języku PHP bez wykorzystania jakichkolwiek platform czy bibliotek, jedynie

z wykorzystaniem PHP w wersji 5.6. Dodatkowo znajdują się tam skrypty z języka HTML oraz JavaScript. Jednak budowa

całej funkcjonalności opiera się o narzędzia PHP, które pozwalają programiście na bardzo łatwy i szybki dostęp do bazy danych i komunikację z nią. Zaimplementowany serwis internetowy FitnessApp wspomaga użytkownika w prowadzeniu zdrowego trybu życia, co dzisiaj jest niezwykle popularne. Główną funkcjonalnością systemu jest wspomaganie użytkownika w prowadzeniu zdrowego trybu życia poprzez porzucenie złego nawyku palenia papierosów i notowanie jego postępów w tym procesie. Użytkownik po zalogowaniu, ma możliwość monitorowania swojego postępu w procesie rzucania palenia. Użytkownik po zapaleniu papierosa loguje się do serwisu i wpisuje dane takie jak, cenę paczki papierosów którą kupił, ostatnią datę zapalenia

papierosa oraz jakiej marki był to papieros. System zapisuje te dane w bazie danych i każdy użytkownik ma możliwość wyświetlenia własnych postępów po zalogowaniu na swój profil. System wyświetla użytkownikowi najczęściej palone papierosy, daty w jakich palił te papierosy i kwotę jaką mógłby zaoszczędzić rzucając palenie.

Druga aplikacja natomiast została zaimplementowana także w języku PHP jednakże różnica polega na tym, że wykorzystana została platforma Magento. Funkcjonalności obu aplikacji są takie same.

Magento jest to otwarte oprogramowanie sklepu

internetowego jednak powstające na tej platformie aplikacje mogą odbiegać od tematu głównego dla którego został zaprogramowany ten system. Przedstawiony system

zarządzania treścią (ang. CMS – Content Management

System) powstał na bazie najpopularniejszego frameworka PHP – Zend framework. Jest to zbiór uniwersalnych bibliotek przeznaczonych do tworzenia serwisów internetowych. Dostarcza on mechanizmów które wspierają działanie aplikacji internetowych oraz komunikację z nimi. Podstawowymi założeniami w tym zbiorze bibliotek jest stopień swobody jaki jest zostawiony dla programisty oraz wzorce projektowe które są wykorzystywane, czyli przede wszystkim MVC - (ang. Model-View-Controller). Jest to

wzorzec architektoniczny którego założenia podzielone są na trzy główne części [7]. Pierwsza z nich to model

reprezentujący problem i logikę działania aplikacji, kolejna część to widok, który opisuje sposób w jaki są wyświetlane pewne części modelu. Ostatnią częścią modelu MVC jest kontroler, który przyjmuje dane wejściowe i operuje na danych, wykonuje pewien działania i zwraca przetworzoną wartość.

Wszystkie te części są ze sobą połączone i razem tworzą cały spójny model, wykorzystywany najczęściej przy tworzeniu aplikacji internetowych. Taki system tworzenia

serwisu jest bardzo przejrzysty i pozwala na łatwą rozbudowę widoku. Właśnie taki model MVC jest wykorzystany w platformie e-commerce Magento.

Magento jest jedną z najpopularniejszych platform sklepu

internetowego. Według danych z Builtwith z 2017 roku porównując wszystkie narzędzia e-commerce, Magento

wspiera ponad 28 % wszystkich sklepów internetowych w całym Internecie i ponad 16 % wszystkich stron internetowych. Takie dane plasują Magento na drugim

miejscu zaraz za WooCommerce, co zostało przedstawione na rysunku 1 [8].

Rys. 1. Porównanie platform e-commerce [8]

Dane przedstawione na rysunku 1, prezentują jak szerokie zastosowanie znajduje ta platforma oraz, jak wielkim

zaufaniem programiści darzą ten system zarządzania treścią. Jest to spowodowane przede wszystkim ogromnymi

możliwościami jakie oferuje Magento, na stabilności całej platformy oraz możliwościach wprowadzania wszelkiego rodzaju zmian i modyfikacji całego systemu. Zmiany te mogą dotyczyć bardzo wielu rzeczy, począwszy od nie wielkich zmian graficznych jak np. logo po te bardzo rozbudowane jak

przykładowo modyfikacja czy też stworzenie własnej metody wyliczania kosztów dostawy. Z tego względu druga aplikacja została stworzona właśnie przy użyciu Magento.

3. Testy jednostkowe

Testy jednostkowe (ang. Unit test) jest to jedna z metod

testowania wytwarzanego programowania i polega na

poddawaniu konkretnych metod (funkcji) aplikacji testom,

czyli weryfikacji poprawności działania całej funkcji. Następnie otrzymane wyniki poddawane są analizie, niezależnie od tego czy dany wynik jest poprawny – zgodny

z obliczeniami wstępnymi, czy też jest błędny – otrzymana

wartość na wyjściu różni się od wartości spodziewanej, która jest wartością poprawna i została wyliczona przez programistę lub inną osobę, która ma odpowiednią wiedzę, aby taki poprawny wynik otrzymać. Zaletą takich testów jest


8

możliwość ciągłego poddawania analizie wyjściowych danych niezależnych części aplikacji na modyfikowanych

elementach programu. Umożliwia to bardzo często wychwycenie błędu zanim dane zostaną przekazane dalszej części całego oprogramowania [9].

Testy jednostkowe przeprowadzane są na kilka różnych sposobów. Do najbardziej rozpowszechnionych należy wpisywanie na wejściu danych w odpowiednim miejscu i analizie otrzymanego wyniku. Ta metoda jest nazywana

„debugowaniem” (ang. debug – usuwanie błędów). Innymi technikami testowania jednostkowego aplikacji jest metoda

testów napędzanych rozwojem w wolnym tłumaczeniu (ang. Test-driven development), w skrócie TDD. Polega ona na testowaniu dodawanej funkcjonalności następnie implementacja funkcjonalności i refaktoryzacji kodu, czyli napisanie kodu spełniającego zadane wymagania i standardy. Obie aplikacje zostały poddane testom. Analizowano wielkość kodu, szybkość działania systemów oraz odporność na błędy i wyświetlane wartości. Aby testy jednostkowe miały sens, analiza musi spełniać pewne kryteria. Każdy z testów musi być niezależny, wykonywanie dwóch testów

powinno odbywać się w ten sposób aby jeden nie wpływał bezpośrednio na wynik drugiego testu. Testy jednostkowe muszą spełniać także warunek powtarzalności i muszą być możliwie najłatwiejsze. Aplikacja powinna być wykonana w ten sposób aby w każdym momencie była możliwość przetestowania aplikacji i tak aby nie wpłynęło to na stabilność i jakość projektowanego serwisu. Jednoznaczność testów, to cecha która pozwala krótko i rzeczowo odpowiadać na pytanie czy dana metoda, funkcja działa poprawnie. Najważniejsza cecha w przypadku testów jednostkowych to ich jednostkowość przy tworzeniu testów jednostkowych powinno się pamiętać, że testowana jest tylko i wyłącznie jedną funkcjonalność, jedna metoda, nie należy także sprawdzać w jednym teście wielu zestawów danych.

4. Aplikacja

Obie aplikacje zostały zaimplementowanie w celu przeprowadzenia na nich testów jednostkowych i porównania wyników. Podczas przeprowadzanie testów starano się wyciągnąć wnioski, który z analizowanych systemów jest lepszy pod względem wymienionych wcześniej cech –

wielkości i czystości kodu, szybkości działania, funkcjonalności, łatwości rozbudowy, efektywności oraz odporności na błędy. Przede wszystkim sprawdzono w jakim stopniu testy jednostkowe mogą wpłynąć na proces tworzenia aplikacji. Również ważną tutaj cechą jest stabilność i łatwość programowania jak i możliwość przeprowadzanych testów [10].

4.1. Aplikacja PHP/MySQL

Aplikacja FitnessApp została zaprogramowana używając języka PHP oraz MySQL do połączenia z lokalną bazą danych [11]. Baza danych aplikacji została zaprojektowana w programie DBeaver w wersji 3.8.5 oraz stworzona przy

pomocy instalatorów w Magento. Poniższy listing przedstawia sposób w jaki to się odbywa. Przykład 1. Skrypt łącznie z bazą danych.

$host='localhost'; $user='root';

$pass=''; $database='traviti'; $link=mysqli_connect($host,$user,$pass); mysqli_select_db($link,$database) or die ("Błąd przy wybieraniu bazy danych ".mysql_error()); setlocale(LC_ALL, 'pl_PL', 'pl', 'polish'); mysqli_query($link,"SET CHARSET utf8");

Jak zaprezentowano w przykładzie 1 połączenie odbywa się poprzez bezpośrednie podanie adresu serwera i danych do logowania z pliku z rozszerzeniem .php. Jakiekolwiek zmiany

wprowadzone w pliku np. wprowadzenie błędnego adresu spowoduje automatycznie rozłączenie z docelową bazą danych.

Aplikacja FitnessApp składa się z trzech podstawowych funkcjonalności poddanych testom: logowanie, rejestracja, zapis i odczyt z bazy danych. Ostatnia funkcjonalność, czyli zapis i odczyt, możliwa jest tylko dla użytkowników zalogowanych. Dla pozostałych użytkowników systemu, czyli niezalogowanych, nie jest wyświetlana informacja o liczbie zapalonych papierosów w danym czasie. Zalogowany użytkownik wprowadza do formularza takie informacje jak liczba spalonych papierosów, cena paczki papierosów oraz ich marka. Takie dane umożliwiają przeprowadzenie analizy danych. W przykłądzie 2, przedstawiona zostanie funkcjonalność logowania do bazy danych. Przykład 2. Skrypt sprawdzenia loginu.

$sprawdzenie1 = mysqli_query($link, "SELECT * FROM userscigarette INNER JOIN questions ON users_cigarette.id_questions = questions.id_questions AND login='$login'") or die("Nie ma takiego loginu w bazie");

Logowanie do aplikacji odbywa się w 4 krokach. Najpierw sprawdzany jest login, czy istnieje w bazie danych.

Jeżeli tak, można przystąpić do kolejnego kroku jakim jest sprawdzenie wpisywanych grup. Logowanie w obu

aplikacjach odbywa się poprzez podanie dwóch grup, grupy te definiowane są przez użytkownika przy logowaniu, może to być dowolna nazwa, przykładowo dla jednego użytkownika mogą to być dwie grupy, z czego pierwsza z nich to będą osoby z którymi w dzieciństwie grał w piłkę nożna, natomiast druga grupa będą to osoby z którymi przykładowy użytkownik siedział w ławce w szkole. Dla

każdej z grup użytkownik definiuje dwie odpowiedzi. Oznacza to, że do każdej opisanej grupy zdefiniowane są dwie odpowiedzi i tak np. analogicznie, jeżeli jako grupę podano osoby z którymi użytkownik siedział w ławce w szkole podstawowej będą to dwa imiona i nazwiska np. Jan Kowalski, natomiast druga odpowiedź będzie to druga osoba, np. Piotr Nowak. Tak zdefiniowane dane mogą użytkownikowi ułatwić logowanie, natomiast mogą także zdecydowanie utrudnić włamanie się na konto użytkownika i dodatkowo zabezpieczyć jego dane.

Kolejnym krokiem jest sprawdzenie poprawności wpisanych grup., co zostało pokazane w przykładzie 3. Przykład 3. Skrypt sprawdzenie grup.

$sprawdzenie2 = mysqli_query($link, "SELECT * FROM userscigarette INNER JOIN questions ON users_cigarette.id_questions=questions.id_questions AND


9

login='$login' AND question_one='$grupa1' AND question_two='$grupa2'") or die("Podałeś złe nazwy grup");

Jeżeli podany login istnieje w bazie danych z bazy wczytane są odpowiedzi. Ponieważ login użytkownika i grupy znajdują się w różnych tabelach niezbędne jest wykorzystanie klauzuli JOIN dla MySQL.

Następnie odbywa się pobranie oraz sprawdzenie poszczególnych odpowiedzi do grup poprzez pobranie loginu i tak jak w przypadku grup użycie klauzuli JOIN i porównanie odpowiedzi, tak jak przedstawiono w przykładzie 4. Przykład 4. Skrypt sprawdzenie pierwszej osoby.

$sprawdzenie3=mysqli_query($link, "SELECT * FROM userscigarette INNER JOIN questions ON users_cigarette.id_questions=questions.id_questions AND login='$login' AND answer_two='$osoba1'") or die("Zła pierwsza odpowiedz w grupie pierwsze");

Ostatnim krokiem przy logowaniu jest porównanie wszystkich zapytań, czy są spełnione, jeżeli tak następuje zalogowanie użytkownika, co przedstawia przykład 5. Przykład 5. Skrypt sprawdzający prawdziwość wszystkich warunków.

if((mysqli_fetch_array($sprawdzenie1)) && (mysqli_fetch_array($sprawdzenie2)) && (mysqli_fetch_array($sprawdzenie3)) && (mysqli_fetch_array($sprawdzenie4)) && (mysqli_fetch_array($sprawdzenie5)) && (mysqli_fetch_array($sprawdzenie6))) { $_SESSION['zalogowany'] = true; $_SESSION['login'] = $login; $nick = $_SESSION['login']; echo "zalogowales sie"; }

Kolejną funkcjonalnością którą należy omówić jest

rejestracja użytkownika. Wszystkie dane wprowadzane do bazy danych są filtrowane prostą metodą, której działanie opiera się o sprawdzenie, czy podane dane wpisane w pole posiadają długość zawierającą się w przedziale od 1 do 100 znaków, dodatkowo dozwolone są odpowiednie grupy znaków i tak użytkownik, aby przejść walidację może wprowadzić litery zarówno duże jak i małe od a do z. Metodę tą przedstawia przykłąd 6. Przykład 6. Skrypt walidacji danych z pól.

if(preg_match(‘[A-Za-z]{1,100}/’, $osoba5)) { $ok6=1; }

Jeżeli wszystkie dane przejdą tą walidację, następuje sprawdzenie dostępności loginu a następnie zapisanie danych do bazy danych tak jak przedstawia to przykład 7. Przykład 7. Skrypt rejestracji, zapisanie danych i sprawdzenie loginu.

$sprawdzenie=mysqli_query($link, "SELECT * FROM ùsers_cigarette` WHERE login='$login'"); if(mysqli_fetch_array($sprawdzenie)) { echo "Jest juz taki login<br>"; $ok1=0; } else { $ok1=1;

} if($ok1==1) { $zapytanie_wstaw_questions = "INSERT INTO `traviti`.`questions` (ìd_questions`, `question_one`, ànswer_one`, ànswer_two`, `question_two`, ànswer_three`, ànswer_four`) VALUES ('$ile_users_cigarette','$grupa1', '$osoba1', '$osoba2', '$grupa2', '$osoba5', '$osoba6')"; $zapytania_wstaw_grupe1 = mysqli_query($link, $zapytanie_wstaw_questions); }

Ostatnią z omawianych tu funkcjonalności poddawanych testom jednostkowym jest zapis do bazy danych

odpowiednich pól, pozwalających na późniejsza analizę danych. Przykład 8 przedstawia funkcjonalność pozwalającą na zapis danych do bazy, sprawdzając przy tym jaki użytkownik jest zalogowany, pobranie jego loginu, następnie zapisanie odpowiednich danych.

Przykład 8. Zapisanie wprowadzonych danych.

$sprawdzenie1=mysqli_query($link, "SELECT * FROM userscigarette INNER JOIN questions ON users_cigarette.id_questions=questions.id_questions AND login='$login'") or die("Nie ma takiego loginu w bazie"); $zapytanie_wstaw_brand = "UPDATE `Cigarettes` INNER JOIN userscigarette ON Cigarettes.id_cigarette=users_cigarette.id_cigarette AND login='$login' SET brand='$papieros'"; $zapytania_update1 = mysqli_query($link, $zapytanie_wstaw_brand);

4.2. Magento

Funkcjonalności przedstawione w rozdziale 4.1 zaimplementowano w drugiej aplikacji, przy użyciu Zend

Framework i Magento. Przy implementacji tej aplikacji

wykorzystano edytor PhpStorm w wersji 2016.1.2 wraz

z dodatkiem Magicento.

Pierwszą analizowaną funkcjonalnością będzie logowanie, które odbywa się za pomocą funkcji przedstawionej w przykłądzie 9. Metoda ta pobiera kolekcję wszystkich elementów z bazy danych, następnie przekazane parametry do funkcji czyli podany przez użytkownika login oraz email są analizowane pod kątem poprawności z obiektami z bazy danych.

Przykład 9. Logowanie do serwisu, aplikacja zaimplementowana w Magento.

public function loggingOn($login, $email, $group, $answer) { $collection = Mage::getModel('monogo_traviti/usercigarette')->getCollection(); $collection->getSelect()->joinLeft(array('question' => 'monogo_traviti/questions'), 'main_table.id_questions = question.id_questions'); foreach($collection as $user) { $userLogin = $user->getLogin(); $userEmail = $user->getEmail(); if(($login == $userLogin)&&($userEmail == $email)) { if((in_array($user->getQuestionOne(), $group)) && (in_array($user->getQuestionTwo(), $group))) { if($user->getQuestionOne() == $group[0]) {


10

if(($user->getAnswerOne() == $answer[0]) && ($user->getAnswerTwo() == $answer[1])) { if($user->getQuestionTwo() == $group[1]) { if (($user->getAnswerThree() == $answer[2]) && ($user->getAnswerFour() == $answer[3])) { return 1; } else { return 0; } else { return 0; } else { return 0; } else { return 0; } else { return 0; } else { return 0; } }

Jeżeli funkcja przedstawiona na listingu 9 zwróci wartość jeden oznacza to, że użytkownik o podanym loginie i e-mailu istnieje w bazie danych i można przejść do zalogowania. W przeciwnym wypadku wyświetlany jest komunikat o błędnych danych logowania.

Następnym elementem funkcjonalności jest odczyt z bazy danych podczas rejestracji użytkownika. Poniższa funkcja przedstawiona na listingu 10, ukazuje w jaki sposób jest to wykonane w Magento.

Przykład 10. Rejestracja do serwisu, aplikacja Magento.

public function checkLoginEnable($login, $email) { $collection = Mage::getModel('monogo_traviti/usercigarette')->getCollection(); foreach($collection as $user) { $userLogin = $user->getLogin(); $userEmail = $user->getEmail(); if(!($login == $userLogin)) { return 0; } if($userEmail == $email) { return 1; } } return 0; } public function insertUser($login, $email) { $collection = Mage::helper('monogo_traviti')->getUserCigaretteCollection(); $sizeCollection = count($collection) + 1;

$data = array('id_questions' => $sizeCollection, 'id_cigarette' => $sizeCollection, 'email' => $email, 'login' => $login); $model = Mage::getModel('monogo_traviti/usercigarette'); $model->setData($data); $model->save(); }

W przykładzie 10 przedstawiono dwie funkcje. Pierwsza

„checkingLoginEnable” pozwala sprawdzić dostępność loginu oraz adresu e-mail w serwisie podanych przez

użytkownika. Jeżeli login oraz e-mail są dostępne funkcja zwraca wartość 1. Natomiast druga funkcja, „insertUser”, przedstawia sposób w jaki odbywa się zapis danych w Magento.

Ostatnia funkcjonalność przedstawia sposób w jaki wykonuje się funkcja zapisu danych do bazy w celu pobrania statystyk późniejszych, co zostało przedstawione w przykładzie 11. Funkcja ta pozwala pobrać jako parametr

dane które są niezbędne do wpisania do bazy. Następnie pobierany jest model wykorzystywanych danych w tabeli

„cigarettes” i następuje zapis danych. Przykład 11. Zapis danych w Magento.

public function updateSmoking($answer, $group) { $data = array('brand' => $answer[0], 'price' => $answer[1]); $model = Mage::getModel('monogo_traviti/cigarettes'); $model->setData($data); $model->save(); }

5. Środowisko testowe

Testy obu aplikacji, FitnessApp oraz tej samej aplikacji

zaimplementowanej na platformie Magento 1.9, zostały przeprowadzone w jednym środowisku testowym, którego parametry zostały przedstawione w tabeli 1 Wyniki jakie otrzymano podczas testowania zostały zapisane oraz następnie przedstawione poniżej.

W środowisku testowym zainstalowany jest system operacyjny Ubuntu 16.04 LTS 64-bitowy . Natomiast

przeglądarka wykorzystywana do testów to Google Chrome w wersji 59.0.3071.104 (Oficjalna wersja) (64-bitowa).

Natomiast język PHP jest zainstalowany w wersji 5.6.

Tabela 1. Specyfikacja urządzeń testowych

Model ASUS X550JK CPU Intel Core i7-4710HQ 2,50 GHz x8 Pamięć RAM 12 GB DDR3 HDD SATAII 500GB GPU Intel Haswell Mobile

Karta sieciowa

Broadcom BCM43142 802.11b/g/n Wireless

Network Adapter + Atheros

AR8172/8176/8178 PCI-E Fast Ethernet

Controller Rozdzielczość ekranu

1920x1080px


11

5.1. Wyniki badań

Analizując powyższe dwie aplikacje otrzymano zestaw wyników, które zostaną przedstawione w tabeli 2. Tabela ta

stanowi punkt wyjściowy do dalszej analizy poszczególnych systemów i wyciągnięcia wniosków na temat każdego z nich. Tabela 2. Zestawienie wyników badań

Cecha Magento 1.9 PHP/MySQL Wielkość kodu - logowanie - rejestracja - dodawanie

73 linii 67 linii 28 linii

87 linii 140 linii 60 linii

Czas ładowania - logowanie - rejestracja - dodawanie

2,57 sec 3.56 sec 1,51 sec

0,78 sec 0,94 sec 0,59 sec

Łatwość rozbudowy (w skali 1-10)

8 5

Efektywność rozbudowy (w skali 1-

10) 7 4

Funkcjonalność (w skali 1-10)

9 5

Czystość kodu (w skali 1-10)

10 6

Łatwość programowania (w

skali 1-10) 3 8

Testy zostały wykonane dla zestawu 5 danych wejściowych. Po zakończeniu testów, w przypadku czasu ładowania strony została wyciągnięta średnia arytmetyczna z wszystkich wyników i została zaprezentowana w tabeli 2. Pozostałe cechy zostały poddane ocenie dwóm osobom, każda z nich jest programistą korzystającą z platformy Magento, co sprawia, że ocena tych aplikacji może wydawać się subiektywna, jednak starano się oddać całkowity i jak najbardziej realistyczny obraz dwóch systemów i w sposób jednoznaczny przedstawić sposób działania i ogromną wagę jaką powinno się przykładać przy programowaniu na testowanie aplikacji, żeby były one

możliwie jak najbezpieczniejsze, odporne na błędy oraz optymalne.

Cała analiza danych i testy zostały przeprowadzone na wszystkich funkcjonalnościach systemu a dane zestawione w tabeli 2 prezentują podsumowanie poszczególnych aplikacji internetowych. Podczas testów nieokreśloną pomocą w aplikacji wykonanej za pomocą Magento okazała się funkcja Mage::log() [12], pozwalająca w pliku logów wyświetlić poszczególne elementy wprowadzane do funkcji jak i ich przetwarzanie. Szeroko rozbudowany

system jakim jest platforma e-commerce pozwala także dzięki modelowi MVC na wielokrotne wykorzystanie raz

zdefiniowanych funkcji w Helper, odwołując się do nich. Jest to podstawowy atut dla efektywności i łatwości rozbudowy całego systemu, co spowodowało, że ten właśnie serwis

wykonany przy pomocy frameworka Zend został wyżej oceniony niż aplikacja FitnessApp. Niestety jednak czas ładowania strony różni się i to znacząco, ponieważ Magento wykorzystuje wiele bibliotek i załączenie każdej z nich zajmuje znaczącą ilość czasu. Na końcu porównując czytelność kodu, zdecydowanie i to bardzo mocno przeważa aplikacja w Magento, jest to spowodowane ogromną liczbą

wspomnianych wcześniej bibliotek które pozwalają wykorzystać wbudowane funkcje i wykorzystać je do dalszej pracy

6. Wnioski

Przedstawione w artykule dwa programy różnią się miedzy sobą sposobem wykonania, jednak ich funkcjonalność pozostaje ta sama. Oba serwis działają poprawnie, zapisują i odczytują dane oraz analizują je. Aplikacja FitnessApp nie

posiada natomiast walidacji adresu email, w przeciwieństwie do aplikacji korzystającej z Magento 1.9. Liczne biblioteki wybudowane pozwalają systemowi zbudowanemu za pomocą platformy e-commerce na niezwykle szerokie pole do

rozwoju i to z ogromną łatwością. Mimo różnicy czasu jaka pojawia się przy tworzeniu aplikacji, aplikacja z wykorzystaniem platformy Magento jest dużo bardziej skuteczna, intuicyjna i posiada większe możliwości. Testy jednostkowe wykazały, że aplikacja też posiada znacznie

mniej błędów, czyli jest mniej awaryjna oraz bardziej odporna na wprowadzanie błędnych danych, waliduje je poprawnie. Jednym z minusów tak zaprojektowanej aplikacji jest trudność nauki jaką jest przyswojenie wszystkich funkcji wbudowanych. Jednak ich opanowanie otwiera przed

programistą ogromne możliwości.

Literatura

[1] http://www.internetlivestats.com/internet-users-by-country/

Statystyki Internetu [14.07.2017],

[2] Yank K., Build Your Own Database-Driven Website Using

PHP & MySQL, SitePoint, 2003,

[3] Ross J., PHP i HTML. Tworzenie dynamicznych stron WWW,

Helion, 2010,

[4] http://www.cs.put.poznan.pl/jkobusinski/php.html Opis oraz

z statystyki Zend framework [17.07.2017]

[5] Sanborn M., Lehm M., Leising R., Fowler R. Documentation

for Magento Developers, 660 York ST San Francisco CA

94110.

[6] Martin R. C., Czysty kod. Podręcznik dobrego programisty, Helion, 2015.

[7] Gajda W., PHP, MySQL i MVC. Tworzenie witryn WWW

opartych na bazie danych, Helion, 2010.

[8] http://www.cminds.com/magento-updated-statistics/ Statystyki

Magento [10.07.2017]

[9] Beck K. Test Driven Development: By Example 1st Edition

[10] Lerdorf R., Tatroe K., MacIntyre P., Programming PHP,

Helion, 2007.

[11] Feathers Michael Working Effectively with Legacy Code

(Robert C. Martin Series) 1st Edition, Kindle Edition.

[12] Branko Ajzele, Magento 2 Developer's Guide, 2015.

http://www.cs.put.poznan.pl/jkobusinski/php.html

JCSI 6 (2018) 12-19



12

Analiza wpływu technik bezpiecznego programowania na wydajno ć i bezpieczeństwo aplikacji

Tomasz Kobiałka,


Streszczenie. Tematyką podejmowaną w niniejszym artykule są zagrożenia, które należy wziąć pod uwagę podczas tworzenia oprogramowania. W ramach artykułu przybliżono wybrane rodzaje zabezpieczeń przed często wykorzystywanymi lukami bezpieczeństwa. W oparciu o napisane

programy, przeanalizowano wpływ poszczególnych technik bezpiecznego programowania na wydajno ć i bezpieczeństwo aplikacji. Niniejszy artykuł prezentuje zarówno teoretyczny opis zabezpieczeń, jak również przykłady ich technicznej implementacji.

Słowa kluczoweŚ programowanie; bezpieczeństwo; wydajno ć


An analysis of influence of safe programming techniques on applications

efficiency and security

Tomasz Kobiałka


Abstract. The topics covered in this article are the risks that must be taken into account when developing the software. This article gives you an

overview of safeguards against some of the anticipated common security vulnerabilities. Based on the written programs, the impact of the

various techniques of safe programming on the performance and security of the application has been analyzed. This article presents both

a theoretical description of the protections as well as examples of their technical implementation.

Keywords: programming; efficiency; security


1. Wstęp

Tematem artykułu są techniki bezpiecznego programowania oraz analiza ich wpływu na wydajno ć i bezpieczeństwo aplikacji.

W dzisiejszych czasach osiągnięcie sukcesu w branży programistycznej wiąże się z wytężoną pracą wielu ludzi. Zazwyczaj jest to równoznaczne z poniesieniem dużych nakładów finansowych. Zarówno pieniądze, jak i praca mogą pój ć na marne, jeżeli tworzone oprogramowanie nie zostanie dostatecznie zabezpieczone – chociażby przed osobami, które będą umożliwiały korzystanie z produktu w sposób nieautoryzowany. Pod uwagę należy wziąć także możliwo ć osłabienia wizerunku producenta, jeżeli osoba z zewnątrz zdecyduje się rozpowszechniać niebezpiecznie zmienione programy, nie wspominając o tym, że oprogramowanie –

często służące do realizacji celów strategicznych, bądź celów użyteczno ci publicznej – może zostać zaatakowane przez osoby o złych zamiarach. Jako przykład można podać oprogramowanie medyczne, albo obsługujące bankowo ć lub lotnictwo. Atak osoby trzeciej może narazić użytkowników na straty nie tylko finansowe, ale także zdrowotne, a w skrajnych przypadkach nawet utratę życia. Każdy z tych przypadków nasuwa my l o tym, że warto należycie zabezpieczyć stworzony program.

Głównym celem bezpiecznego programowania jest wyeliminowanie możliwo ci użycia programu niezgodnie z jego przeznaczeniem. Jednakże, oprogramowanie o zbyt

restrykcyjnych zabezpieczeniach znacząco zmniejsza swoją użyteczno ć dla zwykłych użytkowników. Dlatego należy tak dopasować używane techniki, aby znaleźć kompromis pomiędzy zapewnieniem bezpieczeństwa, a pozostawieniem swobody końcowemu odbiorcy.

2. Zagrożenia

2.1. Wstrzykiwanie kodu SQL

Wstrzykiwanie kodu SQL (ang. SQL injection) jest

techniką używaną do atakowania aplikacji, których kluczowym komponentem jest baza danych i dane na niej

zgromadzone. Technika polega na wprowadzeniu do pola

wej ciowego aplikacji takiego zapytania SQL, którego wynikiem będzie działanie pożądane przez osobę atakującą, a potencjalnie niebezpieczne dla aplikacji i danych, z których korzysta. SQL injection wykorzystuje luki w bezpieczeństwie aplikacji, np. brak filtrowania danych wej ciowych, tudzież brak ustalania konkretnych typów dla każdego wyrażenia w kodzie aplikacji (typowanie słabe), a w konsekwencji powstanie możliwo ci wykonania wstrzykiwanego zapytania. Atakujący może sfałszować tożsamo ć, usunąć lub zmienić dane w bazie oraz naruszyć ich integralno ć, a nawet przyznać sobie uprawnienia administratora bazy. Badania

wykazały, że przeciętna aplikacja webowa jest narażona na rednio 4 ataki tego typu w miesiącu, a prób wstrzyknięcia

SQL aplikacjom sklepów internetowych jest dwa razy więcej niż innym aplikacjom [1]. Na rysunku 1. zaprezentowano przykładową próbę wstrzyknięcia kodu SQL.


13

Rys 1Ś Przykładowa próba wstrzyknięcia kodu SQL

2.2. Przepełnienie bufora

Przepełnienie bufora (ang. buffer overflow) jest anomalią, w której program podczas zapisu danych do bufora przekracza granice pamięci bufora i nadpisuje sąsiadujące

lokacje pamięci. Błąd tego typu najczę ciej jest wywoływany przez zniekształcone wej ciaś jeżeli podczas powstawania programu założono, że wszystkie wej cia będą mniejsze niż pewna warto ć i pojemno ć bufora jest ustawiona dokładnie na tę warto ć, nieprawidłowa transakcja, która produkuje więcej danych niż przewidziano powoduje zapis danych poza zakresem pamięci bufora. W momencie, w którym sąsiadujące w pamięci z buforem dane lub kod wykonywalny są nadpisywane, program najczę ciej zaczyna zachowywać się niestabilnie, następują błędy w dostępie do pamięci, dane wynikowe są błędne, a często program przedwcze nie kończy swoje działanie [2]. Schemat poglądowy takiej sytuacji został zaprezentowany na rysunku 2. Atakujący powoduje przepełnienie bufora i zmienia adres powrotu. Zamiast

powrotu do wła ciwego wywołania procedury, zmodyfikowany adres oddaje sterowanie zło liwemu kodowi, mieszczącemu się w innym miejscu pamięci procesu.

Wykorzystywanie przepełnienia buforu do przeprowadzania ataków jest powszechnie stosowaną przez hakerów praktyką. W wielu systemach układ pamięci programu, albo całego systemu, jest poprawnie zdefiniowany. Poprzez przesłanie danych mających na celu wywołanie przepełnienia, zapis w miejsca pamięci, mający na celu zastąpienie wykonywanego kodu zło liwym kodem staje się możliwy. Nowoczesne systemy operacyjne używają różnych technik by zwalczać zło liwe przepełnienia bufora, szczególnie poprzez randomizację układu pamięci, a także celowe zachowywanie przerw pomiędzy buforami i analizę zachowań, które powodują zapis danych do tych czę ci pamięci, w których zaalokowany jest bufor. [3]

Rys 2Ś Bufor podczas normalnej pracy oraz w momencie wystąpienia ataku

2.3. Zakleszczenie

Zakleszczenie, inaczej blokada wzajemna (ang. deadlock)

jest stanem, w którym każdy uczestnik grupy akcji czeka na zwolnienie blokady przez innego uczestnika. Zakleszczenie

jest częstym problemem w systemach wieloprocesowych, programowaniu równoległym oraz obliczeniach rozproszonych, gdzie programowe i sprzętowe blokady są używane do zarządzania zasobami współdzielonymi i w implementacjach synchronizacji procesów. W systemach operacyjnych blokada wzajemna występuje kiedy proces lub wątek przechodzi w stan czekania, ponieważ żądane przez niego zasoby systemowe są wstrzymywane przez inny proces

w stanie czekania, który z kolei czeka na dostęp do innych zasobów wstrzymywanych przez kolejny czekający proces. Zakleszczenie następuje wtedy, gdy wątek lub proces nie jest w stanie zmienić swojego stanu z powodu używania żądanych przez jego zasobów przez inny proces w stanie


14

oczekiwania [4][5].

Rys 3Ś Schemat poglądowy sytuacji wystąpienia zakleszczenia

2.4. Inżynieria wsteczna

Inżynieria wsteczna (ang. reverse engineering) to czynno ć polegająca na analizie oprogramowania, mająca na celu pozyskanie wiedzy o jego działaniu i budowie. Informacje te mogą zostać wykorzystane do pozyskania nieautoryzowanej wiedzy o oprogramowaniu i jego

funkcjonowaniu, a także do jego modyfikacji. Wiedza ta może być wykorzystana do uzyskania z pozoru niedostępnych

informacji o oprogramowaniu czy też jego modyfikacji.

Najczęstsze cele inżynierii wstecznejŚ odzyskiwanie i modyfikacja kodów źródłowych, odtwarzanie algorytmów szyfrowania i kompresji, analizowanie danych i algorytmów aplikacji po skompilowaniu, łamanie szyfrów zabezpieczonych plików (bazy danych, pliki konfiguracyjne), analizowanie protokołów sieciowych.

Inżynieria wsteczna to proces analizy aplikacji, której kod nie jest powszechnie dostępny. Dzięki niej, cracker jest w stanie odtworzyć i zrozumieć logikę programu, a także uzyskać wiedzę na temat jego kompletnego działania, która może być wykorzystana do znajdowania i korzystania z luk w programie. Patrząc pod kątem bezpieczeństwa, utrudnianie tego procesu potencjalnym osobom atakującym oprogramowanie jest bardzo ważne [6].

3. Techniki zabezpieczeń

3.1. SQL injection

Przyczyną ataków polegających na wstrzyknięciu kodu SQL jest zazwyczaj wykorzystanie parametru, który może zawierać dane wysłane przez osobę atakującą, bez odpowiedniego przefiltrowania tych danych. W ten sposób osoba trzecia jest w stanie wstrzyknąć fragment kodu, który zmieni wynik całego zapytania [7].

Przykład 1. Przykład skryptu przechwytującego dane z formularza

<? include "db_connect.php"; $login = $_POST['login']; $pass = $_POST['pass']; $wynik = mysql_query("SELECT login FROM db_users WHERE login='$login' AND password=PASSWORD('$pass')"); if(mysql_num;rows(Swynik) > 0) {

$rekord = mysql_fetch_array($wynik); echo "LOGIN OK: ".$rekord['login'];

} else { echo "LOGIN FAILED"; include "form.html"; } ?>

Przykładowy skrypt PHP zaprezentowany w przykładzie 1 przechwytuje dane z formularza wysłanego przez użytkownika. Kod ten jest potencjalnie niebezpieczny –

używa w zapytaniu danych uzyskanych od użytkownika z pominięciem jakiejkolwiek filtracji. Daje to atakującemu możliwo ć zalogowania się na konto dowolnego użytkownika – wystarczy znajomo ć loginu. Wystarczy, że w formularzu jako login zostanie podany ciąg znakówŚ „ user' –- ”, a jako hasło dowolne wyrażenie. Tym sposobem, po pobraniu z formularza danych skrypt PHP wykona zapytanie

przedstawione w przykładzie 2.

Przykład 2. Zapytanie SQL z wstrzykniętym kodem rozpoczynającym komentarz

SELECT * FROM db_users WHERE login='nazwa_uz' -- ' AND password='dowolne'

Czę ć zapytania, następująca po podwójnym my lniku zostanie zinterpretowana jako komentarz, wykonane jest

więc zapytanie tożsame z zaprezentowanym w przykładzie 3.

Przykład 3. Zapytanie SQL, które faktycznie zostanie wykonane

SELECT * FROM db_users WHERE login='nazwa_uz'

W ten sposób osoba trzecia jest w stanie zalogować się na konto dowolnego użytkownika. W wielu przypadkach konto posiadające uprawnienia administratora ma login „admin” bądź „administrator”. W związku z tym możliwe dla atakującego staje się przejęcie czę ciowej lub niemal całkowitej kontroli nad systemem.

W przypadku nieznajomo ci jakiegokolwiek loginu, atakujący również jest w stanie zalogować się do systemu. Wystarczy, że w formularzu logowania poda dowolny login i hasło będące następującym wyrażeniemŚ „ ') OR 1=1-- ”. Zapytanie wykonane przez skrypt widoczny w przykładzie 2 będzie miało następującą postać zaprezentowaną w przykładzie 4.

Przykład 4. Zapytanie SQL z wstrzykniętym warunkiem

SELECT * FROM db_users WHERE login=" AND password=PASSWORD(' ') OR 1=1 -- ')

Sytuację, w której również wykona się tylko czę ć, która nie została zakomentowana przedstawia przykład 5.

Przykład 5. Zapytanie SQL, które faktycznie zostanie wykonane

SELECT * FROM db_users WHERE login=" AND password=PASSWORD(' ') OR 1=1

Przykład pokazuje wstrzyknięcie do wyrażenia warunku, który zawsze jest prawdziwy (1=1). Zapytanie zwróci jako wynik wszystkie konta utworzone w systemie, a osoba

atakująca zostanie zalogowana na konto utworzone jako pierwsze. Często pierwszym kontem w bazach danych systemów jest konto administratora.


15

Powyższe sposoby ataków wymagają użycia specjalnych znaków, które są czę cią składni języka SQL. W celu zabezpieczania systemu przed wstrzykiwaniem kodu, należy zaimplementować filtrację danych pobranych od użytkownika przed ich przekazaniem do zapytania. W niektórych przypadkach wystarczy usunięcie możliwo ci korzystania ze znaku „'”, co uniemożliwi osobie nieuprawnionej ominięcie znaku otaczającego warto ć którego z parametru. W przypadku, gdy nie jest to możliwe, należy skorzystać z funkcji addslashes() - funkcja ta poprzedza każdy potencjalnie niebezpieczny znak znakiem „\”. Mniej uniwersalnym rozwiązaniem – ponieważ działającym tylko z niektórymi rodzajami baz danych (np. MySQL) jest użycie funkcji (lub jej odpowiednika) mysql_real_escape_string(),

która po zidentyfikowaniu zestawu znaków bazy danych dodaje „\” do znaków, które są czę cią składni SQL i są potencjalnie niebezpieczne [8]. Istotnym sposobem

zabezpieczenia jest również używanie symbolu „'” przy przekazywaniu każdego parametru nawet w przypadkach, w których składnia SQL tego nie wymaga. Uniemożliwia to atakującemu wstrzyknięcie kodu w pasku adresu przeglądarki przy wywoływaniu zapytania. [9]


Zapobieganie błędom przepełnienia bufora wymaga zwracania szczególnej uwagi na używane przy tworzeniu oprogramowania funkcje. Powinny one brać pod uwagę rozmiar danych, które są ich parametrami. Bardzo często za problemy tego typu odpowiadają funkcje obsługujące łańcuchy tekstowe. W przykładzie 6 przedstawiono wywołanie funkcji strcpy.

Przykład 6. Wywołanie strcpy

char *strcpy( char *strDestination, const char *strSource )

Na listingu widać, że funkcja strcpy w żaden sposób nie sprawdza rozmiaru danych, które przyjmuje. W wielu sytuacjach jej działanie zostanie zakończone wystąpieniem błędu, np. gdy bufor, z którego kopiujemy oraz docelowy nie

zawierają żadnych danych, jeżeli strSource nie kończy się jako null, a najczę ciej gdy łańcuch źródłowy jest większy od bufora.

Bezpieczniejszym rozwiązaniem jest użycie funkcji strncpy, która sprawdza rozmiar danych wej ciowych i bufora

docelowego. Listing pokazany jako przykład 7 przedstawia wywołanie funkcji.

Przykład 7. Wywołanie strncpy

char *strncpy( char *strDest, const char *strSource, size_t count )

3.3. Zakleszczenie

Przeważająca czę ć reakcji systemów operacyjnych na zakleszczenie opiera się na zapobieganiu wystąpienia jednego z czterech warunków Coffmana (wzajemne wykluczanie, przetrzymywanie i oczekiwanie, brak wywłaszczeń i czekanie cykliczne). W systemach, w których występuje rozpoznawanie zakleszczeń, w momencie wystąpienia zakleszczenia, następuje detekcja stanu systemu w celu

wykrycia, czy blokada nastąpiła, a następnie czy została skorygowana. Uruchomiony zostaje algorytm, który ledzi alokację zasobów oraz stan procesów, w wyniku którego następuje cofnięcie systemu do stanu sprzed wystąpienia błędu. Proces, w którym nastąpiło zakleszczenie zostaje uruchomiony ponownie.

Istnieją algorytmy zapobiegania zakleszczeniom. Ich działanie polega na organizacji użycia zasobów przez każdy proces tak, aby zapewnić warunki, w których przynajmniej

jeden proces zawsze jest w stanie uzyskać dostęp do zasobów, których potrzebuje. Często używanym rozwiązaniem jest algorytm bankiera, autorstwa Edsgera Dijkstry. Przeciwdziała on nastąpieniu blokady „deadlock” poprzez odmowę lub zawieszenie procesom możliwo ci dostępu do danych w sytuacji, w której uzyskanie dostępu do danego zasobu mogłoby skutkować stanem niebezpiecznym systemu.


Jedną z praktyk utrdudniających inżynierię wsteczną jest zaciemnianie kodu. W przypadku języków interpretowanych

(np. PHP), należy zmodyfikować kod w taki sposób, aby był rozumiany przez interpreter, ale dla człowieka, który uzyskał do niego dostęp w sposób nieautoryzowany był możliwie mało czytelny. Sposoby zaciemniania koduŚ

szyfrowania i deszyfrowanie kodu podczas jego działania, zmiana nazw zmiennych i funkcji na losowe ciągi znaków, wyeliminowanie znaków spacji oraz nowego wiersza –

kod w jednej linii, zapis stałych tekstowych za pomocą kodów ASCII [10].

Korzystając z powyższych metod można znacznie

utrudnić lub wręcz uniemożliwić osobie niepowołanej uzyskanie w jakikolwiek użytecznego kodu źródłowego.

W przypadku programów napisanych w językach kompilowalnych, oprócz wymienionych wyżej metod podstawową zasadą bezpieczeństwa jest usunięcie informacji,

z których korzysta program debugujący. Niemal wszystkie kompilatory każdego języka mają taką możliwo ć, ponieważ kwestia ta jest kluczowa dla ochrony programu. W przypadku

pominięcia tej zasady, osoba nieuprawniona jest w stanie dokonać skutecznej dekompilacji kodu i w efekcie uzyskać kod aplikacji zbliżony do oryginalnego i umożliwiający zrozumienie szczegółów działania programu [11]. W przykładzie 8 zaprezentowano kod programu wypisującego liczby pierwsze.

Przykład 8. Kod programu przez zaciemnieniem

void primes(int cap) { int i, j, composite; for(i = 2; i < cap; i++) { composite = 0; for(j = 2; j < i; j++) composite += !(i % j); if(!composite) printf("%d\t", i); } } int main() {


16

primes(100); }

Przykład 9 przedstawia kod z przykładu 8 po przeprowadzeniu zaciemniania.

Przykład 9. Kod programu po zaciemnieniu

_(__,___,____){___/__<=1?_(__,___+1,____):!(___%__)?_(__,___+1,0):___%__==___/ __&&!____?(printf("%d\t",___/__),_(__,___+1,0)):___%__>1&&___%__<___/__?_(__,1+ ___,____+!(___/__%(___%__))):___<__*__?_(__,___+1,____):0;}main(){_(100,0,0);}

Innym rozwiązaniem jest kompresja plików wykonywalnych. Pliki te zostają skompresowane przez zewnętrzne oprogramowanie, a następnie są dekompresowane podczas wykonywania programu wła ciwego. Zaletą tego rozwiązania jest również zmniejszenie rozmiaru plików;

spowalnia to jednak pracę programu. Sposób ten zapewnia jednak stosunkowo mały poziom zabezpieczenia. [12]

4. Analiza wpływu zabezpieczeń na działanie

4.1. Wstrzykiwanie kodu SQL

Badanie wpływu technik bezpiecznego programowania na aplikacje webowe wykonano z wykorzystaniem kodu PHP.

Posłużono się autorską, niezabezpieczoną aplikacją webową. Badanie objęło obronę przed atakami typu cross-site

scripting, SQL injection oraz shell injection. W przykładzie 11 zaprezentowano fragment skryptu przechwytującego dane z formularza wypełnianego przez użytkownika. Dla celów badania, zmierzono czas wykonania skryptu – wynosi on

0,091 s (jest to zaokrąglony redni czas wykonania z dziesięciu prób).

Przykład 10. Niezabezpieczone przechwytywanie danych z formularza

if (isset($_POST['zglos'])) { $temat = $_POST['temat']; $opis = $_POST['opis']; $data_rozp = $_POST['data_rozp']; $data_zak = $_POST['data_zak']; $godz_rozp = $_POST['godz_rozp']; $godz_zak = $_POST['godz_zak']; $liczba_u = $_POST['liczba_u']; $user=$_POST['user']; mysql_query("INSERT INTO ‘wydarzenie‘ (‘temat‘, ‘data_rozp‘, ‘data_zak‘, ‘godz_zak‘, ‘id_user‘, ‘opis‘) VALUES ( ' " . Stemat . " ' , STR_TO_DATE ( ' " . date ( ' Y-m-d' ) . " ' , ' %Y-%m-%d' $data_zak."', '".$godz_zak."', '".$user."', '".$opis."');"); header('Location: zaw.php?id='.$id_w); ob_flush(); }

Kod zaprezentowany w przykładzie 10 przejmuje dane z formularza POST. Instrukcja warunkowa sprawdza, czy

nastąpiło ustawienie pola odpowiedzialnego za zatwierdzenie

(przesłanie) formularza, zdefiniowanego wcze niej jako „zglos”. Jeżeli warunek jest spełniony, do kolejnych

zmiennych przechwytywane są odpowiednio nazwane pola formularza. Następnie z poziomu kodu PHP następuje wykonanie zapytania SQL, wstawiającego dane przesłane w formularzu do nowego rekordu w bazie danych. Po tej

operacji użytkownik jest przekierowywany do kolejnej strony i następuje przesłanie danych z bufora wyj ciowego.

Dane pobrane od użytkownika nie są w żaden sposób filtrowane. Oznacza to, że użytkownik może przeprowadzić dowolny atak możliwy z poziomu przeglądarki. Podstawową funkcją zabezpieczającą jest htmlentities(), która konwertuje wszystkie zawarte w polu formularza znaczniki HTML do

postaci encji. Wszystkie przykładowe znaki specjalne oraz

znaczniki html zostały skonwertowane na encje.

W celu zbadania wydajno ci, zaimplementowano rozwiązanie w skrypcie przechwytującym dane z formularza. Kod źródłowy przedstawiono na listingu w przykładzie 11.

Przykład 11. Przechwytywanie danych po użyciu funkcji htmlentities()

if (isset($_POST['zglos'])) { Stemat = htmlentities($_POST['temat']); Sopis = htmlentities($_POST['opis']); $data_rozp = htmlentities($_POST['data_rozp']); $data_zak = htmlentities($_POST['data_zak']); $godz_rozp = htmlentities($_POST['godz_rozp']); $godz_zak = htmlentities($_POST['godz_zak']); $liczba_u = htmlentities($_POST['liczba_u']);

$user=$_POST['user']; mysql_query("INSERT INTO ‘wydarzenie‘ (‘temat‘, ‘data_rozp‘, ‘data_zak‘, ‘godz_zak‘, ‘id_user‘, ‘opis‘) VALUES (' " . Stemat . " ' , STR_TO_DATE ( ' " . date ( ' Y- m-d') . " ' , ' %Y-%m- %d' $data_zak."', '".$godz_zak."', '".$user."', '".$opis."');"); header('Location: zaw.php?id='.$id_w); ob_flush(); }

Zmierzony czas wykonania skryptu wyniósł 0,126 s (jest to zaokrąglony redni czas wykonania z dziesięciu prób). Zastosowanie „htmlentities” w zauważalny sposób wpłynęło na wydajno ć. Czas wykonania skryptu zwiększył się o około 37 ms, co oznacza wzrost o niemal 41%.

Kolejną funkcją, którą można zastosować jest mysql_real_escape_string. Jest to implementacja funkcji

dodającej znaki uniksowe – lewe uko niki – do znaków mogących być czę cią kodu SQL. Zastosowana implementacja to wersja tej funkcji dla bazy MySQL. Ważne jest, żeby w momencie użycia funkcji połączenie z bazą było otwarte, inaczej funkcja nie zadziała.

W celu zbadania wydajno ci, zaimplementowano rozwiązanie w skrypcie przechwytującym dane z formularza. Czas wykonania skryptu wyniósł 0,153 s (jest to zaokrąglony redni czas wykonania z dziesięciu prób). Zastosowanie

„mysql_real_escape_string” istotnie wpłynęło na wydajno ć. Czas wykonania skryptu zwiększył się o około 61 ms, co oznacza wzrost o o 67% w porównaniu z czasem wykonania niezabezpieczonego skryptu.


17

W celu zabezpieczenia aplikacji za pomocą obydwu

rozwiązań, utworzono funkcję filtruj(), która zwraca łańcuch „oczyszczony” z potencjalnych niebezpieczeństw. Dla dziesięciu powtórzeń, redni czas jednego wykonania skryptu wynosi 0,168 s. Zastosowanie filtracji danych w do ć znaczący sposób wpływa więc na szybko ć działania skryptu. Czas wykonania zwiększa się niemal dwukrotnie. Ciągle nie jest to jednak warto ć zauważalna dla użytkownika. W przypadku formularzy zbliżonych do badanego, czyli posiadających około siedmiu pól, metoda filtracji danych może być z powodzeniem stosowana – wpływ na wydajno ć będzie znikomy.

Wpływ na bezpieczeństwo aplikacji polega na udaremnieniu prób ataków na aplikację przy pomocy przeglądarki bądź narzędzi służących do zło liwego wykorzystywania luk w formularzach. Filtracja danych

zapobiega zmianie warunków wykonania się zapytania SQL, a zamiana znaczników HTML na encje ustrzeże aplikację przed wstrzyknięciem potencjalnie zło liwego skryptu, mogącego zaatakować system lub którego z użytkowników.


Występowanie błędów bufora zależy w dużej mierze od ostrożno ci programisty, zarówno w programowaniu, jak i w wybieraniu technologii tworzenia oprogramowania.

Istnieją jednak funkcje narażone na wygenerowanie tego błędu, które posiadają zabezpieczone odpowiedniki –

w ramach badania zmierzono wpływ ich użycia na wydajno ć aplikacji.

Na listingu w przykładzie 12 zaprezentowano propozycję zabezpieczenia przed przepełnieniem bufora funkcji kopiującej łańcuch.

Przykład 12. Bezpieczne użycie strcpy

bool obslugaStGCy(const char* input) { char buf[80]; if(input == NULL) { assert(false); return false; } if(strlen(input) < sizeof(buf)) strcpy(buf, input); else return false; return true; }

Funkcja „strcpy” nie przyjmuje jako argument rozmiaru bufora, co czyni ją niebezpieczną w przypadku próby kopiowania łańcucha dłuższego niż pojemno ć bufora docelowego. Za pomocą instrukcji warunkowej zabezpieczono ją więc przed taką sytuacjąś w przypadku zbyt dużego rozmiaru łańcucha wej ciowego funkcja zwraca warto ć „false”, co oznacza, że operacja kopiowania łańcucha nie została wykonana. To samo dzieje się w przypadku, gdy bufor, z którego kopiujemy nie zawiera żadnych danych. Pomiar czasu wykonania funkcji dla argumentu o długo ci dwudziestu znaków przeprowadzono w pętli – czas

pojedynczego wykonania był trudny do wychwycenia. Pętla

wykonała 10000 iteracji, z których wyciągnięto redni czas wykonania funkcji.

Tabela 1. Czas wykonania implementacji obsługi strcpy

Liczba wykonań redni czas wykonania [ms] 10000 0.00091188196

Czas wykonania funkcji jest bardzo krótki – wynosi

niespełna 1ms. Zabezpieczenie ma znikomy wpływ na wydajno ć aplikacji – wyniki pomiaru czasu wykonania

funkcji bez zabezpieczenia różnią się o pomijalne warto ci. Przedstawia je tabela 4.25.

Tabela 2. Czas wykonania implementacji obsługi strcpy – bez

zabezpieczenia


Kolejną badaną funkcją jest strncpy. Listing w przykładzie 13 przedstawia implementację obsługi tej funkcji dla potrzeb badawczych.

Przykład 13. Bezpieczne użycie strncpy

bool obslugaStrncpy(const char* input) { char buf[80]; if(input == NULL) { assert(false); return false; } buf[sizeof(buf) - 1] = '\0'; strncpy(buf, input, sizeof(buf));

if(buf[sizeof(buf) - 1] != '\0') return false; return true; }

Funkcja „strncpy” jest bezpieczniejsza od „strcpy”, ponieważ przyjmuje jako parametr rozmiar kopiowanego łańcucha wej ciowego. Ciągle jednak program należy zabezpieczyć przed pustym parametrem wej ciowym oraz brakiem znaku null na końcu łańcucha. W badanej

implementacji zabezpieczanie zostało zrealizowane za pomocą instrukcji warunkowych – w przypadku wystąpienia wyżej wymienionych zagrożeń funkcja zwróci warto ć „false”, a funkcja „strncpy” nie wykona się. W tabeli 3 przedstawiono wyniki pomiaru czasu wykonania funkcji.

Tabela 3. Czas wykonania implementacji obsługi strncpy


W porównaniu do użycia w implementacji mniej bezpiecznej funkcji „strcpy”, czas wykonania programu nieznacznie wzrósł. Spowodował to nieco dłuższy czas wykonania funkcji kopiującej, która przyjmuje dodatkowy parametr.

Kolejną badaną funkcją jest „snprintf”. Funkcja również realizuje funkcjonalno ć zapisywania sformatowanego łańcucha źródłowego w zadanym buforze docelowym. Funkcja jest niemal w pełni bezpieczna, ponieważ została zabezpieczona przed wszystkimi argumentami mogącymi wywołać przepełnienie bufora. Dodatkowym zabezpieczeniem jakie należy zastosować jest sprawdzenie


18

zakończenia łańcucha znakiem „\0”, czyli null. Kod implementacji przedstawiono w przykładzie 14.

Przykład 14. Obsługa snprintf

bool obsluga_snprint(int line, unsigned long err, char* msg) { char buf[132]; if(msg == NULL) { assert(false); return false; } if(_snprintf(buf, sizeof(buf)-1, Bład w linii %d = %d - %s\n", line, err, msg) < 0) return false; else buf[sizeof(buf)-l] = '\0'; return true; }

Oprócz samego wywołania funkcji, następuje sprawdzenie, czy wiadomo ć kopiowana nie jest pusta. W przypadku możliwo ci wystąpienia przepełnienia, funkcja zwróci „false”, a „_snprintf” nie wykona się. Jeżeli dane są poprawne, funkcja wykonuje się, a bufor docelowy zostaje zakończony znakiem null. Wyniki pomiaru czasu wykonania implementacji zaprezentowano w tabeli 4.

Tabela 4. Czas wykonania implementacji obsługi _snprintf


Czas wykonania implementacji funkcji dla tego samego

łańcucha jest niemalże taki sam jak

w przypadku implementacji korzystającej z funkcji „strncpy”. Oznacza to podobny, mały negatywny wpływ na wydajno ć aplikacji – wyniki pomiaru prezentuje tabela 5.

Tabela 5. Czas wykonania implementacji obsługi _snprintf

Implementacja strcpy strncpy snprintf Zajęta pamięć 17 KB 21 KB 22 KB

Z pomiaru pamięci zajmowanej przez poszczególne implementacje wynika, że implementacja używająca funkcji „strcpy” potrzebuje nieco mniej zasobów. Jest to jednak funkcja najmniej bezpieczna, a różnica w wydajno ci pomiędzy nią a bardziej bezpiecznymi funkcjami jest bardzo niewielka.

4.3. Zakleszczenie

Zabezpieczanie programu przed błędami związanymi z dostępem procesów do zasobów jest w dużej mierze kwestią podej cia programisty do strony teoretycznej tworzonego oprogramowania. Techniką, która pozwala zapobiec tego typu błędom jest używanie algorytmu bankiera. W ramach badania zabezpieczenia przed błędami związanymi z alokacją procesów, przygotowano implementację algorytmu bankiera w języku Java. Działanie algorytmu polega na stworzeniu bezpiecznego ciągu. Algorytm stara się zaalokować wszystkie procesy.

W ramach badania zbadano szybko ć działania algorytmu dla konkretnych danych wej ciowych.

Dane wej ciowe użyte w algorytmie zaprezentowano w tabeli 6.

Tabela 6. Badanie algorytmu bankiera – dane wej ciowe

Rodzaj Dane 10000 3 Liczba zasobów 4

Tablica alokacji

1 2 2 1

1 0 3 3

1 2 1 0

Tablica maks. liczby egz.

zasobu

3 3 2 2

1 1 3 4

1 3 5 0

Tablica przydziału 3 1 1 2

Algorytm poprawnie bezkonfliktowo alokuje wszystkie

procesy. Zmierzono czas wykonania operacji alokacji.

Wyniki zaprezentowano w tabeli 7.

Tabela 7. Badanie algorytmu bankiera – czas wykonania

Dane wej ciowe redni czas wykonania [ms] Tabela 6 0.1054663

redni czas wykonania operacji alokacji procesów dla podanych danych wej ciowych (3 procesy, 4 zasoby) wynosi około 1 ms. Oznacza to, że fakt skorzystania z algorytmu praktycznie nie wpływa na wydajno ć, za to kompleksowo eliminuje błędy związane z wątkami i zasobami, w przypadku znajomo ci informacji o żądanych, używanych i aktualnie dostępnych zasobach.


Badanie zaciemniania kodu przeprowadzono na

przykładzie działania programu Dotfuscator. Obiektem

badania była przykładowa aplikacja, działająca w rodowisku .NET Frawework 4. W celu próby przeprowadzenia inżynierii wstecznej, użyto programu .NET Reflector 9.0.

Kod aplikacji został łatwo zdekompilowany. Widoczna jest kompletna struktura, sygnatury oraz ciała metod. Poniżej przedstawiono pomiar czasu inicjalizacji niezabezpieczonego

przed inżynierią wsteczną programu.

Tabela 8. Czasy inicjalizacji programu przed obfuskacją

Przypadek redni czas wykonania [s] Projekt 1, przed użyciem .NET

Reflectora 2.821105

redni czas inicjalizacji programu wyniósł w przybliżeniu 2,8 s.

Następnie przeprowadzono zaciemnianie kodu programem Dotfuscator. Operacja obfuskacji została przeprowadzona bez zmiany standardowych parametrów programu. Dotfuscator umożliwia ustanawianie własnych reguł zaciemniania kodu podczas każdego etapu tego procesuŚ zmiany nazw, zmiany przebiegu wykonania, szyfrowania

łańcuchów, usuwania niepotrzebnych fragmentów kodu i łączenia bibliotek. Po uzyciu programu Dotfuscator,

przeprowadzono ponowną próbę inżynierii wstecznej na badanym programie przy pomocy .NET Reflectora. Kod po


19

zaciemnieniu jest trudny do rozczytania. Przeprowadzono

zmianę przebiegu wykonania oraz zmianę nazw (klas, zmiennych obiektów). Dodatkowo, kod programu został zoptymalizowany, a nieużywane fragmenty kodu zostały usunięte. Poniżej przedstawiono wyniki pomiaru czasu inicjalizacji programu po zaciemnieniu i optymalizacji kodu.

Tabela 9. Czasy inicjalizacji programu po obfuskacji

Przypadek redni czas wykonania [s] Projekt 1, po użyciu .NET Reflector

2.391155

Z wyników badania wynika, że czas redni inicjalizacji programu po obfuskacji jego kodu wyniósł około 2,4 s. Oznacza to, że program Dotfuscator oprócz dużego wpływu na bezpieczeństwo aplikacji, wpływa również korzystnie na jej wydajno ć. W przypadku badanego programu, przyspieszenie inicjalizacji jest minimalneś można się spodziewać, że korzystny wpływ na szybko ć wykonania programu teoretycznie powinien rosnąć wraz z rozmiarem projektu – więcej linii kodu zostanie zoptymalizowane.

W celu sprawdzenia prawdziwo ci tej tezy, użyto Dotfuscatora na większym projekcie o niezoptymalizowanym kodzie (zbadano proces generowania GUI). Wyniki

zaprezentowano w tabeli 10.

Tabela 10. Czasy inicjalizacji programu po obfuskacji

Przypadek redni czas wykonania [s] Projekt 2, przed użyciem Dotfuscatora

17.25434

Projekt 2, po użyciu Dotfuscatora

16.85349

Z pomiaru wynika, że skuteczno ć obfuskacji badanym narzędziem nie ro nie wraz z objęto cią kodu poddawanego obróbce, a zależy od większej liczby czynników (zasoby, z jakich program korzysta, złożono ć operacji, które wykonuje itd.). Objęto ć kodu projektu badanego w przypadku drugim jest większa około o miokrotnie od projektu badanego w poprzednim przypadku, a mimo to

przyspieszenie jego wykonania przez Dotfuscator również jest minimalne, a nawet mniejsze.

Zmierzono również ilo ć pamięci zajmowanej przez badane programy po wykonaniu badanych procesów przed i po procesie zaciemniania.

Tabela 11. Porównanie pomiarów zajmowanej pamięci

Projekt Przed obfuskacją Po obfuskacji Projekt 1 6720 KB 6440 KB Projekt 2 68 543 KB 68 512 KB

Z pomiaru wynika, że użycie programu Dotfuscator spowodowało spadek ilo ci pamięci operacyjnej zajmowanej przez program pierwszy o 280 KB. Jest to spadek o około 4%. W przypadku drugiego badanego projektu, ilo ć zajmowanej pamięci zmieniła się o pomijalną warto ć. Wynika z tego, że działanie Dotfuscatora ma również korzystny wpływ na oszczędno ć pamięci potrzebnej do działania badanego programu. Należy jednak pamiętać, że wielko ć tego wpływu mocno zależy od indywidualnych wła ciwo ci danego kodu [5].

5. Wnioski

W ramach artykułu przeprowadzono analizę wpływu wybranych technik bezpiecznego programowania na

wydajno ć i bezpieczeństwo aplikacji, na podstawie własnych implementacji zabezpieczeń oraz implementacji autorstwa innych autorów. Przybliżono tematykę zabezpieczania programu przed błędami oraz atakami niepowołanych osób.

Wnioski, jakie nasuwają się po przeprowadzeniu analizy, to przede wszystkim fakt, że nie istnieje żadne w stu procentach skuteczne zabezpieczenie programu i danych,

którymi operuje. Niezależnie od zastosowanej techniki, zawsze jest ryzyko, że osoba atakująca prędzej czy później będzie w stanie ją obej ć. Zabezpieczenia to ciągła walka

autorów zabezpieczeń z osobami, które pracują nad sposobem ich obej cia. Co nie oznacza, żeby zaprzestawać prób zabezpieczania oprogramowania – utrudnianie hakerom ich

zamiarów jest rzeczą bardzo ważną i istotną dla możliwo ci normalnego korzystania z wszelakich programów.

W ramach artykułu zawarto analizę wybranych rozwiązań, według autora skutecznych i praktycznych. Mnogo ć technik bezpiecznego programowania nie pozwala na zbadanie wszystkich w ramach krótkiego artykułuś analiza innych bądź nowszych rozwiązań może być przedmiotem kolejnych eksperymentów i dyskusji. Kwestie bezpieczeństwa oprogramowania zmieniają się na tyle szybko, że tematyka przedstawiona ta zawsze może być przedmiotem badań.

Literatura

[1] K. Sacha, Inżynieria oprogramowania, Helion, Gliwice, 2010.

[2] Sahel Alouneha, Mazen Kharbutlib, Rana AlQuremb, Procedia

Computer Science, Volume 21, 2013, 250-256.

[3] Herbert Schildt, Java. Kompendium programisty. Wydanie IX,

Helion, Gliwice, 2015

[4] Marcin Lis, Tworzenie bezpiecznych aplikacji internetowych,

Helion, Gliwice, 2014.

[5] http://searchsecurity.techtarget.com/ [02-03-2017]

[6] J. C. Foster, Vitaly Osipov, Nish Bhalla, Niels Heinen, Dave

Aitel, Buffer Overflow Attacks, 2005, 161-228.

[7] J. Viega, M. Messier, C i C++. Bezpieczne programowanie.

Receptury, Helion, Gliwice, 2011.

[8] N. Kalicharan, Java Zaawansowane zastosowania, Helion,

Gliwice, 2014.

[9] Grande, J., Boudol, G., Serrano, M., Proceedings of the 17th

International Symposium on Principles and Practice of

Declarative Programming, PPDP 2015, 149-160.

[10] V. Alessandrini, S. Memory, Application Programming, 2016,

83-99.

[11] Welsch, Y., Schäfer, J., Poetzsch-Heffter, A. Lecture Notes in

Computer Science (including subseries Lecture Notes in

Artificial Intelligence and Lecture Notes in Bioinformatics),

471-500.

[12] Franz, M., Lecture Notes in Computer Science (including

subseries Lecture Notes in Artificial Intelligence and Lecture

Notes in Bioinformatics), 12-22.

http://searchsecurity.techtarget.com/

JCSI 6 (2018) 20-27



20

Wykorzystanie metody eye-trackingu do ewaluacji responsywnej aplikacji

internetowej

Dariusz Meksuła*, Konrad Mikołajczyk*, Małgorzata Plechawska-Wójcik, Magdalena Borys


Streszczenie. Celem niniejszego artykułu jest zaprezentowanie metody eye-trackingu w kontek cie ewaluacji responsywnej aplikacji internetowej zarządzającej praktykami studenckimi. Do okre lenia użyteczno ci aplikacji została wybrana metoda ledzenia ruchu oka ze

względu na jej wysoką obiektywno ć. Za pomocą tej metody można jednoznacznie okre lić gdzie podążał wzrok użytkownika, które elementy

interfejsu przykuwały jego uwagę a które zostały całkowicie pominięte. W ramach pracy zostały przygotowane scenariusze zawierające zadania dla uczestników badań, ankiety oraz wykonano pomiary czasów realizacji poszczególnych zadań. Zgromadzone dane zostały zaprezentowane z wykorzystaniem map cieplnych i cieżek skanowania. W artykule został zawarty aktualny przegląd literatury z dziedziny eye-trackingu oraz

szczegółowy opis samej metody ledzenia ruchu oka. Dodatkowo zostały zawarte informacje na temat obiektu badań, sposobie ich przeprowadzenia oraz rezultaty wraz z dyskusją wyników.

Słowa kluczowe: ewaluacja użyteczno ciś użyteczno ćś eye-tracking; metryki eye-trackingowe


Adresy e-mail: [email protected], [email protected]

The use of eye-tracking methods for evaluation of responsive web application

Dariusz Meksuła*, Konrad Mikołajczyk*, Małgorzata Plechawska-Wójcik, Magdalena Borys Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. The purpose of this article is to present the eye-tracking method in the context of evaluation of responsive web application dedicated

to manage students practices. To determine usability of the application the eye-tracking method has been chosen due to its high objectivity.

Using this method one can unequivocally determine the user gaze direction, which interface elements enchained his attention and which ones

were completely skipped. As part of the work were prepared scenarios with tasks for the research participants, questionnaires and time of the

tasks execution where measured. Collected data were presented as heat maps and scanpaths. The paper covers also actual review of bibliography

of the eye-tracking area and detailed description of the eye-tracking method. What is more the paper gives description of test subject, conducted

test and discusses results.

Keywords: usability evaluation; usability; eye-tracking; eye-tracking metrics


E-mail addresses: [email protected], [email protected]

1. Wstęp

Obecnie patrząc w przeszło ć widzimy ponad dwie dekady [1] ciągłego rozwoju witryn internetowych i ich wpływu na codzienne życie. Budując witryny internetowe główny nacisk kładzie się na użyteczno ć stron, ich prostotę i przejrzysto ć, bogate funkcje wyszukiwania czy responsywny wygląd dla urządzeń mobilnych. Jednak jak sprawdzić czy dana witryna spełnia powyższe wymagania? Aby tego dokonać, opracowano wiele metod i instrumentów do oceny użyteczno ci. Większo ć z nich skupia się przede wszystkim na badaniu specyficznych cech strony internetowej

tj. funkcjonalno ci czy szybko ci. Pozostałe natomiast bazują na subiektywnych opiniach użytkowników. Istotny jest zatem

dobór odpowiedniej techniki do danego problemu. Istotne jest

również aby metody oceny użyteczno ci witryn internetowych a głównie opinie ich odbiorców, były

stosowane już na etapie planowania i projektowania. Takie

podej cie pozwoliłoby na usprawnienie wielu procesów oraz eliminację błędnych założeń projektantów.

Celem niniejszego artykułu jest przedstawienie studium

przypadku wykorzystania techniki eye-trackingu w procesie

ewaluacji responsywnej aplikacji internetowej zarządzającej praktykami studenckimi. Ocena użyteczno ci stworzonej aplikacji została wykonana za pomocą wybranych metryk

eye-trackingowych. Badanie zostało przeprowadzone przy

użyciu stacjonarnego eye-trackera na reprezentatywnej grupie

osób. Otrzymane wyniki badań pozwoliły dowie ć tezy, że podstawą sukcesu witryny internetowej jest jej prostota

i czytelno ć.

2. Przegląd literatury

2.1. Ocena użyteczności oprogramowania

Tworząc stronę internetową, jak również innego rodzaju oprogramowanie warto zwrócić uwagę na jego użyteczno ć. Na podstawie informacji dostępnych w artykule J. Nielsena

[2] metody oceny oprogramowania można podzielić na dwie główne grupy. Pierwsza z nich to metoda oceny jako ci użytkowej uwzględniającej kontekst użytkownika tzn. wszelkie aspekty wynikające ze strony użytkownika mające wpływ na interakcje z oprogramowaniem czyli


21

przyzwyczajenia, do wiadczenia, wiedza czy osobiste odczucia. Druga to ocena jako ci konstrukcyjnej, która uwzględnia przede wszystkim aspekty techniczne m.in. niezawodno ć działania, przejrzysto ć aplikacji, łatwo ć jej konserwacji i efektywno ć. Według P. Krzosa [3] ocena

użyteczno ci jest procesem trudnym, ale i bardzo istotnym zarazem. Tłumaczy to tym, że dużą rolę odgrywają indywidualne preferencje użytkowników, a te mogą być czasami skrajnie różne. Krzos uważa, że oprócz ogólnej satysfakcji użytkowników dużą rolę w ocenie użyteczno ci oprogramowania odgrywa również jego wydajno ć i efektywno ć co poniekąd kształtuje opinię użytkowników. Jako główną i najbardziej powszechną technikę do mierzenia

użyteczno ci przytacza metodę ledzenia ruchu oka i jednocze nie zaznacza, że w każdej metodzie ważna rolę odgrywają odpowiednio przygotowane testy i interpretacja ich wyników. Z podobnego punktu widzenia wychodzą W. Albert i T. Tullis [4]. Dodatkowo ich książka w większym stopniu skupia się nad metrykami ogólnymi min. osobistymi odczuciami i emocjonalnym zaangażowaniu użytkowników w pomiarze użyteczno ci oprogramowania. Autorzy do pomiaru użyteczno ci oprogramowania zastosowali również subiektywne badania ankietowe. P. Kopy ć [5] w swojej

publikacji prezentuje najpopularniejsze narzędzia i techniki do mierzenia użyteczno ci witryn internetowych czy ogólnie oprogramowania. Na pierwszym miejscu opisuje Microsoft

Usability Guidelines czyli wytyczne firmy Microsoft na temat

użyteczno ci różnego rodzaju aplikacji. Wytyczne te składają się z pięciu podstawowych grup. Pierwsze kryterium to Zawartość, które odnosi się do aktualno ci prezentowanych informacji, ich stopniu szczegółowo ci i znaczeniu oraz wykorzystaniu technik multimedialnych. Drugie kryterium to

Łatwość używania rozumiane jako ilo ć wymaganego wysiłku do zapoznania się z funkcjonalno cią i zrozumienia oprogramowania. Kolejne kryterium Promocja to szereg

narzędzi i technik promujących daną aplikację w rodkach masowego przekazu. Następnie wyróżnia się kryterium

Dostosowanie odnoszące się do dopasowania oprogramowania do społeczno ci, nowych technologii i aktualnych trendów. Ostatnie już kryterium to Emocje

rozumiane jako wiarygodno ć aplikacji, stopień zainteresowania u użytkownika i jego osobiste odczucia.

Analizując użyteczno ć oprogramowania warto przytoczyć również wytyczne sporządzone przez J. Nielsena [6], które są najbardziej znane i najczę ciej stosowane. Podobnie jak wytyczne firmy Microsoft, możemy podzielić je na pięć grup. Pierwsza to Nauczalność, odnosi się do łatwo ci wykonywania zadań przy pierwszym kontakcie z oprogramowaniem. Druga Efektywność, rozumiana jako

szybko ć korzystania z oprogramowania u osób, które już go znają. Trzeci element podziału to Zapamiętywalność, czyli

łatwo ć przypomnienia sobie działania oprogramowania po dłuższym czasie niekorzystania. Czwarty dotyczy Błędów, jak

często są popełniane i jak łatwo można się ich pozbyć. Ostatnie kryterium opracowane przez Nielsena to Satysfakcja,

mówiąca o tym czy korzystanie z oprogramowania

pozostawia przyjemne odczucia.

Trudno nie zgodzić się z zaprezentowanymi stwierdzeniami. Głównym celem tworzenia oprogramowania komputerowego, w tym stron internetowych, jest pozyskanie

jak największej liczby użytkowników. Aby tego dokonać

oprogramowanie musi być jako ciowo użyteczne. Jednak, jak

wynika z badań literaturowych, jest to pojęcie względne w stosunku do każdego użytkownika, dlatego należy dążyć do ogólnego konsensusu.

2.2. Przygotowanie badań z wykorzystaniem eye-trackera

Według J. Nielsena i K. Pernice’a [7] stanowisko

badawcze powinno składać się z dwóch podstawowych elementów tj. oprogramowania przeznaczonego do analizy oraz eye-trackera czyli urządzenia rejestrującego ruch oka użytkownika za pomocą odpowiednich czujników. P. Krzos

[3] uważa, że testy należy rozpocząć od odpowiedniego przygotowania miejsca. Zaleca się aby pomieszczenie do

badań nie miało okien na zewnątrz budynku, było jednakowo o wietlone oraz istniała możliwo ć wglądu na badanie z innego pomieszczenia. Dodatkowo informuje, że istnieje szereg mniej ważnych czynników wpływających na jako ć zbieranych danych tj. czy urządzenia rejestrujące dane

i sterujące są ustawione na tym samym stole, czy badany nosi szkła korekcyjne, ma alergie i czy w pomieszczeniu

występują inne źródła promieniowania podczerwonego. Kolejna sprawa to odpowiednia konfiguracja urządzenia

rejestrującego. Następnie należy zapewnić jak najbardziej komfortową pozycję dla osoby badanej, gdyż jej nadmierne

ruchy mogą zniekształcić wyniki testów. Ważną rzeczą jest również przeprowadzenie wstępnej kalibracji eye-trackera.

W artykule B. Wąsikowskiej [8] można znaleźć kolejną receptę na udane testy eye-trackingowe. Projektowanie

eksperymentu należy rozpocząć od ustalenia założeń badawczych i na ich podstawie stworzyć odpowiednie scenariusze testowe. Kolejny etap to okre lenie wielko ci próby i metod jej doboru. Autorka podkre la, że im bardziej homogeniczna jest wybrana grupa uczestników badania tym

bardziej szczegółowe wnioski będzie można sformułować. Dodatkowo zauważa, że wpływ na wyniki testów mogą mieć wady wzroku, a nawet zbyt duża ilo ć makijażu. Standardowa wersja oprogramowania eye-trackera umożliwia nagrywanie ruchu oczu, odtworzenia zarejestrowanego nagrania

z nałożonym ruchem oczu na prezentowanym bodźcu czy też analizę otrzymanych wyników w formie wizualnej

Powyższe informacje ukazały istotę badania eye-trackerem. Autorzy artykułu przygotowali badania

uwzględniając przy tym wyżej opisane aspekty co pozwoliło na otrzymanie bardziej rzetelnych wyników analizy.

3. Eye-tracking

Eye-tracking w języku polskim okulografii, rozumiany

jest jako zbiór technik badawczych służących do rejestracji, pomiaru i analizy danych o ruchu oka w okre lonych

przedziałach czasowych [9]. W uproszczeniu można stwierdzić, że eye-tracking umożliwia okre lenie cieżki skanowania oraz przedstawienie wizualne, na co w danym

momencie patrzył badany. Wyniki badań z wykorzystaniem

tej metody pozwalają stwierdzić, które elementy oprogramowania (w przypadku badań nad oprogramowaniem) przyciągają uwagę użytkowników, a które są całkowicie pomijane.

Obecnie działanie większo ci urządzeń rejestrujących ruch oczu opiera się na metodzie wykrywania położenia

źrenicy oraz odbicia na rogówce (ang. pupil and corneal


22

reflection). Pierwszym krokiem jest wykrycie położenia źrenicy przez kamerę o wysokiej rozdzielczo ci, następnie rogówka jest o wietlana niewidocznym dla człowieka wiatłem podczerwonym. wiatło to odbija się od

powierzchni oka tworząc w nich dobrze widzialne (przez kamerę) refleksy w zakresie wiatła podczerwonego, umożliwiające dokładne okre lenie punktu patrzenia. Urządzenia te okre lane są mianem eye-trackerów, inaczej

okulografów [10].

3.1. Metryki eye-trackingowe

Metryki eye-trackingowe są cennym zestawem narzędzi, które można wykorzystać do odkrywania zachowań i schematu my lenia użytkowników, korzystających z danego oprogramowania w różnych sytuacjach. Dodatkowo pozwalają na interpretację sposobu postrzegania poszczególnych elementów oprogramowania. Większo ć miar eye-trackingowych oparta jest o dwa podstawowe

rodzaje ruchów okaŚ fiksacje i sakady. Fiksacja to

koncentracja wzroku w jednym punkcie, za które uważa się stabilizację siatkówki oka na minimum 200 milisekund, podczas których mózg zaczyna przetwarzać informacje wizualne odbierane z oczu. Dzięki fiksacjom można jednoznacznie okre lić gdzie patrzy badana osoba. Sakady natomiast to gwałtowne przeniesienie wzroku z jednego

punktu skupienia na kolejny (sekwencje ruchu oka pomiędzy kolejnymi fiksacjami), które zajmują od 20 do 40 milisekund [10]. W oparciu o wyżej wymienione ruchy oczu możemy wyróżnić następujące metryki eye-trackingowe:

Czas do pierwszej fiksacji (ang. Time to first fixation)

[11] - czas od momentu pokazania bodźca do wykrycia pierwszej fiksacji. Pozwala na weryfikację, ile czasu potrzeba użytkownikowi na odnalezienie pożądanego bodźca z wyznaczonymi obszarami zainteresowań. Długi czas może wskazywać na nieodpowiednio

wyeksponowany obszar i trudno ć jego odnalezienia. Czas trwania fiksacji (ang. Fixation duration) [11] - czas

skupienia wzroku na danym bodźcu. Interpretacja tej miary może być różnaŚ pozytywna ponieważ użytkownik jest zainteresowany, a dany obszar jest dla niego

atrakcyjny, bądź też negatywna ponieważ wpatruje się bo nie może go zrozumieć. W celu pogłębienia analizy

stosuje się dodatkowe miary. Metryka ta jest bardzo ogólna, dlatego też najczę ciej stosuje się redni czas trwania fiksacji z danego zbioru. Liczba fiksacji (ang. Number of fixations) [10] - liczba

pojedynczych skupień wzroku. Ogólnie przyjmuje się, że im większa liczba fiksacji tym większa ilo ć elementów w danym obszarze skupiających uwagę respondentów. Z drugiej strony może być on bardziej skomplikowany

i wymaga od użytkownika zwiększonego my lenia. Całkowity czas obserwacji (ang. Total visit duration)

[10] - całkowity czas spędzony w danym obszarze

zainteresowania. Długie poruszanie wzroku w pewnym regionie wyraźnie wskazuje na wysoki poziom zainteresowania, a krótsze czasy wskazują, że inne obszary na ekranie lub w otoczeniu mogą być bardziej

interesujące. Powtarzalno ć fiksacji (ang. Repeat fixations) [11] - liczba

wizyt i ponownych odwiedzin danego obszaru

zainteresowania. Interpretacja tej miary również może być dwojakaŚ pozytywna, ponieważ może wiadczyć o dużym zainteresowaniem danym obszarem, bądź też negatywna poprzez błądzenie wzroku przy szukaniu pożądanych informacji. Procent respondentów, którzy zwrócili uwagę na dany obszar zainteresowania (ang. Percentage of participants

fixating in an area of interest) [11] - miarę tą można rozszerzyć do procentu osób, które dany obszar nie tylko zauważyli ale również i eksplorowali za co przyjmuje się wykonanie więcej niż jednej fiksacji. Liczba sakad (ang. Number of saccades) [12] - liczba

sekwencji ruchu oka pomiędzy kolejnymi fiksacjami. Im większa liczba sakad tym większe błądzenie wzroku oraz trudniejsze przeszukiwanie danego obszaru. Amplituda sakad (ang. Saccade amplitude) [12] -

odległo ć kątowa jaką pokonuje wzrok podczas swojego ruchu. Większa amplituda sakad wskazuje na większą odległo ć pomiędzy obszarami zainteresowań bądź też na przeszukiwanie pomiędzy ważniejszymi obszarami. Długo ć cieżki skanowania (ang. Scanpath length) [12] -

liczba następujących po sobie sakad i fiksacji. Im krótsza jest rzeczywista cieżka, tym lepiej realizowano zadanie

wyszukiwania. cieżka idealna to najmniejsza liczba prostych linii (sakad) pomiędzy elementami koniecznymi

do odnalezienia (fiksacji). Czas trwania cieżki skanowania (ang. Scanpath duration)

[12] - podobnie jak wyżej, im dłuższy czas cieżki skanowania tym słabsza efektywno ć zrealizowanego wyszukani.

3.2. Formy prezentacji wyników i sposoby analizy danych

cieżka skanowania (ang. Scanpath) wskazuje kolejno ć postrzegania poszczególnych elementów badanego obiektu, na które patrzy użytkownik podczas badania.

Kluczowymi składowymi tej miary są fiksacje oraz sakady. cieżka ta ma najczę ciej postać ponumerowanych kół, które

odpowiadają fiksacjom, połączonych ze sobą liniami, które odpowiadają sakadom. Im większa jest rednica koła tym dłużej trwała fiksacja tzn. użytkownik koncentrował w swój wzrok w danym punkcie podczas badania. Linie symbolizują ruch wzroku pomiędzy kolejnymi punktami, dodatkowo kolejno ć ta zaznaczona jest poprzez numery kół. Warto zauważyć, że w większo ci cieżka skanowania

pokrywa się ze cieżką wędrówki kursora po ekranie [10],

a miejsce koncentracji wzroku miejscu kliknięcia myszą. Taki sposób prezentacji pozwala stwierdzić, czy w badanym materiale została zachowana odpowiednia hierarchiczno ć i ulokowanie poszczególnych elementów.

Mapa cieplna (ang. Heat map) pozwala okre lić, które z obserwowanych elementów przyciągnęły uwagę użytkowników podczas badania przedstawiając sumaryczne wyniki skupienia uwagi wizualnej dla wybranej grupy

respondentów. Skupienie wzroku odwzorowane jest za

pomocą barw. W większo ci przypadków im barwa jest intensywniejsza i cieplejsza tym nastąpiło dłuższe skupienie wzroku użytkowników w danym obszarze natomiast w przypadku kolorów chłodniejszych skupienie to trwało znacznie krócej. Miejsca bez kolorów oznaczają pominięcie


23

danego obszaru, ale nie oznacza to jednak, że wzrok respondentów całkowicie nie podążał przez to miejsce, ponieważ mogło być go tam relatywnie tak mało, że nie został zaprezentowany graficznie. W ogólno ci mapa cieplna jest graficzną reprezentacją często ci występowania fiksacji wzroku użytkowników w badanym obszarze gdzie wagą dla poszczególnych punktów będzie długo ć lub liczba fiksacji

w danym punkcie [10].

Obszary zainteresowania (ang. Area of interest, AOI)

w ogólno ci pozwalają na wydzielenie z grupy spojrzeń tylko tych, które dotyczą wyodrębnionych obszarów prezentowanych na ekranie z procentowym zapisem rozkładu uwagi. Dodając do AOI odpowiednią metrykę, możemy przedstawić je w formie półprzeźroczystych warstw zawierających procentowy opis tego, w jakim stopniu

poszczególne elementy przykuwały uwagę, nałożonych na oglądany obraz. Obszary zainteresowań najczę ciej wskazuje się poprzez podanie współrzędnych narożników. Badacz może również samodzielnie zaprojektować AOI w kształcie prostokątnym, eliptycznym bądź wielokąta, bądź też wygenerować je automatycznie za pomocą dołączonego oprogramowania. Przewagą AOI w stosunku do map cieplnych jest możliwo ć uzyskania konkretnych warto ci liczbowych, które pozwalają na dokonanie dokładnej analizy ilo ciowej spojrzeń i stosowanie miar statystycznych (wykraczających poza miary statystyki opisowej). Przykładowo ocena koloru żółtego może być trudna do jednoznacznej interpretacji, natomiast wskazanie, że 60% respondentów zauważyło dany obszar jest jednoznaczne i nie

pozostawia wątpliwo ci [10].

4. Obiekt badawczy

Obiektem badań była responsywna aplikacja internetowa.

Aplikacja pozwala studentom na znalezienie i odbycie

praktyk, których wybór będzie możliwy spo ród tych ogłaszanych przez firmy. Pracodawca ma możliwo ć weryfikacji praktykanta w momencie rekrutacji, zmianę statusu praktyki i wystawienie oceny końcowej. Administrator, czyli osoba uprawniona do nadzoru praktyk

przez uczelnie posiada wgląd we wszystkie dane studenta oraz informacje związane z ich odbyciem. Aplikacja oferuje

funkcje dla niezarejestrowanych użytkowników, zarejestrowanych użytkowników, przedstawicieli firm biorących udział w projekcie oraz administratorom czuwającym nad pracą całej aplikacji.

Aplikacja została stworzona od podstaw z wykorzystaniem języka HTML, CSS, PHP, bazy danych

MySQL, biblioteki JavaScript, JQuery, Bootstrap, jej interfejs

jest prosty, zoptymalizowany, dopasowujący się do rozdzielczo ci ekranu. Umożliwia to bezproblemowe

korzystanie z serwisu na różnych urządzeniach końcowych. Na Rys. 1 oraz Rys. 2 został zaprezentowany widok strony głównej aplikacji, odpowiednio w wersji tradycyjnej oraz mobilnej.

Rys. 1. Widok strony głównej w wersji tradycyjnej

Rys. 2. Widok strony głównej w wersji mobilnej

5. Metodyka badawcza

Do ewaluacji responsywnej aplikacji internetowej

zarządzającej praktykami studenckimi wykorzystano

eye-tracker stacjonarny Tobii TX300. Podczas testów aplikacja była otwierana w przeglądarce Internet Explorer

w najnowszej dostępnej wersji 11. Wersja mobilna aplikacji została emulowana również za pomocą przeglądarki, ale w odpowiednio dobranych wymiarach okna co umożliwiło jej poprawne działanie, tak jak na urządzeniu mobilnym.

W badaniach wzięło udział dwana cie osób, zróżnicowanych pod względem wieku i statusu zatrudnienia. Najmłodsza osoba miała 20 lat natomiast najstarsza 50 lat.

rednia wieku wyniosła 26 lat, mediana 23 a odchylenie

standardowe 9,7. W głównej mierze byli to studenci ale także osoby pracujące oraz posiadające własną działalno cią


24

gospodarczą. Warto zaznaczyć, że żadna z badanych osób nie miała wcze niej żadnego kontaktu z badaną aplikacją internetową.

Przed przystąpieniem do badania uczestnicy byli proszeni

o wypełnienie krótkiej ankiety. Ankieta zawierała krótki opis aplikacji oraz badania a także czę ć metryczną.

Podczas testów, w pokoju z eye-trackerem przebywali:

moderator badań, obserwator zachowań użytkownika oraz badana osoba. Pierwszym etapem było zapoznanie użytkownika z zasadą działania eye-trackera oraz ideą przeprowadzanych badań. Kolejny etap to kalibracja sprzętu, polegająca na podążaniu wzrokiem po ekranie za przesuwającym się czerwonym punktem. Następnie każdy z badanych był proszony o wykonywanie poszczególnych zadań wg scenariusza. W ramach badań zostały stworzone dwa zestawy scenariuszy: pierwszy z perspektywy studenta

oraz drugi z perspektywy pracownika firmy. Każdy z użytkowników otrzymał oba zestawy scenariuszy do wykonania, z tą różnicą, że jeden wykonywany był na wersji mobilnej a drugi na wersji tradycyjnej. Zadania ze

scenariuszy dotyczyły m.in. rejestracji, logowania

i wylogowania z systemu, aplikację studenta na wybraną praktykę, dodanie nowego ogłoszenia praktyki do systemu

czy wystawienia oceny studentowi, który ukończył praktykę. Zestawy scenariuszy oraz ich kolejno ć była przydzielana całkowicie losowo. Z aspektów technicznych warto zaznaczyć, że tylko pierwsze zadanie zostało wy wietlone na ekranie eye-trackera, natomiast podczas badania zadania były czytane przez moderatora badań. Dodatkowo każdy z użytkowników miał cały czas wgląd do tre ci poszczególnych zadań. Ostatni etap badania to wypełnienie ankiety dotyczącej wykonywanych zadań, a także oceny testowanej aplikacji. Dla każdego scenariusza została stworzona oddzielna ankieta. Cało ć badań dla jednej osoby trwała około 25 minut.

6. Wyniki badań

6.1. Wystawienie oceny studentowi

Jednym z zadań wykonywanych przez użytkowników w ramach stworzonych scenariuszy było wystawienie dowolnej oceny studentowi, który ukończył praktykę. Jak się okazało zadanie to było jednym z bardziej problematycznych

w całym badaniu. Swoje problemy użytkownicy tłumaczyli przede wszystkim niewła ciwym doborem statusu praktyki

dla studenta, który ją ukończył, a którego można by było ocenić oraz również niewła ciwą nazwą etykiety dla przycisku zatwierdzającego wprowadzaną ocenę. Na Rys. 3

został zaprezentowany rozkład uwagi siedmiu użytkowników podczas wystawiania oceny studentowi.

Rys. 3. Mapa cieplna prezentująca rozkład uwagi wizualnej użytkowników podczas wystawiania oceny studentowi w wersji tradycyjnej aplikacji

Studenci oczekujący na wystawienie oceny umieszczeni

byli na samej górze listy. Wykres mapy cieplnej ukazuje, że największą uwagę przykuł obszar z polem oceny u pierwszego studenta na li cie. Samo puste pole z oceną nie przyczyniło się jednak do szybkiego wykonania zadania. Dodatkowo wykres pokazuję, że duża czę ć uwagi skupiona była również na kolumnie ze statusem praktyki studenta co potwierdza głębszą analizę badanych komu takową ocenę mogą wystawić. Warto zauważyć, że praktycznie nikt nie analizował kolumny z terminem praktyk co przy porównaniu z aktualną datą mogłoby dać wskazówkę kto praktykę ukończył a kto jest jeszcze w trakcie jej odbywania.

W wersji mobilnej aplikacji problem z okre leniem który student podlega ocenie również wystąpił. Nie było jednak problemu z nazwą etykiety dla przycisku potwierdzającego wprowadzenie oceny. Na Rys. 4 został zaprezentowany rozkład uwagi pięciu użytkowników podczas wystawiania oceny studentowi.

Najwięcej uwagi uczestnicy zwrócili na dane pierwszego studenta na li cie. Mała liczba fiksacji dla danych studentów na dalszych pozycjach na li cie wiadczy o małym zainteresowaniu użytkowników. Na mapie cieplnej można zauważyć trzy wyraźnie skupienia wzroku w okolicach pola

z filtrami i nazwy studenta, pola ze statusem oraz pola

z oceną i przyciskiem „Akceptuj”. Obserwacje te potwierdzają analizowanie przez badanych czy dany student kwalifikuje się do wystawienia oceny za odbycie praktyki.

redni czas wystawienia oceny studentowi, dla wersji tradycyjnej aplikacji wyniósł 70 sekund, a dla wersji mobilnej

30 sekund. Użytkownicy podczas wykonywanego zadania popełnili łącznie 10 błędów, za które uznane było zboczenie z prawidłowej cieżki poruszania do wła ciwej podstrony, 8 wersji tradycyjnej oraz 2 w wersji mobilnej aplikacji.


25

Rys. 4. Rozkład uwagi wizualnej użytkowników podczas zadania wystawienia oceny studentowi w formie mapy cieplnej i cieżki skanowania-

wersja mobilna aplikacji

6.2. Pozostałe scenariusze zadań

Ze względu na dużą ilo ć otrzymanych wyników badań

i ich obszerną tre ć, wnioski dotyczące pozostałych zadań są ogólne.

Pierwszym zadaniem dla studenta była rejestracja w systemie. Proces ten przebiegł bardzo sprawnie. Jedyny problem jaki wystąpił, został spowodowany początkowym zawahaniem użytkowników, jakie dane muszą umie cić w formularzu rejestracyjnym (informacja ta była zawarta w tre ci zadania, jednak w większo ci przypadków nie została zauważona). Kolejne zadanie to logowanie do systemu. Proces ten również nie sprawił żadnych problemów użytkownikom, w scenariuszu dla firmy również. Pierwsze

problemy pojawiły się przy zadaniu z wy wietleniem informacji o swoim profilu. Zostały one spowodowane nieodpowiednim doborem nazwy etykiety wła ciwego odno nika do danej podstrony z informacjami. Aplikacja na wybraną praktykę z kierunku informatyka również przebiegła bardzo sprawnie. Przy tym zadaniu jednak można zauważyć było brak analizy od użytkowników wybranej oferty praktyki, co poniekąd mogło być spowodowane nieodpowiednim sformułowaniem tre ci zadania. W przypadku sprawdzania statusu aplikacji na praktykę w wersji mobilnej aplikacji nie wszyscy użytkownicy za pierwszym razem odnaleźli wła ciwą informację. Swoje problemy tłumaczyli brakiem stosownej etykiety przy polu z wła ciwą warto cią. Użytkownicy wcieleni w rolę pracownika firmy, podczas

dodawania nowego ogłoszenia o praktykę również nie mieli większych trudno ci w prawidłowym wykonaniu zadania. Kluczowym elementem podczas przyjmowania aplikacji

studenta na daną praktykę okazało się odnalezienie wła ciwej podstrony z dostępnymi aplikacjami. Trzech na pięciu użytkowników potrzebowało trochę więcej czasu na wykonanie tego zadania. Ostatnie wykonywane zadania tj.

podgląd profilu studenta jak również proces wylogowania z systemu po raz kolejny nie sprawiły żadnych problemów. W tym przypadku warto jednak zwrócić uwagę na

zdecydowanie większą analizę profilu studenta przez użytkowników w porównaniu do zadania, gdzie użytkownicy wybierali interesujące ich ogłoszenie o praktyce.

6.3. Podsumowania badań

Z punktu widzenia studenta aplikacja została zaprojektowana bez większych zastrzeżeń. W tabeli 1 zostały pokazane wyniki przeprowadzonej ankiety na temat

poszczególnych zadań ze scenariusza. Według odczuć ankietowanych najprostsze okazały się być zadania związane z rejestracją, logowaniem, sprawdzeniem statusu zgłoszenia i aplikacją na praktykę. Tylko dwóch użytkowników neutralnie oceniło proces wylogowania. Stosunkowo najtrudniejsze okazało się być zadanie związane wy wietleniem informacji o swoim profilu co potwierdziły wcze niejsze wyniki badania eye-trackingowego.

Tabela 1. Ocena trudno ci zadań wykonywanych w scenariuszu studenta-

wyniki ankietowe

Cało ciowy czas zadań wykonywanych w ramach jednego scenariusza z punktu widzenia studenta trwał rednio 162 sekundy dla wersji tradycyjnej oraz 156 sekund dla

wersji mobilnej. W tym czasie użytkownicy popełnili łącznie 24 błędy, 7 w wersji tradycyjnej oraz 17 w wersji mobilnej aplikacji.

Podsumowując przeprowadzone testy z punktu widzenia pracownika firmy, w niektórych przypadkach aplikacja nie

została zaprojektowana dostatecznie dobrze. W tabeli 2

zostały pokazane wyniki przeprowadzonej ankiety na temat poszczególnych zadań ze scenariusza. Według odczuć ankietowanych najprostsze okazały się być zadania związane z logowaniem, dodaniem nowego ogłoszenia o praktykę, przyjęciem studenta oraz wylogowaniem. Zdecydowanie najwięcej problemów przysporzyło zadanie z wystawieniem

oceny studentowi i po czę ci zadanie z wy wietleniem informacji o wybranym studencie co potwierdziły

wcze niejsze wyniki badania eye-trackingowego.


26

Tabela 2. Ocena trudno ci zadań wykonywanych w scenariuszu pracownika firmy- wyniki ankietowe

Cało ciowy czas zadań wykonywanych w ramach jednego scenariusza z punktu widzenia studenta trwał rednio 225 sekund dla wersji tradycyjnej oraz 174 sekundy dla

wersji mobilnej. W tym czasie użytkownicy popełnili łącznie 32 błędy, 23 w wersji tradycyjnej oraz 9 w wersji mobilnej

aplikacji.

W tabeli 3 oraz 4 zostały zaprezentowane statystyki przeprowadzonych testów. Umieszczone są tam rednie warto ci czasu, kliknięć, popełnionych błędów oraz odwiedzonych podstron w ramach poszczególnych zadań w obydwu zestawach scenariuszy. Tabele uwzględniają również podział na wersje mobilną i tradycyjna aplikacji. Tabela 3. Statystyki testów dla zestawu dla studenta

Tabela 4. Statystyki testów dla zestawu dla firmy

W zestawie dla studenta najdłużej wykonywanym zadaniem był proces rejestracji, zarówno dla wersji mobilnej jak i tradycyjnej aplikacji. Rejestracja wygenerowała również największą liczbę kliknięć. W procesie logowanie nie

zaobserwowano błędów użytkownika. Najsprawniej

wykonanym zadaniem był proces wylogowania z systemu,

dla wersji tradycyjne trwał rednio tylko 1,67 sekund a dla wersji mobilnej 9,3 sekundy. W scenariuszu zadań dla firmy

badani najdłużej wykonywali zadanie dodania nowego

ogłoszenia o praktykę. Również ten proces wygenerował największą liczbę kliknięć w obu wersjach aplikacji. Spowodowane to było prawdopodobnie konieczno cią wypełniania dużej ilo ci pól formularza. Brak błędów zaobserwowano podczas dodawania nowego ogłoszenia jak również sprawdzania informacji o praktykancie. Podobnie jak w zestawie dla studenta najsprawniej wykonanym zadaniem

był proces wylogowania. Trwał rednio 3,86 sekund dla wersji tradycyjnej oraz 7 sekund dla wersji mobilnej aplikacji

W tabeli 5 zostały zaprezentowane wyniki przeprowadzonej ankiety na temat całokształtu stworzonej

aplikacji.

Tabela 5. Ocena całokształtu stworzonej aplikacji internetowej- wyniki ankietowe

W ogólno ci aplikacja została oceniona bardzo pozytywnie. Wszyscy ankietowani uznali, że jest prosta w obsłudze. Możliwo ć intuicyjnego poruszania się po stronie została negatywnie oceniona tylko przez jeden oddany głos. Przejrzysto ć interfejsu i rozkład głównego menu również wywarł pozytywne wrażenie. Elementy te uzyskały tylko po jednym neutralnym głosie. Wygląd formularzy, przycisków czy innych elementów interakcyjnych otrzymał dwa neutralne głosy i jeden negatywny czyli został oceniony stosunkowo

najgorzej. Za najmocniejszą stronę aplikacji 80% użytkowników uznało jej prosty wygląd i tzw. „lekko ć” a pozostali uznali to za wadę i dodaliby więcej elementów graficznych, wzbogacając tym samym wygląd aplikacji. Jako słabe strony zostawały przytaczane elementy omówione wcze niej, tj.: organizacja rozwijanego menu pod nazwą użytkownika, brak odpowiednich statusów dla studentów, którzy czekają na wystawienie oceny.

Jako główną zmianę większo ć badanych zaproponowało reorganizacje rozwijanego menu zarządzania kontem użytkownika w tradycyjnej wersji aplikacji. W efekcie końcowym rozwijane menu zostało usunięte, na pasku menu pozostała jedynie etykieta z nazwą użytkownika będąca jednocze nie linkiem do szczegółowych danych oraz przycisk „Wyloguj”. Wprowadzone zmiany zostały zaprezentowane na Rys.5.

Kolejna zmiana związana była z brakiem zainteresowania ze strony użytkowników filtrami do praktyk według wydziałów oraz interaktywną wyszukiwarką (prawdopodobnie było to spowodowane danym uszeregowaniem ogłoszeń na li cie). Etykieta filtrów „Praktyki dla wydziałów” została zmieniona na „Pokaż praktyki dla wydziałów. W przypadku przebywania

użytkownika na podstronie z ogłoszeniami podpowiedź dla wyszukiwarki została zmieniona z „Szukaj” na „Szukaj praktyki”. Następna zmiana odnosiła się do aplikacji mobilnej i statusu zgłoszenia. Na odpowiedniej podstronie do warto ci statusu zgłoszenia została dodana etykieta „Status” w celu sprecyzowania znaczenia danej warto ci. Wprowadzone zmiany zostały zaprezentowane na Rys.6.


27

Rys. 5. Zmiany menu zarządzania profilem użytkownika

Rys. 6. Zmiany statusu zgłoszenia

Ostatnie już rekomendacje zmian dotyczyły procesu

wystawiania oceny studentowi za odbytą praktykę. W aplikacji został dodany nowy status „Czeka na wystawienie oceny”, który dotyczy studentów, którzy ukończyli swoje praktyki i czekają na uzyskanie oceny. Dodatkowo nastąpiła zmiana nazwy przycisku do

wystawiania ocen, gdy pole z oceną będzie puste etykieta będzie miała warto ć „Wystaw ocenę” a w innym przypadku

pozostanie bez zmian.

7. Wnioski

Przeprowadzone badania dowiodły tezy, że sukcesem współczesnej witryny internetowej jest jej prostota

i czytelno ć. Stosowanie nowoczesnych technik czy znajomo ć różnorodnych frameworków jest oczywi cie

cennym i pożądanym atutem, ale nie jest konieczne by móc stworzyć stronę zawierającą powyższe atuty. Istotą dla projektantów witryn internetowych jest odpowiednie

dopasowanie produktu do oczekiwań użytkowników. Badania wykazały, że przy przeglądaniu strony liczy się przede wszystkim wła ciwa tre ć strony oraz przejrzysty interfejs graficzny. Użytkownicy cenią również możliwo ć intuicyjnego poruszania się według ogólno-przyjętych standardów co nie powoduje konieczno ci uczenia się od nowa, a tylko zaoszczędza ich czas.

Literatura

[1] Tim Berners-Lee. Weaviin the Web. Harper 1999.

[2] Nielsen J .Ten Usability Heuristics. ACM New York USA

1994.

[3] Krzos Paweł. ledzenie cieżki wzroku w ocenie użyteczno ci oprogramowania. Politechnika Wrocławska, MWSE 2016.

[4] William Albert, Thomas Tullis. Measuring the User Experience

2nd Edition. Published by Elsevier Inc. USA 2013.

[5] Kopy ć Paweł. Wybrane metody oceny użyteczno ci stron i aplikacji internetowych. Kraina Biznesu Kraków 2014.

[6] Jakob Nielsen. Designed Web Usability: The Practice of

Simplicity. New Riders USA 1999.

[7] Nielsen Jakob and Kara Pernice. Eyetracking Web Usability.

New Riders Publishing Thousand Oaks, CA, USA 2009.

[8] Wąsikowska Barbara. Eyetracking w badaniach marketingowych. Zeszyty naukowe Uniwersytetu

Szczecińskiego, 2015

[9] Eyetracking Solutions and Research: eyetracking.pl.

[29.08.2017]

[10] Garczarek-Bąk Urszula. Użyteczno ć badań eye-trackingowych

w pomiarze utajonych determinant zachowań zakupowych nabywców. Uniwersytet Ekonomiczny w Poznaniu 2016.

[11] Robert J. K. Jacob and Keith S. Karn. Eye Tracking in Human–Computer Interaction and Usability Research: Ready to Deliver

the Promises. 2003.

[12] Grobelny, J., Jach, K., Kuliński, M., & Michalski, R. ledzenie wzroku w badaniach jako ci użytkowej oprogramowania . Historia i mierniki. Unpublished paper presented at Interfejs

użytkownika - Kansei w praktyce Conference, Warszawa 2006.

JCSI 6 (2018) 28-33



28

Porównanie wydajno ci szkieletów aplikacji mobilnych umożliwiających programowanie z wykorzystaniem technologii internetowych

Marcin Martyna* , Jakub Smołka


Streszczenie. Na przestrzeni ostatnich lat powstało wiele szkieletów aplikacji pozwalających na programowanie aplikacji mobilnych. Czę ć z nich bazuje na językach programowania typowych dla tworzenia aplikacji internetowych, takich jak HTML czy JavaScript. W artykule

zawarte jest porównanie trzech takich wieloplatformowych rodowisk programistycznych jakimi są PhoneGap, NativeScript oraz

Appcelerator. W każdym z tych rodowisk powstała aplikacja o identycznych funkcjonalno ciach przeznaczona na system Android.

Zaimplementowane testy pozwoliły sprawdzić która z aplikacji jest najwydajniejsza pod względem czasu jakiego potrzebuje na wykonanie

poszczególnych funkcji. Przedstawiono zestawienie i analizę otrzymanych wyników.

Słowa kluczowe: porównanie szkieletów aplikacji; Android; mobilna aplikacja; testowanie aplikacji



Efficiency comparison of mobile application frameworks for programming using

internet technologies

Marcin Martyna*, Jakub Smołka Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. Over the last few years many frameworks allowing programming mobile applications have been created. Some of them are based on

programming languages typical for internet application programming - HTML or JavaScript for example. This paper presents a comparison of

three cross-platform environments: PhoneGap, NativeScript and Appcelerator. Using each of these environments an application with identical

functionalities was created. The application was designed for Android operating system. Implemented tests allowed for determining which one

of the application framework is the most efficient with respect to the time needed for executing respective functions. Obtained results are shown

and analyzed.

Keywords: framework comparison; Android; mobile application; application testing



1. Wstęp

W wiecie gdzie prawie każdy jest użytkownikiem smartfona firmy je produkujące stają przed nie lada wyzwaniem, wyzwaniem o to by to wła nie produkt danej firmy znalazł się na sklepowej półce a następnie trafił do rąk nowego wła ciciela. W ten sposób firmy konkurują ze sobą tworząc coraz to nowsze, lepsze urządzenia. Smartfony na

rynku pojawiły się około dziesięć lat temu i od tamtego czasu systematycznie podbijają serca coraz to nowych użytkowników [1]. Z danych na rok 2016 wynika że na wiecie jest 2.1 miliarda tych urządzeń prognoza na obecny

rok mówi że będzie ich 2.32 miliarda [2]. Kolejne prognozy wskazują ciągły wzrost tej tendencji [2].

Wraz ze wzrostem mocy obliczeniowych tych urządzeń wzrosły oczekiwania konsumentów odno nie aplikacji tworzonych na nie. To wła nie dzięki temu postępowi programi ci piszący aplikacje na te urządzenia mają coraz to większe możliwo ci. Artykuł po więcony jest możliwo ciom jakie stoją przed programistami, którzy zdecydują się na pisanie aplikacji mobilnych przy pomocy JavaScript czy

HTML w szkieletach aplikacji jakimi są PhoneGap, NativeScript czy Appcelerator.


Przeglądu literatury dokonano na podstawie dostępnych pozycjach w bazach Scopus, Springer, ScienceDirect oraz

BazTech. Pozycje których tematyka stanowiła wsparcie tematu pracy zostały opisane poniżej.

Artykuły [3], [4], [5] stanowiły wprowadzenie do

badanych frameworków. Znajdowały się w nich praktyczne przykłady użycia fragmentów kodu źródłowego oraz instrukcje odno nie interfejsów graficznych poszczególnych frameworków. W artykułach [6], [7], [8] zawarte zostały porównania dotyczące aplikacji tworzonych natywnie oraz

tych tworzonych w frameworkach wieloplatformowych.

Natomiast artykuły [9], [10], [11] opisują sposoby testowania aplikacji na konkretnych przykładach.

3. Cel badań

Celem badań było porównanie wydajno ci frameworków pozwalających na tworzenie mobilnych aplikacji na system Android przy pomocy takich języków programowania jak HTML i JavaScript. Badania mają za zadnie sprawdzić, który ze szkieletów aplikacji radzi sobie najlepiej z poszczególnymi aspektami, tak by osoby poszukujące wieloplatformowego


29

rodowiska programistyczne miały zarys możliwo ci oraz wydajno ci porównywanych framework’ów.

4. Szkielety aplikacji

Szkielet aplikacji lub platforma programistyczna (ang.

framework) narzędzie, które dostarcza programi cie gotowych bibliotek czy komponentów. Znacznie ułatwia pracę i skraca czas jaki programista musi po więcić nad aplikacją by ją ukończyć. Ponadto istnieją także wieloplatformowe szkielety

aplikacji tzw. cross-platform frameworks, które pozwalają na pisanie aplikacji na różne platformy jak np. Android i iOS jednocze nie. Obecnie na rynku istnieje szkielet aplikacji dla

prawie każdego popularnego języka programowania. Chcąc napisać aplikację z natywnymi funkcjami na system Android

czy iOS programista musi znać dwa różne języki programowania oraz napisać oddzielny kod dla każdej z aplikacji, natomiast w przypadku szkieletów aplikacji wieloplatformowych wystarczy jeden język, w którym napisany kod jest odpowiednio przystosowywany do danej

platformy. Najczę ciej dzieje się to w taki sposób, że do kodu źródłowego dodawane są odpowiednie wtyczki zawarte w narzędziu przystosowujące aplikację do danego systemu mobilnego. Dla Javy najpopularniejszymi szkieletami

aplikacji są Spring MVC, Struts 2 czy Hibernate, a dla

JavaScript to Angular, ReactJS czy Vue.js, ale to tylko

wierzchołek góry lodowej [12,13]. Narzędzia te z uwagi na coraz to większe potrzeby programistów czy silną konkurencję na rynku są nieustannie ulepszane.

5. Użyte technolgie

W celu przeprowadzenia odpowiednich testów a następnie porównania poszczególnych szkieletów aplikacji niezbędne było wykorzystanie technologii opisanych

w kolejnych podpunktach.

5.1. System Android

Jako że docelową platformą aplikacji tworzonych w celach porównawczych jest Android warto wspomnieć o nim kilka słów. W 2005 roku mała firma o nazwie „Android Inc” została kupiona przez znanego na całym wiecie giganta branży internetowej „Google”, był to początek drogi do

stworzenia systemu Android oraz do wej cia firmy Google na

rynek urządzeń mobilnych. Kolejnym przełomowym wydarzeniem było wydanie pierwszej wersji tego systemu 21 października 2008 roku, od tamtego dnia Android

systematycznie znajdował coraz to nowych konsumentów powoli zdobywając rynek systemów obsługujących urządzenia mobilne [14]. Obecnie open sourceowy Android

jest najpopularniejszym systemem mobilnym, prawie 72% na

rynku systemów urządzeń mobilnych z pewno cią można nazwać miażdżącą przewagą nad konkurencją, drugi na rynku

iOS posiada jedynie 18,89% rynku [15]. Należy pamiętać że na przestrzeni lat system ten był nieustannie ulepszany do

obecnie znajdującej się na rynku wersji 8.0 zwanej także Oreo.

5.2. NativeScript

Open sourceowy NativeScript jest wieloplatformowym

frameworkiem pozwalającym na tworzenie hybrydowych

[16] aplikacji mobilnych na urządzenia bazujące na systemach Android i iOS. Należący do bułgarskiej firmy „Telerik” udostępniony został w marcu 2015 roku i nieustanie

rozwijany od tamtego czasu. Obecnie dostępny jest w stabilnej wersji 3.0 wydanej w maju 2017 roku. Oparty na

licencji Apache 2.0, NativeScript pozwala na tworzenie

aplikacji używając zarówno JavaScript jak i TypeScript [17].

Framework ten bezpo rednio wspiera AngularJS aczkolwiek

korzystanie z niego nie jest obowiązkowe, użytkownik ma możliwo ć swobodnego wyboru rodowiska programistycznego.

5.3. Appcelerator

Kolejny framework, Titanium Appcelerator to następne wieloplatformowe rodowisko programistyczne dostępne dla

każdego użytkownika. Choć pojawił się już w grudniu 2008 roku to dopiero w czerwcu 2009 roku i w 2012 roku wyszło

wsparcie do takich platform jak Android czy iOS.

Appcelerator pozwala nam na tworzenie aplikacji na

wcze niej wymienione platformy używając jednego kodu

bazowego. W przypadku Appceleratora jedynym dostępnym

językiem programowania jest JavaScript. Kolejną wspólną cechą tych rodowisk jest licencja (Apache 2.0).

W przypadku Appceleratora użytkownik do dyspozycji ma

oddzielne rodowisko, w którym ma możliwo ć edytowania kodu źródłowego. W Appceleratorże istnieje także możliwo ć zakupienia wersji rozszerzonej dającej dodatkowe możliwo ci np. czat i wsparcie email, współpraca z innymi twórcami czy

dostęp do usługi RMAD (ang. Rapid Moblie App

Development) [18], to tylko czę ć możliwo ci jakie twórcy przygotowali swoim klientom więcej informacji można znaleźć na stronie producenta [19].

5.4. PhoneGap

Należący do fundacji Apache (pełna nazwa Apache Software Fundation) PhoneGap jest wieloplatformowym

szkieletem aplikacji bazującym na licencji Apache 2.0.

PhoneGap nie różni się od wcze niej wymienionych programów pod względem języków jakie są używane do tworzenia aplikacji, tak jak poprzednicy bazując na jednym kodzie można stworzyć aplikacje na Androida i iOSa

jednocze nie. Szukając informacji na temat tego rodowiska można natknąć się na pewne nie cisło ci, otóż PhoneGap

stworzony został przez firmę Nitobi, która w 2011 roku

została kupiona przez Adobe Systems. Następnie kod źródłowy PhoneGap został przekazany obecnemu

wła cicielowi, aczkolwiek by mogło to się odbyć firma Adobe musiała zmienić nazwę produktu z uwagi na ochronę własno ci intelektualnej [20]. Apache Callback taka była pierwsza propozycja nowej nazwy, niestety nie przyjęła ona się zbyt dobrze i społeczno ć szybko ją zmieniła. Obecnie

formalna nazwa tego frameworka to Apache Cordova -

Cordova od nazwy ulicy na jakiej znajdowała się siedziba firmy Nitobi w Vancouver [20]. Według autora [20] pomimo


30

różnych nazw, które są jedyną różnicą jest to wciąż ten sam

framework i nie prędko to się zmieni.

5.5. Urządzenie testowe

Testy przeprowadzone zostały na urządzeniu Asus ZenFone 2 ZE551ML o następujących parametrachŚ

Rys 1. Parametry urządzenia na którym odbyły się testy [21]

Więcej informacji na temat danego urządzenia można znaleźć na stronie producenta [21].


W każdym ze rodowisk wykonano aplikację implementującą ten sam zestaw testów. W każdym z testów umieszczono funkcje mierzące czas wykonania się danego testu. Funkcja swreset() odpowiada za reset warto ci pomiaru, reset ten następuje za każdym razem gdy dany test jest

uruchamiany. Funkcja startstop() rozpoczyna pomiar czasu

a display() podaje warto ć w jakim test się wykonał.

Przykład 1. Ukazanie metod odpowiedzialnych za pomiar czasu na przykładzie pobierania lokalizacji GPS w framework’u PhoneGap

var Latitude = undefined; var Longitude = undefined; function getMapLocation() { swreset(); startstop(); navigator.geolocation.getCurrentPosition(onMapSuccess, onMapError, {enableHighAccuracy: true}); } function onMapSuccess(position) { Latitude = position.coords.latitude; Longitude = position.coords.longitude; document.stpw.output.value = "Lokalizacja " + Latitude + " " + Longitude; display();

} function onMapError(error) {

document.stpw.output.value = "Odczytanie lokalizacji nie powiodło się"; }

Podczas opracowywania testów wzorowano się na pracy

[22]. Oto spis wszystkich testów:

1) Generowanie 100 000 liczb z przedziału [0-9]

2) Pobieranie listy kontaktów

3) Sortowanie listy 10 000 elementów

4) Zapis dużego pliku

5) Wielokrotny zapis małego pliku

6) Wielokrotny odczyt małego pliku

7) Odczyt dużego pliku

8) Odczyt bieżącej pozycji urządzenia poprzez GPS

9) Konwersja obrazu do odcieni szaro ci 10) Odtworzenie pliku audio o długo ci 1s

Każda z powyższych funkcji została przetestowana trzykrotnie, raz w każdej z aplikacji wykonanych w różnych frameworkach. Wszystkie testy odbyły się na jednym urządzeniu a w tle nie było uruchomionych żadnych innych aplikacji. Miało to na celu nie dopuszczenie do sytuacji gdzie dane funkcje miały by lepszy czas jedynie ze względu na to, że w tle działały inne aplikacje spowalniające czas wykonania poszczególnych testów. Funkcje badano pod względem czasu jakiego potrzebują na wykonanie, a następnie wyniki zestawiono w tabeli. Rezultaty z tabel posłużyły do stworzenia wykresów przedstawiających minimalne, rednie oraz maksymalne czasy pomiarów poszczególnych frameworków. Należy zaznaczyć, że w przypadku Appceleratora nie udało się zaimplementować testu konwersji obrazu do odcieni szaro ci.

7. Wyniki badań

Do każdego z testów wykonano dwadzie cia pomiarów.

Wyniki umieszczono w tabeli, a następnie na ich podstawie stworzone zostały wykresy znajdujące się na rysunkach 2-11.

Min oznacza minimalny czas po ród wszystkich wyników w jakim test został wykonany. rednia stanowi rednią obliczoną ze wszystkich pomiarów danego narzędzia. Max

jest czasem najdłuższym w jakim zadanie zostało wykonane. Warto ci liczbowe na osi poziomej każdego z wykresów oznaczają czas w milisekundach.

Rys 2. Wyniki testu generowania 100 000 liczb z przedziału (0;9)


31

Rys 3. Wyniki testu pobierania kontaktów z urządzenia

Rys 4. Wyniki testu sortowania tablicy 10 000 elementów

Rys 5. Wyniki testu odczytu z dużego pliku

Rys 6. Wyniki testu wielokrotnego odczytu małego pliku

Rys 7. Wyniki testu zapisu dużego pliku

Rys 8. Wyniki testu wielokrotnego zapisu małego pliku

Rys 9. Wyniki testu odtwarzania pliku audio

Rys 10. Wyniki testu konwersji obrazu do odcieni szaro ci

Rys 11. Wyniki testu pobierania lokalizacji z GPS


32

8. Wnioski

Na podstawie danych zebranych z pomiarów i zestawionych na rysunkach 2-11 oraz w tabeli 1, można zauważyć znaczną przewagę Appceleratora nad pozostałymi frameworkami.

Tabela 1. Porównanie badanych frameworków

Kryterium

porównawcze Appcelerator PhoneGap NativeScript

Czas budowy

aplikacji 1min 16s

3min 28s

7s przy

uruchamianiu w

przeglądarce

1min 35s przy

pierwszym

uruchomieniu

oraz po

dodaniu

wtyczki.

25s w

następnych uruchomieniac

h

Sposób budowy

aplikacji

W rodowisku,

aplikacja jest

tworzona

bezpo rednio na

urządzenie lub emulator

Na stronie

producenta,

aplikacja jest

możliwa do pobrania poprzez

zeskanowanie kodu

QR po zbudowaniu

projektu.

Możliwo ć uruchomienia

aplikacji w

przeglądarce jednak nie wspiera

to natywnych

funkcji

W wierszu

poleceń poprzez

wykonanie

polecenia „tns run android” wcze niej przechodząc do lokalizacji

projektu za

pomocą polecenia „cd”

Zintegrowane

rodowisko graficzne

Tak Tak Nie

Licencja Apache 2.0 Apache 2.0 Apache 2.0

Obsługiwane języki programowania

JavaScript JavaScript oraz

HTML

JavaScript oraz

TypeScript

Plik na bazie

którego budowany jest

interfejs

graficzny

XML HTML XML

Wtyczki

Do pobrania na

stronie

producenta

Do pobrania na

stronie producenta

Do pobrania na

stronie

producenta

Sposób dodania

wtyczki w

projekcie

Skopiowanie

pliku zip z

wtyczką do projektu a

następnie dodanie modułu w pliku tiapp.xml

Odniesienie się poprzez „<script type="text/javascri

pt" src=lokalizacja

wtyczki"></script>

” w pliku html

Dodanie w

wierszu

poleceń za pomocą polecenia „tns plugin add

nazwa

wtyczki”

W 7 na 10 testów narzędzie to okazało się najwydajniejsze osiągając wyniki nawet kilku czy

kilkunastokrotnie lepsze od konkurentów. Na podstawnie dokonanych pomiarów oraz danych z rysunków 2-11 wynika

że Appcelerator jest szybszy od drugiego pod względem wydajno ci PhoneGap o 267%. Wynik uzyskano poprzez porównanie zsumowanych ze sobą rednich warto ci każdego

rodowiska ze wszystkich testów z wyjątkiem konwersji obrazu do odcieni szaro ci. W porównaniu z NativeScript, Appcelerator jest o 359% szybszy. Tak znaczne różnice wynikają głównie ze znacznych różnic w czasach pomiarów w testach, takich jak odczyt lokalizacji z GPS czy pobranie

kontaktów. Drugim pod względem wydajno ci jest framework PhoneGap który od najgorszego NativeScript jest o 36% bardziej wydajny. Przy obliczaniu tego wyniku

uwzględnione zostały rednie czasy w te cie konwersji

obrazu do odcieni szaro ci.

Literatura

[1] Podróż w czasieŚ Era G1, czyli pierwszy smartfon z Androidem o wielu imionach, http://komorkomania.pl/2465,podroz-w-

czasie-htc-dream-era-g1 [01.06.2017]

[2] Number of smartphone users worldwide from 2014 to 2020 (in

billions, https://www.statista.com/statistics/330695/number-of-

smartphone-users-worldwide/ [26.05.2017]

[3] Sarah Allen, Vidal Graupera, Lee Lundrigan: PhoneGap

[4] S. Hanschke, H. Heitkötter, T. A. Majchrzak: Evaluating Cross-

Platform Development Approaches for Mobile Applications.

[5] S. Allen, V. Graupera, L. Lundrigan: Titanium Mobile.

[6] Wenliang Du, Xing Jin, Tongbo Luo, Lusha Wang: Fine-

Grained Access Control for HTML5-Based Mobile

Applications in Android.

[7] Euler Horta Marinho, Rodolfo Ferreira Resende: Native and

Multiple Targeted Mobile Applications.

[8] Antonio Cicchetti, Manuel Palmieri, Inderjeet Singh:

Comparison of cross-platform mobile development tools.

[9] B. Dookheea, V. Hurbungs, Y. K. Suttroogun: A Framework to

Reduce the Testing Time of a Mobile Application Using an

Automation Tool.

[10] Marcelo Medeiros Eler, Andre Takeshi Endo, Davi Bernardo

Silva,: An analysis of automated tests for mobile Android

applications.

[11] Henning Heitkötter ,Tim A. Majchrzak, Benjamin Ruland,

Till Weber: Comparison of Mobile Web Frameworks.

[12] 7 Best Java Frameworks for 2016

https://www.romexsoft.com/blog/7-best-java-frameworks-for-

2016/ [01.06.2017]

[13] 5 Best JavaScript Frameworks in 2017 https://hackernoon.com/5-

best-javascript-frameworks-in-2017-7a63b3870282.

[14] A complete history of Android

http://www.techradar.com/news/phone-and-

communications/mobile-phones/a-complete-history-of-android-

470327/3 [01.06.2017]

[15] Mobile operating systems' market share worldwide from

January 2012 to December 2016

https://www.statista.com/statistics/272698/global-market-share-

held-by-mobile-operating-systems-since-2009/ [01.06.2017]

[16] Aplikacja mobilna – Hybryda czy Natywna? Różnice

https://www.gmi.pl/blog/aplikacja-mobilna-hybryda-natywna/

[17] Strona producenta TypeScript https://www.typescriptlang.org/

[14.08.2017]

[18] Rapid mobile app development (RMAD)

http://whatis.techtarget.com/definition/rapid-mobile-app-

development-RMADrapid [02.06.2017]

[19] PhoneGap, Cordova, and what’s in a name?

http://phonegap.com/blog/2012/03/19/phonegap-cordova-and-

whate28099s-in-a-name/ [02.06.2017]

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Antonio%20Cicchetti.QT.&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Manuel%20Palmieri.QT.&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Inderjeet%20Singh.QT.&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Marcelo%20Medeiros%20Eler.QT.&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Andre%20Takeshi%20Endo.QT.&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Davi%20Bernardo%20Silva.QT.&newsearch=true

http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin=%22Authors%22:.QT.Davi%20Bernardo%20Silva.QT.&newsearch=true


33

[20] Asus ZenFone ZE551ML

https://www.asus.com/pl/Phone/ZenFone_2_ZE551ML/

[03.06.2017]

[21] Strona producenta Appcelerator zakładka cnnik

https://www.appcelerator.com/pricing/ [6.09.2017]

[22] Bartłomiej Matacz: Efficiency Analysis of Mobile Application

Frameworks

.

JCSI 6 (2018) 34-41



34

Badanie zachowań użytkowników oraz metod autoryzacji w kontek cie bezpieczeństwa urządzeń mobilnych

Piotr Król*, Damian Marek , Jakub Smołka


Streszczenie. W niniejszym artykule przedstawiono badania metod autoryzacji użytkowników mobilnych urządzeń wyposażonych w ekran dotykowy. Analizie poddano metody autoryzacji istniejące w systemie android, oraz nowe możliwo ci uwierzytelniania, zaproponowane przez autorów. Blokadę ekranu za pomocą PIN (ang. Personal Identification Number), oraz wzoru porównano z nowoopracowanymi przez autorów metodami. Analizowano czas wprowadzania klucza, liczbę pomyłek oraz liczbę kombinacji danej metody autoryzacji.

Słowa kluczoweŚ uwierzytelnianie użytkownikówś blokada wzoremś blokada pinemś bezpieczeństwo systemu androidś metody autoryzacji


Adresy e-mail: [email protected]*, [email protected], [email protected]

Analysis of user behavior and authorization methods in context of mobile

devices security

Piotr Król*, Damian Marek, Jakub Smołka Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. This article discusses authentication methods for users of mobile devices with touchscreens. The analysis concerns the authentication

methods already existing in Android OS and new authorization methods proposed by the authors. Pattern and PIN (Personal Identification

Number) lock were compared with two new authentication methods. The time required for entering the key, number of mistakes, number of

possible combinations were analyzed.

Keywords: : user authentication; pattern lock; pin lock; android security; authorization methods


E-mail addresses: [email protected]*, [email protected], [email protected]

1. Wstęp

Początki telefonów komórkowych z Systemem Android miały miejsce w grudniu 2008 roku, gdy HTC zaprezentowało pierwsze urządzenie o przeznaczeniu komercyjnym [1]. Mowa o modelu G1 znanym również jako HTC Dream z preinstalowanym Androidem w wersji 1.0. Od

tamtej pory w materii urządzeń mobilnych wiele się zmieniło. Zwykłe telefony komórkowe posiadające funkcję dzwonienia, pisania sms-ów oraz budzika zaczęły być wypierane przez urządzenia wielofunkcyjne, których głównym przeznaczeniem było korzystanie z Internetu.

Liczba użytkowników posiadających smartfony w ciągu ostatnich lat drastycznie wzrasta. W 2017 roku liczba ludzi

korzystających z tych urządzeń szacowana jest na około 2,

a 32 miliarda [2], z czego około 85% są to użytkownicy systemu Android [3]. Są to urządzenia, które przestały służyć już tylko i wyłącznie do dzwonienia czy pisania wiadomo ci tekstowych. Oprócz tych podstawowych rzeczy, smartfony są wykorzystywane do przeprowadzania płatno ci mobilnych, przechowywania haseł czy do zarządzania firmami. Oznacza

to że wraz z popularyzacją mobilnych urządzeń wielofunkcyjnym stały się one miejscem gdzie przechowywane mogą być wrażliwe dane, których dostanie się w niepowołane ręce mogłoby mieć niepożądane skutki.

Standardowe metody blokady w systemie android,

to płaszczyzna, gdzie niewiele się zmienia od dłuższego czasu.

Istniejące rozwiązania są wszystkim znane, co oznacza

że powstały sposoby ominięcia bądź wykradnięcia hasła użytkownika. Producenci smartfonów tacy jak LG,

czy Samsung nierzadko wprowadzają autorskie sposoby

blokady urządzeń, lecz nie są one dostępne dla użytkowników z czystym systemem Android.

Temat autoryzacji użytkowników w systemie opracowanym przez Google, jest powszechnie znany, lecz

nowe bądź istniejące sposoby uwierzytelniania wła cicieli

urządzeń nie są rozwijane. Szerokie pole manewru, jakie

pozostawili producenci mobilnych systemów operacyjnych skłoniło autorów do podjęcia powyższego tematu.

Poczucie bezpieczeństwa jest pożądane w ród użytkowników smartfonów, na których przechowywane

są poufne dane, toteż w niniejszym artykule przeanalizowano najczę ciej stosowane oraz nowe sposoby autentykacji opracowane przez autorów.


Poniżej przedstawiono aktualny stan badań z zakresu zabezpieczeń urządzeń mobilnych. Dzięki pozycjom

dostępnym w bazach naukowych takich jak Springer, ScienceDirect, BazTech, Scopus Przeanalizowano problem

bezpieczeństwa przechowywanych informacji w urządzeniach mobilnych, oraz nowo zaproponowane rozwiązania w celu podniesienia poziomu bezpieczeństwa.


35

Pozycja [4] opisuje słabe punkty, które posiada zaimplementowana w systemie android blokada za pomocą wzoru. Opisuje ona ryzyko złamania blokady z wykorzystaniem smugi, jaką zostawia po sobie palec po wykonaniu wzoru blokady na ekranie. Artykuły [5, 6, 7]

zawierają opis procesu tworzenia i badania nowych metod autoryzacji, które mogłyby podnie ć poziom bezpieczeństwa użytkowników systemów mobilnych. Dodatkowo

w pozycji [8] postarano się ulepszyć blokadę wzorem poprzez dodanie wskaźnika poziomu siły wzoru, co wpłynęło na to, że użytkownicy chętniej skłaniali się do tworzenia bezpieczniejszych wzorów.

3. Metody autoryzacji w systemie Android

Popularyzacja urządzeń mobilnych z ekranem dotykowym otworzyła nowe możliwo ci blokady urządzeń kieszonkowych. Oprócz autoryzacji za pomocą hasła bądź kodu cyfrowego jak to było w przypadku tradycyjnych

telefonów komórkowych, do smartfonów wkroczyły nieznane wcze niej nowe metody zabezpieczania ich przed

niepowołanym użyciem.

Firma Google dostarcza użytkownikom swojego systemu

operacyjnego możliwo ć zablokowania urządzenia przed użyciem przez osoby nieuprawnione na kilka sposobów. Najbardziej znanymi metodami są blokada wzorem, oraz blokada pinem. Sporą popularno cią cieszy się również

stosowana przez producentów blokada poprzez odcisk palca.

Wymaga ona jednak posiadania specjalnego czytnika, który potrafi zeskanować linie papilarne. Rozwiązanie to zdaje się być dobrym zabezpieczeniem, gdyż nie da się w łatwy sposób podrobić odcisku palca. Rozwiązanie to jest również szybkie

i można go używać bez patrzenia na ekran urządzenia mobilnego.

3.1. Blokada za pomocą PIN’u

Omawiany rodzaj blokady znany jest większo ci użytkowników. Ten rodzaj blokady w różnych formach znajduje zastosowanie w wielu obszarach takich jakŚ dostęp do konta bankowego, wej cie do biura, czy dostęp do różnych aplikacji mobilnych.

Rys. 1. Ekran blokady za pomocą PIN’u

Jego działanie opiera się na kombinacji czterech cyfr

(Rys. 1.), z których każda może występować dowolną ilo ć razy. Zmiana kolejno ci cyfr w PIN-ie również ma znaczenie

więc funkcją opisującą liczbę możliwych kombinacji będą wariacje z powtórzeniami opisane wzorem (1)

� gdzie: n- wielko ć zbioru cyfr ,k- liczba cyfr w pinie.

Zgodnie ze wzorem (1) dla systemu dziesiętnego liczba

możliwych do utworzenia PIN-ów jest równa 10k, czyli

10 000 dla najbardziej typowego cztero-cyfrowego PINu.

Po zastosowaniu takiej metody zabezpieczenia użytkownika możliwe jest wykonanie pięciu prób odblokowania urządzenia. Po pięciu nieudanych próbach urządzenie zostaje zablokowane na 30 sekund bez możliwo ci odblokowania. Po upłynięciu tego czasu możliwe jest kolejne podej cie do odblokowania, które w razie pomyłki skutkuje ponownym zamrożeniem urządzenia, lecz tym razem na 60 sekund. Kolejna nieudana próba zablokuje urządzenie na 4 minuty bez możliwo ci odblokowania i gdy następnym razem znów nie uda się poprawnie wprowadzić kodu PIN, niemożliwe będzie odblokowanie urządzenia za pomocą tego kodu. Jedynym sposobem na tak zablokowane urządzenie jest autoryzacja

poprzez skrzynkę e-mail.

3.2. Blokada za pomocą wzoru

Metoda wykorzystująca wzór jest jednym

z najpopularniejszych sposobów zabezpieczenia urządzenia przed niepowołanym dostępem. Popularno ć tej metody wynika głownie z faktu, że jest ona dostępna w systemie

Android jako jeden z wbudowanych sposobów

zabezpieczenia urządzenia. Spo ród możliwo ci jakie oferuje mobilny system operacyjny firmy Google metoda

wykorzystująca wzór sprawia wrażenie najbardziej skompilowanej do powtórzenia przez osoby niepowołane

przy jednoczesnym zachowaniu intuicyjnego wyglądu i łatwo ci zapamiętania zdefiniowanego schematu. Główną zaletą przedstawionego rozwiązania jest możliwo ć zdefiniowania wzoru wedle uznania użytkownika.

Działanie zabezpieczenia oparte jest o pozornie proste łączenie punktów wy wietlanych w formie siatki na ekranie

(Rys 2.). Użytkownik wybiera jeden z punktów i rozpoczyna powtarzanie zdefiniowanej wcze niej kombinacji poprzez przeciągnięcie palcem przez wszystkie wymagane punkty.

Podstawowym złożeniem przy tworzeniu i powtarzaniu

Rys. 2. Ekran blokady za pomocą wzoru odblokowania


36

sekwencji odblokowywania jest fakt że każdy punkt może zostać wykorzystany tylko jeden raz.

Przykład z rys. 2 z siatką złożoną z 9 punktów przedstawia zdefiniowany wzór złożony z 5-ciu punktów. Minimalna liczba punktów użytych do zdefiniowania wzoru wynosi 4. Warto ć ta jest narzucona przez twórców systemu Android, którzy stwierdzili, że sekwencja złożona

z 3 punktów jest wyjątkowo nieskutecznym zabezpieczeniem. W takim rozwiązaniu maksymalna teoretyczna liczba

kombinacji okre lona jest sumą permutacji (2): ∑ �!�− !�= (2) � − liczba punktów siatki, � − liczba punktów użytych we wzorze

W przypadku siatki złożonej z 9 punków teoretyczna maksymalna liczba możliwych wzorów wynosi 985 824.

Obliczenia dokonane według podanego wzoru pozwalają na okre lenie wszystkich możliwych połączeń punktów siatki wy wietlonej na ekranie. W celu obliczenia liczby dostępnych kombinacji w metodzie wzorcowej należy wykluczyć przypadki, w których użytkownik nie jest w stanie połączyć punktów. Przykładem takiej operacji jest próba połączenia punktów położonych w jednej linii, które nie sąsiadują ze sobą w taki sposób by pominąć punkt znajdujący się pomiędzy. Palec użytkownika i ekran telefonu są zbyt mało precyzyjnymi narzędziami wprowadzać sekwencje złożone z takich punktów i połączeń miedzy nimi. W konsekwencji

należy wykluczyć czę ć wzorców których użytkownik nie jest w stanie fizycznie wykonać. Warto ci te zostały okre lone w

pracy Marty Løge, która dokonała badań dotyczących m.in.

liczby wła ciwych kombinacji uwzględniając tylko możliwe do powtórzenia sekwencje [9]. Zależno ć liczby możliwych wzorów w zależno ci od zastosowanej liczby punktów została przedstawiona w Tabeli 1.

Tabela 1. Zależno ć liczby możliwych wzorów od liczby wykorzystanych

punktów siatki

Liczba punktów Liczba kombinacji

4 1624

5 7152

6 26016

7 72912

8 140707

9 140704

Przy zastosowaniu wzoru złożonego z 4 punktów na siatce 9 otrzymuje się 1624 kombinacji. Z zwiększenie liczby punktów we wzorze do 5 zwiększa liczbę możliwych kombinacji ponad czterokrotnie. Korzystając ze wzoru

złożonego z maksymalnej liczby możliwych do użycia punktów uzyskuje się 9! możliwo ci, czyli 140704. Wykorzystanie wzoru złożonego z 8 punktów daje dokładnie taką samą liczbę kombinacji co w przypadku skorzystania

z wzoru okre lonego na 9 punkach. Całkowita liczba

możliwych do wykorzystania wzorów jest sumą możliwo ci dla poszczególnych ilo ci wykorzystywanych punktów i wynosi 389112. Po za siłą zabezpieczenia wynikającą z dużej liczby możliwych kombinacji autorzy zabezpieczyli się przed próbą złamania wzoru metodą siłową. Po 5-krotnym

błędnie wprowadzonym wzorze zostaje zablokowana możliwo ć wprowadzania wzoru ponownie na czas 1 minuty.

Po upływie czasu blokady, można spróbować wprowadzić wzór ponownie lecz po 5-tej nieudanej próbie urządzenie zostanie zablokowane na 5 minut. Trzecia podobna próba złamania wzoru skutkować będzie całkowitym zablokowaniem urządzenia a jedynym sposobem na odblokowanie będzie autentykacja za pomocą konta Google. W zależno ci od producenta i wersji systemu operacyjnego

Android liczby dopuszczalnych prób mogą się nieznacznie różnić jednak zasada ograniczonego zaufania do osoby wprowadzającej wzór jest stosowana i nadmierne błędne wprowadzanie sekwencji skutkować będzie blokadą urządzenia na okre lony czas.

3.3. Proponowana blokada 1

Pierwszą metodą autoryzacji wykorzystującą ekran dotykowy opracowaną przez autorów jest blokada

opracowana na potrzeby pracy badawczej. Głównym modułem systemu jest logika zawarta w częsci programistycznej, która odpowiada za zapisywanie wzorca

odblokowującego oraz sprawdzenie czy jest on poprawny. Dodatkowo na potrzeby badań aplikacja wyposażona została w bazę danych, do której zapisywane są parametry

konfiguracyjne oraz dane na temat samego procesu

odblokowywania.

W tym rozwiązaniu użytkownik sam może zdecydować jak mocne będzie jego zabezpieczenie. Działanie tej formy upoważnienia wła ciciela korzysta z przycisków pojawiających się na ekranie w formie siatki (Rys. 3.).

Użytkownik sam może zdecydować ile kolumn i wierszy będzie wykorzystywał. Możliwo ć ta pozwala osobie korzystającej z tej formy zabezpieczeń zdecydować jaki chce stosować poziom bezpieczeństwa. Minimalna liczba kolumn

i wierszy została zdefiniowana odpowiednio na 3 kolumny

oraz 4 wiersze. Ograniczenie to zostało nałożone z powodów bezpieczeństwa po to, aby użytkownik nie mógł ustawić kombinacji, którą możnaby odganąć w trzech próbach.


37

Jak w każdej metodzie odblokowania na początku należy zdefiniować wzorzec. Użytkownik wybiera z jakiej siatki

przycisków ma składać się ekran odblokowania. Następnie

okre la liczbę przycisków, których należy dotknąć aby odblokować urządzenie. Po tej czynno ci ukazuje się sam ekran odblokowania (Rysunek 3), na którym widoczna jest

siatka przycisków a użytkownik wybiera te, które go interesują tym samym definiując wzorzec.

Ze względu na to, że rozmiar siatki przycisków oraz długo ć samego hasła blokady może być , liczba wszystkich

możliwych do utworzenia haseł również będzie zmienna i będzie zależała od tych czynników. Liczba wariacji

wszystkich możliwych haseł definiują wariacje bez powtórzeń opisane wzorem ∗ ![ ∗ − ]! (3)

gdzie i - ilo ć kolumn, j - ilo ć wierszy, k - długo ć hasła

Liczba kombinacji dla wszystkich konfiguracji hasła przedstawia Tabela 2.

Tabela 2. Liczba kombinacji hasła w zależno ci od długo ci hasła oraz kolumn i wierszy przycisków

Długość hasła

Siatka 4 5 6 7 8

3x4 11880 95040 665280 3991680 19958400

3x5 32760 360360 3603600 32432400 259459200

3x6 73440 1028160 13366080 160392960 1764322560

3x7 143640 2441880 39070080 586051200 8204716800

4x4 43680 524160 5765760 57657600 518918400

4x5 116280 1860480 27907200 390700800 5079110400

4x6 255024 5100480 96909120 1744364160 29654190720

4x7 491400 11793600 271252800 5967561600 125318793600

4x4 116280 1860480 27907200 390700800 5079110400

5x5 303600 6375600 127512000 2422728000 43609104000

5x6 657720 17100720 427518000 10260432000 235989936000

5x7 1256640 38955840 1168675200 33891580800 948964262400

6x4 255024 5100480 96909120 1744364160 29654190720

6x5 657720 17100720 427518000 10260432000 235989936000

6x6 1413720 45239040 1402410240 42072307200 1220096908800

6x7 2686320 102080160 3776965920 135970773120 4758977059200

3.4. Proponowana blokada 2

Druga metoda opracowana przez autorów jest połączeniem metody wykorzystującej wzór z PIN-em.

Na potrzeby badan została opracowana implementacja

nowatorskiego podej cia do wprowadzania kodu cyfrowego. Ideą tego rozwiązania jest wprowadzenie kolejnych cyfr PIN-

u poprzez odnalezienie i wskazanie ich na ekranie urządzenia.

Rozwiązanie to zakłada, że w etapie tworzenia zabezpieczenia użytkownik wprowadza kod cyfrowy złożony z 5 cyfr a następnie zapisuje go jako bazowy kod PIN.

Odblokowanie odbywa się przy pomocy gestu przeciągnięcia palcem po ekranie w sposób podobny do wzoru odblokowania (Rys. 4.). Podczas próby odblokowania użytkownik wybiera jedną z czterech cyfr wy wietlonych w pierwszej linii. Po wybraniu punktu z uznaną za wła ciwą cyfrę przechodzi do wybrania kolejnej cyfry PIN-u spo ród wy wietlonych w linii drugiej. Liczba wy wietlanych linii jest równa liczbie cyfr zadeklarowanego PIN-u. Pojawiające się na ekranie liczby w danej linii zawierają cyfry spo ród których tylko jedna będzie wła ciwa, pozostałe natomiast są liczbami losowymi z przedziału 0-9 z wykluczeniem warto ci wła ciwej. Istotną cechą w wy wietlanej linii jest fakt,

że za każdym razem przy odblokowaniu cyfry są tasowane co sprawia, że lad wykonywanego gestu za każdym razem

będzie inny co ogranicza złamanie wzoru poprzez podejrzenie przez osoby postronne. Poniżej zaprezentowano grafiki

przedstawiające 3 próby wprowadzenia wzoru z czego jedna okazuje się być niewła ciwa (Rys.4).

Wykorzystanie PIN-u o długo ci większej lub równej 5 umożliwi uzyskanie kombinacji okre lonych wzorem (4) � (4)

gdzie: n- wielko ć zbioru możliwych cyfr ,k-liczba cyfr

w PINie.

Natomiast wprowadzanie PIN-u przy pomocy metody

wykorzystującej wzór uniemożliwi osobie niepowołanej jednoznaczne okre lenie szyfru. Dodatkowym zabezpieczeniem jest losowanie miejsca w linii, w którym pojawiać się będzie wła ciwa cyfra PIN-u co w rezultacie

sprawi ze wskazywany na ekranie wzór nie będzie powtarzany oraz nie będzie możliwe powtórzenie zapamiętanego przez osobę niepowołaną wzoru.

Pojawienie się wła ciwej liczby na okre lonej pozycji jest

okre lone prawdopodobieństwem wynoszącym 0,25.

Rys. 3. Widok tworzenia blokady

Rys. 4. Wprowadzanie kodu odblokowania przy pomocy nowego

rozwiązania


38

W przypadku kiedy wzór ma długo ć 5 prawdopodobieństwo

pojawienia się takiej samej kombinacji wynosi: / = . 9 (5)

4. Metoda Badań

4.1. Przedmiot badań

Przedmiotem badań są 2 aplikacje imitujące ekran blokady urządzenia z systemem Android. Dodatkowo

aplikacje te w celu porównania badanych parametrów implementują funkcjonalno ci blokowania ekranu znane użytkownikom z system Android. Wspomniane aplikacje

zbierają informacje na temat własno ci takie jak liczba

pomyłek przy wprowadzaniu wzorca, czas wprowadzania wzorca, liczba możliwych kombinacji. Wykonanie aplikacji przez autorów zostało przy wykorzystaniu różnych technologii, tudzież języka programowania, lecz parametry

podczas badania są mierzone według tych samych wyznaczników.

4.2. Grupa badawcza

Badania pozwalające na ocenę skuteczno ci i użyteczno ci metod autoryzacji użytkowników zostały przeprowadzone na grupie potencjalnych odbiorców tego typu rozwiązań.

Pierwszą grupę stanowią anonimowi użytkownicy którzy za pomocą ankiety internetowej udzielili informacji na temat obecnego stanu znajomo ci tematyki związanej z autoryzacją dostępu do ich urządzeń.

Do ankiety przystąpiło 85 osób które odpowiedziały na 10 kluczowych pytań z zakresu wykorzystania metod blokady ekranu. Na pytania związane cisłe z tematyką pracy odpowiadali tylko ci ankietowani, którzy zadeklarowali używanie urządzenia wyposażonego w ekran dotykowy z systemem Android. Zdecydowana większo ć, wynosząca 97,5% odpowiedziała twierdząco na pytanie czy zależy im aby urządzenie, z którego korzystają było zabezpieczone przed niepowołanym dostępem (Rys. 5).

Rys. 5. Podział odpowiedzi użytkowników na pytanie o przywiązywanie uwagi do bezpieczeństwa posiadanego urządzenia

Spo ród ankietowanych 58,5% stanowiły kobiety a 41,4% mężczyźni w wieku od 18 do 40 lat (Rys.6). Najliczniejszą grupę stanowiły osoby pomiędzy 18 a 25

rokiem życia, która liczyła 85,4 % cało ci (Rys. 7).

Rys. 6. Procentowy udział mężczyzn i kobiet w przeprowadzonej ankiecie

Rys. 7. Podział procentowy respondentów ze względu na wiek

Rys. 8. Procentowy udział ankietowanych ze względu na deklarowane wykształcenia

Osoby biorące udział w ankiecie deklarowały w 47,6%,

że są osobami o wykształceniu wyższym a 35,4% w trakcie studiów. 15,9% to osoby które w pytaniu o wykształcenie zaznaczyły warto ć „ rednie” (Rys 8).

Drugą grupę stanowiło 21 użytkowników, którzy przetestowali zaimplementowane przez autorów rozwiązania i poprzez użycie konkretnych metod, dostarczyli danych

na podstawie których dokonywana była dalsza analiza problemu.

4.3. Proces gromadzenia danych

Badania, na których opierali się autorzy, przy sprawdzeniu efektywno ci metod zabezpieczania urządzeń mobilnych zostały wykonane w dwojaki sposób. Podział procesu pozyskiwania danych uwzględniał kontekst informacji i był uwarunkowany sposobem komunikacji

z użytkownikami.

W pierwszej kolejno ci została przeprowadzona ankieta za po rednictwem popularnej platformy Google Forms.

Ankieta miała na celu dostarczenie informacji dotyczących wiadomo ci użytkowników na temat problematyki

autoryzacji dostępu i sposobów zabezpieczania prywatnych


39

urządzeń mobilnych, na których przechowują cenne oraz często prywatne dane. Postawione użytkownikom pytania

dotyczyły m.in. faktu posiadania danych o charakterze poufnym oraz czy użytkownicy używają metod autoryzacji dostępu. Ponadto ankietowani zostali zapytani czy uważają,

że domy lne sposoby autoryzacji są dostatecznie bezpieczne oraz czy znają i pokusiliby się o stosowanie takich rozwiązań.

Drugim sposobem na pozyskanie danych na potrzeby

badań było udostępnienie użytkownikom urządzeń z wdrożonymi mechanizmami zabezpieczającymi oraz poproszenie ich o użycie zaprezentowanych metod autoryzacji. Badanie to miało na celu pozyskanie danych dotyczących jako ci mechanizmów, na które wpływały m.in

czas odblokowywania, liczba pomyłek na okre loną liczbę prób. Czas odblokowania podany w sekundach, jest

parametrem, którego pomiar zaczyna się przy wybraniu

pierwszego elementu/liczby hasła, a pomiar kończy się po wybraniu ostatniego elementu. Kolejny badany parametr

czyli liczba pomyłek, jest warto cią, która mówi ile razy dany użytkownik pomylił się podczas autoryzacji.

5. Analiza wyników

5.1. Aplikacja

W tabeli 3 zestawiono maksymalne ilo ci kombinacji haseł, jakie można utworzyć w porównywanych metodach autoryzacji systemu Android.

Tabela 3. Ilo ć kombinacji w zależno ci od rodzaju blokady

Rodzaj blokady Maksymalna ilo ć Kombinacji PIN 10000

Wzór 140704

Metoda 2 100000

Metoda 1 4758977059200

Największą liczbę kombinacji dostarczyć może nowo opracowana Metoda 1, gdzie przy konfiguracji siatki

przycisków 6x7 oraz ha le o długo ci 8-miu liczb, można utworzyć ponad 4,7 biliona różnych haseł. Jest to warto ć znacznie przewyższająca konkurencyjne rozwiązania. Im

wyższa jest ta warto ć, tym trudniej daną blokadę złamać, gdyż zmniejsza się prawdopodobieństwo odgadnięcia hasła, co jest jak najbardziej pożądanym zjawiskiem. Drugim pod

tym względem rozwiązaniem jest blokada za pomocą wzoru, czyli sposób, który można znaleźć domy lnie zaimplementowany w systemie Android. Liczba kombinacji

wzoru, jaki można utworzyć wynosi ponad 140tys. Niewiele gorszym rozwiązaniem pod względem ilo ci kombinacji hasła okazała się Blokada 2 opracowana przez autorów. Liczba różnych haseł jakich możliwe jest utworzenie wynosi 100tys. Najsłabszą metodą okazała się blokada przy pomocy cztero-

cyfrowego kodu PIN. Dostarczyć ona może tylko 10 tys. różnych haseł, co powoduje, że w porównaniu do trzech

pozostałych blokad staje się rozwiązaniem, które potencjalnie najłatwiej jest złamać, próbując wprowadzić jak najwięcej kombinacji.

Kolejnym analizowanym aspektem jest czas autoryzacji

(Rys. 9, Tabela 4), czyli wprowadzanie wcze niej zdefiniowanego hasła bądź wzoru odblokowania. Jest to aspekt ważny, gdyż rozwiązania, które wymagają długiego

czasu wprowadzania wzorca, mogłyby męczyć użytkowników i pomimo zapewnienia dobrego poziomu

zabezpieczenia mogłyby sprawić, że użytkownik zrezygnowałby z ich używania na rzecz słabszych metod autoryzacji.

Tabela 4. redni czas trwania autoryzacji użytkownika w zależno ci od blokady

Rodzaj blokady redni czas autoryzacji [s] Metoda 1 2,42

Metoda 2 2,94

PIN 1,49

Wzór 1,21

Rys. 9. rednia długo ć trwania autoryzacji dla poszczególnych metod

Odnotowano, że redni czas autoryzacji, jest najkrótszy

w przypadku blokady wzorem. Czas ten wynosi 1,21s. Jest to

najlepszy wynik spo ród badanych narzędzi. Niewiele gorsza okazuje się blokada PIN, gdyż redni czas wprowadzania hasła wynosił prawie 1,5s. Gorzej wypadły nowo opracowane przez autorów rozwiązania. rednie czasy wynosiły odpowiednio 2,42s (metoda 1), oraz 2,94s (metoda 2). Można zauważyć, że blokada PIN oraz wzór, wypadły lepiej niż pozostałe, lecz warto wspomnieć, że są to blokady, które większo ć użytkowników zna, posiada w swoim urządzeniu, bądź najprawdopodobniej kiedy ich używało. Mogło to wpłynąć na to, że osoba testująca nie musiała na nowo poznawać danego mechanizmu działania, co skróciło czas autoryzacji. W przypadku rozwiązań opracowanych w celach naukowych, użytkownicy musieli poznać nowe mechanizmy autoryzacji oraz je zrozumieć, tak by potem pomy lnie stworzyć blokadę i przej ć proces uwierzytelnienia. Z uwagi na ten fakt, czas potrzebny na odblokowanie mógł się wydłużyć. Warto dodać, że różnica między najwolniejszą metodą, a najszybszą to zaledwie 1,73s, co nie powinno mieć negatywnego wpływu na odczucia użytkowników. Tabela 5. Ilo ć pomyłek w zależno ci od blokady

Rodzaj blokady Liczba pomyłek

Metoda 1 2

Metoda 2 2

PIN 2

Wzór 1

Tabela 5 przedstawia ile osób popełniło błąd, w każdej testowanej metodzie podczas procesu uwierzytelniania.

W trzech metodach czyli: metoda 1, metoda 2 oraz blokada

PIN, dwóch użytkowników popełniło 2 błędy, natomiast tylko jeden użytkownik popełnił błąd przy użyciu blokady PIN.

Analiza liczby popełnionych błędów może doprowadzić do wskazania rozwiązania, którego wzorzec może być trudny do zapamiętania. Dane zebrane podczas tego testu nie różnią


40

się od siebie drastycznie. W przypadku wszystkich testowanych metod autoryzacji wyniki były podobne, dlatego

można stwierdzić, że pod względem trudno ci zapamiętania wzorca, badane rozwiązania są takie same.

5.2. Ankieta

Przeprowadzone badanie w formie anonimowej ankiety

umożliwiło poznanie oczekiwań i wiadomo ci użytkowników w zakresie skuteczno ci używanych przez ankietowanych rozwiązań. Spo ród wszystkich ankietowanych niemal każdy uczestnik stwierdził że zależy mu na bezpieczeństwie danych, które przechowuje na swoim urządzeniu. Wyjątkami okazały się dwie osoby które na to pytanie odpowiedziały negatywnie.

Istotną kwestią, która w ankiecie została poruszona, było pytanie do użytkowników na temat tego czy na swoich urządzeniach posiadają dane uznawane jako wrażliwe lub poufne. Spo ród wszystkich odpowiedzi 54,3% użytkowników wykorzystuje swoje urządzenia do przechowywania takich informacji. 34,6% ankietowanych

deklaruje, że nie posiada tego typu danych lub nie traktuje ich

w taki sposób natomiast 11,1% respondentów nie było w stanie opowiedzieć zarówno twierdząco jak i przecząco na zadane pytanie (Rys.10).

Ankietowani zostali również zapytani o typy danych jakie

przechowują. Dane te zostały zestawione na Rys. 11.

Najpopularniejszą grupę stanowią prywatne zdjęcia i nagrania wideo. 84,1% ankietowanych udzieliło takiej odpowiedzi. Ponad połowa zapytanych osób przechowuje w swoich

urządzeniach informacje teleadresowe i stanowi 56,8% całej grupy ankietowanych. Niewątpliwie istotną grupą danych jakie użytkownicy urządzeń przechowują są hasła i inne dane

dostępowe do kont. Wyniki ankiety dla wyżej wymienionych grup wynoszą kolejno 43,2% dla haseł i 40,9% dla innych danych dostępowych. Sumując te wyniki otrzymujemy grupę która stanowi blisko 85% osób deklarujących posiadanie tego typu danych spo ród wszystkich ankietowanych.

Wynik ten, w zestawieniu z najpopularniejszą grupą jaka stanowią multimedia, ukazuje jak poważną sprawą jest autoryzacja dostępu urządzeń mobilnych

Najrzadziej ankietowani wykorzystują smartfony do przechowywania poufnych notatek i dokumentów tekstowych (2,3%) oraz danych innej kategorii (4,6%).

Rys. 11. Najczę ciej przechowywane na urządzeniach typy danych

Kluczowym pytaniem przeprowadzonej ankiety było pytanie o to czy ankietowani w ogóle korzystają z jakiegokolwiek mechanizmu blokady ekranu. Jak się okazuje, pomimo wiadomo ci zagrożeń i konsekwencji wynikających z nieautoryzowanego dostępu zaledwie 82,7% ankietowanych włączyło w swoim urządzeniu mechanizmy

zabezpieczające. Widać zatem, że mimo deklaracji

respondentów o tym, że zależy im na bezpieczeństwie urządzeń istnieją osoby, które nie podjęły kroków w tym kierunku i nie zabezpieczyły się przed niepowołanym dostępem. Na podstawie informacji uzyskanych od osób które zabezpieczyły swoje urządzania dostrzegamy,

że najpopularniejszym sposobem blokady niepowołanego dostępu jest wzór odblokowania. Metoda polegająca na wprowadzeniu identycznej kombinacji połączenia punktów na ekranie jest stosowana przez 55,2%

ankietowanych. Kolejnym bardzo popularnym sposobem

okazuje się tradycyjny PIN, który stosowany jest przez 40,3% osób. 35,8% respondentów jako zabezpieczenie swoich urządzeń wykorzystuje metodę sprawdzania odcisku palca. Wynik ten jest uzależniony od liczby urządzeń wyposażonych

w odpowiedni sensor pozwalający na sprawdzenie zgodno ci linii papilarnych. Najrzadziej wykorzystywanym sposobem

jest odblokowanie za pomocą hasła złożonego ze znaków alfanumerycznych i jest wykorzystywany przez ok. 1,5%

zapytanych osób (Rys. 12).

Rys.12. Popularno ć stosowanych mechanizmów zabezpieczających

Ankietowane osoby zostały również poproszone o odpowiedź na pytanie czy istniejące i znane im metody autoryzacji dostępu są skuteczne i wystarczające by zabezpieczyć urządzenie. Spo ród zapytanych osób 43,9% są przekonane iż istniejące i wykorzystywane rozwiązania są bezpieczne i skutecznie uniemożliwiają dostęp do urządzenia

i znajdujących się na nim danych osobom postronnym.

Trochę więcej niż ćwierć osób (28,8%) nie jest w stanie okre lić czy i w jakim stopniu istniejące na rynku rozwiązania są skuteczne. Grupa ta nie odpowiedziała na

pytanie się ani twierdząco ani przecząco. Pozostali, stanowiący 27,3% czyli nieco mniej niż niezdecydowani, są przekonani iż stosowane metody autoryzacji dostępu są zbyt

Rys. 10. Podział ankietowanych ze względu na wiadomo ć posiadania danych poufnych na urządzeniach mobilnych


41

słabe i nie gwarantują satysfakcjonującego ich poziomu bezpieczeństwa.

Rys. 13. Procentowy rozkład zadowolenia z poziomu bezpieczeństwa zapewnianego przez standardowe mechanizmy autoryzacji

Zdecydowana większo ć użytkowników nie korzysta z popularnych i niestandardowych metod autoryzacji.

Zapytani w ankiecie w 93,8% oznajmili, że nie używają metod które nie są preinstalowane w samym systemie operacyjnym. Zaledwie 6,2% ankietowanych zaznajomiło się z tematem i użyło mniej popularnych mechanizmów, które mogą okazać się nie lada zaskoczeniem dla osób

niepowołanych. Ostatnim elementem ankiety były wolne sugestie ankietowanych dotyczące metod i możliwo ci jakie mogły by w przyszło ci skutecznie służyć za mechanizmy

zabezpieczające urządzenia. W ród odpowiedzi najczę ciej pojawiały się metody skanowania tęczówki oka oraz walidacja modelu głosu użytkownika. Ponadto ankietowani

wymieniali ujęty w zestawieniu odczyt odcisku palca. Dużą uwagę ankietowanych przykuwała autoryzacja wieloetapowa wykorzystująca różne kanały komunikacyjne m.in. wiadomo ci SMS, email. Najbardziej wybiegającymi w przyszło ć sugestiami były sposoby analizy DNA

6. Wnioski

Na podstawie badań przeprowadzonych po ród 21 osób zaobserwowano, że proces autoryzacji nowo opracowanych metod trwa w większo ci przypadków dłużej niż dla metod już stosowanych w systemie Android. Jest to m.in.

spowodowane tym, że użytkownicy mieli styczno ć z takimi sposobami zabezpieczeń po raz pierwszy i po dłuższym

czasie użytkowania ten czas mógłby ulec skróceniu. Biorąc pod uwagę liczbę kombinacji hasła najgorzej wypada blokada PIN, co oznacza że zapewnia najniższy poziom odporno ci na złamanie metodą sprawdzenia wszystkich kombinacji hasła zwaną Brute Force [10]. Najlepsza pod tym względem jest proponowana metoda 1, gdyż przy najbardziej złożonym ha le i największej siatce wzorca, zapewnia największą liczbę

kombinacji. Druga po metodzie 1 jest blokada wzorem, która dostarcza o przeszło 40tys więcej kombinacji niż metoda 2.

Poddając analizie liczbę błędów popełnianych przez testujących, wszystkie rozwiązania wypadają podobnie. Rozwinięcie badań w postaci przebadania dużo większej grupy, mogłoby dostarczyć dane, których analiza pomogłaby stwierdzić jaki różnice pomiędzy badanymi rozwiązaniami.

Przeprowadzona ankieta dostarcza informacji

dotyczących zachowania, przyzwyczajeń oraz oczekiwań

użytkowników urządzeń mobilnych. Z badania jednoznacznie

wynika, że respondenci chcą chronić swoje urządzenia przy pomocy skutecznych mechanizmów jednak niejednokrotnie brakuje im poczucia iż wykorzystywane obecnie metody są nadal bezpieczne. Spo ród wykorzystywanych predefiniowanych mechanizmów w systemie Android najbardziej doceniany przez użytkowników jest „wzór odblokowania” stosowany przez ponad połowę ankietowanych. Zestawienie wykorzystywanych

mechanizmów i ich procentowy udział w stosowaniu ukazuje,

że blokada przy pomocy odcisku palca staje się coraz czę ciej wykorzystywanym sposobem. Walidacja odcisku palca

zapewnia duże poczucie bezpieczeństwa o czym może wiadczyć fakt wskazywania tego rozwiązania w wolnych

sugestiach od ankietowanych. Najczę ciej przechowywanymi materiałami są dane multimedialne często o charakterze poufnym i istotnym znaczeniu sentymentalnym dla

użytkowników, a także dane wykorzystywane w codziennych

czynno ciach związanych z bankowo cią, biznesem i komunikacją. Tego rodzaju dane wymagają szczególnej ochrony, którą mechanizmy autoryzacji powinny zapewniać.

Wyniki ankiety ukazują, że blisko 29% niepewno ć ankietowanych oraz 27% przekonanie o braku skuteczno ci popularnych sposobów autoryzacji dostępu wskazuje obszar, w którym istnieje potrzeba rozwijania oprogramowania

i ulepszania urządzeń w celu zapewnienia jak najbardziej bezpiecznego i odpornego na ataki mechanizmu blokady

urządzenia przed niepowołanym dostępem. Sprostanie

wymaganiom użytkowników w tym obszarze stanowi niewątpliwie wyzwanie dla producentów zarówno oprogramowania jak i urządzeń a także okazuje się wietnym obszarem badań, których rezultatem mogą być nowe przełomowe koncepcje jak i udoskonalone wersje znanych metod zabezpieczania urządzeń.

Literatura

[1] First Android Phone http://www.spinfold.com/first-android-phone/

[30.05.2017]

[2] Number of smartphone users worldwide from 2014 to 2020 (in billions, https://www.statista.com/statistics/330695/number-of-smartphone-

users-worldwide/ [26.05.2017]

[3] Global market share held by smartphone operating systems from 2009

to 2016, https://www.statista.com/statistics/263453/ global-market-

share-held-by-smartphone-operating-systems// [26.05.2017]

[4] Taekyoung Kwon, Sarang Na, TinyLock: Affordable defense against

smudge attacks on smartphone pattern lock systems, Graduate School of Information, Yonsei University, Seoul 120-749, Republic of Korea,

2013.

[5] J. Angulo, E. Wästlund, P. Gullberg, D. Kling, D. Tavemark, S.Fischer-

Hübner, Understanding the user experience of secure mobile online transactions in realistic contexts of use, 2012.

[6] Kwang Il Shin ,Ji Soo Park, Jae Yong Lee, Jong Hyuk Park, Design

and Implementation of Improved Authentication System for Android

Smartphone Users, 2012.

[7] Hsin-Yi Chiang, Sonia Chiasson, Improving user authentication on

mobile devices: A Touchscreen Graphical Password, 2013.

[8] Chen Sun, Yang Wang, Jun Zheng, Dissecting pattern unlock: The

effect of pattern strength meter on pattern selection, 2014.

[9] Marte Dybevik Løge, Tell Me Who You Are and I Will Tell You Your Unlock Pattern, 2015.

[10] M. Bond, P. Zielinski Decimalisation table attacks for PIN cracking, 2013

JCSI 6 (2018) 42-46

Wysłane: 2017-10-12


42

Porównanie konfiguracji i możliwości bibliotek ORM dla systemu Android

Tomasz Serwin* Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska

Streszczenie. W artykule omówiono temat konfiguracji i możliwości bibliotek mapowania relacyjno-obiektowego dla systemu Android.

Przedstawiono dotychczasowe porównania ORM dla systemów mobilnych. Opisane zostały sposoby konfiguracji oraz wspierane typy atrybutów obiektów.

Słowa kluczowe: orm; android; sqlite



Comparison of the configuration and capabilities of ORM libraries for Android

Tomasz Serwin*


Abstract. The article discusses configuration and capabilities of object-relational mapping libraries for the Android operating system. It also

presents previous comparisons of ORMs for mobile systems. Configuration methods and supported mappings from java to database types are

described.

Keywords: orm; android; sqlite



1. Wstęp

System Android, którego pierwsza wersja została opublikowana 21 października 2008 r., jest aktualnie najpopularniejszym systemem operacyjnym na urządzenia mobilne[1]. Jego popularność powoduje powstawanie wielu bibliotek o różnym zastosowaniu.

Jednym z ważnych obszarów jest dostęp i komunikacja z bazą danych. Android do przechowywania danych oferuje bazy SQLite. Dodatkowo zapewniany jest podstawowy zestaw

funkcji, który pozwala na komunikację z oferowaną bazą [2].

Jednak nie wszystkich programistów zadowalają możliwości dostarczanego API. Powstały więc liczne biblioteki mapowania relacyjno-obiektowego oferujące rozszerzone możliwości działania na bazie danych.

Badanie przydatności ORM i porównanie ORM pod względem wydajnościowym nie jest nowym tematem, chociaż nie jest on dokładnie zgłębiony w odniesieniu do wszystkich platform. Jednak oprócz wydajności, ważnym elementem jest również wygoda używania biblioteki i jej możliwości.

2. Analiza literatury

Zbigniew Rosiek w artykule „Mapowanie obiektowo relacyjne ORM – czy tylko dobra idea?” przedstawia wady i zalety ORM w oparciu o JPA (Java Persistence API). Wśród problemów, które można napotkać przy korzystaniu z ORM

wskazuje on na inne systemy typów używany przez język

programowania i przez bazę danych [3]. Ważna jest więc obecność automatycznego mapowania pomiędzy najczęściej spotykanymi typami.

Szereg artykułów omawia porównanie wydajnościowe. Artykuł „A Comparative Study of the features and Performance of ORM Tools in a .NET Environment” obejmuje porównanie narzędzi ORM na platformę .NET.

Porównywane są Entity Framework oraz NHibernate.

Kryterium porównania jest czas wykonywania różnych operacji Select, Insert oraz Delete [4]. Dodatkowo wskazane

zostały również wady i zalety nauki narzędzi ORM.

W artykule „Mobile Data Store Platforms: test Case based

Performance Evaluation” autorstwa K. Kussainova i B. Kumalakova dokonano porównania 3 technologii mobilnych: Realm, SnappyDB oraz API Androida. Porównano jest pod względem operacji zapisywania – tworzono 10000

rekordów – jak i odczytywania – tworzono zapytania

odczytujące 12000 rekordów [5].

Ciekawe spojrzenie na temat zawiera artykuł „Understanding the Energy, Performance, and Programming Effort Trade-offs of Android Persistence Frameworks”. W artykule tym również zbadano wydajność operacji Insert oraz Select, poprzez zmierzenie czasu wykonywania.

Dodatkowo jednak zbadano również operacje Update i Delete,

oraz dodano badanie wpływu tych operacji przy zastosowaniu różnych ORM na konsumpcję energii urządzenia [6].


43

Artykuł „Comparing the Performance of Object Databases and ORM Tools” chociaż nie dotyczy bezpośrednio technologii na platformę Android, zawiera porównanie bibliotek ORM dla języka Java. Przedmiotem porównania są czas tworzenia obiektów oraz czas wykonywania zapytania

wydobywającego odpowiednie rekordy. To drugie porównanie wykorzystuje szereg różnych zapytań: wykorzystujących operację złączenia tabel, relacje pomiędzy tabelami oraz porównania. W artykule sprawdzono również wpływ tzw. gorących i zimnych startów aplikacji na czas wykonywania poszczególnych zadań [7].

„The Usage and performance of Object Databases

compared with ORM tools in a Java environment” autorstwa

Mikalea Kopteff porównuje technologie Versant I Hibernate.

Technologie porównano te pod względem szybkości wykonywania zapytań jak i sposobu połączenia z bazą oraz tworzenia transakcji. Pokazano również jak wygląda mapowanie klasy przy użyciu plików XML [8].

“Performance Evaluation of Java Based Object Relational

Mapping Tools” to kolejny artykuł porównujący biblioteki mapowania relacyjno obiektowego dla języka Java. Porównane zostały takie technologie jak Hibernate, TopLink oraz Ebean. Oprócz porównania czasu wykonywania różnych zapytań, jak w wyżej wymienionych artykułach, praca ta analizuje również języki zapytań jakie dostarcza każda z badanych technologii [9].

W artykule „Energy Efficiency of ORM Approaches:

an Empirical Evaluation” zbadano czas wykonywania

podstawowych operacji bazodanowych przez technologie

Propel i TinyQueries, takich jak odczyt, zapis, aktualizacja

i usuwanie rekordów. Drugim kryterium była dodatkowo

konsumpcja energii jaką potrzebuje urządzenie, aby wykonać

poszczególne operacje [10].

3. Badane technologie

Na potrzeby artykułu zbadano 6 różnych bibliotek, które podzielić można na 3 kategorie:

1) Biblioteki mapowania obiektowo – relacyjnego

używające SQLite GreenDAO OrmLite DBFlow SugarORM

2) Biblioteka mapowania obiektowo – relacyjnego oparta

o własny typ plików Realm

3) Rozszerzona warstwa bazodanowa SquiDB

Wprawdzie Realm nie jest oparty o SQLite, jednak jego

wsparcie zarówno dla Androida, jak i iOS [11] pozwala na wygodniejsze tworzenie wieloplatformowej aplikacji.

Natomiast SquiDB jest przedstawiana przez twórców nie jako pełnoprawny ORM, ale jako warstwa rozszerzająca możliwości SQLite. SquiDB ma na celu przede wszystkim

zachowanie elastyczności związanej z bezpośrednim używaniem SQL[12].

4. Środowisko testowe

Do testów wykorzystano telefon Xiaomi Redmi Note z systemem operacyjnym Android 7.1.1

4.1. Badane technologie

Technologie zostały użyte w następujących wersjach:

GreenDAO 3.2.0 OrmLite 5.0 DBFlow 4.0.0-beta5 SugarORM 1.5 Realm 3.0.0. SquiDB 4.0.0-beta.1

4.2. Projekt testowy

Aby porównać technologie, dla każdej z nich utworzono oddzielny projekt. Każdy z projektów zawierał 3 klasy modelu:

Book, zawierającą informacje o książce Author, zawierającą informacje o autorze książki Publisher, zawierającą informacje o wydawcy książki Owner, zawierającą informacje o właścicielu wydawnictwa.

Klasy połączone zostały relacjami. Book i Publisher

połączone zostały relacją jeden do wielu (jeden wydawca może wydać wiele książek). Author i Book połączone zostały relacją wiele do wielu (książka może być napisana przez wielu autorów, autor może napisać wiele książek). Klasy Owner

i Publisher łączy relacja jeden do jednego. Schemat takiej

bazy danych zawarty jest na rysunku 1.

Klasy zawierają atrybuty o różnych typach. Celem jest zbadanie, czy są one automatycznie mapowane na typy bazodanowe, czy konwersja musi zostać wykonana ręcznie. Badane typy to:

typy proste (int, boolean itd.) typy boxed (Integer, Boolean itd.) String Date List.

Rys 1. Relacje pomiędzy encjami.


44

Ponadto utworzono typ wyliczeniowy Genre, opisujący gatunek książki, i sprawdzono czy jest on automatycznie mapowany na typ bazodanowy. Jeśli nie, wskazano sposób jak takie mapowanie wykonać.

5. Analiza wyników

W technologiach ORM na klasy można mapować tabele najczęściej na 3 sposoby:

poprzez adnotacje, poprzez dziedziczenie dostarczanej klasy, poprzez pliki XML

Pierwsze badanie objęło sprawdzenie, jakie sposoby mapowania umożliwiały badane technologie. Wyniki

zamieszczono w tabeli 1.

Tabela 1. Sposób mapowania klas na tabele bazy danych

Adnotacja Dziedziczenie XML

GreenDAO Wymagana Nie Nie

OrmLite Wymagana Nie Nie

DBFlow Wymagana Możliwe Nie

SugarORM Nie Wymagane Nie

Realm Możliwe Możliwe Nie

SquiDB Wymagana Wymagane Nie

Spośród wszystkich technologii jedynie Realm zapewniało elastyczność wyboru pomiędzy adnotacją, a dziedziczeniem. Mapowanie poprzez adnotację wymagało również implementacji interfejsu RealmModel.

DBFlow wymaga adnotowania mapowanych klas,

ale zapewnia również możliwość dziedziczenia po klasie BaseModel. Pozwala to na wygodne wykonywanie poleceń (save, delete i innych) poprzez wywołanie ich wprost na obiekcie. W przypadku, gdy klasa BaseModel nie jest

dziedziczona, wywołanie takich metod następuje poprzez adapter.

OrmLite i GreenDAO umożliwiają jedynie adnotowanie mapowanej klasy. Obsługa poleceń wykonywana jest poprzez obiekt DAO, który wykonuje wszystkie operacje związane z rekordami.

SugarORM wymaga dziedziczenia klasy SugarRecord.

Wymagane dziedziczenie ogranicza elastyczność aplikacji, niemożliwe jest dziedziczenie klasy modelu po innej klasie nadrzędnej.

Ciekawe rozwiązanie zastosowane jest w SquiDB. Do mapowania wykorzystywana jest oddzielna klasa,

adnotowana poprzez @TableModelSpec. Następnie generator kodu generuje klasę reprezentującą wiersz w tabeli lub wiersz widoku. Klasa reprezentująca wiersz tabeli dziedziczy po TableModel, a klasa reprezentująca wiersz widoku po ViewModel. Obie klasy dziedziczą po klasie AbstractModel. Rozwiązanie to pozwala na elastyczność w przypadku klasy adnotowanej (może ona dziedziczyć po innej klasie) i jednocześnie ułatwia wykonywanie operacji poprzez generowane klasy.

Co ciekawe, żadna z technologii nie umożliwia mapowania poprzez pliki XML. Jest to zaskoczenie, gdyż najpopularniejszy ORM dla języka Java, Hibernate [13], zapewnia taką możliwość. Pozwala to na całkowite oddzielenie kodu mapującego od klasy modelu, przez co nie jest ona zanieczyszczona niepotrzebnym kodem.

Drugie badanie miało na celu sprawdzenie dostępności adnotacji konfigurujących. Wyniki zostały zawarte w tabeli 2.

Tabela 2. Dostępność adnotacji konfigurujących

Tabela Id Kolumny Jeden

do

jednego

Jeden

do

wielu

Wiele

do

wielu

GreenDAO Tak Tak Tak Tak Tak Tak

OrmLite Tak Tak Tak Tak Tak Nie

DBFlow Tak Tak Tak Tak Tak Tak

SugarORM Nie Nie Nie Nie Nie Nie

Realm Tak Nie Nie Nie Nie Nie

SquiDB Tak Tak Tak Nie Nie Nie

Brak danej adnotacji nie przesądza jednak o braku funkcjonalności. Używając ORMLite i DBFlow należy zaznaczyć adnotacją, które z atrybutów mają być mapowane, pozostałe są zaś ignorowane. Odwrotna sytuacja jest w przypadku Realm, SugarORM, SquiDB i GreenDAO:

w tych technologiach adnotacją należy oznaczyć te pola, które mają zostać zignorowane. Adnotacje oznaczające kolumny w GreenDAO i SquiDB pozwalają na dodatkowe określenie parametrów np. nazwa pola w bazie danych.

Realm wprawdzie nie posiada adnotacji do oznaczania

relacji, jednak są one możliwe do wykonania. Wystarczy ustawić obiekt lub listę obiektów (RealmList) jako parametr

klasy, a odwzorowane zostanie połączenie jeden do jednego, jeden do wielu lub wiele do wielu. Podobnie zachowuje się SugarORM. SquiDB nie posiada adnotacji, które ułatwiłyby modelowanie relacji, nie tworzy też tych relacji automatycznie. Proponowanym przez autorów rozwiązaniem [12] jest przechowywanie identyfikatora rekordu, z którym aktualny rekord jest związany i użycie ModelMethod lub

funkcji pomocniczych. Mają one wywołać odpowiednie zapytanie na bazie danych.

GreenDAO, OrmLite i DBFlow posiadają adnotacje wspomagające tworzenie relacji wiele do wielu. Wszystkie osiągają ten efekt poprzez klasę mapowaną na tabelę pośredniczącą. DBFlow sam automatycznie generuje taką klasę, pozostałe technologie wymagają od programisty utworzenia takich klas samodzielnie.

Spośród wybranych technologii tylko SugarORM nie pozwala na oznaczenie encji poprzez adnotację i wymaga dziedziczenia po klasie SugarRecord<T>.

Ostatnie badanie dotyczyło mapowania typów z języka Java na języki bazodanowe. Wyniki badania przedstawiono

w tabeli 3.


45

Wsparcie dla typów prostych, typów boxed, String i Date jest podstawowym wymaganiem w stosunku do ORM

i wszystkie wybrane technologie obsługują takie mapowania.

Tabela 3. Typy Java mapowane na typy bazodanowe

Typy

proste

Typy

boxed String Date List Enum

GreenDAO Tak Tak Tak Tak Nie Nie

OrmLite Tak Tak Tak Tak Nie Tak

DBFlow Tak Tak Tak Tak Nie Tak

SugarOR

M Tak Tak Tak Tak Nie Tak

Realm Tak Tak Tak Tak Nie Nie

SquiDB Tak Tak Tak Tak Nie Tak

Problem następuje w przypadku próby mapowania prostej listy, gdyż takiego mapowania nie wykonuje żadne z narzędzi – mapowane są tylko listy innych encji. Rozwiązaniem tego problemu może być przekształcanie listy do postaci JSON a następnie umieszczanie takiego ciągu znaków w bazie danych jako varchar. Nie pozwala to jednak na wygodne

przeszukiwanie tak zapisanych informacji w bazie danych.

Nie wszystkie technologie automatycznie mapują typ wyliczeniowy (enum) do bazy danych. Najlepiej wywiązuje się z tego OrmLite, który pozwala zarówno na mapowanie

enum jako tekstu (varchar) jak i mapowania ordinal [14] –

unikatowego numeru danego elementu typu wyliczeniowego.

Automatyczne mapowanie wykonują również SugarORM, SquiDB oraz DBFlow.

Dokumentacje pozostałych technologii wskazują jednak na rozwiązanie takiego problemu. GreenDAO proponuje utworzenie konwertera [15] (przykład 1), a w Realm rozwiązaniem jest zapisywanie typu wyliczeniowego jako String (przykład 2).

Przykład 1. Mapowanie typu wyliczeniowego w GreenDAO

@Entity public class User { @Id private Long id; @Convert(converter = RoleConverter.class, columnType =

String.class) private Role role; enum Role { DEFAULT, AUTHOR, ADMIN } static class RoleConverter implements PropertyConverter<Role, String> { @Override public Role convertToEntityProperty(String databaseValue) { return Role.valueOf(databaseValue); } @Override

public String convertToDatabaseValue(Role entityProperty) { return entityProperty.name(); }}}

Realm proponuje rozwiązanie podobne do tego, jakie OrmLite wykonuje automatycznie, czyli konwertowanie enum

do String i przechowywanie jako varchar.

Przykład 2. Mapowanie typu wyliczeniowego w Realm

public enum MyEnum { FOO, BAR; } public class Foo extends RealmObject { private String enumDescription; public void saveEnum(MyEnum val) { this.enumDescription = val.toString(); } public MyEnum getEnum() { return MyEnum.valueOf(enumDescription);}}

6. Wnioski

Przy wyborze odpowiedniego ORM warto sprawdzić, czy udostępnia on odpowiednie możliwości.

Programiści używający Hibernate w projektach Java docenią GreenDAO i OrmLite. Technologie te bardzo

przypominają Hibernate. Udostępniają konfigurację poprzez adnotację, wspierają wszystkie podstawowe typy (chociaż w przypadku GreenDAO mapowanie enum trzeba wykonać samodzielnie). Umożliwiają również łatwe mapowanie relacji. GreenDAO zapewnia taka możliwość dla wszystkich typów relacji – 1:1, 1:n, n:m – a OrmLite pozwala na osiągnięcie efektu relacji n:m poprzez samodzielne stworzenie tabeli

pośredniczącej.

Atrakcyjnym wyborem jest również DBFlow, które oprócz możliwości dostarczanych przez dwie wcześniej wspomniane technologie zapewnia również możliwość dziedziczenia encji po specjalnej klasie. Ta specjalna klasa powoduje,

że ułatwione jest wykonywanie operacji CRUD (Create Read Update Delete), gdyż wywoływane są one z obiektu –

niepotrzebna jest specjalna klasa DAO.

Alternatywą dla wymienionych bibliotek może być Realm. Nie zapewnia on wprawdzie tak bogatej gamy adnotacji,

jednak w tym przypadku są one zbędne. Realm sam wykrywa atrybuty do mapowania (tylko te niepotrzebne należy ignorować) i łączy tabele relacjami, jeśli atrybutem encji jest inna encja lub lista encji. Zaletą jest również wieloplatformowość – z tego ORM można skorzystać zarówno na systemie Android jak i iOS.

SugarORM jest zdecydowanie najmniej atrakcyjna opcją. Wymaga dziedziczenia, brakuje mu mechanizmu mapowania

enum, jego lista adnotacji jest bardzo uboga. Jest to ORM,

który może mieć zastosowanie najwyżej przy prostych projektach, gdyż brakuje mu zalet pozostałych produktów.

W oddzielnej kategorii można sklasyfikować SquiDB. Jest to technologia o szerokich możliwościach, ale wymaga większych nakładów pracy. Pomimo, że nie zapewnia mechanizmu mapowania relacji, to umożliwia wykonanie takiego mapowania samodzielnie, dzięki czemu programista ma kontrolę nad mechanizmem od jego początku, do końca.

Literatura

[1] http://www.gartner.com/newsroom/id/3609817 Gartner Says

Worldwide Sales of Smartphones Grew 7 Percent in the Fourth

Quarter of 2016 [15.02.2017]


46

[2] https://developer.android.com/reference/android/database/sqlite

/SQLiteDatabase.html SQLiteDatabase [20.05.2017]

[3] Z. Rosiek, Mapowanie obiektowo relacyjne (ORM) – czy tylko

dobra idea?, Zeszyty Naukowe Warszawskiej Wyższej Szkoły Informatyki, nr 4, 2010.

[4] S. Cvetković, D. Janković, A Comparative Study of the Features and Performance of ORM Tools in a .NET

Environment, W: Dearle A., Zicari R.V. (eds) Objects and

Databases. ICOODB 2010. Lecture Notes in Computer Science,

vol 6348. Springer, Berlin, Heidelberg.

[5] K. Kussainov, B. Kumalakov, Mobile Data Store Platforms:

Test Case based Performance Evaluation, 8th International Joint

Conference on Knowledge Discovery, Knowledge Engineering

and Knowledge Management, At Porto, Portugal, Volume: 3.

[6] J. Pu, Z. Song, E. Tilevich, Understanding the Energy,

Performance, and Programming Effort Trade-Offs of Android

Persistence Frameworks, 2016 IEEE 24th International

Symposium on Modeling, Analysis and Simulation

of Computer and Telecommunication Systems (MASCOTS).

[7] P. Van Zyl, D.G. Kourie, A. Boake, Comparing the

Performance of Object Databases and ORM Tools, Proceeding

of South African Institute for Computer Scientists and

Information Technologists, 1-11, 2006.

[8] . M. Kopteff, “The usage and performance of object databases compared with orm tools in a java environment.” [Online].

http://www.odbms.org/wp-content/uploads/2013/11/045.01-

Kopteff-TheUsage-and-Performance-of-Object-Databases-

Compared-with-ORM-Tools-ina-Java-Environment-March-

2008.pdf.

[9] S.N. Bhatti, Z.H. Abro, F. Rufabro, Performance Evaluation of

Java Based Object Relational Mapping Tools, Mehran

University Research Journal of Engineering and Technology,

32(2):159--166, 2013.

[10] G. Procaccianti, P. Lago, W. Diesveld, Energy Efficiency of

ORM Approaches: an Empirical Evaluation, Proceeding ESEM

'16 Proceedings of the 10th ACM/IEEE International

Symposium on Empirical Software Engineering and

Measurement.

[11] https://realm.io/products/realm-mobile-database/ Realm Mobile

Database [20.05.2017]

[12] https://github.com/yahoo/squidb Oficjalna strona projektu

SquiDB [10.07.2017]

[13] https://blogs.oracle.com/theaquarium/dzone-survey-shows-jpa-

dominates-java-persistence DZone Survey Shows JPA

Dominates Java Persistence [23.10.2015]

[14] http://ormlite.com/javadoc/ormlite-core/doc-

files/ormlite_2.html#Persisted-Types Dokumentacja OrmLite,

Persisted Data Types [15.09.2017]

[15] http://greenrobot.org/greendao/documentation/custom-types/

Dokumentacja GreenDAO, Custom Types [15.09.2017].

JCSI 6 (2018) 47-54



47

Analiza porównawcza wybranych szkieletów służących do wstrzykiwania zależno ci

Rafał Szewczyk*, Małgorzata Plechawska-Wójcik*


Streszczenie. Artykuł przedstawia analizę porównawczą wybranych szkieletów do wstrzykiwania zależno ci w języku Java. Analiza polega na porównaniu szybko ci działania frameworków w różnych konfiguracjach. Dla każdej technologii została stworzona osobna aplikacja, a wyniki

badań zostały przedstawione w formie wykresów i tabel.

Słowa kluczowe: dependency-injection; ioc; java


Adres e-mail: [email protected], [email protected]

Comparative analysis of selected skeletons for dependency injection

Rafał Szewczyk*, Małgorzata Plechawska-Wójcik*


Abstract. The article presents a comparative analysis of selected skeletons for dependency injection in Java. The analysis consists in comparing

the speed of the frameworks in different configurations. For each technology has been created a separate application, and the results are

presented in graphs and tables.

Keywords: dependency-injection; ioc; java


E-mail address: [email protected], [email protected]

1. Wstęp

W dzisiejszych czasach wiele firm decyduje się na zmianę swoich statycznych stron internetowych na nowoczesne

aplikacje. Jest to podyktowane coraz większymi oczekiwaniami klientów korzystających z takich serwisów

[1]. Dodatkowo dzięki nim obsługa witryn staje się efektywniejsza [2]. Użytkownicy oczekują coraz szybszych programów, co spowodowało dynamiczny rozwój narzędzi do

budowy takich projektów [3]. Decydując się na korzystanie z takiej aplikacji należy wybrać odpowiednią technologię, tak aby zapewnić ich sprawne działanie oraz wygodę korzystania dla użytkowników.

Celem artykułu jest porównanie wybranych szkieletów

służących do wstrzykiwania zależno ci. Ich analiza została przeprowadzona ze względu na to, że wstrzykiwanie zależno ci jest fundamentalnym składnikiem działania takich aplikacji [4], a w sieci istnieją jedynie opisy poszczególnych technologii pomijające aspekty wydajno ciowe [5][6][7].

Dodatkowo w publikacji zostanie sprawdzona teza, że aplikacje tworzone w oparciu o najbardziej rozbudowaną bibliotekę, mają znaczną przewagę nad autorskimi projektami wspierającymi wstrzykiwanie zależno ci.

2. Wstrzykiwanie zależno ci

Wstrzykiwanie zależno ci jest to wzorzec projektowy wykorzystywany w aplikacjach internetowych [8]. Polega na

tworzeniu modułowych programów bez bezpo rednich

zależno ci pomiędzy komponentami. Jest implementacją zasady odwróconego sterowania (IoC), która polega na tworzeniu oraz wiązaniu obiektów poza kodem aplikacji. Jest

to realizowane za pomocą poszczególnych bibliotek, które dzięki wykorzystaniu specjalnego kontenera zapewniają im

cały cykl życia [9]. Zastosowanie tego wzorca niesie za sobą wiele korzy ci [10]. Przede wszystkim ułatwia budowę takich programów, poprawia możliwo ci dalszej rozbudowy oraz

utrzymania. Dodatkowo jest możliwo ć łatwiejszego testowania poszczególnych funkcjonalno ci poprzez

modularną strukturę oraz wyeliminowanie bezpo rednich zależno ci [11].

3. Przebieg badań

3.1. rodowisko testowe

Do przeprowadzenia testów wydajno ciowych posłużono się laptopem Lenovo Y50-70 z procesorem Intel Core i7

4770HQ oraz 8GB pamięci RAM.

3.2. Badane technologie

Biblioteki użyte do testów Ś

Spring (w wersji 5.0.0.RC3) – kompleksowe narzędzie do budowy aplikacji internetowych. Jest to jedna

z najpopularniejszych technologii [6],


48

Google Guice (w wersji 4.1.0) – framework

zaprojektowany na podstawie Spring’a. Jednak skupiony

na wstrzykiwaniu zależno ci [5], PicoContainer (w wersji 2.15) – jest to technologia

zapewniająca wsparcie dla metodyki wstrzykiwania

zależno ci. Jest mniej popularna od powyższych narzędzi [7], Weld (w wersji 3.0.1.Final) – rozbudowana technologia

firmy JBoss. Posiada bogaty zestaw narzędzi do tworzenia aplikacji internetowych [12], EasyDI (w wersji 0.3.0) – mała biblioteka przeznaczona do projektów wykorzystujących wstrzykiwanie

zależno ci. Ze względu na prosty kontener przeznaczona

dla małych aplikacji [13], SilkDI (w wersji 0.6) – autorski projekt programisty Jana

Bernitt’a. Stworzony w celu zwiększenia prostoty użycia oprogramowania poprzez zmniejszenie ilo ci konfiguracji [14].

3.3. Projekt aplikacji

Aby porównać technologie przedstawione w rozdziale 3.2,

dla każdej z nich została stworzona oddzielna aplikacja.

Każdy z projektów wykorzystywał 4 wzajemnie powiązane klasy:

Car – klasa zawierająca informacje o samochodzie, Owner – klasa zawierająca informacje o posiadaczu samochodu, CarShop – klasa zawierająca informacje o komisie

samochodowym, Operator – klasa reprezentująca posiadacza komisu.

Klasy zostały połączone relacjami. Owner i CarShop

zostały połączone relacją jeden do wielu (w komisie może być wielu posiadaczy samochodów). Podobnie zostały połączone klasy Car i CarShop (w komisie może być wiele samochodów). Analogicznie zostały powiązane klasy Operator i CarShop (jeden wła ciciel może posiadać wiele komisów). Diagram klas takiej aplikacji został przedstawiony na rysunku 1.

Rys. 1. Diagram klas użytych w programie

3.4. Metody badawcze

Do porównania frameworków przeprowadzono badania

składające się z dwóch etapów - pomiaru czasu startu

kontenera oraz wstrzykiwania obiektów o różnej złożono ci w ramach działania pojedynczego programu. Czas uzyskany

z poszczególnych eksperymentów został przedstawiony w milisekundach, a wyniki zostały zgromadzone w tabelach oraz na wykresach.

Ponadto pomiary zostały zrealizowane dla dwóch zakresów widoczno ci obiektówŚ

singleton - za każdym razem wstrzykiwana ta sama

instancja obiektu, prototype – za każdym razem wstrzykiwany nowy obiekt.

Aby szczegółowo porównać zachowanie technologii

podczas wstrzykiwania zależno ci wykorzystano obiekty

o różnej strukturze:

obiekt klasy Car, obiekt klasy Operator zawierający 100 obiektów CarShop, obiekt klasy Operator zawierający 10000 obiektów CarShop, obiekt klasy Operator zawierający 100000 obiektów CarShop.

Dodatkowo w celu uwidocznienia różnic między technologiami, podczas porównań wykorzystywanym obiektom zostały przypisane wagi według przyjętej specyfikacji:

obiekt klasy Car – waga 10 %, obiekt klasy Operator zawierający 100 obiektów CarShop – waga 20 %, obiekt klasy Operator zawierający 10000 obiektów CarShop – waga 30 %, obiekt klasy Operator zawierający 100000 obiektów CarShop – waga 40 %.

Najwyższa pozycja w rankingu oznacza, że czas wstrzykiwania obiektów w okre lonej technologii był najdłuższy. Ponadto najlepsze wyniki zostały oznaczone kolorem zielonym, a najgorsze kolorem czerwonym.

Aby rezultaty otrzymane z przeprowadzonych

eksperymentów były jak najbardziej zbliżone do siebie, to w wszystkich aplikacjach skorzystano z tej samej metody

wstrzykiwania zależno ci (została użyta metoda wstrzykiwania przez pola klasy). Wyeliminowało to konieczno ć uruchamiania przez kontener dodatkowych metod (np. metod ustawiających).

4. Analiza wyników

4.1. Czas startu kontenera

Pierwszy etap testów składał się z pomiaru czasu, jaki niezbędny jest do uruchomienia kontenera zawierającego używane obiekty w poszczególnych technologiach.

Eksperyment 1

Eksperyment pierwszy polegał na pomiarze czasu startu

kontenera dla obiektów w zakresie Singleton podczas pierwszego uruchomienia programu. Rezultaty umieszczono

w tabeli 1.


49

Tabela 1. Czas pierwszego uruchomienia kontenera, zakres singleton [ms]

Car Operator

(100

obiektów CarShop)

Operator

(1000

obiektów CarShop)

Operator

(100000

obiektów CarShop)

Czas wykonania [ms]

Spring 449,00 447,00 460,00 938,00

Google Guice 353,00 203,43 205,80 202,10

PicoContainer 31,12 32,44 36,01 31,99

Weld 661,00 642,00 631,00 621,00

EasyDI 3,34 3,53 3,64 3,24

Silk DI 52,20 54,93 55,26 51,79

Z przeprowadzonych badań wynika, że czasy startu

kontenera w każdej z technologii znacznie się od siebie

różnią. Ponadto widać, że w zakresie widoczno ci Singleton na start kontenera nie ma wpływu ilo ć używanych obiektów. Aby precyzyjnie porównać technologie sporządzono ich ranking za pomocą wag opisanych w rozdziale 3.4, a rezultaty

zamieszczono w tabeli 2.

Tabela 2. Ranking technologii na podstawie czasu pierwszego uruchomienia

kontenera, zakres singleton

Pozycja w rankingu

Spring 1

Google Guice 3

PicoContainer 5

Weld 2

EasyDI 6

Silk DI 4

Dzięki takiemu zestawieniu wyników widać znaczną przewagę lekkich bibliotek w tym eksperymencie. Najlepsze

rezultaty osiągnęła biblioteka EasyDI, a najgorsze Weld. Dodatkowo bazując na osiągniętych czasach można

wyróżnić 2 grupy frameworków w kolejno ci od najgorszych do najlepszych:

1) Spring, Weld oraz Google Guice,

2) Silk DI, PicoContainer, oraz EasyDI, które są znacznie mniej rozbudowanymi technologiami.

Wyniki pierwszego eksperymentu zostały przedstawione na wykresie 1.

0

100

200

300

400

500

600

700

800

900

1000

Spring Google Guice PicoContainer Weld EasyDI Silk DICarOperator obiektów CarShopOperator obiektów CarShopOperator obiektów CarShop

Cza

s [m

s]

Wykres 1. Czas pierwszego uruchomienia kontenera, zakres singleton

Eksperyment 2

Kolejny eksperyment polegał na pomiarze czasu startu

kontenera dla obiektów o zakresie Singleton podczas 500 kolejnych uruchomień programu. U rednione wyniki zostały zawarte w tabeli 3.

Tabela 3. redni czas uruchomienia kontenera, zakres singleton

Car Operator

(100

obiektów CarShop)

Operator

(1000

obiektów CarShop)

Operator

(100000

obiektów CarShop)

Czas wykonania [ms]

Spring 10,64 10,44 10,83 62,59

Google Guice 0,85 0,46 0,48 0,46

PicoContainer 0,09 0,10 0,09 0,10

Weld 15,82 14,43 15,56 15,24

EasyDI 0,02 0,01 0,01 0,01

Silk DI 0,18 0,19 0,18 0,18

Również w tym przypadku widać, że występują znaczne różnice między czasami. Jednak w przypadku kolejnych

uruchomień programu są to zdecydowanie lepsze wyniki. Na

podstawie rezultatów z tabeli 3 został stworzony ranking, który przedstawia tabela 4. wiadczy on o przewadze mniej rozbudowanych technologii.

Tabela 4. Ranking technologii na podstawie redniego czasu uruchomienia kontenera, zakres singleton

Pozycja w rankingu

Spring 1

Google Guice 3

PicoContainer 5

Weld 2

EasyDI 6

Silk DI 4

Wyniki drugiego eksperymentu zostały przedstawione na wykresie 2.

0

10

20

30

40

50

60

70


Cza

s [m

s]

Wykres 2. redni czas uruchomienia kontenera, zakres singleton

Eksperyment 3

Eksperyment trzeci polegał na pomiarze czasu startu kontenera dla obiektów w zakresie Prototype podczas


50

pierwszego uruchomienia programu. Rezultaty zostały zamieszczone w tabeli 5.

Tabela 5. Czas pierwszego uruchomienia kontenera, zakres prototype

Car Operator

(100

obiektów CarShop)

Operator

(1000

obiektów CarShop)

Operator

(100000

obiektów CarShop)

Czas wykonania [ms]

Spring 402,00 433,00 413,00 447,00

Google Guice 228,06 232,53 261,26 200,21

PicoContainer 26,49 25,40 27,26 26,45

Weld 773,00 649,00 596,00 640,00

EasyDI 3,70 4,10 3,39 2,32

Silk DI 56,87 54,78 53,71 54,22

Ponownie można zaobserwować znaczne różnice pomiędzy poszczególnymi technologiami. Dodatkowo

okazało się, ze na start kontenera nie ma wpływu zakres widoczno ci używanych obiektów, ani ich liczba. Na

podstawie rezultatów z tabeli 5 został stworzony ranking,

który przedstawia tabela 6.

Tabela 6. Ranking technologii na podstawie pierwszego uruchomienia

kontenera, zakres prototype

Pozycja w rankingu

Spring 2

Google Guice 3

PicoContainer 5

Weld 1

EasyDI 6

Silk DI 4

Tu także lepsze w rankingu są małe biblioteki, które są wydajniejsze od rozbudowanych technologii. Rezultaty tego

eksperymentu zostały przedstawione na wykresie 3.

0

100

200

300

400

500

600

700

800


Cza

s [m

s]

Wykres 3. Czas pierwszego uruchomienia kontenera, zakres prototype

Eksperyment 4

Eksperyment czwarty polegał na pomiarze czasu startu

kontenera dla obiektów o zakresie Prototype podczas 500 kolejnych uruchomień programu. Wyniki osiągnięte z tego eksperymentu zostały u rednione, a następnie umieszczone w tabeli 7.

Tabela 7. redni czas uruchomienia kontenera, zakres prototype

Car Operator

(100

obiektów CarShop)

Operator

(1000

obiektów CarShop)

Operator

(100000

obiektów CarShop)

Czas wykonania [ms]

Spring 14,74 17,88 31,67 32,38

Google Guice 0,50 0,46 0,44 0,46

PicoContainer 0,07 0,07 0,06 0,06

Weld 15,40 21,26 41,56 51,00

EasyDI 0,01 0,01 0,02 0,02

Silk DI 0,17 0,29 0,34 0,33

Tak samo jak w przypadku eksperymentu 2 czasy są zdecydowanie lepsze niż podczas pierwszego uruchomieniu

programu. wiadczy to o konieczno ci załadowania obiektów do kontenera podczas pierwszej iteracji.

W tabeli 8 umieszczono ranking technologii na podstawie

osiągniętych czasów.

Tabela 8. Ranking technologii na podstawie redniego czasu uruchomienia kontenera, zakres prototype

Pozycja w rankingu

Spring 2

Google Guice 3

PicoContainer 5

Weld 1

EasyDI 6

Silk DI 4

Podobnie jak w poprzednich eksperymentach lekkie

biblioteki osiągają lepszą wydajno ć w porównaniu do bardziej rozbudowanych technologii. Wyniki czwartego

eksperymentu zostały przedstawione na wykresie 4.

0

10

20

30

40

50

60


Cza

s [m

s]

Wykres 4. redni czas uruchomienia kontenera, zakres prototype

Podsumowanie etapu pierwszego

Porównanie wyników eksperymentów z etapu 1 zostało wykonane poprzez u rednienie pozycji poszczególnych technologii w rankingach z tego etapu. Przedstawia je

tabela 9.


51

Tabela 9. Ranking technologii na podstawie redniej pozycji w wszystkich

eksperymentach z etapu 1

Pozycja w rankingu

Spring 1

Google Guice 3

PicoContainer 5

Weld 1

EasyDI 6

Silk DI 4

Takie zestawienie wyników ostatecznie potwierdza zasadno ć używania mniej rozbudowanych technologii

w aspekcie krótkiego czasu startu kontenera. Stosunkowo

długie czasy bardziej rozbudowanych technologii mogą być związane z konieczno cią wykonywania dodatkowych akcji przed uruchomieniem kontenera.

4.2. Czas wstrzykiwania zależno ci

Drugi etap testów składał się z pomiaru czasu, jaki potrzebny jest do wstrzyknięcia okre lonej liczby obiektów w poszczególnych technologiach.

Eksperyment 5

Piąty eksperyment polegał na pomiarze czasu jaki

niezbędny jest do wstrzyknięcia okre lonej liczby obiektów o zakresie Singleton podczas pierwszego uruchomienia

programu. Tabela 10 prezentuje otrzymane wyniki.

Tabela 10. Czas pierwszego wstrzyknięcia po zainicjowaniu kontenera, zakres singleton

Car Operator

(100

obiektów CarShop)

Operator

(1000

obiektów CarShop)

Operator

(100000

obiektów CarShop)

Czas wykonania [ms]

Spring 0,0006 0,0007 0,0007 0,0007

Google Guice 0,0688 0,0424 0,3296 2,8463

PicoContainer 0,0595 0,1515 0,5575 3,5203

Weld 0,1280 0,1834 0,6041 3,8999

EasyDI 0,2836 0,2279 0,6022 3,7230

Silk DI 0,0064 0,0344 0,3359 3,0075

W etapie drugim wyniki ponownie charakteryzują się dużym zróżnicowaniem. Dodatkowo widać, że ilo ć wstrzykiwanych obiektów ma niewielki wpływ na rezultaty

tego eksperymentu. Ranking uwidaczniający różnice

pomiędzy technologiami przedstawia tabela 11.

Tabela 11. Ranking technologii na podstawie czasu pierwszego

wstrzyknięcia, zakres singleton

Pozycja w rankingu

Spring 6

Google Guice 5

PicoContainer 3

Weld 1

EasyDI 2

Silk DI 4

W tym przypadku na najlepszą pozycję wysunęła się najbardziej rozbudowana technologia. Jest to odmienna

sytuacja w stosunku do poprzednich eksperymentów, gdzie bezkonkurencyjne były małe biblioteki. wiadczy to o dobrze

zaprojektowanym kontenerze, który charakteryzuje się większą wydajno cią podczas inicjalizacji obiektów. Na

podstawie wyników technologie zostały podzielone na 3 grupy w kolejno ci od najgorszych do najlepszych:

3) Weld, EasyDI,

4) PicoContainer, Silk DI oraz Google Guice, które są głównie mniej rozbudowanymi technologiami,

5) Spring.

Wyniki piątego eksperymentu zostały przedstawione na wykresie 5.

0

0,5

1

1,5

2

2,5

3

3,5

4

Spring Google Guice PicoContainer Weld EasyDI Silk DI

CarOperator obiektów CarShopOperator obiektów CarShopOperator obiektów CarShop

Cza

s [m

s]

Wykres 5. Czas pierwszego wstrzyknięcia po zainicjowaniu kontenera, zakres

singleton

Eksperyment 6

Kolejny eksperyment polegał na wstrzyknięciu okre lonej liczby obiektów o zakresie Singleton podczas kolejnych 500 prób uruchomień programu. Jego wyniki zostały zgromadzone w tabeli 12.

Tabela 12. redni czas wstrzyknięcia jednego obiektu, zakres singleton

Car Operator

(100

obiektów CarShop)

Operator

(1000

obiektów CarShop)

Operator

(100000

obiektów CarShop)

Czas wykonania [ms]

Spring 0,000052 0,000054 0,000054 0,000071

Google Guice 0,000074 0,000077 0,000069 0,000069

PicoContainer 0,000021 0,000025 0,000028 0,000023

Weld 0,000746 0,000817 0,000704 0,000851

EasyDI 0,000023 0,000029 0,000026 0,000025

Silk DI 0,000052 0,000054 0,000054 0,000056

Ponownie zauważono znaczne różnice między czasami. Porównując tabele 10 z tabelą 12 można zauważyć, że kolejne wstrzyknięcia są zdecydowanie szybsze. wiadczy to o tym, że podczas pierwszego użycia obiekty muszą być zainicjalizowane. Na podstawie rezultatów z tabeli 12 został stworzony ranking, który przedstawia tabela 13.

Dodatkowo wykonano następujący podział technologii ze względu na otrzymane czasy w kolejno ci od najgorszych do najlepszych:

1) Weld,


52

2) Google Guice, Spring oraz Silk DI,

3) EasyDI, PicoContainer.

Tabela 13. Ranking technologii na podstawie rednich czasów wstrzyknięć, zakres singleton

Pozycja w rankingu

Spring 3

Google Guice 2

PicoContainer 6

Weld 1

EasyDI 5

Silk DI 4

Tym razem kolejno ć frameworków ulega zmianie. Przy kolejnych wstrzyknięciach ponownie najlepsze okazują się mniej rozbudowane technologie. Jedyną wyróżniającą się biblioteką jest Weld, który poprzez zastosowanie mechanizmu dynamicznego wstrzykiwania zależno ci za każdym razem dostarcza nowy obiekt [5]. Ponadto tak jak

w przypadku eksperymentu 5, rozmiar obiektów ma niewielki

wpływ na osiągnięte czasy.

Wyniki szóstego eksperymentu zostały przedstawione na wykresie 6.

0

0,0001

0,0002

0,0003

0,0004

0,0005

0,0006

0,0007

0,0008

0,0009


Cza

s [m

s]

Wykres 6. redni czas wstrzyknięcia jednego obiektu, zakres singleton

Eksperyment 7

Siódmy eksperyment polegał na pomiarze czasu jaki potrzebny jest do wstrzyknięcia okre lonej liczby obiektów o zakresie Prototype podczas pierwszego uruchomienia

programu. Tabela 14 przedstawia osiągnięte rezultaty.

Z danych otrzymanych z testu w zakresie Prototype

widoczne są znaczne różnice pomiędzy czasami, w zależno ci od ilo ci wstrzykiwanych obiektów. W tabeli 15 umieszczono ranking technologii na podstawie osiągniętych czasów.

Ponownie zauważono, że najpopularniejsze technologie okazały się najgorsze. Wyróżniono 3 grupy w zależno ci od technologii w kolejno ci od najgorszych do najlepszych.

1) Weld,

2) Google Guice, Silk DI oraz PicoContainer,

3) Spring i EasyDI.

Tabela 14. Czas pierwszego wstrzyknięcia, zakres prototype

Car Operator

(100

obiektów CarShop)

Operator

(1000

obiektów CarShop)

Operator

(100000

obiektów CarShop)

Czas wykonania [ms]

Spring 0,3008 0,9481 5,5422 68,1141

Google Guice 0,0541 0,0094 0,9062 38,1003

PicoContainer 0,0483 0,2607 3,4635 44,2364

Weld 0,0828 0,1944 1,6446 36,8724

EasyDI 0,1173 0,6700 5,9602 84,9424

Silk DI 0,0017 0,0130 0,8636 40,0270

Tabela 15. Ranking technologii na podstawie czasu pierwszego

wstrzyknięcia, zakres prototype

Pozycja w rankingu

Spring 2

Google Guice 5

PicoContainer 3

Weld 6

EasyDI 1

Silk DI 4

Wyniki siódmego eksperymentu zostały przedstawione na wykresie 7.

0

10

20

30

40

50

60

70

80

90


Cza

s [m

s]

Wykres 7. Czas pierwszego wstrzyknięcia, zakres prototype

Eksperyment 8

Ostatni eksperyment polegał na wstrzyknięciu okre lonej liczby obiektów o zakresie Prototype podczas kolejnych 500

prób uruchomień programu. Rezultaty przedstawia tabela 16.

Tabela 16. redni czas wstrzykiwania jednego obiektu, zakres prototype

Car Operator

(100

obiektów CarShop)

Operator

(1000

obiektów CarShop)

Operator

(100000

obiektów CarShop)

Czas wykonania [ms]

Spring 0,001516 0,015864 0,334080 3,898427

Google Guice 0,000110 0,003328 0,286363 3,073268

PicoContainer 0,000188 0,003438 0,333198 3,696530

Weld 0,000930 0,004231 0,319661 3,294051

EasyDI 0,000262 0,002683 0,313320 3,657439

Silk DI 0,000049 0,002879 0,293516 3,106973

Wyniki zgromadzone w tabeli 16 wiadczą, że czasy kolejnych wstrzyknięć są zdecydowanie lepsze. Na ich


53

podstawie został stworzony ranking, który przedstawia

tabela 17.

Tabela 17. Ranking technologii na podstawie rednich czasów wstrzyknięć, zakres prototype

Pozycja w rankingu

Spring 1

Google Guice 6

PicoContainer 2

Weld 4

EasyDI 3

Silk DI 5

Grupy podziału względem technologii prezentują się podobnie jak w eksperymencie 7, z wyjątkiem frameworku EasyDI, który podczas pierwszego uruchomienia programu dla dużych obiektów osiągał największe czasy. Jest to

spowodowane małą wydajno cią tej technologii dla dużych obiektów, co przyczyniło się do jej niskiej pozycji w rankingu.

Wyniki ósmego eksperymentu zostały przedstawione na wykresie 8.

0

0,5

1

1,5

2

2,5

3

3,5

4


Cza

s [m

s]

Wykres 8. redni czas wstrzykiwania jednego obiektu, zakres prototype

Podsumowanie etapu drugiego

Porównanie wyników eksperymentów z etapu 2 zostało wykonane poprzez u rednienie pozycji poszczególnych technologii w rankingach z tego etapu. Przedstawia je

tabela 18.

Tabela 18. Ranking technologii na podstawie redniej pozycji w wszystkich eksperymentach z etapu 2

Pozycja w rankingu

Spring 1

Google Guice 5

PicoContainer 4

Weld 2

EasyDI 3

Silk DI 5

Również w tym etapie okazało się, że mniej rozbudowane technologie mają przewagę nad bardziej złożonymi narzędziami. Ich relatywnie dobre czasy prawdopodobnie są

związane z prostotą mechanizmów użytych w tych frameworkach.

5. Wnioski

Na podstawie przeprowadzonych eksperymentów można zauważyć, że frameworki osiągają różne czasy dla tych samych operacji.

Z badań przeprowadzonych w etapie pierwszym okazało się, że na czas startu kontenera nie ma wpływu zakres widoczno ci, ani liczba używanych obiektów. Dodatkowo zaobserwowano przewagę lekkich bibliotek, co może być spowodowane bardziej rozbudowanymi mechanizmami

w konkurencyjnych bibliotekach oraz konieczno cią wykonywania specyficznych akcji przed startem kontenera.

W przypadku etapu drugiego zauważono, że przy wstrzykiwaniu zależno ci znaczny wpływ mają zakresy widoczno ci. W zakresie Singleton nie istnieją znaczne różnice w zależno ci od rozmiaru obiektów. Przeprowadzona

analiza wykazuje, że mniejsze biblioteki osiągają lepsze rezultaty od rozbudowanych narzędzi. W każdym przypadku najgorszy okazał się framework Weld. Wyjątek stanowi tutaj eksperyment 1, gdzie najlepszy był Spring. wiadczy to o doskonałym zaprojektowaniu kontenera w tej technologii, co pozwala na szybki dostęp do obiektów o różnych rozmiarach,

tuż po jego uruchomieniu. W przypadku zakresu Prototype

zaobserwowano wykładniczy przyrost czasu w zależno ci od rozmiaru wstrzykiwanych obiektów. Jednak

w przeciwieństwie do zakresu Singleton wszystkie frameworki

działały podobnie (nie było znacznych różnic w czasie). Ostatecznie dzięki przeprowadzonym eksperymentom

widać, że teza stawiana we wstępie okazała się fałszywa. Potwierdziło to zasadno ć korzystania z małych bibliotek w celu wstrzykiwania zależno ci.

Literatura

[1] Karami G.,Tian J.: Improving web application reliability and

testing using accurate usage models. [W]: Studies in

Computational Intelligence, Volume 722, pp. 75-92, 2018.

[2] Bąk T, Sakowicz B.Ś Development of advanced J2EE solutions

based on lightweight containers on the example of "e-

department" application. [W]: Proceedings of the International

Conference on Mixed Design of Integrated Circuits and

Systems, Article number 1706692, pp. 779-782, MIXDES,

2006.

[3] Spring Dependency Injection Styles – Why I love Java based

configuration. https://blog.codecentric.de/en/2012/07/spring-

dependency-injection-styles-why-i-love-java-based-

configuration/ [2017]

[4] Yang H.Y.,Tempero E.: An empirical study into use of

dependency injection in Java. [W]: Proceedings of the

Australian Software Engineering Conference, ASWEC

4483212, 2008.

[5] Guice documentation. https://github.com/google/guice

[15.10.2017]

[6] Spring documentation.

https://docs.spring.io/spring/docs/current/spring-framework-

reference/html/beans.html [15.10.2017]

[7] PicoContainer documentation. http://picocontainer.com/

[15.10.2017]

[8] Kontekstowe komponenty w J2EE 6 - Wstrzykiwanie

zależno ci. http://michalorman.pl/blog/2009/11/kontekstowe-

komponenty-w-j2ee-6-wstrzykiwanie-zaleznosci/ [15.10.2017]


54

[9] Shi W., Zhang Z.: Design and application of lightweight

container. [W]: Jisuanji Gongcheng/Computer Engineering,

Volume 32, Issue 20, pp. 65-66, 20 October 2006.

[10] Wstrzykiwanie zależno ci a testy jednostkowe - złoty rodek.

https://4programmers.net/Inzynieria_oprogramowania/Wstrzyki

wanie_zaleznosci [15.10.2017]

[11] Shrinidhi R., Hudli and Raghu V. Hudli: A Verification

Strategy for Dependency Injection. Lecture Notes on Software

Engineering, Vol. 1, No. 1, February, 2013.

[12] Weld documentation.

https://docs.jboss.org/weld/reference/latest/en-

US/html/injection.html [15.10.2017]

[13] EasyDI documentation. https://github.com/lestard/EasyDI

[15.10.2017]

[14] Silk DI documentation. http://www.silkdi.com/ [15.10.2017]

JCSI 6 (2018) 55-58



55

Porównanie możliwo ci bibliotek GTK+ oraz Qt w programowaniu gier Kamil Drzas*, Dominik Alchimowicz*, Maciej Pańczyk


Streszczenie. Programowanie gier składa się z wielu elementów. Implementacja podstawowych funkcji takich jak renderowanie obrazu czy obsługa dźwięku wymaga użycia niskopoziomowych bibliotek i dużej wiedzy. rodowiska do tworzenia interfejsów graficznych aplikacji, ze

względu na ich funkcjonalno ć, mogą być atrakcyjnym wyborem w przypadku tworzenia prostych gier. Artykuł przedstawia porównanie dwóch popularnych bibliotek: GTK+ oraz Qt.

Słowa kluczowe: programowanie gier; gtk+; qt



Comparison of GTK+ and Qt libraries in game development

Kamil Drzas*, Dominik Alchimowicz*, Maciej Pańczyk


Abstract. Game development consists of many elements. Implementation of basic features such as rendering and sound handling requires usage

of low level libraries and deep knowledge. Libraries that help to create user interfaces (UI), because of their functionality, may be an attractive

platform for creating basic games. This paper presents the results of comparison of the two popular libraries: GTK+ and Qt.

Keywords: game development; gtk+; qt



1. Wstęp

Programowanie gier komputerowych to bardzo

skomplikowany proces. Nawet prosta gra wymaga

implementacji wielu elementów, takich jak renderowanie grafiki, obsługa fizyki (wykrywanie kolizji, czy działanie grawitacji), sterowania, czy też dźwięków. W przypadku

mniej skomplikowanych gier, lub prototypów, implementowanie tych funkcji staje się zbyt czasochłonne i nieopłacalne.

Silnik gry to ekosystem zawierający wyżej wymienione moduły. Duże firmy inwestują bardzo duże rodki we własne, zamknięte technologie, jednak na rynku istnieją też dostępne dla niezależnych deweloperów rodowiska takie jak Unity czy Unreal Engine. Silniki takie zwykle zawierają wszystkie potrzebne elementy do stworzenia kompletnego produktu.

Korzystanie z gotowych silników niesie za sobą pewne konsekwencje. Poziom ich skomplikowania może utrudnić pracę dla początkujących programistów, a mała elastyczno ć ogranicza swobodę w tworzeniu gry i wymaga dostosowania się do danego rodowiska.

Napisanie gry od ‘zera’ nie musi wymagać samodzielniej

implementacji wszystkich potrzebnych modułów. Na rynku znajduje się wiele darmowych bibliotek udostępniających konkretne funkcjonalno ci np. Box2D (silnik fizyki 2D) czy libgdx (audio, obsługa urządzeń wej ciowych, grafika).

Celem niniejszej pracy było porównanie możliwo ci, w programowaniu gier, dwóch popularnych bibliotek do tworzenia interfejsów graficznychŚ GTK+ oraz Qt. Badana była zarówno wydajno ć, jak i dostępno ć funkcji potrzebnych przy tworzeniu gier.

2. Aplikacja testowa

W celu przeprowadzenia badań wydajno ci stworzona została prosta gra zręczno ciowa w dwóch wersjach, odpowiednio dla każdej biblioteki. Przy tworzeniu aplikacji wykorzystano architekturę Entity-Component-System (ECS)

[1]. Architektura ta ułatwia rozdzielenie kodu programu na

pomniejsze moduły, co pozwoliło na stworzenie dwóch wersji tej samej gry różniących się jedynie podsystemami związanymi z wy wietlaniem bitmap w przestrzeni 2D

przechwytywaniem klawiszy.

Celem aplikacji jest zbadanie wydajno ci w przypadku dużej liczby poruszających się w oknie bitmap. Użycie dostępu do biblioteki OpenGL z wewnątrz GTK+/Qt z poziomu porównywanych frameworków zostało pominięte

ponieważ nie jest z nimi bezpo rednio związane. Rysunek 1

przedstawia działanie aplikacji w wersji GTK+ a Rysunek 2

w wersji Qt.


56

Rys. 1. Aplikacja w wersji GTK+

Rys. 2. Aplikacja w wersji Qt

Wykorzystane oprogramowanie:

EntityX [2] - darmowa implementacja architektury ECS Kompilator Microsoft Visual C++ 2015 GTK+ 3.6.4 Microsoft Visual Studio - rodowisko programistyczne do wersji GTK+ QT 5.9.1 MSVC2015 32bit QtCreator - rodowisko programistyczne do wersji Qt

Platforma testowa:

Windows 10 64-bit Intel Core i7 4700-MQ 8 Gb RAM Intel HD Graphics 4600

3. Porównanie bibliotek

Obie biblioteki analizowane będą pod kątem następujących kryteriówŚ

dostępno ci funkcji łatwo ci implementacji dostępu do dokumentacji wydajno ci

3.1. Dostępność funkcji

Zarówno biblioteka GTK+ jak i Qt posiadają podstawowe funkcje związane z ich przeznaczeniem, tj. tworzeniem interfejsów graficznych dla aplikacji. W kontek cie programowania gier natomiast zapotrzebowanie na funkcje

może wykraczać poza kompetencje obu bibliotek. Tabela 1 przedstawia wybrane funkcjonalno ci przydatne w wytwarzaniu gier.

Tabela 1. Dostępno ć podstawowych funkcji

GTK+ QT

Dołączone rodowisko nie tak

Wy wietlanie bitmap tak tak

Dostęp do OpenGL tak tak

Obsługa kontrolerów gier nie tak

Obsługa dźwięków nie tak

Obsługa sieci nie tak

W przypadku zapotrzebowania na funkcje związane z programowaniem gier biblioteka Qt oferuje zdecydowanie

więcej. Natywna obsługa dźwięków oraz kontrolerów gier dzięki modułom Qt Multimedia oraz Qt Gamepad eliminuje potrzebę korzystania z zewnętrznych bibliotek udostępniających te funkcje. W przypadku obsługi audio dodatkowym atutem jest możliwo ć wykorzystania pozycjonowania źródeł dźwięku, co pozwala graczowi na okre lenie z jakiego kierunku dany dźwięk się wydobywa [3].

Kolejną zaletą rodowiska Qt jest moduł Graphical Effects [4]. Moduł ten zawiera wiele łatwych do zaimplementowania efektów graficznych takich jakŚ

Displace - przesuwa pixele bitmapy na podstawie mapy Blur - rozmycie Motion Blur - rozmycie poruszających się obiektów Glow - efekt halo wokół obiektu Mask - zakrycie czę ci obiektu

W grach komputerowych istotną rolę pełnią także efekty cząsteczkowe, które biblioteka Qt wspiera natywnie. Emitery

cząsteczek w Qt pozwalają na konfigurację wielu parametrów takich jak kształt emitera czy czas życia pojedynczej cząsteczki [5].

3.2. Łatwość implementacji

Implementacja biblioteki GTK+ odbywa się w sposób typowy dla języka C/C++. Należy w projekcie użyć odpowiednich plików nagłówkowych, a na etapie kompilacji/linkowania dołączyć odpowiednie biblioteki. W celu okre lenia potrzebnych do linkowania modułów pomocne jest darmowe narzędzie pkg-config, które


57

automatycznie wygeneruje potrzebne komendy. Aby jeszcze

bardziej ułatwić proces budowania projektu wykorzystać można rodowisko Visual Studio. Po konfiguracji i dodaniu potrzebnych cieżek do plików czy bibliotek budowanie

i linkowanie odbywa się w sposób automatyczny.

W przypadku biblioteki Qt implementacja przebiega

w sposób bardziej uproszczony. Dołączone do Qt rodowisko Qt Creator pozwala na zautomatyzowanie procesu budowania

aplikacji. Konfiguracja projektu odbywa się przez edycję pliku konfiguracyjnego [nazwa_projektu].pro, gdzie znajdują się informacje o plikach nagłówkowych, kodzie źródłowym czy też dodatkowych zewnętrznych bibliotekach [6]. Plik

konfiguracyjny jest automatycznie aktualizowany

w przypadku dodawania/usuwania elementów projektu.

Tworzenie widoków gry

Obiekty reprezentowane są w grze przy pomocy widgetów służących do wy wietlania bitmap w oknie. Zarówno GTK+ jak i Qt posiadają takie widgety. Przykład 1 pokazuje jak wy wietla się bitmapę w bibliotece GTK+.

Przykład 1. Tworzenie bitmapy w GTK+

GdkPixbuf *img = img_map.at(event.component->resourcePath); GtkWidget *widget = gtk_image_new_from_pixbuf(img); gtk_layout_put(GTK_LAYOUT(RenderSystem::container), widget, 0, 0); entity.assign<View>(widget); gtk_widget_show(widget);

Do utworzenia obiektu korzysta się z funkcji

gtk_image_new_from_file lub gtk_image_new_from_pixbuf.

Druga opcja jest bardziej optymalna, gdyż w przypadku powtórzenia się tego samego pliku graficznego można wykorzystać już uprzednio wczytany gtk_pixbuf redukując przy tym zużycie pamięci RAM. Utworzony GtkWidget

umieszcza się w kontenerze przy użyciu funkcji gtk_layout_put podając jako parametry uprzednio utworzony

layout i widget. Następnie uchwyt do widgetu umieszczany jest w komponencie View.

Tworzenie bitmap w Qt odbywa się w nieco inny sposób. Istotną różnicą jest to, że widgety zdefiniowane są w plikach QML. Implementacja przedstawiona jest na Przykładzie 2.

Przykład 2. Tworznie bitmapy w Qt

QQmlComponent component(RenderSystem::m_engine, QUrl::fromLocalFile(QString::fromStdString(event.component

->resourcePath))); QObject *object = component.create(); QQmlEngine::setObjectOwnership(object, QQmlEngine::CppOwnership); QQuickItem *item = qobject_cast<QQuickItem*>(object);

item->setParent(RenderSystem::m_game_container); item->setParentItem(RenderSystem::m_item_container); entity.assign<View>(item);

Pierwszym krokiem jest wczytanie komponentu Qml

a nastepnie utworzenie instancji obiektu przy pomocy funkcji

create. Ważnym elementem jest ustawienie własno ci tego obiekt w funkcji setObjectOwnership. W przypadku tworzenia

widgetów z poziomu c++ jest to wymagane, gdyż w innym

wypadku widget ten został by usunięty przez mechanizm Garbage Collector silnika Qml.

RenderSystem

Za renderowanie obiektów odpowiedzialne są frameworki GTK+ oraz Qt. Celem systemu renderowania natomiast jest

aktualizacja pozycji bitmap w oknie na podstawie danych ze

stanu gry. Implementację przedstawia Przykład 3.

Przykład 3. Render system w wersji GTK+

void RenderSystem::update(entityx::EntityManager & entities, entityx::EventManager & events, double dt) { View::Handle viewComponent; Position::Handle positionComponent; for (Entity entity :

entities.entities_with_components(viewComponent, positionComponent)) { //GTK+ gint gx = positionComponent->x; gint gy = positionComponent->y; gtk_layout_move(GTK_LAYOUT(container), viewComponent->view, gx, gy); // QT viewComponent->view->setX(positionComponent->x); viewComponent->view->setY(positionComponent->y); } }

Funkcja Update w systemie RenderSystem uruchamiana

jest co klatkę gry. System ten przetwarza jedynie obiekty

z komponentami View (uchwyt do widgeta GTK+/Qt) oraz

Position (pozycja w wiecie gry). Przy pomocy funkcji entities_with_components biblioteki EntityX następuje iteracja po obiektach zawierających oba te komponenty, a następnie dla każdego widgeta przypisywana jest nowa pozycja na podstawie komponentu Position (gtk_layout_move

dla GTK+, setX/setY dla Qt).

3.3. Dostęp do dokumentacji

Obie biblioteki posiadają dostęp do wyczerpującej dokumentacji, w której zawarte są m.in. opis klas i funkcji,

wprowadzenie, opis poszczególnych modułów czy też poradniki i tutoriale.

Dokumentacja biblioteki Qt [7] jest jednak dużo bardziej rozbudowana i przejrzysta niż GTK+ [8]. Jest to spowodowane

tym, że Qt rozwijane jest przez firmę Qt Company, która posiada duże zasoby finansowe, a biblioteka GTK+ wspierana jest przez społeczno ć.

3.4. Wydajność

Testy wydajno ci przeprowadzone były w warunkach normalnego działania gry, włączając w to wykrywanie kolizji. W trakcie jej działania, co okre lony interwał czasu, na ekranie gry pojawiał się przeciwnik, który leciał w stronę gracza, a gdy przeciwnik ten opu cił ekran, jego obiekt gry

został zniszczony.


58

Poprzez modyfikację parametru, okre lającego wyżej wymieniony interwał czasu, kontrolowana była rednia ilo ć widocznych na ekranie obiektów. Po jej ustabilizowaniu się mierzono ilo ć od wieżeń pętli gry na sekundę.

Ze względu na użycie QtQuick 2.0 w przypadku biblioteki Qt, pomiar ilo ci klatek na sekundę odbywał się również dodatkowo w oknie Qml. Silnik Qml renderuje obiekty na

oddzielnym wątku i posiada domy lnie blokadę 60 klatek na sekundę. Tabela 3 przedstawia wyniki pomiarów.

Tabela 2. Wyniki pomiarów wydajno ci

rednia ilo ć obiektów

GTK+ -

pomiar z

pętli gry

QT - pomiar

z pętli gry QT - pomiar

z silnika Qml

80 83 18000 60

163 60 13100 60

294 42 8700 60

720 20 2300 60

1480 4 355 60

Rysunek 3 przedstawia wyniki pomiarów wydajno ci na wykresie. Pominięto pomiar z pętli gry w przypadku Qt.

0

20

40

60

80

100

80 163 294 720 1480

Liz

a kl

atek

na

seku

ndę

Średnia ilość o iektów

GTK+

QT

Rys. 3. Liczba klatek na sekundę w zależno ci od liczby obiektów

Wyniki pomiarów wskazują na znacznie większą wydajno ć w przypadku biblioteki Qt. QtQuick 2.0 korzysta

z OpenGL(ES) 2.0, dzięki czemu wykorzystywany jest potencjał karty graficznej. Dodatkowo, dzięki zastosowaniu Scene Graph proces renderowania hierarchii obiektów jest bardziej optymalny [9]. Bardzo wysoka liczba iteracji pętli gry na sekundę względem pomiaru z silnika Qml potwierdza fakt, że silnik ten działa na oddzielnym wątku, co pozwoliło na wydajne przetwarzanie logiki gry. Biblioteka Qt nawet przy

bardzo dużej ilo ci obiektów zachowywała stabilne 60 klatek na sekundę.

Biblioteka GTK+ cechowała się mniejszą wydajno cią. Wraz ze wzrostem ilo ci obiektów na scenie ilo ć klatek na

sekundę stale spadała, osiągając w najgorszym przypadku nawet 4 kl/s przy około 1500 obiektach. Tak niski wynik spowodowany był faktem, że GTK+ działa jednowątkowo i nie wykorzystuje przyspieszenia sprzętowego karty graficznej [10].

4. Wnioski

W pracy przebadano i porównano możliwo ci dwóch popularnych bibliotek do tworzenia interfejsów graficznychŚ GTK+ oraz Qt. Obie biblioteki umożliwiają programowanie gier w różnym stopniu.

Z przeprowadzonej analizy wynika, że biblioteka Qt cechuje się znacznie większą wydajno cią, a także większą ilo cią funkcji przydatnych przy tworzeniu gier.

Przyspieszenie sprzętowe pomaga zapewnić płynne działanie aplikacji, a dodatki takie jak efekty cząsteczkowe czy efekty graficzne mogą w łatwy sposób zwiększyć jej walory wizualne.

Biblioteka GTK+, ze względu na jej słabą wydajno ć przy dużej ilo ci obiektów, nie nadaje się do zbyt skomplikowanych projektów. Może ona sprawdzić się w grach typu szachy, czy pasjans, gdyż tego typu gry nie są zwykle wymagające graficznie ani nie wymagają dużej płynno ci animacji.

Biblioteka Qt, ze względu na dołączone narzędzie Qt Creator, jest znacznie łatwiejsza w implementacji. Dokumentacja biblioteki Qt jest także bardziej przejrzysta oraz przyjazna dla użytkownika, niż w przypadku GTK+, co zwiększa efektywno ć i wygodę pracy z tym

frameworkiem.

Obie biblioteki spełniają w pełni swoje zdanie, tj. tworzenie atrakcyjnych interfejsów graficznych. Jednak w przypadku programowania gier biblioteka Qt oferuje

zdecydowanie więcej możliwo ci.

Literatura

[1] https://www.gamedev.net/articles/programming/general-and-

gameplay-programming/understanding-component-entity-

systems-r3013 [20.09.2017]

[2] https://github.com/alecthomas/entityx [20.09.2017]

[3] http://doc.qt.io/qt-5/qml-qtaudioengine-audioengine.html

[20.09.2017]

[4] http://doc.qt.io/qt-5/graphicaleffects.html [20.09.2017]

[5] http://doc.qt.io/qt-5/qtquick-effects-particles.html[20.09.2017]

[6] D. Molkentin, The art of building Qt Applications, William

Pollock, 2007

[7] http://doc.qt.io/ [20.09.2017]

[8] https://developer.gnome.org/gtk3/stable/ [20.09.2017]

[9] W. Wysota, L. Haas, Game Programming Using Qt, Packt

Publishing, 2016.

[10] A. Krause, Foundations of GTK+ Development, Apress, 2007.

JCSI 6 (2018) 59-61



59

Technologia blockchain i jej zastosowania

Hlib Dikariev*, Marek Miłosz


Streszczenie. W artykule przedstawiono rezultaty analizy technologii rozproszonego rejestru blockchain. Analizę przeprowadzono pod kątem możliwo ci zastosowania technologii blockchain w różnych dziedzinach działalno ci ludzkiej.

Słowa kluczowe: blockchainś szyfrowanieś skrót kryptograficznyś kryptografia



Blockchain technology and its application

Hlib Dikariev*, Marek Miłosz Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. The article presents the results of analysis of the distributed registry technology called blockchain. The analysis was

performed for the possibility of using the blockchain technology in different spheres of human activity.

Keywords: blockchain; encryption; encription label; cryptography



1. Wstęp W ostatnich latach technologie komputerowe radykalnie

zmieniły styl życia miliardów ludzi na całym wiecie. Jednakże rewolucja komputerowa nie kończy się a dopiero zaczyna. Stworzenie technologii rozproszonego rejestru -

blockchain nazywa się bowiem rewolucją na poziomie wynalazku internetu. Szerokie wprowadzenie tej technologii

może zmienić zasady funkcjonowania całego społeczeństwa, ponieważ pozwala ona obej ć się bez centralnego zarządzania wieloma procesami społecznymi (rys. 1).

Rys. 1. Zasada działania systemu zdecentralizowanego [1]

Komputerowa technologia blockchain jest podstawą funkcjonowania wirtualnych kryprowalut, z których najbardziej znana jest bitcoin [3]. Innowacyjna technologia

blockchain jest wyjątkowym systemem, który może być stosowany praktycznie we wszystkich dziedzinach życia.

Lista problemów, które można rozwiązać za pomocą technologii blockchain jest w zasadzie nieskończona

i zaczyna się od sektora finansowego, a kończy się na np. medycynie.

2. Cel, teza i hipotezy badawcze

Celem danego artykułu jest analiza aktualno ci zastosowania technologii przechowywania danych blockchain

na podstawie badania istniejących systemów, które są używane w różnych dziedzinach życia.

Główna teza pracy zawiera się w stwierdzeniu, że blockchain może być zastosowany nie tylko w sferze finansowej (kryptowaluty), ale i w różnych dziedzinach np.

w ubezpieczeniach, branży motoryzacyjnej lub medycynie. Dlatego też zostały sformułowane dwie hipotezy badawczeŚ

H1: Blockchain może być zastosowany w wielu dziedzinach

ludzkiej działalno ci.

H2: Dane, zapisane w blockchain już nigdy nie mogą być usunięte. Wszystkie zmiany można wy ledzić od momentu powstania zapisu.


Obiektem badań jest technologia blockchain z punktu

widzenia jej wykorzystania jako wielofunkcyjnej

i wielopoziomowej technologii informacyjnej, przeznaczonej

do bezpiecznego przechowywania różnych aktywów.

3.1. Plan badań

Badanie zostało rozpoczęte od okre lenia głównej tezy pracy oraz hipotez badawczych. Dalej została wybrana odpowiednia literatura na temat technologii blockchain

i zakresu jej stosowania oraz zostały okre lone kryteria jej badania (rys. 2).


60

Rys. 2. Plan badań

3.2. Kryteria badawcze

Kryteria badania opierają się na studiowaniu literatury na temat blockchain oraz możliwo ci i aktualno ci zastosowania danej technologii.

3.2.1. Kryteria włączenia literatury w badanie

Została zbadana literatura napisana po 2009 roku, która powinna spełniać następujące kryteriaŚ

Badane będą następujące rodzaje literaturyŚ książki, artykuły naukowe oraz artykuły ze źródeł internetowych, po więconych tematowi blockchain. Musi być dostępny pełny tekst pozycji literatury. Badane będą literaturę, w której podnosi się pytanie problematyki technologii blockchain lub możliwo ci jej zastosowania.

3.2.2. Kryteria wykluczenia literatury z badania

Analizie nie będą poddane pozycje literatury, spełniające. następujące kryteria wykluczeniaŚ

Artykuły i książki nie pasujące do tematu badania. Artykuły, które nie opisują możliwo ci zastosowania technologii blockchain. Prace, dla których nie można uzyskać dostępu przez Internet.

3.3. Dobór literatury

Wybór literatury został przeprowadzony w 2 etapach

(rys. 3). Pierwszy etap obejmował podstawowy wybór i opierał się na kryteriach włączenia literatury w badania po

przeczytaniu nagłówka, adnotacji i znalezieniu artykułu. W drugim etapie, je li początkowy wybór spełniał kryteria, artykuł lub książka zostawały zbadane w pełni.

Rys. 3. Etapy wyboru literatury

3.4. Kryteria jakości literatury

Głównym kryterium oceny jako ci literatury jest jej dostępno ć w wyszukiwarce Google Scholar, która służy do przeszukiwania bazy danych zawierającej różnorodne publikacje naukowe.

4. Analiza technologii blokchain

W danym rozdziale zostanie przedstawiony wynik analizy

technologii blockchain, narzędzi oraz możliwo ci jej wykorzystania.

4.1 Technologia blockchain i jej zastosowanie

Blockchain lub łańcuch bloków to zdecentralizowana i rozproszona baza danych w modelu open source w sieci

o architekturze peer-to-peer (P2P) bez centralnych

komputerów i nie mająca scentralizowanego miejsca przechowywania danych. Służy ona przede wszystkim do księgowania poszczególnych transakcji lub aktywów za pomocą algorytmów kryptograficznych, upublicznionych

w internecie.

4.2 Koncepcja technologii blockchain

Po przeprowadzeniu analizy technologii blockchain,

można wyróżnić 2 podstawowe pojęcia jej przypisywane,

które najczę ciej można znaleźć w literaturzeŚ

Innowacyjno ć. Decentralizacja.

4.2.1. Innowacyjność

Blockchain rewolucjonizuje sposób zawierania,

rozliczania i zapisywania transakcji. Technologia działa w następujący sposóbŚ cyfrowe nagrania są łączone w bloki, które następnie są łączone kryptograficznie i chronologicznie w "łańcuch" za pomocą skomplikowanych algorytmów matematycznych [2]. Każdy blok jest powiązany z poprzednim i zawiera w sobie zestaw rekordów. Nowe bloki są zawsze dodawane do końca łańcucha (rys. 2).

Gdy został utworzony nowy blok, to poprzedni blok nie może być już zmieniony [2].


61

Rys. 4. Organizacja bloków [2]

W ten sposób nie da się go podrobić. Do bloku można tylko dodawać nowe wpisy. Najważniejsze jest to, że informacja w blockchain jest aktualizowana na wszystkich

komputerach w sieci jednocze nie.

4.2.2. Decentralizacja

W swojej książce, Melanie Swan twierdzi, że decentralizacja jest główną zaletą technologii blockchain [1]. Pojęcie systemu zdecentralizowanego opiera się na równouprawnieniu uczestników w sieci (ang. peer-to-peer).

Często w takiej sieci występuje brak dedykowanych serwerów, a każdy komputer (peer) jest zarówno klientem jak i wykonuje funkcje serwera. Oznacza to, że żaden z uczestników systemu nie będzie w stanie dokonać zmian w sieci bez wiedzy innych. Melanie Swan opisuje w swojej

książce decentralizacjęŚ ”Blockchain jako system zdecentralizowany - jest nową, rewolucyjną technologią komputerową (ang. Blockchain as decentralization is

a revolutionary new computing paradigm)”.

Po ponad siedmiu latach od wynalezienia technologii

blockchain można zobaczyć, że koncepcja decentralizacji może być wykorzystana nie tylko dla kryptowalut, ale i do

rejestracji różnych rodzajów umów, systemów pieniężnych albo praw majątkowych [5].

4.3 Obszary zastosowań technologii blockchain

Blockchain jest przeznaczony do decentralizacji rynków w szerokim aspekcie. Obsługuje przekazywanie wielu rodzajów aktywów, od momentu powstania każdego składnika aktywu do momentu jego przekazania lub wymiany. Główna idea polega na tym, że za pomocą funkcji zdecentralizowanego dziennika rekordów można zarejestrować, potwierdzić i wysłać wszystkie rodzaje umów. Blockchain pozwala zastąpić wszystkie rodzaje transakcji, w tym operacji

z papierami warto ciowymi, akcjami i udziałami spółek, wierzytelno ciami, funduszami oraz różnego rodzaju instrumentami finansowymi (kontrakty terminowe, opcje

i inne) [4]. Przykłady zastosowań technologii blockchain przedstawiono w tabeli 1.

5. Dyskusja

Blockchain jest nową technologią, która szybko zyskuje popularno ć i rozwija się każdego dnia [5]. Po przestudiowaniu literatury i przeprowadzeniu analizy na temat

technologii blockchain okazało się, że głównymi innowacjami technologicznymi są decentralizacja i bezpieczeństwo sieci [1, 2, 3, 4]. Pojęcie centralizacji i jej roli zostało postawione pod znakiem zapytania po wynalezieniu zdecentralizowanych

systemów [1].

W artykule zostały sformułowane i zbadane dwie hipotezy badawcze. Została przeprowadzona analiza możliwych obszarów zastosowań technologii blockchain, która pokazała że istnieje wiele obszarów ludzkiej działalno ci, w której może być zastosowana technologia (potwierdzenie hipotezy

H1). Przykłady zostały podane w tabeli 1. Również po badaniu algorytmów, na których opiera się technologia blockchain, można stwierdzić, że hipoteza H2 też jest prawdziwa.

Tabela 1. Przykłady zastosowań technologii blockchain [1]

Obszar zastosowań Przykład

Transakcje finansowe Papiery warto ciowe, akcje spółki, obligacje, emerytury, fundusze,

instrumenty finansowe

Dokumenty dostępne publicznie

wiadectwo własno ci gruntów i nieruchomo ci, wiadectwa rejestracji pojazdów, biznes licencji

Dowody Prawo jazdy, dowód osobisty, paszport Dokumenty prywatne Weksle, umowy, podpisy, testamenty,

pełnomocnictwa

Dokumenty, które wymagają za wiadczeń

Ubezpieczeniowe polisy, wiadectwa własno ci, po wiadczenie notarialne dokumentów

Należy zaznaczyć, że wszystkie problemy z blockchain pochodzą z młodo ci technologii i że istnieje jeszcze wiele pytań do ewentualnego szerszego wdrożenia danej technologii.

6. Wnioski

Obecnie technologia blockchain zyskuje szybką popularno ć i z każdym dniem coraz więcej osób dowiaduje się o jej zaletach w porównaniu z klasycznymi technologiami przechowywania danych. Na dodatek wiele prywatnych

i publicznych projektów jest tworzonych lub przenoszonych na technologię blockchain. Wynika to przede wszystkim z korzy ci, które oferuje technologia w porównaniu z relacyjnymi bazami danych:

Zabezpieczenie danych za pomocą algorytmów kryptograficznych. Decentralizacja. Wielofunkcyjno ć.

Potencjalnie technologia ta obejmuje wszystkie bez

wyjątku dziedziny działalno ci gospodarczej i ma wiele

zastosowań, w tymŚ finanse i gospodarka, operacje materialne i niematerialne, aktywa, rachunkowo ć w państwowych i prywatnych instytucjach a także organizacjach typu mieszanego.

Literatura

[1] Melanie Swan. Blockchain: Blueprint for a New Economy.

O'Reilly Media, 2015.

[2] Siraj Raval. Decentralized Applications. O'Reilly Media, 2016

[3] Satoshi Nakamoto. Bitcoin: A Peer-to-Peer Electronic Cash

System. Whitepaper, 2008.

[4] Oleg Mazonka. Blockchain: Simple Explanation. Whitepaper,

2016.

[5] Aaron Wright, Primavera De Filippi. Decentralized Blockchain

Technology and the Rise of Lex Cryptographia. Social Science

Research Network, 2015.

[6] Sinclair Davidson, Primavera De Filippi, Jason Potts. Economics

of Blockchain. Social Science Research Network, 2016.

[7] Simon Taylor. Blockchain: understanding the potential. Barclays

report, 2015.

JCSI 6 (2018) 62-67

Wysłane: 2017-11-06


62

Pięć sposobów wprowadzenia współbieżności do programu w języku C#

Paweł Szyszko*, Jakub Smołka


Streszczenie: Dzisiejsze procesory w komputerach osobistych i urządzeniach mobilnych umożliwiają coraz bardziej efektywne zrównoleglanie działań w celu szybszego uzyskania wyników. Twórcy oprogramowania mają wiele różnych możliwości zaimplementowania współbieżności, jednak zazwyczaj trzymają się jednej, najbardziej znanej sobie techniki. Warto prześledzić działanie każdej z nich, aby odkryć, kiedy można ją wykorzystać w sposób efektywny, a kiedy lepiej poszukać alternatywy. W poniższym artykule zostały przedstawione sposoby równoległej implementacji obliczeń matematycznych z wykorzystaniem wątków, zadań, puli wątków, puli zadań oraz równoległej pętli for z klasy Parallel.

Wszystkie zostały napisane w języku C# na silniku Windows Presentation Foundation platformy .NET. Zaimplementowane obliczenia

matematyczne to obliczenie liczby Pi z pomocą wzoru Leibniza.

Słowa kluczowe: programowanie równoległe; .Net; C#; pi

*Autor do korespondencji/


Five ways to insert concurrency to a program written in C#

Paweł Szyszko*, Jakub Smołka


Abstract: Nowadays processors working in personal computers and mobile devices allow for more and more effective parallel computing.

Developers have at their disposal many different methods of implementing concurrency, but usually use the one, that they now best. It is

beneficial to know, when a particular technique is good and when it is better to find an alternative. This paper presents different ways of

implementing parallel mathematical calculations using threads, tasks, thread pool, task pool and parallel for loop. Each method was used in a C#

application running on Windows Presentation Foundation engine on .NET platform. Implemented operation is calculation value of Pi using

Leibnitz’s formula.

Keywords: parallel programming; .Net; C#; pi

*Corresponding author


1. Wstęp Praca twórcy oprogramowania nie składa się jedynie

z samego pisania kodu. Musi on także znaleźć odpowiednie rozwiązania postawionych przed nim problemów – takie

rozwiązania, które będą najprostsze i najefektywniejsze. Jednym z takich problemów jest przyspieszenie i skrócenie czasu potrzebnego na wykonanie długich i skomplikowanych zadań, a jego rozstrzygnięciem – wprowadzenie

współbieżności. Takie rozwiązanie generuje kolejne pytanie:

w jaki sposób wprowadzić współbieżność do kodu aplikacji. Istnieje wiele możliwości na zrównoleglenie działań w programie, a większość z nich jest stosunkowo prosta w obsłudze.

Poniższy artykuł przedstawia pięć sposobów na zrównoleglenie działań w aplikacji napisanej w języku C# na platformie programistycznej .Net oraz stara się przedstawić odpowiedź na pytanie, która z nich jest najefektywniejsza

i najprostsza do działań na szeregach matematycznych na przykładzie szeregu Leibniza pozwalającego na obliczenie wartości liczby π z zadaną dokładnością.

2. Dotychczasowe badania

Rozwój programowania równoległego jest na tyle szybki, że badania naukowe nie zawsze nadążają za nimi. Pomimo,

że nad tym tematem pracowało i pracuje tysiące zespołów z całego świata wciąż wiele rzeczy pozostaje do odkrycia. Jedną z pierwszych prac porównujących dwie techniki wprowadzania współbieżności do programu był artykuł, napisany przez Niklausa Wirtha w 1996 [13]. Przedstawione

zostały w nim wady i zalety podejścia wątkowego oraz jego alternatywy – opartego na przerwaniach systemu zadań, ale wybór technologii został pozostawiony twórcom oprogramowania. Od tamtego czasu większość badań skupia się na znalezieniu optymalnego rozwiązania (nie zawsze jest

to możliwe [3,9]) – technologii zrównoleglania działań –

zadanego problemu i w ten sposób przedstawia swoje wyniki [5,11]. Niestety większość badaczy skupia się jedynie na dwu wyżej wymienionych sposobach, co sprawia, że inne techniki,

które z nich wyewoluowały pozostają nieprzebadane.

3. Pięć sposobów wprowadzenia współbieżności do kodu w języku C#

3.1. Kolekcja wątków

Pierwszym sposobem na oddelegowanie prac jest

wykorzystanie wątku. Oczywiście wykorzystanie pojedynczego wątku nie sprawi, że działania będą wykonywane równolegle, więc należy posłużyć się większą kolekcją, jak na listingu 1. Praca ze zmiennymi globalnymi

wymaga zabezpieczeń np. konstrukcji lock [4,10].


63

Każdy wątek w kolekcji należy zainicjować, przekazań mu akcję do wykonania (np. poprzez wyrażenie lambda jak w przykładzie) i wystartować poleceniem Start(). Język C# nie posiada wbudowanych elementów pozwalających na jednoczesne oczekiwanie na zakończenie pracy przez wiele wątków, aby więc osiągnąć taki efekt należy posłużyć się licznikiem, np. zastosowanym w przykładzie obiektem klasy CountdownEvent. Metoda Signal() tego obiektu jest

po prostu dekrementacją licznika, która jest operacją atomową, więc nie ulegnie przerwaniu.

Wątki i ich kolekcje są dostępne jedynie dla aplikacji tworzonych z myślą o starszych systemach Windows przy użyciu silników WPF i Windows Forms. Listing 1. Przykładowa implementacja kolekcji wątków

Thread[] threads = new Thread[workersNr]; CountdownEvent countdown = new

CountdownEvent(workersNr); for (int j = 0; j < workersNr; j++) { threads[j] = new Thread(() => { /.../ lock (key) { countdown.Signal(); } }); } for (int j = 0; j < workersNr; j++) { threads[j].Start(); } countdown.Wait(); countdown.Dispose();

3.2. Kolekcja zadań

Alternatywą dla wątków w większości języków programowania wspierających współbieżność, a więc także w języku C# są zadania. Są one prostsze w obsłudze i zwalniają programistę z wielu działań związanych

z synchronizacją (listing 2.), kosztem dodatkowych

związanych np. ze zwolnieniem wykorzystywanych zasobów (metoda Dispose()).

Listing 2. Przykładowa implementacja kolekcji zadań

Task[] tasks = new Task[workersNr]; for (int j = 0; j < workersNr; j++) { tasks[j] = Task.Factory.StartNew(() => { /.../

}); } Task.WaitAll(tasks); foreach (var t in tasks) t.Dispose();

W przeciwieństwie do wątków zadania mogą być uruchamiane w momencie inicjalizacji, a klasa je

reprezentująca posiada wbudowany mechanizm oczekiwania. Należy pamiętać, że aby zadanie było wykonywane współbieżnie trzeba posłużyć się metodami Factory.StartNew() lub Run(), a nie konstrukcją await task,

która uruchamia kod asynchronicznie. Akcje przekazywane

do zadań powinny być możliwie najkrótsze i niezależne [1].

3.3. Pula wątków

Pula wątków jest kolekcją wątków, której można przydzielić zadanie do wykonania. W przeciwieństwie do zwykłej kolekcji deklarowanej w aplikacji, jest ona zarządzana z poziomu biblioteki klas lub systemu operacyjnego co ułatwia pracę programisty. Wciąż musi on zapewnić bezpieczeństwo wątków (ang. thread-safety) i nie

może przewidzieć kolejności ich zakończenia, a dodatkowo klasa ThreadPool tworzy tylko wątki tła, których działanie jest przerywane wraz z zakończeniem pracy aplikacji. Programista nie musi natomiast oddzielnie startować każdej akcji, która jest uruchamiana, kiedy zwolni się wątek roboczy i nadejdzie jej kolej (listing 3.).

Listing 3. Przykładowa implementacja puli wątków

CountdownEvent countdown = new CountdownEvent(workersNr);

for (int j = 0; j < workersNr; j++) { ThreadPool.QueueUserWorkItem((index) => { /.../ lock (key) { countdown.Signal(); } },j); } countdown.Wait(); countdown.Dispose();

3.4. Pula zadań

Analogicznie jak pula wątków, pula zadań jest obiektem pozwalającym na wprowadzenie współbieżności do programu. Aby ją wykorzystać należy posłużyć się obiektem TaskPoolScheduler (listing 4.) z przestrzeni nazw

System.Reactive.Concurency [12], która nie jest standardowym obiektem, więc musi być dołączona do projektu. Ten sposób najlepiej sprawdza się przy krótkich operacjach. Podobnie jak pula wątków, to pula zadań zarządza wykonywaniem zadań [1]. Listing 4. Przykładowa implementacja puli zadań

CountdownEvent countdown = new CountdownEvent(workersNr);

TaskPoolScheduler taskpool = TaskPoolScheduler.Default; List<IDisposable> disposables = new List<IDisposable>(); for (int j = 0; j < workersNr; j++) { disposables.Add(taskpool.Schedule(j, (IScheduler scheduler, int threadIndex) => {

/.../ lock (key) { countdown.Signal(); } return Disposable.Empty; })); } countdown.Wait(); countdown.Dispose(); foreach (var d in disposables) d.Dispose();

Możliwe jest posługiwanie się wieloma rodzajami planisty (TaskPoolScheduler), a nawet tworzenie własnych, ale można także, jak w przykładzie, wykorzystać obiekt domyślny.


64

3.5. Pętla równoległa

Równoległe implementacje pętli for i foreach pojawiły się w języku C# wraz z biblioteką TPL. Te dwie konstrukcje najlepiej sprawdzają się do wykonywania serii takich samych zadań (np. obliczania szeregu liczbowego). Wykorzystanie pętli równoległej for jest zdecydowanie najprostsze [8] i

gdyby nie potrzeba oczekiwania na wynik, można by ją zapisać w jednej linii kodu (nie licząc akcji do wykonania) –

listing 5.

Listing 5. Przykładowa implementacja równoległej pętli for

CountdownEvent countdown = new CountdownEvent(workersNr); Parallel.For(0, workersNr, (_) => { /.../ lock (key) {

countdown.Signal(); } }); countdown.Wait(); countdown.Dispose();

4. Algorytmy badawcze

4.1. Algorytm sekwencyjny

Wykorzystanie algorytmu sekwencyjnego w połączeniu z ww. sposobami oddelegowania obliczeń, pozwala na odciążenie wątku głównego, ale nie ma na celu przyspieszenia obliczeń. Nie różni się on niczym od swego odpowiednika, który byłby uruchamiany w wątku GUI (listing 6.).

Listing 6. Algorytm sekwencyjny implementujący szereg Leibniza

for (int j = 0; j < calculations; j++) { Pi = 0; for (int i = 0; i < sequenceLength; i++) { if (i % 2 == 0) Pi = Pi + (decimal)4 / (decimal)(2 * i + 1); else Pi = Pi - (decimal)4 / (decimal)(2 * i + 1); } }

Algorytm składa się z dwóch pętli for, z których pierwsza pozwalana na wielokrotne ponowienie obliczeń – pojedyncze

obliczenie wartości szeregu było zbyt szybkie, aby możliwe było odczytanie czasu trwania obliczeń, a druga przebiega po całym szeregu i w zależności od parzystości lub nieparzystości licznika dodaje lub odejmuje kolejny element.

4.2. Algorytm równoległy

Wątek główny zapełnia kolekcję obiektami odpowiedniego typu w zależności od wykorzystywanej technologii w liczbie przekazanej przez zmienną workersNr.

Do robotników nie są przekazywane żadne argumenty startowe. Każdy z nich deklaruje własną zmienną myI

przechowującą informację o aktualnej wartości iteratora, a następnie w sekcji krytycznej [6] pobiera wartość globalną i inkrementuje zmienną globalnego iteratora [7]. Kiedy

robotnik uzyska informację nad którą wartością ma pracować wchodzi w pętlę, której nie opuści dopóki pobrana wartość

myI nie będzie większa niż zadana liczba obliczeń π. W pętli robotnik oblicza wartość zgodnie z sekwencyjnym algorytmem, a następnie zapisuje ją do tablicy wynikowej i pobiera kolejną wartość iteratora. Kiedy pętla się zakończy kończy się także działanie robotnika (listing 7.).

Listing 7. Algorytm równoległy obliczania liczby π

for (int j = 0; j < workersNr; j++) { threads[j] = new Thread(() => { int myI; lock (key) { myI = i; i++; } while (myI < calculations)

{

decimal myPi = 0; for (int k = 0; k < sequenceLength; k++) { if (k % 2 == 0) myPi = myPi + (decimal)4 / (decimal)(2 * k + 1); else myPi = myPi - (decimal)4 / (decimal)(2 * k + 1); } lock (key) { PiValues.Add(myPi); myI = i; i++; } } lock (key) { countdown.Signal(); } }); }

5. Wyniki badań

W procesie badawczym posługiwano się dwoma dodatkowymi zmiennymi liczbowymi. Zmienna

sequenceLength pozwalała na zmianę długości szeregu, a co za tym idzie rozmiar pracy do wykonania, a zmienna

calculations – liczby powtórzeń całego procesu obliczenia szeregu. Manipulowano nimi tak, aby pomiar czasu pozwalał na odczytanie ok. dwóch cyfr znaczących.

5.1. Algorytm sekwencyjny

Wykorzystanie algorytmu sekwencyjnego, poza wątkiem głównym, okazało się być tak samo wydajne, jak jego uruchomienie w wątku GUI (wykresy na rys. 1. str. 4).

Widoczne są różnice niewielkie statystyczne, ale są one na tyle małe, że można uznać, że czas wykonania algorytmu nie zależy od tego, czy jest uruchamiany w wątku interfejsu użytkownika, czy poza nim. Oznacza to, że oddelegowanie

prac powinno mieć miejsce zawsze, w najgorszym wypadku

zwolnione zostaną zasoby wątku głównego.

Wartymi uwagi są „pudełka” przedstawiające czas wykonania obliczeń przez WorkTask, ThreadPool i Parallel. Są one zbliżone w większości przypadków zbliżone do siebie, co jest zgodne z informacją, że pracują w oparciu o tę samą technologię.


65

0,03

0,032

0,034

0,036

0,038

0,04

0,042

0,044

100 el ms

0,31

0,32

0,33

0,34

0,35

0,36

0,37

0,38

0,39

1000el ms

31

32

33

34

35

36

37

38

39

40

100000el ms

310

320

330

340

350

360

370

380

1000000el ms

0,0026

0,0027

0,0028

0,0029

0,003

0,0031

0,0032

0,0033

10 el ms

3

3,1

3,2

3,3

3,4

3,5

3,6

3,7

3,8

3,9

4

10000el

Rys. 1. Wykresy prezentujące czas obliczenia szeregu Leibniza z wykorzystaniem algorytmu sekwencyjnego

ms


66

0

5

10

15

20

25

30

35

0

5

10

15

20

25

30

35

0

5

10

15

20

25

30

35

330

350

370

390

410

430

450

470

490

510

530

330

350

370

390

410

430

450

470

490

510

530

330

350

370

390

410

430

450

470

490

510

530

330

350

370

390

410

430

450

470

490

510

530

Rys. 2. Wykresy prezentujące czas obliczenia szeregu Leibniza z wykorzystaniem algorytmu równoległego; kolory odróżniają od siebie wykresy czasu obliczeń wykonywanych przez różną liczbę robotników: czerwony – 1, niebieski – 2, zielony – 4, pomarańczowy – 8

0

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

0,0045

0

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

0,0045

0

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

0,0045

0

0,0005

0,001

0,0015

0,002

0,0025

0,003

0,0035

0,004

0,0045

0

0,005

0,01

0,015

0,02

0,025

0,03

0,035

0

0,005

0,01

0,015

0,02

0,025

0,03

0,035

0

0,005

0,01

0,015

0,02

0,025

0,03

0,035

0

0,005

0,01

0,015

0,02

0,025

0,03

0,035

0

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0

0,05

0,1

0,15

0,2

0,25

0,3

0,35

0

0,5

1

1,5

2

2,5

3

3,5

0

0,5

1

1,5

2

2,5

3

3,5

0

0,5

1

1,5

2

2,5

3

3,5

0

0,5

1

1,5

2

2,5

3

3,5

0

5

10

15

20

25

30

35

ms ms

ms ms

ms ms


67

5.2. Algorytm równoległy

Prezentowane na rysunku 2. (str. 5) wykresy

przedstawiają statystyki czasu obliczeń wartości liczby π dla każdej z pięciu technologii programowania równoległego i różnych długości szeregu Leibniza. W przeciwieństwie do swoich odpowiedników prezentujących czas obliczeń z wykorzystaniem algorytmu sekwencyjnego zawierają dodatkową informację na temat liczby robotników wykonujących zadanie. I tak: czerwonym kolorem zostały zaznaczone „pudełka” prezentujące statystyki czasu obliczeń wykonywanych przez jednego robotnika, niebieskim –

dwóch, zielonym – czterech i pomarańczowym – ośmiu.

Wykorzystanie algorytmu równoległego jest uzasadnione tylko, jeżeli działanie, które ma być wykonane jest podzielne na niezależne od siebie elementy. Jeżeli nie jest (jak w przypadku ostatniego zadania – obliczenia jednego

długiego szeregu), obliczenia są wykonywane i tak przez jednego robotnika, więc czas wykonania jest zbliżony do czasu działania algorytmu sekwencyjnego, a nawet większy, gdyż dodawany jest narzut czasowy związany z synchronizacją. W pozostałych przypadkach, gdy do wykonania była praca możliwa do rozdzielenia, udział kolejnych robotników w pozytywny i dość przewidywalny sposób wpływał na czas obliczeń, nigdy nie udało się jednak osiągnąć m-krotnego przyspieszenia działania, a jedynie bliski tej wartości wynik (gdzie m to liczba robotników).

Analiza wyników pozwala stwierdzić, że żadna z badanych technologii programowania równoległego nie wybija się ponad inne, więc każda z nich może być z równie dobrym skutkiem wykorzystywana do obliczeń zbliżonych do działań na szeregach liczbowych. Jest to o tyle pozytywna

wiadomość, że każdy programista może sam zdecydować, która technologia najbardziej mu odpowiada.

6. Podsumowanie

Przeprowadzenie badań nad pięcioma technologiami programowania równoległego w języku C# pozwoliło stwierdzić, że każda z nich tak samo dobrze nadaje się do obliczeń współbieżnych oraz sekwencyjnych, oraz, że samo przeniesienie obliczeń poza wątek GUI pozwala na

zwiększenie wydajności aplikacji.

Każda z przedstawionych technologii ma inną implementację, inne wymagania i inne ograniczenia, ale wybór konkretnej warto pozostawić twórcom oprogramowania opierającym się na swoich doświadczeniach i wykorzystujących określone biblioteki i frameworki [2].

Literatura

[1] Blaar H., Lange T., Winter R., Karnstedt M.: Possibilities

to solve the clique problem by thread parallelism using

task pools. 19th IEEE International Parallel and

Distributed Processing Symposium 2005.

[2] Bugnion Laurent: MVVM : Multithreading and

Dispatching in MVVM Applications. MSDN Magazine,

2014.

[3] Choudhury Olivia i inni: Balancing Thread-Level and

Task-Level Parallelism for Data-Intensive Workloads on

Clusters and Clouds. IEEE International Conference on

Cluster Computing, 2015.

[4] Jin Jiangming, Zhang Yang, Tang Shanjiang, Fan

Hongfei: Performance Modeling and Analysis for

Critical Section Contention in Parallel Codes. IEEE

Trustcom/BigDataSE/ISPA, 2016.

[5] Lee Jiyeon, Chwa Hoon Sung, Lee Jinkyu, Shin Insik:

Thread-level priority assignment in global

multiprocessor scheduling for DAG tasks. Journal of

Systems and Software, 2016.

[6] Nowak Robert Współdzielenie obiektów w aplikacjach współbieżnych. Software Developers Journal 2010

[7] Paolieri Marco i inni: A Software-Pipelined Approach to

Multicore Execution of Timing Predictable Multi-

threaded Hard Real-Time Tasks. 14th IEEE International

Symposium on Object/Component/Service-Oriented

Real-Time Distributed Computing, 2011.

[8] Schubring Tadeusz: Algorytmy równoległe w języku programowania C#. TTS Technika Transportu

Szynowego, 2016.

[9] Schwan K., Zhou H.: Dynamic scheduling of hard real-

time tasks and real-time threads. IEEE Transactions on

Software Engineering, 1992.

[10] Smoliński Mateusz: Elimination of task starvation in

conflictless scheduling concept. Information Systems in

Management vol. 5 (2) 2016, 237−247.

[11] Tousimojarad Ashkan i inni: Number of Tasks, not

Threads, is Key. 23rd Euromicro International

Conference on Parallel, Distributed, and Network-Based

Processing, 2015.

[12] Warczak Mateusz i inni: Programowanie równoległe i asynchroniczne w C# 5.0. Wydawnictwo Helion, 2014.

[13] Wirth Niklaus: Tasks versus Threads: An Alternative

Multiprocessing Paradigm. Springer-Verlag 1996.

JCSI 6 (2018) 68-72



68

Analiza wydajno ci aplikacji mobilnych przy zastosowaniu różnych narzędzi programistycznych do ich budowy

Paweł Kotarski*, Kacper ledź*, Jakub Smołka Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska

Streszczenie. Rozwiązania pozwalające tworzyć aplikacje na różne systemy mobilne, w których istnieje możliwo ć współdzielenia całego kodu źródłowego bądź dużych jego czę ci cieszą się coraz większą popularno cią. W artykule przedstawiono porównanie wydajno ci aplikacji mobilnych przeznaczonych na system Android stworzonych przy pomocy domy lnych narzędzi tego rodowiska oraz rozwiązań oferujących

wsparcie dla wielu platform. Autorzy na wybranych przykładach badają wydajno ć w różnych aspektach działania aplikacji.

Słowa kluczowe: android; wydajno ćś narzędzia programistyczne



Analysis of the impact of development tools used on the performance of the

mobile application

Paweł Kotarski*, Kacper ledź*, Jakub Smołka Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. Solutions that allow developers to create application for different mobile systems in which they can share whole source code or large

parts of it are becoming more popular. This article compares the performance of Android-based mobile application created with the default and

multiplatform tools. Authors on selected examples examine performance in various aspects of the application.

Keywords: android; performance; development tools



1. Wprowadzenie

Android jest obecnie najpopularniejszym systemem

operacyjnym na urządzenia mobilne. Mimo swojej przeważającej pozycji na rynku wciąż istnieją inne, popularne systemy mobilne. W związku z tym niektóre firmy borykają się z problemem tworzenia kilku wersji tej samej aplikacji na

różne systemy mobilne, aby dostarczyć swój produkt do jak

największej ilo ci potencjalnych klientów. Wymaga to

stworzenia i utrzymywania takich samych programów

w różnych językach programowania i pracujących na dedykowanych rodowiskach.

W ostatnim czasie powstało wiele bibliotek, które mają pomóc w rozwiązaniu tych problemów. Jednymi z bardziej

popularnych są darmowy Apache Cordova oraz komercyjny Xamarin. Ich głównym założeniem jest możliwo ć wykorzystywania tego samego kodu przez programy tworzone

na różne systemy operacyjne. Wiele firm decyduje się na skorzystanie z takich technologii ze względów ekonomicznych.

Niniejszy artykuł ma na celu porównanie wydajno ci aplikacji działających na systemie Android stworzonych

w technologiach oferujących wsparcie dla

wieloplatformowo ci z aplikacjami tworzonymi natywnie. To

porównanie ma pomóc w wyborze odpowiedniego narzędzia do tworzenia aplikacji spełniającego wymogi danej organizacji. Dzięki niemu firmy będą mogły podjąć decyzję, czy ewentualne straty wydajno ciowe są rekompensowane

przez szybsze tempo wytwarzania oprogramowania oraz

mniejsze nakłady finansowe.

2. Obiekt badań

Obiektem badań były narzędzia programistyczne służące do tworzenia aplikacji na systemie Android. Badane przez nas

narzędzia toŚ Android SDK i język Java, Android NDK,

Xamarin, Apache Cordova.

2.1. Android SDK i język Java

Najpopularniejszą metodą tworzenia aplikacji na system Android jest wykorzystanie języka Java. Jest on

wykorzystywany w aplikacjach dostępnych w systemie bezpo rednio po jego zainstalowaniu. Ogromną popularno ć zyskał dzięki dobrymi proporcjami między łatwo ci pisania kodu, a wydajno cią działania gotowego programu. Rozwiązanie to jest darmowe, ale można je zastosować tylko na telefonach z systemem Android. Widok aplikacji tworzony

jest w języku XML natomiast bazowy blok tworzący elementy interfejsu użytkownika reprezentuje klasa View. Wszystkie

funkcje systemu udostępniane aplikacji przez system

operacyjny dostępne są w postaci klas języka Java[1].

2.2. Android NDK

Android NDK jest zbiorem narzędzi, który umożliwia tworzenie fragmentów aplikacji używając do tego języków natywnych takich jak C i C++. Dla pewnych typów aplikacji taki zabieg może pomóc w ponownym wykorzystywaniu kodu


69

bibliotek[2]. Pisanie fragmentów aplikacji wrażliwych wydajno ciowo w kodzie natywnym może znacznie poprawić szybko ć jej działania. Według oficjalnej dokumentacji systemu Android nie zaleca się pisania całej aplikacji przy pomocy Android NDK, ze względu na zwiększenie skomplikowania kodu. Ponadto w pewnych obszarach użycie natywnego kodu nie przynosi zauważalnych zysków wydajno ciowych.

2.3. Xamarin

Platforma Xamarin służy do tworzenia aplikacji na różne mobilne systemy operacyjne. Są nimi Android, Windows

Mobile oraz iOS. Jest to narzędzie komercyjne, powstałe przez ewolucję projektu Mono, który był alternatywną implementacją .Net Framework dla systemów z rodziny Unix.

Językiem odpowiadającym za logikę aplikacji jest C#. Jest on

popularnym wyborem dla tworzenia aplikacji desktopowych

dla systemu Windows. Wygląd aplikacji można tworzyć w dwojaki sposób: wykorzystując Xamarin Forms lub natywne rozwiązania każdego systemu. Decydując się na Xamarin Forms powstaje jedna wersja widoku w języku

XAML. W przypadku tworzenia natywnych widoków trzeba

stworzyć osobną wersję widoku dla każdej platformy w domy lnym języku (dla systemu android jest to język XML).

2.4. Apache Cordova

Platforma Apache Cordova jest narzędziem open source,

które umożliwia tworzenie aplikacji na wiele systemów mobilnych wykorzystując technologie webowe. Korzystając z tej platformy można pisać aplikację na systemy mobilne takie jak: Andoird, iOS, Windows Moblie, Blackberry.

Stworzenie wyglądu aplikacji jest równoznaczne stworzeniu responsywnej strony www dostosowanej do urządzeń mobilnych. Natomiast logika napisana jest w języku JavaScript, w którym można odwoływać się do API systemowego w celu skorzystania z takich funkcjonalno ci jak GPS, powiadomienia, aparat, akcelerometr poprzez obiekty

po redniczące zapewnione przez platformę Apache Cordova.

3. Procedura i platforma testowa

W niniejszej publikacji przeprowadzone zostały trzy eksperymenty, a następnie została przeprowadzona analiza wyników. Pierwszym eksperymentem był pomiar czasu sortowania tablicy posiadającej 100 000 elementów. Następnym przetestowanym scenariuszem był pomiar czasu potrzebnego na zapis pliku o rozmiarze 10MB. Ostatnim

eksperymentem opisanym w tym artykule był pomiar czasu potrzebnego na odczyt pliku o rozmiarze 10MB. Każdy z eksperymentów przeprowadzony został 20 razy aby uniknąć błędów związanych ze skokami obciążenia podzespołów przez

system. Na potrzeby testów zostały napisane cztery aplikacje oparte o rozwiązania opisane w rozdziale „2. Obiekt badań”.

3.1. Sortowanie tablicy

Test każdej aplikacji polegał na posortowaniu dwudziestu różnych tablic o rozmiarze stu tysięcy elementów. Wszystkie

aplikacje korzystały z tego samego zbioru tablic. Mierzony był czas jedynie sortowania tablicy z pominięciem czasu potrzebnego na załadowanie tablicy do pamięci.

Sortowanie tablic zostało zrealizowane poprzez implementację algorytmu quicksort na poszczególnych platformach. Jest on jednym z najpopularniejszych

algorytmów stosowanych w dzisiejszej informatyce do

sortowania dużych zbiorów danych. Wykorzystuje zasadę „dziel i zwyciężaj” sortując rekursywnie mniejsze fragmenty

podzbioru.

3.2. Zapis dużego pliku

Celem testu było zmierzenie czasu potrzebnego do zapisania w pamięci urządzenia pojedynczego pliku

o rozmiarze 10MB. Proces generowania pliku polegał na powieleniu losowego ciągu znaków do momentu uzyskania przez plik oczekiwanego rozmiaru. Aplikacja zapisywała plik sekwencyjnie.

3.3. Odczyt dużego pliku

Ostatni eksperyment polegał na zmierzeniu czasu potrzebnego do sekwencyjnego odczytu pliku o rozmiarze

10MB. Testowanym plikiem był plik tekstowy zawierający losowe znaki.

3.4. Platforma testowa

Wszystkie testy zostały przeprowadzone na urządzaniu fizycznym oraz emulatorze systemu Android działającym na komputerze klasy PC bazującym na specyfikacji telefonu LG

Nexus 5X. Testowanym urządzeniem fizycznym był telefon Xiaomi Redmi 3 Pro, którego parametry sprzętowe zostały przedstawione w Tabeli 1.

Tabela 1. Parametry techniczne Xiaomi Redmi 3 Pro

Procesor Qualcomm Snapdragon 616

Taktowanie 1,50 GHz

Liczba rdzeni 8

Pamięć RAM 3 GB

Pamięć ROM 32 GB

System operacyjny Android 7.1.2 Nougat

4. Wyniki badań

Poniżej znajdują się wyniki przeprowadzonych badań. Wszystkie czasy badań zostały przedstawione w milisekundach. Wykresy prezentują medianę dwudziestokrotnego wykonania eksperymentu. Wykresy

przedstawiają kolejno wyniki badań sortowania tablicy posiadającej sto tysięcy elementów na urządzeniu oraz emulatorze, zapis pliku o rozmiarze 10MB na urządzeniu oraz emulatorze i odczyt pliku o rozmiarze 10MB na urządzeniu oraz emulatorze dla aplikacji stworzonej przy użyciu rozwiązania Apache Cordova, Xamarin, Android NDK i języka C++ oraz Android SDK i języka Java.


70

Rys. 1. Szybko ć sortowania tabeli na urządzeniu

Rys. 2. Szybko ć sortowania tabeli na emulatorze

Rysunek 1 oraz rysunek 2 przedstawiają wyniki badań sortowania tablic elementów. Na urządzeniu fizycznym z tym zadaniem najszybciej poradziła się aplikacja napisana

w języku Java, natomiast najgorszy wynik osiągnęła aplikacja napisana na platformę Apache Cordova. Na symulatorze

najlepiej poradziły sobie aplikacje napisane w technologiach

Xamarin i Android NDK a najgorzej w języku Java.

Rys. 3. Szybko ć zapisu dużego pliku na urządzeniu

Rys. 4. Szybko ć zapisu dużego pliku na symulatorze

Rysunek 3 oraz rysunek 4 przedstawiają wyniki badań zapisu dużego pliku. Na urządzeniu fizycznym najszybciej

poradziła sobie aplikacja w technologii Xamarin, natomiast

najgorszy wynik osiągnęła aplikacja napisana na platformę Apache Cordova. Na symulatorze najlepiej poradziła sobie aplikacja napisana w technologii Xamarin, a najgorzej

w języku Java.

Rys. 5. Szybko ć odczytu dużego pliku na urządzeniu

Rys. 6. Szybko ć odczytu dużego pliku na symulatorze


71

Rysunek 5 oraz rysunek 6 przedstawiają wyniki badań odczuty dużego pliku. Na urządzeniu fizycznym z takim zadaniem najszybciej poradziła sobie aplikacja napisana z wykorzystaniem android NDK, natomiast najgorszy wynik

osiągnęła aplikacja napisana na platformę Apache Cordova.

Na symulatorze kolejno ć wyników jest identyczna.

5. Analiza wyników

W wynikach testów sortowania tablicy elementów oraz zapisu dużego pliku można zauważyć podobny stosunek wydajno ciowy poszczególnych platform wobec siebie.

Widoczna tam jest również znacząca różnica czasu wykonania testu przez aplikacje napisaną w oparciu o technologię Java pomiędzy urządzeniem fizycznym a emulatorem. Taka różnica nie jest zauważalna przy te cie odczytu dużego pliku.

Podczas każdego eksperymentu przeprowadzanego na fizycznym urządzeniu najwolniejszą aplikacją okazywał się program stworzony przy pomocy platformy Apache Cordova.

Różnica wydajno ci pomiędzy wspomnianą aplikacją a pozostałymi testowanymi aplikacjami była często mocno zauważalna oraz wynosiła wielokrotno ć najlepszego wyniku. Kolejno ć technologii w rankingu testu odczytu dużego pliku jest identyczna na urządzeniu fizycznym oraz na emulatorze.

Na podstawie przeprowadzonego testu sortowanie tablicy

można zauważyć, że użytkownik korzystający z aplikacji stworzonych w oparciu o technologie: Xamarin, Android

NDK oraz język Java nie zauważy znaczących różnic wydajno ciowych podczas wykonywania podstawowych obliczeń przez aplikację. W wypadku odczytu dużego pliku widać znaczące różnice pomiędzy wynikami wszystkich platform. Lecz oprócz aplikacji napisanej w oparciu

o rozwiązanie Apache Cordova te różnicę wydajno ciowe nie powinny przeszkadzać w codziennym użytkowaniu aplikacji.

5.1. Sortowanie tablicy

W wynikach badania sortowania tablicy na urządzeniu można zauważyć znaczne różnice czasowe pomiędzy aplikacją napisaną w oparciu o platformę Apache Cordova,

a aplikacjami napisanymi z wykorzystaniem innych

technologii. Czasy sortowania tablic aplikacji napisanych

w oparciu o Xamarin, Android NDK i język Java są porównywalne i te aplikacje działają około 250% szybciej niż aplikacja korzystająca z technologii webowych. Najszybsza na

urządzeniu okazała się aplikacja napisana w języku Java.

Natomiast na emulatorze wyniki prezentują się zupełnie inaczej. Widać znaczny spadek wydajno ci aplikacji napisanej w języku Java. Jest ona prawie 13 razy mniej wydajna

od aplikacji pisanych w technologiach Xamarin i Android

NDK. Stosunek wydajno ci aplikacji napisanej w Apache

Cordova do aplikacji napisanych w Android NDK i Xamarin

jest prawie identyczny w wynikach testów przeprowadzonych

na urządzeniu fizycznym i wynikach testów przeprowadzonych na symulatorze. Najszybszymi okazały się aplikacje napisane z wykorzystaniem technologii Xamarin

i Android NDK otrzymując prawie identyczne czasy z różnicami rzędu pojedynczych milisekund.

5.2. Zapis dużego pliku

W te cie zapisu dużego pliku najlepszy wynik na urządzeniu osiągnęła aplikacja napisana z wykorzystaniem narzędzi Xamarin. Podobne, ale nieco gorsze rezultaty uzyskały kolejno programy napisane z użyciem Android SDK w języku Java, oraz Android NDK i języka C++. Aplikacja

stworzona z wykorzystaniem Apache Cordova zapisywała plik o wielko ci 10 MB najdłużej, z czasem około 2 sekund. Dla porównania pozostałe aplikacje radziły sobie z tym zadaniem w czasie poniżej pół sekundy.

Na testach dokonanych na emulatorze najszybszą platformą był Xamarin. Pokonał on drugi w kolejno ci Android NDK o ok. 20%. W danym te cie trzecie miejsce zajęła platforma Apache Cordova z wynikiem ok. dwa razy

gorszym od pierwszego miejsca. Najdłużej test wykonywał się na aplikacji napisanej w języku Java. Czas wykonania był prawie siedmiokrotnie dłuższy od czasu wykonania podobnej aplikacji napisanej w oparciu o technologie webowe i wynosił ponad trzy sekundy.

5.3. Odczyt dużego pliku

Odczyt dużego pliku na urządzeniu trwa od 75 milisekund

do 4.3 sekundy. Najlepsze osiągi ma aplikacja napisana z wykorzystaniem Android NDK, a najgorsze wyniki osiągnął program napisany w technologiach webowych. Aplikacje

stworzone przy pomocy rozwiązania Xamarin oraz języka Java odczytują pojedynczy plik o rozmiarze 10 MB

w ok. 0.5 sekundy. Jest to zauważalna różnica dla przeciętnego użytkownika systemów mobilnych.

Na wynikach testów na emulatorze można zauważyć mniejszą różnicę pomiędzy wynikami. Niechlubną ostatnią pozycję podczas tego testu osiągnęło rozwiązanie stworzone przy pomocy Apache Cordova. Jego wydajno ć była ponad 5 razy mniejsza od plasującej się na trzeciej pozycji aplikacji napisanej w języku Java. Różnica w wydajno ci pomiędzy rozwiązaniami stworzonymi w oparciu o platformę Xamarin

i Android NDK nie jest zauważalna z punktu widzenia przeciętnego użytkownika.

6. Wnioski

Na podstawie przeprowadzonych na potrzeby artykułu testów można wysnuć następujące wnioskiŚ

Platforma Apache Cordova w dużym stopniu odstaje wydajno ciowo od pozostałych opisanych technologii.

Najprawdopodobniej wynika to ze sposobu działania technologii webowej. Logika aplikacji opiera się na języku JavaScript, który jest parsowany i kompilowany

w momencie uruchomienia. Ponadto przy korzystaniu

z zasobów zewnętrznych silnik platformy Apache

Cordova musi przenosić dane pomiędzy warstwą natywną a warstwą webową. Podczas testów zaobserwowano znaczącą różnicę w czasie wykonania między aplikacją napisaną w języku Java uruchamianą na urządzeniu fizycznym a emulatorze. Często był to spadek w rankingu względem innych

technologii. Może to wynikać z niższej wersji systemu Android na emulatorze niż testowanym urządzeniu oraz

gorszej optymalizacji rodowiska uruchomieniowego


72

Android (ART) języka Java na emulatorze niż na urządzeniu. Na podstawie przeprowadzonych testów nie można jednoznacznie stwierdzić które narzędzie pozwala tworzyć najwydajniejsze aplikacje. Najwydajniejszą technologią

na urządzeniu dla kolejnych scenariuszy testowych:

sortowania tablicy, odczytu dużego pliku, zapisu dużego pliku są kolejnoŚ język Java, Android NDK oraz Xamarin.

Uzyskane wyniki pozwalają pokazać, że istnieją rozwiązania służące do tworzenia wieloplatformowych aplikacji mobilnych, które nie ustępują wydajno ciowo rozwiązaniom natywnym. Dzięki temu można szybciej tworzyć aplikacje mobilne nie tracą na wydajno ci ich działania. Ponadto dzięki zastosowaniu takich rozwiązań zmniejsza się czas i koszt utrzymywania aplikacji dzięki współdzieleniu dużych czę ci kodu pomiędzy platformami.

Literatura

[1] View | Android Developers, https://developer.android.com/

reference/android/view/View.html [30.06.2017]

[2] Android NDK | Android Developers,

https://developer.android.com/ndk/index.html [30.06.2017]

[3] Batyuk L., Schmidt A. D., Schmidt H. G., Camtepe A.,

Albayrak S. , Mobile Wireless Middleware, Operating Systems

and Applications – Workshops, Springer, 2009, 381-392

[4] Yadav R. K., Bhadoria R. S., Performance analysis for Android

runtimes environment, IEEE, 2015

[5] Gerasimov V. V., Bilovol S. S., Ivanova K. V., Comparative

analysis between Xamarin and PhoneGap for .Net, 2015

[6] Ptitsyn P. S., Radko D. V., ARPN Journal of Engineering and

Applied Sciences, vol. 11, no. 19, 2016, 11300-11307

[7] Corral L., Sillitti A., Succi G., Mobile multiplatform

development: An experiment for performance analysis,

Procedia Computer Science, 2012

[8] Delia L., Galdamez N., Thomas P., Corbalan L., Pesado P.,

Multi-Platform Mobile Application Development Analysis,

Research Challenges in Information Science (RCIS), 2015

[9] Lin C.M., Lin J.H., Dow C.R., Wen C.M., Benchmark Dalvik

and Native Code for Android System, IEEE, 2011

[10] Peppers J., Xamarin Crossplatform Application Development,

Packt Publishing, 2014

[11] Cadmen R.K., Apache Cordova in Action, Manning

Publications, 2015

JCSI 6 (2018) 73-76



73

Analiza porównawcza narzędzi online do zarządzania i komunikacji w projektach informatycznych

Łukasz Naumiuk*, Elżbieta Miłosz


Streszczenie. W artykule przedstawiono rezultaty analizy porównawczej wybranych narzędzi online do zarządzania i komunikacji w projektach informatycznych. Badania przeprowadzono przy pomocy analizy wielokryterialnej oraz eksperymentu naukowego, który polegał na utworzeniu harmonogramu projektu w badanych aplikacjach. Rezultaty badań pozwoliły okre lić warto ci zmiennych diagnostycznych, które pomogły wybrać najlepsze narzędzie.

Słowa kluczowe: analiza porównawczaś narzędzia onlineś zarządzanie projektemś komunikacja w projekcie



Comparative analysis of online tools for management and communication

in IT projects

Łukasz Naumiuk*, Elżbieta Miłosz


Abstract. The article presents the results of comparative analysis of selected online tools for management and communication in IT projects.

The research was carried out using a multicriteria analysis and a scientific experiment which consisted in creating a project schedule in the

studied applications. The results of the study allowed one to determine the values of diagnostic variables that helped to select the best tool.

Keywords: comparative analysis; online tools; project management; communication in the project



1. Wstęp

Początków pojęcia projektu można szukać już w czasach starożytno ci. Historia jego kształtowała się razem z rozwojem społeczeństwa, zostawiając lad w postaci piramid, linii kolejowych czy też rakiet kosmicznych lub operacji wojskowych. Dopiero w XX w. nastąpiło uporządkowanie wiedzy i wprowadzenie technik jak i narzędzi do zarządzania projektami. Stało się to ze względu na dynamiczny rozwój wiata biznesu, duże projekty

rządowe, które stanowiły problem, je li były zarządzane starymi metodami. Dało to możliwo ć rozwoju metodyk

związanych z zarządzaniem projektami [1].

Obecnie pojęcie projektu występuje praktycznie we wszystkich dziedzinach życiaŚ w edukacji, gospodarce,

kulturze, sporcie, administracji publicznej, wojsku itd.

Zostało to spowodowane przez szybki i znaczny wzrost zasobów informacji towarzyszący rozwojowi firm. Na

wiecie istnieje wiele różnych definicji pojęcia „projekt”.

Według Project Management Institute (PMI) „(projekt) jest

tymczasowym przedsięwzięciem mającym na celu stworzenie unikalnego produktu lub usługi, gdzie tymczasowość oznacza, że przedsięwzięcie ma ściśle oznaczony początek i koniec,

a unikalność, że produkt lub usługa w wyraźny sposób jest

inna na wszystkie podobne produkty lub usługi”[2]. A więc aby przedsięwzięcie mogło nosić miano projektu potrzebne

jest zdefiniowanie okre lonych atrybutów działania. Najważniejszymi cechami projektu są tymczasowo ć, celowo ć, niepowtarzalno ć oraz złożono ć. Zatem projektem informatycznym można nazwać stworzenie bądź modernizację systemu informatycznego poprzez powiązanie ze sobą zasobów ludzkich, sprzętu, oprogramowania, elementów organizacyjnych i informacyjnych, które przetwarzają dane za pomocą technik komputerowych

zgodnie z dokumentacją techniczną, która została wcze niej stworzona dla danego projektu. Projekty informatyczne

dotyczą głównie wdrożenia struktur IT, wdrożenia oprogramowania, czy też jego wytworzenia[3,4].

2. Metodyki zarządzania projektami informatycznymi

2.1. PRINCE2

PRINCE2 (Projects in Controlled Environments) jest

brytyjskim standardem zarządzania projektami. Został opublikowany w 1996 r. Podej cie to może być stosowane przy wszystkich typach projektów, ponieważ dotyczy tylko


74

działań związanych z zarządzaniem projektem, a nie wnika bezpo rednio w charakter prac wykonywanych przez zespół projektowy. Technika ta może być stosowana również do projektów dowolnej wielko ci. Metodyka ta okre la obowiązki oraz odpowiedzialno ć decyzyjną i wykonawczą. Wyróżnia się podej ciem procesowym do zarządzania projektem. Definiuje siedem procesów najwyższego rzędu, które dzielone są na podprocesy [5,6].

Zalety wykorzystania PRINCE2:

Zapewnia wysoką standaryzację i powtarzalno ć projektów o takim samym podej ciu, terminologii

i dokumentacji. Jej stosowanie nie wymaga opłat autorskich. Materiały PRINCE2 są opublikowane i ogólnodostępne. Sprawuje kontrolę nad startem, realizacją i zakończeniem projektu.

Wady PRINCE2:

Syndrom PINO (Prince In Name Only – Prince tylko

z nazwy) Duży nacisk na dokumentacje sprawia, że dokumenty stają się celem samym w sobie zamiast skupić się na realizacji projektu. PRINCE2 nie definiuje wprost analizy wymagań.

2.2. PMBoK

PMBoK został opublikowany przez Project Management

Institute w 1983 r. w formie białej księgi, która miała stanowić próbę udokumentowania i standaryzacji informacji

i praktyk związanych z zarządzaniem projektami. Dzięki temu powstał zbiór wiedzy, najlepszych i powszechnie stosowanych rozwiązań w dziedzinie zarządzania projektami.

Project Management Body of Knowledge ukierunkowany jest

na zestaw konkretnych technik i narzędzi zarządczych opisując prace jako wyniki pojedynczych procesów. Procesy pogrupowane są w 5 grup i 10 obszarów wiedzy [7].

Pięć podstawowych grup procesów w PMBok to:

1) procesy rozpoczęcia,

2) procesy planowania,

3) procesy realizacji,

4) procesy kontroli,

5) procesy zakończenia.

Wła ciwą czę ć PMBok stanowi 10 następujących obszarów wiedzy:

1) zarządzanie integralno cią projektu,

2) zarządzanie zakresem,

3) zarządzanie czasem,

4) zarządzanie kosztami, 5) zarządzanie jako cią,

6) zarządzanie zasobami ludzkimi, 7) zarządzanie komunikacją,

8) zarządzanie ryzykiem,

9) zarządzanie zaopatrzeniem,

10) zarządzanie interesariuszami.

2.3. IPMA

International Project Management Association (IPMA)

jest organizacją założoną w 1965 r. Wskazuje na konkretne

kompetencje w trzech obszarach, które są potrzebne dla kierownika projektu. Główny obszar to kompetencje techniczne, które są istotą całego zarządzania projektami i mają związek z tworzeniem produktów projektu. Kierownik

zespołu powinien posiadać cechy negocjatora, motywatora

i przywódcy tak, aby łatwo radzić sobie z problemami powstałymi przy pracy nad projektem. IPMA nie proponuje cisłej metodyki, a jedynie wytyczne. Opiera się na dobrych

praktykach i elastycznym dostosowywaniu się do rozwiązań dla potrzeb konkretnego klienta. Połączenie kompetencji behawioralnych z technikami zarządzania i wiedzą kontekstową pozwala stworzyć czterostopniowy cykl certyfikacji pozwalający rozwijać się z poziomu członka zespołu do dyrektora zarządzającego dużą firmą [8].

2.4. SCRUM

SCRUM najczę ciej wykorzystywany jest przy wytwarzaniu produktów oraz przy prowadzeniu innowacyjnych projektów o nieznanym lub wysokim stopniu niepewno ci. Rozwój produktu dzielony jest na iteracje

trwające maksymalnie miesiąc kalendarzowy (zwany sprintem). Po każdym sprincie zespół jest w stanie dostarczyć działającą wersję produktu. Zazwyczaj zespół składa się z od 3 do 9 osób. Główne role w projekcie pełniąŚ Zespół Deweloperski (grupa osób, składająca się z ludzi

odpowiedzialnych za dostarczenie produktu), Wła ciciel produktu (osoba reprezentująca klienta), Scrum Master –(osoba odpowiedzialna za usuwanie przeszkód uniemożliwiających zespołowi wykonanie zadania, oraz poprawną implementację procesu i metod).. Wła ciciel produktu może być członkiem zespołu jednak nie powinien on być członkiem Scrum Master. [9].

2.5. TENSTEP

TENSTEP stanowi metodykę zarządzania projektami stworzoną na podstawie biblioteki dobrych praktyk PMBoK. Charakteryzuje się tym, że każdy kolejny krok odpowiada na

potrzebę zwiększenia dyscypliny zarządzania projektem wraz ze wzrostem jego skali. Priorytet ustalają numeracja poszczególnych kroków. Zaletą tej metody jest skalarno ć oraz elastyczno ć proponowanych rozwiązań. Standard pozwala na stworzenie struktury odpowiedzialno ci i uprawnień w grupie projektowej. Projekty realizowane są w sposób prosty, a podejmowanie w nich trudnych decyzji

w ciężkich sytuacjach korzystnie wpływa na zmniejszenie się poziomu ryzyka [10].

Zdefiniowane kroki TenStep to [10]:

Krok 1: Zdefiniowanie pracy do wykonania.

Krok 2Ś Budowanie planu budżetu

Krok 3Ś Zarządzanie harmonogramem i budżetem

Krok 4Ś Zarządzanie problemami krytycznymi Krok 5Ś Zarządzanie zmianą Krok 6Ś Zarządzanie komunikacją


75

Krok 7Ś Zarządzanie ryzykiem

Krok 8Ś Zarządzanie ludźmi Krok 9Ś Zarządzanie jako cią

Krok 10Ś Zarządzanie pomiarami

3. Cel badań oraz medody i narzędzia badawcze

Celem prowadzonych badań było porównanie wybranych aplikacji internetowych do zarządzania i komunikacji w projektach informatycznych, dostępnych na rynku. Wybrano siedem aplikacji znalezionych przy pomocy

wyszukiwarki Google, które zamieszczone były na listach rankingowych:

1) OpenProject,

2) Trello,

3) Podio,

4) Wrike,

5) Bugilo,

6) Asana,

7) ZohoProjects.

Podczas rejestracji w aplikacjach okazało się, że wystąpił problem techniczny w aplikacji ZohoProjects, przez co

rejestracja nie była możliwa. Z tego powodu zaistniała konieczno ć wyłączenia tej aplikacji z analizy. Ostatecznie więc w przeprowadzonym badaniu wzięło udział sze ć aplikacji oferujących możliwo ć zarządzania projektami online.

W pracy sformułowano dwie hipotezy badawcze, które starano się udowodnićŚ

H1Ś Program Trello stanowi najlepsze rozwiązanie dla uczestników projektu

H2Ś Rozwiązania zaprezentowane w Bugilo zapewniają najlepszą kontrolę i planowanie pracy dla kierownika zespołu.

Porównanie wybranych aplikacji internetowych

przeprowadzono metodą analizy wielokryterialnej. Analiza

porównawcza oparta była na następujących 6 kryteriach,

które zostały stworzone na potrzebę prowadzonych badań

w oparciu na do wiadczeniach z pracy w programie MS Project:

1) Funkcjonalno ć platformy (czy aplikacja posiada daną funkcjonalno ć?)Ś a. -Tworzenie listy zadań

b. -Tworzenie wykresów Gantta

c. -Definiowanie zasobów projektu

d. -Przydzielanie zasobów do zadań

e. -Zarządzanie kosztami projektu

f. - ledzenie realizacji projektu

g. -Polska wersja językowa

2) Łatwo ć rejestracji (ocena procesu rejestracji użytkownika oceniana w punktach)

3) Wygląd witryny (wygląd aplikacji po zalogowaniu się, oceniany w punktach)

4) Przyjazno ć interfejsu (łatwo ć i intuicyjno ć wykorzystania aplikacji oceniana w punktach)

5) Jako ć komunikacji (ocena jako ci komunikacji w projekcie, oceniana w punktach)

6) Możliwo ć rozszerzenia aplikacji (czy istnieje możliwo ć rozszerzenia aplikacji o dodatkową funkcjonalno ć?)

Za każde kryterium użytkownik tworzący projekt w testowanej aplikacji mógł przyznawać okre loną liczbę punktów. Nie przyznawano punktów niepełnych. I tak odpowiednio: 0 - 7 pkt za funkcjonalno ć (1 punkt za posiadaną

funkcjonalno ć aplikacji lub 0 punktów za jej brak) 0 - 2 pkt za łatwo ć rejestracji 0 - 4 pkt za wygląd aplikacji 0 - 3 pkt za przyjazno ć interfejsu 0 - 2 pkt za jako ć komunikacji 0 - 2 pkt za możliwo ć rozszerzenia aplikacji.

Maksymalnie aplikacje mogły zdobyć 20 punktów. Oceny aplikacji dokonywano tworząc w nich harmonogram mobilnej gry free to play na platformę Android i IOS, który

stanowił narzędzie badawcze.

4. Rezultaty analizy programów online do zarządzania i komunikacji w projektach informatycznych

Wszystkim kryteriom analizy porównawczej zostały potraktowane jednoznacznie i zostały im przypisane jednakowe wagi. Końcowe wyniki uzyskane przez poszczególne aplikacje przedstawia tabela 1.

Tylko jedna z testowanych aplikacji posiadała wszystkie wymienione funkcjonalno ci. Jest nią OpenProject. Drugą pod względem funkcjonalno ci aplikacją jest Bugilo. Program oferuje możliwo ć zarządzania kosztami przedsięwzięcia, jednak brakuje w nim możliwo ci tworzenia wykresów Gantta oraz definiowania i przydzielania zasobów do zadań. Program posiada pełny polski interfej,s co znacząco ułatwia pracę w tym narzędziu. Pozostałe aplikacje oferują jedynie funkcjonalno ć przydatną przy tworzeniu małych projektów, w których nie trzeba zarządzać kosztami ponieważ oferują jedynie możliwo ć tworzenia list zadań oraz ledzenie postępu prac nad nimi. Wszystkie aplikacje dostały maksymalną liczbę punktów za proces rejestracji, ponieważ był on prosty i bezproblemowy. Aplikacja ZohoProject

została wykluczona z analizy poprzez problem z rejestracją na platformie, ponieważ bez rejestracji w aplikacji nie było możliwe utworzenie w niej harmonogramu.

Dwie z testowanych aplikacji (Trello oraz Wrike)

dostały maksymalną liczbę punktów za przyjazno ć interfejsu, ponieważ proces tworzenia nowego projektu

przebiegał w nich bardzo szybko i intuicyjnie. Nawet nowi użytkownicy nie powinni mieć z tym problemu. Najmniej przyjaznym programem do tworzenia projektu okazała się aplikacja Podio ze względu na brak polskiej wersji językowej oraz skomplikowany i mało intuicyjny interfejs.

Mimo skomplikowanego i czasochłonnego procesu tworzenia projektu, aplikacja Podio zapewnia najlepszą komunikację dla kierownika zespołu oraz członków projektu. Jako jedyna z testowanych aplikacji zapewnia możliwo ć

kontaktu bezpo redniego między członkami projektu udostępniając im czat, możliwo ć tworzenia konferencji i wideokonferencji, a także możliwo ć dyskusji pod każdą aktywno cią w projekcie. Pozostałe aplikacje umożliwiają w większym bądź mniejszym stopniu możliwo ć


76

komentowania aktywno ci użytkowników we wcze niej utworzonych zadaniach, co jest wystarczające aby prowadzić projekt.

Tabela 1. Wyniki uzyskane przez aplikacje.

Nazwa aplikacji

Kryterium Op

en

Pro

ject

Trel

lo

Po

dio

Wrik

e

Bu

gil

o

Asa

na

Funkcjonalność 7 3 2 2 4 2

Tworzenie listy

zadań 1 1 1 1 1 1

Tworzenie

wykresów Gantta

1 0 0 0 0 0

Definiowanie

zasobów projektu

1 0 0 0 0 0

Przydzielanie

zasobów do zadań

1 0 0 0 0 0

Zarządzanie kosztami

projektu 1 0 0 0 1 0

ledzenie realizacji

projektu 1 1 1 1 1 1

Polska wersja

językowa 1 1 0 0 1 0

Łatwość rejestracji 2 2 2 2 2 2

Wygląd witryny 3 3 2 3 3 3

Przyjazność interfejsu 2 3 1 3 2 2

Jakość komunikacji 1 1 2 1 1 1

Możliwość rozszerzenia

aplikacji 0 1 2 1 0 1

Suma 14/20 13/20 11/20 12/20 12/20 11/20

Istnieje również możliwo ć rozszerzenia aplikacji o dodatkową funkcjonalno ć. Aplikacją, która góruje nad innymi możliwo ciami rozszerzenia swojej funkcjonalno ci jest Podio, jednak ze względu na swoją złożono ć bez zainstalowanych dodatkowych funkcji jest do ć trudna w obsłudze. Również programy Trello, Wrike i Asana oferują możliwo ć rozszerzenia swojej funkcjonalno ci, jednak

w programie Trello mimo dużej liczby dodatkowych aplikacji

występuje ograniczenie do tylko jednego dodatku do projektu

w wersji darmowej, natomiast ilo ć dodatkowych rozszerzeń w aplikacji Wrike jak i Asana jest bardzo mała.

5. Wnioski

W pracy przeprowadzono analizę najistotniejszych cech

aplikacji do zarządzania i komunikacji w projekcie informatycznym oraz dokonano porównania wybranych

6 narzędzi do tego celu przeznaczonych. Zgodnie

z przeprowadzonymi badaniami, a tym samym analizując badane aspekty najlepszą aplikacją okazał się Open Project, oferujący największą funkcjonalno ć, która stanowi podstawę do zarządzania dużymi projektami informatycznymi.

W badaniach postawiono hipotezę, że Program Trello

stanowi najlepsze rozwiązanie dla uczestników projektu, Analizując tabelę 1 aplikacja ta znajduję się na drugiej pozycji pod względem uzyskanej ilo ci wszystkich punktów. Można przyjąć, że jest to dobre rozwiązanie jednak nie jest ono najlepsze z po ród wybranych aplikacji. Zatem pierwszą hipotezę należy odrzucić. Druga hipoteza to przypuszczenie,

że rozwiązania zaprezentowane w Bugilo zapewniają najlepszą kontrolę i planowanie pracy dla kierownika

zespołu. Również i tę hipotezę należy odrzucić, ze względu na to, że rozwiązania zaprezentowane w Open Project wydają się być lepsze od tych zaprezentowanych Bugilo..

Rynek aplikacji oferujących zarządzanie i komunikację

w projektach informatycznych rozwija się bardzo dynamicznie, więc możliwe jest ze powstały już bądź powstają rozwiązania lepsze, oferujące bogatszą funkcjonalno ć oraz zapewniające lepszą komunikacje dla kierownika i członków zespołu niż zaprezentowane w tej pracy. Niemniej jednak aplikacje zaprezentowane w tym

przeglądzie pozwalają na zarządzanie małymi przedsięwzięciami jak i tymi bardziej złożonymi i czasochłonnymi.

Literatura

[1] Frączkowski K.Ś Zarządzanie projektem informatycznym. Oficyna Wydawnicza Politechniki Wrocławskiej. Wrocław 2013.

[2] Strojny J., Szmigiel K.: Modern Management review mmr, vol.XX,

22(3/2015), pp 249-265 Publishing House of Rzeszow University

of Technology, Rzeszów, 2015.

[3] A.K. Munns, B.F. Bjeirmi, The role of project management in

achieving project success, “International, Journal of Project Management”, 14/2, 1996.

[4] http://4pm.pl/artykuly/trojkat-ograniczen - 10.06.2017

[5] Bradley K.: Understanding PRICE2,SPOCE Project Management

Ltd, Poole 2002.

[6] PRINCE2. Skuteczne zarządzanie projektami, OGC, Londyn 2009

[7] A Guide to the Project Management Body of Knowledge, Fifth

Edition, PMI, USA 2012.

[8] Dałkowski B, Zalewski M, Sta to L.Ś Polskie Wytyczne Kompetencji IPMA (National Competence Baseline – NCB),

wersja 3. Stowarzyszenie Project Management Polska, 2009.

[9] http://www.scrumguides.org/ - official Scrum Guide PDF in

English - 10.06.2017.

[10] Pietras P, Zarządzanie projektami. Wybrane metody i techniki, Oficyna Księgarsko-Wydawnicza "Horyzont", Łódź, 2003.

JCSI 6 (2018) 77-81

Wysłane: 2017-11-13


77

Porównanie wydajności emulatora i fizycznego urządzenia z systemem Android

w oparciu o algorytm szachowy

Kamil Litkowski*, Jakub Smołka


Streszczenie. W artykule omówione zostały zagadnienia dotyczące różnic wydajności między emulatorami Android Emulator w wersji 26.1.4

i BlueStacks App Player 3 oraz fizycznymi urządzeniami mobilnymi z systemem Android. Wydajność zostaje mierzona poprzez pomiar czasu wykonywania algorytmu szachowego. W artykule opisane zostały dotychczasowe badania związane z daną tematyką. Przedstawiona została także metoda badań, wyniki badań bazujących na algorytmach szachowych oraz wnioski z nich płynące.

Słowa kluczowe: emulator; android; wydajność



Performance comparison of an emulator and physical Android mobile device

based on chess algorithm

Kamil Litkowski*, Jakub Smołka


Abstract. Article discusses performance differences of emulators Android Emulator version 26.1.4 and BlueStacks App Player 3 and physical

devices with Android platform. Performance is measured by the chess algorithm execution time. Article also describes previous research related

to this subject. The article also presents the used research methods, results of research based on chess algorithms and conclusions.

Keywords: emulator; android; performance



1. Wstęp

W ostatnim czasie, ze względu na postęp technologiczny

w zakresie miniaturyzacji, można zauważyć gwałtowny rozwój urządzeń mobilnych oraz systemów operacyjnych na

nie przeznaczonych. Systemy te przenoszą część

funkcjonalności komputerów do urządzeń mobilnych. Dane

urządzenia mobilne zostały nazwane smartfonami (ang. smartphone). Niewielki rozmiar w połączeniu z mnogością funkcjonalności zaowocował ogromnym wzrostem popularności.

Najbardziej znanymi mobilnymi systemami operacyjnymi

są: Android, iOS, Windows Phone oraz BlackBerry.

Aktualnie najpopularniejszym z nich jest Android [1]. Jego

popularność skutkuje rozwojem emulatorów pozwalających uruchamiać dany system oraz aplikacje przeznaczone na

niego na innych urządzeniach. Emulatory w tym przypadku

znajdują zastosowanie przy testowaniu tworzonych aplikacji

oraz, coraz częściej, wykorzystywane są do korzystania z aplikacji nie mających odpowiedników na inne rodzaje

urządzeń lub w celu wypróbowania aplikacji. W przypadku

konsol lub innych urządzeń, których głównym celem jest rozrywka, główną funkcjonalnością emulatorów jest korzystanie na innych urządzeniach z aplikacji

przeznaczonych tylko na urządzenia mobilne.

Do najbardziej popularnych darmowych emulatorów należą Android Emulator wykorzystujący

Android Virtual Device (AVD), BlueStacks App Player,

Andy oraz Genymotion [2]. Najpopularniejszym z nich jest

Android Emulator zintegrowany ze środowiskiem programistycznym Android Studio. Pozwala na tworzenie

wirtualnych urządzeń o wybranych parametrach sprzętowych oraz wybranej wersji systemu. Daje on możliwość

przyspieszenia działania emulatora za pomocą specjalnych narzędzi, dostępnych za pomocą Android SDK, także zintegrowanego z Android Studio. Pozostałe wymienione

emulatory nie oferują takiej elastyczności w tworzeniu

wirtualnych urządzeń, jednak mogą konkurować pod względem wydajności, a do ich głównych zalet zaliczają się prostota i intuicyjność obsługi oraz dodatkowe

funkcjonalności przydatne w niektórych zastosowaniach,

np. wbudowana możliwość nagrywania filmów

i strumieniowania w BlueStacks App Player. Godny uwagi

jest także projekt Android-x86 umożliwiający uruchomienie

Androida na urządzeniu opartym o architekturę x86.

Celem artykułu jest zbadanie wydajności obliczeniowej

mierzonej poprzez czas wykonywania algorytmu szachowego

dla wybranych emulatorów urządzeń z systemem Android

w porównaniu do fizycznych urządzeń mobilnych przy

szczególnym uwzględnieniu wysokiego wykorzystania


78

zasobów. Analiza zostaje dokonana przy wykorzystaniu

algorytmu szachowego z rodziny mini-max cechującego się dużą ilością obliczeń niezbędnych do określenia wartości punktowej ruchów w drzewie ruchów na podstawie

aktualnego stanu planszy. Analiza została poprzedzona

przeglądem literatury dotyczącej emulatorów urządzeń z systemem Android oraz ich wydajności.


Emulatory zawierają dużą część funkcjonalności fizycznego urządzenia, część aplikacji oraz umożliwiają instalowanie nowych [3]. Do najczęściej wykorzystywanych

darmowych emulatorów należą między innymi Android Emulator korzystający z Android Virtual Device (AVD),

BlueStacks, Andy oraz Genymotion [2].

Zagadnienie wydajności emulatorów podjął Mihai Neacsu

w artykule „Benchmark time: Comparing Andy, AmiDuOS,

Genymotion, BlueStacks”. Stwierdzono w nim, że Andy występuje w wersji darmowej, BlueStacks oraz Genymotion są dostępne w wersji freemium – część funkcjonalności jest

płatna, natomiast AmiDuOS jest płatny, a do darmowego

korzystania przeznaczona jest jedynie trzydziestodniowa

wersja próbna. Wydajność zbadano za pomocą dwóch programów: AnTuTu Benchmark oraz 3D Mark. Oba

pozwalały określić szczegółowe wyniki pod kątem wybranych

aspektów działania, m. in.: wydajności procesora oraz pamięci RAM, przetwarzania grafiki 2D oraz 3D, odczytu i zapisu

danych oraz działania bazy danych. W obu aplikacjach

najlepszym emulatorem okazał się Andy. Jednak biorąc pod uwagę składowe wyniki, nie można dokonać tak

jednoznacznej oceny, gdyż każdy z badanych emulatorów okazał się najlepszy w co najmniej jednej z badanych

kategorii. Wynika z tego, że w zależności od zastosowania najlepszy okazywał się inny z emulatorów. Zaskakująco największą liczbę najlepszych pojedynczych wyników uzyskał Genymotion, plasujący się w zbiorczych testach na

przedostatniej oraz ostatniej pozycji [4].

Lauren Darcey oraz Shane Conder omawiają problem wydajności emulatorów w artykule „Supercharge Your Slow

Android Emulator”. Wskazane zostają tam powody niskiej

wydajności wirtualnych urządzeń oraz omówione zostają sposoby na znaczące jej ulepszenie. Jako przyczyna

zwiększenia wydajności zostaje wskazane przeniesienie

systemu Android na architekturę x86 przez Intel, co pozwoliło na opracowanie obrazów systemu opartych o nią, a w efekcie

pozwalających na znacznie szybsze działanie na urządzeniach

o nią opartych niż w przypadku emulacji architektury ARM. Do faktycznego przyspieszenia działania konieczne okazało się także opracowanie specjalnego sterownika. Został on stworzony przez firmę Intel i otrzymał nazwę Intel Hardware

Accelerated Execution Manager (HAXM). W dalszej części artykułu omówiono zasady działania tego sterownika oraz

przedstawiono konfigurację krok po kroku, a następnie

przeprowadzono badania porównujące wydajność emulatorów opartych o architektury x86 oraz ARM. Wykazano

wielokrotną różnicę w szybkości działania. W kolejnej części artykułu przeprowadzone zostały badania zawierające również pomiary przeprowadzone na fizycznych urządzeniach. Jednak

mogły zostać wykorzystane jedynie w celach poglądowych z powodu brakuporównania urządzeń pod względem parametrów sprzętowych, a w efekcie brak miarodajności danych pomiarów [5].

Eugene Shih w artykule „Running Android emulator up to 16x faster on AWS or Google Cloud: performance

benchmarks” oraz Manon Lumeau w „How to Speed up the

Android Emulator by up to 400%”, podobnie jak autorzy powyższego artykułu, opisuje sposób na przyspieszenie działania emulatora oraz porównuje wydajność różnych emulatorów i fizycznych urządzeń. Jednakże prezentuje w tym

celu inne podejścia. W badaniach, podobnie jak w poprzednim

przypadku, nie zostały uwzględnione różnice sprzętowe między badanymi urządzeniami [6, 7].

Wart odnotowania jest także artykuł „Performance analysis of selected hypervisors (Virtual Machine Monitors VMMs)” autorstwa Adama Arciszewskiego oraz Waldermara

Graniszewskiego. Jego celem było określenie wydajności darmowych narzędzi wirtualizacji w kilku wybranych

aspektach: szybkości wykonywania obliczeń oraz odczytu i zapisu plików. Badania zostały przeprowadzone dla

VirtualBox, VirtualPC oraz porównane z wynikami bez wirtualizacji. Pierwszym rodzajem testu było sprawdzenie szybkości obliczania wartości π oraz kodowania

z wykorzystaniem algorytmu AES-256. Rezultatami drugiego

badanego przypadku były czasy odczytu oraz zapisu pliku

o rozmiarze 1GB. Oba testy zostały powtórzone wielokrotnie, a oprócz średniego wyniku podane zostały również minimalna

i maksymalna wartość oraz odchylenie standardowe. Wyniki badań zostały opracowane i zinterpretowane oraz wskazano

przesłanki do użycia każdego z rozważanych rozwiązań [8].

Przeprowadzony przegląd literaturowy wskazuje, że tematyka wydajności emulatorów oraz maszyn wirtualnych

była wielokrotnie poruszana. Jednak w przypadku emulatorów Androida brakuje obiektywnych badań uwzględniających różnice wydajności urządzeń mobilnych oraz opartych

o architekturę x86. We wszystkich przytoczonych

przypadkach nie zostały wzięte pod uwagę różnice sprzętowe pomiędzy nimi. Ich zbadanie może umożliwić projekt Android-x86 oferujący wersję systemu Android dedykowaną dla urządzeń o architekturze x86, dzięki czemu aplikacje przeznaczone na urządzenia mobilne można uruchomić bezpośrednio na komputerze, z wyłączeniem konieczności wirtualizacji.

3. Metoda badawcza

Analiza porównawcza wydajności urządzeń mobilnych

oraz emulatorów odbywa się poprzez pomiar czasu

wykonywania algorytmu szachowego. Do badań wybrana

została taka metoda ze względu na dużą ilość obliczeń oraz

możliwość sprawdzenia zachowania przy wykorzystaniu

wielu wątków.

Badania przeprowadzono na dwóch urządzeniach mobilnych oraz dwóch urządzeniach opartych o architekturę x86, na których uruchomione zostają Android

Emulator w wersji 26.1.4 oraz BlueStacks App Player 3.


79

Badania zostały podzielone na dotyczące aplikacji

jednowątkowych oraz wielowątkowych, co skutkuje możliwością zbadania zależności wydajności emulatorów i fizycznych urządzeń w odniesieniu do liczby działających wątków. Pozwala to także na sprawdzenia działania emulatorów w obliczu większej konkurencji wątków –

m.in. w przypadku przekroczenia przez liczbę wątków aplikacji liczby wątków procesora. Badania aplikacji wielowątkowej odbywają się w przypadku Android Emulator

dla jedynie dwóch rdzeni. Jest to spowodowane fazą eksperymentalną tej funkcjonalności – na obecną chwilę możliwe jest ustawienie maksymalnie takiej liczby. W celu

ograniczenia losowości pomiarów, badania zostały

przeprowadzone dziesięciokrotnie dla każdego z przypadków.

Pod uwagę wzięta została głównie uśredniona wartość pomiarów. Wszystkie czasy wyrażono w milisekundach.

3.1. Etapy badania

Pierwszym etapem badania jest określenie różnic sprzętowych między urządzeniami mobilnymi oraz urządzeniami opartymi o architekturę x86 dla wszystkich przypadków. Odbywa się to za pomocą projektu Android x86,

który umożliwia korzystanie z systemu Android na

urządzeniu opartym o architekturę x86.

Drugim etapem są pomiary przeprowadzone dla

emulatorów, a następnie porównanie ich z wynikami otrzymanymi w trakcie testów urządzeń mobilnych oraz przy

wykorzystaniu projektu Android-x86 [9]. Rzeczywiste

spowolnienie emulatorów względem maszyn fizycznych pozbawione wpływu różnic wydajności urządzeń zostaje

obliczone poprzez podzielenie wyników otrzymanych dla emulatorów przez otrzymane dla projektu Android-x86, przy

założeniu, że Android-x86 wykorzystuje pełne możliwości urządzeń i że urządzenie mobilne byłoby równie wydajne jak

to oparte o architekturę x86.

3.2. Aplikacja testowa

W aplikacji testowej wykonywany jest algorytm

szachowy w przypadku pięciu różnych scenariuszy

początkowych (stan początkowy planszy), a następnie sumowane ich czasy wykonania. Aplikacja zostaje

wykorzystana w dwóch wariantach o różnym progu odcięcia ruchów, czyli różnicą między aktualnie przetwarzanym oraz

najwyższym możliwym wynikiem, po przekroczeniu której badany ruch zostaje odrzucony. Dla obu wariantów te wartości wynoszą 10 oraz 30. Ma to znaczący wpływ na

liczbę badanych gałęzi ruchów, a w efekcie na liczbę zadań.

Ponadto aplikacja zostaje wykonana w wersjach jedno-, dwu-,

cztero- oraz ośmiowątkowej.

Użyty w badaniu algorytm bazuje na algorytmach

z rodziny mini-max [10]. Tworzone jest w nim drzewo

ruchów i w przypadku każdego możliwego na podstawie

stanu planszy określana jest wartość punktowa. Wartości są obliczane dla każdej figury, a następnie w przypadku gracza

pierwszego dodawane, a w przypadku drugiego odejmowane

od łącznego wyniku. Celem gracza pierwszego jest

zmaksymalizowanie tej wartości, a drugiego

zminimalizowanie. Ponadto, w celu zmniejszenia liczby

przetwarzanych ruchów, ustalona jest różnica między

aktualnym ruchem a maksymalną wartością dla danej tury, po przekroczeniu której dana gałąź nie jest dalej przetwarzana, ze względu na niską szansę osiągnięcia w niej najbardziej

optymistycznego wariantu ruchu.

3.3. Badane urządzenia

Badane urządzenia podzielono na dwie grupy:

z uruchamianym emulatorem oraz urządzenia mobilne. Ich parametry zostały ukazane w tabelach 1 oraz 2.

Tabela 1. Urządzenia z uruchamianym emulatorem

Numer Procesor RAM

I i5-4460, 4 x 3,2GHz 8GB

II i5-7200U, 2 x 2,5GHz 8GB

Tabela 2. Urządzenia mobilne

Nr Wersja

systemu

Model Procesor RAM

III 7.0 Huawei P9

Lite

HiSilicon Kirin 650

4 x 2,0 GHz +

4 x 1,7 GHz

2GB

IV 7.1 Xiaomi

Mi5

Qualcomm

Snapdragon 820

4 x Kyro 2,2 GHz

3GB

4. Analiza wyników badań

Zbiorcze wizualizacje średnich wyników w zależności od

liczby wątków dla odpowiednio pierwszego oraz drugiego

wariantu aplikacji zostały przedstawione na rysunkach 1 oraz 2. Liczbą rzymską zostały na nich oznaczone numery urządzeń, a skrótami AVD i BS rodzaj uruchomionego na nich urządzenia wirtualnego – odpowiednio Android Virtual

Device będące wirtualnym urządzeniem tworzonym przez Android Emulator oraz BlueStacks.

Rys. 1. Wizualizacja wyników pierwszego wariantu aplikacji w zależności od liczby wątków


80

Rys. 2. Wizualizacja wyników drugiego wariantu aplikacji w zależności od liczby wątków

Na przedstawionych wykresach najlepiej widoczne są bezwzględne różnice wyników. Najbardziej negatywnie wyróżnia się BlueStacks App Player. Jest on wielokrotnie

wolniejszy od urządzeń mobilnych nawet pomimo

kilkukrotnie wyższej wydajności urządzeń w porównaniu do mobilnych. W przypadku Android Emulatora wyraźnie widoczny jest fakt niewiele gorszej lub, w niektórych przypadkach, nawet lepszej wydajności urządzeń mobilnych w porównaniu do wyników tego emulatora. Warte

odnotowania jest także to, że wydajność fizycznych urządzeń

względem emulatorów rośnie wraz ze zwiększaniem liczby

wątków aplikacji.

Wyniki dla obu wariantów aplikacji prezentują się dość podobnie. Bardzo zauważalna jest nieco mniejsza różnica w wydajności BlueStacks w stosunku do pozostałych wyników w przypadku drugiego wariantu oraz zdecydowanie

bardziej zbliżone wyniki pozostałych przypadków w wariancie pierwszym. W drugim wariancie dużo traciły urządzenia mobilne ze względu na mniejszą liczbę

wykorzystywanych wątków, a przez to brak wykorzystania

pełni ich mocy. Natomiast korzystniej prezentowały się emulatory, co wskazuje na niezbyt dobre radzenie sobie ich

z wielowątkowością.

Wizualizacje stopni pogorszenia wydajności na emulatorach z pominięciem różnic sprzętowych

(współczynnik wyliczony poprzez podzielenie wyników dla emulatorów przez osiągnięte dla projektu Android-x86)

w zależności od liczby wątków zostały ukazane na rysunkach 3 oraz 4. Znaczenie symboli na wykresach jest identyczne jak

w przypadku rysunków 1 oraz 2.

Na wykresach można zauważyć, że Android Emulator okazał się być wolniejszy 3-4 krotnie od fizycznych urządzeń, a różnica okazała się stabilna niezależnie od wariantu aplikacji oraz liczby wątków. Różnice jedynie minimalnie wzrastały wraz z liczbą wątków oraz były nieznacznie wyższe przy mniejszej liczbie wykonywanych zadań, czyli w drugim wariancie aplikacji.

Rys. 3. Wizualizacja stopnia pogorszenia wydajności dla pierwszego

wariantu aplikacji w zależności od liczby wątków

Rys. 4. Wizualizacja stopnia pogorszenia wydajności dla drugiego wariantu

aplikacji w zależności od liczby wątków

Natomiast BlueStacks okazał się wielokrotnie mniej wydajny. Porównując do fizycznych urządzeń, był od 8 do nawet 25 krotnie wolniejszy. Warto zwrócić uwagę na ogromny rozrzut powiększający się wraz z liczbą wykorzystywanych wątków – pomijając aplikację ośmiowątkową, gdy różnica okazała się mniejsza niż w przypadku czterowątkowej, jednak większa niż przy dwuwątkowej. Ponadto różnica wydajności okazała się dużo mniejsza w przypadku słabszego urządzenia, co wynika

z proporcjonalnie mniejszej różnicy wyników w przypadku emulatora niż w przypadku wybranych urządzeń fizycznych.

5. Wnioski

Przeprowadzone badania ukazały wielokrotną różnicę

pomiędzy wydajnością fizycznych urządzeń mobilnych oraz emulatorów. Wybrane do badań urządzenia różniły się typem oraz wieloma parametrami, m.in.: mocą obliczeniową procesora oraz liczbą jego rdzeni i wątków, a także ilością pamięci RAM. Pozwoliło to na zbadanie różnic również w przypadku urządzeń o ograniczonym zużyciu energii,

w przypadku gdy liczba wątków wykorzystywanych

w aplikacji przekraczała liczbę wątków procesora oraz gdy liczba wątków procesora nie była w pełni wykorzystana.

Bezwzględne wyniki badań w przypadku Android

Emulatora okazały się zbliżone do otrzymanych na

kilkukrotnie mniej wydajnych urządzeniach mobilnych. Uniknięcie czynnika różnic w wydajności urządzeń pozwoliło


81

na stwierdzenie, że Android Emulator, w zależności od liczby

wątków oraz wariantu aplikacji, okazał się 3-4 krotnie mniej

wydajny od urządzeń fizycznych. Pozwala to stwierdzić, że obciążenie oraz wielowątkowość nie mają znaczącego wpływu na jego działanie.

Natomiast w przypadku BlueStacks App Player zauważyć można wielokrotną różnicę w stosunku do urządzeń mobilnych – nawet w przypadku bezwzględnych wyników. Przy uwzględnieniu różnic wydajności urządzeń,

dysproporcja ta okazała się bardzo duża – dochodząca do niemal 25 razy.

Znaczącą rolę w wynikach badań odegrały liczba wątków oraz wariant aplikacji. Emulatory, a przede wszystkim

BlueStacks, radziły sobie słabiej od fizycznych urządzeń

z dużą liczbą wątków oraz ich synchronizacją. Znacznie lepsze wyniki, w porównaniu do urządzeń fizycznych, zostały odnotowane w przypadku mniejszej liczby wątków oraz przy znacznie mniejszej konkurencji w drugim wariancie. O ile

w przypadku Android Emulatora różnice te nie były aż tak znaczące, o tyle w przypadku BlueStacks były wielokrotne.

Literatura

[1] Vincent J.,99.6 percent of new smartphones run Android

or Ios,https://www.theverge.com/2017/2/16/14634656/android-

ios-market-share-blackberry-2016 [31.05.2017]

[2] Pinola M., How to Run Android on Your PC: The Best Android

Emulators, https://www.laptopmag.com/articles/run-android-

apps-on-pc [31.05.2017]

[3] Saha A. K., A Developer’s First Look At Android. Linux For

You, 01.2008.

[4] Neacsu M., Benchmark time: Comparing Andy, AmiDuOS,

Genymotion, BlueStacks,

http://www.download3k.com/articles/Benchmark-time-

Comparing-Andy-AmiDuOS-Genymotion-BlueStacks-01443

[31.05.2017]

[5] Conder S., Darcey L., Supercharge your slow Android

emulator, http://www.developer.com/ws/android/development-

tools/haxm-speeds-up-the-android-emulator.html [31.05.2017]

[6] Shih E., Running Android emulator up to 16x faster on AWS or

Google Cloud: performance benchmarks,

https://www.ravellosystems.com/blog/android-emulator-faster-

performance-aws-google/ [31.05.2017]

[7] Lumeau M.,How to Speed up the Android Emulator by up to

400%, https://doc.nuxeo.com/blog/speeding-up-the-android-

emulator/ [31.05.2017]

[8] Arciszewski A., Gramoszewski W., Performance analysis of

selected hypervisors (Virtual Machine Monitors - VMMs).

INTL JOURNAL OF ELECTRONICS AND

TELECOMMUNICATIONS, 2016, VOL. 62, NO. 3.

[9] http://www.android-x86.org [20.09.2017]

[10] Lee C.-I. C., The min-max algorithm and isotonic regression.

The Annals of Statistics, 1983, Vol. 11, No. 2.

JCSI 6 (2018) 82-86



82

Porównanie szkieletów aplikacji AngularJS i React.js na przykładzie aplikacji internetowej

Łukasz Capała*, Maria Skublewska-Paszkowska


Streszczenie. Artykuł zawiera porównanie szkieletów aplikacji AngularJS i React.js. Dla potrzeb badawczych zostały utworzone dwie aplikacje oferujące identyczne funkcjonalno ci. Zmierzony i porównany został czas wykonania typowych zadań aplikacji internetowejŚ wstawianie,

sortowanie i usuwanie elementów z listy obiektów JavaScript.

Słowa kluczowe: javascript, angular, react, wydajno ć frameworka



Comparison of AngularJS and React.js frameworks based on a web application

Łukasz Capała,*, Maria Skublewska-Paszkowska

a

a Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. The paper contains comparison between AngularJS and React.js frameworks. For research purposes two applications that provides

the same functionalities were created. Time of typical tasks execution: elements insertion, sorting and deletion from JavaScript list of objects

was measured and compared.

Keywords: javascript, angular, react, framework performance



1. Wstęp

Standard ECMAScript 6 wprowadził do języka JavaScript elementy charakterystyczne dla popularnych

języków wysokiego poziomu, takich jak Java, C++ czy C#.

Zamiast używania funkcji jako zamienników dla obiektów zaimplementowano charakterystyczne słowo kluczowe

Class. Język JavaScript znajduje zastosowanie w prostej

manipulacji drzewem dokumentu strony internetowej w celu

interakcji z użytkownikiem. Można go wykorzystać do budowy skomplikowanych aplikacji działających w przeglądarce internetowej a także aplikacje typu server-

side (działające po stronie serwera) dzięki Node.js. Połączenie JS z responsywnymi elementami języka HTML pozwala tworzyć rozbudowane projekty, które wchodzą w interakcję z użytkownikiem bez potrzeby przeładowania okna przeglądarki internetowej (ang. single page

application) [1].

Na polu front-endu, czyli warstwy prezentacji również nastąpiły duże zmiany na przestrzeni lat. Oparte

o JavaScript szkielety aplikacji (ang. framework)

umożliwiają na rozległą, dynamiczną modyfikację zawarto ci strony a pod względem implementacji są proste w obsłudze. Operowanie na danych, takie jak wstawianie, sortowanie, usuwanie są teraz wykonywane przez program klienta, nie powodując obciążenia po stronie serwera,

poprzez wyeliminowanie zbędnych zadań. Same szkielety

opierają się również o nakładki standaryzujące i rozszerzające możliwo ci języka JavaScript (JSX, TypeScript), jednocze nie ułatwiając programi cie budowanie aplikacji. Tak utworzone projekty są bardzo interaktywne i podobne do tych działających bezpo rednio w rodowisku systemu operacyjnego, bez połączenia z Internetem.

W ród najpopularniejszych frameworków można wymienić AngularJS (od nowszych wersji nazywany Angular) oraz React.js (lub pro ciej - React) [2]. Angular

jest rozwijany przez Google, React przez firmę Facebook.

Artykuł podejmuje temat porównania powyższych szkieletów. W każdym z nich została utworzona identyczna aplikacja. Oferowała te same funkcjonalno ci. Jedno

z porównań dotyczyło Angular w wersji 1 [3]. Liczba zmian

zawartych w wersjach 2 lub wyższych jest duża. Zmienia to całkowicie budowę aplikacji opartej o Angular.

Porównanie nie będzie pokrywało takich kryteriów jak przyswajalno ć (prędko ć opanowania zasad tworzenia aplikacji przy pomocy frameworka) czy rodzaj wzorca

projektowego.


83

2. AngularJS

Angular posiada rozbudowane możliwo ci, jeżeli chodzi o kwestię implementacji obszaru frontowego aplikacji. Najnowsza wersja 4.2.4 używa do tego języka TypeScript, który stanowi swoistą nakładkę na język JavaScript. Wprowadza on obsługę typowania oraz inne rzeczy

charakterystyczne dla znanych języków programowania. Wersja 1 i niższe były pod względem składni kodu źle oceniane przez programistów [4]. Tutaj istnieje wyraźny podział na komponenty, szablony, dyrektywy oraz serwisy. Zrezygnowano z charakterystycznej terminologii MVC

(Model Widok Kontroler, ang. Model View Controller)

znanej z poprzednich wersji narzędzia.

Atutem Angular wciąż pozostaje możliwo ć dwustronnego wiązania danych [5]. Umożliwia ona aktualizację pola obiektu komponentu poprzez interfejs

użytkownika i odwrotnie – zmienna zaktualizowana

w komponencie zmieni swoją warto ć również na warstwie prezentacji. Proces ten jest zautomatyzowany przez

framework i nie wymaga żadnej ingerencji programisty do jego wywołania.

Prosty system szablonów opartych na plikach HTML pozwala łatwo mieszać dyrektywy ze znanymi znacznikami hipertekstowymi, co ułatwia przystosowanie aplikacji pod kątem dostosowania zawarto ci do różnych urządzeń i przekątnych ekranu (ang. responsive web design). [6]

Metody zaimplementowane we frameworku można bezproblemowo testować za pomocą narzędzi testów automatycznych Javascript, takich jak Karma [7][8].

Dodatkowo dla AngularJS możliwe jest utworzenie profilu UML w celu projektowania aplikacji sterowanych

modelami. Tak zaimplementowany projekt wymaga jedynie

wypełnienia formularza generującego gotową aplikację. 87% kodu pokrywa się z ustalonymi koncepcjami co skraca czas programowania [9].

3. React.js

React klasyfikowany jest również do bibliotek JS. Ma on jednak bardzo specyficzne cechy frameworka. Jego

uporządkowanie i hierarchia powoduje, że programista ma z góry narzuconą drogę implementacji swojej aplikacji

w tym narzędziu. Tak jak w Angular tutaj również istotną rolę posiadają komponenty [10].

Komponenty są obiektami klasy, która dziedziczy po React.Component. Każdy moduł musi zawierać funkcję render(), która rysuje komponent w drzewie dokumentu. Zawierają się w niej zwykle szablony oraz

inne subkomponenty. Te drugie układają się w kompozycje. Zaczynając od komponentu nadrzędnego, kończąc na subkomponentach małych elementów sterujących aplikacją. Postać komponentu może zawierać elementy jego stanu oraz parametry (ang. props) [10].

Parametry są dla danego modułu niezmienne, stanowią jego wła ciwo ci, które może zmieniać jedynie komponent nadrzędny o ile taki istnieje. Parametrem może być na przykład wielko ć fontu napisu, liczba możliwych ocen na li cie ratingowej. Stan jest zbiorem aktualnych, dynamicznych warto ci przechowywanych w ciele komponentu. Jako przykład można podać aktualnie przeglądaną stronę książki elektronicznej czy chociażby stan rozgrywki w szachy (mat, szach).

Pisanie szablonów i wyrażeń w składni JSX może zastąpić tworzenie kodu bezpo rednio w języku JavaScript. Pozwala to uniknąć skomplikowanych struktur złożonych z zagnieżdżonych w sobie metod React.createElement [11].

Dzięki temu kod jest czytelny, łatwiejszy w modyfikacji i recenzji.

Składnia JSX przypomina połączony JavaScript z HTML. Widoki wypisywane są w postaci standardowych znaczników (plus znaczniki komponentów), ale można takie struktury przypisywać do zmiennych, tablic i pól obiektów [11].

4. Wybór odpowiedniego szkieletu

Istotnym czynnikiem w wyborze szkieletu są przede wszystkim jego koszty, programi ci wolą polegać na darmowych narzędziach. Framework powinien być jak najbardziej rozszerzalny za pomocą prostej modyfikacji kodu. Aplikacja na nim oparta, powinna zajmować mało przestrzeni dyskowej i wykonywać szybko swoje zadania [12].

Istotne są równieżŚ

1) modułowo ćś 2) przeno no ćś 3) możliwo ć manipulacji DOM (Obiektowy Model

Dokumentu, ang. Document Object Model);

4) czytelno ć koduś 5) częste aktualizacje [12].

5. Metoda i platforma testowa

Aplikacje zostały sprawdzone pod kątem prędko ci wykonywanych operacji – wstawiania, sortowania oraz

usuwania jednego lub wielu elementów przechowywanych w tablicy obiektów JavaScript. Operacja usuwania pojedynczego wiersza sprowadzona została do usunięcia rodkowego elementu listy. Badanie zostało wykonane na

komputerze typu laptop z procesorem Intel® Core™ i7-

6700HQ 2.60GHz w przeglądarce Google Chrome. Ta sama przeglądarka posiada wygodne narzędzie deweloperskie które ułatwiło pomiar czasu (od wyprowadzenia żądania do finalnej metody rysującej).

Obie aplikacje korzystały z tej samej bazy danych (przechowywanej w pliku tekstowym), zawierającej 100000 rekordów. Każdy rekord składał się z trzech kolumn zawierających ciągi znaków. Baza danych została pobrana do tablicy obiektów JavaScript. Każda z aplikacji pobierała rekordy z tablicy do mniejszej i wy wietlała zawarto ć


84

nowej macierzy w postaci tabeli HTML (funkcjonalno ć wstawiania rekordów). Sortowanie oraz usuwanie odbywa się na wy wietlonej porcji danych. Kasowanie dzieliło się na wymazywanie wszystkich elementów oraz usuwanie pojedynczego wiersza (rekordu ze rodka utworzonej tablicy).

Listing 1. Wy wietlanie tabeli rekordów – Angular

<table> <thead> <tr> <th>id</th> <th>gender</th> <th>phone</th> </tr> </thead> <tbody> <tr *ngFor='let item of records'>

<td>{{item.index}}</td> <td>{{item.gender}}</td> <td>{{item.phone}}</td> </tr> </tbody> </table>

Listing 2. Wy wietlanie tabeli rekordów - React

<table> <thead> <tr> <th>id</th> <th>gender</th> <th>phone</th> </tr> </thead> <tbody> {this.state.records} </tbody> </table>

Listing 3. Metoda sortująca

var newrecords = this.records.sort(function (a, b) { var a_key = parseInt(a.index); var b_key = parseInt(b.index); if (a_key < b_key) return -1 * order; if (a_key > b_key) return 1 * order; return 0; });

6. Wyniki badań

Badania zostały przeprowadzone pod kątem prędko ci wykonywanych operacji. Zadaniem aplikacji było wczytywanie, sortowanie i usuwanie dużej liczby rekordów (lub pojedynczego rekordu) z tablicy JavaScript

zawierającej łącznie 100000 wierszy. Każda z aplikacji musiała wy wietlić, posortować, usunąć jeden lub wszystkie elementy załadowane poprzez przyciski sterujące działaniem aplikacji. Wyniki zostały zaprezentowane zbiorczo na rysunkach od 1 do 4.

Rys. 1. Wykres redniego czasu dla operacji ładowania rekordów

Rys. 2. rednie czasy sortowania dla każdej serii badanych rekordów


85

Rys. 3. U rednione czasy usuwania wszystkich rekordów dla obu szkieletów

Rys. 4. U rednione czasy dla operacji usuwania jednego

rekordu

7. Dyskusja wyników.

Rysunek 1 pokazuje przewagę Angular dla czterech pierwszych zestawów rekordów. Dla liczby stu tysięcy czas wstawiania jest krótszy dla frameworka React. Mimo gorszego wyniku drugiego frameworka nie można jednoznacznie stwierdzić że taka minimalna różnica byłaby odczuwalna przez użytkownika w standardowym używaniu aplikacji – zwykle wprowadza się podział na strony przez co można uniknąć opóźnień w wy wietlaniu dużej liczby danych. Zbliżony wynik dla 100000 rekordów może wiadczyć o obciążeniu maszyny testowej. Manipulacja

DOM w takim zakresie jest kosztowna czasowo, niezależnie od stosowanej technologii. Platforma, na której działa aplikacja ma znaczenie również w przypadku tysiąca wierszy – niewielkie zmiany wynikają z działania samej przeglądarki, systemu operacyjnego, pracy dysku twardego.

Listing 4. Implementacja metody kopiującej obiekt

copy(current_object: any) { var object_copy = current_object; if (current_object && typeof current_object === “object”) { object_copy = Object.prototype.toString.call(current_object) === “[object Array]” ? [] : {}; for (var property in current_object) { object_copy[property] = this.copy(current_object[property]); } } return object_copy; }

rednie czasy sortowania (rysunek 2) dużej liczby rekordów pokazują że Angular radzi sobie kilkukrotnie gorzej od React. Zmiany kolejno ci elementów w Angular.js przeprowadzane są bezpo rednio na widoku –

kilkukrotnie uruchamiana jest iteracja w celu ponownego

wypisania elementów za pomocą ngFor (Listing 1). React

zmieniając stan komponentu tworzy tak zwane deep copy

obiektu, czyli kopiuje wszystkie jego atrybuty przez

warto ć, nie referencję. Pozwala to na niemal

natychmiastową podmianę zawarto ci listy. Angular

w wersji 2 i wyższej nie posiada wbudowanego kopiowania

(wcze niej istniała funkcja copy). Implementacja własnej metody kopiującej (Listing 4) pomogła skrócić czas sortowania do około 30 sekund, mimo to był to wynik 3 razy wolniejszy niż ten osiągnięty przez React. Dodatkowo takie rozwiązanie nie kwalifikowało się jako poprawny test, ponieważ używane jest dodatkowe obej cie, nie zaimplementowane bezpo rednio w danym frameworku.

Taki sam problem istnieje w przypadku usuwania

wszystkich rekordów. Rysunek 3 pokazuje, że rednie czasy wykonywania tej operacji są krótsze dla React dla liczby

rekordów [50000ś 100000]. Kolejny raz w React zawarto ć listy podmieniana jest na jej kopię, w tym wypadku pustą. Angular wykonuje dodatkowe iteracje co spowalnia cały proces.

Angular osiąga krótsze rednie czasy dla usuwania

pojedynczego rekordu. Rysunek 4 pokazuje że React jest szybszy jedynie dla 1000 rekordów. Może to być


86

spowodowane pracą maszyny testowej oraz czynnikami niezależnymi od aplikacji. Dla kolejnych serii danych jest kilkukrotnie wolniejszy. Kopiowanie obiektu podczas

zmiany stanu powoduje powstanie nadmiaru

wykonywanych operacji – potrzebne jest ponowne

uzupełnienie listy z wyłączeniem usuwanej pozycji. Angular jedynie modyfikuje wy wietlaną tabelę – usuwa

element z drzewa dokumentu, jeżeli ten nie występuje już w modelu jego komponentu.

8. Wnioski.

Operacje na dużych zbiorach danych zawsze są kosztowne czasowo. Aplikacja działająca po stronie przeglądarki klienta powinna operować jedynie na porcjach danych, wprowadzić podział na strony których zawarto ć będzie ładowana z bazy danych tylko na wyraźne żądanie użytkownika. Rendering długich list powoduje spowolnienie pracy przeglądarki, zmniejszenie responsywno ci na akcje dokonywane przez korzystającego z aplikacji.

Angular oraz React dla małej liczby rekordów osiągają zbliżone wyniki, nie wpływające na efektywno ć użytkowania strony. Dopiero operowanie na wielkich listach pokazuje przewagę React – dla sortowania oraz

usuwania dużej kolekcji. Mimo takiej prezentacji wyników używanie Angular do budowy aplikacji wcale nie jest

niezalecane. Konieczna jest przemy lana implementacja funkcjonalno ci w aplikacji zarządzającej dużą liczbą danych. Bez odpowiedniego podej cia nawet bardzo szybkie frameworki, a nawet sam JavaScript nie są w stanie zoptymalizować zarządzania strukturą hipertekstu. Długie dokumenty HTML nigdy nie będą działały tak samo dobrze jak ich krótsze odpowiedniki, wynika to z natury samego języka – jest interpretowany przez przeglądarkę.

Warto korzystać z obu narzędzi, a wybór konkretnego

zależy od potrzeb i preferencji. Dostarczają one kompletny zestaw funkcji do zbudowania dynamicznej aplikacji

internetowej typu single page. Dzisiejsze możliwo ci wręcz wymuszają na producentach oprogramowania używanie tych narzędzi. Mimo swoich zalet i wad ułatwiają pracę i skracają czas potrzebny na zbudowanie skomplikowanego projektu.

9. Literatura

[1] Stępniak, W.ś Nowak, Z.ś Performance analysis of SPA web systems, Advances in Intelligent Systems and Computing

521, s. 235-247, 2017.

[2] 5 Best JavaScript Frameworks in 2017 https://da-

14.com/blog/5-best-javascript-frameworks-2017 (dostęp 08.06.2017)

[3] Nowacki, R.; Plechawska-Wójcik, M.ś Analiza porównawcza narzędzi do budowania aplikacji Single Page Application –

AngularJS, ReactJS, Ember.js, Politechnika Lubelska, Lublin,

Polska, 2016.

[4] Kumar, A.; Singh Kumar, R.; Comparative Analysis of

AngularJS and ReactJS, International Journal of Latest Trends

in Engineering and Technology, nr 7, s. 225-227.

[5] Angular Docs https://angular.io/docs/js/latest/index.html

(dostęp 08.06.2017). [6] Patel S. K. - Responsive Web Design with AngularJS, 2014.

[7] Fat, N.; Vujovic, M.; Papp, I.; Novak, S.; Comparison of

AngularJS framework testing tools, Zooming Innovation in

Consumer Electronics International Conference, ZINC 2016.

[8] Mesbah, A.; Chapter Five – Advances in Testing JavaScript-

Based Web Applications, Advances in Computers, nr 97, s.

201-235, 2015.

[9] Chansuwath, W.; Senivongse, T.; A Model-Driven

Development of Web Applications Using AngularJS

Framework, IEEE/ACIS 15TH INTERNATIONAL

CONFERENCE ON COMPUTER AND INFORMATION

SCIENCE (ICIS), s. 683-688, 2016.

[10] Components, Props and State https://facebook.github.io/react-

vr/docs/components-props-and-state.html (dostęp 08.06.2017) [11] Vipul A M; Sonpatki, P.; ReactJS by Example – Building

Modern Web Applications with React, 2016.

[12] Pano, A.; Graziothin, D.; Abrahamsson, P.; What leads

developers towards the choice of a JavaScript framework?,

2016.

JCSI 6 (2018) 87-91



87

Porównanie wydajno ci wieloplatformowego szkieletu aplikacji na platformach Android i Windows 10 Mobile.

Dawid Wieczorek*, Jakub Smołka


Streszczenie. W artykule sprawdzono czy aplikacje napisane z wykorzystaniem wieloplatformowego szkieletu działają jednakowo wydajnie na wybranych systemach operacyjnych co rozwiązania natywne. Testowaniu poddano framework Xamarin.Forms porównując go z rozwiązaniami

natywnymi Android SDK i Universal Windows Platform na systemach Android i Windows 10 Mobile.

Słowa kluczowe: xamarin, cross-platform, android, windows



Comparison of performance multi-platform application core on Android and

Windows 10 Mobile.

Dawid Wieczorek*, Jakub Smołka


Abstract. The article examined whether applications written using the cross-platform application framework perform equally well as native

solutions on selected operating systems. The Xamarin.Forms framework was tested against the native Android SDK and Universal Windows

Platform frameworks for mobile systems Android and Windows 10 Mobile.

Keywords: xamarin, cross-platform, android, windows



1. Wstęp Celem artykułu jest porównanie wydajno ci

wieloplatformowego szkieletu aplikacji napisanej

z wykorzystaniem Xamarin oraz Xamarin.Forms. Analizę wykonano na dwóch platformach mobilnych – Androidzie

w wersji 7 Nougat i Windows 10 Mobile. Badanie obejmuje

zarówno teoretyczne aspekty wymienionego frameworku jak i testy praktyczne.

W artykule sprawdzana jest hipoteza, że tworzenie aplikacji ze wspólnym szkieletem umożliwia wydajne ich działanie niezależnie od systemu operacyjnego. Hipoteza została postawiona ze względu na to, że segment aplikacji mobilnych jest jednym z najszybciej rozwijających się segmentów aplikacji, a przed twórcami postawione jest zadanie stworzenia jednakowo wydajnych i ergonomicznych

aplikacji na różne systemy mobilne takie jak Android

i Windows 10 Mobile.

W klasycznym podej ciu każda z aplikacji na różne systemy mobilne tworzona jest z osobna, natomiast celem

twórców jest zapewnienie tej samej funkcjonalno ci niezależnie od systemu operacyjnego. Dla firm zajmujących się wytwarzaniem aplikacji mobilnych utrzymanie kilku

zespołów deweloperskich dla oddzielnych systemów mobilnych generuje wysokie koszty implementacji nowych

funkcjonalno ci oraz utrzymania danego produktu [1].

Wychodząc naprzeciw oczekiwaniom twórców oprogramowania powstają frameworki pozwalające na współdzielenie kodu źródłowego aplikacji między systemami

operacyjnymi takie jak Xamarin. Pozwalają one na tworzenie uniwersalnych aplikacji w jak najmniejszym stopniu

obciążając programistów konieczno cią dopasowania do konkretnego systemu operacyjnego. Pozwala to tworzyć oprogramowanie mobilne mniejszym nakładem pracy, a co za tym idzie niższym kosztem.

2. Natywne technologie

Stworzenie wieloplatformowej aplikacji napisanej

z wykorzystaniem natywnych technologii zabiera dużo czasu

ze względu na konieczno ć przenoszenia oprogramowania między systemami. Głównym językiem, w którym stworzone są aplikacje dla systemu Windows 10 Mobile jest C#, aplikacje dla systemu Android są natomiast implementowane w języku Java. Decydując się na korzystanie z technologii

natywnych powstają faktycznie dwie oddzielne aplikacje połączone wspólnymi zasobami takimi jak grafika, dźwięk. Dodając nowe funkcjonalno ci programi ci muszą po więcić znaczący czas na stworzenie kodu źródłowego dla obu platform. Odbija się to negatywnie na kosztach wytworzenia oprogramowania [2].

Są segmenty rynku, w których tworzenie aplikacji natywnych jest zdecydowanie lepszym rozwiązaniem niż tworzenie aplikacji wieloplatformowej. Są to między innymi aplikacje wymagające najwyższej wydajno ci obliczeniowej oraz gry wykorzystujące zaawansowaną grafikę 3D. Dodatkowym plusem aplikacji natywnych jest sprawniejsze

działanie dotyku. Gesty takie jak szczypanie i przesuwanie działają dokładnie tak, jak było to zamierzone przez


88

użytkownika. Czas odpowiedzi na daną interakcję jest dokładnie taki sam jak w pozostałych systemowych i natywnych aplikacjach. Brak warstwy po redniej zapobiega opóźnieniom dotyku [3].

3. Platforma Xamarin

3.1. Xamarin

Xamarin jest wieloplatformowym rozwiązaniem stanowiącym zunifikowane rodowisko programistyczne dla deweloperów aplikacji mobilnych. Wprowadza możliwo ć tworzenia aplikacji w języku C# dla systemu Android oraz iOS, a także obsługuje system Windows 10 Mobile. Na systemie Android działa wykorzystując interpretowany kod

IL zdolny do uruchomienia za pomocą rodowiska uruchomieniowego Mono zintegrowanego ze stworzoną aplikacją. Mono działa bezpo rednio na poziomie jądra Linuxowego, nie wykorzystując maszyny Dalvik bądź rodowiska uruchomieniowego ART, co pozwala na wydajne

działanie aplikacji [4].

Platforma Xamarin umożliwia wykorzystywanie natywnego interfejsu SDK dla systemu Android z poziomu

aplikacji. Odbywa się to poprzez wywołanie maszyny Dalvik, bądź rodowiska uruchomieniowego ART za pomocą Managed Callable Wrapper, na którym uruchamiana jest natywna funkcjonalno ć. Rezultat wykonania przesyłany jest do rodowiska uruchomieniowego Mono poprzez kanał komunikacji Android Callable Wrapper. Interakcja aplikacji

napisanej w Xamarinie z maszyną Dalvik i rodowiskiem

ART obciążona jest sporym kosztem wydajno ciowym

[5, 6, 7].

3.2. Xamarin.Forms

Xamarin.Forms jest zestawem narzędzi pozwalającym w bardzo prosty sposób definiować współdzielony wygląd aplikacji. Elementy Xamarin.Forms definiowane są za pomocą Extensible Application Markup Language (XAML).

To API dostarcza wiele gotowych wieloplatformowych

elementów interfejsu użytkownika, takich jak gotowe strony,

elementy nawigacyjne, kontenery elementów na stronach oraz kontrolki pozwalające na interakcję z użytkownikiem [8].

Interfejs zaprojektowany w Xamarin.Forms bez problemu

może być przenoszony pomiędzy różnymi systemami operacyjnymi. Elementy graficzne zaprojektowane są w taki sposób, aby wygląd odpowiadał w jak największym stopniu systemowi operacyjnemu na którym jest uruchamiany. Jako

przykład można podać wygląd elementu odpowiadającego za wprowadzanie tekstu, na systemie Android jest on

wy wietlany jako podkre lone pole tekstowe, natomiast na systemie Windows 10 Mobile pole tekstowe jest z każdej strony otoczone ramką (Rys. 1)[9].

Dostosowywanie się elementów interfejsu pozwala zwiększyć atrakcyjno ć aplikacji, które nie odstają od aplikacji natywnych napisanych dla konkretnego systemu

operacyjnego, zachowując wytyczne [10].

4. Metoda badań

W celu stworzenia testów wydajno ci zdecydowano się na zaprojektowanie i zaimplementowanie aplikacji

testujących wykorzystującŚ 1) Język C# i platformę .NET

2) Język Java

3) rodowisko programistyczne Visual Studio

4) rodowisko programistyczne Android Studio

5) Emulator z systemem Windows 10 Mobile

6) Emulator z systemem Android 7

Rys. 1. Porównanie wyglądu zdefiniowanego za pomocą tego samego pliku XAML w systemie Android (po lewej) oraz Windows 10 Mobile (po prawej)

Testy zostały podzielone na kilka kategorii:

1) Test uruchamiania aplikacji

2) Testy wydajno ci obliczeniowej 3) Testy wydajno ci odczytu/zapisu danych

4) Testy prędko ci połączenia internetowego

Test uruchamiania aplikacji polegał na dokładnym zmierzeniu czasu uruchamiania dla aplikacji zawierającej jeden widok od momentu naci nięcia ikony aplikacji na pulpicie głównym, do czasu wy wietlenia widoku.

Testy wydajno ci obliczeniowej polegały na wykonaniu sortowania bąbelkowego tablicy zawierającej 20000 elementów oraz wykorzystaniu funkcji skrótu SHA-256

i MD-5 do haszowania 50 megabajtów danych. Testy wydajno ci odczytu i zapisu danych odbywały się

poprzez mierzenie czasu odczytu pliku o rozmiarze 50MB

oraz 1000 plików o rozmiarze 50kB, a następnie przez zapisanie pliku o rozmiarze 100MB oraz 1000 plików o rozmiarze 50kB.

Testy zostały wykonane w aplikacjach natywnych działających na systemach operacyjnych Android i Windows 10 Mobile, oraz aplikacjach zapewniających tą samą funkcjonalno ć wykonanych z wykorzystaniem platformy Xamarin, które mogły być uruchomione na obydwu systemach. Pozwoliło to na stworzenie porównania wydajno ci aplikacji ze współdzielonym kodem do technologii natywnych na dany system operacyjny.

Zestawiając różnicę między technologiami natywnymi a współdzielonym szkieletem aplikacji porównano stopień wydajno ci oprogramowania między wymienionymi systemami operacyjnymi [11].


89

5. Wyniki badań

Wyniki badań zostały przygotowane poprzez analizowanie zarejestrowanego materiału wideo w przypadku testowania czasu uruchamiania aplikacji oraz odczytanie

danych zapisanych w logach aplikacji testowej. Każdy z eksperymentów został wykonany 10 razy. Obliczono następnie redni czas trwania każdego z eksperymentów.

5.1. Pomiar czasu uruchamiania aplikacji

Eksperyment ukazuje pomiar czasu uruchamiania

aplikacji zawierającej ten sam interfejs użytkownika, stworzonej za pomocą rozwiązań natywnych oraz platformy Xamarin.Forms (Rys. 2). Wyniki ukazują negatywny wpływ frameworka Xamarin na wydłużenie czasu uruchomienia aplikacji. Na systemie mobilnym Android czas uruchomienia

został wydłużony ponad pięciokrotnie w porównaniu do natywnego rozwiązania zaprojektowanego w Android SDK.

Rys. 2. Test - uruchamianie aplikacji

W wersji dla systemu Windows 10 Mobile wydłużenie czasu gotowo ci aplikacji jest sporo mniejsze, natomiast nadal znaczące - przekraczające 65%.

5.2. Testy wydajności obliczeniowej

5.2.1. Sortowanie bąbelkowe

Eksperyment z przeprowadzeniem sortowania

bąbelkowego 20000 elementów pokazuje znaczną różnicę między czasem wykonania sortowania w aplikacji natywnej

dla systemu Android oraz w aplikacji wieloplatformowej

zaimplementowanej w Xamarin.Forms (Rys. 3). Rozwiązanie przygotowane w Android SDK zakończyło sortowanie w czasie rednim o 251% krótszym od implementacji stworzonej w Xamarin.Forms.

Inaczej sytuacja przedstawia się w systemie Windows 10 Mobile, gdzie sortowanie w aplikacji natywnej zakończyło się w czasie krótszym o jedyne 4%.

5.2.2. Funkcja skrótu SHA-256

Kolejny eksperyment ukazuje czas haszowania funkcją skrótu SHA-256 na poszczególnych systemach operacyjnych (Rys. 4). W tym wypadku po raz kolejny największa różnica

występuje pomiędzy rozwiązaniem przygotowanym w Android SDK a Xamarin.Forms, gdzie implementacja

wieloplatformowa potrzebowała na obliczenie funkcji skrótu aż 28 razy więcej czasu od aplikacji natywnej na systemie Android.

Rys. 3. Test - sortowanie bąbelkowe

Rys. 4. Test - funkcja skrótu SHA-256

W przypadku systemu mobilnego od Microsoftu różnica między Xamarin.Forms a Universal Windows Platform jest marginalna, zarówno rozwiązanie natywne jak i wieloplatformowe zapewniają bardzo zbliżone czasy wykonania.

5.2.3. Funkcja skrótu MD5

Następny eksperyment ukazuje czas haszowania funkcją skrótu MD5 (Rys. 5). W przypadku tej funkcji skrótu różnica między implementacjami nie jest już tak duża jak

w przypadku SHA-256 na systemie Android.

Xamarin.Forms wykonuje operacje w czasie o 475%

dłuższym niż rozwiązanie natywne przygotowane w Android SDK.

Na systemie mobilnym od Microsoftu różnica podobnie jak w poprzednim te cie sprawdzającym funkcję skrótu SHA-256 jest marginalna.


90

Rys. 5. Test - funkcja skrótu MD5

5.3. Testy wydajności odczytu/zapisu danych

5.3.1. Czas zapisu pliku 50MB

W tym te cie został zmierzony czas zapisu pliku o rozmiarze 50MB (Rys. 6). Odwrotnie niż w poprzednich testach na systemie Android najkrótszy czas zapisu zapewnił wieloplatformowy szkielet aplikacji Xamarin.Forms.

W porównaniu do natywnej technologii rozwiązanie to zapisało plik w czasie krótszym o 613% od implementacji natywnej w Android SDK.

Rys. 6. Test - czas zapisu pliku 50MB

W przypadku systemu Windows 10 Mobile rozwiązanie wieloplatformowe wykonało zapis w czasie o 10% krótszym od rozwiązania przygotowanego w Universal Windows Platform.

5.3.2. Czas zapisu 1000 plików o rozmiarze 50kB

W tym eksperymencie przetestowany został zapis 1000

małych plików w pętli (Rys. 7). Po raz kolejny na systemie mobilnym od Google wydajno ć rozwiązania wieloplatformowego jest większa od wydajno ci natywnej aplikacji przygotowanej w Android SDK. W tym wypadku

czas zapisu jest trzykrotnie krótszy w te cie napisanym za pomocą Xamarin.Forms.

Rys. 7. Test - czas zapisu 1000 plików o rozmiarze 50kB

W systemie Windows 10 Mobile występuje podobna różnica między rozwiązaniem wieloplatformowym a natywnym jak w poprzednim te cie zapisu dużego pliku. Wynosi ona 8% na niekorzy ć aplikacji napisanej we frameworku Xamarin.Forms.

5.3.3. Czas odczytu pliku 50MB

W kolejnym eksperymencie został wykonany odczyt pliku o rozmiarze 50MB za pomocą aplikacji wieloplatformowych i natywnych (Rys. 8).

Rys. 8. Test - czas odczytu pliku 50MB

W przypadku systemu Android rozwiązanie Xamarin.Forms jest prawie trzykrotnie wolniejsze od

rozwiązania przygotowanego w Android SDK. Na systemie

mobilnym od Microsoftu różnica między rozwiązaniem wieloplatformowym a natywnym jest kolejny raz niewielka.

Jak w poprzednich testach rozwiązanie to jest nieco wolniejsze od aplikacji natywnej, w tym wypadku o 10%.

5.3.4. Czas odczytu 1000 plików 50kB

Następny eksperyment polegał na zmierzeniu czasu odczytu 1000 plików o rozmiarze 50Kb (Rys. 9).


91

Podczas tego testu zmniejszyła się różnica pomiędzy Android SDK a Xamarin.Forms w porównaniu do odczytu dużego pliku. Rozwiązanie wieloplatformowe jest tylko dwukrotnie wolniejsze od rozwiązania natywnego.

Rys. 9. Test - czas odczytu 1000 plików o rozmiarze 50kB

W przypadku systemu Windows 10 Mobile po raz kolejny

występuje niewielka różnica na niekorzy ć rozwiązania wieloplatformowego Xamarin.Forms, która podczas tego testu wynosi 11%, zatem spowolnienie działania jest porównywalne do pozostałych testów.

5.4. Test prędkości połączenia internetowego

Ostatni z testów polega na pobraniu pliku poprzez połączenie internetowe o rozmiarze 100MB (Rys. 10). Po raz kolejny szybko ć aplikacji wieloplatformowej na systemie mobilnym Android była dużo mniejsza od rozwiązania natywnego. Implementacja testu

w Xamarin.Forms zakończyła zadania w czasie ponad dwa i pół razy dłuższym od analogicznej implementacji w Android SDK.

Rys. 10. Test - pobieranie pliku o rozmiarze 100MB

W przypadku systemu mobilnego od Microsoftu zadanie

zostało zakończone zarówno dla rozwiązania natywnego jak

i wieloplatformowego w podobnym czasie, różnica nie przekroczyła 1%.

6. Wnioski

Zebranie wyników badań na platformie Android wskazuje na wysokie spowolnienie działania spowodowane wykorzystaniem wieloplatformowego szkieletu aplikacji

w 7 testach na 9. Na tym systemie operacyjnym jedynie

w przypadku zapisu pliku rozwiązanie Xamarin.Forms było szybsze od rozwiązania natywnego. Największa różnica wydajno ci wystąpiła podczas używania funkcji skrótu SHA-256, gdzie implementacja natywna okazała się 28 razy szybsza.

Inaczej wygląda sytuacja na systemie mobilnym Windows 10 Mobile, gdzie występuje dużo mniejsza różnica między technologią natywną Universal Windows Platform a rozwiązaniem wieloplatformowym Xamarin.Forms. Większo ć testów wykazała różnicę w wydajno ci nieprzekraczającą 10% na niekorzy ć wieloplatformowego szkieletu aplikacji, co wskazuje na zbliżoną wydajno ć obu rozwiązań. Używanie Xamarin.Forms zdecydowanie

negatywnie wpływa jedynie na czas uruchamiania aplikacji, gdzie został on wydłużony o 66%.

Postawiona w artykule hipoteza badawcza mówiąca o tym, że tworzenie aplikacji ze wspólnym szkieletem umożliwia wydajne ich działanie niezależnie od systemu operacyjnego została obalona. Odpowiednia wydajno ć jest zapewniona jedynie w przypadku systemu Windows 10

Mobile, natomiast na urządzeniach pracujących pod kontrolą systemu operacyjnego Android korzystanie

z wieloplatformowego szkieletu aplikacji w większo ci przypadków daje znaczne spowolnienie jej działania.

Literatura

[1] L. Delia, N. Galdamez, P. Thomas, L. Corbalan i P. Pesado,

„Multi-platform mobile application development analysis,” w Research Challenges in Information Science (RCIS), 2015

IEEE 9th International Conference on, IEEE, 2015.

[2] A. Troelsen, Język C# 2010 i platforma .NET 4, Warszawa:

Wydawnictwo Naukowe PWN, 2011.

[3] J. Dickson, Xamarin Mobile Development, Allendale: Grand

Valley State Univerity, 2013.

[4] P. Čečil, Cross-platform Mobile Development, Prague:

Department of Software Engineering, 2015.

[5] D. Hermes, Xamarin Mobile Application Development: Cross-

Platform C# and Xamarin.Forms Fundamentals, New York:

Apress, 2015.

[6] C. Petzold, Creating Mobile Apps with Xamarin.Forms,

Washington: Microsoft Press, 2016.

[7] https://www.xamarin.com/forms. [03. 06.2017].

[8] C. C. Sirvent Mazarico, Comparison between Native and Cross-

Platform Apps, VäxjöŚ Linnaeus University, Faculty of Technology, Department of Computer Science., 2015

[9] M. Reynolds, Xamarin Essentials, Birmingham: Packt

Publishing, 2014.

[10] C. Bilgin, Mastering Cross-Platform Development with

Xamarin, Birmingham: Packt Publishing, 2016.

[11] N. Panigrahy, Xamarin Mobile Application Development for

Android - Second Edition, Birmingham: Packt Publishing,

2015.

JCSI 6 (2018) 92-96

Wysłane: 2017-11-15


92

Porównanie możliwości implementacji usług REST w języku Java z wykorzystaniem popularnych frameworków aplikacji internetowych

Rafał Kwiatkowski*, Piotr Kopniak Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska

Streszczenie. W artykule zostały zaprezentowane wyniki porównania efektywności i możliwości implementacji usług REST w języku Java przy użyciu frameworków takich jak Jersey, Apache CXF i Spring MVC. Analiza porównawcza została przeprowadzona na podstawie aplikacji

zaimplementowanej za pomocą każdego z wymienionych frameworków. Aplikacja została zaimplementowana z wykorzystaniem takich narzędzi jak Spring Boot, Hibernate, Maven i MySQL.

Słowa kluczowe: REST; Mikrousługi; RESTful; java

* Autor do korespondencji.


Comparison of capabilities to implement REST services in Java language using

the popular web application frameworks.

Rafał Kwiatkowski*, Piotr Kopniak Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. This article presents the results of a comparison of capabilities and efficiency of REST in Java using frameworks such as Jersey,

Apache CXF and Spring MVC. Comparative analysis was conducted on the basis of application implemented by each of the above frameworks.

Application have been implemented using technologies such as Spring Boot, Hibernate, Maven, and MySQL.

Keywords: REST; Microservices; RESTful; java



1. Wstęp

Dzięki rozwojowi technologii coraz rzadziej korzysta się ze szkieletów sieciowych wywołujących usługi i tworzących strony internetowe takie jak RPC CORBA i usługi oparte na protokole SOAP wymagające wielu zależności i będące bardzo skomplikowane [1]. Obecnie częściej aplikacje są

tworzone przy pomocy paradygmatu dostarczania i używania interfejsów API. Taka architektura daje większe możliwości jak m.in. stosowanie zwinnych technik programowania,

łatwiejsze skalowanie, rozpowszechnianie czy integracja w każdej płaszczyźnie.

REST jest wzorcem narzucającym dobre praktyki tworzenia architektury aplikacji rozproszonych. RESTful

Webservices (inaczej RESTful web API) jest usługą sieciową zaimplementowaną na bazie protokołu HTTP i warunków stylu REST. Moda na architekturę mikro serwisów czy

konteneryzacja za pomocą takich narzędzi jak Docker, w które REST idealnie się wkomponowuje daje mu dodatkową popularność. Jest prosty, wydajny i daje duże możliwości.

Celem artykułu jest ocena przydatności frameworków Jersey, Apache CXF oraz Spring MVC dla usług RESTowych języka Java. Frameworki zostały porównane na podstawie analizy utworzonego kodu aplikacji oraz metryk statycznych.

Teza jaka została postawiona w artykule to „Spring MVC daje większe możliwości, niż pozostałe rozwiązania”.

W celu utworzenia aplikacji potrzebnej do

przeprowadzenia badań wykorzystano następujące narzędzia:

• środowisko programistyczne InteliJ IDEA;

• język programowania Java w wersji 8;

• frameworki do przebadania tj. Jersey, Apache CXF

i Spring MVC;

• frameworki do implementacji aplikacji tj. Hibernate,

Spring, Spring Boot;

• do budowania projektu użyto narzędzia Maven;

• silnikiem bazy danych był MySQL.

2. Styl REST

Technologia Representational State Transfer (REST)

wprost z rozwinięcia skrótu oznacza zmianę stanu poprzez reprezentację[13]. Termin Rest został zdefiniowany po raz pierwszy w roku 2000 przez Roya Fieldinga w jego pracy

mailto:[email protected]


93

doktoranckiej na temat „Style architektoniczne i projektowanie

architektury oprogramowania opartych na sieci” [4]. Najczęściej można spotkać się z definicją, że jest on stylem architektonicznym reprezentowania i przesyłania danych. Z praktycznego punktu widzenia jest on odpowiedzialny za styl

formatowania identyfikatorów URI reprezentujących zasoby, które są dostarczane i przechowywane w aplikacji.

Wyróżnia się 6 założeń REST [2]:

1) Klient – Serwer

2) Jednolity interfejs

3) Bezstanowość

4) Możliwość zapisywania danych w buforze

5) System warstwowy

6) Kod na żądanie.

Aplikacje określa się jako REST gdy spełnia pięć warunków z sześciu. Kod na żądanie jest warunkiem opcjonalnym [3].

3. Opis prezentowanych frameworków

Framework jest szkieletem do budowy aplikacji,

usprawniającym powtarzające się mechanizmy dla określonej architektury. W przypadku frameworków dla usług RESTowych oczekuję się od niego, że będzie miał metody usprawniające tworzenie takich usług. Będą to np.

przygotowane mechanizmy do odbierania żądań za pomocą odpowiednich metod HTTP, czy produkcja i konsumpcja

typów MIME (min. XML, JSON, ATOM).

3.1. Jersey

Jersey RESTful framework jest otwartym (ang. open

source) frameworkiem zbudowanym na podstawie

specyfikacji JAX-RS (tj. JSR 311 oraz JSR 339) [5]. Jest

to natywna implementacja tego protokołu rekomendowana przez firmę Oracle. Rozszerza implementacje JAX-RS

o dodatkowe funkcjonalności (min. takie jak WSDL czy wsparcie dla formatów XML, JSON czy ATOM), w celu uproszczenia tworzenia usługi RESTful i łatwiejszej implementacji klienta. Wersja 2.X została zaprezentowana

w 2012 roku [7].

3.2. Apache CXF

Apache CXF jest to framework o otwartym kodzie

źródłowym przeznaczonym do tworzenia usług sieciowych. Powstał z połączenia kilku projektów open source: CELTIX, rozwijanego przez IONA technologies, Xfire, tworzony przez

zespół działający w ramach Codehaus. Oraz biblioteki YOKO. Zostały połączone przez Apache Software Foundation i w 2008 roku wyszedł z fazy inkubacji [12]. Jest to dojrzały i elastyczny framework umożliwiający i dający narzędzia do kompletnej implementacji aplikacji sieciowych,

zarówno za pomocą CORBA jak i SOAP czy REST [8].

3.3. Spring MVC

Spring REST jest częścią Spring MVC, który jest jednym z modułów najpopularniejszego frameworka w świecie Javy,

jakim jest Spring firmy Pivotal. Cały framework posiada otwarty kod źródłowy. Część odpowiedzialna za REST została po raz pierwszy wydana wraz z wersją 3.0 pod koniec 2009 roku, a udoskonalony w wersji 4.0, Spring MVC stal

się w pełni dojrzałą i stabilną technologią dla tworzenia serwisów RESTowych. Spring ma wiele modułów, które można dodawać do projektu w zależności od potrzeb, dlatego też Spring REST służy tylko do łatwego i efektywnego używania tego stylu architektonicznego. Spring jako jedyny z omawianych frameworków posiada pełne wsparcie dla najwyższego poziomu w modelu dojrzałości Richardsona jakim jest HATEOAS [6, 9].

3.4. Porównanie frameworków

Do zaprezentowania możliwości implementacji usług REST w języku Java zostały wybrane Jersey, Apache CXF oraz Spring MVC. Pierwszym argumentem uzasadniającym ten wybór jest ich dokumentacja, rekomendacje oraz

popularność w renomowanym serwisie StackOverFlow. Każde z rozwiązań posiada obszerną dokumentacje, na którą składa się konfiguracja wstępna, opis funkcjonalności, przykłady implementacji oraz JavaDoc z opisem wszystkich metod. Poza

tym Spring MVC oraz Jersey zawierają także blogi firmowe. Frameworki te posiadają też rekomendacje popularnych firm branżowych, co buduje większe zaufanie do rozwiązań, jakie prezentują Jersey, Apache CXF oraz Spring MVC. Popularność frameworków przekłada się na liczbę rozwiązanych problemów dostępnych w internecie, które występują w trakcie implementacji. Poniżej zostało przedstawione zestawienie liczby zapytań dla prezentowanych frameworków w serwisie StackOverFlow z dnia 01.10.2017 roku.

Tabela 1. Liczba zapytań na portalu Stackoverflow

Framework Liczba zapytań

Spring MVC 42549

Jersey 31057

Apache CXF 4209

Jak wynika z powyższej tabeli w serwisie Stackoverflow najwięcej razy pytano o Spring MVC co ukazuje go jako najpopularniejsze rozwiązanie.

Drugim argumentem stojącym za tymi rozwiązaniami są ich funkcjonalności. Wszystkie 3 umożliwiają programowanie za pomocą adnotacji, zaawansowane wsparcie procesu logowania i testowania, wsparcie dla HATEOAS

(w tym Spring posiada oddzielny moduł w pełni wpierający ten poziom w modelu dojrzałości Richardsona), oraz jako jedyne mają wsparcie dla Spring Boota co pozwala na łatwiejszą i optymalniejszą konfiguracje.

Ostatnim argumentem jaki stoi za wybraniem tych

frameworków są ich różnice. Są to 3 świetne rozwiązania, jednocześnie całkowicie inne, implementujące inne biblioteki i standardy. Co więcej, Jersey jest małym frameworkiem służącym tylko wspomaganiu tworzenia usług REST, gdzie Apache CXF jest frameworkiem pozwalającym tworzyć kompletne aplikacje sieciowe, w którym obsługa RESTa


94

to mały fragment jego możliwości i Spring MVC, w którym wszystko jest w osobnych modułach – oddzielnych

podprojektach, co stanowi ciekawe zestawienie

do porównania.

4. Opis obiektu badań

W celu udowodnienia postawionej tezy zaprojektowano

i zaimplementowano aplikacje, wykonane za pomocą 3 różnych RESTowych frameworków [5].

Projektem aplikacji do zaprezentowania możliwości frameworków jest aplikacja REST typu CRUD (ang. Create,

Read, Update, Delete) opierającą się na operacjach tworzenia

nowych pozycji, wczytywania, odświeżania i usuwania

danych z bazą danych MySQL za pomocą metod HTTP takich jak GET, POST, PUT, DELETE. W aplikacji zostało zaimplementowane zamienianie formatu prezentowanych

danych użytkownikowi w locie z formatu XML na JSON i

odwrotnie (tzw. marshalling). W aplikacji dążono do spełnienia poziomu drugiego w modelu dojrzałości Richardsona.

5. Opis metody badawczej.

Badanie zostało przeprowadzone na podstawie porównania zaprojektowanych i zaimplementowanych aplikacji za pomocą dwóch metod:

• Analizy kodu – analiza ta polegała na zaprezentowaniu

rozwiązań jakie oferują frameworki. W metodzie tej główny nacisk położono na różnice implementacyjne tych samych funkcjonalności tj. konfiguracji frameworków, przetwarzania danych, oraz przesyłania danych do klienta HTTP, oraz zmianie formatów wysyłanych danych.

• Metryk statycznych – metryki te polegały na zliczeniu

linii kodu z pominięciem pustych linii i komentarzy

z podziałem na warstwy w każdej aplikacji i porównaniu ich. Zliczenie linii kodu ma na celu pokazanie

efektywności frameworków. Im mniejszej liczby linii

kodu potrzebowano do napisania tej samej aplikacji

w danym rozwiązaniu tym wyższą ocenę framework uzyskał.

6. Badania

Aplikacje zbudowano zgodnie z założeniami REST oraz dobrymi praktykami programistycznymi. Aplikacja została także zaprojektowana z podziałem na warstwy:

• Model – zawiera modele danych mapowane za pomocą frameworka Hibernate,

• Repozytorium – zawiera interfejsy i klasy dające dostęp do danych,

• Kontroler – zawiera klasy odpowiedzialne

za przechwytywanie żądań http.

Rysunek poniżej przedstawia strukturę aplikacji dla frameworka Apache CXF. Poszczególne implementacje mają

różnice wewnątrz warstw, które są omówione w dalszej części artykułu lecz struktura katalogów jest taka sama.

Rys 1. Struktura projektu.

W celu ukazania funkcjonalności frameworków nie jest potrzebna skomplikowana logika biznesowa, dlatego została utworzona encja produktów w celu przeprowadzenia na niej operacji CRUD. Wykorzystano adnotacje JAXB w celu

umożliwienia konwersji encji na typ XML [11].

Rys 2. Encja produkt.

Aby zapewnić identyczne warunki do porównywania frameworków użyto tych samych implementacji do tworzenia ziaren, wstrzykiwania zależności oraz stereotypów z implementacji Springa.

6.1. Konfiguracja

Aby usprawnić proces implementacji konfiguracji wstępnej użyto nowoczesnego narzędzia jakim jest Spring Boot. Eliminuje on konieczność tworzenia rozbudowanych konfiguracji xml-owych czy rozbudowanych klas

implementacyjnych, a do uruchomienia aplikacji wystarcza

klasa uruchomieniowa opatrzona adnotacją @SpringBootAplication [10].

Do pełnego skonfigurowania frameworku Jersey wystarczyło utworzenie klasy konfiguracyjnej zawierającej lokalizacje klasy przechwytującej żądania HTTP i nadającą główną ścieżkę URL aplikacji co prezentuje rysunek 3.

Rys 3. Konfiguracja frameworku Jersey.

Framework Apache CXF ma bardzo szerokie zastosowanie

i oprócz stylu REST, głównym jego zastosowaniem jest


95

tworzenie usług za pomocą protokołu SOAP. Pomimo informacji w dokumentacji tego frameworka o wsparciu dla

JSON, format ten nie jest w pełni wspierany dla stylu REST. Aby zapewnić tą funkcjonalność została dodana biblioteka Jackson, co wymagało dodatkowej konfiguracji zaprezentowanej na rysunku 4.

Rys 4. Konfiguracja biblioteki Jackson dla Apache CXF.

Oprócz tego Apache CXF wymaga ustawienia ścieżki URL aplikacji oraz przeszukiwania komponentów frameworka Spring w celu znalezienia implementacji protokołu JAX-RS

przechwytujących żądania HTTP w pliku application.properties co prezentuje rysunek poniżej

Rys 5. Konfiguracja frameworku Apache CXF.

Spring MVC nie wymaga żadnej dodatkowej konfiguracji. Po utworzeniu projektu w Spring bootcie jest gotowy

do użycia. W przypadku niestandardowych ustawień można dowolnie modulować je w pliku application.properties.

Tabela poniżej prezentuje liczby linii kodu potrzebnych

do kompletnego skonfigurowania frameworków.

Tabela 2. Liczba linii kodu potrzebnych do konfiguracji

Framework Liczba linii kodu

Jersey 7

Apache CXF 11

Spring MVC 0

6.2. Dostęp do danych

Do implementacji aplikacji typu CRUD potrzebna jest

warstwa dostępu do danych. W Jersey oraz Apache CXF stworzono interfejs ProductRepository, oraz utworzono jego

implementacje. W implementacji zastosowano adnotacje

@Transactional implementującą korzystanie z transakcji. Oprócz tego wstrzykiwany jest kontekst EntityManagera z frameworku Hibernate. Prezentuje to poniższy rysunek.

Rys 6. Implementacja repozytorium dla Jersey oraz Apache CXF.

Aby uzyskać wszystkie dane należy wykonać zapytanie HQL oraz utworzyć zapytanie, którego wynik zostanie zwrócony jako lista elementów. Pozostałe metody są tworzone w sposób analogiczny.

Rys 7. Implementacja metody wyszukiwania wszystkich dla Jersey

oraz Apache CXF.

W dostępie do danych w implementacji Spring MVC wspomaga go moduł Spring Data z dedykowanymi metodami dla aplikacji RESTowych (m.in. podmoduły Spring Data REST, oraz Spring Data HATEOAS). Dzięki niemu nie jest wymagane tworzenie implementacji metod. Wystarczy sam

interfejs rozszerzony o interfejs JpaRepository. Zapewnia

on implementacje wszystkich metod CRUD. Aby utworzyć niestandardowe zapytanie także nie jest konieczna implementacja. Wystarczy napisać ciało metody, a moduł ten stworzy sam odpowiednie zapytanie jak na rysunku 8.

Rys 8. Implementacja całej warstwy dostępu do danych dla Spring MVC.

Tabela poniżej prezentuje liczby linii kodu potrzebnych do zaimplementowania wszystkich metod dla warstwy dostępu do danych potrzebnych do stworzenia aplikacji CRUD

Tabela 3. Liczba linii kodu potrzebnych do utworzenia warstwy danych


Jersey 57

Apache CXF 57

Spring MVC 3

6.3. Kontroler

Z uwagi na to iż Jersey i Apache CXF dla REST implementują protokół JAX-RS ich rozwiązania

są analogiczne. Aby utworzyć kontroler w tych technologiach należało oznaczyć go komponentem Spring, dodać ścieżkę URL dla całej klasy, oraz wstrzyknąć repozytorium jak zostało to pokazane na rysunku 9.

Rys 9. Implementacja kontrolera w Jersey oraz Apache CXF.

W Spring MVC należy dodać adnotacje @RestController, oraz także wstrzyknąć repozytorium, natomiast ścieżka dla całej klasy nie jest wymagana co prezentuje rysunek 10.

Rys 10. Implementacja kontrolera w Spring MVC.


96

W podejściu Jersey oraz Apache CXF aby utworzyć metodę przechwytującą żądanie HTTP należy dodać adnotacje określająca rodzaj żądania, ścieżkę URL, oraz produkowany lub konsumowany format danych jak na rysunku poniżej.

Rys 11. Implementacja przykładowej metody kontrolera w Jersey oraz Apache CXF.

W podejściu Spring MVC aby utworzyć metodę przechwytującą żądanie HTTP należy dodać adnotacje określającą rodzaj żądania i w nim podać URL jako wartość. Domyślnie dane są produkowane i konsumowane za pomocą plików JSON co zostało przedstawione na rysunku 12.

Rys 12. Implementacja przykładowej metody kontrolera w Spring MVC.

W celu zmiany domyślnego formatu danych do adnotacji określającej metodę HTTP należy dodać potrzebny MediaType (tj. inny typ danych) jak prezentuje to rysunek 13.

Rys 13. Implementacja przykładowej zmiany typu danych w metodzie kontrolera dla Spring MVC.

Tabela 4 prezentuje liczby linii kodu potrzebnych

do zaimplementowania wszystkich metod do kontrolera typu

REST do stworzenia aplikacji CRUD

Tabela 4. Liczba linii kodu potrzebnych do utworzenia kontrolera.


Jersey 52

Apache CXF 52

Spring MVC 4

7. Wnioski

W obecnych czasach programista powinien skupiać się na realizacji procesów biznesowych i język wraz z dodatkowymi frameworkami i bibliotekami powinien

to umożliwiać. Nowoczesne podejście takie jak zastosowanie programowania opartego na adnotacjach, konfiguracji

za pomocą spring boota, czy zastosowanie serwisów RESTful wspomaga w tym procesie.

Dobra dokumentacja, oraz popularność frameworka, a co za tym idzie mnogość rozwiązanych już problemów dostępnych w internecie przyśpiesza proces implementowania rozwiązań biznesowych. Z rozdziału 3.4 wynika, iż Spring MVC posiada dobrą dokumentację, JavaDoc i bloga firmowego, oraz jednoznacznie można stwierdzić iż jest najpopularniejszym frameworkiem z prezentowanych w tym

artykule w serwisie Stackoverflow.

Z prezentowanych badań można wywnioskować iż Spring MVC umożliwia utworzenie kompletnej aplikacji RESTowej typu CRUD z zachowaniem założeń REST oraz spełniając 2 poziom w modelu dojrzałości Richardsona. Co więcej w zestawieniu z frameworkiem Jersey oraz Apache CXF jest

najlepszym do tego celu rozwiązaniem. Argumentem potwierdzającym jest fakt, iż nie wymaga żadnej konfiguracji, a pozostałe tego wymagały. W warstwie dostępu do danych poprzez moduł Spring Data bez dodatkowej implementacji dostępny jest gotowy zestaw metod a tworzenie nowych jest generowane na podstawie ciała metody, a pozostałe frameworki wymagały pełnej implementacji. W warstwie kontrolera zapewnia najkrótsze i najwygodniejsze przyjmowanie żądań HTTP z domyślnym formatem JSON do produkowania i konsumowania danych. Dlatego

postawiona teza „Spring MVC daję większe możliwości, niż pozostałe rozwiązania” została udowodniona.

Literatura

[1] K. Smita, S. Kumar Rath. Performance comparison of SOAP

and REST based Web Services for EnterpriseApplication

Integration. Advances in Computing, Communications and

Informatics (ICACCI), 2015 International Conference on.

IEEE, 2015.

[2] Murat Yener, Alex Theedom, JavaEE Zaawansowane wzorce

projektowe, Helion, 2015.

[3] Bhakti Mehta, RESTful Java Patterns and Best Practices, Packt

Publishing, 2014.

[4] Praca doktorska Roya Fieldinga, 2000 https://www.ics.uci.edu/

~fielding/pubs/dissertation/rest_arch_style.htm

[5] Bill Burke, RESTful Java with JAX-RS 2.0, O’Reilly, 2014.

[6] Martin Fowler, Model dojrzałości Richardsona, 2010 https://

martinfowler.com/articles/richardsonMaturityModel.html

[7] Dokumentacja Jersey https://jersey.java.net/documentation/

latest/user-guide.html [05.10.2017]

[8] Dokumentacja Apache CXF http://cxf.apache.org/docs/

[05.10.2017]

[9] Dokumentacja Spring MVC .https://docs.spring.io/spring/docs/

current/spring-framework-reference/web.html [05.10.2017]

[10] Dokumentacja Spring Boot https://docs.spring.io/spring-

boot/docs/current-SNAPSHOT/reference/htmlsingle/

[15.10.2017]

[11] Masoud Kalali, Developing RESTful Services with JAX-RS

2.0, WebSockets, and JSON, Packt Publishing, 2013

[12] Powstanie Apache CXF https://en.wikipedia.org/wiki/Apache_

CXF [17.10.2017]

[13] Definicja REST https://pl.wikipedia.org/wiki/Representational_

State_Transfer

http://cxf.apache.org/docs/

https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/

https://docs.spring.io/spring-boot/docs/current-SNAPSHOT/reference/htmlsingle/

https://en.wikipedia.org/wiki/Apache_CXF

https://en.wikipedia.org/wiki/Apache_CXF

JCSI 6 (2018) 97-101

Wysłane: 2017-11-15


97

Wydajność pracy z bazami danych w aplikacjach ASP.NET MVC

Paweł Borys*, Beata Pańczyk


Streszczenie. Podczas tworzenia aplikacji internetowych działających w oparciu o bazę danych niezwykle ważne jest wybranie odpowiedniego narzędzia pozwalającego na obsługę bazy. Wybór ten ma wpływ zarówno na działanie wdrożonego już programu jak i na przebieg procesu jego

wytwarzania. Jednak liczba dostępnych rozwiązań jest duża i często niełatwo jest zdecydować, z którego narzędzia najlepiej skorzystać w danym projekcie. Niniejszy artykuł przedstawia porównanie wydajności pracy z trzema popularnymi rozwiązaniami dla platformy ASP.NET

MVC: ADO.NET, Entity Framework i NHibernate..

Słowa kluczowe: bazy danych; Entity Framework; NHibernate; ADO.NET; ASP.NET MVC



ASP.NET MVC database applications performance

Paweł Borys*, Beata Pańczyk Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. During web application development, working with a database and choosing appropriate tool for database managing is extremely

important. This choice influences both final application and its development process. However there is a large number of possibilities of

choosing the best tool to use in a project. It often provides some difficulties. The main goal of this paper is to present the advantages and

disadvantages of three popular solutions for ASP.NET MVC platform (ADO.NET, Entity Framework, NHibernate) to help make the proper

decision.

Keywords: databases; Entity Framework; NHibernate; ADO.NET; ASP.NET MVC



1. Wstęp

Tworzenie nowoczesnych aplikacji internetowych

nieodłącznie wiąże się z wykorzystaniem baz danych. W popularnym wzorcu architektonicznym Model-Widok-

Kontroler (MVC), organizującym podział aplikacji na trzy części o odrębnych zadaniach, model odpowiada danym, na których pracuje program i które zazwyczaj przechowywane są w relacyjnej bazie danych [1]. Programista wykorzystując framework ASP.NET MVC stoi przed koniecznością wyboru

efektywnej metody obsługi bazy danych. W przypadku

skomplikowanej struktury relacyjnej bazy danych, w której tabele są połączone wieloma wzajemnymi relacjami, samodzielna implementacja tej funkcjonalności może okazać się bardzo czasochłonna, a w przypadku mniej doświadczonych programistów, również problematyczna. Dlatego tak ważnym zagadnieniem jest dobór odpowiedniego narzędzia wspomagającego programistę w tworzeniu aplikacji bazodanowych.

Celem niniejszego artykułu jest porównanie trzech

popularnych narzędzi ułatwiających obsługę bazy danych w aplikacji ASP.NET MVC. Określone zostaną wady oraz

zalety każdego z nich pod względem wydajności działania.

Dodatkowo oceniony zostanie poziom skomplikowania kodu

w języku C#, niezbędnego do implementacji danego

rozwiązania. Przeprowadzone badanie pozwoli na łatwiejsze

dobranie odpowiedniego narzędzia przez programistę przystępującego do tworzenia aplikacji internetowej w architekturze MVC. Ponieważ warstwa modelu aplikacji jest podstawą, na której opiera się implementacja jej logiki

biznesowej, decyzje podjęte na tym etapie są niezwykle istotne dla całego projektu. Poza różnicami w samym procesie implementacji obsługi danych, mogą one spowodować duże

różnice w wydajności działania finalnego programu.

Narzędzia porównywane w artykule to Entity Framework,

NHibernate oraz ADO.NET. Dwie pierwsze z wymienionych

technologii realizują nowocześniejsze, obiektowe podejście do bazy danych jakim jest mapowanie obiektowo-relacyjne

(ang. Object-Relational Mapping, ORM). Ideą mapowania obiektowo-relacyjnego jest wykorzystanie korzyści jakie daje paradygmat programowania obiektowego do zarządzania danymi w relacyjnej bazie danych [2]. Z kolei ADO.NET jest

starszym rozwiązaniem, w którym programista komunikuje się z serwerem bazodanowym bezpośrednio za pomocą zapytań SQL. Wszystkie z wymienionych technologii są aktualnie

stosowane. Zarówno Entity Framework, jak i NHibernate są z powodzeniem wykorzystywane przez programistów i żadna z tych technologii nie jest uznawana za jednoznacznie lepszą

[3].


98

2. Narzędzia pracy z bazami danych w ASP.NET MVC

2.1. ADO.NET

ADO.NET jest zbiorem bibliotek pozwalających na komunikację z bazą danych z poziomu klas języka C# [4].

Odbywa się to za pomocą pisanych przez programistę zapytań SQL, czego skutkiem jest szereg potencjalnych problemów, które mogą pojawić się w projekcie wykorzystującym tę technologię. Zmiany w strukturze tabel bazy danych mogą spowodować konieczność wprowadzania poprawek do kodu aplikacji w wielu miejscach, co jest zarówno czasochłonne jak i znacząco zwiększa ryzyko popełnienia błędu. Ponadto problematyczne może okazać się zaimplementowanie bardziej

złożonych operacji na danych, obejmujących np. operacje

kaskadowe.

2.2. Narzędzia ORM

Odpowiedzią na problemy technologii takich jak ADO.NET było zastosowanie mapowania obiektowo-

relacyjnego. Narzędzia ORM prezentują dane przechowywane

w tabelach bazy danych oraz relacje zachodzące między nimi w postaci klas obiektowego języka programowania. Takie podejście umożliwia operowanie na danych z wykorzystaniem

szerokiego wachlarza możliwości programowania

obiektowego. Jest to na przykład możliwość obsługi

skomplikowanych, nierzadko wielokrotnie zagnieżdżonych powiązań pomiędzy obiektami. Ponadto frameworki takie jak Entity Framework lub NHibernate stanowią dodatkową warstwę abstrakcji oddzielającą kod aplikacji od bazy danych co ułatwia dostosowanie kodu programu do modyfikacji

struktury bazy lub zmiany systemu zarządzania bazą danych.

3. Porównanie narzędzi

3.1. rodowisko testowe

Do testów wykorzystano autorską aplikację ASP.NET MVC stworzoną na potrzeby niniejszego badania. Wersje wykorzystanych narzędzi oraz specyfikacja środowiska testowego przedstawione są w tabelach 1 i 2.

Tabela 1. Wykorzystane oprogramowanie.

Narzędzie Wersja

.Net Framework 4.5.2

MSSQL 2016

Serwer IIS 7.5

MySQL 6.5.21

Serwer Apache 2.4.26

ADO.NET 4.6.1

Entity Framework 6.1.3

NHibernate 4.1.1

Tabela 2. Platforma testowa.

System Microsoft Windows 7 64-bit

CPU Intel Core i3

Pamięć RAM 4 GB

Bazą danych wykorzystaną do przeprowadzenia testów jest dostępna na licencji MIT baza Chinook [5], która reprezentuje sklep z utworami muzycznymi w wersji cyfrowej. Fragment

diagramu ERD przedstawiono na rysunku 1. Wykorzystane w

badaniach tabele zawierają od 300 do ok. 3500 rekordów.

Rys.1. Fragment schemantu testowej bazy danych.

3.2. Scenraiusze testów

W celu dokładnego porównania możliwości oraz

ograniczeń badanych technologii przygotowano 6 scenariuszy testowych. Obejmują one podstawowe, często wykonywane operacje bazodanowe, tj. odczyt oraz zapis rekordów w bazie danych. Odczyt rekordów został zrealizowany na dwa sposoby. Pierwszym było wielokrotne wywołanie zapytania zwracającego rekordy o kolejnych wartościach pola Id,

a drugim określenie warunku w skutek którego wynik pojedynczego zapytania składał się z grupy rekordów. Każda operacja została zrealizowana zarówno dla pojedynczej tabeli jak i dla grupy tabel powiązanych ze sobą wzajemnymi relacjami. Dzięki temu możliwe jest zbadanie w jakim stopniu w praktyce spełnione jest założenie, iż narzędzia ORM wspomagają pracę z rozbudowanymi strukturami danych w bazie. Ponadto każdy scenariusz został zrealizowany na bazie działającej na serwerze MSSQL (tworzony przez

Microsoft) oraz MySQL (rozwijany przez Oracle). Pozwala to

zaobserwować jak poszczególne narzędzia dostosowane są do współpracy z systemem baz danych innym niż ten tworzony

przez firmę Microsoft. Wszystkie scenariusze testowe zostały przedstawione w tabeli 3.

Tabela 3. Scenriusze testów.

Oznaczenie Scenariusz

S1 Odczyt rekordów z pojedynczej tabeli. S2 Odczyt rekordów z 4 powiązanych tabel. S3 Grupowy odczyt rekordów z pojedynczej tabeli. S4 Grupowy odczyt rekordów z 4 powiązanych tabel. S5 Wstawianie rekordów do pojedynczej tabeli. S6 Wstawianie rekordów do 4 powiązanych tabel.

3.3. Aplikacja testowa

Do realizacji testów utworzono sześć projektów, po dwa dla każdego frameworka, odpowiednio dla bazy danych

MSSQL oraz MySQL. Każdy z projektów zawierał klasę HomeController.cs, w której znajdowały się metody

odpowiedzialne za wykonanie każdego ze scenariuszy. Dla

tych dotyczących odczytu danych z bazy, liczba rekordów w pojedynczym pomiarze wynosiła jeden tysiąc. W przypadku zapytań warunkowych, były one dobrane tak aby zwrócić dokładnie tysiąc wierszy wynikowych. Dla scenariuszy

zakładających wstawianie danych do bazy, liczba rekordów wynosiła sto. Prezentowane wartości wynikowe to średnie arytmetyczne wartości otrzymanych dla stu powtórzeń każdego ze scenariuszy.


99

Porównanie wydajności działania badanych narzędzi zostało zrealizowane poprzez zarejestrowanie czasu wykonania zadanych operacji oraz maksymalnej ilości pamięci operacyjnej zajętej przez aplikację podczas ich wykonywania. Do implementacji pomiarów zostały wykorzystane biblioteki udostępnianie przez środowisko .Net [6,7], co zostało przedstawione w przykładzie 1.

Przykład 1. Fragment kodu odpowiedzialny za pomiar czasu wykoania

oraz wykorzystanej pamięci.

public void Start() { GC.Collect(); GC.WaitForPendingFinalizers(); GC.Collect(); _startMemory = GC.GetTotalMemory(true); _watch.Reset(); _watch.Start(); }

public void Stop() { _watch.Stop(); milliseconds = _watch.Elapsed.TotalMilliseconds; memory = GC.GetTotalMemory(false) - _startMemory; }

Implementacja scenariuszy została zrealizowana

z wykorzystaniem domyślnej konfiguracji badanych narzędzi. Dla Entity Framework zastosowano podejście Database First,

które polega na automatycznym wygenerowaniu przez framework odpowiednich klas języka C#, na podstawie

wskazanej bazy danych. W przypadku NHibernate pliki

konfiguracyjne w formacie XML zostały utworzone ręcznie. Wykorzystanie ADO.NET nie wymagało tworzenia dodatkowych plików konfiguracyjnych. Na przykładach 2-4

przedstawiono fragmenty kodu realizujące scenariusz S2.

Przykład 2. Realizacja scenariusza S2 dla ADO.NET.

for (int j = 1; j <= 1000; j++) { command.CommandText = "SELECT t.TrackId, t.Name, t.Composer, t.Milliseconds, t.Bytes, t.UnitPrice, al.AlbumId AS al_Id, al.Title AS al_Title, g.GenreId AS g_Id, g.Name AS g_Name, mt.MediaTypeId AS mt_Id, mt.Name AS mt_Name " + "FROM Track t " + "JOIN Album al ON al.AlbumId = t.AlbumId " + "JOIN Genre g ON g.GenreId = t.GenreId " + "JOIN MediaType mt ON mt.MediaTypeId = t.MediaTypeId " + "WHERE t.TrackId = " + j.ToString(); SqlDataReader reader = command.ExecuteReader(); while (reader.Read()) { Track track = new Track() { Id = (int)reader["TrackId"], Name = reader["Name"].ToString(),

Bytes = (int)reader["Bytes"], Composer = reader["Composer"].ToString(), Milliseconds = (int)reader["Milliseconds"], UnitPrice = (decimal)reader["UnitPrice"] }; tracks.Add(track); Album album = new Album() { Id = (int)reader["al_Id"], Title = reader["al_Title"].ToString() }; albums.Add(album); Genre genre = new Genre() {

Id = (int)reader["g_Id"], Name = reader["g_Name"].ToString()

}; genres.Add(genre); MediaType mediaType = new MediaType() { Id = (int)reader["mt_Id"], Name = reader["mt_Name"].ToString() }; mediaTypes.Add(mediaType); } reader.Close(); }

Przykład 3. Realizacja scenariusza S2 dla Entity Framework.

for (int j = 0; j < 1000; j++) { tracks.Add(context.Tracks.Where(t => t.TrackId == j + 1).Single());

albums.Add(tracks[j].Album);

genres.Add(tracks[j].Genre); mediaTypes.Add(tracks[j].MediaType); }

Przykład 4. Realizacja scenariusza S2 dla NHibernate.

for (int i = 0; i < 1000; i++) { tracks.Add(session.Get<Track>(i + 1)); albums.Add(tracks[i].Album); genres.Add(tracks[i].Genre); mediaTypes.Add(tracks[i].MediaType); }

Zaprezentowane fragmenty kodu wyraźnie pokazują jak bardzo narzędzia ORM upraszczają pracę z bazą danych. Używając ADO.NET konieczna jest ręczna obsługa połączenia z bazą przez programistę oraz skonstruowanie i wywołanie zapytania SQL. W przypadku pracy z tabelami powiązanymi wzajemnymi relacjami, niezbędne jest również zadbanie o zachowanie tych relacji ładowania danych do obiektów w pamięci. Narzędzia wykorzystujące mapowanie obiektowo-relacyjne zwalniają programistę z odpowiedzialności za połączenie z bazą danych, utrzymanie

relacji oraz konstruowanie zapytań. W efekcie, w powyższych przykładach oba narzędzia ORM potrzebowały wielokrotnie mniej linii kodu niż ADO.NET na realizację tej samej operacji odczytu. Pozwala to ograniczyć czas niezbędny na oprogramowanie pracy z bazą i skupić się na logice biznesowej aplikacji, podczas gdy to ORM odpowiada za cały proces, w wyniku którego dane z tabel bazy danych

są mapowane do obiektowej struktury klas języka C#.

3.4. Wydajno ć

W tabelach 4-9 oraz na rysunkach 2-5 przedstawiono

wyniki pomiarów z przeprowadzonych badań.

Tabela 4. Wyniki pomiarów dla scenariusza S1.

Baza danych Narzędzie Czas [s] Pamięć [MB]

MSSQL

ADO.NET 107 1,29

Entity Framework 918 3,99

NHibernate 576 4,01

MySQL

ADO.NET 199 3,07

Entity Framework 1 183 3,98

NHibernate 712 3,28


100



MSSQL

ADO.NET 144 5,11


NHibernate 764 2,81

MySQL

ADO.NET 480 2,85


NHibernate 885 4,14



MSSQL

ADO.NET 2 0,11


NHibernate 40 1,40

MySQL

ADO.NET 3 0,15


NHibernate 23 1,42



MSSQL

ADO.NET 12 0,52


NHibernate 87 4,83

MySQL

ADO.NET 18 0,93


NHibernate 78 4,08



MSSQL

ADO.NET 112 0,08


NHibernate 22 0,54

MySQL

ADO.NET 168 0,21


NHibernate 34 0,48



MSSQL

ADO.NET 410 0,68


NHibernate 124 3,71

MySQL

ADO.NET 778 1,17


NHibernate 914 12,46

Rys. 2. Zestawienie wyników pomiaru czasu wykonania dla bazy MSSQL.

Rys. 3. Zestawienie wyników pomiaru czasu wykonania dla bazy MySQL.

Rys. 4. Zestawienie wyników pomiaru zajętej pamięci dla bazy MSSQL.

Rys. 5. Zestawienie wyników pomiaru zajętej pamięci dla bazy MySQL.

4. Wnioski

W artykule porównano trzy narzędzia służące do pracy z bazami danych z poziomu kodu aplikacji ASP.NET MVC.

Z przeprowadzonej analizy wynika, że żadnego z badanych sposobów obsługi bazy danych – mapowania obiektowo-

relacyjnego oraz podejścia opartego na ręcznym tworzeniu

zapytań SQL – nie można określić jako lepszego od pozostałych bez wzięcia pod uwagę dodatkowych czynników. Są to zagadnienia takie jak stopień

skomplikowania struktury bazy danych lub poziom wiedzy

i doświadczenia programisty.

Spośród narzędzi ORM lepsze wyniki osiągał NHibernate, który w większości przypadków górował nad Entity Framework zarówno pod względem czasu jak i wykorzystanej


101

pamięci. Jedyne przypadki, w których NHibernate osiągnął gorsze wyniki to scenariusz S3 oraz wersja scenariusza S6 dla

bazy MySQL. Był to również jedyny przypadek, w którym rodzaj bazy danych miał znaczący wpływ na wyniki badań. Najważniejszymi zaletami Entity Framework nie są wyniki

tworzonych z jego pomocą aplikacji lecz stopień integracji tego narzędzia z .NET framework oraz środowiskiem Visual

Studio. Bez konieczności instalacji dodatkowych narzędzi programista ma dostęp do graficznego edytora relacji oraz

funkcji automatycznie generujących pliki konfiguracyjne. Ponieważ jednak istnieją narzędzia wspomagające NHibernate, które dają dostęp do takich samych funkcjonalności, według opinii autorów niniejszego artykułu NHibenate jest narzędziem lepszym w tym zestawieniu. Z kolei interfejs ADO.NET, pomimo wad opisanych podczas

przedstawiania kodu aplikacji, zapewnił dużo szybsze

wykonywanie zadań oraz zdecydowanie mniejsze zużycie pamięci we wszystkich przypadkach, poza tymi dotyczącymi wstawiania do bazy obiektów połączonych wieloma wzajemnymi relacjami.

Programista dokonując wyboru odpowiedniego narzędzia (np. pomiędzy ADO.NET a NHibernate) musi wziąć pod

uwagę wymagania stawiane w stosunku do tworzonej

aplikacji. Jeżeli najistotniejszym czynnikiem jest szybkość działania lub wykorzystana pamięć - odpowiednim wyborem

jest ADO.NET. Natomiast w przypadku kiedy niezbędna jest większa elastyczność względem struktury bazy lub szybkość i łatwość implementacji - należy wybrać narzędzie ORM takie

jak NHibernate.

Literatura

[1] Freeman A.: Pro ASP.NET MVC 5, Apress, 2013.

[2] Understanding Object-Relational Mapping: A Framework

Based Approach. The International Journal on Advances in

Software, 2009, nr 2 i 3.

[3] https://www.linkedin.com/pulse/orm-read-performance-ef-vs-

dapper-balazs-hideghety, [10-11-2017]

[4] Bipin J. i in. Professional ADO.NET Programming, Apress,

2001

[5] https://chinookdatabase.codeplex.com, [10-11-2017]

[6] https://docs.microsoft.com/en-

us/dotnet/api/system.diagnostics.stopwatch, [10-11-2017]

[7] https://docs.microsoft.com/en-us/dotnet/standard/garbage-

collection/ [10-11-2017]

bc.pollub.plbc.pollub.pl/Content/13164/PDF/VOL6-2018.pdf · Redakcja JCSI e-mail: [email protected]...

Documents

Transcript of bc.pollub.plbc.pollub.pl/Content/13164/PDF/VOL6-2018.pdf · Redakcja JCSI e-mail: [email protected]...