Posted by: ahmedashfaque | June 3, 2015

Software design fundamentals – What is component diagram?

In the previous post we have seen what is a use case and how a use case is related to a component diagram. Today we will learn about component diagrams and how they are related to classes.

A component diagram is based on use cases. For example we can create a component diagram based on the use cases we had seen in the previous post about a order management system for a restaurant.

  1. The sales rep logins into the order management system. –> we can create a login page for the system.
  2. The sales rep takes customer order. –> We can create an order page.
  3. The sales rep confirms the order. The system comes up with the amount to be paid by the customer for the order. –> We can create a confirmation page.
  4. The sales rep collects the amount from the customer. –> We can create a payment page.
  5. The sales rep delivers the order to the customer. –> We can create a delivery page.
  6. The sales rep closes the order. –> We can create an order closing page.
  7. The sales rep logs out of the order management system. –> We can create log out page.

A page (a web page or a user screen) is easy to think about when you create corresponding pages for each use case. You can already see it in the above example. A page is a component in software designing. Once you are able to design components, designing other component level diagrams is easy. Generally drawing a data flow diagram is enough at the component level.

The next level of software design deals at low level or detail level software designs. It is at this level that you need to provide complete details about each component of your software product. This level is the class and object level in object oriented programming. This we will learn in next post.

One more aspect about component level. Since software development field is a relatively new field, there are no established engineering processes which can be applied during software development. This area will mature in future when more domain knowledge about software product development is acquired. However there are some standard templates which have been developed by software industry for component level design. This area is known as software design patterns.

Software design patterns can be used as templates to develop a component level design for a software product. For example there is a template for creating model view controller architecture based software product. So you need not have to create this architecture from scratch and instead can use this template to build your software product. There are many such templates available.

Posted by: ahmedashfaque | June 2, 2015

Software design fundamentals – What is use cases?

When you write requirement specifications, you also create use cases. These use cases describe how a system should behave to interaction with agents like the user or another software products. In reality these use cases are simple explanations of behavior of the system against events which are triggered outside but have effect on the system under consideration.

Even though Use cases belong to requirement specifications, they can be considered as the first building blocks for designing a software product. It is because the use cases can be the input for creating software component diagrams. Use cases are described in terms of some simple diagrams and also in form of some text explanations.

Suppose a series of use cases describe about activities carried out by a sales representative of a restaurant in regard to taking orders for customers. Let us see some of the activities here.

  1. The sales rep logins into the order management system.
  2. The sales rep takes customer order.
  3. The sales rep confirms the order. The system comes up with the amount to be paid by the customer for the order.
  4. The sales rep collects the amount from the customer.
  5. The sales rep delivers the order to the customer.
  6. The sales rep closes the order.
  7. The sales rep logs out of the order management system.

The above activities are use cases for the order management system. Now if the software designers are handed this set of use cases then they definitely will be able to create a component diagram for the order management system.

So you can see use cases are powerful tools for designing software products.

Posted by: ahmedashfaque | May 19, 2015

practical considerations for software testing – 3

In my previous post we had considered the challenges of unit testing where databases are involved. In this post we will see how to overcome those challenges.

The first challenge is about the fact that a database is an external entity. You can only manipulate a database if you have a connection with the databaase. For any reason if the connection with the database gets broken then you can not do anything with the database. This means the first thing you need to do is to test if a connection with the database is available and it is working. This kind of testing is essentially an integration testing and not a unit testing. Once your database connection test passes then you can write a query which will do some data manipulation in the database. This query will actually change data in the database. On a software project, lot of database testing is performed. This may result in lots of testing data will be created and manipulated in the database. This is not a good practice.

A better approach will be to create a record containing test data in the database and then delete this test data once your testing is complete.

When you follow these principles then you can do your unit teesting with database comfortably.


Posted by: ahmedashfaque | May 17, 2015

practical considerations for software testing – 2

In my last post I had promised I will discuss testing techniques. Today I will discuss testing database manipulation if it iss part of a class and you are doing a unit testing of this class.

When you test a business logic, you test if the computation done inside a class through some method, the computation is correct. For example, if you need to compute correct interest rate for a fixed deposit in a bank in your class using a method then you store values for the principal amount and given interest rate and then do your computation and find out the accrued amount after the interest calculation is done.

If you are testing this class and its method then you will give various values for principal amount and interest rate and find out if the class is doing correct computation and giving you correct results. Suppose the interest rate to be calculated comes from values stored in a database table then what kind of challenges you will face and what kind of strategies you will have to make to overcome those challenges?

If you ever have done a database testing stuff for your classes then you must be aware of the challenges. For novice testers, let me stress that there are indeed many stiff challenges in this task. Some of these challenges include:

  • To manipulate a database, you first need to have a connection and only then you can do any database manipulation. This means that you will first need to do an integration test in form of testing the connection with a database and only then you can perform a unit test.
  • Database is a separate entity and not part of the software system you are testing. This fact again implies that what you are going to perform is actually not a unit test but some sort of an extended test. When you are testing business logic for your class, you are also testing the database structure at the same time.
  • Databases carry a permanent data structure and thus have a different behavior compared to the software component your class belongs to. During execution, data inside a data structure of the software component (e.g. the data structure of the class itself) experience value changes. But after execution, data inside these data structures get reset. For example, suppose you have a variable ‘a’ in your method and you assign it a value 5 during execution. After the source code execution completes, value of this variable will become NULL as the object which was carrying this variable will be destroyed. But if you change value of a field in a database during testing then this change will be permanent. For example if you changed first name of an employee from ‘Alan’ to ‘Keith’ in a database table then this change is permanent. Now if you query the database to find first name as ‘Alan’ then you will get an error because the name is ‘Keith’ and not ‘Alan’. This fact has a profound impact on the way you do unit testing.

In my next post I will show you how to tackle these challenges.

Posted by: ahmedashfaque | May 16, 2015

practical considerations for software testing – 1

As people in the software industry realize the importance of testing, there is no way, testing functions can be minimized on software projects. However unnecessary testing will lead to only waste of time and money. So how to ensure that the software product is tested effectively in least time and yet achieve good results?

Most project managers find it difficult to allot resources for testing at early stage of the project. They think that first they should have something developed so that it can be shown to customers and feel satisfied that they have been doing something worthwhile and the effort is visible. How wrong is this thinking?

Off course people are always hard pressed to show results as early as possible. This is only possible when they have something to show. If the project manager first thinks about testing, allots resources and tries to ensure no defects are injected in the software product being developed then he/she has something less to show to the customer as development will be lot slower. This is one factor which goes against early software testing.

But smart and experienced project managers know better. They are able to justify their early deployment of testing functions using charts to show if they don’t go this way then what bad effects will be expected later on. They will be able to convince the management and the customers that the overall time required for completion of the project will be much less if they deploy testing early in the project. It is because fixing defects later results in more defects enteering in the software product due to multplying effect of one defect passed on from say a defective design into many defects developed in the construction later.

In test driven development, business logic is tested first using unit testing before a class to implement that logic is written. This ensures that the business logic will be correctly implemented and chances of defects due to faulty business logic will be much less. Imagine if you have not done any testing at unit level and built your components. Surely at system level you are going to find defects which will be lot more. When you did testing at unit level, you ensure that chances of defects at system level will be lot less. At system level, many untested classes developed by developers will lead to so many defects that testing and removing them will take lot more time compared to when each class was tested and defects removed at unit level.

In my next post I will delve on benefits of testing techniques.

Posted by: ahmedashfaque | May 12, 2015

How to create data model for your application

In the good old days, creating an Entity Relationship (ER) Diagrams used to be a cake walk. You get your data requirements from end users and lo and behold you had everything to design your database using ER diagrams. Not any more. The reasons are too many. But the most important one is that your data model can not be converted into an ER diagram easily.

In 1980s and even up to 2000 or so, most software projects involved developing a database management system. These systems were also used to be known as Electronic data processing (EDP). These systems primarily were driven by a relational database at the back and some front end which would show and manage data in user forms. Most often there used to be a direct relationship between the user forms and the database entities like tables. Thus it was easy to take your ER diagram and build a system based mostly on your ER diagram.

Cut to present! Most software applications being developed today have sophisticated user interfaces. These applications are web based. These applications show many things at the user interface. They also do many things for the user. But all these things are not directly related to what is stored in your database. For example, a social media website allows its users to chat with friends, like a post, make friends, unfriend a friend etc. None of these features are driven solely by a database. There is something more involved apart from a database here.

This translates to a single fact that your fromt end is not directly related to your database. Thus your ER diagram alone is not sufficient to design your application.

The best approach to these kinds of software products is to use a data model which is a mix of databases and temporal data. Databases will hold the permanent data and temporal data will be present in short memory storage like RAM. The temporal data is managed by creating objects which hold their data till it is saved in the database.


Posted by: ahmedashfaque | May 9, 2015

database table joins

We all have heard about relational databases but do not understand from where they get their power. Let us understand why relational databases are so powwerful.

Everybody uses spreadsheets. They are neat and allow you to store information in a structured way. You use them to store customer information. You use them to store contact details of friends. In fact spreadsheets are so common and popular that they are used for many purposes by many people.

Spreadsheets are good for storing small amount of data. Imagine if you need to store data which is in the range of millions of records. Can you do it on a spreadsheet? Definitely not. A spreadsheet can store information as much as some few thousand records but not more than that. What are some other limitations of a spreadsheet?

  • searching records through a spreadsheet is difficult
  • searching records through a spreadsheet takes time
  • retrieving data from a spreadsheet and using it in some other application is difficult

When it comes to storing, retrieving and managing huge amount of data then relational databases have no match. The power of relational databases comes from their ability to store data kept into many places and when required then retrieve this data at ultra fast speeds. When you store your data in a spreadsheet, you are storing your data in a flat file. But when you store your data in a relational database you are storing your data in a 3 dimensional space.

A relational database is known as relational because it allows to create relationship among tables and entities. Storing data in the most minutest level and then aggregating them when retrieved allows a relational database to make powerful information processing.

It is the ability to create relationships which allows a relational database to store vast amounts of data in a single database. These relationships also allow data to be stored in such a manner that the data integrity and referential relationships are always intact. No redundant data and no inconsistent data is possible when a relational database is designed carefully. So for instance a large company can store all its mission critical data in a relational database no matter how large this data can be. And yet all this data is safe and when required, any data can be retrieved at ultra fast speed.

Indeed there is no match for a relational database when number crunching matters.

Posted by: ahmedashfaque | May 8, 2015

What is a model-view-controller architecture?

You may have heard about model-view-controller (MVC) architecture but may not have idea about what it is or what it does. Let us understand MVC architecture.

Suppose you are using a software application (e.g. a website). On a web page or this website you need to fill out a form and then submit it. After you submit this form, the database attached to the website will store the information you submitted. Later when you want to see the information stored in the database you can go an edit page and you can see your information and you can even edit it.

What happened in that scenario is that the of the website had collected the information from the user interface (browser) and sent it directly to the database and the data was saved in the database. Simle and straight!

Now imagine you had gone to a website where there was a webpage where you need to make some selection (using radio buttons or selection boxes for instance). From that page you navigate to another webpage and do some more stuff. Now you want to go back to the previous page and see if the selection you made were correct. As a general rule, once you move away from a webpage, any changes made by you on that page should be lost. But you are surprized that the information you selected on that wwebpaage is still there even after you had moved away from that page. The information you selected on this wwebpage was also not saved in the database either. So how this information was still available on that page?

The magic done here is by using MVC. MVC architecture consists of a model, a view and a controller. When a user makes some selection on a webpage then a controller component of the software application stores this information. As long as the user does not submit any information (using a submit button for example), any user selection done on any webpage is saved in the memory through the controller component. Only when a user submits the information using a submit button then the controller directs the model to do computation and also to save information in the database. When the model does this part of computation, it informs the controller. The controller then creates a view and then sends it to the user interface. The user will see the processing for the information he/she submitted.

MVC is used extensively for wewbsites. Using MVC, websites are able to provide persistent user selections even when the users keep browsing a website.

Software designers often wonder how to create the software design so that the software product built on this design looks all zazzed up and works wonderfully.

Even though software designers get full idea about the overall software architecture from the requirement specifications. They fully understand how the software product will look like at this stage. The problem arises when they have to drill down and find out how many classes they have to build to capture all aspects of requirement specifications. So here is a discussion on this topic which may help software designers to build great software products.

When I think to design a software product, obviously my first inspiration comes from requirement specifications. Requirements specifications give me all the details to build the software design. Generally I first think about what data I need to keep in my database. So I first design my database tables and their relationships. Entity Relationship diagrams (ER Diagram) come handy here. So I build my ER diagrams and my database. Only when I am confident about my database, I think about other aspects.

If the software product does not has a Model View Controller (MVC) Architecture requirement then I will create my classes directly related to my ER diagram. Thus my ER diagram is good for both building my database as well as my middle tier components.

But suppose your software archiecture has to be MVC based architecture then what you will do to create your classes for your middle tier? Well in this case, I will find out where and what are the differences between views and models in my MVC architecture. For example suppose the user has clicked a navigation button on the user interface and some user selected entries have to be memorized which were done prior to the navigation then a difference will occur between the view and the model when user wants to see selected entries later. Afterall the selected entries were not saved in the database and you have to provide a mechanism to store them in a temporary memory. This is where your ER diagram will differ from your class diagrams.

To take care of this difference, you need to build your classes accordingly.

Posted by: ahmedashfaque | May 5, 2015

integration testing for software products

software products are composed of many components. All these components are made of classes in an object orietned programming language. These classes are linked with each other through method calls. Each class provides an interface through which these methods can make or receive calls. Through these calls classes are integrated with each other.

It is important to make sure that integration of classes works otherwise the software product itself will not work. So you ensure that integration of classes are done properly?

Integration of classes is checked using integration testing. Design documents depict relationships of classes with each other. Each method call with paramters and datatype of each parameter is defined in a design document. Even object diagrams are also provided which determine the sequence of these method calls. When you do integration testing then you ensure that these method calls work correctly and thus classes interact with each other without any problems.

Strictly speaking, integration testing is not done explicitly. When you integrate your code with the main build of the software product and you find that there are compile issues only then you know that there are integration issues with your code. Integration of classes with each other is mostly about the method calls. If a class which receives a method call does not provide a proper interface then you will have integration issues and your code will not compile with the main build. The problem could be wrong parameter data type, wrong data type size etc. So such types of integration issues are essentially due to interface problems.

In some cases where a class has many method calls, it becomes difficult to find integration issues if they arise. In those cases, the class can be broken down into smaller classes. Each class can then have one method to test and thus it becomes easier to do testing.

Integration testing is purely technical in nature. It does not test for business logic. Business logic is always tested during unit testing.

Test Driven Development is a great environment for ensuring that your software product does suffer due to integration problems. We will cover test driven development in our next post.

Older Posts »



Get every new post delivered to your Inbox.

Join 109,581 other followers