Cykl Rozwoju Architektury wg TOGAF

Architektura korporacyjna formalny opis struktury funkcji komponentw korporacji, wzajemnych

powiza pomidzy tymi komponentami oraz pryncypia i wytyczne odnone do zarzdzania
projektowaniem i zmian tych komponentw w czasie
Architektura korporacyjna obejmuje 4 obszary (1) wizja, (2) procesy biznesowe, (3) systemy
informatyczne, (4) - technologie
SOA styl architektury realizujcy podejcie/mylenie usugowe w caej organizacji (a nie tylko w
obszarze IT); stanowi on moliwy sposb realizacji okrelonego zakresu architektury korporacyjnej
TOGAF metodyka wdraania SOA w duych organizacjach
Cykl ADM (Architecture Development Method) jest metod przedstawiajc krok po kroku jak
zaprojektowa i zrealizowa architektur korporacyjn w organizacji. Jest to metoda iteracyjna,
umoliwiajca stworzenie zarwno architektury strategicznej, segmentw jak i potencjau. Efektem
kocowym cyklu jest wprowadzona zmiana organizacyjna (zarwno na poziomie biznesowym jak i IT).

Cykl wok ZARZDZANIA WYMAGANIAMI: Faza wstpna -> (A) Wizja architektury -> (B) Architektura
biznesowa -> (C) Architektura danych i aplikacji -> (D) Architektura techniczna -> (E) Moliwoci i
rozwizania -> (F) Planowanie migracji -> (G) Nadzr nad implementacj -> (H) Zarzdzanie zmian
architektury
Cykl ADM zakada iteracyjne podejcie: iteracyjno caych cykli | iteracyjno wewntrz cyklu |
iteracyjno wg faz
Iteracja rozwoju architektonicznego B-F, Iteracja planowania przejcia E-F, Iteracja adu
architektonicznego G-H
W fazie wstpnej nastpuje okrelenie sposobu, w jaki SOA bdzie realizowana w ramach organizacji,
co obejmuje:

Ustanowienie kontekstu biznesowego wprowadzenia SOA

Pozyskania wsparcia Sponsora
Zmierzenie dojrzaoci usugowej organizacji
Ustanowienie struktury zarzdzania SOA
Zdefiniowanie pryncypiw dotyczcych SOA
Wdroenie repozytorium umoliwiajcego tworzenie modeli architektonicznych

Celem Fazy A jest zdefiniowanie zakresu prac, identyfikacja interesariuszy, utworzenie wizji organizacji
dziaajcej zgodnie z SOA oraz otrzymanie akceptacji sponsora odnonie do dalszych dziaa
Celem Fazy B jest opis bazowej architektury biznesowej i stworzenie docelowej architektury
biznesowej w podejciu usugowym oraz opracowanie analizy luk
Celem Fazy C jest opis bazowej architektury aplikacji i stworzenie docelowej architektury aplikacji w
podejciu usugowym oraz opracowanie analizy luk
Celem Fazy D jest opis bazowej architektury aplikacji i stworzenie docelowej architektury technicznej
w podejciu usugowym oraz opracowanie analizy luk
Celem Fazy E jest identyfikacja nowych moliwoci i kluczowych rozwiza oraz sposobu ich
wprowadzenia do organizacji (w formie architektur porednich) w celu osignicia architektury
docelowej bd one stanowiy podstaw planu migracji
Celem Fazy F jest uoenie poszczeglnych projektw zgodnie z ich priorytetami. Nastpuje
oszacowanie zalenoci, kosztw i korzyci zwizanych z poszczeglnymi projektami migracyjnymi.
Spriorytetyzowana lista projektw stanowi podstaw planu migracji.
Celem Fazy G jest sformuowanie rekomendacji dla kadego projektu w formie kontraktu
architektonicznego sucego do zarzdzania implementacj danego systemu. System ten jest
implementowany i wdraany podczas tej fazy.
Celem Fazy H jest ustanowienie procesu zarzdzania zmianami dla nowej bazowej architektury, ktra
jest osigana z momentem zakoczenia fazy nadzoru nad implementacj. W ramach tego procesu
prowadzi si cigy monitoring rozwoju technologicznego i zmian w rodowisku biznesowym w celu
decydowania czy formalnie zainicjowa nowy cykl rozwoju architektury.
W ramach zarzdzania wymaganiami podczas kadej fazy prace s walidowane pod ktem biecych
wymaga biznesowych, ktre steruj rozwojem architektury

Modelowanie systemw informatycznych / modelowanie obiektowe

Dwa podstawowe modele systemu informatycznego to model strukturalny i obiektowy.

W maych projektach z maym zespoem nie stosuje si modelowania systemw.
Proces projektowania oprogramowania bazuje na cyklu iteracyjnym
Model systemu to inaczej metafora systemu.
W modelu obiektowym opis systemu to opis obiektw (atrybuty/cechy) i opis zalenoci midzy
nimi (zachowania/metody) diagram klas
Komunikacja midzy obiektami odbywa si w oparciu o komunikaty (obiekt otrzymujc komunikat
wykonuje odpowiedni metod)
Model UML jest graficzn reprezentacj systemu

Pojcie rzeczywiste => klasa

Cechy rzeczywistego obiektu => atrybuty obiektu
Operacje na obiekcie => metody obiektu
Podstawowe koncepcje obiektowoci
Abstrakcja definiujemy co naley zrobi, nie definiujemy jak
Hermetyzacja ukrywamy implementacj udostpniamy tylko funkcjonalno (przez interfejs)
Dziedziczenie moliwo utworzenia klasy na podstawie innej, ju istniejcej
Polimorfizm jedna nazwa (np. nazwa metody) moe oznacza rne (w sensie implementacji)
faktyczne metody
Asocjacje
Agregacja w programowaniu obiektowym tworzy si now klas z klas ju istniejcych
Kompozycja szczeglny przypadek agregacji, ktra oznacza skadanie si z obiektw skadowych,
ktre nie mog istnie bez obiektu gwnego

Wprowadzenie do analizy projektowania obiektowego

Rodzaje diagramw UML
Przypadkw uycia
Klas
Aktywnoci
Sekwencji
Stanw
Model UML:
stanowi zapis wiedzy na temat okrelonego zagadnienia
zawiera elementy oraz relacje pomidzy nimi
Diagramy UML stanowi tylko i wycznie wizualizacj fragmentw tego modelu
Nie wszystkie elementy modelu s przedstawiane na diagramach UML

Model kaskadowy
Model kaskadowy (waterfall model) proces tworzenia oprogramowania
Planowanie systemu (w tym specyfikacja wymaga)
Analiza systemu (w tym Analiza wymaga i studium wykonalnoci)
Projekt systemu (poszczeglnych struktur itp.)
Implementacja (wytworzenie kodu)
Testowanie (poszczeglnych elementw systemu oraz elementw poczonych w cao)
Wdroenie i pielgnacja powstaego systemu.

Jeli ktra z faz zwrci niesatysfakcjonujcy produkt cofamy si wykonujc kolejne iteracje a do
momentu kiedy otrzymamy satysfakcjonujcy produkt na kocu schodkw.
Model kaskadowy jest rzadko uywany z nastpujcych powodw:
Nie mona przej do nastpnej fazy przed zakoczeniem poprzedniej
Model ten posiada bardzo nieelastyczny podzia na kolejne fazy
Iteracje s bardzo kosztowne - powtarzamy wiele czynnoci
Tego typu modelu naley uywa wycznie w przypadku gdy wymagania s zrozumiae i przejrzyste,
poniewa kada iteracja jest czasochonna i wymaga duych wydatkw na ulepszanie.

Rational Unified Process (RUP)

RUP to proces iteracyjnego wytwarzania oprogramowania opracowany przez firm Rational Software
Corporation
RUP bazuje na zbiorze zasad inynierii programowania oraz najlepszych praktykach, na przykad:

iteracyjnym wytwarzaniu oprogramowania (Iterative Development)

zarzdzaniu wymaganiami (Requirement Management)

uywaniu architektury bazujcej na komponentach (Component-based architecture)

graficznym projektowaniu oprogramowania

kontroli jakoci oprogramowania (Quality Assurance)

procesu kontroli zmian w oprogramowaniu (Change Management)

Cykl ycia projektu:

faza rozpoczcia (inception phase) w fazie tej formuowany jest problem zagadnienie
biznesowe (business case). Przy opracowaniu tego zagadnienia okrela si jego kontekst (business
context); czynniki wpywajce na jego powodzenie (success factors) na przykad spodziewany
zwrot z inwestycji, zwikszenie udziau w rynku; oraz prognoz finansow. Dodatkowo uzupenia
si go o prosty model przypadkw uycia, plan projektu, wstpn analiz ryzyka oraz opis projektu
(gwne wymagania, ograniczenia, gwna funkcjonalno).
Faza opracowania (Elaboration phase) - W tej fazie projekt systemu nabiera ksztatw.
Przeprowadzona jest analiza dziedziny zagadnienia (ang. Domain Analysis nazywana te w
literaturze polskiej Analiz/Modelem Domeny) i budowana podstawowa architektura systemu.
Faza konstrukcji (Construction phase) - W fazie tej gwny nacisk pooony jest na budow
komponentw i innych funkcjonalnoci opracowywanego systemu. W tej fazie odbywa si
wikszo prac programistycznych. W wikszych projektach moe by wiele iteracji konstrukcji, w
celu podzielenia dziedziny przypadkw uycia na mniejsze, zarzdzalne poddziedziny. Pozwala to
take na szybsze przekazywanie czci prac (lub prototypw).
Faza przekazania systemu (Transition phase) - W tej fazie produkt przekazywany jest od zespou
programistycznego do uytkownikw kocowych (potocznie mwic: do produkcji). W tej fazie
znajduj si takie czynnoci jak: trening uytkownikw kocowych i administratorw, testy
akceptacyjne (testy beta). Sprawdzana jest zgodno produktu z miarami jakoci okrelonymi w
pierwszej fazie.
Dyscypliny
Dyscypliny inynierskie
Modelowanie biznesowe (Business modeling) - tumaczy w jaki sposb opisa wizj organizacji, w
ktrej bdzie wdroony system i jak pniej uy jej do opisania procesw, rl i odpowiedzialnoci
w organizacji.

Wymagania (Requirements) - opisanie tego, co system powinien robi. Wymagania zbierane s

przez analitykw, ktrzy odkrywaj je, klasyfikuj i dokumentuj. Proces zbierania wymaga
polega na dyskusji i uzgodnieniach pomidzy tworzcymi system a klientem.
Analiza i projekt (Analysis & Design) - tworzy model projektowy i opcjonalnie model analityczny
systemu. Model analityczny zapewnia abstrakcj od kodu rdowego to znaczy, suy on jako
wytyczne do stworzenia tego kodu. Model projektowy skada si z klas zorganizowanych w pakiety
i podsystemy z dobrze okrelonymi interfejsami. Suy to wyodrbnieniu komponentw w fazie
implementacji. Zawiera take opis, ktre obiekty klas wsppracuj w celu realizacji przypadkw
uycia.
Implementacja (implementation) - opisuje w jaki sposb zapewni reuywalno istniejcych
komponentw albo implementowa nowe komponenty ze zdefiniowan odpowiedzialnoci
tworzc system atwiejszy do utrzymania i zwikszajc reuywalno.
Testowanie (test) - Proces RUP proponuje podejcie iteracyjne, ktre oznacza testowanie od
pocztkowych faz projektu. Pozwala to na szybsze wykrywanie defektw i ograniczenie kosztw
ich usunicia. Testy s prowadzone w ramach wymiarw jakoci: wiarygodnoci, funkcjonalnoci,
osigw pojedynczych aplikacji oraz systemu (performance). RUP opisuje w jaki sposb testowa
w kadym z tych wymiarw w czasie trwania projektu.
Wdroenie (Deployment) - Celem wdroenia (deployment) jest udane wytwarzanie dystrybucji
produktu i dostarczanie oprogramowania kocowym uytkownikom.

Dyscypliny pomocnicze
Zarzdzanie zmian i konfiguracj (Configuration & Change Mgmt) konfiguracj (wersjonowanie,
rejestr zalenoci), zlecenia zmian, zarzdzanie stanami i miarami (nowy, zalogowany,
zatwierdzony, przypisany, zakoczony), przyczyny, natury, priorytety
Zarzdzanie projektem (Project Management) zarzdzanie zespoem, budetem, umowami,
ryzykiem, monitorwanie iteracji
rodowiskiem (Environment) licencje, sprzt (moc obliczeniowa, pojemno danych)