Задание Маркетинг. Задание. Задание Заполнение листа Задание на производственную практику (эксплуатационную практику) и составление

• Название: Задание Заполнение листа Задание на производственную практику (эксплуатационную практику) и составление
• Анкор: Задание Маркетинг
• Дата: 14.12.2021
• Размер: 1.24 Mb.
• Имя файла: Задание.docx
• Тип: График проведения; #303232
• страница: 7 из 8

ПРИЛОЖЕНИЕ А

Методические рекомендации по заполнению разделов отчета производственной практики

Раздел «ВВЕДЕНИЕ» должен содержать общие сведения о производственной практике. В данном разделе отчета необходимо отразить выполнение Задания 1. Другими словами, необходимо описать место и назначение производственной практики, сформулировать цели и задачи, поставленные самостоятельно на период прохождения производственной практики. Надо описать, какие практические навыки необходимо приобрести в процессе прохождения производственной практики, перечислить приобретенные компетенции.

При написании раздела «ХАРАКТЕРИСТИКА ПРЕДПРИЯТИЯ – МЕСТА ПРАКТИКИ» необходимо описать выполнение Задания 2 и Задания 3. Используя различные методы прикладной информатики, методы разработки и реализации проектных решений по автоматизации и информатизации, используя современные информационно-коммуникационные технологии и технологии программирования, отразить цель функционирования предприятия в целом, его организационную структуру и основные параметры его функционирования, основные этапы и процессы рассматриваемой деятельности, используемые ресурсы.

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

В разделе «ОПИСАНИЕ ЗАДАЧ, РЕШАЕМЫХ ЗА ВРЕМЯ ПРАКТИКИ» нужно отразить все этапы выполнения Задания 4, то есть показать алгоритмы выполнения выполненных задач. При необходимости представить в ПРИЛОЖЕНИИ программный код.

В разделе «СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ» должны быть представлены учебники, учебные пособия, электронные источники за последние 5 лет (не менее 10 наименований). Оформление библиографического списка должно соответствовать ГОСТ 7.0.100–2018.

В «ЗАКЛЮЧЕНИИ» подводятся итоги производственной практики, фиксируются выполненные и невыполненные задания на производственную практику, сформированы ли компетенции, получены ли запланированные на период практики результаты.

ПРИЛОЖЕНИЕ Б

Методические рекомендации по построению схем документирования бизнес-процессов

Унифицированный язык моделирования UML

Унифицированный язык моделирования UML (Unified Modeling Language, UML) представляет собой графическую нотацию, которая предназначена для моделирования и описания всех процессов, протекающих в процессе разработки.

Основные диаграммы UML:

• 
  вариантов использования (use case diagram);
  
• 
  классов (class diagram);
  
• 
  кооперации (collaboration diagram);
  
• 
  последовательности (sequence diagram);
  
• 
  состояний (statechart diagram);
  
• 
  видов деятельности (activity diagram);
  
• 
  компонентов (component diagram);
  
• 
  развертывания (deployment diagram).
  

Для примера моделирования системы выбран программный инструмент моделирования StarUML. Данную программу можно скачать с официального сайта StarUML и свободно использовать в работе.

Диаграммы прецедентов

Моделирование системы с точки зрения пользователя – задача прецедентов.

Диаграмма прецедентов (диаграмма вариантов использования) – это диаграмма, на которой изображаются отношения между исполнителями (актерами) и прецедентами (вариантами использования), другими словами, это пользовательское представление системы.

С помощью этой диаграммы аналитик понимает принципы работы системы и формулирует функциональные требования к системе с точки зрения ее будущих пользователей.

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

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

Результат прецедента должен быть полезен исполнителю, инициировавшему этот прецедент, либо какому-то другому исполнителю.

После исполнения прецедента в системе должны произойти некоторые изменения, например появление новых данных, изменение поведения.

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

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

Отношение – это семантическая связь между отдельными элементами модели.

В основном на диаграммах прецедентов используются следующие типы отношений:

• 
  ассоциация;
  
• 
  включение;
  
• 
  расширение;
  
• 
  обобщения.
  

Ассоциация – это структурное отношение, показывающее, что объекты связаны между собой некоторым образом (см. рис. 1).



Рис. 1. Отношение ассоциации между актером и прецедентом

Включение (include) – отношение, показывающее, что действия одного прецедента включают действия другого.

При этом исполнение базового прецедента невозможно без исполнения используемого.

Изображается включение в виде пунктирной стрелки с надписью <>, которая направлена от базового элемента к используемому.

Расширение (extend) – отношение, создающее новый прецедент путем добавления нескольких шагов к существующему.

Изображается расширение пунктирной стрелкой с надписью <>, направленной от используемого прецедента к базовому.

Обобщение – это отношение между общей сущностью и ее конкретным воплощением.

На диаграммах обобщение обозначается стрелкой с незакрашенным треугольником на конце, направленной от частного элемента к общему (см. рис. 2).



Рис. 2. Отношение обобщения между актерами

Диаграмма вариантов использования помогает отобразить основные требования к моделируемой системе и обеспечить взаимопонимание функциональности системы между разработчиком и заказчиком.

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

1. 
   Создайте новый проект, выберите шаблон Rational Approach.
   
2. 
   В представлении Use Case выберите диаграмму прецедентов Main.
   
3. 
   Выберите на панели элементов Прецедент и поместите на рабочем поле диаграммы, щелкнув мышью, где должен находиться прецедент. Добавьте имя Прецедента.
   
4. 
   Аналогично создайте элемент актера. Добавьте имя актера.
   
5. 
   Выделите соответствующее отношение на панели элементов и проведите линию от одного элемента к другому, удерживая левую кнопку мыши.
   
6. 
   Введите описание элемента в окно документирования. Для этого выделите элемент модели, откройте редактор Documentation (меню View – Documentation).
   
7. 
   При необходимости создания еще одной диаграммы в контекстном меню папки Use Case Model выберите Add Diagram и далее из списка выберите ту диаграмму, которую хотите добавить.
   

Диаграммы состояний

Изменения в системе можно охарактеризовать следующим образом: объекты изменяют свое состояние в ответ на происходящие события и с течением времени.

Состояние – это ситуация в жизни объекта, в течение которой имеет место выполнение некоторого условия.

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

Ясное представление о поведении объекта повышает вероятность того, что разработчик создаст систему, удовлетворяющую всем требованиям.

Диаграмма состояний показывает состояние одного объекта.

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

Инструкция по созданию диаграммы состояний:

1. 
   В контекстном меню представления Logical View выберите Add Diagram.
   
2. 
   Далее в раскрывшемся списке выберите диаграмму состояний Statechart Diagram.
   

Диаграммы последовательностей

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

Основная идея диаграммы последовательностей – взаимодействие объектов происходит в заданной последовательности, для выполнения которого требуется время (см. рис. 3).

Основной элемент диаграммы последовательностей – это объект.

Объектом описывают реальные, конкретные предметы или абстрактные сущности, содержащие в себе данные и поведение.

Объекты располагаются в верхней части диаграммы, а время изменяется сверху вниз.



Рис. 3. Общий вид диаграммы последовательностей

Для одного потока событий может быть построено несколько диаграмм последовательностей.

Линия жизни объекта – вертикальная пунктирная линия на диаграмме, которая служит для обозначения периода времени, в течение которого объект существует в системе и, следовательно, может потенциально участвовать во всех ее взаимодействиях.

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

Объекты и действующие лица на диаграммах последовательностей обмениваются сообщениями. Сообщения, передаваемые от одного объекта к другому, изображаются стрелками, соединяющими линии жизни этих объектов. Объект может передать сообщение самому себе.

Различают несколько типов сообщений.

Вызов операции (процедуры) – это запрос объекта-отправителя объекту-получателю на выполнение одной из его операций.

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

Если последовательность операций включает создание объекта, его позиция вдоль вертикального направления должна соответствовать времени его создания.

Чтобы отразить на диаграмме момент удаления объекта, в нижней части его линии жизни отображают символ «крест». Объект может разрушаться сам по себе или получать инструкцию на уничтожение от другого объекта.

Каждому типу сообщений соответствует его обозначение, которое представлено в таблице 1.

Таблица 1

Графическое представление типов сообщений

Типы сообщений	Графическое представление
Ответное сообщение	Пунктирная стрелка
Синхронное сообщение	Стрелка с закрашенным наконечником
Асинхронное сообщение	Нежирная стрелка
Создать объект	Стрелка со стереотипом <>
Уничтожить объект	Стрелка со стереотипом <>

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

1. 
   В контекстном меню представления Logical View выберите Add Diagram.
   
2. 
   В открывшемся списке выберите диаграмму последовательности Sequence Diagram.
   
3. 
   Для определения типа сообщения выделите сообщение.
   
4. 
   Откройте редактор свойств.
   
5. 
   Выделите раздел ActionKind.
   
6. 
   В выпадающем списке выберите тип синхронизации.
   

Для детализации прецедента необходимо связать диаграмму с прецедентом, для этого щелкните правой кнопкой мыши по прецеденту, а не по папке Logical View.

Диаграммы видов деятельности

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

С помощью диаграммы видов деятельности описывается все, что происходит во время какой-либо операции или процесса.

Графическая нотация диаграммы видов деятельности похожа на нотацию диаграммы состояний, так как на диаграммах видов деятельности также присутствуют обозначения состояний и переходов.

Графически диаграмма деятельности представляется в форме графа деятельности, вершинами которого являются состояния действия, а дугами – переходы от одного состояния действия к другому.

Два состояния на диаграмме деятельности – начальное и конечное – определяют продолжительность потока. Начальное состояние обязательно должно быть отмечено на диаграмме, оно определяет начало потока. Конечных состояний может быть несколько или ни одного. Оно определяет точку завершения потока. Начальное состояние изображается жирной точкой, а конечное – жирной точкой в окружности (см. рис. 4).



Рис. 4. Обозначения начального и конечного состояния

При моделировании управляющих потоков системы часто необходимо показать места их разделения на основе условного выбора. Выбор на диаграмме показывается ромбом, помещенным на переходе.

Ограничительные условия, от которых зависит выбор направления перехода, помещаются обычно над ромбом. В нотации UML условия записываются в квадратных скобках: [условие] (см. рис. 5).

Синхронизация – это способ показать, что две или более ветвей потока выполняются параллельно.

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

Для моделирования этих особенностей в языке UML используется специальная конструкция, получившая название дорожки.



Рис. 5. Пример диаграммы деятельности

Инструкция построения диаграммы деятельности:

1. 
   В контекстном меню выделенного прецедента выберите Add Diagram.
   
2. 
   В появившемся списке выберите Activity Diagram.