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

Суть полиморфизма понимается как способность класса принадлежать более чем одному типу.

Полиморфизм — это способность скрывать множество различных реализаций под единственным общим интерфейсом.

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

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

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

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

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

• компонентом исходного кода;

• компонентом времени выполнения (run time);

• исполняемым компонентом.

Компонент обеспечивает физическую реализацию набора интерфейсов.

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

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

Агрегация (aggregation) представляет собой форму ассоциации — более сильный тип связи между целым (составным) объектом и его частями (компонентными объектами).

Существуют четыре возможных семантики для агрегации:

1) агрегация типа «Безраздельно обладает»;

2) агрегация типа «Обладает»;

3) агрегация типа «Включает»;

4) агрегация типа «Участник».

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

Раздел 2. Структура и основные понятия унифицированного языка моделирования (UML)

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

Первым объектно-ориентированным языком принято считать Simula-67, разработанный Далем и Нигардом в Норвегии в 1967 году. Этот язык использовался ограниченно, тем не менее его концепция во многом способствовала появлению других языков. В начале 1980-х годов широко распространился язык Smalltalk, а в конце того же десятилетия стали активно применяться другие объектно-ориентированные языки, такие как Objective C, C++ и Eiffel.

Объектно-ориентированные языки моделирования появились в 1980-х годах. Именно тогда у разработчиков назрела необходимость учитывать новые возможности объектно-ориентированных языков программирования, так как приложения, становившиеся всё более сложными, предъявляли всё более трудные для выполнения требования. Понадобилось начать разработку новых, альтернативных подходов к анализу и проектированию. В период с 1989 по 1994 год число объектно-ориентированных методов возросло с десяти более чем до пятидесяти. Тем не менее многие пользователи затруднялись выбрать язык моделирования, который полностью отвечал бы их потребностям, что привело к так называемой «войны методов». В результате появилось новое поколение методов, среди которых особое значение приобрели метод Буча, OOSE (Object-Oriented Software Engineering), разработанный Якобсоном, и OMT (Object Modeling Technique), разработанный Рамбо. Кроме того, следует упомянуть методы Fusion, Shlaer-Mellor и Coad-Yourdon.

Критическая масса новых идей начала накапливаться к середине 1990-х годов, когда Гради Буч (компания Rational Software Corporation), Джеймс Рамбо (General Electric), Ивар Якобсон (Objectory) и некоторые другие разработчики попытались объединить свои методы, которые к этому времени уже получили мировое признание как наиболее перспективные в области объектно-ориентированных методов. Они старались создать новый, унифицированный язык моделирования, при этом руководствуясь вполне определенными соображениями. Во-первых, все три метода независимо от желания разработчиков уже развивались во встречном направлении. Разумно было продолжить это движение вместе, а не по отдельности, что помогло бы в будущем устранить нежелательные различия и, как следствие, неудобства для пользователей. Во-вторых, унифицировав методы, проще было привнести стабильность на рынок инструментов объектно-ориентированного моделирования, что дало бы возможность положить в основу всех проектов единый зрелый язык, а создателям инструментальных средств позволило бы сосредоточиться на более продуктивной деятельности. Наконец, следовало полагать, что подобное сотрудничество приведет к усовершенствованию всех трех методов и обеспечит решение задач, для которых любой из них, взятый в отдельности, был не слишком пригоден.

Начав унификацию, разработчики поставили перед собой три главные цели:

1. Моделировать системы целиком, от концепции до исполняемых компонентов, с помощью объектно-ориентированных методов;

2. Решить проблему масштабируемости, которая присуща сложным, критически важным системам;

3. Создать язык моделирования, который может использоваться не только людьми, но и компьютерами.

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

Официальное создание UML началось в октябре 1994 года, после перехода Рамбо в компанию Rational Software, где на тот момент работал Буч. Первоначальной целью было объединение методов Буча и OMT. Первая пробная версия 0.8 Унифицированного метода (Unified Method), как его тогда называли, появилась в октябре 1995 года. Приблизительно в то же время в компанию Rational перешел Якобсон, и проект UML был расширен с целью включить в него OOSE. В результате совместных усилий в июне 1996 года вышла версия 0.9 языка UML. В течение года создатели собирали отзывы от основных компаний-разработчиков программного обеспечения. Выяснилось, что большинство таких компаний сочло UML языком, имеющим стратегическое значение для их бизнеса.

В результате был создан так называемый «консорциум UML». Он объединил организации, которые пожелали предоставить необходимые ресурсы для работы, ориентированной на разработку полной спецификации языка. UML версии 1.0 оказался хорошо определенным, выразительным, мощным языком, применимым для решения большого количества разнообразных задач. В январе 1997 года он был представлен в качестве проекта стандартного языка моделирования консорциуму OMG (Object Management Group).

Пересмотренная версия UML (версия 1.1) предложена вниманию OMG в июле 1997 года. В сентябре данная версия была утверждена на заседаниях группы по анализу и проектированию и Комитета по архитектуре OMG, а 14 ноября 1997 года принята в качестве стандарта всеми участниками консорциума OMG.

На протяжении последующих лет специальная рабочая группа OMG (OMG Revision Task Force) поддерживала продвижение проекта UML. Одна за другой создавались версии 1.3, 1.4 и 1.5. За 2000–2003 годы новая, расширенная группа участников проекта создала модернизированную версию UML 2.0. Эта версия рассматривалась в течение года рабочей группой Finalization Task Force (FTF), а в начале 2005 года члены OMG утвердили официальную версию UML 2.0. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD. Последняя версия UML 2.5 опубликована в июне 2015 года.

В стандарте UML предусмотрен следующий набор диаграмм:

• Структурные (structural) модели:

диаграммы классов (class diagrams) -- для моделирования статической структуры классов системы и связей между ними;

диаграммы компонентов (component diagrams) — для моделирования иерархии компонентов (подсистем) системы;

диаграммы размещения (deployment diagrams) — для моделирования физической архитектуры системы.

• Модели поведения (behavioral):

диаграммы вариантов использования (use case diagrams) — для моделирования бизнес-процессов и функциональных требований к создаваемой системе;

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

диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams) — для моделирования процесса обмена сообщениями между объектами;

диаграммы состояний (statechart diagrams) — для моделирования поведения объектов системы при переходе из одного состояния в другое;

2.1. Диаграммы вариантов использования

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

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

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

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

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

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

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

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

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

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

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