Материал: ВВПИ. Лекции

Еще один вид структурных диаграмм – диаграммы размещений, пример представлен ниже.

*1

Рис. 4.4. Пример диаграмм размещений.

Отметим также еще один важный вид диаграмм UML – диаграммы компонент (пример представлен на рис. 4.5).

Рис. 4.5. Пример диаграмм компонент.

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

Рис. 4.6. Пример диаграмм композитных структур.

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

Рис. 4.7. Пример диаграмм конечных автоматов.

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

27

Рис. 4.8. Пример диаграмм последовательностей.

Литература

1.UML 2.1 Infrastructure Specification, September, 2006, http://www.omg.org/.

2.Kruchten P. The 4+1 View Model of Architecture. IEEE Software, 1995, 12(6), P. 42-50.

3.Буч Г., Якобсон А., Рамбо Дж. UML. Изд. 2-е. / Пер. с англ. СПб.: Питер, 2006, 735 с.

4.Д. В.Кознов. Основы визуального моделирования / Д. В. Кознов. – М: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. – 248 с.: ил. – (Серия «Основы информационных технологий»).

28

Лекция 5. Управление требованиями

Проблема

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

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

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

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

Кроме того, существуют трудности в понимании между заказчиком и программистами, а еще – в изменчивости ПО (требования имеют тенденцию меняться в ходе разработки).

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

Ошибки и разночтения, которые возникают при выявлении требований к системе, оказываются одними из самых дорогих. Требования – это то исходное понимание задачи разработчиками, которое является основой всей разработки.

Несколько слов о трудности взаимопонимания заказчика и разработчиков. Здесь сказывается большой разрыв между программистами и другими людьми. Во-первых, потому, что чтобы хорошо разобраться, какой должна быть система автоматизации больницы и система поддержки химических экспериментов – надо поработать в соответствующей области достаточное время. Или как-то иным способом научиться видеть проблемы данной предметной области изнутри. Во-вторых, сказывается специфичность программирования как сферы деятельности. Для большинства пользователей и заказчиков крайне не просто сформулировать точное знание, которое необходимо программистам. На вопрос, сколько типов анализов существует в вашей лаборатории, доктор, подумав, отвечает - 43. И уже потом, случайно, программист уточнил, а нет ли других типов? Конечно, есть, ответил доктор, только они случаются редко и могут быть в некотором смысле, какими угодно. В первый же раз он назвал лишь типовые. Но, конечно же, информационная система должна хранить информацию обо всех анализах, проведенных в лаборатории….

29

Теперь чуть подробнее об изменчивости ПО и его причинах.

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

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

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

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

Виды и свойства требований

Разделим требования на две большие группы – функциональные и

сервисов системы, ее функционала. Они определяют то, что система должна уметь делать. Нефункциональные требования не являются описанием функций системы. Этот вид требований описывает такие характеристики системы, как надежность, особенности поставки (наличие инсталлятора, документации), определенный уровень качества (например, для новой Java-машины это будет означать, что она удовлетворяет набору тестов, поддерживаемому компанией Sun). Сюда же могут относиться требования на средства и процесс разработки системы, требования к переносимости, соответствию стандартам и т.д. Требования этого вида часто относятся ко всей системе в целом. На практике, особенно начинающие специалисты, часто забывают про некоторые важные

нефункциональные требования.

Сформулируем ряд важных свойств требований.

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

Полнота и непротиворечивость.

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

30