eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingUML a modelowanie funckjonalności systemu
Ilość wypowiedzi w tym wątku: 13

  • 11. Data: 2009-01-16 15:44:34
    Temat: Re: UML a modelowanie funckjonalnoci systemu
    Od: tsharny <t...@w...pl>

    Wiktor Zychla pisze:
    > rozpisanie scenariuszy/przypadków użycia nie zaprojektuje Ci samo
    > architektury systemu, ani nie zbuduje modelu
    > analitycznego/dziedzinowego, może tylko pomóc.
    > spróbuj jakoś tak: scenariusz jaki rozpisujesz:
    >
    > 1. Zalogowanie sie do systemu,
    > 2. Sprawdzenie dostepnych wolnych dni od pracy,
    > 3. Wyslanie prosby o urlop do kierownika.
    > 4. Otrzymanie akceptacji urlopu.
    > 5. Zapisanie w bazie danych urlopu.

    To co Megas podał (5 kroków przypadku użycia 'Wypisanie przez
    pracownika urlopu') jest niczym innym jak osobnymi przypadkami użycia.

    Aktorem będzie Użytkownik, który może wybrać następujące opcje w
    systemie (przypadki użycia):

    1. Zaloguj
    2. Sprawdź wolne dni
    3. Wypisz urlop
    4. Wyświetl dni urlopu

    Dla każdego z przypadków użycia powinno się napisać scenariusz użycia.
    Podczas dalszej pracy w budowaniu całego modelu, wiemy jaką
    funkcjonalność reprezentuje dany przypadek użycia i na tej podstawie
    tworzymy dynamikę systemu.

    Przykład:

    Nazwa: Zaloguj (Nazwa przypadku użycia)

    Twórca: Imię i Nazwisko

    Aktorzy: Użytkownik (Aktorzy wchodzący w interakcję z danym przypadkiem
    użycia)

    Krótki opis: np. Logowanie użytkownika do systemu

    Warunki wstępne:np. podanie identyfikatora użytkownika i hasło
    (konieczne warunki inicjujące przypadek)

    Warunki końcowe:np. identyfikator użytkownika i hasło zgodne z danymi w
    bazie (stan systemu po realizacji przypadku użycia)

    Główny przepływ:a) Użytkownik uruchamia aplikację
    b) Wyświetla się okno logowania do systemu
    c) Użytkownik wpisuje w pola swoje dane: identyfikator oraz hasło
    d) Użytkownik naciska klawisz OK
    e) Po poprawnym zalogowaniu uruchamia się główne okno aplikacji

    Alternatywny przepływ:
    b1) Po wyświetleniu formatki logowania użytkownik naciska klawisz ANULUJ
    b2) Okno logowania wraz z aplikacją zostają zamknięte

    e1) System wyświetla informację o błędnym identyfikatorze użytkownika
    lub haśle
    e2) Użytkownik wraca do punktu c) Głównego przepływu

    .
    .
    .

    w alternatywnym przepływie wypisujemy pełny scenariusz jaki może
    spotkać użytkownik realizując dany przypadek użycia

    Specjalne wymagania:Wypunktowana i scharakteryzowana lista dodatkowych
    zidentyfikowanych wymagań niefunkcjonalnych, które mogą być istotne
    przykładowo podczas projektowania czy kodowania

    Notatki: Lista wszystkich komentarzy dotyczących przypadku użycia i
    lista otwartych kwestii, które powinny zostać rozwiązane wraz z
    propozycjami osób, które mogłyby je rozwiązać

    Zapisanie w bazie danych urlopu nie jest przypadkiem użycia, tylko
    funkcjonalnością, która powinna zostać uruchomiona automatycznie w
    przypadku zatwierdzenia urlopu przez przełożonego (w przypadku
    niezatwierdzeniu również powinna być taka możliwość). Natomiast
    akceptacja urlopu powinna się pojawić podczas uruchomienia opcji
    'Wyświetl dni urlopu' - jeszcze jedną funkcjonalnością przy
    akceptacji/odrzuceniu urlopu przez przełożonego dodałbym powiadomienie
    via mail.

    >
    > już widać, że model analityczny musi przewidywać jakichś użytkowników,
    > jakiś rejestr dni wolnych, jakiś rejestr próść o urlop, coś
    > przechowującego akceptacje / nieakceptacje.

    To już logika systemu.


    > dopiero z takiego przybliżenia analitycznego można bardzo uważnie
    > zaprojektować ścisły model dziedzinowy (czyli diagram klas części
    > biznesowej aplikacji).

    :)

    > podsystemów GUI/IO w ogóle bym nie modelował, bo one są zwykle pochodną
    > technologii jakiej użyjesz i nie masz na nią zbyt dużego wpływu.

    Jak najbardziej może zaprojektować wygląd formatek.

    pozdrawiam
    tsharny


  • 12. Data: 2009-01-16 18:57:24
    Temat: Re: UML a modelowanie funckjonalnoci systemu
    Od: ZbyszekZ <z...@g...com>

    On Jan 14, 11:59 pm, "Megas" <k...@o...eu> wrote:
    > Użytkownik "Megas" <k...@o...eu> napisał w
    wiadomościnews:gklqnl$goj$1@news.onet.pl...
    >
    > >>>Od d?u?szego czasu mam k?opot z wymodelowaniem funkcjonalno??
    > >>>projektowanego
    > >>>systemu, czy kto? móg?by mi w tym pomóc?
    > >>>Sytuacja jest taka, ?e mam ju? wymodelowany model przypadków u?ycia dla
    > >>>mojego systemu, a teraz chcia?bym wymodelowac z jakich cz??ci
    > >>>funkcjonalno?ci b?dzie si? sk?ada? system.
    >
    > >> Co to jest "czesci funkcjonalnosci" I dlaczego system ma sie z niuch
    > >> skladac?
    >
    > >> A.L.
    >
    > Dla przykładu: Funkcjonalnosc programu 'Outlook Express' bedzie sie skladac
    > z czesci:
    > a) Wysyłanie i odbieranie poczty e-mail,

    Diagram przepływu

    > b) Prezentacja e-mail w GUI,

    Diagram przepłwu, diagram stanu

    > c) Tworzenie nowych e-mail (edytor tekstowy),

    Diagram przepływu stanu, aktywności


    Każdy z powyższych będzie rozwinięciem usecase, tak aby "przypadek
    użycia" nie był samą nazwą.

    --
    ZZ@private


  • 13. Data: 2009-01-19 07:58:41
    Temat: Re: UML a modelowanie funckjonalnoci systemu
    Od: "Wiktor Zychla" <u...@n...com.eu>

    >> podsystemów GUI/IO w ogóle bym nie modelował, bo one są zwykle pochodną
    >> technologii jakiej użyjesz i nie masz na nią zbyt dużego wpływu.
    >
    > Jak najbardziej może zaprojektować wygląd formatek.
    >

    chodzi mi o [model] - [projekt] formatek to rzecz oczywiście pożądana.

    Wiktor Zychla

strony : 1 . [ 2 ]


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: