1. Różnica między interfejsem dostarczonym i wymaganym. Proszę podać przykłady.

Interfejs jest to zestaw operacji, które wyznaczają usługi oferowane przez klasę lub komponent. Interfejsy służą do prezentowania komunikacji pomiędzy komponentami. Interfejs wyznacza granicę między specyfikacją tego, co dana abstrakcja ma robić, a implementacją tego, jak to robi. Dobrze zbudowany interfejs charakteryzuje się tym, że wyraźnie oddzielone są wewnętrzne aspekty abstrakcji od zewnętrznych.

W UML 2.0 wprowadzono rozróżnienie pomiędzy interfejsami:

interfejs dostarczany (provided interface)

interfejs wymagany (required interface)

Każda klasa może być wykorzystywana na różne sposoby i może realizować różne interfejsy (różne usługi). Grupowanie usług klasy realizuje się za pomocą portów.

Porty łączą implementację klasy ze środowiskiem, w którym istnieje.

Komunikacja klasy odbywa się poprzez porty.

Interfejs dostarczany są to usługi które klasa implementuje.

Klasa umożliwia innym elementom systemu korzystanie z obsługiwanych przez daną klasę usług.

Dwie postacie interfejsu dostarczanego:

Interfejs jest definicją usług oferowanych przez klasę lub komponent.

Interfejs wymagany są to usługi, które inne klasy muszą dostarczyć w celu zapewnienia odpowiedniego funkcjonowania klasy w środowisku.

Interfejs wymagany są to usługi, które inne klasy muszą dostarczyć w celu zapewnienia odpowiedniego funkcjonowania klasy w środowisku.

1. Podstawowe zasady obiektowości. Wymienić i krótko scharakteryzować.

Obiektowość, orientacja obiektowa – sposób definiowania programów za pomocą obiektów oraz klas. Podejście obiektowe jest zbliżone do procesu ludzkiego myślenia stad upraszcza ono proces projektowania, tworzenia oraz wprowadzania zmian w systemie [programowanie obiektowe].

Obiektowość można także wykorzystać podczas analizy [analiza obiektowa].

?*Obiektowosc powstała z potrzeby łatwiejszego sposobu symulowania systemów – nie tylko

symulowania systemów informatycznych, lecz dowolnych rodzajów systemów.

? Obiektowosc dostarcza metode do tworzenia dowolnych systemów – niezaleznie od tego, jak te

systemy beda implementowane. Ponadto tej samej obiektowej specyfikacji mozna uzyc w wielu

innych dziedzinach, niezaleznie od tego czy dotycza one ludzi, maszyn lub komputerów.

Podstawowe koncepcje obiektowości

? abstrakcja – odfiltrowanie atrybutów i operacji nieistotnych

? enkapsulacja – ukrycie nadmiernego poziomu szczegółowości

? dziedziczenie – generalizacja

⊲ relacja hierarchiczna

⊲ oszczednosc nakładów modelowania

? polimorfizm – wielosc form operacji dla dziedziczonych klas

⊲ wirtualny mechanizm wywoływania funkcji

⊲ naturalny system wyrazania czynnosci

⊲ zmniejszenie nakładów programowania.

1. Rodzaje komunikatów – podać przykłady.

Komunikat przesyłany między obiektami biegnie od linii życia obiektu wysyłającego do linii życia obiektu docelowego. Obiekt może też wysłać komunikat sam do siebie – od swojej linii życia do swojej linii życia.

Komunikat może być: prosty, synchroniczny lub asynchroniczny. Komunikat prosty jest przekazaniem sterowania od obiektu do obiektu. Jeśli jakiś obiekt wysyła komunikat synchroniczny, oczekuje potem odpowiedzi na ten komunikat i dopiero po jej otrzymaniu przechodzi do dalszych własnych działań. Po wysłaniu komunikatu asynchronicznego obiekt kontynuuje własne działania bez oczekiwania na odpowiedź.

Na diagramie przebiegu komunikat prosty jest oznaczany strzałką z dwustronnym grotem otwartym, komunikat synchroniczny – strzałką z dwustronnym grotem pełnym, a komunikat asynchroniczny – strzałką z jednostronnym grotem otwartym.

1. Co to jest metodyka. Omówić składowe metodyki ETHICS.

Metodyka, czyli zestaw pojęć, oznaczeń, języków, modeli, diagramów, technik i sposobów postępowania służących realizacji procesu. Metodyka definiuje fazy realizacji przedsięwzięcia informatycznego, a ponadto dla każdej z faz wyznacza:

1. Role uczestników projektu

2. Scenariusze postępowania

3. Reguły przechodzenia do następnej fazy

4. Produkty, które powinny być wytworzone, m.in. Modele, kod, dokumentację

5. Notację, czyli zbiór oznaczeń, które należy wykorzystywać do dokumentowania wyników poszczególnych faz projektu.

Metoda Effective Technical and Human Implementation of Computer Systems - efektywna techniczna i społeczna realizacja systemów komputerowych powstała w 1996, jej autor Enid Mumford z Manchester Business School.

Mumford wyróżniła trzy poziomy udziału użytkownika:

1. Uczestnictwo na zasadzie konsultacji - podejmowanie decyzji pozostaje w rękach analityków, ale na każdym poziomie dużą rolę odgrywa personel.

2. Uczestnictwo na zasadzie reprezentacji - grupa projektowa składa się z przedstawicieli personelu wszystkich szczebli i analityków systemowych. Przedstawiciele wybierani są przez kierownictwo.

3. Uczestnictwo na zasadzie ugody - przedstawiciele są wybierani przez personel i mają uprawnienia komunikowania decyzji personelowi.

Celem ETHICS jest projektowanie nowego sposobu organizacji pracy przy jednoczesnym spełnieniu podwójnego celu: poprawianie zadowolenia z pracy (system społeczny) oraz wydajności pracy (system techniczny).

Kroki metody:

1. Diagnozowanie potrzeb technicznych i ludzkich - zbieranie i analizowanie danych kwestionariuszowych. Dane te służą do określenia związków miedzy obecną sytuacją w pracy a dopuszczalną sytuacją wyznaczoną przez typologię potrzeb. Określenie celów dotyczących zadowolenia z pracy (zapewnienie różnorodności pracy i zachęt do wydajności) i cele efektywnościowe (poprawa obsługi klientów).

2. Ustalenie zakresu technicznych i społecznych możliwości. Ocena zalet i wad każdej możliwości pod względem społecznym i technicznym.

3. Nadanie rangi każdej technicznej i społecznej możliwości pod względem jej zdolności do realizacji celów społecznych i technicznych. Wybór możliwości o najwyższej randze.

4. Opracowanie szczegółowego projektu społeczno-technicznego.

Mumford analizuje zamówienia klientów i system księgowy, które zbadano przy zastosowaniu podejścia ETHICS i na tej podstawie opracowano nowe systemy społeczny i techniczny.

Podstawowy system techniczny obejmuje pracowników działu zamówień, wypełniających formularze zamówień, pracowników księgowości aktualizujących księgę główną. Problemy są rozwiązywane drogą przekazywania dużej liczby papierów. System społeczny pokazuje różnicę między pracownikami działu zamówień i księgowości. Każdy z pracowników księgowości pracuje na wielu kontach różnych klientów, a problemy są rozwiązywane przez dwóch urzędników starszych rangą.

Motywacje zmian mają tu charakter zarówno techniczny, jak i społeczny. Przykładami kłopotów technicznych są niewłaściwie wypełnione zamówienia, niewłaściwe księgowania na kontach, nieefektywne metody rozwiązywania problemów. Przykłady kłopotów społecznych obejmują dużą absencję, dużą rotację kadr i pewien „wandalizm przemysłowy”.

1. Istota modelowania analitycznego.

Zainteresowanie językiem UML doprowadziło do powstania nowych diagramów lub rozszerzenia znaczenia już istniejących. Przyczyniają się one do zwiększenia jakości, przejrzystości oraz szczegółowości procesu tworzenia systemów przy wykorzystaniu języka UML i na podstawie metodyki RUP. Do najbardziej znanych i użytkowanych w praktyce technik należą:

diagramy modelowania analitycznego,

diagramy modelowania biznesowego.

Modelowanie analityczne to technika wspomagająca język UML, która służy do dokumentowania wyników prac analitycznych i wczesnych prac projektowych.

Diagramy modelowania analitycznego wspomagają dyscyplinę analizy i projektowania; zostały zaproponowane przez Ivara Jacobsona. W praktyce diagramy te umożliwiają przejście od diagramów przypadków użycia oraz ich scenariuszy do diagramów klas oraz diagramów interakcji na poziomie konceptualnym (dotyczącym pojęć) i implementacyjnym.

Diagramy modelowania analitycznego stanowią:

-element pośredni i opcjonalny w procesie tworzenia systemu

-minimalizują lukę semantyczną pomiędzy zrozumiałą dla większości odbiorców terminologią przypadków użycia a technicznymi aspektami projektu systemu informatycznego.

Konsekwentne posługiwanie się diagramami modelowania analitycznego jako pomocą w specyfikowaniu wymagań opartą na przypadkach użycia zwiększa prawdopodobieństwo wiernego przeanalizowania i odzwierciedlenia przyszłej funkcjonalności tworzonego systemu. Osiąga się to poprzez analizę scenariuszy danego przypadku użycia.

Model analityczny (ang. analysis model), grupujący diagramy analityczne, można traktować jako rodzaj wstępnego projektu. Jego celem jest wspomaganie identyfikacji klas. Podstawowymi elementami diagramów modelowania analitycznego są:

*klasy analityczne,

*aktorzy,

*związki.

Diagramy analityczne modelowane są jako diagramy klas z zastosowaniem trzech stereotypowanych klas:

granicznych (ang. boundary),

sterujących (ang. control),

przechowujących (ang. entity).

Podczas analizy scenariuszy przypadku użycia identyfikuje się obiekty analityczne.

Podczas projektowania systemu ulegają przekształceniu w różne kategorie modelowania właściwe dla poziomu implementacyjnego, takie jak atrybuty klas, operacje lub same klasy.

Kategorie modelowania analitycznego w literaturze przedmiotu określane są często mianem obiektów analitycznych.

Proces tworzenia modelu analitycznego

Tworzenie diagramów modelowania analitycznego poprzedzone jest w ramach iteracyjno‑przyrostowego procesu RUP modelowaniem biznesu oraz specyfikacją wymagań tworzonego systemu w postaci systemowych diagramów przypadków użycia. Stąd proces ten można podzielić na następujące etapy:

wyselekcjonowanie, stosownie do złożoności dziedziny przedmiotowej odpowiednich:

diagramów modelu biznesowego,

diagramów przypadków użycia oraz ich scenariuszy,

przeniesienie aktorów z diagramów przypadków użycia na diagramy analityczne,

identyfikację klas analitycznych i określenie ich rodzajów,

integrację poszczególnych zidentyfikowanych elementów w formie diagramów analitycznych składających się na model analityczny.

W trakcie procesu tworzenia modelu analitycznego obowiązują określone zasady konwersji z modeli biznesowych i systemowych diagramów przypadków użycia na kategorie diagramów modelowania analitycznego.

Analogicznie, należy zauważyć, że sporządzenie klas analitycznych na podstawie systemowych przypadków użycia nie polega na bezpośredniej zamianie notacji. Konwersja systemowego modelu przypadków użycia na modele analityczne obejmuje przekształcenie aktorów w klasy graniczne bądź ich bezpośrednie przeniesienie. Natomiast przypadki użycia są przekształcane w odpowiednie rodzaje klas analitycznych – graniczne, sterujące i przechowujące. W dalszych iteracjach RUP klasy analityczne przekształcane są w klasy systemu.

Diagram analityczny zamieszczony na poprzednim slajdzie jest wysokopoziomową specyfikacją przypadku użycia rejestracji uczestnika na aukcji internetowej. Diagram ten zawiera dwóch aktorów:

Uczestnika aukcji,

System Poczty Elektronicznej,

oraz osiem klas analitycznych:

Ofertę Aukcji,

Rejestrację,

Formularz,

Walidację Danych,

Autoryzację,

Aktywację Sprzedaży,

Bazę Danych,

Pocztą.

Opis diagramu

Aktor Uczestnik, chcąc uzyskać prawo do aktywnego uczestnictwa w licytacjach oraz wystawiania artykułów na licytację, musi zarejestrować się w systemie aukcji internetowej. Wykorzystuje w tym celu obiekt klasy granicznej Oferta Aukcji, który uruchamia Formularz rejestracyjny poprzez obiekt klasy sterującej Rejestracja.

Po wprowadzeniu danych następuje ich walidacja. Za realizację tej operacji odpowiada obiekt sterujący o nazwie Walidacja Danych. Poprawne dane zostają zapisane do bazy danych reprezentowanej przez obiekt przechowujący Baza Danych.

Następnie Uczestnik zamierzający uzyskać prawa sprzedającego loguje się do systemu. Wykorzystuje w tym celu login i hasło uzyskane po wypełnieniu Formularza. Analityczny obiekt sterujący Aktywacja Sprzedaży generuje kod sprzedaży, zapisuje go w obiekcie przechowującym Baza Danych i wysyła drogą elektroniczną wiadomość do rejestrującego się Uczestnika.

Wiadomość jest wysyłana przez System Poczty Elektronicznej, który nie jest integralną częścią systemu aukcji internetowej. Pośredniczącą instancją klasy granicznej jest w tym przypadku obiekt graniczny Poczta. Jest on wyspecjalizowanym modułem pozwalającym na obsługę elektronicznych wiadomości w systemie aukcji internetowej.

1. Co to metodyka(odp. w pyt 5). Omów metodykę RUP.

Metodyka RUP obejmuje cały cykl życia projektu:

*analizę

*projektowanie

*zapewnianie jakości w kolejnych iteracjach

*rozwoju systemu

Perspektywy – punkty widzenia różnych grup użytkowników

Zakłada, że oprogramowanie będzie tworzone w cyklach -- każdy z tych cykli dostarcza kolejną

wersję oprogramowania.

Cykl życia oprogramowania można podzielić na następujące etapy: - Rozpoczęcie (Inception)

- Opracowanie(Elaboration)

- Konstruowanie (Constuction)

- Przekazanie (Transition)

Każdy z etapów kończy się wytworzeniem odpowiedniego artefaktu.

Faza Rozpoczęcia:

Wypracowanie ogólnej wizji przedsięwzięcia oraz osiągnięcie zrozumienia i akceptacji projektu ze

strony wszystkich jego uczestników.

Faza opracowania

Ustalenie architektury systemu, stworzenie planu projektu oraz wyeliminowanie elementów

wysokiego ryzyka z projektu.

Faza budowania

Stworzenie systemu na podstawie przyjętej architektury. W tej fazie odbywa się większość prac

programistycznych.

Faza przekazania

W tej fazie produkt przekazywany jest od zespołu programistycznego do użytkowników końcowych.

W tej fazie znajdują się takie czynności jak: trening użytkowników końcowych i administratorów,

testy akceptacyjne (testy beta).

Metodyka RUP wyróżnia następujące fazy wytwarzania oprogramowania:

- Modelowanie biznesowe:

Celem jest przede wszystkim zapewnienie komunikacji i lepsze zrozumienie pomiędzy biznesem

a IT (inżynieria oprogramowania). Inżynierowie oprogramowania muszą zrozumieć strukturę i

dynamikę organizacji swojego klienta, jego bieżące problemy i możliwe usprawnienia.

- Wymagania:

opracowanie wizji systemu, modelu PU i zdefiniowanie wymagań niefunkcjonalnych

- Analiza i projektowanie:

celem jest zobrazowanie sposobu w jaki będzie tworzony system w fazie implementacji. Tworzy

model projektowy i opcjonalnie model analityczny systemu.

- Programowanie:

pozwala na opracowanie kodu źródłowego w wybranym języku programowania

- Testowanie:

oznacza planowanie testów oraz ocenę systemu poprzez wykonanie szeregu testów

- Wdrożenie:

dotyczy instalacji oprogramowania systemu i formalną akceptację kolejnych wersji systemu przez

klienta

- Konfiguracja i zarządzanie zmianami:

obejmuje kontrolę wersji artefaktów opracowanych podczas kolejnych iteracji

- Zarządzanie projektem:

oznacza planowanie i kontrolę realizacji projektu

- Określenie środowiska:

obejmuje przygotowanie infrastruktury dla skutecznej realizacji projektu. Istotę modelowania

analitycznego

1. Cykl życia projektu(systemu) i omówienie metody spiralnej.

Pojęcie cyklu życia systemu oraz wady i zalety modelu spiralnego.

Cykl życia systemu (ang. business system life cycle) jest to strukturalne podejście do zadania

opracowania systemu dla przedsiębiorstwa.

Tradycyjny model cyklu życia systemu

analiza potrzeb → specyfikacja systemu → projektowanie → programowanie → testowanie →

integracja → adaptacja i modyfikacja → eksploatacja → dezektualizacja

Poszczególne etapy następują po sobie po sobie w określonej, zstępującej sekwencji,

Każdy etap powinien być zakończony przed rozpoczęciem następnego,

Model spiralny:

Zalety:

- Do dużych systemów - szybka reakcja na pojawiające się czynniki ryzyka

- Połączenie iteracji z klasycznym modelem kaskadowym

Wady:

- Trudno do niego przekonać klienta

- Konieczność umiejętności szacowania ryzyka

- Problemy, gdy źle oszacujemy ryzyko

1. Szacowanie ryzyka. Rodzaje zagrożeń w projekcie informatycznym

Zagrożenia projektowe mogą spowodować przekroczenie terminów lub budżetu, które mogą mieć

negatywny wpływ na postęp prac. Także wielkość i złożoność systemu stanowią o wielkości

ryzyka projektowego.

Zagrożenia techniczne wpływają na jakość produktów i ich terminowość. Pod czas tego zagrożenia

stworzenie oprogramowania okaże się trudne lub niemożliwe. Problemy te mogą być trudniejsze do rozwiązania niż to się wcześniej wydawało.

Zagrożenia ekonomiczne mogą utrudnić osiągnięcie rynkowego sukcesu oprogramowania.

Pięć najważniejszych takich zagrożeń to:

● powstanie doskonałego produktu, którego nikt nie potrzebuje

● powstanie produktu, który nie odpowiada ludziom

● powstanie produktu, którego firma nie będzie umiała sprzedać,

● utrata zainteresowania kierownictwa

● zmniejszenie budżetu lub liczby pracowników

Niektórych zagrożeń po prostu nie da się przewidzieć. Zagrożenia znane to te, które można wykryć na podstawie dokładnej analizy środowiska, w którym będzie powstawał produkt. Przykładami takich zagrożeń są:

nierealistyczny termin ukończenia prac,

niedoskonałe środowisko tworzenia aplikacji.

Zagrożenia przewidywalne można odgadnąć, analizując przebieg poprzednich przedsięwzięć.

Przykładami takich zagrożeń są:

rotacja personelu,

nieskuteczna komunikacja z klientem,

Zagrożenia nieprzewidywalne to zdarzenia losowe, które bardzo trudno przewidzieć.

1. Różnica między obiektem, a klasą.

Klasa

Opis grupy obiektów o jednolitym zbiorze atrybutów i sposobie zachowania

Zawiera opis tworzenia obiektów klasy

Klasę można nazwać „fabryką obiektów”

Każda klasa posiada „wzorzec” (plany) dla tworzenia obiektów tej klasy.

Każdy nowo tworzony obiekt klasy posiada osobną tożsamość, a także może mieć różne wartości atrybutów.

Obiekty w czasie swojego życia kontaktują się z innymi obiektami. Kontakty polegają na wzajemnym korzystaniu z udostępnianych usług. W trakcie modelowania określamy związki między klasami obiektów.

Podstawowy „model świata” w podejściu obiektowym stanowi zatem zbiór klas obiektów wraz z odpowiednimi związkami między nimi.

Dowolny obiekt jest instancją abstrakcyjnego pojęcia, jakim jest klasa (ang. class) obiektu. Podstawę identyfikacji klasy stanowią grupy obiektów charakteryzujące się:

identyczną strukturą danych tj. takimi samymi atrybutami;

identycznym zachowaniem tj. takimi samymi operacjami;

identycznymi związkami;

identycznym znaczeniem w określonym kontekście.