Структурный подход к разработке программных систем.

п/с ввода/вывода делится на: п/с работы с БД, п/с обработки данных, п/с визуализации.

п/с моделирования делится на: файловую п/с и т.д.

Принципы при структурном проектировании:

· принцип «разделяй и властвуй» – любая сложная задача разделяется на более простые;

· принцип иерархического упорядочивания – любая система может быть представлена в виде дерева, листьями которой являются подсистемы.

Техники, использующиеся при структурном проектировании:

· принцип абстрагирования – заключается в выделении существенных аспектов системы и отвлечения от несущественных;

· принцип формализации – заключается в необходимости строгого методического подхода к решению проблемы;

· принцип непротиворечивости – заключается в обоснованности и согласованности элементов;

· принцип структурирования данных – заключается в том, что данные должны быть структурированы и иерархически организованы.

Объектный подход к разработке программных систем.

Базовыми принципами объектно-ориентированного проектирования являются:

· абстрагирование;

· инкапсуляция;

· полиморфизм;

· наследование (единственное, множественное);

· Типизация;

· Принцип иерархичности.

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

· Абстракция сущностей (некий объект предметной области);

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

· Абстракция виртуальной машины (в этом случае объект группирует внутри себя операции, доступные всем объектам предметной области);

· Произвольный вид абстракции (объект включает в себя те операции, которые не имеют друг с другом ничего общего).

Основные этапы ЖЦ: Требования к ПО.

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

Выделяют 5 основных этапов ЖЦ, первым является требования к ПО.

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

Уровни требований по Вигерсу:

Бизнес требования: определяют высокоуровневые цели организации - заказчика.

Пользовательские требования: описывают цели и задачи пользователя системы, которые должны достигаться при помощи данной системы.

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

Бизнес правила: включают в себя или связаны с корпоративными регламентами, политиками, стандартами, законными актами, внутрикорпоративными инициативами, учетными практиками, и т.д. (играют роль ограничений). Определяют распределение ответственности в системе и играют большую роль в организации процесса разработки.

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

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

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

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

Модель процессов определения времени – это схема процессов жизненного цикла, которые вычисляются от начала проекта и до тех пор, пока не будут определены все требования.

Качество и улучшения – процесс формулировки характеристик и атрибутов качества, которыми должно обладать ПО, а также методы и достижения на всех этапах жизни цикла и оценивание полученных результатов.

Извлечение требований – процесс извлечения информации из различных источников (договора, материалы аналитиков, обзор систем аналогов, декомпозиция задач и т.д.), проведение технических мероприятий (собеседований, собраний, и т.д. для формирования требований как к ПО, так и к процессам). Все требования согласованы с заказчиками.

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

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

Валидация требований часто осуществляется с помощью проектирования (быстрой разработки части система с целью оценки функциональности и стоимости).

Верификация требований – процесс правильности спецификаций на их соответствие, непротиворечивость, полноту, соответствие стандартам.

Управление требованиями – руководство всеми процессами оформления требований, а также проведения мониторинга с целью восстановления источника требований.