Міністерство освіти І науки україни харківський національний економічний університет



Pdf просмотр
Сторінка1/20
Дата конвертації14.03.2017
Розмір5.01 Kb.
  1   2   3   4   5   6   7   8   9   ...   20

1
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ


ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ









Мінухін С. В.

Беседовський О. М.

Знахур С. В.


МЕТОДИ І МОДЕЛІ ПРОЕКТУВАННЯ
НА

ОСНОВІ СУЧАСНИХ CASE
-
ЗАСОБІВ


Навчальний посібник














Харків. Вид.

ХНЕУ, 2
008



2
УДК
004.94(075.8)
ББК
32.973

01я73

М62

Рецензенти: докт. техн. наук, професор кафедри штучного інтелекту Харківсь
- кого національного університету радіоелектроніки Бодянський Є. В.;
докт. техн. наук, професор кафедри інформаційних управляючих систем Харківського національного університету радіоелектроніки Авраменко В. П.

Рекомендовано до видання рішенням вченої ради Харківського національного економічного університету.
Протокол № 7 від 2 9.02
.2008 р.

Рекомендовано Міністерством освіти і науки України

як навчальний посібник для студентів вищих навчальних закладів

(лист №1.4/18
-
Г
-
2267 від 31.10.2008 р.)


Мінухін С. В.

М62
Методи і моделі проектування на основі сучасних CASE
- за
- собів. Навчальний посібник
/ С.
В.
Мінухін, О. М. Беседовський,
С.
В.
Знахур. —
Харків: Вид.
ХНЕУ, 2008.

272 с. (Укр.
мов.)

Розглянуто широке коло питань, присвячених викладанню та вирішенню завдань проектування інформаційних систем на основі сучасних CASE
- засобів. Здійснено теоретико
- методологічні засади структурно
- функціонального проектування із застосуванням методо
- логії SADT, включаючи побудову моделей предметної галузі, основні стандарти структурної методології, аналіз інструментальних засобів для проектування систем на основі структур
- ного підходу. Наведено приклади вирішення практичних завдань проектування окремих комплексів задач у пакетах BPWin та Business Studio.
Рекомендовано для студентів напряму підготовки "Комп’ютерні науки".

ISBN 978-966-676-301-6
УДК 004.94(075.8)

ББК
32.973


01я73


©
Харківський національний
економічний університет, 2008

©
Мінухін С. В.

Беседовський О. М.

Знахур С. В.

2008


3
ВСТУП

Для того щоб успішно виконати проект, об'єкт проектування повинен бути, перш за все, правильно й адекватно описаний, тобто необхідно побудувати повноцінні та функціональні інформаційні моделі об'єкта проектування. Донедавна проектування інформаційних систем виконувалося головним чином на інтуїтивному рівні із застосуванням неформалізованих методів, які ґрунтувалися б на практичному досвіді, експертних оцінках і дорогих експериментальних перевірках якості функціонування подібних систем. Але природно, що під час розробки і функціонування інформаційних систем, потреби користувачів можуть змінюватися або уточнюватися, що ще більш ускладнює розробку та супровід.
У 1970 –
80- х роках при розробці інформаційних систем широко застосовувалася структурна методологія, що надає в розпорядження розробників суворі формалізовані методи опису ІС і схвалюваних технічних рішень. Ця методологія ґрунтувалася на наочній графічній техніці, інакше кажучи, для опису проекту використовувалися різного роду схеми і діаграми. Наочність і суворість засобів структурного аналізу дозволяла розробникам і майбутнім користувачам системи із самого початку неформально брати участь у
її створенні, обговорювати й закріплювати розуміння основних технічних рішень. Проте широке застосування цієї методології та проходження її рекомендаціям при розробці конкретних проектів зустрічалося достатньо рідко, оскільки її практично неможливо реалізувати на належному рівні ручним, неавтоматизованим способом. Уручну дуже важко розробити і графічно представити суворі формальні специфікації системи, перевірити їх на повноту й несуперечність і тим більше змінити.
Якщо учасники проекту намагалися вдатися до ручної розробки, то перед ними виникали наступні проблеми:
неадекватна специфікація вимог; нездатність виявляти помилки у проектних рішеннях; низька якість документації, що знижує експлуатаційні якості; затяжний цикл і незадовільні результати тестування.
Повинні були з'явитися спеціалізовані програмно
- технологічні засоби для розробки проектів, зокрема, заснованих на інформатизації.
Ними стали засоби, що реалізовують CASE
- технологію створення та


4 супро
- воду інформаційних систем. Термін CASE (Computer
-Aided
Software Engineering) сьогодні розуміється досить широко.
Первинне значення терміну, обмежене питаннями автоматизації розробки програмного забезпечення (ПЗ), в даний час придбало новий сенс, і тепер це поняття охоплює процес розробки складних
інформаційних систем у цілому. Тепер під терміном CASE
- засобу розуміються програмні засоби, що підтримують процеси створення й супроводу подібних систем, включаючи аналіз і формулювання вимог, проектування прикладного ПЗ (додатків) і баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління та управління проектом і т. д. CASE
- засоби разом із системним ПЗ і технічними засобами утворюють повне середовище розробки.
Активні дослідження у сфері методології програмування привели до того, що програмування набуло рис системного підходу з розробкою і впровадженням мов високого рівня, методів структурного і модульного програмування, мов проектування і засобів їх підтримки, формальних і неформальних мов описів системних вимог і специфікацій і т. д.
Крім того, появі CASE
- технології сприяли і такі чинники, як:
підготовка аналітиків і програмістів, сприйнятливих до концепцій модульного і структурного програмування; широке впровадження і постійне зростання продуктивності комп'ютерів, що дозволили використовувати ефективні графічні засоби і автоматизувати більшість етапів проектування; впровадження мережної технології, що надала можливість об'єднання зусиль окремих виконавців у єдиний процес проектування шляхом використання бази даних, що розділялася, містить необхідну
інформацію про проект.
Таким чином, CASE
- технологія є методологією проектування ІС, а також набір інструментальних засобів, що дозволяють у наочній формі моделювати наочну область, аналізувати цю модель на всіх етапах розробки і супроводу ІС і розробляти додатки відповідно до потреб користувачів. Велика частка CASE
- засобів використовує методологію структурного (в основному) або орієнтованого аналізу і проектування, що використовують специфікації у вигляді діаграм або текстів для опису зовнішніх вимог, зв'язків між моделями системи, динаміки поведінки системи і архітектури програмних засобів.


5
Згідно з західними дослідженнями CASE
- технологія потрапила в розряд найбільш стабільних інформаційних технологій.
Разом з тим необхідно зазначити наступне:
CASE- засоби не обов'язково дають негайний ефект; він може бути отриманий тільки через деякий проміжок часу; реальні витрати на впровадження CASE
- засобів зазвичай набагато перевищують витрати на їх придбання;
CASE- засоби забезпечують можливості для отримання істотної вигоди тільки після успішного завершення процесу їх впровадження.
Сучасні CASE
- засоби охоплюють значну область підтримки чисельних технологій проектування інформаційних систем –
від простих засобів аналізу та документування до повномасштабних засобів автоматизації, що покривають важливий життєвий цикл ПЗ
Найбільш трудомісткими етапами розробки інформаційних систем є аналіз і проектування, в процесі яких CASE
- засоби забезпечують якість схвалюваних технічних рішень і підготовку проектної документації. При цьому велику роль відіграють методи візуального представлення
інформації. Вони припускає побудову структурних або інших діаграм в реальному масштабі часу, використання багатообразної колірної палітри, наскрізну перевірку синтаксичних правил. Графічні засоби моделювання дозволяють розробникам в наочному вигляді вивчати
існуючу інформаційну систему, перебудовувати її відповідно до поставлених цілей і наявних обмежень.
У CASE
- засоби потрапляють як досить дешеві системи для персональних комп'ютерів з обмеженими можливостями, так і дорогі системи для неоднорідних обчислювальних платформ і операційних середовищ. Так, сучасний ринок програмних засобів налічує близько 300 різних CASE
- засобів, найбільш могутні з яких використовуються практично всіма провідними західними компаніями.
Зазвичай до CASE
- засобів відносять будь
- який програмний засіб, що автоматизує ту або іншу сукупність процесів життєвого циклу ПЗ
і що володіє наступними особливостями:
графічні засоби для опису та документування ІС, що забезпечують зручний інтерфейс з розробником і розвивають його творчі можливості;
інтеграція окремих компонент CASE
- засобів, що забезпечує керованість процесом розробки інформаційної системи;


6 використання спеціальним чином організованого сховища проектних метаданих (репозиторію).
Інтегрований CASE
- засіб (або комплекс засобів, що підтримують повний життєвий цикл ПЗ) містить наступні компоненти: репозиторій, що є основою CASE
- засобу. Він повинен забезпечувати зберігання версій проекту та його окремих компонентів, синхронізацію надходження інформації від різних розробників при груповій розробці, контроль метаданих на повноту й несуперечність; графічні засоби аналізу і проектування, які забезпечуюють створення та редагування ієрархічно пов'язаних діаграм (DFD, ERD і ін.), що створюють моделі інформаційної системи; засоби розробки додатків, включаючи мови 4GL і генератори кодів; засоби конфігураційного управління; засоби документування; засоби тестування; засоби управління проектом; засоби реінжинірингу.
Усі сучасні CASE
- засоби можна класифікувати за типами й категоріями. Класифікація за типами відображає функціональну орієнтацію CASE
- засобів на ті або інші процеси життєвого циклу.
Класифікація за категоріями визначає ступінь інтегрованості за виконуваними функціями та включає окремі локальні засоби, вирішальні невеликі автономні завдання (tools), набір частково інтегрованих засобів, що охоплюють більшість етапів життєвого циклу інформаційних систем
(toolkit) і повністю інтегровані засоби, що підтримують важливий життєвий цикл інформаційних систем і пов'язані загальним репозиторієм.
Крім цього
CASE
- засобу можна класифікувати за використовуваними методологіями і моделями систем і БД, ступені
інтегрованості з СКБД.
Класифікація за типами в основному збігається з компонентним складом CASE
- засобів і включає:
засоби аналізу (Upper CASE) –
призначені для побудови й аналізу моделей наочної області (Design/IDEF (Meta Software), BPwin (Logic Works)); засоби аналізу і проектування (Middle CASE) –
підтримують найбільш поширені методології проектування використовні для створення проектних специфікацій (Vantage Team Builder (Cayenne),
Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas),


7
CASE.Аналитик (Макропроджект)). Виходом застосування таких засобів є специфікації компонентів і інтерфейсів системи, архітектура системи, алгоритмів і структур даних; засоби проектування баз даних, що забезпечують моделювання даних і генерацію схем баз даних (як правило, на мові SQL) для найбільш поширених
СКБД. До них відносяться ERwin (Logic Works), S
-Designor
(SDP) і DataBase Designer (ORACLE). Засоби проектування баз даних є також у складі CASE
- засобів Vantage Team Builder, Designer/2000,
Silverrun і PRO
-IV; засоби розроблення додатків. До них відносяться: засоби 4GL
(Uniface
(Compuware),
JAM
(JYACC),
PowerBuilder
(Sybase),
Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta),
Delphi (Borland) і ін.) і генератори кодів, що входять до складу Vantage
Team Builder, PRO-
IV і частково –
в Silverr un; засоби реінжинірингу, що забезпечують аналіз програмних кодів і схем баз даних і формування на їх основі різних моделей і проектних специфікацій. Засоби аналізу схем БД і формування ERD входять до складу Vantage Team Builder, PRO
-IV, Silverrun, Design er/2000, ERwin і S
-
Designor. В області аналізу програмних кодів найбільшого поширення набувають об'єктно
- орієнтовані CASE
- засоби, що забезпечують реінжиніринг програм на мові С++ (Rational Rose (Rational Software),
Object Team (Cayenne)).
Допоміжні типи включають:
засоби планування та управління проектом (SE Companion,
Microsoft Project і ін.); засоби конфігураційного управління (PVCS (Intersolv)); засоби тестування (Quality Works (Segue Software)); засоби документування (SODA (Rational Software)).
Ураховуючи різноманітну природу CASE
- засобів, було б помилково робити які
- небудь твердження щодо реального задоволення тих або
інших очікувань від їх упровадження.
Можна виділити наступні чинники, що ускладнюють визначення можливого ефекту від використання C
ASE- засобів:
широка різноманітність якості та можливостей CASE
- засобів; досить невеликий час використання CASE
- засобів у різних організаціях і недолік досвіду їх застосування; широка різноманітність у практиці впровадження різних організацій;


8 відсутність детальних метрик і даних для вже виконаних і поточних проектів; широкий діапазон наочних областей проектів; різний ступінь інтеграції CASE
- засобів у різних проектах.
Для успішного впровадження CASE
- засобів організація повинна володіти наступними якостями:
технологія. Розуміння обмеженості існуючих можливостей і здатність прийняти нову технологію;
культура.
Готовність до впровадження нових процесів і взаємин між розробниками і користувачами;
управління. Чітке керівництво і організованість по відношенню до найбільш важливих етапів і процесів впровадження.
Для того щоб ухвалити зважене рішення щодо інвестицій в CASE
- технологію, користувачі змушені проводити оцінку окремих CASE
- засобів, спираючись на неповні та суперечливі дані. Ця проблема часто посилюється недостатнім знанням всіх можливих "
підводних каменів " використання CASE
- засобів.
Серед найбільш важливих проблем виділяють наступні:
достовірна оцінка віддачі від інвестицій в CASE
- засоби скрутна, зважаючи на відсутність прийнятних метрик і даних за проектами і процесами розробки
ПЗ; впровадження
CASE
- засобів може представляти тривалий процес і не принести негайної віддачі. Можливо навіть короткострокове зниження продуктивності в результаті зусиль, що витрачаються на впровадження; відсутність повної відповідності між тими процесами та методами, які підтримуються CASE
- засобами, і тими, що використовуються в даній організації, може привести до додаткових труднощів;
CASE- засоби часто важко використовувати в комплексі з іншими подібними засобами. Це пояснюється як різними парадигмами, підтримуваними різноманітними засобами, так і проблемами передачі даних і управління від одного засобу до іншого; деякі CASE
- засоби вимагають дуже багато зусиль для того, щоб виправдати їх використання в невеликому проекті, проте, можна отримати вигоду з тієї дисципліни, до якої зобов'язує
їх застосування; негативне відношення персоналу до впровадження нової CASE
- технології може бути головною причиною провалу проекту.


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

Розділ 1

Принципи структурно
-
функціонального

проектування


1.1.
Загальні принципи структурних методів і

структурного аналізу

Структурні методи є дисципліною системного аналізу й проектування, тобто присвячені аналізу складних систем і
процесів
[1].
Методи структурного аналізу й проектування визначають аналіз складності великих систем шляхом розчленовування наступним чином:
декомпозиції їх на частини (так звані
"
чорні скриньки ");
ієрархічної організації цих частин.
Вигода при використанні чорних скриньок полягає в тому, що їх користувачам не потрібно знати, як вони працюють, а необхідно знати лише основні характеристики –
так звані входи й виходи, а також їх призначення –
функцію, яку вони виконують.
Отже, можна виділити наступні етапи спрощення складної системи чи об’єкта управління:
1.
Розбивка на чорні скриньки. При цьому цей процес повинен задовольняти наступним критеріям:
кожна чорна скринька повинна реалізовувати одну функцію системи;


10 функція кожної чорної скриньки повинна бути зрозуміла незалежно від складності її реалізації;
зв'язок між чорними скриньками повинен уводитися тільки за наявності зв'язку між відповідними функціями системи;
зв'язки між чорними скриньками повинні бути простими, наскільки це можливо для забезпечення незалежності між ними.
2. Ієрархія цих частин. Для аналізу складної системи недостатньо розбивки її на частини: необхідно ці частини організувати певним чином, а саме –
у вигляді множини ієрархічних структур.
3.
Використання графічних нотацій. Аналіз вимог розроблюваль
- ної
системи є найважливішим серед усіх етапів життєвого циклу (ЖЦ).
Він впливає на всі наступні етапи, будучи в той же час найменш вивченим і зрозумілим процесом
Проблеми, перед якими стає системний аналітик, взаємозалежні та характеризуються наступними твердженнями:
аналітикові складно одержати вичерпну інформацію для оцінки вимог до системи з погляду замовника;
замовник, у свою чергу, не має достатньої інформації щодо проблем обробки даних для того, щоб говорити про те, що є здійсненним, а що ні;
аналітик стикається з надмірною кількістю докладних відомостей як про предметну галузь, так і про нову систему;
специфікація системи не зрозуміла для замовника через обсяг тех
- нічних термінів;
у випадку зрозумілості специфікації для замовника вона буде недо
- статньо зрозумілою для проектувальників і програмістів, які створюють систему.
Структурним
аналізом
прийнято називати такий метод дослідження системи, що починається з її загального огляду й потім деталізується, здобуваючи ієрархічну структуру із все більшим числом рівнів. Для таких методів характерна розбивка на рівні абстракції з обмеженням кількості елементів на кожному з рівнів (від 3 до 6 –
7); обмежений контекст, що включає лише
істотні на кожному рівні деталі; дуальність даних і операцій над ними; використання суворих формальних правил запису; послідовне наближення до кінцевого результату.


11
Усі методології структурного аналізу базуються на ряді загальних принципів, частина з яких регламентує організацію робіт на початкових етапах ЖЦ системи або об’єкта управління, а частина використовується під час вироблення рекомендацій щодо організації робіт.
Використовуються два основних
(базових) принципи: принцип "
поді
- ляй і пануй "; принцип ієрархічного упорядкування.
Перший із них є принципом вирішення складних проблем шляхом розбивки їх на безліч менших незалежних завдань, більш легких для їх розуміння й вирішення. Другий принцип визначає, що легше зрозуміти проблему, якщо вона розбита на частини, та декларує, що побудова цих частин та отримані результати також важливі для розуміння.
До не основних принципів
структурного аналізу відносяться:
1) принцип абстрагування

полягає у виділенні істотних із деяких позицій аспектів системи й відволікання від несуттєвих з метою подання проблеми в простому загальному вигляді;
2) принцип формалізації –
полягає в необхідності суворого методич
- ного підходу до вирішення проблеми;
3) принцип приховування –
полягає у приховуванні
несуттєвої на конкретному етапі інформації: кожна декомпозована частина "
знає
" тільки необхідну їй інформацію;
4) принцип концептуальної спільності –
полягає у використанні єди
- ної філософії на всіх етапах ЖЦ (структурний аналіз –
структурне проек
- тування –
структурне програмування –
структурне тестування);
5) принцип повноти –
полягає в контролі на присутність зайвих елементів;
6) принцип несуперечливості –
полягає в обґрунтованості погодже
- ності елементів;
7) принцип логічної незалежності –
полягає в концентрації уваги на логічному проектуванні для забезпечення незалежності від фізичного проектування;
8) принцип незалежності даних –
полягає в тому, що моделі даних повинні бути проаналізовані й спроектовані незалежно від процесів їх логічної обробки, а також від їх фізичної структури й розподілу;
9) принцип структурування даних –
полягає в тому, що дані повинні бути структуровані й ієрархічно організовані;


12 10) принцип доступу кінцевого користувача –
полягає в тому, що ко
- ристувач повинен мати засоби доступу до бази даних, які він може вико
- ристати безпосередньо (без програмування).
Для цілей моделювання систем та об’єктів взагалі й використання структурного аналізу зокрема, використовуються три групи засобів, що визначають наступні компоненти:
функції,
які система повинна виконувати;
відносини між даними
; залежне від часу поводження системи
(поведінковий аспект).
Серед засобів вирішення цих завдань у методологіях структурного аналізу найбільш часто й ефективно застосовуваними
є наступні
[1]:
DFD (Data Flow Diagrams)

діаграми потоків

даних
;
ERD (Entity-Relationship Diagrams)

діаграми
"
сутність –

зв'язок
";
STD (State Transition Diagrams)

діаграми переходів станів
Логічна DFD виконує наступні функції:
показує зовнішні (стосовно системи) джерела й стоки даних;
ідентифікує логічні функції (процеси) і групи елементів даних;
з’єднує одну функцію з іншими (за допомогою потоків);
ідентифікує сховища (накопичувачі) даних, до яких користувачами системи здійснюється доступ
Структури потоків даних і визначення їх компонентів зберігаються й аналізуються у словнику даних. Зміст кожного сховища також зберігають у словнику даних, модель даних сховища розкривається за допомогою
ERD. У випадку наявності реального часу засоби DFD доповнюються засобами опису залежного від часу поводження системи, що визначається на основі діаграм переходів станів –
STD
(рис. 1.1).



13
Процес
Процес
DFD
DFD
Процес
Процес
Сховище даних
Управлінський процес
Управлінський процес
Потік
Потік даних даних
Специфікація процесу
Специфікація процесу
Словник даних
Словник даних
ERD
ERD
STD
STD
Деталізуюча
DFD
Деталізуюча
DFD

Рис. 1.1.



Поділіться з Вашими друзьями:
  1   2   3   4   5   6   7   8   9   ...   20


База даних захищена авторським правом ©chito.in.ua 2019
звернутися до адміністрації

    Головна сторінка