Studia Podyplomowe IT w Biznesie Rational Unified Process

E. Stemposz. Rational Unified Process, Wykład 5, Slajd 1 wrzesień 2002Powrót

Studia Podyplomowe IT w BiznesieRational Unified Process

Wykład 5Architektura: centralna rola

w RUPWykładowca:dr inż. Ewa Stemposz

[email protected]

Polsko-Japońska Wyższa Szkoła Technik Komputerowych

Warszawa


ZagadnieniaModele a RUP

Architektura – kolokwialnie

Definicja architektury

Architektura dawniej i dziś

Cel tworzenia architektury

Pojęcia związane z architekturą

Reprezentacja: kto korzysta z architektury

Reprezentacja: perspektywy architektoniczne

Model a perspektywa architektoniczna

Artefakty odnoszące się do architektury

Pracownicy związani z budową architektury

Rozwój oparty o komponenty

Prezentowany materiał został przygotowany w oparciu o publikację: Philippe Kruchten, The Rational Unified Process An Introduction, Addison-Wesley, 1999.


Modele a RUP

Model: semantycznie spójna abstrakcja systemu tworzona z pewnej perspektywy; kompletny opis systemu z pewnej perspektywy.

Sformułowanie „kompletny opis” oznacza tu, że żadna dodatkowa informacja nie jest potrzebna, aby zrozumieć system z danej perspektywy.

Pojedynczy model zwykle nie wystarcza do zrozumienia całości problemu i znalezienia odpowiedniego rozwiązania, zazwyczaj potrzebujemy ich wiele. Razem tworzą kompletny opis całości - muszą być wzajemnie spójne i nie redundantne.

Model nie jest rzeczywistością, stanowi jedynie opis rzeczywistości, jej uproszczenie.

Tworzenie modeli wspomaga zapanowanie nad realizacją dużych, złożonych systemów.

Znaczna część RUP poświęcona jest tworzeniu modeli.


Architektura - kolokwialnie

Załóżmy, że utworzono by krótki opisu systemu (max. 60 stron tekstu), który wystarczyłby projektantom, programistom, użytkownikom i menadżerom na:

zrozumienie tego, co system robi.

zrozumienie, jak system robi to, co ma zrobić.

pracę na fragmencie systemu.

rozwijanie systemu.

wykorzystanie części systemu do konstrukcji innego systemu.

Taki opis, można by nazwać opisem architektury systemu.

„Architektura jest tym, co pozostaje, gdy więcej nie można już odrzucić, by nadal nie tylko rozumieć co system robi, ale też umieć wytłumaczyć, jak pracuje.”

Tworzenie architektury jest jedną z aktywności (ale nie jedyną) realizowanych na etapie projektowania systemu.


Definicja architektury

W literaturze spotyka się wiele definicji architektury, RUP proponuje poniższą:Architektura systemu określa:

Organizację systemu, w tym: Podział na elementy strukturalne, co pociąga za sobą konieczność specyfikowania interfejsów tak, by można było określić zachowania elementów w trakcie współpracy. Agregację elementów strukturalnych.

Style architektoniczne, obowiązujące w danej organizacji, związane z budową elementów strukturalnych, specyfikacją interfejsów i składaniem mniejszych jednostek w większe. Architektura dotyczy nie tylko struktury i zachowań, ale także kontekstu: funkcjonalności, używalności systemu, wydajności, zdolności do szybkiego powstawania po błędach, możliwości ponownego wykorzystania elementów systemu, spójności, estetyki, itd.

Definicja jest długa, ale uwidacznia bogactwo, złożoność i liczbę aspektów, które należy brać pod uwagę podejmując decyzje architektoniczne.


Architektura dawniej i dziś (1)

Dawniej:

Cel prac nad architekturą nie zawsze był dobrze wyartykułowany, sama koncepcja pozostawała rozmyta, zawieszona pomiędzy wymaganiami, projektowaniem wysokiego poziomu a implementacją. Nie było akceptowanych powszechnie sposobów na reprezentowanie architektury. Jeśli już architektura powstała, brakowało porządnego opisu - całość tworzyła wrażenie produktu z pogranicza sztuki czy czarnej magii.

Opis z reguły przybierał postać dokumentu nie poddającego się zarządzaniu, składającego się z kilku diagramów z nieprecyzyjną semantyką rozumianą dobrze jedynie przez autorów diagramów.

Praca w taki sposób była możliwa, ponieważ większość systemów nie była ani zbyt duża ani zbyt złożona i nie występowały sytuacje krytycznego zagrożenia dla powodzenia projektów z powodu braku odpowiedniej architektury.



Wszechobecność produktów informatycznych we współczesnym świecie, ich szybki rozwój, złożoność świata a przez to złożoność systemów wspierających działalność człowieka spowodowały, że systemy budowane w sposób jak opisano poprzednio, przestały być skalowalne. Integracja nowych technologii wymaga przebudowywania systemów, a „stare” systemy nie są odporne na zmiany. Ponadto, budowa złożonych systemów wymaga większych zespołów, podziału pracy, a więc strukturalizacji. Nikogo dzisiaj nie dziwią statystyki mówiące o tym, że „słaba” architektura plus niedojrzałe procesy wytwórcze to bardzo częsta przyczyna niepowodzenia projektów.

Dzisiaj:

Wszystkie proste systemy zostały już zbudowane (?).

Zarządzanie złożonymi systemami pozostaje w polu zainteresowania wielu organizacji zajmujących się wytwarzaniem software’u. Występuje powszechna potrzeba do stosowania technologii ponownego użycia na szerokę skalę, w obrębie produktów danej organizacji czy też z wykorzystaniem aktywów dostępnych na rynku. Potrzebne są narzędzia wspierające budowę oprogramowania w taki sposób.



Każda organizacja, dla której problemy związane z architekturą systemów są istotne - ze względu na rodzaj działalności, jaki prowadzi - powinna rozważyć odpowiedzi na pytania związane z trzema poniższymi grupami zagadnień:

1. Zrozumienie celu: Dlaczego architektura jest ważna? Jakie korzyści może przynieść? Jak będziemy ją wykorzystywać?

2. Reprezentacja architektury: Ustanowienie sposobu reprezentacji architektury czyni to pojęcie mniej rozmytym, bardziej konkretnym, czymś co może być wykorzystywane do komunikowania się, może być komentowane, podlegać przeglądom, a ponadto może być systematycznie ulepszane.

3. Proces architektoniczny: Jak tworzyć i weryfikować architekturę, która spełni potrzeby projektu? Kto ma to robić? Jakie artefakty powinny być wytworzone? Jakie atrybuty powinny opisywać jakość procesu i wytworzonych artefaktów?


Cel tworzenia architektury (1)

1. Kontrola intelektualna

Architektura pozwala zdobyć i zachować kontrolę intelektualną nad projektem, ułatwia zapanowanie nad jego złożonością i wspomaga zarządzanie procesem integrowania systemu. Złożony system to coś więcej niż tylko suma wielu części i wiele kolejno podejmowanych niezależnych decyzji. Należy być wyposażonym w precyzyjne reguły dotyczące rozwijania (powiększania się) systemu, tak by ten proces był ciągle możliwy do ogarnięcia przez człowieka.

Integralność systemu - rozumiana jako stan bycia „jednością” zawsze była celem architektów systemowych. W RUP integralność rozumiana jest jako stan ciągły, co oznacza, że system na dowolnym etapie cyklu życiowego jest zawsze zintegrowany i stanowi spójną całość. Chodzi tu o uniknięcie ciężkich i bolesnych etapów integracji, gdy części systemu są „na siłę” dopasowywane jedna do drugiej.



2. Ponowne użycie Architektura, dzięki naciskowi położonemu na identyfikowanie elementów strukturalnych i specyfikowanie interfejsów, dostarcza efektywnej bazy dla ponownego użycia. Dotyczy to zarówno „wewnętrznego”, jak i „zewnętrznego” ponownego użycia. To pierwsze związane jest z identyfikacją wspólnych części, a drugie z wykorzystaniem gotowych produktów.

Architektura ułatwia realizowanie ponownego użycia na tzw. „wielką skalę”: ponowne użycie samej architektury w kontekście linii produktów, które adresują zmieniającą się w ramach jednej dziedziny problemowej, funkcjonalność. Trzeba rozwiązać problemy wynikające z potrzeby skalowalności, zidentyfikować elementy generyczne i zdefiniować punkty, w których produkty będą się różnić.

Architektura musi dostarczyć środków dla efektywnej komunikacji w trakcie realizacji projektu. Robi to ustanawiając wspólny zbiór referencji i wspólne słownictwo jako podstawę dla decyzji projektowych. Każdy uczestnik zna kontekst i granice tego fragmentu prac, które zostały mu przypisane.



Odpowiedzialność nie jest dzielona: fundamentalne decyzje, dotyczące struktury systemu, są podejmowane przez mały zespół architektów, a elementy strukturalne, które mają być wykonane są przypisywane do małych zespołów pracowników. Każdy zespół pracowników musi dobrze wiedzieć, za jakie elementy strukturalne odpowiada, musi znać interfejsy oraz dopuszczalne granice zmian.

3. Baza dla budowy produktu

W RUP, architektura dostarcza bazy dla zarządzania projektem. Zarówno harmonogram, jak i organizowanie zespołu są ustalane stosownie do potrzeb związanych z budową głównych komponentów: warstw i podsystemów.

Architektura (szerzej - cała praca wykonywana w fazie opracowywania) dostarcza bazy nie tylko dla zarządzania projektem, ale też dla rozwijania systemu w dalszych etapach: reguł dla projektowania, styli, mechanizmów, wzorców, - tego wszystkiego, co stanowi podstawę systematycznej, dobrze zorganizowanej pracy, inaczej: dojrzałego procesu.


Pojęcia związane z architekturą (1)

1. Styl architektoniczny

Zarówno architektura jako całość, jak i pojedyncza perspektywa architektoniczna, mogą mieć przypisany atrybut, zwany stylem architektonicznym. Styl architektoniczny, określony poprzez wybór szablonów, narzucenie sposobów opisu architektury czy wykorzystywanych narzędzi, redukuje zbiór możliwych form.

Przykłady styli: klient-serwer czy sterowany-zdarzeniami.

2. Mechanizm architektoniczny

Mechanizmy architektoniczne dostarczają rozwiązania dla pewnej klasy problemów, jak np. pojedyncza klasa czy grupa klas. Mechanizmy architektoniczne umiejscawiane są z reguły w średnich i niższych warstwach architektury i wykorzystywane głównie jako środek do szybkiej implementacji pożądanych rozwiązań.

Przykłady mechanizmów: SZBD czy serwer transakcji.


Pojęcia związane z architekturą (2)

3. Wzorzec architektoniczny

Wzorzec architektoniczny specyfikuje rozwiązanie dla problemu, który powtarza się w określonych sytuacjach projektowych. Wzorce dotyczą bytów na wyższym poziomie abstrakcji niż klasy czy komponenty, stanowiąc rodzaj opisu dla istniejących, sprawdzonych w praktyce, doświadczeń ekspertów. Przykład wzorca: Object Request Broker (ORB).

Wzorce architektoniczne w inżynierii oprogramowania mają podobne znaczenie do wzorców w innych dziedzinach inżynieryjnych. Np. w budownictwie słowo „wieżowiec” przywodzi na myśl bardzo wysoki budynek o określonym kształcie, zbudowany ze stali, a nie z drzewa i z pewnością wyposażony w windy.

Wzorce architektoniczne są bytami o „większej skali” niż mechanizmy architektoniczne.

Korzystanie z wzorców daje w efekcie jednolite słownictwo, a przez to zapewnia jednolite rozumienie reguł leżących u podstaw projektowania - dzięki temu wzorce doskonale nadają się do dokumentowania architektury.


Reprezentacja: kto korzysta z architektury

Kto korzysta z architektury:

Analityk systemowy, który w oparciu o architekturę artykułuje i organizuje wymagania na system (uwzględniając ryzyka i ograniczenia technologiczne). Użytkownik końcowy (lub klient), który używa architekturę do wizualizacji - do zrozumienia tego, co kupuje - na wysokim poziomie abstrakcji.

Kierownik projektu, który w oparciu o architekturę organizuje zespół i ustala harmonogram prac. Projektanci, wykorzystują architekturę do zrozumienia reguł i ustalenia granic fragmentu, za który są odpowiedzialni.

Jeśli system jest otwarty, inne organizacje wytwarzające software, aby rozpoznać, jak korzystać z interfejsów.

Podwykonawcy, aby ustalić granice dla własnych prac. Architekci, wykorzystujący istniejącą architekturę do rozważań o ewolucji czy możliwościach ponownego wykorzystania.


Reprezentacja: perspektywy architektoniczne (1)

W innych dziedzinach inżynieryjnych, np. budownictwie, używane są różne rodzaje opisów czy planów (blueprints: światłokopie) do specyfikowania różnych aspektów projektowanej konstrukcji, takich jak np.: plan pięter, elewacja, okablowanie elektryczne, kanalizacja, ogrzewanie, wentylacja, itd. Jeden rodzaj opisu przykrywa jeden aspekt architektury i jest wykorzystywany przez jedną kategorię uczestników projektu, nie mniej jednak opisy nie są niezależne - muszą być wzajemnie spójne. W budownictwie - dzięki latom doświadczeń - opisy zostały zestandaryzowane i są doskonale rozumiane i wykorzystywane przez ludzi zaangażowanych w realizację projektów.

Wzorem bardziej zaawansowanych dziedzin inżynieryjnych, powinno się podobnie postępować przy produkcji oprogramowania. Można wyspecyfikować kilka podstawowych perspektyw, zwanych perspektywami architektonicznymi, które adresują różne aspekty produktu programistycznego, jak np.:

funkcjonalność systemu, jego logiczną organizację, wpółbieżność, fizyczne rozmieszczenie elementów składowych na konkretnej platformie.



Perspektywa architektoniczna będąc uproszczonym opisem systemu (rodzajem abstrakcji), przykrywa pewne aspekty, a omija inne, nierelewantne z danego punktu widzenia. Tworzenie każdej perspektywy wymaga zidentyfikowania:

Tego, na czym należy skupić uwagę tworząc daną perspektywę.

Uczestników projektu, zainteresowanych powstaniem perspektywy.

Elementów, które powinny zostać uchwycone w opisie.

Sposobu reprezentowania elementów (dotyczy to również relacji między nimi).

Zasad organizacyjnych, które powinny stanowić bazę (przewodnik, zbiór wytycznych) dla budowy perspektywy.

Najlepszego procesu, który mógłby być wykorzystany do budowy perspektywy.

RUP sugeruje podejście oparte na pięciu perspektywach: logicznej, implementacyjnej, procesowej, wdrożeniowej i przypadków użycia.



Perspektywalogiczna

Perspektywaimplementacyjna

Perspektywaprocesowa

Perspektywawdrożeniowa

Perspektywaprzypadków

użycia

Użytkownicy końcowiFunkcjonalność

ProgramiściZarządzanie software’m

IntegratorzyWydajnośćSkalowalność

Inżynierowie systemowiTopologia systemuWypuszczenie, instalacjaKomunikacja

Analitycy/testerzyZachowanie

Pięć perspektyw architektonicznych



Perspektywa logiczna

Adresuje wymagania funkcjonalne na system, innymi słowy - określa co system powinien robić dla użytkowników końcowych.

Identyfikuje główne pakiety, podsystemy, klasy (wszystko, co składa się na model projektowy systemu).

Perspektywa implementacyjna

Opisuje organizację modułów systemu (kodu źródłowego, plików z danymi, komponentów, plików z kodem wykonawczym, itd.) w środowisku implementacji w terminach warstw i pakietów oraz w terminach zarządzania konfiguracją (prawa własności, strategie wypuszczania, itd.).

Perspektywa procesowa

Adresuje wszystko, co jest związane ze współbieżną (równoległą) pracą systemu: zadania, wątki, procesy i ich wzajemne interakcje. Ponadto, zajmuje się elementami, takimi jak: startup i shutdown systemu, tolerancja błędów, deadlock, czas odpowiedzi, skalowalność, itp.



Perspektywa wdrożeniowa

Opisuje, w jaki sposób komponenty czasu wykonania (i obiekty) są mapowane na węzły obliczeniowe platformy.

W tym miejscu inżynieria oprogramowania spotyka się z inżynierią systemową.

Adresuje elementy takie, jak: rozmieszczenie, instalacja.

Perspektywa przypadków użycia

Ta perspektywa pełni specjalną rolę w definiowaniu architektury. Składa się z kilku głównych scenariuszy (lub przypadków użycia). Początkowo - na wstępnym etapie tworzenia architektury (w fazie początkowej i opracowywania) - scenariusze te spełniają funkcję przewodnika. Później stanowią podstawę do weryfikowania innych perspektyw - medium do ilustracji pracy perspektyw.


Model a perspektywa architektoniczna (1)

Model stanowi kompletną reprezentację adresującą pewne aspekty systemu.

Perspektywa architektoniczna, w przeciwieństwie do modelu, nie stanowi kompletnej reprezentacji systemu, ale skupia się na tych elementach, które są architektonicznie istotne.

Co oznacza sformułowanie: architektonicznie istotne? Architektonicznie istotny jest element, który wywiera znaczący wpływ zarówno na strukturę systemu, jak i na jego wydajność, odporność na błędy, skalowalność i ewolucyjność, itp. Element architektonicznie istotny jest ważny dla zrozumienia systemu.

Do takich elementów można zaliczyć: Najważniejsze klasy, a w szczególności klasy modelujące główne encje biznesowe. Mechanizmy architektoniczne, które pozwolą na przypisanie zachowania do klas, np. mechanizm zapewnienia trwałości czy mechanizmy komunikacyjne.


Model a perspektywa architektoniczna (2)

Wzorce i szablony. Interfejsy. Główne procesy czy wątki sterowania.

Relacje między modelami a perspektywami architektonicznymi:

Model Perspektywa architektoniczna

Model projektowy Perspektywa logiczna

Model projektowy lub Perspektywa procesowamodel procesowy dla złożonych systemówModel implementacyjny Perspektywa implementacyjna

Model wdrożenia Perspektywa wdrożeniowa

Model przypadków użycia Perspektywa przypadków użycia


Artefakty odnoszące się do architektury (1)

RUP definiuje dwa główne artefakty związane z architekturą:

Opis architektury oprogramowania (SAD: Software Architecture Description): zawiera opis perspektyw architektonicznych odnoszących się do projektu.

Prototyp architektoniczny: Definiowanie i weryfikacja architektury to najważniejsze zadania fazy opracowywania. Żeby zweryfikować poprawność architektury i ocenić jej jakość w terminach, np.: wykonalności, wydajności, odporności na błędy, skalowalności i ewolucyjności, itp. trzeba zbudować prototyp architektoniczny.

Prototyp architektoniczny stanowi implementację elementów związanych z najbardziej ważkimi decyzjami projektowymi. Implementację wystarczającą do weryfikacji podjętych decyzji - np. poprzez pomiary czy testy. Z założenia, prototyp nie ma być tworem prowizorycznym, budowanym szybko i byle jak, do wykorzystania tylko na danym etapie rozwoju („quick-and-dirty throwaway prototype”). Ma być rozwijany dalej, przez całą fazę konstrukcji, tak by ostatecznie przybrać postać produktu finalnego.


Artefakty odnoszące się do architektury (2)

Opis architektury oprogramowania i prototyp architektoniczny stanowią podstawę dla konstruowania trzech następnych artefaktów:

Wytyczne dla projektowania: stanowią odzwierciedlenie podjętych wyborów, wybranych wzorców, szablonów, itp.

Struktura produktu w środowisku wdrażania: utworzona w oparciu o perspektywę implementacyjną.

Struktura zespołu projektowego: również zbudowana w oparciu o perspektywę implementacyjną.

Podsumowywując, w fazie konstrukcji, nacisk zostaje zostaje położony na rozbudowywanie prototypu, na dodawanie „mięsa” i „skóry” do szkieletu. Aktywności tego okresu odzwierciedlają to nastawienie: są poświęcone głównie uszczegóławianiu tego, co zostało już wytworzone. Żadne decyzje - rujnujące dotychczasowe osiągnięcia - nie powinny wystąpić w fazie konstrukcji.


Pracownicy związani z budową architektury

RUP specyfikuje, kto jest odpowiedzialny za budowę architektury: pracownik zwany Architektem.

Oprócz Architekta, w definiowanie i implementację architektury wciągnięci są też inni pracownicy – szczególnie w fazie opracowywania:

Projektanci: ich uwaga skupiona jest na projektowaniu ważnych architektonicznie klas (bez detali w samych klasach) i mechanizmów architektonicznych.

Integratorzy: integrują główne komponenty oprogramowania. Prace te są wykonywane - nawet w przypadku szczątkowej implementacji - by zweryfikować poprawność interfejsów. Podstawowy cel to zminimalizowanie ryzyka związanego z integracją komponentów, przede wszystkim tych zakupywanych lub „z odzysku” (ponowne użycie).

Testerzy: do ich zadań należy przetestowanie prototypu pod kątem wydajności, odporności na błędy, itp.


Rozwój oparty o komponenty (1)

RUP wspiera rozwój oprogramowania w oparciu o komponenty (CBD: Component Based Development). Celem jest tu budowa systemów o odowiednio wysokiej jakości, wypełniających pożądane potrzeby biznesowe i budowanych szybko - raczej poprzez składanie z gotowych części niż poprzez wypracowywanie każdego elementu samodzielnie. Taki sposób pracy jest korzystny dla budowy np. rodziny aplikacji: niektóre komponenty opłaca się opracować samodzielnie, a niektóre warto odszukać wśród gotowych, istniejących już w organizacji czy na rynku i ewentualnie zaadaptować do aktualnych potrzeb. Definicja komponentu powinna być na tyle ogólna, by objąć zarówno komponenty występujące na rynku (COM, DCOM, CORBA, JavaBeans) jak i wszelkie złożone elementy, jak np.: strony Web, tabele baz danych, pliki wykonawcze, itp. Z drugiej strony zbyt ogólna definicja może uniemożliwić precyzyjne wyróżnienie potencjalnych artefaktów w projektowanym systemie.

Komponent stanowi nietrywialny, dobrze wydzielony z kontekstu fragment oprogramowania, spójny ze względu na wypełniane funkcje (wysoka kohezja, słabe sprzężenia) i z dobrze zdefiniowanym interfejsem. Można powiedzieć, że komponent dostarcza fizycznej realizacji dla interfejsu.


Rozwój oparty o komponenty (2)

RUP wyróżnia, w zależności od perspektywy, różne rodzaje komponentów:

Komponenty czasu wykonania (run time): wszystkie byty programistyczne istniejące w czasie wykonania na platformie software’owo-hardware’owej , jak np. pliki wykonawcze, procesy, biblioteki dynamiczne (DLL).

Komponenty widziane z perspektywy całości rozwoju oprogramowania w danej organizacji, np. podsystemy, które ze względu na wysoką kohezję i słabe sprzężenia mogą być wykorzystywane w innych projektach. Stanowią dobrą bazę dla wyboru zbioru komponentów czasu wykonania. Komponenty biznesowe: spójny zbiór obu powyższych rodzajów komponentów, stanowiących jednostki programowe dla obsługi np. sprzedaży, zamówień, wypuszczania produktów.

Pojęcia architektury i komponentu przeplatają się wzajemnie: architektura identyfikuje komponenty, specyfikuje ich interfejsy i interakcje w różnych wymiarach, z kolei komponent nie istnieje bez konkretnej architektury.

Date post:	11-Jan-2016
Category:	Documents
Upload:	cardea
View:	40 times
Download:	1 times

Studia Podyplomowe IT w Biznesie Rational Unified Process

Documents