Skip to main content

Posts

Showing posts from October, 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. CUSTOMER DETERMINES THE PRICE OF A GROUP OF ITEMS: Customer enters item codes at the UserTerminal UserTerminal creates Item objects for each item and finds out their individual prices The UserTerminal finds out all the schemes these items belong to The UserTerminal determines the Scheme price of all items belonging to a Scheme and adds the individual price of the remaining items The UserTerminal displays all the above information to the Customer   CUSTOMER CHECKS OUT ITEMS: Customer takes items to the checkout system Checkout assistant adds item codes in the CheckoutSystem

Identifying responsibilities

[Time 2:04 mins] Here I have listed classes from the previous post and associated responsibilities to them. Customer - To shop - To pay for the items Item - Holds an item code - Has a cost - Has a price Scheme - Holds a scheme code - Has a price - Contains a list of other Items Price - Holds the price (for an item) DiscountedPrice - Holds the price - Holds the discount PerUnitPrice - Hold the price - Holds the unit for the price Unit (and subclasses) - Specifies a unit - May have methods for converting between units. StoreManager - Checks the audit trail of items sold - Determines the value of current in-shop inventory CurrentStock - Contains a list of all items in the shop  Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

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 http://www.adaptivelearningonline.net

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 http://www.adaptivelearningonline.net

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 http://www.adaptivelearningonline.net

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

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 http://www.adaptivelearningonline.net

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 () ;      c.start () ; } Example  3 : public class  Car  {      private  Engine engine;      public  void  start () {        engine.start () ;          //maybe do something more      }      pub

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 () {}   }  Java2html Resources: High cohesion on Wikipedia    Note: This post was originally posted on my blog at http://www.adaptivelearningonline.net

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 () ;      doSomethingWithList ( list ) ;  }  private  void  doSomethingWithList ( ArrayList list ) { }  Example  2 : Loosely coupled system  public 

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    } } Java2html Example 2: DRY honoured public class  Account  {    public  void  transferFunds ( double  amt, Account dest ) {      //transfer funds      dispatchEmail ( ... ) ;    }    public  void  delete () {     

Keep it simple

width="290" height="24" id="audioplayer2"> value="playerID=2&bg=0xCDDFF3&leftbg=0x357DCE&lefticon=0xF2F2F2&rightbg=0xF06A51&rightbghove r=0xAF2910&righticon=0xF2F2F2&righticonhover=0xFFFFFF&text=0x357DCE&slider=0x357DCE&track=0x FFFFFF&border=0xFFFFFF&loader=0xAF2910&soundFile=http://www.adaptivesoftware.biz/storage/audio/swdesignprinciples-keepitsimple.mp3" /> [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 Resources: PrematureGeneralization   

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

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 http://www.adaptivelearningonline.net You will find below comments from the original post COMMENT: 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 COMMENT: AUTHOR: Parag 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

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 o

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 furthe

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: Enterprise and deployment design Component design Class design 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

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

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 http://www.adaptivelearningonline.net Here are the comments from the original post ----- COMMENT: AUTHOR: Ranjan EMAIL: URL: https://ranjanjha@blogspot.com 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