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

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

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

Унифицированный язык моделирования (UML) в настоящий момент является стандартом де-факто при описании (документирования) результатов проектирования и разработки объектно-ориентированных систем.

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

- UML 1.4.2 – "ISO/IEC 19501:2005. Информационные технологии. Открытая распределительная обработка. Унифицированный язык моделирования (UML). Версия 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

Рисунок 3

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

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

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

Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют статические части модели, соответствующие концептуальным или физическим элементам системы. Примерами структурных сущностей являются «класс», «интерфейс», «кооперация», «прецедент», «компонент», «узел», «актер».

---

Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей:

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

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

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Такая первичная сущность имеется в единственном экземпляре - это пакет.

Аннотационные сущности – это пояснительные части модели UML: комментарии для дополнительного описания, разъяснения или замечания к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание.

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

Зависимость (dependency) - это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой.

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

Обобщение (generalization) - это отношение, при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (предка). При этом, в соответствии с принципами объектно-ориентированного программирования, потомок (child) наследует структуру и поведение своего предка (parent). 

Реализация (realization) является семантическим отношением между классификаторами, при котором один классификатор определяет обязательство, а другой гарантирует его выполнение.

UML является открытым языком, то есть допускает контролируемые расширения, чтобы отразить особенности моделей предметных областей. Механизмы расширения UML включают:

стереотипы (stereotype) - расширяют словарь UML, позволяя на основе существующих элементов языка создавать новые, ориентированные для решения конкретной проблемы;

помеченные значения (tagged value) - расширяют свойства основных конструкций UML, позволяя включать дополнительную информацию в спецификацию элемента;

ограничения (constraints) - расширяют семантику конструкций UML, позволяя создавать новые и отменять существующие правила.

---

Совместно эти три механизма расширения языка позволяют модифицировать его в соответствии с потребностями проекта или особенностями технологии разработки.

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

диаграмма вариантов использования или прецедентов (use case diagram)

диаграмма классов (class diagram)

диаграммы поведения (behavior diagrams)

диаграмма состояний (statechart diagram)

диаграмма деятельности (activity diagram)

диаграммы взаимодействия (interaction diagrams) 

диаграмма последовательности (sequence diagram) 

диаграмма кооперации (collaboration diagram) 

диаграммы реализации (implementation diagrams)

диаграмма компонентов (component diagram) 

диаграмма развертывания (deployment diagram) 

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

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

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

связи, которые представляются различными линиями на плоскости;

текст, содержащийся внутри границ отдельных геометрических фигур;

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

2.3 Шаблоны проектирования

Шаблоны это эффективные решения, разработанные опытными профессионалами. Идея применения шаблонов принадлежит Кристоферу Александеру (1977 г.). Наиболее популярные шаблоны сводят в единые каталоги. Наиболее известными из них являются каталоги GoF "банды Четырех" (Гамма Е., Хелм Р., Джонсон Р. и Влиссидес Дж.) и GRASP (General Responsibility Assignment Software Patterns – общие шаблоны распределения обязанностей в программных системах).

Шаблон представляет собой именованную пару "проблема / решение", содержащую готовое обобщенное решение типичной проблемы. Таким образом, шаблон:

---

- имеет имя;

- содержит описание проблемы;

- содержит решение проблемы, которое должно адаптироваться при применении шаблона в конкретной ситуации;

- может содержать советы по поводу его применения в различных (специфичных) ситуациях и описание последствий его применения.

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

Объектно-ориентированный подход проектирования информационных систем обладает следующими преимуществами:

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

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

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

---

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

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

• осознавать выгоды такого подхода;

• знать, какие части задачи могут быть решены с применением существующих программных средств;

• заниматься поиском подходящих для повторного использования программ;

• стремиться найти такие программы;

• использовать их даже в том случае, если они лишь частично совпа­дают с тем, что программист написал бы сам.

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

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

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

---