Model informacyjny

Równolegle z opracowywaniem modelu przypadków użycia tworzony jest model informacyjny systemu. Model pozwala na wyrażenie aspektu statycznego

50 Inżynieria oprogramowania – badania i praktyka

modelowanego systemu – odwzorowanie struktury informacji/danych przetwa-rzanych w systemie niezbędnych do realizacji funkcjonalności oferowanych przez system.

Model zawiera charakterystyki elementów należących do dziedziny proble-mu objętej przedsięwzięciem informatycznym wraz z definicjami statycznych relacji zachodzących pomiędzy nimi. Tworząc model podejmowane są kluczo-we decyzje o kształcie systemu i sposobie, w jaki będzie on odwzorowywał rzeczywistość biznesową, a w konsekwencji wspierał swoich użytkowników.

Identyfikacja elementów modelu informacyjnego systemu ma charakter przyrostowy i iteracyjny. Zgodnie z założeniami metodyki rozpoczyna się od wskazania kluczowych elementów dziedziny problemu wokół, których realizo-wane jest przetwarzanie w systemie (zwykle na podstawie opracorealizo-wanego na etapie analizy biznesowej modelu koncepcji biznesowych) i polega na stop-niowym uzupełnianiu modelu o nowe, identyfikowane podczas analizy funk-cjonalności elementy niezbędne do jej realizacji oraz uszczegóławianiu specyfi-kacji tych elementów. Zawarte w modelu elementy oraz ich specyfikacje są ściśle powiązane z pozostałymi artefaktami analizy systemowej – wynikają bezpośrednio z przebiegów przypadków użycia, zaprojektowanych interfejsów użytkownika oraz zdefiniowanych reguł i ograniczeń systemowych determinu-jących przetwarzanie systemu.

Model informacyjny systemu uwzględnia przede wszystkim dane trwałe, aczkolwiek mogą być uwzględnione w nim również dane tymczasowe jeżeli są one wykorzystywane w realizacji funkcjonalności systemu (np. kryteria wyszu-kiwania, struktury danych raportów).

Wykorzystywanym środkiem wyrazu umożliwiającym zapis przyjętej struk-tury zawartości informacyjnej systemu jest diagram klas języka UML (Rysunek 1.27). Klasa odzwierciedla przyjętą definicję rozważanego pojęcia dziedziny problemu, opracowaną z uwzględnieniem przyjętej perspektywy oraz odpo-wiedniego (wynikającego z dostarczanej przez system funkcjonalności) pozio-mu szczegółowości. Stanowi zapis/model tej definicji. Klasa precyzuje od-zwierciedlane pojęcie poprzez wskazanie jego znaczenia (semantyki) oraz cech strukturalnych bytów specyfikowanych (klasyfikowanych) przez pojęcie. Cechy strukturalne pojęcia określane są za pomocą właściwości klasy. Zestaw właści-wości klasy wyznacza zawartość informacyjną jaką niosą ze sobą obiekty klasy przetwarzane w projektowanym systemie.

Przyjęty w prezentowanej metodyce poziom szczegółowości opisu właści-wości klas uwzględnia specyfikację ograniczeń nakładanych na modelowane cechy, w konsekwencji sygnatury właściwości (atrybutów oraz ról

wynikają-Biznesowe korzyści ze stosowania standardów oraz kompleksowych procesów… 51 cych z asocjacji) uzupełniane są o: typ – precyzujący dopuszczalne wartości, jakie mogą być przypisane właściwości; liczność – definiującą liczbę tych war-tości; predefiniowane w języku UML modyfikatory – precyzujące wymaganie unikalności, niezmienności właściwości, ograniczenie podzbioru czy wniosko-walność.

Rysunek 1.27. Model informacyjny systemu.

Ważnym elementem modelu opracowywanego zgodnie z zasadami prezen-towanej metodyki są prawidłowo konstruowane nazwy elementów modelu (klas, właściwości – atrybutów i ról oraz asocjacji). Nazwy powinny precyzo-wać znaczenie etykietowanego elementu w ramach dziedziny problemu, tak by prezentowana informacja była interpretowana jednoznacznie, a diagram zro-zumiały, czytelny i możliwy do interpretacji w sposób intuicyjny. Do zapisu nazw stosowane są konwencje zgodne z zaproponowanymi w specyfikacji języ-ka UML.

W kolejnych krokach etapu analizy model informacyjny systemu jest uszczegóławiany tak, by docelowo uwzględniać:

— specyfikacje ograniczeń-niezmienników nałożonych na elementy modelu:

klasy, właściwości, asocjacje,

— definicje wartości początkowych/domyślnych dla właściwości,

— definicje algorytmów wyliczenia dla właściwości wnioskowanych.

52 Inżynieria oprogramowania – badania i praktyka

Powyższe elementy definiowane są jako ograniczenia (ang. Constraint), opi-sujące odpowiednio klasy, atrybuty lub role, z treścią zapisaną w postaci wyra-żeń języka OCL.

Dla klas modelu informacyjnego nie są definiowane operacje. Wyjątek sta-nowią operacje pomocnicze definiowane w kontekście wyrażeń OCL – operacje

«OclHelper».

W celu uproszczenia, złożony lub obszerny model informacyjny może być podzielony na części. Do reprezentacji przyjętej struktury modelu wykorzystuje się diagram pakietów.

1.7 Podsumowanie

Powołanie się w niniejszym dokumencie na standardy, oparcie rozważań o dobrze określony analityczny proces produkcyjny i przywołanie często stoso-wanych technik miało na celu pokazanie, iż stosowanie spójnych i dedykowa-nych narzędzi do prowadzenia prac analityczdedykowa-nych może przyczynić się do osią-gania różnego rodzaju korzyści biznesowych, począwszy od poprawy jakości produktów, a na docelowym obniżeniu kosztów realizacji prac analitycznych zakończywszy.

Wszystkie z omówionych w dokumencie standardów, z punktu widzenia prowadzenia prac analitycznych, dostarczają ontologie służące do opisu dedy-kowanego aspektu rzeczywistości. Zakładając, iż ontologia jest kompletna, ewentualnie w wystarczającym, z praktycznego punktu widzenia, zakresie po-krywa obszar zastosowań, wówczas wysiłek, jaki należy poświęcić na wypra-cowanie metod opisu danego obszaru skraca się do minimum potrzebnego do zdobycia kompetencji w stosowaniu standardu. W dalszej kolejności, posiadając wystarczająco kompletną ontologię, w dużym stopniu zmniejszamy ryzyko wykonania niepełnych prac analitycznych i wszystkich tego późniejszych kon-sekwencji. Następną korzyścią o jakiej warto wspomnieć przy okazji niektórych standardów, jest możliwość skonstruowania procesu wytwórczego wokół rodza-jów artefaktów opisanych w metamodelu języka. Przykładem takiego standardu jest BMM, opisany w rozdziale Strategia biznesu. Zdefiniowane pojęcia misji, wizji, celów strategicznych i taktycznych, strategii i taktyk, połączone dobrze określonymi relacjami narzucają określoną kolejność prowadzenia prac mają-cych na celu stworzenie planu biznesowego. Uzupełnienie tych pojęć o techniki pozwalające na uzyskiwanie informacji wymaganych do stworzenia modelu skutkuje powstaniem narzędzi facylitacyjnych, mogących znaleźć zastosowanie podczas warsztatów analitycznych. Oparcie się o jednolity standard powoduje, iż powstające narzędzia są stabilne, jednolite, spójne, a co za tym idzie,

możli-Biznesowe korzyści ze stosowania standardów oraz kompleksowych procesów… 53 we do stosowania przez różne zespoły, co z czasem zaowocuje nabyciem wyso-kich kompetencji przez wszystwyso-kich interesariuszy, wymaganych do aktywnego uczestnictwa w projektach realizowanych w organizacji, tym samym zmniejsza-jąc koszty prowadzenia prac.

Powiązanie (bezpośrednio, bądź pośrednio) komplementarnych standardów w ramach jednego procesu produkcyjnego, uzupełnionego o techniki wymagane do wypracowania artefaktów opisanych standardami daje organizacji dodatko-we korzyści. Pierwszą z nich jest znaczne zwiększenie przewidywalności prac, co jest możliwe do osiągnięcia dzięki temu, iż prace prowadzone są według jednolitych zasad i z wykorzystaniem jednolitych i logicznie spójnych środków wyrazu a czego korzyści są trudne do przecenienia. Ta cecha procesu produk-cyjnego jest istotna zarówno dla zespołów roboczych, realizujących prace jak i pozostałych interesariuszy, którzy w pracach uczestniczą, bądź muszą być zaznajamiani z niektórymi z ich efektów. Drugą, jest minimalizacja wysiłku potrzebnego do stałego rozwoju procesu produkcyjnego poprzez korzystanie z wypracowanych już rozwiązań cząstkowych. W pewnym sensie, Centra Do-skonałości odpowiedzialne za rozwój stosowanego procesu wytwórczego, stają się integratorami standardów, ograniczając wysiłek potrzebny na wypracowy-wanie cząstkowych rozwiązań językowych.

Bibliografia

[COSMIC14] The Common Software Measurement International Consortium FFP, Measure-ment Manual Version 4.0, 2014,

[Oul05] Martyn Ould. Business Process Management – A rigorous approach., Meghan Kiffer Press, 30 Styczeń, 2005,

[OMG09] OMG, Model Driven Architecture, Guide Version 1.0.1, 2009 [OMG12] OMG, Systems Modeling Language, Version 1.3, 2012 [OMG13a] OMG, Business Process Model and Notation, Version 2.0, 2013

[OMG13b] OMG, Semantics of Business Vocabulary and Business Rules, Version 1.2, 2013 [OMG13c] OMG, Unified Modeling Language, Version 2.5, 2013

[OMG14a] OMG, Decision Model and Notation, Version 1.0, 2014 [OMG14b] OMG, Business Motivation Model, Version 1.2, 2014 [OMG14c] OMG, Object Constraint Language, Version 2.4, 2014 [RST] RuleSpeak, http://www.rulespeak.com/en/

[RX] RuleXpress , http://www.rulearts.com/rulexpress [SD] Sapiens DECISION . http://www.sapiensdecision.com/

[TDM] The Decision Model, http://kpiusa.com/index.php/The-Decision-Model/the-decision-model.html

[VPEE] Visual Paradigm Enterprise Edition, www.visual-paradigm.com,

Rozdział 2

Wybrane aspekty realizacji rozwiązań