 |
Модель программного процесса?
|
|
|
|
Модель программного процесса — это упрощенное описание программного процесса, представленное с некоторой точки зрения. Модель задается в виде практических этапов, необходимых для создания ПО. В модели мы говорим, что и как мы будем делать. Т.е. какие процессы, с какой степенью конкретизации и в какой последовательности мы будем выполнять. Выбор модели процесса является первым шагом в создании ПО. Правильны выбор модели очень важен, т.к. во многом определяет успех проекта. Выбор тяжелых процессов может утопить проект, а слишком легкое отношение к процессам – к потере контроля над ходом выполнения.
В соответствии с двумя типами процессов – основных и дополнительных - можно говорить о двух типах моделей процесса: модели процесса разработки (модели жизненного цикла) и модели организации работ по выполнению разработки.
К первым типам моделей (модели жизненного цикла) относятся модели, в которых описывается порядок выполнения действий по созданию продукта. К наиболее известным моделям относятся:
• Водопадная (каскадная) модель – процесс разбивается но последовательное выполнение стадий; каждая стадия начинается после полного завершения предыдущей, продукт создается завершением последней стадии и должен полностью соответствовать изначально установленным требованиям.
• Спиральная (циклическая) модель – процесс также разбивается на стадии, но стадии выполняются циклическим повторением. На первом цикле создается прототип продукта, выполняющий часть требований. Дальнейшие циклы связаны с наращиванием прототипа до полного удовлетворения требований.
• Компонентная модель предполагает сборку продукта из заранее написанных частей – компонент. Основной упор делается на интеграцию и совместное тестирование компонент.
|
|
|
• Формальная модель основана на формальном описании требований с последующим преобразованием (трансляцией) требований в исходный код. Применение формальной модели гарантирует соответствие кода описанным требованиям.
Следует отметить, что различия между этими моделями существуют только в теории. На практике спиральная модель может быть дополнена элементами каскадной и компонентной. Задача программного инженера – подобрать правильную их комбинацию, ориентируясь только на конечный результат.
Ко второму типу моделей – моделей организации работ относятся:
• Модель потока работ (workflow model) — показывает последовательность действий, выполняемых людьми на различных этапах разработки ПО. Для каждого действия указываются входы, выходы (результаты) и связи по входам и выходам.
• Модель потоков данных (data flow model) — представляет процесс в виде последовательного преобразования данных. Каждое преобразование может выполняться одним или несколькими действиями.
• Ролевая модель — показывает роли людей, участвующих в программном процессе, а также действия и результаты, за которые они отвечают.
Методы программной инженерии?
Метод программной инженерии — это структурный подход к созданию ПО, который способствует производству высококачественного продукта эффективным в экономическом аспекте способом. В этом определении есть две основные составляющие: (а) создание высококачественного продукта и (б) экономически эффективным способом. Иными словами, метод – это то, что обеспечивает решение основной задачи программной инженерии: создание качественного продукта при заданных ресурсах времени, бюджета, оборудования, людей.
Начиная с 70-х годов создано достаточно много методов разработки ПО. Наиболее известны:
|
|
|
• Метод структурного анализа и проектирования Том ДеМарко (1978),
• Метод сущность-связь проектирования информационных систем Чен (1976)
• Метод объектно-ориентированного анализа Буч (1994), Рамбо (1991).
Метод программной индустрии основан на идее создания моделей ПО с поэтапным преобразованием этих моделей в программу – окончательную модель решаемой задачи. Так, на этапе спецификаций создается модель – описание требований, которая далее преобразуется в модель проекта ПО, проект – в программный код. При этом важно, чтобы модели метода представлялись графически с помощью некоторого языка представления моделей.
Методы должны включать в себя следующие компоненты:
• Описание моделей системы и нотация, используемая для описания этих моделей (например, объектные модели, конечно-автоматные модели и т.д.)
• Правила и ограничения, которые надо выполнять при разработке моделей (например, каждай объект должен иметь одинаковое имя)
• Рекомендации — эвристики, характеризующие хорошие приемы проектирования в данном методе (скажем, рекомендация о том, что ни у одного объекта не должно быть больше семи подобъектов)
• Руководство по применению метода — описание последовательности работ (действий), которые надо выполнить для построения моделей (все атрибуты должны быть задокументированы до определения операций, связанных с этим объектом)
Нет идеальных методов, все они применимы только для тех или иных случаев. Нет абсолютных методов – применяемые на практике методы могут включать элементы различных подходов. Выбор метода составляет задачу специалиста по программной инженерии.
Модель прецедентов (требований)
На слайде представлена модель прецедентов, или вариантов использования (Use case) в нотации языка UML (Unified Modeling Language), поддерживающего объектно-ориентированный анализ и проектирование ПО. Модель описывает (специфицирует) требования к программе регистрации курсов в ВУЗе.
На диаграмме представлены действующие лица (акторы) и действия (прецеденты), которые они выполняют:
· Студент регистрируется на курсе
· Преподаватель: выбирает курс для преподавания и запрашивает расписание курсов
Для каждого действия – прецедента дается его содержательное описание. Далее на основе этой модели строится путем поэтапного ее уточнения и преобразования будут строиться другие модели программы.
|
|
|
Модель классов
На слайде представлена одна из таких моделей – диаграмма классов. На диаграмме показаны основные классы программы: ВУЗ, факультет, Студент, Курс, Преподаватель. Приведены основные атрибуты и методы классов.
Кроме того, отмечены отношения (зависимости) между классами:
· Так отмечено, что ВУЗ состоит из Факультетов (агрегация), причем, один ВУЗ может состоять из одного или нескольких факультетов.
· Каждый преподаватель работает на факультете, но при этом, каждый преподаватель может работать на нескольких факультетах и на каждом факультете могут работать несколько преподавателей.
Модель сущность-связь
На слайде представлена модель сущность-связь для задачи автоматизации продаж товаров со склада. Представлены сущности, участвующие в процессе: Покупатель, Накладная, Список товаров, Склад, … Для каждой сущности представлены ее атрибуты – для покупателя это код покупателя, имя, адрес, банк. Выделены ключевые атрибуты, однозначно идентифицирующие экземпляры сущностей (у покупателя это код). Установлены связи между сущностями: Покупатель получает Накладную. Отмечены свойства связей: один покупатель может получать несколько накладных.
Далее эта модель преобразуется в реляционную модель базы данных для хранения информации о выделенных сущностях.
Представленная на слайде модель записана в нотации IE (Information Engineering). В других нотациях она будет выглядеть иначе.
Нотации модели
На слайде представлен фрагмент модели сущность-связь задачи учета сотрудников, записанный в различных нотациях: Чена (автор метода сущность-связь), Мартина (соавтор), стандарта IDEF1X (Information Modeling Method) и Баркера.
Что такое CASE?
CASE - Computer Aided System Engineering - различного рода инструментальные программы, используемые для поддержки процесса создания программ
CASE средства могут быть классифицированы по нескольким признакам:
|
|
|
• По уровню применения:
- Upper CASE -средства анализа требований
- Middle CASE - средства проектирования
- Low CASE - cсредства разработки приложений
• Специализированные
- Средства проектирования баз данных
- Средства реинжиниринга (восстановления) модели (формирование ERD на основе анализа схем БД или формирования диаграмм на основе анализа программных кодов)
• Вспомогательные
- Планирования и управления проектом
- Конфигурационного управления
- Тестирования
• Интегрированные CASE охватывают все этапы и процессы создания ПО от анализа требований до тестирования и выпуска документации. Интегрированные CASE выступают, как правило, в виде набора согласованных по интерфейсу средств, предназначенных для поддержки отдельных этапов процесса.
В настоящее время существует очень много CASE средств и фирм, специализирующихся на их разработке (Rational). При выборе CASE средств следует руководствоваться основным принципом: сначала метод создания ПО, а потом – CASE средства, применимые для этого метода. Выбор наоборот чреват нехорошими последствиями.
Computer Aided System Engineering - использование компьютеров для поддержки процесса создания программ.
Это широкий спектр программ – инструментальных средств, применяемых на разных этапах разработки ПО: спецификации требований, проектирования, кодирования, тестирования, документирования, …
|
|
|
