Thursday, October 26, 2006

Identifying interactions

[Time 5:50 mins]

In this section we will identify collaborations among the classes as they enact each use case. In this phase we may discover new classes that we had not thought of earlier, as well as new responsibilities for existing classes. We may also discard some initial classes. The process of determining the collaborations as each use case is enacted helps in refining and validating the design.


  1. Customer enters item codes at the UserTerminal
  2. UserTerminal creates Item objects for each item and finds out their individual prices
  3. The UserTerminal finds out all the schemes these items belong to
  4. The UserTerminal determines the Scheme price of all items belonging to a Scheme and adds the individual price of the remaining items
  5. The UserTerminal displays all the above information to the Customer



  1. Customer takes items to the checkout system
  2. Checkout assistant adds item codes in the CheckoutSystem
  3. Checkout system determines the price of all the items, taking into account discounts and schemes
  4. Checkout system generates a bill for the customer
  5. Checkout system accepts the customers payment



  1. The StoreManager uses the ControlPanel to get inventory vauation
  2. The ControlPanel uses the CurrentStock to get the valuation
  3. The CurrentStock object determines the price of every individual item and the price of items and represents it as the maximum price in the PriceRange
  4. The CurrentStock determines the minimum price by associating items into schemes and assuming that they are sold such
  5. The CurrentStock returns the PriceRange object back to the ControlPanel which displays the details to the StoreManager

New classes identified:

  • UserTerminal
  • CheckoutSystem
  • PriceCalculator
  • ControlPanel
  • PriceRange

Note: This post was originally posted on my blog at

Wednesday, October 25, 2006

Identifying responsibilities

[Time 2:04 mins]

Here I have listed classes from the previous post and associated responsibilities to them.

- To shop
- To pay for the items

- Holds an item code
- Has a cost
- Has a price

- Holds a scheme code
- Has a price
- Contains a list of other Items

- Holds the price (for an item)

- Holds the price
- Holds the discount

- Hold the price
- Holds the unit for the price

Unit (and subclasses)
- Specifies a unit
- May have methods for converting between units.

- Checks the audit trail of items sold
- Determines the value of current in-shop inventory

- Contains a list of all items in the shop 

Note: This post was originally posted on my blog at

Refine classes

[Time 6:29 mins]

Now that we have identified some basic classes, some questions come to mind. Let us ponder a bit over these questions. We might identify new classes or remove some old ones at the end.

  • Do we need different types of customers
  • Do we need to represent simple and complex items differently?
  • How do we represent different types of prices?
    • Attributes vs sub classes
  • How do we represent units?
So now we have added a few classes:
  • PriviledgedCustomer (maybe... let me ask the client)
  • DiscountedPrice
  • PerUnitPrice
  • Various Unit subclasses
This is by no means the final class list. As we identify responsibilities and collaborations, we will further refine this class list.

Note: This post was originally posted on my blog at

Identify classes

[Time: 2:00 mins]

Supermarket Classes 

  • Customer
  • Item
  • Price
  • Unit
  • Scheme
  • StoreManager
  • CurrentStock

Note: This post was originally posted on my blog at

Class and communication diagrams

[Time: 7:07 mins]

We have identified classes, their responsibilities, and interactions among them as they enact use cases. Shown below is a class diagram and several communication diagrams that outlines important classes, their relationships, and collaborations among them. I have not shown all the classes, but only the ones that are important and have relationships with other classes. Classes that are not shown include:

  • Customer
  • StoreManager
  • UserTerminal
  • ControlPanel
  • CheckoutSystem  

 Figure 1


Communication Diagrams:

Customer determines the price of a group of items 

 Figure 2


Customer checks out items

Figure 3 


Store Manager valuates in-shop inventory 

Figure 4 

Note: This post was originally posted on my blog at

Translating requirements into system design - A case study

In this section we will take a requirements document for a software system and create a system design from it. The statement for the excercise has been inspired by Dave Thomas' coding kata #1. Let's build a system for a supermarket. Here are the requirements.

The supermarket has various items for selling. Each item has a price. Sometimes an item may have a discounted price, and sometimes it may be part of a scheme. Schemes could be similar to buy two get one free, or buy a certain quantity of an item and get another item free. Items may also be priced for a certain unit. For example Apples may be Rs 40/Kg, however they can be sold in a fractional unit also 500 gms. Some items may be simple, like a can of Pepsi or complex like a crate of 10 Pepsi cans. The sytem should also maintain an audit trail of all sold items for future evaluation.

The store manager should be able to get a valuation of the current stock.

When a shopper checks out items the system should calculate the most optimum price based on schemes that the items may be part of.

Please Note: To keep the exercise simple we do not concerning ourselves with inventory. We only consider items and pricing.

Here are the use cases for this exercise.



  1. Dave Thomas' coding kata's 

Tuesday, October 24, 2006

Your feedback on principles of object oriented design

Please take a couple of minutes to give your feedback on this section. Would you like to see any additions, subtractions, or changes? How did you like the audio and video descriptions used in this section? I know they are not optimal, and I hope to improve them, but it will really help me if I get feedback on exactly what should be improved to make the course more effective for you.

Note: This post was originally posted on my blog at

Monday, October 23, 2006

Using inheritance and composition

  • Inheritance is used for
    • Code resuse
    • To support polymorphism
  • Disadvantages of inheritance
    • Difficult to change the interaface of the subclass
    • Superclass is always instantiated
    • Can get complex and unmanageable
  • Composition is used for code reuse
  • Disadvantages of composition
    • We cannot use polymorphism
    • We cannot extend the system by adding subclasses
    • May have a slight performance overhead
  • Usage
    • Inheritance: IS- A
    • Composition: HAS - A

Example 1

public class Car {

    private Engine engine;

    public void start() {}

    public void stop() {}

public class SUV extends Car{

    public void start() {} //overrides the start method from Car


    public void fourByFourMode() {}


Example 2:

public void someMethod() {

    Car c = new SUV();



Example 3:

public class Car {

    private Engine engine;

    public void start() {


        //maybe do something more


    public void stop() {}




Note: This post was originally posted on my blog at

High Cohesion

[Time: 4 mins]

  • Stuff that goes together, stays together
  • Easy to discover relevant code
  • Levels of cohesion
    • packages
    • classes
    • methods 
So in very simple words, cohesion is keeping related stuff together so we can find what we want without too much difficulty. 


Example 1

public class Student {

    //cohesive methods

    public void registerForCourse() {}

    public void deregisterFromCourse() {}

    viewTranscripts() {}

    //methods below are not in synch with the responsibilities of the Student class

    //hence cohesion is broken

    submit grades() {}

    submitCourseSchedule() {}




Note: This post was originally posted on my blog at

Sunday, October 22, 2006

Loose coupling

[Time: 4:32 mins]

Loose (or low) coupling means (in a generic sense) that an entity can interact with another entity without being concerned with the internal implementation, and through a stable interface. Low coupling is implemented by using principles of information hiding. When two entities are loosely coupled, internal changes in one of them do not affect the other. The calling method is coupled to the called method and not it's implementation. Since we have already discussed encapsulation and information hiding in detail, I will not repeat it here.

  • Loose coupling is achieved with information hiding
  • And by programming to the interface rather than the implementation


Example 1: Tightly coupled system 

public void aMethod() { 

    ArrayList myList = new ArrayList();


private void doSomethingWithList(ArrayList list) {

Example 2: Loosely coupled system 

public void aMethod() { 

myList = new ArrayList();


private void doSomethingWithList(List list) {

  • Loose coupling contains the scope of change when an implementation is modified 

Note: This post was originally posted on my blog at

Saturday, October 21, 2006

Don't repeat yourself

The code says everything once and only once, which is the essence of good design. -- Martin Fowler

[Time: 4:44 mins]

  • Repititive code makes maintainance more difficult
    • There are more places to change
    • We may forget to change some of them
    • Increases probability of bugs
  • Types of repitition
    • In methods in a class
    • Accross the entire software 

Example 1: DRY violated

public class Account {

  public void transferFunds(double amt, Account dest) {

    //transfer funds

    //generate email... create connection

    //create message

    //dispatch email


  public void delete() {

    //delete account

    //generate email... create connection

    //create message

    //dispatch email




Example 2: DRY honoured

public class Account {

  public void transferFunds(double amt, Account dest) {

    //transfer funds



  public void delete() {

    //delete account



  public dispatchEmail() {

    //generate email... create connection

    //create message

    //dispatch email






Note: This post was originally posted on my blog at

Keep it simple

width="290" height="24" id="audioplayer2">



FFFFFF&border=0xFFFFFF&loader=0xAF2910&soundFile=" />

[Time: 5:37 mins]

One should not increase, beyond what is necassary, the number of entities required to explain anything - Occams Razor

  • KISS helps keep software manageable
  • The UNIX kernel is an example of a functionally complex software implemented in simple design
  • Intentional complexity
    • Enthusiasm to use design patterns
    • Enthusiasm to make a system uber flexible
    • Feature bloat
  • Unintentional complexity
    • Maintainance quick fixes
    • Laziness in refactoring


Design principles

[Time: 2:20 mins]

  • What is software design
  • Decomposition is done at various levels of granularity
  • We will focus on some simple principles that deal with classes, their responsibilities, and collaborations.

There are some well known software design principles that serve as guideposts for us in the design process. In this section we will discuss some of the most important principles. AS OF NOW THIS SECTION COVERS SOME BASIC PRINCIPLES. OTHER PRINCIPLES LIKE THE ''OPEN CLOSED PRINCIPLE", "LISKOV SUBSTITUTION PRINCIPLE", etc, WILL BE ADDED IN THE NEXT VERSION OF THIS COURSE.

Something to remember before moving ahead: 

While principles, patterns, heuristics, and guidelines offer valuable advice about how to do things the right way, they don't serve as substitution for thinking on our own. Unfortunately, I think we all too often let these principles, etc. do the thinking for us.

-- Kirk Knoernschild 

Note: This post was originally posted on my blog at

Wednesday, October 11, 2006

Your feedback on goals of software design

Please take a couple of minutes to give your feedback on this section. Would you like to see any additions, subtractions, or changes? How did you like the audio and video descriptions used in this section? I know they are not optimal, and I hope to improve them, but it will really help me if I get feedback on exactly what should be improved to make the course more effective for you.

Note: This post was originally posted on my blog at

You will find below comments from the original post

AUTHOR: Rashmi
DATE: 10/18/2006 05:50:25 PM
Sir could you please explain the difference between inheritance and composition through an example code

DATE: 10/20/2006 01:16:47 PM
Thanks for the suggestion. I will add an example to the blog post. Till then, here is a quick code sample.

//this class uses inheritance. Guitar inherits
//from MusicalInstrument
public class Guitar extends MusicalInstrument {

//this is an example of composition. The class
//Car is composed of several instances of the
//class Wheel
public class Car {
Wheel wheels[];

When a class has other class(es) as instance or class variables then a composition relationship is established between them.
Composition also allows code reuse. In the above example the class Car can invode methods of Wheel thus acheiving functionality without impemented it in it's own class.

Notice the relationship between the classes in both the examples.
A Guitar IS-A MusicalInstrument.
We typically use inheritance when there is an IS-A relationship between two classes.
A Car HAS Wheel(s)
We typically use composition between classes that have a HAS-A or HAS relationship.

now before I wrap up, a couple of questions. Why is it incorrect to use inheritance when there is a HAS-A relationship between two classes. More specifically why should we avoid...
public class Car extends Wheel {}

Here is a very good link that explains the concept in detail:


What about performance

OK, so there is a common myth about performance and good design being contradictory. It is said that we must often sacrifice good design for the sake of performance. Maybe so... but not always.

Good design is about proper decomposition of functional requirements, about proper modularization, non repitition, simplicity, reusability, proper use of inheritance hierarchies, and about containing the functionality.

There is no reason for most of the above to affect performance. However, sometimes we create good design by adding layers and indirection. This may result in extra method calls and perhaps creation of a few more classes. This may somewhat affect performance of the application, but again if the application in question is a web based one, then the performance hit will be negligible compared to the time taken by the web request and database query. However, if we are making software for an embedded device or an application with real time capabilities, then the extra method calls and object creations might hurt. However it is difficult to conclude either way without running a profiler.

So I'd say... first create a good design and make it work. If performance is an issue, run a profiler on the application and fine tune those portions that are the biggest bottlenecks. If in the process, some design has to be sacrificed, so be it. But sacrifice design only and only if it is absolutely necessary, and there is no other option.


  1. DRY Performance 

Note: This post was originally posted on my blog at

And a few more (maybe)

While discussing goals of software design with other developers, a few more potentiall goals came up. They were, robustness, correctness, time to market, staying in tune with team capability, reusability, efficiency, and usability. After some analysis (in my opinion) only reusability passed the test of whether something is a goal of software design. I used a simple test - if we can use design principles like loose coupling, etc to enhance the candidate and if we (almost) always want it as an end result of software development, then the candidate passes the test for a software design goal.

So, as of now reusability defenitely is a design goal. We achieve it by following the DRY principle. Any code that needs to be called accross methods in a class should be factored into a seperate method in that class, and any code that needs to be called accross classes, should be factored into a seperate class. This is reusability from an object oriented design perspective, but it can be taken further by creating reusable components. For example if we are building a web application, in all likelihood the authentication code will be needed by other web applications as well. We make it reusable by creating an Authentication component, by packaging all authentication classes into the same package heirarchy and creating a facade class that can be used by client code. The facade class should ideally implement some standard authentication (or a well thought of API in case a stadard does not exist) API, to enable users to swap it with another authentication component.

Thats it about goals of software design. Do write back with your thoughts, perspectives, and queries. 

Note: This post was originally posted on my blog at

Monday, October 09, 2006

Different aspects of software design

Yesterday while talking about goals of software design with some learning participants, we had an interesting discussion about the various aspects of software design. It is analogous to designing a housing complex. There is the macro level design of the buildings, gardens, club house, and jogging track. Then within every building we design the floor plan and the elevation. Each apartment has it's interiors designed separately. Beyond these designs, we also design the electrical systems, drainage systems, etc. The purpose of each design is different.

Similarly in an enterprise software system, we have various aspects of design. Some of them are:

  1. Enterprise and deployment design
  2. Component design
  3. Class design
  4. User Interface design

Each of these deals with a different aspect of the software system and has different goals.

Enterprise design  addresses high level components like naming and directory servers, application server, messaging server, databases, clusters, high level components and their deployment. The purpose of enterprise and deployment design is to create a deployment that fulfills the performance, budget, connectivity, and scalability needs of the enterprise. An enterprise designed must understand the capability of application servers, databases, clusters and other services such as naming and directory services. He must be able to balance requirement with capabilities and costs. An enterprise designer needs to figure out which components get deployed on which servers and how they interact with each other.

Component design usually addresses using and creating reusable components. While creating a software system, we often have to make build vs. buy decisions for certain reusable components. If we come across functionality that we feel can be reused across projects, then we factor out that functionality into a separate component. Each component should ideally have clear responsibilities which should be represented by the public interface of a facade class. This facade class will serve as the point of interaction for the rest of the software system.

Class design deals with flexibility, extensibility, and maintainability. It is all about identifying classes, assigning responsibilities, and understanding how the classes will interact with each other to fulfill their responsibilities. Here is where we deal with concepts like loose coupling, inheritance, polymorphism, and software design patterns. To learn more about object oriented class design, you can refer to the free (under development) course on object oriented analysis and design hosted on our site.

User Interface design addresses usability issues of a software system. Through usability design we ensure that the user interface is intuitive and easy to use. It should be easy and quick to do common tasks, and impossible to do things the user is not allowed to do. It should present information in a way that is easy to use.

All of these are various aspects of software design. Each has a specific goal and a process to achieve good design. 

Sunday, October 08, 2006

Should all learning professionals be blogging?

Recently Tony Karrer asked on the learning circuits blog: Should all learning professionals be blogging? He also encouraged people to comment by posting on their own blog, a concept that Stephen Downes thinks is a huge advance. If you have been following this blog, you will remember that I have been encouraging readers to post their perspectives on the course material in the learning section, on their own blogs, and informing me about the post.

Well, here is my response to the question.

What learning professionals should be doing is this:

  • Staying up the learning curve on technologies that affect them
  • Reflect on their learnings to gain a deeper understanding
  • Share these reflections with others to validate their ideas
  • Have conversations with other professionals to share their knowledge and learn from others
  • Manage the knowledge base of their reflections, resources, etc

Writing works wonders for reflecting on concepts. I cannot stress enough, how useful the process of writing is for reflection. Communication and conversations with peers can happen in a variety of ways: water cooler discussions, phone conversations, emails, forums, etc.

What is important is reflection and conversations, and blogging seem to bundle both in a very easy and effective way. People can reflect over a concept and write a blog post. But it doesn't end here. Conversations are spawned by readers who write a response on their own blogs and trackback to the original post, or by commenting and querying on the authors blog. With the possibility to integrate audio, animations, and slide shows, we have an even richer way to publish and communicate.

So, blogging is all about publishing, communicating, and creating an informal network of peers, and a community of reciprocal learning. That is why it is so important.

My conclusion: It is important to reflect and communicate, and at the moment blogging seems to be the best way to accomplish both. Till we have a better option, I'd say "Yes, all learning professionals should blog"

Perspectives from other learners/bloggers:

  1. Stephen Downes
  2. Geetha Krishnan
  3. Dave Lee 

Notes: This text was originally posted on my earlier blog at
Here are the comments from the original post

AUTHOR: Tarun Chandel
DATE: 10/19/2006 09:24:48 AM
Hello Parag sir,

First of all I must thank you for this site. It's a nice way to get to read about your thoughts. Blogging is a nice thing but has it's limitations. Blogging is essentially like a diary which is up for everyone to read. Blog is best place to express your views about something and other person can get an insight into your thoughts.
If we try to use blogging as a place where various people can come together to share and learn then it is not that great a medium.
For that kind of collaborative experience we need to have something which can help the users communicate with each other and as a group more effectively. A customized Social Networking site can be good solution, but again that will need a lot of work and nothing great is available off the shelf as of now.
I have also tried using blog for various different situations but it is not that great a solution. Blogs I find are very helpful in case you want to express your personal views on any topic.

DATE: 10/19/2006 12:15:01 PM
Social networking sites are good because they give a common platform to a community. But if you think about it the Internet is the common platform.

The biggest issue with social networking sites is that they form a closed community. Those who are not part of that community cannot participate. For example if you have your profile on Ryze then you cannot connect to those who have their profiles on LinkedIn.

Managing multiple accounts can be very tedious. Personal webpages, wikis, and blogs work wonders here, because they use the Internet as the medium. I can connect to you through your blog, without being a member of a community. This is very powerful, because it lets people connect and collaborate without the annoyance of signing up with a particular community.

Probably tools that can map and manage conversations accross multiple blogs will be very useful to view a conversation in entirety. Not very sure how it can be achieved though.

At the moment we can use blogs to establish conversations, disseminating information (product, etc), sharing perspectives, best practices, etc.

Forums work out better for solving specific queries.

Podcasts are also a very interesting medium. They are being used for learning, as well as a replacement for international conference calls in some companies. Podcasts work very well because they transcend time zones. People can listen to them when it is convinient and yet communicate on a common platform. Again that common platform can be a blog for that podcast.

Grassroots journalism is another important application that blogs are being used for.

I think we have probably just scrathed the surface for blogging applications. In time to come there will be many more creative uses of blogs.

Would like to know what you think.


AUTHOR: Ranjan
DATE: 10/27/2006 02:26:40 PM
Hi Sir

I was following your and Tarun's discussion about blogging and I just wonder did we had this kind of discussionn while were in classroon :)

According to a blog is created every 7 second, more than 70000 blogs are created in a month and presently there are more than 25 million blogs!

The porpuse of putting this stats is that people are using the internet to 'upload' contents which is a big change,the internet is becoming more collaborative in nature and blogging makes the nature of information 'open source'; blogging is the best example of 'open source journalism' as some of the breaking news are provided by bloggers rather than 'professionals'.

Learning professionals should be blogging as they get wider audiance and the discussion become more open. As you rightly said it helps in reflection, the amount of research work that is needed before putting up a post is high as your voice is being heard and commented upon by wider range of people.

I wonder if you can invite more people on this blog to write article, the blog will become more intresting. Maybe you can add some of them as memebers to this site and ecourage them to post articles, this way the audiance will get more people to lsiten to and comment.


DATE: 10/28/2006 09:51:00 AM
Hello Ranjan,
I agree, open discussions are very important to learning and generally broadening the perspective. Getting other people involved on this blog is a very good idea.

In fact I have been thinking to extend this initiative with a podcast station, that will focus on core software skills. I plan to invite several experienced people from the industry to share their knowledge on the podcast. Will post details on this blog as soon as I have thrashed out the details.

Thanks for the suggestions.


Half an Hour: Should All Learning Professionals be Blogging?

Recently Tony Karrer asked on the learning circuits blog: Should all learning professionals be blogging? He asked readers to comment on their own blog. Here's my perspective.

Sunday, October 01, 2006

Live Web Based Training

A couple of days back, we conducted a training session for a client over the Internet using collaboration tools like Vyew, and Skype. An account of the details is posted on Webcast Academy's website (where I am an intern in the class of 1.2).

Below is a summary of the discussion, posted as a podcast.

[Time: 3 mins 15 secs]

What are your views on online training? Feel free to write to me if you would like to try something similar for your organization.

Notes: This text was originally posted on my earlier blog at
Here are the comments from the original post

AUTHOR: Ranjan
DATE: 10/03/2006 12:02:34 PM
Hi Sir

I totally agree with you on this,Infact Sun's philosophy while marketting(I hope I am using the right word) java was " Write once, run anywhere"... obviously Sun was promoting a feature over here.
Infact Software portablility has more todo with Microsoft Vs Others fight and Java was one of the first programming language which gave portability a serious thought and provided APIs where software programmer has to bother less about it at the same time.

Here is one of the articles on java portability:


DATE: 10/03/2006 02:22:46 PM
Hello Ranjan,

That's a nice link. A must read for someone who wishes to understand what the team at Sun had in mind when they designed the Java language.