Реализация продукции на основе Case-средств

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

    Характеристика  пользователя 

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

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

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

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

    Характеристика  продукта 

    Предлагаемый  программный продукт предназначен для решения задачи «Учет реализованной продукции по отгрузке».

    Функции приложения:

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

    - организация поиска в базе  данных;

    - расчет реализованной продукции на дату;

    - контроль полученных результатов  и анализ;

    - формирование отчетов для передачи  в подразделения филиала (административно-хозяйственный  отдел, департамент торговли, директору филиала. Организационная структура управления представлена в Приложении 7);

    - настройка системы на конкретного  исполнителя;

    - взаимодействие  в реальном масштабе времени  с внешними системами.

    3.1.2. Модель прецедентов 

    Прецеде́нт (англ. Use Case, а также: вариант использования, сценарий использования) — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс, взаимодействуя с внешними актёрами . В понятие «актер» входят люди, компьютерные системы и процессы. Прецедент описывает взаимодействие программной системы с актерами в виде последовательности сообщений.

    Прецеденты  были предложены Иваром Якобсоном и  значительно популяризированы Алистером Коберном.

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

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

    Один  и тот же прецедент может быть описан с различной степенью детализации.

    В международном стандарте UP модель прецедентов  – результат анализа функциональных требований.

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

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

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

      

    Рис.2 Диаграмма прецедентов 
 

    Развернутое описание процесса (прецедента «Расчет реализованной продукции по отгрузке»)

    Основной  исполнитель: бухгалтер.

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

    Предварительные условия:

1. подготовлена первичная информация о совершении хозяйственных операций;
2. в архиве хранятся документы за 3 года (выписки банка с подложенными к ним платежными поручениями, товарно-транспортные накладные и счета-фактуры, договоры, приложения к договорам);
3. организация осуществляет свою деятельность в строгом соответствии с условиями договора;
4. бухгалтер идентифицирован и аутентифицирован.

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

    Основной  успешный сценарий:

1. Бухгалтер выбирает и запускает запрос на формирование отчета о реализованной продукции за период.
2. Система проводит расчёт реализованной продукции в натуральном и стоимостном выражениях, формирует отчет.
3. Бухгалтер выполняет процедуру визуального контроля отчета.
4. Бухгалтер выводит документ на печать.

          Расширения (альтернативные потоки событий):

    2а.  Система вышла из строя. 

    1. Бухгалтер перезагружает систему, регистрируется, инициирует восстановление прерванного состояния.

    2. Система восстанавливает прерванное  состояние.

    2а.  Система определяет причину сбоя.

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

    2б.  Система выдает ошибку, не выполняет  запрос.

    1. Бухгалтер устраняет ошибку (например, исправляет интервал дат). Если  самостоятельно устранить ошибку  не получается, обращается к работнику  ИТ-отдела.

    2. После устранения ошибки заново  выполняется запрос на формирование  отчета.

    3а.  Отчет сформирован с ошибкой.

1. Бухгалтер проверяет правильность отображения первичной информации в системе.

    2а.  Вводятся корректировки в аналитику  счетов и субсчетов. 

    2б.  Вводятся корректировки в отражения данных по синтетическому субсчету.

    4а.  Документ не выводится на печать.

    1а.  Не настроена форма для печати. Бухгалтер обращается в ИТ-отдел,  работники которого осуществляют  нужные настройки системы.

    1б.  Проблема с оргтехникой. Бухгалтер выполняет устранение неполадок (кончилась бумага в лотке принтера, принтер не подключен к компьютеру и пр.). Если самостоятельно устранить неполадки не получается, бухгалтер обращается к сотрудникам ИТ-отдела.

    2. Документ повторно выводится  на печать.

    Список  технологий и типов  данных:

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

    Специальные требования:

    - Отклик системы (выполнение запроса)  приходит в течение минуты.

    - Быстрое восстановление информации  в случае сбоя системы.

    Частота использования: равна числу запросов в сутки + раз в четыре недели (по регламенту). 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

    3.2.Объектно-ориентированное  проектирование

    Объектно-ориентированное  проектирование (Object-Oriented Design - OOD) - это  поступательный итеративный процесс. Граница между объектно-ориентированным анализом и проектированием расплывчата и построение проекта программного изделия состоит из ряда циклов, в которых уточняются описания классов и взаимодействия между ними, разрабатываются реализующие их программы, проводится их отладка и тестирование и по результатам каждого этапа уточняются рабочие документы предыдущих этапов, дорабатываются описания классов и программы. Эти циклы повторяются до получения требуемого результата.

    Процесс объектно-ориентированного проектирования состоит из циклического выполнения четырех основных шагов:

    - Определение  классов и объектов на определенном  уровне абстракции.

    - Определение  семантики классов.

    - Определение  (идентификация) связей между  классами и объектами.

    - Реализация классов.

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

    3.2.1. Диаграмма концептуальных  классов

    Диаграммой  классов в терминологии UML называется диаграмма, на которой показан набор  классов (и некоторых других сущностей, не имеющих явного отношения к проектированию БД), а также связей между этими классами (иногда термин relationship переводится на русский язык не как “связь”, а как “отношение”). Кроме того, диаграмма классов может включать комментарии и ограничения. Ограничения могут неформально задаваться на естественном языке или же могут формулироваться на языке OCL (Object Constraints Language), который является частью общей спецификации UML, но, в отличие от других частей языка, имеет не графическую, а линейную нотацию. Мы затронем эту тему ниже немного более подробно.

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