Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. Projektowanie oprogramowania cd. 1/34

Projektowanie oprogramowania cd. 2/34 Modelowanie CRC Modelowanie CRC (class-responsibility-collaborator) Metoda identyfikowania poszczególnych klas i definiowania ich odpowiedzialności Kryteria wyboru obiektów: przechowywane informacje potrzebne usługi więcej niż jeden atrybut wspólne atrybuty wspólne operacje najważniejsze wymagania

Projektowanie oprogramowania cd. 3/34 Modelowanie CRC Cechy klasy: materialność inkluzywność sekwencyjność trwałość integralność

Projektowanie oprogramowania cd. 4/34 Modelowanie CRC Przydzielanie klasom odpowiedzialności: Inteligencja systemu powinna być równomiernie rozmieszczona. Odpowiedzialności należy opisywać jak najbardziej ogólnie. Zachowanie związane z danymi należy wiązać z tą klasą, w której te dane się znajdują. Informacje o pojedynczych bytach należy umieszczać w jednej klasie, a nie rozdzielać między klasy. Jeżeli to możliwe warto rozdzielić odpowiedzialności między klasy.

Projektowanie oprogramowania cd. 5/34 Modelowanie CRC Kooperacje kooperacje to związki między klasami typu: jest-częścią wie-o zależy-od

Projektowanie oprogramowania cd. 6/34 Model obiekt-związek związek to zależność między klasami w systemach obiektowych najczęściej związki skierowane związki można ustalić, analizując wyrażenia oznaczające czynności w opisie działania systemu i w opisach przypadków użycia

Projektowanie oprogramowania cd. 7/34 Model obiekt-związek Tworzenie modelu obiekt-związek Na podstawie kart CRC naszkicować sieć kooperacji obiektów Sięgając ponownie do kart CRC, przydzielić nazwy związkom na podstawie odpowiedzialności i kooperacji Na obu końcach każdego nazwanego związku należy zaznaczyć jego liczebność

Projektowanie oprogramowania cd. 8/34 Model obiekt-związek Rysunek: Model obiekt-związek

Projektowanie oprogramowania cd. 9/34 Model zachowania obiektów Przygotowanie zrozumienie przypadków użycia identyfikacja zdarzeń sterujących przebiegiem interakcji i zrozumienie związków tych zdarzeń z poszczególnymi obiektami przygotowanie diagramu sekwencji dla przypadku użycia sporządzić diagram przejść pomiędzy stanami dla systemu sprawdzić poprawność przygotowanego diagramu

Projektowanie oprogramowania cd. 10/34 Zagadnienia związane z projektowaniem Kryteria projektowania: łatwość dekompozycji łatwość składania łatwość zrozumienia ciągłość ochrona

Projektowanie oprogramowania cd. 11/34 Czynności wspólne dla procesów projektowania architektonicznego Czynności wspólne: Strukturalizacja systemu Modelowanie sterowania Podział na moduły Podsystem a moduł podsystem system na własnych prawach moduł komponent systemu, który nie może być traktowany jako osobny system

Projektowanie oprogramowania cd. 12/34 Zakres modeli architektonicznych Opracowywane modele architektoniczne mogą obejmować: Statyczny model strukturalny Model dynamiczny procesu Model interfejsów Model związków

Projektowanie oprogramowania cd. 13/34 Czynniki mające wpływ na architekturę systemu Styl i struktura mogą zależeć od: Efektywność Zabezpieczenie Bezpieczeństwo Dostępność Zdatność do pielęgnacji

Projektowanie oprogramowania cd. 14/34 Typowe przykłady architektury Model repozytorium Model klient-serwer Model wielowarstwowy Modele sterowania: sterowanie scentralizowane sterowanie sterowane zdarzeniami

Projektowanie oprogramowania cd. 15/34 Strukturalizacja systemu Rysunek: Diagram blokowy systemu sterującego robotem

Projektowanie oprogramowania cd. 16/34 Model repozytorium Sposoby wymiany informacji między podsystemami Wszystkie współdzielone dane znajdują się w centralnej bazie danych repozytorium Każdy podsystem prowadzi własną bazę danych wymiana danych przez przesyłanie komunikatów.

Projektowanie oprogramowania cd. 17/34 Model repozytorium Cechy współdzielonego repozytorium: Efektywny sposób współdzielenia dużych ilości danych. Twórcy podsystemów muszą uzgodnić model danych repozytorium. Podsystemy tworzące dane nie muszą zajmować się przetwarzaniem danych. Ewolucja systemu może być trudna z uwagi na ustalony format danych.

Projektowanie oprogramowania cd. 18/34 Model repozytorium Cechy współdzielonego repozytorium: Czynności takie jak tworzenie kopii zapasowej, sterowanie zabezpieczeniami i dostępem oraz odtwarzanie po awarii są scentralizowane. Różne podsystemy mogą mieć odmienne wymagania stawiane zabezpieczeniom oraz strategii odtwarzania i kopiom zapasowym. Model współdzielenia jest widoczny przez schemat repozytorium. Może być trudno rozproszyć repozytorium na kilka maszyn.

Projektowanie oprogramowania cd. 19/34 Model repozytorium Rysunek: Architektura zintegrowanego zestawu narzędzi CASE

Projektowanie oprogramowania cd. 20/34 Model klient-serwer Główne komponenty: Zbiór samodzielnych serwerów oferujących usługi innym systemom. Zbiór klientów, korzystających z usług oferowanych przez serwery. Sieć, która daje klientom dostęp do tych usług.

Projektowanie oprogramowania cd. 21/34 Model klient-serwer Rysunek: Architektura systemu biblioteki filmów i zdjęć

Projektowanie oprogramowania cd. 22/34 Model maszyny abstrakcyjnej Rysunek: Model maszyny abstrakcyjnej systemu zarządzania wersjami

Projektowanie oprogramowania cd. 23/34 Modele sterowania Sterowanie scentralizowane Jeden podsystem całościowo odpowiedzialny za sterowanie, który uruchamia i zatrzymuje inne podsystemy. Sterowanie zdarzeniowe Informacja o zdarzeniu nie jest wbudowana w podsystem, ale każdy system może reagować na zdarzenia zachodzące na zewnątrz.

Projektowanie oprogramowania cd. 24/34 Sterowanie scentralizowane Klasy sterowania scentralizowanego: Model wywołanie-powrót model wywoływania podprogramów Model menedżera wykorzystywany w programach współbieżnych

Projektowanie oprogramowania cd. 25/34 Model wywołanie-powrót Rysunek: Model sterowania wywołanie-powrót

Projektowanie oprogramowania cd. 26/34 Model menedżera Rysunek: Scentralizowany model sterowania dla systemu czasu rzeczywistego

Projektowanie oprogramowania cd. 27/34 Systemy sterowane zdarzeniami Modele sterowania zdarzeniowego: Model rozgłaszania Modele z przerwaniami

Projektowanie oprogramowania cd. 28/34 Model rozgłaszania Rysunek: Model sterowania z wybiórczym rozgłaszaniem

Projektowanie oprogramowania cd. 29/34 Modele z przerwaniami Rysunek: Model sterowania z przerwaniami

Projektowanie oprogramowania cd. 30/34 Poprawność projektu Poprawny projekt jest: kompletny niesprzeczny spójny zgodny z regułami składniowymi notacji

Projektowanie oprogramowania cd. 31/34 Przykłady poprawności Cechy poprawności diagramu klas: acykliczność związków generalizacji-specjalizacji opcjonalność cyklicznych związków klas i związków agregacji brak klas nie powiązanych z innymi umieszczenie w specyfikacji metod informacji o danych wejściowych i wyjściowych

Projektowanie oprogramowania cd. 32/34 Przykłady poprawności Cechy poprawności diagramu interakcji: istnienie metod wywoływanych przez komunikaty w klasach, do których wysyłane są te komunikaty umieszczenie w specyfikacji metod, które te komunikaty wysyłają informacji o tym fakcie Cechy poprawności diagramu stanów: brak stanów, do których nie ma możliwości przejścia brak stanów, z których nie ma możliwości wyjścia jednoznaczność przejść ze stanów pod wpływem poszczególnych zdarzeń

Projektowanie oprogramowania cd. 33/34 Jakość projektu Kryteria decydujące o jakości projektu spójność stopień powiązania składowych przejrzystość

Projektowanie oprogramowania cd. 34/34 W wykładzie wykorzystano materiały Jaszkiewicz A.: Inżynieria oprogramowania, Helion, Gliwice 1997, Pressman R. S.: Praktyczne podejście do inżynierii oprogramowania, WNT, Warszawa 2004, Sommerville I.: Inżynieria oprogramowania, WNT, Warszawa 2003