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

МЕТОДОЛОГИИ И ТЕХНОЛОГИИ
ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ
СИСТЕМ
Методические указания к выполнению курсового проекта
Для студентов направления 230700 –
«Прикладная информатика»
Составители: К. Г. Козлов, И. А. Джиоева
Владикавказ 2013
Министерство образования и науки РФ
Северо-Кавказский горно-металлургический институт
(государственный технологический университет)
Кафедра «Информационные системы в экономике»
МЕТОДОЛОГИИ И ТЕХНОЛОГИИ
ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ
СИСТЕМ
Методические указания к выполнению курсового проекта
Для студентов направления 230700 –
«Прикладная информатика»
Составители: К. Г. Козлов, И. А. Джиоева
Допущено редакционно-издательским советом
Северо-Кавказского горно-металлургического
института (государственного технологического
университета).
Протокол № 24 от 2.07.2013
Владикавказ 2013
1
УДК 004.422(07)
ББК 32.97
К 28
Рецензент:
доктор технических наук, профессор СКГМИ (ГТУ) Кумаритов А. М.
К 28
Методологии и технологии проектирования информационных
систем: Методические указания / Сост. К. Г. Козлов, И. А. Джиоева;
Северо-Кавказский горно-металлургический институт (государственный технологический университет). – Владикавказ: СевероКавказский горно-металлургический институт (государственный
технологический университет). Изд-во «Терек», 2013. – 40 с.
В первом разделе представлены требования к выбору темы, разработке, подготовке к защите курсового проекта, приведены критерии и составляющие оценки курсового проекта. Кроме того, описаны требования к оформлению и содержанию отчета по курсовому
проекту. Во втором разделе даны примеры выполнения всех разделов курсового проекта с описанием и комментариями.
Предназначены для использования в учебном процессе на кафедре «Информационные системы в экономике» при выполнении
курсового проекта по курсу «Методологии и технологии проектирования информационных систем» для магистров по направлению
подготовки 230700 – «Прикладная информатика».
УДК 004.422(07)
ББК 32.97
Редактор: Иванченко Н. К.
Компьютерная верстка: Куликова М. П.
 Составление. Северо-Кавказский
горно-металлургический институт
(государственный технологический университет), 2013
 Джиоева И. А., Козлов К. Г., составление, 2013
Подписано в печать 30.07.2013. Формат 60х84 1/16. Бумага офсетная. Гарнитура
«Таймс». Печать на ризографе. Усл. п.л. 2,3. Тираж 15 экз. Заказ №
.
Северо-Кавказский горно-металлургический институт (государственный технологический
университет). Издательство «Терек».
Отпечатано в отделе оперативной полиграфии СКГМИ (ГТУ).
362021, г. Владикавказ, ул. Николаева, 44.
2
Оглавление
Раздел 1. Требования к оформлению и содержанию курсового
проекта ........................................................................................................4
Общие положения .....................................................................................–
Основные этапы работы и требования к структуре курсового
проекта ........................................................................................................–
Требования к содержанию курсового проекта .......................................6
Требования к оформлению текста работы ..............................................8
Подготовка курсового проекта к защите .................................................–
Защита и оценка курсового проекта ........................................................9
Раздел 2. Пример выполнения курсового
проекта с использованием RationalRoseEnterpriseEdition .....................10
Пример построения диаграммы вариантов использования ...................11
Пример построения диаграммы видов деятельности.............................16
Пример построения диаграммы классов .................................................17
Пример построения диаграмм взаимодействий .....................................23
Пример построения диаграмм состояний ...............................................28
Пример построения полной диаграммы классов ....................................31
Пример построения диаграммы развертывания .....................................32
Пример построения диаграмм навигации ...............................................33
Рекомендуемые темы курсовых проектов...............................................38
Литература .................................................................................................40
3
Раздел 1. ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ И СОДЕРЖАНИЮ
КУРСОВОГО ПРОЕКТА
Общие положения
Разработка курсового проекта является завершающим этапом
изучения дисциплины «Проектирование информационных систем».
Выполнение курсового проекта способствует систематизации и обобщению знаний, полученных в процессе изучения дисциплины, а также
выработке умения ориентироваться в современных ИС при выборе
нужного средства для решения конкретной задачи автоматизации.
Защита курсового проекта должна выявить степень подготовленности студента, умение анализировать предметную область, строить
модели, определять требования к разрабатываемой базе данных, обоснованно выбирать и применять конкретное средство для решения поставленных задач.
Цель курсового проекта – приобретение студентом практических
навыков по формулированию требований к разрабатываемым информационным системам и построению их моделей, а также формирование навыков самостоятельного практического применения современных методов и средств проектирования программного обеспечения,
основанных на использовании визуального проектирования и CASEсредств.
Основные этапы работы и требования к структуре
курсового проекта
Выбор темы курсового проекта
Курсовой проект выполняется на основе задания, выданного преподавателем, который является руководителем проекта. Изменение
темы курсового проекта возможно только по согласованию с руководителем до официального утверждения и закрепления тем за студентами. Студент вправе сам предложить формулировку темы и задания,
и в этом случае тема и задание должны быть в обязательном порядке
согласованы с руководителем и одобрены заведующим кафедрой.
Допускается совместная работа над одной темой двух (но не более!) студентов. В этом случае каждый из соисполнителей в отчете по
курсовому проекту представляет свою часть работы. При этом вопросы на защите проекта каждому студенту могут задаваться по всей работе в целом.
4
Подготовка курсового проекта
При выполнении курсового проекта студенту предлагается:
 провести исследование предметной области (объекта исследования);
 на основе анализа требований к системе построить диаграммы DFD и, при необходимости IDEF3, описывающие предметную область процессы, происходящие в ней, их взаимосвязь.
При применении объектно-ориентированного подхода построить:
 диаграмму вариантов использования;
 диаграммы видов деятельности;
 диаграмму классов;
 диаграммы взаимодействий;
 диаграммы состояний.
Кроме того, необходимо разработать модель пользовательского
интерфейса, а также построить диаграммы физической реализации:
 диаграмму компонентов;
 диаграмму развертывания.
Структура курсового проекта
Внутренняя структура работы должна состоять из введения, разработки модели информационной системы на различных уровнях
представления, заключения, списка использованной литературы и
приложений. Материал в курсовом проекте располагается в следующей последовательности:
1. Титульный лист (см. приложение 2),
2. Оглавление (см. приложение 3);
3. Задание;
4. Введение;
5. Содержательная часть работы;
6. Заключение;
7. Список использованной литературы;
8. Приложения (если имеются)1.
1
В приложения можно выносить громоздкие или малоинформативные таблицы,
схемы, графики.
5
Требования к содержанию курсового проекта
Содержание должно включать нумерованный список разделов
работы с указанием номеров страниц.
Задание содержит текст условия задания на курсовое проектирование (описание предметной области и требования к проектируемой
системе).
Следует обратить внимание на то, что задание на курсовое проектирование не может охватывать все аспекты функционирования ИС,
т. е. не может быть достаточно полным и содержать описание всех
тонкостей и особенностей функционирования системы. В связи с этим
допускается производить корректировку задания, добавлять новые
условия или изменять имеющиеся, делать предположения, не противоречащие оригинальному заданию. Любые допущения или внесение
корректировок должны быть согласованы с руководителем и описаны
в анализе требований (см. ниже).
Введение. Во введении необходимо привести анализ требований
к системе (анализ задания) с указанием её особенностей, схожести с
уже известными существующими системами, потенциальных проблем
и трудностей, с которыми придется столкнуться в процессе работы, а
также возможных путей и способов их преодоления. Необходимо сделать выводы относительно того, в каком направлении развивать проект, какие технологии проектирования планируется использовать. Все
рассуждения и выводы необходимы для формирования у исполнителя
собственного мнения относительно будущего проекта, поэтому могут
носить приблизительный характер.
Содержательная часть работы
Проектирование вариантов использования. Данный раздел должен содержать подробное описание процесса выявления вариантов
использования проектируемой системы (для этого рекомендуется использовать подход, основанный на распределении требований по
субъектам и прецедентам), построенные диаграммы вариантов использования и пояснения к ним. Кроме того, здесь необходимо привести полную описательную спецификацию к каждому варианту использования.
Проектирование классов-сущностей может проводиться параллельно с выявлением вариантов использования. В этом разделе курсового проекта должен быть представлен и описан процесс выявления
классов-сущностей проектируемой системы, их атрибутов и взаимосвязей между ними. Для каждого класса необходимо обозначить его
6
задачи, обосновать необходимость его наличия в системе, проанализировать связи с другими классами, обосновать установление каждого
типа связи.
Проектирование видов деятельности. Данный раздел курсового
проекта должен включать описание процесса выявления видов деятельности при построении для каждого варианта использования диаграмм видов деятельности. Каждая диаграмма видов деятельности
должна быть снабжена комментариями и пояснениями.
Проектирование взаимодействий. В этом разделе проекта необходимо представить диаграммы последовательностей и коопераций,
построенные для каждого варианта использования или вида деятельности, с описаниями и пояснениями.
Проектирование состояний. Здесь необходимо привести диаграммы состояний для классов (и прецедентов, если это необходимо с
точки зрения разработчика проекта). Кроме самих диаграмм, необходимо привести рассуждения относительно того, для каких элементов
проекта целесообразно строить диаграммы, и обоснование принимаемых в связи с этим решений.
Проектирование статической структуры системы представляет
собой построение полной диаграммы классов, включая, помимо классов-сущностей, пограничные и управляющие классы, а также их атрибуты, операции и связи между ними.
Проектирование пользовательского интерфейса. В данной части
курсового проекта должны быть представлены схемы, иллюстрирующие взаимодействие элементов пользовательского интерфейса и диаграммы навигации между окнами. Модель интерфейса должна быть
построена с учетом основных принципов создания GUI.
Проектирование архитектуры системы. В этом разделе должна
быть приведена архитектура, выбранная для развертывания будущего
приложения, обоснование выбора указанной архитектуры, аппаратное
и программное обеспечение используемой для развертывания системы. Кроме того, здесь должна быть представлена диаграмма развертывания, демонстрирующая взаимосвязь аппаратных и программных
элементов системы.
Заключение. В заключении должны быть приведены основные
выводы по результатам разработки проекта системы, оценка степени
готовности проекта для дальнейшей реализации, обозначить достоинства и недостатки проекта, привести причины и возможные пути
устранения последних.
7
Список использованной литературы должен содержать перечень источников материалов, использованных в процессе разработки
проекта и написания отчета по курсовой работе.
Требования к оформлению текста работы
Текст отчета по курсовому проекту должен быть оформлен в соответствии со следующими правилами:
 поля: левое – 3 см, верхнее, нижнее, правое – 2 см;
 основной текст: шрифт Times New Roman, размер 14 пт,
начертание обычное, междустрочный интервал одинарный, выравнивание по ширине отступ первой строки 1,25 см;
 заголовки первого уровня: шрифт Arial, размер 14 пт, начертание полужирное, все буквы прописные, выравнивание по левому
краю, без отступа первой строки;
 заголовки второго уровня: шрифт Arial, размер 14 пт, начертание полужирное, выравнивание по левому краю, без отступа первой
строки;
 заголовок третьего уровня: шрифт Times New Roman, размер
14 пт, начертание полужирное, выравнивание по левому краю, c отступом первой строки 1,25 см.
Рисунки следует размещать в отдельном абзаце с выравниванием
по центру. Все рисунки должны быть пронумерованы и подписаны
(нумерация сквозная). Параметры подписи: расположение – под рисунком, выравнивание по центру, шрифт Times New Roman, размер
12 пт, начертание курсивное.
Все таблицы в тексте также должны быть пронумерованы и подписаны. Параметры названия таблиц: расположение – над таблицей,
выравнивание по центру, шрифт Times New Roman, размер 14 пт,
начертание обычное. Размер шрифта текста в таблице не более 12 пт.
Подготовка курсового проекта к защите
Оформленный курсовой проект представляется студентом преподавателю в электронном виде (файлы проекта, выполненные с помощью CASE-средств, а также файл отчета по курсовому проекту) и в
твердой копии (папка с распечатанным текстом отчета по проекту)
для просмотра не позднее двух недель до начала сессии. По результатам проверки работы она либо допускается, либо не допускается к за8
щите. В случае, если руководитель не допускает работу к защите, он
должен указать, какие разделы работы не соответствуют требованиям,
какие в ней имеются критические ошибки, вследствие которых она к
защите не допускается до её исправления. После получения допуска
студент должен защитить работу в сроки, установленные графиком
защит курсовых проектов.
Защита и оценка курсового проекта
На защиту курсового проекта отводится до 15 минут.
Возможен прием курсовых работ в присутствии комиссии, состоящей из нескольких преподавателей кафедры ИС.
Во время защиты курсового проекта студент должен в течение
5–7 минут выступить с докладом, сформулировать цель работы, изложить содержание, акцентируя внимание на наиболее важных и интересных с его точки зрения решениях, в первую очередь, приятых студентом самостоятельно. Доклад должен быть тщательно продуман,
изложение должно быть последовательным и логичным. При выступлении должна быть проведена демонстрация основных результатов
работы с помощью подготовленной презентации, созданной с целью
максимально полного освещения наиболее важных и интересных аспектов работы, а также формирования у комиссии адекватного представления о выполненной работе. Без презентации студент к защите
не допускается!
После завершения изложения доклада студент должен ответить
на вопросы членов комиссии по представленной работе и её результатам.
При определении итоговой оценки по защите курсового проекта
учитываются содержание и оформление работы, доклад студента, ответы на вопросы, а также презентация.
Студенты, выполнившие курсовой проект, но получившие при
защите неудовлетворительную оценку, имеют право на повторную
защиту.
При неудовлетворительной оценке работы преподаватель устанавливает, может ли студент представить к повторной защите ту же
работу с необходимой доработкой или должен разработать новую тему.
9
Раздел 2. ПРИМЕР ВЫПОЛНЕНИЯ КУРСОВОГО
ПРОЕКТА С ИСПОЛЬЗОВАНИЕМ
RationalRoseEnterpriseEdition
В распоряжении агентства находятся несколько видов рекламных
услуг (реклама в Интернете, щитовая реклама, реклама в печатных
изданиях и на CD дисках), которые предлагаются клиентам. Клиент
вправе выбрать и заключить договор на предоставление нескольких
видов рекламных услуг. Задачи привлечения клиентов и продажи
услуг агентства возложены на менеджеров. Требуется автоматизировать работу внутри рекламного агентства с целью улучшения взаимодействия отдельных подразделений и повышения эффективности труда менеджеров.
Основная рутинная работа агентства связана с поиском рекламодателей и заключением с ними договоров. Эта задача возложена на
менеджеров. Информационная система должна обеспечивать поддержку деятельности менеджера при его работе с клиентами. Каждый
менеджер должен иметь возможность работы только с теми клиентами, ответственность за которых он несет. Менеджер имеет имя и пароль для входа в систему. После входа в систему ему открывается
главное окно программы.
Менеджер определяет список свободных в настоящее время рекламных площадей. Этот список также должен предоставляться системой. Система определяет, свободна ли рекламная площадь, исходя
из сроков окончания действующих договоров с клиентами. После того, как список свободных рекламных площадей определен, менеджер
звонит клиенту с целью предложить услуги рекламного агентства.
Список клиентов, а также информация о них предоставляется руководством и вводится в систему администратором. При начале очередного действия (звонок, посещение клиента, заключение договора и т.
д.) менеджер вносит информацию о нем в систему. Таким образом
менеджер регистрирует в системе событие. При регистрации события
фиксируется время и дата его совершения, а также результаты. В результате звонка, менеджер может договориться с клиентом о заключении договора, обговорить детали и согласовать время встречи для его
подписания, либо договориться о повторном звонке, либо очной
встрече, возможно для обсуждения деталей договора. Менеджер также может получить отказ от использования услуг данного рекламного
агентства. В случае отказа, он и его причины фиксируются в системе.
В случае необходимости совершения повторного звонка или встречи,
10
это также фиксируется. Если менеджер совершает повторный звонок
или встречается с клиентом, он вносит информацию об этом в систему
в виде очередного события для данного клиента. Как видно из предыдущего описания, любое событие должно быть зафиксировано, с указанием даты и времени его совершения, а также результатов.
Конечным результатом события может быть либо заключение договора, либо отказ клиента. В случае согласия клиента на заключение
договора менеджер оформляет договор, распечатывает и подписывает
его у клиента и руководителя рекламного агентства. В системе сохраняется информация о договоре для последующего контроля соблюдения его условий.
После заключения договора, менеджер обязан контролировать
процесс создания и размещения рекламных материалов клиента, а
также оплату последним суммы, указанной в договоре. Для этого в
системе должна быть предусмотрена возможность ввода платежей
клиента, а также окончания этапов создания и размещения рекламных
материалов.
Система также должна иметь возможность формирования по запросу менеджера списка клиентов, с которыми агентство давно не работало, чтобы предложить этим клиентам вновь воспользоваться рекламными услугами.
Администратор системы осуществляет ее безопасность. Для этого
он назначает всем пользователям системы (менеджерам) имена и пароли. В задачи администратора также входит назначение менеджерам
клиентов и реквизитов клиентов в систему. Кроме того, администратор может изменять настройки системы.
Система должна быть спроектирована на основе клиентсерверной архитектуры.
Пример построения диаграммы вариантов использования
Для выявления вариантов использования проектируемой системы
можно построить таблицу распределения требований по субъектам и
прецедентам.
На основании информации, представленной в таблице 1, были построены две диаграммы вариантов использования (по числу субъектов). Построение для каждого из субъектов системы отдельной диаграммы вариантов использования было выполнено исходя из соображения удобства представления. Построенные диаграммы представлены ниже.
11
Таблица 1 – Распределение требований по субъектам
и прецедентам
Требование
1
Основная рутинная работа агентства связана с
поиском рекламодателей и заключением с ними
договоров. Эта задача возложена на менеджеров. Информационная система должна обеспечивать поддержку деятельности менеджера при
его работе с клиентами. Каждый менеджер
должен иметь возможность работы только с
теми клиентами, ответственность за которых он
несет.
Менеджер имеет имя и пароль для входа в систему. После входа в систему ему предоставляется список клиентов, для которых в настоящее
время не действуют договора, либо процесс
заключения договора не завершен.
Менеджер определяет список свободных в
настоящее время рекламных площадей. Этот
список также должен предоставляться системой. Система определяет, свободна ли рекламная площадь, исходя из сроков окончания действующих договоров с клиентами.
После того, как список свободных рекламных
площадей определен, менеджер должен запланировать работу с клиентом. Он звонит клиенту
с целью предложить услуги рекламного
агентства. Список клиентов, а также информация о них предоставляется руководством и вводится в систему администратором.
При начале очередного действия (звонок, посещение клиента, заключение договора и т.д.)
менеджер вносит информацию о нем в систему.
Таким образом менеджер регистрирует в системе событие. При регистрации события фиксируется время и дата его совершения, а также
результаты.
12
Субъект
2
Прецедент
3
Менеджер
Назначение
клиентов
менеджерам
Менеджер
Вход
в систему
Менеджер
Определение
списка рекламных
площадей
Администратор
Планирование
работы с клиентом
Добавление
нового клиента
Менеджер
Регистрация
события в
системе
Окончание табл. 1
1
2
После заключения договора, менеджер обязан
контролировать процесс создания и размещения
рекламных материалов клиента, а также оплату
последним суммы, указанной в договоре. Для
Менеджер
этого, в системе должна быть предусмотрена
возможность ввода платежей клиента, а также
окончания этапов создания и размещения рекламных материалов.
Система также должна иметь возможность
формирования по запросу менеджера списка
клиентов, с которыми агентство давно не работало, чтобы предложить этим клиентам вновь Менеджер
воспользоваться рекламными услугами.
Администратор системы также имеет свои логин и пароль для входа в систему. В задачи администратор по работе с системой входит
назначение всем пользователям системы (менеджерам) имен и паролей (добавление менеджеров в систему), изменение их данных, назначение менеджерам клиентов, а также ввод реквизитов клиентов в систему. Кроме того, администратор может изменять настройки системы.
13
Администратор
3
Контроль
выполнения
условий
договора;
Внесение
платежей
клиента
Формирование
списка
клиентов,
давно не использующих
рекламные
услуги
Вход в систему;
Создание
нового пользователя
(менеджера);
Изменение
данных пользователя
Назначение
клиентов
менеджерам;
Добавление
нового клиента;
Изменение
настроек системы
Рисунок 1 – Диаграмма вариантов использования для субъекта "Менеджер"
Рисунок 2 – Диаграмма вариантов использования для субъекта
"Администратор"
14
Для завершения этапа моделирования вариантов использования
необходимо описать каждый прецедент. Типовая структура описательной спецификации и примеры описания по такой структуре приведены в таблицах 2 и 3.
Таблица 2 – Описание прецедента «Вход в систему»
1. Краткое
описание
2. Субъект
3. Предусловие
4.1. Основной
поток
4.2. Альтернативные потоки
5. Постусловие
Пользователь входит в систему, чтобы начать работу.
Менеджер
Администратор
Пользователь запускает систему
При запуске система выводит окно, в котором предлагается
ввести логин и пароль. Пользователь вводит свои логин и
пароль и инициирует процесс авторизации выбором соответствующей функции. При этом функция авторизации будет
недоступна (неактивна), пока пользователь не заполнит оба
поля. После выбора функции авторизации система запускается, и пользователь может начинать работать.
Пользователь ввел неверное имя или пароль. В этом случае
система уведомляет об этом и предлагает попробовать ввести
еще раз.
При успешном выполнении пользователь начинает работу.
Если прецедент выполняется менеджером, система после
успешного входа открывает ему список клиентов, которым
следует предложить услуги.
Таблица 3 – Описание прецедента «Регистрация события в системе»
1. Краткое
Пользователь входит в систему, чтобы начать работу
описание
2. Субъект
Менеджер
3. Предусловие Совершено очередное событие в процессе работы с клиентом
Для начала выполнение данного прецедента менеджер должен
открыть в системе текущую работу с клиентом и выбрать на открывшейся форме функцию создания нового события. В результате на форме появляется пустое событие, для которого менеджер должен выбрать тип (звонок, встреча и т. д.), отметить
4.1. Основной
дату и время совершения, а также зафиксировать результат (попоток
вторный звонок, отказ, заключение договора и т. д.). В случае,
если результатом события является отказ, менеджер должен внести его причины в соответствующем поле. После внесения всей
необходимой информации о событии менеджер инициирует сохранение, в результате чего новое событие сохраняется в системе.
15
Окончание табл. 3
4.2. Альтернативные
потоки
Менеджер пытается сохранить событие, не заполнив какое-либо
из обязательных полей. В этом случае система выводит сообщение и предлагает исправить возникшую ошибку.
5. Постусло- При успешном выполнении прецедента в текущей работе с кливие
ентом появляется новое событие.
Подобным образом необходимо описать каждый из выявленных
ранее прецедентов. Описания основных и альтернативных потоков
становятся основой для дальнейшего проектирования, в частности,
для построения диаграмм видов деятельности, а также взаимодействий.
Пример построения диаграммы видов деятельности
Как было сказано выше, диаграммы видов деятельности строятся
на основании описания основных и альтернативных потоков событий
прецедентов. Для примера приведем диаграммы видов деятельностей,
описанных в предыдущем разделе.
Рисунок 3 – Диаграмма видов деятельности для прецедента
"Вход в систему"
16
Рисунок 4 – Диаграмма видов деятельности для прецедента "Регистрация
события в системе"
Как видно из рисунков 3 и 4, диаграммы полностью соответствуют описанию основного и альтернативных потоков событий соответствующих прецедентов и представляют их в графической форме. Как
известно, в отличие от описания потоков событий, диаграммы строятся с внутрисистемной точки зрения. На диаграммах это можно видеть
в названиях деятельностей («Получить запрос на сохранение» вместо
«Нажать кнопку сохранения», «Принять логин и пароль» вместо
«Ввести логин и пароль» и т. д.).
Построенные диаграммы видов деятельности должны быть описаны, при этом особое внимание необходимо уделять объяснению и
комментариям к наиболее интересным или сложным местам (синхронизация деятельностей, сложное ветвление и т. д.)
Диаграммы видов деятельности, наряду с диаграммами классов и
прецедентов, служат в дальнейшем основой для построения диаграмм
взаимодействий.
Пример построения диаграммы классов
Работа по моделированию классов-сущностей может проводиться
параллельно с разработкой диаграмм вариантов использования. Классы-сущности, как и прецеденты, выявляются на основе требований к
системе. Ниже приведен пример выявления и описания классов17
сущностей, а также построенной диаграммы классов-сущностей для
описанной выше системы.
На основе анализа требований к системе можно сразу выделить
несколько классов-сущностей, которые очевидно нужны в системе.
Во-первых, очевидно, что в системе необходим класс, в котором
хранится вся информация о клиентах, когда-либо обращавшихся в
агентство. Таким классом будет класс Клиент. Этот класс имеет следующие атрибуты:
– Код клиента;
– Наименование клиента;
– Организация;
– Адрес;
– Телефон;
– ФИО руководителя.
Атрибут Код клиента – это уникальный идентификатор клиента в
системе. Его значение присваивается автоматически при регистрации
клиента в системе. Атрибут Наименование клиента – это название
организации, предприятия или фирмы, обратившейся за рекламными
услугами в агентство. Следующий атрибут – Организация – дополнительный атрибут, он введен в систему всего лишь для большей информативности. Его значение показывает, является ли данный клиент
юридическим лицом, организацией или нет. Атрибуты Адрес и Телефон хранят адрес и контактный телефон клиента соответственно. Атрибут ФИО Руководителя предназначен для хранения фамилии, имени и отчества руководителя клиента.
Кроме того, в системе необходим класс, хранящий информацию о
менеджерах и администраторах. Такими классами будет Пользователь. Этот классы имеет следующие атрибуты:
– Код пользователя;
– Тип пользователя;
– Логин;
– Пароль;
– ФИО;
– Адрес;
– Телефон;
– Дата приема на работу.
Значение атрибута Код пользователя является уникальным идентификатором пользователя в системе. Атрибут Тип пользователя нужен для определения прав пользователя при входе в систему. Т. е.
каждому типу пользователя соответствуют определенные права. Так,
18
например, пользователь типа администратор имеет права на любые
действия в системе: изменение, добавление, удаление данных, изменение настроек системы и т. д. Пользователь типа менеджер не имеет
права ничего удалять, изменять или добавлять, его права ограничены
просмотром списка своих клиентов (т. е. клиентов, закрепленных за
ним), ведением работы с ними, просмотром других данных (например,
списка рекламных площадей), формированием отчетов.
Атрибут Логин – это имя пользователя, назначаемое администратором и используемое для входа в систему. Атрибут Пароль в сочетании с предыдущим атрибутом используется для авторизации пользователя в системе.
Следующий класс, необходимость создания которого не вызывает
сомнений, – это класс Договор. Этот класс хранит всю информацию о
заключаемых договорах и имеет следующие атрибуты:
– Код;
– Номер договора;
– Менеджер;
– Клиент;
– Площади;
– Сумма;
– Статус;
– Дата заключения;
– Дата окончания.
Атрибут Код – уникальный идентификатор конкретного договора
в системе. Атрибут Номер договора – это номер очередного договора,
его значение присваивается автоматически при создании договора.
Атрибуты Менеджер и Клиент хранят информацию, соответственно,
о менеджере, заключившем договор, и о клиенте, с которым этот договор заключен. Следующий атрибут – Площади – хранит список
площадей, арендованных клиентом по данному договору. Атрибут
Сумма – это сумма договора, которую клиент обязан оплатить, чтобы
фирма разместила его рекламу в соответствии с договором. Атрибут
Статус предназначен для присвоения договору различных статусов,
его значениями могут быть, «заключен» или «оплачен», «исполнен».
Значение последних двух атрибутов вполне ясно, поэтому на них
останавливаться не будем.
Для хранения информации о рекламных площадях в системе необходим класс Площадь. Этот класс будет иметь следующие атрибуты:
19
– Код;
– Тип;
– Адрес;
– Статус.
Атрибут Код, как и во всех других классах, – это уникальный
идентификатор конкретной площади в системе. Следующий атрибут –
Тип – хранит тип площади. Его значениями могут быть типы рекламных площадей, находящихся в распоряжении рекламного агентства.
Это щитовая реклама, реклама в Интернет, реклама на/в транспорте и
т. д. Атрибут Адрес нужен для указания конкретного адреса каждой
рекламной площади. Атрибут Стоимость аренды необходим для
определения стоимости аренды каждой площади за единицу времени
(сутки, неделя, месяц). Наконец, атрибут Статус хранит статус площади. Он может принимать одно из двух значений – «свободно» или
«арендовано».
Для хранения информации об операциях, проводимых в процессе
работы с клиентом, был выявлен класс Событие. Предполагается
наличие следующих атрибутов в классе Событие:
– Код;
– Менеджер;
– Клиент;
– Дата;
– Время;
– Результат;
– Примечание.
Здесь, пожалуй, стоит остановиться только на двух последних атрибутах. Атрибут Результат хранит результат совершенного события. В качестве значения в этом атрибуте может быть записано следующее:
 «повторный звонок» – этот статус означает, что клиенту необходимо перезвонить;
 «встреча» – с клиентом необходимо встретиться;
 «предварительное согласие» – клиент принял предложение
фирмы и готов заключить договор, но необходимо согласование деталей и условий;
 «отказ» – клиент отказался от предлагаемых ему рекламных
услуг;
 «заключение договора» – это означает, что все детали с клиентом согласованы и следующим этапом работы будет заключение договора.
20
Атрибут Примечание необходим для того, чтобы фиксировать
комментарии к событию, если это необходимо.
Наконец, на начальном этапе анализа требований была выявлена
необходимость создания еще одного класса, хранящего все события,
фиксируемые в процессе работы с клиентом. Назовем этот класс Работа. Он будет иметь следующие атрибуты:
– Код;
– Менеджер – для хранения менеджера, создавшего работу;
– Клиент – для хранения клиента, с которым ведется работа;
– Дата создания;
– Клиент;
– Договор – предполагается, что этот атрибут примет значение
номера договора, который по результатам работы будет заключен, если результатом работы будет заключение договора с клиентом;
– Событие – список событий, зафиксированных в системе в
процессе работы;
– Результат – хранит конечный результат работы (отказ или
заключение договора).
Таким образом, мы получили следующие шесть классовсущностей, выявленных на начальном этапе анализа требований.
Рисунок 5 – Классы-сущности проектируемой системы
(первоначальный состав)
21
Теперь необходимо определить, какие между этими классами существуют связи. Помимо определения самих связей, необходимо также разобраться с кратностями выявленных ассоциаций.
Итак, очевидно, что класс Договор будет связан с классами Пользователь, Клиент и Площадь, а также с классом Работа. Рассмотрим
каждую из этих связей в отдельности.
Между классом Клиент и Договор существует ассоциативная
связь. Ясно, в заключении одного договора участвует только один
клиент, т. е., грубо говоря, один договор может включать только одного клиента, поэтому кратность здесь будет равна 1. Один же клиент
может заключить с агентством как минимум один договор, т. е. один и
больше договоров, поэтому кратность равна 1..n. Для одного из концов этой же связи на стороне класса Договор обозначим ролевое имя
«клиент», которое будет означать, что помимо атрибутов самого класса Договор, в нем при реализации появится еще и атрибут, который
будет ссылкой на объект класса Клиент. Аналогичным образом обозначены ролевые имена для остальных связей.
Рассмотрим ассоциацию между классами Пользователь и Договор. В принципе, она аналогична предыдущей ассоциации, за исключением того, что пользователю в системе может не соответствовать ни
один договор, если он является администратором (0..n).
Следующая связь – ассоциация между классами Площадь и Договор. Данная ассоциация имеет следующие кратности: в одном договоре может быть указано несколько площадей (т. е. в договоре будет
указан список площадей), таким образом, получим кратность 1..n, и
одна площадь может использоваться много раз, т. е. содержаться во
многих договорах (1..n).
Рассмотрим теперь связь между классами Договор и Работа. Договор может быть связан с единственной работой (1), а работа может
быть связана с как одним договором, так и не быть связана с договором вообще, если она не закончилась заключением договора (0..1).
Ассоциации Клиент – Работа и Пользователь – Работа моделируются совершенно аналогично ассоциациям Клиент – Договор и
Пользователь – Договор соответственно, поэтому на них подробно
останавливаться не стоит.
Рассмотрим ассоциацию Пользователь – Клиент. Здесь тоже все
достаточно просто. Один клиент закреплен за единственным менеджером (1), а одному пользователю может не соответствовать ни один
клиент, если пользователь является администратором, или может со22
ответствовать много клиентов, если пользователь является менеджером (1..n).
Следующая связь, которая заслуживает внимания, – это связь
между классами Событие и Работа. Между ними установлена агрегация по значению (композиция): работа состоит из событий, события
– это части работы.
На рисунке 6 представлена диаграмма классов с выявленными
связями и их кратностями.
Рисунок 6 – Диаграмма классов-сущностей (начальный вид)
Пример построения диаграмм взаимодействий
На диаграммах взаимодействий изображают один из процессов
обработки информации в варианте использования. То есть, если в варианте использования несколько альтернативных потоков, для него
нужно строить несколько диаграмм взаимодействий. Таким образом,
на одной диаграмме будет показано, что происходит, когда всё в порядке, а на других будет изображен ход событий в альтернативных
потоках.
Примеры диаграмм для прецедентов, описание и диаграммы видов деятельности, для которых приведены в соответствующих разделах настоящих методических указаний, представлены на рисунках
7–10.
23
На рисунке 7 изображена диаграмма последовательности сообщений, передаваемых в процессе выполнения основного потока прецедента «Вход в систему». К каждому сообщению привязана операция, т. е. если на диаграмме объекту класса посылается сообщение,
оно становится операцией в классе, которому принадлежит объект,
принимающий сообщение.
Как видно из соответствующей диаграммы видов деятельности,
прецедент начинается с открытия формы авторизации при запуске системы. Затем в эту форму производится ввод логина и пароля, после
чего пользователь запускает авторизацию выбором соответствующей
функции. Очевидно, для моделирования взаимодействия объектов в
процессе выполнения вышеописанного необходимо ввести новый
класс, который будет реализовывать интерфейс и функции формы авторизации. Это будет пограничный класс (класс со стереотипом
boundary) Назовем его «Форма авторизации». Взаимодействие субъекта с системой в начале выполнения прецедента осуществляется через этот класс. Для начала форма авторизации должна быть открыта.
Смоделируем это отправкой соответствующему классу сообщения
отобразить. Таким образом, в классе Форма авторизации появляется
метод, отвечающий за его открытие. Далее сообщением 2 моделируем
операцию ввода данных в поля формы. Сообщение 3 вызывается классом в себе самом и моделирует операцию, которая отвечает за активацию кнопки входа после появления данных во всех необходимых полях (а именно логин и пароль). Сообщение 4 – это фактически нажатие кнопки входа. На этом работа с интерфейсом пока заканчивается,
поэтому для дальнейшего выполнения прецедента необходим новый
класс, который принял бы управление от пограничного класса, обработал бы поступивший запрос и выполнил дальнейшие необходимые
действия. Другими словами, здесь необходим управляющий класс,
назовем его «Авторизация». В ответ на нажатие кнопки входа форма
авторизации передает этому классу полученные от пользователя логин
и пароль. Это показано сообщением 5 с соответствующими параметрами. Управляющий класс принимает значения и передает их контейнерному классу Пользователи для нахождения соответствия (сообщение 6). Если переданная комбинация логин-пароль найдена в классе
Пользователи, этот класс передает управляющему классу тип найденного пользователя для определения его прав (сообщение 7). После
успешного определения прав пользователя открывается главное окно
программы (сообщение 8).
24
Рисунок 7 – Диаграмма последовательности для основного потока событий
прецедента "Вход в систему"
Аналогичным образом строятся и описываются остальные диаграммы последовательности. Примеры – на рисунках 8–10.
Рисунок 8 – Диаграмма последовательности для альтернативного
потока событий прецедента «Вход в систему»
25
На этапе моделирования взаимодействий в систему добавляются
новые классы, что видно на диаграммах, представленных на рисунках
7 и 8. В процессе их построения были выявлены и добавлены такие
классы, как Форма авторизации, Главное окно (пограничные), Авторизация (управляющий) и Пользователи (контейнерный). Диаграммы
построены с применением подхода BCE (Boundary-Control-Entity; подробнее о подходе в [1], параграф 5.2.4).
Ниже представлены диаграммы, изображающие последовательность операций при выполнении прецедента «Регистрация события в
системе».
Рисунок 9 –Диаграммы последовательности для основного потока
событий прецедента "Регистрация события в системе"
Каждая построенная диаграмма последовательности в работе
должна быть описана.
RationalRose имеет возможность строить диаграммы кооперации
автоматически на основании диаграммы последовательности и наоборот. Для переключения между двумя видами диаграмм взаимодействий достаточно при открытой диаграмме последовательности/кооперации нажать клавишу F5.
26
Рисунок 10 – Диаграммы последовательности для альтернативного потока
событий прецедента "Регистрация события в системе"
Пример диаграммы кооперации для основного потока событий
прецедента «Регистрация события в системе» приведен на рисунке 11.
Рисунок 11 – Диаграмма кооперации для основного потока прецедента
"Регистрация события в системе"
27
На диаграмме кооперации представлена вся та же информация,
что на диаграмме последовательности, но, как известно, с разными
акцентами. Разработчики не всегда строят диаграммы кооперации. Их
имеет смысл представить тогда, когда необходимо проанализировать
взаимодействие двух конкретно взятых объектов.
После построения всех необходимых диаграмм взаимодействий
первоначальный состав классов проектируемой системы значительно
расширяется, поскольку, как уже было отмечено выше, этап моделирования взаимодействий сопряжен с необходимостью вводить новые
классы в модель. Впоследствии эти классы добавляются к начальной
диаграмме классов сущностей для моделирования статической структуры системы.
Кроме того, поскольку каждое сообщение, посылаемое объекту,
становится в соответствующем классе операцией, в процессе создания
диаграмм взаимодействий в классах появляются операции. Так,
например, после построения диаграммы последовательности для прецедента Регистрация события в системе существующие классы Событие и Работа будут выглядеть следующим образом:
Рисунок 12 – Вид классов "Событие" и "Работа" после построения
диаграммы последовательности для прецедента
"Регистрация события в системе"
Пример построения диаграмм состояний
Как известно, диаграммы состояний строятся для моделирования
поведения объекта. То есть, на этих диаграммах отображается жизненный цикл одного объекта, начиная с момента его создания и заканчивая его уничтожением. Диаграммы состояний не требуется созда28
вать для каждого класса. Многие проекты вообще обходятся без них.
Явным сигналом, говорящем о необходимости моделирования поведения объекта, является наличие в классе атрибута, от значений которых зависит это самое поведение. Подробнее о том, как проводить
анализ динамики поведения объекта с целью определения необходимости строить для него диаграмму состояний, читайте в [2].
В нашем случае хорошим индикатором нескольких состояний
объекта являются атрибуты Статус в классах Договор, Площадь.
Приведем диаграммы состояний для каждого из них.
Рисунок 13 –Диаграмма состояний для объекта класса "Договор"
На рисунке 13 изображена диаграмма, демонстрирующая поведение объекта класса Договор. Как видно из диаграммы, начальным состоянием для этого объекта является состояние «Активен». Из этого
состояния возможны три перехода. Рефлексивный переход происходит при продлении договора (событие), однако продление может произойти только при условии, что срок действия договора истекает не
ранее, чем через пять дней (ограждающее условие). Разберем переход
«Активен» – «Исполнен». Этот переход выполняется в том случае,
если одна из сторон по каким-либо причинам не выполняет условия
договора, причем при наступлении данного события переход происходит в любом случае (это показано отсутствием ограждающего усло29
вия). Само состояние «Расторгнут» имеет входное действие (entry)
«освободить рекламные площади», т. е. поведение, которое проявляется, когда объект переходит в данное состояние. То есть при расторжении договора освобождаются рекламные площади, которые по этому договору были арендованы.
Переход «Активен» – «Исполнен» обозначен событием «условия
договора выполнены» с ограждающим условием «договор действует».
Этим показано, что договор считается исполненным в том случае, когда выполнены все его условия, при этом договор продолжает действовать, т. е. площади, арендованные по данному договору, остаются
заняты до окончания срока действия договора. Как только срок действия договора при выполненных его условиях истекает, договор переходит в состояние «Завершен». Это показано соответствующим переходом с событием «срок действия договора подошел к концу» с
ограждающим условием «условия договора выполнены».
Как видно из диаграммы, конечными состояниями для объекта
класса Договор, т. е. состояниями, в которых он может находиться
непосредственно перед уничтожением, могут быть состояния «Расторгнут» или «Завершен». Конечные состояния (точки выхода) необязательны, т. е., к примеру, их могло не быть, если бы завершенные ли
расторгнутые договоры не удалялись из системы. В нашем случае мы
предположили, что после того, как договор расторгается или завершается, он удаляется из системы. Поэтому на диаграмме изображен переход из этих состояний в точку выхода (можно было изобразить две
отдельные точки выхода для каждого из этих состояний).
Теперь приведем диаграмму состояний для объекта класса Площадь. Анализируя возможные значения атрибута Статус, можно сделать вывод о том, что площадь может находиться в состояниях «Свободна» или «Арендована». Диаграмма состояний для объекта класса
Площадь
будет
выглядеть
следующим
образом:
Рисунок 14 – Диаграмма состояний для объекта класса "Площадь"
30
На диаграмме представлены указанные выше состояния с взаимными переходами между ними. Данная диаграмма достаточно проста.
Изначально новая площадь (т. е. вновь созданный объект класса Площадь) находится в состоянии «Свободна». Из этого состояния она
может перейти в состояние «Арендована» при наступлении события
«заключен договор на аренду площади», т. е. если клиент желает
арендовать рекламную площадь, и в подтверждение этого с ним заключается договор, по которому он арендует выбранную площадь на
определенный срок, в течение которого действует договор. Обратный
переход происходит тогда, когда договор, по которому данная площадь была арендована, успешно завершен либо расторгнут по инициативе одной из сторон.
Рефлексивный переход происходит при продлении срока действия договора, по которому арендована площадь. При этом для перехода указано событие «продление договора», а в качестве аргумента
данного события указан срок продления договора.
Таким образом, диаграммы документируют динамику поведения
объекта, благодаря чему аналитики и разработчики получают о нем
четкое представление.
Пример построения полной диаграммы классов
Полная диаграмма классов представляет статическую структуру
проектируемой системы. На ней изображаются все классы с их атрибутами и методами, необходимость создания которых была выявлена
в процессе работы над проектом системы. Смоделированные классы
необходимо связать друг с другом. Основанием для выявления связей
между классами служат диаграммы взаимодействий, в частности,
удобнее пользоваться диаграммами кооперации. Если объекты кооперируют друг с другом, значит, между соответствующими классами
должна быть установлена связь. Фрагмент диаграммы, представляющей статическую структуру системы, приведен на рисунке
31
Рисунок 15 – Фрагмент статической структуры системы
Пример построения диаграммы развертывания
Поскольку диаграмма развертывания (размещения) отражает физические взаимосвязи между программными и аппаратными компонентами системы, она является хорошим средством для изображения
размещения объектов и компонентов в распределенной системе. Диаграмма развертывания для нашего примера приведена на рисунке 16.
32
Рабочее место
менеджера 1
локальная сеть
Сервер СУБД
Рабочее место
администратора
локальная сеть
Рабочее место
менеджера N
локальная сеть
Рисунок 16 – Диаграмма развертывания проектируемой системы
На диаграмме показаны три узла, каждый их которых является
процессором (processor), то есть обладает собственной вычислительной мощностью. Центральный узел – это сервер, с которым в локальной сети соединены рабочие станции. Рабочих станций изображено на
диаграмме три. Одна из них – это рабочее место администратора. Две
другие – рабочие места менеджеров. Предполагается, что одновременно с системой могут работать несколько менеджеров, поэтому было принято решение показать на диаграмме рабочее место менеджера
1 и рабочее место менеджера N.
Устройства (device) на диаграмме отсутствуют, что продиктовано
отсутствием необходимости их наличия для физического размещения
компонентов системы. Они изображаются для моделирования узлов,
не имеющих вычислительной мощности (терминалы ввода/вывода,
принтеры, сканеры).
Пример построения диаграмм навигации
Проектирование
пользовательского
интерфейса
(GUI–
GraphicUserInterface)осуществляется с соблюдением известных принципов, таких как принцип обратной связи, пользовательского контроля, согласованности, индивидуализации и настройки, терпимости к
ошибкам, эргономичности, эстетичности. Уже на этапе описания потоков событий для прецедентов, аналитик, занимающийся это работой, имеет некоторый зрительный образ интерфейса для поддержания
взаимодействия пользователя с системой. Поэтому при проектирова33
нии GUI следует опираться именно на описание потоков событий
прецедентов.
Для построения диаграмм навигации в UML не предусмотрено
специальных диаграмм, поэтому можно пользоваться диаграммами
видов деятельности. В них есть все элементы, которые могут понадобиться при создании модели интерфейса.
При выполнении курсового проекта следует построить диаграммы навигации для как можно большего числа функций. Необязательно
проектировать весь интерфейс системы от начала до конца.
Для обозначения элементов интерфейса можно использовать следующие стереотипы:
 первичное окно – <<primary window>>;
 вторичное окно – <<secondary window>>;
 диалоговое окно – <<dialogbox>>;
 окно сообщений – <<messagebox>>;
 вкладка – <<page>>;
 кнопка – <<button>>;
 поле ввода – <<edit>>;
 надпись – <<label>>;
 флажок («галочка») – <<checkbox>>;
 переключатель – <<radiobutton>>;
 группа переключателей – <<radiogroup>>;
 список (блок со строками) – <<listbox>>;
 выпадающий список – <<combobox>>;
 таблица – <<table>>;
 столбец таблицы – <<column>>;
 меню – <<menu>>;
 пункт меню – <<menuitem>>;
 панель инструментов – <<toolbar>>;
 ссылка – <<link>>.
Приведем примеры диаграмм навигации.
На рисунке 17 представлена диаграмма навигации для функции
авторизации.
34
Рисунок 17 – Диаграмма навигации для функции авторизации
На диаграмме представлено окно авторизации и его основные
элементы. Как видно, это две надписи, два поля ввода (для логина и
пароля), две кнопки (для отмены и входа в систему). При нажатии
кнопки «Отмена» окно закрывается, система не запускается. После
нажатия кнопки «Войти» при условии верно введенных данных открывается главное окно программы. В том случае, если данные введены неверно, после нажатия кнопки «Войти» появится окно сообщений
с соответствующим уведомлением. Кнопка «Ok» в этом окошке позволяет вернуться к форме ввода логина и пароля.
Интерфейс главного окна можно было бы представить на текущей
диаграмме, однако, во избежание её чрезмерной громоздкости и плохой читаемости лучше это сделать на отдельной диаграмме.
В качестве еще одного примера приведем модель интерфейса
главного окна с переходом к форме работы с клиентом.
35
Рисунок 18 – Диаграмма навигации для главного окна и формы работы
с клиентом
36
На рисунке 18 видно, что в главном окне расположены кнопки
запуска основных функций программы, а также кнопка выхода из системы и кнопка закрытия программы. Окно работы с клиентом вызывается нажатием кнопки «Начать работу с клиентом», что показано
стрелкой перехода от соответствующего элемента к модели формы
работы с клиентом. На этой форме для начала необходимо выбрать
клиента. Для выбора клиента необходимо нажать кнопку «Выбрать
клиента», при этом откроется список потенциальных клиентов, т. е.
тех клиентов, которые давно не пользовались услугами агентства, а
также новых клиентов, назначенных данному менеджеру. Кроме того,
на форме имеется поле «Дата начала», в котором фиксируется дата
начала текущей работы. Кнопка «Добавить событие» служит для добавления нового события в рамках работы. Для каждого добавляемого
события из выпадающего списка выбирается наименование; дата, результат и примечание указываются в полях ввода. Дата завершения
работы указывается в поле «Дата завершения», а результат выбирается из выпадающего списка «Результат работы». Значением результата
работы может быть «отказ» либо «заключение договора». Если в качестве результата для работы выбрано заключение договора, становится
активной кнопка «Оформить договор», которая сразу позволяет перейти к форме нового договора. Кнопки «Отмена» и «Сохранить» возвращают к главному окну, с той разницей, что в первом случае возврат к главному окну происходит без сохранения произведенных изменений, во втором – с сохранением изменений.
Интерфейс должен быть хорошо продуман и спроектирован таким образом, чтобы он не противоречил описанию потоков событий
прецедентов, а также модели классов-сущностей.
Проектирование пользовательского интерфейса является завершающим этапом выполнения курсового проекта.
37
Рекомендуемые темы курсовых проектов
1. Разработка проекта программного обеспечения информационной системы, реализующей учет складских операций.
2. Разработка проекта программного обеспечения информационной системы автоматизации деятельности библиотеки.
3. Разработка проекта программного обеспечения информационной системы автоматизации деятельности кадрового агентства.
4. Разработка проекта программного обеспечения информационной системы автоматизации работы рекламного агентства
5. Разработка проекта программного обеспечения информационной системы автоматизированного управления контентом образовательного сайта кафедры.
6. Разработка проекта программного обеспечения информационной системы автоматизированного учета и анализа риэлтерских
услуг.
7. Разработка проекта программного обеспечения информационной системы автоматизированного учета и анализа торговопосреднических операций.
8. Разработка проекта программного обеспечения информационной системы автоматизированного учета операций потребительского кредитования коммерческого банка.
9. Разработка проекта программного обеспечения информационной системы автоматизированного учета расходов на производство
продукции и формирования производственной себестоимости.
10. Разработка проекта программного обеспечения информационной системы поддержки заказов и учета товаров торгового предприятия.
11. Разработка проекта программного обеспечения информационной системы автоматизации работы пункта проката компактдисков.
12. Разработка проекта программного обеспечения информационной системы учета оплаты коммунальных услуг населением.
13. Разработка проекта программного обеспечения информационной системы, реализующей учет и анализ торговых операций.
14. Разработка проекта программного обеспечения информационной системы, реализующей учет перевозок грузов по регионам.
15. Разработка проекта программного обеспечения информационной системы, реализующей функции www-конференции.
38
16. Разработка проекта программного обеспечения информационной системы, реализующей функции каталога ресурсов сети Интернет.
17. Разработка проекта программного обеспечения информационной системы сбора, обработки и передачи информации о рекрутах и
вакансиях через Интернет.
18. Разработка проекта программного обеспечения информационной системы «Клиент-Банк».
19. Разработка проекта программного обеспечения информационной системы, автоматизирующей деятельность книгопечатного издательства.
20. Разработка проекта программного обеспечения информационной системы, автоматизирующей деятельность частной поликлиники.
21. Разработка проекта программного обеспечения информационной системы, автоматизирующей деятельность ателье по пошиву
одежды.
22. Разработка проекта программного обеспечения информационной системы, автоматизирующей деятельность автосалона.
23. Разработка проекта программного обеспечения информационной системы, автоматизирующей деятельность фирмы по продаже
подержанных автомобилей.
24. Разработка проекта программного обеспечения информационной системы, автоматизирующей деятельность пассажирского автопредприятия.
25. Разработка проекта программного обеспечения информационной системы, автоматизирующей деятельность агентства по продаже авиабилетов.
26. Разработка проекта программного обеспечения информационной системы, автоматизирующей деятельность гостиницы.
39
Литература
1. Лешек А. Мацяшек. Анализ и проектирование информационных систем с помощью UML 2.0. Издательский дом «Вильямс», 2008.
2. Боггс У., Боггс М. UML и Rational Rose. Издательство «Лори»,
2006.
3. Боггс У., Боггс М. UML и Rational Rose. Упражнения. Издательство «Лори», 2006.
4. Вендров А. М. Проектирование программного обеспечения
экономических информационных систем. Учебник. Москва, Финансы
и статистика, 2006.
5. Вендров А. М. Практикум по проектированию программного
обеспечения экономических информационных систем. Учебник.
Москва, Финансы и статистика, 2006.
6. Проектирование экономических информационных систем.
Курс лекций под ред. Столбовского Д. Н. Владикавказ, 2006.
7. Гвоздева Т. В., Баллод Б. А. Проектирование информационных
систем. Издательство «Феникс», 2009.
40