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

Размещено на http://www.allbest.ru/

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

Вступ

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

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

Найбільш поширеним засобом моделювання даних є модель "сутність - зв'язок" (Entity-Relationship Model - ERM). Вона вперше була введена П. Ченом у 1976 р. Ця модель традиційно використовується у структурному аналізі і проектуванні, проте, по суті, це підмножина об'єктної моделі предметної області. Один з різновидів моделі "сутність - зв'язок" використовується в методі IDEF1-X, що належить сімейству стандартів IDEF, і реалізується у низці поширених CASE-засобів (зокрема, AH Fusion ERwin Data Modeler).

Методи об'єктно орієнтованого аналізу і проектування програмного забезпечення. Мова UML

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

Більшість сучасних методів ООАП базуються на використанні мови UML. Уніфікована мова моделювання UML (Unified Modeling Language) є мовою для визначення, подання, проектування і документування програмних систем, організаційно-економічних систем, технічних систем та інших систем різної природи. UML містить стандартний набір діаграм і нотацій найрізноманітніших видів.

UML - це наступник того покоління методів ООАП, які з'явилися в кінці 1980-х і на початку 1990-х років. Створення UML фактично розпочалося в кінці 1994 p., коли Граді Вуч і Джеймс Рамбо почали роботу щодо об'єднання їх методів Booch і ОМТ (Object Modeling Technique) під егідою компанії Rational Software. До кінця 1995 р. вони створили першу специфікацію об'єднаного методу, названого ними Unified Method. Тоді ж у 1995 р. до них приєднався автор методу OOSE (Object-Oriented Software Engineering) Івар Якобсон. Таким чином, UML є прямим об'єднанням і уніфікацією методів Г. Буча, Д. Рамбо і Г. Якобсона, проте доповнює їх новими можливостями. Головними при розробці UML були такі цілі:

надати користувачам готову до використання виразну мову візуального моделювання, що дозволяє їм розробляти осмислені моделі й обмінюватися ними;

передбачити механізми розширюваності і спеціалізації для розширення базових концепцій;

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

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

стимулювати зростання ринку об'єктно орієнтованих інструментальних засобів;

інтегрувати кращий практичний досвід.

UML прийнятий на озброєння практично всіма найбільшими компаніями - виробниками ПЗ (Microsoft, Oracle, IBM, Hewlett-Packard, Sybase тощо). Крім того, практично всі світові виробники CASE-засобів, крім IBM Rational Software, підтримують UML у своїх продуктах (Oracle Designer, Together Control Center (Borland), AllFusion Component Modeler (Computer Associates), Microsoft Visual Modeler). Стандарт UML версії 1.1, прийнятий OMG у 1997 p., містить такий набір діаграм:

Структурні моделі (structural):

діаграми класів (class diagrams) - для моделювання статичної структури класів системи і зв'язків між ними;

діаграми компонентів (component diagrams) - для моделювання ієрархії компонентів (підсистем) системи;

послідовність виконуваних дій;

передачу інформації між функціональними процесами;

відношення між даними.

Поширеними моделями проектування ПЗ:

1) функціональна модель SADT (Structured Analysis and Design Technique);

2) модель IDEF3;

3) DFD (Data Flow Diagrams) - діаграми потоків даних.

Метод SADT є сукупністю правил і процедур, призначених для побудови функціональної моделі об'єкта певної предметної області. Функціональна модель SADT відображає функціональну структуру об'єкта, тобто його дії і зв'язки між цими діями. Метод SADT розроблений Дугласом Россом у 1969 р. для моделювання штучних систем середньої складності. Цей метод успішно використовувався у військових, промислових і комерційних організаціях США для вирішення широкого кола завдань, таких як довгострокове і стратегічне планування, автоматизоване виробництво і проектування, розробка ПЗ для оборонних систем, управління фінансами і матеріально-технічним постачанням тощо. Метод SADT підтримується Міністерством оборони США, яке було ініціатором розробки сімейства стандартів IDEF (Icam DEFinition), які є основною частиною програми ІСАМ (інтегрована комп'ютеризація виробництва), що проводиться за ініціативою BBC США.

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

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

IDEF-їх - методологія побудови реляційних структур.

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

Метод SADT реалізовано саме в одному зі стандартів цього сімейства - IDEF-0, який був затверджений як федеральний стандарт США в 1993 р.

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

повнота опису бізнес-процесу (управління, інформаційні і матеріальні потоки, зворотні зв'язки);

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

відповідність підходу до опису процесів стандартам IS9000.

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

Метод моделювання IDEF-3, що є частиною сімейства стандартів IDEF, розроблено у 1980 р. для закритого проекту Міноборони США. Цей метод призначений для таких моделей процесів, у яких важливо зрозуміти послідовність виконання дій і взаємозалежності між ними. Хоча IDEF-3 і не досяг статусу федерального стандарту США, він набув значного поширення серед системних аналітиків як доповнення до методу функціонального моделювання IDEF-0 (моделі IDEF-3 можуть використовуватися для деталізації функціональних блоків IDEF-0, що не мають діаграм декомпозиції). Основою моделі IDEF-3 слугує сценарій процесу, що виділяє послідовність дій і під-процесів аналізованої системи.

Діаграми потоків даних (Data Flow Diagrams - DFD) є ієрархією функціональних процесів, пов'язаних потоками даних. Мета такого представлення - показати, як кожен процес перетворює свої вхідні дані у вихідні, а також виявити відношення між цими процесами.

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

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

Підхід RAD-технології передбачає наявність трьох складових:

невеликих груп розробників, що виконують роботи з проектування окремих підсистем ПЗ. Це зумовлено вимогою максимального управління колективом;

короткого, але ретельно проробленого виробничого графіка;

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

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

Життєвий цикл ПЗ за підходом RAD включає чотири стадії:

1) аналіз і планування вимог;

2) проектування;

3) реалізація;

4) введення в дію.

На стадії аналізу і планування вимог користувачі здійснюють такі дії:

а) визначають функції, що має виконувати система;

б) виділяють найважливіші функції, що вимагають проробки в першу чергу;

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

обмежується масштаб проекту;

встановлюються часові рамки для кожної з наступних стадій;

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

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

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

детальніше розглядаються процеси ІС;

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

встановлюються вимоги розмежування доступу до даних;

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

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

вхідний елемент застосування (вхідний документ або екранна форма);

вихідний елемент застосування (звіт, документ, екранна форма);

запит (пари "питання/відповідь");

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

інтерфейс застосування (сукупність записів даних, переданих іншому застосуванню).

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

Моделі поведінки (behavioral):

діаграми варіантів використання (use case diagrams) - для моделювання функціональних вимог до системи (у вигляді сценаріїв взаємодії користувачів з системою);

діаграми взаємодії (interaction diagrams);

діаграми послідовності (sequence diagrams) і кооперативні діаграми (collaboration diagrams) - для моделювання процесу обміну повідомленнями між об'єктами;

діаграми станів (statechart diagrams) - для моделювання поведінки об'єктів системи при переході з одного стану в інший;

діаграми діяльності (activity diagrams) - для моделювання поведінки системи в рамках різних варіантів використання або потоків управління.

UML має механізм розширення, призначений для того, щоб розробники могли адаптувати мову моделювання до своїх конкретних потреб, не змінюючи при цьому його метамодель. Наявність механізмів розширення принципово відрізняє UML від таких засобів моделювання, як IDEF-0, IDEF-IX, IDEF-3, DFD і ERM. Перераховані мови моделювання можна визначити як сильно типізовані (аналогічно з мовами програмування), оскільки вони не допускають довільної інтерпретації семантики елементів моделей. UML, допускаючи таку інтерпретацію (в основному за рахунок стереотипів), є мовою, що слабо типізується. До її механізмів розширення відносять: стереотипи; тегування (іменовані) значення; обмеження.

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

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

Обмеження - це семантичне обмеження, що має вид текстового виразу природною або формальною мовою (OCL - Object Constraint Language), який неможливо представити за допомогою нотації UML.

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

RAD-технологія - кодування. Одночасність створення клієнтських і серверних місць ІС та активне залучення користувачів до процесу розроблення прикладного ПЗ зумовили поширення технологи швидкого розроблення застосувань RAD (Rapid Application Development) у рамках спіральної моделі ЖЦ.

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

загальну інформаційну модель ІС;

функціональні моделі системи в цілому і підсистеми, що реалізовані окремими командами розробників;

інтерфейси між автономно працюючими підсистемами;

прототипи екранних форм, звітів, діалогів.

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

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

На стадії реалізації відбувається безпосереднє швидке розроблення застосування:

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

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

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

аналізується використання даних і визначається необхідність їхнього розподілу; об'єктний орієнтований проектування uml

розробляється фізичне проектування бази даних;

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

установлюються способи підвищення продуктивності;

завершується розроблення документації проекту.

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

розробити нову систему "з нуля";

створити модель діяльності підприємства, за якою можна розробити 1С;

розробити 1С на основі старої.

Варто зазначити, що підхід RAD не претендує на універсальність. Він придатний тільки для невеликих проектів. Крім того, підхід RAD недоцільно застосовувати для побудови складних розрахункових програм, операційних систем чи програм управління складними об'єктами в реальному масштабі часу, тобто програм, що містять великий обсяг програмного коду.

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

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

Основний недолік цього варіанта - неефективне використання системи-прототипу: після усування недоліків у проекті та вдосконалення постановки задачі прототипи не використовують.

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

розроблення застосувань ітераціями;

необов'язковість повного завершення робіт на кожній стадії ЖЦПЗ;

обов'язковість залучення користувачів у процес розроблення ІС;

доцільність застосування CASE-засобів, що забезпечують цілісність проекту і генерацію коду застосувань;

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

використання прототипування, що дає змогу повніше з'ясувати і задовольнити потреби користувачів;

тестування й розвиток проекту, що здійснюються одночасно з розробленням;

ведення розробки завдяки нечисленній команді професіоналів;

грамотне управління розробленням ІС, чітке планування і контроль виконання робіт.

Размещено на Allbest.ru