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.
Ukazują się różne opracowania na temat tytułowej transformacji. Jednym z takich opracowań jest tekst Transformacja Modeli Pana Piotra Carewicza z firmy 300 D&C, opublikowany w periodyku Analiza Biznesowa Lato 2015 firmowanym przez Warszawski oddział IIBA. Pozwolę sobie na pewną polemikę z przedstawionym tam procesem transformacji modelu procesów biznesowych BPMN na Przypadki Użycia notacji UML. Autor powołuje się na OMG.org i specyfikacje BPMN i UML. Dlatego dla porządku przytoczę kluczowe definicje.
10.3 Activities An Activity is work that is performed within a Business Process. An Activity can be atomic or non-atomic (compound). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which allows the inclusion of re-usable Tasks and Processes in the diagram. However, a Process is not a specific graphical object. Instead, it is a set of graphical objects. The following sub clauses will focus on the graphical objects SubProcess and Task. Activities represent points in a Process flow where work is performed. They are the executable elements of a BPMN Process. (źr. BPMN formal 13 – 12-09)
Aktywność to element w procesie reprezentujący wykonaną określoną pracę. Atomowa (elementarna) aktywność to czynność w procesie, której nie dzielimy już na mniejsze elementy składowe.
18.1.3.1 Use Cases and Actors A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject. A UseCase is a kind of BehavioredClassifier that represents a declaration of a set of offered Behaviors. Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. These Behaviors, involving interactions between the Actors and the subject, may result in changes to the state of the subject and communications with its environment. A UseCase can include possible variations of its basic behavior, including exceptional behavior and error handling. (źr. UML 2.5 formal 13 – 12-09)
Przypadek użycia jest więc konkretnym zachowaniem systemu (subject) dającym jako efekt wartościowy (oczekiwany) rezultat dla aktora.
Transformacja wg. OMG
Dla dokonania jakiejkolwiek transformacji, należy przyjąć konkretną pragmatykę (kontekst) gdyż obie notacje (UML i BPMN) dają pewną swobodę jej użycia (jak widać powyższe definicje dają pewien margines swobody użycia tych symboli). Z pomocą może przyjść nam biznesowa definicja procesu biznesowego: aktywność przekształcająca stan wejścia w stan wyjścia procesu, tworząca wartościowy produkt dla aktora (roli w procesie). Taka aktywność jest realizowana (może być) zgodnie z jakąś procedurą. Przypadki użycia są ograniczane ich stanem początkowym i końcowym, mają aktora, mają jeden lub więcej alternatywnych scenariuszy. Warto tu zwrócić uwagę, że stan początkowy i końcowy przypadku użycia oraz wejście i wyjście elementarnego procesu biznesowego, to analogiczne – odpowiadające sobie – pojęcia. Pojęcie „atomowy” (w literaturze spotykane słowo to także „elementarny”) oznacza:
elementarny proces biznesowy: zadanie wykonywane przez jedna osobę, w jednym miejscu i określonym czasie, w odpowiedzi na określone zdarzenie biznesowe; zadanie to prowadzi do uzyskania mierzalnej wartości biznesowej; po jego wykonaniu dane są w spójnym stanie; (przypadki użycia powinny realizować elementarne procesy biznesowe, cytat z: UML i wzorce projektowe, Craig Larman)
Kluczowym wymaganiem dla transformacji jest zdefiniowanie pojęcia, które będzie łącznikiem (będzie transformowane z „czegoś” na „coś”, będzie wspólnym elementem w obu modelach) pomiędzy modelem procesów biznesowych a modelem przypadków użycia. Tu z pomocą przychodzi architektura SOA. SOA to wzorzec łączący model procesów biznesowych z modem aplikacji:
Generalnie koncepcja SOA bazuje na uznaniu, że „atomowe” procesy biznesowe są wspomagane (support) pojedynczymi usługami aplikacyjnymi. Tu znowu powołamy się na OMG.org i specyfikację profilu UML jakim jest SoaML:
6.1.5 Key Concepts of Basic Services A key concept is, of course, service. Service is defined as the delivery of value to another party, enabled by one or more capabilities. Here, the access to the service is provided using a prescribed contract and is exercised consistent with constraints and policies as specified by the service contract. A service is provided by a participant acting as the provider of the service-for use by others.
6.2.6 Business Motivation […] There are other ways of capturing requirements including use cases. A Service Contract, which is also a classifier, can realize UseCases. In this case, the actors in the use case may also be used to type roles in the service contract, or the actors may realize the same Interfaces used to type the roles. (źr. OMG SoaML, formal-12 – 05-10)
Tak wiec mamy przełożenie: atomowy proces w BPMN, aktywność która wraz z jej wejściem i wyjściem, jest przyporządkowywana do pojedynczej usługi aplikacyjnej reprezentowanej w UML jako przypadek użycia, który ma swój stan początkowy i końcowy. Zarówno atomowy proces jak i przypadek użycia nie są już dzielone na mniejsze elementy, bo „gradację” podziału „w dół” ogranicza to, że w toku spójnej pracy jednego człowieka (aktor) ma powstać wartościowy dla aktora rezultat (produkt). Innymi słowy atomowym procesem i zarazem przypadkiem użycia, będzie np. utworzenie faktury sprzedaży, gdyż niekompletna faktura nie stanowi żadnej wartości biznesowej. Wszelkie działania w toku tworzenia faktury są elementami scenariusza jednego przypadku użycia, a wcześniej procedury realizacji jednej aktywności tworzącej tę fakturę.
Jak więc wygląda transformacja? Tu posłużę się fragmentem strony pomocy pakietu Visual-Paradigm, jednej z niewielu aplikacji CASE zachowującej pełną zgodność ze specyfikacjami OMG:
Diagram przypadków użycia nie jest modelem „systemowym”, jest kontraktem pomiędzy zamawiającym oprogramowanie a jego dostawcą, stanowi specyfikację wymagań, gdzie pod pojęciem „wymaganie” rozumiemy to, jakie usługi ma to oprogramowanie oferować (do czego będzie ono wykorzystywane przez aktora):
18.1 Use Cases 18.1.1 Summary UseCases are a means to capture the requirements of systems, i.e., what systems are supposed to do. The key concepts specified in this clause are Actors, UseCases, and subjects. Each UseCase?s subject represents a system under consideration to which the UseCase applies. Users and any other systems that may interact with a subject are represented as Actors. (UML v.2.5)
W modelu MDA (Model Driven Architecture) diagram przypadków użycia stanowi „pomost” pomiędzy modelem biznesowym CIM (Computation Independet Model) a modelem logiki działania i architektury PIM (Platform Independent Model). Model PIM to realizacje przypadków użycia bazujące na modelu dziedziny.
18.1.3 Semantics 18.1.3.1 Use Cases and Actors […] Each UseCase specifies some behavior that a subject can perform in collaboration with one or more Actors. UseCases define the offered Behaviors of the subject without reference to its internal structure. (UML v.2.5)
Kluczem jest ostatnie zdanie: przypadki użycia definiują zachowanie systemu bez odnoszenia się do jego wewnętrznej struktury. Innymi słowy model przypadków użycia nie służy do modelowania architektury (wewnętrznej struktury) oprogramowania. W UML 2.5 jawnie wydzielony trzy obszary semantyczne modelowania, które potwierdzają powyższe:
Jednak dla zachowania uniwersalności i kompatybilności wstecz zachowano w UML 2.5 pojęcia – stereotypy – «Extend» i «Include», które „wyjawiają” wewnętrzną strukturę aplikacji, jednak UML 2.5 zastrzega:
The specific manner in which the location of an ExtensionPoint is defined is intentionally unspecified. This is because UseCases may be specified in various formats such as natural language, tables, trees, etc. […] The included UseCase must be available for the behavior of the including UseCase to be completely described. (UM v.2.5. R.18.1.3.)
Czyli stereotypy związku użycia dla przypadków użycia, oznaczone związkiem «extend» lub «include», zostały w UML 2.5 dla zachowania możliwości używania diagramów przypadków użycia i kontynuowania ich opisu w firmie opisowej (tekst, tabele, innego formy słowne a nie graficzne). Są to reliktowe konstrukcje z czasów gdy na początku lat 90-tych powstawał UML (były to trzy odrębne notacje trzech twórców): autor diagramu przypadków użycia nie znał diagramów strukturalnych (diagramy klas, komponentów) i musiał jakoś „pokazać” elementy architektury kodu. Stosowanie tych konstrukcji w sytuacji gdy modelem realizacji przypadków użycia będą diagramy sekwencji bazujące na modelu dziedziny (modele struktury), nie ma żadnego uzasadnienia i wprowadza zbędny zamęt i nadmierne, niczym nie uzasadnione, rozdrobnienie modelu (pomijam, że na tym etapie – umowa z zamawiającym – przedwcześnie narzuca decyzje architektoniczne).
Autor tekstu wprowadził także kolejny podział przypadków użycia (stereotypy) na „cel użytkownika”, przypadki „wspierające”, „pomocnicze”, „podfunkcje”. Niestety nie zostały one (te pojęcia) precyzyjnie zdefiniowane, wprowadzają do całej „metody” chaos pojęciowy. Z kontekstu można wywodzić, że jest to jakaś forma wyniesienia na poziom modelu przypadków użycia, poszczególnych kroków ich scenariuszy (wyszukanie zgłoszenia, zapisanie informacji o zmianie zgłoszenia do dziennika) czy wręcz (o zgrozo!) linii kodu, jednak cel tego jest niejasny, poza znaczną komplikacją diagramu, który jako kontrakt z kupującym, powinien być prosty i czytelny dla „biznesu”. Wyciąganie na poziom „usług systemu” niemalże pojedynczych linii przyszłego programu nie znajduje w moich oczach żadnego uzasadnienia (po raz kolejny przypominam, że przypadki użycia to wymagania a nie model kodu), poza tym, że przybliża taki model do produktów analizy strukturalnej z lat 80-tych (pytanie po co?).
Autor powołuje się także na notację BPMN słusznie wskazując, że do transformacji na przypadki użycia tworzymy „proces prywatny”, nie przeznaczony do wykonania (non-executable) w rozumieniu „nie tworzony w celu bezpośredniego uruchomienia” np. w jakimś „silniku procesowym”. I tu kończy się konsekwencja, gdyż zaleca stosowanie detalicznych czynności i znaczników specyficznych dla modeli wykonywalnych (oznaczenia w lewym górnym roku). Otóż do transformacji na przypadki użycia tworzymy model CIM (OMG MDA) a tu nie „brniemy” w detaliczne szczegóły, gdyż te będą realizowane w aplikacji. Model CIM to procesy biznesowe „computation independent model” w notacji BPMN, poziom szczegółowości modelu biznesowego CIM, do transformacji, kończymy na wspomnianych na początku „atomowych procesach biznesowych”, to która z aktywności tych procesów stanie się wymaganiem (przypadkiem użycia aplikacji) zależy od umowy na zakres projektu i od niczego więcej. Wymóg jakoby czynności wysłania i odebrania komunikatu musiały być obligatoryjnie wydzielane wydaje się dziwny. Np. czytamy:
Send Task A Send Task is a simple Task that is designed to send a Message to an external Participant (relative to the Process). Once the Message has been sent, the Task is completed.
skoro więc czynność wysłania komunikatu jest dedykowana do jednego zdarzenia jakim jest wysłanie komunikatu, zaś na modelu procesów biznesowych „nie-wykonywalnych” taki poziom szczegółowości nie jest niczym uzasadniony (wysłanie potwierdzenia to z reguły ostatni krok procedury a w scenariuszu przypadku użycia, ostatni krok tego scenariusza) to pomysł ten wydaje się nie mieć żadnego uzasadnienia. Po drugie „wysłanie komunikatu” odwzorowane jako przypadek użycia nie ma żadnego sensu w świetle tego czym jest przypadek użycia w UML.
Nie wiem też jak, z pomocą jakiej transformacji, Pan Carewicz uzyskał na diagramie przypadków użycia dziedziczących po sobie aktorów.
Na zakończenie
Z przykrością muszę napisać, że artykuły takie jak tekst Pana Piotra Carewicza wprowadzają zamęt. Nie mają, jak pokazałem, podstaw semantycznych, nie mają uzasadnienia w samych notacjach, nie raz wręcz kolidują z nimi, prowadzą do powstawania bardzo rozbudowanych i kosztownych w opracowaniu dokumentów, nie wnoszących swoją szczegółowością żadnej wartości dodanej, a użycie takiej dokumentacji jest praktycznie nie możliwe, gdyż jak widać jest ona niespójna a nadmiar szczegółów podanych na tak wczesnym etapie jak planowanie wymagań, prowadzi do bardzo dużej ilości aktualizacji w toku realizacji projektu. Zdaje sobie sprawę, że Pan Carewicz próbuje sobie jakoś poradzić z użyciem UML do metody wymiarowania oprogramowania COSMIC, której jest orędownikiem, ale moim zdaniem to jednak ślepa uliczka.
Powyższe, nie mające uzasadnienia w UML, konstrukcje, można spotkać także w materiałach publikowanych przez firmę SPARX, producenta oprogramowania Enterprise Architect. Osobiście, i nie tylko ja (np. Czas nie jest aktorem), odradzam te materiały i sugeruję jednak oryginalne specyfikacje. Samo narzędzie firmy SPARX, mimo, że bardzo tanie i popularne, niestety jest bardzo pracochłonne. Tyle w kwestii samej transformacji. Ocenę metody opisanej przez Pana Carewicza z firmy 300 D&C pozostawiam czytelnikom.
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.
Projekty integracyjne w środowisku złożonych (kilkadziesiąt aplikacji) systemów należą do bardzo trudnych z uwagi na ich złożoność. Z pomocą przychodzi nam SOA jako model pojęciowy i ESB jako wzorzec architektury. Referat, wygłoszony na konferencji GigaCon, opisuje proces analizy i modelowania w toku specyfikowania wymagań na ESB i interfejsy.
Poniżej struktura architektury SOA na bazie standardów OMG:
Kluczowe pojęcia: – procesy biznesowe, elementarne aktywności, która wraz z wejściem i wyjściem stanowią elementarny proces biznesowy, – usługa biznesowa (także aplikacyjna) to przypadek użycia danej aplikacji (aplikacja świadczy usługi, każda usługa ma stan początkowy, produkt i scenariusz realizacji), – komponent, reprezentuje integrowane aplikacje.
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.
Diagram przypadków użycia stale budzi wiele kontrowersji. Bywa, że nafaszerowany związkami «include» i «exclude» wygląda jak talerz winogron.
Considering that the main rationale of use cases is to provide a conceptual bridge between business value and system capabilities, it’s not the role of business analysts to weld their concrete, and specific requirements into the consistent and stable functional architecture implemented by software classes. (źr. Use Cases should know nothing about classes | LinkedIn).
Powyższy cytat pochodzi z pewnej dyskusji. „Świat się spiera” na temat tego do czego służy diagram przypadków użycia. Dyskusja na LinkedIn pokazała, że „świat jest w tej kwestii podzielony”. Skąd problem?
W 2011 roku napisałem, nie pierwszy i pewnie nie ostatni raz, że to ma być prosty diagram. Jego celem jest określenie zakresu projektu w postaci, zrozumiałego dla zamawiającego, diagramu pokazującego kto i do czego będzie używał aplikacji. I nic ponad to. NIe przypadkiem jest często uznawany za tak zwany „[[model czarnej skrzynki]]”. Tak często spotykane, modele nafaszerowane szczegółami projektu wywleczonymi na wierzch z pomocą związków «include» i «extend», stanowią zbędne (i przedwczesne) ujawnianie architektury wewnętrznej, zaś dziedziczenie na tych diagramach to dla odmiany zbędne wplatanie tu modeli pojęciowych. Komplikowanie tego diagramu niszczy jego podstawową rolę: kontrakt zamawiającego z dostawcą oprogramowania: zamawiający zawiera świadomie ten kontrakt gdy zrozumie ten diagram.
…proste jest piękne: przypadek użycia to pojedyncza, elementarna kompletna usługa świadczona przez System dla jego użytkownika (czytaj Przypadki użycia…).
Specyfikacja UML owszem zawiera opis, nie tylko, związków «include» i «extend» ale i dziedziczenia, należy jednak pamiętać, że specyfikacja zachowuje kompatybilność wstecz (aż do lat 90-tych!) i to, że pomysłodawca tego diagramu (obecny UML to zlepek trzech notacji) nie znał diagramu klas, wiec musiał sobie jakość poradzić z pokazaniem choćby namiastki wewnętrznej struktury aplikacji. Dysponując jednak lepszym do tego narzędziem, jakim jest diagram klas lub komponentów, komplikowanie diagramów przypadków użycia nie ma większego sensu. Polecam tu niedawno napisaną recenzje książki UML for Java programmers:
Drugim powodem jest postępująca standaryzacja modeli pojęciowych różnych notacji rodem z OMG, między innymi z powodu rosnącego znaczenia (i korzyści z…) całościowego podejścia do modelowania organizacji zwanego architekturą korporacyjna lub biznesową (lub po protu [[podejściem systemowym do analizy organizacji]]). Ta standaryzacja to między innymi „zrównanie” pojęcia „aktywność” w procesie biznesowym (BPMN) z pojęciem Przypadek Użycia (UML), gdzie jest to elementarna usługa, wspierająca aktywność aktora, mająca stan początkowy i końcowy (a proces ma wejście i wyjście), stan końcowy cechuje określona wartość dla aktora (UML) lub odbiorcy (BPMN), z pojęciem usługa aplikacyjna w architekturze SOA (i w architekturze korporacyjnej).
Obecnie przypadki użycia stanowią pomost pomiędzy perspektywą biznesową widząca przypadki użycia jako „usługi aplikacji” a perspektywą aplikacji, która oferuje je (przypadki użycia) jako usługi aplikacyjne. Poniżej „klasyczny”, od lat znany, diagram obrazujący model SOA ([[Service Oriented Architecture]]):
Na tym diagramie widać (nie sugerujmy się kształtem ikon ;)) warstwę Business Servces, która stanowi ni mniej ni więcej tylko właśnie przypadki użycia aplikacji (Components) umieszczonych w warstwie poniżej. Na dzisiaj procesy biznesowe modelujemy notacją BPMN (twardziele nadal robią to diagramem aktywności UML ;)), a resztę poniżej notacją UML (mapując 1:1 atomowe procesy biznesowe na przypadki użycia, niektóre programy CASE robią to nawet automatycznie):
The most effective way to develop a quality software that can streamline and blend well with users» daily operations is to begin by analyzing users» daily work flows with care and precision and, to understand how parties work together to get jobs done. By doing so, you can find out the functions that the software should provide in order to help the users. (From Business process to Use Case…)
Jeżeli nad procesami umieścić model motywacji biznesowej (notacja BMM, nie ma tej warstwy na powyższym diagramie) to otrzymamy model architektury korporacyjnej (po kilku próbach zastosowania nadal uważam, że [[notacja ArchiMate]] nie wnosi żadnej wartości dodanej, jest to – pomysł na nowa notację – raczej zaprzeczeniem zasady „nie mnóż bytów ponad potrzebę” znanej jako [[brzytwa Ockhama]]).
Jest tu jeszcze jedna ciekawa rzecz: nie ma danych na tych modelach. „Staromodne” podejście mówi, że oprogramowanie to struktury danych i funkcje. I tak jest od strony technicznej ale to nie ma nic wspólnego z biznesem. Biznes jest zainteresowany faktem sprzedaży, a to, że dokumentujemy do fakturą VAT to „szczegóły”. Dlatego na tym poziomie abstrakcji (uogólnienia) nie ma sensu robienie modeli danych, ma sens robienie specyfikacji obiektów biznesowych, na poziomie ich nazw. Takie podejście nazywa się zarządzaniem poziomem szczegółowości projektu (od ogółu do szczegółu), na poziomie modelowania takiej architektury nie ma znaczenia to, ile danych jest na fakturze, znaczenie ma, to że zaistniał fakt sprzedaży i na czymś (nośnik danych, obiekt bezsensowy z nazwą) go udokumentowano.
Tak więc na tytułowe pytanie obecnie należało by odpowiedzieć: nie, przypadki użycia nie znają swoich realizacji… W dokumentacji na etapie modelowania przypadków użycia, tworzymy prosty diagram złożony z trzech typów elementów: aktor, przypadek i system. Bez pomijania elementu „system” (prostokąt będący kontenerem ma przypadki użycia), który stanowi podstawę tego diagramu: wskazuje granice systemu. Jakiekolwiek szczegóły, w tym modele danych, to ostatni etap pracy jakim jest projektowanie i wykonanie implementacji. Wszelkie bazy danych modelujemy na samym końcu.
Kolejny wniosek: przypadków użycia nie są setki a o rząd a nawet dwa rzędy mniej. Specyfikacje na setki przypadków użycia to jakieś totalne nieporozumienie (albo niezrozumienie). Usługa aplikacji świadczona aktorowi (kompletna) to nie wstawienie adresu na fakturze, a wystawienie (utworzenie) kompletnej faktury. Wstawianie adresów, produktów itp. to elementy scenariusza przypadku użycia (wywołania na diagramie sekwencji albo opis współdziałania aktora z ekranem aplikacji).
Nie ma też np. czegoś takiego jak „[[systemowe przypadki użycia]]”, anie czego takiego jak „[[biznesowe przypadki użycia]]” (to relikt z metodyki RUP z lat 90’tych przed pojawieniem się notacji BPMN). Wiem, wiem, że często się pojawiają w literaturze i na stronach znanych blogów, jednak nigdzie tam nie znalazłem definicji tych pojęć odróżniających te twory od „normalnych” przypadków użycia, interfejsów komponentów czy procesów biznesowych. Prowadzenie nowego pojęcia powinno mieć jakieś podstawy i wartość dodaną bez tego są tylko urywaniem niezrozumienia modelowanej istoty rzeczy i łamaniem zasady ekonomii myślenia, tej prostej zasady „nie twórz bytów ponad miarę” (przypominam [[brzytwa Ockhama]]) (niestety firma SPARX, producent bardzo popularnej i taniej aplikacji: Enterprise Architect, ma w zwyczaju wymyślanie różnych dziwnych bytów tego typu, między innymi „czas jako aktor systemu” nadając mu dedykowany stereotyp). Bo zastanówcie się, gdzie na powyższym diagramie SOA wstawić owe systemowe czy biznesowe przypadki użycia???
Owszem, można przyjąć dowolna konwencję tworzenia modeli ale wtedy należy ją opisać od strony pojęciowej. Bez tego model staje się zwykłym obrazkiem, nie jest modelem. Ale pytanie po co, skoro w BPMN/UML to wszystko jest, wraz z opisem jak „gładko” przejść z modelu biznesowego, przez model przypadków użycia do modelu architektury systemu… Owszem notacja UML zawiera wszystkie opisane tu pojęcia i symbole, ale nie wolno zapominać, że notacja to wyłącznie język czyli same słowa i gramatyka, sens maja dopiero zdania. Tak wiec pisząc „Krowa z silnikiem odrzutowym, jelita na czerwono, jądrowymi kopytami, wyprawiona na buty skóra, zniszczyła metro, wypadek samochodowy, przelatując nad Warszawą, liczba płyt chodnikowych to 1347, a następnie wylądowała w Elektrociepłowni Żerań, załadunek węgla w południe wykonany przez Kowalskiego, i pożywiła się węglem popijając wodę z Wisły” to poprawne gramatycznie, bezbłędnie napisane zdanie w języku polskim, ale nikt nie ma chyba wątpliwości, że kompletnie pozbawione sensu. Tak samo można poprawnie, zgodnie z zasadami notacji, narysować diagram UML …
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.
Bałagan pojęciowy w raporcie z analizy, powoduje, że raport nie pozwala na jego jednoznaczną interpretację, co praktycznie dyskwalifikuje go jako przydatne źródło informacji w projekcie.
Dzisiaj kontynuacja tej tezy w kontekście powstających modeli, ich treści i szczegółowości.
Weźmy np. dość często pojawiające się pojęcia: „proces systemowy” czy też „system” w modelu procesu biznesowego, sekwencje i diagramy sekwencji itp. Spotykam się niestety z masą bełkotu i herezji w dokumentach, na blogach czy nawet w książkach… Na listach dyskusyjnych LinkedIn widać, że problem nie dotyczy tylko naszego kraju :). Przyczyną tych problemów jest praktycznie zawsze ignorowanie definicji pojęć tak językowych (język w jakim pisana jest dokumentacja) jak i notacyjnych (ignorowanie lub po prostu nieznajomość lub nawet nie zrozumienie standardu). Czy nazywanie czegoś herezją to moje subiektywne uznanie? Myślę, że nie, to porównanie (audyt?) ze standardami i ogólnie uznanymi systemami pojęciowymi, jednym z nich język ojczysty autora dokumentu.
Najpierw kilka kluczowych definicji (słownik języka polskiego PWN):
proces: przebieg następujących po sobie i powiązanych przyczynowo określonych zmian
procedura: określone reguły postępowania
sekwencja: układ jakichś elementów, w którym następują one w określonej kolejności
scenariusz: zaplanowany lub przewidywany rozwój wydarzeń
Proces, definicja „biznesowa” mówi o produkcie procesu biznesowego, jest nim właśnie ta wprowadzona „zmiana”. Procedura w praktyce jest regułą (biznesową). Sekwencja w UML to nic innego jak ustalona (dla sensu lub powodzenia operacji) kolejność zdarzeń (wywołań). Scenariusz to pojęcie wykorzystane w opisie przypadków użycia: „scenariusz przypadku użycia”. W związku z tym, że przypadki użycia są wymaganiem (opisem użycia produktu), interakcja aktor – system, ma status „planowany”. Uznanie w projekcie, że wymaganie jest „OK”, daje w konsekwencji „projekt”, czyli sekwencję opisującą realizację przypadku użycia. Jak widać, słownik nie jest taki zły, notacje i ich system pojęciowy w szczególności.
Model CIM to model opisujący logikę działania (sens istnienia) modelowanej organizacji, to model tego „co i po co się dzieje” a nie „jak i czym”. Tu nie pokazujemy narzędzi (jakim jest np. oprogramowanie). Standardem na tym poziomie modelowania są notacje BMM i BPMN. Rzecz w tym, że model procesów biznesowych nie powinien zawierać żadnych pojęć typu „system” czy „oprogramowanie”. Dlaczego? Bo dla zrozumienia i udokumentowania tego jak działa organizacja, potrzebna jest wiedza o tym jakie informacje i jak są przetwarzane, a nie „czym”.
Często widuję próby pokazania na jednym diagramie: pracy ludzi, integracji systemów, szczegółów procedur i wszystko inne, co tylko autor dokumentu wie. To totalne nieporozumienie, to pokaz niezrozumienia tego czym są modele, a są uproszczeniami (abstrakcjami), określonymi perspektywami analizowanego zjawiska.
Model PIM to obraz logiki działania (część biznesowa, domena) narzędzia jakim jest aplikacja. Tu pojawia się to, jakie informacje i jak są (mają być) przetwarzane. Model ten jednak nie opisuje szczegółów (środowisko aplikacji, framework, rozwiązania technologiczne np. logowanie, kodowanie, itp.), opisuje wyłącznie biznesową logikę działania aplikacji. Gdzie i jak to projektować, pokazać, testować?
Przytoczę po raz kolejny diagram ze strony Business Process Trends:
(źr. http://www.bptrendsassociates.com/)
Mamy tu trzy poziomy modelowania organizacji: architektura procesów, modele procesów oraz ich implementacja. Architekturę procesów z reguły przedstawia się jako wysokopoziomowe uogólnienie np. z pomocą prostej notacji znanej jako „pagoniki” :):
Modele procesów tworzymy z użyciem, nie raz tu już omawianej, notacji BPMN. Tu jest mowa o procesach biznesowych i ewentualnych ich podprocesach ale nadal poziom szczegółowości nie schodzi poniżej pary „aktywność i jej produkt” (proces biznesowy). Implementacja to reguły wg. których realizowane są poszczególne aktywności. Dana aktywność jest realizowana albo na bazie umiejętności jej wykonawcy (rola) i nie tworzymy jej diagramu a powołujemy się na opis stanowiska, albo na bazie procedury czyli wykonawca danej pracy musi przestrzegać reguł narzuconych procedurą. Procedurę spisujemy w punktach z ewentualnymi wariantami (a nie modelujemy obrazkami). Ale implementacja to albo wdrożenie procedury albo wdrożenie oprogramowania.
A gdzie te „systemowe procesy”?
Otóż nie ma czegoś takiego, nie w architekturze opisywanej standardowo ani w BPMN ani w UML, nie ma (nie znam) w architekturze korporacyjnej. Mając wiedzę o komponentach systemu (różnych aplikacjach) mamy wiedzę do czego zostały one stworzone i jakie realizują zadania (znamy ich interfejsy). Zaś elementem, który inicjuje w systemie jakąkolwiek sekwencję wydarzeń (interakcji między aplikacjami, komponentami, obiektami) jest zainicjowany przypadek użycia systemu, a konkretnie zdarzenie inicjujące wygenerowane przez konkretnego aktora. Jeżeli teraz przypomnimy sobie, że aktorem systemu może być także inny system (kłania się diagram przypadków użycia), inicjujący interakcje (żąda obsługi, np. przez API) to mamy pełny obraz sytuacji: aktor inicjuje sekwencje wydarzeń jaką są kolejno następujące po sobie wzajemne wywołania komponentów lub obiektów. Znowu kluczowym pojęciem staje się tu SYSTEM (na diagramie przypadków użycia jest to element System czyli oryg. „subject” danej perspektywy) i jego granice. To akurat bardzo ładnie pokazuje ten turorial:
Tak więc mamy:
procesy biznesowe jako pary aktywność i jej produkt (za produkt odpowiada wykonawca procesu, są to np. modele w notacji BPMN),
procedury (lub wymagane umiejętności), opisujące atomowe (niepodzielne) aktywności (opisane np. w postaci wypunktowanych list), tworzenie procedur to implementacja określonych aktywności metodami organizacyjnymi (np. wdrożenie systemu zarządzania jakością ISO),
scenariusze przypadków użycia opisują interakcje aktor-aplikacja (opisane jako punktowane listy, modelowane jako interakcje aktor-system w notacji UML), jest to implementacja określonych aktywności w aplikacji,
Bardzo dobrze pokazuje to model SOA opisany w poprzednim artykule Wzorzec CRUD. Warstwa procesów, usług aplikacyjnych/przypadków użycia i komponentów to odrębne warstwy i perspektywy. Nie mieszamy więc ani poziomów abstrakcji ani perspektyw modeli. W przeciwnym razie, ulegając sugestiom w rodzaju „ale ja chcę zobaczyć to wszystko na jednym diagramie” pchamy projekt w kierunku „utraty panowania nad złożonością”… To prosta droga do klęski 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.
Regularnie spotykam się z monstrualnymi specyfikacjami: najpierw „wymagań” a potem „przypadków użycia”: dziesiątki, setki (o ich ilości napisałem tu). Na ich podstawie powstają wyceny – nie mniej kosmiczne. Jednak jeżeli zestawić to z badaniami projektów i oceną, że jedną z kluczowych przyczyn porażek jest nadmierna złożoność i niejednoznaczność specyfikacji wymagań, a potem samego projektu i jego zakresu oraz utrata panowania nad tym zakresem, to może warto się nad tym pochylić?
Kluczem jest definicja wymagania i często są nimi właśnie przypadki użycia. Pojęcie przypadku użycia (UML) i usługi (SoaML):
Przypadek użycia (UML, Superstructure v.2.4.1.): A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.
Usługa (SoaML, v.1.0.1.): Service is defined as the delivery of value to another party, enabled by one or more capabilities. Here, the access to the service is provided using a prescribed contract and is exercised consistent with constraints and policies as specified by the service contract.
Tak więc przypadek użycia jako efekt daje określony, wartościowy rezultat. Warto teraz w tym miejscu podkreślić, że SOA (patrz specyfikacja) zakłada, że usługa jako efekt (produkt) daje „Real World Effect defined as service operation post condition” co jest o tyle istotne, że analogicznie kończy się przypadek użycia (przypomnę, że „post condition” to stabilny stan systemu po wykonaniu operacji).
Popatrzmy teraz na pojęcie czynności w BPMN:
Aktywność a czynność: (BPMN, v.2.0) An Activity is work that is performed within a Business Process. An Activity can be atomic or non-atomic (compound). The types of Activities that are a part of a Process are: Task, Sub-Process, and Call Activity, which allows the inclusion of re-usable Tasks and Processes in the diagram. However, a Process is not a specific graphical object. Instead, it is a set of graphical objects. The following sections will focus on the graphical objects Sub-Process and Task. […] A Task is an atomic Activity within a Process flow. A Task is used when the work in the Process cannot be broken down to a finer level of detail.
Tu zaczyna się pragmatyka biznesowa, czyli definicja pojęcia proces biznesowy, która zakłada, że proces biznesowy (także elementarny, atomowy) to czynność lub łańcuch logicznie powiązanych czynności (aktywność), tworzy produkt mający wartość dla odbiorcy tego produktu (produkt musi się nadawać do biznesowego wykorzystania). Ta definicja jest niemalże kopia definicji przypadku użycia. Procesem biznesowym jest KAŻDA aktywność wraz z jej samodzielnie przydatnym biznesowo produktem (para aktywność i jej produkt, dlatego w BPMN nie ma jednej ikony na „proces biznesowy”). Jak widać, te trzy pojęcia: przypadek użycia aplikacji, usługa aplikacji oraz elementarny proces biznesowy (podkreślam, że projekty IT dla biznesu mają biznesowy kontekst co nadaje ściślejsze znaczenia tym trzem pojęciom), mają niemalże tożsame definicje (zresztą OMG dąży w tym właśnie kierunku). Popatrzmy tu:
The majority of today’s SOA design techniques 1,2,3 are centered around definition of services. They use 1service-oriented decomposition, based on the business processes, enterprise business/functional model, required long term architectural goals and reuse of the existing enterprise functionality. (Incorporating Enterprise Data into SOA).
Kluczem jest sugestia (uznanie), że elementarnym pojęciem do dekompozycji funkcjonalnej jest pojęcie elementarnej (atomowej) usługi (i nie jest nią jedna linia programu!) będącej także elementarnym procesem biznesowym. Popatrzmy na diagram obrazujący architekturę SOA (pochodzący z tego samego artykułu):
Mamy tu, między innymi, trzy ważne warstwy (tu drugą, trzecią i czwartą od góry), są to odpowiednio: procesy biznesowe, usługi aplikacyjne (ta warstwa to abstrakcja) oraz aplikacje świadczące te usługi. Mamy więc mapowanie elementarnych atomowych procesów (pojedynczych czynności) na elementarne usługi aplikacyjne. Usługi te, to nic innego jak przypadki użycia aplikacji, czyli każdą aplikację (jej użyteczność) można opisać z pomocą jej „przypadków użycia”, a te jak już wiemy, w UML służą – jak widać słusznie – do specyfikowania wymagań funkcjonalnych. Tu uwaga, nie należy tego mylić ze spotykanymi w literaturze „biznesowymi przypadkami użycia” (nie ma taki w UML).
Konwencja biznesowych przypadków użycia to relikt metody RUP z lat 90’tych, kiedy to nie było np. notacji BPMN, i tak zwany „biznesowy diagram przypadków użycia” opisywał firmę, jej usługi i klientów (aktorów), a nie aplikację (do dzisiaj jest to przyczyną wielu nieporozumień i powstawania niskiej jakości niejednoznacznych dokumentacji).
Warto tu teraz zwrócić uwagę, że wymagania funkcjonalne i poza-funkcjonalne, jakościowe i dziedzinowe oraz usługi systemu to elementy abstrakcyjne.
Tak na prawdę rzeczywiste są jedynie wymagania biznesowe jako oczekiwania zamawiającego wyrażone w jego języku, oraz przypadki użycia i model dziedziny, bo opisują rzeczywisty byt jakim jest (przyszły) produkt (aplikacja).
CRUD, czym jest?
CRUD to skrót od ang. Create, Retrieve, Update, Delete (Utwórz, Przywołaj, Zaktualizuj, Usuń). Są to cztery podstawowe operacje na tak zwanych kartotekach, obiektach służących do zapamiętywania informacji czyli pojedynczych „encji” (nie mylić z encjami w bazach relacyjnych) lub ich agregatach. Obiektami odpowiedzialnym za ich przechowywanie są repozytoria (Repository). Kluczowe cztery operacje udostępniane przez repozytorium to właśnie CRUD. Pytanie brzmi: czym jest kartoteka? Jest zbiorem kart (dokumentów) o jednakowej (lub podobnej) strukturze. Tak więc usługą jest „zarządzanie kartami”, czy też odrębnymi usługami są tworzenie karty, czytanie, uzupełnienie, usunięcie? Popatrzmy na to z perspektywy usługi dla użytkownika: ma sens posiadanie wygodnej szuflady z kartami w bibliotece ale czy ma sens samodzielna, wyjęta z kontekstu usługa „tworzenie nowych kart”? Można polemizować, ale jeżeli chcieć utrzymać spójność pojęciową i możliwość kontroli spójności i kompletności projektu i jego zakresu, lepiej uznać, że usługą aplikacyjną jest „zarządzanie kartami”. Po pierwsze taka usługa jest samowystarczalna, zaś samo tworzenie karty bez możliwości jej przywołania nie ma sensu, więc te cztery proste czynności są niejako nierozerwalnie związane, stanowiąc jedną usługę. Po drugie tworzenie nowego zapisu, modyfikowanie czy usuwanie, to kontekst użytkownika, w zasadzie każdą z czterech operacji CRUD można sprowadzić do scenariusza:
pokaż kartę (pusta to tworzenie nowego zapisu)
zrób z tym coś (wpisz nowe, zmień, usuń) i potwierdź (zachowaj skutek)
Dlatego są podstawy by uznać, że „zarządzanie kartami katalogowymi” to jednak jeden przypadek użycia, a poszczególne operacje, to kontekstowe warianty scenariusza wynikające z procesu czyli chwilowego celu użytkownika (aktora). To podobnie jak młotek (usługa dostępna ze skrzynki narzędziowej), to człowiek używa młotka w kontekście wbijanie gwoździa, zbijania szyby, rozbijania kamieni. Młotek w rękach człowieka po prostu służy do uderzania, więc przypadkiem użycia jest uderzanie a nie czynność w procesie zbijania budy dla psa jaką jest wbijanie gwoździ w deski. Podejście takie wcale nie jest nowe, w ciekawy sposób opisał to autor tego artykułu:
If you have ever been writing use cases for a data-oriented system (i.e. CMS), you have probably noticed that there is a problem with the large number of use cases like „Add an article”, „Remove an article” etc. If you have all CRUD operations available for all objects in the system, you can finish with up to 4 x number-of-objects of use cases. You can reduce this number by introducing the CRUD pattern, which I would like to present you in this blog entry. (CRUD Pattern in Use Cases ? PUT Software Engineering Team).
Można takie podejście (wynikające niejako wprost z definicji przytoczonych pojęć), jak widać, nazwać wzorcem projektowym :). Bardzo ładnie przekłada się to na architekturę (model oparty o wzorzec BCE), operującą pojęciami boundary (granica), controll ( sterowanie) i entity (nośnik informacji):
Na powyższym diagramie mamy dwa przypadki użycia: górny to typowy CRUD, dolny do usługa, np. obliczeniowa. Przypadek pierwszy (górny) dodatkowo korzysta z logiki „Samodzielna logika” tego drugiego PU (integracja dwóch aplikacji/komponentów).
Poniżej dwa ciekawe artykuły, rozwijające powyższe. Pierwszy to tak zwane mikro serwisy, wzorzec traktujący każdą usługę aplikacyjną 9a tym samym przypadek użycia) jako odrębną aplikację, drugi pokazuje jak projektować interfejsy w takich przypadkach.
„Microservices” – yet another new term on the crowded streets of software architecture. Although our natural inclination is to pass such things by with a contemptuous glance, this bit of terminology describes a style of software systems that we are finding more and more appealing. We’ve seen many projects use this style in the last few years, and results so far have been positive, so much so that for many of our colleagues this is becoming the default style for building enterprise applications. Sadly, however, there’s not much information that outlines what the microservice style is and how to do it. (Microservices).
Tell-Don’t-Ask is a principle that helps people remember that object-orientation is about bundling data with the functions that operate on that data. It reminds us that rather than asking an object for data and acting on that data, we should instead tell an object what to do. This encourages to move behavior into an object to go with the data. (TellDontAsk).
Na zakończenie
Analizy biznesowe wymagają oderwania się od technokracji, nie ma czegoś takiego jak dziesiątki przypadków użycia dla jednej faktury, nie ma systemowych przypadków użycia (nawet w specyfikacji UML ich nie znajdziecie), są kompletne (dające jako efekt przydatne produkty) usługi aplikacyjne i korzystający z tych usług aktorzy, w tym inne aplikacje lub komponenty. Dokumentacje zawierające setki przypadków użycia to nieporozumienie, technokratyczni zabójcy projektów. Warto się zastanowić zanim powierzycie analizę i projekt logiki systemu technokratycznemu developerowi… Zapraszam do lektury kolejnego artykułu o zarządzaniu szczegółowością analizy..
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.