Kategoria modelowania

Wielkość: px
Rozpocząć pokaz od strony:

Download "Kategoria modelowania"

Transkrypt

1 7 Diagramy implementacyjne oraz diagramy pakietów 7.1 Wstęp Diagramy implementacyjne słuŝą do ilustracji dwóch aspektów implementacji systemu informatycznego: struktury kodu i konfiguracji elementów czasu wykonania. Diagramy pakietów z kolei, są budowane przede wszystkim dla duŝych projektów, tworzonych przez duŝą grupę współpracujących osób, projektów składających się z wielu jednostek funkcjonalnych, ze złoŝonymi zaleŝnościami pomiędzy tymi jednostkami. Zadaniem pakietów jest grupowanie elementów danego (jednego) modelu, wraz z występującymi pomiędzy tymi elementami relacjami. Istnieje co najmniej kilka powodów, dla których warto jest uŝywać diagramów pakietów: W celu ukrycia mniej istotnych elementów modelu (podobnie jak zilustrowano to w przykładzie o subkolaboracji umieszczonym w wykładzie dotyczącym diagramów interakcji). Dla ułatwienia podziału pracy między członkami zespołu czy teŝ róŝnymi zespołami. Dla ułatwienia procesu zarządzania budową produktu informatycznego. 7.2 Diagramy implementacyjne UML definiuje dwa rodzaje diagramów implementacyjnych: Diagramy komponentów ilustrują strukturę kodu projektowanego systemu poprzez specyfikowanie implementacji elementów projektu (np. klas czy podsystemów) za pomocą komponentów i ich interfejsów, oraz wskazanie zaleŝności występujących pomiędzy komponentami. Celem identyfikacji komponentów jest budowa systemów o odpowiednio wysokiej jakości, wypełniających poŝądane potrzeby biznesowe i budowanych szybko raczej poprzez składanie z gotowych części niŝ poprzez wypracowywanie kaŝdego elementu samodzielnie. Taki sposób pracy jest korzystny dla budowy np. rodziny aplikacji: niektóre komponenty opłaca się opracować samodzielnie, a niektóre warto odszukać wśród gotowych, istniejących juŝ w organizacji czy na rynku i ewentualnie zaadaptować do aktualnych potrzeb. Diagramy wdroŝeniowe pokazują konfigurację systemu czasu wykonania, czyli rozmieszczenie komponentów i obiektów na węzłach. Węzły modelują obliczeniowe zasoby czasu wykonania. Taka konfiguracja moŝe być zarówno statyczna, jak i dynamiczna: komponenty i obiekty mogą migrować między węzłami w czasie wykonania. Omówienie diagramów implementacyjnych rozpoczniemy od diagramów komponentów Diagramy komponentów Komponent stanowi nietrywialną, dobrze wyizolowaną z kontekstu jednostkę implementacji, spójną ze względu na wypełniane funkcje (wysoka kohezja, słabe sprzęŝenia) i posiadającą dobrze zdefiniowany interfejs; z załoŝenia, komponent nadaje się do wielokrotnego uŝycia. Prawidłowo skonstruowany komponent korzysta z innych komponentów wyłącznie za pośrednictwem ich interfejsów, co z załoŝenia ułatwia przyszłe modyfikacje. MoŜna wyróŝnić kilka rodzajów komponentów: komponenty z perspektywy jednego projektu, komponenty z perspektywy całości rozwoju oprogramowania w danej organizacji oraz komponenty biznesowe (np. do obsługi zamówień, sprzedaŝy, itp.). Kategorie modelowania, wykorzystywane przy konstruowaniu diagramów komponentów w UML 2.*, przedstawiono w Tab. 1.

2 Kategoria modelowania Notacja komponent interfejs udostępniający interfejs pozyskujący port Port złoŝony zaleŝność realizacja «realize» Konektor delegowany «delegate» Konektor składany Tab. 1 Kategorie modelowania dla diagramu komponentów w UML 2.* Komponenty mogą być opatrywane stereotypami. Przykładowe stereotypy to: podsystem (ang. subsystem), program wykonywalny (ang. executable), biblioteka (ang. library) i baza danych/tabela bazy danych (ang. table). Przykładowe diagramy komponentów przedstawiają Rys. 1 i Rys. 2.

3 cod Ticket reservation system component named interface Ticket reservation IReservations dependency User interface Repertoire updating unnamed interface Rys. 1 Przykładowy diagram komponentów (1) Diagramy komponentów pokazują zaleŝności pomiędzy komponentami oprogramowania. Komponenty mogą istnieć w róŝnym czasie: niektóre z nich w czasie kompilacji (komponenty kodu źródłowego), niektóre w czasie konsolidacji (komponenty kodu binarnego), zaś niektóre tylko w czasie wykonania (komponenty kodu wykonywalnego). Diagram komponentów jest przedstawiany w postaci grafu skierowanego, gdzie węzłami są komponenty, a łuki w postaci strzałek z przerywaną linią modelują zaleŝności występujące pomiędzy klientami i dostawcami pewnej informacji. Bezpośrednia specyfikacja klientów i dostawców informacji ma duŝe znaczenie dla przeprowadzania modyfikacji elementów systemu: zmiany wprowadzane do elementu modelującego dostawcę pewnej informacji mogą skutkować koniecznością wprowadzania zmian do elementów modelujących jej klienta.

4 cod SHOP IOrder «delegate» IOrder «component» Orders IPerson IPerson «component» Clients IProduct IProduct ball&socket IAccount «delegate» «component» Products IAccount Rys. 2 Przykładowy diagram komponentów (2) Zbiór komponentów składających się na kod systemu moŝe być opisany na dwa sposoby: Poprzez utworzenie listy komponentów wraz ze specyfikacją ich zaleŝności jest to tzw. biblioteka komponentów. W tym przypadku bardzo pomocne jest nazywanie interfejsów. Poprzez diagram komponentów ilustrujący sieć ich wzajemnych zaleŝności. Diagram komponentów pokazuje takŝe, za realizację jakiego interfejsu jest odpowiedzialny kaŝdy z komponentów Przykład z kancelarią prawniczą Na Rys. 3 zaprezentowano diagram komponentów skonstruowany w oparciu o tekst specyfikujący wymagania dla systemu wspierajacego pracę kancelarii prawniczej (rozdział 2, podrozdział 2.10).

5 cod Law office People handling User interface Cases handling Rys. 3 Diagram komponentów dla systemu wspierającego pracę kancelarii prawniczej Diagramy wdroŝeniowe Diagramy wdroŝeniowe przedstawiają konfigurację następujących elementów czasu wykonania: komponentów sprzętowych, czyli fizycznych jednostek posiadających pamięć, a często równieŝ moc obliczeniową; komponentów oprogramowania (kod wykonywalny); obiektów związanych z komponentami. Diagram wdroŝeniowy jest grafem, gdzie wierzchołki, zwane tu węzłami, połączone są liniami odwzorowującymi połączenia komunikacyjne komponentów sprzętowych (Rys. 4). Węzły, podobnie jak połączenia komunikacyjne, mogą być opatrzone stereotypami, np.: «CPU», «pamięć». Węzły przechowują obiekty i wystąpienia komponentów; węzły mogą brać udział w związkach generalizacji. dd Ticket reservation system communication channel :Server :Laptop :Ticket reservation IReservations :User interface node Rys. 4 Przykładowy diagram wdroŝeniowy

6 W UML istnieje moŝliwość zastąpienia symboli standardowych symbolami specjalnymi, które mogą znacząco ułatwiać percepcję diagramów (Rys. 5). Main server Corporate Ethernet Internet Accounting server Web Client Local branch Ethernet Windows-based PC Windows-based PC Rys. 5 Diagram wdroŝeniowy z wykorzystaniem specjalnych symboli 7.3 Diagramy pakietów Pakiety grupują elementy danego (jednego) modelu wraz z występującymi pomiędzy tymi elementami relacjami. Elementy, wchodzące w skład pakietu, to tzw. elementy wysokiego poziomu, jak np.: klasy i ich związki, maszyny stanów, grafy przypadków uŝycia, itp. To, co jest zawarte w elementach wysokiego poziomu, np. atrybuty, operacje, wnętrza stanów zagnieŝdŝonych, linie Ŝycia, komunikaty, itp., z reguły nie pojawia się jako bezpośrednia zawartość pakietów. Pakiet zazwyczaj nie posiada swojego interfejsu (oprócz specjalnego rodzaju pakietu zwanego podsystemem patrz podpunkt omawiający specjalne rodzaje pakietów 7.3.3) a zaleŝności występujące pomiędzy pakietami wynikają z relacji między ich elementami składowymi. ZaleŜności są przedstawiane na diagramach pakietów w postaci strzałek z przerywaną linią i mogą być opatrywane stereotypami. Relacje między elementami, opisywane pośrednio przez zaleŝności, mogą być róŝnego rodzaju, ale tego typu informacja zazwyczaj nie jest przenoszona przez diagramy pakietów dzięki specyfikacji zaleŝności uwidaczniany jest jedynie fakt występowania relacji, a nie jej rodzaj, np. fakt istnienia asocjacji między dwiema klasami umieszczonymi w dwóch róŝnych pakietach. Bezpośrednie pokazywanie relacji pomiędzy elementami zawartymi w róŝnych pakietach nie jest zabronione, zaleca się raczej jedynie podkreślanie faktu ich występowania. Dla diagramów pakietów obowiązuje taka sama zasada abstrakcji, jak wszystkich poprzednio omawianych rodzajów diagramów: szczegóły nigdy nie powinny utrudniać rozumienia całości. Pakiety mogą być zagnieŝdŝane oraz mogą brać udział w związkach dziedziczenia, co jest zaznaczane analogicznie jak na diagramach klas. Dany model zazwyczaj opisywany jest przez wiele pakietów. Definicja kaŝdego elementu wchodzącego w skład modelu moŝe znajdować się tylko w jednym z pakietów opisujących model. Podział modelu na pakiety jest arbitralny, ale u jego podstaw powinny leŝeć racjonalne przesłanki, np. wspólna funkcjonalność, silne skojarzenia, itp. Kategorie modelowania, wykorzystywane przy konstruowaniu diagramów pakietów w UML 2.*, przedstawiono w Tab. 2. Jak widać, pakiet jest przedstawiany w postaci duŝego prostokąta z małym prostokątem, zwanym etykietą, umieszczonym w lewym górnym rogu. JeŜeli zawartość pakietu nie jest pokazana, wówczas nazwa pakietu jest wpisana do większego prostokąta; w przeciwnym przypadku nazwa pakietu jest umieszczana w etykiecie. Kategoria modelowania Notacja

7 pakiet zaleŝność zagnieŝdŝanie + Tab. 2 Kategorie modelowania dla diagramów pakietów w UML 2.* Rys. 6 przedstawia róŝne sposoby prezentowania zagnieŝdŝania pakietów. Package A Package A Package B1 Package B2 Package B1 Package B2 Package B3 Package B4 Package B3 Package B4 Package A + Package B1 Package B2 Package B3 Package B4 Rys. 6 RóŜne sposoby prezentowania zagnieŝdŝania pakietów Odwołania między pakietami Pakiet (klient), który odwołuje się do elementu w innym pakiecie (dostawcy informacji), moŝe wykorzystać pakiet zawierający ten element, uŝywając zaleŝności typu «import» albo «access» (będących rodzajami zaleŝności typu «usage»). Główną cechą róŝniącą oba rodzaje zaleŝności jest odmienny sposób traktowania nazw elementów.

8 Nazwy z pakietów zaimportowanych za pomocą zaleŝności typu «import» są dodawane do przestrzeni nazw pakietu importującego. Na przykład na diagramie z Rys. 7 nazwy z pakietu Q są dodawane do przestrzeni nazw pakietu P, co oznacza, Ŝe elementy z P traktują nazwy z Q tak samo jak nazwy z P (uwaga: moŝe tutaj wystąpić konflikt nazw). Class notion P Q A X:E «import» E Rys. 7 Ilustracja zaleŝności typu «import» Dla zaleŝności typu «access» nazwa, do której następuje odwołanie, musi być poprzedzona nazwą pakietu, w którym jest zdefiniowana. Na Rys. 8 pokazano, Ŝe atrybut X w klasie A zawartej w pakiecie P będzie wystąpieniem klasy E, której definicja została umieszczona w pakiecie Q. Nazwa klasy E została poprzedzona nazwą pakietu Q, co ma zapobiec wystąpieniu konfliktu nazw. P Q A X:Q::E «access» E Rys. 8 Ilustracja zaleŝności typu «access» Reguły widoczności Pakiet widzi wszystkie zewnętrzne dla niego pakiety poprzez pakiet, wewnątrz którego jest zagnieŝdŝony; innymi słowy, zagnieŝdŝony pakiet widzi wszystko to, co widzi pakiet, który go zawiera. Specjalne symbole + (publiczny), (prywatny) oraz # (chroniony) są uŝywane na oznaczenie widoczności elementu zawartego w pakiecie na zewnątrz pakietu. Zasady widoczności dla elementów zawartych w pakietach są następujące: Element zdefiniowany w danym pakiecie jest widoczny dla innych elementów tego pakietu. Jeśli element jest widoczny w pakiecie A, to jest widoczny we wszystkich pakietach, które są w A zagnieŝdŝone. Jeśli pakiet B jest powiązany zaleŝnością z pakietem A, to wtedy wszystkie elementy o widoczności publicznej w A są widoczne w B. Jeśli pakiet B dziedziczy z pakietu A, to wtedy wszystkie elementy w A o widoczności publicznej lub chronionej są widoczne w B. ZaleŜności nie są przechodnie, tzn. jeśli A jest połączone zaleŝnością z B, a B z C, to nie znaczy, Ŝe A jest połączone zaleŝnością z C. ZaleŜności nie są teŝ symetryczne. Ponadto, UML określa następujące reguły widoczności dla elementów klas w pakietach: Elementy zawarte wewnątrz klasy, np. atrybuty, operacje czy klasy zagnieŝdŝone są widoczne (dostępne dla innych klas) wewnątrz pakietu, jeśli widoczność tych elementów jest publiczna. W przypadku dziedziczenia, podklasa widzi elementy o widoczności publicznej i chronionej. Cała zawartość klasy jest widoczna wewnątrz klasy.

9 Rys. 9 stanowi ilustrację powyŝszych reguł. Pakiet A jest powiązany zaleŝnością typu «access» z pakietem B; zaleŝność odwrotna nie występuje. Klasa U w pakiecie B o widoczności publicznej jest dostępna dla klas X i Y w pakiecie A. Klasa V, jako klasa o widoczności prywatnej, nie jest dostępna dla klas z pakietu A. Klasy U i V nie mają dostępu do Ŝadnej klasy w pakiecie A pomimo publicznej widoczności klasy X (brak odpowiedniej zaleŝności pakiet B nie ma dostępu do pakietu A). Klasy X i Y, podobnie jak U i V, jako klasy zdefiniowane w tym samym pakiecie widzą nawzajem swoje publiczne elementy. A B +X -Y «access» +U -V Rys. 9 Ilustracja reguł widoczności dla pakietów Z kolei Rys. 10 pokazuje sposób, w jaki moŝna uczynić diagram bardziej czytelnym prowadząc zaleŝność od wewnętrznej granicy pakietu; zaleŝność ta oznacza, Ŝe wszystkie elementy zawarte w pakiecie A odwołują się do publicznych elementów pakietu C. Podobny sposób upraszczania diagramów polegający na zmniejszeniu liczby elementów bez utraty informacji był juŝ prezentowany dla diagramów stanów przy opisie stanów złoŝonych. A A +X «access» +X «access» C C B +K B +K -L -L «access» Rys. 10 Wykorzystanie zaleŝności poprowadzonej od wewnętrznej granicy pakietu Specjalne rodzaje pakietów UML wyróŝnia następujące specjalne rodzaje pakietów: «fasada» (ang. «facade») zawiera wyłącznie odwołania do elementów zdefiniowanych w innych pakietach. «model» stanowi abstrakcję systemu widzianą z pewnej perspektywy. Zwykle zawiera drzewo pakietów. Model moŝe zawierać relewantne elementy z otoczenia systemu, np. aktorów. Elementy z róŝnych modeli nie oddziaływują bezpośrednio na siebie, ale często stanowią róŝne reprezentacje tego samego bytu, róŝniące się na przykład ilością detali, co moŝe wymuszać potrzebę łączenia ich zaleŝnością typu «trace» czy «refinement». «podsystem» (ang. «subsystem») reprezentuje pewien spójny, logiczny, wyizolowany z kontekstu fragment systemu oraz posiada dobrze wyspecyfikowany zbiór interfejsów do interakcji z otoczeniem. Podsystem podzielony jest na dwie części: specyfikacyjną i realizacyjną. Część specyfikacyjna zawiera

10 opis interakcji z otoczeniem, z reguły za pomocą przypadków uŝycia. Część realizacyjna, posługując się kolaboracjami, podaje sposoby realizacji przypadków specyfikowanych w pierwszej części opisu podsystemu. Podsystemy mogą być zbudowane z innych podsystemów, przy czym podsystemy najniŝszego poziomu muszą zawierać elementy modelu. Podsystem stanowi zgrupowanie elementów modelu logicznego, podczas gdy komponent jest zgrupowaniem elementów modelu implementacyjnego. W wielu przypadkach podsystemy są implementowane jako komponenty, co upraszcza transformację modelu logicznego w implementacyjny i przez to jest powszechnie stosowanym podejściem Przykład z kancelarią prawniczą Na Rys. 11 zaprezentowano diagram pakietów skonstruowany w oparciu o tekst specyfikujący wymagania dla systemu wspierajacego pracę kancelarii prawniczej (rozdział 2, podrozdział 2.10). pd Law office People handling Cases handling User interface Rys. 11 Diagram pakietów dla systemu wspierającego pracę kancelarii prawniczej 7.4 Podsumowanie Konstruowanie diagramów implementacji jest uŝyteczne zarówno ze względu na ponowne uŝycie, jak i ze względu na moŝliwość uzyskania za ich pomocą odpowiednich parametrów wydajnościowych projektowanego systemu. Z kolei stosowanie pakietów ułatwia zarządzanie przechowywaniem, konfiguracjami oraz modyfikowaniem elementów systemu dobrze przeprowadzony podział na pakiety moŝe znacząco ułatwić zarządzanie procesem budowy produktu programistycznego. Problematykę diagramów pakietów moŝna podsumować następująco: Pakiety stanowią zgrupowanie elementów modelu. Są środkiem ogólnego przeznaczenia wykorzystywanym do budowy struktur hierarchicznych. KaŜdy element modelu, który nie jest zawarty wewnątrz innego elementu modelu, musi być zdefiniowany wewnątrz dokładnie jednej przestrzeni nazw (ang. home package). Oprócz elementów modelu pakiet moŝe takŝe zawierać inne pakiety (poprzez zagnieŝdŝanie). Pakiety mogą brać udział w związkach dziedziczenia. WyróŜnia się pakiety specjalnego rodzaju, m.in. «fasada», «model» oraz «podsystem».

11 W praktyce, podsystemy są implementowane jako komponenty, co upraszcza transformację modelu logicznego w model implementacyjny. 7.5 Przykładowe pytania i problemy do rozwiązania 1. Krótko scharakteryzuj cel budowy diagramów implementacyjnych. 2. Wymień i omów rodzaje diagramów implementacyjnych. 3. Zdefiniuj pojęcia: komponent, wystąpienie komponentu, interfejs, port, zaleŝność, węzeł. 4. Kiedy, w jakich sytuacjach i w jakim celu wykorzystywane są diagramy pakietów? 5. Podaj notację UML dla pakietu w oparciu o prosty przykładowy diagram. 6. Jakie rodzaje związków mogą występować między pakietami? 7. Wymień i krótko omów specjalne rodzaje pakietów. 8. Co oznacza pojęcie: home package? 9. Jaka zaleŝność występuje pomiędzy pojęciami: podsystem i komponent? Na jakim etapie cyklu Ŝyciowego produktu informatycznego funkcjonuje kaŝde z tych pojęć? 10. W oparciu o tekst specyfikujący wymagania dla systemu wspierającego pracę wypoŝyczalni płyt dvd (rozdział 2, podrozdział 2.12), skonstruuj diagram pakietów oraz diagram komponentów.

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 Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,

Bardziej szczegółowo

Komputerowe Systemy Przemysłowe: Modelowanie - UML. Arkadiusz Banasik arkadiusz.banasik@polsl.pl

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ółowo

Rysunek 1: Przykłady graficznej prezentacji klas.

Rysunek 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ółowo

UML w Visual Studio. Michał Ciećwierz

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ć

Bardziej szczegółowo

Język UML w modelowaniu systemów informatycznych

Ję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ółowo

Michał Adamczyk. Język UML

Michał 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ółowo

Analiza i projektowanie aplikacji Java

Analiza i projektowanie aplikacji Java Analiza i projektowanie aplikacji Java Modele analityczne a projektowe Modele analityczne (konceptualne) pokazują dziedzinę problemu. Modele projektowe (fizyczne) pokazują system informatyczny. Utrzymanie

Bardziej szczegółowo

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 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,

Bardziej szczegółowo

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig

Modelowanie. Wykład 1: Wprowadzenie do Modelowania i języka UML. Anna Kulig Modelowanie Obiektowe Wykład 1: Wprowadzenie do Modelowania i języka UML Anna Kulig Wprowadzenie do modelowania Zasady Pojęcia Wprowadzenie do języka UML Plan wykładu Model jest uproszczeniem rzeczywistości.

Bardziej szczegółowo

DIAGRAMY IMPLEMENTACYJNE

DIAGRAMY IMPLEMENTACYJNE DIAGRAMY IMPLEMENTACYJNE Maciej Patan Strukturalne diagramy implementacyjne Służą pokazaniu implementacji modelu, włączając w to strukturę kodu źródłowego oraz implementację środowiska wykonania. Typy:

Bardziej szczegółowo

Podstawy programowania III WYKŁAD 4

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.

Bardziej szczegółowo

Pakiety i interfejsy. Tomasz Borzyszkowski

Pakiety i interfejsy. Tomasz Borzyszkowski Pakiety i interfejsy Tomasz Borzyszkowski Pakiety podstawy W dotychczasowych przykładach nazwy klas musiały pochodzić z jednej przestrzeni nazw, tj. być niepowtarzalne tak, by nie doprowadzić do kolizji

Bardziej szczegółowo

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 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

Bardziej szczegółowo

Podstawy języka UML UML

Podstawy języka UML UML Podstawy języka UML UML Plan prezentacji Wprowadzenie do modelowania Wprowadzenie do języka UML Diagram klas Diagram pakietów Diagram przypadków użycia Diagram czynności Terminologia Terminologia Aplikacja

Bardziej szczegółowo

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 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

Bardziej szczegółowo

Komunikacja i wymiana danych

Komunikacja i wymiana danych Budowa i oprogramowanie komputerowych systemów sterowania Wykład 10 Komunikacja i wymiana danych Metody wymiany danych Lokalne Pliki txt, csv, xls, xml Biblioteki LIB / DLL DDE, FastDDE OLE, COM, ActiveX

Bardziej szczegółowo

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu

Inżynieria wymagań. Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia. Część 5 Definicja systemu Inżynieria wymagań Wykład 3 Zarządzanie wymaganiami w oparciu o przypadki użycia Część 5 Definicja systemu Opracowane w oparciu o materiały IBM (kurs REQ480: Mastering Requirements Management with Use

Bardziej szczegółowo

Inżynieria oprogramowania

Inżynieria oprogramowania Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów

Bardziej szczegółowo

Model przestrzenny Diagramu Obiegu Dokumentów. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Model przestrzenny Diagramu Obiegu Dokumentów. Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Model przestrzenny Diagramu Obiegu Dokumentów Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Sposoby weryfikacji architektury oprogramowania: - badanie prototypu

Bardziej szczegółowo

Spis treúci. 1. Wprowadzenie... 13

Spis 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ółowo

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Szczególne problemy projektowania aplikacji internetowych. Jarosław Kuchta Projektowanie Aplikacji Internetowych Szczególne problemy projektowania aplikacji Jarosław Kuchta Miejsce projektowania w cyklu wytwarzania aplikacji SWS Analiza systemowa Analiza statyczna Analiza funkcjonalna Analiza dynamiczna Analiza behawioralna

Bardziej szczegółowo

Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML

Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML VIII Konferencja PLOUG Koœcielisko PaŸdziernik 2002 Modelowanie systemów w architekturze J2EE z wykorzystaniem notacji UML Piotr Wilk Premium Technology Sp. z o.o. PWilk@PremiumTechnology.pl Modelowanie

Bardziej szczegółowo

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu.

Tutorial prowadzi przez kolejne etapy tworzenia projektu począwszy od zdefiniowania przypadków użycia, a skończywszy na konfiguracji i uruchomieniu. AGH, EAIE, Informatyka Winda - tutorial Systemy czasu rzeczywistego Mirosław Jedynak, Adam Łączyński Spis treści 1 Wstęp... 2 2 Przypadki użycia (Use Case)... 2 3 Diagramy modelu (Object Model Diagram)...

Bardziej szczegółowo

Diagramy klas. WYKŁAD Piotr Ciskowski

Diagramy klas. WYKŁAD Piotr Ciskowski Diagramy klas WYKŁAD Piotr Ciskowski przedstawienie statyki systemu graficzne przedstawienie statycznych, deklaratywnych elementów dziedziny przedmiotowej oraz związków między nimi obiekty byt, egzemplarz

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Laboratorium z przedmiotu Programowanie obiektowe - zestaw 02 Cel zajęć. Celem zajęć jest zapoznanie z praktycznymi aspektami projektowania oraz implementacji klas i obiektów z wykorzystaniem dziedziczenia.

Bardziej szczegółowo

Fazy analizy (modelowania) oraz projektowania FAZA ANALIZY:

Fazy 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ółowo

Język UML w modelowaniu systemów informatycznych

Ję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 6 Diagramy komunikacji Diagram komunikacji (ang. communication diagram),

Bardziej szczegółowo

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania...

Spis treúci. Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników. Wstęp... 11. Podziękowania... Księgarnia PWN: Robert A. Maksimchuk, Eric J. Naiburg - UML dla zwykłych śmiertelników Spis treúci Wstęp... 11 Podziękowania... 13 O autorach... 15 Robert A. Maksimchuk... 15 Eric J. Naiburg... 15 Przedmowa...

Bardziej szczegółowo

Bazy danych i usługi sieciowe

Bazy danych i usługi sieciowe Bazy danych i usługi sieciowe Modelowanie związków encji Paweł Daniluk Wydział Fizyki Jesień 2014 P. Daniluk (Wydział Fizyki) BDiUS w. II Jesień 2014 1 / 28 Modelowanie Modelowanie polega na odwzorowaniu

Bardziej szczegółowo

Język programowania. Andrzej Bobyk http://www.alfabeta.lublin.pl. www.alfabeta.lublin.pl/jp/

Język programowania. Andrzej Bobyk http://www.alfabeta.lublin.pl. www.alfabeta.lublin.pl/jp/ Język programowania Andrzej Bobyk http://www.alfabeta.lublin.pl www.alfabeta.lublin.pl/jp/ Literatura K. Reisdorph: Delphi 6 dla każdego. Helion, Gliwice 2001 A. Grażyński, Z. Zarzycki: Delphi 7 dla każdego.

Bardziej szczegółowo

UML. zastosowanie i projektowanie w języku UML

UML. zastosowanie i projektowanie w języku UML UML zastosowanie i projektowanie w języku UML Plan Czym jest UML Diagramy przypadków użycia Diagramy sekwencji Diagramy klas Diagramy stanów Przykładowe programy Visual Studio a UML Czym jest UML UML jest

Bardziej szczegółowo

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 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ółowo

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA

PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.4 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA WYMAGANIAMI PROJEKT WERSJA numer wersji

Bardziej szczegółowo

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie

Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie Projekt dotyczy stworzenia zintegrowanego, modularnego systemu informatycznego wspomagającego zarządzanie pracownikami i projektami w firmie informatycznej. Zadaniem systemu jest rejestracja i przechowywanie

Bardziej szczegółowo

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela

Laboratorium modelowania oprogramowania w języku UML. Ćwiczenie 1 Wprowadzenie do narzędzia CASE. Materiały dla nauczyciela Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 1 Wprowadzenie do narzędzia CASE

Bardziej szczegółowo

Zakres wykładu. Podstawy InŜynierii Oprogramowania

Zakres wykładu. Podstawy InŜynierii Oprogramowania Zakres wykładu Pojęcia podstawowe InŜynierii Oprogramowania Proces wytwarzania oprogramowania Artefakty procesu wytwarzania i ich modele Jakość oprogramowania Literatura: [1] Sacha K., InŜynieria oprogramowania,

Bardziej szczegółowo

Analiza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32

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:

Bardziej szczegółowo

MODELOWANIE OBIEKTOWE

MODELOWANIE 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ółowo

DIAGRAM KLAS. Kamila Vestergaard. materiał dydaktyczny

DIAGRAM KLAS. Kamila Vestergaard. materiał dydaktyczny DIAGRAM KLAS Kamila Vestergaard materiał dydaktyczny DEFINICJA D I A G R A M K L A S Diagram klas pokazuje wzajemne powiązania pomiędzy klasami, które tworzą jakiś system. Zawarte są w nim informacje dotyczące

Bardziej szczegółowo

Modelowanie i Programowanie Obiektowe

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

Bardziej szczegółowo

Wykład 7 Metodyki wytwarzania oprogramowania internetowego (2) Wykładowca: dr inż. Mariusz Trzaska

Wykład 7 Metodyki wytwarzania oprogramowania internetowego (2) Wykładowca: dr inż. Mariusz Trzaska Wykład 7 Metodyki wytwarzania oprogramowania internetowego (2) Wykładowca: dr inż. Mariusz Trzaska Zagadnienia Wprowadzenie MDD Model Analityczny Projektowy Przykład Podsumowanie Wykorzystano materiały

Bardziej szczegółowo

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe.

Warstwa integracji. wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. Warstwa integracji wg. D.Alur, J.Crupi, D. Malks, Core J2EE. Wzorce projektowe. 1. Ukrycie logiki dostępu do danych w osobnej warstwie 2. Oddzielenie mechanizmów trwałości od modelu obiektowego Pięciowarstwowy

Bardziej szczegółowo

KARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20

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:

Bardziej szczegółowo

Wykład 1 Inżynieria Oprogramowania

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

Bardziej szczegółowo

Cel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2

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

Bardziej szczegółowo

Kontrola spójności modeli UML za pomocą modelu. Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

Kontrola spójności modeli UML za pomocą modelu. Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Kontrola spójności modeli UML za pomocą modelu przestrzennego DOD Stanisław Jerzy Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska Wprowadzenie Obecne metody kontroli spójności modeli

Bardziej szczegółowo

2. Podstawy programu Microsoft Access

2. Podstawy programu Microsoft Access 8 Wprowadzenie do projektowania baz danych 2. Podstawy programu Microsoft Access Baza danych utworzona w programie Microsoft Access składa się z wielu obiektów róŝnych typów. MoŜna podzielić je na dwie

Bardziej szczegółowo

Wydział Elektroniki Politechniki Wrocławskiej. Kierunek: Informatyka Specjalność: InŜynieria Systemów Informatycznych

Wydział Elektroniki Politechniki Wrocławskiej. Kierunek: Informatyka Specjalność: InŜynieria Systemów Informatycznych Wydział Elektroniki Politechniki Wrocławskiej Kierunek: Informatyka Specjalność: InŜynieria Systemów Informatycznych Projekt z przedmiotu Komputerowe Systemy Zarządzania (INE3608) pt. System. Opracowanie:

Bardziej szczegółowo

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT <NAZWA PROJEKTU> WERSJA <NUMER WERSJI DOKUMENTU> Załącznik nr 4.6 do Umowy nr 35-ILGW-253-.../20.. z dnia... MINISTERSTWO FINANSÓW DEPARTAMENT INFORMATYKI PLAN ZARZĄDZANIA KONFIGURACJĄ OPROGRAMOWANIA PROJEKT WERSJA

Bardziej szczegółowo

Modelowanie danych, projektowanie systemu informatycznego

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

Bardziej szczegółowo

Zasady organizacji projektów informatycznych

Zasady 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ółowo

Testy poziom po poziomie

Testy poziom po poziomie poziom po poziomie Prowadzący: Tomasz Mielnik Eliza Słonińska Agenda 1. Modele prowadzenia projektów 2. V-Model 3. Poziomy testów 4. Typy testów 5. Zadanie 1 Modele prowadzenia projektów Wodospadowy (ang.

Bardziej szczegółowo

Zintegrowany model struktury

Zintegrowany model struktury Zintegrowany model struktury W tej części użyjemy diagramu bloków wewnętrznych aby opisać statyczny (nie behawioralny) widok interfejsów wszystkich podsystemów i sposób, w jaki te interfejsy łączą się

Bardziej szczegółowo

Spis treści. spis treści wygenerowany automatycznie

Spis treści. spis treści wygenerowany automatycznie Spis treści Rozdział 2.Wymagania edytorskie 2 2.1. Wymagania ogólne 2 2.2. Tytuły rozdziałów i podrozdziałów 2 2.3. Rysunki, tabele i wzory 3 2.3.1. Rysunki 3 2.3.2. Tabele 4 2.3.3. Wzory 4 2.4. Odsyłacze

Bardziej szczegółowo

Diagramy przypadków użycia

Diagramy przypadków użycia Instytut Informatyki Uniwersytetu Śląskiego 10 października 2010 Spis treści 1 Wprowadzenie do UML 2 3 4 5 6 Diagramy UML Język UML definiuje następujący zestaw diagramów: diagram przypadków użycia - służy

Bardziej szczegółowo

Programowanie Urządzeń Mobilnych. Część II: Android. Wykład 2

Programowanie Urządzeń Mobilnych. Część II: Android. Wykład 2 Programowanie Urządzeń Mobilnych Część II: Android Wykład 2 1 Aplikacje w systemie Android Aplikacje tworzone są w języku Java: Skompilowane pliki programów ( dex ) wraz z plikami danych umieszczane w

Bardziej szczegółowo

Język JAVA podstawy. Wykład 4, część 1. Jacek Rumiński. Politechnika Gdańska, Inżynieria Biomedyczna

Język JAVA podstawy. Wykład 4, część 1. Jacek Rumiński. Politechnika Gdańska, Inżynieria Biomedyczna Język JAVA podstawy Wykład 4, część 1 1 Język JAVA podstawy Plan wykładu: 1. Podstawy modelowania obiektowego 2. Konstruktory 3. Dziedziczenie, związki pomiędzy klasami, UML 4. Polimorfizm 5. Klasy abstrakcyjne

Bardziej szczegółowo

Laboratorium 6 DIAGRAM KLAS (Class Diagram)

Laboratorium 6 DIAGRAM KLAS (Class Diagram) Laboratorium 6 DIAGRAM KLAS (Class Diagram) Opisuje strukturę programu (a także zależności między nimi), co znajduje odzwierciedlenie w kodzie. Charakteryzuje zależności pomiędzy składnikami systemu: klasami,

Bardziej szczegółowo

Internetowy moduł prezentacji ofert pracy do wykorzystania na stronie WWW lub panelu elektronicznym. Wstęp

Internetowy moduł prezentacji ofert pracy do wykorzystania na stronie WWW lub panelu elektronicznym. Wstęp Internetowy moduł prezentacji ofert pracy do wykorzystania na stronie WWW lub panelu elektronicznym. Wstęp Prezentujemy Państwu propozycję modułu aplikacji internetowej słuŝącej do prezentacji ofert pracy

Bardziej szczegółowo

Paweł Kurzawa, Delfina Kongo

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

Bardziej szczegółowo

Technologia informacyjna

Technologia informacyjna Technologia informacyjna Pracownia nr 9 (studia stacjonarne) - 05.12.2008 - Rok akademicki 2008/2009 2/16 Bazy danych - Plan zajęć Podstawowe pojęcia: baza danych, system zarządzania bazą danych tabela,

Bardziej szczegółowo

Bazy danych. wprowadzenie teoretyczne. Piotr Prekurat 1

Bazy danych. wprowadzenie teoretyczne. Piotr Prekurat 1 Bazy danych wprowadzenie teoretyczne Piotr Prekurat 1 Baza danych Jest to zbiór danych lub jakichkolwiek innych materiałów i elementów zgromadzonych według określonej systematyki lub metody. Zatem jest

Bardziej szczegółowo

UML cz. I. UML cz. I 1/1

UML 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ółowo

Podstawy języka UML UML

Podstawy języka UML UML Podstawy języka UML UML Plan szkolenia Plan szkolenia Godzina (czas) 10:20 11:20 (60 min) 11:20 11:40 (20 min) 11:40 13:10 (90 min) 13:10 13:30 (20 min) 13:30 15:00 (90 min) Temat Wprowadzenie do UML (Definicja,

Bardziej szczegółowo

Informatyzacja przedsiębiorstw WYKŁAD

Informatyzacja przedsiębiorstw WYKŁAD Informatyzacja przedsiębiorstw WYKŁAD dr inż. Piotr Zabawa IBM/Rational Certified Consultant pzabawa@pk.edu.pl wersja 0.1.0 07.10.2010 Wykład 1 Modelowanie procesów biznesowych Przypomnienie rodzajów narzędzi

Bardziej szczegółowo

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski

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

Bardziej szczegółowo

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

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

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych

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

Bardziej szczegółowo

PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ. Opis działania raportów w ClearQuest

PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ. Opis działania raportów w ClearQuest PROJEKT CZĘŚCIOWO FINANSOWANY PRZEZ UNIĘ EUROPEJSKĄ Opis działania raportów w ClearQuest Historia zmian Data Wersja Opis Autor 2008.08.26 1.0 Utworzenie dokumentu. Wersja bazowa dokumentu. 2009.12.11 1.1

Bardziej szczegółowo

Modelowanie przypadków użycia. Jarosław Kuchta Projektowanie Aplikacji Internetowych

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.

Bardziej szczegółowo

Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp

Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp Internetowy moduł prezentacji WIZYT KLIENTA PUP do wykorzystania np. na stronie WWW. Wstęp Prezentujemy Państwu propozycję modułu aplikacji internetowej słuŝącej do prezentacji zaplanowanych wizyt klienta

Bardziej szczegółowo

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) 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ółowo

Sieci VPN SSL czy IPSec?

Sieci VPN SSL czy IPSec? Sieci VPN SSL czy IPSec? Powody zastosowania sieci VPN: Geograficzne rozproszenie oraz duŝa mobilność pracowników i klientów przedsiębiorstw i instytucji, Konieczność przesyłania przez Internet danych

Bardziej szczegółowo

KURS ACCESS 2003 Wiadomości wstępne

KURS ACCESS 2003 Wiadomości wstępne KURS ACCESS 2003 Wiadomości wstępne Biorąc c udział w kursie uczestnik zapozna się z tematyką baz danych i systemu zarządzania bazami danych jakim jest program Microsoft Access 2003. W trakcie kursu naleŝy

Bardziej szczegółowo

Transformacja modelu ER do modelu relacyjnego

Transformacja modelu ER do modelu relacyjnego Transformacja modelu ER do modelu relacyjnego Wykład przygotował: Robert Wrembel BD wykład 4 (1) 1 Plan wykładu Transformacja encji Transformacja związków Transformacja hierarchii encji BD wykład 4 (2)

Bardziej szczegółowo

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 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ółowo

Dynamiczny przydział pamięci w języku C. Dynamiczne struktury danych. dr inż. Jarosław Forenc. Metoda 1 (wektor N M-elementowy)

Dynamiczny przydział pamięci w języku C. Dynamiczne struktury danych. dr inż. Jarosław Forenc. Metoda 1 (wektor N M-elementowy) Rok akademicki 2012/2013, Wykład nr 2 2/25 Plan wykładu nr 2 Informatyka 2 Politechnika Białostocka - Wydział Elektryczny Elektrotechnika, semestr III, studia niestacjonarne I stopnia Rok akademicki 2012/2013

Bardziej szczegółowo

Zintegrowany System Zarządzania Biblioteką SOWA2/MARC21 OBSŁUGA CZASOPISM

Zintegrowany System Zarządzania Biblioteką SOWA2/MARC21 OBSŁUGA CZASOPISM Zintegrowany System Zarządzania Biblioteką SOWA2/MARC21 OBSŁUGA CZASOPISM Poznań 2011 Spis treści 1. Wstęp...3 2. Tworzenie informacji o zasobach czasopisma...4 3. Rekord karty wpływu...5 4. Tworzenie

Bardziej szczegółowo

Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa tel: 22 667 17 04, faks: 22 667 17 33

Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa tel: 22 667 17 04, faks: 22 667 17 33 Zakład Ubezpieczeń Społecznych Departament Zamówień Publicznych ul. Szamocka 3, 5, 01-748 Warszawa tel: 22 667 17 04, faks: 22 667 17 33 993200/370/IN-402/2012 Warszawa, dnia 22.05.2012 r. Informacja dla

Bardziej szczegółowo

UML cz. III. UML cz. III 1/36

UML cz. III. UML cz. III 1/36 UML cz. III UML cz. III 1/36 UML cz. III 2/36 Diagram współpracy Diagramy współpracy: prezentują obiekty współdziałające ze sobą opisują rolę obiektów w scenariuszu mogą prezentować wzorce projektowe UML

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

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

Bardziej szczegółowo

Identyfikacja i modelowanie struktur i procesów biologicznych

Identyfikacja i modelowanie struktur i procesów biologicznych Identyfikacja i modelowanie struktur i procesów biologicznych Laboratorium 2: Wprowadzenie do UML-a. mgr inż. Urszula Smyczyńska AGH Akademia Górniczo-Hutnicza 1. Cel zajęć Celem zajęć jest zapoznanie

Bardziej szczegółowo

Przykładowa implementacja

Przykładowa implementacja Wzorce projektowe, cz. 10 Facade Fasada służy do ujednolicenia dostępu do złożonego systemu poprzez udostępnienie uproszczonego i uporządkowanego interfejsu programistycznego. Fasada zwykle implementowana

Bardziej szczegółowo

Zmiany. Initial Step krok inicjujący sekwenser

Zmiany. Initial Step krok inicjujący sekwenser Zmiany Initial Step krok inicjujący sekwenser W ferworze walki czasem usuniemy krok inicjujący (po rozpoczęciu FB z GRAPH jest on standardowo oznaczony S1). Skutkuje to tym, że wszystko wygląda dobrze,

Bardziej szczegółowo

Diagram maszyny stanowej - POJĘCIA

Diagram maszyny stanowej - POJĘCIA Diagram maszyny stanowej - POJĘCIA Stan : sytuacja w cyklu życia bytu (obiektu, PU, podsystemu, aktora, operacji itp), kiedy spełnia on pewne warunki, realizuje pewną czynność lub czeka na pewne zdarzenie.

Bardziej szczegółowo

UPEDU: Analiza i projektowanie (ang. analysis and design discipline)

UPEDU: Analiza i projektowanie (ang. analysis and design discipline) Wydział Informatyki PB Analogia do powstawania kryształu Inżynieria oprogramowania II Wykład 7: UPEDU: Analiza i projektowanie (ang. analysis and design discipline) Marek Krętowski e-mail: mkret@wi.pb.edu.pl

Bardziej szczegółowo

Projektowanie oprogramowania

Projektowanie oprogramowania Wrocław, 27.09.2010 1. Warunki wstępne Projektowanie oprogramowania Warunkiem uczestnictwa w zajęciach jest zaliczenie przedmiotu: Podstawy inżynierii oprogramowania (ćwiczenia) Zajęcia składają się z

Bardziej szczegółowo

POLITECHNIKA OPOLSKA

POLITECHNIKA OPOLSKA POLITECHNIKA OPOLSKA WYDZIAŁ MECHANICZNY Katedra Technologii Maszyn i Automatyzacji Produkcji Laboratorium Podstaw Inżynierii Jakości Ćwiczenie nr 2 Temat: Schemat blokowy (algorytm) procesu selekcji wymiarowej

Bardziej szczegółowo

Projektowanie systemu sprzedaŝy ubezpieczeń dla T. U. Generali zgodnie z metodyką User-Centered Design

Projektowanie systemu sprzedaŝy ubezpieczeń dla T. U. Generali zgodnie z metodyką User-Centered Design Case Study Projektowanie systemu sprzedaŝy ubezpieczeń dla T. U. Generali zgodnie z metodyką User-Centered Design Zadanie Naszym zadaniem było zaprojektowanie interfejsu aplikacji do sprzedaŝy ubezpieczeń

Bardziej szczegółowo

System zarządzania bazą danych SZBD (ang. DBMS -Database Management System)

System zarządzania bazą danych SZBD (ang. DBMS -Database Management System) Podstawowe pojęcia Baza danych Baza danych jest logicznie spójnym zbiorem danych posiadających określone znaczenie. Precyzyjniej będzie jednak powiedzieć, Ŝe baza danych jest informatycznym odwzorowaniem

Bardziej szczegółowo

Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50

Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50 Koncepcja systemu informatycznego realizującego w środowisku Oracle Spatial proces generalizacji modelu BDOT10 do postaci BDOT50 Architektura systemu Architektura systemu System udostępnia dwa kanały dostępu,

Bardziej szczegółowo

Fazy przetwarzania zapytania zapytanie SQL. Optymalizacja zapytań. Klasyfikacja technik optymalizacji zapytań. Proces optymalizacji zapytań.

Fazy przetwarzania zapytania zapytanie SQL. Optymalizacja zapytań. Klasyfikacja technik optymalizacji zapytań. Proces optymalizacji zapytań. 1 Fazy przetwarzania zapytanie SQL 2 Optymalizacja zapytań część I dekompozycja optymalizacja generacja kodu wyraŝenie algebry relacji plan wykonania kod katalog systemowy statystyki bazy danych wykonanie

Bardziej szczegółowo

Dr Katarzyna Grzesiak-Koped

Dr 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ółowo

PRZEWODNIK PO PRZEDMIOCIE

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

Bardziej szczegółowo

Diagramy czynności. sekwencyjnych i współbieŝnych. pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów

Diagramy czynności. sekwencyjnych i współbieŝnych. pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów Diagramy czynności Graficzne przedstawienie sekwencyjnych i współbieŝnych przepływów sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów Zastosowanie w modelowaniu scenariuszy

Bardziej szczegółowo

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia 2010. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska

MiASI. Modelowanie systemów biznesowych. Piotr Fulmański. 7 stycznia 2010. Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska MiASI Modelowanie systemów biznesowych Piotr Fulmański Wydział Matematyki i Informatyki, Uniwersytet Łódzki, Polska 7 stycznia 2010 Spis treści 1 Czym jest system biznesowy? Po co model bizensowy? Czym

Bardziej szczegółowo

Wydział Elektryczny. Katedra Automatyki i Elektroniki. Instrukcja. do ćwiczeń laboratoryjnych z przedmiotu: SYSTEMY CYFROWE 1.

Wydział Elektryczny. Katedra Automatyki i Elektroniki. Instrukcja. do ćwiczeń laboratoryjnych z przedmiotu: SYSTEMY CYFROWE 1. Politechnika Białostocka Wydział Elektryczny Katedra Automatyki i Elektroniki Instrukcja do ćwiczeń laboratoryjnych z przedmiotu: SYSTEMY CYFROWE 1 PAMIĘCI SZEREGOWE EEPROM Ćwiczenie 3 Opracował: dr inŝ.

Bardziej szczegółowo

Projektowanie zorientowane na uŝytkownika

Projektowanie zorientowane na uŝytkownika Uniwersytet Jagielloński Interfejsy graficzne Wykład 2 Projektowanie zorientowane na uŝytkownika Barbara Strug 2011 Hall of shame Hall of shame Model wodospad Feedback Problem z modelem waterfall Projektowanie

Bardziej szczegółowo

POLITECHNIKA OPOLSKA

POLITECHNIKA OPOLSKA POLITECHNIKA OPOLSKA WYDZIAŁ MECHANICZNY Katedra Technologii Maszyn i Automatyzacji Produkcji Laboratorium Podstaw Inżynierii Jakości Ćwiczenie nr 2 Temat: Schemat blokowy (algorytm) procesu selekcji wymiarowej

Bardziej szczegółowo