M.TECH IT / CS-512 / Department of Computer Sc.

& Engg / LIT

1










M.TECH IT IIIrd SEM

AUG-DEC 2007


CS-512

Object Oriented Analysis and Design using UML


TUTORIAL 1

Object Oriented Design and Modelling

(SECTION 1 OF THE SYLLABUS)


M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
2

Object-oriented analysis and design (OOAD)
Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a
group of interacting objects. Each object represents some entity of interest in the system being modeled, and is
characterized by its class, its state (data elements), and its behavior. Various models can be created to show the
static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number
of different notations for representing these models, such as the Unified Modeling Language (UML).
Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a
system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications.
OOA focuses on what the system does, OOD on how the system does it.
Object-oriented systems
An object-oriented system is composed of objects. The behavior of the system results from the collaboration of
those objects. Collaboration between objects involves them sending messages to each other. Sending a message
differs from calling a function in that when a target object receives a message, it itself decides what function to
carry out to service that message. The same message may be implemented by many different functions, the one
selected depending on the state of the target object.
The implementation of "message sending" varies depending on the architecture of the system being modeled, and
the location of the objects being communicated with.
Object-oriented analysis
Object-oriented analysis (OOA) looks at the problem domain, with the aim of producing a conceptual model of
the information that exists in the area being analyzed. Analysis models do not consider any implementation
constraints that might exist, such as concurrency, distribution, persistence, or how the system is to be built.
Implementation constraints are dealt with during object-oriented design (OOD).
The sources for the analysis can be a written requirements statement, a formal vision document, interviews with
stakeholders or other interested parties. A system may be divided into multiple domains, representing different
business, technological, or other areas of interest, each of which are analyzed separately.
The result of object-oriented analysis is a description of what the system is functionally required to do, in the form
of a conceptual model. That will typically be presented as a set of use cases, one or more UML class diagrams,
and a number of interaction diagrams. It may also include some kind of user interface mock-up.
Object-oriented design
Object-oriented design (OOD) transforms the conceptual model produced in object-oriented analysis to take
account of the constraints imposed by the chosen architecture and any non-functionaltechnological or
environmentalconstraints, such as transaction throughput, response time, run-time platform, development
environment, or programming language.
The concepts in the analysis model are mapped onto implementation classes and interfaces. The result is a model
of the solution domain, a detailed description of how the system is to be built.
What is an Object (computer science)
In the programming paradigm of object-oriented programming, an object is the individual run-time unit that is
used as the basic building block of programs. These objects act on each other, as opposed to a traditional view in
which a program may be seen as a collection of functions, or simply as a list of instructions to the computer. Each
object is capable of receiving messages, processing data, and sending messages to other objects. Each object can
be viewed as an independent little machine or actor with a distinct role or responsibility.
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
3

In the world of OOP (object-oriented programming), an object is an instantiation (instance) of a class. A class is
only a blueprint offering a defined functionality. That functionality is actually implemented by creating an instance
of that class, in form of an object. For example, a diagram of a computer monitor is a class (let's call it
monitor_class). The actual computer monitor any particular computer user is looking into is an instance of that
class, an object. Multiple objects of the monitor_class can be created, each using the functionality defined by the
class.
Hence, in the realm of software development, to use the functionality of a particular class, an object of that class
must first be created. In the same way that to a person who wanted to drive a car, a specification of a car would
not be of any use; what is needed is a real car constructed from that specification.
Objects in object-oriented programming
In object-oriented programming (OOP), an instance of a program (i.e. a program running in a computer) is
treated as a dynamic set of interacting objects. Objects in OOP extend the more general notion of objects
described above to include a very specific kind of typing, which among other things allows for:
1. data members that represent the data associated with the object.
2. methods that access the data members in predefined ways.
In the case of most objects, the data members can only be accessed through the methods, making it easy to
guarantee that the data will always remain in a well-defined state (class invariants will be enforced). Some
languages do not make distinctions between data members and methods.
In almost all object-oriented programming languages, a dot(.) operator is used to call a particular
method/function of an object. For example, consider an arithmetic class named Arith_Class. This class contains
functions like add(), subtract(), multiply() and divide(), that process results for two numbers sent to them. This
class could be used to find the product of 78 and 69 by first of all creating an object of the class and then invoking
its multiply method, as follows:
1 int result = 0; // Initialization
2 arith_Obj1 = new Arith_Class(); // Creating a new instance of Arith_Class
3 result = arith_Obj1.multiply(78,69); // Product of 78 and 69 stored in result variable
In a language where each object is created from a class, an object is called an instance of that class. If each
object has a type, two objects with the same class would have the same datatype. Creating an instance of a class
is sometimes referred to as instantiating the class.
A real-world example of an object would be "my dog", which is an instance of a type (a class) called "dog", which
is a subclass of a class "animal". In the case of a polymorphic object, some details of its type can be selectively
ignored, for example a "dog" object could be used by a function looking for an "animal". So could a "cat", because
it too belongs to the class of "animal". While being accessed as an "animal", some member attributes of a "dog" or
"cat" would remain unavailable, such as the "tail" attribute, because not all animals have tails.
A ghost is an object that is unreferenced in a program, and can therefore serve no purpose. In a garbage-
collected language, the garbage collector would mark the memory occupied by the object as free, although it
would still contain the object's data until it was overwritten.
Three properties characterize objects:
1. Identity: the property of an object that distinguishes it from other objects
2. State: describes the data stored in the object
3. Behavior: describes the methods in the object's interface by which the object can be used
Some terms for specialized kinds of objects include:
Singleton object: An object that is the only instance of its class during the lifetime of the program.
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
4

Functor (function object): an object with a single method (in C++, this method would be the function
operator, "operator()") that acts much like a function (like a C/C++ pointer to a function).
Immutable object: an object set up with a fixed state at creation time and which does not vary afterward.
First-class object: an object that can be used without restriction.
Container: an object that can contain other objects.
Factory object: an object whose purpose is to create other objects.
Metaobject: an object from which other objects can be created (Compare with class, which is not
necessarily an object)
Prototype: a specialized metaobject from which other objects can be created by copying
God object: an object that knows too much or does too much. The God object is an example of an anti-
pattern.
Antiobjects: a computational metaphor useful to conceptualize and solve hard problems often with
massively parallel approaches by swapping computational foreground and background.
Object oriented design



Figure 1:An object
Object oriented design is part of OO methodology and it forces programmers to think in terms of objects, rather
than procedures, when they plan their code. An object contains encapsulated data and procedures grouped
together to represent an entity. The 'object interface', how the object can be interacted, is also defined. An object
oriented program is described by the interaction of these objects. Object Oriented Design is the discipline of
defining the objects and their interactions to solve a business problem that was identified and documented during
object oriented analysis.
The origins of object oriented programming is structured programming. Structured programming fell short in big
and complex programs. Object oriented methodology tries to remedy those shortfalls.
The first object oriented languages were Simula and SmallTalk. The use of object oriented languages became
popular after Grady Booch wrote the first paper titled Object-Oriented Design, in 1982.
Object oriented design is defined as a programming language that has five conceptual tools to aid the
programmer. These programs are often more readable than non-object oriented programs, and debugging
becomes easier with locality.
Input (sources) for object oriented design
Conceptual model (must have): Conceptual model is the result of object-oriented analysis, it captures
concepts in the problem domain. The conceptual model is explicitly chosen to be independent of
implementation details, such as concurrency or data storage.
Use case (must have): Use case is description of sequences of events that, taken together, lead to a
system doing something useful. Each use case provides one or more scenarios that convey how the
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
5

system should interact with the users called actors to achieve a specific business goal or function. Use
case actors may be end users or other systems.
System Sequence Diagram (should have): System Sequence diagram (SSD) is a picture that shows, for a
particular scenario of a use case, the events that external actors generate, their order, and possible inter-
system events.
User interface documentations (if applicable): Document that shows and describes the look and feel of the
end product's user interface. This is not mandatory to have, but helps to visualize the end-product and
such helps the designer.
Relational data model (if applicable): A data model is an abstract model that describes how data is
represented and used. If not object database is used, usually the relational data model should be created
before the design can start. How the relational to object mapping is done is included to the OO design.
Object oriented concepts supported by an OO language
The five basic concepts of object oriented design are the implementation level features that are built into the
programming language. These features are often referred to by these common names:
Encapsulation: A tight coupling or association of data structures with the methods or functions that act on
the data. This is called a class, or object (an object is often the implementation of a class).
Information hiding: The ability to protect some components of the object from external entities. This is
realized by language keywords to enable a variable to be declared as private or protected to the owning
class.
Inheritance: The ability for a class to extend or override functionality of another class. The so called child
class has a whole section that is the parent class and then it has its own set of functions and data.
Interface: A definition of functions or methods, and their signatures that are available for use to
manipulate a given instance of an object.
Polymorphism: The ability to define different functions or classes as having the same name but taking
different data types.
Designing concepts
Defining objects, creating class diagram from conceptual diagram: Usually map entity to class.
Identifying attributes.
Use design patterns (if applicable): A design pattern is not a finished design, it is a description of a
solution to a common problem. The main advantage of using a design pattern is that it can be reused in
multiple applications. It can also be thought of as a template for how to solve a problem that can be used
in many different situations and/or applications. Object-oriented design patterns typically show
relationships and interactions between classes or objects, without specifying the final application classes
or objects that are involved.
Define application framework (if applicable): Application framework is a term usually used to refer to a set
of libraries or classes that are used to implement the standard structure of an application for a specific
operating system. By bundling a large amount of reusable code into a framework, much time is saved for
the developer, since he/she is saved the task of rewriting large amounts of standard code for each new
application that is developed.
Identify persisted objects/data (if applicable): Identify objects that have to be persisted. If relational
database is used design the object relation mapping.
Identify, define remote objects (if applicable)
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
6

Output (deliverables) of object oriented design
Class diagram: Class diagram is a type of static structure diagram that describes the structure of a system
by showing the system's classes, their attributes, and the relationships between the classes.
Sequence diagram: Expend the System Sequence Diagram to add specific objects that handle the system
events. Usually we create sequence diagram for important and complex system events, not for simple or
trivial ones.
A sequence diagram shows, as parallel vertical lines, different processes or objects that live
simultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in which
they occur.
Programming concepts
Aspect oriented programming: One view of aspect-oriented programming (AOP) is that every major
feature of the program, core concern (business logic), or cross-cutting concern (additional features), is an
aspect, and by weaving them together (also called composition), you finally produce a whole out of the
separate aspects.
Dependency injection: The basic idea is that if an object depends upon having an instance of some other
object then the needed object is "injected" into the dependent object. For example, being passed a
database connection as an argument to the constructor instead of creating one internally
Acyclic Dependencies Principle: The dependency graph of packages or components should have no cycles.
This is also referred to as having a Directed Acyclic Graph. For example, package C depends on package
B, which depends on package A. If package A also depended on package C, then you would have a cycle.
Composite Reuse Principle: Favor polymorphic composition of objects over inheritance.
Current OO languages
Some modern languages that endorse object oriented design practices:
ActionScript
CLOS (an expansion of the Lisp Programming Language)
C++
C#
Eiffel
Java
PHP
Objective-C
Python
Ruby
Simula
SmallTalk
VB.Net
Delphi
Object-Oriented Modeling
Object-Oriented Modeling, or OOM, is a modeling paradigm mainly used in computer programming. Prior to the
rise of OOM, the dominant paradigm was functional programming, which emphasised the use of discreet reusable
code blocks that could stand on their own, take variables, perform a function on them, and return values.
The Object-Oriented paradigm assists the programmer to address the complexity of a problem domain by
considering the problem not as a set of functions that can be performed but primarily as a set of related,
interacting Objects. The modeling task then is specifying, for a specific context, those Objects (or the Class the
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
7

Objects belongs to), their respective set of Properties and Methods, shared by all Objects members of the Class.
For more discussion, see Object-oriented analysis and design and Object-oriented programming. The description
of these Objects is a Schema.
As an example, in a model of a Payroll System, a Company is an Object. An Employee is another Object.
Employment is a Relationship or Association. An Employee Class (or Object for simplicity) has Attributes like
Name, Birthdate, etc. The Association itself may be considered as an Object, having Attributes, or Qualifiers like
Position, etc. An Employee Method may be Promote, Raise, etc.
The Model description or Schema may grow in complexity to require a Notation. Many notations has been
proposed, based on different paradigms, diverged, and converged in a more popular one known as UML.
An informal description or a Schema notation is translated by the programmer or a Computer-Aided Software
Engineering tool in the case of Schema notation (created using a Module specific to the CASE tool application) into
a specific programming language that supports Object-Oriented Programming (or a Class Type), a Declarative
Language or into a Database schema.
Object modeling language
An Object Modeling Language is a standardized set of symbols and ways of arranging them to model (part of)
an object oriented software design or system design.
Some organizations use them extensively in combination with a software development methodology to progress
from initial specification to an implementation plan and to communicate that plan to an entire team of developers
and stakeholders. Because a modeling language is visual and at a higher-level of abstraction than code, using
models encourages the generation of a shared vision that may prevent problems of differing interpretation later in
development. Often software modeling tools are used to construct these models, which may then be capable of
automatic translation to code.
First Generation
In the first generation, isolated methodologists and small groups developed techniques that solved problems they
saw first-hand in Object Oriented (OO) development projects.
The first generation includes techniques such as:
Booch method
Class-Responsibility-Collaboration card (CRC)
Object-modeling technique (OMT)
Object-oriented software engineering (OOSE)
Shlaer-Mellor
Yourdon-Coad (see Edward Yourdon)
The first generation languages were co-developed and very closely tied with specific object-oriented
methodologies usually with the same name. It was often difficult to determine whether the notation or
methodology was being referred to.
Second Generation
The second generation recognized that many best practices were scattered among the fragmented OO
methodology landscape. Several attempts were made to gather these practices into coherent frameworks such as
FUSION. However, the OO community was beginning to recognize the benefits that industry standardization would
bring: not just a good way of doing things, but the good way, which would lead to common parlance and practice
among developers.
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
8
Third Generation
The third generation consists of credible attempts at this single industry-standard language, with Unified Modeling
Language (UML) being the primary example. By this time, the futility of standardizing the method was recognized,
and the languages developed into notations that are suitable for a wide range of development methods.
Booch method


Class diagram
The Booch method is a technique used in software engineering. It is an object modeling language and
methodology that was widely used in object-oriented analysis and design. It was developed by Grady Booch while
at Rational Software (now part of IBM).
The notation aspect of the Booch method has now been superseded by the Unified Modeling Language (UML),
which features graphical elements from the Booch method along with elements from the object-modeling
technique (OMT) and object-oriented software engineering (OOSE).
Methodological aspects of the Booch method have been incorporated into several methodologies and processes,
the primary such methodology being the Rational Unified Process (RUP).
Class-Responsibility-Collaboration card
Class-Responsibility-Collaboration cards (CRC cards) are a brainstorming tool used in the design of object-
oriented software. They were proposed by Ward Cunningham. They are typically used when first determining
which classes are needed and how they will interact.
CRC cards are usually created from index cards on which are written:
1. The class name
2. Its Super and Sub classes (if applicable)
3. The responsibilities of the class.
4. The names of other classes that the class will collaborate with to fulfill its responsibilities.
5. Author
Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of
the class and prevents him from getting into its details and inner workings at a time when such detail is probably
counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because
the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other
people.
A common method to determine what cards should be created is to read a specification for the program being
designed and consider if each noun should be a class and if each verb should be a responsibility of the noun or
class that it belongs to. Naturally, the existence of a noun or verb does not require a class or responsibility in the
program, but it is considered a good starting point.
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
9
Object-modeling technique


OMT object diagram


OMT state diagram
The object-modeling technique (OMT) is an object modeling language for software modeling and designing. It
was developed circa 1991 by Rumbaugh, Blaha, Premerlani, Eddy and Lorensen as a method to develop object-
oriented systems, and to support object-oriented programming.
OMT is a predecessor to the Unified Modeling Language (UML). Many OMT modeling elements are common to
UML.
Object-oriented software engineering
Object-oriented software engineering (OOSE) is an object modeling language and methodology
OOSE was developed by Ivar Jacobson in 1992 while at Objectory AB. It is the first object-oriented design
methodology to employ use cases to drive software design. It also uses other design products similar to those
used by OMT.
The tool Objectory was created by the team at Objectory AB to implement the OOSE methodology. After success
in the marketplace, other tool vendors also supported OOSE.
After Rational bought Objectory AB, the OOSE notation, methodology, and tools became superseded.
As one of the primary sources of the Unified Modeling Language (UML), concepts and notation from OOSE
have been incorporated into UML.
The methodology part of OOSE has since evolved into the Rational Unified Process (RUP).
The OOSE tools have been replaced by tools supporting UML and RUP.
OOSE has been largely replaced by the UML notation and by the RUP methodology.
Shlaer-Mellor
The Shlaer-Mellor method, developed by Sally Shlaer and Stephen J. Mellor, is one of a number of object-
oriented analysis (OOA) / object-oriented design (OOD) methods which arrived in the late 1980s in response to
perceived weaknesses in the existing structured analysis and structured design (SASD) techniques in use by
(primarily) software engineers.
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
10

Of these perceived problems, Shlaer and Mellor chose to address:
The complexity of designs generated through the use of SASD.
The problem of maintaining analysis and design documentation over time.
Principles of Modelling
Structural modeling perspective
This approach concentrates on describing the static structure. The main concept in this modeling perspective is
the entity, this could be an object, phenomena, concept, thing etc.
The data modeling languages have traditionally handled this perspective, examples of such being:
The ER-language (Entity-Relationship)
Generic Semantic Modeling language. (GSM)
Other approaches including:
The NIAM language (Binary relationship language)
Conceptual graphs (Sowa)
Looking at the ER-language we have the basic components:
Entities: Distinctively identifiable phenomenon.
Relationships: An association among the entities.
Attributes: Used to give value to a property of an entity/relationship.
Looking at the generic semantic modeling language we have the basic components:
Constructed types built by abstraction: Aggregation, generalization, and association.
Attributes.
Primitive types: Data types in GSM are classified into printable and abstract types.
Printable: Used to specify visible values.
Abstract: Representing entities.
Functional modeling perspective
This approach concentrates on describing the dynamic process. The main concept in this modeling perspective is
the process, this could be a function, transformation, activity, action, task etc. A well-known example of a
modeling language employing this perspective is data flow diagrams.
The perspective uses four symbols to describe a process, these being:
Process: Illustrates transformation from input to output.
Store: Data-collection or some sort of material.
Flow: Movement of data or material in the process.
External Entity: External to the modeled system, but interacts with it.
Now, with these symbols, a process can be represented as a network of these symbols. This decomposed process
is a DFD, data flow diagram.
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
11
Behavioral perspective
Behavioral perspective gives a description of system dynamics. The main concepts in behavioral perspective are
states and transitions between states. State transitions are triggered by events. State Transition Diagrams
(STD/STM), State charts and Petri-nets are some examples of well-known behaviorally oriented modeling
languages. Different types of State Transition Diagrams are used particularly within real-time systems and
telecommunications systems.
Rule perspective
Rule perspective gives a description of goals/means connections. The main concepts in rule perspective are rule,
goal and constraint. A rule is something that influences the actions of a set of actors. The standard form of rule is
IF condition THEN action/expression. Rule hierarchies (goal-oriented modeling), Tempora and Expert systems
are some examples of rule oriented modeling.
Object perspective
The object-oriented perspective describes the world as autonomous, communicating objects. An object is an
entity which has a unique and unchangeable identifier and a local state consisting of a collection of attributes
with assignable values. The state can only be manipulated with a set of methods defined on the object. The value
of the state can only be accessed by sending a message to the object to call on one of its methods. An event is
when an operation is being triggered by receiving a message, and the trace of the events during the existence of
the object is called the objects life cycle or the process of an object. Several objects that share the same
definitions of attributes and operations can be parts of an object class. The perspective is originally based on
design and programming of oriented systems. Unified Modelling Language (UML) is a well known language for
modelling with an object perspective.
Communication perspective
This perspective is based on language/action theory from philosophical linguistics. The basic assumption in this
perspective is that person/objects cooperate on a process/action thorough communication within them.
An illocutionary act consists of five elements: Speaker, hearer, time, location and circumstances. It is a reason
and goal for the communication, where the participations in a communication act is oriented towards mutual
agreement. In a communication act, the speaker generally can raise three claims: truth (referring an object),
justice (referring a social world of the participations) and claim to sincerity (referring the subjective world of the
speaker).
Actor and role perspective
Actor and role perspective is a description of organisational and system structure. An actor can be defined as a
phenomenon that influences the history of another actor, whereas a role can be defined as the behaviour which is
expected by an actor, amongst other actors, when filling the role. Modelling within these perspectives is based
both on work with object-oriented programming languages and work with intelligent agents in artificial
intelligence. When modelling with an actor perspective, the focus is on who and why, and to improve the
understanding of needs and the structure of requirements. I* is an example of an actor oriented language.
Model-Driven Engineering
Model-Driven Engineering (or MDE) refers to the systematic use of models as primary engineering artifacts
throughout the engineering lifecycle. MDE can be applied to software, system, and data engineering. Models are
considered as first class entities. The best known MDE initiative is the Object Management Group (OMG) called
Model-Driven Architecture (MDA), which is a registered trademark of OMG. Another related acronym is Model-
Driven Development (MDD) which is also a OMG trademark.
As it pertains to software development, Model-Driven Development refers to a range of development approaches
that are based on the use of software modeling as a primary form of expression. Sometimes models are
constructed to a certain level of detail, and then code is written by hand in a separate step. Sometimes complete
models are built including executable actions. Code can be generated from the models, ranging from system
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
12

skeletons to complete, deployable products. With the introduction of the Unified Modeling Language (UML), MDD
has become very popular today with a wide body of practitioners and supporting tools. More advanced types of
MDD have expanded to permit industry standards which allow for consistent application and results. The continued
evolution of MDD has added an increased focus on architecture and automation.
MDD technologies with a greater focus on architecture and corresponding automation yield higher levels of
abstraction in software development. This abstraction promotes simpler models with a greater focus on problem
space. Combined with executable semantics this elevates the total level of automation possible. The Object
Management Group (OMG) has developed a set of standards called Model Driven Architecture (MDA), building a
foundation for this advanced architecture-focused approach.
Model Integrated Computing is yet another branch of MDE.
According to Douglas Schmidt, model-driven engineering technologies offer a promising approach to address the
inability of third-generation languages to alleviate the complexity of platforms and express domain concepts
effectively.
Modeling language
A modeling language is any artificial language that can be used to express information or knowledge or systems
in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of
components in the structure.
A modeling language can be graphical or textual.
Graphical modeling languages use a diagram techniques with named symbols that represent concepts and
lines that connect the symbols and that represent relationships and various other graphical annotation to
represent constraints.
Textual modeling languages typically use standardised keywords accompanied by parameters to make
computer-interpretable expressions.
An example of a graphical modeling language and a corresponding textual modeling language is EXPRESS-G and
EXPRESS (ISO 10303-11).
Not all modeling languages are executable, and for those that are, the use of them doesn't necessarily mean that
programmers are no longer required. On the contrary, executable modeling languages are intended to amplify the
productivity of skilled programmers, so that they can address more challenging problems, such as parallel
computing and distributed systems.
A large number of modeling languages appear in the literature.
Examples
Example of modelling languages are:
EXPRESS and EXPRESS-G (ISO 10303-11) is an international standard general-purpose data modeling
language. It is used among others to specify various ISO standard data models, such as the application
protocols of ISO 10303 (STEP), ISO 13584, ISO 15926 and others.
Unified Modeling Language (UML) is a general-purpose modeling language that is an industry standard for
specifying software-intensive systems. UML 2.0, the current version, supports thirteen different diagram
techniques, and has widespread tool support.
Petri nets use variations on exactly one diagramming technique and topology, namely the bipartite graph.
The simplicity of its basic user interface easily enabled extensive tool support over the years, particularly
in the areas of model checking, graphically-oriented simulation, and software verification.
IDEF is a family of modeling languages, the most notable of which include IDEF0, for functional modeling,
and IDEF1 for information modeling.
M.TECH IT / CS-512 / Department of Computer Sc. & Engg / LIT
13

SysML is a Domain-Specific Modeling language for systems engineering that is defined as a UML profile
(customization).
Energy Systems Language (ESL), a language that aims to model ecological energetics & global economics.
Business Process Modeling Notation (BPNM, and the XML form BPML) is an example of a Process Modeling
language.
Fundamental Modeling Concepts (FMC) modeling language for software-intensive systems.
Gellish English, a structured subset of natural English, which includes a Gellish English dictionary and in
which facts are expressed in a standardised Gellish Database Table. Gellish English is not a meta
language, but integrates and upper ontology with domain ontologies in one language.
Applications
Various kinds of modeling languages are applied in different disciplines, including computer science, information
management, business process modeling, software engineering, and systems engineering. Modeling languages
can be used to specify system requirements, structures and behaviors. Modeling languages are intended to be
used to precisely specify systems so that stakeholders (e.g., customers, operators, analysts, designers) can better
understand the system being modeled. The more mature modeling languages are precise, consistent and
executable. Informal diagramming techniques applied with drawing tools are expected to produce useful pictorial
representations of system requirements, structures and behaviors, but not much else. Executable modeling
languages applied with proper tool support, however, are expected to automate system verification, validation,
simulation and code generation from the same representations.