Model przestrzenny Diagramu Obiegu Dokumentów Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska
Wprowadzenie Sposoby weryfikacji architektury oprogramowania: - badanie prototypu (idea proof-of-concept) - przegląd/inspekcja modelu (scenariusze). Moment zakończenia prac nad architekturą oprogramowania: - kompletność modelu - termin przeglądu/inspekcji modelu Przedstawiony będzie model przestrzenny DOD (Diagram Obiegu Dokumentów) 3DOD. Służy on do spójnego i kompletnego opisu architektury oprogramowania w perspektywie projektowej, a także do wygenerowania modeli UML przedstawiających strukturę, zachowanie i funkcjonalność systemu informatycznego. 2
Plan prezentacji Opis architektury oprogramowania Wymiary architektury oprogramowania Diagramy obiegu dokumentów (DOD) Model przestrzenny DOD Wymiar funkcjonalności DOD Wymiar struktury DOD Wymiar zachowania DOD Automatyczne mapowanie elementów Podsumowanie 3
Opis architektury oprogramowania Nie jest możliwe utworzenie prostego i zrozumiałego modelu opisującego wszystkie aspekty projektowanego systemu Architektura składa się z wielu powiązanych modeli opisujących wybrane aspekty Najważniejsze aspekty architektury (model perspektyw architektonicznych 4 + 1 ): Perspektywa przypadków użycia Perspektywa projektowa Perspektywa implementacyjna Perspektywa procesowa Perspektywa wdrożeniowa 4
Opis architektury oprogramowania ciąg dalszy Ogólny model projektowania architektury oprogramowania (Hofmeister, Kruchten, Nord) : Architektoniczna Analiza wynik: Architektonicznie Znaczące Wymagania Architektoniczna Synteza wynik: Propozycje rozwiązań architektonicznych Architektoniczne Oszacowanie wynik: Zweryfikowana architektura oprogramowania 5
Opis architektury oprogramowania ciąg dalszy Cele analizy architektonicznej (The four C s) Kompletność (ang. Completeness) Zewnętrzna powiązanie z wymaganiami Wewnętrzna zamodelowanie wszystkich elementów Spójność (ang. Consistency) - nazw, interfejsów, zachowania, interakcji Niesprzeczność elementów różnych modeli Niesprzeczność elementów tego samego modelu Kompatybilność (ang. Compatibility) Prawidłowość (ang. Correctness) 6
Wymiary architektury oprogramowania ciąg dalszy Perspektywę projektową (logiczną) można w sposób wystarczający przedstawić za pomocą modeli (wymiarów) opisujących: Strukturę np. diagram klas, Zachowanie np. diagram stanów, Funkcjonalność np. diagram przypadków użycia Brak reguł wiązania elementów w danej perspektywie, np. w projektowej: Struktura, Zachowanie, Funkcjonalność Główny powód: stosowanie języka UML, którego semantyka określona jest w języku naturalnym 7
Wymiary architektury oprogramowania ciąg dalszy 8
Diagram Obiegu Dokumentów funkcjonalność, zachowanie, struktura w jednym modelu Diagram Obiegu Dokumentów umożliwia za pomocą jednego diagramu (modelu) zaprezentować trzy wymiary: Strukturę nagłówek diagramu, Zachowanie operacje na obiektach, Funkcjonalność operacje zgrupowane w partycje. Umieszczenie elementów DOD w przestrzeni umożliwia otrzymanie rzutów tych elementów wraz z ich związkami na płaszczyzny, które można interpretować jako wymiary: struktury, zachowania, funkcjonalności. 9
Diagram Obiegu Dokumentów funkcjonalność, zachowanie, struktura w jednym modelu Opinia Podanie Rejestr Kancelaryjny Decyzja [2] [1] [3] Petent 01 02 P K 18 17 Urzędnik 05 09 03 09 04 RK 16 11 15 06 08 06 08 12 14 Dyrektor 07 07 13 10
Model przestrzenny DOD wizualizacja przestrzenna Diagramu Obiegu Dokumentów 11
Model przestrzenny DOD wymiary Rzut prawy boczny 3DOD pozwala obejrzeć funkcjonalność modelu. Rzut górny 3DOD pozwala obejrzeć strukturę modelu. Rzut dolny 3DOD obejrzeć zachowanie obiektów modelu. Rzut główny 3DOD to płaski diagram obiegu dokumentów. 12
Model przestrzenny DOD wymiar funkcjonalności 13
Model przestrzenny DOD wymiar struktury 14
Model przestrzenny DOD wymiar zachowania 15
Model przestrzenny DOD wymiar zachowania c.d. 16
Model przestrzenny DOD Diagram Obiegu Dokumentów rzut prostopadły 17
DOD mapowanie elementów Z diagramu DOD można wygenerować w prosty sposób (proste transformacje) trzy diagramy UML wystarczająco opisujące architekturę oprogramowania w perspektywie projektowej: Diagram klas Diagram stanów Diagram przypadków użycia. 18
DOD mapowanie elementów Diagram obiektów wymiar struktury Diagram stanów wymiar zachowania class Diagram klas stm Decyzja-statechart Opinia [2] Podanie [1] Decyzja [3] Start 10 Utworzony 11 12 Podpisany 13 14 Zarchiwizowany 15 16 Wysłany 17 Koniec Petent Urzędnik Opinia Podanie Rejestr Kancelaryjny Decyzja [2] [1] [3] 01 18 P K 02 17 04 RK 16 05 09 03 09 11 15 06 06 08 08 12 14 Diagram Obiegu Dokumentów DOD = funkcjonalność + struktura + zachowanie Dyrektor 07 07 13 uc Diagram UC Obsługa sprawy Utworzenie opinii - 05 Akceptacja opinii - 07 Utworzenie decyzji - 11 Akceptacja podania - 07 Urzędnik Dyrektor Kontrola podania - 03 Akceptacja decyzji - 13 Archiwizacja dokumentów - 09,15 Rejestr Kancelaryjny Diagram przypadków użycia wymiar funkcjonalności 19
Podsumowanie - 1 Przedstawiono model przestrzenny DOD do modelowania architektury oprogramowania w perspektywie projektowej. Zaleta modelu przestrzennego DOD zrozumiałość, spójność (ang. Consistency) wygenerowanych diagramów UML, kompletność opisu (ang. Completeness). Automatyczne zachowanie spójności i kompletności opisu przy modyfikacji, wprowadzaniu, usunięciu elementu w jednym z trzech wymiarów (ang. Refinement) 20
Podsumowanie - 2 Na podstawie jednego diagramu modelu przestrzennego DOD można wygenerować kilka diagramów UML opisujących spójnie i kompletnie system informatyczny w perspektywie projektowej. Transformacje elementów z trzech podstawowych diagramów UML do modelu przestrzennego DOD może wspierać architektów przy ocenie spójności i kompletności perspektywy projektowej moment zakończenia prac projektowych. 21
Pytania? 22