Com S/Geron 415X Gerontechnology in Smart Home Environments Implementation. Dr. Hen-I Yang Computer Science Department, ISU

Transcription

1 Com S/Geron 415X Gerontechnology in Smart Home Environments Implementation Dr. Hen-I Yang Computer Science Department, ISU April 5 and 7, 2011

2 Announcement Suggested progress for the week Integrate with the concepts from the design team and post the design concepts on the project website Prepare for the next (and last) UI Design critique session on Apr 14 Identify and design services for your systems Assigned Reading for the week: Protect Human Research Participants [pdf file, posted on WebCT] Posting of the Answer Key to the Cancelled Homework Homework 5 Due April 19 IRB Certification User Study Design

3 Term Project

4 Project Timeline Important Dates: UI and Design Concept Critique Session April 14 Final Demo and Poster: April 28 in class Final Report: May 1 by midnight Victory Lap: at least one representative from each group

5 Final Project Deliverables Functional Prototype (through demo and documented source code submitted through SVN) Final Presentation and Demo (30 minutes/group jointly with design team, April 28) Poster Victory Lap with Design Review (Date TBD) Final Report User s Manual (for end user) Step-by-step guide on how to use your application for not-verytech-savvy older population Step-by-step guide on how to install your application (if it requires installation) FAQ (if necessary) Everything related to the project is due midnight on May 1 via (hiyang@iastate.edu)

6 Final Report Project Name and Group Members Problem Statement [G] Storyboard [G] System Requirements C-requirements (Use Cases) [G] D-requirements (Workflows, a list of services and their design, sequence diagram) [C] A description of the system architecture [C]

7 Final Report (cont.) Test Cases [G] IRB application (User Study Design) [G] Self-evaluation of your project Strength and weakness of your project/application Changes to your project since the beginning of the semester What would you have done if you have 3 more months? What do you think your grade should be for this project? Conclusion Use improved version of materials you created for the proposal and midterm report as much as possible Document any contact with users or caregivers during project concept formation and throughout the process

8 Individual Notes in the Final Report Self Evaluation List your contributions to the project. What have you learned through this project? (in terms of C, G and design team, such as interdisciplinary teamwork) What was the biggest challenge for you? Did you, and if you did, how did you overcome the obstacle? Interdisciplinary Collaboration What are the contributions of the design team? How do you rate their contribution to the project (letter grade)? Were there any disagreement and how did you sort it out? What have you learned about working with non-computer scientists? Introspection What would you do differently if you get a chance to do this project all over again? In your opinion, what was percentage of contribution that each group mate of yours (including you) bring towards the completion of the project? Submit through WebCT individually

9 Objectives Wrap up the discussion on Service Engineering Learn what is Sequence Diagram Learn what is Software testing, and specifically, testing in SOA environment

10 Million Dollar Questions What, exactly, is this system supposed to do and in what order is it supposed to do it? What are all the things that can go wrong with the system, and how is the system supposed to behave when this happen? How can I create and record a set of testing scenarios in which I can put this system through its paces? How will I know when I ve tested system completely and thoroughly? Is there anything else this system is supposed to do, or not to do, that I need to know about? Managing Software Requirements A Use Case Approach, 2 nd ed, Leffingwell & Widrig

11 Service-Oriented Software Engineering

12 Why Do We Use Service-Oriented Architecture in Smart Homes? Easier Integration with existing and legacy systems Flexibility (Dynamicity and Transient) Reuse (Shorter Development Time, Less Repetitive Code and Higher Quality) Easier resource sharing Conceptually easier for construction The Alternative

13 Two Steps Software Developments Using Services Service Engineering The textbook focuses web services, but most of the steps are equally applicable to other SOA, including OSGi bundles

14 Software Development Using Services

15 Service Construction by Composition Formulate outline workflow Discover Services Select Services Refine workflow Create workflow program Test Service Workflow design Service list Service Spec Workflow design Executable workflow Deployable service Figure in Sommerville Book

16 Six key stages of service composition Formulate outline workflow Use the requirement to create ideal, abstract service design Discover services Search service registries to find suitable services and their details Select possible services Select a group of suitable services based on functionalities, cost and quality of services (so comparisons can be made) Refine workflow Modify workflow based on the chosen, available services and annotate with more details Create workflow program Transform the abstract workflow design to executable programs Test completed service or application Testing the completed composite service

17 Service Engineering

18 Service Engineering The process of developing services for reuse in SOA Goal Service represents a reusable abstraction that can be useful in different systems Service provides useful functionality associated with that abstraction Service must be robust and reliable With enough documentation that it can be discovered by and understood by potential users

19 Service Engineering Process Service candidate identification Identify possible services and define requirements Service design Design the logical and programmed service interfaces Service implementation and deployment Implement and test the service and make it available Service candidate identification Service design Service implementation and deployment Service requirements Service interface specification Figure 31.7 in Sommerville Book Validated and deployed service

20 Services Service must be useful in supporting business process Types of Services Utility services: provide general functionality used by many business processes Business services: associated with a specific business function Coordination or process services: support a more general business process involving different actors and activities Service Classification Entity-oriented: more like class/object-oriented approach Task-oriented: a service designed to complete some tasks or activities

21 Service Requirements Some helpful questions for service identification & requirements include: For an entity-oriented service, is the service associated with a single logical entity used in the business process? What are its operations? For a task-oriented service, is the task carried out by different people? Will they accept changes due to standardization (among different user)? Is the service independent? For its operation, does the service have to maintain state? Where should the service keep the state information? Could the service be used by clients outside of the organization? Are different users of the service likely to have different nonfunctional requirements?

22 Service Interface Design 3 Stages Logical interface design Identify the operations associated with the service, the inputs and outputs of these operations and the associated exceptions Message design Design the structure of the messages send or received by the service Service interface specification Translate your logical interfaces and messages into an abstract interface description

23 Operation Inputs Outputs Exceptions MakeCatalogue Compare Lookup Search CheckDelivery PlaceOrder Company id PDF-flag Company id Entry attribute Catalogue number Company id Catalogue number Company id Search string Company id Catalogue number Number of items required Company id Catalogue number Number of items required URL of the catalogue URL of page to comparison table URL of page with item information URL of page of search results Catalogue number Expected delivery date Catalogue number Number of items required Predicted delivery data Unit Price Total Price Figure in Sommerville Book Invalid company id Invalid company id Invalid catalogue # Unknown attribute Invalid company id Invalid catalogue # Invalid company id Badly-formed search string Invalid company id Invalid catalogue # Zero items requested No availability Invalid company id Invalid catalogue # Zero items requested

24 From Workflows to Services Do not design a service across the different blocks representing different systems or users For each block, identify logical software components (e.g. entity or task) that provide simple, related and self-contained evocable functionalities TIPS Remember the three basic components of any service? We will focus on the metadata first Define the details of each functionality by specifying the service interface, including the name of the operation, the input parameters, the outputs and the exceptions TIPS Here we focus on the second component: interface TIPS Message exchanges are great indicators of the needs for interfaces, although as you breakdown blocks into services, additional interfaces may be needed for intra-block, inter-service communications

25 From Workflows to Services (con t) Further define the details of each interface, for instance, what are the acceptable values for parameters (e.g. range of integers or floating points, dates in the past or future, allowable length of the Strings) If multiple workflows for different use cases/aspects have been created, go through each workflow to see if there is a need to merge or update existing interfaces, or create new services instead EXPECTED OUTCOME: A list of services with the metadata and detailed interfaces (including input parameters, outputs and exceptions, along with their restrictions)

26 Legacy/Existing System Legacy/Existing systems Hardware devices The concept of Blackbox The concept of Wrapper/Adapter Instead of reinventing the wheel, we put a wrapper with a general interface to the system A wrapper converts the interface of a class into another interface clients expect. Wrappers let classes work together that couldn't otherwise because of incompatible interfaces Does not necessary mean represented as a single service The services should be coherent and support a single are of functionality Design Patterns, Elements of Reusable Object-Oriented Software

27 In-class Activity: Service Design Work through the step-by-step guide of from workflow to services to define the services for your project Decompose your system workflow into independent services Describe the metadata for each of your service Describe the interface for each of your service Fill out the details (input, output, and exception) for each of your service EXPECTED OUTCOME A list of services with the metadata and detailed interfaces (including input parameters, outputs and exceptions, along with their restrictions)

28 Service Engineering

29 Sequence Diagram Graphical representations of control flow Visualize the execution of use cases Think in terms of service Name of the object/service Execution of a function in an object Lifecycle of an object Actions/messages Covert your workflow diagram into sequence diagram between services, and actors

30 Sequence Diagram Courtesy of: Jacob Wittenauer & Simanta Mitra