Добавлен: 25.10.2018
Просмотров: 4939
Скачиваний: 12
36
4.10. ЭСКИЗНЫЙ ПРОЕКТ
В главе «Эскизный проект» описывается детальное проектирование системы. Целью деталь-
ного проектирования является создание проектной документации, по которой может быть создана
система без какой бы то ни было дополнительной информации (возможно силами другой организа-
ции). Как указывалось в разделе «План управления программным проектом» (п. 4.7.1.5) начинать
процесс детального проектирования необходимо с аспектов проекта, представляющих наибольший
риск.
Выполнение детального проектирования системы предполагает проработку следующих шагов:
1. Введение глобальных пакетов:
1.1. базисные (foundation) классы (списки, очереди и т.д.);
1.2. обработчики ошибок (error handling classes);
1.3. математические библиотеки;
1.4. утилиты;
1.5. библиотеки других поставщиков.
2. Детализация архитектурных слоев.
Проанализированные в главе «Разработка концепции АСОИУ» типовые решения архитектурных
слоев ИС, как правило, нуждаются в детализации, поскольку вошедшие в состав системы паттер-
ны изначально имеют существенно упрощенную структуру, в которой множество условий и де-
талей были пропущены для улучшения понимания назначения паттерна.
3. Уточнение проектных классов (design classes):
3.1. Уточнение атрибутов класса:
3.1.1. кроме имени атрибута, задается его тип и значение по умолчанию;
3.1.2. учитываются соглашения по именованию атрибутов, принятые в проекте и языке реали-
зации;
3.1.3. задается видимость атрибутов: public, private или protected;
3.1.4. при необходимости определяются производные (вычисляемые) атрибуты.
3.2. Уточнение операций класса:
3.2.1. создается краткое описание операции, включая пояснение смысла всех ее параметров;
3.2.2. определяется видимость операции: public, private или protected;
3.2.3. определяется область действия операции: экземпляр (операция объекта) или классифи-
катор (операция класса);
3.2.4. задаются предусловия функции (при каких условиях выполняется). Предусловия описы-
вают соотношения между переменными и константами, существование которых предпо-
лагается до момента выполнения функции;
3.2.5. задаются постусловия функции (что происходит в результате ее выполнения);
3.2.6. составляется описание алгоритма выполнения операции (с использованием диаграмм деятель-
ности, блок-схем, псевдокода, а также диаграмм взаимодействия различных объектов при вы-
полнении операции).
Фрагмент некоторого алгоритма, представ-
ленного в виде блок-схемы, показан на рис. 11.
Каждый блок алгоритма снабжен идентифика-
тором, который используется для ссылки при
описании выполняющихся в нем операторов.
Блок-схемы алгоритмов приводят в приложении
к ПЗ и оформляют в соответствии с ГОСТ
19.003-80 «Схемы алгоритмов и программ. Обо-
значения условные графические» [63].
3.3. Определение инвариантов класса.
Инварианты класса представляют собой
эффективные требования к объектам класса,
выраженные в терминах атрибутов класса. Ин-
варианты класса принимают форму ограниче-
ний на значения. Как и С-требования, они часто
называются бизнес-правилами. Например, тре-
бование «Все участники веб-аукционов должны
предоставлять номер своей кредитной карты»
Начало
Инициали-
зация
А.1
Нет
Да
t
j
< T
end
Определение
k
a
(t
j
), k
b
(t
j
), k
c
(t
j
)
А.2
А.3
Конец
Рис. 11. Пример оформления блок-схемы ал-
горитма
37
может быть переведено в специальный инвариант класса Участник следующим образом:
зарегистрирован == true AND 400000001 <= номерКредитнойКарты <= 699999999 OR
зарегистрирован == false AND номерКредитнойКарты == 0.
4. Проработка интерфейсов между слоями проектируемой системы или параллельными процессами.
Поскольку вопросы проектирования интерфейсов играют ключевую роль в обеспечении про-
изводительности при распределенной обработке данных в ИС, несколько типовых решений органи-
зации интерфейсов будут рассмотрены в следующем параграфе.
4.10.1. Организация программных интерфейсов
Организация одновременного функционирования нескольких процессов в рамках одной ин-
формационной системы становится все более и более актуальной задачей. Если несколько процессов
одновременно выполняются на одном узле, то рассматриваются вопросы организации параллельных
вычислений. Если же процессы запущены на разных узлах вычислительной сети и для достижения
поставленной цели необходимо организовать обмен данными между ними, то рассматривается задача
распределенных вычислений (или распределенной обработки данных). Наиболее очевидный пример
распределенной обработки – организация взаимодействия между клиентом и сервером корпоратив-
ного приложения.
Наиболее существенная проблема организации распределенных приложений связана с мини-
мизацией временных издержек, вызванных передачей данных по каналам связи между удаленными
узлами сети. При этом, поскольку каждый удаленный вызов приводит к увеличению временных за-
трат, то при проектировании распределенных приложений стремятся заменить множество «мелких»
(в смысле объема возвращаемых данных) вызовов несколькими «крупными» вызовами, возвращаю-
щими возможно избыточную в данный момент, но потенциально необходимую информацию для вы-
полнения последующих этапов вычислений. Реализовать такую идею можно путем введения допол-
нительных объектов с низкой степенью детализации интерфейса, назначение которых состоит в орга-
низации доступа к сети объектов с высокой степенью детализации интерфейса (например, модели
предметной области). Для этого применяется типовое решение, получившее название интерфейса
уделанного доступа (remote facade).
На рис. 12 приведен простой пример организации интерфейса удаленного доступа: многочис-
ленные set- и get-методы объекта Book интерфейсом удаленного доступа BookFacade заменяются на
одну пару set-get методов для всего объекта в целом. В этом случае, если, например, Удаленный кли-
ент обращается к методу setBookData, интерфейс удаленного доступа считывает параметры, пере-
данные в удаленном запросе, и последовательно вызывает отдельные set-методы объекта Book.
Рис. 12. Пример организации интерфейса удаленного доступа
38
Помимо предоставления интерфейса с низкой степенью детализации, интерфейс удаленного
доступа может выполнять и другие функции, например, обеспечение безопасности или управление
транзакциями
5
.
Если взаимодействие с клиентами требует сохранения состояния объектов между сеансами
необходимо использовать одно из следующих типовых решений: сохранение состояния сеанса на
стороне клиента, сохранение состояния сеанса в БД, сохранение состояния сеанса на стороне
сервера.
В более сложных случаях, чем в рассмотренном выше примере (см. рис. 12), один интерфейс
удаленного доступа может выполнять роль шлюза для нескольких объектов с высокой степенью де-
тализации. Например, интерфейс удаленного доступа для объекта Заказ может применяться для из-
влечения и обновления сведений о заказе, всех его пунктах, а также некоторых сведений о покупате-
ле, разместившем этот заказ. При этом клиенту может потребоваться, например, получить с сервера
связный граф объектов, относящихся к объектам предметной области. Для реализации такой переда-
чи применяется объект переноса данных (data transfer object), возвращаемый клиенту за один вы-
зов, и содержащий не только те данные, которые запросил клиент, но и те, которые ему могут пона-
добиться на следующем этапе взаимодействия с системой.
Поля объектов переноса данных, как правило, содержат значения стандартных типов (строки,
даты и т.д.), а также другие объекты переноса данных. Любые связи между такими объектами долж-
ны укладываться в рамки простого графа, типа иерархии, в противоположность сложным структурам
модели предметной области. Поэтому для переноса данных обычно используют упрощенную форму
объектов домена.
Наиболее распространенной формой реализации объекта переноса данных является множест-
во записей – набор табличных записей, который возвращается в результате выполнения SQL-запроса,
сгенерированного доменом.
С целью «разворачивания» объектов переноса данных на обоих концах соединения исполь-
зуется специальный объект, получивший название «сборщик», который создает объект переноса
данных на основе данных домена и наоборот – обновляет модель домена данными из объекта пере-
носа данных. При создании объекта переноса данных сборщиком используется тот или иной алго-
ритм сериализации, позволяющий получать данные в двоичном, текстовом (причем, в большинстве
случаев, в виде XML-документа) или в зашифрованном формате.
Помимо проработки вопросов, связанных с обеспечением интерфейса удаленного доступа,
необходимо предусмотреть интерфейс для любого источника или получателя данных в системе. Та-
кие интерфейсы чаще всего называются шлюзом (gateway) и помимо доступа, например, к реляци-
онной базе данных (такой частный случай рассмотрен в разделе 4.8.2) могут предоставлять доступ к
XML-документам, транзакциям CICS
6
, W3C
7
, JDOM
8
и т.д.
В большинстве случаев шлюз представляет собой класс в который помещается весь специа-
лизированный код API того или иного источника или потребителя данных. Интерфейс шлюза соот-
ветствует интерфейсу обычного объекта доступа к данным и может содержать набор традиционных
методов. При этом для получения доступа к удаленному источнику, объекты приложения будут об-
ращаться к шлюзу, который в свою очередь будет преобразовывать вызовы простых методов в вызо-
вы специализированного API. Очевидно, что для перехода к другому источнику данных в этом слу-
чае достаточно будет изменить только класс шлюза, а остальная часть системы абсолютно не постра-
дает.
Следует подчеркнуть, что согласно идеологии применения целого ряда GoF-паттернов (Indi-
rection, Protect Variation, Adapter) существует объективная необходимость применения служебных
классов типа «шлюз» для организации взаимодействия между различными подсистемами с целью
инкапсуляции их внутренней структуры, посредством обеспечения доступа к высокоуровневым ме-
тодам, вынесенным в интерфейсную часть. Такой подход позволяет обеспечить фундаментальный
5
В большинстве случаев под транзакциями подразумеваются последовательности операций, описывающих
процессы взаимодействия с БД, однако множество других объектов управляются с помощью механизма под-
держки транзакций: очереди сообщений, задания на печать, банковские платежи и т.д. Поскольку транзакции
являются основным инструментом управления параллельными процессами в корпоративных приложениях ши-
роко известны несколько алгоритмов диспетчеризации транзакций: длинные транзакции, транзакции запроса,
отсроченные транзакции и т.д.
6
CICS (Command Execution Diagnostic Facility) – среда обработки транзакций фирмы IBM
7
W3C - World Wide Web Consortium
8
JDOM - Java-реализация популярного интерфейса доступа к документам (Document Object Model - DOM)
39
принцип модульной декомпозиции «низкая внешняя связанность – высокое внутреннее сцепление», а
также повысить эффективность тестирования отдельных компонентов за счет сокращения количества
тестовых наборов.
Пример организации двухуровневой архитектуры корпоративного приложения типа «клиент-
сервер» показан на рис. 13. Помимо узкоспециализированных шлюзов, предназначенных для взаимо-
действия с БД, слой источника данных содержит шлюз, обеспечивающий доступ к внешним источ-
ником или потребителям данных. Кроме того, в слое домена выделены подсистемы, выполняющие
независимые друг от друга задачи, и взаимодействующие друг с другом посредством межкомпонент-
ного интерфейса. При поступлении удаленного вызова от клиента интерфейс удаленного доступа с
помощью сборщика создает объект переноса данных, который используется для обмена информа-
цией между клиентом и сервером.
Сервер
Клиент
<<
слой
предста
вл
ен
ия
>>
об
ъе
кт
пе
ре
но
са
дан
ных
<<
сервисный
сло
й >>
<<
сл
ой
домен
а>>
<<
слой
исто
чника
данн
ых
>>
сб
ор
щик
интерфейс
удаленного
доступа
сб
ор
щик
об
ъе
кт
пе
ре
но
са
дан
ных
БД
шл
юз
внешний
источник
данных
меж
компо
не
нтн
ы
й
ин
тер
ф
ей
с
Подсис-
тема 1
Подсис-
тема 2
Рис. 13. Пример организации двухуровневой архитектуры типа «клиент-сервер»
Типовые решения по организации межслойных и межмодульных интерфейсов широко обсу-
ждаются в литературе. В частности, в [62, 80, 95, 98] описаны основные концепции организации ин-
терфейсов и приведены примеры их реализации.
4.10.2. Проектирование структуры базы данных
В заключение главы «Эскизный проект» разрабатывают структуру базы данных (БД).
Проектирование БД зависит от типа используемой для хранения данных СУБД – объектной
или реляционной. Для объектных БД проектирования не требуется, поскольку классы-сущности не-
посредственно отображаются в БД. Для реляционных БД классы-сущности объектной модели долж-
ны быть отображены в таблицы реляционной БД. Совокупность таблиц и связей между ними может
быть представлена в виде диаграммы классов, которая по существу является ER-диаграммой. Набор
правил, применяемых при отображении классов в таблицы БД, фактически совпадает с правилами
преобразования сущностей и связей.
Для описания схемы БД применяется следующий набор элементов языка UML:
• таблица представляется в виде класса со стереотипом «Table»;
• представление изображается в виде класса со стереотипом «View»;
• столбец таблицы представляется в виде атрибута класса с соответствующим типом данных;
• обычная ассоциация и агрегация представляются в виде ассоциации со стереотипом «Non-
Identifying» (в терминологии IDEF1X – неидентифицирующая связь);
• композиция представляется в виде ассоциации со стереотипом «Identifying» (в терминологии
IDEF1X – идентифицирующая связь);
• схема БД представляется в виде пакета со стереотипом «Schema», содержащего классы-таблицы;
• контейнер хранимых процедур представляется в виде класса со стереотипом «SP Container»;
40
• ограничения целостности, индексы и триггеры представляются в виде операций классов-таблиц
со стереотипами «РК» (Primary Key), «FK» (Foreign Key), «Unique», «Check», «Index» и «Trigger»;
• физическая база данных представляется в виде компонента со стереотипом «Database».
Кроме создания структуры при проектировании БД, как правило, перечисляются все запросы,
которые необходимо предусмотреть в системе для ее полноценного функционирования, а также при-
водят синтаксис и описание типовых SQL-запросов, хранимых процедур, представлений и триггеров,
позволяющих, с одной стороны, осуществлять мониторинг за состоянием БД, с другой стороны, ре-
шить задачу построения сложно-структурированных запросов к БД, тем самым повысив надежность
и расширяемость системы, а также упростив программирование клиентской части приложения.
Стандарт IEEE 1016-1987 для проектной документации программного обеспечения (SDD –
Software Design Document) содержит руководство по составлению и ведению проектной документа-
ции системы. Основные результаты проектирования архитектуры, а также результаты, полученные в
эскизном проекте, помещаются в соответствующий раздел SDD.
Подводя итог, еще раз перечислим требования к содержанию главы «Эс-
кизный проект» пояснительной записки:
1. детализировать архитектурные слои и описать основные и вспомогательные
пакеты, вошедшие в их состав;
2. детализировать и описать проектные классы (указать инварианты, опера-
ции, атрибуты, область их видимости, пред- и пост- условия функций). Для
функции наиболее трудоемкой с точки зрения реализации составляется
блок-схема алгоритма выполнения операций;
3. с использованием типовых решений «интерфейс удаленного доступа», «объ-
ект переноса данных», «сборщик» и т.д. прорабатываются межслойные ин-
терфейсы проектируемой системы;
4. разрабатывается структура БД, прорабатываются типовые запросы, тригге-
ры, представления и хранимые процедуры, которые необходимо предусмот-
реть в системе для ее полноценного функционирования.
Проектная документация системы, оформленная в соответствии с IEEE 1016-1987, помещает-
ся в приложение ПЗ. Пример составления проектной документации см. в [55]. Оглавление проектной
документации программного обеспечения приведено в приложении Л и включает в качестве примера
типовое описание некоторых разделов, которое необходимо адаптировать в соответствии с содержа-
нием выполняемого проекта. Примечание к тому или иному разделу приведено в квадратных скобках
курсивным шрифтом.
4.10.3. Интеграция приложений
В проектах, состоящих из нескольких независимых частей, в особенности, в комплексных
проектах, выполнение которых осуществляется несколькими студентами, необходимо особое внима-
ние уделить вопросам интеграции. Актуальность поиска и проработки интеграционных решений свя-
зана со следующими обстоятельствами:
1. Ненадежность сети передачи данных. Распределенные системы могут быть связаны друг с дру-
гом посредством телефонных линий, сегментов локальных сетей, маршрутизаторов, коммутато-
ров, спутниковых каналов связи и т.д. Доставка информации на каждом из этих этапов связана с
задержкой и риском потери.
2. Низкая скорость передачи данных. Время передачи данных через каналы связи на порядок
больше вызова локальной процедуры. В этой связи, создание распределенного приложения тре-
бует применение иных принципов проектирования, чем создание приложения, выполняющегося
локально на одном компьютере.
3. Различия между приложениями. Интеграционное решение должно быть ингерентным к разли-
чиям составляющих его частей (язык программирования, платформа, формат данных и т.д.).
4. Подверженность изменениям. Чем больше в состав приложения входит различных составляю-
щих, тем в большей степени оно будет подвержено неминуемым изменениям. В этой связи инте-
грационное решение должно иметь возможность адаптации к изменению объединяемых им при-
ложений.
Для устранения (или снижения влияния) указанных выше проблем используются четыре ти-
повых решения, предназначенных для обмена информацией между приложениями, входящими в со-
став интеграционной системы: