Файл: Моделирование предметной области «Учет продаж» с помощью UML (Выбор средства для моделирования предметной области решаемой задачи).pdf
Добавлен: 28.06.2023
Просмотров: 79
Скачиваний: 3
Язык UML не определяет стандарт процесса. Его авторы признают, что важное значение имеют как надежный язык моделирования, так и сам процесс разработки. Они лишь приводят свои рекомендации относительно организации процесса в отдельных не относящихся к UML публикациях, поскольку стандартизация процесса разработки программных систем выходит за рамки языка UML. Следование стандартам процесса разработки Приложений не играет основной роли в создании Системы. Разработчику гораздо важнее обладать навыками создания хороших проектов.
Для этого необходимо освоить ряд принципов и эвристик, связанных с идентификацией и выделением основных абстрактных объектов, а также с распределением обязанностей между ними. Предлагаемые этапы разработки и модели — это лишь иллюстрация многообразия процесса разработки программного обеспечения с использованием объектной технологии, а не готовая формула. Предлагаемые примеры видов деятельности можно рассматривать в качестве отправной точки для обсуждения и выработки удобного процесса разработки, а также для экспериментирования с ним. Обычно описание процесса включает в себя все виды деятельности, от формулировки требований к системе до вопросов ее распространения. Кроме того, зачастую полное описание процесса включает более широкий круг вопросов, связанных с автоматизацией процесса разработки программного обеспечения, определением долгосрочного жизненного продукта, документированием, поддержкой и обучением персонала, распараллеливанием работ и их координацией между отдельными группами. Мы сосредоточимся лишь на основных видах деятельности, уделяя вопросам взаимодействия групп разработчиков лишь незначительное внимание. Некоторые существенные этапы процесса разработки останутся вне нашего внимания, а именно: планирование, параллельное взаимодействие групп разработчиков, управление проектом, документирование и тестирование. Язык UML позволяет стандартизировать артефакты и систему обозначений, но не определяет стандарт процесса разработки. Это объясняется следующими причинами.
1. Стандартную систему обозначений можно использовать при создании систем самого различного назначения, процесс разработки которых может отличаться от стандартного.
2. Процесс разработки системы может зависеть от множества факторов, таких как квалификация специалистов, доля творчества в общем процессе, природа проблемы, средства ее решения и т.д.
Здесь будут рассмотрены лишь общие принципы и типичные этапы успешного процесса разработки программных систем. На высоком уровне можно выделить следующие основные этапы разработки программного приложения:
1. Планирование — планирование, определение требований, создание прототипов и т.д.
2. Построение — конструирование системы.
3. Развертывание — ввод системы в действие. Итеративный процесс разработки
Итеративный жизненный цикл программного продукта основывается на успешной доработке и усложнении системы в процессе нескольких циклов анализа, проектирования, реализации и тестирования. Развитие системы обусловливается добавлением в каждом цикле разработки новых функций. По завершении предварительного этапа планирования система продолжает разрабатываться на этапе построения в течение нескольких циклов разработки. В каждом цикле решаются задачи удовлетворения небольшого количества требований к системе в процессе анализа, проектирования, построения и тестирования.
При выполнении каждого из таких циклов система постепенно совершенствуется. Такая стратегия разработки противоречит классическому пониманию жизненного цикла, в котором каждый из видов деятельности (анализ, проектирование и т.д.) выполняется лишь один раз с целью удовлетворения всего набора требований к системе. Можно выделить следующие преимущества итеративного процесса разработки. • Эффективность преодоления сложности поставленной задачи • Быстрая обратная связь, обеспечиваемая коротким временем реализации каждого из элементарных циклов Полезной стратегией при выполнении каждого цикла разработки является выделение для него определенных временных рамок — краткого фиксированного времени (к примеру, четыре недели). В течение этого временного интервала должна быть выполнена вся работа по реализации цикла. В качестве временных рамок следует выбирать диапазон от двух недель до двух месяцев. Более краткий период не позволит выполнить сложные задачи, а при выборе более длительных интервалов удлиняется период обратной связи, что затрудняет преодоление сложности поставленной задачи.
2.2 Информационная модель и ее описание
Информационная модель системы, разрабатываемой для реализации операций бизнес-процесс, будет состоять из справочников и таблиц, информация в которые заносится автоматически при работе пользователя с экранными формами. Выделены следующие справочники:
- Справочник товаров;
- Справочник покупателей;
- Справочник сотрудников;
- Справочник покупок.
Информационная модель изображена на рисунке 3.
Рисунок 3. Информационная модель
Моделирование предметной области решаемой задачи с использованием объектно-ориентированного подхода к проектированию
Прецедент – это словесное описание некоторого процесса из предметной области, например заказ книг из библиотеки. Последовательные циклы разработки определяются требованиями прецедентов Цикл разработки призван реализовать один или несколько прецедентов либо упрощенных версий прецедентов. Некоторые циклы разработки (особенно на ранних этапах) должны быть посвящены выполнению не только очевидных, но и неочевидных требований, таких как создание служб поддержки (надежного функционирования, безопасности и т.д.) Прецеденты необходимо ранжировать и реализовывать на более ранних стадиях разработки прецеденты с более высоким приоритетом.
Диаграмма прецедентов, как правило, отражает требования к системе с точки зрения пользователя. Таким образом, прецеденты – это функции, выполняемые системой, а действующие лица – это заинтересованные лица по отношению к создаваемой системе. Такие диаграммы показывают, какие действующие лица инициируют прецеденты.
Рассмотрим диаграмму прецедентов «Магазин компьютерной техники». На Рисунке 3 приведена диаграмма прецедентов для рассматриваемого примера.
Рисунок 4. Диаграмма прецедентов «учет продаж»
В этом примере можно выделить следующие субъекты и соответствующие им прецеденты:
Директор – запрашивает работнику о состояния магазина (прецедент «Запрос о состоянии магазина») и работник передаёт эти отчеты в одном отчете ( прецедент «Отчет о состоянии магазина») .
Продавец - работает с клиентами: продает товар (прецедент «Продажа товара»); проявляет инициативу к клиенту (прецедент «Запрос клиента»); отвечает на вопросы клиента (прецедент «Проверка наличия товара»); отвечает за прием товара (прецедент «Склад»).
Поставщик - заинтересован в реализации прецедента («Склад»), как выдача товара, но не является основным или вспомогательным исполнителем.
Клиент - вынуждает продавца инициировать один из прецедентов..
Клиенты не будут иметь непосредственного доступа к разрабатываемой системе (второстепенный субъекты), однако именно они является основным источником событий, инициализирующих прецеденты, и получателем результата работы прецедентов.
Диаграмма последовательности позволяет отразить последовательность передачи сообщений между объектами. Обычно используются для моделирования потоков управления путем упорядочения по времени.
Диаграммы последовательности это диаграммы взаимодействия, которые подчеркивают упорядоченность сообщений по времени. Диаграммы последовательности показывают множество объектов и сообщений, посылаемых и получаемых этими объектами.
Объекты – это обычно именованные или анонимные экземпляры (instances) классов, однако они могут также представлять экземпляры других элементов (things), таких как кооперации, компоненты и узлы. Диаграммы последовательности используются для иллюстрации динамического представления (view) системы.
Данная диаграмма (Рисунок 4) иллюстрирует упорядоченный поток данных, которые передается в AIS, а она в свою очередь в отчеты. На диаграмме представлены классы: продавец, кассир, отдел заявок и претензий, склад, AIS, отчеты, которые входят в данное действие.
Рисунок 5. Диаграмма последовательности «Учет продаж»
Диаграммы состояний (Statechart diagrams) используются для описания поведения сложных систем. На диаграммах состояний представлен автомат, включающий в себя состояния, переходы, события и виды действий. Диаграммы состояний относятся к динамическому виду системы; особенно они важны при моделировании поведения интерфейса, класса или кооперации. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий. Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах.
Прямоугольниками представляются состояния, через которые проходит объект во время своего поведения. Состояниям соответствуют определенные значения атрибутов объектов. Стрелки представляют переходы от одного состояния к другому, которые вызываются выполнением некоторых функций объекта. Имеется также два вида псевдо-состояний: начальное состояние, в котором находится только что созданный объект, и конечное состояние, которое объект не покидает, как только туда перешел.
Рисунок 6. Диаграмма состояний процесса «Учет продаж»
Диаграмма деятельности - это частный случай диаграммы состояний; на ней представлены переходы потока управления от одной деятельности к другой внутри системы. Диаграммы деятельности относятся к динамическому виду системы; они наиболее важны при моделировании ее функционирования и отражают поток управления между объектами. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов.
Основными элементами диаграмм деятельности являются:
•овалы, изображающие действия объекта;
• линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия "И"};
• ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия "ИЛИ");
• стрелки — отражают последовательность действий, могут иметь метки условий.
На диаграмме деятельности могут быть представлены действия, соответствующие нескольким вариантам использования. На таких диаграммах появляется множество начальных точек, поскольку они отражают теперь реакцию системы на множество внешних событий. Таким образом, диаграммы деятельности позволяют получить полную картину поведения системы и легко оценивать влияние изменений в отдельных вариантах использования на конечное поведение системы.
Данная диаграмма иллюстрирует переход из состояния в состояние, необходимые для создания и отправки заявки. Началом для заказа является обращение клиента к прайсу, зависимости о наличии товара идет разветвление действий. Если товар есть, то продавец выписывает заявку, кассир подтверждает продажу и данные о товар сразу переходит в AIS для повторного заказа, иначе клиент по прайсу заказывает товар через отдел заявок и претензий, которые отправляет в AIS, что необходимо заказать.
Рисунок 7. Диаграмма деятельности «Учет продаж»
Класс (class) - категория вещей, которые имеют общие атрибуты и операции.
Продолжая тему, скажем, что классы - это строительные блоки любой объектно-ориентированной системы. Они представляют собой описание совокупности объектов с общими атрибутами, операциями, отношениями и семантикой. При проектировании объектно-ориентированных систем диаграммы классов обязательны.
Классы используются в процессе анализа предметной области для составления словаря предметной области разрабатываемой системы. Это могут быть как абстрактные понятия предметной области, так и классы, на которые опирается разработка и которые описывают программные или аппаратные сущности.
Диаграмма классов - это набор статических, декларативных элементов модели. Диаграммы классов могут применяться и при прямом проектировании, то есть в процессе разработки новой системы, и при обратном проектировании - описании существующих и используемых систем. Информация с диаграммы классов напрямую отображается в исходный код приложения - в большинстве существующих инструментов UML-моделирования возможна кодогенерация для определенного языка программирования. Таким образом, диаграмма классов - конечный результат проектирования и отправная точка процесса разработки.
На данной диаграмме (см. рис. №4) представлено 11 классов: клиент, продавец, реестр клиентов, прайс, кассир, отчеты, отдел заявок и претензий, AIS, генератор заказов, поставщик и склад.
Каждому классу присвоен свой стереотип, характеризующий его функциональность. Граничные классы – клиент и поставщик, т.е. классы, расположенные на границе системы и всей окружающей среды. Управляющий класс-AIS, т.е. отвечает за координацию действий других классов. Классы-сущности – реестр клиентов, прайс, кассир, отчеты, отдел заявок и претензий, генератор заказов, поставщик и склад.
Для каждого класса определены свои связи, атрибуты и операции с указанием типов. Все связи диаграммы – это связи зависимости.