Egzamin Inżynieria Oprogramowania

1. Procesy wytwórcze informatyczne (fazy, przepływy prac, jak wygląda)

Proces wytwórczy stosuje się by zaplanować, przeanalizować problem i go odpowiednio zaprojektować, zakodować, przetestować i wdrożyć i na końcu konserwować.

Podstawowa zasada: poprawny proces daje poprawny produkt, ale wybór procesu zależy od produktu.

1. Proszę nazwać procesy wytwórcze które znamy

   1. Wersja sensowna:

• Model kaskadowy

• Model iteracyjny

• Model z prototypowaniem

• Model spiralny

• Model przyrostowy

• Transformacje formalne

• RUP

• Model V

  1. Wersja pełna według jego chorego wykładu:

• Wodospadowy proces wytwórczy (kaskadowy)

• Paradygmat prototypowania

• Formalna specyfikacja w języku Z

• Model spiralny (Boehm)

• Model przyrostowy

• Model iteracyjny

• Paradygmat ewolucyjny

• Prototypowanie z wyrzucaniem

• Prototypowanie Ewolucyjne

• Model Liniowy z prototypowaniem

• Model procesu transformacji formalnych

• Model procesu montażu z gotowych elementów

• Proces RUP (Rational Unified Process)

  1. Proszę scharakteryzować jeden z wybranych procesów (tych wyżej)

Model Wodospadowy (Kaskadowy)

Model ten polega na przechodzeniu kolejnych etapów po kolei i ewentualnym cofaniu się do dowolnego wcześniejszego etapu na etapie konserwacji systemu, jeśli się cofnęliśmy to musimy przejść proces do końca po kolei od danego etapu. Kolejne fazy nie nakładają się w czasie. Proces ten jest bardzo naturalny, ułatwia planowanie i kontrolę rozwoju projektu, wadami są wysokie koszta błędów podczas analizy, brak możliwości natychmiastowej reakcji na zmiany wymagań.

1. Proszę wytłumaczyć różnicę między poszczególnymi procesami wytwórczymi

Model kaskadowy – jak wyżej

Model iteracyjny – stopniowe dochodzenie do rozwiązania, poprzez przeprowadzanie w kółko tych samych faz projektowania, na końcu każdego cyklu powstaje produkt działający

Model prototypowania – tworzymy prototypy czyli oprogramowanie które będzie podstawową do tworzenia produktu końcowego

Model przyrostowy – dzielimy problem na mniejsze i sukcesywnie rozbudowujemy, a następnie łączymy w całość

Model spiralny – polega na powtarzanych fazach planowania, analizy rynku, konstruowania i atestowania ze stopniową rozbudową systemu

Transformacje formalne – opierają się na dowodzeniu twierdzeń w językach formalnych

RUP – oparty na przypadkach użycia, składa się z: rozpoczęcie -> opracowanie -> budowa -> przekazanie

Model V – podobny do kaskadowego, testowanie przeprowadza się równolegle do innych prac

1. Po co potrzebny proces wytwórczy i gdzie go możemy zobaczyć w dokumentacji

Procesy wytwórcze służą do przewidywania potrzeb i optymalizacji kosztów wytwarzania oprogramowania, pozwalają skracać czas potrzebny na wykonanie projektu oraz sprawować kontrolę nad wytwarzaniem oprogramowania. Pozwalają dzielić pracę, pozwalają analizować możliwości ponownego użycia, promują powtarzalność procesów i pracę w zespole. Najlepszym przykładem dokumentacji zawierającej proces wytwórczy jest dokument wizji zawierający odpowiednie diagramy UML oraz opracowania odnoszące się do kosztów procesu.

1. Zarządzanie ryzykiem

   1. Proszę opowiedzieć ogólny algorytm zarządzania ryzykiem (z jakich kroków, jak wypełnić tabelkę)

Zarządzanie zagrożeniami koncentruje się na identyfikacji zagrożeń i minimalizowaniu ich wpływu na przedsięwzięcie . Zagrożenie jest prawdopodobieństwem, wystąpienia niesprzyjających okoliczności i.

Czynność RUP:

Zagrożenie	Typ	Opis
Rotacja personelu	Przedsięwzięcie	Doświadczony personel opuści przedsięwzięcie przed końcem.
Zmiana zarządzania	Przedsięwzięcie	Będą zmiany w organizacji zarządzania i priorytetach.
Niedostępność sprzętu	Przedsięwzięcie	Sprzęt nie będzie dostarczony na czas.
Zmiana wymagań	Przedsięwzięcie i produkt	Liczba zmian będzie większa niż oczekiwana.
Opóźnienia specyfikacji	Przedsięwzięcie i produkt	Specyfikacja podstawowych interfejsów nie nadejdzie na czas.
Niedoszacowanie rozmiaru	Przedsięwzięcie i produkt	Niedoszacowano rozmiaru systemu.
Niewydajność narzędzi CASE	Produkt	Narzędzia CASE nie działaja tak sprawnie jak oczekiwano.
Zmiana technologii	Przedsiębiorstwo	Technologia w której buduje się system będzie zmieniona na nową.
Konkurencja dla produktu	Przedsiębiorstwo	Konkurencyjny produkt pojawi się na rynku przed ukończeniem naszego.

• Identyfikacja zagrożeń dla projektu, produktu i przedsiębiorstwa

• Analiza zagrożeń . Ocena prawdopodobieństwa i konsekwencji zagrożeń.

• Planowanie przeciwdziałania zagrożeniom . Opracowanie planów radzenia sobie z zagrożeniami poprzez ich unikanie lub minimalizację skutków

• Monitorowanie zagrożeń . Ustawiczne monitorowanie wszystkich zagrożeń.

Algorytm postępowania z zagrożeniami:

Identyfikacja zagrożeń

• Zagrożenia technologiczne

• Zagrożenia ze strony ludzi

• Zagrożenia organizacyjne

• Zagrożenia narzędziowe

• Zagrożenia szacowania

Analiza zagrożeń

• Przypisz prawdopodobieństwo i konsekwencje do każdego z zagrożeń .

• Prawdopodobieństwo może być bardzo małe, małe, średnie, duże lub bardzo duże.

• Konsekwencje zagrożenia mogą być katastroficzne, poważne, znośne lub nieistotne

Planowanie przeciwdziałania zagrożeniom

• Dla każdego z zagrożeń wybierz jakąś strategię

• Strategie unikania

  • Prawdopodobieństwo zdarzenia się zmniejsza

• Strategie minimalizacji

  • Konsekwencji zagrożenia na przedsięwzięcie lub produkt się zmniejsza

• Plany awaryjne

  • Jeśli zagrożenie się spełni to należy zastosować plan awaryjny

Monitorowanie zagrożeń

• Sprawdzaj czy zagrożenie staje się bardziej czy mniej prawdopodobne

• Sprawdzaj równie czy konsekwencje są bardziej czy mniej poważne

• Każde z zagrożeń powinno być omówione na każdym spotkaniu menedżerskim

Ryzyko

1. Identyfikacja

2. Analiza

3. Planowanie reakcji

4. Monitorowanie nowych

5. Kontrola istniejących

1. Szacowanie nakładów pracy, kosztów przedsięwzięcia

   1. Proszę nazwać metody szacowania kosztów przedsięwzięcia (jakie rodzaje)

   • Algorytmiczne modelowanie kosztów (formuła na podstawie historii)

   • Ocena ekspertów

   • Szacowanie przez analogię

   • Prawo Parkinsona (wszystko zostanie zużyte)

   • Ustalanie ceny pod zwycięstwo

   1. Scharakteryzować czym jest COCOMO 2 (podstawowa część)

Model szacowania liczby osobogodzin w procesie tworzenia oprogramowania. Polega na ustaleniu metryki (ilości linijek kodu), następnie złożoności przedsięwzięcia. Na podstawie określonych metryk i wzorów obliczane są koszta przedsięwzięcia.

1. Jaka jest podstawowa różnica pomiędzy 1. 2. i 3. poziomem COCOMO 2

• Poziom wczesnego prototypowania

  • Podstawą oszacowań są punkty obiektowe

• Poziom wczesnego projektowania

  • Podstawą oszacowań są punkty funkcyjne przeliczane na linie kodu

• Poziom post-architektoniczny

  • Podstawą oszacowań jest rozmiar kodu

1. Proszę podać ogólną charakterystykę metody punktów funkcyjnych

Oparte na połączeniu następujących elementów programu:

• Zewnętrzne wejścia i wyjścia

• Interakcje z użytkownikiem

• Interfejsy zewnętrzne

• Pliki używane przez system

Z każdym elementem jest skojarzona waga (3-15)

Liczba punktów funkcyjnych jest wyznaczana na podstawie sumy wag elementów systemu. Punkty funkcyjne powinny uwzględniać czynnik skomplikowania przedsięwzięcia. Punkty funkcyjne mogą służyć do szacowania liczby linii kodu:

LLK = SLLK * liczba punktów funkcyjnych

SLLK zależy od języka i waha się od 200-300 dla asemblera do 2-40 dla języków czwartej generacji

PF są subiektywne i zależą od szacującego, nie można policzyć punktów funkcyjnych automatycznie.

1. Charakterystyka z innych (po jednym zdaniu)

Punkty obiektowe:

Liczba punktów obiektowych jest ważoną sumą:

• Liczby rożnych wyświetlanych ekranów

• Liczby raportów generowanych przez system

• Liczby modułów 3GL tworzonych dla wsparcia modułów 4GL

Miara linii kodu:

• Miara została zaproponowana, gdy programiści dziurkowali karty

• Ma się to nijak do programów w nowoczesnych językach programowania

Szacunki produktywności

• Szacowanie wydajności zespołu w realizowanych liniach kodu / punktach miar

1. Wymagania

   1. Jak wygląda zarządzanie wymaganiami, co to jest, jakie podstawowe kroki, przepływ pracy (dyscyplina pracy)

Zarządzanie wymaganiami jest skupione na zaspokojeniu oczekiwań użytkowników końcowych systemu poprzez identyfikację i specyfikację ich potrzeb oraz wykrywanie zmiany tych wymagań.

Zarządzanie wymaganiami składa się z następujących czynności:

Analiza problemu - uzgodnienie problemu i stworzenie miar, które dowiodą jego istotności dla klienta.

Zrozumienie potrzeb udziałowców (stakeholders) (brak odpowiedniego słowa w języku polskim) - są to odbiorcy i użytkownicy oprogramowania na różnych szczeblach w organizacji, w innych metodykach zarządzania projektami nazywa się ich Interesariuszami) - konsultacja problemu i jego wartości z głównymi udziałowcami (stakeholders) i rozpoznanie w jaki sposób koncepcja rozwiązania zaspokaja ich potrzeby.

Definicja systemu - tworzenie projektu funkcjonalności na podstawie potrzeb użytkowników, identyfikacja przypadków użycia - które prezentują ogólne wymagania (high-level requirements) i użyteczność modelu systemu.

Zarządzanie zakresem systemu (Scope Management) - modyfikowanie zakresu prac nad systemem bazując na analizie wymagań, wybór kolejności realizacji (atakowania) przypadków użycia.

Zawężanie definicji systemu - uszczegóławianie scenariuszy przypadków użycia razem z użytkownikami systemu w celu stworzenia dokładnej specyfikacji wymagań (Software Requirements Specification - SRS), która może służyć (i na ogół służy) jako umowa pomiędzy wykonawcą systemu a klientem. Na podstawie dokumentu SRS tworzony jest projekt systemu oraz scenariusze testów.

Zarządzanie zmianami wymagań - zarządzanie zmianami wymagań lub nowozidentyfikowanymi wymaganiami w czasie trwania projektu.

Przepływ / organizacja pracy

• Rozmowa i pytania

Zadawanie dowolnych pytań pozwala do końca zrozumieć idee, o co komu tak naprawdę chodzi, rozwiać wszelkie wątpliwości.

• Requirements workshops

Projekt szczegółowych informacji, które mogą obejmować projekt wymagań,
dokumenty, listy punktowe proponowanych funkcji, kopie wywiadów
z potencjalnymi użytkownikami, analityczne raporty dotyczące trendów w branży,
listy od klientów, raporty o błędach od istniejącego systemu i tak dalej.

• Burza mózgów

• Storyboards (rozrysowanie kadrów)

Powinno być używane w każdym oprogramowaniu, którego sukces zależy od pierwszej reakcji użytkownika. Polega na 'przewidywaniu' typowych reakcji: Wyróżniamy:

• pasywne (pokazywanie na obrazkach, slajdach)

• aktywne (kiedy to te obrazki się ruszają)

• interaktywne (gdy sami wcielamy się w odpowiednie role)

  • Odgrywanie ról

  • Use cases

  • Prototypownie

  1. Czym jest przypadek użycia i określić podstawowe związki

Czym jest przypadek użycia:

• Przypadek użycia modeluje „dialog” - interakcję między użytkownikiem a systemem w postaci sekwencji prostych kroków.

• Jest inicjalizowany przez aktora w celu przywołania niektórych funkcjonalności systemu.

• Jest kompletnym i znaczącym przepływem zdarzeń.

• Traktowane razem - wszystkie przypadki użycia stanowią wszystkie możliwe sposoby korzystania z systemu.

• Powinien być pozbawiony szczegółów dotyczących implementacji oraz interfejsu użytkownika.

• Opisuje w jaki sposób system powinien być używany przez użytkownika.

• Odwzorowują strukturę systemu tak, jak ją widzą jego użytkownicy.

Podstawowe związki:

(poszczególne przypadki użycia są powiązane za sobą w pewien sposób tworząc jakby całość opisu systemu)

Każdy aktor, który jest na diagramie przypadków użycia musi być bezpośrednio powiązany z co najmniej jednym przypadkiem użycia. Podobnie każdy przypadek użycia musi być użytkowany co najmniej przez jednego aktora (niejednokrotnie są to powiązania pośrednie).

• Asocjacja - wystąpienie dwukierunkowej komunikacji pomiędzy przypadkiem użycia a aktorem. Jeśli komunikacja ta przebiega tylko w jednym kierunku, można kierunek ten zaznaczyć strzałką. W przypadku diagramów użycia, związkom nie nadaje się nazw.

• Zawieranie - zawierany przypadek użycia nie jest wykonywany samodzielnie. Związek zawierania ma postać przerywanej strzałki ze stereotypem <<include>>, biegnącej od przypadku użycia zawierającego do zawieranego. Związku zawierania używa się wówczas, gdy z kilku innych przypadków użycia można wydzielić pewną część wspólną.

• Rozszerzanie - Związek ten pozwala na wydzielenie przypadku użycia, który w pewnych sytuacjach może zostać wzbogacony o dodatkowe opcje. Wygląda on tak samo jak związek zawierania, jednak ma stereotyp <<extend>>. Często gdy chcemy rozszerzyć system o pewną funkcjonalność już w trakcie realizacji - nie wolno w nim nic zmieniać - po to jest związek rozszerzania, aby dodać coś nowego bez zmiany pozostałych przypadków.

• Uogólnienie - Jak sama nazwa wskazuje, ma on na celu uogólnienie aktorów bądź przypadków użycia, przy czym obiekt uogólniany posiada wszystkie cechy obiektu ogólnego. Uogólnienie ma postać strzałki z linią ciągłą i zamkniętym grotem.

1. Jak realizować przypadki użycia i jak to się robi

• Po co są przypadki użycia: OKREŚLENIE WYMAGAŃ

• NIE określają JAK, ale CO system realizuje.

• Nazewnictwo: zaleca się, aby przypadki użycia nazywać czynnościami, które je opisują w trybie rozkazującym, np.: "Zarejestruj użytkownika".

• Nazwa powinna określać jego przeznaczenie

• Nie umieszczać zbyt wielu związków, a złożone przypadki rozbić na osobne diagramy.

• W MIARĘ CORAZ LEPSZEGO ROZUMIENIA WYMAGAŃ STAWIANYCH SYSTEMOWI PRZECHODZI SIĘ DO DIAGRAMÓW INTERAKCJI. Zwykle jest to jeden diagram przebiegu przedstawiający główny ciąg zdarzeń oraz warianty tego diagramu definiujące ciągi nadzwyczajne.

Omawiany tu przypadek użycia (Zatrudnij pracownika) w istocie opisuje zbiór ciągów, z których każdy reprezentuje jeden z możliwych przebiegów przez wszystkie te warianty. Każdy taki ciąg nosi nazwę scenariusza. Scenariusz jest pewnym szczególnym ciągiem akcji, który ilustruje specyfikowane zachowanie. Scenariusze są dla przypadków użycia tym, czym dla klas obiekty, to znaczy są egzemplarzami przypadków użycia.

Należy utworzyć zestawy klas i innych bytów, których współpraca doprowadzi do implementacji danego przypadku użycia. Te zestawy bytów, włącznie z ich strukturą statyczną i dynamiczną, można zamodelować w UML w postaci kooperacji.

1. Proces biznesowy

   1. Zadania i cel

Proces biznesowy – seria powiązanych ze sobą działań lub zadań, które rozwiązują określony problem lub prowadzą do osiągnięcia określonego efektu. Proces biznesowy wynika z potrzeb klientów a jego wynikiem jest zaspokojenie tych potrzeb.

Celem modelowania biznesowego jest:

• zrozumienie bieżących problemów w docelowej organizacji i określenie potencjałów udoskonalenia,

• ocena wpływu zmiany w organizacji,

• zapewnienie, że klienci, użytkownicy, inwestorzy oraz inne strony będą rozumieć organizację w ten sam sposób,

• wyprowadzenie wymagań systemu oprogramowania, które jest konieczne, aby wspierać docelową organizację,

• zrozumienie jak system oprogramowania, który ma być wykorzystywany w przyszłości, wpasowuje się w organizację.

Schemat organizacyjny nie jest wystarczający, aby zrozumieć działanie firmy. Potrzebujemy również dynamicznego widoku przedsiębiorstwa. Model biznesowy zapewnia statyczny widok konstrukcji organizacji i dynamiczny widok procesów w obrębie organizacji.

1. Na czym polega

Proces biznesowy polega na określeniu części systemu i ich interakcji ze sobą oraz z użytkownikiem w celu stworzenie oprogramowania, w tym celu stosuje się odpowiednie modelowanie poprze diagramy np. UML.

1. Podstawowe diagramy UML w procesie biznesowym (analizy)

Diagram przypadków użycia

Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu informacji, dlatego też zawsze potrzebna jest do niego dokumentacja w postaci dobrze napisanego przypadku użycia. Przypadki użycia są bardzo ważnym narzędziem zbierania wymagań. Diagramy przypadków użycia, mimo swojej prostoty, są bardzo przydatne, gdyż tworzą swojego rodzaju spis treści dla wymagań modelowanego systemu.

Diagram klas

Diagram klas jest ściśle powiązany z projektowaniem obiektowym systemu informatycznego lub wręcz bezpośrednio z jego implementacją w określonym języku programowania. Elementami tego diagramu są klasy, reprezentowane przez prostokąty, które mogą zawierać informację o polach i metodach klasy.

Klasa:

Atrybuty i ich oznaczenia:

• + publiczny

• #chroniony

• - prywatny

• ~publiczny wewnątrz pakietu

0 … 1 – krotność użycia

<<instantiate>> - instancja

Statyczne składowe oznaczone są poprzez podkreślenie

<<exception>> - metoda może zwracać wyjątki

<<call>> - wywołanie operacji

<<create>> - tworzy instancję innej

<<use>> - używa

- Agregacja (istnieje niezależnie, relacja całość-część)

- kompozycja (zarządzalne czasowo, relacja całość- część)

- uogólnienie (to do czego jest skierowana strzałka to ogólna klasa)

<<realizes>> -wymagany interfejs

- klasa abstrakcyjna po lewej tego

<<bind>> - szablony klas

strzałka w kierunku szablonu

Diagram współpracy (diagram komunikacji od UML 2.0)

Diagram współpracy jest jednym z czterech diagramów interakcji. Używamy go po to, żeby zobrazować dynamikę systemu – wzajemne oddziaływanie na siebie obiektów oraz komunikaty, jakie między sobą przesyłają.

Diagram przebiegu (sekwencji)

Analogiczną informację do diagramu komunikacji zawiera drugi z diagramów interakcji, diagram przebiegu. Diagram komunikacji koncentrował się na zobrazowaniu współpracy między obiektami, teraz chcemy pokazać kolejność przesyłania komunikatów i czas istnienia obiektów.

Można grupować komunikaty w bloki posiadające określone właściwości, np.: critical, par (parallel), loop (pętla).

Czas na diagramie płynie w dół; prostokąty narysowane wzdłuż przerywanej linii oznaczają czas życia obiektu, z którego wychodzi linia.

 

Diagram stanów (diagram maszyny stanowej w UML 2.0)

Diagramy interakcji mówiły nam o zachowaniu obiektów, diagram stanów z kolei służy do tego, by pokazać w jakich stanach mogą być obiekty. Poniżej widzimy diagram stanów obiektu dane:

Dane mogą znajdować się w różnych stanach, które są oznaczone zaokrąglonymi prostokątami. Linie ze strzałkami oznaczają przejścia między stanami. Na diagramie widzimy także przypadek, kiedy istnieją dwie alternatywne drogi przejścia między stanami. Rozwidlenie, podobnie jak scalenie dwóch ścieżek przebiegu zmian stanów jest zaznaczone na diagramie pogrubioną poziomą kreską.

Diagram aktywności (czynności)

Diagram aktywności jest pewną mutacją diagramu stanów, z tą różnicą, że diagram aktywności skupia się raczej na opisaniu jakiegoś procesu, w którym uczestniczy wiele obiektów, zaś diagram stanów pokazuje, jakie są możliwe stany konkretnego obiektu. Diagram aktywności jest bardzo dobrym narzędziem, gdy chcemy przedstawić odpowiedzialność obiektów w ramach jakiegoś procesu.

Na diagramie zaokrąglone prostokąty reprezentują konkretne zadania, które powinien wykonać system (bądź jego elementy), rombami zaznaczamy miejsca, w których są podejmowana decyzje, wynikające z efektów wykonania jakiegoś zadania. Pogrubione poziome linie oznaczają miejsca, w których pewne czynności wykonywane są jednocześnie.

Diagram pakietów

Diagram pakietów służy do tego, by uporządkować strukturę zależności w systemie, który ma bardzo wiele klas, przypadków użycia itp. Przyjmujemy, że pakiet zawiera w sobie wiele elementów, które opisują jakieś w miarę dobrze określone zadanie. Na diagramie umieszczamy pakiety i wskazujemy na zależności między nimi. Dzięki temu dostajemy na jednym diagramie obraz całości, bądź dużego fragmentu, systemu.

Na powyższym diagramie widzimy poszczególne pakiety grupujące elementy systemu (np. klasy) odpowiedzialne za konkretne zadania. Przerywane linie ze strzałkami pokazują zależności między pakietami.

Diagram komponentów

Diagram komponentów służy do podziału systemu na prostsze elementy i pokazaniu zależności między nimi. Diagram ten dzieli system na fizyczne elementy oprogramowania: pliki, biblioteki, gotowe, wykonywalne programy itp.

Na diagramie mamy przedstawione komponenty systemu wraz z interfejsami, które one udostępniają. Udostępniane interfejsy są zaznaczone kółkami, podczas gdy interfejsy, których dany komponent wymaga do swojego działania, są oznaczone półokręgiem – gniazdem. Na przykład DB Menadżer udostępnia interfejsy do różnych baz danych, natomiast Aplikacja.exe wymaga wskazania takiego interfejsu.

Diagram strukturalny (composite structures) (UML 2.0)

Diagram strukturalny jest przeznaczony do tego, by modelować współpracę klas, interfejsów, komponentów, które są zaangażowane w pewne zadanie. Diagram ten jest nieco podobny do diagramu klas, z tą różnicą, że diagram klas przedstawia statyczny obraz fragmentu systemu, a diagram strukturalny obrazuje elementy systemu wykonujące wspólne zadanie, typowe sposoby użycia elementów systemu, związki między tymi elementami, które może być trudno przedstawić na innych diagramach.

Na diagramie poniżej widzimy typowy sposób przedstawienia związku między fakturą a jej częściami:

Diagram ten może w zupełności wystarczyć, jednak ma on pewną wadę. Może się okazać, że wcale nie chcemy, aby Naglowek i Dane były oddzielnymi klasami – chcemy tylko podkreślić fakt, że Faktura składa się z takich części jednak bez potrzeby specyfikowania detali. Właśnie w takim przypadku pomocny jest diagram strukturalny:

Inny sposób pokazania związku strukturalnego kilku klas można osiągnąć używając elementu współpracy (collaboration):

Elipsa narysowana przerywaną linią oznacza element współpracy, z którym połączone (lub wewnątrz którego leżą) współdziałające klasy.

Innym możliwym zastosowaniem diagramu strukturalnego jest połączenie jego z diagramem przypadku użycia, który jest przez niego realizowany:

Diagram opisu interakcji (interaction interview)

Diagram opisu interakcji jest swego rodzaju połączeniem diagramu aktywności i diagramu przebiegu (lub innego diagramu pokazującego dynamikę systemu). Zadaniem tego diagramu jest wizualizacja współpracy ze sobą diagramów interakcji.

Diagram przeglądu interakcji ma notację bardzo podobną do notacji diagramu aktywności (czynności), z tą różnicą, że zaokrąglone prostokąty, które reprezentowały zadania wykonywane przez system, są zastąpione przez zwykłe prostokąty, które mogą mieć dwie postacie:

Prostokąt zawiera jakiś diagram interakcji – diagram współpracy (komunikacji), diagram przebiegu, diagram przebiegów czasowych lub inny diagram przeglądu interakcji.

Prostokąt zawiera odnośnik do już istniejącego diagramu interakcji. Obecność odnośnika jest zaznaczona słowem ref w lewym górnym rogu diagramu

Diagram przebiegów czasowych

Diagram przebiegów czasowych obrazuje zachowanie obiektu z naciskiem na dokładne określenie czasu, w którym obiekt jest poddawany jakimś zmianą lub sam wykonuje jakieś działanie.

Powyżej widzimy przykładowy diagram przebiegów czasowych. Są dostępne dwie notacje: czasowa (wyżej) i zadaniowa (niżej), w obu przypadkach diagram ma oczywiście to samo znaczenie.

Diagram wdrożenia

Diagram wdrożenia pokazuje, jak będzie wyglądało wdrożenie i konfiguracja naszego oprogramowania.

1. Wytłumaczyć jak zorganizować w projekcie przejścia z modelu biznesowego na model wymagań funkcjonalnych (na UML)

Aktorów systemu, jak i systemowe przypadki użycia można wyprowadzać z modelu biznesowego. Pracownikowi biznesowemu przyporządkowuje się relewantnego aktora w systemie, a biznesowemu przypadkowi użycia, w którym pracownik biznesowy uczestniczy - relewantny systemowy przypadek użycia.

Odpowiedzialności związane z pracownikami biznesowymi zostają przeniesione na aktorów systemowych. Encje biznesowe - z kolei - są kandydatami na obiekty klas w systemie.

Automatyzacja procesów biznesowych może pociągać za sobą zmianę modelu biznesowego: każdy pracownik biznesowy i każda encja powinny być implementowane przez jeden rodzaj zasobów.

1. Jakie są korzyści z diagramów

Diagramy służą do obrazowania systemu, jego budowy i przepływu informacji w nim zawartych, pokazują jakie czynności będą realizowane przez system, pomagają w porozumiewaniu się między programistami różnych języków programowania, obrazują system jako całość – poglądowo.

1. Diagramy dynamiczne UML, cele i korzyści płynące z wykorzystania

• Przypadków użycia (ang. use case diagram)

• Aktywności (ang. activity diagram)

• Interakcji (diagram abstrakcyjny)

  • Sekwencji (ang. sequence diagram)

  • Komunikacji (ang. communication diagram)

  • Harmonogramowania (lub Zależności czasowych) (ang. timing diagram)

  • Sterowania interakcją

Cele: modelowanie dynamicznych części systemu, wpływu bytów na siebie

Korzyści: usunięcie problemów przepływu danych, wyszukanie i wyodrębnienie funkcji systemu.

1. Wyjaśnić diagramy klas co to jest, podstawowe oznaczenia UML na diagramach klas i wytłumaczyć jak przekształcić diagramy klas w kod (znaleźć odpowiednik)

MDA jest podejściem, w którym UML jest traktowany jako język programowania. Głównym celem MDA jest tworzenia oprogramowania w oparciu o modele biznesowe oraz separacja modelu na zależny oraz niezależny od platformy. Dzięki MDA te same rozwiązania mogą być realizowane na wielu różnych platformach. Ponadto stworzone na bazie MDA systemy mogą być łatwo integrowane oraz łączone z innymi systemami. Nic nie stoi też na przeszkodzie aby ponownie używać opracowane rozwiązania.

Wyróżnia się cztery poziomy w MDA, ale najczęściej stosowane to:

• Platform Independent Model (PIM), który można traktować jako abstrakcyjną specyfikację systemu, gdyż nie jest na tym poziomie wskazana konkretna platforma na której zostanie osadzone tworzone rozwiązanie,

• Platform Specific Model (PSM), który jest modelem o najniższym poziome abstrakcji, odwzorowanym na konkretne rozwiązania wybranej platformy.

1. Architektura systemu

   1. Co oznacza architektura systemu i czym są wzorce architektoniczne, nazwać rodzaje wzorców architektonicznych

Architektura to zbiór istotnych decyzji dotyczących:

• Organizacji systemu oprogramowania.

• Wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany, razem z ich zachowaniami opisanymi w kooperacjach

• Składanie tych elementów w coraz większe podsystemy

• Stylu architektonicznego, według którego tworzy się konstrukcję systemu, to znaczy charakterystyczne elementy i ich interfejsy, od którego zależy kooperacja i składanie

Jej zadania (po co tak naprawdę jest):

• Przedstawienie logicznej organizacji systemu

• Zorganizowanie zestawu funkcji systemu

• Rozwiązanie zagadnień współbieżności

• Opisanie fizycznego rozmieszczenia oprogramowania na zastosowanej platformie

Dlaczego architektura jest tak ważna (przeznaczenie):

• Umożliwia właściwe składanie części systemu w jedną działającą całość

• Inspiruje tworzenie oprogramowania oparte na komponentach*

• Daje podstawę do zarządzania przedsięwzięciem

*Komponent jest niebanalną, wymienialną częścią systemu, która

spełnia jasno wyznaczoną funkcję w ramach dobrze określonej

architektury. Komponent pasuje do pewnego zbioru interfejsów i

zapewnia ich fizyczną realizację.

Wzorzec architektoniczny (ang. Architectural pattern) – w inżynierii oprogramowania jest to uznany i sprawdzony sposób rozwiązania danego problemu z zakresu architektury oprogramowania. Wzorce architektoniczne określają ogólną strukturę danego systemu informatycznego, elementy z jakich się składa, zakres funkcjonalności realizowany przez dany element jak również zasady komunikacji pomiędzy poszczególnymi elementami.

Wzorce architektoniczne:

• Multi tier architecture – Architektura wielowarstwowa

• Three tier architecture – Architektura trójwarstwowa

• Model-View-Controler (MVC) – Model-Widok-Kontroler

• Presentation-abstraction-control

• Blackboard system

• Service Oriented Architecture (SOA) – Architektura zorientowana na usługi

• Peer-to-peer (P2P)

• Implicit invocation – Wywołanie niejawne

• Pipeline

• Naked objects

  1. Jak sprawdza się poprawność wybranej architektury przy projektowaniu systemów informatycznych

Poprawność systemów informatycznych sprawdza się poprzez testowanie – scenariusze testowe, czyli przewidywanie działań na systemie i problemów z nich wynikających.

1. Wzorce projektowe

   1. Czym są wzorce, dlaczego są potrzebne, wymienić rodzaje

Wzorzec projektowy to koncepcja opisująca problem, który powtarza się wielokrotnie, a następnie opisuje modelowe rozwiązanie tego problemu, w taki sposób, żeby można było to rozwiązanie wykorzystywać wiele razy, tak, że żadne dwa wykorzystania nie będą identyczne.

Wzorzec projektowy identyfikuje i opisuje pewną abstrakcję, której poziom znajduje się powyżej poziomu abstrakcji klasy, instancji lub komponentu.

W inżynierii oprogramowania wzorce projektowe to poziom interakcji między klasami. Pokazuje powiązania i zależności pomiędzy klasami oraz obiektami i ułatwia tworzenie, modyfikację i pielęgnację kodu źródłowego. Wzorzec nie jest gotową implementacją rozwiązania, a jedynie opisem.

Wzorce projektowe potrzebne są do:

• wzrostu jakości oprogramowania

• ustalenie wspólnego języka dla programistów (ułatwiają wymianę doświadczeń, specyfikację wymagań)

• zmniejszenia czasu tworzenia oprogramowania

• stanowią zbiór dobrze zdefiniowanych i sprawdzonych rozwiązań

Podział wzorców projektowych:

• kreacyjne – dotyczą sposobów tworzenia obiektów, skupiając się na abstrakcji i hermetyzacji tego procesu

• strukturalne – opisują sposób konstrukcji struktur obiektowych, łączenia ze sobą obiektów i zarządzania nimi

• behawioralne – skupiają się na opisie algorytmów, podziale odpowiedzialności pomiędzy obiekty oraz charakterystyce interakcji pomiędzy nimi

  1. Wymienić wzorce projektowe kreacyjne (modelujące działanie systemu), behawioralne, strukturalne (wybrać nie więcej niż 2 wzorce z każdej grupy)

• kreacyjne:

  • Fabryka Abstrkacyjna (Abstract Factory)

  • Budowniczy (Builder)

• behawioralne:

  • Most (Bridge)

  • Obserwator (Observer)

• strukturalne:

  • Adapter

  • State (Stan)

  1. Wybrać nie więcej niż 2 wzorce z każdej grupy, napisać strukturę np. w pseudokodzie jak to wygląda

Schemat wzorca: Fabryka Abstrakcyjna

Schemat wzorca: Most

Przykład wzorca: Most

Schemat wzorca: Obserwator

Pseudokod: Obserwator

//Stereotyp w UML to coś co możemy rozszerzać

Kolejność diagramów:

1. model wymagań

2. przypadki użycia

3. diagram aktywności

4. diagram sekwencji

5. diagram klas