Вопросы и ответы (старое, есть ошибки), страница 5

Событие, переход.

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

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

Деятельность, действие.

• Деятельность - это продолжающееся неатомарное вычисление внутри автомата.

• Действие - это атомарное вычисление, которое приводит к смене состояния или возврату значения

17. Язык UML. Диаграмма деятельности. Вид диаграммы. Назначение диаграммы.

• Моделирует динамическое поведение системы

• Показывает поток переходов от одной деятельности к другой

• Используется для любых видов абстракций

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

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

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

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

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

Кассы – Компоненты.

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма развёртывания, Deployment diagram — служит для моделирования работающих узлов (аппаратных средств, англ. node) и артефактов, развёрнутых на них. В UML 2 на узлах разворачиваются артефакты (англ. artifact), в то время как в UML 1 на узлах разворачивались компоненты. Между артефактом и логическим элементом (компонентом), который он реализует, устанавливается зависимость манифестации.

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

Прямым проектированием (Forward engineering) называется процесс преобразования модели в код путем отображения на некоторый язык реализации. Процесс "прямого проектирования приводит к потере информации, поскольку написанные на языке UML модели семантически богаче любого из существующих объектно-ориентированных языков. Фактически именно это различие и является основной причиной, по которой мы, помимо кода, нуждаемся и в моделях. Некоторые структурные свойства системы, такие как кооперации, или ее поведенческие особенности, например взаимодействия, могут быть легко визуализированы в UML, но в чистом коде наглядность теряется.

Прямое проектирование диаграммы классов производится следующим образом:

1. Идентифицируйте правила отображения модели на один или несколько язы ков программирования по вашему выбору. Это допустимо делать как при работе над одним конкретным проектом, так и для вашей организации в целом.

2. В зависимости от семантики выбранных языков, вероятно, придется отказаться от использования некоторых возможностей UML. Например, язык UML допускает множественное наследование, а язык программирования Smalltalk - только одиночное. В связи с этим можно или запретить авторам моделей пользоваться множественным наследованием (что сделает создаваемые модели зависимыми от языка), или разработать идиомы для трансляции таких расширенных возможностей в конструкции, поддерживаемые данным языком программирования (что усложнит отображение).

3. Применяйте помеченные значения для специфицирования языка программирования. Это можно сделать как на уровне индивидуальных классов (если нужна тонкая настройка), так и на более высоком уровне, например для пакетов или коопераций.

4. Пользуйтесь инструментальными средствами для прямого проектирования моделей.

Обратным проектированием (Reverse engineering) называется процесс преобразования в модель кода, записанного на каком-либо языке программирования. В результате этого процесса вы получаете огромный объем информации, часть которой находится на более низком уровне детализации, чем необходимо для построения полезных моделей. В то же время обратное проектирование никогда не бывает полным. Как уже упоминалось, прямое проектирование ведет к потере информации, так что полностью восстановить модель на основе кода не удастся, если только инструментальные средства не включали в комментариях к исходному тексту информацию, выходящую за пределы семантики языка реализации.

Обратное проектирование диаграммы классов осуществляется так:

1. Идентифицируйте правила для преобразования из выбранного вами языка реализации. Это можно сделать на уровне проекта или организации в целом.

2. С помощью инструментального средства укажите код, который вы хотите подвергнуть обратному проектированию. Воспользуйтесь этим средством для создания новой модели или для модификации ранее созданной.

3. Пользуясь инструментальными средствами, создайте диаграмму классов путем опроса полученной модели. Можно начать, например, с одного или нескольких классов, а затем расширить диаграмму, следуя вдоль некоторых отношений или добавив соседние классы. Раскройте или спрячьте детали содержания диаграммы в зависимости от ваших намерений.

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

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

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

Стадии проектирования:

1) Формирование требований к системе.

2) Проектирование

3) Реализация

4) Тестирование

5) Ввод в эксплуатацию

6) Сопровождение

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

• Этап проектирования не прекращается никогда

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

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

Итерационная модель разработки - процесс проектирования и реализации кода продукта, при котором не вносятся серьёзные изменения в архитектуру, а лишь направляются эволюционные процессы развития.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРЕДМЕТНАЯ ОБЛАСТЬ – промышленные программные продукты

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

• Сложные в логической организации

• Большие по объему кода

• Имеют много пользователей

• Долгое время жизни (использования)

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

• Должны сопровождаться документацией

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

• Требуют больших финансовых ресурсов

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

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

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

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

• Нельзя ориентироваться только на требования одного, но влиятельного лица. Система обрекается на недолговечность. Должен быть найден и вовлечен в дело действительный пользователь, а не его заменитель

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

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

2. Документирование.

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

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

• Нужно документировать требования

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

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

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

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

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

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

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

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

• Дональд Дуглас – «когда вес документов достигает веса самолета, самолет начнет летать»

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

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

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

Требования («Да, это то что мы заказывали, но не то, что хотели» - Заказчик) :

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

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

• Нужно документировать требования

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

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

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