Преподаватель который помогает студентам и школьникам в учёбе.

Анализ и оценка средств реализации объектно-ориентированного подхода к проектированию экономической информационной системы ( История возникновения объектно-ориентированного подхода проектирования информационных систем )

Содержание:

Введение

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

В 20 века был отмечен кризис программирования (software crisis), который заключался в том, что масштабные проекты стали выполнятся с существенными задержками или с перерасходом средств на разработку. При этом достаточно большое количество программ не обладали требуемыми функциональными возможностями, вследствие чего их качество не устраивало потребителей. Было проведено множество аналитических исследований для анализа сложившейся ситуации. Результаты были не особо обнадёживающими. В заданный срок на тот момент были завершены только 16% проектов. Из остальных проектов примерно 53% сданы заказчику с существенным опозданием или разработчики превысили запланированные расходы.

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

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

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

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

Рисунок 1. Декомпозиция ИС при различных подходах проектирования

Считается, что развитие данного метода началось с появления объектно-ориентированного программирования. В конце 20 века Гради Буч, Джеймс Рамбо (OMT – Object Modeling Technique) и Айвар Якобсон (OOSE – Object Oriented Software Engineering) предложили объектно-ориентированные методы разработки программного обеспечения.

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

В 1994-1996 гг Г. Буч, Дж. Рамбо и А. Якобсон организовали Rational Software Corporation, целью которой было объединение всех успешных разработок в данной области и создание единого стандартного языка объектно-ориентированного моделирования.

Несколько сотен крупных IT компаний, в том числе такие как Microsoft, Hewlett-Packard, IBM, Platinum Technology, Oracle и Rational, провели грандиозную работу, результатом которой стало создание первой версии унифицированного языка моделирования UML (Unified Modeling Language) v 1.0 в январе 1997 года.

Глава 2. Преимущества и сложности объектно-ориентированного подхода

2.1 Преимущества объектно-ориентированного подхода

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

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

Другие преимущества объектно-ориентированного подхода, отмеченные Бучем, можно описать так:

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

Практически всё современное программное обеспечение – объектно-ориентированное, а некоторые из языков программирования (например, Java) предполагают использование объектно-ориентированных структур.

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

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

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

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

2.2 Сложности объектно-ориентированного подхода

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

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

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

Сложности применения объектно-ориентированного подхода есть, но они преодолимы.

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

Глава 3. UML — унифицированный язык моделирования

3.1 Определение Unified Modeling Language

Как уже упоминалось, важным этапом развития объектно-ориентированных систем является создание унифицированного языка моделирования в январе 1997 года. Unified Modeling Language является языком для визуализации, написания спецификаций, документирования и конструирования сложных информационно-насыщенных объектных систем.

UML в настоящее время зарегистрирован как международный стандарт ISO/IEC 19501:2005 «Information technology - Open Distributed».

3.2 Аспекты UML модели

В UML модель могут быть выключены следующие аспекты:

Структурный аспект:

Use-Case-диаграммы, идентифицирующие бизнес-процессы и бизнес-транзакции, их взаимосвязь, соподчиненность и взаимодействие;

Рисунок 2. Пример Use-Case-диаграммы

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

Рисунок 3. Пример Package-диаграммы

Динамический аспект: Behavior-диаграммы (Activity, Statechart, Collaboration, Sequence), описывающие поведение (жизненный цикл) бизнес-процесcов в их взаимодействии во времени и в пространстве с привязкой к используемым ресурсам и получаемым результатам.

Рисунок 4. Пример Activity-диаграммы

Статический аспект:

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

Рисунок 5. Пример Class-диаграммы

Deployment-диаграммы, отражающие технологические ресурсы организации.

Рисунок 6. Пример Deployment -диаграммы

3.3 Словарь UML. Сущности, отношения и диаграммы

Словарь языка UML включает три вида строительных блоков: сущности, отношения, диаграммы.

Основные элементы модели – абстракции, называемые сущностями.

Различные сущности связываются между собой отношениями.

Совокупности сущностей группируются в диаграммы.

Всего в UML различают четыре типа сущностей: структурные, поведенческие, группирующие, аннотационные. Рассмотрим их подробнее.

Структурные сущности представляют собой существительные в моделях. Обычно это статические части модели, которые соответствуют физическим или концептуальным компонентам информационной системы. Различают семь видов структурных сущностей: Узел, Интерфейс, Класс, Прецедент, Кооперация, Компонент, Активный класс.

Динамические составляющие модели, которые так же называют глаголами языка, - поведенческие сущности. Их используют для описания поведения модели в пространстве и времени. Основных типов поведенческих сущностей всего два: Взаимодействие и Автомат.

Блоки, на которые можно разложить модель, организующие части, называются группирующими сущностями. Первичная группирующая сущность всего одна – пакет.

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

Все виды сущностей имеют свой способ графического отображения в диаграммах.

Рисунок 7. Простой пример использования различных сущностей в диаграмме

В языке UML различают четыре типа отношений: зависимость, ассоциация, обобщение и реализация.

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

диаграммы классов (Class Diagrams);
диаграммы объектов (Objects Diagrams);
диаграммы прецедентов (Use Cases Diagrams);
диаграммы последовательностей (Sequence Diagrams);
диаграммы кооперации (Collaboration Diagrams);
диаграммы состояний (State Diagrams);
диаграммы действий (Activity Diagrams);
диаграммы компонентов (Component Diagrams);
диаграммы развертывания (Deployment Diagram).

3.4 Инструментальные средства UML

Инструментальные средства, поддерживающие методологию UML, — Rational Rose (Rational Software), Paradigm Plus (CA/Platinum), ARIS (IDS Sheer AG), Together Designer (Borland) и др.

Система Rational Rose позволяет строить восемь типов диаграмм UML: диаграммы прецедентов, диаграммы классов, диаграммы последовательностей, диаграммы кооперации, диаграммы состояний, диаграммы действий, компонентные диаграммы, диаграммы развертывания. Основным типом диаграмм, своеобразным ядром моделирования в UML являются диаграммы классов. Кроме UML, предусмотрено использование и других методов (Booch, OMT).

Система Paradigm Plus ориентирована на методологию OOCL (Object Oriented Change and Learning) и компонентную технологию проектирования и разработки. Она поддерживает диаграммы различных методов (UML, CLIPP, TeamFusion, OMT, Booch, OOCL, Martin/Odell, Shlaer/Mellor, Coad/Yourdon).

Система ARIS обеспечивает четыре различных «взгляда» на моделирование и анализ: Процессы, Функции (с Целями), Данные, Организация. Для каждого «взгляда» поддерживаются три уровня анализа (требования, спецификации, внедрение). Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и др. Каждый объект моделей ARIS имеет множество атрибутов, которые позволяют контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с workflow-системами и т. д.

Система Together Designer Community Edition — средство создания диаграмм UML 2.0. Позволяет строить диаграммы прецедентов (диаграммы сценариев взаимодействия пользователя с продуктом с точки зрения пользователя); диаграммы последовательностей, описывающие порядок передачи сообщений от одних объектов к другим; диаграммы кооперации, описывающие взаимодействие объектов друг с другом, диаграммы деятельности, описывающие потоки работ и изменение состояний объектов, диаграммы развертывания. При необходимости может создаваться логическая модель данных, содержащая диаграммы «сущность-связь», на ее основе генерируется физическая модель данных для конкретной СУБД, выбранной для реализации проекта.

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

Рисунок 8. Анализ объектно-ориентированного подхода

Глава 4. Средства реализации объектно-ориентированного подхода для проектирования экономической информационной системы

4.1 Моделирование бизнес-процессов и спецификации требований

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

Чтобы сделать рациональный выбор необходимо понимать несколько аспектов:

1. Цели проекта;

2. Требования к информации, необходимой для анализа и принятия решений в рамках конкретного проекта;

3. Возможности подхода с учетом требований п. 2;

4. Особенности разрабатываемой/внедряемой информационной системы.

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

Сравнение средств должно дать ответы на следующие вопросы:

1. Насколько сам подход/метод и его нотации применимы для того или иного этапа создания информационной системы.

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

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

Рисунок 9. Сравнительный анализ нотаций eEPC, IDEF, Sequence и Activity diagram

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

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

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

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

Процессный подход может использовать любые из перечисленных выше средств моделирования. Однако, в настоящее время наблюдается тенденция интеграции разнообразных методов моделирования и анализа систем, проявляющаяся в форме создания интегрированных средств моделирования. Одним из таких средств является продукт, носящий название ARIS - Architecture of Integrated Information System, разработанный германской фирмой IDS Scheer [7].

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

ARIS поддерживает четыре типа моделей, отражающих различные аспекты исследуемой системы:

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

Для построения перечисленных типов моделей используются как собственные методы моделирования ARIS, так и различные известные методы и языки моделирования - ERM, UML, OMT и др.

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

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

Основная бизнес-модель ARIS - eEPC (extended Event Driven Process Chain - расширенная модель цепочки процессов, управляемых событиями). По существу, она расширяет возможности IDEF0, IDEF3 и DFD, обладая всеми их достоинствами и недостатками. Применение большого числа различных объектов, связанных различными типами связей, может значительно увеличить размер модели и сделать ее плохо читаемой.

Бизнес-процесс в нотации eEPC представляет собой поток последовательно выполняемых работ (процедур, функций), расположенных в порядке их выполнения. Реальная длительность выполнения процедур в eEPC визуально не отражается. Это приводит к тому, что при создании моделей возможны ситуации, когда на одного исполнителя будет возложено выполнение двух задач одновременно. Используемые при построении модели символы логики позволяют отразить ветвление и слияние бизнес-процесса. Для получения информации о реальной длительности процессов необходимо использовать другие инструменты описания, например графики Ганта в системе MS Project.

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

Среди таких методов наиболее известными являются метод Ericsson-Penker и метод, реализованный в технологии Rational Unified Process (RUP).

Метод Ericsson-Penker [23] представляет интерес прежде всего в связи с попыткой применения UML в рамках процессного подхода к моделированию бизнес-процессов. Авторы метода создали свой профиль UML для моделирования бизнес-процессов, введя набор стереотипов, описывающих процессы, ресурсы, правила и цели деятельности организации. Метод использует четыре основные категории бизнес-модели:

Ресурсы - различные объекты, используемые или участвующие в бизнес-процессах (люди, материалы, информация или продукты).
Процессы - виды деятельности, изменяющие состояние ресурсов в соответствии с бизнес-правилами.
Цели - назначение бизнес-процессов Цели могут быть разбиты на подцели и соотнесены с отдельными процессами.
Бизнес-правила - условия или ограничения выполнения процессов (функциональные, поведенческие или структурные). Правила могут быть определены с использованием языка OCL.

Основной диаграммой UML, используемой в данном методе, является диаграмма деятельности. Метод Eriksson-Penker представляет процесс в виде деятельности со стереотипом "process" (основой данного представления является расширение метода IDEF0). Полная бизнес-модель включает множество представлений, подобных представлениям архитектуры ПО. Каждое представление выражено в одной или более диаграммах UML. Диаграммы могут иметь различные типы и изображать процессы, правила, цели и ресурсы во взаимодействиях друг с другом. Метод использует четыре различных представления бизнес-модели:

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

Методика моделирования RUP [13] предусматривает построение двух моделей:

модели бизнес-процессов (Business Use Case Model);
модели бизнес-анализа (Business Analysis Model).

Модель бизнес-процессов представляет собой расширение модели вариантов использования UML за счет введения набора стереотипов - Business Actor (стереотип действующего лица) и Business Use Case (стереотип варианта использования). Business Actor (действующее лицо бизнес-процессов) - это некоторая роль, внешняя по отношению к бизнес-процессам организации. Business Use Case (вариант использования с точки зрения бизнес-процессов) определяется как описание последовательности действий (потока событий) в рамках некоторого бизнес-процесса, приносящей ощутимый результат конкретному действующему лицу. Это определение подобно общему определению бизнес-процесса, но имеет более точный смысл. В терминах объектной модели Business Use Case представляет собой класс, объектами которого являются конкретные потоки событий в рамках описываемого бизнес-процесса.

Описание Business Use Case может сопровождаться целью процесса, которая, так же, как и в методе Eriksson-Penker, моделируется с помощью класса со стереотипом "goal", а дерево целей изображается в виде диаграммы классов.

Для каждого Business Use Case строится модель бизнес-анализа - объектная модель, описывающая реализацию бизнес-процесса в терминах взаимодействующих объектов (бизнес-объектов - Business Object), принадлежащих к двум классам - Business Worker и Business Entity. Business Worker (исполнитель) - класс, представляющий собой абстракцию исполнителя, выполняющего некоторые действия в рамках бизнес-процесса. Исполнители взаимодействуют между собой и манипулируют различными сущностями, участвуя в реализациях сценариев Business Use Case. Business Entity (сущность) является объектом различных действий со стороны исполнителей.

Кроме диаграммы данных классов, модель бизнес-анализа может включать:

Диаграммы последовательности (и кооперативные диаграммы), описывающие сценарии Business Use Case в виде последовательности обмена сообщениями между объектами-действующими лицами и объектами-исполнителями. Такие диаграммы помогают явно определить в модели обязанности каждого исполнителя в виде набора его операций.
Диаграммы деятельности, описывающие взаимосвязи между сценариями одного или различных Business Use Case.
Диаграммы состояний, описывающие поведение отдельных бизнес-объектов.
Методика моделирования Rational Unified Process обладает следующими достоинствами:
модель бизнес-процессов строится вокруг участников процессов (заинтересованных лиц) и их целей, помогая выявить все потребности клиентов организации. Такой подход в наибольшей степени применим для организаций, работающих в сфере оказания услуг (торговые организации, банки, страховые компании и т.д.);
моделирование на основе вариантов использования способствует хорошему пониманию бизнес-модели со стороны заказчиков.

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

Спецификация требований к ПО является составной частью процесса управления требованиями [15]. Выявленные в результате применения перечисленных методов требования к ПО оформляются в виде ряда документов и моделей. Так, в технологии RUP функциональные требования к системе моделируются и документируются с помощью вариантов использовании. Стиль их написания зависит от масштаба, количества участников и критичности проекта.

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

4.2 Анализ и проектирование информационной системы

Целью анализа требований является трансформация функциональных требований к ПО в предварительный системный проект и создание стабильной основы архитектуры системы. В процессе проектирования системный проект "погружается" в среду реализации с учетом всех нефункциональных требований.

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

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

Анализ вариантов использования выполняется проектировщиками и включает в себя:

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

В потоках событий варианта использования выявляются классы трех типов:

Граничные классы (Boundary) - служат посредниками при взаимодействии внешних объектов с системой. Типы граничных классов: пользовательский интерфейс (обмен информацией с пользователем, без деталей интерфейса - кнопок, списков, окон), системный интерфейс и аппаратный интерфейс (используемые протоколы, без деталей их реализации).
Классы-сущности (Entity) - представляют собой основные абстракции (понятия) разрабатываемой системы, рассматриваемые в рамках конкретного варианта использования.
Управляющие классы (Control) - обеспечивают координацию поведения объектов в системе. Примеры управляющих классов: менеджер транзакций, координатор ресурсов, обработчик ошибок.

Классы анализа отражают функциональные требования к системе и моделируют объекты предметной области. Совокупность классов анализа представляет собой начальную концептуальную модель системы

Наиболее важной частью объектно-ориентированного анализа является распределение обязанностей между классами (в виде операций классов). Оно выполняется с помощью диаграмм взаимодействия. При построении диаграмм взаимодействия возникают проблемы правильного распределения обязанностей между классами. Для их решения существует ряд образцов [14].

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

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

Объектно-ориентированное проектирование включает два вида деятельности:

проектирование архитектуры системы;
проектирование элементов системы.

Проектирование архитектуры системы выполняется архитектором системы и включает в себя:

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

Проектирование элементов системы включает в себя:

проектирование классов (детализация классов, уточнение операций и атрибутов, моделирование состояний, уточнение связей между классами);
проектирование баз данных (в зависимости от типа используемой для хранения данных СУБД - объектной или реляционной).

Заключение

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

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

Буч Г., Рамбо Д., Джекобсон А. Язык UML: Руководство пользователя: Пер. с англ. – М.: ДМК, 2000. – 432 с.
Вендров А.М. Проектирование программного обеспечения экономических информационных систем: Учебник. – М.: Финансы и статистика, 2000. – 352 с.
Калянов Г.Н. Теория и практика реорганизации бизнес-процессов. Серия «Реинжиниринг бизнеса». – М.: СИНТЕГ, 2000, 212 с.
Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. - М.: Весть-Метатехнология, 2001
Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование: Пер. с англ. – М.: ДМК Пресс, 2001. – 176 с.
Ларман К. Применение UML и шаблонов проектирования. Введение в объектно – ориентированный анализ и проектирование :Пер. с англ. – М.: Издательский дом «Вильямс», 2001. -496 с.
Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: ДИАЛОГ-МИФИ, 2001 – 304 с.
В. Репин, С. Маклаков ARIS Toolset/BPwin: выбор за аналитиком. - http://www.compress.ru/Temp/2878/index.htm
С.Д.Паронджанов, Компания Аргуссофт Методология создания корпоративных ИС. - http://www.neic.nsk.su/rus/tech/cit/kbd96/43.htm
Смирнова Г.Н., Сорокин А.А., Тельнов Ю.Ф. Проектирование экономических информационных систем: Учебник.-М.: Финансы и статистика, 2002.-512 с.
Шеер А.-В. Бизнес-процессы. Основные понятия. Теория. Методы. — М.: Весть-МетаТехнология, 1999.
Хотяшов Э. Н. Основы проектирования систем машинной обработки данных. – М.: ФиС, 1981.