SW wykład 14 - Slajd7: 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:sw1406.png|frame|center|]]
[[Grafika:sw1406.png|frame|center|]]
W procesie przekształcania specyfikacji, wiodącym od początkowej
specyfikacji wymagań wobec budowanego systemu do jego ostatecznej
realizacji, powstające kolejno specyfikacje będą stopniowo
odzwierciedlały coraz więcej szczegółów i decyzji programistycznych,
oraz coraz większe fragmenty gotowego kodu systemu. Warto te już
ustalone fragmenty implementacji wyraźnie w procesie konstruowania
programu wskazywać, odkładając je niejako "na bok" w kolejnych krokach
przekształcania specyfikacji, a pozostawiając do dalszej realizacji
tylko tę część specyfikacji, która nie została jeszcze dostatecznie
uszczegółowiona.
Prowadzi to do nieco innego formalnie pojęcia przekształcenia (czy
uszczegółowienia) specyfikacji wymagań, gdzie wskazujemy specyfikację,
którą mamy jeszcze zrealizować, oraz zakodowany w języku programowania
"konstruktor", który otrzymując dowolną realizację tej pozostałej
specyfikacji niejako "dołoży" do niej ustalone w tym kroku fragmenty
kodu" i w ten sposób zbuduje realizację przekształcanej
specyfikacji. O konstruktorach tych można myśleć jako o dobrze
określonych modułach budowanego systemu, sparametryzowanych przez
realizację pozostałej specyfikacji.
Dodajmy tylko, że oczywiście wykorzystując "identycznościowe"
konstruktory, na poprzednio rozważaną relację uszczegóławiania
specyfikacji można patrzeć jako na szczególny przypadek tego pojęcia.

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

W procesie przekształcania specyfikacji, wiodącym od początkowej specyfikacji wymagań wobec budowanego systemu do jego ostatecznej realizacji, powstające kolejno specyfikacje będą stopniowo odzwierciedlały coraz więcej szczegółów i decyzji programistycznych, oraz coraz większe fragmenty gotowego kodu systemu. Warto te już ustalone fragmenty implementacji wyraźnie w procesie konstruowania programu wskazywać, odkładając je niejako "na bok" w kolejnych krokach przekształcania specyfikacji, a pozostawiając do dalszej realizacji tylko tę część specyfikacji, która nie została jeszcze dostatecznie uszczegółowiona.

Prowadzi to do nieco innego formalnie pojęcia przekształcenia (czy uszczegółowienia) specyfikacji wymagań, gdzie wskazujemy specyfikację, którą mamy jeszcze zrealizować, oraz zakodowany w języku programowania "konstruktor", który otrzymując dowolną realizację tej pozostałej specyfikacji niejako "dołoży" do niej ustalone w tym kroku fragmenty kodu" i w ten sposób zbuduje realizację przekształcanej specyfikacji. O konstruktorach tych można myśleć jako o dobrze określonych modułach budowanego systemu, sparametryzowanych przez realizację pozostałej specyfikacji.

Dodajmy tylko, że oczywiście wykorzystując "identycznościowe" konstruktory, na poprzednio rozważaną relację uszczegóławiania specyfikacji można patrzeć jako na szczególny przypadek tego pojęcia.