The current paper introduces an approach to a development of Ambient Intelligence domain-based software systems from scratch. The presented approach is based on models. The paper also presents the domain-related models expressing different levels of abstractions and stages of the development. The approach refers to a Model-Driven Development of Ambient Intelligence which was suggested at AmI-07-Ambient Intelligence conference. The approach is presented as a standard with its feasible realization. It starts from modeling of a content of the future AmI-dedicated software system and concludes by mapping the graphical concepts into a final code. A process proving feasibility and correctness of the approach is provided through a dedicated research methodology. Its process comprises an identification of needs in a speedy development of the systems. It is followed by studying of the currently available techniques capable of supporting the development and an experimenting with them. It continues by finding a solution, verified by its validation and concludes by an identification of the further perspectives. The developed approach presents a common way of a communication amongst stakeholders participating in creating of AmI-based environments. Such communication involves the notations of AmI-Creator—a Domain-Specific Language of Ambient Intelligence domain. Every part of DSL corresponds to a demonstration of A-methodology expressing a step-by-step guidance for the development. The methodology comprises two parts dedicated to providing semantics for DSL through studying of Ambient Intelligence domain ontology; and development of actual environments. A validity of the working proposition is confirmed by three examples. The further challenges refer to an extension of the presented work by other frameworks and expansion to a development of different domains with complex organizations.
Consumers’ needs in device-based sensitive environments caused a discovery of Ambient Intelligence (AmI) paradigm. Its development became a subject of a scientific discovery. The development had been discussed at AmI-dedicated events one of which suggested an involvement of Model-Driven approaches to it1.
As a response to the suggestion this paper presents a feasible solution, which shows an easy way of building of AmI-based environments through use of Model-Driven Development (MDD)2. The solution demonstrates a simplification of an AmI-dedicated software development process. It starts from a consideration of a domain of interest and finalizes by mapping of modeling elements into a final code. Referring to the idea the current research articulates its question as an investigation of applicability of MDD to the AmI development process. It also tries to prove a hypothesis that such approach is feasible. The solution concerns two concepts: the third wave of computing and the fourth generation of software development. The third wave of computing refers to Ambient Intelligence whereas the fourth generation of software development refers to a modeling process.
The current paper demonstrates a development process of AmI environments (AmI-E) from scratch. It is based on Model-Driven Architecture3 (MDA) initially introduced by Object Management Group4 (OMG) and; consideration of different Software development methodologies. It demonstrates an inference of a common way of communications amongst the stakeholders participating in the software development process expressed in notations of AmI-Creator―Domain-Specific Language (DSL) for the development of AmI-based environments (AmI-E). The semantics of the language syntax corresponds to the semantics of the AmI concepts. Such concepts are presented in ontology of AmI domain expressed in various notations for their future reuse. For example they can be used for an initial analysis of the problem or for expressions used in the final code.
This paper also shows a set of models expressing different aspects and stages of the AmI-E development process. These stages are summarized in A-methodology structure of which is based on A-MDA (Adapted MDA) and MDD. A use of a MDD-based methodology allows a production of an entire flow of the software development process. It starts from an identification of the requirements and finalizes with the end code expressed in (Java) programming language notations. The main outcomes of the presented research comprise:
Adapted Model-Driven Architecture (A-MDA).
Methodology for the development of AmI-E from scratch.
Ontology of AmI environments.
AmI-Creator-DSL for the development of AmI environments.
The feasibility of the presented research is verified, validated at the appropriate stages and tested on different applications.
The current research presents a standalone idea, equivalent of which was not met in the preceding literature survey. The research evaluates the survey’s finding and brings forward its argument declaring AmI as a separate domain on its own rights. This domain has the common indistinguishable parts. The development of the software-based systems from this domain can be based on a typical methodology.
The reminder of this paper shows the reason why the new approach to the AmI development is required. It also describes how it is created, realized, verified, evaluated and tested. The paper suggests a use of such approach for other domains. The paper’s content covers the descriptions of:
1) Approach to the current research.
2) Overview of the existing AmI and SE related developments.
3) Demonstration of an adaptation of MDA.
4) AmI domain concepts, ontologies and DSL.
5) Description of the horizontal set of models.
6) Evaluation (through Verification, Validation and Testing).
7) Conclusion and further work.
This part describes an analysis of a central research problem and its focus. It also shows a structure of the proposed solution and a description of a research methodological approach.
The current research sees a realization of the stated idea through two contexts. The first refers to MDD. The second refers to AmI domain and approaches to its co-related developments (e.g. system development).
A preliminary consideration of MDD showed that it involved such themes as Model-Driven Architecture (MDA) and Domain-Specific Language (DSL). MDA refers to a structure, whereas DSL implies various notations of different concepts.
An initial studying of AmI domain discovered two core subjects comprising Conceptual model and Ontologies. Conceptual model comprises a set of interconnecting concepts. Ontology provides semantics and notations of the concepts and their interconnections in different representations. Ontology is dedicated to a specific reuse for specific purposes. Concretely, ontology of AmI domain comprises a set of various features characterizing the domain; which current research considers as a specific physical entity (or environment).
A further consideration of the existing AmI-related research indicated a lack of common (typical or standard) approaches to a development of AmI systems. Regarding to these, the current research declares a hypothesis asserting an existence of the approach. It shows the proof of a feasibility of such hypothesis.
The main focus of the current research concerns a development of AmI environments based on Model-Driven Development. The research puts forward an idea of using models for the development of AmI. It argues that the research proposes a standard way of intercommunications among stakeholders participating in the development of AmI software systems from scratch.
A realization of the hypothesis peruses two separate objectives. The first refers to a consideration of Ambient Intelligence as a domain characterized by a set of common entities. Such entities refer to a set of basic elements participating in building of AmI-based software systems. The second objective refers to an obtaining of a step- by-step development of such systems.
The set of tasks leading to the objectives refers to two typical sets of activities (or methodologies). The first objective of these is to be devoted to the development of AmI domain (as a set of the standard concepts). The second is to be dedicated to the development of new AmI-based environments. The sequence of both of the sets is based on A-MDA, resulted in A-methodology comprising Vertical and Horizontal parts. The completion of the Vertical part of the methodology assures feasibility of the Horizontal part, completion of which is finalized in code.
The progression of the outlined solution requires the various activities and techniques e.g. collecting necessary information, its analysis, taking decision on the incoming tasks, verification and valuation of the data have gotten.
The current research methodology comprises a combination of variations of qualitative methodology, which depends on the context of the particular stage of the research. It is also updated with additional methods used by the other researches to evaluate and test the appropriate outcomes summarized in the
This section demonstrates the latest updates in the field of AmI and general software development. The updates are summarized in three hundred twenty seven on-line publications for a period of 2005-2010. The section comprises two parts. The outcome from the first part comprises clarification of the research question. Outcome of the second part comprises providing a background for the proposed solution of the specified problem.
Ambient Intelligence is originated in a notion of calm technology or third wave of computing proposed by Mark Weiser in 1988. The purpose of calm technology is serving humans’ needs with an aid of numerous computers.
Research methodologies comprising the current research methodology | Methodologies activities |
---|---|
Qualitative (theoretically-based) from the published works | Collecting information, its analysis and assessment on the relevance and suitability to the research issuers |
Qualitative secondary with elements of primary | To clarify the information use questionnaire and interview for the purpose of obtaining a new information (primary). Collecting the information from the presented and published works concerning different proposed solutions and their income in the studied subject (secondary) |
Evaluation and verification | Use different methods of assessing the obtained results (e.g. as factors and principles). Use different interview and questionnaire techniques for the verification of the obtained results and getting feedback (possibly) showing new directions in the research |
It found its implementation in such areas as health [
The AmI definitions vary. They include such notions as Ubiquitous/Pervasive/Proactive/Ambient Computing, Calm Technology and Smart Environments [
Summarizing the information ([
The ubiquity refers to an increasing number of computers around us, their incorporation in different parts of our environments and becoming a part of our life by maintaining everyday routines.
The disappearance is explained as tendency of computing devices to get smaller and disappear (hiding) in a textile surroundings us. The incorporation of such devices refers to integration of information, communication and sensing technology into everyday life leading to turning of our environments into “smart”. The “smart” concept refers to capabilities of sensing, processing, making decision and actuation, which has to have self-di- rections (e.g. actions or re-action).
The AmI has been understood as a set of entities with different arrangements such as Service-Oriented Architecture [
Some of the AmI-related themes refer to ontology of a single activity as a set of tasks [
Alternatively AmI was realized as middleware comprising different services and facilitating interactions of different parts [
The bases for building of AmI were introduced through such examples as AMENITIES methodology [
To benefit the consumer, a substance of Ambient Intelligence should be attached to a physical entity or an environment. Overview of the existing AmI examples showed that previously the notions of AmI environments were used for testing. Such, a use of the environment was presented in “the rapid prototyping and analysis of Ambient Intelligence systems” [
As things stand above: Previously Ambient Intelligence was presented as a vague technology-based essence. It was understood as comprising element or a summation of elements or disciplines. Regarding to the remaining text, the current research reckons that use of term “Environment” is more appropriate to an identification of “Ambient Intelligence” concept as referring to a particular space under an influence of AmI. Ambient Intelligence represents an “Intelligent environment which reacts in a sensitive and adaptive way to the presence of different objects in order to provide various services to people” [
Having comprehended the information about AmI the current research provides its own definition of Ambient Intelligence as:
Ambient intelligence is Artificial Intelligent Technology-based Environment providing responses on the dynamically detected requests and satisfying the predefined tasks in the expected way and in the expected time.
Furthermore, Ambient Intelligence was articulated by AmI-085 as a subject of expansion into wider areas. Additionally it was indicated that “engineering such systems is a nontrivial task, and convincing solutions are still missing” [
Finally the research question is clarified as focusing on proposition of the standard MDD to the development of AmI systems.
The current research identifies context of models as a clear set of formal elements that describe something being developed for a specific purpose and can be analyzed using various methods [
MDD is associated with a notion of Model-Driven Architecture (MDA), which provides a basic terminology for MDSD―Model-Driven Software Development. The current research sees MDD as means supporting a collaborative discussion among the project’s stakeholders for obtaining an immediate feedback.
There is no agreement among the SE researches on a precise definition and content of MDA. Some of them see MDA as a new approach to writing specifications and application’s development. The developments are based on a Platform-Independent Model (PIM)7 of the application or specification of business functionality and behavior. The other [
The original MDA OMG is organized into a four-layer architecture [
M3 layer meta-meta-model: MOF-Meta-Objects Facility.
M2 layer meta-modeling: UML profile Custom meta-model.
M1 layer model: UML models, Custom meta-model, Models based on the custom’s meta-models.
M0 layer reality: The Real World.
Object Management Group points out on a modeling provided with OMG’s standards. One of these is Unified Modeling Language (UML) which is stated as modeling language of choice [
“Domain-Specific Modeling (DSM) is a model-based software development approach that uses visual models as primary artifacts in the development process” [
Research Note
The current research sees involvement of MDD as a framework supporting a step-by-step development based on a purposely developed methodology. Referring to the idea of using MDA for the entire application’s development the current research sees the MDA as a base for summarizing the entire requirements for the development of AmI applications. Such requirements comprise modeling notations and software tools supporting the models’ production.
Further, SE offers two types of methodologies referring to a step-by-step development process. It also includes such approaches to a general software development, a development of AmI software systems and DSL. The SE methodologies refer to Waterfall, Evolutionary development, Rational-unified process, V or Agile methodologies.
The examples of AmI dedicated approaches and methodologies refer to “Design for all” [
The example refers to rapid prototyping of creating an AmI demonstrator [
Despite the variety of the approaches, AmI scientists ([
The methodologies proposed for the development of DSLs comprise several activities [
Despite approaches and methodologies for AmI-related development are already indicated by some of the authors, the other provide request to a methodology for AmI-related developments. The last indicates a lack of models and software engineering practice helping in managing of a AmI development lifecycle [
Some researches show tools [
As things stand above: The proposed solution of MDD in AmI can be realized by means of MDA, explaining the way of obtaining semantics and syntax for DSL called AmI-Creator. It can be supported by the appropriate tools; and methodology comprising the set of steps necessary for the development of AmI systems.
Believing that the development of AmI-E can be unified, standardized and presented as modeling process based on Software Engineering notions of MDA and MDD the current research generates the research hypothesis that:
“The Model Driven Development approach to the development of AmI domain and applications, based on MDA is possible and can be produced”.
Such hypothesis refers to an inference of a way dedicated to a development of AmI based system from scratch. Focusing on finding a common way of the communication among the stakeholders during the AmI development process the current research puts forward an idea of models. Their semantics should be identified by ontologies. Their syntaxes should be expressed in DSL notations.
The inference of DSL and its concrete use the current research sees through an adaptation of an idea behind MDA. It was generated by the organizations interpreting MDA as an approach to application design and implementation. “As defined by the Object Management Group (OMG), MDA is a way to organize and manage enterprise architectures supported by automated tools and services for both defining the models and facilitating transformations between different model types.”8 In respect to the generated idea of MDA-based structural approach the author presents a novelty to a creation of AmI applications from scratch. It refers to a realization of the requirements comprising models and tools supporting their production. This idea is developed by the current research.
The hypothesis corresponds to the appropriate theory that MDD is a right approach to the development of AmI-based systems. The current research sees the proof of the theory through a conjunctive consideration of two research fields comprising SE and AmI. The first of them serves the development of the second.
Supporting its theory the current research concentrates on producing the following outcomes:
Outline, structure, production and implementation of the Model-Driven Development Methodology for creating software applications from AmI domain from scratch
Present AmI-Creator―a new Ambient Intelligence-dedicated Domain Specific Language (AmI-d-DSL)
Realize IDE (Integrated Development Environment) for AmI, implementing the DSL for AmI
The intended results of the development imply to bring the benefit to the AmI development stakeholders, whether they are developers or not. This benefit would provide the user with a fully developed flow of the development of AmI applications (finalized in the code realization), supplied with AmI-dedicated language and realized tools.
The current research sees a production of the desired targets as outcomes of a “Walkthrough” of the Adapted MDA (A-MDA) based on the structuring idea behind MDA OMG. From the original idea of MDA the current research adapted only the layered arrangement of solving a problem. The every level of A-MDA is dedicated to a task e.g. domain analysis or study the requirements for the appropriate tools. Comparison of two architectures is shown in
Level | MDA OMG | A-MDA | comparison |
---|---|---|---|
M0 | Real world | Real world | Same |
M1 | Models of the World | Models of the World | Same |
M2 | Meta-model | Meta-model | Same |
M3 | Meta-meta-model | Tools definition | Different |
1) The lowest level is devoted to a studying of the dedicated domain.
2) The next level up derives modeling elements of the real world.
3) The following level derives basic modeling concepts.
4) The top level realizes the tools’ requirements.
The A-MDA provides a structure for definition of two methodologies comprising methodology for creating of AmI-based DSL (called AmI-Creator) and methodology for the development of software systems from AmI domain.
In respect to the development of AmI-Creator the requirements for A-MDA refer to a providing a base for outlining the process of the development of DSL for AmI environments. It comprises an obtaining of the DSL semantics, a concrete syntax and its supporting tools. The process corresponds to a methodology outlining the sequence of activities. They start from analysis of a domain with extracting a vocabulary (refer to ontology), continue through design (modeling) and finalizes by realization of the supporting tools. The process is based on a technique called “Walkthrough” referring to the step-by-step activities provided at A-MDA levels:
In the reference to M0 (real world of AmI environment):
o Studying the world of Ambient Intelligence Environment.
o Derive the comprising concepts, their relations and intercommunications.
o Summarize findings of studying the domain in (middle) ontologies.
o Extract domain vocabulary (or semantics).
o Document the findings as ontology documents.
In the reference to M1 (model of AmI environment):
o Outline the sequence of models and their contents.
o Extract the appropriate semantics expressed in vocabulary for every specified model.
o Specify concrete syntax.
o Document the findings.
In the reference to M2 (meta-model of model of AmI Environment):
o Analyze domain of models of the level M1 and derive the set of models’ comprising concepts.
o Summarize, generalize and abstract them into the general types of modeling entities, capable of creating of any modeling concepts for models in the M1.
o Identify these entities as general types, comprising the concepts (or upper-ontology).
o Define the upper ontology as vocabulary for the next part of AmI-Creator (AmI-DSL).
In the reference to M3 (as realization of tools to depict syntax):
o Analyze requirements ensuring full support of the modeling features.
o Give detailed requirements of the working tools.
There are two kind of “Walkthrough” were considered at the research: Vertical and Horizontal. Vertical “Walk through” (
The realization of the current research argument comprises two perspectives. They refer to an obtaining mea-
ningful notations and a consecutive development of activities; where the first refers to a DSL and second refers to a methodology.
The inference of the notations complies a vertical “Walkthrough” of A-MDA. It occupies three bottom layers (M0 - M2) and comprises activities of bottom-up (from M0 to M2) and top-dawn (from M2 to M0) directions. Bottom-up activities are dedicated to obtaining of AmI domain concepts, suggestion of language semantics, their abstractions into meta-language semantics and finalized with a deriving of tools requirements. The bottom- up part also suggests the graphical notations. The top-dawn activities comprise: the realization of the appropriate tools capable of holding the appropriate graphical notations, choosing notations for meta-language and DSL. The horizontal part of A- methodology resides at M1 layer of A-MDA and derives the stages for the development of new AmI domain-based applications. The overall logical structure of the AmI-dedicated development from scratch forms a shape of capital “A” (
The summary explains that the Vertical part is dedicated to the development of AmI domain and its modeling activities, whereas Horizontal part is dedicated to the development of AmI software systems. As overall the A- methodology is dedicated to the development of AmI software application from scratch. It means a starting from studying a domain and realization of the supporting tools for creating applications.
This part demonstrates the step-by-step analysis process. It comprises three stages of initial analysis of the studied domain, ontologies as intermediate analysis of the domain for it future reuse. It finalizes by using the ontology’s concepts as semantics corresponding to the concrete syntax of the concrete DSL. It shows an inference of the modeling concepts to be used in the actual modeling of AmI environments.
Having studied the AmI examples the current research realizes AmI domain as an entity to be considered from two perspectives. The first perspective refers to the request-response context (
Having considered and compared the notions of Conceptual model, Ontologies and Domain-Specific Language the current research found that all three notions showed that they are very close in their ideas. All of them collect and express the domain information, but pursue different purposes:
Concept model is used for studying a domain.
Ontology express a domain concepts and their interconnections in different notations.
DSL provide notations for creating of different applications.
These findings are summarized in the
Three concepts of the Conceptual model represent the abstractions of the AmI domain concepts, derived during an initial analysis of the domain. They correspond to the concepts of the Middle Ontology. This ontology is mapped into a DSL’s semantics and are represented in the concrete syntax of DSL.
The concepts of the Middle ontology refer to the abstractions of the Lower ontologies, which are mapped into the application’s semantics of a future concrete system. The application semantics correspond and map into the concrete syntax of the Domain-Specific Language which can be represented in graphical and non-graphical notations.
One of the non-graphical notations refers to a XML notations, which provide a background for model transformation (refer to the further research).
The purpose of AmI ontologies refers to their further reuse. Depending on the reuse the ontologies can be expressed in more than one notation and can be represented at different levels: Upper, Middle, Lower, Lowest
[
The way of inference of the ontologies is depicted in the (
The studying extracts the meaning of the concepts, which were met in the existing examples. Such meanings provide the semantics for DSL-AmI-Creator. Obtaining the Upper ontology is provided through an abstraction of the middle ontology. Its purpose concerns a providing the semantics for basic modeling concepts, which refer to the meta-models and meta-language concepts. Apart from these the A-MDA ensures the activities for obtaining the requirements for the software tools. The tools should support the feasibility of the producing the notations. The overall approach to an extracting of the semantics for the ontologies from the existing examples is based on the motto:
“Summarize the commonalities and distinguish the differences of AmI-based entities”.
All of the examples showed an existence of the same concepts, containing such notions as Environment (in capacity of a holder of AmI content), Devices intercommunicating through Network, Context providing different information about the environment and Time as length of some kind of a process or performance. These refer to the properties of AmI domain and present a set of the standard characteristics of AmI domain.
The nature of AmI environments is characterized by two contexts of the physical (or time-spatial) entities and software. The successful work of the AmI environments is supported by the appropriate software. Referring to it the ontology comprises software and time-spatial components (
Software residing on the Devices including:
o Sensors’ software.
o Actuators’ software.
o Sensor-actuators’ software.
Software supporting a working Network ensuring a successful work of the interconnecting devices including:
o Servers’ software.
o Nodes’ software.
Software supporting a work of a Control Unit of the entire AmI system including:
o Software of an Operating system.
o Software of a middleware supporting the logic of the system.
o Software of probable applications e.g. modulator/demodulator.
The software component does not participate in the actual building of AmI environments will not be considered in details in this paper. The ontology of the time-spatial context refers to the main focus of building of AmI environments. It comprises a set of the components interconnecting through interfaces as shown in
Environment.
Network.
Devices.
Time.
Context of the Environments referring to its different properties.
These concepts (depicted as ellipses) communicate with each other through interfaces, which can be of hands- free (depicted in dashed lines) or direct (physical) contact (depicted in solid lines). The directions of the intercommunications are shown as the arrowed lines. For example, it is shown that Environment contains Devices, which are capable of detecting a Context. The pointing down arrow shows that the Context’s data is to be processed, but the actual process is not a concern of the current paper.
The central entity of the
ties are taking place during some period of time and refer to the notion of process or performance. The research interpretation of the AmI domain is presented in the model of middle ontologies and upper ontologies. They are expressed in forms explaining that Middle ontology of AmI comprises Holder/Environment, Device, Context, Network, Time and Process. The middle ontology is referred to the expression:
The upper ontology of AmI comprises elements of Object, Subject and Process:
The every concept comprising the ontologies has its own properties and can be considered as a domains on their own rights, example of which is depicted in the
public class Environment{
private String Name;
private int ID;
private String type;
AmIMeasurements [
AmICoordinates [
AmIContext[
AmIDevice[
AmINetwork[
AmITime[
pulic r_type performance()
{//methods can referto UserRequest}
Regarding to the both of the contexts the research presents a mathematical representation of AmI domain (
It is expressed as a adequateness of the result f(a) at the right-hand side of the equitation to the requests obtained as a sensed data by a set of sensors. It tells that every response (or action) f(a) is provided on the identified request, obtained as output from the set of sensors (s) number of which varies from none to indefinite. Further the current research states that every action or a particular event (a) is taking part in a response to a particular request (s) in the particular environment (e) and at the particular time (t) as shown in the Statement 1: ∀a∃s,e,t . The current research argues that it is possible to apply the mathematical model to an expression of the entire AmIHolder. The research speculation states that Ambient Intelligence can be executed in some kind of
physical existence characterised by certain dimensions. Every sensor placed in such existence gets the data from a particular position, identified by coordinates (x,y,z) and in a particular time, which is depicted in the Equitation (1).
The equation should be read as follow: “The overall performance pi at the locale l comprises the perfor- mances, presented in the summarized environments e which is(are) equipped with the network(s)n, assisting the summarized number of performed actions in responses to the set of calculated requests (value of sensing data). The requestes are obtained from the sensors, allocated to the specified coordinates at the detected time t0”. This equitation indicates that AmIHolder can comprise an unlimited number of sensors, actions, networks and environments. It also refers to one of the version of the AmI ontologies represented in the form of mathematical notations. Such can be reused for the identification of the precise components of the future AmI systems, explaining the nature of AmI in the most abstract way.
The actual DSL with its appropriate concrete syntax corresponding to the development stages (
Having provided the background for the development of AmI-E software systems, the A-methodology describes the development process at the Horizontal part of A-methodology (or Horizontal methodology). It realizes the development of AmI environments (or systems). The structural flow of such realisation resides on the level M1 of A-MDA and describes the step-by-step methodology of the complete AmI-E development process.
Every step provides the semantics (purpose or meaning) of the modelling stages and expresses the require- ments to the modelling concepts to be implemented in the concrete syntax, one form of which refers to the graphical notations. Horizontal part specifies a set of the possible models and concrete modelling elements, participating in the development of AmI environments, which finalised with state-chart diagrams representing code. The modelling elements are abstracted in the groups, providing basic entities, from which the elements are derived and; models are constructed. The idea of the horizontal methodology with the appropriate modelling stages are summarised in
Initial description in textual form.
AmIHolder content.
Content of the separate environments.
Activities at the separate environments and detailed models of the separate environments as graphical models.
Code representation in Java language notations.
These suggestions express the requirements to the Domain-specific language-AmI-Creator, which should provide means of textual, graphical and Java programming representations of the particular stages of the devel- opment process. To support the idea of MDD for the development of AmI-E it should be supported by the ap- propriate software development tools. The requirements to the tools comprise their capabilities of expressing of all necessary notations specified in DSL.
The A-methodology can be applied to the development of different domains with complex organisation in two ways.
Figure19. Concrete syntax of the AmI-Creator DSL for depicting of more detailed performance at environments.
The first way is dedicated to the cases when a developer approaches to a development without previous knowledge about a domain and/or a way of its creation. The current research demonstrates a use of such way through a consideration of AmI domain. Such case requires studying the domain through the available sources of information, e.g published documentation. Consideration and analysis of the information should be followed by an extraction of the meaningful elements with their succeeding abstractions in groups, which represent the domain concepts accompanied with their intercommunications. The intercommunications of the entities can be purposeful and lead to a performing of some processes. The groups with their intercommunications and pro- cesses are represented in ontologies of real world (see A-MDA level M0). The ontologies represent the domain semantics and provide a list of meaningful elements for initial modelling to be undertaken at A-MDA level M1.
The purpose of the activities at the level M1 is to investigate the modelling stages forming the entire modelling process finalised with models of code. The result of the investigation specifies the entire set of activities to be completed towards the final target of modelling code. Every stage of the modelling process has its own aim, which requires its own expression in some kind of formal representation.
Such multi-level representations refer to notations of multi-language dedicated to AmI domain with its focusing on the development of AmI environments. The multi-language should have two main notations: textual and graphical. They correspond to the development stages (see
Concluding this part the current research shows that the first way is dedicated to preparing a base for the horizontal part of the methodology, which is devoted to the development of Am-E and described as a second way of using the methodology and dedicated to the development of AmI environments.
The second way of using the methodology (also refer to continuing of the First way) should be used during the development of a prospective AmI-E, when a domain is already learned, tools are specified and set of models are already identified and complete. The activities comprising the Second way refer to the horizontal part of A- methodology (corresponding to
1) Identification of the entire structure of the AmIHolder.
2) Identification of the AmI environment content.
3) Identification of the content of the AmIHolder, comprising the entire set of the environments and their sequence in order of their engagement in the entire process.
4) Clarification of the content of the separate environments with the specified performances.
5) Detailed consideration of the performances in a dedicated diagram.
6) Visualisation of the code of the final activities.
This part demonstrates the activities showing whether the provided approach feasible through validation, verification and testing. The validation was provided for ontology, the AmI-Creator’s semantics and syntaxes, existing languages and tools. Verification is provided for the proposed hypothesis. Testing is provided for the entire approach.
The validation of the AmI ontology was provided on three different examples from different domains compris- ing business, health and self-care-related applications, corresponding to Maria Scenario9, Virtual Hospital10 and Tea-making application [
Such, for example the Patient case shows that AmI activities take part at Environments (Reception room, Examination room, Surgeon room and Recovery room), which comprise AmIHolder. Every Environment con- tains a set of the Devices capable of detecting a different environmental data or Context. The example of such device is a device capable of a detection of a specific signal (or a Context) from a patient’s tag. The Device is equipped with a data-detecting feature; the patient’s tag is equipped with signal-generating features. Such fea- tures ensure the interconnections, which facilitate a Network. A signal’s generating and its detection take Time. This validation showed the presence of all elements of AmI ontology: AmIHolder, Environment(s), Device(s), Context, Network(s) and Time. The result of the verification, summarized in the
The verification of the considered existing languages and tools demonstrates that they cannot facilitate the development of AmI systems. This is because they cannot completely satisfy the requirements to building of AmI environments, narrowed to the certain number of notations and development steps. Such requirements refer to an ability of the tools to provide all notations necessary for building of the software application from AmI domain (
1) Initial textual description of the functionalities of the entire system and at the separate environments(at stage one).
2) Depiction the entire AmIHolder and environments in an architectural notations (at the stage two see the concrete syntax of AmI-Creator at
3) Expression of the analysis at the stages 1 and 2 in the modeling concepts, which are the graphical depictions of the AmIHolder comprising the Environments and their order of the participation in the overall perfor-
Application | AmIHolder | Environment | Network | Device | Cotext | Time |
---|---|---|---|---|---|---|
Maria | Yes | Yes | Yes | Yes | Yes | Yes |
Patient | Yes | Yes | Yes | Yes | Yes | Yes |
Tea | Yes | Yes | Yes | Yes | Yes | Yes |
VP | MetaEdit+ |
---|---|
Provide predefined graphical notations | Allows creation of graphical notations |
Does not provide coherent development of an application | Does not provide coherent development of an application |
Offers various diagrams meaning of which can be vague | Offers some pre-developed examples with graphical notations |
Does not allow depiction of time and activities in the same diagram | No inbuilt examples showing time and activity representation |
Generate Java code as code shells with | Instantly generate XML code |
Attributes and methods and XML Schema | Requires a lot of efforts to develop code generation |
Present separate diagrams only | Requires a lot of efforts to develop code generation |
Generate Java shell from Class diagram only | Do not have means of the analysis of an application |
Does not allow depiction of meta-concepts (which means it is not possible to reuse the developed parts) | Allows meta-concept; development profiles and reuse |
mance (at the stage three see the concrete syntax of AmI-Creator at
4) Analysis of the activities at the separate environments (at the stage four see the concrete syntax of AmI- Creator at
5) Analysis of the kind of the devices and their placement at every environment (at stage five see the concrete syntax of AmI-Creator at
6) Analysis of the behavior of every environments (at stage six
7) Graphical representation of each performance allocated at the appropriate environment (at the stage seven see the concrete syntax of AmI-Creator at
8) Detailed representation of each performance (at the stage eight
9) Code representation (at the stage nine see the concrete syntax of AmI-Creator at page 14).
The
MetaEdit+ does not provide features of the analysis of the system under the development. The current research understands that MetaEdit+ is dedicated to a representation of very small systems (sometimes manually provide features of the code generation). Development of the large systems or representation of multi-level language introduces a problem of depicting of the links between the models. According to a MetaEdit+’s manual, a development of sophisticated language notations takes time.
MetaEdit+ supports meta-modeling features and advertises a full code generation. Closer look at the manual discovered that MetaEdit+ provides editor for a manual writing code. It provides a very limited (ready to use) transformation of graphical notations into XML. Taking in an account the content of the manuals, the current research’s own experiments with the existing examples and attempts to develop an own multilevel language showed that a development of such language introduces a problem and requires an additional training (time on which will oversee the time allocated on the entire research). It also would require a lot of programming experience in writing a translator from graphic-based to a programming-based modeling (program-based implies a use of the conventional programming languages as Java, C++, C sharp).
The overall UML at VP contains two types of diagrams: Structure (to depict statics in the modelling) and Behavior (to depict dynamics in the modeling). They comprise thirteen diagrams and eight sub-diagrams. The set of diagrams covers a very wide range of purposes for the development and at a first glance it looks like they possibly could solve the problem of modeling of AmI environments. The following text describes the results of the experiments with the existing tools. It shows how fully a use of UML can satisfy the requirements for the tools capable of holding all features necessary for the development of Ambient Intelligence environments.
The first step in the AmI-E development refers to the initial description of a prospective AmI-E. Visual Paradigm provides two types of the textual support, referring to the “textual analysis” and “report”. The VP intention of using the “textual analysis” is to identify the future modeling elements, e.g. class, actor, activity, actions, whereas “report” features refers to a generation of the report from developed models. The second kind of the textual support can only be generated and for this reason it is not suitable for the initial description.
The first type of the textual support cannot be adapted for producing the initial documents to be discussed with the customer as it does not provide the features of importing an image file (with picture of the environment) or drawing a content of the environment for the third stage of the development. The activity of “Producing a high level of a graphical model of an entire system” by modeling features of VP shows that UML provides several types of diagrams capable of depictions different features and comprises Class diagram, Component diagram, Package diagram, Deployment diagram, Object diagram, Composite structure diagram.
The consideration of UML’s class diagram shows the problems with depicting activities. For example Class diagram is not capable of depicting a notion of time, which is important for the current research context. Otherwise it is capable of the depiction of a Device, Environments with the allocated performances, which should be completed at the AmI-E.
As UML Use case diagram refers to a behavior diagram the current research tried to adapt it for a depiction of statics along with system functionalities. The Use Case diagram shows that a Device (expressed in an Actor UML notation) is a communicating device capable of communication with other devices. The Use case diagram can depict the set of operations (or performances) and places of their allocation, but cannot show the exact sequence of such; as well as cannot depict time when the operation is to take part.
The consideration of the other kinds of the diagrams comprising Component diagram, Package diagram, De- ployment diagram, Object diagram, Composite structure diagram, Interaction overview diagram demonstrates that these diagrams are not dedicated to such features and their adoption would bring the same complications as lack of precise sequence of the operations and time depiction. The following experiment involves the consideration of UML’s ability to cope with the tasks referring to the dynamic processes in the separate environments. For this purpose the current research considers the behavior diagrams: Use case, Activity, Interaction (Sequence, Communication, Interaction Overview, Timing) and State Machine diagrams.
Having considered the Use case diagram the research looks at the features of Activity diagram allowing a depiction of an Environment, the set of the elements comprising the environment and the performance.
The vertical swim-line of the Activity diagram is capable of an incorporation of the features representing environments. Despite activity diagram allows creation of an additional swim line dedicated to the depiction of time, the features of this diagram are not capable of the depiction of a precise point of time or length of time. The identification of the precise sequence of the operations courses a problem.
The consideration of Communication diagram showed that it can be adapted to a depiction of the AmI environments parts, but it is not capable of a depiction of the entire environment. The diagram is capable of a depiction of the sequence of operations in the graphical (arrowed) notations with the appropriate numbers. The diagram is capable of depicting of the overall process, but is not capable of an identification of a point or a length of the time in a form other than a textual note. There is also some confusion in the depiction of the sequence of the operations. For example in depiction of operations numbered as 2 (Context detection) and 3 (Performance) can show that the operation number 3 is depicted earlier then the operation number 2. This is incorrect: the performance (or reaction on signal detection) cannot take part earlier than the signal detection. The other point required mentioning is inability of an error correction: if a developer requires an inserting of an additional operation, he needs to start modeling since the very beginning as the tools would not display the corrected activities in the required order.
In conclusion the research realizes that none of the tools are capable of depicting the entire AmI environments development process. Based on these considerations the research provides a solution presented as DSL in the meaning of multi-level language and taking some features of UML and MetaEdit+. Also based on the experiments with VP the current research proposes a solution: to provide a precise depiction of the time in the graphical notations supported with the features of expressions in numbers.
The verification of the Language approach to the development of AmI environments showed that the number of the obtained notations is sufficient for the development of all stages and all notations which were met in the considered examples.
The proposed solution was tested on the developments of three different applications comprising: Tea-making application, Maria-scenario and Patient at the surgery. Because of too large sizes the demonstration of two first applications are not included in this paper. The third application is presented fully. It demonstrates an entire process of using of A-methodology’s horizontal part. The testing of the proposed solution comprises inspection of:
Whether the proposed set of steps of the Horizontal methodology is sufficient for the development of AmI-E.
Whether the proposed AmI-Creator is capable of depicting the all necessary entities.
1) The proposed solution is demonstrated through the Patient example based on the step-by-step sequence of performances. The future application refers as a process-based. The area of the application of the system refers to health care organizations. The analysis comprises: “The purpose of the system under the development is providing an electronic maintenance of a patient records’ assisting a person during his/her presence at a hospital. The treatment journey is starting at a patients’ consultancy room and finishing at a patients’ discharging room. The treatment is taking place at a sequence of different environments with different functionalities. All of these environments are supplied with a device containing patients’ records. Completing the predefined functionalities requires a sequence of specified environments (patient reception room with nurse taking initial data from patient; patient examination room with doctor-consultant examining the patient health condition; surgery room with doctor providing operation; after surgery patient’s room for patient recovery (visited by doctor-consultant and nurse)). The listed environments are supplied with equipment supported with sensing devices capable of detecting tags and voice commands. Such detections are based on hands free communications through wireless network. The communication requires time to complete a set of tasks allocated to the appropriate environments.”
2) The area of the application of such system refers to health care organizations.
3) Analysis of the future system shows that it has to have a set of environments with contexts, detectable by the appropriate devices, devices network interconnections, time to commit an activity. The initial studying of the desired features showed that fulfillment of the features, servicing patient treatment at the hospital requires: devices (tags, interrogators, voice activity recognition, electronic device supplied with database as hospital server, computer-clients), context to be detected (e.g. tag signal or voice command), network features to send the information for storage and processing, time to complete request and response, environments the performances should take place. All of these refer to the properties of Ambient Intelligence, which support the purpose of maintenance of people everyday life-so such system is to be considered as of Ambient Intelligence.
4) AmIHolder content: “The AmIHolder of the Patient case consists of reception room, examination room, surgery room, recovery room” which are shown at the picture
5) The main elements of the future system, refer to environments are depicted in the diagram
6) The analysis of the separate performances are as follow:
Reception room: On placing the patient at the appropriate position the patient’s tag is detected and the specified information is uploaded onto the tag.
Examination room: Room tag detection device detects the patient ID through the tag, identify the patient and displays the data on the device screen.
Surgeon (or operation theatre): Room tag detection device detects the patient ID through the tag, identify the patient, notifies surgeon about the patient health conditions and start recording the operation at the specified time.
Recovery room: Room tag detection device detects the patient ID through the tag, process the data, finds and displays the data about the patient.
The set of the environments at AmI Holder, organized in the order of their participation in the overall performance depicted in
7) The detailed description of the sub-performances in
a) At the reception: The passive tag is placed at the allocated area; on the request communication it sends the responding signal, which makes the controlling device start uploading patient information if tag is empty.
b) At the examination room: the patient with the tag) is placed at the allocated area; the controlling device sends the request to communication; the tag responds by the signal; the controlling device ConDev) performs the appropriate activities.
c) At the operation theatre: the ConDev sends the request signal; the tag responds; the ConDev displays the information on a screen and stars recording the operation.
d) At the recovery room: the ConDev sends the request signal; the tag responds; the ConDev displays the information on a screen.
8) The identification of the needed devices are summarized in a dedicated
a) The patient’s tag is invoked by a request to communication signal and responds to it. So this detectabledevice refers to passive tag.
b) The requesting devices refer to controlling devices, situated at the controlling rooms of the appropriate environments.
9) Division of the overall performance into the separate performances is summarized in the
10) The analysis of the sequence of the performances showed that they take part one after the other, which lead to conclusion that such AmI-E is a performance oriented.
11) The detail sequence of the sub-performances with the appropriate environments are as follow:
a) At the reception: The passive tag is placed at the allocated area; on the request communication it sends the responding signal, which makes the controlling device start uploading patient information if tag is empty
b) At the examination room: the patient (with the tag) is placed at the allocated area; the controlling device sends the request to communication; the tag responds by the signal; the controlling device (ConDev) performs the appropriate activities
c) At the operation theatre: the ConDev sends the request signal; the tag responds; the ConDev displays the information on a screen and stars recording the operation
d) At the recovery room: the ConDev sends the request signal; the tag responds; the ConDev displays the information on a screen
Environment | Performance | Devices |
---|---|---|
Patient reception room | After the tag recognition the reception control device uploads a patients ID and data on the patient tag | Patient wrist tag refers to a passive tag (equipped with read-write RFID (Radio Frequency Identification) or SAW (Surface Acoustic Wave)) |
Doctor-consultant room, Operation theatre, patient recovery room | On the patient’s taking an appropriate position the room control system Identifies the patient and display data on the appropriate screens | Patient wrists tags (e.g. read-write RFID (Radio Frequency Identification)) or SAW (Surface Acoustic Wave). ConDev device computer is equipped with interrogator. |
Performance | Performance description |
---|---|
Uploading ID and data about patient on his tag | On arriving to the hospital a patient is given a wrist electronic tag. When patient is registered, the information about him is stored on the server, holding database records of all patients. This is done wirelessly through the communication distance up to 10 meters: When patient is placed at the appropriate position (one at the time) the room controlling device detects the passive tag and sends the appropriate data on it |
Identifying patient at the doctor-consultant room | When patient entered in the consultant’s room, his passive tag is detected by client computer’s interrogator; the room controlling device displays the information about the patient on a screen |
Detecting patient at the operation theatre | When patient is in the operation theatre his tag is identified by the reader of the controlling device and displays the appropriate patient’s record and start recording the operation |
Detecting Patient at the recovery room | When patient entered in the recovery room, his active tag is detected by the controlling device, which finds and downloads patient’s ID. When patient is discharged from the hospital his device is disposed |
12) The modeling of the separate performances for example as modeling of the performances at the appropriate environments: Reception room (top right counter), Examination room (top left corner), Operation theatre (bottom right corner), Recovery room (bottom left corner); and obtaining a pattern is shown as in
13) More detailed analysis of the performances is shown in the
14) Mapping into Java class is shown in the
so Examination/Operation/Recovery rooms) is depicted at the diagram as a swim line “Environment”. It corresponds to the Java class with the same corresponding name. Further (from the ontologies we learn that AmI environment has several properties) the properties of AmI environments map into the appropriate attributes of the class. Such swim lines depicted as Time/Context/PatientTag (or Device)/Network/ConDev (or Device) represent properties of the environments and map into the appropriate Java notations. The prop-
erties are presented as classes because they have their own properties. The classes are shown as set of array data type because the instances of these classes can correspond to the several properties with different values. Such for example class Device can contain Patient Tag and Connecting Device. In this case the Device class will have two instances, what would be indicated as index of 2: Device [
This part provides a summary of the completed research.
Along with the demonstration of how to develop an AmI-based software application from scratch the current research positively answered the research question “whether the attraction of SE and MDD into the development of AmI-E is the right approach to the standardization of such development”. It also proved the research hypothesis that “MDD approach to the development of AmI environments is possible and can be produced”. Giving a positive confirmation the current research points out on the benefits of using the proposed approach and expansion of its applicability to a development of other systems with complex organizations. The research showed a number of models derived during the process of the current research. These models can be used at the appropriate stages of development. Every model has its own notations, which refer to concrete syntax of AmI-Creator. The first part of the multi-level language is expressed in natural language. The second part takes the form of the notations depicted in
To complete the presentation of the AmI-Creator one more set of notations is presented in
In the author’s opinion the current research produced the following knowledge updates at the fields of Ambient
Intelligence and Software Engineering:
1) Adapted use of MDA.
2) New step-by-step methodology based on the specified sequence of models.
3) New insight into the development of DSL, starting from identification of modeling semantics, followed by the language syntax.
4) Development of AmI ontology providing semantics to the corresponding models AmI.
5) AmI ontology providing indistinguishable entities of Ambient Intelligence domain.
6) A methodology for the development of AmI environments finalized in code.
7) Visualization of the intercommunication devices.
This section provides the demonstration of the advantages of the proposed approach through a comparative analysis of the two latest approaches published after the starting date of the current research.
The latest literature survey showed some of the AmI-relevant publications, dedicated to other areas of AmI e.g. towns and wider geographical areas, beach and dance floor. They do not produce DSL or AmI development methodologies. Some of them show stages such as identification of the purpose or development hardware and software (without giving the detailed explanations).
The first example proposes an approach to building a prototype. Alternative to De Ruyter’s approach [
The second example [
Differently from this approach the current research does not specify a particular application area.
In contrast to both of the described approaches the current research pays particular attention to the provided feedback. Such feedback can help to speed up the process of the AmI-E development and avoid an unnecessary testing before planning and analyzing the prospective AmI-Es. Therefore, the Horizontal methodology defines the step-by-step process of the actual development of the prospective AmI-Es. Along with providing the means of intercommunication it provides the sequence of models, finalized by the models of the working code. Such modeling process leads to modeling of the code. Such approach can alleviate the process of coding and help to avoid coding errors. It also can help to speed up the entire process for the development of AmI-E.
The development of the Patient AmI-E took sixteen single person’s working hours of to fully develop such environment (by hand) and model the final code. In comparison with the information given in the De Ruyter [
By producing A-methodology the current research proved that SE MDD (showing way from one model to the other) is possible. The presented AmI-Creator with the appropriate tested methodology and demonstration of the developed environments proved that MDD development exists.
The current research can be considered as state-of-art in the chosen field, which is dedicated to serving needs of the third wave of computing (AmI as Ubicomp) by means of fourth generation of software development (showing a way to code generation through a realization of mapping).
The reason for a considering the presented work as the state-of-art is because it presents the easiest way of creating of Ambient Intelligence environment from scratch. The benefits of using such approach cover leaving coding to the latest stage of the development. This approach helps to reduce considerably (or completely avoid) error in the final code. Providing these, the presented work helps to reduce labor and time consumption. It also allows producing the AmI environments in easy and error-reducing steps.
Furthermore, the research provides the direction for the further development in AmI domain by extension of its applicability to the other frameworks (for example for concurrency). The current research presents a process- oriented framework. Moreover, the current research assumes the applicability (or adaptation) of the methodology to other systems with a complex organization. Besides, the current research based its own realization of the subject on the consideration of the existing SE approaches and AmI-dedicated experiences (shown appropriately in
The realizations and completion of the identified subject depicted in
research. The “Research of AmI development Approach” can be extended to the development of other AmI domain frameworks (e.g. collaborations of several sensing devices leading to single or multiple decision output system, based on different sensing readings). The “Software development approaches” (referred to A-metho- dology) can be applied to other areas of systems with complex organization.
I would like to acknowledge EPSRC funding for making this research happened.