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

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

Наследование – принцип, в соответствии с которым знание об общей категории разрешается применять для более узкой. Применительно к классам это означает, что дочерний класс (узкая категория) полностью включает в себя (наследует) все атрибуты и методы, определенные в родительском классе (общей категории). При этом в дочернем классе могут быть определены дополнительные атрибуты и методы. Например, дочерний класс «треугольник» будет наследовать от родительского класса «геометрическая фигура» все атрибуты (x, у – координаты центра фигуры, color – цвет контура и т. д.) и все методы (draw() – нарисовать фигуру, move(dx, dy) – переместить фигуру и т. д.), а также иметь дополнительный атрибут (r – радиус и d диаметр).

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

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

1.3 Преимущества и недостатки объектно-ориентированного подхода

Определив сущность объектно-ориентированного подхода, можно представить сильные и слабые стороны этого способа.

Достоинства ООП заключаются в следующем:

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

К недостаткам ООП относятся:

• усложнение методологии. Применение объектно-ориентированного подхода требует введения дополнительных способов представления информации о предметной области и методов ее анализа. Язык UML включает более 100 различных условных обозначений. Для успешного использования подобного механизма требуется наличие определенного уровня квалификации у специалистов. Для небольших проектов более эффективным может оказаться применение классических методов разработки. Разработка проектов, для которых важнейшей задачей является описание предметной области и для которых невозможно найти человека, понимающего эту предметную область в целом, также требует использования традиционных подходов в виду их большей доступности для неспециалистов;
• сложность реализации. Объектно-ориентированные проекты и их программная реализация на объектно-ориентированном языке требуют больших временных затрат и приводят к построению более сложной и требовательной к ресурсам программы, нежели классические методы, которые могут оказаться более эффективными для некоторых задач.

Глава 2. Базовые составляющие объектно-ориентированного подхода

2.1 Готовые обобщённые решения

Стадии проектирования используют так называемые шаблоны проектирования.

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

Шаблоны являются эффективными и проверенными решениями. Обычно, но не всегда, оптимально решают задачу. За счёт этого применение шаблонов повышает качество разработки ПО и сокращает затраты.

2.2 Структура Унифицированного процесса

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

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

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

Существуют базовые концепции унифицированного процесса:

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

2.3 Унифицированный язык моделирования

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

Начало разработки UML было положено в 1994 г. Гради Бучем и Джеймсом Рамбо. Осенью 1995 г. к ним присоединился Ивар Якобсон и в октябре того же года была выпущена предварительная версия 0.8 унифицированного метода. С того времени выпущено несколько версий спецификации UML, две из них носят статус международного стандарта:

• UML 1.4.2 – "ISO/IEC 19501:2005. Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 1.4.2" (англ. "Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");
• UML 2.4.1 – "ISO/IEC 19505-1:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 1. Инфраструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 1: Infrastructure") и "ISO/IEC 19505-2:2012. Информационные технологии. Унифицированный язык моделирования группы по управлению объектами (OMG UML). Часть 2. Сверхструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

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

Семантика – раздел языкознания, изучающий значение единиц языка, прежде всего его слов и словосочетаний.

Синтаксис – способы соединения слов и их форм в словосочетания и предложения, соединения предложений в сложные предложения, способы создания высказываний как части текста.

Нотация в UML - графическая интерпретация семантики для ее визуального представления

Определено 3 типа сущностей:

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

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

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

Таблица 1.

Сущности в UML

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

Таблица 2

Декомпозируемые сущности

Наименование	Обозначение	Диаграмма
Скрытое составное состояние		Диаграмма автоматов
Скрытый фрагмент взаимодействия		Диаграмма последовательности
Деятельность		Диаграмма деятельности

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

Таблица 3.

Отношения