Cel i zakres trzeciego wykładu

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

Download "Cel i zakres trzeciego wykładu"

Transkrypt

1 Cel i zakres trzeciego wykładu Tytuł: Diagramy sekwencji, pakietów, stanu i wdrożenia w perspektywie implementacyjnej Cel wykładu: Zaprezentować sposób przygotowania wyżej wymienionych diagramów w perspektywie implementacyjnej. Zakres wykładu 1) Zasady tworzenia diagramów sekwencji 2) Zasady tworzenia diagramów pakietów 3) Sposoby implementacji diagramów stanów 4) Zasady tworzenia diagramów wdrożeń Projektowanie systemów informatycznych, wykład 3 1 1

2 Diagram sekwencji przedstawia sposób wymiany komunikatów pomiędzy obiektami z zachowaniem ich kolejności. Pomijają natomiast całkowicie aspekt dostępu i operacji na danych, związany z komunikacją. Uczestnikami diagramów sekwencji są obiekty, opisane nazwą obiektu i jego klasą, które wymieniają między sobą komunikaty. Diagramy sekwencji Projektowanie systemów informatycznych, wykład 3 2 Diagramy interakcji to modele opisujące, jak współpracują ze sobą grupy obiektów. UML definiuje kilka rodzajów diagramów interakcji, z których najczęściej używanym jest diagram sekwencji. Zwykle diagram sekwencji przedstawia zachowanie się systemu dotyczące jednego przypadku użycia. Diagram pokazuje kilka przykładowych obiektów i komunikaty przez nie wymieniane w ramach przypadku użycia. Pierwszy przykładowy diagram sekwencji będzie dotyczył następującego prostego scenariusza: załóżmy że mamy zamówienie i zamierzamy wywołać na nim polecenie obliczające wartość tego zamówienia. W tym celu najpierw należy wybrać wszystkie pozycje zamówienia i określić ich ceny na podstawie reguł cenowych ustalonych dla zamawianych produktów. Następnie zamówienie musi obliczyć ogólną zniżkę, obliczaną na podstawie reguł ustalonych dla danego klienta. Na rysunku został przedstawiony diagram sekwencji ukazujący jedną z możliwych implementacji tego scenariusza. Diagramy sekwencji ilustrują interakcje wymieniając każdego jej uczestnika razem z pionową linią oznaczającą czas, w którym ten uczestnik bierze udział w interakcji. Kolejno pojawiające się komunikaty są uporządkowane od góry do dołu. Widać wyraźnie, że instancja klasy Zamówienie wysyła komunikaty pobierzllość i pobierzprodukt do klasy Pozycje Zamówienia. Można też dostrzec, jak jest zapisywana metoda wywoływana przez klasę Zamówienie na sobie samej, oraz to, że inna wywoływana w ten sposób metoda wysyła komunikat pobierzinformacjeozniżkach do instancji klasy Klient. Diagram jednak nie przedstawia wszystkiego bardzo dobrze. Sekwencja komunikatów pobierzllość, pobierzprodukt, pobierzcennik oraz obliczcenę jest wysyłana dla każdej pozycji zamówienia, natomiast obliczzniżkę jest wywoływana tylko raz. Nie można na podstawie tego diagramu stwierdzić, że tak jest, chociaż można wprowadzić dodatkową notację, która to umożliwi. Na przedstawionych diagramach nadano uczestnikom nazwy składające się tylko z nazwy obiektu. Pełniejsza składnia ma postać nazwaobiektu : nazwakiasy, gdzie zarówno nazwa obiektu, jak i nazwa klasy może być pominięta. Jeśli opuści się nazwę obiektu, to trzeba pozostawić dwukropek. Na każdej linii czasu są umieszczane słupki aktywności reprezentujące chwile, w których uczestnik bierze udział w interakcji. Oznaczają one obecność jednej z metod uczestnika na stosie wywołań. Słupki aktywności są w UML-u opcjonalne. Odpowiednie nazewnictwo często pomaga w powiązaniu uczestników na diagramie. Wywołanie komunikatu pobierzprodukt zwraca Produkt mający tę samą nazwę, a więc będący tym samym uczestnikiem, co Produkt, do którego jest wysyłany komunikat pobierzcennik. Proszę zwrócić uwagę na to, że użyto strzałki zwrotnej tylko w tym wywołaniu tak aby podkreślić istnienie odpowiedniości. Można używać strzałek zwrotnych we wszystkich wywołaniach, ale lepiej stosować je tylko tam, gdzie niosą one dodatkową informację. Pierwszy komunikat nie ma wysyłającego go uczestnika i nadchodzi z nieokreślonego źródła. Jest nazywany komunikatem wykrytym. 2

3 Inna wersja diagramu sekwencji z pop. slajdu Projektowanie systemów informatycznych, wykład 3 3 Inne podejście do tego samego scenariusza zostało pokazane na aktualnym slajdzie. Podstawowy problem pozostaje ten sam, ale sposób, w który uczestnicy współpracują ze sobą w celu jego rozwiązania, jest zupełnie inny. Zamówienie prosi każdą PozycjęZamówienia, aby obliczyła swoją własną Cenę. PozycjaZamówienia następnie zleca wykonanie obliczenia ceny wszystkim instancjom klasy produkt, które znajdują się na liście zamówienia. Tu warto zwrócić uwagę na to, jak jest przedstawione przekazywanie parametru. Podobnie, aby obliczyć wysokość zniżki, Zamówienie wywołuje metodę na Kliencie. Klient do wykonania swojego zadania potrzebuje dodatkowej informacji z Zamówienia, więc wywołuje na Zamówieniu metodę pobierzcenępodstawową w celu pobrania danych. Pierwsze, co można powiedzieć na temat tych dwóch ostatnich diagramów, jest to, że diagram sekwencji bardzo jasno przedstawia różnice we wzajemnej komunikacji uczestników. To jest ogromna zaleta diagramów interakcji. Nie nadają się one dobrze do przedstawiania szczegółów algorytmów, takich jak pętle lub zachowania warunkowe, ale wywołania między uczestnikami ukazują wyjątkowo przejrzyście i dają naprawdę dobry obraz działań wykonywanych przez poszczególnych uczestników. Drugą sprawą jest oczywista różnica w stylach między dwiema zaprezentowanymi interakcjami. Na poprzednim slajdzie przedstawiono sterowanie scentralizowane, w którym jeden z uczestników wykonuje zdecydowaną większość zadań, a inni uczestnicy dostarczają tylko dane. Na aktualnym slajdzie pokazano sterowanie rozproszone, w którym przetwarzanie jest rozdzielone między wielu uczestników i każdy z nich wykonuje mały fragment algorytmu. Oba style mają swoje wady i zalety. Wiele osób, zwłaszcza tych, które mają małe doświadczenie w technikach obiektowych, jest bardziej przyzwyczajonych do sterowania scentralizowanego. Z wielu względów jest ono mniej skomplikowane, ponieważ całe przetwarzanie dokonuje się w jednym miejscu. Przy sterowaniu rozproszonym można odnieść wrażenie, że ciągle skacze się po różnych obiektach, a sam program jakoś trudno uchwycić. Pomimo to, w projektowaniu obiektowym preferuje się sterowanie rozproszone. Jednym z zadań dobrego projektu jest zlokalizowanie efektów zachodzących zmian. Dane i metody, które uzyskują dostęp do tych danych, często zmieniają się równocześnie. A więc umieszczenie danych i metod ich używających razem w jednym miejscu, jest najważniejszą zasadą projektowania obiektowego. Ponadto, sterowanie rozproszone daje więcej okazji do użycia polimorfizmu zamiast logiki warunkowej. Jeśli algorytmy ustalania cen produktów są różne dla różnych typów produktów, to mechanizm sterowania rozproszonego pozwala na użycie klas pochodnych klasy Produkt w celu poprawnego uwzględnienia tych różnic. Ogólnie styl obiektowy daje możliwość użycia wielu małych obiektów z wieloma małymi metodami, dających mnóstwo okazji do zastosowania przeciążania funkcji i różnych ich wariacji. Jest to coś, czego bardzo trudno nauczyć. Wydaje się, że jedynym sposobem na zrozumienie tego podejścia jest popracowanie w środowisku obiektowym o silnie rozproszonym sterowaniu. 3

4 Tworzenie i usuwanie obiektów Projektowanie systemów informatycznych, wykład 3 4 Na diagramach sekwencji można stosować pewną dodatkową notację oznaczającą tworzenie i usuwanie uczestników. Aby utworzyć uczestnika, należy narysować strzałkę komunikatu łączącą się bezpośrednio z prostokątem uczestnika. Nazwa komunikatu jest w tym wypadku opcjonalna. Można tę nazwę opisać typem konstruktora, którego wywołuje się do tworzenia obiektu. Nazwa nowy jest uniwersalna i nie pokazuje, którego konstruktora użyto. Jeśli uczestnik zaraz po pojawieniu się wykonuje jakąś czynność, na przykład wywołuje komunikat kwerendy, to słupek aktywacji jest umieszczany bezpośrednio pod prostokątem uczestnika. Usunięcie uczestnika jest oznaczane dużym krzyżykiem w kształcie litery X. Strzałka komunikatu skierowana w stronę tego krzyżyka oznacza, że jeden uczestnik jawnie usuwa innego uczestnika. Krzyżyk umieszczony na końcu linii czasu oznacza, że uczestnik usuwa się sam. W środowisku, w którym zwalnianie pamięci przebiega automatycznie (Java,.NET) nie usuwa się obiektów bezpośrednio, ale nadal warto używać krzyżyków w celu wskazania, kiedy obiekt już przestaje być potrzebny i jest gotowy do usunięcia. Jest to również wskazane dla operacji zamykania, w celu zaznaczenia, że obiekt nie będzie już używany. 4

5 Rodzaje komunikatów Projektowanie systemów informatycznych, wykład 3 5 W nowej wersji języka UML strzałka z wypełnionym grotem oznacza komunikat synchroniczny, a strzałka z grotem otwartym należy do komunikatu asynchronicznego. Jeśli obiekt wysyła komunikat synchroniczny, to musi zaczekać na jego zrealizowanie, na przykład na wykonanie podprocedury. Jeśli natomiast obiekt wysyła komunikat asynchroniczny, to może kontynuować przetwarzanie, nie czekając na odpowiedź. Komunikaty asynchroniczne występują w aplikacjach wielowątkowych i w oprogramowaniu pośredniczącym opartym na komunikatach. Asynchroniczność umożliwia szybsze reagowanie i redukuje występowanie sprzężeń czasowych, ale utrudnia wykrywanie błędów w kodzie programu. 5

6 Pętle i instrukcje warunkowe procedure wysłanie foreach (pozycjazamówienia) if (produktwartość > zł) ostrożny.wysłanie else zwykły.wysłanie end if end for if (wymaganepotwierdzenie) komunikator.potwierdzenie end procedurę Projektowanie systemów informatycznych, wykład 3 6 Częstym problemem towarzyszącym diagramom sekwencji jest to, jak pokazać pętle i zachowania warunkowe. Przede wszystkim warto od razu zaznaczyć, że nie jest to coś, przy czym diagramy sekwencji dobrze się spisują. Aby pokazać tego typu struktury sterujące, znacznie lepiej użyć diagramu czynności lub nawet samego kodu programu. Diagramy sekwencji należy traktować jako sposób wizualnego przedstawienia, w jakie interakcje wchodzą ze sobą obiekty, a nie jako sposób modelowania logiki sterującej systemem. Jeśli chodzi o samą notację, to zarówno pętle, jak i instrukcje warunkowe korzystają z ramek interakcji, które służą do wyróżnienia fragmentu diagramu sekwencji. Na slajdzie zilustrowano nieskomplikowany algorytm oparty na pseudokodzie zaprezentowanym na lewo od diagramu. Ogólnie, ramki składają się z pewnego obszaru diagramu sekwencji, który może być dodatkowo podzielony na kilka fragmentów. Każda ramka ma operator a każdemu wydzielonemu fragmentowi ramki może towarzyszyć warunek. Aby przedstawić pętlę, używa się operatora loop i jednego fragmentu ramki, a podstawę iteracji umieszcza się w warunku. Dla instrukcji warunkowej można użyć operatora alt, a w każdym fragmencie ramki umieścić warunek. Zostaje wykonany tylko ten fragment, którego warunek jest prawdziwy. Jeśli istnieje tylko jeden obszar, to rządzi nim operator opt. Ramki interakcji są nowością w UML-u 2.0. Na diagramach przygotowanych przed pojawieniem się UML-a 2.0 stosowano inne podejścia. 6

7 Operatory ramek interakcji alt (od alternative) określający warunek wykonania bloku operacji, odpowiadający instrukcji if-else; warunek umieszcza się wówczas wewnątrz bloku w nawiasach kwadratowych opt (od optional) reprezentujący instrukcję if (bez else). Fragment zostaje wykonany tylko wówczas, gdy zawarty w nim warunek jest prawdziwy. Jest to odpowiednik operatora alt z jednym wyjściem. par (od parallel) nakazujący wykonać operacje równolegle Loop - definiujący pętlę typu for (o określonej z góry liczbie iteracji) lub while (wykonywanej dopóki pewien warunek jest prawdziwy) critical oznaczający obszar krytyczny. Fragment może mieć tylko jeden wątek uruchomiony w danej chwili. neg (od negation)negacja. Fragment przedstawia niepoprawną interakcję. W ten sposób opisujemy niepożądane interakcje w systemie. ref (od reference) Referencja. Odwołuje się do interakcji zdefiniowanej na innym diagramie. Ramka jest rysowana tak, aby przykrywać linie czasu biorące udział w interakcji. Można zdefiniować parametry i wartość zwrotną. sd (od sequence diagram) Diagram sekwencji. Używany do otoczenia ramką całego diagramu sekwencji, w miarę potrzeby. Projektowanie systemów informatycznych, wykład 3 7 7

8 Kiedy używać diagramów sekwencji Należy stosować diagramy sekwencji, aby spojrzeć na zachowanie się kilku obiektów w ramach jednego przypadku użycia systemu. Diagramy sekwencji są użyteczne do przedstawiania współpracy obiektów nie są jednak najlepsze do podawania ścisłej definicji zachowań. Do obserwowania zachowania się jednego obiektu w ramach kilku przypadków użycia należy zastosować diagram stanów. Do badania zachowania w wielu przypadkach użycia lub wielu wątkach należy rozważyć zastosowanie diagramów czynności. Projektowanie systemów informatycznych, wykład 3 8 8

9 Diagramy pakietów (1) Pakiet jest elementem grupującym pozwalającym na pogrupowanie dowolnych bytów UML-a w jednostki wyższego poziomu. Najczęstszym sposobem użycia pakietów jest grupowanie klas. Właśnie to użycie zostanie zaprezentowane w tym fragmencie wykładu. W modelu UML: Każda klasa jest składnikiem jednego pakietu Pakiety mogą być składnikami innych pakietów. Umożliwia to utworzenie hierarchicznej struktury, w której pakiety najwyższego poziomu są podzielone na mniejsze pakiety mające swoje własne podpakiety itd., aż hierarchia osiągnie najniższy poziom w postaci klas. Pakiet może zawierać zarówno pakiety podrzędne, jak i klasy. W językach programowania pakiety odpowiadają takim elementom, jak pakiety w Javie i przestrzenie nazw w językach C++ i.net. Projektowanie systemów informatycznych, wykład 3 9 Klasy są podstawowym składnikiem struktury systemu obiektowego. Są bardzo przydatne, jednak do tworzenia struktury ogromnych systemów, mających po kilkaset klas, potrzeba czegoś więcej. UML umożliwia grupowanie klas w pakiety. Diagramy pakietów służą do bardzo ogólnej prezentacji systemu. Pakiety są wykonywane w perspektywie projektowej lub implementacyjnej stąd na wykładzie z modelowania systemów informatycznych tego typu diagramy nie były prezentowane. Każdy pakiet reprezentuje przestrzeń nazw, co oznacza, że każda klasa musi mieć jednoznaczną nazwę wewnątrz zawierającego ją pakietu. Jeśli chcemy utworzyć klasę o nazwie Data i klasa Data już istnieje w pakiecie System, to nadal możemy mieć klasę Data, jeśli umieścimy ją w odrębnym pakiecie. Aby rozpoznać, która jest która, można użyć w pełni kwalifikowanej nazwy, tzn. nazwy uwzględniającej również zawierający klasę pakiet. Do określania nazw pakietów w UML-u używa się podwójnych dwukropków, więc na przykład klasy Data mogłyby mieć nazwy System::Data oraz MartinFowler::Użytkil::Data. 9

10 Diagramy pakietów (2) Projektowanie systemów informatycznych, wykład 3 10 Na diagramach pakiety są oznaczane za pomocą folderów z zakładkami. Na rysunku pokazano przykład takiego diagramu. Można uwidocznić tylko nazwę pakietu lub też jego zawartość. Wszędzie można używać zamiennie w pełni kwalifikowanych nazw lub zwykłych nazw prostych. Zawartość pakietu można przedstawić za pomocą ikon klas i uwzględnić wszystkie szczegóły klasy, nawet do poziomu diagramu klasy. Wypisanie samych nazw klas ma sens wtedy, gdy chcemy jedynie wskazać, jakie klasy znajdują się w poszczególnych pakietach. Znacznie częściej spotyka się krótkie nazwy klas, takie jak Datę (z pakietu java.util), niż nazwy w pełni kwalifikowane. W UML-u klasy w pakietach mogą być publiczne lub prywatne. Klasa publiczna jest częścią interfejsu pakietu i może być używana przez inne pakiety. Klasa prywatna jest ukryta. W różnych środowiskach programistycznych stosuje się różne reguły dotyczące zakresów widoczności występujących między poszczególnymi elementami pakietów. Należy przestrzegać konwencji środowiska programistycznego, nawet jeśli wymaga to nagięcia zasad UML-a. Dobrą praktyką jest ograniczenie interfejsu pakietu do niewielkiego podzbioru operacji klas publicznych. Można to osiągnąć, nadając wszystkim klasom prywatny zasięg widoczności, tak aby były one widziane tylko przez inne klasy tego pakietu, i dorzucając do pakietu dodatkowe klasy publiczne dla definicji zachowania publicznego. Te dodatkowe klasy, zwane fasadami, zlecają wykonanie operacji publicznych ich prywatnym partnerom w ramach pakietu. W jaki sposób zdecydować, które klasy umieścić w poszczególnych pakietach? Jest to dość trudne pytanie i aby umieć na nie odpowiadać, trzeba posiąść duże umiejętności w dziedzinie projektowania. Pakiety powinny być tworzone tak aby były jak najbardziej spójne wewnętrznie i aby było jak najmniej zależności między pakietami. Każdy nowy element wstawiany do pakietu powinien stanowić pełną całość wraz z pozostałymi elementami w pakiecie (powinien być z nimi w pewien sposób powiązany). Dobrym testem na sprawdzenie czy pakiet jest spójny może być próba nadania krótkiej nazwy pakietowi. Jeżeli istnieją problemy z nadaniem takiej nazwy to prawdopodobnie można dodać do pakietu niepowiązane elementy. 10

11 Zależności między pakietami Diagram pakietów przedstawia pakiety i zależności między nimi. Pojęcie zależności wprowadziłem na poprzednim wykładzie slajd 20. Jeżeli w pakiecie A istnieje przynajmniej jedna klasa, która jest zależna od przynajmniej jednej klasy pakietu B to mówimy, że pakiet A jest zależny od pakietu B. W ten sposób zależności między pakietami podsumowują zależności między zawartościami tych pakietów. Projektowanie systemów informatycznych, wykład 3 11 UML wymienia wiele różnych zależności, z których każda ma własną semantykę i słowo kluczowe. Zwykle jednak łatwiej jest zaczynać od ogólnych zależności bez słów kluczowych, a dopiero później, w miarę potrzeb, stosować bardziej wyrafinowane, jeżeli oczywiście jest to potrzebne. W średnich i dużych systemach narysowanie diagramu pakietów może być jedną z najbardziej wartościowych czynności, którą można wykonać w celu skontrolowania wielkoskalowej struktury systemu. W idealnej sytuacji diagram taki powinien zostać wygenerowany z samego kodu, tak aby można było zobaczyć, co rzeczywiście znajduje się w systemie. Dobra struktura pakietów charakteryzuje się przejrzystym przepływem zależności. Tę cechę trudno zdefiniować, ale często łatwiej rozpoznać. Na rysunku pokazano przykładowy diagram pakietów dla aplikacji przedsiębiorstwa, który ma dobrą strukturę i przejrzysty przepływ zależności. Często przejrzysty przepływ zależności można rozpoznać po tym, że wszystkie zależności podążają w jednym kierunku. Mimo że jest to dobry wyznacznik, to widać na rysunku, że pakiety warstwy odwzorowania danych nie są zgodne z tą regułą. Pakiety te stanowią warstwę izolacyjną między pakietami domeny i bazy danych. Im więcej zależności dochodzi do pakietu, tym stabilniejszy musi być interfejs tego pakietu, ponieważ każda zmiana w interfejsie przeniesie się na wszystkie zależne pakiety. A zatem na rysunku pakiet warstwy domeny aktywów musi mieć stabilniejszy interfejs niż pakiet warstwy odwzorowania danych leasingu. Aby pakiet był bardziej stabilny powinien zawierać możliwie dużo interfejsów i klas abstrakcyjnych (patrz slajd 25 z poprzedniego wykładu). Relacje zależności nie są przechodnie (poprzedni wykład slajd 20). Aby dostrzec, dlaczego jest to istotne w wypadku zależności, spójrzmy ponownie na rysunek na slajdzie. Zmiana w klasie pakietu aktywa-domena może pociągnąć za sobą zmianę w pakiecie leasing-domena. Ale ta zmiana niekoniecznie przeniknie do warstwy prezentacji dziedziny leasingu. (Stanie się tak tylko wtedy, gdy dziedzina leasingu zmieni swój interfejs.) 11

12 Pakiet jak zbiór klas abstrakcyjnych i interfejsów Aplikacja Bramka Bazy danych Bramka Oracle Bramka SQL Server Bramka Test Stub Projektowanie systemów informatycznych, wykład 3 12 Zdarza się, że jeden pakiet definiuje interfejs implementowany przez kilka innych pakietów, na przykład tak jak na zaprezentowanym rysunku. W takim wypadku relacja implementacji wskazuje na to, że bramka bazy danych definiuje Merfejs, a inne klasy bramek bazodanowych zapewniają implementację. W praktyce oznaczałoby to, że pakiet bramki bazodanowej zawiera interfejsy i klasy abstrakcyjne zaimplementowane całkowicie przez inne pakiety. Bardzo częstą praktyką jest umieszczanie interfejsu i jego implementacji w osobnych pakietach. 12

13 Przykład pakietu z interfejsem Ogrzewanie::Grzejnik Oświetlenie::Lampa Projektowanie systemów informatycznych, wykład 3 13 Załóżmy, że należy zaprojektować element interfejsu użytkownika do włączania i wyłączania różnych urządzeń. Element ten powinien współpracować z wieloma różnymi urządzeniami, takimi jak grzejniki i światła. Musi wywoływać metodę na przykład dla grzejnika, ale nie powinien być od niego zależny. Powstania zależności między grzejnikiem a elementem sterującym można uniknąć, definiując w pakiecie elementu sterującego interfejs, który następnie zostanie zaimplementowany przez dowolną klasę, która zechce współpracować z tym elementem sterującym. Ilustruje to rysunek na slajdzie 13

14 Używanie diagramów pakietów Diagramy pakietów są przydatne w dużych systemach, gdyż pozwalają na uzyskanie obrazu zależności między głównymi elementami. Diagramy pakietów dobrze odpowiadają często stosowanym strukturom programistycznym. Rysowanie diagramów pakietów i zależności pomaga w utrzymywaniu pod kontrolą zależności występujących w aplikacji. Diagramy pakietów reprezentują mechanizm grupowania w czasie kompilowania programu. Projektowanie systemów informatycznych, wykład

15 Diagram stanów Diagram stanów przedstawia maszynę stanową składającą się ze stanów, przejść, zdarzeń i czynności. Opisuje on stany pewnego procesu, które są istotne z punktu widzenia modelu pojęciowego tego procesu, oraz przejścia pomiędzy stanami wymuszane poprzez wywoływane usługi obiektu. Określa też reakcje obiektu na zdarzenia zachodzące podczas jego użycia. Diagram stanów odnosi się do modelowania dynamicznych aspektów systemu. Projektowanie systemów informatycznych, wykład 3 15 Zasady tworzenia diagramów stanów zaprezentowano na wykładzie dotyczącym modelowania systemów informatycznych w poprzednim semestrze. W celu przypomnienia podstawowych informacji dotyczących diagramów stanów proszę przeczytać odpowiedni fragment kursu modelowania systemów informatycznych. Na niniejszym wykładzie zamierzam zaprezentować jedynie sposoby implementacji diagramów stanów na podstawie przykładu. Będąc studentem, a nie było to tak dawno (niestety za kilka lat to ostatnie wtrącenie będę musiał wykreślić), namiętnie grałem w gry strategiczne typu Heroes of Might and Magic, Age of Empires, Red Alert. Niestety teraz nie mam już czasu na tego typu intelektualne przygody. Ponieważ jednak darze sentymentem gry strategiczne to mój przykład będzie związany z pewnym aspektem tego typu gier. Załóżmy, że gramy w grę gdzie musimy rozbudowywać osadę. Pierwszym budynkiem jaki należy zbudować aby stworzyć wioskę jest chata sołtysa. Następnie rozbudowujemy wioskę tworząc kolejne chaty i zakłady rzemieślnicze, koszary itd. Kiedy liczba mieszkańców przekroczy 100 wtedy możemy zlecić rozbudowanie (upgrade) chaty sołtysa do ratusza. Wydanie zlecenia rozbudowy chaty sołtysa pod warunkiem osiągnięcia liczby 100 mieszkańców oznacza przekształcenie wioski w miasto. Miasto rozbudowujemy dalej o nowe budynki również takie których nie mogliśmy tworzyć we wiosce. Wydanie zlecenia rozbudowy ratusza do zamku królewskiego pod warunkiem osiągnięcia liczby 1000 mieszkańców oznacza przekształcenie miasta w stolicę. Status stolicy oznacza dodatkowe przywileje oraz umożliwia budowanie nowych budynków, których nie można było budować w mieście (zwłaszcza budynki obronne). Oczywiście nasza osada może zostać zaatakowana przez obcą armię. Wtedy może stracić status stolicy jeżeli liczba mieszkańców spadnie poniżej 1000 lub status miasta jeżeli liczba mieszkańców spadnie poniżej 100. Jeżeli natomiast we wiosce zostanie zburzona chata sołtysa, w mieście ratusz, a w stolicy zamek królewski to osada przestaje istnieć. Oczywiście jest to przykład uproszczony i z punktu widzenia logiki gry można by się do niego w kilku miejscach przyczepić. Przykład uprościłem specjalnie aby stworzyć w miarę prosty i czytelny diagram stanów zaprezentowany na następnym slajdzie. 15

16 Przykład diagramu stanów Wybud. chaty sołtysa [odpowiednia ilość miejsca na planszy] Wioska Zburzenie chaty sołtysa [lm < 100]/ Zablokowanie budowania budynków miasta i niemożność korzystania z bud. miasta Zlecenie wybud. ratusza [lm 100]/ Możliwość budowania budynków miejskich Zburzenie ratusza Miasto Zlecenie wybud. ZK [lm 1000 ]/ Możliwość budowania budynków stolicy [lm < 1000]/Zablokowanie budowania budynków stolicy i niemożność korzystania z bud. stolicy Stolica Legenda: Zburzenie ZK ZK zamek królewski lm liczba mieszkańców Projektowanie systemów informatycznych, wykład

17 Implementacja diagramu stanów - switch void Osada::ObslugaPrzejścia(ZdarzenieOsady Zd) { switch (StanAktualny){ case StanOsady.Wioska: switch(zd){ case ZdarzenieOsady.ZlecenieWybudRatusza: if(lm>=100) StanAktualny = StanOsady.Miasto; break; case ZdarzenieOsady.ZburzenieChatySoltysa: StanAktualny = StanOsady.Zburzona; break; } break; case StanOsadyMiasto: switch(zd){ case ZdarzenieOsady.ZlecenieWybudZK: if(lm>=1000) StanAktualny = StanOsady.Stolica; break; case ZdarzenieOsady.ZburzenieRatusza: StanAktualny = StanOsady.Zburzona; break; case StanOsadyStolica: switch(zd){ case ZdarzenieOsady.ZburzenieZK: StanAktualny = StanOsady.Zburzona; } if(lm < 1000) StanAktualny = StanOsady.Miasto; }// Koniec switch(stanaktualny) }//koniec funkcji Obsluga zdarzenia } if(lm < 100) StanAktualny = StanOsady.Wioska; break; Projektowanie systemów informatycznych, wykład 3 17 Najbardziej bezpośrednim podejściem jest zaimplementowanie diagramu stanów za pomocą zagnieżdżonej instrukcji switch. Na aktualnym slajdzie zaprezentowano przykład takiej implementacji dla diagramu ze slajdu 16. Proszę zauważyć, że funkcja ObsługaPrzejścia obsługuje tzw. przejścia automatyczne czyli takie, które zachodzą automatycznie przy spełnieniu określonego warunku. Przejścia takie nie są rezultatem generacji jakiegokolwiek zdarzenia Zd. Stąd czy funkcja będzie działać poprawnie dla tego typu przejść? Funkcja ta będzie działać poprawnie dla przejść automatycznych wtedy gdy będzie wywoływana przy każdym obiegu pętli komunikatów niezależnie czy wygenerowano ZdarzenieOsady czy nie. Można również postąpić inaczej i obsługę przejść automatycznych umieścić w osobnej funkcji, która będzie wywoływana w każdym obiegu pętli obsługi komunikatów. Wtedy funkcję ObsługaPrzejścia będzie można wywoływać tylko wtedy gdy wygenerowano ZdarzenieOsady. W powyższym pseudokodzie nie uwzględniono przejścia realizowanego przez zdarzenie wybudowania chaty sołtysa. Przejście to prowadzi od pseudostanu do stanu Wioska i jest związane z utworzeniem obiektu klasy Osada stąd nie może być obsłużone w funkcji z klasy Osada. Przejście to powinno być obsłużone w globalnej funkcji obsługi przejść. Rezultatem tego przejścia będzie utworzenie obiektu klasy Osada, ustawienie jej parametrów początkowych i dodanie obiektu do kolekcji wszystkich obiektów gry. Proszę również zauważyć, że w niniejszym kodzie nie zaprezentowano akcji typu odblokowania, zablokowania budowania budynków miasta lub stolicy przy odpowiednich przejściach. Dzieje się tak dlatego, że w kodzie możliwość budowania budynków miasta lub stolicy rozpoznaje się po stanie osady. Mimo że podejście z instrukcją switch wydaje się najbardziej oczywiste prowadzi do powstania długiego i nieczytelnego kodu nawet w prostych przypadkach. 17

18 Implementacja diagramu stanów klasa abstrakcyjna Kontroler ZmianaStanuNa(StanOsady ) ObsZlecenieWybudRatusza(Kontroler* K) ObsZburzenieChatySoltysa(Kontroler* K) ObsZlecenieWybudZK(Kontroler* K) ObsZburzenieRatusza(Kontroler* K) ObsZburzenieZK(Kontroler* K) ObsZdAutomatycznych() stan 1 StanOsady ObsZlecenieWybudRatusza(Kontroler* K) ObsZburzenieChatySoltysa(Kontroler* K) ObsZlecenieWybudZK(Kontroler* K) ObsZburzenieRatusza(Kontroler* K) ObsZburzenieRatusza(Kontroler* K) ObsZburzenieZK(Kontroler* K) ObsZdAutomatycznych(Kontroler* K) stan->obszdautomatycznych(this) StanWioska StanMiasto StanStolica StanKoniec ObsZlecenieWybudRatusza(Kontroler* K) ObsZburzenieChatySoltysa(Kontroler* K) ObsZdAutomatycznych(Kontroler* K) ObsZlecenieWybudZK(Kontroler* K) ObsZburzenieRatusza(Kontroler* K) ObsZdAutomatycznych(Kontroler* K) ObsZburzenieZK(Kontroler* K) ObsZdAutomatycznych(Kontroler* K) If(lm >= 100) K->ZmianaStanuNa(StanMiasto); If(lm < 100) K->ZmianaStanuNa(StanWioska); Projektowanie systemów informatycznych, wykład 3 18 W metodzie ze wzorcem klasy stanów tworzy się hierarchię klas stanów do obsługi zachowania się tych stanów. Każdy stan na diagramie ma jedną podklasę stanów. Kontroler ma metody dla każdego zdarzenia, które po prostu powodują odesłanie do odpowiedniej klasy stanów. Na szczycie hierarchii zdarzeń znajduje się klasa abstrakcyjna (StanOsady), która implementuje wszystkie możliwe metody obsługi zdarzeń tak aby nic nie robiły. Każda klasa konkretnego stanu przeciąża metody obsługujące przejścia wychodzące z tego stanu. Powyższy przykład pokazuje diagram klas UML, z fragmentami kodu w C++, prezentujący klasy implementacyjne diagramu stanów ze slajdu

19 Implementacja diagramu stanu tablica stanów Stan źródłowy Stan docelowy Zdarzenie Dozór Procedura Pseudostan Wioska WybudChatySołtysa Odpowiednia ilość miejsca na planszy Umożliwienie rozbudowy osady Wioska Koniec ZburzenieChatySoltysa Wioska Miasto ZlecenieWybudRatusza lm 100 Umożliwienie budowy budynków miasta Miasto Koniec ZburzenieRatusza Miasto Wioska lm < 100 Zablokowanie budowania budynków miejskich oraz możliwości korzystania z nich Miasto Stolica ZlecenieWybudZK lm 1000 Umożliwienie budowy budynków stolicy Stolica Koniec ZburzenieZK Stolica Miasto lm < 1000 Zablokowanie budowania budynków miejskich oraz możliwości korzystania z nich Projektowanie systemów informatycznych, wykład 3 19 Tabela stanów to trzecie podejście polegające na zakodowaniu informacji z diagramu stanów w postaci tabeli danych. Przykładowemu diagramowi ze slajdu 16 odpowiada tabela zaprezentowana na niniejszym slajdzie. Po sporządzeniu tabeli tworzy się interpreter, który używa tablicy stanów w czasie wykonywania programu, albo generator kodu, który tworzy klasy na podstawie tabeli stanów. Tabela ma taką zaletę, że może być modyfikowana bez ponownej kompilacji programu. Wzorzec stanów jest łatwiejszy do przygotowania, gdy jest potrzebny doraźnie, chociaż potrzeba nowej klasy dla każdego stanu, to nie ma przy tym zbyt dużo kodowania. Niezależnie od tego jaki sposób implementacji stosujemy to zwykle w realnych zadaniach implementacja stanów prowadzi do bardzo skomplikowanego kodu stąd zastosowanie narzędzi CASE w postaci generatorów kodu jest tu ze wszech miar uzasadnione. 19

20 Diagramy wdrożenia Diagramy wdrożenia przedstawiają fizyczny układ systemu. Pokazują, w których częściach sprzętu działają poszczególne fragmenty oprogramowania. Klient-przeglądarka Znacznik z wartością Serwer aplikacji przeglądarka Klient dedykowany {OS=Windows} ReaClient.exe http/internet http/sieć lokalna Węzeł urządzenia Serwer WWW {OS=Linux} {serwer WWW = apache} {Obsługa konta} {liczba wdrożeń = 5} Ścieżka komunikacyjna Zapytanie SQL SQL server System bazodanowy kont klientów Oracle Wdrożony artefakt Węzeł środowiska wykonawczego Projektowanie systemów informatycznych, wykład 3 20 Diagramy wdrożeń przygotowywane są na etapie projektowania systemu i pokazują miejsca wdrożeń poszczególnych fragmentów systemu, więc okazują się bardzo pomocne w wypadku dużych systemów oraz systemów rozproszonych. Na rysunku znajduje się prosty przykład diagramu wdrożenia. Głównymi elementami diagramu są węzły połączone za pomocą ścieżek komunikacyjnych Węzeł jest to coś, co może utrzymywać jakąś część oprogramowania. Są dwa rodzaje węzłów. Pierwszym jest węzeł urządzenia, czyli sprzęt. Węzeł urządzenia może reprezentować komputer albo mniej złożoną część sprzętu komputerowego podłączoną do systemu. Drugim rodzajem jest węzeł środowiska wykonawczego. Reprezentuje on oprogramowanie, które samo się uruchamia lub zawiera inne oprogramowanie Przykładem może tu być system operacyjny. Węzły zawierają artefakty, czyli oprogramowanie w fizycznej postaci najczęściej pliki. Pliki mogą być zbiorami wykonywalnymi (na przykład.exe, pliki binarne, biblioteki DLL, pliki JAR, asemblacje lub skrypty) lub plikami danych, plikami konfiguracyjnymi, dokumentami HTML itp. Wpisanie artefaktu do węzła oznacza, że artefakt ten jest wdrożony do tego węzła w działającym systemie. Artefakty można przedstawić albo za pomocą ramek klas, albo wypisując ich nazwy w węźle. W wypadku użycia pierwszego sposobu można dodać ikonę dokumentu lub słowo kluczowe «artifact». Węzły lub artefakty można oznaczyć za pomocą znaczników z wartościami. W ten sposób można podać różne interesujące informacje o węźle, takie jak producent, system operacyjny, lokalizacja itd. Często w systemach istnieje kilka fizycznych węzłów wykonujących to samo logiczne zadanie. Można to pokazać za pomocą kilku ramek węzłów lub za pomocą znacznika z liczbą wdrożeń (Przykładowo na rysunku 5 serwerów WWW). Ścieżki komunikacyjne między węzłami ilustrują, w jaki sposób poszczególne elementy komunikują się ze sobą. Ścieżki te można oznaczyć etykietami i zapisać w nich informacje o użytych protokołach komunikacyjnych. 20

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

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

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

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

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

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

Być może jesteś doświadczonym programistą, biegle programujesz w Javie,

Być może jesteś doświadczonym programistą, biegle programujesz w Javie, Kompendium PHP 01 Być może jesteś doświadczonym programistą, biegle programujesz w Javie, C++, Pythonie lub jakimś innym języku programowania, których jak myślę, powstało już tyle, że chyba nie ma osoby,

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

Diagramy czynności Na podstawie UML 2.0 Tutorial

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

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych PAŃSTWOWA WYŻSZA SZKOŁA ZAWODOWA W ELBLĄGU INSTYTUT INFORMATYKI STOSOWANEJ Sprawozdanie z Seminarium Dyplomowego Temat: Ułatwienia wynikające z zastosowania Frameworku CakePHP podczas budowania stron internetowych

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

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

koniec punkt zatrzymania przepływów sterowania na diagramie czynności

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

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

1 Podstawy c++ w pigułce.

1 Podstawy c++ w pigułce. 1 Podstawy c++ w pigułce. 1.1 Struktura dokumentu. Kod programu c++ jest zwykłym tekstem napisanym w dowolnym edytorze. Plikowi takiemu nadaje się zwykle rozszerzenie.cpp i kompiluje za pomocą kompilatora,

Bardziej szczegółowo

znajdowały się różne instrukcje) to tak naprawdę definicja funkcji main.

znajdowały się różne instrukcje) to tak naprawdę definicja funkcji main. Część XVI C++ Funkcje Jeśli nasz program rozrósł się już do kilkudziesięciu linijek, warto pomyśleć o jego podziale na mniejsze części. Poznajmy więc funkcje. Szybko się przekonamy, że funkcja to bardzo

Bardziej szczegółowo

Konstruktory. Streszczenie Celem wykładu jest zaprezentowanie konstruktorów w Javie, syntaktyki oraz zalet ich stosowania. Czas wykładu 45 minut.

Konstruktory. Streszczenie Celem wykładu jest zaprezentowanie konstruktorów w Javie, syntaktyki oraz zalet ich stosowania. Czas wykładu 45 minut. Konstruktory Streszczenie Celem wykładu jest zaprezentowanie konstruktorów w Javie, syntaktyki oraz zalet ich stosowania. Czas wykładu 45 minut. Rozpatrzmy przykład przedstawiający klasę Prostokat: class

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

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

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

Wykład V. Rzut okiem na języki programowania. Studia Podyplomowe INFORMATYKA Podstawy Informatyki

Wykład V. Rzut okiem na języki programowania. Studia Podyplomowe INFORMATYKA Podstawy Informatyki Studia Podyplomowe INFORMATYKA Podstawy Informatyki Wykład V Rzut okiem na języki programowania 1 Kompilacja vs. interpretacja KOMPILACJA Proces, który przetwarza program zapisany w języku programowania,

Bardziej szczegółowo

Uwagi dotyczące notacji kodu! Moduły. Struktura modułu. Procedury. Opcje modułu (niektóre)

Uwagi dotyczące notacji kodu! Moduły. Struktura modułu. Procedury. Opcje modułu (niektóre) Uwagi dotyczące notacji kodu! Wyrazy drukiem prostym -- słowami języka VBA. Wyrazy drukiem pochyłym -- inne fragmenty kodu. Wyrazy w [nawiasach kwadratowych] opcjonalne fragmenty kodu (mogą być, ale nie

Bardziej szczegółowo

ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia

ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia ZP/ITS/11/2012 Załącznik nr 1a do SIWZ ZMODYFIKOWANY Szczegółowy opis przedmiotu zamówienia Przedmiotem zamówienia jest: Przygotowanie zajęć dydaktycznych w postaci kursów e-learningowych przeznaczonych

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

UML a kod w C++ i Javie. Przypadki użycia. Diagramy klas. Klasy użytkowników i wykorzystywane funkcje. Związki pomiędzy przypadkami.

UML a kod w C++ i Javie. Przypadki użycia. Diagramy klas. Klasy użytkowników i wykorzystywane funkcje. Związki pomiędzy przypadkami. UML a kod w C++ i Javie Projektowanie oprogramowania Dokumentowanie oprogramowania Diagramy przypadków użycia Przewoznik Zarzadzanie pojazdami Optymalizacja Uzytkownik Wydawanie opinii Zarzadzanie uzytkownikami

Bardziej szczegółowo

W przeciwnym wypadku wykonaj instrukcję z bloku drugiego. Ćwiczenie 1 utworzyć program dzielący przez siebie dwie liczby

W przeciwnym wypadku wykonaj instrukcję z bloku drugiego. Ćwiczenie 1 utworzyć program dzielący przez siebie dwie liczby Część XI C++ W folderze nazwisko36 program za każdym razem sprawdza oba warunki co niepotrzebnie obciąża procesor. Ten problem można rozwiązać stosując instrukcje if...else Instrukcja if wykonuje polecenie

Bardziej szczegółowo

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja

ZPKSoft WDoradca. 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja ZPKSoft WDoradca 1. Wstęp 2. Architektura 3. Instalacja 4. Konfiguracja 5. Jak to działa 6. Licencja 1. Wstęp ZPKSoft WDoradca jest technologią dostępu przeglądarkowego do zasobów systemu ZPKSoft Doradca.

Bardziej szczegółowo

Materiały do laboratorium MS ACCESS BASIC

Materiały do laboratorium MS ACCESS BASIC Materiały do laboratorium MS ACCESS BASIC Opracowała: Katarzyna Harężlak Access Basic jest językiem programowania wykorzystywanym w celu powiązania obiektów aplikacji w jeden spójny system. PROCEDURY I

Bardziej szczegółowo

Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat

Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Opracował Jan T. Biernat Programowanie Strukturalne i Obiektowe Słownik podstawowych pojęć 1 z 5 Program, to lista poleceń zapisana w jednym języku programowania zgodnie z obowiązującymi w nim zasadami. Celem programu jest przetwarzanie

Bardziej szczegółowo

Widoczność zmiennych Czy wartości każdej zmiennej można zmieniać w dowolnym miejscu kodu? Czy można zadeklarować dwie zmienne o takich samych nazwach?

Widoczność zmiennych Czy wartości każdej zmiennej można zmieniać w dowolnym miejscu kodu? Czy można zadeklarować dwie zmienne o takich samych nazwach? Część XVIII C++ Funkcje Widoczność zmiennych Czy wartości każdej zmiennej można zmieniać w dowolnym miejscu kodu? Czy można zadeklarować dwie zmienne o takich samych nazwach? Umiemy już podzielić nasz

Bardziej szczegółowo

1 Podstawy c++ w pigułce.

1 Podstawy c++ w pigułce. 1 Podstawy c++ w pigułce. 1.1 Struktura dokumentu. Kod programu c++ jest zwykłym tekstem napisanym w dowolnym edytorze. Plikowi takiemu nadaje się zwykle rozszerzenie.cpp i kompiluje za pomocą kompilatora,

Bardziej szczegółowo

Wprowadzenie do projektu QualitySpy

Wprowadzenie do projektu QualitySpy Wprowadzenie do projektu QualitySpy Na podstawie instrukcji implementacji prostej funkcjonalności. 1. Wstęp Celem tego poradnika jest wprowadzić programistę do projektu QualitySpy. Będziemy implementować

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

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

Oracle11g: Programowanie w PL/SQL

Oracle11g: Programowanie w PL/SQL Oracle11g: Programowanie w PL/SQL OPIS: Kurs pozwala zrozumieć zalety programowania w języku PL/SQL. Studenci uczą się tworzyć bloki kodu wykonywanego po stronie serwera, który może być współużytkowany

Bardziej szczegółowo

Obiektowy PHP. Czym jest obiekt? Definicja klasy. Składowe klasy pola i metody

Obiektowy PHP. Czym jest obiekt? Definicja klasy. Składowe klasy pola i metody Obiektowy PHP Czym jest obiekt? W programowaniu obiektem można nazwać każdy abstrakcyjny byt, który programista utworzy w pamięci komputera. Jeszcze bardziej upraszczając to zagadnienie, można powiedzieć,

Bardziej szczegółowo

JAVA. Java jest wszechstronnym językiem programowania, zorientowanym. apletów oraz samodzielnych aplikacji.

JAVA. Java jest wszechstronnym językiem programowania, zorientowanym. apletów oraz samodzielnych aplikacji. JAVA Java jest wszechstronnym językiem programowania, zorientowanym obiektowo, dostarczającym możliwość uruchamiania apletów oraz samodzielnych aplikacji. Java nie jest typowym kompilatorem. Źródłowy kod

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

Wprowadzenie do programowania

Wprowadzenie do programowania do programowania ITA-104 Wersja 1 Warszawa, Wrzesień 2009 ITA-104 do programowania Informacje o kursie Zakres tematyczny kursu Opis kursu Kurs przeznaczony jest do prowadzenia przedmiotu do programowania

Bardziej szczegółowo

Java. język programowania obiektowego. Programowanie w językach wysokiego poziomu. mgr inż. Anna Wawszczak

Java. język programowania obiektowego. Programowanie w językach wysokiego poziomu. mgr inż. Anna Wawszczak Java język programowania obiektowego Programowanie w językach wysokiego poziomu mgr inż. Anna Wawszczak 1 Język Java Język Java powstał w roku 1995 w firmie SUN Microsystems Java jest językiem: wysokiego

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

Generated by Foxit PDF Creator Foxit Software http://www.foxitsoftware.com For evaluation only. System Szablonów

Generated by Foxit PDF Creator Foxit Software http://www.foxitsoftware.com For evaluation only. System Szablonów System Szablonów System szablonów System szablonów to biblioteka, która pozwala oddzielić warstwę prezentacji od warstwy logicznej. Aplikacja WWW najpierw pobiera wszystkie dane, przetwarza je i umieszcza

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

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

Rozdział 4 KLASY, OBIEKTY, METODY

Rozdział 4 KLASY, OBIEKTY, METODY Rozdział 4 KLASY, OBIEKTY, METODY Java jest językiem w pełni zorientowanym obiektowo. Wszystkie elementy opisujące dane, za wyjątkiem zmiennych prostych są obiektami. Sam program też jest obiektem pewnej

Bardziej szczegółowo

Dokumentacja końcowa projektu z ZPR

Dokumentacja końcowa projektu z ZPR Dokumentacja końcowa projektu z ZPR Temat projektu: Prowadzący projekt: Zespół projektowy: Losowe przeszukiwanie stanów dr inż. Robert Nowak Piotr Krysik Kamil Zabielski 1. Opis projektu Projekt ma za

Bardziej szczegółowo

Diagramy związków encji. Laboratorium. Akademia Morska w Gdyni

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

Wykład I. Wprowadzenie do baz danych

Wykład I. Wprowadzenie do baz danych Wykład I Wprowadzenie do baz danych Trochę historii Pierwsze znane użycie terminu baza danych miało miejsce w listopadzie w 1963 roku. W latach sześcdziesątych XX wieku został opracowany przez Charles

Bardziej szczegółowo

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 2 Modelowanie i analiza systemów informatycznych 1. Warstwowa budowa systemów informatycznych 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wstęp do modelowania systemów

Bardziej szczegół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

Architektury Usług Internetowych. Laboratorium 2. Usługi sieciowe

Architektury Usług Internetowych. Laboratorium 2. Usługi sieciowe Architektury Usług Internetowych Laboratorium 2. Usługi sieciowe Wstęp Celem laboratorium jest zapoznanie się z modelem usług sieciowych na przykładzie prostego serwera Apache Axis2. Apache Axis2 Apache

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

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia)

Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) Grupy pytań na egzamin magisterski na kierunku Informatyka (dla studentów niestacjonarnych studiów II stopnia) WERSJA WSTĘPNA, BRAK PRZYKŁADOWYCH PYTAŃ DLA NIEKTÓRYCH PRZEDMIOTÓW Należy wybrać trzy dowolne

Bardziej szczegółowo

Kurs programowania. Wstęp - wykład 0. Wojciech Macyna. 22 lutego 2016

Kurs programowania. Wstęp - wykład 0. Wojciech Macyna. 22 lutego 2016 Wstęp - wykład 0 22 lutego 2016 Historia Simula 67 język zaprojektowany do zastosowan symulacyjnych; Smalltalk 80 pierwszy język w pełni obiektowy; Dodawanie obiektowości do języków imperatywnych: Pascal

Bardziej szczegółowo

System zarządzający grami programistycznymi Meridius

System zarządzający grami programistycznymi Meridius System zarządzający grami programistycznymi Meridius Instytut Informatyki, Uniwersytet Wrocławski 20 września 2011 Promotor: prof. Krzysztof Loryś Gry komputerowe a programistyczne Gry komputerowe Z punktu

Bardziej szczegółowo

Ćwiczenia 9: Zarządzanie konfiguracją Zadania:

Ćwiczenia 9: Zarządzanie konfiguracją Zadania: Ćwiczenia 9: Zarządzanie konfiguracją Zadania: Konfiguracja repozytorium CVS: 1. Ściągnij i zainstaluj serwer CVS: CVSNT (www.cvsnt.org). 2. W konfiguracji repozytoriów (Panel Sterowania -> CVSNT) wybierz

Bardziej szczegółowo

SZYBKO ZROZUMIEĆ VISUAL BASIC 2012 Artur Niewiarowski -

SZYBKO ZROZUMIEĆ VISUAL BASIC 2012 Artur Niewiarowski - S t r o n a 2 SZYBKO ZROZUMIEĆ VISUAL BASIC 2012 Artur Niewiarowski - Copyright by Artur Niewiarowski 2013 ISBN: 978-83-937802-0-4 - Artur Niewiarowski Self-Publishing - All rights reserved. Wszelkie prawa

Bardziej szczegółowo

Programowanie I. O czym będziemy mówili. Plan wykładu nieco dokładniej. Plan wykładu z lotu ptaka. Podstawy programowania w językach. Uwaga!

Programowanie I. O czym będziemy mówili. Plan wykładu nieco dokładniej. Plan wykładu z lotu ptaka. Podstawy programowania w językach. Uwaga! Programowanie I O czym będziemy mówili Podstawy programowania w językach proceduralnym ANSI C obiektowym Java Uwaga! podobieństwa w podstawowej strukturze składniowej (zmienne, operatory, instrukcje sterujące...)

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

Zalety projektowania obiektowego

Zalety projektowania obiektowego Zalety projektowania obiektowego Łatwe zarządzanie Możliwość powtórnego użycia klas obiektów projektowanie/programowanie komponentowe W wielu przypadkach występuje stosunkowo proste mapowanie pomiędzy

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

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

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV

Dokumentacja wstępna TIN. Rozproszone repozytorium oparte o WebDAV Piotr Jarosik, Kamil Jaworski, Dominik Olędzki, Anna Stępień Dokumentacja wstępna TIN Rozproszone repozytorium oparte o WebDAV 1. Wstęp Celem projektu jest zaimplementowanie rozproszonego repozytorium

Bardziej szczegółowo

Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online)

Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online) Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online) Spis treści Opis protokołu komunikacji programu mpensjonat z systemami zewnętrznymi (np. rezerwacji online)...1

Bardziej szczegółowo

Funkcje i instrukcje języka JavaScript

Funkcje i instrukcje języka JavaScript Funkcje i instrukcje języka JavaScript 1. Cele lekcji a) Wiadomości Uczeń : zna operatory i typy danych języka JavaScript, zna konstrukcję definicji funkcji, zna pętlę If i For, Do i While oraz podaje

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

Programowanie MorphX Ax

Programowanie MorphX Ax Administrowanie Czym jest system ERP? do systemu Dynamics Ax Obsługa systemu Dynamics Ax Wyszukiwanie informacji, filtrowanie, sortowanie rekordów IntelliMorph : ukrywanie i pokazywanie ukrytych kolumn

Bardziej szczegółowo

TECHNOLOGIE INTERNETOWE WYKŁAD 6. JavaScript Funkcje i obiekty

TECHNOLOGIE INTERNETOWE WYKŁAD 6. JavaScript Funkcje i obiekty 1. Co to jest funkcja? Funkcja jest oddzielnym blokiem kodu, który może być wielokrotnie wykonywany w danym programie, poprzez jej wielokrotne wywoływanie. Do funkcji przekazujemy przeważnie jakieś argumenty,

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

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

Oracle10g: Programowanie w PL/SQL

Oracle10g: Programowanie w PL/SQL Oracle10g: Programowanie w PL/SQL OPIS: Szkolenie dotyczy użytkowników Oracle8i, Oracle9i i Oracle10g. Ten kurs pozwala zrozumieć zalety tego potężnego narzędzia programowania do PL/SQL. Studenci uczą

Bardziej szczegółowo

Ogranicz listę klasyfikacji budżetowych do powiązanych z danym kontem księgowym

Ogranicz listę klasyfikacji budżetowych do powiązanych z danym kontem księgowym Zależności i kontrola danych budżetowych w systemie Sz@rk FK 1. Wstęp Począwszy od wersji Sz@rk FK 2011 (11.03.30) wprowadzono do programu finansowoksięgowego nowe możliwości dotyczące kontrolowania poprawności

Bardziej szczegółowo

Jak ustawić cele kampanii?

Jak ustawić cele kampanii? Jak ustawić cele kampanii? Czym są cele? Jest to funkcjonalność pozwalająca w łatwy sposób śledzić konwersje wygenerowane na Twojej stronie www poprzez wiadomości email wysłane z systemu GetResponse. Mierzenie

Bardziej szczegółowo

Języki programowania zasady ich tworzenia

Języki programowania zasady ich tworzenia Strona 1 z 18 Języki programowania zasady ich tworzenia Definicja 5 Językami formalnymi nazywamy każdy system, w którym stosując dobrze określone reguły należące do ustalonego zbioru, możemy uzyskać wszystkie

Bardziej szczegółowo

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych

Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Mariusz Trzaska Modelowanie i implementacja systemów informatycznych Notka biograficzna Dr inż. Mariusz Trzaska jest adiunktem w Polsko-Japońskiej Wyższej Szkole Technik Komputerowych, gdzie zajmuje się

Bardziej szczegółowo

Instrukcje wyboru. Tworzenie programu, Schematy blokowe, Instrukcje wyboru, Operatory logiczne

Instrukcje wyboru. Tworzenie programu, Schematy blokowe, Instrukcje wyboru, Operatory logiczne Materiał pomocniczy do kursu Podstawy programowania Autor: Grzegorz Góralski ggoralski.com Instrukcje wyboru Tworzenie programu, Schematy blokowe, Instrukcje wyboru, Operatory logiczne Być, czy nie być?

Bardziej szczegółowo

5-6. Struktura dokumentu html. 2 Określenie charakteru i tematyki strony. Rodzaje witryn. Projekt graficzny witryny. Opracowanie skryptów

5-6. Struktura dokumentu html. 2 Określenie charakteru i tematyki strony. Rodzaje witryn. Projekt graficzny witryny. Opracowanie skryptów Aplikacje internetowe KL. III Rok szkolny: 013/01 Nr programu: 31[01]/T,SP/MENIS/00.06.1 Okres kształcenia: łącznie ok. 170 godz. lekcyjne Moduł Bok wprowadzający 1. Zapoznanie z programem nauczania i

Bardziej szczegółowo

Programowanie obiektowe

Programowanie obiektowe Programowanie obiektowe Wykład: klasa, obiekt, po co używać klas, właściwości, atrybuty, funkcje, zachowania, metody, przykładowe obiekty, definiowanie klasy, obiektu, dostęp do składników klasy, public,

Bardziej szczegółowo

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

Znaleziony - jeżeli nadawca nie jest znany w obrębie danego fragmentu Utracony - jeżeli odbiorca komunikatu nie jest znany w obrębie danego fragmentu

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

Budowa aplikacji ASP.NET współpracującej z bazą dany do obsługi przesyłania wiadomości

Budowa aplikacji ASP.NET współpracującej z bazą dany do obsługi przesyłania wiadomości Budowa aplikacji ASP.NET współpracującej z bazą dany do obsługi przesyłania wiadomości Rozpoczniemy od zaprojektowania bazy danych w programie SYBASE/PowerDesigner umieszczamy dwie Encje (tabele) prawym

Bardziej szczegółowo

Platformy programistyczne:.net i Java L ABORATORIUM 7,8: HACKATHON - JTTT

Platformy programistyczne:.net i Java L ABORATORIUM 7,8: HACKATHON - JTTT Platformy programistyczne:.net i Java L ABORATORIUM 7,8: HACKATHON - JTTT O co chodzi? - Przypomnienie Hackathon - http://en.wikipedia.org/wiki/hackathon A hackathon is an event in which computer programmers

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

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

Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle

Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle Podyplomowe Studium Informatyki w Bizniesie Wydział Matematyki i Informatyki, Uniwersytet Łódzki specjalność: Tworzenie aplikacji w środowisku Oracle EFEKTY KSZTAŁCENIA Wiedza Absolwent tej specjalności

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

Rysunkowy tutorial Możesz swobodnie dystrybuować ten plik jeśli pozostawisz go w nietkniętym stanie. Możesz także cytować jego fragmenty umieszczając w tekście odnośnik http://mbartyzel.blogspot.com Jak

Bardziej szczegółowo

Java jako język programowania

Java jako język programowania Java jako język programowania Interpretowany programy wykonują się na wirtualnej maszynie (JVM Java Virtual Machine) Składnia oparta o język C++ W pełni zorientowany obiektowo (wszystko jest obiektem)

Bardziej szczegółowo

Dokumentacja aplikacji Szachy online

Dokumentacja aplikacji Szachy online Projekt z przedmiotu Technologie Internetowe Autorzy: Jakub Białas i Jarosław Tyma grupa II, Automatyka i Robotyka sem. V, Politechnika Śląska Przedmiot projektu: Aplikacja internetowa w języku Java Dokumentacja

Bardziej szczegółowo

Logika funkcji. Modelowanie SI - GHJ 1

Logika funkcji. Modelowanie SI - GHJ 1 Logika funkcji precyzyjne i niedwuznaczne definiowanie szczegółów funkcji stosowana w tych przypadkach, w których funkcja jest złożona lub wymaga arbitralnego algorytmu Celem - zrozumienie przez projektanta

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

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

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

Język JAVA podstawy. Wykład 3, część 3. Jacek Rumiński. Politechnika Gdańska, Inżynieria Biomedyczna Język JAVA podstawy Wykład 3, część 3 1 Język JAVA podstawy Plan wykładu: 1. Konstrukcja kodu programów w Javie 2. Identyfikatory, zmienne 3. Typy danych 4. Operatory, instrukcje sterujące instrukcja warunkowe,

Bardziej szczegółowo

LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika

LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika LK1: Wprowadzenie do MS Access Zakładanie bazy danych i tworzenie interfejsu użytkownika Prowadzący: Dr inż. Jacek Habel Instytut Technologii Maszyn i Automatyzacji Produkcji Zakład Projektowania Procesów

Bardziej szczegółowo

Zakres treści Czas. 2 Określenie charakteru i tematyki strony. Rodzaje witryn. Projekt graficzny witryny. Opracowanie skryptów

Zakres treści Czas. 2 Określenie charakteru i tematyki strony. Rodzaje witryn. Projekt graficzny witryny. Opracowanie skryptów Aplikacje internetowe KL. III Rok szkolny: 011/01 Nr programu: 31[01]/T,SP/MENIS/004.06.14 Okres kształcenia: łącznie ok. 180 godz. lekcyjne Wojciech Borzyszkowski Zenon Kreft Moduł Bok wprowadzający Podstawy

Bardziej szczegółowo

Zintegrowane Systemy Zarządzania Biblioteką SOWA1 i SOWA2 ZAMAWIANIE I REZERWOWANIE

Zintegrowane Systemy Zarządzania Biblioteką SOWA1 i SOWA2 ZAMAWIANIE I REZERWOWANIE Zintegrowane Systemy Zarządzania Biblioteką SOWA1 i SOWA2 ZAMAWIANIE I REZERWOWANIE Poznań 2011 Spis treści 1. Zamawianie i rezerwowanie definicja pojęć...3 2. Zasada działania systemu...4 3. Zamawianie

Bardziej szczegółowo

SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD

SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD Dr inż. Jacek WARCHULSKI Dr inż. Marcin WARCHULSKI Mgr inż. Witold BUŻANTOWICZ Wojskowa Akademia Techniczna SPOSOBY POMIARU KĄTÓW W PROGRAMIE AutoCAD Streszczenie: W referacie przedstawiono możliwości

Bardziej szczegółowo