Information Modeling Requirement Analysis - PowerPoint PPT Presentation

1 / 128
About This Presentation
Title:

Information Modeling Requirement Analysis

Description:

The combination of emerging technologies, global ... AREA OF A RHOMBOID? ... of the square and triangle functions you could compute the area of a rhomboid. ... – PowerPoint PPT presentation

Number of Views:167
Avg rating:3.0/5.0
Slides: 129
Provided by: phi769
Category:

less

Transcript and Presenter's Notes

Title: 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/wiki/Information_model
  • gilbane.com/.../What_is_an_Info
Write a Comment
User Comments (0)
About PowerShow.com