Cyfroteka.pl

klikaj i czytaj online

Cyfro
Czytomierz
00441 003475 12430946 na godz. na dobę w sumie
Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java - książka
Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java - książka
Autor: , Liczba stron: 872
Wydawca: Helion Język publikacji: polski
ISBN: 978-83-246-2872-8 Data wydania:
Lektor:
Kategoria: ebooki >> komputery i informatyka >> programowanie >> uml - programowanie
Porównaj ceny (książka, ebook, audiobook).

Sprawdź, jak sprawnie i bezbłędnie projektować systemy informatyczne!

Projektowanie systemów informatycznych to zadanie bardzo skomplikowane. Ogromna liczba zależności, zasad i wyjątków od nich sprawia, że nie jest możliwe podejście do tego zadania ot tak, z marszu. Zbieranie i analiza wymagań, przygotowanie diagramów klas, aktywności, stanów czy interakcji to tylko część etapów, z którymi musi poradzić sobie projektant. Jeżeli nałożyć na to wszystko wzorce projektowe, stajemy przed prawie nierozwiązywalnym zadaniem. Na szczęście - prawie!

Dzięki tej książce dowiesz się, jak sprostać temu karkołomnemu zadaniu! W trakcie lektury poznasz język UML, który wprowadził porządek w tym skomplikowanym procesie, oraz podstawowe koncepcje inżynierii oprogramowania. Nauczysz się zarządzać procesem tworzenia oprogramowania, zbierać oraz analizować wymagania, identyfikować podsystemy, specyfikować interfejsy oraz testować. Znajdziesz tu wszystko na temat zarządzania zmianami. W trakcie lektury sprawdzisz, jak wygląda cykl życia oprogramowania oraz jak zarządzać konfiguracją. Dodatkowo poznasz metodologię działań, które doprowadzą Cię do wyznaczonego celu. Książka ta stanowi obowiązkową pozycję dla każdego projektanta oraz analityka. Jednak programiści również znajdą tu wiele cennych wskazówek!

Dobry projekt systemu to podstawa sukcesu!

Znajdź podobne książki Ostatnio czytane w tej kategorii

Darmowy fragment publikacji:

Idź do • Spis treści • Przykładowy rozdział • Skorowidz Katalog książek • Katalog online • Zamów drukowany katalog Twój koszyk • Dodaj do koszyka Cennik i informacje • Zamów informacje o nowościach • Zamów cennik Czytelnia • Fragmenty książek online Kontakt Helion SA ul. Kościuszki 1c 44-100 Gliwice tel. 32 230 98 63 e-mail: helion@helion.pl © Helion 1991–2011 Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java Autorzy: Bernd Bruegge, Allen H. Dutoit Tłumaczenie: Andrzej Grażyński ISBN: 978-83-246-2872-8 Tytuł oryginału: Object-Oriented Software Engineering Using UML, Patterns, and Java (3rd Edition) Format: 172×245, stron: 872 Sprawdź, jak sprawnie i bezbłędnie projektować systemy informatyczne! • Czym jest inżynieria oprogramowania? • Jak zapanować nad wszystkimi aspektami procesu projektowania? • Jak wygląda cykl życia oprogramowania? Projektowanie systemów informatycznych to zadanie bardzo skomplikowane. Ogromna liczba zależności, zasad i wyjątków od nich sprawia, że nie jest możliwe podejście do tego zadania ot tak, z marszu. Zbieranie i analiza wymagań, przygotowanie diagramów klas, aktywności, stanów czy interakcji to tylko część etapów, z którymi musi poradzić sobie projektant. Jeżeli nałożyć na to wszystko wzorce projektowe, stajemy przed prawie nierozwiązywalnym zadaniem. Dzięki tej książce dowiesz się, jak sprostać temu karkołomnemu zadaniu! Poznasz język UML, który wprowadził porządek w tym skomplikowanym procesie, oraz podstawowe koncepcje inżynierii oprogramowania. Nauczysz się zarządzać procesem tworzenia oprogramowania, zbierać oraz analizować wymagania, identyfikować podsystemy, specyfikować interfejsy oraz testować. Znajdziesz tu wszystko na temat zarządzania zmianami. W trakcie lektury sprawdzisz, jak wygląda cykl życia oprogramowania oraz jak zarządzać konfiguracją. Dodatkowo poznasz metodologię działań, które doprowadzą Cię do wyznaczonego celu. Książka ta stanowi obowiązkową pozycję dla każdego projektanta oraz analityka, także programiści również znajdą tu wiele cennych wskazówek! • Niepowodzenia w inżynierii oprogramowania • Podstawowe koncepcje inżynierii oprogramowania • Modelowanie przy użyciu języka UML • Organizacja projektu • Narzędzie do komunikacji grupowej • Proces zbierania wymagań • Identyfikacja aktorów, scenariuszy oraz przypadków użycia • Określanie obiektów modelu analitycznego • Analiza wymagań • Dekompozycja systemu na podsystemy • Identyfikacja celów projektowych • Projektowanie obiektów • Wzorce projektowe • Specyfikowanie interfejsów • Odwzorowywanie modelu na kod • Testowanie • Zarządzanie zmianami i konfiguracją • Cykl życia oprogramowania • Metodologie Dobry projekt systemu to podstawa sukcesu! Spis treści Przedmowa Wstęp Podziękowania CZĘŚĆ I Zaczynamy Rozdział 1. Wprowadzenie do inżynierii oprogramowania 1.1. Wprowadzenie: niepowodzenia w inżynierii oprogramowania 1.2. Rozwiązywanie problemów Pozyskiwanie wiedzy Racjonalizacja 1.3. 1.4. 1.5. Czym jest inżynieria oprogramowania? 1.2.1. Modelowanie 1.2.2. 1.2.3. 1.2.4. Podstawowe koncepcje inżynierii oprogramowania 1.3.1. Uczestnicy i role Systemy i modele 1.3.2. Produkty 1.3.3. 1.3.4. Aktywności, zadania i zasoby 1.3.5. Wymagania funkcyjne i pozafunkcyjne 1.3.6. Notacje, metody i metodologie Aktywności inżynierii oprogramowania 1.4.1. 1.4.2. 1.4.3. 1.4.4. 1.4.5. 1.4.6. Zarządzanie tworzeniem oprogramowania 1.5.1. 1.5.2. 1.5.3. 1.5.4. 1.5.5. 1.5.6. Komunikacja Zarządzanie racjonalizacją Zarządzanie konfiguracją oprogramowania Zarządzanie projektem Cykl życiowy oprogramowania Podsumowanie Zbieranie wymagań Analiza Projekt systemu Projektowanie obiektów Implementowanie Testowanie 17 19 31 33 35 36 38 38 40 41 42 43 44 46 46 47 48 48 49 50 51 51 53 53 54 54 55 55 56 56 56 57 6 Spis treĂci 1.6. 1.7. 1.8. Analiza przypadku — system ARENA Literatura uzupełniająca Ćwiczenia Rozdział 2. Modelowanie w języku UML 2.1. Wprowadzenie 2.2. Ogólnie o UML 2.2.1. Diagramy przypadków użycia 2.2.2. Diagramy klas 2.2.3. Diagramy interakcji 2.2.4. Diagram stanów 2.2.5. Diagramy aktywności Podstawowe koncepcje modelowania 2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.3.5. Modelowanie zorientowane obiektowo 2.3.6. Systemy, modele i widoki Typy danych, abstrakcyjne typy danych i instancje Klasy, klasy abstrakcyjne i obiekty Klasy zdarzeniowe, zdarzenia i komunikaty Falsyfikacja i prototypowanie 2.4. UML — głębszy wgląd 2.4.1. Diagramy przypadków użycia 2.4.2. Diagramy klas 2.4.3. Diagramy interakcji 2.4.4. Diagramy stanów 2.4.5. Diagramy aktywności 2.4.6. Organizacja diagramów 2.4.7. Rozszerzenia diagramów Literatura uzupełniająca Ćwiczenia 57 58 59 63 64 65 65 65 67 67 68 69 69 72 73 75 76 77 78 79 86 95 98 101 104 106 107 108 113 114 115 119 119 122 124 126 128 128 135 138 146 146 146 2.3. 2.5. 2.6. 3.4. 3.5. Rozdział 3. Organizacja projektu i komunikacja 3.1. Wstęp — katastrofa Ariane 3.2. O projekcie ogólnie 3.3. Role w realizacji projektu Zadania i produkty Koncepcje organizacyjne projektu 3.3.1. Organizacja projektów 3.3.2. 3.3.3. 3.3.4. Harmonogramy Koncepcje komunikacyjne projektu 3.4.1. 3.4.2. 3.4.3. Mechanizmy komunikacyjne Aktywności organizacyjne 3.5.1. Dołączanie do zespołu 3.5.2. Dołączanie do infrastruktury komunikacyjnej Komunikacja planowa Komunikacja pozaplanowa Spis treĂci 3.5.3. Udział w zebraniach zespołu 3.5.4. Organizacja przeglądów Literatura uzupełniająca Ćwiczenia 3.6. 3.7. CZĘŚĆ II Zmagania ze złożonością Rozdział 4. Zbieranie wymagań 4.1. Wstęp: przykłady problemów z użytecznością 4.2. O zbieraniu wymagań ogólnie Koncepcje zbierania wymagań 4.3. 4.3.1. Wymagania funkcyjne 4.3.2. Wymagania pozafunkcyjne 4.3.3. 4.3.4. 4.3.5. Kompletność, spójność, jednoznaczność i poprawność Realizm, weryfikowalność i identyfikowalność Inżynieria pierwotna, inżynieria wtórna i inżynieria interfejsu 4.4. 4.5. 4.6. 4.7. 4.8. Aktywności związane ze zbieraniem wymagań Identyfikacja aktorów 4.4.1. Identyfikacja scenariuszy 4.4.2. 4.4.3. Identyfikacja przypadków użycia 4.4.4. Doskonalenie przypadków użycia 4.4.5. Identyfikacja relacji między aktorami a przypadkami użycia Początkowa identyfikacja obiektów modelu analitycznego Identyfikacja wymagań pozafunkcyjnych 4.4.7. Zarządzanie zbieraniem wymagań 4.5.1. Negocjowanie specyfikacji z klientem: 4.4.6. metoda Joint Application Design Zarządzanie identyfikowalnością 4.5.2. 4.5.3. Dokumentowanie zbierania wymagań Analiza przypadku — system ARENA 4.6.1. Wstępna deklaracja problemu 4.6.2. Identyfikacja aktorów i scenariuszy 4.6.3. Identyfikacja przypadków użycia 4.6.4. Doskonalenie przypadków użycia i identyfikacja relacji Identyfikacja wymagań pozafunkcyjnych 4.6.5. 4.6.6. Wnioski Literatura uzupełniająca Ćwiczenia 7 147 149 151 152 155 157 158 159 161 161 162 164 165 165 166 167 169 171 173 176 179 182 183 185 187 188 190 190 192 195 198 204 204 205 207 8 Spis treĂci Rozdział 5. Analiza wymagań Analityczny model obiektowy i modele dynamiczne Obiekty encji, obiekty brzegowe i obiekty sterujące Generalizacja i specjalizacja 5.1. Wstęp: złudzenie optyczne 5.2. O analizie wymagań ogólnie Koncepcje analizy wymagań 5.3. 5.3.1. 5.3.2. 5.3.3. Aktywności analizy wymagań: od przypadków użycia do obiektów 5.4.1. 5.4.2. 5.4.3. 5.4.4. Odwzorowywanie przypadków użycia w obiekty Identyfikacja obiektów encji Identyfikacja obiektów brzegowych Identyfikacja obiektów sterujących 5.4. za pomocą diagramów sekwencji 5.4.5. Modelowanie interakcji między obiektami za pomocą kart CRC Identyfikacja skojarzeń Identyfikacja agregacji Identyfikacja atrybutów 5.4.6. 5.4.7. 5.4.8. 5.4.9. Modelowanie zachowania poszczególnych obiektów uzależnionego od ich stanu Przydzielanie odpowiedzialności Komunikacja w związku z analizą wymagań Iteracje modelu analitycznego 5.4.10. Modelowanie relacji dziedziczenia między obiektami 5.4.11. Przeglądy modelu analitycznego 5.4.12. Podsumowanie analizy Zarządzanie analizą wymagań 5.5.1. Dokumentowanie analizy wymagań 5.5.2. 5.5.3. 5.5.4. 5.5.5. Uzgodnienie modelu analitycznego z klientem Analiza przypadku — system ARENA 5.6.1. Identyfikacja obiektów encji Identyfikacja obiektów brzegowych 5.6.2. 5.6.3. Identyfikacja obiektów sterujących 5.6.4. Modelowanie interakcji między obiektami 5.6.5. Weryfikacja i konsolidacja modelu analitycznego 5.6.6. Wnioski Literatura uzupełniająca Ćwiczenia 5.5. 5.6. 5.7. 5.8. 211 212 212 214 214 215 216 217 218 220 222 224 228 228 231 232 233 234 235 236 237 238 239 240 241 243 245 245 250 251 252 254 256 258 258 263 264 266 267 Rozdział 6. Projektowanie systemu — dekompozycja na podsystemy 6.1. Wstęp: projekt mieszkania 6.2. O projektowaniu systemu ogólnie 6.3. Koncepcje projektowania systemu Spis treĂci 6.4. 6.5. 6.6. Podsystemy i klasy Sprzężenie i spoistość 6.3.1. 6.3.2. Usługi i interfejsy podsystemów 6.3.3. 6.3.4. Warstwy i partycje 6.3.5. Aktywności projektowania systemu: od obiektów do podsystemów 6.4.1. Style architektoniczne Punkt wyjścia: model analityczny systemu planowania podróży Identyfikowanie celów projektowych Identyfikowanie podsystemów 6.4.2. 6.4.3. Literatura uzupełniająca Ćwiczenia Rozdział 7. Projekt systemu: realizacja celów projektowych 7.1. Wstęp: przykład redundancji 7.2. O aktywnościach projektowania systemu ogólnie 7.3. 7.4. Koncepcje: diagramy wdrażania UML Aktywności realizacji celów projektowych 7.4.1. Odwzorowywanie podsystemów w procesory i komponenty Identyfikowanie trwałych danych i ich przechowywanie Projektowanie globalnego przepływu sterowania Identyfikowanie usług Identyfikowanie warunków granicznych 7.4.2. 7.4.3. Definiowanie założeń kontroli dostępu 7.4.4. 7.4.5. 7.4.6. 7.4.7. Weryfikowanie projektu systemu Zarządzanie projektowaniem systemu 7.5.1. Dokumentowanie projektu systemu 7.5.2. 7.5.3. 7.5.4. Analiza przypadku — system ARENA 7.6.1. 7.6.2. 7.6.3. Odwzorowanie podsystemów w procesory Przydzielanie odpowiedzialności Komunikacja w projektowaniu systemu Iteracje projektowania systemu Identyfikowanie celów projektowych Identyfikowanie podsystemów i komponenty Identyfikowanie i przechowywanie trwałych danych Projektowanie globalnego przepływu sterowania Identyfikowanie usług Identyfikowanie warunków granicznych 7.6.4. 7.6.5. Definiowanie założeń kontroli dostępu 7.6.6. 7.6.7. 7.6.8. 7.6.9. Wnioski Literatura uzupełniająca Ćwiczenia 7.5. 7.6. 7.7. 7.8. 9 268 270 271 275 279 288 288 290 294 296 297 301 302 303 304 306 306 309 312 319 321 323 326 328 328 330 331 333 334 335 336 337 339 340 341 343 345 347 348 348 10 Spis treĂci Rozdział 8. Projektowanie obiektów: wielokrotne wykorzystywanie rozwiązań wzorcowych 8.1. Wstęp: wpadki produkcyjne 8.2. O projektowaniu obiektów ogólnie 8.3. Koncepcja wielokrotnego wykorzystywania — dziedziczenie, delegowanie i wzorce projektowe 8.3.1. Obiekty aplikacyjne i obiekty realizacyjne 8.3.2. Dziedziczenie implementacyjne i dziedziczenie specyfikacyjne 8.3.3. Delegowanie 8.3.4. Zasada zastępowania Liskov 8.3.5. Delegowanie i dziedziczenie we wzorcach projektowych 8.4. Wybór wzorców projektowych i gotowych komponentów 8.4.1. Hermetyzacja przechowywania danych za pomocą wzorca projektowego Most 8.4.2. Hermetyzacja niekompatybilnych komponentów za pomocą wzorca projektowego Adapter 8.4.3. Hermetyzacja kontekstu za pomocą wzorca projektowego Strategia 8.4.4. Hermetyzacja platformy za pomocą wzorca projektowego Fabryka abstrakcyjna 8.4.5. Hermetyzacja przepływu sterowania za pomocą wzorca projektowego Polecenie 8.4.6. Hermetyzacja hierarchii za pomocą wzorca projektowego Kompozyt 8.4.7. Heurystyki wyboru wzorców projektowych 8.4.8. Identyfikowanie i przystosowywanie frameworków aplikacyjnych Zarządzanie wykorzystywaniem gotowych rozwiązań 8.5.1. Dokumentowanie wykorzystywania gotowych rozwiązań Przydzielanie odpowiedzialności 8.5.2. Analiza przypadku — system ARENA 8.6.1. Zastosowanie wzorca projektowego Fabryka abstrakcyjna Zastosowanie wzorca projektowego Polecenie Zastosowanie wzorca projektowego Obserwator 8.6.2. 8.6.3. 8.6.4. Wnioski Literatura uzupełniająca Ćwiczenia 8.5. 8.6. 8.7. 8.8. 353 354 355 359 359 360 363 364 364 367 368 371 373 376 377 378 379 381 386 388 389 390 390 392 393 393 394 395 Spis treĂci Rozdział 9. Projektowanie obiektów: specyfikowanie interfejsów 9.1. Wstęp: kolej miejska i tramwaje 9.2. O specyfikowaniu interfejsów ogólnie Koncepcje specyfikowania interfejsów 9.3. 9.3.1. 9.3.2. 9.3.3. Implementator, ekstender i użytkownik klasy Typy, sygnatury i widzialność Kontrakty: niezmienniki, warunki wstępne i warunki końcowe Język OCL (Object Constraint Language) Kolekcje OCL: zbiory, wielozbiory i ciągi Kwantyfikatory OCL: forAll() i exists() 9.3.4. 9.3.5. 9.3.6. Aktywności specyfikowania interfejsów 9.4.1. 9.4.2. 9.4.3. Identyfikowanie brakujących atrybutów i operacji Specyfikowanie typów, sygnatur i widzialności Specyfikowanie warunków wstępnych i warunków końcowych Specyfikowanie niezmienników 9.4.4. 9.4.5. Dziedziczenie kontraktów Zarządzanie projektowaniem obiektów 9.5.1. Dokumentowanie projektowania obiektów 9.5.2. 9.5.3. Wykorzystywanie kontraktów w analizie wymagań Analiza przypadku — system ARENA 9.6.1. Przydzielanie odpowiedzialności Identyfikowanie brakujących operacji w klasach TournamentStyle i Round Specyfikowanie kontraktów dla klas TournamentStyle i Round Specyfikowanie kontraktów dla klas KnockOutStyle i KnockOutRound 9.6.2. 9.6.3. 9.4. 9.5. 9.6. 9.7. 9.8. 9.6.4. Wnioski Literatura uzupełniająca Ćwiczenia Rozdział 10. Odwzorowywanie modelu na kod 10.1. Wstęp: Władca Pierścieni 10.2. O odwzorowywaniu ogólnie 10.3. Koncepcje odwzorowywania 10.3.1. Transformowanie modelu 10.3.2. Refaktoryzacja 10.3.3. 10.3.4. 10.3.5. Zasady transformacji 10.4. Aktywności odwzorowywania Inżynieria postępująca Inżynieria odwracająca 10.4.1. Optymalizowanie modelu obiektowego 10.4.2. Odwzorowywanie skojarzeń na kolekcje 11 399 400 401 403 403 403 406 407 411 415 416 417 418 419 421 424 425 425 431 432 433 434 435 438 439 440 440 445 446 447 448 449 450 452 452 453 454 455 458 12 Spis treĂci 10.4.3. Odwzorowywanie kontraktów w wyjątki 10.4.4. Odwzorowywanie modelu obiektowego w schematy bazy danych 10.5. Zarządzanie transformacjami 10.5.1. Dokumentowanie transformacji 10.5.2. Przydzielanie odpowiedzialności 10.6. Analiza przypadku — system ARENA 10.6.1. Statystyki systemu ARENA 10.6.2. Odwzorowywanie skojarzeń na kolekcje 10.6.3. Odwzorowywanie kontraktów w wyjątki 10.6.4. Odwzorowywanie modelu obiektowego w schemat bazy danych 10.6.5. Wnioski 10.7. Literatura uzupełniająca 10.8. Ćwiczenia Rozdział 11. Testowanie 11.1. Wstęp: testowanie wahadłowców 11.2. O testowaniu ogólnie 11.3. Koncepcje związane z testowaniem 11.3.1. Usterki, błędne stany i awarie 11.3.2. Przypadki testowe 11.3.3. Namiastki testowe i sterowniki testowe 11.3.4. Poprawki 11.4. Aktywności związane z testowaniem Inspekcja komponentu 11.4.1. 11.4.2. Testowanie użyteczności 11.4.3. Testowanie jednostkowe 11.4.4. Testowanie integracyjne 11.4.5. Testowanie systemu 11.5. Zarządzanie testowaniem 11.5.1. Planowanie testów 11.5.2. Dokumentowanie testowania 11.5.3. Przydzielanie odpowiedzialności 11.5.4. Testowanie regresyjne 11.5.5. Automatyzacja testowania 11.5.6. Testowanie bazujące na modelach 11.6. Literatura uzupełniająca 11.7. Ćwiczenia CZĘŚĆ III Zarządzanie zmianami Rozdział 12. Zarządzanie racjonalizacją 12.1. Wstęp: przycinanie wędzonej szynki 12.2. O racjonalizacji ogólnie 465 469 475 475 477 478 478 480 482 484 485 485 486 491 492 494 498 500 503 505 505 506 507 508 510 519 526 531 532 532 536 537 538 539 541 543 547 549 550 551 Spis treĂci 12.3. Koncepcje racjonalizacji 12.3.1. CTC — system centralnego sterowania ruchem 12.3.2. Definiowanie problemów: zagadnienia 12.3.3. Eksploracja przestrzeni rozwiązań: propozycje 12.3.4. Wartościowanie elementów przestrzeni rozwiązań: kryteria i argumenty 12.3.5. Kolapsacja przestrzeni rozwiązań: rozstrzygnięcie 12.3.6. Implementowanie rozstrzygnięć: elementy działania 12.3.7. Przykłady modeli zagadnień i ich realizacje 12.4. Aktywności racjonalizacji — od zagadnień do decyzji 12.4.1. Projekt systemu CTC 12.4.2. Kolekcjonowanie racjonalizacji w ramach zebrań 12.4.3. Asynchroniczne kolekcjonowanie racjonalizacji 12.4.4. Racjonalizacja dyskutowanych zmian 12.4.5. Rekonstruowanie racjonalizacji 12.5. Kierownicze aspekty zarządzania racjonalizacją 12.5.1. Dokumentowanie racjonalizacji 12.5.2. Przypisywanie odpowiedzialności 12.5.3. Heurystyki komunikowania racjonalizacji 12.5.4. Modelowanie i negocjowanie zagadnień 12.5.5. Strategie rozwiązywania konfliktów 12.6. Literatura uzupełniająca 12.7. Ćwiczenia Rozdział 13. Zarządzanie konfiguracją 13.1. Wstęp: samoloty 13.2. O zarządzaniu konfiguracją ogólnie 13.3. Koncepcje zarządzania konfiguracją 13.3.1. Elementy konfiguracji i agregaty CM 13.3.2. Wersje i konfiguracje 13.3.3. Żądania zmian 13.3.4. Promocje i emisje 13.3.5. Repozytoria i przestrzenie robocze 13.3.6. Schematy identyfikowania wersji 13.3.7. Zmiany i zbiory zmian 13.3.8. Narzędzia wspomagające zarządzanie konfiguracją 13.4. Aktywności tworzące zarządzanie konfiguracją 13.4.1. Identyfikowanie elementów konfiguracji i agregatów CM 13.4.2. Zarządzanie promocjami 13.4.3. Zarządzanie emisjami 13.4.4. Zarządzanie gałęziami 13.4.5. Zarządzanie wariantami 13.4.6. Zarządzanie propozycjami zmian i ich implementowaniem 13 554 555 556 557 559 560 561 562 567 568 569 577 579 582 585 585 587 588 589 590 592 593 597 598 600 602 603 604 604 605 606 606 608 610 611 613 615 616 619 623 626 14 Spis treĂci 13.5. Kierownicze aspekty zarządzania konfiguracją 13.5.1. Dokumentowanie zarządzania konfiguracją 13.5.2. Przypisywanie odpowiedzialności 13.5.3. Planowanie aktywności 13.5.4. w ramach zarządzania konfiguracją Integracja ciągła jako optymalizacja zarządzania promocjami i ich testowaniem 13.6. Literatura uzupełniająca 13.7. Ćwiczenia Rozdział 14. Zarządzanie projektem 14.1. Wstęp: uruchomienie misji STS-51L 14.2. O zarządzaniu projektem ogólnie 14.3. Koncepcje zarządzania projektem 14.3.1. Zadania i aktywności 14.3.2. Produkty, pakiety pracy i role 14.3.3. Struktura podziału pracy 14.3.4. Model zadań 14.3.5. Macierz kwalifikacji 14.3.6. Plan zarządzania projektem 14.4. Aktywności klasycznego zarządzania projektem 14.4.1. Planowanie projektu 14.4.2. Organizowanie projektu 14.4.3. Kontrolowanie projektu 14.4.4. Kończenie projektu 14.5. Aktywności „zwinnej” realizacji projektu 14.5.1. Planowanie projektu: wykazy zaległości produktu i przebiegu 14.5.2. Organizowanie projektu 14.5.3. Kontrolowanie projektu: dni robocze i wykresy wygaszania 14.5.4. Kończenie projektu: przeglądy przebiegów 14.6. Literatura uzupełniająca 14.7. Ćwiczenia Rozdział 15. Cykl życiowy oprogramowania 15.1. Wstęp: nawigacja polinezyjska 15.2. IEEE 1074: standard cykli życiowych 15.2.1. Procesy i aktywności 15.2.2. Modelowanie cyklu życiowego 15.2.3. Zarządzanie projektem 15.2.4. Prerealizacja 15.2.5. Realizacja — tworzenie systemu 15.2.6. Postrealizacja 15.2.7. Procesy integralne (międzyrealizacyjne) 627 627 628 629 630 632 633 637 638 639 646 646 646 648 649 650 651 653 654 659 665 671 673 674 675 675 677 677 679 683 684 688 688 690 690 691 692 693 694 Spis treĂci 15.3. Charakteryzowanie dojrzałości modeli cyklu życiowego 15.4. Modele cyklu życiowego 15.4.1. Sekwencyjne modele ukierunkowane na aktywności 15.4.2. Iteracyjne modele ukierunkowane na aktywności 15.4.3. Modele ukierunkowane na encje 15.5. Literatura uzupełniająca 15.6. Ćwiczenia Rozdział 16. Wszystko razem, czyli metodologie 16.1. Wstęp: pierwsze zdobycie K2 16.2. Środowisko projektu 16.3. Zagadnienia metodologiczne Ile planowania? Ile powtarzalności? Ile modelowania? Ile procesów cyklu życiowego? Ile kontroli i monitorowania? 16.3.1. 16.3.2. 16.3.3. 16.3.4. 16.3.5. 16.3.6. Kiedy przedefiniować cele projektu? 16.4. Spektrum metodologii 16.4.1. Metodologia Royce’a 16.4.2. Programowanie ekstremalne (XP) 16.4.3. Metodologie rugby 16.5. Analizy przypadku 16.5.1. Projekt XP: ATRACT 16.5.2. Lokalny klient: FRIEND 16.5.3. Rozproszony projekt: JAMES 16.5.4. Podsumowanie analiz przypadku 16.6. Literatura uzupełniająca 16.7. Ćwiczenia Dodatki Dodatek A Wzorce projektowe A.1. Fabryka abstrakcyjna (Abstract Factory) — hermetyzacja platformy Polecenie (Command) — hermetyzacja przepływu sterowania A.2. Adapter (Adapter) — otoczka dla starszego kodu A.3. Most (Bridge) — podmiana implementacji A.4. A.5. Kompozyt (Composite) — rekurencyjna reprezentacja hierarchii A.6. A.7. Obserwator (Observer) — oddzielenie encji od widoków A.8. A.9. A.10. Heurystyki pomocne w wyborze wzorców projektowych Proxy (Proxy) — hermetyzacja kosztownych obiektów Strategia (Strategy) — hermetyzacja algorytmów Fasada (Facade) — hermetyzacja podsystemów 15 695 698 699 701 706 709 710 713 714 717 719 719 720 721 723 723 724 724 725 731 737 742 743 746 754 761 766 766 769 771 772 773 774 775 776 777 778 779 780 781 16 Dodatek B Objaśnienia haseł Terminologia Słownik terminów angielskich B.1. B.2. Dodatek C Bibliografia Skorowidz Spis treĂci 783 783 817 831 847 12.1. WstÚp: przycinanie wÚdzonej szynki 12 Zarządzanie racjonalizacją 549 Można opisywać motocykl w kategoriach „co?” i „jak”, czyli w kategoriach komponentów, z których się składa, oraz zasad, według których komponenty te funkcjonują; oglądając ilustrację motocykla, można się jednak tylko domyślać tych wszystkich „gdzie?” i „dlaczego?” decydujących o takim, a nie innym kształcie poszczególnych części i ich wzajemnym rozmieszczeniu. — Robert Pirsig Zen i sztuka oporządzania motocykla W kontekście realizowania projektów pojęcie „racjonalizacja”1 (rationale) oznacza uzasad- nianie podejmowanych decyzji. Dotychczas w treści tej książki opisywaliśmy modele repre- zentujące różne oblicza systemu; model racjonalizacji reprezentuje natomiast powody, dla których funkcjonalność systemu i jej implementacja przyjmują taki, a nie inny kształt. Racjo- nalizacja ma kluczowe znaczenie w co najmniej dwóch aspektach realizacji projektu: wspoma- ganiu podejmowania decyzji oraz kolekcjonowaniu wiedzy. Na tak pojmowaną racjonalizację składają się: x problemy wymagające rozwiązywania, x możliwe ewentualności rozwiązań tych problemów, x decyzje podejmowane w związku z rozwiązywaniem problemów, x kryteria uwzględniane przy podejmowaniu decyzji, x dyskusje programistów prowadzone w związku z wypracowywaniem decyzji. Racjonalizacja przyczynia się do jakości podejmowanych decyzji, bo ujawniania podsta- wowe elementy decyzyjne — kryteria, priorytety i argumenty. Jeśli chodzi o kolekcjonowanie wiedzy, racjonalizacja ma znaczenie krytyczne w sytuacji, gdy pojawia się konieczność zmian: przy wprowadzaniu do systemu nowej funkcjonalności programiści mają możliwość prześle- dzenia podjętych dotychczas decyzji w kontekście ich uzasadnienia, sensowności, adekwatno- ści i tym podobnych; gdy do zespołu dołączają nowi programiści, mogą łatwo zapoznać się ze wspomnianymi decyzjami, studiując dokumenty racjonalizacji systemu. Niestety, racjonalizacja należy do najbardziej złożonych kategorii informacji zarówno w kontekście jej tworzenia, jak i utrzymywania w aktualnym stanie. Zarządzanie racjonalizacją jest bowiem inwestycją, która przynosi zysk dopiero w dłuższej perspektywie. 1 Ponieważ większość badań związanych z racjonalizacją koncentrowała się początkowo na etapie projektowania systemu, do samego rzeczownika „racjonalizacja” przylgnął na dobre przymiotnik „projektowa” (design rationale). Jak jednak pokazujemy w tym rozdziale, racjonalizacja jest nie- rozłącznie związana ze wszystkimi etapami projektu, dlatego będziemy o niej pisać bez przymiot- ników wiążących ją z konkretnymi etapami czy aktywnościami. 550 Rozdziaï 12. x ZarzÈdzanie racjonalizacjÈ W tym rozdziale opiszemy modelowanie zagadnień jako reprezentację modelowania ra- cjonalizacji, omówimy także aktywności związane z tworzeniem, pielęgnowaniem i wykorzy- stywaniem modeli racjonalizacji. Rozdział zakończymy opisem zagadnień menedżerskich związanych z racjonalizacją, takich jak wspomaganie podejmowania decyzji i negocjowanie. 12.1. WstÚp: przycinanie wÚdzonej szynki Modele systemu są abstrakcjami wykonywanych przez niego funkcji. Modele związane z ana- lizą wymagań — model przypadków użycia, model klas i model sekwencji (o których pisaliśmy w rozdziałach 4. „Zbieranie wymagań” i 5. „Analiza wymagań”) — reprezentują zachowanie systemu z perspektywy jego użytkownika. Model projektu systemu (patrz rozdział 6. „Projek- towanie systemu — dekompozycja na podsystemy”) stanowi reprezentację systemu w kon- tekście podziału na podsystemy, celów projektowych, węzłów sprzętowych, przechowywania danych, kontroli dostępu i tak dalej. Model racjonalizacji systemu reprezentuje natomiast całokształt decyzji, przesłanek, powodów i tym podobnych, decydujących o tym, dlaczego system ten zbudowany jest i działa właśnie tak, a nie inaczej. Rozważmy najpierw, dlaczego w ogóle powinniśmy się zastanawiać nad wspomnianym „dlaczego?” — na początek mała dygresja2. Mary zapytała kiedyś swego męża Johna, dlaczego przycina szynkę na obu końcach przed włoże- niem jej do wędzarni. John odparł, że tak robiła jego mama, prawdopodobnie zgodnie z jakimś prze- pisem, on sam nigdy się nad tym nie zastanawiał. Zaciekawiona Mary zapytała więc o to swą teściową, Ann. Ta odrzekła, że jej mama, Zoe, wymyśliła taki właśnie sposób na poprawienie smaku wędzonej szynki Indagowana na tę okoliczność Zoe wyraziła głębokie zdziwienie: nigdy nie przycinała szynki przed wędzeniem, a już sugestia, jakoby takie przycinanie miało poprawiać smak szynki, jest kompletnym absurdem dla kogoś, kto ma choć blade pojęcie na temat kulinariów. Po chwili Zoe przypomniała sobie jednak, że gdy Ann była małą dziewczynką, zdarzyło się wielokrotnie, iż standardowych roz- miarów szynka nie mieściła się w zbyt ciasnym piecu i faktycznie trzeba ją było skracać o kilka cen- tymetrów z obu końców. Wkrótce jednak kupiono nową, większą wędzarnię i technologia skracania szynki poszła w zapomnienie. Programiści i kucharze uwielbiają rozpowszechniać rozmaite pomysły, sposoby, techniki i tym podobne, którym jednak nie towarzyszy wystarczająca racjonalizacja, która mogłaby zwiększyć ich przydatność w konkretnym zastosowaniu. Wszyscy znamy tak zwany problem roku 2000: w latach 60. i 70. ubiegłego wieku wysokie koszty pamięci i magazynowania da- nych skłaniały do poszukiwań różnych optymalizacji rozmiaru tych danych i jedną z takich technik było zapisywanie tylko dwóch końcowych cyfr roku (na przykład „78”), dwie pierwsze („19”) były bowiem niezmienne. Co do tworzonego i używanego wówczas oprogramowania przyjmowano (jako pewnik) założenie, że w roku 2000 pozostanie już po nim co najwyżej wspomnienie. Czas mijał nieubłaganie, pamięci RAM i dyski drastycznie staniały, a progra- miści w dalszym ciągu nie przejmowali się problemem zapisywania cyfr reprezentujących stu- lecie. Ludzkość wkroczyła dumnie w XXI wiek i zaczęły się problemy z operacjami arytme- 2 Popularna historyjka niewiadomego autorstwa. 12.2. O racjonalizacji ogólnie 551 tycznymi wykonywanymi na dwucyfrowych zapisach lat: piszący te słowa tłumacz, urodzony w roku 1958, latem 2001 roku ukończył (jak to wyliczył jeden z programów) 01–58 = – 57 lat, a jego dziadek, świętujący w 2004 roku 105. urodziny, zaproszony został do lokalnego centrum kultury na (darmową) imprezę dla … pięciolatków. I nie można przy tym zrzucać całej winy na pokolenie programistów lat 90.: zdając sobie sprawę ze zbliżającego się fin de siècle, skrępowani byli jednocześnie względami kompatybilności wstecz z eksploatowanym oprogramowaniem — w pewnym sensie kompatybilności z krótkowzrocznością swych star- szych kolegów. W rezultacie, mimo iż mamy już za sobą pierwszą dekadę nowego stulecia, wiele używanych dziś programów dotkniętych jest „syndromem Y2K”, jak zwykło się nazywać (z angielska) opisany problem. Spadek cen pamięci czy kupno większej wędzarni to przykład zmian, które właściwie rozumieć i wykorzystywać (lepiej sobie z nimi radzić) pozwala właśnie modelowanie racjona- lizacji. Kolekcjonowanie uzasadnień podejmowanych decyzji umożliwia modelowanie zależ- ności między tymi decyzjami i początkowo przyjmowanymi założeniami. Gdy zmieniają się założenia, należy ponownie rozważyć zasadność decyzji podjętych na ich podstawie. W tym rozdziale opiszemy techniki kolekcjonowania, pielęgnowania i wykorzystywania modeli ra- cjonalizacji, w szczególności: x ogólny pogląd na modelowanie racjonalizacji (patrz sekcja 12.2), x koncepcje związane z modelami racjonalizacji (patrz sekcja 12.3), x aktywności związane z tworzeniem i wykorzystywaniem modeli racjonalizacji (patrz sekcja 12.4), x zadania menedżera projektu związane z utrzymywaniem modeli racjonalizacji (patrz sekcja 12.5). Zacznijmy jednak od koncepcji samego modelu racjonalizacji. 12.2. O racjonalizacji ogólnie Racjonalizacja decyzji to zespół motywacji kryjących się za jej podjęciem. Na racjonalizację tę składają się: x Zagadnienie (issue). Każda decyzja związana jest z rozwiązywaniem konkretnego problemu. Klarowny opis tego problemu jest kluczowym elementem racjonalizacji; w związku z przedstawionymi przykładami pytania te brzmią „Jak należy wędzić szynkę?” oraz „W jakiej postaci prezentować rok kalendarzowy?”. x Ewentualności (alternatives). Ewentualnościami nazywamy możliwe sposoby roz- wiązania danego problemu, w tym również sposoby, które nie zostały zastosowane ze względu na niespełnienie jednego lub więcej określonych kryteriów. Przykładowo duży piec wędzarniczy może być zbyt drogi, a przechowywanie liczb oznaczających lata w postaci dwubajtowych słów zamiast bajtów może spowolnić szybkość obliczeń i zwiększyć ilość wymaganej pamięci. 552 Rozdziaï 12. x ZarzÈdzanie racjonalizacjÈ x Kryteria (criteria). Określają one cechy, którymi charakteryzować się powinno roz- wiązanie problemu — i tak na przykład przepis na uwędzenie szynki powinien być wykonalny przy użyciu podstawowego wyposażenia domowej kuchni, a programiści decydujący się pół wieku temu na dwucyfrowy zapis roku dążyli do oszczędności pamięci masowych. Na etapie analizy wymagań wspomniane kryteria mają postać wymagań pozafunkcyjnych i ograniczeń dotyczących między innymi łatwości użyt- kowania systemu czy oczekiwanej liczby błędów popełnianych codziennie przez użytkownika wprowadzającego dane wejściowe. Na etapie projektowania systemu kryteria te wyrażają cele projektowe w postaci niezawodności, czasu reakcji i tym podobnych. Z perspektywy menedżera projektu kryteria te wyrażają jego specy- ficzne cele oraz kompromisy, które musi rozstrzygać — na przykład kompromis między jakością systemu a terminem jego dostarczenia. x Argumentacja (arguments). Zarówno sztuka kulinarna, jak i inżynieria oprogra- mowania nie są dyscyplinami algorytmicznymi, bowiem kucharze i programiści napotykają rozmaite problemy i poszukują różnych sposobów ich rozwiązywania, uwzględniając zalety i wady danego sposobu w porównaniu z innymi. Argumento- wanie dotyczy wszelkich aspektów procesu decyzyjnego — kryteriów, uzasadnień, rozważanych ewentualności oraz rozstrzyganych kompromisów. x Decyzje (decisions). Decyzja to rozwiązanie problemu, reprezentujące konkretną ewentualność wybraną zgodnie z określonymi kryteriami ewaluacji. Kilkucentyme- trowe skracanie wędzonej szynki czy ignorowanie cyfr stulecia w zapisie lat to przy- kłady konkretnych decyzji. Konkretny kształt modelu analitycznego czy modelu projektu systemu jest niczym innym, jak skumulowanym efektem ciągu podjętych decyzji. Być może wiele z tych decyzji podjętych zostało bez starannego przeanalizo- wania rozwiązywanego problemu lub należytej eksploracji możliwych ewentualności. Przez cały czas realizowania projektu, na wszystkich jego etapach, zmuszeni jesteśmy do podejmowania licznych decyzji, wspomaganych modelami racjonalizacji, i tak: x W czasie zbierania wymagań i ich analizy decydujemy o kształcie funkcjonalnym systemu, przy wydatnej współpracy z klientem. Podejmowane decyzje motywowane są przez użytkownika lub przez potrzeby organizacyjne. Uzasadnienie tych decyzji staje się użyteczne przy tworzeniu przypadków testowych na potrzeby testów inte- gracyjnych i testów akceptacyjnych. x W czasie projektowania systemu formułujemy cele projektowe i determinujemy kształt dekompozycji systemu na podsystemy. Decyzje związane z celami projektowymi wynikają najczęściej z wymagań pozafunkcyjnych, tak więc kolekcjonowanie ra- cjonalizacji tych decyzji umożliwia śledzenie zależności między dwiema encjami — wymaganiami pozafunkcyjnymi i celami projektowymi: gdy zmienią się wyma- gania, łatwiejsze będzie odpowiednie przeformułowanie celów projektowych. x Zarządzanie projektem wiąże się z przyjmowaniem wielu różnych założeń związanych z relatywnym ryzykiem projektowym — i tak na przykład komponenty utworzone stosunkowo niedawno wymagają (statystycznie) więcej fatygi ze strony programistów 12.2. O racjonalizacji ogólnie 553 niż komponenty w miarę dojrzałe. Kolekcjonowanie racjonalizacji ryzykownych decyzji i opracowywanie „planów odwrotu” umożliwi złagodzenie ewentualnych pro- blemów, które wynikać mogą z tego ryzyka. x W czasie testowania i integrowania podsystemów wykrywamy niezgodności między ich interfejsami. Na podstawie racjonalizacji kryjącej się za konkretnym kształtem tych interfejsów możemy łatwo zidentyfikować założenie, którego niespełnienie okazało się przyczyną usterki i usunąć tę usterkę przy minimalnym wpływie na resztę systemu. Zarządzanie racjonalizacją jest inwestycją, wymagającą określonych zasobów dedyko- wanych zarządzaniu zmianami: kolekcjonując pewne informacje teraz, ułatwiamy sobie póź- niejsze weryfikowanie podejmowanych obecnie decyzji, w związku z wprowadzanymi zmia- nami w systemie. Wielkość wspomnianych zasobów zależna jest od konkretnego typu systemu. Gdy na przykład tworzymy skomplikowany system dla konkretnego klienta, system ten będzie z pewnością doznawał wielu zmian w dłuższej perspektywie; klient, który jest świadom tego faktu, może wówczas nawet zażądać kolekcjonowania racjonalizacji także na swój użytek. Jeśli natomiast tworzymy koncepcyjny prototyp nowego produktu, prototyp ten prawdopo- dobnie okaże się nieprzydatny, gdy rozpoczną się prace nad rzeczywistym produktem. Kolek- cjonowanie racjonalizacji na etapie tworzenia wspomnianego prototypu może opóźnić jego demonstrację, co stwarzać może ryzyko „skasowania” całego projektu; zarządzanie racjonali- zacją jest w tym wypadku inwestycją nieopłacalną, bo w najlepszym razie dającą korzyści nie- współmierne do ponoszonego ryzyka. Kolekcjonowanie racjonalizacji może mieć różną intensywność, odzwierciedlaną w po- staci czterech następujących poziomów: x brak wyraźnego kolekcjonowania — informacja związana z racjonalizacją ma jedynie formę ulotną, bo istnieje tylko w umysłach programistów, a w najlepszym razie — w listach, faksach i innej postaci komunikatach wymienianych między nimi. Całość jawnej dokumentacji systemu skupia się w jego modelach. x rekonstruowanie racjonalizacji — ulotnej (w sensie powyżej opisanym) informa- cji związanej z racjonalizacją nadaje się fizyczną postać w ramach aktywności do- kumentacyjnych projektu. Kryteria projektowe i motywacje kryjące się za najważ- niejszymi decyzjami architektonicznymi integrowane są z odpowiednimi modelami systemu. Odrzucone ewentualności oraz argumenty „za” i „przeciw” nie zostają jawnie udokumentowane. x bieżące kolekcjonowanie racjonalizacji, w związku z każdą podejmowaną decyzją. Informacja związana z racjonalizacją reprezentowana jest w formie odrębnego mo- delu, zawierającego odniesienia do innych modeli — i tak na przykład modele za- gadnień reprezentują racjonalizację w formie grafu, którego każdy węzeł prezentuje zagadnienie, ewentualność lub kryteria ewaluacji. Racjonalizacja modelu analitycz- nego może być wówczas reprezentowana przez powiązania poszczególnych zagad- nieńz odpowiednimi przypadkami użycia. x zintegrowanie racjonalizacji z modelami systemu sprawia, że staje się ona central- nym modelem systemu. Pojawiające się sukcesywnie nowe elementy racjonalizacji zapisywane są w „żywej”, przeszukiwalnej, informacyjnej bazie danych. Wszelkie 554 Rozdziaï 12. x ZarzÈdzanie racjonalizacjÈ zmiany w systemie rozpoczynają swój żywot od zarejestrowania ich w tej bazie, w for- mie dyskusji towarzyszącej poszczególnym decyzjom. Wspomniana baza stanowi zatem swoiste podsumowanie decyzji, których konsekwencje rozproszone są po modelach systemu. W dwóch pierwszych przypadkach miejscem przechowywania informacji związanej z racjonalizacją są umysły programistów; dwa następne przypadki reprezentują fizyczne umo- cowanie wspomnianej informacji, która tym samym staje się niezależna od umysłu ludzkiego, zawodnego i ograniczonego pod względem ilościowym. Wybór złotego środka między dwiema skrajnościami — brakiem fizycznego reprezentowania racjonalizacji a jej ścisłą integracją z modelami systemu — uzależniony jest od możliwości zainwestowania zasobów w owo repre- zentowanie, we wczesnych etapach realizacji projektu. W tym rozdziale skupimy się wyłącznie na dwóch ostatnich z czterech wymienionych poziomów. Oprócz korzyści długofalowych, jakie daje kolekcjonowanie racjonalizacji, przynosić ono może także korzyści doraźne. Po pierwsze, zmusza do podejmowania decyzji przemyśla- nych, niedyktowanych emocjami — a przynajmniej pozwala odróżnić decyzje starannie prze- myślane od podejmowanych w obliczu presji czy innych „pilnych” okoliczności. Po drugie, pozwala programistom lepiej rozumieć decyzje podejmowane przez kolegów. Modele racjonalizacji, w porównaniu z innymi modelami systemu, zawierają wyraźnie więcej informacji, zmieniającej się w wyraźnie szybszym tempie. Złożoność tej informacji stwarza potrzebę opracowania technik zarządzania nią w sposób sformalizowany. Za chwilę opiszemy reprezentowanie racjonalizacji w formie modeli zagadnień. 12.3. Koncepcje racjonalizacji W tej sekcji opiszemy modelowanie zagadnień, opierające się na założeniu, że aktywności programistów są działaniami dialektycznymi, zmierzającymi do rozwiązywania problemów drogą poszukiwania i ewaluowania różnych ewentualności. Modelując argumenty przema- wiające „za” i „przeciw” wspomnianym ewentualnościom, tworzymy reprezentację racjonali- zacji obejmującą: x zagadnienia reprezentujące problemy projektowe i pytania związane z projektem (patrz sekcja 12.3.2), x ewentualności rozwiązań tych problemów (patrz sekcja 12.3.3), x argumenty „za” poszczególnymi rozwiązaniami i „przeciw” nim (patrz sekcja 12.3.4), x decyzje wyboru konkretnych rozwiązań (patrz sekcja 12.3.5), x implementacje podjętych decyzji w postaci przydziału zadań (patrz sekcja 12.3.6). W sekcji 12.3.7 dokonamy przeglądu wybranych systemów reprezentowania proble- mów — systemów o znaczeniu historycznym. Najpierw jednak przyjrzyjmy się szczegółowo scentralizowanemu systemowi kierowania ruchem kolei miejskiej, który to system stanowić będzie kanwę do budowania rozmaitych przykładów na potrzeby tego rozdziału. 12.3. Koncepcje racjonalizacji 555 12.3.1. CTC — system centralnego sterowania ruchem Scentralizowany system sterowania ruchem (w dalszym ciągu określać go będziemy skrótem CTC, od Centralized Traffic Control) umożliwia zdalne monitorowanie ruchu pociągów i zdalne sterowanie tym ruchem. Każda trasa podzielona jest na tak zwane odcinki izolowane, z któ- rych każdy reprezentuje najmniejszy niepodzielny odcinek monitorowania. Zadaniem sygna- lizatorów i innych urządzeniem jest stworzenie gwarancji, że w danej chwili na każdym ze wspomnianych odcinków znajduje się co najwyżej jeden pociąg. Gdy pociąg wjeżdża na dany odcinek izolowany, specjalne czujniki rejestrują ten fakt i powodują wyświetlenie na monitorze dyspozytora (w odpowiedniej lokalizacji, odpowiadającej danemu odcinkowi) informacji za- wierającej między innymi identyfikator pociągu. Do łączenia odcinków w kompletne trasy służą zwrotnice, zarządzane zdalnie przez dyspozytorów. Zbiór wszystkich odcinków znajdujących się pod kontrolą określonego dyspozytora nazywamy „sekcją dyspozycyjną”. Na rysunku 12.1 przedstawiona jest uproszczona postać interfejsu użytkownika systemu CTC. Odcinki izolowane reprezentowane są przez linie, zwrotnice — przez zbieg trzech lub czterech linii. Sygnały reprezentowane są przez ikony odzwierciedlające dwa stany: „stój” i „droga wolna”. Zwrotnice, pociągi i sygnalizatory opatrzone są unikalnymi identyfikatorami, używa- nymi przez dyspozytora w celu wydawania poleceń. Na rysunku 12.1 widzimy zatem sygnali- zatory S1, S2, S3 i S4, zwrotnice SW1 i SW2 i pociągi T1291 i T1515. Komputery zlokalizowane w pobliżu odcinków, zwane „stacjami przydrożnymi”, stanowią zabezpieczenie gwarantujące, że grupa sygnalizatorów i zwrotnic nigdy nie znajdzie się w stanie zagrażającym bezpieczeń- stwu — czyli na przykład sygnał „droga wolna” nie zostanie wyświetlony równocześnie na sygnalizatorach S1 i S2. Stacje przydrożne zostały tak zaprojektowane, że zapewniają bezpie- czeństwo nawet w przypadku awarii całego systemu, bowiem system ten komunikuje się z sy- gnalizatorami i zwrotnicami wyłącznie za ich pośrednictwem. Sam system nie musi więc być „całkowicie bezpieczny” (failsafe), choć jego ewentualne awarie powinny mieć charakter sporadyczny. Rysunek 12.1. Uproszczony przykład wyświetlanej sekcji dyspozycyjnej CTC W latach 60. ubiegłego wieku pulpity sterownicze systemu CTC miały postać dedyko- wanych urządzeń wyposażonych w żarówki wyświetlające stan poszczególnych odcinków izolowanych oraz przyciski służące do przestawiania zwrotnic i ustawiania sygnalizacji. W la- tach 70. dedykowane pulpity zastąpione zostały monitorami kineskopowymi, umożliwiają- cymi wyświetlanie większej ilości szczegółów na mniejszej powierzchni. Ostatnio monitory 556 Rozdziaï 12. x ZarzÈdzanie racjonalizacjÈ te ustąpiły miejsca stacjom roboczym umożliwiającym tworzenie bardziej wyrafinowanych interfejsów dla dyspozytorów i pozwalającym na rozproszenie przetwarzania między kilka komputerów. Mimo iż system nie jest krytyczny dla życia i zdrowia ludzkiego — nad którego bezpieczeństwem czuwają stacje przydrożne — jednak jego awaria spowodować może chaos komunikacyjny, przekładający się (między innymi) na straty ekonomiczne. W konsekwencji wszelkie transformacje technologiczne CTC — takie jak zastępowanie dedykowanych pulpitów monitorami czy wymiana tych monitorów (połączonych z komputerami mainframe) na stacje robocze — powinny odbywać się bardziej stopniowo niż w innych systemach. Tak oto CTC jawi się jako dziedzina, w której kolekcjonowanie racjonalizacji jest czynnikiem krytycznym — i dlatego właśnie wybraliśmy ją jako przykładową na potrzeby tego rozdziału. 12.3.2. Definiowanie problemów: zagadnienia Zagadnienie to reprezentacja konkretnego problemu, którym może być wymaganie, pro- jekt lub element zarządzania. Jak szybko dyspozytor powinien być informowany o opóźnieniu pociągu? W jaki sposób powinny być przechowywane trwałe dane? Która technologia niesie ze sobą największe ryzyko? Zagadnienia często reprezentują problemy, dla których nie istnieje jedyne poprawne rozwiązanie i które z tego powodu nie mogą być rozwiązywane algorytmicz- nie. Zagadnienia rozwiązywane są zwykle w drodze dyskusji i negocjacji. W języku UML zagadnienia reprezentowane są przez instancje klasy Issue. W klasie tej definiowany jest atrybut subject reprezentujący streszczenie zagadnienia, atrybut description reprezentujący bardziej szczegółowy opis zagadnienia i jego związki z innymi materiałami oraz atrybut status informujący, czy zagadnieniezostało rozwiązane („zamknięte” — closed), czy nie („otwarte” — open). Zagadnienia zamknięte mogą być ponownie otwierane. Zgodnie z konwencją zagadnienia opatrywane są krótkimi nazwami, na przykład train delay?, umoż- liwiającymi ich jednoznaczną identyfikację. Na rysunku 12.2 przedstawiliśmy reprezentację trzech zagadnień sformułowanych w poprzednim akapicie. Rysunek 12.2. Przykłady zagadnień Zagadnienia pojawiające się w związku z realizacją projektu zwykle bywają powiązane, między innymi zagadnienia mogą być dekomponowane na prostsze podzagadnienia. Zagad- nienie Jaki powinien być czas reakcji w systemie sterowania ruchem? automatycznie generuje zagadnienie Jak szybko dyspozytor powinien być informowany o opóźnieniu pociągu? Zresztą, samo tworzenie systemu CTC może być postrzegane jako pojedyncze złożone zagadnienieJaki 12.3. Koncepcje racjonalizacji 557 system kontroli ruchu powinniśmy zbudować?, podlegające dekomponowaniu na znaczną liczbę prostszych podzagadnień. Zagadnienia mogą być także generowane przez decyzje podejmowane w związku z innymi zagadnieniami. Przykładowo zagadnienie dotyczące cache’owania danych w węźle lokalnym generuje natychmiast zagadnienia związane z utrzymywaniem spójności między centralnym egzemplarzem danych a jego replikami w węzłach lokalnych. Takie wtórne zagadnienia nazywamy zagadnieniami wynikowymi (consequent issues). Powróćmy do systemu CTC i wyobraźmy sobie, że rozważamy jego migrację z kom- putera mainframe na sieć stacji roboczych. W nowej wersji systemu każdy dyspozytor będzie korzystał z osobnej stacji roboczej komunikującej się z serwerem, który zapewnia komunikację ze stacjami przydrożnymi. W czasie dyskusji na ten temat wyniknęły dwa zagadnienia: W jaki sposób dyspozytor powinien wydawać polecenia systemowi? oraz W jakiej postaci na ekranie stacji roboczej ma być wyświetlany stan odcinków izolowanych?. Na rysunku 12.3 zagad- nienia te przedstawione są na diagramie obiektów UML. Rysunek 12.3. Zagadnienia związane z interfejsem CTC Zagadnienie powinno koncentrować się wyłącznie na problemie, nie na możliwych ewentualnościach jego rozwiązania (ewentualności te są bowiem przedmiotem propozycji, o których pisać będziemy w następnej sekcji). Konwencją promującą tę regułę jest formuło- wanie zagadnień w formie pytań; aby dodatkowo wyeksponować tę regułę, dołączać będziemy znak zapytania na końcu nazwy zagadnienia. 12.3.3. Eksploracja przestrzeni rozwiÈzañ: propozycje Propozycja jest jedną z odpowiedzi na zagadnienie. Dyspozytor nie musi być informowany o opóźnieniach pociągów to propozycja związana z zagadnieniem Jak szybko powinien być dyspozytor informowany o opóźnieniu pociągu? Propozycja niekoniecznie musi być dobra czy poprawna w kontekście zagadnienia, z którym jest powiązana. Propozycje umożliwiają dogłębne eksplorowanie przestrzeni rozwiązań: często w czasie burzy mózgów nawet bezsen- sowne propozycje stają się źródłem nowych pomysłów, które w innych okolicznościach być może nie miałyby szansy zaistnienia. Różne propozycje związane z tym samym zagadnieniem mogą się zazębiać, tak jak na przykład dla zagadnienia Jak przechowywać trwałe dane? propo- zycje Należy użyć relacyjnej bazy danych oraz Należy użyć relacyjnej bazy danych dla danych strukturalnych i „płaskich” plików dla obrazów i dźwięków. Propozycje służą do reprezentowania zarówno wybranych rozwiązań dla zagadnień, jak i odrzuconych ewentualności rozwiązania. Jedna propozycja może odnosić się do kilku zagadnień, na przykład propozycja Należy wykorzystać architekturę „model-widok-kontroler” może być adresowana do zagadnień Jak odseparować obiekty interfejsu od obiektów encji? oraz Jak zapewnić spójność między wieloma 558 Rozdziaï 12. x ZarzÈdzanie racjonalizacjÈ widokami tego samego obiektu?. Propozycja może stać się także źródłem nowego zagadnienia: propozycja Należy wykorzystywać automatyczne odśmiecanie jako odpowiedź na zagadnienie Jak minimalizować wycieki pamięci? prowadzi natychmiast do zagadnienia Jak minimalizować degradację reaktywności systemu spowodowaną automatycznym zarządzaniem pamięcią?. Rozważając sensowność propozycji w kontekście danego zagadnienia, należy brać pod uwagę także wszystkie jego zagadnienia wynikowe. Na diagramach UML propozycje reprezentowane są jako instancje klasy Proposal. W klasie tej (podobnie jak w klasie Issue) definiowane są atrybuty subject i description. Zgod- nie z konwencją, nazwa propozycji powinna mieć formę krótkiej frazy czasownikowej. Propo- zycje jako obiekty klasy Proposal powiązane są z odnośnymi zagadnieniami, jako obiektami klasy Issue, za pomocą dwojakiego typu skojarzeń: skojarzenie addressed by wskazuje za- gadnienie, dla którego dana propozycja jest odpowiedzią, zaś skojarzenie raises wskazuje jedno lub kilka zagadnień generowanych przez daną propozycję. Powróćmy do CTC. Rozważając zagadnienie związane z interfejsem dyspozytora, ma- my do wyboru dwie propozycje: graficzny interfejs typu „wskaż i kliknij” (point click) oraz interfejs tekstowy (text-based), w ramach którego odcinki izolowane reprezentowane są w postaci znaków semigraficznych. Propozycja interfejsu tekstowego generuje zagadnienie wynikowe dotyczące wyboru konkretnej emulacji terminala. Wzajemne powiązanie tych za- gadnień i propozycji widoczne jest na rysunku 12.4. Rysunek 12.4. Przykład propozycji i zagadnienia wynikowego. Propozycje i zagadnienie wynikowe generowane przez jedną z nich wyróżnione zostały pogrubioną ramką Propozycja powinna zawierać jedynie meritum proponowanego rozwiązania, w oderwa- niu od jego oceny, zalet i wad, te bowiem są domeną innych elementów UML — kryteriów i argumentów. 12.3. Koncepcje racjonalizacji 559 12.3.4. WartoĂciowanie elementów przestrzeni rozwiÈzañ: kryteria i argumenty Kryterium wyraża pożądaną jakość propozycji przynależnej do określonego zagadnienia. Cele projektowe, takie jak na przykład czas reakcji systemu czy jego niezawodność, to kryteria związane z celami projektowymi. Cele menedżerskie, w postaci minimum kosztów i minimum ryzyka, to kryteria związane z zagadnieniami wynikającymi z zarządzania projektem. Zbiór kryteriów wskazuje kierunki oceniania poszczególnych propozycji. Propozycja spełniająca określone kryteriów kwalifikowana jest jako oceniona pozytywnie, propozycja niespełniająca go — jako oceniona negatywnie, w kontekście tegoż kryterium. Dane kryterium może być współdzielone przez wiele zagadnień. Na diagramach UML kryteria reprezentowane są w postaci instancji klasy Criterion. Klasa ta, podobnie jak klasa Issue, posiada atrybuty subject i description. Atrybut subject zawsze wyrażany jest w ukierunkowaniu pozytywnym, to znaczy musi wyrażać kryterium, które poszczególne propozycje powinny maksymalizować — czyli na przykład szybkość, reaktywność, niski koszt, a nie czas czy koszt (pożądanymi cechami są bowiem maksymalna szybkość, maksymalna reaktywność i maksymalnie niski koszt, ale nie maksymalny czas i maksymalny koszt). Kryteria (jako obiekty klasy Criterion) wiązane są z odpowiednimi propozycjami (obiektami klasy Proposal) za pomocą skojarzeń assessment. Skojarzenie posiada atrybut value, wyrażający propozycję w kontekście danego kryterium („spełniająca” — meets — albo „niespełniająca” — fails), oraz atrybut weight, wyrażający znaczenie („wagę”) propozycji w kontekście tegoż kryterium. Zgodnie z konwencją, na końcu nazwy kryterium dołącza się znak dolara ($) dla zaznaczenia, że kryteria stanowią miarę dobroci i nie powinny być mylone z zagadnieniami czy argumentami. W związku z interfejsem dyspozytora CTC formułujemy dwa kryteria: dostępności (availability) jako niefunkcyjne wymagania jak najdłuższej pracy bez awarii i użyteczności (usablility) rozumianej w tym przypadku jako minimalizacja czasu wydawania popraw- nych poleceń (patrz rysunek 12.5). Kryteria te wyprowadzone zostały wprost z niefunkcyj- nych wymagań dla systemu. W kontekście tych kryteriów rozpatrujemy obie propozycje do- tyczące wariantów technologii interfejsu (GUI albo tekstowy), i tak interfejs GUI okazuje się niezgodny z kryterium dostępności, jest bowiem bardziej skomplikowany, a więc trudniejszy do przetestowania i bardziej podatny na błędy; interfejs GUI okazuje się jednak lepszy z per- spektywy kryterium użyteczności, ze względu na wygodniejszą formę wydawania poleceń i wprowadzania danych. Tak oto spotykamy się ze sprzecznością wymagającą kompromisu: każda z propozycji okazuje się maksymalizować jedno kryterium przy minimalizowaniu dru- giego. Należy zatem zdecydować, któremu z kryteriów przypisuje się większą wagę (weight). Argument to opinia wyrażona przez osobę, zgadzającą się lub nie z propozycją, kryte- rium czy oceną. Argumenty są odzwierciedleniem debaty poświęconej poszukiwaniu rozwią- zań; definiują adekwatność miary dobroci, a czasem prowadzą do podejmowania decyzji. Na diagramach UML argumenty reprezentowane są przez instancje klasy Argument, posiadającej atrybuty subject i description. Argumenty powiązane są z encją, której dotyczą, za pomocą skojarzeń is supported lub is opposed, zależnie od tego, czy przemawiają na jej rzecz, czy przeciwko niej. 560 Rozdziaï 12. x ZarzÈdzanie racjonalizacjÈ Rysunek 12.5. Przykład oceny propozycji przez kryteria. Kryteria wyróżnione zostały pogrubioną ramką. Spełnienie kryterium przez propozycję reprezentowane jest przez etykietę meets skojarzenia assesment, niespełnienie — przez etykietę fails Stając wobec wyboru między dostępnością a użytecznością systemu CTC, zauważamy, że korzyści z większej użyteczności systemu mogą być okupione uszczerbkiem na jego do- stępności, co może się przekładać na poważne awarie niwelujące korzyści wynikające z wy- godniejszej i sprawniejszej obsługi systemu — jest to argument przemawiający zarówno na rzecz kryterium dostępności (availability), jak i przeciwko interfejsowi GUI (point click). Relację tę przedstawiliśmy na rysunku 12.6. Definiując kryteria, oceniając propozycje, argumentując „za” i „przeciw”, dokonujemy wartościowania elementów w przestrzeni rozwiązań. Kolejnym krokiem jest wybór jednego z tych rozwiązań w celu rozstrzygnięcia problemu i zamknięcia zagadnienia. 12.3.5. Kolapsacja przestrzeni rozwiÈzañ: rozstrzygniÚcie Rozstrzygnięcie (resolution) reprezentuje ewentualność wybraną jako sposób zamknięcia za- gadnienia. Decyzja rozstrzygnięcia wpływa na jeden z modeli systemu lub model zadań. Roz- strzygnięcie jest wynikiem rozpatrywania wielu propozycji i jednocześnie podsumowaniem ich uzasadnienia. Na diagramach UML rozstrzygnięcia reprezentowane są przez instancje klasy Resolution, definiującej atrybuty subject, description, justification i status. Każde rozstrzygnięcie, jako obiekt klasy Resolution, powiązane jest z odnośnymi propozycjami (jako obiektami klasy Proposal) za pomocą skojarzeń based-on. Jednocześnie każde rozstrzy- gnięcie powiązane jest za pomocą skojarzenia resolves z dokładnie jednym zagadnieniem (jako obiektem klasy Issue), dla którego jest rozwiązaniem. Nieustanne zmiany w projekcie mogą powodować, że rozstrzygnięcie, które aktualnie jest rozwiązaniem pewnego zagadnienia, przestanie nim być, gdy zamknięte (closed) zagad- nienie zostanie ponownie otwarte (open). Z tą okolicznością wiąże się atrybut status klasy Resolution; gdy odnośne zagadnienie jest zamknięte, czyli gdy rozstrzygnięcie pozostaje jego 12.3. Koncepcje racjonalizacji 561 Rysunek 12.6. Przykład argumentu (reprezentujący go obiekt został wyróżniony pogrubioną ramką) rozwiązaniem, atrybut status ma wartość active; w przeciwnym razie ma on wartość obsolete. Z zamkniętym zagadnieniem skojarzone jest dokładnie jedno rozstrzygnięcie o statusie active i dowolna liczba (lub zero) rozstrzygnięć o statusie obsolete. Ostatecznie więc zdecydowaliśmy się na wybór tekstowego interfejsu dla naszego sys- temu CTC. Decyzja taka podyktowana została większym priorytetem kryterium dostępności w stosunku do kryterium użyteczności; w konsekwencji dyspozytor nie będzie mógł oglądać tak dużej ilości danych jednocześnie jak w przypadku interfejsu GUI, a wprowadzanie danych za pomocą klawiatury będzie trwało dłużej i będzie mniej wygodne w porównaniu z klikaniem. W zamian jednak zyskujemy większą pewność funkcjonowania całego systemu. Na diagramie UML (patrz rysunek 12.7) wybrane przez nas rozwiązanie reprezentowane jest jako obiekt klasy Resolution skojarzony z dwoma obiektami klasy Issue. Dodanie rozstrzygnięcia do modelu zagadnień oznacza formalne zakończenie dyskusji nad danym zagadnieniem. Wobec iteratywnego charakteru procesu tworzenia systemu mogą pojawić się potrzeby otwarcia któregoś z zamkniętych zagadnień i ponownego ocenienia od- rzuconych ewentualności. Gdy jednak proces ten zostanie zakończony, większość zagadnień musi być zamknięta, a otwarte powinny być jawnie opisane w dokumentacji w postaci listy znanych problemów. 12.3.6. Implementowanie rozstrzygniÚÊ: elementy dziaïania Rozstrzygnięcie implementowane jest w postaci elementów działania (action items). Element działania to zadanie, do którego przydzielona jest osoba odpowiedzialna i dla którego okre- ślono datę zakończenia. Elementy działania nie są elementami racjonalizacji per se, lecz raczej 562 Rozdziaï 12. x ZarzÈdzanie racjonalizacjÈ Rysunek 12.7. Przykład zamkniętego zagadnienia. Jego rozstrzygnięcie wyróżnione jest pogrubioną ramką częścią modelu zadań (patrz rozdział 14. „Zarządzanie projektem”); mimo to, opisujemy je w tym miejscu, ponieważ są ściśle powiązane z modelami zagadnień. Na diagramach UML elementy działania reprezentowane są jako instancje klasy ActionItem definiującej atrybuty subject, description, owner, deadline i status. Atrybut owner reprezentuje osobę odpowiedzialną za wykonanie zadania związanego z elementem działania, atrybut status może przyjmować cztery wartości reprezentujące stan wspomnianego zadania: todo („do wykonania”), notDoable („niewykonalne”), inProgress („trwające”) i done („wykonane”). Rozstrzygnięcie powiązane jest z odnośnym elementem działania poprzez skojarzenie is implemented by. Na rysunku 12.8 widoczny jest element działania generowany przez rozstrzygnięcie z rysunku 12.7. Zakończyliśmy opis notacji wykorzystywanej do reprezentowania racjonalizacji w po- staci modelu zagadnień i jego integracji z modelem zadań, przyjrzyjmy się więc funkcjo- nującym w praktyce wybranym systemom zarządzania racjonalizacją. 12.3.7. Przykïady modeli zagadnieñ i ich realizacje Kolekcjonowanie racjonalizacji w postaci modeli zagadnień zostało oryginalnie zaproponowane przez W. Kunza i H. Rittela. Od tego czasu opracowano wiele różnych modeli na potrzeby inży- nierii oprogramowania i nie tylko. Opiszemy w skrócie cztery z nich: IBIS (Issue-Based Infor- mation System [Kunz i Rittel, 1970]), DRL (Decision Representation Language [Lee, 1990]), QOC (Questions, Options, and Criteria [MacLean i in., 1991]) i NFR Framework [Chung i in., 1999]. 12.3. Koncepcje racjonalizacji 563 Rysunek 12.8. Przykład implementacji rozstrzygnięcia. Element działania wyróżniony jest pogru- bioną ramką Issue-Based Information System Issue-Based Information System (IBIS) to system dedykowany problemom o złej struk- turze i problemom zagmatwanym, nietypowym (w odróżnieniu od problemów typowych, „oswojonych”): takich problemów nie sposób „ruszyć” w sposób algorytmiczny, można je rozwiązywać jedynie w drodze dyskusji i debat. Model zagadnień systemu IBIS (patrz rysunek 12.9) tworzony jest przez trzy klasy wę- złów: Issue, Position i Argument kojarzonych ze sobą za pomocą siedmiu różnych klas skoja- rzeń: supports („wspiera”), objects-to („sprzeciwia się”), replaces („zastępuje”), responds-to („odpowiada”), generalizes („uogólnia”), questions („kwestionuje”) i suggests („sugeruje”). Węzeł klasy Issue reprezentuje problem projektowy. Propozycje jego rozwiązywania repre- zentowane są przez węzły klasy Position (podobnej do klasy Proposal opisywanej w sekcji 12.3.3). Węzły klasy Argument reprezentują wartościowanie przez programistów poszczegól- nych propozycji i powiązane są z węzłami klasy Position za pomocą skojarzeń supports („wspiera”) i objects-to („sprzeciwia się”). Dany argument (Argument) może być powiązany z kilkoma propozycjami. Oryginalny model systemu IBIS nie zawiera węzłów reprezentujących kryteria i roz- strzygnięcia. Rysunek 12.9. Model systemu IBIS 564 Rozdziaï 12. x ZarzÈdzanie racjonalizacjÈ IBIS wspierany jest przez narzędzie hipertekstowe o nazwie gIBIS, opisane przez J. Con- klina i K. C. Burgessa-Yakemovica [Conklin i Burgess-Yakemovic, 1991], i wykorzystywany do kolekcjonowania racjonalizacji w trakcie spotkań osobistych. Stanowi jednocześnie bazę dla większości późniejszych rozwiązań bazujących na modelach zagadnień, między innymi DRL i QOC. Decision Representation Language System Decision Representation Language (DRL) pomyślany został jako narzędzie wspomagające kolekcjonowanie racjonalizacji projektowania, rozumianej jako reprezentacja jakościowych elementów podejmowania decyzji — rozpatrywanych ewentualności rozwiąza- nia, ich ocen i kształtujących te oceny argumentów oraz kryteriów oceniania. DRL wspierany jest przez narzędzie o nazwie SYBIL, umożliwiające użytkownikowi śledzenie zależności mię- dzy elementami racjonalizacji w sytuacji ponownej ewaluacji poszczególnych ewentualności rozwiązań. DRL stanowi rozwinięcie systemu IBIS, przez wzbogacenie modelu o dwie klasy węzłów reprezentujące cele projektowe (Goal) i procedury (Procedure). Z perspektywy DRL konstruowanie racjonalizacji związanej z artefaktem jest zadaniem porównywalnym z two- rzeniem samego artefaktu. Podstawową wadą DRL jest jego złożoność — siedem klas węzłów i piętnaście klas skojarzeń, co widać na rysunku 12.10 — oraz dodatkowy wysiłek konieczny dla nadania racjonalizacji odpowiedniej struktury. Rysunek 12.10. Model systemu DRL Questions, Options, and Criteria Innym efektem rozszerzenia systemu IBIS jest system o nazwie Questions, Options, and Criteria (QOC) („pytania, opcje i kryteria”). Węzły klasy Question („pytania”) składają się na reprezentację rozwiązywanego problemu. Propozycje jego rozwiązań reprezentowane są przez „opcje”, czyli węzły klasy Option (odpowiadającej klasie Proposal opisywanej w sekcji 12.3.3). 12.3. Koncepcje racjonalizacji 565 Opcje mogą generować kolejne pytania; są też oceniane (dodatnio lub ujemnie) według kryte- riów (Criteria) stanowiących relatywną miarę dobroci definiowaną przez programistów. Argumenty (Argument) mogą wspierać lub kwestionować pytania, opcje i kryteria oraz skoja- rzenia między nimi. Model systemu QOC przeds
Pobierz darmowy fragment (pdf)

Gdzie kupić całą publikację:

Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce projektowe i Java
Autor:
,

Opinie na temat publikacji:


Inne popularne pozycje z tej kategorii:


Czytaj również:


Prowadzisz stronę lub blog? Wstaw link do fragmentu tej książki i współpracuj z Cyfroteką: