Клуб "Трёх инженеров"
 

Email:

Пароль:

Забыли пароль?

Вступить в клуб?

Микроконтроллеры AVR

MS Visual Studio & C#

MODBUS-RTU & RS485

SolidWorks & Cosmos

Компьютерная техника

Мехатроника & Авиация

Силовая электроника

Всего статей:

Категорий/рубрик:

Комментариев:

Пользователей:

33

7

239

2008

 
видео прикол из Городка
Репортаж об интернете из глубинки
Для корректного отображения этого элемента вам необходимо установить FlashPlayer и включить в браузере Java Script.

Разработка программного обеспечения для мехатронных систем с использованием современных CASE-технологий

Автор: Меньшиков Павел Владимирович

Дата: 2009-11-07


В любом производстве используемая технология определяет лучшие достижимые показатели. В силу специфичности производства программного обеспечения (ПО) - практически нулевая стоимость тиражирования, очень быстрый процесс устаревания и т. д. - технология его создания сильно завязана на человеческий ресурс и поэтому должна включать в себя организационный и управленческий аспекты. На сегодняшний день в мире существует большое количество различных процессов для создания ПО. Тем не менее, среди них относительно немного технологий, рассматривающих полный жизненный цикл проекта разработки ПО, сочетающих в себе научный подход, серьезную базу исследований и имеющих историю реального использования и адаптации. Из методологий и технологий, получивших определенное признание на данный момент, можно назвать следующие: Capability Maturity Model (CMM), Microsoft Solution Framework (MSF), Oracle Method, Rational Unified Process (RUP), Structural Analysis and Design Technique (SADT).

Рассмотрим применение технологии разработки ПО RUP (Rational Unified Process [1]) на примере создания автоматизированной информационной системы (АИС) «Справочник материалов». Основными особенностями инженерного программного обеспечения  (ПО) являются [2]:

  • сложность предметной области, из чего следует, что эксперт должен либо находиться в команде разработчиков (что неэффективно), либо очень хорошо проработать требования к ПО вместе с руководителем проекта;

  • архитектурная сложность;

  • зачастую – высокие требования к ресурсам компьютера, необходим хорошо оптимизированный код;

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

  • необходимость в постоянном обновлении и возможность подключения дополнительных модулей от сторонних производителей для более полного охвата предметной области (масштабируемость проекта АИС).

Установим требования к инженерному ПО АИС:

  • высокая надежность и минимальное количество ошибок в готовом продукте;

  • высокая производительность;

  • простота и удобство использования;

  • широкие функциональные возможности;

  • надежная, легко надстраиваемая модульная архитектура.

Основными этапами разработки АИС являлись: определение целей проекта и функциональных требований к нему; бизнес-моделирование; реализация; тестирование; внедрение. Каждому этапу отводилась одна итерация процесса разработки АИС.

Определение целей и требований. Для определения целей проекта АИС и функциональных требований к нему в первую очередь были рассмотрены программы-аналоги, были выявлены их преимущества и недостатки. На их основании цели и требования были сформированы таким образом, чтобы результатом разработки являлась АИС, обладающая преимуществами АИС-аналогов и лишенная их недостатков, а также обладающая рядом принципиально новых функций. После анализа АИС-аналогов были определены бизнес-цели и бизнес-требования к разрабатываемой АИС. Диаграммы бизнес-целей и бизнес-требований  представлены, соответственно, на рисунке 1 и 2.

Рисунок 1 – Диаграмма бизнес-целей АИС.

Рисунок 2 – Диаграмма бизнес-требований АИС.

Бизнес-моделирование. На этом этапе с учетом сформулированных функциональных требований и бизнес-целей составляется первый вариант функциональной модели (ФМ) АИС. В данном случае удобнее всего строить ФМ АИС на основе вариантов использования (Use Cases), которые представляют собой отдельные реакции на действия пользователя или других модулей системы. Диаграмма вариантов использования является многоуровневой. Верхний уровень диаграммы, состав бизнес-процессов (БП), представлен на рисунке 3. Было определено пять БП: «Вход в программу», «Просмотр материалов», «Поиск материалов», «Редактирование материалов» и «Выход из программы». Для каждого из этих БП на следующей стадии моделирования были определены варианты использования. В общем случае диаграмма второго уровня представляет собой взаимодействие между различными вариантами использования в рамках одного БП, однако в данном случае никакого взаимодействия нет. Последней стадией этого этапа является предварительная проработка всех вариантов использования с помощью диаграмм деятельности. Эта итерация является в каком-то роде решающей, так как именно на ней определяется архитектура создаваемой АИС. Корректно разработанная ФМ АИС позволит на дальнейших итерациях минимизировать потери времени на переписывание исходного кода системы, уменьшить риски провала проекта и значительно упростить дальнейший процесс разработки.

Рисунок 3– Диаграмма «Состав бизнес-процессов»

Анализ и проектирование. На этом этапе осуществлялась работа над ФМ и  созданием исходного кода АИС.  Модель данных является представлением структуры базы данных, ее таблиц и их полей и взаимосвязей между ними. База данных обладает двумя базовыми таблицами: Root и USER. В таблице Root хранятся базовые сведения о материале, такие как группа, к которой он относится, заменители, вид поставки и т.д. Каждому материалу назначается уникальный идентификационный номер CSTEEL, по которому осуществляется связь с вторичными таблицами. В таблице USER хранятся данные о пользователях, их паролях, уровне доступа и времени последнего входа в систему. С таблицей USER связана по идентификатору CUSER таблица favorites, в которой хранятся «избранные» материалы для всех пользователей.

Реализация. На этом этапе производится углубление и детализация ФМ и основная проработка кода приложения АИС.  Разработка основного кода программы происходит с применением функции генерации кода по модели, доступной в ПО Enterprise Architect (используемое инструментальное средство языка UML).

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

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

Результат создания ПО АИС «Справочник материалов» представлен на рисунке 4.

Рисунок 4 – Главная форма АИС «Справочник материалов»

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

Литература:

  1. Booch G. Object-oriented analysis and design with applications. Third edition // Boston : Addison-Wesley, 2004.

  2. Кульга К.С. Разработка программного обеспечения PLM-системы на основе объектно-ориентированных методов CASE-технологий // САПР и графика.   2009.   №6.  С.91–94.

Рейтинг:

Просмотров: 44579

Комментарии:

Нет комментариев.

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