UML profile for modeling product observation. - Pure

UML profile for modeling product observation.

Citation for published version (APA):Funk, M., Putten, van der, P. H. A., & Corporaal, H. (2008). UML profile for modeling product observation. InFDL 2008. Forum on Specification, Verification and Design Languages, 2008, 23-25 September 2008, Stuttgart,Germany (pp. 185-190). IEEE Computer Society. https://doi.org/10.1109/FDL.2008.4641443

DOI:10.1109/FDL.2008.4641443

Document status and date:Published: 01/01/2008

Document Version:Publisher’s PDF, also known as Version of Record (includes final page, issue and volume numbers)

Please check the document version of this publication:

• A submitted manuscript is the version of the article upon submission and before peer-review. There can beimportant differences between the submitted version and the official published version of record. Peopleinterested in the research are advised to contact the author for the final version of the publication, or visit theDOI to the publisher's website.• The final author version and the galley proof are versions of the publication after peer review.• The final published version features the final layout of the paper including the volume, issue and pagenumbers.Link to publication

General rightsCopyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright ownersand it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights.

• Users may download and print one copy of any publication from the public portal for the purpose of private study or research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal.

If the publication is distributed under the terms of Article 25fa of the Dutch Copyright Act, indicated by the “Taverne” license above, pleasefollow below link for the End User Agreement:www.tue.nl/taverne

Take down policyIf you believe that this document breaches copyright please contact us at:[email protected] details and we will investigate your claim.

Download date: 17. Dec. 2021

https://doi.org/10.1109/FDL.2008.4641443

https://doi.org/10.1109/FDL.2008.4641443

https://research.tue.nl/en/publications/2caa66bd-66a0-477d-bd30-209ab94dbb46

UML Profile for Modeling Product Observation

Mathias Funk, Piet van der Putten, Henk CorporaalDept. of Electrical Engineering, Electronic Systems Group

Technical University Eindhoven, The NetherlandsEmail: [m.funk, p.h.a.v.d.putten, h.corporaal]@tue.nl

Abstract

Nowadays interactive electronics products offera huge functionality to prospective customers, butoften it is too huge and complex to be grasped andused successfully. In this case, customers obviate thestruggle and return the products to the shop. Alsothe variability in scope and features of a productis so large that an up-front specification becomeshard if not impossible. To avoid the problem ofan inadequate match between customer expectationsand designer assumptions, new sources of productusage information have to be developed. One possi-bility is to integrate observation functionality intothe products, continuously involving real users inthe product development process. The integration ofsuch functionality is an often overlooked challengethat should be tackled with an appropriate engineer-ing methodology. This paper presents on-going workabout a novel design for observation approach thatsupports early observation integrations and enablesthe cooperation with various information stakehold-ers. We show how observation can be embeddedseamlessly in a model-driven development processusing UML. An industrial case-study shows thefeasibility of the approach.

1. Introduction

Complex innovative electronic products often failto satisfy customers’ needs. Products are too com-plicated, thus too cumbersome to use. The inherentfunctionality is often not relevant to user needsand expectations. Increasing numbers of returnedtechnically sound products support this [1]. On theother hand, nowadays products are hard to specifybecause of their high complexity and because ofrapidly changing user demands. Also, due to fastercycles, the product creation process cannot benefitfrom traditional feedback channels any more. While

a couple of years ago, a product technology couldreach maturity within 10 to 20 cycles, thus allowingfor gradual improvements, todays products have toaccomplish the same within three cycles. Obviously,delivering a mature product in this setting becomesdifficult.

Accordingly, complex interactive productsshould be built for rapid changes. Products can beadapted to changing needs during development andeven after release, in terms of firmware updatesand and the like. Still, targeting the product fora certain user base is a major problem in theindustry [1]. One reason for this is the lack ofusage information which is reliable enough to basethe further development of the product on.

Our approach towards this problem is to buildobservation modules into products. These productsare given to selected key testers who use the prod-ucts in their habitual environment - an approachpromising to yield more representative data thanusability labs. The built-in observation modules canbe configured remotely and observe parts of the sys-tem including user interaction, system performanceand potentially user satisfaction with the systemprovided functionality.

This paper concentrates on the integration ofsuch observation facilities into products. We pro-pose a model-driven technique to do this in anefficient and structured way which is tailored tocurrent system development practices. After point-ing at related work, we introduce product observa-tion together with an industrial case-study. Subse-quently, we show how observation-related parts ofthe system can be modeled by means of a novelUML profile. An overview on the developmentapproach for observation integration shows the ap-plication of the modeling. The flow from systemmodels to the final runtime which features a built-in observation system is described. The paper endswith a conclusion and an outline of future steps.

Forum on Specification and Design Languages 2008

978-1-4244-2265-4/08/$25.00 © 2008 IEEE Page 185

Authorized licensed use limited to: Eindhoven University of Technology. Downloaded on April 6, 2009 at 09:50 from IEEE Xplore. Restrictions apply.

An extended version of this paper covers the UMLprofile for observation in full length [2].

2. Related work

The remote monitoring of products has beendone before, ranging in scope from the monitoringof cars to building automation, computer programs,mobile devices, and websites [3], [4], [5], [6]. How-ever, our research is different in two important as-pects: First, in our approach we assume that infor-mation stakeholders are not willing to use complexprogramming paradigms to achieve the sought-afterdata, therefore we use a visual language to spec-ify observation behavior in a domain-specific way.Second, the integration of observation functionalityinto the target system is described in a softwareengineering process which is, in our opinion, nec-essary for widespread use. On the technical levelwe rely on the proven model-driven engineeringapproach, but also try to apply more agile modelingtechniques like model interpretation [7] that allowsfor dynamic adaptation of runtime systems withoutthe need for client compilation support. The mod-eling of observation systems is performed using theUnified Modeling Language (UML) [8] and, moreprecisely, its profile extension mechanism [9].

Our approach towards “design for observation”is related to “design for test”. The goal is toenable evaluation of systems as early as possibleand throughout the development process. Signifi-cant effort has to be spent before valuable dataemerges. However, design for test targets mainlythe scope of specification correctness within thesystem, whereas design for observation aims atthe reduction of failures during interaction betweenuser and system.

3. Product usage observation

Our approach separates the concerns of (i) prod-uct or system development and (ii) the specificationof what to observe and how to present the col-lected data. In its application, product observationinvolves accordingly two roles: the first role is asystem developer, concerned with the integrationof the observation module into the product. Thesecond role, the information stakeholder, specifiesobservation in an easy and straight-forward pro-cess. For information stakeholders, the proposedapproach opens a dedicated information channelwhich provides potentially high quality data. Even

Figure 1. Technical observation system overview

more importantly, the observation behavior can beadapted remotely to changing information needs.

An observation system [10] consists of three mainlayers: the authoring and analysis layer (AAL), themanagement and repository layer (MRL), and theobservation layer (OL) (cf. Figure 1). On the firstlayer, it can be specified what to observe and how toprocess and present the collected information. TheMRL plays mainly the role of a middleware betweenspecification of observation and observation itself,it transports observation specifications towards theOL and the observed data from products back tothe AAL. The OL is the place where the actualobservation is carried out within the product in-stances. From the development perspective, twointeresting things happen here: First, hooks haveto be integrated into the product. They repre-sent places that can be observed, that is, theyare proxies to the actual places in hardware andsoftware where the actual data is generated. Thisencapsulation helps to maintain a consistent inter-face from product to observation module. Second,observation specifications coming from the AALare transformed into executable runtime structuresand represent the logic of observation in a certainscenario. The latter aspect is beyond the scope ofthis paper and has been covered in [11].

3.1. A priori case study

We carried out case-studies to explore the do-main of observation and build experience for devel-oping an architecture. One of the studies togetherwith a large Dutch consumer electronics manufac-


978-1-4244-2265-4/08/$25.00 © 2008 IEEE Page 186


turer shall be described briefly as an introductoryexample to the domain of product usage observa-tion.

Subject of the observation was a working proto-type of an “internet on television” product with acouple of novel features. Regarding those features,the company had no market experience, so the maingoal was to explore the relevance of such a prod-uct to customers. We integrated the observationmodule partly by reverse-engineering the system forappropriate observable items, partly by intrument-ing available source code to provide data aboutusage. Eventually, 20 product instances were givento key testers located in 8 countries world-wide.These people were asked to embed the product intotheir home lifestyle and use it regularly for 6 weeks.During that time, the observation system collectedin total 800.000 data items and moreover, we wereable to test the use case of changing observationrequirements successfully. This and other exper-iments proved the applicability of the approachand motivated the development of an engineeringapproach for observation integration.

4. Modeling observation

Modeling of observation systems can be donein the Unified Modeling Language (UML). Thislanguage is an industry-wide standard for modelingof hardware and software systems. UML modelsare widely understood by developers in the com-munity, and the modeling process benefits fromextensive tool support. UML offers a light-weightextension mechanism, profiles, that is suitable forbuilding domain-specific UML models. This meansto project domain language semantics onto UMLby technically extending it with a dedicated set ofnew concepts.

The observation profile as shown in Figure 2 isbasically divided into five sets of subprofiles thatcorrespond to the layers of an observation system(cf. Section 3). While the upper 4 profile packagesare entirely concerned with the observer side of thedata collection process, the observation executionprofile package at the bottom of the figure involvesboth observer and observee roles. There are twosets of stereotypes, each concerning one of the tworoles in the observation integration sub profile. Thisis especially interesting as the thin line betweenthe sets can be drawn right through this profile.Both sets have a close relationship as observedinformation is transmitted directly between sys-tem parts which have complementing stereotypes

Figure 2. Observation profile (package view, depen-dencies omitted)

applied to them. Inside the observation executionpackage there are two packages concerned withthe architecture and integration of observation intoproducts. Another package deals with the observa-tion behavior at runtime, and the remaining pack-age provides structures for the observation data.

4.1. Observation integration subprofile

Figure 3. Integration profile

In the specification of observation, hooks are usedas information sources. However, hooks are onlyabstract places where information can be perceived.Therefore, on the system level, a «Hook» is re-alized as a proxy element that encapsulates thecombination of an «Observable» element and itsobservation-related properties, such as «Character-istic» and «Constraint». Characteristics cover tim-ing properties and data types, constraints describe


978-1-4244-2265-4/08/$25.00 © 2008 IEEE Page 187


runtime limitations of the observable. This meta-information can be used to implement predictableobservation modules, or to simulate observationbehavior prior to deployment.

Hooks and observables are basically two differentviews on the same entity. From the hook side,only observation-related properties are shown andother information, e.g. about the implementation,is hidden - vice versa from the observable side. Bothconcepts are aggregated in respective concepts,«HookModel» and «Observee». While the Hook-model denotes a collection of hooks, the Observeeis a system part which contains «Observable» el-ements, but is itself not directly observable. Thisstereotype can be used early in the developmentto annotate system parts that should be observed,and can be refined later to actual «Observable»s.Another stereotype of the integration profile is the«ObservationContext» which represents contextualinformation belonging to observable or observee.This information can (i) determine how the ob-servable behaves, generates data, and responds totriggering, and (ii) it can be part of the raw ob-servation data that is generated by the observable.All context information depends on the «Observa-tionScenario». Such a scenario is a usage settingand contains information about the enviroment theproduct is used in as well as the user who interactswith the product.

To further explain the relationship betweenhooks and observables, interaction patterns in theobservation domain are shown in Figure 4. Thenature of hooks, being either self-triggering, ex-ternally triggered, or both, suggests basically twointeraction patterns. The self triggering and theexternally triggered patterns are explained by usingthe aforementioned stereotypes of «Observable»and «Hook».

The first pattern is suitable for hooks which areself-triggered, that is, the observable system struc-ture autonomously triggers the respective hookobject whenever new information is perceived andshould be fed into the observation system. In thispattern the responsibility of taking action lies onthe observee’s side.

The second pattern deals with hooks that have tobe triggered externally to produce data. Here, thehook object has a link to the observable structure,e.g. in the form of a public operation, and cantrigger the observable. In the rare case that anobservable has both characteristics, a combinationof those patterns is also possible.

Hooks, as their proxy nature suggests, connect

Figure 4. Interaction patterns, note the communica-tion directions

observables to the respective interface in the ob-servation module, the «HookInterface» as shownin Figure 3. The observable element delivers rawdata to the interface, and inside the module thisinterface presents the data to the observation com-ponent. The component subsequently processes theraw data according to the specified observation be-havior. Obviously, the resulting data is determinedto a large extent by the observation system inputcoming from hooks, thus the strong connection tothe «HookData» stereotype (cf. Figure 3).

4.2. Observation architecture subprofile

The «HookInterface» is one of the main parts ofthe observation architecture profile shown in Fig-ure 5. The interface stereotype is a part of the «Ob-servationModule», namely being a sub stereotypeof «ObservationSubModule». Other sub modulesare concerned with the communication betweenobservation and repository layer (cf. Figure 1).

Figure 5. Architecture profile

Two submodules deal with runtime behavior of


978-1-4244-2265-4/08/$25.00 © 2008 IEEE Page 188


specified observation, the observation component.The «Configurator» receives an observation speci-fication and translates it into an executable «Ob-servationComponent» which is run by the «Sched-uler». The latter module is responsible for trigger-ing of hooks and the synchronization of concurrentevents.

Both the architecture and the integration profilesare shown here in an overview. Especially the archi-tecture profile contains more elements, that struc-ture the big building blocks depicted in Figure 5. Inthe next section, the usage of the observation profilewill be described in an example development flow.

5. Development flow

The development of an observation system is amodel-driven process which is mainly supportedby the observation profile as shown above. Theactual usage of the profile shall be explained inthe context of development. Figure 6 shows thebasic development flow for system parts in the ob-servation layer following the model-driven architec-ture [12] approach: a platform-independent modelis transformed into a platform-specific model, bothextended by observation-specific meta information.Then an additional weaving step integrates obser-vation facilities, also modeled in UML, into theplatform-specific system model. Although these ob-servation facilities could be modeled directly inthe system model, for later reuse, the modeling ofobservation in a separate model is advisable. Theresult of this step is a system model enriched withobservation facilities. This new model can directlybe used in the subsequent code generation step.

Additionally, a hook model is obtained from theenriched system model. A hook model describes thenature of all hooks present in the system whichcan be used in the specification of observation. It isnecessary for (i) documentation of the observationcapabilities of the system and (ii) for the laterspecification phase where it defines which hookscan potentially be used and which properties theymight have.

The flow depicted in Figure 6 starts with theapplication of the observation profile to systemmodels. Both platform-independent and platform-specific UML models can make use of this profileby application of the respective stereotypes. It isadvisable to integrate observation as early as possi-ble into the development, going from rather coarse-grained stereotypes like «Observee» to more fine-grained ones such as «Observable». Generally it

Figure 6. Observation integration modeling flow

should be possible to attach stereotypes to parts ofboth models as not all observation-related modelingis necessarily platform-specific, and vice versa.

In order to weave system model and observationmodel, first the observation facilities are retrievedfrom the observation model and are inserted intothe system model. This is a simple merging ofmodel elements on the package level. In a secondstep, all «Observable» stereotypes on parts of theextended system model are identified and checkedagainst the observation facilities. This second stepof the weaving algorithm works as a tree traversal,checking all model elements for applied observationstereotypes. In case an element has the stereotype«Observable» applied to it, it depends (i) on thenature of the element and (ii) on the interactionpattern (see section 4.1), what kind of connectionis introduced to the observation module (also seebelow). In any case, a corresponding «Hook» is in-troduced that encapsulates the different interactionbehaviors, data types and timing of observables.

The code generation step first creates structuralcode for all model elements and large parts ofthe observation module can already be generated.This applies especially, if an implementation of theobservation module exists already for the targetplatform. Moreover, a subset of the hooks mightbe realized in a platform-independent fashion, andthus can be reused. Otherwise, at least glue codefor hook implementations can be generated auto-matically from the extended system model. In thiscase the code generation step simply continues thework of the weaving algorithm on the code level:implementations are created for «Observable» and«Hook» as far as possible. Finally, the developerhas to review the glue code in the observables andadd a few instructions to make the observablesdeliver actual data.


978-1-4244-2265-4/08/$25.00 © 2008 IEEE Page 189


6. Conclusion & Future work

Companies experience a lack of reliable, product-specific usage information. We address the informa-tion deficit by building observation modules intoproducts that are capable of providing usage infor-mation directly from products in the field. A case-study shows the applicability of the approach. Ob-servation integration will potentially have a strongimpact on the development of future innovativeproducts, thus the need an engineering methodol-ogy. This paper introduces a model-driven tech-nique to integrate observation functionality intoproducts by means of a novel observation pro-file. System models are enriched with observation-specific concepts and a dedicated model of sup-portive observation facilities is weaved into thesystem model using the concepts as semantic links.The result is an extended system model that canbe used in a final code generation step and thatdocuments the observation capabilities of the sys-tem. The technique introduced here simplifies thedevelopment tasks necessary for observation inte-gration, thus reducing the effort for integration.It helps to automate the process of observationspecification and data collection. Furthermore, wesee observation integration not as a simple paralleldevelopment task only, but as a potential drivingforce behind a new development paradigm: designfor observation. This involves observation as a firstclass development aspect and helps to provide asolid basis for extensive, but meaningful productinformation presented to information stakeholdersin a comprehensive way.

Acknowledgments

This work is being carried out as part of the“Managing Soft-Reliability in Strongly InnovativeProduct Creation Processes” project, sponsored bythe Dutch Ministry of Economic Affairs under theIOP-IPCR program.

References

[1] E. den Ouden, L. Yuan, P. J. M. Sonnemans, andA. C. Brombacher, “Quality and reliability prob-lems from a consumer’s perspective: an increasingproblem overlooked by businesses?” Quality andReliability Engineering International, vol. 22, no. 7,pp. 821–838, 2006.

[2] M. Funk, P. H. A. van der Putten, andH. Corporaal, “UML profile for modeling systemobservation,” Eindhoven University of Technology,Tech. Rep. ESR-2008-09, 2008. [Online]. Available:http://www.es.ele.tue.nl/esreports/

[3] H. Hartson and J. Castillo, “Remote evaluation forpost-deployment usability improvement,” Proceed-ings of the working conference on Advanced visualinterfaces, pp. 22–29, 1998.

[4] D. M. Hilbert and D. F. Redmiles, “An approachto large-scale collection of application usage dataover the internet,” icse, vol. 00, p. 136, 1998.

[5] K. Kabitzsch and V. Vasyutynskyy, “Architec-ture and data model for monitoring of distributedautomation systems,” in 1st IFAC Symposiumon Telematics Applications In Automation andRobotics, Helsinki, 2004.

[6] E. Shifroni and B. Shanon, “Interactive user mod-eling: An integrative explicit-implicit approach,”User Modeling and User-Adapted Interaction,vol. 2, no. 4, pp. 331–365, Dec. 1992. [Online].Available: http://dx.doi.org/10.1007/BF01101109

[7] J. Estublier and G. Vega, “Reuse and variabilityin large software applications,” in ESEC/FSE-13:Proceedings of the 10th European software engi-neering conference held jointly with 13th ACM SIG-SOFT international symposium on Foundations ofsoftware engineering. New York, NY, USA: ACM,2005, pp. 316–325.

[8] Object Management Group, “Unified mod-eling language,” 2006. [Online]. Available:http://www.uml.org

[9] D. D’Souza, A. Sane, and A. Birchenough,“First-class extensibility for UML-profiles, stereo-types, patterns,” in UML’99 - The UnifiedModeling Language. Beyond the Standard.Second International Conference, Fort Collins,CO, USA, October 28-30. 1999, Proceedings,R. France and B. Rumpe, Eds., vol. 1723.Springer, 1999, pp. 265–277. [Online]. Available:citeseer.ist.psu.edu/dsouza99firstclass.html

[10] M. Funk, P. H. A. van der Putten, and H. Cor-poraal, “Specification for user modeling with self-observing systems,” in Proceedings of the First In-ternational Conference on Advances in Computer-Human Interaction, Saint Luce, Martinique, 2008.

[11] M. Funk, P. H. A. van der Putten, and H. Corpo-raal, “Model interpretation for executable obser-vation specifications,” in Proceedings of the 20thInternational Conference on Software Engineeringand Knowledge Engineering. Knowledge SystemsInstitute, 2008.

[12] D. Frankel, Model-Driven Architecture. New York,NY, USA: OMG Press / Wiley, 2003.


978-1-4244-2265-4/08/$25.00 © 2008 IEEE Page 190


Documents

UML profile for modeling product observation. - Pure