
- •В чем состоит суть анализа как этапа разработки по: цель, какие действия выполняются, что является результатом? Может ли этот этап быть пропущен при разработке по и почему?
- •На какие виды и классы можно разделить программные продукты? Приведите примеры программных продуктов для каждого вида. К какому типу Вы бы отнесли систему своего лабораторного практикума?
- •Каково место визуального моделирования в анализе и проектировании по? Является ли диаграмма первичным и самодостаточным артефактом и почему?
- •Почему требования к системе необходимо документировать? Какие существуют способы документирования требований?
- •Что такое «жизненный цикл по»? Какие этапы и процессы входят в жизненный цикл по?
- •В чем заключается идея шаблона Controller? Какие классы могут стать классами-контроллерами?
- •В чем заключается суть водопадной модели жизненного цикла по? Для каких проектов эта модель наиболее применима?
- •Что такое «архитектура программного обеспечения»? Какие основные элементы в нее входят? Каким главным свойством, на Ваш взгляд, должна обладать высококачественная архитектура?
Что такое «жизненный цикл по»? Какие этапы и процессы входят в жизненный цикл по?
Жизненный цикл ПО — период времени, который начинается с момента принятия решения о необходимости создания программного продукта и заканчивается в момент его полного изъятия из эксплуатации. Этот цикл определяет процесс построения и развития ПО.
Другое определение:
Жизненный цикл ПО - упорядоченный набор взаимосвязанных видов деятельности осуществляемый и управляемый в рамках каждого проекта по разработке ПО. (Очень сильно перекликается с процессом), в то время, как
Процесс - это механизм реализации жизненного цикла.
Жизненный цикл может быть представлен с различной степенью детализации. На укрупнённом уровне жизненный цикл включает в себя 3 этапа:
анализ (что сделать)
проектирование (как сделать)
реализация (воплощение)
Существуют различные модели жизненного цикла. Наиболее известная водопадная модель, которая была предложена Уинстоном Ройсом в 1970г.
Другие модели: эволюционная, итеративная, спиральная.
В чем заключается идея шаблона Controller? Какие классы могут стать классами-контроллерами?
Одной из базовых задач при проектировании информационных систем является определение класса, отвечающего за обработку системных событий. При необходимости посылки внешнего события прямо объекту приложения, которое обрабатывает это событие, как минимум один из объектов должен содержать ссылку на другой объект, что может послужить причиной очень негибкого дизайна, если обработчик событий зависит от типа источника событий или источник событий зависит от типа обработчика событий.
В простейшем случае зависимость между внешним источником событий и внутренним обработчиком событий заключается исключительно в передаче событий. Довольно просто обеспечить необходимую степень независимости между источником событий и обработчиком событий, используя интерфейсы. Интерфейсов может оказаться недостаточно для обеспечения поведенческой независимости между источником и обработчиком событий, когда отношения между этими источником и обработчиком достаточно сложны.
Можно избежать зависимости между внешним источником событий и внутренним обработчиком событий путем введения между ними дополнительного объекта, который будет работать в качестве посредника при передаче событий. Этот объект должен быть способен справляться с любыми другими сложными аспектами взаимоотношений между объектами.
Согласно шаблону Controller, производится делегирование обязанностей по обработке системных сообщений классу, если он:
· представляет всю организацию или всю систему в целом (внешний контроллер);
· представляет активный объект из реального мира, который может участвовать в решении задачи (контроллер роли);
· представляет искусственный обработчик всех системных событий прецедента и называется ПрецедентHandler (контроллер прецедента) .
Для всех системных событий в рамках одного прецедента используется один и тот же контролер.
Controller – это класс, не относящийся к интерфейсу пользователя и отвечающий за обработку системных событий. Использование объекта-контроллера обеспечивает независимость между внешними источниками событий и внутренними обработчиками событий, их типом и поведением. Выбор определяется за- цеплением и связыванием.
Раздутый контроллер выполняет слишком много обязанностей. Признаки:
· в системе имеется единственный класс контроллера, получающий все системные сообщения, которых поступает слишком много (внешний или ролевой контроллер);
· контроллер имеет много полей (информации) и методов (ассоциаций), которые необходимо распределить между другими классами