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

Проектирование в основном рассматривается как двух-шаговый процесс [7]:

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

– Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент.

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

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

В качестве основных принципов проектирования выделим следующие:

Абстракция

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

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

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

Связанность и соединение

Связанность – определяет силу взаимосвязи между модулями. Соединение – определяет взаимосвязь элементов внутри модуля, внутренние связи.

Декомпозиция и разбиение на модули

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

Инкапсуляция

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

Разделение интерфейса и реализации

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

Достаточность, полнота и простота

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

Структура и архитектура программного обеспечения

Архитектура программного обеспечения (англ. software architecture) – это структура программы или вычислительной системы, которая включает программные компоненты, видимые снаружи свойства этих компонентов, а также отношения между ними [википедия].

Архитектура ПО является реализацией нефункциональных требований к системе, в то время как проектирование ПО является реализацией функциональных требований.

Архитектура ПО обычно содержит несколько видов, которые аналогичны различным типам чертежей в строительстве зданий. В онтологии, установленной ANSI / IEEE 1471—2000, виды являются экземплярами точки зрения, где точка зрения существует для описания архитектуры с точки зрения заданного множества заинтересованных лиц.

Примеры видов:

- Функциональный/логический вид

- Вид код/модуль

- Вид разработки (development)/структурный

- Вид параллельности выполнения/процесс/поток

- Физический вид/вид развертывания

- Вид с точки зрения действий пользователя

- Вид с точки зрения данных

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

Фреймворк (англ. framework — каркас, структура) – структура программной системы или программное обеспечение, облегчающее разработку и объединение разных компонентов большого программного проекта. В отличие от библиотек, которые объединяют набор подпрограмм близкой функциональности, фреймворк содержит в себе большое количество разных по назначению библиотек. Некоторые авторы используют слово «каркас» в качестве основного. С их точки зрения можно говорить о каркасном подходе как о подходе к построению программ, где любая конфигурация программы строится из двух частей: первая, постоянная часть – каркас, не меняющийся от конфигурации к конфигурации и несущая в себе гнезда, в которых размещается вторая, переменная часть – сменные модули (или точки расширения) [википедия].

Фреймворк реализуется как множество конкретных и абстрактных классов, а также определений способов их взаимоотношения. Конкретные классы обычно реализуют взаимные отношения между классами. Абстрактные классы представляют собой точки расширения, в которых каркасы могут быть использованы или адаптированы. Точка расширения — это та часть фреймворка, для которого не приведена реализация. Соответственно каркас концептуальной модели состоит из концептуальных классов, а каркас программной системы из классов языка программирования общего назначения. Процесс создания фреймворка заключается в выборе подмножества задач проблемы и их реализаций. В ходе реализаций общие средства решения задач заключаются в конкретных классах, а изменяемые средства выносятся в точки расширения.

Примеры такой систематизации в форме фреймворков:

TOGAF [TOGAF81, 2003] – The Open Group Architecture Framework (на момент первичного написания данной главы доступен в версии 8.1, впервые опубликованной в декабре 2003 года; в 2009 году вышла версия TOGAF 9)

Модель Захмана – Zachman Framework [27].

Руководство по архитектуре электронного правительства E-Gov Enterprise Architecture Guidance [E-Gov, 2002]

Архитектурные структуры и точки зрения

Принцип сужения предметной области с использованием точки зрения [пособие по ТССА] широко используется в программной инженерии. Система может рассматриваться с разных точек зрения – поведенческой, структурной, логической, физической и т.п. Следовательно, можно получить множество различных архитектурных представлений. Архитектурное представление может быть определено, как частные аспекты программной архитектуры, рассматривающие специфические свойства программной системы. Дизайн системы – комплекс архитектурных представлений, достаточный для реализации системы и удовлетворения требований, предъявляемых к системе.

Архитектурная структура – применение архитектурной точки зрения и представления к конкретной системе и описания тех деталей, которые необходимы для реализации системы, но отсутствуют в используемом представлении. Таким образом, представление, концентрируясь на заданном подмножестве свойств является составной частью и/или результатом точки зрения, а архитектурная структура – дальнейшей детализацией в отношении проектируемой системы [7]. В качестве примера архитектурных точек зрения можно рассматривать модель Захмана [27].

Архитектурные стили

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

Шаблоны проектирования

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

Чаще всего говорят о следующих группах шаблонов проектирования:

– Шаблоны создания (Creational patterns) - builder, factory, prototype, singleton

– Структурные шаблоны (Structural patterns) - adapter, bridge, composite, decorator, facade, flyweight, proxy

– Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor

⇐ Предыдущая 3 4 5 6 789 10 11 12 Следующая ⇒