Modelowanie systemów informatycznych w języku UML 2.1

Andrzej Stasiak, Włodzimierz Dąbrowski, Michał Wolski

Uzyskaj dostęp

Zakup książkę

ISBN/ISSN:

978-83-01-21108-0

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2009

Liczba stron:

196

XML:ISBN/ISSN:

ONIX MARC21

Bibliografia:

Stasiak, Andrzej; Dąbrowski, Włodzimierz; Wolski, Michał. Modelowanie systemów informatycznych w języku UML 2.1. Red. . Warszawa: Wydawnictwo Naukowe PWN, 2009, 196 s. ISBN 978-83-01-21108-0

Bibliografia refWorks:

RT Book, Whole

SR Electronic(1)

A1 Stasiak, A.

A1 Dąbrowski, W.

A1 Wolski, M.

T1 Modelowanie systemów informatycznych w języku UML 2.1

PB Wydawnictwo Naukowe PWN

PP Warszawa

YR 2009

SN 978-83-01-21108-0

Bibliografia BibTex:

@Book{ 517, author = "Stasiak, Andrzej and Dąbrowski, Włodzimierz and Wolski, Michał", editor = "", title = "Modelowanie systemów informatycznych w języku UML 2.1", publisher = "Wydawnictwo Naukowe PWN", year = "2009", address = "Warszawa", isbn = "978-83-01-21108-0" }

Bibliografia endNote:

TY - BOOK

AU - Stasiak, Andrzej

AU - Dąbrowski, Włodzimierz

AU - Wolski, Michał

ED -

TI - Modelowanie systemów informatycznych w języku UML 2.1

PB - Wydawnictwo Naukowe PWN

CY - Warszawa

PY - 2009

SN - 978-83-01-21108-0

ER -

Netografia (standard APA):

Stasiak, Andrzej; Dąbrowski, Włodzimierz; Wolski, Michał. Modelowanie systemów informatycznych w języku UML 2.1 [baza danych online] Warszawa: Wydawnictwo Naukowe PWN, 2009 [dostęp: 02 05 2024]. Dostęp w Ibuk Libra: https://libra.ibuk.pl/reader/modelowanie-systemow-informatycznych-w-jezyku-uml-21-andrzej-stasiak-wlodzimierz-517.

informatyka, programowanie, zastosowania informatyki, systemy informatyczne, modelowanie, UML

Książka przedstawia sposób modelowania systemów informacyjnych z wykorzystaniem podejścia obiektowego i języka UML 2.1. Czytelnik znajdzie w niej współczesne spojrzenie na modelowanie i projektowanie systemów informatycznych w ujęciu obiektowym zi...

Więcej

ISBN/ISSN:

978-83-01-21108-0

DOI:

Wydawnictwo:

Wydawnictwo Naukowe PWN

Rok wydania:

2009

Liczba stron:

196

XML:ISBN/ISSN:

ONIX MARC21

Strona tytułowa2
Strona redakcyjna3
Spis treści4
O Autorach11
1. Wprowadzenie12
2. Modelowanie – cele i metody13
2.1. Przegląd rozdziału13
2.1.1. Czego dotyczy ten rozdział?13
2.1.2. Co powinieneś wiedzieć, aby zrozumieć?13
2.1.3. Jakie najważniejsze problemy rozwiążemy w tym rozdziale?13
2.1.4. Czego dowiesz się po jego przeczytaniu?13
2.1.5. Dlaczego warto przeczytać ten rozdział?13
2.2. Czym jest, a czym nie jest model systemu?14
2.3. Po co budować modele?16
2.2.1. Czym jest model systemu?16
2.4. Rodzaje modeli17
2.5. Odbiorcy i użytkownicy modeli19
2.6. Język opisu modeli20
2.6.1. Cechy dobrego modelu20
2.7. Podsumowanie21
2.6.2. Jak popsuć model? Cechy złego modelu21
2.8. Czego dotyczył rozdział?22
2.9. Ćwiczenia sprawdzające22
2.8.1. Czego nauczyłeś się w tym rozdziale?22
2.8.2. Jakich błędów warto unikać?22
2.9.1. Pytania testowe22
2.10 Słowniczek pojęć wprowadzonych w rozdziale23
2.11 Przegląd literatury23
2.9.2. Pytania otwarte23
3. Modelowanie biznesowe24
3.1. Przegląd rozdziału24
3.2. Czym jest modelowanie biznesowe24
3.1.1. Czego dotyczy ten rozdział?24
3.1.2. Co powinieneś wiedzieć, aby zrozumieć?24
3.1.3. Jakie najważniejsze problemy rozwiążemy w tym rozdziale?24
3.1.4. Czego dowiesz się po jego przeczytaniu?24
3.3. Notacja i semantyka modeli biznesowych wyrażonych w języku UML25
3.4. Model biznesowy firmy zarządzającej nieruchomościami26
3.4.1. Wstęp do zarządzania nieruchomościami – opis werbalny modelu biznesowego26
3.4.1.1. Regulacje prawne26
3.4.1.2. Podstawowe pojęcia27
3.4.1.3. Mapowanie procesów biznesowych na elementy modelu biznesowego28
3.4.1.4. Model analityczny30
3.4.1.5. Realizacja biznesowego przypadku użycia Odbierz media i usługę30
3.4.1.6. Realizacja biznesowego przypadku użycia Prowadü nadzór techniczny nad nieruchomością31
3.4.1.7. Realizacja biznesowego przypadku użycia Rozlicz finanse nieruchomości33
3.4.1.8. Realizacja Wykonaj bieżące naprawy i remonty35
3.4.1.9. Realizacja Wykonaj uchwałę właścicieli35
3.5. Patrząc w przyszłość: Jak z modelu biznesowego zrobić model przypadków użycia37
3.6. Czego dotyczył rozdział?37
3.7. Ćwiczenia sprawdzające37
3.6.1. Czego nauczyłeś się w tym rozdziale?37
3.6.2. Jakich błędów warto unikać?37
3.7.1. Pytania testowe37
3.8. Słowniczek pojęć wprowadzonych w rozdziale38
3.9. Przegląd literatury38
3.7.2. Pytania otwarte38
4. Modelowanie wymagań40
4.1. Przegląd rozdziału40
4.2. Czym są wymagania dla systemu informatycznego?40
4.1.1. Czego dotyczy ten rozdział?40
4.1.2. Co powinieneś wiedzieć, aby zrozumieć?40
4.1.3. Jakie najważniejsze problemy rozwiążemy w tym rozdziale?40
4.1.4. Czego dowiesz się po jego przeczytaniu?40
4.1.5. Dlaczego warto przeczytać ten rozdział?40
4.3. Rodzaje wymagań41
4.3.1. Wymagania funkcjonalne42
4.3.1.1. Język naturalny42
4.3.1.2. Język naturalny strukturalny42
4.3.1.3. Tablice i formularze42
4.3.1.4. Diagramy blokowe42
4.3.2. Wymagania niefunkcjonalne43
4.3.1.5. Diagramy kontekstowe43
4.3.1.6. Diagramy przypadków użycia43
4.3.1.7. Formalizm matematyczny43
4.3.1.8. Formularz wymagań funkcjonalnych43
4.3.2.1. Wymagania dotyczące produktu43
4.3.2.2. Wymagania dotyczące procesu43
4.4. Metody pozyskiwania i dokumentowania wymagań44
4.4.1. Wywiady i przeglądy44
4.3.2.3. Wymagania zewnętrzne44
4.3.2.4. Weryfikowanie wymagań niefunkcjonalnych44
4.4.2. Studia nad istniejącym oprogramowaniem45
4.4.3. Studia wymagań systemowych45
4.4.4. Studia osiągalności45
4.4.5. Prototypowanie45
4.4.5.1. Jakość dokumentu wymagań46
4.4.5.2. Opis wymagań z wykorzystaniem przypadków użycia46
4.4.6. Konwencje typograficzne i opis szablonu47
4.5. Dokument Specyfikacji Wymagań49
4.5.1. Struktura Dokumentu Specyfikacji Wymagań49
4.5.1.1. Wprowadzenie49
4.5.1.2. Opis ogólny49
4.5.2. Wzorzec szablonu specyfikacji wymagań funkcjonalnych50
4.5.1.3. Diagram przypadków użycia – wnioski50
4.5.1.4. Założenia i zależności50
4.5.1.5. Wymagania systemowe50
4.5.1.6. Wymagania funkcjonalne50
4.5.1.7. Wymagania niefunkcjonalne50
4.5.1.8. Informacje pomocnicze50
4.6. Najczęstsze błędy popełniane przy modelowaniu wymagań51
4.7. Ćwiczenia sprawdzające52
4.8. Słowniczek pojęć wprowadzonych w rozdziale52
4.7.1. Pytania testowe52
4.7.2. Pytania otwarte52
4.9. Przegląd literatury53
5. Modelowanie systemów czasu rzeczywistego w języku UML54
5.1. Wprowadzenie54
5.1.1. Czego dotyczy ten rozdział?54
5.1.2. Co powinieneś wiedzieć, aby zrozumieć?54
5.1.3. Jakie najważniejsze problemy rozwiążemy w tym rozdziale?54
5.2. UML w modelowaniu systemów czasu rzeczywistego55
5.1.4. Czego dowiesz się po jego przeczytaniu?55
5.1.5. Dlaczego warto przeczytać ten rozdział?55
5.2.1. Mechanizmy rozszerzeń języka UML57
5.2.1.1. Stereotypy57
5.2.1.2. Metki58
5.2.1.3. Ograniczenia58
5.3. Modelowanie statyki SCR59
5.2.2. Analiza rozszerzeń języka UML dla SCR59
5.3.1. Klasy czy kapsuły?59
5.3.2. Porty60
5.4. Modelowanie dynamiki systemów uwarunkowanych czasowo62
5.3.3. Łączniki62
5.4.1. Protokoły62
5.4.2. Maszyny stanowe63
5.5. Warsztat projektanta systemów czasu rzeczywistego64
5.6. Cechy dobrego modelu SCR66
5.6.1. Pokładowy system sterowania podwieszeniami66
5.6.1.1. Wymagania wobec pokładowego systemu sterowania podwieszeniami67
5.6.1.2. Modelowanie struktury PSSP68
5.6.1.3. Modelowanie dynamiki PSSP70
5.6.2. Projekt systemu sterowania automatem do serwowania gorących napojów71
5.6.2.1. Wymagania wobec SSA71
5.6.2.2. Struktura SSA72
5.6.2.3. Model dynamiki SSA74
5.7. Sięgając poza UML dla SCR75
5.7.1. Dlaczego warto sterować rozwojem systemów poprzez modele?76
5.7.2. MDA77
5.7.3. MDA a MDSD78
5.8. Ćwiczenia sprawdzające79
5.7.4. Co dalej z językiem UML79
5.8.1. Pytania testowe79
5.9. Słownik pojęć wprowadzonych w rozdziale80
5.8.2. Pytania otwarte80
5.10 Przegląd literatury81
6. Modelowanie baz danych82
6.1. UML w modelowaniu baz danych82
6.2. Modelowanie danych82
6.2.0.1. Przypadki użycia82
6.2.0.2. Diagram klas83
6.2.0.3. Zastosowanie podejścia tabelarycznego do tworzenia architektury aplikacji83
6.2.1. Struktura DataSet83
6.2.2. Podejście tabelaryczne84
6.2.3. Domenowy model organizacji aplikacji85
6.2.3.1. Sposób działania85
6.2.4. Architektura aplikacji wykorzystująca elementy typu DataSet86
6.2.3.2. Kiedy stosować model obiektowy?86
6.2.4.1. Architektura aplikacji87
6.2.4.2. Implementacja88
6.2.4.3. Struktura91
6.2.4.4. Przykład z użyciem CodeSmith99
6.3. Podsumowanie101
6.4. Ćwiczenia sprawdzające101
6.4.1. Pytania testowe101
6.5. Słowniczek pojęć wprowadzonych w rozdziale102
6.6. Przegląd literatury102
6.4.2. Pytania otwarte102
7. Wspomaganie modelowania przez narzędzia CASE103
7.1. Czym są pakiety CASE?103
7.2. Przegląd dostępnych narzędzi CASE103
7.2.1. Case/4/0103
7.2.2. Oracle Designer104
7.2.3. IBM Rational Suite Enterprise104
7.2.4. IBM Rational Software Architect104
7.3. Narzędzia CASE w praktyce105
7.2.5. Enterprise Architect105
7.2.6. StarUML105
7.3.1. „Hurtownia” – narzędzia CASE w projektowaniu systemów biznesowych106
7.3.1.1. Model przypadków użycia106
7.3.1.2. Model analityczny111
7.3.1.3. Model projektu113
7.3.2. System „Bankomat” – narzędzia CASE w systemach wbudowanych114
7.3.2.1. Perspektywa przypadków użycia115
7.3.2.2. Perspektywa projektowa116
7.3.2.3. Perspektywa komponentów120
7.3.2.4. Perspektywa wdrożenia120
7.4. Kierunki rozwoju narzędzi CASE121
8. Przegląd diagramów języka UML123
8.1. Diagram przypadków użycia123
8.1.1. Diagram przypadków użycia – definicja i zastosowanie123
8.1.2. Diagram przypadków użycia – notacja i semantyka123
8.1.2.1. Przypadek użycia123
8.1.2.2. Aktor125
8.1.2.3. Strukturalne związki zawierania i rozszerzenia126
8.1.2.4. Generalizacja127
8.1.3. Diagram przypadków użycia – przykładowe zastosowanie128
8.1.4. Od wymagań werbalnych po wymagania wizualne129
8.1.5. Pięć najczęściej popełnianych błędów132
8.1.6. Wymagania funkcjonalne to nie wszystko136
8.2. Diagram pakietów137
8.1.7. Patrząc w przyszłość137
8.2.1. Diagram pakietów – definicja i zastosowanie138
8.2.2. Diagram pakietów – notacja i semantyka138
8.2.2.1. Pakiet138
8.2.2.2. Zagnieżdżenie138
8.2.2.3. Generalizacja139
8.2.2.4. Zależność139
8.2.3. Diagram pakietów – przykładowe zastosowanie140
8.2.4. Patrząc w przyszłość140
8.2.2.5. Zależność ze stereotypem Import140
8.3. Diagram klas141
8.3.1. Diagram klas – definicja i zastosowanie141
8.3.2. Diagram klas – notacja i semantyka141
8.3.2.1. Klasa141
8.3.2.2. Interfejs142
8.3.2.3. Związek asocjacji (powiązania)143
8.3.2.4. Związek agregacji143
8.3.2.5. Silna agregacja (kompozycja)143
8.3.2.6. Związek zależności144
8.3.2.7. Związek generalizacji144
8.3.2.8. Liczebność145
8.4. Diagram obiektów146
8.3.3. Diagram klas – przykładowe zastosowanie146
8.3.4. Patrząc w przyszłość146
8.4.1. Diagram obiektów – definicja i zastosowanie146
8.4.2. Diagram obiektów – notacja i semantyka147
8.4.2.1. Obiekt147
8.4.2.2. Związek asocjacji (powiązania)149
8.4.3. Diagram obiektów – przykładowe zastosowanie150
8.4.2.3. Związek agregacji150
8.5. Diagram czynności151
8.4.4. Patrząc w przyszłość151
8.5.1. Diagram czynności – definicja i zastosowanie151
8.5.2. Diagram czynności – notacja i semantyka151
8.5.2.1. Aktywność151
8.5.2.2. Czynność152
8.5.2.3. Przepływ sterujący152
8.5.2.4. Przepływ obiektu152
8.5.2.5. Warunek wstępny i warunek końcowy152
8.5.2.6. Obiekt153
8.5.2.7. Magazyn danych153
8.5.2.8. Węzeł końcowy153
8.5.2.10 Zakończenie przepływu154
8.5.2.11 Węzeł decyzyjny154
8.5.2.9. Węzeł początkowy154
8.5.2.12 Węzeł połączenia155
8.5.2.13 Węzeł rozwidlenia155
8.5.2.14 Węzeł scalenia156
8.5.2.15 Partycja aktywności156
8.5.3. Diagram czynności – przykładowe zastosowanie157
8.6. Diagram maszyny stanowej158
8.5.4. Patrząc w przyszłość158
8.6.1. Diagram maszyny stanowej – definicja i zastosowanie158
8.6.2. Diagram maszyny stanowej – notacja i semantyka159
8.6.2.1. Stan159
8.6.2.2. Przejście159
8.6.2.3. Stan początkowy159
8.6.2.4. Stan końcowy160
8.6.2.5. Maszyna stanowa160
8.6.2.6. Punkt wejścia160
8.6.2.7. Punkt wyjścia161
8.6.2.8. Stan wznowienia161
8.6.2.9. Węzeł wyboru161
8.6.3. Diagram maszyny stanowej – przykładowe zastosowanie162
8.6.2.10 Węzeł rozwidlenia162
8.7. Diagramy sekwencji163
8.6.4. Patrząc w przyszłość163
8.7.1. Diagram sekwencji – definicja i zastosowanie163
8.7.2. Diagram sekwencji – notacja i semantyka164
8.7.2.1. Linia życia164
8.7.2.2. Komunikat164
8.7.2.3. Fragment165
8.7.2.4. Wystąpienie interakcji167
8.7.2.5. Punkt końcowy i startowy167
8.7.3. Diagram sekwencji – przykładowe zastosowanie168
8.7.2.6. Brama168
8.7.4. Najczęściej popełniane błędy169
8.7.5. Scenariusze na różnym poziomie abstrakcji173
8.8. Diagramy komunikacji174
8.7.6. Patrząc w przyszłość174
8.8.1. Diagram komunikacji – definicja i zastosowanie174
8.8.2. Diagram komunikacji – notacja i semantyka174
8.8.2.1. Obiekt174
8.8.3. Diagram komunikacji – przykładowe zastosowanie175
8.8.4. Patrząc w przyszłość175
8.8.2.2. Komunikat175
8.9. Diagramy przebiegów czasowych176
8.9.1. Diagramy przebiegów czasowych – definicja i zastosowanie176
8.9.2. Diagramy przebiegów czasowych – notacja i semantyka176
8.9.2.1. Linia stanów176
8.9.2.2. Linia wartości177
8.9.2.3. Etykieta wiadomości177
8.9.2.4. Wiadomość końcowa177
8.9.3. Diagram przebiegów czasowych – przykładowe zastosowanie178
8.9.2.5. Brama diagramu178
8.9.2.6. Wiadomość178
8.10 Diagramy widoku interakcji179
8.10.1 Diagram widoku interakcji – definicja i zastosowanie179
8.9.4. Patrząc w przyszłość179
8.10.2 Diagram widoku interakcji – notacja i semantyka180
8.10.2.1 Interakcja180
8.10.2.2 Egzemplarz interakcji180
8.10.2.3 Węzeł końcowy180
8.10.2.4 Węzeł początkowy181
8.10.2.5 Zakończenie przepływu181
8.10.2.6 Węzeł decyzyjny181
8.10.2.7 Węzeł połączenia182
8.10.2.8 Węzeł rozwidlenia182
8.10.2.9 Węzeł scalenia183
8.10.3 Diagram widoku interakcji – przykładowe zastosowanie184
8.10.2.10 Przepływ sterujący184
8.11 Diagram komponentów185
8.10.4 Patrząc w przyszłość185
8.11.1 Diagram komponentów – definicja i zastosowanie185
8.11.2 Diagram komponentów – notacja i semantyka185
8.11.2.1 Komponent185
8.11.2.2 Interfejs185
8.11.2.3 Połączenie zespolone186
8.11.3 Diagram komponentów – przykładowe zastosowanie187
8.11.2.4 Port187
8.11.2.5 Artefakt187
8.12 Diagram struktury188
8.11.4 Patrząc w przyszłość188
8.12.1 Diagram struktury – definicja i zastosowanie189
8.12.2 Diagram struktury – notacja i semantyka189
8.12.2.1 Część189
8.12.2.2 Port189
8.12.2.3 Element współpracy190
8.12.2.4 Użycie elementu współpracy190
8.12.2.5 Połączenie190
8.12.2.6 Zależność reprezentacji190
8.12.3 Diagram struktury – przykładowe zastosowanie191
8.12.2.7 Zależność wystąpienia191
8.12.2.8 Związek roli191
8.13 Diagram wdrożenia192
8.12.4 Patrząc w przyszłość192
8.13.1 Diagram wdrożenia – definicja i zastosowanie193
8.13.2 Diagram wdrożenia – notacja i semantyka193
8.13.2.1 Węzeł193
8.13.2.2 Komponent193
8.13.2.3 Artefakt194
8.13.2.4 Specyfikacja wdrożenia194
8.13.2.5 årodowisko wykonania194
8.13.2.6 Urządzenie194
8.13.3 Diagram wdrożenia – przykładowe zastosowanie195
8.13.2.7 Asocjacja (powiązanie)195
8.13.2.8 Manifest195
8.13.2.9 Zależność195
8.14 Przegląd literatury196

Rysunek2.10.Przykładmodelustatykisystemunaniższympoziomieabstrakcji

Modeleperspektywyimplementacyjnejmusząuwzględniaćuwarunkowaniaplatformy,

naktórejzostaniewykonanaimplementacjaprzyszłegosystemu.Dlategoteżwmodelachtej

perspektywyprojektancimuszązawrzećszczegółoweinformacjedotyczącenaprzykładtypów

danychczyspecyﬁcznychdlazastosowanegosystemuzarządzaniabaządanychstruktur

danych.Modeletejperspektywycechująsięoczywiściewiększymstopniemszczegółowości

iskomplikowanianiżmodeleperspektywylogicznej,adoichodczytaniaizrozumieniapotrzebna

jestfachowawiedza.Niesąoneprzeznaczonedlaużytkownikówsystemu,aledlajegotwórców

–architektów,programistówitp.

2.5.Odbiorcyiużytkownicymodeli

Wprocesiewytwarzaniaoprogramowaniauczestniczywieleosób.Wzasadziemożemy

powiedzieć,żekażdaznichkorzystawczasierealizacjiswoichzadańzpewnegomodelu

systemu(lubkilku)naodpowiedniodobranympoziomieabstrakcji.

Ważnejest,abymodelijegopoziomabstrakcjiodpowiadałmożliwościomipotrzebom

odbiorcy(użytkownika).Naprzykładniemasensuprzedstawiaćużytkownikowikońcowemu

szczegółowego(naniskimpoziomieabstrakcji)modeluimplementacyjnego,gdyżpopierwsze

modeltakiniebędziedlaniegozrozumiały,apodrugieznajomośćszczegółów

implementacyjnychdlaużytkownikakońcowegojestcałkowiciezbędna.Wartonatomiast

zapoznaćgozmodelemwymagańzapisanymnaprzykładwpostacidiagramówprzypadków

użycia(patrzrozdział8)orazztekstowymmodelemprzypadkówużycia.Modeleowe

przedstawiająteaspektysystemu,któresąważnezpunktuwidzeniaużytkownikakońcowego.

Oprócztegomodeleprzypadkówużyciamogąbyćłatwozrozumiałedlaosoby,któranie

mafachowegoprzygotowaniaiumiejętnościodczytywaniamodeli.

Tabela2.1.Przykładowiużytkownicymodeli

Model

Modelwymagańfunkcjonalnych

Modelwymagańniefunkcjonalnych

Modelarchitektury

Modeldanych

Modelimplementacyjny

Modelinterfejsów

Głównyodbiorca

Użytkownikkońcowy,analityk,architekt

Architekt

Twórcabazydanych,programista

Programista

Użytkownik,analityk

Brak wyników

Modelowanie systemów informatycznych w języku UML 2.1

Treść książki

Znajdź bibliotekę blisko siebie, i uzyskaj dostęp do ebooka w systemie IBUK Libra