В.В. Кулямин - Технологии программирования. Компонентный подход (1133554), страница 28
Текст из файла (страница 28)
Вы моглиобратить внимание на темный кружок на диаграмме деятельности на Рис. 35 — он тожеизображает начальное состояние: дело в том, что диаграммы деятельности являютсядиаграммами состояний специального рода, а деятельности — частный случай состояний.Пример диаграммы состояний приведен на Рис. 38.Состояния могут быть устроены иерархически: они могут включать в себя другиесостояния, даже целые отдельные диаграммы вложенных состояний и переходов междуними.
Пребывая в таком состоянии, система находится ровно в одном из его подсостояний.На Рис. 38 почти все изображенные состояния являются подсостояниями состояния Site.Кроме того, в нижней части диаграммы три состояния объединены, чтобы показать, чтопереход по действию cancel возможен в каждом из них и приводит в одно и то жесостояние Basket.Рисунок 38. Пример диаграммы состояний, моделирующей сайт Интернет-магазина.Состояние может декомпозироваться и на параллельные подсостояния.
Они изображаютсякак области внутри объемлющего состояния, разделенные пунктирными линиями, иханалогом на диаграммах деятельности являются дорожки. Пребывая в объемлющем89состоянии, система должна находиться одновременно в каждом из его параллельныхподсостояний.Помимо показанных на диаграмме состояний изображаемая подсистема может иметьглобальные (в ее рамках) переменные, хранящие какие-то данные. Значения этихпеременных являются общими частями всех изображаемых состояний.На Рис. 38 примерами переменных являются список видимых пользователем товаров,items, и набор уже отобранных товаров с количеством для каждого, корзина, basket.Переходы могут происходить между состояниями одного уровня, но могут также вести изнекоторого состояния в подсостояние соседнего или, наоборот, из подсостояния внекоторое состояние, находящее на том же уровне, что и объемлющее состояние.На переходе между состояниями указываются следующие данные:o Событие, приводящее к выполнению этого перехода.
Обычно событие — это вызовнекоторой операции в одном из объектов или приход некоторого сообщения, хотямогут указываться и абстрактные события.Например, из состояния Categories на Рис. 38 можно выйти, выполнив командубраузера «Назад». Она соответствует событию back, инициирующему переход всостояние Start page. Другой переход из состояния Categories происходит привыборе категории товаров пользователем. Соответствующее событие имеет параметр —выбранную категорию. Оно изображено как choose(category).o Условие выполнения (охранное условие, guardian).
Это условие, зависящее отпараметров события и текущих значений глобальных переменных, выполнениекоторого необходимо для выполнения перехода. При наступлении нужного событияпереход выполняется, только если его условие тоже выполнено.Условие перехода показывается в его метке в квадратных скобках.На Рис. 38 примером условного перехода является переход из состояния Basket всостояние Payment Method.
Он выполняется, только если пользователь выполняеткоманду «Оплатить» (событие buy) и при этом в его корзине есть хотя бы один товар.o Действие, выполняемое в дополнение к переходу между состояниями. Обычно этовызовы каких-то операций и изменения значения глобальных переменных.Действие показывается в метке перехода после слеша (символа ‘/’).
При этомизменения значений переменных перечисляются в начале, затем, после знака ‘^’,указывается вызов операции.Например, на Рис. 38 при выборе пользователем категории товаров происходит переходиз состояния Categories в Items list. При этом список товаров, видимыйпользователю, инициализируется списком товаров выбранной категории.Диаграммы состояний используются часто, хотя требуется довольно много усилий, чтобыразработать их с достаточной степенью детальности.Литература к Лекции 6[1] Л. Басс, П. Клементс, Р. Кацман.
Архитектура программного обеспечения на практике.СПб.: Питер, 2006.[2] IEEE Std 1016-1998 Recommended Practice for Software Design Descriptions.[3] IEEE 1471-2000 Recommended Practice for Architectural Description of Software-IntensiveSystems.[4] R. Kazman et al. SAAM: A Method for Analyzing the Properties of Software Architectures.Proceedings of the 16-th International Conference on Software Engineering, 1994.[5] Г. Буч, Дж. Рамбо, А. Джекобсон. Язык UML. Руководство пользователя. М.: ДМК, 2000.[6] Дж.
Рамбо, А. Якобсон, Г. Буч. UML: Специальный справочник. СПб.: Питер, 2002.[7] М. Фаулер, К. Скотт. UML в кратком изложении. М.: Мир, 1999.[8] И. Соммервилл. Инженерия программного обеспечения. М.: Вильямс, 2002.[9] Э. Дж. Брауде. Технология разработки программного обеспечения.
СПб.: Питер, 2004.90Лекция 7. Образцы проектированияАннотацияРассматривается понятие образца проектирования, классификация образцов проектирования инекоторые широко используемые примеры образцов анализа и архитектурных стилей.Ключевые словаОбразец проектирования, архитектурный стиль, идиома, образец анализа, образец организации,образец процесса, архитектурный стиль «каналы и фильтры», архитектурный стиль«многоуровневая система».Текст лекцииОбразцы человеческой деятельностиЧем отличается работа опытного проектировщика программного обеспечения от работыновичка? Имеющийся у эксперта опыт позволяет ему аккуратнее определять задачи, которыенеобходимо решить, точнее выделять среди них наиболее важные и менее значимые, четчепредставлять ограничения, в рамках которых должна работать будущая система.
Но важнее всегото, что эксперт отличается накопленными знаниями о приемлемых или не приемлемых вопределенных ситуациях решениях, о свойствах программных систем, обеспечиваемых ими, испособностью быстро подготовить качественное решение сложной проблемы, опираясь на этизнания.Давней мечтой преподавателей всех дисциплин является выделение таких знаний «в чистомвиде» и эффективная передача их следующим поколениям специалистов.
В областипроектирования сложных систем на роль такого представления накопленного опыта во второйполовине XX века стали претендовать образцы проектирования (design patterns или простоpatterns), называемые также типовыми решениями или шаблонами. Наиболее широко образцыприменяются при построении сложных систем, на которые накладывается множестворазнообразных требований. Одной из первых работ, которая систематически излагает довольнобольшой набор образцов, относящихся именно к разработке программ, стала книга [1].На основе имеющегося опыта исследователями и практиками разработки ПО выделеномножество образцов — типовых архитектур, проектных решений для отдельных подсистем имодулей или просто программистских приемов, — позволяющих получить достаточнокачественные решения типовых задач, а не изобретать каждый раз велосипед.Более того, люди, наиболее активно вовлеченные в поиск образцов проектирования в середине90-х годов прошлого века, пытались создать основанные на образцах языки, которые, хотя и былибы специфичными для определенных предметных областей, имели бы более высокий уровеньабстракции, чем обычные языки программирования.
Предполагалось, что человек, знакомый стаким языком, практически без усилий сможет создавать приложения в данной предметнойобласти, компонуя подходящие образцы нужным способом. Эту программу реализовать так и неудалось, однако выявленные образцы, несомненно, являются одним из самых значимых средствпередачи опыта проектирования сложных программных систем.Образец (pattern) представляет собой шаблон решения типовой, достаточно частовстречающейся задачи в некотором контексте, т.е. при некоторых ограничениях на ожидаемыерешения и определенном наборе требований к ним.В качестве примера рассмотрим такую ситуацию.
Мы разработали большую программу измногих модулей. Так сложилось, что почти все они опираются на некоторый выделенный модульи часто используют его операции. В какой-то момент, однако, разработчик этого модуля решилпоменять названия операций в его интерфейсе и порядок следования параметров (может быть итак, что его разработчиком является другая организация, у которой этот модуль был приобретен, итакие изменения в нем появились в очередной версии, в которой исправлены многие серьезныеошибки).
Изменить код других модулей системы достаточно тяжело, так как вызовы операций91данного модуля используются во многих местах. А если придется работать с несколькимиразными версиями — не менять же код каждый раз!Другим примером такой ситуации является разработка набора тестов для некоторых операций.Хотелось бы, чтобы с помощью этого набора можно было бы тестировать любую возможнуюреализацию функций, выполняемых этими операциями.
Если функции достаточно частовстречаются, например, совместно реализуют очередь, хранящую некоторые элементы, то такаявозможность очень полезна. Но у каждого набора операций может быть свой интерфейс,переделывать все тесты под который слишком трудоемко.Если можно представить набор требуемых операций как интерфейс некоторого класса вобъектно-ориентированном языке программирования, достойно выйти из такой ситуации поможетобразец проектирования адаптер (adapter).ClientTargetInterface+ operation1(Param1)+ operation2(Param2)+ operation3()AdapterImplementation+ operation1(Param1)+ operation2(Param2)+ operation3()+ implOp1(ImplPar1)+ implOp2(ImplPar2)+ implOp3()Рисунок 39.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
