Отображение модели на язык программирования
позволяет осуществить прямое
проектирование – генерация кода на языке
программирования из модели UML. Также возможно
восстановить модель UML на основе существующей
реализации. Однако, обратное проектирование,
выполняемое инструментальными средствами,
все же требует определенного вмешательства
человека, так как некоторая информация
может теряться при переходе от модели
к коду. Комбинация этих двух путей – прямого
и обратного проектирования – обеспечивает
возможность работы как с графическим,
так и с текстовым представлениями; при
этом обеспечивается согласованность
между ними. В дополнение к прямому отображению
UML благодаря своей выразительности и
однозначности позволяет непосредственно
исполнять модели, имитируя поведение
проектируемых систем, а также управляя
действующими системами.
21. Язык UML. Элементы описания
класса на диаграмме классов
Диаграммы классов включает классы,
интерфейсы, объекты и кооперации, а также
их отношения. Не указываются временные
аспекты функционирования системы.
Структура класса:
- имя класса (уникальное);
- атрибуты;
- операции (методы);
- интерфейсы.
Отношения:
ВОПРОСЫ ПО ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ
1. Стадии проектирования программных
систем. Итерационное проектирование
Теоретический процесс разработки:
Реальный процесс разработки:
Постоянно приходится возвращаться на
предыдущие этапы и вносить изменения.
Основные принципы проектирования
больших программных систем
- этап проектирования не прекращается
никогда, потому что постоянно требуется
вносить изменения.
- уточнение требований продолжается в течение
всего времени проектирования.
- программная система наследует проблемы реальной
системы.
2. Проблема сложности при проектировании
программного обеспечения. Различные
виды сложности при проектировании программного
обеспечения.
1. Сложность проблемы
- сложность поставленной задачи в сочетании
с дополнительными требованиями стоимости,
надёжности, удобства, производительности;
- сложность получения достоверных данных о
предметной области от заказчика;
- изменение требований в процессе разработки
программной системы;
- необходимость длительного обслуживания программной
системы.
2. Сложность управления процессом
разработки
- большой объём программ и сложная логика
функционирования программной системы;
- большой коллектив программистов;
- необходимость согласования технических решений;
- координация работ различных групп программистов;
- поддержания единства и целостности разработки;
- создание документации на программную систему;
- обеспечение временных и финансовых ограничений
на разработку.
3. Сложность обеспечения гибкости
сопровождения конечного продукта
- использование определенных технологий,
стандартов и соглашений в программировании;
- использование специальных решений
для обеспечения сопровождения;
- разработка специальных технологических
средств сопровождения программной системы;
- разработка системы тестирования
программ.
4. Сложность описания поведения отдельных
подсистем
- сложность алгоритмов описания реальной предметной
области;
- сложность информационных связей в предметной
области;
- сложность логических взаимосвязей предметной
области;
- наличие ограничений на параметры функционирования
программной системы.
3. Основные характерные особенности
больших программных систем
Большие программные системы – это
промышленные программные продукты. Для
них характерно следующее:
- различные области применения;
- сложность логической организации;
- большой объём кода;
- множество пользователей;
- долгосрочное использование;
- требуется модернизация и сопровождение;
- требуется сопроводительная документация;
- разрабатываются коллективом программистов;
- требуются значительные финансовые ресурсы.
4. Определение требований к проектируемому
программному обеспечению. Управление
требованиями.
Эта работа выполняется совместно
разработчиком и заказчиком.
1. Постановка задачи
- нужно понять, что нужно сделать.
- требования формулируются совместно с заказчиком
и проектировщиком с максимально возможной
строгостью.
- нельзя ориентироваться на требования
одного, но влиятельного лица, потому что
в этом случае система обрекается на недолговечность;
должен быть найден и вовлечён в дело действительный
пользователь, а не его заменитель.
- разные пользователи предъявляют противоречивые
требования.
- представитель заказчика должен иметь полномочия
принимать решения.
2. Управление требованиями
Самое первое требование к проектированию
больших систем - предусмотреть возможность
будущих изменений.
- предусмотреть изменения в проекте;
- заказчики и разработчики одни и те же требования
понимают по-разному;
- требованиями надо управлять;
- за выработку требований должен отвечать
один и тот же человек.
| |
Может сделать |
Пропустит |
ЗАКАЗЧИК |
Ясно выразить важные потребности
Правильно расставить приоритеты
|
Требования к технологии
Потребности инфраструктуры |
ПРОЕКТИРОВЩИК |
Определить состояние дел в технологии
Определить полноту требований
|
Сортировку интересов пользователей
Тонкости прикладной области |
5. Документирование процесса
проектирования. Назначение документирования.
Требование к документированию.
Самая трудная задача - организовать
ведение документации.
Если отсутствует документация, доступная
для всех, то проект обречён на неудачу.
Дональд Дуглас: "Когда вес документов
достигает веса самолёта, самолёт начинает
летать".
Основные принципы:
- документация создаётся на всех уровнях проектирования;
- должны использоваться методы документирования
(HIPO, SADT, IA, UML).
Чего следует придерживаться при
создании документации:
- требования формируются совместно заказчиком
и проектировщиком с максимально возможной
строгостью;
- язык формулировок требований должен
быть понятен пользователю и проектировщику;
- нужно документировать требования, всегда
записывать их, ничего не оставлять "на
память";
- если требования не записаны и не сделаны
доступными разработчикам, они вроде бы
и не существуют.
6. Использование декомпозиции
при проектировании больших программных
систем. Декомпозиция при алгоритмическом
подходе. Декомпозиция при объектно-ориентированном
подходе.
Декомпозиция – это разложение на
более мелкие составные части.
Алгоритмическая декомпозиция:
Один управляющий алгоритм, который
вызывает всё остальное. Иерархическое
управление сверху вниз. Каждый модуль
имеет только одну связь наверх.
- Нисходящее проектирование - этот алгоритм
предпочтителен, когда в самом начале
мы не проектируем модули, а проектируем
управляющий алгоритм.
- Восходящее проектирование - худший метод,
хотя и чаще встречающийся. Сначала создаются
модули, а потом объединяющий их главный
управляющий алгоритм.
- Комбинированное проектирование - сочетание нисходящего
и восходящего.
Объектная декомпозиция:
7. Требования к программным модулям при
проведении декомпозиции.
1. Проблемы модулей
- модули выполняют слишком много связанных,
но различных функций;
- при проектирования остались невыявленными
общие функции, вследствие чего они рассредоточены
и по-разному реализованы в разных модулях;
- модули взаимодействуют посредством совместно
используемых или общих данных самым неожиданным
образом.
2. Структурное проектирование модуля
Необходимо всегда делать так, чтобы
была одна точка входа в модуль и одна
точка выхода из него. Варианты:
- линейная структура;
- ветвление из входной точки ветвями в итоге
в одну выходную;
- цикл - по кругу внутри можно ходить сколько
угодно, но выход из цикла только в одну
выходную точку модуля.
3. Характеристики модуля
Чем характеризуется модуль при попытках
его изменения, отладке и поиске ошибок:
- функциональная прочность. После проведения декомпозиции
и разбиения модуля на несколько, его функциональность
должна сохраняться;
- информационная прочность - когда данные, используемые
модулем, находятся внутри самого же модуля,
внешние переменные не используются;
- сцепление по данным - передача данных из модуля
в модуль должна быть управляемой. А лучше
вообще не передавать данные от модуля
к модулю;
- сцепление по общей области - избегать его
всеми силами;
- сцепление по по управлению;
- сцепление по формату;
- сцепление по содержимому - по общим константам;
- размер модуля - исключительно для удобства
человека, чтобы модуль был обозримым.
4. Хороший программный модуль
- Сложность взаимодействия модуля с другими
модулями должна быть меньше сложности
его внутренней структуры
- Хороший модуль снаружи проще, чем внутри
- Хороший модуль проще использовать, чем
построить
8. Роль абстракции в процессе
проектирования. Барьер абстракции. Абстракции
сущности и абстракции поведения.
Абстракция:
- выделяет существенные характеристики некоторого
объекта, отличающие его от всех других
видов объектов и, таким образом, чётко
определяет его концептуальные границы
с точки зрения наблюдателя;
- разделяет смысл и реализацию объекта;
- выделение существенных особенностей объекта
и отделения их от несущественных - барьер
абстракции.
Виды абстракций:
- абстракция сущности – объект представляет
собой полезную модель некой сущности
в предметной области.
- абстракция поведения – объект состоит
из обобщенного множества операций.
- абстракция виртуальной машины –
объект группирует операции, которые либо
вместе используются более высоким уровнем
управления, либо сами используют некоторый
набор операций более низкого уровня
- произвольная абстракция – объект
включает в себя набор операций, не имеющих
друг с другом ничего общего
Центральной идеей абстракции является
понятие инварианта – некоторого логического
условия, значение которого (истина или
ложь) должно сохраняться. Для каждой операции
объекта можно задать предусловия (инварианты
предполагаемые операцией) и постусловия (инварианты,
которым удовлетворяет операция). Изменение
инварианта нарушает контракт, связанный
с абстракцией. Все абстракции обладают
как статическими, так и динамическими
свойствами.
9. Уровень реализации. Критерии
выбора языка программирования и стандартов
программирования.
Уровень реализации включает:
- Выбор языка программирования
- Выбор стандартов программирования
- Выбор инструментария программирования
- Проектирование диалогового взаимодействия
- Уровни квалификации. Главный программист
- Компоновка программ
- Контроль версий системы
Выбор языка должен производиться
на основе требований к разрабатываемому
продукту с учетом следующих факторов:
• парадигма языка программирования;
• вид типизации;
• компилируемость или интерпретируемость
кода;
• управление памятью;
• стандартизация;
• переносимость кода;
• скорость разработки;
• скорость исполнения;
• количество потребляемой памяти.
Сложность языка не всегда напрямую
связана с его мощностью.
Концепция языка программирования
неотрывно связана с его реализацией.
Для того чтобы компиляция одной
и той же программы различными
компиляторами всегда давала одинаковый
результат, разрабатываются стандарты
языков программирования. Существует
ряд организаций, целенаправленно занимающихся
вопросами стандартизации. Это Американский
национальный институт стандартов ANSI
(American National Standards Institute), Институт инженеров
по электротехнике и электронике IEEE (Institute
of Electrical and Electronic Engineers), Организация международных
стандартов ISO (International Organization for Standardization).
Как правило, при создании языка выпускается
частный стандарт, определяемый разработчиками
языка.