
- •Питання
- •Проектування пз – проектування, цілі проектування, вимоги до пз
- •Життєвий цикл пз
- •Моделі життєвого циклу
- •Цілісність даних та надійність
- •Шаблони проектування
- •Класифікація архітектур пз
- •Обробка помилок, виключень та небажаних умов
- •Діаграми подій
- •Зв’язність та зв’язаність (coupling and cohesion)
- •Повторне використання коду
- •11. Ітеративне й інкрементне проектування
- •12.Функціональна методика потоків даних
- •13. Структурна схема розроблюваного пз
- •14. Проектування програмного забезпечення при структурному підході
- •15. Типи компонентних структур та основі означення
- •16. Методологія компонентної розробки пз
- •17. Приклади компонентних середовищ
- •18. Планування архітектури
- •1. Архітектура впливає на структуру компанії-розроблювача.
- •2. Архітектура здатна впливати на завдання розроблювача.
- •3. Архітектура може впливати на вимоги, висунуті замовником щодо наступної системи (якщо вона заснована на тій же архітектурі, що й попередня).
- •4. Процес конструювання систем поповнює досвід архітектора.
- •5. Окремі «віхові» системи.
- •19. Програмний процес та архітектурно-економічний цикл
- •20. Архітектурні зразки, еталонні моделі та еталонні варіанти архітектури
- •Архітектурні структури і подання
4. Процес конструювання систем поповнює досвід архітектора.
Архітектор може застосувати при роботі над наступними архитектурами існуючий дослвід, і, відповідно, розширювати базу досвіду компанії. Успіх системи, побудованої на основі інструментальних магістралей, .NET або інкапсульованих кінцевих автоматів, стимулює побудову аналогічних систем і надалі. З іншого боку, невдалі варіанти архітектури рідко використовуються повторно.
5. Окремі «віхові» системи.
Іноді зробити сильний вплив і навіть внести зміни в культуру програмної інженерії (технічну базу, у рамках якої навчаються та працюють конструктори) здатні окремі системи. Такий ефект на індустрію в 1960-х і початку 1970-х рр. зробили перші реляційні бази даних, генератори компіляторів і табличні операційні системи; в 1980-х - перші електронні таблиці та системи керування вікнами. В 1990-х рр. таким каталізатором виступив Інтернет. Подібні інновації завжди знаходять висвітлення в наступних системах.
Із цих і деяких інших механізмів зворотного зв'язку і утвориться архітектурно-економічний цикл. На Рисунку "Архітектурно-економічний цикл" зображені фактори впливу культури та економіки компанії-розроблювача на програмну архітектуру. У свою чергу архітектура виявляється основним визначальним фактором при завданні властивостей розроблювальної системи або систем.
19. Програмний процес та архітектурно-економічний цикл
Програмним процесом (software process) називаються дії по організації, нормуванню та керуванню розробкою програмного забезпечення. Нижче наведений перелік операцій, спрямованих на створення програмної архітектури, її застосування для реалізації проектного рішення, а згодом - на реалізацію або керування розвитком цільової системи або додатка.
Операції програмної архітектури:
створення економічної моделі системи;
виявлення вимог;
створення нової або вибір існуючої архітектури;
документування та поширення відомостей про архітектуру;
аналіз або оцінка архітектури;
реалізація системи на основі архітектури;
перевірка відповідності реалізації архітектурі.
Етапи розробки архітектури
Як слідує зі структури АЕЦ, між різними етапами розробки архітектури існують розгорнуті відношення зворотного зв'язку
Створення економічної моделі системи.
Створення економічної моделі не обмежується оцінкою потреби в системі на ринку. Цей етап виконує істотну роль у контексті створення та звуження вимог.
Скільки повинен коштувати продукт?
Який цільовий сегмент ринку?
Наскільки швидко продукт повинен вийти на ринок?
Чи належний він взаємодіяти з іншими системами?
Є чи які-небудь системні обмеження, у рамках яких він повинен існувати?
Виявлення вимог.
Способів довідатися, чого ж, нарешті, хочуть зацікавлені особи, безліч. Зокрема , у рамках об’ектно-орієнтованого аналізу для фіксації вимог використовуються сценарії, або елементи Use Case. Для системи з підвищеними вимогами до безпеки застосовуються більше строгі методики - наприклад, моделі кінцевих автоматів і мови формальних специфікацій.
Стосовно до системи, що конструюється необхідно прийняти центральне, основне рішення - наскільки в ній будуть відображені інші, вже сконструйовані системи. Оскільки в сьогоднішніх умовах знайти систему, що не має подібностей з іншими системами, досить непросто, методики виявлення вимог припускають знання характеристик попередніх систем.
Моделювання.
Досвідчені системи допомагають моделювати потрібне поводження, проектувати користувальницькі інтерфейси та проводити аналіз споживання ресурсів. Таким чином, в очах зацікавлених осіб система стає "реальною", а процес прийняття рішень по проектуванню системи і її користувальницького інтерфейсу значно прискорюється.
Поза залежністю від методики виявлення вимог, бажані атрибути якості конструюємої системи обумовлюють її кінцевий вид. Для забезпечення окремих атрибутів якості архітекторами вже давно застосовуються ті або інші тактики. Архітектурні рішення компромисні, однак при специфікуванні вимог не всі ці компроміси очевидні. З усією ясністю вони проявляються лише після створення архітектури; тоді ж приймаються рішення щодо сортування вимог відповідно до пріоритетів.
Створення або вибір архітектури.
Основною умовою стабільного проектування системи є дотримання концептуальної цілісності, а вона може виявитися лише у вузькому колі людей, що спільно працюють над проектуванням її архітектури
Поширення відомостей про архітектуру.
Для того щоб архітектура дійсно стала основою проекту, її суть необхідно чітко та недвозначно донести до всіх зацікавлених осіб. Розроблювачі повинні розуміти, що від них потрібно, тестувальники повинні усвідомлювати структуру своїх завдань, менеджмент повинен знати графік і т.д. Для того щоб цієї мети можна було домогтися, документування архітектури повинне бути інформативним, ясним і зрозумілим людям різних професій.
Аналіз або оцінка архітектури.
У процесі проектування завжди розглядається безліч варіантів проекту. Деякі з них забраковуються відразу. Із числа інших в остаточному підсумку відбирається найбільш вдаллий. Одне із глобальних завдань, що стоять перед будь-яким архітектором, полягає саме в тому, щоб зробити цей вибір раціонально.
Оцінити архітектуру на предмет атрибутів якості, які вона забезпечує, зовсім необхідно - без цього не можна бути впевненим у тім, що кінцева система зможе задовольнити всі потреби зацікавлених осіб. Все більше поширення одержують методики аналізу, орієнтовані на оцінку повідомлюваних системі архітектурою атрибутів якості. Сценарні методики забезпечують найбільш універсальну та ефективну оцінку архітектури. Найбільш зріла методична база характерна для методу аналізу компромісних архітектурних рішень (Archіtecture Tradeoff Analysіs Method, ATAM); метод аналізу вартості та ефективності (Cost Benefіt Analysіs Method, CBAM), з іншого боку, передбачає вкрай коштовну можливість ув'язування архітектурних рішень із їх економічним змістом.