Bachelor of Computer Application (BCA) BC0057 Object Oriented Analysis and Design

1. Explain the advantages of object-oriented systems?

Ans.Object-oriented databases make the promise of reduced maintenance, code reusability, real world modeling, and improved reliability and flexibility. However, these are just promises and in the real world some users find that the object-oriented benefits are not as compelling as they originally believed. For example, what is code reusability? Some will say that they can reuse much of the object-oriented code that is created for a system, but many say there is no more code reusability in object-oriented systems than in traditional systems. Code reusability is a subjective thing, and depends heavily on how the system is defined. The object-oriented approach does give the ability to reduce some of the major expenses associated with systems, such as maintenance and development of programming code. Here are some of the benefits of the object-oriented approach: Reduced Maintenance: The primary goal of object-oriented development is the assurance that the system will enjoy a longer life while having far smaller maintenance costs. Because most of the processes within the system are encapsulated, the behaviours may be reused and incorporated into new behaviours. Real-World Modelling: Object-oriented system tends to model the real world in a more complete fashion than do traditional methods. Objects are organized into classes of objects, and objects are associated with behaviours. The model is based on objects, rather than on data and processing. Improved Reliability and Flexibility: Object-oriented system promise to be far more reliable than traditional systems, primarily because new behaviours can be "built" from existing objects. Because objects can be dynamically called and accessed, new objects may be created at any time. The new objects may inherit data attributes from one, or many other objects. Behaviours may be inherited from super-classes, and novel behaviours may be added without effecting existing systems functions.

2. Explain the Booch Methodology ?

Ans:The Booch method is an object-oriented software development method used to analyze,model, and document system requirements. It was developed by grady Booch. The Booch software engineering methodology provides an object-oriented development in the analysis and design phases. The analysis phase is split into steps. The first step is to establish the requirements from the customer perspective. This analysis step generates a high-level description of the system's function and structure. The second step is a domain analysis. The domain analysis is accomplished by defining object classes; their attributes, inheritance, and methods. State diagrams for the objects are then established. The analysis phase is completed with a validation step. The analysis phase iterates between the customer's requirements step, the domain analysis step, and the validation step until consistency is reached. Once the analysis phase is completed, the Booch software engineering methodology develops the architecture in the design phase. The design phase is iterative. A logic design is mapped to a physical design where details of execution threads, processes, performance, location, data types, data structures, visibility, and distribution are established. A prototype is created and tested. The process iterates between the logical design, physical design, prototypes, and testing. The Booch software engineering methodology is sequential in the sense that the analysis phase is completed and then the design phase is completed. The methodology is cyclical in the sense that each phase is composed of smaller cyclical steps. There is no explicit priority setting nor a non-monotonic control mechanism. The Booch methodology concentrates on the analysis and design phase and does not consider the implementation or the testing phase in much detail. The Booch methodology is a widely used design your system using the object paradigm. The Booch method consists of the following diagrams: Class diagrams Object diagrams State transition diagrams Module diagrams Process diagrams Interaction diagrams

3. Justify that UML is a language for modeling, visualizing, specifying, constructing, and documenting ?
Ans:The Unified Modelling Language is a graphical modelling language that provides us with syntax for describing the major element of software systems. The UML is gaining adoption as a single, industry wide language. The UML was originally designed by the three amigos at rational crop: Grady Booch Rumbaugh Jacobson The Language is very rich and carries with it many aspects of software engineering best practices: Modeling :- The language provides a vocabulary and the rules for combining words in that vocabulary for the purpose of communication. A modelling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modelling language such as the UML is thus a standard language for software blueprints. Modeling yields an understanding of system. No one model is ever sufficient. You often need multiple models that are connected to one another in order to understand anything but the most trivial system. Visualizing: - The UML is more than just a bunch of graphical symbols. Behind each symbol in the UML notation is a well defined semantics. In this manner, one developer can write a model in the UML, and another developer, or even another tool, can interpret that model unambiguously some things are best modelled textually. Other are best modelled graphically. The UML is such a graphical language. Using UML you can produce explicit models that facilitate communication. Specifying: - Specifying means building models that are precise, unambiguous and complete. The UML addresses the specification of all the important analysis, design and implementation decisions that must be in developing and deploying a software intensive system. This mapping permits forward engineering. The generation of code from a UML model into a programming language. The reverse is also possible. You can reconstruct a model from an implementation back into the UML. Reverse engineering is not magic. The UML is sufficiently expressive and un ambiguous to permit the direct execution of model, the simulation of systems and the instrumentation of running systems. Documenting :- The UML addresses the documentation of systems architecture and all of its details. The UML also provide a language for

expressing requirements and for tests. The UML provide a language for modelling the activities of project planning and release management. A healthy software organization produces all sorts of artefacts in addition to raw executable code. These artefacts include: Requirements Architecture Design Source Code Project plans Tests Prototypes Releases

4. What are the potential advantages of treating two related classes as subclasses of some super class?
Ans:Classes are composed from structural and behavioral constituents .Programming languages that include classes as a programming construct offer support for various class-related features, and the syntax required to use these features varies greatly from one programming language to another. Every class implements (or realizes) an interface by providing structure and behavior. Structure consists of data and state, and behavior consists of code that specifies how methods are implemented. There is a distinction between the definition of an interface and the implementation of that interface; however, this line is blurred in many programming languages because class declarations both define and implement an interface. Some languages, however, provide features that separate interface and implementation. For example, an abstract class can define an interface without providing implementation.Languages that support class inheritance also allow classes to inherit interfaces from the classes that they are derived from. In languages that support access specifiers, the interface of a class is considered to be the set of public members of the class, including both methods and attributes any private members or internal data structures are not intended to be depended on by external code and thus are not part of the interface. This approach has the benefit that client code can assume that the operations of an interface are available for use whenever the client has access to the object. Many languages support the concept of information hiding and encapsulation, typically with access specifiers for class members. Access specifiers control access to class members. Some access specifiers may also control how

classes inherit such constraints. Their primary purpose is to separate the interface of a class from its implementation.

5. How is responsibility-driven design used as a guide for deciding how to allocate operations to classes?
Ans:The principle of responsibility-driven design states that, if class A sends a message to class B telling it to do something, it is the responsibility of class B to perform the requested operation. The harder part is determining to which class each operation should be allocated. The sequence of the realization of the Estimate funds available for week use case of the star foundation case study includes the message 3:request estimated return on investments for week. The weekly return on investments is computed by summing the estimated annual return of each investment and dividing by 52.thus, the star foundation case study must include the operation getAnnulReturnonInvestment so that, for each object of investment class, the estimated annual return on that investment can be determined, it is not important whether the message to determine the estimated annual return is sent from star application class, or any other class. Identifying the operations to be allocated to the various classes is usually straightforward. It is not important whether the message to determine the estimated annual return is sent from star application class, asset class, or any other class.

6. Explain the five core workflows of the Unified Process ?

Ans:These are five workflow in Unified Process :1. 2. 3. 4. 5. The Requirement Workflow The Analysis Workflow The Design Workflow The implementation Workflow The Test Workflow

The Requirement Workflow :-

The aim of the requirement work flow is to ensure that the developer build the right information system. This is achieved by describing the target information system sufficiently clearly and accurately that the two main stakeholders, the client and the developers, can agree on what the information system should do and should not do. In order to achieve this, the requirements have to be fully understood by the client.

The Analysis Workflow :The purpose of the analysis workflow is to analyze and refine the requirements. By doing this we achieve the detailed understanding of the requirement that we must have to develop an information system correctly and to maintain it easily. It would be simpler to develop an information system by continuing with further iterations of the requirements workflow until we obtain the necessary understanding of the target information system.

The Design Workflow :During the design workflow we refine the analysis workflow until the material is in a form that can be implemented by the programmers. In addition, a number of requirements need to be finalized at this time, including choice of programming language, as well as reuse and portability issues.

The implementation Workflow :The aim of the implementation workflow is to implement the target information system in the selected implementation language. More precisely, a large information system is partitioned into smaller subsystems, which are then implemented in parallel by coding teams. The subsystems, in turn, consist of components or code artefacts. .