Файл: Моделирование предметной области «Учет товаров» с помощью UML (Описание предметной области).pdf
Добавлен: 01.04.2023
Просмотров: 239
Скачиваний: 1
– выполнять резервирование товаров и контроль оплаты;
– вести учет денежных средств на расчетных счетах и в кассе;
– вести учет товарных кредитов и контроль их погашения;
– вести учет переданных на реализацию товаров, их возврат и оплату.
Основное назначение средств работы с распределенными информационными базами - организация единой системы автоматизированного учета на предприятиях, имеющих территориально удаленные объекты: филиалы, склады, магазины, пункты приема заказов и иные подобные подразделения, не связанные локальной сетью:
– ведение неограниченного количества автономно работающих информационных баз;
– полная или выборочная синхронизация данных;
– настройка состава синхронизируемых данных;
– произвольный порядок и способ передачи изменений.
Использование средств управления распределенными информационными базами не ограничивает действия пользователей системы. Все изменения данных система отслеживает автоматически и передает их в соответствии с описанными правилами синхронизации.
«1С:Торговля и склад» содержит средства обеспечения сохранности и непротиворечивости информации:
– возможность запрещения пользователям "прямого" удаления информации;
– специальный режим удаления данных с контролем перекрестных ссылок;
– возможность запрещения пользователям редактировать данные за прошлые отчетные периоды;
– установка запрета на редактирование печатных форм документов;
– «запирание» системы пользователем при временном прекращении работы.
Таким образом, анализ возможностей системы «1С:Торговля и склад» показал, что она является мощным средством автоматизации складской информации. В тоже время, текущая стадия автоматизации компании требует внедрения менее развитой системы, позволяющей автоматизировать четко очерченный круг складских задач.
Понятие жизненного цикла информационной системы является одним из базовых в программной инженерии. Жизненный цикл автоматизированной информационной системы в полной мере определяется как определенный период времени, который начинается с момента непосредственного принятия решения о разработки необходимости разработки информационной системы и заканчивается в тот момент, когда его полного изъятия из непосредственной эксплуатации [15].
Основным нормативным документом, который позволяет регламентировать состав процессов жизненного цикла информационной системы, является международный стандарт ISO/IEC 12207: 1995 «Information Technology - Software Life Cycle Processes» (ISO - International Organization for Standardization, IЕС - International Electrotechnical Commission).
Структура жизненного цикла информационной системы по стандарту ISO/IEC 12207 базируется на следующих группах процессов:
– основные процессы жизненного цикла информационной системы (приобретение, поставка, разработка, эксплуатация, последующее сопровождение);
– вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
– организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого жизненного цикла информационной системы, обучение) [17].
Представленная модель является каскадной, в которой основной характеристикой является разбиение всей разработки на этапы, причем переход с одного этапа разработки информационной системы наследующий происходит, только после того, как будет полностью завершена работа на текущем этапе.
Каждый этап завершается выпуском полного комплекта документации. Однако в процессе создания информационной системы постоянно возникает потребность в возврате к предыдущим этапам и уточнении или пересмотре ранее принятых решений.
Положительные стороны применения каскадного подхода заключаются в следующем: на каждом отдельном этапе формируется законченный набор проектной документации, отвечающий критериям полноты и согласованности; выполняемые в логичной последовательности этапы работ позволяют планировать сроки завершения всех работ и соответствующие затраты.
Можно выделить несколько этапов в существующей схеме планирования задач. В качестве первого этапа возьмем анализ стратегии развития бизнеса. Предприятия, чьи стратегии в бизнесе объединены со стратегиями в области информационных технологий, как правило, занимают лидирующие позиции в условиях конкуренции. Подбор определенного набора пакетов некоторых поставщиков, удовлетворяющих той или иной функции информационной системы управления, является реальной альтернативой выбору автоматизированной системы. Подобный подход может смягчить определенные проблемы, возникающие при внедрении программных модулей.
Все большее количество организаций предпочитает приобретать готовые технологии, а при необходимости добавлять к ним собственное программное обеспечение, так как разработка собственной информационной системы – слишком дорогостоящий процесс.
Подобная тенденция приводит к изменению поставщиками ранее существовавшего способа выхода на рынок. В настоящее время разрабатывается, как правило, только базовая система, которая впоследствии адаптируется под конкретного заказчика. При этом пользователей консультируют по вопросу внедрения информационной системы, что значительно сокращает сроки внедрения, а также повышает квалификацию сотрудников.
Глава 2. Проектная часть
2.1 Выбор средства для моделирования предметной области решаемой задачи
Моделирование предметной области «Управление документооборота» имеет свои особенности, которые можно реализовать при помощи использования средств UML.
UML является языком графического описания для объектного моделирования в области разработки программного обеспечения, для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.
UML является языком широкого профиля, это – открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и последующего документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода [2].
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий и больше сконцентрироваться на проектировании и архитектуре.
Среди основных понятий UML можно выделить Class diagram, Component diagram, Composite structure diagram, Deployment diagram, Object diagram, Package diagram, Activity diagram, Use case diagram.
Диаграмма классов (Class diagram) – статическая структурная диаграмма, описывающая структуру информационной системы, демонстрирующая классы системы, их атрибуты, методы и зависимости между классами.
Диаграмма компонентов (Component diagram) – статическая структурная диаграмма, показывает разбиение программной системы на структурные компоненты и связи (зависимости) между компонентами. В качестве физических компонентов могут выступать файлы, библиотеки, модули, исполняемые файлы, пакеты и т. п.
Диаграмма композитной/составной структуры (Composite structure diagram) – статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса.
Диаграмма развёртывания (Deployment diagram, диаграмма размещения) – служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них.
Диаграмма объектов (Object diagram) – демонстрирует полный или частичный снимок моделируемой системы в заданный момент времени. На диаграмме объектов отображаются соответствующие экземпляры классов (объекты) системы с указанием текущих значений их атрибутов и связей между объектами.
Диаграмма пакетов (Package diagram) – структурная диаграмма, основным содержанием которой являются пакеты данных и отношения между ними.
Диаграмма деятельности (Activity diagram) – диаграмма, на которой показано определенное разложение некоторой деятельности на её составные части для полного освоения предметной области. Под деятельностью (англ. activity) понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов – вложенных видов деятельности и отдельных действий (англ. action), соединённых между собой потоками, которые идут от выходов одного узла к входам другого.
Диаграмма вариантов использования (Use case diagram, диаграмма прецедентов) – диаграмма, на которой отражены отношения, существующие между актёрами и вариантами использования.
Таким образом, использование языка графического описания UML можно получить соответствующие диаграммы, позволяющие описать в полной мере предметную область.
Для работы с UML можно воспользоваться набором программ, среди которых выделяются:
– UMLet;
– yEd;
– Dia;
– CADE;
– Diagram Designer;
– StarUML;
– Microsoft Visio;
– Rational Rose [16].
Rational Rose представляет собой CASE средство проектирования и разработки информационных систем и программного обеспечения для управления предприятиями. Как и другие специализированные CASE средства его можно применять для анализа и моделирования бизнес процессов.
Принципиальное отличие Rational Rose от других средств заключается в объектно-ориентированном подходе. Графические модели, создаваемые с помощью этого средства, основаны на объектно-ориентированных принципах и языке моделирования UML (Unified Modeling Language). Инструменты моделирования Rational Rose позволяют разработчикам создавать целостную архитектуру процессов предприятия, сохраняя все взаимосвязи и управляющие воздействия между различными уровнями иерархии.
Моделирование бизнес процессов в Rational Rose выполняется за счет применения различных аспектов. Каждый из этих аспектов концентрирует внимание на определенных характеристиках и возможностях процессов.
К таким аспектам относятся:
– вариант использования (Use case). Этот аспект дает возможность понять, каким образом действуют участники процесса и за счет этого определить их взаимодействие и влияние на процесс. Для построения моделей процесса в рамках данного аспекта применяются Use-case диаграммы, диаграммы последовательностей, диаграммы совместной работы и диаграммы действий;
– логический аспект. С помощью этого аспекта можно определить функциональные требования процессов. Он задает логическую взаимосвязь между классами элементов процессов. Для построения моделей применяются диаграммы классов и диаграммы состояний;
– составляющие элементы. Этот аспект обращает внимание на состав элементов процесса и их распределение при создании информационной системы. Модели в этом аспекте строятся с помощью диаграммы компонентов. Она содержит информацию об элементах процесса и программном обеспечении;
– ввод в действие. Этот аспект показывает схему процесса в привязке к аппаратному обеспечению информационной системы. Для построения моделей применяется только одна диаграмма – диаграмма топологии [7].
За счет применения различных аспектов Rational Rose предоставляет пользователям (бизнес аналитикам, инженерам, техническим специалистам и руководителям) возможность создавать, анализировать, изменять и управлять моделями, используя единый объектно-ориентированный подход и единый язык моделирования.
Rational Rose обеспечивает следующие возможности моделирования бизнес процессов:
– поддержка объектного моделирования. Применение принципов объектного моделирования и языка UML позволяет приблизить модели процессов к требованиям бизнеса и упрощает вид моделей;
– структурное представление элементов. Модели процессов и их элементы могут быть представлены в виде графической структуры, наглядно отображающий их состав и взаимосвязи;
– интеграция моделей. За счет применения единого языка UML, Rational Rose позволяет объединить модели бизнес процесса, модели приложений и модели данных;
– открытая архитектура. Она позволяет дополнять существующий инструментарий программы новыми функциями и возможностями;
– обратное проектирование. Для целей моделирования бизнес процессов данная возможность может быть полезна, если моделируемый процесс автоматизирован [4].
Преимуществами Rational Rose являются:
– поддержка командной работы. В этом CASE средстве реализована простая поддержка всех участников проекта. Пользователи могут работать со своими собственными уникальными моделями и в своем собственном окружении без смены рабочего места, при этом сохраняется взаимосвязь с общими моделями;
– управление моделями. Все создаваемые модели могут быть легко изменены. Изменения в одной модели автоматически отражаются во взаимосвязанных моделях. Для управления моделями применяется система контроля версий и управления конфигурацией;