Лекция 1
Предыстория возникновения объектного подхода. Соотношение между объектно-ориентированным анализом, проектированием и программированием
План лекции.
1. Сложность программного обеспечения
2. Декомпозиция
3. Предыстория возникновения объектного подхода
1. Сложность программного обеспечения
Технологии ООП возникли как ответ на нарастающую сложность ПО.
Не все программные системы сложны. Существует множество программ, которые задумываются и разрабатываются одним человеком. Но такие программы имеют ограниченную область применения и короткое время жизни. Обычно их лучше заменить новыми, чем переделывать.
Нас интересует разработка промышленных программных продуктов. (Поддержание целостности огромной БД, диспетчеризация транспорта, складской учет, учет кадров, бухгалтерский учет, АСУТП, АСУП). Эти системы разрабатываются всерьез и надолго, многие пользователи зависят от их нормального функционирования.
Промышленная программа имеет такой уровень сложности, что один разработчик не в состоянии охватить все детали системы. Эта сложность присуща всем большим программным системам. С ней можно справиться, но избавиться от нее нельзя.
Сложность ПО вызывается следующими причинами:
1. Сложность реального мира. Предприятие – огромный механизм. Достаточно трудно понять, как он работает. Сложная задача порождает сложное ПО.
Сложность часто возникает из-за нестыковок между пользователями системы и разработчиками. Пользователи-непрофессионалы зачастую смутно представляют, что им нужно, и не могут объяснить это разработчикам.
Часто требования к программной системе меняются в ходе разработки.
2. Трудность управления процессом разработки. Сегодня размер промышленных программных систем – десятки и сотни тысяч строк. Ни один человек не сможет полностью понять такую систему. Если мы разобьем ее на части, мы получим сотни отдельных модулей. Надо будет привлечь команду разработчиков. Но чем больше разработчиков, тем сложнее связи между ними.
Термины:
Сопровождение ПО – устранение ошибок в ходе эксплуатации.
Эволюция ПО – внесение изменений в ответ на изменившиеся требования.
Сохранение ПО – поддержание работоспособности разрушающейся системы.
Последствия сложности. Чем сложнее система, тем легче ее развалить. Строители вряд ли согласятся расширять фундамент уже построенного здания. Но заказчики ПО часто ставят подобные требования перед разработчиками. Поэтому проекты выходят за рамки установленных сроков и бюджетов.
Признаки сложной системы.
1. Сложные системы являются иерархическими и состоят из взаимозависимых подсистем, которые также могут быть разделены на подсистемы, вплоть до самого низкого уровня.
Благодаря этому сложные системы можно понять, описать, спроектировать – мы понижаем уровень сложности.
2. Выбор, какие компоненты системы считаются простейшими, зависит от разработчика.
3. Сложные системы обычно состоят из немногих типов подсистем, но по-разному скомбинированных и организованных.
Разные сложные системы содержат одинаковые структурные части. Из этих блоков можно конструировать более сложные системы.
4. Любая работающая сложная система является развитием работавшей более простой системы.
Сложная система, спроектированная «с нуля», никогда не заработает. Следует начинать с работающей простой системы.
2. Декомпозиция
Чтобы управлять сложными системами, их необходимо разделять на составляющие – меньшие и меньшие подсистемы, которые можно было бы разрабатывать независимо.
Декомпозиция бывает алгоритмическая и объектно-ориентированная.
Алгоритмическая декомпозиция – разделение системы на алгоритмы, где каждый модуль выполняет один из этапов.
Объектно-ориентированная декомпозиция. Критерий – принадлежность элементов к различным абстракциям предметной области.
Каждый объект что-то делает, и можно, послав ему сообщение, попросить его выполнить что-то.
Какая декомпозиция правильнее – по алгоритмам или по объектам? Опыт показывает, что лучше всего начать с объектной декомпозиции
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.