загрузка...
загрузка...
На головну

Проектування програмного забезпечення при структурному підході

  1.  VII. Матеріали методичного забезпечення заняття.
  2.  АВТОМАТИЗОВАНЕ ПРОЕКТУВАННЯ ТЕХНОЛОГІЇ І ОБЛАДНАННЯ
  3.  Адміністративно-правова організація в сфері забезпечення державної безпеки.
  4.  Аналіз забезпечення ресурсами
  5.  Аналіз вимог і визначення специфікації ПО при структурному підході
  6.  Аналіз вимог і визначення специфікацій програмного забезпечення при об'єктному підході
  7.  Анатомо-фізіологічні механізми забезпечення безпеки і захисту людини від негативних впливів

Проектування програмного забезпечення починають з визначення його структури.

5. 1. Розробка структурної та функціональної схем.

Процес проектування складного програмного забезпечення починають з уточнення його структури, т. Е. Визначення структурних компонентів і зв'язків між ними. Результат уточнення структури може бути представлений у вигляді структурної та / або функціональної схем і опису (специфікацій) компонентів.

Структурна схема розроблюваного програмного забезпечення

Структурної називають схему, яка відображатиме склад і взаємодія з управління частин розроблюваного програмного забезпечення.

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

Найпростіший вид програмного забезпечення - програма, яка в якості структурних компонентів може включати тільки підпрограми і бібліотеки ресурсів.

Розробку структурної схеми програми зазвичай виконують методом покрокової деталізації.

Структурними компонентами програмної системи або програмного комплексу можуть служити програми, підсистеми, бази даних, бібліотеки ресурсів і т. П.

Структурна схема програмного комплексу демонструє передачу управління від програми-диспетчера відповідною програмою (рис. 1.1).

Мал. 5.1. Приклад структурної схеми програмного комплексу.

Структурна схема програмної системи, Як правило, показує наявність підсистем або інших структурних компонентів. На відміну від програмного комплексу окремі частини (підсистеми) програмної системи інтенсивно обмінюються даними між собою і, можливо, з основною програмою. Структурна ж схема програмної системи цього зазвичай не показує (рис. 1.2).


Мал. 5.2. Приклад структурної схеми програмної системи.

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

функціональна схема

Функціональна схема або схема даних (ГОСТ 19. 701-90) - схема взаємодії компонентів програмного забезпечення з описом інформаційних потоків, складу даних в потоках і зазначенням використовуваних файлів і пристроїв. Для зображення функціональних схем використовують спеціальні позначення, встановлені стандартом.

Функціональні схеми більш інформативні, ніж структурні. На рис. 1.3 для порівняння наведені функціональні схеми програмних комплексів і систем.

а).


б).

Мал. 5.3. Приклади функціональних схем: а - комплекс програм, б - програмна система.

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

5.2. Використання методу покрокової деталізації для проектування структури програмного забезпечення.

Структурний підхід до програмування в тому вигляді, в якому він був сформульований в 70-х роках XX ст., Пропонував здійснювати декомпозицію програм методом покрокової деталізації. Результатом декомпозиції є структурна схема програми, яка являє собою багаторівневу ієрархічну схему взаємодії підпрограм з управління. Мінімально така схема відображає два рівня ієрархії, т. Е. Показує загальну структуру програми. Однак той же метод дозволяє отримати структурні схеми з великою кількістю рівнів.

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

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

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

Крім цього, доцільно дотримуватися наступних рекомендацій:

- Не відокремлювати операції ініціалізації і завершення від відповідної обробки, так як модулі ініціалізації і завершення мають погану зв'язність (тимчасову) і міцне зчеплення (з управління);

- Чи не проектувати занадто спеціалізованих або занадто універсальних модулів, так як проектування надмірно спеціальних модулів збільшує їх кількість, а проектування надмірно універсальних модулів підвищує їх складність;

- Уникати дублювання дій в різних модулях, так як при їх зміні виправлення доведеться вносити в усі фрагменти програми, де вони виконуються - в цьому випадку доцільно просто реалізувати ці дії в окремому модулі;

- Групувати повідомлення про помилки в один модуль за типом бібліотеки ресурсів, тоді буде легше узгодити формулювання, уникнути дублювання повідомлень, а також перевести повідомлення на іншу мову.

При цьому, описуючи рішення кожного завдання, бажано використовувати не більше 1-2-х структурних керуючих конструкцій, таких, як цикл-поки або розгалуження, що дозволяє чіткіше уявити собі структуру організованого обчислювального процесу.

Розбиття на модулі при даному виді проектування виконується евристичний, виходячи з рекомендованих розмірів модулів (20-60 рядків) і складності структури (дві-три вкладених керуючих конструкції). В принципі в якості модуля (підпрограми) можна реалізувати рішення підзадач, сформульованих на будь-якому етапі процесу деталізації, однак визначальну роль при розбитті програми на модулі відіграють принципи забезпечення технологічності модулів.

Для аналізу технологічності отриманої ієрархії модулів доцільно використовувати структурні карти Константайна або Джексона.

5. 3. Структурні карти Константайна.

На структурної карті відносини між модулями представляють у вигляді графа, вершинам якого відповідають модулі і загальні області даних, а дуг - міжмодульні виклики і звернення до загальних областям даних.

Розрізняють чотири типи вершин (рис. 1.4.):

- Модуль - підпрограма,

- Підсистема - програма,

- Бібліотека - сукупність підпрограм, розміщених в окремому модулі,

- Область даних - спеціальним чином оформлена сукупність даних, до якої можливе звернення ззовні.

а). б). в). г).

Мал. 5.4. Позначення вершин по стандартам IBM, ISO і ANSI:

а - модуль; б - підсистема; в - бібліотека; г - область даних.

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


а). б). в).

Мал. 5.5. Позначення типу виклику:

а - послідовний виклик; б - паралельний виклик; в - виклик співпрограми.

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

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

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

Структурні карти Константайна дозволяють наочно уявити результат декомпозиції програми на модулі і оцінити її якість, т. Е. Відповідність до рекомендацій структурного програмування (зчеплення і зв'язність).

5.4. Проектування структур даних.

Під проектуванням структур даних розуміють розробку їх уявлень в пам'яті. Основними параметрами, які необхідно враховувати при проектуванні структур даних, є:

- Вид інформації, що зберігається кожного елемента даних;

- Зв'язку елементів даних і вкладених структур;

- Час зберігання даних структури ( «час життя»);

- Сукупність операцій над елементами даних, вкладеними структурами і структурами в цілому

Вид інформації, що зберігається визначає тип відповідного поля пам'яті. Як елементи даних в залежності від використовуваної мови програмування можуть розглядатися:

- Цілі і речові числа різних форматів;

- Символи;

- Булевские значення: true і false;

а також деякі структурні типи даних, наприклад:

- Рядки;

- Записи;

- Спеціально оголошені класи.

При цьому для числових полів дуже важливо правильно визначити діапазон можливих значень, а для строкових даних - максимально можливу довжину рядка.

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

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

Подання даних в оперативній пам'яті

Розрізняють дві базові структури організації даних в оперативній пам'яті: векторну і списковую.

векторна структура являє собою сукупність електронних даних пам'яті, які використовуються для розміщення полів даних (рис. 1.6.).

Мал. 5.6. Векторна структура пам'яті.

Послідовне розміщення організованих структур даних дозволяє здійснювати прямий доступ до елементів: за індексом (сукупності індексів) - в масивах або рядках або по імені поля - в записах або об'єктах.

Однак виконання операцій додавання і видалення елементів при використанні векторних структур для розміщення елементів масивів може зажадати здійснення багаторазових зрушень елементів.

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

спискові структури будують зі спеціальних елементів, що включають крім інформаційної частини ще й один або кілька покажчиків - адрес елементів або вкладених структур, пов'язаних з даним елементом. Розміщуючи подібні елементи в динамічної пам'яті можна організовувати різні внутрішні структури (рис. 1.7.).

а).


б).

в).

Мал. 5.7. Приклади спискові структур пам'яті:

а - лінійний однозв'язний список; б - деревовидний список; в - n-зв'язний список.

Однак при використанні спискові структур слід пам'ятати, що:

- Для зберігання покажчиків необхідна додаткова пам'ять;

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

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

Зазвичай векторне подання використовують для зберігання статичних множин, таблиць (одновимірних і багатовимірних), наприклад, матриць, рядків, записів, а також графів, представлених матрицею суміжності, матрицею інцидентності або аналітично. Спискові уявлення зручно для зберігання динамічних (змінних) структур і структур зі складними зв'язками.

У найбільш відповідальних випадках при виборі внутрішнього уявлення доцільно визначати обчислювальну складність виконання найбільш часто зустрічаються операцій зі структурою даних або її елементами для різних варіантів. А також оцінювати їх емкостную складність.

Подання даних у зовнішній пам'яті

Сучасні операційні системи підтримують два способи організації даних у зовнішній пам'яті: послідовний і з прямим доступом.

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

Прямий доступ можливий тільки для дискових файлів, обмін інформацією з якими здійснюється записами фіксованої довжини (виконавчі файли З або типізовані файли Pascal). Адреса запису такого файлу можна визначити по її номеру, що і дозволяє безпосередньо звертатися до потрібного запису.

При виборі типу пам'яті для розміщення структур даних слід мати на увазі, що:

- В оперативній пам'яті розміщують дані, до яких Ви хочете отримувати швидкий доступ, як для читання, так і для їх зміни;

- У зовнішній - дані, які потрібно буде відновити після завершення програми.

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

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

5.5. Проектування програмного забезпечення, засноване на декомпозиції даних.

Практично одночасно були запропоновані методики проектування програмного забезпечення Джексона і Варнье-Орра, засновані на декомпозиції даних. Обидві методики призначені для створення «простих» програм, які працюють зі складними, але ієрархічно організованими структурами даних. При необхідності розробки програмних систем в обох випадках пропонується спочатку розбити систему на окремі програми, а потім використовувати дані методики.

Методика Джексона

При створенні своєї методики М. Джексон виходив з того, що структури вихідних даних і результатів визначають структуру програми.

Методика заснована на пошуку відповідників структур вихідних даних і результатів. Однак при її застосуванні можливі ситуації, коли на якихось рівнях відповідності відсутні. Наприклад, записи вихідного файлу сортовані не в там порядку, в якому відповідні рядки повинні з'являтися в звіті. Такі ситуації були названі «зіткненнями», Виділяють кілька типів зіткнень, які дозволяють по-різному. При різній послідовності записів їх просто сортують до обробки.

Розробка структур програми відповідно до методики виконується наступним чином:

- Будують зображення структур вхідних і вихідних даних;

- Виконують ідентифікацію зв'язків обробки (відповідності) між цими даними;

- формують структуру програми на підставі структур даних і виявлених відповідностей;

- додають блоки обробки елементів, для яких не виявлені відповідності;

- Аналізують і обробляють невідповідності, т. Е. Дозволяють «зіткнення»;

- Додають необхідні операції (введення, висновок, відкриття / закриття файлів і т. П.); - Записують програму в структурній нотації (псевдокоді).

Методика Варнье-Орра.

Методика Варнье-Орра базується на тому положенні, що і методика Джексона, але основними при побудові діаграми вважаються структури вихідних даних і, якщо структури вхідних даних не відповідають структурам вихідних, то їх допускається змінювати. Таким чином, ліквідується основна причина зіткнень.

Однак на практиці не завжди існує можливість перестановки структур вхідних даних: ці структури вже можуть бути строго задані, наприклад, якщо використовуються дані, отримані при виконанні програм, тому дану методику застосовують рідше.

Як випливає з вищевикладеного, методики Джексона і Варнье-Орра можуть використовуватися тільки в тому випадку, якщо дані розроблюваних програм можуть бути представлені у вигляді ієрархії або сукупності ієрархій.

5.6. Case-технології, засновані на структурних методологіях аналізу і проектування.

До нашого часу накопичений досвід успішного використання більшості відомих методологій структурного аналізу і проектування в відповідних CASE-засобах. Найбільшого поширення набули методології: SADT (3, 3%), структурного системного аналізу Гейне-Сарсона (20, 2%), структурного аналізу і проектування Йордана-Де (36, 5%), розвитку систем Джексона (7, 7%), розвитку структурних DSSD (Data Structured System Development) Варнье-Орра (5, 8%), аналіз проектування систем реального часу Уорда-Меллора і Хатлі, інформаційного моделювання Мартіна (22, 1%).

Як видно з наведених статистичних даних, найбільше застосування знайшли структурні методології, що використовують діаграми потоків даних. Це викликано двома причинами:

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

- Розроблений метод побудови проектних специфікацій (структурних карт Джексона або Костантайна) по діаграмах потоків даних, що дозволяє автоматично створювати такі специфікації.





 Визначення вимог до ПО і вихідних даних для його проектування |  Проектування ПО при об'єктному підході |  тестування ПЗ |  Налагодження програмного забезпечення |

загрузка...
© um.co.ua - учбові матеріали та реферати