CSC/ECE 517 Fall 2011/ch1 1e ap

From Expertiza_Wiki
Jump to navigation Jump to search

Introduction to Object Oriented Design

Introduction to Object Oriented Programming

Object-oriented programming (OOP) is a programming language model organized around "objects" rather than "actions" and data rather than logic. It uses "objects" - data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than the logic required to manipulate them. Examples of objects range from human beings (described by name, address, and so forth) to buildings and floors (whose properties can be described and managed) down to the little widgets on your computer desktop (such as buttons and scroll bars).

Object-oriented programming is a method of programming based on a hierarchy of classes, and well-defined and cooperating objects.

  • Classes

The class is the fundamental object-oriented unit. It is a structure that defines the data and the methods to work on that data. Classes define a set of objects that share a common structure and behavior. When you write programs in the Java language, all program data is wrapped in a class.All objects are created from classes, so it important to understand the structure of a class. In fact, it is the design of classes that has fueled the development of various Object Oriented languages.Object is an instance of a class.

  • Objects

An "Object" is binding together of data and behavior, and Object Oriented programming, is the use of objects while solving the problem. What makes an "object" unique is the formal and explicit combination of these smaller pieces' behavior with its' data into a single entity.

Object Oriented Design

Object-oriented design is the process of planning a system of interacting objects for the purpose of solving a software problem. It is one approach to software design. Object-oriented design is the discipline of defining the objects and their interactions to solve a problem that was identified and documented during object-oriented analysis. Much of design involves refining the analysis model through the introduction of classes and algorithms that define exactly how certain required features are realized. Another common design activity is the development of an overall system architecture. This entails organizing the system as a set of major building blocks, such as subsystems or components. For a concurrent system, the architecture includes the basic task or process structure.For a distributed system, it includes the organization of hardware in terms of processors and their interconnections. Basically, object-oriented design (OOD) entails transforming the analysis model into a feasible design. Once the design reaches a sufficient level of specificity, it is translated into an implementation through object-oriented programming. This task can be either relatively straightforward or rather challenging, depending upon the amount of detail in the design.


The first question in OOD ,especially for newcomers, is "How can I decide what classes my program should have in it?" The fundamental rule is that a class should represent some abstraction. For example, a Date class might represent calendar dates, an Integer class might deal with integers, and a Matrix class would represent mathematical matrices. So you need to ask "What kinds of entities does my application manipulate?".

Some examples of potential classes in different application areas would include:

a) GUI/Graphics - Line, Circle, Window, TextArea, Button, Point

b) Architecture - Building, Plot, Room

b) Geography - River, Country, Sea, Continent


Instead of viewing an application as something that performs steps A, B, and C, that is, looking at the program in terms of its functions, instead ask what types of objects and data the application manipulates. Instead of taking a function-oriented approach, take an object-oriented one.

Object Oriented Concepts

  • Abstraction: To implement real world entity into program, class uses the concept of abstraction. Abstraction is a process that involves identifying the crucial behavior of an object and eliminating irrelevant and tedious details.
  • Encapsulation: Binding the data and code to access that data. Encapsulation only refers to a container which has a data and its related functions in it.
  • Inheritance: Defining new classes from the existing one. The new class will get all the methods and properties of the existing class.
  • Polymorphism: Ability to acquire different forms. There are basically two types of polymorphism. Compile Time (also knows as Early binding) and Run Time (also knows as Late binding) Polymorphism.
  • Information Hiding: As encapsulation bind data and methods together, data hiding restrict sensitive data accessing to the system. It is also achieved by using access modifiers i.e. Private, Protected and Public.


Design principles and patterns

Object Oriented Design Principles

  • The DependencyInversionPrinciple (DIP): "The modules that implement a high level policy should not depend on the modules that implement the low level policies, but rather, they should depend on some well-defined interfaces."
  • The CommonClosurePrinciple (CCP):: "The classes in a package should be closed together against the same kinds of changes. A change that affects a package affects all the classes in that package."


Object Oriented Design Patterns

  • Singleton - Ensure that only one instance of a class is created and Provide a global access point to the object.
  • Factory - Creates objects without exposing the instantiation logic to the client and Refers to the newly created object through a common interface.
  • Command - Encapsulate a request in an object, Allows the parameterization of clients with different requests and Allows saving the requests in a queue.
  • Iterator - Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
  • Strategy - Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.
  • Adapter - Convert the interface of a class into another interface clients expect. / Adapter lets classes work together, that could not otherwise because of incompatible interfaces.


Examples

This section discusses about the ATM example using OOD, developed by Dr.Bjork. The overview of this example is explained below. Complete example can be found here http://math-cs.gordon.edu/courses/cs211/ATMExample/

The process of object oriented design starts with the requirements followed by analysis, design and the implementation. Let us dicuss about each of these steps in detail.

Requirements

This design model will help in developing a software that will control a simulated automatic teller machine (ATM). For a complete list of requirements check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Requirements.html

Though there will be more detailed requirements with secuirty constraints, this page provides the basic requirements an ATM should satisfy.

1.) A customer must be able to make a cash withdrawal from any suitable account linked to the card, in multiples of $20.00. Approval must be obtained from the bank before cash is dispensed. 2.) A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope. 3.) A customer must be able to make a transfer of money between any two accounts linked to the card. 4.) A customer must be able to make a balance inquiry of any account linked to the card.

Analysis

The analysis phase involves in finding the use cases, initial test cases and the basic parts (classes) involved in the system.

1.) Use cases:

With the above requirements, we will discuss two important use cases.

Withdrawal Transaction Use Case :

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt.

Deposit Transaction Use Case :

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this account. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later.

Use cases are represented using Interaction diagrams. This section is not going to explain the interaction diagrams. For the interaction diagrams, check here http://math-cs.gordon.edu/courses/cs211/ATMExample/Interactions.html#Startup

2.) Classes

The basic classes of the system can be found using the following conditions

is a singular noun, does not really have the same functionality as some other class, is not simply a primitive type.

The classes required for the ATM model will be,

Card reader. Customer console, consisting of a display and keyboard. Cash dispenser. Envelope acceptor. Receipt printer. Session. Transaction.

Design

The design part includes the process of finding the resposiblities and the interaction of the classes.

The designs can be represented using various methods like

CRC Cards Class Diagram State Charts Interaction Diagrams

In this example we will examine CRC cards closely.

A CRC card has a class name, responsiblities of the class and collobarotars (other classes required to complete the responsiblity).

So for the "Withdrawl" class, a CRC card will be designed as follows,

Responsibilities Collaborators
Perform operations peculiar to withdrawal transaction use case CustomerConsole

CashDispenser

Message

Receipt


So for the "Deposit" class, a CRC card will be designed as follows,

Responsibilities Collaborators
Perform operations peculiar to deposit transaction use case CustomerConsole

Message

EnvelopeAcceptor

Receipt

With this the design is complete. So the rest of the software design includes implemenation and testing which will be convered under ibject oriented programming. http://en.wikipedia.org/wiki/Object-oriented_programming

Advantages of OOD

  • Simplicity: software objects model real world objects, so the complexity is reduced and the program structure is very clear.
  • Modularity: each object forms a separate entity whose internal workings are decoupled from other parts of the system.
  • Maintainable: objects can be maintained separately, making locating and fixing problems easier.
  • Re-usability: objects contain both data and functions that act on data, objects can be thought of as self-contained “boxes”.This feature

makes it easy to reuse code in new systems.

  • Scalability: object’s interface provides a roadmap for reusing the object in new software and thus provides you with all the information

you need to replace the object without affecting other code.

References

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2011/ch1_1e_ap&oldid=54750"