2.3. Функціональна специфікація програмного засобу.

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

Функціональна специфікація складається з трьох частин:

• описи зовнішнього інформаційного середовища, до якого повинні застосовуватися програми ПС, що розробляється;

• визначення функцій ПС, визначених на безлічі станів цього інформаційного середовища (такі функції називатимемо зовнішніми функціями ПС);

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

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

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

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

2.4. Вибір архітектури програмного забезпечення. Структура і формат даних.

Вибір архітектури програмного забезпечення

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

Архітектурою програмного забезпечення називають сукупність базових концепцій (принципів) його побудови.

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

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

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

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

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

З точки зору кількості користувачів, що працюють з однією копією ПО, розрізняють:

• розраховану на одного користувача архітектуру;

• розраховану (мережеву) на багато користувачів архітектуру.

Крім того, у рамках розрахованої на одного користувача архітектури розрізняють:

• програми. Програма (program, routine) - впорядкована послідовність формалізованих інструкцій для вирішення завдання за допомогою комп'ютера. Це найпростіший вид архітектури, який зазвичай використовується при рішенні невеликих завдань;

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

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

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

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

Основні класи архітектури програмних засобів.

Розрізняють наступні основні класи архітектури програмних засобів:

• цілісна програма;

• комплекс автономно виконуваних програм;

• шарувата програмна система;

• колектив паралельно виконуваних програм.

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

Комплекс автономно виконуваних програм складається з набору програм, такого, що:

• будь-яка з цих програм може бути активізована (запущена) користувачем;

• при виконанні активізованої програми інші програми цього набору не можуть бути активізовані до тих пір, поки не закінчить виконання активізована програма;

• усі програми цього набору застосуються до одного і того ж інформаційного середовища.

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

Шарувата програмна система складається з деякої впорядкованої сукупності програмних підсистем, званих шарами, такий, що:

• на кожному шарі нічого не відомо про властивості (і навіть існуванні) наступних (вищих) шарів;

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

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

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

Як приклад розглянемо використання такої архітектури для побудови операційної системи. Таку архітектуру застосував Дейкстра при побудові операційної системи THE.

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