W poprzednim temacie omówione zostały podstawowe zagadnienia i klasyczne zadania z algorytmów zapisywanych schematami blokowymi. Niniejszy temat traktuje o zaawansowanych zagadnieniach przedstawianych za pomocą schematów blokowych
Biblioteka Miejska
Omówimy ten temat na przykładzie zagadnienia programu obsługi biblioteki miejskiej. Tematyka ta już intuicyjnie wydaje się być zaawansowana na tyle, że można się „pogubić” w tym co należy stworzyć. Tutaj ratunkiem są właśnie schematy blokowe, która umożliwiają „opanowanie” zagadnienia i zajęcie się nim w sposób gwarantujący zakończenie sukcesem.
Temat Biblioteki to zgodnie z naszym wyobrażeniem projekcja miejsca w którym przechowywane są książki, na różnych półkach, w różnych kategoriach. Książki, które trzeba przyjąć, skatalogować, umieścić w odpowiedniej kategorii. Książki, które można wypożyczyć i zwrócić. Książki, które trzeba skasować z uwagi na ich zniszczenie. Książki, które są dostępne tylko w czytelni. Skoro książki to i czytelnicy, którzy mogą je wypożyczać, zwracać. Skoro czytelnicy to i czas na jaki mogą zabrać książki ze sobą i koszty jakie ponoszą związane z ich przetrzymaniem.
Jak zrobić taki schemat blokowy?! Wpierw trzeba się zastanowić co będzie korzeniem naszej biblioteki, czy jeden element, czy też będzie ich więcej wzrastających już nie w jedno drzewo, ale w las ze wzajemnymi powiązaniami (relacjami)?! Następnie trzeba nakreślić schemat funkcjonalny traktujący o spodziewanych funkcjach oraz schemat programistyczny traktujący o sposobie realizacji poszczególnych procedur w schemacie funkcjonalnym. Dopiero, po trzecie, teraz można dokonać delegacji zadań dzieląc się nimi, by nie wykonywać wszystkiego od razu i tym samym dając sobie szansę na wykonanie całości i stworzenie działającego poprawnie systemu.
Powyżej zaprezentowany jest schemat funkcjonalny spodziewanego systemu obsługi Biblioteki Miejskiej. W blokach odzwierciedlających odniesienia do podmiotów obsługiwanych w systemie umieszczone są wymagane atrybuty. Bloki połączone są liniami relacji. Teraz cały projekt ubrany w formę wizualną może być poddany ewaluacji celem naniesienia poprawek, dopisania lub skreślenia zbędnych atrybutów, czy uzupełnienie lub skreślenie ze schematu niepotrzebnych bloków. Czy wobec powyższego konieczna jest jakaś zmiana w ww. schemacie blokowym??
Analizując taki schemat można wychwycić błędy w naszym rozumowaniu i uprościć schemat, co oczywiście przeniesie się na uproszczenie struktur tworzonego oprogramowania. Także i tutaj można zauważyć, że „nasz” pomysł z tworzeniem oddzielnego bloku Lokalizacja jest w zasadzie zbędny. Odnosi się on do informacji o chwilowej lokalizacji książki w fizycznym środowisku, tak więc oddzielanie tego od opisu książki może być niepotrzebne (chyba, że chcemy rejestrować wszystkie zmiany lokalizacji książki w jej „życiu” w systemie bibliotecznym). Można więc nasz schemat uprościć do następującego:
Grupę Lokalizacja zawierającą informacje o fizycznym miejscu przechowywania książki przenieśliśmy do grupy Książka. Na ten czas nazywamy te obiekty grupami. Jednakże w dalszym procesie będą one nazywane klasami1Klasa jest zbiorem atrybutów i metod powiązanych ze sobą wzajemnymi zależnościami, pracujących na wspólnych atrybutach i zazwyczaj, w zamyśle programisty, zawiera funkcjonalności służące obsłudze konkretnego tematu. Hermetyzacja tych metod i atrybutów w klasie ma za zadanie utworzenia definicji deklaracji niezbędnych zasobów i metod dla obsługi tego tematu oraz dzięki temu dekompozycji programu na poszczególne bloki składowe. Wybitnie wpływa to na przejrzystość kodu i pozwala szybko kierować się do odpowiednich podprocedur celem dokonywania ich modyfikacji, rozwoju czy naprawy. Także i w tym przypadku widać, że zachowaliśmy w grupie (klasie) Książka przeniesiony do jego wnętrza grupę (klasę) Lokalizacja aby widoczna była relacja i funkcjonalność tego fragmentu. Wynika z tego, że klasy mogą w swej definicji zawierać inne klasy. Co więcej w dalszych rozważaniach można napomknąć, że w celu rozwoju konkretnej klasy może być użyty mechanizm dziedziczenia2Tworzenie klas potomnych z wykorzystaniem klasy macierzystej – podstawowa technika programowania obiektowego szerzej będzie omówiona w późniejszych tematach., by nie wprowadzać zmian w już przygotowanej klasie, a jedynie poprzez dziedziczenie stworzyć nową rozbudowaną o dodatkowe mechanizmy (metody) i atrybuty. Wszystko to upraszcza wizualizację całości systemu i pozwala na szybsze orientowanie się w zakresie funkcjonalności systemu.
Takie rozpisanie funkcjonalności na bloki pozwala zauważyć, że to nie książka, a czytelnik jest punktem centralnym systemu. Wszystko skupia się na nim, koncentruje się funkcjonalnie tak, że książka okazuje się jedynie złożonym atrybutem, a nie podmiotem.
Teraz nadszedł czas aby przygotować diagramy schematów programistycznych. Są one niezbędne aby określić jakich funkcjonalności (metod) potrzebujemy na poziomie klas. Takie przykładowe diagramy mogą wyglądać jak poniżej:
Takie przedstawienie pozwala na przygotowanie się do tworzenia kodu, wizualizuje potrzeby, porządkuje je i hierarchizuje. Powiązanie logiczne (funkcjonalne) systemu z analizą programistyczną jego części składowych pozwala przygotować plan prac związanych z jego stworzeniem. Nie wyczerpuje to tematyki, ale zamysłem niniejszego tematu była jedynie chęć sygnalizacji tematyki i jej stosunkowe przybliżenie… Tematyka ta rozwijana jest w innych modułach jak na przykład w Biznesowym Podejściu do Produkcji Gier.
Zadania do samodzielnego wykonania: Wzorując się na powyższym zagadnieniu spróbuj opisać tematykę zarządzania przedsiębiorstwem spedycyjnym (takim jak np. DHL, czy FedEx). Stwórz niezbędne schematy blokowe (funkcjonalne i programistyczne) programu w Diagram Designer’ze, a wyniki w postaci raportu PDF z oraz opisem działania załącz w Moodle.