{"id":996,"date":"2016-08-24T08:00:58","date_gmt":"2016-08-24T06:00:58","guid":{"rendered":"https:\/\/formalmind.com\/?p=996\/"},"modified":"2022-07-03T14:29:37","modified_gmt":"2022-07-03T12:29:37","slug":"uml-requirements-modeling","status":"publish","type":"post","link":"https:\/\/www.formalmind.com\/de\/blog\/uml-requirements-modeling\/","title":{"rendered":"UML-Anforderungsmodellierung - eine Einf\u00fchrung"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">For\n decades, requirements have been written primarily using natural \nlanguage. There are many good reasons for this, as we already explained \nin this series. Modeling requirements has been used in the past as well,\n but not in a standardized manner.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Modeling in the Old Days<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">Before systems modeling was standardized, people still used models. \nModels include, well, physical models, like the body of a ship\u2019s hull. \nPrototypes and mock-ups are other examples of physical models. And as \nlong as engineers can remember, models were created on paper, in the \nform of sketches, flow diagrams and the like. Some of these models were \ninformal and meant to be thrown away, others used a more formal notation\n and were maintained throughout the system development life cycle.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Unified Modeling Language<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">But the real break-through came with the development of the unified  modeling language (UML). For those who don\u2019t know it: UML is a graphical  general-purpose modeling language that covers the structural and  behavioral aspects of a system. In a nutshell, it formalizes the use of  \u201cboxes and arrows\u201d to give them a well-defined syntax and semantics.  There are plenty of <a href=\"https:\/\/encrypted.google.com\/search?hl=en&amp;q=uml+basics\" target=\"_blank\" aria-label=\" (opens in a new tab)\" rel=\"noreferrer noopener\" class=\"ek-link\">primers on UML<\/a> online.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\"><a href=\"https:\/\/en.wikipedia.org\/wiki\/Unified_Modeling_Language\" target=\"_blank\" aria-label=\" (opens in a new tab)\" rel=\"noreferrer noopener\" class=\"ek-link\">Wikipedia<\/a>  has a nice picture that shows the convergence of the various  proprietary modeling languages into a publicly standardized unified  modeling language. Being standardized and having no strings attached  allowed UML to quickly gain broad acceptance.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Before anybody complains about the formality of UML (or the lack \nthereof), I\u2019d like to point out two things: First, UML can be used as \nformally or informally as one likes (even some would sniff at the use of\n UML for mere \u201cpainting\u201d); Second, later in this series I will talk \nabout \u201creal\u201d formal languages, and how far UML can be pushed in that \ndirection.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Methods for UML Requirements Modeling<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The success of UML also has a downside: Over time, it grew into a huge behemoth, and the <a href=\"https:\/\/www.omg.org\/spec\/UML\/\" target=\"_blank\" aria-label=\" (opens in a new tab)\" rel=\"noreferrer noopener\" class=\"ek-link\">size of the standard<\/a>  (and the thickness of the UML books in the bookstore) can be  intimidating. Therefore, for any task at hand, the relevant subset of  UML should be identified.\u00a0 Also, UML is a <strong>language<\/strong>. Like the language we speak, it can be used in many different ways, good or bad, and even incorrectly. A <strong>method<\/strong> describes how the language should be applied. This typically also addresses the issue of limiting the UML elements to be used.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Many organizations develop or adapt their own methods. If nothing is \nin place yet, it\u2019s always a good idea to start with a method that is as \nclose to what\u2019s needed as possible. That method can then be adapted for \nthe organization or project in question.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Most methods use UML use cases (UC) to describe the high level \nrequirements, and UML class diagrams to describe the domain. From there,\n the model is refined to add more detail. How this looks like in \npractice is described below. But first, here are two methods (out of \nmany others available) that provide a good starting point for UML \nrequirements modeling:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li><strong>ICONIX<\/strong> is a lightweight method from the 90ies. It  promised to get from requirements to code with only four UML diagrams.  For whatever reason, it is not very widely known. I consider it very  useful for small and medium-sized software projects that are not  safety-critical. I wrote about <a href=\"https:\/\/www.se-trends.de\/iconix-methode\/\" target=\"_blank\" aria-label=\" (opens in a new tab)\" rel=\"noreferrer noopener\" class=\"ek-link\">ICONIX in SE-Trends<\/a>, my German blog.<\/li><li><strong>SYSMOD<\/strong> is more of a toolbox than a method, but it  contains a number of useful tactics for requirements modeling. A  SYSMOD-based methods has been described by Tim Weilkiens in various  books. For a good introduction I recommend the (slightly older) <a href=\"https:\/\/www.amazon.de\/gp\/search\/ref=as_li_qf_sp_sr_il_tl?ie=UTF8&amp;camp=1638&amp;creative=6742&amp;index=aps&amp;keywords=0123742749&amp;linkCode=as2&amp;tag=jastramde-21\" target=\"_blank\" aria-label=\" (opens in a new tab)\" rel=\"noreferrer noopener\" class=\"ek-link\">Systems Engineering with SysML\/UML<\/a>.<\/li><\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">UML Requirements with Use Cases and Class Diagrams<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">In UML, requirements are typically captured in Use Cases (UC). A use \ncase shows the interaction of a user with the system and can be usually \nbe captured in one sentence. E.g., \u201cAs a user, I want to log out of the \nsystem, so that nobody can access my account from this browser session\u201d.\n A use case should have an ID (e.g. \u201cLogging out\u201d). It\u2019s possible to \ndraw a picture of the use case, as shown below.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Correspondingly, the domain is modeled, replacing a traditional \nglossary. For this, UML Classes are used. These are much more precise \nthan a glossary, showing well-defined relationships between classes, \nwhich can be enriched with attributes and operations.<\/p>\n\n\n\n<figure class=\"wp-block-image aligncenter\"><img data-src=\"https:\/\/formalmind.com\/wp-content\/uploads\/2016\/08\/uml-1024x381.png\" decoding=\"async\" src=\"data:image\/gif;base64,R0lGODlhAQABAIAAAAAAAP\/\/\/yH5BAEAAAAALAAAAAABAAEAAAIBRAA7\" alt=\"\" class=\"wp-image-986 lazyload\"\/><noscript><img decoding=\"async\" src=\"https:\/\/formalmind.com\/wp-content\/uploads\/2016\/08\/uml-1024x381.png\" alt=\"\" class=\"wp-image-986\"><\/noscript><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">Please: Use it Right!<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The same way that the English language can be abused, UML can be used\n incorrectly. It is very easy to \u201cpaint\u201d something that looks right, but\n has the wrong meaning. Therefore, let me plead here: Take your time to \nunderstand the meaning behind the elements you use. Whether a line is \nsolid or dashed can make a huge difference in semantics.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Experienced users often frown when UML is \u201cjust\u201d used as a drawing. \nIn other words, when the model is not processed further. I have no \nproblem with this, if it improves communication. The biggest problem I \nsee here is that the author does not get feedback on the correct usage \nof the language.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">The Diagram is not the Model<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">At first glance, UML seems to be all about the diagrams. But if done \nright, it is a byproduct of the modeling process, albeit a useful one. \nThe diagram helps to grasp the \u201cbig picture\u201d. It serves as a map, \nhelping the reader to navigate the model. But each symbol in the diagram\n provides a lot of additional information that often has no \nrepresentation in the picture. To demonstrate this, let\u2019s look at the \nuse case. The picture only show the identifier and the relation to the \nactor. The following table shows some of the information that may be \npart of the model as well:<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td>\n<strong>UC-Name<br>\n<\/strong>\n<\/td><td>\nLogging out\n<\/td><\/tr><tr><td>\n<strong>Actors<\/strong>\n\n<\/td><td>\nAny logged in user\n<\/td><\/tr><tr><td>\n<strong>Description<\/strong>\n<\/td><td>\nAs a user, I want to log out of the system, so that nobody can access my account from this browser session.\n<\/td><\/tr><tr><td>\n<strong>Preconditions<\/strong>\n<\/td><td>\nUser is logged into the system\n<\/td><\/tr><tr><td>\n<strong>Activity<\/strong>\n<\/td><td>\n[User] initiates log out\n[System] logs the user out of the system and displays a corresponding message\n<\/td><\/tr><tr><td>\n<strong>Postconditions<\/strong>\n<\/td><td>\nUser is logged out of the system\n<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">Correspondingly, The model of the class could hold attributes, operations, constraints and much more.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Getting more Formal<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">In the example, large chunks of the model are again informal. The \npreconditions and postconditions of the use case, for instance, are \nformulated in plain text. However, just by labeling them as constraints,\n value is added. For instance, a large number of test cases can be \nderived from the model, simply by engineering appropriate test scenarios\n for all constraints.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Further, UML provides a number of mechanisms for formalizing the \nspecification. This is nicely done by ICONIX: The final product of the \nICONIX method is software code. And code is arguably a formal model that\n can be executed to provide the desired functionality. ICONIX achieves \nthis by refining the use cases into sequence diagrams (via robustness \ndiagrams), adding detail on every step. Activity diagrams and state \ndiagrams are other UML model elements that add detail and formality.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Last, there is the <a href=\"https:\/\/en.wikipedia.org\/wiki\/Object_Constraint_Language\" target=\"_blank\" aria-label=\" (opens in a new tab)\" rel=\"noreferrer noopener\" class=\"ek-link\">Object Constraint Language<\/a> (OCL), a textual language that allows some of the informal elements to be stated formally, in a machine readable fashion.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Where are the Requirements?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">One thing seems to be missing: Where are the requirements? They are  still here, but took on a different form. Specifically, many model  elements can be interpreted as requirements. For instance, they are  easily recognized in the constraints (pre-, postconditions and  invariants), but make only sense in the context of the model that they  are embedded in. Therefore, the top-level model elements, like classes  and use cases, do not directly correspond to individual requirements,  but provide the context of many embedded requirements. This is actually a  big advantage: In a textual specification, the context of the  requirements can be hard to grasp, e.g. by deducting it from the chapter  structure. In a model, however, the context is clearly defined. Again,  looking at the use case example, the precondition is only relevant in  the context of the use case \u201cLogging out\u201d. This also means that any  changes to the specification outside the use case will not affect this  precondition. This makes it easy to remove dependencies and to break  down the problem into smaller chunks that can be worked on  independently.<\/p>\n\n\n\n\n\n<h2 class=\"wp-block-heading\">What\u2019s Next?<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">It is tempting to take advantage of all the UML has to offer, \npossibly even all the way to code generation. While this is possible, it\n is advisable to introduce UML for requirements modeling in small steps.\n There are many pitfalls on the way, and trying too much in the first \nsteps can lead to failure and rejection by the stakeholders.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Having said that, UML requirements modeling is great for agile  environments, as it makes it much easier to understand and limit the  impact of changes. Therefore, I can only recommend to give it a try.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">For groups already familiar with UML requirements modeling, \nincreasing the formality can produce some benefits. It could also be \ninteresting to increase the level of formality, especially in safety \ncritical environments. We\u2019ll talk about more formal requirements \nmodeling in the near future.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">Image source (modified): <a href=\"https:\/\/www.flickr.com\/photos\/joone\/3050331298\/\" target=\"_blank\" aria-label=\" (opens in a new tab)\" rel=\"noreferrer noopener\" class=\"ek-link\">Joone via Flickr<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Seit Jahrzehnten werden Anforderungen haupts\u00e4chlich in nat\u00fcrlicher Sprache formuliert. Daf\u00fcr gibt es viele gute Gr\u00fcnde, wie wir in dieser Reihe bereits erl\u00e4utert haben. Auch in der Vergangenheit wurde Anforderungsmodellierung betrieben, aber nicht auf standardisierte Weise. Modellierung fr\u00fcher Bevor die Systemmodellierung standardisiert wurde, benutzten die Leute trotzdem Modelle. Modelle\u2026<\/p>","protected":false},"author":1,"featured_media":1635,"comment_status":"open","ping_status":"open","sticky":false,"template":"wp-custom-template-single-post-feature-image","format":"standard","meta":{"_kadence_starter_templates_imported_post":false,"_kad_post_transparent":"","_kad_post_title":"","_kad_post_layout":"","_kad_post_sidebar_id":"","_kad_post_content_style":"","_kad_post_vertical_padding":"","_kad_post_feature":"","_kad_post_feature_position":"","_kad_post_header":false,"_kad_post_footer":false,"_kad_post_classname":"","footnotes":""},"categories":[13],"tags":[48,49,50,51,52,38],"class_list":["post-996","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-iconix","tag-requirements","tag-requirements-modeling","tag-sysml","tag-sysmod","tag-uml"],"_links":{"self":[{"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/posts\/996","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/comments?post=996"}],"version-history":[{"count":0,"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/posts\/996\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/media\/1635"}],"wp:attachment":[{"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/media?parent=996"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/categories?post=996"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.formalmind.com\/de\/wp-json\/wp\/v2\/tags?post=996"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}