Miło mi poinformować, że moja publikacja naukowa (tu była zapowiedź) na temat syntezy wzorców architektonicznych i wzorców projektowych, systemów obiektowo-zorientowanych zatytułowana:
po długim procesie selekcji i recenzowania, została zakwalifikowana do publikacji i właśnie się ukazała jako jeden z rozdziałów książki:
Jeszcze milej mi poinformować, że – jako współautor – mogę Wam zaoferować kod promocyjny dający 40% zniżki na zakup: IGI40.
Poniżej informacje o książce i o wydawcy.
O książce
Ch. 3: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: Synthesis of MOF, MDA, PIM, MVC, and BCE Notations and Patterns (050719 – 041004) (J.Żeliński)
DescriptionIn today?s modernized environment, a growing number of software companies are changing their traditional engineering approaches in response to the rapid development of computing technologies. As these businesses adopt modern software engineering practices, they face various challenges including the integration of current methodologies and contemporary design models and the refactoring of existing systems using advanced approaches.Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities is a pivotal reference source that provides vital research on the development of modern software practices that impact maintenance, design, and developer productivity. While highlighting topics such as augmented reality, distributed computing, and big data processing, this publication explores the current infrastructure of software systems as well as future advancements. This book is ideally designed for software engineers, IT specialists, data scientists, business professionals, developers, researchers, students, and academicians seeking current research on contemporary software engineering methods. Source: Applications and Approaches to Object-Oriented Software Design: Emerging Research and Opportunities: 9781799821427: Computer Science & IT Books | IGI Global
O wydawcy
IGI Global is a leading international academic publisher committed to facilitating the discovery of pioneering research that enhances and expands the body of knowledge available to the research community. Working in close collaboration with expert researchers and professionals from leading institutions, including Massachusetts Institute of Technology (MIT), Harvard University, Stanford University, University of Cambridge, University of Oxford, Tsinghua University, and Australian National University, IGI Global disseminates quality content across 350+ topics in 11 core subject areas. Source: About IGI Global | IGI Global
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
W ostatnim artykule zwracałem uwagę między innymi na bardzo ważny element analizy i projektowania jakim jest abstrahowanie od detali, ponieważ:
…analityk musi abstrahować od wszelkich detali, bez tego projekt zostanie już na samym początku ?zabity? ich ilością. [1]
Nieco wcześniej (2013 r.) pisałem o tym, kiedy uzgadniać detale, które i gdzie one są:
Cała logika biznesowa jest wykonywana wewnątrz aplikacji (informacje o ewentualnych błędach pojawią się po zatwierdzeniu formularza), np. upust może być sprawdzony (albo naliczony) dopiero po skompletowaniu danych wymaganych do jego wyliczenia, czyli będzie to kilka różnych pól (najmniej dwa :)). Bywa, że do wyliczenia czegoś potrzebne będą dane nie wprowadzane do danej formatki faktury, np. saldo klienta. [2]
Tym razem kilka słów o tym jak skomplikować i zabić projekt już pierwszego dnia. Jednym z najbardziej ryzykownych sposobów rozpoczynania projektu jest rozpoczynanie od konsultacji z użytkownikiem w kwestii interfejsu użytkownika. Prowadzi to do sytuacji, w której jeszcze nie mamy żadnego pojęcia o logice biznesowej i architekturze aplikacji, a już deklarujemy to jak będzie się ona komunikowała z użytkownikiem (ciekawe na jakiej podstawie?).
Do napisania tego artykułu skłonił mnie ten wpis:
The role of design still puzzles many agile teams I work with. When should the design activities take place? Who should carry them out? How are design decisions best captured? This blog tries to answer the questions by discussing a user-centric, iterative, and collaborative design process for Scrum and Kanban teams. [3]
Autor pokazuje jak „walczy” ze złożonością na tym etapie, ja pragnę zasugerować by do tej złożoności na tym etapie po prostu nie dopuszczać. Powyższy diagram pokazuje z czym walczy analityk, który doprowadzi do zebrania wyrwanych z kontekstu (tak, nie ma modelu logiki więc dyskusje o GUI są oderwane od kontekstu) „wymagań” (historyjki użytkownika, lewa kolumna tablicy Story Area), których zamawiający może „naopowiadać” bardzo dużo.
A jak inaczej? Pomoże nam stosowanie wzorców architektonicznych. Są one od lat dostępne w większości frameworków (szkoda, że bardzo często developerzy je ignorują). Poniżej prosty, abstrakcyjny model klasycznego wzorca MVC.
W architekturze wydziela się komponenty (separowanie odpowiedzialności): odpowiedzialny za obsługę dialogu z użytkownikiem (View), odpowiedzialny za technologie, jakość, bezpieczeństwo, sterowanie itp. (Controler) oraz odpowiedzialny za (całą a nie tylko dane!) logikę biznesową (Model).
Zarządzanie złożonością polega tu na tym, by na początku analizy i projektowania abstrahować całkowicie od detali GUI! (a dokładnie od całej technologii czyli elementów View i Contoler). Kluczową odpowiedzialnością aplikacji jest realizacja określonej logiki biznesowej. Na tym etapie powinien powstać model przypadków użycia rozumiany jako prosty dialog pomiędzy użytkownikiem a aplikacją, tu celem jest uchwycenie kluczowych wymagań jakimi są wymagane usługi aplikacyjne realizowane przez aplikację oraz opracowanie wewnętrznej architektury – Modelu, która te usługi zrealizuje. Dopiero po przetestowaniu całej logiki biznesowej na modelach, warto się zabierać na komplikowanie projektu poprzez opracowanie detali GUI, sterowania, bezpieczeństwa itp.. Postępowanie takie umożliwia wzorzec architektoniczny MVVM opracowany ponad 10 lat temu. Wzorzec ten wprowadza dodatkowy komponent pomiędzy komponenty View i Model: View-Model, który realizuje logikę dialogu GUI-użytkownik. Dzięki temu możemy wydzielić etap pracy nad GUI, jako osobny w projekcie, który zrealizuje (później) tak zwany „UX designer”, a developer zamieni pierwotnie abstrakcyjny komponent View na implementacje „View-View Model”.
Bardzo dobry opis tego podejścia:
W przypadku warstwy prezentacji można wykorzystać m. in. następujące rozwiązania: MVC, MVP czy Model-View-ViewModel. Ze względu na mechanizm wiązań (binding), programistom WPF oraz Silverlight, polecany jest wzorzec MVVM ? jest to technologia umożliwiająca bardzo łatwą implementację wzorca. […] …po co utrudniać sobie zadanie poprzez wykorzystywanie MVVM, zamiast pisać aplikację w klasyczny sposób (za pomocą code-behind)? W końcu wdrożenie praktycznie każdego wzorca projektowego wymaga trochę większych początkowych nakładów pracy.
Podejście Code-Behind (autonomous view ? AV) ma poważną wadę ? nie gwarantuje elastyczności oraz testowalności. Podsumowując, wprowadzenie wzorca [MVVM, przypis autora] umożliwia:
niezależność logiki od sposobu wyświetlania danych,
niezależność kodu od technologii, w której wykonana jest warstwa prezentacji,
wykonywanie testów ? za pomocą MVVM czy MVP możliwe jest wykonanie testów zautomatyzowanych (np. jednostkowych),
łatwą zamianę widoków (brak sztywnych powiązań między widokiem a logiką).[4]
(Tak: stosowanie wzorców podnosi początkową pracochłonność ale zwraca się z nawiązką w dalszych cyklach życia projektu.) Strukturę i historię powstania tej architektury zainteresowani mogą poznać także tu:
Model View View Model (MVVM) In 2005, John Gossman, Architect at Microsoft, unveiled the Model-View-ViewModel (MVVM) pattern on his blog. MVVM is identical to Fowler?s Presentation Model, in that both patterns feature an abstraction of a View, which contains a View?s state and behavior. Fowler introduced Presentation Model as a means of creating a UI platform-independent abstraction of a View, whereas Gossman introduced MVVM as a standardized way to leverage core features of WPF and Silverlight to simplify the creation of user interfaces. MVVM is a specialization of the more general PM pattern, tailor-made for the WPF and Silverlight platforms to leverage core features of WPF such as data binding, commands , templates.
This diagram take from MSDN depicts MVVM Pattern in action.
[5]
Tak więc analizę i projektowanie warto zacząć od logiki i szkieletu architektury, a ta to przede wszystkim Model (dziedziny) systemu czyli kompletna logika biznesowa (utożsamianie modelu dziedziny z relacyjną bazą danych to poważny błąd i nieporozumienie). Po uporaniu się z tym etapem projektu ma sens opracowywanie detali komunikacji z użytkownikiem, bo dopiero teraz znamy wymagania i ograniczenia logiki biznesowej. Odkrywanie ich dopiero na etapie prototypowania to stanowczo za późno, bo generuje to ogromne koszty cyklicznego refaktoringu kodu (albo kod szybko staje się „bryłą błota”).
Bardzo często słyszę, że klient chce jak najszybciej coś zobaczyć. Rzecz w tym, że jeżeli się na to zgodzimy, powstaje i jest akceptowana masa tak zwanych „pobożnych życzeń”, a klient bardzo szybko się przywiązuje do tego co zobaczył na prezentacji (i nie chce odpuścić). W efekcie tworzy się spirala żądań, testów i poprawek, które szybko przekształcają „agile” w porażkę budżetu i harmonogramu. Praktyka pokazuje, że budżet zawsze ma limit, dlatego bardzo wiele takich projektów kończy albo w koszu na śmieci albo efekty stanowią tylko namiastkę tego co opisywała pierwotna wizja. Jeżeli zaś zaczniemy od jądra systemu a na koniec zostawimy sobie „makijaż” jakim jest GUI, szansa na sukces będzie znacznie większa. Problem polega na tym, że moda na „user-centric, iterative, and collaborative design” jest silna mimo tego, że jest przyczyną wielu porażek.
Tak więc odpowiedź na pytanie jak poradzić sobie z życzeniami biznesu, brzmi: nie dopuszczać do ich wyartykułowania :). Projektowanie i tworzenie samochodu rozpoczyna się od podwozia i napędu a nie od deski rozdzielczej…
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Tym razem o modelu, a konkretnie komponencie Model, w architekturze systemu. W poprzednim artykule pod koniec napisałem:
Czy musimy znać opis wszelkich zachowań systemu? Nie, i z reguły nie jesteśmy w stanie ich wszystkich opisać, zresztą nie ma takiej potrzeby. Jednak mechanizm (wiedza jak coś działa) pozwala nam wyjaśnić zaobserwowane zachowania oraz przewidzieć przyszłe (dokładnie tak jak teoria naukowa). Niewątpliwie młotek został stworzony do wbijania gwoździ i ten jego ?przypadek użycia? był przyczyną (wymaganie) jego skonstruowania, jednak wiedząc jak jest skonstruowany i znając prawa fizyki, jesteśmy w stanie przewidzieć praktycznie wszelkie inne skutki nawet nie obserwowane wcześniej, np. nie musimy usłyszeć od nikogo ?user story? by przewidzieć co się stanie gdy rzucimy młotkiem w szybę okna sąsiada. (Źródło: Czym jest a czym nie jest tak zwany model dziedziny czyli model obiektowy systemu | | Jarosław Żeliński IT-Consulting)
Istotą zrozumienia określonej rzeczywistości jest jej mechanizm działania. Dokładnie tak jak w przypadku przyrody i jej praw. Zrozumienie otaczającego świata to odkrycie i stworzenie jego – lub konkretnej jego części – modelu. Jest nim także każda organizacja.
Jak już wyżej wspomniano, specyfikowanie oprogramowania metodą „zbierania wymagań” od jego przyszłych użytkowników, przypomina próby opisania słonia przez grupę niewidomych jak w znanej anegdocie.
Tak zebrany i uporządkowany „materiał” to zlepek spekulacji, i nie ma znaczenia jak długo trwa to owo „zbieranie wymagań” ani jakich wyrafinowanych form zarządzania użyjemy. Herbata nie będzie słodsza od samego mieszania.
Czym jest wymaganie wobec systemu? Jest trywialne w swej definicji: od systemu wymagamy by zachowywał się tak jak chcemy. Jednak, jak już wyżej napisano, skoro nie ma sensu spisywać wszystkich znanych nam reakcji na bodźce, należy stworzyć model czyli opis mechanizmu jego działania.
Wzorzec MVC i projektowanie systemu
Podstawowym wzorcem architektonicznym w systemach o obiektowej architekturze, jest wzorzec MVC (Model, View, Controller). Architektura tego wzorca w ogólnej postaci ta ma taką oto postać:
Idea wzorca jest taka: cały system to trzy kluczowe komponenty:
View: to komponent odpowiedzialny za pośredniczenie w komunikacji pomiędzy źródłem bodźców jakim jest jego użytkownik (aktor) a resztą systemu.
Controller: to komponent sterujący systemem, odpowiada za wewnętrzne sterowanie i komunikację z otoczeniem.
Model: to ów kluczowy komponent systemu, zależnie od celu tworzenia systemu (tu aplikacji) albo jest symulatorem albo odwzorowaniem rzeczywistości.
Ideą tego wzorca jest separacja i hermetyzacja tych trzech dziedzinowych obszarów. Każdy z tych komponentów może być realizowany osobno albo po protu „kupiony”. Z reguły View i Controller to gotowe biblioteki (framework) wymagające głównie konfiguracji i opracowania określonych szablonów. Sercem systemu jest Model, komponent realizujący to do czego on służy: dziedzina systemu. Kupując np. gotowy program do księgowania, komponent ten jest gotowy. Oprogramowanie, od którego wymagamy usług niestandardowych, wymaga zaprojektowania tego komponentu. Na czym to polega?
Jeżeli aplikacja lub jej komponent, zastępuje jakąś rzeczywistość i automatyzuje jakieś prace, odwzorowuje ona określoną rzeczywistość. Jeżeli służy ona do prowadzenia skomplikowanych obliczeń, symuluje ona określoną rzeczywistość. Np. aplikacja wspierająca pracę biblioteki odwzorowuje papierowe kartoteki i ich treść, a nie raz także realizuje określone reguły biznesowe regulujące wypożyczaniem książek, wspierając tym samym pracę bibliotekarza. Aplikacja, która między innymi wykonuje złożone obliczenia, nie raz zawiera komponent będący symulatorem reprezentującym rzeczywistość będącą przedmiotem tych obliczeń, np. obliczającym czas realizacji projektu czy koszt procesu biznesowego. Typowymi symulatorami są gry komputerowe czy trenażery (symulatory kabin samolotów).
Po co to wszystko? W 2011 roku pisałem:
Figure 1: Computers, Models, and the Embedding World (Smith 1985)
Otóż nie da się czymś tak złożonym jak oprogramowanie (zakładam, że to nie trywialny system), zarządzać na poziomie detalicznych szczegółów. Jedynym sposobem jest upraszczanie i praca z abstrakcjami. Czym są owe abstrakcje? Modele! Już w 1984 roku zauważono, że: ?the idea that a physical theory or world picture is a model (generally of a mathematical nature) and a set of rules that connect the elements of the model to observations.” (Stephen Hawking and Leonard Mlodinow, called Model-Dependent Realism)? (za Model-Dependent Realism: Is This the Worldview of Software Engineering? ? THINK IN MODELS). (Źródło: Czynniki sukcesu w projektach programistycznych | | Jarosław Żeliński IT-Consulting)
Realizacją te idei jest właśnie architektura MVC i wydzielony komponent, jakim jest Model, którego rolą jest odwzorowanie określonej rzeczywistości. Ta określona rzeczywistość mająca swój kontekst to domena (dziedzina) systemu. Model opisujący jej zachowanie (symulator) to Model Dziedziny Systemu. Grafika, jaką widzimy obok powyższego cytatu, oddaje tę ideę. Po prawej stronie jest konkretna rzeczywistość (Real World), jej zrozumienie (określonej części) w postaci udokumentowanej to właśnie Model. Implementacja to system (tu COMPUTER) czyli aplikacja wraz ze swoim środowiskiem wykonawczym.
Na tle powyższego warto zwrócić uwagę na to, że nieprawdą jest:
to że Model to baza danych,
to że reguły biznesowe są w komponencie Controller a dane w komponencie Model.
Ale prawdą jest, że wymaganiem wobec oprogramowania powinno być to, by zachowywało się ono w pożądany sposób, i znacznie lepiej by wymaganiem był Model niż dziesiątki czy setki przykładowych zachowań systsemu.
Model wyrażony w notacji UML to struktura opisana diagramem klas, z klasami obiektów mających atrybuty i operacje, obiekty połączone związkami użycia… Szczegóły interfejsu użytkownika opracuje grafik UX-designer, zaś wszelkie techniczne kwestie (logowanie, bezpieczeństwo, integracja itp.) opracuje już developer.
A gdzie mityczna baza danych? Tam gdzie jej miejsce: zarządza danymi utrwalanymi w pamięci. Baza danych i systemy zarządzania danymi w architekturze obiektowej nie stanowią miejsca na logikę biznesową, standardowym wzorcem projektowym jest tu tu active records. Podstawową zaletą stosowanie tego wzorca jest separacja utrwalonych danych od aplikacji. To pozwala skupić całą logikę i jej zmienność w kodzie aplikacji i jego architekturze. Dzięki temu można spełnić zasadę Open Close principia bez refaktoringu bazy danych i migracji danych, co miało by miejsce gdyby była to jednolita relacyjna baza danych dla całej aplikacji. Zachowanie separacji i hermetyzacji obiektów do poziomu danych włącznie (jeżeli obiekty współdzielą dane w bazie danych niszczy to ich separację), uwalnia nas od problemu „jednolitego modelu danych”.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Niedawno w artykule o dość wyzywającym tytule 😉 Gdzie są te cholerne szczegóły pisałem o złożoności wymagań i tym, gdzie ta złożoność jest (mogła by być, powinna być dokumentowana, jak kto woli). Tam skupiłem się na takich szczegółach jak reguły biznesowe i złożone typy danych, czyli tym co potocznie (i nie do końca słusznie) nazywa się „walidacjami” ([[walidacja]]).
Drugim elementem „niosącym” szczegóły jest dialog użytkownika z aplikacją czyli „ekrany”. Tu pojawia się kolejna porcja wymagań, nie raz bardzo szczegółowych, zaciemniających nie raz główny sens tworzenia danego oprogramowania: scenariusze pracy z ekranem (formatką ekranową itp.).
Jak już nie raz pisałem, ogólna zasadą (dobrą praktyką) w inżynierii jest abstrahowanie oraz zarządzanie poziomem szczegółowości każdego etapu pracy na projektem. Operowanie pojęciami (terminami) zamiast ich definicjami, to abstrahowanie od szczegółów czyli ich hermetyzacja, np. „Kontrahent” to „nazwa podmiotu, jego NIP, adres”.
Wymagania wobec aplikacji związane z interakcją aktor-system, ich definiowanie i projektowanie realizacji, nie należą do łatwych etapów analizy i projektu, są nie raz bardzo szczegółowe. To powód dla którego warto je także „hermetyzować”. Jak? Pomagają w tym dwie rzeczy: wyodrębnienie projektowania (dokumentowania) szczegółów interakcji jako etap projektowania nazywany [[User Experience]] (dalej UX) oraz użycie wzorca projektowego MVVM-MVC.
Najpierw jednak wzorce, bo te dadzą nam kontekst i granice hermetyzacji. Wzorzec MVVM i korzyści płynące z jego użycia, przystępnie opisano na stronie MSDN:
Przed omówieniem wzorca, warto zastanowić się, po co utrudniać sobie zadanie poprzez wykorzystywanie MVVM, zamiast pisać aplikację w klasyczny sposób (za pomocą code-behind)? W końcu wdrożenie praktycznie każdego wzorca projektowego wymaga trochę większych początkowych nakładów pracy.
Podejście Code-Behind (autonomous view ? AV) ma poważną wadę ? nie gwarantuje elastyczności oraz testowalności. Podsumowując, wprowadzenie wzorca umożliwia:
niezależność logiki od sposobu wyświetlania danych,
niezależność kodu od technologii, w której wykonana jest warstwa prezentacji,
wykonywanie testów ? za pomocą MVVM czy MVP możliwe jest wykonanie testów zautomatyzowanych (np. jednostkowych),
łatwą zamianę widoków (brak sztywnych powiązań między widokiem a logiką).
Z perspektywy analizy i projektowania ([[OOAD]]) najistotniejsze są pierwsze dwa punkty, bo umożliwiają hermetyzację (oddzielenie) logiki biznesowej i projektu opisującego interakcje aktor-system czyli UX. Punkt czwarty daje spełnienie jednej z zasad SOLID czyli „łatwość rozszerzenia bez potrzeby modyfikacji”. Ta ostatnia cecha to np. dodawanie nowych interfejsów użytkownika do kolejnych nowych urządzeń (smartfon, tablet, dedykowane urządzenia i wyświetlacze), bez potrzeby ingerowania w kod obsługujący już oprogramowane urządzenia.
Jak to wygląda z perspektywy architektury aplikacji i jej projektanta? Poniżej model:
Co tu mamy? Mamy MVVM i MVC na jednym diagramie. MVVM polega na wstawieniu pomiędzy widok (View) a Model dodatkowe komponentu, który stanowi wersję logiki biznesowej zawierającą ograniczenia „wyświetlacza” i dedykowane (specyfiaczne) tylko dla niego zachowania (to także pozwala unikania bardzo złej praktyki jaką jest umieszczanie logiki biznesowej w komponencie View). Innymi słowy, jeżeli jakieś zachowania systemu są specyficzne dla konkretnego typu wyświetlacza (ale może to być specyfika aktora o czym dalej), logikę tę hermetyzujemy w komponencie ViewModel.
Mając taką abstrakcję aplikacji jak powyżej, łatwo będzie osobno opisać ją przypadkami użycia, uznając je za „usługi systemu (te świadczy komponent Model) oraz osobno szczegółowymi scenariuszami UX zamkniętymi w parze komponentów View-ViewModel. Oba te elementy projektu – UX i Use Case, są więc „ładnie” odseparowane, nie wpływają na siebie nawzajem i pozwalają na łatwą rozbudowę całego systemu, niewymagającą modyfikowania już powstałego kodu (i dokumentacji).
Nawiąże jeszcze do „specyfiki aktora”. Bardzo często w systemach internetowych, mamy potrzebę separacji użytkowników „z poza firmy” (np. klienci sklepu internetowego, interfejsy samoobsługi dla klientów serwisu itp.). Wiąże się to nie raz z bardzo złożonymi zasadami kontroli dostępu do elementów modelu 9czyli dość głęboko w systemie). Potrafi to bardzo skomplikować cały projekt komponentu Model, a nie raz potrzeby jego istotnej przebudowy. Można tego uniknąć, hermetyzując ten obszar. Bardzo często osoba (użytkownik, aktor systemu) z zewnątrz ma bardzo ograniczone możliwości korzystania z logiki całego systemu. Łatwiej jest zaprojektować dedykowany, relatywnie prosty komponent ViewModel i połączyć go z Modelem, niż modyfikować Model Dziedziny systemu by obsługiwał, nowe, nie raz bardzo wyrafinowane, ograniczenia dostępu.
Tak więc przypadkami użycia opisujemy abstrakcję jaką jest [[Model Dziedziny Systemu]]. Są one wtedy proste, zawierają scenariusz, który w skrócie ma postać: aktor inicjuje usługę, system prezentuje formularz do wypełnienia, aktor wypełnia go i potwierdza, system potwierdza odebranie danych i pokazuje wynik swojej pracy (lub komunikaty o błędach). Tu skupiamy się na opisie tego jakie usługi są wymagane od systemu. Kolejny etap to „komplikowanie” każdego scenariusza w postaci projektowania, dla każdego przypadku użycia, który tego wymaga, różnego rodzaju wizardów lub wprowadzamy ograniczenia związane z uprawnieniami użytkowników. Ten etap to praca projektantów UX i grafików, specjalistów od ergonomii itp.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Poza wymaganiami funkcjonalnymi, podajemy tak zwane wymagania poza-funkcjonalne. Mają one, między innymi, ważna rolę do spełnienia. Jaką?
Najpierw cytat:
Technologia klient/serwer jest zależna od komunikacji pomiędzy poszczególnymi komputerami. Sieci LAN i WAN stają się znacznym wydatkiem oraz wymagają dużych nakładów pracy w związku z zarządzaniem nimi. Co więcej, zmiana wersji oprogramowania na wielu komputerach, co szczególnie widoczne jest w przypadku przetwarzania rozproszonego, staje się istotnym problemem. Wielokrotnie działy IT zastanawiają się nad przejściem na strukturę Internet/Intranet w celu rozwiązania tego problemu. (Wstęp do ERP – technologia u podwalin przedsiębiorstwa).
Pomijając „prostotę” tego tłumaczenia, chcę zwrócić uwagę na ważną rzecz: bardzo duże znacznie ma architektura systemu, niestety wielu producentów ukrywa zastosowaną technologię i architekturę. Jedną z przyczyn jest to, że są to nie raz technologie rodem z lat 90-tych a bywa, że nawet wcześniejsze. Jedną z takich „staroci” jest architektura client-server (tak zwany gruby klient). Innym typem „dinozaura” technologicznego jest tworzenie oprogramowania, w którym logika biznesowa jest w jakiejś części w procedurach wbudowanych bazy danych (w rozumieniu konkretnego tak zwanego motora SQL bazy).
Jaki mamy wybór?
Zanim powiemy sobie o wyborze, kilka słów na temat klasycznej trójwarstwowej architektury jako fundamencie dalszych rozważań. Struktura taka wygląda następująco:
Mamy tu trzy warstwy: Warstwa prezentacji, czyli komponent odpowiedzialny za wyświetlanie informacji na ekranie użytkownikowi i ich przyjmowanie. Warstwa logiki aplikacji podzielona na Logikę dziedzinową (część specyficzna dla dziedziny problemu, tu są np. faktury, sposób naliczania podatków, rabatów itp. ta część realizuje wymagania funkcjonalne) oraz Logikę poza-dziedzinową (wydajność, niezawodność, bezpieczeństwo, integracja z innymi aplikacjami itp.). Najniżej jest warstwa Utrwalania, coraz częściej w paradygmacie obiektowym pomijana na tym poziomie abstrakcji (utożsamiana z realizacją wymagań poza-funkcjonalnych związanych z zachowywaniem informacji).
Praca w sieci wielu użytkowników to wielodostęp (wiele stacji roboczych korzysta z jednego serwera):
Gruby klient
Gruby klient to architektura w której każdy użytkownik ma na swoim lokalnym komputerze nie tylko warstwę prezentacji ale także całą logikę aplikacji. Każde takie stanowisko komunikuje się z serwerem danych:
Do powyższej architektury odnoszą się główne uwagi o wadach z cytatu na początku. Cechy architektury po lewej stronie: kosztowne stacje robocze (muszą, każda, udźwignąć całe oprogramowanie), kosztowna administracja (niezgodność wersji na stacjach roboczych może prowadzić do krachu systemu), kosztowne modyfikacje (także z uwagi na wymaganą zgodność oprogramowania na stacjach roboczych), bardzo duże wymagania na pasmo i niezawodność sieci (duże transfery danych pomiędzy stacjami roboczymi i serwerem, zerwanie połączenia powoduje blokady dostępu do danych) powodują, że praca w sieci rozległej terytorialnie może być wręcz niemożliwa (wtedy wymaga powielania instalacji w każdej lokalizacji i synchronizacji danych, kolejne niemałe koszty). Pewną odmianą jest wariant po prawej stronie, gdzie część logiki aplikacji jest umieszczona na serwerze danych (konkretnie bazy danych), powoduje to nieco zmniejszony ruch w sieci ale dodatkowo komplikuje wszelkie rozszerzenia funkcjonalności i upgrade oraz praktycznie uniemożliwia zmianę (wybór) producenta bazy danych. Duże koszty tej architektury dodatkowo potęguje wymóg wykupienia licencji na bazę danych dla każdego użytkownika.
W większości przypadków tej architektury, logika biznesowa (dziedzinowa) nie jest separowana od reszty, w efekcie dodatkowo wszelkie prace dostosowawcze są bardzo kosztowne (ingerencja w całą aplikację).
Architektura internetowa – cienki klient
Taką nazwę od pewnego czasu nadaje się architekturze opartej na dostępie do aplikacji z pomocą przeglądarki WWW:
Powyższa architektura praktycznie nie ma żadnej wady poprzedniego rozwiązania. Dodatkowo baza danych licencjonowana jest z reguły na aplikację a nie na każdego użytkownika (czyli jest taniej). Stosując tak zwane metody i architektoniczne wzorce obiektowe (najpopularniejszy to MVC: Model, View, Controller) separuje się komponent logiki biznesowej od logiki sterowania aplikacją. W efekcie dostosowanie aplikacji nie polega na kosztownym modyfikowaniu logiki aplikacji, dodaje się i integruje niezależny komponent Logiki biznesowej, co dodatkowo pozwala zachować separację praw autorskich do kodu logiki biznesowej (know-how firmy). Korzyścią takiej architektury jest także możliwość łatwego dodawania możliwości dostępu z innych niż komputer PC, urządzeń (smartfony, tablety, itp.) gdyż wymaga to wyłącznie nowej warstwy prezentacji, logia pozostaje spójna na serwerze.
Kolejna korzyść to łatwa integracja z innymi aplikacjami. Oprogramowanie w tej architekturze „ukrywa” dane, dostęp do nich jest wyłącznie przez Logikę aplikacji za pośrednictwem tak zwanych API (interfejs programistyczny) metodami znanymi w sieci WWW, unikamy kosztownych i ryzykownych łączy bezpośrednich do baz danych (niska pracochłonność integracji, bardzo wysokie koszty utrzymania i rozwoju).
W efekcie rekomendowana architektura mogła by wyglądać tak:
Zalety: niskie koszty utrzymania systemu i infrastruktury, separacja logiki biznesowej (dziedzinowej) dedykowanej od „kupionej”, łatwość i niski koszt upgrade, praca z pomocą przeglądarki WWW, łatwa integracja z innymi aplikacjami, łatwość pracy w sieci lokalnej i rozległej (w tym łatwy zdalny dostęp z dowolnego cudzego komputera). To tylko główne korzyści.
Wymagania pozafunkcjonalne
Jak wspomniałem, wielu dostawców oprogramowania jak Rejtan, broni się przed ujawnianiem architektury, swoich produktów. Głównym powodem jest zapobieganie przedwczesnego wyjawienia opisanych wyżej wad systemów z grubym klientem (znacznie rzadziej spektakularny pomysł, w końcu mamy jednak jakieś standardy). Przypadki, w których zakup systemu był relatywnie niski ale koszt utrzymania, rozwoju i dostosowania nie raz wręcz ogromny, to z reguły właśnie zakup systemu w tej kosztownej architekturze.
Jak starać się tego unikać? Na etapie definiowania wymagań poza-funkcjonalnych, żądać takich cech jak opisane powyżej czyli własnie: dostęp do całości przez przeglądarkę WWW, niskie wymagania na łącza przy zdalnej pracy i pracy w sieci rozproszonej terytorialnie, oddzielenie komponentu z własną dedykowaną logiką biznesową.
[2015]
Polecam pogadanke M.Fowlera na temat roli architektury:
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
oprogramowanie reprezentuje narzędzie pracy, więc projekt tego oprogramowania raczej powinien zawierać pojęcie (klasę) Kartoteka Pracowników a nie Pracownicy. (Dlaczego nie podoba mi się klasa Pracownik?).
To stały temat wielu dyskusji z programistami. Ostatnio, po pewnym szkoleniu, w ramach wsparcia po szkoleniu jakie zawsze świadczę, znowu padło pytanie:
Czy zdarza Ci się robić analizy/projekty, gdzie byty występują pod nazwami innymi niż używanymi potocznie przez Biznes.
Z tym – używane pojęcia – jest regularnie duży problem, dlatego od pewnego czasu ortodoksyjnie stosuję budowanie „przestrzeni pojęciowej” dla projektu ([[Semantics of Business Vocabulary and Business Rules]]). Buduję słownik pojęć, listę reguł biznesowych (to nie to samo co reguły decyzyjne) oraz tak zwany diagram faktów, który służy do testowania (i dokumentowania słownika) – upewnienia się, że pojęcia nie kolidują ze sobą a ich definicje nie nakładają się na siebie oraz, że lista jest dziedzinowo kompletna. Po co to? Właśnie po to,
by żadne zdefiniowane słowo nie miało w projekcie (w wymaganiach, w kodzie) więcej niż jednego znaczenia i by znaczenie każdego zefiniowanego pojęcia nie budziło żadnych wątpliwości
Jedna uwaga na początek: jeżeli „byty” (klasy) w kodzie (projekcie) oprogramowania występują pod innymi nazwami niż w rzeczywistości, to jest to absolutna porażka, bo programista zupełnie traci kontakt z klientem i (lub) dokumentacją opisująca wymagania. Jeżeli już koniecznie programista musi ulżyć sobie w ambicji używania wyłącznie j.angielskiego w kodzie, powinien ten kod być bogato komentowany, by nie było wątpliwości jakie znacznie niesie np. nazwa klasy czy atrybutu (tym bardziej, że np. słowo name to nie tylko nazwisko.….)
Słownik pojęć (często występuje w dokumentach jako czysto polskie słowo glossariusz ;)) bywa często przedmiotem burzliwych negocjacji, bo nie raz (a w zasadzie zawsze ;)) biznes stosuje slang, w którym to samo słowo ma różne znaczenie, zależnie od kontekstu użycia. Może to mieć sens w języku mówionym gdy pełna treść wypowiedzi daje ten kontekst, ale na poziomie analizy i projektu każde pojęcie musi mieć jedno unikalne znacznie mimo braku kontekstu (tym bardziej, że np. nazwy klas nie są elementami pełnych zdań ani opowieści :)).
Pamiętam projekt, w którym wiceprezes pewnej firmy na każde działanie takie jak nowa umowa, nowy projekt, nowy klient, używał słowa „temat”, nikt nie miał odwagi powiedzieć mu, że nie raz nie rozumie o czym on mówi … Ja – obcy – się odważyłem 🙂 i uporządkowaliśmy to, był opór ;). Pamiętam, że dyplomatycznie poprosiłem go by zbudował hierarchię „tematów” nazywając każdy element tej hierarchii jednym lub dwoma słowami słowami i pomogło :), Słownik pojęć to negocjacje 🙂
Evans (DDD ) zapoczątkował bardzo ciekawe podejście, ono się rozwija. Co ciekawe Evans nie wymyślił idei a system wzorców DDD. Wspólny język to dwa elementy: używanie biznesowych nazw (bez skrótów) na elementy rzeczywiste i klasy w systemie, ale także używanie np. pojęcia „fabryka” przez biznes i przez developera jako „kontener” na pewien rodzaj kompetencji (wiedza o tym jak powstają pewne obiekty biznesowe).
Elementy wzorca DDD to nie tylko bloki kodu, to także elementy (klasyfikatory) wiedzy o biznesie. Faktura VAT to agregat – struktura informacji, to tylko wiedza o tym co ten dokument zawiera, ale FabrykaFaktur to odrębna wiedza o tym jak ten dokument jest tworzony. Należy świadomie udokumentować oba byty: dokument i recepta jego tworzenia. Dlaczego osobno? Bo po pierwsze wystawione faktury żyją własnym, życiem i obciążanie każdej z nich (np. tysiąc faktur miesięcznie) całą wiedza jak powstała nie ma większego sensu. Po drugie zmiana przepisów nie powinna się odbić na dokumentach już wystawionych ani dociążyć nowo powstających.
Biznes także musi zrozumieć, że ma dwa różne elementy opisu swoich działań: praca z dokumentami i tworzenie dokumentów. Jednak uznanie tego faktu to jedno, nie wierzę w to, że biznes się tego nauczy, bo nie nauczył się formalnego opisu lub modelowania procesów podczas wdrożeń ISO, jednak uważam, że biznes nie ma takiej potrzeby. Moim zdaniem od dobrego analityka nie ma ucieczki, to inna kompetencja. Nie ma ucieczki od projektantów mody mimo istnienia kobiet chcących mieć ładne sukienki i bardzo dobrych krawców. Nikt tu nikogo nie zastąpi.
Czy Model dziedziny ma stan?
(to część bardziej techniczna)
W kwestii czegoś takiego jak Stan Modelu w MVC (czy model biznesowy ma stan?) jestem ostrożny z używaniem pojęcia „stan”, popatrzmy na gry komputerowe… Czym jest stan? Stan na pewien moment w czasie (snapshot) czy stan „biznesowy” trwający minuty, godziny a nie raz dłużej? Model to system: zespół elementów współdziałających. Z perspektywy biznesu, reaguje on na akcje (stabilny ekran oczekiwania na OK, to permanentny maszynowy przebieg sprawdzania stanu przycisków). Osobiście traktuję klasy Modelu jako samodzielne żyjące byty, konstrukcja metod musi zagwarantować brak błędów i radzić sobie z tym co „stałe” dla użytkownika i „zmienne” dla systemu (zegar bez sekundnika jest z perspektywy minut martwym przedmiotem a mimo to „chodzi”).
Podejście do MVC, które praktykuję: Model powinien realizować 100% funkcjonalności i dać się testować bez warstwy V i C. Konkretnym stanem raczej charakteryzuje się konkretny obiekt a nie cały system. Cały system można zapewne opisać maszyną stanową ale po co, skoro są ich niezliczone ilości? Model żyje jak mrowisko, wystarczy zrozumieć mrówki, mrowisko to skutek na który za bardzo nie mamy wpływu.
Model DDD „analityczny” to metamodel implementacji, Evans traktuje go jako „bloki kodu” zrozumiałe przez biznes, idąc dalej: analityk traktuje DDD jako wiedzę o biznesie w postaci zrozumiałej przez developera. Obie strony uznają, że ta struktura jest wzajemną „umową”. Jestem zwolennikiem takiego podejścia do DDD :), Evans się z tym w moich oczach nie kłoci, on w zasadzie nie pisał o analizie biznesowej :). Wielu programistów, autorów doskonałych książek, zakłada, że „analizę wymagań ma poprawnie wykonaną”, co by to nie miało znaczyć :), ale to ogromne uproszczenie bo tu – błędy – tkwi większość ryzyk projektu.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.