Отчёт Производственная практика ПМ02. Отчёт ПП ПМ02. Отчет по практике вид практики производственная практика (по профилю специальности) в составе

• Название: Отчет по практике вид практики производственная практика (по профилю специальности) в составе
• Анкор: Отчёт Производственная практика ПМ02
• Дата: 16.12.2022
• Размер: 267.93 Kb.
• Имя файла: Отчёт ПП ПМ02.docx
• Тип: Отчет; #847707
• страница: 7 из 7

4.1Составление спецификаций программ с использованием языка визуального проектирования.

SDL (язык спецификации и описания) - это язык для спецификаций и описаний. Спецификация означает точное определение системы или ее части, а описание означает неформальную спецификацию, которая показывает тот или иной аспект системы. Язык SDL предназначен для разработки распределенных систем, управляемых событиями. Он был разработан международным комитетом ITU с 1976 года и является одним из самых надежных в компьютерных технологиях. Есть два варианта этого языка - текстовый (SDL / PR) и графический (SDL / GR), семантика которых одинакова, за исключением некоторых тонкостей.

Метод OOSE (Object-Oriented Software Engineering). Основная задача этого подхода: приблизить компьютерную инженерию к типовому промышленному процессу, каковым является, например, строительство (Рис. 7). Основополагающий принцип подхода – объектная ориентированность, как для анализа, проектирования, программирования, так и для описания процесса разработки ПО в целом. Подход предназначен, в первую очередь, для разработки больших систем.


Рис. 7 Внешний вид структуры OOSE


Рис. 8 Внешний вид структуры OOSE


OOSE предлагает компактное описание структуры компьютерной инженерии, в основе которой лежит концепция архитектуры (рисунок 9). Эта концепция включает в себя базовые концепции и методы, определяемые как объектная ориентация, определенный набор полуформальных моделей с графическими обозначениями, которые предоставляются для описания разрабатываемой системы. Выше приведен метод - линейная последовательность шагов, процедура создания идеальной системы с нуля. Метод описывает, как применить архитектуру к проектированию системы. Над методом находится процесс масштабирования метода. В отличие от метода, он, во-первых, ориентирован на итеративную разработку программного обеспечения (а метод является линейным), а во-вторых, адаптирован для промышленного использования (метод представляет собой идеальную последовательность шагов). Наконец, инструменты - это воплощение архитектуры, метода и процесса в конкретном программном продукте - инструмент CASE, используемый для разработки системы. Анализ и проектирование в OOSE основаны на подходе варианта использования, при котором объекты выбираются путем их написания. Предлагается несколько объектных моделей для разных этапов разработки системы и, как в SDL, блочного анализа.

Метод Бутча. Метод описывает объектную модель и визуальные инструменты, а также сам процесс разработки программного обеспечения с целями, действиями, результатами и показателями прогресса. Кроме того, внимание было уделено организационным вопросам разработки программного обеспечения и влиянию на них объектно-ориентированного подхода. Метод более формализован, чем OOSE, формальные обозначения отделены от описания процесса их использования. Метод основан на одно-классной модели. Предлагается использовать его на различных этапах разработки, чтобы получить одну системную спецификацию, которая меняется от одной фазы разработки к другой. Основа иерархии понятий в этом методе - методология и методика.

«Методология - это набор методов, которые используются на протяжении всего жизненного цикла разработки программного обеспечения и связаны одной философской концепцией». Концепция Буча - это объектно-ориентированный взгляд на мир. «Метод - это четко определенный процесс создания набора моделей с использованием четко определенных обозначений; эти модели описывают различные аспекты программного обеспечения. Буч называет свой подход методом и делит его на три части: нотация, процесс и прагматика. В основе метода лежит умение рассматривать разрабатываемую систему с разных точек зрения. Результат такого рассмотрения называется системной моделью. Буч различает следующие типы моделей: логические, физические, статические и динамические.

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

Прагматика в контексте метода Буча - это та специфика объектно-ориентированного подхода, которая проявляется в организационных вопросах разработки программного обеспечения: управление проектами, кадры, риски, версии системы, специфические программные инструменты для поддержки разработки программного обеспечения и т. Д. Эти проблемы связаны с тем, что проектирование и анализ не являются строгой и формально определенной наукой; для решения значительной части проблем не удается найти подходящие формализации и остается только обсудить их на неформальном уровне. Таким образом, эта часть метода является наиболее неформальной.

4.2. Построение диаграмм вариантов использования системы, последовательности системы, состояний системы, деятельности системы.

Диаграмма вариантов использования является самым общим представлением функциональных требований к системе. Для последующего проектирования системы требуются более конкретные детали, которые описываются в документе, называемом сценарием варианта использования или потоком событий (flow of events). Сценарий подробно документирует процесс взаимодействия действующего лица с системой, реализуемого в рамках варианта использования. Основной поток событий описывает нормальный ход событий (при отсутствии ошибок). Альтернативные потоки описывают отклонения от нормального хода событий (ошибочные ситуации) и их обработку.

Достоинства модели вариантов использования заключаются в том, что она:

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

4.3. Построение диаграмм классов системы.

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

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





Рис. 9 Графический вид класса


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




Рис. 10 Графический пример класса


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

Обязательным элементом присвоения класса на диаграмме является его имя. Должен быть уникальным в пакете. Если класс абстрактный, его имя будет написано курсивом. Абстрактный класс - это класс, из которого нельзя создавать объекты. Эти классы используются в качестве шаблона для дочерних классов при наследовании.

Ниже будет приведен пример, а также правила и рекомендации по построению и развитию диаграммы (рис. 11).

При оформлении схемы необходимо руководствоваться следующими правилами и рекомендациями.

1. 
   Диаграмма классов разработана на основе диаграммы классов анализа.
   
2. 
   Для классов должны быть определены и указаны все атрибуты и методы. Его спецификация, как правило, осуществляется с учетом выбранного языка программирования.
   
3. 
   При определении методов рекомендуется использовать сообщения из ранее разработанных диаграмм последовательности и коммуникаций.
   
4. 
   Подробный проект предельных классов обычно не требуется. Современные инструменты разработки поддерживают визуальную разработку интерфейса системы - меню, диалоговые формы, элементы диалоговых окон, панелей инструментов и т. Д. Прототипы пользовательского интерфейса используются в качестве исходных данных для их проектирования. В связи с этим при проектировании таких классов основное внимание следует уделять характеристикам отображения информации и конкретным операциям, которые происходят во время диалога пользователя с системой. Граничные классы, определяющие интерфейс для взаимодействия с другими системами, требуют детального проектирования.
   
5. 
   Для проектирования классов сущностей вы можете использовать подходы, использованные при проектировании базы данных, особенно если данные будут храниться в таблицах базы данных. Если представление данных в базе данных и в классах отличается друг от друга и в качестве хранилища информации будет использоваться реляционная база данных, рекомендуется разработать отдельную диаграмму классов, описывающую состав и структуру базы данных. Современные инструменты CASE позволяют разрабатывать такие диаграммы и синхронизировать их с базой данных.
   
6. 
   Несмотря на то, что каждому объекту автоматически присваивается уникальный идентификатор во время выполнения программы, рекомендуется, чтобы классы сущностей явно определяли атрибуты, в которых хранятся значения первичных ключей.
   
7. 
   В отличие от реляционных баз данных, в классах приветствуется использование многозначных атрибутов в форме массивов, наборов, списков и т. д.
   
8. 
   Классы управления следует разрабатывать только в случае крайней необходимости - для обработки сложных взаимодействий объектов, реализации сложной бизнес-логики и вычислений, проверки целостности объекта и т. Д. В противном случае лучше распределить функциональность этого класса между соответствующими граничными классами и классами пространственных объектов.
   
9. 
   Рекомендуется установить для атрибутов видимость закрытая или защищенная. Если необходимо прочитать значение такого атрибута из объектов других классов, то для этого должен быть предусмотрен метод get, а если возможность установить новое значение - метод set.
   
10. 
    Для методов публичная видимость должна определяться только в случае крайней необходимости.
    
11. 
    Из-за большого количества классов в системе рекомендуется разрабатывать диаграммы классов отдельно для каждого пакета. По умолчанию инструменты CASE поддерживают этот подход к проектированию, хотя они позволяют разрабатывать диаграммы, содержащие классы из разных пакетов.
    
12. 
    При разработке диаграмм и отдельных классов рекомендуется использовать шаблоны дизайна.
    

Рис. 11 Пример построения диаграммы классов

4.4. Построение диаграмм размещения системы.

Диаграмма развертывания - это один из типов диаграмм, поддерживаемых дизайнером Flexberry.

Корпоративным приложениям часто требуется какая-то ИТ-инфраструктура для работы, хранения информации в базах данных, расположенных где-то на серверах компании, вызова веб-сервисов, использования общих ресурсов и т. Д. В этих случаях полезно иметь графическое представление инфраструктуры, в которой будет развернуто приложение. Для этого нужны диаграммы развертывания (рис. 12), которые иногда называют диаграммами развертывания.



Рис. 12 Пример диаграммы развертывания


Такие диаграммы имеет смысл создавать только для аппаратных и программных систем, тогда как UML позволяет создавать модели любой системы, не обязательно компьютеров.

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

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

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

Используются «трехмерные» обозначения: узлы системы обозначены кубами. Все остальные символы в UML представляют собой плоские формы.

ЗАКЛЮЧЕНИЕ

За время прохождения учебной и производственной от Колледжа «Московский университет имени С.Ю. Витте», я получил огромный опыт работы в коллективе, я смог на практике увидеть и попробовать использовать все полученные мною знания. Я укрепил свои знания в плане работы с компьютерами, компьютерными системами, стал немного разбираться в проектной деятельности и бизнес-процессах, и бизнес-функциях. Изучил новую для себя ОС – ГосЛинукс. Также научился работать с периферийными устройствами. Эта практика научила меня пунктуальности, внимательности, исполнительности, пониманию своей будущей рабочей деятельности, составлению конструктивного содержания задач и сдержанности, написанию отчета. Я считаю, что я стал ответственным, терпеливым и надеюсь, что в будущем смогу стать хорошим специалистом.

Список использованной литературы

Основные источники:

1.Зубкова, Т.М. Технология разработки программного обеспечения : учебное пособие / Т.М. Зубкова ; Оренбургский государственный университет, Кафедра программного обеспечения вычислительной техники и автоматизированных систем. – Оренбург : Оренбургский государственный университет, 2017. – 469 с. : ил. – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=485553

2. Флоренсов, А.Н. Системное программное обеспечение : учебное пособие / А.Н. Флоренсов ; Минобрнауки России, Омский государственный технический университет. – Омск : Омский государственный технический университет (ОмГТУ), 2017. – 139 с. – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=493301

Дополнительные источники:

1.Смирнов, А.А. Прикладное программное обеспечение : учебное пособие : [16+] / А.А. Смирнов. – Москва ; Берлин : Директ-Медиа, 2017. – 358 с. : ил., табл. – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=457616

2.Курчеева, Г.И. Информационное и программное обеспечение электронного бизнеса : учебное пособие : [16+] / Г.И. Курчеева, М.А. Бакаев, В.А. Хворостов ; Новосибирский государственный технический университет. – Новосибирск : Новосибирский государственный технический университет, 2018. – 107 с. : ил., табл. – Режим доступа: по подписке. – URL: http://biblioclub.ru/index.php?page=book&id=576386

Интернет-ресурсы:

1. Справочный онлайн ресурс по веб-технологиям для разного уровня подготовки. – Режим доступа: https://html5book.ru