Transcript Przejście od analizy do projektowania
Jarosław Kuchta
Dokumentacja i Jakość Oprogramowania
Projektowanie systemowe
Zagadnienia
Cele projektowania systemowego Wybór strategii projektowania Przejście od analizy do projektowania Pojęcia: generalizacja, abstrakcja, agregacja partycjonowanie, warstwy projektowe frameworki faktoryzacja Warstwy projektowe Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 2/24
Cele projektowania systemowego (1)
Dopasowanie projektowanego systemu informatycznego do istniejącego systemu (organizacji) Integracja z istniejącym systemem informatycznym Konwersja istniejących danych Dopasowanie się do umiejętności użytkowników Wybór strategii projektowania Projektowanie „od zera” Przystosowanie istniejącego, dostępnego systemu Zlecenie wykonania na zewnątrz Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 3/24
Cele projektowania systemowego (2)
Określenie warunków technicznych dla systemu (sprzęt, oprogramowanie) Wybór konfiguracji systemu: scentralizowana rozproszona mieszana Określenie strategii dla interfejsu użytkownika, wejścia i wyjścia systemu, przechowywania danych Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 4/24
Strategie projektowe
Opracowanie własne Dopasowanie istniejącego oprogramowania Zlecenie na zewnątrz (outsourcing) Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 5/24
Opracowanie własne
Pełna kontrola nad wyglądem i funkcjami systemu Łatwość dopasowania się do wymagań biznesowych Gromadzenie doświadczeń i wiedzy w firmie Wymaga dużego wysiłku (pracy i czasu) Wysoki poziom ryzyka (brak gwarancji powodzenia) Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 6/24
Dopasowanie istniejącego oprogramowania
Wiele wymagań może być spełnionych przez istniejące, pakietowe oprogramowanie (packaged software) Większa efektywność takiego rozwiązania Niepełność zaspokojenia wymagań Potencjalna konieczność zmiany sposobu funkcjonowania organizacji Potencjalna konieczność konwersji istniejących danych Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 7/24
Zlecenie na zewnątrz (outsourcing)
Możliwość obniżenia kosztów Możliwość lepszego dopasowania zasobów do zadania Potencjalny wypływ poufnej informacji z firmy Utrata kontroli nad przyszłym opracowaniem Brak zdobywania doświadczenia Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 8/24
Kryteria wyboru strategii
Potrzeby biznesowe Doświadczenie w firmie Umiejętności projektowe Kierownictwo Ograniczenia czasowe Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 9/24
Wykonalność organizacyjna Wykonalność techniczna Wykonalność ekonomiczna Inne zalety Inne ograniczenia
Macierz alternatyw
Alternatywa 1:
E-Shop
Opracowanie własne Opracowanie w C; Zamówienia przez e-mail Alternatywa 2:
Web Shop
Dopasowanie gotowego oprogramowanie Opracowanie w C i Javie Alternatywa 3:
J-Shop
Opracowanie własne Opracowanie w Javie 15 tys. PLN 70 tys. PLN; 30 tys. PLN Duże doświadczenie z C w firmie Nie nabywamy doświadczeń nabycie doświadczeń z Javą Małe doświadczenie z Javą w firmie Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 10/24
Przejście od analizy do projektowania
Modele analityczne pokazują dziedzinę problemu.
Modele projektowe pokazują system informatyczny.
Utrzymanie spójności - modele projektowe powinny być rozwinięciem (uszczegółowieniem, uściśleniem) modeli analitycznych.
Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 11/24
Przegląd modelu klas
Czy wszystkie klasy analityczne będą implementowane? Uzupełnienie brakujących klas Uzupełnienie definicji klas Stworzenie i uściślenie struktury klas Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 12/24
Stosowane środki (1)
Generalizacja wydzielenie i przenoszenie wspólnych składowych z kilku klas do osobnej, wspólnej klasy, z której te klasy będą dziedziczyć.
Abstrakcja tworzenie klas abstrahujących od pewnych szczegółów implementacji stosowanie interfejsów – abstrakcja od wszystkich szczegółów implementacji (rozwiązanie problemu braku dziedziczenia wielokrotnego) Uszczegóławianie tworzenie klas potomnych oferujących dodatkowe właściwości i możliwości Agregacja deklarowanie klas kontenerowych, które będą zawierały klasy "biznesowe" wynikające z analizy wymagań przenoszenie operacji z klas składowych do klas kontenerowych (komponent klasy kontenerowej "zna" wszystkie komponenty składowe) Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 13/24
Stosowanie środki (2)
Partycjonowanie - podział systemu: podział na warstwy - oszacowanie liczby kontraktów (wymienianych danych i wykorzystywanych operacji) między klasami.
stosowanie warstw ułatwia wprowadzanie modyfikacji do systemu (np. wymianę bazy danych) bez naruszania innych elementów architektonicznych (np. interfejsu użytkownika) podział na przestrzenie nazw – organizacja hierarchiczna złożoności, możliwość stosowania tych samych nazw w różnych przestrzeniach.
Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 14/24
Stosowane środki (3)
Wykorzystanie frameworków framework – gotowa biblioteka komponentów tworzących szkielet aplikacji i określających sposób jej działania.
zaleta: ułatwia i przyspiesza projektowanie i implementację aplikacji warunek: dobra znajomość wykorzystywanego frameworka wady: duża różnorodność frameworków przy braku standaryzacji trudne lub niemożliwe wykorzystanie frameworka w sposób nieprzewidziany przez jego twórcę Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 15/24
Stosowane środki (4)
Faktoryzacja - wykorzystanie gotowych komponentów i szablonów projektowych z dopasowaniem do wymagań konkretnego projektu zastosowanie kodu otwartego (open source) przeniesienie własnego kodu z innego projektu adaptacja gotowych komponentów: problemy: klasy zamknięte (sealed), właściwości i metody prywatne, brak wirtualizacji wrapper – klasa, której interfejs jest dopasowany do wymagań danego projektu, a implementacja korzysta w znacznym stopniu z innej, gotowej klasy (której nie można modyfikować) Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 16/24
Typowe warstwy projektowe
Presentation Layer Application Logic Data Management Foundation Data Layer Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 17/24
Warstwa podstawowa
Warstwa podstawowa (Foundation) – obejmuje klasy wykorzystywane bezpośrednio we wszystkich innych warstwach: definicje podstawowych typów danych (np. typy wyliczeniowe), definicje podstawowych struktury danych (np. listy, drzewa, stosy), użyteczne typy abstrakcyjne (data, czas, waluta) operacje dodatkowe, które nie są dostarczane przez biblioteki Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 18/24
Warstwa danych
Warstwa danych (Data) zawiera komponenty odpowiedzialne za przechowywanie (zapisywanie i odczytywanie) danych: bazy danych (tabele, kwerendy) repozytoria plików Wymaga określenia: które klasy są trwałe (dane przechowywane między sesjami) jaki sposób przechowywania będzie stosowany (baza danych, pliki) jaki format zapisu danych będzie stosowany (tekstowy, binarny) jaki typ bazy danych będzie stosowany (relacyjna, obiektowa) Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 19/24
Warstwa zarządzania danymi
Warstwa zarządzania danymi (Data Management) zawiera klasy odpowiedzialne za dostęp do przechowywanych danych.
Umożliwia: ochronę danych przed nieupoważnionym dostępem współdzielenie danych między wieloma użytkownikami Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 20/24
Warstwa logiki aplikacji
Warstwa logiki aplikacji (Application Logic) – zwana również warstwą biznesową (Business Domain) – zawiera klasy realizujące operacje wymagane w konkretnej operacji wynikające z analizy wymagań.
Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 21/24
Warstwa prezentacji
Warstwa prezentacji (Presentation Layer) zawiera komponenty interfejsu użytkownika (okna, strony etc.): umożliwia użytkownikowi wydawanie poleceń dla systemu i wprowadzanie danych prezentuje dla użytkownika dane przetwarzane z warstwy logiki aplikacji Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 22/24
Przykładowa struktura klas z podziałem na warstwy
Presentation Layer «form» Customer Application Logic Customer Data Management Customers Data Layer «table» Customers «form» Order Order Orders «table» Orders Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 23/24
Literatura
Dennis A., Wixom B.H., Tegarden D., Systems
Analysis & Design. An Object-Oriented Approach
with UML, John Wiley and Sons, USA, 2002 Dokumentacja i Jakość Oprogramowania Projektowanie systemowe 24/24