Obiektowość


architektura klient-serwer



Pobieranie 6.06 Mb.
Strona3/26
Data28.10.2017
Rozmiar6.06 Mb.
1   2   3   4   5   6   7   8   9   ...   26

architektura klient-serwer (client-server architecture) Architektura sprzętu lub oprogramowania, w której występuje podział na część zlecającą pewne usługi (czyli klienta) oraz część wykonującą te usługi (czyli serwer).

architektura komponentowa (component architecture) Pojęcie w programowaniu obiektowym. W architekturze komponentowej program jest zestawem generycznych komponentów o dobrze zdefiniowanym interfejsie i zachowaniu. Komponenty są łączone przy pomocy oprogramowania pośredniczącego. Przykładami architektury komponentowej są: COM/DCOM, JavaBeans, oraz pakiety ORB wg standardu CORBA.

architektura trzywarstwowa (three-tier architecture, three-tiered architecture) Architektura klient-serwer, która jest podzielona na trzy warstwy: interfejs użytkownika, logikę przetwarzania (reguły biznesu, logikę biznesu) oraz bazę danych. Warstwy te są zaprojektowane i istnieją niezależnie, co ma duże znaczenie dla pielęgnacyjności całego systemu ze względu na możliwość zmian w dowolnej warstwie bez konieczności interwencji w pozostałych warstwach. Często warstwy są zrealizowane na odrębnych platformach: interfejs na MS Windows, logika przetwarzania na serwerze aplikacji i baza danych na serwerze bazy danych. Środkowa warstwa może składać się z wielu warstw, co jest określane jako „architektura wielowarstwowa”.

architektura wielowarstwowa (multi-tiered architecture) Architektura klient-serwer składająca się z wielu warstw z dobrze zdefiniowanym interfejsem pomiędzy warstwami. Patrz też: architektura trzywarstwowa.

argument (argument) Inaczej parametr (formalny lub aktualny) metody, funkcji procedury, wyjątku, itd.

argument aktualny (actual argument) Patrz: parametr aktualny.

argument formalny (formal argument) Patrz: parametr formalny.

Ariane 5 Rakieta kosmiczna będąca efektem europejskiego programu badań kosmicznych (European Space Agency), która 4 czerwca 1996 roku eksplodowała 40 sekund po starcie, przynosząc bezpośrednią stratę 500 mln. dolarów, pośrednie straty szacowane na 2 do 6 mld. dolarów, oraz załamanie się europejskiego programu badań kosmicznych. Przyczyną katastrofy był błąd w oprogramowaniu - najbardziej spektakularny błąd programistyczny, w sensie strat materialnych. Bezpośrednią przyczyną było nie przechwycenie wyjątku przy konwersji liczby 64 bitowej na 16 bitową, co zawiesiło oprogramowanie. Pośrednią przyczyną było przeniesienie fragmentu oprogramowania z poprzedniej wersji Ariane 4. Bertrand Meyer i jego współpracownicy uważają, że przyczyną błędu było niewłaściwe ponowne użycie (reuse) wytworzonych komponentów oprogramowania. Przypadek Ariane 5 uważają za jeden z argumentów za metodyką projektowania poprzez kontrakty (Design By Contracts), która nie dopuściłaby do powstania tego błędu.

http://www.eiffel.com/doc/manuals/technology/contract/ariane/index.html



http://www.esrin.esa.it/htdocs/Press/Press96/ariane5rep.html

asercja (assertion) Warunek wstawiony do programu określający dopuszczalny stan przetwarzania, np. X - Y > 10. Asercja zwykle wiąże wartości jednej lub więcej zmiennych. Nie spełnienie asercji podczas wykonania powoduje sygnalizację błędu.

asocjacja (association) Związek pomiędzy klasami obiektów (np. pokazany niżej związek Zatrudnia między firmami i osobami). Asocjacja może łączyć dwie lub więcej klas (niekoniecznie różnych). Zwykle uważa się, że asocjacja umożliwia przechodzenie (nawigację) pomiędzy powiązanymi nią obiektami w dowolnym kierunku. M.in. z tego powodu asocjacja niekoniecznie musi być utożsamiana z powiązaniami wskaźnikowymi; uważa się, że to pojęcie występuje na wyższym poziomie abstrakcji, zaś wskaźniki mają status techniki implementacyjnej. Praktycznie jednak wskaźnikowa interpretacja asocjacji (binarnych) jest dostatecznie precyzyjna i nie prowadzi do trudności koncepcyjnych lub utraty ogólności.



Asocjacja Zatrudnia łącząca klasę Firma i klasę Osoba

Semantyką asocjacji jest pewna liczba „nitek” (powiązań) łączących obiekty będące wystąpieniami klas połączonych przez asocjację. Przykładowo, poniżej znajduje się pewien stan wystąpień klas Firma i Osoba oraz konkretne powiązania Zatrudnia łączące konkretne osoby z konkretnymi firmami: Madzia i Kasia pracują w Globi, Jasio ma posadę w Auchan, Gucio zaczepił się w Społem, gdzie dorabia także Kasia. Wskaźnikowa interpretacja tych „nitek” oznacza, że każda z nich jest implementowana jako dwa wskaźniki: np. od obiektu Madzia prowadzi wskaźnik do obiektu Globi, oraz od obiektu Globi prowadzi wskaźnik do obiektu Madzia. Niekiedy (np. w UML) asocjacja jest zorientowana i zaznaczona strzałką. W takim przypadku definiuje ona wskaźniki prowadzące w jednym kierunku, zgodnie z zaznaczoną strzałką.





Przykładowa realizacja asocjacji Zatrudnia

Dość częstym błędem popełnianym przez początkujących jest plątanie asocjacji z akcją. W danym przypadku Zatrudnia nie oznacza jakiejkolwiek czynności zatrudniania osoby przez firmę. Asocjacja ta oznacza wyłącznie statyczne połączenie obiektów klas Firma i Osoba. Akcje, które doprowadziły do tego połączenia, nie są odwzorowywane przez asocjację. Są one opisywane przez metody, procedury lub inne byty odwzorowujące zachowanie się obiektów.




Pobieranie 6.06 Mb.

Share with your friends:
1   2   3   4   5   6   7   8   9   ...   26




©operacji.org 2020
wyślij wiadomość

    Strona główna