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

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

• Оглавление
• 1. Концепция
• 1.1 Цели и требования к системе
• 1.2 Глоссарий
• 1.3 Учебные цели
• 2. Архитектура и компоненты
• 3. Реализация
• 3.1 Язык программирования Java
• 3.2 AJAX
• 3.3 Технология Google Web Toolkit
• 3.4 Шаблон проектирования MVC
• 3.5 База Данных
• 3.6 Sprin Security
• 3.7 JBoss AS
• 3.8 Apache Ant
• Заключение
• Список литературы



1. Концепция

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

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

Системы управления проектами позволяют обмениваться «задачами» команде, руководителям отделов распределять «задачи» и следить за ходом исполнения, менеджерам планировать время исполнения поставленных задач и вести статистику.

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



1.1 Цели и требования к системе

Задача состоит в разработке системы для команд, разрабатывающих программное обеспечение, а так же руководителей команд. Система должна состоять из клиентской и серверной части. Использование сервера обусловлено задачей хранения и обмена данными между клиентами. Обмен происходит посредством HTTP запросов. БД на сервере отвечает за хранение информации о «задачах» (текст, на кого назначена, статус, планируемое время выполнения, фактическое время выполнения, дата создания и т.д), о пользователях (логин, пароль, имя, фамилия, e-mail, номер телефона), о прикрепленных файлах.

Система должна предоставлять возможность работы с «задачами» и получать аналитическую информацию. Работа с «задачами» подразумевает под собой выполнение функций создания «задач», комментирования, прикрепления файлов, назначение на члена команды, изменение статуса. Аналитическая информация подразумевает под собой: график выполнения задач участниками команды (отношение затраченного времени к планируемому), качество выполнения задач (зависит от количества возвратов «задачи»). Система должна иметь систему оповещения. Пользователям, участвующим в выполнении задачи, должны приходить уведомления о изменениях в на e-mail адрес указанный в профиле пользователя.

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

Пользователям системы так же должна быть доступна функция редактирования своего профиля (имя, фамилия, e-mail). Для руководителей помимо функции редактирования профиля должна быть доступна функция регистрации нового пользователя.



1.2 Глоссарий

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

Статус задачи - Существует 5 типов статусов задач: новая, анализ, к разработке, к приемке, закрыта.

· Новая-такая задача не имеет исполняющего.

· Анализ-такая задача имеет исполняющего, как правило аналитика в команде.

· К разработке-такая задача в роли исполняющего имеет разработчика команды.

· К приемке-задача с таким статусом направляется либо на тестировщика в команде, либо на члена команды создавшего эту задачу.

· Закрыта-этот статус может присвоить только пользователь создавший задание. Этот статус означает успешное выполнение задания.

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

1.3 Учебные цели

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

2) Изучение технологии Google Web Toolkit.

3) Применение полученных знаний в работе с Apache Tomcat, СУБД H2. Получение опыта работы с текстовыми форматами обмена данными, такими как JSON, XML.



2. Архитектура и компоненты

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

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

Эффективным решением, которое было использовано в разработке системы управления проектами является использование клиент-серверной архитектуры.

Рисунок 2.1 Клиент-серверная архитектура

Преимущества клиент-серверной архитектуры:

· Отсутствие дублирования кода программы-сервера программами-клиентами.

· Так как все вычисления выполняются на сервере, то требования к компьютерам, на которых установлен клиент, снижаются.

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

· Позволяет объединить различные клиенты. Использовать ресурсы одного сервера часто могут клиенты с разными аппаратными платформами, операционными системами и т. п.

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

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

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

Сеть-система связи компьютеров или компьютерного оборудования. Сеть так же является компонентом клиент-серверной архитектуры, за счет нее происходит обмен данными между клиентом и сервером. Требования для системы с архитектурой «клиент-сервер» невысокие, достаточно интернета с мобильного устройства, так же количество данных уменьшается за счет передачи маленького объема данных (передается не вся страница, а только ее часть).



3. Реализация

3.1 Язык программирования Java

Для реализации системы был использован язык Java. Применение этого языка программирования требует используемая технология Google Web Toolkit. На сегодняшний день язык Java является одним из самых распространенных языков. К нему существует огромное количество библиотек и технологий, а так же очень много учебных пособий. Язык Java реализует большинство требований с точки зрения программиста. Язык Java и технология Google Web Toolkit были выбраны не случайно, вместе, они невероятно ускоряют разработку AJAX приложения.

3.2 AJAX

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

На рисунке 3.2.1 представлена схема работы AJAX подхода к построению веб приложений. Отметим плюсы этого подхода:

* Экономия трафика.

* Уменьшение нагрузки на сервер.

* Ускорение реакции интерфейса.

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



Рисунок 3.2.1 Схема AJAX

Недостатки:

· Отсутствие интеграции со стандартными инструментами браузера (Недоступна кнопка назад).

· Динамически загружаемое содержимое недоступно поисковикам.

· Усложнение проекта (Перераспределяется логика обработки данных -- происходит выделение и частичный перенос на сторону клиента процессов первичного форматирования данных. Это усложняет контроль целостности форматов и типов).

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



3.3 Технология Google Web Toolkit

Google Web Toolkit - это свободный Java-фреймворк, который позволяет веб-разработчикам создавать Ajax приложения на основе Java.

Используя GWT разработчики могут быстро писать и отлаживать Ajax приложения. Схема работы GWT представлена на рисунке 3.3.1.

Рисунок 3.3.1

Смысл технологии заключается в том, что разработчик пишет веб-приложение практически так же, как и обычное desktop-приложение, а GWT компилятор превращает код в html+css. Так же GWT сам создает серверную часть приложения, что сильно облегчает разработку. Так же разработчику практически не приходится заниматься версткой страницы, для этого есть инструмент под названием GWT Designer, в котором можно простейшим образом располагать элементы на веб странице. Эти элементы называются виджетами. В системе использовались стандартные виджеты (см. Рис. 3.3.2), однако, существуют сторонние библиотеки виджетов.



Рисунок 3.3.2 Виджеты

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

Рисунок 3.3.3 Структура файлов



Src-это исходные файлы, а в папке War храняться настройки сервера.

3.4 Шаблон проектирования MVC

В качестве шаблона проектирования компонент системы был использован MVC.

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

Рисунок 4. Архитектура проектирования MVC

Представление (вид) отвечает за отображение информации, поступающей в систему.

Модель является «сутью» системы и отвечает за непосредственные алгоритмы, расчёты и тому подобное внутреннее устройство системы.

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

3.5 База Данных

Для хранения данных на сервере была разработана база данных. База содержит следующие таблицы:

· Пользователи

· Задачи

· Комментарии

· Файлы

· Статусы

· Роли

· Проекты

· Wiki

В таблице пользователи хранится информация о пользователях: e-mail, логин, пароль и т.д. Эта таблица связана с таблицами: задачи, комментарии, роли и проекты.

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

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

Роли-это вспомогательная таблица для таблицы «пользователи». Пользователь может быть: администраторов, руководителем, проект менеджером, разработчиком.

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

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

Рисунок 3.6.1 Модель Базы данных



3.6 Spring Security

Spring Security это Java/Java EE фреймворк, предоставляющий механизмы построения систем аутентификации и авторизации, а также другие возможности обеспечения безопасности для промышленных приложений, созданных с помощью Spring Framework.

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

<filter>

<filter-name>filterChainProxy</filter-name>

<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>

</filter>

<filter-mapping>

<filter-name>filterChainProxy</filter-name>

<url-pattern>/*</url-pattern>

</filter-mapping>

Помимо добавления фильтра, в файл web.xml необходимо добавить контекст приложения.

<context-param>

<param-name>contextConfigLocation</param-name>

<param-value>

/WEB-INF/cabinet-security.xml

</param-value>

</context-param>

<listener>

<listener-class>

org.springframework.web.context.ContextLoaderListener

</listener-class>

</listener>

Далее, заполняется описанный выше cabinet-security.xml. Элемент <intercept-url> показывает, какие пути должны быть защищены, и с какими ролями возможен доступ к ним. При получении запроса, фильтр проверяет все возможные шаблоны пути сверху вниз.

<property name="objectDefinitionSource">

<s:filter-invocation-definition-source>

<s:intercept-url pattern="/personal/**" access="ROLE_USER"/>

</s:filter-invocation-definition-source>

</property>

<authentication-provider>

указывает на то, как проводить аутентификацию.

<bean id="rememberMeAuthenticationProvider" class="org.springframework.security.providers.rememberme.RememberMeAuthenticationProvider"/>

3.7 JBoss AS

В качестве сервера приложений для нашей веб-системы был выбран JBoss Application Server версии 5.1.0.GA. - абсолютно бесплатный проект, с открытым исходным кодом. На сегодняшний день это лучший бесплатный сервер приложений, обладающий высокой производительностью, надежностью и поддержкой всех существующих стандартов J2EE. JBoss 5 является следующим поколением сервера приложений JBoss, построенным на базе нового JBoss Microcontainer. JBoss Microcontainer является облегченным контейнером для управления POJO, их развертыванием, конфигурацией и жизненным циклом.

JBoss5 построен вокруг передовой концепции Virtual Deployment Framework (VDF), которая берет аспектно-ориентированный дизайн от многих ранних контейнеров JBoss и применяет это на уровне развертывания. Деплойеры работают по цепочке через VFS, анализируют развертывания и предоставляют метаданные, используемые JBoss Microcontainer, который в свою очередь инстанцирует и связывает вместе различные части развертывания, контролируя их жизненный цикл и зависимости.

Многие ключевые возможности JBoss 5, которые используются в работе веб-системы, предоставляются через интеграцию других автономных проектов JBoss:

· JBoss EJB3, включенный в JBoss 5, предоставляет реализацию последней ревизии спецификации Enterprise Java Beans (EJB). EJB 3.0 является глубоко изученной и упрощенной спецификацией EJB. Целями EJB 3.0 являются упрощенная разработка, содействие подходу разработки через тесты, и фокусирование больше на написании POJO, чем кодировании средствами сложных EJB API.

· JBossWS является стеком веб-сервисов для JBoss 5, предоставляющие Java EE совместимые веб-сервисы, JAX-WS-2.0..

· JBoss Transactions является менеджером транзакций по умолчанию для JBoss 5. JBoss Transactions основан на индустриально проверенной технологии и 18 летней истории как лидера в распределенных транзакциях, и является одним из наиболее доступных интероперабельных реализаций.



3.8 Apache Ant

Apache Ant -- java-утилита для автоматизации процесса сборки программного продукта.

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

<project name="TaskManager" default="deploy" basedir=".">

<property file="build.properties"/>

<target name="build-dependencies">

<ant antfile="${project.path.utils}/build.xml" inheritAll="false" />

<ant antfile="${project.path.common-app-objects}/build.xml" inheritAll="false" />

<ant antfile="${project.path.core}/build.xml" inheritAll="false" />

<ant antfile="${project.path.components}/build.xml" inheritAll="false" />

</target>

<target name="init" description="Build initialization">

<ant antfile="${project.path.map-kit}/build.xml" inheritAll="false" />

<path id="libs">

<fileset dir="${module.third-party.dir}" includes="${module.third-party.lib}"/>

<fileset dir="${project.path.core}/build" includes="*.jar"/>

<fileset dir="${project.path.map-kit}/build" includes="*.jar"/>

<fileset dir="${project.path.components}/build" includes="*.jar"/>

<fileset dir="${project.path.utils}/build" includes="*.jar"/>

<fileset dir="${project.path.common-app-objects}/build" includes="*.jar"/>

</path>

</target>

<target name="clean" depends="init">

<delete dir="${build.dir}"/>

</target>

<target name="deploy" depends="clean">

<mkdir dir="${module.build.dir}"/>

<javac srcdir="${module.src.dir}"

destdir="${module.build.dir}"

debug="${compiler.debug}"

optimize="${compiler.optimize}"

deprecation="${compiler.deprecation}"

encoding="${compiler.encoding}">

<classpath refid="libs"/>

</javac>

<copy todir="${module.build.dir}">

<fileset dir="${module.src.dir}">

<include name="**/*"/>

<exclude name="**/*.java"/>

</fileset>

</copy>

<jar jarfile="${module.dist.dir}/${module.name}">

<fileset dir="${module.build.dir}"/>

</jar>

<copy todir="${build.dir}">

<fileset dir="${project.path.map-kit}/build" includes="*.jar"/>

</copy>

</target>

<target name="stand-alone" depends="build-dependencies,deploy"/>

<target name="run-stand-alone" depends="stand-alone">

<java classname="ru.dz.swing.core.test.TestFrame" fork="true">

<arg value="ru.dz.icar.module.map.MapModule"/>

<!-- <arg value="moscowMap"/> -->

<classpath>

<path refid="libs"/>

<fileset dir="${build.dir}">

<filename name="${module.name}"/>

</fileset>

</classpath>

</java>

</target>

</project>

Цели сравнимы с процедурами в языках программирования и содержат вызовы команд-заданий (Tasks). Каждое задание представляет собой неделимую, атомарную команду, выполняющую некоторое элементарное действие.

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

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



Заключение

Итак, поставленная задача разработки системы управления проектами была решена. Созданная система соответствует поставленным требованиям и реализует необходимые функции.

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

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



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

Книги:

1. Java Том I. Основы. Библиотека профессионала. Седьмое издание. Кей С.Хорстманн, Гари Корнелл. Москва. Издательский дом «Вильямс», 2007 .

2. Java Том II. Тонкости программирования. Библиотека профессионала. Седьмое издание. Кей С.Хорстманн, Гари Корнелл. Москва. Издательский дом «Вильямс», 2007.

3. Философия Java. Библиотека программиста. 4-е изд. - СПб.: Питер, 2009

4. «Понимание SQL». Мартин Грубер. Перевод Лебедева В.Н. под редакцией Булычева В.Н. Москва, 1993.

5. «Java Development with Ant». Erick Hatcher, Steve Loughran.

Интернет:

6. http://xstream.codehaus.org

7. http://ru.wikipedia.org

8. https://developers.google.com/web-toolkit/

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

...