8

КАФЕДРА КОМПЮТЕРНИХ ТА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ

Курсова робота

З дисципліни «Графічне та геометричне моделювання та інтерактивні системи»

На тему « Система обліку курсів »

ЗМІСТ

• ВСТУП 3
• ПОСТАНОВКА ЗАДАЧІ 4
• ІНФОРМАЦІЙНЕ ЗАБЕЗПЕЧЕННЯ 6
• АЛГОРИТМ РОЗВЯЗАННЯ ЗАДАЧІ 7
• ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ 12
• ВИСНОВКИ 14
• СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ 15

ВСТУП

Розповсюдження об`єтно-орієнтованих мов програмування в кінці 80-их - початку 90-х років давало потужний поштовх до розробки цього напрямку інформаційних технологій. Користувачам хотілося отримати єдину мову моделювання, яка б об`єднала в собі всю міць об`єктно-орієнтованого підходу і давала б чітку модель системи, яка відображає всі її значимі сторони.

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

Все йшло до створення єдиної мови, яка б об`єднала сильні сторони відомих методів і забезпечувала найкращу підтримку моделювання. І UML стала такою мовою.

UML може бути застосованим на всіх етапах життєвого циклу аналізу бізнес-систем і розробки приложень. Різні види діаграм, які підтримує UML, і великий набір можливостей представлення певних аспектів системи роблять UML універсальним засобом опису як програмних, так і ділових систем.

Ціллю даного курсового проекту є побудова моделі на мові UML, що описує систему прийняття та обліку слухачів навчальних курсів.

Результатом розробки курсового проекту є систематизація роботи навчальних курсів щодо прийняття нових студентів, побудова набору діаграм, і , як наслідок, освоєння та заглиблення розуміння процесу проектування на мові UML.

ПОСТАНОВКА ЗАДАЧІ

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

У даній курсовій роботі демонструється можливий підхід до моделювання системи обліку слухачів на курсах з використанням уніфікованої нотації, заснований на застосуванні Уніфікованої Мови Моделювання (Unified Modeling Language) (UML), і гармонійно сполучить у собі переваги структурних і обєктних методів проектування в CASE Rational Rose.

Основними задачами при моделюванні предметної області є опис:

1. Процесів предметної області;

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

3. Сутностей;

4. Сценаріїв виконання функцій, що підлягають автоматизації;

5. Станів сутностей.

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

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

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

На основі цієї моделі будується модель функцій системи.

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

Наступною задачею при описі предметної області є моделювання документів.

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

1. Проектування користувальницького інтерфейсу системи;

2. Проектування Бази даних системи;

3. Формування альбому вихідних форм системи.

У деяких випадках при моделюванні предметної області варто описати сценарій роботи діючого обличчя із сутностями і стану сутностей.

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

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

ІНФОРМАЦІЙНЕ ЗАБЕЗПЕЧЕННЯ

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

· Ім`я слухача;

· Прізвище слухача;

· Дата народження слухача;

· Ідентифікаційний номер.

Вихідна інформація. Такою інформацією є дані, що зявляються в результаті роботи системи:

· Оцінка за випускні іспити;

· Номер отриманого диплома.

АЛГОРИТМ РОЗВЯЗАННЯ ЗАДАЧІ

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

Діаграма (Dіagram) - це графічне представлення безлічі елементів. Найчастіше вона зображується у виді звязного графа з вершинами (сутностями) і ребрами (відносинами). Діаграма являє собою деяку проекцію системи.

Загальний алгоритм розвязання задачі такий: використовуємо Use case dіagram для відображення списку операцій, що повинна виконувати наша система. Кожен Use case - це деякий процес (послідовність дій), тому ми повинні використовувати Sequence dіagram для його деталізації. На цій діаграмі ми відображаємо обєкти з предметної області (обєкти, що беруть участь у процесі); таким чином, ми одержуємо екземпляри деяких класів і їхню взаємодію. Sequence dіagram відображає сам процес, статична картина взаємодії обєктів відображається за допомогою Class dіagram. Переходимо до Class dіagram, на якій зображуються класи нашого проекту. Далі класи поєднуються в компоненти, що відображаються на Component dіagram, де показується залежність компонентів між собою. В даному випадку нам не потрібно створювати Deployment dіagram, на якій відображається розміщення компонентів на компютерах.

Першою була створена діаграма прецедентів. Вона має вигляд, який показаний на малюнку 1

Малюнок 1 Use Case Diagram (Main)

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

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

Кожна така діаграма, чи як її звичайно називають, кожен Use case - це опис сценарію поводження, якому слідують діючі обличчя (Actors).

Наступною була створена діаграма класів, яка зображена на малюнку 2.

Малюнок 2 Class diagram

На наступному кроці була створена діаграма послідовностей дій (Sequence diagram) для прецеденту „заносити інформацію про студентів” актора „оператор”, яка представлена на малюнку 3. На ній можна побачити класи та операції, які застосовуються до кожного з них у суворій послідовності. Цей тип діаграми не акцентує увагу на конкретній взаємодії, головний акцент приділяється послідовності прийому/передачі повідомлень.

Малюнок 3 Sequence diagram

На наступному кроці ми створили діаграму кооперацій (Collaboration diagram), яка зображена на малюнку 4.

Малюнок 4 Collaboration diagram

Далі ми реалізували діаграму станів (Statechart diagram), яка зображена на малюнку 5. Діаграма станів (Statechart) призначена для відображення станів об`єктів системи, що мають складну модель поведінки.

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

Малюнок 5 Statechart diagram (діаграма станів)

Наступним етапом стало створення діаграми компонентів(Component diagram), яка зображена на малюнку 6. Цей тип діаграм призначений для розподілу класів та об`єктів за компонентами при фізичному проектуванні системи. Часто даний тип діаграм називають діаграмами модулів.

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

Малюнок 6 Component diagram (діаграма компонентів)

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

ПРОГРАМНЕ ЗАБЕЗПЕЧЕННЯ

Для розробки курсового проекту була використана мова UML та система автоматизованої розробки ПЗ Rational Rose 2003.

В даний час для цілей моделювання предметної області на ринку програмних продуктів представлений широкий спектр CASE-засобів. Найбільш популярними в нашій країні CASE-засобами є Rational Rose, BPwin, Silverrun, Process Analyst. Моделювання предметної області в цих засобах має скоріше багато загального, чим розходжень. Однак немаловажним, на наш погляд, є комплексність підходу і використання єдиної уніфікованої нотації, не тільки на етапі моделювання предметної області, але і на наступних етапах розробки програмної системи, як це має місце в CASE Rational Rose.

Ratіonal Rose 2003 займає унікальне місце в ряді CASE продуктів візуального моделювання складних програмних систем, що маються на ринку і має стратегічну перевагу в плані розвитку продукту. Така оцінка заснована на тому, що Ratіonal Rose 2003:

· Підтримує генерацію коду і зворотнє проектування (тобто побудова моделі по програмному коду) відразу для декількох мов (Vіsual Basіc, C++, Java, PowerBuіlder, CORBA Іnterface Defіnіtіon Language(ІDL), Data Defіnіtіon Language для більшості СУБД, ERwіn моделі).

· Підтримує візуальне обєктно-орієнтоване моделювання,.

· Має широкі перспективи розвитку, у тому числі за рахунок появи додаткових продуктів (Lіnks).

· Орієнтований на розроблювачів архітектури інформаційних систем (ІС), менеджерів ІС і програмістів.

В ході побудови діаграм було використано таку властивисть, як зворотнє проектування. Для цього в меню треба вибрати пункт Tools >Visual C ++ > Update Model from Code. Далі у віконці, яке має назву Model Update Tool - Welcome треба натиснути клавішу OK. Зявиться віконце Select Components and Classes, в якому треба натиснути клавішу Add Component. Далі перейти на вкладку Existing та вибрати потрібний файл .dsw.

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

Діаграми дають можливість представити систему (як ділову, так і програмну) у такому виді, щоб її можна було легко перевести в програмний код Ratіonal Rose - обєктно-орієнтований інструмент моделювання, що базується на UML (Unіversal Modelіng Language) - універсальній мові моделювання, що була розроблена компанією Ratіonal саме з метою створення найбільш оптимальної й універсальної мови для опису як предметної області, так і конкретної задачі в програмуванні. Будь-яка задача програмується за допомогою визначених діаграм.

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

ВИСНОВКИ

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

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

В ході розробки курсового проекту побудовано модель системи обліку слухачів на навчальних курсах на мові UML. Ця модель складається з діаграм класів, прецедентів, послідовностей дій, взаємодій та компонентів.

Дана модель може бути вдосконалена наступним чином:

· Побудовою інших діаграм;

· Вдосконаленням існуючих діаграм;

· Більш розгорнутим описом специфікацій.

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

СПИСОК ВИКОРИСТАНОЇ ЛІТЕРАТУРИ

Головатий О.О. Методичні вказівки до оформлення пояснювальних записок із дипломних робіт, літньої практики, курсових робіт та рефератів для студентів спеціальностей “Програмне забезпечення автоматизованих систем” та “Економічна кібернетика”. Жовті Води, ІП “Стратегія”, 2005.

Баранов Д.О. Методичні вказівки до оформлення пояснювальної записки.

Кознов Д.В., Кузнецов С.В., Романовский К.Ю. Объектно - ориентированный подход и диаграммы классов.

Корсачев А. Общие принципы построения модели в Rational Rose

Мищук А. Применение UML в жизненном цикле проектов (www.ci.ru).

Новичков А.Н. Rational Rose для разработчиков и ради разработчиков, 2000.Трофимов С.

Рамбо Д. Тенденции в развитии языка UML и разработки ПО.

.Rational Rose - Case продукт нового поколения

UML диаграммы в Rational Rose (www.caseclub.ru).

UML - новый стандарт языка объектно - ориентированного моделирования. Квинтэссенция успешного опыта (www.ci.ru).

Буч Г. UML. Руководство пользователя, Москва 2004.