Blocks & Block Definition Diagrams can help convey internal and external interaction.
Blocks are the foundation of the structural architecture and defining characteristics of system elements.
Block Definition Diagrams define the features of a block and any relationships between blocks such as associations, generalizations, and dependencies, in terms of properties, operations, and relationships. A few types of Block Definition Diagrams are:
- Association Diagrams
- Conceptual Operation Diagrams
- Domain Diagrams
Blocks and Block Definition Diagrams: Key Elements
On a Block Diagram, the primary elements that are leveraged are System Blocks, Subsystem Blocks, Domain Blocks, or Blocks. Understanding when and where to use each of these elements is key for developing comprehensive use case diagrams.
System
A System consists of blocks that pursue a common goal which cannot be achieved by the system‘s individual elements.
Subsystem
A Subsystem is typically a large, encapsulated block within a larger system.
Domain
A Domain represents an entity, a concept, a location, or a person from the real-world domain.
External
An External block represents an actor. It facilitates a more detailed modeling of actors like ports or internal structures.
Block
A Block is a modular unit that describes the structure of a system or element. It may include both structural and behavioral features, such as properties and operations, that represent the state of the system and behavior that the system may exhibit.
Blocks & Block Definition Diagrams
Blocks and Block Definition Diagrams: Relationships
On a Block Diagrams, External Blocks, Actors, and Domains may interact directly with the system of interest. The relationships created between these elements are associations and or composition relationships, indicating element interaction and hierarchy.
Association
An Association is a weak relationship, which conveys that an interaction can exist between the connected blocks.
Directed Association
A Directed Association is a weak relationship between blocks, which implies that an interaction between the blocks occurs primarily in one direction.
Association Block
An Association Block is essentially an association but with the ability to have its own property information.
Composition
A Composition is a weak relationship, which conveys that an interaction can exist between the connected blocks.
Directed Composition
A Directed Composition is a weak relationship between blocks, which implies that an interaction between the blocks occurs primarily in one direction.
Types of Block Diagrams
Domain Diagram
As mentioned previously, clearly defining the external influencers of your system will help scope the level of effort for developing/detailing the interactions your system will come across. Domain diagrams serve as a means of looking at external influencers of a system. The main line of thought that you should have when
developing these diagrams are what are the main environments my system will be operating within and what impact could it see.
External & Internal Conceptual Operation Diagram
External Conceptual Operation diagrams are similar in the fact that they both are looking at external influencers of a system, however these diagrams concentrate more on the intended interactions that are likely to occur.
Conceptual Operation diagrams and Association diagrams help force discussions on the interactions and responses a system could have with its external influencers, as well as its internal elements. Even though these diagrams are fairly simple to develop, there is often deep thought that has to occur to clearly show the systems interactions comprehensively.
Internal Association Diagram
One best practice is the use of both Actors and Blocks to represent external users throughout this training. This deviation from actors in some cases is due to the fact that blocks allow more traceability through its attributes than actors. If the traceability to the impacted attributes are not desired, the utilization of actors is preferred.
Pingback: Internal Block Diagrams - Beyond MBSE
Pingback: Should I Use a Component Model Element? - Beyond MBSE
Pingback: Model Organization - Beyond MBSE
Pingback: Implementing Use Cases - Beyond MBSE
Pingback: Block - Beyond MBSE
Pingback: Hierarchal Structures - Beyond MBSE
Pingback: Actor - Beyond MBSE