I would like to know what is the difference between attributes and service in GATT in BLE specification, and where we can find attributes, are they in service, characteristics or in descriptors?
In summary ... services, characteristics, and descriptors ... are attributes :-)
The BLE standard provides the ATT protocol that defines the concept of attributes. All attributes are defined inside a table and they have a handle, a type (with a UUID), a value (and permissions).
On top of ATT protocol in the BLE stack, you have GATT and GAP. The GATT protocol defines services, characteristics, and descriptors and each of them is an attribute.
For example, a characteristic is an attribute with a handle, a type (a UUID that tells us that the attribute is a characteristic) and a value (the characteristic properties with a handle to the attribute value and so on). Inside the characteristic, you have an attribute that is the value of the characteristic and one or more descriptors that are themselves attributes.
You can see the attribute concept as the abstract type you can define concrete types like service, characteristic and descriptors.
I can suggest seeing the following video (intro on BLE) by Nordic.
Related
I can't find what are the differences between the ports on these interfaces. What's the difference in action?
The symbols in the ports (squares) are obviously customer specific. The rest is an excerpt of a composite structure diagram. Four simple ports are shown, that offer (ball symbol) or use (socket symbol) a certain interface. So far so good. However, the connectors cannot connect the interface symbols (the balls and sockets). They must connect the ports (the squares). For simple ports (i.e. offering or using only one interface) it is an option to show the ball and socket symbol on the connector, as is done here. Another option is to show the connector connected to the interface symbols. In this case, there would be no ball and socket symbol on the connector. These are three visualizations of the same model. I usually only use a normal line between ports.
Is this UML consistent with the text below?
Instead of trying to either define many subclasses or introduce
multiple inheritance, we can instead define a set of roles that the
device is meant to play. (It should be noted that this is another
reason why the concept of a managed device is a good one – now, we can
define a base concept of a managed device, and model its functionality
by associating one or more roles to it as appropriate). This solves
the mess of having the same generic function (such as routing)
assigned to two different types of devices that implement that same
generic function in different ways, producing different subsets of
functionality.
I believe that the UML specifies that each Device can have 0 or 1 DeviceRoles. A colleague asserts that the UML specifies that each DeviceRole can belong to a maximum of one Device. In either case, the UML seems to not reflect that a Device can aggregate a set of roles.
The UML and text is extracted from TMForum's Information Framework (SID):
Physical Resource Business Entities
Information Framework Suite
GB922 Physical Resource
Release 15.0.1
November 2015
Thanks, Greg
The UML diagram is consistent with the text. It clearly says that the device aggregates zero or more device roles and a device role can be played by zero or one device. In UML, multiplicity is notated adjacent to the type it quantifies.
It would help if the property names were written at the ends of the associations.
I have worked on this document and created a data model from it. In real world experience a resource, for example a physical resource like a mikrotik router can have roles of a router and firewall at the same time. So the model has to let you fulfill the need of several roles for a single resource.
I hope this example will clarify the subject.
Considering the following block diagram:
I would like to model a continuous flow from PressureSensor.pressure to LPF.input.
Is it compliant to the SysML 1.4 specification to model this flow without using ports like in the following diagram?
Or do I have to use ports like in the following diagram?
From the SysML spec (1.3):
The main motivation for specifying ports and flows is to enable design
of modular, reusable blocks with clearly defined ways of connecting
and interacting with their context of use.
In other words: you can of course use direct connectors, but you will loose the ability to specify more details about what is going on along those connectors.
There is a difference between a non-abstract block and a port typed with an interface. A non-abstract block cannot be substituted. In contrast, something with a matching interface is easily substituted.
Think about two analogies:
One brand of HDTV will only work with one brand of cable TV box. If you want to use another brand of HDTV, you would have to emulate the original brand of HDTV completely because of some undocumented inter-dependency.
Any brand of HDTV that has an HDMI interface will work with any brand of cable TV box that has an HDMI interface.
Which situation would you rather have in your living room?
Ball and socket notation is legal UML 2.0, but I cannot find a way to force EA to draw it on the diagram. It refuses to allow dependency between socket and the ball. Is there any way to make it happen, as in diagram below (little ms paint magic):
Also, a side question, can you make the ball or socket appear on the other side of the element?
There are two different ways of showing the ball and socket in EA.
With the one you've used, you've drawn connectors from your Consumer and Producer classes to the IProducer interface (a dependency and a realization, respectively).
You've then switched on display of Dependent and Realized interfaces on your classes.
Doing it this way means the balls and sockets are fixed. You cannot select them (the class gets selected instead), you cannot move them wrt their parent classes, and they cannot be endpoints for connectors.
The other way is to use Expose Interface.
With this method, you don't draw any connectors from your classes to the interface. Instead, you use Expose Interface to create an embedded element, which has the interface as its classifier, in each class.
These exposed interfaces, being elements in their own right, behave the way you want them to: you can move them around the perimeter of their respective classes, and you can draw connectors between them.
In the example, note the absence of any connectors to the IProducer interface element.
In order to expose the interfaces, there are two ways to go about it. You can select Expose Interface in the diagram toolbox, but note that that's only available in the Component toolbox - not the Class toolbox. That's what I've done with the Producer in this example.
The other way is to right-click the class and select New Element -> Port. This creates a port, which you can give any name. Then you right-click the port and select New Element -> Provided / Required Interface.
Either way brings up the Exposed Interface dialog, which allows you to select the interface element that should be exposed by using the ellipsis button (...) and browsing the project tree for interfaces.
Using a port may seem a bit cumbersome but it is, strictly speaking, more correct UML. Note also that a single port can expose several interfaces, both provided and required, allowing you to group interfaces which form some sort of logical unit. It might be that you have several interfaces which form one service and so go together, but that the class provides and requires several services.
This (to me) makes more sense when you're discussing not individual classes but rather components, and I generally use realization/dependency whan I'm modelling classes, and ports and exposed interfaces when I'm modelling components.
In EA ball and socket connections can (only) be drawn between ports. Use the "assembly" connector type.
It is right that ball and socket are legal UML 2.0 notation but they are not UML element, they depict element relations. So I guess that depending of the tool you use it will (or will not ) allow you to create a dependency between them. According to UML specification, a UML dependency should be create between, at least, two NamedElements.
Does anyone know the difference between Credit-Control-Application and Ro application in the diameter protocol? Their implementation in Mobicents diameter stack is almost identical.
I have searched within corresponding RFCs and 3GPP documents but couldn't find out which one must be used for online charging process.
Put in a simple way: IETF specifies the protocol while 3GPP specifies how to use the protocol in a very specific context. 3GPP may have additional requirements or recommendations in place when specifying a reference point (or "interface"), but normally this is done w/o violating any IETF RFCs (otherwise conflicts with be liaised to IETF for resolution).
The above usually describes most of the relationship between an IETF-specified protocol and their corresponding use in 3GPP.
For Diameter applications, 3GPP sometimes may also extends IETF RFCs with additional application IDs, AVPs, as well as defining how to map Information Elements (IEs) from other 3GPP interfaces into the AVPs.
Now down to the Credit-control diameter application and Ro interface. The former is defined in RFC 4006, while the latter is defined in 3GPP TS 32.299. I haven't gone through the 3GPP spec in great details, but it's not too difficult to find just a few differences. For example, Credit-Control-Request (CCR) Message for Ro Interface does not used Requested-Service-Unit AVP and a few others as pointed out in Table 6.4.2 of 32.299; but the CCR message may contain QoS-Information, a group AVP defined in 29.212, and this is Ro-specific. Table 6.4.3 of 32.299 describes similar for Credit-Control-Answer message, and look out for more differences laid out by the document.
As for Mobicents, I don't have experiences with its implementation but it won't surprise me that an open-sourced version is not fully-compliant with 3GPP specifications and omits some of the additional features.