WYKŁADY Flashcards
IO
Pełen opis przedmiotu z usosa
Inżynieria oprogramowania jest wiedzą techniczną dotyczącą wszelkich faz cyklu życia oprogramowania. Oprogramowanie traktowane jest jako konkretny produkt spełniający określone wymagania. Ustandaryzowany zbiór procedur i procesów stosowany podczas rozwiązywania problemów wynikłych w trakcie projektowania i wdrażania oprogramowania traktowanego jako nieodłączna część określonego systemu informatycznego nazywany jest metodyką tworzenia oprogramowania. Metodyki abstrahują od merytorycznego kontekstu danego obszaru, a skupiają się na metodach realizacji zadań związanych z zarządzaniem projektem informatycznym. Celem przedmiotu jest prezentacja wybranych metodyk tworzenia oprogramowania, metod analizy i projektowania systemów informatycznych, sposobów przygotowywania dokumentacji technicznej i użytkowej oraz sposobów testowania systemów i szacowania ich niezawodności. Zajęcia koncentrują się także na metodach weryfikacji i walidacji oprogramowania w całym cyklu wytwórczym, w tym na wykonywaniu testów funkcjonalnych i strukturalnych na różnych poziomach(moduł, system). W trakcie zajęć studenci poznają również język UML.
perspektywa przypadków użycia
opisuje zachowanie systemu z punku
widzenia użytkowników, analityków oraz osób wykonujących testy.
Zawiera zarówno elementy statyczne, opisane za pomocą diagramów
przypadków użycia, jak i dynamiczne, opisane za pomocą diagramów
przebiegu, kooperacji, stanów i czynności,
perspektywa projektowa
– uwzględnia opis klasy, interfejsów, sekwencji i
kooperacji, które razem składają się na opis danego problemu oraz jego
rozwiązanie. Elementy statyczne wyrażane są za pomocą diagramów klas i
obiektów, dynamiczne – za pomocą diagramów interakcji, stanów i
czynności
perspektywa procesowa
odzwierciedla mechanizm kreowania wątków i
procesów w systemie. Elementy statyczne i dynamiczne wyrażanie są za
pomocą diagramów klas, obiektów, interakcji, stanów i czynności, przy
czym główny nacisk kładzie się na klasy aktywne
perspektywa implementacyjna
– opisuje komponenty i artefakty, użyte do
scalenia i fizycznego udostępnienia systemu. Wiąże się ona z zarządzaniem
konfiguracją poszczególnych wersji systemu. Elementy statyczne wyrażanie
są za pomocą diagramów komponentów i artefaktów
perspektywa wdrożeniowa
opisuje węzły modelujące sprzęt, na którym
system będzie uruchomiony. Wiąże się ona głównie z rozmieszczeniem,
dostarczeniem i instalacją części systemu fizycznego. Aspekty statyczne
wyrażane są za pomocą diagramów wdrożenia
Diagram przypadków użycia
W najprostszym ujęciu użytkownik zwany aktorem jest reprezentantem
świata zewnętrznego. Aktor komunikuje się z systemem poprzez zdefiniowane
w jego obrębie przypadki użycia. Przypadek użycia jest dobrze określoną interakcją między użytkownikiem, a systemem komputerowym. Odwzorowuje
wybrane (lub wszystkie) funkcje systemu w sposób jaki będą je widzieć przyszli
użytkownicy.
Dziedziczenie przypadku użycia
Na rysunku 1.6 pokazano najprostszy schemat dziedziczenia, w którym
jeden przypadek użycia (p2) dziedziczy zachowanie innego (p1) i może
dodawać lub modyfikować część tego zachowania. Przypadki użycia mogą
pozostawać w relacjach zależności opisujących tzw. przebiegi podstawowe lub/i
opcjonalne.
Przebieg podstawowy
W przebiegu podstawowym (sekwencyjnym) p1 jest przypadkiem bazowym i zawsze występuje jako pierwszy w kolejności działania: p1 zawsze włącza (lub używa) p2. Stereotyp «include» wskazuje na wspólny fragment
wielu przypadków użycia wykorzystywanych w przebiegach podstawowych, w
których wszystkie operacje powinny być zawsze wykonywane.
Przebieg opcjonalny
W przebiegu opcjonalnym (alternatywnym) przypadek występujący jako
pierwszy w kolejności działania (p1) jest czasami rozszerzany o p2 (inaczej
mówiąc p2 czasami rozszerza p1). Stereotyp «extend» ze strzałką prowadzoną od przypadku użycia, który czasami rozszerza inny przypadek użycia
opisuje operacje nie zawsze wykonywane (opcjonalne).
Generalizacja
Generalizacja jest związkiem między klasą bazową (ang. base class), zwaną
przodkiem, a specyficznym jej rodzajem, zwanym potomkiem lub klasą
potomną lub pochodną (ang. derived class).
Generalizacja jest procesem przejmowania przez jeden obiekt właściwości
innego umożliwiając tym samym klasyfikowania obiektów. W UML opis klasy
najbardziej ogólnej (będącej na szczycie hierarchii generalizacji i niemającej
przodków) często uzupełnia się, dodając pod jej nazwą słowo {root}. Klasy
takie określa się mianem klas-korzeni. Opis klasy, która nie może mieć podklas,
często uzupełnia się słowem {leaf}. Generalizację oznacza
się linią ciągłą zakończoną niewypełnionym grotem skierowanym w kierunku
klasy bazowej (klasy pojęciowo niezależnej).
Zależność
Zależność jest związkiem strukturalnym wskazującym, że obiekty jednego
typu są funkcyjnie zależne od obiektów innego typu. Ogólnie powiemy, iż z
zależnością klas mamy do czynienia wówczas, gdy:
na liście argumentów funkcji składowej klasy występuje nazwa innej klasy,
na liście argumentów funkcji składowej klasy występuje wskaźnik do innej
klasy,
na liście argumentów funkcji składowej klasy występuje odwołanie (referencja) do innej klasy,
w ciele funkcji składowej klasy występuje zmienna, typu innej klasy,
w ciele funkcji składowej klasy występuje wskaźnik do innej klasy,
w ciele funkcji składowej klasy występuje odwołanie (referencja) do innej
klasy, Zależność między klasami dotyczy scenariusza, w którym jedna z klas w jakiś sposób używa obiektów innej klasy. Z reguły obiekty nie pamiętają o sobie (nie przechowują wzajemnych referencji, jak ma to miejsce w przypadku powiązania), a współpraca odbywa się jedynie na poziomie metod (np. metoda jednej z klas przyjmuje w argumencie referencję na obiekt innej klasy). Zależność oznacza się przerywaną linią z otwartym grotem. Grot powinien znajdować się po stronie klasy niezależnej (tej, której kod nie odwołuje się do drugiej klasy).
typem powrotnym funkcji składowej klasy jest wskaźnik do innej klasy. Na diagramie UML zależność oznacza się
linią przerywaną zakończoną strzałką zwróconą w kierunku klasy niezależnej,
Powiązanie
Powiązanie jest związkiem strukturalnym wskazującym, że obiekty jednego
typu są połączone z obiektami innego typu poprzez atrybuty danych klas. Zwykłe powiązanie między dwoma klasami wskazuje, że można przejść z obiektu
jednej z tych klas do obiektu drugiej i na odwrót. Można jednak jawnie wskazać
kierunek nawigacji. W UML powiązanie z kierunkiem oznacza się linią ciągłą
zakończoną otwartym grotem skierowanym w stronę elementu logicznie niezależnego. W UML dostępnych jest sześć podstawowych dodatków do powiązań: nazwa, rola, liczebności przy każdym końcu związku, nawigacja, kwalifikacja oraz
różne rodzaje agregacji, w tym również agregacje z nawigacją. Na poziomie implementacji określa się tak głównie sytuacje, w których jedna z klas zawiera w swoich polach referencję/wskaźnik na obiekt innej klasy. Powiązania mogą być jedno- lub dwustronne. Oznacza się je ciągłą linią z otwartym grotem wskazującym na kierunek powiązania (lub po prostu linią w przypadku powiązania dwustronnego).
Agregacja prosta
Powiązanie dwóch klas jest związkiem strukturalnym elementów równorzędnych, podkreślającym sytuację, w której powiązane klasy znajdują się na
tym samym poziomie pojęciowym. Czasami jednak zachodzi potrzeba zapisania
związku rodzaju „całość-część”. W takiej relacji jedna klasa reprezentuje większy element stanowiący całość, zaś druga reprezentuje elementy mniejsze, czyli
części, z których składa się całość. Agregacja jest szczególnym rodzajem powiązania. Agregację prostą
oznaczamy za pomocą rombu po stronie całości, Również mówimy tutaj o formie relacji części do całości, jednak na znacznie luźniejszych zasadach. Obiekty obu klas mogą istnieć niezależnie od siebie. W praktyce zwykle wiąże się to z sytuacją, w której jedna z klas zawiera modyfikowalną kolekcję obiektów innej klasy. Agregację oznaczamy ciągłą linią z pustym rombem po stronie całości.
Agregacja całkowita
Agregacja całkowita (kompozycja) to związek charakteryzujący się relacją
wyłącznej własności oraz jednością czasu życia całości i części. Proces konstrukcji całości musi być poprzedzony skonstruowaniem wszystkich jej elementów składowych (części nie mogą powstawać po utworzeniu całości, ale w
momencie gdy destrukcji podlega całość muszą zginąć wszystkie jej części). W
przypadku agregacji prostej część może zależeć od kilku całości, zaś w przypadku kompozycji tylko od jednej. Agregację całkowitą oznaczamy symbolem diamentu (wypełnionym rombem) umieszczonym po stronie całości. Tutaj mówimy o sytuacji, w której jedna z klas stanowi nieodłączną część składową innej. Czas życia obiektów obu klas jest ściśle powiązany - obiekty są tworzone i usuwane w tym samym czasie (stworzenie całości wymaga stworzenia części składowej; usunięcie całości z pamięci pociąga za sobą usunięcie części składowej). Kompozycję oznacza się za pomocą ciągłej linii z zamalowanym grotem w kształcie rombu. Grot znajduje się po stronie klasy reprezentującej całość.
Liczebności powiązań
W praktyce, w trakcie modelowania różnych odmian powiązania zachodzi
potrzeba podania liczebności, czyli liczby (krotności) obiektów jaka może być
przyłączona przez jeden egzemplarz powiązania. W UML liczebność zapisywana jest w postaci wyrażenia, którego wartością jest dobrze określony przedział liczbowy lub pojedyncza liczba. Podając liczebność przy jednym końcu
powiązania wskazujemy ile obiektów jednej klasy powinno być połączonych z
każdym obiektem klasy znajdującej się na drugim końcu powiązania. Liczebność można ustalić poprzez wyszczególnienie żądanej liczby, np.: 5, przedziału
liczbowego 1..5 (jeden lub pięć), dowolnie wiele (0..) albo co najmniej dwa
(2..)
Struktury i typy wyliczeniowe
Częściami składowymi modelu mogą być takie elementy, jak struktury i
typy wyliczeniowe. Elementy te z reguły będą agregować z klasami, do których
przekazują swoją zawartość w postaci parametrów. Na rysunku 1.28 pokazano
możliwe oznaczenia agregującej struktury oraz typu wyliczeniowego. Stereotyp «enumeration»
Diagram czynności
Diagramy czynności wykorzystywane do modelowania operacji są bardzo
podobne do używanych dawniej schematów blokowych. Zawartość diagramów
czynności może być przedstawiona w sposób ogólny lub szczegółowy. Elementami szczegółowego diagramu czynności dla modelowanej operacji są pojedyncze kroki obliczeniowe, instrukcje decyzyjne oraz rozgałęzienia. Na diagramach
czynności wyróżniamy punkt startowy, który jest reprezentowany przez czarne
wypełnione koło oraz punkt końcowy przedstawiany w postaci kółka z czarna
kropką w środku.
Diagram obiektów
Obiekty na diagramach mogą tworzyć związki strukturowe, uczestnicząc w
wiązaniach (połączeniach) lub agregacjach. Wiązania są egzemplarzami powiązań i dlatego mogą być charakteryzowane poprzez podanie nazwy, kierunku
działania, roli i właściwego stereotypu. Wiązanie to odpowiednik powiązania
klas, występujący pomiędzy obiektami. Oznaczamy je za pomocą linii ciągłej,
Diagram stanów
Diagramy stanów obrazują sposób, w jaki elementy modelu zmieniają w
czasie swoje własności w odpowiedzi na różnego rodzaju zdarzenia i interakcje.
Podstawowym elementem tego typu diagramów jest ikona stanu, która może być
przedstawiona w sposób uproszczony, poprzez podanie nazwy stanu, lub w sposób szczegółowy, z dodatkowym wyszczególnieniem wartości atrybutów oraz
podstawowych, aktualnie wykonywanych operacji i zdarzeń, Symbol stanu oznaczany jest prostokątem z zaokrąglonymi
narożnikami. Czarne kółko oznacza punkt wejścia do stanu, strzałka jest symbolem przejścia, zaś kółko z czarną kropką (tzw. bycze oko) oznacza punkt wyjścia ze stanu
Diagramy sekwencji (przebiegu)
Diagramy klas są doskonałym narzędziem do prezentowania struktury
logicznej aplikacji. Są głównym elementem modeli opartych na UML, co sprawiło, że są bardzo popularne i powszechnie stosowane. Jednak ze stosowaniem
tego typu diagramów wiążą się poważne problemy:
diagramy klas nie są wstanie wymodelować dynamicznego zachowania
programu – jego zmian w czasie,
diagramy klas ilustrują jeden poziom hierarchii elementów składowych
oprogramowania. Dobrze zaprojektowany program powinien poddawać się
dekompozycji hierarchicznej. Klasy i obiekty są podstawą tej dekompozycji.
Operatory interakcji dla diagramu sekwencji
alt (alternative) - określający warunek wykonania bloku operacji,
odpowiadający instrukcji if-else; warunek umieszcza się wówczas wewnątrz
bloku w nawiasach kwadratowych,
opt (optional) - reprezentujący instrukcję if (bez else),
par (parallel) - nakazujący wykonać operacje równolegle,
critical - blok atomowy, oznaczający obszar krytyczny o najwyższym
priorytecie wykonania. Obiekty nie mogą uczestniczyć w innych zadaniach.
loop - definiujący pętlę typu for (o określonej z góry liczbie iteracji) lub
while (wykonywanej dopóki pewien warunek jest prawdziwy),
break - wykonanie fragmentu i zakończenie interakcji,
neg – funkcjonalności nieprawidłowe – wskazuje na wyjątki, które muszą
zostać obsłużone,
strict – ścisłe uporządkowanie komunikatów,
seq - słabe uporządkowanie dotyczy komunikatów z kilku lini mogących
wystąpić w dowolnym porządku,
ignore – komunikaty nie mają istotnego wpływu na całość komunikacji,
consider – istotność – komunikaty muszą zostać wykonane.
Techniki tworzenia diagramów sekwencji:
*ustalenie otoczenia (operacje, przypadki użycia, itp.)
*zidentyfikowanie obiektów biorących udział w operacji (od lewej umieszczane
są obiekty najważniejsze).
*narysowanie linii życia obiektów (jeśli są tworzone i niszczone - dodanie
odpowiednich komunikatów).
*dodanie komunikatu inicjującego, kolejne komunikaty pod nim (dodanie
parametrów do komunikatów (jeżeli jest to wymagane)).
*dodanie aktywacji (ośrodka sterowania).
Diagramy sekwencji (przebiegu): Wskazówki
*nazwy aktorów są spójne z diagramami przypadków użycia.
*nazwy obiektów są spójne z diagramami klas.
*po lewej stronie umieszczaj aktorów zewnętrznych dla systemu.
*po prawej stronie umieszczaj aktorów, którzy są wewnętrzni dla systemu.
*po lewej stronie umieszczaj aktorów, którzy są systemami inicjującymi
interakcją z modelowanym.
*aktor może mieć taką samą nazwę jak klasa.
*jeżeli jest to niezbędne - umieszczaj komunikat niszczenia (destroy) obiektu.
*umieszczaj nazwę obiektu jeżeli występuje odwołanie do niej w komunikacie.
*umieszczaj nazwę obiektu jeżeli istnieje wiele obiektów tej samej klasy.
*jeżeli umieszczono kilka obiektów o tej samej nazwie, muszą pochodzić z
różnych klas.
*przy aktorach i obiektach/klasach umieszczaj stereotypy informujące o
warstwie systemu, w której one działają.
*umieszczaj tylko najważniejsze komunikaty.
*jeżeli komunikat jest wysyłany do obiektu/klasy, który jest implementowany
jako składnik oprogramowania (klasa, interfejs, komponent), nazywaj
komunikat z użyciem składni języka programowania.
*jeżeli komunikat wymaga przekazania parametrów, podaj ich nazwy, a nie
same typy danych.
*komunikaty wychodzące od aktorów, którzy są osobami lub organizacjami,
nazywaj w sposób opisowy (zdaniem).
*komunikaty przesyłane do klas (nie obiektów) implementowane są jako metody
statyczne
*przy włączaniu innych przypadków użycia do aktualnie modelowanego stosuj
komunikaty ze stereotypem «include»
*komunikat tworzący obiekt oznaczaj stereotypem «create»
*aktywacja nie jest obowiązkowym elementem linii życia, ale ułatwia
zrozumienie diagramu - podkreśla czas trwania danej operacji
