Структурные диаграммы

вопросы проектирования
2 семестр
Информатика. 2 семестр. Тема 02. Проектирование

Проектирование

символы, их размеры, а также правила построения блок-схем определены государственными

стандартами.

ГОСТ 19.701-90. Схемы алгоритмов, программ, данных и систем. Условные обозначения и правила выполнения.
ГОСТ 19.002-80. Схемы алгоритмов и программ. Правила выполнения.
ГОСТ 19.003-80. Схемы алгоритмов и программ. Обозначения условные графические

Информатика. 2 семестр. Тема 02. Проектирование

результате чего изменяется значение, форма представления или расположения данных.
Внутри символа

или же в виде комментария на естественном языке или в виде формулы записываются действия, которые производятся при выполнении операции или группы операций.

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

Информатика. 2 семестр. Тема 02. Проектирование

зависимости от некоторых переменных условий.
Символ используется для изображения унифицированных структур:
РАЗВИЛКА

ПОЛНАЯ
РАЗВИЛКА НЕПОЛНАЯ
ВЫБОР
ЦИКЛ-ДО
ЦИКЛ-ПОКА

Модификация. Выполнение операций, меняющих команды или группу команд, изменяющих программу.
Символ используется для изображения унифицированной структуры ЦИКЛ С ПАРАМЕТРОМ. Внутри символа записывается параметр цикла с указанием начального и конечного значений, а также шаг изменения цикла, если он не равен единице.

Информатика. 2 семестр. Тема 02. Проектирование

хранения, ввода-вывода, базой данных, элементами управления или временным хранилищем в

оперативной памяти.

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

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

Информатика. 2 семестр. Тема 02. Проектирование

носителя малой ёмкости, стандартизированного дизайна и, как правило, однократной записи

– перфоркарты, RFID-метик или штрих-кода.

Лента. (устар.) Ввод-вывод данных в «человеко-читаемом» виде на носитель или устройство, имитирующее бумажную ленту (перфоленту, кассовую ленту, стример, «бегущую строку», последовательный канал передачи данных).

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

Документ. Ввод - вывод данных, носителем которых служит бумага.

Информатика. 2 семестр. Тема 02. Проектирование

линий потока:
1) линии потока должны быть параллельны линиям внешней рамки

блок-схемы (границам листа, на котором изображена блок-схема);
2) направление линии потока сверху вниз и слева направо принимается за основное и стрелками не обозначается, в остальных случаях направление линии потока обозначается стрелками;
3) изменение направления линии потока производится под углом 90 градусов;
4) слияние (объединение) линий (кроме тривиальных случаев) должно обозначаться узлом или концевыми стрелками на линиях потоков.

Old style:

Информатика. 2 семестр. Тема 02. Проектирование

символы. Если блок-схема состоит из нескольких частей, расположенных на одной

странице, то линия потока одной части заканчивается символом СОЕДИНИТЕЛЬ, а линия потока на продолжении блок-схемы начинается с этого же символа. Внутри символов СОЕДИНИТЕЛЬ ставятся одинаковые порядковые номера, соответствующие разорванной линии потока

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

Информатика. 2 семестр. Тема 02. Проектирование

данных или выполнения программы.
Комментарий. Связь между элементами схемы и пояснениями.
Позволяет

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

Информатика. 2 семестр. Тема 02. Проектирование

основе заданных (определенных) функциональных зависимостей
Графическое (описательное) Анализ элементов системы,

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

Информатика. 2 семестр. Тема 02. Проектирование

Моделирование

Численное
Анализ состояний системы на основе методов численного оценивания параметров на основе зависимостей, заданных аналитически (явно или косвенно), стохастически или алгоритмически

Имитационное (описательное) Предсказание поведения системы на требуем уровне детализации в заданных условиях работы

конкретную функцию, элемент, действие или состояние системы и свод правил

для их использования при описании состояния информационной системы (в том числе АСУТП)

Информатика. 2 семестр. Тема 02. Проектирование

Функциональное моделирование
SADT (IDEF0)

Анализ вариантов использования Use Cases (UML)

IDEF1x)
Анализ ответственности
CRC
Моделирование поведения
Activity diagrams (UML)
И многое другое…

системы, несущий информацию о её структуре, составе и (или) функциональности
Определения:
Словарь

(glossary)
Свод описаний (картотека, справочник) всех диаграмм и элементов, существенных для понимания модели

Подшивка (booklet)
Правило объединения диаграмм в модель с учётом связи между ними и версионности

Декомпозиция (decomposition)
Метод рассмотрения модели на основе последовательного разбора (уточнения) элементов диаграмм и описаний более высокого уровня обобщения

хранения вспомогательной информации и ограничивающая область рассмотрения диаграммы
Жизненный цикл

разработки
Последовательность смены фаз работы с моделью и её фрагментами

нисходящего проектирования и связывает диаграммы между собой по принципу «от

общего к частному»

последовательное все более подробное рассмотрение системы от «от общего к

частному»

Функциональность можно проверить только после окончания всех работ,
но можно исключить общие ошибки

Имея «общее» представление о будущей системе добавляем функции, а затем добиваемся их интеграции

В каждый момент времени система работоспособна «по частям», но «интеграция» с каждым разом труднее

разработка
Большая длительность разработки с малым числом «внутренних ошибок»:
Функциональность части системы

доступна «почти сразу», но трудоемкость расширения всё время возрастает:

все модули совместимы (стандартизация форматов данных);
мало сбоев связанных с «неожиданными данными»;
легко искать ошибки в реализации так как есть подробная документация.

Однако только при пробной эксплуатации можно выявить:

ошибки в описании процессов;
ошибку выбора платформы;
ошибки в описании окружения, в том числе условий использования и интерфейса пользователя.

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

В какой-то момент нужно будет сделать полный рефакторинг

Но заказчик видит, что «процесс идет!»

функции в ядре не справляются или нужно расширить область их

применения, то добавляем отдельные функционирующие модули «маскируя» старую функциональность

Ядро

«Используемая» функция

Новая
«фича»

Имитация «старой» функции с новыми возможностями

Проблемы:

Многоядерность с «неполным» дублированием функций

Утрата или добавление поведения в маскирующих модулях, отлично от остальных

?

?

этапе внедрения
Заказчик - вижу результаты, давайте дальше!
…Держаться нету больше сил…
Эксперт

- пока замечаний нет… но не забудьте кое-что…

Разработчик - сделаем, запишем, всё ведь как на ладони!

Аналитик - хм…

Заказчик - всё хуже работаете!

Эксперт - опять всё поломалось, поправьте, Вы забыли кое-что, и, надо добавить вот это…

Разработчик - как ёжик в тумане, целый день без результата…

Аналитик - я же говорил…

планировании?




Качели

Модульный подход
Работаем над модулями изолированно, обеспечивая поддержку тестами
Составляющие:
Подробное описание бизнес-процессов;
Прототипы

(на VBA?) для проверки идей;
Максимальное разделение модулей на всех этапах и стандартизация;
Документирование каждого действия;
Обязательное покрытие системы тестами;
Большой опыт в разработке аналогичных систем;
Features добавляются только в прототипы.

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

области архитектуры системы

(внутренний)
Уточняет задачу
Следит за выполнением
Проверяет результаты
Эксперт (потребитель)
Будет использовать
Аналитик (интервьюер)
Собирает информацию
Моделирует бизнес-процессы
Проектировщик

(разработчик)
Моделирует систему
Разрабатывает стандарты

Программист (кодер)
Разрабатывает код системы

Испытатель (тестер)
Проверяет работоспособность

Специалист по внедрению
Сопровождает систему

(разработчик)
Моделирует систему
Разрабатывает стандарты
Программист (кодер)
Разрабатывает код системы
Испытатель (тестер)
Проверяет работоспособность
Специалист по

внедрению
Сопровождает систему

Трудозатраты

Срок начала этапа

2 недели

1,5 месяца

3 месяца

от 2-х недель

1 год

0 день

2 недели

2 месяца

5 месяцев

5,5 месяцев

* * *

Тестирование при внедрении

платформ и описывать систему «реализуемо»
Нужно отказываться от нереализуемых требований
В системе

не должно быть избыточности и противоречивости
Максимальное использование фреймворков

за внимание !!!
Контакты:
mami.testolog.ru
timid@mami.ru
inform437@gmail.com
Информатика. 2 семестр. Тема 02. Проектирование

Далее:
Введение

в ПиОА
Структурные диаграммы
Общие вопросы проектирования
Обработка данных
…