Transcript Information Modeling: Requirement Analysis

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
•Object Oriented Approach
•The holonic philosophy
•Case study with UML
•Benefits of virtual reality
Introduction
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
•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
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
Scope





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)
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
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)
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
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)


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. Entityrelationship models provide specifications for information about objects by the
following capabilities:
….. is_a …… (entity)
My name
is Sara
… has_a ……. (attribute)
….is_related_to…. (one-to-one or one-to-many)
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 are links between two
• Relationships – links between entities
entities
• The name is given in a diamond box
• The ends of the link show cardinality
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
Level-0
System Requirements
Top-level functions
Level-1
Function A
Function B
Function C
Function E
Function D
Function F
Second-level functions
Level-2
E.2
E.1
E.4
E.5
E.3
E.3
Figure: System functional breakdown
E.6
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
Level-0
Area of a cube
Top-level functions
Level-1
6
*
Area of square
Second-level functions
Level-2
Length of square
*
Length of square
Example of a System functional breakdown
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: 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

Our Word is a collection of collaborating
entities
President
Sales dept.
Factory
Factory
workers
Engineers
Scientists
Object-Oriented Paradigm

Organize software according to the structure of
the world
Factory
Management
Object
Management Information
Object
Sales
Dept.
Object
Worker
Object
Design Object
Laboratory Object
Requirement analysis,
Specification, Design
Problem
Ｐ⇒Ｐ'
Real
World
Ｗ⇒Ｗ'
Platform Ｍ⇒Ｍ'
m
o
d
u
l
e
A
m
o
d
u
l
e
B
m
o
d
u
l
e
C
m
o
d
u
l
e
D
m
o
d
u
l
e
E
b
f
c
a
d
Design Ｄ⇒Ｄ'
Programming, Test
(
d
e
f
u
n
(
r
c
s
w
r
i
t
e
e
(
i
f
(
e
r
r
o
r
o
c
c
u
r
r
e
d
(
w
r
i
t
e
c
u
r
r
e
n
t
f
i
l
e
)
)
(
i
f
b
u
f
f
e
r
i
s
m
o
d
i
f
i
e
d
(
d
o
c
h
e
c
k
o
u
t
(
c
u
r
r
e
n
t
b
u
f
f
e
r
n
a
m
e
)
)
)
)
(
n
o
v
a
l
u
e
)
)
(
d
o
c
h
e
c
k
o
u
t
c
b
u
f
c
o
f
n
a
m
e
(
s
e
t
q
c
b
u
f
(
a
r
g
1
)
)
(
s
e
t
q
c
o
f
n
a
m
e
(
a
r
g
2
)
)
(
i
f
(
|
(
f
i
l
e
e
x
i
s
t
s
(
c
o
n
c
a
t
"
R
C
S
/
"
c
b
u
f
"
.
v
"
)
)
(
p
r
o
g
n
(
m
e
s
s
s
a
g
e
"
p
l
e
a
s
e
w
a
i
t
,
n
o
w
l
o
o
k
i
n
g
"
)
(
e
x
e
c
u
t
e
m
o
n
i
t
o
c
o
m
m
a
n
d
(
c
o
n
c
a
t
.
.
.
(
m
e
s
s
a
g
e
"
d
o
n
e
"
)
Program Ｓ⇒Ｓ‘
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
Cyprus
object:
Iran
Prof.Hashemipour
Italy
Prof. Hacisevki
hasName:
hasName:
Majid Hashemipour
Hasan Hacisevki
hasphoneNo:
hasphoneNo:
1354
1386
teach
Attribute
Turkey
abstraction
instantiation
class:
Country
lives-in
Class:Professor
teach
Hasname:String
Relationship
hasphoneNo:int
teach
Behavior
Relationships Among Classes

Class Hierarchy, Inheritance,
Specialization/Generalization
 City< Country < World


Composition, Aggregation,


Automobile＝Body＋Wheels＋Steering＋Engine
Association, a general relation between classes
People―（lives-in）―Country
Two Major Issues in ObjectOriented 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
- Most of concepts for entity-relationship modeling will correspond to concepts
in object-oriented modeling
- Object-oriented model has MORE features
Object Oriented
Class
Object
Association
Inheritance of attributes
Inheritance of behavior
ER
Entity type
Entity instance
Relationship
Inheritance of attributes
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
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.
hascolour
Rolls,
be thrown
AREA OF A RHOMBOID?
BALL?
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
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)
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.
HOLONIC
CONCEPT
BACKGROUND

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

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.
HOLONIC PHILOSPHY
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 HOLONS
FOUR QUADRANTS OF HOLONS



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

Holarchy: a system of holons that can cooperate to achieve a goal or objective. The
holarchy defines the basic rules for cooperation 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.
HOLONIC SYSTEMS
Cooperative relationships among holons
HOLONIC SYSTEMS

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.
HOLONIC SYSTEMS
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)

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)

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(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
Comparison of holonic with other systems
Conventional vs. Holonic
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
TYPES OF HOLONS AND THEIR RELATION WITH EACHOTHER
Order
Holon
Product
Holon
Resource
Holon
Cell
Holon
Cell
Holon
Machin
e
Holon
AVG
Holon
Robot
Holon
Machin
e
Holon
AVG
Holon
Robot
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
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
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
Production
knowledge
Process execution knowledge
Process Knowledge
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
HOLONIC MANUFACTURING SYSTEM
ORDER HOLON
Production
Knowledge
Process execution
Knowledge
PRODUCT HOLON
Process Knowledge
RESOURCE
HOLON
Resource Holon
Adding new resources
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
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.
Agent
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


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

Coordination protocol b/w agent is nearly always derived from Contract Net
(CNet)
Customer Agent
Task
Announcement
Bid Evaluation
Task offer
construction
Server Agent
Task
Announcement
monitoring
Bid Collection
Bid Submission
Task offer
submission
Task offer
reception
Task Commitment
Task offer
acceptance
Bid
construction
Task offer
evaluation
Agents’ behavior (2/2)

Three classes of agent nodes.
 Manager Node
 Bidding Node
 Contractor Node
Potential
bidders
Bidders
Contractor
Manager
Task Announcement
Receive bids
Award bids
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
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
The most popular multi-agent architecture is holonic multiagent 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
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 multimulti-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. Multimulti-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 (multimultiagent
system) and one lower level (all multi-agent systems). Holonic multi-agent
systems allow creating of unlimited number of levels.
INTRODUCTION
TO UML
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 DIAGRAMS

o
Interaction Diagrams
Sequence Diagram displays the time sequence
of the objects participating in the interaction.
This consists of the vertical dimension (time)
and horizontal dimension (different objects).1
Collaboration Diagram displays 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 received stimuli,
together with its responses and actions.
TYPES OF UML DIAGRAMS




Activity Diagram displays 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
diagram focuses 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 Diagram displays 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 DIAGRAMS

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 DIAGRAMS






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 DIAGRAMS

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 DIAGRAMS)

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 DIAGRAMS)


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 DIAGRAMS)
INTERACTION DIAGRAMS
(SEQUENCE DIAGRAMS)

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 DIAGRAMS)

In the following slides examples of different
sequence diagrams will be shown.
Example 1
INTERACTION DIAGRAMS
(SEQUENCE DIAGRAMS)

In example 1, the sequence diagram shows the
process of registration of a student for seminar
course by an online system.
Example 2
INTERACTION DIAGRAMS
(SEQUENCE DIAGRAMS)

Example 2 shows the process of a phone
connection and explains which steps should be
taken before a call is connected.
Example 3
INTERACTION DIAGRAMS
(SEQUENCE DIAGRAMS)

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?

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 CASE?
A CASE tool repository contains all information about the system.
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
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.
POTENTIAL CASE TOOL
BENEFITS







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
RISKS 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.
RISKS and ASSOCIATED
CONTROLS

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.
RISKS and ASSOCIATED
CONTROLS

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.
RISKS and ASSOCIATED
CONTROLS

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

Picture on the
right shows the
process of data
modeling using
UML and case
tools.
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

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 UML
A case study using UML
A case study using UML
A case study using UML


PPS actor stands for production planning
scheduling actor.
Mediator can be called the messenger.
A case study using UML


SCENARIO 1:
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.
SEQUENCE DIAGRAM FOR SCENARIO 1
PPS Actor
Mediator
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
Robot X
Robot Y
Robot Z
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 UML


SCENARIO 2:
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.
SEQUENCE DIAGRAM FOR SCENARIO 2
PPS Actor
Mediator
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
Robot X
Robot Y
Robot Z
A case study using UML


SCENARIO 3:
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
Mediator
Robot X
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)
Y is capable of 10
X is capable of 10
Rejection (capable of producing 10 units)
Each Y & X produce 10
Produce 10 units
Produce 10 units
Acceptance
Acceptance
Acceptance
Acceptance
Acceptance
Order accepted
Robot Y
Robot Z
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.
References



http://ieeexplore.ieee.org/stamp/stamp.jsp?arnum
ber=00171872
http://www.emeraldinsight.com/Insight/viewPD
F.jsp?contentType=Article&Filename=html/Out
put/Published/EmeraldFullTextArticle/Pdf/0680
140706.pdf
http://www.heverhagen.com/ssd.pdf

Y. Lee Information modeling from Design to Implementation (2005)
Mert Bal PhD Dissertation:Design and development of a virtual realitybased simulation system for agile manufacturing, Eastern Mediterranean
University, Mechanical Engineering Department(2008)
www.eng2.uconn.edu/msl/paper/holonic/paper1.html
hms.ifw.uni-hannover.de
dei.isep.ipp.pt/~nsilva/R&D/Publications/1998/..

cse.unr.edu/~npenrod/lib/exe/fetch.php?...&media=fulltext.pdf










www.mech.kuleuven.be/goa/concepts.htm
en.wikipedia.org/wiki/Information_model
gilbane.com/.../What_is_an_Information_Model__Why_do_You_Need_On
e.html
German-Tunisia Conference on Smart Systems and Device
Proceeding of the 38th Hawaii International Conference on System Science
(2005)
http://me.emu.edu.tr/majid/cimpage.htm (Assoc Prof Dr. Majid
Hashemipour)
Mert Bal, Majid Hashemipour 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 170178.
Mert Bal and Majid Hashemipour, 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 Majid Hashemipour, 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 Majid Hashemipour, 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, Valeriy Vyatkin, Armando Colombo (Eds.), pp 421-432, 2007.

Valuable Contributions of Hamed Farahani Manesh

Valuable Contributions from The ME 561 Class