1. I can think of three ways BCs can use/reference Generic Subdomains ( GS ). Which way is most appropriate and why:
a - BC could have a reference to a dll within which GS is defined and as such this BC would be able to reference the types ( defined within the GS ) as needed ( example: a method defined in BC takes a parameter of type defined in GS )?
b – or should entire GS be defined within Shared Kernel ( this Shared Kernel would be shared with all BCs interested in this GS )?
c – or should only a subset of GS be created within Shared Kernel, while the remainder of GS would reside within a BC?
d – or is there a better alternative?
2. Is GS most often defined within a single BC?
Thanks
Any domain (core, generic subdomain, supporting subdomain) should be in its own bounded context.
That being said, a generic subdomain is generic because it does not fulfill a specific business requirement. It is, however, required to perform other business requirements. So something like a calculation engine that can calculate tax rates, or policy premiums, or customer classification based on arbitrary arguments passed in would qualify. It does not perform any business function.
I don't think a generic subdomain should be part of a shared kernel simply because it has no real business function. A shared kernel, therefore, should encase a shared business model.
So a shared kernel would be used by more than one BC that performs specific business functionality.
I hope that helps?
Related
Why AutoSar defines new types(for intance, ara::core::Future, ara::core::Vector and so on) other than use the standard one(i.e. std::future, std::vector)?
What's the benefit?
You should read about the types in chapter 7 and 8 of the AUTOSAR_SWS_AdaptivePlatformCore.pdf.
7.2.4.2 Types derived from the base C++ standard
In addition to AUTOSAR-devised data types, which are mentioned in the previous sections, the Adaptive Platform also contains a number of generic data types and helper
functions.
Some types are already contained in [4, the C++14 standard]; however, types with almost identical behavior are re-defined within the ara::core namespace. The reason
for this is that the memory allocation behavior of the std:: types is often unsuitable for automotive purposes. Thus, the ara::core ones define their own memory allocation behavior, and perform some other necessary adaptions as well, including about the throwing of exceptions.
[SWS_CORE_00040] DRAFTg Errors originating from C++ standard classes
For the classes in ara::core specified below in terms of the corresponding classes of the C++ standard, all functions that are specified by [4, the C++14 standard], [9, the C++17
standard], or [10, the draft C++20 standard] to throw any exceptions, are instead specified to be the cause of a Violation when they do so.c(RS_AP_00130)
Examples for such data types are: Array, Vector, Map, and String.
The reasons for ara::future are described also in chapter 8.1.6. (I will not cite this here).
So, in the end, ara::core is the place to define / configure the implementation specific details in order to use the same definition in the code base in AUTOSAR Adaptive SW, no matter if it is your own SW on top of ara or within ara service implementation itself.
This is like the Std_Types.h / Compiler.h / Platform_Types.h is the place in AUTOSAR Classic to define / configure the basic primitive types of uint8 / sint8 / ... instead of using uint8_t / int8_t / ... from stdint.h, which was introduced in C99, but was not available in C90.
I have a question regarding modeling on an Activity Diagram that has been bothering me for some time and I was not able to find any answers / Convention anywhere.
Here is an example to better understand my question:
Let say that I have two class named "flat" and "house". both are a generalization of the class "housing".
housing contain an attribute "residents" for the person living in it.
flat contain an attributes "floor" that says at which floor the flat is.
Here is the class diagram:
In an activity diagram, I want to represent the action of giving persons a housing.
this action can take either house or flat as input (so the use of "housing" type for the input pin is correct I think) as well as an undefined number of people.
I want this action to give an updated house or flat as output (not an updated housing as this would mean that information specific to the house or flat would be lost.
I don't really know if I must create two actions (one for house and another for flats) or if there is a way to reuse the action for both class and have a correct output out of it.
Here is the activity Diagram:
My question is: how to represent in an activity diagram, an action that is the same for different type of Object flows as input, and that give the updated Object flow as output (that may be therefore of different type)?
nb:
all type of object flow are class and inherit from a same other class.
I'm representing this in modelio but first had this issue in Cameo.
I'm Trying to fit as best as I can within the rules of UML Language.
Cameo is right in rejecting this model. Give Flat Floor expects a Flat and will not work with a House, but Assign Resident to Housing could return a House. I know, in your context it can only return a Flat, but how should the tool know that?
The correct way to capture this fact would be to add a postcondition to Activity Assign Resident to Housing that states that the type of the input and output pin will be the same.
However, it would be really hard to define a complete set of compatibilty rules that takes into account all the global and local pre- and postconditions and the tools would also be hard pressed to validate a model according to these rules. Therefore the UML specification choose the easy road and simply doesn't allow to connect the pins.
The solution is to use the transformation property of the ObjectFlow. Just assign an OpaqueBehavior that casts the Type House to the Type Flat. Cameo will then accept the model. It is the modelers responsibility to ensure, that this cast will always work, since no exception handling can be defined here. Maybe this should be documented with a local postcondition.
In your specific example there is an even easier solution: simply fork the ObjectFlow of Type Flat and omit the OutputPin of Assign Resident to Housing.
As a side note: Due to a bug in Cameo, you can change the type of the OutputPin to a more specific Type than that of the ActivityParameter. This is correct for InputPins, but should be the opposite for OutputPins. You could use this to let the Parameter be of type House, but the OutputPin-Type would be Flat.
The two flows (top object and lower control) in the blue frame could stay as they are. Give flat floor would commence only when it receives a Flat object and the control token is sent. In order to make the right action sort of optional I would just use the object flow, thus only triggering when a Flat object is passed. That would just be enough and no additional control flow is needed.
To make things clear I would also add a guarded flow from the Assign action to an exit reading [ house was assigned ] or the like.
Is it possible to have two flops/any other instances have the same name in the netlist?
Considering that there is no hierarchy, say I have a design of 10M instances and there exists an flop called foo, is it possible that another flop have same name 'foo'?
No. Within a single scope, you cannot re-use the same identifier for another purpose,
As Dave says, no. But if you had 10M instances, you wouldn't have coded that manually, your logic synthesiser would have. And it won't output an illegal netlist.
The only way your question makes sense is to consider one large verilog file - obviously, here there can't be more than one reg/logic with the name foo. This is fundamental to the verilog scoping rules.
If there is any iteration or local scope of any form in your design, the elaboration process will construct a form of heirarchy to handle this iteration. If you flatten the resulting netlist (by default or design), then each element will either gain an abstract unique identifier (n1, n2, n3...), or be pre/post fixed with some heirarchical information (gen_1_foo, gen_2_foo...).
After the netlist generation, it may be non-trivial to relate a specific flop to it's syntactic source in the verilog - but you brought this on yourself by the lack of heirarchy and structure in the design.
For my understanding, the ApplicationDataType was introduced to AUTOSAR Version 4 to design Software-Components that are independent of the underlying platform and are therefore re-usable in different projects and applications.
But how about the implementation behind such a SW-C to be platform independent?
Use-case example: You want to design and implement a SW-C that works as a FiFo. You have one Port for Input-Data, an internal buffer and one Port for Output-Data. You could implement this without knowing about the data type of the data by using the “abstract” ApplicationDataType.
By using an ApplicationDataType for a variable as part of a PortInterface sooner or later you have to map this ApplicationDataType to an ImplementationDataType for the RTE-Generator.
Finally, the code created by the RTE-Generator only uses the ImplementationDataType. The ApplicationDataType is nowhere to be found in the generated code.
Is this intended behavior or a bug of the RTE-Generator?
(Or maybe I'm missing something?)
It is intended that ApplicationDataTypes do not directly appear in code, they are represented by their ImplementationDataType counterparts.
The motivation for the definition of data types on different levels of abstraction is explained in the AUTOSAR specifications, namely the TPS Software Component Template.
You will never find an ApplicationDataType in the C code, because it's defined on a physical level with a physical unit and might have a (completly) different representation on the implementation level in C.
Imagine a battery control sensor that measures the voltage. The value can be in range 0.0V and 14.0V with one digit after the decimal point (physical). You could map it to a float in C but floating point operations are expensive. Instead, you use a fixed point arithmetic where you map the phyiscal value 0.0 to 0, 0.1 to 1, 0.2 to 2 and so on. This mapping is described by a so called compuMethod.
The software component will always use the internal representation. So, why do you need the ApplicationDataType then? There are many reasons to use them, some of them are:
Methodology: The software component designer doesn't need to worry about the implementation in C. Somebody else can define that in a later stage.
Measurement If you measure the value, you have a well defined compuMethod and know the physical interpretation of the value in C.
Data conversion: If you connect software component with different units e.g. km/h vs mph, the Rte could automatically convert the internal representation between them.
Constant conversion: You can specify an initial value on the physical value (e.g. 10.6V) and the Rte will convert it to the internal representation.
Variable Size Arrays: Without dynamic memory allocation, you cannot have a variable size array in C. But you could reserve some (max) memory in an array and store the actual length in a seperate field. On the implementation level you have then a struct with two members (value, length). But on the application level you just have an array.
from AUTOSAR_TPS_SoftwareComponentTemplate.pdf
ApplicationDataType defines a data type from the application point of
view. Especially it should be used whenever something "physical" is at
stake.
An ApplicationDataType represents a set of values as seen in the
application model, such as measurement units. It does not consider
implementation details such as bit-size, endianess, etc.
It should be possible to model the application level aspects of a VFB
system by using ApplicationDataTypes only.
everyone what is the difference between those 4 terms, can You give please examples?
Static and dynamic are jargon words that refer to the point in time at which some programming element is resolved. Static indicates that resolution takes place at the time a program is constructed. Dynamic indicates that resolution takes place at the time a program is run.
Static and Dynamic Typing
Typing refers to changes in program structure that are due to the differences between data values: integers, characters, floating point numbers, strings, objects and so on. These differences can have many effects, for example:
memory layout (e.g. 4 bytes for an int, 8 bytes for a double, more for an object)
instructions executed (e.g. primitive operations to add small integers, library calls to add large ones)
program flow (simple subroutine calling conventions versus hash-dispatch for multi-methods)
Static typing means that the executable form of a program generated at build time will vary depending upon the types of data values found in the program. Dynamic typing means that the generated code will always be the same, irrespective of type -- any differences in execution will be determined at run-time.
Note that few real systems are either purely one or the other, it is just a question of which is the preferred strategy.
Static and Dynamic Binding
Binding refers to the association of names in program text to the storage locations to which they refer. In static binding, this association is predetermined at build time. With dynamic binding, this association is not determined until run-time.
Truly static binding is almost extinct. Earlier assemblers and FORTRAN, for example, would completely precompute the exact memory location of all variables and subroutine locations. This situation did not last long, with the introduction of stack and heap allocation for variables and dynamically-loaded libraries for subroutines.
So one must take some liberty with the definitions. It is the spirit of the concept that counts here: statically bound programs precompute as much as possible about storage layout as is practical in a modern virtual memory, garbage collected, separately compiled application. Dynamically bound programs wait as late as possible.
An example might help. If I attempt to invoke a method MyClass.foo(), a static-binding system will verify at build time that there is a class called MyClass and that class has a method called foo. A dynamic-binding system will wait until run-time to see whether either exists.
Contrasts
The main strength of static strategies is that the program translator is much more aware of the programmer's intent. This makes it easier to:
catch many common errors early, during the build phase
build refactoring tools
incur a significant amount of the computational cost required to determine the executable form of the program only once, at build time
The main strength of dynamic strategies is that they are much easier to implement, meaning that:
a working dynamic environment can be created at a fraction of the cost of a static one
it is easier to add language features that might be very challenging to check statically
it is easier to handle situations that require self-modifying code
Typing - refers to variable tyes and if variables are allowed to change type during program execution
http://en.wikipedia.org/wiki/Type_system#Type_checking
Binding - this, as you can read below can refer to variable binding, or library binding
http://en.wikipedia.org/wiki/Binding_%28computer_science%29#Language_or_Name_binding