Стадии разработки ПО.
ЭТАП АНАЛИЗА
На этапе анализа должны быть составлены следующие документы.
Текст задания
Прежде всего, нам необходимо получить само задание. Для этого мы встречаемся с заказчиком (в нашем случае это дипломный руководитель). Он нам дает текст задания. Скорее всего, этот текст будет неподготовленным выражением его мыслей, часто идущих в случайном порядке. Очень редко текст задания дается профессиональным постановщиком, поэтому нам придется достаточно много дополнительно уточнять.
Дальше будем работать с этим текстом.
Концептуальная модель
Из текста задания будем выбирать существительные и на их основе строим концептуальную модель.
Концептуальная модель – диаграмма классов, отображающая интересующие нас объекты реального мира, их атрибуты и взаимоотношения между собой. Эта модель описывает предметную область, в ней не отображаются объекты, возникающие при программировании: базы данных, системные ключи, программные модули и т.д. Модель обобщает наши знания в нужной области.
Правильно построенная модель, позволит нам в дальнейшем создать правильную структуру классов (структуру нашей программы-приложения). И напротив, неправильно составленная концептуальная модель увеличивает вероятность создания неправильно функционирующей программы, переделки, а то написание заново, которой отнимут у нас намного больше времени, чем мы потратим на составлении модели.
Пример.
Словарь терминов.
На основе концептуальной модели составляем словарь терминов – описываются наиболее важные термины нашей предметной области.
Пример.
ABITURIENT_TYPE - тип тестируемого – абитуриент (поступающий в ГрГУ). Имеет атрибут school - учебное заведение, которое он закончил.
ADMIN_KIND - может управлять учетными записями пользователей и новостями.
Category - категория вопроса. Имеет title (название), size (кол-во вопросов), rate (сложность) - по умолчанию 1.0.
EXPERT_KIND - имеет доступ к созданию и редактированию тестов.
GUEST_TYPE - всякий посторонний пользователь. Описывается work - место работы, job - занятие.
Question - конкретный вопрос, предлагаемый тестируемому. Имеет descption (см. QuestionDescrption), order (порядок расположения вариантов ответов) - важно, чтобы варианты ответов выводились в случайном порядке, answer(answers) -ответ(ответы), givenTime (когда был задан вопрос), answeredTime (когда был получен ответ). Необходимо знать, правильно ли ответили на вопрос: isRight()==true - ДА, иначе НЕТ.
QuestionDescrption - описание вопроса. Имеет questionString - текст вопроса в HTML виде, string - вектор вариантов ответов в HTML виде. Каждый вопрос принадлежит к какой-либо категории - атрибут category. Внутри имеет маску правильного ответа: isRight(int[l answers): boolean - определяет правильно ли ответили на вопрос.
STUDENT_KIND - имеет права на прохождение тестов и просмотр своих результатов.
STUDENT_TYPE - тип пользователя - студент ГрГУ. Описывается department - факультет, course - курс , group - группа .
TEACHER_KIND - имеет права на просмотр результатов тестирования других, доступ к отчетам.
TEACHER_TYPE - тип пользователя - преподаватель ГргУ. Имеет department -отдел или кафедра(факультет), job - занятие.
Test - тест, предлагаемый пользователю. Содержит descrption - описание теста(см. TestDescrption), вектор вопросов(см. Question), user - пользователь, которому он был выдан(см. User), startTime - время начала тестирования, finishTime -время окончания тестирования. Необходимо знать закончен ли тест - isActiveQ:boolean.
TestDescrption - описание теста. Имеет title - название теста, description -развернутое описание теста в HTML виде, size - кол-во задаваемых вопросов, catNum - сколько категорий вопросов сожержит тест, timeAnswer -максимальное время ответа на вопрос. Хранит вектор категорий.
TestResult - результат одного тестирования. Имеет result - общая оценка, results -массив оценок по категориям, test - ссылка на пройденный тест.
Topic - раздел. Все тесты делятся по разделам. Имеет title - название, description -развернутое HTML описание.
User - пользователь системы. Для входа в систему(идентификации) необходимы атрибуты login и password. Имеет атрибуты; firstName - имя, middleName -отчество, lastName - фамилия, kind - сочетание из STUDENT_KIND, TEACHER_KIND, EXPERT_KIND, ADMIN_KIND, type - один из STUDENT_TYPE, TEACHER_TYPE, GUEST_TYPE, ABITURIENT_TYPE, city - город проживания, address - домашний адрес, zip - почтовый индекс, contactPhone - телефон), email.
Диаграмма функций системы
Это диаграмма описывает актеров (действующих лиц) и действия которые они хотят совершать в рамках нашей программы. Для создания диаграммы будем выбирать из теста задания глаголы. Эта диаграмма позволит нам выявить роли пользователей для разграничения доступа. Самое главное, диаграмма позволяет увидеть все функции, которые должна выполнять наша система, и оценить объем работы.
Пример.
Требования к системе.
Здесь формализуются требования, которые обязательно должны быть соблюдены, при разработке нашего приложения.
Пример.
Основные функции.
Здесь описываются функции, выявленные в ходе анализа. Дается их развернутое описание. Если операция сложна, или ее время на выполнение больше чем 2-3 недели, то она разбивается на несколько более простых.
|
Название |
Актер |
Приоритет |
Описание |
|
Название операции |
Лицо, которое будет ее выполнять |
Срочность реализации данной функции |
Словесное описание действий, которое совершает пользователь, и результат, который он должен получить |
|
Log in |
Any user |
Высокий |
Пользователю выводиться два поля для ввода логина и пароля. После ввода пользователь нажимает кнопку Login. Если пароль или пользователь не опознан, то выводиться сообщение об ошибки и операция повторяется. После удачного входа пользователю выдается приветствие, сообщение для него (если оно есть) от администратора системы и список действий, которые ему доступны. |
|
Select test to pass |
Student |
Средний |
Пользователь выбирает пункт пройти тестирование. Ему выдается экран со списком разделов, описание каждого раздела и кол-во тестов в разделе. После выбора раздела ему выдается список тестов с информацией по каждому тесту: описание теста, кол-во вопросов в тесте, время ответа на вопрос, сколько раз был пройдет тест, в т.ч. за последнее время, средняя оценка. |
Пожелания
Здесь описываются требования, которые не обязательны к исполнению, однако если возможно, то желательно их реализовать.
Пример
СТАДИЯ ПРОЕКТИРОВАНИЯ
На этой стадии мы начинаем решать задание. Документы, могут составляться на этой стадии.
Список модулей.
Начинаем проектирование нашей системы сверху. Выделяем более-менее независимые модули, определяем задачи, которые они будут решать и определяем интерфейс взаимодействия между ними. Если задача большая и ее решает несколько человек, то есть смысл выделить модули так, что каждый модуль реализует только один человек.
Пример.
Удаленный компьютер пользователя.
Любой компьютер, подключенный к Internet или к локальной сети университета, с установленной поддержкой TCP/IP протокола и имеющий web-браузер не ниже 4-й версии, может использоваться для работы с системой. Для этого всего лишь необходимо зайти на web-страницу системы. Если web-браузер не поддерживает java-скрипты, то это не является критичным для полноценной работы с системой, могут быть недоступны лишь некоторые объекты дизайна.
WEB-СЕРВЕР.
Web-сервер реализует обмен данными с пользователем по протоколу HTTP, обеспечивает запуск процессов CGI-скрипта, которому передаются полученные данные для обработки и от которого получается HTML-код для последующей передачи на пользовательский компьютер. Может использоваться любой HTTP-сервер, отвечающий требованиям системы (например, Apache) для разных операционных систем. CGI-скрипт - основная программа данного уровня. CGI-скрипт служит для передачи данных между ядром системы и (через Web-сервер) пользователем, формирования HTML-страниц, предварительной обработки данных, предварительной проверки безопасности работы. Он имеет модульную структуру, состоит из главного модуля и модулей - обработчиков шаблонов. Модули подгружаются по мере необходимости для обработки конкретного шаблона. Это, кроме того, легко позволяет получить расширяемость. Добавление новой функции в систему вызовет добавление лишь соответствующих модулей в скрипт. Обмен данными с ядром осуществляется по протоколу TCP/IP, используя специально разработанный прикладной протокол.
Ядро системы.
Многопоточное Java-приложение. Исполняет роль сервера приложений и работает постоянно. Возложена функция обработки сообщений, пришедших от web-сервера, и выдача ответного сообщения. Происходит основная вычислительная работа, поэтому модули ядра могут располагаться на нескольких машинах.
Структура ядра:
1. PortAdapter - компонента, обеспечивающая связь с web-сервером. Инициализирует и запускает обработчики сообщений.
2. Kernel - центральное звено. Обеспечивает взаимодействие компонент ядра и обработчиков сообщений (MessageWorkers). Содержит хранилище обработчиков сообщений.
3. UserSessions - ведутся пользовательские сессии.
Сервер баз данных.
Сервер БД обеспечивает структурированное и защищенное хранение данных системы, позволяет вести работу с ними, используя язык SQL, получение различных данных, требующих вычисления, используя сохраненные процедуры и функции. Хранить и работать с данными таким образом представляется наиболее рациональным, т.к. сервер БД - специализированное приложение, обеспечивающее удобство и наиболее высокую производительность при работе с информацией. Используется SQL-сервер Sybase Adaptive Server Anywhere v.7.0.1, отвечающий требованиям системы и при этом не требующий больших ресурсов для своего функционирования. Кроме того, с данным сервером поставляются утилиты, облегчающие работу с сервером и базой данных. Взаимодействие ядра системы с сервером БД осуществляется путем использования Java-класса DataProvider, реализующего все основные функции для работы с базой. Работа класса осуществляется путем преобразования данных из внутренних структур для их хранения, генерации на их основе SQL-запроса, его выполнения и обратного преобразования полученной информации во внутренние структуры. Кроме того, класс обеспечивает кэширование наиболее часто используемых статических данных базы (вопросы и ответы к тестам).
Список выбранных программных, аппаратных средств и технологий, которые мы будем использовать для создания нашего ПО.
Для составления этого списка, мы проводим анализ существующих программных средств, технологий с учетом: полезности их применения в нашей задаче, профессионального уровня исполнителей (программистов), экономической целесообразности и т д. Часто в наших условиях список применяемых продуктов предопределен заранее – исходя из экономических возможностей заказчика. Очень важно при выборе технологий, попытаться использовать уже существующие примеры решения данной задачи, и выявить возможные проблемы, с которыми мы столкнемся, используя эти технологии.
Пример.
Исходя из того, что продукт разрабатывается под Интернет, выбран Apache web server как один из наиболее надежных, расширяемых модулями и широко поддерживаемый сторонними производителями ПО. Немаловажно, что он является бесплатным. В качестве языка для генерации html-страниц выбран perl, как один из наиболее простых и широко используемых.
Для создания ядра системы выбрана технология Java. Язык Java обладает встроенной многопоточностью, является объектно-ориентированным, обладает простым синтаксисом и широко поддерживается. Технология Java является бесплатной.
Выбор СУБД.
При разработке системы, возникла необходимость в таком SQL-сервере, который обеспечивал бы все основные функции для работы с базой данных (выполнение SQL, возможность создания процедур, функций, представлений (view), наличие нескольких пользователей с разграничением прав доступа), безопасность хранения и передачи данных, имел специальные программы для работы с базой и при этом имел небольшие системные требования. Этому вполне отвечает SQL-сервер Sybase Adaptive Server Anywhere 7.0.1, который сейчас и используется. Несмотря на свой небольшой объем, он обеспечивает достаточно высокую производительность.
В дальнейшем, планируется перевод БД под Oracle. Эта работа будет выполнена в рамках перевода баз данных кафедры ИВТ под единую и производительную СУБД.
Объектная модель
Представляет собой диаграммы классов. На них проектируются классы системы (с атрибутами и методами), и их взаимоотношения (ассоциации, агрегации, наследования). Базисом для построения объектной модели является концептуальная модель. Их отличием является то, что в объектной модели допустимо не соблюдать все законы предметной области, если в дальнейшем это приведет к усложнению программного кода. Однако важно помнить, что это уменьшает гибкость структуры, и при изменении требований заказчика может повлечь большие переделки в структуре проекта. Важным отличием является и то, что в объектной модели выявляется классы, не связанные с предметной областью: различные системные объекты, хранилища и т.д. Так же объекты из Концептуальной модели наращиваются дополнительными атрибутами и методами для улучшения их взаимодействия в рамках программной среды.
Диаграммы классов являются основным средством для проектирования и наиболее широко используются. Важно знать, что на основе этих диаграмм CASE-средства позволяют получать шаблоны программного кода: заголовки классов, описания методов и атрибутов.
Пример
Структура БД.
Структура БД разрабатывается в каком-либо CASE-средстве. Это позволит нам позднее автоматически сгенерировать базу, причем под все СУБД, которые поддерживает CASE-средство. Для проектирования БД полезно пользоваться объектной моделью, т.к. поля таблиц часто соответствуют атрибутам объектов на диаграммах классов.
Пример
Принципы работы, взаимодействия объектов.
Диаграммы классов описывают структуру объектов и их соотношения между собой. Для проектирования динамического их поведения используются диаграммы последовательности, деятельности, состояний. Каждая из этих диаграмм, хотя и применяется для описания поведения объектов, акцентирует внимание на определенных аспектах.
СТАДИЯ РЕАЛИЗАЦИИ