VII Международная студенческая научная конференция Студенческий научный форум - 2015

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

Обычно начальный код программных систем представляется в виде текста. В большинстве случаев основная их часть создается вручную, иногда на помощь приходят автоматизированные генераторы, хотя сути это не меняет: для того, чтобы разобраться в коде, его нужно будет, по крайней мере, прочесть, что является не такой уж простой задачей. Для того, чтобы немного разобраться в масштабах проблемы, приведем наглядный пример. Представим, что перед некоторым разработчиком программного обеспечения стоит цель проанализировать код программной системы, объем которой составляет миллион строк (примерный объем современных крупным проектов). Допустим, одну строку специалист прочитает за три секунды, а работать он будет обычные восемь часов в сутки. Выполнив несложные арифметические расчеты, мы выясним, что всего программисту придется затратить на эту работу свыше ста дней, что в переводе на пятидневную рабочую неделю составляет полгода на рабочем месте. Кроме того, в коде ведь еще нужно разобраться, мало просто его прочесть. Зачастую даже опытный специалист может довольно долго разбираться в коде, написанным, например, начинающим программистом. Поэтому и совершенно нет смысла, да и возможности, подсчитывать, сколько времени займут все эти операции. Ведь читать код – это не одно и то же, что читать книгу, программный код не похож ни на любовный роман, ни на занимательный детектив.

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

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

И тут мы сталкиваемся сразу с несколькими проблемами:

• прогрессивные инструментальные средства отчасти могут применяться, как правило, к довольно узким задачам: проектированию графического интерфейса, формированию структуры БД;

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

• UML нередко критикуют за его громоздкость и трудность в понимании. Особенно эти претензии можно предъявить к ранним поколениям UML

Однако, применение UML не ограничивается моделированием программного обеспечения. Его помимо прочего применяют для моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

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

Поэтому, несмотря на перечисленные недостатки UML, у него имеются и множество достоинств:

• Объектно-ориентированность языка. Исходя из этого, методы описания сравнительно недалеки от современных объектно-ориентированных языков;

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

• При наглядном и правильном оформлении диаграммы становятся просты и понятны обывателю;

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

• UML получил обширное распространение и постоянно развивается

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

Перейдем от формальностей к конкретным примерам. Наиболее удачным стартом в процессе создания программного обеспечения могут стать диаграммы UML. Они довольно просты и «пластичны». С их помощью команда разработчиков с самого начала разработки может обсуждать все детали и нюансы проекта. Но только начальный этап подготовки завершен и все аспекты согласованны, в этот момент и начинаются сложности. В самом начале разработки очень сложно учесть абсолютно все детали и требования. Поэтому, чем дальше идет время, тем больше проект будет претерпевать изменения и расходится со своим первоначальным видом, а UML диаграммы перестают быть актуальными и их нужно переделывать (но этим уже никто не занимается). В конце концов, остается единственный документ, описывающий систему полностью – это сам программный код - вещь трудночитаемая. А что, если на поздних этапах разработки подключится новый специалист? Ему будет весьма проблематично понять принцип работы системы. Но это еще не все. Что, если специалист, ведущий разработку с самого начала, который держит в голове большую часть идеи программной реализации, покинет проект по каким-либо причинам? Тогда разработка системы может растянуться на весьма продолжительной срок, а то и вовсе зайдет в тупик.

Есть еще один архиважный в процессе разработки программных продуктов момент: сбор требований. Как говорит Брукс, "наиболее тяжелой частью создания системы программного обеспечения является решение о том, что вы собираетесь создавать. Никакая другая часть работы не может настолько навредить созданию системы, как эта, в том случае, если она неверна. Любую другую часть легче исправить, нежели эту." Так что для создания адекватной системы ПО необходима технология, которая может определить и создать систему, которая будет отвечать поставленным требованиям. Если такая система есть, то уже можно говорить о высоком опыте разработчиков, они точно знают что делают и их проект делает шаги к успеху.

Так как этапы анализа и проектирования независимо от модели ЖЦ считаются характеризующими при построении корпоративных информационных систем, в работе представлен анализ современных методик анализа и проектирования их применимости в разных типах проектов. Значимость этого изыскания обусловлена, с одной стороны, тем, что разработчики обыкновенно регламентируют собственные средства (подходы, нотации), как универсальные, а с иной, тем, что настоящая информация по методологии применения отсутствует.

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

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

Хочется отметить, что с развитием программного обеспечения повышается и сложность его разработки. Среднестатистическому человеку процесс создания программ разного уровня порой являет собой непостижимую тайну. Заказчики программных систем обычно и являются этими «обычными» людьми. Но, чтобы они могли донести все свои требования специалистам, которые возьмутся за создание ПО, клиент и исполнитель должны уметь разговаривать на одном языке. Таким языком и является UML. Да, в нем много недостатков, его часто критикуют, но никто не ставит под сомнение важность его существования. Все, что когда-либо было создано, имеет возможность совершенствоваться, идти в ногу с прогрессом. Возможно, уже в скором времени актуальность моей статьи будет исчерпана и про недостатки визуализации программного кода уже и нечего будет сказать. Сделать языки программирования намного ближе к естественным языкам – одна из главных задач современности, и UML в какой-то степени приближает нас к осуществлению этой задачи.

1. Абрамова, О.Ф. CASE-технологии: изучать или исключить? / Абрамова О.Ф. // Alma mater (Вестник высшей школы). - 2012. - № 9. - C. 109-110.

2. IT-портал «Компьютерное обозрение» URL http:// ko.com.ua / vizualizaciya_programmnogo_koda_uvidet_nezrimoe_50261

3. Интернет энциклопедия «Википедия» URL http: // ru.wikipedia.org / wiki / UML

4. Ресурс «OMG-Portal.ru» URL http://www.omg-portal.ru/articlematerial17

5. Портал «Аналитик» URL https: // sites.google.com / site/ infoprobusinessanalysis / project-definition/uml

6. Форум «Архитектура программного обеспечения» URL http: // rsdn.ru / forum / design/618143.flat

7. Силантьев, А.В. Использование компьютерной визуализации в процессе эволюции сложных программных систем [Электронный ресурс] / Силантьев А.В., Абрамова О.Ф. // Студенческий научный форум 2014 : докл. VI междунар. студ. электрон. науч. конф., 15 февр. – 31 марта 2014 г. Направл.: Технические науки / РАЕ. - М., 2014. - C. 1-7. – Режим доступа : http://www.scienceforum.ru/2014/pdf/3774.pdf.

8. Лясин, Д.Н. Объектно-ориентированный анализ и программирование [Электронный ресурс] : учеб. пособие / Лясин Д.Н., Абрамова О.Ф.; ВПИ (филиал) ВолгГТУ // Учебные пособия : сб. Вып. 1. - 1 электрон. опт. диск (CD-ROM). - Волгоград, 2014. - 98 с

9. Матрохин, А.Е. Проблемы процесса разработки программных систем [Электронный ресурс] / Матрохин А.Е., Абрамова О.Ф. // Студенческий научный форум 2014 : докл. VI междунар. студ. электрон. науч. конф., 15 февр. – 31 марта 2014 г. Направл.: Технические науки / РАЕ. - М., 2014. - C. 1-6. – Режим доступа : http://www.scienceforum.ru/2014/pdf/3414.pdf.