- •Тема 1. Введение. Основы методологии проектирования информационных систем 5
- •Жизненный цикл программного обеспечения
- •Модели жизненного цикла программного обеспечения
- •Макетирование
- •Спиральная модель жизненного цикла
- •Компонентно-ориентированная модель
- •Тема 2. Структурный анализ и проектирование Определение структурного анализа
- •Средства структурного анализа
- •Моделирование потоков данных
- •Контекстная диаграмма
- •Построение иерархии диаграмм потоков данных
- •Методология функционально стоимостного анализа
- •Методология функционального моделирования sadt (Structured Analysis and Design Technique)
- •Состав функциональной модели sadt
- •Иерархия диаграмм
- •Словарь данных
- •Тема 3. Построение информационной модели системы. Проектирование баз данных Диаграммы сущность-связь (erd)
- •Сущности, отношения и связи в нотации Чена
- •Типы связей в нотации Чена
- •Ассоциативная связь
- •Диаграммы атрибутов в классической модели Чена
- •Диаграмма категоризации
- •Нотация Баркера. Модель сущность- связь в нотации Баркера
- •Методология idef1x
- •Тема 4. Методика построения информационной модели данных (модели «сущность-связь»)
- •Идентификация отношений между сущностями
- •Разрешение неспецифических отношений
- •Использование средств и техники структурного системного анализа
- •Основные виды работ, рекомендуемые при построении логической и физической моделей программной системы
- •Подход Мартина (ie–методология)
- •Тема 5. Методология rad (Rapid Application Development)
- •Основные принципы методологии rad
- •Состав, структура и функциональные особенности case-средств
- •Поддержка графических моделей
- •Требования к современному диаграммеру
- •Тема 6. Структурное тестирование программного обеспечения Основные понятия и принципы тестирования программного обеспечения
- •Особенности тестирования белого ящика
- •Способ тестирования базового пути
- •Потоковый граф
- •Цикломатическая сложность
- •Шаги способа тестирования базового пути
- •Способы тестирования условий
- •Тестирование ветвей и операторов отношения
- •Способ тестирования потоков данных
- •Тестирование циклов
- •Тема 7. Функциональное тестирование программного обеспечения Особенности тестирования черного ящика
- •Способы разбиения на эквивалентности
- •Способ анализа граничных значений
- •Способ диаграмм причин–следствий
- •Тема 8. Организация процесса тестирования программного обеспечения
- •Методика тестирования программных систем
- •Тестирование элементов
- •Тестирование итераций
- •Восходящее тестирование интеграции
- •Тестирование правильности
- •Системное тестирование
Компонентно-ориентированная модель
Компонентно-ориентированная модель является развитием спиральной модели и тоже основывается на эволюционной стратегии конструирования. В этой модели конкретизируется содержание этапа конструирования. Оно отражает тот факт, что в современных условиях новая разработка должна основываться на повторном использовании существующих программных компонентов.
Рисунок 5 – Этапы конструирования компонентно-ориентированной модели
Программные компоненты, созданные в реализованных программных проектах, хранятся в библиотеке. В новом программном проекте, исходя из требований заказчика, выявляются кандидаты в компоненты. Далее проверяется наличие этих кандидатов в библиотеке. Если они найдены, то компоненты извлекаются из библиотеки и используются повторно. В противном случае создаются новые компоненты, которые применяются в проекте и включаются в библиотеку.
Достоинства компонентно-ориентированной модели:
уменьшает на 30% время разработки программного продукта;
уменьшает стоимость программной разработки до 70%;
увеличивает производительность разработки.
Вопросы для самоконтроля по теме 1:
Охарактеризуйте основные особенности современных крупных проектов.
Опишите основные этапы разработки программного обеспечения на основе классической модели жизненного цикла.
Опишите преимущества и недостатки спиральной модели жизненного цикла программного обеспечения.
Охарактеризуйте назначение макетирования.
Опишите назначение компонентно-ориентированной модели жизненного цикла программного обеспечения.
Тема 2. Структурный анализ и проектирование Определение структурного анализа
На этапе анализа требований к системе формализуются, документируются и уточняются требования заказчика. Именно на этом этапе закладывается успех всего проекта. Из-за неполноты и нечеткости требований разработка проекта может закончиться неудачей. Поэтому список требований к разрабатываемой системе должен включать:
совокупность условий, при которых будет эксплуатироваться программная система, в том числе аппаратных и программных ресурсов и требований квалификации сотрудников, которые будут работать с программной системой;
описание выполняемых системой функций;
ограничения на процессы разработки, к которым можно отнести сроки завершения работ и мероприятия по защите информации.
На этапе анализа определяется архитектура системы, ее функции, распределение функций между аппаратурой и программным обеспечением.
На этапе проектирования исследуется структура системы и взаимосвязи ее компонентов. Проектирование часто определяют как процесс получения логической модели системы. Этап проектирования обычно разделяется на два подэтапа:
проектирование структуры и проектирование интерфейса для отдельных компонентов программной системы, согласование функций и технических требований компонентов системы;
детальное проектирование, включающее разработку спецификаций для каждого компонента.
Особенностью разработки программного обеспечения является то, что наиболее сложные работы выполняются на начальных этапах жизненного цикла, то есть на этапах анализа и проектирования.
Последующие этапы имеют относительно невысокую сложность и трудоемкость.
Ошибки, допущенные на этапах анализа и проектирования, порождают на следующих этапах трудные, а иногда неразрешимые проблемы. Анализ требований к системе оказывает наиболее существенное влияние на все последующие этапы создания программного продукта и при этом является наименее изученным процессом. Если требования не были зафиксированы документально, то для участников проекта они остаются как бы несуществующими.
Язык, на котором формулируются требования к системе, должен быть достаточно простым и понятным как заказчику, так и разработчику, в данном случае системному аналитику. Системный аналитик должен уметь решать следующие задачи:
получение исчерпывающей информации для оценки требований к системе;
заказчик не может судить о том, какие его требования являются выполнимыми, а какие нет. Кроме того, системный аналитик получает от заказчика чрезмерное количество информации о предметной области. Поэтому системный аналитик должен уметь выбирать только существенную информацию;
спецификации системы, которые составляет аналитик, из-за технических терминов и значительного объема часто непонятны заказчику. Если спецификации системы не были поняты заказчиком, то они будут недостаточными для проектировщиков и программистов. Решение этой проблемы состоит в использовании структурных методов.
Наиболее популярным структурным методом является метод структурного анализа.
Метод структурного анализа состоит в том, что исследование предметной области начинается с общего обзора, а затем выполняется более детальное исследование, результаты которого приобретают иерархическую структуру.
Для метода структурного анализа характерно разбиение описания системы на уровне абстракции. Причем количество элементов на каждом уровне ограничено и обычно составляет от трех до девяти. На каждом уровне учитываются только существенные для данного уровня детали, определяется правило и формальное описание компонентов.
Методология структурного анализа базируется на ряде общих принципов. Эти принципы регламентируют организацию работ на начальных этапах жизненного цикла, а также используются для выработки рекомендаций по организации работ на последующих этапах. Перечислим основные принципы:
решение трудных задач выполняется путем их разбиения на множество меньших независимых задач;
каждая отдельная задача существенна для понимания всей системы в целом. Этот принцип называется также принципом иерархического упорядочивания и означает, что система может быть представлена по уровню, но каждый уровень должен добавлять в систему новые существенные детали.
Остальные принципы структурного анализа являются второстепенными, но также не должны игнорироваться разработчиками.
принцип абстрагирования заключается в выделении существенных аспектов системы, чтобы представить проблему в простом общем виде;
принцип формализации состоит в необходимости применения строгого методического подхода для решения всех задач;
принцип упрятывания заключается в том, что несущественная на конкретном этапе информация скрывается, то есть каждый компонент системы получает только ту информацию, которая ему необходима;
принцип концептуальной общности. На всех этапах жизненного цикла должна использоваться единая методология;
принцип полноты. Выполняется контроль на присутствие в системе лишних элементов;
принцип непротиворечивости состоит в проверке обоснованности использования и согласованности всех элементов системы;
принцип логической независимости состоит в том, что проектирование, выполняющееся на логическом уровне, не зависит от физического проектирования;
10) принцип независимости данных состоит в том, что модель данных должна быть спроектирована независимо от процессов их экологической обработки;
11) принцип структурирования данных означает, что данные в программной системе должны быть представлены в виде набора структур доступа;
12) принцип доступа конечного пользователя. Пользователь должен иметь непосредственный доступ к базе данных, чтобы он без программирования мог внести изменения в базу данных.
Соблюдение перечисленных принципов необходимо при организации работ на начальных этапах жизненного цикла независимо от типа разрабатываемой системы.
Использование принципов структурного анализа позволяет на более ранних стадиях разработки получить представления о создаваемой системе, обнаружить промахи и недоработки. Это облегчает работу на последующих этапах жизненного цикла и снижает стоимость разработки.