LOVELY PROFESSIONAL UNIVERSITY

Object Oriented Analysis And Design

SUBMITTED TO: Mr. Avinish Kumar SUBMITED BY: VARUN THAKUR SECTION: RD1901 ROLLNO:A50 REG:10905789

Ans1:The main principal of objects model class:>Abstraction >Encapsulation >Modulatory >hierarchy

Abstraction: Data abstraction is the simplest of principles to understand. Data abstraction and encapsulation are closely tied together, because a simple definition of data abstraction is the development of classes, objects, types in terms of their interfaces and functionality, instead of their implementation details. Abstraction denotes a model, a view, or some other focused representation for an actual item. Its the development of a software object to represent an object we can find in the real world. Encapsulation hides the details of that implementation. Abstraction is used to manage complexity. Software developers use abstraction to decompose complex systems into smaller components. As development progress, programmers know the functionality they can expect from as yet undeveloped subsystems.. Encapsulation: Hide implementation from clients clients depend only on the interface, not the implementation Encapsulation focuses the implementation that gives rise to the behaviours. In Encapsulation is achieved through information hiding.eg: the mobile phone Encapsulation is a process of binding or wrapping the data and the codes that operates on the data into a single entity. This keeps the data safe from outside interface and misuse. One way to think about encapsulation is as a protective wrapper that prevents code and data from being arbitrarily accessed by other code defined outside the wrapper.

Modulatory: The breaking of something complex into manageable pieces. Mutators are public methods that are used to modify the state of an object, while hiding the implementation ofexactly how the data gets modified. Mutators are commonly another portion of the property discussed above, except this time its the set method that lets the caller modify the member data behind the scenes. Hierarchy: >At the top of the hierarchy are the must general class. >At the bottom are most specifics >A subclass inherit all the properly and method from the super class.

Ans2: A package diagram in the Unified Modelling Language depicts the dependencies between the packages that make up a model. In addition to the standard UML Dependency relationship, there are two special types of dependencies defined between packages: 1) package import 2) package merge A package import is "a relationship between an importing namespace and a package, indicating that the importing namespace adds the names of the members of the package to its own namespace."By default, an unlabeled dependency between two packages is interpreted as a package import relationship. In this relationship elements within the target package will be imported in source package. A package merge is "a directed relationship between two packages that indicates that the contents of the two packages are to be combined. It is very similar to Generalization in the sense that the source element conceptually adds the characteristics of the target element to its own characteristics resulting in an element that combines the characteristics of both".

Usages of packages: >Package diagrams can use packages containing use cases to illustrate the functionality of a software system. >Package diagrams can use packages that represent the different layers of a software system to illustrate the layered architecture of a software system. > The dependencies between these packages can be adorned with labels / stereotypes to indicate the communication mechanism between the layers. Example Package diagram organizing the university class model.

I have applied several UML stereotypes on Figure. The application stereotype is applied to the Seminar Registration package, indicating that this package contains user interface (UI) classes and application-specific business classes for registering students in seminars. Similarly the technical stereotype is applied to the Java Infrastructure package indicating that it contains technical classes, perhaps a user interface framework such as Apache Struts or a persistence framework such as Prevayler. Both the application and technical stereotypes are my own convention, albeit very common ones. The import stereotype, a UML standard, is applied to several dependencies indicating that the Java Infrastructure package is imported into the other packages on this diagram

Ans3:In role based access control, the role hierarchy defines an inheritance relationship among roles. For example, the role structure for a bank may treat all employees as members of the employee role. Above this may be roles department manager, and accountant, which inherit all permissions of the employee role, while above department manager could be savings manager, loan manager. Complications can arise when constraints such as separation of duties exist between roles. If separation of duty was used to prohibit personnel from holding both loan manager and accountant roles, then branch manager could not inherit permissions from both of them..

Ans4:Classes: A classes is a set of objects that share a common structure and a common behaviour. Class" applies to a "type" or "model" of a GROUP of items, objects, or concepts. A class describes all the attributes of objects, as well as the methods that implement the behavior of member objects. Its a comprehensive data type which represents a blue print of objects. Its a template of object. A class is simply a representation of a type of object; think of it as a blueprint that describes the object. Just as a single blueprint can be used to build multiple buildings, a class can be used to create multiple copies of an object. Objects: "Object" applies to a specific material item or concept, a group of which may comprise a "class". An object has state, behaviour, and identity; the structure and behaviour are defined in their common class; the terms instance and object are interchangeable Object is a basic unit of a system. An object is an entity that has attributes, behavior, and identity. Objects are members of a class. Attributes and behavior of an object are defined by the class definition.

Ans5:The UML specifies two types of scope for members: instance and classifier. Classifiers are a mechanism that is used to describe the structure and the behaviour of the modelling elements. Classifier members are commonly recognized as "static" in many programming languages. The instance defined the scope of a class, the different classes could be multiple, multilevel and single inherit. In the case of instance members, the scope is a specific instance. For attributes, it means that its value can vary between instances. For methods, it means that its invocation affects the instance state, in other words, affects the instance attributes. Otherwise, in the classifier member, the scope is the class. For attributes, it means that its value is equal for all instances. For methods, it means that its invocation does not affect the instance state. To indicate that a member has the classifier scope, its name must be underlined. Otherwise, as default, the instance scope is considered. Ans6: BASIC STRENGTHS OF OBJECT ORIENTED APPROACH 1. SIMPLICITY Software objects model real world objects, so the complexity is reduced and the program structure is very clear; 2. MODULARITY Each object forms a separate entity whose internal workings are decoupled from other parts of the system; 3. MODIFIABILITY It is easy to make minor changes in the data representation or the procedures in an OO program. Changes inside a class do not affect any other part of a program, since the only public interface that the external world has to a class is through the use of methods;

Ans7:ENCAPSULATION Encapsulation is the process of keeping state and behavior of the object in a single unit and exposing public methods to act upon the state means hiding internal data of the object from the outside world. Encapsulation packages the data and method of an object and provides protection from external tampering by users. It implies that there is visibility to the functionalities offered by an object, and no visibility to its data. The best application of encapsulation is making the data-fields private and using public accessory methods. When an objects state and behavior are kept together, they are encapsulated. Encapsulation is often referred to as information hiding. But although the two terms are often used interchangeably, information hiding is really the result of encapsulation, not a synonym for it. They are distinct concepts. Encapsulation makes it possible to separate an objects implementation from its behaviorto restrict access to its internal data. This restriction allows certain details of an objects behavior to be hidden.

Ans8: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 are the mainstay of object-oriented analysis and design. Class diagrams show the classes of the system, their interrelationships (including generalization, and association), and the operations and attributes of the classes. Class diagrams are used for a wide variety of purposes, including both conceptual/domain modeling and detailed design modeling. Although I prefer to create class diagrams on whiteboards because simple tools are more inclusive most of the diagrams that Ill show in this article are drawn using a software-based drawing tool so you may see the exact notation .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:

UML CLASS DIAGRAM USES

of the application, and for detailed modeling translating the models into programming code
2. To provide an implementation-independent description of the types that are

used in a system and passed between its components. For Example: The type Meal Order might be implemented in .NET code in the r, in XML at the interfaces between components, in SQL in the database, and in HTML in the user interface. Although these implementations are different in detail, the relationship between a Meal Order and other types, such as Menu and

Payment, is always the same. The UML class diagram makes it possible to discuss these relationships separately from the implementations.
3. To clarify the glossary of terms used for communication between the

application and its users, and in descriptions of the users' needs. For more information, see Modeling User Requirements.

Ans9:Dependency: A dependency in the Unified Modeling Language exists between two defined elements if a change to the definition of one may result in a change to the other. In UML this is indicated by a dashed line pointing from the dependent (or client) to the independent (or supplier) element. If more than one client or supplier participates in the dependency, arrows with their tails on the client elements are connected to the tails of one or more arrows with their heads on the supplier elements. Place a small dot on the junction point along with a note on the A dependency is a semantic relationship where a change to the influent or independent modeling element may affect the semantics of the dependent modeling element. A dependency identifies a set of model elements that requires other model elements for their specification or implementation. The complete semantics of the depending elements is either semantically or structurally dependent upon the definition of the supplier element(s). The arrow representing a dependency specifies the direction of a relationship, not the direction of a process.

Association: Association are normally represented as a line with each end connected to class box. Association represented the static relationships shared among the objects of the classes. Association defines the relationship between two or more classes in the System. These generally relates to the one object having instance or reference of

another object inside it. This article discusses on how we can implement Association in UML. Association defines the relationship between two or more classes in the System. These generally relates to the one object having instance or reference of another object inside it. This article discusses on how we can implement Association in UML. An association end specifies the role that the object at one end of a relationship performs. Each end of a relationship has properties that specify the role of the association end, its multiplicity, visibility, navigability, and constraints.

Generalization: The Generalization relationships indicates that one of the two related classes or considered to be a specialized from of the other and super type is considered as generalization is also known as inheritance. Generalization is the process of extracting shared characteristics from two or more classes, and combining them into a generalized superclass. Shared characteristics can be attributes, associations, or methods. UML generalization is similar to the object oriented concept of sub classing, it shows the relationship between a general case and one or more specific specialized cases. So what we're dealing with really is kind of inheritance hierarchy. We have a general use case and we'll call it the parent use case that contains a certain set of behaviors, constraints and assumptions..