Разработка электронного органайзера

МИНИСТЕРСТВО ОБРАЗОВАНИЯ  И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПЕНЗЕНСКИЙ ГОСУДАРСТВЕННЫЙ  УНИВЕРСИТЕТ 

 

 

 

 

 

 

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА К КУРСОВОМУ ПРОЕКТУ

 

по дисциплине «Системное программное обеспечение»

 

на тему: «Разработка электронного органайзера»

 

 

 

 

 

 

 

 

Выполнил: студент группы 10ЗВОЗ1  

Долгушев А.В.

Проверил: Убиенных

 

 

 

 

 

 

 

 

 

 

 

Пенза 2012

 

Задание

 

Создать приложение «Органайзер», предназначенное для помощи в организации и планировании деловой жизни и объединяющее в себе функции записной книжки, календаря и микрокалькулятора. Приложение должно быть предназначено для работы в среде Windows XP. При разработке воспользоваться средой Microsoft Visual C++.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Содержание

 

 

 

Введение

 

 

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

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

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

 

1. Анализ требований

 

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

Обычно выделяют несколько  категорий требований:

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

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

 

1. 1. Функциональные  требования к программной системе.

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

Итак, электронный органайзер должен включать в себя функции:

1. записной книжки,
2. планировщика заданий (календаря),
3. калькулятора.

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

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

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

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

 

1. 2. Пользовательские требования к программной системе.

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

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

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

Рис. 1. Аналог разрабатываемого электронного органайзера.

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

 

1. 3. Требования к среде разработки

Итак, средой разработки выбрана система  Microsoft Visual Studio 2008, причем язык, на котором будет написана программа,  – C++ . Выбор обусловлен несколькими причинами.

Во-первых, Visual C++ поддерживает разработку приложений как на Managed C++ и C++/CLI, так и на обычном C++, и тем самым позволяет генерировать код как для платформы .NET Framework, так и для исполнения в среде «чистой» Windows, что и является основным требованием.

Во-вторых, Visual Studio 2008 предоставляет удобные средства проектирования визуальных компонентов приложения и некоторую генерацию кода.

 

2. Проектирование программной системы

 

В данном пункте опишем источники данных, приведем пример интерфейса приложения и определимся с технологией реализации программной системы. Также в этом разделе приведем описание возможных UML-диаграмм.

2.1 Проектирование данных

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

Что касается выбора СУБД, то здесь всё очевидно: остановимся  на довольно распространенной MS Access.

 Рис. 2. Схема данных в MS Access.

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

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

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

Кратко опишем приведенные  таблицы.

Таблица Users хранит имена пользователей (user) и их пароли (password). В нашей версии программной системы будет отсутствовать.

Sheduler – это записная книжка. В ней хранится идентификатор записи (id_task), текст записи (text_task), статус записи, т. е. «выполнено»/«невыполнено», он будет отображаться во второй версии системы (status_task) и внешний ключ (user).

Calendar – таблица планировщика заданий. В ней хранится идентификатор события (id_event), комментарий к нему (text_event), который в первой версии приложения будет отсутствовать, дата события (date_event), являющаяся обязательным атрибутом для всех событий,  и внешний ключ (user), обеспечивающий разграничение событий пользователей.

 

2.1 Проектирование интерфейса и реализации

Программу планируется  построить на основе прообраза MVC. Model-view-controller («Модель-представление-поведение») – схема использования нескольких шаблонов проектирования, с помощью которых модель данных приложения, пользовательский интерфейс и взаимодействие с пользователем разделены на три отдельных компонента. Подчеркнем, что это будет именно прообраз MVC, поскольку прослойка, отвечающая за поведение системы будет очень тесно связана с интерфейсом, т. е. за поведение будут отвечать обработчики событий, генерируемых пользователем.

В целом же приложение будет представлять один класс-форму. Поэтому нецелесообразно проектировать диаграмму классов. Что же касается прочих диаграмм, то можно ограничиться диаграммой состояний. Эту диаграмму приведем только для подсистемы «записная книжка». Календарь очень практически идентичен в состояниях и возможных переходах, поэтому нет смысла приводить ещё одну похожую диаграмму. Калькулятор же представляет собой тривиальную подпрограмму, он в принципе не нуждается в проектировании.  Диаграмма состояний приведена в Приложении Б.

Завершением данного  пункта будет проектирование интерфейса системы. На рис. 3. изображена первая версия интерфейса приложения.

Рис. 3. Интерфейс электронного органайзера.

 

3. Программная реализация и тестирование системы

 

В этом разделе опишем архитектуру приложения и технологию доступа к данным. Также приведем примеры кода программной системы и результаты тестирования.

 

3. 1. Кодирование

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

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

Создавая Windows-приложения, постоянно приходится сталкиваться с обработкой событий, связанных с элементами формы. Например, при щелчке на кнопке «Добавить» в модуле «Записная книжка» добавляется новая строка в dataGridView1 и соответствующая ячейка переходит в режим редактирования:

private: System::Void b_new_task_Click(System::Object^  sender, System::EventArgs^  e)

{

  dataGridView1->Rows->Add();

  dataGridView1->Rows[dataGridView1->RowCount - 1]->Cells[1]->Value="Введите задание";

  dataGridView1->Rows[dataGridView1->RowCount - 1]->Cells[1]->Selected=true;

  addFlag = 1;

  dataGridView1->BeginEdit(true);

}

Что касается Технологии доступа к данным, в программе используется технология OLE DB. Остановимся на ней подробнее.

OLE DB (Object Linking and Embedding Database) – набор интерфейсов, основанных на COM, которые позволяют приложениям обращаться к данным, хранимым в разных источниках информации или хранилищах данных с помощью унифицированного доступа.

OLE DB является API, разработанной Microsoft для доступа к различным типам данных, которые хранятся в единой форме. OLE DB отделяет хранилище данных от приложения, которое должно иметь доступ к нему через набор абстракций, которые включают DataSource, сессию, командную строку.

OLE DB использует различных провайдеров для разных источников данных. Для доступа к используемой нами MS Access (и других локальных баз данных) используется Jet OLE DB.

Провайдер Jet 4.0 OLE DB поддерживает работу с Access 97, Access 2000 (и выше). Механизм Jet удобно использовать для импорта и экспорта данных. Для экспорта необходимо  предать специальной функции строку соответствующего SQL-запроса. Ниже приведен код, добавляющий записи в таблицу Calendar или изменяющий их:

OleDbConnection^ conn = gcnew OleDbConnection("Provider=Microsoft.Jet.OLEDB.4.0;Data Source=dbOrganizer.mdb");

conn->Open();

String^ Query;

if (addFlag == 3)

{

Query = "INSERT INTO Calendar (date_event, name_event, text_event) VALUES ('";

Query += monthCalendar1->SelectionStart.Date.ToShortDateString() + "', '" + textBox_name->Text + "', '" + richTextBox1->Text->ToString() + "')";

}

else if (addFlag == 4)

{

Query = "UPDATE Calendar SET name_event = '" + textBox_name->Text + "', text_event = '" + richTextBox1->Text->ToString() + "' WHERE id_event = " + idEvent.ToString();

}

OleDbCommand^ Command = gcnew OleDbCommand(Query, conn);

Command->ExecuteNonQuery();

conn->Close();

deactivate();

addFlag = 0;

Аналогичным образом происходит извлечение данных из таблиц БД. Добавляется лишь один объект – DataReader, который предоставляет интерфейс для работы с извлеченными данными.

Код программы  представлен в Приложении В.

3. 2. Тестирование

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