Ten wykład poświęcony będzie językowi UML i metodologii projektowania systemów informatycznych, która jest dość silnie oparta i silnie związana ze znanym nam już choć z zarysu koncepcyjnego podejściem, metodologią obiektową. Pyzatym od razu zwróćmy uwagę na pewien fakt . Otóż język UML nie tylko jest wykorzystywany przy projektowaniu systemów informatycznych, ale także do innych systemów nie mających nic wspólnego z informatyką. Często używany jest do opisania i projektowania skomplikowanej sieci powiązanych ze sobą działań - pewne przedsięwzięcia o charakterze ekspedycyjnym, transportowym, produkcyjnym. Pomimo, że mówimy słowo "język" to jego elementami jest 9 diagramów, które definiują koncepcje i poszczególne fazy projektowania systemu.

UML - najbardziej popularna metodologia tworzenia obiektów systemu informatycznych(przydatna najbardziej na etapie projektowania).
Słów kilka na temat metodologii

• Metodologia wspomaga modelowanie dziedziny problemowej stanowiącej przedmiot projektowania systemu.
• Metodologia dostarcza szeregu pojęć modeli, diagramów, języków technik i sposobów postępowania
• Metodologia jest wykorzystywana zarówno do projektowania pojęciowego jak i logicznego czy fizycznego
• Metodologia ustala fazy realizacji projektu a ponadto dla każdej z faz projektu wyznacza:
  1. Role uczestników projektu.
  2. Scenariusze postępowania.
  3. Reguły przechodzenia do następnej fazy.
  4. Modele które powinny być wytworzone.
  5. Dokumentacji która powinna powstać.
  6. Notacje której należy używać.

Podczas projektowania systemu informatycznego ważną role odgrywa notacja.
Notacja - służy do dokumentowania wyników poszczególnych faz projektu, zarówno pośrednich jak i końcowych. Wspomaga ludzką pamięć i wyobraźnie. Jest ważnym elementem metodologii. Właściwa notacja ułatwia komunikację, zarówno między członkami zespołu projektowego, jak i między zespołem projektowym a klientem. Każda notacja, która nie jest "tą właściwą" może zrodzić wiele problemów!

Do podstawowych pojęć związanych z metodologia obiektowa zaliczamy:
Obiekt - podstawowe pojęcie w podejściu obiektowym. Reprezentuje sobą konkretny pojedynczy byt. Jest charakteryzowany przez:

• identyfikator (nazwę)
• stany (wartości atrybutów obiektu)
• zachowanie (operacje obiektu)

Zachowanie może zmieniać stan obiektu, od którego pochodzi i/lub stany innych obiektów.

Klasa a obiekt.
Klasa - reprezentuje zbiór obiektów, które dzielą strukturę i wspólne zachowanie. Operacje i atrybuty są definiowane jednorazowo, w klasie. O obiektach, które należą do danej klasy, mówi się, że są instancjami tej klasy. Instancje zawierają określone własne (czasem nawet określone jako "prywatne") wartości atrybutów klasy i współdzielą operacje klasy. Zachowanie instancji jest więc jednolite.
Enkapsulacja - jest techniką, w której dane są przechowywane w obiektach razem z operacjami, jakie można na nich wykonać. Jedynym sposobem dotarcia do danych ukrytych wewnątrz kapsuły jest użycie operacji należącej do powłoki kapsuły ,która za zadanie ma wykonać stosowną operacje na danych. Eliminuje to ryzyko niepoprawnego użycia danych obiektu, ponieważ operacje na nich zawsze wyłącznie "autoryzowane".
Polimorfizm - jest techniką, w której ukrywa się szczegóły implementacji we wspólnym interfejsie. Polimorfizm upraszcza komunikację między obiektami.

Model obiektowy oprócz klas i obiektów uwzględnia związki między nimi:

• Związek zależności (Dependency) - oznacza wykorzystanie jednego obiektu przez drugi. Najczęściej dotyczy sytuacji użycia jednego obiektu, jako argumentu w operacji drugiego obiektu.
• Związek generalizacji (Generalization) - relacja między jedną klasą, a klasami będącymi jej udoskonalonymi wersjami. Każda podklasa dziedziczy cechy swojej nadklasy.
• Związek asocjacyjny (Association) - oznacza grupę więzi o wspólnej strukturze i znaczeniu.
  Więzi - to połączenie jakie istnieje między instancjami. Najważniejszą z cech ego związku jest jego typ, wyróżniony ze względu na liczność wystąpienia instancji w związku.

TYPY ASOCJACJI

• jeden do jeden - tylko jedna instancja może mieć tylko jedną więź w danym związku,
• jeden do wielu - instancja może mieć wiele więzi w danym związku. Jedna instancja która jest z nią powiązana nie może mieć więzi więcej niż jedną,
• wiele do wielu - wiele więzi w danym związku.

SPECJALNE TYPY ASOCJACJI

• Agregacja - relacja typu całość - część. Jeden element składa się z innych elementów. Jest relacją antysymetryczną. Oznacza to, że element-całość zawiera element-część, lecz elementy-części nie mogą zawierać elementu całości.
  (Przykład: linia a punkt - linia składa się z punktów. Punkty nie zawierają lini. Ponadto punkt może być współdzielny z wieloma liniami.)
• Kompozycja - silniejsza forma agregacji. W agregacji element - części mogą być wykorzystane przez inne elementy. Często także się dzieje, że z chwilą zniszczenia elementu całości ulega zniszczeniu element - część. Jednak w kompozycji żaden element - część nie może być dzielony.
  (Przykład: samochód a silnik - samochód zawiera silnik, który jak wiemy może być wykorzystywany tylko przez jeden samochód jednocześnie.)

Bardziej znane wcześniejsze metodologie i notacje obiektowe:

• Martin\Odell
• OODA, Booch
• OMT, Rumbaugh
• OOSA, Shlaer-Meller
• Objectory, Jacobson
• OOA/OOD, Coad/Yourdon

Każda metodologia miała swoje mocne i słabe strony. OMT było mocne w analizie, ale słabsze w projektowaniu. OODA na odwrót itd. Język UML powstał jako powszechnie oczekiwana unifikacja.

UML:

• jest językiem do specyfikacji, wizualizacji, konstrukcji i dokumentowania projektów związanych z systemami informacyjnymi, intensywnie wykorzystującymi oprogramowanie, a także do modelowania biznesowego wszelkich innych systemów (przede wszystkim  wizualizacja i grafy)
• oferuje standaryzowany sposób zapisu projektu, obejmującego zarówno jego konceptualne aspekty, takie jak procesy biznesowe czy funkcje systemu, jak też i elementy fizyczne (np. schematy baz danych)
• zapewnia:
  • Semantykę i notację dotyczącą szerokiej gamy współczesnych aspektów modelowania
  • Semantyka w kontekście modelu. Ujmuje aspekty strukturalne (technologia komponentów przetwarzanie rozproszone, szkielet), wykonalności, modelowania, które są przewidywane w przyszłości.
  • Semantykę adresującą określone aspekty modelowania, które są przewidywanie w przeszłości.
  • Mechanizmy rozszerzalności, tak aby poszczególne zespoły projektowe mogły rozszerzać język dla potrzeb ich aplikacji przy zmniejszonym wysiłku.
  • Semantykę ułatwiającą wymianę danych modelu pomiędzy wieloma narzędziami CASE.

ISTOTNYMI SKŁADNIKAMI UML SĄ DIAGRAMY, wyróżnić możemy:

• Diagramy strukturalne:
  • diagram klas (ile, jakich i jak powiązanych klas trzeba stworzyć)
  • diagram komponentów (cechy fizyczne, lokalizacja itp.)
• Diagramy behawioralne:
  • diagram przypadków użycia (jak wykorzystujemy klasy, komponenty)
  • diagram sekwencji (kolejność)
  • diagram aktywności

W sumie jednak diagramów używanych w tej metodologii jest więcej. Pełne zestawienie diagramów wykorzystywanych w UML obejmuje:

• diagram przypadków użycia
• diagram klas
• diagram obiektów
• diagram sekwencji
• diagram współpracy
• diagram stanów
• diagram aktywności
• diagram komponentów
• diagram wdrożeniowy

Tworząc diagramy trzeba zadbać o właściwy stopień ich szczegółowości:

• Diagram Przypadków Użycia obrazuje w jaki sposób aktorzy (np. ludzie) mogą wykorzystać system. Jego głównym celem jest odwzorowanie funkcji projektowanego systemu w taki sposób, jak będą je widzieć jego użytkownicy.
  Produkt: autor, przypadek użycia, związek
• Diagram Klas obrazuje statyczną strukturę systemu wykorzystując klasy i ich relacje.
  Produkt: klasa, związek
• Diagram Obiektów obrazuje statyczną strukturę systemu wykorzystując obiekty (instancje) i ich relacje.
  Produkt: obiekt, związek
• Diagram Sekwencji obrazuje kolejność w czasie wysyłania komunikatów pomiędzy różnymi obiektami w systemie.
  Produkt: obiekt, komunikat, linia życia obiektu
• Diagram Współpracy obrazuje przepływy komunikatów. Funkcjonowanie i przepływy między obiektami, obrazuje sposób współpracy grupy obiektów w celu.
  Produkt: obiekt, komunikat, związek
• Diagram Stanów obrazuje strony w których może znaleźć się dany obiekt.
  Produkt: stan, przejście
• Diagram Aktywności przedstawia akcje wykonywane przez system (sekwencje - jedna po drugiej, równolegle - niezależnie).
  Produkt: akcja, warunek decyzyjny
• Diagram Komponentów przedstawia komponenty które składają się na aplikacje . Elementy budujące system i ich powiązania, publiczne interfejsy - postrzeganie klasy z zewnątrz, jak widziane jest miejsce do którego docierała komunikaty.
  Produkt: komponent, zależność
• Diagram Wdrożeniowy obrazuje architekturę systemu. Prezentuje sposób rozmieszczenia komponentów w określonej konfiguracji sprzętowej.
  Produkt: węzeł, asocjacja, komunikacja, instancja komponentów.

CASE (Computer-Aided Software Engineering Tools)
Zalety uzywania CASE do tworzenia modeli w UML:

• ponowne wykorzystanie - stworzony model można ponownie wykorzystać.
• wiele perspektyw - prezentacje gotowego modelu można dostosować do wymaganej sytuacji; Na przykład można wykorzystać określone elementy bez ich usuwania.
• automatyczne generowanie kodu - automatyczna translacja jest mniej podatna na błędy.
• sprawdzenie poprawności modelu - zdefiniowane reguły biznesowe i ograniczenia.
• szybkie tworzenie modelu - tworzenie modelu ze źródeł programu.