PRESENTED BY,P.Gowsalya140405

KEY ABSTRACTIONA key abstraction is a class or object that forms part of the vocabulary of the problem domain.

The primary value of identifying such abstractions is that they give boundaries to our problem;

They highlight the things that are in the system and therefore relevant to our design, and they suppress the things that are outside the system and therefore superfluous.

Identification of key abstractions

key abstractions involves two processes: Discovery and invention

Through discovery, we come to recognize the abstractions used by domain experts if the domain expert talks about it, the abstraction is usually important .

Through invention, we create new classes and objects that are not necessarily part of the problem domain but are useful artifacts in the design or implementation.

Refining Key AbstractionsOnce we identify a certain key abstraction as a candidate, we must evaluate it.

As Stroustrup suggests, often this means that the program mer must focus on the questions:

How are objects of this class created? Can objects of this class be copied and/or destroyed?What operations can be done on such objects?

Placing classes and objects at the right levels of abstraction is difficult.

Sometimes we may find a general subclass and so may choose to move it up in the class structure, thus increasing the degree of sharing. This is called class promotion.

Similarly, we may find a class to be too general, thus making inheritance by a subclass difficult because of the large semantic gap. This is called a grainsize conflict.

Naming Key Abstractions

Naming things properlyso that they reflect their semanticsis often treated lightly by most developers yet is important in capturing the essence of the abstractions we are describing.

Suggestions:Objects should be named with proper noun phrases, such as the Sensor or just simply shape.

Classes should be named with common noun phrases, such as Sensor or Shape.

Modifier operations should be named with active verb phrases, such as draw or moveLeft.

Selector operations should imply a query or be named with verbs of the form to be, such as extentOf or isOpen.

Identifying MechanismsMechanism to describe any structure whereby objects collaborate to provide some behaviour the satisfies a requirement of the problem.

Consider a system requirement for an automobile: Pushing the accelerator should cause the engine to run faster, and releasing the accelerator should cause the engine to run slower.

DesignsA mechanical linkage connects the accelerator directly to the fuel injectors.An electronic mechanism connects a pressure sensor below the accelerator to a computer that controls the fuel injectors.No linkage exists. The gas tank is placed on the roof of the car, and gravity causes fuel to flow to the engine.Which mechanism a developer chooses from a set of alternatives is most often a result of other factors, such as cost, reliability, manufacturability, and safety.

OBJECT ORIENTED DESIGN

* The Object ModelOBJECTAttributes contained in datastructuresProcedures whichcan operate on thedata structuresObject IdentityObject StateObject behaviour

* Some OO TerminologyThe following characteristics are generally understood to be included

Identity: Two Objects with the same attribute values are distinct.Classification: Objects with the same attributes and behaviour are grouped into Classes.Polymorphism: The same procedure name may be used by different Classes to invoke different code.Inheritance: Allows a Class to be defined as a sub-type of another Class.Encapsulation: Separates the external interface of an Object from its internal implementation details.

*Conventional Structured Programming ApproachDataCallData AccessMethodMethod

*Benefits of OO DesignObjects are more stable building blocks for systems than traditional procedures.Objects are extensible.Objects are more reusable than procedures alone because they can be more independent of program context.End users may relate easily to Object concept.Object Oriented development reduces project risk by spreading integration across the project life cycle.

*OO State Of The ArtObject Oriented programming languages have matured over 20 years (Smalltalk, C++, Object-Pascal, Java).Development of GUIs like Windows and X have accelerated interest in Object Oriented techniques.Increasing desire for reusability increases interest in OO.Analysis and Design methodologies in a constant state of flux. At present a very big effort is being made to develop a standardised notation, the UML.

*Views Provided by Models UML provides rich set of modelling tools.Different views of system supported by models. Models provide differing perspectives.Use-case view (externally perceived functionality).Logical view (internal functionality).Component view (organisational).Concurrency view (comms. & synch.).Deployment view (physical architecture).

THANK U

*Based on notes from Brian Stone