Projektowanie systemów informatycznych
Przedstaw techniki (diagramy) stosowane w analizie i projektowaniu obiektowym.
Metodyka Jacobsona - OOSE (Object Oriented Software Engineering )
nastawiona na modelowanie użytkowników, wymagań funkcjonalnych, cyklu życia systemu informatycznego
niekompletnie modeluje dziedzinę przedmiotową
Model Obiektów według Jacobsona
obiekty
powiązania
komunikacja między obiektami
Obiekty:
obiekty interfejsu
osoby, urządzenia wewnętrzne systemu biznesowego, które komunikują się z aktorem lub aktor z nimi w trakcie przypadku użycia (kasjer, pracownik informacji, kelner). Klient kontaktuje się bezpośrednio z interfejsem
obiekty sterujące
aktywne elementy systemu które bezpośrednio nie komunikują się z aktorem ale wykonują inne ważne czynności niezbędne do realizacji procesu biznesowego modelowanego w przypadku użycia (np. magazynier, kucharz)
obiekty encję
bierne elementy systemu niezbędne do procesu biznesowego modelowanego przypadkiem użycia - to są produkty materialne 9rachunek, faktura, komponenty)
Powiązania:
Takie same elementy jak na diagramie związków encji. Asocjacje : 1:1, 1:n, n:n Mogą być jeszcze agregacje i uogólnienia
Komunikaty:
Wysyłanie komunikatów (wywołań operacji przypisanych do obiektów) w celu wykonania określonych zadań
Metodyka Booch'a - OODA (Object Oriented Design with Application )
dobrze obsługuje fazę projektowania, implementacji i związki systemu z środowiskiem implementacji
obsługa fazy analizy, nie ma dobrych technik rozpoznania wymagań użytkowników
Metodyka Booch'a skupia się na dostarczeniu narzędzi umożliwiających w miarę proste przedstawienie pojedynczego systemu tak by mógł być łatwo zaimplementowany. Proces rozwoju systemu podzielono na fazy: strategii, analizy, projektu, zmian i pielęgnacji systemu. Metodyka dostarcza różnych, powiązanych ze sobą modeli:
Model Logiczny - opisuje klasy i obiekty projektowanego systemu;
Model Fizyczny - opisuje oprogramowanie i sprzęt, które ma się składać na projektowany system;
Model Statyczny - opisuje statyczne niezmienne w czasie aspekty systemu: klasy, obiekty, moduły, procesy;
Model Dynamiczny - opisuje dynamiczne, zmieniające się w czasie cechy systemu: zmiany stanów i scenariusze;
Metodyka Rumbaugh'a - OMT (Object Modeling Technique )
nastawiona na modelowanie dziedziny przedmiotowej
modelowanie wymagań użytkownika i sprawy implementacyjne
Metodyka Raumbaugh'a (Object Modelling TechniQue) - opisuje klasy i ich związki w trakcie procesu tworzenia projektowanego systemu. Proces tworzenia systemu został podzielony na siedem faz: strategii, analizy, projektu systemu, projektu obiektów, implementacji, testowania, pielęgnacji. W trakcie tych faz modeluje się system z trzech punktów widzenia używając do tego trzech różnych powiązanych ze sobą modeli:
Model Obiektów - opisuje statyczną stronę systemu pokazując strukturę obiektów w systemie wraz z informacjami o ich atrybutach, metodach i wzajemnych powiązaniach;
Model Dynamiczny - opisuje zmieniające się w czasie zachowanie projektowanego systemu, podstawowe pojęcia z nim związane to zdarzenie oraz stan, rozumiany jako kolekcja powiązań obiektu z innymi obiektami; model umożliwia opis zdarzeń zachodzących w systemie i dozwolonych sekwencji zdarzeń dla każdego obiektu;
Model Funkcjonalny - opisuje działania wykonywane przez system: przepływ danych i współdziałanie obiektów;
Przedstawić różnice między związkiem agregacji a związkiem uogólnienia (podać przykłady obu związków).
Związek uogólnienia ( generalizacji, specjalizacji )
Dwie klasy pozostają w związku uogólnienia jeżeli jedna z nich zawiera specjalizację, jest rodzajem drugiej
Klasa specjalizująca jest typem klasy uogólnionej
Osoba |
|
|
Klasa osoba
to uogólnienie
klasy pracownik
Student |
|
|
Pracownik |
|
|
Klasa pracownik
to uogólnienie
klasy kierownik projektu
Kierownik Projektu |
|
|
Generalizacja może mieć wiele specjalizacji i na odwrót
Związek agregacji ( związek całość - część )
Jeżeli obiekt pewnej klasy tworzy całość składającą się z obiektów innych klas stanowiących części, w tym związki obiektów należące do całości, nie muszą być tego samego typu co obiekty stanowiące części.
Związek agregacji w szczególnym przypadku sprowadza się do kompozycji, dotyczy on wtedy bytów tego samego typu
wszystkie części w kompozycji przynależą tylko do jednej części - zlikwidowanie tej całości pociąga za sobą likwidację tych części
W przypadku agregacji ( normalnym ) - byty mogą być różnych typów i części występujące mogą przynależeć do więcej niż jednej całości - likwidacja całości nie likwiduje części
( likwidacja uczelni ( całości ) )
( likwiduje wydział ( część ) )
Szczególnym przypadkiem agregacji jest agregacja tego samego typu.
Wskazać sposób zastosowania związków uogólnienia w odniesieniu do wybranej klasy.
Dziedziczenie jest wynikiem związku uogólnienia
Osoba |
Data urodzenia Imie i nazwisko Adres |
Wylicz wiek ( ) |
Student |
Numer indeksu Średnia ocen |
Stypendium ( ) |
|
Data zatrudnienia Stanowisko Stawka godzinowa |
Zarobek ( )
|
Kierownik Projektu |
Liczba projektów |
Dodaj nowy projekt ( ) |
Określić przykładowe związki agregacji w dziedzinie odnoszącej się do działalności Uniwersytetu.
Przedstawić cztery warunki konieczne metodyki obiektowej.
Abstrakcja
Jako uogólnienie, pojecie definiowane zgodnie z zasadą Dijkstry. Polega na podziale systemu na poziomy tworzące pewne hierarchie. Każdy utworzony poziom stanowi uogólniony model systemu w postaci powiązanych ze sobą elementów składowych opisujących jedynie istotne dla tego poziomu aspekty systemu, a pomijający wszystkie nieważne aspekty.
W modelach obiektowych abstrakcję definiujemy jako uogólniony model obiektu bądź klasy opisujący istotne z pewnego punktu widzenia cechy tegoż obiektu, natomiast pomijamy cechy nie istotne.
Wyróżniamy dwa rodzaje abstrakcji:
Kompozycyjna
Zbiór pewnych obiektów, które tworzą nową jakość.
Uogólniona
Polega na utworzeniu nowej jakości na podstawie cech obiektu należących do pewnego zbioru charakteryzującego się pewnymi cechami wspólnymi dla tych obiektów.
Modularność
Moduły muszą być bardzo silnie spójne, natomiast powinny być bardzo luźno i słabo powiązane ze sobą.
Modularność w modelu strukturalnym doprowadziła drogę dekompozycji procesu do poziomu funkcji elementarnych.
Hierarchizacja
Wywodzi się od poziomu abstrakcji Dijkstry. W modułach obiektowych system można podzielić na prawie dowolne struktury zbudowane ze składników reprezentujących obiekty i klasy. Wyróżniamy hierarchię kompozycyjną i uogólnioną.
Enkapsulacja
Staramy się schować, ukryć w module zarówno struktury danych jak i sposób realizacji funkcji.
Enkapsulacja umożliwia przede wszystkim praktyczne zrealizowanie koncepcji abstrakcji, gdyż inne moduły widzą jedynie to co jest dla nich ważne i potrzebne do wzajemnej współpracy.
Omówić statyczny model struktur danych w standardzie UML.
Najpopularniejszym modelem konceptualnym danych jest model ER. Graficznym elementem takiego modelu danych jest diagram związków encji (ERD). Podstawowymi pojęciami modelu ER są obiekt (ang. entity), związek (ang, relationship) oraz a:rybut (ang attribute). Obiekt jest to coś, co istnieje i jest odróżnialne. Obiekty mają swoje własności (cechy charaktery styczne) zwane atrybutami, takie jak nazwa, waga, cena. wiek itp. (dokładniej — atrybut jest funkcją przypisującą obiektowi wartość cechy ze zbioru wartości tej cechy, czyli z dziedziny). Będziemy dalej używali pojęcia atrybutu w znaczeniu nazwy pewnej własności obiektu. Obiekty mające te same atrybuty łączy się w typy obiektów. Przykładami typów obiektów mogą być Klient, Produkt, Część, Rachunek. Typ Klient jest zbiorem różnych klientów, z których potrafimy każdego odróżnić. Taki atrybut (tub zestaw atrybutów), którego wartości w sposób jednoznaczny identyfikują każdy obiekt w zbiorze obiektów (typie), nazywa się kluczem. Na przykład atrybut kod_wyrobu w typie Wyrób pozwala jednoznacznie zidentyfikować każdy wyrób, stanowiąc klucz. Związki pomiędzy obiektami przedstawiają powiązania w świecie rzeczywistym — na przykład obiekt Wyrób składa się z obiektów części. Diagram ten spotyka się w różnych graficznie postaciach. My przyjmiemy notację zwaną czasem notacją „wronich łapek. Typy obiektów są przedstawione za pomocą prostokątów, a linie łączące te prostokąty symbolizują istniejące powiązanie między konkretnymi obiektami należącymi do łączonych typów Powiązanie między obiektami w zależności od swojej charakterystyki przedstawiane jest linią z pewnymi „dodatkami" — na przykład z „wronimi łapkami''. („Case dla ludzi”)
Model danych w systemie przedstawiony za pomocą ERD służy do zilustrowania statycznej struktury danych w systemie w sposób niezależny od konkretnego systemu zarządzania bazą danych.
Metoda budowania modelu danych systemu :
identyfikacja (wydzielenie) zbioru obiektów (tzn, grup danych) w systemie wraz z ich atrybutami kluczowymi;
identyfikacja powiązań bezpośrednich miedzy obiektami (ewentualnie z wykorzystaniem tablicy krzyżowej powiązań) oraz ich rodzaju,
przekształcenie tablicy krzyżowej powiązań w pojęciowy model danych i identyfikacja pozostałych atrybutów obiektów;
przekształcenie każdego z powiązań typu M:N na dwa powiązania typu 1:N i identyfikacja dodatkowych atrybutów charakterystycznych dla nowo powstałych obiektów;
sprawdzenie poprawności otrzymanej struktury poprzez porównanie z wymaganiami systemu.
Omówić wybrany model dynamiczny w standardzie UML.
ELH pokazuje zmiany w encjach w czasie a te zmiany są wymuszone zdarzeniami które oddziaływają na encję. To jest diagram dynamiczny. Służy aby w jawny sposób pokazać wszystkie zdarzenia zachodzące w systemie, zarówno zdarzenia typowe (normalne) oraz zdarzenia nietypowe (nadzwyczajne, błędne, wskazujące na sytuację awaryjną - jest ich więcej niż normalnych i powodują dużo więcej błędów niż normalne).
Odpowiada encji na ERD (skojarzenie)
DFD Procesy generujące przepływy aktualizujące |
DFD Magazyny danych
|
DFD Przepływ aktualizujący |
DFD Rodzaj aktualizacji |
Zdarzenie |
Proces 2 Ustalenie konta |
Konto Klienta (D1) |
Nowy rekord |
Utwórz nowy wpis w magazynie, przepływ typu C C - create (stwórz) |
Założenie konta |
Proces 4 Utworzenie rekordu pożyczki |
Konto Klienta (D1) |
Obciążenie konta |
Modyfikacja zawartości magazynu, przepływ typu U U - Update (aktualizuj) |
Uzyskanie pożyczki, przyznanie pożyczki |
Proces 7 Obsługa spłat |
Konto Klienta (D1) |
Spłaty |
Modyfikacja, przepływ typu U U - Update (aktualizuj) |
Każdorazowe dokonanie spłaty kolejnej raty pożyczki |
Proces 3 Funkcje utrzymania |
Konto Klienta (D1) |
Dezaktywacja |
Usunięcie wpisu w magazynie, przepływ typu D D - Delete (skasuj) |
Likwidacja konta |
C, U, D i R - ta notacja występuje też w SyBase.
MATRIX CRUD - macierz( tablica krzyżowa) pokazuje zależności między procesami a magazynami danych, pokazuje rodzaje przepływów między nimi
( C - create (utwórz), D - Delete (skasuj), U - Update (aktualizuj), R - Read (czytaj) )
Komponenty diagramu ELH
Diagram acykliczny ( typu drzewo, hierarchiczny )
Na danym poziomie naszego drzewa
odczytujemy w umowny sposób kolejność zdarzeń.
Zdarzenie na lewo jest wcześniejsze od zdarzenia na prawo itd.
Sekwencja zdarzeń jest odczytywana na danym poziomie od lewej do prawej. Zdarzenia iteracyjne to zdarzenia które powtarzają się pewną ilość razy (np. spłata kredytu), może być też 0 powtórzeń (brak wystąpienia zdarzenia). Zdarzenia selektywne zależą od spełnienia warunków ( coś ala „if” lub „switch” w C++)
Teraz nasz diagram ELH
Dwa etapy tworzenia diagramu ELH:
1 etap - utworzenie pomocniczej tablicy krzyżowej dla encji [magazynu danych] poprzez wybranie encji z diagramu związków encji, poprzez identyfikację zdarzeń dotyczących danej encji na podstawie przepływów aktualizujących ten magazyn danych na DFD w którym to magazynie znajduje się aktualizowana encja.
2 etap - rozważenie dla każdej encji wziętej z ERD następujących kwestii
normalnego, typowego cyklu życia
rozważenie zdarzeń specjalnych (wyjątkowych)
rozważenie sytuacji błędnych, awaryjnych
Tworzenie ELH w prawidłowym cyklu życia encji odbywa się według harmonogramu:
wybranie zdarzeń oddziaływujących na dane encje z tablicy krzyżowej
ustalanie sekwencji zdarzeń na danym poziomie drzewa historii życia encji
sprawdzenie czy pewne zdarzenia mają zachodzić warunkowo ( czy możliwa jest selekcja zdarzeń )
sprawdzenie czy zdarzenia mogą być iteracyjne ( zachodzące wielokrotnie )
jeśli iteracje występują to czy przypadkiem nie zmieniają one sekwencji zdarzeń czy system traktuje jednakowo wszystkie iteracje zdarzeń jednego, danego typu
Model konceptualny a model fizyczny struktur danych (w poznanym narzędziu CASE).
Model konceptualny struktur danych to diagram związków encji ERD
Możemy wyróżnić w tym modelu: encje, powiązania ( 1:1, 1:n, n:n ), każde powiązanie ma swoją nazwę.
Mamy tu również do czynienia z kluczem. Klucz jest atrybutem dzięki któremu dana encja jest rozpoznawana, „klasyfikowana”.Atrybuty, które nadawane są każdej encji, opisują tą encje. Atrybtuty mogą być różnego typu.
W tym modelu istnieje jeszcze możliwość przyporządkowania każdego typu danych do domen. Domeny to „zbieranie” danych jednego typu w jedną całość. Typy są przypisane atrybutom. Można stworzyć wiele domen ( np. typu integer, byte, string itp. ) dzięki nim, w narzędziu case, przy sprawdzaniu poprawności modelu ustrzeżemy się błędów związanych z źle przypisanymi typami oraz narzędzie CASE'owe nie będzie nam sygnalizować ostrzeżeń o typach nieprzypisanych do żadnych domen.
ERD diagram - (statyczny model struktur danych) na tym diagramie nie ma uwarunkowań czasowych ( dlatego statyczny, opisuje bierne elementy).
Model fizyczny uwzględnia składniki sterująco - koordynujące które powodują zwrot przepływu danych pomiędzy odpowiednimi modułami. Procesy z DFD przechodzą w struktury zwane modułami
Model fizyczny to model wygenerowany z modelu konceptualnego ( plik PDM - Psyhical data model - wygenerowany z pliku CDM - conceptual data model ). W tym modelu mamy klucze główne ( pk - primary key ) i obce ( fk - foreign key ). Klucz główny encji to klucz dzieki któremy dana encja jest identyfikowana a klucz obcy to klucz dziedziczony z innej encji, dzięki któremu mamy większe możliwość zidentyfikowania encji ponieważ jest ona opisywana większą ilością kluczy ( klucze są swego rodzaju „identyfikatorami” ) strzałki między encjami pokazują dziedziczenie kluczy. Strzałka skierowana w stronę danej encji oznacza że ta encja dziedziczy klucz główny ( który staje się kluczem obcym dla tej encji która go dziedziczy ) od encji z ktorej „wychodzi” strzałka.
Omówić wykorzystanie narzędzia CASE do projektowania systemu informatycznego.
Na podstawie metodyk opracowanych w pierwszej połowie lat osiemdziesiątych powstały obecnie cząstkowe lub kompleksowe pakiety wspomagające proces tworzenia systemów informatycznych. W dalszym ciągu powstaje wiek nowych, niezależnych technik. Tworzone są cale łańcuchy narzędzi właściwie dopasowanych do celów poszczególnych faz cyklu życia systemu Rozwój i stopniowe udoskonalanie różnych składników metodyki spowodowały powstanie warsztatu lub środowiska analityka i projektanta systemów (zespołu tworzącego oprogramowanie). Przez warsztat należy tu rozumieć ogół metodyk, modeli, technik oraz komputerowych pakietów służących tworzeniu systemów informatycznych. Sercem warsztatu jest centralna biblioteka (encyklopedia, słownik) zawierająca opis wszystkich składników systemu, którymi są:
struktury danych {obiekty, atrybuty, powiązania, ścieżki dostępu);
opis procesów w systemie;
opis interfejsów użytkownika (formatki ekranowe, dialogi, raporty);
opis wszystkich składników każdego z modeli systemu;
wzajemne powiązania między poszczególnymi składnikami systemu;
dane dotyczące zarządzania projektem (wersje, prawa dostępu);
ewentualnie kod, dokumentacja dla użytkownika.
Poszczególne narzędzia odpowiadają głównym fazom cyklu życia systemu: analizie, projektowaniu, wdrażaniu i utrzymaniu. Współczesną formą warsztatów pracy są zintegrowane pakiety typu CASE.
Zakres komputerowego wspomagania inżynierii programowania obejmuje:
określenie granic systemu informatycznego. Który ma zostać poddany informatyzacji
analizę i dekompozycję problemu na składowe odpowiadające elementom tego systemu
dobór najwłaściwszych metod i narzędzi realizacji tych składowych
syntezę systemu informatycznego.
Podstawową sprawą w CASE są techniki i metodyki.
Wśród oprogramowania CASE możemy wyróżnić:
Pakiety narzędziowe
Pakiety zintegrowane o charakterze zamkniętym
Możemy wyróżnić trzy poziomy zapotrzebowania na narzędzia CASE'owe:
Wysoki, nazywany też planowaniem wspomaganym komputerowo. Pozwala na przechowywanie w pamięci komputera i analizowanie informacji na temat struktury przedsiębiorstwa, jego celów, warunków osiągnięcia tych celów
Średni służy analizie i projektowaniu systemów informatycznych, w szczególności określaniu ich najbardziej efektywniej i odpowiadającej rzeczywistości struktury
Niski jest ukierunkowany na wspomaganie tworzenia programów realizujących funkcje opisane na wyższym poziomie w sposób co najmniej półautomatyczny, tzn. eliminujący konieczność pisania przez programistę fragmentów kodu realizujących powtarzalne w wielu systemach funkcje.
Wskazać różnice oraz podobieństwa w strukturalnym i obiektowym projektowaniu systemów informatycznych.
Projektowanie strukturalne: |
Projektowanie obiektowe: |
|
|
Omówić statyczny model danych w projektowaniu strukturalnym.
Odp. Pyt 6.
Omówić dynamiczny model danych w projektowaniu strukturalnym.
Odp. Pyt 7.
Komponenty i zastosowanie diagramu sekwencji.
Otoczenie Obiekt
(środowisko)
W diagramie sekwencji są różne obiekty które się nawzajem komunikują za pomocą komunikatów wysyłanych do siebie (komunikat jest przeważnie nazwą operacji)
Omówić pojęcia: operacje, metody, komunikaty - związane z zachowaniem się obiektu.
Sposób zachowania - jest to charakterystyka określająca jakie operacje mogą być dokonywane na obiekcie poprzez inne obiekty, jakie operacje może on wykonywać na innych obiektach, oraz jakie są konsekwencje dokonywania tych operacji w sensie zmian stanów danego obiektu oraz obiektów które były z nim w interakcji.
Rodzaje operacji: kategorie
Operacja konstruktora - tworzy obiekt wraz z ewentualnym zainicjowaniem zmiennych, jego stanu początkowego
Modyfikator - zmienia wartości atrybutów
Selektor - udostępnia informacje o stanie innego obiektu, nie powoduje jego zmiany stanu
Iterator - umożliwia dostęp do całej struktury obiektu poprzez sekwencyjne udostępnianie jej poszczególnych elementów w ściśle określony sposób.
Destruktor - potrafi usunąć obiekt
Operacja jest przyporządkowana do obiektu i każda operacja ma swoją nazwę. Wywołanie tej nazwy jest jednoznaczne z uruchomieniem tej operacji. - uruchomieniem aktywności obiektu. Natomiast metoda jest wewnętrzną specyfikacją tej operacji, to jest zapisanie kodu w jaki sposób operacja będzie realizowana. Operacja to to co widzą sąsiednie obiekty a metoda to sposób implementacji.
Formalna specyfikacja operacji.
warunki wstępne operacji ( niezmienniki umożliwiające wykonanie operacji, niezmienniki to wyrażenia logiczne odpowiadające warunkom które muszą być spełnione jeśli operacja ma być wykonana. Jeżeli niezmienniki nie są spełnione tzn. że coś jest nie tak i operacja nie zostanie wykonana )
sama semantyka operacji ( opis przebiegu działania algorytmu operacji )
warunki końcowe operacji ( niezmienniki jakie muszą być spełnione po wykonaniu operacji - jeśli niezmienniki nie zachodzą to znaczy że coś jest nie tak )
sytuacje szczególne ( wyjątki )
warunki niespełnione - oznacza że wykonanie operacji zostało zaniechane a informacja o niemożliwości wykonania i jej przyczyna jest przesłana do obiektu żądającego wykonania operacji
Aby wykonać jakąś operacje obiektu muszą się wzajemnie informować o tym. Zamiar wysyłania informacji między obiektami odbywa się za pomocą mechanizmu przesyłania komunikatów między obiektami. Wysłanie komunikatu to zamiar wykonania operacji. Zazwyczaj komunikat ma w sobie ( inaczej: ma nazwę ) nazwę operacji.
Porównać strukturalne i obiektowe projektowanie baz danych.
|
Relacyjne bazy danych |
Obiektowo - relacyjne bazy danych |
Obiektowe bazy danych |
Standard |
SQL2 (ANSI X3H2) |
SQL3/4 (w opracowaniu) |
ODGM-v2.0 |
Współpraca z obiektowymi językami programowania |
Słaba, programiści muszą dostosować program obiektowy do potrzeb bazy |
Graniczona gównie do nowych typów danych |
Bezpośrednia, szeroko rozumiana |
Użytkowanie |
Łatwa do zrozumienia struktura, wiele narzędzi dla użytkowników |
Zapewnia niezależność danych od aplikacji, trudno odzwierciedlać złożone powiązania |
Łatwe dla programistów, użytkownikom pozostaje pewien dostęp przez SQL |
Programowanie |
Zapewnia niezależność danych od aplikacji, trudno odzwierciedlać złożone powiązania |
Zapewnia niezależność danych od aplikacji, trudno odzwierciedlać złożone powiązania |
Obiekty w naturalny sposób odzwierciedlają dziedzinę, łatwość modelowania różnorodnych typów i powiązań |
Rozszerzalność |
brak |
Głównie ograniczona jest do nowych typów danych |
Daje sobie radę z dowolną złożonością dziedziny, użytkownicy mogą pisać metody i dołączać struktury |
Złożone dane i powiązania między nimi |
Trudne do zrealizowania |
Trudne do zrealizowania |
Daje sobie rade z dowolną złożonością dziedziny, użytkownicy mogą pisać metody i dołączać struktury |
„Dojrzałość” systemów |
Bardzo dojrzałe, dobrze poznana i przetestowana metodologia, liczne implementacje, stabilność na rynku |
Niedojrzałe, rozszerzenia są nowe, wciąż ewoluujące i stosunkowo słabo poznane |
Dość dojrzałe (dzięki powszechności OOA i OOD) |
Możliwość utrzymywania się na rynku |
Przewidywana dla dużych przedsiębiorstw obecnych na rynku |
Przewidywana dla przedsiębiorstw znanych z RDBMS, dołączają się nowi |
Na razie trudno prognozować mimo iż sukces modelu obiektowego wydaje się oczywisty |
|
Relacyjne |
Obiektowe |
Cechy podstawowe |
|
|
Przykłady systemów |
Oracle, Informix, Sybase, Ingres, DB2, Progress, Gupta, Access |
GemStone, O2, Persistance, Versant, POET, Objectivity, ODI |
Zalety |
|
|
Wady |
|
|
Lepsze gdy... |
|
|
Porównać ze sobą pojęcia: encja i klasa.
Encja |
Klasa |
|
|
Diagramy stanów w projektowaniu strukturalnym i obiektowym.
A: r
C: mój komputer
Stan 1 Wyświetla listę dysków
C: x
A: y
Stan 2 Wyświetla listę folderów dla
wybranego dysku
C: z
A: w
Stan 3 Wyświetla zawartość danego
Folderu
Akcja - odpowiada pojawieniu się przepływu wyjściowego sterującego r
Mój komputer - komputer który spowodował to że doszło do uruchomienia procesu 1.
Stan systemu opisuje co dzieje się z systemem w danej chwili czasu, który to czas zazwyczaj trwa niepomijalny kawałek czasu. Samo przejście zwane zmianą stanu jest opisane dwojako. Poprzez warunek (przyczynę), druga rzecz to akcja - czynność powzięta przez system która spowoduje zmianę stanu.
Zasady diagramu przejść stanu:
system w każdej chwili czasu jest w jakimś stanie
na tym Diagramie może być tylko jeden START i jeden STOP
każdy stan pośredni powinien być dostępny ze stanu początkowego ( pośrednio lub bezpośrednio )
stan końcowy musi być dostępny dla każdego stanu ( pośrednio lub bezpośrendio)
dany warunek musi powodować przejście danego stanu tylko do jednego jedynego stanu następnego
Diagram przejść stanów jest bardzo dobrą techniką opisu współpracy (dialogu) użytkownika z systemem a ten dialog to poruszanie się po całym menu jakie oferuje system.
Diagramy przejść stanów obiektowy ( state eharts )
diagram dynamiczny ( zależności czasowe nałożone na byty - klasy i obiekty
nazywany również diagramem Harela
diagram Harela nawiązuje do automatu skończonego, opisuje on stany pewnego procesu które są istotne z punktu widzenia modelu pojęciowego tego procesu oraz przejścia pomiędzy stanami. Diagram Harela odwzorowywał stany obiektów pewnej klasy podczas ich cyklu życia oraz przejścia pomiędzy stanami powodowanych przez zdarzenia lub komunikaty.
Komunikat ( druga przyczyna wywołania zmiany systemu ) -jeśli komunikat jest wysyłany do obiektu pewnej klasy oznacza to żądanie wykonania jednej z operacji przypisanej do tej klasy. Wywołanie komunikatu to wywołanie metody przypisanej do tej klasy. Nazwa komunikatu jest zazwyczaj nazwą wywoływanej metody.
Wysyłanie komunikatu może się wiązać z przekazaniem pewnych danych wejściowych do wywoływanej metody oraz z pobraniem danych wyjściowych tej metody.
Diagram stanów obiektów może pokazywać dynamikę zmian systemu, dynamikę zmian grup klas lub dynamikę zmian jednej, klasy. Zależy jak na ten diagram patrzymy:
Jeżeli patrzymy na diagram Harela w odniesieniu do danej klasy obiektów to na tym diagramie są wszystkie stany przez które klasa może przejść.( diagram ten będzie analogiczny do diagramy życia encji ( ELH ), ale nie będzie struktury drzewa)
Jeżeli diagram przejść stanów prezentuje dynamikę zmian wykonywanych w systemie funkcji (funkcje te realizowane są w metodach przypisanym poszczególnym klasom) to tak rozumiany diagram stanów służy do prezentowania sposobu realizacji funkcji systemowych.
Elementy obiektowe diagramu przejść stanów :
Zdarzenia
Stany
przejścia(transformacja )
akcja
operacja
zdarzenie - klasa zjawisk na które system reaguje w pewien sposób, w pewien podobny sposób
stany - pewien okres czasu w którym znajduje się system lub obiekt, trwa niepomijalny kawałek czasu, jest to okres czasu jaki upływa pomiędzy dwoma kolejnymi zdarzeniami które to pierwsze zdarzenie spowodowało ze nasz byt wszedł w ten stan, trwał niepomijalny kawałek czasu i potem drugie zdarzenie powoduje że wychodzi obiekt z tego stanu
przejście ( transformacja ) - przejście z jednego do drugiego stanu zaistniałym zdarzenie wywołującym zmianę stanu i może być jeszcze uwarunkowane spełnieniem pewnych warunków. Przejście odbywa się natychmiastowo, czas trwania jest pomijany
akcja - czynność wykonywana w momencie zajścia zdarzenia ponieważ zdarzenie też trwa króciutko to akcja jest wykonywana natychmiast, w pomijalnie krótkim czasie
operacja - czynność której wykonanie trwa niepomijalny kawałek czasu
operacje wykonywane są gdyby system był w jakimś stanie a stan system na daną
chwilę jest stabilny
akcja jest wykonywana w momencie zajścia zdarzenia a system na daną chwilę jest niestabilny
operacja może zostać przerwana w momencie zajścia zdarzenia, takiego któ®e powoduje wyjście z danego stanu
jeżeli operacja kończy się samoczynnie to kiedy się kończy generuje zdarzenie które może powodować przejście do innego stanu
Jak na diagramie są opisywane stany i przejścia?
|
Zdarzenie (parametr) [warunek] /akcja (to nie powoduje opuszczenia tego stanu) |
Entry - wejście do stanu, po tym stanie wypisuje się akcje wykonawczą w momencie wejścia do stanu niezależnie od tego jakie zdarzenie spowodowało przejście
Exit - po tym słowie wymienia się akcję wykonywania w momencie wyjścia ze stanu niezależnie od zdarzenia które spowodowało wyjście
Do - po tym wymienia się operację wykonywane w tyra stanie i w dowolnym stanie może być wykonywanych wiele operacji
w ramach opisu stanu wymienia się również zdarzenia których zajście nie powoduje przejścia do innego stanu
Przejścia między stanami
Zdarzenie (parametr) [warunek] / akcja
Komponenty następne
Start End
Entry: wyplacalny=l |
Klient wypłacalny |
exit: wypłacalny=0 exit: wypłacalny=2 |
Klient niewypłacalny |
exit: ustaw klienta=2 |
Entry: ustaw status klienta =0 |
|
Klient z kontem zerowym |
exit: zapisz konto zerowe |
Składniki modelu pojęciowego UML.
Składa się z bloków konstrukcyjnych.
BLOKI KONSTRUKCYJNE
ELEMENTY
podstawowe składniki DIAGRAMY
każdego sytsemu ZWIĄZKI schematy grupujące
połączenia pomiędzy istotne elementy
elementami
RODZAJE ELEMENTÓW - strukturalne - czynnościowe - grupujące - komentujące |
RODZAJE ZWIĄZKÓW - zależności - powiązanie - uogólnienia - realizacja |
|
Elementy strukturalne - klasa - interfejs - kooperacja - przypadek użycia - klasa aktywna - komponent - węzeł |
Elementy czynnościowe - instrukcje - maszyny stanowe
|
Związki - zależności - uogólnienie
|
Diagramy opisujące statyczne struktury danych - diagram klas - diagram obiektów, diagram pakietu
|
Diagramy dynamiczne - diagram stanów - diagram aktywności - diagram sekwencji - diagram współpracy |
Diagramy fizyczne - diagram komponentów - diagramy struktury sprzętowej
|
DIAGRAMY - grafy w których wierzchołkach są elementy, natomiast krawędzie to związki.
Modele cyklu życia systemu informacyjnego lub informatycznego - liniowy, z prototypem, spiralny.
Model liniowy
Szkolenie pracowników odbywa się podczas m.in. projektowania i testowania
Model logiczny - odpowiada na pytanie co system ma robić - bez odwoływania się do rozwiązań implementacyjnych
Model fizyczny - w jaki sposób ma zostać zrealizowany powyższy model
Model liniowy - cykl życia Systemu Informatycznego(powyższy rysunek).
Model z prototypem - model cyklu życia SI
Zgodnie z definicją R. Barker'a - prototypowanie jest metodą szybkiej prezentacji pojęć, w celu uzyskania akceptacji użytkownika i sprawdzenie wykonywalności.
Model z prototypem jest polecany kiedy istnieją trudności ze sformułowaniem wymagań użytkownika do końcowego projektu.
Tworzenie prototypu ma na celu przede wszystkim doprecyzowanie tych założeń użyt. które są trudne do założenia.
Zalety modelu z prototypem |
Wady modelu z prototypem |
1. Minimalizacja ryzyka związanego z niemożnością określenia wymagań przez użytkownika 2. Szybka demonstracja użytkownikowi działającej wersji systemu (wersja beta) 3. Szybkie wykrycie nieporozumień pomiędzy użytkownikiem a projektantem, które mogłyby powstać w fazie określania wymagań. 4. Możliwość wykrycia brakujących funkcji systemu lub trudnych usług. 5. Redukcja czasu oczekiwania na kolejne etapy. 6. Stały kontakt pomiędzy użytkownikiem a projektantem. |
1. Dodatkowe koszty budowania prototypu. 2. Długie oczekiwanie na ostateczny etap. |
Istnieją dwa typy prototypowania
Prototypowanie szybkie
Jest tu sprzężenie zwrotne - modyfikacja wymagań według wskazówek użytkownika
Prototypowanie strukturalne
W prototypowaniu strukturalnym tworzony jest tylko i wyłącznie w celu bardziej precyzyjnego sformułowania wymagań przez użytkownika (stosować w przypadku złożonych systemów)
Model spiralny
Kalkulacja kosztów
1987 Barry Boehm
Model spiralny opisuje cykl życia SI w kolejnych wersjach.
Modelowanie wymagań użytkownika w podejściu strukturalnym i obiektowym.
Model wymagań użytkownika w podejściu strukturalnym:
Model liniowy
Model z prototypem - model cyklu życia SI
Model spiralny opisuje cykl życia SI w kolejnych wersjach.
Model wymagań użytkownika w podejściu obiektowym:
Diagram przypadków użycia (USE CASE)
Występują tutaj aktorzy, przypadki użycia, powiązania. Na tym modelu widać zależności pomiędzy kolejnymi przypadkami użycia oraz między aktorami. Widać również wszystkie powiązania aktorów i przypadków użycia.
Proces biznesowy to zbiór działań wewnątrz firmy (rynku biznesowego) wykonywanych w celu dostarczenia klientowi konkretnej usługi lub produktu
Aktor to abstrakcyjny użytkownik systemu reprezentujący grupę rzeczywistych użytkowników występujących w tej samej roli wobec systemu.
Definicja Przypadku Użycia:
ciąg interakcji między aktorem a systemem
ciąg transakcji (niepodzielnych operacji wykorzystywanych wewnątrz systemu dostarczających aktorowi rezultaty o mierzalnej wartości
Dwa typy powiązań pomiędzy przypadkami użycia stosowanymi w modelowaniu przypadków użycia.
1) Powiązanie <<include>>
powiązanie to łączy dwa przypadki użycia z których jeden rozszerza funkcjonalność drugiego przypadku
2) Powiązanie <<extend>>
łączy ono dwa przypadki użycia z których jeden może rozszerzać funkcjonalność drugiego
Przypadek użycia który modeluje proces biznesowy odpowiada procesowi przetwarzania danych (czyli funkcji systemowej) opisywanego strukturalnie
Do modelowania wymagań funkcjonalnych w podejściu obiektowym wykorzystujemy przypadki użycia interakcji z aktorami ( diagram przypadków użycia = USE CASE DIAGRAM ). W modelowaniu przypadków użycia nie widać wewnętrznej struktury systemu czy to biznesowego czy informatycznego zatem model przypadków użycia nie wystarcza do pełnego opisu funkcjonowania czy to systemu biznesowego czy systemu informatycznego dlatego Jacobs w swojej metodyce wprowadził tzw. Model obiektów którym pokazał w jaki sposób realizowane są procesy biznesowe w systemie. Model obiektów według Jacobsona przedstawia wewnętrzną architekturę systemu biznesowego lub systemu informatycznego. Model obiektów Jacobsona nie wszedł do standardu UML.
Omówić rolę słownika (repozytorium) w narzędziach CASE przy projektowaniu baz danych.
Niezbędnym uzupełnieniem każdego z modeli systemu reprezentowanego przez omawiane dalej diagramy jest dokładna identyfikacja (opia) wszystkich elementów każdego modelu. Dokonuje się tego przy użyciu tzw. słownika danych, który zawiera dokładne definicje wszystkich elementów każdego z diagramów, a także wzajemne powiązania między poszczególnymi diagramami (modelami).
Opracowano już wiele pakietów słowników danych pozwalających na automatyczne wykonywanie wielu funkcji, a zwłaszcza na kontrolę spójności i zupełności danych, Taki słownik danych stanowi podstawowy element każdego pakietu typu CASE. Zawiera on definicję wszystkich strata danych, (obiekty, atrybuty, po wiązania), procesów, jednostek komunikacji z użytkownikiem (ekrany, raporty, dialogi), danych dotyczących zarządzania przedsięwzięciem (wersje, prawa dostępu, osoby odpowiedzialne; ang. project management). Może również zawierać wygenerowany kod źródłowy programów, dokumentacje użytkownika.
Słownik danych definiuje swoje elementy w następujący sposób:
Oprócz identyfikatora, unikatowego dla każdego z elementów, i nazwy {etykiety, ang. label), każdy element jest zaopatrzony w krótkie wyjaśnienie znaczenia;
Każdy złożony element ma dokładną definicję swoich elementów składowych <np. atrybuty złożone, struktury rekordów, przepływy danych, magazyny danych, obiekty);
Magazyny danych, przepływy danych mają zawsze zdefiniowaną zawartość;
Wszystkie dane elementarne mają zdefiniowane zakresy wartości, jakie mogą przyjmować (ciągłe lub dyskretne), jednostki miary;
Powiązanie między obiektami jest dokładnie scharakteryzowane;
Wszystkie powiązania między poszczególnymi elementami każdego modelu są dokładnie opisane (np. kolejne, rozwinięcia diagramu DFD, zależności miedzy poszczególnymi węzłami na diagramie ELH, ródło i przeznaczenie każdego przepływa).
Ogólnie każdy element na różnych diagramach ma pewien, zapisany w słowniku danych, zestaw atrybutów, które go zgadnie z definicją każdego modelu charakteryzują.
Notacja słownika danych
Istnieje wiele notacji używanych do zdefiniowania elementów słownika danych. Będziemy posługiwali się najczęściej stosowaną. Przedstawiają tabeli
Symbol |
Znaczenia |
= |
jest złożony z (następujących elementów) |
+ |
i |
( ) |
opcjonalność (element może być obecny lub nie) |
{} |
iteracja elementu (element może się powtórzyć) |
[ ] |
selekcja (jeden z podanych elementów może zostać wybrany) |
* * |
komentarz |
@ |
identyfikator — klucz obiektu ( np. magazynu danych) |
| |
oddzielanie alternatywnych elementów w konstrukcji [ ] |
„..” |
literał |
Przykłady opisu elementów w słowniku danych
Definicje
Definicja różnych elementów modelu jest zapisywana za pomocą symbolu = i jest odczytywana jako „jest złożony”, np.
A = B + C
oznacza: A jest złożone z elementów B i C.
Jak już wspomniano, definicja każdego elementu powinna zawierać również opis znaczenia, zawartość - tzn. elementy składowe w przypadku elementów złożonych, wartości jakie może przyjmować dany element (dziedzina, zakres) jednostki miary.
Dane elementarne (atrybuty proste)
Są to najmniejsze jednostki informacji, z których są tworzone elementy złożone, takie jak atrybuty złożone, magazyny danych itp.
wzrost = *wzrost zawodnika w druzynie*
*zakres 1-200; jed. miary cm*
nazwisko = *nazwisko autora*
imię = *imię autora*
płeć = ["M"|"K"]
Struktury (atrybuty złożone)
id_autor = *identyfikator autora* nazwisko + imię
Elementy opcjonalne
adres_kl = *adres klienta* kod + miejsc + ulica + nrdom + (nr_telefonu)
Iteracje
{} zero-nieskończoność
5( )100 dolna i górna granica 5 i 100
Nr_kat_książki = 1 (cyfra )10
Selekcje
Cyfra = [1|2|3|4|5|6|7|8|9|0]
Aliasy
identyfikator = "alias" nr,Jcat_fcsiążki
Alias jest alternatywną nazwą danego elementu. Zjawisko występowania wielu nazw dla danego elementu jest bardzo częste, gdy projekt jest tworzony przez wiele osób. Dodatkowo nazwy wykorzystywane przez użytkowników systemu różnią się od nazw tych samych elementów używanych przez analityków czy projektantów. Wszystkie nazwy aliasy winny znaleźć się w słowniku w celu ułatwienia, zrozumienia specyfikacji systemu zarówno przez użytkowników, jak i cały zespół tworzący system.
Klasyfikacja metodyk projektowania strukturalnego.
DeMarco - twórca klasycznej analizy strukturalnej
TOP - DOWN - „od ogółu do szczegółu” rozbijanie problemu na mniejsze
Problem ogólny, bardzo złożony musimy podzielić na problemy mniejsze, prostsze do rozwiązania(Diykstry).
Podział systemu informatycznego na podsystemy, na procesy potomne => dekompozycja systemowa.
7 kroków metodyki DeMarco:
zbudowanie modelu fizycznego istniejącego systemu informacyjnego(opis systemu informacyjnego)
Stworzenie modelu logicznego systemu informacyjnego
zbudowanie modelu logicznego docelowego systemu
zbudowanie modelu fizycznego docelowego systemu
szacowanie kosztów dla zaprezentowanych modeli z punktu 4
wybór odpowiednich właściwości modelu
specyfikacja systemu uwzględniająca podział całości na podsystemy
Wady:
powód - analiza sytuacji w celu stworzenia modelu ( niechęć do ujawniania niektórych mechanizmów firmy a analityk drąży jak najgłębiej aby ocenić sytuację jak najlepiej
sztywno narzucona technika TOP - DOWN, trudności podziału na mniejsze problemy tego jednego wielkiego problemu
Metodyka Yourdana - zwana współczesną analizą strukturalną
oderwanie się od systemu aktualnie działającego i tworzenie założeń dla nowego systemu ( patrzenie na system jak na system który ma powstać a nie na system który istnieje)
zdefiniowanie podstawowej listy funkcji ( nie wiążemy się z istniejącym systemem tylko definiujemy wymagania funkcjonalne nowo tworzonego systemu w przyszłości )
metoda TOP - DOWN
Funkcje można wyliczyć na podstawie zdarzeń zachodzących w systemie oraz na które system reaguje.
Metodyka Yourdana
Model środowiskowy stanowi idealny model wymagań systemu.
musi być krótki opis celu działania systemu,
lista zdarzeń, które pobudzają system do działania,
wyznaczona granica systemu (wewnątrz granicy jest system a na zewnątrz użytkownicy czyli obiekty zewnętrzne )
Diagram kontekstowy
Porównanie klasycznej analizy strukturalnej DeMarco z metodyką Yourdona.
DeMarco - twórca klasycznej analizy strukturalnej
TOP - DOWN - „od ogółu do szczegółu” rozbijanie problemu na mniejsze
Problem ogólny, bardzo złożony musimy podzielić na problemy mniejsze, prostsze do rozwiązania(Diykstry).
Podział systemu informatycznego na podsystemy, na procesy potomne => dekompozycja systemowa.
7 kroków metodyki DeMarco:
zbudowanie modelu fizycznego istniejącego systemu informacyjnego(opis systemu informacyjnego)
Stworzenie modelu logicznego systemu informacyjnego
zbudowanie modelu logicznego docelowego systemu
zbudowanie modelu fizycznego docelowego systemu
szacowanie kosztów dla zaprezentowanych modeli z punktu 4
wybór odpowiednich właściwości modelu
specyfikacja systemu uwzględniająca podział całości na podsystemy
Wady:
powód - analiza sytuacji w celu stworzenia modelu ( niechęć do ujawniania niektórych mechanizmów firmy a analityk drąży jak najgłębiej aby ocenić sytuację jak najlepiej
sztywno narzucona technika TOP - DOWN, trudności podziału na mniejsze problemy tego jednego wielkiego problemu
Metodyka Yourdana - zwana współczesną analizą strukturalną
oderwanie się od systemu aktualnie działającego i tworzenie założeń dla nowego systemu ( patrzenie na system jak na system który ma powstać a nie na system który istnieje)
zdefiniowanie podstawowej listy funkcji ( nie wiążemy się z istniejącym systemem tylko definiujemy wymagania funkcjonalne nowo tworzonego systemu w przyszłości )
metoda TOP - DOWN
Funkcje można wyliczyć na podstawie zdarzeń zachodzących w systemie oraz na które system reaguje.
Model środowiskowy stanowi idealny model wymagań systemu.
musi być krótki opis celu działania systemu,
lista zdarzeń, które pobudzają system do działania,
wyznaczona granica systemu (wewnątrz granicy jest system a na zewnątrz użytkownicy czyli obiekty zewnętrzne )
Diagram kontekstowy
Diagram przepływu danych na poziomie kontekstowym - jest to kolejny element modelu środowiskowego
Strzałki - przepływ danych ( strzałki muszą przecinać granice systemu )
Kółko w środku - proces o numerze 0, proces najbardziej złożony, reprezentuje cały system (dla całego systemu informatycznego jest tylko jeden taki proces )
Wymagania funkcjonalne systemu przedstawiamy za pomocą diagramu przepływu danych i najbardziej ogólne wymagania funkcjonalne przedstawiamy na za pomocą diagramu kontekstowego.
Zawartość słownika dotyczących danych elementarnych ( atrybutów zawartych w we/wy ) związanych z przepływem we/wy.
Podmodel zachowań - opisuje wewnętrzną architekturę projektu systemu informatycznego zarówno pod względem składników statycznych i składników dynamicznych.
Aby stworzyć pełny podmodel zachowań wykorzystujemy różne techniki, a te techniki to działania opisujące interesujący nas system.
W podejściu Yourdanowskim zbiór diagramów DFD tworzony jest techniką mieszaną.
Diagram DFD pokazuje hierarchię funkcji, powstaje drzewo funkcji.
ERD diagram - (statyczny model struktur danych) na tym diagramie nie ma uwarunkowań czasowych ( dlatego statyczny, opisuje bierne elementy).
Zbiór diagramów DFD - zbiór diagramów przepływu danych. Uzyskamy w wyniku kroków dekompozycji diagramu kontekstowego DFD na którym był tylko jeden proces ( kolejne poziomy potomne DFD w stosunku do diagramu kontekstowego )
Statyczne diagramy: ERD, DFD(Data Flow Diagram)
Dynamiczne diagramy: ELH(Entity Life History - Diagram życia encji), STD(State Transition Diagram - diagram przejść stanów)
System biznesowy a system informatyczny (wg metodyki Jacobsona).
Przejście z systemu biznesowego na system informatyczny
Jeżeli jeden i drugi system modelujemy za pomocą przypadków użycia czym stają się obiekty interfejsu systemu biznesowego w systemie informatycznym?
Obiekty interfejsu systemu biznesowego
najczęściej awansują na aktorów systemu informatycznego. W systemie biznesowym te obiekty interfejsu współpracowały z obiektami sterującymi, obecnie wspomaga je system informatyczny i z nimi komunikuje się w celu wykonania swego zadania
Obiekty sterujące systemu biznesowego
mają wierne odpowiedniki w systemie jako obiekty sterujące systemu informatycznego lub jako wyspecjalizowane podsystemu. obiekty sterujące awansują na aktorów systemu i są wspomagane w wykonywaniu swoich zadań przez system ma miejsce wtedy gry system informatyczny całkowicie zastępuje lub częściowo pracę człowieka czyli w systemach sterowania, okresowe rozliczenia
Obiekty encje
znajdują bezpośrednie odbicie w systemach informatycznych ( obiekty aplikacji ) części systemów reprezentujących elementy bierne ( bazy danych, dokumenty itp. )
Obiekty interfejsu dla systemów informatycznych: przyciski na ekranach interakcyjnych, okna dialogowe, ikony, paski przewijania
Obiekty aplikacji: dane, rachunki, faktury, dane o produktach,
Obiekty sterujące: te elementy systemu które uczestniczą w realizacji funkcji systemowych ale są niewidoczne dla aktora
Zwykle aktorzy systemu biznesowego znajdują się poza zasięgiem modelu przypadków użycia systemu informatycznego
System
Biznesowy
BANK
Klient banku kasjer Konto ( obiekt )
klienta ( encja )
W systemie informatycznym dla banku kasjer stał się aktorem
SI
Obsługa klienta
kasjer
klient banku
(nie jest już aktorem)
System biznesowy
kasjer
System informatyczny
bankomat
Modele implementacyjne w projektowaniu strukturalnym i obiektowym.
Określa w jaki sposób system ma zostać zrealizowany przy użyciu dostępnych środków technologicznych
Dostępne narzędzia
Dostępne środowisko systemowe ( system operacyjny )
Środowisko sprzętowe
Model implementacyjny według metodyki Yourdona składa się z 3 modeli:
Model organizacji kodu COM CODE ( STC ( w CASE dla ludzi ) ( structure Chart - schemat struktury - jak wygląda struktura oprogramowania)
Model Środowiska oprogramowania
Model Środowiska sprzętowego
Model organizacji kodu przedstawia hierarchiczną strukturę budowy oprogramowania.
Model logiczny ( podstawowoy )
DFD
Dane Wejście Przetworzenie Wyjście Wyniki
INPUT PROCESS OUTPUT
Transformacja ( przekształcenie )
Model fizyczny ( implementacyjny ) jest to model oprogramowania
Strzałki oznaczają hierarchię, zależność hierarchiczną ( te strzałki bez kółek )
Model fizyczny uwzględnia składniki sterująco - koordynujące które powodują zwrot przepływu danych pomiędzy odpowiednimi modułami. Moduły są komponentami
Strzałki ( bez kółek ) łączą moduły pokazując hierarchiczną zależność między modułami ( grot wskazuje moduł podrzędny )
Moduły - rodzaje
1) Moduł doprowadzający ( jest podłączony do jakiegoś modułu nadrzędnego ). Pośredniczy w przepływie doprowadzania danych do systemu ( moduł dostaje z modułów podrzędnych dane i je przekazuje do modułu nadrzędnego, przepływ danych jest jednokierunkowy, od modułu podrzędnych do modułów nadrzędnych.
2) Moduł odprowadzający Uczestniczy w odprowadzaniu danych. Otrzymuje dane od modułu nadrzędnego i przekazuje je do podrzędnych modułów. Przepływ jest jednokierunkowy.
3) Moduł transferowy moduł ten przetwarza dane tak, że po otrzymaniu danych z modułu nadrzędnego i przetworzeniu ich odsyła je do modułu nadrzędnego.
4) Moduł koordynujący ( sterujący, kontrolny ) Ten moduł ma tylko moduły podrzędne. Otrzymuje on dane od modułu podrzędnego i rozprowadza te dane do modułów podrzędnych.
4
Obiekt 4
Obiekt 3
Obiekt 2
Obiekt 1
Komunikat + nazwa
(wywołanie zdarzenia)
Komunikaty wynikające z przebiegu realizacji przypadków użycia
Granica systemu
Granica systemu architektury
Obiekt interfejsu
Scenariusz słowny (kolejne czynności w postaci pseudokodu)
użytkownik ma kontakt z twórcami systemu w tych momentach
Model fizyczny
Instalacja (wdrażanie)
Model logiczny
Testowanie
Projektowanie
Określanie wymagań
Konserwacja (eksploatacja)
Implementacja
(Pisanie kodu).
Faza strategiczna
(rozważania za i przeciw systemowi)
Analiza
(Rozeznać dziedzinę
systemu)
Dokumentowanie - narzędzia CASE
Uogólnienie
Klasa specjalizacji
Klasa generalizacji
Uogólnienie
Zdarzenie sekwencyjne
Zdarzenie złożone
Zdarzenie złożone
Zdarzenie złożone
Nazwa encji
Likwidacja konta
Spłacanie pożyczki
Przyznanie pożyczki
Założenie konta
Uogólnienie
Konto klienta
Zdarzenie selektywne
Zdarzenie selektywne
Zdarzenie selektywne
Zdarzenie iteracyjne
Sterowanie
Wyniki
Dane
Wejście
Sterowanie
Przetwarzanie
Atrybuty
@............................................................
Nazwa encji
Wszystkie operacje jakim poddawane są obiekty danej klasy np. wyświetl, edytuj - metody klasy.
Nazwy stanów - pola klasy.
Nazwa klasy - symbol graficzny
Model implementacyjny (fizyczny) - czyli jak zrealizować to co zostało ustalone w modelu logicznym
Model podstawowy (logiczny) - czyli odpowiedzi na pytania co system ma robić
Podmodel środowiskowy
Model zachowań:
- ERD(DCM) - statyczny model struktur danych
- zbiór diagramów DFD - uzyskany w wyniku kroków dekompozycji diagramu kontekstowego DFD
Nazwa stanu
SŁOWA KLUCZOWE
Opis stanu
Stan k+1
Stan k
nowego rachunku (suma zapłaty)[suma ~ posiada - limit ]
zarejestruj niewypłacalność konta
nowy rachunek (suma do zapłaty)[suma - posiada - winien]
klient z kontem zerowym
uzyskał .status klienta (wplata) [wpłata]
zapisz jako klient wypłacalny
uzyskał status klienta banku (wplata) [wplata = 0]
zapisz zerowe konto
Moduł doprowadzający
Moduł odprowadzający
Moduł transferowy
Moduł koordynujący
Wyszukiwarka