Presentation is loading. Please wait.

Presentation is loading. Please wait.

Day 2: Hands-on UML Using UML to put MITA to work to solve the immediate process improvement needs of states.

Similar presentations


Presentation on theme: "Day 2: Hands-on UML Using UML to put MITA to work to solve the immediate process improvement needs of states."— Presentation transcript:

1 Day 2: Hands-on UML Using UML to put MITA to work to solve the immediate process improvement needs of states

2 MITA UML Training – Day 2 Hands-on Training
8:30 – 10:00 Hands-on Exercises: Business Processes Set up model structure Simple business process (trigger, inputs, output, activities, decisions, business objects Activity diagrams for Provider Enrollment 10:15 – 12:00 Hands-on Exercises: System Integration Sequence Diagrams (options, alternatives) Capabilities as interface Service specifications for business and infrastructure processes 13:00 – 14:30 Artifact Generation and Tools Using the UML model to generate WSDL and XSDs: UML-to-WSDL configuration Using hyperModel for constrained Using MIF import to re-use HL7 models Integration with Subversion for version control 14:45 – 16:00 Hands-on: Using the HL7 and Fox tools MITA Project for MITA models Version control with Subversion HL7 information Model Change Control Fox Portal for project files

3 Tooling Overview IBM Rational Software Architect/Modeler
Websphere Business Modeler Free plugins compatible with Eclipse 3.2 hyperModel 3.0: HL7 MIF, HL7 UML Profile, Abstract Datatypes Version Control (SVN) HL7 Web-based Tools Wiki MITA Project on HL7 Homebase

4 Rational Software Modeler/Architect
Eclipse-based Uses the underlying EMF (Eclipse Modeling Framework)

5 Websphere Business Modeler
Integrated with RSA/RSM Eclipse based Open-source alternatives available

6 UML vs. BPMN , BPEL WSDL WSDL is the target representation of MITA-based messages and tools are widely available Business Process Automation is a relatively new and very appropriate for new development Eclipse based tools are available to add business process automation as needed: Eclipse and Eclipse Modeling Framework provides integration

7 BPMN  BPEL <sequence name="main"
xmlns:ns="http://eclipse.org/bpel/sample" xmlns:ns0="http://www.xmethods.net/sd/CATrafficService.wsdl"> <receive name="receiveInput" operation="initiate" partnerLink="client" portType="ns:Traffic2" variable="input"/> <assign name="Assign" validate="no"> <copy> <from part="payload" variable="input"> <query><![CDATA[/tns:input]]></query> </from> <to part="hwynums" variable="trafficRequest"/> </copy> </assign> <invoke inputVariable="trafficRequest" name="Invoke" operation="getTraffic" outputVariable="trafficResponse" partnerLink="traffic" portType="ns0:CATrafficPortType"/> <assign name="Assign1" validate="no"> <from part="return" variable="trafficResponse"/> <to part="return" variable="trafficResponse"/> <invoke inputVariable="output" name="callbackClient" operation="onResult" partnerLink="client" portType="ns:Traffic2Callback"/> </sequence> BPEL Visual Editor – available for Eclipse 3.3 tools

8 Eclipse Perspective Eclipse is a framework for IDEs (integrated development environments) In Eclipse, the layout of the user interface can be totally changed at the click of a button by changing “perspective” These layouts are called "perspectives" and they have various purposes.  RSM includes a “Modeling” perspective. To view the SVN repository you need the SVN perspective In order to open a perspective select WindowOpen Perspective  Other... and then select the perspective. In order to modify a perspective WindowShow View

9 Plugins and Features Add-on tools, open-source
Help  Software Updates  Find and Install  Search for new features New Remote Site…

10 Getting Started… File  New  Project File  New  UML Model
Right-click in any tool to open context-sensitive menu

11 … using the style guide RSA provides default projects
“Blank.emx” The MITA styleguide will provide a consistent structure for each project

12

13 Project Browser Model contents vs. Views Diagrams Packages
Activity Actions Diagram Structured Activities Select a package and right-click context-specific menu Add Delete

14 Model Elements Workspace Model Project (NewProject
Diagrams (by model) Models (separate .emx files) (New Model) Model Packages: name space for the various model elements (classes, interfaces, associations, actors) Diagrams Structure Behavior UML elements

15 Overview Reviewing the core modeling components Activity Diagrams
Class Diagrams (and Packages) Sequence Diagrams

16 Model-driven Approach
As requirements change, we change the UML model re-generate user documentation re-generated WSDL re-generated XSD Diagrams provide views on the model an element change is automatically reflected in all diagrams that use the element

17 Tooling Capabilities Modeling Managed in MITA Project Repository
Includes WSDL and XSD generation Managed in MITA Project Repository Configuration management portal Developers check in / check out Model artifacts Available to all as Read-Only with downloadable viewer Wiki for brainstorming, co-editing documentations, collaboration

18 Summary of Project Artifacts
Model Artifacts Business Process (Activity diagram) MITA “to be” Minnesota specific business rules Business Triggers, system boundaries Information Model (Class Diagram ) HL7-based, standardized vocabulary Interactions (Sequence Diagram) Operations expose business capabilities Modeling realization artifacts Service Specifications Ports, interfaces, business rules User documentation and runtime artifacts WSDL XSD

19 Style Guide Pre-defined structure Selected notation
Certain diagrams/views Default MITA structure and local extensions

20 RSA: Create a new project
Create new UML project File  New  Project  UML Project Re-use style guide or start from “blank”

21 Enroll Provider System
Logical Model Overview (using Classes and Packages) Enroll Provider Demo Enroll Provider System Enroll Provider Provider Registry Manage Provider Info Inquire Provider Info

22 Shared information

23 Shared information

24 Detailed Information Model: Healthcare Provider (Role)
Reuse reference HL7 class names, attributes, data types, code sets Reuse internal HL7 code sets, where appropriate Reuse standard coding systems (ICD, SNOMED, X12, NCPDP, etc.) as necessary Additional Medicaid codes may be submitted to Standard Development Organizations for adoption Benefit: Industry-standard code sets can be used in place of state-specific codes to enable semantic interoperability The HL7 Reference Information Model is extensive and includes a variety of contributions (industry, government, international) and it meets the needs of the Medicaid

25 Adding … Select package Add UML model element or a diagram
Context-sensitive dialog

26 Business Triggers (state changes)
Application extracted from business process analysis – service for provider enrollment. Pure activity diagram for provider enrollment application. Extracted from Provider Enrollment system swim lane in activity diagram for business analysis process. Three modules: New/Active, Valid, and Approved

27 Process description using activities
Action & Information Input Output Reference other process Control Edges – information and process control

28 RSA: Add a new diagram

29 Overview of business domains and areas

30 “Enroll Provider” Process
Input Data Trigger Result

31 Enroll Provider MITA Business Process Item Details Links Description
A brief description of the complete business process Location in the Model Trigger Event An occurrence that triggers a business process (e.g., receipt of a request, phone call, or a scheduled date) The Trigger is a defined data set. Sources of Trigger events Result One or more outcomes from the execution of the Business Logic (results are defined as data in motion and are the immediate output from the business process, not the ultimate, downstream result) The Result is a defined data set. Business processes affected by the Result Business Process Steps A sequence of steps that execute the successful completion of the business process (steps start with a verb) N/A Shared Data Shared data is data at rest (i.e., data stores accessed to complete a step in the business process) Shared data is a defined data set. List of data sources Predecessor The preceding business process, the Result of which becomes an input Trigger to this business process Other BP Successor The Results of this business process, which may become a Trigger for another business process Constraints Conditions that must be met for this generalized process to execute (e.g., enrolling institutional providers requires different information from enrolling pharmacies) External rules Failures An identification of the exit points throughout the business process where the Business Logic specifies that the process must terminate because of failure of one or more steps Failure Notifications Performance Measures Measures that describe what can be measured but that are not specific measures in themselves, such as the following: 1. Time to complete process (e.g. real-time response = within ___ seconds; batch response = within ___ days) 2. Accuracy of decisions = ___% 3. Consistency of decisions and disposition = ___% 4. Error rate = ___% or less The MITA template specifies the type of measure but not the actual measure. External source or performance measure rules Enroll Provider

32 RSA: Add “Description”
Diagram (empty)

33 Activity Diagram of Business Process
Trigger Event 1 Performance Measures Failures Constraints Successor Predecessor Shared Data Business Process Steps Result Trigger Event Description Links Details Item Tier 3: Enroll Provider PM Enroll Provider Control flow [condition] Failures 1 Decision Actions Reused Process Object flow [condition] Result

34 Shared Data Information Model HL7 as the starting point Input Messages
Class Diagrams provide a view of the shared data HL7 as the starting point Import MIF-based HL7 models into UML Modify Input Messages Output Messages

35 Class Diagram Provides a view of Information and structure of message content or service performed Class diagrams are grouped into packages that represent a type of message or a service. Class Message content (attributes) Interface Implemented by components/services Operations Enumeration Define value sets Coded literals A class is depicted on the class diagram as a rectangle with three horizontal sections, as shown in Figure 2. The upper section shows the class's name; the middle section contains the class's attributes; and the lower section contains the class's operations (or "methods").

36 Information Model - Message
“Entities” have “roles” and “roles” have “participation” in “Acts” or “Events”

37 Share Information: Healthcare Provider (Role)
Primitive type Default value Multiplicity HL7 Datatype Attribute/ Property of the this type of object Enumeration

38 Detailed Information Model: Healthcare Provider (Role) Class Object
Name Section Stereotype { Class Name { Attribute Name Information models only use top two of three parts of class. Name Section: Stereotype of class name comes from vocabulary domain. Class Name is concatenated string of meaningful words with uppercase for each word that describe the class object being modeled. Attribute Section: Attributes are in the second section of the diagram. Two parts to each attribute: name and datatype separated by a colong To left of colon goes the attribute name. Two stereotypes of attribute names – “attribute” and “element” Attributes start with lover case, names are concantenated and all remaining names in string are uppercase. To right of colon goes the data type – either basic UML notation or from data types domain. Note that data types have cardinality and multiplicity but can also be specified within the attribute after data type name. Data types from a data type class are capitalized. A value can be set for the datatype following an “=“ sign. Attribute Multiplicity Attribute Value Attribute Section Attribute Name

39 Cardinality and Multiplicity
Multiplicities Meaning 0..1 Basic notation - Zero or one instance. Note that “m” representing a maximum number of instance may replace 1 and “n” representing a minimum number of instances may replace zero. 0..*  or  * Optionality - No limit on the number of instances and if zero then no minimum either.. 1 Cardinality of exactly one instance 1..* Cardinality of at least one instance. Note that * may be replaced by “m” representing a maximum number of instances.

40 RSA: Add shared data Add diagrams Add classes Class diagram
Root class of input message Root class of the response

41 Activity Diagram – detailed notation

42 RSA: Create a simple activity
Create information model package Create activity diagram Triggers Drag-and-drop input message Draw control flow Draw object flow to object node If the object flow cannot be created, an input pin is missing

43 Object nodes Data store: data flow in which the data is persistent
Central buffer: consolidates data from several sources and destinations. They do not connect directly to actions Input/Output pins

44 Edges/Connectors Control flow Object flow
Process control passed from one action to the next Object flow information “in”/”out”

45 Actions Simple actions Fork/join process flows
Re-used activities/processes

46 Information Model The information model is used to describe message content and structure. Unlike a data model which is used to represent permanent information, the data model is used to represent a snapshot of information at an instance in time for sharing information. The structures in information models represent how a message is composed to share information – not how data is stored within or retrieved from data structures. The source of the data captured for a message may include several data structures and data stores. The use of the data included in a message is various and can include parsing the information into one or more data stores. Data is manipulated from data stores for inclusion in messages, reports, or displays. Data within data stores may be in any format required by the application. Data is extracted from one or more data stores for composition of a message according to the schema for that message and will require transformation unless the data stores are XML representations of the schema. Conversely data is stored into one or more data stores from the message according to the usage requirements for that data beyond messaging – e.g. repositories for reporting and querying, updates to data stores based upon use of information in messages, It is important to note that only the source data for a message can be an authoritative source because data cannot be validated or verified for accuracy, authenticity, or authority after it has been put into a message. Message validation only ensures that data uses valid structures with valid values

47 HL7 Data Types Re-usable
Allows us to avoid platform compatibility issues

48 Value Sets/Vocabulary

49 Validation of messages
HL7 Terminology Intended for Code Sets Validation of messages Allowed values

50 Use cases Use case diagram identifies the business actors
Use cases elaborated using other views Scenarios Basic Alternate Error

51 Use case diagram Elaborate using High-level use cases only
Interactions Activities Without narrative High-level use cases only Focus on automation and integration Integration-related use cases

52 Infrastructure Use case
Use Case Diagram Identifies the various ways in which a user interacts with a system or other users Actors, use cases, associations, inclusion Enroll Provider Information relies on Add Update Inquire System Actor Actor Business Use case Infrastructure Use case

53 Service Define interfaces Create package Create component
Create a class diagram Interface Operations based on use cases Create package Namespace for service Create component Add port of a certain type (interface)

54 Provider Registry Service
Interface Port System

55 System Interactions Based on the Service(s) defined
Base on scenarios/use cases Lifelines used to organize service calls Each lifeline is an instance of interface or service Each message corresponds to an operation invocation Ad-hoc messages are not maintainable over time

56 Sequence Diagram User role : Actor Type System : Business Process
Message/Request System : Business Process System : Service type Return Asynchronous Notification

57

58 RSA: Sequence diagram New sequence diagram
Provider initiates the enrollment process Add alternative Add optional invocation

59 Sequence Diagram A sequence diagram is an interaction diagram that details how operations are carried out -what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence. A sequence diagram has two dimensions: The vertical dimension shows the sequence of messages/calls in the time order that they occur; the horizontal dimension shows the object instances to which the messages are sent. A sequence diagram describes messages – each with a sender and receiver. In both cases the vertical lines represent the instances of the types indicated above them and the horizontal lines represent actions that involve the instances that they connect. Both dimensions can be expanded to refine the analysis and provide more detailed steps and a finer scale; each event can be expanded to more detailed sequences and each object to more detailed objects. A sequence diagram is almost explanatory; it shows the calls between the different objects in their sequence and can show, at a detailed level, different calls to different objects.

60 Use of Sequence Diagrams
Reading a sequence diagram is very simple. Start at the top left corner with the "driver" instance that starts the sequence. Then follow each message down the diagram. Remember: Even though the example shows a return message for each sent message, this is optional. Sequence charts for scenarios help to identify the different participants in the action and their interactions and to show the sequence of events. This helps with the conceptualization of the role of time and with understanding dependencies between instances. Sequence charts assist the designer in allocating instances among distributed system components and are often useful during testing. A sequence diagram is very simple to draw. Across the top of your diagram, identify the class instances (objects) by putting each class instance inside a box. In the box, put the class instance name and class name separated by a space/colon/space " : " (e.g., provider : Provider). The vertical “lifelines” are dashed lines to the bottom of the sequence. The activation bars are vertical oblong rectangles that begin when a message is received and end at some point in time after message is sent – depending on the processing activities associated with the class. If a class instance sends a message to another class instance, draw a line with an arrowhead pointing to the receiving class instance; place the name of the message/method above the line. Optionally, for important messages, you can draw a dotted line with an arrowhead pointing back to the originating class instance; label the return value above the dotted line. It is a good practice to include the return value lines because the extra details make the diagram easier to read.

61 Message Flow Conventions
Symbol Meaning Simple message which may be synchronous or asynchronous Simple message return (optional but recommended) A synchronous message An asynchronous message For the activity diagrams we are modeling we use simple messages if we don’t care about synchronization. This is usually the case for secondary messages. Synchronous message flow requires that the class object generating the message wait upon a response before doing anything else with message. Asynchronous messaging can be represented by any of the three arrow types shown in the table with synchronization. Asynchronous messaging means the class object originating the message does not need to wait on a response. We also use the simple message return in all cases where message is “outbound” after the original message is received from the application. We use synchronization for the original input from user and output back to user. The simple message return is not used with the end user because acknowledgements are sent back as synchronized messages to the end user..

62 Elements of Sequence Diagram
Driver Sequenced “life line” Self-directed Message Activation Bar This represents a possible, future reuse of the “Inquire Provider Information” process and corresponding service National Plan and Provider Enumeration System (NPPES) Message Return Message Name Sequenced classes with “life lines” instead of “swim lanes” because represents action over time as differentiated from order of activities.

63 Alternate view: Communication diagram

64 Communication Diagram
Entirely equivalent to the sequence diagram Provides another view, improves documentation With RSA, it is automatically created Create a sequence diagram Select “interaction”, add “communication diagram”

65 HL7 Concepts Reference Information Model Patterns
Act-Participation-Role-Entity Observation – Author – Nurse - Person Act-ActRelationship Prescription   Allergy Role-RoleLink PhysicianAssistant

66 HL7 Reference Information Model (RIM)

67 Model Management HL7 MITA Project Version Control with Subversion
Version Control with Subversion Model comparison SVN/SubversionPlugin Help  Software updates  Find and install

68 New Remote Site… HL7 import tool
HL7 import tool

69 WSDL and XSD generation
UML-to-WSDL Includes XSD generation Generate XSDs based on the content of a diagram Using hyperModel File  New  Transformation Source “services” package to the destination WSDL directory

70

71 WSDL

72 Change Control Process Overview

73 HL7 MITA Project: Repository
hl7projects.hl7.nscee.edu

74 Issue and change request tracker

75 Fox Portal


Download ppt "Day 2: Hands-on UML Using UML to put MITA to work to solve the immediate process improvement needs of states."

Similar presentations


Ads by Google