Шпоры по ТООМ

1-АБСЭБ- 6

1. Средства языка UML для детализации поведения системы, описанного на диаграммах сценариев использования.

Создатели 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 - это согласованный блок функциональности, которую представляет система, подсистема или класс. Этот блок описывает последовательности сообщений, которыми обменивается система и один или несколько внешних пользователей (актеров), а также действия, осуществляемые при этом системой [UML]. Прецеденты являются описанием или вариантами использования системы. С помощью прецедента описывается некоторый процесс. К взаимодействию относятся только отношения между системой и актерами; внутреннее поведение и реализация системы скрыты.

Разработка, управляемая прецедентами

В Rational Unified Process "красной нитью", объединяющей систему при выполнении отдельных задач, являются прецеденты, которые определяют поведение системы. Одним из преимуществ Rational Unified Process является его "управляемый прецедентами подход". Это предполагает, что определенный для системы прецедент является основанием для всего процесса разработки.

Прецеденты играют роль в каждом из четырех основных потоков работ процесса: Требования, Анализ и проектирование, Выполнение и Испытание.

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

При создании диаграмм использования вначале определяются исполнители (роли, пользователи). Исполнитель (actor) является внешним по отношению к системе понятием, которое определенным образом участвует в процессе, описываемом прецедентом. Актер представляет собой некую идеализацию намерения пользователя, а не самого этого пользователя. Один реальный пользователь может соответствовать нескольким актерам, а один актер может представлять одно и то же намерение сразу нескольких пользователей.

Прецеденты представляют поведение системы. Каждый прецедент подробно описывается. Поток событий прецедентов показывает, как система шаг за шагом взаимодействует с субъектами и что делает система.

Объединяющая функция прецедентов прослеживается на всем протяжении цикла развития системы. Одна и та же модель прецедентов используется в потоках работ Требования, Анализ и проектирование и Испытания.

Диаграммы Use Cases включают отношения и ассоциации, показывающие взаимодействие между воздействующими объектами и функциями (изображаются в виде стрелок), и примечания (note), которые могут быть привязаны к любому объекту диаграммы Use Cases.

Рис.3.1.Диаграмма использования

Поток событий для прецедента

Поток событий (flow of events) – это последовательность событий, необходимых для обеспечения требуемого поведения. Поток событий описывается в терминах предметной области.

Если типичный ход событий можно представить в виде одной последовательности, очевидно, что в процессах может быть множество альтернативных вариантов реализации действий. В таком случае возникает проблема определения альтернативных прецедентов. Для этого в прецедент добавляются потоки для исключительных ситуаций (альтернативные потоки).

Между актером и прецедентом может существовать ассоциативное отношение. Ассоциативная связь может быть односторонней или двусторонней. Направление связи показывает, кто является ее инициатором (актер или прецедент). Существует два типа отношений между прецедентами: включает (include) и дополняет (extend). Отношение «включает» изображается как отношение зависимости , направленное от базового прецедента к используемому.

Отношение дополняет (extend relationship) применяется для отражения: дополнительных режимов; режимов, которые запускаются только при определенных условиях, например сигнала тревоги; альтернативных потоков, которые запускаются по выбору актера.

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

2. Основы работы над проектом в среде Rational Rose.

Rational Rose – семейство объектно-ориентированных CASE-средств фирмы Rational Software Corporation – предназначено для автоматизации процессов анализа и проектирования ПО, а также для генерации кодов на различных языках и выпуска проектной документации. Rational Rose использует метод объектно-ориентированного анализа и проектирования, основанный на языке UML. Текущая версия Rational Rose реализует генерацию кодов программ для С++, Visual C++, Visual Basic, Java, PowerBuilder, CORBA Interface Definition Language (IDL), генерацию описаний баз данных для ANSI SQL, Oracle, MS SQL Server, IBM DB2, Sybase, а также позволяет разрабатывать проектную документацию в виде диаграмм и спецификаций. Кроме того, Rational Rose содержит средства реверсного инжиниринга программ и баз данных, обеспечивающие повторное использование программных компонентов в новых проектах.

Структура и функции. В основе работы Rational Rose лежит построение диаграмм и спецификаций UML, определяющих архитектуру системы, её статические и динамические аспекты. В составе Rational Rose можно выделить шесть основных структурных компонентов: репозиторий, графический интерфейс пользователя, средства просмотра проекта (браузер), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кодов (индивидуальный для каждого языка) и анализатор для С++, обеспечивающий реверсный инжиниринг.

Репозиторий представляет собой базу данных проекта. Браузер обеспечивает “навигацию” по проекту, в том числе перемещение по иерархиям классов и подсистем, переключение от одного вида диаграмм к другому и т. д. Средства контроля и сбора статистики дают возможность находить и устранять ошибки по мере развития проекта, а не после завершения его описания. Генератор отчетов формирует тексты выходных документов на основе содержащейся в репозитории информации.

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

В результате разработки проекта с помощью CASE-средства Rational Rose формируются следующие документы: – диаграммы UML, в совокупности представляющие собой модель разрабатываемой программной системы; – спецификации классов, объектов, атрибутов и операций; – заготовки текстов программ.

Взаимодействие с другими средствами и организация групповой работы. Для поддержки командной работы над проектом на каждой стадии жизненного цикла ПО имеется интегрированный набор продуктов Rational Suite. Rational Suite существует в следующих вариантах: • Rational Suite AnalystStudio – предназначен для определения и управления полным набором требований к разрабатываемой системе; • Rational Suite DevelopmentStudio – предназначен для проектирования и реализации ПО; • Rational Suite TestStudio – представляет собой набор продуктов, предназначенных для автоматического тестирования приложений; • Rational Suite Enterprise – обеспечивает поддержку полного жизненного цикла ПО и предназначен как для менеджеров проекта, так и отдельных разработчиков, выполняющих несколько функциональных ролей в команде разработчиков. В состав Rational Suite, кроме Rational Rose, входят следующие компоненты: • Rational Requisite Pro – средство управления требованиями, предназначенное для организации совместной работы группы разработчиков. Оно позволяет команде разработчиков создавать, структурировать, устанавливать приоритеты, отслеживать, контролировать изменения требований, возникающих на любом этапе разработки компонентов приложения; • Rational ClearCase – средство управления конфигурацией ПО; • Rational SoDA – средство автоматической генерации проектной документации; • Rational ClearQuest – средство для управления изменениями и отслеживания дефектов в проекте на основе средств e-mail и Web; • Rational TeamTest – средство автоматического обнаружения ошибок во время выполнения программы и генерации сценариев для проведения регрессионного тестирования; • Rational Robot – средство для создания, модификации и автоматического запуска тестов; • Rational Purify – средство для локализации трудно обнаруживаемых ошибок времени выполнения программы; • Rational PureCoverage – средство идентификации участков кода, пропущенных при тестировании; • Rational Quantify – средство количественного определения узких мест, влияющих на общую эффективность работы программы; • Rational Suite PerformanceStudio – средство нагрузочного тестирования приложений «клиент-сервер» и Web-приложений. Для организации групповой работы в Rational Rose возможно разбиение модели на управляемые подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. В качестве подмодели может выступать пакет или подсистема.

1-АБСЭБ- 7

1. Модель сценариев использования. Значение сущностей: Актер, Сценарий использования; Описание архитектуры; Глоссарий.

Вариант использования представляет собой последовательность действий (транзакций), выполняемых системой в ответ на событие, инициируемое некоторым внешним объектом (действующим лицом). Вариант использования описывает типичное взаимодействие между пользователем и системой. Действующее лицо (actor) – это роль, которую пользователь играет по отношению к системе. Действующие лица представляют собой роли, а не конкретных людей или наименования работ. Показывать на диаграмме действующих лиц следует только в том случае, когда им действительно необходимы некоторые варианты использования.

Действующие лица делятся на три основных типа – пользователи системы, другие системы, взаимодействующие с данной, и время. Время становится действующим лицом, если от него зависит запуск каких-либо событий в системе. На рис. показан пример такой диаграммы для банкомата (Automated Teller Machine, ATM).

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

Конкретная цель диаграмм вариантов использования – это документирование вариантов использования (всё, входящее в сферу применения системы), действующих лиц (всё вне этой сферы) и связей между ними.

Варианты использования начинают описывать, что должна будет делать система. Цель – описать, что будет делать система, а не как она будет делать это. Связи между вариантами использования и действующими лицами. В языке UML на диаграммах вариантов использования поддерживается несколько типов связей между элементами диаграммы. Это связи коммуникации (communication), включения (include), расширения (extend) и обобщения (generalization). Связь коммуникации – это связь между вариантом использования и действующим лицом. На языке UML связи коммуникации показывают с помощью однонаправленной ассоциации (сплошной линии со стрелкой). Направление стрелки позволяет понять, кто инициирует коммуникацию. Связь включения применяется в тех ситуациях, когда имеется какой-либо фрагмент поведения системы, который повторяется более чем в одном варианте использования. С помощью таких связей обычно моделируют многократно используемую функциональность. Связь расширения применяется при описании изменений в нормальном поведении системы. Она позволяет варианту использования только при необходимости использовать функциональные возможности другого.

На языке UML связи включения и расширения показывают в виде зависимостей с соответствующими стереотипами. С помощью связи обобщения показывают, что у нескольких действующих лиц имеются общие черты. Например, клиенты могут быть двух типов: корпоративные и индивидуальные. Эту связь можно моделировать с помощью нотации, показанной на рис.

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

2. Примеры использования UML для построения визуальных моделей. Модель учебного процесса.

Стереотипы классов

Отношения

Разработка диаграмм классов

Диаграммы взаимодействия объектов

Диаграмма состояний класса «Учебный курс»

1-АБСЭБ- 8

1. Диаграммы компонент (Component diagram) и диаграммы размещения компонент (Deployment diagram).

Диаграммы реализации - диаграммы, с помощью которых описывается архитектура приложения, состоят из диаграмм компонентов и диаграмм развертывания. Диаграммы компонентов и развертывания предназначены для моделирования архитектуры приложения.

Компонента – исходный код, бинарный код или run-time объект.

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

Главная диаграмма компонентов обычно представляет определенные для системы пакеты.

Компоненты исходного кода – это программные файлы, содержащиеся внутри пакетов. Классы в логическом представлении отображаются на компоненты в представлении компонентов

Диаграмма развертывания

Бывает в форме описания (описание типов) и в форме инстанциации (описание объектов).

Узел может иметь следующую семантику:

Компьютерный ресурс

Механическое устройство

Человеческий ресурс

Диаграммы развертывания показывают распределение процессов и компонентов между процессорами. При помощи диаграмм развертывания документируется размещение программных модулей на узлах (физических и логических устройствах) системы.

Распределение процессов по узлам сети производится с учетом следующих факторов 

используемые образцы распределения (трехзвенная клиент- серверная конфигурация, «толстый » клиент , «тонкий » клиент , равноправные узлы и т.д.)

время отклика;

минимизация сетевого трафика;

мощность узла;

надежность оборудования и коммуникаций.

В UML существует несколько разновидностей класса: сущность, интерфейс и др. Для указания вида класса в UML введено понятие стереотипа. Существует стандартный набор стереотипов, который, при необходимости, можно расширять.

Основные стереотипы класса – это сущность, граничный элемент, элемент управления, сервисный элемент и исключение.

2. Тестирование системы. Роль фазы тестирования в жизненном цикле программного обеспечения. Корректировка модели.

Один из способов повысить качество программ – это стандартизация процесса разработки: ввести единообразные требования к этапам работ, документации, организовать регулярные совещания, проводить инспекцию кода и проч. Одним из первых продвижений на этом фронте стало введение понятия жизненного цикла программной системы, четко определявшее необходимость рассмотрения многих задач, без решения которых нельзя рассчитывать на успех программного проекта.

В простейшем варианте набор этапов жизненного цикла таков:

- анализ требований;

- проектирование (предварительное и детальное);

- кодирование и отладка ("программирование");

- тестирование;

- эксплуатация и сопровождение.

Стандартизованная схема жизненного цикла с четкой регламентацией необходимых работ и с перечнем соответствующей документации легла в основу так называемой «водопадной» или каскадной модели. Водопадная модель подразумевает жесткое разбиение процесса разработки программного обеспечения на этапы, причем переход с одного этапа на другой осуществляется только после того, как будут полностью завершены работы на предыдущем этапе. Каждый этап завершается выпуском полного комплекта документации, достаточной для того, чтобы разработка могла быть продолжена другой командой. Водопадная модель стала доминирующей в стандартах процессов разработки Министерства обороны США. Многие волей или неволей, даже отклоняясь от этой модели, в целом соглашались с ее разумностью и полезностью. Водопадная модель требовала точно и полно сформулировать все требования; изменение требований было возможно только после завершения всех работ. Водопадная модель не давала ответ на вопрос, что делать, когда требования меняются или меняется понимание этих требований непосредственно во время разработки.

В конце 80-х годов была предложена так называемая спиральная модель, был развит и проверен на практике метод итеративной и инкрементальной разработки (Iterative and Incremental Development, IID). В спиральной модели были учтены проблемы водопадной модели. Главный упор в спиральной модели делается на итеративности процесса. Описаны опыты использования IID с длиной итерации всего в полдня. Каждая итерация завершается выдачей новой версии программного обеспечения. На каждой версии уточняются (и, возможно, меняются) требования к целевой системе и принимаются меры к тому, чтобы удовлетворить и новые требования. В целом Rational Unified Process (RUP) также следует этой модели.

Концепции Rational Software Ink. предполагают объективно осуществляемое управление качеством. Оценка качества всех действий и их участников выполняется с использованием объективных измерений и критериев. Испытание (тестирование) качества производится на всех итерациях жизненного цикла.

Выделяют следующие рекомендации к разработке тестов:

- все необходимые тесты должны быть готовы к моменту реализации той или иной части программы; при этом обычно один тест соответствует одному требованию;

- совокупность ранее созданных тестов должна (при неизменных требованиях) выполняться на любой версии программы;

- если же в требования вносятся изменения, то тесты должны меняться максимально оперативно.

1-АБСЭБ- 9

1. Необходимость архитектуры системы. Описание архитектуры системы c использованием пакетов.

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

некоторой общностью. Существует несколько наиболее распространенных подходов к группировке. Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет с классами-сущностями, один с граничными классами, один с управляющими классами и т.д. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете.

Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования.

Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов

2. Генерация программного кода в нотации Java. Разработка Web- приложений с использованием UML.

Интернет-магазин позволяет делать покупки с доставкой на дом. Клиенты магазина при помощи программы-браузера имеют доступ к каталогу продаваемых товаров, поддержку которого осуществляет Интернет-магазин. По окончании выбора товаров производится оформление заказа и регистрация покупателя. Клиент указывает в регистрационной форме свою фамилию, имя и отчество, адрес доставки заказа и телефон, по которому с ним можно связаться для подтверждения сделанного заказа. Заказы передаются для обработки в систему автоматизации торговли. Проверка наличия товаров на складе и их резервирование Интернет-магазином не производятся. Дополнительно требуется разработать схему базы данных, хранящей заказы. Следует определиться, по какому архитектурному шаблону будет строиться Web-приложение («тонкий клиент» или «толстый клиент»). В соответствии с выбранным шаблоном следует построить модели клиентской части магазина и серверной части, промоделировать связи между частями приложения.

Для Web-приложений типичными являются следующие классы:

клиентская Web-страница;

серверная Web-страница (например, CGI-скрипт);

HTML-форма;

объект JavaScript.

Дополнительные связи между классами Web-приложений:

link – ссылка с одной страницы на другую;

build – связь между CGI-скриптом и клиентской страницей, генерируемой при его выполнении;

submit – связь между формой и серверной Web-страницей, принимающей данные из формы.

Типичные компоненты:

Web-страница (HTML-файл),

Active Server Page (ASP),

Java Server Page (JSP),

сервлет,

библиотека скриптов (например, подключаемый файл с Javascript-функциями).

1-АБСЭБ- 10

1. Средства нотации языка UML для описания статической структуры модели системы. Структурирование модели системы на пакеты, модели и подсистемы.

UML содержит стандартный набор диаграмм и нотаций самых разнообразных видов.

– диаграммы классов (class diagrams) – для моделирования статической структуры классов системы и связей между ними. На диаграммах классов изображаются также атрибуты классов, операции классов и ограничения, которые накладываются на связи между классами.

Стереотипы – это механизм, позволяющий разделять классы на категории. В языке UML определены три основных стереотипа классов: Boundary (граница), Entity (сущность) и Control (управление).

Структурирование модели системы на пакеты

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

некоторой общностью. Существует несколько наиболее распространенных подходов к группировке. Во-первых, можно группировать их по стереотипу. В таком случае получается один пакет с классами-сущностями, один с граничными классами, один с управляющими классами и т.д. Этот подход может быть полезен с точки зрения размещения готовой системы, поскольку все находящиеся на клиентских машинах пограничные классы уже оказываются в одном пакете.

Другой подход заключается в объединении классов по их функциональности. Например, в пакете Security (безопасность) содержатся все классы, отвечающие за безопасность приложения. В таком случае другие пакеты могут называться Employee Maintenance (Работа с сотрудниками), Reporting (Подготовка отчетов) и Error Handling (Обработка ошибок). Преимущество этого подхода заключается в возможности повторного использования.

Таким образом, диаграмма пакетов представляет собой диаграмму, содержащую пакеты классов и зависимости между ними. Строго говоря, пакеты и зависимости являются элементами диаграммы классов

2. Диаграммы деятельности (Activity diagram): простые и составные состояния деятельности, узлы принятия решений, распределение между классами объектов ответственности за деятельности.

Диаграммы деятельности

Определение деятельности изображается в виде диаграммы деятельности. Диаграммы действий отражают динамику проекта и представляют собой схемы потоков управления в системе от действия к действию, а также параллельные действия и альтернативные потоки.

В представлении деятельности используются конструкции, задающие синхронизацию. Выполнение этапов вычислений может быть как параллельным, так и последовательным.

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

В определении деятельности задаются узлы деятельности. Узел деятельности представляет выполнение оператора в процедуре или шага в потоке работ. Узлы соединяются между собой потоками управления и потоками данных. Выполнение узла деятельности обычно начинается, когда на каждом из его входных потоков появляются маркеры управления. Далее узел ожидает завершения своих вычислений. Когда выполнение узла завершается, управление передается узлам, связанным с выходными потоками данного узла. Потоки деятельности аналогичны переходам по завершению: переход управления происходит, когда завершается выполнение, но можно определить действия, которые будут происходить при наступлении конкретных событий.

Узлы деятельности могут быть вложенными. Диаграмма деятельности может иметь ветвления (branches), а также разделения (forking) управления между параллельными потоками. Параллельные потоки представляют собой элементы деятельности, которые объекты или люди могут совершать одновременно. Часто параллельность возникает в результате агрегации, когда у каждого объекта появляется свой собственный поток управления. Параллельные элементы деятельности могут осуществляться как одновременно, так и в любой последовательности.

В конечном счете, листами графа деятельности являются действия. Действием называется примитивная, предопределенная деятельность - например, чтение или изменение значения атрибута или ссылки, создание или разрушение объекта, отправка сигнала.

«Разделы». Иногда на диаграмме нужно соотносить элементы деятельности с ответственностью за них - например, сгруппировать вместе все элементы деятельности одной организации. Разделение ответственности можно изобразить, поделив всю диаграмму вна части (называемые разделами) вертикальными линиями. Линии делят диаграмму действий на несколько участков, чтобы показать, кто отвечает за выполнение действий на каждом участке.