MODEL HOMEWORK # 1 CAP306: Computer Networks DOA: DOT: DOS: DOE:

Homework Title / No. : ____1____________________________Course Code : _ cap 412

CAP 315____ Course Instructor: _Avinish Sir ___________ Course Tutor (if applicable) : ____________ Students Roll No.__RD3801A08______________ Section No. : _D3801__________________ Declaration: I declare that this assignment is my individual work. I have not copied from any other students work or from any other source except where due acknowledgment is made explicitly in the text, nor has any part been written for me by another person. Students Signature : __Himanshu Gautam___ Evaluators comments: _____________________________________________________________________
Marks obtained : ___________ out of ______________________

Part A Q:-1 What are the basic principles of object orientation? Answer: - ABSTRACTION: The abstraction principles used in the object-oriented approach are: Classification/instantiation, aggregation/decomposition, generalization/specialization and grouping/individualization. By providing support for the abstraction principles, the objectoriented paradigm makes it possible to use conceptual modeling as an efficient tool during the phases of analysis and design. Conceptual modeling can be defined as the process of organizing our knowledge of an application domain into hierarchical rankings or orderings of abstraction. ENCAPSULATION: Often, encapsulation is referred to as "information hiding." An object "hides" the implementation of its behavior behind its interface or its "public face." Other objects can use its behavior without having detailed knowledge of its implementation. Objects know

only the kind of operations they can request other objects to perform. This allows software designers to abstract from irrelevant details and concentrate on what objects will perform. MODULARITY: Modularity is another way of managing complexity by dividing large and complex systems into smaller and manageable pieces. A software designing method is modular if it allows designers produce software systems by using independent elements connected by a coherent, simple structure. [Mey88] defines a software construction method to be modular if it satisfies the five criteria: Modular Protection Modular Understandability Modular Composability Modular Continuity Modular Decomposabiiity

HIERARCHY Hierarchy is a ranking or ordering of abstractions. Types of hierarchies: 1. Class 2. Aggregation 3. Containment 4. Inheritance 5. Partition 6. Specialization Q2:- Why we use package, explain with the diagram? Answer: - Package diagrams are used to reflect the organization of packages and their elements. When used to represent class elements, package diagrams provide a visualization of the namespaces. The most common use for package diagrams is to organize use case diagrams and class diagrams, although the use of package diagrams is not limited to these UML elements.

Packages can be built to represent either physical or logical relationships. When choosing to include classes in specific packages, it is useful to assign the classes with the same inheritance hierarchy to the same package. There is also a strong argument for including classes that are related via composition, and classes that collaborate with them, in the same package. Q:-3 Role of hierarchy in object orientation. Answer: - hierarchies in object-oriented programming Its often the case that the building blocks of a software project form similar conceptual relationship hierarchies. Consider for example the following build-in LabVIEW types.

All of these build-in types are numeric types. Furthermore EXT, DBL, SGL, CXT, CDB and CSG are floating point numbers whereas I64, I32, I16, I8, U64, U32, U16 and U8 are integer

numbers. We can divide integers to signed and unsigned integers and floating point numbers to real and complex numbers. Indeed these numeric types can be considered to form a conceptual hierarchy similar to one below.

Object-oriented programming allows the developer to specify this kind of conceptual hierarchies in software architecture. Each box in the above image can be considered to be a class. Remember from my last article that classes are building blocks in object-oriented programming that encapsulate both data and functionality. This concept of hierarchies is called inheritance in object-oriented programming. The word inheritance comes from the fact that the classes in the hierarchy inherit properties, functionality and interfaces of their parents and all other ancestors. The diagram itself is called a class diagram as it represents the relations between different classes. In object-oriented programming developers can define class hierarchies that define the relations of classes. Decedent classes inherit the functionality, the interface and the data type of all the ancestor classes. Although it didnt yet become clear, class hierarchies and inheritance is one of the key substances in object-oriented programming. Class hierarchies greatly enhance code reuse and allow creating more intuitive software architectures.

Q:-4 explain the relationship between Classes and objects?. Answer: - They look very much same but are not same. Class is a definition, while object is a instance of the class created. Class is a blue print while objects are actual objects existing in real world. Example we have class CAR which has attributes and methods like Speed, Brakes, Type of Car etc. Class CAR is just a prototype, now we can create real time objects which can be used to provide functionality. Example we can create a TATA car object with 100 km speed and urgent brakes. Q:-5 What is the need define the class scope and how we do define the class scope? Answer: - the operator of scope (::, two colons). It is used to define a member of a class from outside the class definition itself. #include <iostream> using namespace std;

class CRectangle { int x, y; public: void set_values (int,int); int area () {return (x*y);} }; void CRectangle::set_values (int a, int b) { x = a; y = b; } int main () { CRectangle rect; rect.set_values (3,4); cout << "area: " << rect.area(); return 0; } The scope operator (::) specifies the class to which the member being declared belongs, granting exactly the same scope properties as if this function definition was directly included within the class definition. For example, in the function set_values() of the previous code, we have been able to use the variables x and y, which are private members of class CRectangle, which means they are only accessible from other members of their class.

Part B Q:-6 Explain the basic Strengths of object orientation? Answer: - 1. A single paradigm 2. facilitates architectural and code reuse. 3. Models more closely reflect the real world (i) more accurately describe corporate data and processes (ii) decomposed based on natural partitioning (iii) easier to understand and maintain 4. stability A small change in requirements does not mean massive changes in the system under development. Q:-7 Explain the concept of Encapsulation with the help of an diagram?. Answer: - Encapsulation means as much as shielding. Each object-oriented object has a shield around it. Objects can't 'see' each other. They can exchange things though, as if they are interconnected through a hatch. It separates the external aspects of an object from the internal implementation details of the object, which are hidden from other objects. The object encapsulates both data and the logical procedures required to manipulate the data.

Example of Encapsulation Concept.

Q:-8 What is Class diagram? Where we will use the class diagrams? Answer: - The purpose of a class diagram is to depict the classes within a model. In an object oriented application, classes have attributes (member variables), operations (member functions) and relationships with other classes. The UML class diagram can depict all these things quite easily. The fundamental element of the class diagram is an icon the represents a class.

Q:-9 Explain Dependency , association, Generalization ? Answer: ASSOCIATION Objects are often associated with, or related to, other objects. For example, as you see in Figure 2 several associations exist: Students are ON WAITING LIST for seminars, professors INSTRUCT seminars, seminars are an OFFERING OF courses, a professor LIVES AT an address, and so on. Associations are modeled as lines connecting the two classes whose instances (objects) are involved in the relationship. When you model associations in UML class diagrams, you show them as a thin line connecting two classes. Associations can become quite complex; consequently, you can depict some things about them on your diagrams. The label, which is optional, although highly recommended, is typically one or two words describing the association. For example, professors instruct seminars. Notation for associations.

DEPENDENCY Sometimes the relationship between a two classes is very weak. They are not implemented with member variables at all. Rather they might be implemented as member function arguments. Consider, for example, the Draw function of the Shape class. Suppose that this function takes an argument of type DrawingContext. a dashed arrow between the Shape class and the DrawingContext class. This is the dependency relationship. In Booch94 this was called a using relationship. This relationship simply means that Shape somehow depends upon DrawingContext. In C++ this almost always results in a #include. GENERALIZATION Also called an "is a" relationship, because the child class is a type of the parent class. Generalization is the basic type of relationship used to define reusable elements in the class diagram. Literally, the child classes "inherit" the common functionality defined in the parent class.