Month: April 2019

Streszczenie: Wiele publikacji, w tym podręczniki akademickie, zawiera niespójności w opisach zastosowań metod i wzorców architektonicznych, kryjących się pod skrótami MOF, MDA, PIM, MVC, BCE. Skuteczna analiza oraz następujące po niej projektowanie oprogramowania, szczególnie gdy są to projekty realizowane w dużych zespołach, wymaga standaryzacji procesu wytwórczego i stosowanych wzorców i frameworków. W pracy tej podjęto próbę uporządkowania systemu pojęć opisujących ten proces , stosowanych do opisu wzorców architektonicznych. Przeprowadzono analizę kluczowych pojęć MOF i MDA, wzorców MVC i BCE, stworzono spójny opis łączący je w jeden system.

1. Wprowadzenie

Celem badań było zweryfikowanie obecnego stanu metod projektowania i opracowanie spójnego systemu pojęć i wzorców projektowych w obszarze projektowania logiki oprogramowania, jako jej abstrakcyjnego modelu. Wiele publikacji na temat analiz i projektowania, w obszarze inżynierii oprogramowania, przywołuje nazwy wzorców projektowych MVC i BCE oraz model PIM (patrz OMG MDA, OMG MOF 2016). Z uwagi na, nie raz, nie małe rozbieżności w interpretacji tych metod i wzorców, autor podjął próbę uporządkowania ich wzajemnych zależności.

2. Metody

Wykorzystano systemy notacyjne Object Management Group (OMG.org). Specyfikacja MOF opisuje trzy poziomy abstrakcji: M1, M2, M3 oraz poziom M0 czyli realne rzeczy (patrz struktura poziomów abstrakcji, OMG MOF 2016). M0 to realny system, poziom M1 to abstrakcja obiektów tego systemu (jego model) . Poziom M2 to związki pomiędzy klasami tych obiektów (nazwy ich zbiorów) czyli metamodel systemu. Poziom M3 to meta-metamodel poziom opisujący metodę modelowania z użyciem nazwanych elementów o określonej  semantyce i syntaktyce.

Proces analizy i projektowania został oparty na specyfikacji MDA (OMG MDA). Proces ten ma trzy fazy rozumiane jako tworzenie kolejnych modeli: CIM, PIM, PSM oraz fazę tworzenie kodu. Model CIM jest dokumentowany z użyciem notacji BPMN (OMG BPMN 2013) i SBVR (OMG SBVR 2017). Są to odpowiednio: modele procesów biznesowych oraz modele pojęciowe i reguły biznesowe. Modele PIM i PSM dokumentowane są z użyciem notacji UML (OMG UML 2017). Pomiędzy modelem CIM a PIM ma miejsce ustalenie listy usług aplikacyjnych (reakcje systemu), których mechanizm realizacji opisuje model PIM. Standardowym wzorcem używanym do modelowania architektury aplikacji jest wzorzec MVC. Komponent Model tego wzorca jest modelowany z użyciem wzorcza architektonicznego BCE.

[…]

Spis treści
1. Wprowadzenie 1
2. Metody 2
2.1. Semiotyka a UML 2
2.2. Specyfikacja MOF Poziomy abstrakcji 3
2.3. Specyfikacja MDA i model PIM 4
2.4. Wzorzec architektoniczny MVC 5
2.5. Wzorzec architektoniczny BCE 5
3. Rezultaty 6
3.1. Założenie uproszczające 6
3.2. Zintegrowany model struktury procesu projektowania aplikacji 7
4. Dyskusja 8
5. Dalsze prace 8
6. Bibliografia 9
7. Kluczowe pojęcia metodyczne 11

Cała publikacja …

Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns
Jaroslaw Zelinski (Independent Researcher, Poland)

Source Title: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities
Copyright: ? 2020 |Pages: 12
DOI: 10.4018/978-1-7998-2142-7.ch003

Od lat nie cichnie dyskusja na temat przepływu pracy i dokumentów oraz zarządzania procesami biznesowymi zachodzącymi w firmach. Nierzadko wiele pojęć z tego zakresu stosujemy błędnie, dlatego warto usystematyzować sobie wiedzę o nich, wskazać różnice między nimi i ostatecznie odpowiedzieć na pytanie, czy oprogramowania wspomagające ten obszar można z sukcesem wdrożyć we wszystkich przedsiębiorstwach. To kluczowe, jeśli chcemy skutecznie zarządzać procesami w firmie.

Dokumenty i procesy

Demagogią jest twierdzenie, że koszt przechowywania dokumentu elektronicznego to tylko kilka mikrometrów dysku i koszt tego miniobszaru. Prawdziwym kosztem przechowania takiego dokumentu jest bowiem koszt całej infrastruktury wraz z jej zabezpieczeniem. Gdyby było inaczej, każdy z nas miałby już w firmie elektroniczne superarchiwum.

Co więcej, obieg dokumentów to nie ? jak się mylnie sądzi ? zarządzanie procesami. Dokumenty są tylko jednym z elementów mapy procesów organizacji, a zatem systemy obiegu dokumentów to wsparcie zarządzania zorientowanego na procesy, nie zaś systemy zarządzania procesami biznesowymi.

Wielu utożsamia pojęcie obiegu dokumentów, obiegu informacji z procesami biznesowymi i ich zarządzaniem. Jest to moim zdaniem kluczowe nieporozumienie, żeby nie powiedzieć błąd.

Proces biznesowy to działanie charakteryzujące się przede wszystkim wnoszeniem wartości dodanej i posiadanie papieru czy dokumentu w wersji elektronicznej nie ma tu nic do rzeczy. Na mapie procesów biznesowych dokumenty i ich kolejne wersje stanowią produkty procesów (niejedyne zresztą). Proces polegający na podjęciu decyzji to praca człowieka niosąca dużą wartość dodaną, ale nie obieg dokumentów będących śladami po niektórych tylko procesach w firmie. Dla przykładu procesem jest wyprodukowanie podzespołu i nie ma to nic wspólnego z systemem obiegu dokumentów. Gdzieś po drodze powstanie dokumentacja techniczna, ale jeden z elementów systemu zarządzania procesami w firmie, jego podsystem.

Systemy obiegu dokumentów i obiegu informacji są ważnymi elementami w każdej organizacji, ale są to tylko produkty i to nie wszystkie na mapie procesów biznesowych firmy, dlatego właśnie nazywanie systemów, zaliczanych do klasy workflow, systemami BPM (Business Process Management) uważam za poważne nadużycie.

Kolejną ślepą uliczką jest traktowanie systemów klasy workflow jako narzędzi ścisłej kontroli poczynań pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników (np. czasu ich pracy). Znacznie skuteczniejsze są systemy informatyczne zaprojektowane tak, by pomagały pracownikom osiągać ich cele. Takie niejako wdrażają się same. Z kolei systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez pracowników.

Jednak coś w tym jest, że obieg dokumentów (informacji) czasami staje się modelem procesów.

Kiedy i co modelować

Jeżeli czegoś nie można narysować, to znaczy, że to nie istnieje! To stwierdzenie odnosi się do istoty procesów i zarządzania nimi. Aby czymkolwiek zarządzać, należy to najpierw opisać, czyli udokumentować. Takim opisem będzie mapa procesów biznesowych, która stanowi model firmy z perspektywy jej funkcjonowania. Jak ją prawidłowo wykonać?

Model firmy powinien w sposób jasny i zrozumiały dla jej pracowników opisywać firmę, jej cel rynkowy oraz wszelkie jej aktywności wewnętrzne i zewnętrzne. Jest on niezbędny do przewidywania zachowań firmy, ale także do przygotowania jej na wdrożenia systemów informacyjnych.

Cała publikacja w ostatnim numerze  Informacja Zarządcza 18/2019