Model architektoniczny oprogramowania - Software architectural model
Model architektoniczny (w oprogramowaniu ) jest bogaty i rygorystyczny schemat, tworzone przy użyciu dostępnych standardów, w których główną troską jest, aby zilustrować zestaw specyficzną kompromisów tkwiących w konstrukcji i projektowania systemu lub ekosystemu. Architekci oprogramowania używają modeli architektonicznych do komunikowania się z innymi i szukania opinii rówieśników. Model architektoniczny jest wyrazem punktu widzenia w architekturze oprogramowania.
Niektóre kluczowe elementy modelu architektonicznego oprogramowania to:
- bogaty : dla danego punktu widzenia powinno być wystarczających informacji, aby szczegółowo opisać obszar. Informacji nie powinno brakować ani niejasne. Celem jest zminimalizowanie nieporozumień, a nie ich utrwalanie. Zobacz uwagi poniżej dotyczące „głównego problemu”.
- rygorystyczny : architekt zastosował określoną metodologię do stworzenia tego konkretnego modelu, a wynikowy model „wygląda” w określony sposób. Oto test rygorystyczności: gdyby dwóch architektów w różnych miastach opisywało to samo, powstałe diagramy byłyby prawie identyczne (z możliwym wyjątkiem układu wizualnego, do pewnego stopnia).
- diagram : ogólnie rzecz biorąc, model może odnosić się do dowolnej abstrakcji, która upraszcza coś w celu odniesienia się do określonego punktu widzenia. Ta definicja wyraźnie podklasy „modele architektoniczne” zalicza się do podzbioru opisów modeli, które są przedstawiane w postaci diagramów.
- standardy : standardy obowiązują, gdy wszyscy je znają i wszyscy z nich korzystają. Pozwala to na poziom komunikacji, którego nie można osiągnąć, gdy każdy diagram znacznie się od siebie różni. UML jest najczęściej cytowanym standardem.
- główny problem : łatwo jest być zbyt szczegółowym, włączając wiele różnych potrzeb na jednym diagramie. Należy tego unikać. Lepiej jest narysować wiele diagramów, po jednym dla każdego punktu widzenia, niż narysować „mega diagram”, który jest tak bogaty w treść, że jego zrozumienie wymaga dwuletnich studiów. Pamiętaj o tym: budując domy, architekt dostarcza wiele różnych schematów. Każdy jest używany inaczej. Często ostateczny pakiet planów będzie zawierał wiele razy diagramy z planem piętra: plan ramowy, plan elektryczny, plan ogrzewania, hydraulika itp. Nie mówią tylko: to plan piętra, więc 100% informacji, które MOŻNA przejść należy tam umieścić plan piętra. Podwykonawca hydrauliki nie potrzebuje szczegółów, na których zależy elektrykowi.
- zilustruj : ideą tworzenia modelu jest komunikacja i poszukiwanie cennych informacji zwrotnych. Celem diagramu powinno być udzielenie odpowiedzi na konkretne pytanie i podzielenie się nią z innymi, aby (a) sprawdzić, czy się zgadzają, oraz (b) pokierować ich pracą. Ogólna zasada: wiedz, co chcesz powiedzieć i na czyją pracę zamierzasz wpłynąć.
- określony zestaw kompromisów : metodologia analizy kompromisów architektury (ATAM) opisuje proces, w którym architektura oprogramowania może zostać zweryfikowana pod kątem adekwatności. ATAM robi to, wychodząc od podstawowego założenia: nie ma czegoś takiego jak „jeden rozmiar dla wszystkich”. Możemy stworzyć ogólny projekt, ale potem musimy go dostosować do konkretnych sytuacji w oparciu o wymagania biznesowe. W efekcie dokonujemy kompromisów. Diagram powinien uwidocznić te konkretne kompromisy. Dlatego zanim architekt utworzy diagram, powinien być przygotowany do opisania słowami, które kompromisy próbuje zilustrować w tym modelu.
- kompromisy nieodłącznie związane ze strukturą i projektem : komponent nie jest kompromisem. Kompromisy rzadko przekładają się na obraz na diagramie. Kompromisy to pierwsze zasady, które doprowadziły do powstania modeli projektowych. Kiedy architekt chce opisać lub bronić konkretnego kompromisu, diagram może posłużyć do obrony pozycji.
- system lub ekosystem : ogólnie modelowanie można przeprowadzić na różnych poziomach abstrakcji. Przydatne jest modelowanie architektury konkretnej aplikacji wraz z komponentami i interakcjami. Rozsądne jest również modelowanie systemów aplikacji potrzebnych do realizacji pełnego procesu biznesowego (np. Od zamówienia do gotówki). Jednak postrzeganie modelu pojedynczego komponentu i jego klas jako architektury oprogramowania nie jest zwykle przydatne. Na tym poziomie model, choć cenny sam w sobie, ilustruje projektowanie znacznie bardziej niż architekturę.
Zobacz też
Bibliografia
Zewnętrzne linki
- Opublikowane przez SEI definicje architektury oprogramowania zawierają listę definicji architektury używanych przez autorów klasycznych i współczesnych.
- Model architektoniczny zawiera definicję modelu architektonicznego z bazy danych inżynierii oprogramowania obiektowego Uniwersytetu Ottawy.
- Architectural Tradeoff Analysis Method (ATAM) to metoda, za pomocą której można ocenić architekturę pod kątem przydatności i dopasowania do wymagań.
 |
Ten artykuł dotyczący inżynierii oprogramowania jest skrótem . Możesz pomóc Wikipedii, rozbudowując ją . |