ЛЕКЦИЯ 3 Проектирование программ сложной структуры. Проектирование программ сложной структуры.

Типовые приемы конструирования пакетов программ сложной структуры

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

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

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

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть САSЕ-системами. CASE - Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

Процедуры являются «клеем», который соединяет методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки.

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

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

Популярные парадигмы ТКПО: классический ЖЦ (каскадная модель) макетирование (прототипирование) - процесс создания модели требуемого программного продукта. эволюционная стратегия конструирования (пример – спиральная модель ЖЦ).

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенными среди которых являются следующие: SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы; DFD (Data Flow Diagrams) диаграммы потоков данных; ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм. Перечисленные модели в совокупности дают полное описание ИС независимо от того, является ли она существующей или вновь разрабатываемой. Состав диаграмм в каждом конкретном случае зависит от необходимой полноты описания системы.

СТАДИЯ АНАЛИЗА Стандарты семейства IDEF IDEF0 - стандарт функционального моделирования IDEF1 - стандарт информационного моделирования, известен еще и под названием "ER- диаграммы". IDEF3 - определяет методологию моделирования процессовв, проще говоря, построения технологических карт.

Наиболее интересные компоненты современного развития семейства IDEF: DFD "Data flow diagram", "диаграммы потоков данных" - широко распространенная методология моделирования процессов- ориентированного типа. "Моделирование в терминах системы" - специализированная система моделирования, создана усилиями специалистов BAAN.

В основе стандарта IDEF0 лежит метод SADT (методология структурного анализа и проектирования). Основная идея этой методологии - построение древовидной функциональной модели предприятия.

На рисунке - дерево узлов функциональной модели.

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

Сопоставление и взаимосвязь структурного и объектно- ориентированного подходов. Структурное проектирования работает хорошо, потому что оно позволяет нам одновременно сосредотачиваться на меньшем количестве деталей. Это логичная методика, которая поощряет организованную доводку системы и уменьшает уровень сложности (степени интеграции) на каждой из последующих стадий проекта. По очевидным причинам, нисходящее (структурное) проектирование подходит лучше всего тогда, когда применяется к проблемам, которые имеют ясно выраженный иерархический характер. К сожалению, многие из реальных проблем не иерархические. Проект, основанный на построении сверху вниз, имеет также и другие ограничения, которые станут очевидными при разработке и сопровождении больших программных систем. Функциональную точку зрения трудно развивать. Реальные системы трудно охарактеризовать функционально. Фокусирование на функциональности теряет из виду данные. Функциональная ориентация производит код, менее пригодный для многократного использования.

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

Объектно-ориентированное проектирование - конструирование программных систем как структурных коллекций, реализующих абстрактные типы данных. Объектно-ориентированное проектирование и объектно-ориентированное программирование улучшают возможности нисходящего проектирования, концентрируя больше внимание на данных системы, а не на том, что система делает. Это подход позволяет создавать системы, которые легче сопровождать, они более гибкие, более устойчивые и более приспособлены к многократному использованию, чем создаваемые при нисходящем структурном подходе. Объектно-ориентированные методы лучше потому что: Они работают на более высоком уровне абстракции. Нет "прыжков" между фазами. Они поддерживают данные, которые имеют тенденцию, к большей стабильности, чем функции. Они поощряют и поддерживают классические достоинства хорошего программирования и проектирования. Они сопровождаются инструментами, обеспечивающими поддержку повторного использование кода. Объектно-ориентированный подход имеет два аспекта: объектно-ориентированная разработка программного обеспечения; объектно-ориентированная реализация программного обеспечения.

Объектно-ориентированная разработка программ Объектно-ориентированная разработка ПО связана с применением объектно- ориентированных моделей при разработке программных систем и их компонентов. Говоря об объектно-ориентированной разработке, имеют в виду: объектно-ориентированные технологии разработки программных систем; инструментальные средства, поддерживающие эти технологии.

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

Объектно-ориентированная разработка программ Различные объектно-ориентированные методологии разработки программного обеспечения: RUP (Rational Unified Process) OMT (Object Modeling Technique) SA/SD (Structured Analysis/Structured Design); JSD (Jackson Structured Development); OSA (Object-Oriented System Analysis)

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

Цель Рационального Унифицированного Процесса – обеспечить изготовление программного продукта высочайшего качества, соответствующего потребностям пользователя, в заданные сроки и в пределах заранее составленной сметы.

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

В основе RUP лежат следующие принципы: Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков. Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)). Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки. Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта. Постоянное обеспечение качества на всех этапах разработки проекта (продукта). Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам.

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

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

Суть работы в рамках Рационального Унифицированного Процесса - это создание и сопровождение моделей. Модели, выраженные на языке UML (универсальный язык моделирования), создают представление разрабатываемого программного комплекса.

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

Рациональный Унифицированный Процесс состоит из следующих четырех фаз: Начало (inception) - определение бизнес- целей проекта. Исследование (Уточнение) (elaboration) - разработка плана и архитектуры проекта. Построение (контруирование) (construction) - постепенное создание системы. Внедрение (transition) -поставка системы конечным пользователям.

УНИФИЦИРОВАННЫЙ ЯЗЫК МОДЕЛИРОВАНИЯ Унифицированный язык моделирования (UML) является стандартным инструментом для создания документированных каркасов ("чертежей") программного обеспечения. С помощью UML можно визуализировать, специфицировать, конструировать и документировать процесс разработки программных систем.

Диаграмма классов, показывающая Агрегацию между двумя классами Диаграмма прецедентов для упрощенной модели работы ресторана