Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce...

Idź do

• Spis treści• Przykładowy rozdział• Skorowidz

• Katalog online

• Dodaj do koszyka

• Zamów cennik

• Zamów informacjeo nowościach

• Fragmenty książekonline

Helion SAul. Kościuszki 1c44-100 Gliwicetel. 32 230 98 63e-mail: [email protected]© Helion 1991–2011

Katalog książek

Twój koszyk

Cennik i informacje

Czytelnia

Kontakt

• Zamów drukowanykatalog

Inżynieria oprogramowaniaw ujęciu obiektowym. UML,wzorce projektowe i JavaAutorzy: 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!

http://helion.pl

http://helion.pl/zamow_katalog.htm

http://helion.pl/katalog.htm

http://helion.pl/zakupy/add.cgi?id=iowuje

http://helion.pl/emaile.cgi

http://helion.pl/cennik.htm

http://helion.pl/online.htm

mailto:[email protected]

http://helion.pl/ksiazki/iowuje.htm

http://www.amazon.com/exec/obidos/ASIN/0136061257/helion-20

http://www.amazon.com/exec/obidos/ASIN/0136061257/helion-20

Przedmowa 17

Wstęp 19

Podziękowania 31

CZĘŚĆ I Zaczynamy 33

Rozdział 1. Wprowadzenie do inżynierii oprogramowania 351.1. Wprowadzenie: niepowodzenia w inżynierii oprogramowania 361.2. Czym jest inżynieria oprogramowania? 38

1.2.1. Modelowanie 381.2.2. Rozwiązywanie problemów 401.2.3. Pozyskiwanie wiedzy 411.2.4. Racjonalizacja 42

1.3. Podstawowe koncepcje inżynierii oprogramowania 431.3.1. Uczestnicy i role 441.3.2. Systemy i modele 461.3.3. Produkty 461.3.4. Aktywności, zadania i zasoby 471.3.5. Wymagania funkcyjne i pozafunkcyjne 481.3.6. Notacje, metody i metodologie 48

1.4. Aktywności inżynierii oprogramowania 491.4.1. Zbieranie wymagań 501.4.2. Analiza 511.4.3. Projekt systemu 511.4.4. Projektowanie obiektów 531.4.5. Implementowanie 531.4.6. Testowanie 54

1.5. Zarządzanie tworzeniem oprogramowania 541.5.1. Komunikacja 551.5.2. Zarządzanie racjonalizacją 551.5.3. Zarządzanie konfiguracją oprogramowania 561.5.4. Zarządzanie projektem 561.5.5. Cykl życiowy oprogramowania 561.5.6. Podsumowanie 57

Spis treści

6 Spis tre�ci

1.6. Analiza przypadku — system ARENA 571.7. Literatura uzupełniająca 581.8. Ćwiczenia 59

Rozdział 2. Modelowanie w języku UML 632.1. Wprowadzenie 642.2. Ogólnie o UML 65

2.2.1. Diagramy przypadków użycia 652.2.2. Diagramy klas 652.2.3. Diagramy interakcji 672.2.4. Diagram stanów 672.2.5. Diagramy aktywności 68

2.3. Podstawowe koncepcje modelowania 692.3.1. Systemy, modele i widoki 692.3.2. Typy danych, abstrakcyjne typy danych i instancje 722.3.3. Klasy, klasy abstrakcyjne i obiekty 732.3.4. Klasy zdarzeniowe, zdarzenia i komunikaty 752.3.5. Modelowanie zorientowane obiektowo 762.3.6. Falsyfikacja i prototypowanie 77

2.4. UML — głębszy wgląd 782.4.1. Diagramy przypadków użycia 792.4.2. Diagramy klas 862.4.3. Diagramy interakcji 952.4.4. Diagramy stanów 982.4.5. Diagramy aktywności 1012.4.6. Organizacja diagramów 1042.4.7. Rozszerzenia diagramów 106

2.5. Literatura uzupełniająca 1072.6. Ćwiczenia 108

Rozdział 3. Organizacja projektu i komunikacja 1133.1. Wstęp — katastrofa Ariane 1143.2. O projekcie ogólnie 1153.3. Koncepcje organizacyjne projektu 119

3.3.1. Organizacja projektów 1193.3.2. Role w realizacji projektu 1223.3.3. Zadania i produkty 1243.3.4. Harmonogramy 126

3.4. Koncepcje komunikacyjne projektu 1283.4.1. Komunikacja planowa 1283.4.2. Komunikacja pozaplanowa 1353.4.3. Mechanizmy komunikacyjne 138

3.5. Aktywności organizacyjne 1463.5.1. Dołączanie do zespołu 1463.5.2. Dołączanie do infrastruktury komunikacyjnej 146

Spis tre�ci 7

3.5.3. Udział w zebraniach zespołu 1473.5.4. Organizacja przeglądów 149


CZĘŚĆ II Zmagania ze złożonością 155

Rozdział 4. Zbieranie wymagań 1574.1. Wstęp: przykłady problemów z użytecznością 1584.2. O zbieraniu wymagań ogólnie 1594.3. Koncepcje zbierania wymagań 161

4.3.1. Wymagania funkcyjne 1614.3.2. Wymagania pozafunkcyjne 1624.3.3. Kompletność, spójność, jednoznaczność i poprawność 1644.3.4. Realizm, weryfikowalność i identyfikowalność 1654.3.5. Inżynieria pierwotna, inżynieria wtórna

i inżynieria interfejsu 1654.4. Aktywności związane ze zbieraniem wymagań 166

4.4.1. Identyfikacja aktorów 1674.4.2. Identyfikacja scenariuszy 1694.4.3. Identyfikacja przypadków użycia 1714.4.4. Doskonalenie przypadków użycia 1734.4.5. Identyfikacja relacji między aktorami

a przypadkami użycia 1764.4.6. Początkowa identyfikacja obiektów

modelu analitycznego 1794.4.7. Identyfikacja wymagań pozafunkcyjnych 182

4.5. Zarządzanie zbieraniem wymagań 1834.5.1. Negocjowanie specyfikacji z klientem:

metoda Joint Application Design 1854.5.2. Zarządzanie identyfikowalnością 1874.5.3. Dokumentowanie zbierania wymagań 188

4.6. Analiza przypadku — system ARENA 1904.6.1. Wstępna deklaracja problemu 1904.6.2. Identyfikacja aktorów i scenariuszy 1924.6.3. Identyfikacja przypadków użycia 1954.6.4. Doskonalenie przypadków użycia

i identyfikacja relacji 1984.6.5. Identyfikacja wymagań pozafunkcyjnych 2044.6.6. Wnioski 204


8 Spis tre�ci

Rozdział 5. Analiza wymagań 2115.1. Wstęp: złudzenie optyczne 2125.2. O analizie wymagań ogólnie 2125.3. Koncepcje analizy wymagań 214

5.3.1. Analityczny model obiektowy i modele dynamiczne 2145.3.2. Obiekty encji, obiekty brzegowe i obiekty sterujące 2155.3.3. Generalizacja i specjalizacja 216

5.4. Aktywności analizy wymagań:od przypadków użycia do obiektów 2175.4.1. Identyfikacja obiektów encji 2185.4.2. Identyfikacja obiektów brzegowych 2205.4.3. Identyfikacja obiektów sterujących 2225.4.4. Odwzorowywanie przypadków użycia w obiekty

za pomocą diagramów sekwencji 2245.4.5. Modelowanie interakcji między obiektami

za pomocą kart CRC 2285.4.6. Identyfikacja skojarzeń 2285.4.7. Identyfikacja agregacji 2315.4.8. Identyfikacja atrybutów 2325.4.9. Modelowanie zachowania poszczególnych obiektów

uzależnionego od ich stanu 2335.4.10. Modelowanie relacji dziedziczenia między obiektami 2345.4.11. Przeglądy modelu analitycznego 2355.4.12. Podsumowanie analizy 236

5.5. Zarządzanie analizą wymagań 2375.5.1. Dokumentowanie analizy wymagań 2385.5.2. Przydzielanie odpowiedzialności 2395.5.3. Komunikacja w związku z analizą wymagań 2405.5.4. Iteracje modelu analitycznego 2415.5.5. Uzgodnienie modelu analitycznego z klientem 243

5.6. Analiza przypadku — system ARENA 2455.6.1. Identyfikacja obiektów encji 2455.6.2. Identyfikacja obiektów brzegowych 2505.6.3. Identyfikacja obiektów sterujących 2515.6.4. Modelowanie interakcji między obiektami 2525.6.5. Weryfikacja i konsolidacja modelu analitycznego 2545.6.6. Wnioski 256


Rozdział 6. Projektowanie systemu — dekompozycja na podsystemy 2636.1. Wstęp: projekt mieszkania 2646.2. O projektowaniu systemu ogólnie 2666.3. Koncepcje projektowania systemu 267

Spis tre�ci 9

6.3.1. Podsystemy i klasy 2686.3.2. Usługi i interfejsy podsystemów 2706.3.3. Sprzężenie i spoistość 2716.3.4. Warstwy i partycje 2756.3.5. Style architektoniczne 279

6.4. Aktywności projektowania systemu:od obiektów do podsystemów 2886.4.1. Punkt wyjścia: model analityczny systemu

planowania podróży 2886.4.2. Identyfikowanie celów projektowych 2906.4.3. Identyfikowanie podsystemów 294


Rozdział 7. Projekt systemu: realizacja celów projektowych 3017.1. Wstęp: przykład redundancji 3027.2. O aktywnościach projektowania systemu ogólnie 3037.3. Koncepcje: diagramy wdrażania UML 3047.4. Aktywności realizacji celów projektowych 306

7.4.1. Odwzorowywanie podsystemóww procesory i komponenty 306

7.4.2. Identyfikowanie trwałych danych i ich przechowywanie 3097.4.3. Definiowanie założeń kontroli dostępu 3127.4.4. Projektowanie globalnego przepływu sterowania 3197.4.5. Identyfikowanie usług 3217.4.6. Identyfikowanie warunków granicznych 3237.4.7. Weryfikowanie projektu systemu 326

7.5. Zarządzanie projektowaniem systemu 3287.5.1. Dokumentowanie projektu systemu 3287.5.2. Przydzielanie odpowiedzialności 3307.5.3. Komunikacja w projektowaniu systemu 3317.5.4. Iteracje projektowania systemu 333

7.6. Analiza przypadku — system ARENA 3347.6.1. Identyfikowanie celów projektowych 3357.6.2. Identyfikowanie podsystemów 3367.6.3. Odwzorowanie podsystemów w procesory

i komponenty 3377.6.4. Identyfikowanie i przechowywanie trwałych danych 3397.6.5. Definiowanie założeń kontroli dostępu 3407.6.6. Projektowanie globalnego przepływu sterowania 3417.6.7. Identyfikowanie usług 3437.6.8. Identyfikowanie warunków granicznych 3457.6.9. Wnioski 347


10 Spis tre�ci

Rozdział 8. Projektowanie obiektów:wielokrotne wykorzystywanie rozwiązań wzorcowych 3538.1. Wstęp: wpadki produkcyjne 3548.2. O projektowaniu obiektów ogólnie 3558.3. Koncepcja wielokrotnego wykorzystywania

— dziedziczenie, delegowanie i wzorce projektowe 3598.3.1. Obiekty aplikacyjne i obiekty realizacyjne 3598.3.2. Dziedziczenie implementacyjne

i dziedziczenie specyfikacyjne 3608.3.3. Delegowanie 3638.3.4. Zasada zastępowania Liskov 3648.3.5. Delegowanie i dziedziczenie

we wzorcach projektowych 3648.4. Wybór wzorców projektowych i gotowych komponentów 367

8.4.1. Hermetyzacja przechowywania danychza pomocą wzorca projektowego Most 368

8.4.2. Hermetyzacja niekompatybilnych komponentówza pomocą wzorca projektowego Adapter 371

8.4.3. Hermetyzacja kontekstu za pomocąwzorca projektowego Strategia 373

8.4.4. Hermetyzacja platformy za pomocąwzorca projektowego Fabryka abstrakcyjna 376

8.4.5. Hermetyzacja przepływu sterowania za pomocąwzorca projektowego Polecenie 377

8.4.6. Hermetyzacja hierarchii za pomocąwzorca projektowego Kompozyt 378

8.4.7. Heurystyki wyboru wzorców projektowych 3798.4.8. Identyfikowanie i przystosowywanie

frameworków aplikacyjnych 3818.5. Zarządzanie wykorzystywaniem gotowych rozwiązań 386

8.5.1. Dokumentowanie wykorzystywaniagotowych rozwiązań 388

8.5.2. Przydzielanie odpowiedzialności 3898.6. Analiza przypadku — system ARENA 390

8.6.1. Zastosowanie wzorca projektowegoFabryka abstrakcyjna 390

8.6.2. Zastosowanie wzorca projektowego Polecenie 3928.6.3. Zastosowanie wzorca projektowego Obserwator 3938.6.4. Wnioski 393


Spis tre�ci 11

Rozdział 9. Projektowanie obiektów: specyfikowanie interfejsów 3999.1. Wstęp: kolej miejska i tramwaje 4009.2. O specyfikowaniu interfejsów ogólnie 4019.3. Koncepcje specyfikowania interfejsów 403

9.3.1. Implementator, ekstender i użytkownik klasy 4039.3.2. Typy, sygnatury i widzialność 4039.3.3. Kontrakty: niezmienniki, warunki wstępne

i warunki końcowe 4069.3.4. Język OCL (Object Constraint Language) 4079.3.5. Kolekcje OCL: zbiory, wielozbiory i ciągi 4119.3.6. Kwantyfikatory OCL: forAll() i exists() 415

9.4. Aktywności specyfikowania interfejsów 4169.4.1. Identyfikowanie brakujących atrybutów i operacji 4179.4.2. Specyfikowanie typów, sygnatur i widzialności 4189.4.3. Specyfikowanie warunków wstępnych

i warunków końcowych 4199.4.4. Specyfikowanie niezmienników 4219.4.5. Dziedziczenie kontraktów 424

9.5. Zarządzanie projektowaniem obiektów 4259.5.1. Dokumentowanie projektowania obiektów 4259.5.2. Przydzielanie odpowiedzialności 4319.5.3. Wykorzystywanie kontraktów w analizie wymagań 432

9.6. Analiza przypadku — system ARENA 4339.6.1. Identyfikowanie brakujących operacji

w klasach TournamentStyle i Round 4349.6.2. Specyfikowanie kontraktów dla klas

TournamentStyle i Round 4359.6.3. Specyfikowanie kontraktów dla klas KnockOutStyle

i KnockOutRound 4389.6.4. Wnioski 439


Rozdział 10. Odwzorowywanie modelu na kod 44510.1. Wstęp: Władca Pierścieni 44610.2. O odwzorowywaniu ogólnie 44710.3. Koncepcje odwzorowywania 448

10.3.1. Transformowanie modelu 44910.3.2. Refaktoryzacja 45010.3.3. Inżynieria postępująca 45210.3.4. Inżynieria odwracająca 45210.3.5. Zasady transformacji 453

10.4. Aktywności odwzorowywania 45410.4.1. Optymalizowanie modelu obiektowego 45510.4.2. Odwzorowywanie skojarzeń na kolekcje 458

12 Spis tre�ci

10.4.3. Odwzorowywanie kontraktów w wyjątki 46510.4.4. Odwzorowywanie modelu obiektowego

w schematy bazy danych 46910.5. Zarządzanie transformacjami 475

10.5.1. Dokumentowanie transformacji 47510.5.2. Przydzielanie odpowiedzialności 477

10.6. Analiza przypadku — system ARENA 47810.6.1. Statystyki systemu ARENA 47810.6.2. Odwzorowywanie skojarzeń na kolekcje 48010.6.3. Odwzorowywanie kontraktów w wyjątki 48210.6.4. Odwzorowywanie modelu obiektowego

w schemat bazy danych 48410.6.5. Wnioski 485


Rozdział 11. Testowanie 49111.1. Wstęp: testowanie wahadłowców 49211.2. O testowaniu ogólnie 49411.3. Koncepcje związane z testowaniem 498

11.3.1. Usterki, błędne stany i awarie 50011.3.2. Przypadki testowe 50311.3.3. Namiastki testowe i sterowniki testowe 50511.3.4. Poprawki 505

11.4. Aktywności związane z testowaniem 50611.4.1. Inspekcja komponentu 50711.4.2. Testowanie użyteczności 50811.4.3. Testowanie jednostkowe 51011.4.4. Testowanie integracyjne 51911.4.5. Testowanie systemu 526

11.5. Zarządzanie testowaniem 53111.5.1. Planowanie testów 53211.5.2. Dokumentowanie testowania 53211.5.3. Przydzielanie odpowiedzialności 53611.5.4. Testowanie regresyjne 53711.5.5. Automatyzacja testowania 53811.5.6. Testowanie bazujące na modelach 539


CZĘŚĆ III Zarządzanie zmianami 547

Rozdział 12. Zarządzanie racjonalizacją 54912.1. Wstęp: przycinanie wędzonej szynki 55012.2. O racjonalizacji ogólnie 551

Spis tre�ci 13

12.3. Koncepcje racjonalizacji 55412.3.1. CTC — system centralnego sterowania ruchem 55512.3.2. Definiowanie problemów: zagadnienia 55612.3.3. Eksploracja przestrzeni rozwiązań: propozycje 55712.3.4. Wartościowanie elementów przestrzeni rozwiązań:

kryteria i argumenty 55912.3.5. Kolapsacja przestrzeni rozwiązań: rozstrzygnięcie 56012.3.6. Implementowanie rozstrzygnięć: elementy działania 56112.3.7. Przykłady modeli zagadnień i ich realizacje 562

12.4. Aktywności racjonalizacji — od zagadnień do decyzji 56712.4.1. Projekt systemu CTC 56812.4.2. Kolekcjonowanie racjonalizacji w ramach zebrań 56912.4.3. Asynchroniczne kolekcjonowanie racjonalizacji 57712.4.4. Racjonalizacja dyskutowanych zmian 57912.4.5. Rekonstruowanie racjonalizacji 582

12.5. Kierownicze aspekty zarządzania racjonalizacją 58512.5.1. Dokumentowanie racjonalizacji 58512.5.2. Przypisywanie odpowiedzialności 58712.5.3. Heurystyki komunikowania racjonalizacji 58812.5.4. Modelowanie i negocjowanie zagadnień 58912.5.5. Strategie rozwiązywania konfliktów 590


Rozdział 13. Zarządzanie konfiguracją 59713.1. Wstęp: samoloty 59813.2. O zarządzaniu konfiguracją ogólnie 60013.3. Koncepcje zarządzania konfiguracją 602

13.3.1. Elementy konfiguracji i agregaty CM 60313.3.2. Wersje i konfiguracje 60413.3.3. Żądania zmian 60413.3.4. Promocje i emisje 60513.3.5. Repozytoria i przestrzenie robocze 60613.3.6. Schematy identyfikowania wersji 60613.3.7. Zmiany i zbiory zmian 60813.3.8. Narzędzia wspomagające zarządzanie konfiguracją 610

13.4. Aktywności tworzące zarządzanie konfiguracją 61113.4.1. Identyfikowanie elementów konfiguracji

i agregatów CM 61313.4.2. Zarządzanie promocjami 61513.4.3. Zarządzanie emisjami 61613.4.4. Zarządzanie gałęziami 61913.4.5. Zarządzanie wariantami 62313.4.6. Zarządzanie propozycjami zmian

i ich implementowaniem 626

14 Spis tre�ci

13.5. Kierownicze aspekty zarządzania konfiguracją 62713.5.1. Dokumentowanie zarządzania konfiguracją 62713.5.2. Przypisywanie odpowiedzialności 62813.5.3. Planowanie aktywności

w ramach zarządzania konfiguracją 62913.5.4. Integracja ciągła jako optymalizacja

zarządzania promocjami i ich testowaniem 63013.6. Literatura uzupełniająca 63213.7. Ćwiczenia 633

Rozdział 14. Zarządzanie projektem 63714.1. Wstęp: uruchomienie misji STS-51L 63814.2. O zarządzaniu projektem ogólnie 63914.3. Koncepcje zarządzania projektem 646

14.3.1. Zadania i aktywności 64614.3.2. Produkty, pakiety pracy i role 64614.3.3. Struktura podziału pracy 64814.3.4. Model zadań 64914.3.5. Macierz kwalifikacji 65014.3.6. Plan zarządzania projektem 651

14.4. Aktywności klasycznego zarządzania projektem 65314.4.1. Planowanie projektu 65414.4.2. Organizowanie projektu 65914.4.3. Kontrolowanie projektu 66514.4.4. Kończenie projektu 671

14.5. Aktywności „zwinnej” realizacji projektu 67314.5.1. Planowanie projektu:

wykazy zaległości produktu i przebiegu 67414.5.2. Organizowanie projektu 67514.5.3. Kontrolowanie projektu:

dni robocze i wykresy wygaszania 67514.5.4. Kończenie projektu: przeglądy przebiegów 677


Rozdział 15. Cykl życiowy oprogramowania 68315.1. Wstęp: nawigacja polinezyjska 68415.2. IEEE 1074: standard cykli życiowych 688

15.2.1. Procesy i aktywności 68815.2.2. Modelowanie cyklu życiowego 69015.2.3. Zarządzanie projektem 69015.2.4. Prerealizacja 69115.2.5. Realizacja — tworzenie systemu 69215.2.6. Postrealizacja 69315.2.7. Procesy integralne (międzyrealizacyjne) 694

Spis tre�ci 15

15.3. Charakteryzowanie dojrzałości modeli cyklu życiowego 69515.4. Modele cyklu życiowego 698

15.4.1. Sekwencyjne modele ukierunkowane na aktywności 69915.4.2. Iteracyjne modele ukierunkowane na aktywności 70115.4.3. Modele ukierunkowane na encje 706


Rozdział 16. Wszystko razem, czyli metodologie 71316.1. Wstęp: pierwsze zdobycie K2 71416.2. Środowisko projektu 71716.3. Zagadnienia metodologiczne 719

16.3.1. Ile planowania? 71916.3.2. Ile powtarzalności? 72016.3.3. Ile modelowania? 72116.3.4. Ile procesów cyklu życiowego? 72316.3.5. Ile kontroli i monitorowania? 72316.3.6. Kiedy przedefiniować cele projektu? 724

16.4. Spektrum metodologii 72416.4.1. Metodologia Royce’a 72516.4.2. Programowanie ekstremalne (XP) 73116.4.3. Metodologie rugby 737

16.5. Analizy przypadku 74216.5.1. Projekt XP: ATRACT 74316.5.2. Lokalny klient: FRIEND 74616.5.3. Rozproszony projekt: JAMES 75416.5.4. Podsumowanie analiz przypadku 761


Dodatki 769

Dodatek A Wzorce projektowe 771A.1. Fabryka abstrakcyjna (Abstract Factory)

— hermetyzacja platformy 772A.2. Adapter (Adapter) — otoczka dla starszego kodu 773A.3. Most (Bridge) — podmiana implementacji 774A.4. Polecenie (Command) — hermetyzacja przepływu sterowania 775A.5. Kompozyt (Composite) — rekurencyjna reprezentacja hierarchii 776A.6. Fasada (Facade) — hermetyzacja podsystemów 777A.7. Obserwator (Observer) — oddzielenie encji od widoków 778A.8. Proxy (Proxy) — hermetyzacja kosztownych obiektów 779A.9. Strategia (Strategy) — hermetyzacja algorytmów 780A.10. Heurystyki pomocne w wyborze wzorców projektowych 781

16 Spis tre�ci

Dodatek B Objaśnienia haseł 783B.1. Terminologia 783B.2. Słownik terminów angielskich 817

Dodatek C Bibliografia 831

Skorowidz 847

12.1. Wst�p: przycinanie w�dzonej szynki 549

Zarządzanie racjonalizacjąMożna opisywać motocykl w kategoriach „co?” i „jak”, czyli w kategoriachkomponentów, z których się składa, oraz zasad, według którychkomponenty te funkcjonują; oglądając ilustrację motocykla, możnasię jednak tylko domyślać tych wszystkich „gdzie?” i „dlaczego?”decydujących o takim, a nie innym kształcie poszczególnych częścii ich wzajemnym rozmieszczeniu.

— Robert Pirsig Zen i sztuka oporządzania motocykla

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, dlaktó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ę:

� problemy wymagające rozwiązywania,� możliwe ewentualności rozwiązań tych problemów,� decyzje podejmowane w związku z rozwiązywaniem problemów,� kryteria uwzględniane przy podejmowaniu decyzji,� 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 kolekcjonowaniewiedzy, 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ę zewspomnianymi decyzjami, studiując dokumenty racjonalizacji systemu.

Niestety, racjonalizacja należy do najbardziej złożonych kategorii informacji zarównow 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.

W

12

550 Rozdzia� 12. � 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żerskichzwiązanych z racjonalizacją, takich jak wspomaganie podejmowania decyzji i negocjowanie.

12.1. Wst�p: przycinanie w�dzonej szynkiModele 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śmyw rozdziałach 4. „Zbieranie wymagań” i 5. „Analiza wymagań”) — reprezentują zachowaniesystemu 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, przechowywaniadanych, kontroli dostępu i tak dalej. Model racjonalizacji systemu reprezentuje natomiastcałokształt decyzji, przesłanek, powodów i tym podobnych, decydujących o tym, dlaczegosystem 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łataki 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 przedwędzeniem, a już sugestia, jakoby takie przycinanie miało poprawiać smak szynki, jest kompletnymabsurdem dla kogoś, kto ma choć blade pojęcie na temat kulinariów. Po chwili Zoe przypomniałasobie 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 skracaniaszynki poszła w zapomnienie.

Programiści i kucharze uwielbiają rozpowszechniać rozmaite pomysły, sposoby, technikii tym podobne, którym jednak nie towarzyszy wystarczająca racjonalizacja, która mogłabyzwiększyć ich przydatność w konkretnym zastosowaniu. Wszyscy znamy tak zwany problemroku 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 takichtechnik 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 oprogramowaniaprzyjmowano (jako pewnik) założenie, że w roku 2000 pozostanie już po nim co najwyżejwspomnienie. 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, urodzonyw 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 lokalnegocentrum 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 desiècle, skrępowani byli jednocześnie względami kompatybilności wstecz z eksploatowanymoprogramowaniem — 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ściwierozumieć 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 tymrozdziale opiszemy techniki kolekcjonowania, pielęgnowania i wykorzystywania modeli ra-cjonalizacji, w szczególności:

� ogólny pogląd na modelowanie racjonalizacji (patrz sekcja 12.2),� koncepcje związane z modelami racjonalizacji (patrz sekcja 12.3),� aktywności związane z tworzeniem i wykorzystywaniem modeli racjonalizacji (patrz

sekcja 12.4),� 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ólnieRacjonalizacja decyzji to zespół motywacji kryjących się za jej podjęciem. Na racjonalizacjętę składają się:

� Zagadnienie (issue). Każda decyzja związana jest z rozwiązywaniem konkretnegoproblemu. 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?”.

� Ewentualności (alternatives). Ewentualnościami nazywamy możliwe sposoby roz-wiązania danego problemu, w tym również sposoby, które nie zostały zastosowaneze względu na niespełnienie jednego lub więcej określonych kryteriów. Przykładowoduży piec wędzarniczy może być zbyt drogi, a przechowywanie liczb oznaczającychlata w postaci dwubajtowych słów zamiast bajtów może spowolnić szybkość obliczeńi zwiększyć ilość wymaganej pamięci.


� 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ścidecydujący się pół wieku temu na dwucyfrowy zapis roku dążyli do oszczędnościpamię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 przezużytkownika wprowadzającego dane wejściowe. Na etapie projektowania systemukryteria te wyrażają cele projektowe w postaci niezawodności, czasu reakcji i tympodobnych. Z perspektywy menedżera projektu kryteria te wyrażają jego specy-ficzne cele oraz kompromisy, które musi rozstrzygać — na przykład kompromismiędzy jakością systemu a terminem jego dostarczenia.

� Argumentacja (arguments). Zarówno sztuka kulinarna, jak i inżynieria oprogra-mowania nie są dyscyplinami algorytmicznymi, bowiem kucharze i programiścinapotykają 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.

� 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 modeluprojektu systemu jest niczym innym, jak skumulowanym efektem ciągu podjętychdecyzji. 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śmydo podejmowania licznych decyzji, wspomaganych modelami racjonalizacji, i tak:

� W czasie zbierania wymagań i ich analizy decydujemy o kształcie funkcjonalnymsystemu, przy wydatnej współpracy z klientem. Podejmowane decyzje motywowanesą przez użytkownika lub przez potrzeby organizacyjne. Uzasadnienie tych decyzjistaje się użyteczne przy tworzeniu przypadków testowych na potrzeby testów inte-gracyjnych i testów akceptacyjnych.

� W czasie projektowania systemu formułujemy cele projektowe i determinujemy kształtdekompozycji systemu na podsystemy. Decyzje związane z celami projektowymiwynikają 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.

� Zarządzanie projektem wiąże się z przyjmowaniem wielu różnych założeń związanychz relatywnym ryzykiem projektowym — i tak na przykład komponenty utworzonestosunkowo 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 ryzykownychdecyzji i opracowywanie „planów odwrotu” umożliwi złagodzenie ewentualnych pro-blemów, które wynikać mogą z tego ryzyka.

� W czasie testowania i integrowania podsystemów wykrywamy niezgodności międzyich interfejsami. Na podstawie racjonalizacji kryjącej się za konkretnym kształtemtych interfejsów możemy łatwo zidentyfikować założenie, którego niespełnienieokazał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 tenbędzie z pewnością doznawał wielu zmian w dłuższej perspektywie; klient, który jest świadomtego 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ć jegodemonstrację, 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:

� brak wyraźnego kolekcjonowania — informacja związana z racjonalizacją ma jedynieformę 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.

� 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 modelamisystemu. Odrzucone ewentualności oraz argumenty „za” i „przeciw” nie zostają jawnieudokumentowane.

� 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ł prezentujezagadnienie, 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.

� zintegrowanie racjonalizacji z modelami systemu sprawia, że staje się ona central-nym modelem systemu. Pojawiające się sukcesywnie nowe elementy racjonalizacjizapisywane są w „żywej”, przeszukiwalnej, informacyjnej bazie danych. Wszelkie


zmiany w systemie rozpoczynają swój żywot od zarejestrowania ich w tej bazie, w for-mie dyskusji towarzyszącej poszczególnym decyzjom. Wspomniana baza stanowizatem swoiste podsumowanie decyzji, których konsekwencje rozproszone są pomodelach systemu.

W dwóch pierwszych przypadkach miejscem przechowywania informacji związanejz 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 dwiemaskrajnoś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łączniena 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źniewięcej informacji, zmieniającej się w wyraźnie szybszym tempie. Złożoność tej informacjistwarza potrzebę opracowania technik zarządzania nią w sposób sformalizowany. Za chwilęopiszemy reprezentowanie racjonalizacji w formie modeli zagadnień.

12.3. Koncepcje racjonalizacjiW tej sekcji opiszemy modelowanie zagadnień, opierające się na założeniu, że aktywnościprogramistów są działaniami dialektycznymi, zmierzającymi do rozwiązywania problemówdrogą 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ą:

� zagadnienia reprezentujące problemy projektowe i pytania związane z projektem(patrz sekcja 12.3.2),

� ewentualności rozwiązań tych problemów (patrz sekcja 12.3.3),� argumenty „za” poszczególnymi rozwiązaniami i „przeciw” nim (patrz sekcja 12.3.4),� decyzje wyboru konkretnych rozwiązań (patrz sekcja 12.3.5),� 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ółowoscentralizowanemu 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ótemCTC, od Centralized Traffic Control) umożliwia zdalne monitorowanie ruchu pociągów i zdalnesterowanie 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 zewspomnianych odcinków znajduje się co najwyżej jeden pociąg. Gdy pociąg wjeżdża na danyodcinek izolowany, specjalne czujniki rejestrują ten fakt i powodują wyświetlenie na monitorzedyspozytora (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ącychsię pod kontrolą określonego dyspozytora nazywamy „sekcją dyspozycyjną”.

Na rysunku 12.1 przedstawiona jest uproszczona postać interfejsu użytkownika systemuCTC. Odcinki izolowane reprezentowane są przez linie, zwrotnice — przez zbieg trzech lubczterech linii. Sygnały reprezentowane są przez ikony odzwierciedlające dwa stany: „stój” i „drogawolna”. 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 zlokalizowanew 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 nasygnalizatorach 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ć charaktersporadyczny.

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ówizolowanych 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


te ustąpiły miejsca stacjom roboczym umożliwiającym tworzenie bardziej wyrafinowanychinterfejsów dla dyspozytorów i pozwalającym na rozproszenie przetwarzania między kilkakomputerów. Mimo iż system nie jest krytyczny dla życia i zdrowia ludzkiego — nad któregobezpieczeństwem czuwają stacje przydrożne — jednak jego awaria spowodować może chaoskomunikacyjny, przekładający się (między innymi) na straty ekonomiczne. W konsekwencjiwszelkie transformacje technologiczne CTC — takie jak zastępowanie dedykowanych pulpitówmonitorami czy wymiana tych monitorów (połączonych z komputerami mainframe) na stacjerobocze — powinny odbywać się bardziej stopniowo niż w innych systemach. Tak oto CTCjawi 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óźnieniupociągu? W jaki sposób powinny być przechowywane trwałe dane? Która technologia niesie zesobą największe ryzyko? Zagadnienia często reprezentują problemy, dla których nie istniejejedyne 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 tejdefiniowany jest atrybut subject reprezentujący streszczenie zagadnienia, atrybut descriptionreprezentujący bardziej szczegółowy opis zagadnienia i jego związki z innymi materiałamioraz atrybut status informujący, czy zagadnieniezostało rozwiązane („zamknięte” — closed),czy nie („otwarte” — open). Zagadnienia zamknięte mogą być ponownie otwierane. Zgodniez 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 generujezagadnienie 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


system kontroli ruchu powinniśmy zbudować?, podlegające dekomponowaniu na znaczną liczbęprostszych podzagadnień. Zagadnienia mogą być także generowane przez decyzje podejmowanew związku z innymi zagadnieniami. Przykładowo zagadnienie dotyczące cache’owania danychw węźle lokalnym generuje natychmiast zagadnienia związane z utrzymywaniem spójnościmiędzy centralnym egzemplarzem danych a jego replikami w węzłach lokalnych. Takie wtórnezagadnienia 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ędziekorzystał 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 jakisposób dyspozytor powinien wydawać polecenia systemowi? oraz W jakiej postaci na ekraniestacji 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żliwychewentualnoś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ędziemyznak 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ć informowanyo 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ć dobraczy 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 zagadnieniemmogą 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 danychstrukturalnych i „płaskich” plików dla obrazów i dźwięków. Propozycje służą do reprezentowaniazaró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żywykorzystać architekturę „model-widok-kontroler” może być adresowana do zagadnień Jakodseparować obiekty interfejsu od obiektów encji? oraz Jak zapewnić spójność między wieloma


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 zagadnienieJak 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 obiektamiklasy Issue, za pomocą dwojakiego typu skojarzeń: skojarzenie addressed by wskazuje za-gadnienie, dla którego dana propozycja jest odpowiedzią, zaś skojarzenie raises wskazujejedno 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 reprezentowanesą w postaci znaków semigraficznych. Propozycja interfejsu tekstowego generuje zagadnieniewynikowe 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 wynikowegenerowane 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ówi argumentów.


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 kryteriazwiązane z celami projektowymi. Cele menedżerskie, w postaci minimum kosztów i minimumryzyka, to kryteria związane z zagadnieniami wynikającymi z zarządzania projektem. Zbiórkryteriów wskazuje kierunki oceniania poszczególnych propozycji. Propozycja spełniającaokreślone kryteriów kwalifikowana jest jako oceniona pozytywnie, propozycja niespełniającago — 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 subjectzawsze wyrażany jest w ukierunkowaniu pozytywnym, to znaczy musi wyrażać kryterium, któreposzczegó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 maksymalnykoszt). Kryteria (jako obiekty klasy Criterion) wiązane są z odpowiednimi propozycjami(obiektami klasy Proposal) za pomocą skojarzeń assessment. Skojarzenie posiada atrybutvalue, 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ę”) propozycjiw 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ć mylonez 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 trudniejszydo 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. Nadiagramach UML argumenty reprezentowane są przez instancje klasy Argument, posiadającejatrybuty 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, czyprzeciwko niej.


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 skojarzeniaassesment, 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 narzecz 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”, dokonujemywartościowania elementów w przestrzeni rozwiązań. Kolejnym krokiem jest wybór jednegoz 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 podsumowaniemich uzasadnienia. Na diagramach UML rozstrzygnięcia reprezentowane są przez instancje klasyResolution, definiującej atrybuty subject, description, justification i status. Każderozstrzygnię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 aktualniejest 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 klasyResolution; gdy odnośne zagadnienie jest zamknięte, czyli gdy rozstrzygnięcie pozostaje jego


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 activei 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ściw 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 danychza 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 diagramieUML (patrz rysunek 12.7) wybrane przez nas rozwiązanie reprezentowane jest jako obiektklasy Resolution skojarzony z dwoma obiektami klasy Issue.

Dodanie rozstrzygnięcia do modelu zagadnień oznacza formalne zakończenie dyskusjinad 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 listyznanych problemów.

12.3.6. Implementowanie rozstrzygni�: elementy dzia�ania

Rozstrzygnięcie implementowane jest w postaci elementów działania (action items). Elementdział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


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 tymmiejscu, ponieważ są ściśle powiązane z modelami zagadnień. Na diagramach UML elementydziałania reprezentowane są jako instancje klasy ActionItem definiującej atrybuty subject,description, owner, deadline i status. Atrybut owner reprezentuje osobę odpowiedzialną zawykonanie zadania związanego z elementem działania, atrybut status może przyjmować czterywartości reprezentujące stan wspomnianego zadania: todo („do wykonania”), notDoable(„niewykonalne”), inProgress („trwające”) i done („wykonane”). Rozstrzygnięcie powiązanejest z odnośnym elementem działania poprzez skojarzenie is implemented by. Na rysunku12.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 zaproponowaneprzez 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].


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 jerozwią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 sekcji12.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ązanyz kilkoma propozycjami.

Oryginalny model systemu IBIS nie zawiera węzłów reprezentujących kryteria i roz-strzygnięcia.

Rysunek 12.9. Model systemu IBIS


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 wykorzystywanydo 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 innymiDRL i QOC.

Decision Representation Language

System Decision Representation Language (DRL) pomyślany został jako narzędziewspomagające kolekcjonowanie racjonalizacji projektowania, rozumianej jako reprezentacjajakoś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 wspieranyjest 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ścirozwiązań. DRL stanowi rozwinięcie systemu IBIS, przez wzbogacenie modelu o dwie klasywęzłów reprezentujące cele projektowe (Goal) i procedury (Procedure). Z perspektywy DRLkonstruowanie 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łówi piętnaście klas skojarzeń, co widać na rysunku 12.10 — oraz dodatkowy wysiłek koniecznydla 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, andCriteria (QOC) („pytania, opcje i kryteria”). Węzły klasy Question („pytania”) składają się nareprezentację 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).


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 przedstawiony jest schematycznie na rysunku 12.11.

Rysunek 12.11. Model systemu QOC

QOC i IBIS różnią się jednak zasadniczo na poziomie procesów. Zadaniem systemuIBIS jest kolekcjonowanie elementów racjonalizacji na bieżąco, gdy pojawiają się w toku dys-kusji i rejestrowane są za pomocą wspomnianego narzędzia gIBIS. W systemie QOC strukturamodelu tworzona jest natomiast jako wynik refleksji nad bieżącym stanem projektu. Koncep-cyjna separacja faz konstrukcji i argumentacji akcentuje systematyczność i strukturalny cha-rakter racjonalizacji, w przeciwieństwie do budowania jej „na gorąco”. Z perspektywy modeluQOC racjonalizacja jest opisem eksplorowania przestrzeni projektowej przez programistów,system IBIS postrzega natomiast racjonalizację jako chronologiczny zapis analizy prowadzącejdo określonego projektu. W praktyce każde z tych podejść okazuje się przydatne do kolekcjo-nowania racjonalizacji w wystarczającym kształcie. (Aktywnościami związanymi z kolekcjo-nowaniem racjonalizacji i zarządzaniem nią zajmiemy się w sekcji 12.4).

NFR

Framework NFR3, opisany przez L. Chunga, B. A. Nixona, E. Yu i J. Mylopoulosa [Chungi in., 1999], w przeciwieństwie do trzech poprzednio omawianych modeli zagadnień dedyko-wany jest inżynierii wymagań, udostępnia bowiem metody śledzenia wymagań pozafunkcyj-nych związanych z poszczególnymi decyzjami, ocenianych propozycji rozwiązań i interakcjimiędzy wspomnianymi wymaganiami. Wymagania pozafunkcyjne traktowane są jako cele doosiągnięcia; jako że wymagania pozafunkcyjne są ze swej natury wysokopoziomowe i subiek-tywne — a przez to trudno się nimi operuje na poziomie modeli zagadnień — wspomnianecele mogą być doskonalone przez podział na podcele. Cele i podcele reprezentowane są w mo-delu jako węzły grafu, relacje dekompozycji na podcele reprezentowane są przez skierowanekrawędzie tego grafu. Model NFR dostarcza dwa typy dekompozycji. Oto one. 3 Skrót od Non-Functional-Requirements — „wymagania pozafunkcyjne” — przyp. tłum.


� Dekompozycja koniunkcyjna (AND decomposition) — by spełniony był określony cel,muszą być spełnione wszystkie podcele stanowiące wynik jego dekompozycji.

� Dekompozycja dysjunkcyjna (OR decomposition) — by spełniony był określony cel,wystarczy spełnienie co najmniej jednego spośród podcelów stanowiących wynik jegodekompozycji.

Tak więc cele wysokopoziomowe (specyfikowane przez klienta i użytkowników) dekom-ponowane są na bardziej szczegółowe podcele. Co ciekawe, nie musi to być podział ściśle drze-wiasty — jeden podcel może być podporządkowany kilku celom macierzystym. NFR udostęp-nia ponadto nowe klasy skojarzeń do reprezentowania rozmaitych powiązań, przykładowodany cel może wspierać inny cel lub kolidować z nim. Ponieważ wymagania pozafunkcyjnerzadko mają postać umożliwiającą kwalifikowanie binarne („spełnione-niespełnione”), skoja-rzenia między celami (podcelami) reprezentują także stopień, w jakim jeden cel korespondujez drugim lub z nim koliduje. Cel uważa się za „usatysfakcjonowany” (satisficed, nie mylićz satisfied — „spełniony”)4, jeśli wybrana ewentualność spełnia go w ramach minimum celówwspierających wyznaczonego przez skojarzenie; w przeciwnym razie cel uważany jest za„stłamszony” (denied). Ów limit formułowany jest w postaci pięciu następujących wag przypi-sywanych skojarzeniu: makes („powoduje”), helps („wspomaga”), neutral („nie ma związku”),hurts („kłóci się”) i breaks („zaprzecza”).

Węzły najwyższego poziomu reprezentują cele wysokopoziomowe specyfikowaneprzez klienta. W wyniku ich sukcesywnego doskonalenia do postaci celów bardziej szcze-gółowych uzyskujemy zbiór celów reprezentujących poszczególne cechy systemu — cele tenazywane są celami realizacyjnymi (operationalizing), dla odróżnienia od celów repre-zentujących oryginalne wymagania pozafunkcyjne.

Na rysunku 12.12 widoczny jest fragment grafu ukazujący warianty mechanizmu uwie-rzytelniania transakcji bankomatowych. Celami wysokopoziomowymi są tu: elastyczność(Flexibility), niski koszt (Low cost) i bezpieczeństwo (security). Ogólnie pojęte bezpie-czeństwo dekomponowane jest koniunkcyjnie na składowe: uwierzytelnienie (Authentication),poufność (Confidentiality) i integralność (integrity) — bezpieczny system może zezwalaćna dostęp do kont jedynie uprawnionym użytkownikom, dokonywane transakcje muszą byćtajne, a każda transakcja musi zakończyć się z zachowaniem integralności stanu kont (awariasystemu nie może spowodować zagubienia ani wykreowania kwoty). Uwierzytelnienie (jakocel) jest dalej dekomponowane dysjunkcyjnie ze względu na środki uwierzytelnienia, którymimogą być: numer konta wraz z numerem PIN (Account+PIN), karta inteligentna wraz z nu-merem PIN (SmartCard+PIN) lub linie papilarne (FingerPrint). Każdy z tych trzech ostat-nich podcelów jest celem realizacyjnym, na diagramie został więc wyróżniony pogrubionąobwódką. Każdy z nich pozostaje w określonej relacji z innymi celami; na diagramie ograni-czyliśmy się do pokazania, jak ma się uwierzytelnianie za pomocą numerów konta i PIN orazuwierzytelnianie za pomocą linii papilarnych do wymagań elastyczności i niskiego kosztu.

4 „Spełnienie” to właściwość kategoryczna: cel może być spełniony albo nie. „Usatysfakcjonowanie”

to wielkość mierzalna: dany cel jest tym bardziej „usatysfakcjonowany”, im więcej podcelów jest z nimzgodnych. Odpowiednio duży wskaźnik usatysfakcjonowania jest więc „rozmytym” odpowiednikiemspełnienia — przyp. tłum.

12.4. Aktywno�ci racjonalizacji — od zagadnie� do decyzji 567

Rysunek 12.12. Dekompozycja celów projektowych w ramach frameworku NFR na przykładzie me-chanizmu uwierzytelniania transakcji bankomatowych

Gdy w wyniku kompozycji zidentyfikowanych zostanie kilka celów realizacyjnych, pro-gramiści wybierają i wartościują wybrane ich podzbiory; na podstawie skojarzeń między ce-lami można wówczas wyrokować o „usatysfakcjonowaniu” lub „stłamszeniu” poszczególnychcelów wysokopoziomowych. W przykładzie na rysunku 12.12 jako rozwiązanie wybrany zostałpierwszy z wymienionych środków uwierzytelnienia (Account+PIN); jak widzimy, „usatysfak-cjonowane” zostały cele Authentication i Low cost, zaś „usatysfakcjonowanie” celu Securityuzależnione jest od „usatysfakcjonowania” celów Confidentiality i Integrity. Nie jest na-tomiast „usatysfakcjonowany” cel Flexibility.

Dla typowego, niebanalnego systemu przedstawiony graf dekompozycji rozrasta sięi komplikuje do tego stopnia, że do oceniania i porównywania różnych ewentualności roz-wiązania konieczne jest użycie narzędzi wspomagających. Jedną z zalet frameworku NFR,której nie będziemy szczegółowo opisywać, jest możliwość wielokrotnego wykorzystywaniadokonanej dekompozycji; umożliwia to programistom grupowanie wyników poprzednicheksploracji i ponowne ich wartościowanie w świetle nowych kryteriów.

12.4. Aktywno�ci racjonalizacji — od zagadnie� do decyzjiWłaściwe zarządzanie racjonalizacją ułatwia programistom radzenie sobie z koniecznymizmianami. Dokumentując uzasadnienie każdej decyzji, mogą oni łatwiej przeanalizować podjętewcześniej istotne decyzje pod kątem ich aktualności w obliczu nowych wymagań klienta czyzmian w środowisku. By jednak modele racjonalizacji mogły być rzeczywiście użyteczne, za-warta w nich informacja musi być aktualna, musi posiadać odpowiednią strukturę i musi byćłatwo dostępna. W tej sekcji opiszemy związane z tym aktywności, czyli:

� kolekcjonowanie racjonalizacji w ramach zebrań (patrz sekcja 12.4.2),� rewidowanie modeli racjonalizacji i ich sukcesywne ulepszanie (patrz sekcja 12.4.3),� wzbogacanie racjonalizacji o nowe elementy podczas wprowadzania zmian do systemu

(patrz sekcja 12.4.4),� rekonstruowanie racjonalizacji ukrywającej się za modelami systemu (patrz sekcja

12.4.5).


Najbardziej krytyczne elementy racjonalizacji rodzą się na etapie projektowania systemu:decyzje podejmowane na tym etapie mają wpływ na każdy podsystem i ich zmiana jest zwyklekosztowna, szczególnie gdy odbywa się w późnych stadiach procesu. Co więcej, racjonalizacjakryjąca się za dekompozycją systemu jest zazwyczaj bardzo skomplikowana, jako że rozciągasię na dużą liczbę zagadnień, takich jak odwzorowanie w węzły sprzętowe, przechowywa-nie trwałych danych, kontrola dostępu, globalne sterowanie przepływem i warunki graniczne(o czym pisaliśmy w rozdziale 7. „Projekt systemu: realizacja celów projektowych”).

Z tych właśnie względów w tym rozdziale skoncentrujemy się właśnie na etapie pro-jektowania systemu; opisywane techniki kolekcjonowania racjonalizacji wyglądają podobniena wszystkich innych etapach, począwszy od zbierania wymagań, aż po testy pilotażowe. Po-szczególne aktywności opisywać będziemy w kontekście realnego przykładu, jakim jest systemCTC; rozpocznijmy więc od przedstawienia projektu tego systemu.

12.4.1. Projekt systemu CTC

Ogólną charakterystykę systemu CTC przedstawiliśmy w sekcji 12.3.1. Wyobraźmy sobie, żeuczestniczymy w procesie inżynierii wtórnej, czyli w unowocześnianiu tego systemu, polega-jącym na zastąpieniu centralnego komputera mainframe siecią stacji roboczych. Zamierzamytakże rozszerzyć funkcje systemu o takie mechanizmy jak kontrola dostępu i generalnie lepszewsparcie dla bezpieczeństwa i użyteczności. Znajdujemy się właśnie w środku etapu projek-towania systemu i na razie sformułowaliśmy (na podstawie wymagań pozafunkcyjnych) kilkacelów projektowych (które wymieniamy, począwszy od najważniejszych).

� Dostępność. Awarie systemu nie mogą się zdarzać częściej niż jedna na miesiąc,a powrót systemu do normalnej pracy po awarii nie powinien trwać dłużej niż 10minut.

� Bezpieczeństwo. Żadna encja zlokalizowana poza nastawniami nie może uzyskiwaćdostępu do informacji o stanie zarządzanych odcinków izolowanych ani też nie możemieć możliwości manipulowania jakimikolwiek urządzeniami.

� Użyteczność. Przeszkolony dyspozytor może pomyłkowo wydawać błędne polecenianie częściej niż dwa razy dziennie.

Każdy dyspozytor posiada własny węzeł kliencki, zaś całością systemu zarządza para du-blujących się serwerów (patrz rysunek 12.13 i tabela 12.1). Serwery te odpowiedzialne są takżeza przechowywanie trwałych danych; dane te przechowywane są w formie niezależnych plików,które można kopiować offline i następnie importować do bazy danych w celu przetwarzaniaich zawartości. Komunikacja systemu z urządzeniami (stacjami przydrożnymi) odbywa się zapośrednictwem modemów zarządzanych przez dedykowaną maszynę. Oprogramowanie midd-leware realizuje dwa rodzaje komunikacji między podsystemami: wywoływanie metod reali-zujących żądania oraz powiadamianie o zdarzeniach istotnych dla poszczególnych podsystemów.Przed nami zadanie rozwiązania zagadnień związanych z kontrolą dostępu oraz mechanizma-mi zabezpieczającymi dyspozytorów przed ingerowaniem w ich sekcje dyspozycyjne przezinnych dyspozytorów.


Rysunek 12.13. Dekompozycja systemu CTC. Zarządzanie stanem systemu jest zadaniem serweramainServer, który w razie awarii zastępowany jest przez serwer hotBackup. Serwer wysyła polecenie i odbierainformację o stanie odcinków za pośrednictwem modemów, którymi zarządza węzeł ModemPool

Tabela 12.1. Opis podsystemów systemu CTC z rysunku 12.13

DispatcherClient Każdemu dyspozytorowi przydzielony jest węzeł DispatcherClient,realizujący interfejs użytkownika.

CTCServer Zarządza stanem systemu: wysyła dane do urządzeń w terenie i odbiera informacjeo ich stanie za pośrednictwem węzła ModemPool. Odpowiedzialny takżeza przechowywanie trwałych danych (między innymi adresów sieciowychi nazw urządzeń, przydziału dyspozytorów do sekcji dyspozycyjnych,rozkładów jazdy pociągów i tym podobnych). Redundancja w postaci pracydublujących się serwerów ma na celu zwiększenie dostępności systemu.

ModemPool Zarządza modemami realizującymi komunikację z urządzeniami w terenie.

ModemManager Zarządza połączeniami z urządzeniami w terenie i transmituje do nich polecenia.

StorageSubsystem Zarządza stanem trwałych danych systemu.

TrackingSubsystem Zarządza stanem poszczególnych odcinków izolowanych, na podstawieinformacji uzyskiwanych od urządzeń w terenie. Wysyła (za pośrednictwemwęzła ModemManager) polecenia do urządzeń w terenie, bazując na poleceniachotrzymywanych od węzła UISubsystem.

UISubsystem Odpowiedzialny za wyświetlanie stanu odcinków izolowanych na użytekdyspozytora oraz kontrolowanie poprawności poleceń wydawanych przezdyspozytora przed przekazaniem ich do węzła CTCServer.

12.4.2. Kolekcjonowanie racjonalizacji w ramach zebra�

Zebrania umożliwiają programistom prezentowanie, negocjowanie i rozwiązywanie zagad-nień w warunkach osobistej komunikacji. Fizyczna obecność dyskutantów jest tu bardzoważna, dostarcza bowiem sygnały komunikacji niewerbalnej, w postaci oceny nastawieniainnych uczestników do problemu i ich motywacji. Negocjowanie i podejmowanie decyzji „na


odległość”, na przykład ze pośrednictwem e-maili, jest mniej efektywne, bo łatwiej wówczaso nieporozumienia, tak więc spotkania „twarzą w twarz” stanowią bardziej naturalny punktwyjścia do kolekcjonowania racjonalizacji.

Procedury organizowania zebrań i związane z nimi dokumenty (agendy i protokoły) opi-saliśmy już w rozdziale 3. „Organizacja projektu i komunikacja”. Agenda, publikowana przedzebraniem, opisuje status problemu i jego aspekty przeznaczone do przedyskutowania. Przebiegzebrania dokumentowany jest w formie protokołu, który opublikowany zostaje wkrótce pozakończeniu zebrania. Wykorzystując koncepcje modelowania zagadnień opisane w sekcji 12.3,tworzymy agendę w kategoriach zagadnień, na temat których chcemy dyskutować i rozwiązaniaktórych chcemy poszukiwać. Jako cel zebrania określamy rozwiązanie tychże zagadnień, a takżewszystkich innych podzagadnień, które wynikną w trakcie dyskusji. Protokołowi zebrania na-dajemy strukturę uwzględniającą propozycje zgłaszane w trakcie zebrania, uzgodnione kryteriaich oceniania oraz argumenty wysuwane na poparcie poszczególnych propozycji i przeciwkonim. Podjęte decyzje formułujemy w kategoriach rozstrzygnięć i implementujących je ele-mentów działania. Przegląd statusu tych ostatnich będzie prawdopodobnie jednym z punktównastępnych zebrań.

Jako przykład rozpatrzmy zagadnienia związane z kontrolą dostępu w systemie CTC.Musimy w związku z tym zorganizować spotkanie z udziałem zespołu architektonicznegooraz programistów odpowiedzialnych za podsystemy UISubsystem, TrackingSubsystemi NotificationService. Alice, facilitator zespołu architektonicznego, publikuje poniższą agendę.

AGENDA: Integracja kontroli dost�pu i powiadamiania

Gdzie i kiedyData: 13 wrześniaPoczątek: 16:30Koniec: 17:30Pokój: Train Hall, 3420

RolePierwszy facilitator: AliceChronometrażysta: DaveProtokolant: Ed

1. CelPierwszą rewizję projektów odwzorowania sprzętowo-programowego i systemu przechowywaniadanych mamy już za sobą, konieczne jest teraz zdefiniowanie modelu kontroli dostępu i jegointegracji z istniejącymi podsystemami, między innymi NotificationService i TrackingSubsystem.

2. Oczekiwane wynikiRozwiązanie zagadnień związanych z integracją kontroli dostępu i powiadamiania.

3. Rozpowszechniana informacja [czas: 15 minut]AI[1]: Dave: Analiza modelu kontroli dostępu realizowanej przez middleware.

4. Dyskusja [czas: 35 minut]I[1]: Czy dyspozytor ma prawo oglądać sekcje dyspozycyjne kontrolowane przez innych dyspozytorów?I[2]:Czy dyspozytor ma prawo wysyłania poleceń do urządzeń znajdujących się w sekcjach

dyspozycyjnych kontrolowanych przez innych dyspozytorów?I[3]: W jaki sposób kontrola dostępu powinna być zintegrowana z podsystemami TrackingSubsystem

i NotificationService?

5. Podsumowanie [czas: 5 minut]Przegląd i przyporządkowanie nowych elementów działania.Uwagi krytyczne


W czasie zebrania dyskutowany będzie element działania stanowiący wynik poprzed-niego zebrania zespołu architektonicznego: AI[1]: Analiza modelu kontroli dostępu realizo-wanej przez middleware. Middleware dostarcza podstawowe bloki dla uwierzytelniania i szy-frowania informacji, nie wnosi nic poza tym do modelu kontroli dostępu. Zagadnienia I[1]i I[2] zostaną rozwiązane dość szybko w oparciu o wiedzę z dziedziny aplikacyjnej: każdydyspozytor może oglądać wszystkie sekcje dyspozycyjne, lecz możliwość manipulowania urzą-dzeniami ograniczona jest do jego własnej sekcji. Zagadnienie I[3] (W jaki sposób kontrola do-stępu powinna być zintegrowana z podsystemami TrackingSubsystem i NotificationService?)nie jest jednak tak oczywiste i stanowić będzie temat do dyskusji.

Trwa zebranie. Dave, programista odpowiedzialny za komponent NotificationService,proponuje zintegrowanie kontroli dostępu z klasą TrackSection (patrz rysunek 12.14 i tabela12.2). Klasa TrackSection powinna w związku z tym utrzymywać listę uprawnień, określającąuprawnienia poszczególnych dyspozytorów do odczytywania i modyfikowania stanu poszcze-gólnych sekcji dyspozycyjnych. Podsystem zainteresowany zdarzeniami zachodzącymiw ramach klasy TrackSection powinien subskrybować powiadamianie o tych zdarzeniach zapomocą usługi NotificationService. Usługa ta powinna sprawdzać, czy dyspozytor żą-dający informacji o danej sekcji dyspozycyjnej ma uprawnienia do (przynajmniej) odczyty-wania tego stanu.

Rysunek 12.14. Propozycja P[1]: Dostęp do klasy TrackSection kontrolowany jest za pomocą listyuprawnień utrzymywanej przez ten komponent. W oparciu o tę listę usługa NotificationServicesprawdza, czy żądający informacji dyspozytor ma prawo do jej uzyskiwania

Alice, programistka odpowiedzialna za podsystem TrackSubsystem, którego częścią jestklasa TrackSection, proponuje odwrócenie zależności między klasą TrackSection a usługąNotificationService (patrz rysunek 12.15 i tabela 12.3). Zgodnie z jej propozycją, podsys-tem UIClient nie powinien mieć bezpośredniego dostępu do usługi NotificationService,nawet przy subskrybowaniu informacji. W celu dokonania subskrypcji podsystem UIClientwywoła metodę subscribeToEvents() klasy TrackSection, która to metoda po pozytyw-nym zweryfikowaniu uprawnień wywoła operację subscribeToStateChangeEvents() usługiNotificationService. Dzięki temu uzyskamy scentralizowanie w ramach jednej klasy


Tabela 12.2. Opis elementów modelu widocznego na rysunku 12.14

NotificationService Usługa propagująca informację o zmianie stanu sekcji dyspozycyjnej(TrackSection). W celu otrzymywania informacji dotyczącej określonejsekcji za pośrednictwem tej usługi zainteresowany podsystem powinien tęinformację subskrybować. Może to jednak uczynić tylko podsystemposiadający uprawnienia do odczytywania informacji na tematwspomnianej sekcji. Uprawnienia te odczytywane są za pomocą operacjiisAccessible() klasy TrackSection.

System System odpowiedzialny za bezpieczne sprawdzanie, na podstawieinformacji przekazanej przez komponent UIClient, który dyspozytorżąda informacji. Obiekt TrackSection weryfikuje uprawnienia bieżącegodyspozytora za pomocą operacji whoIsThis().

TrackSection Klasa reprezentująca sekcję dyspozycyjną, złożoną z odcinkówreprezentowanych przez obiekty TrackCircuits i powiązane z nimiobiekty Devices. Na poziomie klasy TrackSection realizowana jestkontrola dostępu, w oparciu o listę utrzymywaną przez każdy obiekttej klasy.

UIClient Podsystem odpowiedzialny za wyświetlanie stanu sekcji dyspozycyjnychi przyjmowanie poleceń od dyspozytora.

Rysunek 12.15. Propozycja P[2]: klient zostaje pozbawiony dostępu do usługi NotificationService,całość operacji związanych z kontrolą dostępu skupiona zostaje w klasie TrackSection, za pośrednictwemktórej klient subskrybuje żądaną informację

wszystkich „chronionych”5 operacji i całokształtu kontroli dostępu. Ponadto, gdy zmienią sięuprawnienia dostępu, klasa TrackSection może we własnym zakresie anulować subskrypcjepozostające w sprzeczności z nowymi uprawnieniami.

5 Autorzy używają tu przymiotnika „chroniona” (protected) na określenie faktu, że wykonanie danej

operacji uzależnione jest od uprawnień podsystemu wywołującego tę operację, czyli poprzedzoneweryfikacją tych uprawnień (operacja „chroniona” jest przez mechanizm kontroli dostępu). Nie należywięc tym razem kojarzyć słowa „chroniona” z innym jego znaczeniem — poziomem widzialnościprotected elementu klasy (patrz sekcja 9.3.2) — przyp. tłum.


Tabela 12.3. Opis elementów modelu widocznego na rysunku 12.15; zmiany w stosunku do tabeli12.2 wyróżnione zostały kursywą

NotificationService Usługa propagująca informację o zmianie stanu sekcji dyspozycyjnej(TrackSection). W celu otrzymywania informacji dotyczącej określonejsekcji za pośrednictwem tej usługi zainteresowany podsystem powinien tęinformację subskrybować. Może to jednak uczynić tylko podsystemposiadający uprawnienia do odczytywania informacji na tematwspomnianej sekcji. Uprawnienia te odczytywane są za pomocąoperacji isAccessible() klasy TrackSection. Usługa dostępna jestbezpośrednio jedynie dla klasy TrackSection, podsystem UIClientnie ma do niej dostępu, subskrybuje on żądaną informację przezwywoływanie metody subscribeToEvents() klasy TrackSection.

TrackSection Klasa reprezentująca sekcję dyspozycyjną, złożoną z odcinkówreprezentowanych przez obiekty TrackCircuits i powiązane z nimiobiekty Devices. Na poziomie klasy TrackSection realizowana jestkontrola dostępu, w oparciu listę utrzymywaną przez każdy obiekt tejklasy. Klient, żądający informacji o stanie sekcji, powinien tę informacjęsubskrybować, wywołując metodę subscribeToEvents() klasyTrackSection. Klasa TrackSection po pozytywnym zweryfikowaniuuprawnień podsystemu żądającego informacji wywołuje operacjęsubscribeToTrackSectionEvents() usługi NotificationService.

Propozycja, którą zgłosił Ed, opiera się na ważnym spostrzeżeniu, iż kontroli dostępu po-winny podlegać jedynie próby modyfikowania stanu sekcji dyspozycyjnych, ponieważ z założeniaoglądanie stanu wszystkich sekcji ma być dostępne dla wszystkich dyspozytorów. Zakładając,że modyfikacja stanu sekcji dokonuje się wyłącznie przez wywoływanie odpowiednich metod,i biorąc pod uwagę fakt, że usługa NotificationService wykorzystywana jest jedynie do po-wiadamiania o zmianach stanu, a nie uczestniczy w modyfikacji wspomnianego stanu, łatwozauważyć, iż usługa ta nie pozostaje w żadnej relacji do mechanizmu kontroli dostępu. Nietrzeba zatem integrować jej z tym mechanizmem. Otrzymujemy tym samym propozycję bę-dącą ulepszeniem propozycji Dave’a (patrz rysunek 12.16 i tabela 12.4).

Rysunek 12.16. Propozycja P[3]: jedynie próby modyfikowania stanu obiektu TrackSection podlegająkontroli dostępu, więc usługa NotificationService przestaje być zależna od tego mechanizmu


Tabela 12.4. Opis elementów modelu widocznego na rysunku 12.16; zmiany w stosunku do tabeli 12.2wyróżnione zostały przekreśloną kursywą

NotificationService Usługa propagująca informację o zmianie stanu sekcji dyspozycyjnej(TrackSection). W celu otrzymywania informacji dotyczącejokreślonej sekcji za pośrednictwem tej usługi zainteresowanypodsystem powinien tę informację subskrybować. Może to jednakuczynić tylko podsystem posiadający uprawnienia do odczytywaniainformacji na temat wspomnianej sekcji. Uprawnienia te odczytywanesą za pomocą operacji isAccessible() klasy TrackSection.

Zespół architektoniczny zdecydował o wyborze propozycji Eda, dzięki jej prostocie.Ed jako protokolant sporządza przedstawiony poniżej chronologiczny protokół.

CHRONOLOGICZNY PROTOKÓ�: Integracja kontroli dost�pu i powiadamiania



1. CelPierwszą rewizję projektów odwzorowania sprzętowo-programowego i systemu przechowywaniadanych mamy już za sobą, konieczne jest teraz zdefiniowanie modelu kontroli dostępui jego integracji z istniejącymi podsystemami, między innymi NotificationServicei TrackingSubsystem.

2. Oczekiwane wynikiRozwiązanie zagadnień związanych z integracją kontroli dostępu i powiadamiania.3. Rozpowszechniana informacjaAI[1]: Dave: Analiza modelu kontroli dostępu realizowanej przez middleware.

Status: Middleware udostępnia silne mechanizmy szyfrowania i uwierzytelniania, pozatym nie wprowadza żadnych ograniczeń do modelu dostępu; konieczne jest więczaimplementowanie reguł dostępu na serwerze.

4. DyskusjaI[1]: Czy dyspozytor ma prawo oglądać sekcje dyspozycyjne kontrolowane przez innych

dyspozytorów?Ed: Tak, wynika to ze specyfikacji CTC.

I[2]: Czy dyspozytor ma prawo wysyłania poleceń do urządzeń znajdujących się w sekcjachdyspozycyjnych kontrolowanych przez innych dyspozytorów?Zoe: Nie, tylko dyspozytor przydzielony do danej sekcji dyspozycyjnej ma prawo

manipulować urządzeniami tej sekcji. Zauważmy przy tym, że możliwa jest dynamicznazmiana przydziału dyspozytorów do sekcji.

Ed: To też wynika ze specyfikacji CTC.


I[3]: W jaki sposób kontrola dostępu powinna być zintegrowana z podsystemamiTrackingSubsystem i NotificationService?Dave: W klasie TrackSection zaimplementowana jest lista uprawnień. Usługa powiadamiania

wykorzystuje tę listę do sprawdzania, które podsystemy mają prawo uzyskiwaćinformację o stanie tej sekcji.

Alice: Prawdopodobnie powinniśmy odwrócić kierunek zależności między usługąpowiadamiania a klasą TrackSection. Klient UIClient nie powinien kontaktować siębezpośrednio z usługą powiadamiania, lecz tylko z klasą TrackSection, któraprzed udostępnieniem informacji usłudze powiadamiania zweryfikuje uprawnieniapodsystemu żądającego tej informacji. W ten oto sposób skupimy w jednym miejscuwszystkie mechanizmy zależne od kontroli dostępu.

Dave: Dzięki takiemu rozwiązaniu klasa TrackSection będzie mogła automatyczniezweryfikować istniejące subskrypcje w przypadku zmodyfikowania listy uprawnień.

Ed: Zauważcie, że wszyscy dyspozytorzy mogą oglądać wszystkie sekcje dyspozycyjne,a więc kontrola dostępu konieczna jest tylko przy próbie modyfikowania ich stanu.Usługa powiadamiania może więc działać bez kontekstu kontroli dostępu.

Alice: Ale uwzględnienie możliwości powiązania usługi powiadamiającej z kontrolądostępu daje bardziej ogólne rozwiązanie.

Ed: Jednocześnie bardziej skomplikowane. Oddzielmy więc w tej chwili powiadamianieod kontroli dostępu i powróćmy do problemu, gdy zmienią się wymagania.

Alice: Dobrze, muszę zatem zrewidować API podsystemu TrackingSubsystem.5. PodsumowanieAI[2]: Alice: Zaprojektowanie kontroli dostępu dla podsystemu TrackingSubsystem w oparciu

o uwierzytelnianie i szyfrowanie udostępniane przez middleware.

Ed utworzył swój protokół poprzez wstawienie do agendy informacji o przebiegu dyskusjidotyczącej poszczególnych zagadnień. Zapis tej dyskusji ma postać chronologicznej listy wypo-wiedzi poszczególnych dyskutantów. Większość tych wypowiedzi łączy propozycje i argumentyna ich rzecz (oraz przeciwko niektórym innym propozycjom), aby więc protokół był zgodnyz modelem zagadnień, Ed nadaje mu odpowiednią strukturę, czego efekt widoczny jest poniżej.

STRUKTURALNY PROTOKÓ�: Integracja kontroli dost�pu i powiadamiania



1. CelPierwszą rewizję projektów odwzorowania sprzętowo-programowego i systemu przechowywaniadanych mamy już za sobą, konieczne jest teraz zdefiniowanie modelu kontroli dostępui jego integracji z istniejącymi podsystemami, między innymi NotificationServicei TrackingSubsystem.2. Oczekiwane wynikiRozwiązanie zagadnień związanych z integracją kontroli dostępu i powiadamiania.


3. Rozpowszechniana informacjaAI[1]: Dave: Analiza modelu kontroli dostępu realizowanej przez middleware.

Status: Middleware udostępnia silne mechanizmy szyfrowania i uwierzytelniania,poza tym nie wprowadza żadnych ograniczeń do modelu dostępu; konieczne jestwięc zaimplementowanie reguł dostępu na serwerze.

4. DyskusjaI[1]: Czy dyspozytor ma prawo oglądać sekcje dyspozycyjne kontrolowane przez innych

dyspozytorów?R[1]: Tak (wynika to ze specyfikacji CTC i potwierdzone jest przez Zoe, użytkownika

testującego).I[2]: Czy dyspozytor ma prawo wysyłania poleceń do urządzeń znajdujących się w sekcjach

dyspozycyjnych kontrolowanych przez innych dyspozytorów?R[2]: Nie, tylko dyspozytor przydzielony do danej sekcji ma prawo manipulować

urządzeniami tej sekcji. Zauważmy przy tym, że możliwa jest dynamiczna zmianaprzydziału dyspozytorów do sekcji (wynika to ze specyfikacji CTC i potwierdzonejest przez Zoe, użytkownika testującego).

I[3]: W jaki sposób kontrola dostępu powinna być zintegrowana z podsystemamiTrackingSubsystem i NotificationService?P[3.1]: W klasie TrackSection zaimplementowana jest lista uprawnień. Dany podsystem,

aby subskrybować powiadamianie o zdarzeniach tej sekcji, wysyła żądanie do usługipowiadamiania, która z kolei kontaktuje się z przedmiotową sekcją w celuzweryfikowania uprawnień wspomnianego podsystemu.

P[3.2]: W klasie TrackSection skupione zostają wszystkie chronione operacje. Podsystemzamierzający subskrybować informacje o stanie danej sekcji, kontaktuje się z tąwłaśnie sekcją, która po zweryfikowaniu jego uprawnień wywołuje usługępowiadamiania w celu dokonania rzeczonej subskrypcji.A[3.1] na rzecz P[3.2]: Chronione operacje i kontrola dostępu zostają zintegrowanew ramach jednej klasy.

P[3.3]: Nie trzeba kontrolować dostępu związanego z odczytywaniem informacji,UICLient może więc żądać subskrypcji od usługi powiadamiania bez względuna swe uprawnienia — usługa powiadamiania nie musi w ogóle interesować sięlistami uprawnień.A[3.2] na rzecz P[3.3]: Dyspozytorzy mogą bez ograniczeń oglądać wszystkie sekcje(patrz R[1]).A[3.3] na rzecz P[3.3]: Prostota.

R[3]: P[3.3]. Patrz AI[2].

5. PodsumowanieAI[2]: Alice: Zaprojektowanie kontroli dostępu dla podsystemu TrackingSubsystem w oparciuo uwierzytelnianie i szyfrowanie udostępniane przez middleware, zgodnie z rozstrzygnięciem R[3]tego protokołu.

Reasumując, rezultatem spotkania poświeconego kontroli dostępu było ustalenie, że:� każdy dyspozytor może oglądać stan wszystkich sekcji, lecz modyfikować może wy-

łącznie stan swej własnej sekcji,


� kontrola dostępu odbywa się na podstawie listy uprawnień skojarzonej z każdymobiektem klasy TrackSection,

� usługa powiadamiania (NotificationService) została odseparowana od kontrolidostępu, bowiem informacja o stanie dowolnej sekcji jest dostępna dla każdegodyspozytora.

Skupiając się na modelu zagadnień, możemy ponadto zauważyć, że:

� rozważano integrację usługi powiadamiania (NotificationService) z mechanizmamikontroli dostępu,

� scentralizowanie wszystkich chronionych metod w klasie TrackSection było ak-ceptowaną regułą.

Dwie ostatnie informacje są typowymi informacjami wchodzącym w skład racjonalizacji;zazwyczaj informacje tego typu uważane są za mało istotne, ich utrwalenie w modelu okazujesię jednak korzystne w dłuższej perspektywie, gdy pojawia się konieczność zmian.

12.4.3. Asynchroniczne kolekcjonowanie racjonalizacji

Dyskusje na zebraniach opierają się o informację kontekstową. Uczestnicy zebrania dysponująpokaźnym zasobem wiedzy na temat systemu, jego przeznaczenia i projektu. Facilitator z ko-nieczności ukierunkowuje przebieg zebrania na wąski zakres zagadnień oczekujących na roz-wiązanie. I tak na przykład wszyscy uczestnicy opisywanego w poprzedniej sekcji zebraniaz pewnością znają przeznaczenie systemu CTC, jego elementy funkcjonalne, cele projektowei aktualny kształt jego dekompozycji na podsystemy. Protokół z zebrania odzwierciedla jedyniedyskutowane na tym zebraniu zagadnienia, pomijając cały kontekst dyskusji. I niestety, wskutektego kontekst ów ulega z czasem zatraceniu i protokoły stają się coraz mniej zrozumiałe.

Temu właśnie problemowi można zaradzić przy użyciu modelowania zagadnień. W roz-dziale 3. „Organizacja projektu i komunikacja” opisywaliśmy wykorzystywanie oprogramowa-nia wspomagającego pracę grupową (groupware) w warunkach komunikacji asynchronicznej.Integrując przygotowanie do zebrania i jego przebieg z komunikacją asynchroniczną, zysku-jemy możliwość utrwalania także informacji kontekstowej.

Załóżmy na przykład, że programistka imieniem Mary, odpowiedzialna za podsystemUISubsystem, nie mogła uczestniczyć w zebraniu poświęconym kontroli dostępu. Zapoznałasię z agendą tego zebrania i protokołem (które dostępne były na grupie dyskusyjnej zespołuarchitektonicznego) i choć znakomicie rozumie wynik zebrania, dyskusja na temat usługi po-wiadamiania (NotificationService) wydaje się jej nie do końca jasna: zgodnie z argumentemA[3.3] dla propozycji P[3.3], ponieważ każdy dyspozytor może obserwować stan każdej sekcji,wszystkie zdarzenia w systemie są publicznie widoczne, nie ma więc potrzeby ujmowaćinformacji o nich w ramy mechanizmu kontroli dostępu. Aby jednak kontrola taka była sku-teczna w odniesieniu do modyfikowania stanu sekcji, konieczne jest założenie, że zdarzenia za-chodzące w jednym podsystemie nie mogą powodować zmiany stanu innych podsystemów,w tym poszczególnych sekcji TrackSection. Mary chce się upewnić, że taki właśnie jej tok


myślenia jest prawidłowy i w związku z tym wysyła na grupę dyskusyjną widoczny poniżejpost, w którym dodatkowo proponuje, by w konsekwencji zabronić usłudze TrackingServicesubskrybowania jakichkolwiek zdarzeń.

Grupy dyskusyjne: ctc.architecture.discuss

Temat: DataI[1]: Czy dyspozytor ma prawo oglądać sekcje dyspozycyjne kontrolowane przez

innych dyspozytorów?14 wrz

I[2]: Czy dyspozytor ma prawo wysyłania poleceń do urządzeń znajdujących sięw sekcjach dyspozycyjnych kontrolowanych przez innych dyspozytorów?

14 wrz

I[3]: W jaki sposób kontrola dostępu powinna być zintegrowana z podsystemamiTrackingSubsystem i NotificationService?

14 wrz

P[3.1]: W klasie TrackSection zaimplementowana jest lista uprawnień. 14 wrzP[3.2]: W klasie TrackSection skupione zostają operacje subskrypcyjne. 14 wrz

+A[3.1]: Rozszerzalność. 14 wrz+A[3.2]: Scentralizowanie wszystkich chronionych operacji. 14 wrz

P[3.3]: Usługa NotificationService nie jest związana z kontekstem kontrolidostępu.

14 wrz

+A[3.3]: Dyspozytorzy mogą oglądać wszystkie sekcje. 14 wrz+A[3.3]: Prostota. 14 wrz

Od: MaryGrupy dyskusyjne: ctc.architecture.discussTemat: Zagadnienie wynikowe: Czy dopuszczalne jest realizowanie żądań przy użyciupowiadamiania?Data: 15 wrz, czw, 13:12:48 -0400I[4] w odpowiedzi na A[3.3]: w związku z listami uprawnień w kontekście możliwości:> Dyspozytorzy mogą oglądać stan wszystkich sekcji, mają więc dostęp do wszystkich zdarzeń.Zakładamy zatem, że stan sekcji TrackSection nie jest sterowany zdarzeniami i zdarzeniawykorzystywane są tylko do informowania podsystemów o zmianie stanu w innych podsystemach.Czy dla większego bezpieczeństwa nie powinniśmy zabronić usłudze TrackingService subskrybowaniajakichkolwiek informacji o zdarzeniach?

Wykorzystywanie tego samego modelu zagadnień zarówno na zebraniach, jak i na po-trzeby dyskusji online umożliwia integrowanie informacji związanej z racjonalizacją. Mimo iżintegrację tę zapewnić można przy użyciu prostych technologii, takich jak grupy dyskusyjne,poszczególne elementy — modele zagadnień, agendy oraz protokoły zebrań i związane z nimikomunikaty — mogą być integrowane także za pomocą zaawansowanych narzędzi groupware,jak Lotus Notes czy wieloużytkowa baza zagadnień dostępna w sieci WWW (czego przykładwidzimy na rysunku 12.17). Ustanawiając odpowiednie procedury wspomnianej integracji,możemy kolekcjonować obszerną informacją związaną z racjonalizacją. I tu pojawia się ko-lejne wyzwanie — utrzymywanie tej informacji w stanie aktualnym, stosownie do dokonywa-nych zmian.


Rysunek 12.17. Przykład bazy zagadnień — szablon bazy danych (LN IBIS w Domino Lotus Notes).W tej bazie za pomocą formularzy WWW programiści mogą rejestrować zagadnienia, propozycje,argumenty i rozstrzygnięcia

12.4.4. Racjonalizacja dyskutowanych zmian

Modele racjonalizacji pomagają programistom uporać się z problemami wynikającymi z ko-nieczności wprowadzania zmian do systemu; niestety, sama racjonalizacja też jest przed-miotem zmian, gdy rozważamy adekwatność podjętych decyzji do nowych warunków. Innymisłowy, projektując rozwiązanie problemu pojawiającego się na przykład w związku ze zmia-nami w wymaganiach klienta, musimy nie tylko dostarczyć racjonalizacji dla nowych zmianwprowadzanych do systemu, lecz także powiązać nowe elementy racjonalizacji z tymi, którekryją się za obecnym kształtem systemu.

Załóżmy dla przykładu, że klient kontraktujący system CTC zmienił swe wymaganiadotyczące kontroli dostępu: dotychczas wszyscy dyspozytorzy mogli bez ograniczenia oglądaćstan wszystkich sekcji, klient uznał jednak, że dla danego dyspozytora interesujący może byćco najwyżej stan sekcji przylegających do jego własnej sekcji — stan innych sekcji jest dla niegoobojętny z punktu widzenia wykonywanych zadań.

Stajemy zatem przed koniecznością zmodyfikowania projektu mechanizmów kontrolidostępu, w związku z czym organizowane jest zebranie zespołu architektonicznego. Należyprzede wszystkim przeanalizować racjonalizację stojącą za obecnym kształtem wspomnianychmechanizmów; Alice, główny facilitator zespołu architektonicznego, publikuje widoczną po-niżej agendę.


AGENDA: Zrewidowanie kontroli dost�pu— dyspozytorzy mog� ogl�da tylko przylegaj�ce sekcje dyspozycyjne

Gdzie i kiedyData: 13 październikaPoczątek: 16:30Koniec: 17:30Pokój: Signal Hall, 2300


1. CelKlient żąda, by dyspozytorzy mogli oglądać tylko sekcje przylegające do ich własnych sekcji.

2. Oczekiwane wynikiZrewidowanie mechanizmów kontroli dostępu w związku z powyższą zmianą w wymaganiach klienta.

3. Rozpowszechniana informacja [czas: 15 minut]AI[1]: Dave: Odtworzenie racjonalizacji kryjącej się za obecnym projektem kontroli dostępu.

4. Dyskusja [czas: 35 minut]I[1]: W jaki sposób zrewidować istniejące mechanizmy kontroli dostępu, by ograniczyć

dyspozytorom dostęp wyłącznie do sekcji przylegających do ich własnych sekcji?

5. Podsumowanie [czas: 5 minut]Przegląd i przyporządkowanie nowych elementów działania.Uwagi krytyczne.

W trakcie zebrania Dave prezentuje racjonalizację dyskutowaną na poprzednim zebra-niu i na forum grupy dyskusyjnej zespołu architektonicznego. Zespół architektoniczny po-twierdza nieaktualność założenia, że dyspozytorzy mogą bez ograniczeń oglądać wszystkiesekcje — zgodnie z obecnymi wymaganiami możliwość ta ograniczona jest tylko do sekcjiprzylegających. Analizując protokół z poprzedniego zebrania, za najbardziej przydatną dlanowych warunków uznają oni propozycję P[2] (patrz rysunek 12.15): wszystkie chronioneoperacje scentralizowane są w klasie TrackSection i to ona staje się głównym obiektemwszelkich zmian wynikających z nowych wymagań dotyczących kontroli dostępu. Niestety,implementacja istniejącego projektu jest już mocno zaawansowana i przyjęcie propozycji P[2]jako rozstrzygnięcia wiązałoby się z drastycznymi zmianami istniejącego kodu, czego progra-miści chcieliby raczej uniknąć. Alicja optuje więc za propozycją P[1] (patrz rysunek 12.14):nie potrzeba wprowadzać zmian do podsystemu UIClient, bowiem interfejsy klas TrackSectioni NotificationService pozostają niezmienione. Zmiany wymaga natomiast implementacjausługi NotificationService: w celu weryfikacji praw dostępu usługa ta kontaktuje się z klasąTrackSection; gdy natomiast wprowadzone zostaną zmiany do listy uprawnień utrzymywanejprzez obiekt klasy TrackSection, ten kontaktuje się z usługą NotificationService, by anulo-wać (ewentualne) nieprzysługujące już subskrypcje. Wadą takiego rozwiązania jest cyklicznazależność obu klas TrackSection i NotificationService, jednak modyfikacja istniejącegokodu sprowadzona zostaje do rozmiarów minimalnych.

I ta właśnie propozycja wybrana zostaje jako rozstrzygnięcie przez zespół architekto-niczny. Ed sporządza widoczny poniżej strukturalny protokół (jego chronologiczny pierwo-wzór darujemy sobie ze względu na oszczędność miejsca).


STRUKTURALNY PROTOKÓ�: Zrewidowanie kontroli dost�pu— dyspozytorzy mog� ogl�da tylko przylegaj�ce sekcje

Gdzie i kiedyData: 13 październikaPoczątek: 16:30Koniec: 17:30Pokój: Signal Hall, 2300


1. CelKlient żąda, by dyspozytorzy mogli oglądać tylko sekcje przylegające do ich własnych sekcji.

2. Oczekiwane wynikiZrewidowanie mechanizmów kontroli dostępu w związku z powyższą zmianą w wymaganiach klienta.

3. Rozpowszechniana informacjaAI[1]: Dave: Odtworzenie racjonalizacji kryjącej się za obecnym projektem kontroli dostępu.

Wynik: Odtworzenie zagadnień I[1] (z 13 września) i I[2] (z 15 września):I[1]: Jak powinno się zintegrować kontrolę dostępu z klasami TrackSection

i NotificationService?(protokół z 14 września)P[3.1]: W klasie TrackSection zaimplementowana jest lista uprawnień. Dany podsystem,

aby subskrybować powiadamianie o zdarzeniach tej sekcji, wysyła żądanie do usługipowiadamiania, która z kolei kontaktuje się z przedmiotową sekcją w celuzweryfikowania uprawnień wspomnianego podsystemu.

P[3.2]: W klasie TrackSection skupione zostają wszystkie chronione operacje. Podsystemzamierzający subskrybować informacje o stanie danej sekcji kontaktuje się z tą właśniesekcją, która po zweryfikowaniu jego uprawnień wywołuje usługę powiadamianiaw celu dokonania rzeczonej subskrypcji.A[3.1] na rzecz P[3.2]: Rozszerzalność.A[3.2] na rzecz P[3.2]: Scentralizowanie wszystkich chronionych operacjiw jednej klasie.

P[3.3]: Nie ma potrzeby kontrolowania dostępu związanego z odczytywaniem informacji,UICLient może więc żądać subskrypcji od usługi powiadamiania bez względuna swe uprawnienia — usługa powiadamiania nie musi w ogóle interesować sięlistami uprawnień.A[3.3] na rzecz P[3.3]: Prostota.

R[3]: P[3.3]. Patrz AI[2].I[2]: Czy dopuszczalne jest realizowanie żądań przy użyciu powiadamiania? (post Mary z 15 września

na grupie dyskusyjnej)R[2]: Mechanizm powiadamiania może być wykorzystywany wyłącznie do informowania

o zmianach stanu podsystemów. Obiekty TrackSection — i w ogóle całypodsystem TrackingSubsystem — nie mogą zmieniać swego stanu wskutekpowiadomień.

4. DyskusjaI[1]: Jak należy zrewidować projekt kontroli dostępu, by ograniczyć dostępność sekcji dla

dyspozytora tylko do przyległych sekcji?


P[1.1]: Skupienie chronionych operacji, w tym subskrybowania, w ramach klasyTrackSection, jak w P[3.2] w protokole z 13 września.A[1.1] przeciwko P[1.1]: To wymagałoby modyfikacji wszystkich podsystemówsubskrybujących powiadamianie o zdarzeniach, ponieważ operacja subskrybowaniazostałaby przeniesiona z klasy NotificationService do klasy TrackSection.

P[1.2]: Usługa NotificationService wysyła do obiektu TrackSection żądaniezweryfikowania uprawnień, natomiast obiekt TrackSection wysyła do usługiNotificationService żądania anulowania subskrypcji, jeśli wynika to zezmienionych uprawnień dostępu — jak w P[3.1] w protokole z 13 września.A[1.2] na rzecz P[1.2]: Minimalne zmiany w istniejącej implementacji.A[1.2] przeciwko P[1.2]: Cykliczna zależność między klasami.

R[1]: P[1.2], patrz AI[2] i AI[3]

5. PodsumowanieAI[2]: Alice: Zmiana implementacji klasy TrackSection pod kątem odwoływania

subskrypcji tych dyspozytorów, którzy tracą do niej uprawnienia w wynikuzmian na liście dostępu.

AI[3]: Dave: Zmiana usługi NotificationService — w celu weryfikowania uprawnieńzwraca się ona do docelowego obiektu TrackSection.

Protokół ten przydatny jest do dwóch celów: określa racjonalizację nowej zmiany i jed-nocześnie odnosi ją do istniejącej racjonalizacji. Tę ostatnią przywołuje jako cytat z protokołudokumentującego poprzednie zebrania oraz postu na grupie dyskusyjnej zespołu architekto-nicznego. Wspomniany protokół opublikowany zostanie na rzeczonej grupie dyskusyjnej, byprogramiści nieobecni na zebraniu mogli przedyskutować jego treść, zamykając w ten sposóbcykl rejestrowania i wyjaśniania informacji składającej się na racjonalizację. Gdy używane sąnarzędzia hipertekstowe, odniesienie do istniejącej racjonalizacji ma formę hiperłączy, coumożliwia wygodne nawigowanie po powiązanych egzemplarzach informacji.

Nawet jeśli do rejestrowania i śledzenia poszczególnych zagadnień wykorzystywana jestzaawansowana baza danych, gromadzona w niej informacja może szybko przerodzić sięw ogromny chaos, bez wyraźnej struktury. Co więcej, nie wszystkie zagadnienia są w tej bazierejestrowane, bo nie wszystkie są przedmiotem dyskusji na zebraniach: wiele z nich rozstrzy-ganych jest w ramach nieformalnych konwersacji lub nawet przez pojedynczych programi-stów, bez jakichkolwiek konsultacji. Konieczne zatem staje się rekonstruowanie umykającejw ten sposób informacji i integrowanie jej z bieżącą racjonalizacją.

12.4.5. Rekonstruowanie racjonalizacji

Rekonstruowanie racjonalizacji to odmienna metoda jej kolekcjonowania. Zamiast rejestro-wania na bieżąco, informacja składająca się na racjonalizację jest systematycznie rekonstru-owana na podstawie modeli systemu, zapisków komunikacyjnych (e-maili, postów na grupachdyskusyjnych) i faktów zapamiętanych jedynie przez programistów. W ten sposób racjonali-zacja rozwijana jest w sposób bardziej systematyczny, we wczesnych fazach projektu zu-żywanych jest mniej zasobów, co umożliwia programistom szybsze uzyskiwanie rozwiązań.


Ponadto odseparowanie aktywności projektowych od kolekcjonowania racjonalizacji umoż-liwia programistom krytyczne i bardziej obiektywne przyglądanie się efektom swych prac.Rekonstruowanie racjonalizacji opiera się jednak głównie na tych propozycjach, które wy-brane zostały jako rozstrzygnięcia; propozycje odrzucone są szybko zapominane przez pro-gramistów i ich utrwalanie jest znacznie trudniejsze.

Załóżmy na przykład, że nie prowadziliśmy kolekcjonowania racjonalizacji w związkuz tworzeniem systemu CTC i jedyna informacja związana z tym systemem zawarta jest w jegoprojekcie, którego fragment dotyczący kontroli dostępu prezentuje się następująco.

4. Kontrola dost�pu

Kontrola dostępu w systemie CTC realizowana jest na poziomie sekcji dyspozycyjnych (TrackSection):dyspozytor (Dispatcher) przydzielony do danej sekcji może modyfikować ich stan, czyli prze-stawiać sygnały i zwrotnice oraz operować innymi urządzeniami. Dyspozytor może równieżoglądać stan sekcji przylegających do jego sekcji macierzystej, bez możliwości modyfikowaniaich stanu. Dyspozytor może w ten sposób obserwować pociągi zbliżające się do kontrolowanejprzez niego sekcji.

Kontrola dostępu zaimplementowana jest w postaci list uprawnień, utrzymywanych przez po-szczególne obiekty TrackSection reprezentujące konkretne sekcje. Dla danej sekcji lista ta za-wiera identyfikację dyspozytora uprawnionego do modyfikowania tej sekcji („pisarza”) orazidentyfikacje dyspozytorów uprawnionych do obserwowania ich stanu („czytelników”)6. Zewzględów ogólności (rozszerzalności) lista zaimplementowana jest w ten sposób, że może za-wierać wielu „czytelników” i wielu „pisarzy”. Lista utrzymywana przez daną sekcję sprawdzanajest przed wykonaniem każdej operacji odczytującej lub modyfikującej jej stan.

Gdy podsystem żąda subskrybowania określonej informacji, dotyczącej stanu danej sekcji, wy-woływana przez niego usługa NotificationService kontaktuje się z tą sekcją w celu zweryfi-kowania praw wspomnianego podsystemu do odczytywania jej stanu. Gdy modyfikuje się listęuprawnień związaną z daną sekcją, sekcja ta wywołuje usługę NotificationService w celuanulowania nieuprawnionych subskrypcji.

Powyższe rozwiązanie przedstawione jest na rysunku 12.14.

Rekonstruując racjonalizację na podstawie dokumentacji i przeglądów, zapisujemy każdezagadnienie w formie tabeli z dwiema kolumnami, zawierającymi propozycje (lewa kolumna)i argumenty „za” i „przeciw” tym propozycjom (prawa kolumna). W tabeli 12.5 widoczny jestefekt takiej rekonstrukcji w odniesieniu do zintegrowania kontroli dostępu z mechanizmamipowiadamiania. Identyfikujemy dwa możliwe rozwiązania: P[1], zgodnie z którym klasaTrackSection eksportuje wszystkie operacje wymagające kontroli dostępu, oraz P[2], po-legające na delegowaniu przez usługę NotificationService kontroli dostępu do obiektuTrackSection. Wyliczamy zalety i wady każdego z tych rozwiązań (w prawej kolumnie), a nadole tabeli umieszczamy uzasadnienie decyzji o wyborze konkretnego rozwiązania.

6 To analogia do paradygmatu „czytelników i pisarzy”, o tyle jednak daleka, że nie mamy tu do czynienia

z rywalizowaniem o dostęp do zasobów — przyp. tłum.


Tabela 12.5. Zrekonstruowana racjonalizacja kontroli dostępu związanego z powiadamianiemw systemie CTC

I[1]: Jak powinno się zintegrować kontrolę dostępu z klasą TrackSection i usługą powiadamiania?

Kontrola dostępu w systemie CTC realizowana jest na poziomie sekcji dyspozycyjnych (TrackSection):dyspozytor (Dispatcher) przydzielony do danej sekcji może modyfikować ich stan, czyli przestawiaćsygnały i zwrotnice oraz operować innymi urządzeniami. Dyspozytor może również oglądać stansekcji przylegających do jego sekcji macierzystej, bez możliwości modyfikowania ich stanu. Dyspozytormoże w ten sposób obserwować pociągi zbliżające się do kontrolowanej przez niego sekcji.

P[1]: Klasa TrackSection odpowiedzialnajest za modyfikowanie stanu sekcji orazsubskrypcje związane z powiadamianiem.Kontrola dostępu zaimplementowana jest w formielisty uprawnień utrzymywanej przez obiektyklasy TrackSection. Uprawnienia sprawdzanesą dla każdej operacji odczytującej lubmodyfikującej stan wspomnianych obiektów.Podsystem zamierzający subskrybowaćpowiadomienia o zdarzeniach wywołujeodpowiednie metody klasy TrackSection,które z kolei przekazują wywołanie do usługipowiadamiania (NotificationService) podwarunkiem pozytywnego zweryfikowaniauprawnień do subskrypcji. Rozwiązanieto przedstawione jest na rysunku 12.15.

Na rzecz propozycji:� Scentralizowane rozwiązanie — wszystkie

chronione metody związane z klasąTrackSection zgrupowane są w tej klasie.

P[2]: Klasa TrackSection odpowiedzialna jestwyłącznie za modyfikowanie stanu sekcji, usługapowiadamiania (NotificationService)zarządza tylko powiadamianiem.Podobnie jak P[1], z tą jednak różnicą,że podsystem żąda subskrypcji bezpośredniood usługi powiadamiania, która odwołuje siędo obiektu TrackSection w celu zweryfikowaniauprawnień do tej subskrypcji.

Na rzecz propozycji:� Interfejs niezależny od kontroli dostępu:

interfejsy klas NotificationServicei TrackSection są takie same jak w przypadkunieobecności kontroli dostępu.

� Przeciwko propozycji:� Cykliczna zależność między klasami

NotificationService i TrackSection: obiektTrackSection wywołuje usługę powiadamiającąw celu zasygnalizowania zdarzenia, zaś usługapowiadamiająca odwołuje się do obiektuTrackSection w celu zweryfikowaniauprawnień do subskrypcji.

R[1]:

P[2]. Propozycja P[1] mogłaby być lepszym rozwiązaniem, ze względu na wyłączenie usługipowiadamiania z kontekstu kontroli dostępu, gdyby nie konieczność związanej z tym znaczącejprzeróbki istniejącego kodu. W przypadku propozycji P[2] przeróbka ta jest znacznie mniejsza.

Przedstawione rekonstruowanie racjonalizacji jest mniej kosztowne niż aktywnościuprzednio opisywane. Jest jednak znacznie trudniejsze pod względem dokumentowania od-rzuconych propozycji i powodów ich odrzucenia, szczególnie gdy podejmowane decyzje byływielokrotnie rewidowane. Rozstrzygnięciu z tabeli 12.5 towarzyszy wyjaśnienie, iż jest ono

12.5. Kierownicze aspekty zarz�dzania racjonalizacj� 585

wyborem gorszej (nieoptymalnej) propozycji z określonych względów praktycznych (czyliprzeróbki kodu znacznie bardziej ograniczonej w porównaniu z wyborem propozycji opty-malnej). O takich subtelnościach często jednak zapomina się z czasem.

Rekonstruowanie racjonalizacji może być efektywnym narzędziem przeglądu systemu,szczególnie pod względem wyszukiwania decyzji niespójnych z celami projektowymi. I jeżelinawet zmiana tych decyzji okazuje się niewykonalna w późnych stadiach projektu, nabytaprzy tej okazji wiedza okaże się pożyteczna dla nowych programistów oraz programistów do-konujących rewizji systemu w następnych iteracjach.

Wzajemne proporcje między kolekcjonowaniem, utrzymywaniem i rekonstruowaniemracjonalizacji są różne dla odmiennych projektów i muszą zostać starannie określone przezmenedżera projektu. Spotyka się dość często kolekcjonowanie, przy znacznym wysiłku, po-tężnej dawki informacji w większości bezużytecznej lub trudno dostępnej dla programistów,którzy mogliby ją spożytkować. Zajmiemy się tym problemem w następnej sekcji.

12.5. Kierownicze aspekty zarz�dzania racjonalizacj�Gdy menedżer projektu żąda od programistów szczegółowego uzasadnienia podejmowanychprzez nich decyzji projektowych, często traktowany jest jak intruz, a same techniki związanez racjonalizacją napotykają opór ze strony programistów i rychło przeradzają się w biurokrację.Stanowi to duże wyzwanie dla menedżera, odpowiedzialnego za najważniejsze aspekty zarzą-dzania racjonalizacją, między innymi:

� jej dokumentowanie (patrz sekcja 12.5.1),� przypisywanie odpowiedzialności w zakresie kolekcjonowania i pielęgnowania modeli

racjonalizacji (patrz sekcja 12.5.2),� zapewnienie komunikacji dotyczącej modeli racjonalizacji (patrz sekcja 12.5.3),� negocjowanie zagadnień (patrz sekcja 12.5.4),� rozwiązywanie konfliktów (patrz sekcja 12.5.5).

Jak poprzednio, koncentrujemy się na racjonalizacji związanej z etapem projektowaniasystemu, opisywane techniki przydatne są jednak równie dobrze na wszystkich pozostałychetapach.

12.5.1. Dokumentowanie racjonalizacji

Modele racjonalizacji (na przykład modele zagadnień) różnią się pod względem struktury odmodeli systemu (modelu przypadków użycia, modelu klas, kodu źródłowego). Jako że modeletypowego systemu są rozległe i skomplikowane, programiści wykorzystują rozmaite technikiradzenia sobie z ich złożonością, organizując je w warstwy i hierarchie, wiążąc je z przypad-kami użycia, czy też kojarząc dokumentację obiektów systemu z ich kodem źródłowym.Modele racjonalizacji są z natury bardziej objętościowe od modeli systemu, obejmują bowiemwszystkie propozycje związane z rozwiązywaniem poszczególnych problemów, argumenty„za” i „przeciw” tym propozycjom, podjęte decyzje oraz ich uzasadnienia. Ponieważ podej-mowane decyzje bywają rewidowane i zmieniane, modele racjonalizacji także nieustannieewoluują. Niewłaściwe jest zatem myślenie o racjonalizacji w kategoriach jedynie dokumentu,


gdyż każdy taki dokument rychło stawałby się nieaktualny i nieadekwatny do pozostałych do-kumentów. Odpowiedniejszym podejściem jest utrzymywanie racjonalizacji w formie repozy-torium, nieustannie aktualizowanego i uzupełnianego o nowe zagadnienia i decyzje. Zawartośćtego repozytorium musi być jednak utrzymywana w aktualnym stanie i łatwo dostępna dlawszystkich zainteresowanych. Wymaganie to prowadzi wprost do ścisłego zintegrowania re-pozytorium racjonalizacji z innymi narzędziami i procesami programistycznymi. Przykłademnarzędzia realizującego taką integrację jest REQuest; narzędzie to umożliwia formułowanieprzypadków użycia w kontekście ich racjonalizacji, o czym piszą A. H. Dutoit i B. Paech[Dutoit i Paech, 2002]. Na rysunku 12.18 widzimy przykładowy ekran tej aplikacji; lewakolumna zapewnia dostęp do poszczególnych wymagań systemu, w podziale na przypadkiużycia i wymagania pozafunkcyjne, zaś w prawej kolumnie prezentowane są elementy racjo-nalizacji związane z poszczególnymi wymaganiami, w kategoriach rozszerzonego modeluQOC. Przyciski w górnej części lewej kolumny umożliwiają programistom formułowanie pytańw różnych kategoriach (klarowności, kompletności, spójności, prawidłowości uformowania,poprawności, uzasadnienia) i kojarzenie ich z aktualnie wyświetlanym elementem.

Zielone, żółte i czerwone wskaźniki towarzyszące elementom racjonalizacji wymienio-nym w lewej kolumnie oznaczają status zagadnienia reprezentowanego przez ten element.Klikając wspomniany wskaźnik, otrzymujemy opis odnośnego zagadnienia w prawej kolumnie.

Rysunek 12.18. REQuest — przykład repozytorium racjonalizacji zintegrowanego z narzędziem inżynieriiwymagań: elementy modelu racjonalizacji kojarzone są z poszczególnymi wymaganiami. W lewej kolumniewyświetlane są elementy modelu wymagań, prawa kolumna dedykowana jest modelowi zagadnień

Zintegrowanie elementów specyfikacji z widokami elementów racjonalizacji daje pro-gramistom łatwy dostęp do aktualnej informacji; zapewnienie jej aktualności w dłuższej per-spektywie, poprzez konsolidowanie i pielęgnowanie jej elementów, jest zadaniem wynikającymz roli redaktora racjonalizacji; tę i inne role związane z zarządzaniem racjonalizacją opiszemyw następnej sekcji.


12.5.2. Przypisywanie odpowiedzialno�ci

Właściwe przyporządkowanie odpowiedzialności związanej z kolekcjonowaniem i pielęgno-waniem racjonalizacji jest najbardziej krytyczną decyzją menedżera, decydującą o rzeczywistejużyteczności modeli racjonalizacji. Zarządzanie racjonalizacją sprowadzone do postaci biuro-kratycznej procedury uzasadniania przez każdego programistę każdej podejmowanej przezniego decyzji nie spełni swego zadania. Zamiast tego modele racjonalizacji powinny być utrzy-mywane przez niewielką grupę osób — „historyków systemu” — na podstawie wszelkiejinformacji, jaka będzie dla nich dostępna ze strony programistów: szkiców dokumentówprojektowych, postów na grupach dyskusyjnych i tym podobnych. Ponieważ gromadzonaw ten sposób informacja jest jedną z najważniejszych, jakiej potrzebują programiści w zmaga-niach się z konsekwencjami nieuchronnych zmian, w interesie samych programistów leżytroska o zapewnienie jej należytej szczegółowości i kompletności.

W związku ze wspomnianą na wstępie odpowiedzialnością za aktualność i użytecznośćinformacji składającej się na racjonalizację, menedżer projektu wyznacza następujące role.

� Protokolant odpowiedzialny jest za kolekcjonowanie na bieżąco elementów racjo-nalizacji pojawiających się w ramach zebrań; kolekcjonowanie to polega na spo-rządzaniu chronologicznego zapisu dyskusji, który to zapis po zakończeniu zebraniastanowi podstawę do sporządzenia strukturalnego protokołu dokumentującego za-gadnienia, propozycje, argumenty i rozstrzygnięcia. Pisaliśmy o tym w sekcji 12.4.2.

� Redaktor racjonalizacji odpowiedzialny jest za gromadzenie i organizację informa-cji związanej z racjonalizacją. Informacja ta obejmuje między innymi strukturalneprotokoły z zebrań, prototypy, oceny poszczególnych technologii przez programi-stów, szkice modeli systemu oraz dokumenty projektowe (lub ich szkice). Dla zebranejinformacji tworzony jest indeks według poszczególnych zagadnień. Redaktor racjo-nalizacji wyręcza programistów w porządkowaniu i strukturalizowaniu informacjiskładającej się na racjonalizację, ograniczając ich rolę do udostępniania tej informacji.

� Weryfikator racjonalizacji analizuje informację zebraną przez redaktora i iden-tyfikuje napotkane w niej luki, korzystając z tych samych źródeł informacji, co re-daktor. Nie jest to rola o charakterze menedżerskim, weryfikator powinien przekonaćprogramistów, iż uzyskanie od nich rzetelnych informacji opłaci się w dłuższej per-spektywie. Role redaktora i weryfikatora często powierzane są tej samej osobie.

Rozmiar projektu determinuje liczbę protokolantów, redaktorów i weryfikatorów.Przy przydzielaniu tych ról pomocne mogą okazać się następujące heurystyki.

� Jeden protokolant dla każdego zespołu. Zebrania są zwykle organizowane przez zespołyzajmujące się poszczególnymi podsystemami lub zespół międzyfunkcyjny. Rolę proto-kolanta mogą rotacyjnie pełnić poszczególni programiści, co przyczynia się do równo-miernego rozłożenia tego czasochłonnego obowiązku w całym cyklu realizacji projektu.

� Jeden i ten sam redaktor racjonalizacji przez cały czas realizacji projektu. Ta rola wy-maga pełnoetatowego zaangażowania, w przeciwieństwie więc do rotacyjnej roli pro-tokolanta wymaga zachowania spójności i z tego względu powinna być przypisanapojedynczej osobie. W przypadku małych projektów rolę tę pełnić może architektsystemu (patrz rozdział 6. „Projektowanie systemu — dekompozycja na podsystemy”).


� Zwiększenie liczby weryfikatorów racjonalizacji po dostarczeniu systemu. Po dostar-czeniu systemu klientowi zmniejsza się liczba programistów, którzy muszą byćbezpośrednio zaangażowani w projekt. Programistom odciążonym można powie-rzyć role weryfikatorów, którzy powinni wydobyć tyle informacji związanej z ra-cjonalizacją, ile to tylko możliwe — elementy tej informacji wciąż są jeszcze żywew umysłach programistów i należy je utrwalić, zanim naturalną koleją rzeczy odejdąw zapomnienie.

12.5.3. Heurystyki komunikowania racjonalizacji

Duża część informacji komunikowanej w związku z projektem to informacja związana z ra-cjonalizacją, każdy argument jest bowiem z definicji racjonalny, co wyjaśnialiśmy w sekcji12.2. Programiści wymieniają argumenty dotyczące celów projektowych, istotności związanychz nimi zagadnień, ich ewaluacji i tak dalej. Na racjonalizację systemu składa się ogrom skom-plikowanej informacji, znacznie obszerniejszej niż sam system. Informacja ta wymieniana jestnajczęściej w kręgu małych forów, między innymi na zebraniach zespołu i w ramach niefor-malnych konwersacji przy automacie z kawą. Podstawowym wyzwaniem pod adresem za-rządzania racjonalizacją jest udostępnienie tej informacji zainteresowanych uczestnikom,z zachowaniem treści, lecz bez przeładowywania formy. Opisaliśmy już kilka technik ko-lekcjonowania i strukturalizowania racjonalizacji, między innymi przez modelowanie zagad-nień w protokołach i reprezentowanie racjonalizacji w formie repozytoriów. Uzupełnieniemtych technik mogą być poniższe heurystyki, które sprawiają, że struktura racjonalizacji stajesię bardziej czytelna i łatwiej po niej nawigować.

� Wybieraj nazwy zagadnień w sposób spójny. Zagadnienia powinny być opatrywanespójnymi nazwami, unikalnymi w obrębie protokołów, grup dyskusyjnych, komu-nikatów e-mail i dokumentów. Dla ułatwienia identyfikacji w nazwie każdego zagad-nienia powinien być obecny jego numer i krótka, sugestywna fraza określająca jegokategorię (na przykład „zagadnienie_dostęp/powiadamianie”).

� Scentralizuj zagadnienia. Mimo iż zagadnienia mogą być w dyskutowane w różnychkontekstach, jeden z nich (grupę dyskusyjną, bazę zagadnień) należy specjalnie wy-różnić jako ich centralne repozytorium. Baza zagadnień powinna być utrzymywanaprzez redaktora racjonalizacji, lecz każdy programista powinien mieć możliwość jejodczytywania i rozszerzania o nowe pozycje. Ułatwi to programistom szybkie wy-szukiwanie niezbędnych informacji.

� Zapewnij powiązania zagadnień z odnośnymi elementami systemu. Większość za-gadnień odnosi się do konkretnych elementów modeli systemu (przypadków użycia,obiektów, podsystemów). Identyfikowanie zagadnień związanych z konkretnym ele-mentem systemu jest sprawą oczywistą, relacja odwrotna — identyfikowanie elementusystemu, do którego odnosi się konkretne zagadnienie — jest zdecydowanie bardziejproblematyczna. By relację ta stała się bardziej użyteczna i czytelna, należy wiązaćkażde zagadnienie w momencie jego powstawania z elementem systemu, któregodotyczy.


� Zarządzając zmianami, pamiętaj o racjonalizacji. Racjonalizacja systemu ewoluujewraz z jego modelami, zatem powinna podlegać zarządzaniu konfiguracją w takimsamym stopniu jak wspomniane modele.

Kolekcjonowanie i strukturalizowanie racjonalizacji nie tylko usprawnia jej komuniko-wanie, lecz także ułatwia komunikację związaną z modelami systemu. Zintegrowanie obutych kategorii informacji ułatwia programistom utrzymywanie spójności między nimi.

12.5.4. Modelowanie i negocjowanie zagadnie�

Najważniejsze decyzje związane z projektem są w większości przypadków wynikiem negocjacji— różne strony, reprezentujące różne, często sprzeczne interesy wypracowują konsensusw sprawie wybranego aspektu systemu. Analiza wymagań wiąże się z negocjowaniem kształtufunkcjonalnego systemu z klientem, projektowanie systemu wymaga negocjowania interfejsówmiędzy programistami, integrowanie podsystemów wymaga rozwiązywania konfliktów międzyprogramistami. Modele zagadnień są wygodną formą reprezentowania informacji wymie-nianej w czasie negocjowania, mogą być jednak równie użyteczne w dziele ułatwiania samychnegocjacji.

Tradycyjne negocjowanie, polegające na trwaniu z uporem na swych pozycjach, jest czę-sto czasochłonne i bezowocne, szczególnie gdy stanowiska negocjujących stron są wyraźniesprzeczne. Cały wysiłek kierowany jest wówczas na akcentowanie zalet własnego stanowiska,przy jednoczesnym wytykaniu wad stanowiska prezentowanego przez drugą stronę. Jeżeli na-wet obie strony zainteresowane są osiągnięciem porozumienia, perspektywa zmiany prezen-towanego nastawienia postrzegana bywa jako ryzyko utraty wiarygodności. Takie negocjacjez trudem (jeżeli w ogóle) posuwają się do przodu, prowadząc do wypracowania jakiegoś kom-promisu.

Jedną ze znanych metodologii pokonywania opisanych trudności jest tak zwana har-wardzka metoda negocjowania, opisana w książce R. Fishera, W. Ury’ego i B. Pattona [Fisheri in., 1991], koncentrująca przebieg negocjacji na ich przedmiocie, a nie na negocjującychstronach. W przełożeniu na modelowanie zagadnień podstawowe założenia tej metody możnasformułować następująco.

� Oddzielaj propozycje od formułujących je programistów. Programiści wkładają takwiele wysiłku w wypracowywanie konkretnych propozycji i w efekcie tak silnie sięz nimi identyfikują, że krytykowanie danej propozycji odbierane jest jak osobistyatak na jej autora. Wyraźne oddzielenie propozycji od osoby jej autora ułatwia dys-kutowanie i być może odrzucenie. Można ten cel osiągnąć, wypracowując poszcze-gólne propozycje kolektywnie (nie jednoosobowo) lub angażując obie negocjującestrony w ich opracowywanie. Programiści łatwiej rezygnują ze swych propozycji,jeśli te nie wiążą się jeszcze z zaangażowaniem znacznych zasobów, stąd oczywistywniosek, by negocjowanie propozycji odbywało się jeszcze przed rozpoczęciem im-plementowania ich następstw.

� Koncentruj się na kryteriach, nie propozycjach. Programiści bronią swych propozycji(i podważają propozycje drugiej strony), działając zgodnie z pewnymi kryteriami— wysuwane przez nich propozycje są zapewne zgodne z ich własnymi kryteriami,


lecz niekoniecznie z kryteriami przyjmowanymi przez innych programistów. Kon-flikt w negocjacjach jest więc najczęściej tak naprawdę konfliktem między kryteriami— gdy kryteria staną się w pełni jawne, łatwiejsze będzie wypracowanie kompromisu.Gdy uzgodniony zostanie zestaw kryteriów satysfakcjonujący wszystkie negocjującestrony, negocjowanie poszczególnych propozycji nabierze bardziej obiektywnegocharakteru i stanie się daleko mniej kontrowersyjne.

� Uwzględniaj wszystkie kryteria, zamiast faworyzować jedno wybrane. Różnica kryte-riów przyjętych przez poszczególne strony negocjacji wynika wprost z różnicy intere-sów tych stron: kryteria wydajnościowe motywowane są przez względy użytecznościsystemu, kryteria modyfikowalności — przez względy jego pielęgnacji i tak dalej. Nawetjeśli pewne kryteria wyraźnie górują nad innymi pod względem priorytetu, zupełneignorowanie tych o niższym priorytecie może równać się ignorowaniu interesów jed-nej lub kilku negocjujących stron.

Postrzeganie realizacji projektu w kategoriach negocjacji uwydatnia jego aspekt spo-łeczny. Programiści są przecież ludźmi, a zatem — poza oczywistym nastawieniem technicz-nym — prezentują określony stosunek emocjonalny do poszczególnych ewentualności roz-wiązania określonego problemu. Przekłada się to w prostej linii na interpersonalne relacjemiędzy programistami i stanowić może genezę rozmaitych konfliktów natury osobistej. Spro-wadzenie zagadnienia do obiektywnego, czysto technicznego wymiaru — co osiągnąć możnawłaśnie dzięki ich modelowaniu — zdecydowanie sprzyja łagodzeniu opisanego zjawiska.

Przykładem tak ukierunkowanego modelu jest WinWin — narzędzie wspomagającezbieranie wymagań i ułatwiające negocjowanie stron prezentujących odmienne punktywidzenia, które w swej pracy opisali B. Boehm, A. Egyed, J. Kwan, D. Port, A. Shah i R. Ma-dachy [Boehm i in., 1998]. U podstaw jego powstania legła znana prawda, iż warunkiem ko-niecznym pomyślności w realizacji projektu jest zadowolenie jego głównych uczestników.Często bowiem postęp w negocjacjach uwarunkowany jest nie tyle rozstrzyganiem kom-promisów między negocjującymi stronami, ile właśnie rozpoznaniem kryteriów przyjmowa-nych przez negocjujące strony. Jawność wszystkich wspomnianych kryteriów ułatwia rozpo-znawanie konfliktów między nimi i poszukiwanie kompromisowych rozwiązań.

WinWin wykorzystuje model podobny do QOC (patrz rysunek 12.19), od którego różnisię uporządkowaniem węzłów w hierarchie taksonomii. Oryginalne węzły kryteriów modeluQOC tutaj nazywane są „warunkami zwycięstwa” (Win Condition) i reprezentują kryteriasukcesu poszczególnych stron negocjacji. Zgodnie z modelem, proces rozpoczyna się od zi-dentyfikowania głównych „graczy” i ich „warunków zwycięstwa”; skonfliktowane ze sobą„warunki zwycięstwa” modelowane są w postaci zagadnień. Gdy osiągnięte zostanie poro-zumienie (Agreement), jest ono wprowadzane do bazy WinWin i kojarzone ze wspomnianymiwarunkami. Ułatwia to wypracowywanie i dokumentowanie osiągniętych kompromisów.

12.5.5. Strategie rozwi�zywania konfliktów

Niestety, czasami zdarza się tak, że wypracowanie kompromisu w negocjacjach okazuje sięnieosiągalne. W takiej sytuacji trzeba sięgnąć po określone strategie rozwiązywania konflik-tów. Najgorszymi bowiem decyzjami projektowymi są te, które nie zostały podjęte wskutek


Rysunek 12.19. Model zagadnień systemu WinWin

braku porozumienia i braku wspomnianych strategii. Odkładanie istotnych decyzji na póź-niejsze fazy projektu może wiązać się z kolosalnymi nawet kosztami zmian w projekcie i ko-lekcjonowania kryjącej się za nimi racjonalizacji.

Spośród wielu istniejących strategii rozwiązywania konfliktów ograniczymy się do pię-ciu poniższych.

� Większość ma rację. Głosowanie na zasadzie „decyduje większość” może przełamaćimpas i przyczynić się do podjęcia decyzji. Rozmaite narzędzia wspomagające współ-pracę grupową umożliwiają przypisanie wag istotności poszczególnym argumentomw modelu zagadnień i wyłonienie „zwycięskiej” propozycji na podstawie formułyarytmetycznej, o czy można przeczytać w pracy M.Purvisa, M. Purvis i P. Jonesa[Purvis i in., 1996]. Zakłada się przy tym równouprawnienie wszystkich dyskutan-tów i statystyczne oczekiwanie, że grupa zwykle podejmuje właściwe decyzje.

� Właściciel ma ostatnie słowo. Zgodnie z tą strategią rozstrzygający głos należy do„właściciela” zagadnienia, czyli osoby, która je sformułowała.

� Menedżer ma zawsze rację. Ta strategia jest szczególnie przydatna w warunkachhierarchicznej organizacji projektu: gdy grupa nie potrafi wypracować konsensusu,jej menedżer narzuca swą decyzję, wypracowaną na podstawie argumentów pre-zentowanych przez członków tej grupy. Zakłada się tu, że menedżer jest w stanienależycie zrozumieć wspomniane argumenty.

� Ekspert ma zawsze rację. W ramach tej strategii rozstrzygnięcia dokonuje niezależnyekspert, niezaangażowany w debatę, na podstawie oceny sytuacji i swego doświad-czenia. Przykładowo na etapie analizy wymagań ekspertem takim może być testującyużytkownik, któremu prezentuje się poszczególne propozycje rozwiązania zagad-nienia. Wadą tej strategii jest fakt, że ów ekspert może mieć nikłą wiedzę na tematinnych zagadnień i generalnie na temat kontekstu dyskutowanego zagadnienia.

� Niech czas zdecyduje. Gdy dane zagadnienie pozostaje nierozwiązane, upływającyczas wywiera coraz większą presję na znalezienie rozstrzygnięcia i podjęcie decyzji.Wraz z upływem czasu mogą pojawić się nowe okoliczności — zdefiniowanie nowych


aspektów systemu czy podjęcie ważnych decyzji — które znacznie ułatwią rozwiąza-nie patowego dotąd problemu. Niebezpieczeństwem tej strategii jest zagrożenie, iżwymusza ona podejmowanie decyzji krótkowzrocznych, optymalizujących kryteriakrótkoterminowe — na przykład łatwość implementacji — a ignoruje cele daleko-siężne, takie jak modyfikowalność i pielęgnowalność.

Strategie „Większość ma rację” i „Właściciel ma ostatnie słowo” są najgorszymi z moż-liwych, bowiem oznaczają ignorowanie racji sporej (być może) liczby uczestników. Strategie„Menedżer ma zawsze rację” i „Ekspert ma zawsze rację” prowadzą do lepszego rezultatu, podwarunkiem wszakże, iż menedżer (ekspert) ma wystarczającą wiedzę na temat problemu bę-dącego przedmiotem sporu. Strategia „Niech czas zdecyduje” oznacza tymczasową ucieczkęod problemu, na dłuższą metę niosącą ryzyko kosztownych przeróbek.

W praktyce najpierw należy dążyć do osiągnięcia konsensusu. Gdy dążenia okazują siębezowocne, należy pozostawić decyzję menedżerowi lub ekspertowi. Gdy ci nie potrafią do-konać właściwego wyboru, pozostaje głosowanie jako ostateczność.

12.6. Literatura uzupe�niaj�caWiększość prac związanych z modelowaniem zagadnień ma swe źródło w publikacji W. Kunzai H. Rittela [Kunz i Rittel, 1970], choć opisuje ona wykorzystywanie modelu IBIS w kontekścienegocjowania złożonych problemów politycznych. Zastosowanie modelu IBIS na gruncieinżynierii oprogramowania nastąpiło w późnych latach 80. ubiegłego stulecia, w postacinarzędzia gIBIS, omówionego w pracy J. Conklina i K. C. Burgessa-Yakemovica [Conklini Burgess-Yakemovic, 1991], a wykorzystywanego z powodzeniem w przemyśle do wieluanaliz przypadków. Narzędzie gIBIS stało się też punktem wyjścia dla innego (komercyjnego)narzędzia QuestMap, wykorzystywanego do kolekcjonowania i strukturalizowania racjonali-zacji w czasie zebrań.

Na początku lat 90. ubiegłego wieku alternatywą IBIS dla stał się QOC, koncentrującysię na systematycznym wartościowaniu propozycji według przyjętych kryteriów (zamiastokazjonalnie formułowanych argumentów), o czy piszą A. MacLean, R. M. Young, V. Bellottii T. Moran [MacLean i in., 1991]. Oba modele podzieliły odtąd rynek i IBIS wykorzystywanyjest w kontekście racjonalizacji gromadzonej „w locie”, podczas gdy QOC jest bardziej przy-datny do długofalowego reprezentowania informacji związanej z racjonalizacją.

W literaturze przedmiotu spotyka się niewiele przykładów zastosowania racjonalizacjiw tworzeniu oprogramowania — do nielicznych należą książki T. P. Morana i J. M. Carrolla[Moran i Carroll, 1996] oraz A. H. Dutoita, R. McCalla, I. Mistrika i B. Peacha [Dutoit i in.,2006]. Efektywne wykorzystywanie racjonalizacji w procesie tworzenia oprogramowania jesttrudnym zadaniem ze względów zarówno technicznych (modele racjonalizacji są obszerne,trudne w zarządzaniu i wykorzystywaniu), jak i pozatechnicznych — kolekcjonowanie racjo-nalizacji wiąże się z wysiłkiem, którego beneficjantami stają się głównie inne osoby, o czympiszą A. H. Dutoit i B. Paech [Dutoit i Paech, 2001]. Istnieją jednak liczne fakty, ilustrującewyjątkowe znaczenie gromadzenia i integrowania racjonalizacji dla powodzenia rozmaitychprzedsięwzięć. W tym rozdziale ograniczyliśmy się do trzech narzędzi wspierających stosowa-nie racjonalizacji w inżynierii oprogramowania: WinWin [Boehm i in., 1998], NFR Frame-work [Chung i in., 1999] i REQuest [Dutoit i Paech, 2002].

12.7. wiczenia 593

12.7. wiczenia12.1. W sekcji 12.3 omawialiśmy zagadnienie związane z kontrolą dostępu i powiada-

mianiem w systemie CTC. Podaj przykład innego zagadnienia, jakie może wyniknąćw związku z tworzeniem takiego systemu, przedstaw możliwe propozycje, kryteriai argumenty. Zaproponuj oraz uzasadnij rozstrzygnięcie. Oto dwa możliwe przykładywspomnianych zagadnień:� Jak zapewnić spójność między serwerem głównym (mainServer) a zapasowym

(hotBackup)?� Jak wykrywane będą awarie serwera głównego i jak zaimplementowane będzie

przejęcie pracy przez serwer zapasowy?12.2. Wyobraź sobie, że tworzysz program narzędziowy wspomagający modelowanie

w języku UML i postanowiłeś ściśle zintegrować zarządzanie racjonalizacją z innymimechanizmami modelowania. Opisz, w jaki sposób programista wykorzystującyTwoje narzędzie kojarzył będzie zagadnienia z innymi elementami modelu. Narysujdiagram klas przedstawiający model zagadnień i wspomniane skojarzenia.

12.3. Poniższy fragment jest wyjątkiem dokumentu SDD dla systemu FRIEND opisującymw języku naturalnym racjonalizację decyzji wyboru relacyjnej bazy danych jako ma-gazynu przechowywania obiektów trwałych. Narysuj model zagadnień obejmującyzagadnienia, propozycje, argumenty i kryteria zawarte w tym opisie (podobnie jakuczyniliśmy to w sekcji 12.3).

Jednym z fundamentalnych problemów przy projektowaniu podsystemu przechowywania danychjest wybór silnika bazodanowego. Początkowo jedno z wymagań pozafunkcyjnych nakazywałoużycie w tej roli obiektowej bazy danych, jako alternatywę wymieniono natomiast relacyjną bazędanych, „płaskie” pliki oraz kombinację tych dwóch mechanizmów. Obiektowa baza danych dajewymierne korzyści w postaci automatycznego zarządzania skomplikowanymi powiązaniamimiędzy przechowywanymi obiektami, jest jednak mało wydajna w stosunku do dużych rozmia-rów danych i częstych operacji wyszukiwania, poza tym dostępne obecnie produkty tej kategoriinie integrują się dobrze z mechanizmem CORBA, ze względu na brak wsparcia cech specyficz-nych dla niektórych języków programowania, między innymi skojarzeń w języku Java. Relacyjnebazy danych oferują rozwiązanie bardziej niezawodne, bardziej wydajne, a także większy wybórproduktów i większe wsparcie w postaci licznych narzędzi. Ponadto relacyjne bazy danych integrująsię bezproblemowo z mechanizmem CORBA. Relacyjne bazy danych nie zapewniają jednakbezpośredniego wsparcia dla implementacji skomplikowanych powiązań między danymi. Za-proponowano także specjalne potraktowanie danych tworzonych jednorazowo i odczytywanychbardzo rzadko, lecz koniecznych do przechowywania przez dłuższy czas — na przykład odczy-tów wskazań czujników, nagrywanych rozmów czy migawek z kamer: ze względu na skąpe po-wiązania tych danych z innymi elementami najbardziej odpowiednim mechanizmem ich prze-chowywania byłyby niezależne pliki, zdolne przechowywać niejednorodne dane dużychrozmiarów i łatwo poddające się archiwizowaniu. System niezależnych plików wymagałby jed-nak napisania „od zera” wszelkiego kodu związanego z zarządzaniem ich zawartością, w tymkodu odpowiedzialnego za serializację danych i szeregowanie dostępu. Ostatecznie wybraliśmyrelacyjną bazę danych, bazując na wymaganiach związanych z mechanizmem CORBA i stosun-kowo prostym charakterem powiązań między elementami przechowywanych danych.


12.4. Narysuj model QOC równoważny grafowi celów frameworku NFR z rysunku 12.12.Przedyskutuj wady i zalety zastosowania QOC i NFR dla reprezentowania racjonali-zacji w procesie zbierania i analizowania wymagań.

12.5. Wyobraź sobie, że integrujesz system raportowania błędów z narzędziem zarządzaniakonfiguracją w celu śledzenia wykrywanych błędów, ich poprawiania, żądania nowychcech i rozszerzeń. Integrację tę chcesz zrealizować za pomocą modelu zagadnień.Narysuj diagram klas tego modelu, uwzględniający elementy zarządzania konfiguracją,elementy raportowania błędów i dyskusje związane z tymi elementami.

Bibliografia[Boehm i in., 1998] B. Boehm, A. Egyed, J. Kwan, D. Port, A. Shah, R. Madachy

Using the WinWin spiral model: A case study, „IEEE Computer”31(7): str. 33 – 44, 1998.

[Chung i in., 1999] L. Chung, B. A. Nixon, E. Yu, J. Mylopoulos Non-FunctionalRequirements in Software Engineering, Kluwer Academic,Boston, 1999.

[Conklin i Burgess-Yakemovic, 1991] J. Conklin, K. C. Burgess-Yakemovic A process-orientedapproach to design rationale, „Human-Computer Interaction”,t.6, str. 357 – 391, 1991.

[Dutoit i Paech, 2001] A.H. Dutoit, B. Paech „Rationale management in softwareengineering” w: S. K. Chang (red.) Handbook of SoftwareEngineering and Knowledge Engineering, t.1, WorldScientific Publishing, 2001.

[Dutoit i Paech, 2002] A. H. Dutoit, B. Paech Rationale-based use casespecification, „Requirements Engineering Journal”, 7(1):str. 3 – 19, 2002.

[Dutoit i in., 2006] A. H. Dutoit, R. McCall, I. Mistrik, B. Paech (red.) RationaleManagement in Software Engineering, Springer,Heidelberg, 2006.

[Fisher i in., 1991] R. Fisher, W. Ury, B. Patton Dochodząc do TAK.Negocjowanie bez poddawania się, Polskie WydawnictwoEkonomiczne, Warszawa, 2000.

[Kunz i Rittel, 1970] W. Kunz, H. Rittel „Issues as elements of informationsystems”, Working Paper Nr 131, Institut für Grundlagender Plannung, Universität Stuttgart, Germany, 1970.

[Lee, 1990] J. Lee „A qualitative decision management system” w: P. H.Winston, S. Shellard (red.) Artificial Intelligence at MIT:Expanding Frontiers, t.1, str. 104 – 133, MIT Press, Cambridge,MA, 1990.

[MacLean i in., 1991] A. MacLean, R. M. Young, V. Bellotti, T. Moran „Questions,options, and criteria: Elements of design space analysis”,„Human-Computer Interaction”, t.6, str. 201 – 250, 1991.

[Moran i Carroll, 1996] T. P. Moran, J. M. Carroll (red.) Design Rationale: Concepts,Techniques, and Use, Lawrence Erlbaum Associates,Mahwah, NJ, 1996.

Bibliografia 595

[Purvis i in., 1996] M. Purvis, M. Purvis, P. Jones „A group collaboration toolfor software engineering projects”, Conference proceedingsof Software Engineering: Education and Practice (SEEP’96),Dunedin, NZ, styczeń 1996.

@see, 429«boundary», 106«control», 106, 216«create», 224«entity», 106«extent», 106«include», 106«invariant», 408«postcondition», 408«precondition», 408«sut», 540«testCase», 540«testComponent», 540«testContext», 540«testObjective», 540

AAbstract Factory, 772Abstract Window Toolkit, 276abstrakcyjne typy danych, 72action items, 561, 646activities, 640, 646activity-centered, 685Ada, 606adaptacyjne tworzenie oprogramowania, 737Adapter, 365, 366, 371, 773

delegowanie, 373dziedziczenie, 373

Adaptive Software Development, 737adaptowalność, 162agenda przeglądu klienckiego, 131agenda spotkania, 142agile, 637, 673Agile Alliance Manifesto, 737agregacja, 92, 231

agregacja współdzielona, 231kompozycyjna, 231

agregat CM, 602, 603agregat zarządzania konfiguracją, 602Airbus A320, 598akceptacja systemu, 672akcje, 99aktorzy, 79, 80

aktywności, 43, 47, 68, 100, 124, 640, 689partycje aktywności, 103

aktywności analizy wymagań, 217aktywności etapu projektowania systemu, 305aktywności inżynierii oprogramowania, 49

analiza, 51implementowanie, 53projekt systemu, 51projektowanie obiektów, 53testowanie, 54zbieranie wymagań, 50

aktywności klasycznego zarządzania projektem, 653aktywności organizacyjne, 146

dołączanie do infrastruktury komunikacyjnej, 146dołączanie do zespołu, 146udział w zebraniach zespołu, 147

aktywności projektowania systemu, 288, 303aktywności racjonalizacji, 567aktywności realizacji celów projektowych, 306aktywności specyfikowania interfejsów, 416aktywności zbierania wymagań, 166aktywności „zwinnej” realizacji projektu, 673aktywny przegląd projektu, 507ALAP, 650Albrecht A. J., 666alfa-testowanie, 530algorytm szyfrowania, 318alternatives, 551Ambler S., 739, 771analityczny model obiektowy, 64, 213, 214, 401analityk, 239analiza, 48, 49, 51, 212analiza opisu przypadków użycia, 219analiza wymagań, 159, 211, 236

aktywności, 217, 237analityczny model obiektowy, 214ARENA, 245cele, 212diagramy sekwencji, 224dokument analizy wymagań, 238dokumentowanie, 238identyfikacja agregacji, 231identyfikacja atrybutów, 232identyfikacja obiektów brzegowych, 220, 250identyfikacja obiektów encji, 218, 245

Skorowidz

848 Skorowidz

analiza wymagańidentyfikacja obiektów sterujących, 222, 251identyfikacja skojarzeń, 228iteracje modelu analitycznego, 241komunikacja, 240koncepcje, 214konsolidacja modelu analitycznego, 254model dynamiczny, 214modelowanie interakcji między obiektami, 228,

252modelowanie relacji dziedziczenia między

obiektami, 234modelowanie zachowania poszczególnych

obiektów uzależnionego od ich stanu, 233obiekty brzegowe, 215obiekty encji, 215obiekty sterujące, 215odwzorowywanie przypadków użycia w obiekty,

224przeglądy modelu analitycznego, 235przydzielanie odpowiedzialności, 239uzgodnienie modelu analitycznego z klientem,

243weryfikacja modelu analitycznego, 254zarządzanie analizą wymagań, 237

analiza zorientowana obiektowo, 76AND decomposition, 566Andres C., 485, 633, 725API, 123, 270, 357Application Programmer Interface, 270, 357arbiter, 540Arbiter, 540architecture-centric management, 655architekt, 239, 331architekt systemu, 123architektura, 266architektura czterowarstwowa, 286, 287architektura filtr-potok, 286architektura klient-serwer, 283, 284architektura MVC, 281architektura oprogramowania, 279, 296architektura otwarta, 275architektura P2P, 284architektura peer-to-peer, 284architektura repozytoryjna, 279, 280architektura SOA, 348architektura trójwarstwowa, 285architektura warstwowa, 268architektura zamknięta, 275ARENA, 57, 190, 245, 303

analiza wymagań, 245awarie, 346deklaracja problemu, 190odwzorowywanie modelu na kod, 478projektowanie systemu, 334specyfikowanie interfejsów, 433

statystyki systemu, 478wielokrotne wykorzystywanie rozwiązań

wzorcowych, 390wzorce projektowe, 390

argumentacja, 552arguments, 552argumenty, 559argumenty komunikatu, 95Ariane 501, 114ArrayList, 74artifact road map, 728As late as possible, 650As soon as possible, 650ASAP, 649, 650ASD, 737asSet(), 414asynchroniczna komunikacja grupowa, 145asynchroniczne kolekcjonowanie racjonalizacji, 577asynchroniczne mechanizmy komunikacyjne, 138,

140ATRACT, 743, 762

cel projektu, 743kontrola, 745modelowanie, 745planowanie, 744powtarzalność, 744procesy cyklu życiowego, 745projekt, 743środowisko projektu, 744wnioski, 746wynik, 745

atrybut klasy, 74atrybuty, 232, 247, 469audyt, 601audytor, 629automatyczne weryfikowanie spełnienia

kontraktów, 465automatyzacja testowania, 538awaria, 324, 325, 346, 494, 499, 500AWT, 276

BBabatunda A. O., 740Babich W. A., 602, 632bag, 413Baker P., 543ball, 271ball-and-socket, 270Baron J. T. T., 151baseline, 597Basic Support for Cooperative Work, 145Bass L., 297, 348baza danych, 311, 469

tabele, 469

Skorowidz 849

Beck K., 228, 258, 485, 633, 725Beedle M., 674, 678, 725benchmark test, 530Bersoff E. H., 602beta-testowanie, 526, 530bezpieczeństwo, 36, 162, 290, 568biblioteka, 603, 606biblioteka dynamiczna, 606biblioteka kontrolowana, 606biblioteka statyczna, 606biblioteki klas, 383bieżące kolekcjonowanie racjonalizacji, 553big-bang testing, 521Binder R. V., 542Birrer E. T., 382blackboard systems, 280blackbox tests, 504Blaha M., 311, 348, 449, 472blueprint, 46błąd roku 1900, 36błąd roku przestępnego, 36błędny stan, 494, 499, 500, 502błędy, 368, 494błędy w oprogramowaniu, 324BNF, 609Boehm B., 590, 669, 677, 687, 701Booch G., 107, 108, 162, 215, 703Borghoff U. W., 151Borning A., 440bottom-up testing, 521, 522brak klienta, 718breakage, 668Bridge, 368, 774Brooks F. P., 664, 678Brown W. J., 771Bruegge B., 382brygady tygrysów, 529BSCW, 145bucket theory of the mind, 41budowanie infrastruktury, 643budowanie wieloetapowe, 631budżet, 36bug, 494Burgess-Yakemovic K. C., 592buried association, 472burn down chart, 676burza mózgów, 133, 228, 241, 242, 333Buschmann F., 296, 394, 771

Ccache’owanie wyników czasochłonnych obliczeń, 457callback, 285, 383całościowe zarządzanie jakością, 740Campbell R. H., 382Capability Maturity Model, 632, 695

Carr M. J., 669Carroll J. M., 169, 205, 592CASE, 55, 452, 748Catalysis, 49cechy specyfikacji, 164cele analizy, 212cele projektowe systemu, 290cele testowania, 540Centralized Traffic Control, 555Champty J., 166change request, 602change set, 608chaordic system, 766Charette R. N., 669chief programmer organization, 679Christerson M., 107chroniona operacja, 405chroniony atrybut, 405chronometrażysta, 142Chung L., 565ciągi, 411, 413Class, Responsibilities i Collaborators, 228ClearCase, 610, 611Clements P., 297, 348CM aggregate, 602CMM, 695Cockburn A., 173, 206, 725, 737Cocoa, 378COCOMO II, 677, 727Cohn M., 677, 738Collection, 74Command, 775competitor testing, 530Composite, 776Computer Aided Software Engineering, 55Concurrent Version System, 611, 633configuration, 602configuration item, 602configuration management aggregate, 602Conklin J., 592consequent issues, 557Constantine L. L., 107, 206, 296continuus integration, 630Contract4J, 440CORBA, 276, 277, 283core use cases, 703correction, 499CRC, 228criteria, 552critical path, 649cross reference, 429CruiseControl, 631Crystal Clear, 737CTC, 555, 568

kontrola dostępu, 583opis systemu, 569

850 Skorowidz

Cunningham W., 228, 258Curtis B., 723CVS, 608, 609, 610, 611, 633cykl życiowy oprogramowania, 56, 637, 683, 686

aktywności, 689dojrzałość modeli, 695grupy procesów, 688IEEE 1074, 687, 688iteracyjne modele ukierunkowane na aktywności,

701modele, 685, 698modele ukierunkowane na aktywności, 685modele ukierunkowane na encje, 685, 706modelowanie cyklu życiowego, 690postrealizacja, 693prerealizacja, 691proces, 688procesy integralne, 694procesy międzyrealizacyjne, 694realizacja, 692sekwencyjne modele ukierunkowane

na aktywności, 699tworzenie systemu, 692ujęcie produktowe, 686zależności czasowe między aktywnościami, 686zarządzanie projektem, 690

cykle, 701, 703czas, 43czas przestoju, 649czas reakcji, 162czas trwania projektu, 719częstotliwość zmian, 719członkowie projektu, 116czynniki ryzyka, 670, 671czytelność modelu projektu systemu, 328

Ddane, 303dane trwałe, 309Dart S., 601dashboard, 631Date C. J., 469De Marco T., 107, 218dead reckoning, 684deadlock, 284debugowanie, 495, 496Decision Representation Language, 562, 564decisions, 552decyzje, 101, 120, 552decyzje implementacyjne, 72defekty, 494definiowanie

atrybuty, 236cele projektowe, 290

problem, 642projekt, 116projekt wysokopoziomowy, 656skojarzenia, 236wyjątki związane z naruszeniem kontraktów, 448zakres projektu, 643założenia kontroli dostępu, 312, 340

definiowany model kontroli procesów, 740deklaracja problemu, 129, 130, 642, 654, 655dekompozycja dysjunkcyjna, 566dekompozycja hierarchiczna, 275dekompozycja koniunkcyjna, 566dekompozycja systemu, 263, 269, 278, 295, 332, 401delegowanie, 359, 363delegowanie implementacji, 363delegowanie we wzorcach projektowych, 364deliverable, 640, 648delty, 608Deming E. W., 740demonstrowanie prototypów, 666dependability, 162design by contracts, 440diagramy aktywności, 68, 79, 101

decyzje, 101partycje aktywności, 103rozwidlenia, 102węzły kontrolne, 101zastosowania, 103złączenia, 102

diagramy De Marco, 72diagramy interakcji, 64, 67, 79, 95

argumenty, 95komunikaty, 95zastosowanie, 97

diagramy klas, 52, 64, 65, 78, 86, 255, 328agregacja, 92dziedziczenie, 93klasy, 87klasy skojarzeniowe, 88krotność skojarzenia, 89kwalifikowanie, 92łącza, 88metody, 94obiekty, 87operacje, 94redukcja krotności, 92role, 89skojarzenia, 88skojarzenia kwalifikowane, 92zastosowania, 94

diagramy komunikacyjne, 97, 282diagramy PERT, 532diagramy przypadków użycia, 64, 65, 78, 79

aktorzy, 79przypadki użycia, 79relacja dziedziczenia, 84

Skorowidz 851

relacja komunikacji, 82relacja rozszerzania, 83relacja zawierania, 82scenariusze, 85zależności komunikacyjne, 82

diagramy sekwencji, 52, 67, 224, 225, 228, 252diagramy sieciowe, 640, 649diagramy stanów, 67, 79, 98, 233

akcje, 99aktywności, 100przejście między stanami, 98przejście wewnętrzne, 100stan, 98zagnieżdżone maszyny stanów, 100zagnieżdżony stan, 100zastosowania, 101

diagramy UML, 43diagramy wdrażania, 304Dijkstra E. W., 296, 440Directory, 91dojrzałość modeli cyklu życiowego, 695dokładność, 162dokonywanie podziału pracy, 657dokument analizy wymagań, 188, 238

system obecnie użytkowany, 189system proponowany, 189wprowadzenie, 188

dokument projektu obiektów, 402, 425, 428budowanie, 426interfejsy klas, 429pakiety, 429utrzymywanie materiału źródłowego, 431wstęp, 428

dokument projektu systemu, 328, 329architektura istniejącego systemu, 329model projektu nowego systemu, 329usługi oferowane przez podsystemy, 330wprowadzenie, 329

dokument RAD, 238dokument SDD, 328dokument umowy projektu, 642dokumentacja powtarzalnego rozwiązania, 388dokumentalista techniczny, 390, 432dokumentowanie

analiza wymagań, 238projektowanie obiektów, 425projekt systemu, 328racjonalizacje, 585testowanie, 532transformacje, 475wykorzystywanie gotowych rozwiązań, 388zarządzanie konfiguracją, 627zbieranie wymagań, 188

dołączanie do infrastruktury komunikacyjnej, 118,146

dołączanie do zespołu, 118, 146DOORS, 187doskonalenie przypadków użycia, 160, 173, 198dostarczenie systemu, 644dostępność, 162, 335, 568doświadczenie uczestników, 717Douglass B. P., 258Doyle M., 151DRL, 562, 564dry run, 150Dutoit A. H., 586, 592Duval P., 630dwukierunkowe skojarzenia „jeden do jednego”, 459dynamiczna kontrola dostępu, 317dynamiczne witryny WWW, 385dynamika zmian, 433dyskusja rozproszonych uczestników w czasie

rzeczywistym, 144dziedziczenie, 73, 93, 216, 359, 360

dziedziczenie implementacyjne, 360, 361, 362dziedziczenie interfejsu, 362dziedziczenie kontraktów, 424dziedziczenie specyfikacyjne, 360, 362dziedziczenie we wzorcach projektowych, 364subklasy, 93superklasy, 93

dziedzina aplikacyjna, 76, 130dziedzina realizacyjna, 76

Eearned value, 667egoless programming, 679, 732egzemplarze, 72Eiffel, 440, 465ekspert komponentu, 389Ekspert ma zawsze rację, 591ekspert wzorca projektowego, 389ekstender klasy, 403elementy działania, 561, 646elementy konfiguracji, 602, 603elementy ryzyka, 669Elssamadisy A., 771e-mail, 140emisja, 117, 134, 602, 605, 616Engineering Change Proposal, 602engineering workflows, 704entity-centered, 685Erl T., 348Erman L. D., 280erroneous state, 494, 499error, 494error guessing, 512etap zbierania wymagań, 50ewentualności, 551

852 Skorowidz

ewolucja elementu konfiguracji, 608ExecuteTrip, 289exists(), 415eXtreme Programming, 485, 520, 526, 633, 725, 731

FFAA, 599Fabryka abstrakcyjna, 376, 390, 772

delegowanie, 376dziedziczenie, 376zastosowanie, 390

Facade, 777facilitator, 142Facilitator, 143Fagan M. E., 496, 541failure, 494, 499faks, 138falsyfikacja modeli, 77, 495Fasada, 295, 777FAT, 91fault, 494, 499Fayad M. E., 382faza definiowania projektu, 116Feature-Driven Design, 725Feiler P., 771Felsing J., 725field tests, 530Files, 91filtrowanie pakietów, 316filtry, 286Finish no earlier than, 650Finish no later than, 650firewall, 315Fisher R., 151, 589flat staffing, 664Flower M., 108Floyd R. W., 440fly-by-wire, 598FNET, 650FNLT, 650follproof, 496forAll(), 415foreign key, 470formowanie zespołów, 643, 663formularz formalizujący żądanie zmiany, 138formułowanie ograniczeń, 423forward engineering, 427, 452, 706Fowler M., 394, 450, 457, 737, 771Frames, 394framework, 383, 384

frameworki aplikacyjne, 381, 382frameworki białoskrzynkowe, 382frameworki czarnoskrzynkowe, 383frameworki infrastrukturalne, 382

frameworki pośredniczące, 382NFR, 565

Freeman-Benson B., 440FRIEND, 79, 167, 743, 746, 762

aktywności cyklu życiowego projektu, 751cel projektu, 746dokumenty systemowe, 749iteracje, 753kontrola, 750modelowanie, 748planowanie, 747powtarzalność, 747procesy cyklu życiowego, 750scenariusze, 170środowisko projektu, 747wnioski, 753wynik, 752zespoły funkcyjne, 750

funkcje projektowe, 646FURPS, 162FURPS+, 162

GGaffney J. E. Jr., 666gałęzie, 607Gamma E., 283, 295, 308, 394, 771Garlan D., 296generalizacja, 216, 234, 360generowanie dokumentu ODD, 428gIBIS, 592Gladwin T., 719Gleick J., 766globalna tabela dostępu, 314globalny przepływ sterowania, 319, 341Glover A., 630główny architekt, 432, 477gniazda TCP/IP, 276gniazdo, 270Goldberg A., 394gra planistyczna, 733gradual staffing, 664graf PERT, 126graf przepływów, 513graficzne reguły reprezentowania widoków, 71graniczne przypadki użycia, 323Grenning J., 677, 738grep, 287groupware, 577, 578grupa procesów, 688grupa produktów, 640grupowanie klas, 105grupowanie przypadków użycia, 104grupy dyskusyjne, 140Guttag J., 440

Skorowidz 853

HHalstead M. H., 666Hammer M., 166Hamu D. S., 382Harel D., 98harmonogram, 115, 126, 640, 646

graf PERT, 126ścieżka krytyczna PERT, 127wykres Gantta, 126

harmonogram przeglądów, 118, 150HashMap, 74Hayes-Roth F., 280HEARSAY II, 280Helm R., 283Henderson V. D., 602hermetyzacja algorytmów, 780hermetyzacja hierarchii, 378hermetyzacja kontekstu, 373hermetyzacja kosztownych obiektów, 779hermetyzacja niekompatybilnych komponentów, 371hermetyzacja platformy, 376, 772hermetyzacja podsystemów, 295, 777hermetyzacja przechowywania danych, 368hermetyzacja przepływu sterowania, 377, 775heurystyki Abbotta, 218heurystyki identyfikowania wzorców projektowych,

381heurystyki komunikowania racjonalizacji, 588heurystyki metodologiczne, 765heurystyki pisania przypadków użycia, 175heurystyki pisania scenariuszy, 175heurystyki pomocne w czytelnym formułowaniu

ograniczeń, 423heurystyki pomocne w grupowaniu obiektów

w podsystemy, 295heurystyki pomocne w identyfikowaniu atrybutów, 233heurystyki pomocne w identyfikowaniu obiektów, 181heurystyki pomocne w identyfikowaniu obiektów

brzegowych, 221heurystyki pomocne w identyfikowaniu obiektów

encji, 220heurystyki pomocne w identyfikowaniu obiektów

sterujących, 223heurystyki pomocne w identyfikowaniu skojarzeń, 230heurystyki pomocne w odwzorowywaniu naruszenia

kontraktów w wyjątki, 468

heurystyki weryfikowania kompletności zestawuprzypadków użycia, 182

heurystyki wspomagające rysowanie diagramówsekwencji, 227

heurystyki wspomagające zarządzanie gałęziami, 621heurystyki wyboru między relacjami zawierania

i rozszerzania, 179heurystyki wyboru wzorców projektowych, 379, 781

hierarchiczna organizacja projektu, 120Highsmith J., 725, 735, 737Hoare C. A. R., 440Hock D., 766Hofmeister C., 297hook methods, 382Hopper G. M., 541HTTP, 283, 384

IIBIS, 562, 563, 592iContract, 440, 468idealny tydzień, 733identyfikacja

agregacje, 231agregaty CM, 613aktorzy, 160, 167, 192atrybuty, 232cele projektowe, 290, 335elementy konfiguracji, 600, 613frameworki aplikacyjne, 381obiekty brzegowe, 220, 250obiekty encji, 218, 220, 245obiekty modelu analitycznego, 179obiekty sterujące, 222, 251obiekty trwałe, 310, 339podsystemy, 294, 336przypadki użycia, 160, 171, 195relacje, 198relacje między aktorami a przypadkami użycia, 176relacje między przypadkami użycia, 160scenariusze, 160, 169, 192skojarzenia, 228trwałe dane, 309umiejętności, 660usługi, 321, 343warunki graniczne, 323, 345wymagania pozafunkcyjne, 160, 182, 184, 204

identyfikatory wersji, 606identyfikowalna specyfikacja, 165identyfikowalność, 160, 187idiotoodporność, 496IEEE 1074, 687, 688, 698, 709implementator, 123, 403implementowanie, 53includes(), 414infrastruktura komunikacyjna, 118, 660inicjowanie projektu, 690Inline Class Refactoring, 457inspection, 495inspekcja kodu, 132, 495, 666inspekcja komponentu, 506, 507inspekcja problemu, 117instalowanie systemu, 644, 672

854 Skorowidz

instancja klasy, 74instancje aktorów uczestniczących, 86int, 72integracja ciągła, 630, 633integrowanie, 553

integrowanie pionowe, 521, 525integrowanie poziome, 521

interakcje między uczestnikami projektu, 120interdyscyplinarność, 22interfejs API, 123interfejs podsystemów, 270interfejs programisty, 270, 357interfejs użytkownika, 378interfejs wzorca, 365interfejsy, 285, 399internacjonalizacja, 162internal work products, 648intersection(), 414inv:, 415inżynier API, 123inżynieria, 35inżynieria interfejsu, 165inżynieria odwracająca, 427, 449, 452, 706inżynieria oprogramowania, 35, 38, 266, 716

aktywności, 49koncepcje, 43modelowanie, 38, 39niepowodzenia, 36pozyskiwanie wiedzy, 38, 41proces sterowany racjonalizacją, 38racjonalizacja, 42rozwiązywanie problemów, 38, 40

inżynieria pierwotna, 165inżynieria postępująca, 427, 448, 452, 706inżynieria wahadłowa, 706inżynieria wtórna, 165inżynieria wymagań, 157inżynierskie przepływy pracy, 704Islam N., 382issue, 551Issue-Based Information System, 562, 563issue-based life cycle model, 707iteracje modelu analitycznego, 241

burza mózgów, 242dojrzewanie, 242ustalanie, 242

iteracje projektowania systemu, 333iteracyjne modele ukierunkowane na aktywności, 701

jednolity proces wytwarzania oprogramowania,703

model spiralny, 701iteracyjne planowanie, 738

JJAA, 599Jacobson I., 107, 108, 162, 205, 215, 709JAD, 160, 185

agenda sesji, 185badania, 185definiowanie projektu, 185dokument końcowy, 185przygotowania, 185sesja, 185słownik menedżera, 185wstępna specyfikacja, 185wywiady, 185

JAMES, 136, 743, 754, 762aktywności, 757cel projektu, 754iteracje, 756kontrola, 759modelowanie, 756planowanie, 755powtarzalność, 756procesy cyklu życiowego, 757środowisko projektu, 755wnioski, 760wynik, 760

Java, 72, 258, 269klasy abstrakcyjne, 74

Java RMI, 276, 283JavaCard, 758Javadoc, 429, 440jContractor, 440jeden do jednego, 90jeden na wiele, 90jednokierunkowe skojarzenia „jeden do jednego”, 459jednolity proces, 532, 725jednolity proces wytwarzania oprogramowania, 703jednostki pracy, 640jednoznaczność specyfikacji, 164Jensen R. W., 687język

Ada, 606Eiffel, 440Java, 72język z wbudowaną kontrolą typów danych, 72OCL, 107, 359, 407SQL, 470UML, 43, 63, 64

Johnson R., 283Joint Application Design, 160, 185Jones T. C., 496Jonsson P., 107JUnit, 538, 539

Skorowidz 855

Kkamienie milowe, 117, 118, 665karty CRC, 228, 258karty inteligentne, 754katalog główny, 603, 606katastrofa Ariane, 114katastrofa Challengera, 638Katzenbach J. R., 677Kay A., 394Kayser T. A., 151, 662Kelly J. F., 740Kemerer C. F., 624Key Process Areas, 696kierownicze aspekty zarządzania konfiguracją, 627klasy, 65, 73, 86, 268

atrybuty, 74, 232dziedziczenie, 73, 93ekstender, 403implementator, 403instancja, 74operacje, 74użytkownik, 403

klasy abstrakcyjne, 73klasy bazowe, 360klasy bezpośrednio powiązane, 412klasy implementacyjne, 366klasy klienckie, 365, 403klasy pochodne, 360klasy powiązane pośrednio, 412klasy rozszerzające, 367klasy skojarzeniowe, 88, 89, 464klasy zdarzeniowe, 75klasyczne zarządzanie projektem, 653Klepp A., 407klient, 124, 239, 283klient pełnomocnik, 718klient prezentacji, 286klient-serwer, 283, 284klimat technologiczny, 718klucze główne, 470klucze kandydackie, 470klucze obce, 470kluczowe obszary procesu, 696know-how, 722Knuth D. E., 607kolapsacja, 456kolekcje, 413kolekcje OCL, 411kolekcjonowanie racjonalizacji, 562, 569komentarze Javadoc, 429, 440komisja, 119kompletność modelu, 235kompletność modelu projektu systemu, 327kompletność specyfikacji, 164komponenty, 306, 384

komponenty fizyczne, 269komponenty logiczne, 269komponenty testowe, 540Kompozyt, 378, 379, 776kompromisy projektowe, 293komunikacja, 22, 55, 79, 113, 117

analiza wymagań, 240emisje, 117inspekcja problemu, 117mechanizmy, 138projektowanie systemu, 331przeglądy klienckie, 117przeglądy partnerskie, 117przeglądy projektowe, 117rozwiązywanie problemów, 117zdarzenia nieprzewidywalne, 117zdarzenia przewidywalne, 117zebrania statusowe, 117żądanie wyjaśnień, 117żądanie zmian, 117

komunikacja między uczestnikami, 432komunikacja partnerska, 122komunikacja planowa, 118, 128, 139

burza mózgów, 133deklaracja problemu, 129emisje, 134przeglądy klienckie, 131przeglądy partnerskie, 132przeglądy post mortem, 134przeglądy projektowe, 132przeglądy statusowe, 133

komunikacja pozaplanowa, 118, 135, 136rozwiązywanie problemów, 137żądanie wyjaśnień, 136żądanie zmian, 137

komunikatory, 140komunikaty, 75, 76, 94, 95

argumenty, 95komunikowanie, 120koncepcja wielokrotnego wykorzystania, 359koncepcje komunikacyjne projektu, 128koncepcje organizacyjne projektu, 119koncepcje zbierania wymagań, 161konfiguracja, 602, 604konfiguracja oprogramowania, 56konfiguracja sprzętowa, 306konfiguracyjne przypadki użycia, 345konflikty, 620, 623konserwacja systemu, 54konsolidacja modelu, 236konsolidacja modelu analitycznego, 254konsultanci, 124kontakt z użytkownikami, 718kontekst testowania, 540kontrakty, 406kontrola dostępu, 304, 312, 340

856 Skorowidz

kontrola projektu, 644, 665, 675demonstrowanie prototypów, 666inspekcje kodu, 666kamienie milowe, 665metryki, 666przeglądy projektu, 666zarządzanie ryzykiem, 669zebrania, 665

kontrola zmian, 601kontroler, 281, 629konwersacja okazjonalna, 140kończenie pracy systemu, 345kończenie projektu, 671, 677

akceptacja systemu, 672instalowanie systemu, 672refleksje post mortem, 673

koszty operacyjne, 335kółko-gniazdo, 271KPA, 696Kramer R., 440, 468Kraut R. E., 151krotki, 311krotność skojarzenia, 89Kruchten P., 709krystaliczną czystość, 737kryteria, 552kryteria kosztowe, 291kryteria pewności działania, 291kryteria pielęgnowalności, 292kryteria użytkownika, 292kryteria wydajności, 291Kunz W., 562, 592kursy projektowania, 26kursy technologiczne, 26kursy wprowadzające, 26kwalifikowanie, 92kwantyfikatory OCL, 415kwestionariusze, 140, 141

LLarman C., 258, 766, 771Leveson N. G., 348liczebność zespołów, 662light weight, 737light-headed, 737linia bazowa, 189, 597, 604LinkedList, 74Liskov B., 440listy kontroli dostępu, 314listy uprawnień, 314lizak, 271, 321local king client, 717Lockwood L. A. D., 206logika aplikacji, 285lokalne atrybuty, 412

lokalny klient samodzielny, 717lollipop, 271Lotus Notes, 140

Łłatwość utrzymania, 162łącza, 88łącznik, 121, 123łącznik architektoniczny, 331, 432, 477

Mmacierz kontroli dostępu, 314macierz kwalifikacji, 650Mack R. L., 542MacLean A., 592magazynowanie danych, 285Malveau R. C., 771mapa artefaktów, 728mapy stanów, 98Martin J., 394master directory, 603maszyna stanu, 98Matyas S., 630Mayhew D. J., 543McCabe T., 666mean time between failures, 162mechanizm odwołania zwrotnego, 285mechanizmy komunikacyjne, 138

asynchroniczne, 138synchroniczne, 138, 140

menedżer konfiguracji, 124, 240, 331, 390, 432, 629Menedżer ma zawsze rację, 591menedżer projektu, 637, 722metamodel dziedziczenia, 362metoda Fagana, 507metoda Joint Application Design, 185metodologia Royce’a, 48, 725

artefakty, 727cechy, 725dojrzałość procesów, 729doświadczenie dziedzinowe, 729elastyczność procesów, 729elementy, 726kontrola, 730mapa artefaktów, 728metryki jakościowe, 730metryki menedżerskie, 730modelowanie, 727planowanie, 726powtarzalność, 727procesy cyklu życiowego, 728ryzyko architektoniczne, 729skala projektu, 728spójność udziałowców, 729

Skorowidz 857

metodologia rugby, 737iteracyjne planowanie, 738kontrola, 741modelowanie, 739planowanie, 738powtarzalność, 739procesy cyklu życiowego, 740

metodologie, 48, 713, 717, 719, 724Boocha, 48Catalysis, 49kontrola, 723metodologia jednolitego procesu, 49modelowanie, 721monitorowanie, 723OMT, 48planowanie, 719powtarzalność, 720procesy cyklu życiowego, 723przedefiniowanie celów projektu, 724Scrum, 674, 737XP, 731

metody, 48, 94, 717metody zahaczane, 382metryki, 666Meyer B., 440MFO, 650miara dobroci, 559miary dojrzałości, 668miary kondycji finansowej projektu, 667miary modularności, 668miary postępu technicznego, 668miary stabilności, 668middleware, 276, 355, 359, 384, 571, 744mierniki ilościowe, 666minimalizacja ryzyka, 672Minsky Marvin, 394misja STS-51L, 638mistrz, 674, 675model, 43, 46, 69, 70, 281, 721

archiwizowanie, 722komunikowanie, 721projektowanie, 721

model analityczny, 94, 213, 214, 455, 705model analityczny systemu planowania podróży, 288model bazarowy, 619model cyklu życiowego oprogramowania, 685, 689,

698model dojrzałości organizacyjnej, 695model dynamiczny, 64, 213, 214model dziedziny aplikacyjnej, 77model funkcjonalny, 64, 213model FURPS, 162model FURPS+, 162model implementacji, 705model kaskadowy, 42, 699, 708model maszyny stanów UML, 98

model menedżerski, 640model obiektowy, 64model OMT, 748model OSI-ISO, 276, 277model projektu obiektów, 64model projektu systemu, 327, 705model przypadków użycia, 705model racjonalizacji, 585model sekwencyjny, 687model spiralny, 701model systemu, 69model testowania, 498, 705model ukierunkowany na aktywności, 685model ukierunkowany na encje, 685, 706

zagadnieniowy model cyklu życiowego, 707model zadań, 640, 646, 649model „zębaty”, 709modelowanie, 38, 39, 69, 70, 721

język UML, 63modelowanie cyklu życiowego, 690modelowanie interakcji między obiektami, 228, 252modelowanie relacji dziedziczenia między

obiektami, 234modelowanie systemów nierealistycznych, 39modelowanie zachowania poszczególnych obiektów

uzależnionego od ich stanu, 233modelowanie zorientowane obiektowo, 76Model-View-Controller, 258, 281model-widok-kontroler, 258, 281Modula 2, 269modyfikacja planów projektu, 644modyfikowalność, 290Moran T. P., 592Most, 368, 774


Mowbray T. J., 771MSO, 649, 650MTBF, 162, 668MUE, 607Must finish on, 650Must start on, 650MVC, 258, 281My UML Editor, 607Myers G. J., 512, 542MyTrip, 307, 308, 313, 323, 325

Nnadklasy, 73nadużycie interfejsu, 36namiastka testowa, 499, 505narzędzia, 717narzędzia komunikacji grupowej, 144narzędzia wspomagające zarządzanie konfiguracją, 610

858 Skorowidz

nauka, 38nauki o sztuczności, 39nauki przyrodnicze, 38nauki społeczne, 38nawigacja, 88nawigacja polinezyjska, 684nazwy

przypadki użycia, 80scenariusze, 85

negocjowanie specyfikacji z klientem, 185Netmeeting, 144network diagram, 649Neumann P., 59NFR, 562, 565, 592

cele realizacyjne, 566dekompozycja, 565

niby-klient, 718Niech czas zdecyduje, 591niejednoznaczności, 212Nielden J., 542niepowodzenia w inżynierii oprogramowania, 36niezawodność, 162, 290, 494niezawodność oprogramowania, 494, 495niezawodny system, 325niezmienniki, 406NIH, 387no client, 718Nonaka I., 677, 737Norman D. A., 206, 740Not Invented Here, 387notacja, 48, 71notacja Backusa-Naura, 609notacja Boocha, 64notacja kółko-gniazdo, 270, 271notacja kropkowa, 408notacja OMT, 64notacja OOSE, 64notacja UML, 63notatki, 105nowe technologie, 367nowe widoki, 368nowi dostawcy, 367numery wersji, 606

Oobiekt uczestniczący, 67obiektowa baza danych, 311obiektowy model projektu systemu, 64obiekty, 73, 74, 86

operacje, 94przejście między stanami, 98stan, 98

obiekty aplikacyjne, 359obiekty brzegowe, 215, 220, 342

obiekty encji, 215, 218, 342obiekty modelu analitycznego, 179obiekty projektu, 125obiekty proxy, 308obiekty realizacyjne, 359obiekty sterujące, 215, 342obiekty trwałe, 125, 310obiekty uczestniczące, 181Object Constraint Language, 107, 359, 407Object Design Document, 402, 425Object Modeling Technique, 48, 64Object-Oriented Software Engineering, 64obsada stopniowana, 664Observer, 778Obserwator, 283, 390, 778

zastosowanie, 393obsługa sytuacji wyjątkowych, 324OCL, 107, 359, 407

exists(), 415forAll(), 415kolekcje, 411, 413kontrakty, 421kwantyfikatory, 415niezmienniki, 421odwołania do atrybutów, 414ograniczenia, 408operacje kolekcji, 414warunki końcowe, 409warunki wstępne, 408

ODD, 402, 425, 534, 748oddzielenie encji od widoków, 778Odell J. J., 394odporność na awarie, 290odwołania skrośne, 429odwołania zwrotne, 285odwzorowanie kontraktów w wyjątki, 465, 482odwzorowanie modeli klas w schematy

przechowywania danych, 448odwzorowanie modelu na kod, 445

aktywności, 454ARENA, 478cele, 447dokumentowanie transformacji, 475inżynieria odwracająca, 449, 452inżynieria postępująca, 448, 452koncepcje, 448odwzorowywanie kontraktów w wyjątki, 465, 482odwzorowywanie modelu obiektowego w schemat

bazy danych, 469, 484odwzorowywanie skojarzeń na kolekcje, 458, 480optymalizacja modelu, 447, 455przydzielanie odpowiedzialności, 477refaktoryzacja kodu, 448, 450transformacja modelu, 448, 449, 453zarządzanie transformacjami, 475zasady transformacji, 453

Skorowidz 859

odwzorowanie modelu obiektowego w schematybazy danych, 469, 484

odwzorowanie klas i atrybutów, 470odwzorowanie pionowe, 473odwzorowanie poziome, 475odwzorowanie relacji dziedziczenia, 473odwzorowanie skojarzeń, 472skryte powiązania, 472tabela pośrednicząca, 472tabela skojarzeniowa, 472

odwzorowanie oprogramowania w konkretny sprzęt,303

odwzorowanie pionowe, 473odwzorowanie podsystemów w procesory

i komponenty, 306, 337odwzorowanie poziome, 473, 475odwzorowanie przypadków użycia w obiekty, 224odwzorowanie skojarzeń na kolekcje, 458, 480ogół-szczegóły, 217ograniczenia, 106, 107, 163ograniczenia ASAP, 649ograniczenia czasowe, 649, 650ograniczenia MFO, 649ograniczoność zasobów, 22okno projektowe, 334okresowe zebrania statusowe, 665OMT, 48, 64, 748

analiza, 48projekt obiektów, 48projektowanie systemu, 48

OMTool, 748OOPSLA, 258OOSE, 64, 166operacje, 74, 94opóźnianie kosztownych obliczeń, 457oprogramowanie, 35oprogramowanie pośrednie, 355, 359, 384optymalizacja modelu, 357optymalizacja modelu obiektowego, 353, 455optymalizacja ścieżek dostępu, 455OR decomposition, 566organizacja diagramów, 104organizacja głównego programisty, 679organizacja łącznikowa, 122organizacja projektu, 113, 119organizacja przeglądów, 149organizacja zespołowa, 119organization chart, 640organizowanie projektu, 659, 675

formowanie zespołów, 663identyfikacja umiejętności, 660podpisanie umowy projektu, 664przydzielanie ról technicznych, 661przypisywanie ról menedżerskich, 661ustanowienie infrastruktury komunikacyjnej, 660wybór liczebności zespołów, 662

wyrównywanie braku kwalifikacji, 662zebranie otwierające, 664

Orr O., 736OSI-ISO, 276otoczka dla starszego kodu, 773Overgaard G., 107OWL, 130, 669

PP2P, 284, 285package, 405Paech B., 586, 592pakiet, 126pakietowa operacja, 405pakietowy atrybut, 405pakiety, 104

grupowanie klas, 105grupowanie przypadków użycia, 104

pakiety pracy, 640, 646Palmer S., 725Parnas D., 296, 507participants, 640Partsch H., 485partycje, 275partycje aktywności, 103partycjonowanie, 268, 278partycjonowanie aktywności, 103Paulish D. J., 677Paulk M. C., 695, 723peer-to-peer, 284PEM, 130percepcja dwustabilna, 212Perforce, 610, 611Personal Environment Module, 130PERT, 126, 532Petroski H., 739, 766pewność działania, 162piłka, 271Plan testów, 125, 497, 533, 534Plan Zarządzania Konfiguracją Oprogramowania,

627, 628aktywności, 628harmonogram, 628konserwacja planu, 628wstęp, 628zarządzanie, 628zasoby, 628

Plan Zarządzania Projektem, 651, 654, 690Planning Poker, 677, 738planowanie, 719planowanie projektu, 654, 674

deklaracja problemu, 654, 655Plan Zarządzania Projektem, 654podział pracy, 657projekt wysokopoziomowy, 656

860 Skorowidz

planowanie projektuSPMP, 654tworzenie początkowego harmonogramu, 659wysokopoziomowy projekt systemu, 654

planowanie testów, 497, 532PlanTrip, 288platforma sprzętowa, 306pliki, 311pluskwy, 494płaska obsada, 664początkowa identyfikacja obiektów modelu

analitycznego, 179początkowy harmonogram, 659podejście rugby, 737podejście zorientowane obiektowo, 40podklasy, 73podmiana implementacji, 774podpisanie umowy projektu, 664podsystemy, 70, 267, 268, 294podtypowanie, 363pojedynczy projekt, 623poker planistyczny, 738Polecenie, 377, 390, 775

delegowanie, 378dziedziczenie, 378zastosowanie, 392

polimorfizm, 517pomocnicze przepływy pracy, 704Popper K., 41, 59, 495poprawki, 499, 505poprawność modelu projektu systemu, 327poprawność specyfikacji, 164Portny S. E., 677post mortem, 644, 673post:, 409postrealizacja, 693potencjalnie dostarczalne przyrosty produktu, 674potentially deliverable product increment, 674Poter A. A., 496potoki, 286powtarzalna architektura, 720powtarzane trawersowanie skojarzeń, 455poziomy dojrzałości organizacji cyklu życiowego, 695pozyskiwanie wiedzy, 38, 41, 42praca, 640praca grupowa, 577prawa dostępu, 313pre:, 408Premerlani W., 311, 348, 449, 472prerealizacja, 691primary key, 470priorytety funkcja systemu, 243priorytetyzacja czynników ryzyka, 671private, 405Problem Statement, 642, 655problemy z oprogramowaniem, 37

problemy z użytecznością, 158proces, 688proces falsyfikacji, 78proces jednolity, 703proces przetwarzania wymagań, 689proces rewizyjny, 244proces sterowany racjonalizacją, 38procesor, 306procesy cyklu życiowego, 723procesy integralne, 694procesy międzyrealizacyjne, 694product backlog, 674product owner, 675produkt, 43, 46, 115, 124, 640, 646produkt docelowy, 46, 115produkt finalny, 640, 648produkt wewnętrzny, 46, 125, 648profile, 539programista, 477, 629programowanie bezosobowe, 679, 732programowanie ekstremalne, 485, 520, 633, 725, 731

aktywności, 734Częste integrowanie, 735emisje systemu, 733gra planistyczna, 733idealny tydzień, 733kontrola, 735modelowanie, 734Najpierw testy, 734partner, 732planowanie, 732powtarzalność, 734procesy cyklu życiowego, 734Programowanie parami, 735prowadzący, 732Refaktoryzacja przed rozszerzeniem, 735system samoorganizujący się, 735szybkość projektu, 733testy, 734Testy dla każdej nowej usterki, 735zasady, 732

programowanie sterowane problemami, 42programowanie sterowane ryzykiem, 42programowanie wielowątkowości, 321Project Agreement, 642, 664project functions, 646project kick off meeting, 674project velocity, 733projekt, 43, 56, 113, 115

członkowie, 116faza definiowania projektu, 116faza startowa, 117faza terminalna, 117faza ustalona, 117harmonogram, 115, 126interakcje między uczestnikami projektu, 120

Skorowidz 861

komunikacja, 117komunikacja planowa, 128komunikacja pozaplanowa, 135koncepcje komunikacyjne, 128koncepcje organizacyjne, 119organizacja hierarchiczna, 120organizacja projektów, 119organizacja zespołowa, 119produkt, 115, 124realizacja, 116role, 122struktura łącznikowa, 121, 122uczestnicy, 116zadanie, 116, 124zespoły, 119

projekt mieszkania, 264projekt obiektów, 48, 49projekt systemu, 51projekt systemu informatycznego, 37projekt wysokopoziomowy, 656projekt XP, 743projektant obiektów, 123, 432projektowanie, 49, 721projektowanie globalnego przepływu sterowania, 319,

341projektowanie niezawodnych systemów, 325projektowanie obiektów, 53, 353, 355

aktywności, 356ARENA, 390biblioteki klas, 383delegowanie, 363dokumentowanie wykorzystania gotowych

rozwiązań, 388dziedziczenie implementacyjne, 360dziedziczenie specyfikacyjne, 360elementy, 353gotowe komponenty, 356, 367hermetyzacja hierarchii, 378hermetyzacja kontekstu, 373hermetyzacja niekompatybilnych

komponentów, 371hermetyzacja platformy, 376hermetyzacja przechowywania danych, 368hermetyzacja przepływu sterowania, 377heurystyki wyboru wzorców projektowych, 379identyfikacja frameworków aplikacyjnych, 381komponenty, 384obiekty aplikacyjne, 359obiekty realizacyjne, 359optymalizacja modelu, 357przydzielanie odpowiedzialności, 389przystosowywanie frameworków

aplikacyjnych, 381restrukturyzacja modelu, 357specyfikowanie interfejsów, 357, 399wielokrotne wykorzystanie, 359

wybór wzorców projektowych, 367wzorce projektowe, 356, 364zarządzanie projektowaniem obiektów, 425zarządzanie wykorzystywaniem gotowych

rozwiązań, 386zasada zastępowania Liskov, 364

projektowanie sterowane cechami, 725projektowanie sterowane odpowiedzialnością, 166projektowanie systemu, 48, 49, 51, 263, 266, 305, 552

aktywności, 288architektura programowa, 267architektura warstwowa, 268ARENA, 334cele projektowe, 267definiowanie celów projektowych, 290dokumentowanie, 328doskonalenie dekompozycji stosownie do celów

projektowych, 263graniczne przypadki użycia, 267hermetyzacja podsystemów, 295identyfikacja celów projektowych, 290identyfikacja podsystemów, 294interfejsy podsystemów, 270interfejsy programisty, 270iteracje, 333klasy, 268kompromisy projektowe, 293komunikacja, 331koncepcje, 267kryteria kosztowe, 291kryteria pewności działania, 291kryteria pielęgnowalności, 292kryteria użytkownika, 292kryteria wydajności, 291odwzorowanie podsystemów w procesory

i komponenty, 337partycje, 275partycjonowanie, 268podsystemy, 267, 268projektowanie wstępnej dekompozycji, 263rozpoznawanie celów projektowych, 263spoistość, 267, 271, 272sprzężenie, 267, 271style architektoniczne, 279usługi, 267, 270warstwy, 275zarządzanie projektowaniem systemu, 328

projektowanie za pomocą kontraktów, 440promocja, 602, 605, 615promotion, 602propozycja, 557protected, 405protokolant, 142, 587protokół z zebrania, 143, 144prototyp interfejsu użytkownika, 509prototyp pionowy, 334, 509

862 Skorowidz

prototyp poziomy, 334, 509prototyp z krainy Oz, 509prototypowanie, 77, 78prototypy, 666proxy, 308Proxy, 308, 457, 779proxy client, 718prywatna operacja, 405prywatny atrybut, 405przebiegi, 674przechowywanie danych, 309, 311, 339przeczuwanie błędów, 512przedefiniowanie celów projektu, 724przeglądy, 495

przeglądy klienckie, 117, 131, 149przeglądy modelu analitycznego, 235przeglądy partnerskie, 117, 132przeglądy post mortem, 134przeglądy projektu, 117, 132, 666przeglądy przebiegów, 677przeglądy statusowe, 133

przejście między stanami, 98przejście wewnętrzne, 100przenośność, 162przepływ sterowania, 304, 319, 341przepływ zdarzeń, 80, 86przepływy pracy, 704przepustowość, 162przestrzeń robocza, 606przewidywalne zdarzenia komunikacyjne, 128przydział programistów do projektu, 664przydzielanie obiektów i podsystemów do węzłów,

307przydzielanie odpowiedzialności, 239, 330, 389, 431przydzielanie ról technicznych, 661przypadki testowe, 499, 503, 540przypadki użycia, 51, 79, 81, 171

aktorzy, 80doskonalenie, 173identyfikacja, 171nazwa, 80przepływ zdarzeń, 80przypadki użycia dla sytuacji wyjątkowych, 346warunki końcowe, 80warunki wstępne, 80wymagania jakościowe, 80zależności komunikacyjne, 82

przypisywanie ról menedżerskich, 661przyrosty, 608przystosowywanie frameworków aplikacyjnych, 381pseudo-client, 718pseudowymagania, 163public, 405publiczna klasa, 405publiczny atrybut, 405Pull Up Constructor Body, 450

Pull Up Field, 450Pull Up Method, 450Purvis M., 591

QQOC, 562, 564, 590, 592Questions, Options, and Criteria, 562, 564QuestMap, 592

Rracjonalizacja, 42, 55, 549, 551, 579

aktywności, 567argumentacja, 552argumenty, 559, 570aspekty kierownicze, 585bieżące kolekcjonowanie racjonalizacji, 553CTC, 568Decision Representation Language, 564decyzje, 552definiowanie problemów, 556dokumentowanie, 585DRL, 564eksploracja przestrzeni rozwiązań, 557elementy działania, 561ewentualności, 551heurystyki komunikowania, 588IBIS, 563implementacja rozstrzygnięć, 561Issue-Based Information System, 563kolapsacja przestrzeni rozwiązań, 560kolekcjonowanie asynchroniczne, 577kolekcjonowanie racjonalizacji, 553, 562, 569koncepcje, 554kryteria, 552, 559, 570modele racjonalizacji, 585modelowanie zagadnień, 589negocjowanie zagadnień, 589NFR, 565propozycja, 557, 570protokolant, 587przypisywanie odpowiedzialności, 587QOC, 564Questions, Options, and Criteria, 564redaktor racjonalizacji, 586, 587rekonstruowanie racjonalizacji, 553, 582rozstrzygnięcie, 560strategie rozwiązywania konfliktów, 590wartościowanie elementów przestrzeni

rozwiązań, 559weryfikator racjonalizacji, 587zagadnienie, 551, 556zintegrowanie racjonalizacji z modelami

systemu, 553

Skorowidz 863

racjonalizowanie zmian, 506RAD, 188, 206, 238, 534, 748Raport zdarzeń testowych, 533, 535raportowanie, 120raportowanie statusu, 601Rational Unified Process, 709rationale, 549Ray W. H., 740RCS, 610, 633rdzenne przypadki użycia, 703realistyczna specyfikacja, 165realistyczność modelu, 236, 327realizacja celów projektowych, 301, 306

aktywności, 306realizacja projektu, 116realizacja skojarzeń, 448redaktor dokumentacji, 123, 239, 331redaktor racjonalizacji, 586, 587redukcja krotności, 92redukcja obiektów do atrybutów, 456redukcja złożoności modelu, 82, 84redundancja, 302refaktoryzacja kodu, 448, 450, 485

wchłonięcie klasy, 457wciągnięcie metod, 450, 451wciągnięcie pola, 450wciągnięcie treści konstruktora, 450, 451

refleksje post mortem, 673Rehabilitation Act, 163reingeenering, 166reinżynieria, 166rekonstruowanie racjonalizacji, 553, 582rekurencyjna reprezentacja hierarchii, 776relacja dziedziczenia, 84relacja komunikacji, 82relacja między aktorami a przypadkami użycia, 176relacja ogół-szczegół, 217relacja rozszerzania, 83, 180relacja rozszerzania między przypadkami użycia, 176relacja zawierania, 82, 180relacja zawierania między przypadkami użycia, 177relacje, 469relacyjne bazy danych, 311, 469release, 602release candidate, 525reliability, 494Remote Procedure Call, 283ReportEmergency, 81, 219repository, 603repozytorium, 279, 603, 606REQuest, 586, 592Requirements Analysis Document, 188, 238RequisitePro, 187resolution, 560responsibility-driven design, 166restrukturyzacja modelu, 353, 357

reverse engineering, 427, 452, 706review, 495Revision Control System, 610, 633Ritchie D. M., 287Rittel H., 562, 592Robson D. J., 516Rochkind M. J., 632role, 44, 45, 89, 640, 646role menedżerskie, 661role międzyfunkcyjne, 123role programistyczne, 123role techniczne, 661role w realizacji projektu, 122role zarządcze, 122round-trip engineering, 706Rowen R. B., 709Royce W., 532, 677, 687, 699, 725rozbudowywanie infrastruktury komunikacyjnej, 118rozmowy telefoniczne, 140rozpoczynanie pracy systemu, 345rozpoznawanie kwalifikacji, 643rozproszenie geograficzne, 718rozstrzygnięcie, 560rozszerzalność, 363rozszerzenia diagramów, 106rozwiązywanie problemów, 21, 38, 40, 117, 137, 138rozwidlenia, 102różnice między zawieraniem a rozszerzaniem, 178RPC, 283Rubin E., 212Rubin J., 509, 542rugby, 737Rumbaugh J., 107, 108, 162, 215, 455, 485rundy, 701ryzyko, 669

Ssamoloty pasażerskie, 598sandwich testing, 521, 522SatWatch, 161, 163, 187sawtooth model, 709scalanie gałęzi, 620SCCS, 632scenariusze, 85, 130, 171

instancje aktorów uczestniczących, 86nazwy, 85przepływ zdarzeń, 86scenariusz bieżący, 169scenariusz ewaluacyjny, 170scenariusz treningowy, 170scenariusz wizjonerski, 169

scenopis rysunkowy, 509schedule, 646Scheduler, 540

864 Skorowidz

schemat bazy danych, 311schemat identyfikowania wersji, 606schemat organizacyjny, 640schematy, 469Schlichter J., 151Schwaber K., 674, 677, 725sciences of the artificial, 39SCMP, 627Scrum, 674, 677, 725, 737, 739

dni robocze, 675kontrola projektu, 675kończenie projektu, 677mistrz, 674, 675organizowanie projektu, 675planowanie projektu, 674potencjalnie dostarczalne przyrosty produktu, 674przebiegi, 674przeglądy przebiegów, 677role, 675schemat ogólny, 678właściciel produktu, 675wykresy wygaszania, 675zebranie planistyczne, 674zebranie startowe, 674zebranie statusowe, 675zespół, 675

Scrum master, 675Scrum of Scrums, 766Scrum team, 675SDD, 328, 534, 748sekcja 508 ustawy Rehabilitation Act, 163sekwencje abstrakcyjne, 96sekwencyjne modele ukierunkowane

na aktywności, 699model kaskadowy, 699V-Model, 700

select(), 414self, 408sequence, 413Service Oriented Architecture, 348serwer, 283serwer prezentacji, 286sesja JAD, 185sesje treningowe, 118set, 413sformułowanie problemu, 129shadow testing, 531Shaw M., 296Siegel S. G., 602Siewiorek D. P., 348, 543Simon H., 39size, 414skalowalność, 335skill matrix, 650skojarzenia jeden do jednego, 459skojarzenia jeden na wiele, 461

skojarzenia kwalifikowane, 92, 463skojarzenia niekwalifikowane, 92skojarzenia wiele na wiele, 461skojarzenia wielokrotne, 455skojarzenie, 88, 229, 458

atrybuty, 229skryte powiązania, 472slack time, 649Smalltalk-80, 258smoke test, 632SNET, 650SNLT, 650SOA, 348socket, 270Software Configuration Management Plan, 627software library, 603software life cycle models, 685software life cycles, 637Software Project Management Plan, 642software reliability, 494solidność, 162sort, 287Source Code Control System, 632specjalista od zastosowań, 124specjalista z zakresu dziedziny aplikacyjnej, 124specjalista z zakresu dziedziny realizacyjnej, 124specjalizacja, 216, 217Specyfikacja przypadków testowych, 533, 534, 535specyfikacja usług, 353specyfikacja wymagań, 159, 164

identyfikowalność, 165jednoznaczność, 164kompletność, 164poprawność, 164realizm, 165spójność, 164weryfikowalność, 165

specyfikowanie interfejsów, 357, 399, 401, 403aktywności, 402, 416ARENA, 433brakujące atrybuty i operacje, 402definiowanie sygnatur, 402definiowanie widzialności, 402dziedziczenie kontraktów, 424ekstender klasy, 403identyfikacja brakujących atrybutów, 417identyfikacja brakujących operacji, 417, 434implementator klasy, 403język OCL, 407kolekcje OCL, 411kontrakty, 406kwantyfikatory OCL, 415specyfikowanie kontraktów, 402, 435, 438specyfikowanie niezmienników, 421specyfikowanie sygnatur, 418specyfikowanie typów, 418

Skorowidz 865

specyfikowanie warunków końcowych, 419specyfikowanie warunków wstępnych, 419specyfikowanie widzialności, 418sygnatury, 403, 404typy, 403użytkownik klasy, 403widzialność, 403, 405zarządzanie projektowaniem obiektów, 425

specyfikowanie niezmienników, 421SPMP, 642, 652, 654, 655, 690spoistość, 267, 271, 272spotkania osobiste, 140, 141spójność modelu, 235, 327spójność specyfikacji, 164sprint backlog, 674sprzęt, 43sprzężenie, 267, 271SQL, 471staged build, 631stan obiektu, 98standard cykli życiowych, 688stany realizacji projektu, 116Start no earlier than, 650Start no later than, 650statecharts, 98statyczna polityka dostępu, 316stereotypy, 106, 216

«boundary», 106«control», 106, 216«entity», 106«extent», 106«include», 106«invariant», 408«postcondition», 408«precondition», 408«sut», 540«testCase», 540«testComponent», 540«testContext», 540«testObjective», 540

sterowanie proceduralne, 319sterowanie wielowątkowe, 320sterowanie zdarzeniowe, 319sterownik testowy, 499, 505storyboard, 509Strategia, 373, 518, 780


strategia przechowywania danych, 311strategia przechowywania obiektów trwałych, 340strategia zrównoleglonych projektów, 624strategie integrowania pionowego, 525strategie integrowania poziomego, 521strategie minimalizowania ryzyka, 672strategie rozwiązywania konfliktów, 590Strategy, 780

Straus D., 151Streeter L. A., 151struktura łącznikowa, 121, 122struktura podziału pracy, 640, 646, 648, 657struktura raportowania organizacji, 120strukturalizowane wywiady, 140STS-51L, 638style architektoniczne, 279subklasy, 73, 93, 360subtelna kontrola, 741subtle control, 741Suchman L. A., 719, 720suchy przebieg, 150superklasy, 73, 93, 360supporting workflows, 704Sutherland J., 677Swarz R. S., 348, 543swimlanes, 103Swing, 258, 276, 378Switzer J., 151SYBIL, 564sygnały dymne, 138sygnatury, 404synchroniczna komunikacja grupowa, 140synchroniczny mechanizm komunikacyjny, 138, 140syndrom „to nie nasz wynalazek”, 387syndrom Y2K, 551system, 43, 46, 69system ARENA, 57, 190, 245system centralnego sterowania ruchem, 555system chaordyczny, 766system CVS, 608System Design Document, 328system informatyczny, 35, 37system komputerowy promu kosmicznego, 302system plików, 91system samoorganizujący się, 735system sztuczny, 39system tablicowy, 280system under test, 540system wysokiej jakości, 382sytuacje wyjątkowe, 346szablon dokumentu RAD, 206szkolenia, 662szybkość projektu, 733szyfrowanie, 318szyfrowanie informacji, 313

Śścieżka krytyczna, 649ścieżka krytyczna PERT, 127ścisłe dziedziczenie, 364śledzenie problemów, 506średni czas pracy między awariami, 162, 668

866 Skorowidz

środowisko projektu, 716, 717, 744czas trwania projektu, 719częstotliwość zmian, 719doświadczenie uczestników, 717klimat technologiczny, 718kontakt z użytkownikami, 718rozproszenie geograficzne, 718typ klienta, 717

środowisko testowe, 539

TT.H.E., 296tabela pośrednicząca, 472tabela skojarzeniowa, 472tabele, 469Takeuchi H., 677, 737taksonomiczna identyfikacja ryzyka, 669task, 640, 646task model, 649Taxonomy-Based Risk Identification, 669Taylor F., 719, 740TCS, 535teoria umysłu pojemnika, 41Test Case Specification, 535test driver, 499test harness, 539Test Incident Report, 535Test Plan, 497test stub, 499TestCase, 503, 538tester, 123, 124testing, 494testowanie, 54, 491, 494, 496, 553

aktywności, 497, 506automatyzacja, 538awaria, 499, 500błędny stan, 499, 500dokumentowanie, 532inspekcja komponentu, 506, 507JUnit, 538koncepcje, 498namiastka testowa, 499, 505Plan testów, 533, 534, 536planowanie testów, 497, 532poprawki, 499, 505profile, 539Przydzielanie odpowiedzialności, 536przypadki testowe, 499, 503Raport podsumowujący, 533Raport sumaryczny, 535Raport zdarzeń testowych, 533, 535Specyfikacja przypadków testowych, 533, 534, 535sterownik testowy, 499, 505środowisko testowe, 539TCS, 535

TestCase, 503, 538testowanie akceptacyjne, 497, 526, 644testowanie bazujące na modelach, 539testowanie funkcjonalności, 497, 526testowanie graniczne, 511testowanie hurtowe, 521testowanie instalacji, 497, 526testowanie ręczne, 538testowanie kanapkowe, 521, 522testowanie modułów, 510testowanie pilotażowe, 526, 530testowanie polimorfizmu, 517testowanie regresyjne, 506, 537testowanie rywala, 530testowanie sterowane stanami, 516testowanie strukturalne, 497testowanie systemu, 497, 506, 526testowanie ścieżek, 512testowanie użyteczności, 497, 506, 508testowanie w cieniu, 530testowanie wahadłowców, 492testowanie wstępujące, 521, 522testowanie wydajności, 497, 526, 528testowanie wymaganiowe, 526testowanie zstępujące, 521, 522, 523testowany komponent, 498testy białoskrzynkowe, 504testy czarnoskrzynkowe, 504TIR, 535U2TP, 539uprząż testowa, 539usterki, 499, 500zarządzanie testowaniem, 531

testowanie integracyjne, 497, 506, 519, 520strategie integrowania pionowego, 525strategie integrowania poziomego, 521

testowanie jednostkowe, 497, 506, 510graf przepływów, 513pokrycie, 510reprezentatywność, 511rozłączność, 511testowanie graniczne, 511testowanie polimorfizmu, 517testowanie ścieżek, 512testowe klasy równoważności, 510

testowany komponent, 498testowany system, 540testowe klasy równoważności, 510testy akceptacyjne, 530testy bezpieczeństwa, 529testy białoskrzynkowe, 504testy czarnoskrzynkowe, 504testy dubletowe, 520testy dwójkowe, 520testy instalacyjne, 531testy kwadrupletowe, 520

Skorowidz 867

testy na dym, 632testy objętościowe, 529testy odtwarzania, 530testy pilotażowe, 530testy polowe, 530testy produktu, 509testy prototypu, 509testy przeciążeniowe, 529testy regresyjne, 537testy scenariusza, 508testy tripletowe, 520testy uwarunkowań czasowych, 529testy wzorcowe, 530TEX, 607tępe zliczanie, 684ThingLab, 440Thompson K., 287Tichy W., 633, 771TicketDistributor, 44

aktywności, 47dekompozycja systemu, 53model dynamiczny systemu, 51, 52model obiektowy systemu, 52produkty, 46przypadki użycia, 51PurchaseOneWayTicket, 51role, 45zadania, 47zasoby, 47

TIR, 535tolerowanie usterek, 495Tonies C. C., 687top-down testing, 521, 522tory pływackie, 103Total Quality Management, 740TP, 497TQM, 740transformacja modelu, 447, 448, 449

dokumentowanie, 475zarządzanie transformacjami, 475zasady, 453

trwałe dane, 303, 309Turner C. D., 516tworzenie oprogramowania, 54tworzenie systemu, 692typ klienta, 717typed languages, 72typy atrybutów, 404typy danych, 72

UU2TP, 539, 540uczestnicy, 43, 44, 116, 640udział w zebraniach zespołu, 147

UML, 21, 43, 63, 64, 65, 78, 607diagramy aktywności, 68, 79, 101diagramy interakcji, 64, 67, 79, 95diagramy klas, 64, 65, 78, 86diagramy przypadków użycia, 64, 65, 78, 79diagramy sekwencji, 67diagramy stanów, 67, 79, 98diagramy wdrażania, 304dziedziczenie, 93klasy, 75komponenty fizyczne, 269komponenty logiczne, 269krotność, 90maszyna stanu, 98model dynamiczny, 64model funkcjonalny, 64model obiektowy, 64modelowanie, 63notacja, 71notatki, 105obiekty, 74ograniczenia, 106organizacja diagramów, 104pakiety, 104rozszerzenia diagramów, 106skojarzenia, 88stereotypy, 106tory pływackie, 103U2TP, 539widzialność elementu, 406

UML 2 Testing Profile, 539umowa projektu, 642, 664Unified Modeling Language, 48Unified Process, 162, 532, 703, 725Unified Software Development Process, 49, 166, 703unikanie usterek, 495union(), 414unit testing, 510Universal Modeling Language, 21, 43, 63UNIX, 287uprząż testowa, 539URPS, 163uruchamianie na sucho, 150uruchamianie projektu, 643usługi, 267, 270, 321, 343usterki, 494, 499, 500usterki maszyny wirtualnej, 502usterki wykryte podczas inspekcji kodu, 125usterki wykryte podczas testowania, 125utrzymanie systemu, 54uwierzytelnianie, 313, 317uzgodnienie modelu analitycznego z klientem, 243uzgodnienie umowy projektu, 642użyteczność, 158, 162, 568użytkownik, 124, 239użytkownik klasy, 403

868 Skorowidz

Vvaporware, 37variants, 602verdict, 540version, 602Vlissides J., 283V-model, 687, 699, 700VMS, 632Vodde B., 766

Wwaga lekka, 737walkthrough, 495warianty, 602, 604, 623Warmer J., 407warstwy, 275wartość wypracowana, 667warunki graniczne, 304, 323, 345warunki końcowe, 80, 406, 419warunki wstępne, 80, 406, 419waterfall model, 699WBS, 646, 648, 657wchłonięcie klasy, 457wciągnięcie metod, 450, 451wciągnięcie pola, 450wciągnięcie treści konstruktora, 450, 451Weber C. V., 723WebifyWatch, 167WebObjects, 384Weinand A., 382Weinberg G. M., 732wersje, 602, 604weryfikacja modelu analitycznego, 254weryfikacja projektu systemu, 326weryfikator, 240, 331weryfikator racjonalizacji, 587weryfikowalna specyfikacja, 165weryfikowalne cechy specyfikacji, 164wędrówka po kodzie, 132, 495węzły kontrolne, 101whitebox tests, 504wideokonferencje, 140widok, 69, 281, 368widzialność, 405wiele na wiele, 90wielokrotne wykorzystywanie frameworków, 721wielokrotne wykorzystywanie rozwiązań

wzorcowych, 353, 359ARENA, 390biblioteki klas, 383delegowanie, 363dokumentowanie wykorzystania gotowych

rozwiązań, 388

dziedziczenie implementacyjne, 360dziedziczenie specyfikacyjne, 360frameworki aplikacyjne, 381obiekty aplikacyjne, 359obiekty realizacyjne, 359przydzielanie odpowiedzialności, 389wzorce projektowe, 364, 383zarządzanie wykorzystywaniem gotowych

rozwiązań, 386zasada zastępowania Liskov, 364

wielowątkowość, 321wielozbiory, 411, 413Większość ma rację, 591Wigand R. T., 679WinWin, 590, 592Władca Pierścieni, 446Właściciel ma ostatnie słowo, 591właściciel produktu, 675Work Breakdown Structure, 640, 646work packages, 640, 646work product, 640work units, 640workflows, 704wpadki produkcyjne, 354wspieralność, 162wspinaczka wysokogórska, 716współdzielenie kodu między warianty, 624wstępna deklaracja problemu, 190wstępne definiowanie architektury systemu, 642wstępne zaplanowanie zarządzania projektem, 642Wstępny Plan Zarządzania Projektem

Programistycznym, 642WWW, 140wybór konfiguracji sprzętowej, 306wybór liczebności zespołów, 662wybór platformy, 306wybór strategii przechowywania danych, 311wybór strategii przechowywania obiektów trwałych,

340wydajność, 162wykaz zaległości produktu, 674wykaz zaległości przebiegu, 674wykorzystywanie gotowych rozwiązań, 353, 386wykres Gantta, 126wykresy wygaszania, 676wykrywanie usterek, 495wymagania, 157

wymagania dotyczące interfejsu, 163wymagania funkcyjne, 48, 161, 191wymagania implementacyjne, 163wymagania jakościowe, 80, 163wymagania operacyjne, 163wymagania pakietowe, 163wymagania pozafunkcyjne, 48, 162, 163, 182, 191,

205wymagania prawne, 163

Skorowidz 869

wyraziste kamienie milowe, 665wyrównywanie braku kwalifikacji, 662wysokopoziomowy projekt systemu, 654wystąpienia, 72wysyłanie komunikatu, 75, 95wywiady strukturalne, 141wzorce projektowe, 359, 364, 383, 402, 721, 771

Abstract Factory, 772Adapter, 365, 366, 371, 773Bridge, 774Command, 775Composite, 776delegowanie, 364dziedziczenie, 364Fabryka abstrakcyjna, 376, 390, 772Facade, 777Fasada, 295, 777hermetyzacja algorytmów, 780hermetyzacja hierarchii, 378hermetyzacja kontekstu, 373hermetyzacja kosztownych obiektów, 779hermetyzacja platformy, 376, 772hermetyzacja podsystemów, 777hermetyzacja przechowywania danych, 368hermetyzacja przepływu sterowania, 377, 775heurystyki pomocne w wyborze wzorców

projektowych, 781heurystyki wyboru wzorców projektowych, 379Kompozyt, 378, 776Most, 368, 774Observer, 778Obserwator, 283, 393, 778oddzielenie encji od widoków, 778otoczka dla starszego kodu, 773podmiana implementacji, 774Polecenie, 377, 392, 775Proxy, 308, 457, 779rekurencyjna reprezentacja hierarchii, 776Strategia, 373, 518, 780Strategy, 780wybór wzorców projektowych, 367

XX11, 276, 278XP, 725, 731, 737

YYahoo Groups, 145Yourdon E., 107, 296

Zzachowanie obiektu, 67zachowanie systemu w kategoriach aktywności, 69zachowanie zewnętrzne, 79zadanie, 43, 44, 47, 116, 124, 640, 646

pakiet, 126specyfikacja prac, 126

zagadnienia, 551, 556, 707zagadnienia wynikowe, 557zagadnieniowy model cyklu życiowego, 707zagnieżdżone maszyny stanów, 100zagnieżdżony stan, 100założenia kontroli dostępu, 312, 340zamknięta architektura warstwowa, 277zamknięte zagadnienie, 707zapora sieciowa, 315zarządzanie analizą wymagań, 237zarządzanie cyklem życiowym, 683zarządzanie danymi, 303zarządzanie emisjami, 616zarządzanie gałęziami, 619zarządzanie generowaniem binariów, 601zarządzanie identyfikowalnością, 187zarządzanie jakością oprogramowania, 691zarządzanie konfiguracją, 56, 189, 597, 600

agregat CM, 602, 603agregat zarządzania konfiguracją, 602aktywności, 597, 600, 601, 611aspekty kierownicze, 627audyt, 601biblioteka, 603, 606ClearCase, 610, 611CVS, 610, 611dokumentowanie, 627elementy konfiguracji, 602, 603emisja, 602, 605ewolucja elementu konfiguracji, 608gałęzie, 607heurystyki wspomagające zarządzanie

gałęziami, 621identyfikacja agregatów CM, 613identyfikacja elementów konfiguracji, 600, 613identyfikatory wersji, 606integracja ciągła, 630katalog główny, 603koncepcje, 602konfiguracja, 604konflikty, 620, 623kontrola zmian, 601linia bazowa, 604narzędzia wspomagające zarządzanie

konfiguracją, 610numery wersji, 606Perforce, 610, 611

870 Skorowidz

zarządzanie konfiguracjąPlan Zarządzania Konfiguracją Oprogramowania,

627, 628planowanie aktywności, 629promocja, 602, 605przestrzeń robocza, 606przypisywanie odpowiedzialności, 628raportowanie statusu, 601RCS, 610repozytorium, 603, 606role, 629scalanie gałęzi, 620schematy identyfikowania wersji, 606SCMP, 627testowanie, 630warianty, 602, 604wersje, 602, 604współdzielenie kodu między warianty, 624zarządzanie emisjami, 616zarządzanie gałęziami, 619zarządzanie generowaniem binariów, 601zarządzanie procesem, 601zarządzanie promocjami, 615, 630zarządzanie propozycjami zmian, 626zarządzanie wariantami, 623zarządzanie zmianami, 626zbiory zmian, 608zmiany, 608żądanie zmiany, 602, 604

zarządzanie procesem, 601zarządzanie projektem, 54, 56, 552, 637, 639, 690

aktywności, 640, 641, 645, 646aktywności klasycznego zarządzania projektem,

653elementy działania, 646faza definicyjna, 642faza koncepcyjna, 642faza końcowa, 644faza startowa, 643faza ustalona, 643funkcje projektowe, 646harmonogram, 640, 646jednostki pracy, 640koncepcje, 646kontrola projektu, 641, 665kończenie projektu, 641, 671macierz kwalifikacji, 650model zadań, 640, 646, 649modele menedżerskie, 640organizowanie projektu, 641, 659pakiety pracy, 640, 646Plan Zarządzania Projektem, 651planowanie projektu, 641, 654praca, 640produkt, 640, 646produkt finalny, 640, 648

produkt wewnętrzny, 648role, 646SPMP, 642, 652struktura podziału pracy, 640, 646, 648uzgodnienie umowy projektu, 642WBS, 648Wstępny Plan Zarządzania Projektem

Programistycznym, 642wynik, 640zadanie, 640, 646zasoby, 640

zarządzanie projektowaniem obiektów, 425dokumentowanie projektowania obiektów, 425przydzielanie odpowiedzialności, 431wykorzystywanie kontraktów w analizie

wymagań, 432zarządzanie projektowaniem systemu, 328zarządzanie promocjami, 615zarządzanie propozycjami zmian, 626zarządzanie racjonalizacją, 55, 549

aspekty kierownicze, 585racjonalizacja, 551

zarządzanie ryzykiem, 644, 669zarządzanie scentralizowane architektonicznie, 655zarządzanie testowaniem, 531zarządzanie transformacjami, 475zarządzanie tworzeniem oprogramowania, 54

cykl życiowy oprogramowania, 56komunikacja, 55zarządzanie konfiguracją oprogramowania, 56zarządzanie projektem, 56zarządzanie racjonalizacją, 55

zarządzanie wariantami, 623zarządzanie wykorzystywaniem gotowych rozwiązań,

386zarządzanie zbieraniem wymagań, 183zarządzanie zmianami, 626zasada zastępowania Liskov, 364, 394zasoby, 43, 47, 640zastoje, 284zbieranie wymagań, 50, 65, 157, 159, 552

aktywności, 160, 166analiza wymagań, 159dokument analizy wymagań, 188dokumentowanie, 188doskonalenie przypadków użycia, 160, 173identyfikacja aktorów, 160, 167identyfikacja przypadków użycia, 160, 171identyfikacja relacji między aktorami

a przypadkami użycia, 176identyfikacja relacji między przypadkami użycia,

160identyfikacja scenariuszy, 160, 169identyfikacja wymagań pozafunkcyjnych, 160, 182inżynieria interfejsu, 165, 166inżynieria pierwotna, 165

Skorowidz 871

inżynieria wtórna, 165JAD, 185jednoznaczność, 164kompletność, 164komunikacja, 158koncepcje, 161negocjowanie specyfikacji z klientem, 185początkowa identyfikacja obiektów modelu

analitycznego, 179poprawność, 164RAD, 188specyfikacja wymagań, 159spójność, 164system ARENA, 190weryfikowalne cechy specyfikacji, 164wymagania funkcyjne, 161wymagania pozafunkcyjne, 162zarządzanie identyfikowalnością, 187zarządzanie zbieraniem wymagań, 183

zbiory, 411, 413zbiory zmian, 608zdalne wywoływania procedur, 283zdarzenia, 75, 76zdobycie K2, 714zebrania, 147, 665

zebrania planistyczne, 674zebrania początkujące, 118zebrania statusowe, 117, 118, 665, 675zebranie otwierające, 664zebranie startowe, 674

zespoły, 119, 663zespoły czteroosobowe, 663zespoły międzyfunkcyjne, 121, 146

zespoły podsystemów, 146zespoły trzyosobowe, 663zespół (Scrum), 675zintegrowane środowisko programistyczne, 280zintegrowanie racjonalizacji z modelami systemu, 553złącza, 270złączenia, 102złudzenie optyczne, 212zmiany, 37, 608zmiany w implementacji, 367zmiany w środowisku operacyjnym, 324zmiany w zakresie dziedziny aplikacyjnej, 368zmodyfikowane testowanie kanapkowe, 523znacznikowane komentarze Javadoc, 429zorientowane obiektowo tworzenie

oprogramowania, 41zorientowanie obiektowe, 40zrównoleglone projekty, 623Z-Schematy, 72zwinna realizacja projektu, 673

planowanie projektu, 674zwinne metodologie, 725, 737

Źźle zlokalizowane atrybuty, 456

Żżądanie wyjaśnień, 117, 136żądanie zmian, 117, 137, 138, 602, 604

Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce...

Documents

Transcript of Inżynieria oprogramowania w ujęciu obiektowym. UML, wzorce...