Введение в UML Узенцова Наталия © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018
План лекции • • Диаграмма прецедентов Диаграмма классов Диаграмма последовательности Диаграмма деятельности © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 2
Моделирование прецедентов Форма выработки требований Этапы моделирования: • Устанавливаются границы потенциальной системы. • Выявляются актеры. • Выявляются прецеденты: – определяется прецедент; – устанавливаются основные альтернативные потоки. • Предыдущие шаги повторяются, пока прецеденты, актеры и границы системы не стабилизируются. © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 3
Диаграмма прецедентов (Use Case) Компоненты: Граница системы – прямоугольник, очерчивающий прецеденты для обозначения края, или границы, моделируемой системы. В UML 2 эту границу называют контекстом системы (subject). Актеры – роли, выполняемые людьми или сущностями, использующими систему. Прецеденты – то, что актеры могут делать с системой. Отношения – значимые отношения между актерами и прецедентами. © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 4
Идентификация актеров • • Кто или что использует систему? Какие роли они играю во взаимодействии? Кто устанавливает систему? Кто или что запускает и выключает систему? Кто обслуживает систему? Какие системы взаимодействуют с данной системой? Кто или что получает и предоставляет информацию систем Происходит ли что-нибудь в точно установленное время? © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 5
Главные моменты при создание актера • Актеры всегда являются внешними по отношению к системе, следовательно, находятся вне вашего контроля. • Актеры взаимодействуют непосредственно с системой – так они помогают в определении контекста системы. • Актеры представляют роли, исполняемые людьми или сущностями по отношению к системе, а не конкретных людей или сущностей. • Один человек или сущность может играть по отношению к системе множество ролей одновременно или последовательно во времени. • У каждого актера должно быть короткое, осмысленное с прикладной точки зрения имя. • Каждого актера должно сопровождать краткое описание (одна или две строчки), объясняющее, что данный актер из себя представляет с прикладной точки зрения. © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 6
Идентификация прецедентов • Какие функциональные возможности понадобятся конкретному актеру от системы? • Система сохраняет и извлекает информацию? Если да, какой из актеров инициирует это поведение? • Что происходит, когда система изменяет состояние (например, при запуске и выключении системы)? Кто-нибудь из актеров получает при этом уведомление? • Какие-либо внешние события оказывают влияние на систему? Как система узнает об этих событиях? • Система взаимодействует с какой-либо внешней системой? • Система генерирует какие-либо отчеты? © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 7
Пример Use Case диаграммы © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 8
Диаграмма классов (class diagram) Служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Минимальная форма класса включает в себя следующее: • Имя – обязательно. • Атрибуты – имена атрибутов являются обязательными, хотя на начальном этапе могут моделироваться только важные предполагаемые атрибуты. • Операции – в анализе операции могут быть всего лишь очень приблизительными формулировками обязанностей класса. Параметры и возвращаемые типы операций приводятся только в том случае, если они важны для понимания модели. • Видимость – обычно не указывается. • Стереотипы – могут указываться, если они приводят к улучшению модели. • Помеченные значения – могут указываться, если они улучшают модель. © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 9
Диаграмма классов (class diagram) © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 10
Диаграмма классов (class diagram) Подклассы наследуют все возможности своих надклассов. Наследуют: атрибуты; операции; отношения; ограничения. © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 11
Диаграмма классов (class diagram) Агрегация – это отношение целое-часть. Семантику агрегации можно подытожить следующим образом: • агрегат может существовать как независимо от частей, так и вместе с ними; • части могут существовать независимо от агрегата; • агрегат является в некотором смысле неполным в случае отсутствия некоторых частей; • части могут принадлежать одновременно нескольким агрегатам. © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 12
Диаграмма классов (class diagram) Композиция – более строгая форма агрегации. • Резюмировать семантику композиции можно следующим образом: одновременно части могут принадлежать только одному композиту – совместное владение частями невозможно; • композит обладает исключительной ответственностью за все свои части; это означает, что он отвечает за их создание и уничтожение; • композит может высвобождать части, передавая ответственность за них другому объекту; • в случае уничтожения композита он должен или уничтожить все свои части, или передать ответственность за них другому объекту. © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 13
Диаграмма последовательности (sequence diagram) Представляет взаимодействия между линиями жизни как упорядоченную последовательность событий. Это самая гибкая форма диаграммы взаимодействий. © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 14
Диаграмма последовательности (sequence diagram) © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 15
Диаграмма последовательности (sequence diagram) © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 16
Диаграммы деятельности (activity diagram) Позволяют моделировать процесс как деятельность, которая состоит из коллекции соединенных ребрами узлов © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 17
Диаграммы деятельности (activity diagram) Узлы управления © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 18
Q&A © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 19
Спасибо! © 2010 Net. Cracker Technology Corp. Confidential. 2/8/2018 20