I'm new to Autosar and trying to understand the concept theoretically.
I understand the philosophy, the goal, and the uses, but one thing that I don't completely understand is whether Autosar contains some out-of-the-box software components for developers? And if yes how can I recognize them in a binary file?
Assuming that the question uses the term “software-component” according to the meaning in AUTOSAR as some piece of application-level software:
no, there are no software-components standardized by AUTOSAR. There are PortInterfaces that are standardized and out of those PortInterfaces software-components could be created.
And also, some specifications postulate the existence of specific software-components, but this represents actually the opposite of a standardization. Those software-components are mostly postulated because it is not possible to standardize the respective functionality within the respective basic-software module (OEM/suppliers have proprietary approaches that they want to keep).
AUTOSAR defines an architecture with certain methodology and exchange formats. The BSW below and including the RTE is also specified. The BSW modules/components and their interfaces are standardized and include the MCAL, HW Abstraction and Service Layer components.
From your question it's a bit unclear what you mean with
some out-of-the-box software components for developers
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
What is nice about UML is that it offers a unified suite of defined diagrams for expressing software architecture. However, the diagrams are about the system being built and do not help for helping represent requirements and understand user-level issues (use-case diagram is the highest level and it's still very specific, we are looking for diagrams to use as input into a use-case).
So we've been using a hodge-podge of diagrams leaning heavily on dataflow diagrams, but I was wondering if there was a standard with a suite of diagrams like UML in existence for gather requirements etc.
I've seen individual diagrams that are useful, but never a suite of them that are standardised and interwork.
Is there something like a RML "Requirements Modeling Language" which a family of related diagrams for requirements and other more abstract concerns?
Depends what you mean by 'Higher Level'. Dataflow Diagrams are good - but to a large extent still define 'how' things work, not 'why'. I assume that since you've looked at DFDs you've also looked at and rejected business process diagrams in some form, e.g. bpmn/bpml.
Some other suggestions that may (or may not) be useful to you:
Feature Models, particularly useful for understanding Software Product Lines and the variability/commonality among variants;
Business Motivation Models which model the 'why's; objectives, constraints etc.
SBVR. A formalism for capturing business vocabulary & rules. Note it's textual rather than diagrammatic so might not be applicable.
Behaviour Trees, a notation for Behaviour Engineering.
That's a pretty broad spectrum. If you can be more specific about needs then it can be narrowed down. Worth noting however that none of the above have widespread industry acceptance; certainly not to the level UML has.
hth.
The Archimate modelling language is used for enterprise architecture modelling and might address some of your needs. The language is standardised by the OMG.
OMG page: http://www.opengroup.org/subjectareas/enterprise/archimate
A very useful blog from an experienced user of Archimate is here: http://masteringarchimate.com/ He has also written a useful book, sold through his web site.
Orbus Software have created a very nice Visio stencil for Archimate diagrams: http://www.orbussoftware.com/downloads/visio-starter-packs/archimate-starter-pack
A freely available single-user tool for Archimate modelling is Archi: http://www.archimatetool.com/
There are also a number of commercial tools including those from Orbus, BizzDesign, Corso, Avolution and others.
Eoin.
OMG, the standardization body which maintains UML, has a higher-level language for systems modelling: SysML.
SysML is intended to be higher-level than UML. It includes a "requirement" element type and omits many of UML's low-level constructs, but is still closely enough related that someone familiar with UML will recognize most of SysML.
UML itself is a model in a higher modelling language: The Meta Object Facility (MOF) which you could consider the supreme abstraction, because MOF is defined by itself (i.e. there is a MOF model that represents the MOF language). You can use MOF to describe a modelling language which can then contain diagrams/classes that you can define.
Link to MOF homepage: http://www.omg.org/mof/
And wikipedia: http://en.wikipedia.org/wiki/Meta-Object_Facility
Although UML is billed as a low level language you can certainly use it for higher level concepts either through UML profiles (See UML Profiles) or through a more developed extension. One such extension is UPDM which takes UML and SysML and extends it for use in architectures in the Defence industry (also applicable to more general uses) by representing the DoDAF and MODAF frameworks.
Just because UPDM is typically used to model lower level software architectures it doesn't mean that its extension mechanisms like MOF can't be used to model anything you want.
There is a modeling language called RML developed by Seilevel (full disclosure- I work there) that is specifically designed for requirements. You can read about it in this book
http://www.amazon.com/Visual-Software-Requirements-Developer-Practices/dp/0735667721/ref=sr_1_1?ie=UTF8&qid=1463064250&sr=8-1&keywords=requirements+models
Our blog has a lot of posts about it
http://www.seilevel.com/requirements/
Models are designed to be friendly to business users. The categories of models are
Objectives (Business objectives model, requirements mapping matrix, objective chain etc)
People (Org chart, process flow, KPI model etc)
Systems (eco system map, system flow, system interface)
Data (business data diagram, data flow, data dictionary)
I have a need to describe a hierarchical finite state machine in a standard and portable format. Is there a widely-accepted and supported file format that I should use?
I see that the Graphviz DOT language supports sub-graphs that may be referenced by directed edges. (Although rendering connected clusters using Graphviz is a bit of a problem.) Interpreting the text label on a generic directed edge as a transition event/criterion seems like a slight semantic stretch, but not unusable.
I see that a UML Statechart has support for hierarchically nested states. However, the accepted answer to this question implies that describing a statechart in XMI myself may not actually be properly interoperable with tools that nominally support UML.
I see the W3C SCXML Standard. However, this is still a working draft (and has been for almost 7 years), and I'm not certain if any tool supports this format (other than through conversion).
Is there a more widely-acceptable alternative than one of the above? Should I use one or the other of the above?
One of the examples of portability is that I would like for the graph to be able to be read and used by an HSM simulator like Matlab Stateflow.
There is an OMG standard for UML diagram interchange. But I don't thing it is widely accepted. You can also use the eclipse EMF UML2 format, for which you can develop yourself translators for other formats.
I would like to create a set of domain objects in multiple languages, so that I can target different platforms. I have been looking at external DSLs as a way to define a language for my domain, and then potentially writing adapters that generate code for the languages I'm interested in targeting. Is this the best way to solve this problem? Or is it just simpler to maintain multiple versions of the project?
I think that Apache Thrift delivers what you are asking for.
Sorry for late answer, but as you mention C# being your main language, this practically fully supported Visual Studio based technology is exactly what you are looking for.
You have to understand what you want to abstract with your DSLs, but the multiple-platform support is trivial on top of that.
Disclaimer: This is our technology, but it's publicly open and it solves exactly the problem presented in the question.
http://abstraction.codeplex.com/
Note! Mind the very "alpha" stage of the current download, I suggest you skip the zipped download and grab the latest source. I am updating better construct in relatively near future. Check out the "Context" implementation in "Production/Dev/AbstractionTemplate" solution.
It is difficult to be helpful without understanding what you are planning to use your DSL for.
Is portability your main problem here?
To succesfully target these different platforms, you will probably have to maintain plaftorm-specific layers anyway (generated or not).
If you plan to write your whole application in your DSL, then use your own compiler to transform it into runnable code for each platform, well it is most probably a bad idea, too complex and overengineered.
However, if you have a well-defined chunk of platform-independent logic, then a DSL is a good choice. Just write an interpreter for it on each target platform (provided that performance is not critical, this is also simpler and easier than generating code).
What is the best way to create multiple language versions of a domain?
This is (was?) somehow the idea of Model Driven Architecture (MDA). Quoting Model-driven architecture from Wikipedia:
The Model-Driven Architecture approach
defines system functionality using a
platform-independent model (PIM) using
an appropriate domain-specific
language (DSL).
Then, given a platform definition
model (PDM) corresponding to CORBA,
.NET, the Web, etc., the PIM is
translated to one or more
platform-specific models (PSMs) that
computers can run. This requires
mappings and transformations and
should be modeled too.
The PSM may use different Domain
Specific Languages (DSLs), or a
General Purpose Language (GPL) like
Java, C#, PHP, Python, etc. Automated tools generally
perform this translation.
Depending on the complexity of your domain and the availability of a MDA Tool, this might be an option (with a lower implementation cost).
See also
MDA: Nice idea, shame about the ...
Language Workbenches and Model Driven Architecture
UML vs. Domain-Specific Languages
DSL in the context of UML and GPL
UML or DSL: Which Bear Is Best? (be sure to read this one)
I would like to ask what is the difference between a subsystem and a component in the UML sense?
I have to agree with Preet, but practically, a subsystem is larger than a component. I use components for libraries (either bought, pillaged, or built) and subsystems for a part of the whole system that performs a given integrated function. For example, in a blood processing device, the centrifuge driver and control would be a component. The integrated blood suction regulation (which includes safety mechanisms, motor control, user control, and communications) would be a subsystem.
Before UML 2.0 I could perfectly see a <<subsystem>> as a design-time <<component>>, which would finally become a <<component>>. The UML 1.4 defines component as "A modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. A component is typically specified by one or more classifiers (e.g., implementation classes) that reside on it, and may be implemented by one or more artifacts (e.g., binary, executable, or script files)."
After the aforementioned "fuzziness" was introduced to the UML (in UML 2.0), I am more inclined to use <<subsystem>> as a larger <<component>>, and see both of them as replaceable and reusable constituents of a system.
From IBM developerWorks - UML basics: The component diagram
The UML 2 specification is quite vague
on how a subsystem is different from a
component. The specification does not
treat a component or a subsystem any
differently from a modeling
perspective. Compared with UML 1.x,
this UML 2 modeling ambiguity is new.
But there's a reason. In UML 1.x, a
subsystem was considered a package,
and this package notation was
confusing to many UML practitioners;
hence UML 2 aligned subsystems as a
specialized component, since this is
how most UML 1.x users understood it.
This change did introduce fuzziness
into the picture, but this fuzziness
is more of a reflection of reality
versus a mistake in the UML 2
specification.
So in short none.
In UML models, subsystems are a type of stereotyped component that represent independent, behavioral units in a system. Subsystems are used in class, component, and use-case diagrams to represent large-scale components in the system that you are modeling.
You can model an entire system as a hierarchy of subsystems. You can also define the behavior that each subsystem represents by specifying interfaces to the subsystems and the operations that support the interfaces.
In diagrams, compartments display information about the attributes, operations, provided interfaces, required interfaces, realizations, and internal structure of the subsystem.
Typically, a subsystem has a name that describes its contents and role in the system.
As the following figure illustrates, a subsystem is displayed as a rectangle that contains the name of the subsystem. It also contains the keyword «Subsystem» and the subsystem icon.
From: IBM Knowledge Center
I heard about B-Method which is invented in France. Is it an alternative to traditional programming languages like c++ and java or is it a completely different thing with different purposes?
Quote the B-website:
B is a formal specification method
which, thanks to an adequate language,
allows for highly accurate expressions
of the properties required by
specifications. One can then prove in
a fully automated fashion that these
properties are unambiguous, coherent
and are not contradictory. This then
allows us to mathematically prove that
these properties are taken into
account as the design stages progress.
Therefore, this method and its
associated proof allow for:
(1) Clear technical specifications and
system specifications to be reached
that are structured, coherent and
unambiguous, and (2) The development of
software that is contractually
guaranteed to be fault-free.
To answer your question: No, B-Method is not an alternative to programming languages. It’s a way of creating blueprints for programs and for verifying that the thing you created really works as described by the blueprints. If you don’t understand this you can safely forget about it.
No, as the Wikipedia article says, B-Method is a Formal Method not a programming language. You can read up on Formal Methods on Wikipedia too. Basically, they can be used during development to describe and verify algorithms.