DOCSLIB.ORG

D2.9 – Report on the Welive Open Service Layer V1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

A neW concept of pubLic administration based on citizen co-created mobile urban services Grant Agreement: 645845 D2.9 – REPORT ON THE WELIVE OPEN SERVICE LAYER V1 DOC. REFERENCE: WeLive-WP2-D29-REP-160419-v10 RESPONSIBLE: FBK AUTHOR(S): ENG, TECNALIA, UDEUSTO, FBK, CNS, INF, DNET DATE OF ISSUE: 19/04/16 STATUS: FINAL DISSEMINATION LEVEL: CONFIDENTIAL VERSION DATE DESCRIPTION v0.1 06/11/2015 Definition of the Table of Contents and distribution of tasks 17/01/2016 Description of specifications of the Visual Composer, query mapper and v0.3 controller v0.7 21/01/2016 Description of Social Wrapper and Web Scraper v0.8 27/01/2016 Description of specification of WeLive Player Description of Logging BB 16/03/2016 Description of specification of AAC, WeLive player test, ethical issues and v0.9 version ready to be externally reviewed v0.10 31/03/2016 Reviewers´ comments processed v1.0 19/04/2016 Visual Composer tests completed and final version ready for submission D2.9 – Report on the WeLive Open Service Layer v1 page 1 INDEX 1. EXECUTIVE SUMMARY ............................................................................................................................................ 8 2. INTRODUCTION ....................................................................................................................................................... 9 3. OVERVIEW OF WELIVE OPEN SERVICE LAYER AND HIGH LEVEL ARCHITECTURE .................................................... 10 3.1. REQUIREMENTS ............................................................................................................................................. 10 3.2. ARCHITECTURE .............................................................................................................................................. 11 3.3. DEPLOYMENT ................................................................................................................................................ 13 4. OPEN SERVICE LAYER SPECIFICATIONS .................................................................................................................. 14 4.1. BB METAMODEL ............................................................................................................................................ 14 4.2. CORE PROFILE ................................................................................................................................................ 15 4.2.1. BUILDING BLOCKS ................................................................................................................................. 15 4.2.1.1. Artifact class ..................................................................................................................................................... 15 4.2.1.2. Building Block class ........................................................................................................................................... 16 4.2.1.3. Dataset class .................................................................................................................................................... 17 4.2.1.4. PublicServiceApplication class ........................................................................................................................... 17 4.2.2. BUILDING BLOCK ENTITIES ..................................................................................................................... 17 4.2.3. LEGAL CONDITIONS ............................................................................................................................... 18 4.2.4. INTERACTION PROFILE ........................................................................................................................... 18 4.2.4.1. Interaction Point class ...................................................................................................................................... 19 4.2.4.2. TechnicalConstraint class .................................................................................................................................. 20 4.3. SECURITY PROFILE ......................................................................................................................................... 20 4.3.1. COMMUNICATION MEASURES ............................................................................................................... 21 4.3.1.1. ProtocolConstraint class ................................................................................................................................... 21 4.3.1.2. OriginConstraint class ....................................................................................................................................... 22 4.3.2. AUTHENTICATION MEASURES ............................................................................................................... 22 4.3.2.1. IdentityProvider class ....................................................................................................................................... 23 4.3.3. AUTHORIZATION MEASURES ................................................................................................................. 23 4.3.3.1. Permission class ............................................................................................................................................... 24 5. CONTROLLER SPECIFICATIONS ............................................................................................................................... 25 5.1. REST API ........................................................................................................................................................ 25 5.2. CONTROLLER UI ............................................................................................................................................. 28 5.2.1. FUNCTIONAL ASPECTS OF THE CONTROLLER .......................................................................................... 28 5.2.2. DETAILED REQUIREMENTS AND USE CASE MODEL ................................................................................. 30 5.2.2.1. DETAILED REQUIREMENTS ................................................................................................................................ 30 5.2.2.2. USE CASE MODELS ............................................................................................................................................ 42 5.2.3. DYNAMIC MODEL AND INTEROPERABILITY DEMANDS ........................................................................... 44 5.2.3.1. FLOW CHART .................................................................................................................................................... 44 5.2.3.2. INTEROPERABILITY WITH OTHER WELIVE COMPONENTS ................................................................................... 45 5.2.4. TECHNOLOGY CHOICE REASONING AND USAGE DESCRIPTION FOR IMPLEMENTATION ........................... 47 5.2.5. ARCHITECTURE AND DEPLOYMENT DIAGRAM OF THE CONTROLLER ...................................................... 48 5.2.6. DOCUMENTATION AND USER MANUAL ................................................................................................. 49 5.2.6.1. Access .............................................................................................................................................................. 49 5.2.6.2. Language selection ........................................................................................................................................... 49 5.2.6.3. City selection .................................................................................................................................................... 49 5.2.6.4. Registering ....................................................................................................................................................... 50 5.2.6.5. Log in ............................................................................................................................................................... 50 5.2.6.6. WeLive tool selection ....................................................................................................................................... 51 5.2.6.7. Log out ............................................................................................................................................................. 52 5.2.6.8. WeLive support ................................................................................................................................................ 52 D2.9 – Report on the WeLive Open Service Layer v1 page 2 5.2.7. DATA PROTECTION RELATED REQUIREMENTS ........................................................................................ 52 5.2.8. FUNCTIONAL TESTS RESULTS OF THE CONTROLLER ................................................................................ 56 6. VISUAL COMPOSER SPECIFICATIONS ..................................................................................................................... 57 6.1. FUNCTIONAL ASPECTS OF THE VISUAL COMPOSER ......................................................................................... 57 6.2. DETAILED REQUIREMENTS AND USE CASE MODEL .......................................................................................... 58 6.2.1. DETAILED REQUIREMENTS....................................................................................................................
Recommended publications
  • Opensocial: from Social Networks to Social Ecosystem

    Opensocial: from Social Networks to Social Ecosystem

    2007 Inaugural IEEE International Conference on Digital Ecosystems and Technologies (IEEE DEST 2007) OpenSocial: From Social Networks to Social Ecosystem Juliana Mitchell-WongI, Ryszard Kowalczyk', Albena Rosheloval, Bruce Joy2 and Henry Tsai2 'Centre for Information Technology Research, Swinburne University, Hawthorn, VIC, Australia e-mail: (jmitchellwong, rkowalczyk, aroshelova)@ict.swin.edu.au 2Everyday Interactive Networks, Hawthorn, VIC, Australia, e-mail: (brucejoy, henrytsai)@ein.com.au ties to be managed using the one application. GAIM' and Abstract-Unlike the physical world where social ecosys- Trillian2 are two example applications for instant messaging tems are formed from the integrated and managed relation- communities. These applications however do not address ships between individuals and organisations, the online digital any of the fundamental issues: the independent and isolated world consists of many independent, isolated and incompatible nature of communities, the ignorance to overlapping rela- social networks established by organisations that have over- lapping and manually managed relationships. To bring the tionships in different communities, or the manual manage- online digital world in-line with the physical world, integration ment of relationships. of social networks, identification of overlapping relationships Communities on the other hand have moved towards in social networks, and automation of relationship manage- forming alliances with other communities to enable content ment in social networks are required. OpenSocial is a frame- search and retrieval between them by using common ontol- work that enables social networks to interlink and self- use common organise into a social ecosystem guided by the policies of indi- ogy [1]. The of ontology enables communities viduals and organisations. to interlink, but each of these communities assumes that their policies are agreeable by every community in the alli- Index Terms-social framework, self-organised, self- ance.
  • Android User Profile Layout Example

    Android User Profile Layout Example

    Android User Profile Layout Example Is Kelwin unloving when Rudd uprises angrily? Type-high and effuse Ari scheme his rustle decried unsaddles dogmatically. Provisory Jerrold praised genotypically. Mobile applications evolve with user's needs offering new functionality still. Portfolio App User Profile UIUX Design by Anjan Rhudra Paul Modern Mobile App. Free material Design Profile designs for android with source code. Developing a mobile app against user data facilitates the design thinking process. The design details is for an instance and its own android user profile layout example is their natural boundaries and colors. See more ideas about user profile profile interface design. Top 35 Free Mobile UI Kits for App Designers 2020 Colorlib. Built with Android Studio the template's notable features include these beautiful gallery and user profiles Users can comment like pickle and send. Finally the profile screen design should be oriented to the necessary audience remember the. Step 1 Add the mixpanel-android library probably a gradle dependency. 9 Top App Design Trends for 2021 99Designs. The user would be notified via Toast if the profile does matter exist. The layout 3 add event handling to handle user input was the profile 4 save the profile as. Designing complex UI using Android ConstraintLayout. Easy for edit high-quality design Build Dynamic Android Apps From and Learn Android User Interface Design Are these any requirements or. Android Material Design profile page to Overflow. In this collection we'll be showcasing creative examples of User Profile designs. Profile Screen UI Design Android Unique Andro Code. IPhone users are proven to okay more satisfied and peninsula in using their devices And sophisticated data translates into profits most find the mobile.
  • Mobile Application

    Mobile Application

    Mobile Application What makes a good mobile app, and how can I create my own? Mobile Application What makes a good mobile app, and how can I create my own? Mobile applications are quickly replacing websites as a common way that learning designers now reach their learners. Mobile apps benefit from the same opportunities provided by websites but also allow the Visuals in Learning Design 1 learning designer to utilize various smartphone capabilities that are not standard on desktop and laptop computers, such as location services, gyroscopes, cameras, facial recognition, augmented reality, and so forth. This means that learning designers can approach apps similar to how they approach websites, but also that apps may have many potential opportunities that are not available with websites alone. In terms of ARC, a mobile application's emphasis will vary greatly by its purpose, but at a basic level, apps may be thought of as being similar to websites in that their primary function is to appeal to the learner and to get them to stay on the app to learn. This means that apps should strive to be clear, sleek, and inviting and should also make it clear to the learner where they are and where they need to go to keep learning Visuals in Learning Design 2 For this project, you will create a visual mockup for an iOS/Android app of your choice for a smartphone or tablet. You are encouraged to use existing User Interface Design Kits (e.g., iOS Design Kit, Google Material Design, Bootstrap, jQuery UI Mobile, Publica) along with Adobe Illustrator to complete this project.
  • PDF Download Android User Interface Design

    PDF Download Android User Interface Design

    ANDROID USER INTERFACE DESIGN : IMPLEMENTING MATERIAL DESIGN FOR DEVELOPERS PDF, EPUB, EBOOK Ian Clifton | 448 pages | 10 Dec 2015 | Pearson Education (US) | 9780134191409 | English | Boston, United States Android User Interface Design : Implementing Material Design for Developers PDF Book Paging 3. Unlike typical ease-in-ease-out transitions, in Material Design, objects tend to start quickly and ease into their final position. The online book is very nice with meaningfulcontent. With Material Design, Google introduced its most radical visual changes ever, and made effective design even more essential. Head MD [T8G. Material utilises classic principles from print design to create clean, simple layouts that put your content front and center. Please try again. It is great. In this article 1. The first best-practice guide to superb Android smartphone and tablet app design. You can use the CardView widget to create cards with a default elevation. Communicate with wireless devices. It will bebetter if you read the book alone. See also : Material Design Principles. Ian's love of technology, art, and user experience has led him along a variety of paths. Adaptive vs. Autofill framework. Device management. Work fast with our official CLI. Additional Product Features Dewey Edition. Resources Free Wallpapers. When a chapter covers multiple apps, the individual apps are in their own subdirectories within the chapter directory. Multiple APK support. For elements entering and exiting the screen which should do so at peak velocity , check out the linear-out-slow-in and fast-out-linear-in interpolators respectively. Web-based content. Clifton , Trade Paperback Be the first to write a review.
  • Worleydigital@Gmail.Com 952 334 9130

    [email protected] 952 334 9130

    https://joshuaworley.com [email protected] 952 334 9130 Frontend Developer, Digital Designer, and Digital Producer with 6 years of professional experience in the US and APAC. For examples of my work please see my public portfolio: https://joshuaworley.com EXPERIENCE Worley Digital - Freelance Business Offering Frontend Development, Digital Design, and Digital Marketing Services Global DIGITAL DESIGNER, FRONTEND DEVELOPER, DIGITAL PRODUCER, CONSULTANT Apr 2020 - Present • Client: Celebideo (Dec 2020 - Present) Cameo-like Startup in Japan o App & Prototype Design (Figma), Frontend Development (React Native) • Client: Mila Clarity (Nov 2020 – Dec 2020) https://milaclarity.com/ o Shopify updates (Liquid, JavaScript), Web Design (Figma) • Client: Namonai (August 2020 – Present) https://namonai.jp o Brand, Website, App Design, Frontend Development (JavaScript, nanohtml) o Case Study: https://joshuaworley.com/projects/namonai • Client: Telcoin (October 2020 - Present) https://telco.in o Website Updates (HTML, CSS, JavaScript), v3 Cryptocurrency Wallet and Remittance App Design (Figma) • Client: SnapHabit o Brand, UXUI Design (Figma) o Case Study: https://joshuaworley.com/projects/snaphabit • Client: A Lighthouse Called Kanata (May 2020 – July 2020) https://lighthouse-kanata.com o Rebranding, Site Migration, Webapp Expansion (CoffeeScript, Jade), SEO • Client: Sedona (April 2020) https://sedo.na o Website Design (Sketch) Frontend Coding (React.js) o Case Study: https://joshuaworley.com/projects/sedona Ptmind, Inc. - Tokyo/Beijing-based B2B Data Analytics Software Startup Shibuya, Tokyo FRONTEND DEVELOPER, UXUI DESIGNER, GROWTH MANAGER Apr 2019 – Apr 2020 • Project: Designed and developed the Ptengine flagship product’s SPA webapp renewal (Vue.js, Nuxt.js, Wordpress CMS) https://ptengine.jp • Created all design and marketing materials for the Japanese office, including a branded design assets library, illustrations, wireframes, user flows, personas, blog images, flyers, web components, web portals, splash pages, digital invitations, and business cards.
  • Hybrid Mobile Application for Project Planning System

    Hybrid Mobile Application for Project Planning System

    Master Thesis Czech Technical University in Prague Faculty of Electrical Engineering F3 Department of Computers Hybrid mobile application for project planning system Bc. Jan Teplý Supervisor: Mgr. Miroslav Blaško May 2017 ii Acknowledgements Declaration I would like to thank Mgr. Miroslav I declare that this work is all my own work Blaško and Ing. Jindřich Hašek for guid- and I have cited all sources I have used in ance in work on this thesis. And finally the bibliography. I would like to thank the CTU in Prague Prague, May 25, 2017 for being a very good alma mater. Prohlašuji, že jsem předloženou práci vypracoval samostatně, a že jsem uvedl veškerou použitou literaturu. V Praze, 25. května 2017 ..................................................... Bc. Jan Teplý iii Abstract Abstrakt Plantac is the proprietary web application Plantac je proprietární webová aplikace for project time and cost planning. Cur- pro plánování času a nákladů projektů na rently written on Java EE framework with platformě Java EE a grafickým uživatel- ZK framework for graphical user interface. ským rozhraním v frameworku ZK. Cí- The goal of this thesis is to explore the lem práce je prozkoumat možnosti pro vy- possibility of the creation of alternative tvoření alternativního multiplatformního multi-platform user interface, that enables uživatelského rozhraní, které zpřístupní chosen functions of Plantac on mobile de- vybrané funkce systému Plantac na mobil- vices even without internet connection. ních zařízeních i bez přístupu k internetu. Keywords: web, mobile, hybrid, offline, Klíčová slova: web, mobil, hybridní, Angular, Progressive apps, Cordova offline, Angular, Progressive apps, Cordova Supervisor: Mgr. Miroslav Blaško Překlad názvu: Hybridní mobilní aplikace pro systém plánování projektů iv Contents 1 Introduction 1 4.2.9 Development .
  • Designing English Listening Materials Through Youtube Video Editing Indonesian Journal of English Language Teaching and Applied Linguistics Vol

    Designing English Listening Materials Through Youtube Video Editing Indonesian Journal of English Language Teaching and Applied Linguistics Vol

    Designing English Listening Materials through YouTube Video Editing Indonesian Journal of English Language Teaching and Applied Linguistics Vol. 4(2), 2020 www.ijeltal.org e-ISSN: 2527-8746; p-ISSN: 2527-6492 Designing English Listening Materials through YouTube Video Editing: Training for English Teachers of Islamic Junior High Schools, Parepare, South Sulawesi Zulfah Fakhruddin IAIN Parepare, Indonesia e-mail: [email protected] Usman IAIN Parepare, Indonesia e-mail:[email protected] Rahmawati IAIN Parepare, Indonesia e-mail: [email protected] Sulvinajayanti IAIN Parepare, Indonesia e-mail: [email protected] Abstract: This study was conducted to help English teachers in designing English listening materials in form of audio and textbook through YouTube video editing. 18 English teachers of 10 Islamic junior high schools in Parepare were trained to write English listening materials in form of textbook and to edit video (download ,import, cut, merge, and export video) in form of audio.150 students were observed and tested to evaluate teachers’ products. Training materials consist of: (1) searching and download video through YouTube, (2) editing video that includes import, cut, merge, and export video, and (3) writing worksheet that contains phoneme discrimination dan listening comprehension exercise in form of multiple choice,true false,and completion. Training activities include: (1) explanation, (2) practice, (3) grouping, (4) assignment/design, and (5) evaluation and revision. After following training, teachers’ ability was categorized into good and fair in designing English listening materials. More than 50% Indonesian Journal of English Language Teaching and Applied Linguistics, 4(2), 2020 275 Zulfah Fakhruddin, Usman, Rahmawati, Sulvinajayanti teachers were categorized into good in editing video and 72% teachers were categorized into good in writing listening exercise.
  • Ray Cromwell

    Ray Cromwell

    Building Applications with Google APIs Ray Cromwell Monday, June 1, 2009 “There’s an API for that” • code.google.com shows 60+ APIs • full spectrum (client, server, mobile, cloud) • application oriented (android, opensocial) • Does Google have a Platform? Monday, June 1, 2009 Application Ecosystem Client REST/JSON, GWT, Server ProtocolBuffers Earth PHP Java O3D App Services Media Docs Python Ruby Utility Blogger Spreadsheets Maps/Geo JPA/JDO/Other Translate Base Datastore GViz Social MySQL Search OpenSocial Auth FriendConnect $$$ ... GData Contacts AdSense Checkout Monday, June 1, 2009 Timefire • Store and Index large # of time series data • Scalable Charting Engine • Social Collaboration • Story Telling + Video/Audio sync • Like “Google Maps” but for “Time” Monday, June 1, 2009 Android Version 98% Shared Code with Web version Monday, June 1, 2009 Android • Full API stack • Tight integration with WebKit browser • Local database, 2D and 3D APIs • External XML UI/Layout system • Makes separating presentation from logic easier, benefits code sharing Monday, June 1, 2009 How was this done? • Google Web Toolkit is the Foundation • Target GWT JRE as LCD • Use Guice Dependency Injection for platform-specific APIs • Leverage GWT 1.6 event system Monday, June 1, 2009 Example App Code Device/Service JRE interfaces Guice Android Browser Impl Impl Android GWT Specific Specific Monday, June 1, 2009 Shared Widget Events interface HasClickHandler interface HasClickHandler addClickHandler(injectedHandler) addClickHandler(injectedHandler) Gin binds GwtHandlerImpl
  • Emergency Management in Social Media Generation

    Emergency Management in Social Media Generation

    EMERGENCY MANAGEMENT IN SOCIAL MEDIA GENERATION Deliverable 5.1 Identification of Social Network Providers and API Design Final Thomas Ludwig1, Christian Reuter1 University of Siegen1 September 2014 Work Package 5 Project Coordinator Prof. Dr.‐Ing. Rainer Koch (University of Paderborn) 7th Framework Programme for Research and Technological Development COOPERATION SEC‐2013.6.1‐1: The impact of social media in emergencies D5.1: Identification of Social Network Providers and API Design, Version V1, PU Distribution level Public (PU) Due date 30/09/2014 (M6) Sent to coordinator 30/09/2014 No. of document D5.1 Title Identification of Social Network Providers and API Design Status & Version Final Work Package 5: Information Collection and Presentation Related Deliverables D3.3, D4.1, D5.2, D5.4 Leading Partner University of Siegen Leading Authors Thomas Ludwig, University of Siegen Christian Reuter, University of Siegen Contributors Marc‐André Kaufhold, University of Siegen Federico Sangiorgio, IES (section 5.3) Federica Toscano, IES (section 5.3) Massimo Cristaldi, IES (section 5.3) Mark Tolley, OCC (section 5.4 and 5.5) Mel Mason, OCC (section 5.4 and 5.5) Reviewers Matthias Moi, University of Paderborn Keywords Social Network Provider, API, Open Social, Activity Streams, Facebook, Twitter, Google+, YouTube, Tumblr, Instagram This project has received funding from the European Union’s Seventh Framework Programme for research, technological development and demonstration under grant agreement no 608352. I D5.1: Identification of Social Network
  • Building the Polargrid Portal Using Web 2.0 and Opensocial

    Building the Polargrid Portal Using Web 2.0 and Opensocial

    Building the PolarGrid Portal Using Web 2.0 and OpenSocial Zhenhua Guo, Raminderjeet Singh, Marlon Pierce Community Grids Laboratory, Pervasive Technology Institute Indiana University, Bloomington 2719 East 10th Street, Bloomington, Indiana 47408 {zhguo, ramifnu, marpierc}@indiana.edu ABSTRACT service gateway are still useful, it is time to revisit some of the Science requires collaboration. In this paper, we investigate the software and standards used to actually build gateways. Two feasibility of coupling current social networking techniques to important candidates are the Google Gadget component model science gateways to provide a scientific collaboration model. We and the REST service development style for building gateways. are particularly interested in the integration of local and third Gadgets are attractive for three reasons. First, they are much party services, since we believe the latter provide more long-term easier to write than portlets and are to some degree framework- sustainability than gateway-provided service instances alone. Our agnostic. Second, they can be integrated into both iGoogle prototype use case for this study is the PolarGrid portal, in which (Google’s Start Page portal) and user-developed containers. we combine typical science portal functionality with widely used Finally, gadgets are actually a subset of the OpenSocial collaboration tools. Our goal is to determine the feasibility of specification [5], which enables developers to provide social rapidly developing a collaborative science gateway that networking capabilities. Standardization is useful but more incorporates third-party collaborative services with more typical importantly one can plug directly into pre-existing social networks science gateway capabilities. We specifically investigate Google with millions of users without trying to establish a new network Gadget, OpenSocial, and related standards.
  • An Analysis of Social Network Connect Services∗

    An Analysis of Social Network Connect Services∗

    AN ANALYSIS OF SOCIAL NETWORK CONNECT SERVICES∗ Antonio Tapiador1,V´ıctor Sanchez´ 1 and Joaqu´ın Salvachua´ 1 1Universidad Politecnica´ de Madrid, Av. Complutense 30, Madrid, Spain fatapiador, vsanchez, [email protected] Keywords: Social Networks; API; OAuth; REST: mashups Abstract: Social network platforms are increasingly becoming identity providers and a media for showing multiple types of activity from third-party web sites. In this article, we analyze the services provided by seven of the most popular social network platforms. Results show OAuth emerging as the authentication and authorization protocol, giving support to three types of APIs, client-side or Javascript, server-side or representational state transfer (REST) and streaming. JSON is the most popular format, but there a considerable variety of resource types and a lack of representation standard, which makes harder for the third-party developer integrating with several services. 1 INTRODUCTION for instance: finding friends in the platform. On the other hand, this is also interesting for the provider that Popular social network platforms are leveraging iden- is now showing new kinds of activity in the streams. tity services. They provide authentication commodi- An attempt to provide a unified connect service ties, relieving third-party websites, applications and was made by OpenSocial (Hasel,¨ 2011), a standard services from managing user data. They are also an promoted by Google, Myspace and others, which has increasingly important media. Using already exis- been adopted to some extend. tent identity providers can improve the engagement In this article, we provide an in deep analysis of of users in those third-party sites.
  • Personal & Contextual Portability and Plasticity with Opensocial

    Personal & Contextual Portability and Plasticity with Opensocial

    Widgets and Spaces: Personal & Contextual Portability and Plasticity with OpenSocial THÈSE NO 5804 (2013) PRÉSENTÉE LE 30 AOUT 2013 À LA FACULTÉ DES SCIENCES ET TECHNIQUES DE L'INGÉNIEUR INSTITUT DE GÉNIE ÉLECTRIQUE ET ÉLECTRONIQUE PROGRAMME DOCTORAL EN INFORMATIQUE, COMMUNICATIONS ET INFORMATION ÉCOLE POLYTECHNIQUE FÉDÉRALE DE LAUSANNE POUR L'OBTENTION DU GRADE DE DOCTEUR ÈS SCIENCES PAR Evgeny BOGDANOV acceptée sur proposition du jury: Dr A. Karimi, président du jury Dr D. Gillet, Dr C. Salzmann, directeurs de thèse Dr E. L.-C. Law, rapporteur Dr L. Moccozet, rapporteur Dr C. Ullrich, rapporteur Suisse 2013 A person who never made a mistake never tried anything new — Albert Einstein To my parents. Acknowledgments This thesis is only partially my work. It would not be possible without my friends, relatives, colleagues who were helping me (knowingly or unknowingly) during this PhD journey. I am hugely grateful to all of you! Denis Gillet and Christophe Salzmann. Thank you for accepting me into your research family, for giving me the freedom in choosing and shaping the research directions according to my interests, for being my mentors. After our discussions I was always leaving your office inspired and highly motivated. This is indeed something! I would like to thank my thesis committee members for reading my thesis and being my examinators: Alireza Karimi, Effie Lai-Chong Law, Carsten Ullrich, Laurent Moccozet. My research work was partially funded through the following projects: ROLE, PALETTE, SWITCH, GO-LAB. I am thankful to these projects and I did appreciate working in them. Stéphane Sire, I owe you a huge chunk of my thesis and my personal development.