пр_ИС_Тем12-13

12.5.6. Диаграммы пакетов (Package diagram)

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

Пакетная технология группирования классов объектов позволяет упростить:

•разработку и эксплуатацию ЭИС;

•гибкую адаптацию типовых компонентов с позиции их повторного использования;

•оптимизацию клиент-серверной архитектуры ЭИС.

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

Рис. 12.16. Пример диаграммы пакетов

Собеспечивающей точки зрения ИС разбивают на пять основных пакетов:

•«Интерфейс», объекты которого реализуют функции взаимодействия пользователей с ИС по вводу-выводу информации и обмен сообщениями между подсистемами;

•«База данных», объекты которого выполняют доступ к данным во внешней памяти;

•«Управление задачами», объекты которого осуществляют функции диспетчеризации и маршрутизации обработки объектов, например, в системе управления рабочими потоками;

•«Утилиты», объекты которого осуществляют вспомогательные функции, например преобразование форматов данных;

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

11

12.5.7. Диаграммы компонентов и размещения(Component diagram, Deployment diagram)

Диаграмма компонентов — это диаграмма, на которой изображена организация множества компонентов ми зависимости между ними.

Компонент — это физически заменяемая часть системы, реализующая спецификацию интерфейсов.

Программные компоненты представляются в виде исходных, откомпилированных и исполняемых программных кодов объектов. Один компонент, как правило, соответствует программному коду одного пакета классов объектов.

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

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

Рис. 12.17. Пример диаграммы компонентов и размещения

12.6. Проектирование ИС на основе объектно-ориентированной CASEтехнологии

Рассмотрим технологическую сеть проектирования ИС на основе использования объектноориентированной CASE-технологии, для которой характерны последовательное расширение и

12

уточнение моделей на различных стадиях жизненного цикла ЭИС: анализа системных требований, логического и физического проектирования, реализации.

Технологическая сеть объектно-ориентированного проектирования ИС (рис. 12.18)

представляет собой обобщение методологий Objectory [89] и Natural Engineering Workbench [110].

Рис. 12.18. Функциональная модель работ объектно-ориентированного проектирования ИС:

Анализ системных требований к ИС

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

13

Рис.12.19. Функциональная модель работ этапа анализа системных требований

Так, в объектно-ориентированной методологии анализа и проектирования бизнес-процессов предусматриваются:

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

2.Задание порядка разработки и автоматизации бизнес-процессов в соответствии с определенными критериями, например наибольшим эффектом для заказчика, простотой и быстротой разработки и т. д.

3.Неформальное словесное описание бизнес-процессов.

Структура основных бизнес-объектов и их взаимодействий описывается в соответствии с требованиями модели классов объектов.

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

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

Разработка диаграммы классов объектов предполагает задание состава основных атрибутов и определение характера взаимосвязей классов объектов.

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

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

Логическое проектирование ИС

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

(рис. 12.20).

14

Рис. 12.20. Функциональная модель работ на этапе логического проектирования ИС:

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

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

Уточнение диаграммы состояний объектов выполняется в связи с детализацией диаграммы вариантов и диаграммы классов объектов.

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

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

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

Физическое проектирование ИС

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

15

Рис. 12.21. Функциональная модель работ на этапе физического проектирования ИС:

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

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

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

Реализация ИС

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

16

Рис. 12.22. Функциональная модель работ на этапе реализации ИС:

Генерация классов объектов в конкретной объектно-ориентированной программной среде (C++, Visual Basic, Pascal и т.д.), выбираемой из универсума объектно-ориентированных языков программирования, осуществляется на основе диаграммы классов объектов.

Генерация шаблонов процедур методов класса объектов в конкретной объектноориентированной программной среде (C++, Visual Basic, Pascal и т.д.), выбираемой из универсума объектно-ориентированных языков программирования, производится на основе диаграммы взаимодействий объектов.

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

17

ТЕМА 13. Прототипное проектирование ИС (RAD-технология)

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

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

Одним из условий обеспечения высокого качества создаваемых ИС является активное вовлечение конечных пользователей в процесс разработки предназначенных для них интерактивных систем, что нашло отражение в методологии прототипного проектирования. Ядром этой методологии является быстрая разработка приложений RAD (Rapid Application Development).

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

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

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

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

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

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

Рассмотрим основные возможности и преимущества быстрой разработки прототипа ИС

(рис. 13.1).

18

Рис. 13.1. Основные возможности и преимущества быстрой разработки прототипа ИС

Все приемы для быстрой разработки приложений RAD служат одновременно для обеспечения высокого качества продукта и низкой стоимости разработки. К числу этих приемов относятся:

1)разработка приложения итерациями;

2)необязательность полного завершения работ на каждом из этапов жизненного цикла для начала работ на следующем;

3)обязательное вовлечение пользователей в процесс проектирования и построения системы;

4)высокая параллельность работ;

5)повторное использование частей проекта;

6)необходимое применение CASE-средств, обеспечивающих техническую целостность на этапах анализа и проектирования;

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

8)использование автоматических генераторов (мастеров);

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

10)тестирование и развитие проекта, осуществляемые одновременно с разработкой нескольких версий прототипа.

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

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

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

19

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

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

Такие инструментальные средства можно условно разделить на два класса: инструменты быстрой разработки приложения в развитых СУБД — класс DEVELOPER интегрированные инструменты быстрой разработки приложений — класс BUILDER.

К инструментам этих классов можно отнести средства 4GL (генераторы компонентов приложений):

•генераторы таблиц базы данных;

•генераторы форм ввода-вывода;

•генераторы запросов;

•генераторы отчетов;

•генераторы меню.

Такие генераторы существуют почти во всех СУБД, как персональных Access, FoxPro, Paradox, так и в окружении промышленных серверов БД (Oracle, Informix, Adabas D и др.).

Отличительной чертой класса BUILDER является то, что инструменты данного класса легко интегрируются с CASE-средствами и представляют собой единую среду быстрой разработки приложения. К интегрированным инструментам класса BUILDER можно отнести такие, как Power Builder Enterprise (Power Soft), Delphi (Borland), Builder Си ++ и др.

Рассмотрим инструментальную среду быстрой разработки приложений СУБД Access, которая включает ряд мастеров (конструкторов).

Мастер (конструктор) таблиц предназначен для быстрого создания структуры таблиц БД и их взаимосвязей.

Мастер (конструктор) форм ввода-вывода позволяет быстро создать экраны ввода информации в БД различного типа (ленточные, в столбец, табличные).

Мастер (конструктор) запросов позволяет создавать запросы различной сложности.

Мастер (конструктор) отчетов позволяет создавать отчеты на базе нескольких таблиц или запросов.

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

Жизненный цикл создания ИС на основе RAD-технологии предполагает после формирования технического задания и декомпозиции системы независимую разработку подсистем с последующей сборкой, тестированием и внедрением комплексной ИС (рис. 13.2).

20