сд.01_пиэ_о_проектирование ИС_12310-2010_8_1. Образовательный стандарт учебной дисциплины Проектирование информационных систем
 Скачать 7.87 Mb.
|
|
А.12 Лабораторная работа 12 – 2ч. Разработка постановок задач функциональных подсистем АИС А.12.1 Цель работы - разработать постановки задач функциональных подсистем АИС. А.12.2 Объект изучения Объектом изучения являются этапы и работы, выполняемые при формулировке перечня задач и разработке постановок их решения. Теоретические сведения содержатся в лекциях и литературе. А.12.3 Оборудование и технические средства Техническими средствами для выполнения работы являются средства лаборатории «Электронный офис», обеспечивающие доступ к сетевому серверу кафедры. А.12.4 Содержание и последовательность работы 1) Выявить функциональные подсистемы АИС и разработать постановки задач; 2) Выполнить следующие работы технического проектирования: - П5 (разработка постановки решения i-й задачи для j-й подсистемы); 3) Разработать и/или уточнить формы входных и выходных документов; 4) Установить соответствие между перечнем задач и набором форм. 5) Защитить работу. В процессе защиты лабораторной работы необходимо представить отчет и ответить на контрольные вопросы. А.12.5 Требования к оформлению работы Отчет о лабораторной работе должен содержать постановки задач, определенные ранее в функциональной матрице. На каждую задачу оформляется отдельная постановка задачи. В каждой постановке описывается 14 пунктов (см. рис. А.12.1.) Отчет оформляется в виде принтерной распечатки с соблюдением требований ГОСТ 2.105 на листах формата A4. А.12.6 Литература 1 Смирнова Г.Н. Проектирование экономических информационных систем: учебник / Г.н. Смирнова, А.А. Сорокин, Ю.Ф. Тельнов. - М.: Финансы и статистика, 2003. - 512 с.: ил. 2 http://www.rugost.com/ А.12.7 Методические указания к выполнению работы Основным компонентом локальных проектных решений, являющимся базой для разработки информационного, программного и технологического обеспечения для каждой задачи, является «Постановка задачи» (см. рисунок А.12.1).  Рисунок А.12.1 – Схема структуры «Постановка задачи» Этот документ содержит три составные части: - характеристику задачи; - описание выходной информации; - описание входной информации. В состав раздела «Характеристика задачи» входят следующие компоненты: описание цели, назначения решения конкретной задачи, перечень функций и процессов, реализуемых решаемой задачей, характеристика организационной и технико-экономической сущности задачи; обоснование целесообразности автоматизации решения задачи; указание перечня объектов, для которых решается задача; описание процедур решения задачи; указание периодичности решения задачи и требований к организации сбора первичных данных; описание связей с другими задачами. Под целью автоматизации решения задачи подразумевается получение определенных значений экономического эффекта в сфере управления какими-либо процессами системы или снижение стоимостных и трудовых затрат на обработку информации, улучшение качества и достоверности получаемой информации, повышение оперативности ее обработки и т.д., т.е. получение косвенного и прямого эффекта от внедрения данной задачи. Под экономической сущностью решаемой задачи понимается состав экономических показателей, рассчитываемых при ее решении, документы, в которые заносятся эти показатели, перечень исходных показателей, необходимых для получения результатных и наименования тех первичных документов, в которых они содержатся. Организационная сущность задачи – это описание порядка решения задачи; организационной формы, применяемой для ее решения; режима решения; состава файлов с постоянной и переменной информацией; способа получения и ввода первичной информации в ЭВМ; формы выдачи результатной информации: на печать, на экран, на магнитный носитель или передача по каналам связи. Описание алгоритма решения задачи включает формализованное описание входных и результатных показателей и перечень формул расчета результатных показателей в случае решения задачи прямым методом счета или описание математической модели, экономико-математического метода, применяемого для ее реализации, и перечня последовательных шагов выполнения расчетов. Далее указывается периодичность решения задачи и регламент выдачи результатных документов, требования к организации сбора исходных данных, т.е. к способу и техническим средствам съема, регистрации, сбора и передачи данных для обработки. Большое значение имеет описание связи задачи с другими задачами функциональной подсистемы, в которую она входит, а также с задачами других подсистем или с внешней средой. Описание выходной информации включает в себя: перечень и описание выходных сообщений, документов; перечень структурных единиц информации; периодичность возникновения и сроки получения информации, наименование, идентификатор по каждой форме документа. Описание входной информации состоит из перечня входных сообщений; перечня структурных единиц информации, описания периодичности возникновения и сроков получения информации; наименования и идентификатора по каждой форме документа. Подробнее данный вопрос рассмотрен в предложенном учебнике. А.13 Лабораторная работа 13 – 4ч. Разработка внемашинной и внутримашинной технологии решения задач ЭИС. Разработка моделей технологических процессов с использованием диаграмм IDEF0, IDEF3, DFD, ARIS. Разработка технологических процессов на основе моделирования взаимодействия объектов системы и динамического представления системы с использованием языка UML А.13.1 Цель работы- разработка внемашинной и внутримашинной технологий решения задач в ЭИС. Разработка моделей технологических процессов с использованием диаграмм IDEF0, IDEF3, DFD, ARIS. Моделирование взаимодействия объектов системы и динамического представления системы на основе языка UML А.13.2 Предмет и содержание работы Предметом работы являются изучение методов и средств описания внемашинных и внутримашинных технологических процессов с использованием технологий IDEF0, IDEF3, DFD, ARIS и средств построения диаграмм взаимодействия – диаграмм последовательности и диаграмм сотрудничества (кооперации) UML, а также диаграмм схем состояний – диаграмм схем состояний и диаграмм деятельности UML. Теоретические сведения содержатся в лекциях и литературе. А.13.3 Оборудование и технические средства Техническими средствами для выполнения работы являются средства лаборатории «Электронный офис», обеспечивающие доступ к сетевому серверу кафедры. А.13.4 Содержание и последовательность работы Изучить теоретический материал по вопросам моделрования и описания твнемашинных и внутримашинных технологических процессов на основе диаграмм стандартов IDEF0, IDEF3, диаграмм DVD,системы ARIS языка моделирования UML. Изучить по учебнику [4 ,гл.7] вопросы проектирования внемашинных и внутримашинных технологических процессов обработки данных. Описать технологические процессы при помощи инструментария
Выполнить описание взаимодействия объектов системы и динамического представления системы; 4.1) Диаграмма последовательности UML. 4.2) Диаграмма сотрудничества (кооперации) UML. 4.3) Диаграмма схем состояний UML. 4.4.) Диаграмма деятельности UML. А.13.5 Требования к оформлению работы Описать технологические процессы при помощи инструментария
3) ARIS 4) UML: Выполнить описание взаимодействия объектов системы и динамического представления системы; 4.1) Диаграмма последовательности UML. 4.2) Диаграмма сотрудничества (кооперации) UML. 4.3) Диаграмма схем состояний UML. 4.4.) Диаграмма деятельности UML. Отчет оформляется в виде принтерной распечатки с соблюдением требований ГОСТ 2.105 на листах формата A4. А.13.6 Литература 1. Вендров А.М. Проектирование программного обеспечения экономиче ских информационных систем: Учебник.-2-е изд., перераб и доп.- М.: Финансы и статистика, 2006.-544 с. 92/5/Э
Дополнительная литература
А.13.7 Методические указания к выполнению работы Методы визуального моделирования используются для описания бизнес-процессов и внемашинных и внутримашинных технологических процессов, показанных ниже (рис.7.1,7.2). Подробное описание представлено в предлагаемых учебниках.   Модели структурного описания системы были рассмотрены выше. Рассмотрим модели объектно-ориентированного описания на основе языка UML. Динамические модели обеспечивают представление поведения систем. «Динамизм» этих моделей состоит в том, что в них отражается изменение состояний в процессе работы системы (в зависимости от времени). Для моделирования поведения системы используют: - автоматы; - взаимодействия. Автомат (Statemachine) описывает поведение в терминах последовательности состояний, через которые проходит объект в течение своей жизни. Взаимодействие (Interaction) описывает поведение в терминах обмена сообщениями между объектами. Таким образом, автомат задает поведение системы как цельной, единой сущности; моделирует жизненный цикл единого объекта. В силу этого автоматный подход удобно применять для формализации динамики отдельного трудного для понимания блока системы. Взаимодействия определяют поведение системы в виде коммуникаций между его частями (объектами), представляя систему как сообщество совместно работающих объектов. Именно поэтому взаимодействия считают основным аппаратом для фиксации полной динамики системы. Автоматы отображают с помощью: - диаграмм схем состояний; - диаграмм деятельности. Взаимодействия отображают с помощью: - диаграмм сотрудничества (кооперации); - диаграмм последовательности. Диаграмма схем состояний показывает конечный автомат, представляет состояния, переходы, события и действия. Диаграммы схем состояний обеспечивают динамическое представление системы. Они особенно важны при моделировании поведения интерфейса, класса или сотрудничества. Эти диаграммы выделяют такое поведение объекта, которое управляется событиями, что особенно полезно при моделировании реактивных систем. Диаграмма деятельности — специальная разновидность диаграммы схем состояний, которая показывает поток от действия к действию внутри системы. Диаграммы деятельности обеспечивают динамическое представление системы. Они особенно важны при моделировании функциональности системы и выделяют поток управления между объектами. Диаграммы взаимодействия показывают взаимодействие, включающее набор объектов и их отношений, а также пересылаемые между объектами сообщения. Диаграммы взаимодействия обеспечивают динамическое представление системы. Диаграмма последовательности — это диаграмма взаимодействия, которая выделяет упорядочение сообщений по времени. Диаграмма сотрудничества (диаграмма кооперации) — это диаграмма взаимодействия, которая выделяет структурную организацию объектов, посылающих и принимающих сообщения. Диаграммы последовательности и диаграммы сотрудничества изоморфны, что означает, что одну диаграмму можно трансформировать в другую диаграмму. У разных разработчиков имеются различные предпочтения вида диаграммы взаимодействия. В диаграмме последовательности делается акцент именно на последовательность сообщений: легче наблюдать порядок, в котором происходят различные события. На кооперативной диаграмме можно использовать пространственное расположение объектов для того, чтобы показать их статическое взаимодействие. Одним из принципиальных свойств любой формы диаграммы взаимодействия является их простота. Посмотрев на диаграмму, можно легко увидеть все сообщения. Однако если попытаться изобразить нечто более сложное, чем единственный последовательный процесс без особых условных переходов или циклов, такой подход не сработает. Диаграммы взаимодействия наиболее хороши, когда они отображают простое поведение; при более сложном поведении они быстро теряют свою ясность и наглядность. Если нужно показать сложное поведение системы на одной диаграмме, то следует использовать диаграмму деятельностей. Диаграммы взаимодействия следует использовать, когда нужно описать поведение нескольких объектов в рамках одного варианта использования. Они хороши для отображения взаимодействия между объектами и вовсе не так хороши для точного описания их поведения. Если нужно описать поведение единственного объекта во многих вариантах использования, то следует применить диаграмму состояний. Если же описывается поведение во многих вариантах использования или многих параллельных процессах, следует рассмотреть диаграмму деятельностей. Диаграмма схем состояний отображает конечный автомат, выделяя поток управления, следующий от состояния к состоянию. Конечный автомат — поведение, которое определяет последовательность состояний в ходе существования объекта. Эта последовательность рассматривается как ответ на события и включает реакции на эти события. Диаграмма схем состояний показывает: 1) набор состояний системы; 2) события, которые вызывают переход из одного состояния в другое; 3) действия, которые происходят в результате изменения состояния. В языке UML состоянием называют период в жизни объекта, на протяжении которого он удовлетворяет какому-то условию, выполняет определенную деятельность или ожидает некоторого события. Как показано на рисунке А.13.1, состояние изображается как закругленный прямоугольник, обычно включающий его имя и подсостояния (если они есть).  Рисунок А.13.1 – Обозначение состояния Переходы между состояниями отображаются помеченными стрелками (см. рисунок А.2).  Рисунок А.13.2 – Переходы между состояниями Событие — происшествие, вызывающее изменение состояния. Действие — набор операций, запускаемых событием. Иначе говоря, события вызывают переходы, а действия являются реакциями на переходы. Для отображения перехода в начальное состояние принято обозначение, показанное на рисунке А.13.3.  Рисунок А.13.3 – Переход в начальное состояние Соответственно, обозначение перехода в конечное состояние имеет вид, представленный на рисунке А.13.4.  Рисунок А.13.4 - Переход в конечное состояние В качестве примера на рисунке А.13.5 показана диаграмма схем состояний для системы охранной сигнализации.  Рисунок А.13.5 - Диаграмма схем состояний системы охранной сигнализации Из рисунка видно, что система начинает свою жизнь в состоянии Инициализация, затем переходит в состояние Ожидание. В этом состоянии через каждые 10 секунд (по событию after (10 sec.)) выполняется самопроверка системы (операция Самопроверка ()). При наступлении события Тревога (Датчик) реализуются действия, связанные с блокировкой периметра охраняемого объекта, — исполняется операция БлокироватьПериметр() и осуществляется переход в состояние Активна. В активном состоянии через каждые 5 секунд по событию after (5 sec.) запускается операция ПриемКоманды(). Если команда получена (наступило событие Сброс), система возвращается в состояние Ожидание. В процессе возврата разблокируется периметр охраняемого объекта (операция РазблокироватьПериметр()). Для указания действий, выполняемых при входе в состояние и при выходе из состояния, используются метки entry и exit соответственно. Например, как показано на рисунке А.13.6, при входе в состояние Активна выполняется операция УстановитьТревогу() из класса контроллер, а при выходе из состояния — операция СбросТревоги().  Рисунок А.13.6 - Входные и выходные действия и деятельность в состоянии Активна Действие, которое должно выполняться, когда система находится в данном состоянии, указывается после метки do. Считается, что такое действие начинается при входе в состояние и заканчивается при выходе из него. Например, в состоянии Активна это действие ПодтверждатьТревогу(). Между состояниями возможны различные типы переходов. Обычно переход инициируется событием. Допускаются переходы и без событий, например, условные переходы - переход происходит по событию, но только в том случае, если выполнено некоторое условие (см. рисунок А.13.7). Сторожевое условие (guard condition), если оно есть, всегда записывается в прямых скобках после события-триггера и представляет собой некоторое булевское выражение. Порядок выполнения условного перехода: 1) происходит событие; 2) вычисляется условие УсловиеПерехода; 3) при УсловиеПерехода=true запускается переход и активизируется действие, в противном случае переход не выполняется.  Рисунок А.13.7 – Обозначение условного перехода Вложенные состояния Одной из наиболее важных характеристик конечных автоматов в UML является подсостояние. Подсостояние позволяет значительно упростить моделирование сложного поведения. Подсостояние — это состояние, вложенное в другое состояние. На рисунке А.13.8 показано составное состояние, содержащее в себе два подсостояния.  Рисунок А.13.8 - Обозначение подсостояний На рисунке А.13.9 приведена внутренняя структура составного состояния Активна.  Рисунок А.13.9 - Переходы в состоянии Активна Семантика вложенности такова: если система находится в состоянии Активна, то она должна быть точно в одном из подсостояний: Проверка, Звонок, Ждать. В свою очередь, в подсостояние могут вкладываться другие подсостояния. Степень вложенности подсостояний не ограничивается. Данная семантика соответствует случаю последовательных подсостояний. Возможно наличие параллельных подсостояний — они выполняются параллельно внутри составного состояния. Параллельные подсостояния (concurrent substates) позволяют специфицировать два и более подавтомата, которые могут выполняться параллельно внутри составного события. Каждый из подавтоматов занимает некоторую область или регион внутри составного состояния, которая отделяется от остальных горизонтальной пунктирной линией. Если на диаграмме состояний имеется составное состояние с вложенными параллельными подсостояниями, то объект может одновременно находиться в каждом из этих подсостояний. Отдельные параллельные подсостояния могут состоять из нескольких последовательных подсостояний (подавтоматы 1 и 3 на рисунке А.13.10).  Рисунок А.13.10 - Изображение составного состояния с вложенными параллельными подсостояниями Поскольку каждый регион вложенного состояния специфицирует некоторый подавтомат, то для каждого из вложенных подавтоматов могут быть определены собственные начальное и конечные подсостояния. При переходе в данное составное состояние каждый из подавтоматов оказывается в своем начальном подсостоянии. Далее происходит параллельное выполнение каждого из этих подавтоматов, причем выход из составного состояния будет возможен лишь в том случае, когда все подавтоматы будут находиться в своих конечных подсостояниях. Если какой-либо из подавтоматов пришел в свое конечное состояние раньше других, то он должен ожидать, пока и другие подавтоматы не придут в свои конечные состояния. Иногда при возврате в составное состояние возникает необходимость попасть в то его подсостояние, которое в прошлый раз было последним. Такое подсостояние называют историческим. Информация об историческом состоянии запоминается. Как показано на рисунке А.13.11, подобная семантика переходов отображается значком истории — буквой Н внутри кружка.  Рисунок А.13.11 - Историческое состояние При первом посещении состояния Активна автомат не имеет истории, поэтому происходит простой переход в подсостояние Проверка. Предположим, что в подсостоянии Звонок произошло событие Запрос. Средства управления заставляют автомат покинуть подсостояние Звонок (и состояние Активна) и вернуться в состояние Команды. Когда работа в состоянии Команды завершается, выполняется возврат в историческое подсостояние состояния Активна. Поскольку теперь автомат запомнил историю, он переходит прямо в подсостояние Звонок (минуя подсостояние Проверка). В некоторых случаях бывает желательно скрыть внутреннюю структуру составного состояния. Например, отдельный подавтомат, специфицирующий составное состояние, может быть настолько большим по размеру, что его визуализация затруднит общее представление диаграммы состояний. В подобной ситуации допускается не раскрывать на исходной диаграмме данное составное состояние, а указать в правом нижнем углу специальный символ-пиктограмму. В последующем диаграмма состояний для соответствующего подавтомата может быть изображена отдельно с необходимыми комментариями. Как показано на рисунке А.13.12, для обозначения составного состояния, имеющего внутри себя скрытые (не показанные на диаграмме) подсостояния, используется символ «очки».  Рисунок А.13.12 - Символ состояния со скрытыми подсостояниями  Рисунок А.13.13 – Пример диаграммы схем состояния  Рисунок А.13.14 – Пример использования параллельных подсостояний В метамодели UML автомат является пакетом, в котором определено множество понятий, необходимых для представления поведения моделируемой сущности в виде дискретного пространства с конечным числом состояний и переходов. Длительность нахождения системы в любом из возможных состояний существенно превышает время, которое затрачивается на переход из одного состояния в другое. Предполагается, что в пределе время перехода может быть равно нулю (если дополнительно не оговорено другое), то есть смена состояний объекта может происходить мгновенно. Поведение автомата моделируется как последовательное перемещение по графу от вершины к вершине с учетом ориентации связывающих их дуг. Для автомата должны выполняться следующие обязательные условия: - состояние, в которое может перейти объект, определяется только его текущим состоянием и не зависит от предыстории; - в каждый момент времени автомат может находиться только в одном из своих состояний. При этом, автомат может находиться в отдельном состоянии как угодно долго, если не происходит никаких событий; - время нахождения автомата в том или ином состоянии, а также время достижения того или иного состояния никак не специфицируются; - количество состояний автомата должно быть конечным и все они должны быть специфицированы явным образом. Отдельные псевдосостояния могут не иметь спецификаций (начальное и конечное состояния). В этом случае их назначение и семантика полностью определяются из контекста модели и рассматриваемой диаграммы состояний; - граф автомата не должен содержать изолированных состояний и переходов. Для каждого состояния, кроме начального, должно быть определено предшествующее состояние, а каждый переход должен соединять два состояния автомата; - автомат не должен содержать конфликтующих переходов, когда объект одновременно может перейти в два и более последующих состояния (кроме случая параллельных подавтоматов). В языке UML исключение конфликтов возможно на основе введения сторожевых условий. Диаграмма деятельности представляет особую форму конечного автомата, в которой показываются процесс вычислений и потоки работ. В ней выделяются не обычные состояния объекта, а состояния выполняемых вычислений — состояния действий. При этом полагается, что процесс вычислений не прерывается внешними событиями. Словом, диаграммы деятельности очень похожи на блок-схемы алгоритмов. Основной вершиной в диаграмме деятельности является состояние действия (рис. 5.15), которое изображается как прямоугольник с закругленными боковыми сторонами.  Рисунок А.13.15 - Состояние действия Состояние действия считается атомарным (действие нельзя прервать) и выполняется за один квант времени, его нельзя подвергнуть декомпозиции. Если нужно представить сложное действие, которое можно подвергнуть дальнейшей декомпозиции (разбить на ряд более простых действий), то используют состояние поддеятельности. Изображение состояния под-деятельности содержит пиктограмму в правом нижнем углу (рисунок А.13.16).  Рисунок А.13.16 - Состояние под-деятельности Фактически в данную вершину вписывается имя другой диаграммы, имеющей внутреннюю структуру. Переходы между вершинами — состояниями действий — изображаются в виде стрелок. Переходы выполняются по окончании действий. Кроме того, в диаграммах деятельности используются вспомогательные вершины: - решение (ромбик с одной входящей и несколькими исходящими стрелками); Вершина «решение» позволяет отобразить разветвление вычислительного процесса, исходящие из него стрелки помечаются сторожевыми условиями ветвления (в квадратных скобках). - объединение (ромбик с несколькими входящими и одной исходящей стрелкой); Вершина «объединение» отмечает точку слияния альтернативных потоков действий. - линейка синхронизации — разделение (жирная горизонтальная линия с одной входящей и несколькими исходящими стрелками); - линейка синхронизации — слияние (жирная горизонтальная линия с несколькими входящими и одной исходящей стрелкой); Линейки синхронизации позволяют показать параллельные потоки действий, отмечая точки их синхронизации при запуске (момент разделения) и при завершении (момент слияния). - начальное состояние (черный кружок); - конечное состояние (незакрашенный кружок, в котором размещен черный кружок меньшего размера). Пример диаграммы деятельности приведен на рисунке А.13.17. Эта диаграмма описывает деятельность покупателя в Интернет-магазине. Здесь представлены две точки ветвления — для выбора способа поиска товара и для принятия решения о покупке. Присутствуют три линейки синхронизации: верхняя отражает разделение на два параллельных процесса, средняя отражает и разделение, и слияние процессов, а нижняя — только слияние процессов.  Рисунок А.13.17 – Диаграмма деятельности покупателя в Интернет магазине Дополнительно на этой диаграмме показаны две плавательные дорожки — дорожка покупателя и дорожка магазина, которые разделены вертикальной линией. Каждая дорожка имеет имя и фиксирует область деятельности конкретного лица, обозначая зону его ответственности.  Рисунок А.13.18 - Диаграмма деятельности для примера с приготовлением напитка  Рисунок А.13.19 - Фрагмент диаграммы деятельности для торговой компании  Рисунок А.13.20 – Диаграмма деятельности (активности) для примера рассмотрения заявки на получение кредита Диаграммы взаимодействия. Диаграммы взаимодействия предназначены для моделирования динамических аспектов системы. Диаграмма взаимодействия показывает взаимодействие, включающее набор объектов и их отношений, а также пересылаемые между объектами сообщения. Существуют две разновидности диаграммы взаимодействия — диаграмма последовательности и диаграмма сотрудничества. Диаграмма последовательности — это диаграмма взаимодействия, которая выделяет упорядочение сообщений по времени. Диаграмма сотрудничества — это диаграмма взаимодействия, которая выделяет структурную организацию объектов, посылающих и принимающих сообщения. Элементами диаграмм взаимодействия являются участники взаимодействия — объекты, связи, сообщения. Диаграммы сотрудничества отображают взаимодействие объектов в процессе функционирования системы. Такие диаграммы моделируют сценарии поведения системы. В русской литературе диаграммы сотрудничества часто называют диаграммами кооперации. Объекты на диаграммах сотрудничества обозначаются так же, как и на других UML-диаграммах – прямоугольниками (см. рисунки А.13.21-5.22). Однако на диаграммах данного вида имя объекта может дополняться его ролью в сотрудничестве.  Рисунок А.13.21 - Обозначение объекта  Рисунок А.13.22 – Пример обозначения объекта Составной объект – объект, который состоит из других объектов (см. рисунок А.13.23).  Рисунок А.13.23 – Обозначение составного объекта Объекты взаимодействуют друг с другом с помощью связей — каналов для передачи сообщений. Связь между парой объектов рассматривается как экземпляр ассоциации между их классами. Иными словами, связь между двумя объектами существует только тогда, когда имеется ассоциация между их классами. Неявно все классы имеют ассоциацию сами с собой, следовательно, объект может послать сообщение самому себе. Итак, связь — это путь для пересылки сообщения. Путь может быть снабжен характеристикой видимости. Характеристика видимости проставляется как стандартный стереотип над дальним концом связи. В языке предусмотрены следующие стандартные стереотипы видимости: «global» - объект-поставщик находится в глобальной области определения объекта-клиента; «local» - объект-поставщик находится в локальной области определения объекта-клиента; «parameter» - объект-поставщик является параметром операции объекта-клиента; «self» - один и тот же объект является и клиентом, и поставщиком. Приведенные стереотипы требуют пояснения. Связь между объектами в информационной системе на уровне программирования на определенном языке осуществляется посредством передачи параметров (переменных) от одного объекта другому объекту. Например, объект Отдел продаж передает объекту Склад некоторый принятый в организации документ (переменную), в котором сообщает о необходимости выделения продукции той или иной номенклатуры. Значение передаваемых параметров является содержанием передаваемого посредством связи сообщения. Сообщение — это спецификация передачи информации между объектами в ожидании того, что будет обеспечена требуемая деятельность. Прием сообщения рассматривается как событие. Результатом обработки сообщения обычно является действие. Для записи сообщений в языке UML принят следующий синтаксис: ВозврВеличина := ИмяСообщения (Аргументы), где ВозврВеличина задает величину, возвращаемую как результат обработки сообщения. Когда объект посылает сообщение в другой объект (делегируя некоторое действие получателю), объект-получатель, в свою очередь, может послать сообщение в третий объект, и т. д. Так формируется поток сообщений — последовательность управления. Очевидно, что сообщения в последовательности должны быть пронумерованы. Номера записываются перед именами сообщений, направления сообщений указываются стрелками (размещаются над линиями связей). Наиболее общую форму управления задает процедурный или вложенный поток (поток синхронных сообщений). Как показано на рисунке А.13.24, процедурный поток рисуется стрелками с заполненными наконечниками  . Рисунок А.13.24 - Поток синхронных сообщений Здесь сообщение 2.1 : Напиток : = Изготовить(Смесь№3) определено как первое сообщение, вложенное во второе сообщение 2 : Заказать(Смесь№3) последовательности, а сообщение 2.2 : Принести(Напиток) — как второе вложенное сообщение. Все сообщения процедурной последовательности считаются синхронными. Работа с синхронным сообщением подчиняется следующему правилу: передатчик ждет до тех пор, пока получатель не примет и не обработает сообщение. В нашем примере это означает, что третье сообщение будет послано только после обработки сообщений 2.1 и 2.2. Отметим, что степень вложенности сообщений может быть любой. Главное, чтобы соблюдалось правило: последовательность сообщений внешнего уровня возобновляется только после завершения вложенной последовательности. Менее общую форму управления задает асинхронный поток управления. Как показано на рисунке А.13.25, асинхронный поток рисуется обычными стрелками  . Здесь все сообщения считаются асинхронными, при которых передатчик не ждет реакции от получателя сообщения. Такой вид коммуникации имеет семантику почтового ящика — получатель принимает сообщение по мере готовности. Иными словами, передатчик и получатель не синхронизируют свою работу, скорее, один объект «избавляется» от сообщения для другого объекта. В нашем примере сообщение ПодтверждениеВызова определено как второе сообщение в последовательности. Рисунок А.13.25 - Поток асинхронных сообщений Итак, сообщения на диаграммах сотрудничества изображаются стрелками вдоль связей. Порядок передачи сообщений может быть определен явным указанием номера сообщения возле стрелки. Вид сообщения несет дополнительную смысловую нагрузку в виде определения ролей взаимодействующих объектов. В зависимости от этого сообщения графически изображаются: - сплошной линией с треугольной стрелкой – такое сообщение означает вызов процедуры (метода объекта) или вызов другого потока управления;- сплошной линией с обычной стрелкой – такое сообщение означает простой поток управления, то есть просто передачу данных.- пунктирной линией с обычной стрелкой  – такое сообщение означает возврат значения из процедуры.Помимо рассмотренных линейных потоков управления, можно моделировать и более сложные формы — итерации и ветвления. Итерация представляет повторяющуюся последовательность сообщений. После номера сообщения итерации добавляется выражение *[i := 1 .. n]. Оно означает, что сообщение итерации будет повторяться заданное количество раз. Например, четырехкратное повторение первого сообщения РисоватьСторонуПрямоугольника можно задать выражением 1*[i := 1 .. 4] : РисоватьСторонуПрямоугольника(i) Для моделирования ветвления после номера сообщения добавляется выражение условия, например: [х>0]. Сообщение альтернативной ветви помечается таким же номером, но с другим условием: [х<=0]. Пример итерационного и разветвляющегося потока сообщений приведен на рисунке А.13.26. Здесь первое сообщение повторяется 4 раза, а в качестве второго выбирается одно из двух сообщений (в зависимости от значения переменной х). В итоге экземпляр рисователя нарисует на экране прямоугольное окно, а экземпляр собеседника выведет в него соответствующее донесение. Таким образом, для формирования диаграммы сотрудничества выполняются следующие действия: 1) отображаются объекты, которые участвуют во взаимодействии; 2) рисуются связи, соединяющие эти объекты; 3) связи помечаются сообщениями, которые посылают и получают выделенные объекты.  Рисунок А.13.26 - Итерация и ветвление В итоге формируется ясное визуальное представление потока управления (в контексте структурной организации сотрудничающих объектов). В качестве примера на рисунке А.13.27 приведена диаграмма сотрудничества системы управления полетом летательного аппарата. На данной диаграмме представлены пять объектов, явно показаны характеристики видимости всех связей системы. Поток управления в системе включает восемь сообщений: четыре асинхронных и четыре синхронных сообщения. Экземпляр Контроллера СУ ждет приема и обработки сообщений: - ВклРегСкор(); - ВрРегУгл(); - ТекущСкор(); - ТекущУгл().  Рисунок А.13.27 - Диаграмма сотрудничества системы управления полетом Порядок следования сообщений задан их номерами. Для пятого и седьмого сообщений указаны условия: - включение Регулятора Скорости происходит, если относительное время полета Т больше заданного периода Тзад; - включение Регулятора Углов обеспечивается, если относительное время полета меньше или равно заданному периоду.  Рисунок А.13.28 – Диаграмма сотрудничества для примера отношения расчета чеками за товары Диаграмма сотрудничества (диаграмма кооперации) показывает структурные особенности взаимодействия между объектами и является развитием идеи построения диаграмм сущность-связь. Диаграмма последовательности ориентирована на отображение временных аспектов взаимодействия. Диаграмма последовательности — вторая разновидность диаграмм взаимодействия. Отражая сценарий поведения в системе, эта диаграмма обеспечивает более наглядное представление порядка передачи сообщений. Правда, она не позволяет показать такие детали, которые видны на диаграмме сотрудничества (структурные характеристики объектов и связей). Графически диаграмма последовательности — разновидность таблицы, которая показывает объекты, размещенные вдоль оси X, и сообщения, упорядоченные по времени вдоль оси Y.  Рисунок А.13.29 - Диаграмма последовательности системы управления полетом Как показано на рисунке А.13.29, объекты, участвующие во взаимодействии, помещаются на вершине диаграммы, вдоль оси X. Обычно слева размещается объект, инициирующий взаимодействие, а справа — объекты по возрастанию подчиненности. Сообщения, посылаемые и принимаемые объектами, помещаются вдоль оси Y в порядке возрастания времени от вершины к основанию диаграммы. Используются те же синтаксис и обозначения синхронизации, что и в диаграммах сотрудничества. Таким образом, обеспечивается простое визуальное представление потока управления во времени. От диаграмм сотрудничества диаграммы последовательности отличают две важные характеристики. Первая характеристика — линия жизни объекта. Линия жизни объекта — это вертикальная пунктирная линия, которая обозначает период существования объекта. Большинство объектов существуют на протяжении всего взаимодействия, их линии жизни тянутся от вершины до основания диаграммы. Впрочем, объекты могут создаваться в ходе взаимодействия. Их линии жизни начинаются с момента приема сообщения «create». Кроме того, объекты могут уничтожаться в ходе взаимодействия. Их линии жизни заканчиваются с момента приема сообщения «destroy». Как представлено на рисунке А.13.30, уничтожение линии жизни отмечается пометкой X в конце линии:  Рисунок А.13.30 - Создание и уничтожение объекта Вторая характеристика — фокус управления. Фокус управления — это высокий тонкий прямоугольник, отображающий период времени, в течение которого объект выполняет действие (свою или подчиненную процедуру). Вершина прямоугольника отмечает начало действия, а основание — его завершение. Момент завершения может маркироваться сообщением возврата, которое показывается пунктирной стрелкой . Можно показать вложение фокуса управления (например, рекурсивный вызов собственной операции). Для этого второй фокус управления рисуется немного правее первого (рисунок А.13.31). Рисунок А.13.31 - Вложение фокусов управления Для отображения «условности» линия жизни может быть разделена на несколько параллельных линий жизни. Каждая отдельная линия соответствует условному ветвлению во взаимодействии. Далее в некоторой точке линии жизни могут быть снова слиты (рисунок А.13.32).  Рисунок А.13.32 - Параллельные линии жизни Ветвление показывается множеством стрелок, идущих из одной точки. Каждая стрелка отмечается сторожевым условием (рисунок А.13.33).  Рисунок А.13.33 – Ветвление   Рисунок А.13.34 - Диаграмма последовательности по прецеденту «Контролировать успеваемость студентов» А.14 Лабораторная работа 6 – 2ч. Моделирование компонентов Проектирование технического обеспечения системы. Уточнение состава перифирийной техники, аппаратной платформы и операционной среды ИС. Моделирование технической и программной системы на основе диаграмм компонентов и размещения. А.14.1 Цель работы - Спроектировать техническое обеспечение системы. Определить состав перифирийной техники, аппаратной платформы и операционной среды ИС, а также основные компоненты программного обеспечения. А.14.2 Предмет и содержание работы Предметом работы является проектирование технического обеспечения системы; уточнение состава перифирийной техники, аппаратной платформы и операционной среды ИС; моделирование технической и программной системы на основе диаграмм компонентов и размещения. При этом изучаются методы и средства построения диаграмм реализации – диаграмм компонентов и диаграмм размещения UML. Статические и динамические модели описывают логическую организацию системы, отражают логический мир программного приложения. Модели реализации обеспечивают представление системы в физическом мире, рассматривая вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах. Теоретические сведения содержатся в лекциях и литературе. А.14.3 Оборудование и технические средства Техническими средствами для выполнения работы являются средства лаборатории «Электронный офис», обеспечивающие доступ к сетевому серверу кафедры. А.14.4 Содержание и последовательность работы 1) Выполнить анализ архитектуры АИС с целью определения: - типа АИС; - состава комплекса технических средств (КТС-перифирийной техники и аппаратной платформы); - системного и прикладного ПО. 2) Выполнить описание технического и программного (в т.ч. системного и инструментального) обеспечения. 3) Выполнить следующие работы технического проектирования: - П11 Уточнение состава периферийной техники; - П12 Уточнение состава аппаратной платформы проекта. 4) Выявить компоненты технического и программного обеспечения АИС. 5) Построить диаграмму компонентов UML. 6) Построить диаграмму размещения компонентов UML. А.14.5 Требования к оформлению работы 1) Описание технического и программного (в т.ч. системного и инструментального) обеспечения (архитектуры и конкретных наименований и параметров технических и программных средств); 2) Диаграмма компонентов; 3) Диаграмма размещения. Отчет оформляется в виде принтерной распечатки с соблюдением требований ГОСТ 2.105 на листах формата A4. А.14.6 Методические указания к выполнению работы Статические и динамические модели описывают логическую организацию системы, отражают логический мир программного приложения. Модели реализации обеспечивают представление системы в физическом мире, рассматривая вопросы упаковки логических элементов в компоненты и размещения компонентов в аппаратных узлах. Компонентные диаграммы Компонентная диаграмма — первая из двух разновидностей диаграмм реализации, моделирующих физические аспекты объектно-ориентированных систем. Компонентная диаграмма показывает организацию набора компонентов и зависимости между компонентами. Элементами компонентных диаграмм являются компоненты и интерфейсы, а также отношения зависимости и реализации. Как и другие диаграммы, компонентные диаграммы могут включать примечания и ограничения. Кроме того, компонентные диаграммы могут содержать пакеты или подсистемы, используемые для группировки элементов модели в крупные фрагменты. |