12
с API e3.Series использовался файл-справки САПР e3.Series [20], в нем
описаны все методы для работы с объектами e3.Series (Рис.2).
Рисунок 2 – API e3.Series
Существует объекты верхнего уровня – Приложения (Класс
Application). Их может быть несколько – столько, сколько в данный
момент открыто приложений (окон) с САПР. Объект Приложение (класс
Application) содержит объект Проект (класс Job). В случае e3.Series
проектов может быть ровно или меньше количества окон, т.к. в одном окне
с e3.Series может быть открыт только один проект.
В объекте Проект (класс Job) могут содержаться подчиненные
объекты (таблица 1)
В свою очередь, к примеру, объект «Изделие в проекте» (класс
Device) может содержать объекты: модель (Outline), символы (Symbol),
выводы (Pin), питание (Supply), жилы кабеля (Core) – если изделие кабель,
13
жгуты (bundle) – если изделие кабель, слоты (slot), описание изделий в БД
(Component).
Таблица 1 – подчиненные объекты в объекте (класс) JOB
Название
Класс
Соединение
Connection
Изделие в БД
Component
Области листа
Field
Изделия в проекте
Device
Блоки
Module
Графика
Graph
Файлы
ExternalDoc
Опции
Option
Варианты
Variant
Листы
Sheet
1.3 CASE технологии
Вышеописанная технология COM относится к компонентному
подходу этапа развития технология программирования (всего четыре
этапа: стихийное программирование, структурный подход, объектный
подход и компонентный). Компонентный подход – это разработка
программного обеспечения с помощью отдельных компонентов, которые
физически находятся отдельно от программного обеспечения и
взаимодействуют между собой с помощью стандартного двоичного
интерфейса. Объекты-компоненты можно использовать в любом языке
программирования, поддерживающем соответствующую технологию или
распространять в двоичном виде (без исходников), можно собирать в
исполняемые файлы или в динамически вызываемые библиотеки. Это
позволяет программистам использовать технологию, хорошо
зарекомендовавшую в области проектирования аппаратуры, по другому
14
говоря, создавать продукты, состоящие из повторно использованных
частей [12, с.11].
Для создания составных документов раньше (в старых версиях
Windows) использовалась технология OLE (Object Linking and Embedding).
Эта технология связывала и внедряла объекты. Развитием OLE технологии
стала COM технология. Она определяет общую парадигму взаимодействия
программ любых типов, таких как приложения, операционные системы и
библиотеки. Из этого следует, что технология COM позволяет одной части
программного обеспечения использовать функции (службы),
предоставляемые другой, независимо от того, функционируют ли эти
части в пределах одного процесса, в разных процессах на одном
компьютере или разных компьютерах. На рисунке 3 можно посмотреть
взаимодействие программных компонентов различных типов. Если нужно
обеспечить передачу вызовов между компьютерами, то можно
воспользоваться модификацией COM, которая называется DCOM
(Distributed COM – распределенная COM) [12, с.11].
На базе технологии COM и её распространенной версии DCOM были
разработаны компонентные технологии, решающие различные задачи
разработки программного решения.
Существует технология создания программируемых приложений.
Называется она OLE-automation (автоматизация). Эта технология
обеспечивает программируемый доступ к внутренним службам этих
приложений.
На базе OLE-automation была построена технология для создания
программного обеспечения как сосредоточенного на одном компьютере,
так и распределенном в сети и называется она Active-X. Такая технология
позволяет использовать визуальное программирование для создания
компонентов – элементов управления Active-X. Полученные таким
образом элементы управления можно устанавливать на компьютер
15
дистанционно с удаленного сервера, причем устанавливаемый код зависит
от используемой операционно системы. Это позволяет применять
элементы управления Active-X в клиентских частях приложений Интернет.
Рисунок 3 – Взаимодействие программных компонентов различных
типов
Рассмотрим создание и внедрение автоматизированных технологий
разработки и сопровождения программного обеспечения. Такая технология
называется CASE-технология (Computer-Aided Software/system Engineering
– что в переводе означает разработка программного
обеспечения/программных систем с использованием компьютерной
поддержки). CASE-технология является отличительной особенностью
современного этапа развития технологии программирования.
В настоящий момент становится трудно разрабатывать сложное
программное обеспечение без средств автоматизации. С помощью CASE-
технологии эта проблема частично упрощается, так как поддерживают
компонентный, объектный и структурный подходы к программированию
[12, с.13].
Такие упрощения не означают, что программное обеспечение будет
создаваться из программных компонентов, но анализ существующих
проблем разработки сложного программного обеспечения показывает, что
он будет применяться достаточно широко.
16
1.4 Жизненный цикл и этапы программного обеспечения
Отрезок времени, с момента, когда появляется только сама идея
создания программного обеспечения, и до момента, когда завершается
поддержка разработчиком программного обеспечения, называется
жизненный цикл [12, с.17].
Существует стандарт ISO/IEC 12207:1995 [7] «Information Technology
– Software Life Cycle Processes». В этом стандарте описывается состав
процессов жизненного цикла, структуру жизненного цикла и его процессы.
Совокупность взаимосвязанных действий, преобразующих некоторые
входные данные в выходные – это и есть процессы жизненного цикла.
На рисунке 3 представлены процессы жизненного цикла по
указанному стандарту. Каждый процесс характеризуется определенными
задачами и методами их решения, а также исходными данными и
результатами.
Согласно стандарту процесс разработки заключается в выполнение
разработчиком задач и действий, работу по созданию программного
обеспечения, компонентов программного обеспечения, оформление
эксплуатационной документации, проектной документации, подготовка
необходимых для проверки работоспособности и соответствия качества
программных продуктов документации, обучение персонала.
Рассмотрим последовательность действий процесса разработки по
стандарту:
- подготовительная работа. Здесь составляется план работы, выбирается
стандарты, средства и методы разработки, а также схемы и модели
жизненного цикла;
- анализ требований к системе. В этом действии определяются
функциональные возможности системы и пользовательских требований;
17
Рисунок 3 – Структура процессов жизненного цикла программного
обеспечения [12, с.18]
- проектирование архитектуры системы. Вычисление необходимого
оборудования, программного обеспечения, а также операции, выполнение
которых предстоит обслуживающему персоналу;
- анализ требований к программному обеспечению. Здесь
устанавливаются функциональные возможности программного
обеспечения, среды функционирования компонентов и внешних
интерфейсов, характеристики производительности, пользовательская
документация, эксплуатация и сопровождение, а также спецификация
надежности и безопасности;
- проектирование архитектуры программного обеспечения. В этом
действии ведется документирование всех интерфейсов и его компонентов,
разрабатывается структура ПО и предварительная версия
18
пользовательской документации, а также требований к тестам и плана
интеграции;
- детальное проектирование программного обеспечения. Здесь
ведется обновление пользовательской документации, описание в
подробностях компонентов программного обеспечения, описание
интерфейсов, разработка требований к тестам и планам интеграции
компонентов и последующее документирование;
- тестирование и кодирование программного обеспечения. В этом
действии ведется обновление пользовательской документации путем
тестирования каждого разработанного компонента, обновляется
пользовательская документация и план интеграции программного
обеспечения;
- интеграция программного обеспечения. В этом действии ведется
тестирование программного обеспечения, а также в соответствии с планом
интеграции ведется сборка программных компонентов;
- квалификационное тестирование программного обеспечения. Здесь
в присутствии заказчика ведется тестирование программного обеспечения;
- интеграция системы. В этом действии ведется сборка программного
обеспечения, всех компонентов системы и оборудование;
- квалификационное тестирование системы. Проверка оформления,
тестирование системы на соответствие требований;
- установка программного обеспечения. В этом действии на
оборудовании заказчика ведется установка программного обеспечения;
- прием программного обеспечения. После того, как все установлено
на оборудовании заказчика ведется оценка результатов тестирования.
Основные этапы разработки программного обеспечения указаны в
ГОСТ 19.102-77 «стадии разработки»[5].
На протяжении последних тридцати лет в программировании
сменилось три модели жизненного цикла программного обеспечения:
19
каскадная, многопроходная модель и спиральная. Для разработки
дополнительного функционала для САПР «E3.Series» по заводу АО
«O`zelectroapparat-electroshield» подойдет спиральная модель жизненного
цикла.
1.4.1 Спиральная модель жизненного цикла
При создании программных систем приходится иметь дело с
характеристиками еще несуществующей системы. Идея о том, что
необходимо сформулировать все требования полностью, т.е.
исчерпывающим образом, до начала проектирования, а тем более
реализации системы, изжила себя вместе с каскадной моделью жизненного
цикла, которая поддерживала последовательную модель реализации
системы [15, с.29]. Спиральная модель, на котором базируется
большинство современных методологий, предусматривает поэтапное
выделение и детализацию требований на всем протяжении цикла
разработки системы.
На рисунке 4 показана спиральная модель жизненного цикла.
Рассмотри достоинства и недостатки этой модели.
Достоинства:
- заказчики активно участвуют в разработке, и могут видеть
разрабатываемый продукт;
- в спиральной модели входят преимущества каскадной и многопроходной
модели
Недостатки:
- исходя из последнего пункта в достоинствах этой модели, сюда и
перекочевали все недостатки, также негативная реакция заказчика
порождает новый цикл разработки и так может продолжать до
бесконечности
20
Рисунок 4 – спиральная модель ЖЦ
Существует улучшенная спиральная модель. На рисунке 5 можно её
увидеть.
Рисунок 5 – улучшенная спиральная модель
Улучшение в этой модели заключается в том, что здесь используется
каскадный подход на завершающих этапах.
Спиральную модель целесообразно использовать когда нужен
прототип, требуется проекты со средним или высоким риском, огромным
проектом и сложные требования.
21
Остальные модели жизненного цикла в приложении Б.
1.5 Способы разработки дополнительного функционала для САПР
Проанализировав технологии, этапы и жизненный цикл
программного обеспечения рассмотрим способы разработки
дополнительного функционала для САПР.
Так как на предприятии АО «O`zelectroapparat-electroshield» на
компьютерах установлена операционная система семейства windows,
рассматриваться будут способы разработки для Windows на Visual basic,
как наиболее простой в освоении (VBS для разработки с помощью
скриптов и VB.Net для Microsoft Visual Studio).
1.5.1 Разработка с помощью скриптов
На любом из известных языков программирования (в рамках данной
выпускной работы был выбран VisualBasic, как наиболее простой в
освоении) создается скрипт, извлекающий необходимую информацию из
полей базы данных, производящий требуемые операции над извлеченными
данными и помещающий результаты операций в заранее подготовленную
таблицу (форматку), также находящуюся в единой базе данных.
Скрипт – это сценарный язык, представляющий собой краткое
описание действий, выполняемый системой. В готовом виде скрипт
(сценарий) является программой, имеющая дело с готовыми
программными компонентами.
Программный скрипт представляет собой программу, которая
считывает и записывает данные непосредственно в проект. Скрипты
основаны на Общей Объектной Модели (COM). Пример кода подключения
к САПР E3.Series показано в листинге 1 (листинги составлены согласно
[6]), а результат выполнения на рисунке 6.
Текст (код) программы можно написать в любом простейшем
редакторе, сохраняющем файлы в кодировке ASCII или Юникод,