сд.01_пиэ_о_проектирование ИС_12310-2010_8_1. Образовательный стандарт учебной дисциплины Проектирование информационных систем
 Скачать 7.87 Mb.
|
|
Процесс разработки (development process) предусматривает действия и задачи, выполняемые разработчиком, и охватывает работы по созданию ПС и его компонентов в соответствии с заданными требованиями, включая оформление проектной и эксплуатационной документации; подготовку материалов, необходимых для проверки работоспособности и соответствующего качества программных продуктов, материалов, необходимых для организации обучения персонала, и т. д. 1. Подготовительная работа начинается с выбора модели ЖЦ ПС, соответствующей масштабу, значимости и сложности проекта. Действия и задачи процесса разработки должны соответствовать выбранной модели. Разработчик должен выбрать, адаптировать к условиям проекта и использовать согласованные заказчиком стандарты, методы и средства разработки, а также составить план выполнения работ. 2.Анализ требований к системе подразумевает определение ее функциональных возможностей, пользовательских требований, требований к надежности и безопасности, требований к внешним интерфейсам и т. д. Требования к системе оцениваются исходя из критериев реализуемости и возможности проверки при тестировании. 3.Проектирование архитектуры системы на высоком уровни заключается в определении компонентов ее оборудования, ПС операций, выполняемых эксплуатирующим систему персоналом.. Архитектура системы должна соответствовать требованиям предъявляемым к системе, а также принятым проектным стандартам и методам. 4.Анализ требований к ПО предполагает определение следующих характеристик для каждого компонента ПС:
Требования к ПС оцениваются исходя из критериев соответствия требованиям к системе, реализуемости и возможности проверки при тестировании. 5.Проектирование архитектуры ПС включает следующие задачи (для каждого компонента ПС):
Архитектура компонентов ПС должна соответствовать требованиям, предъявляемым к ним, а также принятым проектным стандартам и методам. 6.Детальное проектирование ПС включает следующие задачи:
7.Кодирование и тестирование ПС охватывают следующие дачи:
8.Интеграция ПС предусматривает сборку разработанных компонентов ПС в соответствии с планом интеграции и тестирование агрегированных компонентов. Для каждого из агрегированных компонентов разрабатываются наборы тестов и тестов процедуры, предназначенные для проверки каждого из квалификационных требований при последующем квалификационном тестировании. Квалификационное требование — это набор критериев или условий, которые необходимо выполнить, чтобы квалифицировать программный продукт как соответствующий се им спецификациям и готовый к использованию в условиях эксплуатации. 9.Квалификационное тестирование ПС проводится разработчиком в присутствии заказчика (по возможности) для демонстрации того, что ПС удовлетворяет своим спецификациям и готово к использованию в условиях эксплуатации. Квалификационное тестирование выполняется для каждого компонента ПС по разделам требований при широком варьировании тестов. При этом также проверяются полнота технической и пользователе кой документации и ее адекватность самим компонентам ПС. 10.Интеграция системы заключается в сборке всех ее компонентов, включая ПС и оборудование. После интеграции система, свою очередь, подвергается квалификационному тестированию на соответствие совокупности требований к ней. При этом также производятся оформление и проверка полного комплекта документации на систему. 11.Установка ПС осуществляется разработчиком в соответствии с планом в той среде и на том оборудовании, которые предусмотрены договором. В процессе установки проверяется работоспособность ПС и баз данных. Если устанавливаемое ПС заменяет существующую систему, разработчик должен обеспечить их параллельное функционирование в соответствии с договором. 12.Приемка ПС предусматривает оценку результатов квалификационного тестирования ПС и системы и документирование результатов оценки, которые проводятся заказчиком с помощью разработчика. Разработчик выполняет окончательную передачу ПС заказчику в соответствии с договором, обеспечивая при этом необходимое обучение и поддержку. А.10 Лабораторная работа 10 – 4ч. Разработка функциональной структуры и перечня задач, моделей бизнес - прецедентов предметной области и прецедентов разрабатываемой информационной системы с использованием средств MS Visio А.10.1 Цель работы – выполнение первых трех этапов ТСП выполнения работ на этапе технического проектирования и моделирование функциональных требований к информационной системе с использованием языка UML. А.10.2 Предмет и содержание работы Предметом работы являются методы и средства проектирования и построения диаграмм бизнес - прецедентов (вариантов использования, use case) предметной области. Теоретические сведения содержатся в лекциях и литературе. А.10.3 Оборудование и технические средства Техническими средствами для выполнения работы являются средства лаборатории «Электронный офис», обеспечивающие доступ к сетевому серверу кафедры. А.10.4 Содержание и последовательность работы 1) Выполнить работы этапа П1стадии технического проектирования (ТП) «Разработка основных положений по новой системе» 2) Выполнить работы этапа П2 стадии технического проектирования (ТП) «Изменение организационной структуры». 3) Выполнить работы этапа П3 стадии технического проектирования (ТП) «Разработка функциональной структуры и перечня задач» (доработать функциональную матрицу). 2) Изучить основные особенности и понятия объектного подхода к анализу и проектированию ИС. В процессе изучения использовать материалы из курса лекций, а также литературу; 3) Изучить основные понятия и возможности построения use case диаграмм в системе MS Visio; 5) Построить use case модель (диаграмму прецедентов) требований к информационной системе и сделать ее описание; 6) Защитить работу. В процессе защиты лабораторной работы необходимо представить отчет, продемонстрировать построенные модели, и ответить на контрольные вопросы. А.10.5 Требования к оформлению работы 1) Основные положения по ЭИС. Краткое описание (эскизный проект) ЭИС; 2) Организационная структура, описание организационной структуры; 3) Функциональная структура и перечень задач (Функциональная матрица); 4) Модели функционирования в виде use case - диаграмм. Отчет оформляется в виде принтерной распечатки с соблюдением требований ГОСТ 2.105 на листах формата A4. А.10.6 Методические указания к выполнению работы Различают структурно-ориентированный (функционально-ориентированный) и объектно-ориентированный подходы к проектированию ИС. Принципиальное различие между структурным и объектно-ориентированным подходом заключается в способе декомпозиции системы. Объектно-ориентированный подход использует объектную декомпозицию, при этом статическая структура системы описывается в терминах объектов и связей между ними, а поведение системы описывается в терминах обмена сообщениями между объектами. Каждый объект системы обладает своим собственным поведением, моделирующим поведение объекта реального мира. Понятие «объект» впервые было использовано около 30 лет назад в технических средствах при попытках отойти от традиционной архитектуры фон Неймана и преодолеть барьер между высоким уровнем программных абстракций и низким уровнем абстрагирования на уровне компьютеров. С объектно-ориентированной архитектурой также тесно связаны объектно-ориентированные операционные системы. Однако наиболее значительный вклад в объектный подход был внесен объектными и объектно-ориентированными языками программирования: C#, Object Pascal. На объектный подход оказали влияние также развивавшиеся достаточно независимо методы моделирования баз данных, в особенности подход «сущность-связь». Концептуальной основой объектно-ориентированного подхода является объектная модель. Основными ее элементами являются: - абстрагирование (abstraction); - инкапсуляция (encapsulation); - модульность (modularity); - иерархия (hierarchy). Абстрагирование — это выделение существенных характеристик некоторого объекта, которые отличают его от всех других видов объектов и, таким образом, четко определяют его концептуальные границы относительно дальнейшего рассмотрения и анализа. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности его поведения от деталей их реализации. Выбор правильного набора абстракций для заданной предметной области представляет собой главную задачу объектно-ориентированного проектирования. Инкапсуляция - это процесс отделения друг от друга отдельных элементов объекта, определяющих его устройство и поведение. Инкапсуляция служит для того, чтобы изолировать интерфейс объекта, отражающий его внешнее поведение, от внутренней реализации объекта. Объектный подход предполагает, что собственные ресурсы, которыми могут манипулировать только методы самого класса, скрыты от внешней среды. Абстрагирование и инкапсуляция являются взаимодополняющими операциями: абстрагирование фокусирует внимание на внешних особенностях объекта, а инкапсуляция (или, иначе, ограничение доступа) не позволяет объектам-пользователям различать внутреннее устройство объекта. Модульность — это свойство системы, связанное с возможностью ее декомпозиции на ряд внутренне связных, но слабо связанных между собой модулей. Инкапсуляция и модульность создают барьеры между абстракциями. Иерархия — это ранжированная или упорядоченная система абстракций, расположение их по уровням. Основными видами иерархических структур применительно к сложным системам являются структура классов (иерархия по номенклатуре) и структура объектов (иерархия по составу). Примерами иерархии классов являются простое и множественное наследование (один класс использует структурную или функциональную часть соответственно одного или нескольких других классов), а иерархии объектов — агрегация. Основные понятия объектно-ориентированного подхода — объект и класс. Объект определяется как осязаемая реальность (tangible entity) - предмет или явление, имеющие четко определяемое поведение. Объект обладает состоянием, поведением и индивидуальностью; структура и поведение схожих объектов определяют общий для них класс. Термины «экземпляр класса» и «объект»' являются эквивалентными. Состояние объекта характеризуется перечнем всех возможных (статических) свойств данного объекта и текущими значениями (динамическими) каждого из этих свойств. Поведение характеризует воздействие объекта на другие объекты и наоборот относительно изменения состояния этих объектов и передачи сообщений. Иначе говоря, поведение объекта полностью определяется его действиями. Индивидуальность - это свойства объекта, отличающие его от всех других объектов. Определенное воздействие одного объекта на другой с целью вызвать соответствующую реакцию называется операцией. Как правило, в объектных и объектно-ориентированных языках операции, выполняемые над данным объектом, называются методами и являются составной частью определения класса. Класс — это множество объектов, связанных общностью структуры и поведения. Любой объект является экземпляром класса. Определение классов и объектов — одна из самых сложных задач объектно-ориентированного проектирования. Следующую группу важных понятий объектного подхода составляют наследование и полиморфизм. Понятие полиморфизма может быть интерпретировано как способность класса принадлежать более чем одному типу. Наследование означает построение новых классов на основе существующих с возможностью добавления или переопределения данных и методов. УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ UML Большинство существующих методов объектно-ориентированного анализа и проектирования (ООАП) включают как язык моделирования, так и описание процесса моделирования. Язык моделирования — это нотация (в основном графическая), которая используется методом для описания проектов. Нотация представляет собой совокупность графических объектов, которые используются в моделях; она является синтаксисом языка моделирования. Например, нотация диаграммы классов определяет, каким образом представляются такие элементы и понятия, как класс, ассоциация и множественность. Процесс — это описание шагов, которые необходимо выполнить при разработке проекта. Унифицированный язык моделирования UML (Unified Modeling Language) — это преемник того поколения методов ООАП, которые появились в конце 80-х и начале 90-х гг. Создание UML фактически началось в конце 1994 г., когда Гради Буч и Джеймс Рамбо начали работу по объединению методов Booch и ОМТ (Object Modeling Technique) под эгидой компании Rational Software. Главными в разработке UML были следующие цели: - предоставить пользователям готовый к использованию выразительный язык визуального моделирования, позволяющий разрабатывать осмысленные модели и обмениваться ими; - предусмотреть механизмы расширяемости и специализации для расширения базовых концепций; - обеспечить независимость от конкретных языков программирования и процессов разработки; - обеспечить формальную основу для понимания этого языка моделирования (язык должен быть одновременно точным и доступным для понимания, без лишнего формализма); - стимулировать рост рынка объектно-ориентированных инструментальных средств; - интегрировать лучший практический опыт. Язык UML находится в процессе стандартизации, проводимом OMG (Object Management Group) - организацией по стандартизации в области объектно-ориентированных методов и технологий, в настоящее время принят в качестве стандартного языка моделирования и получил широкую поддержку в индустрии ПО. Язык UML принят на вооружение практически всеми крупнейшими компаниями - производителями ПО (Microsoft, IBM, Hewlett-Packard, Oracle, Sybase и др.). Кроме того, практически все мировые производители CASE-средств, помимо Rational Software (Rational Rose), поддерживают UML в своих продуктах (Paradigm Plus 3.6, System Architec, Microsoft Visual Modeler for Visual Basic, Delphi, PowerBuilder и др.). Создатели UML представляют его как язык для определения, представления, проектирования и документирования программных систем, организационно-экономических, технических и др. UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов. Стандарт UML версии 1.1, принятый OMG в 1997 г., предлагает следующий набор диаграмм для моделирования: - диаграммы вариантов использования (use case diagrams) для моделирования бизнес-процессов организации (требований к системе); - диаграммы классов (class diagrams) для моделирования статической структуры классов системы и связей между ними; - диаграммы поведения системы (behavior diagrams); - диаграммы взаимодействия (interaction diagrams) для моделирования процесса обмена сообщениями между объектами. Существуют два вида диаграмм взаимодействия: диаграммы последовательности (sequence diagrams) и кооперативные диаграммы (collaboration diagrams); - диаграммы состояний (statechart diagrams) для моделирования поведения объектов системы при переходе из одного состояния в другое; - диаграммы деятельностей (activity diagrams) для моделирования поведения системы в рамках различных вариантов использования или моделирования деятельностей; - диаграммы реализации (implementation diagrams); - диаграммы компонентов (component diagrams) для моделирования иерархии компонентов (подсистем) системы; - диаграммы размещения (deployment diagrams) для моделирования физической архитектуры системы. ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ (USE CASE) В течение достаточно длительного периода времени в процессе как объектно-ориентированного, так и традиционного структурного проектирования разработчики использовали типичные сценарии, помогающие лучше понять требования к системе. Эти сценарии трактовались весьма неформально — они почти всегда использовались и крайне редко документировались. Ивар Якобсон впервые ввел понятие "вариант использования" (use case) и придал ему такую значимость, что он превратился в основной элемент разработки и планирования проекта. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта использования обычного текстового процессора - "сделать некоторый текст полужирным" и "создать индекс". Даже на таком простом примере можно выделить ряд свойств варианта использования: он охватывает некоторую очевидную для пользователей функцию, может быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу. В простейшем случае вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать. Когда Якобсон в 1994 г. предложил варианты использования в качестве основных элементов процесса разработки ПО, он также предложил применять для их наглядного представления диаграммы вариантов использования. На рисунке А.10.1 показан пример диаграммы use case.  Рисунок А.10.1 – Диаграмма вариантов использования Человеческие фигурки здесь обозначают действующих лиц, овалы - варианты использования, а линии и стрелки - различные связи между действующими лицами и вариантами использования. Действующее лицо (actor) — это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Несмотря на то, что на диаграммах вариантов использования они изображаются в виде стилизованных человеческих фигурок, действующее лицо может также быть внешней системой, которой необходима некоторая информация от данной системы (например, система учета). Показывать на диаграмме действующих лиц системы следует только в том случае, когда им действительно необходимы некоторые варианты использования. Все варианты использования так или иначе связаны с внешними требованиями к функциональности системы. Если системе учета требуется файл, то это требование должно быть удовлетворено. Варианты использования всегда следует анализировать вместе с действующими лицами системы, определяя при этом реальные задачи пользователей и рассматривая альтернативные способы решения этих задач. Действующие лица могут играть различные роли по отношению к варианту использования. Они могут пользоваться его результатами или могут сами непосредственно в нем участвовать. Значимость раз личных ролей действующего лица зависит от того, каким образом используются его связи. Хорошим источником для идентификации вариантов использования служат внешние события. Следует начать с перечисления всех событий, происходящих во внешнем мире, на которые система должна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешательства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагировать, помогает выделить варианты использования. В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования: - Отношение ассоциации (association relationship); - Отношение обобщения (generalization relationship); - Отношение зависимости, наиболее встречающиеся ее стереотипы: - Отношение расширения (extend relationship); - Отношение включения / использования (include relationship). - Отношения реализации. Отношение ассоциации Отношение ассоциации является одним из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. Применительно к диаграммам вариантов использования оно служит для обозначения специфической роли актера в отдельном варианте использования. Другими словами, ассоциация специфицирует семантические особенности взаимодействия актеров и вариантов использования в графической модели системы. Таким образом, это отношение устанавливает, какую конкретную роль играет актер при взаимодействии с экземпляром варианта использования. На диаграмме вариантов использования, так же как и на других диаграммах, отношение ассоциации обозначается сплошной линией между актером и вариантом использования. Эта линия может иметь дополнительные условные обозначения, такие, например, как имя и кратность.  Рисунок А.10.2 - Пример графического представления отношения ассоциации между актером и вариантом использования Кратность (multiplicity) ассоциации указывается рядом с обозначением компонента диаграммы, который является участником данной ассоциации. Кратность характеризует общее количество конкретных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации. Применительно к диаграммам вариантов использования кратность имеет специальное обозначение в форме одной или нескольких цифр и, возможно, специального символа "*" (звездочка). Возвращаясь к общей теории множеств, следует заметить, что кратность представляет собой мощность множества экземпляров сущности, участвующей в данной ассоциации. Что касается самого понятия ассоциации, то это одна из наиболее общих форм отношений в языке UML. Для диаграмм вариантов использования наиболее распространенными являются четыре основные формы записи кратности отношения ассоциации: - Целое неотрицательное число (включая цифру 0). Предназначено для указания кратности, которая является строго фиксированной для элемента соответствующей ассоциации. В этом случае количество экземпляров актеров или вариантов использования, которые могут выступать в качестве элементов отношения ассоциации, в точности равно указанному числу. Примером этой формы записи кратности ассоциации является указание кратности "1" для актера "Клиент банка" (рисунок А.10.2). Эта запись означает, что каждый экземпляр варианта использования "Оформить кредит для клиента банка" может иметь в качестве своего элемента единственный экземпляр актера "Клиент банка". Другими словами, при оформлении кредита в банке необходимо иметь в виду, что каждый конкретный кредит оформляется на единственного клиента этого банка. - Два целых неотрицательных числа, разделенные двумя точками и записанные в виде: "первое число .. второе число". Данная запись в языке UML соответствует нотации для множества или интервала целых чисел, которая применяется в некоторых языках программирования для обозначения границ массива элементов. Эту запись следует понимать как множество целых неотрицательных чисел, следующих в последовательно возрастающем порядке: {первое_число, первое_число+1, первое_число+2, ..., второе_число]. Очевидно, что первое число должно быть строго меньше второго числа в арифметическом смысле, при этом первое число может быть равно 0. Пример такой формы записи кратности ассоциации - "1..5". Эта запись означает, что количество отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации, равно некоторому заранее неизвестному числу из множества целых чисел {1, 2, 3, 4, 5}. Эта ситуация может иметь место, например, в случае рассмотрения в качестве актера - клиента банка, а в качестве варианта использования - процедуру открытия счета в банке. При этом количество отдельных счетов каждого клиента в данном банке, исходя из некоторых дополнительных соображений, может быть не больше 5. Эти дополнительные соображения как раз и являются внешними требованиями по отношению к проектируемой системе и определяются ее заказчиком на начальных этапах ООАП. - Два символа, разделенные двумя точками. При этом первый из них является целым неотрицательным числом или 0, а второй - специальным символом "*". Здесь символ "*"обозначает произвольное конечное целое неотрицательное число, значение которого неизвестно на момент задания соответствующего отношения ассоциации. Пример такой формы записи кратности ассоциации - "2..*". Запись означает, что количество отдельных экземпляров данного компонента, которые могут выступать в качестве элементов данной ассоциации, равно некоторому заранее неизвестному числу из подмножества натуральных чисел. - Единственный символ "*", который является сокращением записи интервала "0..*". В этом случае количество отдельных экземпляров данного компонента отношения ассоциации может быть любым целым неотрицательным числом. При этом 0 означает, что для некоторых экземпляров соответствующего компонента данное отношение ассоциации может вовсе не иметь места. В качестве примера этой записи можно привести кратность отношения ассоциации для варианта использования "Оформить кредит для клиента банка". Здесь кратность "*" означает, что каждый отдельный клиент банка может оформить для себя несколько кредитов, при этом их общее число заранее неизвестно и ничем не ограничивается. При этом некоторые клиенты могут совсем не иметь оформленных на свое имя кредитов (вариант значения 0). Если кратность отношения ассоциации не указана, то по умолчанию принимается ее значение, равное 1. Отношение обобщения Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом В называется предком или родителем по отношению А, а вариант А - потомком по отношению к варианту использования В. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования (см. рисунок А.10.3). Эта линия со стрелкой имеет специальное название - стрелка "обобщение".  Рисунок А.10.3 - Пример графического изображения отношения обобщения между вариантами использования Отношение обобщения между вариантами использования применяется в том случае, когда необходимо отметить, что дочерние варианты использования обладают всеми атрибутами и особенностями поведения родительских вариантов. При этом дочерние варианты использования участвуют во всех отношениях родительских вариантов. В свою очередь, дочерние варианты могут наделяться новыми свойствами поведения, которые отсутствуют у родительских вариантов использования, а также уточнять или модифицировать наследуемые от них свойства поведения. Применительно к данному отношению, один вариант использования может иметь несколько родительских вариантов. В этом случае реализуется множественное наследование свойств и поведения отношения предков: С другой стороны, один вариант использования может быть предком для нескольких дочерних вариантов, что соответствует таксономическому характеру отношения обобщения. Между отдельными актерами также может существовать отношение обобщения. Данное отношение является направленным и указывает на факт специализации одних актеров относительно других. Например, отношение обобщения от актера А к актеру В отмечает тот факт, что каждый экземпляр актера А является одновременно экземпляром актера В и обладает всеми его свойствами. В этом случае актер В является родителем по отношению к актеру А, а актер А, соответственно, потомком актера В. При этом актер А обладает способностью играть такое же множество ролей, что и актер В. Графически данное отношение также обозначается стрелкой обобщения, т. е. сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительского актера. Отношение зависимости Зависимость — семантическое отношение между двумя предметами, в котором изменение в одном предмете (независимом предмете) может влиять на семантику другого предмета (зависимого предмета). Как показано на рисунке А.10.4, зависимость изображается в виде пунктирной линии, возможно направленной на независимый предмет и иногда имеющей метку.  Рисунок А.10.4 - Графическое изображение отношения зависимости Отношение расширения Отношение расширения определяет взаимосвязь экземпляров отдельного варианта использования с более общим вариантом, свойства которого определяются на основе способа совместного объединения данных экземпляров. В метамодели отношение расширения является направленным и указывает, что применительно к отдельным примерам некоторого варианта использования должны быть выполнены конкретные условия, определенные для расширения данного варианта использования. Так, если имеет место отношение расширения от варианта использования А к варианту использования В, то это означает, что свойства экземпляра варианта использования В могут быть дополнены благодаря наличию свойств у расширенного варианта использования А. Отношение расширения между вариантами использования обозначается линией со стрелкой (вариант отношения зависимости), направленной от того варианта использования, который является расширением для исходного варианта использования. Данная линия со стрелкой помечается ключевым словом "extend" ("расширяет"), как показано на рисунке А.10.5.  Рисунок А.10.5 - Пример графического изображения отношения расширения между вариантами использования Отношение расширения отмечает тот факт, что один из вариантов использования может присоединять к своему поведению некоторое дополнительное поведение, определенное для другого варианта использования. Данное отношение включает в себя некоторое условие и ссылки на точки расширения в базовом варианте использования. Чтобы расширение имело место, должно быть выполнено определенное условие данного отношения. Ссылки на точки расширения определяют те места в базовом варианте использования, в которые должно быть помещено соответствующее расширение при выполнении условия. Один из вариантов использования может быть расширением для нескольких базовых вариантов, а также иметь в качестве собственных расширений несколько других вариантов. Базовый вариант использования может дополнительно никак не зависеть от своих расширений. Семантика отношения расширения определяется следующим образом. Если экземпляр варианта использования выполняет некоторую последовательность действий, которая определяет его поведение, и при этом имеется точка расширения на экземпляр другого варианта использования, которая является первой из всех точек расширения у исходного варианта, то проверяется условие данного отношения. Если условие выполняется, исходная последовательность действий расширяется посредством включения действий экземпляра другого варианта использования. Следует заметить, что условие отношения расширения проверяется лишь один раз - при первой ссылке на точку расширения, и если оно выполняется, то все расширяющие варианты использования вставляются в базовый вариант. Отношение включения / использования Отношение включения между двумя вариантами использования указывает, что некоторое заданное поведение для одного варианта использования включается в качестве составного компонента в последовательность поведения другого варианта использования. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров вариантов использования всегда упорядочена в отношении включения. Семантика этого отношения определяется следующим образом. Когда экземпляр первого варианта использования в процессе своего выполнения достигает точки включения в последовательность поведения экземпляра второго варианта использования, экземпляр первого варианта использования выполняет последовательность действий, определяющую поведение экземпляра второго варианта использования, после чего продолжает выполнение действий своего поведения. При этом предполагается, что даже если экземпляр первого варианта использования может иметь несколько включаемых в себя экземпляров других вариантов, выполняемые ими действия должны закончиться к некоторому моменту, после чего должно быть продолжено выполнение прерванных действий экземпляра первого варианта использования в соответствии с заданным для него поведением. Один вариант использования может быть включен в несколько других вариантов, а также включать в себя другие варианты. Включаемый вариант использования может быть независимым от базового варианта в том смысле, что он предоставляет последнему некоторое инкапсулированное поведение, детали реализации которого скрыты от последнего и могут быть легко перераспределены между несколькими включаемыми вариантами использования. Более того, базовый вариант может зависеть только от результатов выполнения включаемого в него поведения, но не от структуры включаемых в него вариантов. Отношение включения, направленное от варианта использования А к варианту использования В, указывает, что каждый экземпляр варианта А включает в себя функциональные свойства, заданные для варианта В. Эти свойства специализируют поведение соответствующего варианта А на данной диаграмме.  Рисунок А.10.6 - Пример графического изображения отношения включения (использования) между вариантами использования Итак, к отношениям зависимости между прецедентами применимы два стереотипа: 1) extend - показывает, что целевой прецедент расширяет поведение исходного; 2) include (use) - говорит о том, что исходный прецедент явным образом включает в себя поведение целевого. Связь типа «расширение» применяется тогда, когда один вариант использования подобен другому, но несет несколько большую нагрузку. В данном примере основным вариантом использования является «Заключить сделку». В этом варианте предполагается нормальный ход процесса. Однако в случае превышения некоторого лимита — например, максимальной суммы торговой сделки, установленной для конкретного клиента, процесс, связанный с данным вариантом использования, не может выполняться обычным образом и должен претерпеть некоторое изменение. Такое изменение можно предусмотреть в рамках основного варианта использования «Заключить сделку». Однако такой подход может привести к загромождению варианта использования разной «побочной» логикой, за которой теряется его «нормальная» логика. Другой способ учесть изменение — это поместить нормальный процесс в рамки одного варианта использования, а все отклонения от него — в другие варианты. Связь «использование» применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования, и нет необходимости копировать его описание в каждом из этих вариантов. Например, варианты Проанализировать риск и Договориться о цене требуют оценки стоимости сделки. Таким образом, создается отдельный вариант использования под названием «Оценка стоимости», и предыдущие два варианта будут на него ссылаться. Отметим сходства и различия между связями «расширение» и «использование». Оба они предполагают выделение общих фрагментов поведения из нескольких вариантов использования в единственный вариант, который «используется» или «расширяет» несколько других вариантов. С другой стороны, в каждом случае это делается с различными целями. Два типа связей подразумевают различный смысл связей с действующими лицами. В случае «расширения» у действующих лиц имеется связь с основным вариантом использования. При этом предполагается, что данное действующее лицо реализует как основной вариант использования, так и все его расширения. В случае применения связи «использование» действующие лица, связанные с общим вариантом использования, как правило, отсутствуют. Даже если имеются исключения, то такое действующее лицо не имеет отношения к реализации других вариантов использования. Выбор применяемой связи определяется следующими правилами: - связь «расширение» следует применять при описании изменений в нормальном поведении системы; - связь «использование» следует применять для избежания повторов в двух (или более) вариантах использования. Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию. Отношение реализации Реализация — семантическое отношение между классификаторами, где один классификатор определяет контракт, который другой классификатор обязуется выполнять (к классификаторам относят классы, интерфейсы, компоненты, элементы Use Case, кооперации). Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их. Как показано на рисунке А.10.7, реализация изображается как нечто среднее между обобщением и зависимостью.  Рисунок А.10.7 - Графическое изображение отношения реализации Приведем примеры построения use case диаграмм ..   Рисунок А.10.8 – примеры диаграмм прецедентов А.11 Лабораторная работа 11 – 2ч. Моделирование бизнес классов предметной области и информационное обеспечение автоматизированной системы А.11.1 Цель работы – разработка информационного обеспечения ЭИС системы, моделирование бизнес классов с использованием языка UML. А.11.2 Предмет и содержание работы Предметом работы являются методы и средства создания информационного обеспечения и построения диаграмм бизнес классов предметной области. Теоретические сведения содержатся в лекциях и литературе. А.11.3 Оборудование и технические средства Техническими средствами для выполнения работы являются средства лаборатории «Электронный офис», обеспечивающие доступ к сетевому серверу кафедры. А.11.4 Содержание и последовательность работы 1. Выполнить следующие работы технического проектирования: - П4 (разработка принципов организации информационного обеспечения и внутримашинной информационной базы); - П6 (разработка форм документов и системы их ведения); - П7 (разработка классификаторов и кодов); - П8 (разработка структуры входных и выходных сообщений); - П9 (разработка макетов и структур файлов). 2) Описать бизнес классы предметной области и построить диаграммы UML в Microsoft Visio. 3) Построить ERD диаграммы. 4) Защитить работу. В процессе защиты лабораторной работы необходимо представить отчет, продемонстрировать построенные модели на экране, и ответить на контрольные вопросы. А.11.5 Требования к оформлению работы В отчете должны содержаться следующие пункты:
Отчет оформляется в виде принтерной распечатки с соблюдением требований ГОСТ 2.105 на листах формата A4. А.11.6 Методические указания к выполнению работы Информационное обеспечение ИС является средством для решения следующих задач: - однозначного и экономичного представления информации в системе (на основе кодирования объектов); - организации процедур анализа и обработки информации с учетом характера связей между объектами (на основе классификации объектов); - организации взаимодействия пользователей с системой (на основе экранных форм ввода-вывода данных); - обеспечения эффективного использования информации в контуре управления деятельностью объекта автоматизации (на основе унифицированной системы документации). Информационное обеспечение ИС включает два комплекса: - внемашинное информационное обеспечение (классификаторы технико-экономической информации, документы, методические инструктивные материалы); - внутримашинное информационное обеспечение (макеты/экранные формы для ввода первичных данных в ЭВМ или вывода результатной информации, структуры информационной базы: входных, выходных файлов, базы данных). К информационному обеспечению предъявляются следующие общие требования: - информационное обеспечение должно быть достаточным для поддержания всех автоматизируемых функций объекта; - для кодирования информации должны использоваться принятые у заказчика классификаторы; - для кодирования входной и выходной информации, которая используется на высшем уровне управления, должны быть использованы классификаторы этого уровня; - должна быть обеспечена совместимость с информационным обеспечением систем, взаимодействующих с разрабатываемой системой; - формы документов должны отвечать требованиям корпоративных стандартов заказчика (или унифицированной системы документации); - структура документов и экранных форм должна соответствовать характеристиками терминалов на рабочих местах конечных пользователей; - графики формирования и содержание информационных сообщений, а также используемые аббревиатуры должны быть общеприняты в этой предметной области и согласованы с заказчиком; - в ИС должны быть предусмотрены средства контроля входной и результатной информации, обновления данных в информационных массивах, контроля целостности информационной базы, защиты от несанкционированного доступа. Информационное обеспечение ИС можно определить как совокупность единой системы классификации, унифицированной системы документации и информационной базы. |