Projektowanie systemowe

Prezentacja na temat: "Projektowanie systemowe"— Zapis prezentacji:

1 Projektowanie systemowe
Jarosław Kuchta Dokumentacja i Jakość Oprogramowania Projektowanie systemowe

2 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

3 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

4 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

5 Projektowanie systemowe
Strategie projektowe Opracowanie własne Dopasowanie istniejącego oprogramowania Zlecenie na zewnątrz (outsourcing) Dokumentacja i Jakość Oprogramowania Projektowanie systemowe

6 Projektowanie systemowe
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

7 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

8 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

9 Kryteria wyboru strategii
Potrzeby biznesowe Doświadczenie w firmie Umiejętności projektowe Kierownictwo Ograniczenia czasowe Dokumentacja i Jakość Oprogramowania Projektowanie systemowe

10 Macierz alternatyw Alternatywa 1: E-Shop Alternatywa 2: Web Shop
Alternatywa 3: J-Shop Wykonalność organizacyjna Opracowanie własne Dopasowanie gotowego oprogramowanie Wykonalność techniczna Opracowanie w C; Zamówienia przez Opracowanie w C i Javie Opracowanie w Javie Wykonalność ekonomiczna 15 tys. PLN 70 tys. PLN; 30 tys. PLN Inne zalety Duże doświadczenie z C w firmie nabycie doświadczeń z Javą Inne ograniczenia Nie nabywamy doświadczeń Małe doświadczenie z Javą w firmie Dokumentacja i Jakość Oprogramowania Projektowanie systemowe

11 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

12 Projektowanie systemowe
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

13 Projektowanie systemowe
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

14 Projektowanie systemowe
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

15 Projektowanie systemowe
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

16 Projektowanie systemowe
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

17 Typowe warstwy projektowe
Presentation Layer Application Logic Data Management Foundation Data Layer Dokumentacja i Jakość Oprogramowania Projektowanie systemowe

18 Projektowanie systemowe
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

19 Projektowanie systemowe
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

20 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

21 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

22 Projektowanie systemowe
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

23 Przykładowa struktura klas z podziałem na warstwy
Presentation Layer «form» Customer «form» Order Application Logic Customer Order Data Management Customers Orders Data Layer «table» Customers «table» Orders Dokumentacja i Jakość Oprogramowania Projektowanie systemowe

24 Projektowanie systemowe
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