| Model konceptualny bazy danych w UML. |
|---|
| Napisane przez Wed 08 Feb 2006 przez Artur (6482 cztane) |
|
Etap modelowania konceptualnego wiąże się przede wszystkim z uzmysłowieniem sobie występujących procesów biznesowych. Innymi słowy, kwestia już samej bazy danych i związanych z nią technicznych tematów jest daleka od tego miejsca, aczkolwiek te informacje są niezbędna do jej powstania. W realnym świecie praca nad projektem sprowadza się do spotkań z ludźmi pracującymi w tym danym środowisku. Istnieją pewne gotowe wzorce do przeprowadzania takich spotkań, za przykład może posłużyć choćby tzw. sesja JAD (Joint Application Development), podczas której zbiera się wymagania i modeluje przyszły system. Model biznesowych przypadków użycia. Poznanie istniejących procesów biznesowych jest niezbędne a zarazem pierwszą czynnością którą należy wykonać aby rozpocząć pracę nad konkretnym systemem informatycznym. Użyłem pojęcia systemu, dlatego że baza danych jest jedynie elementem pewnej całości i nie sposób ją zaprojektować bez wiedzy o reszcie. Jednak niniejszy temat pracy zobowiązuje mnie do projektowania samej bazy danych, dlatego też to ona tu będzie na pierwszym planie. W zasadzie podstawowym czynnikiem, który decyduje o większości procesów biznesowych są poczynania ludzi istniejących w danym systemie informacyjnym. Zrozumienie ich sposobu postrzegania procesów biznesowych jest głównym celem analityka. Zamieszczenie wielu stron tekstu na temat tych procesów, nie przekazuje tak pożądanych informacji jak diagramy biznesowych przypadków użycia. Powstają one na bazie szeregu rozmów z przyszłymi użytkownikami systemu. W zbiorze pytań, podstawowymi będą: czym się zajmujesz ? co robisz aby zrealizować swoją pracę ? czy doświadczenie wpłynęło na twoją opinię o pewnych zbędnych czynnościach ? Diagram zawiera tzw. biznesowych aktorów, biznesowe przypadki użycia oraz powiązania pomiędzy nimi. Poniżej zamieszczę opisane symbole notacji UML. Diagramy czynności biznesowych przypadków użycia. Fundamentem dla tych diagramów są biznesowe przypadki użycia. Pozwalają zrozumieć istotę występujących procesów wszystkim, począwszy od przyszłych użytkowników przez członków sztabu technicznego a skończywszy oczywiście na zleceniodawcach. Diagram pokazuje tzw. wnętrze przypadków użycia, pozwala jednocześnie zrozumieć jak przypadki użycia są wykonywane. Kolejne cechy każdego to: zrozumienie procesów biznesowych, zidentyfikowanie obszaru procesów biznesowych, odkrycie powielania się procesów, zidentyfikowanie tzw. wąskich gardeł. Model biznesowy celu Diagram ten jest w zasadzie pewnego rodzaju uzupełnieniem kompletnego zrozumienia występujących procesów biznesowych. Powyżej omawiane diagramy skupiają uwagę na samych przypadkach użycia i występujących w nich czynnościach. Modelując tzw. cel biznesowy uświadomię sobie przede wszystkim jak te czynności wyglądają od wewnątrz systemu informacyjnego. Co za tym idzie, zrozumiem jacy pracownicy i w jakiej ilości realizują te czynności, które zaspokajają procesy biznesowe. Encje biznesowe wskażą jakie składniki poza ludźmi występują w obiegu informacji. Prace nad modelem biznesowym celu rozpoczynają się i bazują na analizowaniu biznesowych przypadków użycia. Biznesowy model celu zawiera biznesowych pracowników, aktorów biznesowych, encje biznesowe oraz połączenia pomiędzy nimi. Diagramy sekwencji Jest diagramem obrazującym interakcję obiektów z wypukleniem czasu. To oddziaływanie obiektów przedstawia nam choćby scenariusz danego przypadku użycia. Obiekty umieszczamy na górze, czas jest przedstawiony na linii znajdującej się pod danym obiektem. Czas jego aktywności uwidacznia prostokąt na „jego linii czasu”. Komunikaty które są przesyłane pomiędzy obiektami możemy rozpatrywać na trzy różne sposoby: proste (przekazanie sterowania od obiektu do obiektu), synchroniczne(obiekt po wysłaniu komunikatu czeka na odpowiedź), asynchroniczne(wysłanie komunikatu przez obiekt nie powoduje wstrzymanie jego działań). Wyróżniamy podstawowy podział diagramu przebiegu tzn. diagram przebiegu egzemplarzowy gdzie jest przedstawiony jeden scenariusz danego przypadku użycia oraz diagram przebiegu ogólny gdzie rozpatrujemy możliwe scenariusze. Możliwość stworzenia a zarazem obiekt przedstawiamy w postaci prostokąta zawierającego jego nazwę, umieszczając go niżej od już istniejących. Komunikat „Create” tworzy natomiast „destroy” usuwa obiekt. Dopuszczalne jest również przedstawienie rozgałęzienia if (warunek jeżeli jest przedstawiony w nawiasach kwadratowych) oraz pętli while (warunek dopóki przedstawiony w nawiasach prostokątnych z gwiazdką po lewej stronie). Rekurencja również nie jest tu nie rozwiązanym tematem. A mianowicie, przedstawiamy jako strzałkę wychodzącą i wchodzącą do miejsca aktywacji obiektu. Możliwe jest również umieszczanie na tej linii czasu stanów, podobnie jak w przypadku diagramów stanów. Diagram sekwencji stanowi ważne ogniwo w poprawnym zrozumieniu potrzeb i wymagań od bazy danych. Możemy tu przejrzyście zobrazować przepływ informacji, który jest niezmiernie ważny dla samej bazy danych. Wyczytujemy tu jakie transakcje i w jakim czasie mają miejsce. Poprzednia analiza tu nabiera rzeczywistego wymiaru czasu, który jest nieodłączny przy korzystaniu z bazy danych. Zapotrzebowanie od bazy poprzez wykonywanie poszczególnych zadań tu obrazujemy nie tylko poprzez samo istnienie ale również wpływ i oddziaływanie otaczających bytów. |
| Indeks :: Drukuj :: E-mail |
Komentarze są własnością ich autorów. Nie ponosimy odpowiedzialności za ich treść.