- •Структура uml. Строительные блоки uml. Общие механизмы uml. Архитектура языка.
- •Унифицированный процесс разработки (up). Аксиомы up (итерация и инкремент). Структура up. Фазы up.
- •Метамодель требований предъявляемых к по. Моделирование прецедентов.
- •Обобщение актеров. Обобщение прецедентов. Отношения «include» и «extend».
- •Выявление классов анализа. Деятельность up: анализ прецедента. Основные и альтернативные потоки анализа прецедента.
- •Отношения между: а) актерами и прецедентами б) прецедентами и прецедентами (обобщение, «include» и «extend») в) актерами и актерами (обобщение).
- •Архитектурный анализ. Пакеты и пространства имен. Вложенные пакеты. Зависимости пакетов.
- •Вложенные пакеты:
- •Реализация прецедентов. Элементы прецедента. Взаимодействия. Линии жизни. Сообщения. Диаграммы взаимодействия (коммуникационные диаграммы).
- •Диаграммы взаимодействий.
- •Проектирование класса, атрибуты, операции. Наследование, шаблоны, вложенные классы.
- •Отношения уровня проектирования. Агрегация и композиция.
- •Отношения классов уровня анализа. Ассоциации: один-к-одному, один-ко-многим, многие-к-одному, многие-ко-многим.
- •Подсистемы. Подсистемы и интерфейсы. Шаблон «Facade».
- •Трехуровневая архитектура системы (схема архитектуры). Преимущества и недостатки интерфейсов.
- •Диаграммы взаимодействия при проектировании прецедента (добавить курс «uml» в бд ).
- •Диаграммы состояний объекта.
Вложенные пакеты:
• внутренний пакет может видеть все открытые члены своих внешних пакетов;
• если между внешним пакетом и членами его внутренних паке тов не установлена явная зависимость (обычно «access» или «import»), он не может видеть члены своих внутренних пакетов; это обеспечивает возможность скрывать детали реализации во вложенных пакетах.
Отношение зависимости между пакетами указывает на то, что клиентский пакет некоторым образом зависит от пакета поставщика.
• «use» – элемент клиентского пакета использует открытый элемент пакета поставщика.
• «import» – открытые элементы пространства имен поставщика добавляются как открытые элементы в пространство имен клиента. Элементы клиента имеют доступ ко всем открытым элементам поставщика через неполные имена.
• «access» – открытые элементы пространства имен поставщика добавляются как закрытые элементы в пространство имен клиента. Элементы клиента имеют доступ ко всем открытым элементам поставщика через неполные имена.
• «trace» – клиент является историческим развитием поставщика. Это отношение обычно применяется к моделям, а не к элементам.
• «merge» – открытые элементы пакета поставщика объединяются с элементами клиентского пакета. Используется только при разработке метамоделей.
Реализация прецедентов. Элементы прецедента. Взаимодействия. Линии жизни. Сообщения. Диаграммы взаимодействия (коммуникационные диаграммы).
Реализация прецедентов – важнейшая часть процесса анализа. Она позволяет сравнить теорию с практикой, явно демонстрируя, как могут взаимодействовать объекты классов для обеспечения заданного поведения системы. Диаграммы взаимодействий показывают, как классы и объекты реализуют требования, определенные в прецеденте.
Взаимодействия – это единицы поведения контекстного классификатора. Взаимодействия могут использовать любые возможности контекстного классификатора.
Линия жизни представляет участника взаимодействия – то, как экземпляр классификатора участвует во взаимодействии.
• Каждая линия жизни имеет необязательное имя, тип и необязательный селектор.
• Все линии жизни обозначаются той же пиктограммой, что и их тип.
• Экземпляры обозначаются путем подчеркивания имени, типа и селектора.
Сообщение представляет конкретный тип соединения между двумя взаимодействующими линиями жизни.
• Синхронное сообщение (сплошная стрелка).
• Асинхронное сообщение (открытая стрелка).
• Возврат (открытая стрелка, пунктирная линия).
• Сообщение создания (открытая стрелка, сплошная линия, стереотип «create»).
• Сообщение уничтожения (открытая стрелка, сплошная линия, стереотип «destroy»).
• Найденное сообщение (открытая стрелка, исходящая из заштрихованного кружка).
• Потерянное сообщение (открытая стрелка, заканчивающаяся в заштрихованном кружке).
Диаграммы взаимодействий.
• Диаграммы последовательностей – акцентируют внимание на временной упорядоченности сообщений.
• Коммуникационные диаграммы – акцентируют внимание на структурных отношениях между объектами.
• Диаграммы обзора взаимодействий – акцентируют внимание на отношениях между взаимодействиями.
• Временные диаграммы – акцентируют внимание на реальном времени взаимодействий.
Диаграммы деятельности в контексте к: а)прецедентам б)классам в)интерфейсам.
Диаграммы деятельности – это ОО блок схемы:
• они используются для моделирования всех типов процессов;
• диаграммы деятельности можно создать для любого элемента модели для описания его поведения;
• хорошая диаграмма деятельности описывает один конкретный аспект поведения системы;
• в UML 2 диаграммы деятельности имеют семантику технологии сетей Петри.
Синтаксис типов узлов действия: действие, сигнал, событие, событие времени. Синтаксис узлов управления: начальный и конечный поток; расширение, слияние, ветвление, объединение.
Категории узлов:
• узлы действия – элементарные единицы работы в рамках деятельности;
• узлы управления – управляют потоком деятельности;
• объектные узлы – представляют объекты, используемые в деятельности.
Узлы действия
Узлы управления:
Диаграмма деятельности. Примеры: а)обработки прерываний б)обработка исключений.
Диаграммы деятельности часто называют «ОО блок_схемами». Они позволяют моделировать процесс как деятельность, которая состоит из коллекции соединенных ребрами узлов.
Области с прерываемым выполнением действий – это области деятельности, прерываемые при прохождении маркера по прерывающему ребру. Когда область прерывается, все ее потоки немедленно прекращаются. Области с прерываемым выполнением действий полезны для моделирования прерываний и асинхронных событий.
Современные языки программирования часто обрабатывают ошибки посредством механизма, называемого обработкой исключений (excep+ tion handling). В случае выявления ошибки в защищенной части кода создается объект исключения. Поток управления переходит в обработчик исключения, который некоторым образом обрабатывает объект исключения. В этом объекте исключения содержится информация об ошибке, которая может использоваться обработчиком исключения. Обработчик исключения может прервать приложение или попытаться
восстановить нормальное состояние. Часто информация объекта исключения сохраняется в журнале регистрации ошибок.