Читайте также:
|
При вирішенні завдань використовується існуючий стандартний набір інструментів і надаються результати роботи у вигляді максимально загального набору інструментів, оформленого у відповідності зі стандартами, тобто у вигляді простих, але досить потужних і загальних функцій (класів), наділених документацією, із простими очевидними прикладами використання та позначених шляхів інтеграції з іншими інструментами (системами).
Метапрограмування - концепція програмування, пов'язана зі створенням програм, які породжують інші програми як результат своєї роботи, або програм, які змінюють себе під час виконання. Перше дозволяє одержувати програми при менших витратах часу й зусиль на кодування, ніж якби програміст писав їх вручну цілком, друге дозволяє поліпшити властивості коду.
Генерація коду
При цьому підході код програми не пишеться вручну, а створюється автоматично програмою-генератором на основі іншої, більше простої програми.
Такий підхід набуває сенсу, якщо при програмуванні виробляються різні додаткові правила (більше високо рівневі парадигми, виконання вимог зовнішніх бібліотек, стереотипні методи реалізації певних функцій та ін.). При цьому частина коду губить змістовне наповнення і стає лише механічним виконанням правил.
Самомодифікуємий код
Самомодифікуємий код - можливість змінювати або доповнювати себе під час виконання перетворює програму у віртуальну машину. Хоча така можливість існувала вже давно на рівні машинних кодів, з мета програмуванням пов'язують перенос подібних технологій у високо рівневі мови.
Одними із основних методів реалізації є:
Інтроспекція - подання внутрішніх структур мови у вигляді змінних вбудованих типів з можливістю доступу до них із програми. Дозволяє під час виконання переглядати, створювати й змінювати визначення типів, стік викликів, звертатися до змінного по імені, одержуваному динамічно й ін.
Інтерпретація довільного коду, представленого у вигляді рядка
Лекція 05
Функціонально-орієнтоване проектування
та проектування на основі структур даних
Проектування програмного забезпечення при структурному підході
Пр и проектуванні складного програмного забезпечення, насамперед, необхідно визначити структурні компоненти й зв'язки між ними. Отримана в результаті структура ПЗ повинна бути представлена у вигляді структурної або функціональної схем і специфікацій її компонентів.
Ст руктурне програмування -методологія розробки програмного забезпечення, в основі якої лежить подання програми у вигляді ієрархічної структури блоків. Запропонована в 70-х роках XX століття Э. Дейкстрой, розроблена та доповнена Н. Віртом.
Будь-яка програма являє собою структуру, побудовану із тр ьох типів базових конструкцій:
послідовне виконання
од нократне виконання операцій у тому порядку, у якому вони записані в тексті програми
ро згалуження
од нократне виконання однієї із двох або більше операцій, залежно від виконання деякої заданої умови
ци кл
ба гаторазове виконання однієї й тієї ж операції доти, поки виконується деяка задана умова (умова продовження циклу)
У програмі базові конструкції можуть бути вкладені одна в іншу довільним чином, але ніяких інших засобів керування послідовністю виконання операцій не передбачається.
Повторювані фрагменти програми (або не повторювані, але логічно цілісні обчислювальні блоки) можуть оформлятися у вигляді т.зв. підпрограм (процедур або функцій). У цьому випадку в тексті основної програми, замість поміщеного в підпрограму фрагмента, уставляється інструкція виклику підпрограми. При виконанні такий інструкцій виконується викликана підпрограма, після чого виконання програми триває з інструкції, що випливає за командою виклику підпрограми.
Розробка програми ведеться по-кроково, методом "зверху вниз".
Фу нкціональна схема
Функціональна схема - це схема взаємодії компонентів программ-ного забезпечення з описом інформаційних потоків, складу даних у пото-ках і вказівкою використовуваних файлів і пристроїв. Для зображення функцио-нальных схем використають спеціальні позначення, установлені стандартом.
Таблиця "Стандартні позначення для функціональних схем"
Функціональні схеми, більш інформативні, ніж структурні. На рисунку «Приклад функціональної схеми програмного комплексу» наведено функціональну схему програмного комплексу, що реалізовує різні методи сортування масивів.
Рисунок. Приклад функціональної схеми програмного комплексу
Ст руктурна схема розроблювального ПЗ
Структурна схема -схема, що відображає склад і взаємодію по керуванню частин розроблювального програмного забезпечення.
Структурна схема визначається архітектурою розроблювального ПЗ.
Розробку структурної схеми програми зазвичай виконують методом покрокової деталізації.
Структурні схеми пакетів програм розробляють для кожної програми пакету окремо, оскільки організація програм у пакети не передбачає передачі керування між ними.
Ко мпоненти структурної схеми
Компонентами структурної схеми пр ограмної системи або програмного комплексу можуть служити:
програми,
підсистеми,
бази даних,
бібліотеки ресурсів і т.п.
Приклад структурної схеми програмного комплексу, для рішення математичних завдань зображений на рисунку «Приклад структурної схеми програмного комплексу»:
Рисунок «Приклад структурної схеми програмного комплексу»
Пр иклади струкурних схем
Структурні карти Джексона
Структурна схема -це сукупність елементарних ланок об'єкту та зв'язків між ними, один з видів графічної моделі. Під елементарною ланкою розуміють частина об'єкта, системи керування й т.д., що реалізує елементарну функцію.
Техніка структурних карт Джексона заснована методі структурного програмування Джексона, що виявляє відповідність між структурою потоків даних і структурою програми. Основну увагу в методі сконцентровано на відповідності вхідних і вихідних потоків даних. Структури на діаграмах Джексона будуються із чотирьох основних компонентів, представлених на рисунку «Елементи структурних діаграм Джексона»:
оп ерація -блок кодів, що має один вхід й один вихід (а);
пр оходження -послідовне виконання операцій ліворуч праворуч (б);
ви бір -виконання однієї з операцій залежно від виконання усло-вия (в);
іт ерація -багаторазове виконання блоку (г)
Рисунок Елементи структурних діаграм Джексона
Приклад:
Техніка структурних карт Джексона заснована на методології структурного програмування Джексона і полягає в продукуванні діаграм (структурних карт) для графічного ілюстрування внутрішньо-модульних (а іноді і міжмодульних) зв'язків і документування проекту архітектури системи ПЗ. При цьому техніка дозволяє здійснювати проектування нижнього рівня структури ПЗ та на цьому етапі є близькою до традиційних блок-схем.
Ха рактеристики гарної моделі реалізації
Ст руктурні карти самі по собі нічого не говорять про якість моделі (проекта) реалізації, тому що є всього лише інструментом для демонстрації структури системи та складових її модулів, а також їх зв'язків один з одним.
Один з фундаментальних принципів структурного проектування полягає в тому, що більша система повинна бути розчленована на доступні для огляду модулі. При цьому істотним є те, що це розчленовування повинне бути виконано таким чином, щоб модулі були як можна більш незалежні (критерій зчеплення - couplіng), і щоб кожен модуль виконував єдину (пов’язану із загальним завданням) функцію (критерій зв’язності - cohesіon).
Крім цих двох взаємно-доповнючих критеріїв у структурному проектуванні існуює цілий ряд інших керівних принципів, які можуть застосовуватись для оцінки та поліпшення якості проекту на підставі структурних карт.
Рисунок Приклад "гарної" структурної карти Джексона
Зч еплення (couplіng)
Од ним зі способів оцінки якості проекту є аналіз зчеплення модулів. Зчеплення є мірою взаємозалежності модулів. У гарному проекті зчеплення повинні бути мінімізовані, тобто модулі повинні бути слабко-залежними (незалежними) настільки, наскільки це можливо.
Сл абке зчеплення мі ж модулями служить ознакою добре спроектованої системи по таких причинах:
- зменшення кількості з'єднань між двома модулями призводить до зменшення ймовірності появи "хвильового ефекту" (помилка в одному модулі впливає на роботу інших модулів);
- мінімізація ризику появи "ефекту брижі (ряби)" (внесення змін, наприклад, при виправленні помилки, приводить до появи нових помилок), тому що зміна впливає на мінімальну кількість модулів;
- при супроводі модуля відсутність необхідності турбуватися про внутрішні деталі інших модулів;
- спрощення системи для розуміння, наскільки це можливо.
Сл абке зчеплення мо же бути досягнуте за рахунок комбінування тр ьох на ступних сп особів дій:
- видалення необов'язкових зв'язків;
- зменшення кількості необхідних зв'язків;
- спрощенням необхідних зв'язків
Пр актичні рекомендації для ослаблення зчеплення модулів:
1. Створюйте мінімальні по кількості параметрів міжмодульні зв’язки.
2. Створюйте прямі (а не непрямі) міжмодульні зв’язки, оскільки інтерфейс між двома модулями найбільш зрозумілий (і, отже, менш складний), якщо людина може осягнути його відразу без попереднього посилання до деяких інших інформаційних об'єктів.
3. Створюйте локалізовані зв'язки (наприклад, значення списку параметрів обчислюйте безпосередньо перед викликом модуля).
4. Створюйте явні зв'язки. Красномовним прикладом неявного зв'язку є взаємодія модуля А с модулем У за рахунок модифікації області даних з В: для того, щоб людина, що супроводжує модуль У зрозуміла, за рахунок чого модифікується ця область даних, вона буде проробити доволі величезну роботу.
5. Створюйте гнучкі зв'язки для полегшення модифікацій.
Зчеплення є лише одним із критеріїв оцінки якості розбивки системи на частині: воно оцінює, наскільки добре модулі відділені один від іншого.
Зв ’язність (cohesіon)
Ін шим критерієм оцінки якості розчленовування системи є критерій зв’язності, що контролює, як дії в одному модулі зв'язані один з одним.
Фактично зчеплення й зв’язність є двома взаємозалежними способами виміру розчленовування системи на частини: зв’язність модуля часто визначає якість його зчеплення з іншими модулями.
Зв ’язність -це міра міцності з'єднання функціональних та інформаційних об'єктів усередині одного модуля.
Розміщення сильно зв'язаних об'єктів у тому самому модулі зменшує міжмодульні взаємозв'язки й взаємовпливи.
Рі вні зв’язності:
функціональна зв’язність,
Функціонально зв'язний модуль мі стить об'єкти, призначені для виконання одного і лише завдання, наприклад:
Розрахунок заробленої плати,
Зчитування даних кредитної карти.
Кожний із цих модулів має одну чітко визначену ціль, при його виклику виконується тільки одне завдання (при цьому воно виконується повністю без виконання будь-якого іншої додаткової дії).
по слідовна зв’язність,
Модуль має послідовну зв’язність, як що його об'єкти охоплюють підзадачі, для яких вихідні дані однієї з підзадач служать вхідними даними для наступної, наприклад:
Відкрити файл - Прочитати запис - Закрити файл.
ін формаційна зв’язність,
Інформаційно-зв'язний модуль мі стить об'єкти, що використають ті самі вхідні або вихідні дані. Припустимо, що ми хочемо з'ясувати деякі відомості про книгу, знаючи її ІSBN:
назву книги, її автора й ціну.
Ці три підзадачі є зв'язаними тому, що всі вони працюють із тим самим вхідним інформаційним об'єктом - ІSBN, що і робить цей модуль информационно зв'язним.
пр оцедурна зв’язність,
Процедурно зв'язний модуль є модулем, об'єкти якого включені в різні (і можливо незв'язні) підзадачі, у яких керування переходить від кожної підзадачі до наступної (відзначимо, що в послідовно зв'язному модулі дані, а не керування, переходили від однієї підзадачі до наступної).
Як приклад приведемо наступний перелік кроків у деякому процедурно зв'язному модулі:
1. Зробити зарядку
2. Прийняти душ
3. Зварити каву
4. Одягтися
5. Відправитися на службу
Відправитися на службу - це останній крок, внесений у список цього «модуля». Але, наприклад, дії Прочитати газету або Сходити в магазин можуть бути рівною мірою придатними кандидатами для кроку 5, оскільки кроки в цьому списку зв'язані тільки тим, що вони відбуваються в даному порядку протягом конкретного дня.
ти мчасова зв’язність,
Тимчасово зв'язним є модуль, об 'єкти якого включені в підзадачі, зв'язані часом виконання. Уявімо собі картину пізнього вечора:
1. Почистити зуби
2. Вимкнути телевізор
3. Вигнати кота в коридор
Ці дії ніяк не зв'язані один з одним, за винятком конкретного часу їхнього виконання. Всі вони - частина сталого режиму наприкінці дня.
ло гічна зв’язність,
Модулем з логічною зв’язністю є модуль, об'єкти якого сприяють вирішенню однієї загальної підзадачі, для якої ці об'єкти відібрані в зовнішньому стосовно модуля світі.
Наприклад, збираючись у поїздку, можна скласти собі наступний список:
1. Поїхати автомобілем
2. Поїхати поїздом
3. Поплисти на кораблі
4. Полетіти на літаку
Що зв'язує ці дії? Всі вони є способами переміщення. Але вирішальний момент полягає в тому, що для будь-якої поїздки людина повинна вибрати конкретний спосіб переміщення, тому що малоймовірно, що хто-небудь буде використовувати їх усі для окремої поїздки.
У такий спосіб логічно зв'язний модуль містить деяку кількість підзадач (дій) того самого загального виду. Для того, щоб його використати, необхідно вибрати саме ту частину (частини), які потрібні. Ці різні підзадачі повинні володіти одним і тільки одним інтерфейсом із зовнішнім світом. При цьому семантика кожного параметра залежить від використовуваної підзадачі.
ви падкова зв’язність.
Випадково зв'язковим є модуль, об 'єкти якого відповідають під-завданням, незначно зв'язаним один з одним:
1. Ремонтувати автомобіль
2. Пити пиво
3. Дивитися фільм
Випадково зв'язний модуль подібний логічно зв'язному модулю, його объекти не зв'язані ні потоками даних, ні потоками керування. Однак, підзадачі в логічно зв'язному модулі є принаймні однієї категорії; для випадково-зв'язного модуля навіть це невірно.
Фу нкціонально-орієнтована методологія
Функціональна методика потоків даних
Діаграма потоків даних
Data Flow Dіagrams (DFD) - діаграми потоків даних -методологія графічного структурного аналізу, що описує зовнішні по відношенню до системи джерела й адресати даних, логічні функції, потоки даних і сховища даних, до яких здійснюється доступ.
Рисунок «A sample data flow diagram»
Рисунок «Data Flow diagram: Level 1 Diagram»
Ді аграма потоків даних -один з основних інструментів структурного аналізу й проектування інформаційних систем, що існували до широкого поширення UML. Незважаючи на місце, що має, у сучасних умовах зсув акцентів від структурного до объектно-ориентированному підходу до аналізу й проектування систем, "стародавні" структурні нотації як і раніше широко й ефективно використаються як у бізнесі-аналізі, так й в аналізі інформаційних систем.
Історично склалося так, що для опису діаграм DFD використаються дві нотації - Йодана (Yourdon) і Гейна-Сарсона (Gane-Sarson), що відрізняються синтаксисом.
На наведеній нижче ілюстрації використана нотація Гейна-Сарсона:
Інформаційна система приймає ззовні потоки даних. Для позначення елементів середовища функціонування системи використається поняття зовнішньої сутності. Усередині системи існують процеси перетворення інформації, що породжують нові потоки даних. Потоки даних можуть надходити на вхід до інших процесів, міститися (і витягатися) у накопичувачі даних, передаватися до зовнішніх сутностей.
Модель DFD, як і більшість інших структурних моделей - ієрархічна модель. Кожен процес може бути підданий декомпозиції, тобто розбивці на структурні складові, відносини між якими в тій же нотації можуть бути показані на окремій діаграмі. Коли досягнута потрібна глибина декомпозиції - процес нижнього рівня супроводжується міні-специфікацією (текстовим описом).
Крім того, нотація DFD підтримує поняття підсистеми - структурної компоненти розроблювальної системи.
Нотація DFD - зручний засіб для формування контекстної діаграми, тобто діаграми, що показує розроблювальну систему у комунікації із зовнішнім середовищем. Це - діаграма верхнього рівня в ієрархії діаграм DFD. Її призначення - обмежити рамки системи, визначити, де закінчується розроблювальна система й починається середовище.
Ме та методики потоків даних
Метою методики потоків даних є побудова моделі розглянутої системи у вигляді діаграми потоків даних (Data Flow Dіagram - DFD), що забезпечує правильний опис виходів (відгуків системи у вигляді даних) при заданому впливі на вхід системи (подачі сигналів через зовнішні інтерфейси). Діаграми потоків даних є основним засобом моделювання функціональних вимог до проектованої системи.
При ст воренні діаграми потоків даних ви користаються чотири ос новних поняття:
- потоки даних,
По токи даних є абстракціями, що використаються для моделювання передачі інформації (або фізичних компонентів) з однієї частини системи в іншу. Потоки на діаграмах зображуються іменованими стрілками, ориен-тація яких указує напрямок руху інформації.
- процеси (роботи) перетворення вхідних потоків даних у вихідні,
Пр изначення процесу (роботи) складається в продукуванні вихідних потоків із вхідних відповідно до дії, що задає ім'ям процесу. Ім'я процесу повинне містити дієслово в невизначеній формі з наступним доповненням (наприклад, "одержати документи по відвантаженню продукції"). Кожен процес має унікальний номер для посилань на нього усередині діаграми, що може використатися разом з номером діаграми для одержання унікального індексу процесу у всій моделі.
- зовнішні сутності,
Сх овище (накопичувач) даних дозволяє на зазначених ділянках визначати дані, які будуть зберігатися в пам'яті між процесами. Фактично сховище представляє "зрізи" потоків даних у часі. Інформація, яку воно містить, може використовуватись в будь-який час після її одержання, при цьому дані можуть вибиратися в будь-якому порядку. Ім'я сховища повинно визначаи його вміст і бути іменником.
- накопичувачі даних (сховища).
Зо внішня сутність являє собою матеріальний об'єкт поза контекстом системи, що є джерелом або приймачем системних даних. Її ім'я повинно містити іменник, наприклад, "склад товарів". Передбачається, що об'єкти, представлені як зовнішні сутності, не повинні брати участь ні в якій обробці.
Пр оцес побудови DFD
Пр оцес побудови DFD починається зі створення так званої основної діаграми типу "зірка", на якій представлений моделюємий процес і всі зовнішні сутності, з якими він взаємодіє:
Рисунок «Діаграма типу «зірка»»
У випадку складного основного процесу він відразу представляється у вигляді декомпозиції на ряд взаимодіючих процесів.
Критерії складності методики потоків даних
- наявність великої кількості зовнішніх сутностей,
- багато-функціональність системи,
- її розподілений характер.
Зовнішні сутності виділяються стосовно основного процесу. Для їх визначення необхідно виділити постачальників і користувачів основного процесу, тобто всі об'єкти, які взаємодіють із основним процесом. На цьому етапі опис взаємодії полягає у виборі дієслова, що дає уявлення про те, як зовнішня сутність використовує основний процес або використовується ним.
Наприклад, основний процес - "облік звернень громадян", зовнішня сутність - "громадяни", опис взаємодії - "надає заяви та одержує відповіді". Цей етап є принципово важливим, оскільки саме він визначає границі моделюємої системи.
На наступному кроці відбувається декомпозиція основного процесу на набір взаємозалежних процесів, що обмінюються потоками даних. Самі потоки не конкретизуються, визначається лише характер взаємодії. Декомпозиція завершується, коли процес стає простим, тобто:
1. процес має два-три вхідних і вихідних потоку;
2. процес може бути описаний у вигляді перетворення вхідних даних у вихідні;
3. процес може бути описаний у вигляді послідовного алгоритму.
Після декомпозиції основного процесу для кожного підпроцесу будується аналогічна таблиця внутрішніх подій.
Наступним кроком після визначення повної таблиці подій виділяються потоки даних, якими обмінюються процеси і зовнішні сутності.
Найпростіший спосіб їх виділення полягає в аналізі таблиць подій. Події перетворюються в потоки даних від ініціатора події до запитуваного процесу, а реакції - у зворотний потік подій.
Після побудови вхідних і вихідних потоків аналогічним чином будуються внутрішні потоки. Для їх виділення для кожного із внутрішніх процесів виділяються постачальники та користувачі інформації.
Якщо постачальник або споживач інформації представляє процес збереження або запиту інформації, то вводиться сховище даних, для якого даний процес є інтерфейсом.
Після побудови потоків даних діаграма повинна бути перевірена на повноту та несуперечність.
По внота діаграми за безпечується, якщо в системі немає «висячих» процесів, не використовуваних у процесі перетворення вхідних потоків у вихідні.
Не суперечність системи за безпечується виконанням наборів формальних правил про можливі типи процесів:
на діаграмі не може бути потоку, що зв'язує дві зовнішні сутності - ця взаємодія видаляється з розгляду;
жодна сутність не може безпосередньо одержувати або віддавати інформацію в сховище даних - сховище даних є пасивним елементом, керованим за допомогою інтерфейсного процесу;
два сховища даних не можуть безпосередньо обмінюватися інформацією - ці сховища повинні бути об'єднані.
Пе реваги та недоліки
До пе реваг методики DFD ві дносяться:
- можливість однозначно визначити зовнішні сутності, аналізуючи потоки інформації усередині та поза системою;
- можливість проектування зверху вниз, що полегшує побудову моделі "як повинно бути";
- наявність специфікацій процесів нижнього рівня, що дозволяє здолати логічну незавершеність функціональної моделі та побудувати повну функціональну специфікацію розроблювальної системи.
До недоліків ме тодики DFD ві днесемо:
- необхідність штучного введення керуючих процесів, оскільки керуючі впливи (потоки) і керуючі процеси із точки зору DFD нічим не відрізняються від звичайних;
- відсутність поняття часу, тобто відсутність аналізу тимчасових проміжків при перетворенні даних (всі обмеження за часом повинні бути уведені в специфікаціях процесів).
Дата добавления: 2015-04-26; просмотров: 25 | Поможем написать вашу работу | Нарушение авторских прав |