One of three programming paradigms We can identify three paradigms: - - PDF document

Object-Oriented Analysis and Design

One of three programming paradigms

We can identify three paradigms: functional programming, imperative programming and object

• riented approach. Object orientation is comparatively young compared to the other two. Use

the paradigm that suits the problem. If the problem do not supply any suitable objects - do not use object-orientation, use another approach. Program into the language - and use a suitable

• language. Find a language where you can express your thoughts clearly.

Quotes from the book “Code Complete” by Steve McConnell: “Programmers who program “in” a language limit their thoughts to constructs that the lan- guage directly supports. If the language tools are primitive, the programmer’s thoughts will also be primitive.” “Programmers who program “into” a language first decide what thoughts they want to express, and then they determine how to express those thoughts using the tools provided by their specific language.” Object-orientation is a way of thinking. C++ class features support that way of thinking, but C++ can equally well support the imperative way of thinking, and to some degree the functional way of thinking.

Functional programming (Lisp, Scheme, Python)

Solves a task by means of “mathematical” functions, or expressions, that depend purely on

• input. There is no global state. Execution is recursive in nature, and functions should have no

side-effects, just return a result. The program have no “state”. Lambda calculus and recursion are central. Functions are treated as any data, and can be created on the fly, and passed around just like any variable to adapt the behaviour of other functions.

Imperative programming (Ada, C++, Python)

A program consist of statements, functions and procedures that manipulate a program state. Execution of the statements are sequential, and focus on how the program should achieve something in a step by step manner. It is common that functions and procedures cause side effects rather than just calculating a result from the given inputs.

Object orientation (Java, C++, Ada)

A program consist of loosely coupled objects that cooperate to solve a task. The objects are

• ften modeled to represent some real-world “thing” or abstract “concept”. Each object should

provide a cohesive interface that other parts of the program can use, but no details of how the

• bject works internally. Emphasis is on abstraction to name and easily access a possibly

complex behaviour model, encapsulation to be able to update, replace or modify object internals without affecting other parts of the program, and association, composition, aggregation and inheritance to easily reuse functionality in similar objects. Internally, objects

• ften use the imperative paradigm.

The core task of creating an object oriented program is to break it down in areas of responsibility, and identify how those interact. Each responsibility owns a set of properties and provide a certain behaviour, together forming a classification. Each object is an instance of this classification.

Object-Oriented Analysis and Design

Analogy: Company An analogy may be departments in a company. Each department have a responsibility to keep track of some data, market situation, raw materials, or products. Each department can process requests from other departments. If one department or employee tries to interfere with how another department work this will be frowned upon, most departments are very proud of their work and yell high when someone tries to interfere with their operation or try to steal their

• resources. The collective task the departments in the company solve is “making money”.

In this analogy “economy department” may be compared to a class. It may keep track of “bank account” which would correspond to a member variable of that class. It may provide the service “pay salaries” corresponding to a member function. A specific economy department at a specific company location would correspond to an instance (object) of the class. The company would finally correspond to the entire program. Analogy: Car We can also think of a car. It has the responsibility to look and behave as a car. To fulfill this it

• wns an engine, a set of wheels, and a good looking chassis, and it provide means to accelerate,

break and steer. Engine and wheels could in this case be other objects, with their respective responsibilities, and the car cooperate with them to behave like a car. One instance of the class car is a yellow Volvo, another instance is a red Ferarri, both are different in some aspects, but both classify as cars as both of them have the responsibility, properties and behaviour of a car. Analogy: American football Another analogy is to think of the objects as players in a football game. Each kind of player has it’s own abilities and responsibility in the game. When called upon (with or without the ball) each player can take some actions. The collective goal is to cooperate to win the match. In this analogy each kind of player is fairly similar - with fairly similar responsibilities and abilities. That’s not necessarily true in a program - making the analogy poor in that sense. An object-

• riented program would probably describe all players as one kind of object (class) with abilities

to “throw the ball” and “run”, and properties like “length”, “speed” or “toughness”. Specialized defensive players could inherit the properties of the basic player but extent the functionality with “tackle”, and offensive players could have the extra ability to “touchdown”.

Object-Oriented Analysis and Design

Object-Oriented analysis (OOA) and design (OOD)

OOA and OOD is the process of determining which objects that are needed, and how they should cooperate in order to solve a task. It is a creative process of mind, not writing of code. A loose description of the process follows. Formulate the task or problem. Write down some scenarios common to the problem. What are the functional requirements of the program? Things the end user must be able to perform, and what the program should visibly do. This is needed before you can start the real analysis:

• 1. Identify various objects (often nouns) involved in the problem, or in the tasks or scenarios.

Identify various activities taking place in the scenarios (often verbs). This is a broad and fuzzy process. Brainstorm. Keep all suggestions to start with. Once you feel you can not find any more objects or operations you are done with this step.

• 2. Organize your objects and operations into classes. Think of three important things: Name

(Class name), Responsibility and Collaborators. This is often referred to as CRC and summarize each class. Rule out duplicate objects, they are just duplicate instances of one

• class. The same can be true of objects with very similar responsibility. The name should be

chosen carefully to describe the class(ification). The responsibility should be one (single) you naturally think of when dealing with an object of that class. List the operations each class have - the services or behaviour each class provide to others. Identify which other classes each class need to collaborate with in order to fulfill it’s responsibility.

• 3. Identify classes that are a natural part of other classes, or related in some way:
• A Cat is an Animal. This relation is called inheritance. A cat is everything an animal is,

can do everything an animal can do, and is in addition a Cat that may be more than a regular animal (has 9 lives) and do more than a regular animal (purr).

• A Person consist of a Skeleton. This relation is called composition. If we remove the

skeleton from a person he/she become just a pile on meat (not a person anymore). For this reason composition is a really strong relation.

• A Person has ten Fingers. This relation is called aggregation. It is weaker than
• composition. If we remove the fingers the person will still be a person. The fingers is not

essential to remain a person.

• A Person knows about or uses Cars. This weakest relation is called association.
• 4. When you have all classes described with name, responsibility, services provided, and

collaborators you go back to the initial scenario. Execute each scenario or task that the program should support. Which classes and operations are involved, and in what order? Can the task be completed with the identified classes and operations, or is anything missing?

• 5. Start over until you feel you can not improve further. When all classes and operations from

step one are organized in a logic and natural way, and all scenarios work out, you are done. The order of the above steps are not written in stone. You can follow whatever order that feels appropriate - but remember all steps, and iterate several times. The end goal is to have a set of classes, each with one clear and specific responsibility, and as few collaborators as possible. The operations (services, behaviour) provided by each class should be closely related to the responsibility of the class (high cohesion) and the connections between classes should be few (low coupling). The detailed specification of each class with member variables and member functions (just specification, no implementation) falls into object-oriented design.

Object-Oriented Analysis and Design

Practice on object-oriented analysis

Library Organize a software that keep track of stuff you borrow from a library and who borrowed what. A library have papers, music, movies, audio books e-books, reference books (can not be borrowed), love stories, thrillers, detective stories, fantasy books, science fiction books, comic books, and much more. The software is also used to know how many books, and which types exist of each title, where in the library it can be found, genre classification, age classification, wear and tear and much more. Your task is to think of how the software will be used in the library, and which features each use case require. Do an object-oriented analysis of this software to determine how to organize the software in areas of responsibility. Come up with the classes needed to build the software to support all use cases you can think of. Some functions to get you started:

• add newly bought books and customers that moved to town
• register which customer that borrow which book until when
• search books, magazines, papers and customers
• remove broken books and customers that moved to another city
• let customers return borrowed books, papers, magazines, cd’s or dvd’s
• list all books that are currently borrowed
• list all books that are currently overdue
• write reviews of books, magazines or dvd’s

Texas hold ’em poker A poker game take place around a table. A dealer hand out five cards to players around the table. Each player can then place a bet on his hand, or fold. the betting continue until all contributed equal to the pot or folded. The dealer then reveal “the flop” consisting of three open community cards on the table. A new betting round starts followed by the “the turn” single community card, a new betting round and “the river” community card and a last betting round. If more than one player remain after this they reveal their hands to determine the winner. How do you organize this in classes and functions? Highlight keywords in the description. Blackjack This is a relatively simple card game where a dealer deals two cards to each player, and two for

• herself. Cards have the value on the card or at most 10, except for Ace which can be either 1 or
• 11. Players with a total card sum above 21 lose (“bust”). The player at 21 (“blackjack“), or

closest lower than 21 win. Players can ask for more cards (“hit”) or chose to stop (“stand”). The dealer have to hit if her total sum is less than 17. How do you organize this in classes and functions?

Object-Oriented Analysis and Design

C++ class syntax

C++ provide specific syntax to describe a class (description of responsibility with it’s properties and operations) and syntax to create instances (objects, variables) of a class. The class name, and operation names provide abstraction for the responsibility of the class, the keywords public and private provide separation of what is internal private properties and operation of the class (encapsulation) from what is operations intended for use by other classes (interface). It is also possible to denote that a class inherit all properties and operations of another class. The basic syntax with italic style to denote customizable names:

class Class_Name { public: Class_Name(parameter-list); // constructor return-type operation1(parameter-list); ... return-type operationN(parameter-list); private: return-type internal_operation1(parameter-list); ... return-type internal_operationN(parameter-list); data-type property1; ... data-type propertyN; };

Example of a class that describe a car (assuming preexisting classes for Engine etc.):

class Car { public: Car(); void accelerate(); void decelerate(); // ‘break’ is a reserved word void turn(bool to_left); // false will mean ‘to_right’ private: Engine cylinders; array<Wheel,4> wheels; string color; }; // To create an instance of a class Car (an object variable) you do Car my_yellow_volvo; // Will consist of an Engine object etc.