1 Объектно-ориентированное проектирование Самое лучшее средство

1 Объектно-ориентированное проектирование Самое лучшее средство – это большая диаграмма, приколотая к стене. Даг Скотт

2 Преимущества использования объектно-ориентированного подхода Кодирование составляет небольшую часть разработки программного обеспечения Оценка временных затрат, в % 35% Спецификация, разработка 20% Кодирование, отладка 30% Тестирование, корректировка, фиксация 15% Оформление документации, поддержка Объектно-ориентированный подход облегчает другие составляющие разработки программных систем

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

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

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

6 Важнейшие понятия объектного подхода Инкапсуляция; Наследование; Полиморфизм.

7 Инкапсуляция - сокрытие данных и методов в качестве собственных ресурсов объекта

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

9 Наследование Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов.

10 §1. Понятие ОО проектирование

11 Жизненный цикл ПО (каскадная модель): Анализ требований Проектирование Реализация Тестирование и отладка Сопровождение, эксплуатация

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

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

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

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

16 Так как построение моделей крайне важно при проектировании сложных систем, объектно-ориентированное проектирование предлагает богатый выбор моделей, которые представлены на рис.

17 Перечень областей, для которых реализованы объектно-ориентированные системы

18 §2. Основные сведения о языке UML Методология объектно-ориентированного анализа и проектирования реализуется с использованием унифицированного языка моделирования Unified Modeling Language (UML)

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

20 Разрабатывается с 1994 г. Объединяет средства представления трех ведущих объектно-ориентированных методов: OMT (Джеймс Рамбо) OOSE (Ивар Якобсон) Booch (Гради Буч) Является промышленным стандартом Обладает многими полезными свойствами и большой коллекцией изобразительных средств Содержит множество диаграмм

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

22 Мотивация применения UML Увеличиваются объемы и сложность программных систем (трудно анализировать) Необходимо документировать разработку программных систем (трудно) UML является графической моделью программной системы (наглядность) Существуют CASE – средства для генерации и анализа UML – моделей и на основе этих моделей разрабатываются программные системы (автоматизация кодирования).

23 Модель проекта представляет собой совокупность подмоделей структуры и поведения Каждая подмодель представлена набором диаграмм Подмодели согласованы между собой Модель проекта:

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

25 Контроль качества Концепции Rational Software Ink. предполагают объективно осуществляемое управление качеством Оценка качества всех действий и их участников выполняется с использованием объективных измерений и критериев Испытание (тестирование) качества производится на всех итерациях жизненного цикла

26 Структурные диаграммы Диаграммы, моделирующие динамику Варианты использования

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

28 §3. Диаграммы вариантов использования (use case) или диаграммы прецедентов Понятие варианта использования (use case) впервые ввел Ивар Якобсон. Вариант использования (use case) представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом) – на диаграмме отображается овалом.

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

Пример диаграммы вариантов использования для банкоматов

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

Правила разработки диаграмм use case Не моделируйте связи между actors; Не соединяйте стрелкой два варианта использования непосредственно; Сплошная стрелка (коммуникационная связь) должна начинаться на actor и заканчиваться на варианте использования (вариант использования должен быть инициирован действующим лицом). 32

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

Поток событий включает: Краткое описание; Предусловия; Основной поток событий; Альтернативный поток событий (один или несколько); Постусловия.

Основной поток событий для варианта использования «Снять деньги со счёта» Клиент вставляет карточку в АТМ. АТМ запрашивает код. Клиент вводит код. АТМ подтверждает код. Если код не подтверждён, выполняется альтернативный поток событий А1. АТМ выводит список доступных действий: Положить деньги на счёт; Снять деньги со счёта; Перевести деньги.

Клиент выбирает «Снять деньги». АТМ запрашивает сумму. Клиент вводит требуемую сумму. АТМ определяет, достаточно ли денег на счету. Если недостаточно, выполняется альтернативный поток событий А2. АТМ вычитает сумму из счёта клиента. АТМ выдаёт сумму наличными. АТМ возвращает клиенту карточку. АТМ печатает чек для клиента.

Альтернативный поток А1 1. АТМ информирует клиента, что идентификационный номер введён неправильно. 2. АТМ возвращает клиенту его карточку. 3. Вариант использования завершается. Альтернативный поток А2 1. АТМ информирует клиента, что денег на его счету недостаточно. 2. АТМ возвращает клиенту его карточку. 3. Вариант использования завершается.

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

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

Связи включения и расширения

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

Диаграмма вариантов использования для торговой системы

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

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

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

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

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

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

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

52 Диаграмма классов определяет типы классов системы и различного рода статические связи, которые существуют между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами. §5.Диаграмма классов на UML

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

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

Каждому атрибуту соответствует отдельная строка: <квантор видимости><имя атрибута>: <тип атрибута> = [<исходное значение>] Квантор видимости: "+" ─ (public) атрибут с областью видимости общедоступный. Такой атрибут доступен из любого другого класса пакета, в котором определен данный класс. "#" ─ (protected). атрибут с областью видимости защищенный. Атрибут недоступен для всех классов, за исключением подклассов данного класса. "-" ─ атрибут с областью видимости закрытый (private). Атрибут недоступен для всех классов без исключения. (Package or Implementation) пакетный - атрибут является общедоступным, но только в пределах его пакета и никак не обозначается.

Вместо условных графических обозначений можно просто записывать ключевое слово public, protected, private или Package or Implementation. Тип атрибута определяется в зависимости от языка программирования, который предполагается использовать для реализации данной модели. Каждой операции соответствует отдельная строка: <квантор видим.><имя операции>([список параметров]): [тип возвращаемого значения]

Окно # Видимость: Булево + Ширина: Целое + Высота: Целое + Показать() + Переместить() + Спрятать() Графическое изображение оконного класса

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

2) Операции управления управляют созданием и уничтожением объектов. В эту категорию попадают конструкторы и деструкторы классов. 3) Операции доступа Атрибуты обычно бывают закрытыми или защищенными. Тем не менее, другие классы иногда должны просматривать или изменять их значения. Для этого существуют операции доступа. Создание общих операций Get и Set (получения и изменения значения) для каждого атрибута класса является стандартом.

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

Чтобы идентифицировать операции, выполните следующие действия: 1. Изучите диаграммы последовательности и кооперативные диаграммы. Большая часть сообщений на этих диаграммах является операциями реализации. Рефлексивные сообщения будут вспомогательными операциями. 2. Рассмотрите управляющие операции. Может потребоваться добавить конструкторы и деструкторы. 3. Рассмотрите операции доступа. Для каждого атрибута класса, с которым должны будут работать другие классы, надо создать операции Get и Set.

5.2. Стереотипы классов Стереотипы – это механизм, позволяющий разделять классы на категории. В языке UML определены три основных стереотипа классов: Boundary (граница, интерфейс); Entity (сущность); Control (управление).

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

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

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

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

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

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

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

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

Ассоциацию можно определить и на единственном классе (унарная ассоциация):

Кратность ассоциации показывает, сколько экземпляров одного класса взаимодействуют с помощью этой связи с одним экземпляром другого класса в данный момент времени. Кратность ассоциации определяется кардинальными числами, которые записываются в форме строки в квадратных скобках : [нижняя_граница .. верхняя_граница] Либо в виде одного числа: 1 – кратность равна 1, * - любое неотрицательное целое число. По умолчанию кратность = 1.

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

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

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

Примеры различных видов отношений

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

Отношение зависимости Отношение зависимости является наиболее общей формой отношения, которое используется, когда изменение одного элемента модели может потребовать изменения другого зависимого от него элемента. Графически оно изображается пунктирной линией со стрелкой, направленной к независимому элементу.

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

В свернутой форме интерфейс представляют в виде небольшого круга и линии, соединяющей его с элементом, реализующим данный интерфейс. На рис. показан компонент в виде динамически компонуемой библиотеки srch.dll, реализующий тот же самый интерфейс ISearch. Таким образом, интерфейс позволяет связать логическую модель системы (классы, объекты) с физической (файлы, компоненты).

Диаграмма классов для варианта использования «Снять деньги»

85 Связи между классами (пиктограммы) Ассоциация Постоянное, структурное отношение, “has a” Непрерывная линия со стрелкой (в случае направленности ассоциации) Зависимость Временное отношение, “uses a” Пунктирная линия со стрелкой Обобщение Наследование, “is a” Непрерывная линия со стрелкой (треугольной) Реализация Пунктирная линия со стрелкой (треугольной) OR

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

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

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

Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. Другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования.

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

Диаграмма пакетов

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

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

Пример диаграммы состояний для банковского счета:

На диаграмме имеются два специальных состояния – начальное и конечное. С состоянием можно связывать данные пяти типов: деятельность, входное действие, выходное действие, событие и история состояния. Рассмотрим каждый из них в контексте диаграммы состояний для класса Account системы ATM.

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

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

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

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

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

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

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

Действие Действием является непрерываемое поведение, осуществляющееся как часть перехода. Например, при переходе счета из открытого в закрытое состояние выполняется действие «Сохранить дату закрытия счета». Это непрерываемое поведение осуществляется только во время перехода из состояния «Открыт» в состояние «Закрыт». Действие рисуют вдоль линии перехода после имени события, ему предшествует косая черта.

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

Состояния и переходы жизненного цикла объекта

Состояния и переходы жизненного цикла технического устройства

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

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

Диаграмма компонентов дли клиента АТМ

Например, класс ATM screen преобразуется в компонент ATM Screen диаграммы. Он преобразуется также и во второй компонент ATM Screen. Вместе эти два компонента представляют тело и заголовок класса ATM Screen. Выделенный темным компонент называется спецификацией пакета и соответствует файлу тела класса ATM Screen на языке C++ (файл с расширением .СРР). Невыделенный компонент также называется спецификацией пакета, но соответствует заголовочному файлу класса языка С++ ((файл с расширением .Н). Компонент ATM.exe является спецификацией задачи и представляет поток обработки информации. В данном случае поток обработки является исполняемой программой.

Компоненты соединены штриховой линией, что соответствует зависимостям между ними. Например, класс Card Reader зависит от класса ATM Screen. Это означает, что, для того, чтобы класс Card Reader мог быть скомпилирован, класс ATM Screen должен уже существовать. После компиляции всех классов может быть создан исполняемый файл ATMClient.exe.

Диаграмма Компонентов для сервера АТМ

АТМ содержит два потока обработки и, таким образом, получаются два исполняемых файла: клиент АТМ и сервер ATM, включающий в себя компонент Account. Как видно, у системы может быть несколько диаграмм компонентов, в зависимости от числа подсистем или исполняемых файлов. Каждая подсистема является пакетом компонентов. В общем случае, пакеты – это совокупности компонентов. Пример АТМ содержит два пакета: клиент АТМ и сервер АТМ.

Диаграммы размещения Диаграмма размещения отражает физические взаимосвязи между программными и аппаратными компонентами системы. Она является хорошим средством для того, чтобы показать маршруты перемещения объектов и компонентов в распределенной системе. Диаграмма размещения показывает физическое расположение сети и местонахождение в ней различных компонентов. В нашем примере система АТМ состоит из большого количества подсистем, выполняемых на отдельных физических устройствах, или узлах.

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

118 Программные средства, реализующие нотацию UML Rational Unified Process – гипертекстовая база знаний; Rational Rose – CASE средство объектного моделирования; SoDA - инструмент автоматизации документооборота моделирования; Requisite PRO – инструмент управления требованиями; ClearQuest - средство управления запросами на изменение .

119 Общая платформа группы ClearQuest RequisitePro Rational Rose Главная БД БД пользователей Коллективная БД Документы БД пользователя Rational Test БД Rational Test БД RequisitePro Rational SoDA Документы Word Репозиторий. Правила синхронизации

120 Поддержка потоков работ средствами Rational Suite

121 Инструменты для аналитиков. Rational Rose (Modeler Edition) Обеспечивает возможность визуального моделирования архитектуры и компонентов c использованием соответствующего промышленным стандартам Унифицированного языка моделирования (UML).

122 Инструменты для разработчиков. Rational Rose (Modeler Edition) Обеспечивает возможность визуального моделирования архитектуры и компонентов Автоматически создает каркас кода для Java, C++, XML и др. языков Автоматически поддерживает взаимодействие между Requisite Professional и SoDa

123 Общая платформа группы. Rational SoDA Автоматически генерирует документы, извлекая информацию из файлов, которые производятся при разработке проекта, включая исходный код и модели, произведенные инструментами Rational. Форматирует информацию согласно предопределенным шаблонам.

124 Графический интерфейс пользователя Rational Rose

125 Пример Java программы Class Helloworld{ Public static void main {String [] args { Systemout.println (“Hello, XXI Century World”); } }

126 От UML диаграммы классов  к Java коду Различное представление одинаковой информации: Имя, состояние, поведение класса Отношения между классами Обеспечение возможности перенести одно на другое UML  Java Генерация кода, основанного на UML-модели Java  UML Создание UML-модели для документирования разрабатываемого кода

127 Java  UML : Пример class Clock { // name // state private int seconds; private int minutes; private int hours; // behavior public void start(); public void adjustTime(int value); public void reset(); } Java Code Class Diagram

128 Диаграмма классов Представление структуры класса General In Java Name Name State Variables Behavior Methods

129 Зависимость Зависимость может быть вызвана локальной переменной параметром возвращаемым значением Пример Class A { Class B { B Foo(B x) { … B y = new B(); … return y; … } } }