Методические указания. МУ К ПЗ ТРПО ПКС. Методические указания по выполнению практических работ учебной дисциплины мдк 03. 01 Технология разработки программного обеспечения
 Скачать 5.82 Mb.
|
|
Тема 1.5. Организация процесса тестирования программного обеспечения Практическое занятие 10. Тема: Тестирование и отладка программных модулей средствами RAD Studio. Цель работы: ознакомится с методами и видами тестирования ПО и провести тестирование разрабатываемого программного продукта. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, MS Visio, RAD Studio, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы из лабораторной работы №9; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Порядок выполнения работы Разработать чек-лист и тест-кейсы по шаблону, изображенному на рисунке, для тестирования разработанного ПС в соответствии с индивидуальным заданием в Приложении Б. Провести тестирование ПС средствами RAD Studio. Оформить результаты тестирования.  Форма отчета: Отчет по практическому занятию в формате MS Word, содержащий тест-кейс и описание действий. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Раздел 1. Технология разработки программного обеспечения Тема 1.6. Основы объектно-ориентированного представления программных систем Практическое занятие 11-12. Тема: Построение объектно-ориентированных систем средствами MS Studio. Цель работы: изучить структуру программ на основе использования метода объектно-ориентированного программирования. Продолжительность занятия: 4 часа. Оснащение: Персональный компьютер, программа Microsoft Word, Visual Studio, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Порядок выполнения работы Составить алгоритм и программу Student для ввода и вывода данных по студентам (фамилия, имя, группа, стипендия). Программа должна иметь класс, объект, операторы ввода и вывода данных. Данные вводить во время работы программы. 1. Построить алгоритм реализации программы в виде блок-схем. 2. Разработать программу в Visual Studio на основе ООП с использованием классов и объектов (язык программирования С#). 3. Оформить отчет выполненной работы. Форма отчета: Программа на языке C#, отчет о проделанной работе с блок схемой и ее описанием. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Литература: 1. Гниденко, И. Г. Технология разработки программного обеспечения: учебное пособие для среднего профессионального образования / И. Г. Гниденко, Ф. Ф. Павлов, Д. Ю. Федоров. — Москва : Издательство Юрайт, 2020. — 235 с. — (Профессиональное образование). —ISBN 978-5-534-05047-9. — Текст : электронный // ЭБС Юрайт [сайт]. —URL: https://urait.ru/bcode/453640 Раздел 1. Технология разработки программного обеспечения Тема 1.6. Основы объектно-ориентированного представления программных систем Практическое занятие 13. Тема: Построение объектно-ориентированных систем средствами RAD Studio. Цель работы: изучить структуру программ на основе использования метода объектно-ориентированного программирования. Продолжительность занятия: 2 часа. Оснащение: Персональный компьютер, программа Microsoft Word, RAD Studio, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Порядок выполнения работы Составить программу Teacher для ввода и вывода данных по студентам (фамилия, имя, кабинет, дисциплины). Программа должна иметь класс, объект, операторы ввода и вывода данных. Данные вводить во время работы программы. 1. Разработать программу в RAD Studio на основе ООП с использованием классов и объектов (язык программирования С#). 2. Оформить отчет выполненной работы. Форма отчета: Программа на языке C#, отчет о проделанной. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Литература: 1. Гниденко, И. Г. Технология разработки программного обеспечения: учебное пособие для среднего профессионального образования / И. Г. Гниденко, Ф. Ф. Павлов, Д. Ю. Федоров. — Москва : Издательство Юрайт, 2020. — 235 с. — (Профессиональное образование). —ISBN 978-5-534-05047-9. — Текст : электронный // ЭБС Юрайт [сайт]. —URL: https://urait.ru/bcode/453640 Раздел 1. Технология разработки программного обеспечения Тема 1.7. Описание интеграции Практическое занятие 14-16. Тема: Разработка схемы интеграции на примере отдельно взятой организации. Цель работы: ознакомится с видами и способами интеграции, разработать схему интеграции информационных систем. Продолжительность занятия: 6 часа. Оснащение: Персональный компьютер, программа Microsoft Word, методические указания к практическим занятиям. Методические указания по выполнению работы: изучить краткие теоретические материалы по теме практического занятия; изучить условие задания практического занятия; при выполнении работы соблюдать последовательность действий; оформить отчет по практической работе Теоретические сведения В компании используются три независимые информационные системы: «Складская система» (учет и анализ товародвижений на складе), «CRM-система» (учет и анализ продаж и других взаимоотношений с клиентами) и «Бухгалтерская система» (бухгалтерский учет и финансовый анализ). Между ними нет информационного обмена.  Это приводит к тому, что менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему, вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов. В такой ситуации присутствует большой документооборот между менеджерами, бухгалтерией и складом, а также двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской). Если посчитать затраты оплачиваемого компанией времени сотрудников на выполнение дублирующихся процедур в разных системах (выделены красным на схеме), то может получиться ощутимая доля в общих издержках фирмы. Вертикальная интеграция В соответствии с этим подходом системы интегрируются по принципу функциональных экспертиз. Например, в данном случае выделены две экспертизы: оперативный учет и бухгалтерской учет. При этом бухгалтерский учет находится по вертикали выше оперативного учета. В нашем примере подсистемы оперативного учета поставляют данные подсистеме бухгалтерского учета.  Это позволяет существенно сократить трудозатраты на дублирующиеся и бумажные операции, однако, есть два отягчающих момента. Во-первых, такую систему крайне трудно расширять функционально. Например, компания может захотеть создать подсистему-экспертизу «Аналитика», которая по вертикали будет расположена над экспертизой «Бухгалтерский учет». Эта экспертиза в значительной степени основана на данных «Оперативного учета». Поэтому, помимо собственно разработки подсистемы «Аналитика» придется дорабатывать подсистему «Бухгалтерский учет» для того, чтобы она получала и хранила для нее из «Оперативного учета» дополнительную информацию. Во-вторых, остаются значительные возможности по интеграции в рамках одной функциональной экспертизы. Интеграция «многие ко многим» (звезда, спагетти) В рамках данного подхода каждая из используемых в компании подсистем может при необходимости обращаться к функционалу любой другой подсистемы, при этом каждая из подсистем может также использоваться любой другой подсистемой. Такой тип отношений между элементами называется «многие ко многим».  В этом случаем имеем место с практически неограниченными возможностями интеграции подсистем между собой (естественно, если подсистемы технологически позволяют делать это). Но, с другой стороны, затраты на поддержку такой интеграционной схемы экспоненциально растут при увеличении числа интегрированных подсистем. Например, если в нашем случае потребуется изменить что-то в бухгалтерской подсистеме (допустим, изменить ее объектную модель), то это может привести к необходимости переработки все остальных подсистем использующих ее, т.к. вызовы старой объектной модели перестанут работать. Для трех взаимодействующих систем это может быт не так критично, а вот для тридцати весьма и весьма. Горизонтальная интеграция Данный подход заключается в использования специализированного «промежуточного» (middleware) ПО - так называемой корпоративной сервисной шине. Основная задача этого ПО заключается в хранении репозитория функционала корпоративных приложений, подключенных к ней, и обеспечение возможности использования этих функций другими приложениями, также подключенными к этой шине. Взаимодействие между приложениями могут, например, происходить в форме обмена сообщениями или вызова опубликованных функций в виде Веб-сервисов. Подключение системы к шине производится путем создании специального адаптера для каждой системы. После этого «опубликованные» функции системы становятся доступными другим подключенным системам.  Например, CRM-система при подключении к шине публикует свои функции по работе с клиентской базой данных. Шина обеспечивает возможность их использования бухгалтерской и складской системами. В свою очередь CRM-система получает возможность с бухгалтерскими и складскими данными. Преимуществом данного подхода является то, что сами системы могут заменяться в рамках существующей спецификации опубликованных функций. При этом никаких изменений в других системах не требуется. Кроме того, подключение новой системы в достаточной степени стандартизировано и упрощено. Например, имеется возможность подключить новую систему «Аналитика», которая сразу получит доступ ко всем остальным системам. Безусловно, самая лучшая интеграция – это отсутствие необходимости в ней. Например, все представленные выше подсистемы могут быть реализованы в виде функциональных модулей одной ERP-системы какого-либо вендора. В этом случае необходимость в интеграции отпадает, т.к. система уже изначально единая, обеспечивающая гораздо большую связность между функциональными модулями чем любой из приведенных выше вариантов интеграции между различными системами.  Объекты и методы интеграции систем Ранее при описании подходов к интеграции систем мы рассматривали каждую информационную систему как «неделимый» объект. Однако, информационная система представляет из себя совокупность нескольких компонентов, поэтому, говоря об интеграции информационных систем, правильнее говорить об интеграции составляющих их компонентов. Поэтому, интеграция информационных систем заключается в интеграции одного или нескольких компонентов интегрируемых информационных систем (объектов интеграции): Интеграция платформ Интеграция данных Интеграция приложений Интеграция бизнес-процессов Целями интеграции платформ являются: Обеспечение возможности взаимодействия между приложениями, работающими на различных программно-аппаратных платформах (например, между приложениями, работающими на серверах Windows, Solaris, Linux и др.). Обеспечение возможности работы приложений, разработанных для одной программно-аппаратной платформы, на других программно-аппаратных платформах (например, приложений Windows на платформах Linux, Solaris и др.). Существует несколько подходов, направленных на достижение этих целей. В рамках каждого из подходов существуют различные технологии: Удаленный вызов процедур (RPC, Web-сервисы, REST и пр) ПО промежуточного слоя (Microsoft.Net, Java Runtime) Виртуализация Технологии удаленного вызова процедур (в широком смысле под процедурой понимается некоторая функциональность приложения) позволяют опубликовать процедуру и обеспечить возможность ее вызова (передачи входящих параметров и получения выходных результатов) для приложений, работающих на других платформах. Концепция программного обеспечения промежуточного слоя (framework, среда исполнения, виртуальная машина) состоит в разработке прикладного ПО не с использованием сервисов конкретной операционной системы (например, Windows API), а с использованием сервисов ПО промежуточного слоя. Разработчиками ПО промежуточного слоя создаются ее реализации под различные операционные системы, которые транслируют вызовы соответствующих функций фрэйворка в вызовы соответствующей операционной системы. Типичным примером является технология Java Runtime Environment. Приложения, разработанные для этой технологии работают на любых программно-аппаратных платформах (Windows, Linux и др.) без каких-либо доработок самих приложений. Аналогичные возможности предоставляет среда Microsoft .Net Framework. Интересной и современной концепцией является «виртуализация». К интеграции платформ она имеет отношение постольку, поскольку позволяет существенно упростить использования различных платформ и, соответственно, использование систем, требующих для своего функционирования наличия конкретных платформ. Если без виртуализации возможно одновременное функционирование N операционных сред на N серверов, то применение технологий виртуализации позволяет обеспечить функционирование N операционных сред на M серверов. Если N > M – это позволяет сократить расходы на аппаратное обеспечение путем его более эффективного использования. Если N < M – это простой путь увеличения производительности систем. Например, виртуализация позволяет развернуть и одновременно использовать на одном физическом сервере несколько операционных систем: Windows, Linux и др. На каждом из таких «виртуальных» серверов могут быть развернуты соответствующие системы, которые будут доступны одновременно. Примеры технологий виртуализации: Microsoft Hyper-V, KVM, OpenVZ, Virtuozzo, VMware, Xen и пр. Интеграция данных По определению информационная система работает с данными. В подавляющем большинстве случаев система имеет в своем составе базу данных для их хранения. Интеграция на уровне данных предполагает совместное использования данных различных систем. Интеграция данных может оказаться проще, чем интеграция приложений, т.к. промышленные СУБД, в которых обычно хранят данные информационные системы, имеют развитые возможности программного доступа к данным из других приложений. Сами приложения при этом могут иметь весьма ограниченные возможности программного (вне собственного пользовательского интерфейса) использования своей функциональности внешними системами. Подходы к интеграции данных: Универсальный доступ к данным Хранилища данных Технологии универсального доступа к данным позволяют обеспечить единообразный доступ к данным различных СУБД. Посредником для работы с конкретной СУБД в данном случае является драйвер для соответствующей СУБД. Например, один и тот же SQL-запрос на выборку данных SELECT * FROM TTABLE может быть использован на выборку данных из таблицы TTABLE, хранящейся в различных СУБД. Это позволяет абстрагироваться от специфики конкретных СУБД и легко осуществлять интеграцию данных, хранящихся в различных СУБД. Наиболее распространенные технологии этого класса: ODBC, JDBC, ADO.NET. Кроме того, на сегодняшний день широко распространены технологии объектно-реляционного отображения (ORM), которые также позволяют абстрагироваться от деталей взаимодействия с конкретными СУБД. Примерами таких технологий являются Entity Framework, Hibernate, NHibernate, Flexberry ORM. Концепция хранилищ данных состоит в создании корпоративного хранилища данных. Хранилище данных – база данных, хранящая в себе данные, собираемые из баз данных различных информационных систем, для целей их дальнейшего анализа. Например, может быть создано единое хранилище данных компании, в которое собрана информация из бухгалтерской, оперативной системы, внешних систем партнеров компаний. Для создания хранилищ данных используются технологии (OLAP), отличные от технологий создания оперативных БД (OLTP). В основном это делается для повышения производительности выполнения сложных аналитических запросов по многим параметрам (многомерные запросы). Подходы к созданию и наполнению хранилищ данных отражены в парадигме ETL (extraction, transformation, loading = извлечение, преобразование и загрузка). Технологии и инструментальные средства анализа больших массивов данных с целью выявления закономерностей предметной области объединяются понятием «Data Mining». Термин для совокупности технологий хранилищ данных и инструментальных средств, обеспечивающих перевод транзакционной деловой информации в человекочитаемую форму, пригодную для бизнес-анализа – «Business Intelligence». Интеграция приложений Интеграция на уровне приложений подразумевает использование готовых функций приложений другими приложениями. Например, разрабатывая систему электронного документооборота, существует возможность использовать в рамках этой системы в качестве текстового редактора MS Word вместо того, чтобы разрабатывать свой собственный текстовый редактор. Или, например, ПО Call-центра, получив входящий звонок от клиента, имеет возможность обратиться к функции биллинговой системы по проверке баланса (на входе – номер телефона абонента, на выходе – его текущий баланс) и, в зависимости от состояния баланса соединить его с оператором или автоматически проинформировать о необходимости пополнить свой счет. При этом структура база данных биллинговой системы является ее внутренней информацией, публикуются конкретные функции, позволяющие другим системам работать с конкретными данными. Стоит упомянуть следующие подходы к интеграции приложений: Интерфейсы прикладного программирования Обмен сообщениями (Корпоративная сервисная шина) Сервис-ориентированная архитектура Интеграция пользовательских интерфейсов Программный интерфейс конкретной системы представляет собой «опубликованный» функционал этой системы, который может быть использован извне. Функционал может публиковаться в виде набора функций (пример – Windows API) или в виде объектной модели (объекты со свойствами и методами, пример – объектные модели приложений Microsoft Office). В большинстве случае интеграция нескольких систем заключается в передаче информации между ними, например, в форме запрос-ответ. Если системы функционируют в гетерогенных распределенных средах, то принципиальное значение имеет обеспечение гарантированности, безопасности, управляемости доставки информации между приложениями. Эти и другие принципы реализуются в корпоративных системах обмена сообщениями. В данном случае речь идет об обмене сообщениями между приложениями, а не людьми, как, например, в случае E-mail или мессенджеров. Функциональность этих систем достаточно прозрачна – прием сообщения от одного приложения, транспортировка по заданным правилам и передача этого сообщения другому приложению. При этом может производиться шифрование сообщений (для невозможности прочтения данных в процессе транспортировки), цифровая подпись (для защиты от умышленного изменения данных во время пути сообщения), настройка подписки (для отправки одного сообщения сразу нескольким приложениям), определение метаданных для сообщений (для облегчения использования сообщений со сложной структурой содержимого) и др. Сервис-ориентированная архитектура (SOA) является логическим продолжением концепции Веб-сервисов, которая состоит в публикации функциональных блоков какого-либо приложения в виде, позволяющем получить к ним доступ другим приложением через Веб. Веб (протокол HTTP) в данном случае привлекателен ввиду возможности его использования и, соответственно, использования опубликованного в Веб-приложений функционала на любых программно-аппаратных платформах. Веб-сервис – небольшая программная надстройка над функционалом приложения, преобразующая вызовы, получаемые через Веб, во внутренние вызовы функций приложения и возвращающая результаты обратно. Основными идеями SOA являются: Публикация функционала корпоративных приложений в виде Веб-сервисов. Упорядочивание опубликованных сервисов в виде каталога. Построение на основе Веб-сервисов новых приложений путем их комбинации. Цена создания новых приложений на основе существующих Веб-сервисов будет существенно ниже, чем разработка приложений «с нуля» или обширная интеграция с другими системами. Например, в компании (оператор связи) существует система Service Desk (техническая поддержка абонентов) и биллинговая система (тарификация услуг). Перед компанией стоит задача сделать новую систему «Личный кабинет абонента», в которой абонент мог бы через Интернет просмотреть состояние своего счета и сообщить о неисправности. Для этого компания вместо того, чтобы создавать «Личный кабинет» с собственной базой данных, синхронизируемой с БД биллинговой системы и системы Service Desk, использует готовые Web-сервисы «Карточка абонента» (опубликованный функционал биллинговой системы) и «Создать заявку в техподдержку» (опубликованный функционал системы Service Desk). Очевидно, что вся работа по новому приложению «Личный кабинет» состоит лишь в создании Веб-интерфейса пользователя на сайте компании. Также часто используется следующий подход – интеграция пользовательских интерфейсов. Например, для создания приложений «одного окна». Простейший пример – фреймы на Веб-странице. Внутри каждого фрейма содержится отдельное Веб-приложение. Благодаря фреймам, все эти приложения отображаются на экране одновременно. Пользовательские интерфейсы Веб-приложений легко интегрируются, однако, существуют возможности интегрировать и «классические» пользовательские интерфейсы и их фрагменты (ActiveX). Интеграция бизнес-процессов Наиболее целостным подходом к интеграции систем является интеграции на уровне бизнес-процессов. В рамках интеграции бизнес-процессов происходит и интеграция приложений, и интеграция данных и, что не менее важно, людей, вовлеченных в этот бизнес-процесс. Интеграция на уровне бизнес-процессов является наиболее «естественной» для организаций, так как их деятельность состоит, прежде всего, именно из бизнес-процессов, а не приложений, баз данных и платформ. Идеи, лежащие в основе интеграции бизнес-процессов, достаточно просты: Составить сценарий некоторого бизнес-процесса, происходящего в организации, описать в нем операции взаимодействия пользователей с различными системами и систем между собой. Таким образом, бизнес-процесс является элементом, логически интегрирующим различные системы. Сценарий создается при помощи специализированного программного продукта, который далее будет управлять ходом этого бизнес-процесса согласно сценарию. Операции взаимодействия с системами в рамках бизнес-процесса детально описываются в терминах информационного обмена: форматы обмена, используемые сервисы, приложения, события, правила, политики и т.п. К интегрирующему программному обеспечению, при помощи которого описан сценарий бизнес-процесса, подключаются посредством адаптеров интегрируемые системы, вовлеченные в бизнес-процесс. Таким образом, становится возможным автоматизированный информационный обмен между системами. Готовый к выполнению бизнес-процесс выводится на «пульт управления» менеджера, при помощи которого, он может запускать и останавливать бизнес-процессы, отслеживать их состояние, вводить данные и принимать решения на отдельных операциях бизнес-процессов, требующих участия человека и др. Взаимодействия между системами, не требующее участия человека осуществляется автоматически интегрирующим ПО. Порядок выполнения работы 1. Составить схему интеграции приложения, в соответствии с вариантом из приложения Б и описать ее. 2.Оформить отчет о проделанной работе Форма отчета: Схема интеграции приложения. Место проведения самоподготовки: кабинет АНПОО «Кубанский ИПО» Раздел 1. Технология разработки программного обеспечения |