4.2. Проектирование программ с помощью метода Джексона

Автор: Майкл Джексон, 1975 г., Лондон.

Основные управляющие структуры:

1. Последовательность (seq, рис. 1). A состоит из B, C, D именно в таком порядке.

2. Структура выбора (sel, рис. 2). В правом верхнем углу ставится 0, означающий, что S состоит из X или Y. На нижнем уровне не менее 2-х элементов.

3. Итерация (iter, рис. 3). I состоит из E, повторяющегося 0–n раз. На это указывает «*» в правом верхнем углу.

Нотация:

– элемент – команда (например, (R) – чтение)

Основные этапы проектирования:

1. Описывается структура данных входа

2. Описывается структура данных выхода

3. Устанавливаются структурные соответствия между входом и выходом

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

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

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

Хорошине и плохие данные в методе Джексона (рис. 1)

Допустимые – специфируются для обработки, т.е. результат ожидается.

Недопустимые – результат непредсказуем.

Ошибочные – допустимые, но некорректные.

Рассматриваются 4 вида ошибок:

1. Пропуск (отсутствие записи или ее элемента)

2. Вставления (лишняя запись или ее элемент)

3. В содержании (запись отнесена к определенному типу, но ее элементы некорректны)

4. Ошибки в связях с другими данными

Дополнительные вопросы:

Метод множественного предварительного чтения: предназначен для проверки ошибок в связях. Буфер на входе.

Метод отката: буфер на выходе. Вместо слов «и» и «или» пишут допустить, отвод и принять.

Могут возникнуть несколько несоответствий при проектировании методом Джексона:

1. Порядковое столкновение структур. Записи на входе и выходе отсортированы по разным ключам. Решение:

• Входные данные переписать в память с другой сортировкой

• Прямой доступ по ключу

• Пересортировка (выходных данных)

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

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

4.3. Case-средства разработки информационных систем (ис)

1. Методологическая основа – STRADIS. STRategic Architecture for the Deployment Information Systems

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

Жизненный цикл в STRADIS:

1. Стратегическое планирование. 2. Анализ требований к информационной системе и быстрое создание прототипа. 3. Проектирование информационной системы. 4. Разработка (программирование и проверка информационной системы). 5. Инсталляция и ввод в эксплуатацию. 6. Сопровождение.

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

STRADIS определяет документы (поэтапно):

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

2. Вход (из 1):

• начальное обоснование разработки (возможные выгоды, оценка затрат времени на разработку)

• Детальное обоснование разработки (цели создания системы, логическая модель, детальная оценка средства; принимается решение о целесообразности разработки)

• Эскизные требования к системе (уточняется логическая модель и цели новой системы)

• Требования к реализации системы (к СУБД, ЯП, техническим и программным средствам)

• Детальные требования к системе

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

4. Разработка и реализация (программирование проверка) сверху вниз

5. Устанавливаются технические средства, обучение пользователей

6. Идет проверка функционирования системы в реальной среде, тонкая настройка, подготовка и конвертирование файлов и испытание

Работы: 1. Прием и оценка предложений по изменению. 2. Контроль реализации требований к развитию. 3. Контроль к проведению изменений

Не реже чем раз в 2 года анализ инсталлированной системы (степень удовлетворения потребностей пользователей). Решение: создавать ли новую систему?

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

Обеспечение качества разработки:

1. Структурный просмотр – нахождение максимума ошибок в разрабатываемом проекте

2. Техническая инспекция – формальный характер: проверяется полнота, согласованность и правильность

3. Управленческая инспекция состоится после первых двух и принимает решение о продолжении работ