Файл: « Склад».pdf

2.1.3 Классы и объекты

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

Это приводит к четкому определению объекта, данному Смитом и Токи: "Объект представляет собой конкретный опознаваемый предмет, единицу или сущность, реальную или абстрактную, имеющую четко определенное функциональное назначение в данной предметной области" [1]. В еще более общем виде объекты могут быть определены как нечто, имеющее четко очерченные границы [11].

Сами по себе объекты не представляют особого интереса: только в ходе взаимодействия объектов реализуются системы.

По выражению Ингалса: "Вместо процессора, беззастенчиво перемалывающего структуры данных, мы получаем сообщество хорошо воспитанных объектов, которые вежливо просят друг друга об услугах". Самолет, по определению, "совокупность элементов, каждый из которых по своей природе стремится упасть на землю, но за счет совместных непрерывных усилий преодолевающих эту тенденцию" [1].

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

Особый интерес для объектно-ориентированного проектирования и анализа и представляют следующие типы иерархических соотношений объектов:

• связи;
• агрегация.

Старк и Зайдевиц назвали эти типы отношений отношениями "родитель/потомок" и старшинства соответственно [7].

Понятия классов и объектов настолько тесно связаны, что невозможно говорить об объектах безотносительно к их классам.

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

В общепонятных терминах может быть дано следующее определение класса: "группа, вид или множество с разновидностями, общими свойствами или общим свойством, возможностями, отличиями по качеству или условиями" [1].

В контексте объектно-ориентированного анализа дается следующее определение класса:

классом называют некое множество объектов, имеющих общую структуру и общее поведение.

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

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

Можно разделить интерфейс класса на три части:

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

Известны три основных типа отношений между классами [1].

Отношение "обобщение/специализация", общее и частное, известное как "is-a".

Отношение "целое/ часть", известное как "part of".

Семантические, смысловые отношения, ассоциации.

Языками программирования выработаны несколько общих подходов к выражению отношений этих трех типов.

Большинство объектно-ориентированных языков непосредственно поддерживают различные комбинации следующих видов отношений:[7]

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

Альтернативой наследованию является делегирование, при этом объекты рассматривают как прототипы, которыми делегируется свое поведение родственным им объектам. Таким образом, классы становятся не нужны [1].

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

2.2 Анализ требований

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

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

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

Все такие склады несут ответственность при учете товаров и выполнении заказов. С целью повышения эффективности своей работы склады обязаны сами поддерживать те списки товаров, которые в большей степени соответствуют потребностям местных рынков.[4]

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

Кроме этого, номенклатура может оперативно меняться в соответствии с изменяющимися требованиями клиентов.

Компании должны иметь на всех складах одинаковые системы учета.

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

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

По результатам системного анализа можно выделить следующие основные функции системы:[10]

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

Основные режимы использования системы:[4]

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

В каждый из основных сценариев может входить несколько вторичных:

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

Для таких сложных систем будут выявляться много основных сценариев и еще больше вторичных.[10]

Этот этап анализа может занимать много времени, пока не удастся добиться более или менее подробного уровня детализации.

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

На рисунке 1 представлен сценарий, в котором покупатель размещает свой заказ.[4]

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

• сведения о клиенте;
• база данных товаров;
• заявка на комплектование.

Этот список абстракций формируется на этапе рассмотрения сценариев работы.

начало

клиент звонит в отдел заказов

менеджер заносит данные клиента

клиент

зарегистрирован?

Да

Нет

менеджер просматривает данные

менеджер делает новую запись

менеджер формирует заказ

менеджер записывает новый заказ

менеджер получает номер заказа

менеджер сообщает номер заказа клиенту

менеджер выписывает расходную накладную кладовщику

конец

Рисунок 1 - сценарий заказа

Рисунок 2 отражает продолжение сценария, представленного на рисунке 1.[4]

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

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

начало

кладовщик получает расходную накладную

кладовщик формирует заказ

кладовщик передает заказ службе доставки

служба доставки передает заказ клиенту

служба доставки передает расходную накладную кладовщику

конец

клиент расписывается в накладной

Рисунок 2 - сценарий выполнения заказа

2.3 Проектирование

При составлении каждого из рассмотренных в предыдущем разделе сценариев требуется ответить на ряд вопросов:[10]

• Какой объект будет нести ответственность за выполнение того или иного действия?
• Как объект будет проводить ту или иную операцию: самостоятельно или используя свойства другого объекта?
• Не слишком ли много операций вменяется в круг обязанностей данного объекта? Что произойдет при ошибке в ходе выполнения сценария?
• Что случится, если будут нарушены некоторые предусловия?

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

• информация о клиенте;
• информация о товаре;
• информация о поставщике;
• заказ;
• расходная накладная;
• документ на отгрузку.

Основной сущностью в проектируемой системе является товар.

Товар хранится на складе.

Товар, лежащий на складе, кроме того, что связан со складом, еще характеризуется количеством.

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

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

Диаграмма классов, от англ. class diagram, служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования.[5]

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

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