Differences

This shows you the differences between two versions of the page.

--- mdd:patterns [2016/12/25 16:07] – aliakseisemchankau
+++ mdd:patterns [2026/08/29 07:59] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
+====== A Pattern Language for Use Cases	Specification ======
+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
+====== Введение ======
+В контексте этой статьи нам будет нужно несколько специальных понятий.
+Начнем с понятия "паттерн". Согласно Александру Кристоферу, "Паттерн описывает проблему, которая возникает
+снова и  снова в производстве, а также описывает решение этой проблемы, которое
+можно применять в любом из этих случаях, не тратя времени на повторное его
+придумывание ". Также, согласно ему же, паттерн -- "одновременно явление окружающего мира и правило, которое дает нам представление, как его произвести, а также, когда нам следует сделать это. Это одновременно процесс и предмет; одновременно определение действующего предмета  и определение процесса, который его произведет." Схожее определение можно найти и у Коплина: "Паттерн - способ для создания предмета, но это также и [во многих отношениях] и сам предмет".
+На текущий момент повсеместно используются техники из книги "Дизайн паттернов: элементы переиспользуемого объектно-ориентированного обеспечения." Дизайн паттернов считается стандартным решением, которое может быть применено множество раз в различных задачах и ситуациях. К тому же, они дают большую гибкость в разработке.
+Анализ требований -- это часть разработки обеспечения, которая обычно включает две части: спецификация и обработка требований и менеджмент требований. Не обнаруженные вовремя шибки, допущенные при анализе требований, могут быть крайне дорогостоящими.
+Также, мы введем термин "паттерн требований" -- его можно определить, как "инструкцию для написания определенного вида требований", или "переиспользуемый фреймворке (основанный на опыте), который задает качество требования за минимальное необходимое время".
+Есть разные способы представления паттернов требований. В общем и целом, они следуют следующему шаблону: название; автор; задача, которую он решает; контекст, в котором он используется; описание последствий применения; само решение; применимость, показывающая, когда и где паттерн может быть применен; классификация; ссылки на известные применения; примеры применения; а также ссылки на схожие паттерны;
+В этой статье мы будем следовать упрощенному шаблону описания паттернов: название паттерна; контекст использования; решаемая задача; само решение; примеры применения; последствия применения; родственные поттерны; известные применения;
+====== Основная часть: ======
+Согласно исследованиям Пола, есть два класса программных интенсивных систем:
+)// информационные системы//, которые собирают, хранят, меняют, передают и обрабатывают информацию; и
+) //встроенные информационные системы//, где программное обеспечение явяляется частью системы и сильно связано 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. В более сложных ситуациях следует придерживаться следующей диаграммы:
+{{ :mdd:деаграма_патернаф.png |}}
+ Приведем подробное описание некоторых из этих паттернов:
+**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 и другие.
+**Пример**: на изображении показано, как каждому юзкейзу сопоставлен соотвествующий тип.
+{{ :mdd:первый_паттерн.png |}}
+**Последствия**: Как результат, все юзкейзы приобретут четкую и ясную классификацию по типа. Это первый шаг для того, чтобы быть уверенными в консистентности юзкейза и модели и создать затем интерактивные блоки.
+**Похожие паттерны**: Object Manager и Keep Use Case Consistent with the Domain Model.
+**Известные примеры использования:** SilabMDD, языки XIS и XIS-Mobile.
+**Keep Use Case Consistent with the Domain Model Pattern**
+**Контекст**: Юзкейзы используются для идентификации и спецификации функциональных требований. С другой стороны, предметная область представляет фундамент для понимания основной проблемы и ясного понимания главных концепций изучаемой системы. Следвательно, это хорошая практика, когда мы определяем предметную область для лучшей поддержки системных требований спецификации.
+**Задача:** Юзкейз содержит как структурные элементы, так и элементы поведения. Структура юзкейзов не отделена от поведения; они пересекаются в юзкейз-процессах,  используют пре- и пост-условия. Юзкейз-процессы определяеют поведения юзкейзов и в то же время прячут свою структуру. Проблема заключается в четком определении консистентности и учитывании всех юзкейзов,  определенных с разной степенью детальности.
+**Решение:** Чтобы убедиться в консистентности между юзкейзами и предметной областью, каждая часть юзкейза должна быть связана с сущностями, определенными в предметной области. Каждый юзкейзд должен быть связан ровно с одной предметной сущностью, то есть, поведение строго определено через эту сущность из предметной области. Это значит, что все сущности, на которые ссылается какой-либо юзкейз должны быть связаны с ним. Вообще говоря, все, что специфицированы в юзкейзах, должно следовать этим правилам.
+**Пример :** на изображении можно видеть юзкейзную модель, где каждый юзкейз категоризован соответствующим типом и соотнесен с соотвествующей сущностью из предметной области.
+{{ :mdd:второй_паттерн.png |}}
+**Следствие:** как результат применения данного паттерна мы сохраняем коинсистентность между юзкейзами и привлеченной предметной областью. Также, этот паттерн приводит к тому, что получившиеся юзкейзы становятся более тщательно определенными. и могут быть быть использованы в различных контекстах.
+====== Заключение ======
+Чтобы создать спецификации к информационной системе, обладающие высоким качеством, надо постоянно проверять их на консистентность, полноту и правильность. Проверка требований, основанных на сценариях использования, написанная на обычном языке -- очень сложная задача. Написание юзкейзов может быть усовершенствовано различными техниками и паттернами, например теми, что описаны в этой статье.
+Здесь мы предлагаем несколько взаимодополняющих паттернов, которые позволяют удерживать консистентность сценариев использования и предметной области. Первый шаг к тому, чтобы сделать юзкейзы переиспользуемыми -- это определение типов (create, view, update, delete, search) или определить абстрактные классы на мета-уровне абстракции.
+Спецификации и язык, изложенные в этой сатье, уже поддержаны некоторыми инструментами, которые можно найти в сообществе.
+====== Ссылки ======
+] 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.
+– 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.