АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Примітка. Розглядаючи різні етапи ЖЦ програми, слід зазначити одну важливу обставину

Читайте также:
  1. Примітка
  2. Примітка
  3. Примітка
  4. Примітка
  5. Примітка
  6. Примітка
  7. Примітка
  8. Примітка
  9. Примітка
  10. Примітка
  11. Примітка
  12. Примітка

Розглядаючи різні етапи ЖЦ програми, слід зазначити одну важливу обставину. А саме, якщо поява RAD-інструментів дозволила істотно скоротити терміни етапу програмування, то відсутність відповідних засобів для перших двох етапів довгий час стримувала процес розроблення інформаційних систем. Розвиток методології ООАП був направлений на автоматизацію другого, а потім і першого етапів ЖЦ програми.

Методологія ООАП тісно пов'язана з концепцією автоматизованого розроблення програмного забезпечення (Computer Aided Software Engineering, CASE). Поява перших CASE–засобів була зустрінута з певною насторогою (див. розділ 13). З часом з'явилися як захоплені відгуки про їх застосування, так і критичні оцінки їх можливостей. Причин для таких суперечливих думок було декілька. Перша з них полягає в тому, що ранні CASE-засоби були простою надбудовою над деякою системою керування базами даних (СКБД). Хоча візуалізація процесу розроблення концептуальної схеми БД має важливе значення, вона не вирішує проблем розроблення інформаційних систем інших типів.

Друга причина має складнішу природу, оскільки пов'язана з графічною нотацією, реалізованою в тому або іншому CASE-засобі. Якщо мови програмування мають строгий синтаксис, то спроби запропонувати відповідний синтаксис для візуального представлення концептуальних схем БД були сприйняті далеко неоднозначно. З'явилося декілька підходів, які детальніше будуть розглянуті в розділі 14. На цьому фоні поява уніфікованої мови моделювання (Unified Modeling Language, UML), яка орієнтована на вирішення завдань перших двох етапів ЖЦ програм, була сприйнята з великим оптимізмом всім співтовариством корпоративних програмістів.

Останнє, на що слід звернути увагу, це усвідомлення необхідності побудови попередньої моделі програмної системи, яку, згідно сучасним концепціям ООАП, слід вважати результатом перших етапів ЖЦ програми. Оскільки мова UML навіть у своїй назві має відношення до моделювання, слід додатково зупинитися на цілому ряді достатньо важливих питань. Таким чином, ми переходимо до теми, яка традиційно не розглядається у виданнях з ООАП, але має найпряміше відношення до процесу побудови моделей і, власне, моделювання. Мова йде про методології системного аналізу і системного моделювання.

3.4. Методологія системного аналізу і системного моделювання

Системний аналіз як науковий напрям має давнішу історію, ніж ООП і ООАП, і власний предмет дослідження. Центральним поняттям системного аналізу є поняття системи, під якою розуміється сукупність об'єктів, компонентів або елементів довільної природи, які створюють деяку цілісність. Визначальною передумовою виділення деякої сукупності як системи є виникнення у неї нових властивостей, яких не мають складові її елементи. Прикладів систем можна привести достатньо багато – це персональний комп'ютер, автомобіль, людина, біосфера, програма і ін. Більш ортодоксальна точка зору припускає, що всі предмети, що оточують нас, є системами.

Найважливішими характеристиками будь-якої системи є її структура і процес функціонування. Під структурою системи розуміють стійку в часі сукупність взаємозв'язків між її елементами або компонентами. Саме структура зв'язує всі елементи і перешкоджає розпаду системи на окремі компоненти. Структура системи може відображати самі різні взаємозв'язки, у тому числі і вкладеність елементів однієї системи в іншу. У цьому випадку прийнято називати дрібнішу або вкладену систему підсистемою, а більшу – метасистемою.

Процес функціонування системи тісно пов'язаний із зміною її властивостей або поведінкою в часі. При цьому важливою характеристикою системи є її стан, під яким розуміється сукупність властивостей або ознак, які в кожний момент часу відображають найістотніші особливості поведінки системи.

Розглянемо наступний приклад. Як систему візьмемо "Автомобіль". Для цього випадку система охолоджування двигуна буде підсистемою "Автомобіля". З однієї сторони, двигун є елементом системи "Автомобіль". З іншої сторони, двигун сам є системою, що складається з окремих компонент, таких як циліндри, свічки запалення і ін. Тому система "Двигун" також буде підсистемою системи "Автомобіль".

Процес функціонування системи відображає поведінку системи в часі і може бути представлена як послідовна зміна її станів: якщо система змінює однин свій стан на інший, то прийнято говорити, що система переходить з одного стану в інший. Сукупність ознак або умов зміни станів системи в цьому випадку називається переходом. Для системи з дискретними станами процес функціонування може бути представлений у вигляді послідовності станів з відповідними переходами. Точніший графічний опис процесу функціонування систем буде наведений в розділі 9.

Методологія системного аналізу служить концептуальною основою системно-орієнтованої декомпозиції предметної області. У цьому випадку початковими компонентами концептуалізації є системи і взаємозв'язки між ними. При цьому поняття системи є більш загальним, ніж поняття класів і об'єктів в ООАП. Результатом системного аналізу є побудова деякої моделі системи або предметної області.

Поняття моделі так широко використовується в повсякденному житті, що придбало дуже багато смислових відтінків. Це і "Будинок моделей" відомого кутюрє, і модель престижної марки автомобіля, і модель політичного керівництва, і математична модель коливань маятника. Стосовно програмних систем нас цікавитиме тільки те поняття моделі, яке використовується в системному аналізі. А саме, під моделлю розумітимемо деяке уявлення про систему, що відображає найістотніші закономірності її структури і процес функціонування, що фіксується на деякій мові або в іншій формі.

Прикладів моделей можна привести достатньо багато. Наприклад, аеродинамічна модель гоночного автомобіля або проектованого літака, модель ракетного двигуна, модель коливальної системи, модель системи електропостачання регіону, модель виборчої компанії і ін.

Загальною властивістю всіх моделей є їх подібність оригінальній системі або системі-оригіналу. Важливість побудови моделей полягає в можливості їх використання для отримання інформації про властивості або поведінку системи-оригіналу. При цьому процес побудови і подальшого застосування моделей для отримання інформації про систему-оригінал отримав назву моделювання.


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.004 сек.)