SW wykład 14 - Slajd8: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Mengel (dyskusja | edycje)
Nie podano opisu zmian
 
Tarlecki (dyskusja | edycje)
Nie podano opisu zmian
 
Linia 2: Linia 2:


[[Grafika:sw1407.png|frame|center|]]
[[Grafika:sw1407.png|frame|center|]]
Szczególną rolę w procesie konstruowania systemów naszkicowanym przy
poprzednich slajdach odgrywać będą kroki, w których dokonujemy
podziału danego zadania programistycznego na podzadania. Taka
dekompozycja polegać zawsze musi na ustaleniu pewnej liczby podzadań,
które dalej będą realizowane niezależnie od siebie i w wyniku dadzą
wzajemnie niezależne moduły systemu, podanie specyfikacji,
określających te podzadania, oraz podanie konstrukcji, która z
otrzymanych z realizacji podzadań modułów zbuduje cały system.
Tak rozumiany krok dekompozycji zadania programistycznego jest
poprawny, jeśli tylko dla wszelkich realizacji podzadań, które są
poprawne względem ich zadanych specyfikacji, podana konstrukcja buduje
system, który jest poprawny względem specyfikacji przekształcanej.
Ważną konsekwencją tek rozumianej poprawności dekompozycji zadania
jest to, że dalsze konstruowania każdego z modułów spełniających
specyfikacje podzadań może przebiegać wzajemnie niezależnie od
konstrukcji pozostałych modułów, a uzyskane w ten sposób moduły mogą
być później dowolnie zmieniane, o ile tylko nadal pozostaną poprawne
względem zadanej specyfikacji podzadania. Dobrze służy to
modyfikowalności, dalszej optymalizacji i pielęgnacji zbudowanego
systemu.
Gdy postępując w ten sposób uda nam się "zamknąć" wszystkie gałęzie
procesu konstruowania systemu, to oczywiste złożenie wykorzystywanych
w poszczególnych krokach konstrukcji prowadzi do budowy systemu
będącego poprawną realizacją pierwotnego zadania programistycznego
(określonego pierwotną specyfikacją wymagań). Powstaje przy tym dobrze
zmodularyzowany system, gdzie każdy moduł ma ściśle określoną
specyfikację, która ujmuje wszystkie własności, na których reszta
systemu może polegać, i w ramach której można ten moduł dowolnie
modyfikować. Specyfikacje te stanowią przy tym bardzo dobrą
dokumentację systemu dla przyszłych (użytkowników i) programistów
zajmujących się dalszą pielęgnacją i rozwijaniem systemu.

Aktualna wersja na dzień 14:06, 18 paź 2006

<<powrót do strony wykładu

Systematyczne konstruowanie programów Inżynieria wymagań Walidacja specyfikacji Strukturalne języki specyfikowania Zadanie programisty Uszczegóławianie Uszczegóławianie, c.d. Dekompozycja Wyzwanie

Szczególną rolę w procesie konstruowania systemów naszkicowanym przy poprzednich slajdach odgrywać będą kroki, w których dokonujemy podziału danego zadania programistycznego na podzadania. Taka dekompozycja polegać zawsze musi na ustaleniu pewnej liczby podzadań, które dalej będą realizowane niezależnie od siebie i w wyniku dadzą wzajemnie niezależne moduły systemu, podanie specyfikacji, określających te podzadania, oraz podanie konstrukcji, która z otrzymanych z realizacji podzadań modułów zbuduje cały system.

Tak rozumiany krok dekompozycji zadania programistycznego jest poprawny, jeśli tylko dla wszelkich realizacji podzadań, które są poprawne względem ich zadanych specyfikacji, podana konstrukcja buduje system, który jest poprawny względem specyfikacji przekształcanej.

Ważną konsekwencją tek rozumianej poprawności dekompozycji zadania jest to, że dalsze konstruowania każdego z modułów spełniających specyfikacje podzadań może przebiegać wzajemnie niezależnie od konstrukcji pozostałych modułów, a uzyskane w ten sposób moduły mogą być później dowolnie zmieniane, o ile tylko nadal pozostaną poprawne względem zadanej specyfikacji podzadania. Dobrze służy to modyfikowalności, dalszej optymalizacji i pielęgnacji zbudowanego systemu.

Gdy postępując w ten sposób uda nam się "zamknąć" wszystkie gałęzie procesu konstruowania systemu, to oczywiste złożenie wykorzystywanych w poszczególnych krokach konstrukcji prowadzi do budowy systemu będącego poprawną realizacją pierwotnego zadania programistycznego (określonego pierwotną specyfikacją wymagań). Powstaje przy tym dobrze zmodularyzowany system, gdzie każdy moduł ma ściśle określoną specyfikację, która ujmuje wszystkie własności, na których reszta systemu może polegać, i w ramach której można ten moduł dowolnie modyfikować. Specyfikacje te stanowią przy tym bardzo dobrą dokumentację systemu dla przyszłych (użytkowników i) programistów zajmujących się dalszą pielęgnacją i rozwijaniem systemu.