Nowoczesne zakupy?

Dziś znowu będzie o zakupach. Temat jak najbardziej bliski każdemu. Poszedłem na zakupy z myślą zakupu letniej części garderoby. Pierwszy, drugi, trzeci sklep… Patrzę na rozmiarówkę 32, 33, 34, 36, 38 itd. i się zastanawiam co oznacza? Przymierzam różne rozmiary w różnych sklepach i doświadczenia różne, żadnej logiki – za ciasne, za krótkie, za szerokie. A na samych spodniach żadnej informacji co dokładnie oznacza rozmiar, że typ jest regular, czy slim, jaka jest nogawka, jaki stan. O cenach już nie wspomnę.

Wchodzę do ostatniego sklepu, po drodze myśląc, nie mogłoby być tak jak z pozostałymi spodniami – szerokość/długość i informacjo stanie, nogawkach itp., i tu niespodzianka. Jako jedyny sklep, na spodniach podawał rozmiary w standardowej formie. Niby jest jakiś standard rozmiarówki, ale… Ile czasu zaoszczędziłbym trafiając bezpośrednio do tego sklepu lub/i każde ze spodni było oznaczone w podobny sposób? Czy tak trudno zamieścić jakąś informację na półce albo informację o długości np. nogawek (np. jest taka sama na osoby o wzroście)? Albo trzymać się tego samego rozmiaru, przy danym numerku? W jednym sklepie spodnie rozmiaru np. 34 miały inne „rzeczywiste” wymiary.

Poszukałem informacji w Internecie i znalazłem pewne wytyczne, co może oznaczać, ale nie były to jedyne wytyczne. Czyli może muszę najpierw sprawdzić w Internecie, a potem pójść do zwykłego sklepu? A może to jest sposób na „nowoczesne zakupy” (diagram w BPMN) ? 1) Znajdź rzecz, 2) Sprawdź producenta. 3) Wyjmij komórkę i uruchom wyszukiwarkę. 4) Wyszukaj rozmiarówkę tego producenta 5) sprawdź wymiary i 6) zadecyduj co z towarem w ręce.

Wszyscy szczęśliwi, sklep, producenci sprzętu elektronicznego orazs sieci komórkowej. Wiem, pierwsza myśl, to, że przesadziłem. Można zawiesić w sklepie rozmiarówkę, np. w przymierzalni lub na półce, co nie oznacza wcale, że byłaby poprawna, jak w przykładzie z ceną, o którym kiedyś pisałem. A co w sytuacji, gdy jest kolejka? Można spytać obsługę, ale można usłyszeć, że rozmiar jest standardowy. Może być także niedostępna. A co o tym myślą czytelnicy? Ja ostatecznie nic nie kupiłem.

Reklama

Specjalistyczny pośrednik

Ponad roku, przy okazji omawiania wzorców „Fire and Forget” oraz „Request-Response” posłużyłem się przykładem procesu ETL. Jednym z etapów realizacji tego procesu, jest wyciąganie (ang. Extract) danych. Wskazałem przykład zastosowania wzorca „Request-Response” (Pytanie – Odpowiedź) oparty na odpytywaniu bazy danych (dokładnie DBMS, tj. Systemu Zarządzania Bazą Danych) o dane/informacje/status i zwracanie przez nią stosownej informacji. Były to sprawdzenie dostępności bazy (DB), pytanie o wielkość danych (WD) i pobieranie kolejnych rekordów danych (DZ – dane zapytania). Takie działania mogą się odbywać poprzez bezpośrednie zapytania w języku SQL. Fragment oznaczony jako „bez wzorca” na diagramie poniżej przedstawia takie bezpośrednie odpytania.

Załóżmy jednak, że mamy odbytać kilka baz i powiązać dane ze sobą. Chcielibyśmy równocześnie uniknąć sytuacji namierzania się na każdą bazę osobno, identyfikowania jej strukury, a chcielibyśmy przekazać żądanie: sprawdź, pobierz, zapytaj. W takiej sytuacji między procesem Extract a poszczególnymi bazami danych można umieścić narzędzie pośredniczące, które wykona określone operacje i odpowiednio rozdzieli zadania po DBMS poszczególnych baz źródłowych.

W takim celu można zastosować wzorzec projektowy Fasada (ang. Facade), który zmniejszy liczbę połączeń i zależności między systemami. Wiąże się to utworzeniem „pośrednika” przyjmującego żądania i wysyłającego je do odpowiednich wykonawców. Sytuację taką prezentuje powyższy diagram w BMPN w części „wzorzec”.

Zaletą jest to, że mamy jeden interfejs, który można wykorzystać w różnych procesach, bez konieczności ingerowania w systemy źródłowe. Modyfikując połączenie między pośrednikiem a bazą (np. przeniesienie w inne miejsce, inna konfiguracja, sposób zapytania) modyfikujemy je tylko w jednym miejscu, bez konieczności zmiany procesów wywołujących. Takie rozwiązania są stosowane w implementacji systemów opartych o usługi (SOA).

Zadanie: Reguła biznesowa

W artykule „A New Information Systems Paradigm: What does a Business Analyst Needs to Know?” na ModernAnalyst.com autorzy przybliżają czytelnikom serwisu ewolucję systemów informacyjnych i sposobu ich tworzenia. Przechodzą od prostych rozwiązań, wymagających więdzy po stronie szeroko pojętego biznesu nt. choćby tworzenia zapytań SQL, aż do rozwiązań nowoczesnych, rozbudowanych z implementacją systemów klasy workflow, wspartych silnikami baz danych i nie tylko.

Jednym z elementów, które poruszają, jest zarządzanie regułami biznesowymi i tworzenie systemów wspierających ich definiowanie, przechowywanie oraz wykonywanie. Tzw. BRMS (Business Rules Management System, czyli System Zarządzania Regułami Biznesowymi) są nieodłącznym elementem tworzonych systemów. Powstają one trochę przez analogię do wspomnianych jakiś czas temu przeze mnie BPMS (Business Process Management System, czyli System Zarządzania Procesami Biznesowymi) czy DBMS (Data Base Management System, czyli System Zarządzania Bazą Danych).
Załóżmy, że mamy następującą regułę biznesową, wykorzystywaną w korespondencji wysyłanej z systemu:

• Płeć: mężczyzna → powitanie: Pan;
• Płeć: kobieta oraz Stan: mężatka → powitanie: Pani;
• Płeć: kobieta oraz Stan: wolny → powitanie: Panna;

Reguła jest bardzo prosta i to co się rzuca w oczy, w przypadku pierwszej reguły, stan cywilny nie ma znczenia. Powyższą regułę można byłoby w łatwy sposób zapis w bazie danych – jako 3 wiersze, z 3 atrybutami.

Powyższy artykuł przypomina, że w celi opisu takich reguł powstawała Decision Model Notation (DMN) – notarcja modeli decyzyjnych. Artykuł nie rozwija tego tematu, ale w Internecie można znaleźć informacje. W szczególności na stronach brcommunity.com wskazują, że definiowanie reguł jest związane z ich wielokrotnym użytkowaniem. Jest to silne wsparcie dla osób projektujących proces, za pomocą notacji BPMN 2.0, gdzie została przygotowana opcja „BusinessRuleTask”. Służy ona do wołania o wynik poszczególnych reguł. Od notacji BPMN można przejść do postaci wykonawczej poprzez zastosowanie BPML. Przykład zastosowanie tego typu zadania – BusinessRuleTask- został wskazany na powyższym diagramie BPMN. Zadania tego typu oznaczane są przez symbol pogrubionej „tabelki”.

W biznesie można spotkać się z dwoma typami reguł biznesowych – reguły ogólne, mające zastosowanie do wielu procesów, mających miejsce w różnych miejscach orgranizacji oraz reguły szczególne, wykorzystywane w danym procesie biznesowym. Opis reguł biznesowych jest ważnym elementem, który pozwala na zrozumienie działania procesu oraz okoliczności jego wykonania. Często są to tabele lub diagramy drzewiaste ze względu na różnorodnosć powiązań. Samo wykonanie reguł biznesowych może zostać zaimplementowane w różnych sposób – może to być np. tabela bazy danych, na której wykonywane są zapytania SQL a wynikiem jest wynik reguły. Na konferencjach często można usłyszeć w jaki sposób implementować reguły i w jakich sytuacjach. Równocześnie zwracana jest uwaga, aby sposób ich definiowania i przechowywania pozwalał na ich późniejsze aktualizowanie bez konieczności zmiany systemu odwołującego się.

Wzorcowa pizza

Wyobraźmy sobie, że jesteśmy w pizzerii i mamy ochotę zjeść pizzę. Nie wiemy jeszcze jaką, ale będzie to pizza. Można powiedzieć, że danie to jest pewien sposób abstrakcyjne, bliżej nieokreślone, do momentu, gdy zapoznamy się z menu i dowiemy się jakie są możliwości. Spośród rodzajów pizzy, np. Amerykańska, Wegetarianska, Hawajska, Rzeznicka itp., będziemy wybierać konkretną na podstawie jej składników, które w niej będą. Przeglądamy menu i decydujemy się na konkretne składniki – na przykład Ser, Szynka, Salami lub Ananans, Ser itd.

Wymienione składniki też są w pewien sposób abstrakcyjne, nie wiemy jak będą ułożone, ile ich będzie, jak będą duże, ale wiemy, że będzie to określony składnik.
Mamy więc od strony Klienta: wybraną pizzę składająca się z wymienionych składników.
Restauracja wie jaka pizza z jakich się składa elementów, ale dopiero w momencie przygotowania nastąpi ich wybór.

Powyższy przykład, opierając się na wyborze abstrakcyjnych składników z jednej strony, a dostarczenia konkretnych produktów z drugiej, można przedstawić za pomocą wzorca projektowego fabryka abstrakcyjna (ang. abstract factory).
Wzorzec ten składa się z elementów, zaprezentowanych na powyższym przykładowym diagramie UML:

• Fabryka abstrakcyjna (ang. abstract factory) – interfejs dla klienta do wyboru konkretnych rodzajów pizzy. Na diagramie oznaczony jako „AF”.
• Fabryka konkretna (ang. concrect factory) – określa elementy konieczne do stworzenia danej pizzy z elementów składowych. Na diagramie oznaczony jako „CF”.
• Produkt abstrakcyjny (ang. abstract product) – interfejst dla klienta do wyboru rodzaju składników pizzy. Na diagramie oznaczony jako „AP”.
• Produkt (ang. product) – konkretna realizacja oczekiwana przez klienta – dany składnik pizzy. Na diagramie oznaczony jako „P”.
• Klient (ang. client) – używa powyższych elementów (wybiera pizzę, składniki). Na diagramie oznaczony jako „C”.

Klient inicjuje wybór pizzy, wybierając jej składniki, fabryka tworzy, w zależności od wybranej pizzy, odpowiednie zestawienie składników. Te zależności obrazują strzałki użytkowania (ang. uses) elementów na diagramie.

Czynności dla wartości procesu

Odbierając zwrot jednej z przesyłek na poczcie, przypomniałem sobie o jednym z zadań, które kiedyś musiałem wykonywać. Co tydzień, musiałem „dostarczyć” przesyłkę z jednego końca miasta na jego drugi koniec. Przesyłka miała dotrzeć tego samego dnia, do godziny 12, tak, aby obiorca (Klient) mógł wykorzystać dane z przesyłki w swoich działaniach. Proces, bo o nim można mówić, wyglądał jak na poniższym diagramie:

Zastanówmy się jak elementy tego procesu wpływają na wartość dostarczaną Klientowi. Klient płacił miesięcznie określony ryczał za dostarczony materiał – stała cena. Z jego puntku widzenia istotne były elementy: termin dostarczenia, zawartość oraz cena, którą płaci – co przypomina omawiany wczesniej trójkąt ograniczeń: zakres-cena-czas. Dostarczona przesyłka miała dla nego określoną wartość, mógł ją dalej wykorzystać w zaplanowanych ramach czasowych. Nie było dla niego istotne, kto i w jaki sposób dostarczy przesyłkę.

Z kolei dostawca, rozliczał się z kurierem niezależnie. Planował przygotowanie przesyłki. Ustał termin odbioru i dostarczenia z kurierem, biorąc pod uwagę takie elementy jak wielkość przesyłki, okres miesiąca/roku, pogodę, informację o natężeiu ruchu czy dostępność kuriera.

Do czego zmierzam? Chciałbym zobrazować na tym prostym przykładzie, 3 rodzaje działań rozróżnianych przez literaturę, decydujących o wartości procesu dla klienta i mogących go ewentualnie przekonać do zaplaty więcej za efekt procesu.
Te 3 rodzaje działań to:

• czynności dodające, zmieniające wartość (na niebiesko) – np. terminowa dostawca i przygotowanie przesyłki,
• czynności bez wartości dodanej (na zielono) – np. rozliczenia z kurierem, z klientem,
• czynności umożliwiające wzrost wartości (na żółto) – np. przygotowanie materialów na przesyłkę z wyprzedzeniem, rezerwacja kuriera, co może ewentualnie przyczynić się do skrócenia czasu dostawy. Inny przykład to przekazanie przesyłki kurierowi.