|
Реферат: CD-Rom drivers (Программирование)
Московский Государственный Строительный Университет
Кафедра САПР в строительстве
Курсовая работа
“Приводы CD-ROM”
Выполнил: студент ЭОУС-3-11 Васильев А.В.
Проверил: Гаряев Н.А.
Москва 1997
ФОРМАТЫ И СТАНДАРТЫ
Музыкальные оптические компакт-диски пришли на смену виниловым в 1982
году - примерно в то же время, когда появились первые персональные
компьютеры фирмы IBM. Эти устройства явились результатом плодотворного
сотрудничества двух гигантов электронной промышленности - японской фирмы
Sony и голландской Philips. Строго определенная емкость компакт-дисков
связана с такой интересной историей.
Исполнительный директор фирмы Sony Акио Морита решил, что компакт-диски
должны отвечать запросам исключительно любителей классической музыки - не
более и не менее. После того, как группа разработчиков провела опрос,
выяснилось, что самым популярным классическим произведением в Японии в те
времена была 9-я симфония Бетховена, которая длилалсь 72-73 минуты. Поэтому
было решено, что компокт-диск должен быть расчитан именно на 74 минуты
звучания, а точнее, на 74 минуты и 33 секунды. Так родился стандарт,
известный как “Красная Книга” (Red Book). Когда 74 минуты пересчитали в
килобайты, получилось 640 Мбайт.
Специалисты же Philips определили минимальные требования к качеству
записи звука и регламентировала, например, такие характеристики
аудиокомпакт-дисков, как их размер, метод кодирования данных и
использование единой спиральной дорожки. В частности частота выборки
стереосигналов определялась на уровне 44.1 кГц (для одного канала 22.05
кГц), а разрядность каждого - 16 бит.
Две вышеназванные фирмы сыграли также ведущую роль при разработке первой
спецификации цифровых компакт-дисков - так называемой “Желтой Книги”
(Yellow Book), или просто CD-ROM. Она послужила основой для создания
компакт-дисков с комплексным представлением информации, то есть способных
хранить не только звуковые, но и текстовые и графические данные (CD-Digital
Audio, CD-DA). При этом привод, читая заголовок диска, сам определяел его
тип - аудио- или цифровые данные. В этом формате, однако, не
регламентировались логические и файловые форматы компакт-дисков, поскольку
решение данных вопросов было полностью отдано на откуп фирмам-
производителям. Это, в частности, означало, что компакт-диск,
соответствующий требованиям “Желтой Книги”, мог работать только на
конкретной модели накопителя. Такое положение дел, особенно в связи с
большим коммерческим успехом компакт-дисков, разумеется, не могло
удовлетворить производителей подобных устройств. В общих интересах
необходимо было срочно найти компромисс.
Именно поэтому вторым стандартом де-факто для цифровых компакт-дисков
стала спецификация HSG (High Sierra Group), или просто High Sierra. Этот
документ носил, вообще говоря, рекомендательный характер и был предложен
основными производителями цифровых компакт-дисков с целью обеспечить хотя
бы некоторую совместимость. Данная спецификация определяла уже как
логический, так и файловый форматы компакт-дисков.
Созданная спецификация оказалась настолько привлекательной, что стандарт
ISO-9660 (1988 год) для цифровых компакт-дисков , в принципе совпадал с
основными положениями HSG. Заметим, что все компакт-диски, соответствующие
требованиям стандарта ISO-9660, который определяет их логический и файловый
форматы, являются совместимыми друг с другом. В частности этот документ
определяет, каким образом найти на компакт-диске его содержимое (Volume
Table Of Contents, VTOC). Базовый формат, предложенный в HSG-спецификации,
во многом напоминал формат флоппи-диска. Как известно, системная дорожка
(трек 0) любой дискеты не только идентифицирует сам флоппи-диск (его
плотность, тип используемой ОС ), но и хранит информацию о том, как он
организован по директориям, файлам и поддиректоиям. Инициирующаая дорожка
данных на компакт-диске начинается со служебной области, необходимой для
синхронизации между приводом и диском. Далее расположена системная область
, которая содержит сведения о структурировании диска. В системной области
находятся также директории данного тома с указателями или адресами других
областей диска. Существенное различие между структурой компакт-диска и,
например, дискетой заключается в том, что на CD системная область содержит
прямой адрес файлов в поддиректориях, что должно облегчить их поиск.
Международный стандарт ISO-9660 описывает файловую систему на CD-ROM. ISO-
9660 первого уровня напоминает файловую систему MS-DOS: имена файлов могут
содержать до 8-ми символов, расширение имени файла (состоящие из 3-х
символов) отделяется от имени файла точкой. Имена файлов не могут содержать
специальных символов (“~”, “-”, “+”, “=”). При именовании файлов
используются символы только верхнего регистра, цифры и символ “_”. Имена
каталогов не могут иметь расширений. Каждый файл имеет версию; номер
версииотделяется от расширения символом “;”. Каталоги могут иметь
вложенности 8. Стандарт ISO-9660 второго уровня позволяет имспользовать в
именах файлов до 32 символов, накладывая описанные выше ограничения .
Диски, созданные с применением такого стандарта, не могут использоваться в
ряде ОС, в том числе и MS-DOS.
Спецификация CD-I (Interactive) была предложена в 1988 году. Этот
стандарт определял использование дискового плейера без подключения его к
компьтеру. Устройством отображения в данном случае должен был стать ,
например, обыкновенный телевизор. Разумеется, что использовался и его
стандартный звуковой канал. Кроме этого, CD-I предлагала несколько уровней
качества воспроизведения аудио- и графической информации. Данная
спецификация изложена в “Зеленой Книге” (Green Book). Заметим, что так
называемые CD-I-Ready-диски являются некой смесью между аудио-CD (Red Book)
и мультимедиа-диском (Green Book). Таким образом, на аудиоплэйере
прослушивается только звуковая информация, а на устройстве CD-I
воспризводится вся вместе.
Стандарт CD-ROM XA был создан в 1990 году усилиями фирм Microsoft,
Philips и Sony как “мост” между CD-ROM и CD-I. Таким образом, ХА-диск мог
воспроизводиться на CD-I-плэйере или приводе, отвечающем стандарту Yellow
Book (на прои использовании специального программного обеспечения). Формат
спецификации CD-ROM XA совместим сверху вниз с форматами, рекомендованными
High Sierra и ISO-9660. Однако в новой спецификации заложено уже гораздо
больше возможностей. Во-первых, формат ХА позволяет осуществлять
многосеансовую запись на диск. Во-вторых, основной отличительной
особенностью приводов CD-ROM ХА является так называемая техника чередования
(interleaving). Специфификация ХА позволяет одновременно хранить на диске
графические, текстовые и звуковые данные, причем графика может включать как
стандартные картинки и анимацию, так и полнооб’емное видео (full-motion).
Собственно идея
interleaving’а состоит в том, что блоки разнородной информации могут
чередоваться. Например, за первым видеофреймом может следовать сегмент с
его звуковым сопровождением, после которого расположен следующий
видеофрейм, и т.д. Это способствует повышению синхронности воспризведения
звука и видео, а так же существенному уменьшению об’ема промежуточного
буфера, необходимого для достижения синхронности при обычном расположении
инфорвации на диске.
Другой отличительной особенностью спецификации ХА является сжатие
звуковых данных, что позволяет хранить на одном диске до нескольких часов
аудиоинформации вместо обычных 74-х минут. К тому же, как известно,
качество аудио-CD обеспечивается 16-разрядным (2 байта) импульскодовым
преобразованием (РСМ) аналогового сигнала с частотой 44.1 кГц. Таким
образом, для получения стереозвучания (2 канала) скорость передачи данных
между приводом и компьютером должна составлять примерно 176ю4 Кбайт/с
(2х2х44.1). Кстати, именно поэтому минимальная скорость передачи информации
в соответствии со спецификацией РСМ уровня 1 не должна быть меньше 150
Кбайт/с. Для увеличения об’ема хранимой аудиоинформации , но при
воспроизведении ее с тем же качеством спецификация ХА предпологает
использование 4- или 8-разрядного ADPCM-кодирования. В зависимости от
предпологаемого качества воспроизведения информации (высококачественная
музыка, звуковые эффекты или речь) частота преобразования может также
варьироваться.
Еще одна спецификация, принятая в 1991 году и изложенная в “Оранжевых
Книгах” (Оrange Books), относится к записываемым и стираемым дискам. В
первой книге речь идет о магнитооптических дисках (CD-MO), которые
допускают как стирание, так и перезапись информации. Вторая книга посвящена
накопителям с однократной записью типа WORM (Write Once Raed Many).
Информацию на их носители только дозаписать, а не переписать заново. К
подобным накопителям относятся устройстваё, отвечающие, например,
спецификации CD-ROM XA.
В 1993 году была анонсирована еще одна книга - White Book (“Белая”). В
ее создании приняли участие JVC, Matsushita, Philips и Sony. В этом
документе определялись основные параметры видео-CD - компакт-диска, на
котором можно было хранить 72 минуты высококачественного видео вместе со
стереозвуком. Хранение данных на видео-CD базируется на методе сжатия
информации, называемом MPEG (Motion Picture Experts Group). Видео-CD могут
воспроизводиться на специальных видео-CD-плэйерах, CD-I-плэйерах со
специальным картриджем “Digital Video”, а также на компьютере со
специальной платой MPEG-декодера и приводом CD-ROM.
Вообще говоря, стандарт MPEG не определяет форматов записи данных на
носителях. Одним из возможных способов хранения данных может быть CD-I-
компакт-диск (“Зеленая Книга”). Этот диск воспроизводится на CD-I-плэйерах,
когда они оснащены декодарами или картриджами типа “Digital Video”.
Например, практически все цифровые видефильмы проданные Philips до июля
1994 года, соответствовали стандарту Green Book и могли воспроизводиться
только на CD-I-плэйерах. Впрочем, если быть совсем точным, стоит отметить ,
что CD-I MPEG-диски могут воспроизводиться на других типах плэйеров, скажем
на Commodore CD32. Для ПК в этом случае можно использовать ReelMagic PC
Upgrade Kit. Другим способом хранения полноскоростного цифрового видео,
сжатого по методу MPEG, может служить компакт-диск ISO-9660 (Yellow Book).
Спецификация White Book является в настоящее время идеальным средством
для хранения цифрового видео - это единственный стандартный путь
воспризведения видео на мультимедиа-PC.
После принятия спецификации White Book были пересмотрены и переделаны с
ее учетом первые версии стандарта Green Book. Мир цифрового видео стал
принадлежать “Белой Книге”.
В конце 1994 года были анонсированы так назывемые музыкальные
мультимедиа-компакт-диски.ЖДанная спецификация носит название CD Plus.
Подобные диски содержат два сеанса (сессии), один из которых - аудио, а
другой - CD-ROM. Записанную музыку можно прослушивать на аудиоплэйере, а
доступ к мультимедиа-информации (и музыке) возможен на приводе,
подключенном к ПК.
Итак, были рассмотрены практически все наиболее распространенные форматы
хранения данных на CD-ROM. Как уже было сказано, отличительной особенностью
всех этих форматов является их отличие от файловой системы, используемой в
MS-DOS. Таким образом, для доступа к данным, хранимым на CD-ROM, необходимо
преобразование форматов. Для этих целей фирма Microsoft выпустила
специальный драйвер, который называется Microsoft CD Zextention
(mscdex.exe). Он входит в комплект поставки MS-DOS, а также поставляется
практически со всеми приводами CD-ROM.
УСТРОЙСТВО И ПРИНЦИП РАБОТЫ
Как известно, большенство накопителей бывают внешними и встраиваемыми
(нутренними). Приводы компакт-дисков в этом смысле не являются исключением.
Большинство предлагаемых в настоящее время накопителей CD-ROM относятся к
встраиваемым. Внешний накопитель, как правило, стоит заметно дороже. Форм-
фактор современного встриваемого CD-ROM определяется двумя параметрами:
половинной высотой (Half-High, HH) и горизонтальным размером 5.25 дюйма.
Таким образом, для установки подобного накопителя в компьютер требуется
свободный монтажный отсек 5.25 дюйма.
На передней панели каждого накопителя имеется доступ к механизму
загрузки компакт-диска в привод. Также там расположены индикатор работы
устройства (обычно Busy), гнездо для подключеня наушников или стереосистемы
(для прослушивания аудиодисков), а также регулятор громкости (также для
аудио-CD). Кроме того, при использовании контейнера на передней панели
имеется отверстие, с помощью которого можно извлечь компакт-диск даже в
аварийной ситуации, например если не срабатывает кнопка Eject.
На задней панели практически всех без исключения приводов CD-ROM
находятся по крайней мере три раз’ема: интерфейсный, питания и аудио.
Назначение первых двух, видимо, не вызывает вопросов. Раз’ем для вывода
звука позволяет подключать привод к звуковой карте. Это удобно при
прослушивании аудиодисков, поскольку не требует переключения акустической
системы или наушников с одногогнезда на другое.
Кроме этих раз’емов при использовании SCSI-интерфейса с задней панели
привода доступны также резисторы-терминаторы устройства и набор перемычек
(jumpers), или переключателей (switches), которые определяют номер
устройства и режим работы. Не следует забывать, что резисторы-терминаторы
должны быть установлены на host-адапторе SCSI и приводе компакт-дисков,
если к шине интерфейса не подключены другие устройства.
В приводе компакт-дисков можно выделить несколько базовых элементов:
лазерный диод, сервомотор, оптическую систему (включающую в себя
расщепляющую призму) и фотодетектор.
И так, считывание информации с компакт-диска, так же как и запись,
происходит при помощи лазерного луча, но, разумеется, меньшей мощности.
Сервомотор по команде внутреннего микропроцессора привода перемещает
отражающее зеркало. Это позволяет точно позиционировать лазерный луч на
конкретную дорожку. Такой луч, попадая на отражающий свет островок, через
расщепляющую линзу отклоняется на фотодетектор, который интерпретирует это
как двоичную единицу. Луч лазера, попадающий во впадину, рассеивается и
поглощается - фотодетектор фиксирует двоичный ноль (цифровая информация
представляется чередованием впадин (неотражающих пятен) и отражающих свет
островков). В качестве отражающей поверхности компак-дисков обычно
используется алюминий. Разумеется, вся поверхность компакт-диска покрыта
прозрачным защитным слоем.
В отличие от, например, винчестеров, дорожки которых представляют
собойконцентрические окружности, компакт-диск имеет всего одну физическую
дорожку в форме непрерывной спирали, идущей от внутреннего диаметра к
наружному. Тем не менее одна физическая дорожка может быть разбита на
несколько логических.
В то время, как все магнитные диски вращаются с постоянным числом
оборотов в минуту, т.е. с неизменной угловой скоростью (CAV, Constant
Angular Velocity), компакт-диск вращается обычно с переменной угловой
скоростью, чтобы обеспечить постоянную линейную скорость при чтении (CLV,
Constant Linear Velocity). Таким образом, чтение внутренних секторов
осуществляется с увеличенным, а наружных - с уменьшенным числом оборотов.
Именно этим обусловливается достаточно низкая скорость доступа к данным для
компакт-дисков по сравнению, например, с винчестерами.
В последнее время появились так называемые перезаписываемые компакт-
диски CD-R (CD-Recordable). Носители типа CD-R могут быть записаны самим
пользователем на специальном CD-R-приводе. В основном здесь применяются
технологии, основанные на изменении отражающих свойств вещества подложки
компакт-диска под действием луча лазера. Кстати, надо заметить, что
перезаписываемые компакт-диски в несколько раз дороже обычных. Дело в том,
что в качестве светоотражающего слоя в них используется уже не алюминий, а
золото (подобные диски обычно служат как мастерные для дальнейшего
тиражирования). Читать CD-R-диски можно на обычном приводе, но, разумеется,
только первый сеанс записи.
ИНТЕРФЕЙСЫ
Довольно часто фирмы производители поставляют привод CD-ROM с
обязательной картой контроллера, на которой реализован так называемый
(собственный) proprietary-интерфейс. Обычно это собственная реализация
одной из версий интерфейсов IDE или SCSI. Часто при покупке накопителя на
CD-ROM в составе Multimedia Kit на звуковой карте находится именно
proprietary-интерфейс. Стандартами де-факто для интерфейсов приводов
компакт-дисков стали спецификации Mitsumi, Panasonic и Sony. Одним из
популярных интерфейсов всех приводов, включая приводо CD-ROM, является SCSI
или SCSI-2.
Как известно, отличительной особенностью интерфейса IDE является
реализация функции контроллера в самом накопителе. Именно поэтому
подключение подобных приводов к компьютеру выполняется через достаточно
простенькую плату адаптера. Данный интерфейс поддерживает, как правило
программный ввод-вывод. Подсоединение привода к плате интерфейса
выполняется посредством плоского кабеля, который отличается обычно по числу
контактов в зависимости от фирмы - производителя накопителя ( Sony - 34-
контактный, Panasonic - 40-контактный кабель).
Компания Western Digital разработала так называемую спецификацию
Enchanced IDE. Этот документ поддержали практически все ведущие компании по
производству накопителей. Новый интерфейс позволяет подключать одновременно
до четырех приводов жестких дисков. Но самое главное, спецификация
Enchanced IDE позволяет не только увеличить количество подключаемых
устройств, но и использовать другие типы устройств, например приводы CD-ROM
или стримеры. В частности, Western Digital для поддержки накопителей CD-ROM
с интерфейсом IDE предлагает протокол ATAPI (ATA Packed Interface). ATAPI
является расширением протокола ATA и требует незначительных изменений в
системной BIOS. В общем случае используется специальный драйвер. В
последнее время появились накопители, которые поддерживают не только
интерфейс IDE, но и EIDE/ATAPI.
Как известно, интерфейс SCSI стал одним из важнейших промышленных
стандартов для подключения таких периферийных устройств, как, например,
винчестеры, стримеры, лазерные принтеры, приводы CD-ROM и т.п. Необходимо
отметить, что SCSI - интерфейс более высокого уровня, нежели IDE. Физически
SCSI-шина представляет собой плоский кабель с 50-контактными раз’емами,
через которые можно подключить до восьми периферийных устройств. Стандарт
SCSI определяет два способа передачи сигналов - синфазный и
дифференциальный. Версии шины SCSI с дифференциальной передачей сигнала
даят увеличить длину шины. Чтобы гарантировать качество сигналов на
магистрали SCSI, линии шины должны иметь согласование с обеих сторон (набор
согласующих резисторов, или терминатор).
Версия интерфейса SCSI-2 позволяет повысить пропускную способность
магистрали за счет увеличения тактовой частоты обмена и сокращения
критических временных параметров шины, применения новейших БИС и
высококачественных кабелей. Таким образом реализуется “скоростной” вариант
SCSI-2 - Fast SCSI-2. “Широкий” (Wide SCSI-2) вариант магистрали,
предусматривает наличие дополнительных 24 линий данных благодаря
подключению второго 68-проводного кабеля (для приводов CD-ROM не
применяется). Обычно скорость передачи данных по шине SCSI(-2) для приводов
CD-ROM достигает от1.5-2 до 3-4 Мбайт/с.
Несмотря на стандартность интерфейса SCSI, проблема совместимости
приводов с SCSI-адаптерами по-прежнему остается. В случае реализации
собственного интерфейса подключение других устройств, кроме привода CD-ROM,
достаточно проблематично. Здесь следует отметить, что существует
спецификация ASPI (Advanced SCSI Programming Interface), которую
разработала фирма Adaptec - ведущий призводителеь адаптеров SCSI. ASPI
определяет стандартный программный интерфейс для основного (host) адаптера
SCSI. Программные модули ASPI достаточно легко стыкуются друг с другом.
Основным программным модулем ASPI является ASPI-хост-менеджер. С ним
связываются программы-фрайверы ASPI, например, для таких устройств, как
приводы CD-ROM, флоптические и сменные жесткие диски, сканеры и т.д.
В том случае, если производитель SCSI-устройства поставляет ASPI-
совместимый драйвер, то он совместим со всеми хост-адаптерами или
интерфейсными картами Adaptec и большинства других производителей.
К сожалению, в ряде случаев производители приводов CD-ROM поставляют
свою карту контроллера с собственным (несовместимым с ASPI) драйвером,
называя интерфейс SCSI. Это следует иметь в виду, если вы хотите подключить
к SCSI другие устройства.
Какой же из интерфейсов предпочтительней использовать в IBM PC-
совместимых компьютерах для приводов CD-ROM? Хотя теоретически интерфейс
SCSI может обеспечить скорость обмена несколько выше, нежели IDE, на
практике все обстоит несколько сложнее. Не следует забывать, например, тот
факт, что IDE-интерфейс использует в основном прграммный ввод-вывод, а SCSI-
устройства в большенстве случаев - передачу данных по прямому доступу к
памяти. В однопользовательсктх системах программный ввод-вывод часто
оказывается гораздо эффективнее. Это особенно четко проявляется при
использовании улучшенных алгоритмов кэширования. Преймущество SCSI-
адаптеров неоспоримо в первую очередь в многозадачных и
многопользовательских системах. Дело в том, что команды для SCSI-устройства
могут быть построены в очередь, что освобождает процессор для выполнения
других операций. Кроме того, если привод CD-ROM используется в локальной
сети как коллективное устройство, альтернативы SCSI, пожалуй, пока нет.
С другой стороны, установка IDE-привода достаточно проста. В большенстве
случаев справедлив принцип “включай и работай”. Для нормальной работы в
файлы конфигурации системы обычно не требуется добавлять никаких
дополнительных программных драйверов.
Для SCSI-адаптера процесс установки более сложен. Во-первых, следует
помнить о разделяемых системных ресурсах: портах ввода-вывода, прерываниях
IRQ, каналах прямого доступа к памяти DMA, областях в верхней памяти UMB.
Во-вторых, требуется верно определить SCSI ID для конкретного устройства, в-
третьих, не следует забывать, сигнале четности (запретить или разрешить),
установке терминаторов и т.д. Кроме того, файлы конфигурации обязательно
должны быть дополнены соответствующими программными драйверами адаптера и
устройств.
Что же касается стоимости, то SCSI-адаптера обычно в компьютере нет и
его приходится покупать дополнительно.
ОСНОВНЫЕ ПАРАМЕТРЫ ПРИВОДОВ
Скорость доступа (access time) определяет среднее время (в
миллисекундах), необходимое для обнаружения и загрузки первого блока данных
во внутренний буфер. Стандарт MPC 1 устанавливает такое время в одну
секунду или менее, но большенство современных приводов имеют скорость
доступа около 0.3 с. Разумеется, этот параметр не включает в себя время,
необходимое для выхода двигателя на рабочий режим.
Скорость передачи данных (dats-transfer rate) зависит от двух факторов -
плотности данных и скорости вращения диска. Под плотностью в данном случае
понимают количество бит (впадин) на дюйм (или миллиметр). Так, для 16-
битного стереосигнала качества аудио-CD (частота 44.1 кГц) скорость должна
быть 1.4 Мбита/с. Разделив это значени на число бит в байте (8), мы получим
176.4 Кбайта/с - усредненное значение для скорости передачи данных.
Стандарт МСР 1 определяет скорость передачи данных как 150 Кбайт/с, МСР 2 -
300 Кбайт/с. В настоящее время наибольшее распространение получили приводы,
использующие технологию удвоения скорости вращения диска. Именно в этом
случае скорость передачи достигает значения 300 Кбайт/с. Подобные
устройства удовлетворяют спецификации МСР 2, поскольку имеют время поиска
менее 400 мс. Сравнительно недавно появились модели приводов с утроенной,
учетверенной и даже ушестеренной скоростью вращения. Пионером в технологии
увеличения скорости являются, например, фирмы NEC и Plextor.
Под размером блока данных (data block size) понимают минимальное
количество байт, которые передаются на компьютер через интерфейсную карту.
Иначе говоря, это единица информации, с которой оперирует контроллер
привода. Минимальный размер блока данных в соответствии со спецификацией
МРС равен 16 Кбайт. Поскольку файлы на компакт-диске обычно достаточно
большие, то промежутки между блоками данных ничтожно малы.
Размер буфера - размер внутреннего буфера (кэш-памяти),в который
считываются файлы перед их передачей. Стандарт МРС устанавливает размер
буфера в 64 Кбайт, а это в буфере будет находиться около 0.4 секунды 16-
битного стереосигнала качества CD-Audio (частоты 44.1 кГц). Для скоростных
устройств размер буфера может достигать 256 Кбайт и даже 1 Мбайта.
Поддержка проигрывания аудиодисков означает, что с помощью привода CD-
ROM вы сможете слушать обычные музыкальные компакт-диски. Этой возможностью
обладают практически все современные модели приводов. Некоторые модели не
требуют для этого специальных программ - воспризведение аудио-CD
выполняется на “аппаратном” уровне. Для включения этого режима на передней
панели привода имеется специальная кнопка.
Поддержка формата CD-ROM/XA. Подразумевается использование дисков
формата ХА, поддерживающего хранение аудио- и видеоданных единым блоком, в
который также включается информация о синхронизации звука. Данные на
аудиодисках и CD-ROM хранятся на дорожках, вмещающих 24-байтовые “кадры”,
проигрываемые со скоростью 75 кадров в секунду. Хранящиеся данные могут
включать звук, текст, статические и динамическме изображения. При
содержании в обычнои формате каждый тип должен располагаться на отдельной
дорожке, когда в формате ХА данные различного типа могут храниться на одной
дорожке.
Тип загрузки диска. Существует два типа приводов CD-ROM. В первом случае
диск устанавливается напрямую (например, в приводах Mitsumi). Во втором
случае для установки диска используется специальная кассета, называемая
кэдди (caddy). Недорогие односкоростные модели с прямой установкой диска
обычно представляют собой версии аудио-CD-плэйеров. Для прослушивания
аудиодисков на приводе CD-ROM, последний должен обеспечивать эту
возможность. Если есть возможность выбора, то лучше остановиться на моделях
с автоматической очисткой линз и протиркой диска при его загрузке. Обычно
эти опции существенно не влияют на цену.
Литература: Мультимедиа для всех, 2-е издание.
Авторы: А.Бозенко, А.Федоров.
Реферат на тему: Case-технлогии
Министерство общего и профессионального образования Российской Федерации
Волгоградский государственный технический Университет
Кафедра САПР
Реферат на тему: “CASE-технологии. Современные методы и средства
проектирования информационных систем”
Выполнил: Кудряшов
Павел Павлович ИВТ-
262
Проверил: Н.П.
Волгоград 2000
План:
Введение 3
1. Основы методологии проектирования ИС 5
1.1. Жизненный цикл по ИС 5
1.2. Модели жизненного цикла ПО 6
1.3. Методологии и технологии проектирования ИС
8
1.3.1. Общие требования к методологии и технологии
8
1.3.2. Методология RAD 10
2. Структурный подход к проектированию ИС
12
2.1. Сущность структурного подхода 12
2.2. Методология функционального моделирования SADT 13
2.2.1. Состав функциональной модели 14
2.2.2. Иерархия диаграмм 14
2.2.3. Типы связей между функциями 17
2.3. Моделирование потоков данных (процессов) 20
2.3.1. Внешние сущности 20
2.3.2. Системы и подсистемы 20
2.3.3. Процессы 21
2.3.4. Накопители данных 21
2.3.5. Потоки данных 21
2.3.6. Построение иерархии диаграмм потоков данных 22
2.4. Моделирование данных 23
2.4.1. Case-метод Баркера 23
2.4.2. Методология IDEF1 27
3. Характеристики CASE-средств 29
3.1. Silverrun+JAM 29
3.1.1. Silverrun 29
3.1.2. JAM 30
3.2. Vantage Team Builder (Westmount I-CASE) + Uniface
33
3.2.1. Vantage Team Builder (Westmount I-CASE)
33
3.2.2. Uniface 35
3.3. Designer/2000 + Developer/2000 36
3.4. Локальные средства (ERwin, BPwin, S-Designor, CASE.Аналитик)
37
3.5. Объектно-ориентированные CASE-средства (Rational Rose)
38
3.6. Вспомогательные средства поддержки жизненного цикла ПО
40
3.6.1. Средства конфигурационного управления
40
3.6.2. Средства документирования 42
3.6.3. Средства тестирования 43
3.7. Примеры комплексов CASE-средств 43
Литература 45
Введение
Целью данного обзора является введение в особенности современных методов и
средств проектирования информационных систем, основанных на использовании
CASE-технологии.
Несмотря на высокие потенциальные возможности CASE-технологии (увеличение
производительности труда, улучшение качества программных продуктов,
поддержка унифицированного и согласованного стиля работы) далеко не все
разработчики информационных систем, использующие CASE-средства, достигают
ожидаемых результатов.
Существуют различные причины возможных неудач, но, видимо, основной
причиной является неадекватное понимание сути программирования
информационных систем и применения CASE-средств. Необходимо понимать, что
процесс проектирования и разработки информационной системы на основе CASE-
технологии не может быть подобен процессу приготовления пищи по поваренной
книге. Всегда следует быть готовым к новым трудностям, связанным с
освоением новой технологии, последовательно преодолевать эти трудности и
последовательно добиваться нужных результатов.
Тенденции развития современных информационных технологий приводят к
постоянному возрастанию сложности информационных систем (ИС), создаваемых в
различных областях экономики. Современные крупные проекты ИС
характеризуются, как правило, следующими особенностями:
сложность описания (достаточно большое количество функций, процессов,
элементов данных и сложные взаимосвязи между ними), требующая тщательного
моделирования и анализа данных и процессов;
наличие совокупности тесно взаимодействующих компонентов (подсистем),
имеющих свои локальные задачи и цели функционирования (например,
традиционных приложений, связанных с обработкой транзакций и решением
регламентных задач, и приложений аналитической обработки (поддержки
принятия решений), использующих нерегламентированные запросы к данным
большого объема);
отсутствие прямых аналогов, ограничивающее возможность использования каких-
либо типовых проектных решений и прикладных систем;
необходимость интеграции существующих и вновь разрабатываемых приложений;
функционирование в неоднородной среде на нескольких аппаратных платформах;
разобщенность и разнородность отдельных групп разработчиков по уровню
квалификации и сложившимся традициям использования тех или иных
инструментальных средств;
существенная временная протяженность проекта, обусловленная, с одной
стороны, ограниченными возможностями коллектива разработчиков, и, с другой
стороны, масштабами организации-заказчика и различной степенью готовности
отдельных ее подразделений к внедрению ИС.
Для успешной реализации проекта объект проектирования (ИС) должен быть
прежде всего адекватно описан, должны быть построены полные и
непротиворечивые функциональные и информационные модели ИС. Накопленный к
настоящему времени опыт проектирования ИС показывает, что это логически
сложная, трудоемкая и длительная по времени работа, требующая высокой
квалификации участвующих в ней специалистов. Однако до недавнего времени
проектирование ИС выполнялось в основном на интуитивном уровне с
применением неформализованных методов, основанных на искусстве,
практическом опыте, экспертных оценках и дорогостоящих экспериментальных
проверках качества функционирования ИС. Кроме того, в процессе создания и
функционирования ИС информационные потребности пользователей могут
изменяться или уточняться, что еще более усложняет разработку и
сопровождение таких систем.
В 70-х и 80-х годах при разработке ИС достаточно широко применялась
структурная методология, предоставляющая в распоряжение разработчиков
строгие формализованные методы описания ИС и принимаемых технических
решений. Она основана на наглядной графической технике: для описания
различного рода моделей ИС используются схемы и диаграммы. Наглядность и
строгость средств структурного анализа позволяла разработчикам и будущим
пользователям системы с самого начала неформально участвовать в ее
создании, обсуждать и закреплять понимание основных технических решений.
Однако, широкое применение этой методологии и следование ее рекомендациям
при разработке конкретных ИС встречалось достаточно редко, поскольку при
неавтоматизированной (ручной) разработке это практически невозможно.
Действительно, вручную очень трудно разработать и графически представить
строгие формальные спецификации системы, проверить их на полноту и
непротиворечивость, и тем более изменить. Если все же удается создать
строгую систему проектных документов, то ее переработка при появлении
серьезных изменений практически неосуществима. Ручная разработка обычно
порождала следующие проблемы:
неадекватная спецификация требований;
неспособность обнаруживать ошибки в проектных решениях;
низкое качество документации, снижающее эксплуатационные качества;
затяжной цикл и неудовлетворительные результаты тестирования.
С другой стороны, разработчики ИС исторически всегда стояли последними в
ряду тех, кто использовал компьютерные технологии для повышения качества,
надежности и производительности в своей собственной работе (феномен
"сапожника без сапог").
Перечисленные факторы способствовали появлению программно-технологических
средств специального класса - CASE-средств, реализующих CASE-технологию
создания и сопровождения ИС. Термин CASE (Computer Aided Software
Engineering) используется в настоящее время в весьма широком смысле.
Первоначальное значение термина CASE, ограниченное вопросами автоматизации
разработки только лишь программного обеспечения (ПО), в настоящее время
приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом.
Теперь под термином CASE-средства понимаются программные средства,
поддерживающие процессы создания и сопровождения ИС, включая анализ и
формулировку требований, проектирование прикладного ПО (приложений) и баз
данных, генерацию кода, тестирование, документирование, обеспечение
качества, конфигурационное управление и управление проектом, а также другие
процессы. CASE-средства вместе с системным ПО и техническими средствами
образуют полную среду разработки ИС.
Появлению CASE-технологии и CASE-средств предшествовали исследования в
области методологии программирования. Программирование обрело черты
системного подхода с разработкой и внедрением языков высокого уровня,
методов структурного и модульного программирования, языков проектирования и
средств их поддержки, формальных и неформальных языков описаний системных
требований и спецификаций и т.д. Кроме того, появлению CASE-технологии
способствовали и такие факторы, как:
подготовка аналитиков и программистов, восприимчивых к концепциям
модульного и структурного программирования;
широкое внедрение и постоянный рост производительности компьютеров,
позволившие использовать эффективные графические средства и
автоматизировать большинство этапов проектирования;
внедрение сетевой технологии, предоставившей возможность объединения усилий
отдельных исполнителей в единый процесс проектирования путем использования
разделяемой базы данных, содержащей необходимую информацию о проекте.
CASE-технология представляет собой методологию проектирования ИС, а также
набор инструментальных средств, позволяющих в наглядной форме моделировать
предметную область, анализировать эту модель на всех этапах разработки и
сопровождения ИС и разрабатывать приложения в соответствии с
информационными потребностями пользователей. Большинство существующих CASE-
средств основано на методологиях структурного (в основном) или объектно-
ориентированного анализа и проектирования, использующих спецификации в виде
диаграмм или текстов для описания внешних требований, связей между моделями
системы, динамики поведения системы и архитектуры программных средств.
Согласно обзору передовых технологий (Survey of Advanced Technology),
составленному фирмой Systems Development Inc. в 1996 г. по результатам
анкетирования более 1000 американских фирм, CASE-технология в настоящее
время попала в разряд наиболее стабильных информационных технологий (ее
использовала половина всех опрошенных пользователей более чем в трети своих
проектов, из них 85% завершились успешно). Однако, несмотря на все
потенциальные возможности CASE-средств, существует множество примеров их
неудачного внедрения, в результате которых CASE-средства становятся
"полочным" ПО (shelfware). В связи с этим необходимо отметить следующее:
CASE-средства не обязательно дают немедленный эффект; он может быть получен
только спустя какое-то время;
реальные затраты на внедрение CASE-средств обычно намного превышают затраты
на их приобретение;
CASE-средства обеспечивают возможности для получения существенной выгоды
только после успешного завершения процесса их внедрения.
Ввиду разнообразной природы CASE-средств было бы ошибочно делать какие-либо
безоговорочные утверждения относительно реального удовлетворения тех или
иных ожиданий от их внедрения. Можно перечислить следующие факторы,
усложняющие определение возможного эффекта от использования CASE-средств:
широкое разнообразие качества и возможностей CASE-средств;
относительно небольшое время использования CASE-средств в различных
организациях и недостаток опыта их применения;
широкое разнообразие в практике внедрения различных организаций;
отсутствие детальных метрик и данных для уже выполненных и текущих
проектов;
широкий диапазон предметных областей проектов;
различная степень интеграции CASE-средств в различных проектах.
Вследствие этих сложностей доступная информация о реальных внедрениях
крайне ограничена и противоречива. Она зависит от типа средств,
характеристик проектов, уровня сопровождения и опыта пользователей.
Некоторые аналитики полагают, что реальная выгода от использования
некоторых типов CASE-средств может быть получена только после одно- или
двухлетнего опыта. Другие полагают, что воздействие может реально
проявиться в фазе эксплуатации жизненного цикла ИС, когда технологические
улучшения могут привести к снижению эксплуатационных затрат.
Для успешного внедрения CASE-средств организация должна обладать следующими
качествами:
Технология. Понимание ограниченности существующих возможностей и
способность принять новую технологию;
Культура. Готовность к внедрению новых процессов и взаимоотношений между
разработчиками и пользователями;
Управление. Четкое руководство и организованность по отношению к наиболее
важным этапам и процессам внедрения.
Если организация не обладает хотя бы одним из перечисленных качеств, то
внедрение CASE-средств может закончиться неудачей независимо от степени
тщательности следования различным рекомендациям по внедрению.
Для того, чтобы принять взвешенное решение относительно инвестиций в CASE-
технологию, пользователи вынуждены производить оценку отдельных CASE-
средств, опираясь на неполные и противоречивые данные. Эта проблема
зачастую усугубляется недостаточным знанием всех возможных "подводных
камней" использования CASE-средств. Среди наиболее важных проблем
выделяются следующие:
достоверная оценка отдачи от инвестиций в CASE-средства затруднительна
ввиду отсутствия приемлемых метрик и данных по проектам и процессам
разработки ПО;
внедрение CASE-средств может представлять собой достаточно длительный
процесс и может не принести немедленной отдачи. Возможно даже краткосрочное
снижение продуктивности в результате усилий, затрачиваемых на внедрение.
Вследствие этого руководство организации-пользователя может утратить
интерес к CASE-средствам и прекратить поддержку их внедрения;
отсутствие полного соответствия между теми процессами и методами, которые
поддерживаются CASE-средствами, и теми, которые используются в данной
организации, может привести к дополнительным трудностям;
CASE-средства зачастую трудно использовать в комплексе с другими подобными
средствами. Это объясняется как различными парадигмами, поддерживаемыми
различными средствами, так и проблемами передачи данных и управления от
одного средства к другому;
некоторые CASE-средства требуют слишком много усилий для того, чтобы
оправдать их использование в небольшом проекте, при этом, тем не менее,
можно извлечь выгоду из той дисциплины, к которой обязывает их применение;
негативное отношение персонала к внедрению новой CASE-технологии может быть
главной причиной провала проекта.
Пользователи CASE-средств должны быть готовы к необходимости долгосрочных
затрат на эксплуатацию, частому появлению новых версий и возможному
быстрому моральному старению средств, а также постоянным затратам на
обучение и повышение квалификации персонала.
Несмотря на все высказанные предостережения и некоторый пессимизм,
грамотный и разумный подход к использованию CASE-средств может преодолеть
все перечисленные трудности. Успешное внедрение CASE-средств должно
обеспечить такие выгоды как:
высокий уровень технологической поддержки процессов разработки и
сопровождения ПО;
положительное воздействие на некоторые или все из перечисленных факторов:
производительность, качество продукции, соблюдение стандартов,
документирование;
приемлемый уровень отдачи от инвестиций в CASE-средства.
1. Основы методологии проектирования ИС
1.1. Жизненный цикл по ИС
Одним из базовых понятий методологии проектирования ИС является понятие
жизненного цикла ее программного обеспечения (ЖЦ ПО). ЖЦ ПО - это
непрерывный процесс, который начинается с момента принятия решения о
необходимости его создания и заканчивается в момент его полного изъятия из
эксплуатации.
Основным нормативным документом, регламентирующим ЖЦ ПО, является
международный стандарт ISO/IEC 12207 [5] (ISO - International Organization
of Standardization - Международная организация по стандартизации, IEC -
International Electrotechnical Commission - Международная комиссия по
электротехнике). Он определяет структуру ЖЦ, содержащую процессы, действия
и задачи, которые должны быть выполнены во время создания ПО.
Структура ЖЦ ПО по стандарту ISO/IEC 12207 базируется на трех группах
процессов:
основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация,
сопровождение);
вспомогательные процессы, обеспечивающие выполнение основных процессов
(документирование, управление конфигурацией, обеспечение качества,
верификация, аттестация, оценка, аудит, решение проблем);
организационные процессы (управление проектами, создание инфраструктуры
проекта, определение, оценка и улучшение самого ЖЦ, обучение).
Разработка включает в себя все работы по созданию ПО и его компонент в
соответствии с заданными требованиями, включая оформление проектной и
эксплуатационной документации, подготовку материалов, необходимых для
проверки работоспособности и соответствующего качества программных
продуктов, материалов, необходимых для организации обучения персонала и
т.д. Разработка ПО включает в себя, как правило, анализ, проектирование и
реализацию (программирование).
Эксплуатация включает в себя работы по внедрению компонентов ПО в
эксплуатацию, в том числе конфигурирование базы данных и рабочих мест
пользователей, обеспечение эксплуатационной документацией, проведение
обучения персонала и т.д., и непосредственно эксплуатацию, в том числе
локализацию проблем и устранение причин их возникновения, модификацию ПО в
рамках установленного регламента, подготовку предложений по
совершенствованию, развитию и модернизации системы.
Управление проектом связано с вопросами планирования и организации работ,
создания коллективов разработчиков и контроля за сроками и качеством
выполняемых работ. Техническое и организационное обеспечение проекта
включает выбор методов и инструментальных средств для реализации проекта,
определение методов описания промежуточных состояний разработки, разработку
методов и средств испытаний ПО, обучение персонала и т.п. Обеспечение
качества проекта связано с проблемами верификации, проверки и тестирования
ПО. Верификация - это процесс определения того, отвечает ли текущее
состояние разработки, достигнутое на данном этапе, требованиям этого этапа.
Проверка позволяет оценить соответствие параметров разработки с исходными
требованиями. Проверка частично совпадает с тестированием, которое связано
с идентификацией различий между действительными и ожидаемыми результатами и
оценкой соответствия характеристик ПО исходным требованиям. В процессе
реализации проекта важное место занимают вопросы идентификации, описания и
контроля конфигурации отдельных компонентов и всей системы в целом.
Управление конфигурацией является одним из вспомогательных процессов,
поддерживающих основные процессы жизненного цикла ПО, прежде всего процессы
разработки и сопровождения ПО. При создании проектов сложных ИС, состоящих
из многих компонентов, каждый из которых может иметь разновидности или
версии, возникает проблема учета их связей и функций, создания
унифицированной структуры и обеспечения развития всей системы. Управление
конфигурацией позволяет организовать, систематически учитывать и
контролировать внесение изменений в ПО на всех стадиях ЖЦ. Общие принципы и
рекомендации конфигурационного учета, планирования и управления
конфигурациями ПО отражены в проекте стандарта ISO 12207-2 [5].
Каждый процесс характеризуется определенными задачами и методами их
решения, исходными данными, полученными на предыдущем этапе, и
результатами. Результатами анализа, в частности, являются функциональные
модели, информационные модели и соответствующие им диаграммы. ЖЦ ПО носит
итерационный характер: результаты очередного этапа часто вызывают изменения
в проектных решениях, выработанных на более ранних этапах.
1.2. Модели жизненного цикла ПО
Стандарт ISO/IEC 12207 не предлагает конкретную модель ЖЦ и методы
разработки ПО (под моделью ЖЦ понимается структура, определяющая
последовательность выполнения и взаимосвязи процессов, действий и задач,
выполняемых на протяжении ЖЦ. Модель ЖЦ зависит от специфики ИС и специфики
условий, в которых последняя создается и функционирует). Его регламенты
являются общими для любых моделей ЖЦ, методологий и технологий разработки.
Стандарт ISO/IEC 12207 описывает структуру процессов ЖЦ ПО, но не
конкретизирует в деталях, как реализовать или выполнить действия и задачи,
включенные в эти процессы.
К настоящему времени наибольшее распространение получили следующие две
основные модели ЖЦ:
каскадная модель (70-85 г.г.);
спиральная модель (86-90 г.г.).
В изначально существовавших однородных ИС каждое приложение представляло
собой единое целое. Для разработки такого типа приложений применялся
каскадный способ. Его основной характеристикой является разбиение всей
разработки на этапы, причем переход с одного этапа на следующий происходит
только после того, как будет полностью завершена работа на текущем (рис.
1.1). Каждый этап завершается выпуском полного комплекта документации,
достаточной для того, чтобы разработка могла быть продолжена другой
командой разработчиков.
Положительные стороны применения каскадного подхода заключаются в следующем
[2]:
на каждом этапе формируется законченный набор проектной документации,
отвечающий критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют планировать
сроки завершения всех работ и соответствующие затраты.
Рис. 1.1. Каскадная схема разработки ПО
Каскадный подход хорошо зарекомендовал себя при построении ИС, для которых
в самом начале разработки можно достаточно точно и полно сформулировать все
требования, с тем чтобы предоставить разработчикам свободу реализовать их
как можно лучше с технической точки зрения. В эту категорию попадают
сложные расчетные системы, системы реального времени и другие подобные
задачи. Однако, в процессе использования этого подхода обнаружился ряд его
недостатков, вызванных прежде всего тем, что реальный процесс создания ПО
никогда полностью не укладывался в такую жесткую схему. В процессе создания
ПО постоянно возникала потребность в возврате к предыдущим этапам и
уточнении или пересмотре ранее принятых решений. В результате реальный
процесс создания ПО принимал следующий вид (рис. 1.2):
Рис. 1.2. Реальный процесс разработки ПО по каскадной схеме
Основным недостатком каскадного подхода является существенное запаздывание
с получением результатов. Согласование результатов с пользователями
производится только в точках, планируемых после завершения каждого этапа
работ, требования к ИС "заморожены" в виде технического задания на все
время ее создания. Таким образом, пользователи могут внести свои замечания
только после того, как работа над системой будет полностью завершена. В
случае неточного изложения требований или их изменения в течение
длительного периода создания ПО, пользователи получают систему, не
удовлетворяющую их потребностям. Модели (как функциональные, так и
информационные) автоматизируемого объекта могут устареть одновременно с их
утверждением.
Для преодоления перечисленных проблем была предложена спиральная модель ЖЦ
[10] (рис. 1.3), делающая упор на начальные этапы ЖЦ: анализ и
проектирование. На этих этапах реализуемость технических решений
проверяется путем создания прототипов. Каждый виток спирали соответствует
созданию фрагмента или версии ПО, на нем уточняются цели и характеристики
проекта, определяется его качество и планируются работы следующего витка
спирали. Таким образом углубляются и последовательно конкретизируются
детали проекта и в результате выбирается обоснованный вариант, который
доводится до реализации.
Разработка итерациями отражает объективно существующий спиральный цикл
создания системы. Неполное завершение работ на каждом этапе позволяет
переходить на следующий этап, не дожидаясь полного завершения работы на
текущем. При итеративном способе разработки недостающую работу можно будет
выполнить на следующей итерации. Главная же задача - как можно быстрее
показать пользователям системы работоспособный продукт, тем самым
активизируя процесс уточнения и дополнения требований.
Основная проблема спирального цикла - определение момента перехода на
следующий этап. Для ее решения необходимо ввести временные ограничения на
каждый из этапов жизненного цикла. Переход осуществляется в соответствии с
планом, даже если не вся запланированная работа закончена. План
составляется на основе статистических данных, полученных в предыдущих
проектах, и личного опыта разработчиков.
Рис 1.3. Спиральная модель ЖЦ
1.3. Методологии и технологии проектирования ИС
1.3.1. Общие требования к методологии и технологии
Методологии, технологии и инструментальные средства проектирования (CASE-
средства) составляют основу проекта любой ИС. Методология реализуется через
конкретные технологии и поддерживающие их стандарты, методики и
инструментальные средства, которые обеспечивают выполнение процессов ЖЦ.
Технология проектирования определяется как совокупность трех составляющих:
пошаговой процедуры, определяющей последовательность технологических
операций проектирования (рис. 1.4);
критериев и правил, используемых для оценки результатов выполнения
технологических операций;
нотаций (графических и текстовых средств), используемых для описания
проектируемой системы.
Рис. 1.4. Представление технологической операции проектирования
Технологические инструкции, составляющие основное содержание технологии,
должны состоять из описания последовательности технологических операций,
условий, в зависимости от которых выполняется та или иная операция, и
описаний самих операций.
Технология проектирования, разработки и сопровождения ИС должна
удовлетворять следующим общим требованям:
технология должна поддерживать полный ЖЦ ПО;
технология должна обеспечивать гарантированное достижение целей разработки
ИС с заданным качеством и в установленное время;
технология должна обеспечивать возможность выполнения крупных проектов в
виде подсистем (т.е. возможность декомпозиции проекта на составные части,
разрабатываемые группами исполнителей ограниченной численности с
последующей интеграцией составных частей). Опыт разработки крупных ИС
показывает, что для повышения эффективности работ необходимо разбить проект
на отдельные слабо связанные по данным и функциям подсистемы. Реализация
подсистем должна выполняться отдельными группами специалистов. При этом
необходимо обеспечить координацию ведения общего проекта и исключить
дублирование результатов работ каждой проектной группы, которое может
возникнуть в силу наличия общих данных и функций;
технология должна обеспечивать возможность ведения работ по проектированию
отдельных подсистем небольшими группами (3-7 человек). Это обусловлено
принципами управляемости коллектива и повышения производительности за счет
минимизации числа внешних связей;
технология должна обеспечивать минимальное время получения работоспособной
ИС. Речь идет не о сроках готовности всей ИС, а о сроках реализации
отдельных подсистем. Реализация ИС в целом в короткие сроки может
потребовать привлечения большого числа разработчиков, при этом эффект может
оказаться ниже, чем при реализации в более короткие сроки отдельных
подсистем меньшим числом разработчиков. Практика показывает, что даже при
наличии полностью завершенного проекта, внедрение идет последовательно по
отдельным подсистемам;
технология должна предусматривать возможность управления конфигурацией
проекта, ведения версий проекта и его составляющих, возможность
автоматического выпуска проектной документации и синхронизацию ее версий с
версиями проекта;
технология должна обеспечивать независимость выполняемых проектных решений
от средств реализации ИС (систем управления базами данных (СУБД),
операционных систем, языков и систем программирования);
технология должна быть поддержана комплексом согласованных CASE-средств,
обеспечивающих автоматизацию процессов, выполняемых на всех стадиях ЖЦ.
Общий подход к оценке и выбору CASE-средств описан в разделе 4, примеры
комплексов CASE-средств - в подразделе 5.7.
Реальное применение любой технологии проектирования, разработки и
сопровождения ИС в конкретной организации и конкретном проекте невозможно
без выработки ряда стандартов (правил, соглашений), которые должны
соблюдаться всеми участниками проекта. К таким стандартам относятся
следующие:
стандарт проектирования;
стандарт оформления проектной документации;
стандарт пользовательского интерфейса.
Стандарт проектирования должен устанавливать:
набор необходимых моделей (диаграмм) на каждой стадии проектирования и
степень их детализации;
правила фиксации проектных решений на диаграммах, в том числе: правила
именования объектов (включая соглашения по терминологии), набор атрибутов
для всех объектов и правила их заполнения на каждой стадии, правила
оформления диаграмм, включая требования к форме и размерам объектов, и т.
д.;
требования к конфигурации рабочих мест разработчиков, включая настройки
операционной системы, настройки CASE-средств, общие настройки проекта и т.
д.;
механизм обеспечения совместной работы над проектом, в том числе: правила
интеграции подсистем проекта, правила поддержания проекта в одинаковом для
всех разработчиков состоянии (регламент обмена проектной информацией,
механизм фиксации общих объектов и т.д.), правила проверки проектных
решений на непротиворечивость и т. д.
Стандарт оформления проектной документации должен устанавливать:
комплектность, состав и структуру документации на каждой стадии
проектирования;
требования к ее оформлению (включая требования к содержанию разделов,
подразделов, пунктов, таблиц и т.д.),
правила подготовки, рассмотрения, согласования и утверждения документации с
указанием предельных сроков для каждой стадии;
требования к настройке издательской системы, используемой в качестве
встроенного средства подготовки документации;
требования к настройке CASE-средств для обеспечения подготовки документации
в соответствии с установленными требованиями.
Стандарт интерфейса пользователя должен устанавливать:
правила оформления экранов (шрифты и цветовая палитра), состав и
расположение окон и элементов управления;
правила использования клавиатуры и мыши;
правила оформления текстов помощи;
перечень стандартных сообщений;
правила обработки реакции пользователя.
1.3.2. Методология RAD
Одним из возможных подходов к разработке ПО в рамках спиральной модели ЖЦ
является получившая в последнее время широкое распространение методология
быстрой разработки приложений RAD (Rapid Application Development). Под этим
термином обычно понимается процесс разработки ПО, содержащий 3 элемента:
небольшую команду программистов (от 2 до 10 человек);
короткий, но тщательно проработанный производственный график (от 2 до 6
мес.);
повторяющийся цикл, при котором разработчики, по мере того, как приложение
начинает обретать форму, запрашивают и реализуют в продукте требования,
полученные через взаимодействие с заказчиком.
Команда разработчиков должна представлять из себя группу профессионалов,
имеющих опыт в анализе, проектировании, генерации кода и тестировании ПО с
использованием CASE-средств. Члены коллектива должны также уметь
трансформировать в рабочие прототипы предложения конечных пользователей.
Жизненный цикл ПО по методологии RAD состоит из четырех фаз:
фаза анализа и планирования требований;
фаза проектирования;
фаза построения;
фаза внедрения.
На фазе анализа и планирования требований пользователи системы определяют
функции, которые она должна выполнять, выделяют наиболее приоритетные из
них, требующие проработки в первую очередь, описывают информационные
потребности. Определение требований выполняется в основном силами
пользователей под руководством специалистов-разработчиков. Ограничивается
масштаб проекта, определяются временные рамки для каждой из последующих
фаз. Кроме того, определяется сама возможность реализации данного проекта в
установленных рамках финансирования, на данных аппаратных средствах и т.п.
Результатом данной фазы должны быть список и приоритетность функций будущей
ИС, предва | |
