Реферат: Методические указания



МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ

Черниговский государственный технологический университет


применение uml для моделирования и проектирования информационных систем


МЕТОДИЧЕСКИЕ УКАЗАНИЯ

к лабораторному практикуму

по дисциплине

“Объектно-ориентированный анализ и проектирование”

для студентов направления подготовки

6.050102 - “Компьютерная инженерия”



Утверждено

на заседании кафедры

информационных и компьютерных систем




Протокол № 9 от 28.05.2010



Чернигов ЧГТУ 2010

Методичні вказівки до лабораторного практикуму з дисципліни „ Об’єктно-орієнтований аналіз та проектування” для студентів напряму підготовки 6.050102 -“Комп’ютерна інженерія”./ Укл. А. М. Акименко, В.І. Павловський, І. В. Кириєнко — Чернігів: ЧДТУ, 2010. — 40с. Рос. мовою.





Составители: Акименко Андрей Николаевич, кандидат физико-математических наук, доцент

Павловский Владимир Ильич, кандидат технических наук, доцент

Кириенко Ирина Валентиновна, ассистент

Ответственный за выпуск: Павловский Владимир Ильич, заведующий кафедрой информационных и компьютерных систем, кандидат технических наук, доцент

Рецензент: Нестеренко Сергей Александрович, кандидат технических наук, доцент кафедры информационных и компьютерных систем Черниговского государственного технологического университета



СОДЕРЖАНИЕ

ПРЕДИСЛОВИЕ 6

1 ОБЩИЕ УКАЗАНИЯ К ЛАБОРАТОРНЫМ РАБОТАМ 7

1.1 Цель лабораторного практикума 7

1.2 Порядок выполнения лабораторных работ 7

1.3 Содержание отчета о выполнении лабораторных работ 7

2 ЛАБОРАТОРНАЯ РАБОТА №1. ОПИСАНИЕ И АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 8

2.1 Цель работы 8

2.2 Теоретические сведения 8

2.2.1 Анализ предметной области 8

2.2.2 Диаграммы «сущность-связь» 9

2.2.3 Диаграммы потоков данных 9

2.3 Содержание отчета 11

2.4 Контрольные вопросы 11

1. Цели проведения объектного анализа. 11

3 ЛАБОРАТОРНАЯ РАБОТА №2. ОФОРМЛЕНИЕ РЕЗУЛЬТАТОВ АНАЛИЗА ПРИ ПОМОЩИ ДИАГРАММ UML 12

3.1 Цель работы 12

3.2 Теоретические сведения 12

3.2.1 Построение диаграммы вариантов использования 12

3.2.2 Построение диаграммы анализа 15

3.3 Содержание отчета 17

3.4 Контрольные вопросы 18

4 ЛАБОРАТОРНАЯ РАБОТА №3. ДИАГРАММА КЛАССОВ 19

4.1 Цель работы 19

4.2 Теоретические сведения 19

4.2.1 Диаграмма классов 19

4.2.2 Рекомендации по построению диаграммы классов 21

4.3 Содержание отчета 21

4.4 Контрольные вопросы 22

5 ЛАБОРАТОРНАЯ РАБОТА №4. ДИАГРАММЫ ВЗАИМОДЕЙСТВИЯ 23

5.1 Цель работы 23

5.2 Теоретические сведения 23

5.2.1 Диаграмма последовательности 23

Фокус управления 24

Сообщения 24

5.2.2 Диаграмма кооперации 25

5.3 Содержание отчета 26

5.4 Контрольные вопросы 26

6 ЛАБОРАТОРНАЯ РАБОТА №5. ДИАГРАММЫ ПОВЕДЕНИЯ 27

6.1 Цель работы 27

6.2 Теоретические сведения 27

6.2.1 Диаграмма состояний 27

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

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

6.2.3 Рекомендации по построению диаграмм поведения 28

6.3 Содержание отчета 29

6.4 Контрольные вопросы 29

7 ЛАБОРАТОРНАЯ РАБОТА №6. ДИАГРАММА КОМПОНЕНТОВ 31

7.1 Цель работы 31

7.2 Теоретические сведения 31

7.2.1 Представление компонентов 31

Компоненты 32

Зависимости 32

7.2.2 Рекомендации по построению диаграммы компонентов 32

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

7.3 Содержание отчета 33

7.4 Контрольные вопросы 33

8 ЛАБОРАТОРНАЯ РАБОТА №7. ДИАГРАММА РАЗВЕРТЫВАНИЯ 34

8.1 Цель работы 34

8.2 Теоретические сведения 34

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

Узел 35

Соединения 35

8.2.2 Рекомендации по построению диаграммы развертывания 35

8.3 Содержание отчета 36

8.4 Контрольные вопросы 36

9 СПИСОК ИНДИВИДУАЛЬНЫХ ВАРИАНТОВ ЗАДАНИЙ СТУДЕНТОВ 38



ПРЕДИСЛОВИЕ

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

требуемую функциональность системы и степень адаптации к изменяющимся условиям ее функционирования;

требуемую пропускную способность системы;

требуемое время реакции системы на запрос;

безотказную работу системы;

простоту эксплуатации и поддержки системы;

необходимую безопасность.

Проектирование информационных систем охватывает три основные области:

проектирование объектов данных, которые будут реализованы в базе данных;

проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;

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

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

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





^ 1ОБЩИЕ УКАЗАНИЯ К ЛАБОРАТОРНЫМ РАБОТАМ 1.1Цель лабораторного практикума
Лабораторный практикум выполняется при изучении курса "Объектный анализ и проектирование" и имеет целью выработку у студентов навыков в трех направлениях:

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

применение языка UML для моделирования и проектирования информационных систем;

применение соответствующего программного инструментария.

В "Общие указания" вынесены общие для выполнения всех лабораторных работ требования и правила.
^ 1.2Порядок выполнения лабораторных работ
Варианты индивидуального задания определяются преподавателем в соответствии со списком индивидуальных заданий, расположенном в разделе 9 данных Методических указаний.

Для выполнения всех лабораторных работ предлагается единый порядок, предусматривающий следующие шаги:

Ознакомиться с постановкой задачи и исходными данными.

Разработать предлагаемую в работе диаграмму.

Реализовать разработанную диаграмму.

Сохранить файл модели.

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

Тема лабораторной работы.

Цель работы.

Индивидуальное задание.

Описание необходимых абстракций (элементов диаграмм)

Разработанная диаграмма



^ 2ЛАБОРАТОРНАЯ РАБОТА №1. ОПИСАНИЕ И АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 2.1 Цель работы
Согласно варианту, выполнить описание предметной области проектируемой программной системы. Провести объектный анализ полученного описания и построить модель среды с помощью диаграммы потоков данных (анализ поведения системы) и диаграммы «сущность-связь» (анализ данных). Определить назначение проектируемой ИКС.
^ 2.2Теоретические сведения 2.2.1Анализ предметной области
Этап анализа предполагает подробное исследование бизнес-процессов (функций, определенных на этапе выбора стратегии) и информации, необходимой для их выполнения (сущностей, их атрибутов и связей (отношений)). На этом этапе создается информационная модель системы.

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

Аналитики собирают и фиксируют информацию в двух взаимосвязанных формах:

функции — информация о событиях и процессах, которые происходят в бизнесе;

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

Двумя классическими результатами анализа являются:

иерархия функций, которая разбивает процесс обработки на составные части (что делается и из чего это состоит);

модель «сущность-связь» (Entry Relationship model, ER-модель), которая описывает сущности, их атрибуты и связи (отношения) между ними.

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

Ниже мы рассмотрены наиболее часто применяемые методологии структурного анализа:

диаграммы «сущность-связь» (Entity-Relationship Diagrams, ERD), которые служат для формализации информации о сущностях и их отношениях;

диаграммы потоков данных (Data Flow Diagrams, DFD), которые служат для формализации представления функций системы.
^ 2.2.2Диаграммы «сущность-связь»
Диаграммы “сущность-связь” (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).

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




Рисунок 2.1 - Графические изображения для обозначения сущностей

Связь (relationship) определяется как отношение или некоторая ассоциация между отдельными сущностями. Примерами связей могут являться родственные отношения типа "отец-сын" или производственные отношения типа "начальник-подчиненный". Другой тип связей задается отношениями "иметь в собственности" или "обладать свойством". Различные типы связей графически изображаются в форме ромба с соответствующим именем данной связи (рисунок 2.2).




Рисунок 2.2 - Графические изображения для обозначения связей

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

Основными компонентами диаграмм потоков данных являются:

внешние сущности, 

накопители данных или хранилища, 

процессы, 

потоки данных, 

системы/подсистемы.

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




Рисунок 2.3 - Изображение внешней сущности на диаграмме потоков данных

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



Рисунок 2.4 - Изображение процесса на диаграмме потоков данных

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



Рисунок 2.5 - Изображение накопителя на диаграмме потоков данных

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

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

Описание предметной области.

Разработанные диаграммы потоков данных и «сущность-связь».

Назначение программной системы и описание её основных функций.

Выводы.
^ 2.4Контрольные вопросы Цели проведения объектного анализа.
Назначение диаграммы «сущность-связь».

Основные элементы диаграммы «сущность-связь».

Назначение диаграммы потоков данных.

Основные элементы диаграммы потоков данных.



^ 3ЛАБОРАТОРНАЯ РАБОТА №2. ОФОРМЛЕНИЕ РЕЗУЛЬТАТОВ АНАЛИЗА ПРИ ПОМОЩИ ДИАГРАММ UML 3.1Цель работы
Изучить правила оформления диаграммы вариантов использования и диаграммы анализа. Научится выделять особенности функционального поведения проектируемой системы.
^ 3.2Теоретические сведения 3.2.1Построение диаграммы вариантов использования
Визуальное моделирование в UML можно представить как некоторый процесс поуровневого спуска от наиболее общей и абстрактной модели исходной системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме диаграммы вариантов использования (use case diagram), которая описывает функциональное назначение системы или, другими словами, то, что система будет делать в процессе своего функционирования.

Разработка диаграммы вариантов использования преследует цели:

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

сформулировать общие требования к функциональному поведению проектируемой системы;

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

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

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

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

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

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

В языке UML имеется несколько стандартных видов отношений между актерами и вариантами использования:

отношение ассоциации (association relationship),

отношение расширения (extend relationship),

отношение обобщения (generalization relationship),

отношение включения (include relationship),

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

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

Для диаграмм вариантов использования наиболее распространенными являются четыре основные формы записи кратности отношения ассоциации:

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

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

два символа, разделенные двумя точками. При этом первый из них является целым неотрицательным числом или 0, а второй - специальным символом «*», который обозначает произвольное конечное целое неотрицательное число, значение которого неизвестно на момент задания соответствующего отношения ассоциации;

единственный символ «*», который является сокращением записи интервала «0..*».

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

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

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

Семантика отношения расширения определяется следующим образом. Если экземпляр варианта использования выполняет некоторую последовательность действий, которая определяет его поведение, и при этом имеется точка расширения на экземпляр другого варианта использования, которая является первой из всех точек расширения у исходного варианта, то проверяется условие данного отношения. Если условие выполняется, исходная последовательность действий расширяется посредством включения действий экземпляра другого варианта использования.
^ Отношение обобщения
Отношение обобщения служит для указания того факта, что некоторый вариант использования А может быть обобщен до варианта использования В. В этом случае вариант А будет являться специализацией варианта В. При этом В называется предком или родителем по отношению А, а вариант А — потомком по отношению к варианту использования В. Следует подчеркнуть, что потомок наследует все свойства и поведение своего родителя, а также может быть дополнен новыми свойствами и особенностями поведения. Графически данное отношение обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования.

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

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

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

Основными компонентами диаграммы анализа являются:

бизнес-процесс, 

ресурс и информация, 

событие, 

выход, 

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



Рисунок 3.1 - Изображение бизнес-процесса на диаграмме анализа
^ Ресурс и информация
В процессе своей реализации бизнес-процесс использует ресурсы. В качестве ресурсов может выступать информация от внешних или внутренних источников, от других актеров или же от других бизнес-процессов.

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

Обозначение ресурса и информации представлено на рисунке 3.2.



Рисунок 3.2 - Изображение ресурса и информации на диаграмме анализа
Событие
Событием является какой-либо объект, момент времени, дата, уведомление или какой-либо другой триггер, после срабатывания которого начинается выполнение бизнес-процесса. Обозначение события представлено на рисунке 3.3.



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

Обозначение выхода представлено на рисунке 3.4.



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

Обозначение цели представлено на рисунке 3.5.



Рисунок 3.5 - Изображение цели на диаграмме анализа
3.3Содержание отчета
1. Наименование и цель работы, номер варианта.

2. Разработанные диаграммы вариантов использования.

3. Спецификация поведения элементов Use Case диаграммы вариантов использования.

4. Спецификация других элементов диаграммы.

5. Разработанные диаграммы анализа.

6. Выводы.
3.4Контрольные вопросы
1. Назначение диаграммы вариантов использования.

2. Цели разработки диаграммы вариантов использования.

3. Элементы диаграммы вариантов использования. Актеры.

4. Элементы диаграммы вариантов использования. Отношения.

5. Элементы диаграммы вариантов использования. Use Case.

6. Цели разработки анализа.

7. Элементы диаграммы анализа. Бизнес-процессы.

8. Элементы диаграммы анализа. Ресурсы и информация.

9. Элементы диаграммы анализа. События.

10. Элементы диаграммы анализа. Выходы.

11. Элементы диаграммы анализа. Цели.

^ 4ЛАБОРАТОРНАЯ РАБОТА №3. ДИАГРАММА КЛАССОВ 4.1Цель работы
Изучить правила оформления диаграммы классов. Научится разрабатывать статическую структуру модели системы в терминологии классов объектно-ориентированного программирования.
4.2Теоретические сведения 4.2.1Диаграмма классов
Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношений.

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

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

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

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

отношение зависимости (dependency relationship)

отношение ассоциации (association relationship)

отношение обобщения (generalization relationship)

отношение реализации (realization relationship)

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

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

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

отношение агрегации (aggregation relationship)

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

Данное отношение имеет фундаментальное значение для описания структуры сложных систем, поскольку применяется для представления системных взаимосвязей типа "часть-целое". Раскрывая внутреннюю структуру системы, отношение агрегации показывает, из каких компонентов состоит система и как они связаны между собой.
Отношение композиции
Отношение композиции служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого.
4.2.2Рекомендации по построению диаграммы классов
Процесс разработки диаграммы классов занимает центральное место в ООАП сложных систем. От умения правильно выбрать классы и установить между ними взаимосвязи часто зависит не только успех процесса проектирования, но и производительность выполнения программы.

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