- C# - новый объектно-ориентированный язык, предназначенный для применения с .NET.
Заметим, что Visual Studio 2005 использует .NET Framework 2.0. Эта среда также имеет некоторые преимущества по сравнению с предыдущими версиями .NET Framework, а именно:
- Интеграция с SQL Server. Для нас важно прежде всего то, что Visual Studio 2005, .NET Framework 2.0 и SQL Server 2005 тесно связаны между собой в том смысле, что реализованы в сочетании.
- Поддержка 64-разрядных вычислений. Сегодня больше и больше предприятий переходят на современные 64-разрядный процессоры. А среда Visual Studio 2005 может компилировать код так, чтобы он работал на любых процессорах.
В заключение можно сказать, что выбор средств разработки является важной задачей при создании программного продукта, а выбранные нами средства позволили создать современное приложение при минимуме усилий, что подтверждает правильность выбора.
После выбора средств разработки появилась необходимость выбора основных методов и способов разработки базы данных. Надо сказать, что СУБД Microsoft SQL Server 2005 даёт нам два основных способа разработки - написание сценариев на языке T-SQL и визуальные средства разработки. В нашей работе использовалось оба метода, и это позволило в достаточно сжатые сроки создать корректную и целостную базу данных.
Преимуществом написания сценариев является меньшая вероятность ошибки при разработке, так как создание таблиц, атрибутов, ограничений прописывается явно, обдумывается каждая строка сценария. Кроме того, при написании сценариев существует возможность отладки созданных объектов базы данных, например, хранимых процедур. Недостатком же сценариев являются большие затраты времени и сил, уходящих на написание кода.
В среду SQL Server 2005 включены также и визуальные средства разработки базы данных. Они, как ясно из названия, предполагаю создание базы данных без написания сценариев, а при помощи нужных панелей инструментов. Теоретически всю работу по созданию базы данных можно выполнить, вообще не прикасаясь к клавиатуре! Но такой способ разработки чреват большим количеством ошибок, так как легко выбрать не тот пункт выпадающего списка или совершить подобныю ошибку. Кроме того, создавать сложные запросы, представления, триггеры при помощи визуальных средств очень трудно и также чревато большим количеством ошибок.
Поэтому при разработке базы данных применялся другой путь - основная работа была проделана с помощью сценариев, а потом созданная физическая модель базы данных была доработана и отредактирована визуальными средствами. Необходимо отметить, что такой способ является оптимальным для начинающих разработчиков, так как он позволяет избежать ошибок, но в то же время сэкономить время и изучить визуальные средства разработки.
Согласно RUP (Rational Unified Process) жизненный цикл информационной системы делится на следующие стадии:
- Постановка задачи;
- Анализ;
- Проектирование;
- Реализация (кодирование);
- Отладка;
- Тестирование;
- Внедрение;
- Эксплуатация.
Естественно, в ходе разработки нашей системы было сложно полностью провести все этапы жизненного цикла, но большинство стадий все-таки было проведено. Далее рассмотрим все пройденные в процессе разработки этапы.
На этапе постановки задачи, как ясно из названия, происходит постановка задачи, определяются функциональные и нефункциональные требования, пишется техническое задание на разработку системы. Эта стадия была подробно рассмотрена в курсовом проекте по дисциплине «Информационные технологии».
На стадии анализа происходит изучение и анализ предметной области, построение контекстной диаграммы и DFD нижних уровней. Разрабатываются прецеденты, диаграммы прецедентов, последовательностей, взаимодействия и другие. Стадия анализа описана в курсовых проектах по дисциплинам «Информационные технологии» и «Теория информации».
На стадии проектирования происходит разработка проекта системы, строятся модели базы данных (концептуальная и логическая), а также разрабатывается общая архитектура системы. Стадия проектирования подробно описана в курсовых проектах по дисциплинам «Управление данными» и «Теория информации».
Стадия реализации или кодирования характеризуется непосредственным созданием компонентов системы. В нашем случае стадия реализации заключалась в создании базы данных, хранимых процедур и триггеров, а также в создании клиентского приложения для управления данными. Эта стадия была самой трудоёмкой и долгой, так как необходимо было изучить различные технологии для реализации (язык запросов SQL, технологию доступа к данным ADO.NET, язык C#).
На стадии отладки происходит первоначальный поиск ошибок и их исправление. Эта стадия тесно связана со стадией тестирования. В нашем случае тестирования не проводилось, поэтому стадия отладки приобрела особую важность, она выявила некоторые ошибки, допущенные на этапе реализации, и позволила их исправить.
Необходимо отметить, что модель разработки данной системы напоминает итерационную модель. Она характеризуется тем, что в ней присутствуют ярко выраженные связи между этапами. То есть на любой из стадий возможно уточнение и дополнение предыдущей стадии. Это позволяет существенно снизить трудоёмкость отладки и реализации. В нашем случае это выразилось в уточнении описания предметной области на стадии реализации системы, дополнение стадии анализа прецедентами и диаграммами при проектировании и кодировании, а также исправление ошибок реализации на этапе отладки. Создание корректно работающей системы, удовлетворяющей всем требованиям, позволяет сказать, что выбранная модель разработки в нашем случае является оптимальной.
Поддержание целостности базы данных является очень важной задачей, так как это является одним из условий нормального функционирования разрабатываемой системы. База данных находится в состоянии целостности (согласованном состоянии), если выполнены все ограничения целостности, определённые для БД.
Все меры по поддержке целостности базы данных можно разделить на 2 большие группы:
1. Декларативная целостность (ограничения);
2. Процедурная целостность (триггеры, правила и т.д.).
Ограничения (CONSTRAINTS) представляют собой некоторые условия, налагаемые на столбцы, таблицы и гарантирующие, что ваша информация будет подчиняться определённым правилам целостности данных. Надо отметить, что имеется 2 типа реакции на попытку нарушения целостности - отказ и выполнение «компенсирующих» действий. Для данного проекта были использованы ограничения отказа, то есть запрещения выполнения некорректных действий. Существует несколько классификаций для ограничений целостности, но для нас наиболее удобно классифицировать их по области действия.
Согласно вышеуказанной классификации все ограничения целостности базы данных можно разделить на 4 группы:
1. Ограничения атрибута;
2. Ограничения домена;
3. Ограничения кортежа;
4. Ограничения отношения.
Далее рассмотрим все типы ограничений целостности, применяемых в данном курсовом проекте (ограничения атрибута и отношения).
Ограничения атрибута имеют большое значение при организации бизнес-логики системы. Одним из видов ограничения атрибутов является ограничение уникальности (UNIQUE constraints). Еще одно название данного вида ограничения - альтернативный ключ (alternate key). В данном проекте этот вид ограничений широко использовался для поддержки целостности БД. Например, при анализе предметной области было выявлено, что название ЛПУ должно быть уникально. Поэтому при создании таблицы LPU был написан следующий сценарий.
CREATE TABLE LPU
(IDLPU INT IDENTITY PRIMARY KEY,
NameLPU varchar(50) UNIQUE,
MestoLPU varchar(30))
Создав данное отношение, мы установили, что название ЛПУ должно быть уникально. Таким образом, при попытке нарушить это ограничение пользователь получит сообщение об ошибке.
Ограничение UNIQUE было установлено в отношениях LPU, Vrach, Pacient, Type, Diagnos и других для обозначения потенциальных ключей отношений.
Еще одним видом ограничения атрибутов является недопустимость NULL-значений. Это означает, что данный атрибут не может иметь значение NULL (неопределённость). Это ограничение автоматически устанавливается для первичных ключей (Primary key) отношения, так как при значении первичного ключа NULL он перестаёт однозначно идентифицировать кортеж отношения. Можно также установить ограничение недопустимости NULL-значений на любой из других атрибутов. В данном курсовом проекте этот вид ограничения использовался очень широко, например:
CREATE TABLE Type
(IDType INT IDENTITY PRIMARY KEY,
NameType varchar(40) UNIQUE NOT NULL,
TarifType MONEY)
При создании таблицы Type (специальность врача) мы установили, что название специальности не может быть NULL, так как в противном случае теряется весь смысл данного отношения (название специальности является атрибутом, который несёт в себе наибольшую информативность для пользователя).
Установка ограничения NOT NULL была проведена во всех первичных и потенциальных ключах всех отношений, во всех внешних ключах, а также полях, которые несут наибольшую информативность в отношении.
Также при разработке базы данных было использовано ограничение проверки атрибута (CHECK). Надо заметить, что этот тип ограничения относится к ограничениям уровня отношения. Положительная особенность данного вида ограничений состоит в том, что их применение не ограничивается отдельными столбцами. В принципе можно проверить на соответствие определённому критерию любую комбинацию полей данной записи. В данном курсовом проекте ограничение значения использовалось в основном для атрибутов типа DateTime, чтобы исключить возможность ввода будущих дат. Для этого потребовалось написать следующий сценарий.