Μηχανική Οδηγούμενη από Μοντέλα και Γλώσσες Ειδικού Σκοπού Δρ Νικόλαος Σπανουδάκης nikos@science.tuc.gr ΕΕΔΙΠ ΙΙ Γενικό Τμήμα Πολυτεχνείου Κρήτης Χανιά, 6 Φλεβάρη 2012 12/4/2017 Ν. Σπανουδάκης

Περιεχόμενα παρουσίασης Εισαγωγή Οδηγούμενη από Μοντέλα Μηχανική Λογισμικού Model Driven Engineering (MDE) Οδηγούμενη από Μοντέλα Αρχιτεκτονική Λογισμικού Model Driven Architecture (MDA) Ένα παράδειγμα για τη γλώσσα UML Γλώσσες Ειδικού Σκοπού Domain Specific Languages (DSLs) Πρακτοροστραφής Μηχανική Λογισμικού Agent-Oriented Software Engineering Συμπεράσματα 12/4/2017 Ν. Σπανουδάκης

Ο ευρύτερος επιστημονικός χώρος Η Μηχανική Λογισμικού ή Τεχνολογία Λογισμικού (Software Engineering, IEEE, 1990) εφαρμόζει μια συστηματική, μεθοδική προσέγγιση στην ανάπτυξη, λειτουργία και συντήρηση του λογισμικού Μια διαδικασία ανάπτυξης λογισμικού (software process) απαντά στα ερωτήματα (Boehn, 1988): Τι θα κάνουμε μετά; Για πόσο χρόνο θα συνεχίσουμε να το κάνουμε; Μια μεθοδολογία ανάπτυξης λογισμικού (software methodology) είναι ένα προδιαγεγραμμένο και οργανωμένο σύνολο τεχνικών και κανόνων οι οποίοι ορίζουν από ποιον και με ποια σειρά θα χρησιμοποιηθούν οι τεχνικές (Tolvanen, 1998) According to the IEEE Computer Society, software engineering is defined as the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software and the study of such approaches (IEEE, 1990). In the writer’s point of view, software engineering emerged as soon as computer programs (or information systems) became products that would be used by people other than those who built them. Thus, on one hand the development process had to be explained and allocated a budget in a rational way and on the other hand different engineers should be able to be involved in the process, thus all the steps should be adequately documented. The software engineering field has tools such as process models and methodologies (or simply methods). The term process model guides a software project and provides answers to the following questions (Boehn, 1988): “What shall we do next? How long shall we continue to do it?” The methodologies are concerned with different issues such as the products outputted by each phase and how to navigate through each phase. Tolvanen (1998) provides the following definition for a software method: “A predefined and organized collection of techniques and a set of rules which state by whom and in what order the techniques are used.” 12/4/2017 Ν. Σπανουδάκης

Μηχανική Οδηγούμενη από Μοντέλα Model Driven Engineering (MDE) MDE (Beydeda et al., 2005) είναι η συστηματική χρήση μοντέλων ως πρωταρχικά εργαλεία καθόλο τον κύκλο ζωής του έργου λογισμικού στοχεύοντας στην φορητότητα, διαλειτουργικότητα και επαναχρησιμότητα του λογισμικού Βασίζεται σε μετασχηματισμούς μοντέλων και σε μεταμοντέλα (Jouault and Bézivin, 2006) Είναι η δεύτερη επανάσταση της προηγούμενης δεκαετίας μετά την Προσανατολισμένη στις υπηρεσίες μηχανική λογισμικού (Service-oriented Software Engineering – SOSE) MDE (Beydeda et al., 2005) is the systematic use of models as primary engineering artifacts throughout the engineering lifecycle. It is compatible with the recently emerging Model Driven Architecture (MDA) paradigm (see Kleppe et al., 2003). MDA’s strong point is that it strives for portability, interoperability and reusability, three non-functional requirements that are deemed as very important for modern systems design. Model driven engineering relies heavily in model transformation (Sendall and Kozaczynski, 2003). Model transformation is the process of transforming a model to another model. The requirements for achieving the transformation are the existence of metamodels of the models in question and a transformation language in which to write the rules for transforming the elements of one metamodel to those of another metamodel. Meta is a prefix originating from the greek word “μετά” meaning “after”, which is used in epistemology to mean “about”. In the software engineering domain a model is an abstraction of a software system (or part of it) and a metamodel is another abstraction, defining the properties of the model itself. Thus, like a computer program conforms to the grammar of the programming language in which it is written a model conforms to its metamodel (or its reference model). However, even a metamodel is itself a model. In the context of model engineering there is yet another level of abstraction, the metametamodel, which is defined as a model that conforms to itself (Jouault and Bézivin, 2006). We adopt the following three definitions from the same work: Definition 2.1. A metametamodel is a model that is its own reference model (i.e. it conforms to itself ). Definition 2.2. A metamodel is a model such that its reference model is a metametamodel. Definition 2.3. A terminal model is a model such that its reference model is a metamodel. We call these levels: M1, M2 and M3. M1 consists of all models that are not metamodels. M2 consists of all metamodels that are not the metametamodel. M3 consists of a unique metametamodel for each given technical space. Figure 15(A) shows how to adapt the definition of model to this three-level modeling stack. Figure 15(B) shows the associations between the three level models according to the above definitions. Throughout this thesis, the word model will usually refer to a terminal model. The structure for models defined in this section is compatible with the OMG view as illustrated in the MDA guide (see the Object and Reference Model Subcommittee, 2005). An example of this approach is the EBNF technical space: programs (M1) adhere to grammars (M2), which adhere to the grammar of EBNF (M3). 12/4/2017 Ν. Σπανουδάκης

Αρχιτεκτονική Οδηγούμενη από Μοντέλα (Model-Driven Architecture, MDA) Η MDA είναι μια αρχιτεκτονική συστημάτων που βασίζεται στην φιλοσοφία του MDE και ορίζει τρία επίπεδα μοντελοποίησης ενός συστήματος λογισμικού: Υπολογιστικά Ανεξάρτητο Μοντέλο Computation Independent Model (CIM) Μοντέλο Ανεξάρτητο Πλατφόρμας Platform Independent Model (PIM) Μοντέλο Συγκεκριμένης Πλατφόρμας Platform Specific Model (PSM) Ορίστηκε από την Object Management Group (OMG) το 2003 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμοί Μοντέλων Στη UML Με ποια σειρά να πάρω τα διαγράμματα; Πρώτα τα διαγράμματα τάξεων; Μετά αυτά των δραστηριοτήτων; Γιατί πρέπει και όλα αυτά να τα ξεκινήσω από την αρχή; Και αν ξεχάσω κάτι; Πως μπορεί να με βοηθήσει αυτή η «Μοντελο-στραφής» μηχανική; Για να δούμε πως γίνεται αυτό… Μετασχηματισμοί Μοντέλων Στη UML 12/4/2017 Ν. Σπανουδάκης

Ορισμός Περίπτωσης Χρήσης Use Case: Vehicle Reservation Precondition: A customer wants to make a reservation for a vehicle. Description: The customer selects pickup and return locations, as well as the pickup and return dates and times. The customer selects the vehicle type. The system presents all matching vehicles. If the customer requests detail information on a particular vehicle, the system presents detail information to the customer. If the customer selects a vehicle, the system gets the customer information (full name, telephone number, email address). The system presents information on protection products (such as damage waiver, personal accident insurance). If the customer either accepts the reservation or rejects it and the use case finishes. 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμός Κειμένου σε Μοντέλο (Text to Model Trans. – T2M) Είσοδος: Περιγραφή Περίπτωσης Χρήσης Έξοδος: Διάγραμμα Τάξεων Κανόνες Μετασχηματισμού: Ουσιαστικά (Λέξεις με Έντονα Γράμματα) -> Τάξεις Ουσιαστικά προσδιοριστικά άλλων (Λέξεις με Έντονα Πλάγια Γράμματα) -> Ιδιότητες Τάξεων Ρήματα (Λέξεις με Πλάγια Γράμματα) -> Συσχετίσεις τάξεων εφόσον ενώνουν τέτοιες Μέθοδοι τάξεων εφόσον αναφέρονται μόνο σε μία 12/4/2017 Ν. Σπανουδάκης

Συντακτική Ανάλυση του Ορισμού Περίπτωσης Χρήσης A customer wants to make a reservation for a vehicle. The customer selects pickup and return locations, as well as the pickup and return dates and times. The customer selects the vehicle type. The system presents all matching vehicles. If the customer requests detail information on a particular vehicle, the system presents detail information to the customer. If the customer selects a vehicle, the system gets the customer information (full name, telephone number, email address). The system presents information on protection products (such as damage waiver, personal accident insurance) The customer either accepts the reservation or rejects it and the use case finishes. 12/4/2017 Ν. Σπανουδάκης

Αυτόματη Δημιουργία Διαγράμματος Τάξεων Δεν το είχα σκεφτεί!!! Μπορώ να κρατώ ιστορικό με τις επιλογές του χρήστη 12/4/2017 Ν. Σπανουδάκης

Επεξεργασία Διαγράμματος Τάξεων 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμός Μοντέλου σε Μοντέλο (Model to Model Trans. – M2M) Για την αποθήκευση αντικειμένων σε σχεσιακή βάση δεδομένων πρέπει να μετατρέψω το διάγραμμα τάξεων σε Διάγραμμα Οντοτήτων Σχέσεων (Entity Relationship – ER Diagram, Wimmer et al., 2007) Είσοδος: Διάγραμμα Τάξεων Έξοδος: Διάγραμμα Οντοτήτων Συσχετίσεων Κανόνες Μετασχηματισμού Τάξη (Class) -> Οντότητα (Entity) Ιδιότητα (Property) -> Χαρακτηριστικό (Attribute) Συσχέτιση (Association) -> Σχέση (Relationship) Ιδιότητα Συσχέτισης (Association property) -> Ρόλος (Role) 12/4/2017 Ν. Σπανουδάκης

Δίάγραμμα Τάξεων σε Διάγραμμα Οντοτήτων Σχέσεων Μετασχηματισμός Επεξεργασία 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμός Μοντέλου σε Κείμενο (Model to Text Trans. – M2T) Για την υλοποίηση του συστήματος σε Java Είσοδος: Διάγραμμα Τάξεων Έξοδος: Κώδικας Java Κανόνες Μετασχηματισμού Κλάση (Class) -> Java class Ιδιότητα (Property) -> Java class property Ιδιότητα Συσχέτισης (Association property) -> Java class property Εάν είναι με πολλαπλότητα > 1 τότε χρησιμοποίησε την κλάση java.util.Vector Μέθοδος (Method) -> Java method που ρίχνει (throws) ένα UnsupportedOperationException Παρομοίως και για C++ 12/4/2017 Ν. Σπανουδάκης

Υλοποίηση Java Αρχείο Customer.java Αρχείο Customer.java Επεξεργασία import java.util.Vector;   public class Customer { private Object _fullName; private Object _telephoneNumber; private Object _emailAddress; public Vector<Reservation> _myReservations = new Vector<Reservation>(); public VehicleType _select; public void getCustomerInformation() { throw new UnsupportedOperationException(); } Αρχείο Customer.java import java.util.Vector;   public class Customer { private String _fullName; private int _telephoneNumber; private String _emailAddress; public Vector<Reservation> _myReservations = new Vector<Reservation>(); public VehicleType _select; public String getCustomerInformation() { return new String("Name: "+_fullName+ "\nTel.: "+_telephoneNumber+ "\nEmail: "+_emailAddress); } ..... Επεξεργασία 12/4/2017 Ν. Σπανουδάκης

Υλοποίηση C++ Αρχείο Customer.h Αρχείο Customer.cpp #include <exception> #include <vector> using namespace std; #ifndef __Customer_h__ #define __Customer_h__ #include "Reservation.h“ class Reservation; class VehicleType; class Customer; class Customer { private: string _fullName; private: string _telephoneNumber; private: string _emailAddress; public: std::vector<Reservation*> _myReservations; public: VehicleType* _select; public: void getCustomerInformation(); }; #endif Αρχείο Customer.cpp #include <exception> #include <vector> using namespace std; #include "Customer.h" #include "Reservation.h" #include "VehicleType.h" void Customer::getCustomerInformation() { throw "Not yet implemented"; } 12/4/2017 Ν. Σπανουδάκης

Ένα Εργαλείο CASE (Computer Aided Software Engineering) 12/4/2017 Ν. Σπανουδάκης

Επίπεδα MDA στο παράδειγμά μας CIM Διάγραμμα Περίπτωσης Χρήσης PIM Διάγραμμα Τάξεων Διάγραμμα Οντοτήτων-Σχέσεων PSM Java C++ 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμός Κείμενου σε Κείμενο (Text to Text Trans. – T2T) Μπορείτε να σκεφτείτε έναν τέτοιο; Γίνεται όποτε προγραμματίζετε… Όταν κάνετε compile… C source file (*.c) to executable program (machine language) Java source file (*.java) to Java interpreted file (*.class) 12/4/2017 Ν. Σπανουδάκης

Ποια είναι η διαδικασία που ακολουθήσαμε; Ορίζεται σύμφωνα με το Μεταμοντέλο Περιγραφής Διαδικασιών Ανάπτυξης Λογισμικού SPEM (Software Process Engineering Metamodel) της OMG Συμβολισμοί: 12/4/2017 Ν. Σπανουδάκης

Μια Διαδικασία Ανάπτυξης Λογισμικού 12/4/2017 Ν. Σπανουδάκης

Γλώσσες Ειδικού Σκοπού (Πεδίου) Ωραία όλα αυτά αλλά εγώ θέλω να δημιουργήσω λογισμικό με παράλληλη εκτέλεση αλγορίθμων. Δεν με βοηθάει και πολύ η UML… Εμένα που με ενδιαφέρουν οι λογικές και οι βάσεις γνώσης να δεις… Εγώ ήθελα να ξεκινήσω ορίζοντας στόχους για το λογισμικό μου και όχι λειτουργίες… Για να δούμε και τις: Γλώσσες Ειδικού Σκοπού (Πεδίου) 12/4/2017 Ν. Σπανουδάκης

Γλώσσες Ειδικού Σκοπού (ή πεδίου) Domain Specific Languages – DSLs Οι Γλώσσες Ειδικού Πεδίου αποτελούν μια κατηγορία γλωσσών προγραμματισμού, οι οποίες έχουν ως στόχο την αντιμετώπιση εξειδικευμένων προβλημάτων στην διαδικασία ανάπτυξης λογισμικού αλλά και να υποστηρίξουν την εξέλιξη των γλωσσών μοντελοποίησης Π.χ. γλώσσα για παράλληλο προγραμματισμό (Ada) γλώσσα ερωταπαντήσεων βάσεων δεδομένων SQL 12/4/2017 Ν. Σπανουδάκης

Η Γραμμή μηδέν και η εικονική γραμμή μηδέν (Kleppe, 2009) Run a nuclear power plant Business Concepts Autonomous Negotiation Business Process Warehouse Agent Design pattern Aspect Component Abstraction Entity bean Association Object/Class Virtual zero line XML Method Subroutine Database table Loop If statement ASCII Hardware zero line Memory location Accumulator Instruction 12/4/2017 Ν. Σπανουδάκης

Μοντέλα, Μεταμοντέλα και Μεταμεταμοντέλα Για να δούμε τη σχέση τους: 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμοί Μοντέλων Model Transformation Μετασχηματισμός: Είσοδος: το μοντέλο πηγής Ma που είναι σύμφωνο με το μεταμοντέλο MMa Έξοδος: το μοντέλο στόχος Mb που είναι σύμφωνο με το μεταμοντέλο MMb Τέσσερις τύποι: Μοντέλο σε μοντέλο (M2M) Μοντέλο σε κείμενο (M2T) Κείμενο σε μοντέλο (T2M) Κείμενο σε κείμενο (T2T) The overall scheme of the model transformation process followed by both ATL and QVT is presented in Figure 16. On the top there is a common metametamodel (MMM) to which conform two metamodels (MMa and MMb). The goal of the model transformation process or model to model process (abbreviated as M2M) is to take a model Ma, which conforms to MMa, as input (or source model) and produce the Mb, which conforms to MMb as output (or target model). Besides the source and target models the process executes a transformation program (let it be called Tab). The Tab describes the procedure for transforming a model that conforms to MMa to a model that conforms to MMb. The transformation program itself is a model that conforms to a metamodel (MMt), which in turn conforms to the metametamodel (MMM). Thus, like in the case of EBNF, MMt defines the abstract syntax of the transformation language. Both QVT and ATL define their abstract syntaxes through such a metamodel. 12/4/2017 Ν. Σπανουδάκης

Το μεταμεταμοντέλο ecore Του Eclipse Modeling Framework (EMF) 12/4/2017 Ν. Σπανουδάκης

Πρακτοροστραφής Μηχανική Λογισμικού Νάτα πάλι τα «κινέζικα»: μεταμοντέλα, μοντέλα, γλώσσες, καλά πως χρησιμοποιούνται αυτά; Μήπως είναι πολύ θεωρητικά για μένα; Εσείς γνωρίζετε καμία γλώσσα μοντελοποίησης; Α ναι, η UML Για να δούμε μια γλώσσα μοντελοποίησης για ένα νέο πεδίο… Πρακτοροστραφής Μηχανική Λογισμικού 12/4/2017 Ν. Σπανουδάκης

Πρακτοροστραφής Μηχανική Λογισμικού Agent Oriented Software Eng. (AOSE) Από τον χώρο της κατανεμημένης τεχνητής νοημοσύνης και των συστημάτων πολλαπλών πρακτόρων (ΣΠΠ) – Multi-Agent Systems (MAS) δημιουργήθηκε η ανάγκη για την ανάπτυξη λογισμικού το οποίο θα είναι (Wooldridge and Jennings, 1995; Weiss, 2003): Αυτόνομο (autonomous) Κοινωνικό (social) Αντιδραστικό (reactive) Ικανό να παίρνει πρωτοβουλίες (pro-active) Προσαρμοστικό (adaptive) Διαρκές (persistent) Agent Oriented Software Engineering (AOSE) emerged after the autonomous agents and multi-agent systems was established as a research field of the computer science/artificial intelligence discipline. The first workshop with this name took place in 2001 (Ciancarini and Wooldridge, 2001), although the term had already appeared in earlier works, e.g. in Jennings (1999). Agent-oriented development is viewed as a next step in software engineering evolution. Agents are the descendants of objects. The new ideas incorporated in the agent concept that characterize the notion of agency (Wooldridge and Jennings, 1995; Weiss, 2003) are also their main differences with objects (Odell, 2002): Autonomy. Agents can operate without the direct intervention of humans or other entities, and can have some kind of control over their actions, internal state and resource consumption Social ability. Agents use a communication language to interact with other agents (and possibly humans). They have some kind of control over their acquaintances and can choose their collaborators for problem solving Reactivity. Agents perceive their environment and respond in a timely fashion to changes that occur in it according to their goals Pro-activeness. Agents are able to exhibit goal-directed behaviour by taking the initiative, be purposeful, not simply act in response to the environment changes. Other characteristics of agents are adaptability (the agent can adapt to changes in its environment) and persistence (an agent has a lengthy persistence, unlike objects that are instantiated to do something and then are sent to the garbage collector). Agents originated from the distributed problem solving or distributed artificial intelligence discipline. This discipline argued that it is more efficient to create specialized problem solvers (agents) who can, through interaction, provide solutions to more complex problems than the ones that one of them can solve by itself (O’Hare and Jennings, 1996). Systems that are composed of interacting agents are also termed as multi-agent systems (MAS). 12/4/2017 Ν. Σπανουδάκης

AOSE Μεθοδολογίες με μεταμοντέλα The Gaia Methodology (Wooldridge et al., 2000) Multi-agent Systems Engineering (Deloach et al., 2001) PASSI (Burrafato and Cossentino, 2002) Prometheus (Padgham and Winikoff, 2003) Ingenias (Pavón and Gómez-Sanz, 2003) Tropos (Bresciani et al., 2004) Agent Systems Engineering Methodology – ASEME (Spanoudakis, 2009) Agent Modeling Language – AMOLA Gaia, however, has specific limitations related to its use as a complete software development methodology. It does not commit to specific techniques for modeling, nor does it provide guidelines for code generation. The “services model” of Gaia does not apply to modern agents who provide services through agent interaction protocols. Furthermore, the protocol model of Gaia does not provide the semantics to define complex protocols and the Gaia2JADE process additions remedied this situation only for simple protocols. Moreover, Gaia does not explicitly deal with the requirements analysis phase; however, in Zambonelli et al. (2003) the authors propose that it could be integrated with goal-oriented approaches. AUML has been proposed as a language for modeling multi-agent systems. However, it does not come along with a methodology or a complete process for software development. Many methodologies, i.e. Tropos, Mas-CommonKADS, PASSI, ADELFE and MESSAGE (Henderson-Sellers and Giorgini, 2005), use some of its models, mainly the agent interaction protocol (AIP) model. The latter has been defined as an extension to the UML sequence diagram. However, AIP has specific shortcomings when it comes to defining complex protocols (also see Paurobally et al., 2004). The most important ones are the following: the decision points of the participants are not obvious. Only message exchanging is modeled there are no semantics for expressing time-dependent concepts like timeouts it does not allow the designer to easily model a group that participates in a protocol, but whose members can choose individual actions. In the latter case the designer must include all possible group members in the diagram The AUML layered approach to protocols provides a mechanism for specifying the program that implements a protocol but does not specify how it is integrated with other such programs (other protocols), or how to integrate it with the other agent capabilities. All in all, MaSE defines a system goal oriented MAS development methodology. The authors define for the first time inter and intra-agent interactions that must be integrated. However, in their models they fail to provide a modeling technique for analyzing the systems and allowing for model transformation between the analysis and design phases. Their concurrent tasks model derives from the goal hierarchy tree and from sequence diagrams in a way that cannot be automated. MaSE agents are related to system goals. This restricts the definition of autonomous agents. The Vowels methodology and the Volcano respective multi-agent platform (Ricordel and Demazeau, 2002) is one of the first approaches to engineering multi-agent systems. The main idea of the vowels methodology is that a MAS is consisted of four major component types (each corresponding to a Latin vowel), a) the Agent, b) the Environment, c) Interactions, and d) Organization. It is a methodology that introduced these four different aspects in MAS development for the first time in a modular architecture. The different phases of the vowels methodology are presented in Figure 24. The analysis phase consists of two steps. During the first step, a domain ontology is created for describing the information that will be used for defining the problem. The second step is about giving a precise solution to the problem in an implementation independent manner. In the design phase, the engineer chooses the possible orientation of the application towards a specific vowel (brick type), then chooses the model of each brick and the needed wrapper bricks. Then, in the development phase, the bricks are created (programmed or chosen among existing ones). Finally, during the deployment phase the MAS is deployed using a specific language that describes what building blocks will be deployed. PASSI (Burrafato and Cossentino, 2002; Cossentino, 2005) is an AOSE methodology that aims to allow engineers experienced in UML to model and implement agent-based systems. Thus, all the models that they define are derived from UML models. The roles identification phase is about creating extended UML sequence diagrams. PASSI defines that each object in the sequence diagram represents an agent’s role with the convention that the objects are named as <role_name>:<agent_name> (see a sample roles identification diagram in Figure 28). However, this convention does not allow the participation of more than one instances of a role of a specific agent type in a scenario (e.g. for defining a scenario where a manager agent broadcasts a request for proposals to many, e.g. task agents). The Prometheus methodology has been proposed by Padgham and Winikoff (2003 and 2004). It provides a method and a process for developing multi-agent systems. Prometheus supports the development of intelligent agents linking the word intelligence with the analysis and design of an agent as an entity with goals, beliefs, plans and events. It uses the JACK Intelligent Agents Platform (Winikoff, 2005) for system implementation that is also centered on the definition of these terms. It has been conceived as a methodology that will be used by non-experts, including undergraduate students. In Prometheus the authors use the terms of functionality and capability. However, they are not used as independent terms. In fact, functionalities and capabilities refer to the same concept as it evolves through the development phases (i.e. the abilities that the system needs to have in order to meet its design objectives). The support for implementation, testing and debugging of Prometheus models is limited and it has less focus on early requirements and analysis of business processes (Henderson-Sellers and Giorgini, 2005). Another limiting issue of the methodology is the fact that the protocols definition using AIP diagrams is not used later somehow formally at the agent level. This means that the developer has to undertake the mental task of transforming the AIP diagrams to processes. In their book, Padgham and Winikoff (2004) propose that process diagrams are to be developed by looking at the protocols involving the agent in question, as well as the scenarios developed and the goals of the agent. This contradicts the overview diagram shown in Figure 31 and is an issue that almost all the AOSE methodologies suffer from, the lack of a systematic way to integrate interaction protocol specifications to the agent capabilities. Ingenias (Pavón and Gómez-Sanz, 2003) is a methodology that emerged with a development environment allowing for agent development using the Ingenias metamodel. Its metamodel is the richest one among AOSE methodologies containing more than 300 concepts (the ecore metamodel of Ingenias can be downloaded from http://ingenias.sourceforge.net). This feature can also be considered as exceptionally restrictive to developers that want to use their own agent architectures but also needing more learning time than all other methodologies in order to begin working with it. Its process is also hard to learn and use (especially in iterative development) as it consists of about 100 activities (Pavón et al., 2005). INGENIAS clearly distinguishes between an agent and an application showing that agent technology isn’t about substituting existing frameworks, for example for building user interfaces but for adding new characteristics to computer systems. Agents access applications through a kind of Application Programming Interface (API) that they offer. An issue that INGENIAS leaves to the developer is whether he will define first the tasks or goals of an agent. Maybe this is the result of the lack of a requirements analysis phase. Moreover, Ingenias does not offer the convenience of gradually modeling a multi-agent system by considering it at different levels of abstraction. TROPOS (Bresciani et al., 2004) is a methodology whose main difference with other methodologies is its focus in the early requirements analysis phase where the actors and their intentions are identified in the form of goals. The latter are divided in two categories, hard goals (related to functional properties of the actors) and soft goals (related to non functional properties of the actors). Actor diagrams depict the actors, their goals and dependencies on other actors for realizing a goal. Then, goal diagrams analyze the goals of a specific actor to subgoals and plans for achieving the goal. In the late requirements phase the models are extended adding possible interactions between goals (helpful or conflicting goals). An MDA-compliant work based on Tropos has been presented by Perini and Susi (2006), where the authors define rules for transforming a Tropos plan decomposition diagram to a UML activity diagram. They present their rules formally and show how they can build a tool for applying these rules automatically. However, they do not tackle the issue of transforming an AIP diagram to a plan. Finally, even as Tropos starts by identifying stakeholders and their goals in the requirements analysis phase, it ends up by proposing the development of a system composed by a large number of agents not representing the original actors, but more actors that appear during the tasks decomposition. This is better shown in the case of the example of MEdi@ where the shopping cart (usually a data structure for storing items selected by the user while exploring an electronic store’s web site) is identified as an actor (to be developed as an agent). A classical software engineering architecture would define the shopping cart as a stateful object that is instantiated for a user’s session (see Jacyntho et al., 2002). 9/10/2009 N. Spanoudakis Thesis

Γλώσσα AMOLA: Ανάλυση Απαιτήσεων Το Μοντέλο Δραστών-Στόχων (SAG) Το μεταμοντέλο του ορίζεται σύμφωνα με το μεταμεταμοντέλο Ecore (EMF) Meetings Manager Faculty Personnel Learn user habits Personal Assistant Request new meeting Manage meetings 12/4/2017 Ν. Σπανουδάκης

AMOLA: Ανάλυση Συστήματος To Διάγραμμα Περίπτωσης Χρήσης (SUC) βασισμένο στα UML use cases Και το μεταμοντέλο του System Learn user habits Request new meeting Faculty Personnel Personal Assistant Meetings Manager Manage meetings 12/4/2017 Ν. Σπανουδάκης

AMOLA: Ανάλυση Συστήματος (συνέχ.) Το Μοντέλο Ρόλων (SRM) Και το μεταμοντέλο του Role: Personal Assistant Capabilities and Protocols: learn user habits, request new meeting: personal assistant, … Activities: learn user preference, update user preferences, … Liveness: personal assistant = request new meeting || learn user habits learn user habits = learn user preference. update user preferences … 12/4/2017 Ν. Σπανουδάκης

Όπου η γραμματική για τις φόρμουλες ορίζεται με EBNF: Η σημασία των συμβολισμών Operator Interpretation x . y x followed by y x | y x or y occurs x* x occurs 0 or more times x+ x occurs 1 or more times x ω x occurs infinitely often [x] x is optional x || y x and y interleaved |x ω|n x occurs infinitely often n times in parallel 12/4/2017 Ν. Σπανουδάκης

AMOLA: Φάση Σχεδίασης inter και intra-agent control Τα μοντέλα δια (EAC) και ενδο-πρακτορικού ελέγχου (IAC) βασίζονται στο διάγραμμα καταστάσεων Μεταμοντέλο: 12/4/2017 Ν. Σπανουδάκης

Οι Μετασχηματισμοί στην ASEME Οι μετασχηματισμοί είναι πλήρως αυτοματοποιημένοι Το μοντέλο μιας προηγούμενης φάσης μετασχηματίζεται σε ένα αρχικό μοντέλο της επόμενης φάσης (initial model) Ο μηχανικός επεξεργάζεται και ραφινάρει το αρχικό μοντέλο δημιουργώντας την τελική έκδοση (refined model) 12/4/2017 Ν. Σπανουδάκης

Δημιουργία και Επεξεργασία του Μοντέλου Δραστών-Στόχων (SAG) Learn user habits Personal Assistant Meetings Manager Request new meeting 12/4/2017 Ν. Σπανουδάκης

Το πλάνο του μετασχηματισμού XMI (XML Metadata Interchange) is a proposed use of the Extensible Markup Language (XML) that is intended to provide a standard way for programmers and other users to exchange information about metadata (essentially, information about what a set of data consists of and how it is organized). Specifically, XMI is intended to help programmers using the Unified Modeling Language (UML) with different languages and development tools to exchange their data models with each other. In addition, XMI can also be used to exchange information about data warehouses. Effectively, the XMI format standardizes how any set of metadata is described and requires users across many industries and operating environments to see data the same way. XMI is a proposal from the Object Management Group (OMG) that builds on and extends these industry standards or recommendations: Extensible Markup Language (XML), a standard from the World Wide Web Consortium (W3C) Unified Modeling Language (UML), a standard from OMG Meta Object Facility (MOF), another standard from the OMG for a metamodeling and metadata repository Ideally, XMI will allow different cooperating companies a way to use each other's data repositories. XMI is described as similar to, yet competing with, Microsoft's Open Information Model. XMI: XML Metadata Interchange 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμός M2M 12/4/2017 Ν. Σπανουδάκης

Ο μετασχηματισμός SAG 2 SUC Personal Assistant Meetings Manager Learn user habits Learn user habits Personal Assistant Meetings Manager Request new meeting Request new meeting 12/4/2017 Ν. Σπανουδάκης

Επεξεργασία του μοντέλου SUC Personal Assistant Meetings Manager Learn user habits Request new meeting <<include>> Learn user preference <<include>> <<include>> Receive new request Send new request <<include>> <<include>> <<include>> Update user preferences Send new results Receive new results 12/4/2017 Ν. Σπανουδάκης

Ο μετασχηματισμός SUC 2 SRM Personal Assistant Meetings Manager Learn user habits Request new meeting <<include>> Learn user preference <<include>> <<include>> Receive new request Send new request <<include>> <<include>> <<include>> Update user preferences Send new results Receive new results 12/4/2017 Ν. Σπανουδάκης

Ο μετασχηματισμός SUC 2 SRM Role: Capabilities and Protocols: Activities: Personal Assistant Learn user habits Learn user habits Request new meeting Personal Assistant Request new meeting <<include>> Learn user preference <<include>> Learn user preference Send new request <<include>> Send new request <<include>> Update user preferences Update user preferences Receive new results Receive new results 12/4/2017 Ν. Σπανουδάκης

Εκλέπτυνση SRM Role: Personal Assistant Capabilities and Protocols: manage meetings, learn user habits, negotiate meeting date, request change meeting, request new meeting Activities: get user request, read schedule, show results, learn user preference, update user preferences, send change request, receive change results, send new request, receive new results, receive proposed date, decide response, send results, receive outcome, update schedule Liveness: personal assistant = (manage meetings. learn user habits)ω || (negotiate meeting date)ω manage meetings = get user request. (read schedule | request change meeting | request new meeting). show results learn user habits = learn user preference. update user preferences request new meeting = send new request. receive new results request change meeting = send change request. receive change results negotiate meeting date = receive proposed date. (decide response. send results. receive outcome)+. update schedule 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμός SRM 2 IAC Liveness: personal assistant = (manage meetings. learn user habits)ω || (negotiate meeting date)ω learn user habits = learn user preference. update user preferences x || y xω x . y 12/4/2017 Ν. Σπανουδάκης

Μετασχηματισμός M2T - JADE 12/4/2017 Ν. Σπανουδάκης

Χρησιμοποιώντας το GMF Με το SAG.ecore αρχείο μπορώ να ορίσω ένα μετασχηματισμό Μ2Μ σε γραφική αναπαράσταση χρησιμοποιώντας το Graphical Modeling Framework (GMF) του Eclipse 12/4/2017 Ν. Σπανουδάκης

Σύνοψη - Συμπεράσματα Σήμερα είδαμε τα MDE: Model-Driven Engineering MDA: Model-Driven Architecture, CIM, PIM, PSM M2M, M2T, T2M, T2T transformations EMF, Ecore DSL: Domain Specific Language AOSE: Agent Oriented Software Engineering Που βοηθούν στην σταδιακή εκλέπτυνση του μοντέλου του συστήματος χρησιμοποιώντας σε κάθε (υπο)φάση το πιο κατάλληλο μοντέλο 12/4/2017 Ν. Σπανουδάκης

Είδαμε τις τεχνολογίες Object Management Group http://www.omg.com IBM method: Getting form Use Cases to code http://www.ibm.com/developerworks/rational/library/5383.html Eclipse Modeling Tools IDE http://www.eclipse.org ASEME, a DSL for AOSE http://www.amcl.tuc.gr/aseme Visual Paradigm tool http://www.visual-paradigm.com 12/4/2017 Ν. Σπανουδάκης

Ευχαριστώ για την προσοχή σας Είμαι διαθέσιμος για περισσότερες πληροφορίες και ερωτήσεις Δρ Νικόλαος Σπανουδάκης ΕΕΔΙΠ ΙΙ Εργαστήριο Εφαρμοσμένων Μαθηματικών και Ηλεκτρονικών Υπολογιστών Γενικό Τμήμα Πολυτεχνείο Κρήτης Δ.νση: Πολυτεχνειούπολη, Κουνουπιδιανά, 73100, Χανιά Τηλ.: +30 28210 37744 Φαξ: +30 28210 37842 Ηλ. ταχ/μείο: nikos@science.tuc.gr Ιστόσελίδα: http://users.isc.tuc.gr/~nispanoudakis 12/4/2017 Ν. Σπανουδάκης