Techniki projektowania wzorce projektowe

Save this PDF as:
 WORD  PNG  TXT  JPG

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

Download "Techniki projektowania wzorce projektowe"

Transkrypt

1 Techniki projektowania wzorce projektowe

2 2 Przykład: Kasa fiskalna Opis dziedziny problemu System jest przeznaczony do obsługi procesu sprzedaży. Podstawowa funkcjonalność systemu obejmuje takie czynności jak: wprowadzanie kodów towarów kupowanych przez klienta, obliczanie kwoty do zapłaty, obsługa wszystkich rodzajów płatności (m.in. gotówka, karta kredytowa). System powinien współpracować z systemami finansowo-księgowymi. Ze względu na zmieniające się przepisy podatkowe system powinien umożliwiać zmianę reguł obliczania podatków. System musi ponadto utrzymywać aktualną bazę dostępnych towarów

3 3 Identyfikacja klas konceptualnych (1) Store reprezentuje sklep. Sklep opisany jest atrybutami oznaczającymi jego nazwę i fizyczną lokalizację (name, address) Register reprezentuje kasę fiskalną, na której dokonywane są transakcje Cashier reprezentuje osobę obsługującą kasę fiskalną Customer reprezentuje klienta dokonującego zakupu

4 4 Identyfikacja klas konceptualnych (2) ProductCatalog reprezentuje katalog produktów oferowanych do sprzedaży ProductDescription reprezentuje opis produktu. Zawiera takie atrybuty jak description (opis produktu) oraz price (cena) Payment reprezentuje płatność. Zawiera atrybut amounttendered do przechowywania zapłaconej kwoty

5 5 Identyfikacja klas konceptualnych (3) Sale reprezentuje bieżącą sprzedaż (i jednocześnie dokument sprzedaży). Zawiera atrybut date do przechowywania daty transakcji oraz atrybut total do przechowywania całkowitej kwoty do zapłaty SaleLineItem reprezentuje jedną pozycję na dokumencie sprzedaży. Zawiera atrybut quantity do przechowywania ilości zakupionego towaru

6 6 Model dziedziny

7 7 Przypadek użycia Przypadek użycia: Obsługa sprzedaży Wyzwalacz: Klient przychodzi do kasy z produktami, które zamierza kupić Scenariusz główny: 1. Kasjer rozpoczyna nowy proces sprzedaży 2. Kasjer skanuje kod towaru 3. System rejestruje pozycje sprzedaży, wyświetla opis produktu, cenę oraz oblicza kwotę do zapłaty 4. Kroki 2-3 są powtarzane dla wszystkich produktów 5. System wyświetla kwotę do zapłaty 6. Kasjer informuje klienta o kwocie do zapłaty 7. Klient za pośrednictwem kasjera dokonuje płatności 8. System rejestruje płatność

8 8 Diagram sekwencji systemowych Główny scenariusz: 1. Kasjer rozpoczyna nowy proces sprzedaży 2. Kasjer skanuje kod towaru 3. System rejestruje pozycje sprzedaży, wyświetla opis produktu, cenę oraz oblicza kwotę do zapłaty 4. Kroki 2-3 są powtarzane dla wszystkich produktów 5. System wyświetla kwotę do zapłaty 6. Kasjer informuje klienta o kwocie do zapłaty 7. Klient za pośrednictwem kasjera dokonuje płatności 8. System rejestruje płatność

9 9 Kontrakty dla operacji systemowych (1) Operacja: MakeNewSale() Warunki początkowe: Istnieje obiekt r klasy Register Warunki końcowe: Utworzono obiekt s klasy Sale Atrybutowi s.datetime przypisano bieżącą datę i czas Utworzono związek pomiędzy obiektem s a obiektem r

10 10 Kontrakty dla operacji systemowych (2) Operacja: EnterItem(itemId, quantity) Warunki początkowe: Istnieje obiekt s klasy Sale oraz obiekt pd klasy ProductDescription Warunki końcowe: Utworzono obiekt sli klasy SaleLineItem Atrybutowi sli.quantity przypisano wartość argumentu quantity Utworzono związek pomiędzy obiektem sli a obiektem s Utworzono związek pomiędzy obiektem sli a obiektem pd

11 11 Kontrakty dla operacji systemowych (3) Operacja: EndSale() Warunki początkowe: Istnieje obiekt s klasy Sale Warunki końcowe: Atrybutowi s.iscomplete przypisano wartość true

12 12 Kontrakty dla operacji systemowych (4) Operacja: MakePayment(amount) Warunki początkowe: Istnieje obiekt s klasy Sale Warunki końcowe: Utworzono obiekt p klasy Payment Atrybutowi p.amounttendered przypisano wartość argumentu amount Utworzono związek pomiędzy obiektem p a obiektem s

13 13 Projektowanie interakcji wg DDD wskazówki Operacja systemowa trafia do jednego z serwisów Do zadań serwisu należy pobranie z repozytorium obiektu biznesowego, którego dotyczy operacja oraz delegowanie wykonania operacji do tegoż obiektu Jeśli operacja nie może być przypisana do jednego obiektu biznesowego, wówczas serwis wykonuje wszystkie czynności wymagane przez operacje

14 14 Projektowanie Stan wyjściowy: Operacje systemowe są specyfikacją zachowania systemu widzianego z poziomu jego klienta (np. interfejsu użytkownika). Kontrakty dla operacji systemowych opisują stan systemu przed i po wykonaniu operacji systemowej Problem do rozwiązania: Jak przypisać odpowiedzialności do poszczególnych klas i zaprojektować interakcje obiektów, aby zrealizować warunki zapisane w kontrakcie?

15 15 Wzorce GRASP GRASP - General Resposibility Assignment Software Patterns GRASP to zbiór kilku wzorców projektowania obiektowego związanych z przypisywaniem odpowiedzialności do klas. Autorem wzorców GRASP jest Craig Larman Każdy ze wzorców GRASP to rodzaj zalecenia projektowego, którego uwzględnienie z reguły prowadzi do lepszego rozwiązanie problemu

16 16 Wzorce GRASP Ekspert (ang. Expert) Kreator (ang. Creator) Kontroler (ang. Contoller) Luźne sprzężenie (ang. Low Coupling) Wysoka spójność (ang. High Cohesion) Pure Fabrication Polimorfizm (ang. Polimorphism)

17 17 Wzorce GRASP - Kreator Problem: Która klasa powinna być odpowiedzialna za tworzenie nowych instancji danej klasy? Rozwiązanie: Przypisz klasie B odpowiedzialność tworzenia nowych instancji klasy A, jeśli zachodzi jeden lub kilka z poniższych warunków: Klasa B zawiera (agreguje) obiekty klasy A Klasa B rejestruje obiekty klasy A Klasa B intensywnie używa obiekty klasy A Klasa B posiada dane niezbędne do zainicjalizowania obiektów klasy A

18 18 Wzorce GRASP Kreator Im więcej z powyższych punktów jest spełnione, tym mocniejsze jest uzasadnienie dla wyboru klasy B jako kreatora obiektów klasy A W sytuacji, gdy kilka klas kandyduje do bycia kreatorem obiektów klasy A, wówczas wybieramy te klasę, która spełnia najwięcej z powyższych warunków

19 19 Kreator - przykład Problem: Która klasa powinna być odpowiedzialna za utworzenie obiektu typu SalesLineItem? Kandydaci: Sale zawiera obiekty typu SalesLineItems używa obiekty typu SalesLineItems posiada niezbędne dane (quantity) do zainicjowania obiektu typu SalesLineItems model dziedziny (fragment ) ProductDescription - jest opisem dla obiektów SalesLineItems

20 20 Kreator - przykład Rozwiązanie: Na podstawie wzorca Kreator obiekty klasy SalesLineItem powinny być tworzone przez obiekt klasy Sale

21 21 Kreator - przykład Elementy modelu projektowego: kierunek nawigacji od Register do Sale atrybut currentsale w klasie Register realizacja związku Register Sale kierunek nawigacji od Sale do SalesLineItem atrybut lineitems w klasie Sale realizacja związku Sale - SalesLineItems Model projektowy (fragment)

22 22 Wzorce GRASP - Ekspert Problem: Jak brzmi najbardziej ogólna zasada przypisywania odpowiedzialności? Której klasie przypisać daną odpowiedzialność? Rozwiązanie: Przypisz odpowiedzialność klasie, która ma niezbędne informacje, aby ją zrealizować

23 23 Wzorce GRASP - Ekspert Wzorzec Ekspert jest jedną z elementarnych zasad projektowania obiektowego Mimo iż powyższa zasada brzmi jak coś oczywistego, jej zastosowanie może nieraz nastręczać trudności Potencjalne problemy z poprawnym stosowaniem wzorca ekspert wynikają najczęściej z rozproszenia informacji po wielu różnych klasach

24 24 Wzorce GRASP - Ekspert Do poprawnego zastosowania wzorca Ekspert w przypadku rozproszenia informacji konieczny jest podział odpowiedzialności pomiędzy wszystkie klasy posiadające częściowe informacje Każda z klas posiadających częściowe informacje jest tzw. częściowym ekspertem Innym problemem związanym ze wzorcem Ekspert jest naturalna skłonność do przypisywania odpowiedzialności kierując się zasadą, by klasy systemu informatycznego zachowywały się podobnie jak klasy w świecie rzeczywistym, co nie zawsze jest dobrym rozwiązaniem

25 25 Ekspert - przykład Problem: Która klasa powinna być odpowiedzialna za obliczenie kwoty do zapłaty Kandydaci: Sale zawiera atrybut total do przechowywania kwoty do zapłaty SalesLineItem zawiera atrybut quantity niezbędny do obliczenia kwoty do zapłaty za każdy z produktów z osobna model dziedziny (fragment ) ProductDescription zawiera atrybut price z bieżącą ceną każdego z produktów

26 26 Ekspert - przykład Rozwiązanie: Klasy SalesLineItem i ProductDescription są częściowymi ekspertami - zawierają jedynie cześć informacji niezbędnej do obliczenia całkowitej kwoty do zapłaty Do obliczenia całkowitej kwoty do zapłaty należy zaprojektować odpowiednią interakcję pomiędzy wszystkimi klasami posiadającymi cząstkową informację

27 27 Ekspert - przykład Elementy modelu projektowego: kierunek nawigacji od SalesLineItem do ProductDescription atrybut description w klasie SalesLineItem realizacja związku SalesLineItem - ProductDescription Operacja GetTotal() w klasie Sale Operacja GetSubtotal() w klasie SalesLineItem Model projektowy (fragment) Operacja GetPrice() w klasie ProductDescription

28 28 Wzorce GRASP Kontroler Problem: Która klasa spoza interfejsu użytkownika powinna jako pierwsza obsługiwać operacje systemową? Rozwiązanie: Przypisz odpowiedzialność klasie, dla której prawdziwe jest jedno z poniższych stwierdzeń: reprezentuje cały system, podsystem, obiekt leżący najwyżej w hierarchii (ang. root object) reprezentuje przypadek użycia, w którym operacja systemowa ma miejsce

29 29 Wzorce GRASP Kontroler Kontroler reprezentujący cały system, podsystem itp. pełni role fasady dla całej warstwy logiki biznesowej Na ogół kontroler nie posiada wystarczającej wiedzy, aby kompletnie obsłużyć żądanie, stąd jego praca polega na znalezieniu odpowiedniego obiektu z warstwy logiki biznesowej i przekazaniu do niego sterowania (delegacja) Kontroler typu fasada stosuje się w niewielkich systemach, gdzie nie ma zbyt wielu operacji systemowych Jeśli w systemie jest dużo operacji systemowych, wówczas stosuje się kontrolery reprezentujące pojedyncze przypadki użycia, bądź też grupujące kilka przypadków użycia

30 30 Wzorce GRASP Kontroler Kontrolery reprezentujące przypadki użycia są w istocie w istocie tworami sztucznymi, nie mającymi odpowiednika w dziedzinie problemu Kontrolera GRASP nie należy mylić z kontrolerem ze wzorca Model-Widok- Kontroler, który jest elementem warstwy interfejsu użytkownika Kontroler GRASP należy do warstwy logiki biznesowej (znajduje się na granicy tej warstwy)

31 ROZWIĄZANIE I KONTROLER TYPU FASADA Klasy pełniące role kontrolerów Kontroler Zarządzanie wykonywaniem operacji systemowych Przechowywanie i udostępnianie obiektów warstwy biznesowej warstwa aplikacji warstwa logiki biznesowej 31

32 KONTROLER TYPU FASADA CHARAKTERYSTYKA Kontroler reprezentujący cały system, podsystem itp. pełni role fasady dla całej warstwy logiki biznesowej W zakresie odpowiedzialności kontrolera typu fasada leży: koordynacja działań związanych z wykonywaniem operacji systemowych przechowywanie i udostępnianie obiektów warstwy logiki biznesowej Kontroler typu fasada stosuje się w niewielkich systemach, gdzie nie ma zbyt wielu operacji systemowych 32

33 ROZWIĄZANIE II KONTROLER TYPU PRZYPADEK UŻYCIA Klasy pełniące role kontrolerów Kontroler Zarządzanie wykonywaniem operacji systemowych Repozytorium warstwa aplikacji warstwa logiki biznesowej warstwa infrastruktury Przechowywanie i udostępnianie obiektów warstwy biznesowej 33

34 KONTROLER TYPU PRZYPADEK UŻYCIA - CHARAKTERYSTYKA W zakresie odpowiedzialności kontrolera leży koordynacja działań związanych z wykonywaniem operacji systemowych Klasa Repozytorium jest odpowiedzialna za przechowywanie i udostępnianie obiektów warstwy biznesowej Kontrolery reprezentujące pojedyncze przypadki użycia (lub kilka przypadków użycia) stosuje się w bardziej złożonych systemach, gdzie występuje większa liczba operacji systemowych i/lub wymagane jest zapisywanie i odtwarzanie stanu systemu po wykonaniu pewnego ciągu operacji systemowych 34

35 REPOZYTORIUM Zasada Persistence Ignorance System należy projektować w sposób niezależny od infrastruktury, w tym od wszystkich mechanizmów dostępu do danych Cała logika związana z dostępem do bazy danych w celu odtworzenia, zapisania lub wyszukania obiektów biznesowych zaszyta jest w Repozytorium Z punktu widzenia warstwy logiki biznesowej Repozytorium pełni rolę kolekcji obiektów biznesowych 35

36 REPOZYTORIUM PRZYKŁAD Repozytorium wydarzeń Wydarzenie Alarm Uczestnictwo Repozytorium osób Osoba Adres 36

37 37 Kontroler - przykład Problem: Która klasa jako pierwsza obsługuje operacje systemowe takie jak: MakeNewSale(), EnterItem(), EndSale(), MakePayment()? model dziedziny (fragment) Kandydaci: Store - reprezentuje cały system Register - reprezentuje podsystem ProcessSaleHandler klasa utworzona specjalnie w tym celu

38 38 Kontroler - przykład Rozwiązanie 1: funkcje kontrolera pełni klasa Register. Jest to kontroler typu fasada - stosuje się w sytuacji, gdy liczba operacji systemowych jest nieduża Rozwiązanie 2: funkcje kontrolera pełni specjalnie w tym celu utworzona klasa ProcessSaleHandler. Jest to kontroler typu przypadek użycia - stosuje się w sytuacji, gdy liczba operacji systemowych jest znaczna Komentarz: Obydwa rozwiązania są do zaakceptowania. Niemniej praktyka pokazuje, że liczba identyfikowanych operacji systemowych w kolejnych iteracjach projektu wzrasta, stąd preferowane są rozwiązania z dedykowanym kontrolerem (rozwiązanie 2)

39 39 Kontroler - przykład Elementy modelu projektowego: Operacja MakeNewSale() w klasie Register Operacja EnterItem() w klasie Register Operacja MakePayment() w klasie Register Model projektowy (fragment) Operacja EndSale() w klasie Register

40 40 Sprzężenie Sprzężenie (ang. coupling) miara wzajemnej zależności obiektów Niski poziom sprzężeń: Stosunkowo niewielka liczba związków między klasami Możliwość grupowania klas ściślej ze sobą powiązanych Wysoki poziom sprzężeń: Duża liczba związków między klasami Brak możliwości grupowania klas wszystkie klasy są ze sobą ściśle powiązane

41 41 Wzorce GRASP - Luźne sprzężenie Problem: W jaki sposób spowodować, żeby zmiany we fragmencie modelu jak najmniej wpływały na pozostała część modelu? Co należy czynić, aby zwiększyć możliwość ponownego wykorzystania kodu? Rozwiązanie: Przypisuj odpowiedzialności w taki sposób, aby ograniczyć liczbę związków między klasami

42 42 Wzorce GRASP - Luźne sprzężenie Model zawierający dużo związków między klasami charakteryzuje wiele negatywnych cech: zmiany w jednej klasie implikują zmiany w innych klasach problem ze zrozumieniem modelu trudności w ponownym użyciu (wymaga to użycia wszystkich klas powiązanych) Z drugiej strony związki między klasami są nieodłączną cechą każdego modelu obiektowego - umożliwiają realizację zasady podziału odpowiedzialności Postulat luźnych sprzężeń nie sugeruje w żaden sposób usunięcia związków między klasami. Sugeruje jedynie, że jeśli istnieje możliwość zrealizowania określonej funkcjonalności bez zwiększania poziomu zależności, to należy taką opcję wybrać

43 43 Luźne sprzężenie - przykład Problem: Która klasa powinna być odpowiedzialna za utworzenie obiektu typu Payment i powiązanie go z obiektem typu Sale? Zaproponować rozwiązanie w oparciu o zasadę Luźne sprzężenie model dziedziny (fragment ) Kandydaci: Register Sale

44 44 Luźne sprzężenie - przykład nowy związek Rozwiązanie 1: Klasa Register jest odpowiedzialna za utworzenie obiektu klasy Payment (zastosowano wzorzec Kreator - w świecie rzeczywistym kasa fiskalna rejestruje płatności) Klasa Register odpowiada za utworzenie powiązania pomiędzy obiektem klasy Sale i obiektem klasy Payment (metoda AddPayment()) Wniosek: Rozwiązanie 1 zwiększa liczbę związków między klasami - powstał nowy związek pomiędzy klasą Register a klasą Payment

45 45 Luźne sprzężenie - przykład Rozwiązanie 2: (preferowane) Klasa Register deleguje do klasy Sale utworzenie obiektu klasy Payment Klasa Sale odpowiada za utworzenie obiektu klasy Payment i utworzenie powiązania pomiędzy obiektem klasy Sale i nowo utworzonym obiektem klasy Payment Wniosek: Rozwiązanie 2 nie zwiększa liczby związków między klasami - rozwiązanie preferowane z punktu widzenia zasady Luźne sprzężenie

46 46 Luźne sprzężenie - przykład Elementy modelu projektowego: kierunek nawigacji od Sale do Payment atrybut payment w klasie Sale realizacja związku Sales - Payment Operacja MakePayment() w klasie Sale

47 47 Spójność Spójność (ang. cohession) miara wzajemnego zintegrowania metod składowych klas Niski poziom spójności: Klasa A wykonuje samodzielnie wszystkie operacje Duża liczba operacji w klasie A Średni poziom spójności Klasa A deleguje odpowiedzialność do innych klas Klasa A koordynuje wszystkie operacje Wysoki poziom spójności Klasa A deleguje odpowiedzialność do innych klas Operacje w klasach pomocniczych również delegują część odpowiedzialności

48 48 Wzorce GRASP Wysoka spójność Problem: Jak sprawić, aby klasa była łatwa do zarządzania, zorientowana na jedno określone zadanie, a jej kod był zrozumiały? Rozwiązanie: Przypisz odpowiedzialność w taki sposób, aby spójność była jak największa

49 49 Wzorce GRASP Wysoka spójność Klasa, która ma zbyt wiele niezwiązanych ze sobą odpowiedzialności posiada niską spójność (kohezję) Niską kohezją charakteryzuje się również klasa, która co prawda odpowiada za jedno zadanie, ale zadanie to jest mocno skomplikowane i jest realizowane samodzielnie przez jedną klasę Aby poprawić kohezje w tym przypadku należy realizację tego zadania rozłożyć na kilka współpracujących ze sobą klas

50 50 Wzorce GRASP Wysoka spójność Klasa o wysokiej spójności to klasa skupiona na realizacji ściśle określonej funkcjonalności, posiłkująca się innymi klasami w sytuacji, gdy nie posiada wystarczających informacji lub realizacja funkcjonalności jest złożonym procesem Klasy o wysokiej kohezji to klasy, które posiadają stosunkowo niewiele metod, metody są ze sobą powiązane, kod metod jest krótki i czytelny, a w sytuacji bardziej złożonej logiki następuje delegacja odpowiedzialności do klas współpracujących

51 51 Wysoka spójność- przykład Problem: Która klasa powinna być odpowiedzialna za utworzenie obiektu typu Payment i powiązanie go z obiektem typu Sale? Zaproponować rozwiązanie w oparciu o zasadę Wysoka spójność model dziedziny (fragment ) Kandydaci: Register Sale

52 52 Wysoka spójność - przykład Rozwiązanie 1: Klasa Register jest odpowiedzialna za utworzenie obiektu klasy Payment (zastosowano wzorzec Kreator - w świecie rzeczywistym kasa fiskalna rejestruje płatności) Klasa Register odpowiada również za utworzenie powiązania pomiędzy obiektem klasy Sale i obiektem klasy Payment (metoda AddPayment()) Wniosek: Rozwiązanie 1 zwiększa zakres odpowiedzialność klasy Register. W tym konkretnym przypadku jest do zaakceptowania, niemniej może prowadzić do obniżenia spójności klasy Register (duża liczba odpowiedzialności)

53 53 Wysoka spójność - przykład Rozwiązanie 2 (preferowane): Klasa Register deleguje do klasy Sale utworzenie obiektu klasy Payment Klasa Sale odpowiada za utworzenie obiektu klasy Payment i utworzenie powiązania pomiędzy obiektem klasy Sale i nowo utworzonym obiektem klasy Payment Wniosek: Rozwiązanie 2 nie zwiększa zakresu odpowiedzialności klasy Register. Klasa Register deleguje wykonanie określonych czynności do klasy Sale - rozwiązanie preferowane z punktu widzenia zasady Wysoka spójność

54 54 Realizacja operacji MakeNewSale() Operacja: MakeNewSale() Warunki początkowe: Istnieje obiekt r klasy Register Warunki końcowe: Utworzono obiekt s klasy Sale Atrybutowi s.datetime przypisano bieżącą datę i czas Utworzono związek pomiędzy obiektem s a obiektem r Kontroler Kreator

55 55 Realizacja operacji EnterItem() Operacja: EnterItem(itemId, quantity) Warunki początkowe: Istnieje obiekt s klasy Sale oraz obiekt pd klasy ProductDescription Kontroler Warunki końcowe: Utworzono obiekt sli klasy SaleLineItem Atrybutowi sli.quantity przypisano wartość argumentu quantity Utworzono związek pomiędzy obiektem sli a obiektem s Utworzono związek pomiędzy obiektem sli a obiektem pd Kreator Ekspert

56 56 Realizacja operacji MakePayment() Operacja: MakePayment(amount) Warunki początkowe: Istnieje obiekt s klasy Sale Warunki końcowe: Utworzono obiekt p klasy Payment Atrybutowi p.amounttendered przypisano wartość argumentu amount Utworzono związek pomiędzy obiektem p a obiektem s Kontroler Kreator

57 57 Realizacja operacji EndSale() Operacja: EndSale() Warunki początkowe: Istnieje obiekt s klasy Sale Warunki końcowe: Atrybutowi s.iscomplete przypisano wartość true Kontroler Ekspert

58 58 Model projektowy wersja finalna

59 59 Literatura Craig Larman: Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development

Projektowanie Zorientowane na Dziedzinę. ang. Domain Driven Design

Projektowanie Zorientowane na Dziedzinę. ang. Domain Driven Design Projektowanie Zorientowane na Dziedzinę ang. Domain Driven Design 2 Projektowanie Stan posiadania Przypadki użycia Model dziedziny Operacje systemowe Kontrakty dla operacji systemowych Problemy do rozwiązania

Bardziej szczegółowo

Analiza i projektowanie obiektowe 2016/2017. Wykład 8: Przypisywanie obiektom odpowiedzialności (2)

Analiza i projektowanie obiektowe 2016/2017. Wykład 8: Przypisywanie obiektom odpowiedzialności (2) Analiza i projektowanie obiektowe 2016/2017 Wykład 8: Przypisywanie obiektom odpowiedzialności (2) Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Wzorce

Bardziej szczegółowo

Wykład 5. Inżynieria oprogramowania MIS s MIO s MIS n Listopad 2014

Wykład 5. Inżynieria oprogramowania MIS s MIO s MIS n Listopad 2014 Wykład 5 Inżynieria oprogramowania MIS-1-502-s MIO-1-505-s MIS-1-505-n Listopad 2014 Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 5.1 Agenda 1 2 3 5.2 Co to jest G.R.A.S.P.?

Bardziej szczegółowo

Świat rzeczywisty i jego model

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

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej

Analiza i projektowanie obiektowe 2017/2018. Wykład 3: Model wiedzy dziedzinowej Analiza i projektowanie obiektowe 2017/2018 Wykład 3: Model wiedzy dziedzinowej Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Model wiedzy dziedzinowej

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

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

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA

KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,

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

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

Projektowanie obiektowe Wzorce projektowe. Gang of Four Wzorce odpowiedzialności

Projektowanie obiektowe Wzorce projektowe. Gang of Four Wzorce odpowiedzialności Projektowanie obiektowe Wzorce projektowe Gang of Four Wzorce odpowiedzialności 1 Roadmap Singleton Observer Mediator Proxy Flyweight 2 Wzorce odpowiedzialności Udostępniają techniki centralizacji, delegowania

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

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji

Analiza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji 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ół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

Projektowanie obiektowe oprogramowania Wykład 4 - SOLID GRASP Wiktor Zychla 2012

Projektowanie obiektowe oprogramowania Wykład 4 - SOLID GRASP Wiktor Zychla 2012 Projektowanie obiektowe oprogramowania Wykład 4 - SOLID GRASP Wiktor Zychla 2012 1 Taksonomia RDD RDD = Responsibility-Driven Development, przemyślane projektowanie obiektowe Wzorce aplikacyjne Wzorce

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

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

Projektowanie logiki aplikacji

Projektowanie logiki aplikacji Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie logiki aplikacji Zagadnienia Rozproszone przetwarzanie obiektowe (DOC) Model klas w projektowaniu logiki aplikacji Klasy encyjne a klasy

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

Wstęp [2/2] Wbrew częstemu przekonaniu, nie są one gotowymi rozwiązaniami, to tylko półprodukty rozwiązania.

Wstęp [2/2] Wbrew częstemu przekonaniu, nie są one gotowymi rozwiązaniami, to tylko półprodukty rozwiązania. Adrian Skalczuk Szymon Kosarzycki Spis Treści Wstęp [1/2] Wzorce projektowe są nieodłącznym przyjacielem programisty pozwalają pisać czystszy kod, łatwiejszy do zrozumienia przez innych i zapewniają pewien

Bardziej szczegółowo

Inżynieria oprogramowania II

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

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN

REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN REQB POZIOM PODSTAWOWY PRZYKŁADOWY EGZAMIN Podziękowania REQB Poziom Podstawowy Przykładowy Egzamin Dokument ten został stworzony przez główny zespół Grupy Roboczej REQB dla Poziomu Podstawowego. Tłumaczenie

Bardziej szczegółowo

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

Diagramy przypadków użycia. WYKŁAD Piotr Ciskowski Diagramy przypadków użycia WYKŁAD Piotr Ciskowski Diagram przypadków użycia definiowanie wymagań systemowych graficzne przedstawienie przypadków użycia, aktorów, związków między nimi występujących w danej

Bardziej szczegółowo

Diagramy przypadków użycia - MS Visio

Diagramy przypadków użycia - MS Visio Diagramy przypadków użycia - MS Visio LABORKA Piotr Ciskowski zad. 1. Sklep internetowy - diagram przypadków użycia (Visio) o przykład z: Wrycza i in., UML 2.x. Ćwiczenia zaawansowane o narzędzie: MS Visio

Bardziej szczegółowo

Wzorce projektowe cz. II. Wzorce projektowe cz. II 1/35

Wzorce projektowe cz. II. Wzorce projektowe cz. II 1/35 Wzorce projektowe cz. II Wzorce projektowe cz. II 1/35 Wzorce projektowe cz. II 2/35 Iterator Przeznaczenie Wzorzec zapewnia sekwencyjny dostęp do elementów obiektu zagregowanego bez ujawniania jego reprezentacji

Bardziej szczegółowo

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas

Analiza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas 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ółowo

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania

Technologie obiektowe. Plan. Ewolucja technik wytwarzania oprogramowania Literatura Marek Kisiel-Dorohinicki doroh@agh.edu.pl Brett D. McLaughlin, Gary Pollice, David West Head First Object-Oriented Analysis and Design Martin Fowler UML Distilled ( UML w kropelce ) Grady Booch,

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

Zagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)

Zagadnienia (1/3) 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ółowo

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),

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 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity

Bardziej szczegółowo

Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4

Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4 Utrwalanie danych zastosowanie obiektowego modelu danych warstwy biznesowej do generowania schematu relacyjnej bazy danych Informacje wstępne Autor Zofia Kruczkiewicz Wzorce oprogramowania 4 1. Relacyjne

Bardziej szczegółowo

Zofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1

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

Inżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji

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

Jerzy Skalski s9473, grupa WIs I.6-11c. System wspierający obsługę klienta dla firm sprzedających na Allegro

Jerzy Skalski s9473, grupa WIs I.6-11c. System wspierający obsługę klienta dla firm sprzedających na Allegro Jerzy Skalski s9473, grupa WIs I.6-11c System wspierający obsługę klienta dla firm sprzedających na Allegro 1. WYMAGANIA UŻYTKOWNIKA Użytkownicy systemu: System powinien przechowywać informacje dotyczące:

Bardziej szczegółowo

Modelowanie i analiza systemów informatycznych Spis treści

Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych Spis treści Modelowanie i analiza systemów informatycznych...1 Ćwiczenia 1...2 Wiadomości podstawowe:...2 Ćwiczenia...8 Ćwiczenia 1 Wiadomości podstawowe:

Bardziej szczegółowo

Procesowa specyfikacja systemów IT

Procesowa specyfikacja systemów IT Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office

Bardziej szczegółowo

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia

Analiza i projektowanie obiektowe 2015/2016. Wykład 2: Przypadki użycia Analiza i projektowanie obiektowe 2015/2016 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.

Bardziej szczegółowo

Feature Driven Development

Feature Driven Development Feature Driven Development lekka metodyka tworzenia oprogramowania Kasprzyk Andrzej IS II Wstęp Feature Driven Development (FDD) to metodyka tworzenia oprogramowania, która wspomaga zarządzanie fazami

Bardziej szczegółowo

Zasady projektowania obiektowego

Zasady projektowania obiektowego Zasady projektowania obiektowego Nie każdy, kto ma młotek, może nazywać się architektem. wzorce projektowe UML SOLID Robert C. Martin Strategia w metodyce Agile GRASP Responsibility Driven-Design 2 S

Bardziej szczegółowo

Wykład 4. Projektowanie. MIS n Inżynieria oprogramowania Październik 2014

Wykład 4. Projektowanie. MIS n Inżynieria oprogramowania Październik 2014 Wykład 4 MIS-1-505-n Inżynieria oprogramowania Październik 2014 Metody Kazimierz Michalik Akademia Górniczo-Hutnicza im. S. Staszica w Krakowie 4.1 Agenda 1 2 3 Metody Metody 4 5 4.2 Implementacja Metody

Bardziej szczegółowo

KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH

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

BAZY DANYCH MAKRA I PRZYCISKI. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza

BAZY DANYCH MAKRA I PRZYCISKI. Microsoft Access. Adrian Horzyk. Akademia Górniczo-Hutnicza BAZY DANYCH Microsoft Access MAKRA I PRZYCISKI Adrian Horzyk Akademia Górniczo-Hutnicza Wydział Elektrotechniki, Automatyki, Informatyki i Inżynierii Biomedycznej Katedra Automatyki i Inżynierii Biomedycznej

Bardziej szczegółowo

Projektowanie interakcji. Jarosław Kuchta

Projektowanie interakcji. Jarosław Kuchta Projektowanie interakcji Jarosław Kuchta Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania. Interakcja występuje w kontekście

Bardziej szczegółowo

Projektowanie obiektowe Wzorce projektowe. Gang of Four Strukturalne wzorce projektowe (Wzorce interfejsów)

Projektowanie obiektowe Wzorce projektowe. Gang of Four Strukturalne wzorce projektowe (Wzorce interfejsów) Projektowanie obiektowe Wzorce projektowe Gang of Four Strukturalne wzorce projektowe (Wzorce interfejsów) 1 Roadmap Adapter Bridge Composite Facade 2 Pojęcia obiekt interfejs typ klasa 3 Co to jest delegacja?

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

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

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji

Diagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury

Bardziej szczegółowo

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty

Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty Karta opisu przedmiotu Zaawansowane techniki analizy systemowej oparte o modelowanie warsztaty przedmiotu Stopień studiów i forma: Rodzaj przedmiotu Kod przedmiotu Grupa kursów Zaawansowane techniki analizy

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

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia

Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia Instrukcja 3 Laboratoria 3, 4 Specyfikacja wymagań funkcjonalnych za pomocą diagramu przypadków użycia 1 Cel laboratoriów: Specyfikacja wymagań, zdefiniowanych w ramach laboratorium 2 (wg instrukcji 2),

Bardziej szczegółowo

MVVM Light Toolkit. Julita Borkowska

MVVM Light Toolkit. Julita Borkowska MVVM Light Toolkit Julita Borkowska Czym jest MVVM Light Toolkit? MVVM Light Toolkit został stworzony w 2009 roku przez Laurenta Bugnion. Jest to biblioteka dostarczająca zestaw komponentów pomocnych podczas

Bardziej szczegółowo

Aplikacja (oprogramowanie) będzie umożliwiać przygotowanie, przeprowadzenie badania oraz analizę wyników według określonej metody.

Aplikacja (oprogramowanie) będzie umożliwiać przygotowanie, przeprowadzenie badania oraz analizę wyników według określonej metody. Załącznik nr 1 Specyfikacja przedmiotu zamówienia Aplikacja (oprogramowanie) będzie umożliwiać przygotowanie, przeprowadzenie badania oraz analizę wyników według określonej metody. Słowniczek pojęć Badanie

Bardziej szczegółowo

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Projektowanie architektury systemu rozproszonego. Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie architektury systemu rozproszonego Jarosław Kuchta Zagadnienia Typy architektury systemu Rozproszone przetwarzanie obiektowe Problemy globalizacji Problemy ochrony Projektowanie architektury

Bardziej szczegółowo

Diagram wdrożenia. Rys. 5.1 Diagram wdrożenia.

Diagram wdrożenia. Rys. 5.1 Diagram wdrożenia. Diagram wdrożenia Zaprojektowana przez nas aplikacja bazuje na architekturze client-server. W tej architekturze w komunikacji aplikacji klienckiej z bazą danych pośredniczy serwer aplikacji, który udostępnia

Bardziej szczegółowo

Projektowanie obiektowe Wzorce projektowe

Projektowanie obiektowe Wzorce projektowe Projektowanie obiektowe Wzorce projektowe Gang of Four Kreacyjne wzorce projektowe (wzorce konstrukcyjne) 1 Roadmap Memento Factory Method Abstract Factory Prototype Builder 2 Wzorce konstrukcyjne wzorce

Bardziej szczegółowo

Wzorce projektowe i refaktoryzacja

Wzorce projektowe i refaktoryzacja Wzorce projektowe i refaktoryzacja Paweł Kozioł p.koziol@students.mimuw.edu.pl 18.01.2005 Moja praca magisterska Narzędzie dla środowiska Eclipse wspierające stosowanie wzorców projektowych J2EE Prowadzący:

Bardziej szczegółowo

Wypożyczalnia VIDEO. Technologie obiektowe

Wypożyczalnia VIDEO. Technologie obiektowe Wypożyczalnia VIDEO Jest to program do obsługi wypożyczalni i wypożyczeń klientów. Głównym zadaniem programu jest zarządzanie wypożyczeniami i drukowanie potwierdzenia wypożyczenia oraz naliczenie punktów

Bardziej szczegółowo

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych

Modelowanie klas i obiektów. Jarosław Kuchta Projektowanie Aplikacji Internetowych Modelowanie klas i obiektów Jarosław Kuchta Podstawowe pojęcia (1) Byt, encja (entity) coś co istnieje, posiada własne cechy i wyodrębnioną tożsamość (identity); bytem może być rzecz, osoba, organizacja,

Bardziej szczegółowo

SPECYFIKACJA WYMAGAŃ

SPECYFIKACJA WYMAGAŃ SPECYFIKACJA WYMAGAŃ Autorzy: Wersja: 2 Historia zmian dokumentu Osoba

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w menadżerze sprzedaży BaseLinker (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w menadżerze sprzedaży BaseLinker (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w menadżerze sprzedaży BaseLinker (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to dedykowane jest internetowemu menadżerowi sprzedaży BaseLinker.

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

Analiza i projektowanie obiektowe 2016/2017. Wykład 11: Zaawansowane wzorce projektowe (1)

Analiza i projektowanie obiektowe 2016/2017. Wykład 11: Zaawansowane wzorce projektowe (1) Analiza i projektowanie obiektowe 2016/2017 Wykład 11: Zaawansowane wzorce projektowe (1) Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Wzorce projektowe

Bardziej szczegółowo

problem w określonym kontekście siły istotę jego rozwiązania

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

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym RedCart (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym RedCart (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym RedCart (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to dedykowane jest sklepom internetowych działającym na platformie

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to przeznaczone jest dla właścicieli sklepów internetowych opartych

Bardziej szczegółowo

Projektowanie obiektowe oprogramowania Wykład 2 - Unified Process Wiktor Zychla 2013

Projektowanie obiektowe oprogramowania Wykład 2 - Unified Process Wiktor Zychla 2013 Projektowanie obiektowe oprogramowania Wykład 2 - Unified Process Wiktor Zychla 203 Unified Process Rama organizacji procesu wytwarzania oprogramowania. Posiada wyodrębionie fazy inicjowania, projektowania,

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

Wzorce projektowe. dr inż. Marcin Pietroo

Wzorce projektowe. dr inż. Marcin Pietroo Wzorce projektowe dr inż. Marcin Pietroo Wzorce projektowe Wzorzec projektowy (ang. design pattern) w inżynierii oprogramowania, rozwiązanie często pojawiających się, powtarzalnych problemów projektowych.

Bardziej szczegółowo

Wzorce projektowe. dr inż. Marcin Pietroo

Wzorce projektowe. dr inż. Marcin Pietroo Wzorce projektowe dr inż. Marcin Pietroo Adapter - strukturalny wzorzec projektowy, którego celem jest umożliwienie współpracy dwóm klasom o niekompatybilnych interfejsach - adapter przekształca interfejs

Bardziej szczegółowo

Faza analizy (modelowania) Faza projektowania

Faza analizy (modelowania) Faza projektowania Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań

Bardziej szczegółowo

Wzorce logiki dziedziny

Wzorce logiki dziedziny Wzorce logiki dziedziny 1. Wzorce logiki dziedziny skrypt transakcji (Transaction Script), brama tabeli (Table Data Gateway), model dziedziny (Domain model), strategia (Strategy), moduł tabeli (Table Module),

Bardziej szczegółowo

Dla kas Nano E w wersjach od 3.02 oraz Sento Lan E we wszystkich wersjach.

Dla kas Nano E w wersjach od 3.02 oraz Sento Lan E we wszystkich wersjach. INSTRUKCJA KONFIGURACJI USŁUGI BUSOWEJ PRZY UŻYCIU PROGRAMU NSERWIS. Dla kas Nano E w wersjach od 3.02 oraz Sento Lan E we wszystkich wersjach. Usługa busowa w kasach fiskalnych Nano E oraz Sento Lan E

Bardziej szczegółowo

Analiza i projektowanie obiektowe 2017/2018. Wykład 2: Przypadki użycia

Analiza i projektowanie obiektowe 2017/2018. Wykład 2: Przypadki użycia Analiza i projektowanie obiektowe 2017/2018 Wykład 2: Przypadki użycia Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Czym są przypadki użycia. 2.

Bardziej szczegółowo

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017

Kurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017 Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy

Bardziej szczegółowo

DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL

DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL Projektowanie Systemów Komputerowych Laboratoria/Projekty Krzysztof Regulski AGH, WIMiIP DIAGRAM PRZYPADKÓW UŻYCIA USE CASE MODEL 1) Zastosowanie Jedną ze stosowanych metodologii prowadzenia projektów

Bardziej szczegółowo

PRZEWODNIK PO PRZEDMIOCIE

PRZEWODNIK PO PRZEDMIOCIE Nazwa przedmiotu: Kierunek: Inżynieria Biomedyczna Rodzaj przedmiotu: obowiązkowy moduł specjalności informatyka medyczna Rodzaj zajęć: wykład, laboratorium PROGRAMOWANIE OBIEKTOWE Object-Oriented Programming

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

UML 1 diagramy interakcji

UML 1 diagramy interakcji UML 1 diagramy interakcji Materiał na ćwiczenia z rysowania diagramów interakcji wchodzących w skład UMLa. Forma ćwiczeń. Każdy ze studentów otrzymuje materiały w postaci referencji do odpowiednich diagramów

Bardziej szczegółowo

Podręcznik Integracji

Podręcznik Integracji Podręcznik Integracji Spis treści 1. Integracja oferty... 3 1.1. Samodzielne wprowadzanie oferty sklepu... 3 1.2. Automatyczne wprowadzanie oferty z pliku XML... 3 1.3. Cyklicznie pobieranie oferty ze

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento 2 (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento 2 (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym Magento 2 (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to dedykowane jest sklepom internetowych zbudowanym w oparciu

Bardziej szczegółowo

Wzorce projektowe Michał Węgorek

Wzorce projektowe Michał Węgorek Wzorce projektowe Michał Węgorek Wzorce projektowe Plan prezentacji Co to jest i po co to jest? Podział Najczęściej spotykane wzorce Bibliografia Co to jest i po co to jest? Wzorzec projektowy (ang. Design

Bardziej szczegółowo

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD

Projektowanie systemów informatycznych. Roman Simiński siminskionline.pl. Modelowanie danych Diagramy ERD Projektowanie systemów informatycznych Roman Simiński roman.siminski@us.edu.pl siminskionline.pl Modelowanie danych Diagramy ERD Modelowanie danych dlaczego? Od biznesowego gadania do magazynu na biznesowe

Bardziej szczegółowo

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi

Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Problemy niezawodnego przetwarzania w systemach zorientowanych na usługi Jerzy Brzeziński, Anna Kobusińska, Dariusz Wawrzyniak Instytut Informatyki Politechnika Poznańska Plan prezentacji 1 Architektura

Bardziej szczegółowo

Faza Określania Wymagań

Faza Określania Wymagań Faza Określania Wymagań Celem tej fazy jest dokładne określenie wymagań klienta wobec tworzonego systemu. W tej fazie dokonywana jest zamiana celów klienta na konkretne wymagania zapewniające osiągnięcie

Bardziej szczegółowo

Paweł Kurzawa, Delfina Kongo

Paweł Kurzawa, Delfina Kongo Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management

Bardziej szczegółowo

Charakterystyka oprogramowania obiektowego

Charakterystyka oprogramowania obiektowego 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ółowo

FIS SYSTEM MAGAZYNOWY

FIS SYSTEM MAGAZYNOWY FIS OGÓLNA CHARAKTERYSTYKA FIS SYSTEM MAGAZYNOWY System magazynowy FIS jest innowacyjnym programem wspierającym rozmaite procesy biznesowe potrzebne do zarządzania gospodarką magazynową w sklepach, hurtowniach,

Bardziej szczegółowo

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce)

emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce) emszmal 3: Automatyczne księgowanie przelewów w sklepie internetowym PrestaShop (plugin dostępny w wersji ecommerce) Zastosowanie Rozszerzenie to dedykowane jest sklepom internetowych zbudowanym w oparciu

Bardziej szczegółowo

Bazy danych 2. Wykład 1

Bazy danych 2. Wykład 1 Bazy danych 2 Wykład 1 Sprawy organizacyjne Materiały i listy zadań zamieszczane będą na stronie www.math.uni.opole.pl/~ajasi E-mail: standardowy ajasi@math.uni.opole.pl Sprawy organizacyjne Program wykładu

Bardziej szczegółowo

System zarządzania zleceniami

System zarządzania zleceniami Verlogic Systemy Komputerowe 2013 Wstęp Jednym z ważniejszych procesów występujących w większości przedsiębiorstw jest sprawna obsługa zamówień klientów. Na wspomniany kontekst składa się: przyjęcie zlecenia,

Bardziej szczegółowo

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor

Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor Koszalin, 15.06.2012 r. Dokument Detaliczny Projektu Temat: Księgarnia On-line Bukstor Zespół projektowy: Daniel Czyczyn-Egird Wojciech Gołuchowski Michał Durkowski Kamil Gawroński Prowadzący: Dr inż.

Bardziej szczegółowo

Baza danych sql. 1. Wprowadzenie

Baza danych sql. 1. Wprowadzenie Baza danych sql 1. Wprowadzenie Do tej pory operowaliście na listach. W tej instrukcji pokazane zostanie jak stworzyć bazę danych. W zadaniu skorzystamy z edytora graficznego struktury bazy danych, który

Bardziej szczegółowo

Jarosław Żeliński analityk biznesowy, projektant systemów

Jarosław Żeliński analityk biznesowy, projektant systemów Modele wdrażania i zarządzania projektami ERP Jarosław Żeliński analityk biznesowy, projektant systemów (c) Jarosław Żeliński IT-Consulting 1 Cel prezentacji Wskazanie kluczowych ryzyk projektów wdrożenia

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

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

Język UML. dr inż. Piotr Szwed C3, pok

Język UML. dr inż. Piotr Szwed C3, pok Język UML dr inż. Piotr Szwed C3, pok. 212 e-mail: pszwed@ia.agh.edu.pl http://pszwed.ia.agh.edu.pl Przypadki użycia Przypadki użycia: Definicja Przypadek użycia to specyfikacja ciągów akcji i ich wariantów,

Bardziej szczegółowo