Файл: Моделирование предметной области «Управление запасами» с помощью UML (Построение объектной модели предметной области «Управление запасами» с применением языка моделирования UML).pdf

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

Так как построение моделей крайне важно при проектировании сложных систем, объектно-ориентированное проектирование предлагает богатый выбор моделей, (представлены на рис. 1.3.2)

Рис. 1.3.2 Объектно-ориентированные модели.

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

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

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

Type

TBook = class

Public

PagesCount: integer;

Title, Author: string;

function CompareWithBook(OtherBook: TBook): integer;

procedure ShowTitle;

constructor Create(NewTitle, NewAuthor: string; NewPagesCount: integer);

end;

Глава 2. Построение объектной модели предметной области «Управление запасами» с применением языка моделирования UML

2.1 Понятие языка UML

UML (Unified Modeling Language) – это унифицированный графический язык моделирования для описания, визуализации, проектирования и документирования объектно-ориентированных систем. UML призван поддерживать процесс моделирования программных средств на основе объектно-ориентированного подхода, организовывать взаимосвязь концептуальных и программных понятий, отражать проблемы масштабирования сложных систем. Модели на UML используются на всех этапах жизненного цикла программных средств, начиная с бизнес-анализа и заканчивая сопровождением системы. Разные организации могут применять UML по своему усмотрению в зависимости от своих проблемных областей и используемых технологий.

По запросу Object Management Group (OMG) – организации, ответственной за принятие стандартов в области объектных технологий и баз данных назревшая проблема унификации и стандартизации была решена авторами трех наиболее популярных объектно-ориентированных методов – Г.Бучем, Д.Рамбо и А.Джекобсоном, которые объединенными усилиями создали версию UML 1.1, утвержденную OMG в 1997 году в качестве стандарта.

На волне растущего интереса к UML к разработке новых версий языка в рамках консорциума UML Partners присоединились такие компании, как Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, Rational Software, Texas Instruments и Unisys. Результатом совместной работы стала спецификация UML 1.0, вышедшая в январе 1997 года. В ноябре того же года за ней последовала версия 1.1, содержавшая улучшения нотации, а также некоторые расширения семантики. UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005.

Формальная спецификация последней версии UML 2.0 опубликована в августе 2005 года. Семантика языка была значительно уточнена и расширена для поддержки методологии Model Driven Development — MDD. Последняя версия UML 2.4.1 опубликована в августе 2011 года. UML 2.4.1 принят в качестве международного стандарта ISO/IEC 19505-1, 19505-2.

Любой язык состоит из словаря и правил комбинирования слов для получения осмысленных конструкций. Так, в частности, устроены языки программирования, таковым является и UML. Отличительной его особенностью является то, что словарь языка образуют графические элементы. Каждому графическому символу соответствует конкретная семантика, поэтому модель, созданная одним разработчиком, может однозначно быть понята другим, а также программным средством, интерпретирующим UML. Отсюда, в частности, следует, что модель ПС, представленная на UML, может автоматически быть переведена на ОО язык программирования (такой, как Java, C++, VisualBasic), то есть, при наличии хорошего инструментального средства визуального моделирования, поддерживающего UML, построив модель, мы получим и заготовку программного кода, соответствующего этой модели.

Следует подчеркнуть, что UML – это именно язык, а не метод. Он объясняет, из каких элементов создавать модели и как их читать, но ничего не говорит о том, какие модели и в каких случаях следует разрабатывать. Чтобы создать метод на базе UML, надо дополнить его описанием процесса разработки ПС. Примером такого процесса является Rational Unified Process, который будет рассматриваться в последующих статьях.

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

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

Отношения показывают различные связи между сущностями. В UML определены следующие типы отношений:

• Зависимость показывает такую связь между двумя сущностями, когда изменение одной из них – независимой – может повлиять на семантику другой – зависимой. Зависимость изображается пунктирной стрелкой, направленной от зависимой сущности к независимой.
• Ассоциация – это структурное отношение, показывающее, что объекты одной сущности связаны с объектами другой. Графически ассоциация показывается в виде линии, соединяющей связываемые сущности.
• Обобщение – это отношение между сущностью-родителем и сущностью-потомком. По существу, это отношение отражает свойство наследования для классов и объектов. Обобщение показывается в виде линии, заканчивающейся треугольником, направленным к родительской сущности.
• Реализация – отношение между сущностью, определяющей спецификацию поведения (интерфейс) с сущностью, определяющей реализацию этого поведения (класс, компонент). Это отношение обычно используется при моделировании компонент и будет подробнее описано в последующих статьях.

Диаграммы. В UML предусмотрены следующие диаграммы:

• Диаграммы, описывающие поведение системы:
• Диаграммы состояний (State diagrams),
• Диаграммы деятельностей (Activity diagrams),
• Диаграммы объектов (Object diagrams),
• Диаграммы последовательностей (Sequence diagrams),
• Диаграммы взаимодействия (Collaboration diagrams);
• Диаграммы, описывающие физическую реализацию системы:
• Диаграммы компонент (Component diagrams);
• Диаграммы развертывания (Deployment diagrams).

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

UML обеспечивает.

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

Язык UML было бы затруднительно использовать при реальном моделировании программных средств без инструментальных средств визуального моделирования.

2.2 Описание функционирования предметной области «Управление запасами»

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

Выручка увеличилась на 9,09%, а товарные запасы на 12,12%. Соответственно, часть дохода «зависла» на складе в виде нереализованных товаров.

Just in time («точно в срок») – это наиболее распространённый и эффективный подход к ведению логистики. Его суть выражается очень просто: нужно организовать закупки товаров таким образом, чтобы:

Все материалы поступали точно в срок;

Точно в необходимом количестве, не более и не менее;

Точно в указанное место;

Точно к назначенному моменту.

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

Исследование, проведённое Hewlett-Packard – одним из лидеров в сфере внедрения Just in Time на Западе – показывает, что концепция даёт следующие результаты:

Снижение запасов готовой продукции на 75%;

Сокращение запасов незавершённого производства на 50%;

Хранимый объём непроизводственных запасов уменьшился с расчёта на 22 дня до 1 дня;

Время реализации продукции сократилось в среднем в 2 раза;

Продолжительность производственного цикла снизилась на 50%;

Производственные издержки уменьшились на 30%, что позволяет окупить затраты на внедрение системы Just in Time в течение 5-6 месяцев.

Всё перечисленное и делает систему «Точно в срок» самой распространённой логистической концепцией в мире.

Как организовать грамотное управление запасов?

Если реализация системы Just in time пока затруднительна – или уже имеют место проблемы с избыточным наличием материальных запасов – можете воспользоваться следующими рекомендациями:

Добейтесь сведения запасов материалов и сырья с высокой себестоимостью к минимуму;

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

Если какие-то запасы лежат на складе больше года – или если количество материала/сырья явно превышает необходимое на один год – избавляйтесь от излишков;

Если у вашей компании широкая номенклатура материалов, начинайте работать с теми запасами, которые составляют 80% от общей стоимости остатков;

Если вам предлагают скидку за объём, всегда сравнивайте её со стоимостью задействованного капитала. Даже если речь идёт не о кредите, а просто о приобретении лишнего запаса, вы выводите из оборота собственные средства – и теряете на этом;

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

Следуйте этим советам и стремитесь прийти к максимальной оборачиваемости материалов, что позволит использовать капитал с высокой эффективностью.

2.3 Построение предметной области «Управление запасами»

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