journal of computer sciences institutebc.pollub.pl/content/13287/vol11-2019.pdf · framework django...

Redakcja JCSIe-mail: [email protected]: jcsi.pollub.plInstytut Informatyki Wydział Elektrotechniki i Informatyki

Politechnika Lubelskaul. 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ż. Maria Skublewska-Paszkowskadr inż. Jakub Smołkadr inż. Dariusz Gutekdr inż. Marek Miłoszdr inż. Grzegorz Koziełdr inż. Kamil Żyładr inż. Jacek Kęsikdr Mariusz Dzieńkowskidr inż. Maciej Pańczykdr inż. Małgorzata Plechawska-Wójcikdr Edyta Łukasik

Skład komputerowy: Monika Kaczorowskae-mail: [email protected]

Projekt okładki:Marta Zbańska

JCSI Editoriale-mail: [email protected]: jcsi.pollub.plInstitute of Computer Science Faculty of Electrical Engineering and Computer ScienceLublin University of Technologyul. 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:Maria Skublewska-PaszkowskaJakub SmołkaDariusz GutekMarek MiłoszGrzegorz KoziełKamil ŻyłaJacek KęsikMariusz DzieńkowskiMaciej PańczykMałgorzata Plechawska-WójcikEdyta Łukasik

Computer typesetting: Monika Kaczorowskae-mail: [email protected]

Cover design:Marta Zbańska

ISSN 2544-0764

Spis treści

1. WYDAJNOŚĆ PRACY Z BAZAMI DANYCH APLIKACJI TWORZONYCH W DJANGO

BARTOSZ NEJMAN, BEATA PAŃCZYK.......................................................................................................822. TWORZENIE APLIKACJI INTERNETOWYCH NA PLATFORMIE JEE I PHP – ANALIZA PORÓWNAWCZA

SEBASTIAN JĘDRYCH, BARTŁOMIEJ JĘDRUSZAK, BEATA PAŃCZYK.........................................................863. ANALIZA ZASTOSOWANIA NARZĘDZIA CUCUMBER W TESTOWANIU APLIKACJI

ILLIA HERMAN, MAŁGORZATA PLECHAWSKA-WÓJCIK............................................................................914. WDROŻENIE APLIKACJI INTERNETOWYCH WSPOMAGAJĄCYCH ZARZĄDZANIE PRZEDSIĘBIORSTWEM

NA PRZYKŁADZIE WYBRANEJ GMINY

MATEUSZ PONIATOWSKI, ELŻBIETA MIŁOSZ............................................................................................965. PORÓWNANIE WYDAJNOŚCI ALGORYTMÓW SZYFROWANIA NA PLATFORMIE IOS

JAKUB TUDRUJ, PIOTR KOPNIAK.............................................................................................................1016. WYKORZYSTANIE ELEKTRONICZNEGO PULSOMETRU ORAZ DŹWIĘKU PRZESTRZENNEGO DO

INTERAKCJI Z UŻYTKOWNIKIEM W VRPATRYK PLEWA, TOMASZ SZYMCZYK....................................................................................................106

7. WYKORZYSTANIE KONTROLERA KINECT DO INTERAKCJI Z UŻYTKOWNIKIEM W VRPRZEMYSŁAW SAMOŃ, TOMASZ SZYMCZYK...........................................................................................114

8. ANALIZA RÓŻNIC POMIĘDZY SZKIELETAMI APLIKACJI NATYWNYCH I WIELOPLATFORMOWYCH

KINGA ALEKSANDRA ŁOBEJKO...............................................................................................................1199. PORÓWNANIE MOŻLIWOŚCI TWORZENIA APLIKACJI PHP NA PRZYKŁADZIE YII2 I LARAVEL

OLENA SYDORCHUK................................................................................................................................12510. METODY PROWADZENIA TESTÓW JEDNOSTKOWYCH W STANDARDZIE C++14 Z WYKORZYSTANIEM

BIBLIOTEKI GMOCKKAMIL STRÓZIK.......................................................................................................................................131

11. PORÓWNANIE WYDAJNOŚCI JĘZYKA SKRYPTOWEGO ORAZ KOMPILOWANEGO NA PODSTAWIE DZIAŁANIA ALGORYTMU GENETYCZNEGO

FILIP DZIKOWSKI.....................................................................................................................................13712. PORÓWNANIE NARZĘDZI DO TWORZENIA APLIKACJI TYPU SPA NA PRZYKŁADZIE EMBER I REACT

JACEK WRÓBEL.......................................................................................................................................14513. ANALIZA PORÓWNAWCZA WYBRANYCH ZAGADNIEŃ PROGRAMOWANIA WYMAGAJĄCYCH

KOMUNIKACJI MIĘDZYPROCESOWEJ I MIĘDZYWĄTKOWEJ

KAMIL WRÓBEL......................................................................................................................................14914. ANALIZA MOŻLIWOŚCI WSPÓŁPRACY APLIKACJI MOBILNYCH Z USŁUGAMI SIECIOWYMI TYPU

REST I WEB SERVICE

MATEUSZ ROMAN DARAŻ, PIOTR KOPNIAK...........................................................................................15515. ANALIZA I OCENA REALIZACJI POLITYKI BEZPIECZEŃSTWA INFORMACJI W WYBRANYCH POLSKICH

I UKRAIŃSKICH PRZEDSIĘBIORSTWACH BRANŻY ITANDRIY ANDRIYCHUK.............................................................................................................................163

Contents

1. EFFICIENCY OF DATABASES IN DJANGO-BASED APPLICATIONS

BARTOSZ NEJMAN, BEATA PAŃCZYK.......................................................................................................822. COMPARATIVE ANALYSIS OF WEB APPLICATIONS DEVELOPMENT USING JEE AND PHP

SEBASTIAN JĘDRYCH, BARTŁOMIEJ JĘDRUSZAK, BEATA PAŃCZYK.........................................................863. STUDY ON APPLYING THE CUCUMBER TOOL IN TESTING APPLICATIONS

ILLIA HERMAN, MAŁGORZATA PLECHAWSKA-WÓJCIK............................................................................914. IMPLEMENTATION OF WEB APPLICATIONS SUPPORTING BUSINESS MANAGEMENT BASING ON

COMPANIES IN CHOSEN GEOGRAPHIC AREA

MATEUSZ PONIATOWSKI, ELŻBIETA MIŁOSZ............................................................................................965. COMPARISON OF ENCRYPTION ALGORITHMS PERFORMANCE ON IOS PLATFORM

JAKUB TUDRUJ, PIOTR KOPNIAK.............................................................................................................1016. THE USE OF AN ELECTRONIC HEART RATE MONITOR AND SURROUND SOUND TO INTERACT WITH A

USER IN VRPATRYK PLEWA, TOMASZ SZYMCZYK....................................................................................................106

7. USING KINECT CONTROLLER FOR INTERACTING WITH USER IN VRPRZEMYSŁAW SAMOŃ, TOMASZ SZYMCZYK...........................................................................................114

8. ANALYSIS OF THE DIFFERENCES BETWEEN FRAMEWORKS OF NATIVE APPLICATIONS AND CROSS-PLATFORM

KINGA ALEKSANDRA ŁOBEJKO...............................................................................................................1199. COMPARISON OF PHP APPLICATIONS DEVELOPMENT USING THE YII2 AND LARAVEL EXAMPLES

OLENA SYDORCHUK................................................................................................................................12510. METHODS FOR CONDUCTING UNIT TESTS IN THE C++14 STANDARD USING THE GMOCK LIBRARY

KAMIL STRÓZIK.......................................................................................................................................13111. COMPARISON OF THE PERFORMANCE OF SCRIPTING AND COMPILED LANGUAGES BASED ON THE

OPERATION OF THE GENETIC ALGORITHM

FILIP DZIKOWSKI.....................................................................................................................................13712. COMPARISON OF SINGLE-PAGE APPLICATION DEVELOPMENT USING EMBER AND REACT EXAMPLE

JACEK WRÓBEL.......................................................................................................................................14513. COMPARATIVE ANALYSIS OF SELECTED PROGRAMMING ISSUES REQUIRING INTER-PROCESS AND

INTER-THREAD COMMUNICATION

KAMIL WRÓBEL......................................................................................................................................14914. ANALYSIS OF THE POSSIBILITIES OF COOPERATION OF MOBILE APPLICATIONS WITH NETWORK

SERVICES OF THE TYPE REST AND WEB SERVICE

MATEUSZ ROMAN DARAŻ, PIOTR KOPNIAK...........................................................................................15515. ANALYSIS AND EVALUATION OF THE IMPLEMENTATION OF INFORMATION SECURITY POLICY IN

SELECTED POLISH AND UKRAINIAN IT COMPANIES

ANDRIY ANDRIYCHUK.............................................................................................................................163

JCSI 11 (2019) 82-85

Wysłane: 2018-11-30

Przyjęte: 2018-12-01

82

Wydajność pracy z bazami danych aplikacji tworzonych w Django

Bartosz Nejman*, Beata Pańczyk Politechnika Lubelska, Instytut Informatyki, Nadbystrzycka 36B, 20-618 Lublin, Polska

Streszczenie. Tworzenie aplikacji internetowych składa się z wielu procesów. Jednym z nich jest wybór odpowiedniego systemu bazy danych gdyż to od niej może w dużej mierze zależeć szybkość działania aplikacji. Duża liczba dostępnych systemów baz danych sprawia iż wybór ten nie jest łatwy. Niniejszy artykuł przedstawia porównanie wydajności pracy z bazami danych na przykładzie aplikacji tworzonych w Django oraz trzech systemów bazodanowych: MySQL, PostgreSQL oraz MongoDB.

Słowa kluczowe: Django; MongoDB; MySQL; PostgreSQL

*Autor do korespondencji.

Adres e-mail: [email protected]

Efficiency of databases in Django-based applications

Bartosz Nejman*, Beata Pańczyk

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

Abstract. Development of web applications consists of many processes. One of them is choosing appropriate database management system

which may have huge impact on application performance. Large availability of database management systems makes it not an easy choice. The

goal of this paper is to compare efficiency of databases in Django-based applications and three different database management systems:

MySQL, PostgreSQL and MongoDB.

Keywords: Django; MongoDB; MySQL; PostgreSQL

*Corresponding author.

E-mail address: [email protected]

1. Wstęp

Na przestrzeni ostatnich lat można dostrzec znaczny postęp w tworzeniu aplikacji internetowych. Jeszcze kilka lat

temu strony WWW składały się głównie ze statycznego kodu HTML, przez co nie można było nadać im miana aplikacji. Wraz z postępującym rozwojem aplikacji internetowych

zaczęto przechowywać co raz więcej danych. Treści na stronie w większości generowane są dynamicznie, na

przykład poprzez pobranie ich z bazy danych . Wyższy poziom zaawansowania aplikacji wiążę się jednak z dłuższym czasem ładowania strony co jest dużym problemem

w obecnych czasach. Rozwiązaniem jest dobranie odpowiednich narzędzi, a jednym z najważniejszych jest baza danych . Dobranie odpowiedniego systemu dla konkretnej

aplikacji nie jest łatwe. Przeprowadzenie badań wydajności poszczególnych systemów bazodanowych może być bardzo kosztowne. Z pomocą przychodzą narzędzia wykorzystujące mapowanie obiektowo-relacyjne (ang. Object-Relational

Mapping – ORM). Zaletą tego typu narzędzi jest możliwość przełączenia się między różnymi systemami bazodanowymi bez konieczności przebudowywania całej aplikacji .

2. Cel i teza

Celem niniejszego artykułu jest bezpośrednie porównanie wydajności różnych systemów bazodanowych, wykorzystując aplikację webową napisaną w Django. Do realizacji badań

zostaną wykorzystane najpopularniejsze systemy

bazodanowe:

relacyjny MySQL,

relacyjnyPostgreSQL,

nierelacyjny system MongoDB .

Za tezę badawczą przyjęto:

Dla aplikacji tworzonych w Django, relacyjne bazy danych

(MySQL i PostgreSQL) są bardziej wydajne w porównaniu do nierelacyjnej bazy MongoDB.

3. Systemy zarządzania bazami danych

3.1. MongoDB

MongoDB to nierelacyjny system bazodanowy

napisany w języku C++. Wysoką wydajność w porównaniu do relacyjnych systemów zapewnia sposób przechowywania danych w postaci dokumentów przypominających format JSON. Tego typu sposób zapewnia kompatybilność z większością najpopularniejszych języków programowania między innymi Python, czy PHP .

Najważniejsze cechy MongoDB [6]:

1) dane przechowywane są w kolekcjach w postaci dokumentów w formacie BSON (binary JSON);

Journal of Computer Sciences Institute

83 83

2) zaawansowany język zapytań wspierający operacje wejścia/wyjścia i agregację danych;

3) wykorzystywanie indeksów pozwala na szybsze wykonywanie zapytań;

4) automatyczna obsługa sytuacji awaryjnych (ang. failover);

5) pozioma skalowalność zapewniona dzięki dystrybuowaniu danych po klastrach podzespołów (w j.ang sharding) .

3.2. MySQL

MySQL jest jednym z najpopularniejszych systemów zarządzania relacyjnymi bazami danych (ang. Relational Database Management System - RDBMS). Dzięki sprawdzonej wydajności, niezawodności i łatwości użycia MySQL został najczęściej wybieranym systemem bazodanowym w aplikacjach webowych. Wykorzystywany

jest na całym świecie, między innymi przez takich gigantów jak Facebook, Twitter, czy Youtube . Historia MySQL sięga roku 1995 kiedy to pojawiło się pierwsze wydanie. MySQL jest dostępny na licencji open source jednak właścicielem jest Oracle, które również udostępnia licencje komercyjne. Na rynku główną konkurencję stanowią PostgreSQL, Oracle oraz Microsoft SQL Server. Na ich tle MySQL wyróżnia się przede wszystkim następującymi cechami :

1) wydajność - myślą przewodnią projektu była szybkość działania;

2) łatwość użycia – podstawowa konfiguracja sprowadza się do kilku kliknięć;

3) niskie koszty użytkowania dzięki wsparciu ogromnej społeczności.

3.3. PostgreSQL

PostgreSQL znany również jako Postgres, to obok

MySQL jeden z najpopularniejszych systemów open source

do zarządzania obiektowo-relacyjnymi bazami danych .

PostgreSQL zyskał silną reputację dzięki sprawdzonej architekturze, niezawodności, integracji danych oraz wysokiej skalowalności. Wspiera wszystkie główne systemy operacyjne. Od 2001 roku jest również zgodny ze standardem ACID zapewniając niepodzielność, spójność, izolację

transakcji oraz trwałość danych.

4. Porównanie systemów

4.1. rodowisko testowe

Do przeprowadzenia badań została napisana aplikacja webowa w języku Python w wersji 3.7.0 z wykorzystaniem

o frameworka Django w wersji 2.1.1. Dla każdego systemu bazy danych została wykorzystana ta sama aplikacja testowa.

Wszystkie testy zostały przeprowadzone na tym samym sprzęcie: Lenovo y510P, 64 bitowy system Windows 10

PRO. Komputer został wyposażony w procesor Intel® Core™ i5-4200 M o taktowaniu 2.5GHz, kartę graficzną NVIDIA GeForce GT 755M, 8 GB pamięci ram DDR3 o częstotliwości 1600 MHz oraz dysk SSD WD GREEN

o pojemności 240GB. Wykorzystane bazy danych to MySQL

5.6.37, PostgreSQL 10.6 oraz MongoDB 3.4.7.

4.2. Scenariusze testowe

Scenariusze testowe realizują fundamentalne operacje

wykonywane w aplikacjach webowych. Te operacje to

wstawianie, odczytywanie danych oraz aktualizowanie

danych. Testy są wykonywane na tabelach prostych i tabelach

złożonych, które posiadają odwołania do innych tabel. Dla każdego scenariusza i każdej bazy danych, operacje zostały wykonane 1000 razy, a ich czas zsumowany. Tabela 1

przedstawia zestawienie scenariuszy.

Tabela . Scenariusze testów

Numer

scenariusza

Opis scenariusza

1 Utworzenie jednego modelu bez relacji

2 Utworzenie jednego modelu z relacjami

3 Utworzenie stu modeli bez relacji

4 Utworzenie stu modeli z relacjami

5 Pobranie jednego modelu bez relacji

6 Pobranie jednego modelu z relacjami

7 Pobranie stu modeli bez relacji

8 Pobranie stu modeli z relacjami

9 Warunkowe pobranie modeli bez relacji

10 Warunkowe pobranie modeli z relacjami

11 Warunkowa aktualizacja pola w 100 modelach

12 Warunkowa aktualizacja relacji w 100 modelach

4.3. Aplikacja testowa

Framework Django sam wykonuje znaczną część procesu budowy aplikacji. Implementacja aplikacji testowej

ograniczyła się do podstawowych kroków:

1) skonfigurowanie bazy danych,

2) zdefiniowanie modeli

3) wykonanie migracji.

4) wdrożenie panelu administratora,

5) implementacja scenariuszy testowych.

Do przeprowadzenia badań zdefiniowano dwa modele. Pierwszy z nich (przykład 1), to model Team. Model ten

reprezentuje drużynę i zawiera jedno pole name typu

Charfield z argumentem max_length o wartości 255, co

przekłada się na wartość typu string o maksymalnej długości 255 znaków. Zdefiniowanie metody __str__ w tym modelu

sprawi, że w momencie rzutowania obiektu klasy Team na typ

string, zostanie zwrócona nazwa drużyny.

Przykład 1. Model drużyny Team

class Team(models.Model): name = models.CharField(max_length=255) def __str__(self): return self.name

Przykład 2 przedstawia fragment kodu reprezentującego model meczu Match. W klasie Match zostały zdefiniowane pola home_team oraz away_team, które są odwołaniami (kluczami obcymi) do modeli drużyn. Liczby zdobytych

punktów przez drużyny zostaną zapisane w polach

home_team_score oraz away_team_score. Pola te mają zdefiniowaną regułę pozwalającą na zapisanie dodatnich


84 84

liczb całkowitych lub null (w przypadku gdy mecz jeszcze się nie odbył). Data meczu zapisywana jest w polu date. Pole

finished określa, czy dany mecz już się odbył - jest to pole

typu boolean. Pole typu float definiuje mnożnik punktowy

z domyślną wartością 1.

Dodatkowo zdefiniowano walidację tworzonego meczu, która sprawdza, czy drużyna gospodarzy nie jest jednocześnie drużyną gości. W przypadku próby utworzenia takiego obiektu - aplikacja zwróci błąd. Rzutowanie na typ string obiektu klasy Match zwróci nazwę drużyny gości oraz gospodarzy.

Przykład 2. Model meczu Match

class Match(models.Model): home_team = models.ForeignKey( Team, on_delete=models.CASCADE, related_name='%(class)s_home_team' ) away_team = models.ForeignKey( Team, on_delete=models.CASCADE, related_name='%(class)s_away_team' ) home_team_score = models.PositiveSmallIntegerField( blank=True,

null=True ) away_team_score = models.PositiveSmallIntegerField( blank=True, null=True ) date = models.DateTimeField( null=True ) finished = models.BooleanField( default=False ) reward_multiplier = models.FloatField( default=1 ) def clean(self, *args, **kwargs): from django.core.exceptions import ValidationError if self.home_team == self.away_team: raise ValidationError("Error")

super(Match, self).clean(*args, **kwargs) def save(self, *args, **kwargs): self.full_clean() super(Match, self).save(*args, **kwargs) def __str__(self): return "%s vs %s" \ % (self.home_team.name, self.away_team.name)

Scenariusze zostały wykonane wykorzystując wiersz poleceń. Dla wszystkich scenariuszy utworzono jedną klasę Command, która dziedziczy po klasie BaseCommand.

W Django klasy tworzące komendę, dostępną z wiersza

poleceń, umieszcza, się w folderze management/commands.

Nazwa pliku komendy ma istotne znaczenie ponieważ stanowi ostatni człon nazwy komendy. Przykładowo plik komendy o nazwie tests.py tworzy komendę „python

manage.py tests”.

Każdy ze scenariuszy został zdefiniowany w oddzielnej metodzie. Czas poszczególnych scenariuszy mierzony jest za pomocą funkcji time() pochodzącej z klasy time. Fragment

kodu mierzący czas przedstawia przykład 3. Ten sam sposób mierzenia czasu zaimplementowany jest w każdym ze scenariuszy. Implementację jednego ze scenariuszy pokazuje

przykład 3.

Przykład 3. Implementacja przykładowego scenariusza

def scenario1(self): scenario = ScenarioInfo(1) scenario.tries = self.tries for x in range(0, scenario.tries): start_time = time.time() team = Team()

team.name = "New Team" team.save(True) elapsed_time = time.time() - start_time scenario.total_time += elapsed_time return scenario

4.4. Porównanie wydajno ci

Na rysunkach 1-6 przedstawiono wyniki poszczególnych

scenariuszy.

Rys. . Utworzenie jednego modelu bez i z relacjami (scenariusz 1 i 2)

Rys. 2. Utworzenie 100 modeli bez i z relacjami (scenariusz 3 i 4)


85 85

Rys. 3. Pobranie jednego modelu bez relacji i z relacją (scenariusz 5 i 6)

Rys. 4. Pobranie 100 modeli bez relacji i z relacją (scenariusz 7 i 8)

Rys. 5. Warunkowe pobranie modeli bez i z relacją (scenariusz 9 i 10)

Rys. 6. Warunkowa aktualizacja w 100 modelach (scenariusz 11 i 12)

5. Wnioski

Na podstawie wyników badań, można wywnioskować, że MongoDB całkowicie nie nadaje się do aplikacji napisanych w Django. Jedną z przyczyn może być fakt, że baza MongoDB nie jest oficjalnie wspierana przez twórców Django. Implementacja MongoDB w zaprezentowanej

aplikacji testowej została zrealizowana dzięki zewnętrznej paczce djongo. Działanie tej paczki polega na tłumaczeniu zapytań SQL, wygenerowanych przez ORM na składnię MongoDB, co wiąże się z utratą wydajności przy każdym zapytaniu. Kolejnym istotnym czynnikiem jest to, że MongoDB nie wspiera kluczy obcych, co w efekcie .

w porównaniu do relacyjnych systemów (na przykładzie scenariuszy, w których operacje związane były z relacjami)

znacznie wydłuża czas dostępu do danych.

Przewaga PostgreSQL w większości scenariuszy nie oznacza iż jest to jedyny słuszny system w przypadku aplikacji internetowych. W przypadku aplikacji testowej

wykonanej na potrzeby tego artykułu, różnica w szybkości między PostgreSQL, a MySQL wynosi około 17%. Jednak gdyby w aplikacji położyć nacisk na tworzenie modeli

z relacjami - przewaga PostgreSQL mogłaby znacząco zmaleć. Największą przewagę PostgreSQL (ponad

dwukrotnie mniejszym od MySQL) uzyskał w scenariuszu,

który polegał na warunkowym pobieraniu modeli z czasem.

Podsumowując - osoba poszukująca najbardziej

wydajnego systemu bazodanowego do pracy z aplikacją Django powinna wziąć pod uwagę to, czy aplikacja będzie częściej wykonywała operacje odczytu, czy zapisu.

W przypadku przewagi operacji odczytu, a zwłaszcza odczytu ograniczonego warunkami, lepszym rozwiązaniem może okazać się PostgreSQL, natomiast przewaga operacji zapisu do bazy danych stawia MySQL na lepszej pozycji.

Wyniki uzyskane z testów pozwoliły potwierdzić, postawioną na wstępie tezę.

Literatura

[1] https://www.devsaran.com/blog/history-web-application-

development [29.11.2018]

[2] http://mst.mimuw.edu.pl/lecture.php?lecture=bad&part=Ch1

[29.11.2018]

[3] https://www.thoughtfulcode.com/orm-active-record-vs-data-

mapper/ [29.11.2018]

[4] https://db-engines.com/en/ranking [29.11.2018]

[5] https://bytescout.com/blog/2014/09/mongodb-history-and-

advantages.html [29.11.2018]

[6] Chodorow K.: MongoDB: The Definitive Guide, Second

Edition, O’Reilly Media, 2013.

[7] https://www.oracle.com/MySQL/ [29.11.2018]

[8] https://bytescout.com/blog/2014/09/mongodb-history-and-

advantages.html [29.11.2018]

[9] Obe R., Hsu L.: PostgreSQL: Up and Running, Second Edition,

O’Reilly Media, 2015.

https://db-engines.com/en/ranking

https://bytescout.com/blog/2014/09/mongodb-history-and-advantages.html


https://www.oracle.com/MySQL/



JCSI 11 (2019) 86-90

Wysłane: 2018-11-27


86

Tworzenie aplikacji internetowych na platformie JEE i PHP – analiza

porównawcza

Sebastian Jędrych*, Bartłomiej Jędruszak, Beata Pańczyk

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

Streszczenie. Artykuł analizuje możliwości tworzenia aplikacji internetowych z wykorzystaniem dwóch konkurencyjnych rozwiązań opartych na językach Java (Spring) i PHP (Laravel). Porównano między innymi elementy implementacji, aspekty bezpieczeństwa oraz wydajność stworzonych aplikacji testowych. Celem badań było wskazanie platformy oferującej większe możliwości, określenie która jest łatwiejsza do opanowania i bardziej przyjazna dla programisty, a także wskazanie, która jest bardziej wydajna. Analizując rozwiązania stosowane w obu

technologiach – podjęto próbę oceny ich konkurencyjności względem siebie.

Słowa kluczoweŚ PHP; JAVA; Spring; Laravel



Comparative analysis of web applications development using JEE and PHP

Sebastian Jędrych*, Bartłomiej Jędruszak, Beata Pańczyk


Abstract. The article analyses the possibilities of creating web applications using two competing solutions based on Java (Spring) and PHP

(Laravel) languages. The elements of implementation, security aspects and the efficiency of created test applications were compared. The aim of

the research was to identify a platform offering greater opportunities, easier to learn and more programmer-friendly, and also a more efficient

indication. Analysing the solutions used in both technologies - an attempt was made to assess their competitiveness with each other.

Keywords: PHP; JAVA; Spring; Laravel



1. Wstęp

Liczba dostępnych na rynku rozwiązań do wytwarzania oprogramowania zmusza do ciągłego poszukiwania technologii umożliwiającej szybkie i bezpieczne zrealizowanie projektu. Podejmując decyzję o wyborze języka programowania oraz konkretnego szkieletu programistycznego, czy też konkretnego szablonu programistycznego, najczęściej korzysta się ze źródeł zbierających statystyki i opinie użytkowników, np. TIOBE [1]. Opierając się na danych w nim zawartych, wytypowano

Javę i PHP, jako języki cieszące się obecnie popularnością wśród twórców aplikacji internetowych. Dodatkowo

skorzystano z najbardziej popularnych frameworków reprezentujących badane technologie – Spring dla Javy

(Rys.1) i Laravel dla PHP (Rys. 2).

2. Cel badań

Celem porównania było sprawdzenie, który z frameworków jest technologią oferującą większe możliwości wytwarzania oprogramowania i który osiąga lepsze wyniki w testach wydajnościowych.

Rys. 1. Popularność frameworków w roku 2018 dla Javy [2]

3. Metoda badawcza

Badania zrealizowano za pomocą dwóch aplikacji testowych, zaimplementowanych w wybranych


87

frameworkach. Obie aplikacje oferują takie same funkcjonalności prostej aplikacji typu CRUD. W obu, interfejs

graficzny jest realizowany z wykorzystaniem szablonów Bootstrap, obie też wykorzystują ten sam system zarządzania danymi MySQL. Z uwagi na odmienną specyfikę technologii do zarządzania szablonami widoków wykorzystano Thymeleaf [4] w projekcie Spring i silnik Blade [5] w projekcie Laravel.

Rys. 2. Popularność frameworków w roku 2018 dla PHP [3]

Aplikacja testowa jest rodzajem książki kucharskiej z przepisami dań i oferuje funkcjonalności typowej aplikacji CRUD. Model bazy danych prezentuje rysunek 3. Interfejs

graficzny obu aplikacji wygląda identycznie (Rys. 4).

Rys. 3. Diagram klas wykorzystany w aplikacjach testowych

Rys. 4. Strona główna aplikacji testowej

4. Analiza porównawcza

Ogólną charakterystykę wybranych technologii przedstawiono w tabeli 1.

Tabela 1. Ogólna charakterystyka frameworków

Spring Laravel Twórca Pivotal Software Taylor Otwell Data wypadania pierwszej

wersji 1 października 2002

9 czerwca

2011 Wersja oraz data wydania

najnowszej wersji 5.1- 21 września 2018

5.7- 4 września 2018

Język programowania Java PHP .Technologie widoku Thymeleaf, JSP,

jTwig Blade, Twig,

Volt, Wzorzec projektowy MVC MVC Licencja Apache 2.0 MIT

Analiza porównawcza została przeprowadzona w oparciu o następujące kryteria:

model tworzenia aplikacji,

obsługa operacji bazodanowych, bezpieczeństwo, wydajność i wybrane metryki kodu.

4.1. Model tworzenia aplikacji

Oba frameworki zostały oparte na tym samym szablonie - MVC (ang. Model-View-Controller), jednak każdy realizuje własne modyfikacje, przedstawione na rysunku 5.

Rys. 5. Modyfikacje modelu MVC w Spring i Laravel [6, 7]


88

Za tworzenie elementów aplikacji w projekcie Laravel

odpowiedzialny jest interfejs Artisan CLI, skojarzony

z konsolą danego systemu lub zaimplementowany w wybranym IDE. Spring został oparty na metodzie adnotacji, które nadają klasom odpowiednią rolę. Przykład 1 i 2 przedstawia oba te podejścia dla kontrolera, odpowiednio w Spring i Laravel.

Przykład 1. Kontroler z adnotacjami w Spring

@Controller public class Kontroler { @GetMapping Typ index() {} @PostMapping Typ save() {} @PutMapping(„/{id}”) Typ edit(@PathVariable Typ id) {} @DeleteMapping(„/{id}”) Typ delete(@PathVariable Typ id) {} }

Przykład. 2. Kontroler w Laravel

class Kontroler extends Controller { public function index() {} public function save() {} public function edit($id) {} public function delete($id) {} }

4.2. Obsługa bazy danych

Liczba standardowych i najczęściej wykonywanych operacji na bazie danych (tzn. operacji typu CRUD) pozwala

na stworzenie jednolitego mechanizmu dostępu do danych i ich modyfikacji dla wielu modeli aplikacji. Takie podejście zastosowano w Eloquent ORM [8], który jest podstawowym sposobem obsługi obiektów bazodanowych w Laravel (Przykład 3).

Przykład. 3. Eloquent ORM w Laravel

return Notes::where('RECIPE_ID', $this->ID) ->select('NOTES.RECIPE_NOTES') ->get();

Rozszerzoną składnię poleceń SQL w Laravel udostępniono za pośrednictwem Query Builder, którego składnia jest zbliżona do podstawowej składni języka PHP, opierającego się na parametryzacji (Przykład 4).

Przykład. 4. Query Builder w Laravel

return DB::table('RECIPE') ->Join('NOTES', function($join) { $join->on('RECIPE.ID', '=', 'NOTES.RECIPE_ID') ->where('NOTES.RECIPE_ID', '=', $this->ID); }) ->select('NOTES.RECIPE_NOTES') ->get();

Spring pozwala obsługiwać bazę danych na wiele sposobów, ale szczególnie przydatne są mechanizmy ORM (np.

Hibernate) oraz podstawowy interfejs JDBC. Od wersji

Spring 2.0, za standard uważa się Spring Data [9], który opiera się na sygnaturach będących podstawą języka DSL (ang. domain-specific language). Dzięki temu, za

pośrednictwem jednego z dostępnych interfejsów, możliwe jest zarządzanie bazą bez znajomości języka SQL (Przykład 5).

Przykład 5. Interfejs JpaRepository w Spring

@NoRepositoryBean public interface JpaRepository<T, ID> extends PagingAndSortingRepository<T, ID>, QueryByExampleExecutor<T> { List<T> findAll(); List<T> finAll(Sort varl); List<T> findAllById(Iterable<ID> varl); <S extends T> List<S> saveAll(Iterable<S> varl); }

4.3. Bezpieczeństwo

Zabezpieczenia w aplikacjach internetowych są tematem nie tylko skomplikowanym z naukowego punktu widzenia,

ale też trudnym do implementacji z powodu wielu możliwości potencjalnych ataków i nieprzewidywalności działań użytkowników. Technologie starają się nadążać z identyfikowaniem powszechnych mechanizmów wykorzystywanych do uzyskania wrażliwych danych. Obrona przed typowym atakiem SQL Injection, czy zabezpieczenie

przesyłanych danych z wykorzystaniem kryptografii, stało się koniecznością. Na rysunku 6 przedstawiono reprezentacje

mechanizmu uwierzytelnienia połączenia dla obu technologii.

Rys. 6. Uwierzytelnienie połączenia

4.4. Wydajno ć

Specyfika aplikacji niejednokrotnie wymusza efektywne

renderowanie zawartości strony. Podejścia do sposobu wyświetlania są ściśle powiązane z platformą, co ma swoje odwzorowanie w czasie, który jest potrzebny do załadowania całej zawartości. Celem zbadania tego kryterium, skorzystano

z ChromeDev Tools. Narzędzie to jest wbudowane w przeglądarkę oraz program JMeter, który pozwala symulować obciążenie aplikacji. Na rysunku 7 zestawiono

informacje uzyskane z narzędzia deweloperskiego

przeglądarki Google Chrome. Porównując czasy odpowiedzi dla aplikacji Spring i Laravel, można dostrzec znaczne różnice, spowodowane wykonywaniem kodu PHP osadzonego w widokach aplikacji. Odpowiedzialny za to jest

interpreter PHP, który odczytuje, przetwarza i wykonuje kod,

który w przypadku Javy jest dynamicznie implementowany, eliminując konieczność oczekiwania na cały zestaw danych.


89

Rys. 7. Czasy odpowiedzi zmierzone za pomocą ChromeDev Tools

Pomiary uzyskane za pośrednictwem JMeter, dla jednakowych parametrów obciążenia, przedstawiono w tabelach 2 i 3.

Tabela 2. Czas odpowiedzi dla strony głównej aplikacji

Numer pomiaru

Czas odpowiedzi

Laravel [ms] Czas odpowiedzi

Spring [ms] 1 900 205 2 1050 165 3 440 150 4 410 135 5 480 180 6 1250 105 7 590 195 8 1150 135 9 590 125 10 810 105

redni czas dla 10 pomiarów

714 150

Tabela 3. Czas odpowiedzi dla wybranej podstrony

Numer pomiaru Czas odpowiedzi

Laravel [ms] Czas odpowiedzi

Spring [ms] 1 520 170 2 480 135 3 470 85 4 780 75 5 430 105 6 500 55 7 420 125 8 480 60 9 440 75 10 510 65

redni czas dla 10 pomiarów

503 95

4.5. Wybrane metryki kodu

Tabela 4 zawiera zestawienie podstawowych metryk

kodu. Wyliczenia przeprowadzone zostały za pomocą wtyczki Statistic do IntelliJ IDEA, współpracującej z wieloma technologiami oferującej analizę kodu względem rozszerzeń plików projektu. Wysokie wartości dla Laravel wynikają z wykorzystania bibliotek PHP wchodzących w skład frameworka, które umożliwiają uruchomienie aplikacji

testowej bez konieczności instalowania dodatkowych

pakietów, które potrzebuje Spring – podstawą jest Java Development Kit, z którego można skorzystać za pośrednictwem jednego z wielu IDE.

Tabela 4. Wybrane metryki kodu

Spring Laravel Rozmiar projektu [MB] 1,8 49 Liczba plików 207 21293 Liczba linii kodu HTML 646 2181 Liczba linii kodu Java/PHP 1208 444025

5. Analiza wyników

Implementacja aplikacji testowych oraz przeprowadzona

analiza porównawcza, posłużyły do opracowania tabeli, prezentującej ocenę autorów dla obu frameworków w badanych kategoriach. Tabela 4 przedstawia wyniki w skali

1-5, gdzie 5 jest oceną najwyższą, a 1 najniższą. W kryterium dotyczącym obsługiwanych baz danych, za każdą obsługiwaną bazę przyznawany jest 1 punkt. W przypadku

kryterium opisującego stopień złożoności danego frameworka

– wartość 5 oznacza bardzo łatwy (wymagana niewielka

wiedza deweloperska), natomiast wartość 1 oznacza bardzo trudny (wymagana duża wiedza i doświadczenie deweloperskie).

Tabela 5. Końcowa ocena frameworków

Kryterium oceny Laravel Spring Przejrzystość tworzenia modelu

aplikacji 4 4

Poziom trudności tworzenia aplikacji

4 3

Obsługiwane bazy danych 5 5 Dostępność materiałów 4 5 Wsparcie społeczności 5 5 Wymagany poziom znajomości frameworka

5 2

Przejrzystość struktury katalogów aplikacji

4 5

Wydajność wyświetlania

rekordów 2 5

Końcowa ocena punktowa 32 33

6. Wnioski

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

Laravel należy uznać za platformę prostszą do nauki w porównaniu do Spring;

poziom abstrakcji w Laravel jest na wyższym poziomie

niż w Spring; liczba oferowanych pakietów i funkcji tworzy

z frameworka Spring narzędzie do budowy

zaawansowanych aplikacji, nie tylko internetowych;

Laravel bardziej nadaje się do tworzenia małych i średnich projektów;

do zadań, które wymagają dużej wydajności czasowej zalecany jest Spring;

liczba dostępnych materiałów i poradników dla Spring jest

znacznie obszerniejsza niż w przypadku Laravel.


90

Literatura

[1] Statystyki popularności TIOBE, https://www.tiobe.com/tiobe-

index/ [25.11.2018]

[2] Popularność frameworków Javy, https://zeroturnaround.com/ rebellabs/java-web-frameworks-index-by-rebellabs/

[26.11.2018]

[3] Popularność frameworków PHP, https://coderseye.com/best-php-frameworks-for-web-developers/ [27.11.2018]

[4] Thymealeaf, https://www.thymeleaf.org/ [25.11.2018]

[5] Blade, https://laravel.com/docs/5.6/blade [25.11.2018]

[6] Walls C.: Spring w akcji. Wydanie IV, HELION, Gliwice,

2015.

[7] Saunier R.: Laravel 4 Podstawy tworzenia aplikacji w PHP,

HELION, Gliwice, 2015

[8] Eloquent ORM, https://laravel.com/docs/5.7/eloquent

[25.11.2018]

[9] Spring Data JPA, https://docs.spring.io/spring-data/jpa/

docs/current/reference/html/ [25.11.2018]

JCSI 11 (2019) 91-95

WysłaneŚ 2018-12-07

PrzyjęteŚ 2018-12-16

91

Analiza zastosowania narzędzia Cucumber w testowaniu aplikacji Illia Herman*, Małgorzata Plechawska-Wójcik


Streszczenie. Niniejsza artykuł przedstawia analizę narzędzia do tworzenia testów automatycznych o nazwie Cucumber oraz opisuje jak dane narzędzie jest wykorzystywane w praktyce. W ramach artykułu stworzono kilka przypadków testowych, aby zweryfikować działanie obranego podej cia do testowania w programowaniu w językach Java i Kotlin, atakże został porównany czas wykonania testów w obu językachz rodziny

języków obiektowych.

Słowa kluczowe:Cucumber; Gherkin;BDD; Java; Kotlin.



Study on applying the Cucumber tool in testing applications

Illia Herman*, Małgorzata Plechawska-Wójcik


Abstract.The paper presents an analysis of the Cucumber automated test tool and describes how this tool is used in practice.As part of the

paper, several test cases were created to fully verify the operation of the chosen approach to testing in programming in Java and Kotlin

languages also the time of testing were compared in both languages from the object-oriented language family.

Keywords:Cucumber; Gherkin; BDD; Java; Kotlin.



1. Wstęp

Proces testowania jest niezbędną czę cią procesu

wytwarzania oprogramowania,które jest wykorzystywane dla

potrzeb użytkownika końcowego.Celem testowania

oprogramowania jest uniknięcieróżnego typu usterek

wytwarzanego produktu i organizacji maksymalnie

komfortowej logiki jegoużycia. Testowanie pomaga zweryfikować poprawno ć działania oprogramowania i zebrać informacje na jego temat,aby móc obserwowaćwystąpienie wad i problemów. Dlatego zanim gotowy produkt trafi do

użytkownika, należy pamiętać o testowaniu jako koniecznym

warunku wytwarzania jako ciowego oprogramowania.

Z punktu widzenia technicznego testowanie dzieli się na manualne i automatyczne[9]. Testy automatyczne,

w przeciwieństwie do testów manualnych, bardziej opierają się na programowaniu i takie podej cie wymaga mniejszych nakładów czasu a przede wszystkim pieniędzy [11]. Obecnie

istnieje mnóstwo narzędzi do prowadzenia testów automatycznych, zagadnienie testowania aplikacji jest jednym

z podstawowych zagadnień tworzenia różnego typu oprogramowania.

Tematem podjętym w niniejszym artykule jest analiza

jednego z najpopularniejszych rozwiązań do tworzenia testów automatycznych o nazwie Cucumber. Narzędzie to posiada

dużąbazę użytkowników, dokumentacji technicznej, do ć częste aktualizacje, jest ciągle rozwijane i wspierana jest coraz

większa liczba języków programowania. Cucumber opracowuje język naturalny i zrozumiały dla biznesu, co

rozwiązuje typowy problem podczas komunikacji pomiędzy programistą, czyli twórcą aplikacji i klientem biznesowym.

Wynikiem takiego podej cia jest łatwa dokumentacja testów,

zwiększona ogólna wydajno ć i co najważniejsze szybsze dostarczenie produktu w postaci aplikacji do klienta.

2. Cel badań Celem niniejszego artykułujest oszacowanie czasu

wykonania testów w oparciu o narzędzie Cucumber w takich

językach programowania jak Java i Kotlin.

Hipoteza badawcza postawiona w pracy brzmi: „Nie ma

istotnej różnicy w czasie wykonania testów w narzędziu

Cucumberdla języków programowaniaJava i Kotlin”.

3. Przegląd literatury

Temat automatyzacji testówstaje się coraz popularniejszy

w ród twórców oprogramowania komputerowego, a tym

bardziej dyskusja na ten temat toczy się w zespołach korzystających z metodyk Agile [10] bądź DevOps. Jeżeli chodzi o taki rodzaj testów nie można nie zwrócić uwagi na tak zwane testy behawioralne które są czę cią BDD (z ang. Behavior - driven development) [8]. Składnia testów behawioralnych oparta jest o język półformalny, który pozwala pisać czytelne i zrozumiałe testy nawet dla osób niezwiązanych z branżą IT.

Zgodnie z definicją „ Behaviour - Driven Development polega

na wdrożeniu aplikacji poprzez opisanie jej zachowania z perspektywy interesariuszy” [1].

Grupa badawcza z uniwersytetu RWTH Aachen w swojej

pracy [2], testując różnego typu narzędzia BDD wspomina

o narzędziu Cucumber, jako jednym z najpopularniejszych

i powszechnie stosowanych frameworków tego typu oraz wyróżniają możliwo ć pisania tak zwanychhistoryjek


92

użytkownika i scenariuszy dla przypadków testowych, które można wykorzystać jako podstawę do tworzenia automatycznych testów akceptacyjnych, do których stosuje się badanenarzędzie.

Analizując literaturę na temat Cucumber warto również

odnie ćsię do pracy Olav Undheim [3], która po więcona jest testowaniu, a szczególnie do badania przeprowadzonego przez

Olav Undheim, w którym wzięły udział trzy grupy składające się z dwunastu osób każda. Przed rozpoczęciem badania uczestnicy mieli odpowiedzieć na dwa pytaniaŚ

1) jakie mają do wiadczenie w programowaniu;

2) jakie mają do wiadczenie z Cucumber.

Otrzymane wyniki autor przedstawia w formie wykresów.

Z wykresów wynika, żeŚ

1) żaden uczestnik nie miał więcej niż 2 miesięcy do wiadczenia komercyjnego w programowaniu. Niewielka liczba osób ma krótkie komercyjne do wiadczenie w IT, większo ć zetknęła się z programowaniem na studiach lub

w czasie wolnym;

2) tylko kilka osób słyszało o Cucumber jeszcze przed eksperymentem, ale nikt z niego wcze niej nie korzystał.

Celem badania było opracowanie przez grupę zestawu nieskomplikowanych przypadków testowych oraz odpowiedzenie na parę pytań dotyczących pracy z Cucumber.

Pierwsze pytanie dotyczyło składni Cucumber i grupa C

miała najbardziej zróżnicowane odpowiedzi, ale większo ć nie wykazała większych problemów w zrozumieniu składni narzędzia. Jedynie dwie osoby z grupy C uznało zadanie za raczej trudne.

Kolejne pytanie dotyczyłopotrzeby dodatkowych

wskazówek podczas pisania testów. Tutaj głosy są bardziej zróżnicowane. W grupie A widoczna jest niewielka przewaga osób, chcących uzyskać dalszą pomoc (2 osoby więcej), w grupach B i C większo ć nie potrzebowałaby dalszego wsparcia.

Ostatnią kwestią, poruszaną przez badanie, była chęć pisania testów w wolnym formacie, to znaczy bez użycia pewnej składni w postaci słów kluczowych. W tym przypadku zdecydowana większo ć nie wyraziła takiej chęci. Kilkoro uczestników każdej z grup nie wyraziło zdania.

4. Narzędzie Cucumber

Jest to narzędzie na licencji open source[4] służące do

wykonywania automatycznych testów funkcjonalnych.Zostało opracowane oraz stworzone przez Aslak'a Hellesøy'ac [5],[6] i jest cały czas rozwijane. Stosuje się je głównie jako wsparcie dla BDD [1], gdzie cała aplikacja budowana jest z komponentów, tak zwanych historyjek użytkownika. Do napisania testów automatycznych

w Cucumber wykorzystuje się specjalny język Gherkin [7].

Obecnie Gherkin obsługuje ponad 60 języków naturalnych, w tym język polski. Gherkin rozwiązuje od razu dwa zadaniaŚ tworzenia dokumentacji technicznej projektu i oczywi cie tworzenia testów zautomatyzowanych. Jak każdy język, posiada swoją składnię oraz strukturę, a opisuje się za pomocą już wspomnianych pewnych słów kluczowych. Mimo tego, że opcja pisania historyjek użytkownika w języku

polskim jest dobrze opracowana oraz może się okazać bardzo przydatną i komfortową w oddzielnych przypadkach, to ze

względu na uniwersalno ć języka angielskiego oraz jego wykorzystanie w dokumentacjach technicznych, zaleca się pisać testy szczególnie w języku angielskim.

Słowa kluczowe [7] które wykorzystują się do opisania historyjek użytkownika przedstawione są w tabeli 1.

Tabela 1. Słowa kluczowe w języku Gherkin.

Słowo kluczowe Do czego służy

FEATURE Słowo kluczowe które zawsze rozpoczyna plik testowy (wyjątki które mogą poprzedzać Feature tokomentarze oraz tagi). Opisuje

nazwę przypadku testowego bądź

funkcjonalno ci AS, I WANT, IN

ORDER

Formalnie nie są słowami kluczowymi, stosują

się do opisu dowolnie formowanym. As —

definiuje rolę, I Want — pożądana funkcjonalno ć, In order — rozszerza kontekst

czynno ci w I Want.

SCENARIO Scenariusz przypadku testowego. Kroki które należy wykonać, aby przetestować pewną funkcjonalno ć

GIVEN

Założenia początkowe, które przygotowuje scenariusz do wykonania

WHEN Warunek, który wykonuje pewną akcję, na przykład na GUI (graficzny interfejs

użytkownika) THEN Wynik scenariusza. Opisuje kroki

sprawdzające jego prawidłową realizacją

AND Dodatkowe założenia bądź dodatkowe warunki. Najczę ciej używa się do rozszerzenia pewnego słowa kluczowego (Given, When, Then) o kolejne kroki

BUT Rzadko stosuje się w tworzeniu historyjek, służy głównie do dodawania negatywnych komentarzy albo opisuje warunek, który jest przeciwny do założenia

BACKGROUND Pewny warunek, który należy spełnić przed wykonaniem scenariusza

SCENARIO

OUTLINE

Nazwa skomplikowanego scenariusza. Taki

scenariusz w zależno ci od ilo ci danych wykonuje się wielokrotnie

EXAMPLES Zestaw pewnych danych, które po kolei będą używane do następnych iteracji scenariusza

5. Cucumber w praktyce

Niniejszy rozdział opisuje metodę badawcząi proces analizy narzędzia Cucumber pod kątem wykonania testów w

językach Java i Kotlin.

5.1. Plan badań

Plan badań oparty jest na sprawdzeniu funkcjonalno ci oraz konfiguracji Cucumber w językach programowych Java i Kotlin, a także porównaniu czasu trwania wykonania testów,

który jest liczony w sekundach, w obu językach z rodziny

języków obiektowych.Realizacja badań została przeprowadzonana dwóch urządzeniach o różnych parametrach w celu otrzymania wiarygodnych wyników.


93

Pierwszy etap badania polegał na konfiguracji rodowiska wykonawczego oraz podłączeniu niezbędnych do wykonania testów bibliotek.

Kolejnym etapem było stworzenietrzech aplikacji

testowych z szeregiem różnychfunkcjonalno ci oraz

przygotowaniu zestawu testów w Cucumber. Następnie takie testy zostały przeprowadzone, a wyniki w postaci czasu

wykonania testów zapisane.

Trzecim a jednocze nie ostatnim etapem byłoporównanie oraz omówienie otrzymanych wyników.

5.2. Narzędzia i technologie wykorzystane podczas implementacji badania

Java w wersji 10 – o tym języku programowania chyba wiedzą nawet ludzie nie związani z IT. Dany język zorientowany jest obiektowo oraz jest czę cią tak zwanych języków programowania wysokiego poziomu. Obecnym wła cicielem Java jest Oracle Corporation. Język działa na wirtualnej maszynie JVM (z ang. Java Virtual Machine)

JVM w wersji 1.8 – maszyna wirtualna Java to

rodowisko które wykonuje kod bajtowy Javy.

Kotlin w wersji 1.2 – język programowania który powstał w porównaniu do innych języków do ć niedawno, w 2011

roku. Również działa na wirtualnej maszynie Java.

IntelliJ IDEA wersji 2018.2.5 x64 Ultimate – rodowisko programistyczne dla języków opartych na JVM, wła cicielem,

którego jest znany producent oprogramowania JetBrains.

Selenium WebDriver w wersji 3.14.0 – połączenie serwera Selenium z sterownikiem zapewniającym komunikacje z konkretną przeglądarką.

Apache Maven wersji 3.6.0 – narzędzie które automatyzuje budowę projektu.

JUnit w wersji 4.2 - jeden z najczę ciej wykorzystywanych frameworków do przeprowadzenia testów jednostkowych w języku Java.

5.3. Wymagania systemowe i sprzętowe

Do przeprowadzenia analizy wydajno ci pod kątem czasu wykonania testów Cucumber zostały wykorzystane urządzenia o parametrach przedstawionych w tabeli 2.

Tabela 2. Wykorzystane urządzenia do celów badawczych.

Numer

urządzenia1

Model Procesor Pamięć RAM

System

operacyjny

NR1 Lenovo

IdeaPad

Z580

Intel

Core i3-

2350M

6 GB Microsoft

Windows 7

Professional

(x64)

NR2 HP

EliteBook

840 G3

Intel

Core i5-

6300U

16 GB Microsoft

Windows 10

Enterprise

(x64)

5.4. Aplikacje testowe

Na potrzeby analizy zostałyprzygotowane trzy identyczne

aplikacje w językach Java i Kotlin. Kotlin w porównaniu do 1numer jest wykorzystywany w procesie opisu badania

Java powstał do ć niedawno, w 2011 roku, wła nie głownie z tego powodu taki język został wybrany do badania pod

kątem testowania za pomocą narzędzia Cucumber.

Pierwsza aplikacja napisana została w czystym języku programowym bez użycia dodatkowych bibliotek, a jej

funkcjonalno ć polega na zwróceniu sumy kosztów produktu w zależno ci od podanej liczby produktu. Scenariusz

w Cucumber do testowania poprawnego działania danej funkcjonalno ci przedstawiony jest na przykładzie 1.

Przykład 1. Przypadek testowy №1

Feature: Check a product price Scenario Outline: Check price of milk Given the price of the "milk" is 2 polish złoty When the system checks<count> of the "milk"

Then the price should be <bill>polishzłotych And coś jeszcze, co możemy sprawdzić Examples: | count | bill | | 1 | 2 | | 2 | 4 | | 5 | 3 |

Działanie drugiej aplikacji polega na wyszukiwaniu

pewnej informacji w Internecie oraz wy wietlaniu wyniku wyszukiwania w przeglądarce internetowej. Do realizacji

wszystkich czynno ci oprócz samego języka programowaniazostały użyte również biblioteki JUnit oraz

Selenium. Logika scenariusza Cucumber dla konkretnego

przypadku opisana jest na przykładzie 2.

Przykład 2. Przypadek testowy №2

Feature: Google searching As an user, I want to search some information in Google, So that I can find new interesting things. Scenario: Google searching information about Lublin University of Technology Given a chrome browser is on the Google page When a userenteredphrase "Lublin University of Technology" Then areshownresults for "Lublin University of Technology"

Logika przypadku testowego w trzeciej aplikacjipolega na

przetestowaniu formularza do autoryzacji użytkownika w pewnym systemie. Po podaniu przez użytkownika poprawnego loginu i hasła strona z autoryzacją musi

przekierować go na stronę główną, a w przeciwnym przypadku na stronę z możliwo cią odzyskania hasła. W porównaniu do poprzedniej aplikacjido testów zostały

dodane również pliki html. Odpowiedni scenariusz dla testów Cucumber został opisany w przykładzie 3. Przykład 3. Przypadek testowy №3

Feature: Login to a web page @single Scenario: Successful Login Given I open chrome browser When I on the login.html page And I type my username as Illia and password as 12345 And I click on Sign in button Then I suppose to see greetings for Illia @multiple Scenario Outline: Successful Login Given I open chrome browser When I on the login.html page And I type my username "<username>" and password "<password>" And I click on Sign in button


94

Then I suppose to see greetings for "<name>"

Examples: | username | password | name | | name1 | pass1 | name1 | | name2 | pass2 | name1 | @reset_multiple Scenario Outline: Unsuccessful Login Given I open chrome browser When I on the login.html page And I type my username "<username>" and password "<password>" And I try to Sign in And My password is incorrect and I forgot my correct password Then I redirected on the reset.html Examples: | username | password |

| name1 | pass1 | | name2 | pass2 |

5.5. Wyniki badania

Niniejszy rozdział koncentruje się na porównaniu czasu wykonania testów w oparciu o Cucumber, aby wyja nić,

z którym językiem programowania z rodziny JVM narzędzie może opracowywać testy bardziej wydajnie pod kątem czasu wykonania testu.

Badanie polegało na uruchomieniu każdego przypadku

testowego 5 razy w Java i Kotlin na dwóch urządzeniach NR1 i NR2, wyniki testów są przedstawione w sekundach na

tabelach3 i 4.

Tabela 3. Dane otrzymane na urządzeniu NR1.

Przypadek testowy Czas

wykonania

testu w Kotlin

w sekundach

Czas

wykonania

testu w Java

w sekundach

№1 0,182 0,215

0,193 0,198

0,194 0,219

0,169 0,182

0,212 0,216

redni czas wykonania testu

0,19


0,206

№2 (JUnit, Selenium) 11,274 9,211

12,602 9,272

11,656 8,962

9,795 8,932

10,371 8,876

redni czas

wykonania testu

11,1396


9,0506

№3 (JUnit, Selenium,

obsługa plików HTML) 21,254 21,88

22,338 20,704

23,215 19,924

21,405 19,802

22,112 20,103


22,0648


20,4826

Tabela4. Dane otrzymane na urządzeniu NR2.

Przypadek testowy Czas

wykonania

testu w Kotlin

w sekundach

Czas

wykonania

testu w Java

w sekundach

№1 0,282 0,337

0,316 0,323

0,277 0,287

0,288 0,262

0,303 0,306


0,2932


0,303

№2 (JUnit, Selenium) 11,411 8,227

8,77 8,359

10,062 8,28

8,813 10,11

9,131 8,205


9,6374


8,6362

№3 (JUnit, Selenium,

obsługa plików HTML)

23,044 23,981

24,651 22,666

24,323 22,902

22,957 23,48

22,813 22,123


23,5576


23,0304

Rys. 1. redni czas wykonania testów na NR1.

Rys. 2. redni czas wykonania testów na NR2.

Pomimo różnego czasu wykonania konkretnego testu na

urządzeniach, wynik pod kątem zwycięstwa jest dokładnie ten


95

sam. W przypadku testowym №1 na obu urządzeniach Kotlin

prędzej wykonuje swoje zadanie. Ciekawym faktem jest to, że urządzenie o znacznie słabszych parametrach, ale z

systemem operacyjnym Windows 7 szybciej opracowało pierwszy oraz trzeci przypadek testowy. Ciekawie czy to jest

kwestia systemu operacyjnego?! W kolejnych przypadkach

testowych №2 oraz №3 Java się okazała szybszą od Kotlin.

6. Wnioski

Podsumowując wyniki eksperymentuz rozdziału 6 można przypuszczać, że Kotlin prędzej opracowuje testy Cucumber w aplikacjach, gdy nie potrzebują one dodatkowych bibliotek

do swojego działania, odpowiednio Java jest bardziej

zoptymalizowanym narzędziem, jeżeli chodzi o współpracę z innymi bibliotekami, więc kwestia wyboru konkretnego języku do napisania wydajniejszych testów w Cucumber pod kątem czasu wykonania testów to kwestia konkretnego przypadku testowego.

Nawiązując dohipotezy badawczejnależy podsumować, iż

jednak istnieje różnica w czasie wykonania testów w obu

językach, nawet zwracającuwagę na faktdziałania w obrębietej samej maszyny wirtualnej Java, a więc hipoteza badawcza nie

została potwierdzona.

W artykule przedstawiono analizę zastosowania narzędzia Cucumber w testowaniu aplikacji.Dużym plusem narzędzia jest zrozumiały język testów nawet dla osób nietechnicznych,

łatwa integracja z biblioteką JUnit, Selenium, a także obsługa

wyrażeń regularnych oraz możliwo ć uruchamiania jednego testu z różnymi zestawami danych.

Literatura

[1] Chelimsky, David, et al. The RSpec Book: Behaviour-Driven

Development with

[2] Full-scale Software Engineering / Current Trends in Release

Engineering, Faculty of Mathematics, Computer Science, and

Natural Sciences, Research Group Software Construction,

2016.

[3] Semi-automatic Test Case Generation, Olav Undheim,

Norwegian University of Science and Technology Department

of Computer and Information Science, 2011. [4] Dokumentacja Cucumber, https://cucumber.io/ [21.10.2018] [5] Ian Dees, Matt Wynne, Aslak Hellesoy, Cucumber Recipes,

2013.

[6] Seb Rose, Matt Wynne, Aslak Hellesøy, The Cucumber for Java Book, 2015.

[7] Matt Wynne, Aslak Hellesøy, Steve Tooke, The Cucumber Book, Second Edition, 2017.

[8] Gáspár Nagy, Seb Rose, The BDD Books – Discovery, 2017.

[9] Daniel J. Mosley, Bruce A. PoseyJust, Enough Software Test

Automation, 2002.

[10] Dr. Winston W. Rovce , „Managing the Development of Large Software Systems”, 1970

[11] Paweł Marek, „Weryfikacja i automatyzacja procesu testowania

oprogramowania”, CORE Magazine, 2010.

JCSI 11 (2019) 96-100



96

Wdrożenie aplikacji internetowych wspomagających zarządzanie przedsiębiorstwem na przykładzie wybranej gminy

Mateusz Poniatowski*, Elżbieta Miłosz


Streszczenie. W artykule opisano wdrażanie aplikacji internetowych wspomagających zarządzanie przedsiębiorstwem, w oparciu o wdrożenia w poszczególnych biurach podróży. Przedstawiono różne typy aplikacji internetowych z analizą zalet i wad ich użycia. W analizie zastosowano

metodę sondażu diagnostycznego. Wyniki badań wykazały, że najpopularniejszą aplikacją stosowaną przez biura podróży jest CRM. Przedsiębiorstwa wykazały, że aplikacje były wdrożone bez opóźnień, a główną korzy cią ich posiadania jest wzrost sprzedaży.

Słowa kluczowe: wdrożenieś zarządzanieś aplikacje internetowe



Implementation of web applications supporting business management basing

on companies in chosen geographic area

Mateusz Poniatowski*, Elżbieta Miłosz Institute of Computer Science, Lublin University of Technology, Nadbystrzycka 36B, 20-618 Lublin, Poland

Abstract. The article describes implementation of internet applications supporting business management, basing on implementations in

particular travel agencies. Various web application types of were presented, with the analysis of pros and cons of their usage. Diagnostic survey

method was used in the analysis. Results of research have shown, that most popular web application used by travel agencies is CRM.

Companies from travel business line proved efficiency of this tool, by increase of sales performance.

Keywords: implementation; management; web applications



1. Wstęp

Ważnym aspektem pracy każdego przedsiębiorstwa jest proces jego zarządzania oraz odpowiednie wykorzystywanie technologii informatycznych takich jak aplikacje internetowe.

Wyzwaniem dla każdej firmy jest nadanie jej indywidualnego charakteru. Może w tym pomóc stworzenie dedykowanej aplikacji internetowej. Warto więc zbadać proces wdrożenia tych aplikacji, dowiedzieć się jakie technologie są najbardziej popularne, jakie mają obawy przedsiębiorstwa związane z wdrożeniem aplikacji internetowych oraz jakie odnoszą korzy ci.

2. Aplikacje internetowe w zarządzaniu przedsiębiorstwem

Do zarządzania współczesnym przedsiębiorstwem wymagane jest wykorzystywanie odpowiednich rozwiązań IT. W ostatnich latach znacząco zwiększyła się rola systemów informatycznych w przedsiębiorstwach. Automatyzacja, optymalizacja procesów, wspomaganie w podejmowaniu decyzji oraz poprawa relacji z klientami to główne czynniki wpływające na wzrost popularno ci wszelakich rozwiązań IT w biznesie. Aplikacja internetowa, często nazywana aplikacją webową, to program komputerowy, który do realizacji

funkcjonalno ci wymaga koniecznie dostępu do sieci Internet

[6]. Interfejs takiej aplikacji dostępny jest za pomocą przeglądarki internetowej. Ponadto to także rozwiązania, któreŚ

wykorzystują języki programowania wspierane przez przeglądarki np.: HTML, JavaScript,

posiadają architekturę klient-serwer,

komunikują się za pomocą protokołu HTTP(S).

Działanie aplikacji internetowej wymaga serwera WWW, także serwera aplikacji w celu wykonywania żądań oraz bazy danych do przechowywania informacji. Działanie aplikacji

internetowej można opisać według następujących etapówŚ

1) Uruchomienie żądania do serwera internetowego przez

użytkownika za po rednictwem przeglądarki internetowej.

2) Serwer WWW przekazuje żądanie do konkretnego serwera aplikacji.

3) Serwer aplikacji wykonuje żądanie np. zapytanie do bazy

danych.

4) Serwer sieciowy odpowiada już klientowi, któremu w przeglądarce ukazują się żądane informacje.

Aplikacje internetowe pomagają przedsiębiorstwom zająć na rynku odpowiednią pozycję, co sprawia, że cały czas


97

najczę ciej wykorzystywane są do prowadzenia działalno ci systemy ERP i CRM. Dzieje się tak, ponieważ służą one do optymalizowania i zarządzania procesami zachodzącymi w przedsiębiorstwie. Zarówno pierwszy jak i drugi system

rozpowszechnia informacje w całym przedsiębiorstwie, jednak ERP bardziej jest skupiony na wszystkich procesach

przedsiębiorstwa, a CRM tylko na procesach związanych z relacjami z klientami [6].

Wiele dostępnych źródeł [1,2,3] podaje, że system ERP

jest to narzędzie informatyczne, które usprawnia zarządzanie przedsiębiorstwem, gdyż obejmuje wszystkie działy danej firmy. To sprawia, że system taki pozawala bardziej efektywnie zarządzać przedsiębiorstwem, gdyż w każdej chwili możliwy jest podgląd do niezbędnych informacji, które można na bieżąco w szybki sposób analizować. Ułatwia to planowanie przyszłych działań, gdyż bieżące są w pełni kontrolowane. W ród zalet można wymienić jeszcze przyspieszoną obsługę klienta oraz skrócenie czasu oczekiwania na realizację np. danego zamówienia, czy wykonania obsługi serwisowej.

Natomiast system CRM to system do zarządzania relacjami z klientami poprzez zespół różnych czynno ci, działań, elementów potrzebnych do zarządzania tymi relacjami. Kluczem do sukcesu prawidłowego funkcjonowania firmy jest posiadanie odpowiednio zasobnej grupy klientów, którzy generują zyski. Ten argument sprawia, że klienci zasługują na udogodnienia w postaci funkcjonalnych

systemów IT. Do stworzenia podstawowej bazy informacji

o klientach i nadania jednolitego obrazu firmy wykorzystuje

się różne strategie CRM.

3. Wybrane problemy wdrożeń systemów informatycznych

W dzisiejszych czasach wdrożenie systemów IT nie jest takie proste jak było to jeszcze niedawno. Powstają coraz to nowe narzędzia technologiczne, a metodyki i sam proces

wdrażania również się zmieniają.

Wdrożenie aplikacji internetowych to proces, który żeby zrozumieć należałoby poznać wszystkie etapy związane z projektem informatycznym (od czasu powstania pomysłu na daną aplikację do momentu udostępnienia oraz jej eksploatacji przez użytkowników). Jednak przede wszystkim wdrożenie systemu wiąże się z wyborem pewnej metodyki takiego

wdrożenia już na etapie tworzenia oprogramowania. Przy

wdrażaniu systemów informatycznych (bez względu na wybraną metodykę) na etapie planowania nie można zapomnieć o dokumentacji i spisaniu wymagań funkcjonalnych, niefunkcjonalnych oraz diagramach np. UML

[5]. Najbardziej popularne typy modeli to: kaskadowe,

spiralne, przyrostowe, RUP i zwinne. Wadą podej cia

kaskadowego jest to, że nie można przej ć do kolejnych

etapów bez zakończenia poprzednich, czyli brak elastyczno ci. Ponadto metodyka ta jest prawie niemożliwa w dzisiejszych

czasach do zastosowania, ze względu na złożono ć projektów oraz brak precyzyjnie sformułowanych wymagań ze strony klienta. Dodatkowo programi ci nie są w stanie przewidzieć problemów technicznych związanych z implementacją

projektu, co może wpłynąć na wydłużenie czasu oddania

projektu. Metodyka ta potrafi generować ogromne koszty dla

przedsiębiorców. Zaletą wykorzystania tego podej cia jest stworzenie bardzo czytelnej, dokładnej dokumentacji.

Drugi omawiany model to model spiralny, który został zdefiniowany przez Barry'ego Boehm'a. Cały proces przypomina spiralę, ze względu, że każda kolejna pętla ukazuje następne fazy procesu wdrażania. Ten model metodyki daje korzy ci związane z dużą niezawodno cią, a także szansą, że projekt będzie zrealizowany. Sposób ten jest odpowiedni dla dużych projektów informatycznych. Wadą tego podej cia jest to, że wymaga bardzo do wiadczonych ekspertów w dziedzinie analizy ryzyka zarówno w dziedzinie IT jak i w biznesie. Kolejny omawiany

model to model przyrostowy. Najważniejszą cechą tego modelu jest to, że funkcjonalno ci aplikacji są dzielone na

porcje. W iteracjach te porcje funkcjonalno ci są dostarczane w różnych dziedzinach (np. wymagania, implementacja) [5].

Najczę ciej wykorzystywaną metodyką zwinną jest Scrum, a wdrożenie aplikacji internetowej przy wykorzystywaniu tej metodyki składałoby się zŚ

etapu przygotowań, etapu wdrożenia.

Etap przygotowań to proces, na który składa się głównie analiza potrzeb klienta przez dostawcę. Gdy już są okre lone potrzeby, wykonawca wycenia funkcjonalno ci, a klient

ustala listę priorytetów. Dodatkowo na tym etapie powinien

być ustalony budżet projektu oraz wła ciciel produktu.

Następnym etapem jest wdrożenie. W Scrumie, wdrożenie jest podzielone na kolejne etapy, czyli Sprinty, które mogą trwać od jednego do nawet kilku tygodni. Najważniejszą zasadą jest, aby Sprint zawsze był o stałej długo ci. Sprint złożony jest z etapu planowania, w którym programi ci dostają od wła ciciela produktu listę wymagań, jakie mają zostać zrealizowane. Kolejnym etapem jest praca

programistyczna, w której programi ci implementują spisane

wcze niej wymagania. W tym etapie osoba lub osoby

reprezentujące przedsiębiorstwo nie mogą zmieniać celów planowanego przyrostu. Ostatnie dwa etapy to:

etap oddania, w którym wykonawca pokazuje klientowi efekt swojej pracy,

etap podsumowania, w którym zarówno klient jak i dostawca aplikacji podsumowują ostatni Sprint.

Po tych etapach następuje kolejne planowanie i praca nad

kolejnym Sprintem [7].

Podczas wdrażania sytemu klasy ERP czy CRM do

uzyskania zakładanej potrzeba czasu, sięgającego nawet kilku

miesięcy. Oczywi cie wiążą się z tym także koszty, ale przy wła ciwym wdrożeniu systemu opłacalno ć będzie większa niż poniesione straty czasowe i finansowe. Przed

rozpoczęciem dokonania takich zmian w firmie, należy przeprowadzić wstępną analizę i zadać sobie kilka pytań. Przede wszystkim, czy przedsiębiorstwo dysponuje odpowiednim budżetem, jaki stopień wykwalifikowania posiadają pracownicy, ponieważ konsultacja ze specjalistą

i nawiązanie z nim współpracy generuje kolejne wydatki. Do


98

wdrożenia systemu CRM potrzebna jest wiedza i wysiłek. Ustalenie polityki stosowanej z partnerami czy dostawcami

będzie ważyło o dalszym postępowaniu. Trzeba również zmienić podej cie do klienta, który ma stać w centrum i to jego potrzeby będą priorytetami w działaniu

i funkcjonowaniu biznesu. Wdrażanie nowego systemu wiąże się z systematyczno cią i konieczno cią przestrzegania

zaplanowanych terminów i zadań. Istnieje niebezpieczeństwo,

że sukces nie zostanie odniesiony wbrew założeniom, zwłaszcza w przypadku podejmowaniu niekorzystnych

działań. Nie można podejmować decyzji o wprowadzeniu zmian bez wcze niejszego przemy lenia i kalkulacji. Potrzebne jest odpowiednie przygotowanie odpowiednich

procesów, aby wdrożenie systemu informatycznego nie okazało się bezwarto ciowe. Kolejnym błędem może być wykorzystanie gotowego pakietu, a skutkiem takiego wyboru

może stać się brak połączenia z bazą danych lub przymusowe wprowadzanie informacji. To natomiast wiąże się z wydłużeniem czasu. Należy pamiętać, że każde zmiany i działania wprowadzane w trakcie ulepszania nowego systemu w firmie powinny być spisywane, a wszelkie dokumenty przechowywane [7].

Decydując się na wdrożenie systemu informatycznego

należy przekalkulować opłacalno ć i efektywno ć. Wyrażenie efektywno ci systemu informatycznego można przedstawić za pomocą zależno ci między całkowitymi nakładami, takimi jak: koszty systemu, koszty adaptacji i eksploatacji koszty

sprzętu IT, koszty szkoleń, koszty czasu pracy pracowników biorących udział we wdrożeniu systemów informatycznych a efektami, jakie wynikają z wdrożenia oraz eksploatacji (korzy ci materialne i niematerialne).

Ogólna cieżka etapów wdrożenia systemu może być przedstawiona w następującej kolejno ci [3]:

założenie zespołu projektowo-analitycznego,

analiza potrzeb,

okre lenie funkcjonalno ci systemu,

wybór rozwiązania,

przeprowadzenie wdrożenia systemu.

Trzeba pamiętać, że nie ma jednolitego schematu, ani metody uniwersalnej, która każdej firmie zapewni sukces. Trzeba także być przygotowanym, że wdrożenie może trwać nawet kilkana cie miesięcy i tego czasu niestety nie da się skrócić. Jednym z warunków, żeby uznać, że wdrożenie odbyło się prawidłowo jest sprawdzenie dokumentacji,

w skład której powinna wchodzić dokumentacja dla użytkowników oraz dla administratora. Efektami wdrożenia systemów IT sąŚ

wzrost wydajno ci pracy,

zwiększone bezpieczeństwo danych w przedsiębiorstwie,

lepszy, szybszy dostęp do danych biznesowych,

poprawa kontaktu z klientem,

przyspieszenie procesów np. decyzyjnych, biznesowych, sprzedażowych [7].

4. Założenia i przebieg badań

Większo ć przedsiębiorstw działających na terenie gminy

Lublin ma dostęp do aplikacji internetowych. Są to aplikacje

różnego typu, dlatego też celem badań było zbadanie procesu wdrożenia, a co się z tym wiąże, także oczekiwanych korzy ci, spodziewanych obaw oraz zweryfikowanie, który rodzaj aplikacji internetowych jest najczę ciej wykorzystywany w ród biur podroży prowadzących działalno ć na terenie gminy Lublin. Dla realizacji celu

postawiono następujące pytania badawczeŚ

1. Jaki typ aplikacji internetowych jest najczę ciej wykorzystywany przez przedsiębiorstwa?

2. Jaki język programowania jest najczę ciej wykorzystywany do implementacji aplikacji

internetowych?

3. Jaka była główna obawa przedsiębiorstw, związana z wdrożeniem aplikacji internetowej w okresie planowania wdrożenia?

4. Jaka jest główna zaleta wdrożenia aplikacji internetowej wspomagającej zarządzanie przedsiębiorstwem?

5. Jaki był najczęstszy problem przedsiębiorstw, związany z aplikacją internetową wspomagającą zarządzanie po wdrożeniu?

6. Czy w przedsiębiorstwach, które wdrożyły aplikacje

internetowe czas wdrożenia na etapie planowania był odpowiednio oszacowany?

Postawione pytania badawcze pozwoliły sformułować następujące hipotezy badawczeŚ

H1: Zdecydowana większo ć przedsiębiorstw wykorzystuje aplikacje internetowe, które opierają się na systemie CRM.

H2: Najbardziej popularny język programowania wykorzystywany do implementacji aplikacji internetowych

wspomagających zarządzanie przedsiębiorstwem to PHP. H3: Główną obawą przedsiębiorstw w okresie planowania wdrożenia aplikacji internetowej jest kwestia związana z bezpieczeństwem danych. H4: Największą korzy cią wdrożenia aplikacji jest przyspieszenie procesów biznesowych. H5: Głównym problemem przedsiębiorstw związanym

z wdrożeniem aplikacji internetowej jest wolne działanie aplikacji uzależnione od parametrów posiadanego łącza internetowego.

H6: Czas wdrożenia aplikacji internetowych okazał się być

dłuższy niż planowano.

Realizacja badań odbyła się metodą sondażu diagnostycznego z wykorzystaniem ankiety internetowej,

a więc techniką CAWI (Computer-assisted Web Interview).

Próbę badawczą stanowiły biura turystyczne w mie cie Lublin. Ankieta była przeprowadzona na przełomie listopada i grudnia 2018 roku. Adres, pod którym była ona dostępna został przesłany drogą elektroniczną na adresy e-mail 15 biur

turystycznych zarejestrowanych na terenie gminy Lublin.

Jednak ze względu na małe zainteresowanie, badania odbyły się przy obecno ci ankietera w siedzibach biur turystycznych. Końcowo ankietę wypełniło 30 pracowników z przedsiębiorstw takich jakŚ Koliber,Continental-Travel,

Astur, Gala-Travel, Sass, Coral-Tour, Happy Tour.

5. Wyniki badań i ich analiza

Zebrane dane uzyskano od pracowników biur turystycznych. Poprzez analizę zebranych danych, można


99

stwierdzić, że biura turystyczne w gminie Lublin zdają sobie sprawę, że w dzisiejszych czasach aplikacja internetowa jest niezbędna do zdobycia i podtrzymywania pozycji na rynku.

wiadczą o tym wyniki ankiety, w których 100% badanych przedsiębiorstw wykazuje, że posiada różnego rodzaju aplikacje internetowe.

W zdecydowanej większo ci, bo aż w 67% badanych biur turystycznych, dominuje system CRM jako aplikacja

internetowa wspomagająca zarządzanie. Dużą popularno cią cieszą się również aplikacje ogłoszeniowe - 23%

respondentów korzysta z tego typu aplikacji (Rys.1).

Rys. 1. Rodzaj aplikacji wdrożonych w przedsiębiorstwach

W przedstawionym poniżej wykresie (Rys.2), ukazane

zostały odpowiedzi respondentów, w których wskazują oni po

trzy główne korzy ci wdrożenia aplikacji internetowych. Najczęstsze odpowiedzi toŚ

jest to wzrost sprzedaży, zwiększenie konkurencyjno ci firmy, lepszy kontakt z klientem,

większa możliwo ć rozwoju firmy.

Rys. 2. Korzy ci wynikające z wdrożenia aplikacji internetowych

Kolejne pytanie dotyczyło obaw związanych z wdrożeniem aplikacji internetowych, które pojawiały się na etapie planowania. Przy tym pytaniu respondenci podzielili

się na dwie grupy badanych. Pierwsza to grupa, która miała obawy, druga to ta, która nie odczuwała żadnych obaw w związku z wdrożeniem. 37% ankietowanych wskazało, że najbardziej obawiają się awarii aplikacji. Drugą najczę ciej wskazywaną obawą był brak do wiadczenia pracowników. Natomiast 50 % wszystkich respondentów wcale nie miało obaw związanych z wdrożeniem aplikacji internetowej (Rys.3).

Kolejne pytanie ankiety miało za zadanie zbadać, jaki jest

najczęstszy problem korzystania z aplikacji internetowych już po etapie wdrożenia. 74% respondentów wskazało, że głównym problemem jest wolne działanie aplikacji. Kolejnym problemem okazuje się być również niewystarczający zakres szkolenia z obsługi działania aplikacji dla pracowników (Rys.4.).

Ostatnie pytanie dotyczyło weryfikacji oszacowanego

czasu wdrożenia aplikacji z etapu planowania. 63% badanych

wykazało, że czas wdrożenia był odpowiedni, zgodny z tym czasem, który zaplanowano. Tylko 17% ankietowanych odpowiedziało, że system wdrożono z opóźnieniem.


100

Rys. 3. Obawy wynikające z wdrożenia aplikacji

Rys. 4. Najbardziej istotne problemy, po wdrożeniu aplikacji

6. Wnioski

Analiza badań wykazała, że wszystkie biura turystyczne mają wiadomo ć konieczno ci posiadania aplikacji internetowej. Każde badane przedsiębiorstwo posiada aplikację internetową, z której aktywnie korzysta. W pracy zostało postawionych sze ć hipotez, z czego trzy zostały potwierdzone.

Pierwsza hipotezy, która zakładała, że w większo ci przedsiębiorstw związanych z turystką zarejestrowanych na terenie gminy Lublin wykorzystuje się aplikacje internetowe,

głównie w postaci systemów CRM, została potwierdzona.

Druga hipoteza, która zakładała, że najbardziej

wykorzystywanym językiem programowania służącym do implementacji aplikacji internetowych wspomagających zarządzanie przedsiębiorstwem na przykładzie biur podróży jest PHP, została potwierdzona.

Trzecia hipoteza, która zakładała, że główną obawą przedsiębiorstw w okresie planowania wdrożenia aplikacji internetowej była kwestia związana z bezpieczeństwem danych, została obalona. Z odpowiedzi ankietowanych

wynika, że ponad 50% respondentów nie miało wcale obaw związanych z wdrożeniem aplikacji. Natomiast 37% ankietowanych wykazało, że największą obawą są ewentualne awarie aplikacji.

Czwarta hipoteza, która zakładała, że największą korzy cią wdrożenia aplikacji jest przyspieszenie procesów biznesowych, została obalona. 70% respondentów wykazało, że największą korzy cią aplikacji internetowej jest wzrost sprzedaży.

Piąta hipoteza, która zakładała, że głównym problemem

przedsiębiorstw związanym z aplikacją internetową są utrudnienia związane z prawidłowym działaniem aplikacji ze względu na prędko ć posiadanego łącza internetowego,

została potwierdzona. 74% respondentów wykazało, że po wdrożeniu aplikacji to był najczę ciej występujący problem.

Szósta hipoteza, która zakładała, że czas wdrożenia aplikacji internetowych okazał się być dłuższy niż planowano, została obalona. 63 % respondentów wykazało, że czas wdrożenia był odpowiednio oszacowany na etapie

planowania.

7. Literatura

[1] Adamczewski P., Zintegrowane systemy informatyczne

w praktyce, Warszawa 2003.

[2] Beynon-Davies, P. Inżynieria systemów informacyjnych. Warszawa: WNT, 1999.

[3] Chmielarz W. 1996. Systemy informatyczne wspomagające zarządzanie. Aspekt modelowy w budowie systemów. Warszawa: Wyd. Dom Wydawniczy Elipsa: 36.

[4] Dziembek D.Ś Rozwiązania Cloud Computing we wspomaganiu strategii kodyfikacji wiedzy w organizacji wirtualnej, Pr. Nauk.

UE Wroc. nr 212, Inform. Ekon. nr 22,Wrocław 2011. [5] Grudzewski W., Metody projektowania systemów zarządzania.

Difin, Warszawa, 2004.

[6] Januszewski A., Funkcjonalno ć informatycznych systemów zarządzania, Warszawa 2008.

[7] Zalewski W., Analiza systemów informatycznych wspomagających zarządzanie produkcją w wybranych przedsiębiorstwach. Economy and Management – 4/2011.

JCSI 11 (2019) 101-105

Wysłane: 2018-12-01


101

Porównanie wydajności algorytmów szyfrowania na platformie iOS

Jakub Tudruj*, Piotr Kopniak


Streszczenie. Niniejszy artykuł dotyczy porównania wydajności algorytmów szyfrowania używanych na mobilnej platformie iOS. Skupiono

się na analizie algorytmów kryptografii symetrycznej i asymetrycznej oraz przetestowano, ile czasu zajmują im operacje szyfrowania

i generowania klucza. Badania przeprowadzono na różnych urządzeniach działających na najwyższej wspieranej wersji systemu operacyjnego.

Słowa kluczowe: algorytmy szyfrujące; system iOS; wydajność szyfrowania



Comparison of encryption algorithms performance on iOS platform

Jakub Tudruj,*, Piotr Kopniak

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

Abstract.The subject of this article is to compare iOS mobile operation system encryption algorithms performance. The main target is to

analyze symmetrical and asymmetrical algorithms, test them how much time encryptionand key generation operations take. Tests were carried

out on various devices with the same version of operating system.

Keywords: encryption algorithms; iOS system; encryption performance



1. Wstęp

Coraz większa popularność smartfonów i tabletów oraz ich wykorzystanie w codziennym życiu sprawia,

że producenci oprogramowania coraz częściej wprowadzają na rynek mobilne wersje swoich aplikacji. Przekłada się to na zwiększającą sięliczba programów dostępnych w sklepach Google Play oraz App Store. Rzutuje

to bezpośrednio na coraz większą liczbę danych

przetwarzanych, przesyłanych oraz przetrzymywanych na urządzeniach mobilnych.

Na co dzień wielu użytkowników smartfonów przetwarza wrażliwe dane, takie jak wiadomości, zdjęcia, dane lokalizacyjne, nagrania rozmów, notatki, informacje o swoim stanie zdrowia czy dostępy do kont społecznościowych lub bankowości internetowej. Może to rokować na duże zainteresowanie takimi informacjami przez potencjalnych

hakerów lub przypadkowe osoby mogące uzyskać dostęp do skradzionego lub zagubionego urządzenia mobilnego. Wyciek tych danych może być niezwykle bolesny ze względu na możliwość wykorzystania ich do oczernienia ich właściciela, pozyskania informacji o jego rodzinie, kradzieży własności intelektualnej czy utraty środków na koncie.

Fakty te sprawiają, że zarówno użytkownicy smartfonów jak i programiści powinni zwracać uwagę na bezpieczeństwo

informacji użytkowników. Jednym ze sposobów na zabezpieczenie wrażliwych treści jest użycie szyfrowania.

Niniejszy artykuł ma za zadanie porównać wydajności algorytmów szyfrowania symetrycznego i asymetrycznego

oraz czasu na generowanie klucza kryptograficznego. Dane

te mogą być niezwykle przydatne dla twórców oprogramowania. Dzięki nim możliwe będzie wprowadzenie odpowiedniego kompromisu pomiędzy siłą zabezpieczeń a wydajnością aplikacji mobilnej.

2. Cel i przedmiot badań

Przedmiotem badań byłaanaliza porównawcza szybkości generowania kluczy kryptograficznych oraz

szyfrowaniadanych.

Celem badań była próba potwierdzenia tezy: Czas

szyfrowania tych samych danych za pomocą tych samych algorytmów szyfrujących opartych o te same klucze kryptograficzne oraz generowanie tych samych kluczy

kryptograficznych zajmuje mniej czasu na nowszym

urządzeniu.

Kolejnym celem badań była próba potwierdzenia hipotez:

1) Zastosowanie klucza kryptograficznego o większej długości zwiększa czas szyfrowania tych samych danych,

2) Czas wygenerowania klucza kryptograficznego lub pary

kluczy kryptograficznych wzrasta proporcjonalnie

do zwiększenia się długości generowanego klucza lub pary kluczy.


102 102

3. Opis metodologii badań i narzędzi

W celu przeprowadzenia badania i uzyskania wyników czasowych działania poszczególnych algorytmów szyfrujących wykorzystano zestaw narzędzi deweloperskich dostarczanych przez firmę Apple. Kod aplikacji służącej dokonaniu pomiarów został napisany w języku Swift przy pomocy środowiska programistycznego Xcode. Badanie

zostało przeprowadzone czterokrotnie na każdym z urządzeń w celu zminimalizowania błędu pomiarowego spowodowanego procesami uruchomionymi w tle. Następnie wyniki każdego z badań zostały uśrednione.

3.1. Urządzenia testowe

Badanie przeprowadzono z użyciem smartfonów:

iPhone 5,

iPhone 6 Plus,

iPhone 6S,

iPhone X.

Wszystkie urządzenia działają w oparciu o systemem najnowszą wspieraną wersję systemu iOS. W przypadku

iPhone 5 jest to wersja 10.3, natomiast reszta smartfonów posiada zainstalowaną wersję oznaczoną numerem 12.

Ich specyfikacja została wyszczególniona w Tabeli 1.

Tabela 1. Specyfikacja urządzeń testowych [5]

Model urządzenia Procesor Pamięć RAM

iPhone 5 Apple A6 1.3 GH, 2 rdzenie 1 GB

iPhone 6 Plus Apple A8 1.4 GHz, 2 rdzenie 1 GB

iPhone 6S Apple A9 1.85 GHz, 2 rdzenie 2 GB

iPhone X Apple A11 Bionic

2.39 GHz, 6 rdzeni

3 GB

3.2. Testowane algorytmy

Do przeprowadzenia badania wybrano

dwa najpopularniejsze algorytmy kryptografii asymetrycznej:

RSA oraz ECC. Poniżej przedstawiono badane długości kluczy.

1) RSA:

1024 bity

2048 bitów

4096 bitów

8192 bity,

15130 bitów,

2) ECC:

160 bitów, 224 bity,


512 bitów.

Zbadano również symetryczny algorytm AES używając następujących długości klucza:


256 bitów.

Z powodu ograniczenia wielkości danych możliwych do zaszyfrowania za pomocą algorytmów asymetrycznych,

w pierwszej części badań skupiono się na sprawdzeniu

wydajności szyfrowania klucza AES o długości 128 bitów. Druga część badań polegała na zaszyfrowaniu dużej ilości danych za pomocą klucza AES. Przetestowano szyfrowanie krótkiego tekstu o długości 32 znaków, długiego tekstu składającego się z 10093 znaków oraz dwóch plików graficznych. Mniejsza z grafik miała rozmiar 22 KB, natomiast większa 1,8 MB.

Poniżej (Tabela 2) przedstawiono porównanie bezpieczeństwa w zależności od długości klucza algorytmów ECC oraz RSA [3] [4].

Tabela 2. Porównanie bezpieczeństwa RSA oraz ECC w zależności od długości klucza[3] [4]

Algorytm

Symetryczny RSA ECC

SKIPJACK 80 bitów 1024 bity 160 bitów

3DES 112 bitów 2048 bitów 224 bity

AES 128 bitów 3072 bity 256 bitów

AES 192 bity 8192 bity 384 bity

AES 256 bitów 1530 bitów 512 bitów

3.3. Opis aplikacji testowej

Aplikacja testowa została napisana w języku Swift w wersji 4.2 przy użyciu środowiska programistycznego Xcode 10. Dostęp do funkcji umożliwiających generowanie kluczy oraz szyfrowanie uzyskano dzięki wykorzystaniu

biblioteki CommonCrypto dostarczanej przez firmę Apple.

Poniżej (Rysunek 1) przedstawiono zrzut ekranu aplikacji

uruchomionej na urządzeniu iPhone X.

Rys. 1. Urządzenia testowe podczas przeprowadzania badania


103 103

Aplikacja umożliwia podgląd na żywo wyników poszczególnych etapów badania oraz eksport wszystkich

pomiarów używając formatu danych pliku csv.

Kod aplikacji testowej został umieszczony na publicznym repozytorium w serwisie GitHub pod adresem:

https://github.com/JakubTudruj/encryptionTimeTest.

4. Wyniki badań

Podczas próby przeprowadzania testów okazało się, że biblioteka CommonCrypto nie wspiera tworzenia

kluczy ECC o długości 160 bitów oraz 512 bitów i więcej. W przypadku kluczy RSA maksymalną długością okazała

się para kluczyo długości 8192 bitów. Wynikiem operacji był błąd „OSStatus -50”, który przedstawiono na Przykładzie 1.

Przykład 1. Błąd biblioteki CommonCrypto przy generowaniu pary kluczy o niedozwolonej długości

The operation couldn’t be completed. (OSStatus error -50 - Key generation failed, error -50)

Wyniki badania czasu generowania par kluczy ECC

o długościach 224 bity, 256 bitów oraz 384 bity wykazały, że bez względu na długość klucza czas potrzebny

na jego wygenerowanie jest na tyle krótki (poniżej 142 ms), że z powodzeniem można stosować nawet najdłuższy możliwy klucz na starszych urządzeniach. Użyty do testów iPhone 5 mający jako jedyny procesor 32 bitowy, który jednocześnie charakteryzował się najwolniejszym zegarem,

generował parę kluczy ECC w czasie kolejno: 72, 94 oraz 142

milisekund. Dwukrotnie szybszy w każdym przypadku okazał się jego następca: iPhone 6 Plus. Każde kolejne urządzenie było również dwukrotnie szybsze od swojego poprzednika. Wyniki tej części badania zostały przedstawione na Rysunku 2.

Rys. 2. Wykres przedstawiający czas generowania pary kluczy ECC o różnych długościach na urządzeniach testowych

W kolejnej części badania sprawdzono czas generowania par kluczy RSA o długościach od 1024 bitów do 8192 bitów.

Podobnie jak podczas poprzedniego badania okazało się, że nowsze urządzenia są szybsze od starszych oraz że długość pary kluczy przekłada się na czas potrzebny do ich wygenerowania. Operacja generowania pary kluczy

RSA charakteryzowała się niską wydajnością dla urządzeń mobilnych. Najkrótsza z par kluczy o długości 1024 bitów

na każdym urządzeniu, oprócz iPhone 5, generowała się w czasie krótszym niż sekunda. Każdorazowe zwiększenie długości kluczy skutkowało znacznym wzrostem czasu

potrzebnego do ich wygenerowania. Przekroczenie czasu

3 sekund na najwydajniejszym urządzeniu testowym (iPhone X) dla pary kluczy RSA 2048 jest ostatnią długością klucza, która powinna być akceptowalna w aplikacji mobilnej, aby ta zachowała płynność działania

[2].Najbardziej czasochłonną operacją było generowanie

najdłuższej pary kluczy RSA o długości 8192 bitów. iPhone 5

potrzebował na to aż 1238 sekund (ponad 20 minut). Nawet iPhone X wyróżniający się najszybszym procesorem uzyskał wynik 154 sekund (2,5 minuty). Powyższe dane wskazują, że algorytm RSA jest mało praktyczny w zastosowaniach

mobilnych. Wyniki pomiarów zostały przedstawione poniżej (Rysunek 3).

Rys. 3. Wykres przedstawiający czas generowania pary kluczy RSA o różnych długościach na urządzeniach testowych

Ostatnia część badania w której skupiono się na generowaniu symetrycznego klucza AES wykazała, że podobnie jak w poprzednich przypadkach, czas

generowania kluczy jest tym dłuższy, im dłuższy jest klucz szyfrujący. Większa moc obliczeniowa urządzenia skutkowała skróceniem czasu potrzebnego na wygenerowanie klucza. Nie przekraczał on jednak 340 milisekund. Wyniki tej

części badania zostały przedstawione na Rysunku 4.

72

36

18 9

94

47

24

12

14

2

71

36

18

0

20

40

60

80

100

120

140

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

224 bity itów 384 bity

Cza

s g

en

ero

wa

nia

[m

s]

Długoś klu za ECC

Czas generowania kluczy ECC [ms]

1,3

0,6

0,3

0,2

27

,4

13

,7

6,8

3,4

25

3,7

12

6,9

63

,4

31

,7

1 2

38

,1

61

9,0 3

09

,5

15

4,8

0

200

400

600

800

1000

1200

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

1024 bity itów itów 8192 bity

Cza

s g

en

ero

wa

nia

[s]

Długoś klu za RSA

Czas generowania kluczy RSA [s]


104 104

Rys. 4. Wykres przedstawiający czas generowania symetrycznego klucza AES o różnych długościach na urządzeniach testowych

Po przeprowadzeniu operacji generowania kluczy

kryptograficznych w następnej części zadania sprawdzono w jakim czasie wykonana zostanie operacja szyfrowania

danych. W przypadku zaszyfrowania klucza AES 128 bitów za pomocą symetrycznego klucza publicznego okazało się, że bez względu na zastosowany algorytm oraz jego

długość czas nie przekraczał 1 milisekundy.

Badanie szyfrowania kluczami AES o różnych długościach wykazało, że bez względu na zastosowaną długość klucza operacja zajmowała na tych samych urządzeniach podobną ilość czasu. Znaczenie miała tylko wydajność samego urządzenia testowego. Szyfrowanie długiego oraz krótkiego tekstu wykazało, że potrzebny czas nie przekraczał 1 milisekundy na każdym z urządzeń. Różnice wykazał test szyfrowania większej ilości danych. Szyfrowanie małego obrazka (22KB) nie przekraczało 224

milisekund. Co ciekawe, badanie wykazało, że najszybciej operacja przebiegła dla najdłuższego klucza AES 256 bitów, najwolniejszy z kolei okazała się operacja szyfrowania kluczem o długości 192 bitów. Czas tych operacji jest na tyle

mały, że wyniki te mogły wynikać z błędu pomiarowego.

Każda kolejna generacja smartfonu z systemem

iOS wykazywała się o połowę lepszym czasem szyfrowania

dużego obrazka (1,8 MB) od swojego poprzednika. Podczas,

gdy iPhone 5 potrzebował ok 1 minuty, iPhone X wykonywał tę samą operację w czasie nie przekraczającym 8 sekund.

Wyniki powyższego badania przedstawiono poniżej (Rysunku 5, Rysunek 6).

Rys. 5. Wykres przedstawiający czas szyfrowania małego obrazka za pomocą kluczy AES o różnych długościach na urządzeniach testowych

Rys. 6. Wykres przedstawiający czas szyfrowania dużego obrazka za pomocą kluczy AES o różnych długościach na urządzeniach testowych

Powyższa część badania zaprzeczyła hipotezie 1 mówiącej, że zastosowanie klucza kryptograficznego

o większej długości zwiększa czas szyfrowania tych samych

danych. Jednocześnie też potwierdzona została hipoteza 2 mówiąca, że czas wygenerowania klucza kryptograficznego lub pary kluczy kryptograficznych wzrasta

proporcjonalnie do zwiększenia się długości generowanego klucza lub pary kluczy.

Porównanie szybkości generowania symetrycznych kluczy kryptograficznych na różnych urządzeniach wykazało, że nowsze urządzenia są w stanie wykonać tę operację szybciej, niż ich starsze odpowiedniki. Na Rysunku 7

przedstawiono wykres zależności długości klucza ECC od czasu jego generowania. Zauważyć na nim można, że wykres wzrasta liniowo, natomiast w przypadku pary

90

45

23

11

28

0

14

0

70

35

34

0

17

0

85

43

0

100

200

300

400

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

itów 192 bity itów

Cza

s g

en

ero

wa

nia

[s]

Długoś klu za AES

Czas generowania kluczy AES [ms]

12

4 62

31

16

22

4

11

2 56

28 8

11 3 5

0

50

100

150

200

250

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

AES128 AES192 AES256

Mały o razek

Cza

s sz

yfr

ow

an

ia [

ms]

Długoś klu za AES

Szyfrowa ie ałego o razka [ s]

62

,7

31

,4

15

,7

7,8

62

,3

31

,1

15

,6

7,8

63

,9

32

,0

16

,0

8,0

0

10

20

30

40

50

60

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

iPh

on

e 5

iPh

on

e 6

Plu

s

iPh

on

e 6

s

iPh

on

e X

AES128 AES192 AES256

Cza

s sz

yfr

ow

an

ia [

s]

Długoś klu za AES

Szyfrowa ie dużego o razka [s]


105 105

kluczy RSA (Rysunek 8) wykres posiada charakterystykę rosnącą wykładniczo.

Rys. 7. Wykres przedstawiający porównanie czasu generowania pary kluczy ECC

Rys. 8. Wykres przedstawiający porównanie czasu generowania pary kluczy RSA

Przedstawione wyniki potwierdzają postawioną tezę: czas szyfrowania tych samych danych za pomocą tych samych algorytmów szyfrujących opartych o te same klucze kryptograficzne oraz generowanie tych samych kluczy

kryptograficznych zajmuje mniej czasu na nowszym

urządzeniu.

5. Wnioski

W niniejszym artykule skupiono się na porównaniu czasu

generowania pary kluczy RSA i ECC oraz symetrycznego

klucza AES o różnych długościach. Następnie zmierzono czas

szyfrowania danych różnej wielkości na różnych urządzeniach testowych opartych o najnowszą wspieraną

wersję systemu iOS. Nowsze urządzenia wyposażone w szybszy procesor oraz większą ilość pamięci operacyjnej wykazały się większą wydajnością od swoich poprzedników. Przewaga czasowa wynosiła często połowę czasu. Potwierdziło to postawioną tezę.

Wyniki badań wykazały, że operacja generowania pary kluczy ECC zajmuje o wiele mniej czasu niż generowanie pary RSA. Potwierdza to słuszność i popularność wykorzystania pierwszego z algorytmów w wielu aplikacjach

i rozwiązaniach w urządzeniach mobilnych. Przykładem może być wymiana kluczy między urządzeniem mobilnym a serwerem w celu nawiązania bezpiecznego połączenia SSL (handshake) [1]. Czas generowania kluczy kryptografii

symetrycznej nie ma jednak odzwierciedlenia w czasie

szyfrowania klucza symetrycznego. W każdym przypadku jest on znikomy i nie przekracza 1 milisekundy. Stanowi to

zaprzeczenie postawionej hipotezy mówiącej, że zastosowanie klucza kryptograficznego o większej długości zwiększa czas szyfrowania tych samych danych.

Wykazano również, że zwiększanie bezpieczeństwa danych poprzez zastosowanie dłuższego klucza AES nie wpływa negatywnie na czas wykonywania operacji szyfrowania na urządzeniu mobilnym, bez względu na ich wielkość, co jest potwierdzeniem hipotezy 1:

„czas wygenerowania klucza kryptograficznego lub pary

kluczy kryptograficznych wzrasta proporcjonalnie

do zwiększenia się długości generowanego klucza lub pary kluczy. Szyfrowanie niewielkiej ilości danych obarczone zostało dużym błędem pomiarowym. Operacja zajmowała niewiele czasu, a sam błąd mógł być spowodowany procesami działającymi w tle na urządzeniach testowych.

Literatura

[1] Binnie C.: Linux Server Security: Hack and Defend, Wiley,

2016.

[2] Butkiewicz M., Madhyastha H. V., Sekar V., Wang D, Wu Z.:

Reprioritizing Web Content to ImproveUser Experience

on Mobile Devices, University of Michigan,

https://www.usenix.org/system/files/conference/nsdi15/nsdi15-

paper-butkiewicz.pdf, [10.11.2018]

[3] Hechenblaikner C., StrombergerC., Teufl P., Zefferer T.:

iOS Encryption Systems, Deploying iOS Devices in Security-

critical Environments, Institute for Applied 120 Information

Processing and Communications, Graz University

of Technology, Austria,2013.

[4] PERFORMANCE ANALYSIS OF ELLIPTIC CURVE

MULTIPLICATION ALGORITHMS FOR ELLIPTIC CURVE

CRYPTOGRAPHY, https://etd.lib.metu.edu.tr/

upload/12607698/index.pdf, [10.11.2018]

[5] Support Apple: Identify your iPhoone model,

https://support.apple.com/en-us/HT201296, [20.11.2018].

0

20

40

60

80

100

120

140

160

224 256 288 320 352 384

Cza

s [m

s]

Długoś klu za [ it]

Generowanie pary kluczy ECC

iPhone 5 iPhone 6 Plus

iPhone 6s iPhone X

0

200

400

600

800

1000

1200

1400

1024 2048 3072 4096 5120 6144 7168 8192

Cza

s [s

]

Długoś klu za [ it]

Generowanie pary kluczy RSA

iPhone 5 iPhone 6 Plus

iPhone 6s iPhone X

JCSI 11 (2019) 106-113



106

Wykorzystanie elektronicznego pulsometru oraz d więku przestrzennego do

interakcji z u ytkownikiem w VR

Patryk Plewa*, Tomasz Szymczyk


Streszczenie. Artykuł przedstawia sposób wykorzystania elektronicznego pulsometru oraz d więku przestrzennego do interakcji

z u ytkownikiem w wirtualnej rzeczywisto ci. Sposób interakcji został przedstawiony na podstawie czterech scenariuszy badawczych.

W dwóch pierwszych scenariuszach badawczych zachowanie obiektów wirtualnej rzeczywisto ci zale ało od wskazań pulsometru, w kolejnych dwóch scenariuszach pulsometr był tylko miernikiem. W artykule starano się znale ć odpowied na pytania czy wirtualna rzeczywisto ć wpływa na puls osoby badanej oraz czy d więk przestrzenny wpływa na puls osoby badanej, a je eli tak to, który z czynników w większym stopniu wpływa na puls. Dokonano pomiaru pulsu spoczynkowego ka dej osoby, a następnie wyznaczono zmienno ć pulsu dla ka dego scenariusza. W badaniach przeprowadzono analizę dla ka dej osoby indywidualnie, a tak e zbiorczą dla ka dego ze scenariusza. Dodatkowo

wnioskowanie oparte było równie na ankietach przed badaniami i po badaniach.

Słowa kluczowe: wirtualna rzeczywisto ćś d więk przestrzennyś pulsometr



The use of an electronic heart rate monitor and surround sound to interact with

a user in VR

Patryk Plewa*, Tomasz Szymczyk


Abstract. Article shows a way of use an electronic heart rate monitor and surround sound to interact with user in virtual reality. The method of

interact was presented on the basis of four scenarios. In the first two scenarios the behawior of objects in virtual reality depended on the

indications of heart rate monitor in the next two scenarios heart rate monitor was just a measurer. The article attempts to find an answer to the

question whether virtual reality affects the pulse of the examined person and whether surround sound affects the pulse of the examined person,

and if so which factor influences the pulse to a greater extent. The individual resting pulse was measured and then was determined the pulse

variability for each scenario. In the research, an analysis was carried for each person individually and collective analysis for each scenario. In

addition, inference was also based on questionnaires before and after research.

Keywords: virtual reality; surround sound; heart rate monitor



1. Wstęp

Wa nym aspektem systemów opartych na VR jest stymulacja ludzkich zmysłów takich jak wzrok, słuch czy

dotyk w taki sposób, aby u ytkownik odczuwał obecno ć w rodowisku wirtualnym [1]. Jednak wirtualna rzeczywisto ć to nie tylko gogle nało one na głowę, które przed oczami pokazują obraz. Wirtualna rzeczywisto ć to równie interaktywny d więk przestrzenny.

Podczas interakcji z wirtualnym wiatem towarzyszą badanym ró nego rodzaju odczucia. W zale no ci z czym mieli do czynienia mogą to być na przykładŚ rado ć, spokój, niepokój czy strach. Ka de takie doznanie ma swoje odzwierciedlenie w tętnie. Tętno jest to liczba skurczów komór serca w jednostce czasu i zwykle jest wyra ana jako liczba uderzeń na minutę. Prawidłowy zakres często ci akcji serca u osób dorosłych wynosi od 60 do 100 uderzeń na minutę [2]. Jednak często ć pracy serca zale y od kilku czynników takich jak poziom aktywno ci fizycznej czy stan

psychiczny. W związku z tym je eli podczas interakcji z wirtualną rzeczywisto cią osoba badana czuje spokój towarzyszyć temu mo e obni enie tętna. Z drugiej strony kiedy osoba badana podczas kontaktu ze wiatem wirtualnym będzie się czego bała to prawdopodobnie zwiększy się jej często ć akcji serca.

Puls spoczynkowy jest warto cią indywidualną dla ka dego człowieka. Mo liwe jest ogólne klasyfikowanie zakresu tego pulsu w zale no ci od wieku, kondycji fizycznej, rodzaju uprawianego sportu, sposobu, stylu ycia. Na rysunku

1 mo na zauwa yć jak ró ni się rednia warto ć pulsu spoczynkowego w zale no ci od rodzaju uprawianego sportu.


107 107

Rys. 1. Puls spoczynkowy w zale no ci od uprawianego sportu [3]

Z uwagi na brak mo liwo ci jednoznacznego sklasyfikowania osób badanych podjęto próbę wyznaczenia indywidualnego pulsu spoczynkowego dla ka dej z osób oddzielnie. W czasie odtwarzania muzyki relaksacyjnej

dokonywano ciągłego pomiaru pulsu. Następnie wyliczono warto ć rednią z otrzymanych wyników i tą warto ć uznano za przybli oną warto ć pulsu spoczynkowego danej osoby.

Puls spoczynkowy przybli ony do warto ci całkowitej ka dej z badanych osób był inny. Przedstawia to rysunek 2.

Rys. 2. Puls spoczynkowy badanych osób

Poni sza praca ma za zadanie zbadanie w jakim stopniu i czy w ogóle wirtualna rzeczywisto ć wpływa na szybko ć bicia serca osoby badanej (puls). Jednak, aby to zbadać

nale ało połączyć ze sobą kilka odrębnych rodowisk. Przede wszystkim to zrobienia wirtualnego wiata zastosowano rodowisko Unity jako jedne z najpopularniejszych rodowisk

do tworzenia wirtualnej rzeczywisto ci. Do odczytu pulsu osoby badanej posłu yła opaska na rękę Xiaomi Mi Band 2, która w ostatnim czasie bardzo zyskała na popularno ci. Do pobrania pulsu z opaski stworzona została aplikacja na smartfony z systemem Android, a cało ć łączą usługi sieciowe napisane w języku Java, które odpowiedzialne są za odebranie danych z aplikacji zainstalowanej na smartfonie oraz wysłanie ich do wirtualnej rzeczywisto ci.

2. Opis urządzeń pomiarowych

Badania przeprowadzono w prowizorycznym laboratorium

badawczym wyposa onym w system d więku przestrzennego oraz komputery umo liwiające płynną projekcję wirtualnego obrazu dla wirtualnej rzeczywisto ci. Laboratorium nie było wyposa one w profesjonalny cyfrowy pulsometr umo liwiający rejestrację wyników. Wybrano jednak

najlepszą bud etową opaskę – Xiaomi Mi Band 2 mierzącą puls. Ponadto napisano oprogramowanie umo liwiające rejestrację pulsu z opaski w czasie rzeczywistym.

3. Aplikacje opracowane na potrzeby badań

3.1. Wirtualny świat

Do stworzenia scenariuszy badawczych wykorzystano

darmowe oprogramowanie Unity 2017.

Silnik Unity jest bardzo popularnym rozwiązaniem przeznaczonym dla programistów zajmujących się profesjonalnie lub amatorsko tworzeniem gier dwu lub trój wymiarowych [4]. W Internecie zostało przeprowadzonych

wiele badań oraz ankiet, które sprawdzały popularno ć ró nych silników do tworzenia gier jednak we wszystkich na szczycie listy był silnik Unity [5, 6, 7]. Był to jeden z głównych powodów dla którego postanowiono stworzyć wirtualny wiat wykorzystując Unity. Kolejnym równie wa nym powodem była bardzo obszerna dokumentacja techniczna, oraz du a społeczno ć, która chętnie pomaga w przypadku napotkania problemu.

Stworzono cztery niezale ne scenariusze projekcyjne. Z uwagi na fakt badania wpływu zarówno obrazu jak

i d więku przestrzennego na odczucia osoby badanej dwa

scenariusze ( chodzące dookoła badanego i atakujące go wilki

oraz pomieszczenie z przysuwającymi się w kierunku osoby badanej cianami) wykorzystują obraz 3D jako ródło bod ca wzrokowego, a kolejne dwa scenariusze (nadje d ający pociąg oraz wyjące i chodzące dookoła badanego wilki) opierają się jedynie na d więku przestrzennym. Pierwszy wiat przedstawia ciemny zamglony las widoczny na poni szym rysunku (rys.3).


108 108

Rys. 3. Widok wirtualnego lasu z obrazem VR

Rys. 4. Widok wirtualnego pomieszczenie z obrazem VR

Drugi wirtualny wiat przedstawia małe pomieszczenie w którym znajduje się kilka przedmiotów takich jakŚ stół, butelka, krzesła, beczki, skrzynki oraz lampy, które o wietlały te pomieszczenie. wiat ten przedstawiony został na rysunku 4.

W trakcie badań z wykorzystaniem scenariusza

pierwszego i drugiego wskazania pulsometru były czynnikiem determinującym zachowanie obiektów w wirtualnej rzeczywisto ci. To od zmian pulsu osoby badanej zale ało jak przebiegnie badanie danym scenariuszem.

Rys. 5. Widok sceny Unity 2017 scenariusza przeje d ającego pociągu

Na powy szym rysunku 5 został przedstawiony wirtualny wiat imitujący przeje d ający blisko osoby badanej pociąg.

Osobę badaną w tym wiecie przedstawia kula znajdująca się na rodku w kolorze szarym, a kula w kolorze czarnym

przedstawia pociąg oraz jego kolejne poło enia w czasie. Strzałkami została przedstawiona cie ka ruchu pociągu.

Rys. 6. Widok sceny Unity 2017 scenariusza z krą ącymi dookoła badanego wilkami

Na rysunku 6 został przedstawiony wirtualny wiat imitujący krą ące wokół osoby badanej wilki. Osoba badana w tym wiecie umieszczona została w centrum i przedstawia ją kula w kolorze szarym z ikoną kamery w rodku. Czerwono-biała kula krą ąca dookoła osoby badanej przedstawia wilki, a białymi strzałkami została oznaczona jej cie ka ruchu.

W przypadku scenariusza trzeciego i czwartego pulsometr

był wyłącznie miernikiem, a jego wskazania nie miały przeło enia na zachowanie wirtualnej rzeczywisto ci. Szczegółowy opis scenariuszy badawczych przedstawiony zostanie w rozdziale czwartym.

Do stworzenia wirtualnego lasu wykorzystane zostały obiekty dostępne w dołączonej do rodowiska Unity bibliotece dodatków. U yto obiektów drzew o nazwach Broadleaf oraz Confier, a tak e obiektu przedstawiającego trawę o nazwie GrassFrond01. Dla spotęgowania uczucia strachu osoby badanej stworzony las ma wiele pagórków oraz dołków co w przypadku podjęcia próby ucieczki mogłoby spowodować zapędzenie obiektu przedstawiającego osobę badaną w lepy zaułek.

W trakcie tworzenia sceny przedstawiającej pomieszczenie skorzystano z gotowych obiektów. Podczas tworzenia sceny u yto obiektów beczek oraz skrzynek dostępnych w paczce Western Props Pack. Inne obiekty

widoczne na scenie takie jak stół, krzesła czy lampy zostały pobrane z oficjalnego sklepu Unity [8].

W obu scenach u yto obiektów typu Character

Controller. W rodowisku Unity obiekt ten pozwala na

przedstawienie postaci w widoku pierwszoosobowym bąd z perspektywy osoby trzeciej. W omawianej pracy u yty został widok pierwszoosobowy, aby doznania osoby badanej były jak najbardziej zbli one do prawdziwych.


109 109

3.2. Aplikacja do odczytu danych z opaski Xiaomi Mi

Band 2

Aby odczytać puls z wykorzystanego urządzenia pomiarowego i poddać go dalszym działaniom niezbędne było stworzenie odpowiedniej aplikacji. Aplikacja ta oprócz odczytu pulsu z opaski powinna zapisywać wynik wraz

z godziną pomiaru do odrębnego pliku w celu archiwizowania pomiarów oraz po odczytaniu pulsu automatycznie wysłać go na serwer, który będzie przetwarzał otrzymane dane. Ze

względów mo liwo ciowych postanowiono stworzyć aplikację na telefony z systemem Android i nazwano ją MiBand2. Aplikacja powinna łączyć się z opaską na podstawie wprowadzonego adresu MAC opaski. Po

połączeniu powinien zostać wy wietlony odpowiedni status połączenia opaski z telefonem. Adres serwera na który aplikacja będzie wysyłała dane równie powinien być konfigurowalny z poziomu aplikacji. Interfejs aplikacji oraz

wygląd przykładowego pliku z zapisanymi danymi przedstawiony został na rysunkach 7 i 8.

Rys. 7. Wygląd interfejsu aplikacji

Rys. 8. Widok danych zapisanych w pliku

3.3. Usługi sieciowe pośredniczące pomiędzy aplikacją mobilną a VR

Do zapewnienia komunikacji pomiędzy wirtualną rzeczywisto cią a aplikacją mobilną pobierającą puls z opaski Xiaomi Mi Band 2 stworzono dwie usługi sieciowe. Pierwsza

z usług odpowiedzialna jest za odebranie pulsu z aplikacji mobilnej i zapisanie go w pamięci z dokładną datą, a druga usługa sieciowa odpowiedzialna jest za wysłanie aktualnej warto ci pulsu do wirtualnego wiata. Usługi te stworzone zostały w technologii Java z wykorzystaniem framework’a Spring Boot i uruchamiane są na wbudowanym we framework serwerze Tomcat [9].

4. Procedura badawcza

Zostały przeprowadzone badania mające na celu stwierdzenie w jak du ym stopniu obraz wirtualnej rzeczywisto ci i d więk przestrzenny wpływają na odczucia osoby badanej. Odwzorowaniem reakcji była zmiana pulsu. Dzięki ró norodno ci przygotowanych scenariuszy mo na stwierdzić czy wirtualna rzeczywisto ć wpływa na stan osoby badanej oraz, który z czynników, wizualny model VR czy

d więk przestrzenny ma większy wpływ na puls osoby badanej.

Przed wykonaniem badań osoba badana musiała wypełnić ankietę. Tre ć ankiety przedstawia rysunek 9.

Rys. 9. Ankieta przed badaniem


110 110

Dzięki przeprowadzeniu ankiety mo na było wstępnie okre lić czy przedstawione sceny mogą mieć wpływ na puls osoby badanej. Po przeprowadzonym badaniu osoba badana

równie musiała wypełnić ankietę. Dzięki tej ankiecie mo na było okre lić subiektywne odczucia osoby na temat badania aby pó niej porównać je z rzeczywistymi warto ciami odebranymi z pulsometru. Tre ć ankiety po badaniu przedstawia rysunek 10. W ankiecie do okre lenia intensywno ci odczuć posłu ono się czterostopniową skalą objawów lękowych Rachel żittelman [10]. Skala ta jednak

została dostosowana do warunków badań aby prawidłowo okre lić intensywno ć odczuć.

Rys. 10. Ankieta po badaniu

Do przeprowadzenia badań opracowane zostały cztery scenariusze badawcze.

Celem pierwszego scenariusza badawczego było zbadanie czy wizualny model wirtualnego wiata oraz d więk przestrzenny mają wpływ na zmianę pulsu osoby badanej. W tym celu osoba badana po wej ciu do pomieszczenia w którym wykonywane były badania musiała zało yć wszystkie niezbędne do wykonania badania urządzenia, to jest:

• Opaska do pomiaru pulsu Xiaomi Mi Band 2

• Okulary do wirtualnej rzeczywisto ci

Zachowanie obiektów wirtualnej rzeczywisto ci w tym scenariuszu zale ało od tętna osoby badanej dlatego

następnym krokiem było uruchomienie aplikacji do odczytu

pulsu MiBand2 oraz serwera z usługami sieciowymi. Po

odpowiednim zało eniu urządzeń oraz uruchomieniu niezbędnych aplikacji osoba badana musiała stanąć w wyznaczonym miejscu. Miejsce to okre la punkt w którym schodzą się fale d więkowe ze wszystkich gło ników systemu d więku przestrzennego. Kiedy ju wszystkie zało enia zostały spełnione mo na było przystąpić do wykonania badania. W tym celu nale ało uruchomić przygotowaną na potrzeby badań scenę wirtualnej rzeczywisto ci. Przedstawiała ona ciemny zamglony las. Osoba badana dzięki okularom do wirtualnej rzeczywisto ci widziała wszystko co się dookoła niej dzieje z perspektywy pierwszoosobowej. Wokół niej poruszał się obiekt z którym skojarzony był d więk wyjącej watahy wilków. Początkowo d więk ten był cichy. Według Alexandry Horowitz [11] psy (w tym

przypadku wilki) są w stanie wyczuć, e człowiek się boi co mo e przeło yć się na ich zachowanie względem człowieka. W trakcie badań wzrost tętna uto samiany był ze wzrostem strachu osoby badanej. Dlatego te wraz ze wzrostem tętna osoby badanej (wzrostem strachu) d więk stawał się coraz gło niejszy, a obiekt z d więkiem przybli ał się do obiektu osoby badanej co miało zasymulować to, e wilk czuje się pewnie i jest w stanie w ka dej chwili zaatakować. Kiedy

odległo ć pomiędzy obiektami przekroczyła ustaloną programowo warto ć (obiekty były blisko siebie) d więk wyjących wilków zostawał zmieniany na d więk atakującego wilka. W przypadku spadku pulsu osoby badanej

(uspokojenia się) obiekty oddalały się od siebie, a d więk stawał się coraz cichszy. Zachowanie to symulowało sytuację kiedy to osoba badana czuje mniejszy strach, a tym samym

wilk przestał być na dominującej pozycji względem badanego.

Scenariusz ten zakładał, e osoba po usłyszeniu początkowego d więku to jest wyjącej watahy wilków zacznie być coraz bardziej niespokojna co będzie się przekładało na wzrost pulsu. Je eli jednak tak by się nie stało operator badania miał mo liwo ć manualnego sterowania odległo cią między obiektami co wią e się ze wzrostem natę enia d więku bąd jego całkowitą zmianą. Opcja ta jest

niezbędna równie w przypadku gdy puls osiągnie bardzo wysokie warto ci. Wtedy ze względów zdrowotnych operator

powinien oddalić obiekty od siebie co wią e się ze zmniejszeniem gło no ci bąd całkowicie przerwać badanie.

Drugi scenariusz miał za zadanie zbadać czy sam d więk przestrzenny ma wpływ na zmianę pulsu osoby badanej. W tym celu osoba badana musiała zało yćŚ

• Opaskę do pomiaru pulsu Xiaomi Mi Band 2

• Opaskę na oczy

Opaska na oczy została wykorzystana w tym celu, aby osoba badana mogła się skupić wyłącznie na d więku jaki ją otacza i nie rozpraszała się innymi elementami obecnymi w pomieszczeniu. Reszta kroków niezbędnych do wykonania jest taka sama jak w przypadku scenariusza pierwszego.

Wirtualny wiat u yty do tego scenariusza jest tym samym wiatem jak w scenariuszu pierwszym. Wokół osoby badanej

porusza się obiekt do którego podłączony jest d więk wyjącej watahy wilków. Ró nica polega na tym, e osoba badana nie


111 111

widzi tego co się dookoła niej dzieje, więc zdana jest tylko na swój słuch i wyobra nię.

Trzeci scenariusz badawczy równie badał czy sam d więk przestrzenny jest w stanie wpłynąć na puls osoby badanej. W tym przypadku jednak pulsometr został u yty wyłącznie w celach pomiarowych. Zmiany pulsu nie wpływały na zachowanie wirtualnej rzeczywisto ci. Scenariusz ten miał potwierdzić wyniki badań z wykorzystaniem scenariusza drugiego to znaczy czy

wyłącznie d więk przestrzenny jest w stanie wpłynąć na puls osoby badanej. Do tego celu u yty został d więk nadje d ającego pociągu. Na początku osoba badana słyszy

jedynie d więk ostrzegający o zbli ającym się pociągu stosowany przy przejazdach kolejowych. Wraz z upływem czasu słychać równie d więk trąbiącego pociągu. D więk ten jest coraz gło niejszy poniewa obiekt do którego jest podłączony cały czas zbli a się w linii prostej do obiektu przedstawiającego osobę badaną. Po osiągnięciu programowo

ustawionej minimalnej odległo ci pomiędzy obiektami, obiekt do którego podłączony jest d więk zostaje powoli wycofywany do miejsca z którego rozpoczęte zostało badanie w celu zasymulowania minięcia obiektu osoby badanej. Podobnie jak w poprzednim scenariuszu badawczym osoba

badana do wykonania badania musiała zało yćŚ


• Opaskę na oczy

Czwarty scenariusz badawczy podobnie jak pierwszy

scenariusz badał wpływ zarówno wizualnego modelu VR jak i d więku przestrzennego na puls osoby badanej. Scenariusz

ten przedstawiał małe pomieszczenie. W pomieszczeniu tym znajdowało się kilka przedmiotów takich jakŚ stół, krzesła, beczki, skrzynki oraz lampy, które o wietlały te pomieszczenie. Po rozpoczęciu badania ciany w pomieszczeniu zaczęły przysuwać się w kierunku osoby badanej. Dla wzmocnienia odczuć osoby badanej z gło ników zaczęła równie lecieć niepokojąca muzyka zaczerpnięta z jednego z filmów z gatunku horror. Przedmioty znajdujące się na scenie po kontakcie ze cianą zaczynają się przesuwać, a niektóre spadać na podłogę wydając przy tym charakterystyczny d więk. Równie lampy po kontakcie ze cianą wydają d więk zbijanej arówki i gasną co powoduje, e w pomieszczeniu zaczyna robić się ciemno. ciany jednak

nie zgniatają obiektu przedstawiającego osobę badaną tylko zatrzymują się chwilę wcze niej tworząc bardzo wąski korytarz. Osoba badana przed wykonanie badania musiała zało yćŚ


• Okulary do wirtualnej rzeczywisto ci

Wykonanie badań z u yciem kilku ró nych scenariuszy pozwoliły na wyciągnięcie wniosków i odpowied na pytanie czy wirtualna rzeczywisto ć ma wpływ na puls osoby badanej, a je eli tak to, który z czynników - obraz czy d więk ma większy wpływ na puls.

5. Analiza wyników badań

Ze względu na zastosowanie ró nych scenariuszy badawczych postanowiono przeprowadzić analizę wyników

badań dla ka dego scenariusza oddzielnie. Dzięki temu mo na było zaobserwować wpływ danego scenariusza na tętno w obrębie całej grupy badawczej, a nie tylko

pojedynczej osoby. W tym celu zostały sporządzone odpowiednie wykresy, które przedstawiają ró nice pomiędzy maksymalną warto cią tętna zarejestrowaną w trakcie badania danym scenariuszem, a rednią warto cią tętna spoczynkowego - R. Warto ć ta została wyliczona z poni szego wzoru (1) Ś

R = Pimaxosoby – Pispoczynkowyosoby (1)

gdzie:

R - ró nica pomiędzy maksymalną warto cią tętna zarejestrowaną w trakcie badania danym scenariuszem, a pulsem spoczynkowym danej osoby.

Pimaxosoby - maksymalna warto ć tętna zarejestrowaną w trakcie badania danym scenariuszem danej osoby.

Pispoczynkowyosoby – puls spoczynkowego danej osoby.

Na rysunku 11 przedstawiony został wykres dla badań przeprowadzonych z u yciem scenariusza pierwszego.

Rys. 11. Wykres wyników badań przeprowadzonych scenariuszem pierwszym

Tabela 1. Liczba osób w podziale na odczucia w scenie 1

Odczucia w scenie 1 Liczba osób

1 – adnych odczuć 0

2 – lekkie odczucia 4

3 – wyra ne odczucia 13

4 – bardzo intensywne odczucia 3

Po przeanalizowaniu powy szego wykresu wywnioskować mo na, e badanie scenariuszem pierwszym (wilki z wykorzystaniem wizualnego modelu VR) na ka dej osobie badanej wywołało emocje. Podczas trwania badania tym scenariuszem u ka dej z osób zarejestrowano wy sze tętno w porównaniu do pulsu spoczynkowego tej osoby. Potwierdzają to równie wyniki ankiet przeprowadzonych po badaniach widoczne w tabeli 1. adna z badanych osób nie zaznaczyła, e scenariusz ten nie wywołał na niej adnych


112 112

emocji. Minimalna warto ć R wynosi 7 uderzeń na minutę, a maksymalna 38 uderzeń na minutę.

Rys. 12. Wykres wyników badań przeprowadzonych scenariuszem drugim







Na rysunku 12 przedstawiony został wykres wyników

badań przeprowadzonych przy u yciu scenariusza drugiego

(wilki bez wizualnego modelu VR). W ankiecie po badaniu

jedna osoba zaznaczyła, e scenariusz ten wywołał na niej bardzo intensywne emocje co równie mo na stwierdzić po wykresie poniewa u jednej z osób obliczona warto ć R wynosi 41 uderzeń na minutę. Według wyników z ankiet widocznych w tabeli 2 scenariusz ten nie wywołał adnych odczuć na dwóch osobach. Jednak na powy szym wykresie wyra nie widać tylko jedną osobę, której tętno niezbyt wzrosło w porównaniu do tętna spoczynkowego. U większo ci badanych osób warto ć R wynosi lub przekracza 20 uderzeń na minutę, co w porównaniu z warto ciami tętna spoczynkowego jest wysoką ró nicą.

Rys. 13. Wykres wyników badań przeprowadzonych scenariuszem trzecim







Wyniki badań przeprowadzonych przy u yciu scenariusza trzeciego (nadje d ający pociąg) przedstawione zostały na rysunku 13. Według wyników ankiet widocznych

w tabeli 3 scenariusz ten na adnej z badanych osób nie wywołał bardzo intensywnych odczuć. Jednak równie w przypadku badań tym scenariuszem u ka dej z osób zarejestrowano większą warto ć tętna w stosunku do warto ci pulsu spoczynkowego tej osoby. U dwóch z badanych osób wyliczona warto ć R osiąga lub nawet przekracza 30 uderzeń na minutę, co porównując z warto ciami pulsów spoczynkowych osób jest du ą ró nicą.

Rys. 14. Wykres wyników badań przeprowadzonych scenariuszem czwartym







Wyniki badań przeprowadzonych z u yciem scenariusza czwartego (pomieszczenie) przedstawione zostały na rysunku 14. W tabeli 4 przedstawione zostały wyniki ankiet przeprowadzonych po badaniu. Jedna z badanych osób

zadeklarowała, e badanie tym scenariuszem nie wywołało na niej adnych odczuć co równie mo na wywnioskować z powy szego wykresu poniewa u jednej z badanych osób warto ć R wyniosła 2 uderzenia na minutę. U jednej z badanych osób obliczona warto ć R wyniosła 38 uderzeń na minutę co mo e wiadczyć o tym, e scenariusz ten wywołał na niej bardzo intensywne odczucia. Potwierdzają to równie wyniki ankiet poniewa jedna z osób badanych zadeklarowała, e scenariusz ten wywołał na niej bardzo intensywne odczucia.

żdyby wyciągać wnioski na podstawie wyników ankiet to największe emocje według osób badanych wywołał


113 113

scenariusz pierwszy natomiast najmniejsze emocje scenariusz

trzeci. Jednak biorąc pod uwagę rzeczywiste warto ci zmierzone przy pomocy pulsometru mo na stwierdzić, e to drugi scenariusz badawczy wywołał największe emocje w ród badanych poniewa w trakcie tego scenariusza została zanotowana najwy sza warto ć ró nicy pomiędzy maksymalną zarejestrowaną warto cią tętna danej osoby, a tętnem spoczynkowym. Wszystkie jednak scenariusze

sprawiły, e puls osób badanych zmieniał się.

6. Wnioski

Celem tej pracy było zbadanie czy wirtualna rzeczywisto ć oraz d więk przestrzenny wpływają na ludzkie emocje. Przebadano, który z tych czynników ma większy wpływ na emocje.

Dzięki przeprowadzeniu badań w oparciu o ró ne scenariusze badawcze mo na było zaobserwować jak wirtualna rzeczywisto ć wpływa na emocje ludzi, a dzięki zastosowaniu pulsometru mo na było wej ć w interakcję pomiędzy wirtualną rzeczywisto cią, a osobą badaną. Podział badań na te wykorzystujące okulary do wirtualnej rzeczywisto ci i te, w których to d więk przestrzenny grał główną rolę pozwolił na ocenę, który z czynników ma większy wpływ na emocje badanego.

żdyby brać pod uwagę tylko wyniki ankiet

przeprowadzonych po badaniach mo na by stwierdzić, e to wizualny obraz wirtualnej rzeczywisto ci ma większy wpływ na emocje badanych. Według ankiet to wła nie scenariusze wykorzystujące wizualny obraz wywoływały większe emocje ni te wykorzystujące wyłącznie d więk przestrzenny. Jednak biorąc pod uwagę rzeczywiste wskazania pulsometru ju takich oczywistych wniosków wyciągnąć nie mo na. żdyby brać pod uwagę największa obliczoną warto ć R mo na stwierdzić, e to scenariusz drugi (wilki bez wizualnego modelu VR) wywołał największe emocje w ród osób badanych poniewa to w trakcie badania tym scenariuszem warto ć ta była największa.

Wiele równie zale y od rodzaju emitowanego d więku. Mimo, e scenariusz drugi i trzeci ró niły się wyłącznie rodzajem odtwarzanego d więku to jak mo na zauwa yć na

wykresach większe warto ci tętna zostały zanotowane dla scenariusza drugiego. Mo na zatem wywnioskować, e d więk wyjących wilków wywierał na badanych większe emocje ni d więk przeje d ającego pociągu.

Kolejnym wa nym aspektem, który nale y wziąć pod uwagę jest to czy dana osoba miała ju wcze niej styczno ć z wirtualną rzeczywisto cią. Z przeprowadzonych badań wynika, e osoby, które tej styczno ci wcze niej nie miały du o mocniej reagują ni osoby, które ju wcze niej ten kontakt miały. Jednak w jakim stopniu spowodowane to mo e być nie tyle tym co przedstawia wirtualna rzeczywisto ć, a tym, e jest to dla tych osób nowe do wiadczenie w yciu.

Nie mniej jednak w pracy udowodniono, e zarówno wizualny model VR jak i d więk przestrzenny mają wpływ na puls osoby badanej. Po przeanalizowaniu wyników badań mo na stwierdzić, e to d więk przestrzenny ma większy wpływ na puls osoby badanej.

Literatura

[1] Hill Z. Virtual Reality: Advances in Research and Applications.

Nova Science Publishers, 2016.

[2] Binder M.D., Hirokawa N., Windhorst U.: Heart Rate,

Encyclopedia of Neuroscience, Springer 2009.

[3] https://www.hrv4training.com/uploads/1/3/2/3/13234002/37155

25_orig.png [12.2018]

[4] Mike Geig: Unity przewodnik projektanta gier, Helion, 2015

[5] https://artjoker.net/blog/mobile-game-development-in-2017-

best-tools-and-advice/ [04.2018]

[6] https://www.slant.co/versus/1047/5128/~unity_vs_unreal-

engine-4 [04.2018]

[7] https://thenextweb.com/gaming/2016/03/24/engine-dominating-

gaming-industry-right-now/ [04.2018]

[8] https://www.assetstore.unity.com [04.2018]

[9] Craig Walls: Spring Boot in action, Manning, 2016.

[10] Katarzyna Markowska-Regulska: Strategie radzenia sobie

z lękiem u osób z zaburzeniami odżywiania. Uniwersytet

Medyczny im. Karola Marcinkowskiego w Poznaniu 2014.

[11] http://www.animalplanet.com/pets/do-dogs-know-when-

someone-is-afraid-of-them/ [12.2018].

JCSI 11 (2019) 114-118



114

Wykorzystanie kontrolera Kinect do interakcji z u ytkownikiem w VR

Przemysław Samoń*, Tomasz Szymczyk


Streszczenie. W artykule przedstawiono autorską metodę badania reakcji człowieka na d więk przestrzenny. Wykorzystano ogólnodostępne urządzenia takie jakŚ sensor Kinect, zestaw d więku przestrzennego Creative. Opracowano metodę badawczą, metodę analizy oraz niezbędne scenariusze badawcze. Ponadto zaproponowano dwie ankietyŚ przed i po badaniu. Następnie opracowano wyniki badań, a na ich podstawie sformułowano wnioski.

Słowa kluczowe: sensor Kinect; akwizycja ruchu; przetwarzanie danych



Using Kinect controller for interacting with user in VR

Przemysław Samoń*, Tomasz Szymczyk


Abstract. The article presents the author's method of studying human reaction to spatial sound. Public devices such as: Kinect sensor, Creative

surround sound set were used. A research method, method of analysis and necessary research scenarios were developed. In addition, two

questionnaires were proposed: before and after the study. Next, the results of the research were developed and the conclusions were formulated

on their basis.

Keywords: sensor Kinect; acquiring traffic; data processing



1. Wstęp

Popularno ć sprzętu do przechwytywania ruchu ro nie z roku na rok. Trafia on w coraz szersze grono odbiorców szukających nowego rodzaju rozrywki. Za sprawą niskiej, przystępnej ceny oraz szerokiego kanału dystrybucji trafia on do coraz szerszego grona odbiorców, szukających nowego rodzaju rozrywki. Popularny Kinect jest innowacyjnym,

bezdotykowym interfejsem słu ącym głównie rozrywce. Przeze swoje zaawansowane mo liwo ci autorzy wykorzystują go do badania ruchu.

Przeprowadzone badania zostały wykonane w celu

sprawdzenia, czy interaktywnym d więkiem przestrzennym mo emy wpływać na człowieka i na jego zachowanie. Dodatkowym aspektem jest te fakt czy dostępne na rynku narzędzia, którymi posługujemy się na co dzień, pozwolą zbadać takie oddziaływanie. Badanie pozwoli zweryfikować tak e analizę poprawno ci działania napisanego algorytmu, który przetwarza dane o ruchu.

Badania zostały przeprowadzone na dwudziestu osobach w podobnym wieku, z ró nych grup zainteresowań. Ponad połowa zadeklarowała fakt, e grała w gry komputerowe

o tematyce wojennej.

Dla celów badawczych opracowano aplikacje w następujących językachŚ

● C#,

● Javascript.

Skrypty zostały zaimplementowane w silniku Unity. żłówne skrypty oprogramowania stworzone zostały

w technologii C#. Jest to w pełni obiektowym język stworzonym przez Andersa Hejlsberga na potrzeby .NET

w latach 1998-2001 [1]. rodowisko Unity jest narzędziem do tworzenia gier komputerowych dwuwymiarowych

i trójwymiarowych. Posiada tak e własny sklep, z którego pobierzemy niezbędne zasoby dla projektów.

Przed pomiarami osoby badane wypełniły ankiety przed badaniem o chorobach i problemach które dyskwalifikują do kontynuowania badań. Ka dy scenariusz posiadał oddzielny plik wynikowy wraz z analizą wideo.

2. Akwizycja ruchu, czyli przechwytywanie ruchu

trójwymiarowego.

Przechwytywanie ruchu (Motion Capture) jest procesem

polegającym na rejestrowaniu ruchu obiektów lub ludzi. Znalazł on swoje zastosowanie w armii, rozrywce, sporcie oraz medycynie, stosowany jest równie przy uwierzytelnianiu

widzenia komputerowego i w robotyce. W bran y filmowej i gier wideo odnosi się do zapisywania ruchu aktorów i u ywania uzyskanych informacji do tworzenia animacji postaci w 2D lub 3D. żdy proces skupia się na ruchach twarzy, palców, albo przechwytuje delikatne zmiany

w mimice, często okre la się go mianem przechwytywania performance (ang. performance capture). W wielu dziedzinach

przechwytywanie ruchu często nazywane jest ledzeniem ruchu (ang. motiontracking), jednak w bran y filmowej i gier, termin ten odnosi się bardziej do techniki zwanej


115

matchmoving, umo liwiającej realistyczne wprowadzenie obiektów grafiki komputerowej do nagranego ju materiału filmowego [2].

Rekonstrukcja ruchu w systemach Motion Capture polega

na odtworzeniu orientacji przestrzennej ruchu ciała aktora. Jest to równoznaczne ze znalezieniem obrotów dla ka dej z ko ci, dla których mo liwie najlepiej markery wirtualne odpowiadają markerom rzeczywistym, minimalizując przy tym przyjęty wska nik błędu pomiędzy markerami [3]. Markery rzeczywiste odwzorowują realne punkty w przestrzeni, która jest pokazana w konkretnym czasie. Na owe punkty mo emy nało yć algorytm, który analizuje odległo ci odpowiednich punktów między sobą (tych, które powinny zostać ze sobą połączone, by stworzyć model człowieka). Pozwala nam to

zwizualizować, np. w rodowisku Unity, jak wyglądają połączone punkty, które zostały odczytane. Je eli sensor Kinect le odczyta daną klatkę animacji, zauwa ymy odchylenie którego z punktów. Na rysunku 1 widzimy wizualizację punktową modelu, a tak e nało one połączenia w postaci figur geometrycznych.

Rys. 1. Wizualizacja sylwetki człowieka a) Wizualizacja modelu za

pomocą kropek, b) Wizualizacja modelu za pomocą brył, c) Wizualizacja

modelu za pomocą brył i kropek


Wirtualna rzeczywisto ć jest stosunkowo innowacyjną technologią, która rozwinęła się bardzo dynamicznie w ostatnich latach. Jest u ywana w wielu aspektach naszego ycia jak np. edukacja, rozrywka i medycyna. Coraz więcej

prac naukowych i artykułów odnosi się swoimi badaniami do wirtualnej rzeczywisto ci. Spowodowane jest to du ą mo liwo cią odtworzenia warunków naturalnych nawet w ekstremalnych przypadkach. Dzięki temu mo na zwizualizować dowolny scenariusz w prawie ka dym miejscu i ka dych warunkach. Daje to nieograniczone mo liwo ci połączeń scenariuszy.

Według analizy Matta Matthewsa sensor Kinect Xbox 360 [4] stał się bardzo dochodowym biznesem dla producenta. Za niewielki koszt mo emy dostać nowoczesną technologię. Wyniki sprzeda y pokazane na wykresie samego sensora

w przeciągu 2 lat wynoszą około 20 milionów egzemplarzy. Co dało firmie Microsoft przychód na poziomie kilku milionów dolarów miesięcznie. Były to rekordowe wyniki sprzeda y w porównaniu do konkurencyjnych urządzeń dostępnych na rynku. Kinect był przełomową technologią, którą ludzie pokochali ze względu na wygodę u ytkowania (brak jakichkolwiek dodatkowych kontrolerów, jakie trzeba u ywać za pomocą dłoni).

Artykuł opisuje wytwarzanie oprogramowania poprzez ruch sensora Kinect wraz z okularami bluetooth [5] oraz

informuje o technicznej budowie sensora Kinect. Rejestracja

ruchu odbywa się za pomocą czujnika Kinect. źmiter podczerwieni emituje promienie podczerwone, które odbijają z obiektów do wykrycia przez czujnik głęboko ci IR. Wynikowy videostream jest przechwytywany przez czujnik

koloru. Mamy 3 strumienie danychŚ kolorowy strumień, strumień audio i strumień głębi. Mapa głębi przechowuje odległo ć obiektu i warto ć dla ka dego piksela. W oparciu o technologię wykrywania, głęboko ci obraz graficzny

i współrzędne dla ka dego punktu uzyskujemy połączenie szkieletowe. Informacje te mo emy wykorzystać dla naszej aplikacji do badań zachowania i lęków człowieka oraz wpłynięcie na jego pod wiadomo ć i psychikę.

W artykule o Akrofobii Erick Suyanto [6] opisuje

podej cie do badania strachu poprzez wirtualną rzeczywisto ć. Zadaniem badanego było przej cie przez linę lub most, który znajdował się na bardzo du ej wysoko ci i nie był do końca stabilny. Według badań poziom nasilania się akrofobii mo na

zmniejszyć za pomocą aplikacji. Wewnątrz ludzie mogą w bezpieczny sposób zmierzyć się ze strachem w swoim

umy le. Dodane np. prawdziwe liny (obiekty trzymane w dłoniach) pomagają zwiększać poczucie realno ci rodowiska. Autorzy wspominają, e pomaga to tak e

zmniejszyć skutki strachu. Takie badania pozwalały ludziom zniwelować strach przed spadaniem. Z kolei to pokazało, e wirtualna rzeczywisto ć wpływa tak samo bardzo na zmysł wzroku i słuchu jak realny wiat.

Dzięki firmie Microsoft otrzymali my dostęp do

oprogramowania sensora Kinect [7]. Pozwoliło to na szeroki rozwój w dziedzinach badań. Programi ci projektują scenariusze, dzięki czemu mo na stworzyć bezpieczne warunki testowe. Pozwoliło to leczyć ludzi z ró nych fobii a, tak e badać jego zachowanie.

Artykuł Żotini Patrona opisuje zachowania człowieka podczas przeprowadzonego badania. Weryfikuje on czy

badanie nale y powtórzyć, gdy badany nie pokazuje przypuszczalnych oznak boja ni. Je eli przeprowadzony scenariusz zostanie uznany jako odbiegający od faktycznego

stanu, zostanie powtórzony. Powoduje to urealnienie wyników lub weryfikację poprawno ci przewidywanego scenariusza [8].

4. Badania

W celu przeprowadzenia badań opracowano aplikację dedykowaną dla rodowiska Unity w językach C# oraz Javascript.

4.1. Środowisko badawcze

Pomieszczenie, w którym zostały przeprowadzone badania, było wytłumione, o wymiarach 5 metrów x 3 metry, ze sztucznym o wietleniem. Do d więku przestrzennego wykorzystano model gło ników Logitech Speaker System Z323 wraz z subwooferem. Osoba badania znajdowała się w centralnej czę ci pokoju, jak pokazano na rysunku 6.1. Sala zawierała komputer posiadający rodowisko Unity w wersji 5.6 oraz oprogramowanie do obsługi Kinecta w wersji 1.8. Posiada procesor Intel i7 trzeciej generacji oraz 16żB pamięci RAM. Komputer połączony był z gło nikami i odtwarzał d więk przestrzenny. Osoba badana miała zawiązane oczy


116

i nie był wymagany jest dodatkowy sprzęt do przeprowadzenia badania.

4.2. Metoda badawcza

Przed badaniem osoba badana została poinformowana

o scenariuszu badawczym, jaki zostanie przeprowadzony.

Następnie badany zostaje ustawiony na rodku pomieszczenia oraz następuje kalibracja sensora, która polega na te cie odczytu czy Kinect wykrył osobę badaną i czy cała znajduje się w zasięgu. Podczas trwania scenariusza osoba badana miała zakryte oczy. Przez cały czas trwania badania, do aplikacji dostarczone były dane odczytywane z ruchu

badanego.

4.3. Schemat przeprowadzenia badania

Badanie zostało przeprowadzone w następujących krokach:

1) Przeprowadzenie wywiadu z osobą badaną.

2) Odtwarzanie muzyki relaksacyjnej.

3) Kalibracja sprzętu dostosowana do badanego.

4) Scenariusz wilków.

5) Scenariusz strzałów.

6) Scenariusz nadje d ającego pociągu.

7) Przeprowadzenie ankiety po scenariuszach.

4.4. Scenariusze badawcze

żłównym badanym elementem był wpływ d więku przestrzennego na osoby badane i odwzorowanie ich

zachowania podczas scenariusza. Zostały przeprowadzone 2 scenariusze, które zawierają ró ne opcje przypadków. Ankieta pozwoliła uzyskać dane na temat subiektywnego odbioru własnego zachowania uczestników podczas scenariusza z wilkiem. Scenariusze zostały poprzedzone ankietą sprawdzającą mo liwo ci przystąpienia do badania. Zostały dołączone dodatkowe pytania o problemy z sercem, ADHD

oraz poziom gestykulacji podczas rozmowy. Umo liwi to lepiej skalibrować ruch oraz wyciąć czę ć ruchów, które nie powinny być zapisane jako faktyczna reakcja na scenariusz.

Pierwszym scenariuszem jest symulacja sytuacji badanego

w ciemnym lesie, gdy zbli a się niebezpieczne zwierzę. Badanie sprawdziło, czy człowiek jest w stanie uspokoić się w sytuacji stresowej. Osoba badana została zaprowadzona w pomieszczeniu na odpowiednie miejsce przed sensor

Kinect. Na początku nastąpiła konfiguracja urządzenia

poprzez test widoczno ci szkieletu na ekranie komputera. Następnie badany wykonał kilka ruchów testowych dla ustalenia odpowiedniej pozycji. Podczas przeprowadzania

badania niezbędne było zało enie opaski na oczy. Po wykonaniu tych elementów nastąpiło rozpoczęcie badania. Badanie będzie trwało około 2 minut gdzie zostaje przeprowadzony atak wilka. Sprawdzono zachowanie gdy

nasze zachowanie nie ma wpływu na zachowanie wilka.

Drugim scenariuszem sprawdzono zachowanie człowieka w sytuacji zamieszanie. Do tego celu wykorzystano

zamieszanie przypominające strzelnicę. Obiekt za plecami strzela wystrzałem przed nas a następnie wraz na osobę badano leci seria strzał z karabinu maszynowego. Strzały zostają wystrzelone tu przed osobą badaną w losowych

miejscach.

Ostatnim scenariuszem sprawdzono zachowanie człowieka podczas symulacji zbli ania się w jego kierunku du ego, niebezpiecznego obiektu. Obiektem w symulacji był rozpędzony pociąg, zbli ający się z prawej strony, wprost na badanego. Warunki badania i kroki zostały przeprowadzone jak w scenariuszu pierwszym. W tym scenariuszu osoba

badana nie znała dokładnego przebiegu badania. Badanie sprawdziło strach na gło ny obiekt poruszający się centralnie na człowieka.

Wszystkie scenariusze dostarczyły danych o ruchu badanego. Do badań zostały dołączone nagrania wideo, które pozwoliły zweryfikować dane o ruchu tam, gdzie sensor nieprawidłowo zinterpretował dane.

5. Wyniki badań

Wyniki badań zostały przeprowadzone na 20-osobowej

grupie badawczej. Większo ć z osób zadeklarowała, e gra w gry komputerowe o tematyce wojennej. Badania

zaprezentowane poni ej skupione zostały na podzieleniu człowieka na czę ci ciała i sprawdzenie którymi kończynami poruszamy w danej sytuacji zagro enia najczę ciej.

Po przeprowadzeniu scenariuszy i przeanalizowania

danych przygotowano wykresy ruchu dla poszczególnych scen w ka dej kolejnej sekundzie danego badania. Wszystkie wyniki zostały zweryfikowane pod względem poprawno ci- błędne wskazania Kinect zostały odrzucone. Za ruch, danej czę ci ciała, uznano dodatni wektor ruchuŚ długo ć, kąt obrotu, przesunięcie, obliczony przez Unity 3D.

Rys. 2. Wykres ruchu poszczególnych czę ci ciała w kolejnych sekundach scenariusza z wilkiem

Na rysunku 2 przedstawiono zbiorczo ruch daną kończyną. Faza 1 to ekspozycja osoby badanej na d więk biegającego daleko od niej wilka. Często osoba badana nie rozpoznawała jeszcze zagro enia. Żaza 2 to początek u wiadamiania sobie zagro enia. „Wirtualny agresor” wyra nie zbli a się i atakuje. Towarzyszy temu wzrost amplitudy d więku i zmiana sampla na inny – gro ne szczekanie i warczenie. Atak następuje około 1 sekundy przed wystąpieniem fazy 3. W fazie 3 osoba badana jest wyra nie przestraszona i porusza się- stara się zasłonić rękami głowę.

Rysunek 3 prezentuje zbiorczo ruch kończyn osób badanych w scenariuszu 2. W fazie 1 osoba badana słyszy d więk przeładowywanej za nią broni. Porusza się zupełnie swobodnie bez udziału adnych niepokojących bod ców. W fazie 2 następuje oddanie strzału przez „wirtualną osobę” zza pleców badanej. Wyra nie widoczne jest „drgnięcie”,


117

„skok” wywołane przestrachem. Zauwa yć mo na tak e pewne „ochłonięcie”, spadek emocji tu przed fazą 3 – padł niespodziewanie strzał, nastąpił ruch, i uspokojenie. W fazie 3 osoba badana wyra nie słyszy ostrzał z karabinu

maszynowego z linii horyzontu w jej kierunku. Strzały są oddawane w kierunku „wirtualnej osoby” zza jej pleców, ale to wła nie osoba badana znalazła się na linii strzału. Taka sytuacja wywołuje panikę co wyra nie widać na wykresie

(rys. 3) w fazie 3.

R

ys. 3. Wykres ruchu poszczególnych czę ci ciała w kolejnych sekundach scenariusza ze strzałami

Rys. 4. Wykres ruchu poszczególnych czę ci ciała w kolejnych sekundach scenariusza z pociągiem

Scenariusz z pociągiem przedstawiony na rysunku 4

wzbudził najwięcej emocji. Wirtualny pociągŚ leniwie, ale konsekwentnie zbli a się do osoby badanej. Na powy szym rysunku 4 obrazuje to faza 1. Mo na w niej zaobserwować ogólne ruchy kończynami. Żaza 2 to szybki trwający mniej ni 2 sekundy przejazd pociągu tu przy badanym. Powoduje to

wyra ny „dyskomfort” i próbę „uskoczenia”. Widoczna faza 3 to czas uspokojenia się badanego po silnym bod cu lękowym.

Rysunek 5, 6 i 7 pokazują jakimi czę ciami ciała poruszały osoby badane podczas scenariuszy. We wszystkich wykresach

przewa ają ruchy rąk. wiadczy to o najszybciej reakcji na sytuację. Osoby badane miały zakryte oczy, co sprawiało, e nie wiedziały, w którą stronę uniknąć sytuacji zagro enia. W rzeczywistym wiecie ludzie reagują tak e górnymi partiami ciała. Pokazuje to, e przygotowane scenariusze wpłynęły na psychikę badanych. Ruch głowy na rysunku 5 i rysunku 6 wskazuje, e osoby badane próbowały zasłonić ją w jaki sposób. Mózg w sytuacji zagro enia próbuje przekazać odpowiednie sygnały ciału by, uniknąć jakichkolwiek obra eń.

Rys. 5. Wykres u ywalno ci poszczególnych partii ciała w scenariuszu z wilkami

Rys. 6. Wykres u ywalno ci poszczególnych partii ciała w scenariuszu ze strzałami

Rys. 7. Wykres u ywalno ci poszczególnych partii ciała w scenariuszu z pociągiem

6. Wnioski

Problematyka poruszona w tym artykule jest popularnym

tematem do badań nad zachowaniem człowieka w warunkach stresowych. Przed badaniami spodziewano się, e najmniej prawdopodobne scenariusze (strzelanina na strzelnicy lub atak

wilka) wywołają najsilniejsze emocje – najsilniejszy ruch.

Wyniki badań pokazały jednak co innego. Sytuacja najbardziej prawdopodobna – stanie na torach kolejowych

(scenariusz 3- pociąg) wywołała największy lęk u wszystkich badanych. Ponadto sam przejazd pociągu trwający zaledwie 1,75 sekundy wywołał reakcję trwającą pomiędzy 25-tą a 28,5 sekundy, czyli 3,5 sekundy. Na tej podstawie mo na wyznaczyć inercję mię ni człowieka. Pociąg „uderzył” w badanych dokładnie w 25 sekundzie projekcji. Nadje d ał on z kierunku: prawy przód dla osób badanych. Spowodowało


118

to naturalną chęć „odskoczenia”, co widać na ruchu kończyn dolnych rysunek 7. Na pozostałych rysunkach (rys. 5 i rys. 6) ruch nóg wynosi od 2,9 do około 9,1 procent ogólnego ruchu całego ciała.

Podczas badań nie wystąpiły problemy zdrowotne. Wszystkie 20 osób badanych zostały przebadane wszystkimi zaplanowanymi (trzema) scenariuszami. adna z osób nie przerwała badania i nikt nie skar ył się na adne objawy uboczne po zakończeniu.

Literatura

[1] Pańczyk B., Badurowicz M., Programowanie obiektowe - Język C#, Politechnika Lubelska, 2013.

[2] https://www.mocap.pl/blog/motion-capture-przechwytywanie-

ruchu.

[3] Pięciak T., Pawłowski R. Wizualizacja ruchu człowieka ( Motion Capture ), In ynierowie dla Biologii i Medycyny Ś kwartalnik wykładowców i studentów in ynierii biomedycznej Ś ISSN 189709149 - 2009 nr 5, 22-27.

[4] https://www.gamasutra.com/view/news/172666/Analysis_Wher

e_do_Kinect_sales_go_from_here.php.

[5] Iliukhin V.N., Mitkovskii K.B. , Bizyanova D.A., Akopyan

A.A.: The Development of Motion Capture System Based on

Kinect Sensor and Bluetooth-Gloves, Procedia Engineering

2017, 506-513.

[6] Marchelino Suyanto E., Angkasa D., Turuga H.,

SutoyoR.:Overcome Acrophobia with the Help of Virtual

Reality and Kinect Technology, Procedia Computer Science

2017, 476-483.

[7] https://www.pcworld.pl/news/Microsoft-Kinect-zawsze-i-

wszedzie,383881.html.

[8] Patrona F., Chatzitofis A., Zarpalas D., Daras P. : Motion

analysis: Action detection, recognition and evaluation based on

motion capture data, Patern Recognition April 2018, 612-622.

https://www.sciencedirect.com/science/article/pii/S1877705817308664












JCSI 11 (2019) 119-124

WysłaneŚ 201ř-01-14


119

Analiza różnic pomiędzy szkieletami aplikacji natywnych i wieloplatformowych

Kinga Aleksandra Łobejko*


Streszczenie. Głównym celem niniejszego artykułu jest analiza różnic pomiędzy szkieletami aplikacjami natywnych i wieloplatformowych.

Położono nacisk na przedstawienie technologii, które są obecnie wykorzystywane, ich rozwój i wykorzystanie na rynku. Omówiono wybrane technologie, które umożliwiają programowanie mobilne z podziałem na języki natywne i języki wysokiego poziomu. Przedstawiono różnice pomiędzy procesami wytwarzania aplikacji mobilnych.

Słowa kluczowe: aplikacje mobilneś wieloplatformowo ćś języki natywneś języki wyższego rzędu



Analysis of the differences between frameworks of native applications and

cross-platform

Kinga Aleksandra Łobejko*


Abstract. The main purpose of the article is an analysis of differences between frameworks of native applications and cross-platform. The

emphasis was put on presenting technologies that are currently used, their development and the situation on the market. The work includes

a discussion of selected technologies used in mobile programming with division into native and high level languages. The differences between the

processes of manufacturing mobile applications were presented.

Keywords: mobile application; cross-platform; native language; high-level programming



1. Wstęp

Nowe technologie są obecne na całym wiecie. Większo ć ludzi ma dostęp do komputerów, smartfonów, tabletów i innych urządzeń wymagających obsługi programowej. Wraz z postępem technologicznym powstają też nowe rozwiązania i języki programowania.

Temat wieloplatformowo ci jest tematem coraz czę ciej pojawiającym się w artykułach naukowych. Wieloplatformowo ć jest wyzwaniem na dzisiejszym rynku

[1]. Wiodącymi platformami, jakie są rozważane przy tworzeniu aplikacji, są iOS i Android. Nie tylko różnorodno ć pod względem systemów operacyjnych jest wyzwaniem. Dodatkowym aspektem, który twórcy oprogramowania muszą wziąć pod uwagę, jest programowanie na różne rodzaje urządzeń, między innymi telefony komórkowe, tablety, telewizory, komputery pokładowe, piloty czy urządzenia ubieralne. Obserwacje rynku [1] pozwalają na wyciągnięcie wniosków, iż Internet rzeczy ma coraz większy udział w życiu użytkowników. Twórcy oprogramowania nie mogą zatem pozostać bierni. Muszą brać pod uwagę przekształcający się rynek zbytu oprogramowania. Programi ci w celu zredukowania kosztów wytwarzania oprogramowania korzystają z wieloplatformowych

zintegrowanych rodowisk programistycznych [2]. Ważnym czynnikiem jest możliwo ć wykorzystania wiedzy

programistów aplikacji webowych do tworzenia aplikacji mobilnych [3]. Rozważane są jednak również minusy tworzenia hybrydowych aplikacji. Głównymi argumentami przeciw rozwiązaniom wieloplatformowym są ograniczenia dostępu do funkcjonalno ci sprzętowych, wariacje w kwestii

do wiadczeń użytkowników czy spadek wydajno ci [3, 4]. Mówiąc o hybrydowych aplikacjach mobilnych można dostrzec pewne trendy. W Google Play, w którym znajdują się aplikacje na platformę Android można dostrzec wzrost liczby aplikacji hybrydowych, szczególnie w takich kategoriach jak finanse, medycyna, transport, biznes, styl

życia czy społeczno ci [3]. Najmniej aplikacji hybrydowych znajduje się w kategoriach: fotografia, muzyka i dźwięk, narzędzia, gry, personalizacja. wiadczy to o tym, że aplikacje wieloplatformowe zyskały popularno ć w przypadku aplikacji, które korzystają z dużych zasobów bazodanowych i wchodzą w proste interakcje z nimi.

Natomiast gdy wymagane jest sięganie do zasobów sprzętowych programi ci stawiają na natywne aplikacje [3].

Obecnie badania naukowe nie dotyczą już tylko porównania wytwarzania oprogramowania w językach natywnych i językach wyższego rzędu, a sięgają one porównań na szczeblu rodowisk pozwalających tworzyć oprogramowanie na wiele platform [2]. Artykuły naukowe poruszają również kwestię rozwoju technologii wieloplatformowych. Pomimo niewątpliwych zalet platform Xamarin czy Ionic, fala krytyki jest równie znacząca [5].


120 `

Negatywne zarzuty dotyczą między innymi odczuć użytkowników względem rozwiązań natywnych.

2. Języki wykorzystywane podczas procesu wytwarzania aplikacji mobilnych

2.1. Języki natywne

Aplikacje natywne tworzone są na konkretną platformę. Rozwiązanie takie posiada szereg zalet, do których należą m.in.Ś szybko ć działania aplikacji oraz posiadanie bezpo redniego dostępu do komponentów urządzanie mobilnego (np. akcelerometr, czujnik zbliżeniowy, aparat fotograficzny) [6]. Wadą aplikacji natywnych jest konieczno ć tworzenia osobnych wersji dla każdej platformy, co przekłada się na wydłużenie procesu wytwarzania oprogramowania.

Każda z platform posiada dedykowany język (bądź języki) programowania. W przypadku platformy iOS są to Objective-C oraz Swift, a dla platformy Android – Java

i Kotlin. Z kolei językiem dedykowanym dla platformy Windows Phone jest C#. W niniejszym podrozdziale zostaną przedstawione języki natywne dla każdej z tych trzech platform.

2.2. Języki wysokiego poziomu

Alternatywą dla wytwarzania aplikacji mobilnych za

pomocą języków natywnych są aplikacje hybrydowe. Są one tworzone z wykorzystaniem języków wysokiego poziomu (szkieletów).

Rys 1. Popularno ć szkieletów hybrydowych w pytaniach na portalu StackOverflow [7]

Na rys 1. zaprezentowano statystyki dotyczące często ci zapytań związanych z danym szkieletem do tworzenia aplikacji hybrydowych. Analizując powyższy wykres można zaobserwować kolejno ć powstawania kolejnych rozwiązań. Najstarszym szkieletem jest Apache Cordova (powstały w 2009 roku jako PhoneGap). Często ć zapytań o to rozwiązanie na portalu StackOverflow systematycznie rosła –

wzrost ten zatrzymał się około roku 2012, gdy na rynku pojawiła się alternatywa – Xamarin. Trzecim rozwiązaniem jest IONIC, który stał się tematem pytań użytkowników w 2014 roku. Najmłodszym szkieletem w zestawieniu jest React

Native. Analizując czę ć powyższego wykresu dla roku 2017 można stwierdzić, że na początku 2017 roku użytkownicy najczę ciej interesowali się najnowszym rozwiązaniem (jakim jest React Native). Drugie miejsce pod względem popularno ci zajmował Xamarin, trzecie z kolei – IONIC.

Najmniej popularnym tematem z tej grupy było najstarsze rozwiązanie – Apache Cordova.

3. Rozróżnienie procesów wytwarzania aplikacji mobilnych

3.1. Natywna aplikacja mobilna

Natywna aplikacja mobilna jest to aplikacja napisana

w językach domy lnie przeznaczonych na wybrane platformy mobilne, to znaczy dla iOS – Objective-C, Swift,

dla Androida – Java, a dla WindowsPhone/Windows – C#.

W przypadku wytwarzania oprogramowania

z wykorzystaniem języków natywnych tworzony wspólny jest projekt aplikacji, jednak realizacji odbywa się w oddzielnych zespołach programistycznych, gdyż wytwarzany kod nie może być współdzielony.

W ród popularnych, natywnych aplikacji mobilnych należy wymienić [8]Ś TechCrunch, The New York Times,

Pokemon GO.

Rozwiązanie to posiada zarówno zalety, jak i wady. Niewątpliwie mocną stroną natywnych aplikacji mobilnych jest większa wydajno ć (w porównaniu z rozwiązaniami alternatywnymi) [9]. Aplikacje tworzone z wykorzystaniem

języków natywnych (takich jak Java czy Objective-C)

działają zazwyczaj szybciej, obciążając urządzenie w mniejszym stopniu. Kolejną zaletą aplikacji natywnych jest zapewnienie szybszego dostępu do danych – jest to bardzo

istotny czynnik z punktu widzenia użytkownika produktu

[10].

Niewątpliwie mocną stroną tego podej cia jest uzyskanie pełnego dostępu do możliwo ci urządzenia, na którym działa aplikacja (obsługa funkcji wbudowanych, takich jak akcelerometr, GPS i kamera). Programi ci tworzący aplikację w języku natywnym danej platformy mają dzięki temu większe możliwo ci w kwestii funkcjonalno ci tworzonego produktu.

Kolejną zaletą tego rozwiązania jest uzyskanie większej przejrzysto ci architektury kodu aplikacji, w związku z czym zarządzanie kodem staje się łatwiejsze. W aplikacjach natywnych zazwyczaj stosowane są nowoczesne języki (Kotlin, Swift), które są dynamicznie rozwijane. Ponieważ każda platforma mobilna posiada swoje własne standardy, dlatego też aplikacje natywne posiadają zazwyczaj lepiej dostosowany user experience (do wiadczenie użytkownika). Tego rodzaju podej cie w wytwarzaniu aplikacji mobilnych wiąże się też zazwyczaj z dostępno cią lepszych narzędzi do testowania (a co za tym idzie – łatwiejszym wykrywaniem błędów, które pojawiają się w trakcie implementacji aplikacji)

[9].


121 `

Natywne aplikacje mobilne posiadają także swoje słabe strony. Po pierwsze, działają tylko w jednym systemie operacyjnym. Aby dana aplikacja działała na wielu platformach, musi ona zostać napisana w różnych językach (w języku natywnym danej platformy). Taka sytuacja rodzi

koszty – firma jest zmuszona zatrudnić większą liczbę programistów – oraz powoduje wydłużenie czasu tworzenia aplikacji. Dany programista specjalizuje się najczę ciej w jednym języku natywnym, a więc wytworzenie różnych wersji aplikacji dla różnych platform mobilnych oznacza zaangażowanie wielu zespołów programistów. Dlatego też wiele firm decyduje się na wykonanie swoich aplikacji firmowych tylko na jedną, wybraną platformę.

3.2. Hybrydowa aplikacja mobilna

Hybryda – jak sama nazwa wskazuje – jest połączeniem ze sobą dwóch różnych rozwiązań. Definicja ta występuje także w aspekcie aplikacji mobilnych. Przy budowie hybrydowej aplikacji mobilnej wykorzystuje się technologie, służące do tworzenia aplikacji internetowych, jednocze nie mając dostęp do natywnych funkcjonalno ci smartfonów. Cały ten proces może zachodzić dzięki narzędziom, które kompilują języki wyższego rzędu na języki natywne. W języku potocznym można nazwać to tłumaczeniem języka zrozumiałego dla aplikacji internetowej na język, którym posługuje się dana aplikacja mobilna.

W ród aplikacji mobilnych wytworzonych tą metodą należy wymienić [12]Ś Amazon App Store, Twitter, Apple App Store, Evernote, Instagram, Untappd, Uber, Gmail.

Rozwiązanie to umożliwia stworzenie jednej aplikacji,

która będzie działała na różnych systemach. Hybrydowe aplikacje mobilne wiążą się z ponownym wykorzystywaniem

kodu – czę ć kodu jest współdzielona, a czę ć jest tworzona z my lą o konkretnej platformie. Czynnik ten sprawia, że

w kwestii szybko ci wytwarzania aplikacji działającej na wielu platformach (wynikającej z objęto ci tworzonego kodu) aplikacje hybrydowe górują nad aplikacjami stworzonymi z użyciem języków natywnych (w których wytwarzanie aplikacji na różne systemy wiąże się z tworzeniem kodu w językach dedykowanych dla danej platformy, a więc brakiem możliwo ci ponownego wykorzystania kodu).

Można wyróżnić dwa główne sposoby tworzenia hybrydowych aplikacji mobilnych. Pierwszy z nich polega na

wykorzystaniu języka JavaScript oraz odpowiednich

szkieletów, które – za pomocą wtyczek – pozwolą na dostęp do natywnych funkcji. Takie rozwiązanie osłabia jednak wydajno ć aplikacji. Drugi sposób związany jest natomiast z użyciem platform, które zostały oparte o bardziej natywne komponenty (przykładami sąŚ Xamarin oraz React Native). Platformy te korzystają ze współdzielonej warstwy widoku

oraz natywnych komponentów. Ponieważ komponenty te tworzone są w językach dedykowanych dla danej platformy, skutkuje to uzyskaniem wyższej wydajno ci (w porównaniu ze sposobem pierwszym) [9].

W ród zalet hybrydowych aplikacji mobilnych należy wymienić m.in. uzyskanie oszczędno ci zasobów –

wytworzenie tego rodzaju aplikacji nie wymaga

zaangażowania osobnych zespołów programistycznych dla każdej platformy, na której będzie działać aplikacja. Dzięki takiemu podej ciu skraca się również czas wytworzenia aplikacji – budowanie interfejsu użytkownika z wykorzystaniem technologii internetowych nierzadko

okazuje się szybsze i łatwiejsze.

Hybrydowe aplikacje mobilne posiadają jednak także wady. Nie wszystkie szkielety stosowane w tym rozwiązaniu bezproblemowo radzą sobie z obsługą wbudowanych funkcji urządzenia (kwestia ta wygląda dużo lepiej w przypadku języków natywnych). Tego rodzaju aplikacje mogą również

okazać się wolniejsze (ponieważ kod nie zawsze jest kompilowany do kodu napisanego z wykorzystaniem języka natywnego). W porównaniu z aplikacjami natywnymi, aplikacje hybrydowe posiadają zazwyczaj mniej dopasowany user experience (ponieważ nie są tworzone dla konkretnej

platformy, tak więc konwencje mogą zostać uogólnione, przez co mogą odbiegać od konwencji danej platformy). Innymi słabszymi stronami tego rodzaju rozwiązania są częste zmiany w ekosystemie języka JavaScript oraz mniejszy potencjał do rozwoju aplikacji [9].

4. Progressive web app (PWA)

Progressive web app [13] (PWA) są to aplikacje internetowe, które uruchamiają się tak jak zwykłe strony internetowe [4] jednak wyglądają jak natywne aplikacje mobilne [13], co sprawia, że są przyjazne dla użytkownika.

Jest to szczególnie atrakcyjne dla osób, które nie decydują się na wyszukiwanie aplikacji w sklepie, pobieranie jej

i instalowanie ze wiadomo cią, iż będzie użyta raz czy dwa razy. Statystycznie 4ř% użytkowników nie instaluje żadnej aplikacji w ciągu miesiąca [12]. Można zatem stwierdzić, że prawie połowa osób nie skorzysta z reklamujących się aplikacji. Według „The 2016 U.S. Mobile App Report” [12]

użytkownicy korzystają z jednej ulubionej aplikacji przez większo ć czasu.

Jednocze nie znacznie chętniej użytkownik wejdzie na stronę internetową przez urządzenie mobilne. Dlatego też reklama stron i usług internetowych rozwinęła się adekwatnie do obecnych czasów i odpowiada na potrzeby konsumentów wykorzystując w tym celu PWA.

PWA są instalowane na głównym ekranie użytkownika bez potrzeby pobierania aplikacji ze sklepu z aplikacjami.

Aplikacje mogą wykorzystywać powiadomienia jak aplikacje natywne. Dużą zaletą PWA jest szybkie załadowanie zawarto ci. Aplikacje uruchamiają się natychmiast –

niezależnie od jako ci połączenia internetowego. Na przestrzeni lat można dostrzec, iż wszystkie wymienione zalety zdecydowanie trafiają do użytkowników, co potwierdza rys. 2. Mobilne strony internetowe mają 4.5 razy więcej odwiedzin z aplikacji typu PWA niż z natywnych aplikacje mobilne, a także wzrost odwiedzin w przeciągu roku jest znacznie wyższy (o 2ř punktów procentowych)

[12].


122 `

Rys. 2. Liczba odwiedzin aplikacji internetowych, mobilnych aplikacji

internetowych i aplikacji mobilnych oraz porównanie warto ci w przeciągu roku [12]

Jedną z najważniejszych cech progresywnych aplikacji internetowych jest działanie w trybie offline. Jest to aspekt różniący PWA od zwykłych aplikacji internetowych, które w przypadku braku połączenia z siecią Internet nie wy wietlają użytkownikowi nawet czę ci interfejsu bądź danych. Progresywne aplikacje internetowe w tej kwestii

przypominają aplikacje natywne, które nawet w trybie offline są w stanie wy wietlić użytkownikowi tre ć (np. listę newsów pobranych podczas ostatniej wizyty w aplikacji). Ich działanie w trybie offline może sprowadzać się do wy wietlenia odpowiedniego komunikatu lub wy wietlenie danych pobranych w czasie, gdy aplikacja posiadała połączenie z siecią [14].

Elementem umożliwiającym wzbogacenie aplikacji o tego rodzaju działanie w trybie offline jest Service Worker

API. Pozwala on programi cie na okre lenie, które zasoby aplikacji zostaną zapisane do pamięci podręcznej, a które wymagają połączenia z siecią Internet. Dzięki takiej możliwo ci aplikacja jest w stanie wy wietlić użytkownikowi najważniejsze tre ci nawet w trybie offline.

Innym elementem, o który można uzupełnić aplikację dzięki Service Worker API są tzw. push notifications. Jest to

rodzaj komunikatów, które mogą być wy wietlane nawet wtedy, gdy aplikacja nie jest otwarta [15]. Service Worker

API pozwala także na zaimplementowanie w aplikacji Background Sync (API umożliwiające odraczanie działań, dopóki użytkownik nie uzyska stabilnego połączenia z siecią) [16].

Ważnym elementem progresywnej aplikacji internetowej

jest plik manifest.json, przechowujący informacje dotyczące opisu aplikacji. Za pomocą tego pliku można zdefiniować m.in. lokalizacje ikon aplikacji, jej nazwę oraz kolory interfejsu przeglądarki i urządzenia mobilnego w momencie uruchamiania aplikacji. Ciekawą opcją jest możliwo ć ustawienia trybu „standalone” (w trybie tym interfejs przeglądarki zostaje ukryty – użytkownik odnosi wrażenie natywno ci uruchomionej aplikacji) [14].

Google opublikowało tzw. Progressive Web App

Checklist [17], będący wykazem cech, które powinna spełniać aplikacja internetowa, żeby mogła być uznana za progresywną aplikację internetową. Zostały one podzielone na dwie grupy, które uznać można zaŚ podstawowy poziom

wymagań (Baseline Progressive Web App Checklist) oraz

rozszerzony poziom wymagań (Exemplary Progressive Web

App Checklist). W ród wymagań poziomu podstawowego znajdują się m.in. następujące cechyŚ

aplikacja internetowa jest serwowana przez HTTPS

(zapewnione bezpieczeństwo danych), strony aplikacji są responsywne na tabletach

i urządzeniach mobilnych, wszystkie adresy URL aplikacji ładują się w trybie offline

(a więc aplikacja działa nawet wtedy, gdy urządzenie nie ma połączenia z siecią Internet),

obecno ć metadanych pozwalających na dodanie skrótu aplikacji do ekranu startowego (umożliwia to plik manifest.json),

aplikacja wczytuje się szybko nawet w przypadku wolniejszych połączeń (np. 3G),

aplikacja internetowa działa poprawnie w różnych przeglądarkach (Chrome, Edge, Firefox, Safari, itp.),

wszystkie przej cia i animacje są płynne, nie sprawiają one wrażenia, jakby aplikacja blokowała się z powodu wolnego (lub braku) połączenia z siecią Internet –

aplikacja szybko reaguje na działania użytkownika, ekrany aplikacji zmianiają się sprawnie,

każda strona aplikacji posiada swój adres URL. Rozszerzona lista wymagań obejmuje między innymi

następujące wymaganiaŚ tre ć aplikacji (strony) jest indeksowana przez Google, strony używają History API, tre ć strony nie sprawia wrażenia „skakania” w trakcie

ładowania, pola formularza nie są zasłaniane przez klawiaturę

ekranową w momencie ich aktywowania (poprzez dotknięcie),

aplikacja jest responsywna na telefonach, tabletach oraz

urządzeniach desktopowych.

W ród zalet progresywnych aplikacji internetowych należy wymienić fakt, że aplikacje tego typu uruchamiają się na każdej platformie (nie ma potrzeby tworzenia osobnych wersji aplikacji dla urządzenia mobilnego i urządzenia desktopowego – PWA będzie działać na każdej z tych platform). Drugą mocną stroną PWA jest łatwo ć aktualizacji (w przypadku aplikacji mobilnych - udostępnianych np. przez sklep z aplikacjami dostępny w systemie urządzenia – proces

ten jest często wieloetapowy i długotrwały). Aktualizacja progresywnej aplikacji internetowej sprowadza się do wykonania aktualizacji plików na serwerze, a użytkownik podczas kolejnego uruchomienia tej aplikacji automatycznie

otrzyma jej najnowszą wersję. Wybranie tego podej cia pozwoli również na redukcję kosztów, rozwiązując kwestię zatrudnienia programistów mobilnych. Ostatnią zaletą PWA jest wygoda korzystania z tego typu aplikacji – użytkownicy są w stanie uruchomić i korzystać z tego rodzaju aplikacji na każdej platformie [14].

Progresywne aplikacje internetowe posiadają również swoje słabsze strony. Ponieważ aplikacje te wykorzystują do

swojego działania przeglądarki mobilne, tak więc niektóre funkcjonalno ci PWA mogą działać w różny sposób na różnych przeglądarkach (albo w ogóle nie funkcjonować).


123 `

Niektóre funkcjonalno ci telefonu nie są dostępne za po rednictwem WEB API, co w pewien sposób ogranicza twórców progresywnych aplikacji internetowych [14].

5. Porównanie procesów wytwarzania aplikacji mobilnych

Aplikacje natywne posiadają przewagę nad aplikacjami hybrydowymi w kwestii wydajno ci. Podobnie przedstawia się kwestia dostępu do funkcji wbudowanych urządzenia mobilnego (czujniki, GPS, aparat) – dostęp do tych elementów za po rednictwem języków natywnych jest łatwiejszy. Aplikacje natywne dysponują także lepszymi narzędziami służącymi do testowania, w związku z czym w przypadku tego rodzaju aplikacji wykrywanie błędów staje się łatwiejsze i szybsze.

Aplikacje hybrydowe posiada przewagę nad podej ciem natywnym w wytwarzaniu aplikacji mobilnych w przypadku

oszczędno ci zasobów. Do stworzenia aplikacji hybrydowej wymagane jest zaangażowanie jednego zespołu programistycznego. W przypadku aplikacji natywnych, nad

wersjami aplikacji na różne platformy pracują zazwyczaj różne zespoły programistyczne.

Podejmując decyzję dotyczącą wyboru między podej ciem natywnym i hybrydowym, należy rozważyć również inne kwestie. Pierwszą z nich jest kwestia budżetu –

w tym przypadku wytworzenie aplikacji hybrydowej będzie wiązało się z mniejszymi wydatkami. Wynika to z braku

konieczno ci zatrudnienia wielu zespołów programistycznych (w przypadku aplikacji natywnej zazwyczaj różne wersje aplikacji wymagają zaangażowania nowego zespołu programistycznego, skupiającego się na danej platformie). W przypadku aplikacji hybrydowych, duża czę ć kodu jest współdzielona.

Kolejną kwestią jest wykorzystanie funkcji natywnych w aplikacji. W tym przypadku lepszą decyzją wydaje się być wybranie podej cia natywnego. Aplikacja wytworzona w języku natywnym danej platformy zazwyczaj będzie lepiej spełniała funkcje związane z dostępem do funkcji wbudowanych urządzenia – w przypadku aplikacji

hybrydowej, niektóre, bardziej zaawansowane funkcjonalno ci mogą okazać się niedostępne lub trudniejsze w implementacji (w porównaniu z aplikacją natywną).

Rozważając sposób wytwarzania aplikacji mobilnej warto również wziąć pod uwagę do wiadczenie użytkownika (user

experience). W tym przypadku przewagą wykazują się aplikacje natywne. Stworzenie aplikacji na konkretną platformę wiąże się z przestrzeganiem pewnych konwencji

ustalonych przez nią (np. w przypadku Google będzie to Material Design). Konwencje w aplikacjach hybrydowych są zazwyczaj bardziej uogólnione, ponieważ ta sama aplikacja będzie działać na różnych platformach.

Należy zastanowić się również nad tym, czy aplikacja może zostać wprowadzona na poszczególne platformy w sposób sekwencyjny. Je li odpowiedź na to pytanie jest twierdząca, wtedy aplikacja natywna może okazać się

lepszym wyj ciem. Aplikacja hybrydowa będzie miała przewagę nad podej ciem natywnym w sytuacji, gdy produkt powinien być wprowadzony jednocze nie na wszystkie platformy – w przypadku aplikacji natywnej wymagałoby to jednoczesnego zatrudnienia osobnych zespołów programistycznych, którzy w tym samym czasie pracowaliby nad wersjami aplikacji na różne platformy. Sekwencyjne realizowanie kolejnych wersji aplikacji (w przypadku

podej cia natywnego) ma również tę zaletę, że programi ci realizujący kolejne wersje mają dostęp do wersji już stworzonych (a więc mogą korzystać z do wiadczenia programistów, którzy już pracowali nad tą aplikacją).

W przypadku chęci szybkiego wej cia na rynek lepszą opcją jest aplikacja hybrydowa. Wynika to z szybszej implementacji aplikacji, która jest od razu dostępna na wielu platformach (bez konieczno ci tworzenia różnych wersji aplikacji, jak ma to miejsce w przypadku aplikacji

natywnych).

Ostatnią kwestią jest rodzaj urządzeń, na których będzie działać aplikacja. Je li ma być ona uruchamiana nie tylko na telefonach, ale także na takich urządzeniach jak telewizory i zegarki, wtedy lepszym rozwiązaniem jest aplikacja natywna. Podej cie to wynika z trudniejszego dostępu do funkcji natywnych w przypadku aplikacji hybrydowych.

6. Wieloplatformowość

Wieloplatformowo ć jest szerokim pojęciem, które może dotyczyć nie tylko oprogramowania, ale również języków programowania i systemów operacyjnych. W przypadku

aplikacji, pojęcie to oznacza, że aplikacja działa na wielu (co najmniej dwóch) systemach operacyjnych i architekturze komputera.

Dzięki hybrydowym aplikacjom mobilnym można mieć do czynienia z wieloplatformowo cią. Kod jest pisany w jednym języku z wykorzystaniem jednego narzędzia, a stworzona aplikacja działa na wielu platformach. Zazwyczaj

dotyczy to systemów iOS, Android i Windows. O wieloplatformowo ci można również mówić w przypadku

progresywnych aplikacji internetowych (PWA). Aplikacje te

nie wymagają konieczno ci tworzenia osobnych wersji aplikacji na różne platformy – od strony kodu są aplikacjami internetowymi, wzbogaconymi m.in. o działanie w trybie offline i tzw. push notifications.

7. Wnioski

W obecnych czasach urządzenia mobilne są wszechobecne. Zarówno w prywatnym życiu jak i zawodowym. Zwiększone zapotrzebowanie na urządzenia mobilne ma ogromny wpływ na rozwój nowych rozwiązań w zakresie oprogramowania. Urządzenia bez odpowiedniego oprogramowania nie są przydatne. Pierwotne rozwiązania jak języki natywne zostają powoli wypierane na rzecz nowych technologii. Powodem jest duże zróżnicowanie urządzeń wykorzystywanych przez konsumentów i nacisk na skrócenie czasu wytwarzania aplikacji przy ograniczeniu kosztów.


124 `

Literatura

[1] Majchrzak T. A., Rieger C.: Weighted Evaluation Framework

for Cross-Platform App Development Approaches,

EuroSymposium on Systems Analysis and Design, September

2016, DOI: 10.1007/978-3-319-46642-2_2

www.researchgate.net/publication/308495821 [09.12.2018]

[2] Goetz J., Li Y..: Evaluation of Cross-Platform Frameworks for

Mobile Applications, September 2018,

www.researchgate.net/publication/329488825_Evaluation_of_

Cross-Platform_Frameworks_for_Mobile_Applications

[09.12.2018]

[3] Malavolta I., Soru T., Terragni V.: End Users' Perception of

Hybrid Mobile Apps in the Google Play Store, Mobile Services

(MS), 2015 IEEE International Conference on, August 2015,

[09.12.2018]

[4] E. Masi, G. Cantone, M. Mastrofini, G. Calavaro, P. Subiaco:

Mobile apps development: A framework for technology

decision making. In Mobile Computing, Applications, and

Services, Springer, 2013.

[5] Bi rn-Hansen A., Majchrzak T. A., Gr nli1 Tor-Morten:

Progressive Web Apps for the Unified Development of Mobile

Applications, 2018, [09.12.2018]

[6] Rodzaje aplikacji mobilnych, www.biznesport.pl/blog/rodzaje-

aplikacji-mobilnych/ [05.01.2019]

[7] Robinson D.: Exploring the State of Mobile Development with

Stack Overflow Trends.

www.stackoverflow.blog/2017/05/16/exploring-state-mobile-

development-stack-overflow-trends/ [08.01.2019]

[8] Saccomani P.: Native Apps, Web Apps or Hybrid Apps?

What’s the Difference? www.mobiloud.com/blog/native-web-

or-hybrid-apps/ [08.01.2019]

[9] Winkler M.: Native vs Hybrid – jaki rodzaj aplikacji mobilnej

wybrać. www.appchance.pl/blog/native-vs-hybrid-jaki-rodzaj-

aplikacji-mobilnej-wybrac/ [07.01.2019]

[10] Golan M.Ś Mobilna aplikacja internetowa czy natywna? A może hybryda? www.golan.pl/aplikacje-natywne-internetowe-

hybrydowe/ [07.01.2019]

[11] Harbuz M.: Czym jest aplikacja hybrydowa? www.x-

coding.pl/blog/developers/czym-jest-aplikacja-hybrydowa/

[08.01.2019]

[12] comScore, Inc: The 2016 U.S. Mobile App Report. comScore,

Inc. 2016.

[13] Alter T.Ś Building Progressive Web Apps. O’Reily Media, Inc., 2017.

[14] Suchodolski P.: PWA (Progressive Web App) – pierwsze kroki.

www.sunscrapers.com/blog/pwa-pierwsze-kroki/ [07.01.2019]

[15] Archibald J.: Introducing Background Sync.

www.developers.google.com/web/updates/2015/12/background

-sync [07.01.2019]

[16] Gauntt M.: Adding Push Notifications to a Web App.

www.developers.google.com/web/fundamentals/codelabs/push-

notifications/ [07.01.2019]

[17] Progressive Web App Checklist. www.developers.google.com/

web/progressive-web-apps/checklist [08.01.2019]

JCSI 11 (2019) 125-130 WysłaneŚ 2018-11-28 PrzyjęteŚ 2018-12-06

125

Porównanie możliwo ci tworzenia aplikacji PHP na przykładzie Yii2 i Laravel Olena Sydorchuk*


Streszczenie. W pracy przedstawiono wyniki porównania możliwo ci tworzenia aplikacji internetowych w technologii PHP na przykładzie popularnych platform programistycznych Yii2 i Laravel. Badania zostały zrealizowane poprzez implementację dwóch aplikacji o takiej samej funkcjonalno ci, korzystającej z tej samej bazy danych. W obu technologiach porównano strukturę aplikacji, elementy tworzenia interfejsu graficznego, wybrane metryki kodu oraz efektywno ć pracy z bazami danych. W podsumowaniu wskazano najważniejsze wady i zalety obu rozwiązań.

Słowa kluczowe:Yii2; Laravel;PHP; frameworki



Comparison of PHP applications development using the Yii2 and Laravel examples

Olena Sydorchuk*


Abstract.The paper presents the results of comparison of the possibilities of creating web applications in PHP technology on the example of popular programming platforms Yii2 and Laravel. The research was carried out by implementing two applications with the same functionality using the same database. In both technologies, the application structure, elements of creating the graphical interface, selected code metrics and efficiency of working with databases were compared. The summary indicates the most important advantages and disadvantages of both solutions..

Keywords:Yii2; Laravel; PHP; frameworks.



1. Wstęp W warunkach szybkiego rozwoju technologii

informacyjnych i szybkiej ewolucji systemów zarządzania informacją, najbardziej aktualne z zadań, które nieustannie występują przed twórcami aplikacji, to wybór podej cia do tworzenia interfejsu i przyspieszenia kodowania. Podczas tworzenia aplikacji, deweloperzy często projektują interfejs, za pomocą specjalnych narzędzi do projektowania, przeciągając zestaw składników lub elementów sterowania na powierzchnię projektową [1].

Ze względu na olbrzymią konkurencję pomiędzy aplikacjami o podobnym zakresie funkcjonalno ci, użytkownik wybierze tę, która będzie bardziej intuicyjna i przyjazna. A programista w prostszy sposób będzie w stanie zmienić interfejs oraz wspierać aplikację.

Do wyboru jest wiele różnych podej ć, frameworków, bibliotek, narzędzi dla różnych języków programowania. Ich nowe wersje pojawiają się na rynku nawet kilka razy w ciągu roku.

2. Cel badań

Celem niniejszego artykułu jest porównanie dwóch, stosunkowo nowych, konkurencyjnych frameworków - Yii2 i Laravel. Obie platformy wspierają proces implementacji aplikacji webowych w PHP.

Postawiono następującą tezęŚ

Platforma programistyczna Laravel jest bardziej przyjazna

dla początkującego programisty aplikacji webowych w stosunku do platformy Yii2.

3. Wybrane możliwości Yii2 i Laravel

Zaletą korzystania z dowolnego frameworka jest Ś

korzystanie ze standardowego sposobu rozwiązania zadań, co minimalizuje nieczytelno ć koduś

stosowanie gotowych rozwiązań do tworzenia i walidacji formularzy oraz standardowe ich zabezpieczenia;

łatwo ć pisania kodu z użyciem sprawdzonej architektury i metod;

aktywna społeczno ć, która pomaga w rozwiązywaniu pojawiających się problemówś

Stosowanie frameworka nie jest jednak wolne od wad:

pakiet frameworka, powoduje obciążenie serwera, co może stanowić poważny problem. Na szczę cie dostępne są opcje buforowania, które zmniejszają wpływ przeciążenia, a dla aplikacji korporacyjnych można użyć natywnego kodu SQL, aby zminimalizować czas wykonania zapytania. Dlatego problem przeciążenia serwera nie uniemożliwia korzystanie z niego;

praca z ogromną ilo cią generowanego automatycznie kodu, wymaga zrozumienia i do wiadczenia w pracy z frameworkiem;


126

Pomimo wskazania kilku wad - o wiele trudniej jest napisać od zera własny system. Zastosowanie frameworka w celu zaimplementowania rozbudowanego projektu z modułem użytkownika i administratora – jest niewątpliwie dobrym rozwiązaniem.

W tabeli 1 przedstawiono podstawowe wła ciwo ci obu analizowanych platform programistycznych. W kwestii związanej z rozwojem i ciągłym unowocze nianiem frameworków, wyraźną przewagę ma Laravel. Framework ten jest na bieżąco aktualizowany. Niemalże każdego roku wychodzą nowe wersje, które mają nowe możliwo ci, zwiększające jego konkurencyjno ć[1].

Tabela 1. Wła ciwo ci frameworków

Właściwości Yii2 Laravel

Aktualna wersja Yii 2.0.15 (marzec, 2018)

Laravel 5.6 (luty, 2018)

Data wprowadzenia

12 pażdziernika 2014 9 czerwca 2011

Strona domowa projektu

https://www.yiiframework.com/

https://laravel.com/

Twórca QiangXue Taylor Otwell

Język programowania

PHP PHP

rodowisko programistyczne

NetBeans, PHP Storm, Zend Studio

NetBeans, PHP Storm, IntelliJ IDEA

Generacja widoku wspomagana przez IDE

Nie posiada takiej możliwo ci

Jest możliwo ć generacji widoku z kontrolera dla jego wybranej metody

Instalacja bibliotek

Możliwo ć podłączenia bibliotek innych firm

Możliwo ć podłączenia bibliotek innych firm

Społeczno ć (listy dyskusyjne, grupy wsparcia itp.)

https://forum.yiiframework.com; https://www.yiiframework.com;

http://laravel.org.pl; https://plus.google.com/communities/106838454910116161868; https://www.wykop.pl/tag/laravel/

Wielko ć [MB] 30 MB 16 MB

Obsługiwane bazy danych

MySQL, PostgreSQL, SQLite, SQL Server i Oracle, MongoDB

MySQL, PostgreSQL, SQLite i SQL Server, MongoDB

Stosowany ORM Active Record Eloquent

Routing - przykład

use yii\helpers\Url; $url = Url::to(['site/view','id' => 1]);

Route::get('funckja', function () { return 'Witaj ';});

Architektura MVC MVC

Silniki szablonów Twig, Smarty Blade

Licencja GFDL MIT

W tabeli 2 przedstawiono podstawowe wady i zalety obu rozwiązań.

4. Aplikacja testowa

W celu przeprowadzenia porównania zostały utworzone dwie aplikacje testowe o tej samej funkcjonalno ci, współpracujące z tą samą bazą danych MySQL [2]. Aplikacja oferuje możliwo ć rejestracji i uwierzytelniania użytkownika w celu skorzystania z oferty wypożyczenia pojazdu dwukołowego (skuter, rower).

W panelu użytkownikawy wietlają się informacje o wiadomo ciach od innych użytkowników systemu, o czasie, na który jest wypożyczony pojazd itp.

Tabela 2. Najważniejsze wady i zalety frameworków

Właściwości Yii2 Laravel

Zalety Łatwo ć nauczenia się tworzenia prostego projektu;wiele wbudowanych rozwiązań dla interfejsówś doskonały generator modeli, kontrolerów i akcji CRUD;kompletny zestaw narzędzi do uproszczonego wdrażania RESTfull API.

Wbudowany kolektor skryptów i scssś wbudowany korektor szablonów Bladeś bardzo elastycznyrouting;elastyczne możliwo ci pisaniaś interfejsu REST API; szybko rozwija się.

Wady Mało elastyczny routing; bardzo rzadko pojawiają się nowe wersje; zbyt mało rozdzielonyfrontend i backend.

Duża liczba klas działa poprzez funkcje wspomagająceś trudniejszy do nauki w porównaniu do Yii2 (subiektywna ocena autorki); brak oficjalnej dokumentacji w języku rosyjskim (z wiedzy autorki), brak wbudowanych generatorów interfejsów.

Aplikacja współpracuje z relacyjną bazą danych MySQL [2]. Model struktury bazy przedstawia rys. 1.

Rys. 1. Graficzna reprezentacja diagramu ERD

Strona główna aplikacji dla zalogowanego użytkownikaprzedstawiona jest na rysunku 2.

5. Elementy implementacjiaplikacji testowej

5.1. Yii

Aplikacja Yii jest zorganizowana zgodnie z wzorcem architektonicznym model-widok-kontroler (MVC). Modele reprezentują dane, zasady sprawdzania poprawno ci ilogikę biznesową, widoki odpowiadają za wy wietlanie informacji związanych z modelem, kontrolery przyjmują dane wej ciowe i konwertują je na polecenia dla modeli i widoków.

W Yiido tworzenia modeli dla tabel wykorzystano generator kodu GII [7] (Rys. 3).

https://forum.yiiframework.com/

https://forum.yiiframework.com/



http://laravel.org.pl/

https://www.wykop.pl/tag/laravel/

https://www.wykop.pl/tag/laravel/


127

Rys. 2. Strona główna aplikacji testowej

Rys. 3. Generator kodu dodawania nazwy tabeli (Table_Name)

AccessControl jest filtrem akcji, która dopasowuje podaną cieżkę do odpowiedniego kontrolera i jego metody (akcji).

.Przykład 1 przedstawia podłączenie modeli w danym kontrolerze.

Przykład 1. Dodanie modeli do kontrolera

use app\models\ContactForm; use app\models\Uzytkownik; use app\models\LoginForm; use app\models\MailerForm; class SiteController extends Controller {

public function actions() { return [ 'error' => [ 'class' => 'yii\web\ErrorAction', ], 'captcha' => [ 'class' => 'yii\captcha\CaptchaAction', 'fixedVerifyCode' => YII_ENV_TEST ? 'testme' : null, ], ]; } }

W aplikacjach internetowych, widoki są zwykle tworzone za pomocą szablonów, zarządzanych przez komponent widoku aplikacji. Formularze generowane jako widoki w Yii oferują prostą możliwo ć wprowadzenia walidacji za po rednictwem modelu (Przykład 2).Rysunek 4 przedstawia widok strony z formularzem.

Przykład 2. Walidacja w modelu w Yii (Rys. 6)

public function rules() { return [ ['nazwa_urzadzenia', 'required', 'message' =>

'Wybierz rodzaj urzadzenia'], ['miasto_urzadzenia','required', 'message' => 'Wpisz miasto'], ['ulica_urzadzenia', 'required', 'message' => 'Wpiszulice'], ['cena_dobe', 'required', 'message' =>

'Wpisz cene za dobe'], ['data_od_kiedy','required', 'message' =>

'Wpisz date od kiedy wypozyczasz'], ['data_do_kiedy', 'required', 'message' => 'Wpisz date do kiedy wypozyczasz'], ['kaucja', 'required', 'message' => 'Wpiszkaucje'], ['opis', 'safe'], ]; }

Rys. 4. Widok strony z formularzem

Przykład 2 przedstawia walidacjęw modeludla danych z rysunku 4.

Nawigacja na stronie ma postać menu szybkiego dostępu (Przykład 3). Listing 3. Fragment widoku z nawigacją w Yii

//strony, które zawsze będą widoczne <li><a href="<?= Url::to(['/reservation/index']); ?>">Regulamin</a></li> <li><a href="<?= Url::to(['/reservation/devices']); ?>">Urzadzenia</a></li> //jeśli użytkownik nie jest zalogowany <?phpif (Yii::$app->user->isGuest): ?> <li><a href="<?= Url::to(['/reservation/exposure']); ?>">Wystawić</a></li> <li><a href="<?= Url::to(['/site/register']); ?>">Rejestracja</a></li> <li><a href="<?= Url::to(['/site/login']); ?>">Logowanie</a></li> <?phpelse: ?>// jeżeli użytkownik jest zalogowany <li class="menu-with-dropdown"> <a href="#">Możliwości</a> <div class="dd-holder"> <div class="dd-t"></div> <div class="dd"> <ul> <li><a href="<?= Url::to (['/reservation/rentinging']); ?>">Masz wynajmowane</a></li> <li><a href="<?= Url::to(['/reservation/devided']); ?>">Maszpozyczone</a></li>

Dodatkowy zasóbAssetsw Yii, jest to plik, który może

być użyty na stronie internetowej. Może to być plik CSS, plik JavaScript, obraz bądź plik wideo itp. Rejestracja zestawu zasobów w widoku,powoduje automatyczne dołączenie do strony arkuszy CSS i JavaScript (Przykład 4). Przykład 4. Dołączenie plików CSS i JavaScript w Yii

class AppAsset extends AssetBundle { public $basePath = '@webroot'; public $baseUrl = '@web'; public $css = [ 'css/style.css',

128

'css/ie6.css', 'js/slick/slick.css',

'js/slick/slick-theme.css', ]; public $js = [ 'js/slick/slick.min.js', 'js/js-func.js', 'js/png-fix.js', ]; }

5.2. Laravel

Aplikacje Laravel są zgodne z tradycyjnym wzorcem projektowym MVC[3], w którymŚ kontrolery obsługują żądania użytkowników i pobierają

dane za po rednictwem modeli;

modele są stosowane do interakcji z bazą danych i pobierania informacji o obiektach;

widoki służą do renderowania stron.

Dodatkowo, trasy służą do mapowania adresów URL do wyznaczonych działań kontrolerów.Modele zazwyczaj znajdują się w folderze app, ale można je umie cić w dowolnym miejscu, co okre lone jest w pliku konfiguracyjnym composer.json. Wszystkie modele dziedziczą po klasieIlluminate\Database\Eloquent\Model.

Najłatwiejszym sposobem utworzenia szablonu modelu jest użycie w konsoli polecenia artisanmake:model.

Widoki stron w aplikacji testowej w przeglądarce wyglądają niemal identycznie (zastosowane zostały te same arkusze CSS i skrypty JS). Przykład 5 przedstawia walidacjęw modeluobsługującymiwypożyczenia.

Przykład5. Fragment modelu z walidacją w Laravel

protected function rules() { return [ 'nazwa_urzadzenia' => 'required', 'miasto_urzadzenia' => 'required', 'ulica_urzadzenia' => 'required', 'opis' => 'required', 'cena_dobe' => 'required', 'data_od_kiedy' => 'required', 'data_do_kiedy' => 'required', 'kaucja' => 'required', ]; } }

Fragment kodu z elementem nawigacji w Laravel prezentuje przykład 6. Obiekty tworzące menu zostały dodane do pliku widoku w folderze./views/layouts/app.blade.php.

Przykład 6. Fragment widoku z nawigacją w Laravel

<div id="header"> <div class="shell"> <h1 id="logo" class="notext"> <a href="/">SzybkieKolo</a></h1> <div id="navigation"> <ul> <li><a href="{{url('/reservation/index')}}">Regulamin</a></li> <li><a href="{{url('/reservation/devices')}}">Urzadzenia</a></li> @if(!Auth::user())

<li><a href="{{url('/reservation/exposure')}}">Wystawić</a></li> <li><a href="{{url('/register')}}">Rejestracja</a></li>

<li><a href="{{url('login')}}">Logowanie</a></li> @else

<li class="menu-with-dropdown"> <a href="#">Możliwości</a> <div class="dd-holder"> <div class="dd-t"></div> <div class="dd"> <ul> <li><a href="{{url('/reservation/rentinging')}}"> Masz wynajmowane</a></li> <li><a href="{{url('/reservation/devided')}}"> Masz pozyczone</a></li> <li><a href="{{url('/reservation/exposure')}}"> Wystawić urządzenie</a></li>

W tym samym pliku, w celu dołączenia reguł CSS i JS należy dodać kilka wierszy kodu do nagłówka jak w przykładzie 7.

Przykład 7. Dołączenie CSS i JS w Laravel

<script src="{{ asset('js/slick/slick.min.js') }}" defer></script> <script src="{{ asset('js/js-func.js') }}" defer></script> <script src="{{ asset('js/png-fix.js') }}" defer></script>  <link rel="dns-prefetch" href="https://fonts.gstatic.com"> <link href="https://fonts.googleapis.com/css?family=Nunito" rel="stylesheet" type="text/css">  <link href="{{ asset('css/bootstrap.css') }}" rel="stylesheet"> <link href="{{ asset('css/style.css') }}" rel="stylesheet"> <link href="{{ asset('css/ie6.css') }}" rel="stylesheet"> <link href="{{ asset('js/slick/slick.css') }}" rel="stylesheet"> <link href="{{ asset('js/slick/slick-theme.css') }}" rel="stylesheet">

6. Definicja routingu

6.1. Yii

Podstawą routingu i tworzenia adresów URL w Yii jest użycie menedżera URL, zarejestrowanego jako składnik aplikacji urlManager[3].

Menadżer udostępnia:

metodę parseRequest(), która służy do analizy przychodzącego żądania z parametrami,

metodę createUrl(), która tworzy adres URL.

Konfiguracja routingu (Przykład 8) realizowana jest w pliku konfiguracyjnym /config/web.php.

Przykład 8. Plik z definicją routingu w Yii

<?php $params = require(__DIR__ . '/params.php'); $config = [ 'id' => 'basic', 'basePath' =>dirname(__DIR__), 'bootstrap' => ['log'], 'language' => 'pl-PL', 'components' => [ 'request' => [ 'cookieValidationKey' => 'gNFp8ueOxFl90dSlsgLO5kBFGeD_0lP-', ], 'cache' => [ 'class' => 'yii\caching\FileCache', ], 'user' => [ 'identityClass' => 'app\models\Uzytkownik', 'enableAutoLogin' => true, ], 'errorHandler' => [ 'errorAction' => 'site/error', ], 'mailer' => [ 'class' => 'yii\swiftmailer\Mailer',


129

'useFileTransport' => true, ], 'mail' => [

'class' => 'yii\swiftmailer\Mailer', 'useFileTransport' => false, 'transport' => [ 'class' => 'Swift_SmtpTransport', 'host' => 'szybkie_kolo.com', 'username' => '[email protected]', 'password' => '$2y$13$Bz0H1y2VUjBQDjUUgXrysuPaj.E8ShLpKjs4WMTc33RzB6L7XZK5S', 'port' => '8080','encryption' => 'tls', ], ], 'log' => [ 'traceLevel' => YII_DEBUG ? 3 : 0, 'targets' => [ [ 'class' => 'yii\log\FileTarget', 'levels' => ['error', 'warning'], ], ], ], 'db' => require(__DIR__ . '/db.php'), ], 'params' => $params, ]; if (YII_ENV_DEV) { $config['bootstrap'][] = 'debug'; $config['modules']['debug'] = [ 'class' => 'yii\debug\Module', ]; $config['bootstrap'][] = 'gii'; $config['modules']['gii'] = [ 'class' => 'yii\gii\Module', ]; } return $config;

6.2. Laravel

Wszystkie trasy (ang. routes) w Laravel są zdefiniowane w specjalnych plikach, które znajdują się w katalogu routes. Te pliki są automatycznie ładowane przez framework.

Plik routes/web.php okre la trasy dla interfejsu sieciowego (Przykład 9), które są czę cią grupy tzw. brokerów internetowych iudostępniają funkcje obsługi sesji i ochronę np. przed atakiem CSRF. Trasy z pliku routes/api.phpnie obsługują stanów i należą do grupy dystrybutorów api (Przykład 9).

Przykład 9. Definicja routingu w Laravel (plik web.php)

<?php Route::get('/', 'HomeController@index')->name('home'); Route::get('reservation/exposure', 'ReservationController@reservation');

Route::post('reservation/exposure', 'ReservationController@create'); Route::get('wystaw_prom', 'ReservationController@wystaw_prom'); Route::get('reservation/devices', 'ReservationController@devices'); Route::get('reservation/advertisement/{id}', 'ReservationController@advertisement'); Route::get('reservation/message', 'ReservationController@messageForm'); Route::get('reservation/renting/{id}', 'ReservationController@renting'); Route::get('reservation/userlog', 'ReservationController@userLog');

Route::get('reservation/mydevises', 'ReservationController@mydevises');

Route::get('reservation/rating', 'ReservationController@rating'); Route::get('reservation/basked', 'ReservationController@basked'); Route::get('logout', function(){ Auth::logout(); return redirect()->back(); }); Auth::routes();

Przykład 10. Definicja routingu w Laravel (plik api.php)

<?php use Illuminate\Http\Request; Route::middleware('auth:api')->get('/user',

function (Request $request) { return $request->user(); });

7. Metryki kodu

Tabela 2 przedstawiaporównanie podstawowych metryk kodu dla obu aplikacji.

Tabela 2. Wybrane metryki kodu obu aplikacji

Yii2 Laravel

Liczba plików aplikacji 5 804 55 209

:iczba plików konfiguracyjnych 7 13

Liczba dołączanych bibliotek 20 45

Waga bibliotek[MB] 53 246

Przykładowy kontroler — liczba linii kodu

134 93

Przykładowy widok — liczba linii kodu

42 34

Przykładowy model — liczba linii kodu

62 57

Rozmiar projektu [MB] 60,5 294

Z wyników zestawionych w tabeli 2 wynika, ze aplikacja w Laravel zajmuje do 5 razy więcej pamięci, i wykorzystuje więcej bibliotek. Z kolei projekt Yii2 zajmuje więcej linii kodu. Tylko w przypadku przykładowego widoku w obu rozwiązaniach liczba linii kodu jest prawie jednakowa.

8. Wydajność aplikacji

Najważniejszym parametrem każdego programu komputerowego jest jego szybko ć działania. Do zbadania wydajno ci aplikacji testowych skorzystano z narzędzia DevTools dostępnego wprzeglądarce GoogleChrome. Wyniki przedstawiono w tabeli 3.

Tabela 3. Wydajno aplikacji

Yii2 Laravel

Czas wyszukiwania konkretnego pojazdu do

rezerwacji [s] 2,72 1,1

Czas ładowania się strony głównej [s] 4,5 1,39

Czas ładowania strony był mniejszy dla aplikacji Laravel.Dla małej aplikacji, niewielkie różnice w czasie ładowania stron nie stanowią problemu, ale w wypadku


130

dużego projektu, czas ładowania aplikacji może już być bardzo istotny.

9. Ocena końcowa

W tabeli 4 przedstawiono ocenę punktową analizowanych frameworków (opinia autorki) w skali 1-5, gdzie 5 jest oceną najwyższą. Tabela 4. Końcowa ocena frameworków

Kryterium oceny Laravel Yii

Przejrzysto ć tworzenia modelu aplikacji

4 5

Poziom trudno ci tworzenia aplikacji

3 3

Obsługiwane bazy danych 5 5

Dostępno ć materiałów 5 3

Wsparcie społeczno ci 5 3

Wymagany poziom znajomo ci frameworka

3 3

Przejrzysto ć struktury katalogów aplikacji

3 4

Wydajno ć wy wietlania rekordów 5 5

Końcowa ocena punktowa 33 31

10. Wnioski

W artykule przedstawiono wybrane elementy analizy porównawczejdwóch platform programistycznych dla PHP. Na podstawie przedstawionych wyników, można wnioskować, że Laravel jest bardziej wskazany dla mniej do wiadczonego programisty. Oferuje możliwo ć automatycznego generowania layoutu, tworzenia widoków dla wybranego modelu oraz

kodu akcji kontrolerów. Dodatkowo istnieje wiele materiałów pomocniczych udostępnianych na stronach Microsoft, blogach i forach dyskusyjnych.

Framework Yii2 jest silnym konkurentem Laravel, jednak oferuje zdecydowanie mniejsze wsparcie, je li chodzi o generowanie kodu aplikacji webowej. Jego wielką zaletą jest dużo mniejszy rozmiar gotowej aplikacji.

W wyniku przeprowadzonych badań stwierdzono, że Laravel jest bardziej przyjazny dla początkującego programisty aplikacji webowych w stosunku do Yii2.

Literatura

[1] Merkel Dirk. Chapter 6: PHP Frameworks // Expert PHP 5 Tools. Packt Publishing, 2010.

[2] Yii 2 Application Development Cookbook, Third Edition, Andrew Bogdanov, Dmitry Eliseev, November 2016.

[3] Dokumentacja Laravel, https://laravel.ru[16.10.2018]

[4] Dokumentacja Yii, https://www.yiiframework.com[19.10.2018] [5] Surguy M.: History of Laravel PHP framework, Eloquence

emerging. http://maxoffsky.com/code-blog/history-of-laravel-php-framework-eloquenceemerging/, [10.10.2018]

[6] Yii2 By Example, develop complete web applications from scratch through practical examples and tips for beginners and more advanced users, Fabrizio Caldarelli, 2015.

JCSI 11 (2019) 131-136

Wysłane: 2019-02-14


131

Metody prowadzenia testów jednostkowych w standardzie C++14

z wykorzystaniem biblioteki GMOCK

Kamil Strózik*


Streszczenie. W artykule przedstawiono jeden z problemów występujących podczas korzystania ze standardu C++14 wraz z biblioteką żoogle

Mock. Na podstawie wprowadzonego problemu omówiono mo liwe rozwiązania, a tak e zaprezentowano poprawiony schemat dla podejścia TDD.

Słowa kluczowe: testy jednostkowe; C++14; Google Mock; TDD;


Adres/adresy e-mail: [email protected]

Methods for conducting unit tests in the C++14 standard

using the GMOCK library

Kamil Strózik*


Abstract. The article presents one of the problems encountered when using the C ++ 14 standard along with the Google Mock library. Based on

the introduced problem, possible solutions were discussed, as well as an improved scheme for the TDD approach was presented.

Keywords: unit tests; C++14; Google Mock; TDD;


E-mail address/addresses: [email protected]

1. Wstęp

Wraz z kolejnymi standardami języka C++ pojawił się problem zgodności nowych funkcjonalności z biblioteką żoogle Mock. Proste podejście „red-green-refactor” z metodyki Test-Driven Development w przypadkach braku

zgodności przestało mieć zastosowanie. W związku z tym nale y ponownie zastanowić się nad krokami u ycia TDD poprzez istniejące problemy.

2. Idee testowania kodu

2.1. Znaczenie testowania

Testowanie przestaje być dodatkową, opcjonalną częścią projektu, zaczyna być uznawane za coś obowiązkowego i oczywistego. Dodatkowo coraz więcej firm, projektów planuje skrupulatnie fazy testowania.

Testowanie stało się obowiązkiem z powodu omyłkowości ludzi. Dobrze znanym przykładem jest uniknięcie o włos III wojny światowej. 26 września 1983 roku system Związku Radzieckiego podał komunikat o rozpoznaniu lecących amerykańskich rakiet w stronę podmoskiewskiej bazy wojskowej. Zgodnie z ówczesnymi procedurami, taki komunikat miał rozpocząć kontratak Związku Radzieckiego doprowadzając do kolejnej wojny światowej. Na szczęście

komunikat został podwa ony i system nie przyczynił się do śmierci ludzi [1].

Kolejnym przykładem jest zaciemnienie północno-

wschodnie z 2003 roku (Northeast blackout of 2003). Dostęp do prądu straciło wtedy 55 milionów osób ze Stanów Zjednoczonych oraz Kanady. Przywracanie dostępu do prądu trwało przez kolejne dwa tygodnie [2].

Wszystkie te błędy mogły zostać wykryte przez testowanie oprogramowania. W celu znajdowania błędów został opracowany model V, który dla ka dego etapu projektu informatycznego wprowadza jego testowanie. Czy to poprzez

przejrzenie wymagań, analizę struktury projektu, czy pó niejsze testy powstałego kodu oraz aplikacji jako całości.

Obecnie testy są integralną częścią produktu, a kod testów jest tak samo przechowywany i wersjonowany jak ka dy inny kod ródłowy [3]. Pozwala to zauwa yć, e jakość kodu testów jest tak samo wa na, jak jakość kodu testowanego, jeśli nie wy sza [4].

2.2. Znaczenie testów jednostkowych

Bazując na modelu V Robert Martin [5] określa jak dokładnie ma być przetestowane oprogramowanie konkretnym rodzajem testów. O ile same testy systemowe powinny się


132 132

skupić na przetestowaniu około 10% kodu programu, to testy jednostkowe mają pokrywać całość kodu, zatem celem powinno być 100% (rys. 1.).

Rys. 1. Piramida testów automatycznych [3]

W celu łatwiejszego osiągnięcia wysokiego pokrycia testami jednostkowymi powstało pojęcie TDD (Test-Driven

Development), które jest dyscypliną pomagającą rozwijać jakość projektu, a nie tylko losowym podejściem do weryfikacji elementów systemu [6]. TDD mo na przedstawić równie jako sposób zarządzania strachem podczas programowania [7]. Zdarza się równie , e w obrębie metodyki TDD wyró nia się UTDD (Unit Test-Driven

Development), które ma potwierdzać poprawne działanie systemu oraz ATDD (Acceptance Test-Driven Development),

które ma potwierdzić działanie logiki biznesowej. [8]

Całą listę argumentów dlaczego testy jednostkowe wraz

z TDD są tak istotne przedstawia Jeff Langr, m. in.

zwiększoną wykrywalność błędów z 40% do 90% w fazie

implementacji przy jednoczesnym wzroście czasu jej trwania

w projekcie z 15% do 35%, czy zale ność odwrotnie proporcjonalną między ilością testów jednostkowych, a zło onością kodu [6]. Z kolei programiści z wielu firm

przedstawiają wykorzystanie napisanych testów jednostkowych jako testów regresyjnych, które w krótkim czasie są w stanie potwierdzić działanie całego produktu [9].

Natomiast koreańscy naukowcy przedstawiają mo liwość wykorzystania istniejących testów jednostkowych do wygenerowania testów integracyjnych, jako bazę scenariuszy testowych [10].

Skoro pisanie testów jednostkowych jest tak istotne,

to jaka jest ich definicja? Test jednostkowy jest

to zautomatyzowany fragment kodu wywołujący kod testowanej jednostki, który następnie sprawdza pewne zało enia o pojedynczym wyniku końcowym tej jednostki. Prawie zawsze do pisania testów jednostkowych jest wykorzystywana zewnętrzna biblioteka, co pozwala na łatwe i szybkie uruchamianie. Test powinien być wiarygodny, czytelny oraz łatwy w utrzymaniu. Dodatkowo powinien

zwracać te same wyniki dopóki nie zmieni się testowany kod. [11]

Ka dy element powy szej definicji jest wa ny jeśli chodzi o metodę prowadzenia testów. Pozwala ona na łatwiejsze pisanie kodu, implementację nowych funkcjonalności, a uogólniając ulepsza fazę implementacji oraz cały etap powstawania oprogramowania i jego utrzymanie.

2.3. Metoda tworzenia testów jednostkowych

W poprzednim podrozdziale została ju przedstawiona definicja i zalety techniki TDD. Niniejszy podrozdział omówi kolejne kroki jej stosowania.

TDD mo na przedstawić w stosunkowo krótkim schemacie krokowym:

1) Napisać test dla nowego wymagania funkcjonalnego.

2) Uruchomić wszystkie testy i sprawdzić, e warunki z nowo napisanego testu nie są spełniane.

3) Zaimplementować jedynie taką ilość kodu produkcyjnego, który pozwoli na spełnienie warunków z nowego testu.

4) Uruchomić wszystkie testy, w przypadku nie działania któregoś z testów, powrócić do kroku 3.

5) Uporządkować kod pod kątem zmniejszenia zło oności, poprawy czytelności, czy łatwości konserwacji.

6) Uruchomić wszystkie testy, jeśli wykryją one błędy, to nale y je poprawić.

7) Jeśli są nowe wymagania funkcjonalne, to powrócić do kroku 1. w przeciwnym wypadku mo na zakończyć proces.

Odnosząc się do znanej mantry „red-green-refactor” [7] z metodyki TDD, mo na do niej przypisać odpowiednie kroki schematu:

● „red” – kroki 1 i 2, gdy nowy test potwierdza brak

potrzebnej funkcjonalności, ● „green” – kroki 3 i 4, gdy test daje „zielone światło”

szybkiej zmianie kodu produkcyjnego implementującego funkcjonalność

● „refactor” – kroki 5 i 6, gdy zostaje uprzątnięty kod produkcyjny oraz testowy.

Tak prosty schemat przyczynił się do upowszechnienia się techniki TDD, która oprócz licznych zalet wymienionych wcześniej, posiada równie ograniczenia, przez które nie zawsze mo e być stosowana.

3. Różnice pomiędzy standardami C++03, a C++14

3.1. Wprowadzenie

„Zaskakujące jak C++11 wydaje się być nowym językiem. źlementy pasują lepiej do siebie, tworząc wy szy poziom programowania, które jest bardziej naturalne ni dotychczas i tak wydajne jak nigdy dotąd.” Bjarne Stroustrup [12]

Powy szy cytat pokazuje jak następcę standardu C++03 postrzega jego twórca. Wiele elementów dodano, sporo


133 133

poprawiono. Jednak by mo na było mówić o kompletnych zmianach nale y wziąć pod uwagę standard C++14. Poprawia on wady wprowadzonych nowości, niedociągnięcia przedstawionych udogodnień.

3.2. Inteligentne wskaźniki

Język C++ od dawna był oskar any o to, e programy napisane z jego wykorzystaniem niejednokrotnie posiadają wycieki pamięci. Programiści wskazywali na trudności w zarządzaniu pamięcią, konieczność ręcznego zwalniania zaalokowanej pamięci. A same wska niki były równie wa ne jak niebezpieczne [13]. W związku z tymi zarzutami ju w C++03 występował auto_ptr równolegle z surowymi

wska nikami. Niestety stwarzał on wiele problemów, przez które nie był powszechnie u ywany. Standard C++14 posiada alternatywę dla auto_ptr. Począwszy od C++11, biblioteka języka udostępnia dwa rodzaje inteligentnych wska ników: unique_ptr, shared_ptr [13].

Unique_ptr przejął całą funkcjonalność wska ników auto_ptr, dodatkowo implementując brakującą semantykę przenoszenia [14]. W standardzie C++14 auto_ptr jest

oznaczony jako przestarzały o czym informuje kompilator wyświetlając ostrze enia w czasie kompilacji, natomiast

w standardzie C++17 został on całkowicie usunięty [15]. Sam unique_ptr zyskał prostszy i czytelniejszy interfejs,

co w połączeniu z szybkością działania i niezawodnością wpłynęło na jego popularność. Stosuje się go wszędzie tam, gdzie istotne jest wyłączne prawo do posiadania danego obszaru pamięci oraz zarządzanie nim. Dlatego wielokrotnie wykorzystuje się unique_ptr do pozyskania pewnych

zasobów, wykonania na nich operacji, a następnie na zwolnieniu tych pozyskanych zasobów [13]. Samo zwolnienie zasobów odbywa się w sposób automatyczny, przez co ten typ wska nika jest u ywany jako zmienna klasy, dzięki czemu nie ma ju potrzeby implementacji destruktora w klasie.

Wśród inteligentnych wska ników większą popularność zdobył shared_ptr, który w sposób automatyczny zarządza współdzieleniem własności zasobu. Dzięki temu shared_ptr daje mo liwość utworzenia wielu wska ników odnoszących się to tego samego obiektu, a w chwili gdy przestaje istnieć ostatni wska nik do obiektu jest on usuwany, a jego zasoby zwalniane [13]. Dla bardziej zło onych zastosowań w standardzie języka znajdują się równie klasy pomocnicze, takie jak weak_ptr, bad, weak_ptr,

czy enabled_shared_from_this.

4. Google Mock

By móc pisać testy zgodnie z podejściem TDD nale y korzystać z atrap obiektów, które w języku angielskim określa się je jako mock. Atrapa to fałszywy obiekt zewnętrznej zale ności w systemie, który pozwala sterować przebiegiem testu, a tak e sprawdzać wywoływanie funkcji udawanego interfejsu [16].

Czy biblioteki żoogle Test oraz żoogle Mock zachęcają do korzystania z TDD w czystej formie? Odpowied jest

niejednoznaczna. Poniewa rozpoczynając pracę nad projektem warto zacząć od prostego testu.

Przykład 1. Prosty test działania biblioteki żTest

#include <gtest/gtest.h>

TEST(VideoConverterTest, SimpleTest)

{

ASSERT_TRUE(true);

}

Przykład 1. pokazuje taki prosty test, który pozwala rozpocząć cykl Red-Green-Refactoring. Podczas pierwszej

próby kompilacji tego testu zostają wyświetlone błędy o braku pliku nagłówkowego gtest.h. Po wskazaniu ście ki do bibliotek żoogle udaje się zbudować program oraz zaimplementowany test kończy się sukcesem, co potwierdza prawidłowe skonfigurowanie projektu. Żaza refaktoryzacji, uprzątnięcia kodu oznacza w tym momencie implementację właściwych testów do wymagań.

Wymaganiem będzie implementacja klasy VideoConverter, która wykorzystując interfejs IManager, którego funkcja na postawie MemoryStruct wylicza ilość wolnej pamięci.

Samo wymaganie mo e wydać się trudne i skomplikowane, ale dzięki implementacji testu upraszcza się.

Przykład 2. Implementacja prostego testu dla wymagania


TEST(VideoConverterTest,

computeFreeSpace_MemoryAsParam_ReturnedValue)

{

IManagerMock managerMock;

VideoConverter testObj(managerMock);

MemoryStruct* pMemory = new MemoryStruct();

const unsigned EXPECTED_SIZE{5u};

EXPECT_CALL(managerMock,

computeFreeSpace(pMemory))

.WillOnce(Return(EXPECTED_SIZE));

ASSERT_DOUBLE_EQ(EXPECTED_SIZE,

testObj.getFreeMemorySize(pMemory));

delete pMemory;

}

Test przedstawiony w przykładzie 2. nie kompiluje się. Uzyskane błędy mówią o braku definicji dla pojęć: VideoConverter, IManagerMock, MemoryStruct. Analizując przebieg testu mo na przewidzieć implementację. Klasa VideoConverter w konstruktorze przyjmie referencję do interfejsu IManager, konstruktor powinien zachować referencję jako zmienną obiektu, dodatkowo klasa powinna mieć funkcję getŻreeMemorySize, która przyjmuje obiekt typu MemoryStruct, a zwraca liczbę bez znaku. Interfejs powinien mieć funkcję o nazwie computeFreeSpace o takim

samym typie parametru i zwracanym jak testowana funkcja.


134 134

Przykład 3. Implementacja prostego testu wraz zale nościami dla wymagania

#include <gmock/gmock.h>


using namespace testing;

struct MemoryStruct {};

class IManager {

public:

virtual ~IManager(){};

virtual unsigned computeFreeSpace(MemoryStruct*

memory) = 0;

};

class IManagerMock : public IManager {

public:

MOCK_METHOD1(computeFreeSpace,

unsigned(MemoryStruct*));

};

class VideoConverter {

public:

VideoConverter(IManager& manager) :

m_manager(manager) {}

unsigned getFreeMemorySize(MemoryStruct* memory) {

return m_manager.computeFreeSpace(memory);

}

private:

IManager& m_manager;

};

TEST(VideoConverterTest,

computeFreeSpace_MemoryAsParam_ReturnedValue) {

IManagerMock managerMock;

VideoConverter testObj(managerMock);

MemoryStruct* pMemory = new MemoryStruct();

const unsigned EXPECTED_SIZE{5u};

EXPECT_CALL(managerMock,

computeFreeSpace(pMemory))


ASSERT_DOUBLE_EQ(EXPECTED_SIZE,

testObj.getFreeMemorySize(pMemory));

delete pMemory;

}

Kompilacja i uruchomienie testu z przykładu 3. została zakończona sukcesem, został napisany działający kod. Wcią jednak potrzebna jest faza sprzątania kodu. Kod produkcyjny tj. VideoConverter, IManager, MemoryStruct powinny się znale ć w osobnych plikach, w katalogach aplikacji, a testy

i atrapy klas w analogicznej, lecz osobnej strukturze. Jeśli IManagerMock będzie wykorzystywany przez kilka klas testowych, to tak e powinien znale ć się w oddzielnym pliku.

Przeniesienie klas do osobnych plików powinno zakończyć się próbą kompilacji i uruchomieniem testów. Napisany wcześniej test powinien potwierdzić, e nie była zmieniana logika biznesowa, sam przebieg programu się nie zmienił. Kod produkcyjny został uprzątnięty, warto równie tworzyć testy jednostkowe najprościej jak to tylko mo liwe.

Przykład 3. prezentuje sposób tworzenia i wykorzystania bibliotek oferowanych przez Google. Atrapę tworzy się na podstawie klasy bazowej, dla funkcji wirtualnych. Wa ne, e klasa posiada wirtualny destruktor, który zapewni

właściwe niszczenie hierarchii tworzonych obiektów. Samo utworzenie sprowadza się do wykorzystania makra MOCK_METHOD1 [17]. Przyjmuje ono jako pierwszy

parametr nazwę funkcji, następnie typ zwracany, a w nawiasie tyle typów parametrów ile przedstawia samo

makro, w tym przypadku jest to jeden parametr. W ten sposób na etapie kompilacji jest tworzona klasa atrapy, która przesłania metody z prawdziwego interfejsu. Najczęściej do tworzenia atrap wykorzystywany jest skrypt gmock_gen,

który na podstawie podanej ście ki do pliku nagłówkowego klasy oraz jej nazwy, generuje do niej atrapę [18].

Wykorzystanie utworzonego obiektu atrapy jest równie proste. Dla weryfikacji wywołania funkcji na obiekcie atrapy

u ywa się makra źXPźCT_CALL, które przyjmuje konkretny obiekt atrapy, funkcje i jej argumenty, dodatkowo

mo na zdefiniować szereg akcji, które mają się wydarzyć w czasie wywołania funkcji. Przykład 3. demonstruje funkcje atrapy, która ma zwrócić oczekiwaną wartość.

5. Rozwiązanie problemu niekopiowalnych obiektów

Język C++14 posiada semantykę przenoszenia, posiada inteligentne wska niki. Konstrukcją, która łączy te dwa zagadnienia jest unique_ptr, który implementuje politykę przeniesienia, jednak nie ma zaimplementowanej semantyki

kopiowania. W części zastosowań jest to zaletą, gdy istotna jest pewność, e aktualny wska nik jako jedyny odnosi się do przechowywanej pamięci.

Przykład z poprzedniego rozdziału sugeruje mo liwość wykorzystania inteligentnego wska nika w miejsce surowego, dzięki czemu program będzie odporniejszy na wycieki

pamięci. Aktualnym zadaniem będzie jedynie taka zmiana, bez ingerencji w logikę funkcji. Takie zadanie wydaje się być mechanicznym, skryptowym zadaniem, które powinno zamienić wystąpienia MemoryStruct* na std::unique_ptr, warto równie do tworzenia u yć funkcji std::make_shared. Kod wygląda poprawnie, wszystkie odwołania do surowych wska ników zostały zamienione. Wydaje się, e kompilacja i utworzony test powinny przejść bezbłędnie.

Przykład 4. Błąd zwracany przy próbie u ycia unique_ptr

/home/kamil/01_UniquePtrAsParam/tests/VideoConverterTes

t.cpp:39:31:

error: use of deleted function ‘std::unique_ptr<_Tp, _Dp>::unique_ptr(const std::unique_ptr<_Tp, _Dp>&) [with

_Tp = MemoryStruct; _Dp = std::default_delete]’ computeFreeSpace(pMemory)).WillOnce(Return(EXPECTED_S

IZE));

Przykład 4. pokazuje, e makro źXPźCT_CALL próbuje wywołać konstruktor kopiujący, który jest usunięty. Ta próba wywołania powoduje, e kompilacja obiektu Matcher

nie mo e zakończyć się pomyślnie, przez co cały proces kompilacji ulega przerwaniu.


135 135

W przypadku tego błędu mo na jego rozwiązania albo pozostawić ten fragment kodu nieprzetestowanym,

co nierzadko się zdarza. Ignorowanie błędu, unikanie go jest złym rozwiązaniem, mogącym w przyszłości zaszkodzić całemu projektowi. Jak zatem rozwiązać ten problem?

Problem sprawia weryfikacja wywołania, jest ona jednak kluczowa z punktu widzenia testu, nie mo na z niej zrezygnować. W takim razie powraca problem braku mo liwości kopiowania unique_ptr, pojawia się mo liwość zamiany na shared_ptr. Jednak z mo na z niej skorzystać jedynie wtedy, gdy nie jest istotna wydajność, poniewa w niektórych operacjach shared_ptr potrafi być dwukrotnie wolniejszy ni unique_ptr. Ponadto shared_ptr nie zapewnia kontroli, czy jest jedynym właścicielem przechowywanego

obiektu.

żdy unique_ptr jest jedynym rozwiązaniem to trzeba się zastanowić co tak naprawdę jest wa ne w aktualnym teście, co nale ałoby przetestować. W tym przypadku powinno zostać sprawdzone wywołanie funkcji interfejsu, e zostanie jej przekazany ten sam obiekt, który trafił do testowanej funkcji. Jednak czy istotna jest sama klasa unique_ptr, czy to

co na nią wskazuje? Jeśli istnieje potrzeba sprawdzenia jedynie obiektu, na który wskazuje ten wska nik problem wydaje się o wiele prostszy.

Rozwiązaniem, które przedstawia przykład 5. jest wykorzystanie mechanizmu dziedziczenia, dzięki któremu mo na przesłonić funkcję bazową własną implementacją. W ciele weryfikowanej funkcji zostało wywołana funkcja z makra żMock’a. Makro natomiast jako parametr przyjmuje

wska nik.

Przykład 5. Poprawione makro dla sprawdzania metody

computeFreeSpace

MOCK_METHOD1(computeFreeSpaceProxy,

unsigned(MemoryStruct*));

unsigned computeFreeSpace(

std::unique_ptr<MemoryStruct> memory) override {

return computeFreeSpaceProxy(memory.release());

}

Dzięki przekazywaniu do makra jedynie wska nika, istnieje obecnie mo liwość weryfikacji wywołania w niemal identyczny sposób, jak podczas starej implementacji tego przykładu z u yciem surowych wska ników, co przedstawia przykład 6.

Przykład 6. Sprawdzenie wywołania funkcji computeŻreeSpace przy u yciu makra

EXPECT_CALL(*m_IManagerMock,

computeFreeSpaceProxy(pMemory.get()))


Kompilacja i uruchomienie testu przebiegło pomyślnie. ądana zmiana w kodzie ródłowym zgodnie

z przewidywaniami wymagała jedynie zamianę typów. Więcej problemów przysporzył kod testów. Wygenerowana przez skrypt gmock_gen atrapa interfejsu IManager zawiera

jedynie makro, które uniemo liwia jego u ycie. W tym wypadku zostaje zaburzona idea TDD, w której buduje się

test, a w dalszych krokach implementuje się kod potrzebny do pozytywnego wykonania testu. Oczywiście pierwszy powinien być test, by wiedzieć co powinno zostać zaimplementowane. Jednak w kolejnym kroku podczas

korzystania ze standardu C++14 wraz z biblioteką żMock nale y poprawić wygenerowaną atrapę oraz test.

6. Poprawiona metoda tworzenia testów jednostkowych

Przedstawiony schemat krokowy dla metodyki TDD

nie znalazł zastosowania w przedstawionych przykładach. Mantra „red-green-refactor” chocia ogólnie poprawna to jednak nie była w pełni przestrzegana. Błędem w schemacie krokowym jest zało enie braku problemów przy implementacji testu na podstawie wymagań, czy implementacji kodu produkcyjnego na podstawie testu.

Jest to jednak zrozumiałe, poniewa trudno stworzyć ogólny schemat uwzględniający wszystkie problemu.

Na podstawie przedstawionych przykładów opracowano poprawiony schemat krokowy metodyki TDD dla nowego

standardu C++ wykorzystywanego wraz z biblioteką żMock.

Poni ej przedstawiono poprawiony schemat krokowy:

1) Napisać test dla nowego wymagania funkcjonalnego. 2) Uruchomić wszystkie testy i sprawdzić wynik

uruchomienia,

3) Zaimplementować na podstawie testu jedynie taką ilość kodu produkcyjnego, który pozwoli na spełnienie warunków z nowego testu, jeśli wystąpił problem z testem niezwiązany z funkcjonalnością to nale y poprawić test stosując omówione rozwiązania (metoda proxy, saveArg).

4) Uruchomić wszystkie testy, w przypadku nie działania któregoś z testów, powrócić do kroku 3.

5) Uporządkować kod pod kątem zmniejszenia zło oności, poprawy czytelności, czy łatwości konserwacji.

6) Uruchomić wszystkie testy, jeśli wykryją one błędy, to nale y je poprawić.

7) Jeśli są nowe wymagania funkcjonalne, to powrócić do kroku 1. w przeciwnym wypadku mo na zakończyć proces.

Największa zmiana schematu nastąpiła w kroku 3., gdzie został dodany warunek „jeśli wystąpił problem z testem niezwiązany z funkcjonalnością”. Warunek utrudnia pisanie testów początkującym programistom, którzy będą musieli nauczyć się rozpoznawać znane problemy testów, które nie będą wynikały z implementacji funkcjonalności. Wraz z nowo dodawanymi funkcjonalnościami do kolejnych standardów języka C++, baza znanych problemów mo e się powiększać. Nale y pamiętać, e nawet dobrze dopracowane biblioteki posiadają swoje ograniczenia, a w wielu produktach występuje problem aktualizacji funkcjonalności do nowych standardów.

Bazę znanych problemów mo na by zamknąć w postaci skryptu, który poprawiałby wynik działania istniejącego skryptu gmock_gen. Wtedy w przypadku wykrycia,

e parametrem funkcji jest unique_ptr lub referencja

do rvalue skrypt automatycznie tworzyłby metodę proxy.


136 136

Natomiast gdy wykryłby wyra enie lambda, które nale y testować korzystając z konstrukcji SaveArg w kodzie testowym, to skrypt mógłby poinformować o tym w komentarzu przed daną metodą.

Obiektem lub metodą proxy mo na nazwać model, w którym istnieje pośrednik, który kontroluje dostęp [19]. Zatem skrypt tworzyłby funkcję przesłaniającą funkcję z klasy bazowej. Przesłonięta funkcja wywoływała funkcję z makra MOCK_MźTHOD, która przyjmowałaby obsługiwany przez bibliotekę żoogle Mock typ. Dla typu std::unique_ptr byłby to typ TYPź*, natomiast w przypadku TYPE&& to TYPE&.

7. Wnioski

Język C++ wraz z bibliotekami Google Test oraz Mock

w standardzie C++03 pozwalał na korzystanie z dobrodziejstw podejścia TDD do tworzenia oprogramowania. Pojawienie się nowszych standardów postawiło wyzwanie przed żMock’iem oraz utrudniło pracę programistom podczas prób pisania testów, które niejednokrotnie się nie kompilowały, co mogło doprowadzić do rezygnacji przez programistów z wykorzystywania

funkcjonalności oferowanych przez nowe standardy.

Istniejące problemy kompatybilności standardu C++14

z biblioteką żMock mo na rozwiązać poprzez dostosowanie procesu TDD, gdzie nale y zacząć od implementacji testu, następnie przejść do napisania fragmentów kodu jedynie w takim stopniu, by test mógł zostać spełniony. Jednak gdy wystąpią błędy nale y zwrócić uwagę czy to nie jest jeden z omówionych problemów. Zastosowanie innego sposobu

weryfikacji wywoływanej funkcji, przedstawionej

w poprzednich rozdziałach, pozwala na wykorzystanie zaplanowanej struktury kodu produkcyjnego, a w przypadku

testów na powrócenie do standardowego podejścia TDD.

W przypadku schematycznych problemów jak potrzeba tworzenia funkcji Proxy dla np. unique_ptr lub dla referencji

do rvalue rozwiązaniem mo e być napisanie skryptu takiego jak gmock_gen, który jednak rozpoznawałby parametry i w większym stopniu dopasowywałby do nich wygląd ostatecznie wygenerowanej atrapy.

Literatura

[1] Stanisław Pietrow, https://pl.wikipedia.org/wiki/Stanis%C

5%82aw_Pietrow . [10.01.2019]

[2] Northeast blackout of 2003, https://en.wikipedia.org/wiki/

Northeast_blackout_of_2003 [11.01.2019]

[3] Ganesan D., Lindvall M.: An analysis of unit tests of a flight

software product line. Science of Computer Programming,

Volume 78, 2013.

[4] żarousi Yusifoğlu V., Amannejad Y., Betin Can A.: Software test-code engineering: A systematic mapping. Information and

Software Technology, Volume 58, 2015.

[5] Martin R. C.: The Clean Coder: a code of conduct for

professional programmers. Pearson Education, 2011.

[6] Langr J.: Modern C++ Programming with Test-Driven

Development. The Pragmatic Programmers, 2013.

[7] Beck K., Test Driven Development: By Example. Addison-

Wesley Professional, 2003.

[8] Latore R.: Effects of Developer Experience on Learning and

Applying Unit Test-Driven Development. IEEE Transactions

on Software Engineering, Volume 40, 2014.

[9] Runeson P.: A Survey of Unit Testing Practices. IEEE

Software, volume 23, 2006.

[10] Shin Y., Choi Y., Lee W. J.: Integration testing through reusing

representative unit test cases for high-confidence medical

software. Computers in Biology and Medicine, Volume 43,

2013.

[11] Osherove R.: The art of Unit Testing Second Edition. Manning

Publications Co., 2014.

[12] C++11 - the new ISO C++ standard,

http://www.stroustrup.com/C++11FAQ.html, [11.01.2019]

[13] Josuttis N.: C++. Biblioteka standardowa. Podręcznik programisty. Wydanie II. Helion, 2014.



[15] ISO/IEC JTC1 SC22 WG21 N4660. Programming Languages -

C++.



[17] Dokumentacja dla biblioteki Google Mock, https://github.com/

google/googletest/blob/master/googlemock/docs/CookBook.md

[19.01.2019]

[18] Dokumentacja dla skryptu gmock_gen.py, https://github.com/

google/googletest/tree/master/googlemock/scripts/generator

[13.01.2019]

[19] Freeman E, Freeman E.: Head First Design Patterns. O’Reilly, 2004.

https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md

https://github.com/google/googletest/blob/master/googlemock/docs/CookBook.md

JCSI 11 (2019) 137-144

Wysłane: 2019-02-16


137

Porównanie wydajności języka skryptowego oraz kompilowanego na podstawie działania algorytmu genetycznego

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

Streszczenie. Celem artykułu jest porównanie wydajności wybranych języków programowania (Python, C) - poprzez pomiar czasu działania oraz wykorzystania zasobów komputera - algorytmu genetycznego dla zadanych parametrów, a następnie ocena czy język skryptowy może być porównywalny pod względem szybkości z językiem kompilowanym. Do tego celu zaimplementowany został algorytm genetyczny w każdym z wymienionych języków, a następnie przeprowadzone zostały testy, których wyniki stanowiły podstawę ostatecznej oceny ich wydajności oraz

dowód, że język skryptowy może osiągać czasy działania porównywalne z językiem kompilowanym.

Słowa kluczowe: Python; C; wydajność



Comparison of the performance of scripting and compiled languages based on

the operation of the genetic algorithm

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

Abstract. The aim of this work was to compare the performance of selected programming languages (Python, C) by measuring the time of

operation and use of computer resources of the genetic algorithm for given parameters, and then assessing whether the scripting language can be

comparable in terms of speed with the compiled language. For this purpose, a genetic algorithm has been implemented in each of these

languages and test scenarios were developed. The results form the basis for the final evaluation of the performance of the presented languages

and proof that the scripting language can achieve operating times comparable to the compiled language.

Keywords: Python; C; efficiency



1. Wstęp

Początek dwudziestego pierwszego wieku to okres intensywnego rozwoju technologii, a tym samym systemów informatycznych, których rozmiary często przekraczają kilka milionów linii kodu. Utrzymanie takiej ilości kodu oraz dostosowanie jej do przyszłego rozwoju przy zachowaniu

wydajności zapewniającej swobodę użytkowania stanowi duże wyzwanie. Podczas projektowania nowego systemu należy zdecydować jakie priorytety powinny zostać przyjęte w systemie – rozszerzalność i utrzymanie, szybkość działania czy może minimalne zużycie dostępnych zasobów. W zależności od ich ustawienia w dużej mierze zależeć będzie wybór technologii, w tym języka programowania w którym system zostanie napisany. Jeżeli priorytetem będzie szybkość działania pod uwagę powinny być brane języki niskiego poziomu, w pełni kompilowane o statycznej definicji typów jak na przykład język C, natomiast jeżeli na pierwszym miejscu znajdzie się rozszerzalność i utrzymanie, języki o prostej i intuicyjnej składni zyskuję przewagę, np. Python. Czasami jednak wybranie głównego priorytetu jest bardzo trudne i wszystkie wspomniane cechy systemu powinny

zostać wzięte po uwagę. Czy istnieje zatem sposób na

połączenie intuicyjności i możliwości języka skryptowego z szybkością języka kompilowanego?

Niniejszy artykuł skupia się na porównaniu przedstawicieli obu wspomnianych języków (Python, C) pod kątem szybkości wykonywania obliczeń oraz zużycia zasobów komputera, a także pokazuje metody dzięki którym możliwe jest znalezienie odpowiedzi na pytanie czy język skryptowy może osiągać czasy działania porównywalne z językiem kompilowanym. Przeprowadzone testy wraz z wynikami mogą stanowić silną podstawę do dyskusji podczas rozważań nad językiem programowania w którym projekt/system/program powinien zostać zaimplementowany.


2.1. Język C

Język C został zaprojektowany w 1972, przez Dennisa Ritchiego i od tamtej pory jest stale rozwijany. Został znormalizowany przez American National Standards Institute

(ANSI) w 1989 roku. Najnowsza stabilna wersja

o oznaczeniu C18, została wydana w czerwcu 2018 roku. C jest językiem ogólnego przeznaczenia, wspierającym


138 138

programowanie strukturalne (proceduralne), leksykalny zapis

zmiennych oraz rekurencję. Ponieważ jest typowany statycznie już w procesie kompilacji zapobiega błędom np. przy przekazywaniu argumentów do funkcji. Z założenia, C dostarcza konstrukcje, które efektywnie odwzorowują typowe instrukcje maszynowe, a zatem znalazł trwałe zastosowanie w aplikacjach, które wcześniej były kodowane w języku maszynowym (assembler), w tym w systemach operacyjnych,

a także w różnych aplikacjach dla komputerów, od superkomputerów po systemy wbudowane [1].

Został zaprojektowany do kompilacji za pomocą stosunkowo prostego kompilatora, aby zapewnić niskopoziomowy dostęp do pamięci, liczne konstrukcje

językowe, które skutecznie mapują instrukcje maszynowe oraz zapewnić minimalną potrzebę wsparcia w czasie pracy.

Język został zaprojektowany, aby zachęcić do programowania na wielu platformach. Zgodny z normami program C,

napisany z myślą o przenośności może być skompilowany dla bardzo różnorodnych platform komputerowych i systemów operacyjnych z niewielkimi zmianami w kodzie źródłowym [2].

2.2. Język Python

Zgodnie z badaniami przeprowadzonymi przez Instytut

Inżynierów Elektryków i Elektroników (IEEE) w latach 2017 oraz 2018 i opublikowanych w czasopiśmie naukowym IEEE Spectrum, język Python uplasował się na pierwszym miejscu

najczęściej używanych języków programowania [1, 3].

Python został stworzony we wczesnych latach dziewięćdziesiątych przez Guido van Rossuma, w Stichting

Mathematisch Centrum (CWI) w Holandii jako następca języka zwanego ABC. Jest on jego głównym autorem, jednak od wersji 1.6.1. jest dystrybuowany na licencji GNU (GPL).

W związku z powyższym wszystkie źródła języka Python

dostępne są dla każdego na stronie projektu na serwisie

GitHub [15]. Aktualnie dostępną stabilną wersją języka jest wersja 3.7.2. Ponieważ Python jest koncepcją języka, doczekał się wielu implementacji. Najpopularniejszą z nich i omawianą w niniejszej pracy jest implementacja w języku C – CPython, jednak znaleźć można również implementację w języku Java (Jython), która z powodzeniem tłumaczy kod Pythona do kodu bajtowego wirtualnej maszyny JVM oraz

implementację przygotowaną z myślą o programistach .NET – IronPython [4].

2.3. Porównanie wydajności języków C oraz Python w literaturze

Porównanie zostanie rozpoczęte pracą opracowaną przez czterech autorów: Muhammada Ateeq, Hina Habib, Adnana Umer, Muzammila Ul Rehman, pt. C++ or Python? Which

One to Begin With: A Learners Perspective [5]. W tytule

powyższego artykułu znajduje się „C++”, jednak wgląd do pracy pozwala stwierdzić, że w porównaniu nie są wykorzystywane specyficzne dla wspomnianego języka mechanizmy, jak klasy czy szablony. Mając to na uwadze wraz z faktem, że zachowanie zgodności na poziomie kodu źródłowego z językiem C, jest podstawowym wymogiem dla

kolejnych standardów C++ oraz, że biblioteka standardowa pokrywa się w znacznej części z biblioteką języka C, przykład ten może być bez przeszkód wykorzystany do

przedstawienia, który z porównywanych w niniejszej pracy języków jest lepszym wyborem dla początkującego programisty. Autorzy postanowili przebadać studentów po dwóch semestrach nauczania w których poznawali oni wymienione języki (I semestr – Python, II semestr – C++).

W przeprowadzonej ankiety, która skupiała się na intuicyjności i prostocie pisania kodu, biorąc po uwagę takie aspekty jak prostota, elastyczność, narzędzia do debuggowania czy dostępność modułów, badacze zauważyli, że studenci byli bardziej usatysfakcjonowani Pythonem,

a jego funkcje, jak instrukcje warunkowe, czy pętle, były prostsze w porównaniu do C++.

Następnym przykładem będzie praca autorstwa L. Dobrescu: Replacing ANSI C with other modern

programming languages [6], również rozprawiająca o zaletach oraz wadach zastąpienia ustandaryzowanego i wydajnego języka C, językiem zorientowanym obiektowo jak Python lub Java. W artykule autor punktuje obiektywne

uwagi, z których pierwszą informacją na temat Pythona jest jego prostota, składania, interpreter oraz ogromna

społeczność, które zachęcają do programowania. Użytkownika nie czeka tutaj żmudny proces kompilacji i linkowania. Użycie interpretera pozwala otrzymać wynik działania programu od razu. Autor zaznacza, że jest to bardzo dobry język programowania do wyboru jako pierwszy

oferujący bardzo duże możliwości wraz z bardzo dokładnymi komunikatami błędów, które dla początkującego programisty są ważną informacją.

W kolejnej pracy pt. An empirical comparison of seven

programming languages [7], autor Lutz Prechelt dokonał porównania siedmiu języków programowania: C, C++, Java, Perl, Python, Rexx, i Tcl. Języki te mogą być podzielone na dwie główne grupy:

1) języki kompilowane – C, C++, Java,

2) języki skryptowe – Perl, Python, Rexx, Tcl,

Z każdej z powyższych grup wybrani zostali przedstawiciele, na których skupia się temat niniejszej pracy - C oraz Python. Do ich porównania Autor publikacji wykorzystał problem nazywany Phonecode. Zasada działania algorytmu była bardzo prosta. Program wczytywał słownik

73,113 słów do pamięci, a następnie odczytywał z drugiego pliku numery telefonów i tłumaczył je na słowa wykorzystując poprzednio wczytany słownik. Rolę drugiego pliku odgrywały dwa różne zbiory danych – zawierający 1,000 numerów telefonów oraz drugi pusty plik, który służył jedynie do zmierzenia czasu wczytywania słownika. Na podstawie przeprowadzonych badań stwierdzono, że wszystkie algorytmy działają z porównywalną niezawodnością, natomiast języki skryptowe, zużywają o około połowę więcej pamięci operacyjnej w porównaniu do C/C++ (Java, która jest językiem typowanym statycznie, jest kompilowana do kodu bajtowego JVM, powodując tym samym, że zużywa ona prawie czterokrotnie więcej pamięci niż C/C++). Nie jest również zaskoczeniem, że czas wczytania słownika zawierającego ponad 70 tysięcy


139 139

rekordów, zajął językom C/C++ dziesięciokrotnie mniej czasu niż językom skryptowym. Braki w wydajności w prezentowanych przykładach, języki skryptowe nadrabiają natomiast szybkością oraz prostotą implementacji [19].

Napisanie algorytmów w językach skryptowych wymagało o średnio prawie o połowę mniej linii kodu w porównaniu z językami kompilowanymi.

Praca Li Jun oraz Li Ling, pt. Comparative research on

Python speed optimization strategies [8], rzuca pierwsze

światło na sposoby optymalizacji szybkości działania Pythona. Metody przyspieszenia wykonywania kodu

programu zostały przez Autorów przedstawione w klarowny sposób oraz skategoryzowane w dwóch grupach –

optymalizacji, które w znikomym stopniu wpłynęły na czas wykonywania programu oraz optymalizacji, które znacząco wpłynęły na czas wykonywania się programu (których czasy działania w porównaniu do takiego samego kodu w języku C są bardzo obiecujące). W pracy autorstwa pary Jun oraz

Ling zostało również zawarte bardzo ciekawe porównanie szybkości wykonywania obliczeń z wykorzystaniem różnych wersji języka Python, które zostały zestawione z czasem wykonania tych samych operacji z wykorzystaniem języka C. Wyniki uzyskane podczas przeprowadzania tego testu jasno

pokazują jak ważne jest posiadanie najbardziej aktualnej wersji interpretera języka Python oraz jak słabo wypada (niezależnie od wersji) w porównaniu do języka kompilowanego. Warto zaznaczyć, że czasy uzyskane podczas wykonywania optymalizacji z grupy znacząco poprawiających wydajność, testowane były z wykorzystaniem najwolniejszego interpretera języka Python ze wszystkich porównywanych. Wydaje się być logicznym, że czasy te mogły by być jeszcze lepsze przy wykorzystaniu najnowszego (bądź najlepszego z testowanych) interpretera.

Kolejną pracą, zestawiającą ze sobą bezpośrednio języki Python oraz C, jest Program performance test based on

different computing environment [9], autorstwa Hailong Zang

oraz Jun Nie. Porównanie dokonywane jest na podstawie czasu działania algorytmu obliczającego odległość pomiędzy punktami na sferze. Podobnie do poprzedniego artykułu przedstawionego w poprzednim akapicie, Autorzy

wykorzystują implementację CPython, która pozwala na dodawanie kodu napisanego w języku C. W tym przypadku jednak, porównanie zostaje dokonane również po optymalizacji obliczeń napisanych w C, z wykorzystaniem biblioteki OpenMP (Open Multi-Processing). Praca skupia się niestety tylko na jednej metodzie optymalizacji (po jednej dla

każdego języka), jednak wyniki uzyskane przez badaczy

pozwalają zobaczyć, jak wybrana metoda przyspieszenia działania języka Python wpływa na jego wydajność. W krótkim punkcie na początku artykułu można przeczytać dlaczego do porównania zostały wybrane akurat te języki –

prostota i elegancja (Python) kontra szybkość (C).

2.4. Algorytm genetyczny

Od czasu przedstawienia koncepcji przełożenia zachowań panujących w naturze, na język komputerowy, nastąpił wykładniczy wzrost prac badawczych w tej dziedzinie i na dzień dzisiejszy można stwierdzić, że rozwój

algorytmów genetycznych osiągnął swego rodzaju dojrzałość. Było to możliwe zarówno dzięki wspomnianym badaniom oraz znacznie malejącym kosztom szybkich i tanich komputerów. Problemy, które kiedyś rozważane były w kategoriach niemożliwych do wyznaczenia, w dzisiejszych

czasach, z punktu widzenia złożoności obliczeń nie stanowią już wyzwania [16]. Dzięki temu, złożone problemy, które wymagają jednoczesnego rozwiązywania mogą być wyznaczone z użyciem algorytmu genetycznego. Warto również zaznaczyć, że w przypadku wspomnianej rodziny

algorytmów uzyskana optymalizacja jest przekształcana z pokolenia na pokolenie bez ścisłego formułowania matematycznego, które występuje w tradycyjnych gradientowych sposobach optymalizacji [10].

Algorytm genetyczny inspirowany jest naturalną selekcją, tj. biologicznym procesem w którym silniejszy osobnik jest faworytem w niesprzyjającym otoczeniu. Algorytm

genetyczny używa bezpośredniej analogii do procesu ewolucji. Zakłada, że potencjalnym rozwiązaniem problemu może być jednostka, która jest reprezentowana przez zbiór cech. Cechy takie nazywane są genotypem osobnika (chromosomu), który najczęściej przedstawiany jest w formie ciągu binarnego. Bardzo ważną cechą z punktu widzenia algorytmu genetycznego jest funkcja przystosowania

osobnika, która jest miarą jakości rozwiązania.

Najbardziej podstawowy zapis algorytmu genetycznego

sprowadza się do następującej procedury:

1) Wybierz początkową populację osobników –

chromosomów, 2) Genotypy wybranych osobników poddawane są

operatorom ewolucyjnym (mutacja, krzyżowanie), 3) Oblicz funkcję przystosowania dla każdego osobnika, 4) Dokonaj selekcji osobników na podstawie wybranej

metody selekcji,

5) Zastąp osobniki o najmniejszej wartości funkcji przystosowania nowymi osobnikami.

Podczas projektowania działania algorytmu genetycznego

niezbędne jest ustalenie następujących rzeczy:

genotypu jako reprezentanta wyniku,

funkcji przystosowania,

sposobu selekcji osobników, definicji operatorów ewolucyjnych.

Kodowanie

Fundamentalną rzeczą w algorytmie genetycznym jest sposób kodowania wartości, które reprezentują rozwiązanie optymalizowanego problemu. Mechanizm ten polega na

naturze wykorzystywanych zmiennych, na przykład przy próbie wyznaczenia rozwiązania dla optymalnych przepływów w transporcie cieczy, zmienne (przepływy

w różnych kanałach) przyjmują wartości ciągłe, natomiast dla problemu komiwojażera zmiennymi są wielkości binarne reprezentujące uwzględnienie lub wykluczenie krawędzi w obwodzie hamiltonowskim. W każdym wypadku mechanizm kodowania powinien zapewniać jednoznaczność dekodowania tzn. każdemu genotypowi (np. każdej


140 140

kombinacji bitów) musi odpowiadać punkt z przestrzeni stanów, czyli rozwiązanie zadania [11].

Funkcja przystosowania

Funkcja przystosowania, nazywana również funkcją celu lub dopasowania, używana jest w algorytmach genetycznych

do obliczenia wartości rozwiązania dla danego osobnika w każdej iteracji. Jest ona podstawowym źródłem informującym o jakości każdego chromosomu w przestrzeni

rozwiązań [11].

Krzyżowanie

Operator ten polega na łączeniu w pary losowych

chromosomów z danej populacji w celu przeprowadzenia na nich krzyżowania, tj. wybór losowego miejsca (bitu) w chromosomie jednego z rodziców, a następnie wymiana kodu genetycznego pomiędzy wybranymi osobnikami zaczynając od wylosowanego punktu. Czy dojdzie do

skrzyżowania zależy od ustalonego w drodze losowania prawdopodobieństwa [17].

Mutacja

Kolejnym operatorem genetycznym jest mutacja. Mutacja

bitu polega na jego zamianie z 0 na 1 oraz w drugą stronę w przypadku chromosomów kodowanych binarnie. Jeżeli genotyp danego osobnika zakodowany jest w postaci liczb

całkowitych, stosuje się permutacje, natomiast w przypadku liczb rzeczywistych wprowadza się do losowo wybranych genów niedeterministyczne zmiany o wybranym rozkładzie. Tak jak w przypadku krzyżowania, szansa, że akurat dany bit będzie poddany mutacji określana jest losowo wygenerowaną wartością. Każdy z bitów w ciągu binarnym mutuje

z niezależnym prawdopodobieństwem, tj. prawdopodobieństwo mutacji danego bitu, nie wpływa na prawdopodobieństwo mutacji kolejnych bitów [11].

3. Oprogramowanie testowe

Do porównania wydajności obydwu języków i ustalenia czy języki skryptowe mogą być porównywalnie szybkie jak

języki kompilowane wykorzystany zostanie algorytm genetyczny, który przy pomocy figur geometrycznych

(trójkątów), będzie się starał odtworzyć podany na wejście znormalizowany obraz. Na podstawie czasu działania algorytmu (w różnych wersjach - optymalizacja) dla wybranej

liczby osobników oraz sprecyzowanej liczby pokoleń, a także poprzez pomiar zużycia zasobów (pamięci) dokonana zostanie analiza, która ostatecznie pozwoli ocenić, czy wydajność skryptu może osiągnąć wartości programu napisanego w języku C.

3.1. Zasada działania

Zasada działania algorytmu w pierwszym kroku polega na wczytaniu do pamięci operacyjnej – tablicy o rozmiarze

iloczynu wysokości oraz szerokości pliku – obrazu w postaci

surowych bajtów (plik w formacie .raw/.data), który posłuży jako wzorzec dla algorytmu genetycznego. Następnie dla

każdego osobnika, których liczba może być dowolnie

zdefiniowana zostanie utworzona tablica o identycznym

rozmiarze zainicjalizowana zerami. Ponieważ algorytm jako metodę selekcji wykorzystuje metodę rankingową na samym

początku zostaną zainicjalizowane dwie kolejne tablice –

pierwsza przechowująca najlepsze chromosomy, wytypowane

w drodze rankingu, druga przechowująca osobniki wygenerowane na drodze krzyżowania. Ponieważ obraz podany na wejście jest w skali szarości (każdy bajt ma wartość z przedziału [0,255]), funkcją przystosowania użytą w celu selekcji najlepszych osobników będzie suma kwadratów różnic, a więc im mniejsza wartość sumy tym lepszy dany osobnik. Dąży się więc do minimalizacji funkcji celu. Mutacja w przypadku tego konkretnego algorytmu

będzie się odbywała poprzez uśrednianie wartości danego bajtu z losowo wygenerowaną wartością, również z wcześniej wspomnianego przedziału – będzie to zatem proste przyciemnianie lub rozjaśnianie danego piksela. Krzyżowanie wykorzystywane podczas generowania nowego pokolenia jest

prostą, jednak bardzo skuteczną funkcją. Skupia się ona na kopiowaniu najlepszych osobników aż do czasu zapełnienia następnej populacji. Przy wykorzystaniu tej metody blokowana jest możliwość reprodukcji dla osobników najgorzej przystosowanych, jednak na potrzeby badań wykonywanych podczas niniejszej pracy jest to wystarczające rozwiązanie. Całość jest powtarzana do czasu osiągnięcia podanej liczby pokoleń, zapisując przy okazji na dysk najlepiej przystosowanego osobnika z danego pokolenia

w celu umożliwienia podejrzenia jak radzi sobie algorytm. Działanie algorytmu można przedstawić przy pomocy

diagramu (Rys. 1.).

Całość oprogramowania zawiera się w dwóch plikach źródłowych. Jeden napisany w języku Python o rozszerzeniu .py, drugi napisany w języku C z rozszerzeniem .c. Ponieważ są to języki skrajnie różne, podczas implementacji algorytmu

w języku kompilowanym w celu emulacji obiektowości, wykorzystana została technika C-structure subtyping, które pozwala na taki zabieg w języku C, w celu jak najbardziej dokładnego odwzorowania algorytmu w dwóch plikach. Jako obraz wejściowy wykorzystany został znormalizowany obraz autorstwa Leonarda da Vinci pt. Portret damy z gronostajem,

potocznie noszący nazwę Damy z łasiczką.

Każdy z algorytmów składa się z kilku głównych części (ponieważ różnica pomiędzy klasą, a strukturą polega tylko na różnych prawach dostępu do zmiennych, w dalszej części pracy, terminy struktura oraz klasa będą używane wymiennie w odniesieniu do obydwu języków):

struktura reprezentująca pokolenie – jest to główna część programu, zawierająca w sobie tablice przechowujące dane każdego chromosomu, najlepsze osobniki, a także metody wykorzystywane przy mutacji, krzyżowaniu oraz ocenianiu,

mutacja, krzyżowanie, ocena – jak wspomniano

w poprzednim punkcie każdy algorytm składa się z tych samych wyrażeń wykorzystanych przy implementacji wspomnianych funkcji, przetłumaczonych na semantykę danego języka,


141 141

Rys. 1. Schemat działania wykorzystywanego algorytmu genetycznego

struktura reprezentująca osobnika – w programach

została również zaimplementowana struktura definiująca dany chromosom, przechowująca wartość jego funkcji dopasowania, a także jej definicję,

funkcja dopasowania – zdefiniowana jako metoda

w klasie reprezentującej osobnika, struktura opisująca trójkąt – służy ona do generowania

nowego osobnika podczas procesu mutacji, który w prezentowanym algorytmie przyjmuje postać figury geometrycznej - trójkąta.

3.2. Metody optymalizacji języka Python

Ze względu na wygodę używania języka Python oraz ogromnej społeczności, stworzone zostało bardzo wiele

metod oraz sposobów optymalizacji. W niniejszym podpunkcie przedstawione zostaną techniki optymalizacji, które zostaną wykorzystane podczas testów oprogramowania.

1) Technologia Just-In-Time

Metoda ta jest bardzo dobrze znana wszystkim

użytkownikom języka JAVA. Polega ona na kompilowaniu kodu do kodu maszynowego podczas działania programu, bezpośrednio przed jego wykonaniem w przeciwieństwie do standardowej ścieżki wykonania, gdzie kod najpierw jest tłumaczony do kodu bajtowego maszyny danego języka. Python również posiada swoją implementację kompilatora

JIT. Do roku 2012, jedynym dostępnym rozwiązaniem był kompilator Psyco [12], który przestał być rozwijany. Na całe szczęście w jego miejsce pojawił się w odczuciu autora niniejszej pracy dużo lepszy kompilator Just-In-Time, który w przeciwieństwie do Psyco (który był importowany w postaci modułu), jest całkowicie oddzielną implementacją Pythona, w pełni kompatybilną z wykorzystywanym w niniejszej pracy CPythonem – PyPy [13]. Jest to bardzo

dobre rozwiązanie, które nie wymaga żadnego przekształcania kodu, który został napisany dla danej wersji standardowej implementacji Pythona, będąc dodatkowo w pełni przenośnym rozwiązaniem.

2) Rozszerzenia w języku C

W każdym algorytmie znajdują się wąskie gardła, które skutecznie spowalniają pracę programu. Dzięki możliwości rozszerzania języka Python, z wykorzystaniem języka C [14],

mogą one zostać zaimplementowane w języku kompilowanym, korzystając z udostępnionego API implementacji języka Python, a następnie dołączone do projektu jak zwykły moduł. Niestety to rozwiązanie jest

bardzo pracochłonne i podatne na błędy. Programista musi być zaznajomiony z wewnętrznymi mechanizmami języka, jak na przykład zliczanie referencji, które błędne zaimplementowane może prowadzić do wycieków pamięci i niezdefiniowanego zachowania programu, które może skutkować jego awaryjnym zakończeniem.

3.3. Metody optymalizacji języka C

Głównym sposobem na zoptymalizowanie kodu napisanego w języku C jest jego ponowne napisanie używając coraz bardziej wyrafinowanych technik, jak wstawki kodu

asemblera [19]. By uniknąć niepotrzebnego zaciemniana kodu, do testów zostaną wykorzystane optymalizacje dostępne w kompilatorze. Do kompilacji kodu źródłowego napisanego w języku C, przedstawiany algorytm genetyczny wykorzystuje kompilator GCC 8.2.0.. Ponieważ kompilacja przeprowadzana jest na systemie Windows, wykorzystane

zostanie środowisko MinGW.

GCC udostępnia cztery podstawowe rodzaje optymalizacji:

O1 – niezależna od architektury wysoko poziomowa optymalizacja obliczeń,

O2 – zawiera optymalizacje wykonywane w O1, a także specyficzne optymalizacje dla danej architektury

procesora,

O3 – tak zwana agresywna optymalizacja, nacisk zostaje

postawiony na całkowitą maksymalizację szybkości obliczeń.

4. Testy

Testowanie opracowanego oprogramowania zostało przeprowadzone na maszynie o procesorze Intel® Core™ i7-

3517U, taktowanym zegarem o częstotliwości 1.9 GHz w trybie normalnym oraz możliwości taktowania na poziomie 2.4 GHz w trybie boost, posiadającej 12 GB pamięci RAM, działającej pod kontrolą systemu operacyjnego Windows 10 (64-bit).


142 142

Wnioski wyciągnięte na podstawie wyników otrzymanych z przeprowadzonym testów pozwoliły ocenić stopień wydajności poszczególnych języków oraz zdecydować czy język skryptowy może być porównywalny pod względem szybkości działania z językiem kompilowanym.

4.1. Badanie wydajności

Badanie wydajności zostało przeprowadzone na

podstawie wcześniej zdefiniowanych scenariuszy. Dla poszczególnego języka obejmowały one przetestowanie czasu

działania algorytmów oraz wykorzystywanych zasobów pamięci bez zastosowania optymalizacji oraz z jej

zastosowaniem, dla różnych wartości osobników w populacji oraz różnych wartości najlepszych osobników dla stałej liczby pokoleń, która pozwoli wyraźnie zauważyć działanie algorytmu i wynosić będzie 1000.

1) Scenariusz 1 - pierwszy scenariusz zakłada przetestowanie działania algorytmu dla 300 osobników w populacji oraz dla liczby najlepszych osobników wynoszącej 2,

2) Scenariusz 2 – w tym przypadku liczba osobników w populacji wynosi 500, reszta zgodnie z poprzednim

scenariuszem,

3) Scenariusz 3 – liczba osobników zostanie podniesiona do 1000, wartość liczby najlepszych osobników również nie ulega zmianie,

4) Scenariusz 4 – scenariusz czwarty jako pierwszy zmienia

liczbę najlepszych osobników do 10, zmniejszając również liczbę chromosomów w pokoleniu do 300,

5) Scenariusz 5 – liczba najbardziej przystosowanych

osobników, którzy zostaną poddani krzyżowaniu wzrasta do 50, przy zachowaniu stałej liczby populacji,

6) Scenariusz 6 – liczba najlepszych osobników: 100, osobników w populacji: 300.

Powyższe scenariusze zostały wykonane ośmiokrotnie: cztery razy w przypadku języka C – bez optymalizacji i cztery

z optymalizacjami oraz analogicznie dla języka Python.

4.2. Język Python – wyniki testów

Wyniki uzyskane podczas testów dla języka Python zostały przedstawione w dwóch kolejnych podpunktach i przeprowadzone zostały przy wykorzystaniu najnowszego dostępnego interpretera języka w wersji 3.7.2. – w przypadku

testów przeprowadzanych bez optymalizacji oraz z wykorzystaniem PyPy w wersji 6.0.0. w przypadku

optymalizacji wykorzystującej JIT.

Bez wykorzystania optymalizacji

Wyniki zostały przedstawione w tabeli 1.

Tabela 1. Wyniki otrzymane dla skryptu pythonowego, bez wykorzystania

optymalizacji

Numer

scenariusza Czas działania Wykorzystana pamięć

1. 7 godzin 56 minut 196 MB


3. 25 godzin 36 minut* 619 MB


5. 7 godzin 42 minuty 196 MB


*jest to w tym przypadku aproksymacja, ponieważ ostatni test został przerwany na 612 iteracji po upływie 15,5 godziny.

Z wykorzystaniem optymalizacji

Testowanie oprogramowania z wykorzystaniem

optymalizacji zostało podzielone na 3 części:

Z wykorzystaniem możliwości rozszerzania języka Python językiem C,

Z wykorzystaniem kompilatora Just-In-Time,

Z połączeniem dwóch powyższych punktów.

1) Rozszerzenia w języku C

Tabela 2. Wyniki dla optymalizacji z wykorzystaniem rozszerzeń Pythona w języku C

Numer


1. 28 minut 52 sekund 225 MB

2. 51 minut 13 minut 317 MB

3. 1 godzina 52 minuty 620 MB

4. 32 minuty 33 sekundy 196 MB

5. 26 minut 54 sekundy 196 MB


2) Kompilator JIT

Tabela 3. Wyniki dla optymalizacji z wykorzystaniem kompilatora JIT

Numer


1. 3 minuty 14 sekund 400 MB






3) Kompilator JIT + rozszerzenia C

Tabela 4. Wyniki dla optymalizacji z wykorzystaniem kompilatora JIT

i rozszerzeń napisanych w języku C

Numer


1. 1 godzina 36 minut 1816 MB

2. 2 godziny 59 minut 2502 MB






143 143

4.3. Język C

Testy dla języka C przeprowadzane były z wykorzystaniem scenariuszy opisanych w punkcie 4.1.. Kod

kompilowany był przy użyciu kompilatora GCC 8.2.0 rewizja

3, udostępnionego przez środowisko MinGW.

Bez wykorzystania optymalizacji

Tabela 5. Wyniki uzyskane dla algorytmu napisanego w języku C, bez optymalizacji

Numer








Z wykorzystaniem optymalizacji

1) Optymalizacja O1

Tabela 6. Wyniki otrzymane dla algorytmu (C), z wykorzystaniem

optymalizacji O1

Numer








2) Optymalizacja O2


optymalizacji O2

Numer








3) Optymalizacja O3


optymalizacji O3

Numer








5. Wnioski

Analizując otrzymane wyniki, stanowczo można stwierdzić, że język Python w swojej podstawowej formie jest językiem bardzo wolnym i mało wydajnym. Wyniki otrzymane dla algorytmu napisanego w tym właśnie języku, bez żadnych optymalizacji są niedopuszczalne, jeżeli chodzi o codzienną pracę i testy. Program napisany w języku C, również pozbawiony metod optymalizacyjnych wykonywał się średnio 15 razy szybciej, zużywając przy tym około 4 razy mniej pamięci. Wynik testów pozbawionych optymalizacji nie jest zaskakujący – język skryptowy był wolniejszy, zaskoczeniem jest natomiast różnica w czasach wykonywania poszczególnych wersji algorytmu. Pamiętając jednak o bardzo dużych możliwościach poprawienia efektywności języka Python, wyniki uzyskane z wykorzystaniem

rozszerzeń C API języka Python pozwoliły uzyskać czasy minimalnie lepsze od podstawowej wersji algorytmu

napisanej w języku C, nie zwiększając przy tym kosztów związanych z wykorzystaniem pamięci. W opozycji do pierwszej z metod optymalizacyjnych języka Python,

wykorzystana została flaga kompilatora GCC – O1, która pozwoliła poprawić czasy uzyskane przez podstawową wersję algorytmu (C) dwunastokrotnie, nie zmieniając przy tym zużycia pamięci.

Wykorzystanie PyPy, a więc implementacji Pythona, która wykorzystuje kompilator Just-In-Time okazał się najlepszą metodą optymalizacyjną w rozpatrywanych przypadkach – biorąc pod uwagę najpierw czas wykonywania algorytmu. Pozwolił osiągnąć czasy gorsze średnio o 32 sekundy od wyników uzyskanych dzięki kolejnej optymalizacji kodu generowanego przez kompilator języka –

O2 - które pozwoliło poprawić uzyskane wcześniej (przy zastosowaniu optymalizacji O1) czasy średnio o dodatkowe 6%. Agresywna optymalizacja kodu napisanego w języku C spowodowała nieznaczne pogorszenie wyników, przybliżając się tym samym do wyników otrzymanych przy wykorzystaniu PyPy. Ostatnia metoda optymalizacji

wykorzystana w przypadku algorytmu w języku Python

okazała się zupełnie nietrafiona. Wyniki otrzymane przy jej zastosowaniu były bardzo niezadowalające.

Biorąc pod uwagę powyższe rozważania język C jest językiem bardziej wydajnym od języka Python zarówno pod względem czasu wykonywania obliczeń jak również zużycia pamięci. Wydajność języka Python może być jednak znacząco podwyższona przy wykorzystaniu

ogólnodostępnych narzędzi, dorównując wydajności języka C

(bez optymalizacji). Narzut w postaci większej ilości zużywanej pamięci można uznać (biorąc pod uwagę wielkości pamięci jakimi operują dzisiejsze komputery) za nieistotny – nawet przy komputerze korzystającym z 4GB pamięci RAM, algorytm nie zakłócałby działania systemu. Przedostatnie zdanie jest bardzo ważne, ponieważ na poczet wydajności danego języka można również zaliczyć szybkość pisania kodu, jego utrzymanie, przejrzystość i zrozumienie,

w których język Python jest niekwestionowanym liderem, co w połączeniu z możliwością uzyskiwania czasów działania porównywalnych z językiem C czyni z niego prawdziwe


144 144

narzędzie do tworzenia kodu szybkiego i przejrzystego, który będzie łatwy w utrzymaniu i rozbudowie.

W całej pracy porównywane były czasy działania algorytmów, a nie jakość generowanych rozwiązań, ponieważ w rozważanym temacie sprawa ta jest drugorzędna. W opinii

autora warto jednak przedstawić wynik zaimplementowanego algorytmu genetycznego. Rysunek 2. przedstawia wyniki

działania algorytmu dla 1, 1000, 20000, oraz 100000 pokoleń przy założeniu trzystu osobników w populacji oraz osobników zdolnych do rozmnażania w liczbie 2.

Rys. 2. Wynik działania algorytmu genetycznego dla (od lewej): 1, 1000,

20000, 100000 pokoleń

Literatura

[1] https://www.businessinsider.com/the-10-most-popular-

programming-languages-according-to-github-2018-

10?IR=T#10-ruby-1 [05.01.2019]

[2] Andersen L. O.: Program Analysis and Specialization for the C

Programming Language. Dania, Maj 1994.

[3] https://en.wikipedia.org/wiki/C_(programming_language)

[05.01.2019]

[4] Lutz M.: Learning Python. O'Reilly Media, 2013.

[5] Ateeq M., Habib H., Umer A., Rehman M. U.: C++ or Python?

Which One to Begin with: A Learner's Perspective. [W]: 2014

International Conference on Teaching and Learning in

Computing and Engineering, IEEE, 11-13 April 2014.

[6] Dobrescu L.: Replacing ANSI C with other modern

programming languages. [W]: 2014 International Symposium

on Fundamentals of Electrical Engineering (ISFEE), IEEE, 28-

29 Nov. 2014.

[7] Prechelt L.: An empirical comparison of seven programming

languages. Computer, Volume: 33, Issue: 10, Oct 2000.

[8] Jun L., Ling L.: Comparative research on Python speed

optimization strategies. [W]: 2010 International Conference on

Intelligent Computing and Integrated Systems, IEEE, 22-24

Oct. 2010.

[9] Zhang H., Nie J.: Program performance test based on different

computing environment. [W]: 2016 IEEE International

Conference of Online Analysis and Computing Science

(ICOACS), IEEE, 28-29 May 2016.

[10] Man K. F., Tang K. S., Kwong S.: Genetic algorithms: concepts

and applications [in engineering design]. IEEE Transactions on

Industrial Electronics, 1996, Volume: 43, Issue: 5, Oct 1996, p.:

519 - 534.

[11] Srinivas M., Patnaik L. M.: Genetic algorithms: a survey.

Computer, 1994, Volume: 27, Issue: 6, June 1994, p.: 17 - 26.

[12] http://psyco.sourceforge.net/ [02.02.2019]

[13] http://pypy.org/index.html [02.02.2019]

[14] https://docs.python.org/3.6/extending/extending.html

[02.02.2019]

[15] https://github.com/python/cpython [06.01.2019]

[16] Merelo-Guervós J. J., Blancas-Álvarez I., Castillo P. A., Romero G., Rivas V. M., García-Valdez M., Hernández-Águila A., Romáin M.: A comparison of implementations of basic evolutionary algorithm operations in different languages. [W]:

2016 IEEE Congress on Evolutionary Computation (CEC),

IEEE, 24-29 July 2016.

[17] Suman S., Giri V. K.: Genetic Algorithms: Basic Concepts and

Real World Applications. Gorakhpur, Uttar Pradesh, India, May

2016.

[18] Myalapalli V. K., Myalapalli J. K., Savarapu P. R.: High

performance C programming. [W]: 2015 International

Conference on Pervasive Computing (ICPC), IEEE, 8-10 Jan.

2015.

[19] Gerardo de la Fraga L., Tlelo-Cuautle E., Azucena A. D. P.: On

the Execution Time of a Computational Intensive Application

in Scripting Languages. [W]: 2017 5th International Conference

in Software Engineering Research and Innovation

(CONISOFT), IEEE, 25-27 Oct. 2017.

JCSI 11 (2019) 145-148



145

Porównanie narzędzi do tworzenia aplikacji typu SPA na przykładzie Ember i React

Jacek Wróbel*


Streszczenie. W artykule przedstawiono wyniki porównania narzędzi do tworzenie aplikacji typu SPA przy użyciu platformy programistycznej Ember oraz React. Badania przeprowadzono z wykorzystaniem aplikacji testowych o takiej samej funkcjonalno ci, ale zaimplementowanych na obu platformach. Porównanie dotyczyło struktury projektu, wybranych metryk kodu oraz efektywno ci renderowania stron.

Słowa kluczoweŚ React; Ember; JavaScript



Comparison of single-page application development using

Ember and React example

Jacek Wróbel*


Abstract. The article presents the results of comparison of tools for creating SPA applications using the Ember and React framework. The

research was carried out using test applications with the same functionality but implemented on both platforms. The comparison concerned the

structure of the project, selected code metrics and the effectiveness of page rendering.

Keywords: React; Ember; JavaScript



1. Wstęp

Język programowania JavaScript jest aktualnie bardzo szeroko wykorzystywany w dziedzinie informatyki, między innymi w tworzeniu stron internetowych, aplikacji

internetowych, gier, aplikacji mobilnych itp. Można użyć go do zaprogramowania strony klienta, ale także strony serwera, np. za pomocą platformy programistycznej (ang. framework) Node.js [1]. Bardziej popularne jest jednak tworzenie widoku

aplikacji, co było pierwotnym założeniem tego języka.

W międzyczasie wytworzono bardzo dużo nowych frameworków, które są mniej lub bardziej chętnie wykorzystywane przez programistów. Wykorzystywanie frameworków powoduje zwiększenie efektywno ci pracy

programisty, poprawę jako ci kodu oraz niezawodno ć.

Tworzenie aplikacji na platformie programistycznej wymaga

mniej linii kodu do napisania. Dodatkowo platformy takie są już odpowiednio zabezpieczone przed niechcianymi

działaniami ze strony użytkowników. Wadą stosowania takich rozwiązań może być do ć duża złożono ć kodu oraz ich

wydajno ć, w porównaniu do aplikacji napisanych w zwykłym JavaScript.

Dla mniej do wiadczonego programisty, decyzja o tym,

który framework wybrać nie jest prosta. W sieci można znaleźć kilka artykułów porównujących cechy wybranych

frameworków JavaScript [9][10]. Zdania na temat, która platforma programistyczna jest lepsza są podzielone.

2. Cel badań

W niniejszym artykule zostaną przeanalizowane dwie

platformy programistyczne: starsza Ember.js oraz nowsza

biblioteka React,js. Są one obecnie jednymi

z najpopularniejszych narzędzi wspierających budowę zaawansowanych aplikacji w JavaScript. Według portalu HotFrameworks - Ember jest na siódmym miejscu, za React na drugim miejscu w rankingach popularno ci (Rys. 1) [2].


146 146

Rys. 1. Porównanie popularno ci React i Ember w ostatnich 4 latach [2]

3. React i Ember

Ember wykorzystuje architekturę MVC oraz pozwala tworzyć aplikacje z wykorzystaniemŚ

Ember CLI (ang. Command Line Interface) – konsola

użytkownika wspomagająca tworzenie aplikacjiś silnika szablonów Handlebars, który umożliwia

wielokrotne wykorzystanie jednego komponentu;

warstw danych, co daje możliwo ć spójnej komunikacji z zewnętrznymi API (ang. Application Programming Interface).

React jest biblioteką JavaScript, która posiada specyficzne dla frameworka cechy. Podobnie jak Ember, korzysta

z komponentów, które są niezależnymi modułami aplikacji, jak np. formularz czy tabela danych. W każdym komponencie zdefiniowana jest funkcja render(), która wywoływana jest

w razie zmiany stanu komponentu, aby go wyrenderować [5].

Zaletą React jest też język JSX, który jest pochodną XML [6] i pozwala ograniczyć liczbę wierszy kodu wpisywanych przez programistę. Przykład 1 i 2 pokazuje kod potrzebny do wy wietlenia hiperłącza w React i z wykorzystaniem języka JSX.

Przykład 1. Wy wietlenie hiperłącza za pomocą React

render: function() { return React.DOM.a({ href: 'http://facebook.github.io/react' }, 'React'); }

Przykład 2. Wy wietlenie hiperłącza za pomocą JSX

render: function() { return <a href="http://facebook.github.io/react">React</a> ; }

W obu przykładach efektem końcowym będzie kod HTML: <a href="http://facebook.github.io/react">React</a>

Najważniejsze cechy obu platform zostały zestawione w tabeli 1.

Tabela 1. Podstawowe wła ciwo ci React.js oraz Ember.js

React Ember.js

Autor Jordan Walke Yehuda Katz, Tom

Dale, Charles Jolle Język programowania

JavaScript

Pierwsze wydanie 1 marca 2013 8 grudnia 2011 Aktualna wersja

stabilna 16.3.2 (16 kwietnia

2018) 2.18.0 (1 stycznia

2018) Licencja MIT

4. Aplikacje testowe

Aplikacje testowe zostały wykonane w rodowisku programistycznym PhpStorm z zastosowaniem wtyczek do

React oraz Ember [3]. Do zarządzania danymi zostało wykorzystane zewnętrzne API, dzięki któremu można dodać, usunąć lub edytować wpisy [4]. Aplikacje posiadają funkcjonalno ci CRUD (ang. Create, Read, Update, Delete), czyli realizują funkcje tworzenia, odczytu, edycji i usuwania

danych. Interfejs graficzny użytkownika (Rys. 2) jest taki sam

w obu przypadkach, dzięki czemu można łatwo porównać szybko ć renderowania stron.

Rys. 2. Zrzut ekranu z aplikacji testowej

5. Analiza porównawcza

W analizie porównano:

strukturę projektu;

metryki kodu;

szybko ci renderowania stron.

5.1. Struktura aplikacji

W strukturze aplikacji Ember i React można zauważyć czę ci wspólne, jak zaznaczono na rysunku 3. Na niebiesko

oznaczone są komponenty aplikacji, m.in. tabela danych. Kolorem czerwonym zakre lono katalog z plikami konfiguracyjnymi, na żółto plik package.json, który zawiera wszystkie zależno ci potrzebne do zbudowania projektu.


147 147

Rys. 3. Porównanie struktury plików w obu aplikacjach testowych

5.2. Metryki kodu

Umieszczenie dużej liczby danych w tabeli wymaga zastosowania iteracji. W przypadku React wykorzystano

funkcję map() (Przykład 3), natomiast w Ember użyta została pętla {{#each}}, do której przekazano dane (Przykład 4).

Przykład 3. Wypełnienie tabeli danymi w React

{this.props.data.map((item, idx) => { return <tr key={idx}> {this.props.config.map((field, idx) => { return <td key={idx}>{item[field.key]}</td> })} </tr> })}

Przykład 4. Wypełnienie tabeli danymi w Ember

{{#each cryptocurrencies as |cryptocurrency|}} <tr> <td>{{cryptocurrency.name}}</td> <td>{{cryptocurrency.symbol}}</td> </tr>

{{/each}}

5.3. Szybko ć renderowania

Testy wydajno ciowe zostały przeprowadzone na dwóch platformach. Konfiguracja pierwszej platformy (laptop) jest

następująca:

procesor: Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz,

2401 MHz, Rdzenie: 2, Procesory logiczne: 4,

karta graficzna: Intel(R) HD Graphics 520,

pamięć RAMŚ 8GB, system operacyjny: Windows 10 Home.

Specyfikacja sprzętowa drugiej platformy (PC) stanowi:

procesor: Intel(R) Core(TM) i5-3570K CPU @ 3.40GHz,

3401 MHz, Rdzenie: 4, Procesory logiczne: 4,

karta graficzna: AMD Radeon HD 7900 Series,

pamięć RAMŚ 16GB,

system operacyjny: Windows 10 Pro.

Wszystkie testy zostały przeprowadzone na przeglądarce Google Chrome, w której znajdują się narzędzia deweloperskie. Posiada ona wiele przydatnych

funkcjonalno ci, między innymi możliwo ć uruchomienia

testów wydajno ci. Wynik testu wydajno ci ładowania strony został przedstawiony na rysunku 4.

Rys. 4. Przykładowy wynik testu wydajno ci ładowannia strony

Testy wydajno ciowe na małej liczbie danych

W tabelach 2 i 3 zostały przedstawione wyniki badania

wydajno ci na około 180 rekordach w aplikacji React.js na

laptopie i PC. Badane były czasy renderowania aplikacji oraz całkowity czas ładowania.

Tabela 2. Wyniki testów wydajno ciowych na małej liczbie danych w React na pierwszej platformie

Numer próby Czas rysowania

aplikacji

Całkowity czas ładowania

1 127.8ms 1638ms

2 138.8ms 1954ms

3 144.2ms 1973ms

4 148.8ms 2136ms

5 137.4ms 1739ms

redni czas 139.4ms 1888ms

Tabela 3. Wyniki testów wydajno ciowych na małej liczbie danych w React na drugiej platformie


aplikacji


1 95.2ms 1229ms

2 93.7ms 957ms

3 97.3ms 960ms

4 92.7ms 1130ms

5 95.6ms 1122ms


Wyniki badań szybko ci renderowania dla Ember.js

ukazane są w tabelach 4 i 5.

Tabela 4. Wyniki testów wydajno ciowych na małej liczbie danych w Ember na pierwszej platformie


aplikacji


1 72.9ms 1356ms

2 87.0ms 1573ms

3 72.4ms 1467ms

4 79.8ms 1686ms

5 77.0ms 1631ms



148 148

Tabela 5. Wyniki testów wydajno ciowych na małej liczbie danych w Ember na drugiej platformie


aplikacji


1 65.0ms 1080ms

2 74.4ms 1101ms

3 69.4ms 1029ms

4 70.5ms 997ms

5 70.6ms 1065ms


Wyniki testów na małej liczbie danych wskazują na to, że Ember.js lepiej sobie radzi z rysowaniem aplikacji przy takiej

liczbie rekordów (ok. 180 elementów), gdzie różnica redniego czasu na laptopie wynosiła około 63ms.

Dodatkowo lepszy procesor dużo bardziej pomaga React.js, ponieważ redni czas na laptopie wynosił 139.4ms, za na PC już 94.9ms. W Ember.js ta różnica wynosiła około 8ms.

Testy wydajno ciowe na dużych zbiorach danych

W tabelach 6 oraz 7 przedstawiono wyniki testów na dużych zbiorach danych, wynoszących ponad 2000 rekordów w aplikacji React na laptopie i PC.

Tabela 6. Wyniki testów wydajno ciowych na dużej liczbie danych w React na pierwszej platformie


aplikacji


1 219.5ms 2660ms

2 330.3ms 2976ms

3 226.0ms 2567ms

4 208.0ms 2818ms

5 228.8ms 2800ms


Tabela 7. Wyniki testów wydajno ciowych na dużej liczbie danych w React na drugiej platformie


aplikacji


1 185.6ms 1870ms

2 199.1ms 1959ms

3 189.4ms 1908ms

4 187.1ms 1941ms

5 182.0ms 1857ms


W tabelach 8 i 9 zostały zaprezentowane wyniki czasów rysowania dla aplikacji Ember kolejno na laptopie i PC.

Tabela 8. Wyniki testów wydajno ciowych na dużej liczbie danych w Ember na pierwszej platformie


aplikacji


1 595.1ms 4135ms

2 587.5ms 4004ms

3 908.7ms 4890ms

4 585.8ms 4392ms

5 499.7ms 4224ms


Tabela 9. Wyniki testów wydajno ciowych na dużej liczbie danych w Ember na drugiej platformie


aplikacji


1 493.5ms 3789ms

2 482.6ms 3713ms

3 466.3ms 3656ms

4 460.3ms 3610ms

5 453.1ms 3657ms


Wyniki na dużej liczbie danych, tj. 2000 rekordów,

prezentują się nieco odmiennie od tych na małej liczbie

danych, gdyż tym razem to React.js lepiej wypadł w czasie rysowania i ogólnym czasie ładowania aplikacji. redni czas rysowania w React był ponad dwa razy mniejszy niż w Ember

zarówno na laptopie jak i PC.

6. Wnioski

Po wykonaniu testów wydajno ciowych można stwierdzić, że bardzo ważną rolę odgrywa sprzęt, na którym testowane są aplikacje, gdyż na lepszej konfiguracji sprzętowej czas renderowania w aplikacji był mniejszy

o około 25%. Również ważną kwestią jest jaka liczba danych jest przetwarzana w aplikacji, ponieważ przy 180 rekordach w tabeli to Ember na obu platformach miał lepszy czas renderowania, za przy około 2000 rekordów React poradził sobie lepiej.

Dla aplikacji z małą liczbą danych to Ember.js wydaje się być lepszym frameworkiem. Jednak, gdy aplikacja musi wy wietlać dużą liczbę danych to React będzie lepszym wyborem. Zatem wybór technologii jest przede wszystkim zależny od tego, jaką aplikację programista chce stworzyć oraz tego, w jakim czasie będzie potrafił nauczyć się danego narzędzia.

Literatura

[1] A. Rauschmayer, Speaking JavaScript, O’Reilly, 2014. [2] Wykorzystano wykres porównujący popularno ć frameworków,

https://hotframeworks.com/languages/javascript/ [20.05.2018]

[3] https://www.jetbrains.com/phpstorm/ [20.05.2018]

[4] http://api.emitter.pl [20.05.2018]

[5] A. Banks, E, Porcello, Learning React, O’Reilly, 2017. [6] https://reactjs.org/ [20.05.2018]

[7] https://www.emberjs.com/ [20.05.2018]

[8] https://coinmarketcap.com/api/ [28.11.2018]

[9] https://jcsi.pollub.pl/jcsi2016/volume2/jcsi2(2016)98-103.pdf

[03.12.2018]

[10] https://blog.kollegorna.se/3-years-of-ember-6-months-of-react-

34ce909a5ce1 [03.12.2018]

JCSI 11 (2019) 149-154

Wysłane: 2019-04-01


149

Analiza porównawcza wybranych zagadnień programowania wymagających komunikacji międzyprocesowej i międzywątkowej

Kamil Wróbel*


Streszczenie. Poniższy artykuł przedstawia porównanie mechanizmów komunikacji i synchronizacji oferowanych w aplikacjach wielowątkowych oraz analogicznych rozwiązań opartych o komunikację międzyprocesową. Porównanie teoretyczne zestawiono z praktycznymi

klasycznymi problemami synchronizacji. Porównano dostępność mechanizmów komunikacji i synchronizacji w bibliotece Boost i w komunikacji międzyprocesowej IPC. Przedstawiono subiektywną ocenę stopnia trudności implementacji i porównanie wydajności.

Słowa kluczowe: wątki; procesy; BOOT; komunikacją międzyprocesowa; systemy operacyjne


Adres e-mail: [email protected]*

Comparative analysis of selected programming issues requiring inter-process and

inter-thread communication

Kamil Wrobel*


Abstract. The following article presents a comparison of multithread and multiprocess communication and synchronization. The theoretical

comparison was supported by the solutions of practical, classical synchronization problems. The availability of communication and

synchronization mechanisms in the Boost library and in IPC interprocess communication was compared.A subjective assessment of the

difficulty in implementation and applications performance was also presented.

Keywords: threads; processes; boost; IPC; operation systems


E-mail address: [email protected]*

1. Wstęp Systemy operacyjne zostały stworzone po to aby stanowić

połączenie pomiędzy warstwą sprzętową komputera a warstwą interfejsu użytkownika, która umożliwia mu dokonywanie interakcji z komputerem. W momencie uruchomienia

programu jest tworzony proces czyli aktywność, która jest odpowiedzialna za wykonanie zaimplementowanego zadania.

Pojedynczy proces stanowi całkowity kontekst, który jest niezbędnym elementem do prawidłowego wykonania programu. Aby móc osiągnąć wysoką wydajność oraz jednocześnie w efektowny sposób wykorzystać posiadane zasoby sprzętowe koniecznie jest wykonanie pewnych fragmentów kodu w sposób równoległy, przez co zastosowanie mechanizmów wielowątkowych i wieloprocesowych jest kluczowym czynnikiem, który umożliwia tworzenie wysokowydajnych aplikacji. Jednak

takie podejście do tworzenia aplikacji sprawiło, że powstał szereg nowych problemów związanych z komunikacją i synchronizacją powyższych mechanizmów. Bardzo ważne jest nie tylko zrozumienie samej problematyki aplikacji

współbieżnych, ale również zrozumienie współbieżności osobno w kontekście wątku i procesu. Oba mechanizmy opierają się na niskopoziomowych funkcjach jakie są dostarczane przez system operacyjny. Pojęcie zasady ich działania jest koniecznym warunkiem, który umożliwia tworzenie wysokowydajnych i spójnych aplikacji. Sposoby

pisania aplikacji przy wykorzystaniu obydwu mechanizmów bardzo się od siebie różnią nie tyko pod względem samego aspektu programowania ale również różnych przypadków zastosowania.

Na podstawie powyższych stwierdzeń można wywnioskować, że implementacja aplikacji współbieżnych jest o wiele trudniejsza w stosunku do aplikacji opierających się na pojedynczych wątkach i procesach, ale korzyści jakie dzięki temu można uzyskać są z pewnością wartę zachodu.


W skład literatury, która pozwoliła dogłębnie przyjrzeć się problematyce artykułu wchodzą zarówno książki opisujące od podstaw działanie systemów operacyjnych [6], wątków i procesów oraz wszystkie inne tematy bezpośrednio z nimi związane, jak i publikacje naukowe pochodzące z serwisu Google Schoolar. Uzupełnieniem literatury jest zestaw prezentacji z wykładów „Systemy operacyjne” [4] oraz „Programowanie równoległe i rozproszone” [5] pochodzący z Politechniki Lubelskiej oraz szeroko dostępne artykuły w serwisie Wikipedia. Literatura jest również wspierana poprzez oficjalną dokumentację dla systemu operacyjnego i języków programowania [7] które zostały wykorzystane w celu przeprowadzenia badań.

Journal of ComputerSciencesInstitute

150

Bardzo duża liczba pozycji z literatury skupia się opisie

zasady działania wątków i procesów. Prezentują one sposób działania każdego z mechanizmów, który często jest poparty praktycznymi przykładami. Jednak w dzisiejszych czasach mimo bardzo rozwiniętej tematyki programowania współbieżnego w dalszym stopniu trudno znaleźć pozycję literaturową, która stanowiłaby porównanie tych dwóch mechanizmów jakimi są wątki i procesy.

3. Systemy operacyjne i współbieżność

W najprostszy sposób system operacyjny można zdefiniować jako środowisko, które przyjmuje działania wygenerowane przez użytkownika za pośrednictwem programów, które w dalszej kolejności są przetwarzane i zwracane z powrotem w postaci wyników. Do głównych zadań systemu operacyjnego należy zaliczyć:

kontrolowanie pamięci operacyjnej dla działających zadań;

obsługa sprzętu oraz urządzeń peryferyjnych; dostarczenie odpowiednich mechanizmów służących do

prawidłowej komunikacji oraz synchronizacji między zadaniami;

gromadzenie i zarządzanie danymi.

Współbieżność pozwala na to aby dany program był w stanie realizować kilka zadań jednocześnie w celu osiągnięcia jak największej wydajności. Opiera się ona na fakcie istnienia jednocześnie kilku wątków bądź procesów, które operują na współdzielonych zasobach. Z tego powodu ważnym warunkiem jest ich odpowiednia synchronizacja

i komunikacja, ponieważ zarówno wątki jak i procesy są nawzajem od siebie zależne. Zastosowanie współbieżności wprowadziło charakterystyczne dla tego zagadnienia problemy, jednym z najprostszych i najbardziej

rozpoznawalnych przykładów jest scenariusz

konsumenta - producenta. W tym problemie istnieje jeden lub

wiele procesów konsumenta i producenta, które razem współdzielą wspólną strukturę danych. Producent ma za cel wyprodukować zasób i umieścić go w strukturze tak, aby konsument mu go pobrać i skonsumować. Problemem jaki należy rozwiązać w tym zadaniu jest to, aby konsument nie pobierał danych w momencie kiedy nie ma ich w buforze,

a producent nie nadpisywał nie odebranych danych w momencie kiedy bufor jest pełny.

Niepoprawna synchronizacja wątków i procesów może doprowadzić do takich problemów jak zakleszczenia (ang. deadlock) – czyli sytuacji w których dwa lub więcej procesów / wątków czeka na siebie nawzajem przez co żaden z nich nie jest w stanie się zakończyć, bądź zagłodzenia (ang. resourcestarvation) – czyli zjawiska w którym proces lub wątek nie jest w stanie ukończyć swojego zadania ponieważ nie może on uzyskać dostępu do procesora lub współdzielonego zasobu.

4. Procesy i wątki

Proces zdefiniowany jest jako pojedynczy egzemplarz

wykonywanego programu ściśle związanego z zadaniem zleconym mu do wykonania. Rozpoczyna on swoje działanie w momencie wydzielenia mu przestrzeni adresowej oraz po

przekazaniu procesorowi sygnału, aby ten zaczął

interpretować odpowiedni kod. Każdy uruchomiony proces posiada swojego przodka (czyli proces z którego został on utworzony) i za pomocą funkcji systemowej fork() jest

w stanie utworzyć proces potomny. Proces w momencie zakończenia działania zwraca do systemu operacyjnego odpowiednią wartość liczbową mówiąca o kodzie zakończenia procesu. Liczba 0 oznacza poprawne jego zakończenie, natomiast każda inna wartość stanowi odpowiedni kod błędu.

Wątek natomiast można zdefiniować jako fragment kodu, który wykonuje się równolegle w obrębie jednego procesu. Wątki są również mechanizmem dostarczanym

i obsługiwanym przez system operacyjny, odstępstwem od tej zasady są wątki, które są zarządzane przez maszynę wirtualną w takich językach jak java lub python. Wątki podobnie jak procesy mają swój unikatowy identyfikator jednak w ich

przypadku jest nim ciąg alfanumeryczny.

Wątki i procesy łączy i dzieli wiele podobieństw i różnic, do tych pierwszych można zaliczyć fakt, że wątek współdzieli większość zasobów (przestrzeń adresową, struktury danych systemowych itp.) jakie zostały przydzielone procesowi,

wyjątkiem jest czas procesora, który jest przydzielany odrębnie każdemu wątkowi, warto również zaznaczyć to, że zakończenie działania wątku nie powoduje zwolnienia zasobów, ponieważ należą one do procesu. Natomiast do różnic między tymi dwoma mechanizmami można zaliczyć fakt, że wątki wymagają znacznie mniej zasobów i czasu do ich utworzenia niż procesy. Jednak jedną z najważniejszych różnic jaka dzieli wątki i procesy jest ich sposób komunikacji. Przesłanie pewnej ilości informacji między dwoma wątkami ogranicza się do odwołania do odpowiedniego wskaźnika danej struktury w której są przechowywane informacje, dodatkowo procesor zapewnia atomowość takich operacji. Natomiast przekazywanie danych pomiędzy dwoma procesami jest o wiele trudniejsze, wymusza to wykorzystanie

mechanizmów komunikacji międzyprocesowej (ang. Inter processcommunication), które bazują na budowaniu dynamicznych struktur w pamięci systemów pozwalających na wymianę informacji pomiędzy procesami.

4.1. Biblioteka Boost

Biblioteka Boost w znacznym stopniu poszerza

możliwości języka C++ poprzez zagregowanie szeregu różnych modułów zaczynając od ogólnego przeznaczenia kończąc na bibliotekach dedykowanych programowaniu współbieżnemu jaką jest Boost.Thread, która stanowi warstwę abstrakcji pozwalająca współbieżne wykonywanie zadań.

Wątek w bibliotece Boost jest reprezentowany przez klasę boost::thread, w celu utworzenia i uruchomienia nowego

wątku należy wywołać następujący konstruktor boost::threadnazwaWatku(&nazwaFunkcji, arg1, arg2, arg3,

…). Pierwszym parametrem jest adres funkcji, która ma się wykonać w oddzielnym wątku, natomiast drugim opcjonalnym parametrem są argumenty, jakie są przekazywane do funkcji określonej pierwszym argumentem. W momencie gdy główny (wykonujący się w metodzie

main()) wątek dojdzie do momentu utworzenia drugiego wątku poprzez jeden z wcześniej wymienionych sposobów, nowo utworzony wątek rozpocznie wykonywanie kodu funkcji przekazanej jako parametr. Kluczową funkcją jaką można znaleźć w klasie thread jest funkcja thread::join()


151

w momencie kiedy pierwszy wątek wywoła tą metodę na obiekcie klasy thread, reprezentujący drugi działający wątek, pierwszy wątek wstrzyma swoje działanie do momentu gdy praca drugiego wątku zostanie zakończona.

Muteks umożliwia wykonywanie sekcji krytycznej kodu,

czyli takiego fragmentu, który powinien być wykonywany jednocześnie tylko i wyłącznie przez jeden wątek. Jest reprezentowany przez klasę mutex. Jego dwiema

najważniejszymi metodami są metody lock() i unlock().

Metoda lock() z nich blokuje wątek na obiekcie go wywołującym i wstrzymuje pozostałe wątki do momentu aż wątek obecnie wykonujący sekcję krytyczną wywoła metodę unlock().

Lock Guard wykorzystuje muteks w swojej implementacji

(przekazywany jako argument konstruktora) i pozwala

automatyczne zwolnienie blokady muteksu z momentem

końca zakresu jego działania, dzięki temu podczas wystąpienia wyjątku muteks nie jest blokowany.

Unique Lock w przeciwieństwie do Lock Guard (który bezwarunkowo zakłada blokadę na dany zakres) pozwala na

zablokowanie muteksu, sprawdzenie stanu i jego ewentualne

odblokowanie podczas oczekiwania na spełnienie warunku, z tego powodu jest często wykorzystywany z zmienną warunkową.

Zmienna warunkowa jest mechanizmem, który został przeznaczony do sytuacji, w których jeden lub więcej wątków oczekuje na zajście jakiegoś warunku do momentu, kiedy inny wątek go spełni i wywoła odpowiednią metodę pozwalającą powiadomić i odblokować wcześniej zablokowane wątki. Połączone są one z metodami informowania o zmianie

wartości zmiennej bez angażowania czasu procesora, który bez takiej informacji musiałby nieustannie sprawdzać czy warunek został spełniony lub nie. Zmienna warunkowa jest używana zawsze w parze z muteksem. W booscie zmienna

warunkowa jest reprezentowana poprzez klasę condition_variable, posiada ona metodę wait(), do której przekazuje się mutex, umożliwia wstrzymanie wykonywania kodu przez dany wątek do momentu, aż na zmiennej tego obiektu nie zostanie wywołana metoda notify_one() lub

notify_all(), która jest odpowiedzialna za wznowienie

działania wcześniej wstrzymanych wątków.

Bariera [3] jest mechanizmem służącym do synchronizacji grupy wątków. Wątki po dojściu do bariery są na niej zatrzymywane do momentu aż ostatni z nich jej nie osiągnie, po tym wszystkie wątki są zwalniane i mogę kontynuować dalej swoją pracę.

Semafor jest to natomiast abstrakcyjny mechanizm,

z którego korzystają zarówno wątki jak i procesy. Znajduje on zastosowanie podczas gdy wątki/procesy korzystają z wspólnego zasobu, dzięki czemu zapobiega on wykonaniu

niechcianych operacji na określonym zbiorze danych. Semafor jest chronioną nieujemną liczbą całkowitą lub zmienną logiczną. W przypadku wykorzystania semafora w powiązaniu z danym zasobem, jego początkową wartość jest ustawiana na liczbę dostępnych zasobów tego typu. W chwili gdy wątek/proces chce skorzystać z danego zasobu, musi on sprawdzić czy wartość semafora jest dodatnia, co oznacza, że zasób jest dostępny. Natomiast gdy jego wartość wynosi zero

oznacza to, że nie ma dostępnych zasobów i wątek/proces musi czekać aż inny tego typu mechanizm zwolni zasób i zwiększy wartość semafora. Na semaforze można wykonać dwie atomowe operacje:

opuszczenie semafora (V) – zwiększa wartość zmiennej semaforowej, przez co współdzielony zasób staje się dostępny dla innych wątków/procesów;

podnoszenie semafora (P) – jeśli wartość semafora wynosi zero, metoda blokuje wywołujący ją wątek/proces do momentu kiedy zostanie wywołana metoda opuszczenia semafora, po czym zmniejsza to wartość. Jeśli wartość jest większa od zera semafor nie blokuje wątku/procesu tylko

zmniejsza jego wartość.

Biblioteka Boost sama nie dostarcza gotowej

implementacji semafora, jednak dzięki niej można stworzyć własną implementację wykorzystując wcześniej omawiane mechanizmy synchronizacji.

4.2. Mechanizmy IPC

System operacyjny dostarcza wszystkie funkcje

pozwalające na zarządzanie procesami [8], do najważniejszej z nich należy funkcja fork() służąca do utworzenia nowego procesu, który różni się od procesu macierzystego zazwyczaj tylko identyfikatorem PID. Kolejnymi istotnymi funkcjami

służącymi do zarządzania procesami jest funkcja getpid(),

która pozwala na pobranie identyfikatora PID obecnego procesu oraz funkcja wait(), która blokuje proces macierzysty ją wywołujący do momentu, aż proces potomny zostanie zakończony [2] przez co będą dostępne informacje o statusie jego zakończenia. System operacyjny udostępnia również szereg mechanizmów służących do przesyłania danych między procesami.

Potoki nienazwane [1] oraz nazwane są to dwa podstawowe mechanizmy służące do jednokierunkowego

przesyłania i odbierania danych między procesami. Główną różnicą między nimi jest fakt, że potok nienazwany istnieje tak długo jak jest otwarty (do momentu zamknięcia wszystkich jego deskryptorów) natomiast potok nazwany istnieje jako plik w drzewie katalogów i jest identyfikowany przez jego nazwę. Funkcją służącą do utworzenia potoku nienazwanego (i jednoczesnego jego otwarcia) jest funkcja pipe(), która przyjmuje jako argument dwuelementową tablice liczb całkowitych i wypełnia ją w momencie wywołania kolejno

deskryptorem potoku do odczytu oraz do zapisu. Aby wysłać dane do potoku należy posłużyć się funkcją write() natomiast,

aby odczytać dane z potoku należy wywołać komplementarną metodę read(). Do tworzenia potoków nazwanych służy natomiast metoda mkfifo(). Bardzo istotną różnicą między potokiem nienazwanym a potokiem nazwanym jest fakt, że deskryptor potoku nazwanego w momencie jego utworzenia

nie jest otwierany w przeciwieństwie do potoku nienazwanego, przez co wymusza na programiście użycie wcześniej wspomnianej funkcji o nazwie open().

Kolejki komunikatów w odróżnieniu od potoków są

dwukierunkowe, co oznacza, że procesy komunikujące się ze sobą mogą przesyłać dane do siebie nawzajem, ponadto przesyłają one ustruktyryzowane porcje danych, gdzie potoki

przesyłają dane w sposób niesformatowany, posiadają one również swój unikatowy identyfikator, który znajduje się


152

w systemowej tablicy zawierającej obiekty IPC. Proces nadający komunikaty może je wysłać nawet jeśli, żaden z innych procesów nie czeka na ich odbiór (w tym czasie każdy wysłany komunikat jest buforowany w kolejce). Są one przechowywane tak długo jak długo nie zostaną odebrane lub jak długo kolejka komunikatów nie zostanie usunięta. Proces odbierający komunikat ma możliwość odebrania pierwszego

komunikatu dodanego do kolejki bądź komunikatu o określonym identyfikatorze. Do metod obsługujących kolejki komunikatów należą:

msgget() - funkcja służąca do utworzenia nowej kolejki, bądź do pobrania już istniejącej;

msgctl() - funkcja służąca do zarządzania kolejką; msgsnd() - służy do wysłania wiadomości do kolejki

komunikatów; msgrcv() - pozwala na pobranie wiadomości z kolejki

komunikatów.

Ogólna zasada działania semaforów została przybliżona w sekcji, która opisuje wątki. System UNIX pozwala tworzyć semafory jako zestaw składający się z pojedynczego semafora

jak i kilku pojedynczych semaforów. Operacje na semaforach można wykonać poprzez zastosowanie poniższych funkcji:

semget() - służy do utworzenia lub pobrania istniejącej tablicy semaforów;

semop() - funkcja służąca do zmiany wartości semafora; semctl() - pozwala na wykonywanie takich operacji jak

ustawianie początkowej wartości semafora, badanie praw dostępu do niego.

5. Metoda badawcza

Metoda badawcza opiera się na analizie teoretycznej wiedzy pozyskanej z literatury, która została poparta poprzez programistyczne rozwiązanie typowych problemów związanych z współbieżnością:

Problem producenta – konsumenta;

Problem wielu producentów – jednego konsumenta;

Problem jednego producenta – wielu konsumentów; Problem czytelników i pisarzy; Problem pięciu ucztujących filozofów.

Każdy z powyższych problemów został rozwiązany osobno przy użyciu wątków i procesów, poprzez wykorzystanie odpowiednich funkcji udostępnianych przez powyższe mechanizmy, prezentuje to poniższa tabela: Tabela 1. Mechanizmy wykorzystane przy rozwiązywaniu każdego z zadań.

Problem Mechanizmy wykorzystane przy

implementacji

Wątki Procesy

Jeden konsument –

Jeden producent

Mutex Potok nienazwany

Wielu producentów-

Jeden konsument

Mutex, Unique Lock,

Conditional Variable

Potok nazwany

Jeden producent –

Wielu konsumentów

Mutex, Lock Guard,

Barriera

Potok nazwany

Czytelnicy i pisarze Semafor (Muteks,

ConditionalVariable)

Kolejka komunikatów

Pięciu filozofów Semafor (Muteks,

Conditional

Variable), Barriera

Semafor

5.1. Przykładowy program

Przykładowy program będzie stanowił rozwiązanie klasycznego problemu konsumenta – producenta [9],

w którym producent będzie produkował kolejne dane będące liczbami całkowitymi inkrementowanymi o jeden, po czym

konsument będzie je odczytywał. Przykład 1. Kod programu rozwiązujący problem konsumenta – producenta

przy pomocy wątków.

boolwyprodukowanoWszystkieDane = false; int dana = 0; constintdanychDoWyprodukowania = 10; mutexmutexWatku; void watekProducent() { cout<< "Tworzewatekproducenta: " <<this_thread::get_id() <<endl; while (dana <danychDoWyprodukowania) {

mutexWatku.lock(); dana++; cout<< "Watekproducenta " <<this_thread::get_id() << " wyprodukowaldane " << dana <<endl; mutexWatku.unlock(); this_thread::sleep_for(chrono::milliseconds(5)); } wyprodukowanoWszystkieDane = true; cout<< "Koniec pracy producenta " <<this_thread::get_id() <<endl; } void watekKonsument() { cout<< "Tworzewatekkonsumenta: " <<this_thread::get_id() <<endl;

while (1) { mutexWatku.lock(); cout<< "Watekkonsumenta " <<this_thread::get_id() << " odczytujedane " << dana <<endl; mutexWatku.unlock(); this_thread::sleep_for(chrono::milliseconds(5)); if (wyprodukowanoWszystkieDane) { break; } } cout<< "Koniec pracy konsumenta " <<this_thread::get_id() <<endl; } int main() { thread pierwszyWatek(watekProducent); this_thread::sleep_for(chrono::milliseconds(1)); threaddrugiWatek(watekKonsument);

pierwszyWatek.join(); drugiWatek.join(); exit(0); }

Program posiada trzy funkcje watekProducent(),

watekKonsument() oraz main(), która kolejno uruchamia dwie poprzednie metody w oddzielnych wątkach po czym czeka aż ich praca się zakończy. Do wykonania sekcji krytycznej kodu został wykorzystany muteks, który blokuje w wątku producenta moment, w którym zmienna dana jest

inkrementowana, po czym zwalnia on blokadę, pozwalając


153

wątkowi konsumenta odczytać zainkrementowaną zmienną. Wątki działają do momentu osiągnięcia przez zmienną dana

zadeklarowanej wartości 10.

Rozwiązanie tego samego problemu w przypadku

procesów wygląda następująco: Przykład 2. Kod programu rozwiązujący problem konsumenta – producenta

przy pomocy procesów.

constintdanychDoWyprodukowania = 10; int dana = 0; intconstwielkoscBuforu = 50; void procesProducent(intpdesk[2]) { char str[wielkoscBuforu]; while (dana <danychDoWyprodukowania) { dana++; sprintf(str, "%d", dana); printf("Producent %d produkuje dane: %s\n", getpid(), str);

write(pdesk[1], str, wielkoscBuforu); if (dana == danychDoWyprodukowania) { break; } } } void procesKonsument(intpdesk[2]) { char buf[wielkoscBuforu]; while (dana <danychDoWyprodukowania) { read(pdesk[0], buf, wielkoscBuforu); printf("Konsument %d konsumuje dane: %s\n", getpid(),

buf); dana = atoi(buf); if(dana == danychDoWyprodukowania){ break; } } } main() { intpdesk[2]; pipe(pdesk); printf("Tworze proces producenta i konsumenta\n"); if (fork() == 0) { procesProducent(pdesk); printf("Procesproducenta %d konczydzialanie\n", getpid()); exit(0); } if (fork() == 0) {

procesKonsument(pdesk); printf("Proces kosumenta %d konczydzialanie\n", getpid()); exit(0); } wait(NULL); printf("Procesy potomne procesu %d zakonczyly swoje dzialanie\n", getpid()); exit(0); }

Budowa struktury programu jest bardzo zbliżona jak w przypadku wątków, metoda main() tym razem tworzy dwa

oddzielne procesy potomne (za pomocą metody fork()), po

czym proces macierzysty czeka na zakończenie ich pracy poprzez wywołanie metody wait(). W celu zapewnienia

synchronizacji i komunikacji pomiędzy procesami konsumenta i producenta został wykorzystany potok nienazwany. Proces producenta w momencie wyprodukowania

danej zapisują ją w potoku za pomocą metody write(), jeżeli dana została już przesłana do potoku to proces konsumenta odczytuje ją za pomocą metody read(), jeżeli potok jest natomiast pusty to proces wstrzymuje swoje działanie na tej metodzie do momentu zapisania danych do potoku.

6. Wnioski

Wnioski zostały opracowane na podstawie zgromadzonych

materiałów oraz wyników uzyskanych wskutek rozwiązania praktycznych problemów, pozwoliły one porównać wątki i procesy pod względem sposobów komunikacji i synchronizacji, stopnia trudności implementacji oraz wydajności.

Komunikacja pomiędzy procesami w stosunku do

komunikacji pomiędzy wątkami jest w znacznym stopniu trudniejsza. Jak można zauważyć na praktycznym przykładzie, że przesłanie komunikatu pomiędzy wątkami ogranicza się do odwołania do odpowiedniej zmiennej, która dla każdego wątku w obrębie jednego procesu jest ulokowana pod tym samym adresem w pamięci komputera. Sytuacja wygląda całkowicie inaczej w przypadku procesów, ponieważ w momencie utworzenia nowego procesu (wywołaniu funkcji fork()), jest ona nowo lokowany w pamięci, przez co wymusza

to korzystanie z wyżej poznanych mechanizmów komunikacji międzyprocesowej.

W przypadku procesów funkcje zapewniające synchronizacje są udostępniane przez system operacyjny i jednocześnie są funkcjami służącymi do komunikacji np. wywołanie metody read() na potoku wstrzymuje proces do

momentu umieszczenia danych poprzez wywołanie metody write(). Mechanizmy synchronizacji dla wątków są dostarczane przez bibliotekę boost, która udostępnia szereg różnych funkcji pozwalających uzyskać różne zachowania

wątków w zależności od potrzeb.

Istotnym kryterium porównawczym jest stopień trudności zrozumienia działania poszczególnych mechanizmów oraz ich implementacja. Należy się tutaj odwołać do różnic pomiędzy językiem C++ i C. Język C++ jest językiem obiektowym i to

dla środowiska tego języka została stworzona biblioteka boost, dzięki wsparciu obiektowości pozwala on również podzielić aplikacje na poszczególne klasy, co sprawia, że kod staje się bardziej przejrzysty oraz w większym stopniu podatny na zmiany. Język C natomiast jest językiem strukturalnym, przez co stworzony kod może nie być tak dobrze czytelny w stosunku do kodu stworzonego w językach obiektowych.

Wydajność jest czwartym porównawczym czynnikiem, który przeważa na korzyść wątków. Wynika to z dużego kosztu utworzenia (lub zakończenia) procesu w stosunku do wątku, dzieje się tak dlatego ponieważ w momencie utworzenia nowego procesu, jest mu przydzielany całkowity nowy obszar pamięci, natomiast każdy nowo utworzony wątek współdzieli ten sam segment pamięci, który został przydzielony procesowi go tworzącemu.


154

Bazując na wyciągniętych wnioskach można stwierdzić, że wątki przeważają nad procesami pod różnymi aspektami, chociaż w praktyce jest to mocno uzależnione od przypadku zastosowania wyżej wymienionych mechanizmów.

Literatura

[1] Brzeziński Jerzy, Wawrzyniak Dariusz. Politechnika Poznańska. Materiały z zajęć Systemy Operacyjne. http://wazniak.mimuw.edu.pl/index.php?title=Systemy_operacy

jne. 2006.

[2] Fusco John, Linux, Niezbędnik programisty. Helion 2009.

[3] Karbowski A., Niewiadomska-Szynkiewicz E., Programowanie

równoległe i rozproszone. Oficyna Wydawnicza Politechniki Warszawskiej 2009

[4] Pańczyk Maciej, Politechnika Lubelska Materiały z przedmiotu Systemy Operacyjne 2014.

[5] Pańczyk Maciej, Politechnika Lubelska Materiały z przedmiotu Programowanie Równoległe i Rozproszone 2014.

[6] Love R., Linux, Programowanie systemowe. Helion. Gliwice

2008.

[7] Williams Anthony, BotetEscriba Vicente. Official

documentation for Boost Library - Chapter 39. Thread.

http://www.boost.org/doc/libs/1_68_0/doc/html/thread.html.

2007.

[8] Bershad, Brian N., et al. "User-level interprocess

communication for shared memory multiprocessors." ACM

Transactions on Computer Systems (TOCS) 9.2 (1991): 175-

198.

[9] Guźlewski Z., Weiss T., Programowanie współbieżne i rozproszone w przykładach i zadaniach. WNT, Warszawa 1993.

JCSI 11 (2019) 155-162

Wysłane: 2019-04-11


155

Analiza możliwości współpracy aplikacji mobilnych z usługami sieciowymi typu REST i Web Service

Mateusz Roman Daraż*, Piotr Kopniak


Streszczenie. W artykule przedstawiono wyniki przeglądu bibliotek na platformę Android, wspomagających integrację z usługami sieciowymi typu REST i SOAP. Przeprowadzono analizę wydajności i złożoności programów klienckich korzystających z najpopularniejszych rozwiązań.

Metody badawcze oparto na autorskiej aplikacji mobilnej umożliwiającej symulację komunikacji asynchronicznej. Wynikiem badań jest analiza porównawcza bibliotek, ułatwiająca wybór adekwatnych rozwiązań.

Słowa kluczowe: aplikacje mobilne; Android; SOAP; REST



Analysis of the possibilities of cooperation of mobile applications with network

services of the type REST and Web Service

Mateusz Roman Daraż*, Piotr Kopniak


Abstract. The article presents the results of a review of libraries for the Android platform, supporting the integration with REST and SOAP

network services. An analysis of the performance and complexity of client programs using the most popular solutions. The research methods

were based on the author's mobile application that enable the simulation of asynchronous communication. The result of the research

is a comparative analysis of libraries, that facilitate the selection of adequate solutions.

Keywords: mobile applications; Android; SOAP; REST



1. Wstęp

Dynamiczny rozwój rozwiązań mobilnych opartych na usługach sieciowych, stawia przed architektami systemów i programistami aplikacji mobilnych, coraz wyższe wymagania dotyczące implementacji, wydajności oraz skalowalności programów. W praktyce budowa systemów mobilnych, wiąże się z wykorzystaniem oprogramowania wspomagającego integrację, a co za tym idzie koniecznością wyboru adekwatnych rozwiązań. Zastosowanie odpowiedniej technologii jest istotne zarówno w kontekście aplikacji klienckiej, jak również usług sieciowych z którymi współpracuje.

Niniejszy artykuł pokazuje jak ważnym problemem

są możliwości gotowych bibliotek systemowych

i zewnętrznych, wykorzystanych do budowy programów

mobilnych zintegrowanych z usługami typu REST i SOAP.

Bada prawdziwość tezy, mówiącej, że usługi sieciowe typu REST są lepszym rozwiązaniem od usług SOAP w przypadku korzystania z nich poprzez mobilne aplikacje klienckie.

Podstawę do użycia odpowiedniej technologii stanowi jej wydajność, którą analizowano na podstawie czasu dostępu do danych zawartych w przetworzonej odpowiedzi serwera. Poza

tym, ze względu na rosnące wymagania odnośnie

funkcjonalności, jak i prostoty obsługi aplikacji nie bez

znaczenia pozostaje kwestia złożoności implementacyjnej, która jest istotnym elementem procesu wytwórczego.

Wykonane analizy porównawcze, przedstawiają możliwości implementacyjne jakimi dysponują twórcy programów mobilnych i ułatwiają zastosowanie rozwiązania,

które spełni wymagania stawiane przed systemem. Badano

oprogramowanie na popularną platformę Android, posiadającą największy udział w rynku mobilnych systemów operacyjnych, według statystyk organizacji StatCounter GlobalStats, który w lutym 2019 roku wynosił 74,15 % [1].

W ramach prac badawczych przeprowadzono analizę

skomplikowania programów klienckich wykonaną w oparciu o metryki statyczne oraz analizę wydajnościową, sprawdzające

prawdziwość poniższych hipotez:

1) programy mobilne zintegrowane z usługami typu SOAP są bardziej skomplikowane od wykonujących te same czynności aplikacji zintegrowanych z usługami REST;

2) rozmiar aplikacji mobilnych współpracujących

z usługami typu REST jest mniejszy od programów zintegrowanych z usługami w standardzie SOAP;

3) programy mobilne zintegrowane z usługami sieciowymi typu REST, działają szybciej od programów korzystających z usług SOAP.


156 156

2. Usługi sieciowe

Zgodnie z definicją międzynarodowej organizacji World Wide Web Consortium (W3C) [2], zajmującej się opracowywaniem standardów i zasad dotyczących Internetu, webservice jest zestawem oprogramowania zaprojektowanym

do wsparcia wymiany danych pomiędzy maszynami poprzez sieć, zazwyczaj z wykorzystaniem protokołu HTTP i języka XML oraz innych ustandaryzowanych technologii związanych z siecią [3].

Integracja usług wymaga użycia odpowiednich metod komunikacyjnych, które oferują efektywną integrację komponentów. Metody mają zagwarantować efektywność zarówno w działaniu i konfiguracji programów jak również w procesie ich wytwarzania. Stosowane technologie

komunikacji obejmują standardy usług sieciowych RESTful Web services (RS WS) oraz XML Web services (XML WS).

Standard XML Web services w zestawieniu ze standardem

RESTful Web services wyróżnia się większą złożonością konfiguracji, co wymaga od deweloperów wykorzystania skomplikowanych bibliotek, których zadaniem jest budowanie

wiadomości SOAP. Z kolei prostota konfiguracji charakterystyczna dla REST, wymaga kontroli i prawidłowej obsługi zawartości przesyłanych treści [4]. Bez względu na wykorzystywane rozwiązanie, konsument i dostawca usługi

muszą być zgodni co do semantyki przesyłanych danych.

3. Konfiguracja środowiska badawczego

Maszyna wirtualna pełniąca rolę serwera usług sieciowych, działa w oparciu o platformę Ubuntu Server.

W ramach systemu pracuje serwer bazy danych MariaDB,

który stanowi magazyn danych dla usług sieciowych. Z kolei

same usługi są udostępniane za pomocą serwera Apache.

Parametry wirtualnego serwera:

Procesor: Intel Core i5 2,4 GHz (1 rdzeń) Pamięć RAM: 2048 MB

Dysk twardy: SSD (rozmiar wirtualny 20 GB).

Karta sieciowa Wi-Fi: Intel PRO/1000 (mostkowana)

Oprogramowanie wirtualnego serwera:

System operacyjny: Ubuntu Server 18.10

Serwer bazy danych: MariaDB 10.1.29

Serwer HTTP: Apache 2.4.34

PHP: 7.2.10

Tak jak w przypadku usług sieciowych, aplikacja mobilna

działa na urządzeniu wirtualnym (typu telefon),

uruchamianym za pomocą menadżera Android Virtual Device (AVD), wbudowanego w środowisko Android Studio.

Parametry wirtualnego urządzenia mobilnego:

Model telefonu: Nexsus 5X

Rozdzielczość: 1080 x 1920: 420dpi System operacyjny: Android 8.1 x86 (Oreo)

Wersja API: 27

4. Przegląd bibliotek

W przeglądzie nie uwzględniano oprogramowania o względnie małej popularności oraz bibliotek przestarzałych takich jak kSOAP, RoboSpice oraz HttpClient, zastąpionych

przez nowsze oprogramowanie. Inspekcja dotyczyła zarówno bibliotek działających jako standardowy klient HTTP, jak również bibliotek specjalistycznych, zaprojektowanych do współpracy z usługami sieciowymi konkretnego rodzaju.

Zestawienie nie obejmuje bibliotek takich jak Picasso czy

Fresco, dedykowanych do obsługi obrazów. Wyniki przeglądu przedstawiono w tabeli 1.

Tabela 1. Biblioteki wspomagające integrację z usługami sieciowymi

Nazwa Wersja Rodzaj Zastosowanie

Android HTTP b.d. Systemowa Ogólne

Android Volley 1.1.1 Zewnętrzna Ogólne

OkHttp 3.12.1 Zewnętrzna Ogólne

Loopj 1.4.9 Zewnętrzna Ogólne

Retrofit 2.5.0 Zewnętrzna Spec. dla REST

kSOAP2 3.6.3 Zewnętrzna Spec. dla SOAP

Przy uwzględnieniu aspektu praktycznego, wyselekcjonowano siedem kryteriów, na podstawie których wykonano analizę porównawczą dostępności podstawowych mechanizmów (tabela 2). Uwzględniano wyłączenie funkcje wspierane natywnie, czyli takie, które nie wymagają użycia przez dewelopera dodatkowych komponentów. Przykładowo biblioteki Android HTTP i kSOAP2, pozwalają na obsługę żądań asynchronicznych, wyłącznie po zastosowaniu klasy AsyncTask, na podstawie czego stwierdzono, że nie posiadają wbudowanej funkcji do obsługi komunikacji asynchronicznej. Wyjątkiem są rozwiązania, w których wspomniane komponenty zostały użyte wewnątrz badanej biblioteki

i stanowią jej integralną cześć.

Tabela 2. Porównanie funkcjonalności bibliotek

ądan

ia sy

nchr

onic

zne

ądan

ia a

sync

hron

iczn

e

Kol

ejko

wan

ie ą

dań

Prio

ryte

ty ą

dań

Po

na

wia

nie

Pule

wąt

ków

Pam

ięć p

odrę

czna

Android HTTP tak nie nie nie nie nie nie

Volley tak tak tak tak tak tak tak

OkHttp tak tak tak nie tak tak tak

Loopj tak tak tak nie tak tak tak

Retrofit tak tak tak nie tak tak tak

kSOAP2 tak nie nie nie nie nie -

Funkcja ponawiania jest istotna ze względu na pewność komunikacji i umożliwia ponowne wysyłanie żądań, w przypadku problemów z połączeniem sieciowym. Z kolei mechanizm ustawiania priorytetów ustala kolejność obsługi żądań, zaś pule wątków zapewniają ich równolegle przetwarzanie zwiększając wydajność programów. Biblioteki korzystające z pamięci podręcznej, umożliwiają tymczasowe przechowywanie danych w pamięci urządzenia, dzięki czemu mogą być one ponownie użyte, co skraca czas dostępu do


157 157

danych (brak informacji dla kSOAP2). Z punktu widzenia

użyteczności, ważne jest również zapewnienie obsługi żądań asynchronicznych, które nie są wykonywane w głównym wątku programu oraz żądań synchronicznych, mających

zastosowanie w procesach wykonywanych sekwencyjnie.

W wyniku przeglądu do przeprowadzenia badań wydajności i złożoności implementacyjnej zakwalifikowano

biblioteki Volley, Retrofit oraz kSOAP2. Rozwiązania wyselekcjonowano na podstawie ich popularności, która wynika zarówno z funkcjonalności jak również ze specjalistycznego przeznaczenia, które gwarantuje łatwość integracji z usługami REST i SOAP. Volley ma szerokie

zastosowanie ze względu rozbudowaną funkcjonalność, z kolei Retrofit oferuje wsparcie dla technologii REST, która zyskuje na popularności wraz z szybkim rozwojem aplikacji mobilnych. Tymczasem kSOAP2 jest jedyną biblioteką na

platformę Android liczącą się na rynku, zaprojektowaną do współpracy z usługami typu SOAP.

5. Metryki oprogramowania

Analizę porównawczą bibliotek wykonano w oparciu o metryki dynamiczne i metryki statyczne. Metryka jest

liczbową charakterystyką oprogramowania pozwalająca na ilościową ocenę produktów (kodu źródłowego, zestawu testów itd.), procesów wytwarzania oprogramowania oraz ludzi biorących udział w procesach wytwórczych [5]. Zgodnie ze

standardem IEEE 1061-1998 metryka jest funkcją odwzorowującą jednostkę oprogramowania w wartość liczbową, która jest intepretowana jako stopień spełnienia pewnej własności jakości jednostki oprogramowania [6].

Metryki pozwalają w sposób obiektywny porównać ze sobą poszczególne technologie i umożliwiają ocenę czy produkt odpowiada ustalonym względem niego wymaganiom. Wśród nich funkcjonuje elementarny podział na metryki dynamiczne i statyczne. Metryki statyczne pozwalają na ocenę jakości kodu źródłowego już na etapie tworzenia oprogramowania, a także kontrolę jego złożoności. Wśród metryk statycznych można wyodrębnić: metryki obiektowe, rozmiaru, złożoności oraz pakietów. Pierwsze z nich badają jakość programów obiektowych oraz wykorzystanie właściwości programowania zorientowanego obiektowo. Z kolei metryki rozmiaru

i złożoności służą do określenia skali programu oraz jego

złożoności na różnych poziomach abstrakcji. Zadaniem metryk pakietów jest analiza prawidłowości powiązań pomiędzy poszczególnymi pakietami. Metryki dynamiczne, wyznaczane w oderwaniu od kodu źródłowego, polegają na analizie zachowania uruchomionego programu. Są stosowane do pomiaru wydajności i niezawodności produktu. Metryki stały się integralną częścią procesu produkcji oprogramowania

i są wykorzystywane na każdym etapie jego rozwoju [7].

5.1. Metryki statyczne

W rozdziale przedstawiono metryki stosowane do pomiaru

skomplikowania aplikacji klienckich korzystających z bibliotek Volley, Retrofit i kSOAP2.

Liczba linii kodu (LOC) – podstawowa metryka statyczna do

pomiaru liczby linii kodu źródłowego, mówiąca o skali

badanego oprogramowania i stosowana jako wskaźnik klas i metod przekraczających zalecany rozmiar.

Liczba klas (TLC) – prosta metryka rozmiaru zdefiniowana

dla pakietów, dostarczająca dane o całkowitej liczbie klas z wyłączeniem klas wewnętrznych, której zalecana wartość jest mniejsza od 40 [8].

Zło oność cyklomatyczna McCabe’a (CC) – podstawowa

metryka złożoności ozn. CC lub v(G), wykorzystywana do analizy struktury decyzyjnej programu używana do obliczania złożoności metod lub procedur. Niski poziom CC charakteryzuje prosty i zrozumiały kod, natomiast wartości powyżej 10, charakteryzują złożony kod źródłowy, w którym ryzyko wystąpienia błędu jest wysokie [9].

Zestaw metryk Chidamber-Kemerer – metryki obiektowe

opracowane przez Shyama R. Chidambera i Chrisa F.

Kemerera, nazywane również zestawem CK, zostały zaprojektowane do badania złożoności i utrzymywalności oprogramowania obiektowego [10]. Zestaw oryginalnie

zawiera 6 metryk wyliczanych dla każdej klasy:

wa ona liczba metod w klasie (WMC) – uproszczona

wersja metryki, której wartość stanowi suma metod zdefiniowanych w analizowanej klasie. Rekomendowany

maksymalny próg wartości metryki wynosi 20 [8];

głębokość drzewa dziedziczenia (DIT) – najdłuższa ścieżka dziedziczenia od badanej klasy do klasy korzenia.

Drzewa o dużej głębokości charakteryzują złożone klasy, o większym stopniu specjalizacji [8];

liczba bezpośrednich potomków klasy (NOC) – liczba

bezpośrednich potomków klasy, czyli podklas. Zbyt duża wartość NOC, może wynikać z nieprawidłowego użycia mechanizmu dziedziczenia [8];

powiązania między klasami (CBO) – liczba klas, które są związane z analizowaną klasą. Niski poziom CBO

ułatwia wprowadzanie zmian w programie, w wyniku mniejszej liczy zależności pomiędzy klasami, co przekłada się na niższy stopień złożoności [8];

odpowied klasy (RŻC) - miara potencjalnej komunikacji

między klasą a innymi klasami. Wysokie wartości RFC wskazują na dużą funkcjonalność i złożoność klasy [8];

brak spójności metod (LCOM) – miara poziomu

spójności metod. Zbyt wysokie wartości metryki wskazują klasy o dużej złożoności, które powinny zostać podzielone na mniejsze, pełniące mniej obowiązków. Do realizacji prac badawczych wybrano miarę w wersji LCOM1, która jest jedną z kilku z odmian metryki LCOM [8].

Rozmiar programu – miara polega na pomiarze liczby

plików tworzących projekt oraz rozmiaru programu zapisanego w formie pliku APK, wyrażanego w KB. Dla każdego wariantu aplikacji rozmiar mierzono na tej samej maszynie, zapisując APK na wolumenie z systemem plików NTFS, aby wyeliminować wpływ różnych systemów plików na odczytywany rozmiar danych.

5.2. Metryki dynamiczne

W rozdziale przedstawiono metryki stosowane do oceny

dynamiki aplikacji implementujących badane biblioteki.


158 158

Całkowity czas przetwarzania (TPT) – miara wyrażana w milisekundach, przedstawiająca czas jaki upłynął pomiędzy wysłaniem żądania przez aplikację mobilną do odczytania przez nią przetworzonej odpowiedzi.

Czas przetwarzania przez bibliotekę (PT) – miara

wydajności bibliotek, wyrażana w milisekundach, prezentująca różnicę pomiędzy całkowitym czasem odpowiedzi, a sumą czasu odpowiedzi usługi sieciowej oraz sieci komputerowej, wyznaczana wzorem:

gdzie: PT – czas przetwarzania przez bibliotekę,

TPT – całkowity czas przetwarzania, SRT – czas odpowiedzi

usługi, NRT – czas odpowiedzi sieci.

Pomiar polega na obliczeniu opóźnień wynikających z pracy

badanych bibliotek z uwzględnieniem opóźnień wynikających z wydajności sieci komputerowej i usług sieciowych.

Czas odpowiedzi usługi (SRT) – metryka stosowana do

pomiaru czasu reakcji serwera, polegająca na pomiarze czasu jaki upłynął od wysłania żądania do usługi sieciowej do momentu odebrania pierwszego bajtu odpowiedzi. Badanie

przeprowadzono przy użyciu narzędzia Wireshark umożliwiającego przechwytywanie i nagrywanie ruchu

sieciowego oraz programu Response Time Viewer for

Wireshark służącego do analizy i wizualizacji czasów odpowiedzi na podstawie zarejestrowanych pakietów danych. W aplikacji analitycznej, czas odpowiedzi usługi jest określany jako czas odpowiedzi aplikacji i funkcjonuje pod

nazwą Appliacation Response Time w skrócie ART.

Czas odpowiedzi sieci (NRT) – metryka pozwalająca na zmierzenie opóźnień wynikających z działania sieci komputerowej, wrażanych jako czas odpowiedzi sieci mierzony w milisekundach (uzgodnienie TCP). Tak jak

w przypadku SRT, badanie przeprowadzono przy użyciu narzędzia Wireshark oraz programu Response Time Viewer for Wireshark do analizy zarejestrowanych pakietów danych.

6. Metody badawcze

6.1. Metoda pomiaru zło oności

Pomiar złożoności oprogramowania, wykonano z użyciem różnego typu metryk statycznych, przedstawionych

w rozdziale 5.1. Poza tym porównano rozmiar programów, mierząc liczbę plików tworzących projekt i zajętość dysku twardego dla programów w formie pliku APK. Pomiary

realizowano wieloetapowo, badając niezależnie złożoność programów implementujących biblioteki Volley, Retrofit i kSOAP2. Narzędzia i rozszerzenia wykorzystane podczas pomiarów zostały opisane w ramach poszczególnych etapów. Miary użyte w trakcie badań, wyznaczają poszczególne etapy badawcze, które opisano szczegółowo w dalszej części rozdziału. Metoda badawcza, zawiera opis czynności wykonywanych podczas realizacji poszczególnych etapów i prowadzi do uzyskania wyników niezbędnych do

przeprowadzenia analizy porównawczej.

Etap 1 – Liczba linii kodu

Pomiar liczby linii kodu źródłowego (LOC) przeprowadzono z poziomu środowiska programistycznego Android Studio z użyciem rozszerzenia MetricsReloaded w wersji 1.8. Miarę zastosowano do całego projektu, ale LOC

odczytywano dla pakietu realizującego najważniejsze funkcje programu, uwzględniając wszystkie tworzące go klasy i interfejsy oraz kod wykonywalny wygenerowany

automatycznie przez IDE. Z pomiarów wykluczono jedynie kod źródłowy, odpowiedzialny za automatyczne testowanie

aplikacji. Pomiar LOC dla pakietów grupujących klasy tworzące np. GUI lub realizujące inne funkcje niezwiązane bezpośrednio z komunikacją z usługą sieciową nie jest istotny z punktu widzenia analizy porównawczej. W trakcie

wykonywania prac badawczych w oknie ustawień MetricsReloaded, wybrano profil Lines of code metrics,

dedykowany do tego typu pomiarów.

Etap 2 – Liczba klas

Pomiar liczby klas przeprowadzono z poziomu IDE

z użyciem rozszerzenia MetricsReloaded, analogicznie jak

w przypadku metryki LOC. Miarę zastosowano do całego projektu, ale liczbę klas odczytywano dla jednego pakietu, pomijając klasy przeznaczone do wykonywania testów automatycznych. W trakcie wykonywania prac badawczych

w oknie ustawień MetricsReloaded, wybrano profil Class

count metrics. Liczbę klas odczytano dla pakietu, zawierającego kod źródłowy odpowiedzialny za użycie biblioteki i komunikację z usługą sieciową.

Etap 3 – Zło oność cyklomatyczna

Badanie złożoności cyklomatycznej wykonano z użyciem rozszerzania MetricsReloaded, wykorzystując profil Complexity metrics. Tak jak w przypadku innych użytych miar, wykluczono z analizy klasy i metody odpowiedzialne za

testowanie programu. Badanie polegało na pomiarze średniej złożoności oprogramowania dla pakietu zawierającego kod źródłowy odpowiedzialny za komunikację z API.

Etap 4 – Zestaw metryk Chidamber-Kemerer

Do obliczenia wartości 6 metryk tworzących zestaw CK, również użyto rozszerzanie MetricsReloaded, wykorzystując profil Chidamber-Kemerer metrics. Tak jak w przypadku

innych miar, wykluczono z analizy klasy i metody

odpowiedzialne za testowanie programu. Pomiar wykonano

dla klas wykorzystywanych do integracji z usługą sieciową, wymaganych do prawidłowego działania komunikacji. Ze

względu na różnice w badanym zbiorze klas wynikające z właściwości bibliotek, nie porównywano ze sobą konkretnych klas, ale średnie wartości metryk.

Etap 5 – Rozmiar programu

Tak jak w poprzednich etapach do pomiaru ilości plików zastosowano MetricsReloaded, w którym wybrano profil

Number of files metrics. Z analizy wykluczono klasy,

przeznaczone do wykonywania testów automatycznych.


159 159

W pomiarach uwzględniono wszystkie pliki projektu, również te które nie są bezpośrednio związane z wykorzystaniem API. W praktyce tylko niewielka ich część zależy od rodzaju biblioteki zastosowanej w projekcie. Zajętość programu na dysku, mierzono zapisując pliki APK na partycji z systemem plików NTFS i odczytując ich rozmiar z właściwości pliku.

6.2. Metoda pomiaru wydajności

Programy mobilne implementujące badane biblioteki, współpracują z usługami sieciowymi typu REST i SOAP

i mierzą całkowity czas przetwarzania dla trzech rodzajów wywołań. Każdy z programów został zbudowany w oparciu o ten sam szablon projektu oraz identyczne GUI, zapewniające użytkownikowi funkcje potrzebne do przeprowadzenia

pomiarów. Zasadniczo różnice w konstrukcji kodu źródłowego, wynikają wyłącznie ze specyfiki używanej biblioteki i rodzaju API z którego korzysta program. Każda odmiana aplikacji zapewnia taką samą funkcjonalność, ograniczoną do funkcji niezbędnych do wykonania badań i posiada prosty interfejs prezentujący wyniki pomiarów.

Program kliencki obsługuje trzy rodzaje wywołań i dla każdego z nich oblicza całkowity czas przetwarzania, mierzony do mementu zamiany odpowiedzi serwera na

obiekty Java. Poza tym w trakcie pomiarów zlicza wysłane żądania oraz oblicza średni czas ich obsługi. Po

wciśnięciu przycisku, wywołana jest metoda odpowiedzialna

za wysłanie nowego żądania oraz odebranie i konwersję odpowiedzi. Program kliencki obsługuje następujące żądania:

pobierz egzamin – program wysyła do serwera identyfikator egzaminu, którego dane chce pobrać z serwera. Po otrzymaniu prawidłowego żądania usługa wysyła odpowiedź zawierającą wszystkie dane egzaminu w ustalonym formacie. Po odebraniu, odpowiedź jest konwertowana do postaci obiektów Java odpowiadających

strukturom danych, zawartym w odpowiedzi;

pobierz egzaminy – program wywołuje akcję pobierającą z bazy danych egzaminy i w odpowiedzi odbiera listę wszystkich egzaminów zdawanych przez studentów. Następnie odpowiedź jest zamieniana na kolekcję lub wektor elementów, zawierający obiekty Java;

dodaj studenta – w przypadku tego żądania aplikacja wysyła do serwera obiekt reprezentujący studenta, który odebrany przez usługę sieciową, zostaje dodany w formie

nowego rekordu do tabeli przechowującej dane studentów.

Badanie wydajności bibliotek w oparciu o metryki dynamiczne jest procesem wieloetapowym, wymagającym użycia dodatkowych narzędzi pomiarowych. Metoda badawcza zawiera opis czynności wykonywanych podczas realizacji poszczególnych etapów i prowadzi do uzyskania wyników niezbędnych do przeprowadzenia późniejszej analizy porównawczej. W ramach każdego etapu, wykonywane są pomiary całkowitego czasu przetwarzania (TPT), czasu odpowiedzi usługi i czasu odpowiedzi sieci na podstawie których obliczany jest faktyczny czas przetwarzania danych przez bibliotekę. TPT jest mierzony dla każdej akcji niezależenie przez program kliencki, który dodatkowo zlicza wysłane żądania i oblicza średni czas ich przetwarzania.

Procedurę badawczą podzielono na trzy niezależne etapy i w każdym z nich przeprowadzono pomiar wydajności jednej biblioteki. Każdy z etapów realizowano w taki sam sposób, bez względu na to jaką zastosowano bibliotekę lub jaki rodzaj

usługi sieciowej wykorzystywał klient mobilny. Zaprezentowana sekwencja czynności dotyczy wyłączenie akcji jednego rodzaju, ale ma zastosowanie dla pozostałych dwóch. Praktyczne aspekty metody badawczej opisano w sposób uniwersalny, mającym zastosowanie na każdym etapie badań. W celu zwiększenia precyzji pomiarów w ramach prac badawczych analizowano TPT dla dziesięciu żądań każdego rodzaju. W ramach poszczególnych etapów wyodrębniono kroki konieczne do uzyskania żądanych wyników, przedstawione w dalszej części rozdziału.

Krok 1 – Pomiar TPT

W pierwszym kroku zmierzono całkowity czas przetwarzania dla wywołania pobierającego dane egzaminu o wskazanym identyfikatorze. Po kliknięciu przycisku „Pobierz egzamin”, program mobilny wysyła żądanie do usługi sieciowej i otrzymaną odpowiedź konwertuje do postaci obiektów Java. W GUI prezentuje całkowity czas przetwarzania, średni czas przetwarzania i liczbę żądań wysłanych od rozpoczęcia pomiaru (rysunek 1). TPT jest

obliczany dla każdego żądania niezależnie, natomiast średni czas przetwarzania i liczba wysłanych żądań są obliczane dla

całego cyklu pomiarowego.

Rys. 1. Wynik pomiaru TPT dla wywołania pobierającego dane egzaminu

Procesem wykonywanym w trakcie wysyłania żądań jest nagrywanie ruchu sieciowego, za pomocą programu

Wireshark. Jego zadaniem jest przechwytywanie danych

wymienianych z użyciem protokołu HTTP, pomiędzy klientem mobilnym, a usługą sieciową (rysunek 2).

Rys. 2. Nagrywanie ruchu sieciowego pomiędzy klientem i usługą sieciową

Krok 2 – Pomiar SRT i NRT

Pomiar czasu odpowiedzi usługi i czasu odpowiedzi sieci komputerowej wymagał zastosowania narzędzia analitycznego, którego zadaniem było odczytanie tych parametrów na podstawie zarejestrowanego ruchu sieciowego.


160 160

Do tego celu wykorzystano aplikację SolarWinds Response Time Viewer, która umożliwia analizę pakietów przechwyconych przez program Wireshark. Pliki z ruchem

sieciowym otwierano w SolarWinds Response Time Viewer

i poddawano analizie, w wyniku której odczytywano czas

odpowiedzi sieci (NRT) i czas odpowiedzi usługi (SRT) dla

protokołów HTTP lub SOAP (tylko dla kSOAP2).

Krok 3 – Obliczenie PT

Czas przetwarzania przez bibliotekę (PT), obliczono na podstawie wcześniej zmierzonych parametrów TPT, SRT, NRT dla każdego wywołania niezależnie. Poza tym obliczono średni czas przetwarzania dla dziesięciu wywołań tego samego rodzaju, czyli dla jednego cyklu pomiarowego. Eliminacja

opóźnień wynikających z czasu odpowiedzi sieci i usług sieciowych, zimniejsza błąd pomiarowy i pozwala na

porównanie rzeczywistych czasów przetwarzania.

7. Wyniki badań

7.1. Wyniki pomiaru zło oności

Metryki rozmiaru użyte w metodzie badawczej przedstawiają różnice w skali programów klienckich implementujących poszczególne biblioteki. Ze względu na

zróżnicowanie w konstrukcji programów nie porównywano LOC dla poszczególnych klas, zaś dla całych pakietów Java

dla których nie ma rekomendowanych wartości tej metryki. Poza TLC, również pozostałe metryki rozmiaru nie posiadają zalecanych zakresów wartości i posłużono się nimi wyłącznie na potrzeby analizy porównawczej. Tabela 3 przedstawia

wartości metryk rozmiaru z zaznaczonymi wartościami największymi (ozn. ▲) oraz najmniejszymi (ozn. ▼).

Tabela 3. Porównanie wartości metryk rozmiaru

Metryka Wartość zalecana

Volley Retrofit kSOAP2

LOCsum - 468 441 ▼ 771 ▲

TLC < 40 18 ▲ 15 13 ▼

Rozmiar w KB - 1967 ▲ 1928 1840 ▼

Liczba plików - 27 28 ▲ 26 ▼

W przypadku metryk CC i WMC, otrzymane wyniki

pomiarów porównano z wartościami rekomendowanymi. Dla pozostałych metryk z zestawu CK, literatura mówi wyłącznie o wartościach wysokich (ozn. ↑) lub niskich (ozn. ↓), nie określając konkretnie zalecanych zakresów wartości miar. Tabela 4 przedstawia uśrednione wartości metryk obiektowych i złożoności z zaznaczonymi wartościami

największymi (ozn. ▲) oraz najmniejszymi (ozn. ▼).

Tabela 4. Porównanie wartości metryk obiektowych i złożoności

Metryka Wartość zalecana


CCśr < 10 1,08 1,05 ▼ 3 ▲

WMCśr < 20 10.86 9,86 ▼ 13,44 ▲

DITśr ↓ 2,43 ▲ 2 ▼ 2,11

NOCśr ↓ 0 0 0

CBOśr ↓ 2,43 3 ▲ 2,33 ▼

RFCśr ↓ 11,29 ▲ 10,38 9,89 ▼

LCOMśr ↓ 3,57 3,71 ▲ 2,44 ▼

7.2. Wyniki pomiaru wydajności

Tabela 5. Pomiary wydajności dla Retrofit i akcji "Pobierz egzamin"

Retrofit - Pobierz egzamin

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 201 82 14 105

100 94

2 205 71 29 105

3 214 71 11 132

4 172 71 11 90

5 200 80 23 97

6 181 76 19 86

7 274 130 59 85

8 231 74 25 132

9 174 71 15 88

10 176 75 24 77

Tabela 6. Pomiary wydajności dla Retrofit i akcji "Pobierz egzaminy"

Retrofit - Pobierz egzaminy

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 349 15 21 313

363 385

2 302 15 9 278

3 327 14 23 290

4 339 15 16 308

5 476 15 36 425

6 459 15 28 416

7 422 16 18 388

8 416 15 19 382

9 418 14 12 392

10 468 16 10 442

Tabela 7. Pomiary wydajności dla Retrofit i akcji "Dodaj studenta"

Retrofit - Dodaj studenta

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 192 83 24 85

88 87

2 153 68 13 72

3 168 66 31 71

4 162 75 15 72

5 237 69 66 102

6 203 73 28 102

7 209 72 20 117

8 162 66 13 83

9 160 61 10 89

10 173 68 14 91

Tabela 8. Pomiary wydajności dla Volley i akcji "Pobierz egzamin"

Volley - Pobierz egzamin

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 254 70 36 148

163 157

2 217 69 11 137

3 221 71 17 133

4 285 65 23 197

5 264 67 14 183

6 257 67 24 166

7 222 70 20 132

8 288 68 26 194

9 279 67 7 205

10 217 71 9 137


161 161

Tabela 9. Pomiary wydajności dla Volley i akcji "Pobierz egzaminy"

Volley - Pobierz egzaminy

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 416 15 14 387

443 444

2 420 15 15 390

3 577 14 42 521

4 479 16 10 453

5 462 16 11 435

6 485 15 9 461

7 581 14 52 515

8 426 14 25 387

9 548 16 18 514

10 406 14 22 370

Tabela 10. Pomiary wydajności dla Volley i akcji "Dodaj studenta"

Volley - Dodaj studenta

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 133 65 16 52

75 79

2 153 65 15 73

3 134 62 15 57

4 125 62 13 50

5 172 67 11 94

6 168 64 18 86

7 170 63 16 91

8 175 68 11 96

9 143 73 9 61

10 168 62 10 96

Tabela 11. Pomiary wydajności dla kSOAP2 i akcji "Pobierz egzamin"

kSOAP2 - Pobierz egzamin

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 190 74 22 94

81 86

2 179 70 25 84

3 166 67 28 71

4 188 72 17 99

5 160 71 19 70

6 171 70 22 79

7 119 69 18 32

8 196 71 23 102

9 200 78 33 89

10 177 67 16 94

Tabela 12. Pomiary wydajności dla kSOAP2 i akcji "Pobierz egzaminy"

kSOAP2 - Pobierz egzaminy

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 890 185 20 685

652 655

2 872 179 36 657

3 781 204 28 549

4 882 193 35 654

5 907 192 21 694

6 899 202 23 674

7 874 198 26 650

8 931 190 43 698

9 878 195 38 645

10 880 225 37 618

Tabela 13. Pomiary wydajności dla kSOAP2 i akcji "Dodaj studenta"

kSOAP2 - Dodaj studenta

Nr

żądania

TPT

[ms]

SRT

[ms]

NRT

[ms]

PT

[ms]

PTśr

[ms]

PTme

[ms]

1 163 65 37 61

71 163

2 161 64 36 61

3 188 66 38 84

4 171 61 30 80

5 160 58 35 67

6 189 69 31 89

7 141 58 25 58

8 189 60 39 90

9 159 67 28 64

10 151 63 30 58

Na bazie wyników pomiarów, obliczono przeciętny (mediana) i średni czas przetwarzania, zgodnie z metodami badawczymi. Tabela 14 przedstawia zestawienie tych czasów z zaznaczonymi wartościami największymi (ozn. ▲) oraz najmniejszymi (ozn. ▼) dla poszczególnych wywołań.

Tabela 14. Porównanie przeciętnych i średnich czasów przetwarzania

Wywołanie


PTśr

[ms]

PTme

[ms]

PTśr

[ms]

PTme

[ms]

PTśr

[ms]

PTme

[ms]

Pobierz

egzamin 100 94 163 ▲ 157 ▲ 81 ▼ 86 ▼

Pobierz

egzaminy 363 ▼ 358 ▼ 443 444 652 ▲ 655 ▲

Dodaj

studenta 88 ▲ 87 ▲ 75 79 71 ▼ 65 ▼

8. Wnioski

8.1. Zło oność oprogramowania

Na podstawie badań złożoności przeprowadzonych dla

bibliotek Retrofit, Volley i kSOAP2, można sformułować następujące wnioski. Metryki rozmiaru wykazały, że program korzystający z biblioteki kSOAP2 ma największy rozmiar pod względem liczby linii kodu źródłowego, zaś najmniejszy pod względem liczby klas, zajmowanej przestrzeni dyskowej po

zbudowaniu APK oraz liczby plików w projekcie. Poziom TLC dla żadnej biblioteki nie przekracza wartości rekomendowanej, więc analizowane pakiety nie wymagają

podziału. Z kolej program implementujący bibliotekę Volley jest największy pod względem rozmiaru pliku APK i liczby użytych klas. Program oparty na Retrofit, posiada najwięcej plików w projekcie i najmniejszą sumaryczną wartość LOC. Ze względu na najwyższą wagę metryki LOC i relatywnie

małe różnice w wartościach pozostałych metryk rozmiaru stwierdzono, że najbardziej rozbudowany jest program korzystający z kSOAP2. Wysoki poziom LOC przekłada się na zwiększenie pracochłonności i czasochłonności procesu implementacji programu. Analiza porównawcza potwierdza

słuszność hipotezy 1, mówiącej że programy mobilne zintegrowane z usługami REST, mają mniejszy rozmiar od aplikacji zintegrowanych z usługami SOAP.

Złożoność cyklomatyczna McCabe’a (CC) oraz ważona liczby metod w klasie (WMC), mieszczą się w zalecanych zakresach wartości, kształtując się na względnie niskim poziomie. Metryki osiągają wartości najwyższe dla biblioteki


162 162

kSOAP2, co oznacza, że posiada ona średnio najwięcej metod w klasie i są one najbardziej skomplikowane, co w praktyce przekłada się na większe prawdopodobieństwo wystąpienia błędu. Z kolei najniższe wartości miar CC i WMC, zmierzono dla biblioteki Retrofit, dla której poziom skomplikowania metod okazał się blisko trzykrotnie mniejszy niż dla kSOAP2, zaś liczba metod w klasie mniejsza w przybliżeniu o cztery.

Dla Volley wartości obu metryk były porównywalne z wartościami zmierzonymi dla biblioteki Retrofit. Wartość stopnia dziedziczenia (DIT) dla wszystkich bibliotek była zbliżona, z czego najwyższa dla Volley, zaś najniższa dla Retrofit. Z kolei średnia liczba podklas (NOC) dla wszystkich badanych bibliotek była równa zeru, ze względu na niestosowanie mechanizmu dziedziczenia w analizowanym

pakiecie. Również średnie wartości metryk obiektowych CBO i RFC były bardzo zbliżone, na podstawie czego stwierdzono

że klasy tworzące programy klienckie mają podobną funkcjonalność oraz zdolność do wprowadzania zmian. Jedynie poziom spójności metod (LCOM) zmierzony dla kSOAP2, różnił się w sposób zauważalny od wartości LCOM dla pozostałych bibliotek i był w przybliżeniu o 1/3 mniejszy. Taka dysproporcja wskazuje na mniejszą liczbę obowiązków, a co za tym idzie mniejszą złożoność implementacyjną klas użytych w oprogramowaniu implementującym kSOAP2. Podsumowując, ze względu na duże wartości CC i WMC w porównaniu z Volley i Retrofit oraz zbliżone wartości pozostałych metryk z wyjątkiem LCOM, stwierdzono że najwyższy poziom złożoności charakteryzuje programy oparte na kSOAP2. Z kolei aplikacje korzystające z Volley i Retrofit mają podobną złożoność i nie można jednoznacznie wskazać, która technologia charakteryzuje programy bardziej skomplikowane. Wyniki badań potwierdzają słuszność hipotezy 2, mówiącej że programy mobilne współpracujące z usługami SOAP są bardziej skomplikowane od wykonujących te same czynności aplikacji zintegrowanych

z usługami REST.

8.2. Wydajność programów klienckich

Na podstawie badań wydajności bibliotek zaobserwowano, że szybkość działania programów mobilnych, zintegrowanych z usługami sieciowymi, zależy zarówno od typu wykorzystywanej biblioteki, jak również od rodzaju wywoływanej akcji. Uśredniona wartość PT dla wywołania pobierającego dane egzaminu, okazała się najmniejsza dla biblioteki kSOAP2, zaś największa dla Volley. W przypadku pobierania większej porcji danych w postaci 100 egzaminów, najszybsza okazuje się biblioteka Retrofit, natomiast czas przetwarzania danych jest najdłuższy dla kSOAP2. Właśnie dla wywołań pobierających dane, różnice w wartościach PT między bibliotekami są największe i sięgają blisko 300 [ms] dla wywołania pobierającego wiele egzaminów. Czasy zmierzone dla najszybszej biblioteki są blisko dwukrotnie mniejsze niż dla biblioteki najwolniejszej. Inaczej jest w przypadku wywołania dodającego studenta do systemu, gdzie czasy przetwarzania bibliotek są porównywalne, przy czym średnia wartość PT jest największa dla Retrofit i najmniejsza dla kSOAP2. Celem pracy było zbadanie

prawdziwości stwierdzenia, że programy zintegrowane z usługami typu REST, działają szybciej od aplikacji współpracujących z usługami typu SOAP. Z uwagi na to,

że największe opóźnienia występują podczas pobierania wielu egzaminów oraz zważywszy na to że rozmiar danych pojedynczego egzaminu w mniejszym stopniu odpowiada

rozmiarom danych pobieranych w rzeczywistych systemach,

stwierdzono że najniższy poziom wydajności charakteryzuje kSOAP2. Z kolei aplikacje korzystające z Volley i Retrofit

mają zbliżoną wydajność i analogicznie jak w przypadku

analizy złożoności nie można jednoznacznie wskazać, która technologia cechuje programy o większej wydajności. Nie mniej jednak uzyskane wyniki potwierdzają hipotezę 3, że wydajność aplikacji mobilnych zintegrowanych z usługami typu REST jest większa, niż programów korzystających z usług SOAP.

Teza mówiąca o tym że usługi sieciowe typu REST są lepszym rozwiązaniem od usług SOAP w przypadku

korzystania z nich poprzez mobilne aplikacje klienckie

okazała się prawdziwa. Programy korzystające z usług typu REST, charakteryzują się mniejszym rozmiarem, a co za tym idzie ich przygotowanie wymaga mniejszego nakładu pracy i jest mniej czasochłonne. Poza tym na niekorzyść programów zintegrowanych z SOAP przemawia większa złożoność implementacyjna, która zwiększa ryzyko wystąpienia błędu, zmniejsza czytelność kodu i utrudnia proces testowania. Za stosowaniem integracji z REST przemawia również większa szybkość działania bibliotek Retrofit i Volley w porównaniu z biblioteką kSOAP2 przeznaczoną do integracji z SOAP.

Literatura

[1] Mobile Operating System Market Share Worldwide,

http://gs.statcounter.com/os-market-share/mobile/worldwide

[20.02.2019].

[2] W3C Organization, http://www.w3.org [02.11.2018].

[3] Web Services Architecture, http://www.w3.org/TR/ws-arch/

[12.12.2018].

[4] B. P. Upadhyaya, Rest client pattern. Industrial Electronics

(ISIE), 2014 IEEE 23rd International Symposium on Industrial

Electronics (ISIE), IEEE, 2014.

[5] K. Subieta, Słownik terminów z zakresu obiektowości, Wyd. 1, Akademicka Oficyna Wydawnicza PLJ, Warszawa 1999

[6] Software & Systems Engineering Standards Committee, 1061-

1998 - IEEE Standard for a Software Quality Metrics

Methodology, IEEE, 1998.

[7] M. Shereshevsky, R. Gunnalan, H. H. Ammar, Pseudo dynamic

metrics [software metrics], The 3rd ACS/IEEE International

Conference on Computer Systems and Applications, 2005.

[8] S. H. Kan, Metryki i modele w inżynierii jakości oprogramowania, PWN, 2006.

[9] T. McCabe, A Software Complexity Measure, IEEE

Transactions on Software Engineering, 1976.

[10] S. R. Chidamber, C. F. Kemerer, A Metrics Suite for Object

Oriented Design, IEEE Transactions on Software Engineering,

1994.

JCSI 11 (2019) 163-166

Wysłane: 2019-02-14


163

Analiza i ocena realizacji polityki bezpieczeństwa informacji w wybranych

polskich i ukraińskich przedsiębiorstwach branży IT

Andriy Andriychuk*


Streszczenie. W artykule przedstawiono rezultaty po przeprowadzeniu ankiet w wybranych przedsiebiorstwach Ukrainy i Polski, a takze

opisano porównanie polityk bezpieczeństwa informacji w tych przedsiębiorstwach oraz oceniono, które przedsiębiorstwa lepiej chronią informacje, biorąc pod uwagę wspomniane firmy obu krajów jako przedmiot badań.

Słowa kluczowe: bеzрiесzеństwо infоrmасji; роlitуkа bеzрiесzеństwа infоrmасji. *Autor do korespondencji.


Analysis and evaluation of the implementation of information security policy in

selected Polish and Ukrainian IT companies

Andriy Andriychuk*


Abstract. The article presents the results after conducting surveys in selected enterprises of Ukraine and Poland, as well as described the

comparison of information security policies in enterprises and verbal, which enterprises better protect information, taking into account the

companies of both countries as a research subject.Thе рrоfеssiоnаl litеrаturе оf thе givеn issuе, аs wеll аs Intеrnеt sоurсеs, wеrе usеd.

Keywords: infоrmаtiоn роliсу; sесuritу infоrmаtiоn роliсу.



1. Wstęp

Rozwój i rozpowszechnienie: elektroniki, internetu,

urządzeń dostępowych oraz pojawienie się sieci społecznościowych, a także wykorzystywanie sieci

publicznych do przekazywania informacji, przyczynia się nie tylko do tworzenia informacji jako kluczowego

elementu określającego wiedzę, ale także decydującego czynnika bezpieczeństwa osób fizycznych i prawnych

poszczególnych państw.

Bezpieczeństwo informacji od dawna uważane jest za

jeden z głównych priorytetów prawie wszystkich organizacji, a w tym przedsiębiorstw branży IT.

Zwiększona uwaga poświęcana temu zagadnieniu wynika z szybko rosnącej ilości informacji, potrzeby jej przetwarzania, przesyłania i przechowywania. Konwersja

znacznej części informacji na formę elektroniczną oraz

wykorzystywanie lokalnych i globalnych sieci stwarza

jakościowo nowe zagrożenia dla niejawnych informacji

[1, 2].

Globalna informatyzacja doprowadziła do tego, że informacje korporacyjne i systemy telekomunikacyjne

zyskały główne znaczenie w obecnym świecie. Systemy

informacji korporacyjnej i telekomunikacyjnej są tworzone

w celu uzyskania określonych usług informacyjnych. Jeżeli nie można uzyskać dostępu do informacji o usługach, szkodzi to wszystkim osobom powiązanym z informacjami,

zarówno przedsiębiorcom jak i klientom. Dlatego

najważniejszym elementem bezpieczeństwa informacji jest dostępność usług systemów informatycznych [3].

2. Założenia badań

Celem badań jest porównanie polityki bezpieczeństwa informacji w polskich i ukraińskich przedsiębiorstwach, a także ustalenie, które organizacje lepiej chronią informacje, podejmując wspomniane wcześniej podmioty

obu krajów jako przedmiot badań.

W planie badań uwzględniono zadania:

1. Analiza literatury z zakresu informatyki, która odzwierciedla problem badania.

2. Badanie i identyfikacja współczesnych i najbardziej

popularnych sposobów ochrony informacji. 3. Ocena aktualnego poziomu bezpieczeństwa informacji

przedsiębiorstw. 4. Propozycja sposobów usprawnienia ochrony informacji

w celu osiągnięcia akceptowalnego poziomu bezpieczeństwa zasobów informacyjnych przedsiębiorstwa.


164 164

W badaniach sformułowano hipotezę badawczą:

Polityka bezpieczeństwa informacji prywatnych przedsiębiorstw w Polsce jest na wyższym poziomie niż podobnych organizacji na Ukrainie.

Jako teoretyczną podstawę badania wykorzystano

publikacje oraz artykuły dotyczące polityki i narzędzi bezpieczeństwa informacji.

Aby osiągnąć cel badań, wybrano klasyczne metody

badawcze: sondaż diagnostyczny (przeprowadzenie ankiety wśród przedsiębiorstw Polski i Ukrainy) oraz analizę porównawczą jako metodę weryfikacji wyników ankietowania.

Ankieta została opracowana dla firm komercyjnych na Ukrainie i w Polsce. Pytania ankiety dotyczyły metod ochrony informacji i osób odpowiedzialnych za

bezpieczeństwo informacji przedsiębiorstwa.

Autor pracy stosował się do następującego planu działania:

1. Przygotowanie ankiety.

2. Badanie przedsiębiorstw na Ukrainie i w Polsce. 3. Analiza porównawcza.

3. Realizacja i wyniki badań

Ankieta została przygotowana pod kątem identyfikacji metod ochrony informacji w przedsiębiorstwach. Przy jej

pomocy uzyskano dane o normach i przepisach

stosowanych w przedsiębiorstwach dla zapewnienia

bezpieczeństwa informacji. Główne zagadnienia objęte ankietą to organizacyjne i sprzętowe środki ochrony informacji, na przykład tworzenie kopii zapasowych

i szyfrowanie danych, praca z personelem i dostępem

użytkownika.[4, 5]

Od 2 do 30 listopada 2017 r. przeprowadzono ankiety

w 74 przedsiębiorstwach. Ankietami objęto: 53

przedsiębiorstwa ukraińskie i 21 polskie. Formularze dla

przedsiębiorstw zostały przesłane e-mailem. Wszystkie

przedsiębiorstwa są związane z branżą IT i zajmują się tworzeniem oprogramowania lub zasobów internetowych.

Różnice w nich wynikały ze specyfiki pracy, liczby

personelu i bazy klientów. Pytania ankiety dla polskich

firm przedstawiono w tabeli 1.

Rezultaty wyników odpowiedzi na wybrane pytania ankiety dla przedsiębiorstw polskich przedstawiono na rys.1, 3, 5, 7, a dla przedsiębiorstw ukraińskich na rys. 2, 4,

6, 8.

Tabela 1. Zestawienie pytań zadanych ankietowanym w sprawie

bezpieczeństwa informacji

№ Pytanie

1 Czy znają Państwo pojęcie polityki bezpieczeństwa informacji?

2 Czy korzystają Pańtwo wyłącznie z certyfikowanych narzędzi ochrony danych z nieautoryzowanego dostępu?

3 Czy istnieje u Państwa pełny zestaw dokumentacji dla każdego z narzędzi ochrony danych z nieautoryzowanego dostępu?

4 Czy jest zapewniona u Państwa ochrona hasłem wszystkich komputerów i LANów wykorzystywanych w procesach technologicznych?

5 Czy są u Państwa udokumentowane wymagania dotyczące haseł dostępu?

6 Czy ustalone u Państwa wymagania dotyczace haseł, są przestrzegane?

7 Czy istnieje u Państwa w organizacji osoba odpowiedzialna

za zapewnienie bezpieczeństwa informacji?

8 Czy u Państwa monitorowane są następujące procesy: generowanie, rozprzestrzenianie, zmiana, usuwanie haseł, opracowywanie niezbędnych instrukcji, kontrola nad działaniami personelu przy pracy z hasłami?

9 Czy funkcjonuje u Państwa elektroniczny dziennik działań podejmowanych przez personel i użytkowników?

10 Czy istnieje u Państwa podział komputerów na segmenty: księgowość, dział sprzedaży, deweloperzy itp.?

11 Czy istnieje u Państwa priorytet komputerów w sieci?

(Kategoryzowanie poziomu ważności poszczególnych chronionych komputerów i ustalanie priorytetów incydentów w systemie)

12 Czy stosują się Państwo do kontroli drukowania

(Przydzielanie tylko autoryzowanych drukarek w celu

drukowania poufnych informacji w celu wyeliminowania

możliwych kanałów wycieku informacji.)

13 Czy stosuje się u Państwa szyfrowanie danych poufnych?

14 Czy stosują się Państwo do ograniczenia praw

użytkowników (na przykład ograniczenia dotyczące uruchamiania aplikacji)

15 Czy regularnie wykonują Państwo kopię zapasową danych?

16 Czy korzystają Państwo z serwerów zdalnych do przechowywania informacji?

17 Czy korzystają Państwo z bezpiecznych nośników pamięci?


165 165

Rys. 1. Wynik odpowiedzi na pytanie: „Czy stosuje się u Państwa szyfrowanie danych poufnych?” w przedsiębiorstwach polskich

Rys. 2. Wynik odpowiedzi na pytanie: „Czy stosuje się u Państwa

szyfrowanie danych poufnych?” w przedsiębiorstwach ukraińskich

Rys. 3. Wynik odpowiedzi na pytanie: „Czy istnieje u Państwa podział komputerów na segmenty: księgowość, dział sprzedaży, deweloperzy itp.?” w przedsiębiorstwach polskich

Rys. 4. Wynik odpowiedzi na pytanie: „Czy istnieje u Państwa podział komputerów na segmenty: księgowość, dział sprzedaży, deweloperzy itp.?” w przedsiębiorstwach ukraińskich

Rys. 5. Wynik odpowiedzi na pytanie: „Czy istnieje u Państwa elektroniczny dziennik działań podejmowanych przez personel i użytkowników?” w przedsiębiorstwach polskich

Rys. 6. Wynik odpowiedzi na pytanie: „Czy istnieje u Państwa elektroniczny dziennik działań podejmowanych przez personel i użytkowników?” w przedsiębiorstwach ukraińskich


166 166

Rys. 7. Wynik odpowiedzi na pytanie: „Czy istnieje u Państwa priorytet komputerów w sieci? w przedsiębiorstwach polskich .

Rys. 8. Wynik odpowiedzi na pytanie: „Czy istnieje u Państwa

priorytet komputerów w sieci? (w przedsiębiorstwach ukraińskich.)

Zgodnie z wynikami ankiety przeprowadzonej w firmach

z branży IT na Ukrainie i w Polsce, można stwierdzić, że polskie firmy używają znacznie więcej certyfikowanych narzędzi bezpieczeństwa niż ukraińskie i monitorują dostępność dokumentacji na ich temat. Jeśli chodzi o prostsze i bardziej niezawodne narzędzia bezpieczeństwa, takie jak ochrona hasłem komputerów i sieci, szyfrowanie i tworzenie kopii zapasowych danych, ograniczenie praw

użytkowników, podział komputerów na segmenty i ich priorytetyzacja w sieci, wykazano, że takie działania są obecne w wielu firmach IT w obu krajach. Większość firm zatrudnia pracowników odpowiedzialnych za bezpieczeństwo informacji (ponad 60% respondentów).

76% ankietowanych polskich firm prowadzi elektroniczny

dziennik działań podejmowanych przez pracowników oraz

użytkowników, a tylko 34% utrzymuje go na Ukrainie lub

częściowo utrzymuje (9% respondentów). Również 81% polskich przedsiębiorstw segmentuje swoje komputery, podczas gdy na Ukrainie robi to tylko 41% i 14%

częściowo. Również 81% polskich przedsiębiorstw priorytetowo traktuje komputery w sieci, na Ukrainie

zrobiono to tylko w 40% przypadków, co wskazuje, że wśród polskich przedsiębiorstw wynik jest prawie dwukrotnie wyższy. Wskaźnik szyfrowania danych jest o 18% wyższy w Polsce niż na Ukrainie.

4. Wnioski

Podsumowując wyniki badań, autor pracy zauważył, że postindustrialny etap rozwoju społeczeństwa wnosi wiele

korzyści dla naszego życia.Jednak wraz z pozytywnymi

korzyściami przynosi to również ludziom negatywne konsekwencje - nowe zagrożenia dla ich żywotnych interesów. Wśród takich zagrożeń są zagrożenia w sferze informacyjnej [6-8]. Do ich szybkiej lokalizacji i eliminacji

konieczna jest polityka informacyjna państwa adekwatna do skali zagrożeń informatycznych. Polityka ta powinna uwzględniać obiektywne procesy globalizacji, rosnącą otwartość społeczeństw i opierać się na priorytecie narodowych interesów Ukrainy i Polski. Potwierdziła się także hipoteza, że polityka bezpieczeństwa informatycznego prywatnych przedsiębiorstw w Polsce jest

lepsza niż polityka bezpieczeństwa informatycznego prywatnych przedsiębiorstw na Ukrainie.

Literatura

[1] Харченко Л.С., Информационная безопасность Украины

: Глоссарий / Л. С. Харченко, В. А. Липкан, А. В. Логинов, Текст, Киев 2004, 136.

[2] httрs://uсhеbnikiоnlinе.соm/роlitоlоgiа/infоrmаtsiуnа_bеzреkа_-_оstrоuhоv_vv/nоrmаtivnо-

рrаvоvе_rеgulуuvаnnуа_infоrmаtsiуnоуi_bеzреki_ukrауini. htm [20.04.2018]

[3] K. Lidеrmаn, Bеzрiесzеństwо infоrmасуjnе, Wуdаwniсtwо Nаukоwе РWN, Wаrszаwа 2012, 11-12.

[4] Батюк А.Є., Інформаційні системи в менеджменті, Інтелект-Захід, Львів 2004, 343–384.

[5] В.Л. Бурячок, В.Б. Толубко, В.О. Хорошко, С.В. Толюпа, Інформаційна та кібербезпека: соціотехнічний аспект,

ДУТ, Киев 2015.

[6] Б.Р. Бабаян, Защита информационных систем

[7] httрs://businеssinsidеr.соm.рl/firmу/рrzерisу/rоdо-gdрr-

rеgulасjе-о-осhrоniе-dаnусh-оsоbоwусh-zmiаnу-w-

firmасh/21р6svs.

[8] httр://сусlоwiki.оrg/wiki/Средства_защиты_информации

journal of computer sciences institutebc.pollub.pl/content/13287/vol11-2019.pdf · framework django...

Documents