IDENTIFYING OBJECTS AND CLASSES FROM REQUIREMENT SPEC

Software Requirement Specification (SRS)

Requirement Specification is use to plan the project and finalize the requirements at the initial stage of the project. The main reasons is for using a spec, because of the requirements are not clear at the initial stage of the project and need to come up with a sigh in document with the client by capturing requirements as much as possible. There may be lot of contradictions in the early stage of the document. Then come up with an object oriented design with the help of business analysts and do a requirements analysis process. Then latter stages requirements can be clearly identify and can do the necessary modifications to the specification. There are different techniques to identify classes from a SRS.

• Textual analysis

A class is conceptually a set of objects of the same kind, and objects represent ‘things’ in the system domain. So nouns and noun phrases in the requirements document can be used as an aid to identifying possible classes. But there are some problems in this method. Such as sometimes nouns and noun phrases are duplicated, have to deal with different ways of referring to the same thing (eg. Member and library member, title and film title etc.), same word ay be used to refer different things (Number can be used to represent Number of DVDs and number of members). There are some guide lines for rejection of candidate classes. Following are some questions that help to reject the candidate classes.

§ Is it a property?

§ Does it refer to a behavior of the system?

§ Is it outside the scope of the system?

§ Does it refer to an aspect of the user interface?

§ Does it refer to connections between other significant entities in the system domain?

§ Is it a word or phrase that is used in talking about systems in general, rather than a reference to something in the system domain?

• Class Responsibility Collaborator Cards (CRC cards )

A Class Responsibility Collaborator (CRC) model is a collection of standard index cards that have been divided into three sections, as depicted in following figure. Each class has responsibilities. Classes cannot fulfill those responsibilities alone. Classes need to collaborate with other classes and interact with those classes. In simple way a class represents a collection of similar objects, a responsibility is something that a class knows or does, and a collaborator is another class that a class interacts with to fulfill its responsibilities

figure1

Abstract class

An abstract class is a type of class that cannot be instantiated; it merely exists to be extended and contains methods and variables common to all sub-classes. For example consider a hospital system (figure 2).

figure2

Class Categories

There are 3 types of classes.

¢ Analysis classes

— Data abstraction directly drawn from the model of the external system

¢ Design Classes

— describes a data abstraction introduced for the internal needs of the algorithms in the software

¢ Implementation classes

— There are two types of implementation classes.

— 1.Typed implementation classes: A class that implements a concrete class. Implementation classes are never used directly.

— 2.Typeless implementation classes: A class that implements a concrete class and provides an interface that is not specific to a given element type.

Ideal Class

A class that has a clearly associated abstraction, which can be described as a data abstraction (or as an abstract machine). The class name is a noun or adjective, adequately characterizing the abstraction. The class represents a set of possible run-time objects, its instances. (Some classes are meant to have only one instance during an execution; that is acceptable too.)

W.G.K.D. Karunarathne(044022)
Level 4

Lecture 2 - Presentation

Here is the presentation of the Lecture 2

Class Categories

The classes can be divided in to three categories
• analysis classes
• design classes
• implementation classes

Analysis classes
An analysis class describes a data abstraction directly drawn from the model of the external system. PLANE in a traffic control system, PARAGRAPH in a document processing system, are typical examples.

Any software system is based on an operational model of some aspect of the external world. So to simulate the real world things, there should be a way. The analysis class can either be abstract or not. Here it’s important the way we look at the external object. We should look at the object in the system’s point of view.

Implementation classes
An implementation class describes a data abstraction introduced for the internal needs of the algorithms in the software, such as LINKED_LIST or ARRAY.
When we implement the system we have to think about various ways of structuring the objects. This is coming under “Data Structures and Algorithms”.

Differed Implementation Classes
This is a subset of implementation classes. Although the traditional books emphasize about the fully implemented classes in practice we may not be able to use them as it is. The implementation classes are quite abstract, for a broader usage. For example, various queue implementations will be descendants of a deferred class QUEUE describing the abstract concept of sequential list.

Design Classes
Design classes are new set of classes introduced by the architecture to produce an elegant and extendable software structures. STATE, COMMAND type of classes are falling in to this category. Controller classes that are being used in MVC are also fall in to this category

Out of the above types of classes Analysis classes belong to the problem space. Since those classes are found in the problem space. But the other two are in the solution space. When providing the solution, the architecture introduces those new classes.

Lecture 2

CRC Cards

Class Responsibility Collaborator (CRC cards) are a brainstorming tool used in the design of object-oriented software. They were proposed by Ward Cunningham and Kent Beck. There original purpose was to teach programmers the object-oriented paradigm.

Why uses CRC cards?

• They are portable... No computers are required so they can be used anywhere. Even away from the office.
• They allow the participants to experience firsthand how the system will work. No computer tool can replace the interaction that happens by physically picking up the cards and playing the role of that object...
• They are a useful tool for teaching people the object-oriented paradigm.

What is a CRC CARD?

Nothing more than a blank card of 6 X 4 inches. In that card, you can draw a table something like this

By reading the spec you will come across nouns. For each nouns that you feel that can be a class, allocate a card and write the class name on top. Then reading further you will find the thing that can be done or has to be done by that class. Those are the responsibilities. Write down those responsibilities in the relevant cards. There are other classes that this class will communicate or this class should know that “there is a class like this”. Those are called collaborators. Write class names of the collaborators under the collaborator column.

Lecture 2

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.

Comments to Lecture 2 Presentation

Comments

What is Object Oriented Analysis Model?

A model is an abstract thing to understand something well. We use analysis model to capture important requirements, for communication purposes and to explain the system the way we want. There is no perfect model as such. If your model is good enough to explain all the requirements, then that is going to be enough.

Object Oriented Analysis Model is used to identify domain classes and objects. For example, in a banking system, bank policy, interest rate are domain objects. The domain classes are identified during the analysis phase. These classes build the conceptual model of the system domain. At design phase, more classes will be added. Design classes are added by the architect to make the model more elegant and to arrange communication. During implementation phases more classes will be added. Delegates in C# are an example of such implementation classes. Here just because you are using C#, you are required to have delegates. Similarly depending on the technology that is being used to develop the system, more classes may needed to be added.

Requirements document

Requirements document should be clear an unambiguous. Requirements document or the SRS is an important thing in any software project. It’s the agreement client and the software company. At early stages of software development, requirements are not very clear. Through SRS, we capture requirements. Therefore SRS is a tool that is used to collect requirements. We can use SRS for planning of activities such as QA, support etc.

Natural language is ambiguous. Same word may convey different meanings. People understand differently depending on the person’s background, experience, knowledge and culture. Therefore experience and proper knowledge is required to identify classes from requirements document. Also you can’t stick to one method. CRC is another option where you can go for searching classes.

Class Responsibility Collaboration (CRC) Cards

To identify objects we need a better way. CRC is one option. Every class has responsibilities. But they can’t fulfill these responsibilities alone. They need to collaborate with other classes in order to fulfill these responsibilities. CRC concerns responsibilities.

• CRC can be used in both analysis and design.
• Responsibility of a class is the behavior of that particular class or what actions that the class should perform.
• Both CRC and class diagrams represent the same. Unlike in Class diagrams, in CRC, class attributes are missing. In CRC, we are only interested in finding responsibilities and collaborators.
• Sometimes you may need to invent new classes as collaborators.
• When considering responsibilities and collaborations, always make sure whether a particular class is the suitable class to fulfill a particular responsibility.

The difference between class and object

Class has name, variables and operations for it where as object has id (to uniquely identify at run time), state (stored in attributes), behavior (depends on the state). Here the state is very important in Object Oriented Design. It’s important to manage the state of all objects during entire life cycle. All objects should be created in valid states. This is the job of the constructor. All methods that operate on objects should move objects from one valid state to another. An object’s behavior depends on its state. For example, the coin box can’t operate when it’s full.

Scope of a system

You have to identify the things that are inside and things that lie outside the system boundary. Nouns that correspond to entities that are inside the system boundary will be listed and nouns that represent either the system boundary or entities outside the system boundary will be rejected.

Surangi N. Alexander (044052)

Object Oriented Analysis vs Object Oriented Design

Why software engineers are paid more?
Software engineers are modeling projects whereas engineers are building projects. Developing a Software Project is much more complex than the developing any other tangible project like building. Since the nature of intangibility of software, it is very harder to monitor and measure the progress of software project.


• Complexity of the problem domain
The domains can vary really vastly in a software problem. If the problem could be solved simply and easily by human, then there is no need for a software system. It is clearly obvious that we have so much software systems because of the complexity of the problem domain.

• Impedance Mismatch
The system developer and the architect of the system doesn’t know what the client really wants and the client also is not clear what he needs with his requirement.
So vague ideas and communication gap ends with the project in mismatching situation.

• Difficulty of managing the development process
Software is a total intangible product/Service. It is hard to measure and value in a quantitative manner. Qualitatively only we can get at the needed milestones and achievements in a software process.
Software development process is also a intangible process with lot of inconsistencies. There is no clear cut benchmark to evaluate the progress and the management.

Abstraction – Find out the special characteristics of an object that can be that can distinguish it form the other objects with the clear boundaries relative to the viewer. Recognition of the similarities of the objects is important to distinguish the objects. This should be a simple specification where the details are emphasized on the importance to the user. Entity abstraction (Considering the properties of objects), Action abstraction (Considering the functionality of the object), Virtual machine abstraction (Set of similar objects represented as one due to abstraction level) and coincidental abstraction (Non similar objects represented as one) are some abstraction types

Encapsulation – putting the properties and the factions together in a single module without having it to depend on the other such modules internal values; This serves the actual implementation of the abstraction. Also allows to hide the details of implementation.

Modularity- This is to group the factions in to a components which are loosely coupled and they should have the ability to work independently. Reduces the cost of software redesign and modules can be reused.

Hierarchy – Is the ordering of the abstractions in to a tree like structure. There are two types of Hierarchy’s is a and part of. As a example wheel is a part of the car and ford is a type of a car.

W.R.V.G.I.R Kumara (044051)

—