Реализация продукции на основе 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 допускается использование произвольной комбинации букв, цифр и даже знаков препинания. Однако на практике рекомендуется использовать в качестве имен классов короткие и осмысленные прилагательные и существительные, каждое из которых начинается с заглавной буквы.

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

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

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

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

В диаграмме классов могут участвовать связи трех разных категорий: зависимость (dependency), обобщение (generalization) и ассоцирование (association). Для проектирования реляционных БД наиболее важны вторая и третья категории связей. Поэтому по поводу связей-зависимостей мы будет очень кратки.

 

Связи-зависимости 

 

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

 

Связи-обобщения 

 

Связью-обобщением называется связь  между общей сущностью, называемой суперклассом, или родителем, и более  специализированной разновидностью этой сущности, называемой подклассом, или потомком. Обобщения иногда называют связями “is a”, имея в виду, что класс-потомок является частным случаем класса-предка. Класс-потомок наследует все атрибуты и операции класса-предка, но в нем могут быть определены дополнительные атрибуты и операции.