Программное обеспечение и его разработка
Шрифт:
Такие «дополнительные пробежки» обычны для разработчиков программного обеспечения. Если системе не хватает ресурсов ЦП или памяти, разработчикам приходится работать с большей нагрузкой и намного дольше — и как следствие растет стоимость обеспечения. Им приходится отыскивать пути обхода слабых мест аппаратуры. Иногда приходится и переделывать программы.
Система команд и их влияние на производительность. Машина Тьюринга имела всего шесть команд. Она могла выполнять любые задания, но такой ограниченный набор используемых команд сильно затрудняет работу программиста. Одно из важных экономических решений, которое принимает каждый производитель
Современные большие машины распознают и выполняют более чем 300 разных команд. Овладеть таким «словарем» для программиста достаточно сложно. Изучение этих команд и способов их эффективного использования может потребовать от программиста месяцы, а то и годы. Только половина набора команд машины IBM 7090 использовалась регулярно.
Невозможно ответить на вопрос о том, на какой машине (большой, с богатым выбором команд, или маленькой, с ограниченным набором) легче программировать. Как и для многих других вопросов из области вычислительной техники, ответ «зависит» от множества деталей. Маленькую, простую задачу может оказаться легче программировать на маленькой машине с небольшим набором команд. Большие, сложные задачи, возможно, легче решать на машине с «богатым» словарем. К тому же все зависит от того, на машинах какого типа привыкли работать программисты. Однажды в Хьюстоне нам пришлось с помощью группы, имевшей огромный опыт работы на большой машине IBM 360 модели 75, разрабатывать обеспечение для маленькой IBM системы 7. Это было ужасно! Они не понимали ограничений этой машины, неправильно подходили к решению задачи, использовали неверные методы. Они ухлопали целый год — и чертову уйму денег, — прежде чем разобрались, в чем дело. А это были хорошие опытные разработчики.
Случается и наоборот. Перевод группы, привыкшей работать на ограниченных системах команд, на программирование с использованием «богатых» систем так же может привести к ужасающим результатам. Прежде всего, они не справляются с богатством, как и повсюду, где оно достается людям. Продуктивность их работы чрезвычайно низка.
Теоретически большие системы команд можно использовать более эффективно, это относится и к стадии разработки. Не надо только думать, что это всегда так.
Наилучшим способом замерять производительность машины было пропустить на ней именно Вашу программу, определив время ее обработки прямо по секундомеру.
Такой способ труден и дорог. Некоторые еще не запрограммированные задачи приходится программировать специально для подобных замеров. Для замеров нужно использовать задачи, которые могут быть просчитаны на разных машинах. Такие задачи называются эталонными пакетами.
Что же можно охарактеризовать с помощью эталонных пакетов и замеров времени? Все, что имеется в вычислительной системе — аппаратуру, отдельные программы (а следовательно, и умение тех, кто занимался их программированием), трансляторы, программное обеспечение, устройства ввода/вывода, размер машинного слова, систему команд, операционную систему, действия операторов.
Из того, что машина А выигрывает у машины В, нельзя делать вывод о том, что ее аппаратура работает быстрее. Плохое программное обеспечение могло
Чтобы вычислительная система работала эффективно, необходимо так ее сбалансировать, чтобы она подходила для решения поставленных перед ней задач, чтобы процессор был загружен в равной мере с устройствами ввода/вывода, не опережал их работу, но и не отставал от них. Кроме того, система должна включать в себя высококачественное программное обеспечение. В хорошо сбалансированной системе одновременно работают почти все устройства.
Что измеряется | |
---|---|
Пропускная способность характеризует систему в целом: команды + программное обеспечение + операторы + магнитофоны, а также искусство программистов и качество аппаратуры ЭВМ | МКС измеряет внутреннюю скорость центрального процессора и памяти |
С помощью замеров времени | С помощью измерений на смесях команд |
Как измеряется |
Рис. 3.2. Пропускная способность системы и МКС как средства оценки производительности вычислительной машины.
На рис. 3.2 наглядно подытоживаются наши рассуждения о производительности.
Глава 4
Таксономия программного обеспечения
Каким же образом мы справляемся со всем своеобразием вычислительной машины? Помогает нам распределение по категориям и классам, разделение предмета на составные части и куски. Именно это мы и собираемся проделать в этой главе с программным обеспечением.
Мы уже видели, что по типам использования все вычислительные машины могут быть разбиты на несколько категорий, мы насчитали пять таких категорий. Эти же пять категорий оказываются полезными и для понимания внешних влияний, испытываемых программным обеспечением. Как мы увидим, они могут не совпадать с обычным делением программного обеспечения на некоторые типы.
Здесь представлена таксономия программного обеспечения, которая может быть полезной для обсуждения и понимания проблем, возникающих при разработке, использовании и продолжающейся разработке программного обеспечения больших и сложных систем.
Как мы уже видели, есть пять типов использования систем с программным обеспечением:
Тип I. Использование для обработки данных.
Тип II. Использование для проведения научных расчетов.
Тип III. Использование для информационных систем.
Тип IV. Использование в диалоговых системах решения задач.
Тип V. Использование для управления процессами.
За время своей жизни программное обеспечение проходит три фазы:
1. Фазу разработки.
2. Фазу использования.
3. Фазу продолжающейся разработки (часто называемой сопровождением).
Существуют три типа программного обеспечения:
1. Прикладное обеспечение.
2. Инструментальное обеспечение.
3. Системное обеспечение.
Три отличительные черты применения программного обеспечения:
1. Масштабность программного обеспечения.
2. Сложность программного обеспечения.
3. Ясность программного обеспечения.