Posty z kategorii: Projektowanie

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 🙂

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

Cześć!

Witam Cię, w środowy dzień. Jest to jeden z dwóch postów, które powstaną w tym tygodniu. Czas się zabrać za naszą aplikację.

Od czego by tu zacząć? Może siądziemy od razu do kodu? Nic z tych rzeczy.

Oczywiście są różne podejścia do tworzenia aplikacji. Działka, która się tym zajmuje nazywa się Inżynierią Oprogramowania. Jest to bardzo, bardzo ciekawa nauka z dziedziny informatyki, która zajmuje się wszystkimi fazami cyklu życia oprogramowania. Samo pisanie kodu, to tylko fragment tego cyklu (tak, część z Was, która programowanie miała w szkole/na studiach etc. jako tylko przedmiot jeden z wielu, pewnie się zdziwi, a ludzie, którzy trochę bardziej zawodowo zajmują się oprogramowaniem wiedzą to doskonale i wiedzą również, jak życie weryfikuje założenia, o czym będzie kiedy indziej). Oprogramowanie jest produktem takim samym jak… nie wiem, masło, samochód czy krzesło. (Co to za herezje!) Ma spełniać określone potrzeby techniczne, społeczne i ekonomiczne, dlatego ważnym jest, by zaplanować to, jakie funkcjonalności ma dostarczać, do czego ma służyć, z jakich komponentów będzie zbudowane itd. itd. Ważne też jest, że nauka ta powstaje niejako od tyłu, tzn. nie siada sobie grupka ludzi i mówi dzisiaj sobie coś wymyślimy, tylko stanowi esencję najlepszych i najbardziej efektywnych praktyk stosowanych podczas aktualnie rozwijanych przedsięwzięć informatycznych. Podejście od teorii do praktyki w tym przypadku całkowicie spaliło na panewce.

Zatem zagłębiając się w ten temat możemy uniknąć popełniania błędów przy tworzeniu własnych rozwiązań, tak naprawdę nie tylko z branży IT, bo wiele z tych praktyk da się przetransformować na inne zawody lub dziedziny życia.

Czy skoro jest to takie idealne, to nasze oprogramowanie będzie bezbłędne? Oczywiście, że nie. Tak po prostu się nie da. Ale da się zminimalizować ich wystąpienia. Da się zoptymalizować sam proces wytwarzania oprogramowania. Czy to dużo, czy mało? Fajnie jest o tym pomyśleć.

Skoro inżynieria oprogramowania rozrosła się tak bardzo, to z jakich jej dobrodziejstw ja skorzystam podczas tworzenia MagazineManager’a? Przede wszystkim zastosuję coś, co zwie się modelem wodospadowym lub kaskadowym  wytwarzania oprogramowania. Model ten, dzieli się na fazy takie jak:

  1. Faza określenia wymagań – to jest to, co będziemy robić już następnym razem, tzn. wytworzymy sobie dokument zawierający informację na temat celi jakie chcemy poprzez ten projekt osiągnąć oraz wymagań, jakie postawię przed tworzonym oprogramowaniem.
  2. Faza projektowania – bardzo szczegółowo określimy strukturę wewnętrzną systemu.
  3. Faza implementacji – coś co tygryski lubią najbardziej, czyli w końcu posiedzimy przy kodzie!
  4. Faza testowania – co tu dużo komentować, jak się coś zrobiło no to trzeba zrobić rozruch systemu i zobaczyć czy działa.
  5. Faza konserwacji – ta faza trwa chyba najdłużej, tzn. poprawiamy to, co przestało działać kiedy produkt poszedł do klienta.

Niby takie proste, jasne i logiczne, ale ile razy każdy z nas wpadł w takie sidła, że usiadł, zrobił coś tak od strzału i nagle na koniec nie działa/działa tragicznie/nie spełnia wymagań/jest tak źle zrobione, że nie da się tego w prosty sposób poprawić czy rozwinąć (niepotrzebne skreślić).

Wadami tego systemu jest to, iż błędy popełnione w pierwszych fazach, silnie oddziałują na kolejne etapy rozwoju, przez co ich poprawianie może być drogie (jeżeli mówimy o komercyjnych projektach). Zaletą przede wszystkim łatwość monitorowania tego procesu. Głównie model ten wykorzystywany jest w projektach, które są bardzo ważne i rzadko zmieniają się zachcianki klienta.

Ciekawostką jest też to, że zapętlając punkty 1. do 4. otrzymujemy model spiralny, też często używany. Łatwo buduje się w ten sposób nowe wersje systemu, dodaje kolejne funkcjonalności. Klient ma większy wpływ na bieżący rozwój oprogramowania, przez co zmiana zdania czy wykrycie błędu jest zdecydowanie tańsze. Poza tym pozwala na dopracowywanie projektu. Znaczenie poszczególnych faz jest nieco inne, ale to raczej temat na inny post. Gdzie na przykład stosowany jest tego typu metoda? Hmm… A którą teraz mamy wersję Volkswagena Golfa? VII czy VIII? 🙂

Ktoś może zadać pytanie, czy to projektowanie rzeczywiście jest tak ważne? TAK! Powszechnie twierdzi się, że sama faza projektowania powinna zabierać ok. 70% a nawet 80% czasu rozwoju całego projektu. Lepiej przemyśleć coś 1001 razy niż o raz za mało.

Dobra czas kończyć chyba to pisanie. Tak będzie wyglądał początek zabawy z MagazineManager’em i w sumie z Daj się poznać 🙂 Może wydawać się to nudne, jednak mam nadzieję pokazać wam, jak bardzo takie rzeczy są potrzebne! Osoby bardziej doświadczone, mogą się podzielić własnymi doświadczeniami czy wiedzą!

Zachęcam gorąco do zagłębienia się w temat inżynierii oprogramowania, myślę, że wiele osób świetnie się tu odnajdzie i wyniesie dużo ciekawych wniosków.