Организация процесса проектирования инфокоммуникационных систем

Язык UML практически не зависим от организации процесса разработки, и его можно применять, например, при создании систем в рамках технологии, ориентированной на использовании главным образом каскадной модели жизненного цикла. Стадии и этапы работы согласно этой технологии описаны в действующем стандарте ГОСТ 34.601-90 (переиздание 01.09.2009).

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

Стадия 1. Формирование требований к системе.

На этой стадии проектирования выделяют следующие этапы работ:

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

Стадия 2. Разработка концепции.

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

Стадия 3. Техническое задание.

• разработка и утверждение технического задания на создание систем.

Стадия 4. Эскизный проект.

• разработка предварительных проектных решений по системе и ее частям;
• разработка эскизной документации на систему в целом и ее части.

Стадия 5. Технический проект.

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

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

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

Следующей диаграммной, которая может быть построена, является диаграмма последовательности (sequence diagram). С помощью этой диаграммы описывают поведение взаимодействующих групп объектов. Как правило, для каждого случая (прецедента) составляется своя диаграмма последовательности. На диаграмме отображаются объекты, сообщения, которыми они обмениваются, и временная шкала обмена этими сообщениями. По горизонтали можно проследить последовательность возникновения сообщений. По вертикали для каждого объекта отображается набор входящих и исходящих сообщений в порядке их возникновения.

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

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

• управляется вариантами использования;
• сконцентрирован на архитектуре;
• является итеративным и инкрементным.

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

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

Итеративным (Iterative) называется процесс, который предполагает управление потоком исполняемых версий системы. Инкрементный (Incremental) процесс подразумевает постоянное развитие системной архитектуры при выпуске новых версий, причем каждая следующая версия усовершенствована в сравнении с предыдущей. Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками(Risk-driven), поскольку при этом в каждой новой версии серьезное внимание уделяется выявлению факторов, представляющих наибольший риск для успешного завершения проекта, и сведению их до минимума. В следующем пункте данный процесс рассматривается подробнее.