1. 2. 3. 4. 5. 6. 7.

System development activities consist of systems analysis, modeling, design, implementation, testing, maintenance. Major elements of object model are Abstraction, Encapsulation, Modularity and Hierarchy. Minor element of object model are Typing, Concurrency and Persistence Good design stipulates high cohesion and low coupling. Abstract class can only be inherited. Attributes describe the static characteristics of objects and methods define its behavior. UML can be used to model a broad range of systems, a few of which are information systems, technical systems, distributed systems, business systems and real-time systems. 8. Explain how encapsulation violates with inheritance. With Inheritance Encapsulation can be violated in Three Ways. a. The subclass might access an instance variable of its superclass. b. The subclass might call a private operation of its superclass. c. The subclass might refer directly to superclasses of its superclass. Different languages trade off support for encapsulation and inheritance in different ways. For example, the interface of a C++ class may have three parts: private parts, which declare members that are accessible only to the class itself, protected parts, which declare members that are accessible only to the class and its subclasses, and public parts, which are accessible to all the classes. 9. What does dynamic binding offer for object orientation? Polymorphism exists when the features of inheritance and dynamic binding interact. Polymorphism represents a concept in type theory in which a single name (such as variable declaration) may denote objects of many different classes that are related by some common superclass. Any object denoted by this name is therefore able to respond to some common set of operations. Polymorphism (or many forms) enables a class within an inheritance hierarchy to be represented simultaneously as itself and as any superclass within its inheritance hierarchy. Polymorphism is not the same as method overloading or method overriding (which is known instead as ad-hoc polymorphism). Polymorphism is only concerned with the application of specific implementations to an interface or a more generic base class. 10. What is software Software is the term associated with the programs that are written to manage the various resources of a computer system and perform certain designated useful tasks. Software can be further classified into system software and application software. 11. What is difference between overriding and overloading? Overloading is when we define two methods with the same name, in the same class, distinguished by their signatures. Overriding is when we redefine a method that has already been defined in a parent class using the exact same signature. Overloading is resolved at compile time. Overriding is resolved at runtime based on the type of the implicit first parameters. Overloading can occur within a single class, as well as among subclasses within an inheritance hierarchy. Because the various signatures for an overloaded operation are unique, the proper method can be determined at compile-time. 12. What is abstract class? Give example. An Abstract Class is a class that is used only as a base class for other classes or subclasses. We do not (need not, or even cannot) Instantiate from an abstract class. Abstract classes can only be inherited. Abstract class is introduced to make it possible to store a set of attributes and methods common to several classes in one place. Abstract Class example, using System; abstract class MyBaseC // Abstract class { protected int x = 100; protected int y = 150; public abstract void MyMethod(); // Abstract method public abstract int GetX { get; } // Abstract property public abstract int GetY { get; } // Abstract property } class MyDerivedC: MyBaseC { public override void MyMethod() { x++; y++;} public override int GetX { get {return x+10;} } // overriding property public override int GetY { get {return y+10; }} // overriding property public static void Main() { MyDerivedC mC = new MyDerivedC(); mC.MyMethod(); Console.WriteLine("x = {0}, y = {1}", mC.GetX, mC.GetY); }} Output: 110 and 160

13. Explain major elements of object model. Abstraction Abstraction is the process of representing only the important features and hiding the background details and explanations from the user. For Example We dont know the inner details of the Monitor of our PC? What happen when we switch ON Monitor? Does this matter to us what is happening inside the Monitor? No Right, Important thing for us is weather Monitor is ON or NOT. Encapsulation Abstraction focuses on the observable behavior of an object, whereas encapsulation focuses on the implementation that gives rise to that behavior and this is achieved through information hiding. Encapsulation is the mechanism by which the abstraction is implemented. It is the result. The radio, for instance, is an object that encapsulates many technologies that might not be understood clearly by most people who benefit from it. Modularity Modularization consists of dividing a program into modules which can be compiled separately, but which have connection with other modules. Good design stipulates high cohesion and low coupling. Cohesion is the interdependency within a module and coupling is the dependency between modules. Modules serve as the physical containers in which we declare the classes and objects of our logical design. Hierarchy Set of abstractions forms a hierarchy and by identifying hierarchies, we simplify the understanding of a system. Hierarchy is a ranking or ordering of abstractions. The two most important hierarchies in a complex system are its class structure (the is a hierarchy) and its object structure (the part of hierarchy). Example, Inheritance is an important is-a hierarchy and defines relationships among classes, wherein one class shares the structure and behavior defined in another class.

Saving Bank Account

Bank Account Fix Deposit Account Recurring Deposit Account

Explain minor elements of object model. Typing: A type is a strict characterization of structural or behavioral properties which a collection of entities share. Programming languages can be strongly typed, weakly typed or even untyped. Strong typing enforces certain design decision, and so is particularly relevant as the complexity of our system grows. However, there is a dark side to strong typing. Particularly, strong typing introduces semantic dependencies such that even small changes in the interface of a base class require recompilation of all subclasses. Concurrency: Concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on time-shared threads on the same processor, or on physically separated processors. Because computations in a concurrent system can interact with each other while they are executing, the number of possible execution paths in the system can be extremely large, and the resulting outcome can be indefinite. Concurrent use of shared resources can be a source of indeterminacy leading to issues such as deadlock. Persistence: Persistence is the ability of an object to survive the lifetime of the OS process in which it resides. Different types of object persistence are 1. Temporary results in expression evaluation. 2. Local variables in procedures. 3. Data that exists between executions of a program. 4. Data that exists between versions of a program. 5. Data that live longer than the program. Traditional programming languages usually address only the first three kinds of object persistence; persistence of the last two kinds is typically achieved by File system or Relational Database or Object-Database. 14. What is UML? What is the importance of UML? UML is an industry standard modeling language with a rich graphical notation, and comprehensive set of diagrams and elements. It is used for Visualizing, Specifying, Constructing and documenting the artifact of a software-intensive system. UML is a Language for Visualizing - Something are best modeled textually; other are best modeled graphically. In all interesting system, there are structures that go beyond what can be represented in a programming language. UML is a Language for Specifying Specifying means building models that are precise, clear and complete. The UML addresses the specification of all the important analysis. UML is a Language for Constructing - The UML is not a visual programming language, but its models can be directly connected to a variety of programming. UML is a Language for Documenting - A software solution is made up by all sorts of artifacts in addition to raw executable code. These artifacts include: Requirements, Design, Project Plans, Architecture, Source code, Tests, Prototypes, and Releases. UML is important because it provides users a ready-to-use, expressive visual modeling language so they can develop and exchange meaningful models. It provides extensibility and specialization mechanisms to extend the core concepts. It integrates best practices and supports higher-level development concepts such as collaborations, frameworks, patterns and components. We build models so we can better understand the system we are developing.

15. Various steps in UML. During requirements gathering we develop the Use case diagram, Use case description, and Supplementary specifications. Analysis artifacts Below are done, Analysis classes, Use case realization, Sequence and collaboration diagram, and Class diagram (if required). End product of design Below are done, Design classes, packages and subsystems. Class diagram, State chart diagram, and Object diagram. Describe run time architecture Here we identify active classes and threads. Creates Process diagram and Activity diagram. Describe distribution Here we create deployment diagram. 16. List the various notations among classes. UML notations are the most important elements in modeling. Efficient and appropriate use of notations is very important for making a complete and meaningful model. Class Notation - Illustrate classes with rectangles divided into compartments. Place the name of the class in the first partition (centered, bolded, and capitalized), list the attributes in the second partition, and write operations into the third. Active Class Notation - Illustrate active classes with a thicker border. Visibility Notation - Use visibility markers to signify who can access the information contained within a class. - is used for Private, # is used for Protected and + is used for Public. Association Notation - Place association names above, on, or below the association line. Use a filled arrow to indicate the direction of the relationship. Place roles near the end of an association. Roles represent the way the two classes see each other.

Multiplicity Notation - Place multiplicity notations near the ends of an association.

17. Best practice of software engineering. Best Practice of software engineering is A principle, technique, or rule that is followed regardless of the development methodology, language, or application domain. Practice 1 - Develop iteratively - A technique that is used to deliver the functionality of a system in a successive series of releases of increasing completeness. Each iteration is focused on defining, analyzing, designing, building and testing some set of requirements. Scrum is widely used methodology in Agile development lifecycle. Practice 2 - Manage requirements - Make sure you solve the right problem and build the right system by taking a systematic approach to getting, organizing, documenting and managing the changing requirements of a software application. Practice 3 - Use component architecture A system should be designed in such way it can gracefully accumulate new changes without changing all the components. Practice 4 - Software Patterns: Software Patterns describe how to solve typical problems that appear in many application scenarios in similar ways. We should try to use best and suitable design patterns to design the software. E.g. Using Interface and Dependency injection, IOC (Inversion of Control) can be implemented which helps in loading the components at run time and helps in developing TDD (Test Driven Development). Various development errors can be avoided using software patterns. We should use right design pattern for data persistence.

Practice 5 - Model visually - They let us maintain consistency among a systems artifacts: its requirements, design and implementation. It helps improve a teams ability to manage software complexity. Practice 6 - Continuously verify quality - It is not just developing a software which meets the users needs and expectations; it includes identifying the measures and criteria and the implementation of a process to ensure that the resulting product has achieved the desired degree of quality. Practice 7 - Manage change - Control how and when changes are introduced into project artifacts and who introduces the changes. 18. Explain briefly the software development problems. 1. Poor Requirement - Many projects still follow Waterfall SDLC. If the requirements are not very clear and complete, then the team will find it difficult to proceed on schedule. The team will find it especially difficult to provide deliverables as per customers expectations since the requirements were unclear or incomplete at the beginning. 2. Unrealistic schedule and Estimation - Many a time project managers force too much work within too less man-hours either because of inexperience or because of other constraints such as limited budget or lack of clarity in customers business. Bad scheduling is bound to have a ripple effect on development, testing and deployment stages of an SDLC. 3. Inadequate testing A software development requires adequate testing and the effort should be one third of development. So in case of inadequate testing no one knows whether or not the software working as per expectation until customers complain or systems crash. 4. Frequent changes - The business side of the customer may consider adding features during development stage as minor changes. But it throws the whole development team very much off the schedule and cost estimates if the team has to keep revising the code to add features often. 5. The pregnant woman mistake - Fred Brooks illustrated a common project management mistake with his famous statement that just because one woman can have a baby in nine months does not mean that nine women can have a baby in one month. And we still see this come up time and time again the idea that throwing more people at a problem can make it be fixed quicker. Sadly, this is just not true. Every person you add to a project adds friction to the project as well things like the time needed to bring them up to speed or coordinate their work with other people. In fact, my experience has been that there is a tipping point where adding people actually slows the work down more than it speeds things up, especially for the first few months. And there are many tasks that just cant be split up to be done by many people or teams at once. They simply have to be done one foot in front of the other. 6. Miscommunication - Though communication and collaboration are not the stages of an SDLC, communication is the backbone for collaborating and getting things done. Whether communication is done through documentation, stand-up meetings and virtual brainstorming or through web-based SDLC management tools, information sharing and knowledge exchange is required for the project to meet quality standards and deliver on schedule. 19. What is Persistence and why it is important? The property of an object by which its existence exceeds time (i.e., the object continues to exist after its creator ceases to exist) and /or space ( i.e., the objects location moves from the address space in which it was created). Why is Persistence Important? a. Unifying Persistence with Object Model, we get Object Oriented databases. B. Offers the programmers of database systems the abstraction power of object technology. C. Smalltalk provides support for persistence, Most OOPL do not support persistence directly. D. Many systems provide an OO Skin over a RDBMS 20. Explain OOA check points. Below check points should be used in OOA phase, A. The classes are relatively small. B. Responsibility, control, and communication are distributed. One object doesnt do everything. Makes it easier to reuse, easier to develop and manage. C. Information with different rates of change is separated. D. Minimum assumptions of language or system. It describes the world, not a program. E. There should be no redundancy. F. If the requirements were extended to include more things, the existing parts of the design would only change minimally. G. Good hierarchy is linked by IsA relationships. H. Each class in the design should have a list of responsibilities and collaborators that describe what the class does within the system.

21. Explain OOD check points. Below check points should be used in OOD phase, Every class should have at least one attribute or object connection. Every class should have at least one service. No object knows about every other object in the system. No object is the clear center of the information flow. Objects connect to other objects only if they need information from them. There are no unnecessary middlemen. Attributes and services are as high in the inheritance hierarchy as possible. 22. What is Model? A model is an abstract representation of a system which is constructed to understand the system prior to building or modifying it. A model is simplified representation of reality, because reality is too complex or large. Modeling enables us to cope with the complexity of a system. Most modeling techniques used for analysis and design involve graphic languages. These graphic languages are sets of symbols. The symbols are used according to certain rules of methodology for communicating the complex relationships of information more clearly than descriptive text. UML is the widely used unified modeling language. 23. Explain CRC model with the help of example. CRC stands for Class, Responsibility, Collaborator, and describes the information on the card. A CRC model is really a collection of standard index cards that represent classes. Cards are divided in three sections. In the top of the card we write name of the class and in the body we write list of class responsibilities on the left and collaborators on the right. The class name of an object creates a vocabulary for discussing a design. We need to find just the right set of words to describe our objects. Responsibilities identify problems to be solved. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise the design will be. Those classes that are required by a class to complete the responsibility are identified as collaborator. Example - Below is CRC card example for a student enrollment in seminar. To do this, a student needs to know if a spot is available in the seminar and, if so, he then needs to be added to the seminar. However, students only have information about themselves (their names and so forth), and not about seminars. What the student needs to do is interact with the card labeled Seminar to sign up for a seminar. Therefore, Seminar is included in the list of collaborators of Student card.

24. DEFINITIONS: OOA, OOD AND OOP Object-oriented analysis (OOA) is a method of analysis that examines requirements from the perspective of the classes and objects found in the vocabulary of the problem domain. During OOA, there is an emphasis on finding and describing the objects or concepts in the problem domain. For example, in the case of the library system, some of the concepts include books, library and patron. During OOA phase, the overall questions are What? As in, What will the classes in my program be?, and What will each class be responsible for? We dont worry about implementation details in the OOA phase. Object-oriented design (OOD) is the process of planning a system of interacting objects for the purpose of solving a software problem. It forces programmers to plan out their code in order to have a better flowing program. During OOD, there is an emphasis on defining logical software Objects that will ultimately be implemented in an Object-oriented programming language. These software objects have attributes and methods. To illustrate, in a library system, a book software object may have a title attribute and a print method. During OOD phase, we are worried about some implementation details, but not all what the attributes and methods of a class will be. Object-oriented programming (OOP) is a method of implementation in which programs are organized as cooperative collection of objects each of which represents an instance of some classes are all members of a hierarchy of classes united via inheritance relationships. Object-oriented programming can be called as a new programming pattern that will help us develop software that is more reliable, easily maintainable and reusable. The three fundamental units of Object- oriented programming are objects, methods and messages.

25. What is Object-oriented Analysis and Design ? explain. Object-oriented analysis and design (OOAD) is a software engineering approach that models a system as a group of interacting objects. Each object represents some entity of interest in the system being modeled, and is characterized by its class, its state (data elements), and its behavior. Various models can be created to show the static structure, dynamic behavior, and run-time deployment of these collaborating objects. There are a number of different notations for representing these models, such as the Unified Modeling Language (UML). Object-oriented analysis (OOA) applies object-modeling techniques to analyze the functional requirements for a system. Object-oriented design (OOD) elaborates the analysis models to produce implementation specifications. OOA focuses on what the system does, OOD on how the system does it. 26. Explain various relationships among classes. Three major relationship exist among classes Association, Generalization and Dependencies Association It is set of structural relationships among classes. Two classes may be aware of each other existence. Example in an automated system for retail point of sale, two of our key abstraction includes products and sale. The class Product denotes the products sold as part of sale, and the class Sale denotes the transaction through which several products were last sold. By implication, this association suggests bi-directional navigation. Product N 1 Sale Product last Sale Generalization Generalization is a relationship in which one model element (the child) is based on another model element (the parent). Generalization relationships are used in class, component, deployment, and use-case diagrams to indicate that the child receives all of the attributes, operations, and relationships that are defined in the parent. We can add generalization relationships to capture attributes, operations, and relationships in a parent model element and then reuse them in one or more child model elements. Because the child model elements in generalizations inherit the attributes, operations, and relationships of the parent, we must only define for the child the attributes, operations, or relationships that are distinct from the parent. Dependency Dependency is a weaker form of relationship which indicates that one class depends on another because it uses it at some point of time. It indicates a semantic relationship between two or more classes. A dependency is shown as a dashed arrow between two model elements. The model element at the tail of the arrow depends on the model element at the arrow head. The arrow may be labeled with an optional stereotype and an optional name. 27. Explain the different kind of relationships among object. There are three kinds of relationships among object: Links and Aggregation / Composition Link - Rumbaugh defines a link as a physical or conceptual connection between objects. An object collaborates with other objects through its links. A link is a specific form of an association through which an object (the client) takes the services of another object (the supplier). During implementation Links will become pointers or references to objects. A Link is an instance of an association and both are bi-directional. (e.g., employs and employed by). Where ambiguity appears, a directional arrow can be added to clarify an Association or Link name. The relationship between any two objects includes the assumptions that each makes about the other, including what operations can be performed and what behavior results. Aggregation and Composition Aggregation - It is an association which denotes a whole/part relationship among objects with the ability to navigate from the whole (aggregate) to its parts (attributes). It is possible for an object to navigate to its container only if this knowledge is part of the objects state. Aggregation may or may not denote physical containment. Composition - Composition is a form of aggregation with strong ownership and coincident lifetime of part with the whole. he multiplicity of the aggregate end may not exceed one. he parts of a composition may include classes and association. -Aggregation and composition are two related (and often confused) relationships that associate a whole with its parts. For example, a team aggregates players. As another example a car (the whole) might be constructed of an engine, some wheels, and some parts). As yet another example, a user process (the whole) within a computer operating system might be constructed from a program memory, some stack space, and an execution context (its parts). Both aggregation and composition enable modeling at two-levels of abstraction: the whole or the part.

28. Aggregation vs. Composition -Both denote whole-part relationships. Both enable modeling at multiple levels of abstraction: whole or part In an aggregation association, parts can be associated with multiple wholes (often at the same time). For example, a wheel can be removed from a car and can be moved to a heap of tires or mounted on another car. Elements in an aggregation have existence and identify outside of the whole. The wheel, for example, has an existence and identity outside of the car. In addition, the parts and the whole within an aggregation can have different lifetimes. For example, after the wheel is removed from the car, the car could be destroyed, yet the wheel would continue to exist. -- In contrast, in a composition association, parts are associated only with one whole. In fact, a part within a composition has no existence outside the whole. For example, a particular stack space does not exist without being contained within a specific user process. The lifetime of the parts in a composition is bound to the lifetime of the whole. -- When a user process is created, the program memory, stack space and execution context are also created. When a user process is destroyed, the program memory, stack space, and execution context die too. If you can navigate to the whole in a composition, then you are guaranteed to be able to navigate to the parts. This is because the lifetimes of the whole and parts correspond. Aggregation is a relatively weaker form of the whole-part relationship, while composition is a relatively stronger form. 29. With the help of example explain object diagram. An object diagram is a graph of instances, including objects and data values. A object diagram is an instance of a class diagram; it shows a snapshot of the detailed state of a system at a point in time. The same notations as for class diagrams are used, with two exceptions: objects are written with and all instances in a relationship are shown. They are not as important as class diagrams but can be used to exemplify a complex class what the actual instances and the relationships could look like. To capture a particular system, numbers of class diagrams are limited. But if we consider object diagrams then we can have unlimited number of instances which are unique in nature. So only those instances are considered which are having impact on the system and have important data and association. The use of object diagrams is fairly limited, mainly to show examples of data structures. The following diagram is an example of an object diagram. It represents an instance of the Order management system at a particular time of purchase. It has the following objects - Customer, Order, SpecialOrder and NormalOrder

30. What is class diagram? Explain with example. Class diagram is a graphical representation of the static view of the system and represents different aspects of the application. A collection of class diagrams represent the whole system. Class diagram represents internal structure of a class and their relationships to other things. -- Generally UML diagrams are not directly mapped with any object oriented programming languages but the class diagram is an exception and can be directly implemented in an OOP language that has the construct for a class. -- To create a class diagram, the classes have to be identified and described and when a number of classes exist, they can be related to each other using a number of relationships. -- Example - Following diagram is an example of an Order System of an application. So it describes a particular aspect of the entire application. -- First of all Order and Customer are identified as the two elements of the system and they have a one to many relationship because a customer can have multiple orders. -- We would keep Order class is an abstract class and it has two concrete classes (inheritance relationship) SpecialOrder and NormalOrder. -- The two inherited classes have all the properties as the Order class. In addition they have additional functions like dispatch () and receive (). -- So the following class diagram has been drawn considering all the points mentioned above:

31. With the help of example explain sequence diagram with concurrent objects. A sequence diagram shows an interaction arranged in time sequence. In particular, it shows the objects participating in the interaction by their lifelines and the messages that they exchange arranged in time sequence. It does not show the associations among the objects. It is better for real-time specifications and for complex scenarios. A sequence diagram has two dimensions. A. The vertical dimension represents time. Normally time proceeds down the page. B. The horizontal dimension represents different objects. There is no significance to the horizontal ordering of the objects.

32. Explain interaction diagram with the help of an example. From the name Interaction it is clear that the diagram is used to describe some type of interactions among the different elements in the model. So this interaction is a part of dynamic behavior of the system. This interactive behavior is represented in UML by two diagrams known as Sequence diagram and Collaboration diagram. The basic purposes of both the diagrams are similar. Sequence diagram emphasizes on time sequence of messages and collaboration diagram emphasizes on the structural organization of the objects that send and receive messages. Sequence Diagram Refer above question. Collaboration Diagram - collaboration diagrams are used to describe the structural organizations of the objects taking part in the interaction. Method calls are similar to that of a sequence diagram. But the difference is that the sequence diagram does not describe the object organization where as the collaboration diagram shows the object organization. Now to choose between these two diagrams the main emphasis is given on the type of requirement. If the time sequence is important then sequence diagram is used and if object organization is required then collaboration diagram is used.

33. Explain implementation diagram with the help of example. Implementation diagram shows aspects of model implementation, including source code structure and run-time implementation structure. Two type of implementation diagram are component diagram and deployment diagram. Component Diagram Component diagrams are used to describe the physical artifacts of a system. This artifact includes files, executables, libraries etc. So the purpose of this diagram is different, Component diagrams are used during the implementation phase of an application. But it is prepared well in advance to visualize the implementation details. Initially the system is designed using different UML diagrams and then when the artifacts are ready component diagrams are used to get an idea of the implementation. This diagram is very important because without it the application cannot be implemented efficiently. A well prepared component diagram is also important for other aspects like application performance, maintenance etc. Below diagram shows four components: Reporting Tool, Billboard Service, Servlet 2.2 API, and JDBC API. The arrowed lines from the Reporting Tool component to the Billboard Service, Servlet 2.2 API, and JDBC API components mean that the Reporting Tool is dependent on those three components.

Deployment diagram The name Deployment itself describes the purpose of the diagram. Deployment diagrams are used for describing the hardware components where software components are deployed. Deployment diagram represents the deployment view of a system. It is related to the component diagram. Because the components are deployed using the deployment diagrams. A deployment diagram consists of nodes. Nodes are nothing but physical hardware used to deploy the application. Deployment diagrams are useful for system engineers. An efficient deployment diagram is very important because it controls Performance, Scalability, Maintainability and Portability. The following deployment diagram is a sample to give an idea of the deployment view of order management system. Here I have shown nodes as: Monitor, Modem, Caching server and Servers The application is assumed to be a web based application which is deployed in a clustered environment using server 1, server 2 and server 3. The user is connecting to the application using internet. The control is flowing from the caching server to the clustered environment.

34. What is Use Case? Explain with the help of example. -- A use case is a sequence of actions that provide a measurable value to an actor. Another way to look at it is a use case describes a way in which a real-world actor interacts with the system. Use Cases have become the starting point of many current Object Oriented (OO) development methodologies. They generally serve as both a foundation and entry point for the rest of the analysis and development process. The characteristics of a use case are -- It should be complete. 2. It should always be initiated by actor. 3. It should provide a value to an actor

35. Primary purpose of Use Case. -- It is used to decide and describe the functional requirements of the system. To give a clear and consistent description of what the system should do. This allows the model to be used throughout the development process. To provide a base for performing system tests that verifies the system. To provide the ability to trace functional requirements into actual classes and operations in the system. 36. The attribute values are dependent upon the values of other attributes are called Derived Attribute. 37. Behavior is how an object acts and reacts, in terms of its state changes and message passing. 38. Four Quality measures are CORRESPONDENCE, CORRECTNESS, VARIFICATION AND VALIDATION. 39. Design process is typically split into two distinct phases: Object-Oriented Analysis (OOA) and Object Oriented Design (OOD). 40. What is quality software? Explain. -- High-quality software provides users with an application that meets their needs and expectations. -- Four quality measures: correspondence, correctness, verification, and validation. -- Correspondence measures how well the delivered system corresponds to the needs of the problem. -- Correctness determines whether or not the system correctly computes the results based on the rules created during the system analysis and design , measuring the consistency of product requirements with respect to the design specification. Verification is the task of determining correctness (am I building the product right?).Validation is the task of predicting correspondence (am I building the right product?). -- Quality in software can be measured by external characteristics (e.g. easy to use, runs fast) or internal characteristics (e.g. modular design, readable code). 41. Pitfall of top-down design. -- The functional viewpoint is difficult to change and evolve Every real-world system undergoes change and evolution. But when the system changes and new requirements are added, the functional architecture becomes more and more unwieldy. Because the software is designed around a relatively fixed tree structure, changes usually require extensive pruning and grafting. Real systems are hard to characterize functionally Most large systems do not have a top. For example, a database system involves tools for querying data, changing data, keeping data consistent, etc There is no one function central to these diverse concerns. The functional approach loses sight of the data As you can see from the example above, the top-down design does not capture anything about the data involved in the program. Functions always do something to data. Usually, the same data is shared among a number of functions (for example, updating, deleting, inserting and querying a database table). Since the decomposition only highlights the functional aspects of the problem, the influence of the data structures on the problem is lost. Functional orientation produces less reusable code Each program element is designed with only a limited set of requirements in mind. Since it is unlikely that this exact set of requirements will return in the next problem, the programs design and code is not general and reusable. Top-down design does not preclude the creation of general routines that are shared among many programs. Q - MERITS OF OBJECT APPROACH. Object orientation works at a higher level of abstraction One of our most powerful techniques is the form of selective amnesia called Abstraction. Abstraction allows us to ignore the details of a problem and concentrate on the whole picture. Software life cycle requires no vaulting (Jump) The object-oriented approach uses essentially the same language to talk about analysis, design, programming and (if using an Object-oriented DBMS) database design. This streamlines the entire software development process, reduces the level of complexity and redundancy, and makes for a cleaner system architecture and design. Data is more stable than functions Functions are not the most stable part of a system, the data is. Over a period of time, the requirements of a system undergo radical change. New uses and needs for the software are discovered; new features are added and old features are removed. During the course of all this change, the underlying heart of the system remains comparatively constant. This heart is the data. Encourages good programming techniques Class are designed with single responsibility so that changing one class has no impact on the other class and so the impact is minimized. Various design patterns are used which provides solution to common problem and makes the system more accurate. Promotes code reuse The code and designs in object-oriented software development are reusable because they are modeled directly out of the real-world problem-domain.

10