Ћекции.ќрг


ѕоиск:




 атегории:

јстрономи€
Ѕиологи€
√еографи€
ƒругие €зыки
»нтернет
»нформатика
»стори€
 ультура
Ћитература
Ћогика
ћатематика
ћедицина
ћеханика
ќхрана труда
ѕедагогика
ѕолитика
ѕраво
ѕсихологи€
–елиги€
–иторика
—оциологи€
—порт
—троительство
“ехнологи€
“ранспорт
‘изика
‘илософи€
‘инансы
’ими€
Ёкологи€
Ёкономика
Ёлектроника

 

 

 

 


ƒ≥аграми поток≥в даних- DFD




ѕринципи побудови модел≥ ≤DEF0

Ќа сьогодн≥шн≥й день ≤DEF0 широко використовуЇтьс€ дл€ розвТ€занн€ двох тип≥в задач:

1. –е≥нжин≥ринг б≥знес-процес≥в орган≥зац≥њ.

2. ѕроектуванн€ ≥нформац≥йних систем.

÷≥ задач≥ можуть бути взаЇмоповТ€зан≥, оск≥льки проектуванн€ ≥нформац≥йноњ системи досить часто призводить до реорган≥зац≥њ б≥знес-процес≥в орган≥зац≥њ. ќднак, коли мова йде просто про ре≥нжин≥ринг, схеми б≥знес-процес≥в орган≥зац≥њ зазвичай будуютьс€ менджерами без детал≥зац≥њ моделей даних.

“ому сл≥д в≥дм≥тити, що при проектуванн≥ ≥нформац≥йних систем в ≤DEF0 ≥нформац≥йна система представл€Їтьс€:

- з одного боку €к сукупн≥сть взаЇмод≥ючих функц≥й - така чисто функц≥ональна ор≥Їнтац≥€ Ї принциповою - функц≥њ системи анал≥зуютьс€ незалежно в≥д об'Їкт≥в, €кими вони оперують;

- з другого боку будуЇтьс€ модель даних, €кими оперують функц≥њ.

÷е дозвол€Ї б≥льш ч≥тко змоделювати лог≥ку ≥ взаЇмод≥ю процес≥в ≥нформац≥йноњ системи.

ѕроцес моделюванн€ ≥нформац≥йноњ системи в ≤DEF0 починаЇтьс€ з визначенн€ контексту, тобто найб≥льш абстрактного р≥вн€ опису системи в ц≥лому. ” контекст входить визначенн€ суб'Їкта моделюванн€ (Scope), мети (Purpose) ≥ точки зору на модель (V≥ewpo≥nt). “акож вказуютьс€ часов≥ рамки модел≥ - AS-≤S чи “ќ-¬E.“ехнолог≥€ проектуванн€ ≤— передбачаЇ спочатку створенн€ модел≥ AS-≤S, њњ анал≥з ≥ пол≥пшенн€ б≥знес≥в-процес≥в, п≥сл€ чого створюЇтьс€ модель “ќ-¬≈, ≥ т≥льки на основ≥ модел≥ “ќ-¬≈ будуЇтьс€ модель даних, прототип ≥ пот≥м остаточний вар≥ант ≤—.

ѕобудова системи на основ≥ модел≥ AS-≤S приводить до автоматизац≥њ п≥дприЇмства за принципом "усе залишити €к Ї, т≥льки щоб комп'ютери сто€ли", тобто ≤— автоматизуЇ недосконал≥ б≥знеси-процеси ≥ дублюЇ, а не зам≥н€Ї ≥снуючий документооб≥г. ” результат≥ впровадженн€ й експлуатац≥€ такоњ системи приводить лише до додаткових витрат на закуп≥влю устаткуванн€, створенн€ програмного забезпеченн€ ≥ супров≥д того й ≥ншого.

ѕоширеною помилкою при створенн≥ модел≥ AS-≤S Ї створенн€ ≥деал≥зованоњ модел≥. ѕрикладом може служити створенн€ модел≥ на основ≥ знань кер≥вника, а не конкретного виконавц€ роб≥т.

 

ƒ≥аграми ≤DEF0

ћодель у нотац≥њ ≤DEF0 м≥стить сукупн≥сть ≥Їрарх≥чно упор€дкованих ≥ взаЇмозалежних д≥аграм.  ожна д≥аграма Ї одиницею опису системи ≥ розташовуЇтьс€ на окремому лист≥.

ћодель може мати чотири типи д≥аграм:

Ј контекстну д≥аграму (у кожн≥й модел≥ може бути т≥льки одна контекстна д≥аграма);

Ј д≥аграми декомпозиц≥њ;

Ј д≥аграми дерева вузл≥в;

Ј д≥аграми т≥льки дл€ експозиц≥њ (FEO).

 онтекстна д≥аграма (рис.10.8) Ї вершиною деревопод≥бноњ структури д≥аграм ≥ €вл€Ї собою самий загальний опис системи ≥ њњ взаЇмод≥њ з зовн≥шн≥м середовищем.

ѕ≥сл€ опису системи в ц≥лому проводитьс€ розбивка њњ на велик≥ фрагменти. ÷ей процес називаЇтьс€ функц≥ональною декомпозиц≥Їю, а д≥аграми, що описують кожен фрагмент ≥ взаЇмод≥€ фрагмент≥в, називаютьс€ д≥аграмами декомпозиц≥њ.

ѕ≥сл€ декомпозиц≥њ контекстноњ д≥аграми проводитьс€ декомпозиц≥€ кожного великого фрагмента системи на б≥льш др≥бн≥ ≥ так дал≥, до дос€гненн€ потр≥бного р≥вн€ подробиц≥ опису. ѕ≥сл€ кожного сеансу декомпозиц≥њ провод€тьс€ сеанси експертизи - експерти предметноњ област≥ вказують на в≥дпов≥дн≥сть реальних б≥знес≥в-процес≥в створеним д≥аграмам. «найден≥ нев≥дпов≥дност≥ виправл€ютьс€, ≥ т≥льки п≥сл€ проходженн€ експертизи без зауважень можна приступати до наступного сеансу декомпозиц≥њ. “ак дос€гаЇтьс€ в≥дпов≥дн≥сть модел≥ реальним б≥знес-процесам на будь-€кому р≥вн≥ модел≥. —интаксис опису системи в ц≥лому ≥ у кожн≥м њњ фрагмент≥ однаковий у вс≥й модел≥.

ƒ≥аграма дерева вузл≥в показуЇ ≥Їрарх≥чну залежн≥сть роб≥т, але не взаЇмозв'€зки м≥ж роботами. ƒ≥аграм дерев вузл≥в може бути в модел≥ €к завгодно багато, оск≥льки дерево може бути побудоване на дов≥льну глибину ≥ не обов'€зково з корен€.

ƒ≥аграми дл€ експозиц≥њ (FEO) будуютьс€ дл€ ≥люстрац≥њ альтернативноњ точки зору на окрем≥ фрагменти модел≥, або дл€ спец≥альних ц≥лей.

—тар≥ верс≥њ €коњсь д≥аграми можна збер≥гати у вид≥ паперовоњ коп≥њ або €к FEO-д≥аграму.

” будь-€кому випадку варто в≥др≥зн€ти р≥зн≥ верс≥њ одн≥Їњ ≥ т≥Їњ ж д≥аграми. ƒл€ цього ≥снуЇ спец≥альний номер - —-numbеr, що повинний привласнюватис€ автором модел≥ вручну. C-number - це дов≥льний р€док, але рекомендуЇтьс€ дотримувати стандарту, коли номер складаЇтьс€ з буквеного преф≥кса ≥ пор€дкового номера, причому €к преф≥кс використовуютьс€ ≥н≥ц≥али автора д≥аграми, а пор€дковий номер в≥дсл≥дковуЇтьс€ автором вручну, наприклад ћ—¬00021.

 

10.4.3. –оботи-функц≥њ (Act≥v≥ty)

–оботи позначають по≥менован≥ функц≥њ задач≥, що в≥дбуваютьс€ прот€гом визначеного часу ≥ мають певн≥ результати.

–оботи зображуютьс€ у вид≥ пр€мокутник≥в. ”с≥ роботи повинн≥ бути назван≥ ≥ визначен≥. ≤м'€ роботи повинне позначати д≥ю (наприклад, "¬иготовленн€ детал≥", "ѕрийом замовленн€" ≥ т.д.).

ѕри створенн≥ новоњ модел≥ автоматично створюЇтьс€ контекстна д≥аграма з Їдиною роботою, що зображуЇ систему в ц≥лому (рис. 1).

ƒ≥аграми декомпозиц≥њ м≥ст€ть родинн≥ роботи, тобто доч≥рн≥ роботи, що мають загальну батьк≥вську роботу.

–оботи на д≥аграмах декомпозиц≥њ звичайно розташовуютьс€ по д≥агонал≥ в≥д л≥вого верхнього кута до правого нижнього. “акий пор€док називаЇтьс€ пор€дком дом≥нуванн€.

¬≥дпов≥дно до цього принципу розташуванн€ в л≥вому верхньому кут≥ розташовуЇтьс€ сама важлива робота чи робота, виконувана за часом першою. ƒал≥ вправо вниз розташовуютьс€ менш важлив≥ чи виконуван≥ п≥зн≥ше роботи. “аке розташуванн€ полегшуЇ читанн€ д≥аграм, кр≥м того, на ньому ірунтуЇтьс€ пон€тт€ взаЇмозв'€зк≥в роб≥т.

 ожна з роб≥т на д≥аграм≥ декомпозиц≥њ може бути у свою чергу декомпозована.

Ќа д≥аграм≥ декомпозиц≥њ роботи нумеруютьс€ автоматично зл≥ва направо. Ќомер роботи показуЇтьс€ в правому нижньому кут≥.

Ќомер складаЇтьс€ з преф≥кса ≥ числа. «звичай використовують преф≥кс ј.  онтекстна д≥аграма завжди маЇ номер ј-0, декомпозиц≥€ контекстноњ д≥аграми - номер ј0. –оботи декомпозиц≥њ ј0 мають номера Al, A2, A3 ≥ т.д. –оботи декомпозиц≥њ нижнього р≥вн€ мають номер батьк≥вськоњ роботи ≥ черговий пор€дковий номер, наприклад роботи декомпозиц≥њ A3 будуть мати номера ј31, ј32, ј««, ј34 ≥ т.д. “ака нумерац≥€ називаЇтьс€ нумерац≥Їю по кутах.

–оботи утворюють ≥Їрарх≥ю, де кожна робота може мати одну батьк≥вську ≥ к≥лька доч≥рн≥х роб≥т.

 

10. 4.4. —тр≥лки (Arrow)

¬заЇмод≥€ роб≥т ≥з зовн≥шн≥м св≥том ≥ м≥ж собою описуЇтьс€ у вид≥ стр≥лок. —тр≥лки означають де€ку ≥нформац≥ю й ≥менуютьс€ ≥менниками, наприклад, "«агот≥вл€", "¬ир≥б", "«амовленн€".

≤мена нових стр≥лок автоматично занос€тьс€ в словник (Arrow D≥ct≥onary). —ловник стр≥лок редагуЇтьс€ за допомогою спец≥ального редактора Arrow D≥ct≥onary Ed≥tor, у €кому визначаЇтьс€ стр≥лка ≥ вноситьс€ стосовно до нењ коментар.

”м≥ст словника стр≥лок можна роздрукувати у вигл€д≥ зв≥ту ≥ одержати тим самим тлумачний словник терм≥н≥в предметноњ област≥, що використовуютьс€ в модел≥.

¬ ≤DEF0 розр≥зн€ють п'€ть тип≥в стр≥лок.  ожен тип стр≥лок п≥дходить до визначеноњ сторони пр€мокутника, що зображуЇ роботу, чи виходить з нењ.

1. ¬х≥д (≥nput) - матер≥ал чи ≥нформац≥€, що використовуЇтьс€ чи перетворитьс€ роботою дл€ одержанн€ результату (виходу). ƒопускаЇтьс€, що робота може не мати н≥ одн≥Їњ стр≥лки входу. —тр≥лка входу малюЇтьс€ €к вх≥дна в л≥ву грань роботи.

ѕри опис≥ технолог≥чних процес≥в (дл€ цього ≥ був придуманий ≤DEF0) не виникаЇ проблем визначенн€ вход≥в. ѕроте при моделюванн≥ ≤—, коли стр≥лками Ї не ф≥зичн≥ об'Їкти, а дан≥, не все так очевидно. ƒе€к≥ дан≥ можуть бути ≥ на вход≥ ≥ на виход≥, дуже часто складно визначати, чи Ї дан≥ входом чи керуванн€м. ” цьому випадку п≥дказкою може служити те, переробл€ютьс€ (зм≥нюютьс€) дан≥ в робот≥ чи н≥. якщо зм≥нюютьс€, то, швидше за все, це вх≥д, €кщо н≥ - керуванн€.

2.  еруванн€ (Control)- правила, стратег≥њ, процедури чи стандарти, €кими керуЇтьс€ робота. " ожна робота повинна мати хоча б одну стр≥лку керуванн€. —тр≥лка керуванн€ малюЇтьс€ €к вх≥дна у верхню грань роботи.

 еруванн€ впливаЇ на роботу, але не перетворитьс€ роботою.

3. ¬их≥д (Output) - матер≥ал чи ≥нформац≥€, що виробл€ютьс€ роботою.  ожна робота повинна мати хоча б одну стр≥лку виходу. –обота без результату не маЇ зм≥сту ≥ не повинна моделюватис€. —тр≥лка виходу малюЇтьс€ €к вих≥дна з правоњ гран≥ роботи.

4. ћехан≥зм (Mechan≥sm)- ресурси, що виконують роботу, наприклад персонал п≥дприЇмства, верстати, пристроњ ≥ т.д. —тр≥лка механ≥зму малюЇтьс€ €к вх≥дна в нижню грань роботи.

ѕо розсуду анал≥тика стр≥лки механ≥зму можуть не зображуватис€ в модел≥.

5. ¬иклик (Call) - спец≥альна стр≥лка, що вказуЇ на ≥ншу модель роботи. —тр≥лка механ≥зму малюЇтьс€ €к вих≥дна з нижньоњ гран≥ роботи. —тр≥лка виклику використовуЇтьс€ дл€ вказ≥вки того, що де€ка робота виконуЇтьс€ за межами моделюЇмоњ системи. —тр≥лки виклику використовуютьс€ в механ≥зм≥ злитт€ ≥ под≥лу моделей.

—тр≥лки на контекстн≥й д≥аграм≥ служать дл€ опису взаЇмод≥њ системи з навколишн≥м св≥том. ¬они можуть починатис€ в границ≥ д≥аграми ≥ зак≥нчуватис€ в роботи, чи навпаки. “ак≥ стр≥лки називаютьс€ граничними.

ѕри декомпозиц≥њ роботи вх≥дн≥ в нењ ≥ вих≥дн≥ з нењ стр≥лки (кр≥м стр≥лки виклику) автоматично з'€вл€ютьс€ на д≥аграм≥ декомпозиц≥њ (м≥грац≥€ стр≥лок), але при цьому не повТ€зуютьс€ з роботами Ц це потр≥бно зробити вручну.

ƒл€ зв'€зку роб≥т м≥ж собою використовуютьс€ внутр≥шн≥ стр≥лки, тобто стр≥лки, що не торкаютьс€ границ≥ д≥аграми, починаютьс€ з одн≥Їњ ≥ к≥нчаютьс€ в ≥нш≥й робот≥.

¬ ≤DEF0 розр≥зн€ють п'€ть тип≥в зв'€зк≥в роб≥т.

«в'€зок по входу (output-≥nput), коли стр≥лка виходу вищесто€щоњ роботи (дал≥ - просто вих≥д) направл€Їтьс€ на вх≥д нижчесто€щоњ.

«в'€зок по керуванню (output-control), коли вих≥д вищесто€щоњ роботи направл€Їтьс€ на керуванн€ нижчесто€щоњ. «в'€зок по входу показуЇ дом≥нуванн€ вищесто€щоњ роботи. ƒан≥ чи об'Їкти виходу вищесто€щоњ роботи не м≥н€ютьс€ в нижчесто€щ≥й.

«воротний зв'€зок по входу (output-≥nput feedback), коли вих≥д нижчесто€щоњ роботи направл€Їтьс€ на вх≥д вищесто€щоњ. “акий зв'€зок, €к правило, використовуЇтьс€ дл€ опису цикл≥в.

«воротний зв'€зок по керуванню (output-control feedback), коли вих≥д нижчесто€щоњ роботи направл€Їтьс€ на керуванн€ вищесто€щою. «воротний зв'€зок по керуванню часто св≥дчить про ефективн≥сть б≥знес-процесу.

–ис.10.12.«воротн≥й звТ€зок по керуванню

 

«в'€зок вих≥д-механ≥зм (output-mechan≥sm), коли вих≥д одн≥Їњ роботи направл€Їтьс€ на механ≥зм ≥ншоњ. ÷ей взаЇмозв'€зок використовуЇтьс€ р≥дше ≥нших ≥ показуЇ, що одна робота п≥дготовл€Ї ресурси, необх≥дн≥ дл€ проведенн€ ≥ншоњ роботи

—тр≥лки також под≥л€ютьс€ на €вн≥ та розгалуджен≥.

явн≥ стр≥лки мають джерелом одну-Їдину роботу ≥ призначенн€м теж одну-Їдину роботу.

—тр≥лки що розгалужуютьс€ використовуютьс€ дл€ в≥дображенн€ використанн€ даних, породжених одн≥Їю роботою, в≥дразу в дек≥лькох ≥нших роботах;

—тр≥лки, що зливаютьс€ використовуютьс€ дл€ в≥дображенн€ використанн€ даних, породжених в р≥зних роботах, що переробл€ютьс€ в одному м≥сц≥.

якщо стр≥лка ≥менована до розгалуженн€, а п≥сл€ розгалуженн€ жодна з г≥лок не ≥менована, то маЇтьс€ на уваз≥, що кожна галузь моделюЇ т≥ ж об'Їкти, що ≥ галузь до розгалуженн€

якщо стр≥лка ≥менована до розгалуженн€, а п≥сл€ розгалуженн€ €ка-небудь з галузей не ≥менована, то маЇтьс€ на уваз≥, що ц≥ галуз≥ в≥дпов≥дають ≥менуванню.

Ќеприпустима ситуац≥€, коли стр≥лка до розгалуженн€ не ≥менована, а п≥сл€ розгалуженн€ не ≥менована €ка-небудь з г≥лок.

Ќовостворен≥ граничн≥ стр≥лки на д≥аграм≥ декомпозиц≥њ нижнього р≥вн€ (не перенесен≥ з д≥аграми верхнього р≥вн€) зображуютьс€ в квадратних дужках ≥ автоматично не з'€вл€ютьс€ на д≥аграм≥ верхнього р≥вн€ (рис.)

ƒл€ њх перенесенн€ потр≥бно в д≥алоз≥ Arrow Tunnel розширити границ≥ (Resolve Border Arrow) стр≥лок. якщо ж замкнути стр≥лку в тунель Change To Tunnel - стр≥лка буде зображуватис€ лише на одн≥й д≥аграм≥ ≥ позначатис€ круглими дужками на к≥нц≥.

“унелюванн€ може бути застосоване дл€ зображенн€ малозначимих стр≥лок, €к≥ не важлив≥ дл€ загального огл€ду модел≥, а слугують лише дл€ њњ детал≥зац≥њ. јбо ж у випадку, коли €кась стр≥лка використовуЇтьс€ у вс≥х роботах на д≥аграмах декомпозиц≥њњ Ц дл€ того, щоб не захаращувати д≥аграми, стр≥лку замикають в тунель на батьк≥вськ≥й д≥аграм≥.

 

 

10.5. ћ≈“ќƒќЋќ√≤ѓ структурного анал≥зу ≥ проектуванн€ SA/SD

—уть методолог≥й SA/SD

як вже зазначалос€, ≥снуЇ дек≥лька методолог≥й, що акцентують увагу на моделюванн≥ поток≥в даних м≥ж процесами. Ќайб≥льш в≥домими Ї:

1. SA (Structured Analysis) Ц методолог≥€ структурного анал≥зу, запропонована ƒе ћарко в 1978 р. [];

2. SD (Structured Design) Ц методолог≥€ структурного проектуванн€ запропонована —т≥венсом, ћайером,  онстантайном [];

3. SSA (Structured Systems Analysis) - структурного системного анал≥зу, запропонована √ейном-—арсоном у 1979 [];

4. SA/SD Ц структурного системного анал≥зу ≥ проектуванн€ …ордана, 1989 [].

ƒо ц≥Їњ ж групи можна в≥днести методолог≥њ:

- SRD (Structured Requirements Definition), розроблена Ken Orr в середин≥ 70-х;

- SSADM (Structured Systems Analysis and Design Method), створена на початку 80-х рок≥в ≥ прийн€та в 1993 роц≥ €к нац≥ональний стандарт ¬еликобритан≥њ, та ≥н.

ƒосить часто в л≥тератур≥ вищеназван≥ методолог≥њ обТЇднуютьс€ п≥д Їдиною назвою SA/SD (або SA-SD чи SASD), за назвою методолог≥њ, запропонованоњ …орданом. ÷е по€снюЇтьс€ тим, що …ордан в своњй книз≥ "Modern Structured Analysis" (—учасний структурний анал≥з) узагальнив досв≥д структурного анал≥зу двох дес€тил≥ть.

ћожна вид≥лити три основних етапи моделюванн€ ≤— в≥дпов≥дно до методолог≥й SA/SD (рис.10.15):

 

1. ћоделюванн€ оточуючого середовища. 2. ‘ункц≥ональне моделюванн€ (моделюванн€ повед≥нки системи). 3. ћоделюванн€ реал≥зац≥њ SA   SD

–ис. 10.15. ќсновн≥ етапи методолог≥њ SA/SD

ѕерших два етапи в≥днос€тьс€ до структурного анал≥зу, вони дають можлив≥сть побудувати лог≥чну модель системи, незалежну в≥д реал≥зац≥њ

“рет≥й етап в≥дноситьс€ до структурного проектуванн€ ≥ передбачаЇ проектуванн€ системи ≥з врахуванн€м њњ реал≥зац≥њ в план≥ програмного ≥ техн≥чного забезпеченн€.

Ќа кожному з етап≥в передбачаЇтьс€ використанн€ певних засоб≥в моделюванн€.

“ак., моделюванн€ оточуючого середовища передбачаЇ побудову контекстноњ д≥аграми ≥ визначенн€ перел≥ку под≥й.

‘ункц≥ональне моделюванн€ передбачаЇ використанн€:

Ј ƒ≥аграм поток≥в даних Ц DFD (Data Flow Diagram).;

Ј —ловник≥в даних;

Ј ѕростих спец≥ф≥кац≥й процес≥в;

Ј ERD Цд≥аграм (див. розд≥л 5.п.2).

¬заЇмозвТ€зок м≥ж цими ≥нструментами подано на рис.10.16.

ћоделюванн€ реал≥зац≥й використовуЇ:

Ј —труктурн≥ модел≥ Ц м≥жмодульна взаЇмод≥€;

Ј ”згодженн€ всередин≥ модул≥в.

–озгл€немо коротко ц≥ засоби.


ƒ≥аграми поток≥в даних- DFD

ѕрактично, на сьогодн≥шн≥й день розр≥зн€ють дв≥ граф≥чн≥ нотац≥њ дл€ DFD (€к≥ ≥ п≥дтримуютьс€ Case-засобами): √ейна-—арсона та …ордана-ƒе ћарко, оск≥льки ƒе ћарко в процес≥ удосконаленн€ свого методу почав використовувати запропонован≥ …орданом граф≥чн≥ зображенн€.

ќсновн≥ символи цих нотац≥й зображен≥ на рис 10.17. ƒо них належать:

Ќазва Ќотац≥€ …ордона Ќотац≥€ √ейна-—арсона
Flow Ц ѕот≥к даних
Process (bubble) - ѕроцес  
Store Ц —ховище
назва

Terminator Ц «овн≥шн≥й обТЇкт
  назва

–ис. 10.17. ќсновн≥ символи д≥аграм поток≥в даних

ѕотоки даних Ц п≥д ними розум≥ють обТЇкти (дан≥), що передаютьс€ з одн≥Їњ частини системи в ≥ншгу, позначаютьс€ стр≥лками. —тр≥лка вказуЇ напр€мок руху даних ≥ може бути €к одно-, так ≥ двонаправленою.

ѕроцеси Ц призначен≥ дл€ отриманн€ вих≥дних поток≥в даних ≥з вх≥дних, в≥дпов≥дно до д≥њ, що задаЇтьс€ ≥мТ€м процесу (аналог роб≥т в IDEF0).  р≥м ≥мен≥ процес маЇ також ун≥кальний номер дл€ посилань на нього усередин≥ д≥аграми.

—ховище даних Ц дозвол€Ї визначати дан≥, що будуть збер≥гатис€ в пам'€т≥ м≥ж процесами., ≤нформац≥€, що воно м≥стить, може використовуватис€ в будь-€кий час п≥сл€ њњ визначенн€, при цьому дан≥ можуть вибиратис€ в будь-€кому пор€дку.≤м'€ сховища повинне ≥дентиф≥кувати його вм≥ст ≥ бути ≥менником. ” випадку, коли пот≥к даних входить або виходить ≥з сховища, ≥ його структура в≥дпов≥даЇ структур≥ сховища, в≥н повинний мати те ж саме ≥м'€.

«овн≥шн≥й обТЇкт - сутн≥сть поза контекстом системи, що Ї джерелом або приймачем системних даних. ѓњ ≥м'€ повинне м≥стити ≥менник. ѕередбачаЇтьс€, що об'Їкти, представлен≥ такими вузлами, не повинн≥ брати участь в обробц≥ даних. “обто, це не системний анал≥тик чи адм≥н≥стратор ≥ звТ€зки м≥ж зовн≥шн≥ми обТЇктами на DFD не показуютьс€.

јналог≥чно до IDEF0 в DFD створюЇтьс€ початково контекстна д≥аграма, що моделюЇ систему найб≥льш загальним чином.  онтекстна д≥аграма в≥дбиваЇ ≥нтерфейс системи з зовн≥шн≥м св≥том, а саме, ≥нформац≥йн≥ потоки м≥ж системою ≥ зовн≥шн≥ми сутност€ми, з €кими вона повинна бути зв'€зана. ¬она ≥дентиф≥куЇ ц≥ зовн≥шн≥ сутност≥, а також, €к правило, Їдиний процес, що в≥дбиваЇ головну мету або природу системи.

“акож зд≥йснюЇтьс€ декомпозиц≥€ Ц спочатку процесу на контекстн≥й д≥аграм≥, а пот≥м, на сл≥дуючому р≥вн≥, й ≥нших процес≥в. ѕроцес декомпозиц≥њ продовжуЇтьс€ доти, поки процеси можуть бути ефективно описан≥ за допомогою коротких (до одн≥Їњ стор≥нки) специф≥кац≥й Ц д≥аграм декомпозиц≥њ. ѕроцеси нумеруютьс€. “ак, наприклад, €кщо ми детал≥зуЇмо процес номер 2 на д≥аграм≥ першого р≥вн€, розкриваючи його за допомогою DFD, що м≥стить три процеси, то њхн≥ номери будуть мати такий вигл€д: 2.1, 2.2 ≥ 2.3. ѕрост≥ системи мабть 2-3 р≥вн≥ декомпозиц≥њ, в складних њх зазвичай не б≥льше восьми.


Ќа рис.10.18. зображено взаЇмозвТ€зок д≥аграм поток≥в даних в нотац≥њ …ордана.

Ќа рис.10.19. подано приклад д≥аграми декомпозиц≥њ в нотац≥њ DFD √ейна-—арсона.

 
 

ќсновними вимогами при побудов≥ моделей DFD Ї:

Ј –озм≥щувати на кожн≥й д≥аграм≥ в≥д 3 до 6-7 процес≥в. ¬ерхн€ границ€ в≥дпов≥даЇ людським можливост€м одночасного сприйн€тт€ ≥ розум≥нн€ структури складноњ системи, нижн€ границ€ обрана з позиц≥й здорового глузду: немаЇ необх≥дност≥ детал≥зувати процес д≥аграмою, що м≥стить всього один або два процеси.

Ј Ќе захаращувати д≥аграми несуттЇвими на даному р≥вн≥ детал€ми.

Ј ƒекомпозиц≥ю поток≥в даних зд≥йснювати паралельно з декомпозиц≥Їю процес≥в; ц≥ дв≥ роботи повинн≥ виконуватис€ одночасно, а не одна п≥сл€ завершенн€ ≥ншоњ.

Ј ¬ибирати €сн≥ ≥мена процес≥в ≥ поток≥в, дл€ пол≥пшенн€ розум≥нн€ д≥аграм, при цьому намагатис€ не використовувати абрев≥атури.

Ј ќднократно визначати функц≥онально ≥дентичн≥ процеси на самому верхньому р≥вн≥, де вони необх≥дн≥, ≥ посилатис€ на них на нижн≥х р≥вн€х.

Ј  ористуватис€ найпрост≥шими д≥аграмними техн≥ками Ц не використовувати без необх≥дност≥ складн≥ об'Їкти.

Ј ¬≥докремлювати керуюч≥ структури в≥д процес≥в.

¬≥дпов≥дно до цих рекомендац≥й процес побудови модел≥ розбиваЇтьс€ на наступн≥ етапи:

1. –озпод≥л множини вимог ≥ орган≥зац≥€ њх в основн≥ функц≥ональн≥ групи.

2. ≤дентиф≥кац≥€ зовн≥шн≥х об'Їкт≥в, з €кими система повинна бути зв'€зана.

3. ≤дентиф≥кац≥€ основних вид≥в ≥нформац≥њ, що циркулюЇ м≥ж системою ≥ зовн≥шн≥ми об'Їктами.

4. –озробка контекстноњ д≥аграми, на €к≥й основн≥ функц≥ональн≥ групи представл€ютьс€ процесами, зовн≥шн≥ об'Їкти - зовн≥шн≥ми сутност€ми, основн≥ види ≥нформац≥њ - потоками даних м≥ж процесами ≥ зовн≥шн≥ми сутност€ми.

5. ‘ормуванн€ DFD першого р≥вн€ на баз≥ процес≥в попередньоњ контекстноњ д≥аграми, перев≥рка основних вимог по DFD першого р≥вн€.

6. ƒекомпозиц≥€ кожного процесу поточноњ DFD за допомогою детал≥зуючоњ д≥аграми, або специф≥кац≥њ процесу, перев≥рка основних вимог по DFD в≥дпов≥дного р≥вн€.

7. ƒодаванн€ визначень нових поток≥в у словник даних при кожн≥й њхн≥й по€в≥ на д≥аграмах.

8. ѕаралельне (≥з процесом декомпозиц≥њ) вивченн€ вимог (у тому числ≥ ≥ нових), розбивка њх на елементарн≥ й ≥дентиф≥кац≥€ процес≥в або специф≥кац≥й процес≥в, що в≥дпов≥дають цим вимогам. ” випадку, €кщо де€ку функц≥ю складно або неможливо виразити комб≥нац≥Їю процес≥в - побудова специф≥кац≥њ процесу.

9. ѕ≥сл€ побудови двох-трьох р≥вн≥в проведенн€ рев≥з≥њ з метою перев≥рки коректност≥ ≥ пол≥пшенн€ зрозум≥лост≥ модел≥.

“аким чином можна розробити лог≥чну функц≥ональну специф≥кац≥ю системи Ц детальний опис того, що повинна робити система, незалежно в≥д середовища реал≥зац≥њ.

—ловники даних

—ловник даних €вл€Ї собою певним чином орган≥зований список вс≥х елемент≥в даних системи з њхн≥ми точними визначенн€ми, що даЇ можлив≥сть р≥зним категор≥€м користувач≥в (в≥д системного анал≥тика до програм≥ста) мати загальне розум≥нн€ ус≥х вх≥дних ≥ вих≥дних поток≥в ≥ компонент сховищ.

 
 

“обто, словник даних в систем≥, де п≥дтримуЇтьс€ моделюванн€ поток≥в даних, маЇ збер≥гати описи вс≥х поток≥в, процес≥в, сховищ ≥ зовн≥шн≥х обТЇкт≥в за в≥дпов≥дною структурою.

Ќа рис.10.20. подана структура словника даних в ≥нструментальному засоб≥ BPWin.

ƒл€ опису розщепленн€/злитт€ поток≥в даних (тобто опису структури груп даних) може використовуватис€ так звана Ѕекуса-Ќаура форма (ЅЌ‘).

–озробка словник≥в даних один ≥з найб≥льш витратних за часом процес≥в системного анал≥зу, однак ≥ один ≥з найб≥льш важливих дл€ розум≥нн€ значенн€ елемент≥в моделей р≥зними користувачами.

 





ѕоделитьс€ с друзь€ми:


ƒата добавлени€: 2017-02-28; ћы поможем в написании ваших работ!; просмотров: 5444 | Ќарушение авторских прав


ѕоиск на сайте:

Ћучшие изречени€:

—амообман может довести до саморазрушени€. © Ќеизвестно
==> читать все изречени€...

2157 - | 2013 -


© 2015-2024 lektsii.org -  онтакты - ѕоследнее добавление

√ен: 0.07 с.