Cechy narzędzi CASE (1):

Narzędzia CASE: Inżynieria Systemów Informatycznych CASE metodyki i narzędzia Jerzy KORCZAK, Barbara SMOK email :<jerzy.korczak, brabara.smok>@ue.wroc.pl http://www.korczak-leliwa.pl http://citi.ae.wroc.pl jest to grupa narzędzi programistycznych tworzących nową technologię konstruowania systemów informacyjnych, obejmujących cały cykl życia systemu informatycznego. J.Korczak, UE Wroclaw 1 Narzędzia CASE: CASE (Computer Aided Software Engineering ) oznacza komputerowo wspomaganą inżynierię oprogramowania lub (Computer Assisted System Engineering ) komputerowo wspomaganą inżynierię systemów Pod tym pojęciem kryją się wszystkie narzędzia komputerowe wykorzystywane w trakcie prac nad oprogramowaniem jak np. kompilatory, debuggery, edytory tekstu, narzędzia harmonogramowania przedsięwzięć, arkusze kalkulacyjne. Cechy narzędzi CASE (1): duży stopień wizualizacji informacji sporządzanie diagramów operują diagramami różnych typów w sposób pozwalający uwzględniać różne aspekty opisywanych obiektów kompletują informację o opisywanych obiektach oraz reprezentują powiązania zachodzące między nimi Cechy narzędzi CASE (2): eliminowanie powielania danych i procesów badanie poprawności i spójności informacji zawartych na diagramach automatyczna generacja schematu relacji (definicja baz danych) stosowanie konstrukcji programowania strukturalnego na poziomie języka diagramów (podprogramy, iteracje, rozgałęzienia) Cechy narzędzi CASE (3): wspomagają projektowanie zewnętrznych obrazów obiektów aplikacji automatycznie generują znaczną część procedur aplikacji na podstawie szablonów programowych podstawowych czynności współdzielenie informacji między autorami systemu tworzą centralną encyklopedię systemu z zapewnieniem koordynacji i kontroli informacji wprowadzanej z różnych stacji roboczych. 1

Narzędzia CASE: Zintegrowane pakiety oprogramowania realizującego zbiór technik projektowania Dostosowane do konkretnej metodyki lub rodzaju metodyk Zazwyczaj wyposażone w repozytorium Dwie główne grupy narzędzi CASE: Upper-CASE: wspomaganie wczesnych faz prac nad oprogramowaniem, w szczególności fazy analizy (potrzeby analityków i projektantów). Narzędzia te nie są związane z konkretnym środowiskiem implementacyjnym. Lower-CASE: wspomaganie faz projektowania i implementacji (potrzeby programistów). Narzędzia te są z reguły ściśle związane z konkretnym środowiskiem implementacji. Składowe narzędzi CASE Funkcje narzędzi CASE: Podział pakietów typu CASE ze względu na zakres: określają granice systemu informacyjnego umożliwiają analizę i dekompozycję problemu na składowe odpowiadające elementom tego systemu Umożliwiają dobór metod i narzędzi do realizacji tych składowych Pozwalają tworzyć i zapisywać modele oraz zależności między nimi Automatyzują niektóre czynności projektowe Kontrolują poprawność i spójność projektu oraz zgodność między modelami pakiety narzędziowe (Toolkits) środowiska (environments) pakiety zintegrowane (Workbench): a) narzędzia specyfikacji i interpretacji opisu systemu b) generatory struktur baz danych c) generatory programów wykonywalnych d) programy dokonujące modyfikacji wersji systemu Aspekty narzędzi CASE Narzędzia CASE stosują różne techniki wizualizacji projektów, w szczególności notacje diagramów encja-związek (ER), OMT, UML i inne. Obecnie większość producentów określa swoje środowiska jako I-CASE.Są to narzędzia łączące w sobie możliwości Lower-CASE i Upper-CASE. Istnieje grupa narzędzi uniwersalnych, które umożliwiają pracę z wieloma notacjami i wieloma metodykami. Istnieją również narzędzia CASE przypisane do konkretnych produktów, np. Oracle CASE. Wiele narzędzi CASE łączy elementy znane z wielu metodyk z własnymi pomysłami. Przykłady narzędzi CASE (są ich dziesiątki): Oracle CASE, EasyCASE, CASE 4.0, ObjectiF, Select OMT Professional, System Architect, ObjectTeam, Paradigm Plus, Rational Rose, Select Enterprise, Oracle Designer Ocena narzędzi CASE (kryteria): Zakres oferowanych funkcji i ich zgodność z potrzebami firmy Koszt Niezawodność Opinia o producencie i dystrybutorze Dostępność na rynku pracy specjalistów znających dany pakiet Stopień zintegrowania z przyjętym środowiskiem programistycznym Wielośrodowiskowość Koszt szkoleń Koszt dostosowania sprzętu do wymagań pakietu 2

Przyczyny trudności z narzędziami CASE Traktowanie narzędzi CASE wyłącznie jako generatorów kodu. Nie jest to efektywne przy braku rzetelnego podejścia do analizy i projektowania: nakłady na implementację stanowią tylko ok. 15-30% całych nakładów koszt błędów popełnionych w fazie implementacji jest stosunkowo niewielki istnieją inne, tańsze narzędzia programistyczne (RAD) Rozkład kosztów realizacji SI Nieznajomość metodyki analizy i projektowania. Narzędzia CASE nie zwalniają z myślenia, wiedzy i doświadczenia. Niewłaściwa organizacja i zarządzanie przedsięwzięciem. Nieuporządkowanie prac, brak planu, brak właściwych ocen, brak monitorowania postępu, itd. Zbyt wysokie oczekiwania w stosunku do narzędzia CASE. Może ono zredukować koszty co najwyżej o 50%, koszt wdrożenia jest wysoki, efekty pojawiają się z pewnym opóźnieniem, wymaga dyscypliny w przedsięwzięciu. Modelowanie 1. Ustalenie głównych przepływów informacji (interfejsów) między systemem a obiektami zewnętrznymi 2. Sporządzenie diagramu kontekstowego 3. Identyfikacja podstawowych procesów 4. Dodanie magazynów danych niezbędnych z punktu widzenia logiki systemu 5. Dekompozycja i uszczegóławianie modelu 6. Weryfikacja syntaktyki i semantyki Metodyki projektowania SI: Metodyki strukturalne Metodyki obiektowe Metodyki strukturalne Dane i procesy modelują osobno Wykorzystują tylko proste typy danych Dobrze są dostosowane do relacyjnego modelu danych Ich podstawowe techniki to: diagramy przepływu danych (DFD), diagramy związków encji (ERD), hierarchie funkcji (FHD), modele macierzowe Metodyki obiektowe: Dane i procesy modelują łącznie Wykorzystują złożone typy danych Dostosowane są do obiektowego modelu danych Ich podstawowe techniki to: diagramy klas UML, przypadki użycia i modele dynamiczne UML 3

Analiza strukturalna Metody strukturalne są szczególnie przydatne w przypadkach, gdy jeden z aspektów aktywny lub pasywny jest bardziej istotny Analiza strukturalna (structured analysis) zw. też analizą wymagań prowadzi do sformułowania specyfikacji systemu (system specification) w formie zestawienia wymagań i założeń (requirements) Główny cel fazy analizy stanowi dekompozycja funkcjonalna SI oraz opis potrzebnych do jego funkcjonowania danych. Najpierw przeprowadza się analizę istniejącego systemu i na jej podstawie buduje się model funkcjonalny nowego systemu. Analiza strukturalna (structured analysis) rozpoczyna się od budowy dwóch różnych modeli systemu: - modelu danych będącego opisem pasywnej części systemu - modelu funkcji opisującego aktywną część systemu Następnie następuje integracja tych modeli, której wynikiem jest model przepływu danych (data flows model). Metodyki strukturalne structured methodologies, structured analysis 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). Metodyki strukturalne Zgodnie z DeMarco, analiza strukturalna używa następujących technik. Diagramy Przepływu Danych (Data Flow Diagrams, DFD) Słownik Danych (Data Dictionary) Strukturalny Angielski (Structured English) -> strukturalny polski Tablice Decyzyjne (Decision Tables) Drzewa Decyzyjne (Decision Trees) Dodatkowo: Schemat Transformacyjny (Transformation Schema) Diagram Przejść Stanów (State Transition Diagram) Lista Zdarzeń (Event List) Schemat Danych (Data Schema) Pre- i post- warunki (Pre- and Post-Conditions) Diagramy Encja-Związek (występują w SSADM) Historie Życia Encji (występują w SSADM) Uważa się, że wadą metodyk strukturalnych są trudności w zintegrowaniu modeli. Faza analizy Określenie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Dokumentacja Celem fazy określenia wymagań jest udzielenie odpowiedzi na pytanie: Co i przy jakich ograniczeniach system ma robić? Wynikiem tej fazy jest zbiór wymagań na system. Instalacja Celem fazy analizy jest ustalenie wszystkich tych czynników lub warunków w dziedzinie przedmiotowej, w otoczeniu realizatorów projektu, w istniejących lub planowanych systemach komputerowych, które mogą wpłynąć na decyzje projektowe, na przebieg procesu projektowego i na realizację wymagań. Wynikiem jest logiczny model systemu, opisujący sposób realizacji przez system postawionych wymagań, lecz abstrahujących od szczegółów implementacyjnych. Czynności w fazie analizy Rozpoznanie, wyjaśnianie, modelowanie, specyfikowanie i dokumentowanie rzeczywistości lub problemu będącego przedmiotem projektu; Ustalenie kontekstu projektu; Ustalenie wymagań użytkowników; Ustalenie wymagań organizacyjnych Inne ustalenia, np. dotyczące preferencji sprzętowych, preferencji w zakresie oprogramowania, ograniczeń finansowych, ograniczeń czasowych, itd. W zasadzie analiza nie powinna stawiać nacisku na zmianę rzeczywistości poprzez wprowadzenie tam nowych elementów np. w postaci systemu komputerowego. Jej celem jest rozpoznanie wszystkich tych aspektów rzeczywistości, które mogłyby mieć wpływ na postać, organizację lub wynik projektu. W odróżnieniu, celem fazy projektowania jest udzielenie odpowiedzi na pytanie: Jak system ma być zaimplementowany? Wynikiem jest opis sposobu implementacji. 4

Tematy i techniki analizy Budowa statycznego modelu klas Analiza funkcji i przypadków użycia Weryfikacja klas i obiektów Identyfikacja i definiowanie metod oraz komunikatów Modelowanie stanów i przejść między stanami Modelowanie procesów i przepływów danych Modelowanie przepływu sterowania Inne Podstawowe rezultaty fazy analizy Poprawiony dokument opisujący wymagania Słownik danych zawierający specyfikację modelu Dokument opisujący stworzony model, zawierający: diagram klas diagram przypadków użycia diagramy sekwencji komunikatów (dla wybranych sytuacji) diagramy stanów (dla wybranych sytuacji) raport zawierający definicje i opisy klas, atrybutów, związków, metod, itd. Harmonogram fazy projektowania Wstępne przypisanie ludzi i zespołów do zadań Analiza strukturalna - modelowanie procesów Podstawowa technika są diagramy przepływów danych (Data Flow Diagrams - DFD) DFD pojawiły się w końcu lat 70-tych w rezultacie prac: T.DeMarco Ch.Gane, T.Sarson E.Yourdon, Constantine Cel modelowania danych (1) Otrzymanie dokładnego modelu potrzeb informacyjnych przedsiębiorstwa Dekompozycja i strukturalizacja problemu Sformalizowanie opisu z wykorzystaniem języka graficznego - jednoznaczność i czytelność Mechanizm efektywnej komunikacji pomiędzy analitykiem i użytkownikiem, pomiędzy analitykami systemu, a nawet pomiędzy użytkownikami Poprawa jakości i efektywności projektowania bazy danych Cel modelowania danych (2) Techniki modelowania procesów diagramy przepływu danych (DFD) Opis danych niezależny od struktur logicznych i fizycznych Niezależność od implementacji pozwala na zastosowanie modelu do integracji istniejących baz danych Podstawa do zrozumienia procesów realizowanych w przedsiębiorstwie i jego reorganizacji Możliwość prezentacji potrzeb informacyjnych na różnym poziomie ogólności Są najstarszą techniką stosowaną w CASE Należą do najważniejszych działań, które programuje się w pierwszej kolejności. Obrazują procesy zachodzące w systemie oraz wymianę danych między nimi, jak również sposób, w jaki te dane są wprowadzane i wyprowadzane z systemu. Stanowią podstawowe narzędzie analizy strukturalnej, podczas której powstaje zbiór diagramów DFD. 5

Diagram kontekstowy (0): Przedstawia cechy systemu: granice systemu, źródła i odbiorców informacji w systemie, główne wejścia i wyjścia z systemu (informacje płynące między światem zewnętrznym a systemem). Jest mapą procesów realizowanych w systemie wraz z powiązaniami zewnętrznymi. Istnieje wiele sposobów tworzenia diagramów przepływu danych. Buduje się go w sposób zstępujący (top-down) lub wstępujący (bottom-up). DFD składa się z: jednostek zewnętrznych (External Entity) - reprezentujących osobę, urządzenie lub inny system informatyczny będącyźródłem lub odbiorcą informacji magazynów danych (Data Store) - ukazujących istniejące i przewidywane bazy danych, z których może korzystać kilka procesów procesów - odpowiadają tym składnikom systemu, które operują na danych, transformują dane wejściowe na informacje wyjściowe przepływu danych (data flow) - opisują strumienie danych o określonej zawartości przepływające pomiędzy dwoma obiektami (źródłem i przeznaczeniem). Przykład DFD: DFD DFD - przykład Obiekty DFD 6

DFD - główne komponenty SSADM Składnica (datastore) Przepływ danych (dataflow) Przepływ danych (data flow) Przepływ danych Łączy wyjście jednego procesu z wejściem innego procesu. Może także łączyć proces (wejście / wyjście) z interfejsem lub składnicą danych Byt zewnętrzny (eksternal) 7

Modelowanie związków encji Obejmuje identyfikowanie rzeczy ważnych w analizowanym przedsiębiorstwie (encji), własności tych rzeczy (atrybutów) i sposobów, jakimi te encje są ze sobą powiązane (związków) Diagram związków encji (ERD): jest modelem sieciowym opisującym na wysokim poziomie abstrakcji układ danych przechowywanych w systemie zw. jest też obiektowo-związkowym diagramem służy do wyrażenia struktury danych projektowanego lub istniejącego systemu. Atrybuty encji Atrybut jest dowolnym szczegółem służącym do kwalifikowania, identyfikowania, klasyfikowania, określania ilości lub wyrażania stanu encji (atrybut jest dowolnym opisem mającym znaczenie dla encji) Atrybut musi opisywać encję, przy której występuje Nazwa atrybutu musi być podana w liczbie pojedynczej Każda encja musi być jednoznacznie zidentyfikowana przez kombinację atrybutów i/lub związków Encja (ang. entity) Jest bytem, rzeczą lub obiektem mającym dla nas znaczenie, rzeczywistym bądź wyobrażonym, o którym informacje muszą być znane lub przechowywane. Jej nazwa powinna powinna reprezentować typ lub klasę rzeczy, a nie żadne jej konkretne wystąpienie Atrybut cecha służąca do identyfikacji, klasyfikacji lub wyrażenia stanu encji Encja 8

Unikalny identyfikator unique identifier Obiekty na diagramach związków encji Związek (relationship) nazwane istotne powiązanie między encjami Nazywanie związków Konstrukcje specjalne Hierarchie encji 9

Funkcja (function) Podstawowymi pojęciami modelu ER są: encja (jednostka danych lub obiekt) (entity) - rzecz istotna, rzeczywista albo wyobrażalna, o której informacje muszą być znane lub przechowywane związek (relationship) - istotne powiązanie między dwiema encjami atrybut (attribute) - każdy szczegół służący do kwalifikowania, identyfikowania, klasyfikowania, określania ilości, wyrażania stanu encji lub też opis rzeczy istotnej. ERD ERD Przykładowy ERD Przykład ERD: 10

Modelowanie hierarchii funkcji tworzy diagramy, które pokazują dekompozycję funkcji na różnych poziomach działalności przedsiębiorstwa Function Hierarchy Diagrammer Dla funkcji można zdefiniować jej hierarchię Każda funkcja jest dekomponowana do najniższego poziomu (elementary business function) Funkcje elementarne stają się formularzami, raportami i narzędziami Function Hierarchy Hierarchiczna struktura funkcji stanowi model funkcjonalny systemu Funkcje odzwierciedlają czynności wykonywane przez użytkownika systemu w procesie przetwarzania danych Funkcja nadrzędna opisuje cały system produkcji Function Hierarchy Funkcja nadrzędna jest dekomponowana na inne funkcje, które mogą być też dekomponowane. W wyniku podziałów otrzymujemy hierarchię funkcji. Z tych diagramów wynikają zależności pomiędzy funkcjami (FDD) definiują model dynamiczny kolejność wykonywania funkcji w systemie, a także uwarunkowania jakie muszą być spełnione przed ich wykonaniem. Diagram macierzowy Matrix Diagrammer (do analizy jest to narzędzie do weryfikacji poprawności i spójności modelu) Matrix Diagrammer 11

Poziomy modelowania SI Metody modelowania Metody analizy Rozkład funkcjonalny Modelowanie procesów Modelowanie danych Analiza obiektowa Rozkład funkcjonalny - pojęcia podstawowe cel przedsiębiorstwa funkcja hierarchia funkcji mechanizmy zdarzenia Weryfikacja każdy proces musi mieć przepływy do niego wpływające jak i wypływające; obiekty zewnętrzne nie mogą komunikować się bezpośrednio z magazynem; nie może istnieć magazyn, z którego następuje tylko odczyt; przepływy wchodzące i wychodzące z procesu na diagramie wyższego poziomu pojawiają się na niższym poziomie jako przepływy przekraczające granice dekomponowanego procesu; nie pojawiają się procesy, których nie było wyżej; procesy są numerowane wielopoziomowo Rola analizy systemowej zrozumienie dziedziny problemu; uzyskanie aktualnego opisu stanu systemu informacyjnego; ułatwienie komunikacji pomiędzy udziałowcami projektu; podstawa mapowania/modelowania 12

Analiza Metody specyfikacji wymagań jest studium dziedziny problemu prowadzącym do specyfikacji obserwowalnego zachowania systemu; podczas analizy ustala się co system ma robić, aby spełnić wymagania użytkownika Język naturalny; Język ustrukturyzowany; Tablice, formularze; Diagramy kontekstowe; Diagramy blokowe; Diagramy przypadków użycia. FUNCTION HIERARCHY DIAGRAMMER Diagram ERD Matrix Hierachia funkcji 13

DFD Geneza obiektowości Obiektowość jest nową ideologią która wynika z zaobserwowanych wad istniejącego świata i podaje jakąś receptę, jak te wady usunąć, a więc przede wszystkim stara się o uzyskanie jak najmniejszej luki pomiędzy myśleniem o rzeczywistości (dziedzinie problemowej) a myśleniem o danych i procesach, które zachodzą na danych. Mentalna percepcja świata rzeczywistego Model pojęciowy Schemat struktury danych W modelu relacyjnym model pojęciowy stara się odwzorować świat rzeczywisty, lecz jest ograniczony dostępną bazą implementacyjną. W rezultacie, schemat struktury danych gubi semantykę danych. Model obiektowy podtrzymuje te zgodności, przybliżając semantykę danych do świata rzeczywistego. Podstawowe zasady obiektowości Obiekt Konto Obiekt - struktura danych, występująca łącznie z operacjami dozwolonymi do wykonywania na niej, odpowiadająca bytowi wyróżnialnemu w analizowanej rzeczywistości. Wpłać Wypłać Tożsamość obiektu - wewnętrzny identyfikator, który pozwala na odróżnienie go od innych obiektów. Hermetyzacja - rozróżnienie pomiędzy interfejsem do obiektu opisującym co obiekt robi, a implementacją definiującą, jak jest zbudowany i jak robi, to co ma zrobić. Klasa - Zgrupowanie obiektów o tych samych charakterystykach. Dziedziczenie - Wielokrotne użycie tego, co wcześniej zostało zrobione: definiowanie klas, które mają wszystkie cechy zdefiniowane wcześniej (z nadklasy) plus cechy nowe. Sprawdź stan Nalicz procent Numer: 123-4321 Stan konta: 34567 PLN Właściciel: Jan Kowalski Upoważniony:... Podpis:... Porównaj podpis Zlikwiduj konto Polimorfizm - Wybór nazwy dla operacji jest określony wyłącznie semantyką operacji. Decyzja o tym, która metoda implementująca daną operację, zależy od przynależności obiektu do odpowiedniej klasy. Upoważnij Podaj osoby upoważnione Hermetyzacja; ukrywanie informacji Hermetyzacja: zgromadzenie elementów struktury i implementacji obiektu w postaci jednej manipulowalnej bryły; oddzielenie specyfikacji obiektu od jego implementacji. Hermetyzacja pośrednio oznacza także ukrycie struktury i implementacji obiektu. Tę własność określa się jako ukrywanie informacji. Hermetyzacja i ukrywanie informacji są różnymi pojęciami, choć mocno powiązanymi. Zasada inżynierii oprogramowania (Parnas, 1972): programista ma tyle wiedzieć o obiekcie programistycznym, ile potrzeba, aby go efektywnie użyć. Wszystko, co może być przed nim ukryte, powinno być ukryte. Hermetyzacja i ukrywanie informacji jest podstawą pojęć: modułu, klasy i ADT. Hermetyzacja ortodoksyjna (Smalltalk) Na zewnątrz są widoczne metody; atrybuty obiektu są ukryte. Ergo: prawie każdy atrybut atr jest obsługiwany przez dwie metody: czytaj_atr, zmień_atr Hermetyzacja ortogonalna (C++) Dowolna własność obiektu (atrybut, metoda,...) może być prywatna (ukryta) lub publiczna Specjalne środki do specyfikowania własności prywatnych i publicznych. Dziedziczenie Generalizacja-specjalizacja jest takim związkiem pomiędzy klasami, który łączy klasę bardziej ogólną (nadklasę) z jedną lub więcej klas (tzw. podklas), będących jej specjalizacjami. Klasa, będąca specjalizacją danej klasy, oprócz własności nadklasy może posiadać (i z reguły posiada) też własności swoje. Związek generalizacji-specjalizacji może być modelowany za pomocą struktur dziedziczenia, co nie jest jedynym możliwym rozwiązaniem. Dziedziczenie inwariantów do klas jest tranzytywne (przechodnie). specjalizacja pole atrybutów Asyste nt Osoba nazwisko data ur. wiek Pracownik pensja Adiunkt Docen t pole nazwy klasy pole metod Profeso r generalizacja 14

Polimorfizm (1) Polimorfizm polymorphism Z greckiego, polimorfizm - oznacza wiele form (postaci) jednego bytu. Słowo polimorfizm też jest polimorficzne. apolimorfizm metod - (co zostało już wyjaśnione wcześniej w punkcie Operacja a metoda ) polega na tym, że operacja wywoływana za pośrednictwem komunikatu może być różnie wykonana, w zależności od rodzaju obiektu, do którego ten komunikat został wysłany; innymi słowy: może istnieć wiele metod implementujących daną operację. a Polimorfizm typów (z teorii typów) - polimorfizm w tzw. polimorficznych językach programowania - oznacza istnienie funkcji, które mogą zarówno przyjmować wartości wielu typów jako swoje argumenty, jak też i zwracać wartości wielu typów. Przykładowo, funkcja daj_pierwszy(lista) zwraca pierwszy element dowolnej listy, niezależnie od tego, czy jest to lista liczb całkowitych, czy lista liczb rzeczywistych, czy lista rekordów, czy też inna. Polimorfizm typów jest uważany za podstawę programowania ogólnego (generic). Temat pozostaje jednak w strefie akademickiej, gdyż języki z polimorfizmem typów (a w szczególności ML) uważane są za zbyt wyrafinowane dla przeciętnego programisty. Z greckiego, polimorfizm - oznacza wiele form (postaci) jednego bytu. Słowo polimorfizm też jest polimorficzne. Polimorfizm metod - (zostało już wyjaśnione w punkcie Podstawowe zasady obiektowości ) - operacja wywoływana przez komunikat może być różnie wykonana, w zależności od rodzaju obiektu, do którego ten komunikat został wysłany. Polimorfizm typów (z teorii typów) - polimorfizm w tzw. polimorficznych językach programowania - oznacza istnienie procedur lub funkcji, które mogą zarówno przyjmować wartości wielu typów jako swoje argumenty, jak też i zwracać wartości wielu typów. Przykładowo, funkcja daj_pierwszy(lista) zwraca pierwszy element dowolnej listy, niezależnie od tego, czy jest to lista liczb całkowitych, czy lista liczb rzeczywistych, czy lista rekordów, czy też inna. Polimorfizm typów jest uważany za podstawę programowania ogólnego (generic). Temat pozostaje jednak w strefie akademickiej, gdyż języki z polimorfizmem typów uważane są za zbyt wyrafinowane dla przeciętnego programisty, a w szczególności ML. Obiekt Byt (rzecz lub pojęcie) obserwowalny w dziedzinie problemowej (czyli w tym fragmencie świata rzeczywistego, którego dotyczy dany system informacyjny), odróżnialny od innych bytów, posiadający dobrze określone granice oraz nazwę jest odwzorowywany na obiekt w implementacji komputerowej. Obiekt może być złożony, tj. może składać się z innych obiektów. Pojęcie obiektu sprzyja lepszemu rozumieniu modelowanego świata rzeczywistego - byty ze świata rzeczywistego odpowiadają obiektom w programie. Obiektem może być także pewien zamknięty fragment oprogramowania (dana, procedura, moduł, dokument, okienko dialogu,...), którym można operować jak zwartą bryłą: usuwać, wyszukiwać, wiązać, kopiować, blokować, indeksować,... Obiekt ma przypisany typ, tj. wyrażenie językowe, które określa jego budowę (poprzez specyfikację atrybutów) oraz ogranicza kontekst, w którym odwołanie do obiektu może być użyte w programie. Obiekt może być powiązany z innymi obiektami związkami skojarzeniowymi, odpowiadającymi relacjom zachodzącym między odpowiednimi bytami w dziedzinie problemowej. Metodyki obiektowe Metodyka wykorzystująca pojęcia obiektowości dla celów modelowania pojęciowego oraz analizy i projektowania systemów informatycznych. Podstawowym składnikiem jest diagram klas, będący zwykle wariantem notacyjnym i pewnym rozszerzeniem diagramów encja-związek. Diagram klas zawiera: klasy, w ramach klas specyfikacje atrybutów i metod, związki generalizacji, związki asocjacji i agregacji, liczności tych związków, różnorodne ograniczenia oraz inne oznaczenia. Uzupełnieniem tego diagramu są inne: diagramy dynamiczne uwzględniające stany i przejścia pomiędzy tymi stanami, diagramy interakcji ustalające zależności pomiędzy wywołaniami metod, diagramy funkcjonalne (będące zwykle pewną mutacją diagramów przepływu danych), itd. Koncepcja przypadków użycia (use cases) zakłada odwzorowanie struktury systemu z punktu widzenia jego użytkownika. Przykłady: Express, OODA(Booch), OMT(Rumbaugh), OOSA(Shlaer-Mellor), Objectory(Jacobson), MOSES/OPEN, OOA/OOD(Coad/Yourdon), Notacja UML. Notacja a metodyka Dowolny język, w tym notacje stosowane w metodykach, oprócz składni posiada dwa znacznie od niej ważniejsze aspekty: semantykę i pragmatykę. Składnia określa, jak wolno kombinować ze sobą przyjęte oznaczenia. Semantyka określa, co należy rozumieć pod przyjętymi oznaczeniami. Pragmatyka określa, w jaki sposób i do czego należy używać przyjętych oznaczeń. Pragmatyka określa, jak do konkretnej sytuacji dopasować pewien wzorzec notacyjny. Pragmatyka wyznacza więc procesy prowadzące do wytworzenia zapisów wyników analizy i projektowania, które są zgodne z intencją autorów tej notacji. Jakakolwiek notacja nie ma większego sensu bez wiedzy o tym, w jaki sposób może być ona użyta w ramach pewnego procesu analizy i projektowania. W metodykach pragmatyka stosowanej notacji (czyli jak i do czego jej użyć) jest sprawą podstawową. Jest ona zazwyczaj trudna do objaśnienia: nie ma innego sposobu oprócz pokazania sposobów użycia na przykładach przypominających realne sytuacje. Niestety, realne sytuacje są zazwyczaj bardzo skomplikowane, co powoduje pewien infantylizm przykładów zamieszczanych w podręcznikach. Diagramy definiowane w UML Autorzy UML wychodzą z założenia, że żadna pojedyncza perspektywa spojrzenia na projektowany system nie jest wystarczająca. Stąd wiele środków: Diagramy przypadków użycia (use case) Diagramy klas, w tym diagramy pakietów Diagramy zachowania się (behavior) Diagramy stanów Diagramy aktywności Diagramy sekwencji Diagramy współpracy (collaboration) Diagramy implementacyjne Diagramy komponentów Diagramy wdrożeniowe (deployment) Diagramy te zapewniają mnogość perspektyw systemu podczas analizy i rozwoju. 15

Proces tworzenia modelu obiektowego Zadania: Identyfikacja klas i obiektów Identyfikacja związków pomiędzy klasami Identyfikacja i definiowanie pól (atrybutów) Identyfikacja i definiowanie metod i komunikatów Czynności te są wykonywane iteracyjnie. Kolejność ich wykonywania nie jest ustalona i zależy zarówno od stylu pracy, jak i od konkretnego problemu. Inny schemat realizacji procesu budowy modelu obiektowego polega na rozpoznaniu funkcji, które system ma wykonywać. Dopiero w późniejszej fazie następuje identyfikacja klas, związków, atrybutów i metod. Rozpoznaniu funkcji systemu służą modele funkcjonalne (diagramy przepływu danych) oraz model przypadków użycia. Typowe klasy: Identyfikacja klas i obiektów przedmioty namacalne (samochód, czujnik) role pełnione przez osoby (pracownik, wykładowca, student) zdarzenia, o których system przechowuje informacje (lądowanie samolotu, wysłanie zamówienia, dostawa), interakcje pomiędzy osobami i/lub systemami o których system przechowuje informacje (pożyczka, spotkanie, sesja), lokalizacje - miejsce przeznaczone dla ludzi lub przedmiotów grupy przedmiotów namacalnych (kartoteka, samochód jako zestaw części) organizacje (firma, wydział, związek) wydarzenia (posiedzenie sejmu, demonstracja uliczna) koncepcje i pojęcia (zadanie, miara jakości) dokumenty (faktura, prawo jazdy) klasy będące interfejsami dla systemów zewnętrznych klasy będące interfejsami dla urządzeń sprzętowych Obiekty, zbiory obiektów i metadane W wielu przypadkach przy definicji klasy należy dokładnie ustalić, z jakiego rodzaju abstrakcją obiektu mamy do czynienia. Należy zwrócić uwagę na następujące aspekty: czy mamy do czynienia z konkretnym obiektem w danej chwili czasowej? czy mamy do czynienia z konkretnym obiektem w pewnym odcinku czasu? czy mamy do czynienia z opisem tego obiektu (dokument, metadane)? czy mamy do czynienia z pewnym zbiorem konkretnych obiektów? Np. klasa samochód. Może chodzić o: egzemplarz samochodu wyprodukowany przez pewną fabrykę model samochodu produkowany przez fabrykę pozycję w katalogu samochodów opisujący własności modelu historię stanów pewnego konkretnego samochodu Podobnie z klasą gazeta. Może chodzić o: konkretny egzemplarz gazety kupiony przez czytelnika konkretne wydanie gazety (niezależne od ilości egzemplarzy) tytuł i wydawnictwo, niezależne od egzemplarzy i wydań partię egzemplarzy danej gazety dostarczaną codziennie do kiosku UML - przykład notacji UML (Unified Modeling Language) powstał jako synteza trzech metodyk/notacji: OMT (Rumbaugh): metodyka ta była dobra do modelowania dziedziny przedmiotowej. Nie przykrywała jednak dostatecznie dokładnie zarówno aspektu użytkowników systemu jak i aspektu implementacji/konstrukcji. OOSE (Jacobson): metodyka ta dobrze podchodziła do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywała jednak dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji/konstrukcji. OOAD (Booch): metodyka dobrze podchodziła do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywała jednak dostatecznie dobrze fazy analizy i rozpoznania wymagań użytkowników. Istniało wiele aspektów systemów, które nie były właściwie przykryte przez żadne z wyżej wymienionych podejść, np. włączenie prototypowania w cykl życiowy, rozproszenie i komponenty, przystosowanie notacji do preferencji projektantów, i inne. Celem UML jest przykrycie również tych aspektów. Zadania fazy projektowania Identyfikacja klas Zadania stojace przed wykonawcami w fazie projektowania: Uszczegółowienie wyników analizy. Projekt musi być wystarczająco szczegółowy aby mógł być podstawą implementacji. Stopień szczegółowości zależy od poziomu zaawansowania programistów. Projektowanie tych składowych systemu, które nie są związane z dziedziną problemową. Optymalizacja systemu. Dostosowanie do ograniczeń i możliwości środowiska implementacji. Określenie fizycznej struktury systemu (projekt architektury systemu). Właściwa identyfikacja klas (abstrakcji opisujących grupy bytów o podobnych własnościach, wyróżnialnych w analizowanej rzeczywistości), to kluczowa umiejętność w obiektowym podejściu do procesu konstrukcji oprogramowania. Klasy są najbardziej stabilnym elementem dziedziny problemowej. Dobry system oparty jest tak dalece, jak tylko jest to możliwe, na klasach reprezentujących grupy bytów wyróżnialnych w dziedzinie problemowej, a nie na funkcjonalności potrzebnej dziś i to dla specyficznego być może zastosowania. Oprogramowanie wykorzystujące klasy powstałe w wyniku analizy dziedzinowej jest znacznie bardziej odporne na zmiany wymagań niż oprogramowanie oparte o jednostki funkcjonalne. Ma to, tzn. oparcie oprogramowania o wykorzystanie klas, duże znaczenie dla technologii ponownego użycia. 16

Podstawowe rezultaty fazy analizy Poprzednicy UML: Poprawiony dokument opisujący wymagania Słownik danych zawierający specyfikację modelu Dokument opisujący stworzony model, zawierający: diagram klas diagram przypadków użycia diagramy sekwencji komunikatów (dla wybranych sytuacji) diagramy stanów (dla wybranych sytuacji) raport zawierający definicje i opisy klas, atrybutów, związków, metod, itd. Harmonogram fazy projektowania Wstępne przypisanie ludzi i zespołów do zadań OMT (Rumbaugh): dobry do modelowania dziedziny przedmiotowej. Nie przykrywa dostatecznie dokładnie zarówno aspektu użytkowników systemu, jak i aspektu implementacji (konstrukcji). OOSE (Jacobson): dobrze podchodzi do kwestii modelowania użytkowników i cyklu życiowego systemu. Nie przykrywa dokładnie modelowania dziedziny przedmiotowej jak i aspektu implementacji (konstrukcji). OOAD (Booch): dobrze podchodzi do kwestii projektowania, konstrukcji i związków ze środowiskiem implementacji. Nie przykrywa dostatecznie dobrze fazy rozpoznania i analizy wymagań użytkowników. Język UML Najważniejsze modele w UML wykorzystywane w fazie analizy: UML (w założeniu swoich twórców) - nie jest wysoce formalnym językiem do przedstawiania czy udowadniania nowych teorii. Ma być przede wszystkim uniwersalnym językiem modelowania ogólnego zastosowania, przeznaczony do wykorzystania tam, gdzie tworzy się systemy oprogramowania. model przypadków użycia opisujący system widziany z perspektywy jego przyszłego użytkownika (za pomocą diagramów przypadków użycia), model obiektowy przedstawiający statyczną budowę, czyli strukturę systemu (za pomocą diagramów klas i diagramów obiektów). Diagram klas może zawierać obiekty. Diagram obiektów nie zawiera klas, ale wyłącznie obiekty. Charakterystyka UML: Diagram klas przykład Diagramy przypadków Diagramy klas Diagramy dynamiczne (interakcji, stanu, aktywności) Diagramy komponentów Diagramy implementacyjne Diagramy pakietów 17

Diagram klas: Diagram obiektów: Diagram klas (class diagram) przedstawia statyczną strukturę klas oraz relacji między nimi w systemie. Diagram klas może również zawierać interfejsy oraz pakiety, a nawet instancje klas Diagram obiektów (object diagram) przedstawia obiekty i wartości danych. Diagram przypadków użycia (use case diagram) Diagram sekwencyjny Wypłata gotówki Przypadek użycia powinien mieć unikalną nazwę Aktor reprezentuje rolę, jaką w systemie może grać określony użytkownik, organizacja lub inny SI. Diagram sekwencyjny (sequence diagram) pokazuje interakcje między obiektami w pojedynczych przypadkach użycia. Pozwala na przedstawienie kolejności zdarzeń dotyczących obiektów Relacja typu <include> lub <extend> - ukazuje związek pomiędzy 2 przypadkami użycia lub przypadkiem i blokiem ponownego użycia Weryfikacja klienta Blok ponownego użycia fragment systemu, który jest używany przez kilka przypadków użycia Diagram kolaboracji Diagram stanów (statechart diagram): Diagram kolaboracji (collaboration diagram) przedstawia interakcje między obiektami w wielu przypadkach użycia; jest pomocny w fazie szukania obiektów i związków między nimi pokazuje sekwencje stanów, przez które przechodzą elementy modelu (np. obiekty lub interakcje) podczas swojego życia, pod wpływem zdarzeń zewnętrznych 18

Diagram czynności (activity diagram): przedstawia przepływ sterowania; wykorzystywany do opisu przypadków użycia lub bardziej kompleksowych operacji Diagram komponentów (component diagram) przedstawia elementy systemu, które mogą być wielokrotnie użyte, ze ściśle zdefiniowanymi interfejsami Diagram konfiguracyjny (deployment diagram) pokazuje konfigurację fizycznych elementów działającego systemu oraz komponentów programowych, procesów i obiektów, które w ich ramach istnieją Literatura Wrycza St., Marcinkowski B., Wyrzykowski K.: Język UML w projektowaniu systemów informatycznych, Helion 2006 Subieta K.: Obiektowość w projektowaniu i bazach danych. Akademicka Oficyna Wydawnicza PLJ Warszawa 1998 Subieta K.: Słownik terminów z zakresu obiektowości. Akademicka Oficyna Wydawnicza PLJ, Warszawa 1999 Słodzień J., Strzembosz E.: Analiza i projektowanie systemów informatycznych. PJWSTK, Warszawa 2003 Roszkowski J.: Analiza i projektowanie strukturalne. Helion 2002 Internet 19