Новиков Ф.А. Учебно-методическое пособие по дисциплине Технологические подходы к разработке программного обеспечения

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

УМП Технологические подходы к разработке ПО 101

5.3.2. Спецификации и модели

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

информации, циркулирующий в циклах повышения продуктивности (см. рис. 38), прохо-

дящих через программистов и заказчиков. Если информация, циркулирующая в левом

цикле, представлена совершенно формально, например, в виде программного кода, то она

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

ного использования при проектировании. Если информация, циркулирующая в правом

цикле, представлена совершенно неформально, например, в виде текстов (устных или

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

значной и неопределенной) для использования при анализе и последующем проектирова-

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

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

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

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

(Unified Modeling Language).

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

ее движения, как показано на рис. 38:

Пользовательские требования (или внешние спецификации) — от заказчиков на фазы ана-

лиза и проектирования;

Пользовательская документация (или детальные спецификации) — от фаз стабилизации и

внедрения к заказчику;

Реализованный компонент со спецификацией (важно наличие кода) — от фазы реализации

к программистам;

Специфицированный компонент (важно наличие спецификации)

— от программистов

(или из репозитория) к фазе проектирования.

Во всех случаях информация имеет одну и ту же семантику — это некоторая специфика-

ция (т.е. описание) программы или компонента программы, но разную прагматику (т.е.

предназначение). Очевидно, что если все виды спецификаций будут вдобавок выражены в

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

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

программирования.

Рис. 38 немного уточняет рис. 4.

Тот факт, что на практике внешние спецификации зачастую готовятся силами сотрудников , не меняет сути дела: при

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

На рис. 4 и 38 отсутствуют фазы опытной эксплуатации и внедрения. Это сделано только для наглядности рисунка. На

самом деле эти фазы подразумеваются.

Или в репозиторий.

При проектировании вполне можно использовать еще не реализованные компоненты, лишь бы они были хорошо спе-

цифицированы!

УМП Технологические подходы к разработке ПО 102

Анализ

Проектирование

Реализация

Стабилизация

Программисты

Заказчики

Внешние спецификации

Реализованный компонент

Пользовательская документация

Специфицированный компонент

Рис. 38. Движение спецификаций в циклах повышения продуктивности

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

гаются разные требования:

• при спецификации реализованного компонента наиболее важными являются точ-

ность и полнота спецификаций, а наилучшей в этом смысле спецификацией про-

граммы является сам текст программы;

• при описании программы для пользователя важнее всего понятность, и поэтому в

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

родной) язык;

• при повторном использовании компонентов самым важным является специфика-

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

ные модели;

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

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

цификации.

В качестве средства спецификации, которое одновременно удовлетворяет (в достаточной

степени) этим противоречивым требованиям наиболее целесообразно использовать мо-

дель программы, выраженную в графической нотации UML.

Диаграммы, которые со-

ставляют модель UML, удовлетворяют поставленным требованиям в следующем смысле.

Будучи строгим и формальным, хотя и графическим языком, UML обладают достаточной

точностью для (полу) автоматической генерации кода.

Замечание

Не следует рассматривать UML в качестве альтернативы обычным средствам программиро-

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

делирования.

Диаграммы UML достаточно понятны, чтобы служить средством коллективного модели-

рования и обмена мнениями с заказчиками.

Пользователи не будут читать код, будь он хоть трижды самодокументированный!

Если объектная модель представлена в графической форме, пользователь может согласиться ее посмотреть.

В некоторых случаях целесообразно дополнительно к UML использовать и другие средства.

УМП Технологические подходы к разработке ПО 103

Замечание

Традиционно считается, что самым понятным является текст с иллюстрациями. Но иллюст-

рации с текстом еще понятнее, т.к. короче — из текста удалена связующая "вода".

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

Замечание

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

объектов (т.е. службы) и не связаны ограничениями конкретной системы ОО программиро-

вания.

Графическая форма моделей UML является наиболее наглядной из известных.

Замечание

Конечно, использование UML не избавляет от риска составить совершенно ненаглядную,

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

средства моделирования.

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

ного порога непривычности). Программе всегда предшествует модель, потому что про-

грамма не может возникнуть ниоткуда. Модель всегда имеет место, даже если бесприн-

ципный программист открещивается от нее. Начиная с некоторой пороговой величины

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

явно превзойден) дополнительные трудозатраты на визуальное моделирование в каждом

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

тов в целом.

5.4. Программная архитектура

Архитектура приложения — это набор принципов, используемых при принятии решений

в процессе разработки и оценки приложения.

Замечание

Набор принципов может отсутствовать. Такое программирование называется беспринцип-

ным и здесь не рассматривается.

На архитектуру приложения (или программного решения иного типа) оказывают влияние

множество факторов:

тип приложения (информационная система, система управления, встроенная система и

т.п.);

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

дополнительные требования (надежность, секретность и пр.);

предметная область (бизнес, наука, транспорт и т.п.);

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

другое.

Сколько существует возможных комбинаций значений перечисленных (и не перечислен-

ных) факторов, столько можно усмотреть различных (и в некотором смысле наилучших)

архитектур. Таким образом, единственной рекомендуемой архитектуры (набора руково-

дящих принципов) нет и быть не может.

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

могут иметь сходную архитектуру. В сущности,

типовая архитектура (или модель) при-

ложения, которая предлагается, например, в MSF, является обобщением некоторых типо-

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

чи применены в большом числе реальных приложений для бизнеса. Сама возможность

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

членении некоторых типовых черт, присущих приложениям рассматриваемого класса.

Рассматриваемые приложения имеют следующие характерные особенности:

• интерфейс с пользователем, т.е. в интерфейсе приложения подразумевается нали-

чие пользователя, интерфейс с другими программами или с аппаратурой либо от-

сутствует, либо носит вспомогательный характер;

УМП Технологические подходы к разработке ПО 104

• многофункциональность, т.е. наличие нескольких, зачастую разнородных функ-

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

приложения, которое не обладает такой особенностью — транслятор с языка про-

граммирования);

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

бизнеса) с учетом особенностей самого бизнеса и даже конкретного предприятия;

• рутинность, т.е. принципиальная заведомая разрешимость и невысокая наукоем-

кость решаемых задач;

• много пользователей, т.е. наличие нескольких категорий пользователей приложе-

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

правами по отношению к приложению;

• модифицируемость, т.е. постоянное изменение функций в процессе эксплуатации

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

В следующих разделах рассматриваются некоторые архитектурные решения, характерные

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

5.4.1. Событийное управление

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

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

функцию, следуя заложенному в нее алгоритму решения задачи, запрашивая по мере не-

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

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

состоянии ожидания

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

муся у него в голове алгоритму решения задачи, а программа выполняет подаваемые ко-

манды (т.н. пассивный интерфейс).

В настоящее время более распространенным, особенно в приложениях рассматриваемого

класса, является второе решение (так называемый пассивный интерфейс). Это обусловле-

но целым рядом причин, в том числе:

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

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

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

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

наличием в современных системах программирования и операционных системах для дан-

ной архитектуры развитого механизма поддержки

, называемого событийным управлени-

ем

(event-driven), который описан ниже;

устоявшейся за последние несколько лет привычкой массового пользователя к пассивно-

му интерфейсу.

Замечание

Следует иметь в виду, что при всех своих достоинствах пассивный интерфейс обладает и

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

ется алгоритм решения задачи и что пользователь в состоянии транслировать этот алго-

ритм в последовательность команд приложения. Пафос, с которым фирмы, производящие

массовые приложения, восхваляют "прозрачность", "интуитивность", "простоту" и т.п. ин-

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

виальной.

Событийное управление — это способ структуризации программного кода, основанный на

следующей идее. Имеется некоторое предопределенное множество поименованных собы-

тий. События могут быть явным образом связаны с объектами, а могут быть связаны не-

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

термин АРМ — Автоматизированное Рабочее Место.

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

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

УМП Технологические подходы к разработке ПО 105

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

называют системными. События могут возникать. Возникновение события подразумева-

ет, что состояние системы изменилось определенным образом. С событием может быть

связана процедура, которая называется реакцией на событие. При возникновении события

автоматически вызывается процедура реакции. В современных системах программирова-

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

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

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

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

и т.д. В программе, целиком управляемой событиями, нет основного потока управления,

он находится вне программы (в операционной системе или в административной системе

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

Управление в программу попадает только в форме вызова процедуры реакции. Такая ор-

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

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

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

подходит для реализации пассивного интерфейса.

Замечание

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

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

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

Поэтому событийное управление называют еще асинхронным.

В современных системах программирования имеются богатые и все время развивающиеся

библиотеки готовых компонент, которые называются элементы управления (controls), и

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

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

мендовано в большинстве случаев.

Замечание

У неумелых программистов существует иллюзия, что программировать вертикальные при-

ложения с пассивным интерфейсом очень просто: достаточно выслушать (даже не записав!)

перечень команд приложения, в том виде, как их представляет себе заказчик (пользователь),

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

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

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

недопустимо большом числе случаев заказчик будет не удовлетворен результатом.

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

имеет в голове правильную (с точки зрения приложения) программу выполнения функции

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

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

компактным и ортогональным приводит к тому, что часто последовательность команд,

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

целостности корпоративных данных). В лучшем случае проверка выполнения всех усло-

вий целостности предусматривается умелым программистом в процедуре реакции по-

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

чает отказ программы выполнять операцию при нажатии самой невинной кнопки ОК. В

худшем случае программист не проверяет выполнение условий целостности в расчете на

то, что пользователь будет действовать только допустимым образом. В результате получа-

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

корпоративных данных.

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

"защита от дурака". Вопрос о том, кто же в данном случае является "дураком" — программист или пользователь —

очень спорен.

УМП Технологические подходы к разработке ПО 106

Существуют три основных метода решения этой проблемы.

Полный отказ от пассивного интерфейса и переход на активный интерфейс, который дер-

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

ствий. Такой подход был характерен для старых приложений на больших машинах кол-

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

тически важных (critical mission) приложениях или в приложениях с малым числом жестко

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

Включение в приложение с пассивным интерфейсом большого количества проверок цело-

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

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

прогнозирования и коррекции действий пользователя. Такой подход очень хорош, но до-

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

ях.

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

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

ра, знакомые всем по приложениям Microsoft Office. Этот подход дешев в реализации и

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

стью приложения и удобствами пользователя. Можно рекомендовать использование мас-

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

Мастер — это активный сценарий (как правило, линейный), выраженный средствами пас-

сивного интерфейса.

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

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

сложной транзакции. Возможности современных элементов управления позволяют легко

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

приложения. Разумно подобранные значения параметров по умолчанию позволяют резко

ускорить выполнение типовых процедур. Мастера являются превосходной альтернативой

чисто событийному управлению при реализации процедур бизнеса. Выделение сценариев,

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

ного проектирования (см. ниже). Явными кандидатами на реализацию в виде мастера яв-

ляются элементы диаграммы использования (use case) верхнего уровня в модели прило-

жения.

Замечание

Microsoft Office содержит, по видимому, одну из самых богатых коллекций мастеров. Для

освоения этой техники настоятельно рекомендуется знакомство с мастерами Microsoft

Office, причем как с поистине гениальными Мастером диаграмм и Мастером сводных таб-

лиц в Excel, так и с другими, довольно убогими, которые нет нужды называть здесь.

Важно подчеркнуть, что решения об архитектуре интерфейса следует принимать с огляд-

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

произволу программиста.

5.4.2. Архитектура клиент/сервер

Термин архитектура клиент/сервер стал активно использоваться по мере распростране-

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

часто ассоциируется с наличием выделенного в сети компьютера (сервера) или с про-

граммой, выполняющейся на этом компьютере. Вообще говоря, архитектура кли-

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

компонент многокомпонентной программы. А именно, программа содержит некоторую

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

мых клиентами. Клиент имеет возможность асинхронно для сервера инициировать вы-

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

УМП Технологические подходы к разработке ПО 107

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

с сервером параллельно или квазипараллельно. Возможны два основных способа реализа-

ции архитектуры клиент/сервер:

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

инициируют клиенты;

активный сервер: сервер опрашивает клиентов на предмет наличия запроса.

В случае реализации на одном компьютере с фиксированным числом клиентов архитекту-

ра клиент/сервер сводится к событийному управлению. Интерес представляет случай, ко-

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

раллельно и число клиентов (и, может быть, серверов) динамически меняется. В настоя-

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

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

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

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

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

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

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

Для отказа от использования архитектуры клиент/сервер должны быть очень веские осно-

вания, обусловленные спецификой приложения.

Замечание

Не следует думать, что для реализации приложения в архитектуре клиент/сервер обязатель-

ным является использование дорогой готовой СУБД со словом "сервер" в названии. По-

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

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

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

ний в архитектуре клиент/сервер. Если требования заказчика по производительности, безо-

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

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

5.4.3. Службы

Служба (service) — это программная конструкция, обеспечивающая набор выполнение

набора операций (или услуг) с некоторыми объектами (или одним объектом).

Важно, что служба полностью специфицируется своим интерфейсом (сигнатурой услуг),

а внутренняя реализация службы скрыта от внешних клиентов службы, которые пользу-

ются услугами. В такой формулировке служба является очень широким понятием, вклю-

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

вания. Программная реализация служб может быть существенно различной и зависеть от

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

характеристик службы, как компоненты ОО программы. Можно принимать во внимание

различные объектные характеристики службы и, соответственно, использовать различные

методы реализации. Например, существенным образом влияют на выбор метода реализа-

ции такие характеристики:

Постоянство объектов: имеет

служба внутреннюю память или нет, т.е. должно ли со-

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

мя. Возможные значения этой характеристики:

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

рирует (например, машинная арифметика).

Оперативная служба, т.е. служба, объекты которой существуют во время выполнения

приложения, использующего услуги службы (например, соединение ODBC).

УМП Технологические подходы к разработке ПО 108

Постоянная служба, т.е. служба, объекты которой существуют и сохраняют свое состоя-

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

файловая система).

Множественность экземпляров: обслуживает служба фиксированное или переменное ко-

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

значения этой характеристики:

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

роено большинство служб операционных систем.

Служба обслуживает статически определенный набор объектов (как, правило, именован-

ных).

Служба позволяет обслуживать заранее не известное множество объектов (как правило, в

состав службы включаются конструкторы и деструкторы).

Динамичность интерфейса: может ли меняться интерфейс службы, т.е. может ли менять-

ся сигнатура и/или

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

Службы имеет постоянный по сигнатуре и семантике интерфейс. Например, так устроено

большинство служб операционных систем.

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

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

Служба имеет заранее не известный клиентам интерфейс, который они должны опреде-

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

мического определения интерфейса).

В таблице 6 приведены некоторые примеры способов реализации служб.

Таблица 6. Примеры способов реализации служб

Характеристика Представление Идентификация объектов

Постоянная служба над множествен-

ными объектами с постоянным (или

консервативно расширяемым) интер-

фейсом

Реляционная СУБД с хранимыми

процедурами. У всех объектов оди-

наковая структура и они различаются

только значениями свойств. Объект

представляется записью в БД

Первичный ключ записи

Служба без памяти с единственным

объектом и статическим интерфей-

сом

Библиотека динамического связыва-

ния

Отсутствует

Оперативная служба над множест-

венными объектами и статическим

интерфейсом

Библиотека динамического связыва-

ния. Объект представляется структу-

рой (или объединением), указатель на

которую передается параметром ме-

тодам объекта

Типизированный указатель

Оперативная служба над фиксиро-

ванными объектами со статическим

или динамическим интерфейсом

Библиотека объектов Имя объекта

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

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

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

Так называемая "преемственность снизу-вверх".

Распространен предрассудок, что только синтаксис вида Object.Method(Arguments) является допустимым в ОО

программировании. Синтаксис Method(pObject,Arguments) ничуть не хуже, а зачастую лучше. Например, если

объект Человек имеет свойство Семейное_положение и метод Вступить_в_брак(супруг:Человек), то обес-

печить необходимую целостность данных не просто. Эта проблема исчезает, если имеется служба (без

памяти!) ЗАГС, у

которой есть метод Регистрация_брака(муж,жена:Человек).

УМП Технологические подходы к разработке ПО 109

Замечание

Не следует воспринимать таблицу 6 догматически: это только примеры возможных реше-

ний. В каждом конкретном случае умелый программист, как творец программы, волен в

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

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

уже разработанной. Готовые программные решения представления служб следует заимство-

вать из репозитория, если они прошли проверку практикой.

5.4.4. Трехслойная архитектура

В недавнем прошлом широкое распространение получила типовая модель приложения,

которая здесь называется трехслойной (three-tier). В наиболее рафинированной форме эта

модель изложена в MSF. В этой модели приложение мыслится как набор взаимодейст-

вующих служб, которые распределены по трем слоям, перечисленным в Таблице 7.

Таблица 7. Трехслойная архитектура приложения

Слой Функция

Пользовательский интерфейс (User Services) Ввод и отображение информации, навигация в приложении

Бизнес-правила

(Business Services) Принятие решений, обработка данных

Управление данными (Data Services) Доступ к данным

Трехслойная архитектура обладает целым рядом очевидных структурирующих досто-

инств:

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

ные) интерфейсы для одного приложения. Такая возможность важна, например, если при-

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

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

другим причинам.

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

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

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

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

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

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

Замечание

В чисто информационных системах (т.е. в таких системах, которые представляют собой не

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

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

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

данных называется подсхемой или представлением (view). Это дает возможность, например,

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

зуемой СУБД.

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

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

компонентов по компьютерам в распределенном приложении. Здесь возникают различные

варианты, например, такие, которые приведены на рис. 39 в разделе Распределение ком-

понентов.

5.5. Проектирование программ

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

проектирования является решающим фактором повышения продуктивности программи-

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

слой служб просто "обработка".

УМП Технологические подходы к разработке ПО 110

рования (см. раздел Продуктивность программирования). В классических инженерных

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

смысл: проектирование начинается, когда имеется описание (как правило, текстовое) на-

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

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

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

нерных дисциплин, термин проектирование носит более размытый характер. К проекти-

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

цикла: определение назначения программы на фазе анализа (что аналогично формулиро-

ванию Технических условий), функциональную спецификацию программы на фазе проек-

тирования, построение кода методом пошагового уточнения на фазе реализации (которое

уже гораздо ближе к воплощению "в металле").

Замечание

Приведенная аналогия носит условный характер. Например, для современного CAD/CAM

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

жет иметь форму перфоленты для станка с ЧПУ. Тем не менее, эта аналогия полезна, по-

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

грамм в дисциплине программирования . Целью является приближение моделей программ к

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

ства, которые достигнуты в схемах инженеров-электронщиков или чертежах инженеров-

автомобилестроителей.

Проектирование программы (в широком смысле этого слова) имеет различные цели и мо-

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

виды проектирования:

• концептуальное проектирование;

• логическое проектирование;

• детальное проектирование.

5.5.1. Концептуальное проектирование

Концептуальное проектирование выполняется на фазе анализа и его результаты отража-

ются в Концепции и во Внешней функциональной спецификации. Методы концептуаль-

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

рования, как правило, оформляются в виде текста на естественном языке с включением

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

достигнуты следующие основные цели.

5.5.1.1. Определение существа проблемы

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

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

вышение эффективности имеющегося решения, снижение стоимости имеющегося реше-

ния, комбинация выше названного или нечто другое.

5.5.1.2. Идентификация предметной области

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

причем как внешние границы (область желаемого), так и внутренние (область абсолютно

необходимого).

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

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

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

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

области).

Аналогичная классификация видов проектирования используется в MSF.