Programowanie Obiektowe - Język UMLkolos.math.uni.lodz.pl/~archive/Programowanie obiektowe/uml.pdf · UML (Unified Modeling Language), zunifikowany język do modelowania, jest następcąi

Programowanie Programowanie ObiektoweObiektowe

JJęęzyk UMLzyk UML

2

UML (Unified Modeling Language), zunifikowany język do modelowania, jest następcą i syntezą notacji występujących w obiektowych metodykach analizy i projektowania systemów informatycznych, które pojawiły się w końcu lat 80-tych i na początku lat 90-tych.

Jest on oparty o pojęcia obiektowości, takie jak obiekty, klasy, atrybuty, związki, agregacje, dziedziczenie, metody i inne.

UML powstał w wyniku połączonych wysiłków trzech znanych metodologów: Grady Boocha, Ivara Jacobsona i Jamesa Rumbaugh'a. Są oni autorami popularnych metodyk: OODA (Booch), Objectory (Jacobson) i OMT (Rumbaugh).

UML jest zestawem pojęć oraz notacji graficznych (diagramów), które pozwalająwszechstronnie odwzorować modelowaną dziedzinę problemu, założenia projektowanego systemu informatycznego, oraz większość istotnych aspektów jego konstrukcji.

UML jest obecnie wspomagany przez wiele narzędzi CASE. Został on także zaakceptowany jako przemysłowy standard przez ciało standardyzacyjne OMG rozwijające standard CORBA.

Programowanie obiektowe (UML)Programowanie obiektowe (UML)WstWstęępp

3

Przypadki użycia (use cases) były w sposób intuicyjny stosowane w tradycyjnym projektowaniu systemów informatycznych na długo przed pojawieniem się metodyk obiektowych.

Kariera przypadków użycia w literaturze z zakresu projektowania SI zaczęła się od wprowadzenia dla nich specjalnej nazwy, przypisaniu tej nazwie określonego znaczenia i rozpropagowanie tego pojęcia jako specjalnego paradygmatu projektowania.

Przypadek użycia jest to pewna nazwana lub dobrze określona interakcja pomiędzyużytkownikiem a systemem komputerowym. Przypadek użycia odwzorowuje pewną funkcję systemu w taki sposób, w jaki będą ją

widzieć jego przyszli użytkownicy. Dla dużych systemów o wielu złożonych i wzajemnie powiązanych funkcjach tego rodzaju podejście ma ogromny sens. Pozwala ono zapomniećo strukturze/architekturze systemu i jego detalach technicznych i skoncentrowaćsię na zewnętrznych funkcjach systemu.

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram przypadkDiagram przypadkóów uw użżyciaycia

4

Podejście do projektowania od strony przypadków użycia jest uważane za znacznie bardziej zdrowe od podejść „technokratycznych”, ponieważ sprzyja ono punktowi widzenia, w którym centralnym ośrodkiem zainteresowania staje się człowiek - przyszły użytkownik systemu - a nie budowa mechanizmu systemu.

Jak pokazały doświadczenia wielu projektów, jedną z głównych przyczyn ich niepowodzeńbyło zbytnie skoncentrowanie się projektantów na detalach technicznych, z pominięciem lub brakiem dostatecznej uwagi dla interakcji pomiędzy użytkownikami a systemem komputerowym.


5

Podejście od strony przypadków użycia ma przede wszystkim na względzie określenie wymagań na projektowany system.

Celem tej metody jest:• Głębsze zrozumienie użycia systemu będącego przedmiotem procesu projektowania.• Zwiększenie stopnia świadomości analityków i projektantów co do celów tego systemu.• Umożliwienie interakcji zespołu projektowego z przyszłymi użytkownikami systemu.• Weryfikacja poprawności i kompletności projektu.• Ustalenie wszystkich strukturalnych i funkcjonalnych własności systemu.• Ustalenie składowych systemu i związanego z nimi planu konstrukcji systemu.• Dostarczenie podstawy do sporządzenia planu testów systemu.


6

Model przypadków użycia dostarcza bardzo abstrakcyjnego poglądu na system z pozycji aktorów, którzy go używają. Nie włącza jakichkolwiek szczegółów, co pozwala wnioskować o systemie na odpowiednio ogólnym, abstrakcyjnym poziomie. Diagram przypadków użycia zawiera znaki graficzne oznaczające aktorów (ludziki) oraz przypadki użycia (owale z wpisanym tekstem).

Te oznaczenia połączone są liniami odwzorowującymi powiązania poszczególnych aktorów zposzczególnymi przypadkami użycia.


Aktor

Przypadek uzycia

Aktor

Przypadek uzycia

7

Podstawowym zastosowaniem takich diagramów jest dialog z użytkownikami zmierzający do sformułowania wymagań na system. Stąd wynika, że diagramy i opis przypadków użycia muszą być bardzo naturalne, proste i nie mogą wprowadzać elementów komputerowej egzotyki i żargonu.

W późniejszej fazie przypadki użycia mogą być wyspecyfikowane bardziej precyzyjnie przypomocy notacji lub diagramów obiektowych. Następną fazą w postępowaniu opartym na przypadkach użycia jest rozpisanie ich przy

pomocy notacji wprowadzanych w innych diagramach UML. Należy podkreślić, że tworzenie przypadków użycia jest niezdeterminowane i subiektywne. Na ogół różni analitycy tworzą różne modele.

Metoda przypadków użycia wymaga od analityka określenia wszystkich aktorówzwiązanych w jakiś sposób z projektowanym systemem. Każdy aktor używać lub będzie używać systemu na kilka specyficznych sposobów (przypadków użycia).

Zazwyczaj aktorem jest osoba, ale może nim być także pewna organizacja lub inny system komputerowy.


8

Należy zwrócić uwagę, że metoda modeluje aktorów, a nie konkretne osoby. Jedna osoba może pełnić rolę wielu aktorów; np. być jednocześnie sprzedawcą i klientem.Jeden aktor może odpowiadać wielu osobom, np. urzędnik.

Aktor jest:• pierwotną przyczyną napędzającą przypadki użycia. Jest on sprawcą zdarzeń

powodujących uruchomienie przypadku użycia.• odbiorcą informacji wyprodukowanych przez przypadki użycia.

Aktor reprezentuje rolę, którą może grać w systemie jakiś jego użytkownik, np. kierownik, urzędnik, klient. Można tworzyć aktorów abstrakcyjnych, na podobieństwo klas abstrakcyjnych. Np. aktor „urzędnik” jest nadklasą dla aktorów „kasjer” i „dyrektor”; powiązania z konkretnymi przypadkami użycia mogą być ustalone zgodnie z tą hierarchiąklas aktorów.


9

Przypadek użycia reprezentuje:• sekwencję operacji lub transakcji wykonywanych przez system w trakcie interakcji

z użytkownikiem; np. potwierdzenie pisma, złożenie zamówienia. • przepływ zdarzeń w systemie i są uruchamiane (inicjowane) przez aktorów.

Przypadek użycia jest zwykle charakteryzowany przez krótką nazwę. Opis przypadku użycia może być jednak dowolnie rozbudowany, w szczególności może zawierać następujące fragmenty:

• Jak i kiedy przypadek użycia zaczyna się i kończy.• Opis interakcji przypadku użycia z aktorami, włączając w to kiedy interakcja ma miejsce

i co jest przesyłane.• Kiedy i do czego przypadek użycia potrzebuje danych zapamiętanych w systemie, lub jak

i kiedy zapamiętuje dane w systemie.• Wyjątki przy przepływie zdarzeń.


10

Typowa dokumentacja przypadków użycia powinna zawierać następujące elementy:• Krótki opis przypadku użycia.• Przepływ zdarzeń opisany nieformalnie.• Związki pomiędzy przypadkami użycia.• Uczestniczące obiekty.• Specjalne wymagania (np. czas odpowiedzi, wydajność).• Obrazy interfejsu użytkownika.• Ogólny pogląd na przypadki użycia (powiązania w postaci diagramów).• Diagramy interakcji dla każdego aktora.


11

UML wprowadza także bardzo proste powiązania pomiędzy przypadkami użycia, oznaczanestrzałkami dodatkowymi napisami «extend» (rozszerza), <<include>> (zawiera).Przypadek użycia podłączony przez strzałkę «extend» oznacza, że niekiedy (nie zawsze)

dany przypadek użycia jest rozszerzony przez inny przypadek użycia. Przypadek użycia podłączony przez strzałkę «include» oznacza, że pewien przypadek

zawiera zachowanie innego przypadku, który warto jest wyodrębnić ze względu na późniejszą możliwość uniknięcia wielokrotnej implementacji tego fragmentu.


Place Order

Order Product Arrange Payment

Request Catalog

<<include>> <<include>>

<<extend>>

12

Pewne fragmenty diagramu przypadków są grupowane jako podsystemy. Graficznie granice systemu (system boundary) oznaczane sa jako prostokąt otaczający wszystkie elementy wchodzące w skład systemu.


Place Order


Request Catalog

CustomerSalesperson

Selling system


<<extend>>

13

Między aktorami i przypadkami użycia mogą zachodzić relacje generalizacji. Relacja ta oznacza iż pewien byt jest uogólnieniem innego lub innych. Z drugiej strony można powiedzieć, że określone byty są szczególnymi przypadkami swojej generalizacji.


PracownikOsoba

Pracownik naukowy

Kierownik

Kierownik katedry

Przekazanie dokumentu

Oddanie indeksu

Oddanie karty zaliczeniowej

Przekazanie podania

Przekazanie podania o urlop

14

Między aktorami, a przypadkami mogą istnieć relacje o różnej krotności. Krotność powiązania dotyczy obu stron relacji wiążącej. Wyróżnia się następujące krotności:

1 – dokładnie jeden0..1 – 0 lub 11..* – 1 lub więcejn..m – nie mniej niż n i nie więcej niż m* – dowolna ilość


Place Order


Request Catalog

Customer Salesperson

Selling system


<<extend>>1

*

1 * 1*

15

W celu umieszczenia dodatkowych komentarzy umieszcza się notki zakotwiczone do bytów których dotyczą.


Place Order


Request Catalog

Customer Salesperson

Selling system

Asocjacja jeden do wielu

Granice systemu

Pracownik sklepu lub akwizytor


<<extend>>1

*

1 * 1*

16

Diagram klas (dawniej: diagram asocjacji klas lub model obiektowy) jest pojęciem kluczowym we wszystkich metodykach obiektowych. Często diagram klas odpowiada diagramowi encja-związek rozbudowanym o dodatkowe elementy.

W odróżnieniu od diagramów encja-związek diagramy klas posiadają metody przypisane do specyfikowanych klas. Poza tym pojawiają się w diagramach klas różnorodne pomocnicze oznaczenia.

Diagram klas pokazuje klasy w postaci pewnych oznaczeń graficznych powiązanych w siećzależnościami należącymi do trzech kategorii:

• Dziedziczenie (inheritance) - ustalenie związku generalizacji/specjalizacji pomiędzy klasami.

• Asocjacja (association) - dowolny związek pomiędzy obiektami dziedziny przedmiotowej, który ma znaczenie dla modelowania.

• Agregacja (aggregation) - stosunek całość-część pomiędzy obiektami z modelowanej dziedziny przedmiotowej jest to szczególny przypadek asocjacji.

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram klasDiagram klas

17

Diagram klas w identycznej wersji jest stosowany zarówno do zapisu wyników analizy jak i dospecyfikowania założeń projektowych. Diagramy klas są podstawą dowolnej analizy i

dowolnego projektu. Żaden projekt obiektowy nie może się obejść bez diagramu klas.

Podstawowe zastosowania diagramów klas:• Zapis modelu pojęciowego. Diagramy reprezentują pojęcia w dziedzinie zastosowań, które

aktualnie podlegają analizie. Model pojęciowy nie musi być związany z jakimkolwiek oprogramowaniem.

• Sformalizowana specyfikacja danych i metod. Jest ona bardziej związana z oprogramowaniem, ale dotyczy jego zewnętrznego opisu (interfejsów) bez wchodzenia w szczegóły implementacyjne. Często podkreślaną zaletą obiektowości jest hermetyzacja, polegająca na oddzieleniu specyfikacji od implementacji. Dla wielu celów zależy nam wyłącznie na określeniu cech zewnętrznych pewnych bytów programistycznych (obiektów, metod, itd.), bez wchodzenia w szczegóły.

• Implementacja. W tym zastosowaniu diagram klas może służyć bezpośrednio jako graficzny środek pokazujący szczegóły implementacji klas, np. w C++.


18

Elementy składowe diagramów klas.Klasa:

Podstawowa postać graficzna:

Postacie graficzne przykładowych stereotypów klas:

Aktor: Aktor biznesowy:

Dokument biznesowy:

Tabela:


Klasa

Klasa Klasa

Klasa

Klasa

19

Elementy składowe klasy:

Klasa abstrakcji:

Atrybuty:

Operacje:


Klasa

KlasaAtrybut_PublicznyAtrybut_Prywatny : int = 5Atrybut_Chroniony : unsignedStatyczny : float

Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)Operacja_Prywatna() : intOperacja_Chroniona(Parametr)

20

Szablon klasy:


Przypisanie<<bind>>

T


Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)Operacja_Prywatna() : intOperacja_Chroniona(Parametr)Dodaj(T) : bool

21

Pakiet:

Pakiety służą do grupowania elementów diagramów.


Pakiet A Pakiet B

Klient Dostawca

22

Interfejs:Interfejs reprezentuje zestaw operacji, które określają usługi oferowane przez klasę.Nie posiadają atrybutów i powiązań. Posiadają tylko operacje. Mogą one posiadać związki

generalizacji.



Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)Operacja_Prywatna() : intOperacja_Chroniona(Parametr)

Interfejs

23

Użycie interfejsu przez klasę.

Postać rozwinięta:

Postać uproszczona:


OsobaNumer : longImie : AnsiStringNazwisko : AnsiString

getImie() : AnsiStringgetNazwisko() : AnsiString

DanePersonalne


Kartoteka <<use>>



DanePersonalne


<<Interface>>

Kartoteka <<use>>

24

Związki:

W diagramie klas występują następujące typy powiązań.• powiązanie,• zależność,• generalizacja,• realizacja.


25

Powiązanie:

Powiązanie jest związkiem strukturalnym, który pokazuje że obiekty jednego elementu sąpołączone z obiektami innego.

Połączenie można uzupełnić o następujące elementy:• nazwa,• rola,• liczebność,• nawigacja,• agregacja,• rodzaj agregacji,• kwalifikacja,• klasa powiązania,• ograniczenia.


Książka Biblioteka

26

Nazwa powiązania:

Rola:

Liczebność:

Nawigacja:


Element Zbiór10..*

Udostępnianie+Książka +Biblioteka

0..* 1

Element Zbiór10..*


0..* 1

Element Zbiór10..*

Udostępnianie+Książka #Biblioteka

0..* 1

Element Udostępnianie Zbiór

27

Agregacja:

Agregacja całkowita:

Kwalifikacja:

Klasa powiązania:


Element Zbiór10..*


0..* 1

Element Zbiór1

ID_Elementu : long0..*

Udostępnianie+Książka+Biblioteka

0..* 1ID_Elementu : long

Element Zbiór10..*


0..* 1

ZbiórElement1

ID_Elementu : long

0..*

#Biblioteka

1

+Książka

0..*

ID_Elementu : longUdostępnianie

Położenie

28

Ograniczenia:

Rodzaje ograniczeń:• implicit – związek nie jest jawny (pojęciowy),• ordered – zbiór obiektów jest uporządkowany,• changeable – wiązanie między obiektami mogą być dodawane, usuwane i modyfikowane,• addOnly – nowe wiązania można dodawać do zbioru wartości atrybutu, ale raz dodane

nie mogą być modyfikowane ani usuwane,• frozen – wartość nie może być zmieniana po zainicjowaniu obiektu, żadne nowe elementy

nie mogą być dodane do zbioru wartości.


ZbiórElement1

ID_Elementu : long

0..n

#Biblioteka+Książka Udostępnianie

Położenie

10..n

ID_Elementu : long

{ordered}

29

Ograniczenia:




Przedsiębiortstwo0..*0..*

0..*1

Pracuje

Kieruje0..* 0..*

1 0..*

{subset}



1

0..*

0..*1

0..*0..*Kieruje

{subset}

0..*

0..*Przedsiębiortstwo

{xor}

Konto

30

Zależność:

Zależność jest to związek użycia. Zmiany dokonane w definicji jednego elementu mogą miećwpływ na inny element.


Pakiet A Pakiet B

Klient Dostawca

DanePersonalne


<<Interface>>

Kartoteka <<use>>

31

Stereotypy ograniczeń:• bind• derive• friend• use• access• import


32

Stereotyp zależności: bind

Źródło tworzy egzemplarz wzorca docelowego z użyciem danych parametrów aktualnych.


Przypisanie

T


Operacja_Publiczna(Parametr_1 : int, Parametr_2 : double = 5.0)Operacja_Prywatna() : intOperacja_Chroniona(Parametr)Dodaj(T) : bool

<<bind>>

33

Stereotyp zależności: derive

Źródło można wyznaczyć na podstawie celu.

Stereotyp zależności: friend

Źródło można szczególny dostęp do wnętrza celu.


DataUrodzenia Wiek<<derive>>

PracownikID_Pracownik : longStanowisko : AnsiString

<<friend>> ListaPłac

34

Stereotyp zależności: use

Znaczenie bytu źródłowego zależy od znaczenia części publicznej celu

Stereotyp zależności: access

Źródło ma prawo dostępu do bytów pakietu docelowego.

Stereotyp zależności: import

Zawartość publiczna pakietu docelowego zostaje dołączona do źródła.


DanePersonalne


<<Interface>>

Kartoteka <<use>>

<<access>>Pakiet A Pakiet B

Pakiet A <<import>> Pakiet B

35

Generalizacja:

Generalizacja jest to związek między elementem ogólnym, a specyficznym jego rodzajem. Potomek dziedziczy strukturę i zachowanie po przodku (uwzględniając zakresy widoczności).





PracownikNaukowyStopienNaukowy : AnsiString

Dziekan

Potomek dziedziedziczy calą implementację, ale nie udostępnia jako publicznych jego interfejsów i nie realizuje ich. (Dziedziczenie prywatne).

<<implementation>>

{incomplete}

Kierownik

Nadzór

36

Ograniczenia generalizacji:• disjoint – obiekty przodka mogą mieć nie więcej niż jednego potomka jako typ.• overlapping – obiekty mogą posiadać dwóch lub więcej potomków jako typ• complete – wszyscy potomkowie w uogólnieniu zostali w modelu uwzględnieniu i nie

wolno dodawać żadnych nowych potomków.• incomplete – nie wszyscy potomkowie w uogólnieniu zostali w modelu uwzględnieniu i

wolno dodawać nowych potomków.


{incomplete}

Kierownik

Nadzór

<<implementation>>

Potomek dziedziedziczy calą implementację, ale nie udostępnia jako publicznych jego interfejsów i nie realizuje ich. (Dziedziczenie prywatne).DziekanPracownikNaukowy

StopienNaukowy : AnsiString


37

Realizacja:

Realizacja jest to związek znaczeniowy między klasyfikatorami, z których jeden określa kontrakt, a drugi zapewnia wywiązanie się z niego:




DanePersonalne


<<Interface>>

Realizacja

Picture

Display

38

Diagram obiektów służy do modelowania statycznych aspektów perspektywy projektowej lub procesowej. Wyobrażają one stan systemu w danej chwili.

Uwzględnia się na nim:• zbiór obiektów,• stan obiektów,• związki między obiektami.

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram obiektDiagram obiektóóww

o1 : Osoba

k1 : Konto

p1 : Przedsiębiortstwo

o2 : Osoba

k2 : Konto

o4 : Osoba

k4 : Konto

k3 : Konto

o3 : Osoba

39

Diagram sekwencji (diagram przebiegu) służy do modelowania dynamicznych aspektów perspektywy projektowej lub procesowej. Uwypukla się na nim kolejność komunikatów w czasie.

Uwzględnia się na nich:• obiekty,• czas życia obiektów,• komunikaty.

Rodzaje komunikatów:• przejście do następnego kroku,• wywołanie procedury,• asynchroniczne przejście,• powrót z procedury.

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram sekwencjiDiagram sekwencji

k : Klient

t : Transakcja

: BazaDanych

1: <<create>>

4: Write(a,5,8)

5: Write(b,Kowalski)

7: <destroy>>

6: Potwierdzenie

2: Set(x,y,z)3: Weryfikacja

40

Przykład:

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram sekwencjiDiagram sekwencji

: Klient : Bankomat : BazaDanych

: Transakcja8: <<create>>

1: Włożenie karty

2: Prośba o PIN

3: Podanie PIN4: Weryfikacja PIN

5: Potwierdzenie PIN

6: Pytanie o kwotę

7: Podanie kwoty

9: Realizacja

11: Transakcja zapisana12: Zakończona

10: Werfikacja

14: <<destroy>>13: Wypłata gotówki

41

Diagram kooperacji służy do pokazania organizacji obiektów uczestniczących w interakcji.

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram kooperacjiDiagram kooperacji

: Bankomat : Klient : BazaDanych

: Transakcja

10: Weryfikacja

4: Weryfikacja PIN

5: Potwierdzenie PIN

1: Włożenie karty

2: Prośba o PIN

3: Podanie PIN

6: Pytanie o kwotę

7: Podanie kwoty

13: Wypłata gotówki

8: <<create>> 12: Zakończona

14: <<destroy>>

9: Realizacja

11: Transakcja zapisana

42

Diagram czynności służy do modelowania dynamicznych aspektów systemu. Przedstawia się na nim sekwencyjne lub współbieżne kroki procesu. Można też zobrazować zmiany zachodzące w obiektach w różnych fazach przepływu sterowania.

Punkt startowy: Przepływ obiektu:

Punkt końcowy: Stan obiektu:

Czynność:

Przejście: Tor:

Punkt synchronizacji:

Decyzja:

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram czynnoDiagram czynnośścici

Czynność

Obiekt[Stan obiektu]

Tor

43

Przykład:


Klient Sprzedawca Magazyn

Żądanie obsługi

Płatność

Odbiór zlecenia

Realizacja zlecenia

Odbiór

Dostarczenie

Żądanie obsługi

Płatność

Odbiór zlecenia

Realizacja zlecenia

Odbiór

Dostarczenie

44

Przykład:



Żądanie obsługi

Płatność

Odbiór

Odbiór zlecenia

Dostarczenie

Realizacja zlecenia

Zlecenie[złożone]

Zlecenie[wprowadzone]

Zlecenie[zrealizowane]

Zlecenie[dostarczone]


Żądanie obsługi

Płatność

Odbiór zlecenia

Realizacja zlecenia

Odbiór

Dostarczenie

45

Przykład:


[System sprawny]

[System niesprawny]

[Droga wolna][Droga zajęta]

[Cel osiągnięty]

[Cel nieosiagniety]

Włącz zasilanie

Wyłącz zasilanie

Uruchom silnik

Jedz

Sprawdz drogę

Wyszukaj nową drogę

Zatrzymaj się

46

Diagram stanów służy do modelowania dynamicznych aspektów systemu. Uwzględnia sięhistorię życia egzemplarzy, klasy, przypadku użycia lub systemu. Egzemplarze reagują na zdarzenia, jak sygnały wywołania operacji i upływ czasu. Po zajściu zdarzenia sąwykonywane czynności, które zależą od bieżącego stanu obiektu. Czynności powodujązmianę stanu lub przekazanie wartości. Stan jest to okoliczność lub sytuacja, w jakiej sięznajduje.

Stan początkowy:

Stan końcowy:

Stan:

Przejście

Zdarzenie: Wprowadzono hasło

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram stanDiagram stanóóww

Błąd logowania

do / ShowMessage("Login error")

47

Przykład:

Programowanie obiektowe (UML)Programowanie obiektowe (UML)Diagram stanDiagram stanóóww

Wprowadzono Login

Zakończono wyszukiwanie [Nie znaleziono]Zakończono wyszukiwanie [Znaleziono]

Wprowadzono hasło

Zakończono weryfikację [Błędne hasło]/ disable program

Zakończono weryfikację/ enable program

po 10 sek./ Terminate program

Zmiana użytkownika/ Logout

Zakończenie programu/ Terminate Program

Wprowadzanie loginu

entry / ShowLoginWindow

Wprowadzanie Hasła

do / ShowPassWindow

WyszukanieUżytkownika

do / SearchUser

Błąd logowania

do / ShowMessage("Login error")

Weryfikacja hasła

do / Verify

Praca z programem

Documents

Programowanie Obiektowe - Język UMLkolos.math.uni.lodz.pl/~archive/Programowanie obiektowe/uml.pdf · UML (Unified Modeling Language), zunifikowany język do modelowania, jest następcąi