23 Внешнее описание пс.
Программная система – это набор взаимосвязанных друг с другом программ и наборов данных.
Разработка программных систем начинается с формирования требований, в котором, исходя из пожеланий заказчика должен быть получен документ – внешнее описание.
Внешнее описание.
Исходным документом является описание трабования. Часто определению требований предшествует процесс выяснения целесообразности и реализации программной системы. Иногда для выявления действительных потребностей пользователя приходится разрабатывать упрощенную версию, называемую прототипом. В определении внешнего описания: описание поведения программного средства. Требования к качеству программного средства должны быть сформулированы так, чтобы разработчику были ясны цели разработки.
Разработка функциональной спецификации предшествует.
Внешнее описание = определение требований + спецификация качества ПС + функциональная спецификация.
Внешнее описание не определяет устройство
24 Определение требований к ПС.
Программная система – это набор взаимосвязанных друг с другом программ и наборов данных.
Определение требований к ПС является исходным документом разработки, где в абстрактной форме отражаются требования пользователя.
Способы разработки определения требований к ПС:
-
Управляемая пользователем разработка;
-
Контролируемая пользователем разработка;
-
Независимая от пользователя разработка.
-
Когда заключают договор на разработку, требования к ПС являются частью договора. Роль разработчика: выяснение понятности этих требований. С целью управления разработки в договор включают пункт, который запрещал бы радикальный пересмотр требований на стадии реализации;
-
Требования к ПС формируются разработчиком при участии представителей пользователей. Роль пользователей – информирование разработчика о своих потребностях, а также контролю того, чтобы формирование требования отражали потребности пользователя. Утверждаются представителем пользователей;
-
Требования к ПС предъявляются без участия пользователей. В тех случаях, когда создается ПС широкого применения.
25 Функциональная спецификация ПС. Методы контроля внешнего описания ПС.
Функциональная спецификация ПС формулируется на естественном языке. Состоит из:
-
Описания внешней информационной среды, к которой должны применяться программы разрабатываемой ПС;
-
Определение функций ПС, определенных на множестве состояний этой информационной среды (внешние функции ПС);
-
Описание нежелательных (исключительных) ситуаций, которые могут возникнуть при выполнении программ программ ПС и реакций на эти ситуации, которые должны обеспечить соотв-е программы.
-
Каналы ввода-вывода, информационные объекты, к которым будет применяться ПС, а также существенные связи между этими информационными объектами;
-
Обозначение всех определенных функций, специфицируются все входные данные, результаты выполнения каждой определенной функции, включая указания их типов и задание всех соотношений и ограничений, которым должны удовлетворять эти данные и результат, семантика каждой из этих функций;
-
Перечислены все существующие случаи, когда ПС не может выполнить свою функцию с точки зрения внешнего наблюдателя. Для каждого такого случая должны быть описана реакция.
Методы контроля внешнего описания ПС
-
Статический просмотр;
-
Смежный контроль;
-
Пользовательский контроль;
-
Ручная имитация.
-
Внимательный просмотр с целью выяления неточностей и ошибок;
-
Спецификация качества сверху – это ее проверка со стороны разработчика требованиями ПС, а смежный контроль функциональной спецификации – это ее проверка разработчиками требованийк ПС и спецификации качества. Смежный контроль внешнего описания снизу – изучение и проверка разработчиками архитектуры ПС, а также разработчиками комплекта тестов;
-
Выражает участие пользователя в принятии решения при разработке внешнего описания и его контроля. Если разработка требований велась под управлением пользователя, то пользовательский контроль внешнего описания означает его смежный контроль сверху. Если представителю пользователя трудно разобраться во внешнем описании, то создается специальная группа разработчиков, выполняющая роль пользователя для проведения такого контроля;
-
Выражает динамический контроль внешнего описания, точнее, функциональной спецификации. Необходимо приготовить исходные данные и на основании функциональной спецификации осуществить имитацию поведения в разрабатываемом ПС. Такая имитация осуществляется специально назначенными разработчками, выполняющими роль будущей программы. Разновидность – имитация за терминалом. Данные вводятся в компьютер человека, играющего роль пользователя, передаются на другой терминал, выполняющий роль ПС. Полученные результаты анализируются.
26 Техническое задание на разработку ПС.
Схема
-
Введение – общая характеристика системы, в достаточной степени подробная, чтобы будущий пользователь мог принять решение о том, отвечает ли она его требованиям или нет;
-
1 Перечисляются все функции, которые ПС должно выполнять;
-
2 Определяется круг пользователей, на которых ориентируется ПС;
-
3 Описываются источники исходных данных, а также источники данных, используемых для корректировки;
-
4 Описываются формы, определяется периодичность, содержание выходной информации.
-
Определяется минимальный состав оборудования для нормальной работы ПС;
-
1 Конфигурация тех. средств: указывается требуемый объем места на жестком диске и т.д.;
-
2 Указываются типы ОС, используемых библиотек, СУБД и т.д.;
-
3 Режимы ПС. Пакетный режим.
-
Описывается взаимодействие пользователя с внешней системой
-
1 Форматы данных, их количество, структура;
-
2 Ответы, сообщения, подсказки;
-
3 Управляющие параметры — параметры, задаваемые при настройке системы на конкретную конфигурацию технических и программных средств;
-
4 Средства, обеспечивающие сохранность данных.
-
1 Стандарты предметной области и области программирования;
-
2 Уровень независимости системы от конкретных внешних условий, с учетом которых она разрабатывается;
-
3 Управляющие параметры — параметры, задаваемые при настройке системы на конкретную конфигурацию технических и программных средств;
-
4 Средства, обеспечивающие сохранность данных.
-
1 Перечень документации, прилагаемой к ПС;
-
2 Спецификация программ — общее функциональное описание программ, входящих в состав ПС;
-
3 Общее описания взаимодействия отдельных информационных потоков в системе.
27 Понятие архитектуры ПС. Основные классы архитектур ПС. Контроль архитектуры ПС.
Архитектура ПС – его строение, представление ПС как системы, состоящей из некот. совокупности взаимод. подсистем. В качестве таких подсистем выступают отдельные программы. Задачи – внедрение прогр. подсистем и отображение на них внешних функций и определение способов взаим-я между выделенными программными подсистемами.
Классы архитектур ПС.
-
Цельная программа – вырожденный случай архитектуры, в составе 1 программа;
-
Комплекс автономно выполняющихся программ, сос-т из подпрограмм так, что
-
а)Любая прога может быть активна, запущена пользователем;
-
б)При выполнении активизированной программы другие не могут быть активизированы;
-
в)Все проги из этого набора применяются к одной и той же инф. среде.
Сложная ПС – состоит из упорядоченной совокупности прог
-
а)На каждом этапе ничего не известно о св-вах и сущ о более высоких слоёв;
-
б)Каждый слой может взаимодействовать по управлению с более низким слоем через заранее определённый интерфейс;
-
в)Каждый слой располагает определ. ресурсами, кот. он либо скрывает от других слоёв, либо предоставляет след. слою через указанный интерфейс..
Недопустимо использование глобальных данных несколькими слоями.
-
Коллектив параллельно выполняющихся программ – набор прог, способных выполняться одновременно и способных взаимодействовать между собой. Взаимод. между такими производится передачей друг другу некоторых сообщений. Простейшая разновидность такой системы – конвейер (ОС юникс).
Конвейер – последов. прог, в кот. стандарт вывод каждой проги кроме самоц последней связан со стандартным вводом этой проги след последовательнотсти. (->P1->P2->…->Pn->) Конвейер обрабатывает некоторый поток сообщений, каждое сообщение поступает на ввод первой программе, кот перераб. предаёт сооб следующей, а сама начинает обработку след сообщений. Необходимо обеспечить синхронизацию этих потоков. В обзем случае коллектив парал-но дейст-щих прог может быть организован в систему с портами сообщений(порт сообщ. – программный вход в систему, обслуж. очередь сообщ).
Контроль архитектуры ПС
-
Смежный контроль
-
а)Сверху – проверка со стороны разработчика требований к ПС и спецификации качества;
-
б)Снизу – проверка архитектуры ПС. документация по разработке комплектов тестов и применению.
Ручная имитация – динамический контроль внешнего описания, функциональной спецификации программного средства. необходиомсть подготовки исходных данных(тесты), на основании функц-ой спец-ции осуществить имитацию поведения ПС.
28 Вспомогательные средства проектирования ПС (схемы ВарньеОрра, СИС, схемы HIPO, функциональные схемы)
Вспомогательные средства проектирования ПС. Схемы Варнье-Орра. Эта иерарх. схема контрольных изобр-й, опирающихся на структуру входных и выходных данных. Сначала система разделяется на ряд отд. про???-в. Затем указ-ся потоки данных для каждого процесса. Затем перечисляются наборы данных, носители инфы.
Для построения диаграмм Варнье используют 3 базовых элемента: последовательность, выбор, повторение.
Картинка
Каждый столбец следует понимать как описание программы. каждый столбец является уточнение предыдущего.
Функциональная схема ПС.
Состоит из нескольких блоков, содерж-щих название программ. эти блоки соед-ся входящими в них стрелками и источниками с исходящими из них стрелками с приёмниками данных. Источники и приёмники изображаются в виде блоков согласно ЕСПД.
Картинка
Функциональные схемы, учитывающие синхронизацию процесса.
На функц. схеме можно отобразить коор-ю программ во времени, включив синхронный интерфейс. Система выполнит след действия: создание файла, корректировка, исполнение, система работает в интерактивном режиме.
Картинка
На схеме не видно, что доступ к БД не может быть получен до завершения её формирования. Для этого используются ПЕРТ-диаграмма. Представляет собой граф, ребра-работа, вершина-событие.
Картинка
каждой стрелке соотв опред операции, а кружок – событию. Событие показывает, что БД свободна для использ.
На ПЕРТ-диаграмме нельзя показать, что корректировка и выборка не совместима во времени. Для того чтобы это показать, используются сети Петри. Используются в качестве моделей, котор описывают движение потоков в данных сетях, допускающих частичное или полное переключение потоков данных из одних мас-тей в другие.
Сети Петри позволяют исследовать как потоки данных, так и динамику передачи управления в системе.
Для этого стоится несколько схем, отраж-х послед-е сост-е сети. Кружки на диаграммах нах позициями, изображ наборы данных, вертик линии – процессы, жирная точка – набор данных в данных момент актив.
Картинка
Еще картинка
Схемы информационных связей(СИС) – проеобр иерархические связи путём удаления линий управ-ми модулями, отключ-я линии потоков данных. Эти линии отражают источники и названия инф.
И еще картинка
Схемы HIPO – иерарх описание входов обработки выходов. Использ на стадии проектирования. Для детал разработки взаимод-я отдельных модулей можно использовать такую схему.
|
Вход |
Обработка |
Выход |
|
1 Исходные данные 2 БД. уточнённые данные 3 Данные БД. |
Проверка правильности данных 1 проверка новых данных 2 корректировка 3 формирование отчёта |
1 сооб-я об ошибках 2 создание БД 1 сооб-я об ошибках 2 обновлен БД Отчёт номер 1 |
Проектируемая документация должна сожержать след инфу:
-
перечень важных функций;
-
определение потоков данных;
-
графич описание процесса передачи данных и управления;
-
перечень носителей инфы, использ для хранения всех наборов данных;
-
описание средств взаимод-я с вычисл-ой средой, включ уже имеющиеся наборы данных и программы;
-
треб-е к синхр-ии выпол-х операций с учётом допустимости данных;
-
предложение по разработке средств защиты;
-
примеры.
29 Объекты и отношения в программировании
Объект (предмет) - всё, что предствляется чувством (объект вещественный) и всё, что представляется умом (умственный) - по Далю.
Объект воплощает некоторую сущность и имеет некоторое состояние, которое может изменяться со временем. Объект может иметь внутреннюю структуру, т.е. состоять из других объектов, которые могут находиться в отношениях.
Объекты могут быть неделимыми и делимыми. Отношение связывает некоторые объекты. Объединение этих объектов обладает некоторым свойством. Если отношение связывает n объектов, то оно называется n-арным (n-местным). Одноместное отношение называетя простым своством объекта, многоместное - ассоциативным.Состояние объекта можно изучать по простым или ассоциативным свойствам. Множество объектов, обладающих общим набором свойств, называют классом. Каждый объект может быть представлен некоторой структурой данных. Простые свойства объекта могут задаваться в виде отдельных компонентов, либо специальной функцией этой структуры данных. Ассоциативные свойства (n > 1) можно представить в активной или пассивной форме. В активной форме n-местное отношение представляется некоторым фрагментом программы, реализующим n-местную функцию. В пассивной форме такое отношение может быть представлено некоторойструктурой данных (реляционной базой данных). Пользователи могут получать информацию об оъектах различными способами. В одних случаях пользователя могут интересовать свойства определенных объектов, в других - результаты взаимодействий с объектами, в третьих - изменение состояний объекта. Это требует использования нисходящих информационных моделей таких объектов, создания программных средств, моделирующих их свойства и предоставление пользователю доступа к этим моделям. В структурном подходе это было затруднено. Сущность состоит в систематическом использовании объекта при опиании...
Категории объектов. - объекты модельного мира (вещественного или умственного); - информационные модели объектов реального мира (пользовательсие объекты); - объекты процесса выполнения программ; - объекты процесса разработки ПС (технологические объекты программирования).
Пассивный объект представляет собой некоторый объект информационой среды, который способен хранить разные данные определенного типа, и с которым связан некоторый набор операций. Операции над таким объектом применяются под воздейтсвием некоторой внешней по отношению к этому объету активной силы, исходящей либо от пользователя, либо оот какого-либо программного объекта, находящегося в процессе выполнения.
Активный объект представляет собой такое расширение пассивного объекта, в котором фрагменты информационной среды способны также хранить программные фрагменты, способные находиться в активном состоянии.
При объектном подходе разработка программного средства приобретает объектные черты: - использование системы понятий, позволяющих описывать объекты и их классы; - декомпозиция объектов является основным свойством упрощения ПС; - использование внепрограммных абстракций для управления процессом разработки; - приоритет разработки структуры данных перед реализацией функций.