Information Modeling Requirement Analysis

1
Information Modeling Requirement Analysis
PREPARED BY SARA IZADPANAHI GULSAH TASEL PHILLIPS
AGBOOLA
2
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

3
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
  products 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.
  

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

5
Requirement Analysis

• In the requirements analysis phase of
  information modeling development, Wand and Weber
  state1, 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 customers
  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.

6
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
7
Scope

• Information modeling starts with the definition
  of the scope of the models 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.

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

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

10
Information Requirement (Cont)

• Depending on the scope, the analysis may include
  todays 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.

11
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)

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

13
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
14
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
15
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

16
Functional Modeling
Level-0
System Requirements
Top-level functions
Level-1
Function A
Function B
Function C
Function D
Function E
Function F
Second-level functions
Level-2
E.2
E.4
E.5
E.1
E.3
E.6
E.3
Figure System functional breakdown
17
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

18
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
19
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

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

21
Object-Oriented Paradigm

• Our Word is a collection of collaborating entities

President
Sales dept.
Factory
Factory workers
Engineers
Scientists
22
Object-Oriented Paradigm

• Organize software according to the structure of
  the world

Management Information Object
Factory Management Object
Sales Dept. Object
Worker Object
Laboratory Object
Design Object
23
Requirement analysis, Specification, Design
Problem P?P'
Platform M?M'
Real World W?W'
Design D?D'
Programming, Test
Program S?S
24
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.

25
Objects and Classes
Cyprus
object
abstraction
Turkey
Iran
Italy
instantiation
class Country
Prof.Hashemipour
Prof. Hacisevki
hasName Majid Hashemipour hasphoneNo
1354 teach
hasName Hasan Hacisevki hasphoneNo 1386 teach
lives-in
ClassProfessor HasnameString hasphoneNoint teac
h
Relationship
Attribute
Behavior
26
Relationships Among Classes

• Class Hierarchy, Inheritance,
• Specialization/Generalization
• Citylt Country lt World
• Composition, Aggregation,
• AutomobileBodyWheelsSteeringEngine
• Association, a general relation between classes
• People?(lives-in)?Country

27
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

28
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

ER
Entity type
Class
Entity instance
Object
Relationship
Association
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.
29
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?
30
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.
31
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.
32
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.

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

34

• HOLONIC CONCEPT

35
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

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

37
HOLONIC PHILOSPHY
38
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.

39

• Holons 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

40
FOUR QUADRANTS OF HOLONS
41
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.

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

43
HOLONIC SYSTEMS
Cooperative relationships among holons
44
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.

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

46
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

47
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

48
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

49
Comparison of holonic with other systems
50
Conventional vs. Holonic
51
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

52
TYPES OF HOLONS AND THEIR RELATION WITH EACHOTHER
Product Holon
Order Holon
Resource Holon
Cell Holon
Cell Holon
AVG Holon
Machine Holon
Machine Holon
AVG Holon
Robot Holon
Robot Holon
53
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.

54
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).

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

56
Holonic Manufacturing Systems
Production knowledge
Process execution knowledge
Process Knowledge
57
How Basic Holons 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.

58
Basic Holons
HOLONIC MANUFACTURING SYSTEM
Production Knowledge
ORDER HOLON
PRODUCT HOLON
Process execution Knowledge
Process Knowledge
RESOURCE HOLON
59
Resource Holon
60
Adding new resources
61
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.

62
Holons Agent
63
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.

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

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

66
Agents behavior

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

Customer Agent
Server Agent
Task Announcement monitoring
Task Announcement
Bid construction
Bid Collection
Bid Evaluation
Bid Submission
Task offer submission
Task offer construction
Task offer reception
Task offer evaluation
Task offer acceptance
Task Commitment
67
Agents behavior (2/2)

• Three classes of agent nodes.
• Manager Node
• Bidding Node
• Contractor Node

68

• 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

69
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

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

71
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).

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

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

74

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

Multi-multi-agent system
75
INTRODUCTION TO UML
76
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.

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

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

79
(No Transcript)
80
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.

81
TYPES OF UML DIAGRAMS

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

82
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

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

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

85
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

86
USE CASE DIAGRAMS

• These steps would generate this simple use case
  diagram

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

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

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

90
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
  objectNameclassName 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.

91
INTERACTION DIAGRAMS (SEQUENCE DIAGRAMS)
92
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.

93
INTERACTION DIAGRAMS (SEQUENCE DIAGRAMS)

• In the following slides examples of different
  sequence diagrams will be shown.

94
Example 1
95
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.

96
Example 2
97
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.

98
Example 3
99
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.

100
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

101
What is CASE?
A CASE tool repository contains all information
about the system.
102
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.

103
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

104
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

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

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

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

108
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

109

• Picture on the right shows the process of data
  modeling using UML and case tools.

110
(No Transcript)
111

• As it is seen in the previous slide by using CASE
  tools we can both generate diagrams and codes at
  the same time.

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

113
A case study using UML
114
A case study using UML
115
A case study using UML
116
A case study using UML

• PPS actor stands for production planning
  scheduling actor.
• Mediator can be called the messenger.

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

118
SEQUENCE DIAGRAM FOR SCENARIO 1
PPS Actor
Mediator
Robot X
Robot Z
Robot Y
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
119
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.

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

121
SEQUENCE DIAGRAM FOR SCENARIO 2
PPS Actor
Mediator
Robot X
Robot Z
Robot Y
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
122
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 Xs
  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.

123
PPS Actor
Mediator
Robot X
Robot Z
Robot Y
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
Acceptance
Acceptance
Acceptance
Acceptance
Acceptance
Order accepted
124
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.

125
References

• http//ieeexplore.ieee.org/stamp/stamp.jsp?arnumbe
  r00171872
• http//www.emeraldinsight.com/Insight/viewPDF.jsp?
  contentTypeArticleFilenamehtml/Output/Published
  /EmeraldFullTextArticle/Pdf/0680140706.pdf
• http//www.heverhagen.com/ssd.pdf

126

• Y. Lee Information modeling from Design to
  Implementation (2005)
• Mert Bal PhD DissertationDesign and development
  of a virtual reality-based 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/RD/Publications/1998/..
• cse.unr.edu/npenrod/lib/exe/fetch.php?...mediaf
  ulltext.pdf
• www.mech.kuleuven.be/goa/concepts.htm
• en.wikipedia.org/wi