Алгоритм выполнения работы

Методические указания по выполнению

Практическая работа № 1-2

по дисциплине МДК 03.02 «Инструментальные средства разработки программного обеспечения»

 

Тема: Модели анализа требований к ПС

Цель: владеть нотациями языка визуального моделирования UML.

Средства, оборудование : инструментарий UML, ПК

Литература:

1. Орлов С. А. Технология разработки программного обеспечения, – СПб: Питер, 2003

2.Вендров А.М. Проектирование программного обеспечения экономических информационных систем. –Москва : Финансы и Статистика, 2002

 

Выполнение работы

 

Теоретическое обоснование

Диаграмма Use Case рассматривается как главное средство для первичного моде­лирования динамики системы, используется для выяснения требований к разра­батываемой системе, фиксации этих требований в форме, которая позволит про­водить дальнейшую разработку. Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Например, два типичных варианта ис­пользования обычного текстового процессора — "сделать некоторый текст полужирным" и "создать индекс". Даже на таком простом примере можно выделить ряд свойств варианта использования: он ухватывает некоторую очевидную для пользователей функцию, мо­жет быть как небольшим, так и достаточно крупным и решает для пользователя некоторую дискретную задачу. В простейшем случае" вариант использования определяется в процессе обсуждения с пользователем тех функций, которые он хотел бы реализовать.

В состав диаграмм Use Case прежде всего входят:

  • элементы Use Case ,
  • актеры,
  • отношения - зависимости, обобщения и ассоциации.

Как и другие диаграммы, диаграммы Use Case могут включать примечания и ограничения. Кроме того, диаграммы Use Case могут содержать пакеты, используемые для группировки элементов модели в круп­ные фрагменты.

Элемент Use Case — это описание последовательности действий (или нескольких последовательностей), которые выполняются системой и производят для отдель­ного актера видимый результат.

Один актер может использовать несколько элементов Use Case и наоборот, один элемент Use Case может иметь несколько актеров, использующих его. Каждый эле­мент Use Case задает определенный путь использования системы. Набор всех эле­ментов Use Case определяет полные функциональные возможности системы.

Варианты использования являются необходимым средством на стадии формирования требований к ПО. Каждый вариант использования — это потенциальное требование к системе, и пока оно не выявлено, невозможно запланировать его реализацию.

Хорошим источником для идентификации вариантов использо­вания служат внешние события. Следует начать с перечисления всех событий, происходящих во внешнем мире, на которые система дол­жна каким-то образом реагировать. Какое-либо конкретное событие может повлечь за собой реакцию системы, не требующую вмешатель­ства пользователей, или, наоборот, вызвать чисто пользовательскую реакцию. Идентификация событий, на которые необходимо реагироватъ, помогает выделить варианты использования.

Следует предпочитать неболь­шие и детализированные варианты использования, поскольку они об­легчают составление и реализацию согласованного плана проекта.

Отношения в диаграммах Use Case

Между актером и элементом Use Case возможен только один вид отношения — ассоциация, отображающая их взаимодействие (рис. 12.28). Как и любая другая ассоциация, она может быть помечена именем, ролями, мощностью.

Между актерами допустимо отношение обобщения (рис. 12.29), означающее, что экземпляр потомка может взаимодействовать с такими же разновидностями эк­земпляров элементов Use Case , что и экземпляр родителя.

Между элементами Use Case определены отношение обобщения и две разновид­ности отношения зависимости — включения и расширения.

Отношение обобщения (рис. 12.30) фиксирует, что потомок наследует поведение родителя. Кроме того, потомок может дополнить или переопределить поведение родителя. Элемент Use Case , являющийся потомком, может замещать элемент Use Case , являющийся родителем, в любом месте диаграммы.

Отношение включения (рис. 12.31) между элементами Use Case означает, что ба­зовый элемент Use Case явно_ включает поведение другого элемента Use Case в точке, которая определена в базе. Включаемый элемент Use Case никогда не использует­ся самостоятельно — его конкретизация может быть только частью другого, боль­шего элемента Use Case. Отношение включения является примером отношения делегации. При этом в отдельное место (включаемый элемент Use Case) помеща­ется определенный набор обязанностей системы. Далее остальные части системы могут агрегировать в себя эти обязанности (при необходимости).

Отношение расширения между элементами Use Case означает, что базо­вый элемент Use Case неявно включает поведение другого элемента Use Case в точ­ке, которая определяется косвенно расширяющим элементом Use Case. Базовый элемент Use Case может быть автономен, но при определенных условиях его поведение может расширяться поведением из другого элемента Use Case. Базовый элемент Use Case может расширяться только в определенных точках — точках расширения. Отношение расширения применяется для моделирования выбираемого поведения системы. Таким способом можно отделить обязательное поведение от необязатель­ного поведения. Например, можно использовать отношение расширения для отдель­ного подпотока, который выполняется только при определенных условиях, находя­щихся вне поля зрения базового элемента Use Case . Наконец, можно моделировать отдельные потоки, вставка которых в определенную точку управляется актером.

Пример 1 простейшей диаграммы Use Case , в которой использованы отношения включения и расширения, приведен на рис. 12.33.

Как показано на рис. 12.34, внутри элемента Use Case может быть дополнительная секция с заголовком Extension points. В этой области перечисляются точки расши­рения. В указанную здесь точку дополнительные запросы вставляется последова­тельность действий от расширяющего элемента Use Case «Запрос каталога». Для справ­ки отмечено, что точка расширения размещена после действий, обеспечивающих создание заказа. На этом же рисунке отображены отношения наследования между элементами Use Case . Видно, что элементы Use Case «Оплата наличными2 и «Оплата в кредит» наследуют поведение элемента Use Case «Произвести оплату» и являются его специализациями

Алгоритм выполнения работы

· Работа выполняется дуальной группой студентов (в составе 2-х человек) с применением компьютера

· Студенты сами выбирают предметную область и сами формулируют задачу. Умение «увидеть» задачу является важной составляющей профессионализма будущих программистов. Предполагается, что ими уже выполнена предыдущая практическая работа (№5) и необходимые навыки уже получены. В соответствии с задачей анализируется предметная область, выбираются актеры, определяется набор требований к будущей системе (элементы Use Case), составляется диаграмма Use Case. Желательно составление диаграммы выполнять на компьютере, с применением соответствующего инструментария.

· Постепенно диаграмма усложняется по мере уточнения требований и детализации

· Формируется отчет по работе – в электронном бумажном вариантах.

Задание (варианты, исходные данные и т.п.)

Предметная область и задача определяются студентом самостоятельно, по выбору.