Oops and Uml Tutorial 1

8/11/2019 Oops and Uml Tutorial 1

1/13

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)


2/13


2

Object-oriented analysis and design(OOAD)

Object-oriented analysis and design(OOAD) is a software engineering approach that models a system as agroup 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 thestatic 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 asystem. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications.OOA focuses on whatthe system does, OOD on howthe system does it.

Object-oriented systems

An object-oriented systemis composed of objects. The behavior of the system results from the collaboration ofthose objects. Collaboration between objects involves them sending messages to each other. Sending a messagediffers from calling a function in that when a target object receives a message, it itself decides what function tocarry out to service that message. The same message may be implemented by many different functions, the oneselected depending on the state of the target object.

The implementation of "message sending" varies depending on the architecture of the system being modeled, andthe 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 ofthe information that exists in the area being analyzed. Analysis models do not consider any implementationconstraints that might exist, such as concurrency, distribution, persistence, or how the system is to be builtImplementation 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 withstakeholders 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 whatthe system is functionally required to do, in the formof 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 takeaccount of the constraints imposed by the chosen architecture and any non-functionaltechnological orenvironmentalconstraints, such as transaction throughput, response time, run-time platform, developmentenvironment, or programming language.

The concepts in the analysis model are mapped onto implementation classes and interfaces. The result is a modelof the solution domain, a detailed description of howthe 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 isused as the basic building block of programs. These objects act on each other, as opposed to a traditional view inwhich a program may be seen as a collection of functions, or simply as a list of instructions to the computer. Eachobject is capable of receiving messages, processing data, and sending messages to other objects. Each object canbe viewed as an independent little machine or actor with a distinct role or responsibility.


3/13


3

In the world of OOP (object-oriented programming), an object is an instantiation (instance) of a class. A class isonly a blueprint offering a defined functionality. That functionality is actually implemented by creating an instanceof that class, in form of an object. For example, a diagram of a computer monitor is a class (let's call itmonitor_class). The actual computer monitor any particular computer user is looking into is an instance of thatclass, an object. Multiple objects of the monitor_class can be created, each using the functionality defined by theclass.

Hence, in the realm of software development, to use the functionality of a particular class, an object of that classmust first be created. In the same way that to a person who wanted to drive a car, a specification of a car wouldnot 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) istreated as a dynamic set of interacting objects. Objects in OOP extend the more general notion of objectsdescribed 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). Somelanguages do not make distinctions between data members and methods.

In almost all object-oriented programming languages, a dot(.) operator is used to call a particularmethod/function of an object. For example, consider an arithmetic class named Arith_Class. This class containsfunctions like add(), subtract(), multiply() and divide(), that process results for two numbers sent to them. Thisclass could be used to find the product of 78 and 69 by first of all creating an object of the class and then invokingits multiply method, as follows:

1 int result = 0; // Initialization2 arith_Obj1 = new Arith_Class(); // Creating a new instance of Arith_Class3 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 instanceof that class. If eachobject has a type, two objects with the same class would have the same datatype. Creating an instance of a classis sometimes referred to as instantiatingthe class.

A real-world example of an object would be "my dog", which is an instance of a type (a class) called "dog", whichis a subclass of a class "animal". In the case of a polymorphic object, some details of its type can be selectivelyignored, for example a "dog" object could be used by a function looking for an "animal". So could a "cat", becauseit too belongs to the class of "animal". While being accessed as an "animal", some member attributes of a "dog" o"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 objects2. State: describes the data stored in the object3.

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.


4/13


4

Functor (function object): an object with a single method (in C++, this method would be the functionoperator, "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 notnecessarily an object)

Prototype: a specialized metaobject from which other objects can be created by copying

God object: an object that knows too muchor 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 withmassively parallel approaches by swapping computational foreground and background.

Object oriented design

Figure 1:An object

Object oriented designis part of OO methodology and it forces programmers to think in terms of objects, rathethan procedures, when they plan their code. An object contains encapsulated data and procedures groupedtogether 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 ofdefining the objects and their interactions to solve a business problem that was identified and documented duringobject oriented analysis.

The origins of object oriented programming is structured programming. Structured programming fell short in bigand 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 becamepopular 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 theprogrammer. These programs are often more readable than non-object oriented programs, and debuggingbecomes easier with locality.

Input (sources) for object oriented design

Conceptual model (must have): Conceptual model is the result of object-oriented analysis, it capturesconcepts in the problem domain. The conceptual model is explicitly chosen to be independent ofimplementation details, such as concurrency or data storage.

Use case (must have): Use case is description of sequences of events that, taken together, lead to asystem doing something useful. Each use case provides one or more scenarios that convey how the


5/13


5

system should interact with the users called actors to achieve a specific business goal or function. Usecase actors may be end users or other systems.

System Sequence Diagram (should have): System Sequence diagram (SSD) is a picture that shows, for aparticular 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 andsuch helps the designer.

Relational data model (if applicable): A data model is an abstract model that describes how data isrepresented and used. If not object database is used, usually the relational data model should be createdbefore 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 theprogramming 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 isrealized by language keywords to enable a variable to be declared as privateor protectedto the owningclass.

Inheritance: The ability for a classto extend or override functionality of another class. The so called childclasshas a whole section that is theparent classand 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 tomanipulate a given instance of an object.

Polymorphism: The ability to define different functions or classesas having the same name but takingdifferent 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 asolution to a common problem. The main advantage of using a design pattern is that it can be reused inmultiple applications. It can also be thought of as a template for how to solve a problem that can be usedin many different situations and/or applications. Object-oriented design patterns typically showrelationships and interactions between classes or objects, without specifying the final application classesor objects that are involved.

Define application framework (if applicable): Application framework is a term usually used to refer to a seof libraries or classes that are used to implement the standard structure of an application for a specificoperating system. By bundling a large amount of reusable code into a framework, much time is saved forthe developer, since he/she is saved the task of rewriting large amounts of standard code for each newapplication that is developed.

Identify persisted objects/data (if applicable): Identify objects that have to be persisted. If relationadatabase is used design the object relation mapping.

Identify, define remote objects (if applicable)


6/13


6

Output (deliverables) of object oriented design

Class diagram: Class diagram is a type of static structure diagram that describes the structure of a systemby 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 otrivial ones.

A sequence diagram shows, as parallel vertical lines, different processes or objects that livesimultaneously, and, as horizontal arrows, the messages exchanged between them, in the order in whichthey occur.

Programming concepts

Aspect oriented programming: One view of aspect-oriented programming (AOP) is that every majorfeature of the program, core concern (business logic), or cross-cutting concern (additional features), is anaspect, and by weaving them together (also called composition), you finally produce a whole out of theseparate aspects.

Dependency injection: The basic idea is that if an object depends upon having an instance of some otherobject then the needed object is "injected" into the dependent object. For example, being passed adatabase 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 cyclesThis is also referred to as having a Directed Acyclic Graph. For example, package C depends on packageB, 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 therise of OOM, the dominant paradigm was functional programming, which emphasised the use of discreet reusablecode 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 byconsidering 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


7/13


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 descriptionof these Objects is a Schema.

As an example, in a model of a Payroll System, a Company is an Object. An Employee is another ObjectEmploymentis a Relationship or Association. An Employee Class(or Object for simplicity) has Attributes likeName, Birthdate, etc. The Association itself may be considered as an Object, having Attributes, or Qualifiers like

Position, etc. An Employee Methodmay be Promote, Raise, etc.

The Model description or Schema may grow in complexity to require a Notation. Many notations has beenproposed, 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 SoftwareEngineering tool in the case of Schema notation (created using a Module specific to the CASE tool application) intoa specific programming language that supports Object-Oriented Programming (or a Class Type), a DeclarativeLanguage or into a Database schema.

Object modeling language

An Object Modeling Languageis 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 progressfrom initial specification to an implementation plan and to communicate that plan to an entire team of developersand stakeholders. Because a modeling language is visual and at a higher-level of abstraction than code, usingmodels encourages the generation of a shared vision that may prevent problems of differing interpretation later indevelopment. Often software modeling tools are used to construct these models, which may then be capable ofautomatic translation to code.

First Generation

In the first generation, isolated methodologists and small groups developed techniques that solved problems theysaw 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-orientedmethodologies 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 OOmethodology landscape. Several attempts were made to gather these practices into coherent frameworks such asFUSION. However, the OO community was beginning to recognize the benefits that industry standardization wouldbring: not just agood way of doing things, but thegood way, which would lead to common parlance and practiceamong developers.


8/13


8

Third Generation

The third generationconsists of credible attempts at this single industry-standard language, with Unified ModelingLanguage (UML) being the primary example. By this time, the futility of standardizing the method was recognizedand 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 whileat 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-modelingtechnique (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 determiningwhich classes are needed and how they will interact.

CRC cards are usually created from index cards on which are written:

1.

The class name2. 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 ofthe 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. Becausethe cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with otherpeople.

A common method to determine what cards should be created is to read a specification for the program beingdesigned and consider if each noun should be a class and if each verb should be a responsibility of the noun orclass that it belongs to. Naturally, the existence of a noun or verb does not require a class or responsibility in theprogram, but it is considered a good starting point.


9/13


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 toUML.

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 designmethodology to employ use cases to drive software design. It also uses other design products similar to thoseused by OMT.

The tool Objectory was created by the team at Objectory AB to implement the OOSE methodology. After successin 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 OOSEhave 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 toperceived weaknesses in the existing structured analysis and structured design (SASD) techniques in use by(primarily) software engineers.


10/13


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 isthe 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 amodeling 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 processis a DFD, data flow diagram.


11/13


11

Behavioral perspective

Behavioral perspective gives a description of system dynamics. The main concepts in behavioral perspective arestates 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 modelinglanguages. Different types of State Transition Diagrams are used particularly within real-time systems andtelecommunications 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 isIF condition THEN action/expression. Rule hierarchies (goal-oriented modeling), Tempora and Expert systemsare some examples of rule oriented modeling.

Object perspective

The object-oriented perspective describes the world as autonomous, communicating objects. An object is anentity which has a unique and unchangeable identifier and a local state consisting of a collection of attributeswith assignable values. The state can only be manipulated with a set of methods defined on the object. The valueof the state can only be accessed by sending a message to the object to call on one of its methods. An event iswhen an operation is being triggered by receiving a message, and the trace of the events during the existence o

the object is called the objects life cycle or the process of an object. Several objects that share the samedefinitions of attributes and operations can be parts of an object class. The perspective is originally based ondesign and programming of oriented systems. Unified Modelling Language (UML) is a well known language formodelling with an object perspective.

Communication perspective

This perspective is based on language/action theory from philosophical linguistics. The basic assumption in thisperspective 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 reasonand goal for the communication, where the participations in a communication act is oriented towards mutualagreement. 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 thespeaker).

Actor and role perspective

Actor and role perspective is a description of organisational and system structure. An actor can be defined as aphenomenon that influences the history of another actor, whereas a role can be defined as the behaviour which isexpected by an actor, amongst other actors, when filling the role. Modelling within these perspectives is basedboth on work with object-oriented programming languages and work with intelligent agents in artificiaintelligence. When modelling with an actor perspective, the focus is on who and why, and to improve theunderstanding 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 artifactsthroughout the engineering lifecycle. MDE can be applied to software, system, and data engineering. Models areconsidered as first class entities. The best known MDE initiative is the Object Management Group (OMG) calledModel-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 approachesthat are based on the use of software modeling as a primary form of expression. Sometimes models areconstructed to a certain level of detail, and then code is written by hand in a separate step. Sometimes completemodels are built including executable actions. Code can be generated from the models, ranging from system


12/13


12

skeletons to complete, deployable products. With the introduction of the Unified Modeling Language (UML), MDDhas become very popular today with a wide body of practitioners and supporting tools. More advanced types ofMDD have expanded to permit industry standards which allow for consistent application and results. The continuedevolution 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 ofabstraction 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 ObjectManagement Group (OMG) has developed a set of standards called Model Driven Architecture (MDA), building afoundation 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 theinability of third-generation languages to alleviate the complexity of platforms and express domain conceptseffectively.

Modeling language

A modeling languageis any artificial language that can be used to express information or knowledge or systemsin a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning ofcomponents in the structure.

A modeling language can be graphical or textual.

Graphicalmodeling languages use a diagram techniques with named symbols that represent concepts andlines that connect the symbols and that represent relationships and various other graphical annotation torepresent constraints.

Textualmodeling languages typically use standardised keywords accompanied by parameters to makecomputer-interpretable expressions.

An example of a graphical modeling language and a corresponding textual modeling language is EXPRESS-G andEXPRESS (ISO 10303-11).

Not all modeling languages are executable, and for those that are, the use of them doesn't necessarily mean thatprogrammers 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 parallecomputing 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 modelinglanguage. It is used among others to specify various ISO standard data models, such as the applicationprotocols 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 forspecifying software-intensive systems. UML 2.0, the current version, supports thirteen different diagramtechniques, 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, particularlyin 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.


13/13


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 inwhich facts are expressed in a standardised Gellish Database Table. Gellish English is not a metalanguage, 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, informationmanagement, business process modeling, software engineering, and systems engineering. Modeling languagescan be used to specify system requirements, structures and behaviors. Modeling languages are intended to beused to precisely specify systems so that stakeholders (e.g., customers, operators, analysts, designers) can betteunderstand the system being modeled. The more mature modeling languages are precise, consistent andexecutable. Informal diagramming techniques applied with drawing tools are expected to produce useful pictoriarepresentations 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.

Documents

Oops and Uml Tutorial 1