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 oriented 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 often 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 object 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 often 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 owns 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- oriented 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 ( C lass name), R esponsibility and C ollaborators. 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.