Temat: Architektura oprogramowania 4+1

Joanna Usidus:

Jerzy N.:

Joanna Usidus:

Jerzy N.:
A które elementy, jeśli można wiedzieć, używałaś przy modelowaniu struktury organizacyjnej firmy ?

W poprzedniej wersji EA - diagramu klas z dziedziczeniem :) W obecnej można użyć też diagramu Org Chart, który posiada cztery elementy:

-Role
i linki:
-Reports to (Vertical Tree)
-Reports to (Lateral Tree)
-Communicates with.

Rozumiem, że na diagramie klas przedstawiałaś aktorów ?

Nie, mówię o strukturze organizacyjnej firmy - czyli podziale na departamenty, komórki itp. - które modelowałam jako zwykłe klasy.

Ciekawe ??? A co sobie te komórki dziedziczyły, hę ???

Temat: Architektura oprogramowania 4+1

Nie, mówię o strukturze organizacyjnej firmy - czyli podziale na departamenty, komórki itp. - które modelowałam jako zwykłe klasy.

Ciekawe ??? A co sobie te komórki dziedziczyły, hę ???

Jeśli diagramem klas modelujemy strukturę organizacyjną, można modelować osoby (role, nazwa stanowiska) które dziedziczą uprawnienia (przełożony dziedziczy uprawnienia podwładnego, dodatkowo ma dodatkowe cechy, których nie ma jego podwładny) w podobny sposób zorganizowane są bazy LDAP wykorzystywane jako lista osób i uprawnień w systemie...

Temat: Architektura oprogramowania 4+1

Jerzy N.:
No tak ... opis architektury oprogramowania wydaje się niezbędny...
W jaki sposób (w jakiej notacji ?) opisujecie architekturę oprogramowania ?
Ja zazwyczaj używam UML-a, ale z dziesięc lat temu opisywałem ją za pomocą DFD (ERD), czy też zwykłych schematach blokowych.

no i właśnie dotknęliśmy głównego tematu wątku :)

osobiście, w zależności od poziomu abstrakcji i perspektywy z której "patrzy się" na system/oprogramowanie używam różnych notacji - uzależniam to od charakterystyki udziałowca, docelowego odbiorcy.

tak więc w moim przypadku DFD, ERD i klasyczne, proste schematy blokowe sprawdzają się doskonale w komunikacji ze społecznością biznesową (czasem UML);
UML-owe diagramy komponentów czy Deployment diagram są czytelne dla ludzi z Network & Infrastructure;

nie umieram jednak za UML'a czy inną formę przekazu do której jest bardziej lub mniej przywiązany. akceptuję każdą inną metodę, notację, która jest prosta, czytelna i zrozumiała;

Temat: Architektura oprogramowania 4+1

Roman Frania:

Jerzy N.:
No tak ... opis architektury oprogramowania wydaje się niezbędny...
W jaki sposób (w jakiej notacji ?) opisujecie architekturę oprogramowania ?
Ja zazwyczaj używam UML-a, ale z dziesięc lat temu opisywałem ją za pomocą DFD (ERD), czy też zwykłych schematach blokowych.

no i właśnie dotknęliśmy głównego tematu wątku :)

osobiście, w zależności od poziomu abstrakcji i perspektywy z której "patrzy się" na system/oprogramowanie używam różnych notacji - uzależniam to od charakterystyki udziałowca, docelowego odbiorcy.

tak więc w moim przypadku DFD, ERD i klasyczne, proste schematy blokowe sprawdzają się doskonale w komunikacji ze społecznością biznesową (czasem UML);
UML-owe diagramy komponentów czy Deployment diagram są czytelne dla ludzi z Network & Infrastructure;

nie umieram jednak za UML'a czy inną formę przekazu do której jest bardziej lub mniej przywiązany. akceptuję każdą inną metodę, notację, która jest prosta, czytelna i zrozumiała;

Czy stosujesy DFD do obiektowych projektów ?

Temat: Architektura oprogramowania 4+1

Osobiście nei jestem zwolennikime stosowania elementów metod strukturalnych w "projektach obiektowcyh" - rozumiem, ze masz tutaj na mysli OOA/OOD/OOP razem wzięte;

ciężko też nazwać "projektami obiektowymi", projekty w ktorych biorę udział. DFD - otrzymuję przeważnie "na wejście" mojej pracy - jako produkt pracy zespołu analityków biznesowych; na to w jakiej formie otrzymuję wymagania - nie mam jednoznacznego wpływu.

Temat: Architektura oprogramowania 4+1

Roman Frania:
biorę udział. DFD - otrzymuję przeważnie "na wejście" mojej pracy - jako produkt pracy zespołu analityków biznesowych; na to w jakiej formie otrzymuję wymagania - nie mam jednoznacznego wpływu.

a ci "analitycy" z jakiej są epoki ;), bo wydawało mi się, że wynik analizy powinien być naturalnym wsadem dla dalszej części pracy i nauczono mnie, że to klient określa wymagania na produkt, ale tylko tak se zamarudziłem ;)

analiza strukturalna i obiektowe metody implementacji charakteryzują się czymś co nazywane jest w książkach "z branży" "niedopasowaniem oporu"..

Temat: Architektura oprogramowania 4+1

klient określa wymagania, a analitycy powinnini je właściwie zrozumieć, zinterpretować i przedstawić w umówionej formie. niby proste, ale nie zawsze działa.

w zalezności od umiejętności ludzi, specyfiki projektów i obranej metodologii - w poszczególnych fazach projektu powinno się zunifikować sposób komunikacji - problem w tym, że poszczególne grupu udziałowców mówią trochę "innymi językami" i często są innych epok :) dotyczy to również przyjętej notacji opisu procesów czy innych wymagań;

tam gdzie oprogramowanie tworzy się od zera - tam można zastosować tego typu rozwiązania (np. tylko i wyłącznie podejście zorientowane obiektowo i tylko diagramy UML) - sprawdzić się to może szczególnie w firmach specjalizujacych się wytwarzaniem oprogramowania;

Temat: Architektura oprogramowania 4+1

Roman Frania:
klient określa wymagania, a analitycy powinnini je właściwie zrozumieć, zinterpretować i przedstawić w umówionej formie. niby proste, ale nie zawsze działa.

Klient nie określa wymagań. To analitycy powinni te wymagania wydobyć od klienta. Zazwyczaj robią to metodą scenariuszy.
Natomiast mało rozgarnięci pytaja: co chceta ? a potem się dziwią ....

w zalezności od umiejętności ludzi, specyfiki projektów i obranej metodologii - w poszczególnych fazach projektu powinno się zunifikować sposób komunikacji - problem w tym, że

Opis architektury oprogramowania służy tej właśnie komunikacji.
A u Ciebie czym się posługujecie ????

poszczególne grupu udziałowców mówią trochę "innymi językami" i często są innych epok :) dotyczy to również przyjętej notacji opisu procesów czy innych wymagań;

Porządnego architekta Wam trzeba ;))))))))

tam gdzie oprogramowanie tworzy się od zera - tam można zastosować tego typu rozwiązania (np. tylko i wyłącznie podejście zorientowane obiektowo i tylko diagramy UML) - sprawdzić się to może szczególnie w firmach specjalizujacych się wytwarzaniem oprogramowania;

Architektura 4+1 to nie UML, ale dowolne notacje ...
RUP natomiast, który opiera się na architekturze 4+1 stosuje wyłącznie UML ...

Temat: Architektura oprogramowania 4+1

Zawsze wymagania okresla klient. Nie zawsze musi to robic samodzielnie i wcale nie musi. Okreslenie wymagan przez klienta to podstawa wiekszosci przedsiewziec informatycznych i nie koniecznie musi oznaczac zapisanie tych wymagan w oczekiwanej przez analitykow formie. To wlasnie analiza biznesowa a pozniej systemowa jest podstawowym narzedziem, ktore jest wykorzystywane w kolejnym etapie i dopiero jej efektem jest zapis w okreslonej formie.

Opis architektury i komunikacja? Mysle, ze mylisz pojecia lub nie do konca rozumiesz ich przeznaczenie. Architektura to nie metodologia i nie ten poziom rozwazan. Sposob komunikacji to domena metodologii. Metodologia moze/powinna wykorzystac dorobek architektury w danym kontekscie i na danym poziomie. Architekt budynku nie mowi jak wiaderko cementu ma zostac dostarczone na 10 pietro. Mozna je dostarczyc na n-sposobow. Szef projektu znajacy zasoby projektowe i dostepne narzedzia decyduje: "JAK" w procesie.

Co do porzadnych architektow - mamy ich kilku ;) Dziekuje mimo to za cenne wskazowki ;))))

Temat: Architektura oprogramowania 4+1

Jarek Żeliński:

Oprócz kilku ogólników, których sporo w różnych artykułach traktujących o IO, nie podano tam sposobu przejścia. Jakbyście zaproponowali jakąś odpowiednią metodę, pewnie na spoko któryś z autorów pochwaliłby się na jakiejś konferencji ... :)

a ja zapytam: jak rozumieć "biznesowy przypadek użycia"?

bo "przypadek użycia" to sytuacja w której planujemy kontakt użytkownika (aktora) z systemem, a biznesowy to co to za zwierzę?

wiem, wiem, że są książki które o tym wspominają, nawet są stosowne stereotypy w UML ale nie ukrywam, ze "rozmydlone" nadal nie rozumiem czym jest proces "przechodzenia od biznesowych przypadków użycia do systemowych przypadków użycia" ... dla wyjaśnienia rozumiem co oznacza wskazanie na modelu procesów czynności zakwalifikowanych do zakresu projektu, te dalej są nazywane "przypadkami użycia systemu".

Nie ukrywam, ze dla mnie "biznesowy przypadek użycia" to jakaś nowomowa...

Nie twierdzę, że to precyzyjna definicja ale wydaje mi się mi się że można to rozumieć mniejwięcej w następujący sposób.

Biznesowe przypadki użycia + RichPicture pokazują co się dzieje w firmie, kto co robi i za co jest odpowiedzialny. Np. magazynier: odbiór dostawy, wydanie częsci itp. Tutaj łatwo zaznaczyć zakres informatyzacji, co można ułatwić a czego raczej się nie opłaca. Tutaj właściwie systemu jeszcze nie ma.

W systemowych przypadkach użycia pokazuje się jak te powyższe będą wykonywane z wykorzystaniem systemu.

To tylko moja interpretacja i nie uważam się tu za wyrocznię. Chętnie wysłucham wszelkich uwag.

Temat: Architektura oprogramowania 4+1

Nie twierdzę, że to precyzyjna definicja ale wydaje mi się mi się że można to rozumieć mniejwięcej w następujący sposób.

Biznesowe przypadki użycia + RichPicture pokazują co się dzieje w firmie, kto co robi i za co jest odpowiedzialny. Np. magazynier: odbiór dostawy, wydanie częsci itp. Tutaj łatwo zaznaczyć zakres informatyzacji, co można ułatwić a czego raczej się nie opłaca. Tutaj właściwie systemu jeszcze nie ma.

Czyli mamy np. model procesów biznesowych na którym widać także czynności.

W systemowych przypadkach użycia pokazuje się jak te powyższe będą wykonywane z wykorzystaniem systemu.

Czyli wskazuje się te czynności, które wejdą w zakres projektu jako Przypadku Użycia.

Hm... zapytałem bo niewiedzieć czemu spotykam w literaturze o UML pojęcie biznesowych przypadków użycia ale nigdzie jawnie nikt nie pisze, że to jakiś kulawy (tak sądzę, bo nic nowego nie wnosi a brzytwa Okhama wisi nad nami ;)) "zamiennik" modelu procesów... i chyba pozostanę przy ty ignorowaniu "biznesowych przypadków użycia"" jako narzędzia...

Temat: Architektura oprogramowania 4+1

I tu się zgodzę. Takie podejście wnosi według mnie za mało informacji i służy właściwe tylko "produkowaniu" stron w dokumentacji.

Jakich metod używa Pan do prezentacji procesów biznesowych w firmie? Sam spotkałem się do tej pory tylko z notacją SPEM/UML. Czy używa się tego w praktyce czy nie? Jeśli nie, to czego warto się nauczyć? Sam raczej nie będę tych diagramów/opisów/etc tworzył, lecz warto rozumieć o czym do mnie pisze analityk.

Temat: Architektura oprogramowania 4+1

Grzegorz Gwoźdź:
I tu się zgodzę. Takie podejście wnosi według mnie za mało informacji i służy właściwe tylko "produkowaniu" stron w dokumentacji.

pozostaje mi przytaknąć...

Jakich metod używa Pan do prezentacji procesów biznesowych w firmie? Sam spotkałem się do tej pory tylko z notacją SPEM/UML.

osobiście od lat w domenie zarządzania i opisu systemów zarządzania stosuje się metody z tej dziedziny: procesowe. Tu niejako standardem są, kiedyś notacja EPC, potem eEPC, obecnie BPMN, oraz narzędzia stosujące te standardy a także swoje dedykowane notacje. W tym miejscu wydaje się, że standardem de 'facto jest już notacja BPMN (wydaje mi się, że znaczenie eEPC maleje...)

Niezależnie od tego, że UML zawiera diagram sekwencji i aktywności, których można by użyć w sferze modelowania procesów zarządzania notacje te nie sprawdzają się, i nie dlatego, że są złe (chociaż mają braki semantyczne w biznesie co wymaga stosowania stereotypów, w moich oczach zaciemniających modele, po mam używać UML plus dedykowane profile jak mam pięknego gotowca jakim jest BPMN) ale dlatego, że w wśród ludzi biznesu są niezrozumiałe. Paradygmat obiektowy to sfera inżynierii oprogramowania a nie biznesu i z moich obserwacji wynika, że próby przebicia się z UML do biznesu to czas stracony (lokalne małe sukcesy nie są dowodem na to, że to możliwe, są dowodem że to trudne).

Czy używa się tego w praktyce czy nie? Jeśli nie, to czego warto się nauczyć? Sam raczej nie będę tych diagramów/opisów/etc tworzył, lecz warto rozumieć o czym do mnie pisze analityk.

Jak wspomniałem, wychodzę z założenia, że do biznesu należy mówić językiem biznesowym (teoria komunikacji społecznej jest dla mnie wystarczającym dowodem na tę tezę) i tak "zapisać" ich (biznesu) wiedzę, potem przetłumaczyć to na język inżynierii i przejść na UML a konkretnie na obiektowy model przyszłego systemu.

wąskim gardłem jest przejście z procesów na model dziedziny i przypadki użycia, które to tak na prawdę powinny być sprowadzone jeden do jednego do modułów (klas) wykonawczych np. widoku i kontrolera wzorca MVC (który bardzo lubię :)) a model dziedziny wchodzi jeden do jednego w Model w MVC.

To wymaga jednak nie tylko samego modelowania procesów (w czymkolwiek) ale wypracowania tak zwanej pragmatyki modeli procesów by móc przejść z niego do modelu obiektowego a wcześniej stosować zasady semiotyki by biznes ze zrozumieniem czytał i zatwierdzał mapy procesów.

Ale to temat na niezłe szkolenie :) a nie na krótką notkę tu na forum ;)Jarek Żeliński edytował(a) ten post dnia 25.10.09 o godzinie 10:55