- •1. Кризис программирования
- •2. Понятие жизненного цикла по
- •3. Требования к технологии проектирования
- •4. Понятия профессионального программирования
- •5. Проект и команда
- •6. Задача профессионального программирования
- •7. Алгоритмы
- •8. Модели и моделирование
- •9. Структурный подход
- •9.1. Проблема сложности
- •9.2. Сущность структурного подхода
- •9.3. Метод функционального моделирования (sadt)
- •9.3.1. Состав функциональных моделей
- •9.3.2. Методика построения модели
- •9.4. Метод моделирования процессов - потоков данных (dfd)
- •9.4.1. Общая концепция
- •9.4.2. Состав диаграмм потоков данных
- •13. Венгерская нотация
- •14. Методология и парадигма программирования
- •15. Современные методологии программирования
- •16. Методология императивного программирования
- •17. Методология объектно-ориентированного программирования
- •18. Методология функционального программирования
- •19. Методология логического программирования
- •20. Методология программирования в ограничениях
- •21. Методология структурного императивного программирования
- •22. Методология параллельного императивного программирования
- •23. Методология нейросетевого программирования
- •23.1. Модель нейрона с линейной функцией активации
- •23.2. Модель нейрона с радиальной функцией активации
- •23.3. Разработка нейросетевой модели
- •24. Основные типы ошибок в программах
- •25. Отладка и тестирование
- •26. Режимы работы компилятора Delphi для поиска ошибок
- •27. Задание режимов работы отладчика с помощью переключающих директив
- •28. Пользователи и их поддержка
- •29. Поддержка программиста: общие требования
- •29.1. Пролог модуля
- •29.2. Проектная документация
- •29.3. Оформление текста программы
- •30. Поддержка конечного пользователя
- •31. Технология программирования графики
- •31.1. Графическая подсистема оболочек Win32/64
- •31.2. Графические средства Delphi
- •31.3. Проектирование интерфейса с пользователем: компоненты стандартных диалогов
- •32.Технология компонентного программирования
- •32.1. Технология com
- •32.1.1. Общая концепция
- •32.1.2. Интерфейс com
- •32.1.3. Сервер com
- •32.2. Технология ole
- •32.2.1 Суть и содержание ole
- •32.2.2.Терминология ole
- •32.2.3. Автоматизация ole
- •32.2.4. Структурированная память
- •32.3. Технология corba
- •32.4. Технология Java
- •32.5.Технология .Net
- •33. Технология описания аппаратуры
- •Input clock, reset, en;
- •If(!reset)
- •34. Технология коллективной разработки
- •34.1. Авторская разработка
- •34.2. Коллективная разработка
- •34.2.1. Технические командные роли
- •34.2.2. Психологические командные роли
- •34.2.3. Типы совместной деятельности
- •34.3. Общинная модель разработки
- •35. Технология оценки качества по
- •35.1. Подходы к оценке качества по
- •35.2. Характеристики качества по
- •35.3. Оценка качества процесса разработки
- •35.3.1. Модель зрелости процесса разработки по
- •35.3.2. Определение возможностей и улучшение процесса создания по
- •35.4. «Достаточно хорошее» по
- •33.5. Стандартизация информационных технологий
- •Международные организации, входящие в структуру оон.
- •Промышленные профессиональные или административные организации.
- •Промышленные консорциумы.
- •36. Инструментальные средства поддержки некоторых технологических подходов
- •36.1. Инструментальные системы
- •36.1.1. Инструментальные среды программирования
- •36.1.2. Средства автоматизации разработки программ (case-средства)
- •36.1.3. Интегрированные среды
- •36.1.4. Репозитории проекта
- •36.2. Поддержка коллективной разработки: системы управления версиями
- •37. Организация диалогов
- •38. Защита программного кода
9.2. Сущность структурного подхода
Сущность структурного подхода к разработке ПО заключается в его разбиении на автоматизируемые функции: система разбивается на функциональные подсистемы, которые, в свою очередь делятся на подфункции, те – на задачи и так далее, до конкретных процедур.
Для описания системы используются две группы средств:
Описывающие функциональную структуру системы.
Описывающие отношение между данными.
В обоих случаях широкое распространение получили следующие модели:
Structured Analysis and Design Technique (SADT) – модели и соответствующие функциональные диаграммы;
Data Flow Diagrams (DFD) – диаграммы потоков данных;
Entity-Relationship Diagrams (ERD) – диаграммы «сущность-связь».
9.3. Метод функционального моделирования (sadt)
Метод SADT – это совокупность процедур и правил, предназначенных для построения функциональной модели объекта в какой-либо предметной области.
Функциональная модель SADT отображает функциональную структуру объекта, т.е. производимые им действия и связи между этими действиями.
Основные концепции метода:
Графическое представление блочного моделирования. Элемент модели (диаграммы) – блок, отображающий функцию. Дуги блока – интерфейсы входа-выхода, предназначенные для взаимодействия блоков друг с другом.
Строгость и точность. Правила SADT включают:
ограничение количества блоков на каждом уровне декомпозиции (3÷6 блоков);
связность диаграмм (через номера блоков);
уникальность меток и наименований (без повторов);
синтаксические правила для графики (блоков и дуг);
разделение входов и управлений (правило определения роли данных).
Отделение организации от функции. Необходимо исключить влияние административной структуры организации на функциональную модель.
9.3.1. Состав функциональных моделей
Модель SADT строится из следующих элементов:
Диаграммы.
Фрагменты текстов.
Глоссарий.
Ссылки друг на друга между перечисленными элементами.
Диаграммы – главные компоненты модели. Все функции организации и интерфейсы на них представлены как блоки и дуги соответственно.
Место соединения дуги с блоком определяет тип интерфейса. Управляющая информация входит в блок сверху, в то время как входная информация, которая подвергается обработке, показана с левой стороны блока, а результаты (выход) показаны с правой стороны. Механизм (человек или автоматизированная система), который осуществляет операцию, представляется дугой, входящей в блок снизу.
На диаграммах используются пять типов взаимосвязей между блоками.
На приведенном рисунке тип отношений между блоками определяется как (а) – «управление», (б) – «вход», (в) – «управленческая обратная связь», (г) – «входная обратная связь», (д) – «выход-исполнитель».
9.3.2. Методика построения модели
Построение SADT–модели начинается с определения всей системы в виде простейшего компонента – одного блока и дуг, изображающих интерфейсы с функциями вне системы.
Поскольку единственный блок отражает систему как единое целое, имя, указанное в блоке, является общим. Это верно и для интерфейсных дуг – они также соответствуют полному набору внешних интерфейсов системы в целом. Этот блок представляет систему в качестве единого модуля.
Затем первый компонент детализируется на другой диаграмме с помощью нескольких блоков, соединенных интерфейсными дугами. Эти блоки определяют основные подфункции исходной функции. Каждая из этих подфункций может быть декомпозирована далее подобным образом в целях большей детализации.
Каждая подфункция может содержать только те элементы, которые входят в исходную функцию. Также модель не может опустить какие-либо элементы, (т.е., родительский блок и его интерфейсы обеспечивают контекст). К контексту нельзя ничего добавить, и из него не может быть ничего удалено.
Модель SADT представляет собой серию диаграмм с сопроводительной документацией, разбивающих сложный объект на составные части, которые изображены в виде блоков.
Диаграмма предыдущего уровня называется родительской для более детальной диаграммы.
Дуги, входящие в блок и выходящие из него на диаграмме верхнего уровня, являются точно теми же самыми, что и дуги, входящие в диаграмму нижнего уровня.
Не присоединённые дуги соответствуют входам, управлениям и выходам родительского блока. Источник или получатель этих пограничных дуг может быть обнаружен только на родительской диаграмме. Все пограничные дуги должны продолжаться на родительской диаграмме, чтобы она была полной и непротиворечивой.
На SADT-диаграммах не указаны явно ни последовательность, ни время. Обратные связи, итерации, продолжающиеся процессы и перекрывающиеся (по времени) функции изображаются с помощью дуг.
Обратные связи могут выступать в виде комментариев, замечаний, исправлений и так далее.