презентация лекций

Нижегородский государственный университет
им. Н.И. Лобачевского
Факультет вычислительной математики и кибернетики
Учебно-исследовательская лаборатория
"Информационные технологии"
Методы проектирования
программного обеспечения
ВМК ННГУ
План занятия.
Глава
1.
Структурный
проектированию ПО.
подход
к
Глава
2.
Объектно-ориентированный
подход к проектированию ПО.
Глава 3. Связь структурного и объектноориентированного подходов.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
2-<51>
Глава 1. Структурный подход.
Сущность структурного подхода…
Проблема сложности больших систем…
 Ни один разработчик не в состоянии
понять всю систему в целом.
Основные подходы к решению проблемы:
 Лозунг «Разделяй и властвуй».
 Иерархическая декомпозиция.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
3-<51>
Глава 1. Структурный подход.
Сущность структурного подхода…
Проблема сложности больших систем.
Необходимо составить правильную декомпозицию.
 Кол-во связей между отдельными подсистемами
должно быть минимальным;
 Связность отдельных частей внутри каждой
подсистемы должна быть максимальной;
Взаимодействие между подсистемами:
 каждая подсистема должна инкапсулировать свое
содержимое (скрывать его от других систем);
 каждая подсистема должна иметь четко определенный
интерфейс с другими подсистемами.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
4-<51>
Глава 1. Структурный подход.
Сущность структурного подхода…
Структурный подход к разработке ПО…
функционально-модульный(структурный) подход – структура
системы описывается в терминах иерархии ее функций и передачи
информации между отдельными функциональными элементами.
Базовые принципы структурного подхода:
 принцип иерархического упорядочения – организация
в древовидные структуры;
 принцип абстрагирования – выделение существенных
аспектов системы и отвлечение от несущественных;
 принцип непротиворечивости – обоснованность и
согласованность элементов системы;
 принцип структурирования данных – данные должны
быть структурированы и иерархически организованы.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
5-<51>
Глава 1. Структурный подход.
Сущность структурного подхода.
Структурный подход к разработке ПО.
Нужны модели, описывающие функциональную
структуру системы и отношения между данными.
Наиболее распространенными являются:



DFD (Data Flow Diagrams) – диаграммы потоков
данных;
SADT (Structured Analysis and Design Technique – метод
структурного анализа и проектирования) – модели и
соответствующие функциональные диаграммы;
ERD (Entity-Relationship Diagrams) – диаграммы
«сущность-связь».
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
6-<51>
Глава 1. Структурный подход.
Метод функционального моделирования SADT…
Общие сведения.
Функциональная модель SADT отображает функциональную
структуру объекта, т.е. производимые им действия и связи
между этими действиями.
Элементы метода основываются на следующих
концепциях:



графическое представление блочного моделирования. Функция
отображается в виде блока, а интерфейсы входа-выхода дугами.
строгость и точность. Ограничение количества блоков на каждом
уровне декомпозиции (правило 3-6 блоков), связность диаграмм
(номера блоков), уникальность меток, синтаксические правила
для графики, разделение входов и управлений.
Отделение организации от функции (исключение влияния
административной структуры организации на функциональную
модель).
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
7-<51>
Глава 1. Структурный подход.
Метод функционального моделирования SADT…
Состав функциональной модели…
Результатом применения метода SADT является модель,
которая состоит из диаграмм, фрагментов текстов и
глоссария, имеющих ссылки друг на друга.
Управление
Вход
Функция
А0
Выход
Механизм
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
8-<51>
Глава 1. Структурный подход.
Метод функционального моделирования SADT…
Состав функциональной модели.
Одной из наиболее важных особенностей метода является
постепенное введение все больших уровней
детализации по мере создания диаграмм,
отображающих модель.
Общее представление.
А-0
А0
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
9-<51>
Структура SADT-модели.
Декомпозиция диаграмм.
Более детальное представление.
А1
А2
А3
А0
А4
Верхняя диаграмма
является родительской
для нижней диаграммы
А421
ИТЛаб ВМК ННГУ,
14.05. 2003
А4
А41
А42
А43
А42
А422
А423
Методы проектирования ПО
© Пастухов В.А.
10-<51>
Глава 1. Структурный подход.
Метод функционального моделирования SADT.
Построение иерархии диаграмм.
А11
Родительский
блок
А12
А13
А1
А12
Эта управляющая дуга переносится с
родительской диаграммы
А121
А122
Эта входная дуга
А123
переносится с род.
диаграммы
Эта дуга продолжается на род. диаграмме
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
11-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов)…
Общие сведения.
Диаграммы потоков данных (DFD) являются основным
средством моделирования функциональных
требований к проектируемой системе.
Главная цель представления – продемонстрировать, как
каждый процесс преобразует свои входные данные в
выходные, а также выявить отношения между этими
процессами.
Для построения DFD используются две различные
нотации:
 Метод Йордана;
 Метод Гейна – Сэрсона.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
12-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов)…
Состав диаграмм потоков данных…
Основные компоненты диаграмм потоков
данных:
 внешние сущности;
 системы и подсистемы;
 процессы;
 накопители данных;
 потоки данных.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
13-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов)…
Состав диаграмм потоков данных…
Внешняя сущность представляет собой
материальный объект или физическое лицо –
источник или приемник информации,
например заказчики, персонал, поставщики,
клиенты, склад.
1
Налогоплательщик
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
14-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов)…
Состав диаграмм потоков данных…
Система представляет в самом общем виде саму
информационную систему. Либо эту роль
выполняет декомпозированный набор
подсистем.
Поле номера
Поле имени
Поле физической реализации
1
Подсистема по
работе с физ.
лицами
ГНИ
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
15-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов)…
Состав диаграмм потоков данных…
Процесс – преобразование входных потоков
данных в выходные в соответствии с
определенным алгоритмом.
Поле номера
Поле имени
Поле физической реализации
1.1
Проверить
плательщика на
задолженность
Нал. инспектор
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
16-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов)…
Состав диаграмм потоков данных…
Накопитель данных – это абстрактное
устройство для хранения информации,
которую можно в любой момент поместить в
накопитель и через некоторое время извлечь,
причем способы помещения и извлечения
могут быть любыми. На диаграмме
идентифицируется буквой «D» произвольным
числом.
D1
ИТЛаб ВМК ННГУ,
14.05. 2003
Реестр налогоплательщиков
Методы проектирования ПО
© Пастухов В.А.
17-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов)…
Состав диаграмм потоков данных.
Поток данных – информация, передаваемая
через некоторое соединение от источника к
приемнику. Поток данных изображается
линией, оканчивающейся стрелкой, которая
показывает направление потока.
1.5
Сформировать
отчётность по
подоходному
налогу
Отдел отчётности
ИТЛаб ВМК ННГУ,
14.05. 2003
Отчётность по
подоходному налогу
1
Региональная
ГНИ
Методы проектирования ПО
© Пастухов В.А.
18-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов)…
Построение иерархии диаграмм потоков
данных…
Главная цель построения иерархии DFD заключается в
том, чтобы сделать требования к системе ясными и
понятными на каждом уровне детализации.
Для достижения этого целесообразно:
 размещать на каждой диаграмме от 3 до 6-7 процессов;
 не загромождать диаграммы не существенными на
данном уровне деталями;
 декомпозицию потоков данных осуществлять
параллельно с декомпозицией процессов;
 выбирать ясные, отражающие суть дела имена
процессов и потоков.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
19-<51>
Глава 1. Структурный подход.
Моделирование потоков данных (процессов).
Построение иерархии диаграмм потоков
данных.
Каждый процесс может быть детализирован при помощи
DFD или (если процесс элементарный) спецификации.
Спецификация процесса должна формулировать его
основные функции таким образом, чтобы в
дальнейшем специалист, выполняющий реализацию
проекта, смог выполнить их или разработать
соответствующую программу. Спецификация является
конечной вершиной иерархии.
Решение о завершении детализации процесса и
использовании спецификации принимается
аналитиком.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
20-<51>
Глава 1. Структурный подход.
Сравнительный анализ SADT-моделей и DFD…
Соотношение применения этих двух разновидностей
структурного анализа в существующих CASEсредствах составляет для DFD – 90 % и для SADT –
10%.
Адекватность средств решаемым задачам. SADT
успешно работает только при описании хорошо
специфицированных и стандартизированных бизнеспроцессов. Если же речь идет не о системах вообще, а
о информационных системах, то здесь DFD вне
конкуренции. Наличие в DFD спецификаций
процессов нижнего уровня позволяет преодолеть
логическую незавершенность SADT.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
21-<51>
Глава 1. Структурный подход.
Сравнительный анализ SADT-моделей и DFD.
Согласованность с другими средствами структурного
анализа. Согласование SADT-модели с ERD
практически невозможно или носит искусственный
характер. В свою очередь, DFD и ERD взаимно
дополняют друг друга.
Интеграция с последующими стадиями ЖЦ ПО
(прежде всего со стадией проектирования). DFD
могут быть легко преобразованы в модели
проектируемой системы. Более того, известен ряд
алгоритмов автоматического преобразования иерархии
DFD в структурные карты различных видов.
Формальные же методы преобразования SADTдиаграмм в проектные решения отсутствуют.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
22-<51>
Глава 1. Структурный подход.
Функциональные модели.
Предназначены для описания функциональной
структуры проектируемой системы.
Иерархия экранных форм моделируется с помощью
диаграмм последовательностей экранных форм.
Техника структурных карт (схем) используется на
стадии проектирования для описания структурных
схем программ. Наиболее часто применяются две
техники:
1.
структурные карты Константайна (для описания
отношений между модулями).
2.
структурные карты Джексона (для описания
внутренней структуры модулей, являющихся
базовыми строительными блоками программной
системы).
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
23-<51>
Глава 1. Структурный подход.
Моделирование данных…
Основные понятия…
Цель моделирования данных состоит в
обеспечении разработчика концептуальной
схемой базы данных.
Наиболее распространенным средством моделирования
данных являются диаграммы «сущность-связь»
(ERD).
Базовыми понятиями ERD являются:
 сущность (Entity);
 связь (Relationship);
 атрибут (Attribute).
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
24-<51>
Глава 1. Структурный подход.
Моделирование данных…
Основные понятия.
Сущность (Entity) – реальный либо воображаемый
объект, имеющий существенное значение для
рассматриваемой предметной области. Каждая
сущность должна обладать уникальным
идентификатором.
Связь (Relationship) – поименованная ассоциация между
двумя сущностями, значимая для рассматриваемой
предметной области.
Атрибут (Attribute) – любая характеристика сущности,
значимая для рассматриваемой предметной области и
предназначенная для квалификации, идентификации,
классификации, количественной характеристики или
выражения состояния сущности.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
25-<51>
Глава 1. Структурный подход.
Моделирование данных…
Метод Баркера…
Данная нотация используется в CASE-средстве
Oracle Designer.
Первый шаг моделирования – извлечение полезной
информации из исходных данных и выделение
сущностей.
Автомашина
Продавец
Покупатель
Контракт
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
26-<51>
Глава 1. Структурный подход.
Моделирование данных…
Метод Баркера…
Второй шаг моделирования – идентификация связей.
Степени связи – один и много. Обязательность –
обязательная и необязательная.
Много
Необязательная
Один
Обязательная
Контракт
Автомашина
ИТЛаб ВМК ННГУ,
14.05. 2003
Продавец
Методы проектирования ПО
© Пастухов В.А.
Покупатель
27-<51>
Глава 1. Структурный подход.
Моделирование данных…
Метод Баркера…
Третий шаг моделирования – идентификация атрибутов.
Контракт
#И/Н (идентификационный номер)
*дата
*цена
Автомашина
#Р/Н
*год
*марка
*модель
*цена
ИТЛаб ВМК ННГУ,
14.05. 2003
Продавец
#И/Н
*имя
*адрес
телефон
Методы проектирования ПО
© Пастухов В.А.
Покупатель
#И/Н
*имя
*адрес
телефон
28-<51>
Глава 1. Структурный подход.
Моделирование данных…
Метод Баркера…
Помимо перечисленных основных конструкций модель
данных может содержать ряд дополнительных
 Супертипы и подтипы – одна сущность является
обобщающим понятием для группы подобных
сущностей.
Летательный аппарат
Супертипы
Аэроплан
Планер
Самолёт
Вертолёт
Подтипы
Другой тип
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
29-<51>
Глава 1. Структурный подход.
Моделирование данных…
Метод Баркера…

Взаимно исключающие связи – каждый экземпляр
сущности участвует только в одной связи из группы
взаимно исключающих связей.
А
В
С
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
30-<51>
Глава 1. Структурный подход.
Моделирование данных.
Метод Баркера.

Рекурсивная связь – сущность может быть связана сама
с собой.

Неперемещаемые (non-transferable) связи – экземпляр
сущности не может быть перенесен из одного
экземпляра связи в другой.
А
ИТЛаб ВМК ННГУ,
14.05. 2003
В
Методы проектирования ПО
© Пастухов В.А.
31-<51>
Глава 2. Объектно-ориентированный
подход. Сущность подхода…
Объектно-ориентированный подход
использует объектную декомпозицию,
при этом статическая структура системы
описывается в терминах объектов и
связей между ними, а поведение системы
описывается в терминах обмена
сообщений между объектами.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
32-<51>
Глава 2. Объектно-ориентированный
подход. Сущность подхода…
Концептуальной основой объектноориентированного подхода является объектная
модель.
Основными ее элементами являются:
 Абстрагирование;
 Инкапсуляция;
 Модульность;
 Иерархия.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
33-<51>
Глава 2. Объектно-ориентированный
подход. Сущность подхода…
Основные понятия объектно-ориентированного
подхода – объект и класс.
Объект определяется как осязаемая реальность –
предмет или явление, имеющие четко
определяемое поведение.
Класс – это множество объектов, связанных
общностью структуры и поведения.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
34-<51>
Глава 2. Объектно-ориентированный
подход. Сущность подхода…
Следующую группу важных понятий объектного
подхода составляют наследование и
полиморфизм.
Полиморфизм может быть интерпретирован, как
способность класса принадлежать более чем
одному типу.
Наследование означает построение новых
классов на основе уже существующих.
Объектно-ориентированная система изначально
строится с учетом ее эволюции.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
35-<51>
Глава 2. Объектно-ориентированный
подход. Сущность подхода.
Важным качеством объектного подхода является
согласованность моделей деятельности
организации и моделей проектируемой
системы.
Требование согласованности моделей
выполняется благодаря возможности
применения абстрагирования, модульности,
полиморфизма на всех стадиях разработки.
По объектным моделям может быть прослежено
отображение реальных сущностей
моделируемой предметной области в объекты и
классы информационной системы.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
36-<51>
Глава 2. Объектно-ориентированный
подход. UML…
Большинство существующих методов объектноориентированного анализа и проектирования (ООАП)
включают как язык моделирования, так и описания
процесса моделирования.
Язык моделирования – это нотация (в основном
графическая), которая используется методом для
описания проектов.
Нотация представляет собой совокупность графических
объектов, которые используются в моделях; она
является синтаксисом языка моделирования.
Процесс – это описание шагов, которые необходимо
выполнить при разработке проекта.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
37-<51>
Глава 2. Объектно-ориентированный
подход. UML…
UML (Unified Modeling Language) – это преемник того
поколения методов ООАП, которые появились в конце
80-х и начале 90-х гг.
Главными в разработке UML были следующие цели:





Представить пользователям готовый к использованию
выразительный язык визуального моделирования, позволяющий
разрабатывать осмысленные модели и обмениваться ими;
Обеспечить независимость от конкретных языков
программирования и процессов разработки;
Обеспечить формальную основу для понимания этого языка
моделирования;
Предусмотреть механизмы расширяемости и специализации для
расширения базовых концепций;
Интегрировать лучший практический опыт.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
38-<51>
Глава 2. Объектно-ориентированный
подход. UML.
Стандарт UML версии 1.1 предлагает следующий набор
диаграмм для моделирования:
 Диаграммы вариантов использования;
 Диаграммы классов;
 Диаграммы поведения системы;
 Диаграммы состояний;
 Диаграммы взаимодействия;
 Диаграммы деятельности;
 Диаграммы реализации;
 Диаграммы компонентов;
 Диаграммы размещения.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
39-<51>
Глава 2. Объектно-ориентированный
подход. Диаграммы классов ...
Диаграммы классов являются центральным
звеном объектно-ориентированных методов.
Диаграмма классов определяет типы объектов
системы и различного рода статические связи,
которые существуют между ними.
Имеются два основных вида статических связей:
 Ассоциации (Представляют собой связи
между экземплярами классов).
 Подтипы (частный клиент является
разновидностью клиента).
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
40-<51>
Глава 2. Объектно-ориентированный
подход. Диаграммы классов…
На диаграммах классов изображаются также атрибуты
классов, операции классов и ограничения, которые
накладываются на связи между объектами.
Построение диаграмм классов можно рассматривать в
различных аспектах:



Концептуальный аспект – диаграммы классов отображают
понятия изучаемой предметной области (моделируемой
организации).
Аспект спецификации – модель спускается на уровень ПО, но
рассматриваются только интерфейсы, а не программная
реализация классов (под интерфейсом здесь понимается набор
операций класса, видимых извне).
Аспект реализации – модель действительно определяет
реализацию классов ПО. Этот аспект наиболее важен для
программистов.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
41-<51>
Глава 2. Объектно-ориентированный
подход. Диаграммы классов…
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
42-<51>
Глава 2. Объектно-ориентированный
подход. Диаграммы классов...

Ассоциации.
Ассоциации представляют собой связи между
экземплярами классов ( личность работает в
компании, компания имеет ряд офисов).
С концептуальной точки зрения ассоциации
представляют собой концептуальные связи между
классами.
Каждая ассоциация обладает двумя ролями; каждая роль
представляет собой направление ассоциации. Таким
образом, ассоциация между Клиентом и Заказом
содержит две роли: одна от Клиента к Заказу, другая от Заказа к Клиенту.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
43-<51>
Глава 2. Объектно-ориентированный
подход. Диаграммы классов...

Атрибуты.
На концептуальном уровне наличие атрибута «имя
Клиента» указывает на то, что Клиенты обладают
именами.
На уровне спецификации этот атрибут указывает на то,
что объект Клиент может сообщить свое имя и
обладает некоторым механизмом его определения.
На уровне реализации Клиент содержит поле
(называемое также переменной или элементом
данных), соответствующее его имени.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
44-<51>
Глава 2. Объектно-ориентированный
подход. Диаграммы классов…

Операции.
Операции представляют собой процессы, реализуемые
классом.
Операции делятся на два типа:
 Запрос- операция, не изменяющая наблюдаемого
состояния класса, результатом ее является некоторое
значение, извлекаемое из класса. Наблюдаемым
состоянием объекта является состояние, которое
можно определить посредством связанных с ним
запросов.
 Модификатор- операция, изменяющая наблюдаемое
состояние объекта.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
45-<51>
Глава 2. Объектно-ориентированный
подход. Диаграммы классов...
Обобщение.
Типичный пример обобщения включает частного и
корпоративного клиентов.
На концептуальном уровне, Корпоративный клиент
является подтипом Клиента, если все экземпляры
Корпоративного клиента являются экземплярами
Клиента.
В рамках модели спецификации смысл обобщения
заключается в том, что интерфейс подтипа должен
включать все элементы интерфейса супертипа.
Обобщение в аспекте реализации связано с
наследованием в языках программирования.

ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
46-<51>
Глава 3. Связь структурного и объектноориентированного подходов…
Главный недостаток структурного подхода заключается в
следующем: процессы и данные существуют отдельно
друг от друга.
В объектно-ориентированном подходе основная
категория модели – класс – объединяет в себе на
элементарном уровне, как данные, так и операции,
которые над ними выполняются (методы).
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
47-<51>
Глава 3. Связь структурного и объектноориентированного подходов…
Данные по сравнению с процессами являются более
стабильной и относительно редко изменяющейся
частью системы. Отсюда следует главное
преимущество объектно-ориентированного подхода,
которое Гради Буч сформулировал следующим
образом:
“объектно-ориентированные системы более открыты и
легче поддаются внесению изменений, поскольку их
конструкция базируется на устойчивых формах. Это
дает возможность системе развиваться постепенно
и не приводит к полной ее переработке даже в случае
существенных изменений исходных требований.”
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
48-<51>
Глава 3. Связь структурного и объектноориентированного подходов…
Преимущества объектного подхода:
 Объектная декомпозиция дает возможность создавать
программные системы меньшего размера путем
использования общих механизмов, обеспечивающих
необходимую экономию выразительных средств.
 Объектная декомпозиция уменьшает риск создания
сложных систем ПО, так как она предполагает
эволюционный путь развития системы на базе относительно
небольших подсистем.
 Объектная модель вполне естественна, поскольку в первую
очередь ориентирована на человеческое восприятие мира.
 Объектная модель позволяет в полной мере использовать
выразительные возможности объектных и объектноориентированных языков программирования.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
49-<51>
Глава 3. Связь структурного и объектноориентированного подходов.
Основой взаимосвязи между структурным и
объектным подходом является общность ряда
категорий и понятий обоих подходов.
Переход организации на объектно-ориентированную
технологию – это смена мировоззрения.
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
50-<51>
Авторский коллектив.





Мееров Иосиф Борисович – куратор проекта
Яценко Антон – лидер проекта
Коваленко Антон
Пастухов Виталий
Жеглов Андрей
ИТЛаб ВМК ННГУ,
14.05. 2003
Методы проектирования ПО
© Пастухов В.А.
51-<51>