2-software_engineering_design (1133542), страница 4

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 4)

Могут быть использованы для количественной оценки ожиданий вотношении различных аспектов конкретного дизайна, например, размера <проекта>, структуры (еесложности) или качества (например, в контексте требований, предъявляемых к производительности).Чаще всего, все метрики разделяют по двум категориям: функционально-ориентированные объектно-ориентированные5. Нотации проектирования (Software Design Notations)Нотация есть соглашение о представлении. Часто под нотацией подразумевают визуальное(графическое) представление.

Нотация может задаваться: стандартом; например, OMG UML – Unified Modeling Language, развиваемый консорциумомOMG (Object Management Group, http://www.omg.org);Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru9Основы программной инженерии (по SWEBOK)Программная инженерия. Проектирование программного обеспечения.общепринятой практикой; например, в eXtreme Programming часто используются карточкифункциональной ответственности и связей класса - Class Responsibility Collaborator или CRCCard (CRC по свое природе является текстовой, то есть невизуальной нотацией);внутренним методом проектной команды (“будем рисовать и обозначать так...”).Определенные нотации используются на стадии концептуального проектирования, ряд нотацийориентирован на создание детального дизайна, многие могут использоваться на обеих стадиях.Кроме того, нотации чаще всего используют в контексте (выбор нотации может быть обусловлентаким контекстом) применяемой методологии или подхода (см.

6 “Software Design Strategies andMethods” данной области знаний). Ниже мы будем рассматривать нотации, исходя из описанияструктурного (статического) или поведенческого (динамического) представления.5.1 Структурные описания, статический взгляд (Structural Descriptions, static view)Следующие нотации, в основном (но, не всегда), являются графическими, описывая и представляяструктурные аспекты программного дизайна. Чаще всего они касаются основных компонент и связеймежду ними (статических связей, например, таких как отношения “один-ко-многим”).Языки описания архитектуры (Architecture description language, ADL): текстовые языки,часто – формальные, используемые для описания программной архитектуры в терминахкомпонентов и коннекторов (специализированных компонентов, реализующих нефункциональность, но обеспечивающих взаимосвязь функциональных компонентов междусобой и с “внешним миром”);Диаграммы классов и объектов (Class and object diagrams): используются дляпредставления набора классов и <статических> связей между ними (например,наследования);Диаграммы компонентов или компонентные диаграммы (Component diagrams): вопределенной степени аналогичны диаграммам классов, однако, в силу спецификиконцепции или понятия компонента*, обычно, представляются в другой визуальной форме;* здесь необходимо отметить различие в понятиях класса (или объекта) и компонента:компонент рассматривается как физически реализуемый элемент программногообеспечения, несущий <в определенной степени> самодостаточную логику и реализуемыйкак конгломерат интерфейса и его реализации (часто, в виде комплекса классов);Карточки <функциональной> ответственности и связей класса (Class responsibilitycollaborator card, CRC): используются для обозначения имени класса, его ответственности (тоесть, что он должен делать) и других сущностей (классов, компонентов, актѐров/ролей и т.п.),с которыми он связан; часто их называют карточками “класс-обязанность-кооперация”;Диаграммы развѐртывания (Deployment diagrams): используется для представления(физических) узлов, связей между ними и моделирования других физических аспектовсистемы;Диаграммы сущность-связь (Entity-relationship diagram, ERD или ER): используется дляпредставления концептуальной модели данных, сохраняемых в процессе работыинформационной системы;Языки описания/определения интерфейса (Interface Description Languages, IDL): языки,подобные языкам программирования, не включающие возможностей описания логикисистемы и предназначенные для определения интерфейсов программных компонентов (имѐни типов экспортируемых или публикуемых операций);Структурные диаграммы Джексона (Jackson structure diagrams): используются для описанияструктур данных в терминах последовательности, выбора и итераций (повторений);Структурные схемы (Structure charts): описываю структуру вызовов в программах (какоймодуль вызывает, кем и как вызываем).5.2 Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view)Следующие нотации и языки (часть из которых – графические, часть - текстовые) используются дляописания динамического поведения программных систем и их компонентов.

Многие из этих нотацийуспешно используются для проектирования деталей дизайна, но не только для этого.Copyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru10Основы программной инженерии (по SWEBOK)Программная инженерия. Проектирование программного обеспечения.Диаграммы деятельности или операций (Activity diagrams): используются для описанияпотоков работ и управления;Диаграммы сотрудничества (Collaboration diagrams): показывают динамическоевзаимодействие, происходящее в группе объектов и уделяют особое внимание объектам,связям между ними и сообщениям, которыми обмениваются объекты посредством этихсвязей;Диаграммы потоков данных (Data flow diagrams, DFD): описывают потоки данных внутринабора процессов (не в терминах процессов операционной среды, но в понимании обменаинформацией в бизнес-контексте);Таблицы и диаграммы <принятия> решений (Decision tables and diagrams): используютсядля представления сложных комбинаций условий и действий (операций);Блок-схемы и структурированные блок-схемы (Flowcharts and structured flowcharts):применяются для представления потоков управления (контроля) и связанных операций;Диаграммы последовательности (Sequence diagrams): используются для показавзаимодействий внутри группы объектов с акцентом на временной последовательностисообщений/вызовов;Диаграммы перехода и карты состояний(State transition and statechart diagrams):применяются для описания потоков управления переходами между состояниями;Формальные языки спецификации (Formal specification languages): текстовые языки,использующие основные понятия из математики (например, множества) для строгого иабстрактного определения интерфейсов и поведения программных компонентов, часто втерминах пред- и пост-условий;Псевдокод и программные языки проектирования (Pseudocode and program designlanguages, PDL): языки, используемые для описания поведения процедур и методов, восновном на стадии детального проектирования; подобны структурным языкампрограммирования.6.

Стратегии и методы проектирования программного обеспечения (Software Design Startegiesand Methods)Существуют различные общие стратегии, помогающие в проведении работ по проектированию. Вотличие от общих стратегий, методы проектирования более специфичны и, в основном, предлагаюти предоставляют нотации (или наборы нотаций) для использования совместно с этими методами, атакже процессы, которым необходимо следовать в рамках используемого метода.Таким образом, методы в данном контексте это не просто некие “слабоформализованные” илипросто частные практические подходы или техники. Методы здесь являются более общимипонятиями, это - методологии, сконцентрированные на процессе (в частности, проектирования) ипредполагающие следование определенным правилам и соглашениям, в том числе – поиспользуемым выразительным средствам.

Такие методы полезны как инструмент систематизации(иногда, формализации) и передачи знаний в виде общего фреймворка (то есть комплексного наборапонятий, подходов, техник и инструментов) не только для отдельных специалистов, но для команд ипроектных групп программных проектов.6.1 Общие стратегии (General Strategies)Это обычно часто упоминаемые и общепринятые стратегии: “разделяй-и-властвуй” и пошаговое уточнение проектирование “сверху-вниз” и “снизу-вверх” абстракция данных и сокрытие информации итеративный и инкрементальный подход и другие...6.2 Функционально-ориентированное или структурное проектирование (Function-Oriented –Structured Design)Это один из классических методов проектирования, в котором декомпозиция сфокусирована наидентификации основных программных функций и, затем, детальной разработке и уточнении этихфункций “сверху-вниз”. Структурное проектирование, обычно, используется после проведенияCopyright © Сергей Орлик, 2004-2010.http://swebok.sorlik.ru11Основы программной инженерии (по SWEBOK)Программная инженерия.

Проектирование программного обеспечения.структурного анализа с применением диаграмм потоков данных и связанным описанием процессов.Исследователи предлагают различные стратегии и метафоры или подходы для трансформации DFDв программную архитектуру, представляемую в форме структурных схем. Например, сравниваяуправление и поведение с получаемым эффектом.6.3 Объектно-ориентированное проектирование (Object-Oriented Design)Представляет собой множество методов проектирования, базирующихся на концепции объектов.Данная область активно эволюционирует с середины 80-х годов, основываясь на понятиях объекта(сущности), метода (действия) и атрибута (характеристики).

Здесь главную роль играютполиморфизм и инкапсуляция, в то время, как в компонентно-ориентированном подходе большеезначение придается мета-информации, например, с применением технологии отражения (reflection).Хотя корни объектно-ориентированного проектирования лежат в абстракции данных (к которымдобавлены поведенческие характеристики), так называемый responsibility-driven design илипроектирование на основе <функциональной> ответственности по SWEBOK* может рассматриватьсякак альтернатива объектно-ориентированному проектированию.*С точки зрения автора книги, такое противопоставление – достаточно спорный вопрос, так какфункциональная ответственность столь же близка принципам современного объектноориентированного проектирования, сколь и абстракция данных. Это вопрос эволюционированиявзглядов и степени их консерватизма.6.4 Проектирование на основе структур данных (Data-Structure-Centered Design)В данном подходе фокус сконцентрирован в большей степени на структурах данных, которымиуправляет система, чем на функциях системы.

Инженеры по программному обеспечению частовначале описывают структуры данных входов (inputs) и выходов (outputs), а, затем, разрабатываютструктуру управления этими данными (или, например, их трансформации).6.5 Компонентное проектирование (Component-Based Design)Программные компоненты являются независимыми единицами, которые обладают однозначноопределенными (well-defined) интерфейсами и зависимостями (связями) и могут собираться иразвертываться независимо друг от друга.

Характеристики

Список файлов книги