Подготовка внешних спецификаций
Правильно составленные внешние спецификации — это объемный документ. Эффективным методом создания такого большого документа является применение к нему иерархической организации. В п. 4.1 внешнее проектирование представлялось в виде двух процессов: первоначального (предварительного) и подробного внешнего проектирования.
Допуская, что спецификации являются иерархически организованными, эти два процесса просто представляют контрольные точки в проектировании системы согласно принятой иерархии. Сначала описываются основные компоненты (то, что находится на первом уровне), затем просто компоненты, затем внешние функции (функции пользователя) и в конце концов — детали всех функций пользователя. Предварительное внешнее проектирование включает три первых шага.
Система проектируется до уровня, когда уже выделены все функции пользователя, но точный их синтаксис, семантика и выходные результаты остаются еще не определенными. При этом преследуются две цели: во-первых, внутри продолжительного процесса внешнего проектирования устанавливается контрольная точка для руководства проекта, и, во- вторых, становится возможной проверка правильности промежуточного уровня проекта и сопоставление его с поставленными целями. В качестве примера на рис. 5.35 показан основной управляющий компонент, в рамках этого основного компонента примером компонента может быть администратор секретности. А в рамках этого компонента примером функции может быть приказ «Сообщить о нарушениях секретности» (пример взят из [18]).
04. Внешний вид спецификаций. Часть 1
Публикация [18] относится к тому времени, когда CASE-средства, поддерживающие процессы проектирования программных систем, только начали развиваться. В настоящее время для целей моделирования процессов проектирования ПС на рынке программных продуктов представлен широкий спектр CASE-средств. В нашей стране в начале 2000-х гг. наиболее популярными CASE-средствами являлись Rational Rose, BPwin, Silverrun, Process Analyst [13]. Моделирование жизненного цикла программных систем в этих средствах имеет много общего, хотя есть и различия.
Рис. 5.35. Иерархическая организация спецификаций
Немаловажными являются комплексность подхода и использование единой унифицированной нотации не только на этапе моделирования предметной области, но и на последующих этапах разработки программной системы, как это имеет место в CASE Rational Rose.
Развитием Rational Rose явилось новое CASE-средство — IBM Rational Software Architect, являющееся частью IBM Software Development Platform- набора инструментов, поддерживающих жизненный цикл разработки программных систем [14, 16, 26]. IBM Rational Software Architect предназначен для построения моделей разрабатываемых программных систем с использованием унифицированного языка моделирования UML 2.0, прежде всего моделей архитектуры разрабатываемого приложения. Кроме того, Rational Software Architect поддерживает технологию разработки, управляемой моделями (model-driven development, MDD), позволяющую моделировать программное обеспечение на различных уровнях абстракции с возможностью трассируемо- сти [21].
Следуя принципам RUP, Rational Software Architect позволяет создавать необходимые модели в рамках рабочих процессов таких дисциплин, как [23]:
- • управление требованиями (requirements);
- • анализ и проектирование (analysis and design);
- • реализация (implementation).
Для решения задач подготовки внешних спецификаций RSA предоставляет разработчику средства построения диаграмм вариантов использования, диаграмм деятельности и диаграмм состояний. Варианты использования специфицируют внешнее поведение, ничего не говоря о том, как его достичь.
Это важно, потому что позволяет эксперту или конечному пользователю общаться с разработчиками, конструирующими систему в соответствии с требованиями пользователя (заказчика), не углубляясь в детали реализации. Диаграммы деятельности показывают структуру процесса как пошаговый поток управления и данных. Они описывают динамическое представление системы и важны при моделировании функций системы. Диаграммы состояний также описывают динамическое представление объекта. Они важны для моделирования поведения интерфейсов, классов или коопераций (вместе с функционирующими объектами обеспечивая совместное поведение).
Детальный внешний проект каждой функции пользователя должен освещать следующие вопросы.
- 1. Описание входных данных. Точное описание синтаксиса (например, формат, допустимые значения, области изменения) и семантики всех данных, вводимых пользователем. Этими данными могут быть приказ, входной документ (форма), ответ на подсказку или аналоговый (цифровой) сигнал от внешних устройств.
- 2. Описание выходных данных. Точное описание всех результатов (выводов) функции, например реакции терминала, сообщения об ошибках, отчеты, аналоговые (цифровые) управляющие сигналы для внешних устройств и т.п., должна быть описана функциональная связь входных сигналов с выходными. Это значит, что читатель спецификаций должен быть в состоянии представить себе выходные данные, порожденные каждым конкретным вариантом входных данных.
- 3. Преобразования системы. Многие внешние функции не только порождают выходные данные, но и изменяют состояние системы. В этом случае должны быть описаны все такие преобразования системы с точки зрения пользователя, так как спецификация является внешней. Например, складская система могла бы иметь команду «заказ», которая используется продавцом, чтобы начать выполнение заказа. Эта функция имеет два выходных результата: накладная, которая пересылается в отдел доставки, и подтверждение, выдаваемое на терминал продавца. Она вызывает также два преобразования системы: обновляется инвентарный файл, и заказ регистрируется в файле контроля.
- 4. Характеристики надежности. Это описание воздействия всех возможных отказов функций на саму систему, файлы (базы данных) и пользователя. Установлено, что включение этого раздела в проект внешних спецификаций оказывает небольшое, но положительное влияние на надежность [18]. В проекте разработки интерактивной системы необходимо, чтобы предложение «любая ошибка в этой команде не должна вызывать сбоя системы» имело место в этом разделе для каждой команды. Хотя разработчики, проектирующие внутреннюю структуру системы, никогда сознательно не допустили бы, чтобы ошибка в команде пользователя вызывала общесистемный сбой, это предложение служит постоянным напоминанием данного факта.
- 5. Эффективность. Это описание всех требований, которые предъявляются к эффективности функции, таких как затрачиваемое время, и используемая память. Эффективность редко можно специфицировать как абсолют, так как она зависит от конфигураций аппаратуры (компьютера), скорости передачи данных по линиям связи, эффективности всех других параллельно выполняющихся программ, числа активных пользовательских терминалов и др. Чтобы справиться с этой проблемой, в спецификациях можно описать несколько стандартных конфигураций и уровней нагрузки, а затем можно указать эффективность отдельных функций по отношению к ним.
- 6. Замечания по программированию. Внешние спецификации должны описывать продукты с точки зрения пользователя и избегать ограничений на внутреннее устройство системы. Однако иногда бывает необходимо подсказать или сообщить какие-то идеи относительно внутреннего проектирования функции. Практиковать это следует как можно реже, но если это необходимо, соответствующую информацию нужно сообщать в этом разделе.
Для всякой достаточно сложной функции задача описания функциональных связей результатов и преобразований с входными данными нетривиальна. Отличный способ справиться с этой проблемой — таблица решений [18]. На рис. 5.36 показана таблица решений для команды L (ОТГРУЗИТЬ_ДЕТАЛИ) из спецификации для складской системы.
Команда L имеет три операнда: N„ — номер покупателя, Nd — номер детали, Сд- количество деталей. Результатами выполнения команды являются сообщения на дисплей менеджера (ОМ = L (N„, Nd, Сд)) и преобразования системы (Р = L (N„ , Nd, Сд )). Эта таблица решений, сопровождаемая небольшим описанием, является прекрасной внешней спецификацией команды.
Таблицы решений представляют собой наглядный и строгий способ отражения отношений между входными и выходными данными. Чтобы оценить достоинства такой таблицы, можно попробовать выразить информацию, представленную в таблице обычным словесным описанием. Таблицы решений уникальны по своим достоинствам в качестве средства общения между разработчиком внешнего проекта, пользователем и программистом.
С одной стороны, в них легко может разобраться пользователь, просматривая внешние спецификации. С другой стороны, они служат идеальными исходными данными для программиста, разрабатывающего логику программы. Кроме того, существуют методы проверки таблиц решений на неполноту, избыточность и неоднозначность. К сожалению, таблицы решений по необъяснимым причинам редко используются на практике.
Рис. 5.36. Пример таблицы решений
Таблицы решений могут использоваться для описания функционирования объектов, подлежащих автоматизации. Например, на рис. 5.37 изображена таблица, представляющая работу банкомата при выполнении функции снятия пользователем некоторой суммы средств с банковской карточки.
Для любой сложной функции пользователя задача установлении соотношений между выводами, системными преобразованиями и вводами способом причины и следствия — нетривиальная работа. В целом внешние спецификации описывают каждый возможный ввод в систему (как правильный, так и неправильный) и реакцию системы на каждый из вводов. Внешние спецификации должны точно и полно описывать внешние интерфейсы (сопряжения) при минимальных предположениях о внутреннем устройстве системы.
Рис. 5.37. Описание функции снятия средств с банковской карточки
Источник: studref.com
Внешние спецификации функций разрабатываемой программы
Как было упомянуто в п. 1.1.2, существует множество способов специфицирования программного обеспечения. Курсовой работой предполагается освоение спецификаций с помощью таблиц решений и схем работы системы и программ. Правила построения таблиц решений описаны в п. 1.1.2 настоящей методики, названные выше схемы строятся согласно ГОСТ 19.701-90 и описаны в /10/.
Приступая к разработке спецификаций следует помнить следующие положения проектирования программы:
— программа должна выполнять требуемую функцию обработки над всеми входными данными и, если входные данные не позволяют продолжить обработку без однозначной трактовки результатов, в программах следует предусматривать аварийный выход или исключать из дальнейшей обработки некорректные данные;
— программа не должна прекращать работу сразу же после первой выявленной ошибки в исходных данных, необходимо проверить всю информацию, относящуюся к одной структуре данных;
— сообщения программы об ошибках должны подчиняться принципу единообразия и, кроме того, быть настолько информативными, чтобы входные ошибочные данные можно было легко отыскать среди большого объема данных.
2.5.1. Таблицы решений для функций программы.Функция “проверка на корректность файла F2” должна выявлять возможную неуникальность номеров или наименований предметов и в случае обнаружения такой ситуации заканчивать обработку. Это словесное описание выполняемой функции формализуется в виде ТР, приведенной в таблице 2.4.
Напомним, что в ТР буква “Д” соответствует в программе такой ситуации, когда логическая переменная принимает значение TRUE, соответственно “Н” — логическая переменная принимает значение FALSE. Черточкой “-“ отмечены те условия, которые в соответствующей комбинации не проверяются.
Таблица решений для функции “проверка на корректность файла F2”
| Условия | ||||||
| Имеют ли 2 разных предмета одинаковые номера? | Н | Д | Н | Н | — | — |
| Присвоены ли 2 разных номера одному предмету? | Н | Н | Д | Н | — | — |
| Номер предмета содержит только цифры? | Д | Д | Д | Н | — | |
| Просмотрены все записи файла F2? | Н | Н | Н | Н | Д | Д |
| Обнаружена некорректность F2? | — | — | — | — | Д | Н |
| Действия | ||||||
| Выдать сообщение 1 ‘2-м предметамприсвоен один номер ’ | ||||||
| Выдать сообщение 2 ‘предметуприсвоены 2 разных номера ’ | ||||||
| Выдать сообщение 3 ‘номерпредметанечисловой’ | ||||||
| Установить признак некорректности | ||||||
| Занести запись из файла в таблицу TAB | ||||||
| Продолжить обработку F2 | ||||||
| Выдать сообщение 3 ‘внесите исправления в F2’ | ||||||
| Прекратить обработку | ||||||
| Перейти к следующей функции |
Цифрами отмечаются те действия, которые должны быть выполнены при истинности или ложности проверяемых условий, причем значение указывает порядок выполнения в программе соответствующих операторов.
Примечание: не рекомендуются такие формулировки условий в ТР, которые содержат отрицание или частицу “не”, т.к. ответы на такие вопросы “да” и “нет” допускают неоднозначное толкование. Например, формулировка первого условия в ТР 2.4 в виде “нет двух разных номеров у одного предмета?” при отрицательном ответе воспринимается как “нет нет двух разных номеров у одного предмета”.
В выдаваемых программой сообщениях в ограничителях “” указаны те элементы сообщения, которые должны быть заменены соответствующим наименованием предмета (имя, имя1, имя2) или номером предмета (N, N1, N2) из файла F2.
Обратите внимание: столбцы таблицы отражают возможные ситуации при анализе одной записи из файла. Пока не достигнут конец файла, признак некорректности не проверяется. Это обстоятельство продиктовано необходимостью проверки всей информации из файла, что приведет к выявлению и печати сообщений обо всех ошибках в справочном файле F2. Если проверять признак некорректности до достижения конца файла, сообщение об ошибке будет выдано при первой обнаруженной ошибке. После первой ошибки в данных программа прекратит работу, что при наличии нескольких ошибок приведет к необходимости многократного запуска программы, причем при каждом запуске будет обнаруживаться одна ошибка и выдаваться предложение пользователю исправить очередную ошибку в справочной файле F2.
Содержанием функции “формирование строк выходной таблицы” является проверка ограничений на значения оценок (значения в интервале от 2 до 5) и на совпадение значений номеров предметов в файлах F1 и F2 (ограничения “в” и “г”, описанные в п. 2.3). На эту же функцию возлагается формирование списка предметов, которые сдают студенты одной академической группы. Соответствующая ТР приведена в таблице 2.5.
Отметим, что столбцы 4 и 6 таблицы 2.5 отражают такую ситуацию, когда ошибка обнаруживается в первой записи, относящейся к академической группе, а столбцы 3 и 5 — когда ошибочная запись не является первой записью среди данных одной академической группы. Кроме того, записи, в которых обнаруживается ошибка (неправильно указана оценка или номер предмета), в дальнейшем не обрабатываются, поэтому не исключена ситуация, когда в одной академической группе не будет обнаружено ни одной правильной записи.
Таблица решений для функции “формирование строк выходной таблицы”
| Условия | |||||||
| Оценка в интервале [2,5]? | Д | Д | Н | Н | Д | Д | — |
| Существует ( ) в TAB номер предмета, совпадающий с номером предмета из файла F1? | Д | Д | — | — | Н | Н | — |
| в списке предметов номер предмета, совпадающий с номером предмета из F1? | Н | Д | — | — | — | — | — |
| Просмотрены все записи файла F1, относящиеся к одной академической группе? | Н | Н | Н | Д | Н | Д | — |
| Просмотрены все записи файла F1? | Н | Н | Н | Н | Н | Н | Д |
| Действия | |||||||
| Выдать сообщение 4 ‘оценка не в диапазоне [2,5]’ | |||||||
| Выдать сообщение 5 ‘не найдено наименование, соответствующее номеру предмета’ | |||||||
| Записать номер предмета в список | |||||||
| Добавить 1 к общему количеству оценок по текущему предмету | |||||||
| Выполнить функцию ‘подведение итогов обработки данных одной академической группы’ | |||||||
| Очистить список | |||||||
| Продолжить обработку | |||||||
| Закончить обработку |
Функция “формирование строк выходной таблицы” формирует список предметов одной академической группы и общее количество отличных, хороших, удовлетворительных и неудовлетворительных оценок по каждому предмету. Сформированный список обрабатывается функцией “подведение итогов обработки данных одной академической группы”. Причем очевидно, что если в списке больше 5 предметов, то нарушается ограничение “а” из пункта 2.3, а если общее количество оценок больше 25, то нарушается ограничение “б” из пункта 2.3. ТР для этой функции приводится в таблице 2.6.
Таблица решений для функции “ подведение итогов обработки данных одной академической группы ”
Статьи к прочтению:
- Внешние запоминающие устройства
- Внешний вид печатного издания. предпечатная подготовка издания
Топ 10 Фишек Windows 10 — Обзор от Comfy.ua
Похожие статьи:
- Схемы разрабатываемой программы Как следует из /10/, схема работы системы отражает процесс выполнения программы, а также взаимодействие с пользователем и данными. Из этой схемы…
- Спецификация функций с помощью таблиц решений. Результатом структурирования целей ПО является выявление всех его функций, которые необходимо запрограммировать. Как следует из вышеприведенного…
Источник: csaa.ru
Назначение и состав внешней спецификации задачи
Решение задачи на ЭВМ предполагает наличие соответствующей прикладной программы. Процесс решения заключается в подготовке исходных данных, вводе их в ЭВМ и получении результатов выполнения программы. Внешняя спецификация программы – это полное и точное описание результатов ее выполнения для всевозможных входных ситуаций.
Внешняя спецификация программы может рассматриваться, с одной стороны, формальной инструкцией по использованию программы, а с другой – формальным техническим заданием на ее разработку.
Разработанные алгоритм и программа считаются правильными, если результаты их выполнения при любых входных данных строго соответ ствуют требованиям внешней спецификации. Любое несоответствие результатов считается свидетельством ошибки алгоритма или программы. Внешняя спецификация прикладной программы включает:
• описание входных данных;
• описание формы представления результатов при допустимых входных данных;
• перечисление аномалий во входных данных и реакций программы на
Описание входных данных включает перечень данных, которые должны быть введены с внешнего устройства в процессе выполнения программы, и их типы: числа целые или вещественные, символы или строки символов и др. (Понятие типа данных будет введено позже).
Аномалии входных данных — это различные нарушения условий до пустимости входных данных. К аномалиям относят такие значения входных данных, для которых нельзя применять реализованный в программе метод решения. Так, для описанного выше метода Эвклида, входные данные не могут быть равны нулю, так что аномалией можно считать случай, когда либо первое, либо второе входное число равно нулю.
Программа может быть хорошей и плохой.
В случае плохой программы могут иметь место:
• непонятный текст выходных данных;
• аварийное завершение ее при недопустимых входных данных. (При этом часто отсутствуют сообщения с разъяснением причины).
Программа считается хорошей, если выполнены следующие требования:
• текст выходных данных легко понимается, и в него включены не только результаты решения, но и входные данные решаемой задачи;
• тексты с выходными данными легко записываются и легко исправляются;
• при обнаружении аномалий формируется легко понимаемый текст с диагностикой выявленных ошибок в данных.
8. Алгоритм: понятие, свойства, способы описания.
Алгоритм — это точное описание упорядоченной последовательности действий, приводящей за конечное число шагов к необходимому результату.
Свойства алгоритмов:
- понятность
- однозначность
- дискретность (пошаговость)
- массовость (универсальность)
- результативность
- конечность
- безошибочность
Очевидно, что предписание «Пойди туда, не знаю куда, принеси то, не знаю что» алгоритмом не является.
В качестве исполнителя алгоритмов в «докомпьютерную» эру подразумевался человек (в крайнем случае, животное — в цирке). Человек постоянно пользуется алгоритмами при решении задач, не задумываясь над этим, машинально (автоматически). Наглядными примерами алгоритмов являются различные инструкции, правила, рецепты. Открывая дверь ключом, никто не размышляет над тем, как это сделать. Но чтобы научить этому другого, придется составить алгоритм. Например, так:
2. Вставить ключ в замочную скважину.
3. Повернуть ключ против часовой стрелки на 2 оборота.
Этот алгоритм обладает всеми необходимыми свойствами. Но если переставить второе и третье действия, алгоритм тоже можно будет выполнить, но дверь не откроется! Вот почему важен не только набор действий, но и их порядок. Кроме того, в приведённом примере следует обратить внимание на два обстоятельства. Первое не требует пояснений: всякий алгоритм должен иметь имя.
Второе состоит в том, что перед выполнением алгоритма задаётся или определяется некоторое начальное состояние,исходные условия алгоритма: открывающий дверь должен находиться перед ней, а не переходить улицу перед подъездом. И ключ также должен находиться под рукой.
Сегодня в качестве исполнителей алгоритмов человеку служат многие автоматические устройства и, прежде всего, конечно, компьютер. При этом составление алгоритма должно быть особенно ответственным и тщательным, так как машина не может домысливать и исправлять ошибки. В этом смысле она — идеальный исполнитель.
При реализации алгоритма для ЭВМ его шаги становятся операторами, а вся их последовательность — программой. Для исполнителя всегда нужно определить те команды, которые он должен и может выполнять, чтобы совершать действия, предусмотренные алгоритмом. Набор таких команд называется системой команд исполнителя. Таких команд ограниченное число и их не может быть много.
Чем меньше команд, тем легче построить техническое устройство в роли их исполнителя. И если исполнителем получена команда, не входящая в его систему команд или неправильно заданная, он должен сообщить об отказе. Т.к. необходимо, чтобы исполнитель получил алгоритм в понятной ему форме, становится важным, каким способом представлен алгоритм.
Способы представления алгоритма:
4. программа на алгоритмическом языке.
Для словесного представления алгоритма используется естественный язык (пример — любые инструкции, рецепты и т.п.)
С табличным способом представления алгоритма Вы сталкиваетесь в расчетных книжках при плате за квартиру, в бухгалтерских ведомостях, в таблицах инженерных расчетов и т.п.
Графический способ представления алгоритма — это блок-схема (рассмотрим на следующем уроке) является наиболее наглядным. Схема алгоритма состоит из графических блоков.
Программа — изложение алгоритма специально для ЭВМ в понятных ей символах, словах и командах (иначе говоря — языком программирования). Четвёртый способ – единственный «понятный» компьютеру как автоматическому исполнителю. Первые три служат для понимания решения задачи самим человеком.
В любом алгоритмическом языке (языке программирования) можно выделить четыре основные конструкции (виды алгоритмов):
1. линейный алгоритм (образование последовательности из нескольких команд);
2. алгоритм ветвления (выбор одной или нескольких команд);
3. циклический алгоритм (повторение одной или нескольких команд с заданным количеством повторов или в зависимости от некоторого условия);
4. вспомогательный алгоритм (самостоятельный алгоритм, облегчающий реализацию модульного принципа составления программы).
Использование комбинаций таких структур позволяет реализовать практически любой алгоритм.
9. Трансляция программ: компиляторы и интерпретаторы.
Трансляция кода — преобразование программы, написанной на языке высокого уровня, в двоичный код, на котором работает компьютер, требует пристального внимания к многочисленным деталям — того, что успешно может делать компьютер под управлением транслирующей программы.
Транслирующие программы делятся на две категории: интерпретаторы и компиляторы.
Интерпретатор преобразует небольшой фрагмент исходной программы в машинные команды и, лишь дождавшись, когда компьютер их выполнит, переходит к обработке следующего фрагмента.
Компилятор, наоборот, транслирует всю программу, написанную на языке высокого уровня, и помещает команды в память компьютера, не выполняя их; компилированную программу можно сохранить, чтобы в дальнейшем использовать.
Каждый из этих способов преобразования имеет свои достоинства и недостатки.
Компилированные про граммы выполняются быстрее, чем интерпретируемые; однажды компилированная программа не требует в дальнейшем компилятора, и компьютеру не приходится исхитряться, чтобы одновременно и транслировать, и выполнять программу.
Программы, написанные на языках, ориентированных на интерпретацию, требуют присутствия в памяти компьютера интерпретатора, который осуществляет трансляцию программы в ходе ее выполнения.
Благодаря построчной трансляции интерпретатор полезен как при отладке, так и при трансляции программ, подверженных частым изменениям; исправленную программу можно сразу запустить, чтобы проверить ее работу. При использовании компилятора исправленную программу приходится перекомпилировать.
Как компилятор, так и интерпретатор должны соответствовать правилам конкретного языка высокого уровня, который они транслируют. Подобно тому как правила грамматики описывают естественный язык, правила формального языка управляют работой программиста, указывая, как можно соединять слова и символы, используемые в языке, при построении сложных выражений и задавая правила форматирования, в том числе употребления пробелов и знаков пунктуации. В транслирующих программах грамматика является основой преобразования понятий исходной программы в машинный код.
10. Интегрированная среда программирования: назначение, состав, основные приемы работы.
Интегрированная среда программирования – система программных средств, используемая программистами для разработки программного обеспечения.
Обычно среда программирования включает в себя:
· компилятор и/или интерпретатор;
· средства автоматизации сборки;
Редактор исходного кода — текстовый редактор для создания и редактирования исходного кода программ. Он может быть отдельным приложением, или встроен в интегрированную среду разработки (IDE).
Редакторы исходного кода имеют некоторые возможности, упрощающие и ускоряющие написание и изменение кода, такие как подсветка синтаксиса, автодополнение, проверка правильности расстановки скобок, контекстная помощь по коду и многие другие. Такие редакторы предоставляют удобный способ для запуска компилятора, интерпретатора, отладчика или других программ необходимых в процессе разработки программного обеспечения. Несмотря на то, что многие текстовые редакторы могут быть использованы для редактирования исходного кода, если они не не имеют расширенных возможностей, автоматизирующих или упрощающих ввод и модификацию кода, то они не могут называться «редакторами исходного кода», а просто являются «текстовыми редакторами, которые также могут быть использованы для редактирования исходного кода».
Подсве́тка си́нтаксиса — выделение синтаксических конструкций текста с использованием различных цветов, шрифтов и начертаний. Обычно применяется в текстовых редакторах для облегчения чтения исходного текста, улучшения визуального восприятия. Часто применяется при публикации исходных кодовв Интернете.
Иногда интегрированная среда программирования содержит также средства для интеграции с системами управления версиями и разнообразные инструменты для упрощения конструирования графического интерфейса пользователя. Многие современные среды программирования также включают браузер классов, инспектор объектов и диаграмму иерархии классов – для использования при объектно-ориентированной разработке программного обеспечения. Хотя, и существуют среды разработки, предназначенные для нескольких языков программирования – такие, как Eclipse, NetBeans, Embarcadero RAD Studio, Qt Creator или Microsoft Visual Studio, обычно среда разработки предназначается для одного определённого языка программирования – как, например, Visual Basic, Delphi, Dev-C++.
Частный случай интегрированных сред программирования – среды визуальной разработки, которые включают в себя возможность визуального редактирования интерфейса программы.
Среда визуальной разработки – среда разработки программного обеспечения, в которой наиболее распространенные блоки программного кода представлены в виде графических объектов. Применяются в основном для создания прикладных программ и разработки графического интерфейса пользователя (GUI).
· стандартизация внешнего вида программ.
· привязка к конкретной среде разработки связана с проблематичностью перехода на другую среду разработки;
· затруднённое использование нестандартных компонентов;
· наличие недокументированных особенностей компонентов.
Некоторые визуальные среды разработки имеют собственный формат хранения проекта, и при переходе на другую среду может возникнуть непереносимость свойств проекта и некоторых частей проекта, таких как собственные библиотеки используемой среды разработки.
Некоторые изменения могут вноситься и в язык программирования. Так, например, несмотря на то, что в среде разработки Delphi за основу взят Pascal, она представляет собой уже новый язык программирования. Среду разработки, как и язык программирования, следует выбирать на этапе проектирования программного обеспечения. Правильно спроектированное программное обеспечение должно учитывать развитие и внедрение новых технологий, поэтому перенос разработки такого программного обеспечения в другую среду разработки не должен представлять трудностей.
studopedia.org — Студопедия.Орг — 2014-2022 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.012 с) .
Источник: studopedia.org
Внешние спецификации программы что это
Узбекское Агентство
Связи и Информатизации
Ташкентский Университет Информационных Технологий
Кафедра
«Программное обеспечение информационных технологий»
Преподаватель дисциплины
Выдержки из лекций
Документ «Внешняя спецификация»
Документ «Внешняя спецификация» является дальнейшим развитием документа «Соглашение о требованиях» и отражает результаты внешнего проектирования программного обеспечения. У нас принято называть этот документ «Техническим проектом». В последнее время этот документ стали чаще называть «Эскизным проектом».
Документ «Внешняя спецификация» содержит описание внешних функций проекта и ожидаемого поведения разрабатываемого продукта с точки зрения внешнего по отношению к нему наблюдателя — пользователя.
Внешняя спецификация содержит документацию описания лишь внешних аспектов программного изделия (что представляет собой изделие) и не связано с его внутренней структурой (как программное изделие организованно). И может содержать:
— название и краткое описание программного изделия;
— функциональную схему системы;
— организацию диалога программного изделия с пользователем;
— описание меню, подменю, действий функциональных клавиш;
— все экранные формы или протокольные экранные сообщения;
— сообщения, выдаваемые пользователю во время проведения сеанса работы программного изделия и ответы на них;
— сообщения об ошибках;
— подсказки пользователю, организация помощи;
— структуру и организацию баз данных;
— описание и подготовку входных данных;
— выходные печатные формы;
— другие внешние сопряжения программного изделия.
Внешняя спецификация предназначена для широкой аудитории, включая пользователя (для проверки и одобрения), авторов документации для пользователя, всех участвующих в проекте программистов, а также всех тех, кто будет заниматься тестированием продукта.
Документ должен быть читаемым и хорошо логически организованным. Он должен учитывать все требования пользователя и отвечать на все вопросы пользователя и разработчиков в области функциональной разработки. Если требование пользователя не может быть удовлетворено, необходимо объяснить, почему, а не просто исключить его из спецификации.
Спецификация внешнего проекта — это документ, объясняющий в бизнес-терминах, что и в каком виде должен делать программный продукт. Все в нем должно представлять интерес для пользователя.
Документ пишется на естественном языке в терминах понятных и пользователю, и разработчику. Он не должен быть перегружен техническими подробностями, структурами файлов и прочими технологическими деталями.
Пользователю интересно будет знать, как будет устроен интерфейс приложения: состав меню, внешний вид экрана, подсказки и помощь пользователю и т.д.; какие отчеты будут представлены программой и как она будет осуществлять переход из одной точки в другую, интерактивной режим работы.
Желательно, чтобы спецификация была удобночитаемой, краткой, точной и исчерпывающей. Двусмысленность в спецификации недопустима.
В работе Parnas DL Technigue for software module specification with examples. Д.А. Парнас предложил следующий метод, составления спецификации на программный модуль.
1. Информация о структуре вызывающего модуля не должна содержать во внешней спецификации на вызываемый модуль.
2. Внешняя спецификация должна быть написана на понятном пользователю и производителю языке для уменьшения вероятности возможных недоразумений.
3. Модули должны быть построены таким образом, чтобы при необходимости внешних изменений в одном из них не приходилось бы изменять связанные с ним модули и процедуры.
4. Рецензент внешней спецификации должен считать, что будут реализованы только те свойства, которые определены в спецификации.
Например, если во внешней спецификации без дополнительных оговорок написано, что «параметр А может принимать любое значение в пределах от 3 до 14», то он вправе предположить, что дробные числа, такие, как 5,71 допустимы, а граничные значения 3 и 14 недопустимы. Недопустимыми являются также числа 123, 0, 29999, 3.001, 115.
5. Ограничения должны быть полностью и точно определены, но причину возникновения этих ограничений указывать не обязательно.
Причины ограничений можно включить во внутреннюю спецификацию, если эта информация в дальнейшем будет помогать специалистам, устраняющим дефекты или расширяющим возможности модулей, избегать нарушения установленных ограничений.
6. Проверка корректности и полноты внешней спецификации должна проводиться еще до начала программирования.
Всегда целесообразно перед программированием организовывать рассмотрения этого документа пользователями или их представителями для утверждения и одобрения.
Материал сайта является электронным пособием
по дисциплине «Технология Программирования»
в помощь студентам ТУИТ.
Источник: tehprog.ru