КАФЕДРАКОМП’ЮТЕРНИХ ТА ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ
Курсоваробота
Здисципліни «Графічне та геометричне моделювання та інтерактивні системи»
Натему « Система обліку курсів »
ЗМІСТ
ВСТУП… 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 для його деталізації. На ційдіаграмі ми відображаємо об'єкти з предметної області (об'єкти, що берутьучасть у процесі); таким чином, ми одержуємо екземпляри деяких класів і їхню взаємодію. Sequencedі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 Sequencediagram
Нанаступному кроці ми створили діаграму кооперацій (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. Ця модель складається здіаграм класів, прецедентів, послідовностей дій, взаємодій та компонентів.
Дана модель може бути вдосконалена наступним чином:
· Побудовоюінших діаграм;
· Вдосконаленняміснуючих діаграм;
· Більшрозгорнутим описом специфікацій.
Ця модель стане не заміним помічником для всіх, хто прагне зрозуміти, щособою уявляє та на яких принципах базується система обліку слухачів нанавчальних курсах./>/>/>СПИСОКВИКОРИСТАНОЇ ЛІТЕРАТУРИ
1. Головатий О.О. Методичні вказівки дооформлення пояснювальних записок із дипломних робіт, літньої практики, курсовихробіт та рефератів для студентів спеціальностей “Програмне забезпеченняавтоматизованих систем” та “Економічна кібернетика”. Жовті Води, ІП“Стратегія”, 2005.
2. Баранов Д.О. Методичні вказівки дооформлення пояснювальної записки.
3. Кознов Д.В., Кузнецов С.В.,Романовский К.Ю. Объектно – ориентированный подход и диаграммы классов.
4. Корсачев А. Общие принципы построениямодели в Rational Rose
5. Мищук А. Применение UML в жизненном цикле проектов (www.ci.ru).
6. Новичков А.Н. Rational Rose для разработчиков и радиразработчиков, 2000.ТрофимовС.
7. Рамбо Д. Тенденции в развитии языка UML и разработки ПО.
8. .Rational Rose – Caseпродукт нового поколения
9. UML диаграммы в Rational Rose (www.caseclub.ru).
10. UML – новый стандарт языка объектно –ориентированного моделирования. Квинтэссенция успешного опыта (www.ci.ru).
11. Буч Г. UML. Руководство пользователя, Москва2004.