Липаев В.В. Программная инженерия

Лекция 8. Объектно-ориентированное проектирование программных средств

ется внешний ключ. Метод представляет реализацию для операции — указывает алгоритм или процедуру, которая ассоциируется с операцией.

Ассоциация отражает важное соединение (связь) между понятиями или классами (объектами). Рассматриваемое понятие включает, по край­ ней мере, два ассоциативных конца. Свойство множественности для кон­ цов ассоциации показывает, какое число экземпляров объектов можно ассоциировать с отдельным экземпляром класса.

Процесс инкапсуляции состоит из отделения внешних аспектов объек­ та от последствий внутренней реализации этого объекта. Другим терми­ ном инкапсуляции является сокрытие информации. Внешние аспекты объекта доступны другим объектам с помощью методов самого объекта, в то время как внутренние реализации этих методов скрыты от внешнего объекта, пересылающего сообщения. Инкапсуляция важна для получения потенциала или для поддержки объектно-ориентированных моделей. По­ скольку подробности реализации скрыты от других объектов, они содер­ жатся в пределах объекта. Влияние изменений, вносимых в реализацию метода, минимально для всей модели.

Потенциально все объекты являются повторно используемыми ком­ понентами, так как они независимо инкапсулируют данные о состоянии и операции. Архитектуру ПС можно разрабатывать на базе объектов, уже созданных в предыдущих проектах. Такой подход снижает стоимость про­ ектирования, программирования и тестирования ПС. Кроме того, появля­ ется возможность использовать стандартные объекты, что уменьшает риск, связанный с разработкой программного средства. Однако иногда повтор­ ное использование эффективнее всего реализовать с помощью коллекций объектов (компонентов или объектных структур), а не через отдельные объекты.

Наследование определяет совместное использование атрибутов и по­ ведение объектов в пределах иерархической структуры (суперклассов и/или подклассов). Каждый подкласс наследует все свойства — (атрибуты и операции) суперкласса (предка) и добавляет свои собственные уникаль­ ные свойства. Класс содержит описание всех атрибутов, ассоциаций и операций, входящих в объект, что является обобщением объекта. Каждый тсласс имеет набор наследуемых свойств — атрибутов, операций и ассоци­ аций. Эти структуры данных и алгоритмы немедленно становятся доступ-

210

8.2. Основные понятия и модели объектно-ориентированного проектирования...

ными для подклассов наследников. Класс может иметь потомков (под­ классы), где потомок является специализацией предшественника. Пото­ мок наследует (включает в себя) эту структуру и поведение общих пред­ шественников, при этом он способен добавлять свои собственные атри­ буты и операции. Такое отношение также известно как обобщение (генерализация). Наследование/специализация/обобщение является преиму­ ществом метода ООП, поскольку поддерживает повторное использование классов. Благодаря применению этих понятий свойства суперклассов по­ вторяются в каждом объекте подкласса, и таким образом поддерживается высокий фактор обновления. Изменения для атрибутов или операций не­ медленно наследуются всеми подклассами.

Модели систем, разрабатываемые при формировании требований, должны отображать реальные сущности, принадлежащие классам объек­ тов. Все объекты связаны с различными уровнями в архитектуре систе­ мы. Конкретные решения по архитектуре системы можно принимать в процессе ее реализации. Когда связи между разработчиками требований, проектировщиками и программистами не очень тесные (например, если система проектируется в одном подразделении предприятия, а реализует­ ся в другом), требуется более детализированная модель. Следовательно, в процессе проектирования важно решить, какие требуются модели и какой должна быть степень их детализации. Это решение зависит также от типа разрабатываемой системы.

Классы не должны содержать информацию об отдельных системных объектах. Можно разработать различные типы объектных моделей, пока­ зывающие, как классы связаны друг с другом, как объекты агрегируются из других объектов, как объекты взаимодействуют с другими объектами. Эти модели расширяют понимание разрабатываемой системы. Идентифи­ кация объектов и классов объектов считается наиболее сложной задачей в процессе объектно-ориентированной разработки систем. Определение объектов — это основа для анализа и проектирования системы.

Модель окружения системы и модель использования системы пред­ ставляют собой две дополняющие друг друга модели взаимоотношений между данной системой и ее окружением. Модель окружения системы — это статическая модель, которая описывает другие системы из окружения разрабатываемого ПС. Модель использования системы — динамическая

211

Лекция 8. Объектно-ориентированное проектирование программных средств

модель, которая показывает взаимодействие данной системы со своим окружением. Модель окружения системы можно представить с помощью схемы связей, которая дает простую блок-схему общей архитектуры сис­ темы. С помощью пакетов языка UML ее можно представить в разверну­ том виде как совокупность подсистем. Такое представление показывает, что рабочее окружение системы находится внутри подсистемы, занимаю­ щейся сбором данных. При моделировании взаимодействия проектируе­ мой системы с ее окружением при ООП применяется абстрактный подход, который не требует больших объемов данных для описания этих взаимо­ действий. Подход, применяемый в UML, состоит в том, чтобы разрабо­ тать модель вариантов использования, в которой каждый вариант пред­ ставляет собой определенное взаимодействие с системой.

Объектные модели, разработанные для формирования требований, могут использоваться как для представления данных, так и для процессов их обработки. В этом отношении они объединяют модели потоков данных и семантические модели данных. Они также полезны для классификации системных сущностей и могут представлять сущности, состоящие из дру­ гих сущностей. Для некоторых классов систем объектные модели — есте­ ственный способ отображения реально существующих объектов, которые находятся под управлением системы. Например, для систем, обрабатыва­ ющих информацию относительно конкретных объектов (таких, как авто­ мобили, самолеты, книги), которые имеют четко определенные атриб)п:ы. Более абстрактные высокоуровневые сущности (например, библиотеки, медицинские регистрирующие системы или текстовые редакторы) труднее моделировать в виде классов объектов, поскольку они имеют достаточно сложный интерфейс, состоящий из независимых атрибутов и методов.

Объектные модели, разработанные во время анализа требований, уп­ рощают переход к объектно-ориентированному проектированию и про­ граммированию. Однако конечные пользователи часто считают объект­ ные модели неестественными и трудными для понимания. Часто они пред­ почитают функциональные представления процессов обработки данных. Поэтому полезно дополнить их моделями потоков данных, чтобы показать сквозную обработку данных в системе.

Модели данных — больших программных систем используют ин­ формационные базы данных. В одних случаях эта база данных существует

212

8.2. Основные понятия и модели объектно-ориентированного проектирования...

независимо от пропзаммной системы, в других — специально создается для разрабатываемой системы. Важной частью моделирования систем яв­ ляется определение логической формы данных, обрабатываемых систе­ мой. Наиболее широко используемой методологией моделирования дан­ ных является моделирование типа «сущность — связь — атрибут», кото­ рое показывает структуру данных, их атрибуты и отношения между ними.

Для описания структуры обрабатываемой информации модели дан­ ных часто используются совместно с моделями потоков данных. Проекты структуры ПС представляются ориентированными графами. Они состоят из набора узлов различных типов, соединенных дугами, отображающими связи между структурными узлами. В системе проектирования присут­ ствуют средства вывода на дисплей этого графа (т.е. структурной диа­ граммы) и его преобразования к виду, удобному для хранения в базе данных проектов. Система редактирования выполняет преобразования структурной диаграммы из формата базы данных в формат, позволяющий отобразить ее на экране монитора в виде блок-схемы. Информация, предо­ ставляемая редактором другим средствам анализа проекта, должна вклю­ чить логическое представление графа проекта. Эти средства работают с объектами, их логическими атрибутами и связями между ними.

Сущность — реальный или абстрактный объект, имеющий определя­ ющее значение для рассматриваемой системы (это может быть объект как самой системы, так и ее окружения). Каждая сущность должна иметь уникальное имя и обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь. Сущность соответствует классу (или типу) объектов, а не конкретному экземпляру класса. Поименованная связь (ассоциация) между двумя сущностями осу­ ществляется с помощью глаголов (например, имеет, определяет, принад­ лежит). Атрибут — любая характеристика сущности (предназначается для идентификации, классификации, численной параметризации или описа­ ния состояния сущности). Значения атрибутов однозначно идентифициру­ ют экземпляр сущности.

Язык моделирования UML не имеет определенных обозначений для типа моделей данных, что желательно для объектно-ориентированного процесса разработки ПС, где для описания систем используются объекты и их отношения. Если сущностям поставить в соответствие простейшие классы объектов (без ассоциированных методов), тогда в качестве моде-

213

Лекция 8. Объектно-ориентированное проектирование программных средств

лей данных можно использовать модели классов UML совместно с име­ нованными ассоциациями между классами.

Модели наследования. Важным этапом объектно-ориентированного моделирования является определение классов объектов, которые затем систематизируются. Это подразумевает создание схемы классификации, которая показывает, как классы объектов связаны друг с другом посред­ ством общих атрибутов и сервисов. Схема классификации организована в виде иерархии наследования, на вершине которой представлены наиболее общие классы объектов. Более специализированные объекты наследуют их атрибуты и сервисы. Эти объекты могут иметь собственные атрибуты и сервисы. В нотации UML наследования показываются сверху-вниз, как принято в других объектно-ориентированных нотациях. Стрелка выходит из класса, который наследует атрибуты и операции, и направлена к роди­ тельскому классу. В UML вместо термина «наследование» чаще использу­ ется термин «обобщение». В моделях множественного наследования клас­ сы могут иметь нескольких родителей. Тогда наследуются атрибуты и сервисы от каждого родительского класса.

Упрощение моделей при ООП может вызывать некоторые затрудне­ ния специалистов в понимании следующего:

—одни и те же динамические и статические модели описывают в разработке только «способы» взаимодействия с объектами;

—инкапсуляция скрывает внутреннее содержание объекта, позво­ ляя разработчику уделять больше внимания методам использования объек­ тов — их существенных, неотъемлемых характеристик; позволяет разде­ лять статус, функцию, поведение; ограничивает доступ к переменным, которые функционируют внутри алгоритма;

—агрегация позволяет создавать крупный объект из небольших, уп­ рощать вид объектов, позволяя выполнять обработку сложных состояний.

8.3.Варианты представления моделей

исредства объектно-ориентированного проектирования

программных средств

Существует два типа объектно-ориентированных моделей систем­ ной архитектуры:

214

8.3.Варианты представления моделей и средства проектирования...

—статические модели, которые описывают структуру системы в тер­ минах классов объектов и взаимоотношений между ними, которые доку­ ментируются на данном этапе, являются отношениями обобщения, отно­ шениями «используют — используются» и структурными отношениями;

—динамические модели, которые описывают структуру системы и показывают динамические взаимодействия между объектами системы (но не классами объектов), — документируемые взаимодействия содержат последовательность составленных объектами запросов к сервисам и опи­ сывают реакцию системы на взаимодействия между объектами.

Вязыке моделирования UML поддерживается ряд возможных стати­ ческих и динамических моделей:

— модели подсистем, которые показывают логически сгруппирован­ ные объекты, они представлены с помощью диаграммы классов, в которой каждая подсистема обозначается как пакет, и является статическим;

— модели последовательностей, которые показывают взаимодействия между объектами, они представляются в UML с помощью диаграмм пос­ ледовательности или кооперативных диаграмм — динамические модели;

— модели конечного автомата, которые показывают изменение со­ стояния отдельных объектов в ответ на определенные события, в UML они представлены в виде диаграмм состояния — динамические модели.

Модель подсистемы является одной из наиболее важных и полезных статических моделей, поскольку показывает, как можно организовать сис­ тему в виде логически связанных групп объектов. В UML пакеты являют­ ся структурами инкапсуляции и не отображаются непосредственно в объек­ тах разрабатываемой системы. Существует несколько способов создания, применения и введения новых определений для моделей ООП с использо­ ванием диаграмм вариантов использования сценариев, диаграмм действий, диаграмм класс/объект, а также диаграмм сотрудничества, взаимодействия, перехода состояния, контекста данных и словаря данных. Некоторые вво­ дятся сверху-вниз, другие — снизу-вверх, и все они итеративно определя­ ются заново с помощью сотрудничества.

Статическое представление объектно-ориентированного анали­ за — представляет собой диаграмму класса, а также диаграмму объекта для представления определенного экземпляра класса, куда входят компо­ ненты атрибутов, служб и отношений наряду с понятиями, взятыми из

215

Лекция 8. Объектно-ориентированное проектирование программных средств

иерархии, абстракции, инкапсуляции и наследования. Идентифицируются ответственности классов, затем обработка идет наверх, а для достовернос­ ти применяются сценарии вариантов использования. В этом случае реали­ зуется подход снизу-вверх. Подобный способ достаточно хорош, но суще­ ствует еще путь сверху-вниз, когда при идентификации классов начинают с практических примеров, а затем продолжается обработка вниз, доходя до сценариев. Если начать с классов, можно сначала идентифицировать их через абстракции. Затем для каждого класса перечисляются ответственно­ сти, идентифицируются атрибуты и операции (поведение — снова через абстракцию) и, наконец, обращаются к сценариям вариантов использова­ ния для подтверждения диаграммы класса. Однако сначала рассматрива­ ется описание диаграмм классов.

Статическое представление объектно-ориентированной разра­ ботки проекта — диаграммы взаимодействия и сотрудничества ото­ бражают взаимодействия, которые пространственно ориентированы на ок­ ружение модели и характеризуют классы и ассоциации (экземпляры и связи). Целью сотрудничества является определение способов реализации вариантов использования. Диаграмма сотрудничества отображает отноше­ ния между экземплярами объектов. Поведение реализуется с помощью набора объектов, обменивающихся входными сигналами в рамках общего взаимодействия, что позволяет достичь поставленной цели. Для представ­ ления механизмов, применяемых при разработке, важно обращать внима­ ние только на определенные объекты и изучать взаимодействие между ним. Рассматриваемые объекты всегда выделяются из большей системы, в которой данные объекты являются лишь компонентами.

Сотрудничество уточняет контекст, который позволяет выразить по­ ведение реализуемого элемента в терминах, единых для всех участников сотрудничества. Таким образом, в то время как модель представляет сис­ тему в целом, сотрудничество является лишь частичным отображением данной модели. Именно сотрудничество определяет эффективность при­ менения подмножества содержимого модели. Сотрудничество можно оха­ рактеризовать на двух различных уровнях: на уровне спецификации или на уровне экземпляра. Диаграмма, представляющая сотрудничество на уровне спецификации, характеризует роль классов и ассоциаций. В то же время диаграмма на уровне экземпляра отображает экземпляры и связи,

216

8.3. Варианты представления моделей и средства проектирования...

которые согласуются с ролями в сотрудничестве. При отображении со­ трудничества указывается, какие экземпляры свойств должны принимать участие в сотрудничестве, т.е. каждый участник указывает необходимые свойства, которыми должен обладать согласуемый экземпляр.

Динамическое представление объектно-ориентированного проек­ тирования — диаграммы взаимодействия и последовательные диаг­ раммы демонстрируют взаимодействие, отображенное в динамике. В ней отображаются экземпляры, участвующие во взаимодействии с помощью соответствующих линий жизни, а также входные сигналы, которыми они обмениваются. Эти сигналы собраны во временную последовательность. В отличие от диаграммы сотрудничества, последовательная диаграмма включает временные последовательности, но не содержит объектных от­ ношений. Последовательная диаграмма может существовать в общей фор­ ме (описывать все возможные сценарии) и в форме экземпляра (описывать один действительный сценарий). Последовательные диаграммы и диаг­ раммы сотрудничества выражают подобную информацию, однако исполь­ зуют различные способы. Последовательная диаграмма имеет две размер­ ности: размерность по вертикали представляет время; размерность по го­ ризонтали представляет различные объекты.

Динамическое представление объектно-ориентированной разра­ ботки проекта — диаграммы переходов между состояниями представ­ ляют основанное на состоянии поведение класса экземпляров объектов для всех сценариев. Обычно моделируются лишь классы с объектами, ко­ торые, как ожидается, проходят через наборы состояний. Состояние пред­ ставляет условие или ситуацию во время жизни объекта, при которой удовлетворяется определенное условие, реализуется некоторая деятель­ ность или же ожидается какое-либо событие. Диаграмма состояния ото­ бражает механизм состояния — поведение, определяющее последователь­ ности состояния, которые проходит объект или взаимодействие во время своей жизни при отклике на события, вместе с соответствующими откли­ ками и действиями.

Механизм состояния определяет набор понятий, которые могут ис­ пользоваться для моделирования дискретного поведения с помощью ко­ нечных систем переходных состояний. Экземпляры событий генерируют­ ся в результате определенного действия в пределах системы или ее окру-

217

Лекция 8. Объектно-ориентированное проектирование программных средств

жения. Затем событие ориентируется на одну или несколько целей. Сред­ ства, с помощью которых экземпляры событий транспортируются к месту назначения, зависят от типа действия, цели, свойств среды коммуникации и многих других факторов. В некоторых случаях это происходит практи­ чески мгновенно и вполне надежно, в то время как в других случаях могут происходить периодические задержки передачи, потеря событий, пере­ упорядочивание или дублирование. Поддерживается полная гибкость при моделировании различных типов коммуникационных возможностей. Со­ бытие получено, если оно размещено в очереди событий по целевому назначению. Событие отправлено, если оно извлечено из очереди собы­ тий и доставлено к механизму состояния для обработки. С этой точки зрения на него ссылаются как на текущее событие. Наконец, событие поглощено, если завершена его обработка. Поглощенное событие стано­ вится недоступным для обработки. Никакие требования не предъявляются к интервалам времени между получением события, отправлением и погло­ щением.

Состояние становится активным, если оно вводится как результат некоторого перехода, а неактивным, если завершается как результат пе­ рехода. Состояние может быть завершено и начато как результат одного и того же перехода. Диаграммы состояния представляют объекты, способ­ ные к динамическому поведению, путем указания соответствующего от­ клика на получение экземпляров события. Обычно они применяются при описании поведения классов. Состояние представляет собой условие во время жизни объекта или взаимодействие, во время которого оно удовлет­ воряет некоторое условие, выполняет определенное действие или ожидает некоторое событие. Концептуально объект остается в состоянии во время некоторого интервала времени.

Инструментальные средства анализа и проектирования ПС со­ зданы для поддержки моделирования систем на этапах жизненного цикла программных средств. Они поддерживают создание, редактирование и ана­ лиз графических нотаций, используемых в структурных методах. Инстру­ ментальные средства анализа и проектирования часто поддерживают только определенные методы проектирования и анализа, например объектно-ори­ ентированные. Другие инструментальные средства являются универсаль­ ными системами редактирования диаграмм многих типов, которые ис-

218

8.3. Варианты представления моделей и средства проектирования...

пользуются разными методами проектирования и анализа. Инструменталь­ ные средства, ориентированные на определенные методы, обычно автома­ тически поддерживают правила и базовые принципы этих методов, что позволяет выполнять автоматический контроль диаграмм.

Инструментальные средства обычно объединяются через общий репозиторий, структура которого является собственностью разработчика пакета инструментальных средств. Центральный репозиторий позволяет проектировщику найти нужный проект, компонент и соответствующую проектную информацию. Обычно для создания общего репозитория инст­ рументов используются системы баз данных типа Sybase или Oracle. Эти пакеты инструментальных средств содержат большое количество средств языков программирования четвертого поколения, предназначенных для генерирования программного кода на основе системной архитектуры, они также могут генерировать базы данных. Пакеты инструментальных средств обычно закрыты, т.е. не рассчитаны на добавление пользователями соб­ ственных инструментов или на изменение средств пакета, в который вхо­ дят:

—редакторы диаграмм, предназначенные для создания диаграмм по­ токов данных, иерархий объектов, диаграмм «сущность-связь», эти редак­ торы не только имеют средства рисования, но и поддерживают различные типы объектов, используемых в диаграммах;

—средства проектирования, анализа и проверки выполняют проек­ тирование ПС и создают отчеты об ошибках и дефектах в системной архитектуре, они могут работать совместно с системой редактирования, поэтому обнаруженные ошибки можно устранять на ранней стадии про­ цесса проектирования;

—словарь данных хранит информацию об объектах, которые исполь­ зуются в структуре системы;

—средства генерирования отчетов на основе информации из цент­ рального репозитория автоматически генерируют системную документа­ цию;

—средства создания форм определяют форматы документов и экран­ ных форм;

—средства импортирования и экспортирования позволяют обмени­ ваться информацией из центрального репозитория различным инструмен­ тальным средствам;

219