Is UML (unified modelling language) a technique for system modelling or for software modelling?
Both. Some diagrams are more useful for software modeling, but some others can be used for both. A state machine for example can be used for a software or a system.
But if you want to model a system with UML, you should take a look at SysML a profile to specialize your UML models.
UML is a general purpose modeling language, although it's primarily geared toward modeling object-oriented software systems. The latest version of the UML specification contains 14 diagrams, some of which are applicable to software in general while others make more sense when applied to modeling object-oriented software systems. Seven UML diagrams are used in SysML, which is commonly used for systems and systems-of-systems modeling.
UML is a tool for modeling all kinds of things, not even just programming related. For example, you can use state diagrams to model the function of a control panel, e.g. a thermostat. You can use use-case diagrams or sequence diagrams to document business processes.
You can use activity diagrams to show how a hamburger is made in a fast-food restaurant.
According to the wikipedia article about Unified Modeling Language it is "a standardized (ISO/IEC 19501:2005), general-purpose modeling language in the field of software engineering. The Unified Modeling Language includes a set of graphic notation techniques to create visual models of object-oriented software-intensive systems."
It is used to describe the more abstract structure of the system and the software itself at the same time.
If you take a look at the article (which I highly recommend), you'll notice that
"The Unified Modeling Language (UML) offers a standard way to visualize a system's architectural blueprints, including elements such as:
* activities
* actors
* business processes
* database schemas
* (logical) components
* programming language statements"
* reusable software components"
By describing the activities, actors, business processes you basically describe the abstract representation/design of the system.
And by describing the (logical) components, programming language statements, reusable software components you describe the implementation details (software).
Related
When designing for a software, what is the correct order of UML diagrams we have to do? Starting from the Use Case diagram, what would be the next diagrams until we have enough to start coding?
UML is just a modeling language, not a software development methodology. A well-known methodology that provides guidelines for using UML in its software development process is the Rational Unified Process, although its popularity has declined. Still, it is not easy to determine the order of the UML diagrams prescribed by RUP from the available material provided by IBM. I have written a paper http://admiraalit.nl/admiraal/WhichUMLmodels.pdf which may help you with that.
For a simple application, a class diagram and a component diagram may be enough, but it depends very much on the type of application.
Currently i am trying to figure out, then to use OWL and then to use UML to describe a domain of interest in a Software Engineering process.
I read this paper by Atkinson, which gives a very good overview about the difference and the equalities of OWL and UML on a semantic and a syntactic level.
However it does not provide a clear indication in which use-cases it might be better to use OWL instead of - for example - an UML class diagramm.
It might be the underlaying development process, which decides the modelling language to take (e.g. model-driven = go for UML, ontology-driven = go for OWL) but for myself it is this difference still not clear?
In both language I can build up a terminology, which I - as an ontology engineer - can reuse in order to infer new knowledge from it. As an Software Engineer I use this terminology for the construction of a (single) system.
So is the difference between OWL and UML just the field of study? Or could I use OWL in order to describe the construction of my (single) software system?
Moreover, this raises the question if the decision of which kind of modelling language to choose is only driven by the goal, which I try to accomplish?
A synthetic answer
UML is a (graphical) language for modeling
OWL is a language used for knowledge representation (KR) in a semantic perspective
In the first place, OWL purpose is not modeling. Using a KR technique is an option in the field of software engineering. It should be distinct from any software engineering process. Both languages have different purposes.
Of course, you could [use] OWL in order to describe the construction of [a software system]. But the interest of such a move would mainly be in automated reasoning about your software construction process and would not be very helpful in the context of a single project. This would only be effective if done for all your projects in order to have a consequent knowledge base (KB).
A detailed explanation
According to the W3C wiki section about OWL:
The W3C Web Ontology Language (OWL) is a Semantic Web language designed to represent rich and complex knowledge about things, groups of things, and relations between things. OWL is a computational logic-based language such that knowledge expressed in OWL can be exploited by computer programs, e.g., to verify the consistency of that knowledge or to make implicit knowledge explicit
There should be some debate about what is a modeling language. For example, the Wikipedia article on the topic considers a broad sense which could also cover OWL. I consider here with the modeling term only the software engineering activity (which is the one you focus on in your question).
You might need modeling in order to define ontologies, just like you would need for the development of a software project. But this OWL modeling would not consider the software engineering elements but rather the domain data of your project. In other words, using UML in a software construction process aims to setup software elements. With OWL, you would not focus on these elements, unless you are trying automated reasoning about software construction.
Beside this, a relationship exists between UML and OWL. A note by Walter W. Change in the frame of the W3C discusses the question. I would summarize the question considering two distinct relations.
Using UML to represent OWL knowledge
An OMG specification called ODM (for Ontology Definition Metamodel) provides a metamodel for defining ontologies. In the frame of this specification, the use of an UML profile is introduced as a way to bridge a gap between both languages. In the ODM 1.1 specification, section 8.4.2:
The goal of a UML profile from the ODM perspective is to provide a bridge between the UML and knowledge representation communities on a well-grounded, semantic basis, with a broader goal of relating software and logical
approaches to representing information.
The UML profile use is introduced in an article. You might find such a profile in the ODM 1.0 specification resources, as a non-normative document. According to what is here considered, this UML profile might be a tool for modeling ontologies.
Using OWL/Semantic Web technologies to represent UML
RDF is the basis format used to write OWL ontologies.
An early (2000) academic work provides a semantic RDF document modeling the UML elements (based on the OMG specification). This work preceded the draft works on the OWL W3C recommendation (2002).
Actually OWL is available as profile in UML. See OMG specfication. So you can use UML with OWL profile in "one soup".
Let's start with the definitions.
Unified Modeling Language (UML) is a general-purpose, developmental,
modeling language in the field of software engineering, that is
intended to provide a standard way to visualize the design of a
system. (Wikipedia)
UML has many diagrams, but none of the classics is designed for ontology modelling. Therefore, researchers have created OWL with this purpose.
The W3C Web Ontology Language (OWL) is a Semantic Web language
designed to represent rich and complex knowledge about things, groups
of things, and relations between things. (W3C)
Such as said by Thomas Kilian in the other answer:
OWL is available as profile in UML. See OMG specfication. So you can
use UML with OWL profile in "one soup".
Therefore, OWL can be part of the set of UML diagrams used in a Software Engineering Process. The main benefit of OWL over classic UML diagrams is when you have to design a system using ontologies. The purpose of class diagrams is to represent classes, not ontologies. If your system does not rely on ontology, stick with the classic UML diagrams; you do not need OWL. If your system uses ontology and you need to represent it on a diagram, use OWL.
OWL is used to describe a domain and to be able to specifically, using semantics, specify knowledge of a domain as well as describe its specificities. Take for example the Friend of a Friend ontology. Using it you can describe how people relate to each other.
You might say that you can do the same thing using UML and you are correct. You can specify properties, relations, and so on, using OWL as well as UML. However, what you can't do with UML is infer domain knowledge. OWL, being a Semantic Web language, models a domain with either an Open or Closed World assumption. Basically you assume knowledge based on what is described in the domain. Then you can use specific instructions to infer knowledge using Rules or just be looking at predicates and statements you have created. Furthermore, you can use specific query languages such as SPARQL to query your ontology as much in the same way you would use SQL to query a database.
TL;DR: Using UML you specify how you would translate a specific domain into software, using OWL you specify knowledge about the domain as it is much richer than UML.
To amend the references of UML and OWL comparison there is a PhD thesis (in German) from Jesper Zedlitz Konzeptuelle Modellierung mit UML und OWL – Untersuchung der Gemeinsamkeiten und Unterschiede mit Hilfe von Modelltransformationen
(Conceptual Modeling with UML and OWL - Exploring the Similarities and Differences Using Model Transformations)
In this thesis studies if and in which extend it is possible to tranform between both modelling languages. In the conclusion (p. 222) it is stated that OWL has possibilities to do more complex modelling and therefore it is not always possible to transform from OWL to UML.
Actually from my work on ontologies in the previous time I see using ontology tools like Protege is very helpful and rich in describing relations between entities and using Tools like OLGA can help you in mapping this ontology to many object oriented language.
Yes, we haven't the capabilities of using graphical representations to design our models like UML but it provides a wide range of options to describe you model.
The importance and benefits of mapping the domain ontology to the UML model are in integrating the benefits and quality that these two modeling techniques provide. That is, if there are already domain ontologies with a certain level of authority, these knowledge bases can help in the creation of UML class diagrams, such as the axiomatic guarantees provided by the description logic that builds it, besides enabling UML power of inferences Provided by this formalism, with the transformation is intended to show the evidence that reuse of ontology can help to reduce ambiguity in class diagrams.
Is Object Oriented Modelling And Design part of Software Architecture?
I am confused between Object Oriented Modelling & Design and Software Architecure. In Software Achitecture we are providing the skeleton for system (as I understand) In Objet Oriented Modelling and design we design the system using different UML Digrams. So are we doing same thing in Software architecture ?
Because a skeleton could be defined using diagrams only,right?
Can someone please explain me with Example of Software architecture?
No, Object Oriented Modeling is a toolset or process, Software Architecture is a deliverable artifact.
Related:
Wikipedia: Software architecture
Wikipedia: Object-oriented analysis and design
Kirill Fakhroutdinov's uml-diagrams.org: examples of UML diagrams documenting a software architecture
Scott W. Ambler's Agile Modeling: Architecture Envisioning: An Agile Best Practice
Software Architecture is a very broad term. It can describe the software of the tiniest component, to the largest systems.
OOMD is the process of arriving at a design that may be a part of a software architecture, typically by using Class Diagrams. But OOMD can be used outside of designing something new. It can be used to help analyse and understand a piece of legacy code.
UML is a language which is used in conjunction with OOMD. It is nothing more than that. A UML diagram doesn't necessarily 'contain' an architectual concept, just as much as a picture of an apple is an apple. One would use UML to illustrate and solidify concepts that will eventually go into the finished product.
Not all of UML is concerned with OOMD (eg. Use Cases, and Activity Diagrams). And not all of OOMD is concerned with Software Architecture.
No, object oriented modelling and design is not part of the software architecture.
The software achitecture is independent of the platform that is used to implement it. The platform doesn't even have to be object oriented.
Software architecture has been around since before object oriented development even existed. I remember learning software achitecture approaches (JSP) before even hearing about object oriented development (OO was a very recent concept when I was in school).
Part of the software architecture could be used to automatically generate object models using some tool, but this a different part. By doing that you have taken the step beyond the software achitecture and chosen a platform for the implementation.
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)
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.