Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Metodologia_SSADM.doc
Скачиваний:
77
Добавлен:
13.04.2015
Размер:
1 Мб
Скачать
☆

Интерфейс процесс - данные.

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

• ранжирование СУБД;

• распределение данных (возможно использование однородной сети, состоящей из различных СУБД-продуктов);

• использование возможностей стандартных языков манипулирования данными (таких как SQL);

• заимствование элементов развитых иерархических СУБД.

1.6 Достоинства инвариантности к реализации проектов

Отличительной чертой подхода SSАDМ к физическому проектированию является наличие предварительно разработанной спецификации логической системы. Эта форма спецификации обеспечивает относительную независимость от конкретной реализации на объекте информатизации, что в свою очередь предоставляет следующие преимущества SSАDМ-проектам: инвариантность; гибкость; бизнес-ориентацию; прагматизм.

Инвариантность.

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

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

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

Гибкость.

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

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

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

Бизнес-ориентация.

Самым большим достоинством инвариантности к реализации является ее особое место при проектировании систем, удовлетворяющих потребности бизнеса. Естественна склонность разработчиков с самого начала проектировать средства реализации для каждой отдельной среды. Однако это может скомпрометировать методологию проектирования системы, так как некоторые необходимые элементы функционального наполнения могут быть исключены, если известно, что "продукт X" не сможет поддержать их. Это полностью противоречит концепциям SSADM, приматом которой при проектировании любых возможных систем является стремление полностью удовлетворять потребности бизнеса. Введение отвлекающих от функциональной по сути проекта характеристик, относящихся к стадии реализации проекта, на ранних стадиях проектирования может только нанести вред поиску наиболее подходящего проектного решения. На рис. 1.13 показывается тенденция наращивания степени детализации проекта системы по мере продвижения по стадиям жизненного цикла и отмечена область возможного начала реализации проекта.

Прагматизм.

Несмотря на сделанные выше замечания, существуют обстоятельства, при которых программно-аппаратная среда известна до начала физического проектирования или существуют весомые аргументы за реализацию системы в особой среде (основные примеры - совместимость и существование хорошей технической базы). Было бы неразумно пренебрегать этой ключевой информацией. Методология SSADM не препятствует этому, позволяя группе разработчиков извлечь максимум выгоды из имеющихся знаний о программно-аппаратной среде и эксплуатации возможностей этой среды при разработке логического проекта (см. рис.1.13).

Рис. 1.13. Иллюстрация независимости процесса проектирования от конкретной реализации физической системы

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]