Posty z kategorii: Projektowanie

Operacja Frontend + CMS cz. 2

Cześć !

W kolejnej części zmagań z przygotowaniem identyfikacji wizualnej, a przy tym nowego super szablonu dla mojej strony, porozmawiamy o nowinkach (może nie już takich ciepłych, ale za to bardzo ważnych!), które chciałbym wykorzystać przy implementacji szablonu. Dla części z Was na pewno będzie to oczywiste, a dla pozostałych może stanowić pewnego rodzaju przypomnienie.

Semantyka w HTML

Słowo semantyczny idąc za słownikiem języka polskiego oznacza:

Dotyczący znaczenia wyrazów; znaczeniowy

I dokładnie do tego odnosi się hasło semantyczny w języku HTML5. Pewnie każdy z Was pisał jakąś stronkę w HTML i tworzył takie potworki.

<body>
    <div class="grid-container">
        <div class="row">
            <div class="col-12"></div>
            <div class="row">
                <div class="col-12"></div>
            </div>
        </div>
        <div class="row">
            <div class="col-8">
                <div id="article-header"></div>
                <div id="article-content"></div>
                <div id="article-footer"></div>
            </div>
            <div class="col-4"></div>
        </div>
        <div class="row">
            <div class="col-12"></div>
        </div>
    </div>
</body>

Jak dobrze, że w Visual Studio Code jest Emmet… Samo myślenie o tym jest ciężkie, a co dopiero tego pisanie. Szablon oparty na wygenerowanej przez nas samych siatce lub dostarczonej z zewnątrz, np. przez Bootstrapa. O zgrozo, komu się chce to pisać! Plus dodatkowe klasy w zależności od rozdzielczości, w jakiej wyświetlana jest strona. Poza tym mówiliśmy wcześniej, że HTML służy do opisu struktury dokumentu, a tutaj na pewno tak nie jest. Dzisiaj dzięki semantyce w języku możemy to samo napisać w ten sposób (przede wszystkim prawidłowo!).

<body>
    <header>
        <nav></nav>
    </header>
    <main>
        <section>
            <header></header>
            <article></article>
            <footer></footer>
        </section>
        <aside></aside>
    </main>
    <footer></footer>
</body>

Język HTML dostarczył nowych znaczników, które jednoznacznie informują programistę (zaraz polecą baty, że w HTMLu się nie programuje i ja się w tym 100% zgadzam), kogoś kto zagląda w źródło strony, co w danej sekcji dokumentu się znajduje. Funkcjonalnością odpowiadają zwykłemu znacznikowi div. Co to daje w takim razie? Nie mogło zostać tak jak było? No nie. Dzięki temu dokument staje się czytelniejszy i jak definicja mówi, język służy do opisania struktury dokumentu. Jednoznacznie widać, gdzie jest zdefiniowany nagłówek strony, główna treść, stopka itd. Ponadto prawidłowe zaimplementowanie strony znacznikami semantycznym pozwala SEO lepiej pozycjonować nasza stronę oraz czytnikom dla osób niedowidzących prezentować treść w pożądany sposób. Tutaj dodatkowe fajne źródło!

Responsive design

Kolejny ze standardów dzisiejszego internetowego świata. Znaczy to tyle, ze odwiedzane przez nas strony maja się dostosowywać do urządzeń, na których są wyświetlane. Pamiętacie pewnie, dawniej strony tworzyło się w 5 wersjach i w zależności od tego, jakie urządzenie odpytywało serwer, to ten odpowiedni kontent mu serwował. Dzisiaj na szczęście odeszliśmy od tej nadmiarowej roboty i tworzymy jedna stronę, która w zależności od rozdzielczości wyświetlacza, dostosowuje wyświetlane treści, zmienia ich układ na stronie. Właściwie robi to przeglądarka. Dlatego też powstają pewne narzędzia wspomagające implementację responsywności. Powiesz teraz: Gościu, no właśnie to co powiedziałeś, że jest beeeee, to była droga do responsywności. I co teraz??? No to ja Ci powiem, zapoznaj się CSS Grid.

CSS Grid

Wyżej masz przykład, jakie cuda tworzyliśmy, kiedy chcieliśmy stworzyć stronę responsywną. Już nie będę tego komentował, ile nadmiarowego kodu… i weź to potem człowieku utrzymaj. No ni… Połowa znaczników to hacki na responsywność. Straszne rzeczy. I dlatego mądrzy ludzie wymyślili grid w CSSie. Z czym to się je? W telegraficznym skrócie – w arkuszu styli definiujemy sobie klasę, która przechowuje siatkę. Mówimy na ile wierszy i kolumn dzieli się owa siatka. Potem mówimy, które elementy znajdują się w kolejnych polach siatki. O, i działa. Koniec. No dobra mistrzu, a jak zamienić miejscami elementy ze sobą? Hmm no normalnie by się nie dało bez użycia JS. A tutaj… 🙂 Wystarczy zdefiniować odpowiednią regułę @media  opisującą siatkę dla danej rozdzielczości i przeglądarka sama poprzestawia elementy. Chcecie przykład? No to klikamy play 😉 Z tego też przykładu nauczyłem się używania gridów. Fajny filmik znalazłem w jutubach:

No i jeszcze polecam prezentację Mortena Rand-Hendriksena z konferencji Wordcamp Europe 2017, jakoś przypadkowo się na nią natknąłem i od razu chciałem to zaimplementować w swoim szablonie 🙂

Stylizacja

No dobrze, troszkę mechaniki omówiliśmy, czas na karoserię. Mamy w architekturze pewne style architektoniczne, czy to historyczne, np. Gotyk, barok, czy dzisiejsze (tu nie będzie przykładu, bo się na tym nie znam). Przy projektowaniu UI aplikacji też są dostępne pewne style designu. Jednym z nich jest tak zwany Material Design od Google. Na pewno go kojarzycie, chociażby z klienta Gmail w Androidzie. Sami twórcy mówią o nich tak:

We created Material Design as a metaphor to rationalize design and implementation, establishing a shared language to help teams unite style, branding, interaction, and motion under a cohesive set of principles.

We believe a better design process yields better products, which is why we’re expanding Material to be a system that supports the principles of good design and strengthens communication and productivity with new tools and inspiration. We hope these resources will help teams realize their greatest design potential, and we’re eager to see the results.

A więcej możecie przeczytać na stronie Material.io.

Mówiłem, że nie będę korzystał z bibliotek zewnętrznych, ale nie mówiłem, że nie będę się na nich wzorował (w celach edukacyjnych oczywiście). Sam Google dostarcza bibliotekę, która pozwala na łatwe użycie elementów stylizowanych na Material Design. Więcej informacji na stronie frameworku Material Design Lite.
Niestety nie nam jakiegoś mega zmysłu grafika i ciężko mi spłodzić coś, co wygląda ładnie. Dlatego wzorowanie się na powyższej bibliotece ułatwi mi uzyskanie oczekiwanych funkcjonalności oraz przy okazji dobry wygląd (chociaż nie to jest ładne, co jest ładne, tylko to, co się komu podoba).

Ale jak w ogóle pisać dobrze te CSSy? Na blogu Żanety Jażdżyk Nettecode.com we wpisie Kierunek: Web Developer cz. I jest link do bloga NaFrontedzie.pl, gdzie autor opisuje różne metodyki tworzenia CSSów. W tym projekcie najprawdopodobniej zastosuję OOCSS (postaram się, ponieważ będzie to mój pierwszy raz).

Połączenie z WordPressem

No dobrze, to załóżmy, że mamy gotową w głowie kompozycję naszej strony, tylko… jak to spiąć z WordPressem? A no należy skorzystać z API! Dla niewtajemniczonych API, to skrót od Application Programming Interface. Z polskiego na nasze jest to zbiór funkcji czy metod, które pozwalają nam uruchomić żądane funkcjonalności w danej aplikacji. WordPress również dostarcza API, które należy wykorzystać przy rozwoju szablonu. Wbrew pozorom dobry programista charakteryzuje się trudną umiejętnością korzystania z dokumentacji i wcale nie mówię tego prześmiewczo. Korzystanie z dokumentacji nie jest sztuką łatwą i potrzeba sporo praktyki, żeby sprawnie się w niej poruszać. Przy praktyce programistycznej ilość materiałów jest duża. Jednak z praktyki inżynierskiej mam doświadczenia, że często naszą jedyną deską ratunku jest dokumentacja i na jej podstawie trzeba stworzyć coś. Nie ma podpowiedzi na StackOverflow czy innych serwisach, szczególnie, kiedy wchodzimy w bardzo specjalistyczną działkę. Dlatego tutaj będzie dobra okazja do przetrenowania tego skilla 🙂 A jeden z tutoriali jutubowych do tworzenia tematów w WordPressie możecie znaleźć tutaj 🙂

Kompatybilność z przeglądarkami

Wszystko ładnie pięknie, ale czy aby na pewno wszystkie dostępne dziś przeglądarki to obsługują, o czym piszesz na początku? Jak to sprawdzić? No jest taka stronka CanIUse.com, gdzie możemy sobie wyszukać interesujące nas ficzery i zobaczyć, które wersje przeglądarki to obsługują.

A co będzie z tymi użytkownikami, którzy korzystają z IE8 przykładowo albo wyświetlają Twoją stronę na cegle? No nic. Doszedłem do wniosku, że nie będę pakował jakiś sztucznych fixów na archaiczne przeglądarki, skoro i tak wiem, że na 99,99999% żaden z odwiedzających tego bloga nie korzysta z takich archaizmów. Będę się więc starał używać nowych technologii w najczystszej postaci. Jeżeli komuś coś nie będzie działało, to zawsze można to zgłosić przez zakładkę kontakt 🙂 Zdecydowana większość cywilizowanych przeglądarek obsługuje wszystkie nowe znaczniki z HTML5 i style CSS3.

Kurcze, kurcze, ja też chcę!

Zapytasz jak zacząć. Nie będę tworzył n-tego posta w Internecie, jak zacząć zabawę z frontem. Świetną robotę zrobiła już Pani Żaneta na swoim blogu 🙂 Tam znajdziesz milion ciekawych linków, z których i ja korzystam. A jak nie, to wujek Google i trzeba poszukać 🙂 Myślę, że szukanie nie zajmie więcej niż 30 sekund 🙂

Podsumowanie

Dobra Misie kolorowe, myślę, że poruszyłem mega ważne zagadnienia, które często gdzieś umykają. Mam nadzieję, że zainteresował Cię temat i będziesz chciał pogłębić swoją wiedzę. Jeżeli chcesz się do mnie przyłączyć to śmiało daj znać! A tym czasem trzymaj się i do zobaczenia gdzieś, kiedyś, na ulicy! 🙂

Operacja Frontend + CMS cz. 1

Cześć!

Zgodnie z wcześniejszą zapowiedzią, bierzemy się za tzw. mięso. Czas się wziąć za przygotowanie nowego szablonu strony. Może wydawać się to troszkę śmieszne, ale jakoś dawno nie miałem okazji pogrzebać nic więcej w szeroko rozumianym froncie, więc drobna okazja właśnie się do tego nadarzyła. Jakie to ma plusy?

Nie ma co zwlekać, czas się wziąć za robotę!

Stos technologiczny

Od najniższego poziomu abstrakcji do najwyższego.

  1. Treść – oczywiście sama zawartość  zostanie opisana przy pomocy języka znaczników HTML5. Jest to standard w dzisiejszym Internecie i choćby dlatego warto to znać. Szczególną uwagę przyłożę do stosowania znaczników semantycznych. Pozwalają one na wyszczególnienie konkretnych fragmentów strony, co niesie ze sobą wiele korzyści. Przede wszystkim pozwala na usystematyzowanie zawartości strony, po drugie optymalizuje stronę pod względem wyszukiwarek. Ponadto sam format jest czytelniejszy dla tworzącego dokument. Należy zwrócić uwagę, aby oddzielić poszczególne warstwy od siebie. W dokumencie HTML nie możne znaleźć się osadzony styl CSS lub kod JS (przynajmniej nie powinien, jest to nieeleganckie, a my jesteśmy dżentelmenami :)). Dokument HTML z definicji ma za zadanie tylko i wyłącznie opisywać strukturę dokumentu, a nie jego wygląd. Do opisu wyglądu służą arkusze, które muszą znaleźć się w osobnych plikach.
  2. Wygląd – oczywiście będzie królował CSS3 i co do tego nie ma żadnych wątpliwości. CSS w wersji 3. daje bardzo dużą pulę narzędzi, które umożliwiają dynamiczne generowanie wyglądu strony. Dawniej wszystko się rysowało i wstawiało jako zdjęcia – cienie, ramki itd. Pamiętam nawet korzystałem z programu, który generował „fajne” przyciski… Dzisiaj patrzę na to z pożałowaniem… Na szczęście cały czas się rozwijamy! Wcześniej wspomniałem też o odizolowaniu warstwy dokumentu i wyglądu. Dzięki strona będzie złożona z łatwo wymienialnych modułów. Bardzo fajną analogią jest gniazdko zasilające w ścianie i urządzenia elektryczne. Łączą się ze sobą ściśle ustalonym interfejsem a jednocześnie są od siebie niezależne. Drugą bardzo ważną rzeczą dostarczoną przez CSS3 są tak zwane siatki (grid). Przyda się to przy implementacji responsywności strony, ale o tym niżej. Przy okazji nie będę korzystał z żadnych preprocesorów – mam założenie zagłębienia się w podstawy.
  3. Interakcja – JavaScript. Język, w którym budowane są dzisiaj całe serwisy, ale ja postaram się, aby po wyłączeniu obsługi JavaScript strona dalej zachowywała swoje funkcjonalności. Podziękujcie za to Krzaqowi – rozmawiał o tym z Maciejem Aniserowiczem w DevTalku z laureatami DSP. A postaram się to przetestować m. in. w takiej przeglądarce, którą zwą Elinks. Poniżej próbeczka:
  4. Obsługa treści – stary dobry WordPress (chociaż co do tego, czy dobry to zdania są podzielone). Ja używam i nie narzekam. Wychodzę z założenia, że trzeba sobie życie ułatwiać, a nie utrudniać. Dla mnie ten CMS jest wystarczający i bardzo ułatwia codzienną pracę z blogiem. Nie mam jakiś specyficznych wymagań co do funkcjonalności. Poza tym nawet jeżeli będę kiedyś potrzebował coś szczególnego, to sobie dopiszę wtyczkę 🙂 No właśnie, przy okazji WordPressa trzeba wspomnieć o PHP. Został on w nim stworzony, więc nie uniknę styczności z tym językiem. Podobno w wersji 7.x jest całkiem fajny 🙂 A no i najważniejsze – szablon musi być zbudowany zgodnie z API WordPressa.
  5. Reszta świata – postaram się nie korzystać z żadnych frameworków czy bibliotek. Chodzi o to, żeby poznać się z podstawami technologii. Czysty JS i PHP, czysty CSS bez stosowania preprocesorów (LESS, SASS, SCSS). Po prostu nie. Co najwyżej skorzystam z Grunta albo Gulpa do minifikacji plików. No i najważniejsze – Git. Kod będzie dostępny u mnie w repozytorium. Przy okazji potrenujemy sobie zabawy z tym systemem kontroli wersji. Nad projektem graficznym będą czuwały zasady Material Design.

Podsumowanie

O tak, zaczynamy powoli bawić się w tak zwane mięsko. Wypisałem podstawowy stos technologiczny, który swoją drogą nie jest zbyt wyszukany, ale taki ma być. Myślałem, że więcej  uda mi się opisać w tym wpisie, jednak jak sobie podsumowałem wszystko, to wyszło bardzo dużo zagadnień. Dlatego podzielę ten wstęp na kilka części. W następnej odsłonie, która być może ukaże się szybciej niż za tydzień, opowiem o smaczkach, które chciałbym zaimplementować w swoim szablonie, podam parę ciekawych źródeł oraz bardziej zagłębię się w poszczególne elementy stosu. Oprócz tego zaprezentuję Ci grafiki ilustrujące szablon strony na urządzenia mobilne oraz tablety i desktopy. Zapraszam do śledzenia! Czołem! 🙂

MVP i MVC – wstęp, rozwinięcie, bez zakończenia

Siyakwamukela! (zulu)

Wracamy do rozważań nad modelowanie aplikacji. W ostatnim wpisie, gdzie wyciągaliśmy informacje ze scenariuszy przypadków użycia narzuciłem temat wzorców architektonicznych MVP i MVC. Wtedy o nich wspomniałem, podlinkowałem parę rzeczy, jednak dzisiaj mam nadzieję troszkę to rozwinąć 🙂

Wzorce projektowe i architektoniczne

Wzorzec projektowy jest narzędziem do rozwiązywania powtarzalnych problemów pojawiających się podczas implementacji oprogramowania. Co ważne, wzorzec mówi tylko, jak podejść do problemu, od której strony go ugryźć, daje schemat rozwiązania zagadnienia. O wzorcach projektowych powstała świetna książka, którą napisali Erich Gamma, Richard Helm, Ralph Johnson i John Vlissides, czyli grupa określana „Bandą czworga”. Mowa oczywiście o książce „Wzorce projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku„. W dzisiejszym programowaniu bez wzorców projektowych nie ma sensownej pracy.

Wzorzec architektoniczny jest podobnym narzędziem do wzorca projektowego, jednak tutaj problemy implementacyjne nie dotyczą relacji klas, obiektów, zaś odnoszę się do struktury systemu, podziału na moduły i relacji pomiędzy nimi. MVP i MVC są właśnie takimi wzorcami.

Zacznijmy od MVC

Głównym zadaniem programisty nie jest wbrew pozorom zaimplementowanie fury kodu, która robi coś tam. Programista jest postawiony przed pewnym problemem, którego musi dokonać analizy i wykonać podział na mniejsze, dające się łatwo zaimplementować fragmenty. Implementacja jest procesem wtórnym.

We wzorcu MVC podchodzimy do analizowanego problemu rozbijając go na trzy składowe, od których bierze się nazwa wzorca:

  1. Warstwa Model – w tej warstwie zawieramy całą logikę biznesową aplikacji. Bardzo ważnym jest, aby nie mieszać warstw ze sobą i żeby rzeczywiście cała logika biznesowa została w tej warstwie.
  2. Warstwa View, czyli widoku – w tej warstwie zawierają się wszystkie klasy, których obiekty potem zmaterializują się w postaci interfejsu graficznego wyświetlanego użytkownikowi; poszczególne fragmenty widoku odpowiadają odpowiednim fragmentom modelu
  3. Warstwa Controller, czyli kontroler – przyjmuje akcje wywołane przez użytkownika, względem których odpowiednio zarządza aktualizowaniem modelu.

Taki podział systematyzuje sposób budowy tworzonego oprogramowania. Na poniższym diagramie można zaobserwować przebieg działania systemu zbudowanego w ten sposób.

Użytkownik systemu wciska przycisk, który jest elementem warstwy widoku. Zdarzenie to jest przekazywane do kontrolera. Kontroler wywołuje odpowiednie działania w warstwie modelu. Po wykonaniu operacji model wywołuje aktualizuje widoku, który to pobiera nowe dane w trybie odczytu z warstwy modelu, już bez uczestniczenia kontrolera.

A MVP?

We wzorcu Model-View-Presenter warstwy są tak samo podzielone. Tutaj zamiast warstwy kontrolera, mamy prezentera, który rozdziela warstwy widoku i modelu. Relacja pomiędzy warstwami wygląda jak na poniższym diagramie.

Znów widok wywołuje, tym razem w prezenterze, akcję wychwyconego zdarzenia. Prezenter zarządza aktualizację modelu. Kiedy to zostanie wykonane, model informuje prezentera, że jego stan uległ zmianie. Prezenter pobiera zaktualizowane dane z modelu, odpowiednio je formatuje i przesyła do warstwy widoku, która prezentuje je użytkownikowi.

Zastosowanie

Wzorce MVP i MVC są powszechnie stosowane w projektach. U mnie też będą zastosowane, tak jak już o tym pisałem. Na diagramach klas dla każdego scenariusza, które mam nadzieję niebawem się pojawią zobaczysz fizyczną realizację architektury systemu zgodnie ze wzorcem MVP. Taka struktura systemu jest elastyczna, łatwo można podmieniać poszczególne warstwy dlatego, że są rozdzielone od siebie.

Podsumowanie

Diagramy miały się już pojawić, ale niestety się nie ogarnąłem z tym. Jak się pali, to od razu cała wieś post ten powstał, ponieważ jeden z czytelników zasugerował mi dogłębniejsze pochylenie się nad tymi wzorcami, które de facto są bezpośrednio związane z moim projektem 🙂 Teraz niestety zaliczenia na dwóch kierunkach biorą górę i muszę się nad tym skupić, zatem na chwilkę wygaszamy pracę nad projektem. Co się odwlecze to nie uciecze 🙂 W zanadrzu mam jeszcze jeden post dla Was, ale musicie być cierpliwi 🙂

Oczywiście zachęcam do komentowania i udostępniania mojej twórczości. Każda interakcja jest na wagę złota, ponieważ pokazuje, że ktoś czyta moje wypociny 🙂 Tymczasem życzę Ci miłego dnia i do zobaczenia! 🙂

MagazineManager – czas zamodelować cz. 4

Wëllkomm! (luksemburski)

Jak się trzymasz? Co u Ciebie drogi Czytalniku? Mam nadzieję, że wszystko w porządku 🙂 Pora kontynuować modelowanie naszej aplikacji. Ostatnio omówiliśmy scenariusze przypadków użycia, co to jest i po co, jak się je tworzy. Jak zapewne widzisz, proces modelowania oprogramowania to logiczny ciąg kolejnych czynności, które prowadzą do przygotowania naprawdę dobrego gruntu do kodowania. Przyjrzyjmy się zatem jednemu ze scenariuszy przypadków użycia. Niech będzie ten dotyczący edycji danych o czasopiśmie:

1. Użytkownik naciska przycisk Edytuj.
2. System wyświetla formularz edycji czasopisma z uzupełnionymi aktualnymi danymi.
3. Użytkownik edytuje dane.
4. Użytkownik naciska przycisk Zapisz.
5. System pobiera dane z formularza.
6. System waliduje dane.
7. System aktualizuje dane w bazie.
8. System wyświetla komunikat o poprawnej aktualizacji danych.

Analiza scenariusza przypadku użycia

Spróbujmy teraz wyciągnąć z niego jakieś wnioski. Mam nadzieję, że pamiętasz z poprzedniego wpisu (jeżeli nie to zachęcam do przeczytania) o sposobie budowania zdań w scenariuszu – podmiot, orzeczenie, dopełnienie, krótkie, proste i rzeczowe zdania. Przeanalizujmy zatem co taka koncepcja może za sobą wnieść do tego scenariusza.

Podmiot mówi bezpośrednio o wykonawcy czynności opisanej – jest to aktor danego przypadku lub system. Cały scenariusz można sobie wyobrazić jako rozmowę aktora z systemem, gdzie słowami, które się wypowiada, czyli przekazuje drugiej osobie jest przepływ sterowania (sterowanie rozumiemy jako wykonanie czynności). Ciśnie mi się porównanie tej rozmowy do tańca, który jest jakby nie patrzeć rozmową pomiędzy kobietą a mężczyzną, tylko w takiej formie taniec może przenieść pełny bagaż emocji i odczuć. Taka luźna dygresja, która nie wiem czemu mi tu pasuje 😀

Orzeczenie to oczywiście czynność wykonywana w danym kroku. A co w kodzie determinuje wykonanie czynności? Tak, dokładnie, wywołanie metody! Jak się pewnie już domyślasz, w naszej aplikacji znajdą się metody aktualizujDane() czy walidujDane(), których argumentem będzie… No właśnie co?

Przechodzimy do dopełnienia. W dopełnieniu przemycamy elementy interfejsu użytkownika, np. przycisk, w kodzie zostanie utworzona tego typu klasa, lub klasy bezpośrednio związane z modelowaną aplikacją, np dane (w domyśle myślimy o danych czasopisma, jednak prawidłowo w napisany scenariusz powinien jednoznacznie na to wskazywać). Proste, prawda :)?

Jak widzisz, dobrze napisany scenariusz to skarb, z którego można wiele odczytać. Po przeanalizowaniu scenariusza można narysować diagram klas, który odwzoruje prawdziwą strukturę kodu, pracującą w projektowanej aplikacji.

Systematyzowanie kodu aplikacji

Czy te informacje, które wyciągamy ze scenariusza, da się w jakiś sposób pogrupować, usystematyzować, oprócz oczywistego wyłuskania klas i metod? Jasne, że tak. Chyba najbardziej widoczna grupa klas, to klasy odpowiadające za elementy interfejsu użytkownika. I w tym miejscu stop. Opowiemy sobie o wzorcach projektowych MVP i MVC, które swoją drogą różnią się od siebie niewiele, dlatego czasem ludzie stosują te nazwy wymiennie (co jest oczywiście błędem!).

MVC i MVP

Pomyślmy sobie tak. Na jakie warstwy możemy podzielić aplikację? No oczywiście na pewno warstwa odpowiadająca za wyświetlanie danych i cały interfejs graficzny. I to będziemy nazywać Widokiem, z ang. View. Drugą warstwą jest grupa klas bezpośrednio opisujących elementy naszego problemu, u nas czasopisma, egzemplarze etc. Tę warstwę nazywamy Model. No i teraz to musimy jedno z drugim połączyć. A gdzie występuje to połączenie? No… W scenariuszu. I za tę realizację scenariusza odpowiadają klasy Presentera. To własnie on odpowiada za wywołanie odpowiedniego widoku, pobranie z niego danych i przekazanie ich do modelu. Potem model po otrzymaniu danych i ich obrobieniu zwraca informację do prezentera i prezenter odpowiednio aktualizuje widok.

Czym zatem różni się MVP od MVC? Otóż jak w MVP to prezenter otrzymywał informację zwrotną od modelu i aktualizował widok, tak tutaj to już nie prezenter a kontroler odpowiednio wywołuje akcje na modelu i model sam bezpośrednio aktualizuje widoki.

Warto w Google wpisać mvp vs mvc i wtedy można dokładnie wczytać się w oby dwa podejścia. Polecam też zajrzeć do Wikipedii: MVP oraz MVC.

Podsumowanie

W najbliższym czasie, dziś już nie zdążę, biorę się za rozrysowanie diagramów klas na podstawie scenariuszy przypadków użycia. W swojej aplikacji wykorzystam architekturę MVP. Taki plan na najbliższe kilka dni. Zachęcam do wyszukiwania informacji na temat MVP i MVC, bo to jest bardzo aktualny i świeży temat. Tymczasem życzę Ci drogi Czytelniku miłego popołudnia, wieczoru lub dnia w zależności od tego, kiedy to czytasz. 🙂 Jeżeli podoba Ci się mój wpis, to udostępnij go proszę swoim znajomym, kliknij łapkę w górę na Facebooku i obserwuj mnie na Twitterze. Do zobaczenia! 🙂

MagazineManager – czas zamodelować cz. 3

Привет! (rosyjski)

Sobota, więc chwila czasu na ogarnięcie posta, którego w sumie dawno nie było 🙂 Ale wiele się dzieje, dlatego byłem zmuszony poluzować z pisaniem, a nie chcę na siłę pisać czegoś, co będzie mało wartościowe. Co się odwlecze, to nie uciecze i dzisiaj siadamy do dalszego omawiania 🙂

Przedmiot rozważań

Głównym tematem tego wpisu będą tak zwane scenariusze użycia inaczej zwane też scenariuszami współpracy. Każdy przypadek użycia, który przedstawiony jest na diagramie, reprezentuje oczekiwane zachowanie systemu skutkujące osiągnięciem pewnego celu. Do jego osiągnięcia koniecznym jest wykonanie szeregu czynności jedna po drugiej. Właśnie ten szereg czynności modelujemy przy pomocy scenariuszy użycia. Proste, prawda :)?

Charakterystyka scenariuszy przypadków użycia

Scenariusz przypadku użycia opisuje kolejne kroki do osiągnięcia rezultatu oczekiwanego prze zdefiniowany przypadek użycia. Opis ten można wykonać na kilka sposobów. Sam scenariusz jest fragmentem opisu przypadku użycia. Wykonywany jest w postaci listy numerowanej kolejnych kroków lub przez wykonanie diagramu czynności w języku UML. Diagramami czynności zajmiemy się w kolejnym odcinku. Na początek przygotujemy sobie scenariusze w postaci listy, przez co narysowanie diagramów będzie łatwiejsze.

Opis

Pełen opis przypadku użycia zawiera takie elementy jak:

Scenariusz

W repozytorium możesz zobaczyć, jak wyglądają utworzone przeze mnie scenariusze użycia. Jest to lista kroków, która opisuje przebieg całego przypadku użycia. W niektórych miejscach na samym początku jest wyszczególniony warunek początkowy. Mówi, co musi być spełnione, aby dany przypadek mógł zostać uruchomiony.

Zwróć uwagę na charakterystyczną budowę zdań. Składają się one z podmiotu, orzeczenia i dopełnienia (niezbyt rozbudowanego). Jest to bardzo ważne, ponieważ ułatwia wyszczególnić, jakie elementy biorą udział w danym przypadku użycia.

Kolejnym ważnym aspektem jest też pierwszy punkt każdego scenariusza. W zdecydowanej większości przypadków to użytkownik (czy system, który współpracuje z naszym) rozpoczyna sekwencję! Aktualnie nie mam nawet pomysłu, kiedy to nie użytkownik zaczyna 🙂

Dalej, scenariusz nie jest pojedynczą metodą. Scenariusz opisuje interakcje użytkownika i naszego systemu, dlatego też każde orzeczenie zdania odpowiada wywołaniu metody.

Na końcu scenariusza podane są także alternatywne drogi, które opisują, co się dzieje w przypadku wprowadzenia błędnych danych czy innych błędów systemowych.

Zastanawiasz się też może, czemu w scenariuszu nie podajemy punktu typu: System wraca tam gdzie był. Nie robi się tego, ponieważ traktuje się to domyślnie 🙂

Podsumowanie

Dzisiaj króciutko (w końcu!) przedstawiłem Ci, drogi Czytelniku, esencję informacji o scenariuszach przypadków użycia. Zapraszam do repozytorium a po inne informacje, na znaną Ci już stronę. Oczywiście też odsyłam do czeluści internetów i książek 🙂

Zapraszam do komentowania, powiedz proszę, czy wolisz posty krótsze, czy może dłuższe 🙂

A no i ostatnie na koniec 🙂 Zauważyłem, że czegoś brakuje w diagramie przypadków użycia 🙂 Kto mi powie czego :D?

Miłego dnia!

MagazineManager – czas zamodelować cz. 2

Byenveni! (kreolski)

Niedziela, 06.04, mija szósty tydzień Daj się poznać. Jesteśmy za półmetkiem, ale mimo to spokojnie idziemy z projektem. Ważniejsze jest dla mnie przekazanie treści i dobre zaprojektowanie, niż naklepanie tego bez przemyślenia z niskiej jakości kodem w dwie noce 🙂 Niestety ten tydzień przyniósł za sobą wiele tematów do ogarnięcia i powstał tylko wpis, który aktualnie czytasz, drogi Czytelniku. Ale wiesz co jest najważniejsze dla mnie? Że ciągnęło mnie do napisania kolejnego wpisu i strasznie mnie złościło, że musiałem w tym tygodniu pofolgować… Uważam to za mój mały wielki sukces 🙂 Dlaczego zapytasz? Bo pomału wchodzi mi w krew prowadzenie tego skromnego przybytku. Czuję też, że dzięki temu się rozwijam i żałuję, że nie mogę poświęcić tyle czasu ile bym chciał, ale żeby tak było, to musiałbym poświęcić wszystko inne i siedzieć całe dnie nad tym, a tego się (niestety) nie da 😀 Widzę także, nad czym muszę popracować od strony technicznej bloga (tutaj jest milion rzeczy do zrobienia), ale także od mojej osobowej strony (redukcja obowiązków oraz lepsze zarządzanie czasem). Mógłbym jeszcze wiele pisać, ale o tym powstanie osobny post 🙂 Czas teraz wracać do naszych schematów.

Wstęp

W ostatnim poście powiedzieliśmy sobie w dwóch słowach o modelowaniu i stworzyliśmy sobie szkice tychże diagramów. W momencie gdy to czytasz, uległy one modyfikacjom. Teraz omówimy sobie ogólnie z czego składają się te diagramy, opiszemy krótko notację, a na koniec powiemy w kilku słowach o systemie.

Diagram przypadków użycia (Use Case)

Pierwszym diagramem, który sobie omówimy jest diagram przypadków użycia. Na nim przedstawione są funkcje, których oczekują użytkownicy od naszej aplikacji lub zewnętrze systemy korzystające z tworzonego przez nas systemu. Na diagramie wyróżniamy komponenty takie jak:

To tak w skrócie, tyle jest potrzebne do zrozumienia całego diagramu. Jeżeli chodzi o symbole, to jak się pewnie domyślasz patrząc na w dymkach opisujemy przypadki użycia, a ludziki reprezentują poszczególnych aktorów. Warto dodać, że jeżeli aktorem jest system zewnętrzny, to możemy zmienić ikonę na inną.

Aktorzy mogą być generalizowani. Przykład? Proszę bardzo. Mamy sklep. W sklepie pracuje kasjer, kierownik, oraz osoba sprzątająca. Każda z nich będzie oczekiwała innych funkcjonalności, dlatego powstanie dla każdej z nich osobny diagram reprezentujący owe przypadki użycia. Ale zauważ, że możemy utworzyć aktora o nazwie Pracownik, który dla którego wyspecyfikujemy funkcjonalności wspólne dla tych trzech typów użytkowników, np. rejestrowanie przyjścia do pracy, rejestrowanie wyjścia z pracy. Relacje generalizacji, oznaczamy przez strzałkę z pustym w środku grotem, jak na poniższym diagramie.

Generalizacja aktorów

Oczywiście to zalążek tego, co można powiedzieć o diagramie przypadków użycia. Po więcej informacji kieruj się w stronę czeluści internetu 🙂 Dodatkowe oznaczenia, krotności oraz pułapki, na które trzeba uważać przy tworzeniu diagramów użycia.

Diagram klas (struktury obiektów)

Modelując program obiektowo szukamy wzorców, czyli klas, stanowiących szablony obiektów, które są ze sobą w jakiś sposób powiązane. I te właśnie powiązania przenosimy „na papier” rysując diagram klas lub diagram struktury obiektów. Dla wyjaśnienia w diagramie klas operujemy tylko na klasach, w diagramie struktury obiektów reprezentujemy relacje pomiędzy konkretnymi instancjami klas, będących w konkretnym stanie.

Klasę (lub obiekt) przedstawiamy w postaci prostokąta podzielonego w pionie na 3 części: w górnej nazwa klasy, w środkowej nazwy pól klasy poprzedzone znakiem + dla dostępu public, – dla private oraz # dla protected oraz po nazwie i dwukropku występującym typie pola, a w ostatniej nazwy metod opisane podobnie jak nazwy pól.

Ponadto wyznaczamy na diagramie relacje zachodzące pomiędzy klasami:

Więcej informacji o relacjach i sposobie ich oznaczania możecie znaleźć pod tym linkiem.

Podsumowanie diagramów

Starałem się dosłownie w kilku słowach wyjaśnić Ci, co znaczą symbole na powyższych diagramach oraz jak je interpretować. Mam nadzieję, że udało mi się to chociaż w małym stopniu. Temat diagramów jest mega duży i nie sposób w kilkuset słowach w poście powiedzieć wszystkiego, ani nawet wystarczającego minimum. Bardzo ciekawym źródłem informacji jest ta strona. Gdyby miał pisać posty tylko o UML to za jakikolwiek kod wziąłbym się za 2 lata chyba 😛 Dlatego jeśli chcesz wiedzieć więcej (a warto!) to zapraszam Cię do przestudiowania powyższej strony, czy poszukania innych, może jeszcze lepszych źródeł. Jeżeli znajdziesz, podziel się! 🙂

MagazineManager – diagramy, kontynuacja

Teraz kilka słów o diagramach stworzonych do MagazineManager’a.

Diagram przypadków użycia odzwierciedla to co jest zapisane w pliku PDF. Jest jeden aktor, ponieważ każdy użytkownik będzie sobie indywidualnie zarządzał bazą.

Diagram klas przedstawia logiczną hierarchię interakcji kolejnych klas. Zastosowana relacja kompozycji określa zależność, iż na przykład magazyn może istnieć bez egzemplarzy, jednak egzemplarz magazynu nie. Określone również zostały krotności relacji. Zależność pomiędzy klasami jest liniowa, ideowo program jest dość prosty.

Diagram klas odzwierciedla rzeczywiste obiekty. W dalszym kroku przygotowane zostaną diagramy klas, które zostaną zaimplementowane w programie, czyli uwzględnią warstwy widoku, prezentera oraz transferowe. Ale to przyszłość 🙂

Czas kończyć…

Dzisiaj bardzo owocny dzień. Przygotowanie tego posta zajęło mi ok. 6 h. Długo, niedługo, starałem się jak najlepiej to zrobić i jak najwięcej pokazać 🙂 Zachęcam do dyskusji w komentarzach! Chciałbym, żeby ktoś świeżym okiem na to spojrzał i powiedział: „Stary, a może tak będzie lepiej?” Bardzo lubię z kimś rozmawiać w czasie projektowania, ponieważ wtedy mózg pracuje na 500% i rzeczywiście model jest najlepszy 🙂

Nie przeciągając, życzę Ci dobrego przyszłego tygodnia oraz do zobaczenia przy kolejnym wpisie 🙂 Cześć! 🙂

MagazineManager – czas zamodelować cz. 1

Xush kelibsiz! (uzbecki)

Niedzielne popołudnie, a ja już drugi tydzień wyrabiam normę trzech postów w tygodniu. I… dobrze mi z tym! Mam nadzieję, że uda się utrzymać tę passę, ponieważ prowadzenie tego małego dobytku sprawia mi naprawdę dużo frajdy 🙂 Dokładniej sobie o tym porozmawiamy już niedługo, więc na ten temat na razie się nie będę rozpisywał 🙂

Za to dzisiaj rozpiszę się o czymś innym. Mianowicie o modelowaniu i narzędziach do niego wykorzystywanych. Znów to troszkę potrwa, ponieważ wiele zagadnień chcę poruszyć dla Ciebie, drogi Czytelniku, ale również dla siebie, żeby usystematyzować swoją wiedzę na ten temat. Sposób nauki poprzez tłumaczenie komuś, tego co się nauczyło, bardzo pomaga w dokładnym zrozumieniu tematu i utrwalaniu wiadomości (o czym, np. ostatnio słyszałem we vlogu Mirosława Burnejki oraz o czym też mówi Mirosław Kardaś – drugiego Mirosława polecam, jeżeli ktoś chce zacząć zabawę z mikroprocesorami rodziny AVR). Dlatego też rozwój projektu jest dosyć powolny, ponieważ traktuje go tylko jako dodatek oraz podkładkę do nauki i przykład praktycznego zastosowania teorii. 🙂

Co to jest modelowanie i po co ono jest?

Jak widzisz, bardzo dużą wagę przykładam do projektowania aplikacji. Czy to dobrze, czy źle… Ja uważam, że dobrze. Za kilka tygodni zobaczycie, że zakodzenie dobrze zaprojektowanej aplikacji trwa moment. Dlatego bardzo ważnym etapem projektowania jest modelowanie. A co to w ogóle jest? Modelowanie jest narzędziem pozwalającym na zobrazowanie potencjalnie trudnych i skomplikowanych zagadnień, które będziemy chcieli rozwiązać przy pomocy tworzonego przez nas oprogramowania. Brzmi trudno, jednak w rzeczywistości jest odwrotnie! Modelowanie pozwala na pokazanie obiektów i interakcji między nimi oraz pozwala zrozumieć architekturę tworzonego systemu nawet przez osoby nie będące programistami (ale to dzięki zapisowi o którym zaraz).

Jak i czym modelować?

Oczywiście powstało wiele narzędzi do tego. Jednym z nich, powszechnie używanym jest język UML. Ustandaryzowana struktura diagramów i symboli umożliwia opisanie rzeczywistości, obiektów w niej się znajdujących wraz z ich stanami oraz powiązaniami. Po dokonaniu tego opisu możemy zamodelować kod, który powinien być zgodny z tym, co odnajdujemy w świecie rzeczywistym. Warto może tutaj dodać, że skupiam się na modelowaniu obiektowym, bo i w takim paradygmacie tworzę swoje oprogramowanie oraz paradygmat ten jest najbardziej popularny dzisiaj na świecie (jeżeli się mylę poprawcie mnie!). Więcej o samym języku UML możecie poczytać na Wikipedii lub w książce profesora Michała Śmiałka Zrozumieć UML 2.0, z którym miałem przyjemność mieć zajęcia własnie z przedmiotu Modelowanie oprogramowania w języku UML. Serdecznie pozdrawiam! 🙂

Narzędzia

Do modelowania w języku UML oczywiście jest programów. Ja miałem okazję skorzystać z programu Enterprise Architect, a do tworzenia diagramów dla MagazinManagera wykorzystam darmowe narzędzie UMLet. Po pierwszym użytkowaniu mogę stwierdzić, że bardzo przyjemnie się z niego korzysta. Prostota narzędzia nie zaciemnia obrazu podczas tworzenia diagramu.

O samym języku będziemy sobie opowiadać przy okazji kreowania kolejnych diagramów – najlepiej tłumaczyć na praktycznym przykładzie.

Modelowanie struktury obiektów/klas

Cechą paradygmatu obiektowego jest tworzenie oprogramowania zgodnego z naturalną, rzeczywistą strukturą zagadnienia. W świecie istnieją pojedyncze obiekty, byty, każdy z inną tożsamością, posiadające cechy oraz zdolności wykonywania pewnych czynności. Obiekty są konkretnymi egzemplarzami schematu zwanego klasą. Klasa definiuje zestaw cech oraz czynności, które obiekty będące egzemplarzami klasy posiadają. Dlatego w pierwszym kroku stworzę diagram z wykorzystaniem języka UML przedstawiający, jakie rzeczywiste klasy obiektów będę wykorzystywał w swoim oprogramowaniu.

Modelowanie funkcjonalności aplikacji

Następnym diagramem opisującym system jest diagram przypadków użycia. Ma on za zadanie zobrazować, jakie funkcje system ma dostarczać funkcje, ze względu na zdefiniowanych użytkowników. Użytkownika określamy mianem aktora.

Podsumowanie

W kilku zdaniach opisałem Ci, co będę robił w najbliższym czasie. W repozytorium projektu znajdują się dwa diagramy opisane powyżej. Przejrzyj je, zobacz, czy są one zrozumiałe. W następnym odcinku omówimy sobie ich budowę oraz porozmawiamy o kolejnych diagramach, które powstaną. Zachęcam do komentowania i wspólnej nauki! 🙂 Cześć! 🙂

Już wiem, co aplikacja ma robić!

Üdvözöljük! (węgierski)

Niedziela, piękna pogoda, więc kończymy posta i idziemy na spacer 🙂

Dzisiaj będzie króciutko, bez odkrywania świata. Bardziej to będzie wpis sprawozdawczy.

Co w specyfikacji piszczy?

Troszkę popracowałem, co może być stosunkowo mało widoczne, jeśli chodzi o objętość dokumentu, ale dużo posiedziałem, poczytałem i przemyślałem. Co z tego wynikło? Rozpisując się nad dodawaniem artykułów do bazy itd. przypomniałem sobie o CRUD. CRUD to skrótowiec wywodzący się od angielskich słów Create, Read, Update i Delete. Obojętnie czy to będzie całe czasopismo, kategoria lub artykuł, zawsze muszę mieć dostęp do tych czynności. Aplikacja będzie interfejsem pomiędzy zbiornikiem danych a użytkownikiem, więc wiele więcej funkcjonalności mieć nie będzie. Ponadto poza samymi funkcjonalnościami jak widzisz dokument zawiera parę innych rzeczy, które są związane z realizacją tych funkcjonalności.

Baza danych

Zdecydowałem się zastosować silnik mySQL rozwijany przez firmę Oracle z uwagi na szeroko dostępne narzędzia takie jak XAMPP czy WAMP, które każdy, kto kiedyś pisał cokolwiek związanego ze stronami internetowymi ma na komputerze. Ograniczy to konieczność stosowania przez szarego Kowalskiego dodatkowego silnika bazodanowego poza tym co ma.

Co dalej?

Kolejnym krokiem w projektowaniu aplikacji będzie jej zamodelowanie z wykorzystaniem języka UML. Trochę sobie porysujemy i porozmawiamy o tym co, jak i z czym. 🙂 W międzyczasie chcę w końcu zmodyfikować też sam wygląd bloga, aby był bardziej ludzki i dawał więcej funkcjonalności.

LaTeX

Powiedziałem kiedyś, że powiem wam w dwóch słowach o LaTeXu. Jest to język, który służy do składania dokumentów. W mojej opinii jest to taki Word dla programistów, bo tam cały wygląd dokumentu opisujemy odpowiednimi znacznikami. Dzięki LaTeXowi unikamy przykrego rozjechania się dokumentów przy przenoszeniu między różnymi wersjami oprogramowania biurowego, o przejściu Word — LibreOffice/OpenOffice nie wspominając. Kompilator wypluwa plik PDF niezależnie od tego, gdzie to kompilujemy. Odkąd nauczyłem się z tego korzystać, używanie pakietu biurowego dąży do zera. Zachęcam do zapoznania się z tym, kod macie u mnie w repozytorium (pliki z rozszerzeniem .tex). Na koniec posta załączę przykładowe linki z tutorialami itp.

Dobra to chyba wszystko na dzisiaj. Założyłem sobie 3 posty w tym tygodniu i cel spełniłem, z czego jestem dumny. W końcu udało mi się napisać krótszy post niż 800 czy 900 słów, co też jest może i małym sukcesem 🙂 W najbliższym czasie postaram się pisać częstsze i krótsze posty, zobaczymy, jak to rozwiązanie się sprawdzi 🙂

Miłego dnia!

Linki:

https://www.matematyka.pl/latex.htm

http://www.fuw.edu.pl/~kostecki/kurs_latexa.pdf

Kompilator mikTEX: https://miktex.org/

Środowisko TexMaker: http://www.xm1math.net/texmaker/

Zwinne testowanie

Welkom! (holenderski)

Witam Cię w poniedziałkowy wieczór znów na mojej stronie. Tak szybko kolejny wpis? Tak! Nadrabiamy zaległości, poza tym dzisiejszy temat jest kontynuacją wczorajszego, więc idę za ciosem. Dzisiejszy dzień jest bardzo ważny dla mnie z różnych powodów i zwieńczenie go wpisem, będzie wisienką na torcie. Może zastanawiasz się, co z projektem? Te posty są bezpośrednio z nim związane. Otóż jak pisałem, bodajże w opisie projektu na stronie konkursu, wybrałem stosunkowo prosty projekt po to, żeby móc pokazać troszkę wiedzy i poglądów na pewne tematy oraz nauczyć się nowych technologii na jakimś żywym przykładzie. Także w projekcie dzieje się cały czas! No ale już nie przedłużając, jedziemy z dzisiejszym tematem.

Dzisiaj chcę z Tobą, drogi czytelniku, pociągnąć temat zwinności i metodyk z nią związanych. Jeżeli widziałeś ten szkic specyfikacji, który powstał i leży sobie spokojnie na GitHub, to może zwróciłeś uwagę na końcowe zdanie. Do budowy aplikacji zostanie wykorzystana metodyka Test-Driven Development. Ale co to tak naprawdę jest?

TDD

TDD, czyli Test-Driven Development jest uważana za metodykę zwinną głównie ze względu na spełnienie manifestu: „Działające oprogramowanie ponad obszerną dokumentację”. Testowanie oprogramowania ogranicza (nie eliminuje!!!) występowanie błędów, a dobrze napisane testy mogą usprawnić dokumentowanie kodu, możemy potraktować je jako formę specyfikacji. Wróćmy do początku i zdefiniujmy sobie dokładnie hasło TDD. Za tym pojęciem kryje się cykliczne wykonywanie kilku kroków (za Wikipedią):

  1. Projektujemy test
  2. Implementujemy funkcjonalność
  3. Refaktoryzujemy kod

Brzmi to jednak bardzo pobieżnie i enigmatycznie, jednak kryje się za tym bardzo duża siła (czym jestem ostatnio zafascynowany i dlatego teraz, razem z Wami poznaję tę tematykę).

Co w trawie (TDD) piszczy?

Sednem TDD nie jest tak naprawdę pisanie oprogramowania niejako od tyłu, no bo w sumie po co i czemu tak, a w ogóle to te całe testy to nie wiadomo po co są, szkoda klawiatury. Pozwól jednak, że udowodnię Ci nieprawdziwość takiego podejścia!

Z definicji test jednostkowy ma przetestować pojedynczy element programu, jego zachowanie w różnych, mniej lub bardziej sprzyjających warunkach. Rozpoczynanie tworzenia aplikacji od zdefiniowania testów, które nawet się nie skompilują ze względu na brak reszty szkieletu zmusi do myślenia i wyciągnięcia z odchłani mózgu, co tak naprawdę chcemy uzyskać. Wychodzimy ze sztywnych więzów implementacyjnych na rzecz interfejsu i funkcjonalności, co w sumie jest zgodne z Agile (znów).

W kolejnym kroku następuje implementacja brakującego szkieletu (z tego co się orientuję to VS i Eclipse udostępniają automatyczne narzędzia, trzeba się będzie przekonać :), ponadto w tym kroku solucja się skompiluje ale uruchomienie wywoła test, które siłą rzeczy nie przejdą) i wypełnienie tego szkieletu logiką (o i działa :D). W tym miejscu zaczynają przechodzić testy. Przechodzimy zatem do punktu 3., czyli refaktoryzujemy kod. Ta wstępna implementacja jest pisana tak z marszu, po to, żeby testy przeszły. Osiągamy przez to jeden cel działającej funkcjonalności spełniającej nasze oczekiwania. Refaktoryzacja jest bardzo ważnym krokiem. Otóż kod powinien być sporządzony w taki sposób, aby testy zawsze kończyły się wynikiem pozytywnym, zatem refaktoryzacja kodu nie ma prawa wpływać na wynik testu. Jeżeli tak jest, to należy się zastanowić, czy sam test został sporządzony poprawnie (znaczyłoby to, że funkcjonalność jako taka nie została dobrze określona). W przeciwnym razie popełniliśmy błąd w przebudowie kodu i należy przeprowadzić ten proces jeszcze raz.

Refleksja

Czy warto jest stosować TDD? Tak! Jednak jak ze wszystkim musimy być rozważni. Już tłumaczę w czym rzecz. Takie podejście do stworzenia oprogramowania pozwala na minimalizację liczby błędów występujących w tworzonym oprogramowaniu. Nigdy nie jesteśmy w stanie wyeliminować ich w 100%, ale minimum jest zawsze najlepszą opcją 🙂 Ponadto testy stanowią dokumentację funkcjonalności dostarczanych przez pakiet oraz mają w sobie przykłady użycia – zatem bezsensowne staje się pisanie zewnętrznego manuala jako dokumentu, jeżeli śledząc kod testu możemy tego dotknąć na żywca.

Oczywiście też jest druga strona medalu. Testy są oczywiście kodem do utrzymywania – dla części osób może to stanowić poważny problem, bo jak wiemy programista to z natury leniwe coś. Samo podejście od tej strony nie jest łatwe, jednak wszystko się da. Materiałów jest cała masa, czy to właśnie podobnych dywagacji czy tutoriali. Pod postem coś tam podlinkujemy fajnego 🙂 To chyba tyle, pamiętaj też, drogi czytelniku, że to tylko narzędzie i trzeba z niego odpowiednio korzystać 🙂

Nie samym TDD człowiek żyje

To co, tak zachwalał i tłumaczył i teraz ucieka? Nic z tych rzeczy 🙂 Ale przy tak świetnej okazji trzeba wspomnieć o ewolucji narzędzia TDD, znanej jako Behavior-Driven Development, w skrócie BDD. Szukając w internecie informacji na ten temat przygotowując się do tworzenia tego posta, często spotkałem się ze stwierdzeniem, że BDD to TDD a TDD to BDD. W istocie rzeczywiście tak jest. Rozszerzenie BDD względem TDD polega na wykorzystywaniu narzędzi do definiowania funkcjonalności oraz przygotowywaniu tzw. user scenarios, które to opisują przebieg krok po kroku konkretnej funkcjonalności. Świetny przykład formowania user scenarios znajduje się pod tym linkiem. User scenarios zapisuje się np. za pomocą języka Gherkin, który współpracuje z narzędziami wspierającymi BDD, np. Cucumber, z którego ja będę korzystał, ale to już w kolejnym poście. BDD też można określić jako metodykę nie będącą tak bardzo restrykcyjną jak TDD. Jednak ta różnica jest jak mówiłem bardzo nikła. Wikipedia angielska mówi: „Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development.”. Myślę, że lepszej konkluzji się nie znajdzie 🙂

Podsumowanie

I tak o to po raz kolejny z wieczora zrobiła się już w sumie noc. Znów post zamiast krótkiego, będzie miał ok. 1000 słów. Mam nadzieję, że w takim telegraficznym skrócie opisałem Ci, co to jest TDD i BDD oraz dlaczego są one takie przyjemne. W kolejnym poście już popracujemy bezpośrednio nad aplikacją, ale musiałem zrobić ten wstęp, by zachować jakiś porządek logiczny 🙂 Mam nadzieję, że Ci się podobało! Zachęcam do komentowania i poprawiania mnie, jeżeli się mylę 🙂 Chciałem także podziękować mojemu koledze Michałowi, który podesłał mi parę linków i zainspirował do pogrzebania na ten temat 🙂 Dziękuję! 🙂 Tymczasem mówię Ci do zobaczenia, ale przewiń stronę dalej, by poklikać w przydatne linki 🙂 Miłego czytania! 🙂

Przydatne linki

TDD Wikipedia: https://pl.wikipedia.org/wiki/Test-driven_development

O testach na Devstyle.pl: http://devstyle.pl/category/tech/tests/

O TDD u Arkadiusza Benedykta: http://www.benedykt.net/2010/11/07/tdd-czyli-test-driven-development/

BDD Wikipedia: https://en.wikipedia.org/wiki/Behavior-driven_development

Narzędzie Cucumber: https://cucumber.io/

Inne:

http://softwareengineering.stackexchange.com/questions/135218/what-is-the-difference-between-writing-test-cases-for-bdd-and-tdd

http://softwareengineering.stackexchange.com/questions/111837/relation-between-bdd-and-tdd

MagazineManager – co on właściwie ma zrobić? Cz. 2

Hi!

Witaj w kolejnym wpisie dotyczącym rozwoju tworzonej aplikacji. W poprzedniej części rozważyliśmy model w jakim będziemy tworzyli oprogramowanie. Wybrałem model kaskadowy, który w przyszłości będzie można przekształcić w model spiralny. Umożliwi to w łatwy sposób dodawanie funkcjonalności. Teraz na potrzeby konkursu założymy sobie pewne wymagania i je po prostu zrealizujemy właśnie zgodnie z modelem kaskadowym. A już w przyszłości, poza konkursem, kiedy w trakcie korzystania z tej aplikacji czegoś mi zabraknie, to to dopiszę. Jednak z takim dopisywaniem funkcjonalności oraz modelem spiralnym wiąże się Agile czyli zbiór metod, założeń tzw. zwinnego wytwarzania oprogramowania oraz Scrum jako jedna z metody zgodnych z Agile. Temat rzeka, jednak już niebawem o tym także porozmawiamy.

Specyfikacja funkcjonalna – opis wymagań, które system ma spełnić

Kiedy klient przychodzi do firmy tworzącej oprogramowanie, ma ku temu jakieś tam powody. Potrzebuje narzędzi, które programiści są w stanie mu dostarczyć. Stawia przed nimi wymagania, mające zaspokoić jego potrzeby. Dlatego w pierwszym kroku klient siada z odpowiednim zespołem i razem opracowują dokument, zawierający funkcjonalności realizowane przez powstający system. To nie jest łatwe zadanie i zajmuje stosunkowo dużo czasu. Zespół musi wdrożyć się niejako w dziedzinę, dla której oprogramowanie jest tworzone po to, aby wyciągnąć co się da od klienta, bo dla niego pewne rzeczy mogą być oczywiste, jako „osobnika z branży”, zaś dla deweloperów już niekoniecznie. Poza tym często jest problem z samym sposobem opisu. Mówi się, że jeden obrazek może zastąpić 1000 słów i to naprawdę tak jest. Ponadto przecież ten sam cel można osiągnąć pokonując różne drogi prawda? Jest dużo takich rozbieżności, używanie różnych terminologii, jeżeli z systemu ma korzystać wiele użytkowników, to każdy z nich co innego by chciał od oprogramowania i tak można wymieniać w nieskończoność. Dlatego ten etap jest kluczowym w rozwoju oprogramowania, bo ewentualne błędy potem odbijają się czkawką przez długi czas.

Czy wymagania są tylko funkcjonalne?

Oczywiście, że nie. Wymagania funkcjonalne jest to tylko część całego systemu, o którym trzeba myśleć. Poza nimi są tzw. wymagania niefunkcjonalne, definiowane jako specyfikowalne z perspektywy czarnej skrzynki jako jakościowe cechy rozwiązania. Wymagania te określają, jakie ograniczenia są nakładane na system, np. spełnienie wymogów określonej normy, integracja z istniejącymi już systemami, które nie mogą być modyfikowane pod nasze rozwiązanie, sprzęt, na którym oprogramowanie będzie miało działać… Znów wymieniać można w nieskończoność i zdecydowanie jest to temat na kolejny odcinek tej serii. Chciałem tylko rzucić temat, może i Ty mi coś ciekawego podpowiesz? 🙂

Jak definiować wymagania?

Jak mówiłem wcześniej – TO NIE JEST TAKIE PROSTE ŻEBY ZDEFINIOWAĆ WYMAGANIA! Dlaczego? Część z tych cech wymieniłem już wcześniej: każdy ma swoją wizję na świat i produkt, który ma uzyskać widzi inaczej, ciężko opisać pewne „ficzery”. Dalej, nie są one oczywiste dla wszystkich a przy okazji mocno ze sobą powiązane. Istny misz masz. Dlatego przechodzimy w opisie wymagań od ogółu do szczegółu w kolejnych krokach:

Jakość opisu wymagań i cechy

Dlatego mówimy także o jakości sporządzonego opisu. Zastanówmy się więc, jakie cechy powinny mieć wymagania i opis, by rzeczywiście dało się coś z tego urzeźbić. Same wymagania przede wszystkim powinny być kompletne i dokładne. Mówiłem o tym wcześniej. Należy wycisnąć co się da z klienta, by rzeczywiście spełnić jego oczekiwania. Przy okazji należy pamiętać o tym, że wymagania muszą być realistyczne i osiągalne, ale tego chyba nie trzeba tłumaczyć. Dalej każde z wymagań powinno być opisane w sposób jasny oraz jednoznaczny – tutaj właśnie przydają się różnego rodzaju diagramy, które eliminują rozbieżności znaczeń języka naturalnego. Ostatnią cechą powinna być weryfikowalność stawianych wymagań. To pozwoli na uniknięcie nieprzyjemnych sytuacji typu nieuregulowanie płatności za pracę, bo produkt nie spełnia wymagań. To chyba tyle, może Ty masz jakiś pomysł?

Co zatem trzeba umieścić w dokumencie zbierający wymagania nałożone na system? Przede wszystkim należy zadbać o to, by dokument nie zaprzeczał sam w sobie w różnych jego częściach. Jeżeli tak jest, to błąd został popełniony na samym początku, przy procesie ich zbierania. Ponadto ma opisywać sposób pracy systemu, jego zachowania zewnętrzne, czy w przypadku niepożądanych lub skrajnych sytuacji. Sam dokument, który opisuje nie tylko funkcjonalności dostarczane przez system musi zawierać nakładane na oprogramowanie ograniczenia lub możliwości zmian/rozwoju aplikacji.

Dokumentacja

Oczywiście to co już zbierzemy, trzeba jakoś ładnie zebrać. W moim przypadku sporządzę dokument napisany w LaTeXu. Polecam się zapoznać z tym mega fajnym narzędziem! Odkąd zacząłem go używać, to Word służy mi jedynie do otwierania dokumentów w nim napisanych. Poza stworzeniem czegoś, co można wydrukować, są narzędzia, które pomagają podczas realizacji funkcjonalności przez programistów. Ale to znów tak obszerny temat, że powstanie o tym kolejny wpis na blogu 🙂 O tym podpowiedział mi mój kolega Michał, dzięki! Jak tylko to ogarnę sobie i będę w stanie Wam to przekazać, to na pewno to zrobię 🙂

MagazineManager – jakie są moje oczekiwania?

W końcu do sedna. Miało być krótko, a wyszło jak zwykle. Jest tyle rzeczy, którymi chce się z Wami podzielić, że wpisy się rozciągają, ale (przynajmniej mam taką nadzieję) mają przez to jakąś wartość dodaną, aniżeli tylko rozwój projektu. Zatem w kilku słowach opiszę, co chcę uzyskać, zaś mam nadzieję, że dzisiaj bądź jutro na GitHubie pojawią się pliki z dokumentacją.

Może od myślników będzie najczytelniej (to nie jest w żadnym porządku logicznym, po prostu co mi do głowy przychodzi na moment pisania tego posta):

I to chyba tyle jak na razie. Na pewno wszystko znajdziecie w dokumencie, który powstanie.

Tym czasem kończę, proszę o komentarze oraz udostępnianie mojego bloga! Dzięki temu będzie nas więcej! 🙂 Miłego dnia! 🙂

P. S. Postanowiłem bardzo spontanicznie, że będę się z Wami witał w różnych językach, tak dla frajdy 🙂

1 2