Разработка автоматизированной системы «Учет деталей большегрузных автомобилей на складе»

 

 

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

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

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

 

 

3.4.3. Требования  к исходным кодам и языкам  программирования

Дополнительные требования не предъявляются.

 

3.4.4. Требования  к защите информации и программ

Требования к защите информации и программ не предъявляются.

 

 

3.4.5. Требования  к программной документации

3.4.5.1. Предварительный  состав программной документации

Состав программной  документации должен включать в себя:

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

Глава 2. Описание предметной области

2.1. Структура компании

 

Организационную структуру компании «Зубр» можно рассмотреть на представленной ниже функциональной схеме (рис.1.).

 

Функциональная схема ООО «Зубр»

 

 

Рис.1. Организационная схема фирмы

 

Должностные обязанности  работников

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

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

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

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

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

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

Водитель -  сопровождение груза  и документов.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

2.2. Схема документооборота

На рис. 2 представлена схема документооборота фирмы.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.2. Схема документооборота

Глава 3. Процесс разработки автоматизированной системы

в среде Rational Rose

3.1. Моделирование  систем в CASE-средствах

Среди всех фирм-производителей CASE-средств именно компания IBM Rational Software Corp. одна из первых осознала стратегическую перспективность развития объектно-ориентированных  технологий анализа и проектирования программных систем. Эта компания выступила инициатором унификации языка визуального моделирования в рамках консорциума OMG, что, в конечном итоге, привело к появлению первых версий языка UML. И эта же компания первой разработала инструментальное объектно-ориентированное CASE-средство, в котором был реализован язык UML как базовая нотация визуального моделирования.

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

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

3.2. Диаграмма вариантов использования (Use case diagram)

Этот вид диаграмм позволяет создать список операций, которые выполняет система. На основе таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждый Use case является описанием сценария поведения, которому следуют действующие лица (Actors).

В системе управления эмиссией банковских карт участвуют следующие действующие лица (actors):

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

В  модели  имеются  следующие  варианты  использования  (Use Case) (рис. 3):

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

Рис. 3. Диаграмма вариантов использования

3.3. Диаграмма  топологии (Deployment diagram)

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

Рис. 4. Диаграмма топологии

Система является однопользовательской. Пользователь данной системы кладовщик.

3.4. Диаграммы  взаимодействия (Interaction diagram)

Этот тип диаграмм включает в себя диаграммы последовательности действий (Sequence diagram) и диаграммы  сотрудничества (Collaboration diagram). Эти диаграммы  позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе (рис. 5 – рис.20).

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

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

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

Диаграммы сотрудничества (Collaboration diagram)

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

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

 

Рис. 5. Диаграмма последовательности.

Оплата заказа через  кассу.

 

Рис. 6. Диаграмма сотрудничества.

Оплата заказа через  кассу.

 

 

Рис. 7. Диаграмма последовательности.

Оплата поставщику.

 

Рис. 8. Диаграмма сотрудничества.

Оплата поставщику.

 

 

 

 

Рис. 9. Диаграмма последовательности.

Отгрузка на торговую точку.

 

 

Рис. 10. Диаграмма сотрудничества.

Отгрузка на торговую точку.

Рис. 11. Диаграмма последовательности.

Отправка заказа на склад.

 

Рис. 12. Диаграмма сотрудничества.

Отправка заказа на склад.

Рис. 13. Диаграмма последовательности.

Оформление заказа.

 

Рис. 14. Диаграмма сотрудничества.

Оформление заказа.

Рис. 15. Диаграмма последовательности.

Расчет стоимости.

 

Рис. 16. Диаграмма сотрудничества.

Расчет стоимости.

 

 

 

 

 

 

 

Рис. 17. Диаграмма последовательности.

Счет на оплату.

 

Рис. 18. Диаграмма сотрудничества.

Счет на оплату.

 

 

 

 

 

 

 

Рис. 19. Диаграмма последовательности.

Связь с поставщиком.

 

Рис. 20. Диаграмма сотрудничества.

Связь с поставщиком.

3.5. Диаграммы  классов (Class diagram)

 

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

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

Диаграмма классов приведена на рис.21.

 

Рис. 21. Диаграмма классов.

 

 

 

3.6. Диаграмма состояний (Statechart diagram)

 

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

Модель поведения позволяет  взглянуть на получаемый программный  объект со стороны, ведь основное назначение объектно-ориентированного программирования – создавать объекты, наделенные определенным поведением, которые в дальнейшем и будут производить работу в программном коде. А данный тип диаграмм позволяет четко представить все поведение полученного программного объекта в виде графических значков состояний. Пример диаграммы состояний приведен на рис. 18.

Рис. 22. Диаграмма состояний. Заполнение главной формы.

 

 

 

 

 

 

 

 

 

 

3.7. Диаграмма деятельности

 

Диаграмма действий (Activity diagram) описывает последовательность действий в системе с помощью  действий. Диаграммы действий являются специальной формой диаграмм состояний, только в основном содержат

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

Рис. 23. Диаграмма действий обработка заказа.

 

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

 

3.8. Диаграммы компонентов (Component diagram)

 

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