Niniejsza praca ma na celu zaprezentowanie idei inżynierii oprogramowania systemów zorientowanych na usługi (SOA) oraz architektonicznego podejścia do ich projektowania i implementacji. Jako przykład systemu SOA przedstawiono aspekt serwisu webowego służący planowaniu imprez. Następnie opisano zastosowanie meta-architektury PCBMER-A jako fundamentu budowy systemów zorientowanych na usługi oraz jej cechy, istotne z punktu widzenia inżynierii oprogramowania SOA. W podsumowaniu przedstawia się propozycje modyfikacji i rozszerzeń powyższego rozwiązania oraz potencjalne regiony zastosowań

1. Rola projektowania architektonicznego w inŜynierii
oprogramowania zorientowanej na usługi
Wojciech Podgórski
w.podgorski@student.pwr.wroc.pl
Abstract. Niniejsza praca ma na celu zaprezentowanie idei inŜynierii
oprogramowania systemów zorientowanych na usługi (SOA) oraz
architektonicznego podejścia do ich projektowania i implementacji. Jako
przykład systemu SOA przedstawiono aspekt serwisu webowego słuŜący
planowaniu imprez. Następnie opisano zastosowanie meta-architektury
PCBMER-A jako fundamentu budowy systemów zorientowanych na usługi
oraz jej cechy, istotne z punktu widzenia inŜynierii oprogramowania SOA. W
podsumowaniu przedstawia się propozycje modyfikacji i rozszerzeń
powyŜszego rozwiązania oraz potencjalne regiony zastosowań.
Keywords: PCBMER-A, Service Oriented Architecture, Aspect Oriented
Programming, design patterns, object oriented practices, web services,
integration, interoperability
1 Wprowadzenie
Prawie od samego początku powstawania zintegrowanych systemów
informatycznych, jednym z ich głównych celów było wspomaganie szeroko
rozumianego biznesu. Poczynając od klasycznych problemów takich jak bankowość
elektroniczna (np. usługi kredytowe) przez elektroniczne hurtownie towarów
(systemy B2B), aŜ po wyszukiwarki najniŜszych cen i portale aukcyjne (systemy B2C
i C2C), biznes elektroniczny (e-Bussiness) stanowił i wciąŜ stanowi jedną z
najwaŜniejszych domen Internetu. Pomimo dość długiego okresu rozwoju tej
dziedziny wciąŜ, istnieją fundamentalne problemy związane z efektywną, zarówno
implementacją, jak i późniejszą eksploatacją i pielęgnacją zintegrowanych systemów
obsługi biznesu. Problemy te moŜna podzielić na kilka warstw abstrakcji:
1. Warstwę wymiany danych – głównym problemem jest integracja na
poziomie fizycznym, dane wymieniane między systemami posiadają inną
reprezentację (zaleŜną od platformy), nadawcy i odbiorcy danych są z góry
ustaleni i „zaszyci” w systemie, występuje niezgodność parametrów (np. inny
format daty) , synchroniczna wymiana danych.
2. Warstwę komunikacji – problem stanowi umiejętny i odpowiedni do sytuacji
dobór sposobu komunikacji między systemami, oparty na jednym z

2. paradygmatów interoperacyjności takich jak zorientowanie na proces (process
oriented interoperability), zorientowanie na interfejsy (interface oriented
interoperability) itp.
3. Warstwę architektury – problem stanowi budowa i architektura systemu,
projektując, implementując a później pielęgnując system naleŜy odpowiedzieć
na takie pytania jak: jak osiągnąć duŜą skalowalność, w jaki sposób uzyskać
efektywną komunikację z róŜnego rodzaju systemami (heterogeniczność
systemów współpracujących), jak zapewnić systemowi adaptacyjność, czy
system powinien być samo opisujący się (semantyczny), itp.
Próby rozwiązania powyŜszych problemów i opracowania standardów przetwarzania
rozproszonego oraz efektywnych technik e-Biznesu sięgają lat 70-tych XX wieku,
kiedy opracowano technikę RPC (Remote Procedure Call). Kolejne rozwiązania
zarówno usprawniały dotychczasowe jak i wprowadzały nowe podejścia. W latach
90-tych wprowadzono komunikację opierającą się na przetwarzaniu komunikatów
(message processing), natomiast po roku 2000 zaprezentowano EAI - korporacyjną
integrację aplikacji (Enterprise Application Integration). Najnowszym podejściem do
projektowania zintegrowanych systemów wspomagających biznes jest SOA.
1.1 SOA (Service Oriented Architecture)
SOA czyli architektura zorientowana na usługi jest stylem, a zarazem zbiorem zasad
wytwarzania i integracji aplikacji. Główny nacisk kładziony jest na promowanie i
stosowanie otwartych standardów definiujących usługi, komunikację i wymianę
danych oraz architekturę serwisów spełniających wymagania uŜytkownika.
Oprogramowanie wytworzone zgodnie z SOA cechuje się bardziej składaniem
funkcjonalności z istniejących rozwiązań, niŜ implementacją nowych od początku
(np. choreografie web service’ów). Ponadto opiera się na idei programowania
obiektowego, proceduralnego oraz zorientowanego na dane, łącząc wszystkie
najlepsze cechy powyŜszych. Architektura poprawnie zbudowanej aplikacji SOA z
załoŜenia cechuje się:
• modularnością (modularity)
• enkapsulacją (encapsulation)
• luźnymi powiązaniami (loose coupling)
• separacją aspektów (seperation of concerns)
• ponownym uŜyciem (reuse)
• kompozytową i niezaleŜną implementacją (composite & stand-alone
implementation)
PoniŜej przedstawia się przykład aplikacji realizującej usługi zgodnie z SOA oraz
wpływ projektowania architektonicznego z uŜyciem meta-architektury PCBMER-A
na osiągnięcie zgodności z SOA oraz zwiększenie integracji i interoperacyjności
wytwarzanego oprogramowania.

3. 2 Studium przypadku
SOA definiuje czym powinno cechować się wytworzone zgodnie z nią
oprogramowanie oraz jak powinno być zbudowane (zorientowanie na usługi). Nie
definiuje jednak sposobu (oprócz sugestii zgodności ze standardami) osiągnięcia
jakości (qualities) aplikacji w niej zbudowanych. Stąd kluczowym aspektem budowy
kaŜdego systemu zgodnego z SOA jest poprawny i efektywny projekt
architektoniczny, który nie tylko opisuje w jaki sposób zbudować zgodność z SOA,
ale takŜe proponuje rozwiązania problemów postawionych w punkcie 1. Aby lepiej
zrozumieć w jaki sposób poprawnie budować aplikacje SOA, zgodnie z przyjętymi
załoŜeniami architektonicznymi posłuŜymy się przykładem.
Problem: decentralizacja procesu organizacji na podstawie przykładu zaplanowania
imprezy okolicznościowej
wynajęcie sali wynajęcie firmy
(A) (B)
lista gości miejsce czas catering
lista prezentów
zaproszenia
rezerwacja
prezentów
Rys. 1. Proces organizacji imprezy urodzinowej
RozwaŜmy proces jakim jest organizacja imprezy urodzinowej. Pierwszym krokiem
jest ustalenie listy gości obecnych na imprezie. Następnie dokonuje się wyboru
miejsca imprezy, który wiąŜe się z rezerwacją sali. Gospodarz wybiera w serwisie A
salę do wynajęcie i dokonuje procesu rezerwacji sali na określony termin. Znając
szczegóły odbycia się imprezy, gospodarz tworzy zaproszenia dla wszystkich gości i
wysyła je pocztą. Kolejnym krokiem jest dokonanie wyboru firmy cateringowej w
serwisie B, obsługującej imprezę, oraz ustalenie szczegółów związanych z usługą.
Ostatnią rzeczą jest ustalenie listy prezentów, które gospodarz chciałby otrzymać od
zaproszonych gości.
Tak zdefiniowany proces wymaga odwołania się do dwóch zewnętrznych instytucji
(serwis A i B) oraz sporządzenia zaproszeń i listy prezentów. Łatwo zauwaŜyć, Ŝe

4. proces organizacji cechuje się duŜym stopniem decentralizacji – kontakt z firmami
zewnętrznymi, wysyłanie zaproszeń. Problem ten nie tylko sprawia dyskomfort
uŜytkownikowi, ale przede wszystkim wiąŜe się z innymi problemami, takimi jak:
brak gwarancji zapewnienie unikalności prezentów, firma cateringowa nie obsługuje
danego miejsca (zbyt daleka lokalizacja), zaproszenia nie dochodzą na czas itp.
Rozwiązaniem postawionych problemów moŜe być utworzenie prostego serwisu
webowego (Organizator), skupiającego wszystkie powyŜsze funkcjonalności w
jednym miejscu, korzystającego z innych serwisów oraz oferującego własne usługi.
deployment Organizator
«Web Service» «J2EE Server»
Serw is A Organizator (PCBMER-A)
Baza danych
System pocztow y
Gość
«Web Service»
Serw is B
«Web Service»
MenadŜer «WWW»
Interfej s uŜytkow nika
Prezentów Portal społecznościow y
«Web Service»
Google Maps
«Web Service»
Porów nyw arka
Gospodarz Cen
Rys. 2. Diagram rozmieszczenia dla serwisu Organizator, ukazujący architekturę SOA oraz
choreografię serwisów w systemie
Serwis Organizator, zbudowany zgodnie z SOA, wykorzystuje usługi oferowane
przez inne serwisy, oferując przy tym własne usługi. Główną częścią systemu jest
aplikacja Organizator oparta na meta-architekturze PCBMER-A, która korzysta z
usług oferowanych przez Serwisy A i B. Teraz Gospodarz imprezy korzystając z
interfejsu uŜytkownika Organizatora, jest w stanie w jednym miejscu wynająć salę
oraz zamówić catering na planowaną imprezę. Korzystając z dodatkowych serwisów
takich jak np. Google Maps jest w stanie znaleźć najbliŜsze interesującego go lokacje
dające moŜliwość zorganizowania imprezy, a takŜe firmy, które zapewnią catering,
ponadto jest w stanie pokazać zaproszonym gościom w którym dokładnie miejscu
odbędzie się impreza. Chcąc zaprosić gości, nie jest zmuszony do wysyłania ręcznie
tworzonych zaproszeń, poniewaŜ moŜe zautomatyzować ten proces wprowadzając
jedynie listę zaproszonych do systemu pocztowego, który automatycznie wyśle
zaproszenia do wszystkich, korzystając z wbudowanego szablonu wiadomości. Po
utworzeniu listy prezentów, goście zarejestrowani w zewnętrznej aplikacji np.
serwisie społecznościowym, są w stanie pobrać listę prezentów oraz zarezerwować
prezent, który chcą kupić gospodarzowi, aplikacja Organizator nie tylko udostępnia
usługi związane z zarządzaniem listą prezentów w postaci Web Service’u, ale takŜe
korzysta z usług zewnętrznych porównywarek cen, tak aby gość mógł wybrać gdzie
kupi prezent najtaniej.
Projektując i implementując system zgodnie z SOA uzyskano nie tylko centralizację
procesu organizacji, ale równieŜ zwiększenie elastyczności rozwiązania, które

5. pozwala na dynamiczne dodawanie i usuwanie usług z których korzysta i które
oferuje system. Tak jak zostało wspomniane powyŜej kluczowym aspektem w
wytwarzaniu systemu był projekt architektoniczny i uŜycie meta-architektury
PCBMER-A.
3 SOA w kontekście meta-architektury PCBMER-A
Rozpatrując SOA w kontekście meta-architektury PCBMER-A naleŜy wyjść od
podstawowego stwierdzenia, iŜ obie koncepcje mają wspólny cel – zapewnić
systemowi adaptacyjność. Z punktu widzenia biznesu w SOA cecha adaptacyjności
tworzonych aplikacji jest najistotniejsza, ze względu na wciąŜ zmieniające się
wymagania. Zmiany tych wymagań propagują nie tylko tworzenie nowych rozwiązań,
ale przede wszystkim dopasowywanie istniejących do panujących warunków. Stąd
budowanie aplikacji adaptacyjnych jest kluczowym wymogiem SOA.
3.1 Adaptacyjność
Adaptacyjność rozumiana jako połączenie skalowalności (scalability), zrozumiałości
(understandability) oraz pielęgnowalności (maintainability) stanowi istotę PCBMER-
A. Zwiększenie pielęgnowalności systemu w SOA pozwala na dołączanie nowych
funkcjonalności małym kosztem, oferowanie i korzystanie z nowych usług oraz ciągły
rozwój aplikacji. Zrozumiałość systemu to nie tylko przejrzysta implementacja, łatwa
w rozwoju i konserwacji, ale równieŜ tolerancja na pewne zewnętrzne zachowania,
które mogą zostać przewidziane i poprawnie obsłuŜone. Skalowalność systemu
pozwala na zapewnienie coraz wydajniejsze pracy w miarę zwiększania zasobów. W
PCBMER-A adaptacyjność jest rozumiana jako wyznacznik zarządzania złoŜonością.
Stąd w meta-architekturze główną ideą zwiększenia adaptacyjności jest minimalizacja
zaleŜności pomiędzy bytami w niej występującymi. W celu kontrolowania złoŜoności,
nie moŜna dopuścić do niekontrolowanych połączeń pomiędzy bytami - tworzenie się
sieci bytów P2P (kaŜdy z kaŜdym) powoduje, Ŝe liczba zaleŜności rośnie
wykładniczo. Rozwiązaniem jest stosowanie hierarchii, w których wzrost liczby
zaleŜności spada do wielomianowego. Ponadto ułoŜenie bytów w hierarchie
powoduje zrozumiałość kaŜdej z występujących relacji (zaleŜności). Kluczem do
poprawnego zarządzania złoŜonością, a co za tym idzie zwiększenia adaptacyjności,
jest zdawanie sobie sprawy z kaŜdej istniejące w systemie zaleŜności oraz rozumienie
jej sensu. Tylko tak sprecyzowana zaleŜność moŜe zaistnieć w systemie, nie mając
negatywnego wpływu na jego jakości.
PCBMER-A uzyskuje cechę adaptacyjności poprzez budowę warstwową (layers)
oraz ścisłą definicję występowania zaleŜności pomiędzy bytami, opisaną siedmioma
zasadami:
1. zasada zaleŜności w dół (downward dependency principle)
2. zasada powiadamiania w góre (upward notification principle)
3. zasada komunikacji z sąsiadami (neighbor communication principle)

6. 4. zasada jawnych asocjacji (explicit association principle)
5. zasada eliminacji cykli (cycle elimination principle)
6. zasada nazywania klas (class naming principle)
7. zasada pakietu znajomości (acquaintance package principle)
PowyŜsze zasady określają w jaki sposób byty zawarte w warstwach mogą ze sobą
współpracować, tak aby zaleŜności między nimi były zminimalizowane.
Odstępstwem są zasady numer 6 i 7, które mówią odpowiednio: w jaki sposób
odpowiednio nazywać klasy oraz interfejsu oraz manifestują istnienie oddzielnej
warstwy, w której przechowywane są interfejsy słuŜące do bardziej złoŜonej
komunikacji pomiędzy bytami, nie stosującej się do zasad 1-5.
3.2 Cechy architektoniczne SOA i PCBMER-A
Zasady budowy meta-architektury PCBMER-A niemal całkowicie przekładają się na
cechy architektury SOA. Modularność oraz separacja aspektów, osiągana jest przez
zastosowanie oraz oddzielenie od siebie sześciu warstw: Prezentacji (Presentation),
Ziaren (Bean), Kontrolera (Controller), Mediatora (Mediator), Encji (Entity) oraz
Zasobów (Resource). Byty zlokalizowane w danej warstwie odpowiadają za
realizację pewnego aspektu i nie mogą zostać przeniesione do innych warstw, razem
stanowią nierozłączny moduł. Z separacji aspektów w PCBMER-A, wynika równieŜ
luźne powiązanie, poniewaŜ byty które skupiają odpowiedzialność na jednym
aspekcie cechują się wysoką kohezją, która z kolei implikuje luźne powiązanie. Meta-
architektura PCBMER-A jest oparta na idei holarchii, byty w niej występujące
(zarówno warstwy, klasy jak i interfejsy) są holonami, wykazującymi naturę zarówno
części jak i całości. Interpretując holon jako część zakładamy, iŜ jest on analitycznie
złoŜony i posiada wewnętrzne relacje, niewidoczne z zewnątrz, stąd kaŜdy holon
cechuje się enkapsulacją. Holony są złoŜone i mają charakter rekursywny,
architektura SOA zakłada kompozytową (composite) implementację, PCBMER-A
wprowadza rozróŜnienie pomiędzy bytem złoŜonym (complex), a składanym
(compound) w postaci aspektu relacji wewnętrznych. W przypadku pierwszego
relacje wewnętrzne są istotne i świadczą o jego naturze, w przypadku drugiego są
nieistotne. JeŜeli załoŜyć, Ŝe kompozyt jest zbliŜony znaczeniowo to bytu złoŜonego
(kompozyt1 - materiał złoŜony z co najmniej dwóch składników, mający właściwości
lepsze od nich lub nowe) to moŜna powiedzieć, Ŝe PCBMER-A w pełni implementuje
koncepcję SOA. Ostatnią cechą jest ponowne uŜycie, jako Ŝe PCBMER-A jest meta-
architekturą, oznacza to Ŝe kaŜda jej instancja (architektura) moŜe być dopasowana do
odrębnego problemu, stąd uzyskuje się najwyŜszy poziom ponownego uŜycia.
1 Słownik Języka Polskiego PWN

7. 4 Rozszerzenia PCBMER-A
Meta-architektura PCBMER-A wywodzi się z lat doświadczeń w dziedzinie inŜynierii
oprogramowania dlatego cięŜko, jest zaproponować rozszerzenie lub modyfikację, nie
popartą odpowiednimi argumentami.
4.1 Programowanie aspektowe
Jedną z rzeczy, która naturalnie wynikają z istoty meta-architektury PCBMER-A są
aspekty. PCBMER-A minimalizując zaleŜności stara się oddzielić w jak największym
stopniu byty ze sobą funkcjonalnie niezwiązane. W tym celu wykorzystuje się
architekturę warstwową oraz paradygmat programowania obiektowego.
Programowanie obiektowe z idei jednak, jest pionową kompozycją w procesie
kompozycji oprogramowania. Kompozycję poziomą stanowi właśnie paradygmat
programowania aspektowego. Programowanie aspektowe stara się maksymalnie
oddzielić od siebie funkcjonalnie odrębne części oprogramowania co prowadzi do
najlepszej modularności, zwiększenia kohezji, nie tylko klas ale całych modułów i w
konsekwencji wzrostu adaptacyjności. W czasie projektowania wyróŜnia się odrębne
aspekty dla oddzielnych jakości oprogramowania takich jak: bezpieczeństwo,
niezawodność, wydajność itd. Następnie w tzw. procesie „tkania” (weaving) integruje
się ze sobą poszczególne aspekty i wyznacza punkty w których ze sobą współpracują.
Zalety tworzenia aspektów moŜna zauwaŜyć nawet w odniesieniu do SOA. JeŜeli
potraktować kolaborację (dąŜenie elementów(ról), poprzez wykonywanie
wyspecjalizowanych funkcji, do wspólnego osiągnięcia poŜądanej funkcjonalności)
jako aspekt, moŜna sobie wyobrazić, Ŝe Web Service realizujący jedną
funkcjonalność jest właśnie kolaboracją grupy bytów (klas, interfejsów). Idąc dalej
jeŜeli grupa takich Web Service’ów w SOA jest odpowiedzialna za wspólną realizację
procesu biznesowego, to moŜna powiedzieć, Ŝe programowanie aspektowe jak i idea
aspektów wspiera zarówno rozumienie jak i implementację procesów biznesowych, a
co się z tym wiąŜe całą SOA. Warto więc rozwaŜyć aplikację aspektów do PCBMER-
A jako przynajmniej opcjonalną część architektury.
4.2 Projekt warstwy Resource
Warstwa Zasobów jest odpowiedzialna za wszelką komunikację z zewnętrznymi
persystantnymi źródłami danych oraz innymi systemami oferującymi/Ŝądającymi
usługi. Jak w kaŜdym systemie warstwa odpowiedzialna za komunikację z bazą
danych, moŜe stać się bardzo łatwo wąskim gardłem, drastycznie ograniczającym
wydajność. Dlatego projekt tej warstwy jest kluczową sprawą w aspekcie wydajności,
i nie tylko. Dobranie odpowiednich wzorców projektowych do serializacji danych i
obsługi transakcji w kontekście persystancji jest bardzo istotną rzeczą, stąd zanim
przejdzie się do implementacji tej warstwy zawsze naleŜy rozwaŜyć takie problemy
jak częstotliwość i rodzaj zapytań, rodzaj medium persystancji (baza danych, pliki,

8. hurtownia danych), architektura medium persystancji, typ problemu (baza danych
genotypów człowieka, baza danych wypoŜyczalni samochodów).
Drugim powodem, dla którego warstwa Zasobów powinna być dobrze
zaprojektowana, jest koncepcja PCBMER-A, która mówi, Ŝe warstwy na niŜszym
poziomie powinny być bardziej stabilne niŜ warstwy na wyŜszym poziomie. Warstwa
Resource znajduje się na samym dole hierarchii, stąd powinna mieć największą
stabilność (wszystkie wyŜsze warstwy są od niej pośrednio zaleŜne). W ogólności
moŜna powiedzieć, Ŝe jeŜeli współczynnik stabilności (Instability) zdefiniujemy jako:
. (1)
gdzie Ca (afferent coupling) to liczba zaleŜności przychodzących a Ce (efferent
coupling) liczba zaleŜności wychodzących, to
IResource → 0 . (2)
4.3 Podział warstwy Resource
Warstwa Zasobów stanowi podstawę PCBMER-A, jednak z punktu widzenia
funkcjonalności, skupia za duŜo odpowiedzialności. Propozycja modyfikacji polega
na podziale warstwy Resource na dwie (róŜne w zaleŜności od sytuacji):
Warstwa pierwotna: Po podziale: Opis:
External Resource Zew. źródła danych + komunikacja
Resource
Internal Resource Wewnętrzne źródła danych
Communication Komunikacja
Resource
Persistance Wewnętrze i zewnętrzne źródła danych
Pierwszy podział dzieli warstwę Resource na External Resource i Internal Resource.
Warstwa Zasobów Zewnętrznych jest odpowiedzialna za wszelką komunikację (Web
Service’y, RMI, Sockets itp.) oraz zewnętrzne persystantne źródła danych, tzn. takie z
system korzysta ale nie moŜe nimi zarządzać. Warstwa Wewnętrznych Zasobów
odpowiada za wewnętrzne persystantne źródła danych tzn. takie, którymi moŜe
zarządzać i ma do nich pełne prawa.
Drugi podział dzieli warstwę Resource na Communication i Persistance. Warstwa
komunikacji odpowiada tylko i wyłącznie za wszelką komunikację (Web Service’y,
RMI, Sockets, Remote APIs, Message Processing itp.), natomiast warstwa
persystancji za persystantne źródła danych, zarówno wewnętrzne jak i zewnętrzne.
PowyŜszy podział nie tylko zwiększa stabilność architektury, ale równieŜ zmniejsza
ryzyko ze strony systemów zewnętrznych i wprowadza dekompozycję
odpowiedzialności na mniejsze jednostki.

9. 4.4 PCBMER-A i metodyki zwinne
Ostatnią propozycją jest integracja meta-architektury PCBMER-A z rodziną metodyk
zwinnych. Integracja, tak samo jak w przypadku SOA, odbywa się na wspólnej
koncepcji zapewnienia systemowi adaptacyjności. Metodyki zwinne z natury są
przygotowane na projekty o wysokim ryzyku i bardzo zmiennych wymaganiach, stąd
uŜycie PCBMER-A jako wzorca niezwykle elastycznego idealnie pasuje do tego
rozwiązania. Sprzeczność pojawia się w momencie projektowania architektonicznego.
Metodyki zwinne nie przewidują takiego projektowania, jednak jak najbardziej
korzystają z gotowych rozwiązań do ponownego uŜycia (wzorców projektowych)
dlatego w tym kontekście PCBMER-A moŜna potraktować jako wzorzec projektowy
gotowy do adaptacji i implementacji, szczególnie nadający się do zwinnych
projektów webowych o wciąŜ modyfikowanych i dodawanych funkcjonalnościach
(beta non-stop).
Bibliografia
1. Booch, g. (2007): The Economics of Architecture-First, IEEE Software, Sept/Oct, pp.18-
20
2. Maciaszek, L.A. (2007): Modeling and Engineering Adaptive Complex Systems,
Challenges in Conceptual Modelling. Tutorials, Posters, Panels and Industrial
Contributions to the 26th International Conference on Conceptual Modeling - ER 2007,
CRPIT No. 83, ed. J. Grundy, S. Hartmann, L. Laender, L. Maciaszek, J. Roddick, ACS,
pp.31-38
3. Maciaszek, L.A. (2008): Analiza Struktur ZaleŜności w Zarządzaniu Intencją
Architektoniczną Systemu (Dependency Structure Analysis for Managing Architectural
Intent), InŜynieria Oprogramowania – Od Teorii do Praktyki, ed. Z. Huzar, Z. Mazur,
Wydawnictwa Komunikacji i Łączności, Warszawa, pp.13-26. (invited paper)
4. Maciaszek, L.A. (2008): Architectural Design and Software Engineering of Adaptive
Complex Systems, series of lectures at Wroclaw University of Technology, Wrocław
2008