Wykład IX
Projektowanie obiektowe

 

Obiektowość:


  • jest nową ideologią, która zmienia myślenie realizatorów SIZ “zorientowanego na maszynę” na “zorientowane na człowieka”

  • jest konsekwencją kryzysu oprogramowania: kosztów związanych z oprogramowaniem, jego zawodnością i trudną do opanowania złożonością

  • przenika wszelkie fazy projektowania, narzędzia i interfejsy

  • dopracowała się własnej kolekcji pojęć i narzędzi

  • jest na początku swojej drogi i musi walczyć z konserwą i spuścizną poprzednich ideologii

 

Punktem wyjścia w obiektowym tworzeniu systemu informacyjnego jest zawsze pewien model biznesowy.

 

System informacyjny składa się z wielu elementów o zróżnicowanych zadaniach i przeznaczeniu.

 

Orientację w tej złożonej materii ułatwia fakt, że większość systemów informacyjnych ma obecnie strukturę warstwową, składającą się m. in. ze składników wewnętrznych (zintegrowanych z jądrem systemu) oraz składników zewnętrznych (satelitarnych). Dzięki temu współczesne systemy informacyjne odznaczają się dużą elastycznością, co oznacza, że można do nich w każdej chwilo dołączać nowe komponenty.

 

Struktura warstwowa SI

Struktura warstwowa SI

 

Podstawowe koncepcje projektowania obiektowego


Koncepcja obiektu

 

  • stan wewnętrzny
  • sposób zachowania
  • tożsamość unikatowa

 

Zasada abstrakcji

 

  • kompozycyjnej
  • uogólniającej

 

Zasada hierarchizacji

 

  • kompozycyjnej
  • dziedziczenia

 

Zasada modularności


Zasada enkapsulacji


 

Modelowanie i projektowanie obiektowe – analiza


Identyfikacja kluczowych abstrakcji


  • podejście klasyczne – kategorie a' priori (rzeczy, zdarzenia, role, miejsca, struktury)
  • analiza zachowań - odpowiedzialności, funkcji systemu, analiza dziedziny rozwiązań

 

Konstrukcja scenariuszy

 

Zdefiniowanie odpowiedzialności klas


 

Pojęcie klasy

Klasa

 

Projektowanie


  • Specyfikacja warstwy zewnętrznej klasy
  • Konstrukcja modeli współpracy obiektów oraz mechanizmów współpracy klas – powstają struktury obiektowe i klasowe
  • Zdefiniowanie architektury systemu

 

Diagramy klasowe

diagramy klasowe

 

Modele SI wg Jacobsona

 

  • Model przypadków użycia: definiuje zewnętrze (aktorów = systemy zewnętrzne = kontekst) oraz wnętrze (przypadki użycia), określające zachowanie się systemu w interakcji z jego zewnętrzem.

  • Obiektowy model dziedziny: odwzorowywuje byty świata rzeczywistego (czyli dziedziny problemowej) w obiekty istniejące w systemie.

  • Obiektowy model analityczny: efekt fazy analizy dla konkretnego zastosowania.

  • Model projektowy (logiczny): opisuje założenia przyszłej implementacji.

  • Model implementacyjny (fizyczny): reprezentuje konkretną implementację systemu.

  • Model testowania: określa plan testów, specyfikuje dane testowe i raport

 

Modele wymagają odpowiednich procesów ich tworzenia:

 

Proces analizy wymagań, składa się z dwóch podprocesów:
  • proces modelowania przypadków użycia
  • proces analizy związany z obiektowym modelem analitycznym

 

Proces projektowania

Proces implementacji

Proces testowania

 

Model analityczny

 

Ujęcie w modelu pewnych elementów dziedziny problemu nie będących częścią systemu czyni model bardziej zrozumiałym. Przykładem jest ujęcie w modelu systemów zewnętrznych, z którymi system ma współpracować.

 

Na etapie modelowania może nie być jasne, które elementy modelu będą realizowane przez oprogramowanie, a które w sposób sprzętowy lub ręcznie.

 

Celem budowy modelu analitycznego może być wykrycie tych fragmentów dziedziny problemu, których wspomaganie za pomocą innego oprogramowania będzie szczególnie przydatne

 

Model wymagań

 

Składowe:

 

  • Model przypadków użycia

  • Obiektowy model analityczny

 

Model przypadków użycia wykorzystuje dwa podstawowe pojęcia:

 

  • Aktor - Reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik; (np. kierownik, urzędnik, klient)

  • Przypadek użycia - Reprezentuje sekwencję operacji, niezbędnych do wykonania zadania zleconego przez aktora, np. potwierdzenie pisma, złożenie zamówienia, itp.

 

Model przypadków użycia

Model przypadków użycia

 

Klasy jako podstawowe pojęcie projektowania obiektowego

 

W projektowaniu obiektowym kluczowym pojęciem jest klasa.

 

Cechą charakterystyczną koncepcji klasy jest ukrycie danych przed obiektami zewnętrznymi.

 

Obiekty zewnętrzne mają dostęp wyłącznie do funkcji (nazywanych też metodami) za pomocą których mogą zlecać wykonanie określonych operacji na danych.

 

Takie zamknięcie danych w „pancerzu” skojarzonych z nimi metod nazywa się enkapsulacją.


Obiekt

Obiekt

 

W takim systemie każdy z obiektów może być programowany przez oddzielnego programistę i nie ma potrzeby uzgadniania w zespole projektowym wewnętrznych rozwiązań poszczególnych obiektów.

 

W podejściu obiektowym wszystkie obiekty mogą być aktywne równocześnie, a każdy z nich wykonuje swoją część zadania.

 

Z jednej klasy można też wygenerować dalsze klasy. Klasy potomne dziedziczą część właściwości klasy macierzystej. W ten sposób powstaje hierarchia klas i podklas, bardzo ułatwiająca operowanie złożonymi obiektami. Mechanizm ten nazywamy dziedziczeniem.

 

Dziedziczenie

Dziedziczenie

 

Budowa systemu w podejściu obiektowym polega na zestawianiu go z klas, których część może być tworzona specjalnie dla danego systemu, ale większość pochodzi z zasobów przeznaczonych do wielokrotnego użytku.

 

Obiekty są od siebie izolowane, ale porozumiewają się poprzez komunikaty.Taki sam komunikat kierowany do różnych obiektów może wywołać różne działania – taka właściwość nosi miano polimorfizmu.

 

Polimorfizm

Polimorfizm