Rola projektowania architektonicznego w inżynierii oprogramowania zorientowanej na usługi
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Rola projektowania architektonicznego w inżynierii oprogramowania zorientowanej na usługi

  • 2,726 views
Uploaded on

Niniejsza praca ma na celu zaprezentowanie idei inżynierii ...

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ń

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
2,726
On Slideshare
2,722
From Embeds
4
Number of Embeds
2

Actions

Shares
Downloads
22
Comments
0
Likes
0

Embeds 4

http://www.lmodules.com 2
http://www.linkedin.com 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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