{"id":7114,"date":"2022-06-02T03:44:14","date_gmt":"2022-06-02T03:44:14","guid":{"rendered":"https:\/\/www.booksofall.com\/de\/?post_type=product&p=7114"},"modified":"2022-06-15T02:52:14","modified_gmt":"2022-06-15T02:52:14","slug":"advanced-uml-structural-modeling","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/de\/advanced-uml-structural-modeling\/","title":{"rendered":"Advanced UML Structural Modeling"},"content":{"rendered":"

The\u00a0Unified Modeling Language<\/b>\u00a0(UML<\/b>) is a general-purpose, developmental,\u00a0modeling language<\/a>\u00a0in the field of\u00a0software engineering<\/a>\u00a0that is intended to provide a standard way to visualize the design of a system.<\/sup><\/p>\n

The creation of UML was originally motivated by the desire to standardize the disparate notational systems and approaches to software design. It was developed at\u00a0Rational Software<\/a>\u00a0in 1994\u20131995, with further development led by them through 1996.<\/sup><\/p>\n

In 1997, UML was adopted as a standard by the\u00a0Object Management Group<\/a>\u00a0(OMG), and has been managed by this organization ever since. In 2005, UML was also published by the\u00a0International Organization for Standardization<\/a>\u00a0(ISO) as an approved ISO standard.<\/sup> Since then the standard has been periodically revised to cover the latest revision of UML.\u00a0<\/sup>In software engineering, most practitioners do not use UML, but instead produce informal hand drawn diagrams; these diagrams, however, often include elements from UML.<\/p>\n

Advanced Structural Modeling<\/h2>\n
    \n
  • A relationship is a connection among things. In object-oriented modeling, the four most important relationships are dependencies, generalizations, associations, and realizations.<\/li>\n
  • Graphically, a relationship is rendered as a path, with different kinds of lines used to distinguish the different relationships.<\/li>\n<\/ul>\n

    Dependency<\/h3>\n
      \n
    • A dependency is a using relationship, specifying that a change in the specification of one thing may affect another thing that uses it, but not necessarily the reverse. Graphically, a dependency is rendered as a dashed line<\/li>\n
    • A plain, unadorned dependency relationship is sufficient for most of the using relationships you’ll encounter. However, if you want to specify a shade of meaning, the UML defines a number of stereotypes that may be applied to dependency relationships.<\/li>\n
    • There are 17 such stereotypes, all of which can be organized into six groups.<\/li>\n
    • First, there are eight stereotypes that apply to dependency relationships among classes and objects in class diagrams.<\/li>\n<\/ul>\n
        \n
      1. bind: Specifies that the source instantiates the target template using the given actual parameters<\/li>\n
      2. derive: Specifies that the source may be computed from the target<\/li>\n
      3. friend: Specifies that the source is given special visibility into the target<\/li>\n
      4. instanceOf: Specifies that the source object is an instance of the target classifier<\/li>\n
      5. instantiate: Specifies that the source creates instances of the target<\/li>\n
      6. powertype: Specifies that the target is a powertype of the source; a powertype is a classifier whose objects are all the children of a given parent<\/li>\n
      7. refine: Specifies that the source is at a finer degree of abstraction than the target<\/li>\n
      8. use: Specifies that the semantics of the source element depends on the semantics of the public part of the target<\/li>\n<\/ol>\n

        bind:<\/strong> bind includes a list of actual arguments that map to the formal arguments of the template.<\/p>\n

        derive:<\/strong> When you want to model the relationship between two attributes or two associations, one of which is concrete and the other is conceptual.<\/p>\n

        friend:<\/strong> When you want to model relationships such as found with C++ friend classes.<\/p>\n

        instanceOf:<\/strong> When you want to model the relationship between a class and an object in the same diagram, or between a class and its metaclass.<\/p>\n

        instantiate:<\/strong> when you want to specify which element creates objects of another.<\/p>\n

        powertype:<\/strong> when you want to model classes that cover other classes, such as you’ll find when modeling databases<\/p>\n

        refine:<\/strong> when you want to model classes that are essentially the same but at different levels of abstraction.<\/p>\n

        use:<\/strong> when you want to explicitly mark a dependency as a using relationship<\/p>\n

        * There are two stereotypes that apply to dependency relationships among packages.<\/p>\n

          \n
        1. access: Specifies that the source package is granted the right to reference the elements of the target package<\/li>\n
        2. import: A kind of access that specifies that the public contents of the target package enter the flat namespace of the source, as if they had been declared in the source<\/li>\n<\/ol>\n

          * Two stereotypes apply to dependency relationships among use cases:<\/p>\n

            \n
          1. extend: Specifies that the target use case extends the behavior of the source<\/li>\n
          2. include: Specifies that the source use case explicitly incorporates the behavior of another use case at a location specified by the source<\/li>\n<\/ol>\n

            * There are three stereotypes when modeling interactions among objects.<\/p>\n

              \n
            1. become: Specifies that the target is the same object as the source but at a later point in time and with possibly different values, state, or roles<\/li>\n
            2. call: Specifies that the source operation invokes the target operation<\/li>\n
            3. copy: Specifies that the target object is an exact, but independent, copy of the source<\/li>\n<\/ol>\n

              * We’ll use become and copy when you want to show the role, state, or attribute value of one object at different points in time or space<\/p>\n

              * You’ll use call when you want to model the calling dependencies among operations.<\/p>\n

              * One stereotype you’ll encounter in the context of state machines is<\/p>\n

                \n
              1. send: Specifies that the source operation sends the target event<\/li>\n<\/ol>\n

                * We’ll use send when you want to model an operation dispatching a given event to a target object.<\/p>\n

                * The send dependency in effect lets you tie independent state machines together.<\/p>\n

                Finally, one stereotype that you’ll encounter in the context of organizing the elements of your system into subsystems and models is<\/p>\n

                  \n
                1. trace: Specifies that the target is an historical ancestor of the source<\/li>\n<\/ol>\n

                  * We’ll use trace when you want to model the relationships among elements in different models<\/p>\n","protected":false},"excerpt":{"rendered":"