Just so I don't forget it in the future. In order to get the wsconnector working in the test environment you need the following in your class path:
Labels:
curam
0
comments
A few of my colleagues at work have been twittering about doing something post Web 2.0. So it kind of got me thinking what would be next (aside from the obvious Web 3.0 + Semantic Web). Then I remembered about the talk of the long tail.
My guess is the Web 3.0 + Semantic web stuff as time passes would end up in the left part where the dominating market is. In that domain, you would also have all the social networking, on-line applications, tagging and other on-line applications. These used to be in the long tail, but has rapidly been shifting to be the dominant market.
So what goes on the long tail now? One may think that the traditional off-line tools and products are going to the long tail, but that's not necessarily the case. It is true that they are losing the market share, but they are still pretty dominant.
So what does that leave us? Do we just give up and go fishing, go on a cruise, or go flying off for a vacation? Well if we do chances are we'd be disconnected from the world (especially when some of those places do not have cell phone or Wi-Fi).
It is nice to be disconnected once in a while to recollect your thoughts, but it would also be nice to share those thoughts back to the world once we come back from our hiatus.
That's what I think the new long tail would be.
In our world today there are many applications out there on the web that help us connect with others or share our knowledge. However, they all require us to be connected which is not guaranteed.
Some common business scenarios are:
All of those scenarios require someone to capture or process information but not have any access to the Internet or even cell phone towers.
This problem is nothing new as there have been much work on these already. Here are some examples of what is out there and my comments about them.
| Technology | Comments |
| Lotus Notes/Domino | This is the product that leads the pack in terms of adoption within many businesses. However, it is ridiculously heavy on resources (especially on version 8). It is also forgetting its roots and requiring more connectivity (it spits out many dialogs and messages when you don't have connection to the servers). |
| Google Gears | This is gaining traction now as a de-facto implementation for partially on-line applications. However, it requires a lot of re-work and the off-line application does not work the same way as an on-line application. It is also not based on any standards unlike... |
| HTML5 | This is the standard way of storing database data within the browser. However, WebKit is the only popular toolkit that uses this so far. Also it has the same problem as Google Gears where the off-line application is different from the on-line application. |
| GIT | One of the most popular decentralized version control systems out there. Unfortunately, it is only dealing with files. Not necessarily an application. However, using this as the basis of application data storage could be the future. |
| Synchronization Technologies | There are many out there but the concept is to synchronize the data between various devices. But these are just data not applications. |
As I specified above there have been some work already. However, for each of them I had comments on because they can still be improved.
Ideally what I'd like to see are:
The data store would have the following properties.
Deployment would have the following properties.
My ideas above will provide disconnected support for the application and the data. However, if we look further down the long tail again, we see one other use case that I have bypassed so far. The feature with the dominant market and with the solutions I have outlined above has one slightly nasty limitation. A single point of failure known as the server.
So what do we do about it?
Well I am thinking that we would take GIT's approach of creating a "web of trust" so we only get data from people that we trust. The difference would be with GIT it is just code. What if we pushed it so it has data and the application?
Then we'd have a social network based on local trusts rather than something that is run on a server (which can be hacked or sold off).
It is not that much further off from what I have written above. The main difference would be the deployment, which instead of a URL would use some sort of secure certificate.
Unfortunately, the intellect needed to use these applications are not a majority in this current generation of people. We have not hit a bubble where facebook, friendster, twitter, google or linkedin all get hacked and their databases are broadcast out to the Internet or sold to the highest bidder. Though that would just take time especially with quantum computing and faster processors coming out trying to break existing public key encryption standards.
The long tail provides us with primarily untapped markets. It saves us from having to compete against the big guys and get away with less risk.
Also your ideas to capture these long tail markets would not have to be as innovative because all you are trying to do is satisfy the need, rather than blowing off the competition.
Anyway hopefully this gives you readers ideas on what to do, I am too lazy to actually build these things but I would really like them to exist. :)
Labels:
idea,
web-design
0
comments
These are the things I would like to get from the Business Analyst specifications. I wrote this up for a friend of mine who was a BA and asking me about it. So from the point of view of a dev guy who has done app maintenance, DBA work, testing and performance analysis here are my view points.
The goals are to make sure there is enough detail for:
One thing you should know is business analyst specifications unlike requirements are living documents like source code. Although they should not change too much. The items here are not necessarily Curam specific, but it links to some of the Curam specific requirement gathering documents.
A starting point document would document what someone would need if they want to know what is going on with the project.
It should have the following:
Specific Objectives or goals for the user. The key things are that they are specific and for the user (or the user's client) such as "get a job for the person" or "gather all the information needed for the mainframe rules processing."
A Glossary of Terms so everyone speaks the same language. Every industry has their own lingo, so having that there reduces the confusion.
A References section which lists business documents such as the ones described here or requirements and where to find them.
The Business Analyst Document Template specifications. This would guide people how to read your documents. It would list your document types, their purpose and audience. (Fortunately I kind of written what the types are for you in this blog entry).
Ideally a BA document has the following:
The starting point document already says what the document types are and their purpose, so don't repeat yourself.
End-to-end scenarios should be the basis of any BA specifications. They should be written up as graphical work flow representations with little detail (the little detail is important because if you put in too much detail on this level it will take too much time make make things harder to change).
They are taken from the goals in the Starting point document.
It should talk about how a person would manually do things. Knowing how things are done manually makes it easier to communicate with the stakeholders (users or client) as they must know how things normally work in case the system breaks down.
It should have the following sections
For the stakeholders a visual representation makes it easier for them to understand what is going on.
For the testers the flow gives them an idea how to do their functional testing.
For the developers if they have a workflow engine, they can utilize the workflow engine to do their work or they can implement but have their unit test planned out as well.
For the business analysts they help define the screen flow and the domain specifications.
The domain specifications is where it gets really interesting. I put it before screen flows because this is usually what is missing in most of my Curam projects. However, it is not really much of a problem outside of Curam projects I find though. However, this can be done in parallel with the screen specifications.
When dealing with domain specifications it is best to think what you as a BA are more used to communicating in. I prefer a more object oriented fashion rather than a database oriented fashion because it lets me avoid getting into lower level details which should be done by the developers or the DBA.
For example, I would talk about a Case as a single object that can contain other objects such as Case Members which has a reference to a Person. A Person is a Participant which has a name. And I could go on.
The advantage of dealing with it in an OO fashion allows me to deal with a collection of objects as one object graph.
Although when I write these, I don't expect the BA version to be the final copy. I would expect the developers to give me a cleaned up version of their UML diagram when they finish from their tool (though it should look relatively the same).
The way this is written would be one document per object graph and a high level object graph diagram.
The high level object graph diagram shows how each object graph would link to each other.
Each object graph document would show:
The BAs specifications do not show the following because they are too low level
For the stakeholders the UML representation allows them to see how things are aggregated together. You can explain to them that each box is like a folder which can contain other folders or papers.
For the testers, knowing the domain model allows them to perform data checks directly on the database without the UI.
For the developers it allows them to write a UML class diagram that can be shared with the BAs for review.
For the DBA it allows them to write a logical and physical data model more easily.
For the business analysts they help define what the data you are dealing with and what operations can be performed.
The end-to-end scenarios would provide the detail on what screens should be available. These documents generally come up to look like a site map. It is best to work with a UI person on this one. These would define the following:
For the testers the flow gives them an idea how to do their functional testing in terms of screen flow.
For the developers the screen flow helps them figure out how to link pages together.
For the business analysts they help define what screens they would need.
The template screen specifications talk about the global look and feel of a screen for the application. You may end up with more than one template depending on the complexity of your application, but you should have at least the following:
These should be done with a UI person who would create the layout in HTML for you.
There are two components to the individual screen specifications. The actual business data and how it looks like. How it looks like should be kept as a separate document written by the UI person. The business data which the BA should do specifies the following:
Treat each screen as an individual document, this allows you to update one screen without having the developers read through the entire document to find what has changed.
The template screen specifications already specify some common field information so DO NOT REPEAT YOURSELF. If you are repeating something often then put it in the template specifications.
From the screen specifications and the domain specifications, you should be able to determine what validation rules you would need aside from the obvious mandatory validation, format validation. What you need to describe are business validation such as SIN validation etc. (although I would recommend you just put in links to some web site that describes the algorithm for you... Google is your friend).
The validation rules document should only describe the ones that are global rather than domain or screen specific. Screen specific or domain specific should be put in as part of their respective documents.
Business rules are best written out as decision tables. You can use the same technique I used for Curam rules.
These are not necessarily part of the business flow but is much needed and usually forgotten.
Labels:
business-analysis,
curam
0
comments
Colleague of mine came up to me with a problem. He was getting a ClassNotFoundException being thrown for some class in WebSphere. However, the class curam.foo.util.MyUtil is there, and it works on development. So what's wrong?
Well the default .classpath that comes with Curam just includes everything in custom/source. However, when the build scripts build implementation.jar, it only includes files that are in the impl package. So to fix this you need to move it to curam.foo.util.impl.MyUtil.
To prevent it in the future, you should modify the classpath so the inclusion pattern for custom/source only includes files in these folders. This will cause the developer's local builds to fail early in the game rather than later in deployment.
Labels:
curam
0
comments
To unit test a loader, you first need to extend it so that the load method is exposed. I usually just create a private static final class within the test class that I am using to test the loader.
private static final class ExposedFoodEvidenceLoader extends FoodEvidenceLoader { public void load(final RulesParameters rp) throws AppException, InformationalException { super.load(rp); } }
In the actual test method, I just create the RDO instances and execute the loader.
final FoodEvidenceGroup foodEvidenceGroup = new FoodEvidenceGroup(); final ItemGroupGlobals itemGroupGlobals = new ItemGroupGlobals(); itemGroupGlobals.dateOfCalculation.setValue(Date.getCurrentDate()); final RulesParameters rulesParameters = new RulesParameters(); rulesParameters.addRDO(itemGroupGlobals, false); rulesParameters.addRDO(foodEvidenceGroup, false); new ExposedFoodEvidenceLoader().load(rulesParameters); assertEquals(FOODTYPE.FILIPINO, foodEvidenceGroup.getfoodType().getValueNoLoad());
Labels:
curam,
testing
0
comments
This extends a java.io.Reader which will be reading from a bunch of strings. The purpose of this is to give the basis of a reader that would read chunks of data which are already be a Strings, but not allocate the whole string information in memory. For example, reading XML from VARCHARs that can span more than one record.
The test case shows a base cases and the general case.
public class BunchOfStringsReaderTest {
@Test
public void readFromBunchOfStrings() throws Exception {
final Reader p = new BunchOfStringsReader("FooBar", "mew mew",
"pikachu");final char[] buf = new char[1000];
int c; int i = 0; do {c = p.read(buf, i, 10);
i += c;
} while (c >= 0); final String s = new String(buf, 0, i + 1); Assert.assertEquals("FooBarmew mewpikachu", s);}
@Test
public void readFromNothing() throws Exception {
final Reader p = new BunchOfStringsReader();final char[] buf = new char[20];
final int c = p.read(buf, 0, 1);Assert.assertEquals(c, -1);
}
@Test
public void readFromOneString() throws Exception {
final Reader p = new BunchOfStringsReader("FooBar");
final char[] buf = new char[20];
final int c = p.read(buf, 0, 1);Assert.assertEquals(c, 1);
Assert.assertEquals('F', buf[0]);}
}
The following shows the code to be implemented to satisfy the test case.
public class BunchOfStringsReader extends Reader { private StringReader currentReader = null; private int i = 0; private final String[] strings; public BunchOfStringsReader(final String... strings) { this.strings = strings; if (strings.length > 0) { currentReader = new StringReader(strings[0]); } } @Override public void close() throws IOException { } public StringReader getNextString() { return new StringReader(strings[++i]); } private boolean hasNextString() { return i + 1 < strings.length; } @Override public boolean markSupported() { return false; } @Override public int read(final char[] cbuf, final int off, final int len) throws IOException { if (currentReader == null) { return -1; } int c = currentReader.read(cbuf, off, len); if (c == -1 && hasNextString()) { currentReader = getNextString(); c = currentReader.read(cbuf, off, len); } return c; } }
Of course this is just a sample of what can be done. A more realistic implementation such as something that will get the data from a database record would do the following:
The performance can be further improved by not relying on the StringReader and managing it via code. However, the resulting code would be more complicated, so it is left as an exercise for the reader.
Labels:
java
0
comments
Since Curam 4.5, it comes with a replacement to the Case Evidence Tree API called the Temporal Evidence Framework. This framework is a significant improvement in terms of development and ease of use over the previous framework. Kudos to Curam for providing us a way out of that previous API.
I won't be talking about the UI of the evidence framework, that is fully documented in the Documentation Center. I would be focusing more on how to do analysis of requirements and converting them to evidence forms and structures.
There are some properties of evidence that a BA should be aware of and take advantage of.
There are two inputs that would help you get the analysis done on this task.
By combining the two you can determine which of the actual forms to convert into evidence forms.
The typical approach when creating evidence is to start with an actual form and just build the evidence form from it. This should only be considered as a starting point.
Some things with actual evidence forms:
Following that you may end up with evidence that is not captured on any actual evidence forms. From this avoid the following traps:
The framework has the concept of both effective date and attribution dates. Attribution dates are basically start and end dates for an evidence. Effective dates show when an evidence has actually changed.
Effective dates are used if you want to see how an evidence changes over time. It is a bit more tedious on the end user because he has to enter two evidence records one when the person is eligible and another when he is not. Effective dates are always present, they can be empty, but the field must not be removed.
Attribution dates should be used if you are defining something that can actually begin or end.
The use of effective dates should be used when you are only trying to capture a change in circumstance. Effective dates are used when you need to visually see the history of changes over time.
Effective dates cannot be set unless the evidence has become active.
There is no reason why you couldn't do both. The Sample Sporting Grant does both.
Put validations only for sanity checks on mandatory fields and structural checks. Let the business rules handle business level validations. This keeps the validation logic simple.
Evidence forms ideally should not have any mandatory fields. This gives a user the flexibility to enter in whatever data he has now and fill in the rest later.
Rather than enforcing mandatory fields on save, have an on-save validation which checks if something needs to be mandatory on final it will show warnings to indicate to the user that the evidence form that they have filled in is not complete. Another validation on-activate will ensure that everything must be correct. The developers need only to change one from just a warning to a full error on the two events.
Although format checks should be done on save. If the user enters data, it should be in the correct form.
The following would be an example of validation analysis for an evidence form.
| Field | Format Requirements | Mandatory |
| Actual Cost | x >= 0 | yes |
| Estimated Cost | x >= 0 | no |
| Director | yes |
Once you have finished capturing what you require in evidence. An analyst needs to refactor the evidence screens so it is more beneficial to the user. They can work with a user interface specialist to do this.
There would be times when evidence forms have a common block. Take the following example:
I could refactor it as
Doing that I only have one evidence workspace to deal with which lists all my living expenses. This works well if the screens are very similar in nature except for a type discriminator which can be passed when creating a new evidence. You can do that by having "New Medical Expense" rather than "New" in the evidence workspace screen.
To determine whether an evidence should be in the participant or case level ask the following questions:
What you may notice is most evidence would be associated with the participant. So let's talk about when would it be in the case?
Unfortunately, Curam does not provide us with a facility of associating only with a participant. Everything is still captured within the context of a case.
The following shows some of the analysis work products that would come out.
The following is the top level view of all the evidence types.
| Evidence Form | Approval Requirements | Attribution Dates | IC Types Associated | Person Assoc |
| Income Report | yes | Income Support Rehabilitation | yes | |
| Special Circumstance Benefit | Director or 2 supervisors | no | Rehabilitation | no |
| Medical Incident Report | Medical supervisor | start date only | Income Support Rehabilitation | yes |
You also need to tabulate all the products that would actually need the evidence so have a product evidence link list.
Product Name
Finally you need to specify what fields an evidence form has and what validations if any there are. Just remember validations on save come first before activate. Keep the required fields on save to a minimum as well. So something like this would help out:
Evidence Form
| Field | Type | Validation On Save | Validation On Activate |
| Participant | Case Participant | required | |
| Expense Amount | Money | > 0 | |
| Expense Type | Expense Type | not blank |
Determining where to get the data is pretty simple.
Evidences has approval support built in, you can use it in lieu of putting in a "approved by" field in your evidence.
Labels:
business-analysis,
curam
2
comments
To be honest, Curam provides an excellent document called the Rules Definition Guide in their Documentation Center that would be a good read for any Business Analyst dealing with Rules. This blog will not rehash what is written there, but my knowledge is based on what was written in that document and other business rule specifications I have seen in other projects.
Although the focus is on Curam, this can be applied to any other rules engine analysis work.
That's usually one of the first questions. The answer to this is neither. If you're thinking of rules and evidence you're thinking way too far ahead. That's a good thing.
The starting point for any rules/evidence work is policy. Policy can be in the form of a legislation or an existing manual. This sets up a guideline for you to work with.
Policies tend to be very large documents. It is best that before you try and extract information from the policies you break it up into logical chunks. Usually chapters and subchapters are sufficient.
Most policies will tell you what conditions you have to meet and what are the outcome based on those conditions. This will be the data that gets put into the catalogue.
The catalogue is an interim work product. It should contain a list of conditions and outcome and links to the sub-policies. This is predominantly a copy and paste from a policy document.
The catalogue would have the following sections.
Here is an example of a conditions that may appear in a policy document.
A senior citizen with no living siblings will receive $100 times their age if they have paid CCSIB premiums for at least 5 years.
A senior citizen with living siblings will receive $100 times their age if they have paid CCSIB premiums for at least 10 years.
The analysis can be broken up into a more formal table format. However, since this is an interim piece of work, you can get away with just creative highlighting. For example:
A senior citizen with no living siblings will receive $100 times their age if they have paid CCSIB premiums for at least 5 years.
What I have done was underline each individual input data and bolded the outcomes. If you keep things consistent you should be able to get away with that approach with the client. Just remind them that this an interim work product but one of the first step in analysis.
If you need a formal table format, you can use the following:
| Condition ID | Policy ID | Policy Text | Data Elements | Outcomes | Analysis |
| P001-C001 | P001 | A senior citizen with no living siblings will receive $100 times their age if they have paid CCSIB premiums for at least 5 years. |
| receive $100 times age | |
| P001-C002 | P001 | This benefit cannot be removed by any future government | Statement. Not a rule | ||
| P001-C003 | P001 | Part of a clan |
| Missing outcome. |
There was an emphasis on interim, because this catalogue is useless for development and just a regurgitation of the policy from the client. It is also highly likely that not everything can be covered in policies.
As a BA you have to add value in order for development to be able to use it. So the next step is to convert what you have into a decision table.
The decision table is a table that collects all the information from the catalogue and places them into a tabular format. A group of condition results in a decision table. The following shows a decision table for a condition group.
Conditions satisfied:
| Input Data Name | Input Data Formula | |||||
| senior | CN-PO-1.1-1 | Y | Y | N | N | N |
| citizen | CN-PO-3.1-1 | Y | Y | N | Y | N |
| no living siblings | CD052 | Y | N | Y | Y | N |
| paid CCSIB premiums for at least 5 years | EV042 >= 5 years | Y | - | - | - | Y |
| paid CCSIB premiums for at least 10 years | EV042 >= 10 years | N | Y | Y | Y | N |
| paid MCSB premiums for at least 10 years | EV? < 10 years | - | - | - | Y | Y |
| Outcome | Outcome ID | |||||
| Receive $100 times their age | OC412 | X | X | X | ||
| Receive $200 times their age | OC413 | X | X |
The Input Data Name specifies the input data as per the condition record from the catalogue. The outcome data is information required by the outcome calculation.
The Input Data Formula is a formula that represents the information in the input data name. The formula may consist of an ID to point to some input data with a few simple calculations if needed. This prevents having to create several input data records where the only difference is one parameter.
The formula does not show where to get the data, but it is best the Input Data ID represents the possible source in this example we used CD for core data, CN for other conditions, EV or evidence data. Information on where to get the data is in the I/O catalogue which is described later.
Sometimes we don't have the any input data information defined yet, in which case we indicate it by a "?" on the ID to remind us to get the information.
One word of advice, try to use what is in the core rather than creating new evidences. The information in the core tend to be things that do not really change over time and can be shared with other parts of your application. Evidences are usually not shared outside the integrated case it is associated with.
One other thing to avoid: you may be tempted to just put some of the conditions like this:
| years paid paid CCSIB premiums | EV042 | >=5 | >=10 | >=10 | >=10 | >=5 |
You may have a harder time normalizing the decision table later. So avoid that.
The Outcome specifies the outcome as per the condition record from the catalogue. The Outcome ID is a unique identifier for the outcome. The outcome ID is not a formula, because describing it as a formula in the decision table would make things hard to read. The detailed information for the outcome will be in the I/O catalogue which is described shortly.
Most documentation regarding rules tables call the outcome as Action, but in Curam speak it is probably best to call this an outcome as the rule engine does not actually start up processes.
Once you have captured your decision table, you can optimize it using the techniques shown in http://www.cems.uwe.ac.uk/jharney/table.html
The conditions satisfied section is just there for the interim. It is meant as a way for the BA to keep track as to which conditions have been completed, be the rule catalogue will eventually be discontinued in favour of the decision tables and I/O catalogue. At which point, the section will be reworked as policies satisfied to ensure that any change in policy will trigger a trace back to the proper decision tables.
This catalogue captures the input data and outcomes that were required by the decision tables in the previous section.
For input data, there are three common sources:
The following tables would illustrate how to capture the information for input data:
| Input Data ID | Input Data Name | Calculation |
| CN005 | date of birth | Person.dateOfBirth |
| CN042 | no living siblings | Person.dateOfDeath defined for all ConcernRoleRelationship relations where type is sibling |
| CN006 | age | Current Date - Person.dateOfBirth |
| Input Data ID | Input Data Name | Evidence Form | Evidence Field |
| EV042 | years paid CCSIB premiums | CCSIB | Years Paid |
As you can see there are two different ways of writing the input data specifications. For core data, it tends to be a calculation rather than a direct field because the data tends to be spread out. It is best to communicate with a Curam developer or someone who knows more about the reference model. It is recommended that data elements be of different type to distinguish them from calculation descriptions.
Evidence input data tends to be new and so it should be possible to list the exact form and field rather than a calculation.
The Outcome data shows the following information:
| Outcome Data ID | Outcome Data Name | Objective Type | Objective Value Formula |
| OC412 | $100 x age | Money | CN006 x 100 |
| OC413 | $200 x age | Money | CN006 x 200 |
| OC501 | Food Delivery | Product Delivery | "FOODDELIVERY" |
| OC001 | General Eligibility | Assessment |
Generally an outcome would end up as an objective in Curam terms. The objectives types are usually money, a product or an assessment. The formula column shows the formula with reference to some of the input data as well.
This is as far as the BA would go. The combination of decision tables and the I/O catalogue would be sufficient information to communicate with the development team. It also provides a way of communication with the client team as they can visually see what would happen depending on their choices.
At this point the rule catalogue should be discarded in favour of the decision tables and the I/O catalogue. This is assuming that all the conditions in the rule catalogue are met.
The decision table will be a almost mechanical process to convert to the Curam rules structure. I say almost because the decision table does not name what the data or rulesets are nor do they group things together. That is left with the development team as part of their naming conventions.
The I/O catalogue will drive the creation of evidence and loaders.
Don't get into analysis paralysis. You should never ever do this when you think you completed a previous section. Once you have sufficient information, move onto the next section, if you realize something is missing go back. There is no harm in updating the previous one.
Business rules are very complicated, and policies are just as complicated. Policies tend to be vague and make certain assumptions which cannot be translated into code so you need to ensure those get analyzed.
Most likely the little problems would arise in development, but if you have done your job correctly, they should very little and you can fix it with a relatively quick turnaround.
The process defined here will provide sufficient documentation for both the client what is going on and the developer to understand what needs to be done.
The process defined here is general to most rule engines as well, there is very little Curam specific information so it can be used in other non-Curam projects.
Labels:
business-analysis,
business-rules,
curam
1 comments
