Speaker A
Давай мы начнём с UML. Ну давайте. Что такое UML? Для чего он используется? Можешь рассказать?
Разбор собеседования системного аналитика: интервьюер проверяет знание UML, диаграмм use case, activity, классов, BPMN, а также REST/SOAP, баз данных и транзакций. Кандидат отвечает неуверенно.
Key Takeaways
- Отвечать на вопрос «что такое UML» нужно кратко, не перечисляя все диаграммы.
- Use case описывает взаимодействие человека (роли) с системой, а не внутреннюю бизнес-логику.
- BPMN описывает бизнес-процесс, Activity-диаграмма — взаимодействие систем.
- SOAP — протокол, REST — архитектурный стиль.
What the video covers
- Интервьюер просит кандидата объяснить, что такое UML и для чего он используется, и просит отвечать кратко.
- Обсуждаются виды диаграмм: классов, state machine, use case, activity, компонентов, sequence, BPMN.
- Разбирается различие между BPMN (бизнес-процессы) и Activity-диаграммой (взаимодействие систем).
- Объясняется диаграмма use case: актор — роль (человек или система), вариант использования — то, как актор взаимодействует с системой.
- Разграничивается вариант использования и бизнес-логика, например, проверка баланса при снятии денег.
- Обсуждаются связи наследования/обобщения и пример с налоговой льготой и льготным кредитом.
- Затрагиваются архитектурные темы: трёхуровневая архитектура, SOAP vs REST (протокол vs архитектурный стиль), структура HTTP-запроса.
- Рассматриваются базы данных, транзакции (принцип атомарности и откат) и оптимизация запросов.
- Видео демонстрирует типичные ошибки кандидата на собеседовании и способы корректного ответа.
Chapters
Full Transcript — Download SRT & Markdown
Speaker A
Ну, UML - это специальный артефакт, который используется в своей работе системный аналитик для того, чтобы а для того, чтобы сформировать требования для разработчиков. То есть иногда достаточно разработчику бляндуса UBL, чтобы понять, какой бизнес, какой процесс нужно ему, а, спроектировать. Вот. Ну, сказать про
Speaker A
Ну, UML — это специальный артефакт, который используется системным аналитиком для того, чтобы сформировать требования для разработчиков. То есть иногда разработчику достаточно увидеть UML, чтобы понять, какой бизнес, какой процесс ему нужно спроектировать. Вот. Ну, сказать про —
Speaker A
Угу. Угу. Вот. Ну, а сам UML - это унифицированный язык разметки, то есть унифицированный. Угу.
Speaker A
Смотри. А, смотри, есть как бы понятный артефакт, как ты имеешь в виду, диаграмма, правильно?
Speaker A
показать, что что мы хотим реализовать в системе, что должен выполнять пользователь. Все действия, которые в системе ему доступны, допустим. Так вот.
Speaker A
Угу. Угу. Вот. Ну, а сам UML — это унифицированный язык моделирования, то есть унифицированный. Угу.
Speaker A
ответ на вопрос. Просто виде такая, да, то есть, да, просто говори кратко, типа это используется для визуального представления различных аспектов системы. То есть кратко, ёмко, как бы, и подземко.
Speaker A
А для чего он используется? Ну, он используется для того, чтобы спроектировать, допустим, какой-то процесс. Вот, если мы, допустим, у нас есть диаграмма use case, там есть участник, актор, и варианты использования. И мы можем показать, что мы хотим реализовать в системе, что должен выполнять пользователь, все действия, которые в системе ему доступны, допустим. Так вот.
Speaker A
А давай числим все, которые ты знаешь. Диаграмма классов, state machine, а диаграмма use cas, как я говорила, вот, вот это те, с которыми я работала, ну, строила их, по крайней мере.
Speaker A
Угу. Подожди, ну, я понял. Угу. Смотри, так как там очень много видов диаграмм, то у тебя как бы просят: что такое UML? Ты можешь перечислять все диаграммы, это будет долго и не совсем ответ на вопрос. Просто вот такое, да, просто говори кратко, типа: это используется для визуального представления различных аспектов системы. То есть кратко, емко, и, в общем, подробно.
Speaker A
А, да, диаграммы. Это это отдельно, да? Угу. А там диаграмма компонентов тоже очень часто на эти рису.
Speaker A
Просто различные аспекты системы. Визуально всё ОК. Какие виды диаграмм ты знаешь? Ну, сиквенс-диаграммы мы рисуем на проекте.
Speaker A
Ну, только email. Угу. Это, кстати, очень интересный ответ. Смотри, то есть ты сюда перетянул сразу BPM. То есть это не очень хорошо в плане, когда, знаешь, одно объясняешь через другое.
Speaker A
А давай перечислим все, которые ты знаешь. Диаграмма классов, state machine, диаграмма use case — как я говорила, вот это те, с которыми я работала, ну, строила их, по крайней мере.
Speaker A
BPMN он нам показывает вот как конкретно бизнес-процесс. То есть там мы можем не рисовать фазы данных, мы можем конкретно бизнес-процессратить. Вот. А когда мы показываем активити, то там уже больше про взаимодействие систем. Хотя, блин, ладно, поняла.
Speaker A
Ердайтеграмму тоже видела. Вот. Ну, смотри, ты лучше не называй, потому что D ни в коем случае.
Speaker A
Ну, как бы кто-то говорит, что это неправильно. Почему? Если вы вписываете, получается, какой-то алгоритм или систему, там есть задача такая с шестерёнкой например.
Speaker A
А, да, диаграммы. Это отдельно, да? Угу. А там диаграмма компонентов тоже очень часто на этих рисуется.
Speaker A
понятнее визуально посмотреть. Ладно, о'кей. А давай поговорим чуть более подробно про диаграмму класс. Ладно, классов мы поставим на потом.
Speaker A
А, да, да, да. Activity-диаграмма тоже рисуется. Угу. Это Activity-диаграмма. Это аналог BPMN-диаграммы.
Speaker A
варианты использовать. Можешь какая система взаимодействующая система? Ну нам говорили, что автором может быть также и система, которая, получается, взаимодействует с разрабатываемой системой. По крайней мере, на интенсиве так говорили.
Speaker A
Ну, только не совсем. Угу. Это, кстати, очень интересный ответ. Смотри, ты сюда сразу притянул BPMN. Это не очень хорошо, когда одно объясняешь через другое.
Speaker A
взаимодействия человека с системой. То есть, ну, у системы системы не может быть вариантов взаимодействия. Она не может, допустим, там захотеть проверить свой щед, ещё что-то, потому что у него нет желания, это просто скрипт какой-то, бизнес-логика.
Speaker A
Сразу напрашивается вопрос: а чем тогда нужен BPMN, если у нас есть Activity? В чём тогда разница между ними?
Speaker A
То есть это может быть пользователь, это может быть администратор, менеджер, там типа родитель там. Ну, это всё, что угодно, в зависимости от системы. О'кей.
Speaker A
BPMN показывает нам именно бизнес-процесс. То есть там мы можем не рисовать фазы данных, мы можем конкретно прописать бизнес-процесс. Вот. А когда мы показываем Activity, там уже больше про взаимодействие систем. Хотя, блин, ладно, поняла.
Speaker A
Ну и включение. А, а ещё третье есть Аэ генерализация наверное да? Ну, вообще называется оно обобщение, но возможно, да, обобщение либо generation relationsшиip по-английски. Да. Да.
Speaker A
Ну, смотри, BPMN тоже рисуется, база данных. Вот я тоже их рисую и в Miro указываю.
Speaker A
То есть, а, с основной частью другого варианта. А так, допустим, ээ фу-фу-фу. Аэ, допустим, а для того, чтобы, а, снять снять деньги со счёта, а, необходимо проверить баланс, допустим. Так, это какая связь?
Speaker A
Ну, кто-то говорит, что это неправильно. Почему? Если вы вписываете, получается, какой-то алгоритм или систему, там есть задача такая, с шестерёнкой, например.
Speaker A
Вариант использования - это то, как человек взаимодействует с системой. Ты когда подходишь в банкоматут, у тебя есть там типа на экране, да, там проверить остаток на счёте там, да, снять деньги, сделать перевод, там ещё что-то. То есть это тот вариант
Speaker A
Угу. А ты вообще-то нотации, база данных есть, что значит неправильно? Этот элемент нотации есть, его можно и нужно использовать, чтобы показать, допустим, что в эту базу данных происходит чтение либо запись, и так далее. Для разработки намного понятнее визуально посмотреть. Ладно, ОК. А давай поговорим чуть более подробно про диаграмму классов. Ладно, классы поставим на потом.
Speaker A
деньги. Угу. Как интересно. Ну, всё равно мы же не снимемся, там не будет. Но это получается как кейс банка.
Speaker A
Давай поговорим про юз-кейс диаграммы. Какие элементы нотации ты там знаешь? Ну, есть диаграмма, там обязательно действующее лицо, то есть актор — это какой-то объект, субъект, либо, может быть, даже система, которая взаимодействует с разрабатываемой системой. Вот. Ну и также варианты использования. Можешь сказать, какая система взаимодействующая? Ну, нам говорили, что актором может быть также и система, которая взаимодействует с разрабатываемой системой. По крайней мере, на интенсиве так говорили.
Speaker A
Угу. Ну ладно, о'кей. А, допустим, я понял. А тогда расширение что? Ну, получается, расширение - это когда это когда расширяется, подождите, расширение.
Speaker A
Ну, смотри, а есть use case, артефакт, типа user story, да? Story US. Да, там действительно может быть система, например, либо пользователь системы, но на диаграмме use case там только актор — это человек. То есть получается, ты рисуешь то, какие есть варианты взаимодействия человека с системой. У системы не может быть вариантов взаимодействия. Она не может, допустим, захотеть проверить свой щед, ещё что-то, потому что у неё нет желания, это просто скрипт какой-то, бизнес-логика.
Speaker A
Так э ну, допустим, а, нам нужна нужно получить льготный кредит. А чтобы его получить, ну, нам нужно получить льготу, то есть предоставить налоговую льготу для того, чтобы получить льготный кредит. Можно такой пример?
Speaker A
Ну, понятно. Значит, либо ты можешь перепутать, либо неправильно сказали. ОК. То есть это всегда живой человек, это просто какая-то роль. Актор — это роль.
Speaker A
условия. То есть, например, вот ты заказываешь была или там где-то в Бургеркинге ещё где-то.
Speaker A
То есть это может быть пользователь, администратор, менеджер, родитель, ну, это всё, что угодно, в зависимости от системы. ОК.
Speaker A
Вот заказ дополнительного соуса, это будет связь включе включения по отношению к сделать заказ. То есть это будет общий вески сделать заказ, допустим, там, а потом будет там, ну, включить заказ. Логично, да? Там будет включение типа ой расширение. Расширение будет стать
Speaker A
Какие ещё элементы там есть? Ну, получается, эти стрелочки — это отношения, которые есть у актора с вариантом использования. Это может быть как включение, так и расширение.
Speaker A
М. Ну, если захочешь не расширить. Угу. Угу. Но он всё равно основной кейс выполнится, да? А когда когда у тебя идут включение, у тебя получается основной выполняется, и вместе с ним обязательно должны выполниться и включающие в него.
Speaker A
Ну и включение. А, а ещё третье есть, наверное, да? Ну, вообще называется оно обобщение, но возможно, да, обобщение, либо generalization relationship по-английски. Да. Да.
Speaker A
Заказ. Ну нет, не совсем. Тут тут неправильно тоже пример. Может ещё попробуешь? Так, обобщение.
Speaker A
Вот. ОК. Давай, чем они отличаются? Ну, получается, включение используется, когда один вариант использования может использовать функционал другого варианта использования. Вот. То есть с основной частью другого варианта. А так, допустим, фу-фу-фу. Допустим, для того, чтобы снять деньги со счёта, необходимо проверить баланс. Так, это какая связь?
Speaker A
Мм, ну, это просто путь. Ты флоу какой-то писал. Смотри, обобщение - это когда есть какой-то общий кейс, и мы его можем реализовать разными путями.
Speaker A
Это включение. Мм. Ха, обязательно проверять баланс, чтобы снять деньги? Ну, обязательно, чтобы на балансе были деньги. То есть нужно... Ой, мы сейчас говорим о вариантах использования.
Speaker A
значения, потому что в любом случае будет выполнен общий кейс оплаты. Как конкретно он будет реализован, да, это уже как бы там по выбору сделано.
Speaker A
Вариант использования — это то, как человек взаимодействует с системой. Когда ты подходишь к банкомату, у тебя на экране есть, да, проверить остаток на счёте, снять деньги, сделать перевод, ещё что-то. То есть это и есть вариант использования. Когда ты выбираешь «снять деньги», вводишь сумму, запрос отправляется в банк, и уже в банке бизнес-логика отрабатывает и проверяет, есть ли деньги. Это уже не вариант использования. Это уже бизнес-логика внутри варианта использования «снять деньги».
Speaker A
Sequнс - это диаграмма последовательности. А, ну и конкретно она показывает вот объекты и связи. А, ну и там есть фокусы управления, сообщения объекты а и а фреймворки.
Speaker A
Угу. Как интересно. Ну, всё равно мы же не снимем, там не будет. Но получается как кейс банка.
Speaker A
Ээ, фреймы, да, фрейм. Фреймвор это типа в программировании как там типа Reactр или что-то такое, а это фрейм.
Speaker A
Ну вот, как бы система. Ну, это даже не банк, это просто алгоритм. Это не кейс. Опять же, кейс — это взаимодействие человека с системой. Что он может в ней сделать?
Speaker A
А пунктивная э линии вертикальные - это линии жизни этого объекта. Вот. М. Ну там может быть как синхронное а сообщение, так и асинхронное передаваться между этими объектами.
Speaker A
Угу. Ну ладно, ОК. Допустим, я понял. А тогда расширение что? Ну, получается, расширение — это когда что-то расширяется, подождите, расширение.
Speaker A
А как это показано награ? Ну синхронная - это а стрелка закрашенная, а асинхронная - это когда обычная вот.
Speaker A
Ну, у меня что-то банковские примеры одни в голове. Давай любые, без разницы. Ну, допустим, нам нужно предоставить какую-то налоговую льготу и так. Хорошо.
Speaker A
это про это, да? Что забыла? Ну, какие объекты в диаграмме классов ты знаешь, можешь назвать?
Speaker A
Так, ну, допустим, нам нужно получить льготный кредит. А чтобы его получить, нам нужно получить льготу, то есть предоставить налоговую льготу, для того чтобы получить льготный кредит. Можно такой пример?
Speaker A
нотации диаграммы, то есть есть класс, есть абстрактный класс, а есть интерфейс. Ну вот, о'кей. У тебя есть класс, а в классе что есть?
Speaker A
Нет, ну, получается, это обязательно, это скорее будет включение, потому что тебе нужно получить какие-то основания для работы. То есть расширение — это то, что может выполниться, а может не выполниться, в зависимости от желания пользователя или какого-то условия. То есть, например, ты заказываешь бургер в Burger King, где-то ещё.
Speaker A
Ну и отношения между классами, соответственно есть. Ну отношения мы пока оставим. А вот давай пока поговорим, что есть у методов и атрибутов ещё.
Speaker A
ОК. А когда ты делаешь основной заказ, тебе в конце предлагают: вы можете заказать дополнительный соус.
Speaker A
Public private protected. Да слышно. Ну, можешь сказать, чем они отличаются и зачем нам ещё нужны?
Speaker A
Вот заказ дополнительного соуса — это будет связь расширения по отношению к «сделать заказ». То есть будет общий вариант «сделать заказ», а потом расширение «заказать дополнительный соус» или что-то ещё. Логично, да? Угу. То есть ты захочешь — дополнительно расширишь свой кейс вот этим.
Speaker A
Так, значит, типы связи, которые могут быть ээ между классами отношения, это ассоциация, то есть прямая линия обычная, а, рисуется тогда между прямоугольничками. А наследование - это незакрашенная стрелочка, а зависимость - это получается обычная стрелочка.
Speaker A
М. Ну, если захочешь — не расширишь. Угу. Угу. Но основной кейс всё равно выполнится, да? А когда у тебя идёт включение, основной выполняется, и вместе с ним обязательно выполняется и включаемый вариант.
Speaker A
Вот, допустим, есть какой-то а класс допустим, а какой-то ownр. И у оунера есть допустим а несколько там видов, которые включаются в этот класс.
Speaker A
Допустим там подожди, смотри, давай, а давай я тебя спрошу. А, допустим, есть такой тип связи наследования, зачем он нужен?
Speaker A
Наследование, чтобы показать, э, кто есть родительский класс, кто дочерний. Вот. А зачем это нужно? И ну и что дочерний?
Speaker A
Вот какие у него особенности по отношению к родительскому. Ну, это из принципов вытекает, на самом деле. Тем связано игра.
Speaker A
Нет, получается, мы тут можем тогда в дочернем добавлять какие-то дополнительные атрибуты, методы, а вот, но на основании, получается, родительского класса, то есть рассудлять как-то дочерней.
Speaker A
Ну, допустим. О'кей. Зачем нужна связь реализации? Но она подразумевает такое решение, а-а, реализация. Так.
Speaker A
Мм, ну, смотри, у нас есть интерфейс и есть класс. Интерфейс есть и класс. И получается, а, ну, интерфей интерфейс и объект реализуют какой-то ещё один интерфейс.
Speaker A
Нет, а, ну, вообще зачем нужен интерфейс? Интерфейс просто делает объявление каких-то методов, но без реализации этих методов. Как раз-таки, когда класс подписывается на интерфейс, он обязан внутри себя а реализовать те методы, которые были объявлены в интерфейсе. Поэтому эта связь
Speaker A
называется, ну, отдельно выделяет связь реализации, когда класс связан с интерфейсом. Угу. Окей, ладно, не будем тоже мучить.
Speaker A
А что там, что такое прототип? Надеюсь, ты повтори. Ой, прототип - это получается один из, а, способов понять, чего хочет стекхол.
Speaker A
Прототип. А прототип представляет собой, а определённую а-а проекцию того, что будет реализовано. Вот как он может понять понять то, что хочет полд в каком виде?
Speaker A
Ну можно рисовать на бумажке то, что то, что, допустим, быстренько как бы понять то, не то. А потом можно сделать а Warframe, а можно а создать какую-то то, получается, ты сама нарисуешь и сама поймёшь или как? Ну и покажу,
Speaker A
получается, стекходе то ли то ли я поняла. Значит, значит, ещё есть не только понять, а есть голосовать, да, понять и согласовать. Так точно. А, ну - это получается красивый прототип, который уже поработал дизайнер. Вот. Ну и карту диалоговых также выделяют. А
Speaker A
важный очень важный очень этап протонтипирования и вообще понять, что хочет получать конечный пользователь. Угу.
Speaker A
О'кей. А так архитектурные знания средний. Давай про архитектуру поговорим. А какие так какие виды архитектуры ты знаешь?
Speaker A
А значит, архитектурная архитекту виды архитектур - это многоуровневая архитектура. То есть там выделяют по классике.
Speaker A
Давай я сначала название просто многоуров. Клиент серверная архитектура, а управляемая событиями а бессерверная архитектура, амонолит SUA, а микросервисы.
Speaker A
Ну, бессерверную называл, не называю. Угу. А почему ты выделял отдельно клиент серверную? Ну, кто-то её уделяет тоже. Были в учебниках.
Speaker A
Ну, когда много клиентов, один сервер. Мм. А если у тебя многоуровневая система, то у тебя нету такого, что один сервер, много клиентов?
Speaker A
Ну да, пола. Хорошо. Ну вообще ну кто кто-то делит тогда frontend, backend и датабаз, и как бы пишут, что это уже считается многоуровней архитектуры.
Speaker A
Ну да, ну ладно, хорошо. Это не это есть уровень архитектура. Просто причём здесь клиент серверная? Это просто вид взаимодействия, а не отдельные архитектуры, ну, я бы сказал. Ладно.
Speaker A
О'кей. Что такое трёхуровневое? Ты уже сказал. То есть, да, это у нас есть Угу. Угу. Это есть баз данных. О'кей.
Speaker A
Что такое толстый и тонкий клиент? Ну, получается, толстый и тонкий клиент это, а, разные получается м то есть при тонком тонкий клиент - это тот, у которого а все вычисления идут куда-то на сервер. А толстый клиент - это
Speaker A
получается все логические вычисления идут на одной машине физической. Вот. То есть, допустим, толстый клиент - это какое-то программное обеспечение, которое установлено на компьютер. И не смотри, вот давай поговорим в рамках многоуровневой системы и толстого, тонкого клиента. Как это взаимосвязано?
Speaker A
Как-то получается фронт есть, да, на фронте. А давай, так скажем так, с уровнями. Как это связано с уровнями системы?
Speaker A
Многоуровнеми. Получается, что вычисления происходят на уровне, логика завязана на уровне фронта, что ли? Нет, midл. Мидл уровне.
Speaker A
Ну, смотри, смотри, когда у нас толстый клиент, вот, как ты правильно сказала, у нас получается двухуровневая система, афontт и бизнеслогик объединены, база данных разделена, то есть получается двух уровневая. Когда у нас тонкий клиент, у нас получается, ну, опять же,
Speaker A
мы вынесли бизнес-логика, у нас уже получается трёхуровневая система. Угу. Угу. Угу. Интересно. Давай поговорим про монолит. Что такое монолит?
Speaker A
Ну, монолит - это получается, когда у нас один код, а, всё вместе находится, то есть какое-то программное обеспечение, всё в одном месте сосредоточено, в том числе и код. И получается, что а монолит он, а простой в разработке, когда у нас, допустим,
Speaker A
только начинается какой-то проект, что-то что-то не планируется расширение, а его до каких-то пор проще масштабировать, э, ну и выделяют, получается, когда он ещё не на не слишком там разросся, а высокой производительности, потому что вся логика там в одном месте сидит и как
Speaker A
бы код. А вот и а ну если небольшой монолит, то его проще развернуть. Вот.
Speaker A
Ну ещё легче его тестировать, так как всё в одном месте находится. Вот. А и до определённого момента поддерживают, в том числе.
Speaker A
Угу. А микросервисная архитектура? Ну, а микросервисная архитектура, она получается хороша тем, что, а, там изначально идёт деление либо на поддомены, либо на какие-то функциональные блоки. И, а, он хорош, когда когда нужно вносить какие-то изменения, э, быстрее, тогда их можно закатить. А
Speaker A
вот разные команды занимаются разработкой. То есть, если монолить поддерживать э допустим а нужна большая какая-то команда, то тут можно поделиться, допустим, по микросервисам и заниматься одним каким-то сервисом определённым. Вот. А-а.
Speaker A
Угу. А SOA, ну, а SOA он чем хорош? Он хорош тем, что SOA в основно в основном заточен на переиспользование. То есть там есть аа сервисная шина, которая является координатором, получается, между этими, а сервисами. А вот, ну и получается тоже
Speaker A
там, э, очень изменения вносить там сложно, потому что получается, а, внесение одного изменения требует там изменения, а, в нескольких сервисах, и как бы это минус. и разные, получается, команды поддерживают. Ээ, и, допустим, какое-то элементарное изменение, если вносить в архитектуру,
Speaker A
то это может быть просто каким-то бесконечным потоком согласований и э совещаний. Вот. Ну, как бы а микросервисы-то предпочитают э дублировать. А вот если говорить про СУА, то там ну я как-то говорила, что это э стараются переиспользовать и получается,
Speaker A
так как там сервисная шина в микро. Хорошо, хорошо, хорошо, давай, всё о'кей отлично. Что такое IP?
Speaker A
IP - это Application Program Interfей, то есть это тот интерфейс, который, а, который который позволяет разным программам общаться между собой. То есть выделяют такие виды IP, как локальные, это в рамках одной системы, и удалённые- это получается э связь ну посредством
Speaker A
HTTP протокола и через сеть. Вот. А вот есть, допустим, вида открытая и закрытая мышка. Для чего они нужны? Что это такое?
Speaker A
Ну, открытый апи, он используется для того, чтобы обращаться, допустим, откры апи, открытой апи. М, ну, когда легко легко интегрироваться в сокрытом апе, не нужно, допустим, никаких разрешений получать, можно просто настроить какую-то интеграцию, проще. А зачем нужно?
Speaker A
Ну, чтобы взаимодействовать, допустим, а с, ну, чтобы взаимодействовать с каким-то другим сервисом. Ну, в закрытом Апе тоже взаимодействовало с другим сервисом, например.
Speaker A
Ну, я думаю, что в закрытом нужно получать какие-то разрешения, чему-то там соответствовать. Угу. Ну вот смотри, вообще главное отличие, что открытая а - это взаимодействие системы с, а внешней средой, то есть Угу.
Speaker A
там может любой к нам Ну то есть мы не контролируем, кто кто там подключается, мы просто предоставляем открытое апи и говорим: "Вот кто хочет, подключайтесь".
Speaker A
А закрытая IP - это внутрикорпоративная IP, когда у нас есть только внутренняя система, которая имеет доступ друг к другу. То есть извне получить доступ они никто не может.
Speaker A
Угу. Понятно. А какие виды самые распространённые опиты, знаешь, которые сейчас используются? Угу. Ну, те, которые используются, которые мы всё время повторяем, это REST app и SWAP appi. Вот.
Speaker A
А ещё А фу-фу-фу-фу-фу. М, ну это основные, наверное, на RPC. А, да, да, да, точно. А граф QL, вебсокеты, JPC. Точно, точно.
Speaker A
А вебсокеты как связаны с ОИ? Ну, э они связаны с тем, что ты в реально времени. у тебя соединение идёт и, ну, в том числе их относится к IP, то есть вебсокет применяется.
Speaker A
Смотри, вебсокеты - это вид интеграции, а не вид IP. Хорошо. Какие вид интеграции ты знаешь?
Speaker A
Интеграции, а, интеграции через а файл обмен, э, через общую базу данных и интеграция по средствам посредника брокера сообщений и, ну, через запис, да. тебе говорила через А ещё, ну, основные это эти же обмен файлами FTP, а общая база данных, а потом а и
Speaker A
через посредника брокераsкеet. Мм, да Webсокеet. Абхук же вебху, да? Современные технологии книжки старые. Ну, это на самом деле не современная технология. Они появились очень давно, где-то в семидесятых-восьмидесятых.
Speaker A
Смотри, что такое SUAP Rest, в чём их отличие. Ну, SUAP получается он протокол, а REST - это архитектурный стиль. Это как бы главное их отличие, э-э, которые определяют, ну, по определению. А потом, аэ, если сравнивать протоколы, то, э,
Speaker A
REST использует, как правило, а, HTTP протокол. Вот. А SUAP разные транспортные протоколы используют помимо HTTP. А также одной из главных получается особенностей, а что подход к разработке получается собой этой интеграции AP происходит а по-разному. То есть арест он, а а он а
Speaker A
он фокусируется на ресурсах, то есть которым вход осуществляется через URL, а у SUAP он основан на подходе удалённого вызова процедур RPC.
Speaker A
обязательно получается. Да, ну ты же до этого сказал, что есть типа REST, SUAP, а есть RPC, а есть гра QL, то есть это четыре отдельных вида AP, а ты уже говоришь, что вызов типа не Ну понятно, что там вызываются
Speaker A
какие-то Нет, то ещё даже не вызываются. Ну там не фокусируются на ресурсах. А я хотела сказать, как бы так, как в росте.
Speaker A
Ну да, да. То есть если вре для каждого отдельного сообщения заводится отдельный endpint, Угу. Угугу.
Speaker A
То в SUAP сообщения могут, ну, не могут, чаще всего приходят на один point. И вот вопрос: а как тогда SUAP понимает, как ему партить сообщения, если там на один point валится там десятки, сотни сообщений разные структуры с разными
Speaker A
данными, и он понимает, как их там разбирать, куда их перенаправлять дальше и так далее.
Speaker A
Это может про то, что каждый SUAP а API должен иметь этот описание, что должно, да, описание, что там должно быть, какие получается данные передаются, какие получаются, какие методы можно использовать.
Speaker A
Ну там, по-моему, не описываются, там просто структура сообщения описывается, да? Какая должна быть? Это же XML - это язык, это просто структурированных данных язык, да? То есть там и сообщение должно быть, список операций, и получается, а способ, котором сообще
Speaker A
Ну да, порт type- это не список операций. Ну ещё там обязательно должна быть А, ну о'кей, смотри. Ну, о'кей, у нас есть весь дверь. То есть, а где конкретно указывается или как это называется, место там, да, или как это где указывается, как
Speaker A
разбирать это сообщение, к чему оно относится, что у нас должно быть указано. Ну, в конверте, да, это про это.
Speaker A
Ну, в конверте, да, у нас есть Что у нас есть в конверте? В конверте у нас есть информация о том, какие данные, ну, у нас есть, да, конверт, а ум.
Speaker A
Вот и в хедере что у нас должно быть указано, чтобы он понимал, что он типа парси, как это парсить.
Speaker A
Угу. Ну, там какая-то кодировка должна быть, правильно? Ну там, ну, в том числе, там должна быть область видимости указана, то есть конкретно пространство, имя указано.
Speaker A
Угу. Он сразу читает headдер, видит пространство имён и понимает дальше, как разбирать это сообщение.
Speaker A
Угу. О'кей. Что такое? раз тоже начала говорить, что такое VSDL, XML, в чём их отличие.
Speaker A
В SDL - это получается описание контрактов SUAP IP. Эн описывает, как всё должно работать, а как ну как работает, наверное, SUAP сервис предоставлять информацию, методы, который будет поддерживать, э параметры которые будут передавать и типы данных.
Speaker A
Вот. А Jon Jon схему, да, рассказать? Ну да, скажи. Ну Jon ээ JSON схема, а это получается, а Jon схема - это тоже получается способ описания структуры аа и ограничений этого JС документа. А в отличие от XML, он не имеет такой чёткий стандарт и как
Speaker A
бы который который есть у у СУАПа. Вот. То есть там тоже описывается формат данных в аконтрактах, э валидацию данных JSON документов. Э также могут генерироваться какие-то примеры запросов.
Speaker A
То есть там тоже даются данные, которые как бы ну если мы смотрим HTTP запрос, то там получается, а есть заголовок, а тело, параметры передачи и ответ, получается, статус запроса, а поле с заголовками и там, если нужно, то тело есть. Вот.
Speaker A
Ну, обязательно ещё, если если тело есть, то есть дело, правильно? Поверно. О'кей. Ну, а какие методы HTTP протокола ты знаешь?
Speaker A
Методы HTTP протокола, а, это получается post patch put head collect delete option. Вот, наверное. Вот зачем нужен опion?
Speaker A
Аtionн нужен, э, для описания параметров соединения с целевыми ресурсами. То есть мы вызываем и видим, аэ, получается ну как, как что мы можем вызывать с помощью этого IP?
Speaker A
Ну, не что, а какие методы доступны поинте. А, а да, дада, да, какие методы доступны.
Speaker A
Точно. А чем отличается от пост? Ну, get отличается от пост тем, что get у нас идёт в адресной строке. Его, допустим, можно даже кшировать на стороне клиента, то есть делать закладочки. А пост у нас, получается, имеет тело и он, а, и он,
Speaker A
ну меняет получается состояние ресурсов. Вот просто для того, чтобы добавить какие-то добавить какие-то данные на ресурс. Вот.
Speaker A
Ну, в том числе можно изменить какие-то данные с помощью поста. Да, да, да, да.
Speaker A
Угу. Ты сказала, можно кэшировать get на клиенте правильно? Угу, угу, угу. Ну, потому что в адресной строке, допустим, мы же видим, куда мы обращаемся, да? В истории браузере браузер это есть.
Speaker A
Ну, он запоминает просто адрес, но ответ вопроса он хранит или нет. Ответ он не хранит.
Speaker A
Ну о'кей. А там смысл в чём? Когда говорит, что G кэшируется, кэшируется не сам запрос, кэшируется ответ на запрос.
Speaker A
То есть, допустим, ответ. Угу. То есть, смотри, у нас, допустим, есть сервер целевой, с которого мы хотим получить данные, а есть, допустим, какой-то промежуточный сервер где-то в интернете, где включено ширивание. Ну и мы, допустим, указали, что этот, а,
Speaker A
ответ, этот запрос, типа, мы, э, разрешаем кэшировать. То есть мы включили кэширование, то есть и когда мы в следующий раз, э, запросим ту же самую информацию, вот этот промежуточный сервер, он посмотрит и скажет, типа, а зачем нам идти туда в
Speaker A
конец? Это, типа, делать длинный долгий запрос. А, и если я могу прямо сейчас достать из Скэша данные и быстро тебе послать назад, это будет быстрее.
Speaker A
То есть, в принципе, если ты слышал про замедление Ютуба, точно да, российская власть как раз про это и говорит, что выходят сервера кэширования Гугла и строя и и ты типа уже обращаешься не к российским серверам, которые закшировали эти видео, а якобы
Speaker A
это типа к европейским, американским, а там типа ответ дольше из-за этого, да, поэтому и скорость падает.
Speaker A
Ну о'кей, ладно. А чем отличается от P? Т изменяет все, получается, поля, а пач меняет только часть ресурса.
Speaker A
Ну, часть отдельных получается полей какого-то ресурса. Допустим, если мы хотим поменять, допустим, что это в полях, в полях, ну, ресурсе какую-то часть ресурса. Вот.
Speaker A
правильно сказать. А какой из них когда лучше использовать? Какой из них лучше использовать? Ну, патч лучше использовать, когда нужно частично, допустим, изменить ресурс.
Speaker A
Вот. А а какой путь? Пут создать новый ресурс. Вот мы тогда, получается, данные предоставляем в тель запроса. Ну и получается так, патч является индопатентным. Вот если про это, то есть при повторном.
Speaker A
Что такое база данных? Ну база данных - это особо структурированный а набор данных, с которыми впоследствии можно работать.
Speaker A
Вот э виды сказать про баз данных или не надо? Да, это следующий вопрос. Какие ты знаешь баз данных?
Speaker A
Ну, основные виды баз данных - это, э, реляционные и нереляционные базы данных. И если мы говорим про реляционные, то там, э, то там выделяют, допустим, MySQL, а, Postgess SQL, Microsoft Service SQL, а, Microsoft Access. А если мы говорим про
Speaker A
NOSGale, то выделяют документы ориентированные, такие как Monbit. А ключ значения - это дис Amazon, база данных также есть графовый и табличные.
Speaker A
А касара вроде так. Ну и какие-то есть ещё базы данных. Э, ладно забыла. Вроде все основные временных рядов. Вот я только про их читал.
Speaker A
Ничего себе вообще временные. Ну ладно. А что такое СБД? Ну, это система управления базы данных.
Speaker A
То есть, а как мы можем манипулировать данными, которые находятся у нас СПД? То есть какое-то прикладное решение.
Speaker A
Какие основные Какие основные функции СБД ты знаешь? Ну, получается, основные функции СУД - это мм это чтение, да, крут операции. Или это не про это?
Speaker A
А чтение, редактирование, обновление. Ты мне скажи. Читать мы можем выбирать данные, а потом можем их редактировать, обновлять, удалять.
Speaker A
Ну это вообще называют манипулирование данными. Манипулировать данными. О'кей. Ну хранение, манипулирование. Что ещё? Мнализ какой-то, объединение.
Speaker A
Это всё манублирование. О'кей. Что ещё? Можем управление транзакциями. Что такое транзакция? Ну, транзакция - это определённая единица. То есть там, а, может быть, а, главное правило транзакции, либо все операции выполняются, либо, а, либо ни одна из них, то есть происходит откат.
Speaker A
Вот транзакция, э, транзакции используют, допустим, частно в банковском секторе. Это когда, допустим, мы списываем деньги с одного, а, лица, и как бы они должны перейти к другому лицу. Если там по пути какая-то из операций не пройдёт, то, как бы мы не
Speaker A
можем списать денег, как бы и не зачислить кому-то. То есть вот, и тогда отменяется вся транзакция.
Speaker A
Ты слушал слышала про Асит свойства? Да, это получается атомарность, согласованность, изолированность и надёжность. Это функции, ээ, это это получается основные характеристики разации.
Speaker A
Угу. О'кей. А где они выполняются обязательно? Мм, где они выполняются обязательно? Ну да. Каких в каком в каком виде баз данных?
Speaker A
Конечно же, виляционных базах данных, там где А в не просто не знаю таких примеров, когда ну в реализованных базовых данных там получается уже А вот эти вот осит свойства, они уже не жёстко выполняются.
Speaker A
А то есть критерий осид свойства, да? Угу. Угу. Ну, типа, если в реляционных они жёстко должны исполняться, то в нереляционных уже допускается нежёстко их исполнение.
Speaker A
Угу. О'кей. Оптимизация запросов. Можешь это про это рассказать в СУБД? Что такое оптимизация запросов СУБД?
Speaker A
Ну да, как одно из главных функций СУБД. Это так иность запросов или может нужно установить вначале А для оптимизации запросов используют индексы. Вот.
Speaker A
А индексы это про это, да? Нет. М оптимизация запросов. То есть ты делаешь какой-то SQL запрос, и если СБД считает, что он не оптимизирован, он, допустим, может его немножко преобразовать от себя, ну, чтобы быстрее его выполнить.
Speaker A
Ну, в том числе, как бы, ну, индексы не относится к оптимизации запросов. То есть сама СБД решает, как простить. Что-то не поняла.
Speaker A
Ну, типа, да, это же запрос. Угу. Индекс - это уже дополнительный элемент оптимизации, потому что ты его вручную создаёшь. То есть ты конкретно в базе данных указываешь, а по каким столбцам ты, допустим, ты хочешь сделать индекс. Угу.
Speaker A
Угу. Ладно. Есть, ну, принчи. Ну, о'кей. А если, допустим, резервное копирование и восстановление данных, тоже как одно из функций СБД.
Speaker A
А, да. поддержка многопользовательского доступа. Допустим, если сразу более одного человека а хочет что-то запросить у базу данных, чтобы, ну, остальные не ждали.
Speaker A
Угу. Ладно. Что такое нормализация в базе данных? Ну, нормализация - это получается процесс, а, устранения каких-то аномалий. А вот и, ну, и для этого были придуманы нормальные формы для достижения определённого качества этих, получается, баз данных.
Speaker A
Вот. Угу. Какие-то формы, сколько их? Получается, их много. А, но оптимально доводить базу данных.
Speaker A
Ну, я читала про шесть, но потом кое-где и восемь, которые там по фамилиям уже этих всяких программистов, изобретателей. Вот.
Speaker A
Ну, главное привести как минимум до трёх форм, потому что мы Ну, давай, что в чём они заключаются?
Speaker A
Первая, вторая, третья. Ну, получается, а первая нормальная форма, она, а, убирает, убирает всякие повторяющиеся значения. Вот, все знаният атомат. Допустим, у нас есть а таблица, в которой и домашний телефон, и рабочий в одном поле, и мы как бы
Speaker A
разбиваем, а, чтобы привести к разбиваем данные, то есть домашний, рабочий телефон. И как бы мы тогда, когда все данные будут атомарны, тогда мы приведём к первой форме. А вот, а ко второй форме, а мы, получается, а здесь а
Speaker A
создаём уже первичные ключи, которые а служат нам для, а, идентификации, получается уникальной ээ идентификации полей. Вот. И а третья нормальная форма - это когда мы, а, когда мы исключаем транзитивные зависимости а между неключевыми полями. Вот так вот.
Speaker A
О'кей. А что такое транзитивная зависимость? зависимость - это зависимость получается от, а, как называется?
Speaker A
Так, знала, забыла. Транзитивная зависимость. Ну, через вторые руки, как-то так. Угу. То есть, э, данные пошли по рукам, получается.
Speaker A
Ну, это получается, а неключевые атрибуты зависят только от первичного ключа. Вот так вот, когда мы устранили вот эту вот транзитивную зависимость.
Speaker A
Ладно, хорошо. Мы и так много сегодня сделали, даже немножко там перелемитили. Давай закончим на это нашу запись. Yeah.
Topics:UMLсистемный аналитиксобеседованиедиаграмма use caseBPMNUML диаграммыREST SOAPбазы данныхтранзакцииIT-собеседование
