Процесс проектирования (Software Design Process)
Проектирование в основном рассматривается как двух-шаговый процесс:
1.3.1 Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент;
1.3.2 Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент.
Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде.
Техники применения (Enabling Techniques)
Принципы проектирования, также называемые техниками применения, являются ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах к проектированию программного обеспечения.
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)
Этот подход подразумевает, что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией (моделью), но не более того. То есть не включают функциональность, отсутствующую в модели.
|
|
|
Данный принцип особенно ярко выделен и явно представлен в виде рекомендуемых практик (best practices) методологий гибкого моделирования и экстремального программирования, где “все, что надо, но ни граммом больше” лежит в основе самой концепции “прагматичного” подхода (и на стадии моделирования, и в отношении реализации в коде). В оригинале этот принцип звучит как YAGNI – “You Aren’t Going to Need It”, то есть “не делай этого, пока не понадобится”.
Ключевые вопросы проектирования. Параллелизм. Контроль и обработка событий. Распределение компонентов. Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости. Взаимодействие и представление. Сохраняемость данных.
В какой-то мере, данную секцию стоило перевести как ключевые проблемы. Как проводить декомпозицию? Как организовать и объединить компоненты в единую систему? Как обеспечить необходимую производительность? Наконец, как обеспечить приемлемое качество системы? Все это – фундаментальные вопросы и проблемы проектирования, вне зависимости от используемых при проектировании подходов.
Параллелизм (Concurrency)
Эта тема охватывает вопросы, подходы и методы организации процессов, задач и потоков для обеспечения эффективности, атомарности, синхронизации и распределения (по времени) обработки информации.
Дата добавления: 2018-05-12; просмотров: 336; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!