Ten artykuł można czytać na dwa sposoby: analitycy czytają od dechy do dechy po kolei ;). Menedżerowie i tak zwany biznes czytają od razu koniec, to jest część Na zakończenie, gdy uznają, że nie wierzą w te wnioski (wyrok) to zaczynają od początku czyli czytają uzasadnienie :).
Niedawno napisałem:
Pomiędzy pojęciami abstrakcja i model jest pewna kluczowa różnica: abstrakcja to pojęcie zaś model to opis mechanizmu, jego konstrukcja, działanie, budowa. Prosty przykład: nazwane prostokąty na typowym diagramie struktury organizacyjnej to abstrakcje komórek organizacyjnych i osób w nich zatrudnionych, prostokąty te wraz z liniami je łączącymi stanowią, jako całość, model podległości zasobów w organizacji. (Źródło: Analiza a modelowanie czyli ile abstrakcji a ile rzeczywistości | | Jarosław Żeliński IT-Consulting)
Kontynuując temat z innej perspektywy powiemy sobie teraz o etapach analizy i projektowania w inżynierii, nie tylko oprogramowania, w oparciu o MDA ([[Model Driven Architecture]], www.omg.org/mda, polecam także pojęcie [[model driven engineering]]). Dobra informacja dla czytelników: na końcu się wszystko wyjaśni, można pominąć część o MDA 🙂
MDA
Pięć lat temu, jeden z artykułów o modelowaniu i projektowaniu, kończyłem tymi słowami:
Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:
- Analiza biznesowa, której produktem są: model organizacji (model biznesowy) oraz opis tego co ma powstać (opis, wymagania na oprogramowanie). Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu.
- Wytworzenie oprogramowania polegające na: opracowaniu szczegółów architektury, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne), kodowaniu oraz dostarczeniu i wdrożeniu.
Źródło: Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie! | | Jarosław Żeliński IT-Consulting
Powoływałem się w tym tekście właśnie na MDA. Czymże to jest? Na stronach OMG znajdziemy: Document — ormsc/14-06-01 (MDA Guide revision 2.0) Contact: Dr. Jon M. SiegelThis final draft of the revised MDA Guide edited in Boston on 18 June 2014 reflects all AB edits requested at the Reston and Boston AB meetings. (Źródło: OMG Document — ormsc/14-06-01 (MDA Guide revision 2.0))
Skorzystam z kilku cytatów i napisze co nieco o MDA. Poniżej kluczowe tezy, nie miałem tu ambicji literalnego tłumaczenia tego dokumentu, chodziło mi o pryncypia.
This guide describes the Model Driven Architecture (MDA) approach as defined by the Object Management Group (OMG). MDA provides an approach for deriving value from models and architecture in support of the full life cycle of physical, organizational and I.T. systems (A ?System?, in this context, is any arrangement of parts and their interrelationships, working together as a whole.). The MDA approach represents and supports everything from requirements to business modeling to technology implementations. By using MDA models, we are able to better deal with the complexity of large systems and the interaction and collaboration between organizations, people, hardware, software.
Stosowanie modeli pozwala znacznie lepiej radzić sobie ze złożonością wielkich systemów jakimi są organizacje oraz funkcjonujące w nich związki między ludźmi, oprogramowaniem i infrastrukturą. Fakt, że badane organizacje współpracują z innymi, dodatkowo komplikuje tę całość.
Models as communications vehicles
A fundamental value proposition for models and modeling is to facilitate a team or community coming to a common understanding and/or consensus.
Jedną z głównych ról modeli, poza ich analizą, jest komunikacja: komunikujemy innym członkom zespołu (także klientom) to co zrozumieliśmy i to czego oczekujemy. Tak więc modele są zarówno opisem rzeczywistości powstałym w toku jej zrozumienia, są także opisem tego co ma powstać, jeżeli chcemy tę rzeczywistość stworzyć.
[?]Abstraction deals with the concepts of understanding a system in a more general way; said in more operational terms, with abstraction one eliminates certain elements from the defined scope; this may result in introducing a higher level viewpoint at the expense of removing detail. A model is considered more abstract if it encompasses a broader set of systems and less abstract if it is more specific to a single system or restricted set of systems. [?]
Podstawową rzeczą w analizie jest redukowanie szczegółów i uogólnianie. Człowiek nie jest w stanie analizować czegoś co składa się z setek detali.
Model Analytics
Once models are captured as semantic data various analytics can be executed across those models including model validation, statistics and metrics. Analytics assists in decision making, monitoring and quality assessment. OMG MDA Guide rev. 2.0 June 2014 page 2
Modele pojęciowe i analityczne służą do zrozumienia badanej rzeczywistości. Modele tworzone (projektowanie) służą do testowania pomysłów i podejmowania decyzji, dalej zaś stanowią opis cech wymaganego rozwiązania. Modele wykonywalne to inne modele ale bazują na modelach analitycznych. Poniżej, na bazie MOF ([[Meta Object Facility]]), pokazano trzy poziomy abstrakcji (poziom zerowy to rzeczywistość).
Abstrakcja to “uproszczony” (pozbawiony zbędnych szczegółów) model określonej rzeczywistości. Metamodel to mechanizm tworzenia tej rzeczywistości w tym także model pojęciowy (więcej w dalszej części).
Model (M1) więc jest albo wynikiem (produktem) analizy badanej rzeczywistości, albo wynikiem (produktem) procesu jej projektowania (projektowania rozwiązania).
Model Simulation and Execution
Models as data can drive simulation engines that can assist in both analytics and execution of the designs captured in models. Simulation assists in the human understanding of how a modeled system will function as well as a way to validate that models are correct. Models can, in some cases be directly executed ? serving as the ?source code? for highlevel applications that implement processes, data repositories and service endpoints. Model execution provides a direct and immediate path to realizing a design with a minimum of technical details being exposed. DBMS Schema and process models are well-known categories of (partially) executable models.[?]
Modele symulacyjne służą do testowania hipotez i podejmowani decyzji. Modele wykonywalne, w tym tworzone automatycznie na bazie modeli abstrakcyjnych, to narzędzia do tworzenia wykonywalnego kodu. Nie tylko w moim mniemaniu, jest to albo daleka przyszłość (mam na myśli komercyjne zastosowania) albo wyłącznie akademickie badania. Wiem, że są udane próby generowania działającego kodu z modeli, jednak wymagania na ilość detali, jakie trzeba zadeklarować w tych modelach, zbliża ich złożoność do złożoności kodu jaki powstaje. Nie będziemy się tu zajmowali modelami wykonywalnymi.
Cztery produkty
Te dwa opisane na początku etapy do analiza systemowa organizacji (potocznie “analiza biznesowa”) oraz implementacja rozwiązania. Produkty to …
MDA to architektura mająca trzy poziomy modelowania, nazywane “od góry” CIM (Computation Independent Model), PIM (Platform Independent Model) i PSM (Platform Specific Model).
Architectural Layers It is useful to identify particular ?layers? of an architecture with respect to its level of abstraction. While there can be any number of architectural layers, a broad categorization of this concept is:
- Business or domain models ? models of the actual people, places, things, and laws of a domain. The ?instances? of these models are ?real things?, not representations of those things in an information system. In MDA domain models have historically been called a ?CIM? for ?Computation Independent Model?.
- Logical system models ? models of the way the components of a system interact with each other, with people and with organizations to assist an organization or community in achieving its goals. [model PIM]
- Implementation models ? the way in which a particular system or subsystem is implemented such that it carries out its functions. Implementation models are typically tied to a particular implementation technology or platform. [model PSM].
Model CIM opisuje ludzi i ich związki, miejsca, prawa rządzące tym wszystkim. Ten model opisuje realną, badaną rzeczywistość całkowicie abstrahując od wykorzystywanych ewentualnie posiadanych narzędzi informatycznych (w przypadku start-up’u lub rozwoju organizacji jest to przyszła jej postać). Nie jest to model jakiegokolwiek oprogramowania ani tego jak ono działa. Produktem tego etapu są: modele procesów biznesowych, specyfikacja reguł biznesowych, biznesowy słownik pojęć i modele pojęciowe.
Model PIM opisuje komponenty aplikacji, ich wzajemne interakcje, logikę działania tych komponentów (ta część logiki opisanej w modelu CIM, która ma być realizowana w aplikacji). Produktem tego etapu są modele: przypadków użycia (w tym postać nośników danych, mockup’y ekranów), komponentów, wewnętrzne struktury komponentów (modele dziedziny z perspektywy wzorca MVC), interakcji, inne jeśli konieczne.
Model PSM to model będący projektem wykonawczym. Jest to rozszerzenie modelu PIM, uszczegółowienie go wraz z dodatkowymi elementami technicznymi (realizującymi środowisko, bezpieczeństwo, wymaganą wydajność itp.). Kod aplikacji to materializacja (implementacja) modelu PSM.
Powyższe, to cztery produkty powstające w tym procesie. Dlaczego pisze o dwóch etapach? Poniżej wyjaśnienie.
Diagram obrazuje produkty/fazy definiowane jako MDA. Każdy produkt analizy to określony zestaw modeli. Na diagramie wskazano jakich notacji używa się w każdym z nich (tu bazując na notacjach rodem z OMG). Tu przypominam to co już nie raz pisałem: celem jest zrozumienie (i tworzenia potrzebnych w danym przypadku modeli) oraz przekazane tej wiedzy, a nie tworzenie “jakichś modeli i dokumentów”. Każdy model, jego powstanie, ma określony cel.
Jeszcze stosunkowo niedawno w moich projektach związanych z oprogramowaniem, wyróżniałem trzy etapy: analiza organizacji, specyfikacja wymagań oraz opracowanie logiki dla dedykowanych komponentów oprogramowania. W końcu, po kilku projektach, przekonałem się, że ten podział “nie działa”. Dlaczego?
Skoro na etapie CIM opracowaliśmy między innymi model logiki biznesowej dla danej organizacji (w tym reguły biznesowe, słownik pojęć) to już ją, te logikę, mamy. Okazało się, że ten “trzeci etap” w zasadzie jest sztuczny, gdyż rzetelne opracowanie CIM to także “ta” logika. Tu warto przytoczyć diagram:
Swego czasu pisałem także o testowaniu modeli:
W toku dalszej pracy podejmowana jest decyzja o zakresie projektu. Wskazując to, jakie “działania” ma wspierać lub przejąć na siebie aplikacja (to są właśnie przypadki użycia), wskazujemy jaka logika ma być przez tę aplikację realizowana i kiedy. Wskazanie zakresu projektu jest więc pierwszym etapem definiowania logiki aplikacji. Jeżeli do tego dodać wiedzę dziedzinową, np. to które elementy mogą być współdzielone a które nie, które powinni być całkowicie niezależne itp., powstanie tak zwany model dziedziny systemu (logika biznesowa i jej struktura czyli architektura aplikacji, a konkretnie części realizującej logikę biznesową).
Na zakończenie
Jak podejść do planów zakupu także gotowego oprogramowania? Czy warto je projektować? Oczywiście, że warto z prostego powodu: nie ma znaczenia to, czy przyszłe oprogramowanie będzie gotowe czy trzeba je będzie dopiero stworzyć. Ono ma realizować taką logikę jakiej oczekujemy. Owszem, jest możliwa decyzja: skoro na rynku nie ma poszukiwanego produktu a stworzenie dedykowanego jest zbyt kosztowne, to albo rezygnujemy z zakupu albo z określonej logiki wewnątrz organizacji. Jednak do podjęcia takiej decyzji musimy tę logikę znać i mieć udokumentowaną (no bo jakoś musimy ją pokazać oferentom). “Ale dostawcy oprogramowania zawsze oferują analizę wymagań”… To prawda … A ilu z nich powie, że nie mają Wam nic do zaoferowania? “Ale dedykowane oprogramowanie może zaprojektować tylko jego wykonawca”. To dlaczego firmy budowlane nie są dopuszczane do prac projektowych i architektonicznych?
Dlatego na diagramie powyżej, jako moment wyboru dostawcy oprogramowania, wskazano ten w którym mamy udokumentowany model logiki czyli PIM. To czy logika taka jest dostępna w jakimś produkcie na rynku czy nie, nie zmienia faktu, że i tak musi zostać ona opisana, bez czego taki wybór jest niemożliwy. Czym więc są (czym powinny być) wymagania na oprogramowanie? Niestety powinny być zwięzłym projektem a nie długą listą cech.
Jeden analityk projektant mający dobre wsparcie narzędziowe, jest w stanie wykonać analizę i projekt dla dowolnie dużej firmy, wystarczy, że potrafi tworzyć abstrakcje i zarządzać złożonością dokumentacji. Czy kilku analityków zrobi to nie gorzej i szybciej? Nie znam takiego przypadku…. bo im więcej osób prowadzi taką analizę tym więcej pracy wymaga koordynacja i praca nad spójnością całości.
Na zakończenie cytat z pewnej dyskusji:
I started a company called Nascent Blue that specializes in MDD for application development. We have actually had the opportunity to compare MDD to traditional development side-by-side on large projects. Our client set up ?the experiment? to collect the PM data for analysis. It was a large project with 5 teams. The results:
1. Our team was less than half the size of the other teams.
2. Our team produced more than twice the code of the other teams.
3. Our team achieved a 75% reduction in cost.
4. Our team achieved a 66% reduction in defect rate.
5. Our team was twice as fast (with half the size).
We have since gotten more efficient and more advanced, so I don?t know what the numbers are now.
(źr. Model driven productivity | LinkedIn).
