WEBVTT 00:00:00.813 --> 00:00:02.375 Здравствуйте, уважаемые студенты. 00:00:02.495 --> 00:00:06.858 Прослушайте рекомендации к выполнению курсовой работы по дисциплине 00:00:07.018 --> 00:00:08.899 проектирование информационных систем. 00:00:09.139 --> 00:00:14.943 Лекцию подготовил доцент кафедры информатики, математики и 00:00:14.983 --> 00:00:19.066 естественно-научных дисциплин Черевичук Игорь Владимирович, к вашим услугам. 00:00:25.248 --> 00:00:28.646 При изучении дисциплины проектирования информационных систем студентами 00:00:28.806 --> 00:00:32.844 направления подготовки: 09.0303: Прикладная информатика, то есть уровень 00:00:32.963 --> 00:00:38.760 бакалавриата, профиль программы проектирования, разработка, внедрение и 00:00:38.840 --> 00:00:40.519 эксплуатация информационных систем. 00:00:41.212 --> 00:00:44.134 Предусматривается подготовка и защита курсовой работы. 00:00:45.055 --> 00:00:48.737 Выполнение курсовой работы по дисциплине проектирования информационных систем 00:00:48.937 --> 00:00:51.299 предусматривает выполнение следующих этапов. 00:00:51.779 --> 00:00:53.220 Прежде всего, выбор темы. 00:00:53.501 --> 00:00:55.782 Тематика курсовых работ разрабатывается 00:00:56.879 --> 00:01:00.440 Ежегодно пересматривается и утверждается кафедрой информатики, математики и 00:01:00.480 --> 00:01:01.761 естественно-научных дисциплин. 00:01:01.841 --> 00:01:04.442 Студент самостоятельно выбирает тему работы. 00:01:04.642 --> 00:01:08.163 Он может предложить свою тему, не указанную в тематике кафедры, но она 00:01:08.283 --> 00:01:11.405 обязательно должна быть согласована с научным руководителем. 00:01:12.205 --> 00:01:14.686 Кафедра устанавливает конечный срок выбора темы. 00:01:15.812 --> 00:01:21.017 Так, ну понятно, что темы определяются 00:01:23.219 --> 00:01:28.705 направлением работы кафедры, то есть предполагает создание, проектирование 00:01:28.825 --> 00:01:30.467 какой-то информационной системы. 00:01:30.587 --> 00:01:34.150 Собственно, характер информационной системы может быть выбран студентом по 00:01:34.270 --> 00:01:35.031 согласованию. 00:01:35.600 --> 00:01:41.997 То есть может быть какая-то система малого предприятия, может быть какая-то 00:01:42.157 --> 00:01:49.073 учётно-информационная система, каталоги библиотек электронные, либо там 00:01:49.433 --> 00:01:51.831 какой-то склад, либо что-то в этом роде. 00:01:52.515 --> 00:01:58.280 Так, ну и таким образом, собственно, тема прежде всего должна быть утверждена 00:01:58.360 --> 00:02:03.844 руководителем. Сбор и обработка информации является одним из наиболее ответственных и 00:02:03.924 --> 00:02:06.165 сложных этапов выполнения курсовой работы. 00:02:07.888 --> 00:02:11.446 Статистическая другая информация собирается с учётом задач, поставленных 00:02:11.606 --> 00:02:16.404 работой. Основными её источниками являются нормативные материалы, то есть законы, 00:02:16.444 --> 00:02:19.842 указы, постановления, методические указания, положения и тому подобное. 00:02:20.042 --> 00:02:23.680 Специальная литература, научные публикации, то есть книги, статьи по 00:02:23.760 --> 00:02:24.559 выбранной теме. 00:02:25.270 --> 00:02:28.428 Не рекомендуется научным руководителям и могут подбираться студентом 00:02:28.548 --> 00:02:32.265 самостоятельно. Эти материалы вместе с учебными пособиями служат основой 00:02:32.465 --> 00:02:35.143 подготовки теоретической части курсовой работы. 00:02:36.302 --> 00:02:42.738 Так, ну сразу обращаю внимание, что первая часть теоретическая, как правило, 00:02:42.898 --> 00:02:46.016 содержит много заимствованной общей информации, поэтому необходимо 00:02:46.954 --> 00:02:50.351 Обязательно сделать ссылки на источники информации. 00:02:50.430 --> 00:02:54.307 То есть вот в квадратных скобочках указывается номер источника информации, 00:02:54.426 --> 00:02:57.623 может быть с указанием страниц, может, просто сам источник. 00:02:58.023 --> 00:03:03.217 Но по крайней мере, откуда то или иное описываемая система, либо какие-то 00:03:03.337 --> 00:03:05.255 рекомендации, либо какие-то правила. 00:03:05.742 --> 00:03:12.104 Взяты обязательно нужно указать публикации в специализированных 00:03:12.224 --> 00:03:15.946 периодических изданиях. То есть вот прикладная информатика, информационные 00:03:16.346 --> 00:03:21.147 технологии, общедоступный PS-менеджер магазин. 00:03:21.582 --> 00:03:27.264 Информационные технологии вычислительной системы, CUS, IT-эксперт, информатика, её 00:03:27.384 --> 00:03:29.385 применение и так далее. 00:03:29.745 --> 00:03:33.026 Учебные пособия, включая наше учебное пособие. 00:03:33.307 --> 00:03:36.708 Студент должен использовать те учебные пособия, которые указаны в списках 00:03:36.828 --> 00:03:39.349 литературы по программам конкретных дисциплин. 00:03:40.273 --> 00:03:43.830 Статистические ежегодники, информационно-справочные сборники. 00:03:44.430 --> 00:03:47.627 Фактические данные об эффективности использования различных средств 00:03:47.707 --> 00:03:53.263 программирования. Подбор литературы в курсовой работе осуществляется студентом 00:03:53.423 --> 00:03:56.021 самостоятельно, с помощью руководителя работы. 00:03:56.141 --> 00:03:58.699 Студент обязан уметь пользоваться каталогами. 00:03:59.331 --> 00:04:03.375 Фондами библиотеки института, электронной библиотечной системой Академии, 00:04:03.415 --> 00:04:06.898 информационными ресурсами, глобальной компьютерной сети Интернет, осуществлять 00:04:06.978 --> 00:04:09.900 поиск нужной печатной электронной информации. 00:04:10.060 --> 00:04:14.745 Особенно важно тем, кто выполняет работу дистанционно, это пользоваться ресурсами 00:04:16.189 --> 00:04:17.630 Электронных библиотек. 00:04:18.070 --> 00:04:22.553 Собственно, ссылки на наиболее важные рекомендуемые источники приводятся в 00:04:22.633 --> 00:04:29.516 пособии. Вот, прежде всего, рекомендуется посмотреть пособие по 00:04:29.596 --> 00:04:31.037 выполнению курсовой работы. 00:04:33.176 --> 00:04:36.659 Вот. Ну, кроме того, что в зависимости от тематики требует, конечно, и 00:04:36.939 --> 00:04:38.661 дополнительной литературы. 00:04:39.261 --> 00:04:45.107 В принципе, поиск литературы может быть проводиться и, скажем, по ключевым словам, 00:04:45.307 --> 00:04:46.828 по направлениям. 00:04:47.229 --> 00:04:48.950 Вот, что сильно облегчает 00:04:49.939 --> 00:04:52.819 Соответственно, подбор литературы и выполнение работ. 00:04:53.499 --> 00:04:57.340 Изучение литературы лучше начинать с учебников, учебных пособий. 00:04:57.420 --> 00:05:00.740 Вначале необходимо твёрдо усвоить требования программы курса. 00:05:01.180 --> 00:05:04.820 Учебники во многом предопределяют главные направления исследования. 00:05:05.020 --> 00:05:06.580 Значительная их часть характеризует 00:05:07.348 --> 00:05:10.951 Актуальные вопросы, связанные с разработкой программных приложений. 00:05:11.912 --> 00:05:16.796 Содержание работы отражает её основную идею, структуру, логику изложения 00:05:16.916 --> 00:05:21.760 материала. Его составление определяет направленность работы: самостоятельность, 00:05:21.800 --> 00:05:23.562 проблемность, исследовательский характер. 00:05:23.682 --> 00:05:26.404 Рекомендуется включать в состав плана три главы. 00:05:27.632 --> 00:05:29.431 А у них по два-три параграфа. 00:05:29.671 --> 00:05:34.589 Ну, что касается первых глав, там, как правило, может быть, и меньше число 00:05:34.709 --> 00:05:37.708 параграфов, но основная часть, наверное, побольше. 00:05:39.548 --> 00:05:44.106 Как правило, содержание курсовой работы должно состоять из введения. 00:05:44.968 --> 00:05:50.002 Трёх пунктов вопроса содержательной части и заключения списка литературы и, 00:05:50.042 --> 00:05:56.754 возможно, приложений Формулировки темы и уровня подготовки 00:05:56.834 --> 00:06:01.389 студента, они могут быть следующие, то есть рассмотреть факторы 00:06:02.833 --> 00:06:07.394 Охарактеризовать состояние, выявить различия, ну и также проанализировать 00:06:07.594 --> 00:06:11.435 практику применения, охарактеризовать причины использования, обосновать 00:06:11.595 --> 00:06:15.995 необходимость моделирования, наметить пути решения проблемы, обеспечение 00:06:16.115 --> 00:06:19.116 информационной безопасности и тому подобное. 00:06:19.236 --> 00:06:21.517 Значит, обращаю внимание, что хорошим тоном является 00:06:23.754 --> 00:06:30.241 Тот момент, когда пояснительная записка о курсовой проекте пишется в безличной 00:06:30.321 --> 00:06:36.609 форме. То есть, не то, что я рассмотрел, я сделал, мы доказали, а было 00:06:36.849 --> 00:06:39.652 рассмотрено, проведён анализ. 00:06:40.481 --> 00:06:43.358 И соответственно, вот в такой терминологии мы работаем. 00:06:44.876 --> 00:06:49.351 Так, примерное содержание плана его оформления вы можете посмотреть на этом 00:06:49.391 --> 00:06:55.504 слайде. Но ещё вас адресую прежде всего к методическим указаниям, которые доступно, 00:06:55.544 --> 00:06:56.303 можно скачать. 00:06:56.940 --> 00:07:03.892 Соответственно, в этом случае там может быть более наглядно это представлено. 00:07:04.092 --> 00:07:07.289 Так, ну первая часть, как правило, теоретическая. 00:07:07.688 --> 00:07:11.284 То есть вот технология проектирования, моделирования информационных систем. 00:07:11.364 --> 00:07:13.681 То есть могут быть, как вот здесь рассмотрены 00:07:14.351 --> 00:07:18.075 Методы функционального анализа информационных систем, то есть это 00:07:18.196 --> 00:07:23.642 классический анализ с использованием различных известных методик и технологий 00:07:24.683 --> 00:07:28.968 разработки информационных систем, то есть на концептуальном уровне, на уровне 00:07:29.088 --> 00:07:29.608 моделей. 00:07:30.127 --> 00:07:32.046 Объектно-ориентированный подход. 00:07:32.526 --> 00:07:37.604 Конечно, редко когда эти подходы используются местные, совместно, хотя 00:07:37.764 --> 00:07:40.123 можно использовать и так в принципе. 00:07:40.922 --> 00:07:45.000 Для какой-то конкретной работы может быть достаточно выбрать один из подходов. 00:07:45.520 --> 00:07:49.119 Вот. Ну, если вы пишете, соответственно, такое теоретическое ведение 00:07:49.725 --> 00:07:54.365 То желательно, конечно, рассмотреть все подходы и обосновать, какой подход вам для 00:07:54.525 --> 00:07:57.524 конкретно вашей задачи будет более удобно использовать. 00:07:58.444 --> 00:08:04.363 Так, соответственно, пункт 1—3, выбор средств проектирования, как видите. 00:08:05.723 --> 00:08:06.683 Собственно, потом. 00:08:07.370 --> 00:08:10.893 Проектирование программного приложения, далее название. 00:08:10.973 --> 00:08:13.815 В данном случае ARM секретаря кафедры, как пример. 00:08:14.136 --> 00:08:18.339 Так, вот обращаю внимание, что желательно, особенно вот в таких вот информационных 00:08:18.499 --> 00:08:22.702 основных частях, указывать именно направления деятельности, чтобы они были 00:08:22.902 --> 00:08:25.104 не все одинаковые, как под копирку. 00:08:25.665 --> 00:08:28.903 Нехорошо, когда вот у вас, скажем, будет просто проектирование программного 00:08:29.063 --> 00:08:31.422 приложения без указания названия и его направления. 00:08:32.632 --> 00:08:36.351 То есть работа становится безликой какой-то, и сразу возникает сомнение: а 00:08:36.431 --> 00:08:37.711 сам ли товарищ делал? 00:08:37.831 --> 00:08:41.389 Может быть, что-то какую-то шаблонную работу скопировал, списал? 00:08:41.429 --> 00:08:44.828 Ну, шаблон в любом случае, конечно, присутствует, но надо, соответственно, 00:08:45.348 --> 00:08:46.788 придать специфику работы. 00:08:46.868 --> 00:08:48.067 То есть, в данном случае указать 00:08:48.906 --> 00:08:51.386 Именно направления. Вот это вот важный момент. 00:08:52.305 --> 00:08:55.945 Так, ну вот здесь, в принципе, стандартные требования, то есть моделирование основных 00:08:56.065 --> 00:09:02.344 потоков данных с использованием методик функционального анализа, может быть, даже 00:09:02.504 --> 00:09:05.943 объектно-ориентированного. Приводится ещё раздел моделирования информационной 00:09:06.023 --> 00:09:08.823 системы средствами языка ОМЛ. 00:09:11.423 --> 00:09:15.022 Более глубокое построение модели в данном случае используемого Amel. 00:09:15.102 --> 00:09:19.740 В принципе, детальное моделирование может быть и реализовано в системе AR, например, 00:09:19.940 --> 00:09:23.459 с помощью методики EDF-X и тому подобное. 00:09:23.579 --> 00:09:24.858 Есть варианты использования. 00:09:27.695 --> 00:09:31.697 Вот. Ну и собственно, проектирование базы данных приложения в соответствии с тем, 00:09:31.737 --> 00:09:36.499 что выбрана система разработки, и у них, соответственно, уже, собственно, эта 00:09:36.539 --> 00:09:41.661 система воплощается. Особое внимание прошу уделить всё-таки разработке моделей. 00:09:41.781 --> 00:09:46.183 То есть, это очень важный этап, и современные прогрессивные методы, вот, 00:09:46.223 --> 00:09:46.463 например 00:09:49.369 --> 00:09:54.212 Ragion Design process рекомендует всё-таки большое внимание уделять концептуальной 00:09:54.252 --> 00:09:58.375 проработке системы на уровне моделей, тогда реализация уже становится, 00:09:58.415 --> 00:10:03.739 собственно, как бы сказать, техническим элементом, когда концепция системы 00:10:03.899 --> 00:10:05.540 детально проработана и продумана. 00:10:06.413 --> 00:10:10.486 Так, ну тут прежде всего проектирование базы данных приложения. 00:10:10.765 --> 00:10:15.198 Когда обращаю внимание, что эти все моменты должны быть связаны, то есть 00:10:16.143 --> 00:10:20.779 Проектирование базы данных является следствием тех моделей, которые мы 00:10:20.858 --> 00:10:22.177 разработали до того. 00:10:22.377 --> 00:10:26.892 То есть, соответственно, уже словарь системы есть, какие-то названия объектов и 00:10:26.972 --> 00:10:29.649 элементов уже имеет место быть. 00:10:29.769 --> 00:10:31.327 То есть мы просто его воплощаем 00:10:33.130 --> 00:10:36.374 ...в базе реляционной модели, на основе реляционной модели. 00:10:37.095 --> 00:10:42.661 То есть, соответственно, от тех моделей содержательных, наглядных либо детальных, 00:10:42.741 --> 00:10:46.025 которые у нас уже имеются, мы переходим к разработке базы данных. 00:10:46.225 --> 00:10:50.149 В некоторых случаях этот подход достаточно тривиальный, но в любом случае требует всё 00:10:50.269 --> 00:10:50.470 равно 00:10:51.363 --> 00:10:57.998 знания и того, и другого То есть и уровня моделирования, и, соответственно, уровни 00:10:58.077 --> 00:11:02.953 разработки баз данных Так ну вот рекомендуется уделить внимание на 00:11:03.073 --> 00:11:08.029 разработку реляционных таблиц, прежде всего, вспомнить нормальные формы, для 00:11:08.189 --> 00:11:09.707 чего они нужны и как они используются 00:11:10.852 --> 00:11:13.373 Какие-то выводы о соответствии нормальной форме написать. 00:11:13.493 --> 00:11:17.294 Обязательно должно быть заключение, список используемых источников. 00:11:19.254 --> 00:11:26.096 Вот. Как оформляются работы, есть отдельное пособие, обратите 00:11:26.376 --> 00:11:30.337 обязательно внимание. То есть вот должно быть содержание, каким образом. 00:11:31.081 --> 00:11:32.841 Выполняется, как нумеруется. 00:11:33.001 --> 00:11:38.523 Обратите внимание, что в конце пунктов заглавия точки не ставятся. 00:11:38.803 --> 00:11:43.044 Вот в том случае, когда у нас, скажем, несколько предложений, тогда точка 00:11:43.204 --> 00:11:45.684 ставится в середине, последняя точка не ставится. 00:11:45.844 --> 00:11:47.925 Ну и такие прочие требования. 00:11:48.659 --> 00:11:52.662 Описано в отдельной методичке, на которые вот тоже обратите особое внимание. 00:11:53.263 --> 00:11:56.346 Итак, начнём: ведение к любой исследовательской аналитической работе 00:11:56.466 --> 00:11:57.827 имеет одинаковое назначение. 00:11:57.947 --> 00:12:02.031 Оно не описывает содержательную часть работы, только предваряет её. 00:12:02.191 --> 00:12:06.515 В курсовой работе оно содержит обоснование выбора темы, то есть актуальность, 00:12:06.675 --> 00:12:08.957 возросшую потребность в разработке в наши дни. 00:12:10.737 --> 00:12:12.457 Слабую изученность проблемы. 00:12:12.696 --> 00:12:15.016 Ну, рекомендуется один-два абзаца. 00:12:15.136 --> 00:12:20.334 Обычно это обоснование завершается так: «Всё рассмотрено, обусловлено выбором темы 00:12:20.494 --> 00:12:24.372 курсовой работы или этим обусловливается выбор в качестве темы и тому подобное и 00:12:24.492 --> 00:12:29.690 так далее». Главная часть введения — это формулировка целей и задач, поставленных 00:12:29.810 --> 00:12:32.329 при написании работы: объекты, предмет исследования. 00:12:33.147 --> 00:12:36.510 Их не сформулировать, исходя из содержания работы. 00:12:36.590 --> 00:12:39.913 При написании курсовой работы были поставлены следующие задачи. 00:12:40.033 --> 00:12:41.755 То есть первое, второе, третье. 00:12:42.075 --> 00:12:48.921 Либо пишется, что сначала указывается цель нечто более ёмкое и общее. 00:12:49.041 --> 00:12:50.082 А вот для, собственно 00:12:50.932 --> 00:12:54.855 Для достижения цели требуется решить следующую задачу и тоже список задач. 00:12:55.016 --> 00:12:59.780 Особое внимание нужно обратить на введение, соответствие введения 00:12:59.980 --> 00:13:04.185 заключению. То есть рассмотренные задачи в той же структуре, как они поставлены, 00:13:04.265 --> 00:13:06.187 должны быть в конце концов реализованы. 00:13:06.918 --> 00:13:12.757 И соответственно, какими-то должно быть соответствие тому, что 00:13:14.597 --> 00:13:18.396 списку задач, которые ставились, списку задач, которые реализованы. 00:13:19.195 --> 00:13:22.195 Так или иначе, все эти задачи должны быть реализованы в конце концов. 00:13:22.732 --> 00:13:26.094 Если такого соответствия нет, то, соответственно, нужно подредактировать. 00:13:26.614 --> 00:13:30.816 Либо какие-то изначальных задач убрать, если они в итоге реализованы не были, 00:13:31.096 --> 00:13:34.417 либо, соответственно, добавить, если что-то реализовали в конце концов. 00:13:34.577 --> 00:13:37.618 То есть как бы свести всё вот в единое согласованное целое. 00:13:38.981 --> 00:13:42.141 Объектом исследования является область применения различных программных систем 00:13:42.301 --> 00:13:44.621 при разработке моделей программного приложения. 00:13:45.021 --> 00:13:48.462 Предметом исследования выступают конкретные формы и виды использования 00:13:48.622 --> 00:13:49.982 программных инструментов. 00:13:50.622 --> 00:13:54.502 Выведение должна быть охарактеризована информационная база работы, что призвано 00:13:54.622 --> 00:13:58.342 подтверждать достоверность исследований, аналитических обзоров и записок. 00:13:58.382 --> 00:13:59.942 В курсовой работе она обязательна 00:14:01.017 --> 00:14:06.542 Она может уместиться в двух-трёх строчках, но её наличие обязательно как атрибут 00:14:06.622 --> 00:14:10.145 исследовательской работы. В работе использована в основном переводная 00:14:10.265 --> 00:14:13.187 литература в сфере информационных технологий, так как в отечественных 00:14:13.267 --> 00:14:16.109 изданиях эта тема пока не нашла должного развития, например. 00:14:16.230 --> 00:14:19.712 Или использована отечественная переводная учебная, периодическая литература, а также 00:14:19.792 --> 00:14:22.675 материалы периодических изданий в сфере информационных технологий. 00:14:23.269 --> 00:14:26.513 Практические материалы предприятий сфера и другие. 00:14:26.634 --> 00:14:29.838 Приводится также характеристика информации из Интернета. 00:14:31.279 --> 00:14:34.964 Введение может содержать ограничения темы и другие значения. 00:14:35.044 --> 00:14:38.048 Например, тема курсовой работы охватывает широкий круг проблем. 00:14:39.130 --> 00:14:43.131 Основное внимание представленной работе уделено и так далее. 00:14:43.891 --> 00:14:48.812 Описание процесса разработки приложения представлено в виде, то есть вот такими 00:14:48.892 --> 00:14:50.933 вот вводными словами нужно пользоваться. 00:14:51.493 --> 00:14:55.294 Содержательной основной части, как вариант, включает глава первая. 00:14:56.154 --> 00:15:01.189 Рассмотрение определения предмета, его характеристиках, роль в развитии 00:15:01.269 --> 00:15:06.025 информационной технологии, виды, классификация, элементы, принципы, методы 00:15:06.145 --> 00:15:08.423 моделирования и проектирования информационных систем. 00:15:09.534 --> 00:15:11.253 Глава вторая. Моделирование. 00:15:11.372 --> 00:15:15.169 Оно должно содержать краткую характеристику объекта исследования, его 00:15:15.409 --> 00:15:19.845 показатели. Изучение предмета исследования в рамках субъекта, отрасли информационных 00:15:19.925 --> 00:15:23.562 технологий. Особенности использования субъекта в данной отрасли. 00:15:23.682 --> 00:15:26.600 Также нужно провести детально проработанную модель информационной 00:15:26.680 --> 00:15:30.477 системы методами функционального или объектно-ориентированного анализа. 00:15:30.980 --> 00:15:32.738 Провести оценку показателей. 00:15:33.538 --> 00:15:36.374 Глава третья. Проектирование базы данных. 00:15:36.894 --> 00:15:41.809 То есть, в большинстве систем всё-таки имеет в своей основе базу данных, то есть 00:15:41.928 --> 00:15:43.727 информационное ядро системы. 00:15:44.486 --> 00:15:47.602 Конечно, могут быть какие-то исключительные варианты, не содержащие 00:15:47.642 --> 00:15:48.282 базу данных. 00:15:49.245 --> 00:15:53.644 То есть, ну, так или иначе, какой-то хранитель данных будет есть на уровне 00:15:53.723 --> 00:15:59.321 массивов, либо каких-то там внешних носителей в виде отдельных файлов. 00:15:59.641 --> 00:16:04.479 Вот. Ну, так или иначе, может быть, это тоже можно назвать базой данных, хотя и 00:16:04.559 --> 00:16:06.158 нестандартной и нереволюционной. 00:16:07.228 --> 00:16:11.748 То есть глава должна содержать обоснование разработку базы данных как информационного 00:16:11.868 --> 00:16:15.908 ядра системы. Могут быть даны рекомендации по совершенствованию процесса 00:16:16.028 --> 00:16:18.788 проектирования программных приложений в рамках исследования. 00:16:18.988 --> 00:16:23.348 Можно использовать материалы предприятия, СМИ, Интернет. 00:16:24.611 --> 00:16:28.249 Заключение составляется на основе написанной работы как выводы из неё. 00:16:28.609 --> 00:16:31.967 Это краткое изложение главных проблем и положений, изложенных в работе. 00:16:32.047 --> 00:16:36.166 В заключении не может содержаться новых моментов, не рассмотренных в основной 00:16:36.285 --> 00:16:41.123 части работы. Оно не является продолжением текста работы, а кратким выводом её 00:16:41.283 --> 00:16:41.843 содержания. 00:16:42.756 --> 00:16:47.152 Текст заключения может содержать выписки из основной части работы. 00:16:47.512 --> 00:16:50.909 Искусство составления заключения — это умение в краткой и лаконичной форме 00:16:51.029 --> 00:16:55.425 показать всё самое ценное в работе: новые идеи, собственный взгляд, возможность 00:16:55.545 --> 00:16:58.222 проблем, их обоснованность, пути решения проблем. 00:16:58.646 --> 00:17:03.723 ...и предложения. Так, ну вот порядок оформления курсовой работы. 00:17:03.922 --> 00:17:08.999 Рекомендуемый объём курсовой работы — 25, 35 листов формата A4. 00:17:09.519 --> 00:17:14.555 Курсовая работа должна состоять из следующих частей, расположенных в 00:17:14.635 --> 00:17:16.274 указанном порядке. Титульный лист. 00:17:17.940 --> 00:17:21.419 Содержание. То есть, соответственно, 00:17:24.538 --> 00:17:26.697 видение. Основная часть, заключение. 00:17:26.777 --> 00:17:30.816 Перечень условных обозначений символов, принятых в работе сокращения при 00:17:30.936 --> 00:17:33.015 необходимости, то есть факультативные. 00:17:33.095 --> 00:17:36.214 Но если их много используется, лучше сделать. 00:17:36.925 --> 00:17:41.929 Список используемых источников тоже по правилам по ГОСТам написаны. 00:17:42.129 --> 00:17:46.373 Приложение. Оригинальность текста должна быть не менее 60%. 00:17:46.493 --> 00:17:50.656 Проверить текст можно использованием, например, вот сайта антиплагиат.ру. 00:17:50.897 --> 00:17:53.899 Каждая структурная часть работы начинается с новой страницы. 00:17:54.570 --> 00:17:56.411 То есть имеется в виду каждая глава. 00:17:56.972 --> 00:18:00.855 Так, ну вот была ссылка, соответственно, на титульный лист. 00:18:01.696 --> 00:18:05.900 Пожалуйста, титульный лист. 00:18:05.980 --> 00:18:10.023 Ну, ещё раз обращаю внимание на то, что 00:18:11.187 --> 00:18:14.103 Есть рекомендации, каким образом это оформляется. 00:18:14.543 --> 00:18:20.815 Каждаемая письменная работа должна быть набрана в текстовом редакторе с включением 00:18:20.895 --> 00:18:23.132 таблицы иллюстраций непосредственно в текст работы. 00:18:23.212 --> 00:18:25.769 Сохранена в формате док в виде одного файла. 00:18:25.849 --> 00:18:26.009 Ну вот 00:18:26.708 --> 00:18:30.425 Соответственно, док X также можно использовать. 00:18:31.344 --> 00:18:34.621 Начиная с титульного лица и заканчивая последней страницей. 00:18:34.701 --> 00:18:36.260 Формат страницы A4. 00:18:36.420 --> 00:18:40.336 Текст в работ следует набирать, соблюдая следующие размеры полей. 00:18:40.416 --> 00:18:45.452 То есть правая — 10 мм, верхняя — 20 мм, левая — 30 мм. 00:18:45.988 --> 00:18:50.352 Тип шрифта — таймс нерован — четырнадцатый кегль. 00:18:50.873 --> 00:18:55.518 На рисунках и таблицах допускается использовать десятый кегль. 00:18:56.759 --> 00:19:01.925 Текст печатается через полтора интервала, то есть красная строка 1—25 см. 00:19:02.045 --> 00:19:04.527 Обращаю внимание, не стандартный один всё-таки там. 00:19:04.995 --> 00:19:07.114 Побольше выделить — это учебная работа. 00:19:07.714 --> 00:19:13.392 Цвет шрифта должна быть должен быть чёрным необходимо соблюдать, рекомендуем 00:19:13.512 --> 00:19:16.311 плотность, контрастность, чёткость изображения по всей работе. 00:19:16.711 --> 00:19:21.109 Полужирный шрифт, курсив и подчёркнутый шрифт не применяется, выравнивание текста 00:19:21.269 --> 00:19:21.868 по ширине. 00:19:23.180 --> 00:19:25.581 Выравнивание таблицы рисунков по центру. 00:19:25.941 --> 00:19:28.181 Расстановка переносов автоматическая. 00:19:28.302 --> 00:19:29.782 Вот обратите внимание. 00:19:30.582 --> 00:19:34.063 Вот это, как правило, достаточно заметно позволяет 00:19:39.424 --> 00:19:42.625 большую информацию в том же объёме представить. 00:19:43.886 --> 00:19:49.282 Так, ну вот сейчас подробно рассмотрим стандартные методологии моделирования 00:19:49.402 --> 00:19:50.801 информационных систем. 00:19:51.201 --> 00:19:55.158 То есть, как раз у нас вот вторая большая часть — это концептуальная проработка 00:19:55.278 --> 00:19:59.635 системы предполагается с использованием определённых методологий. 00:20:00.677 --> 00:20:04.357 Целью моделирования является систематизация знания компании, её 00:20:04.597 --> 00:20:08.437 бизнес-процессов в наглядной графической форме, более удобной для аналитической 00:20:08.557 --> 00:20:10.357 обработки полученной информации. 00:20:10.917 --> 00:20:16.437 Модель должна отражать структуру бизнес-процессов организации, детали их 00:20:16.517 --> 00:20:19.357 выполнения, последовательность документооборота. 00:20:19.477 --> 00:20:22.517 Моделирование бизнес-процессов организации включает два этапа. 00:20:22.869 --> 00:20:24.471 Структурное и детальное. 00:20:25.472 --> 00:20:29.075 Структурное моделирование информационной системы начинается прежде всего с 00:20:29.155 --> 00:20:33.078 бизнес-процессов. И поэтому структурное моделирование бизнес-процессов организации 00:20:33.238 --> 00:20:37.442 может выполняться в нотации DF0 с использованием инструментария BPN или на 00:20:37.482 --> 00:20:38.403 языке УМЭ. 00:20:39.371 --> 00:20:43.414 То есть объектно-ориентированный подход с использованием инструментария Rechn Rose, 00:20:43.454 --> 00:20:50.178 либо visial Paradigm, либо ещё тут более современные свободные средства 00:20:50.338 --> 00:20:55.622 моделирования есть. В конце концов, язык ОМ- 00:20:57.800 --> 00:21:00.643 Хорошими версиями Microsoft Vision. 00:21:00.923 --> 00:21:03.885 Детальное моделирование выполняется на языке UL. 00:21:04.206 --> 00:21:08.609 На этапе структурного моделирования модели должны быть отражены существующая 00:21:08.809 --> 00:21:10.290 организационная структура. 00:21:12.104 --> 00:21:15.260 Документы и иные сущности, используемые при исполнении моделированых 00:21:15.340 --> 00:21:19.135 бизнес-процессов, и необходимые для моделирования документооборота с описанием 00:21:19.215 --> 00:21:20.533 их основного смысла. 00:21:20.933 --> 00:21:25.367 Структура бизнес-процессов, отражающих иерархию от более общих групп с частным 00:21:25.527 --> 00:21:26.406 бизнес-процессами. 00:21:26.958 --> 00:21:30.276 Диаграммы взаимодействия для конечных бизнес-процессов, отражающих 00:21:30.316 --> 00:21:34.951 последовательность создания и перемещения документов, данных, материалов, ресурсов и 00:21:35.031 --> 00:21:37.389 тому подобное между действующими лицами. 00:21:37.869 --> 00:21:41.546 Подготовленная модель должна быть согласована архитекторами и ведущими 00:21:41.626 --> 00:21:44.823 программистами, подтверждающая, что структура бизнес-процессов понятна. 00:21:45.865 --> 00:21:49.784 Значит, обращаю внимание, что мы будем рассматривать в основном моделирование 00:21:49.824 --> 00:21:54.184 информационных систем, ориентированных на поддержку работы какого-то предприятия. 00:21:54.744 --> 00:22:00.223 Вот. В принципе, какие-то локальные информационные системы достаточно простые 00:22:00.303 --> 00:22:00.743 и могут 00:22:01.896 --> 00:22:07.371 Соответственно, моделироваться гораздо проще, поэтому мы посмотрим, рассмотрим 00:22:07.651 --> 00:22:09.410 проблему по максимуму, что называется. 00:22:09.570 --> 00:22:15.764 Естественно, простые системы могут иметь те же самые моменты, которые будут 00:22:15.804 --> 00:22:20.401 рассмотрены, только, может быть, они будут представлены более проще или 00:22:21.118 --> 00:22:23.117 Опущены. Вот. 00:22:23.996 --> 00:22:27.873 Детальное моделирование бизнес-процессов выполняется в той же модели и должно 00:22:27.913 --> 00:22:31.310 отражать требуемую детализацию и должно обеспечивать законодательное представление 00:22:31.990 --> 00:22:33.589 о деятельности организации. 00:22:33.748 --> 00:22:38.105 Детальная модель бизнес-процесса должна включать набор прецедентов, отражающих 00:22:38.225 --> 00:22:40.943 возможные варианты выполнения бизнес-процессов, как есть. 00:22:41.850 --> 00:22:45.331 Диаграммы действий, детально описывающие последовательность выполнения 00:22:45.411 --> 00:22:48.732 бизнес-процессов. Диаграммы взаимодействия, отражающие схемы 00:22:48.892 --> 00:22:50.092 документооборота. 00:22:50.812 --> 00:22:54.853 Модели должны быть согласованы с ведущими специалистами организациями, обладающими 00:22:54.973 --> 00:22:56.974 необходимыми занятиями, знаниями. 00:22:57.774 --> 00:23:01.775 В случае, если после построения модели согласование не было достигнуто 00:23:02.538 --> 00:23:05.857 В модель должны быть внесены необходимые уточнения и коррективы. 00:23:05.937 --> 00:23:10.256 То есть процесс итерации, согласования, внесения корректив и уточнений должен 00:23:10.576 --> 00:23:14.015 повторяться до момента полного подтверждения, что модель понятна и 00:23:14.135 --> 00:23:16.414 однозначно представляет детали бизнес-процесса. 00:23:17.844 --> 00:23:21.485 Рассмотрим историю развития методологии моделирования информационных систем. 00:23:21.685 --> 00:23:25.927 Основу многих современных методологий моделирования бизнес-процессов составляли 00:23:26.047 --> 00:23:30.328 методология САДТ, то есть структурит анализадизайн-текник. 00:23:30.609 --> 00:23:35.010 Метод структурного анализа и проектирования и алгоритмические языки, 00:23:35.090 --> 00:23:37.491 применяемые для разработки программного обеспечения. 00:23:38.105 --> 00:23:41.385 В сжатом виде история развития методологии моделирования информационных систем 00:23:41.545 --> 00:23:43.065 представлена в следующей таблице. 00:23:43.345 --> 00:23:46.666 Для наглядности параллельно приведена история развития подходов к управлению 00:23:46.866 --> 00:23:51.106 качеством. То есть в сороковые-шестидесятые годы, появление 00:23:51.266 --> 00:23:53.267 алгоритмических языков описания. 00:23:53.987 --> 00:23:56.627 С другой стороны, сразу национальные стандарты качества. 00:23:57.665 --> 00:24:01.822 Шестидесятые — появление методологии СНТ, то есть уже структурного анализа и 00:24:01.902 --> 00:24:06.580 проектирования, развитие стандартов в различных областях. 00:24:06.780 --> 00:24:11.257 Семидесятые-восьмидесятые — это вот расцвет как раз, наверное, структурного 00:24:11.377 --> 00:24:12.297 анализа, появление 00:24:13.240 --> 00:24:19.835 целые серии методологии DF: и DF0, и DF3, и DF1X, DFD-RD и, соответственно, принятие 00:24:19.915 --> 00:24:23.032 MSO серии 90088 года. 00:24:23.472 --> 00:24:29.347 Девяностые. Появление методологии AIS, то есть архитектура интегрированных 00:24:29.467 --> 00:24:31.345 информационных систем. УМЛ. 00:24:32.073 --> 00:24:37.034 Девяностые годы тоже. Универсальный язык моделирования, методологии компаний Orical 00:24:37.155 --> 00:24:38.755 Bun Ration и так далее. 00:24:38.915 --> 00:24:44.997 Понятие, то есть, соответственно, как стандарты качества, принятие MSO серия 900 00:24:45.957 --> 00:24:47.438 от девяносто четвёртого года. 00:24:47.984 --> 00:24:54.430 И двухтысячные годы уже принятие MSU серии 9 000 от 2000 года чёткое определение 00:24:54.790 --> 00:24:57.392 процессного перехода к управлению организацией. 00:24:57.592 --> 00:25:01.156 И, соответственно, как видите, методология моделирования бизнес-процессов с одной 00:25:01.236 --> 00:25:06.720 стороны и методология стандарта качества, как бы уже объединены в одном едином 00:25:06.840 --> 00:25:07.441 стандарте. 00:25:08.932 --> 00:25:13.016 Современная методология описания бизнес-процессов и информационных систем. 00:25:13.176 --> 00:25:17.579 Классический стандарт DFD-VFD содержит набор символов или обозначений, с помощью 00:25:17.659 --> 00:25:19.541 которых описывается бизнес-процесс. 00:25:19.701 --> 00:25:24.024 Эти обозначения принято называть языком или методологией описания процессов. 00:25:24.345 --> 00:25:27.347 В данном случае этот язык или методология является классическими. 00:25:28.237 --> 00:25:31.723 В настоящее время появилось много других языков или методологии описания 00:25:31.884 --> 00:25:37.253 бизнес-процессов и информационных систем, содержащих несколько иные обозначения. 00:25:38.284 --> 00:25:42.041 Причём каждая методология содержит свой язык и имеет своё название. 00:25:42.121 --> 00:25:46.518 В настоящее время это проводит, приводит к некоторому замешательству среди конечных 00:25:46.638 --> 00:25:50.475 пользователей, которые данную технологию применяют на практике своей организации. 00:25:50.915 --> 00:25:54.752 Отсюда возникает кажущаяся сложность применения процессной технологий. 00:25:55.372 --> 00:25:59.970 Ну, однако, как будет рассмотрено, в основе-то лежат вот эти самые стандартные 00:26:00.090 --> 00:26:02.449 подходы, как DFD, то есть 00:26:07.367 --> 00:26:13.804 диаграмма потоков данных, дата Flow диаграмм и volk-frow диаграмма работ. 00:26:15.240 --> 00:26:17.718 То есть work flow рабочих процессов. 00:26:18.397 --> 00:26:22.473 На самом деле, несмотря на своё различия, в основном связанные с названием диаграмм 00:26:22.553 --> 00:26:26.629 и видов используемых объектов, современная методология описания бизнес-процессов и 00:26:26.749 --> 00:26:30.705 информационных систем практически идентичны и представляют собой 00:26:30.864 --> 00:26:33.582 незначительное видоизменение двух классических схем. 00:26:33.982 --> 00:26:36.863 Вот эти самые DFD и VFD. 00:26:37.143 --> 00:26:43.664 То есть Data Flow диаграмм и VFD — work flow Diagram, которые уже, собственно, 00:26:44.624 --> 00:26:46.545 наиболее часто используются. 00:26:47.265 --> 00:26:50.465 Значит, кроме того, могут использоваться следующие 00:26:52.260 --> 00:26:54.539 Методики и DF0. 00:26:55.658 --> 00:27:00.856 DFD, соответственно, нотация Гейна Сарсона, Йорда Д-Марка. 00:27:01.215 --> 00:27:02.575 Методология DF3. 00:27:02.695 --> 00:27:07.732 Методология от Firm Orical, BM, методология ARIS, как мы уже сказали, что 00:27:07.812 --> 00:27:10.211 это комплексная методология интегрированная. 00:27:10.567 --> 00:27:15.131 ...который включает, в принципе, опыт уже к этому моменту практически всех имеющихся 00:27:15.251 --> 00:27:21.536 методологий. Ну и кроме того, вот Swiner Lines, так называемые плавательные дорожки 00:27:22.217 --> 00:27:26.540 тоже как мощная модель анализа бизнес-процессов, присутствует практически 00:27:27.944 --> 00:27:30.906 Во всех интегрированных системах моделирования. 00:27:31.467 --> 00:27:32.908 Методология DEF-0. 00:27:32.988 --> 00:27:37.832 То есть это вот первая, хотя, конечно, первые до этого были DFDFD, но это первая 00:27:37.992 --> 00:27:40.635 такая классическая методология. 00:27:42.116 --> 00:27:46.600 Язык ввели американские военные с целью успешного тиражирования бизнес-процессов 00:27:46.720 --> 00:27:48.642 предприятий аэрокосмической промышленности. 00:27:49.930 --> 00:27:54.008 В методология DF-0 незначительно отличается от классической схемы описания 00:27:54.128 --> 00:27:55.447 бизнес-процессов DFD. 00:27:55.487 --> 00:27:58.326 Основным отличием является наличие дополнительной аналитики. 00:27:58.446 --> 00:28:01.844 То есть данный стандарт описания бизнес-процессов предлагает показывать не 00:28:01.964 --> 00:28:06.681 просто входы и выходы, как это было в DFD-формате. 00:28:08.202 --> 00:28:10.963 Он предлагает ввести три типа входов. 00:28:11.843 --> 00:28:15.884 Так, ну, кроме входов и выходов, соответственно, присутствует ещё входы 00:28:16.004 --> 00:28:22.046 управления и так называемый механизм. 00:28:22.206 --> 00:28:26.448 То есть за счёт чего производится выполнение той или иной задачи или работы? 00:28:27.342 --> 00:28:31.146 В стандарте DF-0 с помощью входа показывают объекты информационные или 00:28:31.266 --> 00:28:34.269 материальные потоки, которые преобразуются в бизнес-процессе. 00:28:34.349 --> 00:28:38.353 С помощью управления показывают объекты материальные или информационные потоки, 00:28:38.433 --> 00:28:41.796 которые не преобразуются в процессе, но нужны для его выполнения. 00:28:42.556 --> 00:28:43.998 Скажем, какие-то нормативы. 00:28:45.495 --> 00:28:50.374 С помощью механизмов стали показывать механизмы, при помощи которых 00:28:50.534 --> 00:28:51.973 бизнес-процесс реализуется. 00:28:52.053 --> 00:28:54.092 То есть за счёт кого? Посредством чего? 00:28:54.932 --> 00:28:58.251 Технические средства, люди, информационные системы. 00:28:59.299 --> 00:29:02.937 Выход бизнес-процесса, соответственно, описанного в стандарте DF-0, полностью 00:29:02.977 --> 00:29:08.213 соответствует по смыслу выхода процесса, описанного при помощи DFD-схемы. 00:29:09.013 --> 00:29:13.010 Четыре типа объектов, применяемых для описания входов и выходов в стандарте DF-0 00:29:13.130 --> 00:29:15.368 в английском варианте образуют сокращение Icon. 00:29:16.168 --> 00:29:20.894 И на схемель размещаются в строго отведённых местах относительно работ, 00:29:20.974 --> 00:29:23.537 которые называются функциональными блоками. 00:29:23.898 --> 00:29:29.424 Так, ну таблицу переводить не будем, собственно, здесь на примере показано. 00:29:29.545 --> 00:29:31.107 То есть вход, выход. 00:29:32.914 --> 00:29:39.392 Управление определяется подачей сверху каких-то нормативов. 00:29:39.432 --> 00:29:41.672 В данном случае задание чертёж и механизмы. 00:29:41.712 --> 00:29:44.151 То есть, за счёт чего выполнение производится? 00:29:44.391 --> 00:29:46.030 Как вот здесь, токарь-станок. 00:29:46.745 --> 00:29:49.989 Стандарт DF0 получил большое распространение в США и активно 00:29:50.069 --> 00:29:53.913 использовался в России. Ввиду того, что в стандарте DF0 появилась дополнительная 00:29:53.993 --> 00:29:58.197 аналитика по сравнению с классическим стандартом DFD, схемы бизнес-процессов, 00:29:58.237 --> 00:30:02.281 получаемые при описании в стандарте DF0, выглядят более сложными с точки зрения 00:30:02.361 --> 00:30:04.643 менеджеров компаний, особенно старой школы. 00:30:05.227 --> 00:30:07.670 Ввиду ограниченного наличия у них свободного времени. 00:30:07.790 --> 00:30:11.674 Данная сложность часто приводит к тому, что менеджеры, особенно высшего уровня, 00:30:11.754 --> 00:30:15.397 которые должны принимать активное участие в проекте по описанию, оптимизации 00:30:15.558 --> 00:30:19.241 деятельности компании, отказываются от работы с DF-0. 00:30:19.321 --> 00:30:22.764 В данном случае DeF-0 является излишне информационно насыщенным и сложным 00:30:22.845 --> 00:30:24.286 стандартом, по их мнению. 00:30:25.260 --> 00:30:30.264 Второй недостаток стандарта DF-0 связан с тем, что он даёт больше поводов и 00:30:30.344 --> 00:30:33.666 возможностей сторонникам сопротивления изменениям притормозить проект по 00:30:33.706 --> 00:30:37.548 описанию, оптимизации бизнес-процессов и дискредитировать его идею. 00:30:37.868 --> 00:30:41.751 То есть это также связано с усложнённой аналитикой стандарта, которая часто даёт 00:30:41.871 --> 00:30:42.792 повод задуматься. 00:30:43.726 --> 00:30:46.684 ...и задавать следующий вопрос: а правильно ли, что этот объект относится ко 00:30:46.804 --> 00:30:50.163 входу? Может, он должен быть отнесён к управлению? 00:30:51.122 --> 00:30:57.199 Тем не менее, стандарт-ноль имеет широкое распространение, включая и в России тоже, 00:30:57.439 --> 00:31:01.396 так как по нему существует много книг и различных информационно-методологических 00:31:01.716 --> 00:31:02.316 материалов. 00:31:03.003 --> 00:31:07.080 Также существуют и программные продукты, которые поддерживают данный стандарт, 00:31:07.120 --> 00:31:08.639 овладеть которым несложно. 00:31:08.919 --> 00:31:12.636 Так, ну вот это является широко используемым, рекомендуемым классическим 00:31:12.715 --> 00:31:17.671 стандартным подходом именно как раз к первой части проектирования информационных 00:31:17.751 --> 00:31:18.111 систем. 00:31:19.142 --> 00:31:22.825 Практика показала, что стандарты DF-0 целесообразно использовать в проектах по 00:31:22.865 --> 00:31:26.388 описанию, оптимизации локальных бизнес-процессов в небольших проектах, в 00:31:26.469 --> 00:31:30.432 которых больше участвуют и принимают решения специалисты предметных областей. 00:31:30.872 --> 00:31:34.395 А руководители высшего уровня привлекаются для принятия решений по минимуму. 00:31:36.129 --> 00:31:37.772 Так, ну вот приводится пример. 00:31:37.852 --> 00:31:40.095 Диаграммы увольнения сотрудника. 00:31:40.696 --> 00:31:47.386 Как видите, здесь, как мы 00:31:47.546 --> 00:31:49.228 сказали, основной элемент работы. 00:31:50.158 --> 00:31:53.639 Визировать заявление непосредственно руководитель оформит, издать приказ об 00:31:53.759 --> 00:31:57.600 увольнении, произвести расчёт в бухгалтерии, оформить личное дело и 00:31:57.720 --> 00:32:00.400 наконец оформить и выдать трудовую книжку. 00:32:00.960 --> 00:32:02.680 Ну и, конечно, здесь указаны 00:32:03.625 --> 00:32:08.580 Непосредственно потоки, то есть какие документы, какие-то документы или элементы 00:32:08.700 --> 00:32:10.698 поступают на вход, какие-то на выходе. 00:32:10.778 --> 00:32:14.135 То есть на выходе мы видим, как видите, трудовая книжка сотрудника. 00:32:14.494 --> 00:32:17.252 Ну и кроме того, всякие дополнительные связи. 00:32:17.412 --> 00:32:19.410 Конечно, тут, глядя на эту схему 00:32:22.014 --> 00:32:25.535 Можно в некоторых случаях задуматься, а является ли это управлением? 00:32:25.615 --> 00:32:27.176 Может, это входная информация? 00:32:27.416 --> 00:32:32.178 Вот видите, как заполненный обходной лист является входной лист является 00:32:32.698 --> 00:32:37.700 управлением, соответственно, к работе произвести расчёты с бухгалтерией. 00:32:37.948 --> 00:32:43.465 То есть, опять же могут возникнуть полемика, так ли изображена эта диаграмма 00:32:43.585 --> 00:32:50.300 или нет? Методология DFD в 00:32:50.340 --> 00:32:53.258 нотациях Гейна Сарсона, Йортана Де Марко. 00:32:53.672 --> 00:32:56.875 Следующий стандарт признания бизнес-процессов, который получил 00:32:56.995 --> 00:33:01.279 распространение, был разработан на основе развития классической методологии DFD. 00:33:01.719 --> 00:33:07.204 Данный стандарт представлен двумя немного различающимися вариантами, которые 00:33:07.524 --> 00:33:12.048 называют нотациями. То есть первый из них называется нотация Гейна Сармсона, вторая 00:33:12.128 --> 00:33:13.610 — нотация Йордана Де Марко. 00:33:14.622 --> 00:33:17.986 Гейс Арсон предложил классическую DFD-схему немного усложнить. 00:33:18.066 --> 00:33:22.190 Он предложил ввести в дополнительный объект, с помощью которого показываются 00:33:22.350 --> 00:33:26.634 места бизнес-процессов, в которых хранится информация, то есть хранилище, либо 00:33:26.714 --> 00:33:29.677 материальные ресурсы. Примерами таких мест является архив 00:33:30.400 --> 00:33:34.682 ...в которых хранятся документы, базы данных, в которых хранится информация либо 00:33:34.762 --> 00:33:37.284 склад, на котором хранятся материальные ресурсы. 00:33:37.804 --> 00:33:40.605 Данный объект получил название хранилище данных. 00:33:40.725 --> 00:33:44.807 На DFD-схемах, в нотациях Гейне Сарсона и Ордана Де Марка, также используются 00:33:44.967 --> 00:33:47.528 объекты, с помощью которых показывают внешних субъектов... 00:33:48.847 --> 00:33:50.965 ...с которыми бизнес-процесс взаимодействует. 00:33:51.005 --> 00:33:53.204 Данный объект называют внешними сущностями. 00:33:53.284 --> 00:33:57.681 На рисунке пять приведён пример DFD-схемы бизнес-процесса оформления и выдачи 00:33:57.801 --> 00:34:03.317 трудовой книжки сотруднику при увольнении, разработанной нотацией Гейна Сарса. 00:34:06.525 --> 00:34:11.805 Как видите, присутствует, кроме того, хранилище, как бы сейф, архив. 00:34:14.885 --> 00:34:18.884 Кроме того, действующие лица или участники, как сотрудник. 00:34:19.364 --> 00:34:23.044 Вот определённым таким графическим образом отмечается. 00:34:26.229 --> 00:34:30.506 На данной схеме в качестве хранилища данных выступает сейф, в котором хранятся 00:34:30.586 --> 00:34:35.462 трудовые книжки. И архив, в который помещается заполненный обходной лист. 00:34:35.542 --> 00:34:39.419 В качестве внешней сущности выступает сотрудник, который увольняется и который 00:34:39.739 --> 00:34:43.216 получает выход рассматриваемого бизнес-процесса, то есть трудовую книжку. 00:34:53.043 --> 00:34:57.045 Вторая нотация Йордена Де Марка, методология GFD, была названа в честь 00:34:57.165 --> 00:34:59.846 разрабатывавшего её специалиста Йордена Де Марка. 00:35:00.086 --> 00:35:03.447 В первом приближении эта нотация аналогична нотации Гейне Сарсона, за 00:35:03.487 --> 00:35:04.768 исключением форм объектов. 00:35:04.848 --> 00:35:08.849 Для описания операций бизнес-процессов вместо закруглённых прямоугольников стали 00:35:08.929 --> 00:35:12.690 использоваться круги, то есть немного видоизменились другие объекты, хранилища 00:35:12.851 --> 00:35:14.091 данных и внешние сущности. 00:35:20.725 --> 00:35:25.965 Эти внешние сущности как сотрудник, хранилище данных, как такой вот 00:35:26.205 --> 00:35:32.685 горизонтально расположенный прямоугольник, по сути, та же модель. 00:35:36.085 --> 00:35:40.245 Так, в таблице приводятся название обозначений смысла элементов как основные 00:35:40.325 --> 00:35:42.565 элементы работы или функция. 00:35:44.170 --> 00:35:50.771 Соответственно, два возможных варианта: поток данных вот управляющие 00:35:50.891 --> 00:35:52.771 потоки обозначаются пунктирами. 00:35:54.251 --> 00:35:57.771 Таких нет. Хранилище данных. 00:35:58.851 --> 00:36:03.811 Ну, имеется в виду, что замкнутые тут, как-то так не пропечаталось прямоугольник. 00:36:05.298 --> 00:36:08.701 Без разрывов. Внешняя сущность. 00:36:11.423 --> 00:36:12.785 Методология DF—3. 00:36:12.865 --> 00:36:17.068 Стандарт ЭД-0, который был рассмотрен ранее, является развитием классического 00:36:17.188 --> 00:36:20.872 DFD-подхода, предназначенного для описания бизнес-процессов верхнего уровня. 00:36:21.570 --> 00:36:25.886 Для описания временной последовательности алгоритмов выполнения работ стандарт-0 не 00:36:25.966 --> 00:36:30.402 подходит. Для решения этой задачи стандарт DF-0 получил дальнейшее развитие, в 00:36:30.442 --> 00:36:35.198 результате чего был разработан стандарт-3, который входит в семейство стандарт и NF. 00:36:35.913 --> 00:36:40.751 Стандарт F-3 предназначен для описания бизнес-процессов нижнего уровня, содержит 00:36:40.831 --> 00:36:44.550 объекты, логические операторы, с помощью которых показывают альтернативы и места 00:36:44.710 --> 00:36:48.988 принятия решений в бизнес-процессе, а также объекты, стрелки с помощью которых 00:36:49.108 --> 00:36:51.787 показывают временную последовательность работ в бизнес-процессе. 00:36:52.833 --> 00:36:56.033 То есть вот схема бизнес-процесса показывается. 00:36:56.233 --> 00:37:00.433 И вот некоторый так называемый перекрёсток в момент принятия решения. 00:37:00.833 --> 00:37:07.672 То есть поток данных может идти на выход, получается, а может возвращаться обратно, 00:37:07.832 --> 00:37:10.832 если договор не согласован, идти на подготовку. 00:37:11.684 --> 00:37:14.167 Возвращаться надо подготовить договор. 00:37:15.168 --> 00:37:20.254 В отличие от классической методологии VF, в стандарте DF3, связи между работами 00:37:20.334 --> 00:37:25.380 делятся на три типа обозначения названий и смысл которых приведены в таблице три. 00:37:25.500 --> 00:37:27.342 То есть, во-первых, связь предшествования. 00:37:28.192 --> 00:37:31.788 Обозначает, что вторая работа начинает выполняться после завершения первой 00:37:31.948 --> 00:37:36.822 работы. Связь отношения обозначает, что вторая работа может начаться, даже 00:37:37.061 --> 00:37:40.617 закончиться до того момента, когда закончится выполнение первой работы, или 00:37:40.737 --> 00:37:43.334 пунктир. Связь потоков объектов. 00:37:43.993 --> 00:37:47.271 Двойная стрелочка одновременно обозначает временную последовательность работ и 00:37:47.391 --> 00:37:49.389 материальный, либо информационный поток. 00:37:49.469 --> 00:37:53.186 В данном случае вторая работа начинает выполняться после завершения первой 00:37:53.346 --> 00:37:58.262 работы. При этом выходом первой работы объект, название которого написано над 00:37:58.342 --> 00:38:00.181 стрелкой. В данном случае документ. 00:38:00.919 --> 00:38:05.401 Эта связь также обозначает, что объект продолжаемый первой работой, используется 00:38:05.521 --> 00:38:07.162 в последующих работах. 00:38:10.604 --> 00:38:15.407 Помимо наличия нескольких типов или связей между работами в стандарте DEF—3 00:38:15.687 --> 00:38:19.609 логические операторы, которые в данном случае называются перекрёстками, делятся 00:38:19.649 --> 00:38:22.410 на несколько типов, то есть исключающие или и-и-и 00:38:23.660 --> 00:38:28.625 Перекрёсток, исключающий или, обозначает, что после завершения работы A начинает 00:38:28.745 --> 00:38:32.028 выполняться только одна из трёх расположенных параллельно работ, то есть 00:38:32.188 --> 00:38:34.310 BC или D, одна из. 00:38:35.031 --> 00:38:36.873 В зависимости от условия: 1, 2, три. 00:38:36.993 --> 00:38:41.037 Перекрёсток i обозначает, что после завершения работы A начинают выполняться 00:38:41.117 --> 00:38:44.320 одновременно три параллельно расположенные работы одновременно. 00:38:46.509 --> 00:38:50.550 Перекрёсток или обозначает, что после завершения работы А может запуститься 00:38:50.750 --> 00:38:55.112 любая из комбинаций трёх параллельно расположенных работ BЦ и Д. 00:38:55.752 --> 00:38:57.833 Например, может запуститься только одна из них. 00:38:57.993 --> 00:38:59.673 Могут запуститься три работы. 00:39:00.193 --> 00:39:02.994 Также могут запуститься двойные комбинации, любые. 00:39:03.688 --> 00:39:08.322 Перекрёсток, исключающий или, является самым неопределённым, так как предполагает 00:39:08.522 --> 00:39:12.077 несколько возможных сценариев развития бизнес-процесса, применяется для описания 00:39:12.237 --> 00:39:17.670 слабо формализованных ситуаций, то есть, когда только одна из 00:39:26.256 --> 00:39:31.216 Перекрёстки и или подразделяются также на два подтипа: синхронные и ассинхронные. 00:39:31.256 --> 00:39:36.536 Перекрёстки синхронного типа, что работа БЦ и Д запускается одновременно после 00:39:36.736 --> 00:39:38.056 завершения работы A. 00:39:38.335 --> 00:39:42.055 Перекрёстки асинхронного типа требования к одновременности не предъявляют. 00:39:42.939 --> 00:39:46.421 Приведены на рисунке пять схем взаимодействия работ перекрёстках, 00:39:46.541 --> 00:39:48.182 называемые схемами расхождения. 00:39:48.222 --> 00:39:52.305 То есть наоборот. Так как от перекрёстков расходится несколько работ. 00:39:52.425 --> 00:39:56.227 Существуют и другие схемы взаимосвязи перекрёстков и работ, так называемые схемы 00:39:56.347 --> 00:39:59.829 схождения, когда к перекрёстку подходят несколько работ. 00:40:00.434 --> 00:40:06.233 Уже вот рисунок схемы схождения. 00:40:11.632 --> 00:40:15.711 Так, соответственно, в таблице приводятся обозначения возможных вариантов, то есть 00:40:16.290 --> 00:40:22.133 Синхронные, асинхронные, исключающие 00:40:22.333 --> 00:40:24.294 или. 00:40:25.974 --> 00:40:31.256 Так, ну вот весь этот инструментарий даёт возможность как раз наглядно и в то же 00:40:31.416 --> 00:40:33.537 время детально расписать 00:40:37.300 --> 00:40:41.854 Потоки задач, то есть процессы, которые выполняются, даже можно называть 00:40:41.974 --> 00:40:43.332 подпроцессы. 00:40:48.926 --> 00:40:53.400 Последним отличием стандарта DF3, в отличие от классической методологии Work 00:40:55.592 --> 00:40:59.197 Диаграммой является использование на схеме бизнес-процесса такого элемента, как 00:40:59.357 --> 00:41:02.561 объект ссылки, который связывается с работами и перекрёстками. 00:41:02.641 --> 00:41:06.806 С помощью объектов ссылки показывается прочная важная информация, прочная важная 00:41:06.926 --> 00:41:09.650 информация, которую целесообразно зафиксировать при описании 00:41:09.730 --> 00:41:10.491 бизнес-процесса. 00:41:12.056 --> 00:41:16.816 Технология 1D, методология описания данных, применяется для построения баз 00:41:16.976 --> 00:41:21.135 данных. Является методом для разработки реакционных баз данных и используется 00:41:21.295 --> 00:41:25.175 условный, использует условный синтаксис, специально разработанный для удобного 00:41:25.335 --> 00:41:26.975 построения концептуальной схемы. 00:41:27.095 --> 00:41:28.455 Концептуальной схемой мы назовём 00:41:29.083 --> 00:41:33.804 Универсальное представление структуры данных в рамках коммерческого предприятия, 00:41:33.964 --> 00:41:38.205 независимо от конечной реализации базы данных и аппаратной платформы. 00:41:38.405 --> 00:41:38.685 Будучи 00:41:40.193 --> 00:41:44.753 Статическим методом разработки DF-1X изначально не предназначен для 00:41:44.833 --> 00:41:47.953 динамического анализа по принципу AS, то есть как есть. 00:41:48.033 --> 00:41:52.633 Тем не менее, он иногда применяется в этом качестве как альтернатива методу EDF-1. 00:41:53.033 --> 00:41:57.073 Использование метода DF-1X наиболее целесообразно для построения логической 00:41:57.113 --> 00:42:00.953 структуры базы данных после того, когда все информационные ресурсы исследованы. 00:42:01.438 --> 00:42:05.799 Например, с помощью метода EDF1 либо метода EDF-0. 00:42:06.039 --> 00:42:10.519 И решение о внедрении реакционной базы данных как части корпоративной 00:42:10.599 --> 00:42:12.239 информационной системы было принято. 00:42:12.319 --> 00:42:16.279 Однако не стоит забывать, что средства моделирования EDF-1X специально 00:42:16.439 --> 00:42:19.359 разработаны для построения реакционной информационной системы. 00:42:19.519 --> 00:42:22.279 Если существует необходимость проектирования другой системы, скажем, 00:42:22.359 --> 00:42:23.159 объектно-оритированный 00:42:23.730 --> 00:42:27.809 То лучше избрать другие методы моделирования. 00:42:27.889 --> 00:42:30.209 Ну, прежде всего, на основе языка ОМЭль. 00:42:31.688 --> 00:42:35.927 Посмотрим пример. Вот связи DF представляют собой ссылки, соединение 00:42:36.087 --> 00:42:37.647 ассоциаций между сущностями. 00:42:37.767 --> 00:42:40.846 Ниже на рисунке приведён ряд примеров связи между сущностями. 00:42:42.388 --> 00:42:45.068 То есть, вот есть у нас отдел, есть сотрудник. 00:42:45.309 --> 00:42:47.429 Сотрудник работает в отделе. 00:42:49.109 --> 00:42:51.750 Определены сущности и атрибуты. 00:42:52.230 --> 00:42:54.711 Подчёркиваем, выделены ключевые атрибуты. 00:42:56.031 --> 00:42:59.272 Сущность описывается в диаграмме ИДФ с графическим объектом в виде 00:42:59.352 --> 00:43:03.273 прямоугольника. На рисунке приведён другой пример диаграммы. 00:43:04.528 --> 00:43:10.894 Вот, соответственно, ключевое поле, название сущности в рамочке, атрибуты. 00:43:16.458 --> 00:43:20.539 Существует несколько очевидных причин, по которым EDF-1X не следует применять в 00:43:20.579 --> 00:43:22.379 случае построения генерационных систем. 00:43:22.459 --> 00:43:26.819 Во-первых, EDF1x требует по от проектировщика определить ключевые 00:43:26.859 --> 00:43:29.979 атрибуты для того, чтобы отличить одну сущность от другой. 00:43:30.459 --> 00:43:35.059 В то время как объект-ориентированная система не требует задания ключевых полей. 00:43:36.320 --> 00:43:38.200 В целях идентифицирования объектов. 00:43:38.640 --> 00:43:42.280 Во-вторых, в тех случаях, когда более чем один атрибут является однозначно 00:43:42.640 --> 00:43:47.000 идентифицирующим сущность, проектировщик должен определить один из этих атрибутов 00:43:47.160 --> 00:43:49.840 первичным ключом, а все остальные вторичными. 00:43:49.880 --> 00:43:53.120 И таким образом построенная проектировщиками DF1x модель 00:43:53.933 --> 00:43:59.173 И переданная для окончательной реализации программиста является некорректной для 00:43:59.253 --> 00:44:01.453 применения методов объектно-ориентированной реализации, 00:44:01.493 --> 00:44:04.733 предназначенной для построения реализационной системы прежде всего. 00:44:05.013 --> 00:44:07.853 Ну, зато можно выделить и преимущества EDF-1X. 00:44:08.788 --> 00:44:12.031 Основным преимуществом является по сравнению с другими многочисленными 00:44:12.071 --> 00:44:18.357 методами разработки баз данных, такими как ЕР, например, или жёсткая и строгая 00:44:18.437 --> 00:44:19.958 стандартизация моделирования. 00:44:20.038 --> 00:44:23.962 Установленные стандарты позволяют избежать различной трактовки построенной модели, 00:44:24.002 --> 00:44:26.925 которая, несомненно, является значительным недостатком ЕЭР. 00:44:27.717 --> 00:44:30.317 Она вот более концептуальная. 00:44:31.117 --> 00:44:37.637 Так. Значит, развитие линейки DEF привело потом к появлению технологии DEF-4. 00:44:37.757 --> 00:44:39.637 Это объектно-ориентированная методология. 00:44:39.757 --> 00:44:43.277 Отражает взаимодействие объектов, удобно для создания программных продуктов на 00:44:43.357 --> 00:44:44.677 объектно-ориентированных языках. 00:44:44.837 --> 00:44:45.957 Например, C+. 00:44:46.571 --> 00:44:51.450 Широкого распространения не нашла, поскольку больше широко сейчас 00:44:51.730 --> 00:44:53.770 используется язык УМЭль. 00:44:54.730 --> 00:44:57.129 Вот как раз о нём тоже следует поговорить. 00:44:57.209 --> 00:45:00.409 То есть мы говорили, что вот рассмотренные до этого методы были, как бы сказать, 00:45:00.489 --> 00:45:03.568 классического функционального подхода, то есть вот процессов. 00:45:04.492 --> 00:45:07.295 И с этого действительно следует начинать. 00:45:07.455 --> 00:45:11.538 Ну, поскольку у нас инструментарий в разработке информационных систем в 00:45:11.658 --> 00:45:14.301 основном является объектно-ориентированным, то и появились, 00:45:14.341 --> 00:45:17.503 соответственно, методы объектно-ориентированного анализа. 00:45:17.663 --> 00:45:21.947 Есть смысл начинать вообще изначально исследовать систему в терминах 00:45:22.027 --> 00:45:23.548 объектно-ориентированного подхода? 00:45:24.252 --> 00:45:28.689 Вот как раз удобным инструментом в этом плане является унифицированный язык 00:45:28.729 --> 00:45:33.685 моделирования UML, то есть Unifide Moulin landage. 00:45:33.885 --> 00:45:37.122 То есть он является преемником методов объектно-ориентированного анализа и 00:45:37.242 --> 00:45:39.880 проектирования. То есть, в принципе, он 00:45:41.090 --> 00:45:45.972 Можно сказать, был построен на основе уже имеющихся методологий, которые предложены 00:45:46.572 --> 00:45:48.493 на данном плакате. 00:45:48.533 --> 00:45:51.975 То есть, в принципе, за основу была взята прежде всего объектоентированный подход 00:45:52.135 --> 00:45:57.698 Буча, так называемая диаграмма Буча, там, где в виде облачков показаны были объекты. 00:45:58.728 --> 00:46:04.575 Покод, соответственно, Джекабсон, 00:46:04.655 --> 00:46:09.780 РАМБО, которые связаны с моделированием бизнес-процессов. 00:46:10.101 --> 00:46:13.144 То есть вот такая модель РМТ имеется в виду. 00:46:14.097 --> 00:46:16.818 Май, майер пред ипостусловие и так далее. 00:46:16.938 --> 00:46:20.058 В принципе, довольно много можно найти источников. 00:46:20.218 --> 00:46:26.579 Так или иначе опыт этих методологий был объединён и воплощён в стандарты, 00:46:26.619 --> 00:46:30.380 соответственно, языка ОМЭль, вот, который с девяносто седьмого года является 00:46:30.660 --> 00:46:31.780 стандартом ОМЖ. 00:46:32.995 --> 00:46:36.156 Умейль — это язык визуализации, специфицирования и конструктирования 00:46:36.316 --> 00:46:40.277 документов и документирования артефактов программных систем. 00:46:40.357 --> 00:46:42.638 То есть, можно сказать, элементов программных систем. 00:46:43.558 --> 00:46:47.759 Язык УМЭль предназначен прежде всего для разработки программных систем. 00:46:47.839 --> 00:46:50.320 Его использование особенно эффективно в следующих областях. 00:46:51.294 --> 00:46:55.731 Информационная система масштаба предприятия: банковские, информационные, 00:46:55.771 --> 00:46:59.568 финансовые услуги, телекоммуникации, транспорт, оборонная промышленность, 00:46:59.608 --> 00:47:03.325 авиация, космонавтика, ручная торговля, медицинская электроника, наука, 00:47:03.485 --> 00:47:04.964 распределённые веб-системы. 00:47:05.244 --> 00:47:08.562 Как видите, довольно большой спектр. 00:47:09.603 --> 00:47:13.923 И, собственно, не все непосредственно связаны с информационными технологиями. 00:47:14.922 --> 00:47:16.402 Сущности языка ОМЭль. 00:47:16.482 --> 00:47:19.361 То есть вот основными строительными элементами являются так называемые 00:47:19.481 --> 00:47:24.160 сущности. В языке ОМЭЛ, в языке ОМЭЛ выделяется четыре типа сущностей: 00:47:24.280 --> 00:47:27.080 статические, поведенческие, группирующиеся, аннотационные. 00:47:28.037 --> 00:47:31.757 Статически это можно сказать базовые строительные блоки. 00:47:32.157 --> 00:47:36.477 Это прежде всего класс описания совокупности объектов с общими атрибутами, 00:47:36.517 --> 00:47:38.396 операциями, отношениями и семантикой. 00:47:38.476 --> 00:47:40.476 То есть как раз основа объектно-ориентированного 00:47:40.596 --> 00:47:44.156 программирования. Прежде всего инкапсуляция, то есть как капсула, в 00:47:44.196 --> 00:47:45.436 которой содержатся как данные 00:47:46.296 --> 00:47:49.174 Так и поведенческий элемент описываемой функции. 00:47:49.614 --> 00:47:55.771 И вот в этой методологии и рекомендуется мыслить при построении как раз 00:47:56.691 --> 00:47:59.769 информационной системы на основе объектно-ориентированного подхода. 00:48:00.209 --> 00:48:04.686 Интерфейс, совокупность операций, которые определяют сервисы или набор услуг, 00:48:04.726 --> 00:48:06.685 предоставляемых классом или компонентом. 00:48:08.183 --> 00:48:12.865 Кооперация редко когда какую-то сложную задачу можно решить средствами одного 00:48:12.905 --> 00:48:17.226 класса, поэтому требуется объединять несколько классов в некоторую кооперацию. 00:48:17.306 --> 00:48:20.428 То есть кооперация Collaboration определяет взаимодействие, представляет 00:48:20.508 --> 00:48:24.069 собой совокупность ролей других элементов, которые, работая совместно 00:48:24.815 --> 00:48:29.728 Производит некоторый кооперативный эффект, не сводящийся к простой сумме слагаемых. 00:48:29.968 --> 00:48:33.923 Соответственно, вот обозначается овалом пунктирной линии. 00:48:34.003 --> 00:48:37.278 Прецедент — Это вот как раз важный момент. 00:48:38.311 --> 00:48:41.191 Так называемый вариант использования Uscace. 00:48:41.431 --> 00:48:44.231 Это описание последовательности выполняемой системой действий, которая 00:48:44.391 --> 00:48:48.952 производит наблюдаемый результат, значимый для какого-то определённого эктора актёра. 00:48:49.312 --> 00:48:51.152 Вот обозначается как овалом. 00:48:51.472 --> 00:48:55.952 Именно как раз анализа прецедентов и рекомендуется начинать 00:48:56.997 --> 00:48:59.517 Разработку информационной системы в целом. 00:49:00.357 --> 00:49:05.756 То есть, в принципе, на уровне прецедентов и актёров можно представить 00:49:07.476 --> 00:49:11.796 то, что должна делать система, ещё не рассматривая каким образом и за счёт чего 00:49:12.842 --> 00:49:16.721 То есть, собственно, можно сказать, это такая формализованная постановка целей и 00:49:16.881 --> 00:49:18.921 задач для построения системы. 00:49:20.644 --> 00:49:24.888 Активным классом Active-класс называется класс, объекты, в котором вовлечены один 00:49:25.248 --> 00:49:29.491 несколько процессов нити или нити, поэтому могут инициировать управляющее 00:49:29.531 --> 00:49:33.815 воздействие. То есть нить или подпроцесс, который работает в рамках процессов. 00:49:34.015 --> 00:49:36.857 Несмотря на то, что это, конечно, прежде всего разновидность класса 00:49:37.445 --> 00:49:41.528 Но тем не менее, она выделена в отдельную структурную сущность ввиду большой её 00:49:41.648 --> 00:49:44.930 значимости, особенно в многозадачных системах. 00:49:45.691 --> 00:49:48.933 Компонент — это уже физическая, заменяемая часть системы. 00:49:48.973 --> 00:49:55.337 То есть до этого элементы были рассмотрены абстрактно, а это уже физический элемент, 00:49:55.377 --> 00:49:58.820 то есть представляет собой по сути файл, который хранится на диске. 00:49:59.822 --> 00:50:02.903 Физически заменяемая часть системы, которая соответствует некоторому набору 00:50:02.983 --> 00:50:04.864 интерфейсов и обеспечивает его реализацию. 00:50:04.944 --> 00:50:09.145 То есть может быть запускаемым файлом, может быть динамической библиотекой, может 00:50:09.346 --> 00:50:14.828 быть файлом ресурсов либо данных. 00:50:15.595 --> 00:50:19.473 Узел — это элемент реальной физической системы, который существует во время 00:50:19.713 --> 00:50:23.152 функционирования программного комплекса, представляет собой вычислительный ресурс, 00:50:23.192 --> 00:50:29.229 обычно обладающий как минимум некоторым объёмом памяти, чаще ещё способностью 00:50:29.348 --> 00:50:33.466 обработки. То есть, вот какая-нибудь рабочая станция, персональный компьютер 00:50:33.746 --> 00:50:34.426 либо сервер. 00:50:35.147 --> 00:50:38.345 Узлы. Важной задачей является описание размещений. 00:50:38.464 --> 00:50:44.260 То есть у информационной системы какая-то часть может быть помещена на сервер, так 00:50:44.340 --> 00:50:49.895 называемая серверная часть, какая-то на пользовательские компьютеры, то есть 00:50:50.055 --> 00:50:50.694 клиентская часть 00:50:51.792 --> 00:50:57.506 Эти части, соответственно, взаимодействуют друг с другом в рамках функционирования 00:50:57.666 --> 00:51:03.660 системы в целом. Так, ну вот кроме рассмотренных элементов, ОМЭль, являясь 00:51:03.820 --> 00:51:07.417 открытым языком, позволяет дополнять элементы некоторыми стереотипами. 00:51:08.121 --> 00:51:09.762 Например, стереотипы классов. 00:51:09.962 --> 00:51:12.924 То есть на основе уже имеющихся элементов строить другие. 00:51:13.364 --> 00:51:19.728 В некоторых случаях, собственно, специфика может быть такова, что довольно сильно 00:51:19.808 --> 00:51:21.649 отличаться от базового элемента. 00:51:21.849 --> 00:51:25.291 И в некоторых случаях даже иметь отдельный графический символ. 00:51:25.371 --> 00:51:26.772 Вот так называемый как эктор. 00:51:27.122 --> 00:51:29.004 Он является стереотипом класса. 00:51:29.685 --> 00:51:34.209 Сигнал. Ну, в данном случае просто стандартно обозначен как прямоугольник. 00:51:34.409 --> 00:51:36.691 Название стереотипа записывается в кавычках. 00:51:36.731 --> 00:51:40.495 То есть, видно уже, что это не просто класс, а это именно сигнал. 00:51:40.976 --> 00:51:42.937 Либо реационная таблица баз данных. 00:51:43.018 --> 00:51:43.818 Как видите, вот в таком 00:51:45.486 --> 00:51:51.205 Имеет, соответственно, поле, где указан первичный ключ. 00:51:51.525 --> 00:51:54.084 Соответственно, указаны какие-то атрибуты. 00:51:54.524 --> 00:51:57.043 Вот. Ну и кроме того, ещё правило целостности. 00:51:57.883 --> 00:51:59.802 Стереотипы компонентов. 00:52:00.362 --> 00:52:05.121 Вот. Апплет, так называемый, как стандартный вид компонента плюс 00:52:05.996 --> 00:52:10.352 В кавычках написано название стереотипа база данных, как обычно бочонком 00:52:10.552 --> 00:52:17.267 обозначается, как принято на структурных схемах, либо тело программы определённые 00:52:17.347 --> 00:52:18.626 визуальные значки. 00:52:19.225 --> 00:52:24.021 Поведенческие сущности, то есть вот мало того, что у нас есть структура системы, 00:52:24.461 --> 00:52:26.419 важно ещё бывает и описать поведение. 00:52:27.573 --> 00:52:30.255 В УМере имеются два механизма, описывающих поведение. 00:52:30.336 --> 00:52:31.737 То есть, прежде всего взаимодействие. 00:52:31.777 --> 00:52:35.501 Это поведение, суть которого заключается в обмене сообщениями мессенджеров между 00:52:35.741 --> 00:52:40.225 объектами в рамках конкретного контекста для достижения определённой цели. 00:52:40.305 --> 00:52:43.709 С помощью взаимодействия можно описать как отдельную операцию, так и поведение 00:52:43.909 --> 00:52:44.870 совокупности объектов. 00:52:45.939 --> 00:52:49.097 Взаимодействие предполагает ряд других элементов, таких как сообщения, 00:52:49.177 --> 00:52:54.054 последовательность действий, поведение, инициированное сообщением и связи между 00:52:54.334 --> 00:53:01.130 объектами. Так, ну вот, прежде всего на диаграммах показывается объекты, 00:53:01.410 --> 00:53:05.208 связи между объектами, линиями и сообщения, которыми обмениваются эти 00:53:05.327 --> 00:53:05.727 объекты. 00:53:06.415 --> 00:53:10.409 Чтобы отличить, собственно, объект как экземпляр класса от собственного класса, 00:53:10.608 --> 00:53:12.286 имя объекта подчёркивается. 00:53:12.406 --> 00:53:15.441 То есть, если мы видим подчёркнутое имя, то это объект, а не класс. 00:53:17.147 --> 00:53:18.989 Автомат либо стоит мышина. 00:53:19.069 --> 00:53:22.512 То есть вот альтернативный механизм описания поведения, определяющий 00:53:22.592 --> 00:53:25.435 последовательность состояний, через которые объекты или их взаимодействия 00:53:25.555 --> 00:53:29.078 проходят на протяжении своего жизненного цикла в ответ на различные события, а 00:53:29.158 --> 00:53:30.639 также реакции на эти события. 00:53:30.960 --> 00:53:35.123 С помощью автомата можно описать поведение отдельного класса или коперации классов. 00:53:35.360 --> 00:53:39.802 С автоматом связан ряд других элементов: состояния, переходы из одного состояния в 00:53:39.882 --> 00:53:44.485 другое, события, то есть сущности, инициирующие переходы, виды действий, 00:53:44.605 --> 00:53:46.045 реакция на переход. 00:53:47.326 --> 00:53:51.368 Так, автоматы ML могут быть вложены в структуру, то есть в одном состоянии 00:53:51.488 --> 00:53:53.129 находиться целый вложенный автомат. 00:53:53.812 --> 00:53:58.969 Ну, в данном случае показан пример как раз такого вложенного автомата указывается 00:53:59.169 --> 00:54:03.406 начальное состояние в виде жирной точки, конечное состояние, жирная точка, вот 00:54:03.646 --> 00:54:06.165 обведённая дополнительной окружностью. 00:54:06.445 --> 00:54:10.322 И состояние добавить к заказу новую позицию, как видите, имеет вложенную 00:54:10.402 --> 00:54:12.681 структуру, то есть там находится два состояния. 00:54:13.273 --> 00:54:17.313 Кроме того, при описании состояния могут быть использованы действия при входе, 00:54:17.393 --> 00:54:22.232 действие при выходе, деятельности соответствующим образом. 00:54:22.912 --> 00:54:29.152 В этом с помощью этой методики можно довольно удобно описать 00:54:30.151 --> 00:54:32.113 Вот как раз динамику работы систем. 00:54:32.193 --> 00:54:35.316 То есть особенно реактивных систем, которые меняют своё состояние в 00:54:35.357 --> 00:54:36.718 зависимости от ситуации. 00:54:37.279 --> 00:54:40.322 Вот, в виде так называемого автомата. 00:54:42.642 --> 00:54:46.444 Группирующие сущности — это не что иное, как вот, собственно, пакеты. 00:54:47.004 --> 00:54:50.645 Пакеты представляют собой универсальный механизм организации элементов группы. 00:54:50.685 --> 00:54:53.966 В пакет можно поместить структурные, поведенческие или даже группирующие 00:54:54.046 --> 00:54:57.407 сущности. В отличие от компонентов, существующих во время работы программы, 00:54:57.487 --> 00:55:01.249 пакеты носят чисто концептуальный характер, то есть имеет смысл только во 00:55:01.329 --> 00:55:02.209 время разработки. 00:55:03.420 --> 00:55:09.894 В данном случае, как правило, модели построения довольно большие и громоздкие. 00:55:10.334 --> 00:55:13.131 Как правило, сложные системы делят на подсистемы. 00:55:13.291 --> 00:55:16.368 Вот по такому принципу используются группирующие сущности. 00:55:16.448 --> 00:55:19.646 Применяются они очень часто. 00:55:19.965 --> 00:55:23.442 Аннотационные сущности — то есть не что иное, как комментарии. 00:55:23.562 --> 00:55:25.041 Пояснительные части моделей. 00:55:25.920 --> 00:55:29.117 Эти комментарии для дополнительного описания, разъяснений или замечания к 00:55:29.197 --> 00:55:33.032 любому элементу модели. Имеется только один базовый тип — это вот ноте, само 00:55:33.272 --> 00:55:37.307 примечание. Примечание — это просто символ для обозначения комментариев или 00:55:37.467 --> 00:55:40.344 ограничений, присоединённых к элементам или группы элементов. 00:55:40.424 --> 00:55:43.660 Присоединяется с помощью плантивной линии, то есть специализированной связи. 00:55:44.905 --> 00:55:51.552 Так. Кроме того, что вот язык Umail, как мы сказали, имеет рассмотренные сущности, 00:55:51.833 --> 00:55:54.876 также ещё между сущностями должны быть описаны связи. 00:55:56.127 --> 00:56:00.484 Четыре связи базовых рассматриваются в языке ОМЭ — это зависимость, семантическое 00:56:00.604 --> 00:56:04.162 отношение между двумя сущностями, при котором изменение одной из них независимой 00:56:04.322 --> 00:56:07.161 может повлиять на семантику другой, то есть зависимой. 00:56:07.800 --> 00:56:11.838 Ассоциация — это структурные отношения, описывающее совокупность связей между 00:56:12.038 --> 00:56:13.917 концептуально независимыми объектами. 00:56:14.818 --> 00:56:18.019 Вот. Ассоциация при всей простоте имеет больше всего свойств. 00:56:18.620 --> 00:56:22.662 На концах ассоциации могут быть показаны множественность, как вот здесь показано: с 00:56:22.702 --> 00:56:24.903 одной стороны 0,1, с другой 1 Н. 00:56:25.263 --> 00:56:31.666 То есть, в отличие от системы баз данных, где используются типы связей, как один к 00:56:31.746 --> 00:56:34.908 одному, один ко многим, много к одному и многие ко многим. 00:56:35.028 --> 00:56:36.388 Здесь, видите, это более гибко. 00:56:37.308 --> 00:56:40.909 Можно более детально, соответственно, описать. 00:56:41.069 --> 00:56:44.429 То есть, с одной стороны, либо 0, либо один, либо просто один. 00:56:44.749 --> 00:56:46.550 Тогда один должен быть обязательно. 00:56:47.110 --> 00:56:49.150 С другой стороны, 1N, то есть много. 00:56:49.470 --> 00:56:53.871 Либо N может быть ограниченным каким-то от одного до пяти, скажем. 00:56:55.189 --> 00:56:57.628 Разновидностью ассоциаций является агрегирование. 00:56:57.708 --> 00:56:59.387 То есть отношение — часть целая. 00:56:59.547 --> 00:57:06.264 Факультет, кафедра, как вот здесь показано, то есть тоже удобно 00:57:06.384 --> 00:57:07.983 описывать такие иерархии. 00:57:08.903 --> 00:57:13.740 Обобщение — это вот то самое типовое отношение наследования, характерное для 00:57:13.860 --> 00:57:15.100 объектно-ориентированных систем. 00:57:15.405 --> 00:57:18.683 Отношение специализации, обобщения, при котором объект специализированного 00:57:18.763 --> 00:57:22.599 элемента, потомок может быть поставлен вместо объекта обобщённого элемента — 00:57:22.599 --> 00:57:23.878 родителя или предка. 00:57:24.358 --> 00:57:26.436 Сплошная линия, закрытая стрелочка. 00:57:26.876 --> 00:57:30.113 И реализация, специфическое отношение, семантическое отношение между 00:57:30.233 --> 00:57:33.710 классификаторами, при котором один классификатор определяет контракт, другой 00:57:33.790 --> 00:57:35.029 гарантирует его выполнение. 00:57:36.342 --> 00:57:38.459 используется в особых случаях. 00:57:38.539 --> 00:57:45.252 То есть, в том случае, когда какой-то класс, если абстрактный уровень или 00:57:48.648 --> 00:57:52.005 компонент, если физический уровень, реализует какой-то интерфейс 00:57:53.205 --> 00:57:57.644 Вот, соответственно, между интерфейсом и его реализацией либо между прецедентом и 00:57:57.764 --> 00:58:02.443 кооперацией. То есть тоже допустимое отношение реализации. 00:58:02.523 --> 00:58:04.682 В любом случае предполагается контракт. 00:58:05.482 --> 00:58:09.161 Вот. Ну и здесь в качестве примера приводится довольно сложная программа 00:58:09.561 --> 00:58:10.720 описания некоторой вот 00:58:12.025 --> 00:58:18.705 ...информационной системы вуза, так скажем, что вот абстрактный 00:58:18.825 --> 00:58:25.505 класс персона имеет атрибуты, его потомки — 00:58:25.585 --> 00:58:26.865 студент-преподаватель. 00:58:26.905 --> 00:58:28.705 Обращаем внимание, что стрелочка 00:58:30.600 --> 00:58:34.282 Обобщение указывает на супер-класс, то есть на родительский. 00:58:35.082 --> 00:58:42.004 Вот что может быть показаться нелогично, но тем 00:58:42.044 --> 00:58:45.565 не менее, так и есть. Конец стрелки показывает на супер-класс, на родительский 00:58:45.685 --> 00:58:46.005 класс. 00:58:46.608 --> 00:58:49.888 Между студентом и преподавателем ассоциация в плане обучения. 00:58:50.568 --> 00:58:53.768 То есть отношения типа многие ко многим. 00:58:53.888 --> 00:58:55.968 Показываются роли на концах ассоциации. 00:58:56.048 --> 00:58:59.768 Студент, соответственно, обучаемый, преподаватель стал быть обучающий. 00:59:00.368 --> 00:59:02.128 Ну и дополнительные ещё тут 00:59:02.817 --> 00:59:08.894 Описаны интерфейсы в закрытом виде, то есть в виде одной иконки 00:59:10.093 --> 00:59:12.812 окружности, соответственно, общественная работа. 00:59:12.892 --> 00:59:15.931 Либо интерфейс раскрывается как стереотипный класс. 00:59:16.491 --> 00:59:20.769 Вот. Но только интерфейс не может содержать атрибутов, только операций, то 00:59:20.809 --> 00:59:22.168 есть как ведение дисциплины. 00:59:27.655 --> 00:59:29.255 Примерно стереотипную зависимость. 00:59:29.335 --> 00:59:35.136 Так же, как и элементы стереотипной зависимости, то есть отношения также могут 00:59:35.176 --> 00:59:36.616 иметь различные стереотипы. 00:59:36.696 --> 00:59:40.616 То есть, в данном случае используется зависимость стереотипная, типа сент, 00:59:40.696 --> 00:59:45.297 которая связывает сигнал, в данном случае деление на ноль, то есть исключительная 00:59:45.457 --> 00:59:46.057 ситуация. 00:59:46.572 --> 00:59:51.570 Рексепшн — деление на ноль и арифметический блок или модуль, который 00:59:52.010 --> 00:59:53.609 эту операцию выполняет. 00:59:54.129 --> 00:59:58.447 То есть, соответственно, при выполнении модуля возможно возникновение события, то 00:59:58.527 --> 01:00:01.926 есть вот этого самого исключительного ситуации деления на ноль. 01:00:03.565 --> 01:00:06.326 Таким образом, это моделируется средством amale. 01:00:07.367 --> 01:00:09.328 Диаграммы компонентов. 01:00:09.808 --> 01:00:15.851 Как пример приводится, то есть компоненты и интерфейсы, которые реализуют данные 01:00:15.971 --> 01:00:17.812 компоненты, плюс указываются связь. 01:00:18.189 --> 01:00:22.067 Связи здесь прежде всего реализация сплошной линией в упрощённом виде 01:00:22.226 --> 01:00:24.265 обозначается, не путается с ассоциацией. 01:00:24.345 --> 01:00:26.744 Если это интерфейс, то это значит реализация. 01:00:27.263 --> 01:00:31.341 И зависимости. Вот видите, как обычно зависимостей много, рекомендуется, если 01:00:31.460 --> 01:00:33.539 зависимостей очень много, их просто вообще опускать. 01:00:34.079 --> 01:00:40.284 Ну, это показывает, что тот или иной компонент использует те или иные, 01:00:41.125 --> 01:00:47.329 то есть импортирует те или иные возможности других компонентов. 01:00:48.650 --> 01:00:50.172 Так, вот приводится пример. 01:00:51.462 --> 01:00:55.378 На уровне пакетов организационный аспект какой-то организации. 01:00:55.498 --> 01:00:58.935 То есть, соответственно, структурные подразделения моделируются как пакеты, 01:00:59.055 --> 01:01:00.773 связи как зависимости. 01:01:02.732 --> 01:01:06.608 Вот тоже интересный момент, используются специальные стереотипы. 01:01:07.340 --> 01:01:11.383 ...классов для описания бизнес-процессов, документооборот предприятия. 01:01:11.464 --> 01:01:16.508 То есть вводятся такие стереотипы документов, как просто документ, так 01:01:16.668 --> 01:01:20.352 называемый regestration или регистр, то есть представляющий собой таблицу 01:01:20.512 --> 01:01:22.714 «Репорт», то есть отчёт. 01:01:23.034 --> 01:01:25.396 Вот. Ну и как-то более наглядно, если 01:01:26.398 --> 01:01:31.159 ...каким-то определённым цветом выделять документы определённых видов. 01:01:31.279 --> 01:01:36.841 Кроме того, имеются стереотипные исполнители, то есть так называемые 01:01:36.961 --> 01:01:42.003 бизнес-исполнители. Вот это вот, собственно, человечки несколько отличается 01:01:42.123 --> 01:01:42.923 от стандартного. 01:01:44.089 --> 01:01:45.368 Вектор действующего лица. 01:01:45.408 --> 01:01:47.887 То есть имеется в виду, что это бизнес-модель и, соответственно, 01:01:47.927 --> 01:01:49.166 бизнес-исполнителя. 01:01:49.846 --> 01:01:53.364 Так. Ну и таким образом, язык является удобным инструментом реализации 01:01:53.643 --> 01:01:55.922 документирования и разработки информационных систем. 01:01:55.962 --> 01:01:59.160 При этом является открытым языком с использованием механизмов расширения, с 01:01:59.240 --> 01:02:02.398 успехом может быть использован при моделировании практически любой предметной 01:02:02.518 --> 01:02:02.998 области. 01:02:03.451 --> 01:02:08.209 Так, ну вот использование его в рамках выполнения курсовой работы не является 01:02:08.568 --> 01:02:11.407 обязательным, то есть мы так подробно рассмотрели его. 01:02:11.687 --> 01:02:15.965 Но тем не менее, если предполагается реализация какими-то средствами 01:02:16.085 --> 01:02:20.642 объектно-ориентированного программирования, то будет желательно хотя 01:02:20.682 --> 01:02:22.242 бы привести основные модели. 01:02:24.775 --> 01:02:28.092 То есть, в разделе концептуальной разработки системы. 01:02:28.572 --> 01:02:32.769 В этом случае тогда уже, как правило, структура системы получается более 01:02:33.089 --> 01:02:39.524 продуманной и требует в итоге меньшего времени на её реализацию и поддержку. 01:02:41.682 --> 01:02:44.320 Так, ну, в данном случае предлагается литература. 01:02:45.767 --> 01:02:50.691 По использованию языка OmL. 01:02:51.611 --> 01:02:58.056 Спасибо за внимание Так, ну давайте на этом мы 01:02:58.416 --> 01:02:59.857 лекцию закончим. 01:02:59.977 --> 01:03:02.139 То есть, в принципе, вводная часть 01:03:02.940 --> 01:03:09.136 К выполнению курсового проекта у нас рассмотрено. 01:03:09.455 --> 01:03:14.292 Вот, обращаю внимание на оформление работы и, соответственно, последовательность 01:03:14.412 --> 01:03:18.050 изложения материала. То есть все части должны быть связаны 01:03:18.912 --> 01:03:24.038 Если в первой части идёт в выведении постановочная часть определены какие-то 01:03:24.158 --> 01:03:30.645 задачи, то в следующей части мы рассматриваем, соответственно, реализацию 01:03:30.926 --> 01:03:34.450 этих задач на уровне моделирования концептуальных построений. 01:03:35.627 --> 01:03:42.382 Потом в плане реализации мы реализуем все эти самые модели, которые построены уже в 01:03:42.462 --> 01:03:45.061 виде программного кода, в виде программных модулей. 01:03:45.101 --> 01:03:49.338 И в конце концов в заключении описываем, что сделано то-то, то-то и то-то в 01:03:49.378 --> 01:03:51.937 соответствии с тем, что, собственно, было постановлено. 01:03:52.225 --> 01:03:54.588 ...в качестве поставленного в качестве задач. 01:03:55.109 --> 01:04:00.715 Вот на это внимание обязательно нужно обратить, что разделы не разорваны сами по 01:04:00.795 --> 01:04:06.201 себе Вот они все, собственно, логически связаны и должны вытекать одно из другого 01:04:07.602 --> 01:04:08.203 Спасибо за...