Мелихов А.Ю. Проектирование автоматизированных систем обработки информации и управления

Подождите немного. Документ загружается.

111

Output

Called RealSubject.Request()

Рисунок 72 – Листинг реализации паттерна «Proxy»

Паттерны поведения (Behavioral Patterns) предназначены для распределения

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

эффективности и удобства эксплуатации системы:

1. итератор (Iterator) предоставляет единый метод последовательного доступа к

элементам коллекции, не зависящий и не связанный с самой коллекцией. Позволяет

обеспечить нескольким клиентам множественный доступ к коллекции.

2. наблюдатель (Observer) определяет между элементами зависимость один ко многим

так, что изменении состояния одного объекта все зависящие от него получают

извещение;

3. команда (Command) обеспечивает обработку команды в виде объекта, что позволяет

сохранять ее, передавать в качестве параметра методам, возвращать ее в виде

результата и т.д. Command используется для поддержки операции «отмена», ведения

журнала, операций с транзакциями.

4. стратегия (Strategy) определяет семейство алгоритмов, позволяя при необходимости

подставлять один вместо другого;

5. состояние (State) позволяет объекту варьировать свое поведение при изменении

внутреннего состояния;

6. шаблонный метод (Template Method) определяет скелет алгоритма, перекладывая

ответственность за некоторые его шаги на подклассы;

7. посредник (Mediator) предназначен для упрощения взаимодействия объектов системы

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

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

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

8. цепочка обязанностей (Chain of Responsibility) позволяет избежать жесткой

зависимости отправителя запроса от его получателя, при этом запрос начинает

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

цепочку, по которой запрос передается пока какой-то объект его не обработает.

9. интерпретатор (Interpreter) определяет представление грамматики некоторого языка, а

также интерпретирует предложения языка;

10. посетитель (Visitor) представляет операцию, которую необходимо выполнить над

элементами объекта. Позволяет определить новую операцию, не меняя класса

элементов, к которым он применяется;

11. хранитель (Memento) позволяет получить и сохранить во внешней памяти внутреннее

состояние объекта для его последующего восстановления.

Рассмотрим один из наиболее популярных паттернов поведения наблюдатель

(observer), который предоставляет компоненту возможность гибкой рассылки сообщений

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

имеется не менее одного получателя сообщений, причем их количество и состав могут

изменяться во время работы приложения.

Паттерн Observer применяется во многих приложениях, в которых изменения одного

компонента могут приводить к изменению других компонентов (особенно, когда в модели

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

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

достигается за счет того, что сообщения рассылаются только тем элементам, которые

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

полученную информацию так, как они считают нужным.

112

Рисунок 73 – Структура паттерна «Observer»

Subject располагает информацией о своих наблюдателях; предоставляет интерфейс

для присоединения и отделения наблюдателей. За субъектом может следить любое число

наблюдателей. Среди методов интерфейса должны быть методы добавления и удаления

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

информации от наблюдаемого объекта клиентам.

Observer - определяет интерфейс обновления для объектов, которые должны быть

уведомлены об изменении субъекта.

ConcreteSubject – сохраняет состояние, представляющее интерес для конкретного

наблюдателя ConcreteObserver, а также посылает информацию своим наблюдателям, когда

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

Observer. Методы извещения копируют или клонируют список таких объектов и,

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

объекта Observer.

ConcreteObserver – хранит ссылку на объект класса ConcreteSubject; сохраняет данные,

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

определенный в классе Observer, чтобы поддерживать согласованность с субъектом.

using System;

using System.Collections.Generic;

namespace

DoFactory.GangOfFour.Observer.Structural

{

/// MainApp startup class for Structural

/// Observer Design Pattern.

class MainApp

{

/// Entry point into console application.

static void Main()

{

// Configure Observer pattern

ConcreteSubject s = new ConcreteSubject();

s.Attach(new ConcreteObserver(s, "X"));

s.Attach(new ConcreteObserver(s, "Y"));

s.Attach(new ConcreteObserver(s, "Z"));

/// The 'ConcreteSubject' class

class ConcreteSubject : Subject

{

private string _subjectState;

// Gets or sets subject state

public string SubjectState

{

get { return _subjectState; }

set { _subjectState = value; }

}

/// The 'Observer' abstract class

abstract class Observer

{

public abstract void Update();

}

/// The 'ConcreteObserver' class

113

// Change subject and notify observers

s.SubjectState = "ABC";

s.Notify();

// Wait for user

Console.ReadKey();

}

/// The 'Subject' abstract class

abstract class Subject

{

private List<Observer> _observers = new

List<Observer>();

public void Attach(Observer observer)

{

_observers.Add(observer);

}

public void Detach(Observer observer)

{

_observers.Remove(observer);

}

public void Notify()

{

foreach (Observer o in _observers)

{

o.Update();

}

class ConcreteObserver : Observer

{

private string _name;

private string _observerState;

private ConcreteSubject _subject;

// Constructor

public ConcreteObserver(

ConcreteSubject subject, string name)

{

this._subject = subject;

this._name = name;

}

public override void Update()

{

_observerState = _subject.SubjectState;

Console.WriteLine("Observer {0}'s new state is

{1}",

_name, _observerState);

}

// Gets or sets subject

public ConcreteSubject Subject

{

get { return _subject; }

set { _subject = value; }

}

Output

Observer X's new state is ABC

Observer Y's new state is ABC

Observer Z's new state is ABC

Рисунок 74 – Листинг реализации паттерна «Observer»

6.1.6. Распределение по пакетам

Объединение классов в подсистемы осуществляется, исходя из следующих

соображений:

a. функциональная связь: объединяются классы, участвующие в реализации одного и

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

b. обязательность: совокупность классов, реализующая функциональность, которая

может быть удалена из системы или заменена на альтернативную;

c. связанность: объединение в подсистемы сильно связанных классов;

d. распределение: объединение классов, размещенных на конкретном узле сети.

Согласно MVC-паттерну в системе должно быть определено как минимум три пакета,

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

источника данных.

Поскольку на диаграммах пакетов отражается статическая информация, то для того,

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

диаграммы взаимодействия на которых изображаются архитектурно-значимые сценарии.

114

Рисунок 75 – Отображение структуры взаимодействия на диаграмме пакетов и диаграмме

последовательностей

При проектировании архитектуры становится заметной разница между пакетами и

подсистемами. Так, если пакет – это совокупность объектов, объединенных вместе по тому

или иному признаку (принадлежность к одному и тому прецеденты), то подсистема – это

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

ним, и в совокупности имеющих четко определенное поведение. В подсистемах объект-

интерфейс, как правило, реализуют с использованием шаблона Facade. При этом за

интерфейсом скрывается большое количество низкоуровневых операций; открытыми

остаются лишь несколько высокоуровневых. Более того, наличие большого числа системных

операций приводит к необходимости введение фасадных объектов на уровень слоя и

приложения в целом.

Уровень приложения приходится вводить при выполнении одного из следующих

условий:

- в системе используется несколько интерфейсов пользователей (толстый и тонкий клиент с

обычной и мобильной версией).

- уровень приложения используется в системах с тонким клиентом, когда слой домена

располагается на сервере, а слой представление – на клиенте. Объекты уровень приложения в

данном случае отслеживают состояние сеанса.

- графический интерфейс пользователя включает в свой состав множество экранов и

существует необходимость организации последовательности их вывода.

115

7. ТЕХНИЧЕСКОЕ ЗАДАНИЕ

Независимо от единиц измерения,

используемых поставщиком или

покупателем, производитель будет

использовать свои собственные

произвольные единицы измерения,

переводимые в единицы поставщика или

покупателя с помощью странных и

неестественных коэффициентов пересчета.

Теорема Вышковского

Техническое задание (ТЗ) на АСОИУ является основным документом, определяющим

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

в соответствии с которым проводится разработка АСОИУ и ее приемка при вводе в

эксплуатацию. ТЗ включает в себя системное описание расширенных требований к

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

проекту с учетом всей проведенной выше работы в отношении формулирования и

спецификации требований.

ТЗ на АСОИУ разрабатывают на систему в целом, предназначенную для работы

самостоятельно или в составе другой системы. Дополнительно могут быть разработаны ТЗ

на части АСОИУ (на подсистемы АСОИУ, комплексы задач АСОИУ и т. п.; на

комплектующие средства; на программные средства; на информационные изделия и т.д.)

[62].

Включаемые в ТЗ на АСОИУ требования должны соответствовать современному

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

к лучшим современным отечественным и зарубежным аналогам. Задаваемые в ТЗ на АСОИУ

требования не должны ограничивать разработчика системы в поиске и реализации наиболее

эффективных технических, технико-экономических и других решений.

ТЗ на АСОИУ разрабатывают на основании исходных данных, а также данных,

содержащихся в итоговой документации стадии «Формирование требований к АСОИУ».

В ТЗ на АСОИУ включают только те требования, которые дополняют

требования к системам данного вида (АСУ, САПР, АСНИ и т. д.), содержащиеся в

действующих НТД, и определяются спецификой конкретного объекта, для которого

создается система.

Поскольку в подразделе 2.6.1. ТЗ на создание АСОИУ (ГОСТ 34.602-89) необходимо

перечислить требования к системе в целом, а в подразделе 2.6.3 требования к различным

видам обеспечения, то в главе «Техническое задание» пояснительной записки необходимо с

учетом специфики проектируемой АСОИУ, а также данных, указанных в задании на

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

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

функционированию системы, к численности и квалификации персонала системы и режиму

его работы, показатели назначения, требования к надежности, безопасности, эргономике и

технической эстетике, к эксплуатации, защите информации от несанкционированного

доступа, требования по сохранности информации при авариях, требования к защите от

влияния внешних воздействий, к патентной чистоте, требования по стандартизации и

унификации; а также требования к видам обеспечения: математическому, информационному,

лингвистическому, программному, техническому, метрологическому, организационному,

методическому и другим [57, 60].

Учебный пример составления ТЗ см. в [51, 66]. Оглавление технического задания по

ГОСТ 34.602-89 приводится ниже.

116

Техническое задание на создание автоматизированной системы (ГОСТ 34.602-89)

1. Общие сведения.

2. Назначение и цели создания (развития) системы.

3. Характеристика объектов автоматизации.

4. Требования к системе.

5. Состав и содержание работ по созданию системы.

6. Порядок контроля и приемки системы.

7. Требования к составу и содержанию работ по подготовке объекта

автоматизации к

вводу системы в действие.

8. Требования к документированию.

9. Источники разработки.

117

8. ЭСКИЗНЫЙ ПРОЕКТ

Всегда не хватает времени,

чтобы выполнить работу как

надо, но на то, чтобы ее

переделать, время находится.

Закон Мескимена

Целью детального проектирования является создание проектной документации, по

которой может быть создана система без какой бы то ни было дополнительной информации

(возможно силами другой организации). Наиболее разумным начать процесс детального

проектирования с аспектов проекта, представляющих наибольший риск.

Шаг 1 включает разработку для каждой подсистемы соответствующего

архитектурного решения.

На этапе детального проектирования

архитектуры системы:

• вводятся глобальные пакеты:

o базисные (foundation) классы (списки, очереди и т.д.);

o обработчики ошибок (error handling classes);

o математические библиотеки;

o утилиты;

o библиотеки других поставщиков.

• уточняются проектные классы (design classes):

o класс анализа отображается в проектный класс, если он простой или представляет

единственную логическую абстракцию;

o сложный класс анализа может быть разбит на несколько классов, преобразован в

пакет или подсистему.

На 2-ом этапе уточняется описание классов, которые связывают архитектуру с

классами предметной области. Уточняется тип связи между классами.

Детальное проектирование классов включает следующие шаги:

1. Уточнение атрибутов класса:

1.3. кроме имени атрибута, задается его тип и значение по умолчанию;

1.4. учитываются соглашения по именованию атрибутов, принятые в проекте и языке

реализации;

1.5. задается видимость атрибутов: public, private или protected;

1.6. при необходимости определяются производные (вычисляемые) атрибуты.

2. Уточнение операций класса:

2.3. создается краткое описание операции, включая смысл всех ее параметров;

2.4. определяется видимость операции: public, private или protected;

2.5. определяется область действия операции: экземпляр (операция объекта) или

классификатор (операция класса);

2.6. задать предусловия функции (при каких условиях выполняется). Предусловия

описывают соотношения между переменными и константами, существование

которых предполагается до момента выполнения функции.

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

2.8. составить описание алгоритма выполнения операции (с использованием диаграмм

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

различных объектов при выполнении операции).

2.9. При необходимости ввести дополнительные операции, необходимые для

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

3. Представить атрибуты и методы на объектной модели.

4. Установить инварианты класса.

118

Шаг 3 включает в себя проверку полноты созданного проекта, а также проверку

обеспечения объектной моделью вариантов использования.

Описание инвариантов класса, которые представляют собой эффективные требования

к объектам класса, выраженные в терминах атрибутов класса. Инварианты класса

принимают форму ограничений на значения. Как и С-требования, они часто называются

правилами бизнеса. Например, требование «Все участники веб-аукционов должны

предоставлять номер своей кредитной карты» может быть переведено в специальный

инвариант класса Участник следующим образом:

зарегистрирован == true AND 400000001 <= номерКредитнойКарты <= 699999999 OR

зарегистрирован == false AND номерКредитнойКарты == 0

После определения всех функций, которые необходимо реализовать в

информационной систем для полноценного функционирования, необходимо описать

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

или псевдокода. Фрагмент некоторого алгоритма, представленного с помощью блок-схемы

показан на рис. 7. Каждой блок алгоритма снабжен идентификатором, который используется

для ссылки при описании выполняющихся в нем операторов. Блок-схемы алгоритмов

приводят в приложении к ПЗ и оформляют в соответствии с ГОСТ 19.003-80 «Схемы

алгоритмов и программ. Обозначение условные графические» [54].

Начало

Инициали-

зация

А.1

Нет

Да

< T

end

Определение

), k

)

А.2

А.3

Конец

Рисунок 76 – Пример оформления блок-схемы алгоритма

Существенное значение в разработке «Эскизного проекта» играет окончательное

создание прототипа пользовательского интерфейса, предварительные наброски которого

были выполнены совместно с пользователем на этапе формирования С-требований.

8.1. ОРГАНИЗАЦИЯ ПРОГРАММНЫХ ИНТЕРФЕЙСОВ

Организация одновременного функционирования нескольких процессов в рамках одной

информационной системы становится все более и более актуальной задачей. Если несколько

процессов одновременно выполняются на одном узле, то рассматриваются вопросы организации

параллельных вычислений. Если же процессы запущены на разных узлах вычислительной сети и для

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

ними, то

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

Наиболее очевидный пример распределенной обработки – организация взаимодействия между

клиентом и сервером корпоративного приложения.

Наиболее существенная проблема организации распределенных приложений связана с

минимизацией временных издержек, вызванных передачей данных по каналам связи между

удаленными узлами сети. При этом, поскольку каждый удаленный вызов

приводит к увеличению

119

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

множество «мелких» (в смысле объема возвращаемых данных) вызовов несколькими «крупными»

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

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

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

которых состоит

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

(например, модели предметной области). Для этого применяется типовое решение, получившее

название интерфейса уделанного доступа (remote facade).

На рис. 12 приведен простой пример организации интерфейса удаленного доступа:

многочисленные set- и get-методы объекта Book интерфейсом удаленного доступа BookFacade

заменяются на одну пару set-get методов для

всего объекта в целом. В этом случае, если, например,

Удаленный клиент обращается к методу setBookData, интерфейс удаленного доступа считывает

параметры, переданные в удаленном запросе, и последовательно вызывает отдельные set-методы

объекта Book.

Рисунок 77 – Пример организации интерфейса удаленного доступа

Помимо предоставления интерфейса с низкой степенью детализации, интерфейс удаленного

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

транзакциями

Если взаимодействие с клиентами требует сохранения состояния объектов между сеансами

необходимо использовать одно из следующих типовых решений: сохранение состояния сеанса на

стороне клиента, сохранение состояния сеанса в БД, сохранение состояния сеанса на стороне

сервера.

В более сложных случаях, чем в рассмотренном выше примере (см. рис. 12), один интерфейс

удаленного доступа

может выполнять роль шлюза для нескольких объектов с высокой степенью

детализации. Например, интерфейс удаленного доступа для объекта Заказ может применяться для

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

покупателе, разместившем этот заказ. При этом клиенту может потребоваться, например, получить с

сервера связный граф объектов

, относящихся к объектам предметной области. Для реализации такой

передачи применяется объект переноса данных (data transfer object), возвращаемый клиенту за

один вызов, и содержащий не только те данные, которые запросил клиент, но и те, которые ему могут

понадобиться на следующем этапе взаимодействия с системой.

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

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

поддержки транзакций: очереди сообщений, задания на печать, банковские платежи и т.д. Поскольку

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

приложениях широко известны несколько алгоритмов диспетчеризации транзакций:

длинные транзакции,

транзакции запроса, отсроченные транзакции и т.д.

120

Поля объектов переноса данных, как правило, содержат значения стандартных типов (строки,

даты и т.д.), а также другие объекты переноса данных. Любые связи между такими объектами

должны укладываться в рамки простого графа, типа иерархии, в противоположность сложным

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

упрощенную форму объектов домена

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

множество записей – набор табличных записей, который возвращается в результате выполнения SQL-

запроса, сгенерированного доменом.

С целью «разворачивания» объектов переноса данных на обоих концах соединения

используется специальный объект, получивший название «сборщик», который создает объект

переноса данных на основе данных домена и наоборот – обновляет модель

домена данными из

объекта переноса данных. При создании объекта переноса данных сборщиком используется тот

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

большинстве случаев, в виде XML-документа) или в зашифрованном формате.

Помимо проработки вопросов, связанных с обеспечением интерфейса удаленного доступа,

необходимо предусмотреть интерфейс для любого источника

или получателя данных в системе.

Такие интерфейсы чаще всего называются шлюзом (gateway) и помимо доступа, например, к

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

доступ к XML-документам, транзакциям CICS

, W3C

, JDOM

и т.д.

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

специализированный код API того или иного источника или потребителя данных. Интерфейс шлюза

соответствует интерфейсу обычного объекта доступа к данным и может содержать набор

традиционных методов. При этом для получения доступа к удаленному источнику, объекты

приложения будут обращаться

к шлюзу, который в свою очередь будет преобразовывать вызовы

простых методов в вызовы специализированного API. Очевидно, что для перехода к другому

источнику данных в этом случае достаточно будет изменить только класс шлюза, а остальная часть

системы абсолютно не пострадает.

Следует подчеркнуть, что согласно идеологии применения целого ряда GoF-паттернов

(Indirection, Protect Variation,

Adapter) существует объективная необходимость применения

служебных классов типа «шлюз» для организации взаимодействия между различными подсистемами

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

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

фундаментальный принцип модульной декомпозиции «низкая внешняя связанность – высокое

внутреннее сцепление», а также повысить эффективность тестирования отдельных

компонентов за

счет сокращения количества тестовых наборов.

Пример организации двухуровневой архитектуры корпоративного приложения типа «клиент-

сервер» показан на рис. 13. Помимо узкоспециализированных шлюзов, предназначенных для

взаимодействия с БД, слой источника данных содержит шлюз, обеспечивающий доступ к внешним

источником или потребителям данных. Кроме того, в слое домена выделены подсистемы,

выполняющие независимые друг

от друга задачи, и взаимодействующие друг с другом посредством

межкомпонентного интерфейса. При поступлении удаленного вызова от клиента интерфейс

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

для обмена информацией между клиентом и сервером.

CICS (Command Execution Diagnostic Facility) – среда обработки транзакций фирмы IBM

W3C - World Wide Web Consortium

JDOM - Java-реализация популярного интерфейса доступа к документам (Document Object Model - DOM)