Prawdziwe projekty zwykle wiążą się z uczestnictwem co najmniej kilku osób. Racja bytu większej ilości osób, o dziwo, uzasadniona jest oszczędnościami ! Wynika to przede wszystkim ze świadomości o koszcie dochodzenia przez niedoświadczoną osobę do wykonania danej czynności i w dodatku w odpowiednim czasie. Innymi słowy, taką grupę tworzą z reguły osoby specjalizujące się w osobnych obszarach. Mogą to być analitycy, projektanci aplikacji, projektanci baz danych, programiści a czasami dodatkowe osoby zajmujące się czynnościami nie bezpośrednio związanymi z tworzonym systemem a na przykład kontrolą finansową przedsięwzięcia. Fakt istnienia tych osób nie powinien wprowadzać żadnego nieporozumienia. Używanie języka UML przez uczestników wprowadza spójny obraz obszaru analizy. Być może podam banalny przykład uwydatniający tą sytuację, ale czy z punktu widzenia właściciela firmy, projektanta aplikacji, projektanta bazy danych, programisty, osoba która uczestniczy w obiegu informacji np. księgująca wydatki firmy nie jest po prostu jednym i tym samym „aktorem” ? Dla prezesa- jest osobą zarządzającą fakturami, dla projektanta aplikacji- użytkownikiem systemu, dla projektanta bazy danych- obiektem bądź po prostu rekordem, programisty- pewnym bytem który zadaje szereg odwołań do systemu. Ten „wielo poziomowy” użytkownik jest tu jednoznacznie interpretowanym aktorem i każdy dokładnie wie jak zapisać jego symbol. To prawda, że ten przykład jest mało wybrany ale jedynie komunikuję że, tzw. artefakty jednoznacznie są rozumiane przez osoby myślące w różnym kontekście. Oczywiście, to jedynie wierzchołek zagadnienia ale o tym jak projektant bazy danych traktuje te informacje na swój użytek, opiszę w dalszej części artykułu. Jaki jest cel tworzenia oprogramowania ? Odpowiedź wydaje się dosyć prosta - utrwalamy w ten sposób zrozumiane i zoptymalizowane zagadnienia biznesowe. Dlatego właśnie, ten punkt jest taki ważny aby zrozumieć i zoptymalizować zagadnienia biznesowe. Czym są takie zagadnienia ? Otóż czasami nie wystarcza wcielenie się w rolę takiego systemu informatycznego, który nakładamy na dany system informacyjny, często jest to niemożliwe a nawet niepożądane. To jest cała trudność, aby świadomie rozrysować obieg informacji, z uwzględnieniem ich konsekwencji nie tylko w wymiarze struktury oprogramowania, a przede wszystkim jej odpowiedzi w świecie rzeczywistym. To prawda że UML jest tylko językiem i można go skutecznie stosować w pewnej metodologii, ale cel tworzenia poszczególnych diagramów i w ogóle ich istnienia wpływa po części na sposób pozyskiwania informacji czego konsekwencją są właściwe dane. Reasumując, pozyskane dane optymalizowane są pod kątem oprogramowania, ale w głównej mierze dla zwiększenia wydajności procesów biznesowych w świecie rzeczywistym. Ogromne straty może ponieść zleceniodawca aplikacji kiedy my projektanci a zarazem twórcy, oprogramowania źle zrozumiemy potrzeby. Inżynierowie oprogramowania wiedzą, że ”błędy popełnione podczas projektu są najkosztowniejsze do usunięcia”.

Obecnie, przyjmuje się jako najbardziej optymalny sposób wytwarzania aplikacji równoległą pracę poszczególnych zespołów nad ich obszarem działania a w konsekwencji całą aplikacją. Co to znaczy ? Dla mnie projektanta oznacza że już pierwsze słowa, które usłyszę podczas pierwszych etapów projektu, mogą mieć odzwierciedlenie w bazie danych. Zaletą tego sposobu jest fakt, że występuje równoległe pozyskiwanie informacji przez wszystkich uczestników projektu, ale dodatkowo każdy z nich może wpłynąć już na samym początku na przebieg wydarzeń a docelowo na kształt systemu. W przypadku projektanta bazy danych to świetna możliwość, gdyż analityk nie zastanawia się nad odzwierciedleniem obszaru analizy w bazie danych. Patrzy jedynie na pewną sekwencję kroków w procesie biznesowym, innymi słowy na pewnym znacznie wyższym poziomie abstrakcji niż znajduje się sama baza danych. I stąd też, osoby myślące w jednym czasie o implementacji obszaru rozważań mogą korzystnie wpłynąć na etap analizy. I oczywiście, nie było by to wszystko możliwe bez sprawnej komunikacji o której pisałem wcześniej. Dlatego też, wspólna notacja jest niezbędna przy sprawnej wymianie danych. Można pomyśleć w tym kontekście o UML jako pewnego rodzaju pomostu pomiędzy wyspecjalizowanymi zespołami. Wtedy, gdy analitycy i poszczególni członkowie decydujący dokonują modelowania procesów biznesowych w UML, osoby pełniące inną rolę spójnie wraz z autorami procesów biznesowych postrzegają poszczególne artefakty. Elementarną kwestią jest zrozumienie definicji słowa „projektowanie”, którego znaczenie ja traktuję w tej pracy jako prekursora wszystkich czynności. Projektowanie, w tym rozumieniu to coś więcej niż „modelowanie”, które tak często się stosuje. Modelując zastanawialiśmy się w zasadzie tylko nad modelem logicznym i fizycznym, gdzie poprzez encje, tabele dokonywaliśmy normalizacji dla zapewnienia poprawności modelu. Czynności związane z projektowaniem obejmują znaczenie słowa modelowania, ale dodatkowo rozumie się tu całą pracę towarzyszącą, począwszy od uświadomienia sobie potrzeb poprzez analizowanie procesów biznesowych a kończąc na kompletnym projekcie fizycznym, który zawiera cały układ systemu bazodanowego wliczając chociażby sprzęt. W tym akapicie chciałbym przywołać esencje spornej kwestii podczas realizacji wielu projektów a zarazem recepcie która zaradza temu problemowi. Wiadomo, że tworzenie jakiegokolwiek systemu wiąże się przeważnie z wybraniem jednej z dwóch ścieżek. Pierwsza związana jest z mocnym trzymaniem się planu wyznaczonego przez daną metodologię, na marginesie mówiąc wyróżniamy ich wiele. Druga to swobodniejsze podejście gdzie na zasadzie pewnych heurystycznych wskazówek dokonywane są pewne wybory a co za tym idzie, pomija się pewne kroki. Pierwszy sposób wydaje się najpewniejszy gdzie, poprzez sekwencje wykonywanych czynności dążymy do celu. Ale konsekwencją tego jest, iż cały zespół, gdzie wyróżniliśmy ludzi biznesu, analityków, projektantów, programistów drąży te wszystkie nie powiązane bezpośrednio z ich rolą w zespole zadania. Zaletą tego podejścia jest oczywiście fakt, że te wszystkie osoby na bieżąco otrzymują ten sam zestaw danych, co niewątpliwie przyczynia się do zrozumienia. Ale ile to wymaga czasu i ile sumarycznie włożonej energii ? Można powiedzieć, że te rozwiązanie niekoniecznie pozytywnie jest odbierane przez wszystkich, co nawet z punktu teoretycznego ma pewne negatywy, gdzie np. w świetle wydajności poszczególnych jednostek, analityk mogąc rozważać swoje kwestie zajmuje się opracowywaniem wszystkich etapów projektu. Drugie rozwiązanie gdzie dokonuje się, chociażby pewnych przeskoków pomiędzy etapami, w praktyce często wypada dużo lepiej, ale również ma wiele wad. Często bywa że pewien „przeskoczony” etap stanowi ogniwo, które dla pewnych członków zespołu jest kluczowe do rozważenia. Reasumując, pewien zespół w potrzebie dla swoich tematów pomija pewien krok, z którego wynikać może racja postępowania innego zespołu. Ta mocna cecha, wspólnych w pierwszym podejściu artefaktów tu zanika, czego konsekwencją jest oczywiście niezrozumienie uczestników. UML zaadoptowany przez odpowiednie narzędzie jest tu niezastąpiony. Poszczególne zespoły pracując nad interesującym ich obszarem wpływają na kształt obszaru niebezpośrednio ich interesującego, czego konsekwencją jest równoległe wprowadzanie zmian w całym projekcie. Kolejną zaletą jest oczywiście skuteczne i jednoznaczne powiadamianie wszystkich uczestników projektu, o dokonywanych zmianach. Szeroko rozumiane pojęcie spójności danych zasługuje na dodatkowe wyróżnienie. Co to oznacza ? Przede wszystkim, wiadomo że wszystkie wspomniane czynności, do których używamy diagramów dotyczą tego samego obszaru analizy, ale również te same diagramy są odpowiedzią na pytania członków różnie wyspecjalizowanych zespołów. Pewnemu okresowi w tego rodzaju projektach towarzyszyła idea że baza danych jest kręgosłupem i że cała reszta jest do niej dostosowana. Podejście takie nieco się różni, gdyż wszystkie informacje wywnioskowane z diagramów docelowo mają równe znaczenie. Informacje np. potrzebne do stworzenia interfejsów wpływają na strukturę bazy danych, co wprowadza pewne ścisłe powiązanie a zarazem elastyczność całego projektu. Wiadomo że każdy projekt bazy opiera o trzy podstawowe obszary działań. Poniżej znajduje się rysunek, który obrazuje plan działań, według którego powstać może projekt bazy danych zgodny z profilem UML dla tego celu. 

 Schemat ideologiczny procesu projektowania bazy danych w UML.

Powyższy rysunek jest połączeniem elementarnych i zwyczajowo występujących osobno pojęć ze świata baz danych i inżynierii oprogramowania. Pierwszy zbiór dotyczy modelowania konceptualnego gdzie poprzez szczegółową analizę procesów biznesowych powstanie model ideologiczny biznesowych celów. Obszar drugi zwany modelowaniem logicznym jest znacznie bliżej implementacji poprzez zdefiniowanie przypadków użycia od systemu informatycznego. Szereg diagramów wyznaczy skutecznie, poprawną strukturę bazy danych. Ostatni to modelowanie fizyczne gdzie powstanie implementacja bazy danych oraz jej szczegółowe towarzyszące kwestie, choćby takie jak sprzęt.