Визуальные средства программирования
Обзор сред визуального программирования. Классификация инструментальных средств. Применение визуального программирования при построении интерфейса приложения в Visual Studio Net. Инструменты, методики создания логических моделей данных и алгоритмов.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | учебное пособие |
| Язык | русский |
| Дата добавления | 03.10.2017 |
| Размер файла | 3,3 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Процесс создания приложения можно разделить на следующие этапы:
1. Создание проекта. В результате на экране появляется пустая форма (окно будущего приложения).
2. Создание графического интерфейса проекта - расположение необходимых элементов, задание размеров, изменение свойств;
3. Написание программного кода, который определит, что будет делать ваша программа.
4. Отладка программы.
Чтобы познакомиться с основными инструментами среды разработки, запустим среду программирования.При этом запускается оболочка создания приложений, называемая интегрированной средой разработки IDE (Integrated Development Environment). На экране появится набор окон.
Все основные инструменты среды разработки Lazarus:
1. Окно формы - окно будущего приложения.
2. Главное окно, содержащее три панели: меню, панель инструментов, палитру компанентов. Палитру компанентов вы будете использовать для выбора необходимых вам для создания пользовательского интерфейса помпонент.
3. Окно Инспектор объектов, содержащее файлы проекта и окно со вкладкой Свойства, в котором вы будете настраивать свойсктва помещенных на форму объектов.
4. Окно Редактор исходного кода, в котором вы будете писать программный код.
Дадим появившимся окнам краткую характеристику.
Главное окно. Здесь располагаются меню, панель инструментов и палитра компонентов.
На Палитре компонентов, представляющей собой множество тематических вкладок, располагаются визуальные и невизуальные компоненты для вашей будущей программы.
Невизуальные компоненты видны только на первом этапе создания приложения - при редактировании.
Главное окно остается открытым все время работы IDE. Закрывая его, вы, тем самым, закрываете Lazarus и все открытые в нем окна.
Инспектор объектов содержит четыре страницы
На первой странице «Свойства» постоянно отображаются все доступные свойства выбранного компонента. В левой колонке содержится список всех свойств выделенного в данный момент компонента, в правой - значения свойств.
Значения свойств можно менять еще до запуска проектируемой программы. Например, для будущего окна приложения (формы) свойство Name имеет значение Form1. Для изменения имени достаточно изменить его в Инспекторе объектов.
На второй странице «События» находятся возможные обработчики событий для выбранного компонента. В левой колонке расположены названия события, в правой - соответствующие процедуры.
Окно Редактора кода. На момент первого запуска оно имеет заголовок Unit1.
В окне Редактор исходного кода вы будите писать программный код программы, и само окно очень похоже на обычный текстовый редактор. Для удобства при редактировании текста программы строки пронумерованы, предусмотрено выделение цветами:
· все служебные слова выделяются жирным шрифтом;
· знаки препинания становятся красными;
· строки с ошибками выделяются коричневым цветом;
· комментарии могут заключаться в фигурные скобки {} и выделяются синим.
Текст программы разбивается на части - процедуры и функции.
Основную работу программист производит именно здесь.
Проектировщик форм. У каждого Windows-приложения должно быть хотя бы одно окно.
Lazarus при первом запуске автоматически предлагает пользователю новый проект, открывая пустую форму под названием Form1, и назначает его главным окном.
Перенося на него элементы из палитры компонентов, вы тем самым, предварительно оформляете его.Главное окно в проекте может быть только одно. Все другие создаваемые окна будут дочерними. Закрывая главное окно стандартной кнопкой закрытия окна, или программно, вы закрываете и все дочерние окна. Итак, мы познакомились с основными инструментами разработки программна Lazarus, теперь напишем свою первую программу.
Задание для самостоятельного выполнения
1. Скачать и установить на компьютере среду программирования Lazarus по указанной в начале урока ссылке.
2. Посмотреть видеоурок: “Lazarus. Ввод в курс дела”, из которого вы узнаете о различиях проектов Lazarus и Delphi.
6. Введение в UML
Основные понятия UML Типы диаграмм UML
UML (Unified Modeling Language) версии 2.0 является на данный момент самым распространенным и общеизвестным способом моделирования сложных проектов, в том числе банков данных, баз данных, сетевом планировании, алгоритмизации в процессе разработки программного обеспечения.
"Скелетом" представленного здесь UML-экскурса является диаграммная структура UML. Его авторы выделяют следующие типы диаграмм (diagram types) (см. рис. 3.1):
· Структурные диаграммы:
o диаграммы классов (class diagrams) предназначены для моделирования структуры объектно-ориентированных приложений - классов, их атрибутов и заголовков методов, наследования, а также связей классов друг с другом;
o диаграммы компонент (component diagrams) используются при моделировании компонентной структуры распределенных приложений; внутри каждая компонента может быть реализована с помощью множества классов;
o диаграммы объектов (object diagrams) применяются для моделирования фрагментов работающей системы, отображая реально существующие в runtime экземпляры классов и значения их атрибутов;
o диаграммы композитных структур (composite structure diagrams) используются для моделирования составных структурных элементов моделей - коопераций, композитных компонент и т.д.;
o диаграммы развертывания (deployment diagrams) предназначены для моделирования аппаратной части системы, с которой ПО непосредственно связано (размещено или взаимодействует);
o диаграммы пакетов (package diagrams) служат для разбиения объемных моделей на составные части, а также (традиционно) для группировки классов моделируемого ПО, когда их слишком много.
· Поведенческие диаграммы:
o диаграммы активностей (activity diagrams) используются для спецификации бизнес-процессов, которые должно автоматизировать разрабатываемое ПО, а также для задания сложных алгоритмов;
o диаграммы случаев использования(use case diagrams) предназначены для "вытягивания" требований из пользователей, заказчика и экспертов предметной области;
o диаграммы конечных автоматов (state machine diagrams) применяются для задания поведения реактивных систем;
o диаграммы взаимодействий (interaction diagrams):
§ диаграммы последовательностей (sequence diagrams) используются для моделирования временных аспектов внутренних и внешних протоколов ПО;
§ диаграммы схем взаимодействия (interaction overview diagrams) служат для организации иерархии диаграмм последовательностей;
§ диаграммы коммуникаций (communication diagrams) являются аналогом диаграмм последовательностей, но по-другому изображаются (в привычной, графовой, манере);
§ временные диаграммы (timing diagrams) являются разновидностью диаграмм последовательностей и позволяют в наглядной форме показывать внутреннюю динамику взаимодействия некоторого набора компонент системы.
На рис. 8.1 не все узлы обозначают типы диаграмм - некоторые изображают лишь группы диаграмм, например, "Структурные", "Поведенческие", "Взаимодействий".
Рис. 8.1. Типы диаграмм UML 2.0
Отметим новые типы диаграмм, которые появились в UML 2.0 по сравнению с версией 1.5:
· диаграммы композитных структур (composite structure diagrams) - сюда, фактически, вошло два типа диаграмм: (i) коопераций (при этом кооперации UML 1.5 были сильно расширены); (ii) сложных компонент, созданных на базе компонент языка ROOM [3.5];
· диаграммы схем взаимодействий (interaction overview diagrams) - прообразом этого типа диаграмм явились диаграммы MSC overview [3.6];
· диаграммы коммуникаций (communication diagrams) - это упрощенный вариант диаграмм коопераций UML 1.5 ;
· временн ы е диаграммы (timing diagrams) - это новый тип диаграмм, предназначенный для наглядного изображения потока изменения состояний нескольких объектов.
Оставим в стороне тот факт, что английские названия некоторых типов диаграмм изменились, скажу лишь несколько слов о русскоязычной UML -терминологии. К сожалению, она не является устоявшейся: так, "use case" переводят то как "вариант использования", то как "случай использования" или даже просто как "использование", "deployment" - то как "размещение", то как "развертывание", "state machine (statechart)" - то как "состояния и переходы", то как "конечные автоматы" и т. д. На всякий случай для всех терминов в тексте дается исходное, англоязычное название. Будем надеяться, что у читателя не возникнет в голове безнадежной терминологической путаницы.
Описание нотации UML структурировано по разным типам диаграмм, хотя они и не являются строго обязательными. Различные конструкции языка можно вставлять в разнотипные диаграммы. Например, экземпляры классов можно изображать на одной диаграмме с самими классами, и пакеты также могут показываться на диаграммах классов. Таким образом, границы между различными типами диаграмм размываются. Создание диаграмм того или другого типа - всего лишь наиболее устоявшийся, традиционный способ использования UML, не исключающий, однако, и других вариантов.
Система "Телефонная служба приема заявок"
В дальнейшем в качестве примера будет использоваться система "Телефонная служба приема заявок". Далее будут приведены фрагменты этой системы, изображенные с помощью различных UML -диаграмм. Эти примеры будут снабжены некоторыми "сюжетами" - гипотетическими ситуациями процесса разработки, в которых могла появиться необходимость в создании этих диаграмм. Разумеется, приводимые сюжеты далеко не единственные, даже в рамках разработки данной системы. Но они нужны, чтобы с первых же шагов при знакомстве с UML не появлялось чувство пустоты, подвешенных в воздухе иллюстраций. Часть примеров будет на русском языке, а часть - на английском (это касается всех дальнейших примеров, а не только тех, которые относятся к телефонной службе приема заявок). Если диаграммы связаны с программным кодом, то есть моделируют какие-либо его абстракции (классы, таблицы баз данных, компоненты и пр.), то используется англоязычная терминология - названия модельных сущностей должны быть идентификаторами в программном коде. Если же такого нет, то при именовании используется обычный русский язык. Итак, заказчик данной системы - это компания, владеющая сетью продуктовых магазинов. Данная компания, кроме обычной розничной торговли, хочет предоставлять еще и сервис по обслуживанию клиентов по телефонным заявкам. Клиент регистрируется в компании, а потом по телефону, в удобное для себя время, делает заказ товаров, которые к нему привозят домой, и он расплачивается. Для этого компания хочет организовать у себя локальный телефонный центр, состоящий из офисной многоканальной АТС, штата операторов и соответствующего программного обеспечения. При этом в компании уже есть информационная система по обработке заявок от постоянных мелкооптовых клиентов, и заказываемая система должна быть с ней проинтегрирована.
Диаграммы случаев использования (use case diagrams)
Первым шагом по реализации описанной выше задачи является уточнение требований. Для этого можно применить диаграммы случаев использования UML. Пример такой диаграммы представлен на рис. 3.2.
Рис.8.2. Пример диаграммы случаев использования
На ней обозначено следующие виды пользователей - оператор, менеджер и представители технической поддержки. Система должна также поддерживать внешний интерфейс с системой обработки заявок. Это - четвертый пользователь. Еще одним пользователем системы является Петров А.Б. - директор департамента сбыта товаров, который хочет периодически отслеживать деятельность телефонной службы приема заявок. Для него создано специальное пользовательское место с экранными формами статистики. Случаи использования с рис. 3.2. комментировать не будем, считая, что и так все понятно из картинки.
Различные пользователи ПО, изображаемые на диаграммах случаев использования, назваются актерами (actors). Актеры могут обозначать:
· типовых пользователей ("Менеджер", "Оператор", "Техническая поддержка") - работников компании, сгруппированных по исполняемым обязанностям;
· другие системы, взаимодействующие с данной ("Система обработки заявок");
· выделенного пользователя ("Петров А.Б.").
Отметим, что выделенный пользователь существенно отличается от типового пользователя. Он, как правило, Важная Персона, и согласование функциональности для него согласуется лично с ним. Часто он влияет на оплату проекта, от его мнения о системе, во многом, зависит ее успешная сдача. Такие персоны, ради успеха проекта, нужно уметь идентифицировать и в рамках всей системы создавать некоторую функциональность специально для них и очень при этом стараться!
Случай использования (use case) - это независимая часть функциональности системы, обладающая результирующей ценностью для ее пользователей.
"Независимость" означает, что если случай использования всегда исполняется вместе с некоторым другим, то, по всей видимости, один из них нужно включить в другой (какой именно в какой, как назвать получившийся в итоге случай использования - зависит от обстоятельств).
"Результирующая ценность" случая использования для актера системы подразумевает, что он, данный случай использования, должен приносить актеру некоторый законченный и ценный с точки зрения его бизнеса результат. Будучи реализован системой, этот случай использования действительно делает бизнес актера эффективнее, производительнее. Тем самым разработка системы фокусируется на бизнес-целях, а незначительные случаи использования игнорируются. Строится не абстрактная модель функций системы, а набор самых важных (для заказчика и пользователей) сервисов, чтобы каждый из них правильно понять и не один не упустить. И в дальнейшем контроль разработки системы будет осуществляться именно в терминах этого самого важного - того, что нужно заказчику и пользователям.
Казалось бы, что может быть проще - реализовать набор функций, необходимых пользователю. Однако на деле программный проект может незаметно потерять эту цель. Вместо этого можно, например, очень долго заниматься разработкой сложной и многофункциональной архитектуры, после реализации которой разработчики обещают, что все пользовательские функции получатся почти сразу же и очень легко. Однако, как правило, оказывается, что это "сразу же" было сильным преувеличением и проект весьма выбивается из расписания, а многие заказанные пользователем функции в этом окружении сделать тяжело или невозможно. Бывает, что чрезмерная ориентация на "внутреннее совершенство" ПО оканчивается для проекта либо крупными неприятностями, либо полным крахом. Однако бывают и другие случаи, когда только такая ориентация впоследствии и спасает проект. Последнее случается, когда система долго развивается и сопровождается, или когда требования к ней внезапно и сильно меняются, или когда на ее основе делаются другие системы. Необходим баланс между внутренним совершенством программного обеспечения и функциональностью, нужной для заказчика и доставленной ему в срок. Разработка в терминах случаев использования - хороший способ контролировать, что процесс создания системы двигается в нужном направлении.
Итак, основной задачей диаграмм случаев использования является получение требований к системе от заказчика и пользователей. Трудность формализации требований связана с тем, что пользователи и заказчики, с одной стороны, а программисты - с другой, являются специалистами в совершенно разных областях. Первым очень не просто понять логику программной разработки и отделить существенное от несущественного, изъясняться ясно и точно. Вторым трудно разобраться в новой для них предметной области и адекватно отразить это свое понимание в программной системе. К тому же программные системы очень часто являются уникальными. Поэтому набор пожеланий заказчика и пользователей нуждается в дополнительной обработке, освобождению от противоречий, коррекции и, наконец, интеграции, дабы стало возможным "покрыть" его некоторой программной системой. Привлекательность и эффективность диаграмм случаев использования заключается в том, что они просты для понимания непрограммистами и в то же время достаточно формальны.
Отметим, что сами по себе случаи использования не гарантируют того, что программисты и заказчик адекватно понимают друг друга - они могут по-разному трактовать эти случаи использования. Однако в первом приближении масштаб и границы системы очерчены. Для того чтобы детализировать случаи использования, может применяться обычный текст (по одному абзацу на каждый случай использования) и/или другие диаграммы UML.
Существует два вида принципиально разных диаграмм случаев использования - для ПО и для всей системы в целом. Ведь, как правило, ПО является частью более крупной системы. Последняя может включать другое ПО, а также некоторый бизнес-процесс. Пользователями такой системы будут различные клиенты системы (бизнес-актеры), поскольку система создается именно для них. А сама система будет предоставлять для них бизнес-случаи использования. Пример диаграммы бизнес-случаев использования для системы обработки телефонных заявок показан на рис. 3.3.
Рис. 8.3. Пример диаграммы бизнес-случаев использования
На этом рисунке можно увидеть трех различных клиентов этой системы - постоянного клиента, нового клиента и задающего вопросы (случайного человека, интересующегося услугами магазина, наличием того или иного товара). В общем, для каждого типа клиентов система должна предоставлять разный сервис: для первого типа клиента - возможность сделать заказ (с внесением в базу данных имени клиента, товара, который он заказал, его цены и сроков доставки), для второго - возможность зарегистрироваться (оператор спрашивает у него фамилию, имя, отчество, адрес и пр., персональную информацию и вносит ее в компьютер), для третьего - возможность отвечать на разные вопросы (возможно, со специальными справочниками товаров и пр.). Причем эти актеры наследуют один от другого именно в том порядке, который указан на диаграмме. При наследовании актеров потомок "получает в наследство" все случаи использования своих предков. Таким образом, каждый из этих клиентов может задавать вопросы, а новый клиент, после того как зарегистрировался, может сделать заказ.
Этих бизнес-клиентов можно было бы изобразить и на рис. 3.2, соединив стрелками с оператором (ведь именно через него они взаимодействуют с системой). Но такая диаграмма может вызвать недоумение, хотя некоторые аналитики склонны так делать. Я считаю, что бизнес-актеров лучше изображать на отдельной диаграмме, а на обычной диаграмме случаев использования показывать только пользователей ПО.
Диаграммы активностей (activity diagrams)
С их помощью удобно изображать бизнес-процессы - алгоритмы, по которым работает компания. Именно в эти алгоритмы должна встроиться информационная система, автоматизировав некоторую их часть. В данном случае в компании должен быть создан новый бизнес-процесс по телефонной обработке заявок. Заказчик как-то себе представляет этот будущий процесс. Перед началом разработки системы необходимо уточнить алгоритм работы этой новой службы. На рис. 3.4 показана общая схема работы оператора с клиентом.
Рис. 8.4. Пример диаграммы активностей
Программистам полезно ясно представлять себе все бизнес-процессы компании, которые будут затронуты их новой системой. В данном случае у компании еще есть бизнес-процесс обработки заявок, который уже работает и есть у заказчика, и его также нужно понять. Иначе может оказаться, что упущена какая-то важная деталь, которая не позволяет новой системе полноценно выполнять свои функции. Например, может оказаться, что подсистема обработки заявок, с которой должна интегрироваться создаваемая система, реализована… на макросах к Word/Excel! Очевидно, интегрироваться с такой системой весьма затруднительно. На этот и подобные факты необходимо указать заказчику как можно раньше, так как иначе проект может закончиться неуспешно - заказчик потратит деньги и не получит нужных для своего бизнеса сервисов.
Итак, главной сущностью этого типа диаграмм является активность (activity) - активное состояние системы, в котором она выполняет некоторую работу. После ее завершения происходит переход в другую активность. Возможны и более сложные случаи переходов между активностями. Например, переход по событию.
На диаграмме должны присутствовать символы начала (start) и конца (finish).
Далее, на диаграмме может использоваться параллельный разветвитель (fork), который запускает несколько одновременно работающих веток. Такие ветки могут объединяться (все или только часть) конструкцией под названием параллельный соединитель (join).
Наконец, на диаграмме могут использоваться символы логического ветвления и логического соединения (decision). На ветках, идущих из логического ветвления, обозначаются условия перехода.
Диаграммы развертывания (deployment diagrams)
Теперь настало время в первом приближении определить будущую систему изнутри. Начнем с диаграмм развертывания, которые предназначены для описания аппаратной части системы.
На рис. 3.5, а показано, что телефонная служба приема заявок будет состоять из офисной телефонной станции ( PBX - Public Branch Exchange), сервера, телефонных аппаратов и клиентских компьютеров. На этом рисунке представлена диаграмма развертывания в одном из двух возможных в UML видов - в описательном. На ней определены типы аппаратных узлов системы, а между ними - ассоциации с пометками множественности (см. описание диаграмм классов).
На рис. 3.5, б приведена диаграмма развертывания в экземплярном варианте. Показан тестовый вариант системы, который, кроме сервера и PBX, содержит один пользовательский компьютер для тестирования взаимодействия сервера и клиента и один клиентский компьютер вместе с телефонным аппаратом для тестирования связи клиента с сервером и PBX. Два клиентских компьютера нужны, чтобы тестировать работу ПО в случае более чем одного клиента (при переходе от одного к двум начинают появляться многочисленные ситуации, которые не проявлялись ранее). Большее количество клиентов - три, десять и т. д. - не принципиально на первых стадиях тестирования и отладки.
Описательный и экземплярный виды диаграмм развертывания соотносятся между собой, также, как диаграммы классов и диаграммы объектов.
Таким образом, на диаграммах развертывания показываются узлы (nodes) - элементы аппаратуры, которые также входят в целевую систему, наравне с программным обеспечением. На части этих узлов и развертывается программное обеспечение системы. В рассматриваемом примере такими узлами являются клиентский компьютер и сервер запросов. Кроме того, на диаграммах развертывания могут быть показаны и другие виды узлов - элементы аппаратуры, с которым ПО лишь взаимодействует, например, PBX или телефонный аппарат. Данный тип диаграмм не предназначен для подробного описания аппаратной части системы, а позволяет моделировать только ту часть оборудования, которая прямо или косвенно связана с ПО системы. Например, в данном случае в целевую систему может входить дополнительное сетевое оборудование - переключатели (так называемые "хабы") и т. д. Для подробной спецификации всего этого целесообразно использовать не UML, а средства классического инженерного проектирования.
Построение инженерных чертежей на сегодняшний день также компьютеризировано. Самыми распространенными программными продуктами здесь являются пакеты AutoCAD, Microsoft Visio и др.
Рис. 8.5. Примеры диаграммы развертывания
Диаграммы развертывания могут использоваться, например, как приложение к техническому заданию, а также при обсуждении цен на различные офисные АТС, телефонные аппараты и компьютеры. Такую диаграмму может нарисовать менеджер проекта перед тем, как начать обсуждение архитектуры системы с разработчиками. Эта диаграмма может лежать на столе во время первых таких обсуждений, пока не родилось ничего более конкретного, что также можно нарисовать. Такое "начало от аппаратуры" часто является хорошим стартом проекта, поскольку именно в терминах аппаратуры для многих программно-аппаратных систем формируется существенная часть их функциональных требований: ПО должно уметь управлять таким-то оборудованием в таких-то режимах и т. д. Наконец, диаграмма развертывания может давать хороший обзор всей системы, доступный для непрограммистов (особенно в составе Power-Point презентации с устными пояснениями), поскольку содержит минимум программистских деталей.
Диаграммы компонент (component diagrams)
При обсуждении архитектуры системы, в качестве следующего промежуточного результата, может появиться диаграмма, приведенная на рис. 3.6.
Рис. 8.6. Пример диаграммы компонент
Это - диаграмма компонент UML. На этих диаграммах представляются компоненты (components) - независимые модули ПО, скрывающие свою реализацию и взаимодействующие друг с другом через интерфейсы.
Независимость компонент выражается в следующем.
· Они реализуют существенно различную функциональность системы. Например, модуль ClientGUI реализует пользовательский интерфейс рабочего места оператора, модули ClientNetworkSupport и ServerNetworkSupport - поддержку сетевого взаимодействия между клиентом и сервером, модуль ServerBusinessLogic - бизнес-логику сервера, а модуль RequestDB отвечает за взаимодействие с базой данных заявок и синхронизацию с системой обработки заявок.
· Каждый такой модуль независим с точки зрения физической организации - его реализация скрыта от окружения, все его взаимодействие с окружением происходит по строго определенным правилам, а сам он часто оказывается независимым бинарным файлом (например, DLL-файлом).
· Возможна также независимость периода исполнения - каждая из компонент может находиться или на отдельном компьютере, или в отдельном процессе операционной системы, или работать в контексте отдельной нити (thread).
· Наконец, разработку каждого такого модуля можно поручить отдельному разработчику или команде разработчиков, то есть с помощью компонент организовать разделение коллектива программистов.
В силу своей независимости, а также необходимости взаимодействия, компоненты имеют интерфейсы (interfaces), позволяющие компонентам скрыть их внутреннее устройство и предоставить вовне определенный способ обращения к своим функциям.
Предоставляемый интерфейс на диаграммах UML изображается маленьким кружочком, который соединен обычной линией со своей компонентой. Использование интерфейса показывается пустой чашечкой, которая соединена обычной линией с компонентой и пунктирной линией с "потребляемым" интерфейсом.
Понятие компоненты является очень емким, и однозначного, точного определения для него не существует. Неоднозначность возникает не столько в связи с разночтениями исследователей, сколько в связи с распространением различных технологий и средств программирования, использующих это понятия и по-разному его трактующих.
Самыми распространенными являются компонентные технологии - JavaBeans, EJB, CORBA, DCOM, .Net, web-сервисы и др. Они позволяют создавать распределенные системы, которые, в связи с распространением Интернета, оказываются одним из основных направлений современного программирования. Различные определения понятия компоненты, дискуссию и более глубокое обсуждение данного вопроса можно найти в [3.8].
Информация, представленная на диаграмме с рис. 3.6, может со временем меняться: интерфейсы уточняются, добавляются новые компоненты, существующие разбиваются на более мелкие и т. д. Диаграммы компонент проекта целесообразно поддерживать в актуальном состоянии, (имея в виду итеративность разработки и внесение в проект всяких изменений), поскольку компонентное представление системы часто является ядром ее архитектуры. А иметь корректное и компактное описание архитектуры всегда полезно, с помощью такого описания легче следить за изменениями в проекте и удерживать всю картину целиком.
Но поддержка актуальности каких-либо UML-диаграм, может оказаться непростым делом. Как правило, в начале все просто, концептуально, красиво. Потом - все разваливается на большое число деталей, да и сроки "поджимают" - нужно, чтобы работало. Вследствие этого целостность архитектуры ПО "уходит" из фокуса внимания разработчиков, а поддержка соответствующих UML-диаграмм "забрасывается". Однако есть такое правило - если нельзя ясно и кратко выразить главное в какой-либо сложной деятельности, значит, либо мы делаем что-то не то, либо то, но не так. В данном случае имеет смысл поддерживать актуальность именно этой диаграммы, поскольку она является одной из основных спецификаций архитектуры ПО телефонной службы приема заявок.
Еще один важный аспект системы, изображенный на этой диаграмме - интерфейсы компонент. Их нужно прорабатывать особенно тщательно и вовремя, поскольку если приложение разрабатывается разными рабочими группами, распределенными географически, то запоздалое согласование интерфейсов может потребовать серьезных модификаций в уже написанном коде.
На рис. 3.7 представлена диаграмма, показывающая, каким образом компоненты телефонной службы приема заявок распределяются по аппаратной части системы.
Рис. 8.7. Пример размещения компонент на диаграммах развертывания
Отметим, что описание типов узлов диаграмм развертывания производится на описательном, а не на экземплярном уровне.
Заметим, что именно диаграмма с рис. 3.6 является "кандидатом в долгожители" в процессе разработки, поскольку лаконична и не содержит лишней информации. То, какие именно компоненты располагаются на сервере, а какие на клиенте - не очень важная деталь здесь, поскольку система не очень большая, все это и так помнят. Кроме того, факт распределения компонент по аппаратуре не является здесь предметом изменений, как в более сложной системе, где существует несколько разных серверов, клиенты различных типов и т. д. Диаграмма с рис. 3.7 полезна для отчета, для переговоров с заказчиком и т. д.
7. Пакет LabVIEW - среда конструирования виртуального лабораторного практикума
Назначение LabVIEW. Особенности работы программы
Пакет LabVIEW (Laboratory Virtual Instrumentation Engineering Workbench) представляет собой универсальную систему (инструмент) программирования с расширенными библиотеками программ, ориентированную на решение задач управления инструментальными средствами измерения и задач сбора, обработки и представления экспериментальных данных. В более общем определении LabVIEW можно рассматривать как интегрированную среду разработки, отладки и выполнения программ для измерительных, тестирующих и управляющих систем, аппаратно-программных комплексов сбора, обработки и представления измерительной информации. LabVIEW - высоко интерактивная система, предназначенная для наиболее эффективного взаимодействия разработчика программной системы и среды разработки. Она содержит развитую систему меню, проблеммно-ориентированные библиотеки стандартных модулей и процедур для задач проектирования систем сбора и обработки данных, традиционные средства разработки и отладки программных продуктов.
Создание приложений.
LabVIEW - система визуального (графического) программирования. Ее характерной особенностью является использование универсального объектно-ориентированного языка визуального программирования, который оперирует графическими символами - пиктограммами, изображениями органов управления, приборных индикаторов, других элементов, близких и понятных предметной области инженеров и проектировщиков средств измерения. Это дает возможность пользователю даже с небольшим опытом программирования создавать качественный программный продукт, готовый для решения широкого круга прикладных задач.
В процессе работы с LabVIEW пользователь создает программные модули, называемые виртуальными инструментами (ВИ), поскольку их назначение и характер функционирования в составе ЭВМ соответствует характеру функционирования реальных инструментов. Такие программные модули содержат мощные библиотеки математических функций, позволяющих решать задачи обработки сигналов, корреляционно-спектрального и регрессионного анализа анализа, фильтрации и статистической обработки данных, других функций. Используя подобные библиотеки, ВИ позволяют решать широкий комплекс задач измерения, контроля и регулирования, управления объектами.
Виртуальные инструменты, создаваемые в среде LabVIEW, включают три основные части:
· переднюю панель
· блок-диаграмму
· пиктограмму-соединитель.
Передняя панель - интерактивный графический интерфейс пользователя, имитирующий лицевую панель реального физического инструмента. Она может содержать графические изображения кнопок, клавиш, цифровых и логических органов управления и индикации, которые обеспечивают большую наглядность выполнения процедур ввода команд управления и отображения результатов эксперимента на экране компьютера. Используя манипулятор "мышь", оператор управляет работой ВИ, имитируя действие с обычными органами управления физических приборов.
Блок-диаграмма представляет графическое изображение программы, задающей алгоритм решения задачи и являясь в то же время "исходным текстом" для спроектированного ВИ. Виртуальный инструмент получает инструкции от блок-диаграммы, которая конструируется на языке графического программирования (язык G). На рис.4.3.1 приведена передняя панель и блок-диаграмма виртуального инструмента "Частотный анализатор".
Пиктограмма-соединитель - графический символ ВИ, который задает условное обозначение данного ВИ в общей иерархии виртуальных инструментов, а также определяет схему входо-выходных терминалов ВИ, через которые осуществляется его подключение к другим ВИ. Пиктограмма-соединитель работает подобно графическому параметрическому списку так, что остальные ВИ могут передавать данные к субблокам ВИ. Последнее качество обеспечивает принцип модульности и иерархии системы ВИ, позволяя самостоятельно выполнять как программы верхнего уровня, так и подпрограммы нижнего уровня.
Рис.4.3.1.
Рис.4.3.2
ВИ как приложение, создаваемое в среде LabVIEW (LV-приложение), имеет модульно-иерархическую структуру. Подобная структура представляет собой иерархию модулей, каждый из которых является самостоятельным суб-модулем (суб-блоком), который может рассматриваться как самостоятельный ВИ - субВИ со своей передней панелью, блок-диаграммой и пиктограммой-соединителем. Разбив блок-диаграмму ВИ на отдельные суб-блоки - субВИ, можно их использовать как самостоятельные инструменты или компоненты для построения ВИ более сложной архитектуры. В то же время, создав пиктограмму для собственного ВИ, его можно использовать как отдельный независимый элемент в других ВИ.
Объекты передней панели. Проблемная ориентированность пакета LabVIEW обуславливает наличие специальной библиотеки объектов, предназначенных для конструирования передней панели виртуального инструмента. Библиотека доступна в режиме редактирования и открывается выбором Control главного меню, которое находится в окне после выбора Show Diagram меню Windows (Рис.4.3.2). Основными разделами библиотеки, в которых сконцентрированы объекты создания передних панелей ВИ, являются:
· Numeric- библиотека цифровых органов управления и индикаторов
· Boolean - библиотека органов управления и индикаторов логического (булевского) типа
· String - библиотека органов управления и индикаторов строкового типа
· Array & Cluster - библиотека органов управления и индикаторов массивов и кластеров
· Graph - библиотека индикаторов отображения графиков
· Path & RefNum - библиотека органов управления и индикаторов отображения связей и ссылочных номеров
· Decorations - библиотека элементов декоративного оформления передней панели.
Примеры некоторых объектов передней панели, соответствующих органам управления (а) и индикаторам (в), приведены на рис. 4.3.3a. и рис. 4.3.3b. Выбор нужного органа управления или индикатора осуществляется открытием соотвотствующего окна меню и щелчком курсора мыши на требуемом объекте.
Объекты блок-диаграммы. Блок-диаграмма - это по сути программный код приложения. Объекты конструирования блок-диаграммы ВИ сгруппированы в библиотеках, которые становятся доступными в режиме редактирования. Все объекты конструирования блок-диаграмм разделяются на различные типы, к которым относятся:
· узлы
· терминалы
· соединения.
Узлы - программно-исполняемые элементы, которые являются аналогами элементов языка программирования, как утверждения, операторы, функции, процедуры. К узлам также относятся узлы кодовых интерфейсов, формулы, атрибуты органов управления и т.д.
Рис.4.3.3.а
Рис.4.3.3.б
Терминалы - это порты, через которые передаются данные между блок-диаграммой и передней панелью, так же как и между узлами на блок-диаграмме. Терминалы подразумевают соответствие определенным пиктограммам функций, а также и самим виртуальным инструментам. Для отображения терминала некоторой функции или ВИ необходимо вызвать их пиктограмму и вызвать опцию Show Terminal во всплывающем меню данного объекта.
Соединения - передают данные между входными и выходными терминалами элементов блок-диаграммы. Они изображаются в виде линий различного типа, связывающих отдельные пиктограммы или терминалы на блок-диаграмме.
Библиотеки объектов конструирования блок-диаграммы открываются после выбора опции Functions главного меню, которое находится в окне блок-диаграмм и открывается после выбора Show Panel меню Windows (Рис.4.3.4):
Рис.4.3.4
Рис.4.3.5
Основными библиотеками объектов конструирования блок-диаграммы ВИ являются:
· Struct & Constants - библиотека узлов, называемых "структуры", и различных констант
· Arithmetic - библиотека математических функций и выражений
· Trig & Log - библиотека тригонометрических и логических функций и выражений
· Comparison - библиотека функций сравнения и условий сопоставления
· Conversion - библиотека обратных преобразований
· String - библиотека объектов и функций работы со строками
· Array & Claster - библиотека функций работы с массивами и кластерами
· File I/O - библиотека функций работы с файлами
· Dialog & Date/Time - библиотека функций управления данными и временными характеристиками,
а также ряд других библиотек, содержащих необходимые структуры. В этих же библиотеках находятся некоторые стандартных блоки и суб-ВИ, которые могут быть использованы как отдельные самостоятельные элементы блок-диаграммы.
4. Виртуальный практикум в Web-среде
Решение задач создания виртуальных лабораторий и организации удаленного доступа к сложным инженерным компьютерным приложениям при использовании сетевых технологий принципиально возможно на основе Java-Web технологий, однако достаточно общая схема создания таких приложений пока еще далеко не сформирована, и сейчас можно говорить лишь о некоторых из возможных путей реализации системы виртуального лабораторного практикума в сетевой среде. Программную имитацию лабораторной установки на базе определенной математической модели исследуемых процессов можно реализовать в форме Java-апплета ,
на основе использования возможностей языка, графический интерфейс такой модели выполнен в форме "обычных" регуляторов параметров соответствующей лабораторной установки. Принципиальным является возможность исследования методом численного эксперимента тех характеристик, которые обычно исследуются в реальной установке. Возможности подобной виртуальной "лабораторной установки" могут быть существенно богаче ее физического аналога. Последнее, разумеется, не означает, что виртуальный практикум может заменить реальный физический эксперимент, но он может существенно ускорить проведение работы в лаборатории, сделать ее более осознанной и продуктивной.
В целом ряде случаев создание адекватных программных имитаторов лабораторных установок может привести к чрезмерно большому размеру байт-кода апплета, и пересылка его по сетевым соединениям может оказаться крайне затруднительна. В такой ситуации сетевые возможности Java-апплетов могут быть использованы для организации удаленного доступа к серверным приложениям посредством Web-интерфейса. Задачей Java-апплета в такой клиент-серверной конфигурации является предоставление возможности пользователю в удобной графической среде сформировать задание для серверного приложения (возможно, выполнив при этом определенную предобработку исходных данных), передать его серверу, и по завершению выполнения задачи переслать результаты соответствующему клиенту. Посредством этого же апплета результаты выполнения задания могут быть представлены в графической форме или на их основе проведены дополнительные, менее требовательные к вычислительным ресурсам, расчеты. Следует отметить, что в такой модели ресурсы сети на этапах формирования и предобработки исходных данных, равно как и при обработке результатов, не используются. Они потребляются лишь для относительно "легких" операций пересылки апплета, задания и результатов моделирования.
Реализация основных элементов описанной выше схемы была проведена при разработке имитатора установки для исследования характеристик модема, предназначенного для работы в составе высокоскоростных спутниковых радиолиний (кафедра "Радиотехника и телекоммуникации" СПбГТУ совместно с ЦДО). Сложность математических моделей компонент модема и процессов цифровой обработки радиосигналов, реализованных в нем, многообразие режимов работы устройства заставили разделить программную реализацию модели на серверную и клиентскую части. Первая была написана на языке Delphi и реализована на достаточно производительном компьютере. Она ведет расчет характеристик режимов работы устройства, заданных пользователем посредством клиентской части модели, представляющей собой небольшой Java-апплет (рис.4.3.6). В целом программная реализация модели обеспечивает возможность изменения более 30 параметров, получение результирующей информации в форме графиков исследуемых зависимостей (рис.4.3.7), гистограмм и значений определенных характеристик модема. Все результаты моделирования сохраняются в форме, позволяющей их дальнейшую обработку и повторное использование. При этом, в то время, как размер исполняемого кода серверной части модели достигает 900 кбайт, размер байт-кода этого аплета не превышает 20 кбайт.
Рис. 4.3.6
Рис.4.3.7
для большого числа пользователей такой способ доступа к большим приложениям будет предпочтительнее их установки на своих компьютерах, ибо им не потребуется модернизировать свои вычислительные ресурсы в соответствии с требованиями приложения и им всегда будет доступна последняя версия программного продукта. Для создания больших удобств зарегистрированным пользователям предоставлен исходный текст интерфейсного Java-апплета, что позволит им экономить время и средства, обычно затрачиваемые на оплату коммуникационной линии во время его многократной загрузки.
CourseLab® - это мощное и одновременно простое в использовании средство для создания интерактивных учебных материалов (электронных курсов), предназначенных для использования в сети Интернет, в системах дистанционного обучения, на компакт-диске или любом другом носителе.
Ключевые особенности CourseLab:
· создание и редактирование учебного материала в среде WYSIWYG - что Вы видите, то и получите в результате;
CourseLab 2.0 сертифицирован на соответствие стандарту SCORM 2004, уровень соответствия: CP SCORM 2004 Conformant;
не требует от автора знания языка HTML или каких-либо языков программирования;
встроенные средства построения тестов
объектный подход позволяет - как из детских кубиков - строить учебный материал практически любой сложности;
открытый объектный интерфейс позволяет легко расширять библиотеки объектов и шаблонов, в том числе и за счет созданных самим пользователем;
встроенные механизмы анимации объектов;
возможность вставки в курсы любого Rich-media содержимого - Macromedia® Flash®, Shockwave®, Java®, видео в различных форматах и т.п.;
простые механизмы вставки и синхронизации звукового сопровождения;
возможность импорта в учебный материал презентаций из формата Microsoft® PowerPoint®;
встроенный механизм захвата экранов, позволяющий легко создавать симуляции работы различных программных продуктов;
простой встроенный язык описания действий;
опытному пользователю редактор предоставляет дополнительные возможности через прямой JavaScript-доступ к свойствам объектов и функциям проигрывателя курсов.
Вы можете получить максимально подробную информацию о редакторе и познакомиться с демо-версией на сайте Courselab.ru
Рис. 4.3.8. Интерфейс редактора CourseLab
8. Технологии межпрограммного интерфейса
Тезисы лекции
Технологии межпрограммного интерфейса, появившись с возникновением операционных систем почти полвека назад, непрерывно развивались очень длительное время, принося с каждым шагом развития всё новые и новые преимущества программным комплексам, использующим их.
С возникновением многозадачных ОС получил развитие механизм использования динамических библиотек, представляющих собой исполняемые из других программ откомпилированные перемещаемые модули разделяемого пользования. Сами эти библиотеки были развитием библиотек объектных модулей подпрограмм и функций.
Следующим этапом явилось появление межпрограммных интерфейсов контейнерного типа, как например, механизм DDE в ОС Windows. Такой механизм позволял не только человеку, но и прикладным программам запускать на выполнение иные программы.
Одновременно с этим появилась и развивалась технология клиент-сервер, позволяющая обслуживать множество прикладных программ - клиентов, одной программой - сервером. Это позволило развить использование баз данных корпоративного, сетевого назначения, используя в качестве сервера СУБД - систему управления базами данных.
Параллельно с этим шло развитие межпрограммного интерфейса контейнерного типа, который позволил легко внедрять объекты из одной программы в другую или даже в электронный документ. Примером может служить разработка корпорации Microsoft OLE.
В дальнейшем практика покзала, что этот межанизм можно еще больше развить с помощью так называемой COM-модели Microsoft или CORBA консорциума Object Management Group, использующих объектно-ориентированное программирование и такие принципы, как инкапсуляция, классы, объекты.
В области работы с различными базами данных были разработаны унифицирующие обмен интерфейсные технологии типа ODBC корпорации Microsoft, DBE фирмы Borland и другие.
Постепенно все эти технологии подготовили новое поколение инструментальных средств - визуальные среды, которые иначе называют системами быстрой разработки приложений (RAD) иил языками четвертого поколения (4GL - 4-th Generation Languages).
Технологии .NET Framework и Mono
.NET Framework -- программная платформа, мобильная бинарная среда, выпущенная компанией Microsoft в 2002 году и позволяющая работать скомпилированным приложениям на любой аппаратной платформе в среде Windows. Основой платформы является исполняющая (бинарная) среда Common Language Runtime (CLR), способная выполнять как обычные программы, так и серверные веб-приложения. NET Framework поддерживает создание программ, написанных на разных языках программирования.
Считается, что платформа .NET Framework явилась ответом компании Microsoft на набравшую к тому времени большую популярность платформу Java компании Sun Microsystems (ныне принадлежит Oracle).
Хотя .NET является патентованной технологией корпорации Microsoft и официально рассчитана на работу под операционными системами семейства Microsoft Windows, но существуют независимые проекты (прежде всего это Mono и Portable.NET), позволяющие запускать программы .NET на многих других операционных системах.
Разработка платформы началась в 1999 году. 13 января 2000 года была озвучена новая стратегия компании, получившая название Next Generation Windows Services (сокр. NGWS, рус. Новое поколение служб Windows). Новая стратегия должна была объединить в единый набор существующие и будущие разработки Microsoft для предоставления возможности пользователям работать с Всемирной паутиной с беспроводных устройств, обладающих доступом в Интернет, как со стационарных компьютеров. Было заявлено, что несмотря на огромные возможности домашних компьютеров, корпорация считает важным обеспечение гарантированной работы служб нового поколения и на устройствах, отличных от ПК, то есть “нетбуках”, опирающихся на серверную поддержку.
Ввиду небольшой мощности источников питания мобильных устройств, хранение и передача приложений должна осуществляться серверами, тогда как на тот момент практически вся пользовательская информация и ПО хранились на стационарных компьютерах локально. Тогда идея перехода к “сервероцентрической” модели имела крепкую поддержку среди руководителей крупнейших IT-компаний, так как сулила обеспечение привязки, зависимости конечного пользователя от сервера.
У Microsoft на тот момент было множество причин перехода к новой стратегии. Компания доминировала на рынке операционных систем и веб-браузеров, обладала множеством наработок в области ПО для Интернета, включая порталы MSN и WebTV, а также имела долю в компаниях, занимавшихся предоставлением ПО в прокат через Интернет. Кроме того, у корпорации имелось множество различных (и зачастую несовместимых между собой) сред и технологий программирования, поскольку разработка инструментов для программистов была языкоориентированной, то есть для Visual Basic существовал свой набор приложений, а для C++ -- свой. Поэтому одной из целей разработки новой платформы, было объединение всех наиболее удачных наработок в рамках единой платформы и их унификация.
Кроме того, ставилась задача следования всем актуальным тенденциям в области программирования на тот момент. Так, например, новая платформа должна была напрямую поддерживать объектно-ориентированность, безопасность типов, сборку мусора и структурную обработку исключений. Кроме того, корпорации необходимо было предоставить свой ответ набиравшей популярность платформе Java от Sun.
Так, например, планировалось, что разработчики смогут писать веб-сайт для электронной коммерции целиком на новой версии Visual Basic, а благодаря тому, что обмен информацией будет происходить при помощи XML, разработчики смогут создавать клиентские приложения, функционирующие на Linux, Solaris и Mac OS. То есть, для того, чтобы приложение или операционная система могли взаимодействовать друг с другом нужна была лишь поддержка стандарта с их стороны.
Подобные документы
Разработка интерфейса программы, обеспечивающего доступ ко всем возможностям среды структурно-визуального программирования. Реализация инструментальных средств, позволяющих связывать компоненты в единое приложение. Создание иерархии классов представления.
дипломная работа [2,3 M], добавлен 11.04.2012Расчет трансформатора питания. Численное решение нелинейных уравнений с заданной точностью и дифференциальных уравнений первого порядка. Разработка программы с использованием средств визуального программирования на алгоритмическом языке программирования.
курсовая работа [1,2 M], добавлен 17.08.2013Разработка приложения для работы с базой данных с использованием объектно-ориентированного и визуального программирования. Обзор языка элементов языка программирования Delphi. Проектирование базы данных автозаправки. Клиентская система приложения.
курсовая работа [2,3 M], добавлен 31.01.2016Понятие математического программирования. Класс как тип структуры, позволяющий включать в описание типа не только элементы данных, но и функции. Рассмотрение основных особенности языка программирования C++. Характеристика среды MS Visual Studio 2008.
контрольная работа [318,0 K], добавлен 13.01.2013Описание программного продукта Visual Studio. Возможности, преимущества и недостатки бесплатной среды программирования Sharp Develop для проектов на платформе MS.NET. Получение информации из справочной системы .NET SDK. Запуск визуального отладчика CLR.
реферат [393,4 K], добавлен 05.04.2017Общие сведения о работе программы в среде программирования Microsoft Visual Studio 2008, на языке программирования C++. Ее функциональное назначение. Инсталляция и выполнение программы. Разработанные меню и интерфейсы. Алгоритм программного обеспечения.
курсовая работа [585,5 K], добавлен 24.03.2009Эффективные средства разработки программного обеспечения. Технология визуального проектирования и событийного программирования. Конструирование диалоговых окон и функций обработки событий. Словесный алгоритм и процедуры программы Borland Delphi 7 Studio.
дипломная работа [660,2 K], добавлен 21.05.2012Специфика визуального подхода к программированию, языки и среды программирования, которые поддерживают его возможности. Классификация языков визуального программирования. Объектная модель (иерархия классов VBA), используемая в MS Word и в MS Excel.
контрольная работа [965,6 K], добавлен 27.04.2013Язык разработки, среда реализации, инструменты разработки. Особенности виртуальной среды реализации программ и их учет в разработке программного продукта. Системные макросы и их применение в текстах разработки. Средства визуального программирования.
учебное пособие [1,7 M], добавлен 26.10.2013Характеристика основных разделов программирования, изучаемых в курсе программирования на языке С++. Описание внутренних переменных, входных и выходных данных. Особенности использования компилятора Microsoft Visual Studio 2008. Руководство пользователя.
курсовая работа [18,8 K], добавлен 14.12.2010
