Docstoc

A Tropos Based Requirement Engineering Frameworks for Self Adaptive Systems

Document Sample
A Tropos Based Requirement Engineering Frameworks for Self Adaptive Systems Powered By Docstoc
					                                                              (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                Vol. 08, No. 04, July 2010

              A Tropos Based Requirement Engineering
               Frameworks for Self Adaptive Systems

                      Farah Noman                                                                Zafar Nasir
           Department of Computer Science                                            Department of Computer Science
National University of Computer and Emerging Sciences                     National University of Computer and Emerging Sciences
                   Karachi, Pakistan                                                         Karachi, Pakistan
            farah.nomansaghir@gmail.com                                                   zafar.nasir@nu.edu.pk


   Abstract—The applications developed during the current era             for the development of autonomic systems. Thus such systems
are deployed in environments which change over the course of              are meant to extend their capabilities to restore to a normal
time. These changes if occur in a normal application would                functioning state from an error state. Thus if such an ability is
require re-work so that design and architectural level updates            incorporated in the current systems then unlimited
should be implemented to cater to the newly changed application
environment. This is turns results in wasted effort and increased
                                                                          environmental changes can be effectively catered and the
cost for the system maintenance. Hence there arise a need for             systems can be made available for infinite periods thus
systems that are able to alter their functioning so as to adapt to        reducing the system maintenance cost and in turn saving
the changing environmental needs and to heal themselves                   organizational budgets [2] [3].
automatically from likely errors and system failures without the
need of human intervention. Such systems are known as Self                   The paper presents a Tropos based framework which
Healing, Self Adaptive or Autonomic Systems.                              focuses on the requirements engineering perspective for self
                                                                          adaptive systems. The Tropos methodology is incorporated
   The approaches and frameworks used for gathering, analyzing            with the RELAX language specification constructs to cater all
and specifying requirements for Self Adaptive system are quite
different from the traditional life cycle and require a different
                                                                          the uncertainty factors ingrained in the self adaptive systems
line of action from the processes which are followed when                 execution environment.
capturing requirements for a normal system whose environments
are relatively stable and all the system states are known before                     II. RELATED WORK / LITERATURE REVIEW
hand.                                                                        During the recent years the area of software engineering
                                                                          have witnessed tremendous amount of research and analysis in
  This research focuses on analyzing the various methods,                 the field of self adaptive systems which is conducted in almost
techniques and frameworks for gathering requirements for Self             all the verticals of software development of self adaptive
Adaptive systems. A Tropos based approach has also been
                                                                          system right from their inception to modelling to engineering
proposed for requirements engineering for self adaptive system.
                                                                          and quality assurance [5]. This has resulted in the onset of a
   Keyword-component; Self-adaptive Systems; Requirement                  vast number of techniques for each of the system development
Engineering; Autonomic Systems; Agent oriented Methodologies              domain. A brief discussion of these techniques is as follows:

                       I. INTRODUCTION                                       The core concepts of most of the requirement engineering
                                                                          techniques for self adaptive systems are derived from the
   The changing needs of the modern era have led forward to               concept of goal models where a requirements model is
an application domain where the underlying environment of                 developed through the usage of specific environmental
the system often changes. Such changes occur as part of the               conditions and goal states. Agents are allocated to goal
normal working course of the system and are considered as                 traversal graphs where alternative conditions are to be
part of the common working environment. Thus if such                      considered or negotiated with respect to the specific system
changes are catered to so as to ensure the smooth functioning             variables [6]. One of the earliest goal modelling notations such
of the systems, the system should also be designed in a way so            as KAOS (Knowledge Acquisition in Automated Specification)
that effective decision making can be performed by the system             [7] and i* [8] presents a comprehensive overview of goal
to alter and adapt their behaviours to the changing                       models however in such approaches there is no scope for
environmental needs [1].                                                  catering to uncertainty or adaptively of the system. Hence
                                                                          researchers have proposed extensions of the goal directed
  Although most of the self healing systems development                   requirement acquisition techniques for self adaptive systems.
approaches are in infancy but many industry leaders such as
Microsoft, IBM and SUN and performing extensive research




                                                                     60                              http://sites.google.com/site/ijcsis/
                                                                                                     ISSN 1947-5500
                                                            (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                              Vol. 08, No. 04, July 2010
   Amongst the many extended approaches, one of the                     proposed for self adaptive systems lack some aspect or the
prominent one is that of the KAOS specification language                other. Some techniques make use of the goal models by
incorporated with the “Adapt-Operator” [9]. Another approach            defining system alternatives and environmental constraints
focuses on formal methods such as the RELAX specification               while completely ignoring the system environmental
language for converting traditional requirements statements to          uncertainty factors whilst the other which caters to this
the ones that are able to cater to the uncertainty of the self          uncertainty factors does not provide a systematic mechanism
managing systems [10] [11]. Extension to this approach                  for transforming the developed specifications into formal
provides an amalgamated view of the goal graphs and RELAX               architectures, and design.
by placing specific language constructs in goal graphs nodes
where adaptation is specifically required [12].                            Although some of the work has been performed in defining
                                                                        an amalgamated view of the goals models with formal
   An extended approach defines the pathway of transforming             specifications language for self adaptive systems [12] however,
the requirement specification to the software architecture. This        they take into consideration the general goal models without
approach derives the self adaptive component model from the             focusing on specific ones which can expedite the requirements
KAOS goal model [13]. Another similar approach focuses on               engineering process and which are flexible enough to cater to
the development of a formalized notation in terms of Unified            the requirements change during the system execution
Modelling Language (UML) for the requirements specification             environment.
of self adaptive systems [14].
                                                                           Thus we propose a consolidated framework for
   A different framework focuses on the classification of goals         requirements engineering for self adaptive system by
into soft goals and hard goals thus defining a road map for             incorporating the TROPOS requirements specification
converting the goal models to architectural level diagrams by           methodology with the RELAX specifications to cater to the
providing the concept of Autonomic Elements (AEs) [15].                 environmental uncertainty factors and to reap the benefits of
Also focusing on the system architecture, a research paper              TROPOS for easy requirements modelling and catering to the
proposes a high level approach to facilitate the smooth                 early and late stage of the requirements engineering life cycle.
transition from the system requirements specifications to the
system architecture [16].                                                  The subsequent section briefly presents the main rationale
                                                                        behind the proposition of the requirements specification
   Utilizing the strengths of the i* modelling language for             framework. The next sections explain the TROPOS
representing goals models, a different approach focuses on the          requirements engineering framework followed by the
requirements specifications for embedded self adaptive                  introduction of the RELAX specifications. The next section
systems [17]. Focused on the distributed software systems, one          will shed light on the actual process and various steps of the
more approach defines a framework to develop self adaptive              extended proposed framework followed by a case study that
systems by adopting a Belief-Desire-Intention (BDI) [4].                illustrates the practical implementation of the framework.
Extension to the Tropos methodology is provided in this
approach by modelling environmental variables, goal                     B. Rationale for the Proposition of the Extended Modelling
precedence and priority and goal correlations for catering to               Framework
the flexibility required in all self managing systems.                     It is a well argued fact that specifying the requirements for
                                                                        self managing system is a testing task due to the level of
   A similar approach specifically focus on modelling the               uncertainty in the underlying system environment where the
requirements specifications for self adaptive systems by using          values of the various quantities are unpredictable beforehand.
the advanced version of TROPOS and BDI agents i.e.                      Also the techniques for requirements specification be it a goal
Tropos4AS [18]. A related technique illustrates a tool                  modelling framework or a formal specification language, they
(TAOM4E) that based on the Tropos4AS [19]. An additional                fail to cover all the aspects of catering to this flexibility in the
Tropos related approach has been proposed for requirements              requirements set. An idea has been proposed as a prospective
specification of self managing systems that provides a                  future work for catering to this problem which suggest
framework to translate traditionally captured requirements to           combining the strengths of the RELAX specification language
adaptive requirements through the combination of Tropos goal            with the contemporary goal models for proposing a process
oriented methodology and the domain [20].                               model through which thorough requirements specification can
                                                                        be performed by the analysts [11]. Thus based on the idea we
III. A PROPOSED REQUIREMENTS SPECIFICATION FRAMEWORK                    propose a process model for specifying the requirements for
                 FOR SELF ADAPTIVE SYSTEM                               self managing system by combing the strengths of the Tropos
                                                                        Modelling Framework and the RELAX Specification language
A. Framework Introduction                                               so that a robust requirements set can be developed.
   The study of the various techniques proposed by various
researchers have led to the conclusion that all the proposed              The main advantages of this approach are multi-fold. The
requirement specification and engineering techniques                    Tropos Modelling approach presents a well known and stable




                                                                   61                                http://sites.google.com/site/ijcsis/
                                                                                                     ISSN 1947-5500
                                                              (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                Vol. 08, No. 04, July 2010
process for requirements specification right from the inception           goals, soft goals, plans, resources, mean-end links and
phase of the Early Requirements gathering to the system                   intentional dependencies.
Architectural design and Implementation. On the other hand
the RELAX specification presents specific language constructs                Lastly, the methodology is built on the novel idea that the
as well as formal notations and semantics descriptions for                system to be should be modelled in an incremental fashion,
incorporating flexibility in the requirements set for self                refining it at every subsequent stage from the conceptual level
adaptive systems.                                                         to the executable artefacts through the usage of a sequence of
                                                                          transformational steps. Hence the major advantage of this
   However, if Tropos alone is applied to gathering                       methodology over the other modelling notations is derived
requirements for self adaptive systems, it cannot fulfil the              from the fact that it not only concentrates of the what or how
prerequisite for an adaptive set where specific environmental             perspectives of the system but also on the why aspect of the
variables can be quantified so that partial fulfilment of goals           system [24] [25] [26].
can be taken as satisfactory for iterating a goal path. The
RELAX specification alone lacks a formal process of                          The Tropos model is extensively inspired by the Eric and
gathering the early requirements and then iteratively working             Yu’s framework for requirements engineering which presents
upon that set to transform the requirements to the architectural          the idea of actor, goals and actor dependency links as
design and the implemented system.                                        primitive concepts [27]. The Tropos model propose a goal
                                                                          based requirements modelling technique to capture and
   Also there are a number of agent oriented methodologies                analyse both the business and system requirements, risk and
presented in literature for system modelling. However their               security and location requirements [26].
application and span of usage is restricted to their level of
                                                                           1) Phases of Tropos: The Tropos methodology is divided
maturity. Studying a number of research literature related to
                                                                           into the following four major phases of the software
the comparison of agent oriented methodologies [21] [22], it is
                                                                           development lifecycle [28][29][30]:
also concluded that the Tropos is one single methodology that
is not only stable and relatively mature but it also lays a strong
focus on the early requirements analysis where the domain                                        Early Requirement Analysis
stakeholders and their intentions are identified so that the main
reason for the system development can be acknowledged at                                         Late Requirement Analysis
the initial stages.
                                                                                                    Architectural Design

   Hence this proposed framework presents a process of
identifying the initial set of the requirements and working                                            Detailed Design
upon them for refining them to cater to the underlying
necessities for self adaptive systems. A case study is also                                           Implementation

presented for applying the framework for modelling
                                                                                      Fig. 1. Tropos Iterative and Incremental Approach
requirements of a self adaptive system such as SmartHome for
proving the practicality of the approach.                                 D. RELAX: A Specification Language
C. Requirements Engineering in Tropos                                        RELAX is a requirements specification language developed
                                                                          explicitly for self adaptive system by the researchers at the
   The Tropos is an agent oriented software development                   universities of England, USA and France. The language
methodology which is developed by a group of authors from                 constructs explicitly support the expression of the
various universities in Canada and Italy. The Tropos is a                 environmental uncertainty in the requirements [11]. This
unique agent oriented software engineering methodology that               environmental uncertainty is the core of the self adaptive
drives its strengths from three basic factors such as it keenly           systems where flexible requirements needs to be specified so
focuses on the activities that precede the prospective                    that changes to the environment and other conditions should
requirement engineering practice by collecting information                not affect the normal functioning of the system and the system
about how and why the intended system is envisioned to                    should gracefully alter its execution path to cater to such
achieve the organizational goals. Hence firstly, it focuses on            changes.
the broad picture of the system so that a perspective is
established and ground is set for detailed requirements                     The RELAX vocabulary is specified in a set of its operators
analysis [23].                                                            which are organized into modal, temporal and ordinal
                                                                          operators and uncertainty factors [11]. The following table
   Secondly, it provides means of specifying and designing the            describes the RELAX vocabulary constructs.
system right from the requirements analysis to the system
architecture, design and implementation phases in a systematic
manner. It drives its strength from the notions of actors, hard




                                                                     62                                http://sites.google.com/site/ijcsis/
                                                                                                       ISSN 1947-5500
                                                                    (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                      Vol. 08, No. 04, July 2010
                          TABLE I
                                                                              terms of early requirements gathering which adds extra
               RELAX VOCABULARY AND OPERATORS                                 flexibility and span of usage to our proposed framework.
      RELAX OPERATOR             DESCRIPTION
       Modal Operators
                                                                                 Adjoining the Tropos goal models is the RELAX
          SHALL                        a requirement must hold                specification which will be incorporated at the locations where
                                 a requirement specifies one or more          there remains scope for the system uncertainty and where
           MAY…OR
                                             alternatives                     requirements can be temporarily relaxed to support the system
      Temporal Operators                                                      adaptation process. Thus if there exist some goal paths where
        EVENTUALLY               a requirement must hold eventually
                                    a requirement must hold until a
                                                                              non-critical requirements can be partially neglected in order to
             UNTIL                                                            satisfy other short term critical requirements then RELAX
                                             future position
        BEFORE, AFTER
                                  a requirement must hold before or           specification presents specific vocabulary and constructs that
                                         after a particular event             can effectively cater to such necessity.
                                  a requirement must hold during a
               IN
                                         particular time interval             F. The Proposed Methodology Process Model
                                  a requirement specifies something
 AS EARLY, LATE AS POSSIBLE      that should hold as soon as possible            The steps for developing the requirements specification
                                     or should be delayed as long             using the mentioned modelling approach consists of a step
                                  a requirement specifies something           wise procedure for systematically performing the system
   AS CLOSE AS POSSIBLE TO
                                    that happens repeatedly but the
          [frequency]                                                         analysis so that general as well as adaptive requirements can
                                       frequency may be relaxed
       Ordinal Operators                                                      be effectively gathered. The Fig. 2 describes the high level
                                 a requirement specifies a countable          flow diagram of the modelling steps. The detailed are
   AS CLOSE AS POSSIBLE TO
          [quantity]
                                 quantity but the exact count may be          described as follows:
                                                relaxed
                                 a requirement specifies a countable
                                                                                                     1. Perform the
  AS MANY, FEW AS POSSIBLE       quantity but the exact count may be                                      Early
                                                                                                                                                                  2. Create the
                                                                                                                              High level system goals            detailed Actor
                                                relaxed                                              Requirements
                                                                                                                                                                    Diagrams
                                                                                                        Analysis
       Uncertainty Factors
                                    defines a set of properties that
              ENV                                                                                                                                              Actor Goal Models
                                   define the system’s environment
                                  defines a set of properties that can                                                                                           3. Identify the
             MON                                                                                     4. Resolve the
                                                                                                                                                                  Uncertainty
                                     be monitored by the system                                       Uncertainty        Goal nodes with uncertainty factors
                                                                                                                                                                 factors in the
                                                                                                         factors
                                   defines the relationship between                                                                                               goal models
              REL
                                    the ENV and MON properties
                                      identifies the dependencies                Refined Actor Goal Models with RELAX-ed requirements

              DEP                between the (relaxed and invariant)
                                                                                                     5. Perform the
                                              requirements                                                Late
                                                                                                                                      Consolidated Actor Goal Models
                                                                                                     Requirements
                                                                                                        Analysis
E. The Proposed Requirements Modelling Approach
   The distinguishing characteristic of the Self Managing                         Refined Goal Models with resolved uncertainty factors

system is that there can a number of pathways for realizing a                                        6. Develop the
                                                                                                         system                                                   7. Perform
high level system objective and a set of runtime environmental                                        Architectural
                                                                                                                                System Architecture
                                                                                                                                                                Detailed Design
quantities and variables dictate which particular pathway                                                Design

realization is appropriate at a particular time. Hence for
incorporating such a kind of variation in the execution paths at
runtime, the goal modelling approach for requirements                                               8. Implement the
                                                                                                                                              UML Diagrams
                                                                                                         System
specification offers support to identify and visualize various
different alternatives for satisfying the overall objectives and
goals of the system [31]. These alternatives for a system                                            Fig. 2. The Proposed Process Model
requirement can be due to differences in the system non-
functional goals such as performance, reliability, robustness
etc or due to the ambiguity in the system environment which                    1) Step 1. Perform the Early Requirements Analysis:
can affect the goal paths that are iterated at run time. Hence                 Identify and analyse the system stakeholders and their
the goal modelling approach proves to be a fine approach for                   intentions for the usage of the system. Enlist the set of actors
modelling goal decompositions in terms of its subsequent low                   and their respective high level system goals that they need to
level goals.                                                                   achieve using the system. Create the high level Actor
                                                                               diagrams in this step. This is performed in congruence with
   Hence the modelling approach is primarily based on the                      the general approach adopted for the Tropos Modelling
Tropos Requirements modelling framework that work on the                       framework.
Eric Yu’s i* modelling methodology which is one the
renowned framework for requirements specifications using                       2) Step 2. Create the detailed Actor Diagrams: Perform a
goal models [29]. The Tropos presents additional benefits in                   thorough analysis on each of the high level goal identified in




                                                                         63                                            http://sites.google.com/site/ijcsis/
                                                                                                                       ISSN 1947-5500
                                                              (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                Vol. 08, No. 04, July 2010
 the Step 1 for decomposing the goal into subsequent low-                  5) Step 5. Perform the Late Requirements Analysis: The late
 level goals unless a leaf node is achieved which is one single            requirements analysis needs to be performed where the target
 goal, resource or plan which cannot be further decomposed.                system is added as a new actor in the goal diagram together
 This step is also performed following the methodology                     with its functions and quantities. This requirements analysis
 presented by the Tropos framework.                                        models the new target system actor and its social
                                                                           dependencies on the other actors. This in turn refines the goal
 3) Step 3. Identify the Uncertainty factors in the goal models:           model by placing the concept of the overall system and its
 Iterate the goal graph developed in the previous step using a             interaction scenarios with all the system actors.
 bottom up approach from the leaf nodes to the top nodes for
 the identification of the uncertainty factors that can pose               6) Step 6. Develop the system Architectural Design: The
 hindrance in the achievement of the preceding top level goals.            system architectural design focuses on the system’s global
 These factors can be the varying environmental conditions                 architecture in terms of the sub-systems (actors)
 that should be monitored for smooth functioning of the                    interconnected through data and control flows (dependencies).
 system.                                                                   The architecture is articulated in a three step fashion where
                                                                           the overall architecture in terms of extended actor diagrams is
 4) Step 4. Resolve the Uncertainty factors: The goal graph                performed and then the capabilities to be performed by the
 nodes that are marked with the uncertainty factors needs to be            actor dependencies are defined followed by defining a set of
 thoroughly studied for mitigating and resolving the identified            agent types with one or more different capabilities (agent
 factors. There can be following approaches for the resolution             assignment). This step is performed according to the
 of the identified uncertainty factors:                                    traditional Tropos Modelling framework.
4.1)    Do not perform any refinement: If the identified                   7) Step 7. Perform Detailed Design: The detailed system
        environmental uncertainty factors does not threaten the            design is related to the system agent’s micro level activities
        satisfaction of a low level goal achievement in relation           such creation of the system capability diagrams which is part
        to its preceding higher level goal hence the node should           of the family of the UML Activity diagrams and the Agent
        be left as it is with no refinement iteration.                     interaction diagrams. This step completely models the system
                                                                           in terms of the UML diagrams to aid in the system
4.2)    Refine the leaf node with further sublevels: Sometimes             implementation phase.
       the goal uncertainty factors can be resolved by
       performing analysis on the leaf goal node and further               8) Step 8. Implement the System: The implementation is self
       breaking it up to low level goals so that the factors can           explanatory where the actual system development is
       be effectively captured, measured and analysed during               performed against the detailed design implemented in the
       the process of the goal graph execution.                            previous steps.
4.3)    Introduce the RELAX operators: As discussed earlier,
                                                                             IV. APPLICATION OF THE REQUIREMENTS SPECIFICATION
        the uncertainty factors that are part of the system
                                                                                          FRAMEWORK – A CASE STUDY
        execution environment are sometimes of a nature that
        only their partial fulfilments can prove to be good               For validating the practical implementation of the proposed
        enough for the complete fulfilment of the high level              requirements specification framework, we are presenting a
        goals. Hence for marking such state and conditions, the           case study of a SmartHome application used for assisted living.
        RELAX operators needs to be introduced in the goal                The step by step implementation of such a system and its
        nodes for providing the specific uncertainty factors and          requirements gathering and specification using the proposed
        RELAX operators for precisely measuring the                       modelling framework is described below:
        flexibility in the environmental quantities.
                                                                           1) Step 1. Perform the Early Requirements Analysis During
4.4)    Create a new high level Actor diagram: It is also an               this early requirements analysis phase where the intentions of
        observed scenario that at time the effect of the                   the system stakeholders are identified and analysed and are
        environmental uncertainty factors is so intense that no            modelled into the subsequent goal diagrams. The goal
        goal refinement or relaxation can help in following the            diagrams are modelled in terms of the hard goals, soft goals,
        normal goal graph or the execution path of the system.             plans and resources as per the convention of the Tropos
        Hence for such environmental conditions, new high                  Modelling framework. The high level actor diagram for the
        level goals needs to be identified for the system actors           SmartHome system is depicted in Fig 3.
        which will be executed according to the new set of
        environmental conditions. Also this should be noted                2) Step 2. Create the detailed Actor Diagrams: The detailed
        that this is the most expensive form of resolution since           Actor diagrams are an extension of the strategic or social
        it will require the reapplication of the Steps 1-4 to this         dependency model created in Step 1. This step includes the
        newly created goal.                                                extension of each and every goal defined in the previous step
                                                                           through analysis so that dependencies with other actors are




                                                                     64                              http://sites.google.com/site/ijcsis/
                                                                                                     ISSN 1947-5500
                                                                       (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                         Vol. 08, No. 04, July 2010
 refined. The top level goal which is under consideration is                     3) Step 3. Identify the Uncertainty factors in the goal models:
 AND-OR decomposed into sub-goals (such as hard goals and                          The step in which the uncertainty factors of the
 soft goals), plans and resources. For each of the leaf node of                 environment are identified to introduce flexibility in the goal
 the goal graph means tasks are identified which can be                         nodes. In the “Clean Security Equipment” goal graph some
 further AND-OR decomposed. Additionally, the needed                            goal nodes have been identified that can become victim of
 resources are also established.                                                uncertainty factors hence the RELAX specification operators
                                                                                needs to be identified for specifying conditions for their partial
                                                                                fulfilment. The marked goal nodes are shown in Fig 5.

                                                                                   For example, the goal node marked as “Recharge Battery”
                                                                                has an uncertainty factors related to the level of its battery
                                                                                recharge. The partial satisfaction of the goal such as a
                                                                                particular threshold level of the battery recharge levels can
                                                                                prove to be enough for the working of the Cleaner Agent.
                                                                                Step 4. Resolve the Uncertainty factors: Hence the “Recharge
                                                                                Battery” can be relaxed by introducing a RELAX operator
                                                                                known as “AS CLOSE AS POSSIBLE TO FULL”. Thus more
                                                                                RELAX operators are introduced at the “Start Dust Sensors”,
                                                                                “Start Cleaning Process” and “Find Trash Bin” goal nodes.
                                                                                The Goal graph with RELAX-ed nodes is shown in Fig 6.




          Fig. 3. Actor Diagram or the Social Dependency model

   For the sample case study for the SmartHome, we have
chosen the Cleaner Agent’s “Clean Security Equipment” goal
for refinement for creating the detailed Actor Goal Model.
This is depicted in Fig 4


                                                                                            Fig. 5. Goal Graph with marked Uncertainty factors




     Fig. 4. Cleaner Agent Goal Model for “Clean Security Equipment”



                                                                                                Fig. 6. Goal graph with RELAX-ed nodes




                                                                           65                                 http://sites.google.com/site/ijcsis/
                                                                                                              ISSN 1947-5500
                                                              (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                Vol. 08, No. 04, July 2010
 4) Step 5. Perform the Late Requirements Analysis: The                                                                         TABLE II
                                                                                                                    SYSTEM CAPABILITIES DEFINITION TABLE
 phase of late requirements analysis work upon introducing
 the SmartHome as actor named as “SmartHome Agent”                               Agent                       Capability
                                                                                                                                           Means-End
 where in similar manner the actor goals and                                     Name                           ID
                                                                                                                                                 Identify Equipment Type; Read Device
 interdependencies with the other system actors such as goal                                                    CP-001
                                                                                                                                                              Magnetic Strip
 graphs of all the goals for each of identified system actor
                                                                                                                                                 Identify Equipment Type; Decode Strip
 such as “Cleaner Agent”, “Security Agent”, “Kitchen Agent”,                                                    CP-002
                                                                                                                                                               Information
 “Store Agent” and “Device Agent” are modelled. A subset of                                                                                     Identify Equipment Type; Get Equipment
 the overall actor diagram for the System Agent is depicted in                                                  CP-003
                                                                                                                                                          Information from RFID
 Fig. 7.                                                                                                                                       Identify Dust Particles; Start AS MANY AS
                                                                                                                CP-004
                                                                                                                                                         POSSIBLE Dust Sensors
 5) Step 6. Develop the system Architectural Design: The                                                                                          Start Cleaning Process AS EARLY AS
 architectural design of the system works upon decomposing                                                      CP-005
                                                                                                                                                    POSSIBLE; Use Vacuum Cleaner
 and refining the system actors diagrams identified during the                                                                                    Start Cleaning Process AS EARLY AS
 late requirements analysis phase by describing the structure                                                   CP-006
                                                                                                                                                     POSSIBLE; Use Mopping Brush
 of the overall architecture pattern together with further                     Cleaner                                                            Start Cleaning Process AS EARLY AS
                                                                                                                CP-007
 identifying the interactions and dependencies between                          Agent                                                                POSSIBLE; Use Liquid Cleanser
 different actors by considering them as agents with the                                                                                          Start Cleaning Process AS EARLY AS
                                                                                                                CP-008
 perspective of the overall system.                                                                                                                     POSSIBLE; Use Dry Brush
                                                                                                                                                                     …
                                                                                                                                                                     …
  Various kinds of diagrams are modelled during this phase
                                                                                                                                                    Clean Security Equipment; Identify
such as the system overview diagrams, architectural style                                                      CP-(N-3)
                                                                                                                                                             Equipment Type
diagrams and the overall system decomposition diagrams.
                                                                                                                                               Clean Security Equipment; Clean Equipment
Also the system capabilities definition as well as the agent                                                   CP-(N-2)
                                                                                                                                                                   Dust
definition in terms of the defined capabilities is also developed                                                                              Clean Security Equipment; Maintain Cleaner
during this phase. A partial capabilities definition table for the                                             CP-(N-1)
                                                                                                                                                                 Dust box
Cleaner Agent’s Clean Security Equipment goal are described                                                                                    Clean Security Equipment; Maintain Cleaner
in Table II.                                                                                                     CP-(N)
                                                                                                                                                               Batter Level


                                                                            CleaningEquipment                                                                                                                         SecuredItems
                                                                                                             1..1 1..*          SmartCleaner                          SmartSecurity
                                                                          -EquipmentName : string                                                                                                            -ItemName : string
                                                                          -EquipmentType : string                          -CleanerAgent : object                 -SecurityAgent : object                    -ItemType : string
                                                                          -EquipmentStatus : object      -Contains                                                                              1..* 1..1    -SecurityMechanismStatus : object


                                                                                                                                 1..*                                   1..*
                                                                                                                                 1..1
                                                                                                                                                       1..1
                                                                                                                                SystemSensors                                                                          StoreRepository
                                                                             SmartKitchen
                                                                                      1..*                                  -SensorName : string                                                                    -ItemName : string
                                                                                                                                                                               SmartStoreManager
                                                                          -KitchenAgent :                                   -SensorModule : string     1..1          1..*                                -Maintains -ItemType : string
                                                                                                                                                                               -StoreAgent : object
                                                                          object                      1..*          1..1    -SensorStatus : string                                                                  -ItemQuantity : object
                                                                                  -generates
                                                                                                                                                                                                         1..* 1..1
                                                                              1..*      -generates
                                                                                                                                   -N      *

                                                                              1..1                           1..1                                     -1      *
                                                                                                                                                                                                  Devices
                                                                                DietPlan                                                         SmartDeviceManager            -Contains
                                                                                                              DailyMenu                                                                    -DeviceName : string
                                                                           -DailyCalories : int                                                 -DeviceAgent : object                      -DeviceType : string
                                                                           -MinCalories : int     -MenuItemsList : object
                                                                                                  -MenuCaloriesCount : int                                                     1..* 1..1   -DeviceStatus : object
                                                                           -MaxCalories : int




                                                                                                                         Fig. 8. SmartHome Component Diagram
               Fig. 7. Late Requirement Analysis Goal graph
                                                                              7) Step 8. Implement the System: Various tools are
                                                                              available using which the UML diagrams can be converted
6) Step 7. Perform Detailed Design: The detailed design                       into the code skeletons and eventually the system actual
phase focus on making the system UML diagrams for the                         implementation code. Making use of the same tools, the
system. Various kinds of UML diagrams are developed during                    development code of the SmartHome application will be
this phase so that all the aspects of the system such as it                   developed.
transitions, states, capabilities and attributes can be thoroughly
identified.                                                                             V. CONCLUSION AND FUTURE WORK
A SmartHome component diagram is shown in Fig 8.                              The requirements engineering activity serves as the basis
                                                                           for the development and analysis of any system. However, the
                                                                           system inherent behaviour and its underlying environment
                                                                           have a huge effect on the practices followed for requirements
                                                                           engineering. From the span of a large number of requirement




                                                                     66                                                                          http://sites.google.com/site/ijcsis/
                                                                                                                                                 ISSN 1947-5500
                                                                       (IJCSIS) International Journal of Computer Science and Information Security,
                                                                                                                         Vol. 08, No. 04, July 2010
engineering frameworks, goal models are usually adopted for                        [8]    Yu, E.S.K.: “Towards modeling and reasoning support for early-phase
                                                                                          requirements engineering”
specifying requirements for self adaptive systems which have
                                                                                   [9]     Greg Brown, Betty H.C. Cheng, Heather Goldsby, Ji Zhang: “Goal
a number of environmental uncertainty factors that put risk to                            Oriented Specification of Adaptation Requirements Engineering in
the accomplishment of various system goals and tasks. Thus in                             Adaptive Systems”
this paper we presented a comprehensive view of the various                        [10]    Jon Whittle, Pete Sawyer, Nelly Bencomo, Betty H.C. Cheng: “A
requirements engineering frameworks and practices following                               Language for Self-Adaptive System Requirements”
for requirement elicitation, specification, verification and                       [11]    Jon Whittle, Pete Sawyer, Nelly Bencomo, Betty H.C. Chengy and
monitoring of self adaptive systems.                                                      Jean-Michel Bruelz: “RELAX: Incorporating Uncertainty into the
                                                                                          Specification of Self-Adaptive Systems”
                                                                                   [12]    Betty H.C. Cheng, Pete Sawyer, Nelly Bencomo, Jon Whittle: “A Goal-
   Additionally, we presented a comprehensive set of the                                  Based Modeling Approach to Develop Requirements of an Adaptive
quality requirements which can serve as basis for the                                     System with Environmental Uncertainty”
evaluation of a newly proposed framework. These quality                            [13]    Shan Tang, Xin Peng, Yijun Yu, and Wenyun Zhao: “Goal-Directed
requirements measure the effectiveness of a proposed                                      Modeling of Self-adaptive Software Architecture”
technique against a variety of factors such the level of the                       [14]    Yijun Yu, Alexei Lapouchnian, Sotirios Liaskos, John Mylopoulos,
                                                                                          Julio C.S.P. Leite: “From Goals to High-Variability Software Design”
extension of the technique to various domains, the number of
uncertainty factors it caters to and the extent of the support of                  [15]    Alexei Lapouchnian, Sotirios Liaskos, John Mylopoulos and Yijun Yu:
                                                                                          “Towards Requirements-Driven Autonomic Systems”
the technique to the various phases of the system development
                                                                                   [16]    Matthew J. Hawthorne and Dewayne E. Perry: “Exploiting
life cycle.                                                                               Architectural Prescriptions for Self-Managing, Self-Adaptive Systems:
                                                                                          A Position Paper”
   Lastly based on the mentioned quality requirements, we                          [17]    Pete Sawyer, Nelly Bencomo, Danny Hughes, Paul Grace, Heather J.
proposed a goal based modelling approach for the                                          Goldsby, Betty H. C. Cheng: “Visualizing the Analysis of Dynamically
                                                                                          Adaptive Systems Using i* and DSLs”
specification of self managing systems where various
                                                                                   [18]    Mirko Morandini, Loris Penserini, Anna Perini: “Modelling Self-
environmental uncertainty factors pose a threat to the smooth                             Adaptivity: A Goal-Oriented Approach”
execution of the system goal paths. The proposed framework                         [19]    Mirko Morandini, Loris Penserini, Anna Perini: “Automated Mapping
takes its concepts from the well known Tropos Modelling                                   from Goal Models to Self-Adaptive Systems”
framework and the RELAX specification language by                                  [20]    Nauman A. Qureshi and Anna Perini: “Engineering Adaptive
amalgamating the concepts of both for creating a framework                                Requirements”
that fulfils almost all of the quality requirements of the                         [21]    Khanh Hoa Dam and Michael Winikoff: “Comparing AgentOriented
requirement specification for the self adaptive system.                                   Methodologies”
                                                                                   [22]    Paolo Giorgini, Anna Perini, John Mylopoulos, Fausto Giunchiglia and
                                                                                          Paolo Brescian: “Agent-Oriented Software Development: A Case Study”
    A great number of future directions sprint up after the
                                                                                   [23]    P. Bresciani, P. Giorgini, F. Giunchiglia, J. Mylopoulos, and A. Perini:
proposition of the respective framework where the                                         “Tropos: An agent-oriented software development methodology”
development of a formal tool for modelling such methodology                        [24]   Paolo Bresciani and Fabrizio Sannicol: “Requirements Analysis in
tops the list. Other future directions include the development                            Tropos:a self referencing example”
of a formal language which can translate the late requirements                     [25]   P. Bresciani, A. Perini, P. Giorgini, F. Giunchiglia, and J. Mylopoulos:
analysis goal models into the written requirements                                        “Modelling Early Requirements in Tropos: A Transformation Based
                                                                                          Approach”
specification so as to aid the system analysts. Various
                                                                                   [26]    http://www.troposproject.org: “The Tropos Project”
language modelling techniques are already present in the
                                                                                   [27]   E. Yu: “Modelling Strategic Relationships for Process Reengineering”
literature and their adaptation and extension in relation to the
                                                                                   [28]    John Mylopoulos and Jaelson Castro: “Tropos: A Framework for
proposed framework can serve as a promising future direction.                             Requirements-Driven Software Development”
                                                                                   [29]   Paolo Giorgini, John Mylopoulos and Roberto Sebastiani: “Goal-
                              REFERENCES                                                  Oriented Requirements Analysis and Reasoning in the Tropos
[1]   Stephan Weibelzahl: “Problems and Pitfalls in Evaluating Adaptive                   Methodology”
      Systems”                                                                     [30]   Maddalena Garzetti, Paolo Giorgini, John Mylopoulos, and Fabrizio
[2]   Debanjan Ghosh, Raj Sharman , H. Raghav Rao and Shambhu                             Sannicol-o: “Applying Tropos Methodology to a real case study:
      Upadhyaya, “Self-healing systems - survey and synthesis”                            Complexity and Criticality Analysis”
[3]   Yuriy Brun, Giovanna Di Marzo Serugendo, Cristina Gacek, Holger              [31]    Axel van Lamsweerde and Emmanuel Letier: “Handling Obstacles in
      Giese, Holger Kienle, Marin Litoiu, Hausi M¨uller, Mauro Pezz`e, and                Goal-Oriented Requirements Engineering”
      Mary Shaw: “Engineering Self-Adaptive Systems through Feedback
      Loops”
[4]   Mirko Morandini, Loris Penserini, Anna Perini: “Towards Goal-
      Oriented Development of Self-Adaptive Systems”
[5]   B. H. C. Cheng, H. Giese, P. Inverardi, J. Magee, and R. de Lemos:
      “Software engineering for self-adaptive systems: A research road map,
      Dagstuhl-seminar on software engineering for self-adaptive systems”
[6]   Axel van Lamsweerde: “Goal-Oriented Requirements Engineering: A
      Guided Tour”
[7]   Anne Dardenne, Axel van Lamsweerde and Stephen Fickas: “Goal-
      directed Requirements Acquisition”




                                                                              67                                      http://sites.google.com/site/ijcsis/
                                                                                                                      ISSN 1947-5500