Файл: Применение объектно-ориентированного подхода при проектировании информационной системы. Моделирование предметной области.pdf

ВВЕДЕНИЕ

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

Также в условиях рыночной конкуренции история проектов ИС во многом определяется своевременной реакцией разработчиков на изменения внешней среды, а это требует применения новых концепций, принципов, методов и инструментов, обеспечивающих адаптацию проектов к этим изменяющимся условиям и требованиям.

Часто применяются системы управления знаниями, использование которых рассматривается как конкурентное преимущество для предприятий и организаций, ориентированных на улучшение изменяющихся бизнес-процессов (прикладных процессов) путем автоматизации.

Управление знаниями – направление информатики, включающее широкий спектр принципов, методов и инструментов извлечения, накопления и применения знаний (корпоративных знаний, знаний предметной области).

Управление знаниями – это стратегия предприятия (организации), цель которой выявить и обратить в свою пользу имеющуюся информацию, опыт и квалификацию сотрудников с тем, чтобы повысить качество создаваемых систем. Однако инструменты (средства), предназначенные для извлечения и представления знаний, недостаточно совершенны^[1].

Поэтому существует ряд проблем. Для их определения рассмотрим несколько направлений информатики, где эти проблемы проявляются, в том числе – объектно-ориентированный подход при проектировании ИС и системы управления знаниями (СУЗ). В этом и заключается актуальность выбранной темы.

Цель данной работы является охарактеризовать применение объектно-ориентированного подхода при проектировании информационных систем.

На основании данной цели были предложены к решению следующие задачи:

• рассмотреть общие подходы к объектно-ориентированному проектированию информационных систем;
• проанализировать процесс моделирования в предметной области.

---

ГЛАВА 1. ОБЩИЕ ПОДХОДЫ К ОБЪЕКТНО-ОРИЕНТИРОВАННОМУ ПОДХОДУ ПРОЕКТИРОВАНИЯ ИНФОРМАЦИОННЫХ СИСТЕМ

1.1. Этапы проектирования

Проектирование системы на всех этапах разработки должно быть привязано к процессу (технологическому, бизнес-процессу), особенно на этапе разработки концептуальной модели. Соотношение между различными этапами разработки и методами проектирования ИС представлено на рис. 1.

Рис. 1. Этапы и методы проектирования ИС

Модель проектирования ИС на основе объектно-ориентированного подхода представлена на рис. 2.

Рис. 2. Модель проектирования информационной системы на основе объектно-ориентированного подхода

Наиболее критичным этапом создания ИС является этап разработки концептуальной модели. До появления формализованных методов проектирования процесс разработки часто основывался на произвольных предположениях^[2].

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

На стадии анализа предметной области определяются объекты и их классы и осуществляется объектная декомпозиция системы.

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

На стадии программирования осуществляется разработка программного обеспечения по отдельным компонентам, тестирование и сборка. То есть происходит постепенное создание (эволюция) системы.

Модификация системы не требует полного пересмотра проекта, затрагивая лишь соответствующие классы и объекты.

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

Основное преимущество объектно-ориентированного подхода состоит в упрощении проектирования ИС при наличии типовых проектных решений по отдельным компонентам, а также легкости модификации, поскольку модификация касается лишь отдельных компонент^[3].

---

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

Рис. 3. Зависимость эффективности применения функционально-ориентированного и объектно-ориентированного подходов от количества выполненных проектов

Объектно-ориентированный подход предполагает оперирование «объектом», обладающим некоторыми атрибутами и способным выполнять определённые операции^[4].

При этом повышается унификация разработки и ее пригодность для повторного использования. ИС строится на основе стабильных промежуточных описаний, что упрощает внесение изменений^[5].

1.2. Структурный и объектно-ориентированный подходы к проектированию информационных систем

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

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

---

Практика показывает, что время разработки и размер кода действительно сокращаются. Но с другой стороны существуют дополнительные накладные расходы, связанные с затратами на пересылку сообщения от одного объекта к другому. Согласно статистике, на вызов метода требуется в 1.75 - 2.5 раза больше времени, чем на вызов процедуры. Кроме того, потеря производительности происходит из-за большого количества наследуемого кода. Так же проблемой является динамическое размещение и удаление объектов, поскольку выделение памяти из кучи вызывает дополнительные вычислительные расходы. Но обычно положительные свойства объектно-ориентированных систем нивелируют недостатки, описанные выше, и производительность программы, написанной с использованием объектно-ориентированного подхода чаще выше, чем у её аналога написанного при помощи структурного.

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

Выделяют три основных типа отношений между классами.

Первый, называемый “is-a” или «обобщение/специализация», характеризуется наличием какого-то подкласса, являющегося частным случаем какого-то более общего класса. Например, подкласс кошки является частью класса животные.

Второй, называемый “part of” или “целое/часть”, используется тогда, когда какой-то объект является частью другого объекта, хвост является частью кошки.

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

---

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

ГЛАВА 2. ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОЕКТИРОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ

2.1. Моделирование предметной области в RUP

Задачи этой деятельности:

• понять предметную область или бизнес-контекст (прикладной контекст);
• убедиться, что все заинтересованные лица понимают контекст одинаково;
• осознать имеющиеся проблемы;
• оценить их возможные решения и последствия для бизнеса предприятия (организации).

В результате объектно-ориентированного проектирования предметной области должна появиться ее модель в виде набора диаграмм классов (объектов предметной области) и деятельностей (представляющих бизнес-операции и бизнес-процессы)^[6].

Эта модель отражает виды деятельности, в том числе:

• формирование списка потребностей заинтересованных лиц;
• разработка документа концепции («Видение»), который образует основу для понимания мотивов создания программного обеспечения (средства);
• разработка архитектуры программного средства, включающей подсистемы, интерфейсы подсистем, наиболее общие компоненты и их интерфейсы;
• составление общего словаря заинтересованных лиц;
• разработка модели предметной области, позволяющей описать среду, в которой функционирует программное обеспечение;
• разработка модели предметной области, позволяющей описать среду, в которой функционирует программное обеспечение;
• разработка модели прецедентов использования, которая описывает требования к программному обеспечению в форме актеров и прецедентов использования^[7].

Актер (actor) представляет собой тип пользователя данного программного средства или другое средство (систему), которое взаимодействует с данным. Прецедент использования (use case) описывает, как каждый актер будет взаимодействовать с программным средством. Разработчиком названных артефактов является системный аналитик.

---