Методические указания. МУ К ПЗ ТРПО ПКС. Методические указания по выполнению практических работ учебной дисциплины мдк 03. 01 Технология разработки программного обеспечения
 Скачать 5.82 Mb.
|
|
Тема 1. 2. Основы проектирования программных систем Практическое занятие 3. Тема: Управление процессом разработки программных систем средствами MS Project. Цель работы: приобретение навыков визуализации информации с помощью диаграмм; расширение навыков построения нестандартных диаграмм в среде электронных таблиц и применение средств деловой графики. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа MS Project, программа MS Excel, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Диаграмма Ганта – это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов, представляет собой изображение календарного графика задач в проекте. График Ганта является своеобразным стандартом в области управления проектами, ведь именно с его помощью появляется возможность показать структуру выполнения всех этапов проекта наглядно. Диаграммы Ганта позволяет: - визуально оценить последовательность задач, их относительную длительность и протяженность проекта в целом; - сравнить планируемый и реальный ход выполнения задач; - детально проанализировать реальный ход выполнения задач. Диаграмма даёт возможность решить одну из основных задач и показать персоналу, над чем следует работать, какие ресурсы применять в процессе и с какой скоростью выполнять те или иные задачи. Вся информация подаётся в сжатом виде, без использования запутанных таблиц и огромного количества текста. При этом суть ясна и понятна всем, без исключения, участникам проекта. Использование диаграммы значительно упрощает управление проектами небольших масштабов и даёт возможность всегда держать деятельность сотрудников под контролем. Диаграмма Ганта состоит из полос, ориентированных вдоль оси времени. Каждая полоса на диаграмме представляет отдельную задачу в составе проекта (вид работы), её концы - моменты начала и завершения работы, её протяженность - длительность работы. Вертикальной осью диаграммы служит перечень задач. Кроме того, на диаграмме могут быть отмечены совокупные задачи, проценты завершения, указатели последовательности и зависимости работ, метки ключевых моментов (вехи), метка текущего момента времени «Сегодня» и др. Диаграмма может использоваться для представления текущего состояния выполнения работ: часть прямоугольника, отвечающего задаче, заштриховывается, отмечая процент выполнения задачи; показывается вертикальная линия, отвечающая моменту «сегодня». Часто диаграмма Ганта соседствует с таблицей со списком работ, строки которой соответствуют отдельно взятой задаче, отображенной на диаграмме, а столбцы содержат дополнительную информацию о задаче. Пример такой таблицы представлен ниже.  В электронном виде диаграмма Ганта строится с помощью таких средств, как: MS Project, MS Visio, Primavera и прочее. Разумеется, существует множество других, более совершенных программ, облегчающих управление проектами. Диаграмма Ганта любой сложности может быть легко построена с помощью таких приложений, как: SchedRoll; Gantt Designer; Mindjet JCVGantt Pro; и многих других. Кроме того, существует целый ряд онлайн-сервисов, которые предоставляют своим пользователям возможность не только планировать свои дела, но и получать регулярные отчёты, уведомления о текущем статусе задач по электронной почте. Рассмотрим основные принципы построения диаграммы: Графически задачи отображаются сверху вниз слево направо. Задача может состоять из нескольких подзадач, но не менее 2-х (на графике (Задача 4. Разработка ПО и ее подзадачи 4.1. и 4.2.). Задачи могут выполняться последовательно (Задачи 1. и 2.) и параллельно (Задачи 2. и 3.). Загруженность исполнителей ставится с учетом выполнения работ во времени (Обратите внимание на Задачи 2. и 3.). Этапы календарного планирования 1) Определение основных этапов проекта. Как правило, выделяется минимум три этапа проекта. Этапы можно обозначить, руководствуясь следующими принципами: a. По времени – делить на примерно равные временные промежутки; b. По характеру работ – делить проект на различные блоки работ, отличные друг от друга по содержанию и характеру; c. По результатам – выделить значимые, измеряемые результаты. 2) Декомпозиция этапов на меньшие и конкретные работы (задачи). Если возможно, то максимально подробно, если нет – руководствуйтесь принципами из пункта 1, то есть, разделите каждый этап как минимум еще на 3 задачи. 3) Определение последовательности работ. 4) Определение логических связей. Могут быть ограничения, например, невозможно начать выполнять задачу, не закончив предыдущую, либо не закончив три предыдущих задачи одного блока. 5) Спланировать сроки выполнения задач с построением диаграммы Ганта, диаграмма будет рассмотрена ниже. 6) Определение потребности в ресурсах: a. людские ресурсы - определить ответственных по каждой задаче; b. машины и механизмы; c. помещения; d. материалы и так далее. 7) Определение стоимости ресурсов и трудозатрат. 8) Оптимизация диаграммы Ганта с учетом загрузки ресурсов. Например, первоначально вы не знали, кого назначите выполнять две параллельные задачи, а потом оказалось, что их может выполнить одно должностное лицо и никак иначе, соответственно, эти задачи станут последовательными. Оптимизация диаграммы Ганта: 1) Рассмотрите возможность выполнения задач параллельно. 2) Определите крайние точки проекта и отдельных задач. 3) Установите связи для последовательных задач. 4) Задачи, которые можно сделать позже передвиньте в конец. 5) Определите критичный путь – последовательность задач, которая определяет длительность проекта, и рассмотрите каждую на возможность сокращения по времени. Основные достоинства и недостатки описанного метода планирования и управления. Главным преимуществом является графическая подача материала. Удобство работы с графиками Ганта – возможность чётко выделить и обозначить этапы работы над проектом и одновременное отображение мероприятий и сроков их выполнения. За счёт представления заданий в виде различных цветных полос все члены команды могут буквально с первого взгляда определить свои задачи. Диаграммы Ганта являются отличным презентационным инструментом, который способен продемонстрировать ключевые приоритеты проекта. То есть, как только руководящие лица выделяют и распределяют каждый из имеющихся в наличии ресурсов, команда моментально узнаёт об этом и следует дальнейшим указаниям. Данное свойство графика Ганта крайне полезно для руководителей высшего звена – используя его, можно намного проще подготовить подробный, ёмкий отчёт о состоянии выполнения различных проектов. Тем не менее, как и у любого другого метода планирования, у диаграммы Ганта есть свои недостатки. Ключевым понятием диаграммы Ганта является «Веха» - метка значимого момента в ходе выполнения работ, общая граница двух или более задач. Вехи позволяют наглядно отобразить необходимость синхронизации, последовательности в выполнении различных работ. Вехи, как и другие границы на диаграмме, не являются календарными датами. Сдвиг вехи приводит к сдвигу всего проекта. Поэтому диаграмма Ганта не является, строго говоря, графиком работ. И это один из основных её недостатков. Кроме того, диаграмма Ганта не отображает значимости или ресурсоемкости работ, не отображает сущности работ (области действия). Для крупных проектов диаграмма Ганта становится чрезмерно тяжеловесной и теряет всякую наглядность. Недостатком является зависимость задач. Довольно часто в процессе презентации проектов у руководителей возникает необходимость показать, какие из указанных заданий связаны друг с другом. Но, к сожалению, сам формат диаграммы не позволяет сделать этого. Для того чтобы обойти это ограничение, менеджеры прибегают к различным хитростям: например, добавляют в график специальные вертикальные линии, которые демонстрируют ключевые зависимости. Однако это лишь временное решение, не способное передать информацию в полном объёме. Ещё одним минусом графиков Ганта можно назвать их негибкость. В наши дни проекты не являются статичными – в них постоянно происходят какие-то изменения, сдвиги, учесть которые в диаграмме просто невозможно. Прежде чем приступать к построению графика, руководителям приходится просчитывать всё до мелочей, ведь при малейшем изменении оценки нужно перерисовывать «с нуля» всю диаграмму. И это не говоря уже о том, что возможность проиллюстрировать несколько разных способов планирования за один раз также отсутствует. Вне зависимости от того, зачем вам нужна диаграмма Ганта, программа (даже самая «продвинутая») не сможет отобразить значимость и ресурсоёмкость тех или иных работ, их сущность. А потому для особо масштабных проектов она используется крайне редко. Указанные выше недостатки и ограничения серьёзно ограничивают область применения диаграммы. Тем не менее, в настоящее время диаграмма Ганта является стандартом де-факто в теории и практике управления проектами. В практике управления проектами данный метод чрезвычайно распространён. Календарный план, план-график или диаграмма Ганта после построения становится реальным управленческим инструментом, во-первых, возможно видеть весь проект в виде одной схемы взаимоувязанных задач и не нужно держать в голове, во-вторых, на этом же графике вы отмечаете выполнение задач и видите отклонение от графика. Порядок выполнения работы 1. Выполнить задания. Оформить в отчет. Задание 1. Построение диаграммы Ганта. Стрелочная диаграмма. 1.Нарисуйте таблицу, в левый столбец которой занесите наименования выполняемых мероприятий. Наименования мероприятий следует расставлять сверху вниз в порядке их выполнения. 2.Выберите удобную периодичность контроля над выполнением занесенных в таблицу мероприятий и проставьте ее в верхней строке нарисованной таблицы. В качестве периодичности выполнения работ могут выступать недели, месяцы, кварталы и т.д. 3.В строке каждого мероприятия следует нарисовать стрелку, которая начинается в столбце запланированного срока начала выполнения этого мероприятия, а заканчивается в столбце запланированного срока завершения выполнения рассматриваемого мероприятия. Пример диаграммы Ганта:  Задание 2. 1. Сбор данных. Для того чтобы построить график, понадобятся следующие данные: - координаты всех наборов данных (откуда должен начинаться каждый из столбиков); - название каждого этапа; - продолжительность каждого этапа. Для удобства вписываем их сразу в соответствующие поля таблицы. После того как Вы ввели всю требуемую информацию, можно переходить к созданию самой диаграммы. Важно: проследите за тем, чтобы все форматы данных были указаны правильно: в частности, это касается дат. Особенность диаграммы Ганта в том, что ее столбики начинаются в произвольном месте, в то время как наиболее похожая на нее диаграмма – линейчатая диаграмма начинается с оси. Поэтому мы используем один из самых распространенных трюков с диаграммами – скроем какие-то данные. Создадим таблицу.  Обратите внимание, что не озаглавлены названия этапов, т.е. ячейка А1 пустая. Этот прием позволяет с первого раза в диаграмме определить, где находятся данные, а где подписи к ним. Используем линейчатую диаграмму. Надо брать ее с накоплением, так как нужен второй ряд данных, который и используем в качестве основных данных.  Второй необходимый шаг – это скрытие первого ряда. Для этого делаем его невидимым. Щелкаем на синих данных, правой кнопкой мыши Формат ряда данных/Заливка/Нет Заливки.  По умолчанию данные расположены в порядке снизу вверх. Исправляем это положение - кликаем на ось категорий (подписей) правой кнопкой мыши - Формат оси/Параметры оси/Обратный порядок категорий. Все, основная диаграмма готова, нужно теперь сделать еще кое-какое полезное форматирование: - Убираем легенду. Она просто уже неактуальна для диаграммы Ганта. Выделяем и кнопкой Delete удаляем. - Определяем границы. Excel сам определяет откуда начинаются значения, т.е. на рисунке сверху шкала начинается с первого апреля. Необходимо установить другую дату. Поэтому правой кнопкой мыши на оси дат Формат оси/Параметры оси/Максимальное и минимальное значения. На диаграмме это 3 мая (точнее, 28 апреля, понедельник) и 20 июня. Правда, есть нюанс, в Excel 2007 надо ставить числа в числовом формате. - Ставим недельные шкалы. Там же в параметрах оси, ставим 7 в окне цена основных делений. Вот для чего потребовалось, чтобы первая дата стояла понедельником. Форматируем, добавляем названия диаграммы:  Задание 3. Создание диаграммы Ганта в MS Visio При помощи диаграммы Ганта можно составить расписание задач проекта, а затем отследить его ход. 1.В меню Файл последовательно выберите команды Создать, Расписание, а затем – команду Диаграмма Ганта. 2.На вкладке Дата введите количество задач для начала работы, единицы времени, которые нужно отобразить, и диапазон дат для проекта. ПРИМЕЧАНИЕ. Параметры форматирования можно изменить в любой момент. В меню Диаграмма Ганта выберите команду Параметры, а затем перейдите на вкладку Формат. 3.Замените имена задач по умолчанию именами задач, соответствующими проекту, а также замените даты начала и окончания задач и длительность. 4.В диаграмме Ганта в столбце Название задачи выделите ячейку, содержащую задачу, которую необходимо переименовать, а затем введите новое имя. 5.В диаграмме Ганта выделите ячейку, содержащую дату, которую необходимо изменить, а затем введите новую дату. ПРИМЕЧАНИЕ. Дату для итоговой задачи изменить нельзя. Даты итоговых задач изменяются только при изменении даты одной или нескольких задач, расположенных уровнем ниже итоговой задачи. 6.В диаграмме Ганта выделите ячейку, содержащую длительность, которую нужно изменить, а затем введите новое значение длительности. Используйте следующие сокращения: м - минуты, ч - часы, д - дни и н - недели. ПРИМЕЧАНИЕ. Между числом и сокращением не должно быть пробела. Например, для указания длительности в 5 дней введите 5д. СОВЕТ. Длительность можно также изменить, выделив область задач и перетащив маркер выделения Изображение маркера выделения с правой стороны области задач на новую дату окончания на временной шкале. 7.Добавьте дополнительные задачи в диаграмму Ганта. - Выделите рамку проекта, щелкнув сплошную линию вокруг диаграммы Ганта. - Перетащите вниз маркер выделения Изображение маркера выделения, расположенный по центру нижней части рамки. Будут созданы новые строки задач, заполняющие пространство. - Выделите ячейку Название задачи одной из новых задач, а затем введите имя задачи. СОВЕТ. Положение задач в диаграмме Ганта можно изменить, перетащив строки задач внутри рамки диаграммы. 10.Добавьте вехи в диаграмму Ганта. - Из набора элементов Фигуры диаграммы Ганта перетащите на страницу документа фигуру Веха и поместите ее между задачами, которые предваряет или за которыми следует веха. ПРИМЕЧАНИЕ. При добавлении фигуры Веха в диаграмму Ганта автоматически добавляется строка со значением длительности, равным 0 (нулю). - Введите имя и дату для вехи. СОВЕТ. Задачу в вехе можно изменить, задав значение ее длительности равным 0. Подобным образом можно изменить веху в задаче, задав положительное значение длительности. 11.Создайте зависимости между задачами в диаграмме Ганта. - Сначала выделите область задач или веху, из которых нужно установить связь, а затем нажмите клавишу SHIFT и выделите зависимую задачу или веху. - Щелкните правой кнопкой мыши одну из фигур, а затем в контекстном меню выберите команду Связать задачи. Форма отчета: Диаграмма Ганта с описанием процесса построения. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Литература: 1. Черткова, Е. А. Программная инженерия. Визуальное моделирование программных систем: учебник для СПО / Е. А. Черткова. —2-е изд., испр. и доп. — М.: Издательство Юрайт, 2017. — 168 с. — (Серия: Профессиональное образование). - URL://www.urait.ru Раздел 1. Технология разработки программного обеспечения Тема 1.3. Унифицированный язык моделирования UML Практическое занятие 4. Тема: Построение UML диаграмм средствами MS Visio. Цель работы: изучение основ создания диаграмм на языке UML, получение навыков построения диаграмм. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, MS Visio, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия (Л1: р.2, гл.1, п.1.1-1.3 с. 74-87); изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения Общие сведения о языке UML Язык UML представляет собой общецелевой язык визуального моделирования, который разработан для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения, бизнес-процессов и других систем. Язык UML одновременно является простым и мощным средством моделирования, который может быть эффективно использован для построения концептуальных, логических и графических моделей сложных систем самого различного целевого назначения. В языке UML используется четыре основных вида графических конструкций: ‒ Значки или пиктограммы. Значок представляет собой графическую фигуру фиксированного размера и формы. Примерами значков могут служить окончания связей элементов диаграмм или некоторые другие дополнительные обозначения. ‒ Графические символы на плоскости. Такие двумерные символы изображаются с помощью некоторых геометрических фигур и могут иметь различную высоту и ширину с целью размещения внутри этих фигур других конструкций языка UML. Наиболее часто внутри таких символов помещаются строки текста, которые уточняют семантику или фиксируют отдельные свойства соответствующих элементов языка UML. Информация, содержащаяся внутри фигур, имеет важное значение для конкретной модели проектируемой системы, поскольку регламентирует реализацию соответствующих элементов в программном коде. ‒ Пути, которые представляют собой последовательности из отрезков линий, соединяющих отдельные графические символы. При этом концевые точки отрезков линий должны обязательно соприкасаться с геометрическими фигурами, служащими для обозначения вершин диаграмм, как принято в теории графов. С концептуальной точки зрения путям в языке UML придается особое значение, поскольку они являются простыми топологическими сущностями. ‒ Строки текста. Служат для представления различных видов информации в некоторой грамматической форме. Предполагается, что каждое использование строки текста должно соответствовать синтаксису в нотации языка UML, посредством которого может быть реализован грамматический разбор этой строки. При графическом изображении диаграмм следует придерживаться следующих основных рекомендаций: 1. Каждая диаграмма должна служить законченным представлением соответствующего фрагмента моделируемой предметной области. 2. Все сущности на диаграмме модели должны быть одного концептуального уровня. Здесь имеется в виду согласованность не только имен одинаковых элементов, но и возможность вложения отдельных диаграмм друг в друга для достижения полноты представлений. 3. Вся информация о сущностях должна быть явно представлена на диаграммах. Речь идет о том, что, хотя в языке UML при отсутствии некоторых символов на диаграмме могут быть использованы их значения по умолчанию (например, в случае неявного указания видимости атрибутов и операций классов), необходимо стремиться к явному указанию свойств всех элементов диаграмм. 4. Диаграммы не должны содержать противоречивой информации. Противоречивость модели может служить причиной серьезнейших проблем при ее реализации и последующем использовании на практике. Например, наличие замкнутых путей при изображении отношений агрегирования или композиции приводит к ошибкам в программном коде, который будет реализовывать соответствующие классы. Наличие элементов с одинаковыми именами и различными атрибутами свойств в одном пространстве имен также приводит к неоднозначной интерпретации и может служить источником проблем. 5. Диаграммы не следует перегружать текстовой информацией. Принято считать, что визуализация модели является наиболее эффективной, если она содержит минимум пояснительного текста. 6. Каждая диаграмма должна быть самодостаточной для правильной интерпретации всех ее элементов и понимания семантики всех используемых графических символов. 7. Количество типов диаграмм для конкретной модели приложения не является строго фиксированным. Диаграмма состояний описывает процесс изменения состояний только одного класса, а точнее – одного экземпляра определенного класса, т. е. моделирует все возможные изменения в состоянии конкретного объекта. При этом изменение состояния объекта может быть вызвано внешними воздействиями со стороны других объектов или извне. Именно для описания реакции объекта на подобные внешние воздействия и используются диаграммы состояний. Диаграмма состояний описывает возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла. Диаграмма состояний представляет динамическое поведение сущностей, на основе спецификации их реакции на восприятие некоторых конкретных событий. Хотя диаграммы состояний чаще всего используются для описания поведения отдельных экземпляров классов (объектов), но они также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсистемы, операции и методы. Диаграмма состояний по существу является графом специального вида, который представляет некоторый автомат. Понятие автомата в контексте UML обладает довольно специфической семантикой, основанной на теории автоматов. Вершинами этого графа являются состояния и некоторые другие типы элементов автомата (псевдосостояния), которые изображаются соответствующими графическими символами. Дуги графа служат для обозначения переходов из состояния в состояние. Диаграммы состояний могут быть вложены друг в друга, образуя вложенные диаграммы более детального представления отдельных элементов модели.  Состояние Под состоянием понимается абстрактный метакласс, используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.  Секция «Список внутренних действий» содержит перечень внутренних действий или деятельностей, которые выполняются в процессе нахождения моделируемого элемента в данном состоянии. Каждое из действий записывается в виде отдельной строки и имеет следующий формат: <метка-действия '/' выражение-действия> Метка действия указывает на обстоятельства или условия, при которых будет выполняться деятельность, определенная выражением действия: ‒ entry – эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент входа в данное состояние (входное действие); ‒ exit – эта метка указывает на действие, специфицированное следующим за ней выражением действия, которое выполняется в момент выхода из данного состояния (выходное действие); ‒ do – эта метка специфицирует выполняющуюся деятельность («doactivity»), которая выполняется в течение всего времени, пока объект находится в данном состоянии, или до тех пор, пока не закончится вычисление, специфицированное следующим за ней выражением действия. В последнем случае при завершении события генерируется соответствующий результат; ‒ include – эта метка используется для обращения к подавтомату, при этом следующее за ней выражение действия содержит имя этого подавтомата. Пример: Аутентификация входа  Начальное и конечное состояния Начальное состояние представляет собой частный случай состояния, которое не содержит никаких внутренних действий (псевдосостояния). В этом состоянии находится объект по умолчанию в начальный момент времени. Оно служит для указания на диаграмме состояний графической области, от которой начинается процесс изменения состояний. Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий (псевдосостояния). В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени.  Переход Простой переход (simpletransition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий. В этом случае говорят, что переход срабатывает, Или происходит срабатывание перехода. До срабатывания перехода объект находится в предыдущем от него состоянии, называемым исходным состоянием, или в источнике (не путать с начальным состоянием – это разные понятия), а после его срабатывания объект находится в последующем от него состоянии (целевом состоянии). Переход осуществляется при наступлении некоторого события: окончания выполнения деятельности (doactivity), получении объектом сообщения или приемом сигнала. На переходе указывается имя события. Кроме того, на переходе могут указываться действия, производимые объектом в ответ на внешние события при переходе из одного состояния в другое. Срабатывание перехода может зависеть не только от наступления некоторого события, но и от выполнения определенного условия, называемого сторожевым условием. Объект перейдет из одного состояния в другое в том случае, если произошло указанное событие и сторожевое условие приняло значение «истина». На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние. Каждый переход может помечен строкой текста, которая имеет следующий общий формат: <сигнатура события>'['<сторожевое условие>']' <выражение действия> Событие Событие представляет собой спецификацию некоторого факта, имеющего место в пространстве и во времени. Про события говорят, что они «происходят», при этом отдельные события должны быть упорядочены во времени. После наступления некоторого события нельзя уже вернуться к предыдущим событиям, если такая возможность не предусмотрена явно в модели. События играют роль стимулов, которые инициируют переходы из одних состояний в другие. В качестве событий можно рассматривать сигналы, вызовы, окончание фиксированных промежутков времени или моменты окончания выполнения определенных действий. Имя события идентифицирует каждый отдельный переход на диаграмме состояний и может содержать строку текста, начинающуюся со строчной буквы. Сторожевое условие Сторожевое условие (guardcondition), если оно есть, всегда записывается в прямых скобках после события и представляет собой некоторое булевское выражение. Если сторожевое условие принимает значение «истина», то соответствующий переход может сработать, в результате чего объект перейдет в целевое состояние. Если же сторожевое условие принимает значение «ложь», то переход не может сработать, и при отсутствии других переходов объект не может перейти в целевое состояние по этому переходу. Однако вычисление истинности сторожевого условия происходит только после возникновения ассоциированного с ним события, инициирующего соответствующий переход. В общем случае из одного состояния может быть несколько переходов с одним и тем же событием-триггером. При этом никакие два сторожевых условия не должны одновременно принимать значение «истина». Каждое из сторожевых условий необходимо вычислять всякий раз при наступлении соответствующего события. Пример  Составное состояние и подсостояние Составное состояние (compositestate) – такое сложное состояние, которое состоит из других вложенных в него состояний. Последние будут выступать по отношению к первому как подсостояния (substate).  Последовательные подсостояния (sequential substates) используются для моделирования такого поведения объекта, во время которого в каждый момент времени объект может находиться в одном и только одном подсостояний. Поведение объекта в этом случае представляет собой последовательную смену подсостояний, начиная от начального и заканчивая конечным подсостояниями. Хотя объект продолжает находиться в составном состоянии, введение в рассмотрение последовательных подсостояний позволяет учесть более тонкие логические аспекты его внутреннего поведения.  Параллельные подсостояния (concurrentsubstates) позволяют специфицировать два и более подавтомата, которые могут выполняться параллельно внутри составного события. Каждый из подавтоматов занимает некоторую область (регион) внутри составного состояния, которая отделяется от остальных горизонтальной пунктирной линией. Если на диаграмме состояний имеется составное состояние с вложенными параллельными подсостояниями, то объект может одновременно находиться в каждом из этих подсостояний.  Синхронизирующие состояния Поведение параллельных подавтоматов независимо друг от друга, что позволяет реализовать многозадачность в программных системах. Однако в отдельных случаях может возникнуть необходимость учесть в модели синхронизацию наступления отдельных событий. Для этой цели в языке UML имеется специальное псевдосостояние, которое называется синхронизирующим состоянием. Синхронизирующее состояние (synch state) обозначается небольшой окружностью, внутри которой помещен символ звездочки "*". Оно используется совместно с переходом-соединением или переходом-ветвлением для того, чтобы явно указать события в других подавтоматах, оказывающие непосредственное влияние на поведение данного подавтомата. Для иллюстрации использования синхронизирующих состояний рассмотрим упрощенную ситуацию с моделированием процесса постройки дома. Предположим, что постройка дома включает в себя строительные работы (возведение фундамента и стен, возведение крыши и отделочные работы) и работы по электрификации дома (подведение электрической линии, прокладка скрытой электропроводки и установка осветительных ламп). Очевидно, два этих комплекса работ могут выполняться параллельно, однако между ними есть некоторая взаимосвязь. В частности, прокладка скрытой электропроводки может начаться лишь после того, как будет завершено возведение фундамента и стен. А отделочные работы следует начать лишь после того, как будет закончена прокладка скрытой электропроводки. В противном случае отделочные работы придется проводить повторно. Рассмотренные особенности синхронизации этих параллельных процессов учтены на соответствующей диаграмме состояний с помощью двух синхронизирующих состояний.  Примеры диаграмм состояний.  Порядок выполнения работы В качестве примера рассматривается моделирование системы продажи товаров по каталогу. 1. Запустите MS Visio. 2. На экране выбора шаблона выберите категорию Программы и БД и в ней элемент Схема модели UML. Нажмите кнопку Создать в правой части экрана. 3. Окно программы примет вид.  Клиент оформляет заказ. Класс Заказ имеет атрибут Статус. Проследим динамику движения заказов в системе с помощью диаграммы состояний, составленной для класса Заказ. Данные о сформированном заказе поступают продавцу, который проверяет наличие товаров из заказа, проверяет оплату заказа, комплектует его и делает отметку о готовности. После оплаты заказа он выдается клиенту. Продавец делает отметку о том, что заказ выдан. Если после проверки кредитного рейтинга клиента, он окажется отрицательным, то заказ будет отклонен. Построим диаграмму состояний для класса Заказ. Для этого, в файле с диаграммой классов, созданной в практическом занятии 8, необходимо проделать следующие действия: 1. Щелкнуть правой кнопкой мыши по классу Заказ. 2. В контекстном меню выбрать пункт Схемы. 3. Т.к. в настоящее время уже созданных схем нет, нажать кнопку Создать и выбрать Схема состояний. 4. Переименовать созданный лист в Схема состояний-Заказ. 5. Построить диаграмму состояний для класса Заказ. После формирования заказа он должен быть оплачен. Обработка заказа подразумевает проверку наличия товара и проверку оплаты. Переход в одно из состояний На комплектации, Укомплектован, Выдан означает смену Статуса заказа.  Далее опишем с помощью диаграммы состояний процесс оплаты заказа клиентом, которому соответствует класс ЗаказОплата. Построим диаграмму состояний для проверки оплаты заказа. Чтобы проверить оплату заказа, необходимо определить, существует ли сам заказ. Результатом проверки оплаты заказа является вывод либо сообщения о произведенной оплате с параметрами (дата оплаты), либо сообщения об ожидании оплаты. Событием, предшествующим проверке оплаты заказа, является занесение информации о заказе в базу данных заказов. Чтобы построить диаграмму состояний для класса ЗаказОплаты, необходимо проделать действия, описанные в пунктах 1-4 построения диаграммы состояний для класса Заказ. Полученная диаграмма должна иметь вид, изображенный на рис.  На этой диаграмме есть составное состояние «Проверить оплату заказа», т.к. оно включает в себя проверку кредитного рейтинга клиента и проверку выбора варианта оплаты клиентом. Оплату заказа может произвести только клиент с положительным кредитным рейтингом, поэтому необходимым условием проверки оплаты заказа является проверка кредитоспособности клиента. Если клиент имеет отрицательный кредитный рейтинг, то заказ отклоняется, и на этом дальнейшие события не имеют смысла. Если кредитный рейтинг клиента положительный, то необходимо проверить, выбрал ли клиент вариант оплаты. Событие, которое переводит систему в состояние ожидания выбора варианта оплаты клиентом, является получение сообщения о кредитоспособности клиента. Оплата может быть произведена наличными средствами в магазине или с помощью безналичного расчета. В первом случае необходимо договориться с клиентом о дате и времени его прибытия в магазин. Во втором случае необходимо сообщить клиенту о наличии/поступлении товара. Событие, которое переводит систему в состояние ожидания оплаты, является выбор клиентом варианта оплаты. Соответствующие диаграммы состояний имеют вид Для создания диаграмм состояний, которые входят в состав составного состояния, нужно: 1. Щелкнуть правой кнопкой мыши по Составному состоянию и выбрать пункт Схема. 2. Либо, в Проводнике по моделям выделить название составного состояния и создать новую страницу.  Задание самостоятельной работы В соответствии с индивидуальным вариантом, построить диаграмму состояний. Перечень индивидуальных вариантов приведен в приложении А. Отчет по практическому занятию выполняется в формате MS Word, который содержит экранные формы моделей согласно заданию. Форма отчета: Диаграмма Состояний с описанием процесса построения диаграмм. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Литература: 1. Черткова, Е. А. Программная инженерия. Визуальное моделирование программных систем: учебник для СПО / Е. А. Черткова. —2-е изд., испр. и доп. — М.: Издательство Юрайт, 2017. — 168 с. — (Серия: Профессиональное образование). - URL://www.urait.ru Раздел 1. Технология разработки программного обеспечения |