Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Основи автоматизованого проектування видавничих систем
Інформація про навчальний заклад
ВУЗ:
Інші
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Не вказано
Інформація про роботу
Рік:
2003
Тип роботи:
Конспект лекцій
Предмет:
Основи автоматизованого проектування видавничих систем
Частина тексту файла (без зображень, графіків і формул):
Курс лекцій
з дисципліни
“Основи автоматизованого проектування
видавничих систем”
для студентів інженерного рівня підготовки по спеціальності
“Видавничо-поліграфічна справа” (шифр 0918)
Львів-2003
Зміст
1. Основи методології проектування видавничих систем
1.1. Життєвий цикл видавничих систем.
1.2. Моделі життєвого циклу ВС
1.3. Методології й технології проектування ВС
1.3.1. Загальні вимоги до методології й технології
1.3.2. Методологія RAD
2. Структурний підхід до проектування ІС
2.1. Сутність структурного підходу
2.2. Методологія функціонального моделювання SADT
2.2.1. Склад функціональної моделі
2.2.2. Ієрархія діаграм
2.2.3. Типи зв'язків між функціями
2.3. Моделирование потоков данных (процессов)(1c)
2.3.1. Зовнішня суть
2.3.2. Системи і підсистеми
2.3.3. Процеси
2.3.4. Накопичувачі даних
2.3.5. Потоки даних
2.3.6. Побудова ієрархії діаграм потоків даних
2.4. Моделювання даних
2.4.1. Case-метод Баркера
2.4.2. Методологія IDEF1
2.4.2. Критерії оцінки і вибору
2.4.3. Подход, используемый в CASE-средстве Vantage Team Builder
2.5. Пример использования структурного подхода
2.5.1. Описание предметной области
2.5.2. Организация проекта
3. Программные средства поддержки жизненного цикла ПО
3.1. Методологии проектирования ПО как программные продукты. Методология DATARUN и инструментальное средство SE Companion
3.1.1. Методология DATARUN
3.1.2. Инструментальное средство SE Companion
3.2. CASE-средства. Общая характеристика и классификация
4. Технологія впровадження CASE-засобів
4.1. Визначення потреб в CASE-засобах
4.1.1. Аналіз можливостей організації
4.1.2. Визначення організаційних потреб
4.1.3. Аналіз ринку CASE-засобів
4.1.4. Визначення критеріїв успішного впровадження
4.1.5. Розробка стратегії впровадження CASE-засобів
4.2. Оцінка і вибір CASE-засобів
4.2.1. Загальні відомості
4.2.2. Процес оцінки
4.2.3. Процес вибору
4.2.4. Критерії оцінки і вибору
4.2.4.1. Надійність
4.2.4.2. Простота використання
4.2.4.3. Ефективність
4.2.4.4. Супроводжуваність
4.2.4.5. Переносимість
4.2.4.6. Загальні критерії
4.2.5. Приклад підходу до визначення критеріїв вибору CASE-засобів
4.3. Виконання пілотного проекту
4.4. Перехід до практичного використання CASE-засобів
5. Характеристики CASE-засобів
5.1. Silverrun+JAM
5.1.1. Silverrun
5.1.2. JAM
5.2. Vantage Team Builder (Westmount I-CASE) + Uniface
5.2.1. Vantage Team Builder (Westmount I-CASE)
5.2.2. Uniface
5.3. Designer/2000 + Developer/2000
5.4. Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)
5.5. Об'єктно-орієнтовані CASE-засоби (Rational Rose)
5.6. Допоміжні засоби підтримки життєвого циклу ПО
5.6.1. Засоби конфігураційного управління
5.6.2. Засоби документування
5.6.3. Засоби тестування
5.7. Приклади комплексів CASE-засобів
1. Основи методології проектування видавничих систем
1.1. Життєвий цикл видавничих систем.
Одним з базових понять методології проектування ВС є поняття її життєвого циклу. ЖЦ - це безперервний процес, що починається з моменту ухвалення рішення про необхідність створення системи й закінчується в момент її повного вилучення з експлуатації.
Основним нормативним документом, що регламентує ЖЦ, є міжнародний стандарт ISO/IEC 12207 [5] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія з електротехніки). Він визначає структуру ЖЦ, що містить процеси, дії й завдання, які повинні бути виконані під час створення системи.
Структура ЖЦ по стандарту ISO/IEC 12207 базується на трьох групах процесів:
основні процеси ЖЦ (придбання, доставка, розробка, експлуатація, супровід);
допоміжні процеси, що забезпечують виконання основних процесів (документування, керування конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);
організаційні процеси (керування проектами, створення інфраструктури проекту, визначення, оцінка й поліпшення власне ЖЦ, навчання).
Розробка містить у собі всі роботи зі створення ВС і її компонент відповідно до заданих вимог, включаючи оформлення проектної й експлуатаційної документації, підготовку матеріалів, необхідних для перевірки працездатності й відповідної якості програмних продуктів, матеріалів, необхідних для організації навчання персоналу й т.д. Розробка ВС містить у собі, як правило, аналіз, проектування, реалізацію.
Експлуатація містить у собі роботи із впровадження компонентів ВС в експлуатацію, забезпечення експлуатаційною документацією, проведення навчання персоналу й т.д., і безпосередньо експлуатацію, у тому числі локалізацію проблем й усунення причин їхнього виникнення, модифікацію ВС в рамках встановленого регламенту, підготовку пропозицій по вдосконаленню, розвитку й модернізації системи.
Керування проектом пов'язане з питаннями планування й організації робіт, створення колективів розробників і контролю за термінами і якістю робіт, що виконуються. Технічне й організаційне забезпечення проекту включає вибір методів й інструментальних засобів для реалізації проекту, визначення методів опису проміжних станів розробки, розробку методів і засобів випробувань ВС, навчання персоналу й т.п. Забезпечення якості проекту пов'язане із проблемами верифікації, перевірки й тестування ВС. Верифікація - це процес визначення того, чи відповідає поточний стан розробки, досягнутий на даному етапі, вимогам цього етапу. Перевірка дає змогу оцінити відповідність параметрів розробки вихідним вимогам. Перевірка частково збігається з тестуванням, що пов'язане з ідентифікацією розходжень між дійсними й очікуваними результатами й оцінкою відповідності характеристик ВС вихідним вимогам. У процесі реалізації проекту важливе місце займають питання ідентифікації, опису й контролю конфігурації окремих компонентів і всієї системи в цілому.
Керування конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ВС, насамперед процеси розробки й супроводу ВС. При створенні проектів складних ВС, що складаються з багатьох компонентів, кожний з яких може мати різні варіанти реалізації або версії, виникає проблема врахування їхніх зв'язків і функцій, створення уніфікованої структури й забезпечення розвитку всієї системи. Керування конфігурацією дає змогу органзовувати, систематично враховувати й контролювати внесення змін у ВС на всіх стадіях ЖЦ. Загальні принципи й рекомендації врахування конфігурації, планування й керування конфігураціями ВС відображені в проекті стандарту ISO 12207-2 [5].
Кожен процес характеризується певними завданнями й методами їх рішення, вихідними даними, отриманими на попередньому етапі, і результатами. Результатами аналізу, зокрема, є функціональні моделі, інформаційні моделі й відповідні їм діаграми. ЖЦ ВС носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, вироблених на попередніх етапах.
1.2. Моделі життєвого циклу ВС
Стандарт ISO/IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ВС (під моделлю ЖЦ розуміють структуру, що визначає послідовність виконання й взаємозв'язки між ними, дій і завдань,що виконуються протягом ЖЦ. Модель ЖЦ залежить від специфіки ВС і специфіки умов, у яких остання створюється й функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO/IEC 12207 описує структуру процесів ЖЦ ВС, але не конкретизує в деталях, як реалізувати або виконати дії й завдання, включені в ці процеси.
На сьогодні найбільше поширення отримати наступні дві основні моделі ЖЦ:
каскадна модель (70-85 р.р.);
спіральна модель (86-90 р.р.).
У існуючих однорідних ВС кожен додаток представляв собою єдине ціле. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбивання всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершена робота над біжучим (мал. 1.1). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.
Позитивні сторони застосування каскадного підходу полягають у наступному [2]:
на кожному етапі формується закінчений набір проектної документації, що відповідає критеріям повноти й погодженості;
виконувані в логічній послідовності етапи робіт дають змогу планувати строки завершення всіх робіт і відповідні витрати.
Мал. 1.1. Каскадна схема розробки ВС
Каскадний підхід добре зарекомендував себе при побудові ВС, для яких на початкових стадіях розробки можна досить точно й повно сформулювати всі вимоги, для того щоб надати розробникам можливість реалізувати їх якнайкраще з технічної точки зору. У цю категорію попадають складні розрахункові системи, системи реального часу й інші подібні завдання. Однак, у процесі використання цього підходу став явним ряд його недоліків, викликаних насамперед тим, що реальний процес створення ВС ніколи повністю не укладався в таку жорстку схему. У процесі створення ВС постійно виникала потреба в поверненні до попередніх етапів й уточненні або перегляді раніше ухвалених рішень. У результаті реальний процес створення ВС приймав наступний вигляд (мал. 1.2):
Мал. 1.2. Реальний процес розробки ВС за каскадною схемою
Основним недоліком каскадного підходу є істотне запізнення з отриманням результатів. Узгодження результатів з користувачами виробляється тільки в місцях, після завершення кожного етапу робіт, вимоги до ВС "заморожені" у вигляді технічного завдання на весь час її створення. Таким чином, користувачі можуть внести свої зауваження тільки після того, як робота над системою буде повністю завершена. У випадку неточного викладу вимог або їх зміни протягом тривалого періоду створення ВС, користувачі отримують систему, що не задовольняє їхнім потребам. Моделі (як функціональні, так й інформаційні) об'єктів автоматизації можуть застаріти одночасно з їх затвердженням.
Для подолання перерахованих проблем була запропонована спіральна модель ЖЦ [10] (мал. 1.3), яка робить акцент на початкові етапи ЖЦ: аналіз і проектування. На цих етапах технічні рішення перевіряються шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагменту або версії ВС, на ньому уточнюються мета й характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. У такий спосіб заглиблюються й послідовно конкретизуються деталі проекту. В результаті вибирається обґрунтований варіант, який доводять до реалізації.
Розробка ітераціями відображає об'єктивно існуючий спіральний цикл створення системи. Неповне завершення робіт на кожному етапі дає змогу переходити на наступний етап, не чекаючи повного завершення роботи на біжучому. При ітеративному способі розробки відсутню роботу можна буде виконати на наступній ітерації. Головне ж завдання - якнайшвидше показати користувачам системи працездатний продукт, тим самим активізуючи процес уточнення й доповнення вимог.
Основна проблема спірального циклу - визначення моменту переходу на наступний етап. Для її рішення необхідно ввести тимчасові обмеження на кожний з етапів життєвого циклу. Перехід здійснюється відповідно до плану, навіть якщо не вся запланована робота закінчена. План складається на основі статистичних даних, отриманих у попередніх проектах, і з особистого досвіду розроблювачів.
Мал. 1.3. Спіральна модель ЖЦ
1.3. Методології й технології проектування ВС
1.3.1. Загальні вимоги до методології й технології
Методології, технології й інструментальні засоби проектування (CASE-засобу) становлять основу проекту будь-якої ВС. Методологія реалізується через конкретні технології й підтримуючі їхні стандарти, методики й інструментальні засоби, які забезпечують виконання процесів ЖЦ.
Технологія проектування визначається як сукупність трьох складових:
покрокової процедури, що визначає послідовність технологічних операцій проектування (мал. 1.4);
критеріїв і правил, які використовуються для оцінки результатів виконання технологічних операцій;
нотацій (графічних і текстових засобів), використовуваних для опису проектованої системи.
Мал. 1.4. Подання технологічної операції проектування
Технологічні інструкції, що становлять основний зміст технології, повинні складатися з опису послідовності технологічних операцій, умов, в залежності від яких виконується та або інша операція, і описів самих операцій.
Технологія проектування, розробки й супроводу ВС повинна задовольняти наступним загальним вимогам:
технологія повинна підтримувати повний ЖЦ ВС;
технологія повинна забезпечувати гарантоване досягнення цілей розробки ВС із заданою якістю й у встановлений час;
технологія повинна забезпечувати можливість виконання великих проектів у вигляді підсистем (тобто можливість декомпозиції проекту на складові частини, що розроблюються групами обмеженої кількості виконавців з наступною інтеграцією складових частин). Досвід розробки великих ВС показує, що для підвищення ефективності робіт необхідно розбити проект на окремі слабо зв'язані за даними й функціям підсистеми. Реалізація підсистем повинна виконуватися окремими групами фахівців. При цьому необхідно забезпечити координацію ведення загального проекту й виключити дублювання результатів робіт кожної проектної групи, що може виникнути при наявності загальних даних і функцій;
технологія повинна забезпечувати можливість ведення робіт по проектуванню окремих підсистем невеликими групами (3-7 чоловік). Це обумовлено принципами керованості колективу й підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;
технологія повинна забезпечувати мінімальний час отримання працездатної ВС. Мова йде не про строки готовності всієї ВС, а про строки реалізації окремих підсистем. Реалізація ВС у цілому в короткий термін може вимагати залучення великої кількості розробників, при цьому ефект може виявитися меншим, ніж при реалізації в більш короткий термін окремих підсистем меншою кількістю розроблювачів. Практика показує, що навіть при наявності повністю завершеного проекту, впровадження йде послідовно по окремих підсистемах;
технологія повинна передбачати можливість керування конфігурацією проекту, версій проекту і його складових, можливість автоматичного випуску проектної документації й синхронізацію її версій з версіями проекту;
технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації ВС;
технологія повинна бути підтримана комплексом погоджених CASE-засобів, що забезпечують автоматизацію процесів, що виконуються на всіх стадіях ЖЦ.
Реальне застосування будь-якої технології проектування, розробки й супровід ВС у конкретній організації й конкретному проекті неможливо без вироблення низки стандартів (правил, угод), які повинні дотримуватися всіма учасниками проекту. До таких стандартів відносяться наступні:
стандарт проектування;
стандарт оформлення проектної документації;
стандарт користувацького інтерфейсу.
Стандарт проектування повинен складатися з:
набору необхідних моделей (діаграм) на кожній стадії проектування та ступенів їх деталізації;
правила фіксації проектних рішень на діаграмах, у тому числі: правила іменування об'єктів (включаючи угоди по термінології), набір атрибутів для всіх об'єктів і правила їх заповнення на кожній стадії, правила оформлення діаграм, включаючи вимоги до форми й розмірів об'єктів, і т.д.;
вимоги до конфігурації робочих місць розробників, включаючи налаштування операційної системи, налаштування CASE-засобів, загальні налаштування проекту й т.д.;
механізм забезпечення спільної роботи над проектом, у тому числі: правила інтеграції підсистем проекту, правила підтримки проекту в однаковому для всіх розробників вигляді (регламент обміну проектною інформацією, механізм фіксації загальних об'єктів і т.д.), правила перевірки проектних рішень на конфліктність і т.д.
Стандарт оформлення проектної документації повинен складатися з:
комплектності, складу і структури документації на кожній стадії проектування;
вимог до її оформлення (включаючи вимоги до змісту розділів, підрозділів, пунктів, таблиць і т.д.),
правила підготовки, розгляду, узгодження й затвердження документації із вказівкою крайніх термінів для кожної стадії;
вимоги до налаштування видавничої системи, що використовується як вбудований засіб підготовки документації;
вимоги до настроювання CASE-засобів для забезпечення підготовки документації відповідно до встановлених вимог.
Стандарт інтерфейсу користувача повинен складатися з:
правила оформлення екранів (шрифти й колірна палітра), склад і розташування вікон й елементів керування;
правила використання клавіатури й миші;
правила оформлення текстів допомоги;
перелік стандартних повідомлень;
правила обробки реакції користувача.
1.3.2. Методологія RAD
Одним з можливих підходів до розробки ВС в рамках спіральної моделі ЖЦ є методологія швидкої розробки додатків RAD (Rapid Application Development), що отримала останнім часом широке поширення. Під цим терміном розуміється процес розробки ВС, що містить 3 елементи:
невелику команду розробників (від 2 до 10 чоловік);
короткий, але ретельно пророблений виробничий графік (від 2 до 6 міс.);
повторюваний цикл, при якому розробники, у міру того, як розпочинається єтап знаходити форму, запитують і реалізують у продукті вимоги, отримані через взаємодію із замовником.
Команда розробників повинна представляти собою групу професіоналів, що мають досвід в аналізі, проектуванні, розробці коду й тестуванні ВС з використанням CASE-засобів. Члени колективу повинні також вміти трансформувати в робочі прототипи пропозиції кінцевих користувачів.
Життєвий цикл ВС по методології RAD складається із чотирьох фаз:
фаза аналізу й планування вимог;
фаза проектування;
фаза побудови;
фаза впровадження.
На фазі аналізу й планування вимог користувачі системи визначають функції, які вона повинна виконувати, виділяють найбільш пріоритетні з них, що вимагають пророблення в першу чергу, описують інформаційні потреби. Визначення вимог виконується в основному силами користувачів під керівництвом фахівців-розробників. Обмежується масштаб проекту, визначаються часові рамки для кожної з наступних фаз. Крім того, визначається сама можливість реалізації даного проекту у встановлених рамках фінансування, на даних апаратних засобах і т.п. Результатом даної фази повинні бути список і пріоритетність функцій майбутньої ВС, попередні функціональні й інформаційні моделі ВС.
На фазі проектування частина користувачів бере участь у технічному проектуванні системи під керівництвом фахівців-розробників. CASE-засоби використаються для швидкого отримання працюючих прототипів додатків. Користувачі, безпосередньо взаємодіючи з ними, уточнюють і доповнюють вимоги до системи, які не були виявлені на попередній фазі. Більш докладно розглядаються процеси системи. Аналізується і при необхідності, коректується функціональна модель. Кожен процес розглядається детально. При необхідності для кожного елементарного процесу створюється частковий прототип. Визначаються вимоги розмежування доступу до даних. На цій же фазі відбувається визначення набору необхідної документації.
Після детального визначення складу процесів оцінюється кількість функціональних елементів розроблювальної системи і приймається рішення про поділ ВС на підсистеми, що піддаються реалізації однією командою розробників за прийнятне для RAD-проектів. З використанням CASE-засобів проект розподіляється між різними командами (ділиться функціональна модель). Результатом даної фази повинні бути:
загальна інформаційна модель системи;
функціональні моделі системи в цілому й підсистем, реалізованих окремими командами розробників;
точно визначені за допомогою CASE-засобу інтерфейси між автономно розробленими підсистемами;
побудовані прототипи.
Всі моделі й прототипи повинні бути отримані із застосуванням тих CASE-засобів, які будуть використатися надалі при побудові системи. Дана вимога викликана тим, що в традиційному підході при передачі інформації про проект із етапу на етап може відбутися фактично неконтрольоване перекручування даних. Застосування єдиного середовища зберігання інформації про проект дає змогу уникнути цієї небезпеки.
На відміну від традиційного підходу, при якому використовувалися специфічні засоби прототипування, не призначені для побудови реальних додатків, прототипи викидалися після того, як виконували завдання усунення неточностей у проекті, у підході RAD кожен прототип перетворюється в частину майбутньої системи. Таким чином, на наступну фазу передається більше повна й корисна інформація.
На фазі побудови виконується безпосередньо найшвидша розробка додатка. На даній фазі розроблювачі роблять ітеративну побудову реальної системи на основі отриманих у попередній фазі моделей, а також вимог нефункціонального характеру. Кінцеві користувачі на цій фазі оцінюють отримані результати й вносять корективи, якщо в процесі розробки система перестає відповідати поставленим раніше вимогам. Тестування системи здійснюється безпосередньо в процесі розробки.
Після закінчення робіт кожної окремої команди розробників виробляється поступова інтеграція даної частини системи з іншими, формується повна система, виконується тестування спільної роботи даної частини додатка з іншими, а потім тестування системи в цілому. Завершується фізичне проектування системи:
визначається необхідність розподілу даних;
виробляється аналіз використання даних;
виробляється фізичне проектування бази даних;
визначаються вимоги до апаратних ресурсів;
визначаються способи збільшення продуктивності;
завершується розробка документації проекту.
Результатом фази є готова система, що відповідає всім погодженим вимогам.
На фазі впровадження виробляється навчання користувачів, організаційні зміни й паралельно із впровадженням нової системи здійснюється робота з існуючою системою (до повного впровадження нової). Тому що фаза побудови досить нетривала, планування й підготовка до впровадження повинні починатися заздалегідь, як правило, на етапі проектування системи. Наведена схема розробки ВС не є абсолютною. Можливі різні варіанти, що залежать, наприклад, від початкових умов, у яких ведеться розробка: розробляється зовсім нова система; уже було проведене обстеження підприємства й існує модель його діяльності; на підприємстві вже існує деяка ВС, що може бути використані як початковий прототип або повинна бути інтегрована з тої, що розробляється.
Треба, однак, відзначити, що методологія RAD, як і будь-яка інша, не може претендувати на універсальність, вона ефективна в першу чергу для відносно невеликих проектів, розроблювальних для конкретного замовника. Якщо ж розробляється типова система, що не є закінченим продуктом, а являє собою комплекс типових компонентів, централізовано супроводжуваних, адаптованими до програмно-технічних засобів, СУБД, засобам телекомунікації, організаційно-економічним особливостям об'єктів впровадження й інтегрувальних з існуючими розробками, на перший план виступають такі показники проекту, як керованість й якість, які можуть ввійти в суперечність із простотою й швидкістю розробки. Для таких проектів необхідний високий рівень планування і відповідна дисципліна проектування, строге проходження заздалегідь розробленим протоколам й інтерфейсам, що знижує швидкість розробки.
Оцінка розміру додатків виробляється на основі так званих функціональних елементів. Розмір додатку, що може бути виконаний по методології RAD, для добре налагодженого середовища розробки ВС із максимальним повторним використанням програмних компонентів, визначається в такий спосіб:
< 1000 функціональних елементів
одна людина
1000-4000 функціональних елементів
одна команда розробників
> 4000 функціональних елементів
4000 функціональних елементів на одну команду розробників
Як підсумок перерахуємо основні принципи методології RAD:
розробка додатків ітераціями;
необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;
обов'язкове залучення користувачів у процес розробки ВС;
необхідне застосування CASE-засобів, що забезпечують цілісність проекту;
застосування засобів керування конфігурацією, що полегшують внесення змін у проект і супровід готової системи;
використання прототипування, що дає змогу повніше з'ясувати й задовольнити потреби кінцевого користувача;
тестування й розвиток проекту, здійснювані одночасно з розробкою;
ведення розробки незначною, але добре керованою командою професіоналів;
грамотне керівництво розробкою системи, чітке планування й контроль виконання робіт.
2. Структурний підхід до проектування ІС
2.1. Сутність структурного підходу
Сутність структурного підходу до розробки ІС полягає в її декомпозиції на функції, що автоматизуються: система розбивається на функціональні підсистеми, які у свою чергу поділяються на підфункції, які розділяють на завдання і так далі. Процес розбивки триває аж до конкретних процедур. При цьому система, що автоматизується, зберігає цілісне представлення, у якому всі складові компоненти взаємопов'язані. При розробці системи "знизу-нагору", від окремих завдань до всієї системи, цілісність губиться, виникають проблеми при інформаційному стикуванні окремих компонентів.
Усі найпоширеніші методології структурного підходу [9,11,12,13] базуються на ряді загальних принципів [3]. У якості двох базових принципів використовуються такі:
принцип "розділяй і пануй" - принцип рішення складних проблем шляхом їхньої розбивки на безліч менших незалежних завдань, легких для розуміння й вирішення;
принцип ієрархічного упорядкування - принцип організації складових частин проблеми в ієрархічні деревоподібні структури з додаванням нових деталей на кожному рівні.
Виділення двох базових принципів не означає, що інші принципи є другорядними, оскільки ігнорування будь-якого з них може привести до непередбачених наслідків (у тому числі й до провалу всього проекту). Основними із цих принципів є такі:
принцип абстрагування - полягає у виділенні істотних аспектів системи й від’єднанні їх від несуттєвих;
принцип формалізації - полягає в необхідності строгого методичного підходу до вирішення проблеми;
принцип несуперечності - полягає в обґрунтованості й узгодженості елементів;
принцип структурування даних - полягає в тому, що дані повинні бути структуровані й ієрархічно організовані.
У структурному аналізі використовуються в основному дві групи засобів, що ілюструють функції, виконувані системою, і функції зв’язку між даними. Кожній групі засобів відповідають певні види моделей (діаграм), найпоширенішими серед яких є такі:
SADT (Structured Analysis and Design Technique) моделі й відповідні функціональні діаграми (підрозділ 2.2);
DFD (Data Flow Diagrams) діаграми потоку даних (підрозділ 2.3);
ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок" (підрозділ 2.4).
На стадії проектування ІС моделі розширюються, уточнюються й доповнюються діаграмами, що ілюструють структуру програмного забезпечення: архітектуру ПЗ, структурні схеми програм і діаграми екранних форм.
Перераховані моделі в сукупності дають повний опис ІС незалежно від того, чи є вона існуючою, чи такою, що знову розробляється. Склад діаграм у кожному конкретному випадку залежить від необхідної повноти опису системи.
2.2. Методологія функціонального моделювання SADT
Методологія SADT розроблена Дугласом Россом і одержала подальший розвиток у роботі [4], на її основі розроблена, зокрема, відома методологія IDEF0 (Icam DEFinition), котра є основною частиною програми ICAM (Інтеграція комп'ютерних і промислових технологій).
Методологія SADT являє собою сукупність методів, правил і процедур, призначених для побудови функціональної моделі об'єкту якої-небудь предметної області. Функціональна модель SADT відображає функціональну структуру об'єкту, тобто виконувані ним дії й зв'язки між цими діями. Основні елементи цієї методології ґрунтуються на таких концепціях:
Графічне представлення блокового моделювання. Графіка блоків і дуг SADT-діаграми відображає функцію у вигляді блоку, а інтерфейси входу/виходу представляються дугами, що, відповідно, входять у блок і виходять з нього. Взаємодія блоків між собою описується за допомогою інтерфейсних дуг, що виражають "обмеження", котрі у свою чергу визначають, коли і яким чином функції виконуються й керуються;
Строгість і точність. Виконання правил SADT вимагає достатньої строгості й точності, не накладаючи в той же час надмірних обмежень на дії аналітика. Правила SADT включають:
обмеження кількості блоків на кожному рівні декомпозиції (як правило, 3-6 блоків);
зв’язність діаграм (номери блоків);
унікальність міток і найменувань (відсутність імен, що повторювалися б);
синтаксичні правила для графіки (блоків і дуг);
поділ входів і керувань (правило визначення ролі даних).
відділення організації від функції, тобто виключення впливу організаційної структури на функціональну модель.
Методологія SADT може використовуватися для моделювання широкого кола систем та визначення вимог і функцій, а потім для розробки системи, що задовольняє ці вимоги і реалізує ці функції. Для вже існуючих систем SADT може бути використана для аналізу функцій, що виконуються системою, а також для зазначення механізмів, за допомогою яких вони здійснюються.
2.2.1. Склад функціональної моделі
Результатом застосування методології SADT є модель, що складається з діаграм, фрагментів текстів і глосарію, що мають посилання один на одного. Діаграми - головні компоненти моделі, усі функції ІС та інтерфейси на них представлені як блоки й дуги. Місце з'єднання дуги із блоком визначає тип інтерфейсу. Керуюча інформація входить у блок зверху, у той час як інформацію, що піддається обробці, показано з лівої сторони блоку, а результати виходу показано із правої сторони. Механізм (людина або автоматизована система), що здійснює операцію, представляється дугою, що входить у блок знизу (малюнок 2.1).
Однією з найважливіших особливостей методології SADT є поступове введення все більшої кількості рівнів деталізації в процесі створення діаграм, що відображають модель.
Рис. 2.1. Функціональний блок й інтерфейсні дуги
На малюнку 2.2, де наведені чотири діаграми і їхні взаємозв'язки, показана структура SADT-моделі. Кожен компонент моделі може бути декомпозований на іншій діаграмі. Кожна діаграма ілюструє "внутрішню будову" блоку на батьківській діаграмі.
2.2.2. Ієрархія діаграм
Побудова SADT-моделі починається з представлення всієї системи у вигляді найпростішого компоненту - одного блоку й дуг, що зображують інтерфейси з функціями поза системою. Оскільки єдиний блок представляє всю систему як єдине ціле, ім'я, зазначене в блоці, є загальним. Це вірно і для інтерфейсних дуг - вони також представляють повний набір зовнішніх інтерфейсів системи в цілому.
Потім блок, що представляє систему як єдиний модуль, деталізується на іншій діаграмі за допомогою декількох блоків, з'єднаних інтерфейсними дугами. Ці блоки представляють основні підфункції вихідної функції. Ця декомпозиція виявляє повний набір підфункцій, кожна з яких представлена як блок, границі якого визначені інтерфейсними дугами. Кожна з цих підфункцій може бути декомпозована подібним чином для більш детального представлення.
У всіх випадках кожна підфункція може містити тільки ті елементи, які входять у вихідну функцію. Крім того, модель не може опустити які-небудь елементи, тобто, як ми вже відзначали, батьківський блок і його інтерфейси забезпечують контекст. До нього не можна нічого додати, і з нього не може бути нічого вилучено.
Модель SADT являє собою серію діаграм із супровідною документацією, що розбивають складний об'єкт на складові частини, котрі представлені у вигляді блоків. Деталі кожного з основних блоків показано у вигляді блоків на інших діаграмах. Кожна детальна діаграма є декомпозицією блоку з більш загальної діаграми. На кожному кроці декомпозиції більш загальна діаграма називається батьківською для більш детальної діаграми.
Дуги, що входять у блок і виходять із нього на діаграмі верхнього рівня, є тими самими, що й дуги, які входять у діаграму нижнього рівня й виходять з неї, тому що блок і діаграма представляють ту саму частину системи.
Рис. 2.2. Структура SADT-моделі. Декомпозиція діаграм
На малюнках 2.3 - 2.5 представлені різні варіанти виконання функцій і з'єднання дуг із блоками.
Рис. 2.3. Одночасне виконання
Рис. 2.4. Відповідність повинна бути повною і несуперечливою
Деякі дуги приєднані до блоків діаграми обома кінцями, в інших же один кінець залишається неприєднаним. Неприєднані дуги відповідають входам, керуванням і виходам батьківського блоку. Джерело або одержувач цих примежових дуг може бути виявлений тільки на батьківській діаграмі. Неприєднані кінці повинні відповідати дугам на вихідній діаграмі. Всі граничні дуги повинні бути продовжені на батьківській діаграмі, щоб вона була повною й несуперечливою.
На SADT-діаграмах явно не зазначені ні послідовність, ні час. Зворотні зв'язки, ітерації, процеси, що тривають й функції, що перекриваються (за часом) можуть бути зображені за допомогою дуг. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень і т.д. (малюнок 2.5).
Рис. 2.5. Приклад зворотного зв'язку
Як було зазначено, механізми (дуги з нижньої сторони) показують засоби, за допомогою яких здійснюється виконання функцій. Механізм може бути людиною, комп'ютером або будь-яким іншим пристроєм, що допомагає виконувати дану функцію (малюнок 2.6).
Рис. 2.6. Приклад механізму
Кожний блок на діаграмі має свій номер. Блок будь-якої діаграми може бути далі описаний діаграмою нижнього рівня, котра, у свою чергу, може бути далі деталізована за допомогою необхідного числа діаграм. Таким чином, формується ієрархія діаграм.
Для того, щоб указати розміщення будь-якої діаграми або блоку в ієрархії, використовуються номери діаграм. Наприклад, А21 є діаграмою, котра деталізує блок 1 на діаграмі А2. Аналогічно, А2 деталізує блок 2 на діаграмі А0, котра є верхньою діаграмою моделі. На малюнку 2.7 показане типове дерево діаграм.
Рис. 2.7. Ієрархія діаграм
2.2.3. Типи зв'язків між функціями
Одним з важливих моментів при проектуванні ІС за допомогою методології SADT є точна узгодженість типів зв'язків між функціями. Розрізняють принаймні сім типів зв'язування:
Тип зв'язку
Відносна значимість
Випадкова
0
Логічна
1
Тимчасова
2
Процедурна
3
Комунікаційна
4
Послідовна
5
Функціональна
6
Нижче кожний тип зв'язку коротко визначений і проілюстрований за допомогою типового прикладу з SADT.
(0) Тип випадкової зв’язності: найменш бажаний. Випадкова зв’язність виникає, коли конкретний зв'язок між функціями малий або повністю відсутній. Це відноситься до ситуації, коли імена даних на SADT-дугах в одній діаграмі мають малий зв'язок між собою. Граничний варіант цього випадку показаний на малюнку 2.8.
Рис. 2.8. Випадкова зв’язність
(1) Тип логічної зв’язності. Логічне зв'язування відбувається тоді, коли дані та функції збираються разом внаслідок того, що вони потрапляють до загального класу або набору елементів, але необхідних функціональних відносин між ними не виявляється.
(2) Тип тимчасової зв’язності. Зв'язані за часом елементи виникають внаслідок того, що вони представляють функції, зв'язані в часі, коли дані використаються одночасно, або функції включаються паралельно, а не послідовно.
(3) Тип процедурної зв’язності. Процедурно-зв’язані елементи з'являються згрупованими між собою внаслідок того, що вони виконуються протягом однієї й тієї ж частини циклу або процесу. Приклад процедурно-зв’язаної діаграми наведений на малюнку 2.9.
Рис. 2.9. Процедурна зв’язність
(4) Тип комунікаційної зв’язності. Діаграми демонструють
02.02.2013 12:02-
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора