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

Министерство образования и науки Российской Федерации

Федеральное агентство по образованию

Новосибирский Государственный технический Университет

Кафедра Автоматики

Расчетно-графическая работа

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

«Проектирование программных систем»

Факультет: АВТ

Группа:      АА-28                                                                            Преподаватель:

Студент: Чупров М.Е.                                                                     Тюнина Л.В.

Дата сдачи:

Отметка о защите:

Новосибирск, 2006

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

Разработка информационной системы, хранящей данные о проданных микроконтроллерах, покупателях, производителей микроконтроллеров.

       2. Постановка задачи проектирования

Необходимо разработать информационную систему, содержащую данные о проданных микроконтроллерах. База данных должна содержать данные о названии микроконтроллера, сколько штук продано, дату продажи, срок гарантии и цену. Также необходима информация о покупателе микроконтроллеров – название фирмы, адрес, телефон и e-mail; о производителе – название фирмы, страна, телефон, e-mail.

3. Выявление требований к проекту

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

- добавление, редактирование данных о микроконтроллерах;

- поиск по критериям.

4. Формирование USECASE-диаграммы

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

Рис. 1. USE CASE-диаграмма

4.1. Описание актеров

Актер «РСЦ»

Осуществляет запросы, просматривает информацию, управляет записями: извлекает из архива, создает, удаляет, обновляет.

Актер «Покупатель»

Имеет право просматривать записи, осуществлять запросы.

Актер «Аdmin»

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

Актер «КТО?»

Осуществляет проверку прав доступа в систему. Имеет отношение обобщения, означающее, что экземпляры потомка («РСЦ», «Покупатель», «Аdmin») взаимодействуют с тем же вариантом использования, что и экземпляр родителя, т.е. для них осуществляется проверка прав доступа в систему.

4.2. Описание прецедента

•  проверка прав доступа;

•  просмотр записей проданных микроконтроллеров;

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

4.3. Описание потоков событий

Этапы основного потока событий:

1. Покупатель выбирает критерии, по которому будет производиться поиск его покупки.

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

3. Покупатель вводит нужные параметры.

4. Система выводит список его покупок по заданным критериям.

А1: Гарантийный срок истёк.

5. Покупатель смотрит запись, подходящую по параметрам.

6. Система выводит подлежит модернизации и ремонту.

А2: Не подлежит модернизации.

7. Покупатель подтверждает сообщение.

8. Вариант использования завершается.

Альтернативные потоки:

А1: Гарантийный срок истёк.

1. Система выводит поля с всей необходимой информаций и видно, что гарантийный срок истёк.

2. Покупатель подтверждает сообщение.

3. Вариант использования завершается.

А2: Не подлежит модернизации.

1. Система выводит поля с всей необходимой информаций и видно, что с момента покупки прошло больше 3 месяцев.

2. Покупатель подтверждает сообщение.

3. Вариант использования завершается.

5. ER-диаграмма

ER-диаграмма представляет собой модель «сущность-связь». В данной БД выделяются 4 сущности: Имя МК, Проданные МК, Производитель, покупатель (табл.1). Вводя связи между сущностями, ER-диаграмму системы и ER-диаграммы, разработанной в MSAccess (рис. 2).

                                                                                                                    Таблица 1

Рис. 2. ERDiagram (MicrosoftAccess)

6. Диаграмма классов

На основе представленной ER-диаграммы и основных объектов системы формируется диаграмма классов (рис. 3). Вся необходимая информация хранится в объектах entity-класса, связанных между собой, атрибуты объектов – свойства, признаки сущностей. Boundary-классы обслуживают процессы взаимодействия.

Рис.3. Диаграмма классов

Класс Проданные МК

Данный класс является центральным по отношению ко всем остальным, обеспечивая связь остальных классов в системе. Произведено разделение внутренних полей и процедур: свойства хранятся в классе Проданные МК, методы содержатся в классе NewClass(формирование запросов), 3 управление записями.

Класс Покупатель

Cвойства хранятся в классе Покупатель, методы содержатся в классе NewClass6, управление записями, в 4  управление записями.