Отчет по практике

Договора с поставщиками:

Комплект документов для одного договора содержит:

Договор с поставщиком 

Акт выполненных работ (неограниченное кол-во документов)

Форма договора с заказчиком

Выписка произвольных счетов

Архив выданных актов  выполненных работ 

Архив полученных актов  выполненных работ 

Формирование отчетов

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

Возможность экспорта отчетов  в Microsoft Word или Excel.  
Использование Microsoft SQL Server в качестве сервера базы данных обеспечивает: легкость при установке, высокую надежность и простоту в эксплуатации, автоматическое резервное копирование баз данных.

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

Получение отчетной информации в различных разрезах.

Возможность доработки  программы под требования заказчика.

Авторское внедрение  и сопровождение.

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

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

Встроенная справочная система.

Технические характеристики

Режимы работы:

как независимое приложение: "SkyCom - Договора";

как подсистема, входящая в программный комплекс: "SkyCom - Предприятие".

 

3.2 Функциональная модель системы и ее описание

 

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

Контекстная диаграмма  модели  представлена на рисунке 3.1.

 

Рисунок 3.1 – Контекстная  диаграмма модели ведения договоров с поставщиками

 

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

а) анализ договорных обязательств;

б) выделение просроченных договоров;

в) анализ причин просрочки;

Данные подпроцессы представлены на рисунке 3.2.

 

Рисунок 3.2 – Декомпозиция блока “ анализ выполнения договорных обязательств и реализации продукции ”

 

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

а) получение списка договоров;

б)упорядочивание договоров;

в) сохранение списка договоров.

Декомпозиция блока “анализ договорных обязательств” представлена на рисунке 3.3

Рисунок 3.3 – Декомпозиция блока “анализ договорных обязательств”

 

3.3 Информационная модель системы и ее описание

 

После анализа предметной области было принято решение выделить 7 сущностей: ВидДоговора, Товар, Должность, Сотрудник, Контрагент, Договор, ДоговорТовар. В таблице “ВидДоговора” были выделены следующие атрибуты:

− id (первичный ключ, целое число)

− name(название вида договора, текстовый тип данных)

В таблице “Товар” были выделены следующие атрибуты:

− id (первичный ключ, целое число)

− name(название товара, текстовый тип данных)

В таблице “Должность” были выделены следующие атрибуты:

− id (первичный ключ, целое число)

− name(название должности, текстовый тип данных)

В таблице “Сотрудник” были выделены следующие атрибуты:

− id (первичный ключ, целое число)

− name(имя сотрудника, текстовый тип данных)

− surname(фамилия, текстовый тип данных)

− address(адрес сотрудника, текстовый тип данных)

− log (логин, текстовый тип данных)

• pass(пароль, текстовый тип данных)
• status (статус сотрудника, текстовый тип данных)

В таблице “Контрагенты” были выделены следующие атрибуты:

− id (первичный ключ, целое число)

− name( имя, текстовый тип данных)

− surname(фамилия, текстовый тип данных)

− address(адрес сотрудника, текстовый тип данных)

− phone (телефон, текстовый тип данных)

В таблице “Договор” были выделены следующие атрибуты:

− id (первичный ключ, целое число)

− dateZ (дата заключения, дата)

− dateV (дата выполнения, дата)

− status (статус, текстовый тип данных)

− stoimost (стоимость договора, целое)

В таблице “ДоговорТовар” были выделены следующие атрибуты:

− id (первичный ключ, целое число)

− kol (количество, целое)

− cena (стоимость, целое)

Между сущностями “ВидДоговора” и “Договор” существует связь один-ко-многим. Между сущностями “Контрагент” и “Договор” существует связь один-ко-многим. Между сущностями “Сотрудник” и “Договор” существует связь один-ко-многим. Между сущностями “Должность” и “Сотрудник” существует связь один-ко-многим. Между сущностями “Товар” и “Договор” связь многие-ко-многим, поэтому была спроектирована еще одна сущность “ДоговорТовар”, в которую переходят первичные ключи из таблиц Товар и Договор.

Рассмотрим приведение данной модели к третьей нормальной форме.

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

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

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

Логический  и физический уровни итоговой информационной модели приведены на рисунках 3.3.1 и 3.3.2 соответственно.

Рисунок 3.3.1– Логический уровень информационной модели

Рисунок 3.3.2– Физический уровень информационной модели

 

3.4 Модели представления  системы и их описание

 

3.4.1 Диаграмма вариантов использования. Диаграмма вариантов использования представлена на рисунке 3.4.1.

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

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

− ввод нового сотрудника

− удаление сотрудника

− редактирование информации о сотруднике

− удаление сотрудника

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

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

Рисунок 3.4.2 – Диаграмма состояний системы

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

  3.4.3 Диаграмма классов. На рисунке 3.4.3 представлена диаграмма классов системы.

Рисунок 3.4.3– Диаграмма классов автоматизированной системы ведения договоров с поставщиками

 

3.4.4 Диаграмма последовательностей. Диаграмма последовательностей представлена на рисунке 3.4.4. На диаграмме изображены основные элементы системы, такие как браузер, jsp, сервлет (для получения/передачи данных на Jsp страницы), dao класс для взаимодействия с БД.

Рисунок 3.4.4– Диаграмма последовательностей системы

 

На диаграмме последовательностей отображены основные компоненты системы ведения договоров с поставщиками: Клиент (браузер), JSP страница, Servlet и DAO.

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

Рисунок 3.4.5 – Диаграмма компонентов системы

 

3.4.6 Диаграмма развертывания. Диаграмма развертывания автоматизированной системы ведения договоров с поставщиками изображена на рисунке 3.4.6.

Рисунок 3.4.6 – Диаграмма развертывания системы

 

3.5 Обоснование  принимаемых решений по используемым

     техническим и программным средствам реализации

 

Разработанная автоматизированная система ведения договоров с поставщиками ООО “Торнес” является web-приложением, написанном на языке Java. При разработке системы было принято решение использовать следующие фреймворки:

а) Struts 1.3.8. Struts − открытая реализация паттерна MVC model 2 для построения web приложений на базе Servlets, JSP, XML и Java. На сегодняшний день Struts является одним из самых популярных веб фреймворков. Регулярные исправления и внесения улучшений группой разработчиков фреймворка способствуют этому. Среди преимуществ использования Struts можно выделить следующие:

1) Struts является имплементацией веб-уровня J2EE приложения (web tier), предоставляя отличную организацию контроллера в виде Struts Action Framework;

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

3) Struts позволяет легко реализовать интернационализацию приложения;

4) В Struts реализована хорошая поддержка валидации данных с форм, программист также может самостоятельно настроить правила валидации как на клиенте так и на сервере;

5) Struts поддерживает использование HTML шаблонов для отображения страниц, предоставляя разработчикам плагин Struts Tiles.

б) Spring 2.5.1. Spring − самодостаточный модульный фреймворк, с выраженной многослойной архитектурой. В основе Spring лежит паттерн Inversion of control. Основная идея этого паттерна заключается в устранении зависимости компонентов или классов приложения от конкретных реализаций вспомогательных интерфейсов и делегировании полномочий по управлению созданием нужных реализаций IoC контейнеру. То есть разработчику не нужно заботиться о создании каких то вспомогательных объектов, за него все сделает Spring.

в) Hibernate 3.2.5. Технология Hibernate скрывает SQL код от разработчика, позволяет программистам акцентировать свое внимание на бизнес-логике приложения, а не на запросах к базе данных. Одно из главных преимуществ Hibernate это то, что разработчику неважно с какой БД будет работать приложение − Hibernate делает приложение независимым от диалекта SQL.

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

В качестве сервера для запуска приложений Java EE был использован сервер Apache Tomcat 6.0. Сервер Apache Tomcat обладает следующими характеристиками:

1) Tomcat может использоваться бесплатно в любой организации;

2) Tomcat − это полностью совместимый с J2EE контейнер сервлетов, и он является официальной эталонной реализацией для технологий Java Servlet и JavaServer Pages.

 

3.6 Руководство пользователя автоматизированной системы