2-software_engineering_design (Основы программной инженерии (по SWEBOOK)), страница 2

В качестве такогоконтекста выступает жизненный цикл программной инженерии, а проектирование напрямую связанос результатами анализа требований, конструированием программных систем и их тестированием.Стандарты жизненного цикла, например, IEEE и ISO/IEC (ГОСТ Р) 12207 уделяют специальноевнимание вопросам проектирования и детализируют их, описывая контекст проектирования – оттребований до тестов.1.3 Процесс проектирования (Software Design Process)Проектирование в основном рассматривается как двух-шаговый процесс:1.3.1 Архитектурное проектирование – декомпозиция структуры (статической) и организации(динамической) компонент;1.3.2 Детализация архитектуры – описывает специфическое поведение и характеристики отдельныхкомпонент.Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений,принятых по способам реализации требований в программном коде.1.4 Техники применения (Enabling Techniques)Принципы проектирования, также называемые техниками применения, являются ключевыми идеямии концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах кпроектированию программного обеспечения.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru4Основы программной инженерии (по SWEBOK)Программная инженерия.

Проектирование программного обеспечения.1.4.1 Абстракция (Abstraction)В контексте проектирования программных систем существует два механизма абстракции –параметризация и специфицирование (может интерпретироваться как детализация). При этом,абстракция через специфицирование бывает трех видов: процедурная абстракция (динамическая, тоесть в отношении поведения), абстракция данных (статическая, то есть в отношении информации) иабстракция контроля (то есть управления системой и обрабатываемой ею информацией).Обычно под абстракций, как результатом процесса абстракции, понимают модель, упрощающуюпоставленную проблему до рамок, значимых для заданного контекста.1.4.2 Связанность и соединение (Coupling and Cohesion)Связанность (Coupling) – определяет силу связи (часто, взаимного влияния) между модулями.Соединение (Cohesion) – определяет как тот или иной элемент обеспечивает связь внутри модуля,внутреннюю связь.Значение оригинальных терминов очень близко и, в зависимости от контекста, “связанность” и“соединение” могут рассматриваться как степень самодостаточности или ее отсутствия (coupling) ифункциональная зависимость (cohesion) , соответственно.Хочется особенно подчеркнуть значимость этих понятий, так как с развитием сервисноориентированной архитектуры (Service-Oriented Architecture, SOA), слабосвязанной по своей природе(то есть со слабым “сопряжением”, слабой “силой связи” между модулями), по сравнению, например,с OMG CORBA (Common Object Request Broker Architecture), все чаще приходится сравниватьразличные подходы и решения, определяемые способом и степенью связанности различныхмодулей, компонент и самих программных систем.1.4.3 Декомпозиция и разбиение на модули (Decomposition and Modularization)Декомпозиция и разбиение на модули сложных программных систем производится с цельюполучения более мелких и относительно независимых программных компонентов, каждый изкоторых несет различную функциональность (логически связанные группы функциональности).1.4.4 Инкапсуляция/сокрытие информации (Encapsulation/information hiding)Данная концепция предполагает группировку и упаковку (с точки зрения подготовки к развертываниюи эксплуатации) элементов и внутренних деталей абстракции (то есть модели) в отношенииреализации с тем, чтобы эти детали (как малозначимые для использования компонента или подругим причинам) были недоступны пользователям элементов (компонент).

При этом, в качестве“пользователя” одного компонента может выступать другой компонент. Более того, прииспользовании объектно-ориентированного подхода, наследники компонентов могут не иметьдоступа ко внутренним деталям реализации компонента, который является их предком (зависит отобъектно-ориентированной модели конкретного языка программирования или платформы).1.4.5 Разделение интерфейса и реализации (Separation of interface and implementation)Данная техника предполагает определение компонента через специфицирование интерфейса,известного (описанного) и доступного клиентам (или другим компонентам), от непосредственныхдеталей реализации.1.4.6 Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)Этот подход подразумевает, что создаваемые программные компоненты обладают всеминеобходимыми характеристиками, определенными абстракцией (моделью), но не более того. То естьне включают функциональность, отсутствующую в модели.Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых практик (bestpractices) методологий гибкого моделирования и экстремального программирования, где “все, чтонадо, но ни граммом больше” лежит в основе самой концепции “прагматичного” подхода (и на стадииCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru5Основы программной инженерии (по SWEBOK)Программная инженерия.

Проектирование программного обеспечения.моделирования, и в отношении реализации в коде). В оригинале этот принцип звучит как YAGNI –“You Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”.2. Ключевые вопросы проектирования (Key Issues in Software Design)В какой-то мере, данную секцию стоило перевести как ключевые проблемы. Как проводитьдекомпозицию? Как организовать и объединить компоненты в единую систему? Как обеспечитьнеобходимую производительность? Наконец, как обеспечить приемлемое качество системы? Все это– фундаментальные вопросы и проблемы проектирования, вне зависимости от используемых припроектировании подходов.2.1 Параллелизм (Concurrency)Эта тема охватывает вопросы, подходы и методы организации процессов, задач и потоков дляобеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработкиинформации.2.2 Контроль и обработка событий (Control and Handling of Events)В самом названии данной темы заложен комплекс обсуждаемых вопросов.

В частности, данная темакасается и неявных методов обработки событий, часто реализуемых в виде функции обратноговызова (call-back), как одной из фундаментальных концепций обработки событий.2.3 Распределение компонентов (Distribution of Components)Распределение (и выполнение) по различным узлам обработки в терминах аппаратногообеспечения, сетевой инфраструктуры и т.п. Один из важнейших вопросов данной темы –использование связующего программного обеспечения (middleware*)* часто middleware переводят как “промежуточное программное обеспечение”. Такой вариантперевода, к сожалению, рассматривает связующее ПО во второстепенной – “промежуточной” роли.Читатель, безусловно, может не согласиться с такой трактовкой, однако, многолетняя практикаавтора в обсуждении архитектурных вопросов с различными специалистами демонстрирует именнотакой взгляд пользователей, не знакомых или не имеющих успешного опыта разработки иэксплуатации распределѐнных систем.2.4 Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errorsand Exception Handling and Fault Tolerance )Вопрос темы, как ни странно, формулируется достаточно просто – как предотвратить сбои или, еслисбой все же произошел, обеспечить дальнейшее функционирование системы.2.5 Взаимодействие и представление (Interaction and Presentation)Тема касается вопросов представления информации пользователям и взаимодействияпользователей с системой, с точки зрения реакции системы на действия пользователей.

Речь в этойтеме идет о реакции системы в ответ на действия пользователей и организации ее отклика с точкизрения внутренней организации взаимодействия, например, в рамках популярной концепции ModelView-Controller.Ни в коем случае не надо путать данную тему с вопросами организации пользовательскогоинтерфейса, являющимеся частью “Эргономики программного обеспечения” – Software Ergonomics(см. “Связанные дисциплины”).Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru6Основы программной инженерии (по SWEBOK)Программная инженерия. Проектирование программного обеспечения.2.6 Сохраняемость данных (Data Persistence)Именно сохраняемость, а не сохранность, так как тема касается не доступа к базам данных, кактакового, а также не гарантий сохранности информации.

Суть вопроса – как должны обрабатываться“долгоживущие” данные.3. Структура и архитектура программного обеспечения (Software Structure and Architecture)В строгом значении архитектура программного обеспечения (software architecture) – описаниеподсистем и компонент программной системы, а также связей между ними. Архитектура пытаетсяопределить внутреннюю структуру получаемой системы, задавая способ, которым системаорганизована или конструируется.В середине 90-х, на волне распространения клиент-серверного подхода и начала еготрансформации в “многозвенный клиент-сервер”, призванный обеспечить централизованноеразвертывание и управление общей (для клиентских приложений) бизнес-логикой, вопросыорганизации архитектуры программного обеспечения стали складываться в самостоятельную идостаточно обширную дисциплину.