Logo GenDocs.ru

Поиск по сайту:  

Загрузка...

Шпоры по ТООМ - файл bomb-twirpx.doc


Шпоры по ТООМ
скачать (859.3 kb.)

Доступные файлы (1):

bomb-twirpx.doc1335kb.02.05.2006 17:33скачать

содержание
Загрузка...

bomb-twirpx.doc

  1   2   3
Реклама MarketGid:
Загрузка...

1-АБСЭБ- 1


1. Основные характеристики объектно-ориентированного моделирования.

Принципы объектно-ориентированного анализа.

Объектно-ориентированная модель предметной области представляет собой совокупность диаграмм, описывающих с использованием универсального языка объектного проектирования языка UML различные аспекты структуры и поведения информационной системы.

Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграмма - это одна из проекций предметной области. Базисные конструкции унифицированного языка моделирования UML (сущности, отношения, диаграммы) приведены в руководстве разработчиков UML.

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

Снижение риска проектирования достигается за счет реализации ряда итераций разработки (так называемая спиральная модель жизненного цикла разработки). Каждая итерация может приводить к созданию фрагмента или новой версии модели и включает этапы выработки требований, анализа, проектирования, реализации и тестирования.

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

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

Класс - это множество предметов реального мира, связанных общностью структуры и поведением. Элемент класса - это конкретный элемент данного множества. Например, в сфере организационного управления существует класс организационно-распорядительных документов. Таким образом, объект - это типичный представитель класса, а термины "экземпляр объекта" и "элемент класса" равнозначны.

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

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

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

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

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

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

^ 2. Примеры использования UML для построения визуальных моделей. Модель системы электронной торговли
[ смотри в приложении ]




1-АБСЭБ- 2

^ 1. Системный подход к проектированию информационных систем. Визуальное моделирование.
При определении модели информационной системы за основу было взято понятие алгебраической системы [1], которая объединяет в себе совокупность абстрактных объектов, отношений между ними и систему операций T, задаваемых на основном множестве MA = <A, R, T>. В данной дисциплине системный подход к моделированию, учитывающий свойства элементов и отношений, опирается на определение системы, предложенное в А. И Умновым в [1], данное через понятия “вещи”, “свойства”, “отношения”:

S [{ai}&{rj(qj)}],

aiA, rjR, qjQR,

Sdef [{ai(qi)}&{rj}],

aiA, qiQA, rjR,

где ai – элементы (вещи); rj - отношения между элементами; qj – атрибуты отношений; qi – свойства элементов.

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

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


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


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



Отношения





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



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



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





1-АБСЭБ- 3


^ 1. Процесс проектирования информационных систем Rational Unified Process (RUP). Итеративность проектирования. Типовая итерация. Развитие моделей в результате итераций.

Rational Unified Process (RUP)- это процесс разработки программного обеспечения. Его цель состоит в том, чтобы гарантировать высокое качество программного продукта, отвечающего потребностям конечных пользователей, в пределах предсказуемого графика и бюджета выполнения. RUP обеспечивает строгий подход к решению задач проектирования и ответственности разработчиков. Процесс - это частично упорядоченный набор шагов, которые нужно проделать для достижения цели. При разработке программной системы цель состоит в формировании или расширении существующего программного изделия.



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



Схема организации RUP



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



Стадии завершаются главными вехами.

Первый цикл выполнения этих стадий - начальный цикл. Последующие циклы развития - эволюционные циклы.



Каждый эволюционный цикл проходит те же четыре стадии.

Итерации Каждая стадия может быть разбита на итерации.

^ 2. Программные продукты и возможности среды Rational.
Программные средства, реализующие нотацию Unified Modeling Language

Rational Unified Process – гипертекстовая база знаний;

Rational Rose – CASE средство объектного моделирования;

SoDA - инструмент автоматизации документооборота моделирования;

Requisite PRO – инструмент управления требованиями;

ClearQuest - средство управления запросами на изменение .

Общая платформа группы



^ Инструменты для аналитиков. Rational Rose (Modeler Edition)

Обеспечивает возможность визуального моделирования архитектуры и компонентов c использованием соответствующего промышленным стандартам Унифицированного языка моделирования (UML).
^ Инструменты для разработчиков. Rational Rose (Modeler Edition)

Обеспечивает возможность визуального моделирования рхитектуры и компонентов. Автоматически создает каркас кода для Java, C++, XML и др. языков. Автоматически поддерживает взаимодействие между Requisite Professional и SoDa.
^ Общая платформа группы. Rational SoDA

Автоматически генерирует документы, извлекая информацию из файлов, которые производятся при разработке проекта, включая исходный код и модели, произведенные инструментами Rational.Форматирует информацию согласно предопределенным шаблонам.




Итерация - цикл, приводящий к выпуску изделия (внутренней или внешней версии) или подмножества конечного продукта, возрастающего от итерации к итерации до законченной системы.

Структура процесса: Деловое моделирование, Требования, Анализ и проектирование, Выполнение, Испытание, Развертывание, Управление конфигурацией и изменением, Руководство проектом, Среда, Стадии RUP



Основные потоки работ



Поток работ делового моделирования






1-АБСЭБ- 4

^ 1. Основные характеристики объектно-ориентированного моделирования.
Объектно-ориентированная модель предметной области представляет собой совокупность диаграмм, описывающих с использованием универсального языка объектного проектирования языка UML различные аспекты структуры и поведения информационной системы.

Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграмма - это одна из проекций предметной области. Базисные конструкции унифицированного языка моделирования UML (сущности, отношения, диаграммы) приведены в руководстве разработчиков UML.

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

Снижение риска проектирования достигается за счет реализации ряда итераций разработки (так называемая спиральная модель жизненного цикла разработки). Каждая итерация может приводить к созданию фрагмента или новой версии модели и включает этапы выработки требований, анализа, проектирования, реализации и тестирования.

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

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

Класс - это множество предметов реального мира, связанных общностью структуры и поведением. Элемент класса - это конкретный элемент данного множества. Например, в сфере организационного управления существует класс организационно-распорядительных документов. Таким образом, объект - это типичный представитель класса, а термины "экземпляр объекта" и "элемент класса" равнозначны.

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

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

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

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

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

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


^ 2. Проектирование баз данных с использованием UML.
Обзор возможностей современных СУБД

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

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

Что касается объектно-ориентированных СУБД, то можно сказать, что теоретическая модель для них на сегодняшний день не разработана, а прикладные коммерческие продукты, провозглашенные как объектно-ориентированные, либо таковыми не являются, либо незрелы. Крупнейшие разработчики СУБД стали встраивать в свои продукты поддержку объектной ориентации, по соображениям совместимости предполагая смешанный подход – объектно-реляционный.

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

Несмотря на все недостатки реляционной модели данных, всё же она является наиболее современной на сегодняшний день. По этому нет смысла использовать ранние модели ввиду их неконкурентноспособности по сравнению с реляционными. Но и строить БД на основе чисто реляционной структуры было бы то же неуместно, ввиду её нереальности отображения семантики мира. Поэтому необходимо найти систему, которая основывалась на реляционном подходе и имела определённые разработки в объектно-ориентированных направлениях.

В ООБД информация хранится в форме объектов. Полностью объектно-ориентированная СУБД должна обеспечивать также объектно-ориентированный интерфейс взаимодействия с пользователем.

В основе ООБД лежит понятие объекта. Объектно-ориентированные БД характеризуются свойствами инкапсуляции, наследования и полиморфизма.

^ Диаграммы вариантов использования

Определение акторов. Определение транзакций, инициируемых акторами. Связь акторов с транзакциями - ассоциация

^ Диаграмма вариантов использования каталога

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

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

Модель сущность – связь. Сущность – это объект данных. Отношения. Множественность отношения «играет роль». Множественное наследование. Модель данных UML преобразуется в такую схему легко, хотя существуют проблемы, связанные с отсутствием стандартов OODBMS.

^ Поведение объектов

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

Модель объектно-реляционных данных является гибридом, который берет за основу реляционную модель данных и расширяет ее с помощью некоторых объектно-ориентированных концепций. На рисунке показана комбинация ОО и реляционной структуры. Класс Адрес конструируется из значений, на которые в реляционном отношении приходилось бы несколько колонок., и свертывает их в объект, который занимает всего одну. Основная цель – достижение концептуальной ясности и упрощение проекта. В примере не используется наследование, но проект компактнее, и возможно повторное использование кода.

Преимущества: можно использовать объектно-ориентированные средства (наследование, методы, объектные ссылки)для создания схемы. Которая хорошо вписывается в объектно-ориентированный концептуальный проект. Взаимодействие с реляционными средствами модели данных обеспечивает мост к реляционным операциям (например. использовать SQL).




1-АБСЭБ- 5


^ 1. Обзор основных понятий графической нотации и семантики языка Unified Modeling Language (UML) - унифицированного языка моделирования.
Объектно-ориентированный анализ наилучшим образом подходит для проектирования информационных систем, основанных на ситуационном подходе к управлению сложными объектами.

Важным преимуществом инструментальных средств, реализующих объектный подход (например, разработки фирмы Rational Rose), является возможность генерации на основе моделей программных кодов для разрабатываемой информационной управляющей системы предприятия. В настоящее время наиболее распространенным является применение набора моделей, входящих в UML (Unified Modeling Language - универсальный язык моделирования), так как этот язык стандартизирован, широко используется и постоянно развивается. При визуальном моделировании на UML используются восемь видов диаграмм, каждая из которых может содержать элементы определенного типа. Типы допустимых элементов и отношений между ними зависят от вида диаграммы. Диаграмма в UML – это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграмма – это в некотором смысле одна из проекций системы. UML – диаграммы (как различные подсети семантической сети) представляют разные аспекты предметной области, определяя в совокупности комплекс моделей предметной области.

Набор моделей, используемых в объектно-ориентированном подходе, включает: диаграммы прецедентов (Use Case Diagram); диаграммы взаимодействия (Interaction Diagram), к которым относятся диаграммы последовательности (Sequence diagram) и диаграммы взаимодействий (Collaboration diagram); диаграммы классов (Class Diagram) и объектов; диаграммы состояний (Statechart Diagram); диаграммы действий (Activity Diagram); диаграммы компонентов (Component Diagram); диаграммы размещения (Deployment Diagram).

Разработка объектных моделей системы искусственного интеллекта позволяет выявить существенные признаки проблемных ситуаций принятия решений, разработать логическую структуру базы данных описаний проблемных ситуаций, создать диаграммы прецедентов, пригодные для практической разработки в современных программных средах, то есть использовать преимущества визуального моделирования при разработке информационных систем. Базисные конструкции языка UML (сущности, отношения, диаграммы) приведены в [9] и использованы при построении моделей управления.

В UML имеется 4 типа сущностей: структурные, поведенческие, группирующие, аннотационные.

^ Структурные сущности – это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Аннотационные сущности – пояснительные части модели UML.

В языке UML определены 4 типа отношений: зависимость, ассоциация, обобщение, реализация.

Зависимость – это семантическое отношение между двумя сущностями, при котором изменение одной из них, независимой, может повлиять на семантику другой, зависимой. Ассоциация – структурное отношение, описывающее совокупность связей; связь – это соединение между объектами. Обобщение – отношение «специализация/обобщение», при котором объект специализированного элемента (потомок) может быть подставлен вместо объекта обобщенного элемента (родителя или предка). Реализация – это семантическое отношение между классификаторами.


^ 2. Примеры использования UML для построения визуальных моделей. Модель системы электронной торговли
[ смотри в приложении ]




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) является внешним по отношению к системе понятием, которое определенным образом участвует в процессе, описываемом прецедентом. Актер представляет собой некую идеализацию намерения пользователя, а не самого этого пользователя. Один реальный пользователь может соответствовать нескольким актерам, а один актер может представлять одно и то же намерение сразу нескольких пользователей.

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

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

Диаграммы 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-функциями).


frame2




1-АБСЭБ- 10

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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






1-АБСЭБ- 11


Диаграммы реализации моделируемой системы. Диаграммы компонент (Component diagram) и  диаграммы размещения компонент (Deployment diagram). Компоненты и модули моделируемой системы, их стереотипы. 

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

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

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

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



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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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


^ Отношения ассоциации, их атрибуты, роли, мощность и стереотипы. Примеры отношений.
Классы могут иметь взаимосвязи, называемые отношениями.

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



Мощность отношений (multiplicity) указывается для классов и определяет допустимое количество объектов, участвующих в отношении с каждой стороны. ( 0; 0..1; 0..n; 1;1..n; n )

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

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



Стереотипы

frame3

Квалификатор

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

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

Квалификатор изображается в виде маленького прямоугольника, присоединенного к началу ассоциации (рис.2.7). В нем указываются атрибуты другого класса-партнера ассоциации.






1-АБСЭБ- 12


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

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

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

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

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

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

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

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




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

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

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

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

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

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

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

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

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




1-АБСЭБ- 13


^ 1. Диаграммы переходов и состояний (Statechart diagram): простые и составные состояния, события, простые и сложные переходы.

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

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

Событие – это спецификация существенного факта, который происходит во времени и пространстве. В контексте автоматов событие - это стимул, способный вызвать срабатывание перехода

Простым называется такое состояние, которое не имеет внутренней структуры. Состояние, у которого есть подсостояния, то есть вложенные состояния, именуется составным. Оно может содержать как параллельные (независимые), так и последовательные (непересекающиеся) Подсостояния.

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

Сложные переходы - переходы вместе с ассоциированными событиями и действиями




^ 2. Примеры использования UML для построения визуальных моделей. Модель системы электронной торговли
[ смотри в приложении ]


1-АБСЭБ- 14

^ 1. Диаграммы классов и объектов. Стереотипы как средства расширения языка UML

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

Основные стереотипы класса – это сущность, граничный элемент, элемент управления, сервисный элемент и исключение. Соответственно, классы-интерфейсы имеют стереотип "boundary", классы-сущности - "entity", элемент управления – “control”, сервисный элемент - ”service”, исключение - ” exception”.



Класс- сущность (entity class) используется для моделирования данных и поведения с длинным жизненным циклом. Этот тип классов может представлять сущности реального мира или внутренние элементы системы.

Граничные классы (boundary class) обеспечивают взаимодействие между окружающей средой и внутренними элементами системы. Такие классы представляют интерфейс для пользователя или другой системы (то есть для актера).

Управляющие классы (control class) служат для моделирования последовательного поведения одного или нескольких прецедентов и координации событий, реализующих заложенное в них поведение.


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

На диаграммах последовательностей внимание акцентируется прежде всего на временной упорядоченности сообщений. Для создания такой диаграммы надо прежде всего расположить объекты, участвующие во взаимодействии, в верхней ее части вдоль оси X. Обычно инициирующий взаимодействие объект размещают слева, а остальные - правее (тем дальше, чем более подчиненным является объект). Затем вдоль оси Y размещаются сообщения, которые объекты посылают и принимают, причем более поздние оказываются ниже. Это дает читателю наглядную картину, позволяющую понять развитие потока управления во времени.



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

Во-первых, на них показана линия жизни объекта. Это вертикальная пунктирная линия, отражающая существование объекта во времени. Большая часть объектов, представленных на диаграмме взаимодействий, существует на протяжении всего взаимодействия, поэтому их изображают в верхней части диаграммы, а их линии жизни прорисованы сверху донизу. Объекты могут создаваться и во время взаимодействий. Линии жизни таких объектов начинаются с получения сообщения со стереотипом create. Объекты могут также уничтожаться во время взаимодействий; в таком случае их линии жизни заканчиваются получением сообщения со стереотипом destroy, а в качестве визуального образа используется большая буква X, обозначающая конец жизни объекта. Если объект на протяжении своей жизни изменяет значения атрибутов, состояние или роль, это можно показать, поместив копию его пиктограммы на линии жизни в точке изменения.

Вторая особенность этих диаграмм - фокус управления. Он изображается в виде вытянутого прямоугольника, показывающего промежуток времени, в течение которого объект выполняет какое-либо действие, непосредственно или с помощью подчиненной процедуры. Верхняя грань прямоугольника выравнивается по временной оси с моментом начала действия, нижняя - с моментом его завершения (и может быть помечена сообщением о возврате). Вложенность фокуса управления, вызванную рекурсией (то есть обращением к собственной операции) или обратным вызовом со стороны другого объекта, можно показать, расположив другой фокус управления чуть правее своего родителя (допускается вложенность произвольной глубины). Если место расположения фокуса управления требуется указать с максимальной точностью, можно заштриховать область прямоугольника, соответствующую времени, в течение которого метод действительно работает и не передает управление другому объекту. Сообщения (message) связывают объекты между собой и передают информацию о выполняемом действии. Каждое сообщение представляется на диаграмме сплошной линией со стрелкой на конце, проведенной от линии жизни одного объекта к линии жизни другого объекта. Возможна посылка сообщения объектом самому себе - самоделегирование. В этом случае линия может начинаться и заканчиваться около символа объекта. Линия помечается именем сообщения (операция или сигнал) и значениями его аргументов. Сообщения могут быть помечены условием перехода, которое располагается в квадратных скобках. Сообщения могут быть следующих типов. Асинхронные:сообщения рисуются линией с половинкой стрелки на конце. Асинхронное сообщение не блокирует работу вызывающего объекта..Асинхронные сообщения можно использовать для создания нового объекта или для установления связи с уже выполняемой ветвью процесса. Вызов процедуры:рисуется как заполненная стрелка. Возвращение из процедуры подразумевается неявно и на диаграмме не отображается. Возврат ставиться явно в том случае, если это необходимо для большей ясности и представляется меткой (короткая поперечная линия), расположенной около адресата возврата. Обычно стрелка с сообщением рисуется горизонтально. Это символизирует, что сообщение передается мгновенно и ничего не может произойти в момент передачи. Если на передачу сообщения необходимо какое-то время, в течение которого может что-нибудь произойти, то линия со стрелкой может быть ломаной.


1-АБСЭБ- 15


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

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

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

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

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

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

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

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





^ 2. Сравнительный анализ Case – средств моделирования информационных систем

Rational ROSE способен решить задачи, связанные с объектным моделированием и проектированием: от общей модели процессов (абстрактной) предприятия до конкретной (физической) модели класса в создаваемом программном обеспечении. Работа в Rational Rose заключается в проектировании определенного вида диаграмм. Разработчик может задавать при этом все свойства объектов, отношения и взаимодействие друг с другом

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

Возможности: кодогенерация, возможность обратного проектирования – реинжениринга, Round-trip engineering – сочетает возможности первых двух подходов, когда создается система, а по прохождении некоторого времени эволюционного периода (доработок) подвергается вновь реинженирингу и вновь кодогенерации.

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

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

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

ClearQuest является мощным средством управления запросами на изменение (change request management – CRM), специально разработанным с учетом динамической и сложной структуры процесса разработки ПО. ClearQuest отслеживает и управляет любым типом действий, приводящих к изменениям в течение всего жизненного цикла продукта, помогая, тем самым, организациям более предсказуемым (правильным) образом создавать качественное ПО.

Основные задачи, решаемые посредством ClearQuest:

Управлять изменениями, возникающими в ходе процесса разработки ПО.

Оптимизировать путь прохождения запросов на изменения, а также связанные с ним формы и процедуры.

Через World Wide Web поддерживать связь внутри команд, разделенных территориально.

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

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

Интегрироваться со средствами конфигурационного управления, такими как Rational’s ClearCase, позволяя создавать связи между запросами на изменение и развитие кода.

  1   2   3



Скачать файл (859.3 kb.)

Поиск по сайту:  

© gendocs.ru
При копировании укажите ссылку.
обратиться к администрации