wyszukiwanie

Katalog książek

Bony podarunkowe

Autorzy Nowości eBooki Bestsellery Zapowiedzi Przedsprzedaż Najlepiej oceniane Druk na żądanie

Helion SA
ul. Kościuszki 1c
44-100 Gliwice
tel. (32) 230-98-63

© Helion 1991-2011

Informacje podstawowe

UML. Inżynieria oprogramowania. Wydanie II

Autor: Perdita Stevens
Data wydania: 2007/07
Stron: 304

Powiadom mnie gdy książka będzie dostępna w druku na żądanie

Szczegóły:

Tytuł oryginału: Using UML: Software Engineering with Objects and Components (2nd Edition)
Tłumaczenie: Ireneusz Jakóbik
ISBN: 9788324608058 / 978-83-246-0805-8
Format: B5
Oprawa: miękka
Numer z katalogu: 3749

Informacje dodatkowe:

Praktyczny podręcznik do nauki języka UML

Jak zaprojektować dobry system?
Jak poprawnie tworzyć i odczytywać modele?
Jak w praktyce stosować UML i poprawić jakość projektowanych produktów?

W świecie informatyki dobry projekt to często więcej niż połowa sukcesu, a wraz ze wzrostem popularności obiektowych języków programowania UML -- ujednolicony język modelowania przeznaczony do reprezentacji elementów w analizie obiektowej i programowaniu obiektowym -- stał się podstawowym narzędziem do tworzenia modeli. Dlatego też trudno wyobrazić sobie dobrego informatyka, który nie potrafi przygotować poprawnego projektu w tym języku lub odczytać modelu utworzonego przez kogoś innego.

"UML. Inżynieria oprogramowania. Wydanie II" to przystępny podręcznik dla studentów i informatyków pragnących nie tylko poznać ujednolicony język modelowania, ale przede wszystkim nauczyć się korzystać z niego w kontekście inżynierii oprogramowania. Czytając go, dowiesz się, jak powinien wyglądać dobry system, poznasz składnię i funkcje języka UML, a przedstawione studia przypadku pozwolą Ci zobaczyć, jak używać go do projektowania praktycznych rozwiązań.

Projektowanie systemów bazujących na komponentach
Wprowadzenie do obiektowości
Efektywny proces projektowania
Opracowywanie modeli klas
Przygotowywanie modeli przypadków użycia
Tworzenie diagramów interakcji, stanów i aktywności
Przygotowywanie diagramów struktury i wdrożeń
Stosowanie komponentów i wzorców
Dbanie o jakość procesu i produktu
Praktyczne przykłady projektowania systemów

Jeśli chcesz tworzyć oprogramowanie najwyższej jakości,
zacznij od dobrego projektu.

Wstęp (13)
Część I Tło koncepcyjne (19)
Rozdział 1. Inżynieria oprogramowania z użyciem komponentów (21)

1.1. Co to jest dobry system? (21)
1.2. Czy istnieją dobre systemy? (22)

1.2.1. Problemy... (22)
1.2.2. ...a nawet katastrofalne niepowodzenia (24)
1.2.3. Obietnice, obietnice (25)

1.3. Jakie są dobre systemy? (26)

1.3.1. Hermetyzacja: słabe powiązania (27)
1.3.2. Abstrakcja: wysoki stopień spójności (30)
1.3.3. Architektura i komponenty (31)
1.3.4. Projektowanie oparte na komponentach: modularność (33)

1.4. Jak są zbudowane dobre systemy? (33)

Rozdział 2. Koncepcje obiektów (35)

2.1. Czym jest obiekt? (35)

2.1.1. Przykład (37)
2.1.2. Komunikaty (37)
2.1.3. Interfejsy (38)
2.1.4. Klasy (39)

2.2. Jaki to ma związek z celami poprzedniego rozdziału? (42)

2.2.1. Co wspólnego z komponentami mają obiekty? (43)

2.3. Dziedziczenie (44)
2.4. Polimorfizm i wiązanie dynamiczne (46)

Rozdział 3. Wstępne studium przypadku (49)

3.1. Problem (49)

3.1.1. Sprecyzowanie wymagań (49)
3.1.2. Model przypadków użycia (51)

3.2. Zakres oraz iteracje (53)
3.3. Identyfikowanie klas (55)
3.4. Relacje między klasami (57)
3.5. System w akcji (60)

3.5.1. Zmiany w systemie: diagramy stanów (64)
3.5.2. Dalsze prace (64)

Rozdział 4. Proces projektowania (67)

4.1. Definicje terminów (67)

4.1.1. Modele i języki modelowania (68)
4.1.2. Proces i jakość (70)

4.2. Proces projektowania (70)

4.2.1. Zunifikowana metodologia? (72)
4.2.2. Procesy stosowane w UML (73)

4.3. System, projekt, model, diagram (75)

4.3.1. Wykorzystanie modeli (76)

Część II UML (79)
Rozdział 5. Podstawy modeli klas (81)

5.1. Identyfikowanie obiektów i klas (81)

5.1.1. Co sprawia, że model klasy jest dobry? (81)
5.1.2. Jak zbudować dobry model klasy (82)
5.1.3. Jakim rodzajem rzeczy są klasy? (85)
5.1.4. Obiekty ze świata rzeczywistego a ich reprezentacje w systemie (85)

5.2. Powiązania (86)

5.2.1. Wielokrotności (88)

5.3. Atrybuty i operacje (89)

5.3.1. Operacje (89)
5.3.2. Atrybuty (89)

5.4. Generalizacja (90)

5.4.1. Korzystanie z języka polskiego w celu sprawdzenia, czy zachodzi generalizacja (93)
5.4.2. Implementacja generalizacji: dziedziczenie (93)

5.5. Model klasy podczas opracowywania (94)
5.6. Karty CRC (95)

5.6.1. Tworzenie kart CRC (95)
5.6.2. Używanie kart CRC podczas opracowywania projektu (96)
5.6.3. Przykład karty CRC (97)
5.6.4. Refaktoring (98)

Rozdział 6. Więcej na temat modeli klas (101)

6.1. Więcej na temat powiązań (101)

6.1.1. Agregacja i kompozycja (101)
6.1.2. Role (103)
6.1.3. Możliwości nawigacji (104)
6.1.4. Powiązania kwalifikowane (105)
6.1.5. Powiązania pochodne (107)
6.1.6. Ograniczenia (108)
6.1.7. Klasy powiązań (110)

6.2. Więcej na temat klas (112)

6.2.1. Interfejsy (113)
6.2.2. Klasy abstrakcyjne (115)

6.3. Klasy sparametryzowane (117)
6.4. Zależność (118)
6.5. Komponenty i pakiety (119)
6.6. Widoczność i ochrona (119)

Rozdział 7. Najważniejsze informacje na temat modeli przypadków użycia (121)

7.1. Szczegóły dotyczące aktorów (123)
7.2. Przypadki użycia w szczegółach (125)
7.3. Granice systemu (126)
7.4. Używanie przypadków użycia (127)

7.4.1. Przypadki użycia podczas gromadzenia wymagań (127)
7.4.2. Przypadki użycia podczas projektowania (128)

7.5. Możliwe problemy z przypadkami użycia (130)

Rozdział 8. Więcej informacji na temat modeli przypadków użycia (133)

8.1. Relacje między przypadkami użycia (133)

8.1.1. Przypadki użycia do wielokrotnego użycia: <<include>> (134)
8.1.2. Komponenty i przypadki użycia (136)
8.1.3. Rozdzielanie wariantów zachowania: <<extend>> (138)

8.2. Generalizacje (139)
8.3. Aktorzy i klasy (140)

8.3.1. Notacja: aktorzy jako klasy (141)

Rozdział 9. Najważniejsze informacje na temat diagramów interakcji (143)

9.1. Współprace (144)
9.2. Diagramy komunikacji (145)
9.3. Diagramy sekwencji (147)
9.4. Więcej zaawansowanych funkcji (150)

9.4.1. Komunikaty z obiektu do samego siebie (150)
9.4.2. Zwracane wartości (151)
9.4.3. Tworzenie i usuwanie obiektów (152)

9.5. Diagramy interakcji służące innym celom (154)

9.5.1. Pokazywanie, jak klasa udostępnia operację (154)
9.5.2. Opisywanie, jak działa wzorzec projektowy (154)
9.5.3. Opisywanie, jak można użyć komponentu (154)

Rozdział 10. Więcej informacji na temat diagramów interakcji (155)

10.1. Więcej niż tylko proste sekwencje komunikatów (155)

10.1.1. Zachowania warunkowe (155)
10.1.2. Iteracja (157)

10.2. Współbieżność (158)

10.2.1. Modelowanie ścieżek kontroli (159)

Rozdział 11. Najważniejsze informacje na temat diagramów stanów i aktywności (165)

11.1. Diagramy stanów (166)

11.1.1. Niespodziewane komunikaty (167)
11.1.2. Poziom abstrakcji (168)
11.1.3. Stany, zmiany stanu i zdarzenia (168)
11.1.4. Akcje (169)
11.1.5. Dozór (171)

11.2. Diagramy aktywności (174)

Rozdział 12. Więcej informacji na temat diagramów stanów (179)

12.1. Inne rodzaje zdarzeń (179)
12.2. Inne rodzaje akcji (180)
12.3. Zaglądanie do wnętrza stanów (181)
12.4. Współbieżność w obrębie stanów (183)

Rozdział 13. Diagramy architektury i wdrożeń (185)

13.1. Diagramy struktury komponentów (185)
13.2. Model wdrożeń (187)

13.2.1. Warstwa fizyczna (187)
13.2.2. Wdrażanie oprogramowania na sprzęcie (187)

Rozdział 14. Pakiety i modele (191)

14.1. Pakiety (191)

14.1.1. Kontrolowanie przestrzeni nazw (192)

14.2. Modele (194)

Część III Studia przypadków (197)
Rozdział 15. Administrowanie I4 (199)

15.1. Studium przypadku (199)

15.1.1. Model klas (203)
15.1.2. Dynamika (204)
15.1.3. Diagramy stanów (204)
15.1.4. Diagramy aktywności (204)

15.2. Dyskusja (205)

Rozdział 16. Gry planszowe (207)

16.1. Zakres i wstępna analiza (208)

16.1.1. "Kółko i krzyżyk" (208)
16.1.2. Szachy (209)

16.2. Interakcja (213)
16.3. Z powrotem do szkieletu aplikacji (215)
16.4. Stany (217)

Rozdział 17. Symulacja metodą kolejnych zdarzeń (219)

17.1. Wymagania (219)

17.1.1. Bardziej szczegółowy opis (220)

17.2. Zarys modelu klasy (222)
17.3. Przypadki użycia (224)

17.3.1. Podsumowanie przypadku użycia tworzenie modelu (224)
17.3.2. Podsumowanie przypadku użycia obserwowanie zachowania (225)
17.3.3. Podsumowanie przypadku użycia zbieranie danych statystycznych (225)
17.3.4. Podsumowanie przypadku użycia uruchomienie modelu (225)

17.4. Standardowy mechanizm symulacji opartej na procesie (226)
17.5. Powiązania i możliwości nawigacji (227)
17.6. Klasy w szczegółach (230)

17.6.1. Klasa Zarzadca (230)
17.6.2. Klasa JednostkaAktywna (231)
17.6.3. Klasa JednostkaPasywna (233)
17.6.4. Klasa Zasob (233)

17.7. Klasa Raport (236)
17.8. Klasa DaneStatystyczne (236)

17.8.1. Klasa Srednia (236)

17.9. Budowanie kompletnego modelu symulacji (237)
17.10. Ucztujący filozofowie (238)

Część IV W stronę praktyki (241)
Rozdział 18. Wielokrotne używanie: komponenty i wzorce (243)

18.1. Praktyczne informacje na temat wielokrotnego używania (243)

18.1.1. Co może być użyte wielokrotnie i w jaki sposób? (244)
18.1.2. Dlaczego używać powtórnie? (246)
18.1.3. Dlaczego używanie wielokrotne jest trudne? (247)
18.1.4. Które komponenty w naturalny sposób nadają się do powtórnego użycia? (248)
18.1.5. A co z budowaniem własnych komponentów? (249)
18.1.6. Jaką różnicę sprawia zorientowanie obiektowe? (250)

18.2. Wzorce projektowe (251)

18.2.1. Przykład: Fasada (254)
18.2.2. Język UML i wzorce (254)

18.3. Szkielety (256)

Rozdział 19. Jakość produktu: weryfikowanie, walidacja i testowanie (257)

19.1. Omówienie jakości (257)
19.2. W jaki sposób można osiągnąć wysoką jakość? (258)

19.2.1. Nastawienie na produkt (258)
19.2.2. Nastawienie na proces (258)
19.2.3. Dalsza lektura (259)

19.3. Weryfikacja (259)
19.4. Walidacja (260)

19.4.1. Użyteczność (261)

19.5. Testowanie (262)

19.5.1. Wybieranie i przeprowadzanie testów (263)
19.5.2. Dodatkowe problemy związane ze zorientowaniem obiektowym (265)
19.5.3. Dlaczego testowanie jest często przeprowadzane źle? (267)

19.6. Przeglądy i inspekcje (268)

19.6.1. Problemy związane z przeglądami FTR (269)

Rozdział 20. Jakość procesu: zarządzanie, zespoły i kontrola jakości (271)

20.1. Zarządzanie (271)

20.1.1. Zarządzanie projektem (272)
20.1.2. Szacowanie projektu iteracyjnego (273)
20.1.3. Zarządzanie projektowaniem opartym na komponentach (274)
20.1.4. Zarządzanie ludźmi (275)

20.2. Zespoły (276)
20.3. Przywództwo (277)

20.3.1. Zmiana procesu projektowania (278)

20.4. Kontrola jakości (279)

20.4.1. Kontrola jakości w procesach iteracyjnych (281)
20.4.2. Kompleksowe zarządzanie jakością (281)

20.5. Dalsza lektura (283)

Skorowidz (289)

6		(0)
5		(1)
4		(1)
3		(0)
2		(0)
1		(0)

Liczba ocen: 2

Średnia ocena
czytelników

Oceń książkę

UML. Inżynieria oprogramowania. Wydanie II:

Ocena : 5 Ocena książki 2009-06-08

Jarek

Książkę poleciłbym każdemu, kto szuka podręcznika analizy obiektowej popartego przykładami rozwiązań ilustrowanymi właśnie z pomocą notacji UML. Jest to moim zdaniem jedna z lepszych pozycji na rynku z tego zakresu. Napisana jest w sposób bardzo przystępny i praktyczny. Teoria (tam gdzie się pojawia) jest poparta przykładami jej użycia. Jest to także bardzo dobry podręcznik projektowania. Książka ma pewną cechę wyróżniającą ją z innych: opisuje analizę obiektową ilustrując ją diagramami UML (omawiając je także). Nie da się nauczyć notacji obiektowej, jaką jest UML, bez znajomości analizy obiektowej czy obiektowego projektowania (czy wręcz programowania) podobnie jak nie da sie (i nie ma sensu!) uczyć się cyrylicy bez znajmości jezyka rosyjskiego a mimo to wielu autorów typowych podręczników UML stale próbuje to robić. Ksiązka ta to właśnie podręcznik inzynierii oprogramowania zorientowanego obiektowo ilustrowany (dokumentowany) diagramami w notacji UML i to ma głębki sens. Można tę książke potraktować jako bardzo dobry podręcznik podstaw UMl ilustrowany inżynieria progamowania zorientowana obiektowo.

Ocena : 4 Ocena książki 2008-10-10

guci0

Trudna i nudna, choć daje dobre podstawy - w sumie tylko od Ciebie zależy jak wgryziesz się w temat. WAŻNE: Jak już zapoznasz się z tą książką - KUP inną, ale z dobrymi przykładami/projektami, po prostu utrwalisz wiedzę i podkręcisz możliwości!