Transcript AiPISZ - podsumowanie

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
3
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
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
Model Dziedziny - diagram obiektów
Diagram obiektów - przedstawia obiekty i powiązania miedzy nimi w określonej
chwili
Model dziedziny
6
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
7
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
Model Dziedziny - diagram klas
Diagram klas – przedstawia klasy oraz związki pomiędzy klasami (asocjacje)
Model dziedziny
9
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
Rodzaje klas
• klasy konceptualne (pojęciowe) - faza analizy
• klasy projektowe - faza projektowania
• klasy implementacyjne - faza implementacji
Model dziedziny
11
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
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
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
Diagram sekwencji systemowych
: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
Model dziedziny
przypadku
użycia, wzbogaconą o specyfikację
15 operacji systemowych
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
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
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
18
Analiza
Przypadki użycia
Model
biznesowy
Specyfikacja
wymagań
Przypadki
użycia
Model
dziedziny
problemu
19
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życia
20
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
21
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
22
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
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
•
Biznesowe a systemowe przypadki
Biznesowy przypadek użycia: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
25
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
26
Projektowanie - klasy i związki
Klasy w UML
nazwa
atrybuty
operacje
Projektowanie - klasy i związki
28
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
Projektowanie - klasy i związki
29
Związki między klasami
• Zależność
• Asocjacja
– Agregacja
– Kompozycja
• Generalizacja
Projektowanie - klasy i związki
30
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
31
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
32
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
33
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
34
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-dowiele lub wiele-do-wiele
Projektowanie - klasy i związki
35
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
36
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
37
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
38
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
40
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
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
Diagramy ogólne i egzemplarzowe
Diagram ogólny (generyczny)
Diagram przedstawia wszystkie możliwe
scenariusze interakcji
(blok
alt)
Projektowanie dynamiki diagram interakcji
Diagram egzemplarzowy (instancyjny)
43
Diagram przedstawia jeden
scenariusz interakcji (dla zmiennej
ilość jest większej od 0)
Techniki projektowania – wzorce
projektowe
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
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
warstwa logiki
biznesowej
warstwa
infrastruktury
Repozytorium osób – obsługuje
agregat Osoba, który składa się z
następujących klas:
• Osoba
• Adres
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
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
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
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
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
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
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
57
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
58
Diagram czynności przykład
Węzeł początkowy
Węzeł połączenia
Akcje / czynności
Węzeł decyzyjny
Przepływy sterowania
Diagramy czynności
59
Węzeł końcowy
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
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
ŚRODOWISKOWY
MODEL PODSTAWOWY
MODEL
ZACHOWANIA
MODEL
IMPLEMENTACYJNY
UŻYTKOWNIKA
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)
klient
zlecenie
telefoniczne
kartoteka
zleceń
rejestracja
zlecenia
e-mail
przekazanie
zadań
zlecenie
e-mail
skrzynka
odebranie
poczty
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ń
Faza
strategiczna
Projektowanie
Implementacja
Analiza
Testowanie
Konserwacja
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