Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

ВОПРОСЫ ПО ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ

1. Стадии проектирования программных систем. Итерационное проектирование.

1) Формирование требований к системе.

2) Проектирование

3) Реализация

4) Тестирование

5) Ввод в эксплуатацию

6) Сопровождение

Основные принципы

• Этап проектирования не прекращается никогда

• Уточнение требований продолжается в течение всего времени проектирования

• Программная система наследует проблемы реальной системы

Итерационная модель разработки - процесс проектирования и реализации кода продукта, при котором не вносятся серьёзные изменения в архитектуру, а лишь направляются эволюционные процессы развития.

2. Проблема сложности при проектировании программного обеспечения. Различные виды сложности при проектировании программного обеспечения.

1. Сложность проблемы.

• Сложность поставленной задачи в сочетании с дополнительными требованиями стоимости, надежности, удобства, производительности и т.п.

• Сложность получения достоверных данных о предметной области от заказчика

• Изменение требований в процессе разработки программной системы

• Необходимость длительного обслуживания программной системы

1. Сложность управления процессом разработки.

• Большой объем программ и сложная логика функционирования программной системы

• Большой коллектив программистов

• Необходимость согласования технических решений

• Координация работ различных групп программистов

• Поддержание единства и целостности разработки

• Создание документации на программную систему

• Обеспечение временных и финансовых ограничений на разработку

1. Сложность обеспечения гибкости сопровождения конечного продукта.

• Использование определенных технологий, стандартов и соглашений в программировании

• Использование специальных решений для обеспечения сопровождения

• Разработка специальных технологических средств сопровождения программной системы

• Разработка системы тестирования программ

1. Сложность описания поведения отдельных подсистем.

• Сложность алгоритмов описания реальной предметной области

• Сложность информационных связей в предметной области

• Сложность логических взаимосвязей предметной области

• Наличие ограничений на параметры функционирования программной системы

3. Основные характерные особенности больших программных систем.

ПРЕДМЕТНАЯ ОБЛАСТЬ – промышленные программные продукты

• Различные области применения

• Сложные в логической организации

• Большие по объему кода

• Имеют много пользователей

• Долгое время жизни (использования)

• Требуют модернизации и сопровождения

• Должны сопровождаться документацией

• Разрабатываются коллективом программистов

• Требуют больших финансовых ресурсов

4. Определение требований к проектируемому программному обеспечению. Управление требованиями.

1. Постановка задачи.

• Нужно понять, что нужно сделать

• Требования формулируются совместно заказчиком и проектировщиком с максимально возможной строгостью

• Нельзя ориентироваться только на требования одного, но влиятельного лица. Система обрекается на недолговечность. Должен быть найден и вовлечен в дело действительный пользователь, а не его заменитель

• Разные пользователи дают противоречивые требования

• Представитель заказчика должен иметь полномочия принимать решения

2. Документирование.

• Требования формулируются совместно заказчиком и проектировщиком с максимально возможной строгостью

• Язык формулировок требований должен быть понятен пользователю и проектировщику

• Нужно документировать требования

• Если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют

3. Управление требованиями.

• Предусмотреть изменения в проекте !!!

• Самое первое требование к проектированию больших систем – предусмотреть возможность будущих изменений

• Требования разработчики и заказчики понимают по-разному

• Требованиями надо управлять !!!

5. Документирование процесса проектирования. Назначение документирования. Требование к документированию.

• Если отсутствует документация доступная для всех – проект обречен на неудачу

• Дональд Дуглас – «когда вес документов достигает веса самолета, самолет начнет летать»

• Документация создается на всех уровнях проектирования

• Использовать методы документирования (HIPO, SADT, IA, UML)

• Самая трудная задача – организовать ведение документации

Требования:

• Требования формулируются совместно заказчиком и проектировщиком с максимально возможной строгостью

• Язык формулировок требований должен быть понятен пользователю и проектировщику

• Нужно документировать требования

• Если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют

6. Использование декомпозиции при проектировании больших программных систем. Декомпозиция при алгоритмическом подходе. Декомпозиция при объектно-ориентированном подходе.

Одним из основных способов анализа сложных систем является декомпозиция. При проектировании сложной программной системы необходимо разделять ее на все меньшие и меньшие подсистемы, каждую из которых можно совершенствовать независимо.

Декомпозиция разрабатываемой программной системы на ряд тесно связанных раздельно компилируемых модулей с целью снижения затрат на программирование за счет независимой разработки и тестирования существенно уменьшает затраты.

Виды декомпозиции:

• алгоритмическая (разбиение на подпрограммы)

• объектно-ориентированная (разбиение на совокупность взаимодействующих объектов). Именно объектно-ориентированная декомпозиция отличает объектно-ориентированное проектирование от структурного; в первом случае логическая структура системы отражается абстракциями в виде классов и объектов, во втором - алгоритмами.

Опыт показывает, что полезней вначале применить объектный подход, а затем после упрощения системы - алгоритмический.

В соответствии с алгоритмической декомпозицией предметной области мы при анализе задачи пытаемся понять, какие алгоритмы необходимо разработать для ее решения, каковы спецификации этих алгоритмов (вход, выход), и как эти алгоритмы связаны друг с другом. В языках программирования данный подход в полной мере поддерживается средствами модульного программирования (библиотеки, модули, подпрограммы).

В рамках объектной декомпозиции мы пытаемся выделить основные содержательные элементы задачи, разбить их на типы (классы). Далее для каждого класса абстракций мы определяем его свойства (данные) и поведение (операции), а также, как эти классы абстракций взаимодействуют друг с другом.

Объектная декомпозиция имеет несколько достаточно важных преимуществ

перед алгоритмической декомпозицией:

• Объектная декомпозиция уменьшает размер программных систем за счёт повторного использования общих механизмов, что приводит к существенной экономии выразительных средств.

• Объектно-ориентированные системы более гибкие и проще эволюционируют со временем, потому что их схемы базируются на устойчивых промежуточных формах.

• Объектная декомпозиция существенно снижает риск при создании сложной программной системы, так как она развивается из меньших систем, в которых мы уже уверены.

• Объектная декомпозиция помогает нам разобраться в сложной программной системе, предлагая нам разумные решения относительно выбора подпространства большого пространства состояний.

7. Требования к программным модулям при проведении декомпозиции.

ХАРАКТЕРИСТИКИ МОДУЛЯ

• Функциональная прочность

• Информационная прочность

• Сцепление по данным

• Сцепление по общей области

• Сцепление по управлению

• Размер модуля

Хороший программный модуль

• Сложность взаимодействия модуля с другими модулями должна быть меньше сложности его внутренней структуры

• Хороший модуль снаружи проще, чем внутри

• Хороший модуль проще использовать, чем построить

Правильное разделение программы на модули является почти такой же сложной задачей, как выбор правильного набора абстракций, поскольку в начале работы над проектом решения могут быть неясными, декомпозиция на модули может вызвать затруднения. Для небольших задач допустимо описание всех классов и объектов в одном модуле. Однако для большинства программ (кроме самых тривиальных) лучшим решением будет сгруппировать в отдельный модуль логически связанные классы и объекты, оставив открытыми те элементы, которые совершенно необходимо видеть другим модулям. Такой способ разбиения на модули хорош, но его можно довести до абсурда. Деление программы на модули бессистемным образом иногда гораздо хуже, чем отсутствие модульности вообще.

В процессе разделения системы на модули могут быть полезными два правила. Во-первых, поскольку модули служат в качестве элементарных и неделимых блоков программы, которые могут использоваться в системе повторно, распределение классов и объектов по модулям должно учитывать это. Во-вторых, многие компиляторы создают отдельный сегмент кода для каждого модуля. Поэтому могут появиться ограничения на размер модуля. Динамика вызовов подпрограмм и расположение описаний внутри модулей может сильно повлиять на локальность ссылок и на управление страницами виртуальной памяти. При плохом разбиении процедур по модулям учащаются взаимные вызовы между сегментами, что приводит к потере эффективности кэш-памяти и частой смене страниц. На выбор разбиения на модули могут влиять и некоторые внешние обстоятельства. При коллективной разработке программ распределение работы осуществляется, как правило, по модульному принципу и правильное разделение проекта минимизирует связи между участниками. При этом более опытные программисты обычно отвечают за интерфейс модулей, а менее опытные - за реализацию. На более крупном уровне такие же соотношения справедливы для отношений между субподрядчиками.

8. Роль абстракции в процессе проектирования. Барьер абстракции. Абстракции сущности и абстракции поведения.

Абстрагирование — это метод, с помощью которого разработчики решать сложные проблемы, последовательно разбивая их на более простые.

• Абстракция выделяет существенные характеристики некоторого объекта, отличающие его от всех других видов объектов и, таким образом, четко определяет его концептуальные границы с точки зрения наблюдателя

• Абстракция разделяет смысл и реализацию объекта

• Выделение существенных особенностей объекта и отделение их от несущественных – барьер абстракции

• Абстракция фокусируется на существенных с точки зрения наблюдателя характеристиках объекта

∙ Абстракция сущности

Объект представляет собой полезную модель некой сущности в предметной области

∙ Абстракция поведения

Объект состоит из обобщенного множества операций

∙ Абстракция виртуальной машины

Объект группирует операции, которые либо вместе используются более высоким уровнем управления, либо сами используют некоторый набор операций более низкого уровня

∙ Произвольная абстракция

Объект включает в себя набор операций, не имеющих друг с другом ничего общего

9. Уровень реализации. Критерии выбора языка программирования и стандартов программирования.

• Выбор языка программирования

• Выбор стандартов программирования

• Выбор инструментария программирования

• Проектирование диалогового взаимодействия

• Уровни квалификации. Главный программист

• Компоновка программ

• Контроль версий системы

• Какова природа задачи, которую Вы программируете?

• Предстоит ли реализовать сложный алгоритм, или же нужно написать простую процедуру из нескольких строк?

• Имеет ли задача много независимых частей?

• Можно ли поделить программу на несколько раздельно компилируемых функций, или это будет один модуль?

• Как скоро программа должна быть готова?

• Нужно ли написать программу быстро, не заботясь об ее эффективности, или имеется достаточно времени для разработки наиболее эффективной программы?

• Какова область применения программы?

• Будет ли программа использоваться только ее автором, или она будет широко распространяться?

• Будет ли программа переноситься на другие системы?

• Как долго будет эксплуатироваться программа?

• Будет ли она использована всего несколько раз, или планируется ее применение в течение нескольких лет?

10. Проектирование программных систем. Главный программист, его задачи и функции.

• Проектирование в большей степени связано с искусством

• Программа наследует все проблемы реальной системы

• При проектировании делается обоснование как ПО так и ТС

• Проектирование - итерационный процесс

• Проектированием может заниматься не каждый

Принипы:

• Этап проектирования не прекращается никогда

• Уточнение требований продолжается в течение всего времени проектирования

• Программная система наследует проблемы реальной системы

МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ

• Разбиение на уровни абстракций

• На каждом уровне абстракции – 7 или менее элементов

• Ограниченный контекст, только важные элементы

• Должны определяться как данные, так и операции над ними

УРОВНИ ПРОЕКТИРОВАНИЯ

• Верхний уровень – разделение на подсистемы, модули. Определение взаимодействия. Реализация замкнутости подсистем.

• Средний уровень – реализация технических решений. Выделение макрослоев. Проектирование модулей. Определение потоков данных.

• Нижний уровень – кодирование программ. Технологии кодирования. Структурное программирование.

Главный Программист

Задачи:

2.1. участие в определении возможности формализации элементов действующей системы и целесообразности создания соответствующих программных комплексов;

Характеристики

Список файлов лекций