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
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)
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.
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:
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).
ang. Model Driven Architecture (architektura zorientowana na modele), architektura oparta na otwartych standardach OMG (Object Management Group), pozwala na odseparowanie w analizie i projektowaniu logiki biznesowej, logiki aplikacji i jej implementacji (źr. www.omg.org/mda).
MDA definiuje trzy typy modeli: CIM, PIM, PSM (patrz pozostałe definicje w słowniku). Model CIM (biznesowy) to niezależny od technologii model opisujący cele biznesowe (BMM), procesy biznesowe (BPMN) oraz logikę tych procesów i wspólny słownik (SBVR). Model ten powinien także zawierać struktury danych (dokumentów, tu UML). Model PIM (UML) to model opisujący wewnętrzną architekturę i logikę planowanej do wdrożenia aplikacji (oprogramowania). Zakres tego wdrożenia określa sie z użyciem diagramu przypadków użycia (nie on elementem ani CIM ani PIM, to łącznik). Model PSM to projekt wykonania oprogramowania w określonym środowisku developerskim. Tu praktycznie powstaje jedynie model wdrożenia (UML) i dokumentacja kodu w formie wybranej przez wykonawcę. Poniżej diagram obrazujący związki miedzy tymi modelami.
Struktura modeli w MDA. Po lewej stronie typowy proces MDA, po prawej próba użycia modeli wykonywalnych BPMN (BPEL4WS) w miejsce PIM, ścieżka ta jednak nie przyjęła się.
Kolejna godna polecenia książka na rynku. Nie miałem czasu by wcześniej ją opisać ale w końcu udało się. Ale od początku, wrócimy do niej.
To co najczęściej wzbudza brak zaufania to teza, że można przeprowadzić analizę i projektowanie oprogramowania „na papierze”. Programiści w większości uważają, że to nie możliwe (rok temu na stronach tego bloga burzliwa dyskusja z jednym z nich…). W większości przypadków podczas spotkań (konferencje, projekty itp.) z zespołami programistów słyszę: „czytamy wymagania, kodujemy od razu i tworzymy kolejne wersje aplikacji; inaczej się nie da”. W przypadku szkoleń, ostatniego dnia warsztatów najczęściej słyszę: „ooo, w ciągu jednego dnia [teraz] powstał kompletny projekt dziedziny systemu [chodziło o komponent], przetestowany i oczyszczony z wątpliwości, braku logiki i niespójności, do tego łatwy w dalszym rozbudowywaniu; to co zrobiliśmy teraz na diagramach UML w ciągu dnia, jako zespół tradycyjną metodą robilibyśmy co najmniej tydzień, biorąc pod uwagę kodowanie każdego pomysłu by go dać użytkownikowi do testów”. W zasadzie taki proces analizy i projektowania jest znany od lat jako Model Driven Architecture (MDA):
W czym problem? Nauczyć się pracować na modelach (abstrakcje systemu) a nie od razu na kodzie (a raczej poprzedzić kodowanie analizą i projektowaniem), nauczyć się wzorców projektowych i przede wszystkim obiektowego myślenia (paradygmatu) czyli analizy i projektowania. Wykonanie – implementacja na końcu a nie na początku (podobnie jak baza danych: w metodach obiektowych projektujemy utrwalanie na końcu!). Po drugie, niestety, nie raz słyszałem o dostawców: „nie mamy interesu w tym by projekt trwał krótko”, to jednak tylko argument za tym by nie zlecać im projektowania a tylko realizację.
MDA to trzy kluczowe etapy: CIM, PIM i PSM (szczegółowo opisałem w artykule o analizie). Interesuje mnie tu etap CIM (Computation Independent Model) i PIM (Platform Independent Model). Pierwszy to analiza biznesowa, nie ma ona nic wspólnego z oprogramowaniem, jej celem jest zrozumienie i udokumentowanie tego co robią przyszli użytkownicy systemu oraz wskazanie zakresu projektu dostarczenia oprogramowania. Drugi to PIM czyli opracowanie modelu logiki systemu bez względu na to w jakiej technologii powstanie, tu milczącym założeniem jest, że będzie to technologia obiektowa jednak język programowania może być dowolny.
Dużą zaletą tego podejścia jest to, że opracowanie modelu PIM jako Opisu Przedmiotu Zamówienia (OPZ) jest zgodne z PZP (Prawo Zamówień Publicznych) bo nie determinuje implementacji ale dokładnie opisuje oczekiwania. Uważam, że jest to najlepszy sposób tworzenia OPZ, bo nie pozostawia dowolności w kwestii funkcjonalności rozwiązania. Jaki mamy tu problem? Należy oddzielić projektowanie od realizacji czyli mamy dwa etapy projektu zamiast jednego, dwóch wykonawców (analiza i projektowanie oraz realizacja). Wady? Nie, korzyści bo wykonawca i tak musi jakiś projekt opracować, po drugie wycena na bazie projektu jest daleko mniej ryzykowna niż „wycena na bazie koncepcji”, zresztą skutki wszyscy obserwujemy na rynku. Ale wracamy do tematu :).
Proces od analizy do projektu
Dwa pierwsze (CIM i PIM) to pierwsze etapy procesu powstawania oprogramowania: Analiza Biznesowa i jej produkt oraz projektowanie rozwiązania i jego produkt. Między nimi ma miejsce określenie zakresu, którego produktem jest model przypadków użycia (od 2015 roku w UML 2.5.x ten diagram jest modelem uzupełniającym)
Analiza biznesowa
Zgodnie z zaleceniami opracowujemy model CIM czyli tworzymy model tego „jak działa biznes”. Produktem tego etapu są modele procesów biznesowych (raczej [[BPMN]] niż [[UML]]). Muszą się one jednak cechować ustalonym poziomem abstrakcji (nie powinny być zbyt szczegółowe) i muszą uwzględniać rozdział kompetencji pracowników (ich nie komputeryzujemy) od ich specyficznych dla danej organizacji i procesu (te będą wspierane przez nowe oprogramowanie). Dobrą praktyką jest poprzedzanie tego etapu (uzupełnienie go) o analizę i model architektury korporacyjnej. To jest ostatni gwizdek na wprowadzanie ewentualnych ulepszeń zarządzania (reinżynieria procesów) w organizacji. Kolejny etap to
Opracowanie modelu przypadków użycia
Przypadki użycia, usługi systemu dla użytkowników, to celowe interakcje użytkownika z systemem. Ich cechą powinna być kompletność, bo przypadek użycia to realizacja konkretnego celu biznesowego przez użytkownika. Poprawnie opracowany taki model pozwala mapować czynności z modelu procesów wprost na przypadki użycia (ale nie koniecznie jeden do jednego, przypadków użycia może być mniej, bo ta sama usługa systemu może posłużyć do realizacji kilku celów biznesowych, np. utworzenia danych jak i ich podglądu czy korekty, przykładem mogą być tak zwane [[CRUD]]«y) (kliknij tu by zobaczyć to na przykładzie narzędzia jakiego używam).
Każda czynność kandydująca na przypadek użycia powinna być opisana scenariuszem jej realizacji opisującym jak planujemy tę usługę zrealizować. Jest to tak zwany dialog użytkownik-system. Model przypadków użycia to także definicja zakresu projektu programistycznego (robimy to i tylko to).
Opracowanie modelu dziedziny
Specyfikacja usług systemu (przypadki użycia) to tak zwane wymagania funkcjonalne. Jest to stanowczo za mało by cokolwiek (w szczególności oprogramowanie) mogło powstać. Problem w tym, że samo stwierdzenie „system ma wciągać śmieci” nijak się nie ma do konstrukcji urządzenia jakim jest odkurzacz. Wymaganie pozafunkcjonalne, że „ma ich wciągać co najmniej 90%” także nic nie mówi o tym co na prawdę ma zostać wytworzone. Brakuje PROJEKTU.
Takim projektem jest model dziedziny, jednak nie jest to diagram klas na którym pokażemy, że np. istnieje związek logiczny brudnego dywanu z odkurzaczem! bo to jest tylko model pojęciowy (słownik pojęć). Model dziedziny systemu to model dziedzinowej logiki jaką należy odwzorować w oprogramowaniu. Owszem, jest to także Diagram klas UML, ale zupełnie inny niż tak zwany model konceptualny, który po prostu jest tylko słownikiem (i często jest mylony z modelem danych!).
Model dziedziny systemu to sedno analizy obiektowej. To model całej logiki biznesowej aplikacji: klasy, ich operacje i atrybuty. Nie powinien to być na pewno tak zwany [[anemiczny model dziedziny]] a niestety takie właśnie są one w większości projektów jakie widuję.
Na tym etapie, modelowanie dziedziny systemu, powstają „suche” klasy, bez metod i atrybutów (tak, bez atrybutów!). W projektach złożonych systemów, powstanie modelu dziedzinowego powinno być poprzedzone powstaniem modelu komponentów (także stosowny diagram UML), który jest pośrednią warstwą abstrakcji w takich projektach. W takim przypadku początkowo operujemy praktycznie tylko na klasach abstrakcyjnych i ich interfejsach (są to interfejsy tych komponentów).
Projektowanie realizacji czyli testowanie modelu dziedziny
Mając model dziedziny, czyli listę specjalizowanych „wykonawców” konkretnych prac, możemy przystąpić do testów scenariuszy przypadków użycia. Takim testem jest próba zrealizowania scenariusza przypadku użycia z pomocą obiektów modelu dziedziny. Na tym etapie powstaje diagram sekwencji (lub sterowania interakcją, przepływu interakcji) dla każdego przypadku użycia. Dobrą praktyką jest stosowanie tu diagramów przepływu interakcji. Służą one do modelowanie nietrywialnych przypadków użycia, przepływu scenariuszy alternatywnych, ekranów itp.
W trakcie tworzenia diagramu sekwencji projektowane są operacje klas (metody to ich realizacje). Diagram sekwencji opisuje dialog pomiędzy obiektami prowadzący do zrealizowania zadania, jakim jest cel przypadku użycia (jego stan końcowy). Dialog taki to nic innego jak wywołania operacji obiektów przez inne obiekty (lub własnych). Po opracowaniu diagramu sekwencji obiekty, które brały w niej udział „wzbogacą” się w projekcie o swoje operacje. Na tym etapie może się okazać, że pewne obiekty zmieniają swoje stany. Dla ich klas projektujemy diagramy maszyny stanowej. Jeżeli okaże się, że jakiś obiekt wykonuje nietrywialne zadania (obliczeniowe, złożony proces itp.), jego operację, która za to odpowiada, dokumentujemy z pomocą np. diagramu czynności – taki algorytm to Metoda danej Operacji. Za każdym razem sprawdzamy zgodność z oczekiwaniami użytkownika i uzupełniamy klasy o niezbędne atrybuty, w szczególności, jeżeli reprezentują one dokumenty czy formularze.
Projekt wykonany
Po wykonaniu powyższego, otrzymamy kompletny model aplikacji w notacji UML. Będzie to właśnie model PIM. Wszelkie niejasności powinny zostać wyjaśnione. Pozostaje realizacja, model PSM, czyli opakowanie projektu „technikaliami” (w tym realizacja wymagań pozafunkcjonalych) czyli tym co dają nam np. frameworki MVC i podobne. Oczywiście nie jest to „trywialny problem”, ale w takim projekcie developer rozwiązuje problemy jakości systemu a nie logiki biznesowej systemu (podobnie jak inżynier budowlany, który ma postawić mocny i bezpieczny dom, bo jego funkcjonalność to problem mieszkańca i zadanie projektanta architekta).
Poniżej produkty takiej analizy i projektowania w postaci diagramów (modeli), pierwszy to BPMN, pozostałe UML:
Larman w swojej książce opisuje niemalże identyczne podejście (tabela poniżej). Kluczową różnicą jest jednak źródło informacji pierwotnej. U Larman’a jest to model przypadków użycia i ich scenariusze. W porównaniu z modelem biznesowym, podlegającym testowaniu czy walidacji, całe ryzyko projektu spoczywa na jakości modelu przypadków użycia. Jeżeli powstały one jako efekt np. burzy mózgów, ankietowania pracowników zamawiającego czy tak zwanych sesji JAD ([[Joint Application Development]]), jest bardzo prawdopodobne, że całe ryzyko złej jakości takiego modelu (a jest ono bardzo duże jak pokazuje praktyka) zostanie przeniesione na projekt.
To jest właśnie problem nazywany „użytkownik nie wie czego chce”. Po to się robi analizy biznesowe by w końcu wiedział. Nie zmienia to faktu, że książkę Larman’a gorąco polecam każdemu projektantowi i programiście z ambicjami na metody obiektowe i wzorce projektowe.
Larman’s UML Process
Use Cases
Define user interaction with the system.
Underline nouns to identify concepts in the problem domain.
Conceptual Model
Use the underlined nouns from the use cases to create the concepts in the conceptual model.
Some of the nouns, if they identify simple data types, are used to create attributes of these concepts.
Create associations between the concepts.
System Sequence Diagram
Create system sequence diagrams for each use case scenario.
Each sequence event in the diagram corresponds to a user interaction with the system specified by the expanded use case.
System Contracts
Specify post-conditions for each system event in the system sequence diagrams.
Use the conceptual model to identify objects created, associations formed, and attributes modified.
Collaboration Diagram
Create a collaboration (or sequence) diagram for each system event in the system sequence diagrams.
Assign responsibilities to classes in the conceptual model to fulfill the post-conditions in the contracts.
Use associations from the conceptual model in conjunction with patterns (Expert, Creator) to assign responsibilities.
Class Diagram
Add methods and additional attributes which were discovered in the collaboration diagrams to the classes in the conceptual model.
Code
Create classes with their names, attributes and method signatures taken from the class diagram.
For each method on a class, use the collaboration diagrams to find the sequence of messages generated when the method is called and create at least one line of code for each message.
You can create several different views of the users» requirements. Each view provides a particular type of information. When you create these views, it is best to move frequently from one to another. You can start from any view.
Ronald Ross, współautor standardu modelowania reguł biznesowych i biznesowego słownika pojęć napisał niedawno na swoim profilu LinkedIn:
„People love stories. Are user stories helpful in engineering business solutions? Absolutely. Are you done with requirements and solution engineering when you’ve worked through a set of user stories? No. Not even close!” [„Ludzie kochają historie. Czy historie użytkowników są pomocne w tworzeniu rozwiązań biznesowych? Zdecydowanie tak. Czy skończyłeś z wymaganiami i inżynierią rozwiązania, gdy już opracowałeś zestaw historyjek użytkownika? Nie. Nawet nie zbliżyłeś się do nich!”.]
Świat od dekad boryka się z jakością i skutecznością specyfikowania wymagań na oprogramowanie. OMG.org opublikowało standard o nazwie MDA (ang. Model Driven Architecture ), który tak opisuje proces tworzenia oprogramowania:
CIM -> PIM -> PSM
Są to odpowiednio modele: Model Biznesowy (CIM: Computation Independent Model), Model Mechanizmu działania (PIM: Platform-Independent Model, jest to model dziedziny systemu wg. MVC) oraz Model Implementacji (PSM: Platform-Specific Model). Swego czasu szerzej opisałem zależności między tymi modelami (czytaj więcej o MDA).
CIM to model działania organizacji: procesy biznesowe i ich produkty. Z uwagi na to, że obecnie już nie rodzą się projekty jednorazowej informatyzacji całości organizacji, pojawia się potrzeba określenia zakresu projektu, bo nie jest już nim cała organizacja. Model PIM to udokumentowany mechanizm działania systemu (oprogramowania), logika jego działania. Nie ma tu mowy o tym w jakiej technologii powstanie, bo z zasady mamy ich wiele do wyboru, a wybór technologii zależy od wielu poza-funkcjonalnych ograniczeń i wymagań. Technologia jest (powinna być) konsekwencją wyboru wykonawcy i ten dopiero opracuje model PSM, który w praktyce jest tak zwaną Koncepcją Wdrożenia, można ją także udokumentować w notacji UML, ale na tym etapie powszechna praktyką jest jedynie zaprojektowanie środowiska, zestawienie go i praca od razu w kodzie.
Kluczowym problemem jest przejście z CIM na PIM, czyli jak udokumentować zakres projektu dostarczenia oprogramowania i przekształcić go na wymagania wobec tego oprogramowania?
CIM -> [zakres projektu] -> PIM -> PSM
W metodach zwanych zwinnymi, modele CIM i PIM są pomijane. Typowym zaś narzędziem „zbierania wymagań” są tak zwane historyjki użytkownika (user story). Problem w tym, że są one kluczowym ryzykiem projektów gdyż z reguły są niespójne i niekompletne jako wymagania. Specyfikacja wymagań powinna być: spójna, kompletna i niesprzeczna. Opisanie zakresu projektu historyjkami użytkownika, nie mając modelu procesów biznesowych całości (model CIM), jest pozbawieniem się narzędzia do weryfikacji kompletności, spójności i niesprzeczności takiej specyfikacji. Wszystkie wady (niekompletność, niespójność, sprzeczności) odkrywane są i usuwane (uzupełniane) dopiero na etapie wdrażania. Jest to proces „odkrywania wymagań w toku wdrożenia”.
Historyjki użytkownika jako lista potrzeb biznesowych? Owszem! Historyjki użytkownika jako wymagania dla developera? NIE! To tylko materiał dla projektanta, ponieważ bardzo często jedna i ta sama funkcja systemu realizuje wiele różnych historii użytkownika. Implementacja „per user story” prowadzi do bardzo kosztownych i nieefektywnych rozwiązań (Opisywałem to na blogu: wpis projekt Biblioteka, dwie historyjki użytkownika: chciałbym wypożyczyć książkę oraz chciałbym zwrócić książkę są realizowane jedną usługą aplikacji: Karta Wypożyczenia, która zawiera również pole Data zwrotu. Nadal spotykam programistów przekonujących, że powinny to być dwa osobne ekrany – dwa przypadki użycia, czytaj dwa razy więcej pracy kodera i dwa razy większy koszt).
Czy można sformalizować proces zbierania historyjek użytkownika?
User Story to jedno z najbardziej problematycznych narzędzi w metodach zwinnych. Najczęściej zalecana struktura tych „historyjek”, wraz z przykładami:
„Jako 〈typ użytkownika〉 chcę osiągnąć 〈cel〉, aby 〈jakiś powód〉”.
Na przykład:
„Jako Administrator chcę otrzymywać wiadomość e‑mail, gdy zostanie przesłany formularz kontaktowy, abym mógł na niego odpowiedzieć”
albo
”Jako użytkownik mam możliwość kliknięcia określonej lokalizacji na mapie”;
Tak spisywane wymagania stanowią ogromny problem z powodu nierównej gradacji, sprowadzanie ich do poziomu tak zwanych atomowych user story (drugi z powyższych przykładów) prowadzi do bardzo dużych liczb tych historyjek. Próba ich weryfikacji (walidacja user story) staje się co najmniej trudnym zadaniem. Jakakolwiek wycena oprogramowania na bazie takich historyjek to wróżenie z fusów (więc developerzy mocno zawyżają wyceny z uwagi na ryzyko utraty rentowności). Autorzy innego opracowania zauważają:
Rzeczywiście, przy około 800 US [User Story], hierarchia była raczej trudna do określenia, a obraz systemu podczas planowania był bardzo duży. Skalowalność jest więc zdecydowanie problemem w projektach zwinnych, w których US są słabymi artefaktami inżynierii wymagań. Zdecydował się on [autor] na wprowadzenie wzorca US: „Jako [Użytkownik], chcę [Zadanie], aby [Cel]”, aby zdefiniować hierarchię w postaci Celu, Zadania i Użytkownika, ale bez powiązania semantycznego.
Znam projekt, w którym liczba przypadków użycia, w pewnym średniej tylko wielkości projekcie, szybko sięgnęła czterystu. Wycena na ich podstawie pokazała, że planowany koszt wielokrotnie przekracza planowany budżet. Ten projekt zarzucono, jednak wiele tak wycenionych projektów jest realizowanych, co daje obraz skali strat jakie przynoszą (zawyżony koszt to strata). Powyżsi autorzy piszą na zakończenie:
Przyszłe prace obejmują identyfikację luk reprezentacyjnych, które napotykają praktycy w modelowaniu US, oraz przegląd sposobów, w jakie nasze ramy i [metoda] GORE w ogóle mogłyby rozwiązać te problemy. Równolegle oceniana będzie również zdolność praktyków do stosowania proponowanych ram zamiast zwykłych szablonów. Obecnie trwają prace nad narzędziem CASE (Computer Aided Software Engineering), które zostanie wykorzystane do wsparcia eksperymentów.
Nie znalazłem wyników dalszych prac, więc podzielę się wynikami swoich.
Gradacja User Story
Podstawowym problemem z user story jest, moim zdaniem, brak standardu pozwalającego na zdefiniowanie „atomowej historyjki użytkownika” czyli poziomu, poniżej którego nie dzielimy ich na mniejsze. Jako audytor wielu dokumentacji (często w roli biegłego) zauważyłem, że historyjki użytkownika są doprowadzane do poziomu pojedynczych kroków scenariuszy przypadków użycia. Często też historyjki użytkownika utożsamiane są z przypadkami użycia (UML) i tak modelowane, co jest poważnym błędem. Np. powyższe:
„Jako użytkownik mam możliwość kliknięcia określonej lokalizacji na mapie”
Mogło by to być częścią scenariusza usługi (przypadek użycia UML), której celem jest Pokazanie Określonego Miejsca:
AKTOR inicjuje usługę Cel podróży
SYSTEM wyświetla formularz Adres
AKTOR wprowadza dane i naciska OK
SYSTEM wyświetla mapę z naniesioną lokalizacją
AKTOR klika określony punkt na mapie
SYSTEM powiększa obraz pokazując detale lokalizacji
Powyższa historyjka to jedynie punkt 5. tego scenariusza. Nie trudno dojść do wniosku, że samo kliknięcie na mapie to pozbawiona kontekstu i celu, wyrwana prosta czynność, i jej samodzielne istnienie w specyfikacji jako osobny byt, pozbawione jest sensu. Z perspektywy oprogramowania powstającego w określonym celu, uznanie tej historyjki za samodzielne wymaganie nie ma uzasadnienia. Uznanie jednak, że aplikacja służy między innymi do zapoznawania się określonymi miejscami w przestrzeni, a usługą tej aplikacji jest Pokazanie Określonego Miejsca jak najbardziej ma sens. Idąc za sugestią by historyjka użytkownika miała strukturę:
„Jako [Użytkownik], chcę [Zadanie], aby [Cel]”
zmusza do zastanowienia się czy klikanie na mapie jest celem, czy może jednak tym celem jest Pokazanie Określonego Miejsca, a klikanie jest elementem scenariusza (procedury) realizacji tego celu (pamiętamy, że przypadki użycia mają scenariusze, a te złożone są z sekwencji kolejnych kroków!).
Formalizacja User Story
Pojęcia Użytkownik, Zadanie, Cel, jako spójny zestaw pojęć odpowiadają definicji atomowego (elementarnego) procesu w notacji BPMN (dodatek C, Słownik , ): Aktywność jest skojarzona z jej wykonawcą (pula, tor), tworzy produkt (data object). Biorąc pod uwagę fakt, że produkt ma tu określonego adresata i musi on stanowić sobą wartość dla tego adresata, mamy punkt wyznaczający granicę „dzielenia na części” tych historyjek. Nie będzie to „możliwość wstawienia z listy numeru NIP nabywcy” a „utworzenie faktury” (bo wartość ma dopiero poprawnie wystawiona faktura, a nie kliknięcie np. w pole NIP by wybrać kontrahenta).
Jak sformalizować historyjkę użytkownika? Podstawą formalizacji (i celem) jest opracowanie metody kontroli poprawności (walidacja). Popatrzmy jeszcze raz na szablon:
„Jako 〈typ użytkownika〉 chcę osiągnąć 〈cel〉, aby 〈jakiś powód〉”.
Typ użytkownika to rola, celem jest produkt pracy, a powodem? Powodem jest zawsze to, że określona osoba oczekuje na efekt tej pracy (bez tego praca ta byłaby po prostu zbędna). Można więc wyobrazić sobie taki zapis:
Jako sprzedawca, chcę wystawić fakturę, klientowi.
Mamy tu:
rola: sprzedawca
cel: faktura
powód: oczekuje tego klient.
W tym miejscu widać pełną zgodność tej definicji z konstrukcją: aktywność, jej produkt, jego odbiorca. Innymi słowy analityczny model procesów biznesowych wykonany w notacji BPMN, to nic innego jak połączone w logiczne ciągi historyjki użytkownika.
Wyobraźmy sobie taką listę historyjek użytkownika, wykonaną wg. powyższego opisu:
Specyfikacja historyjek użytkownika
Niektóre narzędzia CASE, pozwalające na ich profilowanie, pozwalają przedstawić to także na modelu wymagań (co później umożliwia śladowanie, czyli kontrolę kompletności, spójności i niesprzeczności):
Diagram wymagań (notacja SysML)
Powyższe mogłoby być konsekwencją takiego modelu procesów:
Jak widać, model procesu daje pełny kontekst dla aktywności. Fakt, że proces to logiczny przepływ pracy, powoduje, że tworzenie modeli BPMN gwarantuje spójność, kompletność i niesprzeczność listy aktywności, ich produktów i ról.
Podsumowanie
Stosowanie typowych historyjek użytkownika ma dwie kluczowe wady: 1. nie ma jednej metody zarządzania ich gradacją i strukturą, wielu autorów przywołuje własne, nieco się różniące metody standaryzacji, 2. ich drobiazgowość oraz brak metody kontroli spójności, prowadzą do szybko rosnącej ich liczby, w konsekwencji chaosu, szczególnie w średnich i większych projektach.
Powyżej widać, że modelowanie procesów biznesowych na podstawie zebranych przykładowych dokumentów (produkty pracy ludzi: dokumenty) i opracowanie na ich podstawie diagramu przypadków użycia, daje znacznie lepsze wyniki niż zbierane na warsztatach historyjki użytkownika. Same wymagania wyrażone jako historyjki użytkownika, nie dają żadnej szansy (brak metody) na kontrolę ich spójności, kompletności i niesprzeczności. Wymagania, jako konsekwencja poprawnie wykonanych modeli procesów biznesowych, z zasady są spójne, kompletne i niesprzeczne.
W przytoczonym tu przykładzie widać, że dwie aktywności (rejestracja zamówienia i kontrola jego statusu) realizowane są jako dostęp do zapisanego w systemie Zamówienia. Daje to jasną przesłankę do tego, że dwie historyjki użytkownika (dwie aktywności na modelu procesów) to dwa różne konteksty użycia tej samej usługi aplikacji: Zamówienia (czyli dostęp do ich tworzenia, aktualizacji i podglądu, to typowy przypadek użycia typu CRUD). Prawa dostępu do tego dokumentu modeluje się zaś regułami biznesowymi (nie pokazano ich na diagramach), np. „Klient ma wgląd tylko w Zamówienia, które sam złożył”.
Można uznać, że małe projekty, o małym ryzyku chaosu wywołanego brakiem modeli procesów, można realizowac „na skróty” czyli historyjki użytkownika i od razu model PSM (implementacja) z pominięciem CIM i PIM, jednak jest to poważne ryzyko już przy średnich projektach. Dlatego proces MDA:
{CIM -> [zakres projektu] -> PIM} -> PSM
wydaje się być znacznie efektywniejszy co pokazuje praktyka (w nawiasach klamrowych {} zakres pracy analityka-projektanta).
Zakres projektu to albo całe procesy biznesowe albo świadomie wybrane ich określone aktywności. Nie jest to także żaden „wodospad” (waterfall), bo analityczny model procesów biznesowych powstanie szybciej i taniej niż lista setek historyjek z pomocą wielodniowych warsztatów angażujących całe zespoły ludzi. Wygenerowane z modelu procesów biznesowych przypadki użycia, są z zasady spójne i kompletne, więc ich iteracyjne (kolejne) specyfikowanie (każdy projektujemy jako samodzielny mikroserwis) pozwala bez ryzyka oddawać je kolejno do implementacji, i jednocześnie dokumentować (uszczegóławiać) kolejne.
To sprawdzona w praktyce metoda wspierana przez wiele narzędzi CASE (wszystkie diagramy i ich przekształcenia pokazane w tym artykule powstały z użyciem Visual-Paradigm). Diagram przypadków użycia UML jest tu automatycznie generowany z modeli BPMN, wg poniższych zasad:
Po tej operacji wystarczy sprawdzić konteksty dokumentow i skonsolidować w jeden ewentualne nadmiarowe przypadki użycia. I na koniec:
„Jeśli nie masz modeli pojęciowych, brakuje Ci ważnego elementu układanki w projektowaniu rozwiązań, który jest niezwykle pomocny w dostrzeganiu i przekazywaniu ogólnego obrazu tych historyjek.”
Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agile requirements: the Quality User Story framework and tool. Requirements Engineering, 21(3), 383 – 403. https://doi.org/10.1007/s00766-016‑0250‑x
Ronald G. Ross. (2020). Business Knowledge Blueprints Enabling Your Data to Speak the Language of the Business (2nd Edition). Business Ruless Solution LLC.
Ross, R. G., & Fisher, L. (2020). Business Rules: Management and Execution.
Wautelet, Y., Heng, S., Kolp, M., & Mirbel, I. (2014). Unifying and Extending User Story Models. In M. Jarke, J. Mylopoulos, C. Quix, C. Rolland, Y. Manolopoulos, H. Mouratidis, & J. Horkoff (Eds.), Advanced Information Systems Engineering (Vol. 8484, pp. 211 – 225). Springer International Publishing. https://doi.org/10.1007/978 – 3‑319 – 07881-6_15
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.