Category Archives: Software Design

USE CASES IN UML AND OBJECT ORIENTED PROGRAMMING

When I took a Object Oriented Programming Class in my second semester in college, I was not able to understand a lot of concepts essential to software design and architecture. I was new to the concept of Classes, relationships between classes, API and exposing methods and attributes. Of course, that’s why I was taking the class. I could program some fundamental programs in pascal before this and i loved global variables (the fact of the matter is I still love them but probably somebody who is debugging a problem or a bug in my code, probably would not like them). So coming back to the point, the first concept in any Software development methodology is a requirement. Business Analysts would talk to the potential customers and figure out a bunch of requirements. Software Architects or Software Designers would view the requirements and model the requirements in a way that would make sense to a Software Developer. Sometimes a business analyst would be talking to the customer and doing a design, there are no hard and fast rules. The main purpose of UML is to specify requirements and design in a standard format so in a team other people can relate to the requirements and design and write efficient code. In my software development experience, good requirements mean 50% less work and also it would save the rework and costs in terms of testing time, and no hacks in code. Overtime a piece of code gets modified multiple times by different people who like to code differently, so more clear the requirement is, most relevant
code you can write to begin with.

What is a use case ?
I would not go too much technical detail on exactly how it is defined. To me its a functional requirement and that’s what I have read in books as well. Functional requirements of a system can be described using Use cases and Use Case Models.By functional requirement I mean that we would use a USE CASE to describe a feature of the system we are trying to design. It will usually involve describing an event that will happen as a result of user or system doing something.
If Use case defines a requirement then a Use Case Model pretty much describe the overall working of the system by showing a collection of requirements and the relationships that exists between them. Lets say we are designing

Let me give you an example, you love Facebook right ? Right or wrong ?? he-he, lets say you have to describe the event of “Sending a friendship request to another member” how that will happen ? There are some business rules that will govern how. First thing is the person browsing Facebook needs to be logged in, second thing is you should be able to find the profile where you want to send the friendship request to. Then there should be a button or a link or some User Interface that the person would be able to click to be able to send a friendship request. After the button or link is clicked, Facebook will do its thing and display if it was able to send your friendship request or “Sorry No Donuts for You”, I guess ORKUT did that, not guessing I am pretty sure ! So in the scenario I just described there are a bunch of components that will make up the use case and I will describe them as I go.

The Aim or Goal or Description of the Use case is to be able to send a friendship request to another member of Facebook. You can give it a short and sweet name and be fancy like “Sending a Friendship request”. So the name/title of the USE CASE would be “sending a friendship request” and the goal/aim/description would be “The system/website/Facebook should be able to send friendship requests to other members with a profile on the system/website/Facebook. So now you know what is the title and description (description is a wordy extension of the title). Next thing would be to identify who is initiating this behavior of the system and by doing what ? A user is initiating the action by clicking on a link. The Primary actor/stake holder of the use case is the “USER” and “Clicking the Send Friendship Request Link” is the Trigger. After clicking since the system/Facebook will do something and say whether it was successful or not and actually send the request “SYSTEM” can be thought of as Secondary actor. So now we are down 5 trashy terms (Title,Description, Primary Actor,Secondary Actor and Trigger). Now there are some conditions that should be fulfilled before the Action/Description can happen like the person sending the friendship request should be signed in to Facebook and be able to locate the profile of the person where the request would be sent and be able to click on the correct link. These are the Preconditions of the Use Case. So the conditions that should be fulfilled before the scenario described in the use case are its preconditions. Usually they can be represented as a numbered list on a Use Case. Similarly after the scenario described in the USE CASE is completed, something will happen that would be the POST CONDITION. Either the friendship request is sent or Sorry No Donuts for you :P. Now comes the main flow or happy scenario or the USE CASE which would define a sequence of events and action that would describe the Use Case. For example

1. User A found User B on Facebook and is able to stalk
2. User A clicks on the “Send Friendship Request” link
3. System sends a friendship request to User B and also sends a notification email

This scenario is happy because whatever we are trying to achieve we did so successfully. Similarly since the system will not be happy all the time, you can have an alternate scenario. Alternate scenarios are also called USE CASE Extensions

1. User A found User B on Facebook and is able to stalk
2. User A Clicks on the “Send Friendship Request” link
3. System was unable to send a friendship request due to some error and displays a message “Sorry No donuts for you since cookies are disabled in the browser !”

I would recommend text from UML Distilled and anything written by Martin Fowler on this subject.

Advertisements

Leave a comment

Filed under Software Design

Designing Web services with REST

REST is an acronym for Representational State Transfer. REST can be described as an architectural style (not a standard) of networked systems. This architecture is vastly becoming popular with Web services. The underlying protocol which is used with web services is http and the distributed systems are connected through the web (internet). REST is an alternative architectural style to SOAP (Simple Object Access Protocol) which instantly gained popularity with the advent of web services and is the widely used standard for web services data transfer.  In this essay I would highlight on the working of REST, the implementation style, characteristics, and principles and compare the architecture with SOAP and try to conclude which one might be better and under what circumstances. In the end I would explain how to use REST with web services by designing a dummy web service which follows the REST architectural style 

So what does Representational State Transfer mean

 As we all know Internet is a collection of various resources. All the resources on the internet (including the web services with a published wsdl) can be accessed through a uniform resource locator (URL) e.g. http://www.mywebsite.com/mywebservice.With Web 2.0 in action static websites are loosing visitor’s interest and we see more and more dynamic web applications like forums, interactive blogs, websites which are regularly updated by users. Example of these applications are wikipedia where the user can moderate the content instantly , youtube where users can update their videos and they immediately become available to potentially everywhere the web application could be accessed with a browser and EBAY where there is real time bidding by the users of the web applications. With REST as the underlying protocol is Hyper Text Transfer Protocol (HTTP) the application changes or transfers its state after each http request / response for each requested resource. 

 So REST can be considered as an architectural style where a web application changes its state constantly and it is named as Representational State Transfer. 

Roy fielding (A researcher of this architectural style, defined the key characteristics, motivations, benefits and the circumstances where its implementation might be beneficial) explains REST as:  

Representational State Transfer is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”

  The motivation for REST was to capture the characteristics of the Web which made the Web successful. Subsequently these characteristics are being used to guide the evolution of the Web.In the beginning of the essay I emphasized on REST being an architectural style and not a standard. REST is a way in which web services can be configured to deliver data streams or we can say that client accesses a resource on the World Wide Web and is certainly not a standard like HTTP or XML. The concept is much similar to what Web 2.0 is, you want see W3C putting out a specification on the working details on REST. Same is true for the vendors of software development technology, the software giants like Microsoft, sun and other platforms manufacturers won’t come out with a REST development toolkit simply because it’s an architectural style. By architectural style I mean a way of implementing things or we can say that defining a framework using the existing technology and using it in a way which is more efficient and effective for us. Although REST is itself not an industry standard but as it works with the Web and the distributed world of internet it works in parallel with many industry renowned standards. These include HTTP, XML, HTML, URLs and various file formats like gif, jpeg, text/xml, text/html and other MIME types. Many of the services especially the web services that we use as out day to day routine for our usage and software development services are based on REST and we are even not aware that we are using it. This is because REST does not work with minor implementation details it has more to do with the overall integration of the components that make a web application or a web service work. 

So what are some of the key characteristics of REST? 

As we know that the model that http follows a Client Server paradigm (as it works on the internet)  where the client is the consumer or requests a resource identified by a URL and located on the World Wide Web and the server is a web server which has the required resource and delivers it using HTTP. The Client Server paradigm is further classified into a pull or push based implementation Style. REST is essentially a pull-based implementation style of http where the consumer (consuming services, applications e.g. browser) or client pulls various representations (resources). Another Key characteristic that rest follows and is due to the http being the underlying protocol is it’s stateless. As we know that http is a stateless protocol so each request from client to the server in this http pull-based implementation style should contain all the information which is necessary for the server to understand the request. In other words the client cannot take advantage of any information that is stored in the server’s context and has to send the client’s info with every representation transfer. An optimization and a key characteristic that REST utilizes to overcome performance limitations and overheads is CACHING. When the web server responds to any of its clients with the requested resource the responses should have the ability to be marked as either cacheable or non-cacheable depending on the capability of client which might be an application or a service. So if the client if Caching enabled the performance can be optimized as the implementation architecture supports caching. What it means essentially is if the same resource is requested by the client again and again or for instance the same parameter or argument is passed to a method exposed by a web service the client should know what the service will return and it should directly get the desired result without going through the whole request/response process. Another key characteristic of REST is all REST implementation should follow a uniform interface .This means that all the resources located on the web server can be accessed by using a generic interface such as HTTP Get, Post, Put or delete. In a REST based implementation, each resource that is requested from a web server can be identified with a unique URL. This is pretty much how internet works, the critical components here are the Client and Server Applications, HTTP as the request/ response based protocol, and the Domain Name System (DNS) which resolves the host names to IP Addresses to exactly know where the requested resources are physically located. So it is essential to use named resources while implementing REST. Another key characteristic of REST is interconnected resource representations. This essentially means that the representations of the resources are interconnected using URLs, thereby enabling a client to progress from one state to another. REST uses Layered components which imply that intermediaries, such as proxy servers, cache servers, gateways, etc, can be inserted between clients and resources to support performance, security, or in other words using intermediary devices between the client and the server does not restrict the client from accessing the server. Etc  Designing web services using REST: 

What are some of the key design principles that we have to keep in mind while designing web services that makes use of REST? Primarily all the conceptual entities that the designers or developers wish to expose as services need to be identified. The design principle is not only limited to REST but it’s a general rule of thumb for good web service design. As we know, one of the characteristics of REST is using named resources. Recall that resources are named as URLs .REST uses a particular naming convention to access resources on the web server. REST proposes to use nouns as resource name instead of verbs.  

E.g. URL such as http://www.bookstore.com/books/getBook?id=11234 should not be used instead the resource should be named as http://www.bookstore.com/books/11234   REST follows the phenomenon of categorization of resources. The resources should be categorized in terms of whether they can only be accessed and not changed by the client. Such resources are called Read Only Resources. With Read only resources clients can just receive a representation of the resource. In addition to this the clients can add new resources or modify existing ones. REST suggests categorizing the resources based on resource types. If they are read only resources which the client can access but not modify, only HTTP Get should be specified as an access method whereas if the clients can update the resources then HTTP POST, PUT, and/or DELETE can be used. In this context all resources accessible via HTTP GET should not have any side effects. That is, the resource should just return a representation of the resource. Invoking/calling or requesting the resource should not result in modifying the resource in any way.   As from the above description it is evident that REST (Representational State Transfer) follows a state based implementation, it supports how we can drill down further into the application. REST supports navigation by supporting navigational links so the state of the request changes and recorded.   For designing a REST style web service some performance optimizations are provided as the design guidelines. REST proposes not to present the whole data in one single response simultaneously to the user (client). Instead present a portion of the data with the ability to drill down information by providing navigational links so the user can drill down by again requesting a resource identified the navigational link and thus the state of the client application changes.   If a web service is to be designed that uses REST as the architectural model, the format of the response data has to be defined using a standardized schema such as the Data Type Definition (DTD) or W3c schema or Schematron e.t.c For those services that require a POST or PUT to it, also provide a schema to specify the format of the response.   The SOAP and REST comparison:   Having discussed the working of REST, characteristics and principles of a typical application that follows a REST based architecture and knowing that it is a design alternative to SOAP (Simple Object Access Protocol) the question that comes to our mind is when to use REST and when to use SOAP , what is the key factor that answers this question ? What are the benefits of REST over SOAP and vice versa? Although there are plenty of overheads which can be immediately noticed with implementing SOAP, writing a wrapper class that puts a SOAP envelope on every request response that goes to and from the web service on the client side and configuring the service itself to parse those request may sound like a lot of work. But primarily we now have tools to do it; I have worked with Microsoft Visual Studio where if a wsdl file hosted on the internet is given as an input all the wrappers required for the web service and initializing SOAP are generated automatically, same is true for many DELPHI environments. The advantage of using SOAP is “sending complex data structures to the web service”.  Development tools like Visual Studio or Delphi can read the WSDL from the web service and that gives you the "INTELLISENSE" auto completion functionality that can save a lot of coding time. The drawback with SOAP is that there is more overhead in the construction of the method request and with the parsing of the request on the web service end.  When you have a web service that is serving thousands of requests a minute or second, that overheard may not be needed. This is in contrast with REST where simple HTTP Get and PUT commands are used to interact with the web service. You compose a URL for your web method request and the service sends back a response.  The response is usually in XML, but that is dependant on the functionality of the web service. For web services that have relatively simple data types, using REST can provide the functionality that is needed.  You also get the advantage of testing individual method requests from a browser as the method request is basic URL. Another big advantage of using REST over SOAP is by sticking to simple semantics (especially if you limit yourself to GET as much as possible); it scales much better as it can take advantage of all levels of caching between you and the server. REST takes advantage of the existing scaling mechanisms the internet has grown on top of HTTP - something SOAP cannot do. 
 The complex data types can still be used with REST by including them as payloads - you just have to manage interpreting it yourself instead of relying on a rich library layer to make it feel like some native type in your program. So if we compare the contrasting architectural styles, REST is the way to go if you are looking for better performance and the web service consists of simple data types where as SOAP would be better if the client application has to be developed fairly quickly and Complex data structures are to be used.   A REST example – An Online Library Catalogue exposing library data as a service ( A self created dummy service to demonstrate REST) :   Here I would describe the whole process of how REST works and some of the common practices that are followed by developing a simple Library Catalogue Service which would define a couple methods of displaying a list of books and listing a particular book’s details. The functionality that is exposed by the service is:   Generating a list of books   Generating details of a particular book  

 

Generating a list of books:


The web service presents a URL to a “Book listing” resource. For example, a client would use this URL to get the parts list:

http://www.books-online.com/books

The client does not know anything about how the listing is generated by the service. All the client knows is that if he/she submits the above URL then a document containing the list of books is returned. Since the implementation is transparent to clients, the Book’s catalogue is free to modify the underlying implementation of this resource without impacting clients. This follows two major principles or concepts of Software Design, loose coupling and encapsulation.Here’s the document that the client receives whenever the above URL is accessed:

<?xml version="1.0"?>
 <p: books xmlns:p=http://www.books-online.com xmlns:xlink="http://www.w3.org/1999/xlink">
 <Book id="00001" xlink:href="http://www.books-online.com/books/00001" mce_href="http://www.books-online.com/books/00001"/>
 <Book id="00002" xlink:href="http://www.books-online.com/books/00002" mce_href="http://www.books-online.com/books/00002"/>
 <Book id="00003" xlink:href="http://www.books-online.com/books/00003" mce_href="http://www.books-online.com/books/00003"/> 
 <Book id="00004" xlink:href="http://www.books-online.com/books/00004" mce_href="http://www.books-online.com/books/00004"/>
 </p: books>    Note that the parts list has links to get detailed info about each book. This is a key feature of REST. The client transfers from one state to the next by examining and choosing from among the alternative URLs in the response document thus resulting in a change of State which REST is all about.   Generating details for a particular book: Any book’s details can be generated by accessing the URL associated with the book’s detail (as presented by the xml in the response above). Again the client receives and XML document which can be parsed for the book’s details.

The web service makes available a URL to each part resource. Example, here’s how a client requests part 00345:

http://www.books-online.com/books/00001  

Here’s the document that the client receives:  

<? Xml version="1.0"?>
<p: Book xmlns:p="http://www.books-online.com"            xmlns:xlink="http://www.w3.org/1999/xlink">
<BookID>00001</BookID>
 <Title>SOA Concepts, Design and Technology</Title>
 <Description>This book is about Services Oriented Architecture</Description>
 <Author>Thomas Erl</Author> 
 <Number of Copies>2</Number of Copies>
<Section>Computer Books</Section> 
</p: Book>          

3 Comments

Filed under Software Design

Concept of Services Oriented Architecture

There are many different styles of applications that are written today. But lately we have seen a paradigm shift where the concept of “Software as a Service” is really been taken seriously. If you are an IT professional chances are 9 times out of 10 you must have heard of the term “Services Oriented Architecture”. What the heck? And you are like “Yeah, I know what that is and you go on  You make an application that consumes a web service!! Bingo!! ” No that’s not what SOA means’s is a new software development model or “An architectural style” where the business layer instead of integrated in the code is rather orchestrated :S . Confused already??  What I have realized over a period of time in the Software Market, whenever a new technology comes don’t jump into that technology and just know the couple POWER Words to horrify your bosses. I bet you 10 to 1 that Mr. John Doe or whatever!! Standing by the coffee machine and boosting about that “New technology” knows little about it.The key idea is to write software as a service ( It may be a web service or a windows service , a service within the enterprise accessible to you from your browser or a service that is published on the internet with a valid WSDL).If you notice the companies that have made it really big during the past year e.g. Google , Amazon and EBay I think the primary reason of their success lies with adopting the new software development paradigms and quickly able to deliver business rules with their service orientation.

So ok!! You want to know what exactly a Services oriented Architecture is. It’s a new software development paradigm which is suitable for applications with distributed processing capabilities .How it helps business?

 Information technology is the backbone of nearly all major businesses. Nearly all major businesses today are Information technology driven. Any change in the business rules or business process (ways in which business is conducted) implies a change in the legacy system infrastructure. This change is sometimes difficult to implement as business logic or business rules are implemented as software code. The legacy systems lack the interfaces and are not designed to integrate / interpolate with newer systems, thus the company looses profitable business and a huge factor is the extent to which the legacy systems can be made scalable. We need a new paradigm of Agile Software development where we need to extract the business logic from the actual implementation and expose the data to other applications for quick integration. The idea is to design software architecture around a set of services which are loosely coupled, scalable, reusable and easily integrated. The architecture is called “Services Oriented Architecture” where software can be implemented as a set of loosely coupled and highly cohesive services that may be used by a number of internal / external applications.However, with its advantages there are upfront development costs (time and money) associated with changing the architecture of the software infrastructure and it depends on the nature of the business, the role of IT in the business and the different costs that are required to change the legacy systems whether the company want to adopt the new applications paradigm or not. With that said, it does provide lots of incentives once implemented properly including higher integration options, existence of business process as configurations, higher reusability, a higher degree of compliance with standards ,  increased cohesion within the sub system and decreased dependencies between subsystems Common misunderstandings:Certain level of misinterpretations and misconceptions about Service Oriented Architecture prevail .The primary misconception of this software architecture building methodology is due to a key technology the Web services. The service oriented architecture and the applications that follow SOA are often confused with just the Web services. Some of the common misconceptions are listed below: 

Any application that uses Web services follows a Service Oriented Architecture.

An application that uses a Web service might follow a Service Oriented Architecture or it might not. It depends on the application’s own design, architecture and design considerations that determine its architecture.

 SOA is same a re – branding Web services:Many people think that Services Oriented Architecture is nothing more than a marketing term which might be interchanged with Web services. The important concept they are missing over here is SOA is another Software Architecture that results in the functionality being distributed to many independent Services to better process Business processes.

 Adopting a Services Oriented Architecture Ensures everything can interoperate:It is not necessary that any application that is developed as per the SOA artifacts would be able to interoperate or integrate necessarily with any other component / application or legacy systems. However SOA gives a high emphasis to increase the degree to interoperability by standardizing the Services produced using SOA. 

If you can use a web service with your application you can easily develop applications based on SOA. SOA is the same as distributed computing with Web services. Pitfalls: If there were no potential hazards, problems and everything was ideal with implementing SOA perhaps all the enterprise software today would have been based on Services Oriented Architecture. It depends on the type of functionality, nature of components, exposed interfaces, degree of reusability and working of an application that determines it architecture. Some of the common pitfalls are mentioned below:

 Designing and implementing an application like traditional distributed architectures:SOA is a relatively newer agile application development paradigm. Many of the new Services that implement SOA are designed just like a legacy application that followed a distributed architecture. This would involve Remote Procedure Calls, non standardized definition of services and an improper definition of the function boundary resulting in an increased degree of dependency and lowering the functionality contained in the Service. 

Not making XML the foundation of application architecture:This also has something to do partly with standardization. All applications that follow SOA should conform to certain standards, the foundation of which is XML.Contemporary SOA cannot be achieved if the internal and external interfaces of the Service don’t use XML as a basis. e.g. A key enabling technology in the Services Oriented Architecture are the Web services. Web services are described using a WSDL (Web Services Description Language) which is XML based. Other than that the BPEL (Business Process Execution Language) and some other key components are also XML based. 

 Ignoring the Performance Requirements of a Service:Usually due to the communications overhead performance of applications or Services following contemporary SOA can be below the required level of performance. The message processing time for the service should be reduced by optimizing the code , reducing the number of request / response and it should be made sure that the Service meets the required response times and performance criteria. This can be done by extensive testing (Stress testing) for various input / output conditions. Not making the services secure:

SOA is most likely to be used as architecture for distributed applications. SSL (Secure Socket Layers) is not the security consideration here. The application designers should also consider the WS-Extensions and security frameworks provided by other vendors in order to provide a standardized software design that follows SOA principles.

Now you would ask hey hey hey!! Wait a second: S!! How BPEL, ESB, grid computing and the Business Intelligence do fits in? What the heck are these J I would be happy to explain if you have that in mind.For now just like John Doe who is standing by the coke machine hehehehe understands that BPEL is the Business Process Execution Language, ESB is the Enterprise Service bus and Grid Computing hmmm has many concepts for virtualization? Technically speaking these all are layers of the Architecture we discussed about called SOA and how these are written , mainly in XML yes business rules with xml is BPEL. ESB is where the services are available on one on many services. It can be taken as the medium where the services reside on the www. If you have any questions / suggestions / queries / ideas in your mind do post your comments. Thanks Note: I have taken the concepts of these pitfalls and disadvantages from a book on Services Oriented Architecture(Concept Technology and Design)  by Thomas Erl

Leave a comment

Filed under Software Design

Object Oriented Design – A Class Diagram Walkthrough

Making a Class Diagram with UML Notation – Explained Step by Step:

 Note: Your feedback , issues are warmly welcomed and I would be happy to assist you with any problem you might be having .Class diagrams are often used in object oriented analysis and design to show the various identified objects , their types (classes) , their data and operations and how the relate , or communicate with other objects or classes. Here are some of the standard UML conventions and a sample class diagram to get you started: 

Identify the classes in the problem domain:

 This is the first and most important step for creating the class diagram. What classes should you include and how to identify them given a problem statement or a scenario? The solution is simple and some time should be spent with the client / system engineers /your teacher in case you are making an academic project or any concerned authority having the required business knowledge.The first step however is creating a problem statement or establishing a set of requirements that the software should fulfill. E.g. you need to create a small library management system. What are some of the requirements for the system? Let’s try to make a problem statement or the scenario for your design. For the sake of simplicity considers the following simple problem Statement. “The library management system would be used by the librarian to keep track of books, library members and the borrowing activity. Not all books can be borrowed by the members. Some books may only be available to review in the library; all such books are termed as Reference books. There are 2 types of library members students and college faculty members. Faculty members can also check out research papers and magazines where as students can only checkout books. The system need to send alerts whenever a book that has to be returned within a specific date is not returned. An email is sent to the librarian and the borrower. The system maintains a catalogue having a description of each book that is available in the library” 

Ways to identify Classes:

 Do the Noun Analysis: Go through the problem statement again and again and try to figure out all the nouns that you come across. In our case some strong contenders for the classes of the library management system would be: Librarian,Book,Member,Catalogue,Student_Member,Faculty_Member,Reference_Book,Issueable_Book,Alert 

Perhaps there might be some nouns that I skipped but why??  I did that intentionally because of either of the two reasons. Either there is no data associated with them. They have no role to play in the system i.e. they don’t have any functions or actions associated with them. So by this we mean that “In order for a noun to be an object or a class it should have some attributes or member data and some actions or member functions.

 Resolving the relationships between classes:

Object oriented analysis and design is all about relationships between objects. Look for a certain type of relationships. These include generalization/inheritance/specialization, composition / containership, aggregation/ collections and associations. All of these are explained briefly below and discussed in terms of our scenario. There are some key questions associated with object oriented design over here.  How data is passed between the classes? What classes should have the objects of another class?What classes create the objects of other classes?What are some of the utility classes that the application requires? All these questions play an important role in the design. Think in terms of hierarchy for generalizations/inheritence:First of all check for hierarchy that may exist between the classes or the objects.This would model the inheritance or generaliztion or the superclass/subclass relationship.In natural language this might resolve to “type of” or “can be”. If you find such words in a problem statement there might be a case of generalization. E.g. In our scenario take the three classes BOOK , REFERENCE_BOOK and ISSUEABLE_BOOK . So a book can be a reference book or an issue able book or you can say that reference books and issue able books are the type of books. They all should ideally share many characteristics which are common to all the three classes.What I mean to say is, whether it is any book (reference or issue able) they all have ISBN number, author a language, a topic e.t.c so what is the difference. The difference is implied by the business rule that reference books cannot be issued but only reviewed. So for reference books we might add a Boolean data member called m_bReference and set it to true or something. Same is the case with Member, Student_Member and Faculty_Member. Inheritance is indicated in the class diagram with a filled black triangle pointing towards the base class and connecters connecting it to all the derived classes. In our scenario the inheritance could be shown as the figure below:

 Think of the Part-Whole Relationships:

Ok so now you know what might be the possible hierarchies in your system and what might be the common data members and the common functions. What are the differences and how the qualify to be another class. Another important type of relationship in terms of Object Oriented Analysis and Design is the “Part of” or “Part Whole” relationship. In Natural language, you might come across “has a” words to quickly identify these kind of relationships. In the list of candidate classes observe which of the objects the part of other objects is. This can also be taken as collection.To give you some examples for common scenarios. A Windows form is a collection of many controls.An automobile is composed of many parts.A shopping cart has many itemsA university is comprised of many campuses Here you want to ask a simple question to resolve the type of relationship and to know whether it is an aggregation or a composition. “Is the whole destroyed when the part is destroyed” or “It doesn’t make a difference to the Whole if the part is destroyed”. Now going through this example list. A form would still exist if any of the control is destroyed; the form serves it purpose properly. This implies an aggregation .An automobile wont function properly if any of its parts are destroyed e.g. it cannot function if the tires, steering, battery is taken out so this implies composition. A university will still exist if a campus is destroyed. So it depends upon the scenario and the business rules.

Returning to our depicted scenario the only part whole relationship noticeable is perhaps the catalogue. A catalogue has list of books available in the system with a short description of each. The catalogue is not destroyed if a book is destroyed so I would use aggregation in the design. In UML aggregation is shown with an empty diamond where as composition is shown with a solid black diamond.

 The Uses relationship – Association:

 Many objects use the methods/functions of other classes for utility. The objects are somehow related might be statically or dynamically but there is not a hierarchy or a part whole relationship. Such relationships are called association and can be mostly identified with “makes use of” or “uses” in the problem statement. E.g. There is a class called “Pen” which exposes a method called “Draw ()”. There is also a “Shape” class having a method called“drawShape ( )” . In the implementation of “drawShape( )” it internally calls / invokes the “Draw ()” method exposed by Pen. In our scenario  A librarian uses the book and student information to issue a book.The catalogue needs a reference of the book to add or update itselfAnd probably some more: 

Here is the sample design which I created with Visio just for the sake of discussion and show how relationships can be expressed in UML in terms of object oriented design.The business rules that I assumed for this discussion were really simple just to make the understanding better.If it helped you in any way or you require some discussion in any area do supply your feedback by leaving comments for this post. Thanks.

Sample Class Diagram

       

53 Comments

Filed under Software Design

Database Design Tutorial

A Database Design Tutorial:

There are several different kinds of database representations. An Entity Relationship Diagram or a ER model, an Enhanced Entity Relationship Diagram EER model, Object Relational Model etc. ER Model is the most universally followed database convention at least in my experience with software application development. Any enterprise application today would surely have a database connected to it, so I think that understanding database design and to be able to design databases is a “must have” for Software developers personnel. In this article I would walk through some of the essentials to give you the basic idea by giving you an example. Once you know how it’s done in a “Non Textbook” way I guess reading the text book or some advanced tutorial would be very easy and interesting. 

The First Step in ER modeling: 

The first step in designing the database is to know what are the business objects or so called “Entities”. How to determine what the entities are? The textbook says Read the problem statement or the scenario and try to identify nouns. From a collection of nouns it would be much clearer to determine what the entities are in your system. No doubt it’s a text book approach. I have had very few instances where I had a problem statement and I could do a noun analysis for an object oriented or the database design. So try to think in terms of the business and ask yourself why? This is called the “ROOT CAUSE ANALYSIS”. Ask yourself the question Why the customer wants to develop this system, who would be using the system, what features should be provided and most importantly what data needs to be stored?. 

 E.g. If someone wants to develop an online forum and you have to design the database for them, try to think what a forum does and generate a problem statement. The requirement would be vaguely “A discussion forum has many categories. In each category there are many topics and each topic may have many messages by different users. Old messages (let’s say 10 days old) are deleted automatically by the system. User can post new messages and edit their message” what would the database design be?It is evident with the problem statement that you need to keep track of categories, messages (post) and user. An entity in the system might be a strong or a weak entity. A Weak entity is one which cannot exist on its own in a system and requires a relationship with a strong entity (the one with a primary key) to identify its records. Such an entity is described by a double lined rectangle in the model. What attributes to store? What is a primary key? What is a partial Key? What are candidate keys? What is a super key? How to select them: Simply ask yourself what is the information that the system should store for a particular entity, importantly how that information would be identified at a later time? Is there a way, an attribute which uniquely identifies any record/row/ tuple in the table? What are some of the other important attributes the system has to store?
The answer to these questions would be very important to you in terms of database design. Primarily while resolving the ER model you would be converting all your entities to tables so what are the columns of that table. They are the characteristics of the entity.
e.g. In our scenario what are the important attributes of a User (in this example we only require a loginid and a password but in a slightly complex scenario like a university registration system there might be many attributes like address , phone number , date of birth , previous college , social security etc Similarly what is the data about the categories we want to store (I guess the category name , Description , we would like to know the number of messages in the category and the topic with maximum posts and stuff like that but lets not talk about that here)The set of attributes which can together uniquely identify an entity instance constitute the Super key. The minimum set of attributes (subset of super key) which can uniquely identify a record in the database is called the candidate key. There can be more than one candidate key for the entity e.g. A Student number and the Social security number we use only one as the primary key of the table and the candidate key which we use to uniquely identify any record in the system is called the Primary Key ( The programmer assigned candidate key). Note in case of weak entities the identifying attribute is called the partial key instead of the primary key. 

Step 2 : What are relationships and why? What is cardinality and multiplicity?

 Once you have identified the entities, all of them think of the relationships and the cardinalities or multiplicity of the relationship. For the sake of simplicity check each of the entity against all others in order to clarify the design. Start with the User. How is the user related to Categories? A user can create a new category? If yes then we have a relationship. Then there are 2 things that need to be answered.1.       Can a Single User create more than 1 category2.       Can a Single Category be created by more than one user These two questions are the key to determine the cardinalities which would indicate how we resolve the database design in terms of tables.The relationship can have the following cardinalities: 

·          1 to 1·          1 to Many·          Many to 1·          Many to Many 

Similarly then compare if the user and topic has a relationship. That would be pretty similar to the first one. Now also compare the user with all the other entities.Note that relationship may also have attributes like the date/time when the message was posted etc.Relationships are indicated as diamonds in the design. A relationship with one of the participating entities is weak is called a weak relationship and is indicated with a double lined diamond. Resolving Relationship in the form of physical Database design:It’s a Science not an art J So you can generate the database physical design by pushing a button given the logical design , but the logical design is not a science its an art , thankfully otherwise we would be out of business JJ

 For 1 to 1 and many to many relationships create a new table for the relationship. Include the primary key of each participating entry. The union of all the primary keys which are referenced as foreign keys can uniquely identify any record in the table. So if the cardinality of both the participating entries is the same make a separate table. However if it is not take the primary key of the entity where cardinality is 1 and include it in the table where it is many as a foreign key. This is also called an identifying relationship sometimes. I would talk a bit about the enhanced ER in my next article; hope this would help you in learning the basics of database design.Some good database design tools are Dezign for databases by datanamic, Microsoft Visio, ERWin, Rational Rose and perhaps some other free design tool. If you have any queries, suggestions or feedback I would really appreciate it.This is a sample DB Design for a STUDENT GRADING SYSTEM which is a solved exercise from “Fundamentals of Database Systems” from ELmasri/ Navathe Question 16 and Question 18 Sample ER Model

Here is Question 18 where a new structure is to be designed that holds the previous college info , degrees and courses taken at another college:

Sample ER Model

Note: If I missed an important design concept you were looking for or is there anything you might wanna discuss ? Was this helpful to you ? I would appreciate your comments . Thanks

15 Comments

Filed under Software Design

Remote Software Update Techniques ?

I have worked on various Self Service terminal applications so far . Kiosks for bill payment , Mini statement and balance inquiries and permit printing to self checkout solutions . One requirement that I always come across and I am not absolutely sure how and what would be the better way of solving it is remotely updating software . I want my exes and dlls to be updated and who does it ? Well it can be a windows service or any other application or perhaps a separate thread watching for the updates .

I have some experience with Microsft BITS and i wrote a wrapper for BITS in C# but all i could use the wrapper for was basically file transfer . The object didnt expose some of the core methodologies that Micrsoft uses to update windows or to install windows updates …..

So if you have worked with any such scenario where software can remotely update itself or u have a design in mind do feel free to discuss . I can provide the code whatever i have experimented , but i would really appreciate any ideas / logics or implementation that could help me make a better design for these kind of problems that i often run into … The Software/Configurations Remote update !! If u have the idea and not the time or patience to develope it feel free !! I will develope it for u !! 😀

If you have any experience with making installation patches without hurting the installe application . I have tried Orca editor and the msp files , thats a pain a pain in the back side …. can u think of a smarter way ? Should we write a software which does that ? If you deploy software on a regular basis i m sure you probably might have some idea for a possible work around , I am amazaed why theres nothing from microsoft , doesnt sound that complicated :$

Cheers !!

1 Comment

Filed under Software Design

Comparison Of Pragramming Languages : Have your say ??

1928994504.jpg      java_starting.jpg   cplusplus.jpg

Programming Languages come in all tastes, shapes and sizes with their pros and cons. If you are a windows/web developer you are likely to say Microsoft.Net and if you are an open source inclined (I seriously don’t know why that would be) lolz you might have other opinion. For the sake of simplicity I would discuss the non Web development (server and client side scripting) here and would add on to my discussion in the next article. In the desktop i.e. windows and dos world having worked with C++ , VC++,VB , VB.Net , Java and C#.Net my personal favorite is definitely C#.Net. Definitely its not the best.Let me elaborate it in detail. Microsoft .Net does provide what most of the developers want. An easy way to make/change a clean UI with a great set of controls , a great collection of base classes making the day to day tasks ( File Handling , Database Handling , Exception Handling , Threads and Network programming) very easy , the scalability factor on the existing API and third party controls available , the extensive documentation and working examples that can be found everywhere , isn’t it like a dream come true .

 vb.jpg

I worked with java for some while and figured that the language is really neat , and was programming in the real sense all the way. Many people do argue that C# is more like Visual Basic with more RAD features and drag and drop support. I would say “Yes” it is but what is wrong with that? After all with all the slipping deadlines and nonexistent frameworks that’s what we are looking for. RAD features with great object oriented programming model, easy to implement the design and clean backup implementation. The problem with that however are the Portability/Compatibility issues.E.g. Whenever you want to make a product for the everyday user and publish it on the internet you have to specify that the user has to install X.X version of the framework or else your product wont work . Yes it’s a huge put off for the user and that’s one thing I don’t like about the .Net technologies. I think Microsoft can make it part of windows i.e. all standard Operating Systems by Microsoft should make sure that all the releases of .Net framework available then are installed with the operating systems. That would make the life of routine application software developers extremely easy and without having to give a link for Microsoft website to download the framework it would be simply awesome. The two problems which I find difficult when working with JAVA are the UI support and the integrated development Environment. With UI support I mean there are base classes available SWING and supporting wrapper classes but “Are they really as easy to use as the C# counterparts? No they are not!! At least to me“Now the Java lovers would argue here that there are some good and super cool IDES available like JBuilder, JCreator and Eclipse and specify the fact that they are simply great to implement Software patterns with struts and installing X.XX plug-ins on your specific IDE. What happens with that is you tend to be very specific, away from the general JAVA developer and there is not a huge community to support for your specific programming or development related issues.Same is the case when you talk about JSP and beans. Configuring the web server (Web Logic in my experience) seems to be difficult in itself and there are so many formalities to it which the new developer find difficult to adopt.With that said I would still believe that java has more pros than cons and is undoubtedly more powerful than any other programming language for application software development. It is extremely powerful and with a existing framework of UI and some good utility wrappers you just can’t beat it and Java developers are “No Wannabes”!! . They mean serious business. As far as the support and help from the existing communities are concerned try to Google a specific topic or an exact working example on C# and 8 times out of 10 you find someone in a similar situation discussing the whole issue in a forum, this is highly unlikely with C/C++ or Visual C++ and Java for that matter.  Long story short I guess it’s the requirements which influence the developers or architects to opt for a particular programming language.  Factors affecting the choice are usually Client requirements, hardware interfacing, operating environment, available developer’s expertise, ease of use, development costs, maintenance costs and portability. Anyways these were my views and my opinion totally off course doesn’t make things right or wrong. So if you are an active developer I would love to have your opinion on the comparison and the things on which you might agree or not? What are your views? What is your opinion? What are some of the best technologies, programming languages, development methods or sdks you have worked on ??

4 Comments

Filed under Software Design