Homework: 1 CAP315 : Object Oriented Analysis and Design

Submitted to: Lect. Avinash Kumar MCA Section: D1901 Roll No.: RD1901B40 Group: 2 Submitted by: Name: Sanjay Course: BCA-

Part A

Q:-1 What are the orientation? Ans:Four basic principles: 1. Abstraction 2. Encapsulation 3. Modularity 4. Hierarchy

basic

principles

of

object

Abstraction is property of encapsulation itself where important components are extracted or used from another group of elements.

Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behaviour; encapsulation serves to separate the contractual interface of an abstraction and its implementation. Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.

Hierarchy is a ranking or ordering of abstractions. . Q:-2 Why we use package, explain with the diagram?. Ans :-

A package in the Unified Modeling Language is used "to group elements, and to provide a namespace for the grouped elements". A package may contain other packages, thus providing for a hierarchical organization of packages. Pretty much all UML elements can be grouped into packages. Thus, classes, objects, use cases, components, nodes, node instances etc. can all be organized as packages, thus enabling a manageable organization of the myriad elements that a real-world UML model entails.For eg:-

When organizing functional models (use case models, workflow models etc.), use packages to model the real-world modular structure of the system being modeled. When organizing source code, use packages to represent the different layers of the source code.

 When organizing component models, use packages to group the components according to ownership and/or reuse possibilities.When organizing deployment models, use packages to represent the different types of deployment environments that you will be modeling. When organizing component models, use packages to group the components according to ownership and/or reuse possibilities.When organizing deployment models, use packages to represent the different types of deployment environments that you will be modeling. Q:-3 Role of hierarchy in object orienatation. Ans:A hierarchy can link entities either directly or indirectly, and either vertically or horizontally. The only direct links in a hierarchy, insofar as they are hierarchical, are to one's immediate superior or to one of one's subordinates, although a system that is largely hierarchical can also incorporate alternative hierarchies. Indirect hierarchical links can extend "vertically" upwards or downwards via multiple links in the same direction, following a path. All parts of the hierarchy which are not linked vertically to one another nevertheless can be "horizontally" linked through a path by traveling up the hierarchy to find a common direct or indirect superior, and then down again.

Role of hierarchy in object orienatation are :

The hierarchy defines classes like this: a dog is a mammal, an apple growing plan is a fruit growing plan which is a growing plan. For eg :vehicles as a class

It allows for the lower level classes (which are usually discovered first in an OO) to be built on top of the higher level classes, thus making them smaller and more readily understandable. Forming the hierarchy eliminates redundant code and organizes our abstractions into something easier to understand. It promotes inheritance maily , with inheritance comes hierarchy or vice a versa.

Q:-4 Explain the relationship between Classes and objects? Ans:-

A class is a definition of an object. It's a type just like int. A class resembles a struct with just one difference : all struct members are public by default. All classes members are private. Remember : A class is a type, and an object of this class is just a variable.Before we can use an object, it must be created. A class specifies :-

a collection of fields; a collection of methods; initial value expressions for the fields; and initialization variables that are bound initialization arguments.

to

In the context of the class system, an object is a collection of bindings for fields that are instantiated according to a class description. The class system allows a program to define a new class (a derived class) in terms of an existing class (the superclass) using inheritance, overriding, and augmenting:

 inheritance: An object of a derived class supports methods and instantiates fields declared by the derived classs superclass, as well as methods and fields declared in the derived class expression.

overriding: Some methods declared in a superclass can be replaced in the derived class. References to the overridden method in the superclass use the implementation in the derived class.

augmenting: Some methods declared in a superclass can be merely extended in the derived class. The superclass method specifically delegates to the augmenting method in the derived class.

An interface is a collection of method names to be implemented by a class, combined with a derivation requirement. A class implements an interface when it declares (or inherits) a public method for each variable in the interface; is derived from the class required by the interface, if any; and specifically declares its intention to implement the interface.

A class can implement any number of interfaces. A derived class automatically implements any interface that its superclass implements. Each class also implements an implicitly-defined interface that is associated with the class. The implicitly-defined interface contains all of the classs public method names, and it requires that all other implementations of the interface are derived from the class. A new interface can extend one or more interfaces with additional method names; each class that implements the extended interface also implements the original interfaces. The derivation requirements of the original interface must be consistent, and the extended interface inherits the most specific derivation requirement from the original interfaces. Classes, objects, and interfaces are all values. However, a class or interface is not an object (i.e., there are no meta-classes or meta-interfaces).

Q:-5 What is the need define the class scope and how we do define the class scope? Ans:To enforce the ability of an object to hide its data, the compiler limits the scope of classthat is, limits their visibility within the program. But to provide flexibility,

it also lets you explicitly set the scope at three levels. Each level is defined by a compiler directive: private The instance variable is accessible only within the class that declares it. protected The instance variable is accessible within the class that declares it and within classes that inherit it. All instance variables without an explicit scope directive have @protected scope. public The instance variable is accessible everywhere.

Part B Q:-6 Explain the basic Strengths of object orientation? Ans :Strengths of object orientation :

Describing large, complex systems as interacting objects makes them easier to understand than otherwise. The behaviours of real world objects tend to be stable over time.

The different kinds of real world objects tend to be stable (i.e., new kinds appear slowly; old kinds disappear slowly) Changes tend to be localized to a few objects. Proper use of OO methods enhances key software quality factors of a system and its constituent components. Emphasis is on data rather than procedure. Programs are divided into objects (abstracted into classes). Data is encapsulated in the objects. Objects communicate with each other through functions (called methods). Follows bottom-up approach in program design.

Q:-7 Explain the concept of Encapsulation with the help of an diagram? Ans :Definition:Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behaviour; encapsulation serves to separate the contractual interface of an abstraction and its implementation. Key concepts:

 Packaging structure and behaviour together in one unit Makes objects more independent

Objects exhibit an interface through which others can interact with it Hides complexity from an objects clients

Q:-8 What is Class diagram? Where we will use the class diagrams? Ans:In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among the classes. The class diagram is the main building block of object oriented modelling. It is used both for general conceptual modelling of the systematics of the application, and for detailed modelling translating the models into programming code. Class diagrams can also be used for data modeling. The classes in a class diagram represent both the main objects and or interactions in the application and the objects to be

programmed. In the class diagram these classes are represented with boxes which contain three parts:

A class with three sections.

The upper part holds the name of the class The middle part contains the attributes of the class The bottom part gives the methods or operations the class can take or undertake

In the system design of a system, a number of classes are identified and grouped together in a class diagram which helps to determine the static relations between those objects. With detailed modeling, the classes of the conceptual design are often split into a number of subclasses. Class diagram are used in structure diagrams, it describes the structure of a system by showing the system's classes, their attributes, and the relationships among the classes. Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems.

Q:-9 Explain Generalization ? Ans :-

Dependency

association,

A relationship is a connection between model elements. A UML relationship adds semantics to a model. We can use several UML relationships to define the structure between model elements. Examples of relationships include associations, dependencies, generalizations. Association:An association relationship is a structural relationship between two model elements that shows that objects of one classifier (actor, use case, class, interface, node, or component) connect and can navigate to objects of another classifier. Even in bidirectional relationships, an association connects two classifiers, the primary (supplier) and secondary (client),

Dependency:-

A dependency relationship indicates that changes to one model element (the supplier or independent model element) can cause changes in another model element (the client or dependent model element). The supplier model element is independent because a change in the

client does not affect it. The client model element depends on the supplier because a change to the supplier affects the client.

Generalization :-

A generalization relationship indicates that a specialized (child) model element is based on a general (parent) model element. Although the parent model element can have one or more children, and any child model element can have one or more parents, typically a single parent has multiple children. In UML 2.0, several classes can constitute a generalization set of another class. Generalization relationships appear in class, component, and use case diagrams.