IEEE 1471

IEEE 1471 to zastąpiony standard IEEE opisujący architekturę „systemu intensywnie korzystającego z oprogramowania”, znanego również jako architektura oprogramowania .

W 2011 roku został zastąpiony przez ISO/IEC/IEEE 42010 , Inżynieria systemów i oprogramowania — Opis architektury .

Przegląd

IEEE 1471 to skrócona nazwa standardu formalnie znanego jako ANSI/IEEE 1471-2000, Zalecana praktyka dotycząca opisu architektury systemów intensywnie korzystających z oprogramowania. W żargonie Instytutu Inżynierów Elektryków i Elektroników (IEEE) jest to „zalecana praktyka”, najmniej normatywna z jej standardów. W 2007 roku norma ta została przyjęta przez ISO/IEC JTC1/SC7 jako ISO/IEC 42010:2007 , Inżynieria systemów i oprogramowania — Zalecana praktyka dotycząca opisu architektury systemów intensywnie korzystających z oprogramowania .

Od dawna jest uznawany [ przez kogo? ] , że „architektura” ma silny wpływ na cykl życia systemu. Jednak do stosunkowo niedawna [ kiedy? ] Kwestie sprzętowe zwykle dominowały w myśleniu architektonicznym, a aspekty oprogramowania, jeśli w ogóle były brane pod uwagę, były często pierwszymi, które były zagrożone pod presją rozwoju. IEEE 1471 został stworzony, aby zapewnić podstawę do myślenia o architekturze systemów intensywnie korzystających z oprogramowania.

Wkład IEEE 1471 można podsumować w następujący sposób (na tej liście pozycje zapisane kursywą to terminy zdefiniowane i używane w standardzie):

  • Zawiera definicje i metamodel opisu architektury
  • Stwierdza, że ​​architektura powinna uwzględniać obawy interesariuszy systemu
  • Twierdzi, że opisy architektury są z natury wielowidoczne , żaden pojedynczy widok nie oddaje odpowiednio wszystkich obaw interesariuszy
  • Określa pojęcia widoku i punktu widzenia , gdzie punkt widzenia identyfikuje zestaw problemów i reprezentacje / techniki modelowania itp. używane do opisu architektury w celu rozwiązania tych problemów , a widok jest wynikiem zastosowania punktu widzenia do określonego systemu.
  • Ustanawia wymagania dotyczące treści dla opisów architektury oraz ideę, że zgodny opis architektury ma zgodność 1 do 1 między jego punktami widzenia a jego poglądami .
  • Zawiera wskazówki dotyczące przechwytywania uzasadnienia architektury i identyfikowania niespójności/nierozwiązanych problemów między widokami w opisie architektury

IEEE 1471 zawiera załączniki informacyjne, które odnoszą się do koncepcji architektury w innych standardach, w tym RM-ODP i IEEE 12207 .

Historia

W sierpniu 1995 r. Komitet Standardów Inżynierii Oprogramowania IEEE (SESC) powołał Grupę Planowania Architektury IEEE (APG), aby wyznaczyć kierunek włączenia myślenia architektonicznego do standardów IEEE. W kwietniu 1996 r. utworzono Grupę Roboczą ds. Architektury (AWG) w celu wdrożenia zaleceń APG skierowanych do SESC. AWG przewodniczył Basil Sherlund, wiceprzewodniczący Ronald Wade, David Emery, specyfikację redagował Rich Hilliard. AWG liczyła 25 członków. Projekty specyfikacji zostały poddane pod głosowanie i skomentowane przez 130 międzynarodowych recenzentów. We wrześniu 2000 r. IEEE-SA Standards Board zatwierdziła specyfikację jako IEEE Std 1471-2000.

W 2006 roku Wspólny Komitet Techniczny ISO/IEC 1 (JTC1), Technologia informacyjna/Podkomitet SC 7, Inżynieria oprogramowania i systemów, przyjął specyfikację jako ISO/IEC 42010, w ramach specjalnej „szybkiej procedury”, równolegle z jej zatwierdzeniem przez krajowe organy ISO i IEC. Skoordynowana rewizja tego standardu przez ISO/IEC JTC1/SC7/WG42 i IEEE CS rozpoczęła się w 2006 r., po udanym głosowaniu przyspieszonym ISO/IEC i zgodnie z 5-letnim przeglądem standardu IEEE.

W listopadzie 2011 r. normy IEEE 1471-2000 i ISO/IEC 42010:2007 zostały zastąpione normami ISO/IEC/IEEE 42010:2011 , Inżynieria systemów i oprogramowania — Opis architektury .

Zamiar

Zgodnie ze standardem IEEE 1471 opis architektury może być wykorzystany do:

  • Ekspresja systemu i jego ewolucja
  • Komunikacja między interesariuszami systemu
  • Ocena i porównanie architektur w spójny sposób
  • Planowanie, zarządzanie i wykonywanie działań związanych z rozwojem systemu
  • Wyrażenie trwałych cech i zasad wspierających system, aby kierować akceptowalnymi zmianami
  • Weryfikacja zgodności wdrożenia systemu z opisem architektury
  • Nagrywanie wkładu w wiedzę na temat architektury systemów intensywnie korzystających z oprogramowania

Terminologia

Zgodnie z IEEE Standard Glossary of Software Engineering Terminology stosowane są następujące definicje:

  • architekt : Osoba, zespół lub organizacja odpowiedzialna za projektowanie architektury systemów.
  • opis architektoniczny (AD): zbiór produktów dokumentujących architekturę.
  • architektura : podstawowa organizacja systemu zawarta w jego komponentach, ich wzajemnych relacjach i środowisku oraz zasady kierujące jego projektowaniem i ewolucją.
  • projektowanie : czynności definiowania, dokumentowania, utrzymywania, ulepszania i certyfikowania właściwej implementacji architektury.
  • system : Zbiór komponentów zorganizowanych w celu realizacji określonej funkcji lub zestawu funkcji. Termin system obejmuje indywidualne aplikacje, systemy w tradycyjnym sensie, podsystemy, systemy systemów, linie produktów, rodziny produktów, całe przedsiębiorstwa i inne skupiska interesów.
  • interesariusz systemu : osoba, zespół lub organizacja (lub ich klasy) zainteresowane systemem lub związane z nim problemy.
  • widok : Reprezentacja całego systemu z perspektywy powiązanego zestawu zagadnień.
  • punkt widzenia : specyfikacja konwencji dotyczących konstruowania i używania widoku. Wzorzec lub szablon, na podstawie którego można opracować indywidualne poglądy, ustalając cele i odbiorców widoku oraz techniki jego tworzenia i analizy.

Ramy koncepcyjne

IEEE 1471 wykorzystuje następujące ramy koncepcyjne.

  1. kontekst systemu może wpływać na ten system. Środowisko może obejmować inne systemy, które wchodzą w interakcję z systemem będącym przedmiotem zainteresowania, bezpośrednio za pośrednictwem interfejsów lub pośrednio w inny sposób. Środowisko określa granice, które określają zakres systemu będącego przedmiotem zainteresowania w stosunku do innych systemów.
  2. System ma jednego lub więcej interesariuszy . Każdy interesariusz zazwyczaj ma interesy lub obawy związane z tym systemem.
  3. Obawy to te interesy, które dotyczą rozwoju systemu, jego działania lub wszelkich innych aspektów, które są krytyczne lub w inny sposób ważne dla jednego lub większej liczby interesariuszy. Obawy obejmują względy systemowe, takie jak wydajność, niezawodność, bezpieczeństwo, dystrybucja i ewoluowalność.
  4. System istnieje po to, aby wypełnić jedną lub więcej misji w swoim środowisku. Misja to użycie lub działanie, dla którego system jest przeznaczony przez jednego lub więcej interesariuszy, aby osiągnąć określony zestaw celów .
  5. Każdy system ma architekturę , zrozumiałą lub nie; czy to nagrane, czy koncepcyjne. Architekturę można zapisać za pomocą opisu architektonicznego .
  6. Opis architektoniczny jest podzielony na jeden lub więcej składników zwanych widokami (architektonicznymi) . Każdy widok dotyczy jednego lub więcej problemów interesariuszy systemu. Widok jest częściowym wyrazem architektury systemu w odniesieniu do określonego punktu widzenia .
  7. Punkt widzenia określa konwencje, według których widok jest tworzony, przedstawiany i analizowany. W ten sposób widok jest zgodny z punktem widzenia. Punkt widzenia określa języki (w tym notacje, modele lub typy produktów), które mają być używane do opisu widoku, oraz wszelkie powiązane metody modelowania lub techniki analizy, które mają być zastosowane do tych reprezentacji widoku. Te języki i techniki są wykorzystywane w celu uzyskania wyników odpowiednich do problemów, których dotyczy dany punkt widzenia.
  8. Opis architektoniczny wybiera jeden lub więcej punktów widzenia do wykorzystania. Wybór punktów widzenia zazwyczaj opiera się na rozważeniu interesariuszy, do których skierowana jest AD, oraz ich obaw. Definicja punktu widzenia może pochodzić z AD lub mogła zostać zdefiniowana gdzie indziej ( punkt widzenia biblioteki ).
  9. Widok może składać się z jednego lub kilku modeli architektonicznych . Każdy taki model architektoniczny jest opracowywany przy użyciu metod ustalonych przez powiązany z nim architektoniczny punkt widzenia. Model architektoniczny może uczestniczyć w więcej niż jednym widoku.

Zgodność

IEEE 1471 definiuje zestaw wymagań normatywnych dotyczących zgodnych opisów architektury, w tym:

  • Identyfikacja AD, wersja i informacje ogólne (punkt 5.1)
  • Identyfikacja interesariuszy systemu i ich obaw uznanych za istotne dla architektury (punkt 5.2)
  • Specyfikacje każdego punktu widzenia, który został wybrany do organizacji reprezentacji architektury oraz uzasadnienie tych wyborów (punkt 5.3)
  • Jeden lub więcej widoków architektonicznych (punkt 5.4)
  • Zapis wszystkich znanych niespójności wśród wymaganych składników opisu architektonicznego (punkt 5.5)
  • Uzasadnienie wyboru architektury (punkt 5.6)

Zobacz też

  •   1471-2000 — Zalecana praktyka IEEE dotycząca opisu architektonicznego systemów intensywnie korzystających z oprogramowania . 2000. doi : 10.1109/IEEESTD.2000.91944 . ISBN 0-7381-2518-0 .

Linki zewnętrzne

  • Witryna IEEE 1471
  • MEGAF to infrastruktura do realizacji frameworków architektury zgodnych z definicją frameworku architektury zawartą w normie ISO/IEC 42010.
Pobrano z „ https://en.wikipedia.org/w/index.php?title=IEEE_1471&oldid=1140987031 ”