Historia UML-a

Rozwój języka UML rozpoczął się w październiku 1994 r., kiedy Grady Booch i Jim Rumbaugh z Rational Software Corporation rozpoczęli współpracę nad ujednoliceniem metod Boocha i OMT (techniki modelowania obiektów). Obie metody rozwijały się niezależnie od siebie i słusznie zostały nazwane jedną z najlepszych metod podejścia obiektowego w tworzeniu systemów oprogramowania. Postanowiono połączyć te dwie metody i w październiku 1995 roku wypuszczono wersję beta, którą nazwano Metodą Ujednoliconą.

Pod koniec 1996 roku stało się jasne, że wiele dużych firm było gotowych uznać UML za podstawową strategię biznesową. Powstało konsorcjum non-profit OMG (Object Modeling Group), które zrzeszało takich wiodących producentów oprogramowania jak DEC, HP, IBM, Microsoft, Oracle, Rational Software itp. W styczniu 1997 roku wydano UML 1.0. Wkrótce do OMG dołączyły takie firmy jak IBM, Objectime, Platinum Technology i Softeam. W wyniku tej współpracy pojawił się UML 1.1. Wersja 1.5 została przyjęta w 2003 roku. 2004 – przyjęto wersję 2.0

Struktura UML-a

UML (skrót od Unified Modeling Language) to graficzny język opisu służący do modelowania obiektów w dziedzinie tworzenia oprogramowania. UML to język ogólny, otwarty standard, który wykorzystuje notację graficzną do tworzenia abstrakcyjnego modelu systemu, zwanego modelem UML. UML został stworzony w celu definiowania, wizualizacji, projektowania i dokumentowania większości systemów oprogramowania.

UML zapewnia rozwój reprezentatywnych modeli organizowania interakcji pomiędzy klientem a twórcą IS oraz różnymi grupami programistów IS.

Przede wszystkim UML dziedziczy techniki Boocha, OMT i OOSE.

Po drugie, obejmuje je.

Po trzecie, należy zauważyć, że UML jest standardem językowym, a nie standardem procesowym.

Język UML zawiera zestaw elementów graficznych używanych na diagramach. Jako język UML zawiera zasady łączenia tych elementów. Diagramy służą do pokazania różnych widoków systemu. Ten zbiór różnych reprezentacji nazywany jest modelem. Model UML opisuje, co system będzie musiał zrobić. Jednocześnie nie mówi się nic o tym, w jaki sposób zostanie on wdrożony.

Z najbardziej ogólnego punktu widzenia opis języka UML składa się z dwóch oddziałujących na siebie części, takich jak:

Semantyka języka UML. Reprezentuje pewien metamodel, który definiuje abstrakcyjną składnię i semantykę koncepcji modelowania obiektowego w języku UML.

Notacja UML. Jest to notacja graficzna służąca do wizualnego przedstawienia semantyki języka UML.

Diagramy UML-a

Przejdźmy teraz do przeglądu notacji graficznej UML. Notacja graficzna to odwzorowanie reprezentacji wizualnej na semantykę języka. Jak wspomniano wcześniej, UML jest kwintesencją trzech technik modelowania i zasadniczo dziedziczy ich zapis graficzny, odrzucając elementy mało używane i niewyraźne i dodając nowe, aby sprostać potrzebom rynku nowoczesnych systemów oprogramowania. Tworząc UML staraliśmy się zachować równowagę pomiędzy prostotą i zrozumiałością języka a jego siłą wyrazu i precyzją. Model opracowywanego systemu to zbiór wzajemnie powiązanych podmodeli, z których każdy opisany jest zbiorem diagramów opisanych za pomocą notacji graficznej zdefiniowanej w języku UML.

Projekt stworzony przy użyciu UML 1.x może zawierać następujące diagramy (pogrupowane według ich przeznaczenia): Są takie schematy osiem:

Diagram przypadków użycia

· Diagram klas

· Diagramy zachowań

o Diagram stanu

o Schemat działania

o Diagramy interakcji

§ Diagram sekwencyjny

§ Schemat współpracy

· Schematy realizacji

o Schemat komponentów

o Schemat wdrożenia

3.1. Diagram przypadków użycia

Diagramy użytkowania opisują funkcjonalność IS, która będzie widoczna dla użytkowników systemu. „Każda funkcjonalność” jest przedstawiana jako „przypadki użycia” lub po prostu przypadki użycia. Przypadek użycia to typowa interakcja użytkownika z systemem, która:

opisuje funkcję widoczną dla użytkownika,

może reprezentować różne poziomy szczegółowości,

zapewnia osiągnięcie określonego celu, ważnego dla użytkownika.

Przypadek użycia jest oznaczony na diagramie owalem związanym z użytkownikami, których zwykle nazywa się aktorami. Aktorzy korzystają z systemu (lub są przez system wykorzystywani) w danym przypadku użycia. Aktor odgrywa pewną rolę w tym przypadku użycia. Diagram przedstawia tylko jednego aktora, ale realnych użytkowników pełniących tę rolę w stosunku do IS może być wielu. Lista wszystkich precedensów faktycznie określa wymagania funkcjonalne dla systemu informatycznego, które stanowią podstawę do opracowania specyfikacji technicznych dla stworzenia systemu.

W diagramach przypadków użycia, oprócz powiązań pomiędzy aktorami i przypadkami użycia, można zastosować jeszcze dwa rodzaje powiązań pomiędzy przypadkami użycia: „use” i „extension” (rys. 3.1.1). Połączenie typu przedłużającego jest używane, gdy jeden przypadek użycia jest podobny do drugiego, ale niesie ze sobą nieco większe obciążenie funkcjonalne. Należy go stosować przy opisywaniu zmian w normalnym zachowaniu systemu. Połączenie typu „use” pozwala na wyizolowanie pewnego fragmentu zachowania systemu i uwzględnienie go w różnych przypadkach użycia bez konieczności jego ponownego opisywania.

Sednem roli UML-a w tworzeniu oprogramowania jest różnorodność sposobów jego wykorzystania, czyli różnice przeniesione z innych języków modelowania graficznego. Różnice te prowadzą do długich i trudnych dyskusji na temat sposobu stosowania UML.

Aby rozwiązać tę trudną sytuację, Steve Mellor i Martin Fowler niezależnie opracowali definicję trzy tryby używania UML przez programistów: mode naszkicować, tryb projekt i tryb język programowania. Najważniejszym z nich jest oczywiście sposób użytkowania. UML do szkicowania. W tym trybie programiści używają języka UML do przekazywania informacji o różnych aspektach systemu. W trybie projektowania można używać szkiców do inżynierii postępowej i odwrotnej. Na rozwój bezpośredni(inżynieria przyszłości) diagramy są rysowane przed kodowaniem i kiedy inżynieria odwrotna(inżynieria odwrotna) diagramy budowane są w oparciu o kod źródłowy, aby lepiej go zrozumieć.

Istota szkicowania lub modelowanie szkiców, w selektywności. W przypadku programowania bezpośredniego szkicujesz poszczególne elementy programu, który masz zamiar napisać, i zwykle omawiasz je z niektórymi programistami w swoim zespole. Dzięki szkicom chcesz ułatwić dzielenie się pomysłami i opcjami tego, co zamierzasz zrobić. Nie omawiasz całego programu, nad którym zamierzasz pracować, a jedynie najważniejsze punkty, które chcesz najpierw przekazać współpracownikom lub fragmenty projektu, które chcesz zwizualizować przed rozpoczęciem programowania. Spotkania te mogą być bardzo krótkie: 10-minutowe spotkanie obejmujące kilka godzin programowania lub jednodniowe spotkanie w celu omówienia dwutygodniowej iteracji.

W inżynierii odwrotnej używasz szkiców, aby wyjaśnić, jak działa jakaś część systemu. Nie pokazujesz wszystkich klas, tylko te, które są interesujące i warte omówienia przed zagłębieniem się w kod. Ponieważ szkicowanie jest nieformalne i dynamiczne i trzeba to robić szybko i wspólnie, najlepszym nośnikiem do wyświetlania jest tablica. Szkice przydają się także w dokumentacji, gdzie dużą rolę odgrywa sam proces przekazania informacji, a nie kompletność. Narzędzia do szkicowania to lekkie narzędzia do rysowania i często programiści tak naprawdę nie przestrzegają wszystkich rygorystycznych zasad UML. Siła szkiców tkwi w selektywności przekazu informacji, a nie w kompletności opisu.

Wręcz przeciwnie, język UML-a Jak oznacza projekt ukierunkowane na kompletność. W procesie bezpośredniego rozwoju koncepcja jest taka, że ​​projekt jest opracowywany przez projektanta, którego zadaniem jest zbudowanie szczegółowego modelu dla programisty, który zajmie się kodowaniem. Taki model powinien być w miarę kompletny pod względem ustalonych decyzji projektowych, a programista powinien móc je śledzić bezpośrednio i bez większego myślenia. Projektantem modelu może być ten sam programista, ale z reguły projektantem jest starszy programista, który opracowuje modele dla zespołu programistów. Powodem takiego podejścia jest analogia z innymi rodzajami prac inżynierskich, gdzie profesjonalni inżynierowie tworzą rysunki, które następnie przekazywane są firmom budowlanym.

Projekt można zastosować do wszystkich części systemu lub projektant może narysować model konkretnej części. Typowym podejściem jest opracowanie przez projektanta modeli na poziomie projektu jako interfejsów podsystemów, a następnie umożliwienie programistom pracy nad szczegółami implementacji.

W inżynierii odwrotnej celem modeli jest przedstawienie szczegółowych informacji o programie w formie dokumentów papierowych lub w formie umożliwiającej interaktywne przeglądanie za pomocą przeglądarki graficznej. W takim modelu możesz pokazać wszystkie szczegóły klasy w formie graficznej, która jest łatwiejsza do zrozumienia dla programistów.

Modelowanie wymaga bardziej wyrafinowanych narzędzi niż szkicowanie, ponieważ konieczne jest zachowanie szczegółów spełniających wymagania zadania. Specjalistyczne narzędzia CASE (inżynieria oprogramowania wspomaganego komputerowo) należą do tej kategorii, chociaż samo określenie stało się niemal wulgarnym słowem, a dostawcy starają się go unikać. Narzędzia do bezpośredniego programowania umożliwiają rysowanie diagramów i kopiowanie ich do repozytorium w celu przechowywania informacji. Narzędzia inżynierii wstecznej odczytują kod źródłowy, zapisują jego interpretację w repozytorium i generują diagramy. Nazywa się narzędzia, które umożliwiają inżynierię do przodu i do tyłu dwustronny (w obie strony).

Niektóre narzędzia wykorzystują kod źródłowy jako repozytorium, a diagramy wykorzystują go do graficznej reprezentacji. Narzędzia takie są bliżej związane z programowaniem i często są wbudowane bezpośrednio w narzędzia do edycji kodu źródłowego.

Granica między modelami a szkicami jest dość niewyraźna, ale różnice polegają na tym, że szkice celowo są niekompletne, podkreślając ważne informacje, podczas gdy modele dążą do kompletności, często w celu ograniczenia programowania do prostych i nieco mechanicznych działań. Oznacza to, że szkice można zdefiniować jako elementy próbne, a modele jako ostateczne.

Im dłużej pracujesz z UML-em, a programowanie staje się bardziej mechaniczne, tym bardziej oczywista staje się potrzeba przejścia do zautomatyzowanego tworzenia programów. Rzeczywiście wiele narzędzi CASE generuje kod w taki czy inny sposób, co pozwala zautomatyzować budowę znacznej części systemu. W końcu dojdziesz do punktu, w którym będziesz mógł opisać cały system za pomocą UML i będziesz w trybie UML. jako język programowania . W takim środowisku programiści rysują diagramy, które są kompilowane bezpośrednio do kodu wykonywalnego, a kod UML staje się kodem źródłowym. Oczywiście takie zastosowanie UML-a wymaga szczególnie wyrafinowanych narzędzi. (Ponadto notacje inżynierii forward i odwrotnej stają się bez znaczenia, ponieważ UML i kod źródłowy stają się jednym i tym samym.)

Jednym z interesujących zagadnień dotyczących UML-a jako języka programowania jest problematyka modelowania logiki behawioralnej. UML 2 oferuje trzy sposoby modelowania zachowań: diagramy interakcji, diagramy stanów i diagramy aktywności. Wszystkie mają swoich zwolenników w dziedzinie programowania.

Inny pogląd deweloperów na UML mieści się gdzieś pomiędzy jego wykorzystaniem do modelowania koncepcyjnego a jego wykorzystaniem do modelowania oprogramowania. Większość programistów używa języka UML do modelowania oprogramowania. Z punktu widzenia oprogramowania Elementy UML są odwzorowywane niemal bezpośrednio na elementy systemu oprogramowania. Jak zobaczymy później, mapowanie nie oznacza wykonywania instrukcji, ale kiedy używamy języka UML, mówimy o elementach oprogramowania.

Z koncepcyjny punkt widzenia UML reprezentuje opis pojęć domenowych. Tutaj nie tyle mówimy o elementach oprogramowania, ile o stworzeniu słownictwa umożliwiającego dyskusję na określony obszar tematyczny.

Nie ma ścisłych zasad wyboru punktu widzenia. Ponieważ na problem można spojrzeć z różnych punktów widzenia, istnieje wiele sposobów jego zastosowania. Niektóre narzędzia automatycznie konwertują kod źródłowy na diagramy, traktując UML jako alternatywną formę kodu źródłowego. Jest to w dużej mierze perspektywa programowa. Jeżeli diagramy UML są wykorzystywane do testowania i zrozumienia różnych znaczeń terminów „pula aktywów” w grupie księgowych, wówczas należy przyjąć znacznie bliższe podejście koncepcyjne.

Konsekwencją różnych zastosowań UML jest to, że toczy się wiele debat na temat znaczenia diagramów UML i ich powiązania z resztą świata. Dotyczy to szczególnie relacji między UML a kodem źródłowym. Niektórzy programiści uważają, że do stworzenia modelu niezależnego od języka programowania użytego do realizacji projektu należy zastosować UML. Inni są przekonani, że model niezależny od języka to oksymoron.

Kolejna różnica zdań dotyczy kwestii natury UML. Myślę, że większość użytkowników UML-a, zwłaszcza szkicowników, widzi istotę UML-a w jego diagramach. Jednak autorzy UML uważają diagramy za drugorzędne, a metamodel UML za pierwotny. Diagramy są jedynie reprezentacją metamodelu. Ten punkt widzenia ma również sens dla programistów używających UML w trybie projektowania i w trybie języka programowania.

Streszczenie: Zidentyfikowano 3 sposoby wykorzystania języka UML.

1 - tryb szkicowania. Sporządzany jest szkic albo przyszłego kodu (wtedy trzeba będzie napisać kod na podstawie modelu), albo istniejącego (aby go lepiej zrozumieć). Celem jest szybka wymiana informacji. Cecha - selektywność. Kompletność nie jest ważna, ważny jest sam proces wymiany.

2 - tryb projektowania. Celem jest kompletność. Powstaje szczegółowy model, który następnie zostanie zaimplementowany (a programista nie musi dużo myśleć o implementacji, jego praca ogranicza się do prostych czynności mechanicznych). Można modelować całość lub tylko część.

3 - tryb języka programowania. Diagramy graficzne są kompilowane w kod, UML staje się kodem źródłowym.

Odpowiedź z poprzednich lat (Den)

Język Ujednolicony język modelowania (UML) można uznać za wynik dość długiej i niezakończonej jeszcze ewolucji metodologii modelowania i projektowania.

To zjednoczenie miało trzy główne cele:

· modelowanie systemu od koncepcji do modułu wykonywalnego, z wykorzystaniem technik obiektowych;

· rozwiązywanie problemów skalowalności w złożonych systemach;

· stworzenie języka modelowania używanego zarówno przez ludzi, jak i komputery.

Do czego służy UML?

UML jest przede wszystkim językiem i jak każde narzędzie językowe dostarcza słownictwa i zasad łączenia słów w tym słownictwie. W tym przypadku słownictwo i reguły skupiają się na koncepcyjnych i fizycznych reprezentacjach systemu. Język dyktuje, jak utworzyć i odczytać model, ale nie dostarcza żadnych wskazówek, jaki rodzaj modelu systemu należy utworzyć - wykracza to poza zakres UML i jest domeną procesu tworzenia oprogramowania.

UML jest językiem wizualizacji. Pisanie modeli w języku UML ma jeden prosty cel – ułatwić proces przekazywania informacji o systemie. Każdy symbol UML ma ściśle określoną semantykę, co pozwala uniknąć błędów interpretacyjnych.

UML to język specyfikacji i precyzyjnych definicji. W tym sensie modelowanie UML oznacza budowanie modeli, które są dokładne, jednoznaczne i kompletne.

UML jest językiem dokumentacji.

Diagramy UML-a

Wizualizacja projektu systemu z różnych punktów widzenia w języku UML realizowana jest poprzez diagramy – rzuty systemu. Diagram to graficzna reprezentacja zbioru elementów, która jest przedstawiona jako połączony graf z wierzchołkami (bytami) i krawędziami (związkami).

Poniżej znajdują się definicje wykresów:

· Schemat klas- diagram strukturalny przedstawiający wiele klas, interfejsów, kooperacji i relacji między nimi;

· Schemat obiektu- schemat strukturalny pokazujący wiele obiektów i relacje między nimi. Można to uznać za szczególny przypadek diagramu klas. Narzędzia do modelowania nie muszą obsługiwać osobnego formatu diagramów cech. Przedstawiają obiekty, więc diagram klas, który nie ma klas, ale zawiera należące do nich obiekty, można uznać za diagram obiektowy;

· Diagram przypadków użycia- diagram zachowań pokazujący wiele precedensów i aktorów, a także zależności między nimi;

· Schemat interakcji:

o Diagram sekwencyjny- diagram zachowania przedstawiający interakcję i podkreślający sekwencję czasową zdarzeń;

o Schemat współpracy- diagram zachowania, który pokazuje interakcję i podkreśla strukturalną organizację obiektów wysyłających i odbierających wiadomości;

· Diagram stanu- diagram zachowania przedstawiający maszynę i podkreślający zachowanie obiektów pod względem kolejności odbierania zdarzeń;

· Diagram aktywności- diagram zachowania przedstawiający maszynę i podkreślający przejścia przepływu sterowania z jednej czynności do drugiej;

· Schemat komponentów- diagram przedstawiający organizację pewnego zbioru elementów i zależności między nimi - dotyczy statystycznego typu systemu;

· diagram topologii systemu (schemat wdrożenia)- schemat strukturalny przedstawiający węzły i relacje między nimi.

Odpowiedź z poprzednich lat (Madina)

opcja 1

Metodologia projektowania obiektowego w języku UML (diagramy UML)

Unified Modeling Language (UML) to język służący do specyfikowania, wizualizacji, konstruowania i dokumentowania, w oparciu o podejście obiektowe, różnych typów systemów: programowych, sprzętowych, programowo-sprzętowych, mieszanych, jawnie obejmujących działalność człowieka itp.

Język UML służy między innymi do projektowania relacyjnych baz danych. W tym celu wykorzystywana jest niewielka część języka (diagramy klas), ale nawet wtedy nie w całości. Z punktu widzenia projektowania relacyjnych baz danych możliwości modeli nie odbiegają zbytnio od możliwości diagramów ER

Schemat klas w terminologii UML nazywa się to diagramem przedstawiającym zbiór klas (i kilka innych bytów), które nie są jawnie powiązane z projektem bazy danych), a także relacje pomiędzy tymi klasami. Ograniczenia mogą być nieformalnie określone w języku naturalnym lub sformułowane w języku OCL (Object Constraints Language).

Klasa nazywa się nazwany opis zbioru obiektów o wspólnych atrybutach, operacjach, relacjach i semantyce. Graficznie klasa jest przedstawiona jako prostokąt. Nazwa (ciąg tekstowy) używana do identyfikacji klasy.

Atrybut klasy to nazwana właściwość klasy opisująca zbiór wartości, jakie mogą przyjmować instancje tej właściwości. Klasa może mieć dowolną liczbę atrybutów (w szczególności nie może posiadać żadnego atrybutu).

Działanie klasowe to nazwana usługa, której można zażądać od dowolnego obiektu tej klasy. Operacja jest abstrakcją tego, co można zrobić z obiektem. Klasa może zawierać dowolną liczbę operacji (w szczególności nie może zawierać żadnych operacji). Zbiór operacji klasy jest wspólny dla wszystkich obiektów tej klasy.

Diagram klas może obejmować trzy różne kategorie relacji: zależność, uogólnienie i powiązanie.

Uzależnienie nazywane sprzęganiem aplikacji, gdy zmiana specyfikacji jednej klasy może wpłynąć na zachowanie innej klasy korzystającej z pierwszej klasy. Jeśli interfejs drugiej klasy ulegnie zmianie, wpływa to na zachowanie obiektów pierwszej klasy. Zależność jest pokazana jako linia przerywana ze strzałką wskazującą klasę, od której istnieje zależność.

Uogólnienie połączenia nazywa się połączeniem wspólnego bytu zwanego superklasa lub rodzic i bardziej wyspecjalizowana wersja tej jednostki o nazwie podklasa lub potomek. Uogólnienia są czasami nazywane połączeniami "jest", co oznacza, że ​​klasa potomka jest szczególnym przypadkiem klasy przodka. Klasa potomna dziedziczy wszystkie atrybuty i operacje po klasie przodka, ale można w niej zdefiniować dodatkowe atrybuty i operacje.

Pojedyncze dziedziczenie (gdzie każda podklasa ma tylko jedną nadklasę) jest wystarczające w większości przypadków, gdy używana jest relacja rodzajowa. Jednak UML pozwala również na wielokrotne dziedziczenie, gdy jedna podklasa jest zdefiniowana na podstawie kilku nadklas.

Na tym schemacie klasy Student I Badacz wywodzące się z tej samej nadklasy Człowiek Z Uniwersytetu. Do klasy Student odnoszą się do tych obiektów klasy Człowiek Z Uniwersytetu, które odpowiadają uczniom i klasie Badacz- obiekty klasowe Człowiek Z Uniwersytetu, odpowiadają badacze. Często zdarza się, że wielu studentów zaczyna brać udział w projektach badawczych już na studiach, więc mogą istnieć takie dwa obiekty zajęć Student I Badacz, które odpowiadają jednemu obiektowi klasy Człowiek Z Uniwersytetu. Zatem wśród obiektów klasy Student mogą być badaczami, a niektórzy badacze mogą być studentami. Następnie możemy zdefiniować klasę Student-Badacz poprzez wielokrotne dziedziczenie z nadklas Student I Badacz. Obiekt klasy Student-Badacz ma wszystkie właściwości i operacje klas Student I Badacz i może być używany wszędzie tam, gdzie można używać obiektów tych klas. Zatem polimorfizm inkluzyjny nadal działa. Wiąże się to jednak z szeregiem problemów. Na przykład podczas tworzenia podklas Student I Badacz oba mogą mieć zdefiniowany atrybut Adres IP komputera. Dla obiektów klas Student wartościami tego atrybutu będzie adres IP komputera klasy terminalowej, a dla obiektów tej klasy Badacz- Adres IP komputera laboratorium badawczego. Co więcej, dla obiektu klasy Student-Badacz Obydwa atrybuty o tej samej nazwie mogą być istotne (student może posiadać zarówno adres IP komputera klasy terminalowej, jak i adres IP komputera laboratorium badawczego). W praktyce stosuje się jedno z poniższych rozwiązań:

• zabraniać tworzenia podklas Student-Badacz dopóki nazwa atrybutu nie zostanie zmieniona w jednej z nadklas Adres IP komputera;
• dziedziczyć tę właściwość tylko z jednej z nadklas, dzięki czemu np. wartość atrybutu Adres IP komputera dla obiektów klas Student-Badacz zawsze będzie adresem IP komputera laboratorium badawczego;
• Dziedzicz obie właściwości w podklasie, ale automatycznie zmieniaj nazwy obu atrybutów, aby wyjaśnić ich znaczenie; nazwij je np. Adres IP komputera Ucznia I Adres IP komputera Badacza.

Każde z tych rozwiązań ma wady, więc używając UML-a do projektowania relacyjnych baz danych, należy zachować szczególną ostrożność podczas korzystania z dziedziczenia klas w ogóle i starać się unikać dziedziczenia wielokrotnego.

Stowarzyszenie nazywa się relacją strukturalną, pokazującą, że obiekty jednej klasy są w jakiś sposób powiązane z obiektami innej lub tej samej klasy. Dopuszczalne jest, aby oba końce stowarzyszenia należały do ​​tej samej klasy. Asocjacja może obejmować dwie klasy i wtedy nazywa się ją binarną. Możliwe jest utworzenie asocjacji łączących n klas na raz (nazywa się to asocjacjami n-arycznymi). 1) Graficznie asocjacja jest przedstawiana jako linia łącząca klasę z nią samą lub z innymi klasami.

Istnieją cztery ważne dodatkowe pojęcia związane z koncepcją skojarzenia: nazwa, rola, wielość i agregacja. Stowarzyszeniu można nadać nazwę, która charakteryzuje charakter relacji. Innym sposobem nazwania stowarzyszenia jest wskazanie roli każdej klasy uczestniczącej w stowarzyszeniu. Rolę klasy, podobnie jak nazwa końca połączenia w modelu ER, określa nazwa umieszczona pod linią asocjacyjną bliżej danej klasy.

Ogólnie rzecz biorąc, stowarzyszeniu można nadać zarówno własną nazwę, jak i nazwy ról klasowych. Dzieje się tak dlatego, że klasa może odgrywać tę samą rolę w różnych asocjacjach, zatem ogólnie rzecz biorąc, para nazw ról klas nie identyfikuje powiązania. W prostych przypadkach, gdy między dwiema klasami zdefiniowano tylko jedno powiązanie, można w ogóle nie kojarzyć z nim dodatkowych nazw.

Wielość Rola asocjacji to cecha wskazująca, ile obiektów klasy o danej roli może lub musi uczestniczyć w każdej instancji asocjacji.

Najczęstszym sposobem określenia wielokrotności roli skojarzenia jest określenie określonej liczby lub zakresu. Wartość „1” wskazuje, że każdy obiekt klasy z daną rolą musi uczestniczyć w jakiejś instancji tego powiązania, a tylko jeden obiekt klasy z daną rolą może uczestniczyć w każdej instancji powiązania. Podanie zakresu „0..1” wskazuje, że nie wszystkie obiekty klasy o danej roli muszą uczestniczyć w dowolnej instancji danego powiązania, lecz w każdym wystąpieniu powiązania może uczestniczyć tylko jeden obiekt. Podobnie określenie zakresu „1..*” wskazuje, że wszystkie obiekty klasy z daną rolą muszą uczestniczyć w jakiejś instancji tego powiązania, a przynajmniej jeden obiekt musi uczestniczyć w każdym wystąpieniu powiązania (nie określono górnej granicy ). W bardziej skomplikowanych przypadkach wyznaczania krotności można zastosować listy zakresów.

Zwykłe powiązanie między dwiema klasami charakteryzuje relację między równymi bytami: obie klasy znajdują się na tym samym poziomie pojęciowym. Czasami jednak diagram klas musi odzwierciedlać fakt, że powiązanie między dwiema klasami ma specjalną formę część-całość. W tym przypadku klasa „całość” ma wyższy poziom pojęciowy niż klasa „część”. Takie stowarzyszenie nazywa się agregat.

Komputery muszą być zainstalowane w każdej klasie terminali. Dlatego klasa Komputer jest „częścią” klasy Klasa terminala. Rola klasy Komputer jest opcjonalne, ponieważ w zasadzie klasy terminali mogą istnieć bez komputerów. Co więcej, choć klasy terminalowe, które nie są wyposażone w komputery, nie spełniają swojej funkcji, obiekty klas Klasa terminala I Komputer istnieć niezależnie.

Zdarzają się przypadki, gdy związek pomiędzy „częścią” i „całością” jest tak silny, że zniszczenie „całości” prowadzi do zniszczenia wszystkich jej „części”. Nazywa się zbiorcze skojarzenia z tą właściwością złożony lub po prostu kompozycje.

Każdy wydział wchodzi w skład jednej uczelni, a likwidacja uczelni powoduje likwidację wszystkich istniejących na niej wydziałów, chociaż w trakcie istnienia uczelni poszczególne wydziały mogą być likwidowane i tworzone.

Diagramy klas mogą określać ograniczenia integralności, które muszą być obsługiwane w projektowanej bazie danych. UML umożliwia definiowanie ograniczeń na dwa sposoby: w języku naturalnym oraz w języku OCL (Object Constraints Language).

Z punktu widzenia definiowania ograniczeń integralności bazy danych ważniejsze są sposoby definiowania niezmienników klas.

Pod niezmienny klasa w OCL rozumiana jest jako warunek, który muszą spełniać wszystkie obiekty danej klasy. Ściślej mówiąc, niezmiennik klasy jest wyrażeniem logicznym, którego ocena musi dawać prawdę przy powstaniu dowolnego obiektu danej klasy i utrzymywać prawdziwą wartość przez cały czas istnienia tego obiektu. Definiując niezmiennik należy podać nazwę klasy oraz wyrażenie definiujące niezmiennik określonej klasy. Syntaktycznie wygląda to tak:

Poniżej znajdują się przykłady niezmienników do określania ograniczeń w OCL.

1. Wyraź w OCL zastrzeżenie, zgodnie z którym pracownicy powyżej 30. roku życia muszą pracować w działach o numerach większych niż 5

2. Określ ograniczenie, zgodnie z którym każdy dział musi mieć kierownika, a żaden dział nie może być tworzony przed odpowiednią firmą

3. Warunek czwartego niezmiennika ogranicza maksymalną możliwą liczbę pracowników firmy do 1000

Opcja 2

1. model RUP. Podstawowe diagramy modelu RUP.

Rational Unified Process (RUP) to jedna ze spiralnych metodologii tworzenia oprogramowania. Metodologia jest wspierana przez Rational Software, a produkt jest aktualizowany około dwa razy w roku. Unified Modeling Language (UML) jest używany jako język modelowania w ogólnej bazie wiedzy.

Iteracyjne tworzenie oprogramowania w RUP polega na podzieleniu projektu na kilka małych projektów, które są realizowane sekwencyjnie, a każda iteracja programistyczna jest jasno zdefiniowana przez zestaw celów, które należy osiągnąć na końcu iteracji. W końcowej iteracji zakłada się, że zestaw celów iteracji musi dokładnie odpowiadać zestawowi celów określonych przez klienta produktu, czyli muszą zostać spełnione wszystkie wymagania. RUP zapewnia ustrukturyzowane podejście do iteracyjnego tworzenia oprogramowania, dzieląc proces na cztery kamienie milowe w czasie: początek, opracowanie, konstrukcja i przejście. Aby pomyślnie opracować projekt, RUP zaleca przestrzeganie sześciu praktyk:

Rozwój iteracyjny;

Zarządzanie wymaganiami;

Stosowanie architektur modułowych;

Modelowanie wizualne;

Kontrola jakości;

Śledzenie zmian.

Nazywa się graficzne reprezentacje modeli systemów w języku UML diagramy. W języku UML definiuje się następujące typy:

· przypadek użycia lub diagram przypadków użycia(diagram przypadków użycia)

· diagram klas(schemat klas)

· wykresy zachowań(schematy zachowań)

· diagram stanu(schemat stanu)

· Diagram aktywności(Diagram aktywności)

· diagramy interakcji(schematy interakcji)

· diagram sekwencyjny(diagram sekwencyjny)

· schemat współpracy(schemat współpracy)

· schematy realizacji(schematy realizacji)

· schemat komponentów(schemat komponentów)

· schemat rozmieszczenia(schemat wdrożenia)

Każdy z tych diagramów przedstawia inny widok modelu systemu. Jednocześnie diagram przypadków użycia reprezentuje koncepcyjny model systemu, który jest punktem wyjścia do konstruowania wszystkich pozostałych diagramów. Diagram klas to model logiczny, który odzwierciedla statyczne aspekty projektu strukturalnego systemu, a diagramy zachowań, które są również rodzajami modelu logicznego, odzwierciedlają dynamiczne aspekty jego funkcjonowania. Diagramy implementacyjne służą do przedstawienia elementów systemu i odnoszą się do jego modelu fizycznego.

Niektóre z powyższych diagramów służą do oznaczenia dwóch lub więcej podgatunków. Poniższe diagramy służą jako niezależne reprezentacje: przypadków użycia, zajęcia, stwierdza, zajęcia, sekwencje, współpraca, składniki I zastosowanie.

W przypadku diagramów UML istnieją trzy typy symboli wizualnych, które są ważne ze względu na zawarte w nich informacje:

· komunikacja, które są reprezentowane przez różne linie na płaszczyźnie;

· tekst, zawarte w granicach poszczególnych kształtów geometrycznych;

· symbole graficzne, przedstawione w pobliżu elementów wizualnych diagramów.

· każdy diagram musi być pełną reprezentacją jakiegoś fragmentu modelowanego obszaru tematycznego;

· podmioty modelu przedstawione na diagramie muszą być na tym samym poziomie koncepcyjnym;

· wszystkie informacje o podmiotach muszą być wyraźnie przedstawione na schemacie;

· diagramy nie powinny zawierać sprzecznych informacji;

· diagramy nie powinny być przeładowane informacjami tekstowymi;

· każdy diagram musi być samowystarczalny dla prawidłowej interpretacji wszystkich jego elementów;

· liczba typów diagramów potrzebnych do opisu konkretnego systemu nie jest ściśle ustalona i ustalana jest przez konstruktora;

Modele systemów powinny zawierać tylko te elementy, które są zdefiniowane

22. Projekt układu scalonego [J]

Gotowa odpowiedź Tony'ego

Odpowiedzi Denisa Kovalevicha zostały zaktualizowane

Etap wdrożenia

Jedną z głównych przyczyn nieudanych wdrożeń jest słaby rozwój projektu SI na etapie doradztwa zarządczego. W rezultacie system informacyjny okazuje się niewystarczająco zintegrowany z całościowym systemem zarządzania firmą.

· brak wsparcia ze strony kluczowych pracowników, zwłaszcza gdy trzeba poświęcić odpowiednią ilość czasu i energii na etapy krytyczne;

· zbyt ambitne plany zamiast mądrego podejścia krok po kroku;

· brak uzyskania wystarczającej porady od praktyków posiadających faktyczne doświadczenie w korzystaniu z podobnych systemów w podobnych przedsiębiorstwach.

Etap operacji

o użytku codziennego;

Sprzedaż

Odpowiedź z poprzednich lat (Madina)

Realizacja.

2.1. Sporządzanie projektów technicznych (TP).

TP tworzą konsultanci wykonawcy i specjaliści IT klienta;

Klient zatwierdza TP.

Określony jest zakres prac, termin i koszt.

Materiały TP wykorzystywane są przy planowaniu i dokumentowaniu prac.

Skład TP:

struktura przechowywanych danych;

algorytmy;

wykorzystywane zasoby systemowe, ich struktura i połączenia;

interfejs użytkownika.

2.2. Planowanie pracy.

Zgodnie z zatwierdzonymi przepisami

kierownicy projektów wykonawcy i klienta sporządzają programy pracy (WP);

klient i wykonawca zatwierdzają RP.

Opracowywane są indywidualne plany dla członków zespołu roboczego.

Skład RP:

wykaz prac: konfiguracja, badania, odbiory (lista prac może zawierać specyfikacje techniczne i specyfikacje techniczne);

czas realizacji;

odpowiedzialny za każdy element RP.

2.3. Wypełnianie podstawowych podręczników.

Cechy sceny:

może wymagać od 1 do 18 miesięcy;

wymaga centralizacji wprowadzania informacji;

jest warunkiem koniecznym działania systemu.

Metody realizacji:

konwersja danych;

ręczne wprowadzanie danych przez użytkowników (operatorów).

2.4. Konfiguracja, testowanie, akceptacja.

Cechy sceny:

najbardziej pracochłonny i odpowiedzialny;

w znacznym stopniu zależy od wstępnego przygotowania (regulaminy, specyfikacje techniczne, specyfikacje techniczne, RP);

wymaga ścisłej dyscypliny zarówno ze strony wykonawcy, jak i ze strony klienta;

towarzyszy pojawienie się dodatkowych zadań od klienta;

wymaga elastyczności ze strony Klienta i Wykonawcy w celu przezwyciężenia sytuacji konfliktowych.

2.5. Operacja próbna.

Cechy sceny:

wymaga szybkiej i rzetelnej reakcji ze strony wykonawcy;

może wymagać od klienta znacznego wysiłku (podwójna praca);

ma znaczny czas trwania (1-3 miesiące);

towarzyszy utworzenie ostatecznej listy uwag (sugestii), planowanie i wykonanie końcowych prac związanych z konfiguracją, testowaniem i odbiorem.

2.6. Dokumentacja.

przygotowanie instrukcji dla użytkowników;

opracowywanie regulaminów współdziałania działów w systemie;

finalizacja dokumentacji technicznej;

tworzenie innych (wcześniej uzgodnionych) dokumentów.

2.7. Zakończenie projektu.

prawne zamknięcie stosunków umownych;

ostateczne rozliczenia finansowe;

podejmowanie decyzji dotyczących dalszej współpracy: zawieranie umów wsparcia technicznego i pogwarancyjnego, wdrażanie nowych projektów.

Recykling IP– przeprowadza się przyciskiem USUŃ.

Odpowiedź z poprzednich lat (Den)

Etap wdrożenia

Faza opracowania i wdrożenia jest zwykle zawsze zakończona w całości. Nie przeszkadza w tym słaby rozwój technologii, brak kompetencji personelu czy użytkowników, czy brak dobrych konsultantów.

Jeśli na tym etapie pojawią się problemy, są one związane z trzema głównymi przyczynami:

brak wsparcia ze strony kluczowych pracowników, szczególnie gdy na krytycznych etapach należy poświęcić odpowiednią ilość czasu i energii;

zbyt ambitne plany zamiast mądrego podejścia krok po kroku;

brak wystarczających porad od praktyków mających faktyczne doświadczenie w korzystaniu z podobnych systemów w podobnych przedsiębiorstwach.

Etap operacji

· Uruchomienie systemu informatycznego

o uruchomienie urządzeń technicznych do eksploatacji próbnej;

o uruchomienie oprogramowania w trybie próbnym;

o szkolenie i certyfikacja personelu;

o przeprowadzenie próbnego działania komponentów i systemu jako całości;

o przekazanie do eksploatacji i podpisanie protokołów odbioru robót.

· Obsługa systemu informatycznego

o użytku codziennego;

o wsparcie oprogramowania, sprzętu i całego projektu.

Etap wsparcia (konserwacji).

Usługi wsparcia technicznego odgrywają bardzo znaczącą rolę w życiu każdego korporacyjnego systemu informatycznego. Obecność wykwalifikowanej służby technicznej na etapie eksploatacji systemu informatycznego jest warunkiem koniecznym do realizacji powierzonych mu zadań, a błędy personelu obsługującego mogą prowadzić do oczywistych lub ukrytych strat finansowych porównywalnych do kosztu samego systemu informacyjnego.

Główne działania wstępne w ramach przygotowań do organizacji utrzymania systemu informatycznego to:

· identyfikację najbardziej krytycznych elementów systemu i określenie krytyczności dla nich przestojów (pozwoli to na identyfikację najbardziej krytycznych elementów systemu informatycznego i optymalizację alokacji zasobów na utrzymanie);

· identyfikację zadań utrzymaniowych i ich podział na wewnętrzne, rozwiązywane przez serwis, i zewnętrzne, rozwiązywane przez wyspecjalizowane organizacje serwisowe (w ten sposób dokonuje się jasnego określenia zakresu realizowanych funkcji i podziału odpowiedzialności);

· analizę dostępnych zasobów wewnętrznych i zewnętrznych niezbędnych do organizacji utrzymania ruchu w ramach opisanych zadań i podziału kompetencji (główne kryteria analizy: dostępność gwarancji na sprzęt, stan funduszu remontowego, kwalifikacje personelu);

· przygotowanie planu organizacji utrzymania, w którym należy określić etapy czynności do wykonania, terminy ich wykonania, koszty poszczególnych etapów oraz odpowiedzialność wykonawców.

Zapewnienie wysokiej jakości obsługi technicznej systemu informatycznego wymaga zaangażowania wysoko wykwalifikowanych specjalistów, którzy są w stanie rozwiązać nie tylko codzienne zadania administracyjne, ale także szybko przywrócić system w przypadku awarii.

Sprzedaż

Likwidacja produktu wraz z przekształceniem jego komponentów w surowce wtórne (zgodnie z wymogami środowiskowymi), połączona z wyłączeniem wszelkich informacji związanych z likwidowanym przedmiotem z systemu informacyjno-informacyjnego.

Temat ten jest szczegółowo omówiony pod adresem http://www.piter.com/attachment.php?barcode=978546900641&at=exc&n=0 i http://www.rus-lib.ru/book/38/men/21 /2.3.html

23. Projekt układu scalonego [J]

Powiązana informacja.

definicję podobną do poniższej.

Język- system znaków służący:

• środek ludzkiej komunikacji i aktywności umysłowej;
• sposób wyrażania samoświadomości człowieka;
• sposób przechowywania i przesyłania informacji.

Język obejmuje zbiór znaków (słownictwo) oraz zasady ich używania i interpretacji (gramatyka).

Do tej dość obszernej definicji musimy dodać, że języki mogą być naturalne i sztuczne, formalne i nieformalne. UML jest językiem formalnym i sztucznym, chociaż, jak zobaczymy później, ta etykieta nie do końca do niego pasuje. Jest sztuczny, bo ma autorów, o których w przyszłości będziemy wspominać jeszcze nie raz (jednocześnie rozwój UML-a trwa nieustannie, co stawia go na równi z językami naturalnymi). Można go nazwać formalnym, ponieważ istnieją zasady jego użycia (jednak opis UML zawiera również elementy wyraźnie nieformalne, o czym ponownie przekonamy się później). Jeszcze jeden niuans: UML to język graficzny, co również trochę myli sytuację!

Przy opisie formalnego języka sztucznego, co widzieliśmy już na przykładach opisu języków programowania, z reguły opisywane są takie elementy, jak:

1. składnia, czyli określenie zasad konstruowania konstrukcji językowych;
2. semantyka, czyli określenie reguł, według których struktury językowe nabywają znaczenie semantyczne;
3. pragmatyka, czyli określenie zasad używania konstrukcji językowych do osiągnięcia potrzebnych nam celów.

Ponadto mniej więcej w tym samym czasie (początek lat 80.) rozpoczęła się „era obiektowa”. Wszystko zaczęło się wraz z pojawieniem się rodziny języków programowania SmallTalk, która zastosowała niektóre koncepcje języka Simula-67 używanego w latach 60-tych. Pojawienie się podejścia obiektowego wynikało przede wszystkim ze wzrostu złożoności problemów. Podejście obiektowe dokonał dość radykalnych zmian w samych zasadach tworzenia i działania programów, ale jednocześnie pozwolił na ich znaczny wzrost wydajność pracy programistów, aby inaczej spojrzeć na problemy i metody ich rozwiązywania, aby programy były bardziej zwarte i łatwo rozszerzalne. W rezultacie języki, które pierwotnie były zorientowane na tradycyjne podejście do programowania, otrzymały szereg rozszerzeń obiektowych. Jednym z pierwszych, w połowie lat 80., był Apple ze swoim projektem Object Pascal. Oprócz, podejście obiektowe wygenerował potężną falę zupełnie nowych technologii oprogramowania, których szczytem były tak powszechnie uznane platformy jak Microsoft. NET Framework i Sun Java.

Ale najważniejsze jest to, że pojawienie się OOP wymagało wygodnego narzędzia do modelowania, ujednoliconej notacji do opisu złożonych systemów oprogramowania. I tak „trzej amigos”, trzej główni specjaliści, trzej autorzy najpopularniejszych metod, postanowili połączyć swoje osiągnięcia. W 1991 roku każdy z „trzech amigos” zaczął od napisania książki, w której opisał swoją metodę OOAP. Każda metodologia była

UML to ujednolicony język modelowania graficznego do opisywania, wizualizacji, projektowania i dokumentowania systemów OO. UML ma za zadanie wspierać proces modelowania oprogramowania w oparciu o podejście OO, organizować relacje koncepcji koncepcyjnych i programowych oraz odzwierciedlać problemy skalowania złożonych systemów. Modele UML są wykorzystywane na wszystkich etapach cyklu życia oprogramowania, od analizy biznesowej po konserwację systemu. Różne organizacje mogą używać UML według własnego uznania, w zależności od obszarów problemowych i używanych technologii.

Krótka historia UML-a

Do połowy lat 90. różni autorzy zaproponowali kilkadziesiąt metod modelowania OO, z których każda wykorzystywała własną notację graficzną. Jednocześnie każda z tych metod miała swoje mocne strony, ale nie pozwalała na zbudowanie wystarczająco kompletnego modelu PS, pokazując go „ze wszystkich stron”, czyli wszystkich niezbędnych projekcji (patrz artykuł 1). Ponadto brak standardu modelowania OO utrudniał programistom wybór najodpowiedniejszej metody, co uniemożliwiało powszechne przyjęcie podejścia OO do tworzenia oprogramowania.

Na zlecenie Object Management Group (OMG), organizacji odpowiedzialnej za przyjęcie standardów w zakresie technologii obiektowych i baz danych, pilny problem unifikacji i standaryzacji rozwiązali autorzy trzech najpopularniejszych metod OO – G Butch, D. Rambo i A. Jacobson, którzy połączyli wysiłki, stworzyli wersję UML 1.1, zatwierdzoną przez OMG w 1997 roku jako standard.

UML jest językiem

Każdy język składa się ze słownictwa i zasad łączenia słów w celu tworzenia znaczących konstrukcji. Tak w szczególności skonstruowane są języki programowania, w tym UML. Jego cechą charakterystyczną jest to, że słownik językowy tworzą elementy graficzne. Z każdym symbolem graficznym związana jest specyficzna semantyka, dzięki czemu model stworzony przez jednego programistę może być dobrze zrozumiany przez innego, a także przez narzędzie programowe interpretujące UML. Z tego wynika w szczególności, że model oprogramowania przedstawiony w UML może zostać automatycznie przetłumaczony na język programowania OO (taki jak Java, C++, VisualBasic), to znaczy, jeśli istnieje dobre narzędzie do modelowania wizualnego obsługujące UML, posiadające zbudowaliśmy model, otrzymamy także przykładowy kod programu odpowiadający temu modelowi.

Należy podkreślić, że UML jest językiem, a nie metodą. Wyjaśnia, z jakich elementów tworzyć modele i jak je czytać, ale nie mówi nic o tym, jakie modele należy opracowywać i w jakich przypadkach. Aby stworzyć metodę opartą na UML-u, należy ją uzupełnić o opis procesu wytwarzania oprogramowania. Przykładem takiego procesu jest Rational Unified Process, który zostanie omówiony w kolejnych artykułach.

Słownik UML-a

Model jest reprezentowany w postaci bytów i relacji między nimi, które są pokazane na diagramach.

Podmioty to abstrakcje będące głównymi elementami modeli. Istnieją cztery typy bytów – strukturalne (klasa, interfejs, komponent, przypadek użycia, współpraca, węzeł), behawioralne (interakcja, stan), grupujące (pakiety) i adnotacyjne (komentarze). Każdy typ jednostki ma swoją własną reprezentację graficzną. Podmioty zostaną szczegółowo omówione podczas studiowania diagramów.

Relacja pokazać różne powiązania między bytami. W UML-u zdefiniowano następujące typy relacji:

• Uzależnienie ukazuje taki związek pomiędzy dwoma bytami, gdy zmiana w jednym z nich – niezależnym – może wpłynąć na semantykę drugiego – zależnego. Zależność jest reprezentowana przez przerywaną strzałkę skierowaną od podmiotu zależnego do podmiotu niezależnego.
• Stowarzyszenie jest zależnością strukturalną pokazującą, że obiekty jednego podmiotu są powiązane z obiektami innego. Graficznie powiązanie jest pokazane jako linia łącząca powiązane podmioty. Asocjacje służą do nawigacji pomiędzy obiektami. Na przykład powiązanie między klasami „Zamówienie” i „Produkt” można wykorzystać z jednej strony do znalezienia wszystkich produktów określonych w konkretnym zamówieniu lub z drugiej strony do znalezienia wszystkich zamówień zawierających ten produkt. Oczywiste jest, że odpowiednie programy muszą wdrożyć mechanizm zapewniający taką nawigację. Jeśli wymagana jest nawigacja tylko w jednym kierunku, jest to oznaczone strzałką na końcu skojarzenia. Szczególnym przypadkiem asocjacji jest agregacja – relacja typu „całość” – „część”. Graficznie jest to podkreślone rombem na końcu w pobliżu esencji-całości.
• Uogólnienie to relacja pomiędzy jednostką nadrzędną a jednostką podrzędną. Zasadniczo relacja ta odzwierciedla właściwość dziedziczenia klas i obiektów. Uogólnienie przedstawiono w postaci linii zakończonej trójkątem skierowanym w stronę jednostki nadrzędnej. Dziecko dziedziczy strukturę (atrybuty) i zachowanie (metody) rodzica, ale jednocześnie może mieć nowe elementy struktury i nowe metody. UML umożliwia wielokrotne dziedziczenie, gdy jednostka jest powiązana z więcej niż jedną jednostką nadrzędną.
• Realizacja– relacja pomiędzy bytem definiującym specyfikację zachowania (interfejs) z bytem definiującym implementację tego zachowania (klasa, komponent). Zależność ta jest powszechnie stosowana przy modelowaniu komponentów i zostanie opisana bardziej szczegółowo w kolejnych artykułach.

Schematy. UML udostępnia następujące diagramy:

• Diagramy opisujące zachowanie systemu:
• Diagramy stanu
• diagramy aktywności,
• diagramy obiektów,
• diagramy sekwencji,
• Schematy współpracy;
• Schematy opisujące fizyczną realizację systemu:
• Schematy komponentów;
• Schematy wdrożeniowe.

Widok sterowania modelem. Pakiety.

Mówiliśmy już, że aby model był dobrze zrozumiany przez człowieka, należy go zorganizować hierarchicznie, pozostawiając na każdym poziomie hierarchii niewielką liczbę bytów. UML zawiera sposób organizowania hierarchicznej reprezentacji modelu – pakietów. Każdy model składa się z zestawu pakietów, które mogą zawierać klasy, przypadki użycia oraz inne encje i diagramy. Pakiet może zawierać inne pakiety, umożliwiając tworzenie hierarchii. UML nie zapewnia oddzielnych diagramów pakietów, ale mogą one pojawiać się na innych diagramach. Opakowanie ma kształt prostokąta z zakładką.

Co zapewnia UML.

• hierarchiczny opis złożonego systemu poprzez identyfikację pakietów;
• formalizacja wymagań funkcjonalnych dla systemu za pomocą aparatu przypadków użycia;
• uszczegóławianie wymagań systemowych poprzez konstruowanie diagramów działań i scenariuszy;
• identyfikowanie klas danych i konstruowanie koncepcyjnego modelu danych w postaci diagramów klas;
• identyfikacja klas opisujących interfejs użytkownika i stworzenie schematu nawigacji ekranowej;
• opis procesów interakcji pomiędzy obiektami podczas wykonywania funkcji systemowych;
• opis zachowania obiektu w postaci diagramów aktywności i stanu;
• opis komponentów oprogramowania i ich interakcji poprzez interfejsy;
• opis fizycznej architektury systemu.

I ostatnia rzecz...

Pomimo całej atrakcyjności języka UML, trudno byłoby go zastosować w prawdziwym modelowaniu oprogramowania bez narzędzi do modelowania wizualnego. Narzędzia takie pozwalają na szybkie prezentowanie diagramów na ekranie wyświetlacza, ich dokumentowanie, generowanie szablonów kodów programów w różnych językach programowania OO oraz tworzenie schematów baz danych. Większość z nich uwzględnia możliwość reengineeringu kodów programów – przywrócenia określonych projekcji modelu oprogramowania poprzez automatyczną analizę kodów źródłowych programów, co jest bardzo ważne dla zapewnienia zgodności pomiędzy modelem a kodami oraz przy projektowaniu systemów, które dziedziczą funkcjonalność systemów poprzednich.

Unified Modeling Language (UML) to standardowe narzędzie do tworzenia „planów” systemów informatycznych (IS). Za pomocą języka UML można wizualizować, określać, projektować i dokumentować elementy tych systemów.

UML nadaje się do modelowania dowolnego systemu: od systemów informatycznych na skalę korporacyjną po rozproszone aplikacje internetowe, a nawet wbudowane systemy czasu rzeczywistego. Jest to bardzo wyrazisty język, który pozwala spojrzeć na system ze wszystkich punktów widzenia istotnych dla jego rozwoju i późniejszego wdrożenia. Pomimo bogactwa możliwości wyrazu, język ten jest łatwy do zrozumienia i użycia. Najlepszym miejscem do rozpoczęcia nauki języka UML jest jego model pojęciowy, który obejmuje trzy podstawowe elementy: podstawowe elementy składowe, zasady definiujące sposób łączenia tych bloków oraz niektóre ogólne mechanizmy języka.

UML jest jednym z elementów procesu rozwoju IS. Choć UML jest niezależny od modelowanej rzeczywistości, najlepiej stosować go wtedy, gdy proces modelowania opiera się na rozważaniu przypadków użycia, jest iteracyjny i przyrostowy, a sam system ma jasno określoną architekturę.

UML to język służący do wizualizacji, specyfikowania, konstruowania i dokumentowania elementów systemów oprogramowania. Język składa się ze słownika i reguł, które pozwalają łączyć zawarte w nim słowa i tworzyć sensowne konstrukcje. W języku modelowania słownictwo i reguły skupiają się na koncepcyjnej i fizycznej reprezentacji systemu. Język modelowania, taki jak UML, jest standardowym narzędziem do tworzenia „planów” układów scalonych.

Tworząc IS o dowolnej złożoności, przeprowadza się modelowanie przyszłego systemu, ale w wielu przypadkach odbywa się to nieformalnie, bez opracowywania żadnego dokumentu. Jednak takie podejście jest obarczone problemami. Po pierwsze, wymiana poglądów na temat modelu pojęciowego jest możliwa tylko wtedy, gdy wszyscy uczestnicy dyskusji mówią tym samym językiem. Po drugie, nie da się uzyskać wglądu w pewne aspekty systemów informatycznych bez modelu wykraczającego poza granice tekstowego języka programowania. Po trzecie, jeśli autor kodu nigdy jawnie nie zaimplementował zamierzonych modeli, informacje te zostaną utracone na zawsze, jeśli zmieni pracę. W najlepszym przypadku można go odtworzyć tylko częściowo na podstawie implementacji.

Użycie UML rozwiązuje trzeci problem: jawny model ułatwia komunikację.

Niektóre funkcje systemu najlepiej modelować tekstowo, inne graficznie. Tak naprawdę we wszystkich interesujących systemach istnieją struktury, których nie można przedstawić za pomocą samego języka programowania. UML jest językiem graficznym, który pozwala rozwiązać drugi ze zidentyfikowanych problemów.

UML to coś więcej niż tylko zestaw symboli graficznych. Za każdym z nich kryje się dobrze określona semantyka. Oznacza to, że model napisany przez jednego programistę może być jednoznacznie zinterpretowany przez innego – lub nawet przez program narzędziowy. To rozwiązuje pierwszy z problemów wymienionych powyżej.

W tym kontekście specyfikacja oznacza budowanie dokładnych, jednoznacznych i kompletnych modeli. UML pozwala określić wszystkie istotne decyzje dotyczące analizy, projektowania i wdrażania, które należy podjąć podczas opracowywania i wdrażania systemu informacyjnego.

UML jest językiem projektowania wizualnego, a modele utworzone przy jego użyciu można bezpośrednio przetłumaczyć na różne języki programowania IS.

Podczas opracowywania SI uwzględniane są takie elementy jak:

• wymagania systemowe;
• opis architektury;
• projekt;
• źródło;
• plany projektów;
• testy;
• prototypy;
• wersje itp.

W zależności od przyjętej metodyki rozwoju, niektóre prace wykonywane są w sposób bardziej formalny, inne zaś mniej. Wymienione elementy nie są po prostu dostarczonymi elementami projektu; są niezbędne do zarządzania, oceny wyniku, a także jako środek komunikacji pomiędzy członkami zespołu w trakcie rozwoju systemu i po jego wdrożeniu.

UML rozwiązuje problem dokumentowania architektury systemu i wszystkich jego szczegółów, dostarcza języka do formułowania wymagań systemowych i definiowania testów, wreszcie dostarcza narzędzi do modelowania pracy na etapie planowania projektu i kontroli wersji.

Gdzie używany jest UML

Język UML przeznaczony jest przede wszystkim do tworzenia systemów informatycznych. Jego zastosowanie jest szczególnie skuteczne w następujących obszarach:

• systemy informacyjne na skalę przedsiębiorstwa;
• usługi bankowe i finansowe;
• telekomunikacja;
• transport;
• przemysł obronny, lotnictwo i astronautyka;
• sprzedaż detaliczna;
• elektronika medyczna;
• nauka;
• rozproszone systemy internetowe.

Zakres UML-a nie ogranicza się do modelowania oprogramowania. Jej wyrazistość pozwala modelować m.in. obieg dokumentów w systemach prawnych, strukturę i funkcjonowanie systemu obsługi pacjenta w szpitalach, projektować sprzęt komputerowy.

Model koncepcyjny UML

Aby zrozumieć UML, należy zrozumieć jego model pojęciowy, na który składają się trzy elementy: podstawowe elementy składowe języka, zasady ich łączenia oraz pewne mechanizmy wspólne dla całego języka. Po opanowaniu tych elementów będziesz mógł czytać modele UML i tworzyć je samodzielnie - oczywiście na początku niezbyt skomplikowane. W miarę zdobywania doświadczenia z językiem nauczysz się korzystać z jego bardziej zaawansowanych możliwości.

Bloki konstrukcyjne UML

Słownictwo UML obejmuje trzy typy elementów składowych:

• esencje;
• relacja;
• diagramy.

Jednostki to abstrakcje będące podstawowymi elementami modelu. Relacje łączą różne podmioty; diagramy grupują zbiory interesujących nas obiektów.

W języku UML istnieją cztery typy encji:

• strukturalny;
• behawioralne;
• grupowanie;
• opisowy.

Jednostki są podstawowymi obiektowymi blokami języka. Za ich pomocą można stworzyć prawidłowe modele. Istnieje siedem typów bytów strukturalnych:

• Klasa
• Interfejs
• Współpraca
• Przypadek użycia
• Aktywna klasa
• Część
• Węzeł

Te siedem podstawowych elementów — klasy, interfejsy, kooperacje, przypadki użycia, aktywne klasy, komponenty i węzły — to podstawowe byty strukturalne, które można uwzględnić w modelu UML. Istnieją również odmiany tych bytów: aktorzy, sygnały, narzędzia (rodzaje klas), procesy i wątki (rodzaje aktywnych klas), aplikacje, dokumenty, pliki, biblioteki, strony i tabele (rodzaje komponentów).

Rzeczy behawioralne są dynamicznymi składnikami modelu UML. Są to czasowniki języka: opisują zachowanie modelu w czasie i przestrzeni. Istnieją tylko dwa główne typy jednostek behawioralnych:

• Interakcja
• Maszyna stanu

Te dwa elementy interakcji i automaty są głównymi jednostkami behawioralnymi zawartymi w modelu UML. Semantycznie są one często kojarzone z różnymi elementami strukturalnymi, przede wszystkim klasami, kooperacjami i obiektami.

Jednostki grupujące są organizującymi częściami modelu UML. Są to bloki, na które można rozłożyć model. Istnieje tylko jedna podstawowa jednostka grupująca, a mianowicie plastikowa torba.

Pakiety to podstawowe jednostki grupujące, których można używać do organizowania modelu UML. Istnieją również odmiany pakietów, takie jak struktury, modele i podsystemy.

Elementy adnotacji— części wyjaśniające modelu UML. Są to komentarze mające na celu dodatkowy opis, wyjaśnienie lub komentarz dotyczący dowolnego elementu modelu. Istnieje tylko jeden podstawowy typ elementu adnotacji: Notatka. Uwaga to po prostu symbol reprezentujący komentarze lub ograniczenia dołączone do elementu lub grupy elementów. Graficznie notatka jest przedstawiana jako prostokąt z zakrzywioną krawędzią, zawierający tekst lub komentarz graficzny.

UML definiuje cztery typy relacji:

• uzależnienie;
• stowarzyszenie;
• uogólnienie;
• realizacja.

Relacje te stanowią podstawowe elementy łączące w języku UML i służą do tworzenia prawidłowych modeli.
Opisane cztery elementy to główne typy relacji, które można uwzględnić w modelach UML. Istnieją również ich odmiany, takie jak udoskonalanie, śledzenie, włączanie i rozszerzanie (w przypadku zależności).

Diagram w UML to graficzna reprezentacja zbioru elementów, najczęściej przedstawiana jako połączony graf z wierzchołkami (bytami) i krawędziami (relacjami). Diagramy są rysowane w celu wizualizacji systemu z różnych perspektyw. Diagram jest w pewnym sensie jednym z rzutów układu. Z reguły, z wyjątkiem najbardziej trywialnych przypadków, diagramy przedstawiają skondensowany obraz elementów tworzących system. Ten sam element może występować na wszystkich diagramach lub tylko na kilku (najczęstsza opcja) lub nie występować na żadnym (bardzo rzadko). Teoretycznie diagramy mogą zawierać dowolną kombinację bytów i relacji. W praktyce jednak stosuje się stosunkowo niewielką liczbę standardowych kombinacji, odpowiadających pięciu najczęściej spotykanym typom składającym się na architekturę systemu informacyjnego. Zatem istnieje dziewięć typów diagramów w języku UML:

• diagramy klas;
• diagramy obiektów;
• diagramy przypadków użycia;
• diagramy sekwencji;
• schematy współpracy;
• diagramy stanu;
• diagramy aktywności;
• schematy komponentów;
• diagramy rozmieszczenia.

Oto częściowa lista diagramów używanych w języku UML. Narzędzia umożliwiają generowanie innych diagramów, ale dziewięć wymienionych to te, które najczęściej spotykasz w praktyce.

Reguły języka UML

Bloki konstrukcyjne UML nie mogą być ze sobą dowolnie łączone. Jak każdy inny język, UML charakteryzuje się zestawem reguł, które definiują, jak powinien wyglądać dobrze sformatowany model, czyli spójny semantycznie i zgodny ze wszystkimi modelami, które są z nim powiązane.

Język UML posiada reguły semantyczne, które pozwalają poprawnie i jednoznacznie zdefiniować:

• nazwy, które można nadać jednostkom, związkom i diagramom;
• zakres(kontekst, w którym nazwa ma jakieś znaczenie);
• widoczność(kiedy nazwy są widoczne i mogą być używane przez inne elementy);
• uczciwość(jak elementy powinny poprawnie i spójnie ze sobą współistnieć);
• wydajność(co oznacza wykonanie lub symulację jakiegoś modelu dynamicznego).

Modele tworzone w trakcie rozwoju systemów informatycznych ewoluują w czasie i mogą być różnie postrzegane przez różnych uczestników projektu w różnym czasie. Z tego powodu powstają nie tylko dobrze zaprojektowane modele, ale także takie, które:

• zawierają ukryte elementy (nie pokazano wielu elementów, aby uprościć percepcję);
• niekompletny (brakuje poszczególnych elementów);
• niespójne (integralność modelu nie jest gwarantowana).

Pojawienie się niezbyt dobrze zaprojektowanych modeli jest nieuniknione w procesie rozwoju, dopóki wszystkie szczegóły systemu nie zostaną w pełni wyjaśnione. Reguły UML zachęcają, ale nie wymagają, do rozwiązywania krytycznych problemów związanych z analizą, projektowaniem i wdrażaniem podczas pracy nad modelem, co z biegiem czasu skutkuje powstaniem dobrze sformułowanego modelu.

Ogólne mechanizmy UML

Budowa staje się łatwiejsza i wydajniejsza, jeśli przestrzegane są pewne konwencje. Kierując się określonymi wzorcami architektonicznymi, można zaprojektować budynek w stylu wiktoriańskim lub francuskim. Ta sama zasada dotyczy UML-a. Pracę z tym językiem znacznie ułatwia konsekwentne stosowanie ogólnych mechanizmów wymienionych poniżej:

• specyfikacje (Specyfikacje);
• dodatki (Ozdoby);
• wspólne podziały;
• Mechanizmy rozszerzalności.

Architektura

Aby wizualizować, określać, konstruować i dokumentować systemy informacyjne, należy je rozpatrywać z różnych punktów widzenia. Wszyscy zaangażowani w projekt — użytkownicy końcowi, analitycy, programiści, integratorzy systemów, testerzy, autorzy tekstów technicznych i kierownicy projektów — mają swoje własne zainteresowania i każdy inaczej postrzega budowany system na różnych etapach jego życia. Architektura systemu jest być może najważniejszym elementem, który służy do zarządzania wszystkimi możliwymi punktami widzenia, a tym samym ułatwia iteracyjny i przyrostowy rozwój systemu w całym jego cyklu życia.

Architektura to zbiór istotnych decyzji dotyczących:

• organizacja systemu oprogramowania;
• dobór elementów konstrukcyjnych tworzących system i ich interfejsów;
• zachowanie tych elementów określone we współpracy z innymi elementami;
• łączenie tych elementów strukturalnych i behawioralnych w coraz większe podsystemy;
• styl architektoniczny, który kieruje i określa całą organizację systemu: elementy statyczne i dynamiczne, ich interfejsy, współpracę i sposób ich łączenia.

Architektura systemu oprogramowania obejmuje nie tylko wszystkie aspekty strukturalne i behawioralne, ale także użytkowanie, funkcjonalność, wydajność, elastyczność, możliwość ponownego użycia, kompletność, ograniczenia i kompromisy ekonomiczne i technologiczne oraz kwestie estetyczne.

Widok z punktu widzenia precedensów Widok przypadków użycia obejmuje przypadki użycia, które opisują zachowanie systemu zaobserwowane przez użytkowników końcowych, analityków i testerów. Ten typ określa nie prawdziwą organizację systemu oprogramowania, ale siły napędowe, od których zależy tworzenie architektury systemu. W języku UML statyczne aspekty tego typu są przedstawiane za pomocą diagramów przypadków użycia, a aspekty dynamiczne za pomocą diagramów interakcji, stanów i działań.

Widok projektu(Widok projektu) obejmuje klasy, interfejsy i współpracę, które tworzą słownik problemu i jego rozwiązań. Widok ten wspiera przede wszystkim wymagania funkcjonalne systemu, czyli usługi, które musi świadczyć użytkownikom końcowym. Używając języka UML, statyczne aspekty tego typu można przekazać za pomocą diagramów klas i obiektów, a aspekty dynamiczne za pomocą diagramów interakcji, stanów i działań.

Widok procesu(Widok procesu) obejmuje wątki i procesy tworzące mechanizmy współbieżności i synchronizacji w systemie. Widok ten opisuje głównie wydajność, skalowalność i przepustowość systemu. W języku UML jego statyczne i dynamiczne aspekty wizualizowane są za pomocą tych samych diagramów, co w widoku projektowym, ale ze szczególnym uwzględnieniem aktywnych klas, które reprezentują odpowiednie wątki i procesy.

Widok wdrożenia Widok implementacji obejmuje komponenty i pliki użyte do zbudowania i wydania końcowego oprogramowania. Widok ten przeznaczony jest przede wszystkim do zarządzania konfiguracją wersji systemu składających się z (w pewnym stopniu) niezależnych komponentów i plików, które można ze sobą łączyć na różne sposoby. W UML tego typu aspekty statyczne są przedstawiane za pomocą diagramów komponentów, a aspekty dynamiczne za pomocą diagramów interakcji, stanów i działań.

Widok wdrożenia Widok wdrożenia obejmuje węzły tworzące topologię sprzętową systemu, na którym działa. Zajmuje się przede wszystkim dystrybucją, dostawą i instalacją części tworzących system fizyczny. Jego statyczne aspekty opisano za pomocą diagramów rozmieszczenia, a jego dynamiczne aspekty za pomocą diagramów interakcji, stanu i działania.

Każdy z wymienionych typów można uznać za całkowicie niezależny, dzięki czemu osoby zaangażowane w rozwój systemu mogą skupić się na badaniu tylko tych aspektów architektury, które ich bezpośrednio dotyczą. Nie możemy jednak zapominać, że gatunki te oddziałują na siebie. Na przykład węzły widoku wdrożenia zawierają komponenty opisane dla widoku implementacji, które z kolei reprezentują fizyczne wykonanie klas, interfejsów, kooperacji i klas aktywnych w widokach projektu i procesu. UML umożliwia wyświetlenie każdego z pięciu wymienionych widoków i ich interakcji.