Для чего нужен uml
Как язык UML помогает организовать работу IT-проекта
Авторизуйтесь
Как язык UML помогает организовать работу IT-проекта
эксперт по системному бизнес-анализу Luxoft Training; евангелист языка UML
«UML устарел»… «UML умер»… Статьи с вариациями на эту тему то и дело всплывают в Сети. Используя эту нотацию для построения моделей уже более 14 лет, я в корне не согласен с такой позицией. Наоборот, в противовес скептикам скажу, что язык жив и, вероятно, ещё долго будет жить. В этом материале постараюсь раскрыть, почему я так думаю.
Unified Modeling Language (UML) был разработан тремя известными сотрудниками Rational Software в начале 90-х и принят в качестве стандарта Object Management Group в 1997 году. Потребность в создании подобного языка ощущалась к тому времени довольно остро, так как программное обеспечение становилось всё сложнее. Обсуждать, описывать и продумывать его работу было всё труднее.
Понимание важности стандартных нотаций для построения моделей пришло ко мне лет 20 назад. На тот момент, еще будучи разработчиком, я искал способ донести до руководства компании предложения по улучшению бизнес-процессов. Презентовать свои идеи я решил в виде диаграмм, а поскольку на тот момент не пользовался никакими нотациями, просто изобразил всё в виде аккуратных кружочков, прямоугольников и треугольников, соединённых стрелками.
На подготовку этих диаграмм у меня ушло довольно много энергии и времени, но презентация вместо ожидаемого триумфа принесла лёгкое разочарование. Руководитель компании, просмотрев диаграммы и прослушав мою презентацию, сказал, что видит в моих предложениях рациональное зерно, но совершенно не может ухватить детали. Откровенно говоря, я списал это на счёт самого руководителя, ведь в правильности диаграмм и прорывном характере идей я был уверен. Поэтому записи свои сохранил – до лучших времен.
Спустя год, решив воплотить в жизнь одну из этих идей, я оказался ровно в таком же положении, что и руководитель компании во время моей презентации. В диаграммах явно чувствовалось рациональное зерно, но им не хватало понятной системы, а назначение «кружков», «прямоугольников» и «треугольников» к этому времени уже забылось. Именно в тот момент я и решил обратить внимание на стандартные нотации.
Когда же через несколько лет в моё поле зрения попали UML-диаграммы, они привлекли меня своей простой, но выразительной формой, хоть мне и не сразу удалось в них разобраться.
Для кого подходит UML
Как только начинаются споры о применимости UML в современных условиях, на ум приходят две известные шутки. Первая говорит о том, что в интернете на любой вопрос можно найти любой ответ. И не только в интернете, должен заметить. Книги, статьи, выступления на конференциях, мнения коллег и обсуждения на форумах демонстрируют полный спектр эмоций – от полного отрицания до фанатичной приверженности. Так кому же верить?
И тут всплывает в памяти другой диалог: «- Не люблю я котов… — Да вы их просто готовить не умеете!». На мой взгляд, секрет полезности (или неполезности) UML кроется именно в этом – в умении правильно «приготовить» диаграммы. Если человек говорит, что какая-то нотация не работает, возможно, он просто не потрудился разобраться в ней. Может быть, эта нотация не соответствует его стилю мышления. Так и с UML: одни специалисты пользуются и получают от этого удовольствие, другие нет. Это просто выбор каждого.
В нашем мире не существует абсолютных истин. В IT-сфере тем более не стоит искать правила, которые были бы одинаково применимы и эффективны для любого проекта или ситуации. Каждый проект, команда, заказчик выбирают для себя то, что удобно им. Поэтому всё, что говорится о UML или других нотациях, – всегда частное мнение.
К тому же для разных ролей в проектной команде UML имеет различную степень применимости. Например, UML отлично справляется с описанием технической стороны системы: архитектуры, алгоритмов, протоколов обмена, процессов и пр. Но руководителям проекта, техническим писателям и дизайнерам интерфейсов пользователя он, скорее всего, не пригодится.
Казалось бы, разработчики должны знать и использовать UML лучше и чаще всех. Но нет, довольно часто они говорят, что проще сразу начать писать код, не тратя время на рисование диаграмм. И в простых случаях такой подход действительно оказывается более выгодным.
Но при разработке больших систем с разветвлённой архитектурой и сложными структурами данных лучше сначала подумать, а потом уже кодить. Код, написанный без глубокого понимания задачи, потом будет много раз переделываться. В ходе переделок меняется логика функционирования системы, её структура становится более запутанной. Вносить очередные изменения становится всё сложнее и сложнее.
А полезен ли UML для аналитиков? Вполне! Например, системные аналитики, будучи ближе к технической реализации системы, могут использовать UML для моделирования структур данных или взаимосвязей между компонентами системы. Хотя для системных аналитиков придуманы и другие нотации, например, SysML, знание UML представляется для них ценным навыком.
Для бизнес-аналитиков применимость UML кажется заметно меньшей. Но опять-таки, это зависит от ситуации. Мне, например, UML помогает анализировать предметную область, продумывать некоторые задачи, описывать требования, проектировать структуры данных.
Чем может помочь UML
Во-первых, UML – это формальный язык, который подчиняется чётко определенным правилам. Каждая его диаграмма, каждый элемент или связь на диаграмме подчинены определённой логике, несут определённый смысл. А это означает, что следование таким правилам дисциплинирует сознание автора модели, направляет процесс его мышления по определённому руслу.
Здесь можно было бы посетовать на ограничение творческого самовыражения автора модели. Но разве это является нашей целью в ходе проекта? Пожалуй, гораздо важнее для нас донести свои идеи, открытия и решения до коллег. Донести так, чтобы не пришлось потом долго отвечать на дополнительные вопросы, а реализация в итоге соответствовала задумке.
Именно формализация позволяет создавать диаграммы, понятные другим людям (тоже знающим UML, разумеется) и не теряющие своей понятности с течением времени (как это было с моими доморощенными диаграммами годы назад).
Во-вторых, стандарт UML содержит почти полтора десятка диаграмм, что позволяет покрыть потребности разных ролей в проекте. Благодаря UML можно создать информационный фундамент для описания различных аспектов системы – начиная с верхнеуровневых требований до решений, непосредственно реализованных в коде.
К примеру, диаграмма классов (class diagram) помогает лучше понять, как распределить обязанности между разными частями системы. Причем речь идёт не только о тех классах, которые разработчик описывает в исходном коде программы. Через классы можно выразить даже понятия предметной области, что позволит лучше понять потребности заказчика и нюансы его работы.
Давайте в качестве иллюстрации попробуем описать часть системы для проведения онлайн-конференций. Судя по диаграмме ниже, встречу может создать только зарегистрированный пользователь, а участвовать в ней могут пользователи двух типов: простые участники и один или несколько ведущих (хостов). Если встреча является повторяющейся, тогда для неё задаются параметры периодичности.
На диаграмме присутствуют и английские названия, и русские, типы данных у одного класса выглядят стандартными, а у другого названы в свободной форме, у пары классов показаны атрибуты, у одного – только операции. Не очень аккуратно, да? Но если знакомый разработчик скажет вам, что это не классы, не верьте.
Это пример диаграммы концептуальных классов, с помощью которой мы можем описать предметную область на очень высоком уровне. Разработчики, конечно же, будут использовать другие классы, таблицы базы данных тоже будут выглядеть по-другому, но эта концептуальная диаграмма позволит аналитику и лучше разобраться в проблеме, и чётче описать требования к ее решению.
Диаграмма деятельности (activity diagram) описывает процесс, в котором одна операция следует за другой, подчиняясь определённой логике. Она позволяет изобразить алгоритмы принятия решений, бизнес-процессы или выполнение пользователями тех или иных действий в системе. Как правило, диаграммы этого типа бывают понятны даже далёким от IT-сферы людям.
Диаграмма вариантов использования (use case diagram) описывает сервисы, предоставляемые системой внешнему миру, и действующих лиц, которые имеют доступ к этим сервисам. Эта диаграмма бывает полезна в самом начале проекта, когда еще нет чёткого представления о том, как именно должна работать разрабатываемая система. Такое понимание как раз и формируется в ходе построения, обдумывания и обсуждения диаграммы.
Ещё одним важным результатом являются вопросы, которые неминуемо возникают у аналитика при построении диаграммы вариантов использования. Эти вопросы позволяют глубже изучить предметную область и потребности заказчика, уточнить требования к системе и в результате предложить наиболее подходящее для заказчика решение.
Эта статья не предполагает знакомство с каждым типом диаграмм UML, приведённые примеры стоит рассматривать лишь как очень поверхностную иллюстрацию возможностей UML и его пользы на различных этапах проекта.
Например, диаграмма состояний (state machine diagram) позволяет описать жизненный цикл объекта в виде графа, вершинами которого являются состояния, а дугами – события или действия, ведущие к смене состояния.
В-третьих, UML – это наглядный способ для поддержки процесса мышления. Он позволяет разбить задачу на части, продумать их по отдельности, а потом склеить в комплексное финальное решение.
Когда мы описываем что-либо с помощью текста, информация воспринимается последовательно. И не важно, о каком тексте идет речь: это может быть и текст требований, написанный на естественном (человеческом) языке, и исходный текст программы, написанный на алгоритмическом языке. В любом случае, чтобы понять смысл текста, мы должны читать его символ за символом, слово за словом, строку за строкой. Часть информации, прочитанная раньше, может забыться или исказиться. Плюс к этому, чтобы найти какой-то определённый фрагмент, приходится затрачивать время на повторный просмотр текста.
Но если информацию представить в виде диаграммы, вся картина будет видна полностью (разумеется, если диаграмма построена правильно и не перегружена деталями). В таком случае сразу видны все элементы и связи между ними, а взгляд без труда находит нужный фрагмент диаграммы. Такую диаграмму можно использовать в качестве «карты», помогающей ориентироваться в большом количестве проектных артефактов.
Какие подводные камни могут омрачить впечатление об UML
UML изучают в институтах, но довольно часто это процесс не привязывают к жизни, не подкрепляют реальными примерами. И вместо того, чтобы стать для IT-специалиста родным языком, UML начинает казаться языком мертвым, похожим на латынь.
Главная сложность в освоении UML состоит в том, что для построения диаграмм требуется определенный стиль мышления. Например, классы – это достаточно абстрактная концепция. Если приучить себя мыслить классами, видеть примеры во внешних предметах и событиях, построение диаграммы не вызовет больших затруднений. Если же человек не обладает стилем мышления, созвучным логике UML, моделирование будет казаться занятием непонятным, трудным и не очень полезным.
Критики, говоря о недостатках UML, упоминают:
Получается, что трудности в работе с UML – штука очень субъективная. Главное, что все эти трудности преодолимы (в основном) и управляемы. Если UML в целом нравится и человеку кажется, что он может применить его в своей практике, аргументы «за» найдутся легко. В противоположной ситуации доводы «против» подобрать также не составит особого труда.
Я не считаю, что нужно бороться за повсеместное внедрение UML, чтобы все айтишники его знали на 100%. На мой взгляд, нужно просто использовать UML разумно и рационально в тех случаях, когда он уместен.
Неочевидные случаи: опыт применения UML в Agile-проекте
Этот случай в моей практике был уникальным, но достаточно показательным. Он произошел лет 10 тому назад, когда UML уже стал для меня привычным инструментом анализа и продумывания решений.
Работая коучем с начинающими Agile-командами, я получил от одной из команд запрос на помощь в планировании. Суть проблемы состояла в том, что коллеги разработали 130 user stories, но описали их в виде простого линейного списка. Поэтому при планировании каждого спринта им приходилось весь этот список просматривать, что c каждым разом становилось всё труднее и труднее.
Поскольку в суть проекта я глубоко не вникал, пришлось попросить команду немного рассказать о том, какая система разрабатывается и для чего. Пока коллеги рассказывали, я рисовал на доске картинки – просто чтобы не упустить ничего важного.
Сначала это были абстрактные рисунки, но как только идея системы стала проясняться, я совершенно автоматически перешел к рисованию вариантов использования (use case diagram). Вот тут-то я впервые услышал вопрос «А что, UML ещё жив?». Оказалось, что не только жив, но и достаточно бодр.
Как правило, в технологии Agile-разработки не находится места долгим медитациям над UML-диаграммами, поэтому коллеги сначала приняли мои художества как кощунство и приверженность устаревшим технологиям. Но всё оказалось проще.
Благодаря диаграмме вариантов использования мы выделили главных действующих лиц, затем определили основные функциональные блоки и разбили их на фичи. А потом всё это обозвали эпиками и организовали в виде дерева. После этого осталось лишь распределить все user stories по узлам этого дерева (т.е. по эпикам). И чудо свершилось – вместо громоздкого и неудобного линейного списка мы получили удобную и логичную структуру, работать с которой стало несоизмеримо проще.
Кстати, как только мы распределили user stories по дереву, стало видно, что одна из трёх подсистем уже практически готова – оставалось доделать лишь одну стори. Раньше об этом никто и не подозревал, так как структура требований отсутствовала и, как следствие, было трудно понять, к чему относится каждая user story. Поэтому команда и «буксовала», не понимая, куда двигаться дальше.
Ту диаграмму вариантов использования я безжалостно с доски стёр – свою задачу она уже выполнила, сохранять её в документах проекта просто не было смысла.
Таким образом, UML нужен не только для того, чтобы нарисовать красивую диаграмму и внести её в какой-то документ или опубликовать на сайте. UML является отличным инструментом для продумывания технических проблем и обсуждения их с коллегами. Диаграммы UML позволяют увидеть картину в целом, структурировать её, найти недостающие звенья, сформулировать вопросы заказчику или разработчикам. А потом обогатить диаграммы полученными ответами.
Простое руководство по UML-диаграммам и моделированию баз данных
Унифицированный язык моделирования (UML) играет важную роль в разработке программного обеспечения, а также в системах, не связанных с ИТ, во многих отраслях, поскольку он дает возможность визуально показать поведение и структуру системы или процесса. UML помогает продемонстрировать возможные ошибки в структурах приложений, поведении системы и других бизнес-процессах.
Почему UML?
Впервые UML появился еще в 1990-х годах благодаря трем инженерам-программистам — Грэди Бучу, Ивару Джекобсону и Джеймсу — поскольку они хотели разработать менее хаотичный способ представления разработки все более сложного программного обеспечения, в то же время отделяя методологию от самого процесса. Сегодня UML по-прежнему является стандартной практической нотацией для разработчиков, а также для руководителей проектов, владельцев бизнеса, технических предпринимателей и специалистов из разных отраслей.
Каковы преимущества UML?
Типы диаграмм UML
Существует два основных типа диаграмм UML: структурные диаграммы и поведенческие диаграммы (а внутри этих категорий имеется много других). Эти варианты существуют для представления многочисленных типов сценариев и диаграмм, которые используют разные типы людей.
От заказчиков и руководителей проектов до технических писателей, конструкторов, аналитиков, программистов и тестеров — представители каждой роли будут использовать конкретную диаграмму в соответствии со своими потребностями. Это означает, что каждый шаблон требует различного фокуса и уровня детализации. Цель UML — визуально представить диаграммы, которые легко понять каждому.
Пример базовой диаграммы последовательности UML. Шаблон доступен длязагрузки
Давайте посмотрим внимательнее:
Структурные диаграммы
Структурные диаграммы представляют статическую структуру программного обеспечения или системы, они также показывают различные уровни абстракции и реализации. Они используются, чтобы помочь визуализировать различные структуры, составляющие систему, например, базу данных или приложение. Они показывают иерархию компонентов или модулей и то, как они связаны и взаимодействуют между собой. Эти инструменты обеспечивают руководство работы и гарантируют, что все части системы функционируют так, как задумано по отношению ко всем остальным частям.
Поведенческие диаграммы
Основное внимание здесь уделяется динамическим аспектам системы программного обеспечения или процесса. Эти диаграммы показывают функциональные возможности системы и демонстрируют, что должно происходить в моделируемой системе.
Давайте подробнее рассмотрим различные типы диаграмм UML, которые относятся к каждой категории:
1. Структурные диаграммы UML
2. Поведенческие диаграммы UML
Модели базы данных
UML также завоевывает популярность как нотация для моделирования баз данных. Эти модели являются отличным визуальным инструментом для проведения мозгового штурма, создания диаграмм в свободной форме и совместной работы над идеями.
Хотя UML не имеет спецификаций для моделирования данных, он может быть полезным инструментом для построения диаграмм, тем более что данные из баз данных могут использоваться в объектно-ориентированном программировании.
Давайте рассмотрим различные типы моделей баз данных, которые вы можете создать:
Упрощение с помощью программного обеспечения
Создаете ли вы модели баз данных или диаграммы UML, использование программных инструментов упрощает и улучшает этот процесс. Обязательно выберите инструменты, которые позволят вам:
При разработке программного обеспечения и непрограммируемых систем во многих отраслях использование визуальных UML-диаграмм может играть важную роль в построении поведенческих процессов и структур. Узнайте больше о создании диаграмм UML с помощью программного обеспечения при помощи пошаговой инструкции: руководства.
Сведения об авторе
UML-диаграммы для моделирования процессов и архитектуры проекта
Сегодня UML используется в создании объектно-ориентированного программного обеспечения, поскольку этот язык доказал свои важность и эффективность. Давайте разбираться, что такое UML и как его применять.
Что такое UML-диаграммы?
Аббревиатура UML расшифровывается как Unified Modeling Language, дословно переводится как «унифицированный язык моделирования». По сути, это язык моделирования, который позволяет создавать структуры программных систем.
UML состоит из графических обозначений, диаграмм, которые помогают создать дизайн программных проектов. С помощью UML-диаграмм проектные группы коммуницируют между собой, составляют и проверяют архитектурный дизайн ПО.
Работа с UML-диаграммами — важная часть проекта, так как на этом этапе продумывается его структура. Проектирование помогает в дальнейшем не запутаться в коде, снизить количество ошибок и упростить работу.
UML имеет единый синтаксис, поэтому является международным языком. Диаграммы будут понятны любому человеку, знакомому с ним. Также стоит отметить, что UML используется для разработки широкого спектра программ от информационных систем масштаба предприятия до распределенных веб-приложений.
Цель существования UML
UML призван дать стандартную нотацию, используемую всеми объектно-ориентированными методами. Кроме того, UML позволяет выбирать и внедрять наработки нотаций-предшественников. Так как UML создан для широкого спектра программ, с его помощью можно конструировать различные системы.
Выделим основные цели дизайна UML:
Функции UML
UML обладает рядом полезных функций:
Истоки возникновения UML
До возникновения UML существовали различные разработки, которые имели успех в мире программирования:
В 1994 году Джим Рамбо, который работал в General Electric, ушел из компании и объединился с Грэди Бучем из Rational Corp., чтобы, используя наработки обоих, создать единый унифицированный метод.
К 1995 году к Бучу и Рамбо присоединился Ивар Якобсон, создатель OOSE. Он принес с собой концепцию «прецедентов», которая также стала частью нового унифицированного метода. Сегодня он называется Unified Modeling Language или UML.
В скором времени крупные компании, среди которых были Microsoft, Oracle и IBM, стали использовать UML как один из основных инструментов, так как он способствовал развитию бизнеса. Компании инвестировали в развитие UML, пока он не сформировался в язык моделирования.
В 1999 году был опубликован «Справочник пользователя унифицированного языка моделирования», а в 2005 году — его второе издание, в котором описывалось руководство по использованию UML 2.0.
Концепции моделирования в рамках UML
В разработке систем, как правило, выделяют три основных модели: функциональная, объектная и динамическая.
Чтобы описать эти системные модели, используются два типа схем — структурные и поведенческие.
Объектно-ориентированные концепции в UML
Чтобы представить предметы окружающей нас действительности, в UML используются объекты. С их помощью можно моделировать создаваемую систему, применяя терминологию соответствующей сферы, а также разбивать сложные системы на небольшие части и выстраивать схему блок за блоком. Следующие концепции объектно-ориентированного метода считаются фундаментальными:
Нотация UML для описания логики проекта
UML, как и другие языки, обладает собственными правилами оформления моделей и синтаксиса. Графическая нотация UML помогает в визуализации системы, объединении всех компонентов в единую структуру, уточнении и улучшении модели в процессе работы.
Существует четыре основных типа элементов графической нотации UML:
Нотация UML фактически является отраслевым стандартом в области разработки ПО, IT-инфраструктуры и бизнес-систем.
Программы для создания UML-диаграмм
Существует множество хороших сервисов, которые позволяют создавать UML-диаграммы. Выбрать лучшие достаточно сложно, поскольку их огромное количество.
Вот несколько, которые наиболее популярны:
Diagrams.net
Одним из наиболее удобных и популярных ресурсов является Diagrams.net. Преимущество приложения заключается в том, что оно бесплатное и доступно всем желающим. Более того, присутствует интерфейс на русском языке. В нем можно моделировать диаграммы рабочих процессов, BPM, организационные, сетевые диаграммы.
Сервис отличается широким функционалом и большим набором инструментов, с помощью которых создаются организационные диаграммы, блок-схемы, сетевые диаграммы и другое.
Для приложения доступны различные форматы: JPG, PNG, SVG, PDF, HTML, XML, возможен импорт в VSDX.
Плюсы и минусы UML-проектирования
Как и любой другой язык, UML обладает своими преимуществами и недостатками. Чтобы объективно оценить пользу UML, разберем его сильные и слабые стороны.
Виды UML-диаграмм
Существует два вида UML-диаграмм — структурные диаграммы и диаграммы поведения. 
Структурными диаграммами представлена статическая часть структуры системы. Также могут быть представлены части системы на разных уровнях абстракции и реализации и взаимосвязь этих уровней. Элементами структурной диаграммы являются значимые понятия системы. Они могут состоять из абстрактных, реальных концепций и концепций реализации.
Среди структурных диаграмм выделяют семь подтипов:
Диаграммы поведения, наоборот, отображают динамическое поведение объектов в системе. Его можно описать, как серию изменений в системе с течением времени.
Диаграммы поведения подразделяются на подтипы:
Можно выделить несколько основных и наиболее доступных типов UML-диаграмм:
Диаграмма прецедентов (Use-case diagram)
Диаграмма прецедентов описывает функциональные требования системы с точки зрения прецедентов и включает в себя два компонента — участника (Actor) и прецедент (Use case).
Участник представляет собой совокупность логически связанных ролей, которые исполняются во время взаимодействия с прецедентами или сущностями (система, подсистема или класс). Участником может быть человек, роль человека в системе или другая система, подсистема или класс.
Прецедент описывает отдельный случай поведения системы с точки зрения пользователя. Важно понимать, что с помощью прецедента отображается сам результат, а не как он достигается. Прецеденты позволяют связать наши потребности и то, как система удовлетворяет их.
Диаграмма классов (Class diagram)
Диаграммы классов используется наиболее широко и являются основой объектно-ориентированного моделирования. Класс представляет собой группу предметов, которые обладают общими атрибутами и операциями.
UML-диаграммы классов отображают как классы внутри системы, так и разные виды отношений между классами.
Выделяют три основных типа отношений в диаграммах классов:
Диаграмма деятельности (Activity diagram)
Диаграмма деятельности или активностей (Activity diagram) использует блок-схему для графического изображения динамических аспектов поведения системы.
Среди таких процессов выделяются бизнес-процессы, логика процедур и переходы от одной деятельности к другой. Таким образом, создается алгоритм действий системы или нескольких систем, взаимодействующих между собой.
UML-диаграммы деятельности позволяют моделировать как вычислительные, так и организационные процессы.
Диаграмма последовательности (Sequence Diagram)
Диаграмма последовательности создает модель взаимодействия объектов. Основой такого взаимодействия служит временная последовательность, которая дает представление о взаимодействии объектов в конкретном прецеденте.
Таким образом, диаграммы последовательности уточняют диаграммы прецедентов и отражает взаимодействие объектов в динамике, во времени. Информация представляется в виде сообщений. Также предполагается обмен сообщениями между объектами в рамках сценария, что и является взаимодействием.
Диаграмма развертывания (Deployment Diagram)
Диаграмма развертывания графически представляет инфраструктуру, на которую будет развернуто приложение, то есть моделирует физический аспект системы. Такой инфраструктурой могут быть топология системы и распределение компонентов по ее узлам, а также соединения — маршруты передачи данных между узлами.
Также с помощью диаграммы компоненты системы организовываются более рационально, что положительно влияет на производительность системы и помогает решить вспомогательные задачи.
Как правило, моделируются и конфигурации оборудования, помимо компонентов программного обеспечения, на которых они размещены.
Мы рассмотрели самые основные UML-диаграммы, но, как вы могли заметить, их намного больше. UML сильно сокращает время разработки, поскольку помогает исключить наличие возможных ошибок и спланировать дальнейшую работу. Использовать его или нет, каждый решает для себя.
Более подробную информацию по UML можно найти в этом обзорном видео:
Что такое индексы в Mysql и как их использовать для оптимизации запросов
Как исправить ошибку доступа к базе 1045 Access denied for user