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

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

В языке моделирования UML поддерживается ряд возможных статических и динамических моделей:

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

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

— модели конечного автомата, которые показывают изменение состояния отдельных объектов в ответ на определенные события, в UML они представлены в виде диаграмм состояния — динамические модели.

Модель подсистемы является одной из наиболее важных и полезных статических моделей, поскольку показывает, как можно организовать систему в виде логически связанных групп объектов. В UML пакеты являются структурами инкапсуляции и не отображаются непосредственно в объектах разрабатываемой системы. Существует несколько способов создания, применения и введения новых определений для моделей ООП с использованием диаграмм вариантов использования сценариев, диаграмм действий, диаграмм класс/объект, а также диаграмм сотрудничества, взаимодействия, перехода состояния, контекста данных и словаря данных. Некоторые вводятся сверху-вниз, другие — снизу-вверх, и все они итеративно определяются заново с помощью сотрудничества.

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

---

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

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

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

---

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

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

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

---

2. МЕТОДЫ ОБЪЕКТНО-ОРИЕНТИРОВАННОГО ПРОЕКТИРОВАНИЯ

К проектированию ИС непосредственное отношение имеют два направления деятельности:

1) проектирование ИС конкретных организаций на базе готовых программных и аппаратных компонентов;

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

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

Существует ряд фирм, специализирующихся на разработке проектов ИС (например, Price Waterhouse, ЛАНИТ, LUXOFT и др.)

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

В России действует государственный стандарт на стадии создания автоматизированных систем ГОСТ 34.601-90.(ПРИЛОЖЕНИЕ 2) Существует и международный стандарт на стадии жизненного цикла программной продукции (ISO 12207:1995). (ПРИЛОЖЕНИЕ 1) Как собственно ИС, так и компоненты ИС являются сложными системами, и при их проектировании нужно использовать один из стилей проектирования:

• нисходящее (Top-of-Design), четкая реализация нисходящего

проектирования приводит к спиральной модели разработки ПО, на каждом

витке спирали блоки предыдущего уровня детализируются, используются

обратные связи (альтернативой является так называемая каскадная модель,

относящаяся к поочередной реализации частей системы);

---

• восходящее (Bottom-of-Design);
• эволюционное (Middle-of-Design).

Чаще всего применяют нисходящий стиль блочно-иерархического проектирования.

Рассмотрим этапы нисходящего проектирования ИС.

Верхний уровень проектирования ИС часто называют концептуальным проектированием. Концептуальное проектирование выполняют в процессе предпроектных исследований, формулировки ТЗ, разработки эскизного проекта.

Предпроектные исследования проводят путем анализа деятельности предприятия (компании, учреждения, офиса), на котором создает или модернизируется ИС. При этом нужно получить, ответы на вопросы:

1. Что устраивает в существующей технологии?

2. Что можно улучшить?

3. Кому это нужно и, следовательно, каков будет эффект?

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

На основе анализа результатов обследования строят модель, отражающую деятельность предприятия на данный момент (до реорганизации). Такую модель называют «As Is (как есть). Далее разрабатывают исходную концепцию ИС. Эта концепция включает в себя предложения по изменению структуры предприятия, взаимодействию подразделений, информационным потокам, что выражается в модели «To Be» (Как должно быть).

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

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

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

---