Методы анализа & проектирования ПО

системы и конечного состава программного продукта. 

вопросы проектирования ПО
(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 и др.
Нотации включают языки описания архитектуры и интерфейса, диаграммы классов и объектов, диаграммы сущность-связь, конфигурации компонентов, схем развертывания, а также структурные диаграммы, задающие в наглядном виде операторы цикла, ветвления, выбора и последовательности.

программного обеспечения.
Различными организациями было разработано несколько различных ADLS, в

том числе:
AADL (стандарт SAE),
Wright (разработан в университете Carnegie Mellon),
Acme (разработан в университете Carnegie Mellon),
xADL (разработан в UCI),
Darwin (разработан в Imperial College в Лондоне),
DAOP-ADL (разработан в Университете Малаги),
а также ByADL (Университет L’Aquila, Италия).
Общими элементами для всех этих языков являются понятия компонента, коннектора и конфигурации. Также, помимо специализированных языков, для описания архитектуры часто используется унифицированный язык моделирования UML.

проектирования и отображения организационных структур.
UML является языком широкого профиля, это — открытый стандарт, использующий

графические обозначения для создания абстрактной модели системы, называемой UML-моделью.
UML был создан для определения, визуализации, проектирования и документирования, в основном, программных систем. UML не является языком программирования, но на основании UML-моделей возможна генерация кода.
UML позволяет также разработчикам программного обеспечения достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение, агрегация и поведение) и больше сконцентрироваться на проектировании и архитектуре.

и проектирования семантически близки к методам программирования на современных объектно-ориентированных языках;
UML позволяет описать

систему практически со всех возможных точек зрения и разные аспекты поведения системы;
Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
UML получил широкое распространение и динамично развивается.

(концептуальном) проектировании баз данных. С её помощью можно выделить ключевые сущности

и обозначить связи, которые могут устанавливаться между этими сущностями.
ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма)
( entity-relationship diagram, ERD).

классов в языке C++.
Реализации:
AIDL: Реализация IDL на Java для Android поддерживающая локальные и удаленные вызовы

процедур. Может быть доступна из нативных приложений посредством JNI.
CORBA IDL — язык описания интерфейсов распределённых объектов, разработанный рабочей группой OMG. Создан в рамках обобщённой архитектуры CORBA.
IDL DCE, язык описания интерфейсов спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group)
MIDL (Microsoft Interface Definition Language) — язык описания интерфейсов для платформы Win32 определяет интерфейс между клиентом и сервером. Предложенная от Microsoft технология использует реестр Windows и используется для создания файлов и файлов конфигурации приложений (ACF), необходимых для дистанционного вызова процедуры интерфейсов (RPC) и COM/DCOM интерфейсов.
COM IDL — язык описания интерфейсов между модулями COM. Является преемником языка IDL в технологии DCE  — спецификации межплатформенного взаимодействия служб, которую разработал консорциум Open Software Foundation (теперь The Open Group).

проектировании это описание поведения системы, когда она взаимодействует с кем-то (или

чем-то) из внешней среды. Система может отвечать на внешние запросы Актёра, может сама выступать инициатором взаимодействия. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем».
Методика сценариев использования применяется для выявления требований к поведению системы, известных также как пользовательские и функциональные требования.
В системном проектировании сценарии использования применяются на более высоком уровне чем при разработке программного обеспечения, часто представляя цели заинтересованных лиц или миссии. На стадии анализа требований сценарии использования могут быть преобразованы в ряд детальных требований и задокументированы с помощью диаграмм требований SysML или других подобных механизмов.

определение, анализ, проектирование, проверку и подтверждение соответствия широкого спектра систем.
SysML

изначально разрабатывался в рамках проекта спецификации с открытым исходным кодом, и имеет открытую лицензию для распространения и использования. Как язык, SysML является расширением части языка UML.

предоставляет системному инженеру дополнительные возможности:


Большая гибкость и выразительность. SysML убирает

программно-ориентированные ограничения UML за счёт введения двух дополнительных типов диаграмм: диаграммы требований и параметрической диаграммы. Первая, очевидно, служит для сбора требований, а вторая для количественного анализа и анализа производительности. В результате становится возможным моделирование широкого спектра систем, которые могут включать оборудование, ПО, информацию, процессы, персонал и площади.
SysML более компактный язык, его легче изучать и применять, так как он избавлен от многих программно-ориентированных особенностей 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 diagram, DFD) — один из основных инструментов структурного анализа и проектирования информационных систем, существовавших до широкого распространения UML. Несмотря на имеющее место в современных условиях смещение акцентов от структурного к объектно-ориентированному подходу к анализу и проектированию систем, «старинные» структурные нотации по-прежнему широко и эффективно используются как в бизнес-анализе, так и в анализе информационных систем.
Модель DFD, как и большинство других структурных моделей — иерархическая модель. Каждый процесс может быть подвергнут декомпозиции, то есть разбиению на структурные составляющие, отношения между которыми в той же нотации могут быть показаны на отдельной диаграмме. Когда достигнута требуемая глубина декомпозиции — процесс нижнего уровня сопровождается мини-спецификацией (текстовым описанием).

операторам в языках программирования, они устанавливают связь между условиями и действиями. Но,

в отличие от традиционных языков программирования, таблицы решений в простой форме могут представлять связь между множеством независимых условий и действий.
В простейшем случае здесь Условия — список возможных условий, Варианты выполнения условий — комбинация из выполнения и/или невыполнения условий из этого списка. Действия — список возможных действий, Необходимость действий — указание надо или не надо выполнять соответствующее действие для каждой из комбинаций условий.
Например, для ситуации «неожиданно погас свет» таблица принятия решений может быть такой:

составные части. Под деятельностью понимается спецификация исполняемого поведения в виде

координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий, соединённых между собой потоками, которые идут от выходов одного узла ко входам другого.
Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.

с другом. Кооперация определяет набор взаимодействующих ролей, используемых вместе, чтобы показать некую

функциональность. Кооперация часто реализует некоторый паттерн (шаблон проектирования).
Собственно, слово "кооперация" значит "совместная деятельность", "сотрудничество". Такие диаграммы показывают, как объекты работают вместе для достижения общей цели, акцентируясь на их ролях.
Следует отметить, что здесь имеет место некоторая терминологическая путаница. В оригинале такие диаграммы называются Collaboration Diagram. Слово "collaboration", конечно же, синоним слова "cooperation", но в "русском" варианте звучит хуже. Поэтому в русскоязычных учебниках говорят "диаграмма кооперации", а не "коллаборации". Кроме этого, само это название немного устарело - в UML 2.x подобные диаграммы называются Communication Diagram. Впрочем, все три слова - "cooperation", "collaboration" и "communication" - являются синонимами, так что довольно часто используется "старое" название. Часто даже, говоря "диаграммы взаимодействия", подразумевают именно диаграммы кооперации.

предназначены для описания динамических аспектов моделируемой системы. Обычно они применяются

для того, чтобы:
Показать набор взаимодействующих объектов в реальном окружении "с высоты птичьего полета";
Распределить функциональность между классами, основываясь на результатах изучения динамических аспектов системы;
Описать логику выполнения сложных операций, особенно в тех случаях, когда один объект взаимодействует еще с несколькими объектами;
Изучить роли, выполняемые объектами внутри системы, а также отношения между объектами, в которые они вовлекаются, выполняя эти роли.

временной оси показаны жизненный цикл (создание-деятельность-уничтожение) и взаимодействие (отправка запросов

и получение ответов). Используется в языке UML.
Основными элементами диаграммы последовательности являются обозначения объектов (прямоугольники с названиями объектов), вертикальные «линии жизни», отображающие течение времени, прямоугольники, отражающие деятельность объекта или исполнение им определенной функции (прямоугольники на пунктирной «линии жизни»), и стрелки, показывающие обмен сигналами или сообщениями между объектами.

способов их преобразований, (в отличие от активных языков) без явного

упоминания порядка выполняемых действий и использования конкретных значений данных.
Z-нота́ция  — формальный язык спецификации, используемый для описания и моделирования программ и их формальной верификации, основана на стандартной математической нотации, используемой в аксиоматической теории множеств, лямбда-исчислении и логике предикатов первого порядка. Допустимые выражения в Z-нотации подобраны таким образом, чтобы избегать парадоксов аксиоматической теории множеств. Также Z-нотация содержит стандартизированный каталог часто используемых математических функций и предикатов.
RAISE - (Строгий подход к промышленной инженерии программного обеспечения) была разработана в рамках проекта Европейского ESPRIT II LACOS в 1990-е годы. Она состоит из набора инструментов, предназначенных для языка спецификаций (RSL) для разработки программного обеспечения.

и др.методы:
Функционально-ориентированные,
Структурные (которые базируются на структурном анализе),
Структурных картах,
Диаграммах потоков данных

(Dataflow) и др.