Witam
Pytanie jak w temacie.
Szukałem info w necie ale nic nie znalazłem.
Jeżeli ktoś by miał takie info czy musi być czy nie to by było cool.
Chodzi tylko o to że potrzebuje potwierdzenia na stronie lub w książce
Moje zaliczenie zależy od tego.

Z góry dzięki za odpowiedzi i pomoc
Pozdrawiam

Pytanie, mogłoby się wydawać trywialne a jednak tak nie jest - otóż, diagramy przypadków uzycia obrazują statyczny aspekt perspektywy przypadków użycia systemu. I co najwazniejsze, w perspektywie tej, obrazuje się usługi systemu, jakie udostępnia swojemu otoczniu! Oznacza to, że nie obrazując aktorów (co jest dopuszczalne), zwyczajnie nie wskażesz odbiorców tych usług systemu, które są przeznaczone (dedykowane) właśnie tym odbiorcom!

W praktyce, diagram (jakikolwiek) to tylko wybranie elementów (potrzebnych) ze zbioru repozytorium projektowego (które może być znacznie szersze od tego co pokazuje diagram), dlatego też, może się zdarzyć, że aktorów się nie zamieszcza, jednak byłby to pewien niedosyt jednego z celu diagramu przypadków użycia - przedstawienia otoczenia systemu.

Pozdrowienia

Artur, to ja mam pytanie, które zahacza o pytanie przedmówcy.


Wstęp do pytania: Załóżmy, że modyfikujemy system X, Y, Z, dodam, że systemy są częścią tzw. zintegrowanego środowiska. Każdy z nich to niezła kobyła, a wszystkie spina warstwa integracyjna(MQ, webServisy, itd). Modelujemy rozwiązanie, które zmienia każdy z systemów. Załóżmy, że sprzedajemy nowy produkt, który wymusza takie zmiany.

Pytanie 1: Czy modelując UC traktujemy każdy z tych systemów jako aktorów, czy może jako komponenty budowanego rozwiązania?

Witam,

jeżeli mielibyśmy precyzyjnie omówić temat, to musielibyśmy najpierw wyjaśnić, czym jest i czego dotyczy to wspomniane "modelujemy rozwiązanie" ?

Pozdrawiam,
Artur

Modelujemy, oznacza przekładamy wymagania funkcjonalne(biznesowe) na systemowe przypadki użycia.

Wyobraźmy sobie te systemy, jako kompletne twory w które musimy wrzucić całkowice nowe produkty, a przez to i procesy obsługi.

Nie wiem, jak można to wyraźić prościej.

Pzdr.,
Maciek

1) Modelowac rozwiazanie - nie zawsze oznacza definiowac wymagania funkcjonalne od systemu informatycznego.

2) Wymagania funkcjonalne to nie koniecznie wymagania biznesowe i zwykle unikam okreslenia "biznesowe", rozwazajac o rozwiazaniach systemu informatycznego z takiego powodu - ze "biznesowe" zwykle wskazuje na najwczesniejszy etap modelowania z uzyciem UML.

3) Moje pytanie wynikalo z faktu, ze warstwa integracyjna - to warstwa najnizsza z trzech w klasycznej strukturze J2EE. Z wielu zalozen a zarazem czytelnosci modeli wynika, ze znacznie lepiej obrazowac i specyfikowac warstwe integracyjna z uzyciem dedykowanej jej elementow notacji UML. Przy czym, w czasie projektowania aplaiakcji duzo wczesniej niz przed specyfikowaniem warstwy integracyjnej definiuje sie wymagania funkcjonalne od aplikacji.

Wroce do pytania Twojego pierwotnego w nastepnym poscie

A wiec unikalbym takiego spojrzenia, gdzie przeplatamy komponenty systemu z aktorami (w rozumieniu inicjatorow wykonania uslugi od systemu).

Moglibysmy ta dyskusje poprawadzic innymi torami, jezeli zaczelibysmy rozwazac problem w pelni na poziomie integracyjnym (gdzie wymagania funkcjonalne zostaly przedstawione i zdefiniowane).

Co myslisz?

Pozdrawiam,
Artur

Artur,

abstrahujemy od warstwy integracyjnej w naszych rozważaniach(na razie). Traktujemy warstwę jako pośrednika. Dla nas system to rozwiązanie kompletne. Podam przykład:

W systemie X, łapiemy zamówienie na produkt, grupę produktów
W systemie Y, przetwarzamy zamówienie delegując obslugę części procesu obsługi do systemów Z, M, N. Cały czas informujemy system X o postępach realizacji zamówienia, koordynowanego przez system Y.

Tak to wygląda. A warstwe integracyjną sprowadzam do roli pośrednika. Systemy X, Y, Z, M, N udostępniają serwisy za pomocą warstwy integracyjnej. Z punktu widzenia modelowanego rozwiązania modelowanie warstwy EAI, będzie dopiero kolejnym etapem. Tak samo, jak modelowanie "wnętrzności" poszczególnych systemów X, Y, Z, M, N. Na razie modelujemy system jako całość.