Разработка системы "WWW-конференция"

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

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 26.05.2015
Размер файла 2,1 M

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

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

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«НИЖЕГОРОДСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

ИМ. Н.И. ЛОБАЧЕВСКОГО»

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

ИНСТИТУТ ЭКОНОМИКИ И ПРЕДПРИНИМАТЕЛЬСТВА

Курсовая работа по дисциплине

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

На тему «Разработка системы WWW-конференция»

Работу выполнил студент

Группы 124-ИЭ

А.А. Никитина

Проверил: к.э.н., доцент

Камскова И.Д.

Н.Новгород, 2014 г.

ВВЕДЕНИЕ

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

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

ГЛАВА 1 АНАЛИЗ ТЕХНОЛОГИЙ ПРОЕКТИРОВАНИЯ ПО

1.1Постановка задачи

Требуется разработать модель программного обеспечения WWW-конференции.

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

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

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

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

Цели создания системы:

предоставление клиентам более детальной информации о товарах и услугах интернет-магазина;

обмен информацией и опытом между участниками форума.

1.2 Технология RAD

Rapid Application Development (RAD) - это жизненный цикл процесса проектирования, созданный для достижения более высоких скорости разработки и качества ПО, чем это возможно при традиционном подходе к проектированию.

Концепция RAD стала ответом на методы разработки программ 1970-х и начала 1980-х годов, такие как «модель водопада». Эти методы предусматривали настолько медленный процесс создания программы, что зачастую даже требования к программе успевали измениться до окончания разработки. Основателем RAD считается сотрудник IBM Джеймс Мартин, который в 1980-х годах сформулировал основные принципы RAD, основываясь на идеях Барри Бойма и Скотта Шульца. А в 1991 году Мартин опубликовал известную книгу, в которой детально изложил концепцию RAD и возможности её применения. В настоящее время RAD становится общепринятой схемой для создания средств разработки программных продуктов.

RAD предполагает, что разработка ПО осуществляется небольшой командой разработчиков за срок порядка трех-четырех с применением инструментальных средств визуального моделирования и разработки. Технология RAD предусматривает активное привлечение заказчика уже на ранних стадиях - обследование организации, выработка требований к системе. Методология RAD является одним из подходов к разработке ПО в рамках спиральной модели ЖЦ.

Жизненный цикл ПО по методологии RAD состоит из четырех фаз:

фаза анализа и планирования требований;

фаза проектирования;

фаза построения;

фаза внедрения.

На стадии анализа и планирования требований пользователи осуществляют следующие действия:

определение функций, которые должна выполнять система;

выделение наиболее приоритетных функций, требующих проработки в первую очередь;

описание информационных потребностей.

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

ограничивается масштаб проекта;

устанавливаются временные рамки для каждой из последующих стадий;

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

список расположенных по приоритету функций будущего ПО ИС;

предварительные модели ПО.

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

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

устанавливаются требования разграничения доступа к данным;

при необходимости для каждого элементарного процесса создается частичный прототип (экранная форма, диалог, отчет, устраняющий неясности или неоднозначности);

устанавливаются требования разграничения доступа к данным;

определяется состав необходимой документации.

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

общая информационная модель системы;

функциональные модели системы в целом и подсистем, реализуемых отдельными командами разработчиков;

точно определенные интерфейсы между автономно разрабатываемыми подсистемами;

построенные прототипы экранных форм, отчетов, диалогов.

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

На стадии реализации выполняется быстрая разработка приложения:

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

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

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

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

производится физическое проектирование базы данных;

формулируются требования к аппаратным ресурсам;

устанавливаются способы увеличения производительности;

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

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

Применение технологии RAD целесообразно, когда:

требуется выполнение проекта в сжатые сроки (90 дней);

нечетко определены требования к ПО;

проект выполняется в условиях ограниченности бюджета;

интерфейс пользователя (GUI) есть главный фактор;

проект большой, но поддается разделению на более мелкие функциональные компоненты;

ПО не обладает большой вычислительной сложностью.

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

Рисунок 1 - Сравнение RAD и Каскадного метода

1.3Технология Extreme Programming

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

Концепцию экстремального программирования разработал Кент Бек во время работы в Chrysler. Он опубликовал этот метод в 1999 в книге -Extreme Programming Explained. Данная методология описывает лучшие практики в сфере планирования, управления, проектирования, кодирования и тестирования. Уорд Каннингем и Рон Джеффрис также привнесли свои идеи, так что все трое считаются основателями метода XP.

Обычно XP характеризуют набором из 12 правил (практик), которые необходимо выполнять для достижения хорошего результата:

планирование процесса;

тесное взаимодействие с заказчиком;

общесистемные правила именования;

простая архитектура;

рефакторинг;

парное программирование;

40-часовая рабочая неделя;

коллективное владение кодом;

единые стандарты кодирования;

небольшие релизы;

непрерывная интеграция;

тестирование.

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

Основными фазами модели можно считать:

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

Истории использования (User Story) - этап сбора требований, записываемых на специальных карточках в виде сценариев выполнения отдельных функций. Истории использования являются требованиями для планирования очередной версии и одновременной разработки приемочных тестов (Acceptance tests) для ее проверки.

Планирование версии (релиза). Проводится на собрании с участием заказчика путем выбора User Stories, которые войдут в следующую версию. Одновременно принимаются решения, связанные с реализацией версии. Цель планирования - получение оценок того, что и как можно сделать за 1-3 недели создания следующей версии продукта.

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

Тестирование проводится с участием заказчика, который участвует в составлении тестов.

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

По завершению цикла делается переход на следующую итерацию разработки

1.4Технология Microsoft Solutions Framework

Microsoft Solutions Framework (MSF) -- методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения.

В 1994 году, стремясь достичь максимальной отдачи от IT-проектов, Microsoft выпустила в свет пакет руководств по эффективному проектированию, разработке, внедрению и сопровождению решений, построенных на основе своих технологий. Эти знания базируются на опыте, полученном Microsoft при работе над большими проектами по разработке и сопровождению программного обеспечения, опыте консультантов Microsoft и лучшем из того, что накопила на данный момент IT-индустрия.

Модель процессов MSF сочетает каскадную и спиральную модели разработки: проект реализуется поэтапно, с наличием соответствующих контрольных точек, а сама последовательность этапов может повторяться по спирали.

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

Создание общей картины приложения.

На этом этапе решаются следующие основные задачи:

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

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

определение бизнес-целей;

оценка существующей ситуации;

создание документа общей картины и области действия проекта;

определение требований и профилей пользователей;

разработка концепции решения;

оценка риска;

Планирование.

Этап состоит из трех стадий: концептуальное, логическое и физическое проектирование.

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

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

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

В ходе данного этапа решаются такие задачи:

разработка проекта и архитектуры решения;

создание функциональной спецификации;

разработка планов проекта;

разработка календарного графика;

создание среды разработки, тестирования и пилотной эксплуатации;

Разработка

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

создание прототипа приложения;

разработка программных компонентов приложения;

создание решения (последовательность ежедневных или более частых сборок приложения);

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

Результаты этапа предполагают следующие элементы:

исходный текст кода и исполняемые файлы;

сценарии установки и конфигурации для развертывания;

окончательная функциональная спецификация;

элементы поддержки решения;

спецификации и сценарии тестирования.

Стабилизация

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

Тестирование подразумевает следующие основные виды работ:

тестирование компонентов;

тестирование баз данных;

тестирование инфраструктуры;

тестирование защиты;

тестирование интеграции;

анализ удобства работы с продуктом;

нагрузочное тестирование (включая анализ ресурсоемкости и производительности);

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

ведение отчетности по тестированию.

Развертывание

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

1.5Обоснование выбора метода, технологии и средства проектирования

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

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

Средством моделирования системы выбрано Rational Rose. Работа продукта основана на универсальном языке моделирования UML (Universal Modeling Language), благодаря чему Rational Rose способен решать практически любые задачи в проектировании информационных систем: от анализа бизнес процессов до кодогенерации на определенном языке программирования.

ГЛАВА 2 СОЗДАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1Фаза анализа и планирования требований

В соответствии с RAD на фазе анализа и планирования требований были сформулированы функции, которые должна осуществлять система:

просмотр сообщений;

поиск по сообщениям;

отправка заполненной регистрационной формы;

регистрация пользователей;

добавление сообщений;

редактирование сообщений;

удаление сообщений;

жалоба на сообщение;

изменение статуса жалобы на сообщение;

жалоба на пользователей;

изменение статуса жалобы на пользователя;

блокировка пользователей;

поиск информации о заблокированных пользователях;

разблокировка пользователей;

формирование отчета о сообщениях пользователей;

формирование отчета о заблокированных пользователях.

Эти функции были отражены в диаграмме вариантов использования, с помощью Rational Rose. Диаграмма представлена на Рисунке 2.

Рисунок 2 - Диаграмма вариантов использования

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

определение общих границ и контекста моделируемой предметной области;

формулирование общих требований к функциональному поведению проектируемой системы;

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

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

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

Правила построения диаграммы вариантов использования:

не моделировать связи между актерами;

не соединять непосредственно два варианта использования;

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

2.2Фаза проектирования

Общая модель информационной системы изображена на Рисунке 3.

Рисунок 3 - Общая модель информационной системы.

В дальнейшем в курсовой работе более детально будут рассмотрены следующие модули системы:

регистрация пользователя;

рассмотрение жалобы на сообщения;

формирование отчета о заблокированных пользователях.

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

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

Диаграммы классов обычно содержат следующие сущности:

классы;

интерфейсы;

кооперации;

отношения зависимости, обобщения и ассоциации.

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

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

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

граничные (boundary) классы: объекты этих классов реализуют интерфейсы системы с внешней средой и различными пользователями (не следует их путать с внутренними интерфейсами взаимодействия классов, упоминавшихся ранее);

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

классы управления (control): объекты этих классов являются активными, берущими на себя управление и организацию вычислительных процессов; чаще всего это стандартные компоненты операционных систем и систем управления базами данных (СУБД), таймеры, координаторы и т.п.;

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

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

На Рисунке 4 представлена общая диаграмма классов для выбранных прецедентов.

Рисунок 4 - Общая диаграмма классов.

Диаграммы классов для каждого модуля в отдельности представлены в Приложении А Диаграммы классов.

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

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

Главный акцент на диаграмме уделяется последовательности приема/передачи сообщений.

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

форма просмотра списка заявок на регистрацию;

форма подтверждения добавления пользователя;

зарегистрированные пользователи;

форма с сообщением об успешном добавлении;

форма с сообщением о невозможности добавления пользователя.

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

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

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

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

Рисунок 5 - Диаграмма последовательности "Добавление информации о зарегистрированном пользователе в базу".

Диаграммы последовательности для остальных выбранных модулей системы представлены в Приложении Б Диаграммы последовательности.

На фазе проектирования также были разработаны прототипы экранных форм.

На Рисунке 6 изображен прототип формы «Просмотр списка заявок на регистрацию». Другие прототипы представлены в Приложении В Прототипы форм.

Рисунок 6 - Просмотр списка заявок на регистрацию.

2.3Фаза построения

В качестве среды реализации был выбран язык программирования PHP (Hypertext Preprocessor). PHP - язык программирования общего назначения, относящийся к скриптовому типу. Он интенсивно применяется при создании виртуальных. Занимает лидирующие позиции в списке языков программирования, идеально подходящих для создания динамических сетевых ресурсов.

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

Доступ к WWW-конференции осуществляется через Интернет, например с помощью браузера Internet Explorer 8, поэтому для оптимальной эффективности доступа к форуму нужно придерживаться некоторых требований к системе:

Компьютер/процессор

Процессор с тактовой частотой 233 мегагерца (МГц) или выше (рекомендуется процессор Pentium)

Операционная система

32-разрядная версия Windows XP;

Windows XP Professional x64 Edition;

32-разрядная версия Windows 7;

64-разрядная версия Windows 7;

Память

32-разрядная версия Windows XP -- 64 МБ;

Windows XP Professional x64 Edition -- 128 МБ;

32-разрядная версия Windows Vista -- 512 МБ;

64-разрядная версия Windows Vista -- 512 МБ;

Свободное место на жестком диске

32-разрядная версия Windows XP -- 150 МБ;

Windows XP Professional x64 Edition -- 200 МБ;

32-разрядная версия Windows 7 -- 70 МБ;

64-разрядная версия Windows 7 -- 120 МБ;

2.4Фаза внедрения

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

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

регистрация пользователя;

рассмотрение жалобы на сообщение;

формирование отчета о заблокированных пользователях.

Регистрация пользователя:

Для просмотра заявок на регистрацию модератор должен:

выбрать пункт меню со списком заявок на регистрацию:

Для добавления информации о зарегистрированном пользователе в базу модератор должен:

выбрать нужную позицию из списка заявок на регистрацию и нажать на ссылку «Добавить»:

подтвердить добавление в открывшейся форме подтверждения, нажав на кнопку «Добавить»:

Для удаления заявки на регистрацию модератор должен:

выбрать нужную позицию из списка заявок на регистрацию и нажать на ссылку «Удалить»:

подтвердить удаление в открывшейся форме подтверждения, нажав на кнопку «Удалить»:

Рассмотрение жалобы на сообщение:

Для просмотра списка жалоб на сообщения модератор должен:

выбрать пункт меню со списком жалоб на сообщения:

Для просмотра конкретной жалобы на сообщение модератор должен:

выбрать нужную позицию из списка жалоб;

нажать на ссылку «Детали»:

Для удаления жалобы на сообщение модератор должен:

нажать на ссылку «Удалить жалобу»:

в открывшейся форме подтверждения нажать на кнопку «Удалить»:

Формирование отчета о заблокированных пользователях:

Для формирования отчета о заблокированных пользователях модератор должен:

выбрать отчет в списке отчетов:

в открывшейся форме отчета и параметров отчета нажать на кнопку «Сформировать»:

ПРИЛОЖЕНИЕ А Диаграммы классов

А.1 Диаграмма классов «Регистрация пользователя»

А.2 Диаграмма классов «Формирование отчета о заблокированных пользователях»

А.3 Диаграмма классов «Рассмотрение жалобы на сообщение».

Приложение Б Диаграммы последовательности

Б.1 Диаграмма последовательности «Просмотр заявок на регистрацию».

Б.2 Диаграмма последовательности «Удаление заявки на регистрацию».

Б.3 Диаграмма последовательности «Просмотр списка жалоб на сообщения».

Б.4 Диаграмма последовательности «Просмотр конкретной жалобы на сообщение».

Б.5 Диаграмма последовательности «Удаление жалобы».

Б.6 Диаграмма последовательности «Формирование отчета о заблокированных пользователях».

Приложение В Прототипы форм

В.1 Прототип формы «Просмотр списка жалоб на сообщения».

В.2 Прототип формы «Просмотр конкретной жалобы на сообщение»

В.3 Прототип формы «Формирование отчета о заблокированных пользователях»

Приложение Г Листинг программы

Г.1 Просмотр заявок на регистрацию

<table border=1>

<thead>

<tr>

<td>Дата</td>

<td>Логин</td>

<td>Пароль</td>

<td>Добавить пользователя</td>

<td>Удалить заявку</td>

</tr>

</thead>

<tbody>

<?php

$query="SELECT *

FROM request";

$res=mysql_query($query);

$num=mysql_num_rows($res);

if ($num<=0)

{

echo "</table> <p>Заявок нет";

}

else

{

$res = db_result_to_array($res);

foreach ($res as $t)

{

echo" <tr>

<td>".$t['dat']."</td>

<td>".$t['login']."</td>

<td>".$t['pass']."</td>

<td><a class=sss href='add.php?login=".$t['login']."'>Добавить<i class='fa fa-check'></i></a></td>

<td><a class=sss href='del.php?login=".$t['login']."'>Удалить</a></td>

</tr> ";} }

?>

</tbody>

</table>

Г.2 Добавление информации о зарегистрированном пользователе в базу

<?php

echo "<FORM method=post enctype='multipart/form-data'> ";

$lg=$_GET['login'] ;

echo " Вы уверенны, что хотите добавить пользователя ".$lg."?";

echo "<p><input type='submit' name='add' value='Добавить'>

<input type='submit' name='cancel' value='Отмена'>

<img src='images\gl.png'> " ;

echo "</form>";

if ($cancel)

{

echo "<script>document.location.replace('newuser.php');</script>";

}

if ($add)

{

$query="SELECT *

FROM request

Where login='".$lg."'";

$res=mysql_query($query);

$row = mysql_fetch_array($res);

$q="INSERT INTO users VALUES

('".$row['login']."','".$row['pass']."',0)";

$res=mysql_query($q);

$q="DELETE FROM request WHERE login='".$lg."'";

$res=mysql_query($q);

echo "<script>document.location.replace('newuser.php');</script>";

}

?>

Г.3 Удаление заявки на регистрацию

<?php

echo "<FORM method=post enctype='multipart/form-data'> ";

$lg=$_GET['login'] ;

echo "Вы уверенны, что хотите удалить заявку?";

echo "<p><input type='submit' name='add' value='Удалить'>

<input type='submit' name='cancel' value='Отмена'>

<img src='images\gl.png'> " ;

echo "</form>";

if ($cancel)

{

echo "<script>document.location.replace('newuser.php');</script>";

}

if ($add)

{

$q="DELETE FROM request WHERE login='".$lg."'";

$res=mysql_query($q);

echo "<script>document.location.replace('newuser.php');</script>";

}

?>

Г.4 Просмотр списка жалоб на сообщения

<table border=1>

<thead>

<tr>

<td>Дата</td>

<td>Автор сообщения</td>

<td>Детали</td>

</tr>

</thead>

<tbody>

<?php

$query="SELECT *

FROM compmess C, messages M

where C.mess=M.idMess";

$res=mysql_query($query);

$num=mysql_num_rows($res);

if ($num<=0)

{

echo "</table><p>Жалоб нет!!!";

}

else

{

$res = db_result_to_array($res);

foreach ($res as $t)

echo " <tr>

<td>".$t['dat']."</td>

<td>".$t['User']."</td>

<td><a href='componetext.php?id=".$t['id']."'>Детали</a></td> ";

echo "</tr>

</tbody>

</table> ";

}

?>

Г.5 Просмотр конкретной жалобы на сообщение

<FORM method=post enctype="multipart/form-data">

<?php

$id=$_GET['id'] ;

$query="SELECT *

FROM compmess C, messages M

where C.mess=M.idMess and id=".$id;

$res=mysql_query($query);

$num=@mysql_num_rows($res);

if ($num<=0)

{

echo "Ссылка не верна!!!";}

$row = mysql_fetch_array($res);

echo"<p><b>Дата: </b>".$row['dat']."

<p><b>Автор сообщения: </b>".$row['User']."

<p><b> Текст сообщения: </b>".$row['txt'];

if($row['topic']==1)

{

echo "<p><a href='forumtopicadm.php?id=".$row['idMess']."'>Ссылка на сообщение</a> ";

}

else

{

echo "<p><a href='forumtopicadm.php?id=".$row['reply']."'>Ссылка на сообщение</a> ";

}

echo "<p><a class=sss href='deltext.php?idC=".$id."&id=".$row['idMess']."'>Удалить сообщение</a>

<p><a class=sss href='delcomp.php?id=".$id."'>Удалить жалобу</a> ";

?>

</form>

Г.6 Удаление жалобы

<FORM method=post enctype="multipart/form-data">

<?php

$id=$_GET['id'] ;

$idC=$_GET['idC'] ;

$query="SELECT *

FROM compmess C, messages M

where C.mess=M.idMess and id=".$id;

$res=mysql_query($query);

$num=@mysql_num_rows($res);

$row = mysql_fetch_array($res);

echo "Вы уверенны, что хотите удалить жалобу на сообщение от ".$row['User']."?";

echo "<p><input type='submit' name='del' value='Удалить'>

<input type='submit' name='cancel' value='Отмена'>

<img src='images\gl.png'> " ;

?>

</form>

<?php

if ($cancel)

{ приложение конференция прецедент

echo "<script>document.location.replace('componetext.php?id=".$idC."');</script>";

}

if ($del)

{

$q="DELETE FROM compmess WHERE id=".$idC;

$res=mysql_query($q);

echo "<script>document.location.replace('comptext.php');</script>";

}

?>

Г.7 Формирование отчета о заблокированных пользователях

<FORM method=post enctype="multipart/form-data">

<input type=submit name='form' value= Сформировать>

</FORM>

<?php

if($form)

{

$q="Select *

from users

where banstate=1";

$res=mysql_query($q);

$num=@mysql_num_rows($res);

if ($num<=0)

{

echo "Заблокированных пользователей нет";

}

else

{

$k=0;

echo "Всего заблокированных пользователей: ".$num."<p>";

echo"<table border=1>

<thead>

<tr>

<td>№</td>

<td>Пользователь</td>

</tr> </thead> ";

$res = db_result_to_array($res);

foreach ($res as $t)

{

$k++;

echo "<tbody>

<tr>

<td>".$k."</td>

<td>".$t['login']."</td>

</tr>";

}

echo "</tbody>

</table>";

}

}

?>

Размещено на Allbest.ru


Подобные документы

  • Анализ моделируемого приложения и постановка задачи. Диаграмма прецедентов, деятельности объектов и состояния классов. Разработка приложения-игры, выбор языка программирования и среды для разработки проекта, интерфейс приложения и ресурсы проекта.

    курсовая работа [308,5 K], добавлен 14.10.2011

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

    дипломная работа [9,9 M], добавлен 20.03.2017

  • Выявление классов-сущностей (диаграмма классов) и вариантов использований системы. Моделирование видов деятельности, взаимодействий, состояний, пользовательского интерфейса и архитектуры системы (диаграмм развертывания) на основе выявленных требований.

    дипломная работа [2,1 M], добавлен 24.01.2016

  • Разработка интернет-приложения (Web–сервиса), позволяющего делать заказы онлайн, выполнять их обработку. Диаграмма вариантов использования. Модель предметной области. Описание концептуальных классов. Моделирование процесса выполнения операций в языке UML.

    курсовая работа [1,3 M], добавлен 21.11.2013

  • Логическая модель и диаграмма потоков данных при моделировании информационной системы управления учебным процессом, ее надежность. Диаграмма прецедентов, классов концептуального уровня, компонентов и пакетов. Сетевой план выполнения проектных работ.

    дипломная работа [6,8 M], добавлен 15.05.2012

  • Определение прецедентов АИС "Автопарковка". Анализ предметной области. Первоначальная настройка системы администратором. Настройка БД и зеркалирования клиентской базы. Диаграмма последовательности системы. Модель проектирования информационной системы.

    курсовая работа [605,8 K], добавлен 06.05.2015

  • Процесс проектирования программы, состоящий из следующих шагов: описание прецедентов, построение диаграммы прецедентов, диаграммы взаимодействий, создание модели программных классов. Тестирование программы входными тестовыми вариантами, ее листинг.

    курсовая работа [1,9 M], добавлен 25.10.2012

  • Разработка системы для автоматизации деятельности бухгалтерии. Моделирование прецедентов и предметной области. Диаграмма классов. Логическая модель данных. Преобразование результатов проектирования в программный код посредством CASE-средства CASEBERRY.

    курсовая работа [424,7 K], добавлен 17.12.2015

  • Разработка оконного приложения на языке C#, в окне которого будет игра "Лабиринт. Диаграмма вариантов использования языка UML. Описание разрабатываемой программы с точки зрения программиста. Разработка прикладного окна, классов Enemy и Dot, Wall и Map.

    курсовая работа [457,6 K], добавлен 22.06.2015

  • Построение модели прецедентов, модели пригодности для прецедента. Описание атрибутов и операций классов системы. Проектирование с применением методологии ICONIX. Построение диаграммы пригодности, диаграммы последовательностей и диаграмма классов.

    курсовая работа [949,5 K], добавлен 25.05.2015

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.