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

Assignment Set 1 (60 Marks)

1. Discuss the importance of object orientation during system development. Ans In an object-oriented environment, software is a collection of discrete objects that encapsulate their data as well as the functionality to model real world objects. In an object oriented system, everything is an object and each object is responsible for itself. In a payroll application, instead of saying, System, compute the payroll of this employee, you tell the employee object, Compute your payroll. Object oriented systems are easier to adapt to changing requirements, easier to maintain, more robust, and promote greater design and code reuse. Higher level of abstraction. Top-down approach supports abstraction at the function level. The objectoriented approach supports abstraction at the object level. Since objects encapsulate both data (attributes) and functions (methods), they work at a higher level of abstraction. Seamless transition among different phases of software development. The object-oriented approach essentially uses the same language to talk about analysis, design, programming and database design. This seamless approach reduces the level of complexity and redundancy and makes for clearer, more robust system development. Encouragement of good programming techniques. In a properly designed system, the classes will be grouped into subsystems but remain independent. Therefore, changing one class has no impact on other classes, and so, the impact is minimized which encourages good programming. Promotion of reusability. Objects are reusable because they are modeled directly out of real-world problem domain. The object orientation adds inheritance, which is a powerful technique that allows classes to be built from each other and therefore, only differences and enhancements between the classes need to be designed and coded 2. What is polymorphism? Explain it with one example Ans Poly means many and morph means form. In the context of object-oriented systems, it means objects that can take on or assume many different forms. Polymorphism means that the same operation may behave differently on different classes. Polymorphism allows us to write generic, reusable code more easily, because we can specify general instructions and delegate the implementation details to the objects involved. Since no assumption is made about the class of an object that receives a message, fewer dependencies are needed in the code and, therefore maintenance is easier. For example, in a payroll system, manager, office worker, and production worker objects all will respond to the compute payroll message, but the actual operations performed are object specific. 3. Explain the various tools for software implementation. Ans 4. Explain Jacobson et al.s methodologies. Ans The Jacobson et al. methodologies (e.g. Object-Oriented Business Engineering (OOBE), ObjectOriented Software Engineering (OOSE), and Object Factory for Software Development (Objectory)) cover the entire life cycle and stress traceability between the different phases, both forward and backward. Use Cases Use cases are scenarios for understanding system requirements. A use case is an interaction between users and a system. The use-case model captures the goal of the user and the responsibility of the system to its users. In the requirements analysis, the use cases are described as one of the following: Non-formal text with no clear flow of events

 Text, easy to read but with a clear flow of events to follow (this is a recommended style) Formal style using pseudo code The use case description must contain: How and when the use case begins and ends The interaction between the use case and its actors, including when the interaction occurs and what is exchanged How and when the use case will need data stored in the system or will store data in the system Exceptions to the flow of events How and when concepts of the problem domain are handled. Every single use case should describe one main flow of events. An exceptional or additional flow of events could be added. The exceptional use case extends another use case to include the additional one. The use case model employs extends and uses relationships. The extends relationship is used when you have one use case that is similar to another use case but does a bit more. In essence, it extends the functionality of the original use case (like a subclass). The uses relationship reuses common behavior in different use cases. Use cases could be viewed as concrete or abstract. An abstract use case is not complete and has no actors that initiate it but is used by another use case. This inheritance could be used in several levels. Abstract use cases also are the ones that have uses or extends relationships.

Some uses of a library. As you can see, these are external views of the library system from the actor such as a member. The simpler the use case, the more effective it will be. It is unwise to capture all of the details right at the start; you can do that later. Object-Oriented Software Engineering: Objectory Object-oriented software engineering (OOSE), also called Objectory, is a method of object-oriented development with the specific aim to fit the development of large, real-time systems. Objectory is built around several different models: Use case model. The use-case model defines the outside (actors) and inside (use case) of the systems behavior. Domain object model. The objects of the real world are mapped into the domain object model. Analysis object model. The analysis object model presents how the source code (implementation) should be carried out and written. Implementation model. The implementation model represents the implementation of the system.

 Test model. The test model constitutes the test plans, specifications, and reports.

The use-case model is considered in every model and phase. Object-Oriented Business Engineering OOBE is object modeling at the enterprise level. Analysis phase. The analysis phase defines the system to be built in terms of the problem-domain object model, the requirements model, and the analysis model. The analysis process should not take into account the actual implementation environment. This reduces complexity and promotes maintainability over the life of the system, since the description of the system will be independent of hardware and software requirements. Design and implementation phases. The implementation environment must be identified for the design model. This includes factors such as DBMS, distribution of process, constraints due to the programming language, available component libraries, and incorporation of graphical user interface tools. Testing phase. Finally, Jacobson describes several testing levels and techniques. The levels include unit testing, integration testing, and system testing. 5. Justify that UML is a language for modeling, visualizing, specifying, constructing, and documenting. Ans The UML is a language for modeling, visualizing, specifying, constructing and documenting the artifacts of a software intensive system. The UML is a Language for Modeling A language provides a vocabulary and the rules for combining words in that vocabulary for the purpose of communication. A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modeling language such as the UML is thus a standard language for software blueprints. Modeling yields an understanding of a system. No one model is ever sufficient. Rather, you often need multiple models that are connected to one another in order to understand anything but the most trivial system. For software intensive systems, this requires a language that addresses the different views of a systems architecture as it evolves throughout the software development life cycle. The vocabulary and rules of a language such as the UML tell you how to create and read well formed models. But they dont tell you what models you should create and when you should create them. Thats the role of the software development process. A well defined process will guide you in deciding what artifacts to produce, what activities and what workers to use them, create them and manage them, and how to use those artifacts to measure and control the project as a whole. The UML is a Language for Visualizing

The UML is more than just a bunch of graphical symbols. Rather, 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 modeled textually; others are best modeled graphically. Indeed, in all interesting systems, there are structures that transcend what can be represented in a programming language. The UML is such a graphical language. Using UML you can produce explicit models that facilitate communication. The UML is a Language for Specifying In this context, specifying means building models that are precise, unambiguous, and complete. In particular, the UML addresses the specification of all the important analysis, design, and implementation decisions that must be made in developing and deploying a software intensive system. The 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 languages. This means that it is possible to map from a model in the UML to a programming language such as Java, C++, or Visual Basic, or even to tables in a relational database or the persistent store of an object oriented database. Things that are best expressed graphically are done so graphically in the UML, whereas things that are best expressed textually are done so in the programming language. 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. Unless you encode that information in the implementation, information is lost when moving forward from models to code. Reverse engineering thus requires tool support with human intervention. Combining these two paths of forward code generation and reverse engineering yields round trip engineering, meaning the ability to work in either a graphical or a textual view, while tools keep the two views consistent. In addition to this direct mapping, the UML is sufficiently expressive and unambiguous to permit the direct execution of models, the simulation of systems, and the instrumentation of running systems. The UML is a Language for Documenting A healthy software organization produces all sorts of artifacts in addition to raw executable code. These artifacts include (but are not limited to), Requirements Architecture Design Source code Project plans Tests Prototypes Releases Depending on the development culture, some of these artifacts are treated more or less formally than others. Such artifacts are not only the deliverables of a project, they are also critical in controlling, measuring, and communicating about a system during its development and after its deployment.The UML addresses the documentation of a systems architecture and all of its details. The UML also provides a language for expressing requirements and for tests. Finally, the UML provides a language for modeling the activities of project planning and release management.

6. Explain Statecharts and Activity Diagrams with examples Ans Statecharts--A statechart diagram shows a state machine, consisting of states, transitions, events, and activities. Statechart diagrams address the dynamic view of a system. They are especially important in modeling the behavior of an interface, class, or collaboration and emphasize the event-ordered behavior of an object, which is especially useful in modeling reactive systems. shows a state chart diagram.

State Chart Diagram Activity Diagram-An activity diagram is a special kind of a statechart diagram that shows the flow from activity to activity within a system. Activity diagrams address the dynamic view of a system. They are especially important in modeling the function of a system and emphasize the flow of control among objects. Fig. 6.17 shows an example of activity diagram.

Activity Diagram for a Restaurant Order for Two Diners