Przykładowe wyniki

Uzyskanie wyników będących znamionami jakości możliwe jest przy wykorzystaniu całego modelu oceny jakości implementacji wzorców projektowych oraz zawartej w nim funkcji oceny. Natomiast weryfikacja wyłącznie względem modelu referencyj-nego pozwala na uzyskanie wyników cząstkowych. Omówiony wcześniej formalizm został zrealizowany jako prototypowe narzędzie wspierające ocenę jakości implemen-tacji wzorców, niestety aktualne zaawansowanie prac pozwala na weryfikację wyłącz-nie wyłącz-niektórych cech wzorców. Zwiększewyłącz-nie zakresu weryfikacji wymaga zrealizowania wymienionych wcześniej rozszerzeń.

W tabeli 2 zostały przedstawione wyniki procentowe uzyskane na podstawie po-ziomu dopasowania dla dwóch prostych przypadków wzorca Singleton z zaznaczonymi różnicami wynikającymi z informacji zawartych w modelu referencyjnym. Artefakty poddane weryfikacji zostały przygotowane na potrzeby eksperymentu i mają na celu praktyczne przybliżenie idei. W przyszłości możliwe będzie przeprowadzenie prak-tycznego eksperymentu również dla bardziej rozbudowanych przypadków wzorca Singleton, w tym wariantów z różnymi metodami synchronizacji w środowisku wielo-wątkowym. Listingi od 1 do 2 zawierają kod źródłowy zweryfikowanego oprogramo-wania.

Tabela 2. Przykłady wyników

Przypadek 1 Przypadek 2

Ogólna charakterystyka Najprostsza implementacja wzorca Singleton, w którym instancja udostępniania jest poprzez pole statyczne.

Instancja singletonu udostępnia-nia poprzez właściwość lub

metodę.

Poziom dopasowania 90% 75%

Różnice względem najwyższego poziomu dopasowania

Modyfikator dostępu pola instan-cji oraz klasy o niższym poziomie dopasowania (wewnętrzny).

Wystąpił zerowy poziom dopa-sowania modyfikatora dla wła-ściwości/metody udostępniającej instancję (niestatyczny) oraz dla modyfikatora dostępu konstrukto-ra (nieprywatny).

Sugestie zmian Osiągnięcie możliwie najwyższego poziomu dopasowania zgodnie z wyznaczonymi różnicami.

Konsekwencje Występujące różnice są poprawną implementacją. Konsekwencją ich wystąpienia jest ograniczenie zasięgu dostępności instancji wzorca, co może być niekorzyst-ne w rozbudowanie aplikacji poprzez dodanie dodatkowych bibliotek, ponieważ będzie wy-magało ingerencji w istniejący

kod.

Nie możliwe jest odniesienie się do instancji bez inicjalizacji obiektu. Po inicjalizacji obiektu możliwe jest odniesienie się jednocześnie do instancji jak też bezpośrednio do elementów składowych, które powinny być dostępne wyłącznie poprzez odniesienie się do instancji. Oba niż-szego wyniku niż przypadek nr 1, o poprawnej implementacji, wynika z nieuwzględ-nienia współczynnika wagi dla weryfikowanych cech. Konsekwencji nie można po-równywać bezpośrednio ze sobą, ponieważ mogą objawić się w różnych fazach życia oprogramowania. W każdym przypadku warto ich uniknąć. Warto również zauważyć, że poważne błędy (przypadek 2) będą utrudniać proces wytwórczy już w czasie imple-mentacji. Natomiast błędy z pozoru mniej poważne (przypadek 1) będą miały duże znaczenie po zakończeniu procesu wytwórczego, tj. w czasie rozwoju i konserwacji oprogramowania.

Listing 1. Kod źródłowy przypadku nr 1.

internal class Singleton1

82 Od procesów do oprogramowania: badania i praktyka

Listing 2. Kod źródłowy przypadku nr 2.

5. Podsumowanie

W pracy krótko uzasadniono, dlaczego ważne jest weryfikowanie poprawności imple-mentacji wzorców projektowych oraz przedstawiono najważniejsze fundamenty badań powiązanych z weryfikacją wzorców projektowych.

Omówiono proces weryfikacji struktury wzorców projektowych, który polega na porównywaniu elementów badanego oprogramowania z szablonowymi elementami w modelu referencyjnym. Struktura abstrakcyjnego opisu wzorców projektowych w modelu referencyjnym oparta jest o założenia paradygmatu programowania obiek-towego, dodatkowo umożliwia opisanie różnych wariantów wzorców. Weryfikacja względem modelu referencyjnego dostarcza cząstkowe wyniki, ponieważ ów model jest częścią większego modelu, który to umożliwia całościową ocenę jakości imple-mentacji wzorców projektowych.

Dalsze prace przewidują przede wszystkim rozbudowę modelu referencyjnego, aby możliwe było opisanie złożonych wzorców oraz zwiększenie szczegółowości ich definicji.

Przeprowadzone prace nad opracowaniem i wykorzystaniem modelu referencyjne-go do weryfikacji wzorców projektowych wykazały, że jest to odpowiednie rozwiąza-nie do postawionego celu. Należy pamiętać, że ostateczrozwiąza-nie to model oceny jakości implementacji wzorców projektowych powinien zostać oceniony pod względem po-prawności w ocenie wzorców. Aktualne niedostatki proponowanego modelu referen-cyjnego ograniczają jego wykorzystanie do weryfikacji wzorców o prostej struk-turze, np. Singleton lub Strategia. Rozbudowa modelu o wymienione wcześniej rozsze-rzenia oraz równoległe wykorzystanie alternatywnych mechanizmów weryfikacji po-winno być wystarczające do opisania szablonów oraz weryfikacji większości z wzor-ców przedstawionych w [4].

Literatura

[1] Binun A.: High Accuracy Design Pattern Detection. Dysertacja doktorska, Rheinischen Friedrich Wil-helms Universitat Bonn, 2012.

[2] Blewitt A.: HEDGEHOG: Automatic Verification of Design Patterns in Java. Dysertacja doktorska, University of Edinburgh, 2006.

public class Singleton2 {

[3] Fabry J., Mens T., Language-Independent Detection of Object-Oriented Design Patterns, Journal Computer Languages: Systems and Structures, Vol. 30, Issue 1-2, 2004, s. 21-33.

[4] Gamma E. i inni: Wzorce projektowe. Elementy oprogramowania wielokrotnego użytku. Helion, Gli-wice, 2010.

[5] Grzanek K., Realizacja systemu wyszukiwania wystąpień wzorców projektowych w oprogramowaniu przy zastosowaniu metod analizy statycznej kodu źródłowego, Dysertacja doktorska, Politechnika Częstochowska, Łódź, 2008

[6] Gueheneuc Y.G., Jussien N., Using explanations for design patterns identification, Proc. First IJCAI Workshop Modeling and Solving Problems with Constraints, C. Bessière, ed., pp. 57-64, 2001.

[7] Kirasić D., Basch D., Ontology-Based Design Pattern Recognition, Knowledge-Based Intelligent In-formation and Engineering Systems, Zagreb, Croatia, 2008

[8] Krishnaswami N. R., Design Patterns in Separation Logic, TLDI'09, ACM, New York, 2009, s. 105-116.

[9] Strona internetowa: http://www.ndepend.com/, dostęp: 18.06.2015.

[10] McConnell S., Kod Doskonały, Helion, Gliwice, 2010

[11] Rasool G.: Customizable Feature based Design Pattern Recognition Integrating Multiple Techniques.

Dysertacja Doktorska, Technische Universitat Ilmenau, Ilmenau 2010

[12] Rasool G. i inni, Evaluation of design pattern recovery tools, Elsevier, Procedia Computer Science, Vol 3, 2011.

[13] Shi N., Ollson R.A., Reverse Engineering of Design Patterns from Java Source Code, ASE ’06: Pro-ceedings of the 21st IEEE/ACM, International Conference on Automated Software Engineering, pages 123–134, Washington, 2006.

[14] Singh Rao R., Gupta M.: Design Pattern Detection by Greedy Algorithm Using Inexact Graph Match-ing, International Journal Of Engineering And Computer Science, Volume 2 Issue 10, 2013, s. 3658-3664.

[15] Smith J., SPQR: Formal Foundations and Practical Support for the Automated Detection of Design Patterns from Source Code, Dysertacja doktorska, University of Noth Carolina, 2005.

[16] Tsantalis N. i inni: Design Pattern Detection Using Similarity Scoring, IEEE Transactions on Software Engineering,Volume: 32, Issue: 11, 2006, s. 896-908.

[17] Wojszczyk R.: Koncepcja hybrydowej metody do oceny jakości zaimplementowanych wzorców pro-jektowych, Zeszyty Naukowe Wydziału Elektroniki i Informatyki nr 7, strony od 17 do 26, Wydawnic-two Uczelniane Politechniki Koszalińskiej, ISSN 1897-7421, Koszalin 2015.

Rozdział 6

Model jakości danych: definicja i pomiary

1. Wprowadzenie

Dane w dzisiejszych czasach mają wartość podniesioną do rangi dobra gospodarczego, takiego jak waluta czy złoto. Mogą być reprezentowane w postaci napisów, liczb, zna-ków lub sygnałów, jak również w formie graficznej i audiowizualnej. Dane są zbierane i gromadzone w trakcie realizacji procesów o charakterze badawczym i biznesowym.

W związku z tym, że pełnią kluczową rolę w procesach decyzyjnych, ich jakość jest niezwykle istotna. Informacja jest efektem interpretacji i przetworzenia danych, dlatego gromadząc i organizując dane, należy mieć na uwadze również wymagania dotyczące pozyskiwania informacji. Informacja jest wnioskowana z danych, a jakość informacji jest ściśle związana z jakością danych i oznacza konsekwentne spełnienie oczekiwań klienta. Z informacją oraz danymi powiązana jest także wiedza. Wiedzę można zdobyć poprzez uczenie się. Można ją podzielić na teoretyczną i praktyczną. Jest dynamiczna, żyje w nas. Biorąc pod uwagę jakościową informację, kontekst i doświadczenie tworzy się nową, jakościową wiedzę.

Istnieje wiele różnych definicji jakości. Już w czasach starożytnych pojawiła się definicja, której autorem był Platon. Określił on jakość jako pewien stopień doskonało-ści [4]. Obecnie jest wiele definicji tego pojęcia. Europejska Organizacja Jakodoskonało-ści (EOQ) definiuje jakość jako stopień spełnienia wymagań, zgodność parametrów zało-żonych z uzyskanymi [12]. Z kolei Olson postrzega jakość poprzez spełnienie wyma-gań dotyczących przeznaczenia i przy jej ocenie proponuje wziąć pod uwagę aktual-ność, istotność i zrozumiałość danych [9]. W pracy „Information Quality” zapropono-wano dodatkowe cechy, ważne w kontekście oceny jakości, a mianowicie dokładność, kompletność, wiarygodność i współzależność [3]. Należy jednak pamiętać, że ocena jakości danych zależna jest od sytuacji, kontekstu czy preferencji. Dlatego zalecane jest podejście rozpatrujące różne perspektywy oceny, z uwzględnieniem opinii grup użyt-kowników przy jednoczesnej bezstronnej analizie danych [2].