 |
Особенности этапа проектирования
|
|
|
|
Проектирование — итерационный процесс, при помощи которого требования к ПС транслируются в инженерные представления ПС. Вначале эти представления дают только концептуальную информацию (на высоком уровне абстракции), последующие уточнения приводят к формам, которые близки к текстам на языках программирования.
Обычно в проектировании выделяют две ступени: предварительное проектирование и детальное проектирование. Предварительное проектирование формирует абстракции архитектурного уровня, детальное проектирование уточняет эти абстракции, добавляет подробности алгоритмического уровня. Кроме того, во многих случаях выделяют интерфейсное проектирование, цель которого — сформировать графический интерфейс пользователя (GUI). Схема информационных связей процесса проектирования приведена на рис. 4.2.
Рис. 4.2. Информационные связи процесса проектирования
Предварительное проектирование обеспечивает:
q идентификацию подсистем;
q определение основных принципов управления подсистемами, взаимодействия подсистем.
Предварительное проектирование включает три типа деятельности:
1. Структурирование системы. Система структурируется на несколько подсистем, где под подсистемой понимается независимый программный компонент. Определяются взаимодействия подсистем.
2. Моделирование управления. Определяется модель связей управления между частями системы.
3. Декомпозиция подсистем на модули. Каждая подсистема разбивается на модули. Определяются типы модулей и межмодульные соединения.
Рассмотрим вопросы структурирования, моделирования и декомпозиции более подробно.
Структурирование системы
|
|
|
Известны четыре модели системного структурирования:
q модель хранилища данных;
q модель клиент-сервер;
q трехуровневая модель;
q модель абстрактной машины.
В модели хранилища данных (рис. 4.3) подсистемы разделяют данные, находящиеся в общей памяти. Как правило, данные образуют БД. Предусматривается система управления этой базой.
Рис. 4.3. Модель хранилища данных
Модель клиент-сервер используется для распределенных систем, где данные распределены по серверам (рис. 4.4). Для передачи данных применяют сетевой протокол, например TCP/IP.
Рис. 4.4. Модель клиент-сервер
Трехуровневая модель является развитием модели клиент-сервер (рис. 4.5).
Рис. 4.5. Трехуровневая модель
Уровень графического интерфейса пользователя запускается на машине клиента. Бизнес-логику образуют модули, осуществляющие функциональные обязанности системы. Этот уровень запускается на сервере приложения. Реляционная СУБД хранит данные, требуемые уровню бизнес-логики. Этот уровень запускается на втором сервере — сервере базы данных.
Преимущества трехуровневой модели:
q упрощается такая модификация уровня, которая не влияет на другие уровни;
q отделение прикладных функций от функций управления БД упрощает оптимизацию всей системы.
Модель абстрактной машины отображает многослойную систему (рис. 4.6).
Каждый текущий слой реализуется с использованием средств, обеспечиваемых слоем-фундаментом.
Рис. 4.6. Модель абстрактной машины
Моделирование управления
Известны два типа моделей управления:
q модель централизованного управления;
q модель событийного управления.
В модели централизованного управления одна подсистема выделяется как системный контроллер. Ее обязанности — руководить работой других подсистем. Различают две разновидности моделей централизованного управления: модель вызов-возврат (рис. 4.7) и Модель менеджера (рис. 4.8), которая используется в системах параллельной обработки.
|
|
|
Рис. 4.7. Модель вызов-возврат
В модели событийного управления системой управляют внешние события. Используются две разновидности модели событийного управления: широковещательная модель и модель, управляемая прерываниями.
Рис. 4.8. Модель менеджера
В широковещательной модели (рис. 4.9) каждая подсистема уведомляет обработчика о своем интересе к конкретным событиям. Когда событие происходит, обработчик пересылает его подсистеме, которая может обработать это событие. Функции управления в обработчик не встраиваются.
Рис. 4.9. Широковещательная модель
Рис. 4.10. Модель, управляемая прерываниями
В модели, управляемой прерываниями (рис. 4.10), все прерывания разбиты на группы — типы, которые образуют вектор прерываний. Для каждого типа прерывания есть свой обработчик. Каждый обработчик реагирует на свой тип прерывания и запускает свой процесс.
|
|
|
