Разработка структуры вэб-представительства

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

Правильная структура базы данных подразумевает:

- распределение данных по тематическим таблицам в целях сокращения объема повторяющихся данных;

- добавление данных, необходимых для объединения сведений, которые содержатся в таблицах;

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

Процесс разработки

Процесс разработки базы данных включает следующие шаги.

- Определение цели создания базы данных

Это позволяет подготовиться к выполнению следующих шагов.

- Поиск и организация необходимых данных

Следует собирать все данные, которые необходимо сохранить в базе данных - Распределение данных по таблицам

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

- Преобразование элементов данных в столбцы

Требуется определить, какие данные требуется хранить в каждой таблице. Каждый элемент данных будет введен в отдельное поле и станет столбцом таблицы.

- Задание первичных ключей

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

- Создание связей между таблицами

Следует проанализировать все таблицы и определить, как данные одной таблицы связаны с данными других таблиц. Может быть необходимым добавить в таблицы поля или создать новые таблицы для создания необходимых связей.

- Усовершенствование структуры

Проверяется структура базы данных на наличие ошибок. Создаются таблицы и добавляется несколько записей с образцами данных. Анализ полученных результаты, внесение в структуру необходимых изменений.

- Применение правил нормализации

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

Ниже представлена структура базы данных для ГОУ СОШ №1194

2. Технологический раздел

2.1 Проектирование на языке UML

Разработка современного программного обеспечения начинается с проектирования. Проектирование призвано выразить структуру и поведение программы до её непосредственного кодирования, что позволяет избежать очень многих ошибок, точнее определить сроки разработки, распараллелить задачи между разработчиками.

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

С повсеместным распространением ООП проектировщики всё чаще стали обращаться к понятию «класс» как к универсальной единице структуры программы и как к актеру поведения. Одновременно несколько видных исследователей - Буч, Джекобсон, Румбах и другие - начали разрабатывать концепции языков, которые могли бы описать все аспекты работы программы, и были бы столь же эффективными, как языки программирования. Их работа вылилась в принятый консорциумом OMG стандарт Unified Modeling Language, который на сегодняшний день используется множеством разработчиков по всему миру и продолжает совершенствоваться.

2.1.1 Концепция Unified Modeling Language

UML представляет собой общецелевой язык визуального моделирования, разработанный для спецификации, визуализации, проектирования и документирования компонентов программного обеспечения. Основные принципы языка UML:

1) абстрагирование - в модель включаются только те аспекты проектируемой системы, которые имеют непосредственное отношение к выполнению системой описываемых функций;

2) многомодельность - достаточно полная модель сложной системы представляет собой некоторое число взаимосвязанных представлений (views), каждое из которых отражает некоторый аспект поведения или структуры системы;

3) иерархическое построение - модель строится на разных уровнях абстракции в зависимости от необходимости раскрытия деталей на данном этапе проектирования.

UML предназначен для описания двух основных видов моделей: статических (модели, описывающие структуру) и динамических (модели, описывающие поведение). Нотация UML, как языка визуального проектирования, включает в себя большое количество компонентов графической нотации. Основными понятиями UML являются «класс», «атрибут», «операция» и «отношение». Основное представление понятий - диаграмма.

2.1.2 Виды диаграмм UML

Диаграммы UML, как и было сказано выше, являются основным способом представления моделей. Последовательность рассмотрения диаграмм в данном подразделе обусловлена рекомендациями Rational Unified Process и наглядно показывает последовательность моделирования системы.

Диаграмма прецедентов (use case diagram)

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

Каждый прецедент характеризует некую предполагаемую последовательность действий. Актер представляет некую внешнюю по отношению к модели сущность. Существует несколько стандартных видов отношений между актерами и прецедентами:

1) ассоциация - указание на семантическую связь актера и прецедента (например, актер инициирует прецедент);

2) включение - указание на то, что заданное поведение одного прецедента включается как составная часть в поведение другого;

3) расширение - указание на то, что заданное поведение прецедента может использоваться другим в случае выполнения неких условий;

4) обобщение - указание на то, что прецедент или актер является специальным случаем другого прецедента или актера соответственно.

Диаграмма классов (class diagram)

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

Класс в UML является абстрактным описанием свойств множества объектов, обладающих одинаковой структурой, поведением и отношениями с объектами других классов. Класс обладает набором атрибутов или свойств, а также набором операций или методов. Выделяется понятие шаблонного класса, аналогичное одноименному из языка С++.

Между классами могут быть следующие отношения:

1) ассоциация - произвольная семантическая связь классов, может иметь кратность (аналогично ER-диаграммам);

2) обобщение - отношение между предком и потомком, интерпретация наследования;

3) агрегация - включение одной сущностью других как составных частей, взаимосвязь между частью и целым;

4) композиция - более сильный вариант агрегации, при котором часть не может существовать отдельно от целого;

5) зависимость - семантическая связь, не являющаяся какой-либо из вышеперечисленных.

Интерфейс в UML - это специальный случай класса, когда специфицируется только его поведение.

Диаграмма кооперации (collaboration diagram)

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

Кооперация - множество взаимодействующих с определенной целью объектов в общем контексте моделируемой системы. Различают два уровня представления кооперации: на уровне спецификации (показывает роли спецификаторов и роли ассоциаций во взаимодействии) и на уровне экземпляров (объекты и связи, образующие отдельные роли).

Диаграмма последовательности (sequence diagram)

Диаграммы последовательности родственны диаграммам кооперации - они преобразуются друг в друга без потери информации. Диаграмма последовательности показывает взаимодействие в срезе времени.

Диаграмма состояний (statechart diagram)

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

Диаграмма состояний по существу является графом, представляющим некий конечный автомат.

Диаграмма деятельности (activity diagram)

Диаграмма деятельности является самым низкоуровневым видом диаграмм UML. Её семантика сродни многократно стандартизованным правилам записи блок-схем алгоритмов.

Диаграмма компонентов (component diagram)

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

Диаграмма развертывания (deployment diagram)

Данный вид диаграмм показывает, как будет развернута система на физическом уровне. Узлами этих диаграмм являются физические объекты, такие как компьютер, сеть, принтер, камера, датчик. Допустимо частично совмещать информацию из диаграмм компонентов и развертывания, чтобы отобразить, какой компонент и где будет физически развернут. Данные диаграммы предполагают широкое использование собственных символов.

2.1.3 Связь с объектно-ориентированными языками

Некоторые виды диаграмм UML, например диаграммы классов, очень хорошо поддаются обработке генераторами кода. Соответствующие инструментальные средства встроены в большинство мощных CASE-средств, таких как, например, Rational Rose. По данным диаграммы классов такое инструментальное средство способно создать набор файлов со сгенерированными определениями классов, включая их свойства и методы согласно спецификациям диаграммы.

2.2 Архитектура Microsoft.NET Framework 2.0

NET Framework включает в себя среду времени выполнения программ, называемую общеязыковой средой выполнения (common language runtime), которая управляет исполнением кода и обеспечивает сервисами, которые упрощают процесс разработки. Компиляторы и утилиты расширяют функциональность среды выполнения, и позволяют вам писать код, который будет пользоваться всеми преимуществами среды. Код, который создан компилятором языка, для среды выполнения, называется управляемым кодом, он получает такие возможности, как межъязыковая интеграция, межъязыковая обработка исключений, расширенные возможности по безопасности, поддержки версионности и развертывания, упрощенная модель взаимодействия компонент, сервисы для отладки и профилирования.

Чтобы среда выполнения могла обеспечить сервисы для управляемого кода, компиляторы языка должны создавать метаданные, которые описывают типы, классы и связи, используемые в вашем коде. Метаданные хранятся вместе с кодом, каждый загружаемый в среду выполнения образ содержит метаданные. Среда выполнения использует метаданные, чтобы находить и загружать классы, размещать экземпляры в памяти, разрешать вызовы методов, создавать машинный код, контролировать выполнение ограничений по безопасности и области видимости.

Среда выполнения автоматически размещает объекты и управляет ссылками на объекты, освобождая их, когда они больше не используются. Объекты, чей жизненный цикл управляется таким образом, называются управляемыми данными. Автоматическое управление памятью позволяет избежать утечек памяти, а также избежать других общих ошибок программирования. Если ваш код управляемый, то вы можете использовать управляемые данные, неуправляемые данные или и те и другие одновременно в вашем приложении. Поскольку компиляторы языков поддерживают собственные типы (примитивные типы), вы можете не всегда знать точно, являются ли ваши данные управляемыми.

CLR позволяет более легко разрабатывать компоненты и приложения, взаимодействующие объекты которых написаны на разных языках. Объекты, написанные на разных языках, могут легко взаимодействовать друг с другом и их поведение тесно интегрировано. Например, вы можете определить класс, и затем использовать другой язык программирования, чтобы наследовать от него другой класс, или вызвать метод оригинального класса. Вы также можете передать экземпляр класса в качестве аргумента метода в класс, написанный на другом языке. Такая межъязыковая интеграция возможна, поскольку компиляторы языков и утилиты используют общую систему типов, поддерживаемую средой выполнения, и они следуют правилам среды выполнения для определения новых типов, а также для создания, использования, хранения и связывания типов.

Как часть своих метаданных, все управляемые компоненты хранят информацию о компонентах и ресурсах, которые они использовали при создании. Среда выполнения использует эту информацию, чтобы быть уверенной, что ваша компонента или приложения, получит необходимые версии того, что вам необходимо, что уменьшает вероятность некорректной работы вашего кода из-за несоответствующей версии используемых модулей. Регистрационные данные и состояние больше не хранятся в реестре, где их трудно поддерживать и содержать. Вместо этого, информация о типах, которые вы определили (и их зависимостях), хранится вместе с кодом, как метаданные, делая репликацию компонент и их удаление менее сложной процедурой.

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

- более высокая производительность.

- возможность легко использовать компоненты, разработанные на разных языках.

- расширяемые типы, поддерживаемые библиотекой классов.

- широкое множество языковых возможностей.

- межъязыковая интеграция, особенно межъязыковое наследование.

- автоматическое управление памятью, когда нет необходимости в подсчете ссылок на объект.

- самоописывающиеся объекты, которые делают ненужным использование Interface Definition Language (IDL).

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

2.3 Архитектура ASP.NET 2.0

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

1) Взаимодействие с IIS

Следует отметить, что веб-серверы IIS 5 и IIS 6 по-разному взаимодействуют с ASP.NET 2.0, поскольку для этих двух версий IIS используются разные модели обработки запросов.

При использовании IIS 5, среда выполнения ASP.NET представлена отдельным процессом aspnet_wp.exe. Этот процесс получает управление от IIS с помощью ASP.NET ISAPI расширения aspnet_isapi.dll. Если расширение запрошенного ресурса связано с ASP.NET ISAPI расширением, то запрос поступает на обработку рабочим процессом ASP.NET, который, в свою очередь, отвечает за загрузку CLR, создание управляемых объектов и выстраивания очереди событий для ASP.NET страницы. В этом случае особенно важно отметить, что рабочий процесс aspnet_wp.exe обслуживает все веб-приложения: каждое приложение выполняется в отдельном домене приложения AppDomain в рамках одного рабочего процесса. Рабочий процесс выполняется под специальной учетной записью ASPNET.

Процесс обработки запроса при использовании IIS 5 может быть разбит на следующие шаги:

1. IIS получает запрос, определяет тип ресурса и, если данный тип связан с ASP.NET, передает его на обработку расширению aspnet_isapi.dll. ISAPI расширение передает запрос на дальнейшую обработку рабочему процессу ASP.NET.

2. После получения запроса, рабочий процесс передает сообщение ISAPI расширению, сообщая о том, что запрос будет обработан.

3. Запрос выполняется в контексте рабочего процесса ASP.NET.

4. После окончания выполнения, рабочий процесс передает данные ISAPI расширению, которое отвечает за освобождение ресурсов, занятых рабочим процессом.

В случае использования IIS 6 модель обработки запросов несколько меняется, поскольку IIS 6 используем модель пула приложений - отдельного рабочего процесса, который обслуживает одно или несколько веб-приложений. Каждый пул приложений обслуживается отдельным экземпляром рабочего процесса w3wp.exe.

IIS 6 использует для получения и обработки запросов драйвер, работающий на уровне ядра операционной системы http.sys, все запросы проходят через этот драйвер, который отвечает за сопоставление запроса соответствующему пулу приложений. Рабочий процесс, обслуживающий пул приложений, загружает необходимые ISAPI расширения. В случае ASP.NET это расширение aspnet_isapi.dll, которое в свою очередь загружает CLR и начинает обработку HTTP запроса. Рабочие процессы выполняются под учетной записью NetworkService.

2) Структура ASP.NET страницы

Структура страницы ASP.NET 2.0 не отличается от структуры страниц ASP.NET 1.х. Страница по-прежнему разделена на две основные части: директивы и представление. Код программной логики страницы может быть вынесен в отдельный файл (выделенный код, Code Behind), либо включен в представление страницы в качестве блока <script> с установленным атрибутом runat=» server» (встроенный код, inline code)).

Разделение кода программной логики и представления

Рассмотрим оба этих способа размещения кода и различия между подходом к разделению кода в ASP.NET 1.х и 2.0. В ASP.NET 1.x при использовании модели встроенного кода класс страницы ASP.NET наследовал классу System. Web.UI. Page и при выполнении приложения компилировался во временную сборку.

При использовании модели разделения кода и представления в ASP.NET 1.x схема наследования становится более сложной, поскольку классу System. Web.UI. Page наследует класс, определенный в файле программной логики (Code Behind), которому, в свою очередь, наследует класс страницы ASP.NET. При этом класс, определенный в файле программной логики компилируется в единую сборку приложения, находящуюся в директории bin, а класс страницы компилируется во временную сборку.

В ASP.NET 2.0, в связи с появлением возможность разделения классов, общая схема становится несколько иной. Для ASP.NET страницы создается частичный класс страницы (partial class), который объединяется частичным классом, объявленным в файле программной логики, который затем компилируется как единой целое, поэтому в файле с исходным кодом нет декларации элементов управления и создания экземпляров этих элементов. Код, создающий элементы управления, генерируется во время компиляции на основании файла с кодом разметки страницы.

Частичные классы (partial class)

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

Если быть откровенным, то дело обстоит не совсем так, как показано на Рис. 4. Помимо класса, «собранного» из двух частей - частичного класса в файле исходного кода и частичного класса, сгенерированного средой выполнения, существует класс страницы, точно также как и в ASP.NET 1.x наследующий классу, определенному в файле исходного текста.

3) Модель компиляции

В ASP.NET 2.0 по сравнению с ASP.NET 1.x появились новые дополнительные стратегии, связанные с новой моделью компиляции приложений: для каждой ASP.NET страницы создается своя собственная сборка. Эта модель компиляции открывает возможность не перекомпилировать все приложение при изменении одного файла исходного кода, а осуществлять компиляцию только измененных файлов. Поэтому ASP.NET 2.0 предлагает три основных стратегии компиляции приложений:

1. Перекомпиляция файлов программной логики. В этом случае создаются сборки в директории bin, которые во время выполнения объединяются с динамическими сборками, генерируемыми для страниц с использованием механизма разделения классов.

2. Полная прекомпиляция. Абсолютно новая возможность, появившаяся в ASP.NET 2.0 и позволяющая создать одну сборку для всех файлов приложения, включая файлы ASPX, содержащие HTML разметку. Сборка помещается в директорию bin веб-приложения, а содержимое всех ASPX файлов замещается на стоку «This is a marker file generated by the precompilation tool, and should not be deleted!».

3. Динамическая компиляция. Эта стратегия аналогична используемой в ASP.NET стратегии динамической компиляции по запросы, с одним исключением, что страницы компилируются не одновременно, а по мере поступления запросов к каждой конкретной странице.

2.4 ORM-системы. Философия NHibernate

Инкапсуляция. Наследование. Полиморфизм.

Три столпа ООП. И это отнюдь не просто громкие слова. Если что-то пишется объектно-ориентированно, оно должно быть объектно-ориентированно настолько, насколько это возможно.

Однако классическая модель ADO предлагает отнюдь не самый красивый подход. Для получения или изменения данных в базе нам предлагается использовать всё тот же SQL, который можно использовать:

а) в виде встраиваемого кода - худший вариант.

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

Как хорошо заметно, самыми часто выполняемыми запросами к базе являются стандартные, без изысков, запросы на выбор (возможно, с объединением 2-4 таблиц) и запросы на изменение конкретной строки где-то в таблице.

В равной степени можно сочувствовать как тому, кто написал это в своём коде (остаётся надеяться, что всё же есть класс с вынесенной в него бизнес-логикой), так и тому, кто создал множество хранимых процедур для этих действий.

Не говоря уже о том, что если в базе, например ~500 таблиц, имеющих сложные связи.

ORM позволяет в той или иной мере элегантно и не выходя за рамки ОО подхода решить эти проблемы. В случае NHibernate у нас будет много подготовительной ручной работы, но в итоге всё это окупится.

Для каждой интересующей нас таблицы в базе создаётся два файла в проекте: один файл - это файл на C#, содержащий класс, описывающий таблицу, а второй - xml-документ, так называемый маппинг, описывающий, как поля таблицы будут записываться в свойства класса. Пример из проекта:

таблица TEACHER (T-SQL):

CREATE TABLE TEACHER

(

ID int IDENTITY (1,1) NOT NULL,

NAME nvarchar(100) NOT NULL,

IMAGE_ID int NULL,

DESCRIPTION nvarchar(500) NULL,

CONSTRAINT [PK_TEACHER] PRIMARY KEY CLUSTERED

(

[ID] ASC

)

)

ALTER TABLE TEACHER ADD CONSTRAINT FK_TEACHER_IMAGE

FOREIGN KEY (IMAGE_ID) REFERENCES [IMAGE] (ID)

класс-сущность (Entity) Teacher, файл Teacher.cs

using System;

using System. Collections. Generic;

using System. Text;

namespace Core. Model

{

public class Teacher: Entity

{

#region Fields

private string name;

private Image image;

private string description;

#endregion

#region Properties

public virtual string Name

{

get {return name;}

set {name = value;}

}

public virtual Image Image

{

get {return image;}

set {image = value;}

}

public virtual string Description

{

get {return description;}

set {description = value;}

}

#endregion

#region Constants

public const string NamePropertyName = «Name»;

#endregion

}

}

Маппинг класса (Teacher.hbm.xml)

<hibernate-mapping xmlns= «urn:nhibernate-mapping-2.2» assembly= «Core»

namespace= «Core. Model»>

<class name= «Teacher» table=» [TEACHER]» lazy= «true» >

<id name= «Id» column=» [id]">

<generator class= «native» />

</id>

<property name= «Name» type= «string» length= «100» column= «NAME» not-null= «true»/>

<many-to-one name= «Image» class= «Image» column= «IMAGE_ID» not-null= «false» />

<property name= «Description» type= «string» column= «DESCRIPTION» not-null= «false»/>

</class>

</hibernate-mapping>

Как хорошо видно, самой замечательной особенностью NHibernate является то, что ID связанных таблиц не являются просто целочисленными (или GUID) свойствами - они являются ссылками на объект соответствующего класса и чтобы достать фотографию учителя, достаточно в коде просто воспользоваться свойством theTeacher. Image. Всю работу проделает NHibernate и вам не понадобится ни строки кода.

2.5 Паттерны проектирования

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

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

2.5.1 Паттерн MVP

2.5.2 Паттерн «Абстрактная фабрика»

2.5.3 Паттерн Singleton

2.6 Отладка и тестирование

В целом различаются дефекты программного обеспечения и сбои. В случае сбоя программа ведёт себя не так, как ожидает пользователь. Дефект - это ошибка / неточность, которая может быть (а может и не быть) следствием сбоя.

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

Уровни тестирования

* Модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция

* Интеграционное тестирование - проверяет, есть ли какие-либо проблемы в интерфейсах и взаимодействии между интегрируемыми компонентами - например, не передается информация, передаётся некорректная информация.

* Системное тестирование - тестируется интегрированная система на её соответствие исходным требованиям

* Альфа-тестирование - имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями / заказчиком на стороне разработчика. Часто альфа-тестирование применяется для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

* Бета-тестирование - в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.

Тестирование «белого ящика» и «чёрного ящика»

В терминологии профессионалов тестирования (программного и некоторого аппаратного обеспечения), фразы «тестирование белого ящика» и «тестирование черного ящика» относятся к тому, имеет ли разработчик тестов доступ к исходному коду тестируемого ПО, или же тестирование выполняется через пользовательский интерфейс либо прикладной программный интерфейс, предоставленный тестируемым модулем.

При тестировании белого ящика (англ. white-box testing, также говорят - прозрачного ящика), разработчик теста имеет доступ к исходному коду и может писать код, который связан с библиотеками тестируемого ПО. Это типично для юнит-тестирования (англ. unit testing), при котором тестируются только отдельные части системы. Оно обеспечивает то, что компоненты конструкции - работоспособны и устойчивы, до определенной степени.

При тестировании чёрного ящика (англ. black-box testing), тестировщик имеет доступ к ПО только через те же интерфейсы, что и заказчик или пользователь, либо через внешние интерфейсы, позволяющие другому компьютеру либо другому процессу подключиться к системе для тестирования. Например, тестирующий модуль может виртуально нажимать клавиши или кнопки мыши в тестируемой программе с помощью механизма взаимодействия процессов, с уверенностью в том, все ли идет правильно, что эти события вызывают тот же отклик, что и реальные нажатия клавиш и кнопок мыши. Как правило, тестирование чёрного ящика ведётся с использованием спецификаций или иных документов, описывающих требования к системе.

Если «альфа-» и «бета-тестирование» относятся к стадиям до выпуска продукта (а также, неявно, к объёму тестирующего сообщества и ограничениям на методы тестирования), тестирование «белого ящика» и «черного ящика» имеет отношение к способам, которыми тестировщик достигает цели.

Бета-тестирование в целом ограничено техникой чёрного ящика (хотя постоянная часть тестировщиков обычно продолжает тестирование белого ящика параллельно бета-тестированию). Таким образом, термин «бета-тестирование» может указывать на состояние программы (ближе к выпуску чем «альфа»), или может указывать на некоторую группу тестировщиков и процесс, выполняемый этой группой. Итак, тестировщик может продолжать работу по тестированию белого ящика, хотя ПО уже «в бете» (стадия), но в этом случае он не является частью «бета-тестирования» (группы / процесса).

Статическое и динамическое тестирование

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

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

Регрессионное тестирование

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

Покрытие кода

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

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

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

При отладке и тестировании веб-представительства и административной подсистемы были использованы методы динамического тестирования: метод «белого ящика», регрессионное тестирование, альфа-тестирование, системное тестирование.

3. Организационный раздел

3.1 Размещение ресурсов сайта

Для того чтобы пользователи могли иметь постоянный доступ к сайту, требуется разместить его на круглосуточно доступном хосте. Предполагаемая загрузка сайта невелика, поэтому производительность сервера не имеет решающего значения.

Требования к серверу:

• поддержка Windows-хостинга на платформе IIS;

• поддержка ASP.NET 2.0;

• поддержка MS Ajax Extensions;

• поддержка MS SQL Server 2005;

• возможность простого управления сайтом;

• объём жесткого диска под сайт и ресурсы на хосте ~100 мб;

• стоимость услуг, согласованная с заказчиком.

Также для доступа к ресурсам SQL-сервера необходима возможность прямого удалённого соединения с базой данных.

Всем этим требованиям удовлетворяет хостинг от русской компании Inform-telecom, на котором в настоящий момент размещён и функционирует сайт.

3.2 Работа с административной подсистемой

Для управления содержимым базы данных используется административная подсистема. Её интерфейс достаточно прост в использовании, несмотря на сложное внутреннее устройство, поэтому специальной инструкции не требуется, приведу только основные принципы.

После запуска административной подсистемы у пользователя есть выбор действия - настройка параметров соединения и редактирование собственно данных.

1) Настройка параметров соединения

В этом диалоге пользователю предлагается ввести информацию, на основе которой будет создана строка соединения с базой данных. Впоследствии эта информация будет сохранена в персонализованном хранилище (другие Windows-пользователи не получат доступа к ней). Сразу же можно проверить работоспособность подключения, нажав на кнопку «Тест». Будет реализована попытка создать тестовое подключение ADODB, о результатах которой будет выведено соответствующее окно:

2) Редактирование данных базы.

Для этих целей предусмотрен единообразный интерфейс, основанный на взимозаменяемых компонентах. Сравните изображения на двух рисунках:

Видно, что поменялось только количество и названия столбцов в списке и элемент управления, позволяющий вводить данные.

Назначения кнопок внизу зависит от того, выделен ли элемент.

- Удалить выбранное - удаляет выбранную запись из базы. Умышленно не поддерживается каскадное удаление, то есть задействованная запись удалена не будет, но будет выведено предупреждающее сообщение;

- Сохранить (если не выбран элемент списка) - охраняет новый элемент со введёнными значениями полей. Если некоторые обязательные значения не введены или некорректны, выводится соответствующее сообщение;

- Изменить (если выбран элемент списка) - вместо сохранения новой записи введённые значения считаются данными для модифицирования старой, выделенной;

- Добавить новое (если выбран элемент списка) - снимет выделение и очищает поля ввода.

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

Заключение

Под руководством моего дипломного руководителя мной была проделана большая подготовительная работа и работа собственно над созданием веб-представительства. Были достигнуты следующие цели:

· исследована предметная область;

· приняты решения, позволяющие создание и легко расширяемой и изменяемой структуры веб-представительства;

· разработаны схемы данных;

· разработаны алгоритмы работы;

· выполнена программная реализация веб-интерфейса;

· выполнена программная реализация административной подсистемы, позволяющей осуществлять управление ресурсами веб-представительства;

· выполнена отладка и тестирование;

· веб-представительство запущено в работу.

Список литературы

1. Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. Приёмы объектно-ориентированного проектирования. Паттерны проектирования.

2. Эндрю Троелсен. Язык программирования С# 2005 и платформа.NET 2.0

3. Т. Нортроп, Ш. Уилдермьюс, Б. Райан Основы разработки приложений на платформе Microsoft.NET Framework.

4. Рейли Д. Создание приложений Microsoft ASP.NET

Страницы: 1, 2