Проведение анализа предметной области в интересах последующего проектирования базы данных является задачей, формирующей единый взгляд на сведения, которые в предметной области обрабатываются, учитывая не только их структуры, но и правила хранения и обработки, что отражается в выделяемых функциях и задачах.
Процесс анализа предметной области в разработке информационных систем предполагает выделение основных и вспомогательных бизнес-процессов [1] , которые призваны обеспечить производство продукта/услуги. Но, наряду с этим, выделение и рассмотрение бизнес-процессов предоставляет возможность определиться с бизнес-элементами и структурами данных, которые должны участвовать в обработке данных. Такие возможности требуют от разработчика информационной системы в моделировании базы данных отталкиваться не только от документов, используемых в деятельности предметной области, но и окружения каждого бизнес-процесса и функций, включающего определение бизнес-элементов, объектов данных, исполнителей обработки, владельцев процессов и функций, предшествующих и последующих функций, инициирующих и результирующих событий, прочие элементы. Глубина рассмотрения бизнес-процессов и функций дает максимально полную информацию о процессах, происходящих в предметной области, и позволяет лучше понимать задачи, которые необходимо реализовать при разработке базы данных, к которым относятся моделирование структуры базы данных, определение правил ссылочной целостности, формирование процедур обработки и представления данных, но запросам пользователей.
Понятия | Предметная область
Один из современных подходов к разработке информационных систем основывается на выделении документарных элементов в бизнес-процессе, где атрибутами являются сущности (объекты) предметной области, впоследствии представляемые сущностями логической модели базы данных. Этот подход может быть применим только на уровне контекстного рассмотрения бизнес-процессов и проведения операций декомпозиции бизнес-процессов, по, при переходе па уровень моделирования потоков данных смысл использования документарного подхода теряется, поскольку сама суть моделей потоков данных предполагает работу с объектами данных, некоторые из которых могут представляться в предметной области виртуальными представлениями и не существовать в документах, а также по причине отсутствия необходимости, кроме отдельных частных случаев, хранения информации о документах, которые сами по себе не являются объектами предметной области [1] [2] .
Учитывая эту особенность подхода к разработке информационных систем, и в частности баз данных, разработчиками в качестве бизнес-элемента рассматриваются элементы, информационно описывающие производимый продукт/услугу и вспомогательные объекты, которые в частных случаях могут представляться документами и информационными объектами, где атрибутами являются характеризующие их другие объекты предметной области, а также характеристические атрибуты соответствующих объектов. Это, по сути, означает, что информационный объект предметной области может представляться документом, содержать в своей структуре указание на другие объекты и дополняться собственными характеристиками (атрибутами) простых типов (рис. 2.2).
Что такое бизнес-процессы? Модуль 1. Урок 1
Рис. 2.2. Объектно-атрибутивное представление предметной области
Такое представление предметной области даст возможность увидеть, что структура базы данных является многоуровневой нелинейной, где элементы- характеристики указывают на характеристические атрибуты объектов предметной области или на другие объекты, которые, в свою очередь, также могут, кроме характеристических атрибутов, содержать ссылки на другие объекты. И такая иерархия взаимосвязей объектов продолжается до тех пор, пока конечный объект не будет описываться только характеристическими атрибутами.
Такое представление модели базы данных является идеальным, подразумевая реализацию линейных цепочек взаимосвязей объектов предметной области, и представляется в форме звезды или снежинки (рис. 2.3).
Рис. 23. Общее представление идеальной объектной модели данных
Однако такое представление не всегда является возможным ввиду различных причин, среди которых можно выделить некорректность проектирования базы данных, неверно проведенный анализ предметной области, циклические взаимозависимости между объектами, возникновение неразрешимых аномалий и пр. Часть из проблемных причин могут быть разрешены в процессе нормализации или возвратов к анализу предметной области с целью исправления ошибок проектирования.
Использование документарного подхода к разработке базы данных, как правило, требует серьезной нормализации исходной модели базы данных и зачастую не позволяет увидеть отдельные проблемные места в моделях базы данных, связанные с корректностью модели относительно предметной области.
Применение объектного подхода в сочетании с функционализацией модели базы данных позволяет разработчику в отдельно взятой функциональной области построить корректную структуру в ее идеальном представлении и заранее исключить различные аномалии и проблемы, связанные с представлением и обработкой данных.
Любой из подходов изначально ориентируется на функциональный анализ предметной области, выполняемый в интересах выявления ключевых информационных (документарных) объектов предметной области. По сути, выполняемый анализ предметной области направлен на построение модели информационного взаимодействия между отдельными функциями и бизнес-процессами предметной области с выделением владельцев и пользователей информации.
- [1] Вопросы разработки информационной системы в целом не являются предметом рассмотрения данного учебника.
- [2] Документы могут являться объектами предметной области только в случае разработки информационной системы документооборота или при необходимости хранения в базе данных отдельных документов, реализуя элементарные задачи документооборота.
Источник: studme.org
МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ И ПРОЕКТИРОВАНИЕ ПО
Очень важно на этапе проектирования достичь взаимопонимания как между разработчиками системы, так и между экспертами предметной области, заказчиками и т.д., так как каждый имеет свое видение проекта. При этом работа сводится к поэтапному выделению объектов, значимых функций системы, информационных потоков и системы их взаимосвязей.
Точки зрения участников разработки по определенным проблемам могут совпадать, при этом формы их представления могут быть различными, что ведет к осложнению совместной работы над одним проектом. Важным инструментом в данном случае является использование единого языка представления проектных решений — языка моделирования. Нужно определить систему обозначений, правил описания процессов, объектов, явлений и их взаимосвязи, позволяющую всем участникам проекта понимать друг друга («говорить на одном языке»).
Язык моделирования — это набор графических нотаций, которые используются для описания моделей в процессе проектирования. Нотация представляет собой совокупность графических объектов, используемых в модели, и является синтаксисом языка моделирования. Язык моделирования, с одной стороны, должен делать решения проектировщиков понятными пользователю, с другой — предоставлять проектировщикам средства достаточно формализованного и однозначного определения проектных решений, подлежащих реализации в виде программных комплексов, образующих целостную систему
Комплексность подхода и использование единой нотации очень важно не только на этапе моделирования предметной области, но и на последующих этапах разработки программной системы.
Изучение предметной области складывается из непосредственного наблюдения протекающих в ней процессов, изучения документов, циркулирующих в системе, а также интервьюирования участников этих процессов.
При разработке модели предметной области определяют некоторые границы, в пределах которых можно развивать логическую модель данных, т.е. моделировать объекты, не выходящие за пределы рассматриваемой предметной области. При этом все второстепенные детали опускаются, чтобы чрезмерно не усложнять процесс анализа и исследования полученной модели.
Результатом проведения исследования предметной области должен стать перечень системных требований, спецификаций, информационных потоков и их описание. Очень часто для этого применяются стандартные способы описания предметной области с использованием моделей DFD (диаграмма потоков данных), UML (унифицированный язык моделирования).
Под моделью предметной области понимается некоторая система, имитирующая структуру или функционирование исследуемой предметной области и отвечающая основному требованию — быть адекватной этой области. Модель должна отражать все аспекты функционирования программного обеспечения, и необходима на всех этапах жизненного цикла программного обеспечения. Но особую роль модели предметной области играют на стадии формирования требований к программному продукту при его создании.
Модель предметной области — это формализованные знания о предметной области, выраженные при помощи каких-либо средств. В качестве таких средств могут выступать текстовые описания предметной области (должностные инструкции, описание документооборота, примеры первичных документов, выходных отчетов и т.п.). Гораздо более информативными и полезными при разработке программного обеспечения и баз данных являются описания предметной области, выполненные при помощи специализированных графических нотаций. От того, насколько правильно смоделирована предметная область, зависит успех дальнейшей разработки системы.
Предварительное моделирование предметной области позволяет сократить время и сроки проведения проектировочных работ и получить более эффективный и качественный проект. Без проведения моделирования предметной области велика вероятность допущения большого количества ошибок в решении стратегических вопросов, приводящих к экономическим потерям и высоким затратам на последующее перепроектирование продукта.
Модель предметной области должна:
- • обеспечивать формализацию — однозначное описание структуры предметной области;
- • быть понятной для заказчиков и разработчиков и строиться на основе применения графических средств отображения модели;
- • быть реализуемой, т.е. должны быть средства физической реализации модели предметной области;
- • обеспечивать возможности оценки эффективности реализации модели.
Для реализации перечисленных требований необходимо построение системы моделей:
- • объектной модели, отображающей состав взаимодействующих в процессах объектов предметной области;
- • функциональной модели, отображающей взаимосвязь функций (действий) по преобразованию объектов в процессах;
- • технической модели, описывающей расположение и способы взаимодействия комплекса технических средств.
Возможно, также потребуются и другие модели, например организационная модель или модель управления, отображающая события и бизнес-правила, которые воздействуют на выполнение процессов.
Главный критерий адекватности модели предметной области заключается в функциональной полноте разрабатываемого программного продукта.
С моделированием непосредственно связана проблема выбора языка представления проектных решений.
Обычно модели строятся на трех уровнях:
- • внешнем (определение требований);
- • концептуальном (спецификации требований);
- • внутреннем (реализация требований).
Так, на внешнем уровне определяется состав основных компонентов программного обеспечения: объектов, функций, событий, организационных единиц, технических средств. На концептуальном — определяется характер взаимодействия компонентов системы. На внутреннем уровне с помощью модели дается ответ на вопрос: «с помощью каких программно-технических средств реализуются требования к системе»?
При работе с большими и сложными программами проблема сложности является главной проблемой. Ни один разработчик не в состоянии выйти за пределы человеческих возможностей и понять всю систему в целом. Единственный эффективный подход к решению этой проблемы заключается в построении сложной системы из небольшого количества крупных частей, каждая из которых, в свою очередь, строится из частей меньшего размера. Так до тех пор, пока самые небольшие части станут легки и доступны для восприятия и понимания. Это означает, что сложную программную систему нужно разделять (декомпозировать) на небольшие подсистемы, каждую из которых можно рассматривать независимо от других.
Источник: studref.com