CC BY
19
Гагарин А.П.
Московский авиационный институт (национальный исследовательский университет), Москва, к.т.н., профессор по кафедре информатики, gagarin ay@outlook.com
Интеграция технологий проектирования и технологий управления проектами в области программного обеспечения "систем-систем"
КЛЮЧЕВЫЕ СЛОВА
Система-систем, CRM-система, программная инженерия, управление программными проектами, адаптивная технология проектирования, экстремально программирование, язык UML, прецедент, диаграмма прецедентов, класс, атрибут класса, метод класс, диаграмма классов, диаграмма последовательностей, ассоциация, артефакт, спринт, IDE.
АННОТАЦИЯ
В статье обсуждается проблема интеграции технологий проектирования и технологий управления проектами при разработке и долговременном сопровождении программных продуктов и систем. Проблема актуальна, в частности, для "систем-систем" (Systems of Systems), для которых может потребоваться неоднократное обновление технологий их собственного развития и технической поддержки. Предлагается решение этой проблемы на основе моделей на языке UML. Особую важность эта система приобретает при работе с большими данными.
"Система-систем" (System of Systems) обязана сохранять свою целостность на протяжении исторических периодов времени, сравнимых со сроками, в течение которых совершают шаги своего развития информационные технологии, применяемые в системах такого рода [1]. Технология проектирования, применявшаяся при создании "системы-систем", наверняка устареет к концу её жизненного цикла. С другой стороны, текущие процессы технической поддержки программного обеспечения "системы-систем" требуют постоянного применения подходящих средств программирования и проектирования. Таким образом, предвидится объективная целесообразность включения в "системы-систем" на правах их подсистем технологических комплексов проектирования и конструирования программной продукции. Для обеспечения упорядоченного развития этих подсистем "в ногу' c развитием включающей их "системы-систем" и с учётом текущего уровня программной инженерии, в неё должны включаться соответствующие
системы управления программными проектами. Указанная перспектива придаёт актуальность проблеме интеграции, заявленной в названии доклада.
Типовая модель организации проектирования программной продукции представлена на рис.1 в виде диаграммы прецедентов в нотации языка UML.
Ты m Leoder
Initiate UML modd
• mdudi»
Tejm Member
к-
■include*
Initiale project
Prepare Workbench
■ indudi
Rool Project
-indude-
initiate the ЙШ Sprint
■indude*
Assign Turn Members
Actualize Sprint
¡issigned artifacts are pfoces&ed № build a solubon
-mdude-
Update UML Model
■ indude-
Initiate Sprint
■ include-
Approve Solution
Approved solutions are mccrpcraied n ttie Model as lb updates
Cfoso project Assign Artifactj
The leader selects artifacts to b practised from ttie ljml model
Рисунок 1. Диаграмма прецедентов проектирования программной продукции Показанная модель ориентирована на обеспечение принципов адаптивного (agile) проектирования с использованием языка UML [2]. Основными прецедентами (use case) [3] являются Initiate Sprint (инициирование спринта) и Actualize Sprint (исполнение спринта), реализуемые, соответственно, руководителем проектирования (Team Leader) и участником команды исполнителей (Team Member). Спринтом считается элемент проекта, которому назначаются исходные данные
(прецедент Assign Artifacts) и в ходе выполнения которого вырабатываются решения по изменению имеющихся и созданию новых рабочих материалов (артефактов) проекта. В обязанности руководителя входит оценка и утверждение результатов выполнения спринтов (прецедент Approve Solution). Руководитель развивает сам или координирует развитие модели проектируемого продукта (прецедент Update UML Model).
В диаграмму также входят прецеденты, реализуемые руководителем проектирования и обеспечивающие инициирование и закрытие проекта.
Диаграмма прецедентов является обзорным документом, её детализируют и конкретизируют другие рабочие документы проектирования, среди которых центральную роль играют диаграммы классов. Диаграмма классов концептуального уровня, соответствующая рассматриваемой модели проектирования, показана на рис.2.
В соответствии с семантикой языка UML диаграмма показывает центральные структурные сущности модели: классы Sprint, Project Artifact, UML Model, Project. В диаграмме прецедентов эти сущности упомянуты как объекты, к которым применяются функции-прецеденты. В данной диаграмме для них указаны атрибуты и связи между собой и с другими классами. В частности, добавлены класс Project Prerequesites и Excerpt. Класс Excerpt представляет выборку из модели разрабатываемого продукта, представленной классом UML Model и передаваемой спринту в качестве входной информации.
Для класса Project Artifact указаны классы-потомки - классы Part of UML Model, Source Code, Bug и Test case, а для класса Sprint - классы Design, Programming, Testing и Deployment. Для этих классов атрибуты не указаны, но установленная связь наследования обязывает ввести в них все атрибуты класса Sprint: Status (состояние исполнения спринта), Time Constraints (ограничения по срокам исполнения).
Таким образом, диаграмма классов не только служит фиксации решений, уже принятых в ходе проектирования, но и служит спецификацией для принятия дальнейших решений. В частности, связи-ассоциации Selection, Initiation, Termination, is Submitted и другие, установленные в диаграмме, являются, фактически, указанием на необходимость разработки диаграмм последовательностей (взаимодействия классов) и соответствующих программ-методов в определении классов, то есть подводят к созданию новых спринтов и определяют их цели, содержание и состав исходных материалов.
Рассматриваемая модель реализуется многими системами управления проектированием, специализированными для ведения программистских проектов и доступными в сети Интернет, такими как WEB-приложение Redmine [4], система Bugzilla [5], сетевой сервис Agilefant [6] и др. Для управления программистскими проектами пригодны некоторые CRM-системы, например, Zoho CRM [7].
Project Prerequisites
^Customer's requisitei: string iE^Tim? Constraints. Date EH Price : dedmal_
- profit Prerequisites
T,
I ri it i at ion
J В Project
Term matten
initiâtes - Closes l
Name : string
d&tt,."
■ prûje< belongs to
7 1
Я IP ML Model
enters as update
Select юл
- is pjrt of UML Model Indusion
H pointed to
.__
----- Excerpt
- selects
Inititmn -¡s inp^ artifact
if submitted
_
mitâtes
- cherts f Team Leader
Sprint
fr
Ëgg Sti3tüi kj.
È51 Time Constraints : dateTnrie
Approval
J
' :
Is elaborated
1 -■* V
3<b
Project Artifact
Г А A A
Design
Programming
Testing
Deploiment
1.,* Assigncment Team Member
Part of U ML Model
Source Code
3 Blj9
Test cjic
Рисунок 2. Диаграмма концептуальная классов проектирования программной продукции
Во всех этих средствах пользователь непосредственно работает с информацией административного плана: именами проектов, этапов, отдельных заданий, сроками их назначения и исполнения, именами исполнителей. Для обращения к материалам разработки: текстам
требований, моделей, исходным текстам программ, планам и протоколам их тестирования пользователь вынужден, как правило, вызывать программные продукты или сервисы за пределами системы управления проектированием.
Определённое исключение составляют подсистемы поддержки коллективной работы в IDE (интегрированных средах проектирования), например, в Сервере TFS [8], в котором, наряду с объектами, представляющими единицы работ (информация административного плана), вопросами разработчиков, ответами на них, непосредственно доступны фрагменты текстов программ на исходных языках. Но модели, предшествующие составлению исходного текста на языке программирования, в этой IDE не доступны, за исключением моделей реляционных структур баз данных.
Таким образом, остаётся не реализованным в полной мере со стороны имеющихся компьютерных средств показанный выше потенциал UML-диаграмм как основания для принятия административных решений по декомпозиции проектных работ, инициировании спринтов.
Для преодоления разрыва между процессом административного планирования и содержательного проектирования программных продуктов предлагается совмещать эти процессы в среде UML, в рамках комплекса UML-диаграмм. Пример такого совмещения рассмотрен далее.
Предполагается, что диаграмма классов, показанная на рис.2, относится к некоторому промежуточному состоянию проектирования некоторой программы, является результатом некоторого спринта и представлена руководителю проекта для принятия дальнейших решений. На рис.3 ввиду ограниченности его пространства воспроизведены только классы Project Prerequisites, Project, Sprint и Project Artifact c их связями между собой и с персоналом (классы Team Leader и Team Member). Они располагаются в правой части рис.3.
Руководитель проекта имеет техническую возможность добавлять к диаграмме объекты - экземпляры классов Sprint, Project Artifact и Team Member и связывать их между собой и классами исходной диаграммы. Рис.3 в целом показывает результат такого добавления.
Объект Sprint01:Sprint представляет решение руководителя проекта инициировать спринт для проработки класса Project Prerequisites, в результате которого должны быть выработаны диаграмма последовательностей для диалогового ввода данных этого класса и решение, как хранить эти данные во внешней памяти. Указанные результаты представлены артефактами SeqDiagrOl и Saving01. Здесь и далее элементы идентификатора объектов, выражающие принадлежность к соответствующим классам, опускаются.
Член команды A назначается исполнителем спринта Sprint01. Стрелка показывает, что класс Project Prerequisites как элемент актуальной диаграммы поступает на вход спринта. Этот элемент в данном случае
выступает как экземпляр класса Excerpt (показан только на рис.2).
SikAon ektotmn
£ SsqD ¡it] г 01: Project Artifaa 5 tquente D^grsm of I Prerquesrtst 1лря
1 A: Тмгп Mcmbtr
■ ■ *-. S :THIA Membet
Spri nt21 : Sprint
' DialOl : Ptoject Arlibct
' DiaHH;Ptoj«t Artifact
' С ; Тйт Member
■ 1Г S'aP'liiS-
Solution prnjHl ртаякц
^ t.
' SprinlOl: Sprint
Project Prerequisite
L
Г
' SavingOl : Piojrct Artifact
i^Cusujmsr^rtquisitis .itring ^Tlms Conitf jimti: Date ; ^Prta: dedmal_
t SptinGZ; Sprint
1
projert Prerequisites
5 DfutKin of Prerequisites Swig
1 SavjngOE : Project Artifact
Ч У
' 5p-ii.4l.25: Sprint
■ nit its
□
^LogidOl: Project Artifact |
fnitiilioii
Terminal ion
Pwj«i
QNaira-itring |
J
Sainton of project saving
1 ■ Sprint
-Cli,ts 'ъъяп
1 Iniliitron
■ innatiS
. j Time iimlrjinti: daSTirr.i
T
Team Leader
facki fj elaborated
project Matt Approval Project Anlfuct
AHigrwmenl
Team Member
Рисунок 3. Модель планирования на основе диаграммы классов Спринт Sprint22 создаётся для проработки класса Project. Ожидаемый артефакт Saving02 должен содержать решение, как сохранять данные этого класса. Предполагается, что при выработке этого решения должны быть учтены решения артефакта SavingOl. Исполнителем спринта Sprint22 назначается тот же член команды A. Он займётся данным спринтом, когда завершит работу над спринтом SprintOl. Таким образом задаётся вынужденная упорядоченность выполнения спринтов во времени.
Спринт Sprint21 в качестве исходного материала получает связи Initiation и Termination между классами Team Leader и Project. Ожидаемый результат - диаграммы последовательностей, определяющие диалог пользователя с разрабатываемой программой по формированию
экземпляров класса Project.
Спринт Sprint23 запланирован как использующий результаты остальных спринтов для выработки артефакта Logic01 - логики, связанной с классом Project. Но этому спринту ещё не назначен исполнитель. Из диаграммы видно, что им может стать член команды C или член команды A, уже освобождающийся к возможному началу исполнения спринта Sprint23.
Обобщая рассмотренный пример, можно констатировать, что руководителю проекта предлагается работать в двух планах: плане модели коллектива исполнителей (административной модели) и плане модели разрабатываемого программного продукта. Обе модели согласованно изменяются во времени. Утверждённые артефакты проектирования, если они выражаются на языке UML, вливаются в модель продукта. Чтобы избежать загромождения моделей неактуальными версиями, можно установить правило, по которому автоматически показываются только актуальные элементы, а их предшественники или отбракованные варианты вызываются по ссылкам.
Объекты административной модели на Рис.3 для простоты показаны без атрибутов. Очевидно, что им должны приписываться хотя бы атрибуты сроков выполнения, директивных и фактических. На основе этих атрибутов нетрудно организовать расчёт времени выполнения проекта на имеющуюся глубину планирования в целом и по ветвям, а также вырабатывать всевозможную сводную информацию.
Для совмещения обоих планов требуется незначительное профилирование языка UML, в частности определение специальных стереотипов и правил их связывания.
Предлагаемый порядок проектирования должен особенно подходить руководителям небольших коллективов, которые сочетают административную деятельность с содержательным развитием проектов. Он органически обеспечивает соблюдение принципов адаптивного проектирования в части глубокой, в меру надобности, декомпозиции проектов и оперативного порождения соответствующих процессов исполнения. Он также соответствует принципам экстремального программирования, обеспечивая единое информационное пространство планирования.
В заключение следует отметить, что рассмотренная диаграмма классов, играет двоякую роль: конкретной модели проектирования программных продуктов и модели произвольного программного проекта, развёртываемого согласно этой конкретной модели. При этом рис.3 фактически показывает возможность самоприменения приведённой конкретной модели. Режим самоприменения может оказаться особо полезным для "систем-систем", обеспечивая упорядоченное развитие их технологических компонентов.
Литература
1. Michael Vierhauser, Rick Rabiser, Paul Grunbacher, Christian Danner, Stefan Wallner. «Evolving systems of systems: industrial challenges and research perspectives» // Proceedings of the First International Workshop on Software Engineering for Systems-of-Systems / Montpellier, France — July 01 - 01, 2013 URL: http://dl.acm.org/
2. Гради Буч, Джеймс Рамбо, Ивар Якобсон. Введение в UML от создателей языка. - М.: «ДМК Пресс», 2012. - 493с.
3. Крэг Ларман. Применение UML и шаблонов проектирования. - М.: «Издательский дом «Вильямс», 2002. - 619с.
4. Redmine. URL: http://www.redmine.org
5. Bugzilla. URL: http://www.bugzilla.org/
6. Agilefant. URL: http://agilefant.com/
7. Zoho CRM. URL: http://agilefant.com/
8. Microsoft Developer Network. MSDN Library Team Foundation Server. URL: http://msdn.microsoft.com/en-us/library/aa730884(V=vs.80).aspx
