27.Omów przykłady nieobiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.
Metodyki strukturalne - łączą statyczny opis danych oraz statyczny opis procesów.
Do tej klasy należą:
Metodyka Yourdona (DeMarco i Ward/Mellor);
Structured System Analysis and Design Methodology (SSADM);
Structured Analysis and Design Technique (SADT).
Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli oraz iż pomimo dojrzałości, mogą nie być adekwatne do współczesnych tendencji wytwarzania systemów informatycznych;
Przykład metodyki - CDM-Oracle-1996
stosowana do procesów biznesowych i funkcji, które nie mogą być obsłużone za pomocą dostępnych aplikacji „z półki”;
CDM jest zbiorem zdefiniowanych procesów tworzenia oprogramowania, które zostały określone przy założeniu, że w procesie wytwórczym stosowane są metody i narzędzia CASE;
zakłada, że potrzeby biznesowe zostają wyraźnie zdefiniowane na samym początku cyklu projektowego oraz że ich zweryfikowanie jest możliwe podczas całego procesu wytwórczego;
CDM wyróżnia następujące procesy:
definicja potrzeb biznesowych (studium możliwości),
analiza istniejących systemów,
opracowanie architektury technicznej,
projektowanie i budowa bazy danych,
projektowanie i budowa modułów,
konwersja danych,
opracowanie dokumentacji technicznej,
testowanie,
szkolenie,
przejście na nowy system,
obsługa serwisowa;
28.Omów przykłady obiektowego podejścia do analizy, projektu i implementacji systemów informatycznych.
/* Pytanie brzmi omów PRZYKŁADY więc jakiś geniusz od poprzedniej ściągi nie bardzo zrozumiał pytanie i na przekór nie przytoczył ANI JEDNEGO przykładu metodyki. Jest tego w chuja i nie widzę sposobu spamiętania wszystkich tych pierdół w podpunktach. Załączam przekroje metodyk z wykładów */
Analiza i Projektowanie - metody obiektowe
Wspólna zasada: zaczynamy od rozpoznania struktury obiektów. Najważniejsze jest, czym są obiekty, a nie co robią.
Wspólne kroki wszystkich metod obiektowych:
Identyfikacja klas i obiektów, ich atrybutów i metod
Ustalenie powiązań między obiektami
Ustalenie interfejsu każdego obiektu (protokołu)
Ustalenie współpracy obiektów, przepływ informacji
Implementacja, tworzenie prototypu.
# Przykład- Metoda Coad/Yourdon
5 głównych czynności
1. znajdowanie klas i obiektów
2. identyfikacja struktur
3. identyfikacja tematów
4. definiowania atrybutów
5. definiowania usług
model analizy obiektowej zawiera 5 warstw
1. warstwa tematów
2. warstwa klas i obiektów
3. warstwa struktury
4. warstwa atrybutów
5. warstwa usług
# Przykłąd Analiza metoda OMT (metoda Rumbaugh)
OMT - Object Modelling Technique
3 części składowe modelu, pokazujące różne jego aspekty:
Model Obiektów (OMT Object Model)
statyczny obraz struktury modelu
- klasy
- atrybuty
- operacje
- relacje między klasami i instancjami (powiązania - asocjacje,
całość - część (agregacje), gen- spec)
Model Dynamiczny (OMT Dynamic Model)
współdziałanie obiektów (powiązania wyznaczone przez komunikaty).
Tu mieszczą się różne diagramy pokazujące przepływ sterowania,
także ograniczenia i warunki na wartości atrybutów.
Model Funkcyjny (OMT Functional Model)
specyfikacja operacji jako funkcji przekształacących wejście na
wyjście, warunki poprawności (asercje).
# Ogólnie w temacie o analizie obiektowej
- opracowanie modelu obiektowego dziedziny zastosowania;
- rozpoznane obiekty odzwierciedlają byty i operacje związane z rozwiązywanym problemem;
Projektowanie obiektowe
- opracowanie modelu obiektowego systemu oprogramowania, który będzie implementacją zidentyfikowanych wymagań;
- obiekty projektu obiektowego są związane z rozwiązaniem problemu;
Zadania w etapach fazy projektowania:
- uściślenie istniejących definicji klas, np. metod,
- dziedziczenie klas i operacji,
- szczegółowy projekt operacji wraz z przeprojektowaniem ich algorytmów,
- wprowadzenie ogólnych mechanizmów realizacji dynamiki obiektów,
- decyzje o trwałości obiektów,
- modularyzacja i ukrywanie informacji,
- optymalizacja modelu,
- dokumentacja projektu;
Programowanie obiektowe
- realizacja projektu oprogramowania za pomocą języka programowania obiektowego;
- języki obiektowe umożliwiają bezpośrednią implementację obiektów i dostarczają udogodnienia do definiowania klas obiektów;
29.Co to jest system informatyczny i jakie są jego główne wyznaczniki jakości.
System informatyczny jest złożoną konstrukcją, której stopień skomplikowania zależy od złożoności architektury. Wielkie systemy są zwykle podzielone na podsystemy, które oferują pewien zbiór powiązanych ze sobą interfejsów;
System informatyczny to złożony program komputerowy lub zespół współdziałających ze sobą programów, przeznaczonych do wykonywania określonych funkcji: np. system operacyjny, system zarządzania bazami danych .
Najczęściej o systemie informatycznym mówi się wtedy, gdy do zbierania, gromadzenia, przesyłania i przetwarzania danych zastosowane są techniczne środki informatyki, a przynajmniej komputer do przetwarzania. Zestaw technicznych środków informatyki jest przeznaczony do realizacji zadań określonych przez system informacyjny .
Podsumowując - system informatyczny to określony obszar systemu informacyjnego danego obiektu, obsługiwany za pomocą technicznych środków dostępnych w informatyce.
Wyznaczniki jakości systemu informatycznego:
zgodny z wymaganiami użytkownika
-niezawodny
-efektywny
-łatwy w konserwacji
-interoperacyjny (jeżeli nie jest autonomiczny)
-ergonomiczny
System informatyczny - jest to zbiór powiązanych ze sobą elementów, którego funkcją jest przetwarzanie danych przy użyciu techniki komputerowej. Na systemy informatyczne składają się obecnie takie elementy jak:
sprzęt - obecnie głównie komputery, oraz
urządzenia służące do przechowywania danych
urządzenia służące do komunikacji między sprzętowymi elementami systemu
urządzenia służące do komunikacji między ludźmi a komputerami
urządzenia służące do przetwarzania danych nie będące komputerami
zasoby osobowe - ludzie
elementy organizacyjne - czyli procedury (procedury organizacyjne - termin z zarządzania) korzystania z systemu informatycznego, instrukcje robocze itp.
30.Omów podstawowe diagramy statyczne w języku IBM/Rational UML.
Diagram klas - to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez ilustrację struktury klas i zależności między nimi. Elementami występującymi w diagramie klas są:
-klasy
-interfejsy
-grupy współdziałania
Pomiędzy elementami występującymi na diagramie klas występują związki:
-zależności
-generalizacji
-asocjacji
-agregacji
Diagram klas jest najczęściej wykorzystywanym diagramem w notacji UML.
Diagram obiektów - (Object Diagram)zamiast klas pokazują instancje. Przydają się do wyjaśniania drobnych elementów ze skomplikowanymi relacjami, zwłaszcza rekurencyjnymi. Każdy prostokąt na diagramie obiektów odpowiada pojedynczej instancji. Nazwy instancji na diagramach UML są podkreślone. Nazwy klas lub instancji mogą zostać pominięte na diagramach obiektów, pod warunkiem, że sens diagramu pozostaje jasny.
Diagram komponentów - (Component Diagram) (zwany także diagramem implementacji) to diagram przedstawiający jeden z aspektów modelu zgodnego z UML. Przedstawia fizyczne elementy wchodzące w skład systemu i połączenia między nimi. Elementami tymi są: Komponenty przedstawiane za pomocą dużego prostokąta, z dwoma mniejszymi z jego lewej strony oraz z etykietą w środku. Komponenty mogą być przedstawiane zarówno jako klasy jak i instancje. Klasa oznacza elementy systemu istniejące podczas jego działania (np. interfejs użytkownika czy dane). Konkretne instancje precyzują o jaki element chodzi (np. okno programu będące częścią interfejsu). Węzły są to zasoby sprzętowe dostępne podczas działania systemu. Obrazowane są za pomocą prostopadłościanów. Zależności
Diagram pakietów - (Package Diagram)to diagram służący do porządkowania struktury systemu. Stosowane, aby uprościć skomplikowane diagramy klas, klasy grupujemy w pakiety. Pakiet to zbiór logicznie powiązanych elementów UML. Pakiety to prostokąty z małymi zakładkami na górze. Nazwa pakietu znajduje się na zakładce albo wewnątrz prostokąta. Strzałki z przerywanymi liniami to zależności. Jeden pakiet jest zależny od drugiego, jeśli zmiany w drugim pakiecie mogą wymusić zmiany w pierwszym.
Diagram wdrożenia - (Deployment Diagram) obrazuje konfigurację węzłów działających w czasie wykonania i zainstalowane na nich komponenty. Odnosi się do statycznych aspektów perspektywy wdrożeniowej. Wiąże się z diagramem komponentów, ponieważ zwykle każdy węzeł zawiera conajmniej jeden komponent.
Diagramy wdrożenia zawierają na ogół węzły i powiązania między nimi. Są przydatne do modelowania systemów rozproszonych i typu klient-serwer.
31.Omów podstawowe diagramy dynamiczne w języku IBM/Rational UML.
Diagram przypadków użycia ( Use Case Diagram)
Diagramy przypadków użycia opisują, co robi system z punktu widzenia zewnętrznego obserwatora. Eksponują to, co robi system, a nie jak to robi. Diagramy przypadków użycia pozostają w bliskim związku ze scenariuszami. Przypadek użycia to podsumowanie scenariuszy pojedynczego zadania lub celu. Aktor to ktoś albo coś, co inicjuje zdarzenia związane z tym zadaniem. Aktor po prostu określa rolę, którą odgrywa człowiek lub obiekt.
Jeden przypadek użycia może mieć wielu aktorów.
Diagramy przypadków użycia mają trzy zastosowania:
-Określanie funkcji (wymagań). Nowe przypadki użycia często generują nowe wymagania, kiedy system jest analizowany i projekt przybiera coraz wyraźniejszy kształt.
-Komunikacja z klientami. Prostota notacji sprawia, że diagramy przypadków użycia są dobrym sposobem porozumiewania się programistów z klientami.
-Generowanie przypadków testowych. Zbiór scenariuszy danego przypadku użycia może zasugerować sposoby testowania tych scenariuszy.
Diagram stanów. (State Machine Diagram)
Obiekty cechują się zachowaniami i stanem. Stan obiektu zależy od jego bieżącej aktywności lub warunków. Diagram stanów pokazuje możliwe stany obiektu oraz przejścia, które powodują zmianę stanu. Stany to zaokrąglone prostokąty. Przejścia to strzałki wiodące od jednego stanu do drugiego. Zdarzenia lub warunki wyzwalające przejścia są zapisane obok strzałek.
Diagram czynności (Activity Diagram) to szczególny przypadek diagramu stanów, który obrazuje strumień kolejno wykonywanych czynności.
Diagram czynności obrazuje przepływ sterowania (jest właściwie schematem blokowym). Przedstawia sekwencyjne (ew. współbieżne) kroki procesu obliczeniowego.
Diagram czynności zawiera na ogół stany (akcji i czynności), przejścia oraz obiekty. Wykonywane obliczenia nazywamy stanami (akcji lub czynności). Stany akcji i czynności są szczególnymi przypadkami stanów maszyny stanowej. Diagram czynności jest rodzajem maszyny stanowej.
Tory wskazują umiejscowienie czynności. Występując na diagramie czynności są pooddzielane pionowymi, ciągłymi liniami. Każdy tor ma unikatową nazwę.
Diagram sekwencji zdarzeń (przebiegów)
Opisują one, jak obiekty ze sobą współpracują. Diagram sekwencji to diagram interakcji, który szczegółowo pokazuje, w jaki sposób są wykonywane operacje - jakie komunikaty są wysyłane i kiedy. Czas upływa w miarę poruszania się w dół strony. Obiekty zaangażowane w operację są wymienione od lewej do prawej według tego, kiedy biorą udział w sekwencji komunikatów.
Diagram współpracy (kooperacji)
Diagramy współpracy to diagramy interakcji. Dostarczają tych samych informacji co diagramy sekwencyjne, ale skupiają się na rolach obiektów, a nie na czasach przesyłania komunikatów. Na diagramie sekwencyjnym role obiektów są wierzchołkami, a komunikaty - liniami łączącymi wierzchołki.
Prostokąty opisujące rolę obiektu są oznaczone nazwami klas lub obiektów (albo obiema nazwami). Nazwy klas są poprzedzone dwukropkiem ( : ).
32.Omów podstawowe diagramy w metodyce Oracle CASE Method.
Diagram zależności
Diagram zależnosci to narzedzie do przedstawiania złożonych zależnosci miedzy przyczynami i skutkami. Diagramy zależnosci pozwalajż odnalećź często trudną do wykrycia zależnosc problemu od pierwotnej przyczyny. Pomagaja zilustrowac łancuchy zaleznosci i wzajemnych zaleznosci, przez co ułatwiaja podjecie działania w odpowiednim miejscu. Pomagaja równiez w identyfikacji efektów ubocznych tych działan. Diagram dokumentujący zależności między elementami danych nazywa się diagramem zależności lub diagramem determinowania.
● Elementy danych rysowane są w postaci owali, kółek lub baniek.
● Zależność funkcyjna oznaczana jest przy pomocy strzałek łączących element determinujący z zależnym
Diagram zależności przedstawia kolejność wykonywania wcześniej ustalonych funkcji elementarnych. Dotyczy zależności informacyjnych. Jest to tzw. diagram następstw, uwzględniający zdarzenia inicjujące wykonanie funkcji oraz ich wyniki. Przedstawia wszystkie możliwe drogi postępowania, zatem wymaga użycia operatorów relacji OR, AND i XOR.
Diagram przepływu danych - DFD (ang. Data Flow Diagram) . diagramy przepływu danych pozwalają na modelowanie procesów w systemie informatycznym lub organizacji. Podstawowe elementy diagramów DFD
to:
· proces (ang. process),
· przepływ (ang. flow),
· magazyn inaczej skład/składnica danych (ang. datastore),
· terminator (ang. terminator) inaczej jednostka zewnętrzna (ang external entity).
Każdy z powyższych elementów ma odpowiedni symbol graficzny jednoznacznie wyróżniajacy go
na diagramie. Niestety, różne metodyki używają różnej symboliki . zwykle jednak koncepcja i semantyka
diagramów jest jednakowa.
-Funkcje — (procesy) realizują określone cele; jeśli funkcji nie można rozbić na pod-funkcje, wówczas nosi ona nazwę elementarnej.
-Magazyny danych — trwałe lub tymczasowe składnice danych, które są argumentami dla funkcji.
-Terminatory — obiekty, które nie są częścią systemu, ale stanowią odbiorców bądź źródła danych lub argumentów funkcji.
Przepływy — elementy pokazujące kierunek przesyłu danych (np. bajtów, znaków, pakietów..).
Diagram przepływu danych obrazuje za pomocą przepływów kierunek przepływu danych pomiędzy funkcjami, magazynami i obiektami zewnętrznymi.
33.Porównaj następujące podejścia do analizy i projektowania systemów informatycznych:
1) podejście: encja-związek, 2) podejście obiektowe.
/* zagadnienie troche niedopowiedziane, ale możne ładnie wode polać w temacie*/
W analize i projektowaniu systemów inf. rozróżniamy dwa podejścia - strukturalne i obiektowe.
Podejście encja-związek jest strukturalne - diagramy encja-związek występuja w strukturalnej metodyce SSADM. Model taki opisuje statyczna strukturę systemu, grupując dane w kolekcje zwane
obiektami (encje). Graficznym odpowiednikiem jest diagram ERD (ang. Entity Relationshi
Diagram), którego węzły reprezentują obiekty natomiast łuki odzwierciedlają relacje
pomiędzy obiektami. Przy podejściu bazodanowym, gdy występuje spora ilość danych, korzystne jest rozróżnianie rodzajów danych oraz prześledzenie ich przepływu.
Obecnie najbardziej rozpowszechnione jest podejście obiektowe. Cechuje się ono przejrzystością oraz wygodą tworzenia modelów. Intuicyjnie dokonywane jest powiązywanie metod z danymi, na których one operują. Pomiędzy obiektami można w prostszy sposób zamodelować interakcję.
Model obiektowy skupia się bardziej nad tym jak dane są przetwarzane, jaki jest do nich dostęp, jaka jest wymiana danych pomiędzy obiektami. W modelu obiektowym na drugi plan przesunięte jest jak dane są przechowywane, a także jak są reprezentowane. Znacznie istotniejsze jest kto ma do nich dostęp, jakie obiekty biorą udział w ich przetwarzaniu i jakie metody operują na danych. Podejście to jest korzystne dla wszystkich systemów, gdzie konieczna jest odpowiednia kontrola dostępu do danych, poprawności danych, oraz kontrola sposobu przetwarzania.