RAFAŁ KASPRZYK, copyright reserved
|
|
- Błażej Socha
- 8 lat temu
- Przeglądów:
Transkrypt
1
2 DIAGRAMY PRZYPADKÓW UŻYCIA Przypadki użycia były w sposób intuicyjny stosowane w tradycyjnym projektowaniu systemów informatycznych na długo przed pojawieniem się metodyk obiektowych. Zasługą Jacobsona jest zarówno wyodrębnienie przypadków użycia jako metody projektowania, jak i stworzenie metodyki i notacji graficznej dla tego paradygmatu. Jak często bywa z powszechnie stosowanymi, lecz nie nazwanymi rzeczami, kariera przypadków użycia w literaturze z zakresu projektowania systemów informatycznych (SI) zaczęła się od wprowadzenia dla nich specjalnej nazwy, przypisaniu tej nazwie określonego znaczenia i rozpropagowanie tego pojęcia jako swego rodzaju paradygmatu projektowania SI. Przypadek użycia jest to pewna nazwana, dobrze określona interakcja pomiędzy użytkownikiem a systemem komputerowym. Przypadek użycia odwzorowuje pewną funkcjonalność systemu w taki sposób, w jaki będą ją widzieć jego przyszli użytkownicy. Jakkolwiek w tym stwierdzeniu można podejrzewać banał, rzecz tak oczywistą, że nie warto o niej mówić, okazuje się, że dla dużych systemów o wielu złożonych i wzajemnie powiązanych funkcjach tego rodzaju podejście ma ogromny sens. Pozwala ono zapomnieć o detalach technicznych (nawet abstrahować od architektury) i skoncentrować się na logice systemu. Podejście do projektowania od strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść technokratycznych, ponieważ sprzyja ono punktowi widzenia, w którym centralnym ośrodkiem zainteresowania staje się człowiek - przyszły użytkownik systemu. Jak pokazały doświadczenia wielu projektów, jedną z głównych przyczyn ich niepowodzeń było zbytnie skoncentrowanie się projektantów na detalach technicznych, z pominięciem lub brakiem dostatecznej uwagi dla interakcji pomiędzy użytkownikami, a systemem komputerowym. Reasumując przypadek użycia można definiować na wiele sposobów. Oto kilka definicji: Przypadek użycia to wycinek funkcjonalności, którą system musi realizować, aby spełnić wymagania Przypadek użycia jest zbiorem ciągów akcji wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku Przypadek użycia to zbiór scenariuszy powiązanych wspólnym celem użytkownika. Przez scenariusz rozumiany jest tu ciąg kroków opisujących interakcje między użytkownikiem, a systemem Podejście przypadków użycia ma przede wszystkim na względzie określenie wymagań funkcjonalnych na projektowany system. Celem tej metody jest: Identyfikacja wymagań funkcjonalnych o Każdy przypadek użycia powinien opisywać realizację jakiegoś celu biznesowego opisanego z punktu widzenia aktora używającego system o Zbiór przypadków użycia stanowi podstawę do umowy między klientem, a dostawcą
3 o Przypadki użycia ułatwiają zadanie ustalenia priorytetów dla wymagań funkcjonalnych Odpowiedź na pytanie, co system ma robić bez określania sposobu realizacji Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu Określenie granic systemu Ustalenie praw dostępu do zasobów Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu Przygotowanie podstaw do szczegółowej analizy i projektowania o Podstawa do identyfikacji klas i obiektów o Określenie odpowiedzialności i współpracy obiektów o Definicja przepływu komunikatów miedzy obiektami Weryfikacja poprawności i kompletności projektu Dostarczenie podstaw do sporządzenie planu testów systemu Pomiędzy przypadkami użycia można wyróżnić przynajmniej trzy podstawowe relacje: Zawieranie o Pozwala na współdzielenie fragmentu funkcjonalności pomiędzy kilkoma przypadkami użycia. Do relacji zawierania dochodzi wówczas, gdy kilka przypadków użycia ma wspólną sekwencję podobnych kroków, której nie warto wciąż kopiować z jednego przypadku użycia do drugiego. Rozszerzanie o Pozwala na warunkowe rozszerzenie funkcjonalności przypadku użycia osadzone w punkcie rozszerzenia. Rozszerzenie przypadku użycia może więc wzbogacić go o dodatkowe zachowanie, ale w takiej sytuacji podstawowy przypadek użycia musi określić pewne punkty rozszerzenia, a rozszerzający przypadek użycia może dodać nowe zachowanie tylko w tych punktach. Przypadek użycia może mieć wiele punktów rozszerzeń, a rozszerzający przypadek użycia może rozszerzać podstawowy przypadek użycia w kilku z tych punktów. Relacja rozszerzania służy do opisywania opcjonalnego przepływu zdarzeń i pozwala na minimalizację liczby zmian wprowadzanych do podstawowego przypadku użycia. Uogólnienie o Pozwala na zilustrowanie różnych wariantów realizacji tego samego przypadku użycia. W istocie jest bardzo podobne do rozszerzania, jest jednak mniej formalne. Relacji uogólnienia używa się wówczas, gdy dany przypadek użycia jest podobny do innego, ale jest nieco obszerniejszy. Specjalizowany przypadek użycia może przesłonić dowolną część podstawowego przypadku użycia, ale zawsze powinien dotyczyć osiągnięcia tego samego celu użytkownika, co podstawowy przypadek użycia. Relacja uogólnianie może być traktowana
4 jako sposób na przedstawienie szczególnej realizacji uogólnionego przypadku użycia. Diagramy przypadków użycia są bardzo proste i głównie dzięki temu tak użyteczne.
5 DIAGRAMY KLAS Diagram klas jest ściśle powiązany z projektowaniem obiektowym systemów informatycznych. Opisuje wyróżnione w systemie klasy obiektów i statyczne powiązania między nimi. Zawiera on również takie elementy jak atrybuty i operacje klas oraz ograniczenia nakładane na klasy obiektów i ich powiązania. Modelując statyczne aspekty perspektywy projektowej, diagramów klas używa się do: Modelowanie słownictwa systemu. Zadanie to polega między innymi na podejmowaniu decyzji, które abstrakcje są częścią rozważanego systemu, a które nie i jakie zobowiązania ma każda z tych abstrakcji. Modelowanie prostych kooperacji. Kooperacja jest to zestaw klas, interfejsów i innych bytów istniejących celem realizacji pewnego zespołowego zachowania wymagającego współpracy wszystkich elementów. Nie należy skupiać się nad jedną klasą, lecz nad zbiorem współpracujących ze sobą klas, by zrozumieć, o co chodzi. W tym wypadku diagramy klas wykorzystuje się do zobrazowania i określenia tego zbioru klas i związków między nimi. Modelowanie schematu logicznej bazy danych. Przez schemat rozumiany jest plan projektu koncepcyjnego bazy danych. W wielu dziedzinach zachodzi potrzeba trwałego przechowywania informacji w bazach danych. W tym wypadku diagram klas wykorzystuje się do modelowania schematów takich baz danych. Klasa jest opisem zbioru obiektów, które mają takie same: Atrybuty opisują stan o Najczęściej typy proste lub biblioteczne o Nie posiadają własnych reguł biznesowych o Ich wartości są istotne dla obiektów klasy Operacje opisują zachowanie o Usługi oferowane przez każdy obiekt klasy o Zwykle powodują zmianę stanu obiektu o Dzielą się na zapytania i polecenia Związki uogólnienie, realizacja, zależność, asocjacja, agregacja, kompozycja o Umożliwiają obrazowanie faktu, że zachowanie jednej klasy zależy od zachowania innej klasy o Powalają na unikanie antywzorów (np. BLOB ) Znaczenie Klasa realizuje jeden bądź wiele interfejsów. Interfejs definiuje zewnętrznie obserwowane zachowanie klasy lub komponentu, określając zbiór deklaracji operacji, ale nigdy sposobu implementacji.
6
7 DIAGRAMY KOMPONENTÓW Komponenty, w odróżnieniu od bytów koncepcyjnych jakimi są np. diagramy klas, są elementami oprogramowania istniejącymi w systemie komputerowym i będącymi fizyczną realizacją zamysłu projektanta oprogramowania, czyli składnikiem konkretnego systemu programowego. Należy tu uchwycić subtelną granicę rozciągłości definicji klasy w stosunku do definicji komponentu, tzn. najważniejszym wyróżnikiem odmienności tych dwóch pojęć jest to, iż klasa jest abstrakcyjnym przedstawieniem zbioru atrybutów i operacji, podczas gdy komponent jest fizyczną częścią systemu. Analizując zagadnienie projektowania realnych fragmentów oprogramowania (komponentów) można dojść do wniosku, że szczególny nacisk powinien zostać położony na możliwość wyizolowania komponentu i jego wielokrotnego użycia. Zadanie to ułatwiają dobrze zdefiniowane interfejsy, które są jedyną drogą przez którą dostępne są operacje komponentu - zupełnie jak w przypadku klas - relację tego typu nazywamy realizacją. Nie można pominąć znaczenia interfejsu jako swego rodzaju "okna na świat" dla komponentu, co warunkuje możliwości jego wymiany i wielokrotnego wykorzystania. Należy w tym miejscu dodać, że w specyfikacji UML 2.0 wyróżnione zostały dwa typy interfejsów. Jeżeli komponent udostępnia jakieś usługi w postaci interfejsu to mówimy wówczas o tzw. interfejsie dostarczanym, udostępnianym lub eksportowanym (ang. provided interface). Może jednak zajść przypadek, że komponent, aby w pełni realizować swoje usługi, potrzebuje skorzystać z usług innych komponentów, co obrazuje się za pomocą interfejsu wymaganego, importowanym (ang. required interface). Wyróżniamy 3 podstawowe rodzaje komponentów: wdrożenia - są podstawą oprogramowania wykonywalnego o COM+, JavaBeans, EJB, biblioteki DLL, pliki wykonywalne EXE,... procesu wytwórczego - komponenty będące artefaktami powstałymi w procesie wytwarzania, na ich podstawie generuje się komponenty wdrożenia o schemat logiczny bazy danych, skrypty SQL, pliki z kodem źródłowym, komponenty wykonania - tworzone jako rezultat działania systemu o wydruki, raporty, W końcu dochodzimy do definicji diagramu komponentów, który zawiera komponenty, interfejsy oraz ich wzajemne związki. Elementy te są ze sobą luźno powiązane najczęściej za pomocą zależności i realizacji.
8
9 DIAGRAMY WDROŻENIA Diagram wdrożenia, obok diagramu komponentów to jeden z dwóch rodzajów diagramów przedstawiających fizyczne aspekty systemów. Jego zadaniem jest zobrazowanie konfiguracji węzłów w czasie wykonania, na których rozmieszczone będą komponenty. Komponenty reprezentują fizyczne (programowe ang. software), wymienne części systemu, które realizują elementy logiczne, podczas gdy węzły to fizyczne (sprzętowe ang. hardware) składnik systemu na których wdrożone zostają komponenty. Najczęściej mamy do czynienia z sytuacją w której diagramy komponentów umieszczane są na diagramach wdrożenia, aby pokazać, które komponenty działają na których węzłach. Węzły dzielone są na: procesory reprezentują zasoby obliczeniowe o posiadają pewną ilość pamięci i zdolność przetwarzania, o mogą wykonywać kod komponentu urządzenia są interfejsem do świata zewnętrznego o nie mają zdolności przetwarzania (np. monitor, drukarka) Diagramy wdrożenia są szczególnie przydatne dla projektantów systemów, których sposób funkcjonowania zależy równie sileni od oprogramowaniu wchodzącym w skład systemu, jak i sprzętu na którym to oprogramowanie ma działać. Pozwalają na zobrazowanie infrastruktury wymaganej przez system. Pomiędzy węzłami występują połączenia (ang. connection), które najczęściej opatrzone są różnymi stereotypami opisującymi ich charakter. Można wyróżnić trzy zasadnicze typy systemów, przy modelowani których warto wykorzystać diagramy wdrożenia: systemy wbudowane, systemy typu klient-serwer oraz systemy rozproszone. Istotna nowością, która została wprowadzona w specyfikacji UML 2.0 jest dodanie elementu będącego specyfikacją wdrożenia. Element ten odpowiada za opis parametrów potrzebnych do wdrożenia komponentu na danym węźle, co ma na celu parametryzację relacji pomiędzy różnymi programowymi i sprzętowymi technologiami. Specyfikacja wdrożenia jest obrazowana za pomocą stereotypu <<deploymentspecyfication>> Ciekawym elementem jest również tzw. środowisko wykonania. Element ten reprezentuje wybrany rodzaj platformy i jest obrazowany za pomocą stereotypu <<ExecutionEnvironment>>
10
11 DIAGRAMY OBIEKTÓW Diagramy obiektów przedstawiają hierarchię obiektów i ich wzajemne powiązania w danej chwili. Jako że przedstawiają instancje klas, a nie same klasy - nazywane są też czasem diagramami instancji. Na diagramach obiektów umieszczamy specyfikacje instancji, a nie same instancje. Rozwiązanie takie umożliwia nie nadawanie wartości obowiązkowym atrybutom, lub też obrazowanie specyfikacji instancji klas abstrakcyjnych. Diagramy obiektów podobne są do diagramów komunikacji, jednakże te pierwsze służą do zobrazowania struktury instancji, diagramy komunikacji natomiast do pokazania ich zachowań.
12 DAIGRAMY STRUKTUR ZŁOŻONYCH Diagramy struktur złożonych służą do hierarchicznego opisywania skomplikowanych fragmentów oprogramowania. Pozwala to na zajęcie się skomplikowanym elementem i podzielenie go na części. Struktury złożone są podobne do pakietów. Aby uświadomić sobie podstawową różnicę najlepiej myśleć o pakietach jako o sposobie grupowania elementów w czasie kompilacji, podczas gdy struktury złożone grupują elementy w czasie wykonania programu. Diagramy struktury swoja notację i zakres stosowania wywodzą głównie z modeli systemów czasu rzeczywistego, gdzie stosowane jest pojęcie tzw. kapsuły, która reprezentuje wyraźnie wydzielony i hermetyczny wątek sterowania systemu. Całkowita izolacja kapsuła (w obu kierunkach) od jej otoczenia możliwa jest dzięki portom, które pełnia rolę obiektów granicznych (interfejsów). Interesujący jest fakt, że diagramy struktury mogą obrazować aspekty statyczny i dynamiczny modelowanego systemów, co stanowi o ich osobliwości. Najczęściej mamy do czynienia z przypadkiem, w którym diagramy struktury ilustrują dekompozycję wskazującą z jakich części składa się kapsuła i w jakie interfejsy jest ona zaopatrzona. Istnieje jednak druga forma diagramów struktury umożliwiająca przedstawienie komunikacji, jaka zachodzi pomiędzy wewnętrznymi elementami kapsuły. Taka forma prezentacji diagramów struktury została nazwana w UML 2.0 diagramem współpracy. Należy pamiętać, że gdy diagram struktury przyjmuje pierwszą formę to można użyć na nim portów i interfejsów. Prezentując natomiast zbiór współpracujących ze sobą elementów składowych kapsuły nie można wykorzystywać portów i interfejsów, ale należy skorzystać ze stereotypowych zależności: <<role binding>>, <<represents>>, <<occurrence>> Ponieważ struktury złożone są nowością, to trudno stwierdzić, jak przydatne okażą się w praktyce.
13
14 DIAGRAMY PAKIETÓW Pakiet jest konstrukcją pozwalającą organizować elementy modelu np. klasy, w logiczne grupy. Natomiast diagram pakietów to diagram składający się z pakietów i zależności między nimi. Pakiety z reguły tworzy się, aby: W przejrzysty sposób zobrazować zależności pomiędzy poszczególnymi elementami modelu. Efektywniej organizować kod źródłowy. Zaznaczyć podobieństwa i różnice pomiędzy poszczególnych elementów modelu. Na diagramie pakietów wszelkie elementy modelu (klasy, interfejsy, kooperacje, komponenty, ) grupowane są w pakiety i/lub podpakiety zgodnie z poziomami zawierania. Warto tworzyć tego typu diagramy dążąc do tego, aby elementy modelu połączone relacjami asocjacji, agregacji, czy to kompozycji umieszczone były w jednym pakiecie. Z reguły naturalnym jest, by w pakiecie umieszczać elementy modelu, które w jakikolwiek sposób od siebie zależą. Diagramy pakietów można także stosować w celu grupowania przypadków użycia. Ogólne zasady tworzenia diagramów pakietów są bardzo proste: Zawsze nadawaj pakietom proste, opisowe nazwy Stosuj pakiety do upraszczania struktury diagramów Stosuj stereotypy by zaznaczyć warstwy architektury programu Zależności między pakietami powinny odzwierciedlać faktyczne wewnętrzne relacje w programie Pakiety powinna charakteryzować wysoka zwartość i niskie sprzężenie.
15
16 DIAGRAMY SEKWENCJI Diagram sekwencji (przebiegu) jest jednym z diagramów interakcji. Diagramy interakcji odnoszą się do modelowania dynamicznych aspektów systemu i służy do opisu współpracy pomiędzy grupą obiektów. Na diagramach sekwencji uwzględnia się konkretne i prototypowe egzemplarze klas, interfejsów, komponentów i węzłów, a także komunikaty przekazywane między nimi. Elementy te są rozpatrywane w kontekście pewnego scenariusza ilustrującego zachowanie systemu. Diagram sekwencji główny nacisk kładzie na uwypuklenie kolejność przesyłania komunikatów w czasie. Diagramy sekwencji stosuje się, aby spojrzeć na zachowanie się kilku obiektów w ramach jednego przypadku użycia systemu. Są użyteczne do przedstawiania współpracy obiektów, ale nie umożliwiają ścisłej definicji zachowania. Reasumując diagramy sekwencji: Przedstawiają interakcje pomiędzy obiektami (w UML 2.0 tzw. uczestnikami interakcji), przy czym największy nacisk kładą na zależności czasowe. Stosowane są zawsze, gdy kolejność wywołań oraz ograniczenia czasowe są istotne Nadają się do modelowania: o Systemów czasu rzeczywistego o Przetwarzania współbieżnego o Złożonych scenariuszy Nie prezentują związków strukturalnych miedzy współdziałającymi obiektami (uczestnikami) Pozwalają na zaprezentowanie różnych typów interakcji: o Synchroniczna o Asynchroniczna o Notacja UML 2.0 wprowadziła do diagramów sekwencji szereg nowości, które bez wątpienia ułatwiają prezentację złożonych scenariuszy wybranych przypadków użycia. Częstym problemem towarzyszącym diagramom sekwencji była trudność z przedstawieniem zachowania warunkowego i pętli. Rozwiązaniem okazało się wprowadzenie ramek interakcji, które służą do wyróżnienia fragmentu diagramu sekwencji. Każda taka ramka ma operator (stereotyp interakcji), a każdej wydzielonej części ramki może towarzyszyć warunek, co pozwala na wizualizowanie różnych wariantów złożonego scenariusza. Najczęściej stosowane stereotypy interakcji: alt (alternatywa) zostaje wykonany tylko ta część ramki, której warunek jest prawdziwy.
17 opt (opcja) fragment zostaje wykonany tylko wówczas, gdy zawarty w nim warunek jest prawdziwy, czyli odpowiednik operatora alt z jednym wejściem. par (współbieżność) każda część ramki interakcji uruchamiana jest równolegle. loop (pętla) ramka interakcji może być wykonana kilka razy, a warunek określa podstawę interakcji. region (obszar krytyczny) ramka interakcji może mieć tylko jeden wątek uruchomiony w dane chwili. neg (negacja) ramka przedstawia niepoprawna interakcję. ref (referencja) ramka odwołuje się do interakcji zdefiniowanej na innym diagramie. Ramka jest rysowana tak, aby przykrywać linie czasu obiektów biorących udział w interakcji. Można zdefiniować parametry wejściowe i wartości zwracaną. sd (diagram sekwencji) używany do otaczania ramką całego diagramu sekwencji, w miarę potrzeb.
18 DIAGRAMY KOMUNIKACJI Diagram komunikacji jest jednym z diagramów interakcji. Diagramy interakcji odnoszą się do modelowania dynamicznych aspektów systemu i służy do opisu współpracy pomiędzy grupy obiektów. Na diagramach komunikacji uwzględnia się konkretne i prototypowe egzemplarze klas, interfejsów, komponentów i węzłów, a także komunikaty przekazywane między nimi. Elementy te są rozpatrywane w kontekście pewnego scenariusza ilustrującego zachowanie systemu. Diagram komunikacji kładzie nacisk na związki strukturalne między obiektami (w UML 2.0 tzw. uczestnikami) biorącymi udział w interakcji oraz komunikaty przesyłane między nimi. Jest wygodniejszy od diagramów sekwencji do przedstawienia złożonych iteracji i rozgałęzień. W swojej idei diagramy komunikacji są podobne do diagramów sekwencji. Ich głównym celem jest więc przedstawienie przepływu komunikatów pomiędzy obiektami. Diagramy komunikacji uwzględniają jednak dwa aspekty: statyczną strukturę uczestniczących obiektów, włączając związki, atrybuty i operacje (jest to nazywane kontekstem współpracy ), oraz kolejność komunikatów wymienianych pomiędzy obiektami dla realizacji konkretnego zadania. Diagram komunikacji może być rozrysowany dla pewnych typów obiektów, dla pewnych operacji lub pewnych przypadków użycia. W odróżnieniu od diagramów sekwencji wymiar czasu nie jest bezpośrednio odwzorowany i nie ma on takiego znaczenia. Natomiast odwzorowane są powiązania pomiędzy obiektami (prezentujące pewną część powiązań z diagramu klas). Diagram sekwencji i komunikacji są semantycznie równoważne tzn., że przekazują tę samą informację. Istnieje możliwość przekształcenia diagramu sekwencji w diagram komunikacji i odwrotnie bez utraty informacji.
19
20 DIAGRAMY CZYNNOŚCI Diagramy czynności to kolejny diagram służący do modelowania dynamicznych aspektów systemu. Diagramy te w zasadzie są schematami blokowymi, które przedstawiają przepływ sterowania z czynności do czynności. Obrazują one sekwencyjne bądź to równoległe/współbieżne kroki procesu. Stanowią uogólnioną wersję diagramów stanów, a ich podstawowym zadaniem nie jest analiza stanów obiektu, ale modelowanie przetwarzania (przepływu zadań). Stany diagramu czynności odpowiadają stanom wyróżnianym w trakcie przetwarzania, a nie stanom obiektów. Czynność może być interpretowana jako zadanie do wykonania przez człowieka lub komputer ale również jako odpowiedzialność, operacja czy metoda klasy, a więc diagram może być tworzony na różnych poziomach szczegółowości. Przejścia pomiędzy stanami (czynnościami) nie są związane z nadejściem zdarzenia, ale z zakończeniem przetwarzania specyficznego dla danej aktywności. Diagramy czynności możemy wykorzystać na bardzo wiele sposobów. Są szczególnie przydatne przy tworzeniu SI i to nie tyko w podejściu obiektowym. Tak więc: Umożliwiając zrozumienie procesów biznesowych Doskonale nadają się do modelowania przepływu zdań i w opisie procesów z dużą liczbą równoległych czynności Wykorzystywane są, jako wygodnym sposobem analizy przypadków użycia Dają możliwość opisu czynności warunkowych i współbieżnych o Proces warunkowy jest przedstawiany za pomocą rozgałęzienia (ang. branch) i scalenia (ang. marge) o Proces współbieżnych jest przedstawiany za pomocą rozwidlenia (ang. fork) i złączenia (ang. join) Określają sposób realizacji rozpatrywanego działania opisując podstawowe reguły porządkujące (szeregujące) czynności Pozwalają na zobrazowanie współdziałania obiektów oraz określenie obiektów odpowiedzialnych za wykonanie danej czynności na wysokim poziomie abstrakcji za pomocą tzw. torów pływackich (ang. swimlines). W celu uszczegółowienia należy stosować diagramy interakcji Mogą być stosowane do opisu algorytmów sekwencyjnych, równoległych i współbieżnych Zmiany wprowadzone w notacji UML 2.0, a dotyczące diagramów czynności sięgają bardzo daleko. Pierwszą widoczną zmianą jest umożliwienie zastosowania torów (partycji) zarówno pionowych jak i poziomych (powstaje dwuwymiarowa siatka). Pozwala to prezentować nie tylko obiekty odpowiedzialne za wykonanie danej czynności, ale grupować czynności w większe zbiory i przypisywać im zbiorcze nazwy lub miejsca realizacji. Inna nowością jest wprowadzenie możliwości zakończenia realizacji scenariusza, w dowolnym miejscu jeżeli zajdzie określony warunek. Dopracowano
21 również sposób przesyłania obiektów pomiędzy czynnościami wprowadzając pojęcie żetonu (ang. token) i wtyku (ang. pin) wykorzystywanych do przekazywania parametrów wejściowych i wyjściowych pomiędzy czynnościami. Idea ta pochodzi z sieci Petriego. Diagramy czynności wykorzystywane są do dynamicznego modelowania systemów. W szczególności stosowane są do modelowania przepływu zadań i opisu algorytmów. Mocną stroną tych diagramów jest to, że zachęcają do stosowania procesów współbieżnych tam gdzie to tylko możliwe.
22 DIAGRAMY MASZYNY STANÓW Diagramy maszyny stanów, nazywane również diagramami stanów, są znaną techniką opisu zachowania się systemu. Wykorzystywane są więc do modelowania dynamicznych aspektów systemu. W technice obiektowej diagramy te wykorzystuje się do zobrazowania możliwych stanów obiektu oraz przejść, które powodują zmianę stanu obiektu. Istotną zaletą diagramów maszyny stanów jest możliwość modelowania zachowania obiektów danej klasy w oderwaniu od reszty systemu. Są szczególnie użyteczne do modelowania historii życia obiektu. Przedstawiają reakcje obiektów na otrzymane zdarzenia. Nadaje się więc do opisu obiektów reaktywnych oraz projektowania systemów interakcyjnych. Formalnie diagram maszyny stanów jest grafem skierowanym, którego wierzchołki stanowią stany obiektu, a łuki opisują przejścia między stanami. Przejście jest odpowiedzią obiektu na jakieś zdarzenie. Akcje są związane z przejściami i traktuje się je jako procesy szybkie i nieprzerywalne (atomowe). Ze stanami związane są czynności, które mogą trwać dłużej i mogą zostać przerwane przez zdarzenie. Diagramy maszyny stanów pozwalają również na wizualizowanie tzw. stanów złożonych. Stan złożony powstaje w efekcie zagnieżdżania stanów i w związku z tym może być dokomponowany na stany bardziej proste. Dekompozycja jest rodzajem specjalizacji. Każdy z podstanów musi dziedziczyć przejścia nadstanu. Tylko jeden z podstanów może być aktywny w danym momencie. Diagramy maszyny stanów radzą sobie również w wypadku, gdy obiekt ma pewne zbiory niezależnych zachowań czyli może znajdować się w kilku stanach równocześnie (tzw. stany współbieżne). Jeśli jednak dla jednego obiektu jest klika skomplikowanych diagramów stanów współbieżnych, to dobrom praktyką jest próba rozbicia tego obiektu na kilka prostszych. Reasumując elementy diagramów stanów to: Stany mogą mieć nazwy, a identyfikowane są na trzy sposoby: o Wartości atrybutów obiektu o Czas, gdy obiekt oczekuje na nadejście jakiegoś zdarzenia event zdarzenie(a:t)/[warunek]/akcja o Czas, w którym obiekt wykonuje jakieś czynności do/czynność1/czynność2/ Zdarzenia bodźce, które mogą uruchomić przejścia pomiędzy stanami o Wolanie operacja(a:t), synchroniczne wywołanie żądania, gdzie obiekt wołający czeka na wynik o Zmiana when(wyrażenie), ciągłe czekania na spełnienie warunku o Sygnał sygnał(a:t), asynchroniczna komunikacja jednokierunkowa
23 o Czas after(czas), uzależnienie od czasu określanego bezwzględnie lub względnie Przejścia wskazują, że obiekt przejdzie z jednego stanu do drugiego, o ile zajdzie określone zdarzenie i będą spełnione warunki o zdarzenie(a:t)[warunek]/akcja przejścia zewnętrzne i wewnętrzne o [warunek]/akcja przejście automatyczne o entry/akcja1we/akcja2we/ wykonanie akcji podczas wejścia do stanu o exit/akcja1wy/akcja2wy/ wykonanie akcji podczas wyjścia ze stanu
24 DIAGRAMY PRZEGLĄDU INTERAKCJI Diagramy przeglądu interakcji są krzyżówką diagramów czynności i diagramów sekwencji i/lub komunikacji. Należy je traktować tak, jak diagramy czynności, w których czynności (aktywności) są zastąpione przez diagramy sekwencji. Istnieje możliwość stosowania dwóch rodzajów elementów interakcyjnych: prostokąty posiadające nazwę diagramu sekwencji i stanowiące jego referencję, zaznaczaną słowem kluczowym REF, które znajduje się w lewym górnym rogu diagramy sekwencji bądź komunikacji, które mogą być bezpośrednio zagnieżdżane w diagramach przeglądu interakcji Ponieważ diagramy przeglądu interakcji są nowością, to trudno stwierdzić, jak przydatne okażą się w praktyce.
25 DIAGRAMY PRZEBIEGÓW CZASOWYCH Diagram przebiegów czasowych jest nowym diagramem interakcji, w którym nacisk kładzie się na ograniczenia czasowe albo dla pojedynczego obiektu, albo, co bardziej pożyteczne dla całej grupy obiektów. Na jego pojawienie się czekali przede wszystkim projektanci systemów czasu rzeczywistego i aplikacji, których działanie jest uzależnione od współpracy z urządzeniami wejścia/wyjścia. Diagram przebiegów czasowych obrazuje zachowanie obiektu z naciskiem na dokładne określenie czasu, w którym obiekt jest poddawany jakimś zmianą lub sam wykonuje jakieś działanie. Diagramy czasowe przydają się do obrazowania ograniczeń czasowych występujących między zmianami stanów różnych obiektów. Są szczególnie przyjazne dla inżynierów zajmujących się projektowaniem urządzeń.
26 Źródła: Martin Fowler, UML w kropelce wersja 2.0, LTP, Warszawa 2005 Michał Śmiałek, Zrozumieć UML 2.0. Metody modelowania obiektowego, Helion, Gliwice
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ółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoTECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek
TECHNOLOGIE OBIEKTOWE WYKŁAD 2 Anna Mroczek 2 Diagram czynności Czym jest diagram czynności? 3 Diagram czynności (tak jak to definiuje język UML), stanowi graficzną reprezentację przepływu kontroli. 4
Bardziej szczegółowoDiagramy sekwencji. wymienianych między nimi
Diagramy sekwencji Graficzne przedstawienie interakcji pomiędzy instancjami klasyfikatorów systemu w postaci sekwencji komunikatów wymienianych między nimi Przykład diagramu sekwencji Układ diagramu wymiar
Bardziej szczegółowoSpis treúci. 1. Wprowadzenie... 13
Księgarnia PWN: W. Dąbrowski, A. Stasiak, M. Wolski - Modelowanie systemów informatycznych w języku UML 2.1 Spis treúci 1. Wprowadzenie... 13 2. Modelowanie cele i metody... 15 2.1. Przegląd rozdziału...
Bardziej szczegółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity
Bardziej szczegółowoModelowanie 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ółowoUML w Visual Studio. Michał Ciećwierz
UML w Visual Studio Michał Ciećwierz UNIFIED MODELING LANGUAGE (Zunifikowany język modelowania) Pozwala tworzyć wiele systemów (np. informatycznych) Pozwala obrazować, specyfikować, tworzyć i dokumentować
Bardziej szczegółowoArchitektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Bardziej szczegółowoUML cz. II. UML cz. II 1/38
UML cz. II UML cz. II 1/38 UML cz. II 2/38 Klasy Najważniejsze informacje o klasie: różnica pomiędzy klasą a jej instancją (obiektem) na podstawie klasy tworzone są obiekty (instancje klasy) stan obiektu
Bardziej szczegółowoPodstawy 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ółowoUML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne.
45. UML, jego struktura i przeznaczenie. Przeznaczenie UML (Unified Modeling Language jest to sposób formalnego opisu modeli reprezentujących projekty informatyczne. Pozwala obrazować, specyfikować, tworzyć
Bardziej szczegółowokoniec punkt zatrzymania przepływów sterowania na diagramie czynności
Diagramy czynności opisują dynamikę systemu, graficzne przedstawienie uszeregowania działań obrazuje strumień wykonywanych czynności z ich pomocą modeluje się: - scenariusze przypadków użycia, - procesy
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoUnified Modeling Language
Unified Modeling Language Wprowadzenie do UML Igor Gocaliński Odrobina historii Połowa lat 70-tych i koniec 80-tych to początek analizy obiektowej Wiele opracowanych metod w połowie lat 90-tych Metoda
Bardziej szczegółowoDiagramy 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ółowoWymiar 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
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH
KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków
Bardziej szczegółowoModelowanie i Programowanie Obiektowe
Modelowanie i Programowanie Obiektowe Wykład I: Wstęp 20 październik 2012 Programowanie obiektowe Metodyka wytwarzania oprogramowania Metodyka Metodyka ustandaryzowane dla wybranego obszaru podejście do
Bardziej szczegółowoUML 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ółowo12) Wadą modelu kaskadowego jest: Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 13) Wadą modelu opartego na prototypowaniu jest:
Zagadnienia obowiązujące na egzaminie z inżynierii oprogramowania: 1) Oprogramowanie to: 2) Produkty oprogramowania w inżynierii oprogramowania można podzielić na: 3) W procesie wytwarzania oprogramowania
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram czynności. Materiały dla studenta
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 4 Ćwiczenia w narzędziu CASE diagram
Bardziej szczegółowoModelowanie obiektowe - Ćw. 3.
1 Modelowanie obiektowe - Ćw. 3. Treść zajęć: Diagramy przypadków użycia. Zasady tworzenia diagramów przypadków użycia w programie Enterprise Architect. Poznane dotychczas diagramy (czyli diagramy klas)
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 7 Przeglądowe diagramy interakcji Przeglądowe diagramy interakcji wiążą
Bardziej szczegółowoMichał Adamczyk. Język UML
Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 10 Diagramy wdrożenia I Diagramy wdrożenia - stosowane do modelowania
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoŚwiat rzeczywisty i jego model
2 Świat rzeczywisty i jego model Świat rzeczywisty (dziedzina problemu) Świat obiektów (model dziedziny) Dom Samochód Osoba Modelowanie 3 Byty i obiekty Byt - element świata rzeczywistego (dziedziny problemu),
Bardziej szczegółowoPodstawy inżynierii oprogramowania
Podstawy inżynierii oprogramowania Modelowanie. Podstawy notacji UML Aleksander Lamża ZKSB Instytut Informatyki Uniwersytet Śląski w Katowicach aleksander.lamza@us.edu.pl Zawartość Czym jest UML? Wybrane
Bardziej szczegółowoRysunek 1: Przykłady graficznej prezentacji klas.
4 DIAGRAMY KLAS. 4 Diagramy klas. 4.1 Wprowadzenie. Diagram klas - w ujednoliconym języku modelowania jest to statyczny diagram strukturalny, przedstawiający strukturę systemu w modelach obiektowych przez
Bardziej szczegółowoproblem w określonym kontekście siły istotę jego rozwiązania
Wzorzec projektowy Christopher Alexander: Wzorzec to sprawdzona koncepcja, która opisuje problem powtarzający się wielokrotnie w określonym kontekście, działające na niego siły, oraz podaje istotę jego
Bardziej szczegółowoUML. dr inż. Marcin Pietroo
dr inż. Marcin Pietroo Pojęcia obiektowości obiekt klasa komunikat hermetyzacja polimorfizm dziedziczenie graficzny język wizualizacji, specyfikowania, tworzenia i dokumentowania systemów informatycznych
Bardziej szczegółowoDiagramy czynności Na podstawie UML 2.0 Tutorial
Diagramy czynności Na podstawie UML 2.0 Tutorial http://sparxsystems.com.au/resources/uml2_tutorial/ Zofia Kruczkiewicz 1 Diagramy czynności 1. Diagramy czyności UML http://sparxsystems.com.au/resources/uml2_tutorial/
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Bardziej szczegółowoTECHNOLOGIE OBIEKTOWE. Wykład 3
TECHNOLOGIE OBIEKTOWE Wykład 3 2 Diagramy stanów 3 Diagram stanu opisuje zmiany stanu obiektu, podsystemu lub systemu pod wpływem działania operacji. Jest on szczególnie przydatny, gdy zachowanie obiektu
Bardziej szczegółowoDiagramy 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
Bardziej szczegółowoProjektowanie Graficznych Interfejsów Użytkownika Robert Szmurło
Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło LATO 2007 Projektowanie Graficznych Interfejsów Użytkownika 1 UCD - User Centered Design 1) User Centered Design Projekt Skoncentrowany
Bardziej szczegółowoNIFIED M L ODELLING ANGUAGE. Diagramy czynności
U M L NIFIED ODELLING ANGUAGE Diagramy czynności 1 Czym jest diagram czynności? Jeden z pięciu rodzajów diagramów UML służących do modelowania dynamicznych aspektów systemu. Przedstawia przepływ sterowania
Bardziej szczegółowoWykład I. Wprowadzenie do baz danych
Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles
Bardziej szczegółowoUML - zarys 2007/2008
UML - zarys 2007/2008 Modelowanie Jest ważne przy tworzeniu wysokiej jakości oprogramowania Jest przydatne przy tworzeniu i analizie działania organizacji Modelujemy aby: Zrozumieć system Określić pożądaną
Bardziej szczegółowoInż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ółowoZnaleziony - jeżeli nadawca nie jest znany w obrębie danego fragmentu Utracony - jeżeli odbiorca komunikatu nie jest znany w obrębie danego fragmentu
czas Dynamiczne aspekty systemu Interakcja - zachowanie polegające na wymianie komunikatów między obiektami w pewnym (ustalonym) otoczeniu, w pewnym (ściśle określonym) celu Komunikat - specyfikacja łączności
Bardziej szczegółowoZalety projektowania obiektowego
Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy
Bardziej szczegółowoAnaliza 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
Bardziej szczegółowoINŻYNIERIA OPROGRAMOWANIA. laboratorium
INŻYNIERIA OPROGRAMOWANIA laboratorium UML 1/4 UML (Unified Modeling Language) - język modelowania obiektowego systemów i procesów [Wikipedia] Spojrzenie na system z różnych perspektyw dzięki zastosowaniu
Bardziej szczegółowoPodstawy języka UML2 w realnych projektach
Kod szkolenia: Tytuł szkolenia: UML2/RP Podstawy języka UML2 w realnych projektach Dni: 3 Opis: Adresaci Szkolenia: Szkolenie adresowane jest do osób, które chciałby poznać podstawy UML2. Przede wszystkim
Bardziej szczegółowoCel wykładu. Literatura. Wyższa Szkoła Menedżerska w Legnicy. Modelowanie wymagań Wykład 2
Wyższa Szkoła Menedżerska w Legnicy Systemy informatyczne w przedsiębiorstwach Zarządzanie, ZIP, sem. 6 (JG) Modelowanie wymagań Wykład 2 Grzegorz Bazydło Cel wykładu Celem wykładu jest przekazanie wiedzy
Bardziej szczegółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 5 Diagram sekwencji - wprowadzenie I Diagram sekwencji (ang. sequence
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Ćwiczenie 5 Ćwiczenia w narzędziu CASE diagram przypadków uŝycia Materiały dla nauczyciela Projekt
Bardziej szczegółowoProcesowa 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Źródło: S. Wrycza, B. Marcinkowski, K. Wyrzykowski Język UML 2.0 w modelowaniu systemów informatycznych Helion DIAGRAMY INTERAKCJI
DIAGRAMY INTERAKCJI DIAGRAMY STEROWANIA INTERAKCJĄ Diagramy sterowania interakcją dokumentują logiczne związki między fragmentami interakcji. Podstawowe kategorie pojęciowe diagramów sterowania interakcją
Bardziej szczegółowoWykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych
Wykorzystanie standardów serii ISO 19100 oraz OGC dla potrzeb budowy infrastruktury danych przestrzennych dr inż. Adam Iwaniak Infrastruktura Danych Przestrzennych w Polsce i Europie Seminarium, AR Wrocław
Bardziej szczegółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoModelowanie obiektowe
Modelowanie obiektowe ZPO 2018/2019 Dr inż. W. Cichalewski Materiały wykonane przez W. Tylman Diagramy klas Diagramy klas Zawiera informacje o statycznych związkach między elementami (klasami) Są ściśle
Bardziej szczegółowoBaza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego
PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga
Bardziej szczegółowoFaza analizy (modelowania) Faza projektowania
Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań
Bardziej szczegółowoOprogramowanie o wysokiej jakości to oprogramowanie spełniające następujące kryteria:
1. Podaj definicję inżynierii oprogramowania. Inżynieria oprogramowania to wiedza techniczna, dotycząca wszystkich faz cyklu życia oprogramowania, której celem jest uzyskanie wysokiej jakości produktu
Bardziej szczegółowoInżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji
Inżynieria oprogramowania Jarosław Kuchta Modelowanie interakcji Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania. Interakcja
Bardziej szczegółowoPodrozdziały te powinny zawierać informacje istotne z punktu widzenia przyjętego celu pracy
Uwaga: 1. Praca powinna być napisana z użyciem formy bezosobowej np. wykonano. Nazwa rozdziału Zawartość Liczba stron 1. Wstęp Rozdział ten powinien zawierać zarys najważniejszych elementów pracy Krótki
Bardziej szczegółowoUML cz. I. UML cz. I 1/1
UML cz. I UML cz. I 1/1 UML cz. I 2/1 UML - Unified Modeling Language ujednolicony można go współdzielić z wieloma pracownikami modelowania służy do opisu projektowanego modelu język posiada opisaną strukturę
Bardziej szczegółowoPodstawy modelowania programów Kod przedmiotu
Podstawy modelowania programów - opis przedmiotu Informacje ogólne Nazwa przedmiotu Podstawy modelowania programów Kod przedmiotu 11.3-WI-INFP-PMP Wydział Kierunek Wydział Informatyki, Elektrotechniki
Bardziej szczegółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoZofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1
Charakterystyka oprogramowania obiektowego 1. Definicja systemu informatycznego 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wymagania 4. Problemy z podejściem nieobiektowym
Bardziej szczegółowoModelowanie i analiza systemów informatycznych
Katolicki Uniwersytet Lubelski Jana Pawła II Wydział Matematyki, Informatyki i Architektury Krajobrazu Modelowanie i analiza systemów informatycznych ćwiczenia informacja wstępna dr Viktor Melnyk, prof.
Bardziej szczegółowoPaweł Kurzawa, Delfina Kongo
Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management
Bardziej szczegółowoProjektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD
Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe
Bardziej szczegółowoDiagram klas UML jest statycznym diagramem, przedstawiającym strukturę aplikacji bądź systemu w paradygmacie programowania obiektowego.
Umiejętność czytania oraz tworzenia diagramów klas UML jest podstawą w przypadku zawodu programisty. Z takimi diagramami będziesz spotykał się w przeciągu całej swojej kariery. Diagramy klas UML są zawsze
Bardziej szczegółowoDiagram sekwencji. Komunikaty mogą być opisane w sposób sformalizowany. poprz / [warunek] *[iter] nr sekw : wynik := operacja(lista)
Diagram sekwencji Komunikaty mogą być opisane w sposób sformalizowany poprz / [warunek] *[iter] nr sekw : wynik := operacja(lista) Przykłady komunikatów przesuń(1,2) wyn1:=przesuń(5,5), *[1..5]: wyn1 :=
Bardziej szczegółowoModelowanie. 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ółowomiejsca przejścia, łuki i żetony
Sieci Petriego Sieć Petriego Formalny model procesów umożliwiający ich weryfikację Główne konstruktory: miejsca, przejścia, łuki i żetony Opis graficzny i matematyczny Formalna semantyka umożliwia pogłębioną
Bardziej szczegółowoDiagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Diagramy interakcji Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania.
Bardziej szczegółowoKARTA PRZEDMIOTU. 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA. 2) Kod przedmiotu: ROZ-L3-20
Z1-PU7 WYDANIE N2 Strona: 1 z 5 (pieczęć wydziału) KARTA PRZEDMIOTU 1) Nazwa przedmiotu: INŻYNIERIA SYSTEMÓW I ANALIZA SYSTEMOWA 3) Karta przedmiotu ważna od roku akademickiego: 2014/2015 2) Kod przedmiotu:
Bardziej szczegółowoSpis 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ółowoDiagramy 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ółowoDIAGRAMY 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ółowoDiagramy związków encji. Laboratorium. Akademia Morska w Gdyni
Akademia Morska w Gdyni Gdynia 2004 1. Podstawowe definicje Baza danych to uporządkowany zbiór danych umożliwiający łatwe przeszukiwanie i aktualizację. System zarządzania bazą danych (DBMS) to oprogramowanie
Bardziej szczegółowoMiASI. 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ółowoWOJSKOWA AKADEMIA TECHNICZNA
WOJSKOWA AKADEMIA TECHNICZNA LABORATORIUM ANALIZA I MODELOWANIE SYSTEMÓW INFORMATYCZNYCH Stopień, imię i nazwisko prowadzącego Stopień, imię i nazwisko słuchacza Grupa szkoleniowa mgr inż. Łukasz Laszko
Bardziej szczegółowoProjektowanie logiki aplikacji
Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie logiki aplikacji Zagadnienia Rozproszone przetwarzanie obiektowe (DOC) Model klas w projektowaniu logiki aplikacji Klasy encyjne a klasy
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla nauczyciela
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram
Bardziej szczegółowoSieci Petriego. Sieć Petriego
Sieci Petriego Sieć Petriego Formalny model procesów umożliwiający ich weryfikację Główne konstruktory: miejsca, przejścia, łuki i żetony Opis graficzny i matematyczny Formalna semantyka umożliwia pogłębioną
Bardziej szczegółowoZagadnienia Semestr IV Inżynieria Oprogramowania WSZiB
Zagadnienia Wprowadzenie pojęcia obiektu i klasy obiektu Reprezentacja systemu jako zbioru wzajemnie oddziaływujących obiektów Poszczególne etapy procesu tworzenia obiektowego projektu systemu Charakterystyka
Bardziej szczegółowoXQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery
http://xqtav.sourceforge.net XQTav - reprezentacja diagramów przepływu prac w formacie SCUFL przy pomocy XQuery dr hab. Jerzy Tyszkiewicz dr Andrzej Kierzek mgr Jacek Sroka Grzegorz Kaczor praca mgr pod
Bardziej szczegółowoLaboratorium modelowania oprogramowania w języku UML. Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram sekwencji. Materiały dla studentów
Zakład Elektrotechniki Teoretycznej i Informatyki Stosowanej Wydział Elektryczny, Politechnika Warszawska Laboratorium modelowania oprogramowania w języku UML Ćwiczenie 3 Ćwiczenia w narzędziu CASE diagram
Bardziej szczegółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoPodstawy 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ółowoDiagramy 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ółowoPodstawy Programowania Obiektowego
Podstawy Programowania Obiektowego Wprowadzenie do programowania obiektowego. Pojęcie struktury i klasy. Spotkanie 03 Dr inż. Dariusz JĘDRZEJCZYK Tematyka wykładu Idea programowania obiektowego Definicja
Bardziej szczegółowoProgramowanie 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ółowoSystemy Czasu Rzeczywistego. dr inż. Piotr Szwed C3, pok
Systemy Czasu Rzeczywistego dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl Cele przedmiotu Podczas laboratorium zrealizowany zostanie projekt symulujący działanie
Bardziej szczegółowoPrzypadki użycia (use cases) Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady
Po co są przypadki użycia? Próby definicji Podstawowe pojęcia Notacje Relacje Dokumentacja Kroki metody Przykłady Po co są przypadki użycia? Gdy projektujemy jakikolwiek system, najważniejszym etapem jest!!!
Bardziej szczegółowoInżynieria Programowania - Projektowanie architektoniczne
Inżynieria Programowania - Projektowanie architektoniczne Katedra Informatyki, Politechnika Świętokrzyska w Kielcach Kielce, 22 października 2016 1 2 3 4 5 Architektury charakterystyczne dla różnych dziedzin
Bardziej szczegółowoPodejś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
Bardziej szczegółowoModel przypadków użycia - rola diagramów aktywności Część 2 Wykładowca Dr inż. Zofia Kruczkiewicz
Model przypadków użycia - rola diagramów aktywności Część 2 Wykładowca Dr inż. Zofia Kruczkiewicz Zofia Kruczkiewicz Wyklad_INP002017_4 1 Diagramy czynności I. Diagramy czynności UML II. Przykład diagramów
Bardziej szczegółowo