Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Введение в программную инженерию. Учебное пособие-1
.pdf
Д.В. Кознов
Введение в программную инженерию
51
каждом конкретном случае своя. Важнейшими характеристиками точки
зрения моделирования является цель (зачем создается модель) и целевая
аудитория (то есть, для кого она предназначается).
Важным вопросом, на который нужно честно себе ответить в самом
начале моделирования — это зачем вы используйте диаграммы (в
частности, UML). Это и есть определение цели моделирования.
Потому, что так создавать модели правильно, нужно? И все проблемы
(даже те, о которых ничего еще не известно) волшебным образом
исчезнут, развеются? Очень часто, например, при создании модели
случаев использования присутствует именно такая «цель»
моделирования. А потом оказывается, что никакие проблемы не
«вылечились», а наоборот, возникли новые (например, созданные нами
диаграммы никто не понимает и не принимает). Да и сам аналитик
чувствует, что диаграммы получились какие-то странные….
А может все происходить совсем не так. Например, аналитик
действительно задался целью выявить требования к системе — не
навязать свое собственное видение другим, а выяснить нужную
информацию, смоделировать и изложить ее доступно. Для этого он и
использует диаграммы случаев использования. Ему важно, чтобы
будущие пользователи системы могли участвовать в этом процессе,
диаграммы рисуются для них, они понятны и не избыточны. И эти же
диаграммы структурируют и проясняют информацию для самого
аналитика.
Подобных сюжетов на практике происходит множество. Тут важно
понимать, что цель модели — это не какая-то гипотетическая задача
типа «описания архитектуры, потому что так нужно, так правильно», а
целевая аудитория — это не абстракция типа «люди, желающие
познакомиться с ПО». И то и другое — что-то очень конкретное,
реально существующее в проекте или рядом с ним. Ведь разработчики
ПО не могут позволить себе за деньги заказчика создавать нечто на все
века и для всех народов. И цель моделирования, и аудитория, которая
будет работать с диаграммами, всегда существуют, важно лишь ясно
понимать, какие они…
Вот полезный практический прием подготовки создаваемой модели с
ориентацией на целевую аудиторию. Можно выбрать одного
представителя такой аудитории — конкретного и известного вам
Д.В. Кознов
Введение в программную инженерию
52
человека — и создавать диаграммы, понятные именно ему. При этом
важно не обсуждать чрезмерно с ним ваши модели, поскольку это
может создать дополнительный контекст, которого другие
пользователи моделей будут лишены. Полезно представлять
воображать себе этого человека при работе над моделями — его
реакции, вопросы, недоумения и пр. И, исходя из этого,
корректировать, исправлять созданное. И, конечно же, полезно
проверить свои предположения, показав ему, что получилось.
Кроме того, важно, чтобы точка зрения была «живая», а не
выдумывалась аналитиком или бездумно копировалась из книжек и
тренингов, посвященных UML. Незаметно для себя аналитик может
придумать свой собственный проект, своих собственных пользователей
системы, заказчика и т.д. То есть аналитик исподволь, навязывает
самому себе определенное восприятие реально существующих людей,
задач, сильно искажая реальное положение дел. И именно в контексте
этой воображаемой ситуации он создает свои модели. Но ведь
реальные люди, реальные ситуации обладают своеобразием, большим
диапазоном вариативности. Соответственно, аналитик должен обладать
гибкостью сознания, большим диапазоном техник, а также чуткостью и
искренним стремлением к тому, чтобы сделать каждый конкретный
проект, где он участвует, более гармоничным, более адекватным.
Язык UML
Часто понятие архитектуры сильно сужают, понимая под ним лишь
описание основных, важных аспектов ПО, создаваемых, например,
архитектором при разработке дизайна системы. Для этих целей
используется язык моделирования UML (Unified Modeling Language).
Этот язык является итогом развития средств визуального
моделирования, т.е. схематического описания программных систем,
которые развивались с блок-схем, предложенных еще фон Нейманом в
конце 40-х годов. Предполагалось, что блок-схемы станут
высокоуровневым языком ввода алгоритмов в вычислительные
машины, но эволюция языков программирования пошла по пути
текстовых языков. Тем не менее блок-схемы получили распространение
при спецификации и документировании ПО, были стандартизованы,
однако широкого практического применения не получили.
Д.В. Кознов
Введение в программную инженерию
53
В конце 60-х годов, в связи с поиском новых средств разработки ПО,
рождением программной инженерии и общими следованиями в области
проектирования и разработки искусственных систем появился термин
структурный анализ (structured analysis) систем. Термин был введен
ученым из MIT, Дугласом Россом, который также предложил
диаграммный метод анализа и проектирования больших искусственных
систем. Метод назывался SADT (Structured Analisys and Desing
Technique), стал основой серии военных стандартов США серии IDEF и
широко распространился в индустрии. Однако диаграммный язык в
SADT был очень скромным — набор блоков и связей между ними, с
поддержкой декомпозиции блоков.
В 70-х годах, в связи с массовым выходом ПО на свободный рынок (то
есть системы стали создаваться не только в военной области, для
крупного бизнеса, но также для среднего и малого бизнеса)
структурный анализ стал бурно эволюционизировать — набор
диаграмм обогатился диаграммами состояний и переходов, сущностьсвязь, потоков данных и т.д. С развитием объектно-ориентированных
средств разработки (конец 80-х — середина 90-х) структурный анализ
превратился в объектно-ориентированный анализ и проектирование.
Появилось большое количество методологий, и постепенно сложился
единый язык моделирования, который и был закреплен в стандарте
UML. Произошло это в 1997 году. С тех пор вышло несколько версий
стандарта UML.
Рассмотрим виды диаграмм UML. «Скелетом» UML является
диаграммная структура. Каждый вид диаграмм является типом
моделей, реализующим определенную точку зрения на программную
систему. Виды диаграмм не являются строго обязательными в UML —
их можно перемешивать, создавать свои собственные виды диаграмм.
Тем не менее стандартные виды диаграмм являются определенным
достоянием программной инженерии, так как отражают опыт многих
исследователей и практиков.
• Структурные диаграммы:
- диаграммы классов (class diagrams) предназначены для
моделирования структуры объектно-ориентированных
приложений классов, их атрибутов и заголовков методов,
наследования, а также связей классов друг с другом;
Д.В. Кознов
Введение в программную инженерию
54
- диаграммы компонент (component diagrams) используются
при моделировании компонентной структуры
распределенных приложений; внутри каждая компонента
может быть реализована с помощью множества классов;
- диаграммы объектов (object diagrams) применяются для
моделирования фрагментов работающей системы,
отображая реально существующие в runtime экземпляры
классов и значения их атрибутов;
- диаграммы композитных структур (composite structure
diagrams) используются для моделирования составных
структурных элементов моделей — коопераций,
композитных компонент и т.д.;
- диаграммы развертывания (deployment diagrams)
предназначены для моделирования аппаратной части
системы, с которой ПО непосредственно связано
(размещено или взаимодействует);
- диаграммы пакетов (package diagrams) служат для
разбиения объемных моделей на составные части, а также
(традиционно) для группировки классов моделируемого
ПО, когда их слишком много.
• Поведенческие диаграммы:
- диаграммы активностей (activity diagrams) используются
для спецификации бизнес-процессов, которые должно
автоматизировать разрабатываемое ПО, а также для
задания сложных алгоритмов;
- диаграммы случаев использования (use case diagrams)
предназначены для «вытягивания» требований из
пользователей, заказчика и экспертов предметной области;
- диаграммы конечных автоматов (state machine diagram)
применяются для задания поведения реактивных систем;
- диаграммы взаимодействий (interaction diagram):
▪ диаграммы последовательностей (sequence diagram)
используются для моделирования временных
аспектов внутренних и внешних протоколов ПО;
▪ диаграммы схем взаимодействия (interaction
overview diagram) служат для организации иерархии
диаграмм последовательностей;
▪ диаграммы коммуникаций (communication diagrams)
являются аналогом диаграмм последовательностей,
Д.В. Кознов
Введение в программную инженерию
55
но по-другому изображаются (в привычной,
графовой, манере);
- временные диаграммы (timing diagrams) являются
разновидностью диаграмм последовательностей и
позволяют в наглядной форме показывать внутреннюю
динамику взаимодействия некоторого набора компонент
системы.
Рассмотрим примеры. Центральным видом диаграмм являются
диаграммы классов. Пример представлен на рис. 4.3.
Start() : void
Stop() : void
CPBX_Agent
IncomingCall(in COpID) : void
ReceiveMessage(in CMessage) : void
CDispatcher
GetID() : COpID
ID : COpID
COperator
Get(in COpID) : COperator
GetFree() : void
COperatorList
SetConnection() : void
FreeConnection() : void
SendMessage(in : CMessage) : int
CServerNetworkConnectionSupport
1
1
1
0..1
1
1
0..1
0..1
CSubOperator
0..*
0..*
Рис. 4.3. Пример диаграмм классов
Еще один вид структурных диаграмм — диаграммы размещений,
пример представлен ниже.
Телефонный
аппарат
PBX
Клиентский
компьютер
Сервер
запросов
Локальная
телефонная сеть
Локальная
компьютерная сеть
1*
1
*
Рис. 4.4. Пример диаграмм размещений
Отметим также еще один важный вид диаграмм UML — диаграммы
Д.В. Кознов
Введение в программную инженерию
56
компонент (пример представлен на рис. 4.5).
ClientNetworkSupport
ServerNetworkSupport
ClientGUI
ICNSupport_GUI
INetwort
IGUI
INetwort
RequestDB
ServerBusinessLogic
ISNSupport_BL
ISNSupport_BL
IServerBL_ReqDB
IServerBL_ReqDB
Компонента
Предоставление
интерфейса
Потребность в
интерфейсе
Рис. 4.5. Пример диаграмм компонент
Интересен также вариант диаграмм композитных структур — сложные
компоненты для систем реального времени и телекоммуникаций.
Пример представлен ниже.
Д.В. Кознов
Введение в программную инженерию
57
СистемныйблокТРС
:МатеринскаяПлатаТРС
ПамятьТРС
:Микросхемы
Памяти [2..8]
:CD-устройство
[0..1]
:Винчестер
:СетеваяКарта
:ВидеоКарта
ПроцессорТРС :Pentium4
VGA
220В
Рис. 4.6. Пример диаграмм композитных структур
Ниже приводятся примеры на поведенческие диаграммы UML.
Диаграммы конечных автоматов позволяют создавать полные
спецификации поведения телекоммуникационных, событийно-
управляемых алгоритмов и автоматически генерировать по этим
описаниям программный код. Пример такой диаграммы для класса
COperator представлена ниже.
Disconnect
[counter =5]
Connected
RequestToConnection/
RequestToConnection()
Connection errors,
TimeoutT12
Terminate
Idle
exit:startT12
Connected
entry/ counter = 0
Disconnect [counter<5]/ counter +=1
WaitingForConnection
Д.В. Кознов
Введение в программную инженерию
58
Рис. 4.7. Пример диаграмм конечных автоматов
Еще один важный вид диаграмм — диаграммы последовательностей.
Они позволяют задавать главные ветки сложных
телекоммуникационных алгоритмов, а также рисовать цепочки вызовов
для объектно-ориентированных приложениях, которые
программируются в терминах объектов, но проектируются часто в
терминах цепочек вызовов. Пример представлен ниже.
:Оператор
:Тел. Аппарат
:Клиентское ПО :ПО сервера
Звонок
Появилась форма с запросом
Вопросы клиента
Причины звонка
Протоколирование
Ответы клиенту
Протоколирование
Рис. 4.8. Пример диаграмм последовательностей
Временные диаграммы предназначаются для наглядного изображения
потока изменения состояний нескольких классов или компонент
системы. Последние изображаются не вертикально, а горизонтально, и
основной упор в этих диаграммах делается на наглядном изображении
их состояний, точнее, того, как эти состояния меняются во времени.
Пример представлен на рис. 4.9.
Д.В. Кознов
Введение в программную инженерию
59
Рис. 4.9. Пример временной диаграммы
Литература
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 с.: ил. — (Серия «Основы
информационных технологий»).
Д.В. Кознов
Введение в программную инженерию
60
Лекция 5. Управление требованиями
Проблема
Например, строители строят дома, пусть разные: многоэтажные,
отдельные коттеджи, офисные здания и пр. — однако, весь этот спектр
вполне может охватить одна компания. Но все это дома. Строительной
компании не приходится строить летающую тарелку, гиперболоид
инженера Гарина, луноход, систему мгновенной телепартации и пр. А
разработчики ПО, во многом, находятся именно в таком положении.
Велико разнообразие систем, которые создает одна компания, одна
команда. Хотя сейчас и намечаются тенденции к специализации рынка
разработки ПО, однако, причуды мировой экономики и многие другие
причины приводят к тому, что строго специализированных компаний
не так много, как хотелось бы. Многие области испытывают большой
дефицит отдельных программистов и целых коллективов и компаний,
хорошо разбирающихся в их специфики. Примером такой области
может служить телевидение, где о данной проблеме открыто говорят на
заседаниях различных международных сообществ.
Кроме того, ПО продолжает проникать во все новые и новые области
человеческой деятельности, и сформулировать адекватные требования
в этом случае вообще оказывается супертрудной задачей.
Но даже если речь идет об одной, определенной области, то процент
новых, уникальных черт систем, принадлежащих этой области, высок:
по сочетанию пользовательских характеристик, по особенностям среды
исполнения и требованиям к интеграции, по распределенности
информации о требованиях среди работников компании-заказчика. Все
это несет на себе очень большой отпечаток индивидуальности
заказчика — персональной или его компании, — сильно связано со
спецификой его бизнеса, используемого в этой области оборудования.
Кроме того, существуют трудности в понимании между заказчиком и
программистами, а еще — в изменчивости ПО (требования имеют
тенденцию меняться в ходе разработки).
В итоге, далеко не очевидно, что та система, которую хочет заказчик,
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]