Семейства программ и фреймворков

⇐ ПредыдущаяСтр 9 из 16Следующая ⇒

Один из возможных подходов к повторному использованию архитектурных решений и компонент заключается в формировании линий продуктов на основе общего дизайна. В объектно-ориентированном программировании аналогичную смысловую нагрузку несут «фреймворки», обеспечивающие решение одних и тех же задач – например, внутренней организации компонентов пользовательского интерфейса или общей логики работы распределенных систем [7].

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

Атрибуты качества

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

– применимые во время выполнения системы, например, среднее время отклика системы;

– используемые в режиме разработки, например, среднее количество методов в классе, среднее количество свойств объекта и т.д.;

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

Существуют атрибуты, которые сложно измерить, например, такой как безопасность.

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

Анализ качества и техники оценки

Известно немало различных инструментов и методов, предназначенных для формирования качественного дизайна ПС:

– обзор дизайна, например, неформальный обзор архитектуры членами проектной команды;

– статический анализ, например, трассировка с требованиями;

– симуляция и прототипирование – динамические техники проверки дизайна в целом или отдельных его атрибутов качества; например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым [7].

Измерения

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

– функционально-ориентированные;

– объектно-ориентированные [7].

Нотации проектирования

Нотация – система условных обозначений, принятая в какой-либо области знаний или деятельности. Нотация включает множество символов используемых для представления понятий и их взаимоотношений, составляющее алфавит нотации, а также правила их применения [википедия].

Следовательно, нотация – соглашение о представлении некоторой абстракции в визуальной (графической) форме. Нотация может задаваться:

– стандартом;

– общепринятой практикой;

– внутренним методом проектной команды.

Определенные нотации используются на стадии концептуального проектирования, ряд нотаций ориентирован на создание детального дизайна, многие могут использоваться на обеих стадиях. Кроме того, нотации чаще всего используют в контексте применяемой методологии или подхода [7].

Структурные описания

Следующие нотации, в основном, являются графическими, описывая и представляя структурные аспекты программного дизайна:

– языки описания архитектуры, такие как текстовые языки, обычно используемые для описания программной архитектуры в терминах компонентов;

– диаграммы классов и объектов, применяемые для представления набора классов и связей между ними (например, наследования);

– диаграммы компонентов используемые для представления набора компонентов и связей между ними с учётом того, что компонент в отличие от класса является реализуемым элементом;

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

– диаграммы развёртывания, применяемые для представления физических узлов, связей между ними и моделирования других физических аспектов системы;

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

– языки описания (определения) интерфейса, предназначенные для определения интерфейсов программных компонентов (имён и типов экспортируемых или публикуемых операций);

– структурные диаграммы Джексона, описывающие структуры данных в терминах последовательности, выбора и итераций (повторений);

– структурные схемы, применяемые для описания структуры вызовов в программах [7].

Поведенческие (динамические) описания

Рассмотрим нотации и языки, используемые для описания динамического поведения программных систем и их компонентов:

– диаграммы деятельности или операций, применяемые для описания потоков работ и управления;

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

– диаграммы потоков данных, описывающие потоки данных внутри набора процессов;

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

– схемы алгоритмов и структурированные схемы алгоритмов, служащие для представления потоков управления (контроля) и связанных операций;

– диаграммы последовательности, демонстрирующие взаимодействие внутри группы объектов по времени;

– диаграммы перехода и карты состояний, применяемые для описания потоков управления переходами между состояниями;

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

– псевдокод и программные языки проектирования, описывающие поведение процедур и методов, в основном на стадии детального проектирования [7].

Подходы и методы проектирования программного обеспечения

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

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

Общие подходы

Наиболее часто используются следующие общепринятые подходы:

– метод пошаговой декомпозиции;

– нисходящий и восходящий подход к проектированию;

– абстракция и инкапсуляция;

– итеративный и инкрементальный подход.

Метод пошаговой декомпозиции

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

– определяется общая структура программы в виде одного из трех вариантов:

– последовательности подзадач (например, ввод данных, преобразование данных, вывод данных),

– альтернативы подзадач (например, добавление записей к файлу или их поиск),

– повторения подзадачи (например, циклически повторяемая обработка данных);

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

– процесс продолжается, пока на очередном уровне не получается подзадача, которая достаточно просто реализуется средствами используемого языка (1 - 2 управляющих оператора языка).

⇐ Предыдущая 4 5 6 7 8910 11 12 13 Следующая ⇒