bc.pollub.plbc.pollub.pl/content/13164/pdf/vol6-2018.pdf · redakcja jcsi e-mail: [email protected]...
TRANSCRIPT
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;
Journal of Computer Sciences Institute
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
3 Zapis 100 studentów
4 Odczyt 100 studentów
5 Zapis 1000 studentów
6 Odczyt 1000 studentów
7 Zapis 10000 studentów
8 Odczyt 10000 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
Nr pomiaru Czas [ms]
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.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Nr pomiaru Czas [ms]
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.
*Autor do korespondencji.
Adres e-mail: [email protected]
Comparison of web application development using PHP and Magento platforms
Bartosz Drawdzik*, Maria Skublewska-Paszkowska
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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.
*Corresponding author.
E-mail address: [email protected]
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ć
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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 `users_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` (`id_questions`, `question_one`, `answer_one`, `answer_two`, `question_two`, `answer_three`, `answer_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]) {
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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.
JCSI 6 (2018) 12-19
WysłaneŚ 2017-09-14
PrzyjęteŚ 2017-09-18
12
Analiza wpływu technik bezpiecznego programowania na wydajno ć i bezpieczeństwo aplikacji
Tomasz Kobiałka,
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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 ć
Adres e-mail: [email protected]
An analysis of influence of safe programming techniques on applications
efficiency and security
Tomasz Kobiałka
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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
E-mail address: [email protected]
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.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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]
3.2. Przepełnienie bufora
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.
3.4. Inżynieria wsteczna
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() {
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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.
4.2. Przepełnienie bufora
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
Liczba wykonań redni czas wykonania [ms] 10000 0.000787545617
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
Liczba wykonań redni czas wykonania [ms] 10000 0.00182376393
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
Journal of Computer Sciences Institute
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
Liczba wykonań redni czas wykonania [ms] 10000 0.001826854346
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.
4.4. Inżynieria wsteczna
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
Journal of Computer Sciences Institute
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.
JCSI 6 (2018) 20-27
WysłaneŚ 2017-09-14
PrzyjęteŚ 2017-09-18
20
Wykorzystanie metody eye-trackingu do ewaluacji responsywnej aplikacji
internetowej
Dariusz Meksuła*, Konrad Mikołajczyk*, Małgorzata Plechawska-Wójcik, Magdalena Borys
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
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
*Corresponding author.
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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ą
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-09-13
PrzyjęteŚ 2017-09-18
28
Porównanie wydajno ci szkieletów aplikacji mobilnych umożliwiających programowanie z wykorzystaniem technologii internetowych
Marcin Martyna* , Jakub Smołka
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
Adres e-mail: [email protected]
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
*Corresponding author.
E-mail address: [email protected]
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.
2. Przegląd literatury
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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].
6. Metodyka badawcza
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)
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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]
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-09-23
PrzyjęteŚ 2017-09-27
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
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
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
*Corresponding author.
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.
2. Przegląd literatury
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.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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ą
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Przyjęte: 2017-10-19
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
*Autor do korespondencji.
Adres e-mail: [email protected]
Comparison of the configuration and capabilities of ORM libraries for Android
Tomasz Serwin*
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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
*Corresponding author.
E-mail address: [email protected]
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].
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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]
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-10-28
PrzyjęteŚ 2017-11-02
47
Analiza porównawcza wybranych szkieletów służących do wstrzykiwania zależno ci
Rafał Szewczyk*, Małgorzata Plechawska-Wójcik*
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
Adres e-mail: [email protected], [email protected]
Comparative analysis of selected skeletons for dependency injection
Rafał Szewczyk*, Małgorzata Plechawska-Wójcik*
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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
*Corresponding author.
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],
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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
Spring Google Guice PicoContainer Weld EasyDI Silk DICarOperator obiektów CarShopOperator obiektów CarShopOperator obiektów CarShop
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
Journal of Computer Sciences Institute
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
Spring Google Guice PicoContainer Weld EasyDI Silk DICarOperator obiektów CarShopOperator obiektów CarShopOperator obiektów CarShop
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
Spring Google Guice PicoContainer Weld EasyDI Silk DICarOperator obiektów CarShopOperator obiektów CarShopOperator obiektów CarShop
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.
Journal of Computer Sciences Institute
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,
Journal of Computer Sciences Institute
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
Spring Google Guice PicoContainer Weld EasyDI Silk DICarOperator obiektów CarShopOperator obiektów CarShopOperator obiektów CarShop
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
Spring Google Guice PicoContainer Weld EasyDI Silk DICarOperator obiektów CarShopOperator obiektów CarShopOperator obiektów CarShop
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
Journal of Computer Sciences Institute
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
Spring Google Guice PicoContainer Weld EasyDI Silk DICarOperator obiektów CarShopOperator obiektów CarShopOperator obiektów CarShop
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]
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-10-31
PrzyjęteŚ 2017-11-02
55
Porównanie możliwo ci bibliotek GTK+ oraz Qt w programowaniu gier Kamil Drzas*, Dominik Alchimowicz*, Maciej Pańczyk
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
Adresy e-mail: [email protected], [email protected]
Comparison of GTK+ and Qt libraries in game development
Kamil Drzas*, Dominik Alchimowicz*, Maciej Pańczyk
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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
*Corresponding author.
E-mail addresses: [email protected], [email protected]
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.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-11-06
PrzyjęteŚ 2017-11-10
59
Technologia blockchain i jej zastosowania
Hlib Dikariev*, Marek Miłosz
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
Adres e-mail: [email protected]
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
*Corresponding author.
E-mail address: [email protected]
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.
3. Metodyka badawcza
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).
Journal of Computer Sciences Institute
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].
Journal of Computer Sciences Institute
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
Przyjęte: 2017-11-13
62
Pięć sposobów wprowadzenia współbieżności do programu w języku C#
Paweł Szyszko*, Jakub Smołka
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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/
Adres e-mail: [email protected]
Five ways to insert concurrency to a program written in C#
Paweł Szyszko*, Jakub Smołka
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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
E-mail address: [email protected]
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].
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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ę.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-11-08
PrzyjęteŚ 2017-11-13
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
*Autor do korespondencji.
Adresy e-mail: [email protected], [email protected]
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
*Corresponding author.
E-mail addresses: [email protected], [email protected]
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
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-11-02
PrzyjęteŚ 2017-11-13
73
Analiza porównawcza narzędzi online do zarządzania i komunikacji w projektach informatycznych
Łukasz Naumiuk*, Elżbieta Miłosz
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
Adres e-mail: [email protected]
Comparative analysis of online tools for management and communication
in IT projects
Łukasz Naumiuk*, Elżbieta Miłosz
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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
*Corresponding author.
E-mail address: [email protected]
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
Journal of Computer Sciences Institute
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ą
Journal of Computer Sciences Institute
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 ć
Journal of Computer Sciences Institute
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
Przyjęte: 2017-11-16
77
Porównanie wydajności emulatora i fizycznego urządzenia z systemem Android
w oparciu o algorytm szachowy
Kamil Litkowski*, Jakub Smołka
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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ść
*Autor do korespondencji.
Adres e-mail: [email protected]
Performance comparison of an emulator and physical Android mobile device
based on chess algorithm
Kamil Litkowski*, Jakub Smołka
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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
*Corresponding author.
E-mail address: [email protected]
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
Journal of Computer Sciences Institute
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.
2. Przegląd literatury
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.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-11-08
PrzyjęteŚ 2017-11-16
82
Porównanie szkieletów aplikacji AngularJS i React.js na przykładzie aplikacji internetowej
Łukasz Capała*, Maria Skublewska-Paszkowska
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
Adresy e-mail: [email protected], [email protected]
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
*Corresponding author.
E-mail addresses: [email protected], [email protected]
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.
Journal of Computer Sciences Institute
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 ć
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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ć
Journal of Computer Sciences Institute
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
WysłaneŚ 2017-11-12
PrzyjęteŚ 2017-11-17
87
Porównanie wydajno ci wieloplatformowego szkieletu aplikacji na platformach Android i Windows 10 Mobile.
Dawid Wieczorek*, Jakub Smołka
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
Adres e-mail: [email protected]
Comparison of performance multi-platform application core on Android and
Windows 10 Mobile.
Dawid Wieczorek*, Jakub Smołka
Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland
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
*Corresponding author.
E-mail address: [email protected]
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
Journal of Computer Sciences Institute
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].
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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).
Journal of Computer Sciences Institute
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
Przyjęte: 2017-11-21
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.
Adres e-mail: [email protected]
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
*Corresponding author.
E-mail address: [email protected]
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
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
Framework Liczba linii kodu
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.
Journal of Computer Sciences Institute
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.
Framework Liczba linii kodu
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
JCSI 6 (2018) 97-101
Wysłane: 2017-11-15
Przyjęte: 2017-11-20
97
Wydajność pracy z bazami danych w aplikacjach ASP.NET MVC
Paweł Borys*, Beata Pańczyk
Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska
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
*Autor do korespondencji.
Adres e-mail: [email protected]
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
*Corresponding author.
E-mail address: [email protected]
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].
Journal of Computer Sciences Institute
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.
Journal of Computer Sciences Institute
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
Journal of Computer Sciences Institute
100
Tabela 5. Wyniki pomiarów dla scenariusza S2.
Baza danych Narzędzie Czas [s] Pamięć [MB]
MSSQL
ADO.NET 144 5,11
Entity Framework 1 242 5,36
NHibernate 764 2,81
MySQL
ADO.NET 480 2,85
Entity Framework 1 517 5,26
NHibernate 885 4,14
Tabela 6. Wyniki pomiarów dla scenariusza S3.
Baza danych Narzędzie Czas [s] Pamięć [MB]
MSSQL
ADO.NET 2 0,11
Entity Framework 3 0,11
NHibernate 40 1,40
MySQL
ADO.NET 3 0,15
Entity Framework 4 0,21
NHibernate 23 1,42
Tabela 7. Wyniki pomiarów dla scenariusza S4.
Baza danych Narzędzie Czas [s] Pamięć [MB]
MSSQL
ADO.NET 12 0,52
Entity Framework 147 5,27
NHibernate 87 4,83
MySQL
ADO.NET 18 0,93
Entity Framework 157 5,58
NHibernate 78 4,08
Tabela 8. Wyniki pomiarów dla scenariusza S5.
Baza danych Narzędzie Czas [s] Pamięć [MB]
MSSQL
ADO.NET 112 0,08
Entity Framework 77 1,88
NHibernate 22 0,54
MySQL
ADO.NET 168 0,21
Entity Framework 67 2,21
NHibernate 34 0,48
Tabela 9. Wyniki pomiarów dla scenariusza S6.
Baza danych Narzędzie Czas [s] Pamięć [MB]
MSSQL
ADO.NET 410 0,68
Entity Framework 213 4,10
NHibernate 124 3,71
MySQL
ADO.NET 778 1,17
Entity Framework 302 8,42
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
Journal of Computer Sciences Institute
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]