Alberto Rodrigues da Silva, Dušan Savić, Siniša Vlajić, Ilija Antović, Saša Lazarević, Vojislav Stanojević, and Miloš Milić. 2015. A pattern language for use cases specification. In Proceedings of the 20th European Conference on Pattern Languages of Programs (EuroPLoP '15). ACM, New York, NY, USA, , Article 8 , 18 pages. DOI: http://dx.doi.org/10.1145/2855321.2855330

В контексте этой статьи нам будет нужно несколько специальных понятий. Начнем с понятия “паттерн”. Согласно Александру Кристоферу, “Паттерн описывает проблему, которая возникает снова и снова в производстве, а также описывает решение этой проблемы, которое можно применять в любом из этих случаях, не тратя времени на повторное его придумывание ”. Также, согласно ему же, паттерн – “одновременно явление окружающего мира и правило, которое дает нам представление, как его произвести, а также, когда нам следует сделать это. Это одновременно процесс и предмет; одновременно определение действующего предмета и определение процесса, который его произведет.” Схожее определение можно найти и у Коплина: “Паттерн - способ для создания предмета, но это также и [во многих отношениях] и сам предмет”.

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

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

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

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

В этой статье мы будем следовать упрощенному шаблону описания паттернов: название паттерна; контекст использования; решаемая задача; само решение; примеры применения; последствия применения; родственные поттерны; известные применения;

Согласно исследованиям Пола, есть два класса программных интенсивных систем:

1) информационные системы, которые собирают, хранят, меняют, передают и обрабатывают информацию; и

2) встроенные информационные системы, где программное обеспечение явяляется частью системы и сильно связано c аппаратным обеспечением.

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

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

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

(P1) Define Use Case Types

(P2) Keep Use Case Consistent with the Domain Model

(P3) Define Use Case with Different Scenario and Interaction Block Types

(P4) Define Use Case with Different Action Types

Желательно использовать эти паттерны совместно. В простых ситуациях допустимо ограничиться первыми двумя: (P1) Define Use Case Types и (P2) Keep Use Case Consistent with the Domain Model. В более сложных ситуациях следует придерживаться следующей диаграммы:

Приведем подробное описание некоторых из этих паттернов:

Define Use Case Types Pattern:

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

Решение: Сперва следует определить предопределенный набор типов юзкейзов. Большая часть этих юзкейзов может быть классифицирована или как entity-create, entity-search, entity-view, entity-update или entity-delete, или какая-то их комбинация вроде entity-manage. Мы можем определить и другие типы использования, такие как entity-browse, entity-report, entity-dashboard, entity-import, entity-export, entity-sync и другие.

Пример: на изображении показано, как каждому юзкейзу сопоставлен соотвествующий тип.

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

Похожие паттерны: Object Manager и Keep Use Case Consistent with the Domain Model.

Известные примеры использования: SilabMDD, языки XIS и XIS-Mobile.

Keep Use Case Consistent with the Domain Model Pattern

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

Задача: Юзкейз содержит как структурные элементы, так и элементы поведения. Структура юзкейзов не отделена от поведения; они пересекаются в юзкейз-процессах, используют пре- и пост-условия. Юзкейз-процессы определяеют поведения юзкейзов и в то же время прячут свою структуру. Проблема заключается в четком определении консистентности и учитывании всех юзкейзов, определенных с разной степенью детальности.

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

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

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

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

Здесь мы предлагаем несколько взаимодополняющих паттернов, которые позволяют удерживать консистентность сценариев использования и предметной области. Первый шаг к тому, чтобы сделать юзкейзы переиспользуемыми – это определение типов (create, view, update, delete, search) или определить абстрактные классы на мета-уровне абстракции.

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

1] CHRISTOPHER, A., ISHIKAWA, S., SILVERSTEIN, M., JACOBSON, M., FIKSDAHL-KING, I., ANGEL, S., A Pattern Language. Oxford University Press, New York, 1977.

[2] GAMMA, E., HELM,R., JOHNSON, R., VLISSIDES,J., Design Patterns : Elements of Reusable Object Oriented Software, Addison Wesley Professional, 1994.

[3] COPLIEN, J., Software Patterns, SIGS, 1996.

[4] BUSCHMANN F, MEUNIER R, ROHNERT H, SOMMERLAD P & STAL M., Pattern Oriented Software Architecture: A System of Patterns, John Wiley & Sons, 1996.

[5] POHL, K., Requirements Engineering - Fundamentals, Principles, and Techniques. Springer, 2010.

[6] MAHENDRA, P., & GHAZARIAN, A., Patterns in the Requirements Engineering: A Survey and Analysis Study, 2014.

[7] WITHALL, S. Software Requirements Patterns. Microsoft Press, 2007.

[8] CHENG, B., ATLEE, J. Research Directions in Requirements Engineering, Future of Software Engineering (FOSE '07), pp. 285 – 303, 2007.

[9] TOVAL, J.A., NICOLÁS, J., MOROS, B., GARCIA. F., Requirements Reuse for Improving Information Systems Security: A Practitioner's Approach, Requirements Engineering, 6(4), pp.205-219, 2002.

[10]WAHONO, R. S. , CHENG, J., Extensible Requirements Patterns of Web Application for Efficient Web Application Development, International Symposium on Cyber Worlds (CW), 2002.

[11]ROBERTSON, S., Requirements Patterns Via Events/Use Cases. PLoP, 1996.

[12]DURÁN, A., BERNÁRDEZ, B., RUÍZ, A., TORO, M., A Requirements Elicitation Approach Based in Templates and Patterns, 1999.

[13]MOROS, B., VICENTE, C., TOVAL, A., Metamodeling Variability to Enable Requirements Reuse, EMMSAD, 2008.

[14]J. YANG, L. LIU, Modeling Requirements Patterns with a Goal and PF Integrated Analysis Approach, COMPSAC, 2008.

[15]FRANCH,X., PALOMARES,C., QUER,C., RENAULT,S., LAZZER, F., A Metamodel for Software Requirement Patterns, REFSQ 2010: 85-90, 2010.

[16]ADOLPH, S., BRAMBLE, P., COCKBURN, A., POLS, A., Patterns for Effective Use Cases. Addison Wesley, 2002.

[17]OVERGAARD, G., PALMKVIST, K., Use Cases: Patterns and Blueprints. Addison Wesley, 2005.

[18]LANGLANDS, M., Inside The Oval: Use-Case Content Patterns, Technical report, Planet Project, 2010. Accessed on 2015. http://planetproject.wikidot.com/use-case-content-patterns

[19]CHUNG, L., SUPAKKUL, S. 2006.“Capturing and reusing functional and non-functional requirements knowledge: A goal- object pattern approach”, IEEE International Conference on Information Reuse and Integration (IRI).

[20]ISSA, A. A. , AL-ALI, A. 2010“Use Case Patterns Driven Requirements Engineering”, International Conference on Computer Research and Development (ICCRD)

[21]CHUNG, L., PAECH,B., ZHAO,L., LIU, L., SUPAKKUL.S. 2012., RePa Requirements Pattern Template, International Workshop on Requirements Patterns (RePa‘12)

[22] STAHL, T., VOLTER, M., Model-Driven Software Development, Wiley, 2005.

[23] SELIC, B., Personal reflections on automation, programming culture, and model-based software engineering. Automated Software Engineering, 15(3-4): 379-391, 2008.

[24] SILVA, A.R., Model-Driven Engineering: A Survey Supported by a Unified Conceptual Model, in Computer Languages, Systems & Structures, Elsevier (to be published), 2015.

[25]SILVA, A.R., VIDEIRA, C., SARAIVA, J., FERREIRA, D., SILVA, R., The ProjectIT-Studio, an integrated environment for the development of information systems, In Proc. of the 2nd Int. Conference of Innovative Views of .NET Technologies (IVNET’06), SBC and Microsoft, 2006.

[26]SILVA, A. R., SARAIVA, J., FERREIRA, D., SILVA, R., VIDEIRA, C., Integration of RE and MDE Paradigms: The ProjectIT Approach and Tools, IET Software, IET, 2007.

[27]FERREIRA, D., SILVA, A.R., A Controlled Natural Language Approach for Integrating Requirements and Model-Driven Engineering, ICSEA, 2009.

[28]SILVA, A.R., SARAIVA, J., SILVA, R., MARTINS, C., XIS – UML Profile for eXtreme Modeling Interactive Systems, in Proceedings of MOMPES'2007, IEEE Computer Society, 2007.

[29]RIBEIRO, A., SILVA, A.R., XIS-Mobile: A DSL for Mobile Applications, Proceedings of the 29th Annual ACM Symposium on Applied Computing (SAC), 2014.

[30]RIBEIRO, A., SILVA, A.R., Evaluation of XIS-Mobile, a Domain Specific Language for Mobile Application Development, Journal of Software Engineering and Applications, 7(11), pp. 906-919, Oct. 2014.

[31]SAVIĆ, D., VLAJIĆ, S., LAZAREVIĆ, S., ANTOVIĆ, I., STANOJEVIĆ, V., MILIĆ, M., SILVA, A. R., SilabMDD: A Use Case Model Driven Approach, ICIST 2015 5th International Conference on Information Society and Technology, 2015.

[32]KOSTMOD4.0 http://rapporter.ffi.no/rapporter/2009/01002.pdf, accessed in January, 2013

[33]SAVIĆ, D., SILVA, A. R., VLAJIĆ, S., LAZAREVIĆ, S., ANTOVIĆ, I., STANOJEVIĆ, V., MILIĆ, M., Use Case Specification at Different Abstraction Level, Proceedings of QUATIC’2012 Conference, IEEE Computer Society, 2012.

[34]FERREIRA, D., SILVA, A.R., RSLingo: An information extraction approach toward formal requirements specifications, Proceedings of MoDRE’2012, IEEE Computer Society, 2012.

[35]FERREIRA, D., SILVA, A.R., RSL-PL: A Linguistic Pattern Language for Documenting Software Requirements, in Proceedings of RePa’13, IEEE Computer Society, 2013.

[36]FERREIRA, D., SILVA, A.R., RSL-IL: An Interlingua for Formally Documenting Requirements, in Proceedings of MoDRE, in the 21st IEEE International Requirements Engineering Conference (RE'2013), IEEE Computer Society, 2013.

[37]JACOBSON I. ET AL. Object-Oriented Software Engineering: A Use-Case Driven Approach, Addison-Wesley1992. [38]NAKATANI, T., URAI, T., OHMURA, S., TAMAI, T., A requirements description meta-model for use cases, Eighth Asia- Pacific Software Engineering Conf. (APSEC’01), 2001.

[39]VERELST, J., SILVA, A.R., MANNAERT, H., FERREIRA, D., HUYSMANS, Identifying Combinatorial Effects in Requirements Engineering. In Proceedings of Third Enterprise Engineering Working Conference (EEWC 2013), Advances in Enterprise Engineering, LNBIP, May 2013, Springer.

[40]SILVA, A.R., VERELST, J., MANNAERT, H., FERREIRA, D., HUYSMANS, P., Towards a System Requirements Specification Template that Minimizes Combinatorial Effects, Proceedings of QUATIC’2014 Conference, IEEE Computer Society, 2014.

[41]CARAMUJO, J., SILVA, A.R., Analyzing Privacy Policies based on a Privacy-Aware Profile: the Facebook and LinkedIn case studies, Proceedings of IEEE CBI'2015, IEEE, 2015.

[42]THE STANDISH GROUP, Chaos Summary 2009 Report, The 10 Laws of Caos, 2009.

[43]Eveleens, L., Verhoef, C., The Rise and Fall of the Chaos Report Figures, IEEE Software, Jan/Feb, 2010.

[44]CRUZ, A.M., A Pattern Language for Use Case Modeling, Proceedings of MODELSWARD 2014, INSTICC Press, 2014.