Architekturocentryczny proces opracowywania oprogramowania

Pełen tekst

(1)ARCHITEKTUROCENTRYCZNY PROCES OPRACOWYWANIA OPROGRAMOWANIA1 ANDRZEJ SOBCZAK Szkoła Główna Handlowa w Warszawie. Streszczenie Wraz ze wzrostem złoĪonoĞci struktury systemów oprogramowania w istotny sposób wzrosła rola architektury tych systemów. Jest to związane z odejĞciem od monolitycznych lub pracujących w trybie klient–serwer rozwiązaĔ na rzecz systemów pracujących w architekturze wielowarstwowej lub architekturze zorientowanej na usługi, a takĪe upowszechnienia siĊ rozwiązaĔ typu COTS. Z tego teĪ powodu zagadnienia związane z architekturocentrycznym procesem opracowywania tych systemów stało siĊ obszarem licznych prac badawczych jak i aplikacyjnych – zarówno w Ğrodowisku akademickim, jak i przemyĞle. Celem niniejszego artykułu jest zdefiniowanie cech wyróĪniających ten proces oraz okreĞlenie jego struktury. Słowa kluczowe: proces wytwarzania oprogramowania, architektura systemu oprogramowania, proces architekturocentryczny 1. PojĊcie procesu opracowywania systemów oprogramowania Aby powstał system oprogramowania, naley zastosowa pewn strategi jego opracowania, okrelon mianem procesu wytwórczego. S. Pressman definiuje proces wytwórczy jako schemat wykonywania pewnych zada, koniecznych do stworzenia dobrego systemu oprogramowania [14]. A. Kobyliski przytacza dwa ujcia procesu wytwórczego (okrelanego mianem procesu programowego). Zgodnie z pierwszym ujciem jest to ogół czynnoci, metod, praktyk i przekształce, które wykonuj ludzie, by opracowywa i konserwowa oprogramowanie oraz inne pokrewne produkty z nim zwizane (np. plan przedsiwzicia, projekt, kod, zestawy testów). W drugim ujciu jest to zbiór procesów stosowanych w organizacji lub w trakcie realizacji przedsiwzicia [tutaj: podczas opracowywania systemów oprogramowania – przypis autora], aby planowa , zarzdza , realizowa , monitorowa , kontrolowa i doskonali działania zwizane z wytwarzaniem oprogramowania [9]. P. Kruchten okrela proces wytwórczy jako uporzdkowane przydzielanie zada i zakresów odpowiedzialnoci w celu doprowadzenia do powstania systemu oprogramowania charakteryzujcego si wysok jakoci, spełniajcego potrzeby swoich uytkowników kocowych w ramach przewidywanego harmonogramu i budetu. Proces powinien opisywa „kto” robi „co”, „jak” i „kiedy” podczas opracowywania systemów oprogramowania [11].. 1 Artykuł został przygotowany w ramach realizacji projektu badawczego Ministerstwa Nauki i Szkolnictwa Wyszego nr N115 010 32/01443..

(2) 140. Andrzej Sobczak Architekturocentryczny proces opracowywania systemów oprogramowania. 2. Definicyjne ujĊcie architektury systemu oprogramowania M. Flasiski wskazuje na złoono jako podstawowe ródło problemów wystpujcych w trakcie konstrukcji systemów oprogramowania. Uwaa on, e po przekroczeniu pewnego progu złoonoci przestaje si panowa nad przygotowanym systemem, poniewa całociowe jego zrozumienie – w rónych jego aspektach i na dowolnym poziomie szczegółowoci – przekracza moliwoci człowieka [5]. P. Kruchten zauwaa wrcz: „obecnie, gdy wszystkie proste systemy s ju zbudowane, złoono wielkich systemów stała si problemem numer jeden dla przedsibiorstw tworzcych oprogramowanie” [11]. Architektura systemu – w ujciu ogólnym – definiowana jest jako struktura (lub zbiór struktur) tego systemu składajca si z okrelonych elementów, widzianych z zewntrz właciwoci tych elementów oraz zwizków midzy nimi. Na potrzeby niniejszego artykułu rozpatrywana jest architektura systemów oprogramowania. Pozwala ona zapanowa nad złoonoci tych systemów [17]. I. Graham stawia tez, e „nie ma dotychczas jasnej i jednoznacznej definicji tego, czym jest architektura systemu oprogramowania” [6]. Najlepszym na to dowodem jest fakt zgromadzenia na stronie internetowej Software Engineering Institute Carnegie Mellon University blisko 50 definicji – zaczerpnitych z literatury oraz zaproponowanych przez internautów – terminu „architektura systemu oprogramowania”. Standard IEEE 1471-2000 Recommended Practice for Architectural Description of SoftwareIntensive Systems definiuje architektur systemu oprogramowania jako: fundamentaln organizacj systemu zawierajc w sobie: elementy, relacje midzy tymi elementami oraz rodowisko i pryncypia projektowania i ewolucji tej organizacji. Przy czym: „fundamentalna organizacja” oznacza zasadnicze, ujednolicone koncepcje i zasady; okrelenie „system” obejmuje system oprogramowania, platform, lini produktow; rodowisko rozumiane jest jako projektowy, operacyjny lub programistyczny kontekst systemu. L. Bass, P. Clements i R. Kazman definiuj architektur systemu oprogramowania jako struktur (lub zbiór struktur) tego systemu, która składa si z okrelonych elementów, widzianych z zewntrz właciwoci tych elementów oraz zwizków midzy nimi [1]. W. Chmielarz definiuje architektur systemu jako układ współpracujcych ze sob nastpujcych elementów: struktury oprogramowania, fizycznej struktury danych, mechanizmów gwarantujcych bezpieczestwo danych . Dodatkowo W. Chmielarz zauwaa, e: „pełna specyfikacja problematyki architektury systemu [informatycznego – przypis autora] wymaga jeszcze ponadto uwzgldnienia w rozwaaniach zagadnie sprztowych oraz zwizanych z organizacj procesu przetwarzania” [3]. P. Kroll i P. Kruchten rozpatruj natomiast architektur jako zbiór znaczcych decyzji dotyczcych struktury systemu, czyli: wyboru elementów strukturalnych i ich interfejsów, z których składa si system, zachowa okrelajcych współprac tych elementów, zorganizowania tych elementów strukturalnych i behawioralnych w wiksze podsystemy, stylu architektonicznego, który ma wpływ na kształt tej struktury [10]. P. Kruchten pisze take, e „architektura opisana w całoci jest czym wielowymiarowym – architektura nie jest płaska” [11]. Na architektur systemu oprogramowania (zanim sam system powstanie) mona wreszcie patrze jak na przedfizyczn form jego istnienia. Architektura stanowi take odwzorowanie (reprezentacj) wiedzy jej projektanta..

(3) POLSKIE STOWARZYSZENIE ZARZĄDZANIA WIEDZĄ Seria: Studia i Materiały, nr 17, 2008. 141. 3. Projektowanie architektury w architekturocentrycznym procesie opracowywania systemów oprogramowania L. Bass, P. Clements i R. Kazman zauwaaj, e kady system oprogramowania ma okrelon architektur, poniewa „kady system moe by pokazany jako składajcy si z elementów i powiza midzy nimi” [1]. Niezbdne jest jednak zaprojektowanie tej architektury w taki sposób, aby system zrealizowany na jej podstawie spełniał okrelone kryteria jakociowe, ilociowe i funkcjonalne. Istotny wpływ na powodzenie w tym obszarze ma wybór procesu wytwórczego. Jak pisze bowiem A. Kobyliski: „istnieje oczywisty zwizek midzy procesami a produktami. (...) Bez procesu programowego – niezalenie od tego, jak on jest zorganizowany – chaotycznie i bezwładnie czy te dojrzale i w sposób uporzdkowany, nie byłoby produktu (....). Problem tkwi w tym, w jaki sposób zorganizowa proces programowy, aby uzyskany produkt spełniał wymagania jakociowe, a ponadto był skoczony w terminie i w ramach załoonego budetu” [9]. Dlatego te decyzja o wykorzystaniu okrelonego procesu jest jednym z istotniejszych elementów przedsiwzicia i zaley od wielu czynników. Do najwaniejszych zaliczy mona rodzaj powstajcego rozwizania, uywane w organizacji metody i narzdzia do opracowywania systemów oprogramowania, a take oczekiwania dotyczce produktów roboczych zwizanych z procesem wytwórczym. Bazujc na tezie L. Bassa, e „w procesie opracowywania systemów oprogramowania architektura jest artefaktem o najwikszym znaczeniu; stanowi ona podstaw do osigania celów biznesowych i podanych atrybutów jakociowych”, proponuje si zastosowanie procesu opracowywania systemów oprogramowania okrelonego mianem architekturocentrycznego [1]. A. Bucchiarone, H. Puccini i P. Pelliccione definiuj proces architekturocentryczny jako ten, w którym specyfikacja architektury systemu jest walidowana na bazie odpowiednich wymaga, a nastpnie zwalidowana architektura stanowi punkt wyjcia do jakichkolwiek innych analiz [2]. L. Bass, P. Clements i R. Kazman wskazuj, e w procesie architekturocentrycznym architektura stanowi jego centralny element [1]. Według C. Hofmeister, R. Nord i D. Soni proces architekturocentryczny polega na uyciu architektury oprogramowania do organizowania czynnoci składajcych si na opracowanie tego oprogramowania [7]. H. Proper okrela, e system jest tworzony w procesie architekturocentrycznym, jeeli jego architektura jest uywana do [15]: • komunikacji i negocjacji pomidzy interesariuszami, • ewaluacji i porównania decyzji architektonicznych, • planowania i zarzdzania rozwojem systemu, • przeprowadzenia weryfikacji powstałego rozwizania z decyzjami architektonicznymi. A. Lattanze zauwaa, e w architekturocentrycznym procesie opracowywania systemów oprogramowania architektura stanowi „zewntrze i centrum” podczas wszystkich faz tego procesu. Na jej podstawie definiowane s wszystkie kolejne działania, artefakty, role [12]. Ponadto A. Lattanze identyfikuje dobre praktyki (ang. best practices) dla procesu architekturocentrycznego [12]: • Na bazie potrzeb interesariuszy zdefiniuj architektur tak wczenie, jak jest to moliwe. • Utwórz, udoskonalaj i aktualizuj architektur w iteracyjny sposób podczas całego cyklu ycia systemu..

(4) 142. Andrzej Sobczak Architekturocentryczny proces opracowywania systemów oprogramowania. • Waliduj architektur, czy spełnia ona oczekiwania interesariuszy. • Zdefiniuj znaczce role dla członków zespołu zajmujcych si architektur. • Twórz estymacje i harmonogramy, korzystajc z architektury. • Wykorzystuj architektur do zwikszenia wydajnoci prac nad systemem. • Zapewnij, aby przyjty proces opracowywania systemów był lekki, skalowalny, moliwy do dopasowania i powtarzalny. okreĞlają. Potrzeby biznesowe. Elementy sterujące architekturą. oddziaływają na. wpływają na. Interesariusze. Architektura. jest podstawą. Plan projektu. Plan testów. Projekt szczegółowy. System. Alokacja zasobów. Rys. 1. Umiejscowienie architektury w architekturocentrycznym procesie opracowywania systemów oprogramowania ródło: A. Lattanze, The Architecture Centric Development Method, Report no. CMU-ISRI-05103, School of Computer Science, Carnegie Mellon University, February 2005, s. 56. Kluczowym elementem architekturocentrycznego procesu opracowywania systemów jest zaprojektowanie architektury. C. Hofmeister. P. Kruchten, R. Nord, H. Obbink, A. Ran i P. America opracowali generyczny model projektowania architektury systemów (por.: rys. 2). W modelu tym podczas analizy architektonicznej nastpuje zdefiniowanie problemów, które musz zosta uwzgldnione w czasie prac nad architektur, oraz okrelenie wymaga architektonicznych (czyli nie wszystkich, lecz takich, które maj wpływ na architektur). Odbywa si to na bazie okrelonych wczeniej zagadnie (ang. concerns) i kontekstu. Przez zagadnienia rozumie si te okolicznoci i aspekty, które s kluczowe dla jednego lub wicej interesariuszy podczas opracowywania architektury. Najczciej zagadnienia te maj posta wymaga (np. wymaga niefunkcjonalnych dotyczcych wydajnoci, bezpieczestwa itp.), ale mona tutaj uwzgldni. obligatoryjne decyzje architektoniczne, przepisy prawne. Kontekst ujmuje rodowisko (organizacyjne, polityczne, stan i dostpno technologii), w jakim realizowany jest system. Kryteria rozrónienia midzy zagadnieniami a kontekstem maj czsto rozmyt posta . Zagadnienie dotyczy konkretnego systemu, natomiast kontekst zwizany jest z ogóln charakterystyk organizacji lub interesariuszy. Synteza architektury jest kluczowym działaniem w ramach projektowania architektury. Nastpuje tutaj – na bazie wymaga architektonicznych – wygenerowanie kandydackich rozwiza architektonicznych. Kandydackie rozwizania.

(5) POLSKIE STOWARZYSZENIE ZARZĄDZANIA WIEDZĄ Seria: Studia i Materiały, nr 17, 2008. 143. architektoniczne obejmuj alternatywne rozwizania lub czciowe rozwizania okrelonych problemów (w formie fragmentów architektury). Decyduj one o przyszłej strukturze systemu. Rozwizania architektoniczne zawieraj dodatkowo informacje o podjtych decyzjach, uzasadnienia tych decyzji, i powizaniach decyzji z wymaganiami. W ramach ewaluacji architektury nastpuje sprawdzenie, które rozwizania architektoniczne s spójne z wymaganiami architektonicznymi oraz czy s one wzajemnie spójne. Jedynie taki zbiór rozwiza moe by. prezentowany jako zwalidowana architektura. Niezbdne jest jej uzupełnienie o informacje dotyczce uzasadnienia podjcia okrelonych decyzji w zakresie oceny walidowanych rozwiza [8].. Rys. 2. Generyczny model projektowania architektury systemów ródło: C. Hofmeister, P. Kruchten, R. Nord, H. Obbink, A. Ran, P. America, A general model of software architecture design derived from five industrial approaches, „The Journal of Systems and Software”, vol. 80, issue 1, January 2007, s. 113. Przykładem realizacji generycznego modelu projektowania architektury systemów jest podejcie opracowane w Software Engineering Institute, Carnegie Mellon University (por.: rys. 3).. Rys. 3. PodejĞcie opracowane w Software Engineering Institute w zakresie projektowania architektury systemów ródło: Opracowanie własne na podstawie: C. Hofmeister, P. Kruchten, R. Nord, H. Obbink, A. Ran, P. America, A general model of software architecture design derived from five industrial approaches, „The Journal of Systems and Software”, vol. 80, issue 1, January 2007, s. 107–18..

(6) 144. Andrzej Sobczak Architekturocentryczny proces opracowywania systemów oprogramowania. Pierwszym krokiem w ramach tego podejcia jest zrealizowanie pierwszej czci warsztatów atrybutów jakociowych (ang. Quality Attribute Workshop – QAW). Pozwala to na zrozumienie problemów poprzez wydobycie atrybutów jakociowych wymaga za pomoc tzw. scenariuszy atrybutów. Scenariusze te identyfikowane s za pomoc „burzy mózgów”, w której uczestnicz główni interesariusze. W wyniku tej operacji powstaje około 30–40 scenariuszy, które podlegaj nastpnie priorytetyzacji. Scenariusze o najwyszym priorytecie s ucilane w celu pełniejszego uchwycenia kontekstu oraz dookrelenia zwizanych z nimi szczegółów. Kolejnym etapem jest zastosowanie metody projektowania architektury sterowanej atrybutami (ang. Attribute-Driven Design – ADD). Projektowanie realizowane za pomoc tej metody bazuje na informacjach wejciowych przygotowanych w formie scenariuszy atrybutów oraz na znajomoci relacji midzy realizacj tych atrybutów a architektur. Główne kroki metod ADD obejmuj nastpujce czynnoci: 1. Wybór modułu, który bdzie podlegał dekompozycji. Przy pierwszej iteracji modułem jest cały tworzony system. 2. Udoskonalanie modułu zgodnie z poniszymi krokami: a. Wybór kluczowych, dla danej dekompozycji, zagadnie ze zbioru scenariuszy jakociowych i wymaga funkcjonalnych. b. Wybór odpowiednich w danej sytuacji taktyk i wzorców architektonicznych. Rozpoznanie modułów potomnych, wymaganych do realizacji tych taktyk. c. Ucilenie modułów potomnych za pomoc przypadków uycia i przedstawienie ich za pomoc wybranych perspektyw architektonicznych. d. Okrelenie interfejsów modułów potomnych i charakterystyki interakcji midzy nimi. e. Zweryfikowanie i udoskonalenie przypadków uycia oraz scenariuszy jakociowych. Sformułowanie ogranicze na moduły potomne. Podjcie decyzji o dalszej dekompozycji modułów lub ich skierowaniu do implementacji. 3. Powtarzanie etapu 2 dla wszystkich modułów wymagajcych dalszej dekompozycji. Powstała architektura jest dokumentowana na bazie metody „widoki i dalej” (ang. Views and Beyond – VaB). Metoda ta zakłada, e dokumentowanie architektury polega na dokumentowaniu istotnych widoków, a nastpnie uzupełnianiu ich o opisy, które maj zastosowanie do wicej ni jednego widoku. P. Clements zaproponował podział widoków na nastpujce grupy [4]: widoki modułów (pokazujce, jak system jest ustrukturalizowany jako zbiór modułów kodu), widoki komponentów i konektorów (przedstawiajce, jak system jest ustrukturalizowany jako zbiór komponentów wykonywalnych), widoki alokacji (ilustrujce, jak cz programowa systemu jest powizana z czci nieprogramow). W podejciu tym kady widok jest prezentowany w wystandaryzowany sposób (podstawowa prezentacja, katalogi elementów i ich relacji, interfejsów oraz zachowa, diagram kontekstowy, podstawowe informacje o architekturze kluczowe dla danego widoku). Realizacja słowa „dalej” w nazwie metody polega na uzupełnieniu dokumentacji architektury m. in. o ogólny opis systemu, przedstawienie szablonu do prezentowania widoków wraz z uzasadnieniem ich zastosowania, mapowanie widoków, słownik, objanienie decyzji architektonicznych dotyczcych wicej ni jednego widoku. Wreszcie powstała architektura ewaluowana jest za pomoc metody analizy kompromisów architektonicznych (ang. Architecture Tradeoff Analysis Method – ATAM)..

(7) POLSKIE STOWARZYSZENIE ZARZĄDZANIA WIEDZĄ Seria: Studia i Materiały, nr 17, 2008. 145. 4. Podsumowanie Przedstawione w niniejszym artykule rozwaania wskazuj, e wraz ze wzrostem stopnia skomplikowania struktury systemów oprogramowania w istotny sposób wzrosła rola architektury tych systemów. Jest to zwizane z odejciem od monolitycznych lub pracujcych w trybie klient– serwer rozwiza na rzecz systemów pracujcych w architekturze wielowarstwowej lub architekturze zorientowanej na usługi, a take upowszechnienia si rozwiza typu COTS. Tym samym mona sformułowa wniosek, e jednym z najwaniejszych elementów procesu opracowywania systemów oprogramowania, który w istotnym stopniu wpływa na przydatno dla organizacji budowanych systemów, jest właciwe zaprojektowanie ich architektury. Jak pisz M. Shaw i P. Clements, dla architekturocentrycznego podejcia „nadszedł złoty wiek” [16]. Z jednej strony jest ono wystarczajco dojrzałe (zgodnie z szeciostopniowym modelem Redwine’a i Riddle’a, dotyczcym opracowywania i propagacji koncepcji w inynierii oprogramowania, architektura oprogramowania znajduje si obecnie na szóstym, najbardziej dojrzałym poziomie), a z drugiej strony upowszechnienie si rozwiza e-commerce wpłynło na konieczno tworzenia rozwiza n-warstwowych, budowania systemów w architekturze zorientowanej na usługi, wykorzystywania komponentów COTS, opracowywania jzyków i narzdzi pozwalajcych implementowa techniki i style architektoniczne. Jednoczenie w rodowisku osób zajmujcych si tworzeniem systemów informatycznych wzrosła wiadomo roli zagadnie architektonicznych – bezporednim tego wyrazem moe by powołanie Worldwide Institute of Software Architects i International Association of Software Architect. Mona wic sformułowa drugi wniosek, e obecnie architekturocentryczny proces opracowywania systemów oprogramowania stał si jednym z dominujcych paradygmatów w inynierii oprogramowania.. Bibliografia 1. 2.. 3. 4. 5. 6. 7. 8.. Bass L., Clements P., Kazman R.: Architektura oprogramowania w praktyce, Wydawnictwa Naukowo-Techniczne, Warszawa 2006. Bucchiarone A., Muccini H., Pelliccione P.: A Practical Architecture-Centric Analysis Process. W: Proceedings of the QoSA 2006, Lecture Notes In Computer Science, vol. 4214, Springer-Verlag, 2006. Chmielarz W.: Systemy informatyczne wspomagajce zarzdzanie, Aspekt modelowy w budowie systemów, Dom Wydawniczy Elipsa, Warszawa 1996. Clements P., Kazman R., Klein M.: Architektura oprogramowania. Metody oceny oraz analiza przypadków, Helion, Gliwice 2003. Flasiski M.: Wstp do analitycznych metod projektowania systemów oprogramowania, Wydawnictwa Naukowo-Techniczne, Warszawa 1997. Graham I., O’Callaghan A., Wills A.: Metody obiektowe w teorii i praktyce, Wydawnictwa Naukowo-Techniczne, Warszawa 2004. Hofmeister C., Nord R., Soni D.: Tworzenie architektury oprogramowania, Wydawnictwa Naukowo-Techniczne, Warszawa 2007. Hofmeister C., Kruchten P., Nord R., Obbink H., Ran A., America P.: A general model of software architecture design derived from five industrial approaches. W: The Journal of Systems and Software, vol. 80, issue 1, January 2007, s. 106–126..

(8) 146. Andrzej Sobczak Architekturocentryczny proces opracowywania systemów oprogramowania. 9. 10. 11. 12. 13. 14. 15.. 16. 17.. Kobyliski A.: Modele jakoci produktów i procesów programowych, Szkoła Główna Handlowa w Warszawie, Warszawa 2005. Kroll P., Kruchten P.: Rational Unified Process od strony praktycznej, Wydawnictwa Naukowo-Techniczne, Warszawa 2007. Kruchten P.: Rational Unified Process od strony teoretycznej, Wydawnictwa NaukowoTechniczne, Warszawa 2007. Lattanze A.: The Architecture Centric Development Method, Report no. CMU-ISRI-05103, School of Computer Science, Carnegie Mellon University, February 2005. Paulish D.: Zarzdzanie architekturocentrycznym procesem tworzenia oprogramowania, Wydawnictwa Naukowo-Techniczne, Warszawa 2007, s. XI. Pressman S.: Praktyczne podejcie do inynierii oprogramowania, Wydawnictwa Naukowo-Techniczne, Warszawa 2004. Proper E.: Architecture-driven Information System Development – Toward a framework for understanding. W: Proceedings of the 7th World Multi Conference On Systemics, Cybernetics and Informatics, 27–30 July 2003, Orlando, Florida, USA 2003. Shaw M., Clements P.: The Golden Age of Software Architecture, Software, IEEE, March–April 2006, vol. 23, issue 2, s. 34–35. Targowski A.: Strategia i architektura systemów informatycznych przedsibiorstwa w gospodarce rynkowej, Nowe Wydawnictwo Polskie, Warszawa 1992. ARCHITECTUROCENTRIC PROCESS OF SOFTWARE DEVELOPMENT. Summary Software architecture has been widely used to describe the design of a software system. This paper has been focus on the process of software system development. The approach is discussed in relation to other existing methods of systems’ developments. Keywords: software system architecture, process of software system development, architecturecentric process. Andrzej Sobczak Katedra Informatyki Gospodarczej Szkoła Główna Handlowa w Warszawie 02-554 Warszawa, al. Niepodległoci 162 e-mail: sobczak@sgh.waw.pl http://kig.sgh.waw.pl.

(9)