Проектирование информационных систем |
Конспект лекций |
План:
1. Понятие класса в ООП
2. Основные компоненты объектно-ориентированного проектирования
3. UML-модели систем
Унифицированный язык моделирования (Unified Modeling Language, UML) — стандартизированное языковое средство, ориентированное на создание и поддержку высококачественных проектов в сфере информационных технологий, укладываясь при этом в разумные временные рамки.
UML - своего рода вариант чертежа, принятый в индустрии информационных технологий. Это метод детального описания архитектуры системы. С его помощью легче создавать и сопровождать систему, вносить в нее требуемые изменения и убеждаться, что она выдержит это, проще составлять план тестирования готовой систем или ее части, составлять документацию.
Класс в UML представляет собой абстракцию в предметной области проектируемой системы, в общем случае выраженную существительным. Класс включает:
- атрибуты — данные, описывающие объект, а также тот объем информации об объекте, который хранится в системе;
- отношения с другими классами и операциями — поведение данного объекта, которое и описывает соответствующие ответственности).
Диаграмма классов отражает содержимое классов и их взаимоотношения. Классы определяют интерфейсы соответствующих экземпляров объектов, характеризуются идентичностью структуры, поведением и отличаются независимостью существования. Классы должны иметь четко определенные ответственности и поддерживать системообразующие функции, взаимодействуя с другими объектами посредством сообщений.
Классы описываются с помощью:
- атрибутов (данные, свойства),
- операций (службы, функции, поведение, процесс, методы),
- жизненного цикла разработки ИС (состояние, идентичность, независимость существования)
- ассоциаций (отношения, связи, соединения).
В современных САПР широко используется подход к определению классов объектов в рамках иерархического метода ООП:
- объекты и атрибуты — это существительные,
- операции и сервисы — глаголы;
Использование в качестве объектов проектирования событий, объектов и ситуаций реального мира из предметной области (например, документов, автомобилей, ролевых ситуаций диспетчера, водителя, механика и т.п.) может потребовать для их реализации специальных структур хранения данных (абстрактные структуры данных).
Основные компоненты объектно-ориентированного проектирования
Компоненты |
Содержание и функции |
Классы |
Объединения однородных объектов, имеющих одинаковые атрибуты, структуру и поведение |
Объекты |
Реальности (сущности), описываемые границами, индивидуальными состояниями и поведением |
Атрибуты |
Характеристики класса, отражающие идентификацию, состояние и поведение конкретного объекта этого класса |
Ассоциации |
Отношение между классами, отражающее связи между объектами этих классов |
Интерфейсы |
Множества операций взаимодействия между объектами |
Сообщения |
Взаимодействия объектов, имеющие стимулы, отправителя и получателя |
Операции |
Возможные воздействия объекта на другой объект того же 1 класса с целью вызвать отклик |
Состояние |
Ситуация, в течение которой объект выполняет деятельность или ожидает события |
Инкапсуляция |
Выделение и сокрытие части информации об объекте |
Наследование |
Совместное использование атрибутов и поведения объектов в пределах иерархической структуры для построения новых классов |
Диаграмма последовательности |
Диаграмма взаимодействия объектов, упорядоченных по времени_их проявления |
Объект является отдельным (особенным) экземпляром класса. Объект — это сущность, способная пребывать в различных состояниях и имеющая определенное множество операций. Состояние объекта определяется набором его атрибутов. Операции, связанные с объектом, предоставляют сервисы (функциональные возможности) другим объектам для реализации ответственностей. Каждый объект отличается идентичностью и имеет характерный набор значений для своих атрибутов. Объектом может быть:
— материальный предмет (или индивидуум);
— выполняемая роль;
— событие;
— взаимодействие (контракт);
— операционная процедура (обзор);
— организационная единица;
— место (организация, перекресток);
— структура.
Свойства классов динамически добавляются к данному объекту и удаляются из него.
Интерфейсом называется набор операций, характеризующих поведение объекта. Интерфейсы можно использовать:
Проектирование интерфейсов объектов может осуществляться для одного объекта или группы объектов. Интерфейсы определяются заранее, т.е. в начале жизненного цикла ИС. При этом проектная группа может быть разделена с учетом границ между объектами, что может быть предпочтительнее разделения по функциональным границам.
Сообщения — предполагают наличие объекта-отправителя и объекта-получателя, (включающего операцию для выполнения), а также задание параметров, необходимых для выполнения операции.
Сообщение является спецификацией по транспортировке информации из одного объекта в другой, причем ожидается, что эта деятельность имеет результат (сообщение может указывать на формирование сигнала или на вызов операции).
Стимул определяет передачу информации из одного экземпляра объекта в другой, (например, формирование сигнала или вызов операции). Является составной частью сообщения. Получение сообщения означает обработку стимула, который передается из объекта-отправителя.
Получатель (объект) является объектом для обработки стимула, который передается из объекта-отправителя.
Отправитель (объект) представляет собой объект, передающий стимул в объект-получатель.
Отношение представляет семантическую связь между элементами модели (примеры отношений включают ассоциации и обобщения).
Ответственность является контрактом или обязательством создателя классов; реализуется посредством пересылки одного или нескольких сообщений.
Атрибут представляет собой описание набора значений, характерных для объектов данного класса. Эта информация является для объекта внутренней и имеет следующие особенности:
- представление с помощью существительного;
- возможность описания объекта в терминах реального времени;
- индикация состояния объекта;
- обладание типом данных;
- идентичность для объектов одного класса — может отличаться по значению, но не по сути;
- возможность получения значения из определенной области допустимых значений.
Операция представляет собой услугу, которая может запрашиваться из объекта посредством сообщения для оказания влияния на его поведение. Операции могут быть описаны согласно следующим параметрам:
— инкапсулирование внутри объекта;
— предполагает отклик на стимул (принятие сообщения);
— возможность действия, выполняемого объектом с помощью другого объекта;
— возможность преобразования, которому подвергается объект.
Метод является специфической реализацией операции. Операция (метод) является средством, с помощью которого объект реализует свою ответственность. Операция для объекта вызывается с помощью сообщения, пересылаемого из другого объекта. Все объекты имеют методы, применяемые для их инициализации и выявления в рамках модели, а также возможности для приобретения атрибутов и избавления от них. Методы представляют собой способы взаимодействия объектов между собой, сообщений для вызова (стимулирования) определенной деятельности (поведения) в пределах объекта получателя. В ходе проведения анализа для этого к каждому объекту, имеющему ссылку на другие объекты, добавляется внешний ключ. Метод представляет реализацию для операции — указывает алгоритм или процедуру, которая ассоциируется с операцией.
Ассоциация отражает важное соединение (связь) между понятиями или классами (объектами). Имеет, по крайней мере, два ассоциативных конца. Свойство множественности для концов ассоциации показывает, какое число экземпляров объектов можно ассоциировать с отдельным экземпляром класса.
Инкапсуляция заключается в отделении внешних аспектов объекта от последствий внутренней реализации этого объекта. Другим термином инкапсуляции является сокрытие информации. Внешние аспекты объекта доступны другим объектам с помощью методов самого объекта, в то время как внутренние реализации этих методов скрыты от внешнего объекта, пересылающего сообщения. Инкапсуляция важна для поддержки объектно-ориентированных моделей. Поскольку подробности реализации скрыты от других объектов, они содержатся в пределах объекта. Влияние изменений, вносимых в реализацию метода, минимально для всей модели.
Потенциально все объекты являются повторно используемыми компонентами, так как они независимо инкапсулируют данные о состоянии и операции. Архитектуру ИС можно разрабатывать на базе объектов, уже созданных в предыдущих проектах. Такой подход снижает стоимость проектирования, программирования и тестирования ИС. Кроме того, появляется возможность использовать стандартные объекты, что уменьшает риск, связанный с разработкой программного средства. Однако иногда повторное использование эффективнее всего реализовать с помощью коллекций объектов (компонентов или объектных структур), а не через отдельные объекты.
Наследование определяет совместное использование атрибутов и поведение объектов в пределах иерархической структуры (суперклассов и/или подклассов). Каждый подкласс наследует все свойства — (атрибуты и операции) суперкласса (предка) и добавляет свои собственные уникальные свойства. Класс содержит описание всех атрибутов, ассоциаций и операций, входящих в объект, что является обобщением объекта. Каждый класс имеет набор наследуемых свойств — атрибутов, операций и ассоциаций. Эти структуры данных и алгоритмы немедленно становятся доступными для подклассов (наследников). Класс может иметь потомков (подклассы), где потомок является специализацией предшественника. Потомок наследует (включает в себя) эту структуру и поведение общих предшественников, при этом он способен добавлять свои собственные атрибуты и операции. Такое отношение также известно как обобщение (генерализация). Наследование/специализация/обобщение является преимуществом метода ООП, поскольку поддерживает повторное использование классов. Благодаря применению этих понятий свойства суперклассов повторяются в каждом объекте подкласса, и таким образом поддерживается высокий фактор обновления. Изменения для атрибутов или операций немедленно наследуются всеми подклассами.
Модели систем, разрабатываемые при формировании требований, должны отображать реальные сущности, принадлежащие классам объектов. Все объекты связаны с различными уровнями в архитектуре системы. Конкретные решения по архитектуре системы можно принимать в процессе ее реализации. Когда связи между разработчиками требований, проектировщиками и программистами не очень тесные (например, если система проектируется в одном подразделении предприятия, а реализуется в другом), требуется более детализированная модель. В процессе проектирования важно решить, какие требуются модели и какой должна быть степень их детализации. Это решение зависит также от типа разрабатываемой системы. Можно разработать различные типы объектных моделей, показывающие, как классы связаны друг с другом, как объекты агрегируются из других объектов, как объекты взаимодействуют с другими объектами. Идентификация объектов и классов объектов считается наиболее сложной задачей в процессе объектно-ориентированной разработки систем. Определение объектов — это основа для анализа и проектирования системы.
Модель окружения системы и модель использования системы представляют собой две дополняющие друг друга модели взаимоотношений между данной системой и ее окружением. Модель окружения системы — это статическая модель, которая описывает другие системы из окружения разрабатываемой ИС. Модель использования системы — динамическая модель, которая показывает взаимодействие данной системы со своим окружением. Модель окружения системы можно представить с помощью схемы связей, которая дает простую блок-схему общей архитектуры системы. С помощью пакетов языка UML ее можно представить в развернутом виде как совокупность подсистем. При моделировании взаимодействия проектируемой системы с ее окружением при ООП применяется абстрактный подход, который не требует больших объемов данных для описания этих взаимодействий. Подход, применяемый в UML, состоит в том, чтобы разработать модель вариантов использования, в которой каждый вариант представляет собой определенное взаимодействие с системой.
Объектные модели, разработанные для формирования требований, могут использоваться как для представления данных, так и для процессов их обработки. Они также полезны для классификации системных сущностей и могут представлять сущности, состоящие из других сущностей. Для некоторых классов систем объектные модели — естественный способ отображения реально существующих объектов, которые находятся под управлением системы. Например, для систем, обрабатывающих информацию относительно конкретных объектов (таких, как автомобили, самолеты, книги), которые имеют четко определенные атрибуты. Более абстрактные высокоуровневые сущности (например, библиотеки, медицинские регистрирующие системы или текстовые редакторы) труднее моделировать в виде классов объектов, поскольку они имеют достаточно сложный интерфейс, состоящий из независимых атрибутов и методов. Объектные модели упрощают переход к объектно-ориентированному проектированию и программированию. Поэтому полезно дополнить их моделями потоков данных, чтобы показать сквозную обработку данных в системе.
Модели данных строятся для информационных систем, использующих информационные базы данных. В одних случаях эта база данных существует независимо от программной системы, в других – специально создается для разрабатываемой системы. Важной частью моделирования систем является определение логической формы данных, обрабатываемых системой. Наиболее широко используемой методологией моделирования данных является моделирование типа «сущность – связь – атрибут», которое показывает структуру данных, их атрибуты и отношения между ними. Для описания структуры обрабатываемой информации модели данных часто используются совместно с моделями потоков данных. Проекты структуры ИС представляются ориентированными графами. Они состоят из набора узлов различных типов, соединенных дугами, отображающими связи между структурными узлами. В системе проектирования присутствуют средства вывода на дисплей этого графа (т.е. структурной диаграммы) и его преобразования к виду, удобному для хранения в базе данных проектов. Система редактирования выполняет преобразования структурной диаграммы из формата базы данных в формат, позволяющий отобразить ее на экране монитора в виде блок-схемы. Информация, предоставляемая редактором другим средствам анализа проекта, должна включить логическое представление графа проекта. Эти средства работают с объектами, их логическими атрибутами и связями между ними. Сущность — реальный или абстрактный объект, имеющий определяющее значение для рассматриваемой системы (это может быть объект как самой системы, так и ее окружения). Каждая сущность должна иметь уникальное имя и обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь. Сущность соответствует классу (или типу) объектов, а не конкретному экземпляру класса. Поименованная связь (ассоциация) между двумя сущностями осуществляется с помощью глаголов (например, имеет, определяет, принадлежит).
Атрибут — любая характеристика сущности (предназначается для идентификации, классификации, численной параметризации или описания состояния сущности). Значения атрибутов однозначно идентифицируют экземпляр сущности.
Язык моделирования UML не имеет определенных обозначений для типа моделей данных, что желательно для объектно-ориентированного процесса разработки ИС, где для описания систем используются объекты и их отношения. Если сущностям поставить в соответствие простейшие классы объектов (без ассоциированных методов), тогда в качестве моделей данных можно использовать модели классов UML совместно с именованными ассоциациями между классами.
Модели наследования. Важным этапом объектно-ориентированного моделирования является определение классов объектов, которые затем систематизируются. Это подразумевает создание схемы классификации, которая показывает, как классы объектов связаны друг с другом посредством общих атрибутов и сервисов. Схема классификации организована в виде иерархии наследования, на вершине которой представлены наиболее общие классы объектов, а более специализированные объекты наследуют их атрибуты и сервисы, а также могут иметь собственные атрибуты и сервисы. В нотации UML наследования показываются сверху-вниз, как принято в других объектно-ориентированных нотациях. Стрелка выходит из класса, который наследует атрибуты и операции, и направлена к родительскому классу. В UML вместо термина «наследование» чаще используется термин «обобщение». В моделях множественного наследования классы могут иметь нескольких родителей. В этом случае наследуются атрибуты и сервисы от каждого родительского класса.
Упрощение моделей при ООП может вызывать некоторые затруднения специалистов в понимании следующего:
- одни и те же динамические и статические модели описывают в разработке только «способы» взаимодействия с объектами;
- инкапсуляция скрывает внутреннее содержание объекта, позволяя разработчику уделять больше внимания методам использования объектов, их существенных, неотъемлемых характеристик; позволяет разделять статус, функцию, поведение; ограничивает доступ к переменным, которые функционируют внутри алгоритма;
- агрегация позволяет создавать крупный объект из небольших, упрощать вид объектов, позволяя выполнять обработку сложных состояний.
Контрольные вопросы и упражнения