Mukarram Mukhtar

Application Architecture

Case Study of Paragon Healthcare:

The purpose of this article is to provide software engineers/application architects with some examples of design documents, application architecture diagrams and class diagrams. For this purpose we’ll take an example of a hypothetical company in healthcare industry, Paragon Healthcare or PHC. Since in depth knowledge of this company’s services and other related information is beyond the scope of this article, I’ll give an apercu of functional requirements before each diagram:

 

Broader Picture:

 

·        PHC has its public website, created several years ago, which gives all the information about the company, its services, jobs, contacts etc.

·        PHC provides services in healthcare field and all of its customers/patients’ health history is saved in highly secure Facets application that runs over Sybase database.

·        There is a web service which can be used for read-only access to customers’ records in Facets server.

·        Now PHC wants to create a new web portal only for its customers. Purpose of this portal would be:

 

o       Customers can create their user accounts

o       Customers can view/print only their medical claims

 

·        All new user accounts will be created in SQL Server database.

·        Whenever a user attempts to create a new account, he/she will be required to enter member id and full name of the patient. This information will be validated by PHC web service first and then user account will be created in SQL Server database.

·        For customer’s convenience, a small team of customer service representatives (CSR) has been setup. If a customer is having some problems in creating user account or accessing member claims then they can make a phone call on PHC help line to talk to CSRs who will assist them.

·        PHC also wants to create a separate intranet application for CSRs, called PHC Admin Tool. The purpose of this admin tool is to give CSRs higher level of access on SQL Server database, where they can:

 

o       Create and Manage users’ accounts

o       Reset passwords

o       Activate/inactivate users

o       View activities of users on Web Portal

 

·        Creation of user account from Admin Tool is also done after validation through web service.

·        For HIPAA compliance, CSRs do not have access to patients’ medical history or member claims.

·        PHC web portal and Admin tool will both have link to PHC main website.

 

Following is a broader picture diagram of application architecture based upon above functional requirements:

 

broader-picture1

 

After Bird’s-Eye view on the whole application architecture, now we are ready to draw diagrams that will give a little more details on two basic components of the application i.e., PHC Web Portal and PHC Admin Tool. Sybase and SQL Server databases’ design would come under ERDs, a completely different topic than Web application’s design; thus I’ll skip that part for now. Likewise Web service requires a whole new article to completely discuss its configuration and setup. Let’s take a look at synopsis of Admin Tool:

 

·        For new account creation, I created a web page which will take user info e.g. member id, first and last name as input etc, validate it via web service and then create an account in SQL Server database using Membership class.

·        Account Management web page will have search user, reset password and activate/inactivate functionalities.

·        Similarly, Activity Log Management and Security Question Management web pages are for view user activity and add/update/delete security questions respectively.

 

PHC Admin’s diagram will look something like this:

phc-admin1

PHC Web Portal is a little more complicated beast. Functional requirements of PHC Web portal are as follows:

 

·        Home page of Web portal will have links to the following web pages:

 

o       Login Page

o       Create Account

o       Reset Password

o       Retrieve Username

 

·        Login page will be main door to enter the web site and to get access to medical claims.

·        If user has not yet created an account, he/she will be provided with a link to Create Account web page.

·        In case of forgotten user name or password, two links will be provided to Retrieve Username and Reset Password pages respectively.

·        Once user has logged in, Account management web page will provide functionalities like updating user profile, update security questions and answers and reset password etc.

·        Member claims pages will be used to view/print members’ medical claims.

 

Let’s see how the diagram will look like:

phc-web-portal1

Application Strata and Façade Design Pattern:

After having bird’s-eye views of both the application components, now we are ready to dive deeper and see how each of these applications have been designed at application tiers level; Admin tool first:

 

·        I’ve divided the whole application into 4 tiers; 3 of these tiers (all the layers except data layer) can either be different ASP.NET projects integrated under one solution file or they can be different folders under one ASP.NET web project. Whichever approach you adopt, the 4 strata will be as follows:

 

o       Presentation Layer

o       Façade & Business Logic Layer (will be further divided into 2 layer later)

o       Data Access Layer

o       Data Layer

 

·        Presentation layer aka UI layer comprises 4 web pages, as shown and explained in previous section.

·        Façade & Business Logic Layer consists of some business objects and façade classes (detail coming in short).

·        Data Access Layer consists of classes and web service that have everything they need to access database.

·        Finally, data layer is composed of SQL Server Database and Sybase database exposed through PHC Web Service.

·        Rules of the game are:

 

o       No layer can bypass its neighboring layer to access a farther layer. What this translates to is, presentation layer can never, let me say that again, never ever, directly instantiate any class in Data Access Layer; neither can it call any shared method of DAL classes, nor it can directly access SQL Server or Sybase databases.

o       Similarly, Façade classes can never directly access SQL Server or Sybase databases.

o       Composition relationship between layers will flow from left to right or within the layer, e.g. database object from Data Layer will be composed in DAO classes (left to right); likewise, DAO classes will be composed in Façade classes (left to right again). Similarly, Façade classes will be composed in Presentation Layer (left to right again).

o       Exception to the above rule is only with Business Objects; these classes are free to wander in any layer in any direction as Presentation Layer also needs to instantiate them and so as Façade and Data Layers.

 

For more details on Façade design pattern, please see http://www.dofactory.com/Patterns/PatternFacade.aspx . Now let’s come back and see how our design diagram looks like:

admin-application-tiers1

  Not much explanation is needed for Web Portal’s application tiers, since layers and rules are same; except the only difference is number of web pages. Diagram looks like this:

  portal-application-tiers11

 

Following is simply another way of drawing the above diagram with Façade & Business Logic Layer split into two, i.e.:

 

·        Business Objects

·        Façade Layer

phc-class-diagram1

 

Class Diagrams & Prototype Design Pattern:

Now let’s discuss and see class diagrams of each of the above mentioned application layers:

 

·        IInstantiable is an interface which will be implemented by almost all the business objects that are instantiated for data operations in database.

·        Clone() method in the interface will be implemented by each class in its own way thus implementing Prototype design pattern; for more details click here ( http://www.dofactory.com/Patterns/PatternPrototype.aspx ).

 business-layer

 facade-layer

data-access-layer

 

Legend:

In all of the above diagrams I’ve used standard symbols and followed application architecture & class diagrams conventions; however for some novice programmers following is the legend diagram of this document.

 

 

 

legend

 

Well folks, that’s pretty much it is; writing a design document is not a rocket science but you can either be busted if you lack this skill or triumphed if you know how to write one. See you folks later; let me have your feedback…

Advertisements

1 Comment »

  1. For most up-to-date news you have to pay a visit the web and on web
    I found this web page as a most excellent website for
    most up-to-date updates.

    Comment by Lan — May 8, 2013 @ 1:24 am


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: