Jacek Jakieła

Jacek Jakieła Adiunkt,
Politechnika
Rzeszowska im.
Ignacego
Łukasiewicz...

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Witam!

Poszukuję bibliotekę kształtów pod Visio dla rozszerzeń Erikssona-Penkera do modelowania biznesowego. Czy ktoś z Państwa wie skąd mógłbym sciągnąć taką bibliotekę?

Z góry dziękuję i pozdrawiam!
Piotr Tadeusz B.

Piotr Tadeusz B. właścicel, MGX
Infoservice

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Jeśli chodzi o VISIO nie wiem, ale w iGrafx za pomocą dostępnych bibliotek daje się tworzyć takie diagramy. iGrafx czyta VISIO, więc może warto się przesiąść. Jest też wersja edukacyjna od 175 zł za rok. Można też wypróbować (przez witrynę http://igrafx.com).
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

a co to za notacja?
Jacek Jakieła

Jacek Jakieła Adiunkt,
Politechnika
Rzeszowska im.
Ignacego
Łukasiewicz...

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Jest to zbiór stereotypów języka UML zdefiniowanych w celu modelowania biznesowego. Został on opisany w jednej z pierwszych książek do modelowania biznesowego z wykorzystaniem języka UML. Autorzy definiują proces biznesowy oraz zbiór jego kluczowych charakterystyk. Pokazują istotność modelowania biznesowego z różnych perspektyw (nie tylko implementacji systemu informatycznego) oraz sposoby odwzorowywania modelu biznesowego na specyfikację systemową przygotowaną z wykorzystaniem języka UML. Argumentują, że wartość dodana ich podejścia tkwi w wykorzystaniu tego samego języka zarówno w fazie modelowania organizacji jak i projektowania systemu, co pozwala zminimalizować lukę semantyczną pomiędzy modelem organizacji oraz systemu i dzięki temu lepiej spełnić wymagania.

Pozdrawiam!
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Jacek J.:
Jest to zbiór stereotypów języka UML zdefiniowanych w celu modelowania biznesowego. Został on opisany w jednej z pierwszych książek do modelowania biznesowego z wykorzystaniem języka UML. Autorzy definiują proces biznesowy oraz zbiór jego kluczowych charakterystyk. Pokazują istotność modelowania biznesowego z różnych perspektyw (nie tylko implementacji systemu informatycznego) oraz sposoby odwzorowywania modelu biznesowego na specyfikację systemową przygotowaną z wykorzystaniem języka UML. Argumentują, że wartość dodana ich podejścia tkwi w wykorzystaniu tego samego języka zarówno w fazie modelowania organizacji jak i projektowania systemu, co pozwala zminimalizować lukę semantyczną pomiędzy modelem organizacji oraz systemu i dzięki temu lepiej spełnić wymagania.

Pozdrawiam!

Hm... teraz znalazłem. Osobiście skłaniam się jednak to tezy potwierdzonej w literaturze teorii komunikacji: łatwiej jest dotrzeć z przekazem do adresata gdy posługujemy się od razu językiem odbiorcy niż metodą wymagajacą poprzedzania każdego przekazu nauką języka w jakim ten przekaz nastąpi.

Moim zdaniem modelowanie sfery biznesowej służy do uzgodnienia tej wiedzy z biznesem. Biznes powinien się zamodelować i pokazać ten model. Moim zdaniem modelowanie sfery biznesowej nie służy programistom, jest tylko narzędziem indentyfikacji wymagań i upewnieniu się, że nic nam nie umknęło. Zapis wymagań ma być zrozumiały dla biznesu bo on musi je potwierdzić (w końcu kto tu jest zamawiającym???). Dopiero potem można przystąpić do projektowania systemu spełniającego opisane i zatwierdzone ze zrozumieniem(!) wymagania.

Niewątpliwie nowe stereotypy biznesowe dla UML mają wartość ale chyba tylko dla inżynierów posługujących się UMLem, ale do czego im potrzebny model biznesowy klienta napisany "ich językiem"???

Swego czasu miałem w ręku badanie ankietowe: jaki procent manadżerów sfery biznesowej rozumie modele UML: nikły (<10%). Owszem można podjąć wysiłek by ich tego nauczyć (podobno w TP_SA się to teraz dzieje), ale nie wiem tak na prawdę po co skoro są metody "biznesowe" modelowania.

Prosze spojrzec na to:
http://www.sparxsystems.com/business_process_model.html
i samemu ocenić (prośba do laików UMLowych!) który wariant jest łatwiejszy w percepcji: UML czy BPMN. Brnięcie dalej oznacza moim zdaniem tylko wyważanie otwartych już drzwi: po co za pomocą sematyki UML dublowac dobrze zdefiniowaną notację BPMN?

Tworzenie biznesowych stereotypów w UML (są już także w RUP) to efekt chyba zliżony to tego, gdy człowiekowi z młotkiem w ręku (tu inżynier znający dobrze UML, ale tylko UML) wszystko kojarzy się z gwoździem.

To co piszę to w żadnym wypadku nie jest krytyka a tylko polemika. Osobiście nie widzę tej wartości dodanej w postaci uwspólnienia semantyki (a gdzie syntaktyka tych nowych stereotypów) opisu biznesu i przyszłego systemu. Dlaczego? Bo nie rozwiązuje to w moich oczach w ogóle problemu semiotyki takich modeli i różnych ich odbiorców a to właśnie moim zdaniem jest głównym problemem w projektach analitycznych IT i ich dokumentacjach.

Po drugie kolejna nowa definicja procesu biznesowego jest chyba już nie potrzebna. Po trzecie, jak twierdzi i udowadnia Ian Graham w swej książce "Metody obektowe w teorii i praktyce": proces biznesowy nie jest obiektem z czym zgadzam się w 100%.

PozdrawiamJarosław Żeliński edytował(a) ten post dnia 28.09.07 o godzinie 10:26
Piotr Tadeusz B.

Piotr Tadeusz B. właścicel, MGX
Infoservice

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Nie pozostaje mi nic innego jak zaprosić na forum BPMN ;-)
Jacek Jakieła

Jacek Jakieła Adiunkt,
Politechnika
Rzeszowska im.
Ignacego
Łukasiewicz...

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Hm... teraz znalazłem. Osobiście skłaniam się jednak to tezy potwierdzonej w literaturze teorii komunikacji: łatwiej jest dotrzeć z przekazem do adresata gdy posługujemy się od razu językiem odbiorcy niż metodą wymagajacą poprzedzania każdego przekazu nauką języka w jakim ten przekaz nastąpi.

Przyjmując takie podejście najlepiej byłoby opisać proces z wykorzystaniem języka naturalnego, ale jak wiemy takie rozwiązanie nie jest najlepsze - stad tak duza popularnosc modelowania konceptualnego realizowanego z wykorzystaniem scisle okreslonej graficznej konwencji notacyjnej. Niestety modelujac w ten sposob musimy zapoznac sie z okreslona notacja, ale jak juz sie to uda funkcjonuje ona jako bardzo wygodny i efektywny jezyk komunikacji.
Wydaje mi sie, ze duzo istotniejsza kwestia niz sama notacja jest tak zwany narzucony slownik (ang. controlled vocabulary) czyli zbior pojec, ktore zostaly wybrane w celu modelowania okreslonej dziedziny problemu. Notacja jest moim zdaniem kwestia drugorzedna chociaz prostota i intuicyjnosc to charakterystyki, ktore powinny cechowac dobrane symbole.
Moim zdaniem modelowanie sfery biznesowej służy do uzgodnienia tej wiedzy z biznesem. Biznes powinien się zamodelować i pokazać ten model. Moim zdaniem modelowanie sfery biznesowej nie służy programistom, jest tylko narzędziem indentyfikacji wymagań i upewnieniu się, że nic nam nie umknęło. Zapis wymagań ma być zrozumiały dla biznesu bo on musi je potwierdzić (w końcu kto tu jest zamawiającym???). Dopiero potem można przystąpić do projektowania systemu spełniającego opisane i zatwierdzone ze zrozumieniem(!) wymagania.

To prawda, ale moim zdaniem nie do konca ;-) Nie mozemy zapominac o tym, ze istnieje jeszcze kwestia przejscia od wymagan do funkcjonalnosci tworzonego systemu. Wydaje sie, ze Pan Jarek przyjmuje jedynie perspektywe osoby odpowiedzialnej za przygotowanie modelu organizacji (procesow biznesowych) i w nastepnym 'dyskretnym' przeskoku widzi gotowy system, ktorego wykonanie lezy w gestii informatykow. Jak wynika z praktyki istnieja dwa kluczowe zrodla niepowodzen projektow informatycznych systemow zarzadzania (bo o takich mowimy w kontekscie modelowania biznesowego). Pierwsze to sytuacja, w ktorej system jest tworzony bez fazy modelowania i analizy organizacji. Drugie zrodlo to sytuacja, w ktorej model systemu nie jest wyprowadzany z modelu organizacji poniewaz nie pozwala na to uzyty jezyk modelowania. W tej sytuacji pojawia sie problem 'luki semantycznej', o ktorym juz pisalem. Zminimalizowanie tej luki wplywa na lepsze odwzorowanie modelu organizacji w modelu systemu a co za tym idzie lepsze spelnienie wymagan wobec systemu. Tak wiec przyjmujac perspektywe osoby, ktora sie zajmuje tylko modelowaniem organizacji mozna powiedziec, ze 'Moim zdaniem modelowanie sfery biznesowej nie służy programistom, jest tylko narzędziem indentyfikacji wymagań i upewnieniu się, że nic nam nie umknęło.'. Gdy jednak patrzymy holistycznie i widzimy caly cykl zycia systemu nalezaloby powiedziec, ze 'modelowanie sfery biznesowej jest kluczowe dla powodzenie projektu i działań zespolu projektowego poniewaz model biznesowy stanowi wejscie dla procesu przygotowywania specyfikacji systemowej a zminimalizowanie luki semantycznej jest odpowiedzialne za powodzenie systemu wyrazone w terminach spelnienia wymagan'.
Niewątpliwie nowe stereotypy biznesowe dla UML mają wartość ale chyba tylko dla inżynierów posługujących się UMLem, ale do czego im potrzebny model biznesowy klienta napisany "ich językiem"???

Swego czasu miałem w ręku badanie ankietowe: jaki procent manadżerów sfery biznesowej rozumie modele UML: nikły (<10%). Owszem można podjąć wysiłek by ich tego nauczyć (podobno w TP_SA się to teraz dzieje), ale nie wiem tak na prawdę po co skoro są metody "biznesowe" modelowania.

Prosze spojrzec na to:
http://www.sparxsystems.com/business_process_model.html
i samemu ocenić (prośba do laików UMLowych!) który wariant jest łatwiejszy w percepcji: UML czy BPMN. Brnięcie dalej oznacza moim zdaniem tylko wyważanie otwartych już drzwi: po co za pomocą sematyki UML dublowac dobrze zdefiniowaną notację BPMN?
Tworzenie biznesowych stereotypów w UML (są już także w RUP) to efekt chyba zliżony to tego, gdy człowiekowi z młotkiem w ręku (tu inżynier znający dobrze UML, ale tylko UML) wszystko kojarzy się z gwoździem.

Jest to moim zdaniem naturalne nastepstwo przyjetych zalozen co do ujednolicenia procesow specyfikacji systemow. Przeciez UML jest jezykiem modelowania i narzedziem, ktore mozemy wykorzystywac do modelowania systemow (w szerszym sensie a nie tylko systemow informatycznych).
To co piszę to w żadnym wypadku nie jest krytyka a tylko polemika. Osobiście nie widzę tej wartości dodanej w postaci uwspólnienia semantyki (a gdzie syntaktyka tych nowych stereotypów) opisu biznesu i przyszłego systemu. Dlaczego? Bo nie rozwiązuje to w moich oczach w ogóle problemu semiotyki takich modeli i różnych ich odbiorców a to właśnie moim zdaniem jest głównym problemem w projektach analitycznych IT i ich dokumentacjach.

Co to jest 'problem semiotyki'? wedlug tego co mnie kiedys uczono semiotyka to nauka o jezyku, ktora zajmuje sie tematyka zwiazana z semantyka, syntaktyka oraz pragmatyka. Chyba w tym miejscu uzyto jakiegos skrotu myslowego.

Po drugie kolejna nowa definicja procesu biznesowego jest chyba już nie potrzebna.

Nie twierdzilem, ze jest to nowa definicja. Tak jak pisalem wczesniej kluczem do sukcesu przy modelowaniu jest dobor odpowiednich pojec. Aby zdefiniowac jezyk modelowania nalezy wiec zdefiniowac pojecie procesu w terminach pojec bardziej elementarnych, ktore sa nastepnie uzyte jako pojecia modelowania dziedziny problemu (w tym przypadku procesow biznesowych).
Po trzecie, jak twierdzi i udowadnia Ian Graham w swej książce
"Metody obektowe w teorii i praktyce": proces biznesowy nie jest > obiektem z czym zgadzam się w 100%.

To, jak modelujemy proces wynika z przyjetego podejscia. Wydaje mi sie, ze mozna znalezc rozne reprezentacje procesu. Przykladowo, mozemy modelowac proces jako zbior czynnosci, pomiedzy ktorymi wystepuja zaleznosci. Mozemy traktowac proces rowniez jako klasyfikator dla czynnosci przynalezacych do okreslonej klasy i wowczas instancje takiego klasyfikatora to nic innego jak obiekty. Mozemy modelowac proces, ktory jest konfiguracja rol. To, ktore podejscie jest najlepsze jest sprawa dyskusyjna. Oczywiscie nic nie stoi na przeszkodzie aby Pan Jarek zgadzal sie Ianem Grahamem w 100%, ze proces biznesowy to nie obiekt (zycie jednak pokazuje, ze warto unikac stwierdzen wypowiadanych ze 100% pewnoscia).

Pozdrawiam
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Semiotyka to nauka o tym jak odbierane są (rozumiane) symbole w danym kontekście. jest to termin bliższy komunikacji ale czym innym jest modelowanie. Semantyka i syntaktyka to definicje zaś semiotyka to subiektywne postrzeganie uzależnione od doświadczeń osoby patrzacej i jej wiedzy. Tak więc prostokącik na papierze może byc procesem ale zależnie od tego czy patrzyy na niego informatyk czy audytor ISO postrzeganie tego samego prostokąta umownie nazwanego procesem (tu semantyka) i uznanie, że musi wskazywać na następny proces lub produkt (tu syntaktyka) wcale nie oznacza, że każdy jednakowo dostrzeże tu taki sam sens procesu i jego wnoszonej wartości.

Po drugie notacje takie jak BPMN w pewnym sensie sa "samoopisujace się", dlatego zrozumiałość diagramów dla osoby nie znającej notacji jest znacznie wyższa dla BPMN niż UML (tu moje doświadczenia z odbiorcami na bazie kilkudziesięciu projektów).

Co do modelowania zajmuję się modelami biznesowymi oraz modelami obiektowymi analizy obiektowej a także modelawi semantycznym danych (np. ERD) i komponentów. Ogólnie tylko nie koduję. Zgadzam się z tym, że ważna jest cała droga od biznesowych oczekiwań do technicznych założeń projektu. Ale tu narzędzia i ich skuteczność moim zdaniem doskonale opisuje SOA i zalecane notacje: BPMN do obszaru procesów bieznesowych, UML do obszaru analizy obiektowej i projektu systemu...

W kazdym razie jestem zwolennikiem tej ścieżki :)

UML jako doskonałe narzędzie modelowania wyników analizy obiektowej (w końcu do tego ta notacja powstała) średnio się moim zdaniem sprawdza jako narzędzie opisu nieobiektowych sfer hierarchicznego i procesowego biznesu nastawionego na abstrakcyjne pojęcie wartości (rynkowej) niedefiniowalne według mnie obiektowo.

w kwestii Iana Grahama napisałem,że zgadzam sie w 100% a nie że jest to 100% prawda..:) ... ot, własnie semiotyka ;) .. obiektem jest w teorii analizy obiektowej odwzorowanie realnego bytu a wartość nie jest bytem a cechą (bytem jest bułka, 20 groszy to jej wartość a nie drugi byt, w teori tworząc klasę bułka jej wartość będzie atrybutem)

Wracając do głownego wątku, nie znalazłam gotowców dla Visio ale Visio można dodac stereotypy wiec zawsze można rozszerzyć notację. Jednak mała uwaga ode mnie: notacja to sumbole (tu prostokąty), stereotypy tak na prawdę są elementami właśnie semiotyki: mówią jak należy rozumieć dany prostokącik.Jarosław Żeliński edytował(a) ten post dnia 30.09.07 o godzinie 12:50
Jacek Jakieła

Jacek Jakieła Adiunkt,
Politechnika
Rzeszowska im.
Ignacego
Łukasiewicz...

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

[author]Jarosław
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Jacek J.:
semiotyką. W procesie modelowania używamy bowiem języka modelowania, który ma określone symbole (w naszym przypadku symbole graficzne) i reguły tworzenia bardziej złożonych struktur (diagramów), znaczenie tych symboli definiuje z kolei semantyka. Tak więc jak Pan widzi semiotyka jako nauka o znakach, ich rodzajach, właściwościach i funkcjach, obejmująca jako swe gł. dyscypliny: semantykę, syntaktykę i pragmatykę (patrz słownik wyrazów obcych) ma z modelowaniem dużo wspólnego.

Za słownikiem więc:

semantyka
1. «dział językoznawstwa, którego przedmiotem jest analiza znaczeń wyrazów»
2. «dział semiotyki zajmujący się badaniem związków, jakie zachodzą między wyrażeniami języka a przedmiotami, do których się one odnoszą»

Sematyka to po portu słowniki, w notacjach semantyka to pary: symbol-przypisane znaczenie

syntaktyka
1. zob. składnia w zn. 1.
2. «dział semiotyki badający wzajemne stosunki i właściwości budowy wyrażeń języka w procesie porozumiewania się ludzi»

Czyli inaczej mówiśc jest to gramatyka, zestaw reguł opisujacych dopuszczalne połączenia znaków/symboli i znaczenie tych połaczeń.

semiotyka
1. «ogólna teoria znaku w procesie porozumiewania się ludzi»

Czyli to jak ludzie rozumieją znaki, z którymi się stykają.

(definicje: słownik jezyka polskiego PWN).

No właśnie chodzi o to, że nie powinno tak być jak Pan pisze. To, jak jest interpretowany określony model i jego elementy składowe powinno wynikać nie z doświadczenia osoby, która go wykorzystuje tylko z precyzyjnie zdefiniowanej semantyki jęzkyka modelowania.

Niezależnie od tego co powinno byc praktyki teorii komunikacji bazuja na badanich i nie zależnie od tego co ja czy Pan o tym sądzimy ja z pokorą przyjmuję wyniki badań, także własnych doświadczeń.
Stwierdzenie 'umownie nazwanego procesem (tu semantyka)' nie jest prawdziwe ponieważ umowne nazwanie prostokąta procesem nie jest jego semantyką.

No tu niestety uważam, że jest: jeżeli dla danej notacji definiuję: prostokąt oznacza proces to jest to semantyka czyli słownik symboli. Patr zpowyżej: para symbol-znaczenie to właśnie sematyka.

Proces jest pojęciem modelowania, które może być oznaczane np. przez prostokąt (tutaj symbol), który niesie określone znaczenie. Z danym pojęciem związana jest również jego intensja i ekstensja. Intensja to mówiąc w uproszczeniu test pozwalający stwierdzić, że określony byt w dziedzinie problemu daje się lub nie sklasyfikować z wykorzystaniem danego pojęcia. Ekstensja to z kolei zbiór wszystkich bytów, które przeszły test i mogą być denotowane przez symbol wybrany dla określonego pojęcia. Dopiero po dokładnym zrozumieniu trójkąta Ogdena wszystko staje się jasne. Zupełnie inną

Trójkąt ten nie oddaje pojęc abtrakcyjnych.... a pojęcie procesu do nich należy.

kwestią jest to o czym Pan pisze, czyli intuicje związane z określonymi symbolami. Tutaj rzeczywiście dla jednej osoby określona notacja może być bardziej intuicyjna a dla innej mniej. Jest to kwestia o strategicznym znaczeniu dla twórcy języka modelowania.

Owszem i do grupy docelowej będącej adresatem tych modeli...
Mówimy o dwóch różnych kwestiach. Pan pisze o SOA jako o architekturze a ja pisałem o procesie prześcia pojęciowego z modelu organizacji na model systemu informatycznego. Jest to powszechnie znany problem określany terminem 'luki semantycznej'.

SOA jest moim zdaniem takim przejsciem: od opsiu procesó bzinesowych do definicji usług systemowych, obie te sfery są odpowiednio modelowane: model procesów i model implementacji usług wspierajacych te procesy. Pierwsze z pomocą BPMN drugie z pomocą UML.
Pogubiłem się. Najpierw musimy zdefiniować cel modelowania. Wydawało mi się, że cały czas dyskutujemy o modelowaniu biznesowym w kontekście projektowania informatycznych systemów zarządzania.

I tu chyba tkwi nieporozumienie: dla mie celem modelowania biznesowego jest opisanie sfery biznesowej, jej zależności i specyfiki danej organiozacji. Specyfika modeli biznesowych operującyh pojęciem procesu jest łańcuch wartości dodanej (tu wewnątrzny). Każdy proces w modelu jest dekomponowany na łańcuch czynności. Te ostatnie poddawane są analizie, ktore z tych czynności wesprzeć inforatyka i jak. procesem jest np. wytworzenie oferty, proces ten składa się z czynności np. analiza zapytania, wykonanie listy produktów i ich wycena, określenie warunków dostawy, pzrekazanie przełożónymu do zatwierdzenia, wysłanie. Proces nie ale wybrane czynności można uznac za warte infortyzacji i potraktowac jako przypadki użycia. Daleszy bieg juz znamy.

Bo jeżeli tak to podejście obiektowe bardzo dobrze sprawdza się przy modelowaniu tak zwanych systemów złożonych a każda organizacja bez wątpienia jest takim systemem. Przez podejście obiektowe rozumiem oczywiście pewien 'mindset' a nie tylko programowanie obiektowe. Jeżeli zapozna się Pan z charakterystyką podstawowych cech systemów złożonych to od razu stanie się jasne, że tzw. "mindset obiektowy" daje nam same korzyści przy modelowaniu.

Owszem, orgaznizacje można modelować obiektowo i robi sie to (modele pojęciowe, diagramy klas, ERD np. w celu zaprojektowania baz danych) ale modelujemy tą metodę byty z jakich się składa organizacja a nie to w jaki spsob tworzy ona wartosc bo to określa model biznesowy w rozumieniu marketingowym, tu ząs raczej model łańcucha wartości M.E.Portera ma zastosowanie.
w kwestii Iana Grahama napisałem,że zgadzam sie w 100% a nie że jest to 100% prawda..:) ... ot, własnie semiotyka ;) .. obiektem jest w teorii analizy obiektowej odwzorowanie realnego bytu a wartość nie jest bytem a cechą (bytem jest bułka, 20 groszy to jej wartość a nie drugi byt, w teori tworząc klasę bułka jej wartość będzie atrybutem)
...nie wiem o co Panu chodzi...powszechnie wiadomo, że definiując określoną klasę obiektów musimy zwrócić uwagę na 3 kluczowe elementy stan opisywany przez atrybuty, tożsamość oraz zachowanie opisane w metodach.

No i co w zwiazku z tym? Proces jako abstrakcja tworzenia wartości dodanej nic tu nie ma do klasy.

No właśnie chodzi o to, że stereotypy są mechanizmem rozszerzeń semantyki określonego elementu bez możliwości zmiany syntaktyki, a mi chodzi o symbole o kształtach zdefiniowanych przez Erikssona-Penkera. Enterprise Architect ma zdefiniowaną tę notację ale będę prowadził zajęcia w miejscu, gdzie nie mają licencji na EA i stąd pytanie o visio.

No Visio nie....:( ale symbole takie są dostępne w PowerPoincie :)

w literaturze spotykam sie z podejćiem bliskim Pana wersji jak i bliskim mojej, nie uzurpuje sobie absolutnie prawa do prawdy. Dla UML to jedne z wielu narzędzi, które traktuję na równi z innymi. Planowane jest podobno wąłczenie BPMN doUML, w końcu UML to tak na prawde, zlepek metod, wiele notacji a nie jedna. Ja w swojej pracy naukowej uważam, że podejscie obiektowe ma swoje ograniczenia.Jarosław Żeliński edytował(a) ten post dnia 30.09.07 o godzinie 18:21
Jacek Jakieła

Jacek Jakieła Adiunkt,
Politechnika
Rzeszowska im.
Ignacego
Łukasiewicz...

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Za słownikiem więc:

semantyka
1. «dział językoznawstwa, którego przedmiotem jest analiza znaczeń wyrazów»
2. «dział semiotyki zajmujący się badaniem związków, jakie zachodzą między wyrażeniami języka a przedmiotami, do których się one odnoszą»

Sematyka to po portu słowniki, w notacjach semantyka to pary: symbol-przypisane znaczenie

syntaktyka
1. zob. składnia w zn. 1.
2. «dział semiotyki badający wzajemne stosunki i właściwości budowy wyrażeń języka w procesie porozumiewania się ludzi»

Czyli inaczej mówiśc jest to gramatyka, zestaw reguł opisujacych dopuszczalne połączenia znaków/symboli i znaczenie tych połaczeń.

semiotyka
1. «ogólna teoria znaku w procesie porozumiewania się ludzi»

Czyli to jak ludzie rozumieją znaki, z którymi się stykają.

(definicje: słownik jezyka polskiego PWN).

No i napisal Pan dokladnie to co ja tylko za pomoca definicji slownikowych - calkowicie sie zgadzam z tymi definicjami. Nie zmienia to faktu, ze kwestie syntaktyki, semantyki i pragmatyki
sa poprzez jezyk modelowania scisle zwiazane z modelowaniem ;-).
No właśnie chodzi o to, że nie powinno tak być jak Pan pisze. To, jak jest interpretowany określony model i jego elementy składowe powinno wynikać nie z doświadczenia osoby, która go wykorzystuje tylko z precyzyjnie zdefiniowanej semantyki jęzkyka modelowania.

Niezależnie od tego co powinno byc praktyki teorii komunikacji bazuja na badanich i nie zależnie od tego co ja czy Pan o tym sądzimy ja z pokorą przyjmuję wyniki badań, także własnych doświadczeń.
Stwierdzenie 'umownie nazwanego procesem (tu semantyka)' nie jest prawdziwe ponieważ umowne nazwanie prostokąta procesem nie jest jego semantyką.

No tu niestety uważam, że jest: jeżeli dla danej notacji definiuję: prostokąt oznacza proces to jest to semantyka czyli słownik symboli. Patr zpowyżej: para symbol-znaczenie to właśnie sematyka.

Chodzilo mi o to, ze nazwanie symbolu procesem to troche za malo. To jest poki co dobranie pary symbol-pojecie. A z pojeciem zwiazane jest okreslone znaczenie - semantyka.

Trójkąt ten nie oddaje pojęc abtrakcyjnych.... a pojęcie procesu do nich należy.

To nie ma znaczenia, jezeli wyjasni Pan kiedy cos jest procesem wowczas moze Pan klasyfikowac co jest a co nie jest procesem.
Owszem, orgaznizacje można modelować obiektowo i robi sie to (modele pojęciowe, diagramy klas, ERD np. w celu zaprojektowania baz danych) ale modelujemy tą metodę byty z jakich się składa organizacja a nie to w jaki spsob tworzy ona wartosc bo to określa model biznesowy w rozumieniu marketingowym, tu ząs raczej model łańcucha wartości M.E.Portera ma zastosowanie.

Wiekszosc moich dotychczasowych komentarzy wynikala z tego, ze probowalem uporzadkowac pewne kwestie, o ktorych Pan pisal. Ta Pana wypowiedz jest przykladem tego o co mi do tej pory chodzilo. Pisze Pan np. 'orgaznizacje można modelować obiektowo i robi sie to (modele pojęciowe, diagramy klas, ERD np. w celu zaprojektowania baz danych) I modele pojeciowe to klasa modeli do ktorych naleza nie tylko modele podejscia obiektowego ale rowniez analizy strukturalnej, np. diagram hierarchii funkcji jest również modelem pojęciowym ale nie ma nic wspólnego z podejściem obiektowym - Pan podaje je jako przyklad modeli obiektowych; ERD to typowy przedstawiciel podejscia strukturalnego a nie obiektowego etc.

w literaturze spotykam sie z podejćiem bliskim Pana wersji jak i bliskim mojej, nie uzurpuje sobie absolutnie prawa do prawdy.

Ja rowniez nie ;-). Chodzi mi tylko o pewien porzadek pojeciowy.
UML to jedne z wielu narzędzi, które traktuję na równi z innymi. Planowane jest podobno wąłczenie BPMN doUML, w końcu UML to tak na prawde, zlepek metod, wiele notacji a nie jedna. Ja
w swojej pracy naukowej uważam, że podejscie obiektowe ma swoje ograniczenia.

Ja rowniez uwazam, ze podejscie obiektowe nie jest 'srebrna kula' ale myslenie w kategoriach obiektowych w procesie konceptualizacji dziedziny problemu czy to przy modelowaniu biznesowym, czy systemu informatycznego jest o wiele bardziej naturalne niz np. podejscie strukturalne.

Pozdrawiam!
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Jacek J.:
Ja rowniez uwazam, ze podejscie obiektowe nie jest 'srebrna kula' ale myslenie w kategoriach obiektowych w procesie konceptualizacji dziedziny problemu czy to przy modelowaniu biznesowym, czy systemu informatycznego jest o wiele bardziej naturalne niz np. podejscie strukturalne.

No to mam wrażenie, że teoria komuniakcji ma jeszcze wiele do zrobienia :).

W kwestii modelowania i języka diagramów jest to chyba kwestia ortodoksji stosowanych pojeć. Ja jestem (niestety:)) zwolennikiem w pewnym zakresie podejścia ortodoksyjnego w rozumieniu takim: jeżeli w geometrii euklidesowej przyjmuje się aksjomat: przez dwa punkty przechodzi tylko jedna prosta i jest on podstawą całej geometrii to ja uważam, że skoro można dowolną figurę narysować cyrklem i linijką (co udowodniono) to znaczy, że spójny i kompletny zestaw symboli (semantyka) języka (notacji) powinien pozwolic zapisać (i pokazać) dowolne zjawisko danej domeny. Stąd mój opór do tworzenia stereotypów bo to według mnie coś takiego jak wzorniki wielokątów dla geometrów, którzy nie radzą sobie z ich rysowaniem linijka i cyrklem. Nawet jeżeli wzornik oszczędza czas to powoduje, że można narysować pięciokąt bez zrozumienia jak jest on skonstruowany.
Jacek Jakieła

Jacek Jakieła Adiunkt,
Politechnika
Rzeszowska im.
Ignacego
Łukasiewicz...

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

No to mam wrażenie, że teoria komuniakcji ma jeszcze wiele do zrobienia :).

Zgadzam sie w 100% ;-).
W kwestii modelowania i języka diagramów jest to chyba kwestia ortodoksji stosowanych pojeć. Ja jestem (niestety:)) zwolennikiem w pewnym zakresie podejścia ortodoksyjnego w rozumieniu takim: jeżeli w geometrii euklidesowej przyjmuje się aksjomat: przez dwa punkty przechodzi tylko jedna prosta i jest on podstawą całej geometrii to ja uważam, że skoro można dowolną figurę narysować cyrklem i linijką (co udowodniono) to znaczy, że spójny i kompletny zestaw symboli (semantyka) języka (notacji) powinien pozwolic zapisać (i pokazać) dowolne zjawisko danej domeny. Stąd mój opór do tworzenia stereotypów bo to według mnie coś takiego jak wzorniki wielokątów dla geometrów, którzy nie radzą sobie z ich rysowaniem linijka i cyrklem. Nawet jeżeli wzornik oszczędza czas to powoduje, że można narysować pięciokąt bez zrozumienia jak jest on skonstruowany.

No i znowu rozminelismy sie :( (no chyba, ze to jest Pana ogolna opinia a nie odpowiedz na moje stwierdzenie). Ja pisalem o konceptualizaji, ktora ma scisle, formalnie zdefiniowane znaczenie w kontekscie modelowania wiedzy a Pan o stereotypach :-). Ja rowniez uwazam, ze stereotypy to cos, czego nie powinno sie naduzywac. To, ze czasem modelarz musi z nich skorzystac podczas pracy z takim jezykiem jak UML wynika z faktu, ze UML zostal zaprojektowany przede wszystkim jako jezyk modelowania systemow informatycznych, a jest wykorzystywany w roznych kontekstach.

Pozdrawiam!
Jarosław Żeliński

Jarosław Żeliński Analityk i
Projektant Systemów

Temat: Rozszerzenia Erikssona-Penkera pod Visio...

Jacek J.:
rowniez uwazam, ze stereotypy to cos, czego nie powinno sie naduzywac. To, ze czasem modelarz musi z nich skorzystac podczas pracy z takim jezykiem jak UML wynika z faktu, ze UML zostal zaprojektowany przede wszystkim jako jezyk modelowania systemow informatycznych, a jest wykorzystywany w roznych kontekstach.

Ano ja właśnie głównie o tym... bo to mnie kłuje ;)

jz



Wyślij zaproszenie do