Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 3)

Диаграмма деятельности — диаграмма, на которой показано разложение некоторой деятельности на её составные части. Под деятельностью понимается спецификация исполняемого поведения в виде координированного последовательного и параллельного выполнения подчинённых элементов — вложенных видов деятельности и отдельных действий, соединённых между собой потоками, которые идут от выходов одного узла к входам другого.

Диаграммы деятельности используются при моделировании бизнес-процессов, технологических процессов, последовательных и параллельных вычислений.

18. Язык UML. Диаграмма компонентов. Вид диаграммы. Назначение диаграммы.

Диаграмма компонентов – описание организации компонентов и зависимостей между ними. Статическое описание системы. Представляет физическое представление системы.

Компонент – это физическая заменяемая часть системы, совместимая с одним набором интерфейсов. Компонент изображается в виде прямоугольника с вкладками.

• классы представляют собой логические абстракции, а компоненты - физические сущности. Таким образом, компоненты могут размещаться в узлах, a классы нет

• компоненты представляют собой физическую упаковку логических сущностей и, следовательно, находятся на другом уровне абстракции

• классы могут обладать атрибутами и операциями. Компоненты обладают только операциями, доступными через их интерфейсы

Интерфейс – это набор операций, которые описывают услуги, доставляемые классом или компонентом.

Стандартные стереотипы компонентов:

• executable (исполнимый) – определяеткомпонент, который может использоваться в узле

• library (библиотека) – определяет статическую или динамическую проектную библиотеку

• table (таблица) – определяет компонент, представляющий таблицу базы данных

• file (файл) – определяет компонент, представляющий документ, который содержит исходный текст или данные

• document (документ) – определяет компонент, представляющий документ

19. Язык UML. Диаграмма развертывания. Вид диаграммы. Назначение диаграммы.

Диаграмма развертывания (Deployment diagram) – представляет конфигурацию обрабатывающих узлов системы и размещенных в них компонентов. Статическое описание системы.

Узел – это физический элемент, который существует во время выполнения и представляет вычислительный ресурс, обычно обладающий как минимум некоторым объемом памяти, а зачастую также и процессором.

В UML диаграммы развертывания используются для визуализации статических аспектов физических узлов и их взаимосвязей, а также для описания их деталей, которые имеют отношения к конструированию систем.

20. Язык UML. Понятие прямого и обратного проектирования.

Проектирование с использованием UML может быть:

• прямое – из модели UML можно получить готовый код описания проекта: все классы и объявления переменных и методов;

• обратное – из кода можно получить диаграмму классов.

Отображение модели на язык программирования позволяет осуществить прямое проектирование – генерация кода на языке программирования из модели UML. Также возможно восстановить модель UML на основе существующей реализации. Однако, обратное проектирование, выполняемое инструментальными средствами, все же требует определенного вмешательства человека, так как некоторая информация может теряться при переходе от модели к коду. Комбинация этих двух путей – прямого и обратного проектирования – обеспечивает возможность работы как с графическим, так и с текстовым представлениями; при этом обеспечивается согласованность между ними. В дополнение к прямому отображению UML благодаря своей выразительности и однозначности позволяет непосредственно исполнять модели, имитируя поведение проектируемых систем, а также управляя действующими системами.

21. Язык UML. Элементы описания класса на диаграмме классов

Диаграммы классов включает классы, интерфейсы, объекты и кооперации, а также их отношения. Не указываются временные аспекты функционирования системы.

Структура класса:

• имя класса (уникальное);

• атрибуты;

• операции (методы);

• интерфейсы.

Отношения:

• зависимости;

• ассоциация;

• агрегация;

• обобщение.

ВОПРОСЫ ПО ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ

1. Стадии проектирования программных систем. Итерационное проектирование

Теоретический процесс разработки:

Реальный процесс разработки:

Постоянно приходится возвращаться на предыдущие этапы и вносить изменения.

Основные принципы проектирования больших программных систем

• этап проектирования не прекращается никогда, потому что постоянно требуется вносить изменения.

• уточнение требований продолжается в течение всего времени проектирования.

• программная система наследует проблемы реальной системы.

2. Проблема сложности при проектировании программного обеспечения. Различные виды сложности при проектировании программного обеспечения.

1. Сложность проблемы

• сложность поставленной задачи в сочетании с дополнительными требованиями стоимости, надёжности, удобства, производительности;

• сложность получения достоверных данных о предметной области от заказчика;

• изменение требований в процессе разработки программной системы;

• необходимость длительного обслуживания программной системы.

2. Сложность управления процессом разработки

• большой объём программ и сложная логика функционирования программной системы;

• большой коллектив программистов;

• необходимость согласования технических решений;

• координация работ различных групп программистов;

• поддержания единства и целостности разработки;

• создание документации на программную систему;

• обеспечение временных и финансовых ограничений на разработку.

3. Сложность обеспечения гибкости сопровождения конечного продукта

• использование определенных технологий, стандартов и соглашений в программировании;

• использование специальных решений для обеспечения сопровождения;

• разработка специальных технологических средств сопровождения программной системы;

• разработка системы тестирования программ.

4. Сложность описания поведения отдельных подсистем

• сложность алгоритмов описания реальной предметной области;

• сложность информационных связей в предметной области;

• сложность логических взаимосвязей предметной области;

• наличие ограничений на параметры функционирования программной системы.

3. Основные характерные особенности больших программных систем

Большие программные системы – это промышленные программные продукты. Для них характерно следующее:

• различные области применения;

• сложность логической организации;

• большой объём кода;

• множество пользователей;

• долгосрочное использование;

• требуется модернизация и сопровождение;

• требуется сопроводительная документация;

• разрабатываются коллективом программистов;

• требуются значительные финансовые ресурсы.

4. Определение требований к проектируемому программному обеспечению. Управление требованиями.

Эта работа выполняется совместно разработчиком и заказчиком.

1. Постановка задачи

• нужно понять, что нужно сделать.

• требования формулируются совместно с заказчиком и проектировщиком с максимально возможной строгостью.

• нельзя ориентироваться на требования одного, но влиятельного лица, потому что в этом случае система обрекается на недолговечность; должен быть найден и вовлечён в дело действительный пользователь, а не его заменитель.

• разные пользователи предъявляют противоречивые требования.

• представитель заказчика должен иметь полномочия принимать решения.

2. Управление требованиями

Самое первое требование к проектированию больших систем - предусмотреть возможность будущих изменений.

• предусмотреть изменения в проекте;

• заказчики и разработчики одни и те же требования понимают по-разному;

• требованиями надо управлять;

• за выработку требований должен отвечать один и тот же человек.

	Может сделать	Пропустит
ЗАКАЗЧИК	Ясно выразить важные потребности Правильно расставить приоритеты	Требования к технологии Потребности инфраструктуры
ПРОЕКТИРОВЩИК	Определить состояние дел в технологии Определить полноту требований	Сортировку интересов пользователей Тонкости прикладной области

5. Документирование процесса проектирования. Назначение документирования. Требование к документированию.

Самая трудная задача - организовать ведение документации.

Если отсутствует документация, доступная для всех, то проект обречён на неудачу.

Дональд Дуглас: "Когда вес документов достигает веса самолёта, самолёт начинает летать".

Основные принципы:

• документация создаётся на всех уровнях проектирования;

• должны использоваться методы документирования (HIPO, SADT, IA, UML).

Чего следует придерживаться при создании документации:

• требования формируются совместно заказчиком и проектировщиком с максимально возможной строгостью;

• язык формулировок требований должен быть понятен пользователю и проектировщику;

• нужно документировать требования, всегда записывать их, ничего не оставлять "на память";

• если требования не записаны и не сделаны доступными разработчикам, они вроде бы и не существуют.

6. Использование декомпозиции при проектировании больших программных систем. Декомпозиция при алгоритмическом подходе. Декомпозиция при объектно-ориентированном подходе.

Декомпозиция – это разложение на более мелкие составные части.

Алгоритмическая декомпозиция:

Один управляющий алгоритм, который вызывает всё остальное. Иерархическое управление сверху вниз. Каждый модуль имеет только одну связь наверх.

• Нисходящее проектирование - этот алгоритм предпочтителен, когда в самом начале мы не проектируем модули, а проектируем управляющий алгоритм.

• Восходящее проектирование - худший метод, хотя и чаще встречающийся. Сначала создаются модули, а потом объединяющий их главный управляющий алгоритм.

• Комбинированное проектирование - сочетание нисходящего и восходящего.

Объектная декомпозиция:

Характеристики

Список файлов ответов (шпаргалок)