Методы анализа & проектирования ПО Каблуков М. 315 с
• Проектирование ПО - это процесс определения архитектуры, компонентов, интерфейсов, других характеристик системы и конечного состава программного продукта.
"Проектирование ПО (Software Design)" • Базовые концепции проектирования ПО (Software Design Basic Concepts), • Ключевые вопросы проектирования ПО (Key Issue in Software Design), • Структура и архитектура ПО (Software Structure and Architecture), • Анализ и оценка качества проектирования ПО (Software Design Quality Analysis and Evaluation), • Нотации проектирования ПО (Software Design Notations), • Стратегия и методы проектирования ПО (Software Design Strategies and Methods).
Базовая концепция проектирования ПО Это методология проектирования архитектуры с помощью разных методов (объектного, компонентного и др. ), процессы ЖЦ (стандарт ISO/IEC 12207) и техники - декомпозиция, абстракция, инкапсуляция и др.
Ключевые вопросы проектирования ПО К ключевым вопросам проектирования ПО относятся: • Декомпозиция программ на функциональные компоненты для независимого и параллельного их выполнения, • Принципы распределения компонентов в среде выполнения и их взаимодействия между собой, • Механизмы обеспечения качества и живучести системы и др.
Структура и архитектура ПО • При проектировании архитектуры ПО используется архитектурный стиль проектирования, основанный на определении основных элементов структуры подсистем, компонентов и связей между ними. Архитектура проекта - высокоуровневое представление структуры системы и спецификация ее компонентов. Архитектура определяет логику отдельных компонентов системы настолько детально, насколько это необходимо для написания кода, а также определяет связи между компонентами. Существуют и другие виды представления структур, основанные на проектировании образцов, шаблонов, семейств программ и каркасов программных сред.
Pattern Одним из важнейших инструментов проектирования архитектуры является паттерн - типовой конструктивный элемент ПО, который задает взаимодействие объектов (компонентов) проектируемой системы, а также роли и ответственности исполнителей.
Анализ и оценка качества проектирования ПО Мероприятия по анализу сформулированных в требованиях атрибутов качества, оценки различных аспектов ПО: • Количества функций, • Структура ПО, • Качества проектирования с помощью формальных метрик (функционально-ориентированных, структурных и объектно-ориентированных), • Проведения качественного анализа результатов проектирования путем статического анализа, моделирования и прототипирования.
Нотации проектирования • Нотации проектирования позволяют представить описание объекта (элемента) ПО и его структуру, а также поведение системы. • Существует два типа нотаций: структурные, поведенческие и множество различных их представлений.
Структурные нотации • Это структурное, блок-схемное или текстовое представление аспектов проектирования структуры ПО из объектов, компонентов, их интерфейсов и взаимосвязей. • К нотациям относятся формальные языки спецификаций и проектирования: • ADL (Architecture Description Language), UML (Unified Modeling Language), ERD (Entity-Relationship Diagrams), IDL (Interface Description Language), Use Case Driven и др. Нотации включают языки описания архитектуры и интерфейса, диаграммы классов и объектов, диаграммы сущность-связь, конфигурации компонентов, схем развертывания, а также структурные диаграммы, задающие в наглядном виде операторы цикла, ветвления, выбора и последовательности.
ADL (Architecture Description Language) • Языки описания архитектуры (ADLS) используются для описания архитектуры программного обеспечения. • Различными организациями было разработано несколько различных ADLS, в том числе: • AADL (стандарт SAE), Wright (разработан в университете Carnegie Mellon), Acme (разработан в университете Carnegie Mellon), x. ADL (разработан в UCI), Darwin (разработан в Imperial College в Лондоне), DAOP-ADL (разработан в Университете Малаги), а также By. ADL (Университет L’Aquila, Италия). Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации. Также, помимо специализированных языков, для описания архитектуры часто используется унифицированный язык моделирования UML.
UML (Unified Modeling Language) • Язык графического описания для объектного моделирования в области разработки программного обеспечения, моделирования бизнес-процессов, системного проектирования и отображения организационных структур. • UML является языком широкого профиля, это — открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. • UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода. • UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение, агрегация и поведение) и больше сконцентрироваться на проектировании и архитектуре.
Преимущества UML • UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных объектноориентированных языках; • UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы; • Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом; • UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии; • UML получил широкое распространение и динамично развивается.
ERD (Entity-Relationship Diagrams) • Модель данных, позволяющая описывать концептуальные схемы предметной области. • ER-модель используется при высокоуровневом (концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности и обозначить связи, которые могут устанавливаться между этими сущностями. • ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма) • ( entity-relationship diagram, ERD).
IDL (Interface Description Language) • Язык спецификаций для описания интерфейсов, синтаксически похожий на описание классов в языке C++. • Реализации: AIDL: Реализация IDL на Java для Android поддерживающая локальные и удаленные вызовы процедур. Может быть доступна из нативных приложений посредством JNI. CORBA IDL — язык описания интерфейсов распределённых объектов, разработанный рабочей группой OMG. Создан в рамках обобщённой архитектуры CORBA. IDL DCE, язык описания интерфейсов спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group) MIDL (Microsoft Interface Definition Language) — язык описания интерфейсов для платформы Win 32 определяет интерфейс между клиентом и сервером. Предложенная от Microsoft технология использует реестр Windows и используется для создания файлов и файлов конфигурации приложений (ACF), необходимых для дистанционного вызова процедуры интерфейсов (RPC) и COM/DCOM интерфейсов. COM IDL — язык описания интерфейсов между модулями COM. Является преемником языка IDL в технологии DCE — спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group).
Use Case Driven • Сценарий использования, вариант использования, прецедент использования — в разработке программного обеспечения и системном проектировании это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Система может отвечать на внешние запросы Актёра, может сама выступать инициатором взаимодействия. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем» . • Методика сценариев использования применяется для выявления требований к поведению системы, известных также как пользовательские и функциональные требования. • В системном проектировании сценарии использования применяются на более высоком уровне чем при разработке программного обеспечения, часто представляя цели заинтересованных лиц или миссии. На стадии анализа требований сценарии использования могут быть преобразованы в ряд детальных требований и задокументированы с помощью диаграмм требований Sys. ML или других подобных механизмов.
Sys. ML • The Systems Modeling Language, язык моделирования систем. • Предметно-ориентированный язык моделирования систем. Поддерживает определение, анализ, проектирование, проверку и подтверждение соответствия широкого спектра систем. • Sys. ML изначально разрабатывался в рамках проекта спецификации с открытым исходным кодом, и имеет открытую лицензию для распространения и использования. Как язык, Sys. ML является расширением части языка UML.
• По сравнению с UML, ориентированным на моделирование программных продуктов, Sys. ML предоставляет системному инженеру дополнительные возможности: Большая гибкость и выразительность. Sys. ML убирает программноориентированные ограничения UML за счёт введения двух дополнительных типов диаграмм: диаграммы требований и параметрической диаграммы. Первая, очевидно, служит для сбора требований, а вторая для количественного анализа и анализа производительности. В результате становится возможным моделирование широкого спектра систем, которые могут включать оборудование, ПО, информацию, процессы, персонал и площади. Sys. ML более компактный язык, его легче изучать и применять, так как он избавлен от многих программно-ориентированных особенностей UML. Конструкции языка для управления моделью поддерживают модели, представления и точки зрения (используются для создания представлений). Эти конструкции расширяют возможности UML и архитектурно стоят в одном ряду с IEEE-Std-1471 -2000 (Рекомендованная IEEE практика для архитектурного описания программно-нагруженных систем) (IEEE Recommended Practice for Architectural Description of Software Intensive Systems).
Поведенческие нотации • Поведенческие нотации отражают динамический аспект поведения систем и их компонентов. • Таким нотациям соответствуют: Диаграммы потоков данных (Data Flow), Таблиц принятия решений (Decision Tables), Деятельности (Activity), Кооперации (Colloboration), Последовательности (Sequence), Формальные языки спецификации (Z, RAISE).
Диаграммы потоков данных (Data Flow) • Так называется методология графического структурного анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных, к которым осуществляется доступ. • Диаграмма потоков данных (data flow diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектноориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем. • Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается миниспецификацией (текстовым описанием).
Таблиц принятия решений (Decision Tables) • Способ компактного представления модели со сложной логикой. Аналогично условным операторам в языках программирования, они устанавливают связь между условиями и действиями. Но, в отличие от традиционных языков программирования, таблицы решений в простой форме могут представлять связь между множеством независимых условий и действий. • В простейшем случае здесь Условия — список возможных условий, Варианты выполнения условий — комбинация из выполнения и/или невыполнения условий из этого списка. Действия — список возможных действий, Необходимость действий — указание надо или не надо выполнять соответствующее действие для каждой из комбинаций условий. • Например, для ситуации «неожиданно погас свет» таблица принятия решений может быть такой:
Деятельности (Activity) • UML-диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого. • Диаграммы деятельности используются при моделировании бизнеспроцессов, технологических процессов, последовательных и параллельных вычислений.
Кооперации (Colloboration) • Это статическая конструкция для моделирования набора сущностей, взаимодействующих друг с другом. Кооперация определяет набор взаимодействующих ролей, используемых вместе, чтобы показать некую функциональность. Кооперация часто реализует некоторый паттерн (шаблон проектирования). • Собственно, слово "кооперация" значит "совместная деятельность", "сотрудничество". Такие диаграммы показывают, как объекты работают вместе для достижения общей цели, акцентируясь на их ролях. • Следует отметить, что здесь имеет место некоторая терминологическая путаница. В оригинале такие диаграммы называются Collaboration Diagram. Слово "collaboration", конечно же, синоним слова "cooperation", но в "русском" варианте звучит хуже. Поэтому в русскоязычных учебниках говорят "диаграмма кооперации", а не "коллаборации". Кроме этого, само это название немного устарело - в UML 2. x подобные диаграммы называются Communication Diagram. Впрочем, все три слова "cooperation", "collaboration" и "communication" - являются синонимами, так что довольно часто используется "старое" название. Часто даже, говоря "диаграммы взаимодействия", подразумевают именно диаграммы кооперации.
• Итак, мы уже говорили, что, подобно диаграммам последовательностей, диаграммы кооперации предназначены для описания динамических аспектов моделируемой системы. Обычно они применяются для того, чтобы: Показать набор взаимодействующих объектов в реальном окружении "с высоты птичьего полета"; Распределить функциональность между классами, основываясь на результатах изучения динамических аспектов системы; Описать логику выполнения сложных операций, особенно в тех случаях, когда один объект взаимодействует еще с несколькими объектами; Изучить роли, выполняемые объектами внутри системы, а также отношения между объектами, в которые они вовлекаются, выполняя эти роли.
Последовательности (Sequence) • Диаграмма, на которой для некоторого набора объектов на единой временной оси показаны жизненный цикл (созданиедеятельность-уничтожение) и взаимодействие (отправка запросов и получение ответов). Используется в языке UML. • Основными элементами диаграммы последовательности являются обозначения объектов (прямоуго льники с названиями объектов), вертикальные «линии жизни» , отображающие течение времени, прямоугольники, отражающие деятельность объекта или исполнение им определенной функции (прямоугольники на пунктирной «линии жизни» ), и стрелки, показывающие обмен сигналами или сообщениями между объектами.
Язык спецификаций • Формальный язык, предназначенный для декларативного описания структуры, связей, свойств данных и способов их преобразований, (в отличие от активных языков) без явного упоминания порядка выполняемых действий и использования конкретных значений данных. • Z-нота ция — формальный язык спецификации, используемый для описания и моделирования программ и их формальной верификации, основана на стандартной математической нотации, используемой в аксиоматической теории множеств, лямбда-исчислении и логике предикатов первого порядка. Допустимые выражения в Z-нотации подобраны таким образом, чтобы избегать парадоксов аксиоматической теории множеств. Также Z-нотация содержит стандартизированный каталог часто используемых математических функций и предикатов. • RAISE - (Строгий подход к промышленной инженерии программного обеспечения) была разработана в рамках проекта Европейского ESPRIT II LACOS в 1990 -е годы. Она состоит из набора инструментов, предназначенных для языка спецификаций (RSL) для разработки программного обеспечения.
Стратегия и методы проектирования ПО • К стратегиям относятся: Проектирование снизу-вверх, сверху-вниз, Абстрагирование, Использование паттернов и др. методы: Функционально-ориентированные, Структурные (которые базируются на структурном анализе), Структурных картах, Диаграммах потоков данных (Dataflow) и др.
Благодарю за внимание!
Скачать презентацию Методы анализа проектирования ПО Каблуков М 315
Методы анализа и проектирования ПО(Каблуков М.315с).ppt