- •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. Защита программного кода
8. Модели и моделирование
Модель – это упрощенное представление реальности.
Моделирование рассматривают, как метод исследования систем на основе переноса изучаемых свойств системы на объекты другой природы.
Инженерная методика создания моделей позволяет:
визуализировать систему;
определить структуру системы и её поведение;
документировать принимаемые решения.
С моделированием тесно связано понятие абстрагирования. Абстрагирование – моделирование возможных реализаций программного продукта с выделением существенных особенностей и подавлением деталей.
Подобный прием (и не только!) позволяет рассматривать моделирование также в качестве попытки решить проблему сложности. В этом плане моделирование предоставляет несколько возможных подходов (различающихся способами декомпозиции систем) к разработке программного обеспечения:
Структурный (функционально–модульный).
Объектно-ориентированный.
Моделирование данных.
Моделирование знаний.
При использовании функционально–модульного подхода структура системы описывается в терминах иерархии её функций и передачи информации между отдельными функциональными элементами.
Применение объектно-ориентированного подхода предполагает описание структуры системы в терминах объектов и связей между ними, а поведения системы - в терминах обмена сообщениями между объектами.
Модель данных определяет правила порождения допустимых структур данных и возможные операции над такими структурами. Исторически термин «данные» происходит от латинского «datum», означающего «факт». Однако модели данных могут описывать и нечто, не имеющее место в реальной действительности.
Знание представляет собой особый, специфический вид информации. Знание характеризуется очень важным свойством, отличающем его от «просто данных» – активностью, то есть способностью самостоятельно обрабатывать информацию.
При этом выделяют четыре общих принципа, позволяющих процесс моделирования (создания и применения моделей по любому из рассмотренных выше подходов):
Выбор модели определяет подходы и получаемый вид решения проблемы.
Каждая модель может быть воплощена с разной с разной степенью абстракции.
Лучшими моделями являются те, которые ближе всего к реальности.
Следует использовать совокупность нескольких моделей.
9. Структурный подход
9.1. Проблема сложности
Сложность является основной проблемой при создании больших и сложных систем любой природы.
Главным способом преодоления сложности разработки больших программных систем является правильная декомпозиция.
Термин «декомпозиция» происходи от латинского «divide et impera», что означает «разделяй и властвуй». Далее по тексту термин «декомпозиция» применяется, как прием иерархического проектирования, который заключается в построении сложной системы, из небольшого количества крупных частей. При этом каждая крупная часть в свою очередь строится из частей меньшего размера и так далее, до тех пор, пока самые небольшие части можно будет строить из имеющегося материала.
«Правильная» декомпозиция – означает следующее:
количество связей между отдельными подсистемами – минимально;
связность отдельных частей внутри каждой подсистемы – максимальна;
При этом структура системы такова, что все взаимодействия между её подсистемами укладываются в стандартные рамки, то есть:
каждая подсистема скрывает своё содержимое от других подсистем;
каждая подсистема имеет чётко определённый интерфейс с другими подсистемами.
Сокрытие содержимого (в данном случае – абстрагирование или инкапсуляция) позволяет рассматривать структуру каждой подсистемы независимо от других подсистем.
Определенные интерфейсы позволяют строить систему более высокого уровня, рассматривая каждую подсистему как единое целое и игнорируя её внутренние устройство.