Презентация на тему Методологія об’єктно-орієнтованого аналізу і проектування

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

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

CASE-засобах. Якщо мови програмування мають строгий синтаксис, то спроби

запропонувати відповідний синтаксис для візуального представлення концептуальних схем БД, були сприйняті далеко не однозначно. На цьому фоні розробка і стандартизація уніфікованої мови моделювання UML викликала натхнення у всього співтовариства корпоративних програмістів.
В рамках ООАП історично розглядалися три графічні нотації:
· діаграми "сутність-зв'язок" (Entity-Relationship Diagrams, ERD)
· діаграми функціонального моделювання (Structured Analysis and Design Technique, SADT)
· діаграми потоків даних (Data Flow Diagrams, DFD).

окремими сутностями відображали не лише семантичний характер відповідного відношення,

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

в детальніше представлення модельованої програмної системи, яке окрім статичних

зв'язків повинне містити інформацію про поведінку або функціонування окремих її компонентів.

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

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

поступове введення усе більш детальних представлень моделі системи у

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