ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 25.11.2019
Просмотров: 598
Скачиваний: 1
Динамічна модель в цілому об'єднує всі діаграми станів за допомогою подій між класами.
Функціональна модель показує, як обчислюються вихідні значення з вхідних без вказівки порядку, в якому ці значення обчислюються. Вона визначає всі операції, умови і обмеження, використовувані в об'єктній і динамічній моделях (зовнішні операції). Функціональна модель відповідає визначенню зовнішніх функцій при реляційному підході до розробки ПС.
Для визначення крупних операцій у функціональній моделі використовуються потокові діаграми (діаграми потоків даних), що дозволяють виразити ці операції через простіші операції. Основними поняттями потокових діаграм є процеси, об'єкти і потоки даних. Потокова діаграма – це граф, вершинами якого є об'єкти або процеси, а дугами – потоки даних. Процеси перетворять дані, що поступають від одних об'єктів і направляються для зберігання в інші об'єкти. Ці процеси представляють внутрішні операції, через які виражається операція, що представляється даною потоковою діаграмою. Об'єкти можуть бути пасивними (сховищами даних) і активними (агентами). Пасивні об'єкти використовуються тільки для зберігання даних, а активні об'єкти використовуються як для зберігання, так і для перетворення даних. Потоки даних визначають допустимі напрями переміщення даних і типи переміщуваних даних.
Процеси можуть виражатися термінальними операціями (визначувані безпосередньо) або за допомогою інших потокових діаграм. Таким чином, потокові діаграми є ієрархічними.
Термінальні операції визначаються так само, як і при реляційному підході (див. лекції 4 і 5). Втім, і діаграми потоків даних використовуються при реляційному підході.
Таким чином, основним змістом етапу зовнішнього опису при об'єктному підході є об'єктне моделювання. При цьому широко використовуються формальні мови специфікацій, у тому числі і графічні. Одним з найбільш споживаних в даний час таких мов є мова UML [15.5].
15.3. Особливості об'єктного підходу на етапі конструювання програмного засобу.
На етапі конструювання при об'єктному підході продовжується процес об'єктного моделювання: уточнюються моделі, побудовані на етапі зовнішнього опису, в термінах опису програмних систем і проводиться подальша декомпозиція об'єктів [15.3, 15.4, 15.5].
В процесі розробки об'єктної архітектури ПС виділяються всі об'єкти, з інформаційними моделями яких збирається безпосередньо працювати користувач, і завершується їх програмна специфікація, а так само визначається їх призначений для користувача інтерфейс. Такі об'єкти ми називатимемо призначеними для користувача. Класи таких об'єктів або окремі активні об'єкти утворюють архітектурні підсистеми. Визначається метод взаємодії між цими підсистемами.
Мал. 15.5. Архітектура «Клієнт-сервер»
У разі використання активних об'єктів основним широким класом архітектури при об'єктному підході є колектив програм (див. лекцію 6), що паралельно діють, причому тут роль програм виконують якраз ці активні об'єкти, а спосіб управління передачею повідомлень залежить від вибраного підкласу такої архітектури. Типовою архітектурою такого класу є архітектура «клієнт-сервер» (див. мал. 15.5). У такій системі один з активних об'єктів, званий сервером, виконує певні програмні послуги із запитів інших активних об'єктів, званих клієнтами. Такий запит передається серверу за допомогою повідомлення від клієнта, результат виконання сервером запиту передаються відповідному клієнтові за допомогою іншого повідомлення.
Подальша розробка структури програмних підсистем і їх кодування на мовах програмування може здійснюватися вже в рамках реляційного підходу на орієнтованих на нього мовах програмування [15.7] – користувач внутрішню організацію цих підсистем вже «не бачить». Проте, у багатьох випадках існують сильні аргументи за те, щоб продовжити об'єктну декомпозицію цих підсистем. Об'єктна структура цих підсистем може бути істотно зрозумілішою розробникові, ніж їх структура при реляційному підході. Крім того, продовження об'єктної декомпозиції і використання основних понять і методів об'єктного підходу при подальшій розробці ПС представляється «природним», оскільки весь процес розробки стає одноманітним (концептуально цілісним).
При розробки модульної структури при об'єктному підході використовуються переважно інформаційно міцні модулі. Інформаційно міцний модуль, що реалізовує який-небудь клас об'єктів або логічно зв'язану сукупність таких класів, зазвичай називають компонентом ПС.
15.4. Особливості об'єктного підходу на етапі кодування програмного засобу.
На етапі кодування при об'єктному підході використовуються мови програмування вже іншого типу – об'єктно-орієнтовані [15.7, 15.8]. Вважається, що мову програмування підтримує об'єктно-орієнтоване програмування, якщо він включає конструкції для [15.8]
-
інкапсуляції і абстракції даних
-
спадкоємство
-
динамічного поліморфізму.
Проте, найістотніша відмінність між реляційними і об'єктно-орієнтованими мовами програмування полягає в наступній: як основні засоби декомпозиції програм в реляційних мовах використовуються описи функцій і процедур (декомпозиція відносин), а в об'єктно-орієнтованих мовах – опис класів об'єктів (декомпозиція об'єктів). Об'єкти, що виникають в програмах при такій декомпозиції архітектурних підсистем, ми називатимемо об'єктами процесу виконання програм.
Змінюється і технологія розробки програмного модуля. При реляційному підході для розробки модуля (в основному, реалізовуючу функцію або процедуру) рекомендувалися структурне програмування і покрокова деталізація (див. лекцію 8). При об'єктно-орієнтованому підході для розробки компоненту (інформаційно міцного модуля) більш підходить запропонована Дейкстрой [15.9] низхідна технологію розробки шаруватої структури модуля. У цій технології кожен модуль розглядається таким, що складається з деякої впорядкованої сукупності програмних шарів (ср. з шаруватою програмною системою в лекції 6), причому кожен шар є реалізацією деякої абстрактної машини (у нашому випадку це можна розглядати як реалізацію класу або логічно зв'язаної сукупності класів). Таким чином, модуль утворює певний ланцюжок ієрархічно зв'язаних абстрактних машин (так звані «намиста» [15.9]) Реалізація кожної абстрактної машини виражається в термінах абстрактної машини (програмного шару, що нижче стоїть), що нижче стоїть, або в термінах вибраної мови програмування (при реалізації абстрактної машини самого нижнього рівня). Розробка модуля починається з розробки абстрактної машини самого верхнього рівня.
Вправи до лекції 15.
15.1. У чому полягає суть об'єктного підходу до розробки програмних засобів (ПС)?
15.2. Які категорії об'єктів можна виділити з погляду розробників ПС?
15.3. Що таке об'єктна модель ПС?
15.4. Що таке динамічна модель ПС?
15.5. Що таке діаграма станів класу?
15.6. Що таке функціональна модель ПС?
15.7. Що таке компонент ПС?
Литература к лекции 15.
15.1. К. Фути, Н. Судзуки. Языки программирования и схемотехника СБИС. – М.: Мир, 1988. С. 85-98.
15.2. В. Даль. Толковый словарь русского языка. – М.: Советская энциклопедия, 1975
15.3. J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorenzen. Objekt-Oriented Modeling and Design. – Prentice Hall. 1991.
15.4. Г.Буч. Объектно-ориентированное проектирование с примерами применения: пер. с англ. – М.: Конкорд, 1992.
15.5. М. Фаулер, К. Скотт. UML в кратком изложении. – М.: Мир, 1999.
15.6. Ф. Крачтен. Введение в RATIONAL UNIFIED PROCESS. – М.: Изд. Дом «Вильямс», 2002.
15.7. В.Ш.Кауфман. Языки программирования. Концепции и принципы. – М.: Радио и связь, 1993.
15.8. М. Бен-Ари. Языки программирования. Практический сравнительный анализ. – М.: Мир, 2000.
15.9. Э. Дейкстра. Заметки по структурному программированию / У. Дал, Э. Дейкстра, К. Хоор. Структурное программирование. – М.: Мир, 1975. – С. 7-97.