
- •Эвм и вычислительные системы».
- •Часть II.
- •Оглавление.
- •Лекция №19 конструкция персонального компьютера.
- •19.1. Основные конструктивные компоненты персонального компьютера.
- •19.2. Корпус пк.
- •19.3. Блок питания.
- •19.4. Системные платы.
- •19.5. Конструктивы и установка плат.
- •Лекция №20 ключевые микросхемы.
- •20.1. Стандартные микросхемы первых системных плат.
- •20.2. Набор микросхем или - chipset.
- •20.3. Микропроцессоры.
- •20.4. Организация доступа к памяти при использовании intel совместимых процессоров
- •Лекция №21 память компьютера
- •21.1. Иерархия подсистемы памяти пк.
- •21.2. Оперативная память.
- •21.3. Архитектура оперативной памяти.
- •21.4. Логическая организация памяти.
- •Лекция № 22 базовая система ввода/вывода.
- •22.1. Bios и cmos ram. Общие сведения.
- •22.2. Возможности bios. Конфигурирование системных ресурсов.
- •22.3. Тест начальной загрузки post.
- •Лекция № 23 кэш – память
- •23.1. Принципы построения кэш-памяти.
- •23.2. Типы кэшей
- •23.3. Целостность данных в кэш-памяти
- •23.4. Кэш-память и эффективность программ
- •Лекция №24 накопители на жестких дисках.
- •24.1. Типы накопителей.
- •24.2. Накопители на жестких дисках. (Винчестеры)
- •24.3. Параметры жестких дисков
- •24.4. Низкоуровневое форматирование
- •24.5. Логическая структура диска
- •24.6. Загрузочный сектор br (Boot Record).
- •24.7. Таблица размещения файлов fat (File Allocation Table).
- •24.8. Корневой каталог (root Directory).
- •24.9. Главный загрузочный сектор mbr (Master Boot Record).
- •24.10. Порядок установки винчестера.
- •24.11. Кэширование диска.
- •Лекция №25 интерфейсы винчестеров
- •25.1. Интерфейс st-506/412.
- •25.2. Интерфейс еsdi
- •25.3. Интерфейс scsi
- •25.4. Интерфейс ide (ata)
- •Лекция №26 шины персональных компьютеров.
- •26.1. Обзор шин пк.
- •26.2. Системные шины.
- •26.3. Локальные шины.
- •26.4. Шина pci (Peripheral Component Interconnect) (1992 год).
- •26.5. Магистральный интерфейс agp.
- •Лекция № 27 видеоподсистемы
- •27.1. Мониторы.
- •27.2. Основные стандарты мониторов (видеоадаптеров).
- •27.3. Проблемы цветопередачи.
- •27.4. Видеопамять.
- •27.5. Повышение скорости работы видеоадаптера.
- •Лекция № 28 современные видеоподсистемы персональных компьютеров.
- •28.1. Свойства современных видеоадаптеров
- •28.2. Современные видеоадаптеры
- •28.3. Архитектура персональных машин с объединенной памятью. Новая архитектура ibm-совместимых пк.
- •28.4. Варианты развития архитектуры uma
- •Лекция 29. Лекция №30 архитектура компьютера
- •30.1. Параллелизм, компьютерная архитектура и приложения пользователя
- •30.2. Однопроцессорные архитектуры
- •30.3. Многопроцессорные архитектуры
- •30.4. Выбор архитектуры
- •Лекция №31 архитектура современных программных средств План лекции
- •31.1. Программное обеспечение эвм
- •31.2. История развития программных средств эвм.
- •31.3. Структура программного обеспечения.
- •31.4. Проблемно-ориентированные пакеты прикладных программ.
- •Лекция №32 операционные системы эвм.
- •32.1. Системное программное обеспечение эвм
- •32.2. Операционные системы (ос) эвм
- •32.3. Организация операционных систем.
- •32.4. Концепция виртуальной операционной системы.
- •32.5. Типы операционных систем.
- •32.6. Операционная среда ms-dos.
- •32.7. Операционная система Unix.
- •Лекция № 33. Операционные системы эвм (продолжение).
- •33.1. Операционные оболочки эвм.
- •33.2. Многооконный графический интерфейс.
- •33.3. Инструментальное программное обеспечение (ипо) эвм.
- •33.4. Трансляторы с языка высокого уровня.
- •33.5. Двухуровневая организация схемы компилятора.
- •33.6. Естественные языки программирования.
- •Лекция № 34 прикладное программное обеспечение
- •34.1. Прикладное программное обеспечение эвм
- •34.3. Классы пакетов прикладных программ
- •34.4. Основные прикладные средства пк.
- •34.6. Качественные характеристики программного обеспечения
34.6. Качественные характеристики программного обеспечения
Если на первых этапах своего развития программирование в значительной степени можно было называтьискусством, то с расширением сферы применения ВТ, классов решаемых задач, а также с появлением различного типа и назначения инструментальных средств разработка ПС приобретает все больше индустриальных черт, делая создаваемые средствапрограммными продуктами. Поэтому, как и к любому другому продукту к ПС можно относить совокупность характеристик, определяющих егокачественную сторону. Первые серьезные подходы к оценкекачества ПО относятся к началу 70-х годов и в настоящее время составляют самостоятельную важную компонентуиндустрии программирования, в определенной мере выполняя рольотдела технического контроля (ОТК). В условиях ужесточающейся конкуренции ПО, особенно для ЭВМ класса ПК,качественные показатели играют все возрастающую роль как для разработчиков, так и для потребителей ПО, где под ПО будем понимать совокупность собственно ПС, связанных с нимиданных и программнойдокументации. Разработка ПО представляет собой, в общем случае, многоэтапный процесспроектирования ипрограммирования, каждый изэтапов которого, в свою очередь, можно подразделять напод этапы (рис.34.3), имеющие самостоятельное значение, но в настоящей книге не обсуждаемые.
На первом этапе специфицируются(определяются) основныесистемные требования кпроекту исходя из его целей, назначения и предметной области, на которую он ориентируется.Второй же этап детализирует требования собственно кпрограммной части проекта;третий этап включаетпрограммную реализацию проекта коллективом программистов различного уровня и квалификации, используя современныепрограммные технологии иинструментальные средства. Из отечественных средств разработки ПО можно отметитьдиалоговую систему структурного программирования (ДССП) сразвиваемым адаптивным языком (РАЯ), ориентированным на созданиеструктурированного ПО. Язык ДССП легко расширяем пользователем, универсален и адаптивен.
Рис. 34.3.
В него включены команды управления системой, средства редактирования и верификации разработанных программ. Система имеет весьма дружелюбный интерфейс с непрофессиональным пользователем, обеспечивает высокую производительность процесса программирования, высокий уровень проверки создаваемого ПО, удобство отладки и сопровождения на конкретной ЭВМ. Система ДССП является совместной разработкой МГУ и ЛГУ, и реализована для ряда типов ЭВМ, включая IBM-совместимые ПК.
На четвертом этапе производитсяотладка итестирование разработанного ПО каклокально, так и вкомплексе, используя наиболее достоверные средства верификации. Современные средства проверки корректности ПО базируются нааппарате математической логики и булевой алгебры,генераторах тестовых данных (ГТД), использовании автоматизированных испытательных стендов и т.д. При этом в последнее время особое внимание уделяется проблеме верификациипараллельного ПО, решение которой представляет значительно большую сложность, чем в случае традиционногопоследовательного программирования. Средства верификации ПО базируются на соответствующих формальныхмоделях надежности ПС, использующих многие результаты и подходыобщей теории надежности, включаяаналитические, имитационные иэкспериментальные методы. Средианалитических можно отметить логический и логико-вероятностный методы; метод на основе аппарата булевой алгебры и др. (в частности,булева алгебра, составляя теоретическую основу многих разделов современной ЦВТ — логического проектирования, логики, теории алгоритмов, вместе с тем предоставляет хорошую методологическую основу для решения задачверификации ПО);имитационные методы базируются на специальныхимитационных ППП(PET. REGIM, PACE, RXVP и др.); основуэкспериментальных методов составляют ГТД(TMETRIC, AGENT, IEBDG, PRO/TEST. PROFILE и др.) ииспытательные стенды (АИСТ-ПС и др.) Особую рольимитационные методы верификации играют в случае необходимости тестированияуправляющих ПС (УПС)режима реального времени.
Специфика УПС определяется необходимостью реакции на внешнее воздействие в реальное время и повышенными требованиями к их надежности; незначительные ошибки в УПС могут приводить к весьма серьезным последствиям (бортовая аппаратура, управление космическими объектами, АЭС и т.д.). Созданные на сегодня средстваверификации во многом ориентированы на ПО общего назначения, функционирование которого не связано жестко свременными ограничениями. Проверка работоспособности УПСреального времени вызывает особые затруднения, определяемые целым рядом факторов. Впервую очередь, это относится кдинамической комплексной отладке и верификации УПС, которые в силу своейвременной специфики предъявляютособые требования к средствам их верификации.
Пятый этап проектирования служит дляапробации разработанного ПО в условиях эксплуатации, близких к реальным; на данном этапе предпринимаются попытки обнаружить и устранить все сколь-нибудь серьезные ошибки, по возможности оптимизировать основные характеристики созданной системы и повысить логический уровень интерфейса с пользователем; уточнить сопровождающую систему документацию и т.д. Работа на данном этапе ведетсястрого по опробованной и утвержденной программе, в определенной мере гарантирующей решение вышеперечисленных задач. Особое вниманиедолжно быть уделено разработке высококачественнойдокументации, которой в отечественной практике часто уделялось недостаточно внимания. Именно по этой причине ряд весьма интересных оригинальных разработок оказались чрезвычайно неудобными в эксплуатации и впоследствии были заменены зарубежными аналогичными(не превосходящими по возможностям), но лучше документированными ПС.
В последние годы вопросу разработки документации по ПО уделяется особое внимание в связи с массовым использованием ПК, обслуживающих в значительной мере непрофессионального с компьютерной точки зрения пользователя. Поэтому в большинстве случаевдокументация проектируемого ПС создается в последнюю очередь, тогда как пользователь обращается к ней в первую очередь и в дальнейшем широко ее использует и обсуждает. Следовательно, важно точно определитьхарактерные чертыхорошей документации. Основное требование к документации заключается внеобходимости обеспечения ееточности и полноты, купивший ППП или компьютер пользовательдолжен получитьточную иисчерпывающую информацию по основным вопросам ее использования. При этомточность трактуется в более широком смысле, предполагая не толькоточное описание функционирования данного ПС в различных режимах его применения, но исоответствие получаемых посредством его результатовсути предметной области, на которую оно ориентировано. Наряду с этим понятиехорошей документации предполагаетмногоплановость ее руководств:системные, по применению, обучающие исправочные; при этом указанные руководства могут иметь пересекающееся наполнение.Системные руководства, как правило, освещают вопросы интерфейса данного ПС с операционной средой, включая егоинсталляцию в конкретных условиях эксплуатации, а также егосистемные характеристики; смысл остальных типов документации достаточно прозрачен из их названия и особого пояснения не требует.
Подготовка высококачественной документации предполагает работу над ней различного родаспециалистов (руководителей проекта, системных и проблемных программистов, сотрудников по маркетингу и сопровождению, редакторов, корректоров и т.д.). При этом, разработка документации должна сопровождатьвесь процесс разработки программного проекта, оперативно корректируясь согласно его изменениям.Апробацию документации весьма эффективно проводить на этапеопытной эксплуатации на группах типичных пользователей, на которых ориентируется данное ПС. Хорошаядокументированность ПС предполагает также наличие развитой многоуровневой оперативнойHelp-информации, доступной пользователю на основных этапах работы с ПС, а также дисковых файлов с последними изменениями по ПС и условиям его эксплуатации. Как правило, официально поставляемые зарубежные ПС для ЭВМ класса ПК удовлетворяют указанным выше требованиямхорошей документированности.
С точки зрения пользователя каждое ПС рассматривается им с трех основных точек зрения: (1) возможностииспользования его для конкретных приложений; (2)удобства эксплуатации и (3) возможностипродолжения егоприменения при тех или иных изменениях условий эксплуатации. Сегодня указанные точки зрения можно освещать на основеряда устоявшихсякачественных характеристик ПС, вкратце рассматриваемых ниже. Подпонятностью ПС понимается возможность пользователяпонять основное назначение данного средства и условия его эксплуатации. Данная характеристика предполагает четкое и ясное описание ПС, исключающее сленг разработчиков, неточности, двусмысленности и т.д. Свойствооцениваемости позволяет установитькритерии применимости данного ПС для конкретных приложений иобеспечивает эффективную возможность оценкикачества его функционирования. Тогда как свойствомодифицируемости определяет возможность изменения ПС пользователем с учетом изменения условий его эксплуатации. Свойствомобильности являетсячрезвычайно важным и определяет возможность использования ПС на ЭВМ разных типов и классов. В качестве примерамобильности можно отметить ПС, разработанные в среде С-языка, имеющего компиляторы на большинстве современных ЭВМ различных классов и типов.
Эффективность ПС определяется требуемыми для выполнения его функций вычислительными ресурсами (объемы ОП и ВП, время решения и др.). Свойствонадежности определяетустойчивость функционирования ПС вреальных условиях эксплуатации (ошибки в данных, особые и аварийные ситуации, ошибки оператора и т.д.). Как правило,надежность ПС обеспечивается на стадии его проектирования и программирования путемпредусмотрения наиболееважных с точки зрения возможных последствийособых иаварийных ситуаций, а также эффективных способов их обработки. Интеллектуальность интерфейса с пользователем предполагает не толькоминимум диалога в процессе функционирования ПС (без крайней необходимости), но и егодружелюбие к пользователю, не выходящее запредметную область решаемых задач. Все сообщения ПС должны носить вполне конкретный характер и требоватьминимальных действий со стороны пользователя. Рассмотренные характеристики допускаютболее детальнуюградацию, позволяющую точнее устанавливать их взаимосвязь и оцениватькачество конкретного ПС на основе специальныхсистем показателей качества. Анализкачественных характеристик ПС позволяет разрабатыватьпринципы создания качественного ПО.
С целью автоматизации вышеуказанных этапов разработки сложных программных проектов создан рядэффективных методов и подходов, среди которых особое внимание уделяетсяпервым двум этапам, от которых во многом зависит успех последующего развития проекта, включаяверификацию его программной части. Ряд исследований по оценкам качества программных проектов показал, что додвух третей ошибок формируется именно настадиях разработкиспецификаций ифункциональных требований к проекту. Действительно,спецификации во многом должны соответствоватькачественным характеристикам, предъявляемым к готовому программному продукту, представляя собойтехническое задание на некоторомформальном языке(языке спецификаций), который может служить как для формального представления(описания) спецификаций, так и в качествеязыка программирования более высокого уровня, чем традиционные языки 3-го и 4-го поколений. Такое развитие ЯВУ представляется вполнеестественным, позволяя существеннорасширять круг пользователей-программистов за счет непрофессиональных (с нынешней точки зрения) пользователей.
Спецификации системных требований и требований к ПС, а также его описания производятся на языке высокого уровня в терминах, характерных для решаемых им задач предметной области (а не для реализации), и служат основой дальнейшей детализации и разработки Проекта. Качественные спецификации существенно облегчают создание ПС, их верификацию, проверку и модификацию, сокращают затраты на разработку и сопровождение. Разработка спецификаций составляет самостоятельную часть технологии и методологии современного программирования и для этих целей создан ряд специальныхязыков спецификаций. Одним изпервых языков спецификаций широкого спектра можно отметить языкCIP-L, ориентированный на разработку спецификаций и ПО какпоследовательного, так ипараллельного. Разработка спецификаций и требований к сложной программной системе — большая интеллектуальная работа, для автоматизации которой создан целый ряд эффективных средств поддержки(SA, LOGOS, CLEAR, AFFIRM, RSL/REVS, PDL и др.). В последние годы в связи с бурным развитиемпараллельного ПО, функционирующим на ненеймановскихпараллельных моделях ВТ, большое внимание уделяется вопросам автоматизации спецификаций, анализу и верификации такого типа программных систем. Решение указанных задач для такого типа ПО является существенноболее сложным относительно ПС последовательного типа, ибо дополнительную сложность вносят элементы взаимодействия параллельно выполняющихся частей системы. Среди средств, ориентированных на автоматизацию спецификаций и требований кпараллельному ПО, можно отметить такие, как:PAISLey, COSY, CESAR, CSP, PDL2 и др.). Наряду с отмеченными средствами автоматизации спецификаций и требований к ПО общего назначения существует целый ряд подобных средств, ориентированных на более специальные типы ПО: реального времени, компиляторы, СУБД, ППП и др.