reklama - zainteresowany?

UML. Inżynieria oprogramowania. Wydanie II - Helion

UML. Inżynieria oprogramowania. Wydanie II
Autor: Perdita Stevens
Tytuł oryginału: Using UML: Software Engineering with Objects and Components (2nd Edition)
Tłumaczenie: Ireneusz Jakóbik
ISBN: 978-83-246-0805-8
stron: 304, Format: B5, okładka: miękka
Data wydania: 2007-07-18
Księgarnia: Helion

Cena książki: 49,00 zł

Dodaj do koszyka UML. Inżynieria oprogramowania. Wydanie II

Tagi: programowanie-kupon | UML - Programowanie

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.

Dodaj do koszyka UML. Inżynieria oprogramowania. Wydanie II

 

Osoby które kupowały "UML. Inżynieria oprogramowania. Wydanie II", wybierały także:

  • Ruby on Rails. Ćwiczenia
  • Zen Steve'a Jobsa
  • ASP.NET MVC. Kompletny przewodnik dla programistów interaktywnych aplikacji internetowych w Visual Studio
  • TDD. Sztuka tworzenia dobrego kodu
  • GitHub. Przyjazny przewodnik

Dodaj do koszyka UML. Inżynieria oprogramowania. Wydanie II

Spis treści

UML. Inżynieria oprogramowania. Wydanie II -- spis treści

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)

Dodaj do koszyka UML. Inżynieria oprogramowania. Wydanie II

Code, Publish & WebDesing by CATALIST.com.pl



(c) 2005-2024 CATALIST agencja interaktywna, znaki firmowe należą do wydawnictwa Helion S.A.