1. Что такое промышленный программный продукт. Дать определения пакета прикладных программ, программной системы

1. Что такое промышленный программный продукт. Дать определения пакета прикладных программ, программной системы.

Пакет прикладных программ (ППП) – называется множество или совокупность (организованная), программ и модулей, позволяющая решать целый класс задач. ППП с дружественным профессионально-ориентированным интерфейсом пользователя называется программной системой (ПС).

ПС, обладающая качествами промышленного изделия, называется ППИ (промышленное программное изделие).

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

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

Только 16,2% завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения; для двух последних категорий проектов бюджет среднего проекта оказался превышенным на 89%, а срок выполнения - на 122%.

Основные причины кризиса:

1. 
   Нечеткая и неполная формулировка требований к ПО
   
2. 
   Недостаточное вовлечение пользователей в работу над проектом
   
3. 
   Отсутствие необходимых ресурсов
   
4. 
   Неудовлетворительное планирование и отсутствие грамотного управления проектом
   
5. 
   Частое изменение требований и спецификаций
   
6. 
   Новизна и несовершенство используемой технологии
   
7. 
   Недостаточная поддержка со стороны высшего руководства
   
8. 
   Недостаточно высокая квалификация разработчиков, отсутствие необходимого опыта.
   

Критичность и масштабность проекта.

Существует 4 уровня критичности. C – самый низкий. Дефекты вызывают потерю удобства (word завис), d – дефекты вызывают потерю возместимых средств (хакер в банке), e – дефекты вызывают потерю невозместимых средств (станция отправлена на Марс, а она не вернулась), l – дефекты создают угрозу человеческой жизни.

Масштабность: 1-6 человек – малый масштаб, 6-20 человек – средний масштаб, свыше 20 – крупный масштаб.
3. Жизненный цикл программного обеспечения. Дать краткую характеристику каждого этапа.

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

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

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

На основе этой модели должно быть выработано понимание проблемы достаточное для проектирования системы.

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

4. Каскадные модели разработки ПО.

Модель водопада (waterfall model) — модель процесса разработки программного обеспечения, в которой процесс разработки выглядит как поток, последовательно проходящий фазы анализа требований, проектирования, реализации, тестирования, интеграции и поддержки.

В оригинальной модели водопада Ройса, следующие фазы шли в таком порядке:

1. 
   Определение требований
   
2. 
   Проектирование
   
3. 
   Конструирование (также «реализация» либо «кодирование»)
   
4. 
   Интеграция
   
5. 
   Тестирование и отладка (также «верификация»)
   
6. 
   Инсталляция
   
7. 
   Поддержка
   

Следуя модели водопада, разработчик переходит от одной стадии к другой строго последовательно. Сначала полностью завершается этап «определение требований», в результате чего получается список требований к ПО. После того как требования полностью определены, происходит переход к проектированию, в ходе которого создаются документы, подробно описывающие для программистов способ и план реализации указанных требований. После того как проектирование полностью выполнено, программистами выполняется реализация полученного проекта. На следующей стадии процесса происходит интеграция отдельных компонентов, разрабатываемых различными командами программистов. После того как реализация и интеграция завершены, производится тестирование и отладка продукта; на этой стадии устраняются все недочёты, появившиеся на предыдущих стадиях разработки. После этого программный продукт внедряется и обеспечивается его поддержка — внесение новой функциональности и устранение ошибок.

Тем самым, модель водопада подразумевает, что переход от одной фазы разработки к другой происходит только после полного и успешного завершения предыдущей фазы, и что переходов назад либо вперёд или перекрытия фаз — не происходит.

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



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

«+» данной модели является механизм контроля.

«-» : выполнять этот контроль затруднительно, поскольку документы, разработанные на начальных этапах, часто бывают неоднозначными.
5. Итеративные модели разработки ПО.

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

Управляемый итеративный процесс имеет ряд преимуществ:

1. 
   управляемая итерация ограничивает финансовые риски затратами на одно приращение
   
2. 
   управляемая итерация снижает риск не поставки продукта в установленные договором сроки. При раннем обнаружении соответствующего риска времени можно внести этот риск в план на ранних этапах разработки
   
3. 
   управляемая итерация ускоряет темпы процесса разработки в целом
   
4. 
   управляемый итеративный процесс направлен на удовлетворение желаний пользователя
   

Спиральная модель разработки ПО

Риск: не уложиться во времени, в финансы.



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

«-» основная доработка на последнем этапе.

Эволюционная модель

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



Преимущества данной модели:

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

Недостатки:

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

Адаптивная модель

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



Это выражается в 3 компонентах данной модели

• 
  Размышляйте (как бы деятельность планирования)
  
• 
  Сотрудничайте (взаимодействие между всеми сторонами, вовлеченными в проект)
  
• 
  Учитесь – предназначен для оценки эволюционного развития продукта
  

Преимущества адаптивной модели:

• 
  Позволяет работать над проектами, требования для которых полностью неизвестны на начальном этапе.
  

Недостатки:

• 
  Основной недостаток – невозможность полноценного управления проектом.
  

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

Сложность программных систем (ПС) обусловлена следующим:

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

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

1. 
   сложные системы часто являются иерархическими и состоят из взаимосвязанных подсистем, которые в свою очередь также могут быть разделены на подсистемы и т.д. в плоть до низкого уровня
   
2. 
   выбор какие компоненты в данной системе считаются элементарными относительно произволен и в большей степени остаются на усмотрение разработчика
   
3. 
   внутрикомпонентная связь обычно сильнее, чем связь между компонентами
   
4. 
   иерархические системы обычно состоят из немногих типов подсистем по-разному скомбинированных и организованных
   
5. 
   любая работающая сложная система является результатом развития работающей более простой системы, сложная система, спроектированная с нуля никогда не будет работать, следует начинать с работающей простой системы
   

7. Техническое задание. Перечислить и охарактеризовать разделы, входящие в техническое задание.

Составление технического задания состоит из следующих этапов:

1. 
   введение
   
2. 
   основание для разработки
   
3. 
   назначение разработки
   
4. 
   требования к программному продукту (основной раздел)
   
5. 
   требования к программной документации
   
6. 
   технико-экономические показатели
   
7. 
   стадии и этапы разработки (составление календарного плана)
   
8. 
   порядок контроля и приемки
   
9. 
   приложения
   

Введение – в данном разделе указывают наименование, краткую характеристику области применения программного продукта и объекта в котором используют программный продукт.

Основание для разработки – в данном разделе указывают:

1. 
   документ или документы, на основании которых ведется разработка
   
2. 
   организация утвердившая этот документ и дата его утверждения
   
3. 
   наименование и (или) условное обозначение темы разработки
   

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

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

1. 
   требования к функциональным характеристикам – в подразделе должны быть указаны требования к составу выполняемых функций, организации входных и выходных данных, временным характеристикам и т.д.
   
2. 
   требования к надежности – в подразделе должны быть указаны требования к обеспечению надежного функционирования (контроль входных и выходных данных, обработка ошибок вычисления, время восстановления системы после отказов и т.д.)
   
3. 
   требования к условиям эксплуатации – в подразделе должны быть указаны условия эксплуатации (температура воздуха, влажность и т.д.) при которых должны обеспечиваться заданные характеристики, а также вид обслуживания, необходимое количество и квалификация персонала
   
4. 
   требования к составу и параметрам технических средств – в подразделе указывается необходимый состав технических средств с указанием их основных характеристик
   
5. 
   требования к информационной и программной совместимости – в подразделе должны быть указаны требования к информационным структурам на входы и выходы методом решения исходным языкам, языком программирования и программным средствам используемым программой, при необходимости должна обеспечиваться защита информации и программы
   
6. 
   требования к маркировке и упаковке – в подразделе, в общем случае, указываются требования к маркировке продукта, варианты и способы упаковки
   
7. 
   требования к транспортировке и хранению – в подразделе для продукта должны быть указаны условия транспортировки, место хранения, сроки хранения в различных условиях
   

Требования к программной документации – в этом разделе должен быть указан предварительный состав программной документации и при необходимости специальные требования к ней.

Технико-экономический показатель – в данном разделе указываются:

1. 
   ориентировочная экономическая эффективность
   
2. 
   предполагаемая годовая потребность
   
3. 
   экономические преимущества разработки по сравнению с существующими аналогами
   

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

Порядок контроля и приемки – в этом разделе указываются виды испытаний и общие требования к приемке работы.

Приложения – приложения составляются по следующим документам:

1. 
   в приложениях к техническому заданию приводят перечень научно-исследовательских работ, обосновывающих разработку
   
2. 
   схемы, таблицы, описания, обоснования и документы, необходимые для разработки.
   

8. Технология экстремального программирования.


Принципы:

1. 
   Игра-планирование. Быстрое определение области действия следующей реализации путем объединения деловых приоритетов и технических оценок
   
2. 
   Частая смена версий. Быстрый запуск производства простой системы. Смена версии каждые 2 недели.
   
3. 
   Метафора. Вся разработка ведется на основе простой общедоступной идеи.
   
4. 
   Простое проектирование. Проектирование выполняется настолько просто, насколько возможно.
   
5. 
   Тестирование. Непрерывное написание тестов для разработанных модулей. Тесты создаются заказчиками. Тесты выполняются безупречно.
   
6. 
   Реорганизация. Система реконструируется, но ее поведение не изменяется.
   
7. 
   Парное программирование. Код каждой подсистемы пишется 2 программистами, причем работают посменно.
   
8. 
   Коллективное владение кодом. Каждый может вносить изменения в код в любое время.
   
9. 
   Непрерывная интеграция. Система интегрируется и собирается по нескольку раз в день.
   
10. 
    40-часовая рабочая неделя.
    
11. 
    Локальный заказчик. В группе разработчиков постоянно присутствует представитель заказчика.
    
12. 
    Стандарты кодирования.
    

9. Унифицированный процесс разработки программного обеспечения. Жизненный цикл унифицированного процесса.




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

Описание:

1. 
   Модель вариантов использования со всеми вариантами использования.
   
2. 
   Модель анализа целью, которой является уточнение вариантов использования.
   
3. 
   Модель проектирования, в которой реализуется модель вариантов использования.
   
4. 
   Модель развертывания, в которой компоненты распределяются по узлам, а каждый узел – компьютер.
   
5. 
   Модель реализации – это диаграмма компонентов.
   
6. 
   Модель тестирования, которая предназначена для тестирования и отладки нашего программного продукта.
   

Разделение цикла разработки на фазы.

Каждый цикл осуществляется в течение некоторого времени. Это время делится на следующие фазы:

• 
  анализ и планирование требований
  
• 
  проектирование
  
• 
  построение
  
• 
  внедрение
  

Каждая фаза заканчивается вехами.

Веха – это измеримый и определяемый результат.

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

Цели:

1) Понять что создавать

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

2) Выяснить ключевые функции системы

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

3) Выявить хотя бы одно возможное решение

Необходимо построить хотя бы одну архитектуру

4) Оценить стоимость, сроки и риски

5) Решить какому процессу следовать и какие средства использовать

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

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

Причины:

1) Проект вели и команде трудно понять его границы

2) Существуют большие технологические риски, которые необходимо уменьшить путем создания прототипа

3) Система не имеет аналогов и трудно понять, что она должна делать

4) Есть множество заинтересованных сторон и их взаимоотношения сложны

5) Трудно получить экономическое обоснование с первого раза
11. Унифицированный процесс разработки программного обеспечения. Этап проектирования.

Цели:

1) Более глубоко понять требования

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

2) Спроектировать и реализовать базовую архитектуру

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

3) Снизить существенные риски и дать более четкую оценку сроков и стоимости

Производится анализ выполнения первых двух щелей и на основе этого строится оценка стоков и стоимости выполнения проекта.

4) Уточнить претендент разработки

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

Количество итераций:

Если подобные проекты уже выполнялись, то фаза проектирования может быть выполнена за 1 итерацию, однако, если отсутствует опыт в разработке систем подобного рода для реализации данной фазы может потребоваться 2-3 итерации.
12. Унифицированный процесс разработки программного обеспечения. Этап внедрения.

Цели:

1) Провести бета-тестирование для проверки соответствия программы ожиданиям пользователя

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

2) Научить пользователя и обслуживающий персонал работать самостоятельно.

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

3) Подготовить площадку для развертывания системы и конвертирования рабочих баз данных

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

4) Подготовить упаковку, тиражирование, провести маркетинговое исследование, разработать рекламные материалы, выпуск дистрибутивов в продажу

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

6) Повысить производительность при выполнении будущих проектов на основе приобретенного опыта.

Количество итераций фазы внедрения зависит от сложности проекта: 1-3
13. Принципы унифицированного процесса.

1. Начинайте наступление на главные риски с самого начала разработки и ведите их непрерывно иначе риски подойдут в наступление на вас.

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

2. Обеспечьте выполнение требований заказчика

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

3. Сконцентрируйтесь на исполняемой программе

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

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

Современные приложения слишком сложны, чтобы можно было получить все требования с самого начала. Это означает, что для того чтобы создать хорошую систему необходимо позволять изменения и с самого начала приспосабливаться к тому, что они будут.

5. С самого начала закладывайте исполняемую архитектуру

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

6. Стройте систему из компонентов

Приложения на основе компонентов более гибкие с точки зрения изменений. В них радикально снижены затраты по обслуживанию. Компоненты облегчают повторное использование и позволяют быстро создавать качественные приложения.

7. Сделайте качество образом жизни, а не запоздалой идеей.

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

14. Работа с кадрами. Перечислить роли разработчиков и дать характеристику каждой из них.

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

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

1. 
   Архитектор проекта
   
2. 
   Ответственные за подсистему
   
3. 
   Прикладные программисты
   

1. 
   Архитектор проекта – это его творец, который отвечает за эволюцию и сопровождение архитектуры системы. Для малых и средних проектов требуется участие одного или максимум двух архитекторов. Для крупных проектов количество архитекторов может измеряться десятками. Архитектор проекта не обязательно самый главный разработчик, но он должен иметь достаточно власти, для того чтобы принимать стратегические решения. Архитекторы необязательно самые лучшие программисты, хотя они должны владеть программой в определенной степени. Архитекторы должны хорошо владеть средствами моделирования программных систем. Очень плохая практика нанимать архитектора со стороны.
   
2. 
   Ответственные за подсистему – это те люди, которые проектируют программные структуры (классы) для реализации тех или иных функциональных возможностей. Они отвечают за проектирование целого ряда подсистем. Каждый ответственный в сотрудничестве с архитектором разрабатывает, обосновывает и согласовывает с другими разработчиками интерфейсы своих подсистем. Ответственные за подсистемы возглавляют их реализацию, тестирование и выпуск версий в течение всей эволюции системы. Ответственные за подсистемы должны хорошо знать систему обозначений и организацию процесса объектно-ориентированной разработки.
   
3. 
   На прикладных программистов возлагается выполнение двух обязанностей:
   

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

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

1. 
   Менеджер проекта отвечает за управление материалами проекта, заданиями, ресурсами и графиком работ.
   
2. 
   Аналитик отвечает за развитие и интерпретацию требований конечных пользователей. Он должен быть экспертом проблемной области.
   
3. 
   Инженер по повторному использованию управляет хранилищем материалов проекта. Активно ищет общее и добивается его использования. Находит, разрабатывает и приспосабливает компоненты для общего использования в рамках проекта.
   
4. 
   Контролер качества (тестер) измеряет результаты процесса разработки, задает общее направление и участвует в тестировании всех версий программного продукта.
   
5. 
   Менеджер интеграции отвечает за сборку совместимых друг с другом версий, категорий и подсистем в релизе программной системы.
   
6. 
   Ответственный за документацию (технический писатель) готовит документацию по выпускаемому продукту для конечного пользователя.
   
7. 
   Системный администратор управляет физическими компьютерными ресурсами в проекте.
   

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

Четыре «П» унифицированного процесса:

Персонал – реальные люди, которые участвуют в проекте. Под персоналом понимаются не только непосредственные разработчики, а все заинтересованные лица.

Проект – организационная сущность при помощи которой происходит управление разработкой ПО.

Продукт – артефакты, создаваемые в течении жизни проекта (модель, документ и т. д.)

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

Утилиты автоматизируют процесс.

16. 
    Использование языка UML при проектировании сложных программных систем. Какие диаграммы используются в UML для создания моделей программной системы.
    

UML (Unified Modeling Language , предложенный James Rumbaugh, Grady Booch and Ivar Jacobson, Rational Software Corp)

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

Необходим процесс, который:

1. 
   обеспечил бы руководство деятельностью команды
   
2. 
   управлял бы задачами отдельного разработчика и команды в целом
   
3. 
   указывал бы, какие артефакты следует разработать
   
4. 
   представлял бы критерии для отслеживания и измерения продуктов и функционирования проекта
   

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

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

С точки зрения визуального моделирования, UML можно охарактеризовать следующим образом. UML предоставляет выразительные средства для создания визуальных моделей, которые:

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

Унифицированный Язык Моделирования (UML):

• 
  не зависит от объектно-ориентированных (ОО) языков программирования,
  
• 
  не зависит от используемой методологии разработки проекта,
  
• 
  может поддерживать любой ОО язык программирования.
  

UML является открытым и обладает средствами расширения базового ядра. На UML можно содержательно описывать классы, объекты и компоненты в различных предметных областях, часто сильно отличающихся друг от друга.

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

1. 
   Use case diagram (диаграммы сценариев);
   

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

2. 
   Deployment diagram (диаграммы топологии);
   

Этот вид диаграмм предназначен для анализа аппаратной части систе­мы, то есть «железа», а не программ. При помощи данной диаграммы проектировщик может произвести анализ необходимой аппаратной конфигурации, на ко­торой будут работать отдельные процессы системы, и описать их взаимо­действие между собой и другими аппаратными устройствами. Этот тип диаграмм также позволяет анализировать взаимодействие про­цессов, работающих на разных компьютерах сети.

3. 
   State diagram (диаграммы состояний);
   

Диаграммы состояний (State) предназначена для отображения состоя­ний объектов системы, имеющих сложную модель поведения.

4. 
   Activity diagram (диаграммы активности);
   

Это дальнейшее развитие диаграммы состояний. Фактически данный тип диаграмм может использоваться и для отражения состояний моделируемого объекта, однако, основное назначение Activity diagram не в том, чтобы отра­жать состояния, а в том, чтобы отражать бизнес-процессы объекта.

5. 
   Interaction diagram (диаграммы взаимодействия);
   

Этот тип диаграмм включает в себя диаграммы Sequence diagram (диаграммы последовательностей действий) и Collaboration diagram (диаграммы сотрудничества). Эти диаграммы позволяют с разных точек зрения рассмотреть взаимодействие объектов в создаваемой системе.

6. 
   Sequence diagram (диаграммы последовательностей действий);
   

Этот тип диаграммы не акцентирует внимание на конкретном взаимо­действии, главный акцент уделяется последовательности приема/передачи сообщений.

7. 
   Collaboration diagram (диаграммы сотрудничества);
   

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

8. 
   Class diagram (диаграммы классов);
   

Этот тип диаграмм позволяет создавать логическое представление системы, на основе которого можно генерировать исходный код описанных классов.

Значки диаграммы позволяют отображать сложную структуру систем, взаимосвязи классов (Classes) и интерфейсов (Interfaces). Данный тип диа­грамм противоположен по содержанию диаграмме Collaboration, на кото­ром отображаются объекты системы

9. 
   Component diagram (диаграммы компонент).
   

Этот тип диаграмм предназначен для распределения классов и объектов по компонентам при проектировании физической структуры системы.

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

16. 
    Основные элементы диаграммы классов. Охарактеризовать каждый из них.
    

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

Class (класс)

Класс — это установки структуры и шаблона поведения для некоторого множества реальных объектов, которые в дальнейшем будут определены в программе на основе данного шаблона. Класс — это некоторая абстракция реального мира. Когда эта абстракция принимает конкретное воплощение, она называется объектом.

Несмотря на то, что создание диаграмм классов является во многом не формализуемым процессом, можно выделить несколько основных этапов.
1 этап: Определение классов.

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

- Перечисление кандидатов в классы, найденных в постановке проблемы.

- Исключение ненужных и некорректных классов.

При выявлении кандидатов в классы выделяются все понятия (прежде всего, существительные), имеющие отношение к нашей системе.

Из списка кандидатов в классы исключаются «плохие классы» согласно следующим критериям:

а) Избыточные классы. Если два класса отражают одну и ту же информацию, то сохраняется наиболее информативное имя.

Совет:

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

б) Нерелевантные классы. Если класс не используется в решении проблемы, он должен быть исключен. Это определяется здравым смыслом, поскольку в другом контексте класс может быть важен.

в) Неясные классы. Класс должен быть характерным, специальным. Некоторые пробные классы могут иметь плохо определенные границы или быть слишком широкими.

г) Атрибуты. Имена, которые изначально описывают другие объекты, должны быть утверждены как атрибуты

Совет:

Если независимое существование свойства является важным, или свойство является сложным объектом, то делайте его классом, а не атрибутом.

д) Операции. Если имя описывает операцию, которая применяется к объектам, а не манипулирует ими с собственными правами, то это не класс.

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

Классы редко бывают изолированы, чаще всего они вступают в отноше­ния друг с другом. Эти отношения показываются при помощи различного вида связей. Типы связей влияют на получаемый при генерации на основе диаграмм исходный код.

В диаграмме классов используются следующие виды связей:

• Unidirectional association (однонаправленная ассоциация);

• Dependency (зависимость);

• Association class (ассоциированный класс);

• Generalization (наследование);

• Realization (реализация).
Unidirectional Association

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

Пример ненаправленной связи



Рис. 3.7

Пример связи

Aggregate показывает, что один класс не просто использует, а содер­жит другой.



Рис. 3.8

Пример агрегирования класса

Агрегирование означает физическое включение объектов одного класса в объекты другого класса.

Association Class (ассоциированный класс)

Используйте данный тип связи для отображения свойства ассоциации.


Рис. 3.9

Пример использования Association Class

Dependency or instantiates (зависимость или реализация)

Этот тип связи позволяет показать, что один класс использует объекты другого. Использование может осуществляться при передаче параметров или вызове операций класса. Графически этот вид связи отражается пунк­тирной стрелкой (рис. 3.10).



Рис. 3.10

Пример связи Dependency or instantiates

Generalization

Данный тип связи позволяет указать, что один класс является роди­тельским по отношению к другому, при этом будет создана связь наследова­ния класса. Пример такой связи показан на рис. 3.11.



Рис. 3.11

Пример связи Generalization

Выделение связей (ассоциаций)

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

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