Modelowanie systemów informatycznych w języku UML 2.1 - ebook

O Autorach

Dr inż. Włodzimierz Dąbrowski pracuje na stanowisku adiunkta na Wydziale Elektrycznym Politechniki Warszawskiej i w Katedrze Inżynierii Oprogramowania Polsko-Japońskiej Wyższej Szkoły Technik Komputerowych. Jest ekspertem w dziedzinie zarządzania projektami informatycznymi i projektowania systemów informacyjnych klasy biznesowej oraz twórcą i moderatorem szkoleń na odległość (e-learning), m.in. anglojęzycznego kursu Software Engineering i kursu Zarządzanie Projektami Informatycznymi. Jest też autorem i współautorem artykułów i publikacji książkowych z zakresu informatyki, pięciu podręczników akademickich oraz członkiem komitetów programowych kilku konferencji informatycznych, członkiem IEEE oraz SEP.

Dr inż. Andrzej Stasiak jest specjalistą w dziedzinie projektowania systemów czasu rzeczywistego, w szczególności zautomatyzowanych systemów dowodzenia (od kilku lat członek komitetu programowego Krajowej Konferencji Inżynierii Oprogramowania). Od 1987 r., jako absolwent i pracownik Wydziału Cybernetyki Wojskowej Akademii Technicznej, prowadzi działalność dydaktyczną i naukowo-badawczą. Doświadczenie zawodowe zyskał, biorąc udział w realizacji wielu złożonych projektów informatycznych.

Michał Wolski jest asystentem w Instytucie Informatyki Akademii Podlaskiej w Siedlcach, gdzie w ramach pracy naukowo-dydaktycznej zajmuje się procesami wytwarzania oprogramowania. Jego obszary zainteresowań badawczych dotyczą także metryk zaufania w otwartym środowisku mobilnych agentów. Opublikował szereg artykułów dotyczących inżynierii oprogramowania oraz brał udział w kilku projektach informatycznych.1. Wprowadzenie

Drogi Czytelniku. Książka, którą trzymasz w ręku, poświęcona jest trudnemu i fascynującemu zarazem zagadnieniu, jakim jest budowanie systemów informatycznych. Zagadnienie to jest bardzo rozległe i nie sposób opisać je w jednej książce. Nasza propozycja koncentruje się na modelowaniu systemów z wykorzystaniem podejścia obiektowego i języka UML w wersji 2.1. Omawia ona metody i narzędzia języka UML w zastosowaniu do modelowania systemów informatycznych. Uwzględnia nieomawiane szczegółowo w literaturze polskiej, praktyczne wykorzystanie języka UML w modelowaniu biznesowym, systemach czasu rzeczywistego, webowych oraz bazach danych. Jej zasadniczą zaletą jest duża liczba przykładów, które powstały na podstawie wieloletniej praktyki autorów w szkoleniach z tego zakresu i kierowaniu dużymi przedsięwzięciami informatycznymi.

Zgromadzona wiedza najlepszych i najgorszych praktyk oraz często popełnianych przez projektantów błędów pozwoliła na zbudowanie unikatowego repozytorium obszernej wiedzy z zakresu modelowania za pomocą języka UML.

Największą zaletą proponowanej książki jest skoncentrowanie się autorów na praktycznych aspektach wykorzystania języka UML 2.1 i pokazaniu zastosowania tego języka w wielu różnych dziedzinach, od projektowania systemów czasu rzeczywistego poprzez projektowanie bazy danych aż po modelowanie systemów biznesowych. Dzięki takiemu podejściu Czytelnicy specjalizujący się w różnych dziedzinach problemowych i studenci różnych kierunków studiów będą mogli znaleźć w niej potrzebną im wiedzę.

Książka skierowana jest przede wszystkim do studentów kierunków informatycznych oraz kierunków ekonomicznych i zarządzania mających w programie modelowanie biznesowe i modelowanie wymagań oraz do projektantów systemów biznesowych i informatycznych.

Mamy nadzieję, że dzięki różnorodnemu i wieloletniemu doświadczeniu autorów, którzy prowadzą zajęcia z projektowania systemów w języku UML na największych warszawskich uczelniach państwowych i prywatnych na różnych poziomach kształcenia (studia inżynierskie, magisterskie, podyplomowe, MBA, kursy doszkalające), udało się stworzyć pozycję pomocną dla wszystkich zainteresowanych budową systemów informatycznych.

Autorzy pragną także podziękować studentom i słuchaczom kursów, z którymi prowadzili liczne dyskusje na temat poruszanych w książce zagadnień. Dyskusje te przyczyniły się do nadania ostatecznego kształtu wielu rozdziałom i pozwoliły nam na

uniknięcie wielu błędów. W szczególności chcielibyśmy podziękować Mariuszowi Godlewskiemu i Grzegorzowi Chuchro, których pomysły i niektóre diagramy zostały zaprezentowane w rozdziale poświęconym bazom danych, oraz Robertowi Budnerowi za ostateczny kształt modelu automatu do wydawania napojów.

Autorzy

Włodzimierz Dąbrowski (kontakt: [email protected])

Andrzej Stasiak (kontakt: [email protected])

Michał Wolski ([email protected])2. Modelowanie – cele i metody

2.1. Przegląd rozdziału

2.1.1. Czego dotyczy ten rozdział?

Modelowanie jest nieodłącznym elementem pracy projektanta bez względu na dziedzinę, którą się zajmuje. Modele mogą być budowane w różnych celach i przy użyciu różnych narzędzi, mieć różny stopień skomplikowania i przydatności. Dlatego zawsze warto zastanowić się, po co i dla kogo budujemy model.

Rozdział ten poświęcony jest wprowadzeniu w tematykę modelowania systemów i sposobów ich budowy.

2.1.2. Co powinieneś wiedzieć, aby zrozumieć?

Ten rozdział w zasadzie nie wymaga od Czytelnika żadnej wiedzy bazowej. Wystarczą nam tutaj odwołania do ogólnej wiedzy i doświadczenia Czytelnika, wyniesionych na przykład ze szkoły średniej.

2.1.3. Jakie najważniejsze problemy rozwiążemy w tym rozdziale?

Z pojęciem modelu spotykamy się od najmłodszych lat. W większości wypadków w czasie posługiwania się modelem nie zdajemy sobie sprawy z jego budowy, doboru, poziomu abstrakcji itd. Po prostu korzystamy z niego. Dzieje się tak do momentu, kiedy nie staniemy się wymagającymi, w pełni świadomymi użytkownikami modelu (np. inżynierem elektrykiem, który musi wykonać instalację elektryczną na podstawie schematu instalacji elektrycznej) lub jego twórcami.

Najważniejszym więc problemem, który chcemy poruszyć w tym rozdziale, jest problem właściwego doboru modelu do potrzeb jego użytkownika.

2.1.4. Czego dowiesz się po jego przeczytaniu?

Po przeczytaniu tego rozdziału Czytelnik dowie się, czym jest model, w szczególności model systemu informatycznego. Postaramy się też znaleźć odpowiedzi na pytania, czym jest, a czym nie jest model systemu oraz jakimi cechami powinien charakteryzować się dobry i funkcjonalny model.

Po zapoznaniu się z treścią tego rozdziału Czytelnik powinien umieć rozpoznać dobry model i dobrać właściwy model do swoich celów.

2.1.5. Dlaczego warto przeczytać ten rozdział?

Mimo że modele otaczają nas w naszej pracy i w życiu codziennym na każdym kroku, często nie zdajemy sobie sprawy, jak dobrać model najwłaściwszy do naszych potrzeb. Niewątpliwie warto jest uświadomić sobie, czym jest model i jakie cechy powinien posiadać. Bez tej wiedzy trudno będzie poruszać się projektantowi systemów informatycznych, trudno też będzie w pełni skorzystać z informacji zawartych w dalszych rozdziałach naszej książki.

2.2. Czym jest, a czym nie jest model systemu?

Jak już wspomnieliśmy na początku tego rozdziału, modele są wszechobecne w naszym życiu prywatnym i zawodowym. Jednym z najlepszych przykładów modelu jest mapa terenu. Jesteśmy pewni, że każdy Czytelnik choć raz w życiu znalazł się w nieznanym miejscu i musiał skorzystać z mapy. Mapa jest właśnie przykładem modelu terenu. Oczywiście mamy do dyspozycji różne mapy. Na przykład w metrze mapa jest bardzo schematyczna i nie odzwierciedla takich szczegółów, jak rzeczywiste odległości między stacjami czy układ przestrzenny ulic. Biada więc komuś, kto chciałby na podstawie takiej mapy szacować czas spaceru między różnymi stacjami, gdyż może okazać się, że rzeczywista odległość między stacją A a stacją B jest trzykrotnie większa niż odległość między stacją B a stacją C, mimo że na mapie odległości te wyglądają na jednakowe. Czy takie odstępstwo modelu od rzeczywistości to zaleta, czy wada tego modelu? Na to pytanie postaramy się odpowiedzieć w dalszej części rozdziału.

Przykładem prostego i łatwego w odbiorze modelu może być też plan pomieszczeń. Jak wiadomo, planując urządzenie mieszkania czy biura, staramy się rozrysować na planie układ pomieszczenia i rozstawienie mebli. Ułatwia to nam zakup i wykonanie mebli. Przykład modelu przedstawiającego plan pomieszczenia biurowego przedstawia rysunek 2.1.

Inny przykład modelu pokazuje rysunek 2.2. Jest na nim zaprezentowany model prowadzonych ze studentami zajęć na temat komunikacji w projekcie. Do przedstawienia tego modelu wykorzystano tak zwaną technikę map pamięci wprowadzoną po raz pierwszy przez Tony’ego Buzana. Mapę taką czyta się w sposób nieliniowy, poruszając się tak jak na planszy zegara – startując od godziny dwunastej i przesuwając się zgodnie z ruchem wskazówek zegara. Na modelu tym umieszczono szereg informacji na temat poruszanych zagadnień (z uwzględnieniem hierarchii zadań), czasu przeznaczonego na poszczególne elementy, dodatkowych materiałów, formy prowadzonych zajęć (np. kolor zielony oznacza pracę samodzielną słuchaczy) itd. Choć model ten jest dość prosty, do jego odczytania potrzebna jest już elementarna wiedza o technice map pamięci oraz o zastosowanych w modelu symbolach. Mimo to

model taki może być odczytany również przez osobę z niewielką znajomością zastosowanej notacji i doświadczenia w budowie map pamięci.

Rysunek 2.1. Model zagospodarowania pomieszczenia biurowego

Rysunek 2.2. Model warsztatu zapisany za pomocą mapy myśli

Istnieją jednak modele, które wymagają do ich odczytania i zrozumienia większej wiedzy i wysiłku. Takie modele pojawiają się często w fizyce, matematyce, chemii, ekonomii, naukach technicznych i wielu innych. Jako przykład może posłużyć model przedstawiony na rysunku 2.3. Jest to model układu dynamicznego o m wejściach i p wyjściach.

Rysunek 2.3. Schematyczny model układu dynamicznego

Model układu dynamicznego w teorii sterowania i systemów przedstawia się zazwyczaj w postaci zależności (1) zwanej transmitancją operatorową lub w postaci

(1)

układu równań (2) zwanych równaniami stanu.

(2)

Zarówno schematyczny model z rysunku 2.3, jak i model w postaci transmitancji czy w postaci równań stanu mogą dotyczyć tego samego rzeczywistego obiektu – na przykład silnika elektrycznego czy wielkiego generatora w elektrowni.

Fakt, że te modele mogą opisywać ten sam rzeczywisty obiekt, jest dla nas bardzo ważny i posłuży nam do dalszych rozważań na temat tego, czym jest i jaki powinien być model.

Na rysunkach 2.4 i 2.5 są natomiast przedstawione modele cyklów wytwórczych oprogramowania. Na rysunku 2.4 przedstawiono schematycznie model kaskadowy cyklu wytwórczego oprogramowania, a na rysunku 2.5 model spiralny.

Jak widać modele, z którymi mamy do czynienia w życiu, mogą być bardzo różne, ukazując różne szczegóły, o zróżnicowanym stopniu złożoności. Jedne z nich wymagają dużej wiedzy i doświadczenia, aby móc z nich skorzystać – inne natomiast są stosunkowo łatwe w odbiorze i nie wymagają specjalnego przygotowania, aby je zrozumieć.

Więcej różnorodnych modeli Czytelnik może znaleźć w książce oraz , które krótko omawiamy w przeglądzie literatury do tego rozdziału.

Rysunek 2.4. Model kaskadowy cyklu wytwarzania oprogramowania

Rysunek 2.5. Model spiralny cyklu wytwarzania oprogramowania

2.2.1. Czym jest model systemu?

Najogólniej można odpowiedzieć na to pytanie, że model jest uproszczeniem rzeczywistości. Przedstawia on wybrane cechy lub zasady działania jakiegoś obiektu lub zjawiska.

Warto zwrócić uwagę, że model nie jest dokładną kopią modelowanego obiektu czy systemu. Nie istnieje więc odwzorowanie wzajemnie jednoznaczne modelu na modelowany system. W wypadku dokładnego powielenia obiektu, systemu czy zjawiska mamy do czynienia z jego kopią, a nie z jego modelem.

2.3. Po co budować modele?

Zastanówmy się teraz, w jakim celu budujemy modele.

Jest to bardzo istotne pytanie. Od odpowiedzi na nie zależy sposób opracowania modelu, poziom jego abstrakcji i wiele innych jego elementów.

Przyczyny budowy modeli są bardzo zróżnicowane. Zazwyczaj modele systemu buduje się, aby:

- ukryć szczegóły rzeczywistego, skomplikowanego systemu;
- dostosować poziom abstrakcji do potrzeb odbiorcy;
- lepiej zrozumieć funkcjonowanie systemu;
- wnioskować o zachowaniu rzeczywistego systemu na podstawie badania jego modelu.

Dzięki stosowaniu modeli możliwe jest wykorzystanie zdolności ludzkiego umysłu do budowy pojęć abstrakcyjnych. Posługując się modelami, możemy dostosować poziom abstrakcji do naszych potrzeb. Na przykład w projektach architektonicznych możemy ukryć szczegóły związane z instalacjami elektrycznymi czy hydraulicznymi, dzięki czemu model architektoniczny staje się bardziej przejrzysty.

Zasada abstrakcji, polegająca przede wszystkim na ukrywaniu szczegółów, jest jedną z podstawowych zasad wykorzystywanych w trakcie modelowania systemów informatycznych. Dzięki tej zasadzie projektanci systemów mogą skutecznie walczyć ze znaczną złożonością systemów informatycznych.

Z punktu widzenia projektanta systemów informatycznych modele pełnią bardzo istotną rolę. Pozwalają mu oraz pozostałym uczestnikom procesu projektowego (na przykład przyszłemu użytkownikowi) lepiej zrozumieć funkcjonowanie rzeczywistych procesów oraz projektowanego systemu.

Na przykład model przypadków użycia, o którym szerzej powiemy w kolejnym rozdziale, jest jednym z podstawowych narzędzi przy konstruowaniu wymagań dla systemu.

Oczywiście, tak jak i w innych dziedzinach życia, dobór modelu, jego stopień szczegółowości oraz ocena celu jego budowy zależy od osoby, która go buduje oraz od jej potrzeb projektowych.

2.4. Rodzaje modeli

Jak już wspomnieliśmy wcześniej, modele, z którymi mamy do czynienia w życiu codziennym czy zawodowym, są bardzo różne. W tym podrozdziale skoncentrujemy się na rodzajach modeli przydatnych w projektowaniu systemów informatycznych.

Klasyfikacja modeli może przebiegać z uwzględnieniem różnych kryteriów. Możemy dzielić modele, biorąc pod uwagę ich przeznaczenie, obszar systemu, który modelują, stopień złożoności itd.

Z punktu widzenia projektowania systemów informacyjnych możemy wyróżnić na przykład:

- model wymagań,
- model architektury systemu,
- model implementacyjny,
- model magazynu danych.

Każdy z tych modeli może być przedstawiany na różnym poziomie abstrakcji, a więc zawierać różną liczbę szczegółów.

Przykładowy podział modeli pokazuje rysunek 2.6.

Rysunek 2.6. Przykładowa klasyfikacja modeli

Na klasyfikację modeli można też spojrzeć z punktu widzenia ich wpływu na modelowany system.

Rysunek 2.7. Perspektywy w modelowaniu

Przyjrzyjmy się schematycznemu rysunkowi (rys. 2.7). Przedstawiliśmy na nim przykład różnych perspektyw w modelowaniu systemu oraz kolejnych transformacji (odwzorowań), które towarzyszą procesowi projektowemu.

Rysunek 2.8. Przykład modelu architektury systemu na wysokim poziomie abstrakcji

Pierwsza z nich to odwzorowanie świata rzeczywistego na model koncepcyjny. Model taki tworzony jest przez osoby zwane analitykami (lub analitykami biznesowymi). Ich zadaniem jest budowa uproszczonego modelu analitycznego (logicznego), który opisywałby rzeczywiste procesy zachodzące w prawdziwym świecie możliwie w sposób jak najdokładniejszy i najbardziej zrozumiały. Najczęściej w wyniku tych prac powstaje model opisu wymagań i model statyki układu, czyli model klas. Modele perspektywy analitycznej powinny dobrze pokazywać logikę działania systemu oraz jego strukturę. Są jednak budowane na wysokim poziomie abstrakcji i w oderwaniu od warstwy implementacyjnej. Nie zawierają więc wielu szczegółów oraz danych niezbędnych do zaplanowania implementacji systemu. Dlatego też potrzebne jest zbudowanie modeli w innej perspektywie i dokonanie transformaty modelu perspektywy logicznej na model perspektywy implementacyjnej.

Rysunek 2.9. Przykład modelu pojęciowego struktury systemu

Rysunek 2.10. Przykład modelu statyki systemu na niższym poziomie abstrakcji

Modele perspektywy implementacyjnej muszą uwzględniać uwarunkowania platformy, na której zostanie wykonana implementacja przyszłego systemu. Dlatego też w modelach tej perspektywy projektanci muszą zawrzeć szczegółowe informacje dotyczące na przykład typów danych czy specyficznych dla zastosowanego systemu zarządzania bazą danych struktur danych. Modele tej perspektywy cechują się oczywiście większym stopniem szczegółowości i skomplikowania niż modele perspektywy logicznej, a do ich odczytania i zrozumienia potrzebna jest fachowa wiedza. Nie są one przeznaczone dla użytkowników systemu, ale dla jego twórców – architektów, programistów itp.

2.5. Odbiorcy i użytkownicy modeli

W procesie wytwarzania oprogramowania uczestniczy wiele osób. W zasadzie możemy powiedzieć, że każda z nich korzysta w czasie realizacji swoich zadań z pewnego modelu systemu (lub kilku) na odpowiednio dobranym poziomie abstrakcji.

Ważne jest, aby model i jego poziom abstrakcji odpowiadał możliwościom i potrzebom odbiorcy (użytkownika). Na przykład nie ma sensu przedstawiać użytkownikowi końcowemu szczegółowego (na niskim poziomie abstrakcji) modelu implementacyjnego, gdyż po pierwsze model taki nie będzie dla niego zrozumiały, a po drugie znajomość szczegółów implementacyjnych dla użytkownika końcowego jest całkowicie zbędna. Warto natomiast zapoznać go z modelem wymagań zapisanym na przykład w postaci diagramów przypadków użycia (patrz rozdział 8) oraz z tekstowym modelem przypadków użycia. Modele owe przedstawiają te aspekty systemu, które są ważne z punktu widzenia użytkownika końcowego. Oprócz tego modele przypadków użycia mogą być łatwo zrozumiałe dla osoby, która nie ma fachowego przygotowania i umiejętności odczytywania modeli.

Tabela 2.1. Przykładowi użytkownicy modeli

--------------------------------- -----------------------------------------
Model Główny odbiorca
Model wymagań funkcjonalnych Użytkownik końcowy, analityk, architekt
Model wymagań niefunkcjonalnych Użytkownik końcowy, analityk, architekt
Model architektury Architekt
Model danych Twórca bazy danych, programista
Model implementacyjny Programista
Model interfejsów Użytkownik, analityk
--------------------------------- -----------------------------------------

2.6. Język opisu modeli

Zastanówmy się teraz nad bardzo ważnym problemem w modelowaniu systemów: W jaki sposób przedstawiać, opisywać model?

Sposobów opisu otaczającego nas świata i zachodzących w nim zjawisk mamy bardzo wiele. Na przykład artyści do opisu rzeczywistości wybierają różnego rodzaju formy artystyczne, takie jak obrazy, rzeźby, zdjęcia, poezję. Innym sposobem opisu jest użycie postaci słownej. Architekci natomiast w swoich modelach posługują się najczęściej rysunkami. Fizycy budują zaś swoje modele, posługując się językiem matematyki. Jaki więc sposób opisu modeli wybrać w wypadku tworzenia modeli systemów informatycznych?

Na to pytanie nie ma jednoznacznej odpowiedzi. Ze względu na dużą złożoność systemów informatycznych, różnorodność osób uczestniczących w procesie tworzenia tych systemów i skomplikowanie procesów wytwórczych nie można określić jednego, najlepszego sposobu opisu potrzebnych nam modeli.

Język opisu modeli należy dobierać do celów, którym model ma służyć, oraz do użytkowników tego modelu.

Na przykład model wymagań służy dokładnemu i precyzyjnemu określeniu wymagań, które są stawiane systemowi informatycznemu. Jednocześnie model ten musi być zrozumiały zarówno dla analityka, jak i dla użytkownika, który określa wymagania w stosunku do systemu i ostatecznie weryfikuje poprawność modelu wymagań. Dlatego też najlepszym językiem opisu modelu wymagań jest język naturalny (opis wymagań w postaci tekstu) uzupełniony o proste elementy graficzne (diagramy przypadków użycia – patrz rozdział 8).

Warto zwrócić uwagę, że tekst dokumentujący model wymagań powinien być napisany jasnym, zrozumiałym dla wszystkich odbiorców językiem. Często, niestety, zdarza się, że dokumentacja wymagań napisana jest w taki sposób, że dla osoby nieznającej dziedziny problemowej specyfikacja taka jest niezrozumiała. Warto w opisie modelu wymagań formułować jasne i proste zdania, a niejednoznaczne lub niezrozumiałe dla wszystkich odbiorców modelu wymagań terminy objaśniać w słowniku.

Opis tekstowy modelu, choć może zapewnić dużą precyzję, ma też wady. Opis taki jest zwykle długi, liniowy i trudno przy jego użyciu szybko ogarnąć większą część systemu. Z tego też powodu powszechną metodą opisu modeli używanych przy budowie systemów informatycznych jest stosowanie elementów graficznych uzupełnionych często drobnymi elementami tekstowymi.

2.6.1. Cechy dobrego modelu

Spróbujmy teraz sformułować cechy dobrego modelu. Kiedy będziemy mogli uznać, że otrzymany model jest poprawny?

Aby móc odpowiedzieć na to zasadnicze pytanie, musimy najpierw ustalić dwie ważne rzeczy:

- Do czego oceniany model ma posłużyć?
- Kto będzie odbiorcą modelu?

Z punktu widzenia budowy i oceny modelu są to elementy kluczowe. Chcemy przy tym zwrócić uwagę Czytelnika, że mamy tutaj – jak to się często zdarza w życiu – z przykładem relatywizmu. Otóż ten sam model może być raz oceniony jako dobry, a innym razem jako złej jakości. Zależeć to będzie właśnie od odpowiedzi na dwa postawione wcześniej pytania.

Dobry model powinien:

- być zrozumiały dla wszystkich odbiorców, dla których jest przeznaczony;
- być zapisany w jasnej i przejrzystej formie;
- stosować zrozumiałe dla wszystkich odbiorców modelu symbole i elementy;
- zawierać taką liczbę szczegółów, aby nie zamazywać elementów, które na danym etapie są ważne (odpowiedni dobór poziomu abstrakcji);
- ułatwiać zrozumienie działania systemu na odpowiednim poziomie abstrakcji;
- umożliwiać realizację celu, dla którego został opracowany;
- być spójny i logiczny.

Zdajemy sobie sprawę, że wymienione cechy dobrego modelu są sformułowane na dużym poziomie ogólności. Ocena poprawności modelu nie jest łatwa: zależy od wielu czynników i zawsze uzależniona jest od celów stawianych budowie modelu oraz od osób, które dokonują tej oceny.

Budując dobry model, warto zawsze mieć na uwadze ostateczny cel, któremu ma służyć. Takie podejście projektowe nie gwarantuje jeszcze sukcesu, ale zdecydowanie zwiększa szansę na jego osiągnięcie.

2.6.2. Jak popsuć model? Cechy złego modelu

Budowa dobrego modelu nie jest łatwa i wymaga dużego wysiłku, wiedzy i doświadczenia. Za to łatwo jest model „popsuć”.

Najczęstszym błędem popełnianym podczas tworzenia modelu systemu jest niedostosowanie modelu (jego poziomu abstrakcji) do potrzeb projektowych. Często zdarza się, że model przeznaczony do wstępnej analizy potrzeb użytkownika i analizy wymagań systemu zawiera zbyt dużo szczegółowych elementów. Szczegóły te utrudniają dostrzeżenie strategicznych wymagań i powodują, że projektanci zajmują się niepotrzebnymi szczegółami, zamiast identyfikować najważniejsze potrzeby.

Z drugiej strony model przeznaczony na przykład do budowy implementacji systemu musi zawierać szczegóły implementacyjne. Jeśli jest ich pozbawiony, osoba tworząca kod nie będzie wiedziała, jakie decyzje powinna podjąć lub może podjąć decyzje błędne, niezgodne z ogólniejszymi założeniami budowy systemu.

Kolejnym sposobem na zbudowanie złego modelu jest stosowanie do jego zapisu złożonej i często nieznanej wszystkim osobom pracującym z modelem notacji. Wówczas wysiłek potrzeby do odczytania i zrozumienia modelu jest znaczny, a duży stopień skomplikowania towarzyszący zazwyczaj takim rozwiązaniom sprzyja błędom i niepoprawnym interpretacjom. Warto więc przyjąć podstawowe założenie: im forma opisu modelu jest prostsza i bardziej przejrzysta, tym lepiej.

Oczywiście zdarzają się sytuacje, w których skomplikowanie opisu jest potrzebne, na przykład w celu wyrażenia niezbędnych niuansów opisywanego systemu czy procesu. W takiej sytuacji trzeba się jednak upewnić, że wszyscy członkowie zespołu rozumieją semantykę modelu. Często zdarza się, że zamiast posługiwać się nowym lub rzadko stosowanym elementem notacyjnym na diagramie modelu, lepiej jest zastosować komentarz słowny.

Świetną receptą na uczynienie modelu zupełnie nieprzydatnym jest też zastosowanie niejasnej i nieprzejrzystej formy jego prezentacji. Na przykład niestarannie narysowany diagram klas z licznymi przecinającymi się liniami łączącymi klasy może sprawić, że prosty model staje się trudny w odbiorze, a tym samym traci swój istotny atut prostoty i przejrzystości.

Zły model charakteryzuje się najczęściej następującymi cechami:

- Jest bardzo rozbudowany i zawiera wiele nieistotnych szczegółów.
- Jest zapisany niezrozumiałym, skomplikowanym językiem.
- Stosuje do opisu rozbudowaną i skomplikowaną notację.
- Jest niespójny bądź trudny do zrozumienia.
- Nie uwzględnia potrzeb, dla których jest budowany.
- Nie wiadomo, dla kogo jest przeznaczony.
- Nie wiadomo, jakiemu celowi ma służyć.

2.7. Podsumowanie

Jeśli chcemy rozwiązać jakiś problem, najpierw budujemy model, a potem przystępujemy do jego rozwiązania. Model służy uproszczeniu problemu i ukryciu niepotrzebnych szczegółów. Dobry model pomaga też w zrozumieniu rzeczywistego problemu lub działania systemu.

Budowa modeli złożonych systemów nie jest łatwa. Wymaga wiedzy i doświadczenia. Budując modele, trzeba zawsze wziąć pod uwagę, jaki problem chcemy za jego pomocą rozwiązać (do czego model jest nam potrzebny) oraz kto będzie z tego modelu korzystał. Od tych dwu elementów zależy wiele decyzji projektowych, takich jak dobór języka do opisania modelu, poziom abstrakcji itp.

2.8. Czego dotyczył rozdział?

2.8.1. Czego nauczyłeś się w tym rozdziale?

W tym rozdziale omówiliśmy pojęcie modelu oraz jego rolę i znaczenie w procesie projektowym. Zapoznałeś się też Drogi Czytelniku z różnymi sposobami wyrażania modeli oraz z ich podziałem (choć przedstawiony podział modeli nie jest kompletny).

Po lekturze fragmentów poświęconych rozważaniom na temat dobrych i złych modeli powinieneś też rozumieć, na co zwracać uwagę, budując dobry model, a jakich praktyk unikać.

2.8.2. Jakich błędów warto unikać?

Najlepiej uczyć się na błędach. Oby tylko nie na swoich. Z tego powodu zwracamy uwagę na typowe błędy i pomyłki, z jakimi spotykamy się w swojej praktyce zawodowej i pracy ze studentami.

Jakich więc błędów unikać w czasie pracy z modelami systemów?

Najczęstszym błędem jest nieodpowiedni dobór modelu do celów, które za jego pomocą chcemy osiągnąć. Do najczęstszych błędów należą:

- umieszczanie zbyt dużej liczby niepotrzebnych szczegółów;
- nadmierne gmatwanie modelu;
- w opisach z zastosowaniem języka naturalnego stosowanie długich, skomplikowanych, podrzędnie złożonych zdań;
- brak świadomości, jaki cel chcemy osiągnąć za pomocą modelu;
- brak świadomości, kto będzie odbiorcą modelu.

2.9. Ćwiczenia sprawdzające

2.9.1. Pytania testowe

1. Kaskadowy model cyklu życia oprogramowania:

a) utrudnia klientowi walidację produktu na etapie wytwarzania;

b) w praktyce każda jego faza jest realizowana zgodnie z podejściem spiralnym;

c) utrudnia sporządzenie harmonogramu projektu.

2. Dobry model powinien:

a) spełniać wymagania użytkownika;

b) być możliwie jak najbardziej szczegółowy;

c) być dostosowany do potrzeb jego odbiorcy.

3. Odbiorcą modeli tworzonych w czasie wytwarzania oprogramowania są:

a) przyszli użytkownicy;

b) analitycy;

c) programiści.

2.9.2. Pytania otwarte

1. Zastanów się, w jakim celu budujemy modele. Podaj kilka przykładów modeli, które sam zbudowałeś.

2. Jakimi cechami powinien charakteryzować się dobry model? Podaj przykład modelu, który uważasz za dobry.

3. Jakimi cechami charakteryzuje się zły model? Podaj przykład modelu, w którym, Twoim zdaniem, występują te złe cechy.

4. Przeczytaj pytanie testowe numer trzy do tego rozdziału. Zastanów się, z jakich modeli korzysta każda z wymienionych osób.

2.10 Słowniczek pojęć wprowadzonych w rozdziale

Model systemu – opis wybranych aspektów systemu na wybranym poziomie abstrakcji. Model nie jest dokładnym odwzorowaniem modelowanego systemu. Zazwyczaj model stanowi uproszczenie systemu rzeczywistego. Wzorzec, prototyp.

2.11 Przegląd literatury

2.1. Robert Maksimchuk, Eric Naiburg, UML dla zwykłych śmiertelników, PWN, Warszawa 2007

Jest to świetna książka wprowadzająca w tajniki języka UML. Czytelnik znajdzie też w niej rozdział poświęcony modelowaniu oraz rozważaniom na temat, czym jest model, po co budować modele i jak je oceniać. Lektura ta może stanowić dobre uzupełnienie rozważań zawartych w naszej książce.

2.2. Zbigniew Michalewicz, David Fogel, Jak to rozwiązać, czyli nowoczesna heurystyka, Wydawnictwa Naukowo−Techniczne, Warszawa 2006

Znakomita pozycja dotycząca rozwiązywania różnych, nieraz bardzo złożonych problemów z wykorzystaniem modeli. Co prawda stosowane modele są głównie modelami matematycznymi, ale sposoby dochodzenia do rozwiązania i zasady tworzenia dobrych modeli są uniwersalne. W tej pozycji ukazane są na tle wielu bardzo ciekawych zagadnień i opisane w świetny sposób.