Файл: Моделирование предметной области «Учет продаж» с помощью UML.pdf

В описании UML используются три языковых уровня:

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

Основная идея описания UML вполне традиционна и согласуется с общепринятой практикой: мета-метамодель — это описание используемого формализма; метамодель — это и есть собственно описание языка (элементов моделирования); там, где формализм не срабатывает, на помощь приходит естественный язык и все это сопровождается примерами фрагментов моделей.

1.3 Диаграммы языка UML

В UML используются следующие виды диаграмм:

• Диаграмма использования
• Диаграмма классов
• Диаграмма объектов
• Диаграмма состояний
• Диаграмма деятельности
• Диаграмма последовательности
• Диаграмма кооперации
• Диаграмма компонентов
• Диаграмма размещения

Канонические диаграммы отнюдь не образуют полного ортогонального набора: они пересекаются как по включенным в них средствам, так и по области применения. Более того, некоторые из них являются частными случаями других, есть просто семантические эквивалентные пары, можно привести примеры допустимых диаграмм, для которых затруднительно указать однозначно, к какому именно из канонических типов диаграмма относится.

Сказанное можно проиллюстрировать условной классификацией диаграмм, приведенной на рис. 2.

Рисунок 2 - Иерархия типов диаграмм

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

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

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

Основные элементы нотации, применяемые на диаграмме использования, показаны на рис.3.

Рисунок 3 - Нотация диаграммы использования (UML 2.0)

Диаграмма классов — основной способ описания структуры системы. Это не удивительно, поскольку UML сильно объектно-ориентированный язык, и классы являются основным (если не единственным) «строительным материалом» системы. На диаграмме классов применяются один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:

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

Основные элементы нотации, применяемые на диаграмме классов, показаны на рис. 4.

Рисунок 4 - Нотация диаграммы классов

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

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

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

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

Диаграмма последовательности — это способ описать поведение системы «на примерах». Фактически, диаграмма последовательности — это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является посылка сообщений взаимодействующими объектами. Именно последовательность посылки сообщений отображается на данной диаграмме, отсюда и название.

Диаграмма кооперации, которая в UML 2 переименована в диаграмму коммуникации, семантически эквивалентна диаграмме последовательности. Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих объектов, только выраженное другими графическими средствами. Более того, большинство инструментов умеет автоматически преобразовывать диаграммы последовательности в диаграммы кооперации и обратно. Такое преобразование является взаимно-однозначным.

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

• реализации между компонентами и интерфейсами (компонент реализует интерфейс);
• зависимости между компонентами и интерфейсами (компонент использует интерфейс);
• зависимости между объектами и компонентами (объект входит в компонент).

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

Достоинства и недостатки объектно-ориентированного подхода

Рассмотрим достоинства объектно-ориентированного программирования.

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

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

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

4. ООП дает возможность создавать расширяемые системы. Компоненты могут быть добавлены на этапе исполнения программы.

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

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

7. Реализация работы с наследниками. Алгоритмы можно обобщить настолько, что они уже смогут работать более чем с одним видом объектов.

8. Создание «каркаса». Независимые от приложения части предметной области могут быть реализованы в виде набора универсальных классов, или каркаса (framework).

9. Сокращается время на разработку.

Компоненты многоразового использования обычно содержат гораздо меньше ошибок, чем вновь разработанные.

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

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

Одако ООП имеет и недостатки.

1. Документирование классов — ресурсоёмкая задача.

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

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

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

4. Неэффективность на этапе выполнения, в т.ч. инкапсуляция данных.

5. Неэффективность в смысле распределения памяти.

6. Излишняя универсальность.

ПРАКТИЧЕСКАЯ ЧАСТЬ

1.4 Спецификация требований к «Учёт продаж»

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

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

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

• Стратегический менеджмент, в том числе и стратегический маркетинг
• Управление товарами, в том числе и тактический маркетинг
• Управление магазинами
• Управление операциями (административный менеджмент).

Рисунок 5 - Функциональная организационная диаграмма

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

Рисунок 6 - Организационная структура технологии сырья и реализации готовой продукции ООО «Компьютерный мир»

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

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

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

Рисунок 7 - Диаграмма вариантов использования учета продаж в магазине