
- •Oop и типы данных. Основные особенности ооп.
- •Инкапсуляция. Классы и структуры.
- •9.Подходы к выделению объектов, их свойств и методов оперирования.
- •10. Уточнение характеристик объектов и редактирование их определений.
- •11. Образцы и типовые проекты при ооп.
- •12. Именование объектов и методов. Коллекции отлаженных заготовок.
- •14. Компоненты: объекты, субъекты, аспекты.
- •15. Подходы к декомпозиции программ и накоплению компонент программ
- •16. Контекст исполнения многократно используемых компонент.
- •17. Проблема версифицирования программы в процессе разработки
- •18. Перенос компонент в разные системы //возможно предыдущее подойдет
- •19. Факторизация программ и программных компонент
- •20. Жизненный цикл программ (жцп). Фазы, этапы и стадии разработки программ
- •Сопровождение
- •Классические схемы жцп. Последовательная модель жцп
- •Каскадная модель жцп. Условия завершения фаз жцп
- •Табличная модель Хантера совмещения фаз жцп.
- •Uml. Диаграммы объектов и диаграммы размещения
- •Термины и понятия
- •Общие свойства
- •Содержание
- •Uml. Временные диаграммы
- •Технологичные последовательности и техника самодокументирования.
- •Основные идеи экстремального программирования
- •Многократность и рефакторинг при разработке программ. Многократность
- •Рефакторинг
- •«Парный» эффект и обе5спечение устойчивости разработки.
- •Коллективное владение
- •2. Ссылки, указатели и переменные – отличия при использовании
- •4. Зачем нужны описатели public и private?
- •5. Перегрузка операций. Пример.
- •6. Роль ссылок в борьбе за эффективность. Пример.
- •7. Инициализация объектов. Варианты конструкторов. Пример
- •8. Указатели и вектора. Сравнение стиля доступа к компонентам
- •9. Что дает использование inline?
- •10. Производные классы. Наследование.
- •11. Деструкторы. Зачем они нужны?
- •12. Друзья
- •13. Левосторонние значения (lvalue)
- •14. Описатель const. Его влияние на присваивание значений. Пример
- •15. Объединение типов данных. Пример полезного применения
- •16. Управление видимостью членов класса и доступам к элементам объекта.
- •17. Ссылка на себя //this
- •18. Освобождение памяти от лишних объектов
- •19. Порядок выполнения конструкторов и деструкторов
16. Контекст исполнения многократно используемых компонент.
17. Проблема версифицирования программы в процессе разработки
Компонент создается как последовательность предварительных, уточняемых определений, сходящихся к удачному определению, отвечающему ряду заранее заданных критериев. Все эти определения частично представляют решения одной и той же задачи. В число критериев входит соответствие постановке задачи, демонстрируемость решения на тестах, а также возможность встраивания компонента в некую ИС или его применения в рамках ИС. Компоненты могут быть интегрированы в ИС при ее создании или применяться через специальный интерфейс и средства взаимодействия процессов.
Набор определений компонентова расширяется по мере необходимости в более хорошем (точном, детальном, удобном, качественном, компактном, наглядном и т.п.) функционировании разных систем, включащих этот компонент. Выбор предпринимаемых улучшений зависит от разнообразия ИС, организуемых на основе иерархии многократно используемых компонентов, обеспечивающих откат при версифицировании. Одинаково определенные компоненты в разных ИС могут обладать различиями в поведении, выполнять разные роли в процессах информационной обработки, по-разному реагировать на взаимодействия с другими компонентами.
Множество ИС, содержащих или использующих общий компонент, можно характеризовать постановкой задачи, для решения которой этот компонент предназначен. Роль компонента в функционировании ИС, использующей его, может быть представлена в виде описания некой подзадачи или рецепта по применению компонента в рамках заданной системы.
Зависимость функционирования ИС от качества реализации содержащихся в ней встроенных компонентов демонстрируется на коллекции тестов, прогон которых удостоверяет работоспособность и обеспечивает измерение характеристик эффективности и производительности ИС.
18. Перенос компонент в разные системы //возможно предыдущее подойдет
19. Факторизация программ и программных компонент
20. Жизненный цикл программ (жцп). Фазы, этапы и стадии разработки программ
Опр: Программный продукт – программа + пользовательская документация. ПП можно эксплуатировать без участия его автора.
Этапы ЖЦ:
Анализ
Проектирование
Реализация
Сборка, тестирование, испытание
Внедрение (выпуск)
Сопровождение
Анализ
Различают 2 случая производства ПП: 1) ПП делается для конкретного заказчика. В этом случае нужно прикладную задачу преврашать в программистскую. Нужно понять как функционирует та среда, которую нужно автоматизировать (анализ бизнес-процессов). В результате появляется документация-спецификация требования, где указаны какие именно задачи д.б. решены и при каких условиях. Эту работу выполняет системный аналитик (аналитик бизнес-процессов).
2) ПП разрабатывается для рынка. Нужно проводить маркетинговые исследования и найти какого продукта на рынке нет. Это связано с большим риском. Цель – разработка спецификации требований.
Проектирование
Цель – определение общей структуры (архитектуры) ПП. Результат – спецификация ПП. Эту работу выполняет системный программист.
Реализация
Написание программного кода. Реализация включает и разработку, и тестирование, и документацию.
Сборка, тестирование, испытние
Сборка всего, что сделано разными программистами. Тестирование всего программного комплекса. Отладка – поиск и устранение причин ошибок. Испытание – уточнение технических характеристик. В результате – гарантия работоспособносит программы.
Внедрение (выпуск)
Внедрение – когда работают на одного заказчика. Включает постановку программы у заказчика, обучение заказчика, консультации, устранение ошибок и явных недостатков. Должно произойти отчуждение ПП – пользователь может работать с ПП без участия автора.
Выпуск – когда ПП разрабатывается на рынок. Начинается с этапа бета-тестирования. Соотв. версия – бета-версияю. Альфа-тестирование – тестирование людьми из той же организации, не участвовавших в разработке программ. Бета-тестирование – изготовление нескольких экземпляров ПП и отправка потенциальным заказчикам. Цель – еще раз проверить разработку ПП.
Если на рынок выпускается принципиально новый ПП, то возможно несколько бета-тестирований. После бета-тестирование – выпуск коммерческой версии.