The symbols we use to elaborate the Interfaces in the example above are: There is further description on symbols and stereotypes in Section: 3 - Symbols and Stereotypes on page: 33. Outlining the Plot – System View 1 The next view of the architecture (after the perspective view in Figure 5) is the first System View. We give this the highly descriptive name “System View 1”. This view takes the system presented as a black-box in the perspective view, and presents it as a white-box, exposing its implementation as a set of interconnecting modules. Figure 02 - System View 1 As we open up the implementation of “My System” essentially focusing in on its internals, we are also defocusing on the externals. In the first level decomposition are the large functional blocks of “My System” and the interfaces between them. These can be thought of as the main characters in our story. Their presence and interaction through interfaces both within the context of the system and through the boundary to the outside world is the main plot line of the architecture.
5 L LDAP Lightweight Directory Access protocol on TCP/IP 5 S SMTP Simple Mail Transfer Protocol on TCP/IP 5 N NFS Network File Share Protocol on TCP/IP 5 M Message Generic Messaging Protocol on TCP/IP (e.g. AMQP). 6 Q SQL query Structured Query Language on Database (specifically a Layer 5 protocol including access to stored procedures) 6 W Web-service XML Web Service (RPC style) with SOAP on HTTP on TCP/IP unless otherwise specified 6 T REST style Interface XML payloads transferred over HTTP following the REST specification. 7 R RSS Really Simple Syndication Protocol on HTTP with XML 7 E ETL Extract / Transform / Load – application / vendor specific protocols 0 A Native API Native API (method call / return) either in-process or out-of-process, but not crossing a device boundary 0 O Off-Line A non-connected interface (such as a manual / operational procedure that copies a file from one location to another) – used to indicate that while not connected by wires, systems are still electronically dependent on each other. 0 … Various Indicates multiple Interfaces of different types (that will be broken out in later more detailed diagrams)
If the interface requires communication connections between the client and service sides, use protocol "K" (Sockets) and provide a comment that describes the actual protocol to be used. Alternatively, you could extend the specification, adding a new standard protocol and update the standard stencil. Recommendation Details The first step is to determine whether the interface provider and consumer are to run in the same compute instance direct interaction or linked together into the same executable. If the interface between the components is a type of in-memory interface that requires no communication pathways between the two components, specify the "A" (Native) Protocol on the interface. When making this selection, it implies that these two modules are always deployed together on the same node in the Deployment Diagram. If the protocol runs over any kind of communications network, and cannot be represented by a protocol, select "K", for Socket (which implies at least a TCP/IP connection and potentially add a note to define the full protocol. What are some common errors to avoid in System Views? I am preparing set of UML component diagrams for my asset. Please describe some of the most errors in these diagrams so I can avoid them! Recommendation Common Diagramming mistakes: Using overly ambiguous or overly specific names. Inconsistent Interfaces across different system views. Specifying the interface type on connections between a given module and its internal components that handle those interfaces. Failing to specify the interface type for connections between components within the same outer module. Recommendation Details 1: Naming issues for components. One type of naming issue is simply choosing an inappropriate name for a module. For advice on this concern, please see The other major naming issue is inconsistent names across various diagrams for the same asset. In a architecture diagramming system, this is usually less of an issue because the repository retains and