Методы анализа, ориентированные на структуры данных

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

Методы, ориентированные на структуры данных, обеспечивают:

1) определение ключевых информационных объектов и операций;

2) определение иерархической структуры данных;

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

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

Наиболее известны два метода: метод Варнье – Орра и метод Джексона.

Метод Варнье-Орра В методе Варнье – Орра для представления структур применяют диаграммы Варнье. Для построения диаграмм Варнье используют 3 базовых элемента: последовательность, выбор, повторение .

а

Последовательность b

c

Выбор a

+

c

а(1,n), где n – количество повторений

Повторение

Рис..3. Базовые элементы в диаграммах Варнье-Орра

Как показано на рис. 4 с помощью этих элементов можно строить информационные структуры с любым количеством уровнем иерархии.

Первичный Заглавные новости

раздел Национальные новости

Местные новости

Редакторский Редакторские колонки (1,3)

раздел Письма (1,N)

Газета Критика (0,1)

Вторичный Спортивные новости

Раздел +

Коммерческие новости

Рис. 4. Структура газеты в виде диаграммы Варнье

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

Метод анализа Джексона.

Как и метод Варнье – Орра, метод Джексона появился в период революции структурного программирования. Фактически оба метода решали одинаковую задачу: распространить базовые структуры программирования (последовательность, выбор, повторение) на всю область конструирования сложных программных систем. Именно поэтому основные выразительные средства этих методов оказались так похожи друг на друга.

Метод Джексона (1975) включает 6 шагов. Три шага выполняются на этапе анализа, а остальные – на этапе проектирования.

1. Объект - действий. Определяются объекты – источники или приемники информации и действия – события реального мира, воздействующие на объекты.
2. Объект- структура. Действия над объектами представляются диаграммами Джексона.
3. Начальное моделирование. Объекты и действия представляются как обрабатывающая модель. Определяются связи между моделью и реальным миром.
4. Доопределение функций. Выделяются и описываются сервисные функции.
5. Учет системного времени. Определяются и оцениваются характеристики планирования будущих процессов.
6. Реализация. Согласование с системной средой, разработка аппаратной платформы.

Основы проектирования программных систем

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

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

В ходе анализа ищется ответ на вопрос: «Что должна делать будущая система?». Именно на этой стадии закладывается фундамент успеха всего проекта. Известно множество неудачных реализаций из-за неполноты и неточностей в определении требований к системе. В процессе синтезаформируется ответ на вопрос: «Как, каким образом система будет реализовывать предъявляемые к ней требования?». Выделяют три этапа синтеза (рис. 5).: проектирование ПС,кодирование ПС, тестирование ПС .

Рассмотрим информационные потоки процесса синтеза. Этап проектирования питают требования к ПС, представленные информационной, функциональной и поведенческой моделями анализа. Иными словами, модели анализа поставляют этапу проектирования исходные сведения для работы. Информационная модель описывает информацию, которую, по мнению заказчика, должна обрабатывать ПС. Функциональная модель определяет перечень функций обработки. Поведенческая модель фиксирует желаемую динамику системы (режимы ее работы). На выходе этапа проектирования – разработка данных, разработка архитектуры и процедурная разработка ПС.

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

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

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

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

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

Рис. 5.Информационные потоки процесса синтеза ПС.

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

Обычно в проектировании выделяют две ступени: предварительное проектирование и детальное проектирование.

Рис. 6.Информационные связи процесса проектирования

Предварительное проектирование формирует абстракции архитектурного уровня, детальное проектирование уточняет эти абстракции, добавляет подробности алгоритмического уровня. Кроме того, во многих случаях выделяют интерфейсное проектирование, цель которого – сформировать графический интерфейс пользователя (GUI). Схема информационных связей процесса проектирования приведена на рис. 6.

Предварительное проектирование включает три типа деятельности:

1. Структурирование системы. Система структурируется на несколько подсистем, где под подсистемой понимается независимый программный компонент. Определяются взаимодействия подсистем.
2. Моделирование управления. Определяется модель связей управления между частями системы.
3. Декомпозиция подсистем на модули. Каждая подсистема разбивается на модули. Определяются типы модулей и межмодульные соединения.

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

Структурирование системы

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

1. модель хранилища данных;
2. модель клиент-сервер;
3. трехуровневая модель;
4. модель абстрактной машины.

В модели хранилища данных(рис. 7) подсистемы разделяют данные, находящиеся в общей памяти. Как правило, данные образуют БД. Предусматривается система управления этой базой.

Рис. 7.Модель хранилища данных

Модель клиент-сервер используется для распределенных систем, где данные распределены по серверам (рис. 8). Для передачи данных применяют сетевой протокол, например TCP/IP.

Рис. 8.Модель клиент-сервер

Трехуровневая модельявляется развитием модели клиент-сервер (рис.9).

Рис. 9.Трехуровневая модель

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

• упрощается такая модификация уровня, которая не влияет на другие уровни;
• отделение прикладных функций от функций управления БД упрощает оптимизацию всей системы.

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

Рис. 10. Модель абстрактной машины

Моделирование управления

Известны два типа моделей управления: модель централизованного управления; модель событийного управления.

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

Различают две разновидности моделей централизованного управления:

• модель вызов-возврат (рис. 11)
• модель менеджера (рис. 12), которая используется в системах параллельной обработки.

Рис. 11.Модель вызов-возврат

Рис. 12.Модель менеджера

В модели событийного управления системой управляют внешние события. Используются две разновидности модели событийного управления:

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

В широковещательной модели (рис. 13) каждая подсистема уведомляет обработчика о своем интересе к конкретным событиям. Когда событие происходит, обработчик пересылает его подсистеме, которая может обработать это событие. Функции управления в обработчик не встраиваются.

Рис. 13.Широковещательная модель

Рис. 14.Модель, управляемая прерываниями

В модели, управляемой прерываниями (рис. 14), все прерывания разбиты на группы – типы, которые образуют вектор прерываний. Для каждого типа прерывания есть свой обработчик. Каждый обработчик реагирует на свой тип прерывания и запускает свой процесс.