That's cool MDE - Introduction

kick it on DotNetKicks.com

This tutorial is about creating a (almost) fully functional web-based database application within 8 hours of work with a great MDE tool we're using since several years now. The tool is called “OlivaNova – The Programming Machine”.

For those of you who are as impatient as I am,click on http://www.c5solutions.de/TravelmanagementDemo to see and try out the running web application prototype (or take a look at the screenshot below).

I would like to show you how to implement a rock-solid, multi-tier, scalable, AJAXified C# ASP.NET client/server-application with ease. The tutorial consists of five parts:
  • 1. The specification
  • 2. Modeling the class diagram
  • 3. Modeling business logic
  • 4. Modeling the user interface
  • 5. Generating and using the application

Modeling, generating and testing took me around eight hours.
Of course, this prototype isn't perfect, but you should be able to get an idea of the possibilities you get with that tool. Throughout the entire code, I coded only as much as four (!) lines of c# code by hand (whereas two of them are only quick-and-dirty hacks to prevent demo users from deleting other users). I encourage you to show me another tool or method that’s so powerful. You'll love it.

Right now, we're going to start with part 1) the specification. I'll write and publish the following parts of the article within the next few days.

Part One: the specification

The customer wants to have a travel expense and management system. The system has to be implemented as web-application for employees, managers and administrators as it has to be accessible from the internet (after authentication). An Employee requests a and depending on the estimated costs the system automatically approves the trip request or forwards the request to the employee’s manager for approval. Employees are assigned to a travel cost group which defines the cost limit that reasons an automatic approval (per trip and also total costs within x days). The travel cost group can be changed at any time in general as the change of the travel cost group doesn’t affect trip requests in the past but only in the future. The trip request status has to be visible to both the employee that requested the trip and his or her manager. Of course, each employee must see only his or her own trip requests and each manager will be able to see only the request of his or her employees (a manager is responsible for the employees within the same department he works in). Trip requests can also be rejected by the manager; a trip request approval status can have the following values: new, automatically approved, manually approved, rejected.

Once the employee’s trip has finished, the employee must enter the actual costs by entering all receipts he paid throughout the trip. If the actual travel costs regularly (trips within x days, as specified in the travel cost group) exceed the travel cost group limit by more than 20 percent, the employee’s manager should get a notification about that fact.

As an optional feature, employee and manager records can also be disabled, so the person cannot log on to the system anymore. Eventually the user administration (employee, manager) is going to be synchronized with the corporate’s AD.

All data views have to exportable to Microsoft Excel.

Please note: I mixed up the words "travel application " and "trip request" somehow because I modeled the application before my colleague corrected me and I'm too lazy to change the model and re-generate the application. I hope you understand this.

Specification of the employee’s data:

First name, last name, salutation, birthdate, department, travel cost group, email address,
ratio in percent of actual costs and estimated costs regarding the last travel,
ratio in percent of actual cots and estimated costs regarding the travels within the last n days as defined in the assigned travel cost group,
ratio in percent of actual costs and n days cost limit as defined in the assigned travel cost group,
boolean value that indicates whether the previously mentioned value exceeds the n days cost limit by more than 20%.

Specification of the manager’s data:

Manager is also an employee; responsible for department (for simplicity, this is the department he also works in)

Specification of the department’s data:

Department ID, name short, name long

Specification of the Travel application data:

start date (must be less or equal to end date),
end date (must be greater or equal to the start date),
start time (if travel end date on same days as start, start time must be lesser than the end time), end time (analogue to start time),
estimated costs (>=0),
currentCostLimit (calculated when entering the application),
abroad (yes/no),
connection (yes/no),
departure location, destination location, intermediate location, purpose, cost center, cost unit,
car license number (dropdown, if no value chosen, cartype must be private; if value chosen, cartype must be company),
cartype (company/private; see car license number)
business Mileage (>=0),
private Mileage (>=0),
receipts, real costs (calculated based on the receipts net sum)
approvedBy ("SYSTEM" if travel cost limit not exceeded; the login of the manager that approved the application),
application status (0=new; 1=automatically approved, 2=manually approved; 3=rejected)

Specification of receipt data:

receiptID, Receipt type (dropdown), bill date, bill time, travelApplicationID, cost Net, tax%
Specification of receipt type data:

Receipt type name (ID)

Specification of car data:

License number (ID)

Specification of cost center:

Cost center ID

Specification of cost unit:

Cost unit ID

Specification of Travel cost group data:

Travel Cost Group ID (autonumeric),
cost limit (decides whether the travel application is automatically approved or not),
cost limit for travels within the last n days,
number of n days for the cost limit mentioned above

Because I don’t want to bore you, I’ll stop specifying any further and just implement the requirements in the model because the effort of directly modeling the features of smaller applications like this one is nearly identical to specifying features in a normal textual representation.

In the next part, I'll show you how classes and attributes are being modeled. Most likely, you'll already know the idea behind it as this modeling language is based on OMT, a predecessor of UML (http://en.wikipedia.org/wiki/Object-modeling_technique).

kick it on DotNetKicks.com

Keine Kommentare: