[WikiDyd] [TitleIndex] [WordIndex

Laboratorium projektowania i wytwarzania systemów informatycznych opartych na graficznym interfejsie użytkownika


Materiały zostały opracowane w ramach realizacji Programu Rozwojowego Politechniki Warszawskiej.

http://prpw.iem.pw.edu.pl/images/KAPITAL_LUDZKI.gifhttp://prpw.iem.pw.edu.pl/images/EU+EFS_P-kolor.gif

http://www.pr.pw.edu.pl/ jest projektem współfinansowanym przez Unię Europejską w ramach Europejskiego Funduszu społecznego (działanie 4.1.1 Programu Operacyjnego Kapitał Ludzki) i ma na celu poprawę jakości kształcenia oraz dostosowanie oferty dydaktycznej Politechniki Warszawskiej do potrzeb rynku pracy. Będzie on realizowany przez Uczelnię w latach 2008-2015.

Ćwiczenie Nr 4

Wykonanie projektu funkcjonalnego wskazanego przez prowadzącego fragmentu systemu informatycznego

Autor: dr inż. Robert Szmurło

1. Cel ćwiczenia

W ramach ćwiczenia student zdobywa doświadczenie związane z metodami projektowania i dokumentowania abstrakcyjnego projektu funkcjonalnego interfejsu użytkownika. Student zdobywa umiejętność wyodrębnienia z słownika dziedzina użytkownika (tutaj nazywanego Obiektami użytkownika) elementów związanych z graficznym interfejsem. W drugiej części ćwiczenia student za pomocą diagramów klas dokumentuje niezbędną funkcjonalność interfejsu.

2. Zakres badań

W ramach ćwiczenia student wykorzystuje dokument analizy wymagań, który został przez niego opracowany na poprzednich zajęciach. W razie potrzeby student powinien dokonać poprawek w wcześniej opracowanym modelu. Podczas zajęć student ma za zadanie opracować diagram obiektów użytkownika, scenariusze przypadków użycia, diagramy okien i widoków abstrakcyjnych interfejsu użytkownika oraz diagramy przepływu zadań.

Abstrakcyjny projekt funkcjonalny interfejsu użytkownika składa się z następujących elementów:

  1. Obiekty Użytkownika - określ obiekty/elementy/pojęcia na których wykonuje operacje użytkownik i system (słownik pojęć)
  2. Przegląd Zadań (Scenariusze) - określ które czynności wykonuje system a które użytkownik
  3. Okna i widoki Abstrakcyjne - jakie informacje musi widzieć użytkownik aby ukończyć zadanie poszczególne zadania (związane z konkretnymi przypadkami użycia) oraz jakie dane powinny być prezentowane do przedstawiania konkretnego obiektu
  4. Przepływ Zadań (Sekwencje) - sprecyzuj dokładnie interakcję użytkownika z systemem → analogia do scenariuszy przypadku użycia

Obiekty użytkownika

  1. Wyodrębniamy obiekty – zazwyczaj są to rzeczowniki z diagramu zawierającego cele użytkowników
  2. Wykorzystujemy specjalną tabelą wskazując na przykład wzajemne zależności, w celu wyselekcjonowania kluczowych obiektów (ważne w iteracjach) np.: konkretne obiekty, osoby, dokumenty, użytkownicy, obiekty abstrakcyjne
  3. Definiujemy jednoznaczne i zrozumiałe dla użytkownika nazwy obiektów (w niektórych metodologiach nazywa się to słownikiem pojęciowym dziedziny)
  4. Porządkujemy obiekty w modelu uwzględniając ich definicje, atrybuty, operacje oraz relacje w postaci diagramu klas.

Przegląd zadań (Scenariusze)

Określamy które czynności wykonuje system, a które użytkownik. Na tym etapie zaczyna się określenie doświadczenia / interakcji użytkownika z systemem. Po raz pierwszy pojawia się system.

Definicja: wysokiego poziomu opis określający strukturę funkcjonalności (ogólnie sekwencji aktywności oraz punktów decyzyjnych), którą system udostępnia dla użytkownika w celu zrealizowania intencji.

Punktem startowym modelu jest odwzorowanie aktualnych procesów w instytucji użytkownika, które wykonaliśmy w projekcie pojęciowym (czasami nazywanym modelem biznesowym). Jednoznacznie określamy kto jest odpowiedzialny za wykonanie danej czynności. Stąd nazwa procesu: przegląd zadań. Jest to często nazywane scenariuszem przypadku użycia.

Okna i widoki abstrakcyjne

W fazie tej określamy jakie informacje musi widzieć użytkownik aby ukończyć zadanie. Projekt abstrakcyjny opisuje strukturę funkcjonalną interfejsu użytkownika.Jest to niezależna od implementacji reprezentacja tego co musi widzieć użytkownik do zakończenia zadania w postaci hierarchicznej struktury elementów widocznych na ekranie. Abstrakcyjny model interfejsu użytkownika tworzymy wykorzystując model obiektów użytkownika (diagram klas) oraz przegląd zadań (diagram sekwencji z przeglądu zadań). Na etapie tym dokonujemy funkcjonalnego mapowania obiektów dziedziny użytkownika na ich reprezentację w graficznym interfejsie.

Głównym celem etapu jest określenie minimalnych informacji z poszczególnych obiektów, które musi widzieć użytkownik aby ukończyć zadanie oraz jaka w danym kroku musi być udostępniona funkcjonalność. Ideą okien i widoków abstrakcyjnych jest możliwość skoncentrowania się na treści oraz funkcjonalności odseparowanej od prezentacji. W widokach abstrakcyjnych nie interesuje nas jak, ale CO? będzie zaprezentowane.

Widoki abstrakcyjne są elementami, które nie mogą pojawiać samodzielnie. Zawsze są one częścią innych widoków lub są częścią okien. Widoki abstrakcyjne tworzymy zazwyczaj dla każdego obiektu użytkownika, który pojawia się w fazie analizy. Użytkownicy nie pracują na obiektach ale na ich widokach, czyli ich graficznej reprezentacji.

Okna abstrakcyjne są samodzielnymi elementami, które pojawiają się użytkownikowi. Okna abstrakcyjne są elementami które pojawiają się w scenariuszach. Okna abstrakcyjne zbudowane są zazwyczaj z widoków abstrakcyjnych.

Projekt sekwencyjny

W etapie nazwanym Przepływ Zadań precyzujemy dokładnie interakcję użytkownika z systemem w postaci diagramów sekwencji. Aktorem startowym w diagramach jest zawsze użytkownik, a instancjami są okna i widoki abstrakcyjne z poprzedniego etapu. Użytkownik operuje zawsze tylko na widokach i oknach abstrakcyjnych a nigdy bezpośrednio na obiektach z dziedziny.

W diagramie przepływu zadań tworzymy szczegółowy projekt interakcji użytkownika systemu z poszczególnymi oknami oraz widokami. Motywacją dla tego etapu jest stworzenie:

3. Program badań

Uwaga! Wykorzystujemy projekt w Enterprise Architect przygotowany na poprzednich zajęciach.

Ćwiczenie podzielone jest na 4 etapy:

  1. Obiekty Użytkownika - określ obiekty/elementy/pojęcia na których wykonuje operacje użytkownik i system (słownik pojęć)
    • Utwórz diagram klas.
    • Dodaj obiekty, wraz z atrybutami i operacjami.
    • Utwórz definicje.
    • Określ zależności (relacje).
    • Uzupełnij informację o liczebności
    • Sukcesywnie dodawaj wszystkie obiekty włącznie z aktorami o których musi wiedzieć system
    • Operacje na klasach określamy najczęściej za pomocą czasowników z projektu pojęciowego.
    • Dla zależności wiele do wielu zaleca się określenie innego obiektu zwanego obiektem łączącym
    • Najczęściej wykorzystywane są dotychczasowo istniejące w firmie formularze, dokumenty papierowe.
    • Do wykonania: 1 diagram klas.
  2. Przegląd Zadań (Scenariusze) - określ które czynności wykonuje system a które użytkownik
    • Do wykonania: 3 diagramy czynności. Przykładowy diagram:

      scenariusz_funkcjonalny.png

  3. Okna i widoki Abstrakcyjne - jakie informacje musi widzieć użytkownik aby ukończyć zadanie poszczególne zadania (związane z konkretnymi przypadkami użycia) oraz jakie dane powinny być prezentowane do przedstawiania konkretnego obiektu
    • Do wykonania: 5 diagramów klas (3 dla okien i 2 dla widoków abstrakcyjnych) Przykładowy diagram:

      model_abstrakcyjny.png

  4. Przepływ Zadań (Sekwencje) - sprecyzuj dokładnie interakcję użytkownika z systemem - analogia do scenariuszy przypadku użycia
    • Do wykonania: 3 diagramy sekwencji po 1 dla każdego scenariusza z punku Przegląd zadań (mogą wymagać utworzenia dodatkowych okien lub widoków abstrakcyjnych) Przykładowy diagram:

      model_sekwencyjny.png

4. Programy użyte w badaniach

Enterprise Architect

5. Sprawozdanie

Sprawozdanie powinno zawierać wygenerowany z Enterprise Architect raport projektu funkcjonalnego zgodnie z załączonym do instrukcji szablonem. W Enterprise Architect należy wykorzystać szablon (diagrams template).

Szablon sprawozdania:

6. Literatura

  1. Notatki do wykładu.

Pliki do pobrania:

  1. Plik z szablonem projektu w Enterprise Architect: :lpgui_projekt_funkcjonalny.eap


2015-09-23 06:44