Techniki projektowania wzorce projektowe
|
|
- Jakub Piasecki
- 7 lat temu
- Przeglądów:
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 2 Projektowanie Stan posiadania Przypadki użycia Model dziedziny Operacje systemowe Kontrakty dla operacji systemowych Problemy do rozwiązania
Bardziej szczegółowoAnaliza 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ółowoWykł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
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ółowoDiagramy czynności Na podstawie UML 2.0 Tutorial
Diagramy czynności Na podstawie UML 2.0 Tutorial http://sparxsystems.com.au/resources/uml2_tutorial/ Zofia Kruczkiewicz 1 Diagramy czynności 1. Diagramy czyności UML http://sparxsystems.com.au/resources/uml2_tutorial/
Bardziej szczegółowoAnaliza 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ółowoWprowadzenie do programowania aplikacji mobilnych
Wprowadzenie do programowania aplikacji mobilnych dr Przemysław Juszczuk dr Przemysław Juszczuk Trochę historii Idea wzorców projektowych wywodzi się jeszcze z wczesnych lat osiemdziesiątych ubiegłego
Bardziej szczegółowoModelowanie 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ółowoAnaliza i projektowanie oprogramowania. Analiza i projektowanie oprogramowania 1/32
Analiza i projektowanie oprogramowania Analiza i projektowanie oprogramowania 1/32 Analiza i projektowanie oprogramowania 2/32 Cel analizy Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie:
Bardziej szczegółowoDiagramy klas. dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com
Diagramy klas dr Jarosław Skaruz http://ii3.uph.edu.pl/~jareks jaroslaw@skaruz.com O czym będzie? Notacja Ujęcie w różnych perspektywach Prezentacja atrybutów Operacje i metody Zależności Klasy aktywne,
Bardziej szczegółowoDiagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym
Diagramy ERD. Model struktury danych jest najczęściej tworzony z wykorzystaniem diagramów pojęciowych (konceptualnych). Najpopularniejszym konceptualnym modelem danych jest tzw. model związków encji (ERM
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA
KATEDRA INFORMATYKI STOSOWANEJ PŁ INŻYNIERIA OPROGRAMOWANIA Przygotował: mgr inż. Radosław Adamus Wprowadzenie Podstawą każdego projektu, którego celem jest budowa oprogramowania są wymagania, czyli warunki,
Bardziej szczegółowoAnaliza i programowanie obiektowe 2016/2017. Wykład 6: Projektowanie obiektowe: diagramy interakcji
Analiza i programowanie obiektowe 2016/2017 Wykład 6: Projektowanie obiektowe: diagramy interakcji Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Przejście
Bardziej szczegółowoProjektowanie logiki aplikacji
Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie logiki aplikacji Zagadnienia Rozproszone przetwarzanie obiektowe (DOC) Model klas w projektowaniu logiki aplikacji Klasy encyjne a klasy
Bardziej szczegółowoProjektowanie 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ółowoPodstawy programowania III WYKŁAD 4
Podstawy programowania III WYKŁAD 4 Jan Kazimirski 1 Podstawy UML-a 2 UML UML Unified Modeling Language formalny język modelowania systemu informatycznego. Aktualna wersja 2.3 Stosuje paradygmat obiektowy.
Bardziej szczegółowoWstę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ółowoKomputerowe 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ółowoWarstwa 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ółowoProjektowanie 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ółowoProgramowanie obiektowe
Programowanie obiektowe Laboratorium 11 - przegląd wybranych wzorców mgr inż. Krzysztof Szwarc krzysztof@szwarc.net.pl Sosnowiec, 24 maja 2017 1 / 38 mgr inż. Krzysztof Szwarc Programowanie obiektowe Wzorce
Bardziej szczegółowoInżynieria oprogramowania II
Wymagania funkcjonalne, przypadki użycia Inżynieria oprogramowania II Problem i cel Tworzenie projektów bez konkretnego celu nie jest dobre Praktycznie każdy projekt informatyczny powstaje z uwagi na jakiś
Bardziej szczegółowoProjekt 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ółowoZagadnienia (1/3) Data-flow diagramy przepływów danych ERD diagramy związków encji Diagramy obiektowe w UML (ang. Unified Modeling Language)
Zagadnienia (1/3) Rola modelu systemu w procesie analizy wymagań (inżynierii wymagań) Prezentacja różnego rodzaju informacji o systemie w zależności od rodzaju modelu. Budowanie pełnego obrazu systemu
Bardziej szczegółowoInż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ółowoTechnologie 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ółowoProjektowanie 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ółowoAnaliza i projektowanie obiektowe 2016/2017. Wykład 10: Tworzenie projektowego diagramu klas
Analiza i projektowanie obiektowe 2016/2017 Wykład 10: Tworzenie projektowego diagramu klas Jacek Marciniak Wydział Matematyki i Informatyki Uniwersytet im. Adama Mickiewicza 1 Plan wykładu 1. Projektowy
Bardziej szczegółowoWykł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ółowoDiagramy 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ółowoProjektowanie obiektowe Wzorce projektowe. Gang of Four Wzorce rozszerzeń
Projektowanie obiektowe Wzorce projektowe Gang of Four Wzorce rozszerzeń 1 Roadmap Decorator Iterator Visitor 2 Wzorce rozszerzeń Mają na celu uczynić proces rozszerzania kodu bardziej czytelnym, prostym
Bardziej szczegółowoWzorce 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ółowoArchitektura Systemu. Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu.
Architektura Systemu Architektura systemu umożliwia kontrolowanie iteracyjnego i przyrostowego procesu tworzenia systemu. Architektura jest zbiorem decyzji dotyczących: organizacji systemu komputerowego,
Bardziej szczegółowoWykład 1 Inżynieria Oprogramowania
Wykład 1 Inżynieria Oprogramowania Wstęp do inżynierii oprogramowania. Cykle rozwoju oprogramowaniaiteracyjno-rozwojowy cykl oprogramowania Autor: Zofia Kruczkiewicz System Informacyjny =Techniczny SI
Bardziej szczegółowoDiagramu Związków Encji - CELE. Diagram Związków Encji - CHARAKTERYSTYKA. Diagram Związków Encji - Podstawowe bloki składowe i reguły konstrukcji
Diagramy związków encji (ERD) 1 Projektowanie bazy danych za pomocą narzędzi CASE Materiał pochodzi ze strony : http://jjakiela.prz.edu.pl/labs.htm Diagramu Związków Encji - CELE Zrozumienie struktury
Bardziej szczegółowoREQB 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ółowoproblem w określonym kontekście siły istotę jego rozwiązania
Wzorzec projektowy Christopher Alexander: Wzorzec to sprawdzona koncepcja, która opisuje problem powtarzający się wielokrotnie w określonym kontekście, działające na niego siły, oraz podaje istotę jego
Bardziej szczegółowoModelowanie 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ółowoAnaliza 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ółowoIteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1
Iteracyjno-rozwojowy proces tworzenia oprogramowania Wykład 3 część 1 Zofia Kruczkiewicz 1 Zunifikowany iteracyjno- przyrostowy proces tworzenia oprogramowania kiedy? Przepływ działań Modelowanie przedsiębiorstwa
Bardziej szczegółowoZaawansowane programowanie obiektowe - wykład 5
Zaawansowane programowanie obiektowe - wykład 5 dr Piotr Jastrzębski (czynnościowe) opisują zachowanie obiektów, komunikację pomiędzy nimi i ich odpowiedzialność. Interpreter Iterator (kursor) Łańcuch
Bardziej szczegółowoZasady 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ółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 4 Diagramy aktywności I Diagram aktywności (czynności) (ang. activity
Bardziej szczegółowoWypoż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ółowoModelowanie 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ółowoTechnologia programowania
Wykład 1 2 październik 2018 Cel kursu Znacie język programowania oraz umiecie tworzyć proste aplikacje. Nie macie doświadczenia w tworzeniu dużych i złożonych systemów. Aby stworzyć duży system należy:
Bardziej szczegółowoZofia Kruczkiewicz - Modelowanie i analiza systemów informatycznych 1
Charakterystyka oprogramowania obiektowego 1. Definicja systemu informatycznego 2. Model procesu wytwarzania oprogramowania - model cyklu życia oprogramowania 3. Wymagania 4. Problemy z podejściem nieobiektowym
Bardziej szczegółowoInżynieria oprogramowania
Inżynieria oprogramowania Wykład 8 Inżynieria wymagań: analiza przypadków użycia a diagram czynności Patrz: Stanisław Wrycza, Bartosz Marcinkowski, Krzysztof Wyrzykowski, Język UML 2.0 w modelowaniu systemów
Bardziej szczegółowoInformacje 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ółowoJerzy 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ółowoJęzyk UML w modelowaniu systemów informatycznych
Język UML w modelowaniu systemów informatycznych dr hab. Bożena Woźna-Szcześniak Akademia im. Jan Długosza bwozna@gmail.com Wykład 3 Diagramy przypadków użycia Diagramy przypadków użycia (ang. use case)
Bardziej szczegółowoAnaliza 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ółowoInżynieria oprogramowania Jarosław Kuchta. Modelowanie interakcji
Inżynieria oprogramowania Jarosław Kuchta Modelowanie interakcji Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania. Interakcja
Bardziej szczegółowoDiagram przypadków użycia
Diagram przypadków użycia Diagram przypadków użycia opisuje system z punktu widzenia użytkownika, pokazuje, co robi system, a nie jak to robi. Diagram ten sam w sobie zazwyczaj nie daje nam zbyt wielu
Bardziej szczegółowoDiagramy interakcji. Jarosław Kuchta Dokumentacja i Jakość Oprogramowania
Diagramy interakcji Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Podstawowe pojęcia Interakcja (interaction) Przepływ komunikatów pomiędzy obiektami konieczny dla wykonania określonego zadania.
Bardziej szczegółowoDiagramy 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ółowoProcesowa specyfikacja systemów IT
Procesowa specyfikacja systemów IT BOC Group BOC Information Technologies Consulting Sp. z o.o. e-mail: boc@boc-pl.com Tel.: (+48 22) 628 00 15, 696 69 26 Fax: (+48 22) 621 66 88 BOC Management Office
Bardziej szczegółowoFeature 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ółowoProjektowanie 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ółowoMVVM 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ółowoAplikacja (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ółowoWzorce 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ółowo1. WYMAGANIA WSTĘPNE W ZAKRESIE WIEDZY, UMIEJĘTNOŚCI I INNYCH KOMPETENCJI
KARTA PRZEDMIOTU przedmiotu Stopień studiów i forma Rodzaj przedmiotu Grupa kursów Zaawansowane techniki analizy systemowej oparte na modelowaniu warsztaty Studia podyplomowe Obowiązkowy NIE Wykład Ćwiczenia
Bardziej szczegółowoKATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH
KATEDRA INFORMATYKI STOSOWANEJ PŁ ANALIZA I PROJEKTOWANIE SYSTEMÓW INFORMATYCZNYCH Przygotował: mgr inż. Radosław Adamus Wprowadzenie: W procesie definiowania wymagań dla systemu tworzyliśmy Model Przypadków
Bardziej szczegółowoProjektowanie 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ółowoDiagram 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ółowoBAZY 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ółowoInstrukcja 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ółowoPodrę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ółowoProjektowanie 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ółowoInstrukcja 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ółowoWzorce 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ółowoTECHNOLOGIE OBIEKTOWE WYKŁAD 2. Anna Mroczek
TECHNOLOGIE OBIEKTOWE WYKŁAD 2 Anna Mroczek 2 Diagram czynności Czym jest diagram czynności? 3 Diagram czynności (tak jak to definiuje język UML), stanowi graficzną reprezentację przepływu kontroli. 4
Bardziej szczegółowoPRZEWODNIK 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ółowoSPECYFIKACJA WYMAGAŃ
SPECYFIKACJA WYMAGAŃ Autorzy: Wersja: 2 Historia zmian dokumentu Osoba
Bardziej szczegółowoWzorce 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ółowoWzorce 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ółowoFaza analizy (modelowania) Faza projektowania
Faza analizy (modelowania) Faza projektowania Celem fazy określania wymagań jest udzielenie odpowiedzi na pytanie: co i przy jakich ograniczeniach system ma robić? Wynikiem tej analizy jest zbiór wymagań
Bardziej szczegółowoZofia 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ółowoKurs programowania. Wykład 12. Wojciech Macyna. 7 czerwca 2017
Wykład 12 7 czerwca 2017 Czym jest UML? UML składa się z dwóch podstawowych elementów: notacja: elementy graficzne, składnia języka modelowania, metamodel: definicje pojęć języka i powiazania pomiędzy
Bardziej szczegółowoKarta 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ółowokoniec punkt zatrzymania przepływów sterowania na diagramie czynności
Diagramy czynności opisują dynamikę systemu, graficzne przedstawienie uszeregowania działań obrazuje strumień wykonywanych czynności z ich pomocą modeluje się: - scenariusze przypadków użycia, - procesy
Bardziej szczegółowoUML 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ółowoBazy danych TERMINOLOGIA
Bazy danych TERMINOLOGIA Dane Dane są wartościami przechowywanymi w bazie danych. Dane są statyczne w tym sensie, że zachowują swój stan aż do zmodyfikowania ich ręcznie lub przez jakiś automatyczny proces.
Bardziej szczegółowoModelowanie 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ółowoWzorce 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ółowoInstrukcja 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ółowoTECHNOLOGIE OBIEKTOWE. Wykład 3
TECHNOLOGIE OBIEKTOWE Wykład 3 2 Diagramy stanów 3 Diagram stanu opisuje zmiany stanu obiektu, podsystemu lub systemu pod wpływem działania operacji. Jest on szczególnie przydatny, gdy zachowanie obiektu
Bardziej szczegółowoProjektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34
Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34 Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych
Bardziej szczegółowoMichał Adamczyk. Język UML
Michał Adamczyk Język UML UML I. Czym jest UML Po co UML II.Narzędzia obsługujące UML, edytory UML III.Rodzaje diagramów UML wraz z przykładami Zastosowanie diagramu Podstawowe elementy diagramu Przykładowy
Bardziej szczegółowoProjektowanie 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ółowoZAMAWIAJĄCY. CONCEPTO Sp. z o.o.
Grodzisk Wielkopolski, dnia 11.02.2013r. ZAMAWIAJĄCY z siedzibą w Grodzisku Wielkopolskim (62-065) przy ul. Szerokiej 10 realizując zamówienie w ramach projektu dofinansowanego z Programu Operacyjnego
Bardziej szczegółowo1 Projektowanie systemu informatycznego
Plan wykładu Spis treści 1 Projektowanie systemu informatycznego 1 2 Modelowanie pojęciowe 4 2.1 Encja....................................... 5 2.2 Własności.................................... 6 2.3 Związki.....................................
Bardziej szczegółowoOmówienie wzorców wykorzystywanych w Prism 5.0. Dominika Różycka
1 Omówienie wzorców wykorzystywanych w Prism 5.0 Dominika Różycka Czym jest wzorzec projektowy? 2 3 Wzorzec projektowy 1. Uniwersalne i sprawdzone w praktyce rozwiązanie często pojawiających się, powtarzalnych
Bardziej szczegółowoPaweł Kurzawa, Delfina Kongo
Paweł Kurzawa, Delfina Kongo Pierwsze prace nad standaryzacją Obiektowych baz danych zaczęły się w roku 1991. Stworzona została grupa do prac nad standardem, została ona nazwana Object Database Management
Bardziej szczegółowoFaza 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ółowoAnaliza 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ółowoProjektowanie obiektowe oprogramowania Wykład 4 wzorce projektowe cz.i. wzorce podstawowe i kreacyjne Wiktor Zychla 2017
Projektowanie obiektowe oprogramowania Wykład 4 wzorce projektowe cz.i. wzorce podstawowe i kreacyjne Wiktor Zychla 2017 1 Wzorce podstawowe 1.1 Interface vs Abstract class class InterfaceAbstractClass
Bardziej szczegółowoAnaliza 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