Modeling:
Modeling is mainly about abstraction, and describing concepts from a different level. like in UML for example, we use boxes to represent classes, arrows to represent associations and relationships.
so when we build a complex system, before we would right the source code for it, we start sketching out different components of the system, and how they believed to interact and so on. then we use these boxes as a reference that we use while writing the source code. in fact these models will always help us to look at the big picture from a different abstraction layer.
this activity is called modeling. in software engineering modeling is mainly based on UML ( unified modeling language) but not restricted to it. in general we can call the language that defines the different models or components that we can use a formalism. UML class diagram, for example, is considered a formalism that lets you model classes and their associations and inheritance or even compositions. UML statecharts is another formalism that allows for modeling the state flow and interactions of a system. of course if we look at other systems we are not limited to UML formalisms, for example Petri nets, or DEVS amongst others are also powerful formalism with different purposes.
Meta modeling:
A formalism like the UML class diagram contains many elements. for example a class is an element that has a type class, has a property called name, and can have many attributes. it can also have many methods each with a qualifier ( public , private or protected) . and so on.
but where is all these things described and specified ? they are in something called the UML class diagram meta model. in general a meta model describes the grammar of a language, or a formalism. in the meta model also you can define the graphical representation of the elements of the formalism . for example you can choose to represent the class by a box with a header that includes its name. and so on.
Domain specific modeling:
Domain specific modeling is just normal modeling. the main thing that is involved here is that the modeling environment ( the formalism ) that will allow the user to build models is built specifically for the desired domain. to make this simpler here is an example . let's say i am a modeler and i wanna build a domain specific modeling language for building traffic systems ( arguably, i am doing that so that i give later to traffic system experts so that they can use it to build a traffic system model for the new city and analyze it). Then I can define this traffic modeling system by specifying the different elements it can have and the different links it can have between them. its really like designing your own UML language. so for example for traffic networks i can talk about defining a domain specific language that has road segments, traffic lights and car generators . i can then describe some constraints like for example a road segment can only be connected to a maximum of two other road segments. or a constraint that i can only connect a car generator to one road segment at any time. by doing this i take away some of the complexity that whoever is designing a traffic system doesnt care about. in this case the user will only worry about the problem domain ( building a traffic system) and not worry about how this system will map back to running code.
However, someone will need to worry about this mapping into a running program as the upcoming post on model transformation will describe.
