Студопедия
Новини освіти і науки:
МАРК РЕГНЕРУС ДОСЛІДЖЕННЯ: Наскільки відрізняються діти, які виросли в одностатевих союзах


РЕЗОЛЮЦІЯ: Громадського обговорення навчальної програми статевого виховання


ЧОМУ ФОНД ОЛЕНИ ПІНЧУК І МОЗ УКРАЇНИ ПРОПАГУЮТЬ "СЕКСУАЛЬНІ УРОКИ"


ЕКЗИСТЕНЦІЙНО-ПСИХОЛОГІЧНІ ОСНОВИ ПОРУШЕННЯ СТАТЕВОЇ ІДЕНТИЧНОСТІ ПІДЛІТКІВ


Батьківський, громадянський рух в Україні закликає МОН зупинити тотальну сексуалізацію дітей і підлітків


Відкрите звернення Міністру освіти й науки України - Гриневич Лілії Михайлівні


Представництво українського жіноцтва в ООН: низький рівень культури спілкування в соціальних мережах


Гендерна антидискримінаційна експертиза може зробити нас моральними рабами


ЛІВИЙ МАРКСИЗМ У НОВИХ ПІДРУЧНИКАХ ДЛЯ ШКОЛЯРІВ


ВІДКРИТА ЗАЯВА на підтримку позиції Ганни Турчинової та права кожної людини на свободу думки, світогляду та вираження поглядів



Контакти
 


Тлумачний словник
Авто
Автоматизація
Архітектура
Астрономія
Аудит
Біологія
Будівництво
Бухгалтерія
Винахідництво
Виробництво
Військова справа
Генетика
Географія
Геологія
Господарство
Держава
Дім
Екологія
Економетрика
Економіка
Електроніка
Журналістика та ЗМІ
Зв'язок
Іноземні мови
Інформатика
Історія
Комп'ютери
Креслення
Кулінарія
Культура
Лексикологія
Література
Логіка
Маркетинг
Математика
Машинобудування
Медицина
Менеджмент
Метали і Зварювання
Механіка
Мистецтво
Музика
Населення
Освіта
Охорона безпеки життя
Охорона Праці
Педагогіка
Політика
Право
Програмування
Промисловість
Психологія
Радіо
Регилия
Соціологія
Спорт
Стандартизація
Технології
Торгівля
Туризм
Фізика
Фізіологія
Філософія
Фінанси
Хімія
Юриспунденкция






Методологія об'єктно-орієнтованого аналізу і проектування

 

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

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

Об'єктно-орієнтований аналіз і проектування (ООАП, Object-Oriented Analysis/Design) - технологія розробки програмних систем, в основу яких покладена об'єктно-орієнтована методологія представлення наочної області у вигляді об'єктів, відповідних класів, що є екземплярами.

Методологія ООАП тісно пов'язана з концепцією автоматизованої розробки програмного забезпечення (Computer Aided Software Engineering, CASE). До перших CASE-средствам віднеслися з певною настороженістю. З часом з'явилися як захоплені відгуки про їх вживання, так і критичні оцінки їх можливостей. Причин для настільки суперечливих думок було декілька. Перша з них полягає в тому, що ранні CASE-средства були простою надбудовою над системою управління базами даних (СУБД). Візуалізація процесу розробки концептуальної схеми БД має важливе значення, проте, вона не вирішує проблем створення програмних засобів інших типів.

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

В рамках ООАП історично розглядалися три графічні нотації:

· діаграми "сутність-зв'язок" (Entity-Relationship Diagrams, ERD)

· діаграми функціонального моделювання (Structured Analysis and Design Technique, SADT)

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

 

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

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

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

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

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

 


Рис. 1.2. Діаграма "сутність-зв'язок" для прикладу співробітників компанії, що працюють над різними проектами

 

 

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

· Нотація IDEF0 - для документування процесів виробництва і відображення інформації про використання ресурсів на кожному з етапів проектування систем

· Нотація IDEF1 - для документування інформації про виробниче оточення систем

· Нотація IDEF2 - для документування поведінки системи в часі

Нотація IDEF2 ніколи не була повністю реалізована. Нотація IDEF1 в 1985 році була розширена і перейменована в IDEF1X. Методологія IDEF знайшла вживання в урядових і комерційних організаціях, оскільки в 1993 році з'явився стандарт FIPS уряду США для двох технологій IDEF0 і IDEF1X. Протягом подальших років цей стандарт продовжував активно розвиватися і послужив основою для реалізації в деяких CASE-средствах, найбільш відомим з яких є AllFusion Process Modeler® (нова назва BPwin® ) компанії Computer Associates.

Процес моделювання IDEF є сукупністю методів, правив і процедур, призначених для побудови функціональної моделі системи якої-небудь наочної області. Функціональна модель IDEF відображує структуру процесів функціонування системи і її окремих підсистем, тобто, виконувані ними дії і зв'язки між цими діями. Для цієї мети будуються спеціальні моделі, які дозволяють в наочній формі представити послідовність певних дій. Вихідними будівельними блоками будь-якої моделі нотації IDEF0 процесу є діяльність (activity) і стрілки (arrows).

Одна з найбільш важливих особливостей нотації IDEF0 - поступове введення усе більш детальних представлень моделі системи у міру розробки окремих діаграм. Побудова моделі IDEF0 починається з представлення всієї системи у вигляді простої діаграми, що складається з одного блоку процесу і стрілок ICOM, службовців для зображення основних видів взаємодії з об'єктами поза системою. Оскільки вихідний процес представляє всю систему як єдина ціла, дана вистава є найбільш загальною і підлягає подальшій декомпозиції. Приклад представлення загальній моделі процесу оформлення кредиту в банці, розробленій за допомогою CASE-средства AllFusion Process Modeler®, змальований на мал. 1.3.


Рис. 1.3. Приклад вихідної діаграми IDEF0 для процесу оформлення кредиту в банці

 

 

Зрештою модель IDEF0 є набором ієрархічно взаємозв'язаних діаграм з супровідною документацією, як

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

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

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

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




Переглядів: 2440

<== попередня сторінка | наступна сторінка ==>
 | 

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

 

© studopedia.com.ua При використанні або копіюванні матеріалів пряме посилання на сайт обов'язкове.


Генерація сторінки за: 0.007 сек.