Конспект по курсу. Объектно ориентированный анализ и проектирование (1133667), страница 5

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

Текст из файла (страница 5)

Во второй модели тройка объектов лекторПетров, семестрСедьмой и курсЛекцийМатан могут быть соединены более чем единожды посредством разных экземпляров класса ЧитаемыйКурс.

П олюса ассоциаций с мощностью «много» имеют еще две характеристики: упорядоченность связываемых объектов и повторяемость (т. е. образуют ли связываемые объекты множество или мультимножество). Различные сочетания этих характеристик образуют четыре типа полюсов: множества {set} (тип полюса по умолчанию), упорядоченные множества {ordered}, мультимножества {bar} и последовательности {sequence}:

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

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

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

• в сигнатуре операции одного класса есть аргумент – объект другого класса;

• в методе одного класса есть локальный объект другого класса;

• результатом операции одного класса является экземпляр другого класса.

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

Общие атрибуты, операции и/или отношения отображаются на верхнем уровне иерархии. Заметим, что ассоциации класса-предка наследуются классами потомками, т. е. экземпляры потомков могут иметь соединения того же рода, что и экземпляры родительского класса. Действует принцип подстановки Лисковой (Liskov substitution principle LSP), по которому любое утверждение, справедливое для экземпляров класса, сохраняет справедливость для экземпляров всех его подклассов. Например, из LSP следует, что экземпляр подкласса подкласса (класса «внука») может рассматриваться как экземпляр подкласса или экземпляр исходного класса (своего «деда»).

В объектной модели наследование может быть множественным. На связи могут накладываться ограничения. Например, если необходимо, множественное наследование в некоторой иерархии классов может быть запрещено (над связью указывается ключевое слово: {disjoint}).

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

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

Литература к лекции 2

1. Буч Г. Объектно-ориентированный анализ и проектирование с примерами приложений. 3-е изд. – М.: Вильямс, 2008. – Часть I.

2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. – Глава 2.

3. Рамбо Дж., Блаха М. UML 2.0. Объектно-ориентированное моделирование и разработка. 2-е изд. – СПб.: Питер, 2006. – Главы 2-3.

4. Грэхем И. Объектно-ориентированные методы. Принципы и практика. 3-е изд.: Пер. с англ. – М.: Вильямс, 2004. – Глава 1.

Лекция 3. Унифицированный язык моделирования (Unified Modelling Language)

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

UML является наследником методов объектно-ориентированного анализа и проектирования, появившихся в конце 1980-х и начале 1990-х годов. Создание UML началось в конце 1994 г., с объединения методов Booch и OMT (Object Modeling Technique) под эгидой компании Rational Software. К концу 1995 г. Гради Буч и Джеймс Рамбо создали первую спецификацию Unified Method, версия 0.8. Тогда же в 1995 г. к ним присоединился создатель метода OOSE (Object-Oriented Software Engineering) Ивар Якобсон. UML является унификацией методов Буча, Рамбо и Якобсона а также суммой передового опыта по разработке ПО:

Разработка UML преследовала следующие цели:

• предоставить разработчикам единый язык визуального моделирования;

• предусмотреть механизмы расширения и специализации языка;

• обеспечить независимость языка от языков программирования и процессов разработки;

• интегрировать накопленный практический опыт.

UML широко используется в индустрии ПО. Практически все мировые производители CASE-средств поддерживают UML в своих продуктах. В 1997 году Object Management Group (OMG) приняла стандарт UML 1.1. В 2004 году был пройден следующий важный этап – принят стандарт UML версии 2.0. В настоящее время UML проходит процесс стандартизации ISO. Текущая версия UML – 2.1.2.

Основные «строительные блоки» UML:

• элементы модели (классы, интерфейсы, компоненты, варианты использования и др.);

• связи (ассоциации, обобщения, зависимости и др.);

• механизмы расширения (стереотипы, ограничения, примечания, именованные значения);

• диаграммы.

Состав диаграмм UML 1.х:

• структурные:

• диаграммы классов, моделирующие статическую структуру классов системы и связи между классами;

• диаграммы компонентов, моделирующие иерархии компонентов ПО;

• диаграммы размещения, моделирующие физическую архитектуру системы;

• поведенческие:

• диаграммы вариантов использования, моделирующие бизнес-процессы и требования к ПО;

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

• диаграммы состояний, моделирующие поведение объектов;

• диаграммы деятельности, моделирующие поведение системы в целом и потоки управления.

В UML 2.0 введены новые типы диаграмм, которых ранее не было: диаграммы обзора взаимодействия, временные диаграммы и диаграммы составных структур.

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

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

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

В диаграммах вариантов использования может присутствовать несколько типов связей:

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

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

• связи расширения (пунктирная линия со стрелкой, соединяющая вариант – особый случай – с базовым вариантом использования);

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

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

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

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

Каждое сообщение может быть описано в таком формате:

[сторожевое условие] *[повторение] номер : переменная := операция (аргументы)

[сторожевое условие] – сообщение посылается только при выполненном условии, при невыполненном не посылается;

Характеристики

Список файлов лекций