information modeling requirement analysis n.
Skip this Video
Loading SlideShow in 5 Seconds..
Information Modeling Requirement Analysis PowerPoint Presentation
Download Presentation
Information Modeling Requirement Analysis

Loading in 2 Seconds...

play fullscreen
1 / 128

Information Modeling Requirement Analysis - PowerPoint PPT Presentation

  • Uploaded on

Information Modeling Requirement Analysis. PREPARED BY SARA IZADPANAHI GULSAH TASEL PHILLIPS AGBOOLA. Outline. Introduction The concept of information modeling Information Modeling Procedure Modeling Methodologies Entity Relationship Approach Functional Modeling Approach

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Information Modeling Requirement Analysis' - gazelle

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
information modeling requirement analysis

Information Modeling Requirement Analysis







  • Introduction
  • The concept of information modeling
    • Information Modeling Procedure
  • Modeling Methodologies
    • Entity Relationship Approach
    • Functional Modeling Approach
    • Object Oriented Approach
  • The holonic philosophy
  • Case study with UML
  • Benefits of virtual reality

The combination of emerging technologies, global competition, and market diversification is imposing a great need for transferring information timely and reliably. Today's manufacturing industry greatly relies on computer technology to support activities throughout a product’s life cycle. Effective and efficient information sharing and exchange among computer systems have been critical issues.

For example, in the manufacturing industry, not only can design and manufacturing work be conducted through integrated CAD/CAM processes with electronic linkages to carriers, such as FedEx and UPS, but the entire project and process management activities can be monitored electronically from ideation to product delivery.

information modeling
Information Modeling
  • An information model is essential to provide the structure for information that is transferred in a communication. An information model is a formal description of a portion of interest of the real world and that provides explicit rules to enable the data items that populate the model to be interpreted without ambiguity.
  • An example of an information model is the structure of a sentence in a natural language. The grammar of the natural language provides the rules for interpretation of the information model (sentence) and the data items in the structure are the words of the language. To complete the capability to interpret the communication correctly a dictionary that defines the meanings of the data items (words) is also needed. To achieve unambiguous communication, everyone in the communication process must use the same information model and the same dictionary. If the communication process is between two computer software systems then the information model and the dictionary also have to be computer processable. A dictionary also has to have an information model to provide a structure for the items and their definitions.
requirement analysis
Requirement Analysis

In the requirements analysis phase of information modeling development, Wand and Weber state[1], “High-quality conceptual modeling work is important because it facilitates early detection and correction of system development errors.” The Standish Group Project, an international consultancy, released a case study report [2] based on more than 30,000 organizations. It stated that for all the software projects developed, only 16% of them succeed. For the rest of 84%, 31% were totally failed, and 53% had cost and time overruns and missing features. According to another report by McConnell [3], the causes of software failure mainly concentrate on: objectives not fully specified (51%) and bad planning and poor estimating (48%). If we can understand customer’s requirements more accurately in the requirements analysis and model the business context to facilitate the implementation of software, then we can increase the probability of success greatly.


Information Modeling Procedure

A quality information model should be complete, sharable, stable, extensible, well-structured, precise, and unambiguous.

In general, the contents of an information model include

- Scope

- Information requirements


Information modeling starts with the definition of the scope of the model‘s applicability. The scope specifies the domain of discourse and the processes that are to be supported by the information model. It is a bounded collection of processes, information, and constraints that satisfy some industry need.

The scope statements include the purpose as well as viewpoints of the model mentioned bellow:

type of product,

type of data requirements,

supporting manufacturing scenario,

supporting manufacturing activities,

supporting stage in the product life cycle.

scope cont
Scope (Cont)

The scope definition may be supported by an activity model and/or a data planning model. An activity model is a representation of the application context, data flows, and the processes of the application. It is a mechanism for gathering high level information requirements. A data planning model provides a high level description of the data requirements for the information model, as well as the relationships among the basic data components. It is used as a roadmap to establish interfaces across a wide range of data.

A well-defined scope should be accurate, unambiguous, viable, and meet the industrial need. During the course of the modeling, the scope should be revisited and may be refined. Since the scope provides the boundaries of the application domain, it also serves as a guideline for evaluating the “completeness” of the information model.

information requirement
Information Requirement

After the scope is defined, the next phase is to conduct a requirements analysis. There is no standard method for collecting information requirements. However, requirements analysis may be accomplished by:

- Literature surveys,

- Standards surveys,

-Domain experts’ interviews,

- Industrial data reviews,

-State-of-the-art assessments.

information requirement cont
Information Requirement (Cont)

Depending on the scope, the analysis may include today‘s manufacturing practices, traditional practices, and near future needs. It is important to capture data requirements accurately for the application scope while performing the requirements analysis. Industry reviews of the result of the analysis will help to ensure the completeness and correctness of the information requirements.

As the result of the requirements analysis, information requirements should be documented. The definition of each identified information item should be included in the document. This document will be a straw man for developing the information model.

modeling methodologies
Modeling Methodologies

Information modeling is a technique for specifying the data requirements that are needed within the application domain.

There are different practices in developing an information model:

- Entity Relationship Approach (ER)

- Functional Modeling Approach

- Object Oriented Approach (O-O)

entity relationship approach er
Entity Relationship Approach (ER)

The ER approach focuses on how the concepts of entities and relationships might be applied to describe information requirements.

The ER approach is based on a graphical notation technique. The basic constructs in an ER model are the entity type, the relationship type, and the attribute type. The notation is easy to understand and the technique has been useful in modeling real problems. There are commercial tools available to map ER models into commercial DBMSs (Database Management Systems). ER approach is a better selection if data requirements are at the higher levels of detail.

• E/R Models are often represented as E/R diagrams (ERDs) that

• Give a conceptual view of the database

• Can identify some problems in a design

The disadvantage of the ER model is its lack of preciseness in supporting the detailed levels.


Entity Relationship Approach (ER)

Entity-relationship models use information objects (entities) to represent objects in the real world, specify the properties of real world objects as attributes of the information objects and show the relationships between the objects. Entity-relationship models provide specifications for information about objects by the following capabilities:

….. is_a …… (entity)

… has_a ……. (attribute)

….is_related_to…. (one-to-one or one-to-many)

My name

is Sara


Entity Relationship Approach (ER)

• Example:

In a University database we might have entities for Students, Modules and Lecturers. Students might have attributes such as their ID, Name, and Course, and could have relationships with Modules and Lecturers (tutor).

• E/R Modeling is used for conceptual design

• Entities - objects or items of interest

• Attributes – facts about, or properties of, an entity

• Relationships – links between entities

• Relationships are links between two entities

• The name is given in a diamond box

• The ends of the link show cardinality

functional modeling approach
Functional Modeling Approach
  • The emphasis of the functional modeling approach is placed on specifying and decomposing system functionality.
  • The functional approach addresses the system's processes and the flow of information from one process to another. It uses objects and functions over objects as the basis. The approach often uses data-flow diagrams. A data-flow diagram shows the transformation of data as it flows through a system. The diagram consists of processes, data flows, actors, and data stores. In the case where functions are more important and more complex than data, the functional approach is recommended. This approach has been in wide use.
  • Functional Flow Block Diagram
    • End product of functional decomposition – shows sequence of system activities
    • Incrementally refine and mark inputs / outputs / controls
    • Used to illustrate system organization and major interfaces
    • Build at the later stage of Concept Generation
    • Sample system functional breakdown - see next page

Functional Modeling


System Requirements

Top-level functions


Function A

Function B

Function C

Function D

Function E

Function F

Second-level functions









Figure: System functional breakdown

levels in functional decomposition
Levels in Functional Decomposition
  • Level 0
    • This is where you start – the highest level involving one block only, i.e. a block corresponding to your system
    • Define inputs, outputs and system functionality (requirements)
  • Level 1
    • Typically referred as main system architecture
    • Architecture means the organization and interconnection between modules. Describe the operation – how modules work together.
    • Define functional requirements for each module.
  • Level 2
    • Typically shows the organization of components within a single module

Functional Modeling


Area of a cube

Top-level functions




Area of square

Second-level functions


Length of square


Length of square

Example of a System functional breakdown

object oriented approach o o
Object Oriented Approach (O-O)

The O-O approach focuses on identifying objects from the application domain first and then operations and functions.

In the objected-oriented approach, the fundamental construct is the object, which incorporates both data structures and functions. The building blocks in the O-O model are object classes, attributes, operations, and associations (relationships.) The objected-oriented approach has the following advantages: easier modeling of complex objects, better extensibility, and easier integration with O-O DBMS and O-O programming code.

The major obstacle for using the OO approach is that the approach requires a critical paradigm shift in thinking compared with other data modeling approaches

object oriented definitions
Object Oriented Definitions
  • Object: An entity that has state, behavior, and identity.
    • State: Attribute types and values.
    • Behavior: How an object acts and reacts.
      • Behavior is expressed through operations that can be performed on it.
      • Behavior is sometimes referred to as a method or service.
    • Identity: Every object has a unique identity.
  • Class: Set of objects that share a common structure and a common behavior.
object oriented paradigm
Object-Oriented Paradigm
  • Our Word is a collection of collaborating entities


Sales dept.






object oriented paradigm1
Object-Oriented Paradigm
  • Organize software according to the structure of the world

Management Information










Laboratory Object

Design Object


Requirement analysis,

Specification, Design



Platform M⇒M'

Real World


Design D⇒D'

Programming, Test

Program S⇒S‘

description of the world
Description of the World
  • How do we describe the world?
    • Class concept + Relations among classes
  • Class as a set of “similar objects” in the world
    • Abstraction :{professor Hashemipour, professor Hacisevki,…}

 class “professor”

    • Instantiation : “professor”  professor Hashemipour
    • Class concepts provides economy and reuse of thought and description.

Objects and Classes











Prof. Hacisevki


Majid Hashemipour





Hasan Hacisevki












relationships among classes
Relationships Among Classes
  • Class Hierarchy, Inheritance,
    • Specialization/Generalization
    • City< Country < World
  • Composition, Aggregation,
    • Automobile=Body+Wheels+Steering+Engine
  • Association, a general relation between classes


two major issues in object oriented methodology
Two Major Issues in Object-Oriented Methodology
  • Object-Oriented Analysis/Design
    • BOOCH, OMT, UML, Catalysis methods
    • Constraints, Formal Approach, Analysis Patterns,Unified Process, …
  • Object-Oriented Programming
    • OO languages: Smalltalk, C++, Java
    • Design Patterns, Frameworks , Class Libraries …
object oriented vs entity relationship
Object Oriented vs. Entity Relationship
  • Most of concepts for entity-relationship modeling will correspond to concepts
  • in object-oriented modeling
  • - Object-oriented model has MORE features

Object Oriented


Entity type


Entity instance




Inheritance of attributes

Inheritance of attributes

Inheritance of behavior

No representation of behavior

Inheritance : methods and/or attributes defined in an object class can be inherited or reused by another object class.

association : relationship between different objects of one more classes.

choice of modeling methodology
Choice of Modeling Methodology



be thrown



Choosing an appropriate modeling methodology is a judgment that must be made at the beginning of the modeling work. In general, an information model, developed in any methodology, is a representation of entities, attributes, and relationships among entities. However, each information model has a different emphasis. The emphasis often depends on the viewpoint associated with the model. Occasionally there are multiple viewpoints for the model. The viewpoints of the model help to decide the type of information modeling methodology to be used.


Choice of Modeling Methodology

-Differences between functional and objected oriented programming can be summed up as follows:

-In object oriented programming everything (or almost everything) is treated as an object that can be modified and that can perform tasks, or in OOP speak one might say objects have state and behavior. What it buys you (among other more advanced things) is: modularity, and data hiding.

-Here is an example: You might have an object that models a ball, from above the ball can be modified (i.e. you can change its state) for example you may be able to change the color of the ball. It can also perform tasks (i.e. it also has behavior) for example the ball can roll, or be thrown. As an object it is bundled neatly in a package that provides methods to change the state of the ball, and to make the ball perform actions. This package is usually called a module, in addition to the methods used to change state, and perform actions, the module also has data that is used to store any state information needed.


Choice of Modeling Methodology

Because this module is a complete package that models your object completely, the module can easily be reused in many different applications. Once it is written and working anyone should be able to use the module without fully understanding internals. For example all one needs to know is that they want a red ball to throw. Here is a good resource on OOP: "Object-Oriented programming concepts” [1]

In functional programming what you have basically are a set of functions each of which performs a task. Selectively executing these function results in the solution to the problem at hand. For example you might have a function that takes the coordinates. of a square computes the area, and you may have another function that computes the area of a triangle. By executing the square function 6 times you could compute the area of a cube. Or by executing a combination of the square and triangle functions you could compute the area of a rhomboid. As you can see you can build quite complex systems based on simple functions.

modeling language
Modeling Language

Quite a few information modeling languages, for different methodologies, have been developed. These information modeling languages provide various ways of formally representing an information model. An information modeling language is a formal syntax that allows users to capture data semantics and constraints. Languages for information models have continued to evolve: the Integrated Computer Aided Manufacturing (ICAM) Definition Language 1 Extended (IDEF1X) ,the EXPRESS Language, and the Unified Modeling Language (UML) are some examples.

In general, the languages are presented in two forms:

- Graphical form

- Textual form

The graphical form is designed primarily for humans, while the textual form is for both humans and machines.

unified modeling language uml
Unified Modeling Language (UML)

UML is a modeling language for specifying, visualizing, constructing, and documenting the artifacts of software systems. It was conceived originally by Grady Booch, James Rumbaugh, and Ivar Jacobson.

It is a graphical representation and its based on the objected-oriented paradigm. UML contains notations and rules and is designed to represent data requirements in terms of O-O diagrams. UML organizes a model in a number of views that present different aspects of a system. The contents of a view are described in diagrams that are graphs with model elements. A diagram contains model elements that represent common O-O concepts such as classes, objects, messages, and relationships among these concepts.

  • Arthur Koestler : “The Ghost in the machine” (1967)
    • Herbert Simon (1969): Complex systems will evolve from simple system more rapidly if there are stable intermediate forms than if there are not
      • Two watchmakers (Bios and Mekhos)
    • “Wholes” and “part” in an absolute sense do not exist

The Holonic idea is a new paradigm develop to organize activities and meet the agile, scalable ,robust and fault-tolerant requirements, overcomes many difficulties faced by existing convectional, rigid systems in manufacturing, offices etc

the holonic concept
The Holonic concept

Holonic idea or concept is not a method or a process but a philosophy. A guiding philosophy for effective and efficient way of getting a performance better than the traditional approaches in use today

This concept can be applied to our day to day life, activities as long as efficiency is needed to be measure. Holonic idea have been applied in offices, business, industry, university.

So, it becomes paramount for us to have a full understanding of this guiding philosophy for efficiency

Next slide explains the Holonic philosophy and shows how it works.

what are holons
What are Holons?

It is a combination of holos (a greek word meaning whole) and suffix on (meaning particles or part)

A holon, as Koestler devised the term, is an identifiable part of a system that has a unique identity, yet is made up of sub-ordinate parts and in turn is part of a larger whole.

It is an autonomous and co-operative building block of a manufacturing system for transforming, transporting, storing and/or validating information and physical objects.


Holon’s Properties

  • Autonomy: the capability of an entity to create and control the execution of its own plans and/or strategies
  • Co-operation: a process whereby a set of entities develops mutually acceptable plans and executes these plans.
  • A holon self-regulates and respond to the environmental changes by using flexible strategies, and the changes are fed back to the center of its controller to continuously adjusts its course of action. The essential attributes of holons includes autonomy and cooperativeness
four quadrants of holons1
  • Four quadrants of holons is developed by a scientist called Ken Wilber as a part of his Integral theory
  • Wilber observes that each holon (and every holarchy) has at least four fundamental, different, irreducible dimensions of existence. These can be seen as four types of 'truth', actively pursued by different disciplines.
  • Wilber's proposition is that each of the four quadrants of each holon must develop in balance with each other .If one quadrant develops at a faster rate than the others, the holon will exhibit unhealthy distortions retarding the holon's functionality with the other holons at its level and above. Eventually, the holarchy will collapse back to a level of balance before it can undertake further sustained development.
holonic systems
Holonic Systems

Holarchy: a system of holons that can co-operate to achieve a goal or objective. The holarchy defines the basic rules for co-operation of the holons and thereby limits their autonomy.

Holonic manufacturing system: a holarchy that integrates the entire range of manufacturing activities from order booking through design, production, and marketing to realize the agile manufacturing enterprise.



Cooperative relationships among holons



The stability of holons and holarchies stems from holons being self-reliant units, which have a degree of independence and handle circumstances and problems on their particular level of existence without asking higher level holons for assistance.

Holons can also receive instruction from and, to a certain extent, be controlled by higher level holons. The self-reliant characteristic ensures that holons are stable, able to survive disturbances. The subordination to higher level holons ensures the effective operation of the larger whole.



In manufacturing, the term ‘Holonic’ is used to stress the concept of highly decentralized coordination and control in production system. This is especially true in the tasks of (ontology) knowledge representation, communication architecture, negotiation, coordination and cooperation principle and algorithms as well as in the corresponding standardization.

In contrast to traditional approach, a Holonic manufacturing system is constructed in a bottom-up fashion by integrating Holons in such a way that they collaborate to provide an array of system-wide characteristic .These behavioral attribute include flexibility, robustness, self-similarity, openness and so forth.

The appearance and the whole existence of Holon's are tightly connected with the requirement of system reconfigurability to support the manufacturing agility, and holons are consider as the lowest level of granularity in the reconfuguration tasks.

comparison with other approaches 1
Comparison with other approaches(1)
  • Existing approaches
    • Hierarchical control
      • Top-down
      • Strictly defined modules and their functionality
      • Autonomy of, and communication b/w modules limited
      • Sensitive to perturbation
      • Rigid architecture
      • Expensive to develop
      • Difficult to maintain
      • Low agility and responsiveness
comparison with other approaches 2
Comparison with other approaches(2)
  • Existing approaches
    • Heterarchical control
      • No hierarchy
      • Power to the basic modules (“agents”)
      • Can react adequately to changes in the environment & in the manufacturing system itself
      • Very agile
      • Simple to design, understand and maintain
      • Predictability low
      • Need for abundant resources and homogeneous environment
comparison with other approaches 21
Comparison with other approaches(2)
  • Holonic vs. hierarchical and heterarchical control
    • Autonomy to the individual modules (holons)
    • Loose hierarchy (holarchy)
    • Differences from the traditional hierarchical control
    • Holons:
      • Can belong to multiple hierarchies
      • Can form temporary hierarchies
      • Do not rely on the proper operation of each holon in the hierarchy

Basic Holons

There are three types of basic building blocks in a holonic manufacturing system (HMS):

1) Product holons,

2) Resource holons,

3) Order holons







Resource Holon

Cell Holon

Cell Holon













product holon
Product Holon

A product Holon holds the process and product knowledge to ensure the correct fabrication of the product with sufficient quality. It acts as an information server to the other Holon's in the HMS. A product Holon provides consistent and up-to-date information on the product life-cycle, user requirements, design, and process plan and bill of material.

order holon
Order Holon

An order holon represents a manufacturing order. It is an active entity responsible for performing the work correctly and on time. It explicitly captures all information and information processing of a job (Valckenaers, 1996).

resource holon
Resource Holon

A resource Holon consists of a physical part, namely a production resource in the HMS, and of an information processing part that controls the resource. It offers production capacity and functionality to the surrounding Holon's (Wyns, 1996). It holds the methods to allocate the production resources, and the knowledge and procedures to organize, use and control these production resources to drive production. A resource Holon is an abstraction for the production means such as machines, furnaces, conveyors, pipelines, pallets, components, raw materials, tools, tool holders, material storage, personnel, energy, floor space, etc.


Holonic Manufacturing Systems



Process execution knowledge

Process Knowledge

how basic holon s functions
How Basic Holon’s Functions

For a minimalistic implementation of a manufacturing system, it suffices to have a Holarchy consisting of these three basic Holon types. For instance, assume the use of a heterarchical control approach, based on a market concept, (Dilts, 1991; Joshi, 1994). In such implementation, product holons are created based on real or forecasted market demand. These product holons determine themselves how the product can be produced on the (dynamically changing) set of resource holons. They maintain all technical information needed for the fabrication of an instance of the product. When an order Holon arrives in the system, it will first discover what it needs via the respective product Holon. The order Holon will negotiate with all relevant resource holons to have itself produced by them. As such, the order Holon takes care of the logistical aspects (the resource allocation). When an operation starts, the order Holon lets the product holon and the resource holons co-operate to perform the technical part of the operation. The main contribution of this basic Holon is to get, eventually, everything manufactured in the face of disturbances, uncertainty and change.

basic holons
Basic Holons






Process execution


Process Knowledge



holons agent
Holons & Agent

The debate on clarifying the difference between holons and agents is an ongoing issue in the research communities. Given the essentially different path on which each concept was developed the question itself is inappropriate.

In response to the need for modeling the complexity of interactions in large scale Holonic systems, agent technology has emerged as a paradigm for structuring, designing and building software systems that require complex interactions between autonomous distributed Holons.


Holons & Agent

The agent paradigm models systems focusing on the underlining dynamics defined by the interactions between their parts. In contrast to the passive way in which objects communicate by invoking methods in one another in a way controlled externally by the user (e.g., from a ‘main’ program), agents are capable to initiate communication and decide (like a human) when and how to respond to external stimuli (e.g.,, manifested upon them as requests from other agents).

From this perspective the agent paradigm extends the object paradigm in that agents can be regarded as proactive objects [6] that have an internal mechanism which governs their behavior enabling them to initiate action as well as to respond to the outside environment in an autonomous way.


In terms of origin, the agent have their roots in the computer science (artificial intelligence area) and the Holons in the computer integrated manufacturing domain, focusing on the problem associated with the flexible manufacturing systems. In conceptual terms, Holon is a concept and an agent is both a concept and a technology. This make it possible to implement the Holon concept and Holonic manufacturing systems using agent technology.

  • Agent
    • It perceives the world in which it is situated.
    • It has the capability of interacting with other agents.
    • It is pro-active in the sense that it may take the initiative and persistently pursues its own goals.
  • MAS : Multi-agent system
    • A collection of, possibly heterogeneous, computational entities, having their own problem solving capabilities and which are able to interact in order to reach an overall goal.
    • MAS is seen as a system revealing a kind of synergy that would not be expected from the sum of its component agent.
agents behavior
Agents’ behavior

Customer Agent

Server Agent

Task Announcement monitoring

Task Announcement

Bid construction

Bid Evaluation

Bid Collection

Bid Submission

Task offer construction

Task offer submission

Task offer reception

Task offer evaluation

Task offer acceptance

Task Commitment

Coordination protocol b/w agent is nearly always derived from Contract Net (CNet)

agents behavior 2 2
Agents’ behavior (2/2)

Three classes of agent nodes.

Manager Node

Bidding Node

Contractor Node






Receive bids

Award bids

Task Announcement


Agent Technology

An intelligent agent is a software entity which exhibits, in some significant measure, autonomy, intelligence, and environmental awareness, and which interacts with its environment to achieve internal goals;

A multi-agent system (MAS) is a software system in which program modules (the individual agents) are given autonomy and intelligence and an underlining coordination mechanism (implementing rules for collaboration, like for holarchies) which enables collaboration between such modules (agents) to attain system objectives

multi agent architecture
Multi-agent architecture

During the last decade a couple of multi-agent architectures are developed to add organization to the multi-agent systems. The two most popular will be discussed.

1. Holonic multi-agent system

2. Multi-multi-agent system

holonic multi agent system
Holonic multi-agent system

The most popular multi-agent architecture is holonic multi-agent system, where autonomy of agents is reduced and agents are merged into holons, which appear outside as a single entity (Fischer et al, 2003). In terms of multi-agent systems holon or holonic agent is an agent that consists of other agents (subholons). Agents join or are joined into holons during the design phase to make them capable to accomplish tasks which they are not capable to deal with alone.


Holonic multi-agent system

In holonic multi-agent systems agents form a hierarchical structure, i.e., each holon can join a higher level holon and consist of lower level holons. Such hierarchical structure allows adapting the system to the structure of the domain. It is well suitable for task allocation and result sharing in the holons. If the holon has to complete a task, a task can be decomposed into some subtasks that are assigned to subholons, which can decompose them into the next level subtasks. If the agent receives a task that it is not able to accomplish it can also find other agents to create a holon, which is capable to accomplish a task. Also partial hierarchy is possible – some agents may participate in more than one holon, what gives an opportunity to create different structures (Fischer et al, 2003).


Holonic multi-agent system

Agents that form holons can be either merged into one holonical agent or keep complete autonomy. If agents are merged into one agent, benefits of distribution are lost and complicated mechanisms for merging and splitting agents are needed. If agents keep full autonomy, coordination mechanisms are needed. Thus both extremes have their drawbacks. Usually a model between these extremes is chosen: one agent (called head or head agent) is given privilege to do resource and task allocation. The head of the holon can have partial or total control over other agents. Agents that are parts of the holon, but are not head agents are called body of the holon or body agents (Gerber et al, 1999). Holons have an interface (head agent) and they can be developed separately like modules in traditional software engineering. Holons also make it easier to

implement changes in the system, because change of agent in one holon affects only agents from the same holon.

multi multi agent system
Multi-multi-agent system

The second well-known multi-agent architecture is multi-multi-agent system, which has been developed inside the Agent.Enterprise methodology (Nimis & Stockheim, 2004). This architecture is developed as a result of multi-agent system integration research. The main ideas of holonic multi-agent systems and multi-

multi-agent systems are similar. Both architectures propose to create systems that consist of subsystems. Subsystems are called holons and multi-agent systems, respectively.


Multi-multi-agent system

Multi-multi-agent systems are created from separate multi-agent systems. Interaction between multi-agent systems is held by gateway agents. Gateway agents accomplish routing and message conversion tasks between different message formats used in different multi-agent systems. Like head agent of the holon gateway agents are interfaces of their multi-agent systems. Although, it is only a mediator between agents of different multi-agent systems and it does not carry out any other tasks, like coordination, task allocation, etc. Multi-multi-agent systems have weak interaction among different multi-agent systems and intensive interaction inside the multi-agent systems. Multi-agent systems accomplish weakly coupled tasks and interact only to obtain results of other tasks. Multi-multi-agent systems offer to create one higher level (multi-multiagent

system) and one lower level (all multi-agent systems). Holonic multi-agent systems allow creating of unlimited number of levels.

what is uml
  • The Unified Modeling Language (UML) is a standard  language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems.  The UML is a very important part of developing object oriented software and the software development process.  The UML uses mostly graphical notations to express the design of software projects.  Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.
goals of uml

The primary goals in the design of the UML were:

  • Provide users with a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models.
  • Provide extensibility and specialization mechanisms to extend the core concepts.
  • Be independent of particular programming languages and development processes.
  • Provide a formal basis for understanding the modeling language.
  • Encourage the growth of the OO tools market.
  • Support higher-level development concepts such as collaborations, frameworks, patterns and components.
  • Integrate best practices.
why do we use uml
  • As the strategic value of software increases for many companies, the industry looks for techniques to automate the production of software and to improve quality and reduce cost and time-to-market. These techniques include component technology, visual programming, patterns and frameworks. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, they recognize the need to solve recurring architectural problems, such as physical distribution, concurrency, replication, security, load balancing and fault tolerance. Additionally, the development for the World Wide Web, while making some things simpler, has exacerbated these architectural problems. The Unified Modeling Language (UML) was designed to respond to these needs.
types of uml diagrams

Each UML diagram is designed to let developers and customers view a software system from a different perspective and in varying degrees of abstraction. UML diagrams commonly created in visual modeling tools include:

  • Use Case Diagram displays the relationship among actors and use cases
  • Class Diagram models class structure and contents using design elements such as classes, packages and objects. It also displays relationships such as containment, inheritance, associations and others.
types of uml diagrams1
  • Interaction Diagrams

Sequence Diagramdisplays the time sequence of the objects participating in the interaction. This consists of the vertical dimension (time) and horizontal dimension (different objects).1

Collaboration Diagramdisplays an interaction organized around the objects and their links to one another. Numbers are used to show the sequence of messages.

  • State Diagram displays the sequences of states that an object of an interaction goes through during its life in response to receivedstimuli, together with its responses and actions.
types of uml diagrams2
  • Activity Diagramdisplays a special state diagram where most of the states are action states and most of the transitions are triggered by completion of the actions in the source states. This diagramfocuses on flows driven by internal processing.
  • Physical Diagrams
  • Component Diagram displays the high level packaged structure of the code itself. Dependencies among components are shown, including source code components, binary code components, and executable components. Some components exist at compile time, at link time, at run times well as at more than one time.1
  • Deployment Diagramdisplays the configuration of run-time processing elements and the software components, processes, and objects that live on them. Software component instances represent run-time manifestations of code units
use case diagrams

A use case is a set of scenarios that describing an interaction between a user and a system.  A use case diagram displays the relationship among actors and use cases.  The two main components of a use case diagram are use cases and actors.

An actor is represents a user or another system that will interact with the system you are modeling.  A use case is an external view of the system that represents some action the user might perform in order to complete a task.

use case diagrams1
  • When to Use: Use Cases Diagrams

Use cases are used in almost every project.  The are helpful in exposing requirements and planning the project. During the initial stage of a project most use cases should be defined, but as the project continues more might become visible. 

use case diagrams2
  • How to Draw: Use Cases Diagrams

Use cases are a relatively easy UML diagram to draw, but this is a very simplified example.  This example is only meant as an introduction to the UML and use cases.

Start by listing a sequence of steps a user might take in order to complete an action.  For example a user placing an order with a sales company might follow these steps. 

  • Browse catalog and select items.
  • Call sales representative.
  • Supply shipping information.
  • Supply payment information.
  • Receive conformation number from salesperson
use case diagrams3
  • These steps would generate this simple use case diagram:
use case diagram
  • This example shows the customer as a actor because the customer is using the ordering system.  The diagram takes the simple steps listed above and shows them as actions the customer might perform.  The salesperson could also be included in this use case diagram because the salesperson is also interacting with the ordering system. 
  • From this simple diagram the requirements of the ordering system can easily be derived.  The system will need to be able to perform actions for all of the use cases listed.  As the project progresses other use cases might appear.  The customer might have a need to add an item to an order that has already been placed.  This diagram can easily be expanded until a complete description of the ordering system is derived capturing all of the requirements that the system will need to perform.
interaction diagrams sequence diagrams
  • Sequence diagrams:
  • Sequence diagrams demonstrate the behavior of objects in a use case by describing the objects and the messages they pass.  the diagrams are read left to right and descending.  The example below shows an object of class 1 start the behavior by sending a message to an object of class 2.  Messages pass between the different objects until the object of class 1 receives the final message.
interaction diagrams sequence diagrams1
  • Below is a slightly more complex example.  The light blue vertical rectangles the objects activation while the green vertical dashed lines represent the life of the object.  The green vertical rectangles represent when a particular object has control.  The represents when the object is destroyed.  This diagrams also shows conditions for messages to be sent to other object.  The condition is listed between brackets next to the message.  For example, a [condition] has to be met before the object of class 2 can send a message() to the object of class 3.
interaction diagrams sequence diagrams2
  • The next diagram shows the beginning of a sequence diagram for placing an order.  The object an Order Entry Window is created and sends a message to an Order object to prepare the order. Notice the the names of the objects are followed by a colon.  The names of the classes the objects belong to do not have to be listed.  However the colon is required to denote that it is the name of an object following the objectName:className naming system.
  • Next the Order object checks to see if the item is in stock and if the [InStock] condition is met it sends a message to create an new Delivery Item object.
interaction diagrams sequence diagrams4
  • The next diagrams adds another conditional message to the Order object.  If the item is [OutOfStock] it sends a message back to the Order Entry Window object stating that the object is out of stack.  

This simple diagram shows the sequence that messages are passed between objects to complete a use case for ordering an item.

interaction diagrams sequence diagrams5
  • In the following slides examples of different sequence diagrams will be shown.
interaction diagrams sequence diagrams6
  • In example 1, the sequence diagram shows the process of registration of a student for seminar course by an online system.
interaction diagrams sequence diagrams7
  • Example 2 shows the process of a phone connection and explains which steps should be taken before a call is connected.
interaction diagrams sequence diagrams8
  • Example 3 is a very daily example. In this sequence diagram we can see the process of money withdraw from an ATM.
what is case
What is CASE?
  • Short for Computer Aided Software Engineering, a category of software that provides a development environment for programming teams. CASE systems offer tools to automate, manage and simplify the development process. These can include tools for:
  • Summarizing initial requirements
  • Developing flow diagrams
  • Scheduling development tasks
  • Preparing documentation
  • Controlling software versions
  • Developing program code
what is case1
What is CASE?

A CASE tool repository contains all information about the system.

what is a case tool
What is a CASE tool?
  • A CASE tool is a computer-based product aimed at supporting one or more software engineering activities within a software development process.
types of case tools
Types of CASE tools

Some typical CASE tools are:

  • Configuration management tools
  • Data modeling tools
  • Model transformation tools
  • Refactoring tools
  • Source code generation tools, and
  • Unified Modeling Language

Many CASE tools not only output code but also generate other output typical of various systems analysis and design methodologies such as

  • data flow diagram
  • entity relationship diagram
  • logical schema
  • Program specification
  • SSADM.
  • User documentation
p otential case t ool b enefits
  • Forward engineering (code generation)
  • Reverse engineering of existing code
  • Support for changing levels of abstraction (e.g. from requirements to analysis to design to code)
  • Testing of the consistency and validity of your models
  • Synchronization of models with delivered code
  • Support for different views and/or potential solutions to a problem
  • Generation of documentation
r isks and associated controls
  • Common CASE risks and associated controls include:
  • Inadequate Standardization : Linking CASE tools from different vendors (design tool from Company X, programming tool from Company Y) may be difficult if the products do not use standardized code structures and data classifications. File formats can be converted, but usually not economically. Controls include using tools from the same vendor, or using tools based on standard protocols and insisting on demonstrated compatibility. Additionally, if organizations obtain tools for only a portion of the development process, they should consider acquiring them from a vendor that has a full line of products to ensure future compatibility if they add more tools.
r isks and associated controls1
  • Unrealistic Expectations : Organizations often implement CASE technologies to reduce development costs. Implementing CASE strategies usually involves high start-up costs. Generally, management must be willing to accept a long-term payback period. Controls include requiring senior managers to define their purpose and strategies for implementing CASE technologies.
r isks and associated controls2
  • Quick Implementation : Implementing CASE technologies can involve a significant change from traditional development environments. Typically, organizations should not use CASE tools the first time on critical projects or projects with short deadlines because of the lengthy training process. Additionally, organizations should consider using the tools on smaller, less complex projects and gradually implementing the tools to allow more training time.
r isks and associated controls3
  • Weak Repository Controls : Failure to adequately control access to CASE repositories may result in security breaches or damage to the work documents, system designs, or code modules stored in the repository. Controls include protecting the repositories with appropriate access, version, and backup controls
As it is seen in the previous slide by using CASE tools we can both generate diagrams and codes at the same time.
a case study using uml
A case study using UML
  • In this project, as an implementation of our research a case study is covered. In this part of our presentation, details about our case study will be covered.
a case study using uml4
A case study using UML
  • PPS actor stands for production planning scheduling actor.
  • Mediator can be called the messenger.
a case study using uml5
A case study using UML
  • The PPS sends at the time 11 p.m. an order to the assembly line about the production of 50 switches within 1 hour. The assembly robots rejects the order. One assembly robot tells the PPS about the rejection of the order.


PPS Actor


Robot X

Robot Y

Robot Z

Order Submission

Order Submission

Order Submission

Order Submission

Order Rejection

Order Rejection

Order Rejection

Order Rejection

Order Rejection

Order Rejection

Order Acceptance

Order Acceptance

Order Acceptance

Order Acceptance

Order Acceptance

a case study using uml6
A case study using UML
  • By following the same procedure, we created 2 more scenarios about the same assembly line. In the following slides, scenarios and their sequence diagrams will be shown.
a case study using uml7
A case study using UML
  • The PPS sends at the time 11 p.m. an order to the assembly line about the production of 50 switches within 1 hour. Robot X and Robot Y sends rejection message but Robot Z accepts the order.


PPS Actor


Robot X

Robot Y

Robot Z

Order Submission

Order Submission

Order Submission

Order Submission

Order Rejection

Order Rejection

Order Rejection

Order Rejection

Order Rejection

Order Rejection

Order Acceptance

Order Acceptance

Order Acceptance

Order Acceptance

Order Acceptance

a case study using uml8
A case study using UML
  • In this scenario, Robot X has a breakdown. First PPS asks Robot Y and Z to produce Robot X’s workload which is 20 units at that time. Robot Y and Z rejects the order and tell PPS that they are capable of producing 10 units. After PPS gets the message, PPS sends an order of 10 units to Y and Z. Finally they accept the order.

PPS Actor


Robot X

Robot Y

Robot Z

Breakdown of robot X

Breakdown of robot X

Breakdown of robot X

Breakdown of robot X

Produce 20 units

Produce 20 units

Produce 20 units

Rejection (capable of producing 10 units)

Rejection (capable of producing 10 units)

Rejection (capable of producing 10 units)

Rejection (capable of producing 10 units)

Rejection (capable of producing 10 units)

Y is capable of 10

X is capable of 10

Each Y & X produce 10

Produce 10 units

Produce 10 units






Order accepted

a case study using uml9
A case study using UML
  • As it is seen in the scenarios, UML plays an important role in the representation of the negotiation scenarios. After this stage, codes should be generated for this negotiations. Codes generated by JADE designed by other group will be shown in their presentation.

Y. Lee Information modeling from Design to Implementation (2005)

Mert Bal PhD Dissertation:Design and development of a virtual reality-based simulation system for agile manufacturing,  Eastern Mediterranean University, Mechanical Engineering Department(2008)

German-Tunisia Conference on Smart Systems and Device

Proceeding of the 38th Hawaii International Conference on System Science (2005) (Assoc Prof Dr. MajidHashemipour)


Mert Bal, MajidHashemipour and H.Manesh, Virtual-reality-based information requirements analysis tool for CIM system implementation: a case study in die-casting industry, International Journal of Computer Integrated Manufacturing, 1 – 14, 2007.

Hashemipour M., Deniz, D. Topuz,C "Computer- supported information requirement analysis tool based on novel methodology for analysing CIM information requirement". Robotics and Computer-Integrated Manufacturing Journal,2000, (16) 211-214.

Hashemipour M, Kayaligil S. Identifying integration types for requirement analysis in CIM development. Integrated Manuf Sys J, 1999; 10 (3-4):pp 170-178.

Mert Bal and MajidHashemipour, Virtual factory approach for implementation of holonic control in industrial applications: a case study in die-casting industry, Robotics and Computer Integrated Manufacturing  (sent for publication, under review, 2007 ).


Mert Bal and MajidHashemipour, Virtual reality for designing holonic agile manufacturing systems,  Int. Journal of Information Sciences, (sent for publication, under review, Ref. No. IS05-IMS2006-032).

Mert Bal and MajidHashemipour, Applications of virtual reality in design and simulation of holonic manufacturing systems: a demonstration in die-casting industry, Lecture Notes in Artificial Intelligence, Vladimir Marik, ValeriyVyatkin, Armando Colombo (Eds.), pp 421-432, 2007.

Valuable Contributions of HamedFarahaniManesh

Valuable Contributions from The ME 561 Class