2339
.pdf-Элементы POLY интерпретируются набором заполняющих линий, причем введенное поле POLY может отличаться от перекодированного на ширину маски заполняющей линии, чтобы этого избежать, не следует делать узких вырезов в полигоне соизмеримых с маской, и, вообще, необходимо стремиться к более простым формам полигона. Следует также избегать применения круглых вырезов в полигоне (CVOD) и неортогональных ребер в полигонных вырезах (PVOD) и самом полигоне, т.к. для повышения истинности интерпретации придется (даже с использованием ключа -m) применять минимальную маску заполняющих линий, что значительно увеличит объем информационного файла.
-При перекодировке используется векторный знакогенератор со своим шрифтом, поэтому графически одна и та же буква ("XXX.PCB" и "XXX.BRD") может иметь различное (хотя и близкое) начертание. При вводе текста P-CAD не обрабатывает ширину линии, которой изображается текст. При перекодировке искусственно вводят ширину линии как функцию от высоты текста согласно приложению 9. При указании ключа (-t) используется утолщенные линии. В качестве формата выходного файла принят формат BRD. Это позволяет с минимальным уроном вписать P-CAD в архитектуру уже эксплуатируемых пакетов проектирования, использовать уже написанные программы перехода на АРМ QUEST, сервисные программы.
Следует также иметь ввиду, что отделом-изготовителем используется базовая позитивная технология изготовления ПП, а в связи с этим изображение текста на фольге ПП должно быть реверсировано. В пакетах P-CAD при вводе текста взводится специальный флаг (M-mirror) в строке статуса (М-зеленая). Программа перекодировки воспринимает флаг зеркальности.
На этом этапе особенности, связанные с использованием системы P- CAD, закончены. Выпуск КД, ТД и изготовление блока РЭА далее идет обычным путем.
Типы вентилей РЭК для конструкторско-технологического отображения
10000 - DIP;
11100 - Резисторы;
11200 - Конденсаторы;
11300 - Индуктивности;
11400 - Транзисторы;
11000 - Другие дискретные элементы;
12000 - Разъемы, перемычки;
13000 - Составные элементы.
Буквенный код. ГОСТ 2.710-81
A - Устройство (общее обозначение).
B - Преобразователи неэлектрических величин в электрические или наоборот.
BQ - Пьезоэлемент.
C- Конденсаторы.
D- Схемы интегральные. Микросборки. DA - Схема интегральная аналоговая.
DD - Схема интегральная цифровая. Логический элемент. DS - Устройство хранения информации.
DT - Устройства задержки.
E- Элементы разные.
EL - Лампа осветительная.
F - Разрядники. Предохранители. Устройства защиты.
FP - Дискретный элемент защиты по току инерционного действия; FU - Предохранитель плавкий.
G- Генераторы. Источники питания. GB - Батарея.
H- Устройства индикационные и сигнальные. HG - Индикатор символьный;
HL - Прибор световой сигнализации.
K - Реле. Контакторы. Пускатели. KA - Реле токовое;
KH - Реле указательное; KK - Реле электротепловое;
KM - Контактор, магнитный пускатель; KT - Реле времени;
KV - Реле напряжения.
L - Катушки индуктивности, дроссели. R - Резисторы.
RK - Терморезистор;
RP - Потенциометр;
RS - Шунт измерительный; RU - Варистор.
S - Устройства коммутационные в измерительных цепях, цепях управления и сигнализации.
SB - Выключатель кнопочный; SF - Выключатель автомат.
T- Трансформаторы, автотрансформаторы.
U- Устройства связи.
V - Приборы электровакуумные и полупроводниковые.
VD - Диод, стабилитрон;
VL - Прибор электровакуумный;
VT - Транзистор;
VS - Тиристор.
W - Линии и элементы СВЧ.
X - Соединения контактные.
XP - Штырь;
XS - Гнездо;
XT - Соединения разборные;
XW - Соединитель высокочастотный.
Z - Устройства оконечные, фильтры, ограничители.
ZL - Ограничитель;
ZQ - Фильтр кварцевый.
Слайд 1841 технологического оборудования фирмы QUEST
Маска 1 - Диаметр 0.25 мм. (10 DBU) Круг.
Маска 2 - Диаметр 0.3 мм. (12 DBU). Круг.
Маска 3 - Диаметр 0.35 мм.(14 DBU). Круг.
Маска 4 - Диаметр 0.4 мм. (16 DBU). Круг. Маска 5 - Сторона 0.5 мм. (20 DBU). Квадрат. Маска 6 - Диаметр 0.63 мм. (24 DBU). Круг. Маска 7 - Диаметр 0.8 мм. (32 DBU). Круг. Маска 8 - Сторона 1.2 мм. (48 DBU). Квадрат. Маска 9 - Сторона 1.4 мм. (56 DBU). Квадрат. Маска 10 - Диаметр 1.4 мм. (56 DBU). Круг. Маска 11 - Сторона 1.4 мм. (56 DBU). Квадрат. Маска 12 - Диаметр 1.6 мм. (64 DBU). Круг. Маска 13 - Диаметр 1.8 мм. (72 DBU). Круг.
Маска 14 - Удвоеная апофема 2.0 мм. (80 DBU). Восьмигранник. Маска 15 - Удвоеная апофема 2.5 мм. (100 DBU). Восьмигранник. Маска 16 - Удвоеная апофема 3.8 мм. (152 DBU). Восьмигранник.
В ходе работы с P-CAD было выявлено, что в самом начале работы по разработке РЭА очень внимательно и тщательно надо использовать или корректировать библиотеку РЭК. Исправление неверно введенных РЭК на заключительных этапах проектирования обходится очень дорого, и, в конце концов, приходится возвращаться к самому началу (к исправлению принципиальной схемы) от уже почти полностью страссированного блока. Это
объясняется тем, что в базе данных проекта помимо ссылок на файл-компонент жестко определено посадочное место РЭК и его оболочка (причем, для всех однотипных РЭК в проекте), и при изменении содержимого файла-компонента получается некая аппликация из старого и нового варианта РЭК.
CASE – ТЕХНОЛОГИИ
(Computer – Aided Software / System Engineering)
Развитие технологий создания, тиражирования и сопровождения ПО привело к созданию технологических систем, которые назвали CASEтехнологиями.
CASE – технологии используются в: создании ПО;
проектировании, исследовании предметной области средствами структурного анализа;
выпуске проектной документации; тестировании проектов;
моделировании при решении задач оперативного и стратегического планирования и управления.
CASE – технология сформировалась за последние 10 лет.
Точного определения CASE – технологии пока нет, но обычно под CASE подразумевают инструмент, позволяющий автоматизировать проектирование и разработку ПО.
СASE оформилась в научное направление в программотехнике.
Создана индустрия CASE, которая объединила сотни фирм и компаний различной ориентации:
это фирмы – разработчики средств анализа и проектирования ПО; фирмы – разработчики специальных ПО; обучающие фирмы;
фирмы, оказывающие помощь при использовании CASE – пакетов; фирмы, занимающиеся выпуском литературы по CASE.
Основные покупатели CASE – пакетов за рубежом: военные организации; центры обработки данных;
коммерческие фирмы по разработки ПО.
Считают, что CASE – наиболее перспективное направление в программотехнике. Практически ни один серьезный пакет на западе не разрабатывается без CASE.
Методология структурного системного анализа SADT принята в качестве стандарта на разработку ПО министерством обороны США.
Менеджеры и руководители компьютерных фирм обязаны знать основы структурно–системного анализа и при обсуждении профессиональных вопросов должен уметь нарисовать простейшую диаграмму, поясняющую суть дела.
Основная цель CASE – отделить проектирование от кодирования и последних этапов разработки ПО, а также скрыть от разработчиков все детали среды разработки и функционирования ПО.
В CASE – системах применяется методология структурного системного анализа, основанная на наглядных диаграммных техниках.
Для описания модели проектируемой системы используются графы, диаграммы, таблицы, схемы.
Описание системы начинается с ее обзора, затем детализируется. Таким образом строится многоуровневая иерархическая структура.
CASE – технологии не могут считаться самостоятельными методологиями, они делают эффективнее структурный системный анализ и проектирование за счет автоматизации процесса.
CASE – преимущества:
улучшают качество ПО за счет автоматического контроля (проекта); за короткое время могут создать прототип будущей системы,
следовательно, на ранних стадиях можно оценить результат разработки; ускоряют процесс проектирования и разработки; освобождают разработчика от рутинной работы; поддерживают развитие и сопровождение разработки;
поддерживают технологии повторного использования компонент разработки.
Жизненный цикл ПО
ЖЦ отражает различные состояния ПО, является моделью создания и использования ПО.
Обычно выделяют следующие этапы ЖЦ:
1.анализ требований;
2.проектирование;
3.кодирование;
4.тестирование и отладка;
5.эксплуатация и сопровождение.
Обычно ЖЦ носит итерационный характер: циклически повторяются все его этапы в связи с изменениями внешних и внутренних факторов функционирования ПО.
На любом этапе ЖЦ существует определенный набор документов и технических решений, которые поддерживают преемственность.
Остановимся на 3 основных моделях ЖЦ:
1.Каскадная модель (70 – 80 гг.) – переход на следующий этап после окончания работ на предыдущем.
2.Поэтапная модель (80 – 85 гг.) – итерационная модель с циклами обратной связи. По сравнению с каскадной моделью здесь меньше трудоемкость за счет элементарной этапной корректировки, но время жизни 1 этапа растягивается на весь период разработки.
3.Спиральная модель (86 – 90 гг.) – каждый виток соответствует созданию новой версии или фрагмента ПО, на нем планируются новые изменения нового витка. Основной упор – на анализ требований и проектирования. На первых 2-х этапах создаются прототипы,
проверяются и обосновываются технические решения. Преимущества спирали:
накопление повторное использование моделей, прототипов, программных средств;
ориентация на модификацию ПО при проектировании; анализ риска и затрат при проектировании.
Рассмотрим 2 основных этапа ЖЦ ПО.
1. Анализ требований
Уточняются требования заказчика. Должен быть четко сформулирован ответ на вопрос ―Что должна делать система?‖
Разработка концептуальной модели должна в себя включать:
условия, в которых эксплуатируется ПО (HARD и SOFT, внешние условия, состав людей и работ);
описание функции ПО; ограничения в процессе разработки (сроки, ресурсы, организация
работы, защита информации).
На основе анализа, требования формулируются как можно точнее: архитектура системы, ее функции, внешние условия, SOFT и HARD; интерфейсы и распределение функций между человеком и
компьютером; требования к программе и информационным компонентам ПО;
необходимая аппаратура; БД; физические характеристики компонентов ПО.
2. Этап проектирования
Здесь решается вопрос ―Каким образом система будет удовлетворять требованиям?‖
Исследуются:
структура системы; взаимосвязи ее элементов (без привязки к конкретной платформе).
Создается логическая модель системы, проектируется физическая ее модель. В конце строится логическая модель системы со строго сформулированными целями, пишутся спецификации физической системы. Процесс этот итерационный.
Можно выделить 2 подэтапа проектирования:
1.проектирование архитектуры ПО (сюда входят структуры и интерфейсы компонентов, согласование функций и технических требований к компонентам ПО, методам и стандартам проектирования, отчетное документирование);
2.детальное проектирование (сюда входят разработка спецификаций компонента ПО, интерфейсов между компонентами, тестов и плана
интеграции компонентов).
На 2-х этапах (анализе и проектировании) создается проект системы, достаточный для ее реализации.
Первый этап (анализ) является наиболее трудной частью разработки. Системный анализ сталкивается с огромными проблемами, возникающими
из-за взаимонепонимания заказчика и разработчика.
(Заказчик не имеет сведений о проблемах обработки информации, а аналитик не понимает специфики работы заказчика).
Аналитику следует воспользоваться методологией структурного анализа.
Структурный анализ
Это метод исследования системы, который начинается с общего обзора ее, затем детализируется. В результате получается иерархическая структура с большим числом уровней. Уровни обычно имеют 3-7 элементов.
На любом уровне включается ограниченный контекст, необходимый для детализации только на этом уровне.
На каждом уровне определяются данные и операции над ними. Существует 2 основных принципа в методологии структурного анализа:
1.Разложение сложных проблем на элементы.
2.Иерархическое упорядочивание по уровням детализации.
1 принцип позволяет трудные задачи разделять на множество мелких независимых, легких для понимания и решения.
2 принцип упрощает понимание, то есть система должна быть понятна и построена по уровням, каждый из которых добавляет новые детали.
Другие принципы разработки ПО
Абстрагирование – выделение существенных и отвлечение от несущественных аспектов системы для представления проблемы в общем виде.
Формализация – строгий методический подход к решению проблемы. Упрятывание – каждая часть на конкретном этапе ―знает только
необходимую ей информацию‖.
Концептуальная общность – единая философия на всем ЖЦ (структурный анализ структурное проектирование структурное программирование структурное тестирование).
Полнота – контроль на присутствие лишних элементов. Непротиворечивость – обоснованность и согласованность элементов. Логическая независимость – концентрация на логическом, а не
физическом проектировании. Независимость данных.
Структурирование данных – иерархическая организация и структурность данных.
Доступ конечного пользователя – пользователь должен иметь доступ к БД, которые он может использовать без программирования.
Средства структурного анализа
Для моделирования системы выявляются 3 основных характеристики системы:
1.функции, которые выполняет система;
2.отношения между данными;
3.поведение системы в реальном времени.
Для представления моделей применяют средства:
DFD (Data Flow Diagrams) - диаграммы потоков данных совместно со словарем данных и спецификациями;
ERD (Entity – Relationship Diagrams) - диаграммы ―сущность – связь‖; STD (State Transition Diagrams) - диаграммы перехода состояний.
Эти диаграммы содержат графические и текстовые средства моделирования.
|
Детализирующая DFD |
|
||
Про |
Поток |
|
Уп |
|
Хран |
равля |
|||
|
данных |
|||
|
|
ющий |
||
|
|
|
||
Спец |
Сло |
|
S |
|
ификация |
|
|
||
варь |
|
|
||
процесса |
|
|
||
данных |
|
|
||
|
|
|
||
|
Компоненты логической модели |
Любая DFD может быть детализирована с помощью DFD нижнего уровня. На самом нижнем уровне логика выражается через спецификацию процесса.
Словарь определяет структуру и компоненты потоков данных. Хранилище (накопитель) данных определяют словарем, модель хранилища данных определяется через ERD.
STD раскрывает DFD во времени.
Диаграммы потоков данных (DFD)
Изображают DFD, используя 2 нотации (формы записи): Йодана (Yourdon)
и Гейна-Сарсона (Gane-Sarson).
Символ |
Йодан |
Гейн- |
|
|
Сарсон |
|
|
|
Поток |
Имя |
Имя |
данных |
|
|
|
и |
номер |
|
мя |
имя |
Процесс |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
имя |
|
имя |
Хранили
ще
имя |
|
имя |
|
|
|
Внешняя
сущность
Потоки данных представляют собой механизмы моделирования передачи информации из одной части системы в другую.
Имя |
Ориентация стрелки показывает направление информации |
||
|
от источника к стоку. |
||
|
Сток может быть двунаправленным |
||
|
|
|
или |
Процесс –преобразует входной поток из выходного. Название процесса – это глагол в неопределенной форме с последующим дополнением (―Вычислить погрешность‖ и т.п.). Любой процесс имеет свой уникальный номер диаграммы. Этот номер используется для ссылок на процесс.
Если связать номер диаграммы и номер процесса, то получится уникальный номер процесса для всей модели.
Хранилище – определяет данные, которые сохраняются в памяти между процессами. Т. е. это ―срезы‖ потоков данных во времени. Информация из хранилища может выбираться в любое время в любом порядке. Имя хранилища
– существительное, отражающее смысл его. Если структура потока данных соответствует хранилищу, из которого входит/выходит то же имя, которое пишется в диаграмме.
Внешняя сущность (терминатор) – Сущность вне контекста системы, являющаяся источником или приемником данных. Имя – существительное.