1.Wyjaśnić różnicę między notacją, językiem a metodyką.

Notacja to umowny sposób zapisu symboli, liter, znaków, itp. Notacja umożliwia w sposób formalny

zapis treści wyrażeń reguł, wzorów, formuł, itd.

Notacja ułatwia komunikację zarówno między członkami zespołu projektowego, jak i między

zespołem projektowym a klientem. Do najważniejszych rodzajów notacji zalicza się:

–Notacje tekstowe

–Specyfikacje – ustrukturalizowany zapis tekstowy i numeryczny

–Notacje graficzne

Metodyka to spójny, logicznie uporządkowany zestaw metod i procedur technicznych oraz

organizatorskich służących zespołowi wykonawczemu do analizy rzeczywistości a także

projektowania pojęciowego, logicznego i/lub fizycznego;

•Metodyka jest to zestaw pojęć, notacji, modeli, języków, technik i sposobów postępowania

służący do analizy dziedziny stanowiącej przedmiot projektowanego systemu oraz do

projektowania pojęciowego, logicznego i/lub fizycznego.

•Metodyka jest powiązana z notacją służącą do dokumentowania wyników faz projektu

(pośrednich, końcowych) jako środek wspomagający ludzką pamięć i wyobraźnię i jako środek

komunikacji w zespołach oraz pomiędzy projektantami i klientami.

•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:

–Role uczestników projektu

–Scenariusze postępowania

–Reguły przechodzenia do następnej fazy

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

–Notację, czyli zbiór oznaczeń, które należy wykorzystywać do dokumentowania wyników

poszczególnych faz projektu.

Składowe języka modelowania:

•składnia - określa jakie oznaczenia wolno stosować i w jaki sposób je ze sobą łączyć;

•semantyka - określa co należy rozumieć pod przyjętymi oznaczeniami;

•pragmatyki - określa w jaki sposób należy dopasować wzorzec notacyjny do konkretnej

sytuacji i problemu.

2.Wyjaśnić różnicę między modelem a diagramem.

Model jest spójnym opisem systemu; stanowi jego kompletny obraz utworzony z określonej

perspektywy na pewnym poziomie szczegółowości, co oznacza, że niektóre elementy systemu

są ukryte, a inne wyeksponowane. Pojedynczy model zazwyczaj nie wystarcza ani do

zrozumienia wszystkich aspektów systemu jednocześnie, ani do jego implementacji. Zazwyczaj

potrzebnych jest wiele modeli, które muszą być wzajemnie spójne oraz redundantne.

Diagram służy do opisania modelu. Model może być opisywany przy pomocy wielu diagramów

opisujących dany model.

3.Podać charakterystykę języka UML.

UML (ang. Unified Modeling Language czyli Ujednolicony Język Modelowania) to graficzny język do obrazowania, specyfikowania, tworzenia i dokumentowania

elementów systemów informatycznych. Umożliwia standaryzację sposobu

opracowywania przekrojów systemu, obejmujących obiekty pojęciowe, takie jak procesy przedsiębiorstwa i funkcje systemowe, a także obiekty konkretne, takie jak klasy zaprogramowane w ustalonym języku, schematy baz danych i

komponenty programowe nadające się do ponownego użycia. UML wspomaga specyfikowanie wszystkich ważnych decyzji analitycznych, projektowych i

implementacyjnych, które muszą być podejmowane w trakcie wytwarzania i wdrażania systemu informatycznego. Modele zapisane w języku UML są jednakowo interpretowane przez wszystkie osoby zaangażowane w dany proces.

4. Omówić modele i diagramy zdefiniowane w UML.

Wyróżnia się 14 diagramów głównych oraz 3 abstrakcyjne (struktur, zachowań i interakcji) : Diagramy struktur -Klas (najczęściej spotykane, ang. class diagram) -Obiektów (ang. object diagram) -Komponentów (ang. component diagram) -Wdrożenia (ang. deployment diagram) -Struktur złożonych (ang. composite structure diagram) -Pakietów (ang. package diagram) -Profili (ang. profile diagram, nowość wprowadzona w UML 2.2) Diagramy zachowań -Czynności (ang. activity diagram) -Przypadków użycia (ang. use case diagram) -Maszyny stanów (ang. state machine diagram) (dla UML 1.x Stanów, ang. statechart diagram) -Interakcji (diagram abstrakcyjny) -Komunikacji (ang. communication diagram) (dla UML 1.x Współdziałania, ang. collaboration diagram) -Sekwencji (ang. sequence diagram) -Czasowe (ang. timing diagram) -Przeglądu interakcji (ang. interaction overview diagram)

Modele: W podejściu obiektowym w fazie analizy najczęściej wykorzystywane są następujące modele: Model przypadków użycia – specyfikujący funkcjonalność systemu widzianą z perspektywy jego przyszłych użytkowników. Model ten jest przedstawiany w postaci diagramu przypadków użycia. Model obiektowy – opisujący statyczną budowę systemu. Model ten jest przedstawiany w postaci diagramu klas i diagramu obiektów. Główna różnica pomiędzy diagramem klas a diagramem obiektów polega na tym, że diagram klas przedstawia klasy oraz może przedstawiać obiekty, podczas gdy diagram obiektów przedstawia obiekty, ale nie przedstawia klas. Czynności prowadzące do powstania modelu obiektowego określa się terminem analiza statyczna. Model dynamiczny (model zachowań) – służący do identyfikowania operacji niezbędnych systemowi do realizacji zadań; najczęściej rozważanymi rodzajami zadań są przypadki użycia. Model ten jest przedstawiany w postaci m.in. diagramów stanów i diagramów komunikacji między obiektami. Zidentyfikowane metody nanoszone są na stworzony uprzednio wstępny diagram klas uzupełniając w ten sposób definicje jego klas. Czynności prowadzące do powstania modelu dynamicznego określa się terminem analiza dynamiczna. W fazie projektowania model pojęciowy jest dostosowywany do wymagań niefunkcjonalnych oraz do ograniczeń środowiska implementacji, stając się modelem logicznym..Podczas implementacji, model logiczny jest przekształcany w model fizyczny, czyli kod.

5.W jakim celu budujemy modele biznesowe. Podaj kilka przykładów modeli, które sam zbudowałeś.

Modelowanie biznesowe (z ang. Business Modeling) to praktyka stosowana z powodzeniem

przez wiele współczesnych przedsiębiorstw. Służy do opisu wszystkiego, co składa się na daną

organizację (dokumentacji, procedur i procesów biznesowych). Dzięki modelom biznesowym

można odpowiedzieć na 6 kluczowych pytań dla każdej organizacji biznesowej: co, jak,

dlaczego, kto, gdzie i kiedy.

W procesie wytwarzania oprogramowania jest pierwszym etapem z jakim spotykają się twórcy oprogramowania, gdyż model biznesowy to opis rzeczywistej firmy lub instytucji.

Modelowanie biznesowe pozwoli zrozumieć czym zajmuje się dane przedsiębiorstwo. Zasadniczym

celem budowy modelu biznesowego jest utworzenie takiego obrazu organizacji, który będąc opisem rzeczywistości stanie się podstawą szkieletu aplikacji (opisem tego szkieletu). Modelowanie biznesowe to wgląd w strukturę przedsiębiorstwa i procesy w nim zachodzące.

Modelowanie biznesowe jest sposobem odwzorowywania i dokumentowania procesów

biznesowych. Zrozumienie istoty procesów biznesowych jest podstawą specyfikacji wymagań oraz analizy i projektowania systemów informatycznych. Wiele metodyk przypisuje temu zagadnieniu wysoki

priorytet. Modelowanie biznesowe to pierwszy etap iteracyjno-przyrostowego cyklu życia

systemu w metodyce RUP.

Tworzenie modeli biznesowych istotnie przyczynia się do lepszego zrozumienia sposobu funkcjonowania organizacji poprzez precyzyjny opis procesów biznesowych

6.Dlaczego właściwe określenie celów biznesowych jest podstawą poprawnego modelu biznesowego?

Modelowanie biznesowe pozwoli zrozumieć czym zajmuje się dane przedsiębiorstwo. Zasadniczym

celem budowy modelu biznesowego jest utworzenie takiego obrazu organizacji, który będąc

opisem rzeczywistości stanie się podstawą szkieletu aplikacji (opisem tego szkieletu). Zrozumienie istoty procesów biznesowych jest podstawą specyfikacji wymagań oraz analizy iprojektowania systemów informatycznych. Wiele metodyk przypisuje temu zagadnieniu wysokipriorytet. Modelowanie biznesowe to pierwszy etap iteracyjno-przyrostowego cyklu życia systemu w metodyce RUP. Tworzenie modeli biznesowych istotnie przyczynia się do lepszego zrozumienia sposobu funkcjonowania organizacji poprzez precyzyjny opis procesów biznesowych.

7.Jakie korzyści lub straty odniesie organizacja z modelu biznesowego?

Modelowanie biznesowe pozwoli zrozumieć czym zajmuje się dane przedsiębiorstwo. Zasadniczym

celem budowy modelu biznesowego jest utworzenie takiego obrazu organizacji, który będąc opisem rzeczywistości stanie się podstawą szkieletu aplikacji (opisem tego szkieletu). Modelowanie biznesowe to wgląd w strukturę przedsiębiorstwa i procesy w nim zachodzące.

Modelowanie biznesowe jest sposobem odwzorowywania i dokumentowania procesów

biznesowych. Zrozumienie istoty procesów biznesowych jest podstawą specyfikacji wymagań oraz analizy i projektowania systemów informatycznych. Wiele metodyk przypisuje temu zagadnieniu wysoki

priorytet. Modelowanie biznesowe to pierwszy etap iteracyjno-przyrostowego cyklu życia

systemu w metodyce RUP.

Tworzenie modeli biznesowych istotnie przyczynia się do lepszego zrozumienia sposobu funkcjonowania organizacji poprzez precyzyjny opis procesów biznesowych.

8.Przedstaw istotę systemu informacyjnego.

SI to taki system, który przetwarza dane w informacje. Jest to zatem zbiór współpracujących elementów, które zbierają i gromadzą dane (input), zmieniają ich treść i formę (processing), emitują dane i informacje (output) oraz dostarczają sprzężenia zwrotnego (feedback), aby osiągnąć zamierzony cel. Wejście systemu (input) określa się jako pozyskiwanie, zbieranie i gromadzenie danych. Może ono wykorzystywać różne techniki i urządzenia. Przetwarzanie danych (processing) polega na przekształcaniu danych w użyteczną informację i może obejmować takie operacje jak: obliczenia, łączenie (tekstów, tabel, zbiorów danych), pobieranie podzbioru danych, dokonywanie porównań i podejmowanie alternatywnych akcji. Może odbywać się ręcznie lub automatycznie. Wyjście systemu (output) dotyczy wyemitowania i prezentacji przydatnej informacji, zwykle w formie dokumentów lub raportów. Sprzężenie zwrotne (feedback) stanowi takie wyjście systemu, które jest użyte do tego, aby zmienić wejście systemu lub proces przetwarzania.

9. Przedstaw klasyfikację systemów.

Elementy systemu mogą mieć charakter niematerialny: system mogą tworzyć np. informacje ekonomiczne oraz procesy związane z ich powstawaniem. Systemy mogą być zamknięte lub otwarte. System zamknięty stanowi samodzielną całość, która nie ma połączeń z innymi systemami – nie pobiera on niczego z innych systemów i nic do nich nie wysyła. Istotą systemów otwartych jest współpraca z innymi systemami. Uwaga: każdy podsystem jest zawsze systemem otwartym: jako część większej całości musi współpracować z przynajmniej jedną lub dwiema innymi częściami, czyli otrzymywać elementy wejścia i przekazywać elementy wyjścia do innych podsystemów.

10. Organizacja gospodarcza jako system i jej elementy składowe.

Organizacja gospodarcza i jej otoczenie należą do systemów, które charakteryzują się ogólnymi właściwościami. Są to systemy: rzeczywiste, sztuczne, złożone z ludzi oraz zasobów materialnych i niematerialnych o niemożliwych do jednoznacznego ustalenia rzeczywistych regułach zachowania się, otwarte i dynamiczne. Są zarówno informowane, jak i informujące. Warunkiem koniecznym skutecznego funkcjonowania każdej organizacji gospodarczej jest zorganizowanie sprawnego przepływu informacji. Należy stworzyć system informacyjny, który będzie stanowił jej integralną część.

11. Cel i zakres analizy strategicznej.

Strategia systemu Na tym etapie tworzy się architekturę systemów informatycznych wspomagających strategiczne cele przedsiębiorstwa. Stosowane są w tym celu wszelkie metody analizy sytuacyjnej firmy (np. burza mózgów, meta­plan, itp.). Konieczny jest udział kierownictwa firmy, ponieważ jest opraco­wywany tzw. infoplan, którego składnikiem jest plan tworzenia systemu informatycznego.

Analiza systemu Dotyczy dziedziny przedmiotowej, wyspecyfikowanej w poprzednim eta­pie, lub jej wycinka i obejmuje analizę organizacji, analizę danych (statykę dziedziny przedmiotowej) i analizę funkcji (dynamikę dziedziny przedmiotowej). Zalecane metody to: model związków encji, podejście ISAC (ang. In­formation Systems Work and Analysis of Changes) i analiza strukturalna.

12. Jaką rolę w organizacjach odgrywa system informacyjny?

Organizacja i jej otoczenie należą do systemów, które charakteryzują się ogólnymi właściwościami. Są to systemy: rzeczywiste, sztuczne, złożone z ludzi oraz zasobów materialnych i niematerialnych o niemożliwych do jednoznacznego ustalenia rzeczywistych regułach zachowania się, otwarte i dynamiczne. Są zarówno informowane, jak i informujące. Warunkiem koniecznym skutecznego funkcjonowania każdej organizacji gospodarczej jest zorganizowanie sprawnego przepływu informacji. Należy stworzyć system informacyjny, który będzie stanowił jej integralną część.

13. Co składa się na sprawnie funkcjonujący system informacyjny?

Wejście systemu (input) określa się jako pozyskiwanie, zbieranie i gromadzenie danych. Może ono wykorzystywać różne techniki i urządzenia. Przetwarzanie danych (processing) polega na przekształcaniu danych w użyteczną informację i może obejmować takie operacje jak: obliczenia, łączenie (tekstów, tabel, zbiorów danych), pobieranie podzbioru danych, dokonywanie porównań i podejmowanie alternatywnych akcji. Może odbywać się ręcznie lub automatycznie. Wyjście systemu (output) dotyczy wyemitowania i prezentacji przydatnej informacji, zwykle w formie dokumentów lub raportów. Sprzężenie zwrotne (feedback) stanowi takie wyjście systemu, które jest użyte do tego, aby zmienić wejście systemu lub proces przetwarzania.

14. Jakie są relacje pomiędzy systemem informacyjnym a informatycznym?

System informatyczny jest wyodrębnioną częścią systemu informacyjnego, w którym do przetwarzania danych zastosowano środki i metody informatyczne, a zwłaszcza sprzęt i oprogramowanie komputerów. System informacyjny jest to układ odpowiednich elementów, którego zadaniem jest przetwarzanie danych.

15. Struktury systemu informatycznego.

KONSTRUKCJA CAŁOŚCI SYSTEMU:

-Struktura funkcjonalna:

>Podział systemu na moduły

>Określenie procesów podstawowych i pomocniczych

-Struktura informacyjna:

>Określenie logicznych struktur danych

>Określenie zasad kodowania danych

-Struktura techniczno-technologiczna:

>Typy sprzętu komputerowego

>Technologia przetwarzania

>Oprogramowanie systemowe

-Struktura przestrzenna:

>Topologia punktów przetwarzania

>Topologia sieci komputerowej

>Oprogramowanie sieciowe

16. Luka informacyjna i jej znaczenie.

Luka ta powstaje pomiędzy ilością informacji pożądanych a dostępnych. Oznaczają informacje pożądane, aczkolwiek niedostępne. Luka powiększa się wraz ze wzrostem złożoności problemu i ilości informacji.

17. Jakie są składniki metodyki TSI i zależności między nimi?

18. Czym różnią się metodyki strukturalne, obiektowe, społeczne i adaptacyjne?

Metodyka strukturalna - Jest to podejście formalne, polegające na tworzeniu systemu o uporządkowanej strukturze procesów i danych oraz związków między nimi. Cechą charakterystyczną tego podejścia jest: -Oddzielne modelowanie danych i procesów, -Wykorzystanie diagramowych i macierzowych metod i technik. Metodyka obiektowa - Opiera się ono na wyodrębnieniu obiektu, czyli każdego bytu, pojęcia lub rzeczy, mającego określone znaczenie w kontekście rozwiązywania problemu w danej dziedzinie przedmiotowej. Pojęcie obiektu umożliwia integralne modelowanie danych i procesów. Metodyka społeczna - Akcentuje ono aspekty humanitarne i społeczne – psychologiczne i socjologiczne – w tworzeniu systemów informatycznych. Podejście społeczne jest użyteczne w fazie planowania systemów informatycznych. Metodyka adaptacyjna - Kwestią, wokół której skoncentrowała się krytyka twórców nowego podejścia, są definiowanie, a następnie modyfikacja i adaptacja potrzeb informatycznych. Nie jest to tylko kwestia ich subiektywnej oceny, ale wpływ dwu szybko zmieniających się czynników: -technologii informatycznych i modyfikacji wymagań systemu w trakcie jego realizacji, -tworzenia oprogramowania na bieżąco w całym procesie TSI W pierwszym założeniu przyjmuje się, zasadniczą trudność w rozumieniu i identyfikacji potrzeb informatycznych oraz założeń systemu, a w konsekwencji zakłada możliwość i akceptację ich zmian, modyfikacji i adaptacji w procesie TSI. Drugie założenie oznacza, że oprogramowanie systemu jest wdrażane przyrostowo, sekwencyjnie w procesie TSI, co odróżnia je od innych metodyk wdrażających system w końcowych fazach cyklu.

19.Co to jest cykl życia systemu?

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

opracowania systemu dla przedsiębiorstwa.

20.Wymień i opisz rodzaje cykli życia systemu.

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 w określonej, zstępującej sekwencji, Każdy etap powinien być zakończony przed rozpoczęciem następnego.

Do najbardziej znanych cykli życia systemu należą:

–Cykl kaskadowy (liniowy, klasyczny)

–Cykl spiralny

–Cykl ewolucyjny

Model kaskadowy

Specyfikacja wymagań → Projektowanie → Implementacja → Testowanie → wdrożenie

Zalety:

- ułatwia organizację: planowanie, harmonogramowanie, monitorowanie przedsięwzięcia

- zmusza do zdyscyplinowanego podejścia

- wymusza kończenie dokumentacji po każdej fazie

- wymusza sprawdzenie każdej fazy przez SQA

Wady:

- narzuca twórcom oprogramowania ścisłą kolejność wykonywania prac

- występują trudności w sformułowaniu wymagań od samego początku

- powoduje wysokie koszty błędów popełnionych we wczesnych fazach,

- powoduje długie przerwy w kontaktach z klientem.

- brak jest weryfikacji i elastyczności

- możliwa jest niezgodność z faktycznymi potrzebami klienta

- niedopasowanie - rzeczywiste przedsięwzięcia rzadko są sekwencyjne

– realizatorzy kolejnych faz muszą czekać na zakończenie wcześniejszych

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

Model Ewolucyjny

Zalety:

– dobry dla małych projektów, szybki start projektu

– tolerancja dla słabo zdefiniowanych wymagań

– niski koszt błędów (krótki czas życia błędów)

Wady:

– trudność z harmonogramowaniem

– koszty prototypowania, błądzenia

– systemy często o złej strukturze

21.Podstawowe fazy liniowego cyklu życia systemu, ich kolejność i istota.

22. Liniowy a spiralny cykl życia systemu.

Model liniowy Zalety: - ułatwia organizację: planowanie, harmonogramowanie, monitorowanie przedsięwzięcia - zmusza do zdyscyplinowanego podejścia - wymusza kończenie dokumentacji po każdej fazie - wymusza sprawdzenie każdej fazy przez SQA Wady: - narzuca twórcom oprogramowania ścisłą kolejność wykonywania prac - występują trudności w sformułowaniu wymagań od samego początku - powoduje wysokie koszty błędów popełnionych we wczesnych fazach, - powoduje długie przerwy w kontaktach z klientem. - brak jest weryfikacji i elastyczności - możliwa jest niezgodność z faktycznymi potrzebami klienta - niedopasowanie - rzeczywiste przedsięwzięcia rzadko są sekwencyjne - realizatorzy kolejnych faz muszą czekać na zakończenie wcześniejszych 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

23. Na czym polega analiza ryzyka w spiralnym modelu cyklu życia systemu.

24. Interpretacja iteracyjno-przyrostowego cyklu życia systemu. Fazy i dyscypliny.

25. Podstawowe kategorie pojęciowe i graficzne diagramów przepływu danych.

Symbol procesu

Symbol obiektu zewnętrznego (terminatora)

Symbol magazynu danych

Symbol przepływu

Proces jest zbiorem funkcji, które zajmują się przetwarzaniem. Proces pobiera “coś” na wejściu, przetwarza a następnie generuje przepływ na wyjściu. Terminator symbolizuje obiekty zewnętrzne wobec systemu. Zwykle jest to osoba lub firma, z którą organizacja się komunikuje. Magazyn danych jest symbolem miejsca, gdzie przechowywane są dane istotne dla firmy. Magazyn służy do buforowania danych wykorzystywanych przez kilka procesów w przypadku braku współmierności czasowej. Przepływ przedstawia proces przenoszenia pakietów informacji pomiędzy elementami systemu lub pomiędzy obiektami zewnętrznymi oraz systemem.

26.Opracuj diagram przepływu danych obsługi sesji egzaminacyjnej.

27.Modelowanie systemów przy użyciu diagramów przypadków użycia.

Wymagania użytkowników systemu informacyjnego można przedstawić w postaci listy zdań, które chcą oni za pomocą tego systemu wykonać. Każde z tych zadań można opisać podając kolejność działań, w toku których użytkownik wybierze zadanie poda dane niezbędne do jego realizacji i odbierze potrzebne mu wyniki. W ten sposób opis wymagań przyjmie postać opisu wszystkich sposobów używania systemu przez użytkowników. Graficzną reprezentacją modelu jest diagram przypadków użycia (use case diagram), którego podstawowymi elementami są ikony aktorów, owale reprezentujące przypadki użycia oraz linie przedstawiające zachodzące między nimi relacje. Istnienie relacji łączącej aktora z przypadkiem użycia wskazuje na zaangażowanie tego aktora w realizację danego przypadku.

28.Opracuj diagram przypadków użycia dla obsługi sesji egzaminacyjnej.

29.Opracuj diagram przypadków użycia dla obsługi międzynarodowej konferencji naukowej.

30.Opracuj diagram przypadków użycia dla obsługi serwisu linii lotniczych.

31.W jaki sposób tworzone są scenariusze i jaką odgrywają one rolę?

Scenariusz jest specyfikacją zachowania, która wyraża proces jako sekwencję zdarzeń i operacji. Scenariusze występują w dwu kategoriach: -scenariusz specyficzny opisujący przykładowe oddziaływanie z pojedynczymi obiektami. -scenariusz ogólny opisuje oddziaływanie w kategoriach typów obiektów. Scenariusze specyficzne są najprostszym sposobem komunikowania się z użytkownikami nie mającymi doświadczenia w modelowaniu. Takie scenariusze dotyczą bezpośrednio ich doświadczeń bez wprowadzania jakiejkolwiek terminologii. Diagram oddziaływania reprezentuje typy obiektowe biorące udział w scenariuszu za pomocą pionowych pasków. Ponieważ scenariusz jest obiektowy, każda operacja jest związana z jej konkretnym typem obiektowym.

32.Składniki pakietu CASE.

Narzędziem CASE mogą być zarówno proste pakiety związane z jedną fazą cyklu życia, z jej wybranymi procesami (workbenches), jak i wielomodułowe środowiska (environments) wykorzystywane w wielu fazach cyklu życia, wielu aspektach wytwarzania i utrzymania systemu. Z punktu widzenia funkcjonalności wśród narzędzi CASE (lub ich modułów) można wyróżnić: -Narzędzia diagramujące (diagramming tools); -Generatory form ekranowych i raportów (form and report generators) lub moduły projektowania interfejsu użytkownika; -Narzędzia analityczne (analysis tools); -Generatory dokumentacji (documentation generators); -Generatory oprogramowania (code, programs generators) i zintegrowane środowisko programistyczne; -Narzędzia wspomagające zarządzanie przedsięwzięciami; -Narzędzia inżynierii odwrotnej;

-Narzędzia wspomagające weryfikację, walidację i testowanie oprogramowania; -Narzędzia modelowania i analizy organizacji; -Zintegrowane narzędzia CASE (Integrated CASE, I-CASE) lub zintegrowane środowisko wytwórcze (Integrated Development Environments, IDE).

33.Rodzaje pakietów CASE.

W zależności od tego, w jakiej fazie cyklu życia systemu narzędzia są użytkowane wyróżnić można: -Narzędzia wysokiego poziomu (upper CASE tools) – narzędzia wspomagające identyfikację i selekcję projektu, inicjację i planowanie projektu, analizę i projektowanie; zwykle są niezależne od środowiska implementacji; -Narzędzia niskiego poziomu (lower CASE tools) – narzędzia wspomagające implementację (konstrukcję, kodowanie, testowanie, instalację) i utrzymanie systemu; zwykle są związane z konkretnym środowiskiem implementacji; -Narzędzia wykorzystywane w wielu fazach cyklu życia systemu (cross life cycle CASE tools).

34.Jak jest definiowane pojęcie obiektu? Proszę podać przykłady obiektów występujących w dziedzinie problemowej „uczelni wyższej”

Obiekt jest to struktura danych stanowiąca w implementacji komputerowej odwzorowanie bytu, który posiada dobrze określone granice i własności, wyróżnialnego w analizowanym fragmencie dziedziny problemowej.

35.Jaka jest różnica pomiędzy obiektem a klasą?

Obiekt jest to struktura danych stanowiąca w implementacji komputerowej odwzorowanie bytu, który posiada dobrze określone granice i własności, wyróżnialnego w analizowanym fragmencie dziedziny problemowej. Klasa, podobnie jak obiekt, należy do podstawowych pojęć obiektowości. W literaturze poświęconej obiektowości funkcjonuje kilka różnych definicji tego pojęcia:

 Klasa jest nazwanym zbiorem obiektów o podobnych własnościach: semantyce, atrybutach, zachowaniu, związkach z innymi obiektami itd.

 Klasa jest nazwanym opisem grupy obiektów o podobnych własnościach. Zgodnie z tą definicją, klasa nie jest zbiorem obiektów, lecz jest wykorzystywana do deklarowania obiektów.

36.Krótko scharakteryzuj koncepcję związku generalizacji-specjalizacji.

W perspektywie pojęciowej, generalizacja-specjalizacja (w skrócie zwana generalizacją lub specjalizacją) jest związkiem łączącym pewną klasę, tzw. nadklasę, z innymi klasami, tzw. podklasami, przy czym nadklasa modeluje byty bardziej ogólne niż byty modelowane przez podklasy .W perspektywie projektowej, ze związkiem generalizacji ściśle związany jest mechanizm dziedziczenia dzięki któremu inwarianty są importowane z nadklasy do podklas. Oznacza to, że podklasa posiada wszystkie własności swojej nadklasy; poza tym podklasa może posiadać (i zazwyczaj posiada) także pewne dodatkowe własności. Dziedziczenie inwariantów jest tranzytywne (przechodnie). Struktury związków generalizacji tworzą drzewa klas (lub inne struktury bez pętli) zwane hierarchiami generalizacji (specjalizacji, dziedziczenia).

37.Co to jest metoda abstrakcyjna i w jaki celu jest wykorzystywana?

Klasa abstrakcyjna jest to klasa, która nie ma i nie może posiadać wystąpień bezpośrednich. Klasa abstrakcyjna służy zatem wyłącznie jako nadklasa dla innych klas, stanowiąc swego rodzaju wspólną część definicji grupy klas o podobnej semantyce. UML pozwala na oznaczenie bytu abstrakcyjnego (klasy czy metody abstrakcyjnej) za pomocą wartości etykietowanej {abstract = TRUE} (lub w skrócie {abstrakt}.

38.Czy klasa abstrakcyjna może być liściem w hierarchii dziedziczenia klas?

Ponieważ klasa abstrakcyjna pełni rolę nadklasy dla innych klas (również dla innych klas abstrakcyjnych), nie może być liściem w hierarchii dziedziczenia. Zastrzeżenie to nie dotyczy oczywiście klasy konkretnej, która może występować w dowolnym miejscu hierarchii.

39.Jaka jest różnica pomiędzy powiązaniem a asocjacją?

Powiązanie posiada nazwę odpowiadającą charakterowi związku między bytami. Dla powiązań binarnych nazwa jest umieszczana na linii (oznaczającej powiązanie) mniej więcej w jednakowej odległości od obu obiektów. Na poziomie implementacyjnym powiązania są odwzorowywane najczęściej jako wskaźniki/referencje prowadzące od obiektów do obiektów. Grupy powiązań posiadających wspólną strukturę i semantykę są modelowane w postaci związków asocjacyjnych, zwanych w skrócie asocjacjami, podobnie jak grupy obiektów o wspólnej strukturze i semantyce są modelowane w postaci klas; nazwy asocjacji są nazwami odpowiadających im powiązań. W ten sposób powiązanie jest traktowane jako wystąpienie (instancja) asocjacji.

40.Rodzaje asocjacji, przykłady.

Typy asocjacji - Jeden do jednego - 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, ale ta instancja, która jest z nią powiązana nie może mieć więzi więcej niż jedną
- Wiele do wielu – i instancja i instancje z nią powiązane mogą mieć w takim związku wiele więzi.

Specjalne typy asocjacji - Agregacja – jest relacją całość-całość; jeden element składa się z innych elementów. Jest to relacja antysymetryczna – tzn., że element-całość zawiera elementy-części, ale elementy-części nie mogą zawierać elementu-całości (przykład z matematyki: linia i punkty – linia składa się z punktów, punkt nie może zawierać linii, a dodatkowo punkt może być elementem wielu linii).
- Kompozycja – silniejsza forma agregacji. Tu żaden element nie może być jednak dzielony. Tutaj często jeśli element-całość się zniszczy, zniszczeniu ulega element-część. (np. silnik i samochód – samochód zawiera silnik, który może być wykorzystywany tylko przez 1 samochód jednocześnie).

41.Krótko omów podstawowe rodzaje stanów: prosty, złożony, początkowy, końcowy.

prosty -stan nie posiadający podstanów (czyli innych stanów wchodzących w jego skład) złożony sekwencyjny -stan złożony z jednego lub więcej podstanów; tylko jeden z podstanów jest aktywny wówczas, gdy jako całość aktywny jest stan złożony

złożony współbieżny -stan podzielony na dwa lub więcej współbieżnych podstanów; wszystkie podstany są jednocześnie aktywne wówczas, gdy jako całość aktywny jest stan złożony początkowy -pseudostan (tzn. stan pełniący tylko funkcje pomocnicze) służący do oznaczenia punktu startowego (początku istnienia obiektu w systemie) końcowy-pseudostan służący do oznaczenia punktu finalnego (końca istnienia obiektu w systemie)

42.Krótko omów zasadniczy cel konstruowania diagramów aktywności, diagramów integracji, diagramów implementacyjnych.

Diagramy aktywności służą przede wszystkim do modelowania przepływów operacji wykonywanych w celu realizacji zadań zlecanych systemowi przez jego aktorów. Diagramy integracji odwołując się do diagramów klas specyfikują, jak będzie przebiegała realizacja zadań zlecanych systemowi przez jego użytkowników (np. przypadków użycia lub tylko ich fragmentów) w terminach współpracujących ze sobą obiektów. UML definiuje dwa rodzaje diagramów interakcji: diagramy współpracy (kolaboracji) oraz diagramy sekwencji - oba przedstawiające niemal identyczną informację, chociaż w nieco inny sposób. Diagramy implementacyjne służą do ilustracji dwóch aspektów implementacji systemu informatycznego: struktury kodu i konfiguracji elementów czasu wykonania.

43.Wymień i omów rodzaje diagramów implementacyjnych.

UML definiuje dwa rodzaje diagramów implementacyjnych: - Diagramy komponentów - ilustrują strukturę kodu projektowanego systemu poprzez specyfikowanie implementacji elementów projektu (np. klas czy podsystemów) za pomocą komponentów i ich interfejsów, oraz wskazanie zależności występujących pomiędzy komponentami. Celem identyfikacji komponentów jest budowa systemów o odpowiednio wysokiej jakości, wypełniających pożądane potrzeby biznesowe i budowanych szybko − raczej poprzez składanie z gotowych części niż poprzez wypracowywanie każdego elementu samodzielnie. Taki sposób pracy jest korzystny dla budowy np. rodziny aplikacji: niektóre komponenty opłaca się opracować samodzielnie, a niektóre warto odszukać wśród gotowych, istniejących już w organizacji czy na rynku i ewentualnie zaadaptować do aktualnych potrzeb. - Diagramy wdrożeniowe - pokazują konfigurację systemu czasu wykonania, czyli rozmieszczenie komponentów i obiektów na węzłach. Węzły modelują obliczeniowe zasoby czasu wykonania. Taka konfiguracja może być zarówno statyczna, jak i dynamiczna: komponenty i obiekty mogą migrować między węzłami w czasie wykonania.

44.Kiedy i w jakich sytuacjach i w jakim celu wykorzystywane są diagramy pakietów? Jakie rodzaje związków mogą występować między pakietami?

Diagramy pakietów z kolei, są budowane przede wszystkim dla dużych projektów, tworzonych przez dużą grupę współpracujących osób, projektów składających się z wielu jednostek funkcjonalnych, ze złożonymi zależnościami pomiędzy tymi jednostkami. Zadaniem pakietów jest grupowanie elementów danego (jednego) modelu, wraz z występującymi pomiędzy tymi elementami relacjami. Istnieje co najmniej kilka powodów, dla których warto jest używać diagramów pakietów: - W celu ukrycia mniej istotnych elementów modelu (podobnie jak zilustrowano to w przykładzie o subkolaboracji umieszczonym w wykładzie dotyczącym diagramów interakcji).

- Dla ułatwienia podziału pracy między członkami zespołu czy też różnymi zespołami. - Dla ułatwienia procesu zarządzania budową produktu informatycznego. Zależności między pakietami:

- zawieranie (import)

- uogólnienie (generalization)

- scalanie (merge)

45.Objaśnij pojęcia: aktor biznesowy, biznesowy przypadek użycia, pracownik biznesowy, encja biznesowa.

Aktor -aktor w biznesowym modelu przypadków użycia reprezentuje użytkownika biznesowego, czyli byt zewnętrzny w stosunku do organizacji, taki jak np.: klient, dostawca czy partner biznesowy. Podobnie, jak dla systemowego modelu przypadków użycia, aktor niekoniecznie musi reprezentować osobę, aktorem może być także np. rząd czy inne władze mające uprawnienia ustawodawcze i przez to wywierające wpływ na działalność organizacji. Aktor musi posiadać unikatową nazwę. biznesowy przypadek użycia-Biznesowy przypadek użycia reprezentuje proces biznesowy realizowany w danej organizacji - proces biznesowy jest określany przez ciąg operacji, które trzeba wykonać, aby otrzymać wartość dodaną. Biznesowy przypadek użycia musi posiadać unikatową nazwę. Kompletny zbiór biznesowych przypadków użycia specyfikuje całość procesów biznesowych realizowanych w danej organizacji. pracownik biznesowy- Pracownik biznesowy reprezentuj rolę, jaką człowiek odgrywa wewnątrz organizacji. Pracownik biznesowy musi posiadać unikatową nazwę. encja biznesowa -Encja biznesowa reprezentuje materialny lub finansowy zasób czy też cokolwiek innego, czym organizacja zarządza lub co wytwarza. Innymi słowy pojęcie encja biznesowa jest wykorzystywane do reprezentowania wszystkiego, co jest konsumowane lub produkowane przez procesy biznesowe. Przykłady encji biznesowych, to: finanse, wyposażenie, inwentarz, technologia, a nawet know-how. Encja biznesowa musi posiadać unikatową nazwę.

46.Objaśnij różnicę między modelami przypadków użycia w modelowaniu biznesowym i w modelowaniu systemowym.

47.Jakie są podstawowe różnice pomiędzy fazami analizy i projektowania.

Faza analizy -jej celem jest bowiem przede wszystkim rozpoznanie tych aspektów dziedziny problemowej, które mogłyby być poddane procesowi informatyzacji. Co więcej, w fazie analizy nie powinno się brać pod uwagę aspektów związanych z implementacją. Faza projektowania -podstawowym celem projektowania jest opracowanie szczegółowego planu implementacji systemu, w jego trakcie dużą rolę odgrywa środowisko implementacji i jego uwarunkowania. Oznacza to, że projektanci muszą posiadać dobrą znajomość języków programowania, bibliotek oraz narzędzi stosowanych w trakcie implementacji.

48.Podstawowe zasady obiektowości.

Obiektowość powstała z potrzeby łatwiejszego sposobu symulowania systemów – nie tylko symulowania systemów informatycznych, lecz dowolnych rodzajów systemów.

•Obiektowość dostarcza metodę do tworzenia dowolnych systemów – niezależnie od tego, jak te systemy będą implementowane. Ponadto tej samej obiektowej specyfikacji można użyć w wielu innych dziedzinach, niezależnie od tego czy dotyczą 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,

-oszczędność nakładów modelowania, -polimorfizm – wielość form operacji dla dziedziczonych klas - wirtualny mechanizm wywoływania funkcji, -naturalny system wyrażania czynności -zmniejszenie nakładów programowania,

49.Architektura oprogramowania i jej rola. Istota architektury trójpoziomowej i czteropoziomowej.

Architektura trójwarstwowa

-Twórcy SI starają się tak zaprojektować architekturę, aby odseparować silnie zależne od

technologii i narzędzi programistycznych interfejs użytkownika i bazę danych od logicznych i pojęciowych, odnoszących się bezpośrednio do rozwiązywanego problemu, zagadnień.

-Architektura trójwarstwowa, której standard został wprowadzony w 1978 przez komitet ANSI/SPARC, proponuje podział systemu na trzy poziomy: jego fizyczną implementację

(tzw. „schemat wewnętrzny”), abstrakcyjny model wycinka rzeczywistości (biznesu, firmy)

odzwierciedlanej przez system (tzw. „schemat pojęciowy”) oraz poziom zewnętrzny, reprezentujący sposoby, w jakie system jest postrzegany z zewnątrz (tzw. „schematy zewnętrzne”).

Architektura czterowarstowa

Warstwy na diagramie są od siebie zależne – komunikują się ze sobą. Zasadą jest, że komunikacja następuje tylko między warstwami sąsiadującymi. Przykładowo warstwa styku z użytkownikiem nigdy nie komunikuje się bezpośrednio z warstwą przechowywania danych.

Bardzo ważny w szkielecie jest również kierunek komunikacji. Warstwa logiki środowiska

nie jest np. zależna i nie uruchamia komunikacji z warstwą logiki aplikacji, natomiast istnieje

zależność odwrotna. Wynika to z tego, że czynności na poziomie logiki środowiska nie wymagają uruchamiania jakiejś funkcjonalności na poziomie aplikacji. Warstwa logiki

aplikacji musi się natomiast komunikować zarówno z logiką środowiska, jak i ze stykiem z

użytkownikiem.

50. Zasady projektowania interfejsu użytkownika.

Tworzenie interfejsu użytkownika jest:

– stosunkowo łatwe bowiem „nie są potrzebne żadne algorytmy bardziej wyrafinowane niż

wyśrodkowanie jednego prostokąta w innym”.

– proste, gdyż popełnione błędy są widoczne bezpośrednio na ekranie i można je zaraz

poprawić.

– przyjemne, bo wyniki pracy są natychmiast widoczne.

Zbliżenie do użytkownika - Interfejs powinien posługiwać się pojęciami i kategoriami wziętymi

z doświadczeń osób, które najczęściej będą korzystać z systemu.

Spójność - Interfejs powinien być spójny, tzn. tam, gdzie to jest możliwe, podobne operacje

powinny być wykonywane w ten sam sposób, także w podobnej tonacji kolorystycznej.

Minimum niespodzianek - Użytkownicy nie powinni być zaskakiwani zachowaniem systemu.

Możliwość wycofania - Interfejs powinien obejmować mechanizmy, które umożliwiają

użytkownikom wycofanie się z błędów.

Porady dla użytkownika - Interfejs powinien przekazywać znaczące informacje zwrotne, gdy

dochodzi do błędów. Powinien też oferować pomoc, której treść zależy od kontekstu.

Rozróżnianie użytkowników - interfejs powinien oferować udogodnienia do interakcji

dostosowane do różnych rodzajów użytkowników systemu.

51. 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ć.