Согласованность и целостность документации.

 Управление документацией требует значительных организационных навыков. Написание хорошей и гибкой документации сродни написанию хорошего и гибкого кода.

Управление документацией подразумевает поддержание ее полноты и согласованности и включает в себя также управление конфигурациями.

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

Согласованность означает, что набор документов не содержит внутренних противоречий.Проблема в том, что когда этот набор велик, то довольно сложно избежать появления в нем взаимоисключающих утверждений.

Поддержка конфигурации – это координация различных версий и частей документации и программного кода.

Способы представления предметной области.

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

  Используются несколько систем обозначений для перечисленных элементов, наиболее известны нотация Йордана-ДеМарко и нотация Гэйна-Сарсона.

Процессы на диаграммах потоков данных могут уточняться: если некоторый процесс устроен достаточно сложно, для него можно нарисовать отдельную диаграмму, описывающую потоки данных внутри этого процесса.

Выделение и анализ требований.

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

Формулировка потребностей может быть разбита на следующие этапы: Выделить одну-две-три основных проблемы. Определить причины возникновения проблем, оценить степень их влияния и выделить наиболее существенные из проблем, влекущие появление остальных. Определить ограничения на возможные решения.

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

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

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

В.19 Стандарты, регламентирующие работу с требованиями.

Правила работы с требования к ПО и более общими системными требованиями (к программно-аппаратной системе), определяются следующими двумя стандартами IEEE.

  IEEE 830-1998Описывает структуру документов для фиксации требований к ПО.
Кроме того, он определяет характеристики, которыми должен обладать правильно составленный набор требований (соответствие реальным потребностям, однозначность понимания, отражение всех выделенных потребностей, согласованность между различными элементами, оформление в удобных для внесения изменений структуре и стилях).

IEEE 1233-1998Описывает правила построения требований для программно-аппаратных систем в целом. Он выделяет следующие необходимые свойства набора требований (Однократное упоминание отдельных требований, Отсутствие пересечений между требованиями, Явное указание связей между требованиями, Полнота, Непротиворечивость, Определение ограничений).

Архитектура ПО.

 Архитектура ПО - набор внутренних структур ПО, которые видны с различных точек зрения и состоят из компонентов, их связей и возможных взаимодействий между компонентами, а также доступных извне свойств этих компонентов.

   Компонент - достаточно произвольный структурный элемент ПО, который можно выделить, определив интерфейс взаимодействия между этим компонентом и всем, что его окружает.

     Aрхитектура ПО представляет собой набор структур или представлений, имеющих различные уровни абстракции и показывающих разные аспекты, объединяемых сопоставлением всех представленных данных со структурными элементами ПО.

Архитектура определяет большинство характеристик качества ПО в целом. Архитектура служит также основным средством общения между разработчиками, а также между разработчиками и всеми остальными лицами, заинтересованными в данном ПО.

   Выбор архитектуры задает способ реализации требований на высоком уровне абстракции. Именно архитектура почти полностью определяет такие характеристики ПО как надежность, переносимость и удобство сопровождения.

21   Список стандартов, регламентирующих описание архитектуры.

 IEEE 1016-1998 (рекомендуемые методы описаний проектных решений для ПО).

IEEE 1471-2000 (рекомендуемые методы описания архитектуры программных систем).

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

       Стандарт IEEE 1471 отмечает необходимость использования архитектуры системы для решения таких задач: Анализ альтернативных проектов системы. Планирование перепроектирования системы, внесения изменений в ее организацию. Общение по поводу системы между различными организациями, вовлеченными в ее разработку, эксплуатацию, сопровождение, приобретающими систему или продающими ее. Выработка критериев приемки системы при ее сдаче в эксплуатацию. Разработка документации по ее использованию и сопровождению, включая обучающие и маркетинговые материалы. Проектирование и разработка отдельных элементов системы.

22 Цели и история создания языка UML

23 Перспективы развития и стандартизации UML. Виды диаграмм UML.

24Основные средства и модели языка UML.

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

Статические диаграммы представляют либо постоянно присутствующие в системе сущности и связи между ними, либо суммарную информацию о сущностях и связях, либо сущности и связи, существующие в какой-то определенный момент времени. Они не показывают способов поведения этих сущностей. К этому типу относятся диаграммы классов, объектов, компонентов и диаграммы развертывания.

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

Статические диаграммы.

 Статические диаграммы представляют либо постоянно присутствующие в системе сущности и связи между ними, либо суммарную информацию о сущностях и связях, либо сущности и связи, существующие в какой-то определенный момент времени. Они не показывают способов поведения этих сущностей. К этому типу относятся диаграммы классов, объектов, компонентов и диаграммы развертывания.

· Диаграммы классов (показывают классы или типы сущностей системы, характеристики классов (поля и операции) и возможные связи между ними)

· Диаграммы объектов (показывают часть объектов системы и связи между ними в некотором конкретном состоянии или суммарно, за некоторый интервал времени)

· Диаграммы компонентов (представляют компоненты в нескольких смыслах — атомарные составляющие системы с точки зрения ее сборки, конфигурационного управления и развертывания)

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

Динамические диаграммы.

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

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

· Диаграммы сценариев (показывают возможные сценарии обмена сообщениями или вызовами во времени между различными компонентами системы (здесь имеются в виду архитектурные компоненты, компоненты в широком смысле — это могут быть компоненты развертывания, обычные ))

· Диаграммы взаимодействия (показывают ту же информацию, что и диаграммы сценариев, но привязывают обмен сообщениями/вызовами не к времени, а к связями между компонентами)

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