Model przestrzenny Diagramu Obiegu Dokumentów

1. Model przestrzenny Diagramu Obiegu Dokumentów Stanisław Niepostyn, Ilona Bluemke Instytut Informatyki, Politechnika Warszawska

2. 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.

3. 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

4. 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

5. Opis architektury oprogramowaniacią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

6. Opis architektury oprogramowaniacią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)

7. 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

8. Wymiary architektury oprogramowania ciąg dalszy

9. Diagram Obiegu Dokumentówfunkcjonalność, 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.

10. Diagram Obiegu Dokumentówfunkcjonalność, zachowanie, struktura w jednym modelu

11. Model przestrzenny DODwizualizacja przestrzenna Diagramu Obiegu Dokumentów

12. Model przestrzenny DODwymiary • 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.

13. Model przestrzenny DODwymiar funkcjonalności

14. Model przestrzenny DODwymiar struktury

15. Model przestrzenny DODwymiar zachowania

16. Model przestrzenny DODwymiar zachowania – c.d.

17. Model przestrzenny DODDiagram Obiegu Dokumentów – rzut prostopadły

18. 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.

19. DOD – mapowanie elementów Diagram obiektów – wymiar struktury Diagram stanów – wymiar zachowania Diagram Obiegu Dokumentów DOD = funkcjonalność + struktura + zachowanie Diagram przypadków użycia – wymiar funkcjonalności

20. 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)

21. 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.

22. Pytania ?