Задания. Департамент образования, науки и молодежной политики Воронежской области Государственное бюджетное профессиональное образовательное учреждение Воронежской области Лискинский промышленнотранспортный техникум имени А. К. Лысенко
 Скачать 7.79 Mb.
|
|
Цель: научиться анализировать методологий проектирования По завершению практического занятия студент должен уметь: анализировать методологий проектирования Продолжительность: 5 аудиторных часа (225 минут) Необходимые принадлежности Компьютеры. Задание Наибольшее распространение при этом получают готовые решения, предлагаемые компаниями 1С или SAP (Systems, Applications and Products in Data Processing), а также системы моделирования процессов в различных нотациях, на которых базируются программные средства проектирования. Подавляющее большинство современных программ позволяют осуществлять автоматическую генерацию программного кода спроектированной информационной системы, что позволяет получать готовый продукт, реализованный, как правило, в форме веб-приложения. При этом открытым остается вопрос качества генерируемого кода, его понятности и читабельности. Наиболее широко распространены следующие нотации: стандарты IDEF (Integration Definition for Function Modeling), в частности IDEF0 и IDEF3, диаграммы потоков данных DFD (Data Flow Diagram), унифицированный язык моделирования UML (Unified Modeling Language) и нотация BPMN (Business Process Modeling Notation), применяемая для моделирования бизнес-процессов. В настоящее время стандарт IDEF0 считается устаревающим и наиболее часто используется только лишь при описании системы в рамках предпроектного исследования. Постановка задачи Основной целью работы являлось исследование допустимости применения стандартов разного уровня абстракции для решения аналогичных задач. В рамках проводимого анализа была поставлена задача проектирования АСОИУ (автоматизированной системы обработки информации и управления), основного процесса документооборота для регистратуры больницы, осуществляемого с помощью программных средств моделирования различных нотаций. Для этого были произведены сопоставление и анализ стандартов UML и BPMN. Помимо теоретического анализа было проведено практическое сравнение нотаций на примере двух систем проектирования для заданного объекта автоматизации. Таким образом, ключевым методом исследования является сравнение различных этапов проектирования информационных систем в разных нотациях на примере двух программ, реализующих работу с этими стандартами. Выбор данной предметной области обусловлен тем, что она имеет достаточно строгую и упорядоченную структуру, но при этом ее внутренние процессы не являются стандартными. При этом вышеуказанные стандарты для проектирования информационных систем в выбранной сфере, как правило, не используются. В качестве основных критериев сравнения выбраны параметры, которые наиболее точно определяют качество и адекватность проектируемой модели, а также степень ее соответствия реальной системе, доступности, понятности и практической полезности. К таким критериям относятся, прежде всего, выразительная мощь стандарта визуального проектирования, структурированность, возможность создания готовой информационной системы, ее практического применения, удобство, скорость разработки и внедрения и т.д. Рассмотрение стандартов UML – согласно одному из определений – язык графического описания для объектного моделирования процессов, в частности производственных, а также бизнес-процессов, системного проектирования, процессов разработки различных систем, программного обеспечения, а также описания и отображения организационных структур [1]. UML является открытым стандартом, использующим визуальные графические обозначения для проектирования абстрактной модели системы, рассматривая ее с точки зрения конструктивного описания. При этом система рассматривается как набор взаимосвязанных сущностей – объектов [1]. Технология визуального моделирования предоставляет возможность упрощенной и наглядной работы со сложными системами, позволяя более детально рассматривать как систему в целом, так и ее отдельные компоненты. Основным преимуществом унифицированного языка является то, что он, прежде всего, является объектно-ориентированным, в результате чего методы описания результатов анализа и проектирования системы структурно близки к методам непосредственного программирования на современных объектно-ориентированных языках [2]. Вторым плюсом применения визуальных моделей при проектировании АСОИУ является то, что они позволяют организовать эффективное взаимодействие между участниками процесса анализа и автоматизации системы: заказчиками, аналитиками и разработчиками. BPMN (Business Process Modeling Notation) – спецификация, содержащая графическую нотацию описания бизнес-процессов на диаграммах, называемых BPD (Business Process Diagram). Данная нотация, подобно прочим, призвана обеспечить взаимопонимание между всеми участниками процесса анализа и автоматизации системы [5]. Нотации UML и BPMN не являются взаимоисключающими. Несмотря на идентичность некоторых функций, схемы процессов в этих нотациях отличаются по визуальному представлению информации. Основным отличием данных стандартов является то, что UML рассматривает систему в виде взаимосвязанных объектов – классов, образующих ее, и их взаимодействия, в то время как в BPMN система описывается на более высоком абстрактном уровне – уровне бизнес-процессов. Главным в данной нотации являются процессы, а не объекты [5]. Следует отметить, что сравнение данных методологий уже неоднократно производилось. По результатам проведенных исследований отмечалось, что в плане выразительной мощности оба стандарта приблизительно одинаково эффективны. Однако, как уже было упомянуто, BPMN является более высокоуровневой нотацией, рассматривающей систему с точки зрения основного процесса. Это заключает в себе определенный минус, поскольку описание организационной структуры и модели данных затрудняется. Однако на сегодняшний день существуют BPMS (Business Process Modeling System), позволяющие описывать не только процессы организации, но также структуру и модель данных. Выбор средств разработки На сегодняшний день существует большое разнообразие программного обеспечения для работы с рассматриваемыми стандартами. В ходе работы был проведен сравнительный анализ существующего программного обеспечения. По результату анализа выбор был сделан в пользу open-source системы ArgoUML. Данная система является кроссплатформенной, иными словами может работать практически на всех платформах [3]. Среди BPMS выбор был сделан в пользу системы Bizagi. Данная BPM-система направлена на моделирование, исполнение, автоматизацию и анализ бизнес-процессов. Основной ее особенностью среди многих прочих BPMS является возможность описания модели данных для будущей информационной системы. Разработка системы При проектировании АСОИУ выбранного к рассмотрению объекта первоначально была разработана действующая модель с помощью UML. По данной модели была осуществлена генерация программного кода и получено работоспособное приложение автоматизации документооборота медицинского учреждения. Следующим шагом было осуществлено проектирование аналогичной системы средствами BPMN системы Bizagi. Обе реализованные системы являются работоспособными. Следует отметить, что поскольку моделирование объекта автоматизации производилось упрощенно, разрабатываемые модели не включали в себя отражение специфичных функций, присущих системе. За счет этого можно было явно проследить параллели различных диаграмм нотаций UML и BPMN. При проектировании информационной системы в среде ArgoUML был создан проект, содержащий две стандартные для UML диаграммы: классов и автоматов (состояний).  Рис. 1. Диаграмма классов  Рис. 2. Диаграмма состояний  Рис. 3. Схема документооборота Диаграмма классов UML позволяет обозначать отношения между классами и их экземплярами, абстрагируясь от предметной области и работая исключительно с сущностями, реализуя принцип объектно-ориентированного программирования. Полученная схема является моделью данных будущего приложения (рис. 1). Эта диаграмма является основным уровнем описания структуры организации и работы системы [2]. Диаграмма состояний – это один из способов детального описания системы в определенные различные состояния и переходов между ними [2] (рис. 2). В рассматриваемом примере для реализации системы оборота медицинской карты данных достаточно использования этих двух диаграмм [6, 7]. Субъектами – участниками процесса документооборота являются: регистратор, сестра приемного отделения, врач приемного отделения, диспетчер отделения, лечащий врач, патологоанатом (рис. 3) [6]. По окончанию проектирования двух диаграмм проект был экспортирован в формат XMI (XML Metadata Interchange – стандарт обмена метаданными с помощью языка расширенной разметки XML), и с помощью системы Plone было сгенерировано готовое приложение [4]. Полученное веб-приложение представляет собой интерфейс для взаимодействия с базой данных. Далее было спроектировано аналогичное приложение средствами Bizagi Studio. Первым шагом была создана диаграмма процесса в нотации BPM (рис. 4). Для выбранной предметной области можно четко проследить связь этой диаграммы и диаграммы состояний нотации UML. Субъекты, взаимодействующие в данной системе (роли), отражены на «дорожках» процесса. Описанные функции субъектов в диаграмме состояний UML находят отражение в блоках задач и условных переходах. Процесс можно поделить на несколько крупных блоков: Регистрация, Осмотр, Лечение и Выписка. Наиболее значимым при проектировании информационной системы, помимо моделирования процесса, является второй шаг разработки в среде Bizagi Studio – создание модели данных будущего приложения (рис. 5). Данный шаг в рассматриваемой системе эквивалентен схеме взаимодействия объектов, описываемой на диаграмме классов UML. Для каждой задачи впоследствии создаются формы интерфейса на третьем шаге проектирования. Логика задач и условных переходов описывается на четвертом шаге. После выполнения оставшихся шагов система автоматически генерирует программный код и создает приложение, доступное в браузере.  Рис. 4. Диаграмма процесса BPMN  Рис. 5. Модель данных Заключение Реализованные приложения для оптимизации работы системы документооборота больницы в настоящее время обладают достаточно низким функционалом. В рамках исследования отработана связка ArgoUML, ArchGen, Plone, с помощью которой была автоматически получена информационная система без написания программного кода [6]. Программа Bizagi позволяет создать приложение подобного функционала встроенными средствами. На основании проделанной работы можно сделать вывод о том, что для простейших автоматизированных систем работы с данными, в частности документами, выразительная мощь обеих нотаций моделирования схожа. Более того, при реализации описании простейших систем четко прослеживаются параллели между различными диаграммами в разных стандартах. Однако при проектировании систем, в которых организационная структура играет большую роль, чем типовые процессы, предпочтение следует отдавать UML. Скорость разработки системы с помощью рассматриваемых технологий, а также степень практической применимости выходных продуктов в целом одинаковы и зависят от человеческого фактора. Помимо непосредственно практического применения, данные системы рекомендуется в настоящем их состоянии использовать в учебном процессе для изучения технологии проектирования и моделирования информационных систем в качестве практического учебного материала. Лабораторное занятие: по теме: «Разработка графика разработки и внедрения информационной системы» Цель: научиться анализировать методологий проектирования По завершению практического занятия студент должен уметь: анализировать методологий проектирования Продолжительность: 4 аудиторных часа (180 минут) Необходимые принадлежности Проектирование информационных систем: метод. указания к лабораторным работам / сост. С.В. Капустина, А.В. Паршаков; ФГОУ ВПО “СФУ”. – Красноярск, 2008. – 80 с. Задание Принципы создания информационной системы Многие пользователи компьютерной техники и программного обеспечения неоднократно сталкивались с ситуацией, когда программное обеспечение, хорошо работающее на одном компьютере, не работает на другом таком же устройстве. Или системные блоки одного вычислительного устройства не стыкуются с аппаратной частью другого. Или информационная система другой компании упорно не желает обрабатывать данные, которые вы подготовили в информационной системе у себя на рабочем месте. Эта проблема называется проблемой совместимости вычислительных, телекоммуникационных и информационных устройств. Развитие систем и средств вычислительной техники, расширенное их внедрение во все сферы науки, техники, сферы обслуживания и быта привели к необходимости объединения конкретных вычислительных устройств и реализованных на их основе информационных систем в единые информационно-вычислительные системы (ИВС) и среды. При этом разработчики ИВС столкнулись с рядом проблем. Например, разнородность технических средств вычислительной техники с точки зрения организации вычислительного процесса, архитектуры, системы команд, разрядности процессора и шины данных и т. д. потребовала создания физических интерфейсов, реализующих, как правило, взаимную совместимость устройств. При увеличении числа типов интегрируемых устройств сложность организации физического интерфейса между ними существенно возрастала. Разнородность программируемых сред, реализуемых в конкретных вычислительных устройствах и системах, с точки зрения многообразия операционных систем, различия в разрядности и прочих особенностей привела к созданию программных интерфейсов между устройствами и системами. При этом необходимо отметить, что достигнуть полной совместимости программных продуктов, разработанных для конкретной программной среды, в другой среде удавалось не всегда. Разнородность интерфейсов общения в системе "человек-компьютер" требовала постоянного согласования программно-аппаратного обеспечения и пер еобучения кадров. Принцип "открытости" информационной системы Решение проблем совместимости привело к разработке большого числа международных стандартов и соглашений в сфере применения информационных технологий и разработки информационных систем. Основополагающим понятием стало понятие открытые системы. Термин "открытая система" сегодня можно определить как "исчерпывающий и согласованный набор международных стандартов на информационные технологии и профили функциональных стандартов, которые специфицируют интерфейсы, службы и поддерживающие их форматы, чтобы обеспечить взаимодействие и мобильность программных приложений, данных и персонала". Это определение, сформулированное специалистами института IEEE (Institute of Electrical and Electronic Engineers), унифицирует содержание среды, которую предоставляет открытая система для широкого использования. В настоящее время общепризнанным координационным центром по разработке и согласованию стандартов открытых систем является OASIS (Organization for the Advancement of Structured Information Standards). Общие свойства открытых информационных систем можно сформулировать следующим образом: расширяемость/масштабируемость: обеспечение возможности добавления новых функций ИС или изменения некоторых уже имеющихся при неизменных остальных функциональных частях ИС; мобильность/переносимость: обеспечение возможности переноса программ, данных при модернизации или замене аппаратных платформ ИС и возможности работы с ними специалистов, пользующихся ИТ, без их переподготовки при изменениях ИС; взаимодействие: способность к взаимодействию с другими ИС (технические средства, на которых реализована информационная система, объединяются сетью или сетями различного уровня: от локальной до глобальной); стандартизуемость: ИС проектируются и разрабатываются на основе согласованных международных стандартов и предложений, реализация открытости осуществляется на базе функциональных стандартов (профилей) в области информационных технологий; дружественность к пользователю: развитые унифицированные интерфейсы в процессах взаимодействия в системе "человек-машина", позволяющие работать пользователю, не имеющему специальной "компьютерной" подготовки. Новый взгляд на открытые системы определяется тем, что эти черты рассматриваются в совокупности, как взаимосвязанные, и реализуются в комплексе, что вполне естественно, поскольку все указанные выше свойства дополняют друг друга. Только в совокупности возможности открытых систем позволяют решать проблемы проектирования, разработки и внедрения современных информационных систем. Структура среды информационной системы Обобщенная структура любой ИС может быть представлена двумя взаимодействующими частями: функциональной части, включающей прикладные программы, которые реализуют функции прикладной области; среды или системной части, обеспечивающей исполнение прикладных программ. С этим разделением тесно связаны две группы вопросов стандартизации: стандарты интерфейсов взаимодействия прикладных программ со средой ИС, прикладной программный интерфейс (Application Program Interface — API); стандарты интерфейсов взаимодействия самой ИС с внешней для нее средой (External Environment Interface — EEI). Эти две группы интерфейсов определяют спецификации внешнего описания среды ИС — архитектуру, с точки зрения конечного пользователя, проектировщика ИС, прикладного программиста, разрабатывающего функциональные части ИС. Спецификации внешних интерфейсов среды ИС и, как будет видно далее, спецификации интерфейсов взаимодействия между компонентами самой среды, — это точные описания всех необходимых функций, служб и форматов определенного интерфейса. Совокупность таких описаний составляет эталонную модель открытых систем (Reference Open System Model). Эта модель используется более 20 лет и определяется системной сетевой архитектурой (SNA), предложенной IBM в 1974 году. Она основана на разбиении вычислительной среды на семь уровней, взаимодействие между которыми описывается соответствующими стандартами, и обеспечивает связь уровней вне зависимости от построения уровня в каждой конкретной реализации (рис. 4.1). Основным достоинством этой модели является детальное описание связей в среде с точки зрения технических устройств и коммуникационных взаимодействий. Вместе с тем она не принимает в расчет взаимосвязь с учетом мобильности прикладного программного обеспечения.  |