І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації - страница 22

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 

1)     зовнішня сутність;

2)     робота;

3)     сховище даних;

4)     потік даних.

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

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

наявність великої кількості зовнішніх сутностей (десяти й більше);

розподілена природа системи;

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

Для складних ІС будується ієрархія контекстних діаграм. При цьому контекстна діаграма верхнього рівня містить не єдиний головний процес, а набір підсистем, поєднаних потоками даних. Контекстні діаграми наступного рівня деталізують контекст і структуру підсистем.

Об'єкти, використовувані в нотації DFD



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

Після побудови контекстних діаграм отриману модель слід перевірити на повноту початкових даних про об'єкти системи й ізольованість об'єктів (відсутність інформаційних зв'язків з іншими об'єктами).

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

правило балансування - означає, що під час деталізації підсистеми або процесу діаграма, яка деталізує зовнішні джерела/приймачі даних може мати лише ті компоненти (підсистеми, процеси, зовнішні сутності, накопичувачі даних), з якими має інформаційний зв'язок підсистема, що деталізується, або процес на батьківській діаграмі;

правило нумерації - означає, що в ході деталізації процесів повинна підтримуватися їх ієрархічна нумерація. Наприклад, процеси, що деталізують процес з номером 2, отримують номери 2.1, 2.2, 2.3 і т. д.

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

Мініспецифікація є кінцевою вершиною ієрархії DFD. Рішення про завершення деталізації процесу і використання мініспецифікації ухвалюється аналітиком на основі таких критеріїв:

наявності в процесу відносно невеликої кількості вхідних і вихідних потоків даних (2 - 3 потоки);

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

виконання процесом єдиної логічної функції перетворення вхідної інформації у вихідну;

можливості опису логіки процесу за допомогою мініспецифікації невеликого обсягу (не більше 20 - 30 рядків).

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

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

 

11.2.5. Методології моделювання даних

 

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

Найбільш поширеним засобом моделювання даних є діаграми "сутність - зв'язок" (ERD). З їх допомогою визначаються важливі для предметної області об'єкти (сутності), їх властивості (атрибути) і відносини один з одним (зв'язки). ERD безпосередньо використовуються для проектування реляційних баз даних. Нотація ERD була вперше запроваджена П. Ченом (Chen) і отримала подальший розвиток у роботах Беркера.

Методологія IDEF1. Метод IDEF1, розроблений Т. Ремей (T. Ramey), також заснований на підході П. Чена і дозволяє забудувати модель даних, еквівалентну реляційній моделі в третій нормальній формі. Заразна основі вдосконалення методології IDEF1 створена її нова версія -методологія IDEF1X. IDEF1X розроблена з урахуванням таких вимог, як простота вивчення і можливість автоматизації. IDEF1X-діаграми використовуються рядом поширених CASE-засобів (зокрема, ERWin, Design/IDEF).

 

11.2.6. Методологія моделювання потоків робіт IDEF3

 

Нотація  IDEF3,  яка  називається  ще workflow diagramming

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

описати виконання в певній послідовності процесів разом з об'єктами;

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

описати сценарії дій співробітників організації.

Для побудови моделі в нотації IDEF3 використовуються об'єкти, характеристика яких наведена в табл. 17.

У моделі використовуються такі ж види стрілок, як в IDEF0 (див. табл. 15).

У ході побудови моделі зв'язки заказують відношення між роботами. Усі зв'язки мають один напрямок, можуть бути спрямовані куди завгодно. Однак існує правило, що рекомендує спрямовувати стрілки зліва направо.


Таблиця 17
11.2.7. Структурне проектування

У процесі структурного проектування виконуються два види робіт:

1)   проектування архітектури ІС, що включає:

розробку структури й інтерфейсів її компонентів (автоматизованих робочих місць);

узгодження функцій і технічних вимог до компонентів;

визначення інформаційних потоків між основними компонентами, зв'язків між ними і зовнішніми об'єктами;

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

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

При цьому відбувається розширення моделі вимог за рахунок:

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

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

побудови моделей міжмодульних і внутрішньомодульних взаємодій з використанням техніки структурних карт.

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

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

структурні карти Джексона - для опису внутрішньої структури модулів. Структурні карти Константайна є моделлю відносин ієрархії між

16Зпрограмними модулями. Вузли структурних карт відповідають модулям і областям даних, потоки відображають міжмодульні виклики (у тому числі циклічні, умовні й рівнобіжні). Міжмодульні зв'язки за даними і управлінням також моделюються спеціальними вузлами, прив'язаними до потоків, стрілками вказуються напрямки потоків і зв'язків. Фундаментальні елементи структурних карт Константайна стандартизовані IBM, ISO і ANSI.

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

 

11.3. Об'єктний підхід до проектування ІС

 

11.3.1. Сутність об'єктного підходу

Об'єктно-орієнтовані методології засновані на об'єктній декомпозиції предметної області. Предметна область подається у вигляді сукупності об'єктів, що взаємодіють між собою за допомогою передачі повідомлень. В об'єктній методології використовуються поняття, визначення яких наведене в табл. 18.


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


1

2

 

3

об'єктно-орієнто­вана декомпозиція

object-oriented composition

de-

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

об'єктно-орієнто-ване програмування

object-oriented pro­gramming (OOP)

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

об'єктно-орієнто­ване проектування

object-oriented (OOD)

design

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

об'єктно-орієнто­ваний аналіз

object-oriented sis

analy-

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

операція

operation

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

поведінка

behavior

Дії та реакції об'єкта, виражені в термінах передачі повідомлень і зміни стану; видима ззовні і відтворена активність об'єкта

стан

state

Сукупний результат поведінки об'єкта: одна зі стабільних умов, у яких об'єкт може існувати, охарактеризованих кількісно; у будь-який конкретний момент часу стан об'єкта включає перелік (зазвичай, статичний) властивостей об'єкта і поточні значення (зазвичай, динамічні) цих властивостей

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

Об'єкти і класи організуються з дотриманням таких принципів:

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

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

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

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

Об'єктно-орієнтовані методології базуються на інтегрованих моделях трьох типів:

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

динамічної моделі, що відображає часові аспекти й послідовність операцій;

функціональної моделі, що описує потоки даних.

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

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

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

11.3.2. Стандарти об'єктного проектуванняНа сьогодні для об'єктно-орієнтованого моделювання проблемної сфери широко використовується уніфікована мова моделювання UML (Unified Modeling Language), яка розроблена групою провідних комп'ютерних фірм світу OMG (Object Management Group) і фактично є стандартом з об'єктно-орієнтованих технологій. Мова UML реалізована багатьма фірмами-виробниками програмного забезпечення в рамках CASE-технологій, на­приклад Rational Rose (Rational), Natural Engineering Workbench (Software AG), ARIS Toolset (IDS prof. Scheer) та ін.

Страницы:
1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44 


Похожие статьи

І О Ушакова - Соціальні мережі як засіб впливу на взаємовідносини з клієнтами

І О Ушакова - Основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Практикум з навчальної дисципліни основи системного аналізу об'єктів і процесів комп'ютеризації

І О Ушакова - Робоча програма навчальної дисципліни Проектування інформаційних систем

І О Ушакова - Робоча програма навчальної дисципліни системний аналіз для студентів напряму підготовки 6 050101 комп'ютерні науки