UML2 и унифицированный процесс. Джим арлоуайла нейштадтпрактический объектно ориентированныйанализ и проектированиеu
 Скачать 6.08 Mb.
|
|
B XML и прецеденты B.1. Применение XML для шаблонов прецедентов Как видите, UML 2 не определяет формального стандарта для докумен тирования прецедентов. Разработчикам моделей приходится или ис пользовать возможности, предлагаемые инструментальными средства ми моделирования UML, которые нередко весьма ограничены, или применять собственный подход. В настоящий момент модель преце дентов чаще всего создается в средстве моделирования, а затем преце денты и актеры подключаются к внешним документам, содержащим их подробные описания. Эти документы обычно создаются в текстовом редакторе, однако это не лучший инструмент для решения данной за дачи. Хотя он обеспечивает возможность форматирования и структу рирования описаний прецедентов и актеров, в нем нельзя отразить се мантику этой структуры. Мы считаем, что структурированные XML документы – естественный формат описаний прецедентов. XML – это язык семантической размет ки, поэтому в нем семантическая структура документа отделена от его форматирования. Описание прецедента или актера, представленное в виде XML документа, можно трансформировать разными способами с помощью XSL [Kay 1]. Описания можно генерировать как HTML, PDF или как документы текстового редактора. Кроме того, можно делать за просы к описаниям для получения определенной информации. Структура XML документа может быть описана на языке описания XML схемы (XML Schema Definition Language, XSL). Несколько прос тых XML схем для актеров и прецедентов представлены на нашем веб сайте. Они доступны для загрузки и использования по лицензии GNU (GNU General Public License) (подробности см. по адресу www. gnu.org). XML и прецеденты 591 Подробное описание XML и XSL выходит за рамки как этой книги, так и нашего веб сайта. Однако на сайте предлагаются полезные ссылки на образовательные ресурсы по XML и XSL. Поскольку применение XML требует специальных редакторов, и заин тересованным сторонам может быть сложно его использовать, недавно нами был разработан простой подход создания прецедентов (и других документов проекта) в XML и других форматах. Он кратко обсуждает ся в следующем разделе. B.2. SUMR SUMR (произносится «саммэ») расшифровывается как Simple Use case Markup Restructured (простая реструктурированная разметка преце дентов). Это текстовый язык разметки для прецедентов. Документы SUMR без труда можно трансформировать в XML, HTML и другие фор маты. SUMR обладает целым рядом преимуществ. • Он очень прост – синтаксис разметки можно выучить за минуту. • Для него не требуются изощренные текстовые редакторы или воз можности редактирования – SUMR документы можно создавать в любом текстовом редакторе, поддерживающем простой текст. В случае необходимости SUMR текст можно вводить прямо в поле HTML формы. • Он структурированный – SUMR документы имеют схему. Можно создать собственную схему или использовать предоставляемые на ми стандартные схемы. • Он бесплатен согласно разрешению для копирования GNU (www.gnu. org/copyleft ). Чтобы вы почувствовали, что такое SUMR, на рис. B.1 приведен про стой прецедент, размеченный как SUMR документ. Синтаксис прост: все, что начинается и заканчивается двоеточиями (например, :это:), – это тег. Тело тега начинается на следующей строке после тега и продолжается до следующей пустой строки. SUMR занимается исключительно структурой и семантикой докумен та, а не его представлением. Он позволяет быстро и эффективно фик сировать важную информацию, не забивая голову форматированием, шаблонами документов или сложными языками разметки. У каждого SUMR документа может быть схема, определенная в специ альном теге :schema:. Схема SUMR – SUMR документ, определяющий теги, которые могут использоваться в других SUMR документах. На рис. B.2 показана SUMR схема нашего примера прецедента. Как види те, правильно описанные схемы SUMR могут быть самодокументируе мыми. 592 Приложение B Когда есть схема, инструменты SUMR можно использовать для: • трансформирования прецедентов, соответствующих схеме, в XML; • генерирования образцовых таблиц стилей XSL для преобразования XML в • XHTML плюс каскадная таблица стилей (Cascading Style Sheet, CSS); • XML FO (форматирующие объекты XML). Рис. B.1. Прецедент, размеченный как SUMR документ file AddItemToBasket.uc :schema: UseCase.sss :name: AddItemToBasket :id: 2 :parents: 1. None :primaryActors: 1. Customer :secondaryActors: 1. None :brief: 1. The Customer adds an item to their shopping basket. :pre: 1. The Customer is browsing products. :flow: 1. The Customer selects a product 2. The Customer selects "add item". 3. The system adds the item to the Customer's shopping basket. 4. :inc:DisplayBasket :post: 1. A product has been added to the Customer's basket. 2. The contents of the basket are displayed. :alt: 1. None :req: 1. None XML и прецеденты 593 Рис. B.2. SUMR схема прецедента file UseCase.sss :schema: UseCase.sss :name: Write the name of the use case here. Use case names are in UpperCamelCase with no spaces. :id: Write the unique project identifier for the use case here. :parents: Write the names of the parent use cases here. If this use case has no parents, write None here. :primaryActors: Write the names of the primary actors here. There must be at least one primary actor. :secondaryActors: List the names of the secondary actors here. Secondary actors participate in the use case, they do not start the use case. If there are no secondary actors, write None here. :brief: Write a brief description of your use case here. This description should be no more than a couple of paragraphs. :pre: Write the preconditions here, one on each line. If the use case has no preconditions, write None here. :flow: Write the main flow here. Each step should be time ordered and declarative. :ext:WriteExtensionPointsLikeThis Note that extension points are NOT numbered. If you need to show nested steps Indent them by one space for each level of indent like this. Include other use cases like this :inc:AnotherUseCase. This is the final step. :post: Write the postconditions here, one on each line. If there are no postconditions, write None here. :alt: List the names of the alternative flows here, one on each line. If there are no alternative flows, write None here. :req: List any special requirements related to the use case here. These are typically non functional requirements. If there are no special requirements, write None here. 594 Приложение B Инструменты SUMR генерируют стандартные таблицы стилей. Это по лезная возможность – не нужно писать таблицы стилей с нуля, доста точно только настроить их. Это также очень гибкий подход, поскольку таблицы стилей предоставляют практически полный контроль над формированием представления SUMR документов. На рис. B.3 представлен пример прецедента с рис. B.1, трансформиро ванного в XML одним из инструментов SUMR. Как только прецедент представлен в формате XML, можно использо вать сгенерированные таблицы стилей XSL для его дальнейшей транс формации. Вариант, обеспечивающий максимальную гибкость, – это трансформация XML в XML FO; после этого с помощью Apache FOP (http://xml.apache.org/fop/index.html) его можно преобразовать во мно жество других форматов вывода, включая PDF и PostScript. На рис. B.4 показан прецедент, сформированный как PDF с помощью стандартной таблицы стилей XML FO, сгенерированной из схемы. В стандартном стиле практически не на что смотреть, но его можно как угодно на строить, редактируя сгенерированную таблицу стилей, которая его описывает. И наконец, на рис. B.5 представлен простой структурированный ре дактор документов SUMR, который мы включили в набор инструмен тов. Он может проверять соответствие прецедента или актера его схе ме, имеет средства подсветки синтаксиса и автонумерации. Это заме чательный инструмент для малых и средних моделей прецедентов. Найти более подробную информацию по SUMR и загрузить инстру менты и примеры схем можно на нашем веб сайте (www.umlandtheuni fiedprocess.com ). Надеемся, вам понравится работать с этим набором инструменталь ных средств. Для нас ценен любой отзыв, который вы можете оставить на нашем веб сайте. XML и прецеденты 595 Рис. B.3. Прецедент с рис. B.1, трансформированный в XML одним из инструментов SUMR file AddItemToBasket.uc 1. None 1. Customer 1. The Customer is browsing products. 1. A product has been added to the Customer's basket. 2. The contents of the basket are displayed. 596 Приложение B Рис. B.4. Прецедент в формате PDF XML и прецеденты 597 Рис. B.5. Структурированный редактор документов SUMR Библиография [Alexander 1], «Writing Better Requirements», Ian F. Alexander, Ric hard Stevens, Ian Alexander, Addison Wesley, 2002, ISBN 0321131630. [Ambler 1], «The Unified Process Inception Phase», Scott W. Ambler, Larry L. Constantine, CMP Books, 2000, ISBN 1929629109. [Ambler 2], «The Unified Process Elaboration Phase», Scott W. Ambler, Larry L. Constantine, Roger Smith, CMP Books, 2000, ISBN 1929629052. [Ambler 3], «The Unified Process Construction Phase», Scott W. Ambler, Larry L. Constantine, CMP Books, 2000, ISBN 192962901X. [Arlow 1], «Enterprise Patterns and MDA: Building Better Software with Archetype Patterns and UML», Jim Arlow, Ila Neustadt, Addison Wes ley, 2004, ISBN 032111230X. [Booch 1], «Object Solutions», Grady Booch, Addison Wesley, 1995, ISBN 0805305947. [Booch 2], «The Unified Modeling Language User Guide», Grady Booch, Ivar Jacobson, James Rumbaugh, Addison Wesley, 1998, ISBN 0201571684. [Chomsky 1], «Syntactic Structures», Noam Chomsky, Peter Lang Publi shing, 1975, ISBN 3110154129. [Frankel 1], «Model Driven Architecture: Applying MDA to Enterprise Computing», David S. Frankel, John Wiley & Sons, 2003, ISBN 0471319201. [Gamma 1], «Design Patterns», Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison Wesley, 1995, ISBN 0201633612. 1 [Harel 1], «Modeling Reactive Systems with Statecharts: The Statemate Approach», David Harel, Michal Politi, McGraw Hill, 1998, ISBN 0070262055. 1 Э. Гамма, Р. Хелм, Р. Джонсон, Дж. Влиссидес «Приемы объектно ориен тированного проектирования. Паттерны проектирования». – Пер. с англ. – СПб.: Питер, 2007. Библиография 599 [Jacobson 1], «Unified Software Development Process», Ivar Jacobson, Grady Booch, James Rumbaugh, Addison Wesley, 1999, ISBN 0201571692. [Kay 1], «XSLT Programmer’s Reference», 2nd Edition, Michael Kay, Wrox Press Inc., 2001, ISBN 1861005067. 1 [Kleppe 1], «MDA Explained: The Model Driven Architecture – Practice and Promise», Anneke Kleppe, Jos Warmer, Wim Bast, Addison Wesley, 2001, ISBN 032119442X. [Kroll 1], «The Rational Unified Process Made Easy: A Practitioner’s Guide to Rational Unified Process», Per Kroll, Philippe Kruchten, Grady Booch, Addison Wesley, 2003, ISBN 0321166094. [Kruchten 1], «The Rational Unified Process, An Introduction», Philippe Kruchten, Addison Wesley, 2000, ISBN 0201707101. [Kruchten 2], «The 4+1 View of Architecture», Philippe Kruchten, IEEE Software, 12(6) Nov. 1995, pp. 45–50. [Leffingwell 1], «Managing Software Requirements: A Use Case Appro ach», 2nd Edition, Dean Leffingwell, Don Widrig, Addison Wesley, 2003, ISBN 032112247X. [Meyer 1], «Object Oriented Software Construction», Bertrand Meyer, Prentice Hall, 1997, ISBN 0136291554. [Mellor 1], «Agile MDA, Stephen J Mellor, MDA Journal», June 2004, www.bptrends.com. [OCL1], «Unified Modeling Language: OCL, version 2.0», www.omg.org. [Pitts 1], «XML Black Book», 2nd Edition, Natalie Pitts, Coriolis Group, 2000, ISBN 1576107833. [Rumbaugh 1], «The Unified Modeling Language Reference Manual», 2nd Edition, James Rumbaugh, Ivar Jacobson, Grady Booch, Addison Wesley, 2004, ISBN 0321245628. [Standish 1], «The CHAOS Report (1994)», The Standish Group, www.standishgroup.com/sample_research/chaos_1994_1.php [UML2S], «Unified Modeling Language: Superstructure, version 2.0», www.omg.org [Warmer 1], «The Object Constraint Language: Getting Your Models Rea dy for MDA», Jos Warmer, Anneke Kleppe, Addison Wesley, 2003, ISBN 0321179366. 1 Майкл Кэй «XSLT. Справочник программиста», 2 е издание. – Пер. с англ. – СПб.: Символ Плюс, 2002. Алфавитный указатель Символы :, двоеточие, в именах множество всех типов, 244 действие, 318 объект, 154 пакет, 252 , запятая, для действий, 318 *, звездочка на коммуникационных диаграммах, 290, 292 >, знак больше чем для операций сравнения OCL, 538 для сравнения коллекций, 547 для типа Boolean, 540 <, знак меньше чем для операций сравнения OCL, 538 для сравнения коллекций, 547 для типа Boolean, 540 –, знак минус для обозначения видимости, 161 +, знак плюс для обозначения видимости, 161 =, знак равенства для операций сравнения OCL, 538 для сравнения коллекций, 547 для строк, 542 для типа Boolean, 540 #, знак числа для обозначения видимости, 161 (), скобки, для обозначения старшинства операций, 537 /, слеш, для комментариев, 536 ; точка с запятой, для действий, 484 А «access», стереотип, 224, 254, 256 alt, оператор, 283 ветвление, 284, 287 с точками продолжения, 308 and, оператор, 540 AndroMDA, инструмент, 29 any, оператор, 552 append, оператор, 550 ArcStyler, инструмент, 29 «artifact», стереотип, 520 assert, оператор, 284 B «bind», стереотип, 384, 386 «boundary», стереотип, 191 break, оператор организация итерации, 287, 290, 291 семантика, 283 «buildComponent», стереотип, 435 C «call», стереотип, 222 CBD (компонентно ориентированная разработка), 431 «centralBuffer», стереотип, 330 CIM (машинно независимые модели), 28 collect, оператор для итераторов, 552 для коллекций, 557 collectNested, оператор для итераторов, 552 для коллекций, 558 {complete}, ограничение, 241 concat, оператор, 541 consider, оператор, 284 «control», стереотип, 192, 193 count, оператор, 547 CRC анализ, выявление классов, 188– 190 «create», стереотип, 273 critical, оператор, 283 D «decisionInput», стереотип, 325 Алфавитный указатель 601 «deployment spec», стереотип, 520 «derive», стереотип, 224 «destroy», стереотип, 273 «device», стереотип, 515 «directory», стереотип, 521 {disjoint}, ограничение, 241 «document», стереотип, 520 DOORS, инструмент, 78, 79, 114 E Eclipse Modeling Framework, 29 «EJB», стереотип, 521 Enterprise JavaBeans (EJB), 432 «entity», стереотип, 193, 435 excludes, оператор, 548 excludesAll, оператор, 548 excluding, оператор, 550 «executable», стереотип, 520 «execution environment», стереотип, 515 exists, оператор, 551 «extend», стереотип, 127, 130 несколько сегментов вставки, 131, 132 условный, 132 характеристики, 127, 130 «external», стереотип, 319 F FIFO (first in, first out) буферы, 330 «file», стереотип, 520 flatten, оператор, 546 for, цикл, 107, 289 forAll, оператор, 552 forEach, оператор, 289 «framework», стереотип, 251 H HashMap, класс, 405 hasReturned, оператор, 577 I Identity, свойство, 149 ignore, оператор, 284 «implementation», стереотип, 435 implies, оператор, 540 «import», зависимости, 225, 254 «include», стереотип, 126, 128 includes, оператор, 547 includesAll, оператор, 548 including, оператор, 550 {incomplete}, ограничение, 241 insertAt, оператор, 550 «instantiate», стереотип, 157, 223 internal, видимость, 162 isEmpty, оператор, 548 isOperationCall, оператор, 577 isSignalSent, оператор, 577 isUnique, оператор, 552 iterate, оператор, 554 iUML, инструмент, 29 J JAR файлы (Java архив), 432 стереотип «JAR», 521 «JavaClassFile», стереотип, 521 «JavaSourceFile», стереотип, 521 JMechanic для Java, инструмент, 377 L «library», стереотип, 520 LIFO (last in, first out) буферы, 330 M «manifest», отношение, 509 MDA (архитектура, управляемая моделью), 27, 29 «merge», стереотип, 255 «modelLibrary», стереотип, 251 MoSCoW, критерии, 81, 82 N neg, оператор, 284 not, оператор, 540 O Objectory, 51 OCL (объектный язык ограничений) в автоматах, 572 выражения, 531 контекст пакета и составные имена, 533 краткий обзор, 583 на диаграммах взаимодействий, 569 на диаграммах деятельностей, 570 навигация, 559 602 Алфавитный указатель в рамках экземпляров контекста, 555 к и от классов ассоциаций, 574 по ассоциациям, 559 по квалифицированным ассоциациям, 575 преимущества, 530 унаследованные ассоциации, 576 характеристики, 529 OMT (Object Modeling Technique –техни ка объектного моделирования), 25 one, оператор, 552 opt, оператор, 283, 287 or, оператор, 540 {overlapping}, ограничение, 241 |