Модель Репозитория (хранилище данных)

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

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

Недостатки ОО подхода

Преимущество ОО подхода

1. Модели имеют меньший размер, т.к. возможно наследование.

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

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

4. Объектная модель естественна, поскольку ориентирована на человеческое восприятие мира.

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

2. Диаграммы отображают специфику этого подхода менее наглядно.

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

Разработка архитектуры подразумевает разработку трех аспектов проекта:

1. Его структуры (модель структуры),
2. Управление проектируемой системой (Модель управления),
3. Модульная декомпозиция.

Обычно разработка архитектуры начинается с разработки структуры проекта, хотя разработка всех трех аспектов – общий и взаимосвязанный процесс.

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

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

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

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

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

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

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

Архитектура интегрированного набора Case инструментов.

Преимущества этой модели:

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

2)Не требуется передавать данные из одной подсистемы в другую, что повышает эффективность.

3)Такие средства, как резервное копирование, безопасность, управление доступом, восстановление данных – централизованы, поскольку входят в систему управления «Репозитория».

4)Модель «Репозитории» прозрачна. В нее легко интегрировать новую подсистему.

Недостатки этой модели:

1)Формат данных «Репозитория» не может и не должен быть удобен для каждой отдельной подсистемы. Поэтому, подсистема, выбрав данные, должна перевести их в удобный для себя формат (увеличивает время, уменьшает эффективность).

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

3)Не все программы, входящие в систему предъявляют одинаково высокие требования к безопасности и резервированию, а СУБД относится ко всем данным одинаково (т.е. потеря эффективности).

Дата добавления: 2014-01-06