Lecture 2

Tuesday, June 3, 2008

IDENTIFYING OBJECTS AND CLASSES FROM THE REQUIREMENT SPECIFICATION


Mistakes done creating classes and objects

There are few signs which indicate a bas design of classes. There are no hundred percent negatives in class designs. One can create a design which is bad, but in that circumstance that design may be legitimate. It’s meant you should try as possible to avoid those pitfalls being occurred in the class design but it’s not meant that you can t design classes as follows.

Designing a class that isn’t

The main drawbacks that can occur are designing a class which is not a class. The main concept behind object oriented construction is to build modules around object types not around functions. Some beginners often fall into a big pitfall calling a routine as a class. The remedy is to be conscious about whether each class being corresponds to a meaningful data abstraction.

Class that performs one task

The next drawback is writing a class that performs one task. Such a class is not considered as a real class. For example people some times say this class prints this thing and that class parses the inputs so on. This is not a good habit of creating classes.

Using Imperative Names

This weakness is regarding the naming conventions of a class. Its not possible to use verbs for naming the classes. If you use a verb such as a ‘Print’ for a class that gives the viewer a illusion that the class is performing only one task which is a drawback. In the earlier drawback explained a class performing only one task is not considered as a good design of a class. There is a rule for naming the classes and it says that a class name should be a Noun or an adjective. So you can use nouns such as List, Tree as appropriately and nouns with adjectives such as Linked List.

Still you can use verbs also to name classes but I the form of nouns. For example instead of the word DELETE_ WORD you can use WORD_DELETION. English provides a better support for this from its grammar because almost all the verbs can be converted to nouns very easily.

Premature Classification

This is also a very common mistake done by the programmers. The mistake is worrying about the inheritance more early in the class creation process. What they do is before identifying all the classes they try to think about the inheritance of the classes. That will lead to bad selection of classes.

First you have to identify all the classes with their attributes and functions. And then should try to identify the common features in those classes and separate those in to a super class. Then you will be having a better design and a structure for your classes. For example of being over concentrating on the inheritance, you will be creating two separate classes for COLOMBO and KANDY which extends from the class CITY where you can you use two instances of the same class CITY at the run time.

No command classes

Some times you have come across classes that have no routine at all. They only have queries to access objects. This is bad design technique but there are special situations where this design is not considered as an improper design. One situation is where the class is representing a object obtained from the outside world which the object oriented software cannot change. Such can be data coming from a sensor of a process control system. Another situation is the class is only used for encapsulating data as constants such as in interfaces. There is another situation where classes instead of modifying the object they produce new objects of the same type. For example addition operation in a class doesn’t modify the object instead for given two values X and Y it produces the value X+Y where the result is in the same format.

Up to now we have gone through the possible mistakes that can happen when designing classes. Then what will be the ideal class look like. They are given below.

  • There is a clearly associated abstraction with a class which can be considered as a data abstraction
  • The class name is a Noun or an Adjective
  • Several queries are available to find out properties of an instance.
  • Several commands are available to change the state of the instance.
  • There are some classes which don’t have commands to modify the objects but they produce objects of the same type as with the example of addition of two values.

2 comments:

Dushmanthie said...

SRS (Software Requirements Specification)

Software Requirements Specification is a formal document where all requirements are written down related with a problem domain. And this is mainly used to identify the requirements properly. Since the requirements of software project keeps on increasing. Therefore we have to limit the scope that we are dealing. For that we have to sign off the document with the client. SRS document is used for this purpose. When we discussed and clear with the requirements we are signing off so we don’t have to implement more than that. For identifying the requirements the CRC cards is used as a tool.

CRC Cards

The long term of the CRC is the Class Responsibility Collaborator. As the name implies CRC card represents the responsibilities of a class.

This is a small card which is used as a tool to identify and to analyze the requirements. In this process several persons get together and one person read out the requirements one by one clearly. And then each requirement is taken into consideration and all the classes are identified. When a new class is identified it’s written on a separate card and offers the responsibility to a person to analyze the class further and to study about that class and the relationships that it has with other classes.
Under the responsibilities category in a CRC card it is mentioned what are the things (responsibilities) that the class should do.

Scope of the system

Scope of a system is the amount of requirements that the system is going to support. You have to identify the features that are inside the boundary of the system. The features that are outside the boundary will be ignored.

Dushmanthie said...

SRS (Software Requirements Specification)

Software Requirements Specification is a formal document where all requirements are written down related with a problem domain. And this is mainly used to identify the requirements properly. Since the requirements of software project keeps on increasing. Therefore we have to limit the scope that we are dealing. For that we have to sign off the document with the client. SRS document is used for this purpose. When we discussed and clear with the requirements we are signing off so we don’t have to implement more than that. For identifying the requirements the CRC cards is used as a tool.

CRC Cards

The long term of the CRC is the Class Responsibility Collaborator. As the name implies CRC card represents the responsibilities of a class.

This is a small card which is used as a tool to identify and to analyze the requirements. In this process several persons get together and one person read out the requirements one by one clearly. And then each requirement is taken into consideration and all the classes are identified. When a new class is identified it’s written on a separate card and offers the responsibility to a person to analyze the class further and to study about that class and the relationships that it has with other classes.
Under the responsibilities category in a CRC card it is mentioned what are the things (responsibilities) that the class should do.

Scope of the system

Scope of a system is the amount of requirements that the system is going to support. You have to identify the features that are inside the boundary of the system. The features that are outside the boundary will be ignored.