Difference :- CLASSES AND OBJECTS The concepts of object-oriented technology must be represented in object-oriented programming languages.

Only then, complex problems can be solved in the same manner as they are solved in real-world situations.OOP languages use classes and objects for representing the concepts of abstraction and encapsulation. The mapping of abstraction to a program is shown in Fig. 1.18.

The software structure that supports data abstraction is known as class. A class is a data type capturing the essence of an abstraction. It is characterized by a number of features. The class is a prototype or blue print or model that de nes different features. A feature may be a data or an operation. Data are represented by instance variables or data variables in a class. The operations are also known as behaviors, or methods, or functions. They are represented by member functions of a class in C++ and methods in Java and C#. A class is a data type and hence it cannot be directly manipulated. It describes a set of objects. For example, apple is a fruit implies that apple is an example of fruit. The term fruit is a type of food and apple is an instance of fruit. Likewise, a class is a type of data (data type) and object is an instance of class.Similarly car represents a class (a model of vehicle) and there are a number of instances of car. Each instance of car is an object and the class car does not physically mean a car. An object is also known as class variable because it is created by the class data type. Actually, each object in an object-oriented system corresponds to a real-world thing, which may be a person, or a product, or an entity. The differences between class and object are given in Table 1.3. Table 1.3 Comparison of Class and Object Class :objects Class is a data type. Object is an instance of class data type. It generates object. It gives life to a class. It is the prototype or model. It is a container for storing its features. Does not occupy memory location. It occupies memory location. It cannot be manipulated because it is not It can be manipulated. available in the memory. Software Development and Object-Oriented Programming Paradigms 19 Instantiation of an object is de ned as the process of creating an object of a particular class. An object has: 1) states or properties

2) operations 3) identity Properties maintain the internal state of an object. Operations provide the appropriate functionality to the object. Identity differentiates one object from the other. Object name is used to identify the object. Hence, object name itself is an identity. Sometimes, the object name is mixed with a property to differentiate two objects. For example, differentiation of two similar types of cars, say MARUTI 800 may be differentiated by colors. If colors are also same, the registration number is used. Unique identity is important and hence the property re ecting unique identity must be used in an object. The properties of an object are important because the outcome of the functions depends on these properties. Banking system objects To identify the main PiggyBank objects, you must first analyze the use-case documentation and list all the nouns that occur. This list provides the basis for the entity, controller, and boundary elements that comprise the domain diagram. The following list contains all the nouns in the PiggyBank use-case documentation:

Customer Account Owner Customer ID Account number Account balance Credit account number Debit account number Amount Check Check reference Check amount Amount to credit CityBank account Transfer

You can refine the list by eliminating the nouns that represent instances of objects, objects that are attributes of other objects, duplicate or related objects, and any other object that represents an insignificant part of the system. Remember that this is an iterative process. In a real-world situation, you would refine this list as you complete your domain model and as you begin to model the dynamic elements of your analysis model. In this tutorial, the refined list of candidate classes is provided below:

Customer Account Check Transfer

These four classes form the basis of the domain model. Likely, this refined list of objects represents entity classes, because entity classes are often the easiest to discover. The remaining classes, which are either instances or attributes of these classes, describe the details of the main classes and provide information about the relationships that exist between them. The following example illustrates a design of the software system in a vending machine for soft drinks, during different phases in the development. Figures 4, is a conceptual class diagram done early in the project, while figure 5 is a high level design, and finally figure 6 is the detailed design. In figure 4, the conceptual class diagram of the problem domain of vending machines is showed. The diagram shows that the problem domain is concerned with Coins, Vending Machines, Soda Cans, and Customers; it also shows how they are related to each others through un-directed associations. For instance, it shows that the Vending Machine is associated to all other conceptual classes in the diagram, whereas Coins are only associated to the Vending Machine class and the Customer class:-

Class diagram Class Responsibility Collaboration (CRC) cards are a brainstorming tool used in the design of object-oriented software. They were proposed by Ward Cunningham and Kent Beck. [1] They are typically used when first determining which classes are needed and how they will interact.CRC cards are usually created from index cards on which are written: 1. 2. 3. 4. The class name Its Super and Sub classes (if applicable) The responsibilities of the class. The names of other classes with which the class will collaborate to fulfill its responsibilities. 5. Author Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents her/him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.A common method to determine what cards should be created

is to read a specification for the program being designed and consider if each noun should be a class and if each verb should be a responsibility of the noun or class to which it belongs. Naturally, the existence of a noun or verb does not require a class or responsibility in the program, but it is considered a good starting point. A collaboration diagram, also called a communication diagram or interaction diagram, is an illustration of the relationships and interactions among software objects in the Unified Modeling Language (UML). The concept is more than a decade old although it has been refined as modeling paradigms have evolved. A collaboration diagram resembles a flowchart that portrays the roles, functionality and behavior of individual objects as well as the overall operation of the system in real time. Objects are shown as rectangles with naming labels inside. These labels are preceded by colons and may be underlined. The relationships between the objects are shown as lines connecting the rectangles. The messages between objects are shown as arrows connecting the relevant rectangles along with labels that define the message sequencing. Collaboration diagrams are best suited to the portrayal of simple interactions among relatively small numbers of objects. As the number of objects and messages grows, a collaboration diagram can become difficult to read. Several vendors offer software for creating and editing collaboration diagrams. Significance:-very useful for visualizing the relationship between objects collaborating
to perform a particular task.2)collaboration diagrams can also help you determine the accuracy of your static model (i.e., class diagrams).-----------Application of State Diagram

The name of the diagram itself clarifies the purpose of the diagram and other details. It describes different states of a component in a system. The states are specific to a component/object of a system. A statechart diagram describes a state machine. Now to clarify it state machine can be defined as a machine which defines different states of an object and these states are controlled by external or internal events. Statechart diagram is one of the five UML diagrams used to model dynamic nature of a system. They define different states of an object during its lifetime. And these states are changed by events. So Statechart diagrams are useful to model reactive systems. Reactive systems can be defined as a system that responds to external or internal events.Statechart diagram describes the flow of control from one state to another state. States are defined as a condition in which an object exists and it changes when some event is triggered. So the most important purpose of Statechart diagram is to model life time of an object from creation to termination.Statechart diagrams are also used for forward and reverse engineering of a system. But the main purpose is to model reactive system. Following are the main purposes of using Statechart diagrams: 1)To model dynamic aspect of a system.2)To model life time of a reactive system.

3)To describe different states of an object during its life time.4) Define a state machine to model states of an object.5) Statechart diagrams are used to model states and also events operating on the system.6) helpful to understand the system behaviour during its execution.7) To model object states of a system.8) To model reactive system. Reactive system consists of reactive objects.9) To identify events responsible for state changes.10) Forward and reverse engineering. Activities in OOA Steps involved in OOA process: 1. Actors identification 2. Using UML activity diagram develop a simple business process 3. Develop the use case 4. Prepare interaction diagram 5. Classification-develop static UML class diagram 6. Iterate and refine How use case help in determining requirements in oo approach A use case in software engineering and systems engineering, is a description of steps or actions between a user (or "actor") and a software system which leads the user towards something useful.[1] The user or actor might be a person or something more abstract, such as an external software system or manual process.Use cases are a software modeling technique that helps developers determine which features to implement and how to gracefully resolve errors.[2]Within systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in SysML requirement diagrams or similar mechanisms. Each use case focuses on describing how to achieve a goal or a task. For most software projects, this means that multiple, perhaps dozens of use cases are needed to define the scope of the new system. The degree of formality of a particular software project and the stage of the project will influence the level of detail required in each use case."[cite this quote] Use cases should not be confused with the features of the system. One or more features (a.k.a. "system requirements") describe the functionality needed to meet a stakeholder request or user need (a.k.a. "user requirement"). Each feature can be analyzed into one or more use cases, which detail cases where an actor uses the system. Each use case should be traceable to its originating feature, which in turn should be traceable to its originating stakeholder/user request. Use cases treat the system as a black box, and the interactions with the system, including system responses, are perceived as from outside the system. This is a deliberate policy, because it forces the author to focus on what the system must do, not how it is to be done, and avoids making assumptions about how the functionality will be accomplished.

A use case should:

Describe what the system shall do for the actor to achieve a particular goal. Include no implementation-specific language. Be at the appropriate level of detail. Not include detail regarding user interfaces and screens. This is done in userinterface design, which references the use case and its business rules.

Use cases are mostly text documents, and use case modeling is primarily an act of writing text and not drawing diagrams. Use case diagrams are secondary in use case work. Dynamic and Static Modeling The most notable difference between static and dynamic models of a system is that while a dynamic model refers to runtime model of the system, static model is the model of the system not during runtime. Another difference lies in the use of differential equations in dynamic model which are conspicuous by their absence in static model. Dynamic models keep changing with reference to time whereas static models are at equilibrium of in a steady state. Static model is more structural than behavioral while dynamic model is a representation of the behavior of the static components of the system. Static modelling includes class diagram and object diagrams and help in depicting static constituents of the system. Dynamic modelling on the other hand consists of sequence of operations, state changes, activities, interactions and memory. Static modelling is more rigid than dynamic modelling as it is a time independent view of a system. It cannot be changed in real time and this is why it is referred to as static modelling. Dynamic modelling is flexible as it can change with time as it shows what an object does wwith many possibilities that might arise in time.