AiPISZ - podsumowanie.

Prezentacja na temat: "AiPISZ - podsumowanie."— Zapis prezentacji:

1 AiPISZ - podsumowanie

2 Model dziedziny

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

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

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 W fazie analizy znaczenie ma jedynie tożsamość obiektu oraz stan – czyli zestaw atrybutów i ich wartości Zachowania obiektów zazwyczaj nie modeluje się w fazie analizy Model dziedziny

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

7 Pojęcie klasy Klasa – jest nazwanym opisem (specyfikacją, wzorcem, definicją) obiektów mających identyczną strukturę (atrybuty, powiązania) i zachowanie 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

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 W wielu opracowaniach używa się terminologii: powiązanie (związek między klasami), wystąpienie powiązania (związek między obiektami) W literaturze angielskjęzycznej na oznaczenia związku między klasami używa się terminu „association”, a na oznaczenie związku między obiektami – „link” Model dziedziny

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

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

11 Rodzaje klas klasy konceptualne (pojęciowe) - faza analizy
klasy projektowe - faza projektowania klasy implementacyjne - faza implementacji Powyższy podział wywodzi się z metodyki RUP Model dziedziny

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

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

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

15 Diagram sekwencji systemowych
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 Model dziedziny

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

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

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

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

20 Specyfikacja wymagań Specyfikacja wymagań – opis funkcji, które system powinien realizować oraz ograniczeń, które powinien spełniać Rodzaje wymagań: Funkcjonalne Niefunkcjonalne Dziedzinowe Do powyższych kategorii należy dodać jeszcze wymagania dziedzinowe. Istnieją inne klasyfikacje wymagań: np. Użytkownika, systemu Przypadki użycia

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

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

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
Zidentyfikować aktorów i ich cele (zasada: Szerokość przed głębokością) Utworzyć główne scenariusze Zidentyfikować rozszerzenia Utworzyć scenariusze rozszerzeń Przypadki użycia

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

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

27 Projektowanie - klasy i związki

28 Klasy w UML nazwa atrybuty operacje
Oprócz powyższych sekcji (nazwa, atrybuty, operacje) klasa może zawierać sekcje zdefiniowane przez użytkownika, np. odpowiedzialność (opis w języku naturalnym zakresu odpowiedzialności klasy), zdarzenia (zdarzenia obsługiwane przez klasę) operacje Projektowanie - klasy i związki

29 Interfejs Interfejs – zbiór operacji wyznaczających usługi oferowane przez klasę (lub komponent) 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 Powinno się używać terminu „klasa realizuje interfejs” lub „klasa implementuje interfejs”, a nie „klasa dziedziczy po interfejsie” Interfejs pełni rolę SPECYFIKACJI, klasa realizująca interfejs – rolę IMPLEMENTACJI, a sam związek pomiędzy specyfikacją a implementacją nosi nazwę REALIZACJI W przypadku interfejsu istotne jest rozróżnienie pomiędzy operacją a metodą, ponieważ interfejs zawiera specyfikację (czyli operacje) , a NIE MOŻĘ zawierać implementacji (czyli metod) Projektowanie - klasy i związki

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

31 Zależność Zależność – związek użycia jednego elementu przez inny
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

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

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

34 Kompozycja - przykład 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ść 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

35 Asocjacja kwalifikowana
Asocjacja kwalifikowana – asocjacja z wydzielonym atrybutem (jednym lub wieloma) jednoznacznie identyfikującym obiekt (lub grupę obiektów) po drugiej związku 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

36 Klasa asocjacyjna Klasa asocjacyjna – klasa posiadająca cechy asocjacji lub asocjacja posiadająca cechu klasy 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

37 Klasa asocjacyjna - przykład
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 Projektowanie - klasy i związki

38 Uogólnienie Uogólnienie (Generalizacja) – związek pomiędzy elementem ogólnym i jego specyficznym rodzajem 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

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

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

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

43 Diagramy ogólne i egzemplarzowe
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) Projektowanie dynamiki - diagram interakcji

44 Techniki projektowania – wzorce projektowe

45 PROJEKTOWANIE Stan „posiadania” Problemy do rozwiązania
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
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 warstwa logiki biznesowej warstwa infrastruktury 49

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 warstwa logiki biznesowej warstwa infrastruktury
SERWISY – PRZYKŁAD 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() warstwa aplikacji warstwa logiki biznesowej warstwa infrastruktury 51 51

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

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

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

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

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

58 Diagram czynności 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 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

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

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

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 Proces Analizy Strukturalnej
MODEL PODSTAWOWY MODEL IMPLEMENTACYJNY UŻYTKOWNIKA MODEL ŚRODOWISKOWY MODEL ZACHOWANIA

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)
kartoteka zleceń zlecenie telefoniczne rejestracja zlecenia przekazanie zadań klient zlecenie odebranie poczty skrzynka odczytanie poczty obsługa poczty

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ń Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja 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