конспект лекцій (ТСПП). Конспект лекцій з дисципліни 07 технологія створення програмних продуктів напряму 050101 Компютерні науки
 Скачать 14.87 Mb.
|
Тема 2. Архітектури програмних застосувань .План лекції 1. Аналіз вимог і визначення специфікацій програмного забезпечення. 2. Визначення вимог до програмних продуктів. 3. Функціональні вимоги. Експлуатаційні вимоги. Самостійна робота 4. Вибір архітектури програмного забезпечення. Структура і формат даних. 5. Статичні, напівстатичні і динамічні структури. Класифікація структур даних. 6. Прості структури даних. 7. Статичні структури даних. Напівстатичні структури даних. 8. Динамічні структури даних Зміст лекції 2.1. Аналіз вимог і визначення специфікацій програмного забезпечення.Архітектура ПС - це його будова як воно видно (чи повинно бути видно) из-вне його, тобто представлення ПС як системи, що складається з деякої сукупності взаємодіючих підсистем. Як такі підсистеми виступають зазвичай окремі програми. Розробка архітектури є першим етапом боротьби із складністю ПС, на якому реалізується принцип виділення відносно незалежних компонент. Основні завдання розробки архітектури ПС :
З урахуванням рішень, що приймаються на цьому етапі, виробляється подальша конкретизація і функціональних специфікацій. 2.2. Визначення вимог до програмних продуктів.Для контролю архітектури ПС використовується суміжний контроль иручная імітація. Суміжний контроль архітектури ПС згори - це її контроль розробниками зовнішнього опису : розробниками специфікації якості і розробниками функціональної специфікації. Суміжний контроль архітектури ПС знизу - це її контроль потенційними розробниками програмних підсистем, що входять до складу ПС відповідно до розробленої архітектури. Ручна імітація архітектури ПС виробляється аналогічно ручній імітації функціональної специфікації, тільки метою цього контролю є перевірка взаємодії між програмними підсистемами. Так само як і у разі ручної імітації функціональної специфікації ПС мають бути спочатку підготовлені тести. Потім група розробників повинна для кожного такого тіста імітувати роботу кожної програмної підсистеми, що входить до складу ПС. При цьому роботу кожної підсистеми імітує один який-небудь розробник (не автор архітектури), ретельно виконуючи усі взаємодії цієї підсистеми з іншими підсистемами (точніше, з розробниками, що їх імітують) відповідно до розробленої архітектури ПС. Тим самим забезпечується імітаційне функціонування ПС в цілому у рамках архітектури, що перевіряється. Визначення вимог до програмного засобу. Визначення вимоги до ПС є початковим документом розробки ПС - завданням, що виражає в абстрактній формі потреби користувача. Вони у загальних рисах визначають задум ПС, характеризують умови його використання. Неправильне розуміння потреб користувача трансформуються в помилки зовнішнього опису. Тому розробка ПС починається із створення документу, достатній повно користувача, що характеризує потреби, і що дозволяє розробникові адекватно сприймати ці потреби. Визначення вимог є сумішшю фрагментів на природній мові, різних таблиць і діаграм. Така суміш, має бути зрозумілою користувачеві, що не знає спеціальних позначень програмістів. Зазвичай у визначенні вимог не міститься формалізовані фрагменти, окрім випадків досить для цього підготовлених користувачів (наприклад, математично) - формалізація цих вимог складає зміст подальшої роботи колективу розробників. Неправильне розуміння вимог замовником, користувачами і розробниками пов'язане зазвичай з різними поглядами на роль необхідного ПС в середовищі його використання. Тому важливим завданням при створенні визначення вимог є встановлення контексту використання ПС, що включає зв'язки між цим ПС, апаратурою і людьми. Краще всього цей контекст у визначенні вимог представити в графічній формі (у вигляді діаграм) з додаванням описів сутей використовуваних об'єктів (блоків ПС, компонент апаратури, персоналу і тому подібне) і характеристики зв'язків між ними. Відомі три способи визначення вимог до ПС:
У керованій користувачем розробці визначення вимог до ПС визначаються замовником, що представляє організацію користувачів. Це відбувається зазвичай в тих випадках, коли організація користувачів (замовник) укладає договір на розробку необхідного ПС з колективом розробників і вимоги до ПС є частиною цього договору. Роль розробника ПС в створенні цих вимог зводиться, в основному, в з'ясуванні того, наскільки зрозумілі йому ці вимоги з відповідною критикою даного документу. Це може призводити до створення декількох редакцій цього документу в процесі укладення вказаного договору. У контрольованій користувачем розробці вимоги до ПС формулюються розробником за участю представника користувачів. Роль користувача в цьому випадку зводиться до інформування розробника про свої потреби в ПС і контролю за тим, щоб формульовані вимоги дійсно виражали його потреби в ПС. Кінець кінцем розроблені вимоги, як правило, затверджуються представником користувача. У незалежній від користувача розробці вимоги до ПС визначаються без якої-небудь участі користувача (на повну відповідальність розробника). Це відбувається зазвичай тоді, коли розробник вирішує створити ПС широкого застосування з розрахунку на те, розроблене їм ПС знайде попит на ринку програмних засобів. З точки зору забезпечення надійності ПС найбільш прийнятною є контрольована користувачем розробка. |