AiPISZ - podsumowanie

Model dziedziny

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Projektowanie - klasy i związki

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

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

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

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

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

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

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

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

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

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

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

Projektowanie dynamiki - diagramy interakcji

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

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

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

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

Techniki projektowania – wzorce projektowe

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

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

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

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

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

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

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

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

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

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

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

Diagramy czynności

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

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

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

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

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

Podstawowe symbole

Diagram stanów – przykład 1.

Modelowanie procesów biznesowych BPMN

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

PRZYKŁAD – OBSŁUGA ZMÓWIENIA

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

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”

PRZEPŁYW ŻETONÓW

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

Modelowanie procesów biznesowych Inne metody

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

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

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

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

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

IDEF0

Hierarchiczna struktura diagramów

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

Architektura SOA

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

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

Modelowanie procesów biznesowych Przepływy pracy

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

Zarządzanie projektem systemu informatycznego

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ń

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

Model ogólny cyklu życia Określanie wymagań Projektowanie Implementacja Testowanie Konserwacja Faza strategiczna Analiza Instalacja Dokumentacja

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

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

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

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

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

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

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”

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

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

Porównanie struktur organizacyjnych

Cykle życia