Оглавление Введение ......................................................................................................................................1 Основные тенденции образования и развития технологии программирования ...................2 Проблемы разработки сложных программных систем ...........................................................4 Жизненные циклы разработки ПО. ...........................................................................................5 Оценка качества процессов создания ПО. ................................................................................8 Понятие технологичности ПО. ..................................................................................................9 Нисходящая и восходящая разработка ПО ............................................................................10 Эффективность и технологичность ПО ..................................................................................11 Программирование с защитой от ошибок ..............................................................................12 Определение требований к ПО и исходных данных для его проектирования ...................13 Разработка технического задания ...........................................................................................15 Принципиальные решения начальных этапов проектирования. ..........................................16 Анализ требований и определение спецификаций ПО при структурном подходе ............18 Схема классификации модели разрабатываемого ПО используемых на этапе определения спецификаций. ................................................................................................18 Структура данных и диаграммы отношения компонентных данных ..................................24 Диаграмма Джексона. ...........................................................................................................25 Скобочные диаграммы Орра ...............................................................................................25 Проектирование ПО при структурном подходе ....................................................................29 Определение спецификаций ПО при объектном подходе ....................................................31 Определение вариантов использования .............................................................................32 Диаграммы классов...............................................................................................................34 Диаграмма последовательности систем .............................................................................36 Диаграмма деятельности ......................................................................................................37 Проектирование ПО при объектном подходе ........................................................................38 Разработка структуры ПО при объектном подходе ..........................................................38 Определение отношений между объектами .......................................................................39 Проектирование классов ......................................................................................................42 Разработка пользовательских интерфейсов ...........................................................................45 Типы интерфейсов ................................................................................................................45 Пользовательские и программные модели интерфейса ....................................................47 Классификация диалогов и общие принципы их разработки...........................................48 Основные компоненты графических пользовательских интерфейсов. ...........................49 Тестирование программных продуктов ..................................................................................51 Структурный подход. ...........................................................................................................51 Функциональный подход Функциональное тестирование ...............................................52 Комплексное тестирование. .................................................................................................53 Составление программной документации..............................................................................54 Виды программных документов. ........................................................................................54 Введение Создание программной системы – трудоёмкая задача, в которой объём программного обеспечения превышает сотни тысяч операторов. Специалист в области разработки программного обеспечения должен иметь представление о методах анализа проектирования, реализации и тестирования программных систем, а так же ориентироваться в современных подходах и технологиях. Технология программирования называют совокупность методов и средств используемых в процессе разработке программного обеспечения. Как и любая другая технология программирования представляет собой набор технологических инструкций, включающих: 1. указания последовательности выполнения технологических операций 2. перечисление условий, при которых выполняется та или иная операция 3. описание самих операций, где для каждой операции определяются исходные данные, результаты, нормативы и стандарты, критерии и методы оценки Метод. Материалы, инструкции, нормативы Исх данные Техническая операция операция Исполнители прогр и тех ср-ва Кроме набора операций и их последовательности технология определяет способ описания проектирования системы на каждом этапе разработки системы. Бывают технологии которые решают конкретную отдельную задачу, и технологии которые охватывают весь процесс разработки. Основные тенденции образования и развития технологии программирования 1й этап: Стихийное программирование от начала 60х годов. Программы имели простейшую структуру. Программа состояла из глобальной программы и подпрограмм которые к ней обращались. При увеличении подпрограмм возрастала вероятность увеличения искажения глобальных данных. Для предотвращения эти ошибок появилось такое понятие как локальные данные. Такой подход создал кризис программирования. Он заключался в следующем: 1) не соблюдались сроки создания 2) проект устаревал раньше, чем был готов 3) увеличивалась его стоимость Многие проекты так и не были запущены! 2й этап: Структурный подход к программированию 60-70гг. Он представляет собой совокупность рекомендуемых технологических приёмов, охватывающих выполнение всех этапов разработки программы. В основе лежит декомпозиция (разбиение на части) сложных систем с целью последующей реализации в виде отдельных небольших подпрограмм, порядка 50-100 операторов. Таким образом проектирование строилось сверху вниз и обеспечивало проработку и реализацию общей идеи построения программы. В структурный подход заложены классические языки программирования СИ и Паскаль. Но этого оказалось не достаточным для разработки сложных программ, и возникла потребность в новом структурировании данных, в связи с чем в языках программирования появляется возможность определять новые пользовательские типы данных. В результате чего стала развиваться новая модульная технология программирования. Основная программа (глобальные данные) Данные 1 П1 Модуль 1 Модуль К данные данные Данные П2 Данные Пn Данные 1 П1 Данные П2 Данные Пn Модульное программирование предполагает выделение 2х программ, использующих одни и те же глобальные данные в отдельно компилируемые модули (библиотеки) графические модули, модуль. Связи между модулями в этой технологии осуществляется через специальный интерфейс. При этом доступ к реализации в модули запрещён. Си++, VB, современный паскаль. Использование модульного программирования существенно упростило разработку ПО несколькими программистами. 3й этап: Объектный подход к программированию 80-90гг Определяется как технология создания сложного программного обеспечения, основанное на представление программы виде совокупности объекта. Каждый из которых является экземпляром определённого типа (класса). В свою очередь классы образуют иерархию с наследование свойств. Взаимодействие объектов в таких системах осуществляется путём передачи сообщений. Основным свойством ООП является более естественная декомпозиция ПО. Это приводит к более полной локализации данных, что позволяет везде независимую разработку отдельных частей программы. Кроме этого объектный подход предлагает новый способ локализации программ, основанный на механизмах наследования, полиморфизма и композиции. Это позволяет создавать библиотеки классов для различных применений. Развитие технологий программирования основанных на объектном подходе позволило создать визуальное программирование. Результатом ориентированного програмимир является заготовка программы в которую уже вмещены. Объектный метод имеет ряд недостатков: 1. Отсутствуют стандарты компоновки, объектов в единое целое 2. Изменение реализации одного из программных объектов связано с перекомпоновкой всего ПО. Таким образом сохраняется зависимость ПО. Поэтому с середины 90х годов появился новый этап: Компонентный подход и CASE – технологии. Этот подход предполагает построение программного обеспечения из отдельных компонентов, физически отдельно существующих частей программного обеспечения, которые взаимодействуют через интерфейсы. В отличии от обычных объектов объекты компоненты можно собрать в динамически вызываемые библиотеки, или в исполняемый файл. И дальше использовать их в любой программе поддерживающей данную технологию. Компонентный подход лежит в основе технологий разработанный на базе COM (component object model) и технологии распределённых систем COBRA общая архитектура с посредником обработки запросов. Технологи СОМ определяет общие правила взаимодействия программ любых типов: библиотек, приложений, ОС. И позволяет одной части ПО использовать функции другой в пределах одного процесса. Технология COBRA можно использовать для создания определённого ПО в разнородной вычислительной среде, принцип такой же как и у СОМ. Отличительной особенностью современного этапа развития технологий является создание и внедрение автоматизированных технологий которые назвали KASSE технологии/ На сегодня поддерживающий как объектный так и структурный . В течении последних лет появился и получил развитие унифицированный язык модулирования UML – он является основой, для целого спектра различных средств программирования. Проблемы разработки сложных программных систем Сложные ПО: 1. сложность формального определения требования к программным системам 2. коллективная разработка 3. необходимость увеличения степени повторяемости кодов 4. отсутствие удовлетворительных средств формального описания поведения дискретных систем. I. 1. При определении требований необходимо учесть большое количество различных факторов. 2. разработчики не являются специалистами предметной области и не могут сформулировать проблему в нужном ракурсе. 3. В процессе создания программных систем используют языки сравнительно низкого уровня, это приводит к крайней детализации операций и увеличивает объём описаний разрабатываемых программ. Средств позволяющих детально описывать поведение сложных систем на более высоком уровне, чем язык программирования не существует 4. Коллективная разработка Необходимость увеличения и степень кодов. Для повышения производительности труда компании стремятся к созданию библиотек компонентов которые можно использовать в дальнейшей разработки. При этом компоненты стараются делать более универсальные, что в итоге приводит к увеличению сложности разработки. Жизненные циклы разработки ПО. Жизненным циклом ПО называют период с момента появления идеи ПО до момента завершения его поддержки фирмой разработчиком. Состав процессов жизненного цикла регламентируется международным стандартом ISO/IEC 12207, который называется информационные технологии. ISO – международная организации по стандартизации IEC – международная комиссия по электротехнике. Этот стандарт описывает структуру жизненного цикла ПО и его процессов. Процесс жизненного цикла определяется как совокупность взаимосвязанных действий преобразующие некоторые входные данные в выходные. Каждый процесс характеризуется отдельными задачами и методами их решения, а так же исходными данными. Основные процессы: приобретение, поставка, разработка, эксплуатация, сопровождение. Организационные процессы: Управление, усовершенствование, создание инфраструктуры, обучение Вспомогательные процессы: документирование, управление конфигурацией, обеспечение качества, аттестация, аудит, разрешение проблем. Процесс разработки в соответствии со стандартом предусматривает действия и задачи выполняемой разработчиком ПО в соответствии с заданными требованиями включая оформление проектной и эксплуатационной документации. А также материалов проверки работоспособности и качества прогр продуктов. По стандартам проверка включает следующие действия: 1. подготовительная работа – план работы, определяются стандарты и методы разработки 2. анализ требуемый к системе – пользоват треб, треб по безопасности 3. проектирование архитектуры системы 4. детальное проектировании ПО – определяются интерфейсы, разработка и тестинг 5. кодирование и тестирование ПО 6. интеграция ПО – все компоненты собираются в единое целое 7. тестирование ПО 8. квалификационное тестирование системы – оформление полноты документации 9. Установка ПО на оборудование заказчика 10. Приём ПО (подписание договоров) Все указанные действия можно условно выделить в стадии разработки по ГОСТу 19.102-77 Постановка задачи: в процессе постановки задачи дБ чётко формулироваться назначение ПО и определяться основные требования к нему. Каждое требование представляет собой описание необходимого или желаемого свойства ПО. Бывают функциональные требования, которые определяют функции, которые должны выполнять разрабатываемое ПО и эксплуатационные требования, которые определяют особенности его функционирования. Этап постановки задачи заканчивается постановкой технического задания в котором фиксируются все потенциальные требования к программе и принимаются основные проблемы мышления Анализ требований и определение спецификаций. Спецификации называют точное формализованное описание функций и ограничений разрабатываемого программного обеспечения. Различают: - функциональные - эксплуатационные Для получения спецификаций выполняют анализ технического задания, выбирают математический аппарат формализации, строят модель предметной области, определяют подзадачи и разрабатывают методы их решения. Проектирование – стадия технического проекта. Проектирование включает в себя: - проектирование общей структуры - декомпозицию компонентов - проектирование этих компонентов Результатом проектирования является детальная модель разрабатываемого программного обеспечения вместе со спецификациями его компонентов всех уровней. Реализация – стадия рабочего проекта – процесс поэтапного написания кода программы на выбранном языке программирования их тестирования и отладку. Существует 5 этап – сопровождение (сейчас не входит) - создание и внедрение новых версий. Для всех этапов разработки существует 3 модели жизненного цикла программного обеспечения. 1. Каскадная. Постановка задачи анализ проектирование реализация модификация Такая модель предполагает переход на следующую стадию только после полного завершения предыдущей стадии. Достоинства: 1) получение в конце каждой стадии законченного набора проектирования документации 2) простота планирования процесса разработки. Недостатки: 1) при неточных спецификациях приводят к пересмотру уже принятых решений. 2) Изменение требования заказа непосредственно в процессе разработки. 2. Модель с промежуточным контролем. В данной схеме можно вернуться на любой уровень. 3. Спиральная модель. В соответствии с этой схемой программное обеспечение создается не сразу, а итерационно с использованием метода прототипирования. Прототипом называют действительный программный продукт, реализовывающий отдельные функции и внешние интерфейсы разрабатываемого программного обеспечения. На итерации как правило специфицируют, проектируют, реализуют и тестируют интерфейс пользователя. На 2) добавляют некоторые ограниченный набор функций, на последних этапах этот набор расширяет возможности разрабатываемого программного продукта. Основным достоинством является начин-ся с некоторой итерации, на которой обеспечена определяемая функциональная полнота, продукт можно предложить пользователю, что позволяет: - сократить время до появления новых версий продуктов - заинтересовать большое количество пользователей за счет продвижения следующих версий. - ускорить формирование и уточнение спецификаций за счет практики использования продукта - уменьшить вероятность морального устарения системы за время разработки. Разработка спиральной модели жизненного цикла программы и КЕЙС технологии позволили сформулировать условия выполнения которых сокращает сроки создания ПО. Современные технологии проектирования, разработки и сопровождения ПО должна отвечать следующим требованиям: 1. Поддержка полного жизненного цикла ПО 2. Гарантированное достижения цели разработки с заданным качеством и в установленное время. 3. Возможность выполнения крупных проектов виде подсистем, разрабатываемые группой производителей (3-7 человек) с последующей интеграцией составных частей и координации ведения общего проекта. 4. Минимальное время получения работоспособной системы 5. Возможность управления конфигурации проекта, ведения версий проекта и автоматического корректного выпуска документации по каждой версии. 6. Независимость выполняемых проектных решений от средств реализации. Этим требованиям отвечает технология RAD (быстрая разработка приложений). Эта технология проектирования созданная для достижения высокой скорости, высокого качества и низкой стоимости разработки ПО. В этой технологии процесс делится на следующие этапы: 1. Анализ и планирование требования пользователя 2. Проектирование 3. Реализация 4. Внедрение На 1м этапе определяются приоритетные требования и направления ограничивающие масштаб проекта. На 2м этапе детально описываются процессы системы, требования к данным и доступа к ним и определяют состав необходимой документации. По результатам анализа этих процессов определяют количество функциональных точек и принимают решение о количестве подсистем и команд участвующих в разработке. Под функциональной точкой в технологии RAD понимают любой из функциональных элементов разрабатываемых системой, к которым относится: входной элемент приложения, выходной элемент приложения, запрос, совокупность записей, интерфейс приложения. Нормы определяющие количество человек для разработки человек: менее 1000 функциональных точек – 1 человек, от 1-4000 точек – команда (3-7 человек). На каждые 4000 точек – 1 команда. На этапе реализации выполняется интерактивное построение реальной системы. На этом этапе активно работают с заказчиками. На этапе внедрения проводят обучение пользователей и осуществляя постепенный переход на новую систему. При этом эксплуатация старой версии продолжается до полного внедрения. Оценка качества процессов создания ПО. В Текущий период рынок ПО характеризуется переходом от штучного производства ПО к промышленному. Соответственно возрастает требования к качеству что требует совершенствование процессов разработки. На настоящий момент существует несколько стандартов связанных с оценкой качества этих процессов которые обеспечивает организацию разработок, к наиболее известным относится: 1) ISO-9000 к разработке ПО ISO-9000-9004 –в этой серии сформированы необычные условия для достижения некоторого минимального уровня организации процессов. 2) LMM- представляет собой совокупность критериев оценки зрелости организации разработки и рецепты улучшения существующих процессов. Пять уровней технологической зрелости Разработчики модели СММ (SEI) определили пять уровней технологической зрелости, по которым заказчики могут оценивать потенциальных поставщиков (претендентов на получение контракта), а поставщики могут совершенствовать процессы создания ПО Каждому из показанных на рисунке уровней технологической зрелости внутри модели СММ дано следующее краткое определение: Уровень 1: Начальный (Initial) — технология разработки ПО характеризуется как произвольная (импровизированная), в некоторых случаях — даже хаотическая. Лишь некоторые процессы определены, успех всецело зависит от усилий отдельных сотрудников. Уровень 2: Повторяемый (Repeatable) — базовые процессы управления проектом ПО установлены для отслеживания стоимости, графика и функциональности выходного продукта. Необходимая дисциплина соблюдения установленных процессов имеет место и обеспечивает возможность повторения успеха предыдущих проектов в той же прикладной области. Уровень 3: Определенный (Defined) — управленческие и инженерные процессы задокументированы, стандартизованы и интегрированы в унифицированную для всей организации технологию создания ПО. Каждый проект использует утвержденную, адаптированную к особенностям данного проекта, версию этой технологии. Уровень 4: Управляемый (Managed) — детальные метрики (объективные данные) о качестве исполнения процессов и выходной продукции собираются и накапливаются. Управление процессами и выходной продукцией осуществляется по количественным оценкам. Уровень 5: Оптимизируемый (Optimized) — совершенствование технологии создания ПО осуществляется непрерывно на основе количественной обратной связи от процессов и пилотного внедрения инновационных идей.На этом уровне идёт постоянное улучшение существующих процессов, т.е. постоянно вводятся новые технологии для эффективности разработки ПО. 3. стандарт ISO/IES 15504 (SPACE) – она определяет возможности для улучшения процесса создания ПО. В основе стандарта лежит оценка процесса. Оценка выполняется путём сравнения процесса разработки ПО в данной организации с описанной в стандарте модели. Этот анализ помогает определить сильные и слабые стороны процесса, а также внутренние риски присущие данному процессу. Это помогает оценить эффективность процессов, определить причины ухудшения качества и связанные с этим издержки во времени и стоимости. В основе стандарта так же лежит определения возможности процесса, т.е. возможности его улучшения. Понятие технологичности ПО. Под технологичностью понимают качество проекта программного продукта, от которого зависят трудовые и материальные затраты на реализацию и последующие модификации. Технологичностью ПО определяется проработанность его модулей, уровнем независимости модулей, стилем программирования и степенью повторного использования кодов. Чем выше независимость модулей, тем легче понять, реализовать, модифицировать и находить ошибки. При проектировании достаточно сложного ПО выполняют его декомпозицию на модули. Модуль – автономно компилируемая программная единица. К модулям предъявляются следующие требования: 1. 1 точка входа 2. 1 точка выхода. 3. Отдельная компиляция 4. Соответствие принципу вертикального управления 5. Выполнение одной функции 6. Небольшой размер (50-70 операторов) 7. Возможность вызова других модулей Уменьшение зависимости модулей улучшает технологичность проекта. Степень независимости модулей (подпрограмм и библиотек) оценивают 2мя критериями: сцеплением и связанностью. Сцеплением является мера взаимозависимости модулей, которая определяет на сколько хороши модули отделены друг от друга. Модули не зависимы если каждый из них не содержит о другом никакой информации. Существует 5 типов сцепления модулей: 1. модули обмениваются данными. При небольшом количестве обмениваемых данных этот тип сцепления обеспечивает наилучшие технологические характеристики ПО. 2. 3. 4. 5. сцепление по образцу – модули обмениваются данными, объединённые в некоторые структуры (элементы массива) Сцепление по управлению – когда 1 модуль посылает другому некоторой информационный объект, предназначенный для управления внутренней логикой модуля. Сцепление по общей области данных – предполагается, что разные модули работают с одними данными. Такой вид сцепления считается недопустимым. Сцепление по содержимому – один модуль содержит обращение к внутренним компонентам другого. Такой вид сцепления тоже не допустим. Связанность модулей – мера прочности соединения функциональных и информационных объектов внутри одного модуля. Если сцепление характеризует качество деления модуля, то связанность характеризует степень взаимосвязанности элементов реализуемым одним модулем. Различают следующие виды связанностей, перечисляются в порядке убывания уровней: 1. Функциональная 2. Последовательная 3. Информационная (коммуникативная) 4. Процедурная 5. Временная 6. Логическая 7. Случайная Функциональная – все объекты модуля предназначены для выполнения одной функции. Последовательная – выход одной функции служит исходными данными для другой функции. Информационная – считается функция обрабатывающая одни и те же данные. Процедурно связанные – функции или данные, которые являются частями одного процесса. Временно связанные – функции выполняются параллельно или в течении определённого периода времени. Логическая связь – функции базируются на объединении данных или функций в одну логическую группу. Случайная – связь между элементами мала или отсутствует. При хорошо продуманной декомпозиции модули верхних уровней иерархии имеют функциональную или последовательную связанность функции данных. Например модули содержащие описании класса при ООП характеризуется информационной связанностью методов и функциональной связанностью данных. Кроме этого для улучшения технологических характеристик используют разделение тела модуля на интерфейсную часть и область реализации. Интерфейсная часть содержит совокупность объявления ресурсов (заголовков подпрограмм, имён переменных, типов, классов и т.д.) который данный модуль предоставляет другим модулям. Ресурсы объявления которых в интерфейсных частях отсутствуют из вне не доступны. Область реализации содержит тела подпрограмм и внутренние ресурсы используемые этими подпрограммами. При такой организации модулей изменение реализации не затрагивает интерфейса, что улучшает технологические характеристики модуля. Нисходящая и восходящая разработка ПО При проектировании, реализации и тестировании ПО применяют 2 подхода: восходящий и нисходящий. В Восходящем подходе сначала проектируют и реализуют компоненты нижнего уровня, затем предыдущего и т.д. По мере завершения проектирования осуществляют сборку. Компоненты нижнего уровня как правило помещают в библиотеки. Данный подход имеет следующие недостатки: большая вероятность не согласованности компонентов и позднее проектирование интерфейса. Восходящий подход в настоящее время не применяется при разработке ПО. Нисходящий подход. Проектирование выполняется сверху вниз. В начале проектируются компоненты верхних уровней и спускаются до самых нижних. При программировании этим методом в любой момент всегда можно провести сборку и тестирование, при этом если какие то уровни не реализованы, то на момент тестирования ставится заглушка на этот компонент. При использовании нисходящего подхода применяют иерархический, операционный и комбинированный методы определения последовательности проектирования и реализации компонентов. Иерархический метод предполагает выполнение разработки строго по уровню. Проблемы: большое количество заглушек, распределение человеческих ресурсов при сборки модулей программы. Операционный метод связывает последовательность выполнения модулей при запуске программы. Проблемы: порядок выполнения модулей может зависеть от данных ранняя разработка модулей вывода результатов с точки зрения распределения человеческих ресурсов, сложным этапом является определение начала работ. Комбинированный метод учитывает следующие факторы влияющие на последовательность разработки: достижимость модулей, т.е. наличие всех модулей в цепочки вызовов данного модуля (спуск по иерархии) зависимость по данным, модули формирующие некоторые данные должны создаваться раньше обрабатывающих. обеспечение возможности выдачи результатов готовность вспомогательных модулей. Нисходящий подход используют при объектно-ориентированном программировании ООП, т.е. сначала проектируют интерфейс, затем разрабатывают классы, а дальше проектируют компоненты. Нисходящий подход обеспечивает: 1. Максимально полное определение спецификации и согласованность компонентов между собой 2. Возможность показать продукт заказчику на ранних стадиях разработки 3. Возможность нисходящего тестирования. Эффективность и технологичность ПО Эффективными считаются программы, которые требуют минимального времени выполнения, и минимального объёма оперативной памяти. Для экономии памяти предлагается: 1. анализировать операции размещения данных, т.е. обратить внимание на выделение памяти, под данные структурных типов. 2. следует выбирать алгоритмы обработки, не требующие дублирования исходных данных в процессе их обработки Уменьшение времени выполнения программы: 1. в первую очередь необходимо анализировать циклические участки программы с большим количеством повторений. При их реализации необходимо выносить вычисление константных не зависящих от параметров циклов выражений за пределы цикла. 2. избегать длинных операций умножения и деления, заменяя их сложением, вычитанием и сдвигами. 3. минимизировать преобразование типов в выражение 4. оптимизировать запись условных выражений 5. исключать многократные обращения к элементам массива по индексам, особенно многомерных. Т.к. при вычислении адреса элементов используется операция умножения на значение индекса. Программирование с защитой от ошибок Любая ошибка программирования которая не обнаруживается на этапах компиляции и компоновки в конечном счёте всё равно может проявиться: 1. способ: выдача системного сообщения об ошибке 2. способ: зависание компьютера 3. способ: получение не верных результатов Способы проявления ошибок: Ошибки определения исходных данных Системное сообщение об ошибке Ошибки проектирования Ошибки кодирования Неверные промежуточные результаты Неверные управляющие переменные Неверные типы данных Неверные индексы массивов Неверные параметры циклов другие Ошибки накопления погрешностей Зависание компьютера неверные Неверные результаты Часть ошибок при программировании можно обнаружить и нейтрализовать. Для этого применяются спец приёмы которые называются защитными или программирование с защитой от ошибок. Анализ ошибок и их ранних проявлений показывает, что при разработке ПО необходимо проверять следующие факты: 1. Правильность выполнения операций ввода-вывода. Причинами не верного выполнения исходных данных могут являться: внутренние ошибки – ошибки ПО (ошибки передачи, ошибки преобразования); внешние ошибки – ошибки пользователя, юзверь сам вводит не верные данные. Для защиты от ошибок преобразования используют «Эхо» данные ввелись и сразу же вывелись для проверки. Обнаружить ошибки пользователя можно только с помощью, каких либо промежуточных контрольных сумм и с помощью контроля интервалов возможных значений, которые как правило определены в техническом задании и пользователю всегда нужно предоставлять введенные данные для проверки. 2. Необходимо проверять допустимость промежуточных результатов. Необходимо проверять промежуточные результаты проверка которых целесообразна, не сложна и возможно позволит обнаружить ошибку: 1. Проверка допустимость индекса массива. 2. Если строится цикл, то всегда необходимо проверить, что бы количество повторений цикла не было отрицательным. 3. Если определяется вероятность какого либо события, то необходимо проверять что бы полученное значение не было больше 1. 4. Предотвращение накопления погрешностей. Для того что бы снизить погрешность результатов вычислений необходимо соблюдать следующие правила: i. Избегать вычитания близких чисел. ii. Избегать деление больших чисел на малые iii. Снижать длинную последовательность чисел iv. По возможности уменьшить количество операций с числами v. Использовать методы уже с известными оценками погрешности vi. Не использовать условия равенства вещественных чисел, особенно с одинарной точностью 3. Обработка и исключение. Всегда при разработки ПО следует предусматривать перехват обработки аварийных ситуаций. Для перехвата практически во всех языках программирования предусмотрено средство обработки исключения. С помощью этих средств программист получает возможность предусмотреть действие, которое позволяет исправить эту ошибку или если это не возможно исправить ошибку, то выдать пользователю сообщение с точным описанием ситуации и вариантом продолжения работы. Определение требований к ПО и исходных данных для его проектирования 1. Этап постановки задачи – является одним из наиболее ответственных этапом создания программного продукта. На этом этапе формулируются основные требования к разрабатываемому ПО, поэтому на сколько полно определены функции и эксплуатационные требования на столько правильно приняты принципиальные решения определяющие процесс проектирования, стоимость разработки и его качества. Каждый программный продукт предназначен для выполнения определённой функции. По назначению все программные продукты можно разделить на 3 группы: системные, прикладные и гибридные. Программные продукты Прикладн ые Системные Операц Сист Оболочки утилиты Для разработчиков программ Гибридные Для не программист ов CASE средства Среда Общего назначения разработки Системы программирован ия Отладочны е средства Профессиональн ые Системы Автоматизированн ые системы управления в режиме РВ автоматизации производственных процессов Обучающи еРазвлекающи е К каждому типу ПО при разработке предъявляют функциональные и эксплуатационные требования. Эти требования определяют некоторые характеристики разрабатываемого ПО, предъявляемые к нему в процессе его функционирования. К этим характеристикам относится: 1. Правильность – функционирование в соответствии с техническим заданием, это требование является обязательным для любого ПО, т.е. всё что указано в ТЗ дБ реализовано. 2. Универсальность – обеспечение правильной работы при любых допустимых данных и защита от не правильных данных, это тоже обязательное требование. 3. Надёжность – обеспечение полной повторяемости результатов и обеспечения их правильности при различного рода сбоев оборудования. 4. Проверяемость – возможность проверки полученных результатов. Для её обеспечения необходимо документально фиксировать исходные данные, установленные режимы и всю информацию которая влияет на получение результатов. 5. Точность результатов – обеспечение погрешности результатов не выше заданных. Она зависит от исходных данных, степени адекватности используемой модели, точности выбранного метода и погрешности выполнения операции в компьютере. 6. Защищённость – обеспечение конфиденциальности информации. Для защищённости применяют программные средства защиты (коды, алгоритмы), кодирование информации, идентификация пользователя. 7. Программная совместимость – возможность функционирования с другим ПО. 8. Аппаратная совместимость – возможность совместного функционирования с разным оборудованием 9. Эффективность – использование минимального возможного количества ресурсов технических средств (время ответа системы, объём оперативной памяти, количество обслуживаемых внешних устройств) 10. Адаптируемость – возможность быстрой модификации для приспособления к изменяющимся условиям функционирования. 11. Повторная входимость – характеристика применяется только к резидентному ПО (дрова). Для обеспечения этого требования необходимо организовать программу таким образом, что бы никакие исходные данные не затирались в процессе её выполнения и восстанавливались при завершении каждого вызова. Разработка технического задания ТЗ представляет собой документ с которым сформулированы основные цели разработки, требования к программному продукту, определены сроки и этапы разработки и регламентирован процесс приёма сдаточных работ. В разработке ТЗ участвуют и заказчики и исполнители. В основе документа лежат исходные требования заказчика, результаты выполнения научно-исследовательских работ, предпроектных исследований и т.д. Схема: факторы определяющие параметры разрабатываемого ПО. Исходные данные Программа Результаты (перечень, характеристик Операционная система и, способ представлени Технические средства я) Основными факторами определяющими характеристики разрабатываемого ПО являются: 1. Исходные данные и требуемые результаты, которые определяют функции программы. 2. Среда функционирования программная и аппаратная. Она может быть задана и может выбираться для обеспечения параметров указанных в ТЗ. 3. Возможные взаимодействия с другими программными или техническими средствами. Разработка ТЗ ведётся в следующей последовательности: 1. Устанавливают набор выполняемых функций, а так же перечень и характеристики исходных данных 2. Определяют перечень результатов и способы их представлений 3. Определяют следы функционирования ПО (параметры тех средств, их комплектация, установленное ПО, версия ПО и т.д. т.е. всё то с чем предстоит взаимодействовать программному продукту) 4. Необходимо регламентировать действия программы в случае сбоя программы. На разработку ТЗ существует ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению». В соответствии с этим ТЗ должно содержать следующие разделы: 1. Введение – должно включать наименование и краткую характеристику области применения программного продукта. Основное назначение введения это продемонстрировать актуальность данной разработки и показать какое место занимает эта разработка в ряду подобных. 2. Основание для разработки – этот раздел должен содержать наименование документа, на основании которого ведётся разработка (приказ, распоряжение). Название организация утвердившей данный документ и наименование или условное обозначение темы разработки. 3. 4. 5. 6. 7. 8. Назначение разработки – содержит описание функционального и эксплуатационного программного продукта с указанием категории пользователя. Требования к программе или к программному изделию. Этот раздел должен включать следующие подразделы: a. Требования к функциональным характеристикам. Что должна делать система. b. Требования к надёжности. c. Условия эксплуатации. d. Требования к составу и параметрам технических средств. Описывается необходимый состав технических средств с указанием их основных технических характеристик (тип процессора). Как правило указывают 2 варианта конфигурации: минимальная и максимальная e. Требования к информационной и программной совместимости. Можно задать методы решения, определить среду и язык программирования. f. Требования к маркировки и упаковки. g. Требования к транспортировки и хранении. h. Определение каких либо специальных требований. Требования к программной документации. Указывается необходимость разработки и наличия руководств пользователя программиста, системного программиста, наличие пояснительной записки. На все типы этих документов существуют свои ГОСТы. Технико-экономические показатели. Указывается экономическая эффективность и экономические преимущества по сравнению с существующими аналогами. Стадии и этапы разработки. Указываются стадии и этапы разработки и содержание работ с указанием сроков разработки и исполнителей. Порядок контроля и приёмки. Указываются общие требования приёмки работ и виды тестирования ПО. При необходимости допускается включать в ТЗ приложения. В приложениях указывают перечень научно исследовательских работ обуславливающих разработку, схемы алгоритмов, таблицы, обоснования, расчёты и другие документы которые следует использовать при разработки. В зависимости от особенностей разрабатываемого продукта разрешается уточнять содержания разделов, т.е. использовать подразделы, вводить новые разделы и объединять существующие. В случаях если какие либо требования предусмотренные техническим заданием заказчик не предъявляет, то обязательно в соответствующем месте ТЗ необходимо указать «Требования не предъявляются». Принципиальные решения начальных этапов проектирования. Это решение, определение процесс проектирования качество трудоемкость, разработки. К этим решениям относится: 1) Выбор архитектуры ПО. Архитектурой ПО называют совокупность разовых концепций и его построение. Она определяется сложностью решаемых задач, степенью универсальности разрабатываемого ПО и количеством польз-ий предполх для работы с ними. Разделяют: -однопользовательскую архитектуру -многопользовательскую архитектуру К однопользовательским относят: -программы -пакеты программ -программные компоненты -программные Системы Под программой подразумевают набор инструментов точно описывающие последовательность действий, которые необходимо выполнять для решения конкретной задачи. Пакеты программ представляют собой совокупность программ, решающие задачи, некоторой прикладной области (AvtoCad) Программ. Комплексы – совокупность программ совместно обеспечивающих решение небольшого класса сложных зад-ч 1 приклад. обл-и. В прикладных компонентах всегда существует прикладные программы называемые диспетчер, которые последовательно или циклически вызывают различные прог-ы комплекса для решения 1 задач. Прогр-е системы- это организов. Совокупность программ, называющие решать класс задач некот-й приклад. области. В отличии от прог-х компонен-х прогр-а входящая в прог. Систему взаимодействует через общие данные, для их разр-и исполнения спец. технологии. Многопользовательская архитектура испол-я при разр-и приложений по приему клиент – сервер 2)Выбор типа пользовательского интерфейса и технологии работы с документами. Различают 4 типа пользовательского интерфейса: 1. примитивный – различают единств. специа с – аний раб-ы, ввод данных, обработка, вывод 2. меню – реализуют ти-во спе-в раб-ты, операции которых организованны в шрарх. стру-ры. 3. Со свободной навигацией. Определяет ти-во возможных операций на конкретном шаге работы. 4. Прямого манипулирования – основные операции перемещения мышью. 3) Выбор под-а к разр-ки; какой пор-у выб-ют: -структурный -процедурный - ОО (че за ОО х3, может и не ОО) Если разраб-я инт-с со свобод. новит-ей и прям. манипул., то испол-я объективноорентир. подход ( использование классов) Примитивный интерфейс (старый подход) 4) Выбор языка программирования 1. Язык может выбр-ть организ-я, вед-я раз-ку. 2.Выбор, осущест-я программистом 3.установ. мнением. Выбор возможен, если все языки разделить на группы: 1) Универсальные языки высокого уровня 2) Специализированнее языки разработка ПО. Они используются для создания конкретного типа ПО (таких как БД, системы искусственного интерфейса) 3) Специальные языки языки польз-ля – явл-я частью профессиональных сред. пользля и харак – я узкой напр-ю (1С) 4) Языки низкого уровня ( Ассемблер) 5) Выбор среды программирования. Средой программирования называют программный комплекс, который включает в себя специальный текстовый редактор, встроенный отладчик. Справочную систему и другие программы, использование к упрощает процесс опим-я и отладки программ. 6) Выбор и формирование стандарта разр-ки Применение: любой техн. Проектирования преобладают формирования ряда стандартов, которые должны соблюдаться всеми участками проекта: 1. стандарт проектирования, который определяет набор необходимых моделей схем и диаграмм на каждой стадии проектирования и степень их детализации. Здесь определяются правила фиксации проект-х решений. Опр-т треб-я к конорит-ии раб-х тест разр-в, вкл-я настр-ки ОС опред-я механизм обеспечения свом-й работы над проектом, т.е. правило интегривание подси-м проекта и анализ прое-х решений на протеречивость. Анализ требований и определение спецификаций ПО при структурном подходе Спецификации представляют собой полное и точное описание функций и ограничений разрабатываемого ПО. При этом спецификация состоит из 2х частей: функциональной (в ней описываются функции разрабатываемого ПО) и эксплуатационная (в ней определяются требования к техническим средствам, надёжности, и информационной безопасности). Требования предъявляемые к функциональным спецификациям: 1. Требование полноты спецификаций: должна содержаться вся существенная информация, все детали реализации для принятия эффективных решений. 2. Требование точности: оно означает, что спецификации должны однозначно восприниматься как заказчиком, так и разработчиком. При структурном подходе на этапе анализа и определения спецификации используют 3 типа модели: 1. Модель ориентированная на функции 2. Модель ориентированная на данные 3. Модель ориентированная на потоки данных Схема классификации модели разрабатываемого ПО используемых на этапе определения спецификаций. Модели спецификаций Не зависимые: от подхода к разработке Структурный подход Объектного подхода Диаграммы переходов состояний Функциональные диаграммы Диаграммы вариантов использования Мат. Модели предметной области Диаграммы потоков данных Контекстные диаграммы классов Диаграммы последовательности Диаграммы отношений компонентов данных Диаграммы деятельности Диаграммы переходов состояний Является графической формы представлений конечной модели используемой для моделирования поведения технических объектов или объектов реального мира. Диаграммы переходов состояний моделирует поведение разрабатываемой системы при получении управляющих воздействий. Под управляющим воздействием понимают команды пользователя или сигналы датчика. Получив управляющее воздействие система может выполнить 3 действия: 1. Выполнить определённое действие 2. Остаться в том же состоянии 3. Перейти в новое состояние Условное обозначение диаграмм переходов состояний: Терминальное состояние (начальное и конечное) Имя состояния Промежуточное состояние Условие действие переход Построим диаграмму переходов которая выполняет некоторые вычисления: Конеч состояние Исх сосояние Ввод Всегда инициализ Вычис л Всегда вычислен Вывод Всегда завершен Диаграммы переходов состояний ПО активно взаимодействующего с окружающей средой Исходное состояние Ввод Инициализаци я Вывод Завершение Конечное состояние Ожидание Воздействи еФункция 1 Воздействи еФункция 2 Воздействи еФункция 3 Пример построения диаграммы переходов состояний для программы построения графиков функций для кот было представлено ТЗ. Исходное состояние Ввод/выбо р формулы Всегда Инициализац ия Команда Завершение Ожидание Конечное состояние Выполнен ие Вывод таблицы или построение графика Ввод Ввод шага Ввод вида интервала результата Эту схему переходов необходимо согласовать с заказчиком ПО, и если его устраивает, то можно писать программу Функциональные диаграммы Они отражают взаимосвязи функций разрабатываемого ПО. Отображений взаимосвязи функций осуществляется с помощью построения иерархии функциональных диаграмм. Каждый блок такой диаграммы соответствует некоторой………………. для которой должны определены исходные данные, результаты, управляющая информация и механизмы её осуществления (чел или тех средства). Управление Исх данные Результаты Управление Механизмы Блоки на диаграмме размещают по ступенчатой схеме в соответствии с последовательностью их работы или доминированию. Доминирование – оказывание одним блоком на другие. Различают 5 типов влияния: 1. Вход-выход Функция 1 Функция 2 2. Управление Функция 1 Функция 2 3. обратная связь по выходу Функция 1 Функция 2 4. Выход исполнитель Функция 1 Функция 2 5. Обратная связь по управлению. Функция 1 Функция 2 Построение функциональных диаграмм ведётся поэтапно с увеличением уровня детализации. Стрелки приходящие или уходящие нумеруются с помощью символов и чисел. Символ обозначает тип связи: I – входная информация С – управляющая М – механизм R – результат Число – номер связи с родительским блоком, считая сверху вниз и слева на право. Все диаграммы связываются друг с другом и иерархической нумерацией блоков: 1й уровень нумеруется А0 2й уровень– А1, А2…… 3й уровень – А11, А12, А21, А22…….. Детализацию завершают после получений функции значение которых понятно и разработчику и пользователю. В процессе построения иерархии диаграмм фиксируют всю уточняющую информацию и строят словарь терминов. Словарь терминов представляет собой краткое описание основных понятий используемых при составлении спецификаций. Он содержит определение основных понятий, а так же всех сокращений и условных обозначений. Описание терминов словаря выполняется по следующей схеме: Термин: Алгоритм Категория: Понятия предметной области Описание: В данном проекте используется для обозначения команд Пример: функциональная диаграмма для построения графиков: Верхнего уровня Функция Отрезок График Построение графиков/ таблиц А0 Таблица Шаг Детализированная диаграмма I1 Ввод/выбор функции и её разбор Добавление функций в список A1 A4 С I2 I3 Построение таблицы значений 1 R 2 С A2 Количество точек I1 – функция I2 – отрезок I3 – шаг 1 Построение графика функции R 1 A3 С1 – вид график/функция R1 – график R2 – таблица значений Диаграмма потоков данных Позволяют специфицировать функции разрабатываемого ПО и вместе с ним обрабатываемые им данные. В основе этой модели лежат понятия: 1. Внешняя сущность – материальный объект или физическое лицо выступающее в качестве источников или приёмников информации 2. Процесс – преобразование входных потоков данных в выходные в соответствии с определённым алгоритмом. Каждый процесс в системе имеет свой номер и связан с исполнителем, который осуществляет данные преобразования. 3. Хранилище данных – абстрактное устройство для хранения информации. При этом тип самого устройства и способы хранения информации не детализируются 4. Поток данных – процесс передачи инфы от источника к приёмнику. Таким образом диаграмма потоков данных иллюстрирует, как потоки данных порожденные внешними сущностями трансформируются соответствующими процессами, сохраняются накопителями данных и передаются другим внешним сущностям, которые являются приёмниками информации. Для изображения диаграмм потоков данных используют 2 способа: Понятие Внешняя сущность Йордана Де Морга Наименован ие Процесс Номер Наименован ие номер Наименован ие номер Накопитель данных наименовани е Поток Гейна-Сарсона наименовани е наименован ие механизм №| наименование наименовани е Построение иерархии потоков данных начинают с контекстной диаграммы которая определяет общий вид системы. На ней отображают взаимодействия системы с приёмниками и источниками информации без указаний исполнителей. На 2м этапе каждую подсистему контекстной диаграммы детализируют при помощи диаграмм потоков данных. Диаграмма по Гейна-Сарсену Список функций Таблица 1 Учащиеся График 1 График/Таблица Шаг Программа построения графиков/таблиц Отрезок Функция 1.1 Функц ия Правильные функции Ввод/выбор функции и её разбор Функции D1 A1 A4 1.2 Отрезок Шаг Построение таблицы значений Таблица значений функций 1.3 A2 Количеств о точек Построение графика функции Граф ик A3 Структура данных и диаграммы отношения компонентных данных Структурой данных называют совокупность правил и ограничений, которые отображают связи существующие между отдельными частями данных. Существует 2 вида структур: 1. абстрактный – используется для уточнения связей между элементами 2. конкретные структуры – используются для представления данных в программах Все абстрактные структуры делятся на 3 группы: 1. Не связанные – элементы которых не связаны между собой. К ним относятся множества и кортежи. 2. С не явными связями. К ним относятся вектор, матрица, массив, запись, строка и т.д. 3. С явными связями (графы). К ним относятся цепь, цикл, дерево, ориентированный граф, взвешенный граф, мультиграф. Элементы 1й группы используются, если никакие отношения элементов не являются существенными для описываемых объектов. Использование элементов 2й группы используют, когда существенными являются вхождение элементов данных в некоторую структуру, а так же их порядок и когда используются отношения иерархий структур. 3ю группу используют, когда в качестве модели структур данных используют граф. В реальной ситуации возможно вложение структур данных, в том числе и разных типов. Соответственно для их описания требуются специальные модели. В зависимости от описываемых типов отношений модели структур данных делятся на иерархические и сетевые. Иерархические модели позволяют описывать упорядоченное или не упорядоченные отношения вхождения элемента данных в компонент более высоко уровня (множества, таблицы, комбинации). К иерархическим моделям относят модель Джексона Орра, которая состоит из диаграмм Джексона и скобочных диаграмм Орра. Сетевые модели основаны на графах и соответственно они поэтому позволяют описывать связанность элементов данных не зависимо от видов отношений. К сетевым моделям относят модель «Сущность-связь», обычно используемых при разработки БД. Диаграмма Джексона. В основе диаграмм Джексона лежит предположение о том, что структуры данных, так же как и программ можно строить из элементов с использованием всего 3х основных конструкций (последовательности, выбора, повторения). Каждая конструкция представляется в виде 2х уровней иерархии. На верхнем расположен блок конструкция, на нижнем блоки элементов. Конструкции различают специальными символами в правом верхнем углу блоков элементов. При изображении последовательности символ не указывается. При изображении выбора ставится символ «О» - сокращённое от OR «ИЛИ». Конструкции последовательности и выбора обязательно должны содержать по 2 или более элементов 2го уровня. При изображении повторения в блоке единственного (повторяющегося) элемента ставится значок * А В С y S D P0 Q0 R0 X* Скобочные диаграммы Орра Они базируются на тех же диаграммах, что и диаграммы Джексона – структуры данных можно строить. Отличие состоит в том что для предоставления конструкции используются фигурные скобки P A * A B S Q y n раз C R Пример: Описанить структуру данных файла «Электронная ведомость» которая отображает № группы, записи об успеваемости студентов (ФИО, предмет, оценка) Файл Тело файла Номер группы Конец файла Студент * Конец записи Данные ФИО Успеваемость Предмет Оценка Число0 Файл № группы Тело файла Конец файла Предмет оценка Студент № раз Буква0 ФИО Данные Конец записи Успеваемость № раз Число + Буква Сетевые модели данных Используются в тех случаях, если отношения между компонентами данных не исчерпываются включением. Для графического представления используют 3 вида модели: 1. Модель П.Чена 2. модель Баркера 3. модель IDEF1 Модель Баркера является наиболее распространённой. Базовыми понятиями сетевой модели данных являются: сущность, атрибут и связь. Сущность – реальный или воображаемый объект имеющий существенное значение, для рассматриваемой предметной области. Каждая сущность должна иметь 1. уникальное имя 2. обладать одни или несколькими атрибутами, которые принадлежат сущности или наследуются через связь 3. обладать атрибутами, которые однозначно идентифицируют каждые экземпляр сущности Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, предметов и т.д.). Имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр. На диаграмме Баркера сущность изображается прямоугольником с закруглёнными углами. Каждая сущность обладает одним или несколькими атрибутами. Атрибут – любая характеристика сущности, которая является значимой для рассматриваемой предметной области и предназначена для квалификации, идентификации, количественной характеристики или выражения состояния сущности. Атрибуты делятся на ключевые и описательные. Ключевые – это те которые входят в состав уникального идентификатора, описательные – все прочие. Все …… перемещают в начало списка и обозначают решёткой. Описательные атрибуты бывают обязательные и не обязательные. Обязательные – те кот имеют конкретные значения, для каждой сущности. Не обязательные – те кот могут быть не определены. Обязательные элементы помечают знаком *, необязательные буквой 0. Имя сущности Имя сущности Имя сущности Атрибут 1 Атрибут 2 Атрибут 3 #Атрибут 1 *Атрибут 2 0 Атрибут 3 1. сущность без атрибутов 2. сущность с атрибутами 3. сущность с уточнением атрибутов Для сущности определены 2 понятия: 1. Супер-тип – сущность обобщающая некоторую группу сущности (подтипов). Он характеризуется общими для подтипов атрибутами и отношениями. Например: супертип - учащийся 2. Подтип Имя супертипа Имя подтипа 1 Имя подтипа 2 Между сущностями можно устанавливать связи. Связь означает, что каждый экземпляр одной сущности ассоциирован с произвольным (в т.ч. и нулевым) количеством экземпляров 2й сущности, и наоборот. Если любой экземпляр одной сущности связан хотя бы с одним экземпляром другой сущности, то связь является обязательной и обозначается сплошной линией. Сущность 1 Сущность 2 Необязательная связь предоставляет собой условное отношение между сущностями. Сущность 1 Сущность 2 Кроме этого сущности бывают не зависимыми, зависимыми и ассоциативными. Не зависимая сущность представляет собой независимые данные которые всегда присутствуют в системе. Зависимая сущность представляет данные зависящие от других сущностей системы, поэтому она всегда должна быть связана с теми сущностями от которых зависит. Ассоциативная сущность представляет данные, которые ассоциируются с отношением между 2мя или более сущностями. Если экземпляр сущности полностью идентифицируется своими ключевыми атрибутами, то говорят о полной идентификации сущности. В противном случае идентификация сущности осуществляется с использованием атрибутов связанной сущности. Идентификация сущности по средствам другой. На схеме их отличают: Сущность 1 Сущность 2 Модель Бакера включает понятия взаимоисключающих, рекурсивных и не перемещаемых связей. Взаимоисключающая связь Сущность 1 Сущность 2 Сущность 3 При наличии этой связи экземпляр сущности участвует только в одной связи из некоторой группы связи. Рекурсивная связь: Сущность 1 Предполагает что сущность может быть связана сама с собой Неперещаемая Сущность 1 Сущность 2 Означает, что один экземпляр сущности не может быть перенесён из одного экземпляра в другой Пример: Структура БД для системы учёта успеваемости студентов. Основными сущностями для решения данной задачи является студент и предмет. Отношения между ними относятся многие ко многим. Для разрешении между ними введём ассоциативную сущность экзамен/зачёт, которая будет отражать текущее выполнение предметного плана. Предметы кот изучает студент отражаются в учебном плане. Он включает в себя список предметов для каждого предмета. Для этого определим сущность семестр. На основании успеваемости студентов будем получать справки любого вида. Для их получения потребуются сущности определяющие структуру организации, к ним должны относится факультет, курс, кафедра и группа. Для определения момента времени начиная с которого отсутствие положительных результатов сдачи сессии считается задолжностью, необходимо хранить даты экзаменов для каждой группы. Появляется сущность: дата, экзамен. Схемы отношений между сущностями (копия). Проектирование ПО при структурном подходе Процесс проектирования сложного ПО начинается с уточнения его структуры т.е. определение структурных компонентов и связей между ними. Результат уточнения структуры Мб представлен в виде структурной или функциональной схем и описания спецификации компонентов. Структурной схемой называют схему отражающую состав и взаимодействие по управлению частей разрабатываемого ПО. Структурную схему разрабатывают для каждой программы входящей в пакет программ, а список программ пакетов определяют исходя из задач описанных в ТЗ. Самый простой вид ПО – это программа, которая в качестве структурных компонентов включает подпрограммы или библиотеки. Разработку структурной схемы программы выполняют методом пошаговой детализации. Функциональная схема – схема взаимодействия компонентов ПО с описанием информационных потоков, состава данных потоков, указания использования файлов и устройств. Для изображения функциональных схем используются специальные обозначения установленные стандартом ГОСТ 19.71-90. Функциональные схемы более информативны, чем структурные. Все компоненты структурных и функциональных схем дБ описаны. Пример программного комплекса: Диспетчер программного комплекса Программы Программы Программы вычисления решения системы определения корней определённого интеграла уравнений уравнения Пример структурной схемы программного комплекса Система учёта успеваемости студентов Подсистема заполнения базы Подсистема формирования отчётов Пример структурной схемы программной системы Комплекс математических программ Программы решения системы уравнений Программы определения корней уравнения Программы вычисления определённого интеграла Ввод Вывод Ввод Вывод данны результа данны результа х тов х тов Пример функциональной схемы комплекса программ Ввод данны х Вывод результа тов Система учёта успеваемости студентов Ввод данных Подсистема наполнения данных Вывод форм ввода Подсистема формирования отчётов База данных Ввод запроса Вывод отчётов 3 Функциональная схема программы системы. Использование метода пошаговой детализации для проектирования структуры ПО. Метод пошаговой детализации реализуется нисходящий подход и базируется на основных конструкциях структурного программирования. Он предполагает пошаговую разработку алгоритма. Каждый шаг включает разложение функций на подфункции. Процесс продолжается до тех пор пока не доходит до функций алгоритм решения которых очевидный. При декомпозиции программ методом пошаговой детализации необходимо придерживаться следующих рекомендаций: 1. не отделять операции инициализации и завершения от соответствующей обработки, т.к. модули инициализации имеют плохую связанность и сильное сцепление по управлению. 2. не проектировать слишком специализированных и слишком универсальных модулей. Проектирование слишком специализированных модулей увеличивает их количество, а проектирование универсальных модулей повышает их сложность 3. избегать дублирование действий в различных модулях. Целесообразнее выносить их в отдельные модули 4. группировать сообщения об ошибках в один модуль. Пример: разработать алгоритм программы построения графиков функций одной переменной на заданном интервале изменения аргумента от х1 до х2, при условии непрерывности функции на всём интервале определения. Разработку алгоритма будем выполнять методом пошаговой детализации и для записи алгоритма будем использовать псевдокод. Для этого принимаем, что программа будет взаимодействовать с юзером через традиционное иерархическое меню. Пункты этого меню: функция, отрезок, шаг, вид результата, выполнить и выпад. Для каждого пункта этого меню необходимо реализовать сценарий предусмотренный в ТЗ. Определение спецификаций ПО при объектном подходе Модели разрабатываемого ПО при объектном подходе основаны на предметах и явлениях реального мира, поэтому на этапе анализов ставится 2 задачи: 1. уточнить требуемое поведение разрабатываемого ПО. 2. разработать концептуальную модель его предметной области, с точки зрения поставленной задачи. В основе объектного подхода лежит объектная декомпозиция, т.е. представление разрабатываемого ПО виде совокупности объектов в процессе взаимодействия которых через передачу сообщений и происходит выполнение требуемых функций. Например, объектная декомпозиция построения объектов и графиков: Управление Вычислить Создать Таблица Уничтожить Изобразить Изобразить Функция График Вычислить Для проектирования объектного подхода используется язык UML (unifaded model///) который является унифицированный языком моделирования, который в настоящее время признан стандартным средством описания проектов, создаваемая с использованием объектно-ориентированного программирования. Спецификация разрабатываемого ПО при использовании UML, Объединяет в себе 5 моделей: 1. модель использования – представляет собой описание функциональности ПО с точки зрения пользователя. 2. логическая модель – описывает ключевые абстракции ПО (классы, интерфейсы и т.д.), т.е средства обеспечивающие требуемую функциональность. 3. модель реализации – эта модель определяет реальную…… организацию в среде разработки. 4. модель процесса – эта модель отображает организацию вычислений и позволяет оценить производительность, масштабируемость и надёжность ПО 5. модель развёртывания – она показывает особенности размещения программных компонентов на …….. уровне Все эти модели характеризуют определённый аспект проектируемой системы и все вместе они представляют полную модель разрабатываемого ПО. Для построения этих моделей используется 9 диаграмм, которые описываются языком UML: 1. Диаграмма вариантов использования 2. Диаграмма классов 3. Диаграмма пакетов 4. Диаграмма последовательности действий 5. Диаграмма коопераций 6. 7. 8. 9. Диаграмма деятельностей Диаграмма состояния объектов Диаграмма компонентов Диаграмма размещения Кроме этого спецификация так же как и при структурном подходе должна включать словарь терминов, различного рода описания и текстовые спецификации. Конкретный набор документаций определяется разработчиком. Определение вариантов использования Представляет собой характерную процедуру применения разрабатываемой системы, конкретным действующим лицом, в качестве которого могут выступать как люди, так и другие системы и устройства. Каждый вариант использования связан с некоторой целью имеющий самостоятельное значение. В зависимости от цели выполнения конкретной процедуры, различают следующие варианты использования: 1. Основные – они обеспечивают требуемую функциональность разрабатываемого ПО. 2. Вспомогательные – они обеспечивают выполнение необходимых настроек системы и её обслуживание. 3. Дополнительные – они обеспечивают дополнительные удобства для пользователя (они реализуются только в том случае если на них не треб серьезных затрат на разработку и эксплуатацию). Варианты использования можно описывать кратко или подробно. Краткая форма описания содержит название варианта использования, его цель, тип варианта использования и его краткое описание. Например, решение типовой задачи: Название варианта Выполнение задания Цель Получение результата решения задачи Действующие лица Пользователь, Краткое описание Решение задачи предполагает выбор задачи, выбор алгоритма, задание данных и получение результатов решений Тип варианта Основной Основные варианты использования обычно описывают подробно. Подробная форма, кроме этой информации включает описание типичного хода событий и возможных альтернатив. Типичный ход событий представляют в виде диалога между юзерами и системой, события при этом последовательно нумеруются. Если пользователь может описывать варианты, то их описывают в отдельных таблицах. Так же отдельно описываются альтернативы связанные с нарушением типичного хода событий. Пример, подробное описание варианта использования «Выполнения задания». Типичный ход событий Действия исполнителя Отклик системы 1. Пользователь инициирует новое задание 2. Система регистрирует новое задание и предлагает список типов задач. 3. Пользователь выбирает тип задачи 4. Система регистрирует тип задачи и предлагает список способа задания данных 5. Пользователь выбирает способ задания 6. Система регистрирует данные и данных: предлагает список решения а) если выбран ввод с Клавы, смотри раздел ввод данных б) если выбран ввод из БД, смотри раздел выбор данных из базы 7. Пользователь выбирает алгоритм 9. Пользователь инициирует процесс решения 11. Пользователь ожидает 13. Юзер анализирует результаты и выбирает сохранить их в базе или нет 8. Система регистрирует алгоритм и предлагает начать решение 10. Система выполняет полноту определения задания и запускает подпрограмму решения задачи 12. Система демонстрирует юзеру результаты и предлагает сохранить их в БД 14. Если выбрано сохранение данных, то система выполняет запись данных задания в базу 15 Система переходит в состояние ожидания Альтернатива: 11. Если время выполнения программы с точки зрения пользователя велико, то он прерывает процесс выполнения 12. Система прерывает расчёты предлагает список алгоритмов решения и возвращается на шаг № 7. Доп инфа 1. Необходимо обеспечивает произвольный выбор типа задачи 2. Необходимо обеспечить возможность выхода из варианта на люб этапе Раздел: Ввод данных Типичный ввод данных Действие исполнителя 1. Юзер выбрал ввод данных 3. Юзер вводит данные 5. Пользователь отвечает на запрос Отклик системы 2. Система последовательно запрашивает все данные 4. Система проверяет данные и запрашивает сохранять их в базе или нет 6. Если данные нужно сохранять, то система выполняет запись данных в базу и регистрирует их в текущем задании Альтернатива 4. Если обнаружены не корректные данные, то система выдаёт сообщение об ошибке и предлагает их исправить возвращаясь на предыдущий шаг. Раздел «Выбор данных из базы» Типичный ход событий Действие исполнителя 1. Пользователь выбрал выбор данных из базы 3. Пользователь выбирает данные Диаграмма вариантов использования Отклик системы 2. Система демонстрирует список данных в базе 4. Система читает данные и регистрирует их в текущем задании Диаграмма вариантов использования позволяет наглядно представлять ожидаемое поведение системы. Основными понятиями диаграммы являются: действующее лицо, вариант использования и связь. Действующее лицо – сущность, которая взаимодействует с ПО с целью получения и представления какой либо информации. Действ лицами мю юзеры, другое ПО, какие либо технические средства. Обозначается человечком. Вариант использования – это некоторая очевидная для действующего лица процедура, решающее его конкретную задачу. Обозначается овалом. Связь – взаимодействие действующих лиц и соответствующих вариантов использования. Обозначается линией. Бывают 2х видов: использования и расширения Использования – она подразумевает, что существует фрагмент поведения, который повторяется в нескольких вариантах использования. Этот фрагмент выполняют как отдельный вариант и указывают с ним связь типа «использования». Расширение – это когда имеется 2 подобных варианта использования, которые отличаются только некоторым набором дополнительных действий, В этом случае дополнительные действие определяют как отдельный вариант использования и определяет с ним связь тип «расширение» Пример, диаграмма вариантов использования длял систем решения задач Выполнение задания Расширение Чтение данных из базы Юзер Просмотр результатов Удаление данных из базы Расширение Сохранение результатов в базе Ввод данных Расширение Удаление результатов из базы Сохранение данных в базе Диаграммы классов Диаграммы классов являются центральным звеном ООР методов разработки ПО. UML предлагает использовать 3 уровня диаграмм классов в зависимости от степени и детализации: 1. Концептуальный – на этом уровне диаграммы классов демонстрируют связи между основными понятиями предметной области 2. Уровень спецификаций – в этом случае диаграммы классов отображают интерфейсы классов объектной области и связи объектов этих классов. 3. Уровень реализации - Диаграммы классов непосредственно показывают поля и операции конкретный классов Каждую модель используют на конкретном этапе разработки ПО. Концептуальную на этапе анализов, диаграммы классов уровней спецификаций на этапе проектирования, и диаграммы уровня реализации на этапе реализации. Каждой модели класс понимает как совокупность общих признаков заданной группы объектов предметной области. Класс отображается в виде прямоугольника в котором указывается имя класса и атрибуты. В качестве атрибутов представляют существенные характеристики объектов. Для конкретного объекта атрибут всегда имеет определённое значение. Между классами определяются отношения. Под отношениями классов понимают статическую, т.е. независящую от времени связь между классами. Различают 2 вида отношений: ассоциация и обобщение. Отношение ассоциации означает наличие связи между экземплярами класса и объектами. Например, класс студенты, ассоциирован с классом институт. Ассоциация может иметь имя, например, обучается: в институте обучается студент. Связь между экземплярами класса подразумевает некоторые роли. Роль связана с направлением ассоциации. У каждой роли есть имя, например, институт носит роль - место обучения, студент – обучающийся. Кроме этого роль обладает характеристикой множественности, которая показывает сколько объектов может участвовать в одной связи с каждой стороны. Множественно определяется след знаками: * - от0 до бесконечности, N….*; N; N1, N2…. Обобщение – отношение между классами, при котором любой объект одного класса (подтипа) обязательно является объектом другого класса (супертипа). Определение основных понятий предметной области, которые должны представляться на конкретной диаграмме в виде классов делят на 2 части: 1. сначала формируют множество понятий характеризующих предметную область в описании вариантов использования 2. исключают понятия, не существенные для данного варианта использования. Пример, построение контекстной диаграммы классов, для решения системы задач. 1. Определяем основные понятия и связываем их между собой. Целью задания является это выполнение задания. Полное описание задания включает в себя: тип задачи, данные и указание на алгоритм и результаты. Данные могут сохраняться в базе и по лицам, описание задания и всё, что с ним связано может сохраняться в базе. Хранит 1 База данных 1 * Хранит * Данные * 1 1 Включае т Использует Задание Тип задачи 1 1 1 Алгоритм Точность Алгоритм 1 Алгоритм 2 1 1 Результаты Включае т Производи т 1 Алгоритм 3 * Диаграмма последовательности систем Это графическая модель, которая для определения сценария варианта использования показывает генерирует действующими лицами события и их порядок, при этом система рассматривается как единая целая. Для построения диаграмм последовательности необходимо представить систему как чёрный ящик и изобразить для неё линию жизни это вертикальная пунктирная линия, идентифицировать каждое действующее лицо и тоже изобразить для него линию жизни. Из описания варианта использования определить множество системных событий и их последовательности. Изобразить системные события в виде линий со стрелками на конце между линиями жизни действующих лиц и системы, а так же списки передаваемых значений. События которые генерируются для системы с действующими лицами называется системными. Они инициируют выражение множества операций, которые называются системными операциями. Каждую системную операцию называют по имени соответствующего операции. Каждую системную операцию необходимо описать: описание должно содержать имя операции и её параметры, описание обязанности, указание типа, название вариантов использования в которых она используется, примечания для разработчиков алгоритмов, описание обработки возможных исключений, описание вывода сообщений, предложение о состоянии системы до выполнения операций описания изменений состояния системы после выражения. Пример: Диаграмма последовательности системы для вариантов использования задачи решения системы задачи System Юзер Сформировать новое задание Определить тип задачи Определить способ задания данных Ввести данные (данные) Выбрать данные из базы Определить тип алгоритма (тип алгоритма) инициировать решение Сохранить задание Загрузить задание После этого каждую операцию необходимо описать: для примера Раздел Описание Имя описания Инициирует решение Обязанности Выполнить задание, вывести результаты юзеру Описание системы Ссылки Вариант использования, выполнить задание Примечание Предусмотреть возможность прерывать процесс решения Исключения Вывод Предусловие Постусловие пользователю 1. Если в задании указаны не все исходные данные, то вывести сообщение об ошибке. 2. Если при указанных исходных данных решение задачи указанным методом не возможно, то вывести сообщение об ошибке ----------------Предполагает наличие всех исходных данных задания Получен результат Диаграмма деятельности Так же как и диаграмма классов используют на разных этапах разработки. Под деятельностью понимают задачу (операцию) которую необходимо выполнить вручную или с помощью средств автоматизации. Диаграмма деятельности является обобщённым представлением алгоритма, реализующий анализируемый вариант использования. Деятельность обозначается прямоугольником с закруглёнными краями с названием деятельности. Ромб – вывод. Линии – синхронизации. Чёрный кружок закрашенный – начало, чёрный круг с точкой внутри – конец. Название деятельность деятельности Выбор Линии синхронизации Начало Конец Для выбора это альтернативный процесс, с указанием выходов да и нет, можно строить циклический процесс указав звёздочку. ДА Нет * Пример: Диаграмма деятельности, уточняющей вариант использования «решения задачи» системы задач: Создание объекта задания Ввод типа задачи Нет Данные ввести Выбор данных из базы Да Ввод данных Выбор алгоритма решения Решение задачи Нет Результаты сохранить Уничтожение объектов задания Да Сохранение результатов Проектирование ПО при объектном подходе Основной задачей логического проектирования при объектном подходе является разработка классов для реализации объектов полученных при объектной декомпозиции. Эта задача включает полное описание полей и методов каждого класса. Физическое проектирование при объектном подходе включает объединение классов и других ресурсов программных компонентов и размещение этих компонентов на конкретных устройствах. Разработка структуры ПО при объектном подходе Все классы можно отнести к определённому типу. Существует 4 типа классов: 1. Классы сущности. Они используются для представления сущности реального мира или внутренних элементов системы. Они не зависят от окружения и их используют в различных приложениях. Класс сущности обозначают на диаграммах 2. 3. Граничные классы (интерфейсные) они осуществляют взаимодействия между действующими лицами и внутренними элементами системы. К этому типу относят классы реализующие пользовательские интерфейсы и классы обеспеч интерф с аппаратными классами Управляющие классы. Служат для моделирования последовательного поведения заложенного в один или несколько вариантов использования Если количество классов велико, то их объединяют в пакеты. Пакеты при объектном подходе называют совокупность описания классов единого назначения. На основе пакетов составляют диаграмму пакетов, которая показывает из скольких частей состоит проектируемая система и как эти части связаны друг с другом. Название Названи е Содержание Название Global Глобальный – пакет, с которыми связаны все пакеты разработанной системы Пример: Разработать диаграмму пакетов: решение системы задач. Пользовательски й интерфейс Библиотека интерфейсных элементов БД Объекты управления Объекты задачи Интерфейс с БД Базовые структуры Global данных Обработка ошибок Global Определение отношений между объектами После определения основных пакетов разрабатываемого ПО, переходят к детальному проектированию классов входящих в каждый пакет. Пример, определение классов для пакета объекта задачи. Для того что бы определить какие классы должны входить в пакет нужно выполнить анализ предметной области, анализ описания варианта использования (решения задачи) и его диаграммы деятельности. В результате этого анализа получаем следующий список классов: 1. Класс задания. Объекты этого класса должны создаваться каждый раз, когда инициируется новое задание. 2. Класс алгоритм. Объекты этого класса определяют алгоритм решения задачи. 3. Данные. Объекты этого класса определяются при вводе или выводе из БД. 4. Класс результата. Объекты этого класса создаются при решении конкретной задачи, конкретным алгоритмом и с использованием конкретных данных. Диаграмма пакета данных для объекта задачи Задание Данные 1 1 включает Тип задачи 1 1 включает Результат * * Алгоритм 1 использует Алгоритм 1 Точность Алгоритм 2 1 производит Алгоритм 3 Основой для проектирования классов является уточнение взаимодействия объектов этих классов в процессе реализации вариантов использования. Для этого применяют диаграммы последовательности, которые отображают взаимодействие объектов упорядоченное во времени. На ней отображают внутренние объекты и последовательность сообщений, которые обмениваются объекты в процессе реализации. Всё это называют сценарием использования. Все объекты отображаются вслед образом Имя объекта Имя объекта: имя класса : Имя класса Условные обозначения передачи управления между классами: 1. сообщение Имя 2. Создание объекта Имя 3. Активизация объекта 4. Уничтожение объекта 5. Прерывание объекта Пример: диаграмма последовательности для сценария решения задач необходимо решить 3 варианта последовательности действий: 1)нормальный процесс 2)прерывание последовательности пользователем 3)возникновение искажения Предполагается, что при команде «создать» создаётся объект решения управлений. Следующее сообщение «начать» активирует этот объект. Объект решения запрашивает у объекта класса «задание»- тип объекта «алгоритм» создать объект требуемого класса и активирует его, при этом может получать и обрабатывать сообщения. Объект классов «алгоритм» запрашивает у объекта класса «задание данных» и начинает обработку. Нормально завершив обработку объект класса «алгоритм» передаёт объекту класса «задание» результаты и возвращает объекту «решение» признак нормального завершения. Объект «решение» уничтожает объект класса «алгоритм» и возвращает вызвавшему ему объекту признак нормального завершения. Диаграмма последовательности действий сценария «процесс решения» при нормальном процессе. Решение : Задание Сообщить тип алгоритма (тип) начать Создать : Алгоритм Сообщить данные (Data) выполнить Записать результаты (Result) норм. завершение Уничтожит ь норм. завершение Решение : Задание Сообщить тип алгоритма (тип) начать Создать : Алгоритм Сообщить данные (Data) выполнить завершить прервать выполнение прервано выполнение прервано Уничтожить Проектирование классов Проектирование классов предполагает окончательное определение структуры. Определение структуры и поведения. Структура объектов определяется совокупностью атрибутов и операции классов. Каждый атрибут – это поле или совокупность полей данных содержащихся в объекте класса. Поведение объектов класса определяется реализуемыми обязанностями. Обязанности выполняются через операции класса. Таким образом при проектировании класса, кроме имени и полного списка атрибутов необходимо уточнить его ответственность и операции. В зависимости от степени детализации диаграммы классов обозначения атрибутов может включать: имя, тип, описание видимости и значения по умолчанию. Для этого используется следующий формат: <признак видимости> <имя> : <тип> = <значение по умолчанию>. Признак видимости может принимать одно из 3х значений: +общий, -скрытый, # защищённый Операциями называют основные действия реализуемые классами. В отличие от методов операция не всегда реализуется непосредственно классами. Например, операция ввод числа может быть реализована не классом, а интерфейсным элементов «окно ввода». Описание операции на диаграмме класса имеет следующий вид: <признак видимости> <имя> (<список параметров>) : <тип возвращаемого значения>. Исходный список операции класса формируют на основе анализа диаграммы деятельности, диаграммы взаимодействия и диаграммы последовательности действий. Построенные для различных сценариев с участием объекта проектируемого класса. Если объекты проектируемого класса должны реализовывать сложное поведение, для них разрабатывают диаграмму состояния. Под состоянием объекта применительно к диаграмме состояния понимают ситуацию в жизненном цикле объекта, во время которой он осуществляет определённую деятельность или ожидает некоторого события. Изменение состояния называют переходом. Таким образом диаграммы состояния показывают состояние объекта, возможные переходы, а так же события или сообщения вызывающий каждый переход. Условное обозначение состояния: закрашенная точка – начальное состояние, кружок внутри точка – конечное состояние, промежуточное состояние Название состояния Вход: Выполнить: Выход: Действие Деятельность Действие Переход обозначается линией со стрелкой, он может быть помечен меткой состоящей из 3х частей, каждую из которых можно опустить: <Событие>/<Условие>/<Действие>. Событие. Если событие не указано, то это означает, что переход выполняется по завершению деятельности связанный с данным состоянием, если указано, то при наступлении события. Условие – логическое выражение определяет переходы в 2 различных состояния. Действия – задаются действия для перехода, которые являются мгновенными и не прерываемыми. Пример диаграммы состояния для объекта класса «решение»: Процесс Прерывание Инициализация Вход: Алгоритм. Создать Выполнить: Инициализация переменных Вход: Алгоритм. Прервать Выполнить: Алгоритм. Уничтожить Выход: Фиксировать прерывание Алгоритм выполнить Ожидание Исключение Аварийное завершение Нормальное завершение Выполнить: Алгоритм. Уничтожить Выход: Фиксировать нормальное завершение Вход: Выдать сообщение Выполнить: Алгоритм. Уничтожить Выход: Фиксировать завершение с ошибкой Диаграммы состояний строятся на основе анализа соответствующей диаграммы последовательности действий. Итогом является уточнение атрибутов и операций классов: решение, задание, алгоритм, данные, результат. Для полного обозначения классов используется следующее обозначение Имя класса Атрибуты Операции Класс задания. Объект класса задания должен хранить идентификатор задачи и тип алгоритма. Соответственно он должен иметь соответствующие поля и включать следующие операции: определить задачу, определить алгоритм, сообщить тип задачи, сообщить тип алгоритма. Кроме этого объект класса «задание» отвечает за объект класса «данные результата» связанные с ним. Следовательно он должен хранить их адреса и выполнять следующие операции: определить данные, сообщить данные, фиксировать результаты, сообщить результаты. Классы «данные», «результаты». Данные задач и их результаты должны храниться в БД, но они имеют различную структуру. Эту проблему можно решить, если хранить в упакованном виде и распаковывать по мере необходимости. Из этого следует, что соответствующие классы должны иметь операции упаковать и распаковать. Кроме этого классы данные и результаты должны хранить тип задачи с которой они связаны и содержать операции: определить тип задачи и сообщить тип задачи. Класс «алгоритм». Объекты класса «алгоритм» отвечают за реализацию метода решения задачи. Поскольку они посылают сообщения объектам класса задания, то должны хранить его адрес. Кроме этого класс «алгоритм» должен объявлять операцию «выполнить». Класс «решение». Объект класса решение обращается к классу алгоритм, соответственно необходимо иметь их адреса. Операции начать, прервать, обработать исключения вытекают из диаграмм последовательности действия. Таким образом результат уточнения атрибутов и операции классов имеет следующий вид: Данные задачи 1 Данные +Тип задачи +Упаковать +Распаковать +Определить тип задачи +Сообщить тип задачи Данные задачи 2 1 1 1 1 Данные Данные задачи 3 Задание +Тип задачи +Тип алгоритма +Данные1:Данные +Результаты1: результаты +Сообщить тип задачи +Сообщить тип алгоритма +Сообщить данные +Фиксировать результаты +Определить задачу +Определить алгоритм +Определить данные +Сообщить результаты 1 Результаты +Тип задачи +Упаковать +Распаковать +Определить тип задачи +Сообщить тип задачи Алгоритм 1 -Задание1:Задание -Алгоритм1:Алгоритм +Начать +Прервать +Обработать исключения 1 -Точность -Задание1: Задание +Выполнить 1 Алг1 Алг2 Алг3 Полностью спроектированные классы реализуются на конкретном языке программирования. Разработка пользовательских интерфейсов Пользовательский интерфейс представляет собой совокупность программных и аппаратных средств обеспечивающих взаимодействие пользователя с компьютером. Основу взаимодействия составляют диалоги. Под диалогом понимают регламентированный обмен информации, осуществляемым в реальным масштабном времени и направленный на совместное решение конкретной задачи: обмен информацией и координация действий. Обмен информацией осуществляется передачей сообщений и управляющих сигналов. Сообщения – порция информации. Их разделяют на 2 группы: 1. входные сообщения - они генерируются человеком с помощью клавиатуры, планшетов, сканеров, с помощью светового перо и сенсорного экрана 2. выходные сообщения – используются мониторы, принтеры, графопостроители, синтезаторы речи и звукогенераторы. Типы интерфейсов Различают процедурно-ориентированный и объектно-ориентированный подход к разработки интерфейса. Процедурно-ориентированные используют традиционные модели взаимодействия с пользователем, основанные на понятии процедура и операция. В этой модели ПО предоставляет пользователю выполнение некоторых действий, для которых пользователь определяет данные и следствием выполнения которых является желаемый результат. Объектно-ориентированные интерфейсы – управляют объектами предметной области. В этой модели пользователь напрямую взаимодействует с каждым объектом и инициирует выполнение операции в процессе которых могут взаимодействовать несколько объектов, т.е. пользователь может создавать объекты, изменять их параметры и связи между ними, и инициировать взаимодействие между ними. Процедурно-ориентированные интерфейсы делят на 3 типа: примитивный, меню, со свободной навигацией. 1. Примитивным называют интерфейс который организует взаимодействие с юзером в консоле. Обычно этот интерфейс организует конкретный сценарий работы ПО, например, ввод данных, решение, вывод результатов. 2. Меню – этот интерфейс позволяет пользователю выбирать необходимые операции из необходимого списка. Последовательность действий в данном интерфейсе определяется пользователем. 3. Со свободной навигацией (графические пользовательские интерфейсы). Интерфейсы данного типа ориентированы для использования в графическом режиме и поддерживают концепцию интерактивного взаимодействия с ПО осуществляя обратную связь с пользователем. При Этом они поддерживают концепцию программ, позволяя изменять информацию между разным ПО. ОН может изменяться в процессе взаимодействия с пользователем, предлагая выбор только тех операций, которые имеют смысл в конкретной ситуацию. Пример: разработать юзерский интерфейс построения графикой или вывода таблицы функций по данному ТЗ. Примеры на листочках (в Эл виде) Этапы разработки пользовательского интерфейса включают те же этапы что и разработка ПО: 1.постановка задачи – определяется тип интерфейса и общие требования к нему 2.анализ требований и определение спецификации – определение сценариев использования и пользовательской модели интерфейса 3.проектирование – включает в себя проектирование диалогов и реализацию в виде процессов ввода и вывода. 4.реализация – включает программирование и тестирование интерфейсных процессов. При проектировании пользовательских интерфейсов, необходимо учитывать психофизические особенности человека связанные с восприятием, запоминанием и обработкой информации. В каждый момент времени фокус внимания может фиксироваться в одной точке, поэтому необходимо плавно отслеживать элементы при переходе с одного на другой. Обработка любого процесса восприятия требует некоторого времени и если сигнал выдаётся в течении времени меньшим времени обработки то человеческий мозг его не воспринимает, поэтому для любого действия нужно выделять определённое время. Так же в процессе обработки информации мозг сравнивает поступающие данные с предыдущими, поэтому при смене кадра мозг на некоторое время блокируется. Поэтому если необходима быстрая реакция пользователя то резкая смена картинки не рекомендуется. Краткосрочная память это самая узкое место в системе обработки информации человека. Её ёмкость 7+2 не связанных объекта. Невостребованная информация хранится не более 30 секунд. Если необходимо ввести или запомнить число или группу символов, то количество не должно превышать 7 + 2. Особенности восприятия цвета Цвет в сознании человека ассоциируется в сознании фона. Цвет является сильным раздражителем, поэтому применять цвета в интерфейсе следует осторожно, поэтому следует помнить что обилие оттенков привлекает внимание, но быстро утомляет. Интерфейс рекомендуют делать в единой цветовой гамме и учитывать индивидуальные особенности восприятия цветов человека, для этого по возможности предоставить пользователю возможность настройки цветов. Особенности восприятия звука Звук в интерфейсе используют для привлечения внимания, как фон, и как источник дополнительной информации. Обязательно предусмотреть отключение звука. Субъективное восприятие времени. Считают что внутреннее время связано со скоростью и количеством воспринимаемой и обрабатываемой информации. Доказано что при ожидании более 1-2 секунд пользователь может отвлечься и потерять мысль, поэтому для сокращения времени ожидания пользователя необходимо занять, но не отвлекая его от работы, например, предоставить пользователю информацию для обдумывания (предоставить промежуточные результаты). Для уменьшения возникновения раздражения необходимо: информировать пользователя о том что заказанные им операции потребуют некоторого выполнения. Пользовательские и программные модели интерфейса Существует 3 модели интерфейса: 1. модель программиста 2. модель пользователя 3. программная модель Программист исходит из того как осуществить не затрачивая существенные ресурсы компьютера, свои силы и время. Е го интересует функциональность, эффективность и технологичность, которые не связаны с удобством пользователя характеристики ПО. Пользовательская модель интерфейса - совокупная обобщённых представлений пользователей о процессах происходящих во время выполнения программы. Эта модель базируется на основе опыта конкретных пользователей, которые характеризуются: 1.уровнем подготовки пользователя в предметной области разрабатываемого ПО 2.уровнем подготовки владения компьютера 3.моделями выполнения операции в данной предметной области 4.устоявшимися стереотипами работы Что бы определить пользовательскую модель интерфейса нужно изучить особенности кот перечислили, для этого проводят опросы, тесты и фиксируют последовательность действий осуществляемых в процессе выполнения операции. Изменять пользовательскую модель очень сложно, поэтому рекомендуют уточнять её и совершенствовать. Критерии оценки интерфейса пользователя: Основным критерием оценки интерфейса пользователя является 1. простота освоения и запоминания системы 2. Скорость достижения результатов при использовании системы 3. субъективная удовлетворённость при эксплуатации системы Классификация диалогов и общие принципы их разработки. Различают в диалогах тип диалога и его форму. Тип диалога определяет кто управляет процессом обмена информации, существуют 2 типа: 1. управляемый программой 2. управляемый пользователем Диалог управляемый программой предусматривает наличие жёсткого линейного или древовидного сценария (когда есть альтернативные варианты) диалога заложенного в ПО. Такой тип диалога как правило содержит большое количество подсказок которое уточняет действия на каждом шаге Управляемый пользователем – в этом случае сценарий диалога зависит от пользователя, который применяет систему для выполнения необходимой операции на данный момент. Формы диалога язык определяет синтаксис – правила, допустимые конструкции языка и его форм и семантики – правила определяющие смысл корректных конструкций языка или его содержаний. В зависимости от синтаксиса и семантики различают 3 формы диалога: 1. Фразовый диалог 2. Директивная 3. Табличная Фразовый диалог предполагает общение пользователя на естественном языке. Содержание диалога в этой форме составляют повелительные, повествовательные и вопросительные предложения и ответы на вопрос. Директивная предполагает использование команд (директив) специально разработанного формального языка. Командой называют предложение этого языка описывающего некоторые комбинированные данные, команды можно вводить в виде строки текста, нажатием клавиш и мышкой. Табличная форма. Она позволяет выбирать пользователю ответ из предложенных вариантов. Её не всегда можно использовать, только при определённом количестве ответов. Если количество ответов велико (более 20), то нужно отказаться от табличных форм. Типы и формы диалога выбирают независимо друг от друга, любая форма применима для обоих типов диалогов Сложное ПО использует диалоги различных типов и форм в зависимости от решаемых задач. Процесс проектирования и реализации диалогов состоит из следующих частей: 1. определение множества необходимых диалогов их основных сообщений и возможных сценариев. Проектирование абстрактных диалогов 2. определение типа и формы каждого диалога, синтаксиса и семантики используемых языков. Проектирование конкретных диалогов 3. Выбор основных и дополнительных устройств и проектирование процессов ввода, ввода для каждого диалога. Проектирование технических диалогов. Основные компоненты графических пользовательских интерфейсов. Современные графические ин WIMP (window icon mouse popup) 1. Окна – все виды делятся на 5 категорий: a. Основное окно – рамка, основное меню b. Дочернее или подчинённые окна c. Диалоговое окно пункт меню/масштаб d. Информационные окна (окно сообщений и окно помощи) e. Окна меню 2. Пиктограммы бывают программные , дочерние пиктограммы которые связаны с конкретным документом, пиктограмма панели инструментов – дублируют доступ к соответствующим пунктам через меню, пиктограмма объектов – используется для прямого управления объектами. 3. Мышь используется для прямого манипулирования изображения в интерфейсе. 4. Компонент вода/вывода. В окна приложения могут размещаться спец компоненты используемые для ввода/вывода информации. Интерфейс практически любого современного ПО включает меню: основное, иерархическое, пиктографическое и контекстное и меню представляет собой компонент ввода/вывода представляющего диалог с пользователем. Пример, разработать основное меню системы решения системы задач. Это стандартный вариант меню для данной системы Мен ю Файл Правка Проект Выполнить Создать Вырезать Создать проект Копировать Определить задачу Выполнить по шагам Вставить Создать данные Присоединит ь данные Открыть Изменить данные Открыть проект Сохранит ьСохранить Окна Каскад Мозаика Справка Содержан ие по программ е Определить алгоритм как Сохранит ь проект Закрыть Печать Выход Не стандартный вариант, основанный на интуитивной модели пользователя, т.е. концептуальной модели пользователя Меню Задание Данные Создать Создать Открыть Открыть Закрыть Закрыть Изменить данные Сохранит ь Сохранить как Связать с проектом Удалить Сохранит ь Сохранить как Удалить Удалить всё Печать Окна Выполнить Удалить всё Печать Выход Через экранную форму Тип задачи Задача 1 Данные Показать Алгоритм Алг 1 Выполнить Создать Время выполнения Открыть Прервать Показать результат Удалить Сохранить Сохранить как Выход Через закладки Задание Данные Тип задачи Данные Алгоритм Выполнить Сохранить Результаты Задача 1 С:\Файл Сохранить Открыть Алг 1 Время выполнения Сохранить как Удалить Прервать Выход Справка Тестирование программных продуктов Тестирование является важным и трудоёмким процессом разработки ПО. Существует 3 стадии тестирования: 1. Автономное 2. комплексное 3. системное Все эти стадии соответствуют завершению разработки ПО. Различают 2 подхода к формированию тестов: структурный и функциональный. Тестирование – процесс выполнения программы, целью которого является выявление ошибок. Процесс разработки ПО предполагает 3 стадии тестирования: автономное тестирование компонентов ПО, комплексное тестирование разрабатываемого ПО, системное (оценочное) тестирование на соответствие основным критериям качества. Основные принципы тестирования: 1. предполагаемые результаты должны быть известны до тестирования 2. не допускать к тестированию программы автора 3. необходимо досконально изучать результаты каждого теста 4. необходимо проверять действия программы на неверных данных 5. необходимо проверять программу на неожиданные побочные явления при неверных данных. Существует такое правило: вероятность наличия не обнаруженных ошибок в части программы пропорционально количеству ошибок уже найденных в этой части. Структурный подход. Базируется на том что известна структура тестируемого ПО и его алгоритма. (стеклянный ящик). При структурном подходе тесты строят, так что бы проверить правильность реализации заданной логики в коде программы. Ещё называют тестирование по маршрутам, т.к. тестовый набор формируется путём анализа маршрутов предусмотренных алгоритмом. Под маршрутом при этом понимают последовательность операторов программ, которые выполняются при конкретном варианте исходных данных. Структурное тестирование должно максимально полно проверить все маршруты программы. Считают что программа проверена полностью, если с помощью теста удаётся осуществить выполнение программы по всем возможным маршрутам передачи управления. Данный метод имеет ряд недостатков: 1. не обнаруживает пропущенных маршрутов 2. не обнаруживает ошибок не зависящих от обрабатываемых данных 3. не даёт гарантии, что программа правильная. Формирование тестовых наборов для тестирования маршрутов осуществляется по следующих критерием: 1. покрытие операторов – этот критерий подразумевает такой набор тестов, что бы каждый оператор программы выполнялся по крайней мере 1 раз. 2. покрытие решений (переходов). Для реализации этого критерия необходимо такое количество и состав теста, что бы результат проверки каждого условия (решения) принимал значение Истина или Ложь, тоже по крайней мере 1 раз. 3. 4. 5. покрытие условий – это критерий более сильный, чем первые 2. Формирует некоторое количество тестов, достаточное для того, что бы все возможные результаты каждого условия решения были выполнены, по крайней мере 1 раз. покрытие решений – условий. По этому критерию тесты должны составляться так что бы по крайней мере 1 раз выполнялись все возможные результаты каждого условия, и все результаты каждого решения. И каждому оператору управление передавалось по крайней мере 1 раз. Комбинаторное покрытие условия. Для этого критерия создаётся множество тестов в которых все возможные комбинации результатов условий в каждом решении и все операторы выполнялись по крайней мере 1 раз. Файл с критериями!!! Функциональный подход Функциональное тестирование Основывается на том, что структура ПО не известна (Чёрный ящик). Программа рассматривается как чёрный ящик, целью тестирования является выяснение обстоятельств в которых поведение программы не соответствует спецификации. Для обнаружения ошибок в программе необходимо выполнить исчерпывающее тестирование на всех возможных наборах данных. При функциональном тестировании существуют следующие методы формирования тестовых моделей: 1. эквивалентное разбиение. Область всех возможных наборов входных данных программы по каждому параметру разбивает на конечное число групп, их называют классы эквивалентности. Наборы данных такого класса объединяют по принципу обнаружения одних и тех же ошибок, т.е. если набор какого либо класса обнаруживает некоторую ошибку, то предполагается, что и все другие тесты этого класса эквивалентности тоже обнаружат эту ошибку и наоборот. Классы эквивалентности определяют выбирая ограничения установленные для каждого входного значения в ТЗ или при уточнении спецификации. Каждое ограничение разбивают на 2 или более групп 2. анализ граничных значений. Граничные значении – значения на границах классов эквивалентности входных значений или около них. В этих местах, на границах, всегда резко увеличивается возможность обнаружения ошибок. Существует насколько общих правил для применения этого метода. Если входное условие описывает область значений, то тесты строятся для границы области и строятся тесты с не правильными входными данными, для ситуация не значительного выхода за границу области, если входное условие удовлетворяет дискретному ряду значений, то формируются тесты для минимального и максимального значения и тесты для большего и меньшего значения, если существует ограничение для выходных значений, то необходимо тестировать и их. 3. анализ причины следственной связи. Он позволяет системно выбирать высоко результативные тесты. Этот метод используется методы алгебры логики: причины и следствия. Причина – отдельное входное условие или класс эквивалентности, следствие – это выходное условие или преобразование системы. Идея метода заключается в уточнении следственных связей, т.е. в отнесении всех следствий к их причинам. Данный метод даёт полезный побочный эффект: он позволяет обнаруживать неполноту или не однозначность исходных спецификаций. 4. предположение об ошибке. Этот метод основан на интуиции, его идея заключается в том, что бы перечислить в некотором списке возможные ошибки или ситуации в которых они могут появиться, а затем на основе этого списка составить тест. Этот метод требует перечислить те особые случаи, которые могут быть не учтены при проектировании. Пример!!!!!!!!! Хз какой(( Комплексное тестирование. Делится на восходящее и нисходящее. Восходящее тестирование – предполагает, что каждый модуль программы тестируется отдельно на соответствие имеющимся на него спецификациям. Дальше эти модули, которые протестировались – собираются в модули более высокой степени интеграции, и затем тоже тестируются, при этом проверяют межмодульные интерфейсы. Тестирование продолжают до тех пор, пока не будет собран весь программный продукт. Этот подход обеспечивает полностью автономное тестирование. Недостатки: ошибки в спецификации, алгоритмах и интерфейсах могут быть обнаружены только на завершающей стадии; для тестирования модули нижнего уровня необходимо разрабатывать специальное ПО, которое обеспечивает вызов этих модулей с необходимыми параметрами. Нисходящее тестирование напрямую связано с нисходящим проектированием и разработкой. Как только проектирование какого либо модуля заканчивается, его кодируют и передают на тестирование. Когда тестирование модуля завершено, к нему подключают следующие модули, которые непосредственно им вызываются и проводят их совместное тестирование и т.д. Недостаток: отсутствие автономного тестирования модулей. Достоинство: ранняя проверка основных решений и качественное многократное тестирование сопряжения модулей в контексте ПО. Комбинированный подход. Его применяют, когда модули верхних уровней тестируют нисходящим способом, а модули нижних уровней восходящим способом. Комбинированный подход позволяет начать тестирование интерфейса, а с другой обеспечивает качественное автономное тестирование модулей низших уровней. Задача специалистов по тестированию является максимальное обнаружение несоответствий тестируемого модуля и соответствий на него. Для решения этой задачи специалист формирует тесты как структурный, так и функциональный подход каждое отклонение от спецификации обязательно документируется путём заполнения специального протокола. Образец ПРОТОКОЛА!!!!! Критерием для завершения тестирования служит 1 из 3х вариантов: 1. определённое количество тестов полученных по методам анализа причинно следственных связей, анализа граничных значений и предположения об ошибке перестают предъявлять ошибки. 2. возможное количество ошибок (оценивается экспертно или по специальным методикам) достигает 93-95 %. 3. строят график зависимости количества обнаруженных ошибок от времени тестирования. недели недели Оценочное тестирование. После завершения комплексного тестирования всегда приступают к оценочному тестированию, целью которого является тестирование программ на соответствие основным требованиям. Оценочное тестирование называют тестирование системы в целом. И оно включает в себя следующие виды: 1. тестирование удобства использования 2. тестирование на предельных объёмах 3. тестирование на предельных нагрузках 4. тестирование удобства эксплуатации 5. тестирование защиты 6. тестирование производительности – определение пропускной способности при заданной конфигурации и нагрузки. 7. тестирование требований к памяти 8. тестирование конфигурации оборудования – тест на разном оборудовании 9. тестирование совместимости – приемлемость на разные версии 10. тестирование удобства установки 11. тестирование надёжности 12. тестирование восстановления 13. тестирование удобства обслуживания 14. тестирование документации Целью всех этих тестов является поиск не соответствия ТЗ. Считается, что только после выполнения всех видов тестировании программный продукт может быть представлен юзеру или к реализации Составление программной документации. На каждый программный продукт должна разрабатываться документация 2х типов: для юзеров и разработчиков. Отсутствие документации не допустимо Виды программных документов. К программным относятся документы содержащие сведения необходимые для разработки, сопровождения и эксплуатации ПО. Документирование ПО осуществляется в соответствии с единой системой программной документации (ГОСТ 19.ХХХ). ГОСТ 19.101-77 устанавливает виды программных документов для ПО различных типов. По этому стандарту: 1. спецификация, должна содержать перечень и краткое описание всех файлов ПО, в т.ч. файлов документации на него. Она является обязательной для программных систем, а так же их компонентов имеющих самостоятельное применение. 2. Код вида документа 12. Он должен содержать текст программы с необходимыми комментариями. 3. Описание программы. Код вида документа13. Содержит сведения о логической структуре и функционирования программы 4. Ведомость держателей подлинников. Код 05. Только для ПО со сложной архитектурой. Эта ведомость содержит список всех предприятий, в которых содержится подлинники программных документов. 5. Ведомость эксплуатационных документом. Код 20. ОН содержит перечень эксплуатационных документов на программу, к которому относятся документы с кодами 30, 31, 32, 33, 34, 35, 46. Необходимость доков со 2го по 6й определяется на этапе разработки ТЗ. 30 – формуляр. Он содержит основные характеристики ПО, комплектность и сведения об эксплуатации ПО. 31 – описание применения. Этот документ должен содержать сведения о назначении ПО, область применения, применяемых методов, классе решаемых задач, ограничения применения и минимальные конфигурации технических средств. 32 – руководство системного программиста. Оно должно содержать сведения для проверки обеспечения функционирования и настройки программы на условиях конкретного применения. 33 – руководство программиста. Содержит сведения для эксплуатации ПО. 34 – руководство оператора. Содержит сведения для обеспечения процедуры общения оператора с вычислительной системой в процессе выполнения ПО. 35 – описание языка. Должен содержать описание синтаксиса и семантики языка. 46 – руководства по техническому обслуживания. Сведения для применения тестовых и диагностических программ и обслуживания технических средств. 81 – пояснительная записка. Она должна содержать информацию о структуре и программных компонентах ПО, включая схему алгоритмов, их общее описание, а так же обоснование принятых технических и технико-экономических решений. Она составляется на стадии эскизного и технического проекта. Допускается объединять отдельные виды эксплуатационных документов, кроме формуляра и ведомости. Необходимость объединения указывается в ТЗ. Имя документа берут у одного из объединяемых документов. Например, в руководство юзера, входит руководство программиста и ещё кого то. Подробное содержание основных наиболее важных программных документов СМОТРИТЕ В РАСПЕЧАТКЕ!!!