p align="justify"> При об'єктно-орієнтованому підході аналіз вимог до системи зводиться до розробки моделей цієї системи. Моделью системи (або будь-якого іншого об'єкта чи явища) ми називаємо формальний опис системи, у якому виділено основні об'єкти, що становлять систему, та відносини між цими об'єктами. Побудова моделей - поширений спосіб вивчення складних об'єктів і явищ. У моделі опущені численні деталі, що ускладнюють розуміння. Моделювання поширене й у науці, й у техніці.
Моделі допомагають:
Перевірити працездатність системи, що розробляється на ранніх етапах її розробки;
Спілкуватися із замовником системи, уточнюючи його вимоги до системи;
Вносити (у разі потреби) зміни у проект системи (як на початку її проектування, так і на інших фазах її життєвого циклу).
В даний час існує декілька технологій об'єктно-орієнтованої розробки прикладних програмних систем, в основі яких лежить побудова та інтерпретація на комп'ютері моделей цих систем. У цьому проекті застосована одна з них – OMT (Object Modeling Techniques). Крім того, побудована діаграма об'єктної моделі на мові UML.
Об'єктна модель визначає структуру об'єктів, що становлять систему, їх атрибути, операції, взаємозв'язки коїться з іншими об'єктами. В об'єктній моделі повинні бути відображені ті поняття та об'єкти реального світу, які важливі для системи, що розробляється. В об'єктній моделі відображається насамперед прагматика системи, що розробляється, що виражається у використанні термінології прикладної області, пов'язаної з використанням системи, що розробляється.
Визначення класів об'єктної моделі
Аналіз зовнішніх вимог до проектованої системи дозволяє визначити об'єкти та класи об'єктів, пов'язані з прикладною проблемою, яку має вирішувати ця система. Всі класи повинні бути осмислені в прикладній області; класів, пов'язаних з комп'ютерною реалізацією, як, наприклад, список, стек і т.п. цьому етапі вводити годі було.
Почнемо з виділення можливих класів із письмової постановки прикладного завдання. При визначенні можливих класів потрібно постаратися виділити якнайбільше класів, виписуючи ім'я кожного класу, що спадає на думку. Зокрема, кожному іменнику, який зустрічається у попередній постановці завдання, може відповідати клас. Тому при виділенні можливих класів кожному такому іменнику зазвичай зіставляється можливий клас.
В результаті одержуємо наступний список можливих імен класів:
Інший proxy;
документ;
Видалений Web сервер;
Конфігурація;
Інформація про документ;
Інформація про віддалений Web сервер;
Заголовок запиту;
Заголовок відповіді.
Прикладна система є безлічі взаємозалежних об'єктів. Кожен об'єкт характеризується набором властивостей, значення яких визначають стан об'єкта, та набором операцій, які можна застосувати до цього об'єкта.
При створенні прикладних систем зручно вважати, що це властивості об'єктів є закритими (тобто. вони недоступні поза об'єктом). Операції об'єктів може бути як відкритими, і закритими.
Отже, кожен об'єкт має певний інтерфейс, тобто. набір відкритих операцій, які можна застосовувати для цього об'єкта. Усі об'єкти одного класу мають однаковий інтерфейс.
Об'єктна модель представляє статистичну структуру проектованої системи (підсистеми). Однак знання статичної структури недостатньо, щоб зрозуміти та оцінити роботу підсистеми. Необхідно мати засоби для опису змін, що відбуваються з об'єктами та їх зв'язками під час роботи підсистеми.
Одним із таких засобів є динамічна модель підсистеми. Вона будується після того, як об'єктна модель підсистеми побудована та попередньо узгоджена та налагоджена. Динамічна модель підсистеми складається із діаграм станів її об'єктів підсистем.
Поточний стан об'єкта характеризується сукупністю поточних значень його атрибутів та зв'язків. Під час роботи системи складові її об'єкти взаємодіють один з одним, внаслідок чого змінюються їхні стани. Одиницею впливу є подія: кожна подія призводить до зміни стану одного чи кількох об'єктів у системі, або виникнення нових подій. Робота системи характеризується послідовністю подій, що відбуваються в ній.
Подія відбувається у певний момент часу. Приклади подій: старт ракети, старт забігу на 100 м, початок проведення, видача грошей тощо. Подія не має тривалості (точніше, вона займає дуже малий час).
Якщо події не мають причинного зв'язку (тобто вони логічно незалежні), вони називаються незалежними(Concurrent). Такі події не впливають одна на одну. Незалежні події немає сенсу впорядковувати, оскільки можуть відбуватися у довільному порядку. Модель розподіленої системи обов'язково має містити незалежні події та активності.
Послідовність подій називається сценарієм. Після розробки та аналізу сценаріїв визначаються об'єкти, що генерують та приймають кожну подію сценарію.
У разі події відбувається як перехід об'єкта у новий стан, а й виконується дія, що з цією подією. Дія називається миттєва операція, пов'язана з подією.
Процес побудови об'єктної моделі включає такі етапи:
Визначення об'єктів та класів;
Підготовка словника даних:
Визначення залежностей між об'єктами;
Визначення властивостей об'єктів та зв'язків;
Організація та спрощення класів при використанні успадкування;
Подальше дослідження та вдосконалення моделі.
Залежність між класами (об'єктами)
З кожним об'єктом пов'язана структура даних, полями якої є атрибути цього об'єкта та покажчики функцій (фрагментів коду), що реалізують операції цього об'єкта (зазначимо, що покажчики функцій у результаті оптимізації коду зазвичай замінюються на звернення до цих функцій). Таким чином, об'єкт – це деяка структура даних, тип якої відповідає класу цього об'єкта.
Між об'єктами можна встановлювати залежностіза даними. Ці залежностівисловлюють зв'язкуабо відносиниміж класами вказаних об'єктів. Приклади таких залежностей зображені малюнку 2.6 (перші дві залежності - бінарні, третя залежність - тренарна). Залежність зображується лінією, що з'єднує класи над якою надписане ім'я цієї залежності, або вказані ролі об'єктів (класів) у цій залежності (вказівка ролей - найзручніший спосіб ідентифікації залежності).
Мал. 2.6. Залежність між класами
Залежність між класами є двосторонніми: всі класи залежно рівноправні. Це навіть у випадках, коли ім'я залежності хіба що вносить напрям у цю залежність. Так, у першому прикладі малюнку 2.6 ім'я залежності має_столицу передбачає, що залежність спрямовано від класу країна до класу місто (двосторонність залежності начебто зникла); але слід пам'ятати, що це залежність двостороння у тому сенсі, що водночас із нею є і зворотна залежність є_столицей. Так само, у другому прикладі малюнку 2.6 можна розглядати пару залежностей володіє-належит. Подібних непорозумінь можна уникнути, якщо ідентифікувати залежності не за іменами, а за найменуванням ролей класів, що становлять залежність.
У мовах програмування залежності між класами (об'єктами) зазвичай реалізуються за допомогою посилань (покажчиків) з одного класу (об'єкта) на інший. Уявлення залежностей з допомогою посилань виявляє те що, що залежність є властивістю пари класів, а чи не якогось однієї з них, тобто. залежність – це ставлення. Зазначимо, що хоча залежності між об'єктами двоспрямовані, їх не обов'язково реалізувати в програмах як двоспрямовані, залишаючи посилання лише в тих класах, де це необхідно для програми.
Подальші приклади залежностей між класами наведено малюнку 2.7. Перший приклад показує залежність між клієнтом банку та його рахунками. Клієнт банку може мати одночасно кілька рахунків у цьому банку, або зовсім не мати рахунки (коли він вперше стає клієнтом банку). Таким чином, потрібно зобразити залежність між клієнтом та кількома рахунками, що й зроблено на малюнку 2.7. Другий приклад показує залежність між кривими (зокрема, прямими) лініями, що перетинаються. Можна розглядати 2, 3 і більше таких ліній, причому вони можуть мати кілька точок перетину. Нарешті, третій приклад показує необов'язкову (optional) залежність: комп'ютер може мати, і може мати миша.
Залежно між класами відповідають залежності між об'єктами цих класів. На малюнку 2.8 показано залежність між об'єктами для першого прикладу малюнка 2.6; на малюнку 2.9 показані залежності між об'єктами для прикладів, зображених малюнку 2.7.
Мал. 2.7. Подальші приклади залежностей. Позначення
Мал. 2.8. Залежність між об'єктами
Зазначимо, що при зображенні залежностей між об'єктами ми, як правило, знаємо кількість об'єктів і не потребуємо таких позначень як "кілька", "два і більше", "не обов'язково".
Під час проектування системи зручніше оперувати не об'єктами, а класами.
Мал. 2.9. Більш складні залежності між об'єктами
Поняття залежності перенесено до об'єктно-орієнтованої технології проектування програмних систем з технології проектування (і моделювання) баз даних, де залежності використовуються з давніх-давен. Мови програмування, зазвичай, не підтримують явного описи залежностей. Проте опис залежностей дуже корисно розробки програмних систем. Технологія OMT використовує залежності під час інтерпретації діаграм, що описують систему.
Тепер ми маємо всі необхідні поняття, щоб описати процес побудови об'єктної моделі. Цей процес включає наступні етапи:
- визначення об'єктів та класів;
- підготовка словника даних;
- визначення залежностей між об'єктами;
- визначення атрибутів об'єктів та зв'язків;
- організація та спрощення класів при використанні наслідування;
- подальше дослідження та удосконалення моделі.
Надіслати свою гарну роботу до бази знань просто. Використовуйте форму нижче
Студенти, аспіранти, молоді вчені, які використовують базу знань у своєму навчанні та роботі, будуть вам дуже вдячні.
Розміщено на http://www.allbest.ru/
ВСТУП
1.1 Основні теоретичні положення об'єктно-орієнтованої технології програмування; Основні поняття об'єктно-орієнтованого підходу
1.2 Поняття об'єкт
2. побудова об'єктної моделі предметної галузі «організація процесів спортивного клубу» із застосуванням мови моделювання uml
2.1 Характеристика мови моделювання UML
2.1.1 Коротка історія UML
2.1.2 Мова UML
2.1.3 Словник UML
2.1.4 Подання керування моделлю.
3.1 Опис структури програми
ВИСНОВОК
СПИСОК ДЖЕРЕЛ
Додаток А
ВСТУП
Спортивний клуб здійснює всебічну діяльність з розвитку фізичної культури та спорту серед молоді та членів їх сімей. З'являється все більше спортивних клубів, що включають у себе безліч спортивних секцій. Процес обліку молоді, що займаються в цих секціях, займає багато часу і є складним процесом. Тому все більш актуальним стає питання автоматизації цього процесу.
При використанні ЕОМ цей процес стає набагато більш точним і швидким, позбавленим безлічі накладок, які виникають при організації вручну.
Особливості організації процесів спортивного клубу виявляються за допомогою об'єктної моделі предметної сфери. Подібні моделі особливо корисні для організації процесу обліку молоді, що займається у секціях спортивного клубу, оскільки моделювання цієї предметної області дає можливість розглянути об'єкт з усіх боків і завдяки цьому передбачити всі можливі проблеми. Наприклад, при складанні розкладу об'єктна модель організації навчального процесу дозволяє уникнути накладок, що виникають при розподілі годинника для секцій, так як цей момент буде передбачений при розробці.
Об'єктну модель предметної області можна побудувати за допомогою візуальної об'єктної мови моделювання UML або у вигляді програмного продукту деякою мовою програмування, що підтримує об'єктну технологію програмування, прикладом якої є мова Object Pascal.
Метою даного дослідження є вивчення об'єктно-орієнтованої методології та технології програмування на прикладі мови Object Pascal, методів та інструментів побудови об'єктних моделей предметних областей, застосування отриманих знань для побудови об'єктної моделі предметної області «Організація роботи спортивного клубу».
Для досягнення мети даного дослідження поставлено такі завдання:
· Вивчити основні теоретичні положення об'єктно-орієнтованої методології;
· Розглянути мову UML та побудувати об'єктну модель предметної області із застосуванням даної мови;
· Розробити додаток, який використовує набір класів для представлення інформації про спортсменів.
Об'єктом дослідження цієї курсової є об'єктно-орієнтована методологія проектування.
Предметом дослідження цього дослідження є об'єктна модель предметної області «Організація роботи спортивного клубу» та її основні властивості.
Гіпотеза дослідження - реалізація об'єктної моделі у візуальному середовищі розробки Delphi, із застосуванням основних положень об'єктно-орієнтованої методології, дозволить спростити процес збирання, зберігання та обробки інформації про учасників спортивного клубу.
На етапі аналізу предметної області та проектування структури програми необхідно побудувати UML діаграму класів.
У процесі написання курсового проекту використовувалися такі методи дослідження:
· Описовий метод застосовується при викладі теоретичних аспектів проблеми та короткої характеристиці об'єкта дослідження;
· Метод порівняння та аналізу. Дозволяє зіставляти різні погляди на тему і провести діагностику об'єкта дослідження;
· Системний підхід. Був використаний з метою узагальнення отриманих результатів та виявлення їхнього логічного взаємозв'язку.
1. ОСНОВНІ ТЕОРЕТИЧНІ ПОЛОЖЕННЯ ОБ'ЄКТНО-ОРІЄНТУВАНОЇ МЕТОДОЛОГІЇ
1.1 Основні поняття об'єктно-орієнтованого підходу
предметна мова програмування модель
З давніх-давен у програмуванні використовувалася структурована процедурно-орієнтована модель. Вибір цілей проекту здійснюється одним із двох підходів, званих «зверху вниз» і відповідно «знизу вгору»
1. Підхід «згори донизу» має на увазі, що завдання розбивається на підзавдання, ті в свою чергу, на підзавдання наступного рівня і т.д. Цей процес званий декомпозицією триває до того часу, поки спрощення подзадач не зводиться до елементарним функцій, які можуть бути формалізовані.
2. Підхід «знизу вгору» має на увазі, що пишуться процедури для вирішення простих завдань, потім вони послідовно об'єднуються в складніші процедури доки не досягається потрібний ефект.
Важливими поняттями програмування є процедурно-орієнтоване програмування та об'єктно-орієнтоване програмування.
Процедурно-орієнтоване програмування - програмування імперативною мовою, при якому послідовно виконувані оператори можна зібрати в підпрограми, тобто більші цілісні одиниці коду, за допомогою механізмів самої мови.
Об'єктно-орієнтоване програмування (ООП) - це стиль програмування, який фіксує поведінка реального світу у такий спосіб, у якому деталі його реалізації приховані.
Об'єкт - це окрема сутність, що виділяється серед інших сутностей своїми властивостями, поведінкою, взаємодією з іншими об'єктами докладання.
Застосування такої технології дозволяє представити структуру програми у вигляді безлічі об'єктів, що взаємодіють один з одним. Внаслідок такої взаємодії, що здійснюється шляхом передачі повідомлень між об'єктами, реалізуються задані функції програми. Прийнявши повідомлення, об'єкт може виконати певну дію, яка називається методом.
Між ОВП та процедурно-орієнтованим програмуванням існують дві важливі відмінності:
1. В ООП програміст спочатку виділяє класи з опису предметної області, потім будується об'єктна модель розв'язання задачі і лише після цього переходить до аналізу їх методів та властивостей.
2. Методи та властивості асоціюються з класом, призначеним для виконання відповідних операцій.
Якщо проаналізувати, яким чином людина вирішує різноманітні практичні завдання в навколишньому світі, то можна зрозуміти, що цей світ також є об'єктно-орієнтованим. Наприклад, щоб потрапити на роботу, людина зазвичай взаємодіє з таким об'єктом, як транспортний засіб. p align="justify"> Транспортний засіб, у свою чергу, складається з об'єктів, які, взаємодіючи один з одним, наводять його в рух, завдяки чому людина реалізує своє завдання - добирається до потрібного пункту. При цьому ні водій, ні пасажир не повинні знати яким чином взаємодіють об'єкти, з яких складається транспортний засіб.
В об'єктно-орієнтованому програмуванні, як і реальному світі, користувачі програм ізольовані від логічної схеми, яка потрібна на виконання завдань. Наприклад, для друку сторінки в текстовому редакторі користувач викликає певну функцію натисканням кнопки на панелі інструментів, але не бачить внутрішніх процесів, що при цьому відбуваються. Під час друку сторінки під час роботи програми відбувається складна взаємодія об'єктів, які, своєю чергою, взаємодіють із принтером.
p align="justify"> При створенні об'єктно-орієнтованої програми предметна область представляється у вигляді сукупності об'єктів, які об'єднані в класи. Виконання програми у тому, що об'єкти обмінюються повідомленнями (взаємодіють між собою). При поданні реального об'єкта, що належить предметної області за допомогою програмного класу, необхідно виділити в реальному об'єкті його суттєві особливості та проігнорувати багато інших властивостей, обмежуючись лише тими, які необхідні для вирішення практичного завдання. Такий прийом називається абстракцією.
Абстракція - це виділення суттєвих характеристик об'єкта, що відрізняють його від інших об'єктів. Причому список істотних властивостей залежить від цілей моделювання, й у різних завдань то, можливо абсолютно різним. Наприклад, об'єкт «щур» з погляду біолога, який вивчає міграції, ветеринара, або кухаря матиме зовсім різні характеристики.
Клас - це сукупність об'єктів, що мають загальні властивості та поведінку. Таким чином, клас можна визначити як певну спільність конкретних об'єктів, як опис – якими вони мають бути і що вони мають робити. Якщо об'єкти реально існують у додатках, то клас - це абстракція, що об'єднує об'єкти в одну групу відповідно до їх властивостей та поведінки у середовищі оточення, в якому вони існують та взаємодіють. Наприклад, кнопка Button1 у формі з усіма своїми конкретними властивостями та дією є об'єктом класу Button.
Поведінка - характеристика того, як один об'єкт впливає на інші об'єкти або змінюється сам під їх впливом. Поведінка впливає спосіб зміни станів об'єкта.
В основі об'єктно-орієнтованої технології програмування лежать «три кити»: інкапсуляція, успадкування та поліморфізм.
Інкапсуляція (encapsulation) - властивість поєднувати всередині однієї структури стан і поведінку, та приховування внутрішнього пристрою об'єкта та деталей реалізації (від слова "капсула"). Важлива властивість будь-якого об'єкта – його відокремленість. Деталі реалізації об'єкта, тобто. внутрішні структури даних та алгоритми їх обробки приховані від користувача об'єкта і недоступні для ненавмисних змін. Об'єкт використовується через інтерфейс – сукупність правил доступу. Наприклад, для того, щоб переключити телевізійну програму, нам достатньо на пульті дистанційного керування набрати її номер, що запустить складний механізм, який зрештою і приведе до бажаного результату. Нам зовсім необов'язково знати, що відбувається в пульті дистанційного керування та телевізорі, нам лише достатньо знати, що телевізор має таку можливість (метод) і як її можна активувати. Інкапсуляція, або приховування реалізації, є основною властивістю ООП. Вона дозволяє створювати об'єкти користувача, що володіють необхідними методами, і далі оперувати ними, не вдаючись у пристрій цих об'єктів. Таким чином, інкапсуляція - механізм, який поєднує дані та методи обробки (маніпуляції) цими даними та захищає і те, й інше від зовнішнього втручання або неправильного використання. Інкапсуляція коду всередині класу забезпечує неможливість «зламати» цей код за будь-якої зміни деталей реалізації окремих класів. Тому можна використовувати об'єкт в іншому оточенні, і бути впевненим, що він не зіпсує області пам'яті, що не належать йому. Якщо ж треба щось змінити чи доповнити у класі, то використовуються механізми успадкування і поліморфізму.
Спадкування (inheritance) - заснована на ієрархії здатність класів включати в себе властивості та поведінку класів-предків, а також додавати до них свою власну поведінку та властивості. Щороку у світі пишеться безліч програм і важливо використовувати вже написаний код. Перевага об'єктно-орієнтованого програмування у тому, що з об'єкта можна визначити спадкоємців, корегують чи доповнюють його поведінка. При цьому немає потреби не тільки повторювати вихідний код батьківського об'єкта, але навіть мати доступ до нього. У такий спосіб спрощується модифікація програми та створення нових програм на основі існуючої. Тільки завдяки спадкуванню можна використовувати об'єкти, вихідний код яких недоступний, але які потрібно внести зміни. Таким чином, при наслідуванні можна не просто додавати новий функціонал, а й змінити існуючий. І багато в чому це забезпечується завдяки поліморфізму.
Поліморфізм (polymorphism) («багато форм») - можливість використовувати однакові висловлювання для позначення різних операцій, можливість класів-спадкоємців по-різному реалізовувати метод, описаний для предка класу, тобто. можливість під час виконання програми за допомогою того самого імені виконувати різні дії або звертатися до об'єктів різного типу. Поліморфізм реалізується через перевизначення методу у класах-спадкоємцях (метод має одне ім'я та однакові параметри, але працює по-різному) – це механізм віртуальних методів через динамічне зв'язування (dynamic binding). Також поліморфізм реалізується як «перевантаження» методів (метод має одне ім'я та різні параметри) - це, наприклад, використання знака + для позначення складання в класі дійсних чи цілих чисел та класі рядків: схожі повідомлення дають зовсім різні результати. Поліморфізм забезпечує можливість абстрагування загальних властивостей.
Модульність - це властивість системи, що була розкладена на внутрішньо зв'язкові, але слабко пов'язані між собою модулі.
У процесі поділу системи на модулі можуть бути корисними два правила. По-перше, оскільки модулі служать як елементарні і неподільні блоки програми, які можуть використовуватися в системі повторно, розподіл класів і об'єктів по модулях має враховувати це. По-друге, багато компіляторів створюють окремий сегмент коду для кожного модуля. Тому можуть з'явитися обмеження розміру модуля. Динаміка викликів підпрограм та розташування описів усередині модулів може сильно вплинути на локальність посилань та керування сторінками віртуальної пам'яті. При поганому розбиття процедур по модулях частішають взаємні виклики між сегментами, що призводить до втрати ефективності кеш-пам'яті та частої зміни сторінок.
Звести докупи такі суперечливі вимоги досить складно, але головне - це усвідомити, що вичленування класів та об'єктів у проекті та організація модульної структури є незалежними діями. Процес розподілу класів та об'єктів становить частину процесу логічного проектування системи, а розподіл на модулі – етап фізичного проектування. Зрозуміло, що іноді неможливо завершити логічне проектування системи, не завершивши фізичне проектування, і навпаки. Два ці процеси виконуються ітеративно.
Типізація - це спосіб захиститися від використання об'єктів одного класу замість іншого або принаймні керувати таким використанням.
Паралелізм – це властивість, що відрізняє активні об'єкти від пасивних.
Збереженість - здатність об'єкта існувати в часі, переживаючи процес, що його породив, і (або) в просторі, переміщаючись зі свого початкового адресного простору.
У програмування основні поняття ОВП перейшли з інших галузей знань, таких як філософія, логіка, математика та семіотика, причому, не зазнавши особливих змін, принаймні того, що стосується суті цих понять. Об'єктний спосіб декомпозиції (подання) є природним і застосовується протягом багатьох століть. Тому не дивно, що в процесі еволюції технології програмування він зайняв належне місце.
Таким чином, у процесі розробки об'єктно-орієнтованих програм необхідно:
1. визначити безліч які утворюють її класів об'єктів (декомпозиція);
2. кожному за класу об'єктів задати набір необхідних даних (полів);
3. кожному за класу об'єктів задати набір дій (методів), виконуваних об'єктами;
4. для кожного класу об'єктів вказати події, на які будуть реагувати об'єкти, та написати відповідні процедури-обробники.
У вихідному програмному коді повинні бути описані класи для всіх програмних об'єктів. Крім того, повинні бути описані змінні, у яких як типи вказані імена відповідних класів. Примірники класів (об'єкти) створюються у процесі виконання програми.
Після створення екземпляр класу повинен отримати значення для всіх своїх полів. Різні екземпляри одного і того ж класу можуть мати різні значення полів, але мають ті самі методи. Поля класу недоступні безпосереднього звернення, зокрема, і присвоювання. Це зроблено підвищення надійності програм. Замість безпосереднього привласнення значення полю об'єкта має бути виконано звернення до спеціального методу відповідного класу, який виконує таке надання і здійснює контроль коректності значення, що вводиться. Аналогічним чином, для прочитання значення поля можуть використовуватися спеціальні методи класу. Для зв'язку полів із методами читання/запису їх значень використовуються члени класу, які називаються властивостями. Користувач, вводячи дані для запису в полях об'єкта або зчитуючи значення полів, має справу з властивостями, що представляють ці поля. Тому зазвичай використовують термін «значення властивостей» замість терміна «значення полів».
Членами класу можуть бути:
1. поля, що використовуються для зберігання даних;
2. якості, як засобу звернення до закритих полів;
3. способи, що задають функціональність об'єктів;
4. події та їх обробники, як засоби управління програмами.
1.2 Поняття об'єкт
Об'єктно-орієнтований підхід у програмуванні пропонує все, що входить до складу програми, вважати об'єктами, які взаємодіють один з одним та з користувачем відповідно до заданих у програмі властивостей та поведінки, виконуючи необхідні функції програми. Таким чином, будь-який додаток при цьому підході є набір взаємопов'язаних об'єктів, що реалізують необхідні функціональні вимоги, пред'явлені до додатку.
Об'єкт завжди конкретний і реально існує у формі або додатку, володіючи при цьому тільки йому властивими властивостями і поведінкою. Ознаками об'єктів, що відрізняють їх один від одного, є їх властивості та поведінка. У реальному світі кожен предмет або процес має набір статичних і динамічних характеристик (властивостей і поведінки). Поведінка об'єкта залежить від його стану та зовнішніх впливів. Наприклад, об'єкт "автомобіль" нікуди не поїде, якщо в баку немає бензину, а якщо повернути кермо, зміниться положення коліс. Таким чином, об'єкт представляється як сукупність даних, що характеризують його стан, та методів (процедур та функцій) їх обробки, що моделюють його поведінку. Виклик процедури або функції виконання часто називають посилкою повідомлення об'єкту (наприклад, виклик процедури «повернути кермо» часто інтерпретується як посилка повідомлення «автомобіль, поверни кермо!»). Таким чином, кожен об'єкт характеризується такими основними поняттями:
1. методом - це функція чи процедура, що реалізує можливі з об'єктом дії;
2. подією - це взаємодії об'єктів друг з одним. Об'єкти генерують задані події та виконують дії у відповідь на задані події. Події - це аналог повідомлень, які отримують та надсилають об'єкти;
3. станом - кожен об'єкт завжди перебуває у певному стані, що характеризується набором властивостей об'єкта. Під впливом подій об'єкт перетворюється на інші стану. При цьому об'єкт може сам генерувати події під час переходу в інший стан;
4. властивістю – ознака, деяка окрема якість (параметр) об'єкта.
Наприклад, властивостями можуть бути розміри об'єкта, заголовок, його найменування. Сукупність властивостей об'єкта визначає його стан. Як правило, властивості - це набір змінних та констант, у яких зберігаються значення, що визначають параметри об'єкта.
Необхідно звернути увагу, що поряд з фізичними можуть існувати також абстрактні об'єкти, типовими представниками яких є числа. Таким чином, об'єкт - це будь-яка фізична або абстрактна сутність предметної області, що чітко ідентифікується.
Об'єкти характеризуються атрибутами. Приміром, атрибутами автомобіля є максимальна швидкість, потужність двигуна, колір кузова тощо. буд. Атрибутами підсилювача є частотний діапазон, вихідна потужність, коефіцієнт нелінійних спотворень, рівень шуму тощо.
Крім атрибутів, об'єкти мають деякі функціональні можливості, які в ООП називають операціями, функціями або методами. Так, автомобіль може їздити, корабель – плавати, комп'ютер – проводити обчислення.
Таким чином, об'єкт інкапсулює атрибути та методи, приховуючи свою реалізацію від інших об'єктів, що взаємодіють з ним та використовують його функціональність.
Об'єктно-орієнтований підхід ґрунтується на систематичному використанні моделей для мовно-незалежної розробки програмної системи, на основі її прагматики.
Останній термін потребує пояснення. Прагматика визначається метою розробки програмної системи: обслуговування клієнтів банку, управління роботою аеропорту, обслуговування чемпіонату світу з футболу тощо. У формулюванні мети беруть участь предмети та поняття реального світу, що мають відношення до програмної системи, що розробляється (див. малюнок 1.2.1).
p align="justify"> При об'єктно-орієнтованому підході ці предмети і поняття замінюються їх моделями, тобто. певними формальними конструкціями, які представляють їх у програмній системі.
Рис.1.2.1 Семантика.
Модель містить не всі ознаки і властивості предмета (поняття), що представляється нею, а тільки ті, які істотні для розроблюваної програмної системи. Тим самим модель "бідніша", а, отже, простіше представляється нею предмета (поняття). Але головне навіть не в цьому, а в тому, що модель є формальною конструкцією: формальний характер моделей дозволяє визначити формальні залежності між ними і формальні операції над ними. Це спрощує як розробку та вивчення (аналіз) моделей, так і їх реалізацію на комп'ютері. Зокрема, формальний характер моделей дозволяє отримати формальну модель програмної системи, що розробляється, як композицію формальних моделей її компонентів.
Таким чином, об'єктно-орієнтований підхід допомагає впоратися з такими складними проблемами, як
· Зменшення складності програмного забезпечення;
· Підвищення надійності програмного забезпечення;
· Забезпечення можливості модифікації окремих компонентів програмного забезпечення без зміни інших його компонентів;
· Забезпечення можливості повторного використання окремих компонентів програмного забезпечення.
Систематичне застосування об'єктно-орієнтованого підходу дозволяє розробляти добре структуровані, надійні в експлуатації, програмні системи, що досить просто модифікуються. Цим пояснюється інтерес програмістів до об'єктно-орієнтованого підходу та об'єктно-орієнтованих мов програмування. Об'єктно-орієнтований підхід є одним з найбільш інтенсивних напрямків теоретичного та прикладного програмування.
1.3 Засоби реалізації об'єктно-орієнтованої технології програмування
У технології ООП взаємовідносини даних та алгоритму мають більш регулярний характер: по-перше, клас (базове поняття цієї технології) поєднує в собі дані (структурована змінна) та методи (функції). По-друге, схема взаємодії функцій та даних принципово інша. Метод (функція), що викликається одного об'єкта, зазвичай, не викликає іншу функцію безпосередньо. Для початку він повинен мати доступ до іншого об'єкта (створити, отримати покажчик, використовувати внутрішній об'єкт у поточному і т.д.), після чого він може викликати для нього один з відомих методів. Отже, структура програми визначається взаємодією об'єктів різних класів між собою. Як правило, має місце ієрархія класів, а технологія ООП інакше може бути названа як програмування від класу до класу.
Будь-яке програмування здійснюється за одним із чотирьох принципів:
· Принцип модульності
· Принцип «від загального до приватного»
· принцип покроковості
· Принцип структурування
Модульне програмування. Принцип модульності формулюється як вимога розробки програми як сукупності модулів (функцій). При цьому поділ на модулі повинен мати не механічний характер, а виходити з логіки програми:
1. розмір модуля має бути обмежений;
2. модуль повинен виконувати логічно цілісну та завершену дію;
3. модуль повинен бути універсальним, тобто по можливості параметризованим: всі характеристики, що змінюються виконуваної дії повинні передаватися через параметри;
4. вхідні параметри та результат модуля бажано передавати не через глобальні змінні, а через формальні параметри та результат функції.
Ще однією, але вже фізичною одиницею програми є текстовий файл, що містить кілька функцій та визначень типів даних і змінних. Модульне програмування лише на рівні файлів - це можливість розділити повний текст програми кілька файлів. Принцип модульності поширюється як на програми, а й у дані: будь-який набір параметрів, характеризуючих логічний чи фізичний об'єкт, може бути представлений у програмі як єдиної структури даних (структурованої змінної).
Уособленням принципу модульності є бібліотека стандартних функцій. Вона зазвичай забезпечує повний набір параметризованих дій, використовуючи загальні структури даних. Бібліотеки є аналогічними програмами, незалежно відтрансльованими і поміщеними в каталог бібліотек.
Спадне програмування. Східне проектування програми полягає в тому, що розробка йде від загального неформального формулювання деякої дії програми природною мовою, "від загальної до приватної": до заміни її однією з трьох формальних конструкцій мови програмування:
· Простій послідовності дій;
· Конструкції вибору або оператора if;
· Конструкції повторення або циклу.
У записі алгоритму це відповідає руху від зовнішньої (осяжної) конструкції до внутрішньої (вкладеної). Ці конструкції також можуть містити у своїх частинах неформальний опис дій, тобто низхідне проектування за своєю природою є покроковим. Зазначимо основні властивості такого підходу:
· Спочатку програма формулюється у вигляді деякого неформального впливу природною мовою;
· Спочатку визначаються вхідні параметри та результат дії;
· Ще один крок деталізації не змінює структуру програми, отриману на попередніх кроках;
· якщо в процесі проектування виходять ідентичні дії в різних гілках, це означає необхідність оформлення цієї дії окремою функцією;
· Необхідні структури даних проектуються одночасно з деталізацією програми.
Покрокове програмування. Східне проектування за своєю природою є покроковим, бо передбачає щоразу заміну однієї словесної формулювання на єдину конструкцію мови. Але в процесі розробки програми можуть бути й інші кроки, пов'язані з деталізацією самої словесної формулювання докладніше.
Те, що цей принцип виділено окремо, говорить про необхідність запобігти спокусі деталізації програми відразу від початку до кінця та розвивати вміння виділяти та зосереджувати увагу на головних, а не другорядних деталях алгоритму.
Взагалі, низхідне покрокове проектування програми не дає гарантії отримання "правильної" програми, але дозволяє повернутися при виявленні тупикової ситуації до одного з верхніх кроків деталізації.
Структурне програмування. При низхідній покроковій деталізації програми необхідні роботи структури даних і змінні з'являються у міру переходу від неформальних визначень до конструкцій мови, тобто процеси деталізації алгоритму даних йдуть паралельно. Однак це стосується насамперед окремих локальних змінних та внутрішніх параметрів. З найзагальнішої погляду предмет (у разі - дані) завжди первинний стосовно виконуваним із нею діям (у разі - алгоритм). Тому насправді спосіб організації даних у програмі більш істотно впливає на її структуру алгоритму, ніж будь-що інше, і проектування структур даних повинен випереджати процес проектування алгоритму їх обробки.
Структурне програмування - модульне низхідне покрокове проектування алгоритму та структур даних.
Об'єктно-орієнтований підхід до програмування включає 3 основні компоненти:
· Об'єктно-орієнтований аналіз (ООА),
· Об'єктно-орієнтоване проектування (ООД),
· Об'єктно-орієнтоване програмування (ООП).
У будь-якій інженерній дисципліні під проектуванням зазвичай розуміється якийсь уніфікований підхід, за допомогою якого ми шукаємо шляхи вирішення певної проблеми, забезпечуючи виконання поставленого завдання. У контексті інженерного проектування мета проектування визначається як створення системи, яка
· Задовольняє заданим (можливо, неформальним) функціональним специфікаціям;
· Узгоджена з обмеженнями, що накладаються обладнанням;
· Задовольняє явним і неявним вимогам щодо експлуатаційних якостей та споживання ресурсів;
· Задовольняє явним та неявним критеріям дизайну продукту;
· Задовольняє вимогам до процесу розробки, таким, наприклад, як тривалість і вартість, а також залучення додаткових інструментальних засобів.
Проектування передбачає врахування суперечливих вимог. Його продуктами є моделі, які дозволяють зрозуміти структуру майбутньої системи, збалансувати вимоги і намітити схему реалізації.
Програма - це цифрова модель проектованої системи. (рис. 1.3.1.)
Мал. 1.3.1. Структура програми.
Важливість побудови моделі. Моделювання широко поширене у всіх інженерних дисциплінах, значною мірою через те, що воно реалізує принципи декомпозиції, абстракції та ієрархії. Кожна модель описує певну частину аналізованої системи, а ми будуємо нові моделі з урахуванням старих, у яких більш-менш впевнені. Моделі дозволяють нам контролювати наші невдачі. Ми оцінюємо поведінку кожної моделі у звичайних та незвичайних ситуаціях, а потім проводимо відповідні доопрацювання, якщо нас щось не задовольняє.
Елементи програмного проектування Зрозуміло, що не існує такого універсального методу, який провів би інженера-програміста на шляху від вимог до складної програмної системи до їх виконання. Проектування складної програмної системи не зводиться до сліпого дотримання певного набору рецептів. Скоріше це поступовий та ітеративний процес. І, тим щонайменше, використання методології проектування вносить у процес розробки певну організованість. Інженери-програмісти розробили десятки різних методів, які ми можемо класифікувати за трьома категоріями. Незважаючи на відмінності, ці методи мають щось спільне. Їх, зокрема, об'єднує таке:
· Умовні позначення - мова для опису кожної моделі;
· Процес - правила проектування моделі;
· Інструменти - засоби, які прискорюють процес створення моделей, і в яких вже втілені закони функціонування моделей. Інструменти допомагають виявляти помилки у процесі розробки.
Хороший метод проектування базується на міцній теоретичній основі і при цьому дає програмісту певний ступінь свободи самовираження.
Об'єктно-орієнтовані моделі. Найкорисніше створювати такі моделі, які фокусують увагу на об'єктах, знайдених у предметній області, і утворюють те, що називається об'єктно-орієнтованою декомпозицією.
Об'єктно-орієнтований аналіз та проектування - це метод, що логічно призводить до об'єктно-орієнтованої декомпозиції. Застосовуючи об'єктно-орієнтоване проектування, створюються гнучкі програми, написані економними засобами. При розумному поділі простору станів ми досягаємо більшої впевненості у правильності нашої програми. У результаті ми зменшуємо ризик розробки складних програмних систем.
Так як побудова моделей вкрай важлива при проектуванні складних систем, об'єктно-орієнтоване проектування пропонує багатий вибір моделей (представлені на рис. 1.3.2). Об'єктно-орієнтовані моделі проектування відображають ієрархію і класів, і об'єктів системи. Ці моделі покривають весь спектр найважливіших конструкторських рішень, які необхідно розглядати при розробці складної системи, і таким чином надихають нас на створення проектів, що мають усі п'ять атрибутів добре організованих складних систем.
Мал. 1.3.2 Об'єктно-орієнтовані моделі.
ООП - ідеологія програмування, заснована на об'єднанні даних та процедур, які можуть працювати з цими даними в сукупності, звані класами.
Сутью ООП є використання звичної у повсякденному житті об'єктної моделі. Кожен об'єкт має свої властивості і з ним можна зробити характерні для нього події. Клас – це тип об'єкта. Клас визначає і реалізує ті самі властивості та події. Об'єкт у нашому розумінні буде змінною, типом який і буде якийсь клас. Полями класу ми називатимемо його властивості, а методами - дії, які можна зробити з екземпляром цього класу (об'єктом).
Під прикладом реалізації класу розглянемо реалізацію поняття книги з використанням класу для того, щоб визначити уявлення книги TBook та безлічі функцій для роботи зі змінними цього типу:
PagesCount: integer;
функція CompareWithBook(OtherBook: TBook): integer;
procedure ShowTitle;
constructor Create(NewTitle, New
Пізнавальні здібності людини обмежені; ми можемо розсунути їх рамки, використовуючи декомпозицію, виділення абстракцій та створення ієрархій.
Складні системи можна досліджувати, концентруючи основну увагу або об'єктах, або процесах; є вагомі підстави використовувати об'єктно-орієнтовану декомпозицію, коли світ розглядається як упорядкована сукупність об'єктів, які у процесі взаємодії друг з одним визначають поведінка системи.
Об'єктно-орієнтований аналіз та проектування - метод, який використовує об'єктну декомпозицію; Об'єктно-орієнтований підхід має свою систему умовних позначень і пропонує багатий набір логічних і фізичних моделей, за допомогою яких ми можемо отримати уявлення про різні аспекти системи, що розглядається.
2. ПОБУДУВАННЯ ОБ'ЄКТНОЇ МОДЕЛІ ПРЕДМЕТНОЇ ОБЛАСТІ «ОРГАНІЗАЦІЯ ПРОЦЕСІВ СПОРТИВНОГО КЛУБУ» З ЗАСТОСУВАННЯМ МОВ МОДЕЛЮВАННЯ UML
2.1 Поняття мови UML
UML (Unified Modeling Language) – це уніфікована графічна мова моделювання для опису, візуалізації, проектування та документування об'єктно-орієнтованих систем. UML покликаний підтримувати процес моделювання програмних засобів на основі об'єктно-орієнтованого підходу, організовувати взаємозв'язок концептуальних та програмних понять, відображати проблеми масштабування складних систем. Моделі на UML використовуються на всіх етапах життєвого циклу програмних засобів, починаючи з бізнес-аналізу та закінчуючи супроводом системи. Різні організації можуть застосовувати UML на власний розсуд залежно від своїх проблемних областей і використовуваних технологій.
2.1.1 Коротка історія UML
До середини 90-х років різними авторами було запропоновано кілька десятків методів об'єктно-орієнтованого моделювання, кожен з яких використовував свою графічну нотацію. При цьому будь-який з цих методів мав свої сильні сторони, але не дозволяв побудувати досить повну модель програмних засобів, показати її «з усіх боків», тобто всі необхідні проекції. До того ж, відсутність стандарту об'єктно-орієнтованого моделювання ускладнювало для розробників вибір найбільш відповідного методу, що перешкоджало широкому поширенню об'єктно-орієнтованого підходу до розробки програмних засобів.
За запитом Object Management Group (OMG) - організації, відповідальної за прийняття стандартів у галузі об'єктних технологій та баз даних, назрілу проблему уніфікації та стандартизації було вирішено авторами трьох найбільш популярних об'єктно-орієнтованих методів - Г.Бучем, Д.Рамбо та А.Джекобсоном, які об'єднаними зусиллями створили версію UML 1.1, затверджену OMG у 1997 році як стандарт.
На хвилі зростання інтересу до UML до розробки нових версій мови в рамках консорціуму UML Partners приєдналися такі компанії, як Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software , Texas Instruments та Unisys. Результатом спільної роботи стала специфікація UML 1.0, що вийшла у січні 1997 року. У листопаді того ж року за нею була версія 1.1, що містила поліпшення нотації, а також деякі розширення семантики. UML 1.4.2 прийнятий як міжнародний стандарт ISO/IEC 19501:2005.
Формальну специфікацію останньої версії UML 2.0 опубліковано в серпні 2005 року. Семантика мови була значно уточнена та розширена для підтримки методології Model Driven Development – MDD. Остання версія UML 2.4.1 була опублікована в серпні 2011 року. UML 2.4.1 прийнятий як міжнародний стандарт ISO/IEC 19505-1, 19505-2.
2.1.2 Мова UML
Будь-яка мова складається зі словника та правил комбінування слів для отримання осмислених конструкцій. Так, зокрема, влаштовані мови програмування, такою є UML. Відмінною його особливістю є те, що словник мови утворюють графічні елементи. Кожному графічному символу відповідає конкретна семантика, тому модель, створена одним розробником, може бути однозначно зрозуміла іншим, а також програмним засобом, що інтерпретує UML. Звідси, зокрема, випливає, що модель ПС, представлена на UML, може автоматично бути переведена на ГО мову програмування (такі як Java, C++, VisualBasic), тобто, за наявності гарного інструментального засобу візуального моделювання, що підтримує UML, побудувавши модель , ми отримаємо і заготівлю програмного коду, що відповідає цій моделі.
Слід наголосити, що UML - це саме мова, а не метод. Він пояснює, з яких елементів створювати моделі та як їх читати, але нічого не говорить про те, які моделі та в яких випадках слід розробляти. Щоб створити метод з урахуванням UML, треба доповнити його описом процесу розробки ПС. Прикладом такого процесу є Rational Unified Process, який розглядатиметься у наступних статтях.
2.1.3 Словник UML
Модель представляється у вигляді сутностей та відносин між ними, що показуються на діаграмах.
Сутності – це абстракції, що є основними елементами моделей. Є чотири типи сутностей - структурні (клас, інтерфейс, компонент, варіант використання, кооперація, вузол), поведінкові (взаємодія, стан), що групують (пакети) та анотаційні (коментарі). Кожен вид сутностей має своє графічне уявлення. Сутності будуть детально розглянуті щодо діаграм.
Відносини показують різні зв'язки між сутностями. У UML визначено такі типи відносин:
· Залежність показує такий зв'язок між двома сутностями, коли зміна однієї з них – незалежної – може вплинути на семантику іншої – залежної. Залежність зображується пунктирною стрілкою, спрямованої від залежної сутності незалежної.
· Асоціація - це структурне відношення, що показує, що об'єкти однієї сутності пов'язані з об'єктами іншої. Графічно асоціація показується у вигляді лінії, що з'єднує сутності, що зв'язуються. Асоціації служать для навігації між об'єктами. Наприклад, асоціація між класами «Замовлення» та «Товар» може бути використана для знаходження всіх товарів, зазначених у конкретному замовленні – з одного боку, або для знаходження всіх замовлень у яких є даний товар – з іншого. Зрозуміло, що у відповідних програмах має бути реалізований механізм, що забезпечує таку навігацію. Якщо потрібна навігація лише в одному напрямку, воно показується стрілкою наприкінці асоціації. Приватним випадком асоціації є агрегування – відношення виду «ціле» – «частина». Графічно воно виділяється за допомогою ромбіка на кінці біля сутності цілого.
· Узагальнення - це відношення між сутністю-батьком і сутністю-нащадком. Фактично, це ставлення відбиває властивість успадкування для класів, і об'єктів. Узагальнення показується як лінії, що закінчується трикутником, спрямованим до батьківської сутності. Нащадок успадковує структуру (атрибути) і поведінку (методи) батька, але водночас може мати нові елементи структури і нові методи. UML допускає множинне успадкування, коли сутність пов'язана з більш ніж однією батьківською сутністю.
· Реалізація - відношення між сутністю, що визначає специфікацію поведінки (інтерфейс) з сутністю, що визначає реалізацію цієї поведінки (клас, компонент). Це ставлення зазвичай використовується при моделюванні компонентів і буде докладніше описано в наступних статтях.
діаграми. У UML передбачені такі діаграми:
· Діаграми, що описують поведінку системи:
· Діаграми станів (State diagrams),
· Діаграми діяльностей (Activity diagrams),
· Діаграми об'єктів (Object diagrams),
· Діаграми послідовностей (Sequence diagrams),
· Діаграми взаємодії (Collaboration diagrams);
· Діаграми, що описують фізичну реалізацію системи:
· діаграми компонент (Component diagrams);
· Діаграми розгортання (Deployment diagrams).
2.1.4 Структура керування моделлю
Для того, щоб модель була добре розуміється людиною, необхідно організувати її ієрархічно, залишаючи на кожному рівні ієрархії невелику кількість сутностей. UML включає засіб організації ієрархічного представлення моделі - пакети. Будь-яка модель складається з набору пакетів, які можуть містити класи, варіанти використання та інші сутності та діаграми. Пакет може містити інші пакети, що дозволяє створювати ієрархії. У UML не передбачено окремих діаграм пакетів, але вони можуть бути присутніми на інших діаграмах. Пакет зображується у вигляді прямокутника із закладкою.
UML забезпечує.
· Ієрархічний опис складної системи шляхом виділення пакетів;
· Формалізацію функціональних вимог до системи за допомогою апарату варіантів використання;
· Деталізацію вимог до системи шляхом побудови діаграм діяльностей та сценаріїв;
· Виділення класів даних і побудова концептуальної моделі даних у вигляді діаграм класів;
· Виділення класів, що описують інтерфейс користувача, і створення схеми навігації екранів;
· Опис процесів взаємодії об'єктів при виконанні системних функцій;
· Опис поведінки об'єктів у вигляді діаграм діяльностей та станів;
· Опис програмних компонент та їх взаємодії через інтерфейси;
· Опис фізичної архітектури системи.
Мова UML було б важко використовувати при реальному моделюванні програмних засобів без інструментальних засобів візуального моделювання. Такі засоби дозволяють оперативно представляти діаграми на екрані дисплея, документувати їх, генерувати заготівлі програмних кодів різними об'єктно-орієнтованими мовами програмування, створювати схеми баз даних. Більшість із них включають можливості реінжинірингу програмних кодів - відновлення певних проекцій моделі програмних засобів шляхом автоматичного аналізу вихідних кодів програм, що дуже важливо для забезпечення відповідності моделі та кодів та при проектуванні систем, що успадковують функціональність систем-попередників.
2.2 Опис функціонування предметної галузі «Організація роботи спортивного клубу»
Залежно від характеру зв'язків між підрозділами підприємства розрізняють такі типи організаційних структур: лінійну, функціональну, лінійно-функціональну та матричну.
У роботі цього спортивного клубу використовується лінійна структура управління.
Спортивний клуб вирішує такі завдання:
· Залучення молоді та членів їх сімей у систематичні заняття фізичною культурою та спортом;
· Виховання фізичних та морально-вольових якостей, зміцнення здоров'я та зниження захворюваності, підвищення рівня професійної готовності, соціальної активності молоді;
· Організація та проведення масових оздоровчих, фізкультурних та спортивних заходів;
· Створення спортивних аматорських об'єднань, клубів, секцій та команд за видами спорту;
· Пропаганда фізичної культури та спорту, здорового способу життя, організація змістовного дозвілля, залучення широких мас молоді до масових суспільно-політичних заходів
Спортивний клуб виконує такі функції:
· Здійснює впровадження фізичної культури та спорту в діяльність молоді, їх побут та відпочинок; пропагує здоровий спосіб життя, веде боротьбу з подолання шкідливих звичок;
· Створює необхідні організаційно-методичні умови для занять різними формами і видами фізичної культури і спорту відповідно до традицій, що склалися в країні;
· Впроваджує нові форми та методи фізичного виховання, передовий досвід та досягнення науки; раціонально та ефективно використовує матеріальну базу;
· всіляко розвиває суспільні засади у масовій фізкультурно-оздоровчій та спортивній роботі;
· Надає допомогу загальноосвітнім школам, коледжам в організації масової оздоровчої, фізкультурної та спортивної роботи;
· Організовує навчально-тренувальний процес у спортивних секціях (збірних командах);
· Розробляє та реалізує календарні плани масових оздоровчих, фізкультурних та спортивних заходів, забезпечує безпеку їх проведення;
· Забезпечує контроль за навчально-тренувальним процесом у секціях спортивного клубу з підготовки спортсменів вищої спортивної кваліфікації, сприяє створенню необхідних умов для зростання їх спортивної майстерності;
· Організовує спільно з органами охорони здоров'я медичний контроль над станом здоров'я які займаються фізичною культурою та спортом у секціях (збірних командах);
· Складає поточні та перспективні плани розвитку масової фізкультурно-оздоровчої та навчально-спортивної роботи, кошторису витрат клубу.
· У межах своєї компетентності здійснює підбір та розстановку фізкультурних кадрів;
· може мати прапор, емблему, спортивну форму, штамп, бланк;
· проводить масові змагання, спартакіади (універсіади), навчально-тренувальні збори;
· Відповідно до затвердженого порядку направляє команди та окремих спортсменів на змагання;
· Видає відповідні посвідчення (значки) членам збірних команд ВНЗ;
2.3 Побудова діаграми класів предметної галузі «Організація процесів спортивного клубу»
У спортивному клубі працюють чотири сеції на базі клубу:
· Баскетбол
· Волейбол
· Теніс.
При зверненні кандидатів-спортсменів до спортивного клубу з метою записатися до якоїсь секції здійснюється реєстрація, яка передбачає такі дії:
· Дані про спортсменів заносяться до таблиці із зазначенням 5 полів: Прізвище, Ім'я, Вік, Телефон, Секція.
· Спортсмени розподіляються за секціями, до яких подано заявку.
· Батькам спортсменів надається розклад секцій спортивного клубу.
Для організації коректної роботи клубу, узгодження роботи секцій, зайнятості тренерів адміністратор спортивного клубу заповнює розклад.
При вступі до клубу спортсмен заноситься до таблиці із зазначенням секції. Усі спортсмени, які займаються в клубі, повинні бути занесені до головної таблиці із зазначенням секції.
Для наочного представлення процесів роботи спортивного клубу було побудовано UML діаграму (Рис 2.3.1).
Мал. 2.3.1 Об'єктно-орієнтована модель спортивного клубу.
3. БУДІВНИЦТВО ОБ'ЄКТНОЇ МОДЕЛІ ПРЕДМЕТНОЇ ОБЛАСТІ «ОРГАНІЗАЦІЯ РОБОТИ СПОРТИВНОГО КЛУБУ» З ЗАСТОСУВАННЯМ ВІЗУАЛЬНОГО СЕРЕДОВИЩА ПРОГРАМУВАННЯ DELPHI
3.1 Опис структури програми
Ця програма входить до складу пакету Sport. Воно складається з класу: class TPeople.
Клас «TPeople» дозволяє створювати та накопичувати інформацію про дітей, які займаються в даному спортивному клубі, який отримав назву «Вогник». Він має п'ять полів: Ім'я задається рядком (string) "Name"; Прізвище задається рядком (string) "Famil"; Вік зберігається у числовій змінній (int) «Age»; телефон задається рядком (string) "Tel"; Секція в якій займається спортсмен задається рядком (string) "Sekc".
TPeople = class
Name: String;
Famil: String;
Age: Integer;
tel: String;
sekc: String;
constructor Create (AName: String);
end;
При цьому введення полів використовується двома способами:
Завантаження значення збереженого файлу з розширенням LST. (Рис 3.1.1.)
Метод організований за допомогою функції OpenDlg, при цьому кожен рядок класу зчитується як окреме значення.
var F: TextFile;
i: Integer;
begin
try
with OpenDlg, PersonsList.Items do
begin
if Not Execute then Exit;
LoadFromFile(FileName);
AssignFile(F, Copy(FileName,1,Length(FileName)-4)+".lso");
Reset(F);
i:= 0;
while Not EOF(F) do
begin
Objects[i] := TPeople.Create("");
Readln(F, (Objects[i] as TPeople).Name);
Readln(F, (Objects[i] as TPeople).Famil);
Readln(F, (Objects[i] as TPeople).Age);
Readln(F, (Objects[i] as TPeople).tel);
Readln(F, (Objects[i] as TPeople).sekc);
Inc(i);
end;
CloseFile(F);
end;
except
on E: EFOpenError do ShowMessage("Помилка відкриття файлу");
end; end;
Мал. 3.1.1 Завантаження файлу.
Другим способом заповнення таблиці є введення з допомогою компонентів Edit.(Рис. 3.1.2.)
Мал. 3.1.2 Заповнення таблиці за допомогою компонента Edit.
Причому значення поля «Секція» вибирається із значень компонента Combobox і надається рядку «Sekc». (Рис.3.1.3)
Мал. 3.1.3 Компонент Combobox.
Введені значення можуть коригуватися шляхом вибору потрібного значення та натискання кнопки «Змінити» (Мал. 3.1.4)
Мал. 3.1.4 Зміна значень.
У програмі передбачено видалення значення шляхом видалення одного запису (Мал. 3.1.5) та видалення всіх записів (Мал. 3.1.6).
Видалення одного запису здійснюється за допомогою вибору значення та натискання кнопки «Видалити».
Мал. 3.1.5 Видалення одного запису.
Для того, щоб очистити всі записи, потрібно натиснути кнопку «Очистити».
Мал. 3.1.6 Кнопка "Очистити".
Обидва способи видалення здійснені такими методами:
procedure TMainForm.ToolButton4Click(Sender: TObject);
begin
with PersonsList do Items.Delete(ItemIndex);
end;
procedure TMainForm.ToolButton5Click(Sender: TObject);
begin
PersonsList.Items.Clear;
end;
Після заповнення таблиці спортсменів виникає необхідність зберегти її для подальшого використання. Це здійснюється натисканням кнопки «Зберегти» (Мал. 3.1.7). Після натискання цієї кнопки здійснюється відкриття діалогового вікна, куди вказується папка зберігання файлу та його назва. (Мал. 3.1.8).
Подібні документи
Коротка характеристика предметної галузі. Актуальність розробки об'єктно-орієнтованої моделі інформаційної системи навчальної бібліотеки. Створення діаграми варіантів використання, послідовності, кооперативної діаграми, діаграми класів.
курсова робота , доданий 01.06.2009
Розробка об'єктно-орієнтованої підсистеми складського обліку для фірми "КавказЮгАвто". Коротка характеристика предметної галузі. Побудова діаграм розміщення, прецедентів, послідовності, компонентів та класів. Генерація програмного коду C++.
курсова робота , доданий 26.06.2011
Основні елементи об'єктної моделі. Сутність та переваги об'єктно-орієнтованого підходу, поняття об'єкта та класу. Уніфікована мова моделювання UML. Діаграми класів та взаємодії: призначення, побудова та приклади використання.
реферат, доданий 09.06.2009
Опис предметної області "Магазин з продажу комп'ютерних комплектуючих". Побудова ER та реляційної моделі даних, сутності та зв'язку. Створення ER і реляційної моделі даних, запитів, уявлень, процедур, що зберігаються для предметної області.
курсова робота , доданий 15.06.2014
Актуальність та практична значущість програмних систем комп'ютерного клубу. Аналіз предметної галузі. Діаграма класи, фізична модель системи. Розробка візуального проекту ІС, з використанням мови UML2.0 та середовища моделювання Microsoft Visio.
курсова робота , доданий 21.06.2014
Аналіз предметної галузі " Конкурс поетів " з урахуванням об'єктно-орієнтованого підходу. Розробка віконної програми та опис інформаційної моделі предметної області. Опис розроблених процедур С++ та результатів тестування програми.
курсова робота , доданий 18.06.2013
Функціональне моделювання IDEF0. Опис усіх процесів роботи відділу технічної підтримки. Декомпозиція контекстної діаграми та основних процесів. Побудова моделі процесів предметної області у стандарті IDEF1Х. Інтерфейс програми контролю трафіку.
звіт з практики, доданий 22.11.2014
Побудова інфологічної моделі предметної області методом ER-діаграми. Створення відносин БД з допомогою мови SQL. Заповнення бази даних. Створення запитів до бази даних комп'ютерного клубу. Створення звіту за допомогою Microsoft Word та Microsoft Excel.
курсова робота , доданий 26.02.2009
Коротка характеристика предметної галузі. Створення діаграми прецедентів, послідовності, співробітництва, класів, розміщення, компонентів. Додавання деталей до описів операцій та визначення атрибутів КЛАСІВ. Генерація програмного коду C++.
курсова робота , доданий 29.06.2011
Загальна характеристика складу, як об'єкта господарську діяльність. Створення діаграми прецедентів та послідовності. Побудова корпоративної діаграми співробітництва. Призначення діаграми класів та компонентів. Генерація програмного коду C++.
Бази даних. Заочники
Лабораторна робота №1
Побудова об'єктної моделі задачі за допомогою мови моделювання UML.
До захисту роботи має бути наданий проект, створений у пакеті Rational Rose, що включає три види діаграм: прецедентів, класів (інтерфейс, дані) та послідовностей для кожної функції.
Загальна інформація
Побудова моделі необхідна для того, щоб краще розуміти систему, що розробляється.
Моделювання дозволяє вирішити такі завдання:
Візуалізувати систему у її поточному чи бажаному для нас стані;
Визначити структуру чи поведінку системи;
Отримати шаблон, що дозволяє сконструювати систему;
Документувати рішення, що приймаються, використовуючи отримані моделі.
Клас(Class) – це опис сукупності об'єктів із загальними атрибутами, операціями та відносинами. Графічно клас зображується у вигляді прямокутника, в якому зазвичай записані його ім'я, атрибути та операції, як показано на рис. 1. Однією з різновидів сутності клас є актор(Actor). Зазвичай актор представляє роль, що у цій системі грає людина, апаратне пристрій і навіть інша система. Як показано на рис. 2, акторів зображують у вигляді людських фігурок.
Прецедент(Use Case) - це опис послідовності виконуваних системою дій, яка виробляє спостерігається результат, значимий якогось певного актора (Actor). Прецедент застосовується для структурування поведінкових сутностей моделі. Графічно прецедент зображується у вигляді обмеженого безперервною лінією еліпса, що зазвичай містить лише його ім'я, як показано на рис. 3.
Поведінкові сутностіє динамічними компонентами моделі UML. Це дієслова мови: вони описують поведінку моделі у часі та просторі. Існує два види поведінкових сутностей:
Взаємодія (Interaction);
Автомат (State machine).
Взаємодія(Interaction) – це поведінка, суть якого полягає у обміні повідомленнями (Messages) між об'єктами у межах конкретного контексту задля досягнення певної мети. Графічно повідомлення зображуються у вигляді стрілки, над якою майже завжди пишеться ім'я відповідної операції, як показано на рис. 4.
Групуючі сутностіє організуючими частинами UML. Це блоки, куди можна розкласти модель. Є лише одна сутність, що групує, а саме пакет.
Пакети(Packages) являють собою універсальний механізм організації елементів групи. У пакет можна помістити структурні, поведінкові і навіть інші сутності, що групують. На відміну від компонентів, що існують під час роботи системи, пакети мають суто концептуальний характер, тобто існують лише під час розробки. Зображується пакет у вигляді папки із закладкою, яка містить, як правило, лише ім'я (див. рис. 5).
Анотаційні сутності– пояснювальні частини моделі UML. Це коментарі для додаткового опису, роз'яснення чи зауваження до будь-якого елемента моделі. Є лише один тип інструкцій – примітки (Note).
Примітка– це символ для зображення коментарів або обмежень, приєднаних до елемента або групи елементів. Графічно примітка зображується у вигляді прямокутника із загнутим краєм, що містить текстовий або графічний коментар, як показано на рис. 6.
У мові UML визначено чотири типи відносин:
Залежність;
Асоціація;
Узагальнення;
Реалізація.
Ці відносини є основними будівельними блоками UML і застосовуються для створення коректних моделей.
Залежність(Dependency) – це семантичне відношення між двома сутностями, при якому зміна однієї з них, незалежної, може вплинути на семантику іншою залежною. Графічно залежність зображується як прямої пунктирної лінії, часто зі стрілкою (див. рис. 7).
Асоціація(Association) - структурне відношення, що описує сукупність зв'язків; зв'язок – це з'єднання між об'єктами. Графічно асоціація зображується у вигляді прямої лінії (іноді завершується стрілкою або містить мітку), поряд з якою можуть бути додаткові позначення, наприклад кратність та імена ролей. На рис. 8 показаний приклад відношень цього типу.
Діаграма в UML – це графічне представлення набору елементів, яке найчастіше зображується як зв'язного графа з вершинами (сутностями) і ребрами (відносинами). Діаграми малюють для візуалізації системи з різних точок зору. У UML виділяють дев'ять видів діаграм:
діаграми класів;
діаграми об'єктів;
діаграми прецедентів;
Діаграми послідовностей;
діаграми кооперації;
діаграми станів;
Діаграми дій;
діаграми компонентів;
Діаграми розгортання.
на діаграмі класівпоказують класи, інтерфейси, об'єкти та кооперації, а також їх стосунки. При моделюванні об'єктно-орієнтованих систем цей тип діаграм використовують найчастіше. Діаграми класів відповідають статичному виду системи з погляду проектування.
на діаграмі прецедентівпредставлені прецеденти та актори (приватний випадок класів), а також відносини між ними. Діаграми прецедентів належать до статичного виду системи з погляду прецедентів використання. Вони особливо важливі при організації та моделюванні поведінки системи.
Діаграми послідовностейє окремим випадком діаграм взаємодії. на діаграми взаємодіїпредставлені зв'язки між об'єктами; показано, зокрема, повідомлення, якими об'єкти можуть обмінюватися. Діаграми взаємодії належать до динамічного виду системи. У цьому діаграми послідовності відбивають тимчасову впорядкованість повідомлень.
Порядок виконання роботи буде розглянуто на прикладі наступного завдання:
Необхідно забезпечити зберігання у базі даних наступної інформації:
- інформація про студентів (включає П.І.Б., домашню адресу, паспортні дані, номер заліковки, дата народження, група);
- інформація про спеціальності (найменування спеціальності, шифр);
- інформація про групи (спеціальність, рік вступу, номер групи).
Забезпечити видачу документа "Список групи", що містить поля: порядковий номер, П.І.Б., номер заліковки.
Побудова об'єктної моделі виконується у пакеті Rational Rose. Для цього створимо порожній проект. Починати виконання слід з діаграми прецедентів. Її будують у сфері Main секції Use Case View, як показано на рис.9.
Перед початком побудови діаграми необхідно визначити ролі користувачів системи (акторів) та його функції (прецеденти). У нашому випадку із системою працюють два актори – це «Працівник навчального відділу» та «Працівник деканату». До функцій працівника навчального відділу входить ведення списку спеціальностей (під веденням спискуми розумітимемо додавання записів, їх коригування та видалення). Функції працівника деканату включають ведення списку студентів і ведення списку груп.
Побудована діаграма зображено на рис. 10.
Далі у секції Logical View слід створити дві діаграми класів. Для цього можна створити два пакети. Перша діаграма повинна містити класи інтерфейсу програми, що проектується (див. рис. 11). Друга діаграма – сутність бази даних (див. рис. 12).
У побудованій діаграмі класів відображені всі форми майбутнього застосування та їх взаємозв'язок.
Наступний етап побудови об'єктної моделі – створення діаграм послідовностей. Діаграми послідовностей створюються кожного прецеденту на діаграмі прецедентів. Щоб додати діаграму послідовностей до прецеденту, необхідно вибрати його в дереві та викликати на ньому контекстне меню (NewàSequence Diagram) як показано на рис. 13.
Приклад діаграми послідовностей прецеденту «Ведення списку спеціальностей» представлений на рис. 14.
