КАТЕГОРИИ: Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748) |
Техники применения (Enabling Techniques)Процесс проектирования (Software Design Process) Контекст проектирования (Context of Software Design) Общие концепции проектирования (General Design Concepts) Основы проектирования (Software Design Fundamentals) Эта секция вводит концепции, понятия и терминологию в качестве основы для понимания роли и содержания проектирования (как деятельности) и дизайна (архитектуры, как результата) программного обеспечения. Темы данной секции: К ним относятся: цель архитектуры, ее ограничения, возможные альтернативы, используемые представления и решения. Например, архитектурный фреймворк – TOGAF [TOGAF, 2003], разработанный и развиваемый консорциумом The Open Group (www.opengroup.org), предлагает следующие <возможные> цели (goals):
Для понимания роли проектирования программного обеспечения важно понимать контекст, в котором осуществляется проектирование и используются его результаты. В качестве такого контекста выступает жизненный цикл программной инженерии, а проектирование напрямую связано с результатами анализа требований, конструированием программных систем и их тестированием. Стандарты жизненного цикла, например, IEEE и ISO/IEC (ГОСТ Р) 12207 уделяют специальное внимание вопросам проектирования и детализируют их, описывая контекст проектирования – от требований до тестов. Проектирование в основном рассматривается как двух-шаговый процесс: 1.3.1 Архитектурное проектирование – декомпозиция структуры (статической) и организации (динамической) компонент; 1.3.2 Детализация архитектуры – описывает специфическое поведение и характеристики отдельных компонент. Выходом этого процесса является набор моделей и артефактов, содержащих результаты решений, принятых по способам реализации требований в программном коде. Принципы проектирования, также называемые техниками применения, являются ключевыми идеями и концепциями, рассматриваемыми на фундаментальном уровне в различных методах и подходах к проектированию программного обеспечения. 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”, то есть “не делай этого, пока не понадобится”.
Дата добавления: 2014-10-22; Просмотров: 576; Нарушение авторских прав?; Мы поможем в написании вашей работы! Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет |