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
Related
For a presentation I would like to show the relationship between machines of our company. There are basic machines and specialized machines. The specialized machines can do everything the basic machine can do.
I would like to show this relationship in the form of a class diagram in UML using the generalization arrow. However, I am afraid that UML class diagrams are very software specific.
Are there alternatives for general contexts? Maybe SysML?
Edit:
Here is a simplified diagram which is in principle very similar to the diagram I would present:
I have no data types for the attributes here, because in my opinion they make no sense. Would you still let it pass as UML? Or other suggestions?
Though SysML is targeted on modeling hardware, it is using similar language elements like UML. And of course it can model hard- and software - like UML.
Actually you can (almost) show SysML using a profile in UML. You can find both the SysML spec and the UML profile at https://www.omg.org/spec/SysML/1.2/About-SysML/
You should not be afraid to use UML if it's at hand. You can describe anything (technical) using this language.
RE your edit (this might start going to far, so if anything else arises ask a new question):
Cooling should be a class of its own. You'd have some abstract cooling device which can do general cooling (of the attached device). You then use specialized coolings that can do more (or less) fancy stuff. An ice bucket would be a simple one. And a Linde machine could come with lots of additional features.
That with the levels seems ok. Note that there's a naming convention where you start classes with upper and attributes/operations with lower case. So one back you'd better write cooling: Cooling
About the memory. The way you did it is not good. It's not overriding anything in that case. Also memory as a general attribute sounds like a flawed design. Memory is too general. Think about what kind of settings should be allowed and probably put these in an enumeration. That definitely needs a bit of brain power to get it right.
As said, these are a few loose thoughts. Making a design is good for an afternoons workshop (as a start).
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
As far as I know it is possible to indicate tight coupling in a component diagram by using the port notation and a straight line between them. Contrary to the ball and socket notation.
How do I indicate tight coupling in class diagrams?
As #ThomasKilian says, coupling is rather feature of code, although design decisions do influence it. Packaging and layering influence the density of the dependencies heavily. From the design perspective the tight coupling is fine as long as the classes belong to the same architecture layer
Rather then noting it in your class diagram, you may find useful the Dependency Structure Matrix as explained at
Source: Lattix's website
They coined the term as far as I remember
See also:
uml-diagrams.org: UML Package Diagrams Overview
Wikipedia: Multitier architecture
Is it appropriate to think of UML as a DSL?
I know that everybody thinks of UML as a way to draw pictures, but underlying the "view" of UML diagrams there is a model...and the "L" in UML stands for Language.
Another question - is SysML a DSL?
UML is a DSL.
A "domain specific language" lets one specify a problem or a solution in a narrow area of application; banking, telephony circuit design, .... One way to distinguish a DSL is that it cannot do general purpose computation (although there are some DSLs that can). Java, C#, Python and COBOL fail this test. (Some would say COBOL is domain-specific for "business" but its only serious concession to that is a decimal data type, and C# has that too.) ColdFusion fails this test; nonstandard syntax does not a DSL make, but IIRC ColdFusion has some support for generating HTML. Fortran fails this test, but its array(-section) sublanguage is only good for arrays and not general purpose computation. Verilog is very domain specific: it is designed to let you write down digital circuits.
UML focuses on specifying different aspects of how software is structured. [You'll note it can't do general purpose computation; one hallmark]. (It actually has 9 or more different aspects it addresses: classes, statecharts, deployment, ... I'll stick to the class aspect for this discussion). The class diagram aspect lets one describe how data is organized, and operations on that data. You can argue this about software so it can't be "domain-specific". What, building software isn't a problem domain?
SYSML is focused on expressing how systems are joined, so it fits this category too.
A more useful question to ask IMHO is, "If I think of UML as a DSL, what do I gain?" Here I don't think you get a lot. The concept of DSL is useful when you arguing for one you don't have (designed or possess) with the point being better expressiveness for a common problem, and might be useful for arguing "you don't want implement your system entirely in it because it isn't Turing capable". It is also useful if you want to explain that your language is going to have a lot of funny notations, precisely because they serve special purposes. People already know this about UML, so... nothing learned.
While I'm a big fan of DSLs, I'm also a big fan of GPLs (general purpose languages). I think in big systems you should necessarily find a "lot" of both: the DSLs to express what they can succinctly (cuts engineering and maintenance costs), and the GPLs to provide arbitrary computation and glue between the system parts. For me what counts in a language is:
what's the class of problem it claims to address and how well does it do it?
what's the syntax (and is it relatively standard for the problem domain)?
what are the precise semantics (this is where you learn the most)?
how good is the tool support?
how well does the DSL integrate into other parts of a big system?
how big and supportive is the community?
UML has (after 15 years) arrived at pretty good answers to these questions.
Homegrown DSLs often don't do so well, partly due to poor design, but often due to the fact that tool support is difficult to get. My company provides machinery to give DSL builders excellent support to improve this situation.
UML is NOT a DSL because UML can be used to model any vertical domain (insurance software, embedded systems,...)
UML is a (horizontal) DSL because UML is a specialized language to model software systems.
So UML is and is not a DSL depending on how you look at it. You could apply the same reasoning to many other languages like html or SQL. They are general because they can be used to represent/manipulate any kind of data but they are specific because they are focused on one task
Short answer - NO - to both questions.
Think of UML as a tool that lets you describe software architectures, software interactions and so on ... describe them in a general way, language agnostic.
DSLs are specialised syntaxes meant to make it easier to describe some specific set of problems
I think the answer to your first question depends on how to define "General" in the term "General Purpose Language". Wikipedia says it is not a DSL:
The opposite is:
a general-purpose programming language, such as C, Java or Python,
or a general-purpose modeling language such as the Unified Modeling Language (UML).
I am a MDA enthusiast so I think I can provide you a very detailed answer to your question.
What is the UML:
The Object Management Group (OMG), a consortium of companies aimed at providing standard languages and technologies, defined a meta-meta modeling language called "The Meta Object Facility" or MOF (http://www.omg.org/mof). A meta-model is a model describing a model or, in other terms, describing the vocabulary (the elements you can use in a model), the syntax (ho they relate each other) and their semantics (what does each entity mean and how its meaning changes in a given context, etc.). A meta-model plays the same role played by Context-Free grammars with respect to the languages they produce. You can thus think at a meta-meta model as a language you can use to define meta-model. This is what the OMG actually did with the UML. The UML language has a meta-model described by means of the MOF in two documents: The UML Infrastructure and the UML Supersturcture (http://www.omg.org/spec/UML).
The UML meta-model has been defined with the aim of been generic enough to cope with the modeling of different systems belonging to different domains. When you define a new UML model you create an instance of the UML meta-model. You could do that for many reasons: to analyse some characteristics of the system, to share some aspects of the system with other stakeholders and so on. However, one of the most important aspects of the OMG vision are model transformations. You can think at a transformation as a set of rules telling an interpreter how to explore a model and produce something else. You can basically transform a model into two different kind of thins, other models (Model2Model, M2M transformations, defined by means of the QVT language) or text such as code or documentation (Model2Text, M2T, transformations defined by means of the MOFM2T Transformation language). So it is VERY IMPORTANT to understand that a UML model is not its diagram. A diagram is just a pictorical representation of the model contents, useful for umans, but not machine readable. You can't apply transformations to a diagram.
The Eclipse Modeling Framework (EMF) is a very powerful (and FREE!) framework implementing all the technologies I have mentioned. A subset of the MOF is implemented in the Eclipse ECORE language. By means of the ECORE the UML meta-model is defined so grafical UML editors (i.e. Papyrus, TopCased, etc.) actually creates XMI representation of the graphically defined UML models conform to the ECORE representation of the UML meta-model. Such representation can be provided as input to transformations engine. The two transformation languages, and related engines, are also available in the EMF with the QVTo plugin and ACCELEO (implementing the MOFM2T transformation language).
As mentioned UML is intentionally generic. However it also provide lightweight extension mechanisms to extends original language vocabulary with domain specific constructs. This can be done by means of stereotypes. A stereotype is a sort of label (actually with meta-attributes) you can attach on model elements to create new entities in the language. You can for instance say in your models some of the classes could be requirements or something else. There are of course some rules, for instance when you stereotype a meta-class you can not violate its original semantics, just reduce it.
SySML is a profile of the UML http://www.omgsysml.org/. A SysML Block is just a UML class stereotyped as Block, a SysML Requirement is just another UML class stereotyped as Block and so on.
Profiling a meta-model like the UML is a quite easy way of creating a sort of DSL (as with stereotypes you add to a more general language some constructs which belong to your domain) which is compatible with the UML (i.e. you can use SysML and UML together). There is another way of creating a DSL which is defining its meta-model by means of the MOF (ECORE). In this case you create a brand new language which is conceptually at the same level of the UML itself.
Many people say UML is just about diagrams because in many cases they do not know what they are talking about. The topic is far more complex, interesting and promising.
UML is a general modelling language that is not specific to any domain whilst the S in DSL stands for Specific. UML is used for modelling systems that can also be represented by multi-purpose programming languages. DSL on the other hand are constrained programming/scripting languages which are specific to a particular domain.
I was hoping you could tell me what the advantages and disadvantages of BPMN are in a developers perspective.
I'm comparing UML with BPMN and a found a bunch of advantages and disadvanteges for UML but none for BPMN.
It's largely down to audience and purpose. In terms of modelling language, BPMN and UML activity diagrams cover pretty much the same conceptual space with different notations. The notation thing gets religious very quickly. I personally prefer AD notation over BPMN - but it's a very personal thing.
Broadly speaking, BPMN tends to find favour with those coming from a business process modelling / business analysis background. UML ADs tend to be favoured by those coming from a software perspective. Tool support tends to mirror this: the high end process modelling tools (casewise, aris, etc.) are more likely to support BPMN; software modelling tools (MagicDraw, Sparx, etc.) favour UML. However there's increasing crossover there. I've used both with business stakeholders with no issues in either case.
Finally is purpose. Are your diagrams going to be for human consumption only or used as a specification for some form of analysis/code generation? If it's not just pictures then your tool chain may well be the deciding factor.
If you want a more detailed description of the differences, have a look at the answer in this forum post.
A new BPMN Profile has been discussed at the OMG. UML can easily generate code even with an activity or state diagrams. You just need to add stereotypes in your model then a parser will take the xmi and create code. The OMG specification will define which stereotypes should be used and why. Really a very good idea !!
In my company we have stopped using BPMN and are only focus on the activity diagram which is more accurate because built on the top of a standard language. Having also class diagram, usecase and activity diagrams allows to model faster.
We get a running code from our activity or state diagram. We debug with our class diagram.
We use the same metamodel for all diagrams and therefore can trace activity to code implementation and through class diagram. I mean that the code is reversed once generated and then we check all requirements and the architecture in order to have a nicer object architecture.
Everything works well :-)
We are now waiting for the new profile specification and will implement the needed stereotypes in order to cover BPMN.
My answer to your question is that we don't need anymore BPMN and should move on to UML 2.3 BPMN profile implementation.
BPMN is for modeling business process flow, isn't it? That's not exactly what UML is for. The goal of UML is to model a software from different view and ultimately not to have to code it (yes that's kind of ideal).
The main arguments for BPMN from a business perspective are usually:
When building BPMN diagrams from scratch with many stakeholders, it is ok to mix tasks of different levels of hierarchy, which can be detailed out or summarized later.
The basic language elements can be thought quickly even to a non-technical audience.
The developers can immediately start working and attaching source-code and scripts to the BPMN-diagram by workflow and business process management software like Camunda.
The main drawbacks are that
The initial BPMN sketch (usually by the business) usually needs many iterations to arrive at a diagram which allows for implementation.
It is not straight forward to represent different roles since the usual concept of lanes in pools might not be enough or lead to huge diagrams, see e.g. BPMN: multiple roles in a row
See the MDA on OMG (Model Driven Architecture):
- we use BPMN only for Computation Independent Models (CIM)
- we use UML only for Platform Independent Model (PIM, high level design) and Platform Specific Model (PSM, low level design).
- using BPMN for any "software systems" or UML for "business" have no sense (see UML v.2.5)
- for developers: we can make transition from BPMN business process to Use Case, it is good tool for defining scope of requirements for software https://www.visual-paradigm.com/tutorials/from-business-process-to-use-cases.jsp
If you are looking for similarities, both UML and BPMN diagrams can be described using text.
PlantUML
BPMN Sketch Miner