УО «ПОЛОЦКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»
(ПГУ)
Кафедра технической кибернетики (ТК)
УТВЕРЖДАЮ
Зав. кафедрой ТК
СИСТЕМНОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ЭВМ
Методическое пособие
по выполнению курсовой работы
Для студентов специальности 400201 “Вычислительные машины, системы и сети”
Разработчик
Ассистент кафедры ТК
Новополоцк
2008
Содержание
Введение 3
1 Список разделов курсовой работы 4
2 Требования к содержанию пояснительной записки 5
3 Правила оформления пояснительной записки 10
4 Допуск к защите 11
5 Выбор варианта задания 11
6 Список рекомендуемой литературы 16
итульный лист 17
иаграммы UML 18
Введение
Курсовая работа по дисциплине «Системное программное обеспечение ЭВМ» выполняется студентами специальности 400201 “Вычислительные машины, системы и сети” 4 курса дневной формы обучения и 5 курса заочной формы обучения.
Целью курсовой работы является формирование умений и навыков самостоятельного проектирования программного обеспечения и освоение практических навыков разработки программного обеспечения с использованием API функций операционной системы Windows.
Задачами курсовой работы по данной дисциплине являются проектирование, разработка и реализация программного продукта, а также написание пояснительной записки и составление UML диаграмм, наиболее полно поясняющих работу реализованного программного продукта.
В данном методическом пособии изложены основы проектирования и реализации программных продуктов, порядок выполнения курсовой работы, требования, предъявляемые к выполнению отдельных частей курсовой работы, оформлению пояснительной записки и защите курсовой работы.
Методическое пособие разработано с целью оказания помощи студентам специальности 400201 ”Вычислительные машины, системы и сети” дневной и заочной форм обучения.
Задания на курсовую работу выдаются преподавателем. Примеры заданий приведены в пункте 5 данного пособия.
Курсовая работа, которая выполнена по заданию без подписи преподавателя или без задания, на проверку не принимается.
Курсовая работа должна состоять из программы, реализованной в соответствии с заданием на курсовую работу и пояснительной записки объемом 26-37 листов.
1 Список разделов курсовой работы
№ | Название раздела | Примерное кол. стр. |
Введение | 1-2 | |
1 | Анализ исходных данных | 5-8 |
1.1 | API функции сетевого взаимодействия (sockets API) |
|
1.2 | Запуск программы на выполнение в виде службы операционной системы Windows |
|
1.3 | Выбор и обоснование среды разработки |
|
2 | Проектирование приложения | 6-9 |
2.1 | Проектирование алгоритма работы программы |
|
2.2 | Проектирование интерфейса |
|
3 | Реализация и тестирование | 9-11 |
3.1 | Реализация программы |
|
3.2 | Тестирование работоспособности программы |
|
Заключение | 1-2 | |
Список использованных источников | 1-2 | |
Приложения | 3 диагр. | |
Всего страниц | 26-37 |
Для реализации практической части курсовой работы, а именно написания программы рекомендуется использование литературных источников [1-14], приведенных в пункте 6 данного пособия.
2 Требования к содержанию пояснительной записки
Введение
Выполнить общий анализ задачи курсовой работы с учетом текущего уровня развития средств вычислительной техники. Отразить основные цели и задачи, поставленные в курсовой работе и описать методы их реализации. Проанализировать роль API функций в работе системы в контексте выполняемой задачи. Рассмотреть службы операционной системы Windows и кратко охарактеризовать использование этого механизма выполнения программ, оценить его достоинства и недостатки с точки зрения целесообразности применения в контексте поставленной задачи. Рассмотреть основные принципы построения клиент-серверных приложений, аргументировать необходимость запуска сервера в виде службы операционной системы Windows с учетом требований технического задания на курсовую работу. Описать основные преимущества выполнения программ в виде служб операционной системы.
1 Анализ исходных данных
1.1 API функции сетевого взаимодействия (sockets API)
Рассмотреть API функции для организации сетевого взаимодействия через сокеты с учетом требований технического задания. Проанализировать исходные данные и на основе проведенного анализа определить, по какому протоколу будет происходить обмен данными (TCP/IP или UDP). Аргументировать использование API функций для реализации сетевого взаимодействия между клиентом и сервером. При анализе API функций для организации сетевого взаимодействия через сокеты необходимо не только привести список этих функций, но и определить последовательность вызовов этих функций, как для организации сервера и клиента (в случае использования протокола обмена TCP/IP), так и для организации сетевого взаимодействия посредством приема/передачи датаграмм (в случае использования протокола UDP).
1.2 Запуск программы на выполнение в виде службы операционной системы Windows
Рассмотреть механизм выполнения программ в виде служб операционной системы. Проанализировать полученные результаты и на основе проведенного анализа сделать выводы о целесообразности запуска серверной части разрабатываемого приложения в виде службы операционной системы. Рассмотреть все API функции для работы со службами операционной системы Windows. Учитывать требования технического задания на курсовую работу. После проведенного анализа API функций для работы со службами операционной системы необходимо определить последовательности вызовов определенных функций для внесения программы в список служб операционной системы, для запуска программы на выполнение после того, как она была внедрена в список служб, для остановки программы, выполняющейся в виде службы и для удаления остановленной программы из списка служб операционной системы Windows.
1.3 Выбор и обоснование среды разработки
В данном разделе необходимо рассмотреть и проанализировать возможности основных средств разработки программного обеспечения и на основе этого проведенного анализа выбрать ту среду разработки, на которой будет реализована программа. В качестве обязательных сред разработки для анализа должны использоваться Microsoft Visual и Borland C++ Builder 6. Допускается реализация программы и с помощью других средств разработки программного обеспечения при условии наличия достаточной аргументации в пользу использования этой среды разработки программного обеспечения. Если в техническом задании жестко задана среда реализации программного продукта, необходимо аргументировать причины (особенно если в результате проведенного сравнительного анализа преимущества данной среды явно не выделяются или являются сомнительными). При анализе возможностей средств разработки программного обеспечения в качестве критериев оценки могут применяться такие критерии как скорость выполнения разработанного программного обеспечения, кроссплатформенность разработанного программного обеспечения, поддержка работы с сетью при помощи API функций сокетов, возможность реализации объектно-ориентированных методов программирования, возможность запуска программ в виде службы операционной системы Windows, наличие развитой системы помощи, поддержка стандартных библиотек и компонентов, сложность разработки интерфейса в данной среде, условия распространения данной среды разработки программного обеспечения (платно или бесплатно) и т. п. После проведения сравнительного анализа средств разработки программного обеспечения на основании выделенных критериев все результаты для наглядности свести в таблицу. Например, анализировались такие среды разработки программного обеспечения как C++Builder 6.0 и Microsoft Visual C++ в составе пакета Microsoft Visual Studio 2005. Таблица результатов тестирования в таком случае может иметь следующий вид.
Критерий сравнения | Borland C++ Builder 6.0 | Microsoft Visual C++ |
Объектно-ориентированный | Да | Да |
Кроссплатформенный | Нет | Нет |
Работа с сетью | Отлично | Отлично |
Возможность запуска сервера в виде службы | Да | Да |
Скорость выполнения | Хорошо | Отлично |
Производительность | Высокая | Высокая |
Поддержка MFC | Неизвестно | Присутствует |
Поддержка VCL | Присутствует | Отсутствует |
Сложность разработки интерфейса | Низкая | Низкая |
Система помощи | Хорошая | Отличная |
Распространение | Платное | Бесплатное |
Таким образом, исходя из представленных характеристик, для разработки программного обеспечения в соответствии с заданием на курсовую работу выбрана среда Microsoft Visual C++ в составе пакета Microsoft Visual Studio 2005, как бесплатно распространяемая оболочка для разработки качественного программного продукта с отличной встроенной системой помощи.
2 Проектирование приложения
2.1 Проектирование алгоритма работы программы
В данном разделе разрабатывается и описывается алгоритм функционирования приложения, определяется основная функциональность разрабатываемого программного продукта, описываются основные правила функционирования программы и обработчики возможных ошибок. Также в этом разделе разрабатывается и описывается протокол обмена информацией между программой-сервером и программой-клиентом, описываются все возможные сообщения от клиента к серверу и от сервера к клиенту, указываются все данные, которые будут передаваться по сети, определяется порядок передачи информации. Приветствуется построение блок-схем функционирования для пояснения алгоритмов функционирования.
2.2 Проектирование интерфейса
В данном разделе разрабатывается и описывается интерфейс программы. Для этого разрабатываются все пункты меню, составляется список функций программы доступных непосредственно пользователю, разрабатывается внешний вид форм оконных приложений, реализующих пользовательскую функциональность. Обосновывается выбор в пользу тех либо иных стандартных интерфейсов, либо в пользу построения собственного интерфейса. Основными критериями при построении интерфейса разрабатываемого программного обеспечения должны быть удобство, простота использования, понятность и как можно более привлекательный внешний вид программы. При проектировании интерфейса необходимо учесть, что разработанный интерфейс должен скрывать от конечного пользователя все особенности реализации программы и не допускать некорректных действий конечного пользователя, которые могут привести к возникновению ошибок в программе.
3 Реализация и тестирование
3.1 Реализация программы
Данный раздел пояснительной записки целиком посвящается описанию методов и средств, с помощью которых реализована программа в соответствии с заданием на курсовую работу. В данном разделе описывается программная реализация клиент-серверной архитектуры с использованием сокетов на базе API функций. Приводится список всех функций и методов, отвечающих за сетевое взаимодействие. Описывается реализация спроектированного протокола обмена информацией по сети. Описываются все особенности реализации клиент-серверного приложения. Также в данном разделе описывается программная реализация запуска серверной части разработанного приложения в виде службы операционной системы Windows на базе API функций. Приводится список всех функций и методов, отвечающих за инициализацию, запуск, остановку и удаление службы. Описываются все особенности реализации работы программы в виде службы операционной системы. Также описывается реализация всех алгоритмов, обеспечивающих корректное функционирование разработанного программного обеспечения, не связанных с сетевым взаимодействием и запуском серверной части программы в виде службы операционной системы Windows. К таким алгоритмам можно отнести, например, алгоритмы сохранения/загрузки, контроля ошибок вводимых пользователем данных, аутентификации пользователей и т. п.
3.2 Тестирование работоспособности программы
Целью тестирования является проверка работоспособности разработанного программного обеспечения. На этой стадии необходимо проверить корректное функционирование разработанного программного обеспечения и соответствие его требованиям, выдвинутым в техническом задании. При выявлении несоответствий работы программы техническому заданию, либо ошибок, требуется доработка программного обеспечения и (или) документации. Разработанное программное обеспечение должно гарантировать устойчивое функционирование независимо от действий конечных пользователей. При возникновении отдельных ошибочных ситуаций разработанное программное обеспечение должно их успешно обрабатывать. Для проведения корректного тестирования сначала необходимо разработать порядок испытаний. Порядок испытаний – это список последовательности действий направленных на проверку корректности работы программы и (или) ее отдельных функциональных частей. Например, необходимо протестировать корректность работы аутентификации пользователей. Порядок испытаний в этом случае может иметь следующий вид:
- ввести корректное имя пользователя и пароль, убедиться в корректности аутентификации; ввести некорректные значения и убедиться в невозможности прохождения аутентификации; убедиться в невозможности возникновения ошибок при вводе в поля аутентификации произвольных символов.
Результаты тестирования работоспособности проведенного в соответствии с порядком испытаний свести в единую таблицу. Пример таблицы результатов тестирования приведен ниже.
Выполняемое действие | Результат выполнения действия | Комментарий |
Ввести корректное имя пользователя и пароль, убедиться в корректности аутентификации | Успешно | Аутентификация пройдена успешно |
Ввести некорректные значения и убедиться в невозможности прохождения аутентификации | Успешно | Аутентификация не пройдена, выдано сообщение о невозможности регистрации |
Убедиться в невозможности возникновения ошибок при вводе в поля аутентификации произвольных символов | Успешно | Ввод произвольных символов в поля аутентификации не влечет ошибок |
Заключение
В этом разделе должны быть сделаны выводы по полученным результатам курсовой работы. Сюда
Список использованных источников
Этот раздел представляет собой перечень всей литературы, которая была использована при разработке программного обеспечения и оформлении пояснительной записки курсовой работы. Список использованных источников формируется в том порядке, в котором даются ссылки на использованную литературу в тексте пояснительной записки, с указанием автора или редакторов, издательства, года издания и количества листов в книге.
Приложения
В качестве приложений должны быть оформлены три диаграммы UML, наиболее полно раскрывающие разработанную программу и при этом не дублирующие друг друга. Выбор типов диаграмм осуществляется разработчиком по согласованию с преподавателем. Основным критерием выбора типа UML диаграмм является наиболее полное раскрытие особенностей разработанного в рамках курсовой работы программного обеспечения. Подробная информация о диаграммах UML приведена в приложении Б.
Диаграммы должны быть оформлены в виде рисунков, как графический материал к курсовой работе. Оформление диаграмм может быть выполнено на форматах А2, А3, А4. Критерием для выбора формата является четкое и полное восприятие диаграммы.
В случаях, когда все особенности разработанного программного обеспечения не могут быть отражены всего лишь на трех диаграммах UML, необходимо построить дополнительные UML диаграммы, которые дополнят уже разработанные и позволят полностью охватить весь спектр особенностей реализованного программного продукта. В качестве приложений также может выноситься и другая вспомогательная информация на усмотрение разработчика.
3 Правила оформления пояснительной записки
Рекомендуется объем пояснительной записки курсовой работы 26-37 страницы текста формата А4. Пояснительная записка к курсовой работе должна быть выполнена на стандартной белой бумаге листах формата А4 с одной стороны листа с обязательным наличием рамок.
Пояснительная записка к курсовой работе должна быть выполнена с применением печатающих и графических устройств вывода ПЭВМ (ГОСТ 2.004) шрифтом Times New Roman черного цвета с высотой не более 14 пт. и не более чем полуторным интервалом и с высотой не менее чем 12 пт. через одинарный интервал. Допускается выполнение пояснительной записки к курсовой работе рукописным способом – четким почерком черными чернилами. Пример титульного листа содержится в приложении А.
Текстовая часть пояснительной записки к курсовой работе оформляется в соответствии с ГОСТ 2.105-95[12].
4 Допуск к защите
К защите допускаются студенты, выполнившие все необходимые этапы курсовой работы в установленные сроки и оформившие пояснительную записку в соответствии с требованиями стандарта ГОСТ 2.105-95[12]. Порядок защиты работ определяется графиком защит. График составляется преподавателем и вывешивается на доске объявлений кафедры заранее.
5 Выбор варианта задания
Задания выдаются преподавателем каждому студенту индивидуально. Успевающий студент (хорошист или отличник) имеет право выбрать задание по своему желанию из перечня заданий, предложенных ему преподавателем. Также может быть предложена своя тема, которую необходимо согласовать с преподавателем. Примерный перечень тем заданий на курсовую работу приведен ниже:
Тема работы: Разработка сетевой игры “Морской бой”.
Исходные данные:
- Операционная система Windows; Запуск сервера в виде службы операционной системы Windows; Среда разработки на выбор; Реализовать сохранение/загрузку игры; Реализовать аутентификацию пользователей.
Комментарий: в данной теме можно выбрать и другую игру, в которую одновременно может играть несколько человек. Например, шашки, шахматы, домино, покер и т. д. Написать программу для игры по сети с учетом следующих требований задания. Сервер должен выполнять все действия, связанные с изменением состояния игры, вести список активных игроков, рассылать клиентам уведомления о происходящих событиях. На стороне клиента должны быть реализованы графический интерфейс, возможность просмотра статистики игры, возможность сохранения или загрузки игры при условии согласия всех играющих и возможность просмотра справочной информации в которой описаны правила игры.
Тема работы: Разработка интерактивного мультимедийного чата для передачи звуковых сообщений по сети
Исходные данные:
- Операционная система Windows; Запуск сервера в виде службы операционной системы Windows; Среда разработки на выбор; Для передачи звуковых пакетов использовать протокол UDP (User Datagram Protocol); Отображать список пользователей; Вести лог подключений; Реализовать аутентификацию; Реализовать широковещательные сообщения для администратора.
Комментарий: реализовать чат, в котором возможен обмен не только текстовыми, но и голосовыми сообщениями. Для этого реализовать запись звука с микрофона и его трансляцию выбранному пользователю на указанный IP-адрес. Предусмотреть возможность как личного общения в чате, так и широковещательной рассылки. Широковещательная рассылка должна быть доступна исключительно администратору.
Тема работы: Разработка клиент-серверного приложения для удаленного администрирования
Исходные данные:
- Операционная система Windows; Запуск сервера в виде службы операционной системы Windows; Среда разработки на выбор; Реализовать аутентификацию; Реализовать просмотр удаленного рабочего стола; Просмотр списка процессов удаленной машины с возможностью завершения этих процессов; Реализовать ведение логов о запущенных и завершенных процессах на удаленных машинах; Предусмотреть возможность выбора директории для сохранения логов; Реализовать перехват управления клавиатурой и мышью удаленной машины.
Комментарий: клиент после подключения к компьютеру, на котором запущен сервис, должен иметь возможность просматривать все происходящее на рабочем столе удаленной машины и позволять перехватывать управление удаленной машиной. Ведение логов подразумевает получение списка уже запущенных процессов на момент подключения и сохранение этого списка в текстовый файл вместе со временем подключения, а также запись в этот файл новых запущенных процессов вместе со временем их запуска и завершенных процессов вместе со временем их завершения.
Тема работы: Разработка клиент-серверного приложения для хранения файлов на удаленном компьютере
Исходные данные:
- Операционная система Windows; Запуск сервера в виде службы операционной системы Windows; Среда разработки на выбор; Хранение файлов осуществляется на сервере в директориях, соответствующих имени пользователя; Реализовать аутентификацию пользователей; Предусмотреть возможность регистрации нового пользователя; Реализовать два типа файлов, хранящихся на сервере: файлы доступные только для того пользователя, который поместил их на сервер и файлы с модификатором общего доступа, которые доступны всем пользователям; Реализовать возможность перемещения файлов на сервер для хранения и скачивания файлов с сервера (как своих собственных, так и общего доступа).
Комментарий: хранение файлов осуществляется на сервере в директориях, соответствующих имени пользователя. Должно быть два вида пользователей – простой пользователь и администратор. Простой пользователь может работать только со своими файлами и файлами, открытыми для общего доступа. Администратор может работать со всеми файлами и редактировать список пользователей. Пользователя с правами администратора может создать только администратор.
Тема работы: Разработка форума в рамках ЛВС
Исходные данные:
- Операционная система Windows; Запуск сервера в виде службы операционной системы Windows; Среда разработки на выбор; На сервере хранится список пользователей форума, список тем и сообщения по каждой теме; Реализовать аутентификацию пользователей; Предусмотреть возможность регистрации нового пользователя; Список пользователей форума доступен только администратору.
Комментарий: должно быть два вида пользователей – простой пользователь и администратор. Простой пользователь может просматривать сообщения в различных темах и добавлять свои собственные сообщения. Редактировать или удалять пользователь может только свои сообщения. Администратор может редактировать или удалять любые сообщения и может редактировать список пользователей. Пользователя с правами администратора может создать только администратор.
Тема работы: Разработка собственной почтовой службы в рамках ЛВС
Исходные данные:
- Операционная система Windows; Запуск сервера в виде службы операционной системы Windows; Среда разработки на выбор; На сервере хранится список почтовых ящиков локальной сети и все письма находящиеся в них; Предусмотреть ограничение максимального размера почтового ящика для пользователей; Реализовать аутентификацию пользователей; Предусмотреть возможность регистрации нового пользователя; Администратор может менять квоту на максимальный размер почтового ящика.
Комментарий: должно быть два вида пользователей – простой пользователь и администратор. Простой пользователь может заходить в свой почтовый ящик, просматривать полученные письма, писать и отправлять письма в пределах локальной сети, редактировать старые письма, удалять ненужные сообщения из почтового ящика. Администратор кроме работы со своим ящиком может просматривать и редактировать список почтовых ящиков пользователей. Пользователя с правами администратора может создать только администратор.
Тема работы: Разработка клиент-серверного приложения для трансляции видео по сети
Исходные данные:
- Операционная система Windows; Запуск сервера в виде службы операционной системы Windows; Среда разработки на выбор; Реализовать аутентификацию пользователей; Выбор видео для трансляции доступен только администратору; Предусмотреть возможность регистрации нового пользователя; Для передачи видео по сети использовать протокол UDP(User Datagram Protocol); При работе с видео использовать стандартные кодеки.
Комментарий: Клиент подключается к серверу либо как простой пользователь, которому доступна исключительно функция просмотра трансляции, либо как администратор. Для администратора необходимо реализовать возможность запуска трансляции, остановки трансляции и возможность выбора видео файла для трансляции. Пользователя с правами администратора может создать только администратор.
Задания, выдаваемые преподавателем, могут отличаться от заданий, указанных в методичке.
6 Список рекомендуемой литературы
Шефферд Дж. – Программирование на Microsoft Visual C++ 6.0 для профессионалов / Пер. с англ. – СПб: Питер; М.: Издательско-торговый дом «Русская Редакция», 2004 – 861с. Шефферд Дж. – Программирование на Microsoft Visual C++.Net для профессионалов / Пер. с англ. – М.: Издательско-торговый дом «Русская Редакция», 2003 – 928с. Рихтер Дж. – Windows для профессионалов: создание эффективных Win32 приложений с учетом специфики 64-разрядной версии Windows/ Пер. с англ. – 4-е изд. – СПб: Питер; М.: Издательско-торговый дом «Русская Редакция», 2001 – 752с. Win32 Основы программирования. – 2-е изд., испр. и дополн. – М.:ДИАЛОГ-МИФИ, 2006. – 416с. Рахул Верма Справочник по функциям Win32 API – 2-е изд. М: Горячая Линия - Телеком, 2002 г. - 552с. Юрий Щупак Win32 API. Эффективная разработка приложений – Спб: Питер, 2007 г. - 572с. . Программирование в C++ Builder 6 – Издательство Бином, 2003, 1152с. . Приемы программирования в C++ Builder 6 и 2006 - Издательство Бином, 2006, 992с. . Программирование в С++ Builder 6 и 2006 - Издательство Бином, 2007, 1184с. Borland C++ Builder 6 для профессионалов. - Издательство Питер, 2003, 800с. Джаррод Холингворт, Боб Сворт, Марк Кэшмэн, Поль Густавсон. Borland C++ Builder 6.Руководство разработчика. - Издательство Вильямс, 2004, 976с. , Приемы программирования в C++Builder. Механизмы Windows, сети. - Издательство Бином-Пресс, 2004, 656с. Фень Юань Программирование графики для Windows – С. П.: Питер, 2002 г. Platform SDK for Windows XP SP2 documentation. ГОСТ 2.105-95 ЕСКД. Общие требования к текстовым документам. – М.: Издательство стандартов, 1995.
итульный лист
Министерство образования Республики Беларусь
Учреждение образования
«Полоцкий государственный университет»
Кафедра ТК
КУРСОВАЯ РАБОТА
По курсу: «Системное программное обеспечение ЭВМ».
На тему: «Тема курсовой работы в соответствии с заданием ».
Группа №-ВС
Выполнил Ф. И.О.
Проверил Ф. И.О.
Новополоцк
2008
иаграммы UML
Диаграмма в UML - это графическое представление набора элементов, изображаемое чаще всего в виде связанного графа с вершинами (сущностями) и ребрами (отношениями). Диаграммы рисуют для визуализации системы с разных точек зрения. Диаграмма - в некотором смысле одна из проекций системы. Как правило, за исключением наиболее тривиальных случаев, диаграммы дают свернутое представление элементов, из которых составлена система. Теоретически диаграммы могут содержать любые комбинации сущностей и отношений. На практике, однако, применяется сравнительно небольшое количество типовых комбинаций. Таким образом, в UML выделяют девять типов диаграмм: диаграммы классов; диаграммы объектов; диаграммы прецедентов; диаграммы последовательностей; диаграммы кооперации; диаграммы состояний; диаграммы действий; диаграммы компонентов; диаграммы развертывания.
На диаграмме классов показывают классы, интерфейсы, объекты и кооперации, а также их отношения. При моделировании объектно-ориентированных систем этот тип диаграмм используют чаще всего. Диаграммы классов соответствуют статическому виду системы с точки зрения проектирования. Диаграммы классов, которые включают активные классы, соответствуют статическому виду системы с точки зрения процессов.
Примеры диаграмм классов приведены ниже.
На диаграмме объектов представлены объекты и отношения между ними. Они являются статическими «фотографиями» экземпляров сущностей, показанных на диаграммах классов. Диаграммы объектов, как и диаграммы классов, относятся к статическому виду системы с точки зрения проектирования или процессов, но с расчетом на настоящую или макетную реализацию.
На диаграмме прецедентов представлены прецеденты и актеры (частный случай классов), а также отношения между ними. Диаграммы прецедентов относятся к статическому виду системы с точки зрения прецедентов использования. Они особенно важны при организации и моделировании поведения системы.
Примеры диаграмм прецедентов приведены ниже.
Работа Интернет - магазина по продаже автомобилей.
Диаграммы последовательностей и кооперации являются частными случаями диаграмм взаимодействия. На диаграммах взаимодействия представлены связи между объектами; показаны, в частности, сообщения, которыми объекты могут обмениваться. Диаграммы взаимодействия относятся к динамическому виду системы. При этом диаграммы последовательности отражают временную упорядоченность сообщений, а диаграммы кооперации - структурную организацию обменивающихся сообщениями объектов. Эти диаграммы являются изоморфными, то есть могут быть преобразованы друг в друга.
Примеры этих диаграмм приведены ниже.
Поток управления на диаграмме последовательностей
Поток управления на диаграмме коопераций
На диаграммах состояний (Statechart diagrams) представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они акцентируют внимание на поведении объекта, зависящем от последовательности событий, что очень полезно для моделирования реактивных систем.
Пример диаграммы состояний для системы удаленного хранения файлов представлен ниже.
Диаграмма деятельности - это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами.
Примеры диаграмм деятельности представлены ниже.
Моделирование операции с помощью диаграммы деятельности
Диаграмма деятельности системы удаленного хранения файлов.
На диаграмме компонентов представлена организация совокупности компонентов и существующие между ними зависимости. Диаграммы компонентов относятся к статическому виду системы с точки зрения реализации. Они могут быть соотнесены с диаграммами классов, так как компонент обычно отображается на один или несколько классов, интерфейсов или коопераций.
Примеры диаграмм компонентов представлены ниже.
Компоненты
На диаграмме развертывания представлена конфигурация обрабатывающих узлов системы и размещенных в них компонентов. Диаграммы развертывания относятся к статическому виду архитектуры системы с точки зрения развертывания. Они связаны с диаграммами компонентов, поскольку в узле обычно размещаются один или несколько компонентов.
Примеры диаграмм развертывания приведены ниже.
Диаграммы развертывания
Здесь приведен неполный список диаграмм, применяемых в UML. Инструментальные средства позволяют генерировать и другие диаграммы, но девять перечисленных встречаются на практике чаще всего.
