АНАЛИЗ И РАЗРАБОТКА ОБЪЕКТНО-ОРИЕНТИРОВАННОЙ МОДЕЛИ ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ

Данная статья посвящена исследованиям, лежащим в области информатики и информационных технологий, и касается изучения анализа и разработки объектно-ориентированной модели информационной подсистемы.

Актуальность данной статьи заключается в том, что модели предприятий используются в анализе требований для определения того, как функционирует организация, а не как реализовать информационные системы. Объектно-ориентированные концепции недавно были адаптированы к корпоративному моделированию. Объекты в этих моделях отличаются от объектов, используемых для проектирования информационных систем.

Поэтому, многие учёные, такие как: Э. Йордон, И. Якобсон, А. Дэннис и Б.Х. Виксом, изучали метод получения общего объектно-ориентированного проектирования информационной системы из объектно-ориентированной модели предприятия. Этот метод использует декомпозицию объектов предприятия и две концепции - делегирование и статические объекты. Также предлагается набор правил, построенных на онтологических утверждениях, для руководства создания проектов из модели предприятия. Конечным результатом этого процесса является объектно-ориентированный логический проект (то есть проект, не зависящий от платформ и языков реализации) информационной системы, которая отражает модель предприятия, на которой она основана.

Объектно-ориентированная парадигма началась с программирования и проектирования программного обеспечения. Позднее она была адаптирована к модели предприятия/бизнеса. Модели предприятий используются в системном анализе для понимания организационных требований. В модели предприятия объекты представляют роли и обязанности в организации. Эти роли задействованы как в обработке информации, так и в неинформационной обработке. Следовательно, объекты в модели предприятия могут сильно отличаются от объектов, используемых в разработке программного обеспечения. Например, при разработке программного обеспечения принято моделировать «элементы инвентаря» как объекты с услугами (например, методы), такие как «изменение уровня запасов».

Однако на уровне предприятия элемент инвентаря является пассивным субъектом, не несущим ответственности за действия. Есть и активные агенты, такие как люди или организационные единицы, которые выполняют организационные действия. Эти агенты обычно даже не представлены в их активной роли в информационной системе.

Модели предприятия являются отправной точкой для проектирования информационных систем. Однако, если объекты в модели предприятия отличаются от объектов в дизайне информационной системы, неясно, как вывести дизайн из модели предприятия.

Некоторые объектно-ориентированные методы предоставляют некие рекомендации для перехода от анализа к дизайну. В частности, исследование Э. Йордона (1991 гг.) и некоторые работы по использованию UML М. Фаулера (1997 гг.) и А. Дэнниса и Б.Х. Виксома (2000 гг.).

Э. Йордон рассматривает проектирование как добавление деталей реализации модели, разработанной на этапе анализа. Эти данные включают взаимодействие человека, управление задачами (например, требования к многозадачности) и управление данными. А. Дэннис и Б.Х. Виксом предлагают, как указать системные требования с диаграммами использования, чтобы управлять процессом разработки. Для каждого варианта применения, диаграмма классов используется для определения классов объектов и их отношений, также используются диаграммы состояний для указания состояний объектов, последовательности или диаграммы совместной работы для определения взаимодействия объектов, а диаграммы активности используются для указания потока действий. Однако оба метода страдают от двух основных недостатков. Во-первых, модели, построенные на этапе анализа, уже включают конструкции информационной системы, поэтому они не представляют собой бизнес, не зависящий от решения информационной системы.

Во-вторых, они не указывают процесс получения модели информационной системы из более ранней модели предприятия.

В данной статье рассмотрен подход к преобразованию модели предприятия в общий проект информационной системы. Для этого используется два понятия - делегирование статических объектов и применение разложения объектов.

Подход метода объектно-ориентированного проектирования основан на онтологической модели, в статье, которая была представлена в, например, В. Вандом в 1989, В. Вандом и Р. Вебером в 1990, а также В. Вандом и С. Ву в 1993.

Метод предполагает, что смоделированный домен состоит из вещей, обладающих свойствами. Свойства могут быть неотъемлемыми или взаимными для нескольких вещей. Компоненты взаимодействуют друг с другом, изменяя взаимные свойства. Один из них моделируется как объект, а свойство моделируется как атрибут. Состояние объекта содержит значения всех его атрибутов в данный момент времени. Объекты обладают атрибутами двух типов — интерфейс и внутренние атрибуты. Атрибуты интерфейса могут быть изменены другими объектами, но не могут быть изменены самим объектом. Внутренние атрибуты могут быть изменены и доступны только самим объектам. Это модельный эквивалент инкапсуляции в разработке программного обеспечения. Изменение состояния - это событие. Объекты взаимодействуют, изменяя атрибуты интерфейса друг друга. В объектно-ориентированных терминах они обмениваются запросами. Изменение значения в атрибуте интерфейса известно, как внешнее событие. Когда это происходит, объект может подвергнуться внутренней трансформации, вызвавшей внутреннее событие. Механизм, осуществляющий преобразование, называется услугой. Внутренние преобразования могут генерировать запросы к другим объектам, тем самым вызывая распространение запроса. Внешние объекты - это те, которые генерируют исходные внешние события.

Цель исследования - идентифицировать объекты, являющиеся компонентами информационной системы. С этой целью представим два понятия: объект делегирования и статический объект (Д. Юнг 1997 гг.). Объект в корпоративной модели представляет собой деятеля, в частности, отдельную или организационную единицу. Поскольку деятель может заниматься обработкой информации, некоторые из атрибутов соответствующего объекта могут представлять информацию, а некоторые из ее услуг представляют собой действия по обработке информации. Возможно, можно «делегировать» задачи обработки информации компьютеризированной системе, освободив делегирующий объект от ответственности за эти задачи.

Объект-делегат - это объект, который был создан для того, чтобы выступать в качестве представителя или поставщика услуг для исходного объекта. Делегированные объекты будут представлять собой компоненты информационной системы. Поскольку объекты в корпоративной модели представляют деятели, все они активны. Однако в информационных системах обычно есть информация о вещах, которые неактивны - например, элементы инвентаря. Чтобы представить неактивный компонент, используется статический объект. Состояние статического объекта может быть изменено только другими (активными) объектами. Следовательно, он имеет только атрибуты интерфейса. Хотя активные объекты могут проходить как внешние, так и внутренние события, статические объекты могут проходить только внешние события. Объект модели предприятия может управлять статическим объектом как часть предоставления своих услуг. Например, можно обнаружить, что администратор инвентаря (активный объект) отправляет элемент инвентаря (статический объект). Статические объекты служат основным средством моделирования состояния вещей, которые не имеют ответственности. Делегирование задач сводится к разложению исходного объекта на измененный объект и «делегирования» объект. В. Вонд и Р. Вебер предположили, что разложение зависит от множества событий, на которые должна реагировать разложившийся компонент (предмет или система), и предложили три необходимых условия для хорошего разложения:

1. Детерминизм: для каждого разложенного объекта событие представляет собой либо: a - указанное внешнее событие, либо b - внутреннее событие.

2. Минимальность: для каждого разложенного объекта нет ненужных атрибутов.

3. Без потерь: каждое возникающее свойство составного объекта, т. е. свойство, не обладающее каким-либо компонентом объекта, может быть представлено в терминах свойств и поведения (взаимодействий и событий) объектов-компонентов. Процесс декомпозиции объекта основан на отслеживании того, как запрос обрабатывается внутри заданного объекта. Процесс начинается с поиска компонентов, которые обрабатывают внешние запросы к составному объекту. Если исходный компонент нуждается в услугах, которые он сам по себе не может предоставить, он «породит» запрос другому компоненту для требуемой службы. В конце трассировки распространения запроса мы будем иметь модель всех компонентов с их атрибутами и услугами, которые необходимы для обработки оригинала запроса. Трассировка всех запросов создаст полную разложенную модель совокупного объекта.

Учитывая основополагающие принципы и условия проектирования и декомпозиции, мы можем выработать правила объектно-ориентированного проектирования. В отличие от эмпирических правил эти правила основаны на формальной основе. Правила описывают свойства, которыми должна обладать хорошая объектная модель, и определяют декомпозицию и формирование делегата и статических объектов. Таким образом, правила обеспечивают оба критерия для хорошего проекта и руководства для процесса проектирования. Процесс начинается с декомпозиции, поскольку состав составных объектов должен быть известен, чтобы сформировать делегированные и статические объекты.

Делегирование предоставляет путь перехода от модели предприятия к первоначальному дизайну информационной системы. В этом случае информационная система состоит из набора объектов-делегатов. Атрибуты делегата обеспечивают связь с проектом базы данных. Чтобы создать более совершенный проект, нужно больше узнать о внутренней структуре объектов делегата. Поскольку основой для поиска свойств объекта и его состава является анализ отправленных им запросов, более подробная информация о деталях может быть найдена путем анализа большего количества запросов, обрабатываемых объектами делегирования. В частности, по мере анализа большего количества запросов атрибуты (представляющие данные) будут разлагаться на более мелкие элементы. Поиск объектов делегатов - это конструктивное решение, указывающее, должны ли выполняться определенные задачи. Можно начинать искать потенциальных делегатов, ища те виды деятельности, которые работают с атрибутами, отражающими знания или информацию. Кандидатами для делегирования являются объекты, участвующие в деятельности по обработке информации (действия, которые изменяют состояние знаний) и / или деятельность по передаче информации (то есть, которые генерируют запросы, передающие информацию). Делегирование регулируется принципом, что, когда атрибуты и службы делегируются объекту делегата, как делегирующий объект («клиент»), так и делегат («сервер») остаются внутренне согласованными и сплоченными в отношении атрибутов и сервисов, т. е. инкапсуляция состояний объекта не нарушается, и никакое действие или информация не «теряются». Это означает, что поведение системы остается прежним до и после делегирования. Это требование может быть формализовано в правиле делегирования:

a) Атрибут должен быть делегирован службам, которые его получают или изменяют.

б) Служба должна быть делегирована с атрибутами, которые она получает или изменяет.

Статические объекты представляют собой вещи, которые участвуют или не участвуют в деятельности организации. Они являются полезными индикаторами типа информации, которая может храниться в базе данных, поскольку они содержат состояние, которое мы хотим сохранить. Кроме того, статические объекты могут помочь нам узнать, какие конкретные состояния в моделируемой системе могут быть изменены и с помощью каких действий. Эта информация важна, поскольку ее можно использовать в дизайне базы данных. Поскольку изменения состояния статических объектов могут выполняться только с помощью прямого манипулирование активным объектом (а именно объектом с серверами), правило требует, чтобы каждый статический объект в модели должен отображаться с хотя бы одним активным объектом, который либо считывает, либо изменяет свое состояние. Объект, который изменяет состояние статического объекта, может быть либо объектом предприятия, либо делегатом. В любом случае исходный объект предприятия должен включать атрибут, отражающий состояние статического объекта. Статические объекты, которые не изменяют состояния при любом (распространяемом) внешнем запросе, не будут отображаться в модели, поскольку они не предоставляют дополнительной информации.

Рисунок 1. Схема предприятия для корпуса хранилища.

Таким образом, системный анализ начинается с изучения организации и заканчивается общей моделью информационной системы. В данной статье описан подход к созданию общей объектно-ориентированной модели информационной системы из объектно-ориентированной модели предприятия. Данный подход основан на онтологических утверждениях.

На современном этапе развития информационных технологий, модели предприятий используются в анализе требований не для определения того, как реализовать информационные системы, а того, как функционирует организация. Объектно-ориентированные концепции были адаптированы к корпоративному моделированию, вследствие чего можно сделать вывод, что тема данной статьи актуальна для предприятий.

Список литературы:

1. Booch, G. Objects-Oriented Analysis and Design with Applications: 2nd edition/The Benjamin/Cummings, Publishing Company, Inc., — Redwood City, CA, 1994.
2. Е. Yourdon and P. Coad. Object-Oriented Analysis: 2nd edition/Yourdon Press — Englewood Cliffs, NJ, 1991.
3. E. Yourdon. Object- Oriented Design: 2nd edition/Yourdon Press —Englewood Cliffs, NJ, 1991.
4. Dennis, A. and B.H. Wixom. Systems Analysis and Design: 4th edition/ JohnWiley & Sons, Inc., — Indiana University of Virginia, 2000.
5. Fowler, M. and K. Scott (1997). UML Distilled: Applying the Standard Object Modeling Language, Addison-Wesley: 2nd edition/Addison-Wesley Longman, Inc., —1999
6. Jacobson, I., M. Christerson, P. Jonsson, and G. Övergaard (1992). Object-Oriented Software Engineering: A Use Case Driven Approach: 3nd edition/ Addison-Wesley Longman, Inc., — Massachusetts, 1992
7. Jung, D. Object-Oriented Modeling: From Analysis to Logical Design. M.Sc. thesis, Faculty of Commerce and Business Administration: 2nd edition/IGI Global Inc., — University of British Columbia, 1997
8. Wand, Y., A proposal for a formal model of objects, W. Kim, F. Lochovsky (eds.), Object-Oriented Concepts, Databases, and Applications: 3nd edition/Addison-Wesley Longman, Inc., — Massachusetts, 1989.
9. Wand, Y. and R. Weber. An Ontological Model of an Information System. IEEE Transactions on Software Engineering. Applications: 9th edition/ Addison-Wesley Longman, Inc., — Massachusetts, 1990.
10. Wand, Y. and R. Weber. A Unified Model of Software and Data Decomposition: 3nd edition/ Proc. of the 12th International Conference on Information Systems — New York, 1991.
11. Wand, Y. and R. Weber. Towards a Theory of Deep Structure of Information Systems: Journal of Information Systems — NC, 1995.
12. Wand, Y. and C. Woo. Object Oriented Analysis: Is it Really that Simple: Proc. of the Third Workshop on Information Technologies and Systems (WITS’93) — Orlando, Florida, 1993.
13. Wand Y., C. Woo, and S. Hui. Developing Business Models to Support Information System Evolution: Proc. of the Ninth Workshop on Information Technologies and Systems (WITS’99) — Charlotte, North Carolina, 1999.