Learn Software Development » Design

Computer networks: What is meant by two tier architecture?

ashish — Wed, 22 Feb 2012 17:10:51 +0000

You might have come across the terms “1 tier architecture, 2 tier architecture and 3 tier architecture or application”. But what does these terms actually mean? A lot of people mention these terms, but don’t really know too much about these. In this article, we have discussed in detail about the two tier architecture. However, to understand the 2 tier architecture you first need to understand the concept of client-server model. So let us start on it. A client-server model as the term itself suggests can be thought of as a type of computing model. This computing model works as a distributed application making a data link between the clients and servers.
A server is a typical resource and service provider whereas the client is the one makes a request for a service or a resource to the server. The location of the client and servers or the distance from each other does not matter, since they are said to be present over the same system, once they are connected via the client server model. The communication between the servers and the clients takes place through the computer network established through the internet and on different hardware (but in most cases, this connection can be made securely if required). A computer serving the requests of the clients is called a host or more commonly called a server. These resources are shared among the several clients that may be located worldwide.
In contrast to the server, no data or file is shared by the clients. The communication thus is said to be initiated by the clients. There are several functions that are built on this model of client and server like:
1. Web access
2. Email exchange
3. Data base access etc.
The client server model presides at the heart of this whole computer networking system. Most of the web applications being built today are based on this model.
However, this is not the same as a two-tier architecture. Now let us discuss about the two tier architecture of the applications. The two tier architecture was developed as an attempt to improve the model of the file server application programming. The benefits that the two tier architectures includes scalability, flexibility and usability. As the term “2 tier architecture” itself suggests, it constitutes of two layers or tiers (“tiers” is more appropriate word):
1. Server and
2. Client
The applications built with the 2 tier architecture system usually have a user friendly graphical user interface as compared to the applications employing other types of architectures. But there are also some limitations of this architecture. It does not permit a large number of users to use the application and also the sharing of data can be done only within the homogenous environment and not outside that environment. The two tiers of this architecture have physical separations which are mainly process boundaries, machine boundaries or corporate boundaries. The two tier architecture application is a combination of the client application and server application. Since there is no intermediate application between the two sides, the communication takes place directly. Particular business logic is often incorporated at either side resulting in fat client or fat server accordingly.
The application programming interface or API forms the link between the data base and the client. 2-tier architecture is very cost effective since it requires less deployment cost. If any change is made to the data base of the application, accordingly the modifications should be done in the client side application. If n numbers of clients are connecting to the data base there will be n number of individual data base connections. The two tier architecture is usually used in the development of the localized applications, where the users are all located in a geographic location, and the server processing their requests can be placed in the same location.

Computer Architecture, Fifth Edition	Computer Organization and Design	Digital Design and Computer Architecture

Software Design: What is meant by three tier architecture?

ashish — Tue, 21 Feb 2012 15:13:18 +0000

Three-tier architecture has been making waves for some time now ! But a lot of the people who talk about it are not aware of the details of this architecture. This article is going to try and explain this new beast called three-tier architecture. To understand the three tier system we first need to understand a more and earlier term i.e., client- server model. No doubt it is a type of computing model, and it plays the role of the distributed application among the clients and the servers. The basic role of the client server model, apart from providing a link between the client and server, is to divide the workload that exists among the servers (the computers the network that are responsible for providing resource and services to the clients) and the clients (one who initiates request from the server for resources and services and which interact with end users whereas the servers are never exposed to users).
The communication that exists between the clients and servers has been possible only because of the computer network. It is implemented on different hardware for both the client and server side. Even though the client and server might reside in different physical regions of the world, they are said to be in the same networking system. The server runs the server programs and is responsible for making available the services and resources that are requested by the clients. Because of this, a server is often called a host. There is only one way transfer of data from the server side. There is no file sharing from the client side. The client is responsible only for initiating the request. In such an architecture, the server should have a high capacity for handling multiple users at a time with heavy processing requests.
The relation between a server and a client is defined by the characteristics of that particular client server model. There are many web applications that implement the client server model in their architecture like:
1. Web access applications
2. Data base access applications and
3. Email
The client server model has been possible because of the presence of a strong network. It is not only software applications, but even many protocols also make use of the client server model like:
1. Telnet
2. DNS
3. SMTP
4. HTTP
Now let us get some details on the three-tier architecture. It consists of three layers and these layers are also called tiers.
1. 1st tier: Client front end: This end is responsible for generating the requests for the resources and the services.
2. 2nd tier: Business logic: Business logic is nothing but the protocols implemented during the processing of the requests. They can be implemented on both the client side as well as the server side. When it is implemented in server the server is called fat server. Similarly when it is implemented on the client side it is called fat client.
3. 3rd tier: Data base back end: This end is responsible for holding the data and responding back to the client side i.e., providing the service requested for.
Nowadays most web applications are using this three-tier architecture. The communication between the server and the client is established through the application programming interface or API. In a three-tier architecture, separate servers are used for the application and the data base. The middle tier is placed between the client and the server so as to control the excess burden on the server. Therefore it forms an intermediate junction between the client and the server and controls the incoming requests and the processed out going requests. Three-tier architecture is a means to enforce the separation between the 2 layers. Three-tier architecture has proved to be a cutting edge in networking technology as it has made the communication faster and more reliable, enabling the building of better and stronger web applications, capable of handling huge requests.

Computer Architecture, Fifth Edition	Computer Organization and Design	Digital Design and Computer Architecture

What are use case diagrams and their role in software development processes?

ashish — Sun, 19 Feb 2012 17:54:48 +0000

Use cases are nothing but a series of steps formalized to achieve goals as defined by the stake holders. The use cases are said to be at the heart of the unified model language or UML as it is known in the abbreviated form. There are total 9 diagrams which comprise the unified model language (UML). The use case diagram is considered to be at the top of the list and drives the remaining 8 diagrams. The use case diagrams defines or displays the relationships or the interactions of the software system with the user and the other systems. The use cases are meant to show the requirements of a software system or application with the help of the structured text as well as the graphics. The requirements which are depicted by a use case diagram are usually functional requirements.
All the use cases are documented with a use case diagram. The textual part of the use case along with the use case diagrams form what is called the “use case model”. The use models as a combination of the text and use case diagrams tell us about the functions that the particular software system or application is supposed to carry out. Use case models also describe the surroundings of the use case i.e., the actors and the interactions occurring between the actor and use case rather than just depicting the functions.
Use case modes provide a measure to the program developers to communicate with the software system or application. To put it simply, a use case model acts as a tool to describe the functionalities of a software system or application. In a typical unified model language use case diagram, the trading manager is responsible for setting the limits for the use case and the accounting system is responsible keeping the accounts updated. It is the responsibility of the actor to analyze the risk, fix the price of the deal and capture the deal. This all forms a part of the valuation process. If in case the use case exceeds its specified limits, it is extended.
UML based used case diagram are in a way a natural means for expressing the requirements of a software system or application. The use cases are still under research for signs of improvement. There is a need for some measure to evaluate them. Enhancement of the use cases is the basic initiative of all the research work going on and there is a hunt for a more sophisticated methodology for managing, specifying, verifying and building the requirements of the software system or applications which are by nature object oriented. Apart from all this the research is aimed at the identification of the quality attributes of the use cases like validation, risk indicators and use case metrics.
A use case is usually analyzed based on these three factors. The result or the outcome of a use case should be visible to the actor. It would not be wrong to say that the use case diagrams are a combination of both the structure diagrams and behaviour diagrams. A use case diagram tends to show how actually the interaction between the software and environment takes place or how the software systems are able to collaborate with the users. The use case diagrams have been stated as the special case of the class diagrams in the unified model language. A requirements use case tool or RUT has been developed as a tool to assist the developers and the customers with the assessment of the quality of the use cases.

Use Case Driven Object Modeling with UMLTheory and Practice	Advanced Use Case Modeling: Software Systems	UML 2 For Dummies

How to incorporate UI design as part of Scrum work, collaboration between Product Owner and UI Designer

ashish — Tue, 18 Oct 2011 19:16:37 +0000

If you want to ensure that your product / software application is successful, there are a number of things you need to care of. If you look at the success of many of Apple’s products such as the iPod, the iPad, iTunes, and the iPhone, it is about ensuring that your workflow appeals to customers, that they find using it so easy that they are even willing to pay a premium for such products. What this brings out is the importance of ensuring that you have workflows that appeal to customers, and this means that you need to get your UI designer into the product development process. However, it is not easy to integrate the working of processes with the working style of UI designers. In my experience, getting them to work with the kind of deadlines and schedules that you can impose on engineers and QE can be a difficult task, and this process can interfere with their creative juices.
So, what happens in the case of Scrum ? Well, for Scrum work, we typically say that features should be worked upon when you get close to the Sprint, since that is when the prioritization of features for a Sprint actually happens. However, when the sprint starts, the team starts working on the tasks, which means that the UI for those tasks should be ready. Which automatically means that the UI for tasks should start before the Sprint planning activities (seems a bit strange that some activities for tasks should occur before the Sprint in which the task should be worked on, but there is no other way to get the UI in place).
For this to happen, it is also necessary that there is a parallel planning process underway, whereby the Product Owner has a list of prioritized tasks (already there as part of the Product Backlog); with the difference being that the tasks for the next Sprint should be confirmed during the previous Sprint. In addition, there should be a schedule in place which tracks the work being done by the UI designer, and this planning needs to happen with the Product Backlog, so that it should never happen that the UI designer is getting too many tasks. If this happens, then the UI will not be ready when the team is starting work on the tasks in the Sprint.
So, in the Sprint before a particular Sprint, the Product Owner, one or 2 assigned team members, and the UI designer should be working on a list of tasks for which the UI is required at the start of the subsequent Sprint, and should aim to get a high level workflow document and a UI wireframe in place. Once the actual Sprint starts, the Scrum team will start working with the UI designer to get the final UI based on the User Stories outlined by the Product Owner.

Problem in Scrum: Looking at technical debt, which will cause more problems as you move ahead ..

ashish — Tue, 04 Oct 2011 14:24:11 +0000

What is technical debt ? Well, I will not try and give a definition for technical debt. Instead, consider that you have 2 approaches to build some great new features. You can do something in a quick way without trying to build a great design, or you can build it the proper way through the required design. Now, if you need to get features done quickly, then trying to build in the proper design and architecture can stretch the possibility of getting the features done in time for the need (say, if the team is under pressure due to market requirements, or due to external stakeholder pressure). In such cases, it is a business need to build the feature done quickly enough, but one of the problems of taking such an approach is that you need to build a structure in order to build more and more features, and as you neglect the design work, building features becomes even more difficult. To put it in another way, in order to save some time in the beginning, you spend more time later. This is what is called technical debt.
In the case of the Scrum process, what I have seen in practice in many teams is the concept that because of the pressures, because of the way that the team seems to work from a Sprint to Sprint, the tendency to think about architectural change can slip by. The whole team is driven through a process whereby the Product Owner defines a set of features, prioritizes them, these are broken down into discrete tasks and estimated and then implemented by the team. There can be a lot of pressure to ensure that the teams are delivering a set of features on a regular basis; further, people are occupied on ensuring that all the features are delivered on time. It can get pretty difficult to insist that architectural tasks are delivered, since there can be a lot of resistance to putting these tasks into the Product Backlog. It would typically need somebody of the stature of an engineering manager to have those discussions with the Product Owner, to explain the need to put in the engineering time for putting in design for building for more features. It can be difficult at times, and in our case, it took us a few months and one round of feature failure to explain the engineering design process in detail to the Product Owner, and now we are in such a condition that the Product Owner totally understands when we push for some architecture work. However, it can take time for the Product Owner to be comfortable with these details.