Файл: Моделирование предметной области «Учёт продаж» с помощью UML.pdf
Добавлен: 23.04.2023
Просмотров: 232
Скачиваний: 2
Сказанное можно проиллюстрировать условной классификацией диаграмм, приведенной на рис. 2.
Рисунок 2 - Иерархия типов диаграмм
Диаграмма использования — это наиболее общее представление функционального назначения системы. Диаграмма использования призвана ответить на главный вопрос моделирования: что делает система во внешнем мире? На диаграмме использования применяются два типа основных сущностей: варианты использования и действующие лица, между которыми устанавливаются следующие основные типы отношений:
• ассоциация между действующим лицом и вариантом использования;
• обобщение между действующими лицами;
• обобщение между вариантами использования;
• зависимости (различных типов) между вариантами использования.
Кроме того, на диаграмме использования можно применить специальный графический комментарий — обозначить границу системы (действующие лица находятся снаружи, а варианты использования — внутри), если это почему-либо неочевидно.
Основные элементы нотации, применяемые на диаграмме использования, показаны на рис.3.
Рисунок 3 - Нотация диаграммы использования
Диаграмма классов — основной способ описания структуры системы. Это не удивительно, поскольку UML сильно объектно-ориентированный язык, и классы являются основным (если не единственным) "строительным материалом" системы. На диаграмме классов применяются один основной тип сущностей: классы (включая многочисленные частные случаи классов: интерфейсы, типы, классы-ассоциации и многие другие), между которыми устанавливаются следующие основные типы отношений:
• ассоциация между классами (с множеством дополнительных подробностей);
• обобщение между классами;
• зависимости (различных типов) между классами и интерфейсами.
Основные элементы нотации, применяемые на диаграмме классов, показаны на рис. 4.
Рисунок 4 - Нотация диаграммы классов
Диаграмма объектов — это частный случай диаграммы классов. Диаграммы объектов имеют вспомогательный характер — по сути это примеры (можно сказать дампы памяти), показывающие, какие имеются объекты и связи между ними в некоторый конкретный момент функционирования системы.
На диаграмме объектов применяют один основной тип сущностей: объекты (экземпляры классов), между которыми указываются конкретные связи (экземпляры ассоциаций).
Диаграмма состояний — это основной способ детального описания поведения в UML. В сущности, диаграммы состояний представляют собой граф состояний и переходов конечного автомата, нагруженный множеством дополнительных деталей и подробностей.
Диаграмма деятельности — это, фактически, старая добрая блок-схема алгоритма, в которой модернизированы обозначения, а семантика согласована с современным объектно-ориентированным подходом, что позволило органично включить диаграммы деятельности в UML.
Диаграмма последовательности — это способ описать поведение системы "на примерах". Фактически, диаграмма последовательности — это запись протокола конкретного сеанса работы системы (или фрагмента такого протокола). В объектно-ориентированном программировании самым существенным во время выполнения является посылка сообщений взаимодействующими объектами. Именно последовательность посылки сообщений отображается на данной диаграмме, отсюда и название.
Диаграмма кооперации, которая в UML 2 переименована в диаграмму коммуникации, семантически эквивалентна диаграмме последовательности. Фактически, это такое же описание последовательности обмена сообщениями взаимодействующих объектов, только выраженное другими графическими средствами. Более того, большинство инструментов умеет автоматически преобразовывать диаграммы последовательности в диаграммы кооперации и обратно. Такое преобразование является взаимно-однозначным.
Диаграмма компонентов — это, фактически, список артефактов, из которых состоит моделируемая система, с указанием некоторых отношений между артефактами. Наиболее существенным типом артефактов программных систем являются программы. Таким образом, на диаграмме компонентов основной тип сущностей — это компоненты (как исполнимые модули, так и другие артефакты), а также интерфейсы (чтобы указывать взаимосвязь между компонентами) и объекты (входящие в состав компонентов). На диаграмме компонентов применяются следующие отношения:
• реализации между компонентами и интерфейсами (компонент реализует
интерфейс);
• зависимости между компонентами и интерфейсами (компонент использует интерфейс);
• зависимости между объектами и компонентами (объект входит в компонент).
Диаграмма размещения немногим отличается от диаграммы компонентов. Фактически, наряду с отображением состава и связей компонентов здесь показывается, как физически размещены компоненты на вычислительных ресурсах во время выполнения. Таким образом, на диаграмме размещения, по сравнению с диаграммой компонентов, добавляется один тип сущностей — узел (может быть как классификатор, описывающий тип узла, так и конкретный экземпляр), а также отношение ассоциации между узлами, показывающее, что узлы физически связаны во время выполнения.
Достоинства и недостатки объектно-ориентированного подхода
Рассмотрим достоинства объектно-ориентированного программирования.
1. Классы позволяют проводить конструирование из полезных компонентов, обладающих простыми инструментами, что позволяет абстрагироваться от деталей реализации.
2. Данные и операции над ними образуют определенную сущность, и они не разносятся по всей программе, а описываются вместе. Локализация кода и данных улучшает наглядность и удобство сопровождения программного обеспечения.
3. Инкапсуляция позволяет привнести свойство модульности, что облегчает распараллеливание выполнения задачи между несколькими исполнителями и обновление версий отдельных компонентов.
4. ООП дает возможность создавать расширяемые системы. Компоненты могут быть добавлены на этапе исполнения программы.
5. Обработка разнородных структур данных. Программы могут работать, не различая вида объектов, что существенно упрощает код. Новые виды могут быть добавлены в любой момент.
6. Изменение поведения во время исполнения. На этапе исполнения один объект может быть заменен другим, что позволяет легко, без изменения кода, адаптировать алгоритм в зависимости от того, какой используется объект.
7. Реализация работы с наследниками. Алгоритмы можно обобщить настолько, что они уже смогут работать более чем с одним видом объектов.
8. Создание «каркаса». Независимые от приложения части предметной области могут быть реализованы в виде набора универсальных классов, или каркаса (framework).
9. Сокращается время на разработку.
Компоненты многоразового использования обычно содержат гораздо меньше ошибок, чем вновь разработанные.
Когда некий компонент используется сразу несколькими клиентами, улучшения, вносимые в его код, одновременно оказывают положительное влияние и на множество работающих с ним программ.
Если программа опирается на стандартные компоненты, ее структура и пользовательский интерфейс становятся более унифицированными.
Одако ООП имеет и недостатки.
1. Документирование классов — ресурсоёмкая задача.
В сложных иерархиях классов поля и методы обычно наследуются с разных уровней. И не всегда легко определить, какие поля и методы фактически относятся к данному классу. Для получения такой информации нужны специальные инструменты, вроде навигаторов классов.
2. Методы, как правило, короче процедур, зато их намного больше. В коротких методах легче разобраться, но они неудобны тем, что код для обработки сообщения иногда «размазан» по многим маленьким методам.
3. Злоупотребление инкапсуляцией данных. Чем больше логики и данных скрыто в недрах класса, тем сложнее его расширять.
4. Неэффективность на этапе выполнения, в т.ч. инкапсуляция данных.
5. Неэффективность в смысле распределения памяти.
6. Излишняя универсальность.
ПРАКТИЧЕСКАЯ ЧАСТЬ
Спецификация требований к «Учёт продаж»
На первом этапе проектирования информационной системы необходимо выполнить анализ предметной области, т.е. определить объекты предметной области и связи между объектами.
При выборе состава и структуры предметной области возможны два подхода: функциональный и предметный.
Функциональный подход реализует принцип движения «от задач» и применяется, когда определен комплекс задач, для обслуживания которых создается информационная система. В этом случае можно выделить минимальный необходимый набор объектов предметной области, которые должны быть описаны.
В предметном подходе объекты предметной области определяются с таким расчетом, чтобы их можно было использовать при решении множества разнообразных, заранее не определенных задач.
Предметной областью называется часть реальной системы, представляющая интерес для данного исследования. При проектировании автоматизированных информационных систем предметная область отображается моделями данных нескольких уровней. Число уровней зависти от сложности решаемых задач, но в любом случае включает концептуальный и логический уровни. [2]
В данной курсовой работе предметной областью является работа автосалона.
Задачей курсовой работы является автоматизация работы автосалона, который занимается продажей автомобилей. Автоматизации подлежат составление актов купли-продажи, торговые чеки, накладные, продажа автомобилей. Автоматизированный учет должен осуществляться на основании данных и документов: закупка товара со склада, стоимость, численность товара, паспортные данные клиентов и.т.д.
Диаграмма вариантов использования
Этот вид диаграмм позволяет создать список операций, которые выполняет система. Часто этот вид диаграмм называют диаграммой функций, потому что на основе набора таких диаграмм создается список требований к системе и определяется множество выполняемых системой функций. Каждая такая диаграмма или, как ее обычно называют, каждый Use case – это описание сценария поведения, которому следуют действующие лица (Actors)
Данный тип диаграмм используется при описании бизнес процессов автоматизируемой предметной области, определений требований к будущей программной системе. Отражает объекты, как системы, так и предметной области и задачи, ими выполняемые.
Диаграмма вариантов использования (рис.5) показывает структуру и движение информационных потоков между актерами автосалона: новыми покупателями, постоянными покупателями, оптовыми покупателями и сотрудниками.
Рисунок 5 - Диаграмма вариантов использования автосалона
Данная диаграмма представляет собой совокупность актеров, вариантов использования и связей между ними. Каждый актер – это некая отдельная роль относительно конкретного варианта использования. Актерами выступают конкретные сотрудники, а также действующие клиенты. На диаграмме отображается поведение системы, то есть что система будет делать.
Главный актером является Сотрудник, так как он взаимодействует со всеми покупателями, напрямую или через посредников.
Весь автосалон по продаже автомобилей и действия персонала направлены на удовлетворение запросов клиентов.
Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.
Диаграмма Классов должна выглядеть как на рисунке 6.
Рисунок 6 - Диаграмма классов
Диаграмма последовательности действий
Взаимодействие объектов в системе происходит посредством приема и передачи сообщений объектами-клиентами и обработки этих сообщений объектами-серверами. При этом в разных ситуациях одни и те же объекты могут выступать и в качестве клиентов, и в качестве серверов. Данный тип диаграмм позволяет отразить последовательность передачи сообщений между объектами.