Примечание: рассматриваемый здесь материал является вводным в различные методологии моделирования процессов при разработке информационных систем. Он может быть полезным при выполнении практических заданий по дисциплине. Более полно проблематика проектирования информационных систем и их программного обеспечения рассматривается в дисциплине «Проектирование информационных ситсем» на 4-м курсе обучения. Для более подробного знакомства рекомендуется также литература [Калянов, 2002; Вендров,2000; Смирнова, 2001].
Методологии информационного моделирования бизнес-процессов являются воплощением так называемого метода структурного системного анализа систем.
Системный структурный анализ (рис.4.8)- метод исследования (моделирования) системы или процесса, который начинается с общего обзора объекта исследования, а затем предполагает его последовательную поэтапную детализацию.
Рис.4.8. Иллюстрация идеи структурного анализа
Примечание: кроме структурного анализа (структурный подход) в настоящее время при разработке сложного программного обеспечения применяется объектно-ориентированный анализ (см. например, универсальный язык объектно-ориентированного анализа и моделирования UML). Однако, по-видимому, для моделирования и анализа бизнес-процессов структурный подход остается превалирующим и поддерживается многими инструментальными средствами, так называемыми CASE- средствами –программами, компьютерной поддержки инженерии систем.
«Анализ предметной области». Обучение проектированию программных продуктов. Часть 1. Тренинг 3.
Похожие статьи:
Сделано на платформе ELport.ru. Все права защищены. Копирование информации допускается только при указании ссылки на сайт «СИСТЕМАТИ». 2023
Источник: systematy.ru
Методологии моделирования предметной области
Функция ( операция ) представляет собой некоторый преобразователь входных объектов в выходные. Последовательность взаимосвязанных по входам и выходам функций составляет бизнес-процесс . Функция бизнес-процесса может порождать объекты любой природы (материальные, денежные, информационные). Причем бизнес-процессы и информационные процессы, как правило, неразрывны, то есть функции материального процесса не могут осуществляться без информационной поддержки. Например, отгрузка готовой продукции осуществляется на основе документа «Заказ», который, в свою очередь, порождает документ «Накладная», сопровождающий партию отгруженного товара.
Функция может быть представлена одним действием или некоторой совокупностью действий. В последнем случае каждой функции может соответствовать некоторый процесс, в котором могут существовать свои подпроцессы , и т.д., пока каждая из подфункций не будет представлять некоторую недекомпозируемую последовательность действий.
Анализ предметной области и построение реляционной модели
На внешнем уровне моделирования определяется список основных бизнес-функций или видов бизнес-процессов . Обычно таких функций насчитывается 15–20.
На концептуальном уровне выделенные функции декомпозируются и строятся иерархии взаимосвязанных функций .
На внутреннем уровне отображается структура информационного процесса в компьютере: определяются иерархические структуры программных модулей, реализующих автоматизируемые функции .
Структура управления
В совокупности функций бизнес-процесса возможны альтернативные или циклические последовательности в зависимости от различных условий протекания процесса. Эти условия связаны с происходящими событиями во внешней среде или в самих процессах и с образованием определенных состояний объектов (например, заказ принят, отвергнут, отправлен на корректировку). События вызывают выполнение функций , которые, в свою очередь, изменяют состояния объектов и формируют новые события, и т.д., пока не будет завершен некоторый бизнес-процесс . Тогда последовательность событий составляет конкретную реализацию бизнес-процесса .
Каждое событие описывается с двух точек зрения: информационной и процедурной. Информационно событие отражается в виде некоторого сообщения, фиксирующего факт выполнения некоторой функции изменения состояния или появления нового. Процедурно событие вызывает выполнение новой функции , и поэтому для каждого состояния объекта должны быть заданы описания этих вызовов. Таким образом, события выступают в связующей роли для выполнения функций бизнес-процессов .
На внешнем уровне определяются список внешних событий, вызываемых взаимодействием предприятия с внешней средой (платежи налогов, процентов по кредитам, поставки по контрактам и т.д.), и список целевых установок, которым должны соответствовать бизнес-процессы (регламент выполнения процессов, поддержка уровня материальных запасов, уровень качества продукции и т.д.).
На концептуальном уровне устанавливаются бизнес-правила, определяющие условия вызова функций при возникновении событий и достижении состояний объектов.
На внутреннем уровне выполняется формализация бизнес-правил в виде триггеров или вызовов программных модулей.
Организационная структура
Организационная структура представляет собой совокупность организационных единиц , как правило, связанных иерархическими и процессными отношениями. Организационная единица — это подразделение, представляющее собой объединение людей (персонала) для выполнения совокупности общих функций или бизнес-процессов . В функционально-ориентированной организационной структуре организационная единица выполняет набор функций , относящихся к одной функции управления и входящих в различные процессы. В процессно-ориентированной структуре организационная единица выполняет набор функций , входящих в один тип процесса и относящихся к разным функциям управления.
На внешнем уровне строится структурная модель предприятия в виде иерархии подчинения организационных единиц или списков взаимодействующих подразделений.
На концептуальном уровне для каждого подразделения задается организационно-штатная структура должностей (ролей персонала).
На внутреннем уровне определяются требования к правам доступа персонала к автоматизируемым функциям информационной системы.
Техническая структура
Топология определяет территориальное размещение технических средств по структурным подразделениям предприятия, а коммуникация — технический способ реализации взаимодействия структурных подразделений.
На внешнем уровне модели определяются типы технических средств обработки данных и их размещение по структурным подразделениям.
На концептуальном уровне определяются способы коммуникаций между техническими комплексами структурных подразделений: физическое перемещение документов, машинных носителей, обмен информацией по каналам связи и т.д.
На внутреннем уровне строится модель «клиент-серверной» архитектуры вычислительной сети.
Описанные модели предметной области нацелены на проектирование отдельных компонентов ИС: данных, функциональных программных модулей, управляющих программных модулей, программных модулей интерфейсов пользователей, структуры технического комплекса. Для более качественного проектирования указанных компонентов требуется построение моделей, увязывающих различные компоненты ИС между собой. В простейшем случае в качестве таких моделей взаимодействия могут использоваться матрицы перекрестных ссылок: «объекты-функции», «функции-события», » организационные единицы — функции «, » организационные единицы — объекты», » организационные единицы — технические средства» и т д. Такие матрицы не наглядны и не отражают особенности реализации взаимодействий.
Для правильного отображения взаимодействий компонентов ИС важно осуществлять совместное моделирование таких компонентов, особенно с содержательной точки зрения объектов и функций . Методология структурного системного анализа существенно помогает в решении таких задач.
Структурным анализом принято называть метод исследования системы, который начинается с ее общего обзора, а затем детализируется, приобретая иерархическую структуру с все большим числом уровней. Для таких методов характерно: разбиение на уровни абстракции с ограниченным числом элементов (от 3 до 7); ограниченный контекст, включающий только существенные детали каждого уровня; использование строгих формальных правил записи; последовательное приближение к результату. Структурный анализ основан на двух базовых принципах – «разделяй и властвуй» и принципе иерархической упорядоченности. Решение трудных проблем путем их разбиения на множество меньших независимых задач (так называемых «черных ящиков») и организация этих задач в древовидные иерархические структуры значительно повышают понимание сложных систем. Определим ключевые понятия структурного анализа .
Операция – элементарное (неделимое) действие, выполняемое на одном рабочем месте.
Функция – совокупность операций , сгруппированных по определенному признаку.
Бизнес-процесс — связанная совокупность функций , в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга, научное открытие, идея), представляющая ценность для потребителя.
Подпроцесс – это бизнес-процесс , являющийся структурным элементом некоторого бизнес-процесса и представляющий ценность для потребителя.
Бизнес-модель – структурированное графическое описание сети процессов и операций , связанных с данными, документами, организационными единицами и прочими объектами, отражающими существующую или предполагаемую деятельность предприятия.
Существуют различные методологии структурного моделирования предметной области, среди которых следует выделить функционально-ориентированные и объектно-ориентированные методологии.
Источник: intuit.ru
Теоретическая часть. Моделирование бизнес-процессов предметной области
В случае создания ПО для информационной системы управления предприятием (совокупность средств, методов и персонала для обработки, хранения и выдачи информации) структурный анализ начинается с исследования того, как организована системауправления предприятием, с обследования функциональной и информационной структурысистемы управления, чтобы понять, как работает организация, которую собираются автоматизировать. Для описания работы предприятия необходимо построить модель. Такая модель должна быть адекватна предметной области; следовательно, она должна содержать в себе знания всех участников бизнес-процессов организации.
По результатам обследования аналитик строит модель «как есть»: обобщенную логическую модель исходной предметной области, отображающую ее функциональную структуру, особенности основной деятельности и информационное пространство, в котором эта деятельность осуществляется. Далее создают модель «как надо»: усовершенствованную обобщенную логическую модель, отображающую реорганизованную предметную область или ее часть, которая подлежит автоматизации.
Эта стадия анализа содержит элементы проектирования. Структурные, функциональные моделисозданные на ранних этапах проектирования программной систем, помогут проектировщику выявить основные функции и составные части проектируемой системы и, по возможности, обнаружить и устранить существенные ошибки.
Функциональные диаграммы предметной области помогут понять, как выполняются отдельные операции организации, которые собираются автоматизировать. На этом уровне определяются все функции,которые выполняет объект, и процессы, протекающие в объекте (например, подразделениях предприятия) для выполнения функций, определяются связимежду функциями, между процессами.
Функция- преобразование входных потоков в выходные, осуществляемое в соответствии с некоторыми внутренними правилами. Выполнение функции обеспечивает процесс. Процесс- совокупность взаимосвязанных действий (работ), преобразующих некоторые входные данные в выходные. Каждый процесс характеризуется определенными задачами и методами их решения, исходными данными, полученными от других процессов, и результатами. Для описания работы организации необходимо построить модель и выделить те процессы, которые должны быть автоматизированы.
Наиболее удобным языком моделирования бизнес-процессов является методология функционального моделирования — IDEF0, предложенный более 20 лет назад Дугласом Россом (SoftTech, Inc.) и называвшийся первоначально SADT — Structured Analysis and Design Technique.
В IDEF0 система представляется как совокупность взаимодействующих работ или функций. Такая чисто функциональная ориентация является принципиальной — функции системы анализируются независимо от объектов, которыми они оперируют. Это позволяет более четко смоделировать логику и взаимодействие процессов организации.
Под моделью в IDEF0 понимают описание системы (текстовое и графическое), которое должно дать ответ на некоторые заранее определенные вопросы.
Моделируемая система рассматривается как произвольное подмножество Вселенной. Произвольное потому, что, во-первых, мы сами умозрительно определяем, будет ли некий объект компонентом системы, или мы будем его рассматривать как внешнее воздействие, и, во-вторых, оно зависит от точки зрения на систему. Система имеет границу, которая отделяет ее от остальной Вселенной. Взаимодействие системы с окружающим миром описывается как вход (нечто, что перерабатывается системой), выход (результат деятельности системы), управление (стратегии и процедуры, под управлением которых производится работа) и механизм (ресурсы, необходимые для проведения работы). Находясь под управлением, система преобразует входы в выходы, используя механизмы.
Процесс моделирования какой-либо системы в IDEF0 начинается с определения контекста, т.е. наиболее абстрактного уровня описания системы в целом. В контекст входит определение субъекта моделирования, цели и точки зрения на модель.
Под субъектом понимается сама система, при этом необходимо точно установить, что входит в систему, а что лежит за ее пределами; другими словами, мы должны определить, что мы будем в дальнейшем рассматривать как компоненты системы, а что как внешнее воздействие. На определение субъекта системы будет существенно влиять позиция, с которой рассматривается система, и цель моделирования — вопросы, на которые построенная модель должна дать ответ; другими словами, первоначально необходимо определить область (Scope) моделирования.
Описание области как системы в целом, так и ее компонентов является основой построения модели. Хотя предполагается, что в течение моделирования область может корректироваться, она должна быть в основном сформулирована изначально, поскольку именно область определяет направление моделирования и когда должна быть закончена модель.
При формулировании области необходимо учитывать два компонента — широту и глубину. Широта подразумевает определение границ модели — мы определяем, что будет рассматриваться внутри системы, а что снаружи. Глубина определяет, на каком уровне детализации модель является завершенной. При определении глубины системы необходимо не забывать об ограничениях времени — трудоемкость построения модели растет в геометрической прогрессии от глубины декомпозиции.
После определения границ модели предполагается, что новые объекты не должны вноситься в моделируемую систему; поскольку все объекты модели взаимосвязаны, внесение нового объекта может быть не просто арифметической добавкой, но в состоянии изменить существующие взаимосвязи. Внесение таких изменений в готовую модель является, как правило, очень трудоемким процессом (так называемая проблема «плавающей области»).
Модели AS-IS и ТО-ВЕ.Целью построения функциональных моделей обычно является выявление наиболее слабых и уязвимых мест деятельности организации, анализ преимуществ новых бизнес-процессов и степени изменения существующей структуры организации бизнеса.
Анализ недостатков и «узких мест» начинают с построения модели AS-IS (Как есть), т. е. модели существующей организации работы. Модель AS-IS может строиться на основе изучения документации (должностных инструкций, положений о предприятии, приказов, отчетов и т. п.), анкетирования и опроса служащих предприятия, создания фотографии рабочего дня и других источников. Полученная модель AS-IS служит для выявления неуправляемых работ, работ не обеспеченных ресурсами, ненужных и неэффективных работ, дублирующихся работ и других недостатков в организации деятельности предприятия. Исправление недостатков, перенаправление информационных и материальных потоков приводит к созданию модели ТО-ВЕ (Как будет) — модели идеальной организации бизнес-процессов. Как правило, строится несколько моделей ТО-ВЕ, среди которых определяют наилучший вариант.
Рисунок 44 — Схема построения моделей «ТО-ВЕ» как результат анализа модели «AS-IS»
Технология проектирования программного обеспечения ИС подразумевает сначала создание модели AS-IS, ее анализ и улучшение бизнес-процессов, т. е. создание модели ТО-ВЕ, и только на основе модели ТО-ВЕ строится модель данных, прототип и затем окончательный вариант ПО.
Порядок выполнения работы
1. Построить функциональную диаграмму предметной области, согласно выбранного варианта (Приложение А) с помощью нотации IDEF0.
2. Оформить отчет по лабораторной работе.
3. Представить отчет по лабораторной работе для защиты.
Источник: megaobuchalka.ru
