Projektowanie logiki aplikacji

Transkrypt

1 Jarosław Kuchta Projektowanie Aplikacji Internetowych Projektowanie logiki aplikacji

2 Zagadnienia Rozproszone przetwarzanie obiektowe (DOC) Model klas w projektowaniu logiki aplikacji Klasy encyjne a klasy zarządzające Miejsce usług w logice aplikacji Projektowanie Aplikacji Internetowych Projektowanie architektury systemu internetowego 2

3 Rozproszone przetwarzanie obiektowe (Distributed Object Computing) Stosuje się: gdy logika jest podzielona na kilka fizycznie odległych komputerów gdy wykorzystuje się model obiektowy przetwarzania gdy obiekty przesyła się przez sieć Trzeba zapewnić: spójność definicji klas po obu stronach kanału komunikacji jednoznaczną i spójną tożsamość obiektów Projektowanie Aplikacji Internetowych Projektowanie architektury systemu internetowego 3

4 Model klas w analizie i w projektowaniu W analizie: Uzupełnienie i uszczegółowienie Modeluje świat rzeczywisty Potrzebny do zrozumienia dziedziny zastosowania Zwykle pojedynczy diagram klas Zawiera najważniejsze klasy, właściwości, relacje Nie zawiera klas kontenerowych Właściwości nie muszą mieć określonych typów Można stosować dziedziczenie wielokrotne Można stosować asocjacje wielostronne Nie określa się widoczności cech, wszystkie są publiczne Raczej nie definiuje się operacji lub tylko uogólnione operacje Raczej nie określa się parametrów operacji W projektowaniu: Modeluje klasy programowe Potrzebny do zaplanowania struktury logicznej kodu Jeden lub kilka diagramów klas Zawiera wszystkie ważne klasy, właściwości, relacje Zawiera klasy kontenerowe Właściwości muszą mieć określone typy Nie stosuje się dziedziczenia wielokrotnego, lecz interfejsy Raczej nie stosuje się asocjacji wielostronnych Określa się widoczność cech jako publiczne, prywatne, chronione Definiuje się operacje, zwłaszcza w projekcie warstwy usługowej Koniecznie określa się parametry operacji Projektowanie Aplikacji Internetowych Projektowanie architektury systemu internetowego 4

5 Przykład uzupełnienie struktury klas Model analityczny Model projektowy specjalizacja Dokument generalizacja Dokument Dokument księgowy Dokument magazynowy Faktura VAT Wydanie Towaru Faktura VAT Faktura Korygująca Wydanie Towaru Zwrot Towaru Projektowanie Aplikacji Internetowych Projektowanie architektury systemu internetowego 5

6 Klasy encyjne (model biznesowy) Model biznesowy klas opisuje klasy pochodzące z analizy dziedziny problemu. Klasy analityczne stają się klasami encyjnymi reprezentują pojęcia (byty, czyli encje) obiekty, na których operuje aplikacja. Klasy encyjne muszą być identyfikowane niezależnie od ich właściwości biznesowych (np. wewnętrzny identyfikator faktury niezależny od numeru faktury w ewidencji). Klasy encyjne muszą być serializowalne (identyczne instancje w różnych pniach aplikacji). Klasy encyjne mają właściwości odpowiadające właściwościom obiektów ze świata rzeczywistego, ale muszą też mieć właściwość identyfikującą (identyfikator liczbowy), która jest sztucznie dodana. Klasa encyjna może mieć operacje przetwarzające właściwości (np. Nazwisko_i_imię = Nazwisko + " " + Imię), ale każdy obiekt klasy encyjnej ma dostęp tylko do własnych właściwości (nie ma dostępu do właściwości innych obiektów). Projektowanie Aplikacji Internetowych Projektowanie architektury systemu internetowego 6

7 Klasy zarządzające Klasa encyjna nie może mieć operacji wymagających dostępu do innych obiektów (np. jak nadać unikatowy numer faktury nie mając dostępu do numerów wszystkich faktur). Potrzebne są klasy osobne zarządzające (menedżery), z których każda zarządza obiektami pewnej klasy encyjnej mając dostęp do całego zbioru obiektów tej klasy i opcjonalnie do zbiorów obiektów innych klas. W klasie zarządzającej deklaruje się operacje stereotypu «new» i «delete». Należy też deklarować operacje zmiany, jeśli zmiana wykracza poza tylko jeden obiekt encyjny. Klasa zarządzająca może deklarować złożone operacje, które wymagają zmiany wielu obiektów i współdziałania wielu klas zarządzających ze sobą. Projektowanie Aplikacji Internetowych Projektowanie architektury systemu internetowego 7

8 Miejsce usług w logice aplikacji W przypadku aplikacji wielowarstwowej część operacji z klas zarządzających deklaruje się jako usługi (zwłaszcza usługi webowe). Usługa webowa składa się z interfejsu, w którym zadeklarowane są operacje udostępniane przez klasę zarządzającą i klasy implementującej ten interfejs. Usługa webowa umożliwia tworzenie różnych aplikacji (o różnej logice) wykorzystujących wspólny, bazowy zbiór operacji na encjach. Klasa zarządzająca może wprost implementować operacje usługowe zadeklarowane w interfejsie. Innym rozwiązaniem jest zadeklarowanie osobnej klasy usługowej implementującej operacje usługowe przy wykorzystaniu kilku klas zarządzających. Encje, interfejsy i klasy usługowe wydziela się do osobnej, niższej warstwy, a w warstwie logiki aplikacji pozostawia się tylko klasy właściwe dla danej, konkretnej aplikacji. Projektowanie Aplikacji Internetowych Projektowanie architektury systemu internetowego 8

9 Literatura Dennis A., Wixom B.H., Tegarden D.: Systems Analysis & Design. An Object-Oriented Approach with UML, John Wiley and Sons, USA, 2002 Bass L., Clements P., Kazman R.: Architektura oprogramowania w praktyce, WNT, Warszawa, 2006 Hofmeister C., Nord R., Soni D.: Tworzenie architektury oprogramowania, WNT, Warszawa, 2006 Projektowanie Aplikacji Internetowych Projektowanie architektury systemu internetowego 9