Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Понятие и классификация).pdf

В рамках ООП разрабатываемая система сначала моделируется при помощи специального языка моделирования, и только после успешных результатов превращается в реальный программный комплекс [7].

Текущий этап развития информационных технологий характеризуется преимущественным выбором объектно-ориентированного подхода в построении баз данных на основе OLАP-структуры (см. рисунок 4).

Рисунок 4 – Форма организации ИС

Реляционные базы данных уступают место хранилищам данных и витринам данных на основе гиперкубов. Процесс преобразования баз данных является проблемным, так как нарушает принципы нормализации.

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

Рисунок 5 – Использование гибридной технологии

Хранилище данных предполагает хранение информации в виде гиперкуба, представленного на рисунке 6.

Рисунок 6 – Пример объектного гиперкуба

Физическая реализация гиперкубов представляется в виде инфологической модели (см. рисунок 7) [13].

Рисунок 7 – Инфологическая модель гиперкуба

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

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

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

• объектно-ориентированного анализа (object-oriented analysis – OOA), на данном этапе разрабатываемая и моделируемая системы анализируются с точки зрения объектов и классов, определенных в предметной области;
• объектно-ориентированного проектирования (object-oriented design – OOD), на данном этапе при помощи объектной декомпозиции создается объектная модель системы;
• объектно-ориентированного программирования (object-oriented programming – OOP), данный этап предполагает создание программы в виде совокупности объектов, каждый из которых в отдельности представляет собой является экземпляр определенного класса, а классы вместе образуют иерархию наследования.

В соответствии с требованиями анализа и проектирования для построения объектной модели сложной системы её требуется представлять в канонической форме. Каноническая форма содержит два вида иерархии: классов и объектов. Считается, что подобное разделение системы, позволяет полностью раскрыть ее архитектуру.

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

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

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

• абстрагирование – представляет собой способ выделения существенно важных характеристик некоторого объекта (абстракций), отличающих его от остальных видов объектов и, таким образом, четко определяющих его концептуальные границы;
• иерархия – способ упорядочения абстракций по уровням;
• инкапсуляция – способ отделения элементов объекта (класса), определяющих его устройство, от элементов, отвечающих за его поведение (разделение интерфейса и реализации);
• модульность – разложение системы на связанные, но относительно самостоятельные части (модули).

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

В рамках системы между классами могут реализовываться следующие отношения:

• наследование – такой вид отношений, при один котором класс полностью повторяет описание поведения и состояния другого класса (суперкласса). Если суперкласс один, наследование называется одиночным, если таких классов несколько – множественным. Данное отношение является базовым при составлении иерархии классов предметной области. Узкие, специализированные классы в иерархии, от которых создаются экземпляры (объекты), называются конкретными классами. Общие классы, от которых экземпляры не производятся, называются абстрактными классами. Верхний класс иерархии носит название базового или корневого;
• ассоциация – отношение семантической зависимости, которое определяет какие роли классы играют по отношению друг к другу. Ассоциации классифицируются по мощности: «один-к-одному», «один-ко-многим», «многое-ко-многим»;
• агрегация – отношение, которое реализует понятие «целое-часть» между объектами данных классов;
• использование – является частным случаем ассоциации, при котором одна из сторон (клиент) использует услуги или ресурсы другой стороны (сервера). Кроме того, подобное использование можно рассматривать и с точки зрения наследования, так как подкласс, наследуя поведение и состояние класса, выступает в роли его клиента.

Операции, которые могут предоставлять классы бывают следующих видов:

• модификатор – изменение состояния объекта;
• селектор – считывание состояния объекта без изменения его состояния;
• итератор – реализация доступа ко всем частям объекта в строго определенной последовательности;
• конструктор – создание и/или инициализация объекта;
• деструктор – освобождение состояния объекта и/или разрушение самого объекта.

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

Объединяя понятия поведения и состояния объекта, можно ввести понятие ответственности или роли объекта. Ответственность объекта характеризует две его стороны – знания, поддерживаемые объектом, и действия, которые этот объект может выполнить. Ответственность отвечает за смысл предназначения объекта и его место в системе. Термин «ответственность» понимается как совокупность всех контрактных обязательств и всех услуг объекта. Следовательно, поведение и состояние объекта отвечают за его роль в системе, а она, в свою очередь, необходима соответствующему классу для выполнения его ответственности.

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

• актор – в данной роли объект способен воздействовать на другие объекты, при этом сам объект не подвержен воздействию (активный объект);
• сервер – объект, находящийся в данной роли, может только подвергаться воздействию со стороны других объектов, не выступая при этом в роли воздействующего объекта (пассивный объект);
• агент – объект в данной роли может быть как активным, так и пассивным.

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

Классы и объекты представляют собой словарь предметной области. Объектно-ориентированная методика позволяет существенно увеличить качество и продуктивность разработки [1].

В рамках данной главы рассмотрены основные понятия ООП, выделены этапы объектно-ориентированного моделирования, а также отдельное внимание уделено понятиям «классы» и «объекты».

3. ЯЗЫК УНИФИЦИРОВАННОГО МОДЕЛИРОВАНИЯ UML

3.1. Термины и определения

Наиболее популярным способом наглядного представления информации о программном обеспечении является визуальное моделирование. Особенности визуального моделирования:

• использование графовых моделей;
• моделирование с разных точек зрения;
• возможность применения в разработке и эволюции ПО, а также в различных видах деятельности по его созданию [11].

Графовые модели, получаемые в результате визуального моделирования могут применяться при обсуждениях основных аспектов разработки с различными заинтересованными сторонами.

Наиболее распространенным языком визуального моделирования является UML (Unified Modeling Language — унифицированный язык моделирования). Данный язык дает возможность описания требований, бизнес-процессов, архитектуры программного обеспечения и разнообразных алгоритмов. Используя один стандарт, известный по всему миру, можно решать очень широкий спектр задач. Но одновременно этот же факт является главным недостатком UML — множество разнообразных средств данного языка, а также внушительные размеры документации (около 1000 страниц) делают UML сложным для изучения, поэтому часто его практическое использование ограничивается лишь небольшим набором задач [4].

В составе языка UML принято выделять 13 типов диаграмм (см. рисунок 8). Важно отметить, что на данном рисунке узлы «Структурные», «Поведенческие» и «Взаимодействий» обозначают группу, а не конкретный тип диаграмм.

Рисунок 8 – Типы диаграмм языка UML

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

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

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

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

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

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

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