Технології об"єктно-орієнтованого аналізу та проектування інформаційних систем. Історія та структура мови UML. Опис функціональної моделі засобами UML. Використання UML в проектуванні програмного забезпечення. Характеристика CASE-засобів Visual Paradigm.
При низкой оригинальности работы "Проектування програмного продукту із застосуванням систем візуального моделювання", Вы можете повысить уникальность этой работы до 80-100%
Розробка моделі програмної системи промислового чи комерційного рівня завжди передує створення нової або оновлення старої. Продумані моделі дуже важливі як для взаємодії команд, що беруть участь у розробці, так і для впевненості в "архітектурної узгодженості" всього проекту, до того як він буде реалізований у вигляді коду. Ми будуємо моделі складних систем, бо не може "охопити" ні одну з таких систем у всій її повноті і цілісності. Метод ГО аналізу дозволяє справлятися і нормально описувати складності, властиві реальним системам. Але при збільшенні складності систем, виникає все більша необхідність в хорошій технології моделювання.Концепції обєктно-орієнтованого аналізу і проектування. Поява нових моделей процесорів і комплектуючих, версій операційних систем і програмного забезпечення відбувається на тлі постійного ускладнення не тільки окремих фізичних та програмних компонентів, а й лежать в їх основі концепцій. Розробка і вдосконалення інформаційних систем призводить до необхідності підтримки єдиного стилю для різних версій програм при їх постійної доробки та модифікації. Трудомісткість створення сучасних додатків на початкових етапах проекту, як правило, оцінюється значно нижче реально витрачених зусиль, що служить причиною незапланованих витрат і затягування остаточних термінів готовності програм. Модель (model) - абстракція фізичної системи, що розглядається з певної точки зору і представлена на деякій мові або в графічній формі.Зокрема, процедурно-орієнтована декомпозиція програм поступилася місцем обєктно-орієнтованої, при якій в якості окремих структурних одиниць програми розглядаються не процедури і функції, а класи та обєкти з відповідними властивостями і методами. Абстракція визначає межу подання відповідного елемента моделі і застосовується для визначення фундаментальних понять ООП, таких як клас і обєкт. Обєкти, які не мають ідентичних властивостей або не володіють однаковим поведінкою, за визначенням, не можуть бути віднесені до одного класу. При цьому якщо загальний або батьківський клас (предок) має фіксованим набором властивостей і поведінкою, то похідний від нього клас (нащадок) повинен містити цей же набір властивостей і подібна поведінка, а також додаткові, які будуть характеризувати унікальність отриманого класу. Якщо як похідного розглянути клас "Персональний компютер", то всі виділені вище властивості міститиме і цей клас.Так, при проектуванні бази даних виникає необхідність в попередній розробці концептуальної схеми або моделі, яка відображала б загальні взаємозвязки предметної області та особливості організації відповідної інформації. Складність моделювання предметної області та розробки корпоративних інформаційних систем привело до появи нової методології обєктно-орієнтований аналіз та проектування. В рамках ООАП історично розглядалися три графічних нотації: • діаграми "сутність-звязок" (Entity-Relationship Diagrams, ERD), • діаграми функціонального моделювання (Structured Analysis and Design Technique, SADT), • діаграми потоків даних (Data Flow Diagrams, DFD). Графічна модель даних будується таким чином, щоб звязки між окремими сутностями відображали не тільки семантичний характер відповідного ставлення, але й додаткові аспекти обовязковості звязків, а також кратність що беруть участь в даних відносинах екземплярів сутностей. В рамках діаграм функціонального моделювання було розроблено декілька графічних мов моделювання, які отримали такі назви: • Нотація IDEF0 - для документування процесів виробництва і відображення інформації про використання ресурсів на кожному з етапів проектування системВ даній дипломній роботі «Проектування програмного продукту із застосуванням систем візуального моделювання» необхідно виконати наступне: Розглянути сучасні технології обєктно-орієнтованого аналізу та проектування інформаційних системУ практичній частині розглянути: · Використання UML в проектуванні ПЗ · Характеристику CASE-засоби Visual Paradigm В лабораторному практикумі розробити методичні рекомендації щодо виконання лабораторних робітВизначення візуального моделювання програмного забезпеченняОрієнтовна схема, що відображає процес від постановки завдання до випуску готового продукту може виглядати так: Принципово можна виділити 2 види розбиття предметної області на складові елементи: - Алгоритмічна декомпозиція (основні елементи програми - будівельні блоки - алгоритми). На сьогоднішній день обєктний підхід і його основи - обєктна модель і обєктна декомпозиція - підтримуються сучасними обєктно-орієнтованими мовами програмування (Object Pascal, C , Java, C # ...). Обєктний підхід: - OOA (object oriented analysis) - обєктно-орієнтований аналіз. OOD (object oriented design) - обєктно-орієнтоване проектування. Буча): Обєктно-орієнтований аналіз - це методологія, при якій вимоги до системи сприймаються з точки зору класів та обєктів, виявлених в предметної області [2].Проекти не вкладаються в терміни, бюджет, не задовольняють вимогам. На допомогу приходи
План
ЗМІСТ
Вступ
1. Літературний огляд. Сучасні технології обєктно-орієнтованого аналізу та проектування інформаційних систем
1.1 Методологія обєктно-орієнтованого програмування
1.2 Методологія обєктно-орієнтованого аналізу і проектування
2. Постановка завдання
3. Теоретична частина. Визначення візуального моделювання програмного забезпечення
3.1 Аналіз та проектування
3.2 Візуальне моделювання. Історія мови UML
3.3 Структура мови UML
3.4 Навчальний приклад. Постановка завдання
3.5 Візуальний опис функціональної моделі засобами UML
3.6 Структура системи та її опис засобами UML
4. Практична частина
4.1 Використання UML в проектуванні ПЗ
4.2 Загальна характеристика CASE-засобів Visual Paradigm
4.3 Інтерфейс програми VP-UML
4.4 Принцип роботи в VP-UML
4.5 Лабораторний практикум
4.5.1 Лабораторна робота № 1 «Діаграма прецедентів»
4.5.2 Лабораторна робота № 2 «Діаграми класів»
4.5.3 Лабораторна робота № 3 «Діаграма послідовності»
4.5.4 Лабораторна робота № 4 «Діаграма комунікацій»
Висновок
Література
Вы можете ЗАГРУЗИТЬ и ПОВЫСИТЬ уникальность своей работы