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)

—

FINDING CANDIDATE CLASSES

Under the topic of finding classes from requirements document, the textual analysis method to find potential classes will be discussed. The candidate classes in the analysis model understandably come from the requirement specification. The text in the specification can be analysed to find potential classes. Generally, a noun in the requirement description corresponds to a potential class. Similarly, adjectives may represent attributes of these candidate classes where as verbs may represent methods of these candidate classes. When identifying these classes, it is important to note that, to model a given system domain, there is no single correct choice of classes. This choice depends on the person, his/her ability and experience. Since poorly chosen classes may add complexity to later phases of the development cycle, and could make the software difficult to maintain and/or extend. Also note that good choices are crucial to the software development process.

Textual analysis – A technique to identify potential classes from a requirements document

Since a class is conceptually a set of objects of the same kind, and objects represent ‘things’ in the system domain, nouns and noun phrases in the requirements document can be used as an aid to identify possible classes.

Example

Below is an extract from the requirements document for a DVD Library System with the nouns and noun phrases underlined.

• The DVD Library holds DVDs of a number of films. It may have any number of copies of each film. The system should, for each film, hold the film's title; no two films have the same title.
• A library member can borrow any DVD of a film that is not currently on loan. However, no member can have more than six DVDs on loan at once. A borrowed DVD must be returned within three days. When a library member returns a DVD it immediately becomes available for loan to other members.
• Each DVD has a unique identifying number.
• Each member of the library has a unique membership number; the system also holds each member's name.

Choosing the nouns and noun phrases is not an exact science. If we consider the nouns and noun phrases underlined in the above example we can identify some problems with the Textual analysis method.

• Problem with noun phrases – If we consider the requirement, It may have any number of copies of each film, here the noun phrase is any number of copies of each film. But it is obvious that the whole noun phrase doesn’t directly relate to any potential class. That’s why in the above example, only the words, ‘number of copies’ and ‘film’ are undelined.
• Nouns and noun phrases are duplicated – In the above example, the term DVD appears more than once.
• Have to deal with different ways of referring to the same thing – in the above example both ‘member’ and ‘library member’ appear. Both refer to the same thing. Therefore instead of having two separate classes, ideally there should be only one class.
• Same word may be used to refer to different things - in the above example, ‘number’ might represent the unique number of DVD or it might represent the unique number of member.

Therefore by grouping nouns that are synonyms we get the following list of candidate classes.

· library (also referred to as ‘DVD Library’)

· DVD (also referred to as ‘copy’)

· number of films

· number of copies

· film

· system (also referred to as ‘DVD Library System’)

· title (also referred to as ‘film title’)

· member (also referred to as ‘library member’)

· loan

· day

· identifying number

· membership number

· member's name

Note – Every item listed here will not give rise to appropriate classes. Your ability to select appropriate classes will improve with experience.

Guidelines for rejection of inappropriate candidate classes

The set of guidelines explained here can be used to reject improper candidate classes.

Is it a property? - In the DVD Library, the word title although it is a noun it is an attribute of a film. Therefore rather than modeling it as a separate class, it is appropriate to model it as an attribute of film class.

Does it refer to a behavior of the system? – Consider the requirement; ‘The system displays a list of the film titles and return dates for the DVDs borrowed by each member’. Here the word ‘list’ although it is a noun it is something that the system has to produce as part of its behavior. Therefore we don’t need to have a separate list class.

Is it outside the scope of the system? - The ‘library’ itself falls into this category. The system will operate in the context of the library and we need to consider only the entities that are inside the library. Here the library is the boundary of the system domain.

Does it refer to an aspect of the user interface? - Consider the requirement; ‘The librarian enters the unique identifying number of the DVD using a barcode reader’. Here ‘barcode reader’ is an aspect of user interface. Therefore we can omit such nouns.

Does it refer to connections between other significant entities in the system domain? - In the DVD Library, since loan is the connection between a DVD and the member who borrowed it, we can omit it from list of candidate classes and model it as an association. But in this example, loan has properties (ex- borrowed date) on its own. Therefore we have to model it as a separate class.

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? Words such as ‘system’, ‘behaviour’ and ‘requirement’ fall into this category: they do not refer to entities in the system domain. Therefore we can omit such nouns.

Surangi N. Alexander (044052)