MODELOWANIE STRUKTURALNE DEFINICJE, NOTACJA, TECHNIKI I NARZĘDZIA
|
|
- Jakub Alojzy Łukasik
- 9 lat temu
- Przeglądów:
Transkrypt
1 ZESZYTY NAUKOWE Dariusz OLCZYK 1 MODELOWANIE STRUKTURALNE DEFINICJE, NOTACJA, TECHNIKI I NARZĘDZIA Streszczenie W artykule wyróżnione zostały dwa zasadnicze podejścia do analizy i modelowania wykorzystywane obecnie w procesie budowy systemów informatycznych: strukturalne oraz obiektowe. Myśl przewodnia to próba odpowiedzi na pytania dotyczące istoty stosowania podejścia strukturalnego, wyjaśnienia podstawowych pojęć stosowanych w praktyce oraz przybliżenia notacji wbudowanych w różnego rodzaju narzędzia wspomagające proces projektowania systemów. Zasadnicza część artykułu zawiera szczegółowe informacje nt. sposobów tworzenia diagramów FHD, DFD oraz ERD. Abstract The article highlights two basic approaches to analysis and modeling currently used in the information systems development: structural and object-oriented. The keynote is an attempt to answer questions about the substance of the structural approach and to clarify key concepts applied in practice as well as to familiarize with notations embedded in different types of tools supporting the process of system design. The main part of the article provides detailed information about the ways of FHD, ERD and DFD diagrams creation. 1. WPROWADZENIE Bezsprzecznie budowa nowych lub modernizacja istniejących systemów informatycznych to nadal trzon działalności informatycznej w kraju i na świecie. Ciągły postęp cywilizacyjny, a co za tym idzie rozwój wszelakich form aktywności człowieka wykorzystującego osiągnięcia świata komputerów, pociąga za sobą potrzebę tworzenia coraz to nowocześniejszych i coraz bardziej złożonych systemów informatycznych. Tym samym przed zespołami IT zajmującymi się wytwarzaniem oprogramowania stawiane są z roku na rok coraz trudniejsze zadania. Wyzwanie jakim jest budowa w pełni funkcjonalnego i akceptowalnego przez odbiorcę biznesowego systemu w określonych reżimach czasowych oraz kosztowych wymaga od specjalistów 1 Mgr inż. Dariusz Olczyk jest wykładowcą w Warszawskiej Wyższej Szkole Informatyki 87
2 Dariusz OLCZYK IT przede wszystkim metodycznego podejścia do procesu wytwarzania oprogramowania, a w szczególności przeprowadzenia rzetelnej analizy systemu informacyjnego organizacji. Gwałtowny rozwój takiej dziedziny informatycznej jaką jest inżynieria oprogramowania w pełni potwierdza powyższą tezę. Pamiętajmy, iż w procesie analizy mamy do osiągnięcia zasadniczo dwa główne cele: po pierwsze chcemy stworzyć zbiór wymagań użytkownika, czyli odpowiedzieć na pytanie co klient potrzebuje, po drugie zbudować logiczny model systemu, który stanie się osią spinającą wszystkie kolejne elementy projektu. Gdyby spojrzeć na zagadnienie modelowania systemów informatycznych poprzez pryzmat historii rozwoju branży informatycznej na przestrzeni ostatnich 40 lat to wyraźnie widać kolejne fazy, przez które to modelowanie przeszło. Lata 70-te to w zasadzie dominacja sprzętu, gdzie oprogramowanie stanowi wyłącznie dodatek. Kolejne lata przynoszą stopniowe acz wyraźne odwrócenie tego stanu na korzyść oprogramowania. Przełom lat 70-tych i 80-tych oraz związany z nim kryzys oprogramowania spowodował narodziny wspomnianej już wcześniej inżynierii oprogramowania. W tym też czasie obserwujemy pojawienie się podejścia strukturalnego stanowiącego pierwsze prawdziwie inżynierskie podejście do modelowania informacji. Z kolei lata 90-te to dynamiczny rozwój podejścia obiektowego spowodowanego głównie popularnością pierwszego istotnego dla przemysłu języka obiektowego jakim był C++. Śmiało można zaryzykować twierdzenie, iż informatycy, a w szczególności projektanci/analitycy systemów informatycznych to jedna z nielicznych grup zawodowych, zapewne tuż obok filozofów, zastanawiająca się nad złożonością otaczającego nas świata. Zapewne właśnie ta różnorodność rzeczywistości z jaką styka się informatyk stanowi o atrakcyjności tego zawodu z drugiej jednak strony jest podstawowym i zdecydowanie niebanalnym problemem do rozwiązania w trakcie projektu. Modelowanie, które w swojej istocie ma ten świat zewnętrzny opisać, uporządkować i wyjaśnić reguły jego działania jest tworzeniem swego rodzaju mapy drogowej dla projektu. Tworząc tą mapę szukamy rzeczy ważnych, a pomijamy nieistotne, generalizujemy pewne informacje, ale przede wszystkim identyfikujemy obiekty i szukamy zależności między nimi. Trzeba pamiętać, że tak stworzony obraz świata zewnętrznego musi być zrozumiały dla wszystkich interesariuszy projektu, zarówno przedstawicieli biznesu jak i obszaru IT. Znaczenie modelowania w cyklu projektowym cały czas wyraźnie rośnie, a wraz z pojawieniem się narzędzi klasy CASE nastąpiło wyraźne przesunięcie ciężaru na elementy tworzenia opisu operującego 88
3 MODELOWANIE STRUKTURALNE DEFINICJE, NOTACJA, TECHNIKI I NARZĘDZIA pojęciami bliskimi zwykłym ludziom w stosunku do tradycyjnego kodowania. Na tym gruncie popularność zdobyło podejście obiektowe. Tutaj bowiem widzimy bezpośrednie korelacje między elementami tworzonych diagramów a elementami ze świata rzeczywistego. Pytanie jakie stawiamy sobie na wstępie niniejszego wykładu to pytanie o zasadność stosowania podejścia strukturalnego w nowych projektach. Czy ten sposób modelowania nie powinien już odejść do lamusa, czy nadal są obszary zastosowań dla których to podejście możne być najlepsze lub chociaż nie gorsze? 2. PODEJŚCIE STRUKTURALNE vs. OBIEKTOWE Podejście strukturalne Cechą charakterystyczną podejścia strukturalnego jest traktowanie świata zewnętrznego jako istoty dualnej składającej się z dwu bytów: danych, procesów przetwarzania. Klasyczna analiza strukturalna zaproponowana przez Toma DeMarco (dzisiaj już rzadko stosowana w praktyce) proponowała kaskadowy, zorientowany na kolejne fazy model budowy systemu informatycznego. Na gruncie krytyki klasycznego podejścia DeMarco powstały nowoczesne metodyki strukturalne, np. nowoczesna analiza strukturalna Yourdona (Modern Structured Analysis) czy metoda SSADM (Structural System Analysis and design Method). Zrezygnowano w nich z modelu kaskadowego na rzecz modeli umożliwiających szybką analizę i budowę oprogramowania, przede wszystkim modelu przyrostowego. Istotną cechą modelowania strukturalnego nadal pozostaje rozdzielenie pojęcia danych i funkcji, pomimo faktu iż nowoczesna analiza strukturalna zbliżyła oba modele wprowadzając mechanizmy zdarzeń i transakcji, które starały się łączyć strumienie danych i procesy. Jeśli zatem chcemy wymienić podstawowe cechy modelowania strukturalnego to będą to na pewno: orientacja na funkcje i procesy, orientacja na dane, analiza zstępująca z góry na dół (top-down), priorytet analizy logicznej, odrębność modelowania danych i procesów, ustrukturalizowane narzędzia i techniki. Głównym celem analizy strukturalnej systemów informatycznych jest stworzenie specyfikacji funkcjonalnych systemu, które będą: graficzne diagramy uzupełnione o szczegółowy materiał tekstowy, 89
4 Dariusz OLCZYK podzielone poszczególne części specyfikacji można czytać i analizować niezależnie od innych, minimalnie nadmiarowe zmiany w wymaganiach użytkownika powinny powodować zmiany tylko w jednej części specyfikacji. Analiza strukturalna koncentruje się na stworzeniu dwóch modeli dziedziny problemu: modelu danych część pasywna systemu, modelu funkcji aktywna część modelu. Wynika z tego faktu proste ale i niezwykle istotne spostrzeżenie, że metody strukturalne mogą być szczególnie przydatne w przypadkach kiedy jeden z aspektów systemu pasywny (dane) lub aktywny (funkcje) jest zdecydowanie dominujący. A zatem jeśli chcemy zbudować system informatyczny obsługujący przechowywanie i wyszukiwanie złożonych danych, a nie realizujący złożone funkcje (dominacja modelu danych) lub system realizujący złożone funkcje związane np. z obliczeniami naukowymi na prostych danych (dominacja modelu funkcjonalnego) wybór podejścia strukturalnego będzie zdecydowanie właściwy. Podejście obiektowe Podejście obiektowe w modelowaniu systemów powstało w połowie lat 80-tych w wyniku gwałtownego rozwoju i wzrostu popularności obiektowych języków programowania (Java, VisualBasic, C+). Nowe koncepcje, które wówczas zaproponowano, stały się głównym trendem w latach następnych w czasie powstawania zarówno nowych języków programowania obiektowego jak i specjalizowanych języków analizy projektowania obiektowego. Myśl o połączeniu dwu modeli: danych i funkcji, których niezależność stanowiła istotną wadę analizy strukturalnej, jest najbardziej widoczną zmianą, jaka przyniosła analiza obiektowa. Najważniejsze zalety nowego podejścia to pojęcie klasy i obiektu łączącego w sobie z definicji dane i operacje oraz naturalna orientacja na przyrostowy model rozwoju oprogramowania. Tym samym łatwo jest wymienić podstawowe cechy modelowania obiektowego: integracja modelu danych i procesów, powiązanie danych i funkcji w ramach obiektów, hermetyzacja (inkapsulacja) zmiana dotyczy tylko danego (jednego) obiektu, grupowanie obiektów w klasy, dziedziczenie danych i procedur w ramach hierarchii klas, komunikacja miedzy obiektami za pomocą komunikatów. W analizie obiektowej podstawową strukturą modelowania jest obiekt (klasa), a system jest przedstawiany jako kolekcja obiektów o określonych cechach realizujących 90
5 MODELOWANIE STRUKTURALNE DEFINICJE, NOTACJA, TECHNIKI I NARZĘDZIA zadania z wykorzystaniem metod (funkcji). Dynamiczna strona systemu opisana jest przez model interakcji pomiędzy obiektami, które zachodzą w wyniku wysyłania i odbierania przez obiekty komunikatów. W podsumowaniu rozważań na temat podobieństw i różnic obu podejść poniżej zaprezentowane zostało zestawienie najistotniejszych cech. PODEJŚCIE STRUKTURALNE dane i procesy modelowane osobno, wykorzystanie w zasadzie tylko prostych typów danych, dobrze dostosowane do relacyjnego modelu danych, podstawowe techniki diagramy związków encji (ERD), hierarchie funkcji (FHD), diagramy przepływu danych (DFD). 3. DIAGRAMY W ANALIZIE STRUKTURALNEJ PODEJŚCIE OBIEKTOWE dane i procesy modelowane łącznie, wykorzystują złożone typy danych, dostosowane do obiektowego modelu danych, podstawowe techniki: diagramy klas UML, przypadki użycia i modele dynamiczne UML W przypadku realizacji zadania projektowego z wykorzystaniem modelowania strukturalnego wykonywane są zazwyczaj trzy podstawowe diagramy w następującej kolejności: Diagram Hierarchii Funkcji (Function Hierarchy Diagram) jako reprezentacja wymagań klienta w zakresie realizacji przez system określonych operacji, Diagram Związków Encji (Entity Relationship Diagram) jako reprezentacja danych jakie muszą być przez system przetwarzane, Diagram Przepływu Danych (Data Flow Diagram) jako element spinający część statyczną (dane) i dynamiczną (funkcje). Poniżej przedstawiona zostanie charakterystyka ww. diagramów a w tym zasady tworzenia, notacja, przykłady oraz wskazówki dla osób wykonujących modele z wykorzystaniem podejścia strukturalnego. Diagram Hierarchii Funkcji Diagram ten jest narzędziem modelowania, pozwalającym opisać w postaci modelu pojęciowego (konceptualnego) czym zajmuje się organizacja, dla której chcemy stworzyć system informatyczny. Jest to pierwszy etap w procesie określania wymagań funkcjonalnych systemu. 91
6 Dariusz OLCZYK Tworząc FHD patrzymy na dziedzinę problemu z perspektywy funkcji, które są realizowane w kontekście celów, które firma chce osiągnąć. W utworzonej hierarchii, funkcje wyższego poziomu opisują istotę działania firmy, natomiast dekompozycja w dół (rozkład funkcji na bardziej elementarne) pokazuje jak podfunkcje przyczyniają się do realizacji funkcji nadrzędnych. Podstawą dobrego modelu firmy jest odwzorowanie w nim wszystkich potrzeb funkcjonalnych przedsiębiorstwa, niezależnie czy mają one związek z informatyzacją czy też nie. Poniżej pokazany jest przykład prostego diagramu FHD opisującego funkcjonalność związaną z przeprowadzeniem zajęć z przedmiotu Inżynieria Oprogramowania. Przy tworzeniu tego typu diagramu należy pamiętać, że w nazwach funkcji powinny znaleźć się pojęcia (terminy), które są używane w organizacji. Ponadto opis powinien być precyzyjny tzn. określać dokładnie to, co dana funkcja realizuje. Dobrą praktyką jest rozpoczynanie nazwy funkcji od czasownika. Etykieta funkcji jest jej nazwą skróconą stosowaną dla wygody. Umożliwia ona szybkie odwoływanie się do danej funkcji podczas analizy. Często jest ona liczbą określającą pozycje funkcji w hierarchii. Już teraz można także wspomnieć, iż te same funkcje wymienione w diagramie FHD pojawia się również w diagramie przepływu danych. Oznaczenia liczbowe tutaj naniesione okażą się wtedy nieoceniona informacją decydującą o czytelności diagramu DFD. Przykład FHD 92
7 MODELOWANIE STRUKTURALNE DEFINICJE, NOTACJA, TECHNIKI I NARZĘDZIA Aby stworzyć dobry Diagram Hierarchii Funkcji należy pamiętać aby hierarchia była: dokładna i spójna na każdym poziomie, kompletna, czyli powinna pokazywać zamierzony zakres, spójna z modelem informacyjnym i zgodna z przyjętymi konwencjami nazewniczymi, zrównoważona, co ułatwi czytanie. Diagram Związków Encji Diagram ten tworzony jest w celu dokładnego opisu potrzeb informacyjnych organizacji. Główny cel to zrozumienie struktury danych przetwarzanych w przedsiębiorstwie oraz dostarczenie modelu niezależnego od sposobu przetwarzania danych i dostępu do nich, umożliwiającego podjęcie decyzji o metodzie implementacji i współdziałaniu z istniejącymi systemami. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych), z których najpopularniejszym jest właśnie ERD. Diagram ten spotyka się w wielu różnych notacjach, do których zaliczamy m.in. notacje: Chena, Martina, Bachmana czy Bakera. Diagram ERD przedstawia: obiekty, o których informacje są istotne z punktu widzenia realizacji celów strategicznych firmy, atrybuty obiektów, związki pomiędzy obiektami. Wyodrębnione obiekty mogą być zarówno rzeczywiste jak i mogą być pojęciami abstrakcyjnymi. W diagramie ERD zasadniczą rolę odgrywają trzy pojęcia, których zrozumienie jest kluczowe dla opanowania umiejętności tworzenia tego diagramu. Są to: ENCJA, rozumiana jako rzecz lub obiekt mający dla nas znaczenie, rzeczywisty lub wyobrażony, o którym informacje muszą być znane i przechowywane, Przykłady encji ATRYBUT, który jest dowolnym opisem mającym znaczenie dla encji. Atrybut może być tekstem, liczbą, wartością logiczną lub obrazem, ZWIĄZEK, będący nazwanym, istotnym powiązaniem pomiędzy dwiema encjami. Związki przedstawiają zależności zachodzące pomiędzy modelowanymi 93
8 Dariusz OLCZYK obiektami. Każdy związek ma dwa końce, z których każdy ma przypisane następujące atrybuty: - nazwę, - liczebność, - opcjonalność. Związek jest reprezentowany za pomocą linii łączącej dwie encje. Przykład związku między encjami Oczywiście ze względu na liczebność możemy wyróżnić kilka typów związków. Oto one: Związek Jeden do Wielu (1:n) Związek Wiele do Wielu (m:n) Związek Jeden do Jeden (1:1) Zdecydowanie rzadziej stosowanymi związkami są: związek nadtyp-podtyp, związek wykluczający czyli łuk. Ciekawą sprawą jeśli chodzi o Diagram Związków Encji jest ilość powszechnie używanych notacji. Mnogość tą powiększają jeszcze bardziej liczne narzędzia 94
9 MODELOWANIE STRUKTURALNE DEFINICJE, NOTACJA, TECHNIKI I NARZĘDZIA wspomagające rysowanie ERD. Trzeba przy tym zaznaczyć, iż jedynie w przypadku dużych narzędzi klasy CASE stworzonych przez renomowane firmy informatyczne możemy mówić o określonej notacji. W większości mniejszych rozwiązań mamy do czynienia z różnego rodzaju hybrydami lub całkowicie autorskimi rozwiązaniami, których trudno jest doszukiwać się w literaturze. Wprowadza to niemały zamęt w tej kwestii i utrudnia jednoznaczność interpretacji wyników. Do najbardziej znanych notacji stosowanych w procesie tworzenia diagramów ERD zaliczamy: Notacja Chena Notacja IDEF1X Notacja Bachmana Notacja Martina (Crow s foot) Notacja Min-Max (ISO) Jean-Raymond Abriala Notacja UML 95
10 Dariusz OLCZYK Notacja Bakera Diagram Przepływu Danych Jedną z metod wykorzystywanych na etapie analizy i projektowania służących do modelowania funkcji systemu jest Diagram Przepływu Danych (ang. Data Flow Diagram DFD). Przedstawia on, w jaki sposób dane przepływają w systemie oraz opisuje procesy przetwarzające dane. Tworzenie diagramu DFD opiera się na następujących kategoriach pojęciowych: proces, przepływ danych, magazyn danych, terminator i odpowiadających im symbolach graficznych. PROCES (ang. process) oznacza transformację danych wejściowych w wynikowe i odpowiada tym składnikom systemu, które przetwarzają dane. Procesy otrzymują i przesyłają dane za pośrednictwem przepływów danych. Kojarzą się one z procedurą, której specyfikacja jest przedstawiona przy użyciu innych technik strukturalnych. Yordon DeMarco Gane-Sarson SSADM 96
11 MODELOWANIE STRUKTURALNE DEFINICJE, NOTACJA, TECHNIKI I NARZĘDZIA PRZEPŁYW DANYCH (ang. data flow) opisuje zbiór danych przepływający pomiędzy dwoma obiektami w systemie. Przedstawia się go za pomocą linii ze strzałkami określającymi kierunek przesyłania informacji. Linie są skierowane najczęściej jednostronnie. Jeśli przekazywana informacja jest zwrotna używa się kolejnych linii lub strzałek dwukierunkowych. Yordon DeMarco Gane-Sarson SSADM MAGAZYN DANYCH (ang. data store) inaczej składnica danych służy do przechowywania danych w postaci jednorodnych kolekcji. Zaistnienie magazynu danych w diagramie ma sens, gdy przechowywane dane służą do realizacji, co najmniej dwóch procesów. Charakter magazynu danych zależy od stopnia szczegółowości diagramu. Yordon DeMarco Gane-Sarson SSADM TERMINATOR (ang. terminator) obiekt zewnętrzny w stosunku do systemu reprezentujący źródła lub miejsca przeznaczenia informacji. Terminatorami są obiekty, z którymi system komunikuje się. Yordon DeMarco Gane-Sarson SSADM 97
12 Dariusz OLCZYK Podobnie jak to miało miejsce w przypadku diagramu ERD tak i tutaj mamy do czynienia z kilkoma notacjami. Sposoby reprezentacji poszczególnych elementów pokazano powyżej. Diagram kontekstowy jest specjalnym graficznym schematem przepływu danych, który definiuje zakres i granice systemu. System przedstawiony jest na diagramie jako pojedynczy proces powiązany bezpośrednio przepływami danych z terminatorami. Całość ma na celu przedstawienie powiązań systemu ze środowiskiem zewnętrznym. Następnie tworzony jest diagram systemowy ukazujący główne funkcje systemu. Każda funkcja jest przedstawiona w postaci hierarchicznej grupy diagramów niższego poziomu. Diagramy niższych poziomów to diagramy szczegółowe. Zbiór diagramów DFD dla systemu wraz z opisem elementów występujących na diagramie w słowniku danych stanowi model funkcji systemu. Jest to graficzna mapa procesów ukazująca przepływ danych miedzy procesami w systemie oraz między światem zewnętrznym a systemem. 4. PODSUMOWANIE W artykule przedstawione zostały cechy charakterystyczne oraz elementy notacji modelowania strukturalnego jako przeciwwagi modelowania obiektowego. Zaprezentowano obszary zastosowań a także główne tendencje rozwoju myśli informatycznej w tym obszarze. Niniejszy artykuł nie wyczerpuje oczywiście tematu i stanowi niejako wprowadzenie do rozważań bardziej szczegółowych zawierających opisy najlepszych praktyk, wskazówek praktycznych oraz przykładów najczęściej popełnianych błędów przy tworzeniu poszczególnych diagramów. Konkludując powyższe rozważania można stwierdzić, iż techniki modelowania strukturalnego nadal znajdują swoje obszary zastosowań i stanowią ważne uzupełnienie technik obiektowych. Natomiast co do jakości wytwarzanych diagramów przez zespoły analityków i projektantów, jak w wielu przypadkach tak i tutaj można przywołać powszechne powiedzenie, że praktyka czyni mistrza. Literatura J. Roszkowski, Analiza i projektowanie strukturalne. Wydanie III; Wydawnictwo Helion, Gliwice 2004 R. Barker, C. Longman, CASE*Method. Modelowanie funkcji i procesów, Wydawnictwo Naukowo- Techniczne, Warszawa 1996 R. Dumnicki, A. Kasprzyk, M. Kozłowski, Analiza i projektowanie obiektowe, Wydawnictwo Helion, Gliwice 1998 A. Jaszkiewicz, Inżynieria oprogramowania, Wydawnictwo Helion, Gliwice
Diagramu 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
Diagramy 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
Zagadnienia (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
Analiza 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:
Projektowanie 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
Analiza 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)
Informatyka 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
Autor: Joanna Karwowska
Autor: Joanna Karwowska W bazie danych przechowujemy tylko niektóre informacje o świecie rzeczywistym. Wybór właściwych wycinków rzeczywistości i dotyczących ich danych jest bardzo istotny od niego zależy
Projektowanie 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
Modelowanie 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
E-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
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
E-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
Ś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),
MODELOWANIE 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
1 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.....................................
Modelowanie 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)
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Diagramy obiegu dokumentów a UML w modelowaniu procesów biznesowych Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Modelowanie biznesowe jest stykiem między
Faza 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ń
Projektowanie 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
Diagramy 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,
Spis 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.
Podstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Wprowadzenie 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
Modelowanie 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
ZARZĄ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
Bazy 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
APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI.
APIO. W4 ZDARZENIA BIZNESOWE. ZALEŻNOŚCI MIĘDZY FUNKCJAMI. ELEMENTY DEFINICJI PROCESU. DIAGRAM ZALEŻNOŚCI FUNKCJI. dr inż. Grażyna Hołodnik-Janczura W8/K4 ZDARZENIA BIZNESOWE W otoczeniu badanego zakresu
Procesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Wykł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
Kurs 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
UML 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ć
Faza 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
Modelowanie 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
KARTA PRZEDMIOTU. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI Ogólne umiejętności posługiwania się komputerem
WYDZIAŁ INFORMATYKI I ZARZĄDZANIA Zał. nr 4 do ZW 33/01 KARTA PRZEDMIOTU Nazwa w języku polskim: Nazwa w języku angielskim: Kierunek studiów (jeśli dotyczy): Specjalność (jeśli dotyczy): Stopień studiów
Projektowanie 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
Bazy 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
1. 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
PRZEWODNIK 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
Systemy 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
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH
ZSE - Systemy baz danych 1 ZASADY PROJEKTOWANIA BAZ DANYCH ZSE - Systemy baz danych 2 rzeczywistość uzyskanie od użytkowników początkowych informacji i wymagań dotyczących przetwarzania danych analiza
Podstawy 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
PRZEWODNIK PO PRZEDMIOCIE WYKŁAD ĆWICZENIA LABORATORIUM PROJEKT SEMINARIUM
Politechnika Częstochowska, Wydział Zarządzania PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu Kierunek Forma studiów Poziom kwalifikacji Rok Semestr Jednostka prowadząca Osoba sporządzająca Profil Rodzaj
Analiza 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
PRZEWODNIK 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.
Inżynieria oprogramowania. Wykład 6 Analiza i specyfikowanie wymagań
Inżynieria oprogramowania Wykład 6 Analiza i specyfikowanie wymagań Proces inżynierii wymagań Feasibility Study Feasibility Report Requirements Analysis System Models Requirements Definition Definition
Analiza 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
Modelowanie i analiza systemów informatycznych
Modelowanie i analiza systemów informatycznych MBSE/SysML Wykład 11 SYSMOD Wykorzystane materiały Budapest University of Technology and Economics, Department of Measurement and InformaJon Systems: The
Strukturalne metodyki projektowania systemûw informatycznych
Strukturalne metodyki projektowania systemûw informatycznych Kalendarium 1976 ó Chen P. (Entity Relationship Model ñ ERD ) 1978 ó DeMarco T. 1979 ó Yourdon E., Constantine L. 1983 ó Jackson M. 1989 ñ Yourdon
MODELOWANIE SYSTEMÓW INFORMACYJNYCH
MODELOWANIE SYSTEMÓW INFORMACYJNYCH Wykładowca: dr inż. Grażyna Hołodnik-Janczura Instytut Organizacji i Zarządzania Politechnika Wrocławska GHJ 1 LITERATURA 1. Barker R., Longman C., CASE*Method: Modelowanie
Karta 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
Dariusz 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
Projektowanie 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
Nazwa 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:
Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
Bazy 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
Wykł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
Modelowanie diagramów klas w języku UML. Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014
Modelowanie diagramów klas w języku UML Łukasz Gorzel 244631@stud.umk.pl 7 marca 2014 Czym jest UML - Unified Modeling Language - Rodzina języków modelowania graficznego - Powstanie na przełomie lat 80
Diagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com
Diagramy klas dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com O czym będzie? Notacja Ujęcie w różnych perspektywach Prezentacja atrybutów Operacje i metody Zależności Klasy aktywne,
TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ
TECHNIKI MODELOWANIA STRUKTURY INFORMACYJNEJ 1. Diagram obiektów i związków (DOZ) 2. Szczegółowa specyfikacja obiektów, atrybutów i związków GHJ 1 Metodyki strukturalne IE (Information Engineering) Martin
Wykorzystanie 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
KATEDRA 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,
Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski
Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej
Narzędzia Informatyki w biznesie
Narzędzia Informatyki w biznesie Przedstawiony program specjalności obejmuje obszary wiedzy informatycznej (wraz z stosowanymi w nich technikami i narzędziami), które wydają się być najistotniejsze w kontekście
PRZEWODNIK PO PRZEDMIOCIE. Projektowanie procesów. Logistyka (inżynierska) niestacjonarne. I stopnia. dr Aleksandra Grabińska.
Politechnika Częstochowska, Wydział Zarządzania PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu Kierunek Forma studiów Poziom kwalifikacji Projektowanie procesów Logistyka (inżynierska) niestacjonarne I stopnia
Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych
Modelowanie przypadków użycia Jarosław Kuchta Podstawowe pojęcia Przypadek użycia jest formalnym środkiem dla przedstawienia funkcjonalności systemu informatycznego z punktu widzenia jego użytkowników.
STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe
STUDIA NIESTACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi
Baza 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
Jak zostać dobrym analitykiem? Wpisany przez RR Nie, 21 paź 2012
Analityk systemów informatycznych to zawód cieszący się w ostatnich latach rosnącą popularnością. Młodych ludzi zachęcają liczne oferty pracy, perspektywa wysokich zarobków i możliwość podnoszenia kwalifikacji.
Egzamin / 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
Podejście obiektowe - podstawowe pojęcia
Podejście obiektowe - podstawowe pojęcia Bogdan Kreczmer ZPCiR IIAiR PWr pokój 307 budynek C3 bogdan.kreczmer@pwr.wroc.pl Copyright c 2003 2008 Bogdan Kreczmer Niniejszy dokument zawiera materiały do wykładu
Diagramy czynności. Widok logiczny. Widok fizyczny
Diagramy czynności System widoków 4+1 Kruchtena Widok logiczny Widok fizyczny Widok procesu Widok przypadków użycia Widok konstrukcji Diagramy czynności są jedynym diagramem w widoku procesu modelowanego
Iteracyjno-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
Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji.
Wymiar poziomy: oś na której umieszczono instancje klasyfikatorów biorące udział w interakcji. Wymiar pionowy: oś czasu przedstawiajaca ułożone chronologicznie komunikaty Podstawowe notacje graficzne Konceptualny
INFORMATYKA 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
Paweł 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
Przepł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
Architektura 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,
STUDIA STACJONARNE I STOPNIA Przedmioty kierunkowe
STUDIA STACJONARNE I STOPNIA Przedmioty kierunkowe Technologie informacyjne Prof. dr hab. Zdzisław Szyjewski 1. Rola i zadania systemu operacyjnego 2. Zarządzanie pamięcią komputera 3. Zarządzanie danymi
Cel 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
Mariusz 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ę
Efekt kształcenia. Ma uporządkowaną, podbudowaną teoretycznie wiedzę ogólną w zakresie algorytmów i ich złożoności obliczeniowej.
Efekty dla studiów pierwszego stopnia profil ogólnoakademicki na kierunku Informatyka w języku polskim i w języku angielskim (Computer Science) na Wydziale Matematyki i Nauk Informacyjnych, gdzie: * Odniesienie-
Podstawy 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
Projektowanie 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
KARTA 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:
Wymagania 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
Baza 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
PODSTAWY 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ń
Inżynieria oprogramowania wykład VI Faza analizy Analiza strukturalna modelowanie procesów, słownik danych
Inżynieria oprogramowania wykład VI Faza analizy Analiza strukturalna modelowanie procesów, słownik danych prowadzący: dr hab. inż. Krzysztof Bartecki, prof. PO Faza analizy systemowej c.d. Wymagania Projektowanie
BAZY 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
Feature Driven Development
Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami
030 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,
Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania
Literatura Marek Kisiel-Dorohinicki doroh@agh.edu.pl Brett D. McLaughlin, Gary Pollice, David West Head First Object-Oriented Analysis and Design Martin Fowler UML Distilled ( UML w kropelce ) Grady Booch,
Podsumowanie wyników ankiety
SPRAWOZDANIE Kierunkowego Zespołu ds. Programów Kształcenia dla kierunku Informatyka dotyczące ankiet samooceny osiągnięcia przez absolwentów kierunkowych efektów kształcenia po ukończeniu studiów w roku
MODELOWANIE 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
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie. Bazy danych. Wykład 4: Model SERM. dr inż. Magdalena Krakowiak
Zachodniopomorski Uniwersytet Technologiczny w Szczecinie Bazy danych Wykład 4: Model SERM dr inż. Magdalena Krakowiak makrakowiak@wi.zut.edu.pl Słabości modelu ERD Wraz ze wzrostem złożoności obiektów
INŻYNIERIA OPROGRAMOWANIA
INSTYTUT INFORMATYKI STOSOWANEJ 2013 INŻYNIERIA OPROGRAMOWANIA Inżynieria Oprogramowania Proces ukierunkowany na wytworzenie oprogramowania Jak? Kto? Kiedy? Co? W jaki sposób? Metodyka Zespół Narzędzia
Projekt: 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
Zalety 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