Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

AiPISZ - podsumowanie. Model dziedziny Modelowanie dziedziny Model dziedziny odzwierciedla statyczne aspekty świata rzeczywistego Modelowanie z definicji.

Podobne prezentacje


Prezentacja na temat: "AiPISZ - podsumowanie. Model dziedziny Modelowanie dziedziny Model dziedziny odzwierciedla statyczne aspekty świata rzeczywistego Modelowanie z definicji."— Zapis prezentacji:

1 AiPISZ - podsumowanie

2 Model dziedziny

3 Modelowanie dziedziny Model dziedziny odzwierciedla statyczne aspekty świata rzeczywistego Modelowanie z definicji upraszcza rzeczywistość Modeluje się tylko wybrane aspekty rzeczywistości 3 Model dziedziny Modelowanie - odwzorowywanie bytów świata rzeczywistego i powiązań między nimi w obiekty i powiązania miedzy obiektami

4 Co to jest obiekt? Obiekt reprezentuje określony byt ze świata rzeczywistego Byt ze świata rzeczywistego może mieć wiele reprezentacji Byty świata rzeczywistego posiadają zazwyczaj wiele cech Obiekt odwzorowuje tylko te cechy, które mają znaczenie z punktu widzenia projektowanego systemu Obiekt może być złożony, tzn. zawierać inny obiekt Model dziedziny 4

5 Formalna charakterystyka obiektu Tożsamość – element wyróżniający dany obiekt pośród innych. W praktyce do wyróżnienia obiektu używa się identyfikatorów Stan – zbiór wartości wszystkich cech (atrybutów) obiektu oraz powiązań między obiektami. Stan obiektu może się zmieniać Zachowanie – zbiór wszystkich usług, jakie obiekt potrafi wykonać na rzecz innych obiektów Model dziedziny 5

6 Model Dziedziny - diagram obiektów Model dziedziny 6 Diagram obiektów - przedstawia obiekty i powiązania miedzy nimi w określonej chwili

7 Pojęcie klasy Obiekt jest instancją (egzemplarzem, wystąpieniem) klasy Klasa może posiadać wiele instancji Klasa nie jest zbiorem obiektów Pomiędzy klasami mogą istnieć związki Model dziedziny 7 Klasa – jest nazwanym opisem (specyfikacją, wzorcem, definicją) obiektów mających identyczną strukturę (atrybuty, powiązania) i zachowanie

8 Powiązanie a Asocjacja Powiązanie - związek (fizyczny lub pojęciowy) miedzy obiektami, odwzorowywujący związek pomiędzy bytami w dziedzinie problemu Asocjacja – związek między klasami wynikający z istnienia powiązań między obiektami tych klas Model dziedziny 8

9 Model Dziedziny - diagram klas Model dziedziny 9 Diagram klas – przedstawia klasy oraz związki pomiędzy klasami (asocjacje)

10 Analiza a projektowanie Analiza koncentruje się na badaniu dziedziny problemu oraz wymagań stawianych przed systemem. Wynikiem analizy jest model dziedziny problemu, który odzwierciedla ważne z punktu widzenia systemu byty świata rzeczywistego, ich najważniejsze cechy oraz zależności miedzy nimi Projektowanie polega na szukaniu rozwiązania dla problemu, którego dotyczy system informatyczny. W wyniku otrzymujemy model projektowy, będący w istocie zbiorem powiązanych klas, wyposażonych w metody odpowiedzialne za realizacje zidentyfikowanego we wcześniejszej fazie zakresu funkcjonalności Model dziedziny 10

11 Rodzaje klas klasy konceptualne (pojęciowe) - faza analizy klasy projektowe - faza projektowania klasy implementacyjne - faza implementacji Model dziedziny 11

12 Proces tworzenia modelu dziedziny 1.Identyfikacja klas konceptualnych i obiektów 2.Identyfikacja związków między klasami konceptualnymi 3.Identyfikacja atrybutów Uwaga: w modelu dziedziny nie specyfikuje się zachowania obiektów, tj. operacji Model dziedziny 12

13 Techniki tworzenia modelu dziedziny Lista typowych klas Analiza dziedziny problemu Identyfikacja fraz rzeczownikowych Komentarz: Najlepsze efekty osiąga się stosując techniki mieszane Model dziedziny 13

14 Operacje Systemowe Przypadek użycia jest opisem interakcji aktora z systemem Aktor wchodzący w interakcje z system generuje pewne zdarzenia, zwane zdarzeniami systemowymi Zdarzenia systemowe skutkują wywołaniem operacji, zwanych operacjami systemowymi Operacja systemowa to operacja, którą system udostępnia na zewnątrz Model dziedziny 14

15 Diagram sekwencji systemowych Model dziedziny 15 :System OperacjaSystemowa1(a, b, c) Odpowiedź systemu OperacjaSystemowa2() Diagram Sekwencji Systemowych (ang. System Sequence Diagram) przedstawia, w jaki sposób zewnętrzny aktor wchodzi w interakcje z projektowanym systemem Diagram Sekwencji Systemowych w istocie jest wizualizacją wybranego scenariusza przypadku użycia, wzbogaconą o specyfikację operacji systemowych

16 Kontrakty dla operacji wg Larmana Kontrakt dla operacji jest opisem stanu systemu przed i po wykonaniu operacji systemowej Kontrakty tworzy się dla bardziej złożonych operacji systemowych Kontrakty tworzy się w oparciu o model dziedziny Model dziedziny 16

17 Projektowanie według umowy Kontrakty dla operacji systemowych są uproszczoną wersją koncepcji projektowania kontraktowego (inaczej: projektowanie według umowy) W projektowaniu kontraktowym oprócz warunków początkowych i końcowych definiuje się tzw. niezmienniki. Jest to rodzaj ograniczeń, które muszą być spełnione zawsze, przez wszystkie instancje klasy. Przykładowo, atrybut cena dla obiektów klasy Produkt musi zawsze być większa od zera W projektowaniu kontraktowym warunki początkowe, końcowe oraz niezmienniki można definiować zarówno dla klas jak i operacji Do formalnego zapisu warunków początkowych, końcowych oraz niezmienników służy język OCL (ang. Object Constrain Language). Model dziedziny 17

18 Proces wytwarzania oprogramowania Przypadki użycia18 Co system będzie robił (zebranie i analiza wymagań) Analiza Jak system będzie zbudowany (opracowanie rozwiązania odpowiadającego wymaganiom) Projektowanie Budowa rozwiązania (kod programu, debugowanie) Implementacja Czy system realizuje założone cele (opracowanie testów, walidacja) Testowanie Instalacja oprogramowania w określonym środowisku Wdrożenie (Integracja) Modyfikowanie systemu w zależności od zmieniających się potrzeb Pielęgnacja (Konserwacja)

19 Analiza Przypadki użycia19 Model biznesowy Specyfikacja wymagań Przypadki użycia Model dziedziny problemu

20 Specyfikacja wymagań Specyfikacja wymagań – opis funkcji, które system powinien realizować oraz ograniczeń, które powinien spełniać Rodzaje wymagań: – Funkcjonalne – Niefunkcjonalne – Dziedzinowe Przypadki użycia20

21 Wymagania funkcjonalne Opisują co system ma robić, jakie funkcjonalności udostępniać Zazwyczaj mają postać listy funkcji realizowanych przez system Każda funkcja to jedno wymaganie Przypadki użycia21

22 Wymagania niefunkcjonalne Opisują własności i ograniczenia sytemu Z reguły dotyczą kwestii bezpieczeństwa, wydajności, czasu odpowiedzi na określone zdarzenia, itp. Mogą zawierać specyfikacje odnośnie języka programowania, bazy danych, systemu operacyjnego, itp. Przypadki użycia22

23 Co to jest przypadek użycia? Przypadek użycia – umowa między uczestnikami (interesariuszami) systemu określająca sposób zachowania systemu Przypadek użycia – opis zbioru ciągów akcji wykonywanych przez system w celu dostarczenia określonemu aktorowi godnego uwagi wyniku Przypadek użycia – reprezentuje pewne odrębne i dobrze określone zachowanie systemu lub jego części Przypadek użycia – określa, co system ma robić Przypadek użycia – opisuje zachowanie systemu z zewnętrznego punktu widzenia 23

24 Etapy tworzenia przypadków użycia 1.Zidentyfikować aktorów i ich cele (zasada: Szerokość przed głębokością) 2.Utworzyć główne scenariusze 3.Zidentyfikować rozszerzenia 4.Utworzyć scenariusze rozszerzeń Przypadki użycia 24

25 Biznesowe a systemowe przypadki użycia Biznesowy przypadek użycia: – Zakres - zakresem jest całe przedsiębiorstwo lub jego dział, komórka, etc. – Poziom celu - cel przypadku użycia jest realizowany wieloposiedzeniowo Systemowy przypadek użycia: – Zakres - zakresem jest system lub jego cześć (podsystem, moduł, etc.) – Poziom celu - aktor realizuje swój cel w trakcie jednej sesji Przypadki użycia25

26 Pakiet Forma organizacji przypadków użycia Obejmuje przypadki użycia logicznie powiązane ze sobą, tzn. posiadające tego samego aktora, dotyczące tego samego problemu (biznesowego przypadku użycia), itp. Przypadki użycia26

27 Projektowanie - klasy i związki

28 Klasy w UML Projektowanie - klasy i związki 28 nazwa atrybuty operacje

29 Interfejs Interfejs zawiera tylko specyfikację operacji, a nie atrybutów Klasa realizująca interfejs musi dostarczyć implementacji dla wszystkich operacji interfejsu Interfejs jest równoważny klasie abstrakcyjnej pozbawionej atrubutów i metod (implementujących) Klasa może realizować wiele interfejsów Projektowanie - klasy i związki 29 Interfejs – zbiór operacji wyznaczających usługi oferowane przez klasę (lub komponent)

30 Związki między klasami Zależność Asocjacja – Agregacja – Kompozycja Generalizacja Projektowanie - klasy i związki 30

31 Zależność Jeśli klasy są zależne, to zmiany dokonane w specyfikacji jednej z klas mogą mieć wpływ na drugą klasę Związki typu asocjacja, agregacja, kompozycja, czy uogólnienie również oznaczają zależność (terminu zależność używamy wtedy, gdy związek nie ma charakteru strukturalnego; jeśli jest to związek strukturalny, wówczas mówimy o asocjacji, agregacji, itd.) Zależność jest najsłabszym rodzajem związku Na diagramie zależność przedstawia się przerywaną linią z grotem wskazującym kierunek zależności Projektowanie - klasy i związki 31 Zależność – związek użycia jednego elementu przez inny

32 Asocjacja Cechy asocjacji: Nazwa – znaczenie związku Rola – powinność jaką pełni obiekt jednej klasy wobec obiektu innej klasy Krotność - maksymalna i minimalna liczbę obiektów jednej klasy powiązanych z jednym obiektem innej klasy Projektowanie - klasy i związki 32 Asocjacja – związek o charakterze strukturalnym między dwiema lub większą liczbą klas wynikający z istnienia powiązań między obiektami tych klas

33 Agregacja Obiekt cześć może istnieć niezależnie od obiektu typu całość Agregacja jest związkiem niesymetrycznym (samochód zawiera silnik, ale silnik nie zawiera samochodu) i przechodnim (samochód zawiera silnik, silnik zawiera cylinder samochód zawiera cylinder) Pod względem syntaktycznym agregacja jest zwykłą asocjacją, różnice istnieją jedynie w sferze semantycznej (znaczeniowej) Projektowanie - klasy i związki 33 Agregacja – rodzaj asocjacji, gdzie obiekty jednej klasy pełnią rolę całości a obiekty innej klasy rolę części, przy obiekty pełniące rolę części mogą należeć do kilku obiektów pełniących rolę całości

34 Kompozycja - przykład Cykl życia obiektu część zawiera się w cyklu życia obiektu całość Obiekt całość jest wyłącznym właścicielem obiektów część Obiekt całość jest odpowiedzialny za tworzenie, inicjowanie i usuwanie obiektów cześć Projektowanie - klasy i związki 34 Kompozycja - rodzaj asocjacji, gdzie obiekty jednej klasy pełnią rolę całości a obiekty innej klasy rolę części, przy obiekt pełniące rolę części może w danym momencie należeć tylko do jednego obiektu typu całość

35 Asocjacja kwalifikowana Atrybut realizujący asocjacje kwalifikowaną nazywa się kwalifikatorem asocjacji W roli kwalifikatorów najczęściej występują identyfikatory obiektów (np. idProdukt, idStudent ) Kwalifikator może odnosić się tylko do asocjacji o krotnościach jeden-do- wiele lub wiele-do-wiele Projektowanie - klasy i związki 35 Asocjacja kwalifikowana – asocjacja z wydzielonym atrybutem (jednym lub wieloma) jednoznacznie identyfikującym obiekt (lub grupę obiektów) po drugiej związku

36 Klasa asocjacyjna Pozwala na dodanie do asocjacji nowych składowych, takich jak atrybuty i operacje Klas asocjacyjnych używa się do modelowania bardziej złożonych asocjacji, tj. asocjacji posiadających pewne cechy, które nie mogą być przypisane do żadnej z klas uczestniczących w asocjacji Dla każdego powiązania (instancji asocjacji) istnieje jeden obiekt klasy asocjacyjnej Projektowanie - klasy i związki 36 Klasa asocjacyjna – klasa posiadająca cechy asocjacji lub asocjacja posiadająca cechu klasy

37 Klasa asocjacyjna - przykład Projektowanie - klasy i związki 37 Każdy obiekt klasy PozycjaZamówienia jest wynikiem istnienia powiązania pomiędzy konkretnym obiektem klasy Zamówienie a konkretny obiektem klasy Produkt Klasa PozycjaZamówienia posiada cechy (np. ilość ), które nie mogą być przypisane do żadnych z klas Zamówienie i Produkt

38 Uogólnienie Element ogólny nazywany jest nadklasą (rodzic), element specyficzny – podklasą (dziecko) Dziecko dziedziczy strukturę i zachowanie rodzica, może również posiadać swoje własne cechy strukturalne i zachowanie Każda instancja podklasy jest jednocześnie instancją nadklasy – stąd instancja podklasy może być użyty w miejsce instancji nadklasy Uogólnienie tworzy hierarchę klas, od najbardziej ogólnych do najbardziej szczegółowych Projektowanie - klasy i związki 38 Uogólnienie (Generalizacja) – związek pomiędzy elementem ogólnym i jego specyficznym rodzajem

39 Projektowanie dynamiki - diagramy interakcji

40 Modele statyczne i dynamiczne Modele statyczne – klasy i zależności między klasami – diagram klas – diagram obiektów Modele dynamiczne – interakcja między obiektami – diagramy sekwencji – diagramy komunikacji Projektowanie dynamiki - diagram interakcji 40

41 Diagram sekwencji Diagram sekwencji przedstawia: komunikaty przysyłane pomiędzy obiektami (i ich kolejność) przepływ sterowania szablon realizowanego algorytmu lub jedną z możliwych ścieżek algorytmu czas życia i okresy aktywności obiektów (ról) biorących udział w interakcji Projektowanie dynamiki - diagram interakcji 41

42 Diagram komunikacji Diagram komunikacji przedstawia: komunikaty przysyłane pomiędzy obiektami (i ich kolejność) przepływ sterowania szablon realizowanego algorytmu lub jedną z możliwych ścieżek algorytmu związki miedzy obiektami (rolami biorącymi udział w interakcji) Projektowanie dynamiki - diagram interakcji 42

43 Diagramy ogólne i egzemplarzowe Projektowanie dynamiki - diagram interakcji 43 Diagram ogólny (generyczny)Diagram egzemplarzowy (instancyjny) Diagram przedstawia wszystkie możliwe scenariusze interakcji (blok alt ) Diagram przedstawia jeden scenariusz interakcji (dla zmiennej ilość jest większej od 0 )

44 Techniki projektowania – wzorce projektowe

45 PROJEKTOWANIE Stan posiadania – Przypadki użycia – Model dziedziny – Operacje systemowe – Kontrakty dla operacji systemowych Problemy do rozwiązania – Zakres odpowiedzialności poszczególnych klas? – Współdziałanie (kooperacja) obiektów w celu realizacji warunków zapisanych w kontrakcie 45

46 DOMAIN DRIVEN DESIGN ( W SKRÓCIE DDD ) Domain Driven Design jest koncepcją projektowania systemów informatycznych, w której kluczową rolę odgrywa model dziedziny Autorem DDD jest Eric Evans (Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003) W literaturze polskiej funkcjonują następujące tłumaczenia terminu DDD: – Projektowanie Zorientowane na Dziedzinę – Projektowanie Sterowane Modelem/Dziedziną Koncepcja DDD to zbiór podstawowych zasad, wzorców oraz sprawdzonych praktyk ułatwiających projektowanie systemu Systemy projektowane zgodnie z duchem DDD mają strukturę warstwową 46

47 PODSTAWOWE ELEMENTY DDD Encja (ang. Entity) Wartość (ang. Value Object) Serwis (ang. Service) Agregat (ang. Aggregate) Repozytorium (ang. Repository) Fabryka (ang. Factory) 47

48 REPOZYTORIUM Wzorzec repozytorium umożliwia dostęp do puli obiektów biznesowych ukrywając przed klientem wszelkie mechanizmy dostępu do bazy danych Z punktu widzenia klienta repozytorium może być traktowane jako kolekcja obiektów biznesowych Repozytorium udostępnia swoim klientom operacje zapisu, odczytu, aktualizacji, usuwania oraz wyszukiwania obiektów biznesowych Koncepcja DDD zaleca utworzenie jednego repozytorium dla każdego agregatu 48

49 REPOZYTORIUM – PRZYKŁAD 49 warstwa logiki biznesowej warstwa infrastruktury Repozytorium wydarzeń – obsługuje agregat Wydarzenie, który składa się z następujących klas: Wydarzenie Alarm Uczestnictwo Repozytorium osób – obsługuje agregat Osoba, który składa się z następujących klas: Osoba Adres

50 SERWIS W myśl koncepcji DDD serwisy to specjalizowane klasy przeznaczone do wykonywania operacji biznesowych, których nie można przypisać do jednego obiektu biznesowego W szerszym znaczeniu serwisem jest również klasa odpowiedzialna za koordynacje działań związanych z wykonywaniem operacji systemowych w ramach jednego przypadku użycia Serwisy nie posiadają wewnętrznego stanu – zwykle tworzone są na potrzeby konkretnego zadania i po jego wykonaniu są usuwane Serwis jest obiektem rozpoczynającym obsługę operacji systemowej 50

51 SERWISY – PRZYKŁAD 51 warstwa logiki biznesowej warstwa infrastruktury warstwa aplikacji Serwis Wydarzeń – odpowiada za zarządzanie wykonywaniem operacji systemowych związanych wydarzeniami, np.: UtworzWydarzenie() DodajAlarm() DodajUczestnika() Serwis Osób – odpowiada za zarządzanie wykonywaniem operacji systemowych związanych osobami, np. : UtworzOsobe() UsunOsobe()

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

53 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? Techniki projektowania - wzorce GRASP 53

54 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 Techniki projektowania - wzorce GRASP 54

55 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) Techniki projektowania - wzorce GRASP 55

56 Diagramy czynności

57 Modelowanie dynamiki systemu Diagramy do modelowania dynamiki systemu: Diagram przypadków użycia Diagramy interakcji – Diagram sekwencji – Diagram komunikacji Diagram czynności Diagram stanu Diagramy czynności 57

58 Diagram czynności Służą do modelowania dynamicznych właściwości systemu Wszystkie akcje i (lub) czynności wykonywane w trakcie realizacji dowolnej funkcjonalności systemu tworzą pewien proces Diagramy czynności pozwalają w graficzny sposób pokazać ten proces - jakie akcje i (lub) czynności są wykonywane, kolejność ich wykonania oraz dane na których operują Diagramy czynności 58 Diagram czynności – graficzne przedstawienie sekwencyjnych i (lub) współbieżnych przepływów sterowania oraz danych pomiędzy uporządkowanymi ciągami czynności, akcji i obiektów

59 Diagram czynności przykład Diagramy czynności 59 Węzeł początkowy Węzeł końcowy Akcje / czynności Węzeł decyzyjny Węzeł połączenia Przepływy sterowania

60 Elementy diagramu czynności Akcje Czynności Przepływy sterowania Węzły początkowe i końcowe Węzły decyzyjne i połączenia Węzły rozwidlenia i scalenia Diagramy czynności 60

61 Diagram stanów - UML Jest to diagram dynamiczny zwany niekiedy diagramem sieci przejść lub diagramem przepływu sterowania Pokazuje stany w jakich może znaleźć się system oraz w uproszczonej formie akcje i warunki łączące stany

62 Podstawowe symbole

63 Diagram stanów – przykład 1.

64 Modelowanie procesów biznesowych BPMN

65 CZYM JEST BPMN? Business Process Modeling Notation (BPMN) jest graficzną notacją opisującą kroki w procesie biznesowym Została specjalnie zaprojektowana tak, aby odzwierciedlić przepływ procesu i informacji pomiędzy różnymi zdarzeniami

66 PRZYKŁAD – OBSŁUGA ZMÓWIENIA

67 KONCEPCJA ŻETONU – TOKENA Pojedyncza transakcja jest reprezentowana przez żeton, który krąży zgodnie z przepływem w procesie i przechodzi przez modelowane obiekty Żeton posiada unikalny identyfikator ID zwany czasem TokenID Początek procesu biznesowego generuje żeton z identyfikatorem TokenID

68 KONCEPCJA ŻETONU – TOKENA Główny TokenID jest wspólny dla wszystkich nowych żetonów generowanych w czasie rozwidlenia przepływu procesu Unikalne dla każdej nowej ścieżki w przypadku jej rozwidlenia uzupełnienie identyfikatora głównego TokenID nazywane jest czasem SubTokenID Jeśli ścieżki się łączą w taki sposób, że tylko jeden żeton może przejść dalej to po taki połączeniu SubTokenID może zostać odcięty

69 PRZEPŁYW ŻETONÓW

70 ZDARZENIA Zdarzenie jest stanem jaki pojawia się podczas przebiegu procesu biznesowego Zdarzenia mają wpływ na przebieg procesu i zazwyczaj coś wyzwalają lub są czegoś rezultatem Mogą rozpoczynać (zdarzenia początkowe), przerywać (pośrednie) lub kończyć (końcowe) przebieg

71 Modelowanie procesów biznesowych Inne metody

72 Metody strukturalne (założenia) Podział procesu projektowania według składowych pasywnych (dane) i aktywnych (funkcje) Metoda uściślania krokowego i projektowania składanego Podział na dwie fazy: – konstrukcja modelu podstawowego – konstrukcja modelu implementacyjnego

73 MODEL PODSTAWOWY MODEL ŚRODOWISKOWY MODEL ZACHOWANIA MODEL IMPLEMENTACYJNY UŻYTKOWNIKA Proces Analizy Strukturalnej

74 Model podstawowy Co powinien robić system aby spełnić wymagania użytkownika? Model powinien zawierać jak najmniej informacji o tym jak system powinien być implementowany Model podstawowy zawiera dwie główne składowe: – model środowiskowy – model zachowania

75 Narzędzia Analizy Strukturalnej Modelowanie funkcji systemu: – Lista zdarzeń – Diagram Przepływu Danych – Słownik Danych – Specyfikacja Procesu Modelowanie gromadzonych danych: Diagram Związków Encji Modelowanie czasowej charakterystyki zachowania: Diagram Sieci Przejść Modelowanie struktury Programu: Diagram Struktury

76 Diagram przepływu danych (Data Flow Diagram – DFD) obsługa poczty rejestracja zlecenia kartoteka zleceń klient przekazanie zadań zlecenie telefoniczne odczytanie poczty odebranie poczty skrzynka zlecenie

77 IDEF0

78 Hierarchiczna struktura diagramów

79 Metodologia prof. Scheera Prof. August Wilhelm Scheer z Uniwersytetu Saarbrucken jest twórcą koncepcji informatyki gospodarczej Od wielu lat pracuje nad opisem metod umożliwiających mapowanie, analizę i reorganizację procesów gospodarczych Na stworzonej przez niego koncepcji oparte jest jedno z wiodących narzędzi, służących mapowaniu i reorganizacji procesów – pakiet programów ARIS

80 Architektura SOA

81 Architektura oparta na usługach (ang. Service Oriented Architecture, SOA) jest to koncepcja tworzenia systemów informatycznych, w której główny nacisk stawia się na definiowanie usług, które spełnią wymagania użytkownika Pojęcie SOA obejmuje zestaw metod organizacyjnych i technicznych mający na celu lepsze powiązanie biznesowej strony organizacji z jej zasobami informatycznymi Mianem usługi określa się tu każdy element oprogramowania, mogący działać niezależnie od innych oraz posiadający wyspecyfikowany interfejs, za pomocą którego udostępnia realizowane funkcje

82 Architektura oparta na usługach Sposób działania każdej usługi jest w całości zdefiniowany przez interfejs ukrywający szczegóły implementacyjne - niewidoczne i nieistotne z punktu widzenia klientów Dodatkowo, istnieje wspólne, dostępne dla wszystkich medium komunikacyjne, umożliwiające swobodny przepływ danych pomiędzy elementami platformy Architektura SOA podobna jest do obiektów rozproszonych, jednak opisuje rozwiązanie na wyższym poziomie abstrakcji. Interfejsy usług są zazwyczaj definiowane w sposób abstrakcyjny i niezależny od platformy programistycznej

83 Modelowanie procesów biznesowych Przepływy pracy

84 Definicja Workflow (w języku polskim określany jako przepływ pracy) jest to zautomatyzowany w całości lub części proces biznesowy, w trakcie którego dokumenty, informacje lub zadania są przekazywane pomiędzy uczestnikami procesu w celu umożliwienia wykonania czynności w sposób zgodny ze zdefiniowanymi regułami

85

86 Zarządzanie projektem systemu informatycznego

87 Cykl życia projektu Formalnie określony sposób realizacji projektu (plan projektu, metodologia budowy systemu) Uporządkowanie przebiegu prac Ułatwienie planowania zadań Monitorowanie przebiegu realizacji zadań

88 Modele cyklu życia Realizacja kierowana dokumentami Prototypowanie Programowanie odkrywcze Realizacja przyrostowa Montaż z gotowych elementów Model spiralny Formalne transformacje

89 Model ogólny cyklu życia Określanie wymagań ProjektowanieImplementacjaTestowanieKonserwacja Faza strategiczna AnalizaInstalacja Dokumentacja

90 Rational Unified Process Rational Unified Process (RUP) to proces iteracyjnego wytwarzania oprogramowania opracowany przez firmę Rational Software Corporation (firma została obecnie przejęta przez IBM) Proces RUP nie jest pojedynczym, ściśle określonym procesem, ale raczej szablonem procesu

91 Iteracyjne wytwarzanie oprogramowania Wytwarzanie oprogramowania w kolejnych iteracjach, pozwala skupić się w pierwszej kolejności na obszarach najbardziej ryzykownych (np. najmniej rozpoznanych) W idealnym przypadku każda iteracja kończy się stworzeniem wykonywalnego artefaktu - pomaga to zredukować ryzyko w projekcie, otrzymujemy szybciej opinie od odbiorców oprogramowania a programistom pozwalamy skupić się na węższej dziedzinie

92 Architektura bazująca na komponentach Pozwala na stworzenie systemu, który jest łatwo rozszerzalny, intuicyjnie zrozumiały i wspomaga ponowne użycie (komponent to zbiór powiązanych obiektów) RUP skupia się na stworzeniu prostej architektury w początkowych iteracjach Ewoluuje ona w każdej iteracji zbliżając się do architektury finalnej Poprzez iteracyjne wytwarzanie oprogramowania zyskujemy możliwość stopniowej identyfikacji komponentów, które mogą być w dalszej części: zakupione, zbudowane, lub użyte ponownie

93 Wizualne modelowanie oprogramowania Abstrakcja projektowania od kodu i przedstawienie koncepcji za pomocą bloków graficznych może być efektywnym sposobem aby pokazać perspektywę rozwiązania Reprezentacja graficzna jest produktem pośrednim pomiędzy analizą procesu biznesowego, a implementacją Model w tym kontekście jest formą wizualizacji oraz uproszczeniem bardziej skomplikowanego projektu RUP specyfikuje wymagane modele i opisuje dlaczego są wymagane

94 Zarządzanie zmianami w oprogramowaniu RUP definiuje metody śledzenia, ewidencji i kontroli zmian Zdefiniowane są także tzw. secure workspaces (bezpieczne przestrzenie robocze), które pozwalają na zagwarantowanie, że zmiany w innych systemach nie wpłyną na system tworzony Koncepcja ta jest ściśle powiązana z tworzeniem architektury zorientowanej komponentowo

95 Struktura organizacyjna RUP proponuje strukturę zespołów w dwóch obszarach – biznesowym (business unit) – projektowym Zadaniem zespołu biznesowego jest koordynowanie funkcji i zasobów wykorzystywanych w wielu projektach z zastosowaniem wspólnej technologii i zasad

96 Metodyki zwinne (agile) Irytacja podejściami nastawionymi na kontrolowanie procedur i dyscyplinę W jaki sposób można odchudzić procesy wytwarzania oprogramowania, przy zachowaniu wysokiej jakości (lub czasem wręcz jej poprawieniu)? Powstały lekkie metodyki rozwoju oprogramowania, których dobrym przykładem jest Programowanie Ekstremalne, po angielsku zwane również XP

97 Metodyka PRINCE2 Projects in a Controlled Environment tzn. Projekty w sterowanym środowisku brytyjska agenda rządowa Central Computer and Telecommunications Agency (CCTA) opublikowało standard pod nową nazwą – PRINCE PRINCE2 opublikowany jako ogólna metoda zarządzania projektami niezależna od dziedziny biznesowej zastosowania ostatnie zmiany opublikowane przez Office for Government Commerce (OGC) – następcę CCTA

98 XPrince Równowaga między zwinnością a dyscypliną z wykorzystaniem Xprince

99 Porównanie struktur organizacyjnych

100 Cykle życia


Pobierz ppt "AiPISZ - podsumowanie. Model dziedziny Modelowanie dziedziny Model dziedziny odzwierciedla statyczne aspekty świata rzeczywistego Modelowanie z definicji."

Podobne prezentacje


Reklamy Google