Przejdź do zawartości

Architektura oprogramowania

Z Wikipedii, wolnej encyklopedii

Architektura oprogramowania – podstawowa organizacja systemu wraz z jego komponentami, wzajemnymi powiązaniami, środowiskiem pracy i regułami ustanawiającymi sposób jej budowy i rozwoju[1].

Opis architektury oprogramowania (ang. Software Architecture Description) postrzegany jest jako platforma porozumiewania się wszystkich osób zaangażowanych w proces wytwórczy systemów informatycznych.

Architektura oprogramowania jest stosunkowo młodą dziedziną informatyki i choć w ostatnich dwóch dekadach dość mocno się rozwinęła i nawet osiągnęła poziom dojrzałości, to nadal trwają dyskusje nad jej miejscem w informatyce, a przede wszystkim nie ma zgody szerokiego gremium w zakresie określenia samej definicji architektury oprogramowania. Stąd SEI na swojej stronie[2] publikuje definicje architektury oprogramowania różnych autorów.

Na obecnym etapie rozwoju architektury oprogramowania systemów informatycznych duże nadzieje wiąże się z rozwojem odpowiednich języków opisu architektury, które pozwolą w łatwy sposób przekształcać opisy architektoniczne w modele analityczne, a nawet wygenerować kody źródłowe, co jest przedmiotem Model Driven Development. Architektura sterowana modelem (MDA), wykorzystywana przez MDD, obecnie nadal jest mocno związana z językiem modelowania UML, toteż rozwój tej dziedziny wiąże się z opracowaniem odpowiedniego języka opisu architektury, który w tym względzie zastąpiłby UML[3]. Podobnie uważa Mary Shaw[4], twierdząc, że osoba proponująca nowy język opisu architektury, musi odpowiedzieć na pytanie „Czy ta propozycja ma jakieś szanse zastąpienia UML? Jakie narzędzia pozwolą to osiągnąć?”. Ponadto Mary Shaw w swoim artykule nakreśliła również pewne obiecujące obszary, które w najbliższym czasie mogą zmienić oblicze architektury oprogramowania m.in.:

  • rozwinięcie formalnych związków pomiędzy decyzjami architektonicznymi a atrybutami jakościowymi;
  • poszukiwanie odpowiedniego języka do opisu architektury;
  • poszukiwanie rozwiązań zapewniających zgodność architektury z kodem.

Historia

[edytuj | edytuj kod]

W latach 1968–1969 odbyły się dwie znaczące konferencje sponsorowane przez NATO[5][6], gdzie dyskutowano o roli i znaczeniu informatyki (ang. computer science) oraz inżynierii oprogramowania (ang. software engineering). W szczególności dyskusje uczestników dotyczyły braku związków pomiędzy informatyką (jako nauką zorientowaną na teorie), a inżynierią oprogramowania (jako nauką zorientowaną na praktykę). Jedną z ciekawych propozycji wypełnienia tej luki i wyjścia z ówczesnego „kryzysu w wytwarzaniu oprogramowania” (ang. software crisis) była koncepcja Iana Sharpa dotycząca modelowania systemów oprogramowania w postaci tzw. architektury oprogramowania. Od tego czasu architektura oprogramowania zaczęła mieć coraz większe znaczenie w projektach systemów informatycznych przyjmując wpierw kierunek rozwoju zakreślony znanym równaniem Perry’ego i Wolfa (Software Architecture = {Elements, Form, Rationale}), po czym przyoblekając się w style wyspecyfikowane przez D. Garlana i M. Shaw, a następnie osiągając stabilność w postulowanym przez Philippe Kruchtena modelu perspektyw architektonicznych 4+1. Obecnie zaś architektura oprogramowania przybrała formę modelu koncepcyjnego opisu architektury jako standard SEI i zdaje się dążyć w kierunku rozwiązań Model Driven Architecture (MDA).

Dyscyplina

[edytuj | edytuj kod]

Peter J. Denning w swoim artykule o Informatyce[7] zaproponował podział tej dziedziny nauki stawiając architekturę oprogramowania na podobnym poziomie co takie obszary jak:

Jednocześnie dla każdego z tych obszarów zaproponował podział na trzy zakresy (procesy) dotyczące strony teoretycznej, abstrakcyjnej (eksperymentalnej) oraz strony praktycznej. Z kolei Ian Sommerville widzi informatykę i inżynierię oprogramowania jako dwie oddzielne dyscypliny (informatyka zorientowana na teorie, inżynieria oprogramowania zorientowana na praktykę), natomiast architekturę oprogramowania określa jako wynik procesu zdefiniowanego wewnątrz inżynierii oprogramowania[8]. Podobnie uważają Bass, Clements i Kazman[9] twierdząc wręcz, że architektura wyłoniła się jako zasadnicza część procesu projektowania systemów informatycznych. Ponadto istnieją źródła, które umiejscawiają architekturę oprogramowania jako dział inżynierii oprogramowania.

Definicje

[edytuj | edytuj kod]

Jedną z pierwszych definicji podali Brookes i Iverson[10] w 1969 roku: „architektura to pojęciowa struktura komputera w postaci widzianej przez programistę”. Jednakże kilka lat później Fred Brookes zrewidował tę definicję twierdząc, że architektura to „pełne i szczegółowe przedstawienie interfejsu użytkownika. (…) Podczas gdy architektura mówi nam, co się dzieje, implementacja mówi, jak to się ma dziać”[11]. Należy przy tym zauważyć, że Brooks odróżnia architekturę oprogramowania od implementacji systemu informatycznego, co często ma miejsce i w obecnych czasach.

Definicję architektury jako pewnej abstrakcji systemu informatycznego podał Schwanke w 1989 roku twierdząc, że „struktura oprogramowania to lista komponentów i połączenia pomiędzy nimi”[12]. Definicja ta została wzbogacona przez Perry’ego i Wolfa o ograniczenia i interakcje pomiędzy komponentami w roku 1992: „Architektura opisuje wybrane elementy architektoniczne, połączenia między nimi oraz ograniczenia tych elementów architektonicznych i ich wzajemnych związków niezbędnych do zdefiniowania modelu spełniającego wymagania i będącego podstawą dla projektu systemu informatycznego”, aczkolwiek o wiele bardziej popularna jest formuła Perry’ego: Software Architecture = {Elements, Form, Rationale}.

Z kolei Garlan i Shaw skłaniają się do bardziej uproszczonej definicji w swoim artykule ogłoszonym rok później[13]: “Architektura oprogramowania danego systemu można traktować jako kolekcję komponentów obliczeniowych – lub prościej komponentów – wraz z opisem interakcji pomiędzy tymi komponentami”. Przełomową definicję architektury oprogramowania podał Philippe Kruchten w 1995 roku, która to definicja uwzględniała abstrakcję architektury oraz potrzebę spełnianie pewnych wymagań w stosunku do projektowanego systemu informatycznego[14]: “Architektura oprogramowania dotyczy projektu i implementacji w aspekcie przedstawiania struktury oprogramowania na ich wysokim poziomie abstrakcji. Jest rezultatem łączenia pewnej liczby elementów architektonicznych w pewną odpowiednio dobraną formę tak, by spełnić główne funkcjonalności oraz wymagania wydajności takie jak skalowalność i dostępność. Architektura związana jest z abstrakcją, dekompozycją i ponowną kompozycją, stylem i estetyką systemu informatycznego.”. A więc architektura oprogramowania to nie tylko opis połączonych ze sobą komponentów, ale też i całe spectrum zagadnień związanych z budową oprogramowania. Definicję tę Kruchten podparł modelem perspektyw architektonicznych 4+1, a następnie rozwinął dla potrzeb metodyki RUP w 1999 roku[15]: „Architektura to zbiór istotnych decyzji dotyczących:

  • organizacji systemu oprogramowania;
  • wyboru elementów strukturalnych i ich interfejsów, z których system jest zbudowany, razem z ich zachowaniami wyspecyfikowanymi w ich kooperacjach;
  • składania tych elementów w coraz większe podsystemy;
  • stylu architektonicznego, według którego tworzy się konstrukcję systemu, to znaczy charakterystyczne elementy i ich interfejsy, od którego zależy kooperacja i składanie.

Natomiast Bass, Clements i Kazman podali bardziej zwartą definicję architektury oprogramowania w 2003 roku: “Architektura oprogramowania programu lub systemu informatycznego jest strukturą lub zbiorem struktur tego systemu, obejmującym elementy oprogramowania, widoczne dla pozostałych elementów oprogramowania oraz zależności między nimi.”. Przy czym w tej definicji termin struktura jest zbieżny z perspektywą. Między innymi na wspomnianej wyżej definicji oparli się autorzy standardu ISO/IEC 42010:2007 wprowadzając następującą definicję: „Architektura systemu informatycznego jest to podstawowa organizacja systemu wraz z jego komponentami, wzajemnymi powiązaniami, środowiskiem pracy i regułami ustanawiającymi sposób jej budowy i rozwoju.”. Więcej definicji architektury oprogramowania można przestudiować na stronie Instytutu Inżynierii Oprogramowania SEI, zwłaszcza, że od dłuższego czasu SEI postanowiło rejestrować różnorodne definicje architektury oprogramowania.

Koncepcje opisu architektury oprogramowania

[edytuj | edytuj kod]

W celu poprawnego zbudowania systemu informatycznego należy wpierw stworzyć jego plan, czy inaczej abstrakcyjny model[16]. Taki model umożliwia wspólne prace nad docelowym systemem wszystkim zainteresowanym osobom biorącym udział w projekcie poprzez utworzenie odpowiedniego wyobrażenia docelowego systemu, bądź jego części. Wynika stąd, że model projektowanego systemu informatycznego jest podstawowym elementem architektury oprogramowania. Koncepcje opisu architektury oprogramowania:

Istnieją też i inne koncepcje opisu architektury jak RM-ODP, TOGAF, DODAF, ARIS.

Metodyki budowy systemów informatycznych

[edytuj | edytuj kod]

Zbieranie wymagań na system informatyczny może odbywać się na wiele sposobów i dotyczyć np. tylko wybranych aspektów opisu docelowego systemu. Częstym sposobem opisu takich wymagań jest opis tekstowy docelowego systemu. Jednakże w większości projektów zaleca się stosowanie do opisu projektowanego systemu takiego opisu architektury, który umożliwiałby pokazanie uzasadnionego ciągu powiązanych modeli od momentu zbierania wymagań, aż po zakres wdrożenia systemu.
Metodyki budowy systemów informatycznych:

Wiele metod i technik projektowania, analizy, czy szacowania architektury oprogramowania opracowano przez Software Engineering Institute i przedstawiono na stronie internetowej organizacji[26].

Języki opisu architektury oprogramowania

[edytuj | edytuj kod]

Język opisu architektury oprogramowania (ang. Architecture Description Language – ADL) z jednej strony musi posiadać prostą, zrozumiałą i możliwie graficzną notację, bez zbyt rozbudowanej semantyki, co pozwoliłoby wizualizować, a jednocześnie zwiększałoby zrozumiałość architektury, a także możliwe byłoby przeprowadzanie prostych analiz architektury oprogramowania. Z drugiej zaś strony ADL powinien posiadać odpowiednie reguły syntaktyczne i semantyczne, co umożliwiłoby przeprowadzanie przeróżnych skomplikowanych analiz, weryfikacji modeli, parsowania, kompilowania i generowania kodu wspomagając budowę systemów informatycznych[27].

Języki opisu architektury:

  • Unified Modeling Language – UML
  • Architecture Analysis & Design Language – AADL[28]
  • Architecture Description Interchange Language – ACME[29]

Istnieją również inne języki opisu architektury oprogramowania jak xADL, Koala, Wright, Darwin.

Zobacz też

[edytuj | edytuj kod]

Przypisy

[edytuj | edytuj kod]
  1. The Institute of Electrical and Electronics Engineers Standards Board: Recommended Practice for Architectural Description of Software-Intensive Systems, ISO/IEC 42010:2007(E) IEEE Std 1471-2000, 2007
  2. Software Architecture | Getting Started | Glossary | What is your definition of software architecture? [online], www.sei.cmu.edu [dostęp 2017-11-22] (ang.).
  3. Philippe Kruchten, Henk Obbink, Judith Stafford: The Past, Prezent, and Future of Software Architecture. IEEE Software, March/April 2006.
  4. Mary Shaw, Paul Clements: The Golden Age of Software Architecture. Software, IEEE, Vol. 23, No. 2. (2006), pp. 31-39.
  5. P. Naur, B. Randell, (Eds.): Software Engineering: Report of a conference sponsored by the NATO Science Committee. Garmisch, Germany, 7-11 Oct. 1968, Brussels, Scientific Affairs Division, NATO (1969) 231pp.
  6. B. Randell, J.N. Buxton, (Eds.): Software Engineering Techniques: Report of a conference sponsored by the NATO Science Committee. Rome, Italy, 27-31 Oct. 1969, Brussels, Scientific Affairs Division, NATO (1970) 164pp.
  7. Denning P.J.: Computer Science: The Discipline. Encyclopedia of Computer Science, 2000 Edition, A. Ralston and D. Hemmendinger. Eds.
  8. Ian Sommerville 2004, Software Engineering, 7th edition.
  9. Len Bass, Paul Clements, Rick Kazman, Software Architecture in Practice, Addison-Wesley 2003.
  10. Brooks F., Iverson K.: Automatic Data Processing. (System 360 Edition), John Wiley, 1969.
  11. Brooks F.: The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975.
  12. R.W. Schwanke, R.Z. Altucher, M.A. Plato: Discovering, Visualizing and Controlling Software Structure. Proc. Fifth Inter. Workshop on Software Specication and Design, Pittsburgh, PA, May 1989, appearing in ACM SIGSOFT Notes, Vol. 14, No. 3, May 1989, pp. 147-150.
  13. D. Garlan, M. Shaw: An Introduction to Software Architecture, Advances in Software Engineering and Knowledge Engineering. vol. 1, World Scientific, 1993, pp. 1-39.
  14. Philippe Kruchten: Architectural Blueprints — The “4+1” View Model of Software Architecture. Philippe Kruchten Rational Software Corp., Paper published in IEEE Software 12 (6) November 1995, pp. 42-50.
  15. Kruchten Philippe: Rational Unified Process od strony teoretycznej. Wydawnictwa Naukowo-Techniczne, 2007.
  16. Hofmeister, Nord, Soni: Applied Software Architecture. Addison-Wesley, 2000.
  17. Dewayne E. Perry, Alexander L. Wolf: Foundations for the Study of Software Architecture. ACM Software Engineering Notes, vol. 17, no. 4, 1992, pp 40-52
  18. Buschmann F., Meunier R., Rohnert H. & Sommerlad P. & Stal M., Pattern-Oriented Software Architecture: A System of Patterns. John Wiley & Sons, 1996.
  19. Soni D., Nord R., Hofmeister C.: Software Architecture in Industrial Applications. Proceedings of the Seventeenth International Conference on Software Engineering. ACM Press, 1995.
  20. D. Parnas, D. Weiss: Active Design Reviews: Principles and Practice. J. Systems and Software, vol. 7, pp. 259–265, 1987.
  21. Rick Kazman, Len Bass, Gregory Abowd, Mike Webb: SAAM: A Method for Analyzing the Properties of Software Architectures, Proceedings of the International Conference on Software Engineering – ICSE'16. 1994, ss. 81-90
  22. Baragry, J.; Reed, K.: Why Is It So Hard To Define Software Architecture. Software Engineering Conference, 1998. Proceedings. 1998 Asia Pacific, 2-4 Dec 1998, ss. 28–36.
  23. Paul C. Clements: Active Reviews for Intermediate Designs, Technical Note, CMU/SEI-2000-TN-009. Carnegie Mellon: Software Engineering Institute, August 2000.
  24. Jayatirtha Asundi, Rick Kazman, Mark Klein: Using Economic Considerations to Choose Among Architecture Design Alternatives. TECHNICAL REPORT CMU/SEI-2001-TR-035, ESC-TR-2001-035, Carnegie Mellon: Software Engineering Institute, 2001.
  25. John Bergey, Mario Barbacci, William Wood: Using Quality Attribute Workshops to Evaluate Architectural Design Approaches in a Major System Acquisition: A Case Study, Technical Note CMU/SEI-2000-TN-010. Carnegie Mellon: Software Engineering Institute, July 2000.
  26. Software Architecture | Tools & Methods [online], www.sei.cmu.edu [dostęp 2017-11-22] (ang.).
  27. N. Medvidovic, R. N. Taylor: A Classification and Comparison Framework for Software Architecture Description Languages, Software Engineering. IEEE Transactions on Volume 26, Issue 1, Jan 2000, ss. 70–93.
  28. Peter H. Feiler, David P. Gluch, John J. Hudak, The Architecture Analysis & Design Language (AADL):An Introduction, Technical Note CMU/SEI-2006-TN-011, Carnegie Mellon: Software Engineering Institute, February 2006.
  29. D. Garlan, R. Monroe, D. Wile: ACME: An Architecture Description Interchange Language. In Proceedings of GASCON’97, November 1997.