Cechy narzędzi CASE (1):
|
|
- Amelia Dudek
- 8 lat temu
- Przeglądów:
Transkrypt
1 Narzędzia CASE: Inżynieria Systemów Informatycznych CASE metodyki i narzędzia Jerzy KORCZAK, Barbara SMOK <jerzy.korczak, brabara.smok>@ue.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
2 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
3 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 % 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
4 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
5 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
6 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
7 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
8 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
9 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
10 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
11 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
12 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
13 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
14 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: Stan konta: 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
15 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
16 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
17 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
18 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
19 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
Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl
Komputerowe Systemy Przemysłowe: Modelowanie - UML Arkadiusz Banasik arkadiusz.banasik@polsl.pl Plan prezentacji Wprowadzenie UML Diagram przypadków użycia Diagram klas Podsumowanie Wprowadzenie Języki
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Bardziej szczegółowoFazy analizy (modelowania) oraz projektowania FAZA ANALIZY:
Fazy analizy (modelowania) oraz projektowania Analiza bez brania pod uwagę szczegółów implementacyjnych Projektowanie ze szczegółami implementacyjnymi. FAZA ANALIZY: Celem fazy analizy jest ustalenie wszystkich
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoCel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Bardziej szczegółowoModelowanie danych, projektowanie systemu informatycznego
Modelowanie danych, projektowanie systemu informatycznego Modelowanie odwzorowanie rzeczywistych obiektów świata rzeczywistego w systemie informatycznym Modele - konceptualne reprezentacja obiektów w uniwersalnym
Bardziej szczegółowoPaweł Kurzawa, Delfina Kongo
Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management
Bardziej szczegółowoZARZĄDZANIU. Wykład VI. dr Jan Kazimirski
INFORMATYKA W ZARZĄDZANIU Wykład VI dr Jan Kazimirski jankazim@mac.edu.pl http://www.mac.edu.pl/jankazim MODELOWANIE SYSTEMÓW UML Literatura Joseph Schmuller UML dla każdego, Helion 2001 Perdita Stevens
Bardziej szczegółowoAnaliza strukturalna systemów informatycznych
Analiza strukturalna systemów informatycznych Modelowanie i analiza systemów informatycznych, w4 Dr inż. Walery Susłow walery.suslow@ie.tu.koszalin.pl Metodyki tworzenia systemów informatycznych (TSI)
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoWprowadzenie do metodologii modelowania systemów informacyjnych. Strategia (1) Strategia (2) Etapy Ŝycia systemu informacyjnego
Etapy Ŝycia systemu informacyjnego Wprowadzenie do metodologii modelowania systemów informacyjnych 1. Strategia 2. Analiza 3. Projektowanie 4. Implementowanie, testowanie i dokumentowanie 5. WdroŜenie
Bardziej szczegółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoMODELOWANIE OBIEKTOWE
(Wykład na podstawie literatury: M.Śmiałek Zrozumieć UML 2.0, Helion 2005) UML Unified Modeling Language (język do specyfikowania, wizualizowania, konstruowania i dokumentacji tzw. artefactów oraz czynności
Bardziej szczegółowo1 Projektowanie systemu informatycznego
Plan wykładu Spis treści 1 Projektowanie systemu informatycznego 1 2 Modelowanie pojęciowe 4 2.1 Encja....................................... 5 2.2 Własności.................................... 6 2.3 Związki.....................................
Bardziej szczegółowoZasady organizacji projektów informatycznych
Zasady organizacji projektów informatycznych Systemy informatyczne w zarządzaniu dr hab. inż. Joanna Józefowska, prof. PP Plan Definicja projektu informatycznego Fazy realizacji projektów informatycznych
Bardziej szczegółowoProjektowanie systemów informatycznych. wykład 6
Projektowanie systemów informatycznych wykład 6 Iteracyjno-przyrostowy proces projektowania systemów Metodyka (ang. methodology) tworzenia systemów informatycznych (TSI) stanowi spójny, logicznie uporządkowany
Bardziej szczegółowoDiagramy przepływu danych I
Literatura bazowa: Projektowanie systemów informatycznych Zajęcia: Diagramy przepływu danych I E.Yourdon, Współczesna analiza strukturalna, WNT, Warszawa 1996 J.Roberston, S.Robertson, Pełna analiza systemowa,
Bardziej szczegółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoModelowanie i Programowanie Obiektowe
Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do
Bardziej szczegółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Bardziej szczegółowoWPROWADZENIE DO UML-a
WPROWADZENIE DO UML-a Maciej Patan Instytut Sterowania i Systemów Informatycznych Dlaczego modelujemy... tworzenie metodologii rozwiązywania problemów, eksploracja różnorakich rozwiązań na drodze eksperymentalnej,
Bardziej szczegółowoFaza analizy (modelowania) Faza projektowania
Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań
Bardziej szczegółowoFaza Określania Wymagań
Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie
Bardziej szczegółowoWprowadzenie do systemów informacyjnych
Uwagi ogólne: Wprowadzenie do systemów informacyjnych Projektowanie obiektowe Obiektowość jest nową ideologią, która zmienia myślenie realizatorów SI z zorientowanego na maszynę na zorientowane na człowieka.
Bardziej szczegółowoPodstawy Programowania Obiektowego
Podstawy Programowania Obiektowego Wprowadzenie do programowania obiektowego. Pojęcie struktury i klasy. Spotkanie 03 Dr inż. Dariusz JĘDRZEJCZYK Tematyka wykładu Idea programowania obiektowego Definicja
Bardziej szczegółowoMichał Adamczyk. Język UML
Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy
Bardziej szczegółowoSVN. 10 października 2011. Instalacja. Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację. Rysunek 1: Instalacja - krok 1
SVN 10 października 2011 Instalacja Wchodzimy na stronę http://tortoisesvn.tigris.org/ i pobieramy aplikację uruchamiany ponownie komputer Rysunek 1: Instalacja - krok 1 Rysunek 2: Instalacja - krok 2
Bardziej szczegółowoNarzędzia CASE dla.net. Łukasz Popiel
Narzędzia CASE dla.net Autor: Łukasz Popiel 2 Czym jest CASE? - definicja CASE (ang. Computer-Aided Software/Systems Engineering) g) oprogramowanie używane do komputerowego wspomagania projektowania oprogramowania
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoArchitektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Bardziej szczegółowoTECHNOLOGIE OBIEKTOWE. Wykład 3
TECHNOLOGIE OBIEKTOWE Wykład 3 2 Diagramy stanów 3 Diagram stanu opisuje zmiany stanu obiektu, podsystemu lub systemu pod wpływem działania operacji. Jest on szczególnie przydatny, gdy zachowanie obiektu
Bardziej szczegółowoCo to jest jest oprogramowanie? 8. Co to jest inżynieria oprogramowania? 9. Jaka jest różnica pomiędzy inżynierią oprogramowania a informatyką?
ROZDZIAŁ1 Podstawy inżynierii oprogramowania: - Cele 2 - Zawartość 3 - Inżynieria oprogramowania 4 - Koszty oprogramowania 5 - FAQ o inżynierii oprogramowania: Co to jest jest oprogramowanie? 8 Co to jest
Bardziej szczegółowoEgzamin / zaliczenie na ocenę*
WYDZIAŁ PODSTAWOWYCH PROBLEMÓW TECHNIKI Zał. nr 4 do ZW33/01 KARTA PRZEDMIOTU Nazwa w języku polskim : INŻYNIERIA OPROGRAMOWANIA Nazwa w języku angielskim: SOFTWARE ENGINEERING Kierunek studiów (jeśli
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA. laboratorium
INŻYNIERIA OPROGRAMOWANIA laboratorium UML 1/4 UML (Unified Modeling Language) - język modelowania obiektowego systemów i procesów [Wikipedia] Spojrzenie na system z różnych perspektyw dzięki zastosowaniu
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH I KARTA PRZEDMIOTU CEL PRZEDMIOTU PRZEWODNIK PO PRZEDMIOCIE C1. Podniesienie poziomu wiedzy studentów z inżynierii oprogramowania w zakresie C.
Bardziej szczegółowoKARTA MODUŁU KSZTAŁCENIA
KARTA MODUŁU KSZTAŁCENIA I. Informacje ogólne 1 Nazwa modułu kształcenia Inżynieria 2 Nazwa jednostki prowadzącej moduł Instytut Informatyki, Zakład Informatyki Stosowanej 3 Kod modułu (wypełnia koordynator
Bardziej szczegółowoINFORMATYKA GEODEZYJNO- KARTOGRAFICZNA. Modelowanie danych. Model związków-encji
Modelowanie danych. Model związków-encji Plan wykładu Wprowadzenie do modelowania i projektowania kartograficznych systemów informatycznych Model związków-encji encje atrybuty encji związki pomiędzy encjami
Bardziej szczegółowoKARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20
Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:
Bardziej szczegółowoMODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM.
PRACA DYPLOMOWA WYŻSZE STUDIA ZAWODOWE MODELOWANIE SYSTEMU INFORMATYCZNEGO WSPOMAGAJĄCEGO DZIAŁALNOŚĆ USŁUGOWĄ W ŚRODOWISKU OBIEKTOWO ZORIENTOWANYM. Marcin Brudka 3901 Promotor: Prof. dr hab. inż. Piotr
Bardziej szczegółowoModelowanie KONCEPCJA. przedstawiana przez INDYWIDUALNOŚĆ GHJ 6
Modelowanie KONCEPCJA staje się zrozumiała wyrażona za pomocą INDYWIDUALNOŚĆ przedstawiana przez SYMBOL GHJ 6 Podejścia w modelowaniu Pełny zakres WSTĘPUJĄCE Opuszczone szczegóły ZSTĘPUJĄCE Niepotrzebne
Bardziej szczegółowoPodstawy Inżynierii Oprogramowania. Wykład 6 Modele systemu
Podstawy Inżynierii Oprogramowania Wykład 6 Modele systemu 2 3 4 Dla klienta Dla projektanta 5 6 Agenda Modelowanie pojęciowe Modele kontekstowe Modele zachowania, danych, obiektowe Język UML (ang. Unified
Bardziej szczegółowoBaza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego
PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga
Bardziej szczegółowoWykład 3 Wymagania. MIS n Inżynieria oprogramowania Październik Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie
Wykład 3 MIS-1-505-n Inżynieria Październik 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 3.1 Agenda 1 2 3 4 5 3.2 Czynności w czasie produkcji. Inżynieria stara się zidentyfikować
Bardziej szczegółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoProgramowanie obiektowe - 1.
Programowanie obiektowe - 1 Mariusz.Masewicz@cs.put.poznan.pl Programowanie obiektowe Programowanie obiektowe (ang. object-oriented programming) to metodologia tworzenia programów komputerowych, która
Bardziej szczegółowoUML cz. I. UML cz. I 1/1
UML cz. I UML cz. I 1/1 UML cz. I 2/1 UML - Unified Modeling Language ujednolicony można go współdzielić z wieloma pracownikami modelowania służy do opisu projektowanego modelu język posiada opisaną strukturę
Bardziej szczegółowoBaza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego
PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga
Bardziej szczegółowoAnaliza i projektowanie obiektowe w UML Kod przedmiotu
Analiza i owanie obiektowe w UML - opis przedmiotu Informacje ogólne Nazwa przedmiotu Analiza i owanie obiektowe w UML Kod przedmiotu 11.3-WK-MATP-UML-W-S14_pNadGen5M44E Wydział Kierunek Wydział Matematyki,
Bardziej szczegółowoDariusz Brzeziński. Politechnika Poznańska, Instytut Informatyki
Dariusz Brzeziński Politechnika Poznańska, Instytut Informatyki Object-oriented programming Najpopularniejszy obecnie styl (paradygmat) programowania Rozwinięcie koncepcji programowania strukturalnego
Bardziej szczegółowoProjektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II)
Projektowanie i wdrażanie systemów informatycznych (materiały do wykładu cz. II) Jacek Cichosz www.zssk.pwr.wroc.pl Katedra Systemów i Sieci Komputerowych Politechnika Wrocławska Narzędzia modelowania
Bardziej szczegółowoPodstawy modelowania programów Kod przedmiotu
Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Bardziej szczegółowoBłędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation)
Błędy procesu tworzenia oprogramowania (Badania firmy Rational Software Corporation) Zarządzanie wymaganiami Ad hoc (najczęściej brak zarządzania nimi) Niejednoznaczna, nieprecyzyjna komunikacja Architektura
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoSpis treści. Analiza i modelowanie_nowicki, Chomiak_Księga1.indb :03:08
Spis treści Wstęp.............................................................. 7 Część I Podstawy analizy i modelowania systemów 1. Charakterystyka systemów informacyjnych....................... 13 1.1.
Bardziej szczegółowoInformatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny) kierunkowy (podstawowy / kierunkowy / inny HES)
KARTA MODUŁU / KARTA PRZEDMIOTU Kod modułu Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu w języku angielskim Modeling and Analysis of Information Systems Obowiązuje od roku akademickiego
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH
KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków
Bardziej szczegółowoWykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych
Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław
Bardziej szczegółowo1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Bardziej szczegółowoWykład I. Wprowadzenie do baz danych
Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles
Bardziej szczegółowoPRZEWODNIK PO PRZEDMIOCIE
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Modeling and analysis of computer systems Kierunek: Informatyka Forma studiów: Stacjonarne Rodzaj przedmiotu: Poziom kwalifikacji: obowiązkowy
Bardziej szczegółowoPojęcie bazy danych. Funkcje i możliwości.
Pojęcie bazy danych. Funkcje i możliwości. Pojęcie bazy danych Baza danych to: zbiór informacji zapisanych według ściśle określonych reguł, w strukturach odpowiadających założonemu modelowi danych, zbiór
Bardziej szczegółowoKarta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty
Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy
Bardziej szczegółowoPodstawy inżynierii oprogramowania
Podstawy inżynierii oprogramowania Modelowanie. Podstawy notacji UML Aleksander Lamża ZKSB Instytut Informatyki Uniwersytet Śląski w Katowicach aleksander.lamza@us.edu.pl Zawartość Czym jest UML? Wybrane
Bardziej szczegółowoMODELOWANIE PRZEPŁYWU DANYCH
MODELOWANIE PRZEPŁYWU DANYCH 1. Diagram przepływu danych (DFD) 2. Weryfikacja modelu strukturalnego za pomocą DFD Modelowanie SI - GHJ 1 Definicja i struktura DFD Model części organizacji rozważany z punktu
Bardziej szczegółowoDr Katarzyna Grzesiak-Koped
Dr Katarzyna Grzesiak-Koped 2 Tworzenie oprogramowania Najlepsze praktyki IO Inżynieria wymagao Technologia obiektowa i język UML Techniki IO Metodyki zwinne Refaktoryzacja Mierzenie oprogramowania Jakośd
Bardziej szczegółowoPODSTAWY BAZ DANYCH. 5. Modelowanie danych. 2009/ Notatki do wykładu "Podstawy baz danych"
PODSTAWY BAZ DANYCH 5. Modelowanie danych 1 Etapy tworzenia systemu informatycznego Etapy tworzenia systemu informatycznego - (według CASE*Method) (CASE Computer Aided Systems Engineering ) Analiza wymagań
Bardziej szczegółowoPrzepływy danych. Oracle Designer: Modelowanie przepływów danych. Diagramy przepływów danych (1) Diagramy przepływów danych (2)
Przepływy danych Oracle Designer: Modelowanie przepływów danych Cele: zobrazowanie funkcji zachodzących w organizacji, identyfikacja szczegółowych informacji, przetwarzanych przez funkcje, pokazanie wymiany
Bardziej szczegółowoBazy Danych. Modele danych. Krzysztof Regulski WIMiIP, KISiM,
Bazy Danych Modele danych Krzysztof Regulski WIMiIP, KISiM, regulski@agh.edu.pl Cele modelowania Strategia informatyzacji organizacji Cele informatyzacji Specyfikacja wymagań użytkownika Model procesów
Bardziej szczegółowoE-1IZ s2. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)
KARTA MODUŁU / KARTA PRZEDMIOTU Załącznik nr 7 do Zarządzenia Rektora nr 10/12 z dnia 21 lutego 2012r. Kod modułu E-1IZ2-1003-s2 Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu
Bardziej szczegółowoZalety projektowania obiektowego
Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy
Bardziej szczegółowoInżynieria oprogramowania. Jan Magott
Inżynieria oprogramowania Jan Magott Literatura do języka UML G. Booch, J. Rumbaugh, I. Jacobson, UML przewodnik użytkownika, Seria Inżynieria oprogramowania, WNT, 2001, 2002. M. Fowler, UML w kropelce,
Bardziej szczegółowoRysunek 1: Przykłady graficznej prezentacji klas.
4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez
Bardziej szczegółowoModelowanie i analiza systemów informatycznych
Modelowanie i analiza systemów informatycznych wykład 6 Komputerowe wspomaganie modelowania systemów (CASE) definicja, charakterystyka, podziałi składowe narzędzi CASE Zautomatyzowane wspomaganie procesu
Bardziej szczegółowoNazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH. Modeling and analysis of computer systems Forma studiów: Stacjonarne
Nazwa przedmiotu: MODELOWANIE I ANALIZA SYSTEMÓW INFORMATYCZNYCH Kierunek: Informatyka Modeling and analysis of computer systems Forma studiów: Stacjonarne Rodzaj przedmiotu: obowiązkowy w ramach specjalności:
Bardziej szczegółowoUniwersytet w Białymstoku Wydział Ekonomiczno-Informatyczny w Wilnie SYLLABUS na rok akademicki 2012/2013
SYLLABUS na rok akademicki 01/013 Tryb studiów Studia stacjonarne Kierunek studiów Informatyka Poziom studiów Pierwszego stopnia Rok studiów/ semestr III/VI Specjalność Bez specjalności Kod katedry/zakładu
Bardziej szczegółowoSystemy informatyczne. Modelowanie danych systemów informatycznych
Modelowanie danych systemów informatycznych Diagramy związków encji Entity-Relationship Diagrams Modelowanie danych diagramy związków encji ERD (ang. Entity-Relationship Diagrams) diagramy związków encji
Bardziej szczegółowoProjektowanie logiki aplikacji
Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie logiki aplikacji Zagadnienia Rozproszone przetwarzanie obiektowe (DOC) Model klas w projektowaniu logiki aplikacji Klasy encyjne a klasy
Bardziej szczegółowoProjekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON
Projekt współfinansowany przez Unię Europejską w ramach Europejskiego Funduszu Społecznego Projekt: Współpraca i Rozwój wzrost potencjału firm klastra INTERIZON Opis szkoleń z obszaru INFORMATYKA planowanych
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Instrukcja do laboratorium rok akad. 2014/2015 Informacje podstawowe: Celem laboratorium jest nabycie przez studentów praktycznej umiejętności wykonywania modeli analitycznych
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej
Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej
Bardziej szczegółowoProjektowanie Zorientowane na Dziedzinę. ang. Domain Driven Design
Projektowanie Zorientowane na Dziedzinę ang. Domain Driven Design 2 Projektowanie Stan posiadania Przypadki użycia Model dziedziny Operacje systemowe Kontrakty dla operacji systemowych Problemy do rozwiązania
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia Materiały dla nauczyciela Projekt
Bardziej szczegółowoBAZY DANYCH model związków encji. Opracował: dr inż. Piotr Suchomski
BAZY DANYCH model związków encji Opracował: dr inż. Piotr Suchomski Świat rzeczywisty a baza danych Świat rzeczywisty Diagram związków encji Model świata rzeczywistego Założenia, Uproszczenia, ograniczenia
Bardziej szczegółowoE-I2SG-2010-s1. Informatyka II stopień (I stopień / II stopień) ogólnoakademicki (ogólno akademicki / praktyczny)
KARTA MODUŁU / KARTA PRZEDMIOTU Załącznik nr 7 do Zarządzenia Rektora nr 10/12 z dnia 21 lutego 2012r. Kod modułu E-I2SG-2010-s1 Nazwa modułu Modelowanie i Analiza Systemów Informatycznych Nazwa modułu
Bardziej szczegółowoWymagania klienta mogą być opisane na różnych poziomach abstrakcji: Podział wymagań: Wymagania funkcjonalne Wymagania niefunkcjonalne
Definiowanie wymagań Wymagania klienta mogą być opisane na różnych poziomach abstrakcji: 1. Definicja wymagań jest zapisana w języku naturalnym jako rezultat rozmów z przedstawiciela klienta 2. Specyfikacja
Bardziej szczegółowoBazy danych 2. dr inż. Tadeusz Jeleniewski
Wykład 4 Projektowanie bazy danych i procesów aplikacji Modelowanie reguł przetwarzania Środowisko przykładowego programu do modelowania reguł przetwarzania Reguły poprawności 2018-02-23 Bazy danych 2
Bardziej szczegółowoZofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2
Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów
Bardziej szczegółowoTechnologie obiektowe
WYKŁAD dr inż. Paweł Jarosz Instytut Informatyki Politechnika Krakowska mail: pjarosz@pk.edu.pl LABORATORIUM dr inż. Paweł Jarosz (3 grupy) mgr inż. Piotr Szuster (3 grupy) warunki zaliczenia Obecność
Bardziej szczegółowoMariusz Trzaska Modelowanie i implementacja systemów informatycznych
Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Notka biograficzna Dr inż. Mariusz Trzaska jest adiunktem w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zajmuje się
Bardziej szczegółowoBazy danych. Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Wykład 3: Model związków encji.
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Bazy danych Wykład 3: Model związków encji. dr inż. Magdalena Krakowiak makrakowiak@wi.zut.edu.pl Co to jest model związków encji? Model związków
Bardziej szczegółowoDiagramy przepływu danych II model środowiskowy, diagram odpowiedzi na zdarzenia KI AE PSI 2006 1
Projektowanie systemów informatycznych Zajęcia: Diagramy przepływu danych II model środowiskowy, diagram odpowiedzi na zdarzenia KI AE PSI 2006 1 Model podstawowy składa się z: modelu środowiskowego modelu
Bardziej szczegółowo030 PROJEKTOWANIE BAZ DANYCH. Prof. dr hab. Marek Wisła
030 PROJEKTOWANIE BAZ DANYCH Prof. dr hab. Marek Wisła Elementy procesu projektowania bazy danych Badanie zależności funkcyjnych Normalizacja Projektowanie bazy danych Model ER, diagramy ERD Encje, atrybuty,
Bardziej szczegółowo