MCA PROGRAMME V SEMESTER ASSIGNMENT

Name Registration Number Learning Center Learning Center Code Course/Program Semester Subject Code Subject Title

|| || || || || || || ||

Mokashi Padmanabh Pramod 521106420 Halo Technologies and Training Pvt. Ltd 01976 MCA Fifth (5th) MC0083 Object Oriented Analysis and Design using UML 05th Dec 2013 _____________

Date of Submission Marks Awarded

|| ||

_______________________ Signature of the Coordinator

__________________ Signature of Evaluator

Halo Technologies and Training Pvt. Ltd. || 65260303 || 9870050750 || academics@halo.co.in

Directorate of Distance Learning Sikkim Manipal University II Floor, Syndicate House, Manipal 576 104

MOKASHI PADMANABH PRAMOD 521106420

MC0083

MC0083 Object Oriented Analysis and Design using UML

1. Give the two orthogonal views of the software. What are the advantages of object orientation? Two orthogonal views of the software Niklaus Wirth, the inventor of Pascal says: Algorithms + Data structures = Programs A software system is a set of mechanisms for performing certain action on certain data. Traditional development techniques focus on the functions of the system. Object oriented systems development centers on object, which combines data and functionality. Advantages of Object Orientation 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 object-oriented 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 Inheritance? Explain Multiple Inheritance. Inheritance Inheritance is the property of object-oriented systems that allows objects to be built from other objects. Inheritance allows explicitly taking advantage of the commonality of objects when constructing new classes. Inheritance is a relationship between classes where one class is the parent class of another (derived) class. The parent class is also known as the base class or super class. Inheritance provides programming by extension as opposed to programming by reinvention. The 2

MOKASHI PADMANABH PRAMOD 521106420

MC0083

real advantage of using this technique is that we can build on what we already have and, more important, reuse what we already have. Inheritance allows classes to share and reuse behaviors and attributes. Where the behavior of a class instance is defined in that classs methods, a class also inherits the behaviors and attributes of all of its superclasses. Dynamic inheritance allows objects to change and evolve over time. More specifically, dynamic inheritance refers to the ability to add, delete, or change parents from objects (or classes) at run time. Vehicle

I know how to stop Stop method is reusable

Car

Ford

Mustang

Taurus I dont know how to stop

Thunder Bird

Stop (my Mustang) Inheritance allows reusability Multiple Inheritance Some object-oriented systems permit a class to inherit its state (attributes) and behaviors from more than one superclass. This kind of inheritance is referred to as multiple inheritance. Multiple inheritance can pose some difficulties. For example, several distinct parent classes can declare a member within a multiple inheritance hierarchy. This then can become an issue of choice, particularly when several superclasses define the same method. It is also more difficult to understand programs written in multiple inheritance systems. One way of achieving the benefits of multiple inheritance in a language with single inheritance is to inherit from the most appropriate class and then add an object of another class as an attribute. Motor Vehicle

Truck

Car

Bus

Utility Vehicle Utility vehicle inherits from both the Car and Truck classes 3

MOKASHI PADMANABH PRAMOD 521106420

MC0083

3. Give the criteria for building high quality software. Explain the use case driven approach to object oriented systems development process. Criteria for Building high-quality software To achieve high quality in software we should be able to answer the following questions: How do we determine that the system is ready for delivery? Is it now an operational system that satisfies users needs? Is it correct and operating as we thought it should? Does it pass an evaluation process?

Blum describes a means of system evaluation in terms of four quality measures: Correspondence measures how well the delivered system matches the needs of the operational environment, as described in the original requirements statement. Validation task of predicting correspondence. Correctness measures the consistency of the product requirements with respect to the design specification. Verification exercise of determining correctness.

Verification: Am I building the product right? Validation: Am I building the right product? Validation begins as soon as the project starts, but verification can begin only after a specification has been accepted. Validation Verification

Needs

Requirement Corrective Correspondence

Design

Software

Four quality measures (correspondence, correctness, validation, and verification) for software evaluation. Use-case driven approach to object oriented systems development process. Object-oriented analysis Use-case driven The object-oriented analysis phase of software development is concerned with determining the system requirements and identifying classes and their relationships to other classes in the problem domain. Actors: The users of the system. 4

MOKASHI PADMANABH PRAMOD 521106420

MC0083

Use case: A typical interaction between a user and a system that captures users goals and needs. You capture a use case by talking to typical users, discussing the various things they might want to do with the system. Scenarios: Used to help analysts understand requirements. Scenarios are a great way of examining who does what in the interactions among objects and what role they play, that is, their interrelationships. Collaboration: The intersection among objects roles to achieve a given goal is called collaboration. The scenarios represent only one possible example of the collaboration. To understand all aspects of the collaboration and all potential actions, several different scenarios may be required, some showing usual behaviors, others showing situations involving unusual behavior or exceptions. Use-case modeling: Expressing these high-level processes and interactions with customers in a scenario and analyzing it is referred to as use-case modeling.

4. Explain the Booch and Jacobson Methodologies. The Booch Methodology The Booch methodology is a widely used object-oriented method that helps you to 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

The Booch methodology prescribes a macro development process and a micro development process. The Macro development process The macro process serves as a controlling framework for the micro process and can take weeks or even months. The macro development process consists of the following steps: Conceptualization: During conceptualization, you establish the core requirements of the system. You establish a set of goals and develop a prototype to prove the concept. Analysis and development of the model: In this step, you use the class diagrams to describe the roles and responsibilities objects are to carry out in performing the desired behavior of the system. Then, you use the object diagram to describe the desired behavior of the system in terms of scenarios or alternatively, use the interaction diagram to describe behavior of the system in terms of scenarios. Design or create the system architecture: In the design phase, you use the class diagram to decide what classes exist and how they relate to each other. Next, you use the object diagram to decide what mechanisms are used to regulate how objects collaborate. Then, 5

MOKASHI PADMANABH PRAMOD 521106420

MC0083

you use the module diagram to map out where each class and object should be declared. Finally, you use the process diagram to determine to which processor to allocate a process. Also, determine the schedules for multiple processes on each relevant processor. Evolution or implementation: Successively refine the system through much iteration. Produce a stream of software implementations (or executable releases), each of which is a refinement of the prior one. Maintenance: Make localized changes to the system to add new requirements and eliminate bugs.

The Micro development process Each macro development process has its own micro development processes. The micro development process consists of the following steps: Identify classes and objects. Identify class and object semantics. Identify class and object relationships. Identify class and object interfaces and implementation.

The Jacobson Methodologies 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

MOKASHI PADMANABH PRAMOD 521106420

MC0083

Object-Oriented Software Engineering: Objectory Object-oriented software engineering (OOSE), also called Objectory, is a method of objectoriented 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.

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 problemdomain 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. Describe the scope of UML? What are the importances of UML process? Scope of UML The Unified Modeling Language (UML) is a language for specifying, constructing, visualizing, and documenting the artifacts of a software-intensive system. First and foremost, the Unified Modeling Language fuses the concepts of Booch, OMT, and OOSE. The result is a single, common, and widely usable modeling language for users of these and other methods. 7

MOKASHI PADMANABH PRAMOD 521106420

MC0083

Secondly, the Unified Modeling Language pushes the envelope of what can be done with existing methods. Thirdly, the Unified Modeling Language focuses on a standard modeling language, not a standard process. Although the UML must be applied in the context of a process, it is our experience that different organizations and problem domains require different processes. The UML specifies a modeling language that incorporates the object-oriented communitys consensus on core modeling concepts. It allows deviations to be expressed in terms of its extension mechanisms. The Unified Modeling Language provides the following: Semantics and notation to address a wide variety of contemporary modeling issues in a direct and economical fashion. Semantics to address certain expected future modeling issues, specifically related to component technology, distributed computing, frameworks, and executability. Extensibility mechanisms so individual projects can extend the metamodel for their application at low cost. We dont want users to directly change the UML metamodel. Extensibility mechanisms so that future modeling approaches could be grown on top of the UML. Semantics to facilitate model interchange among a variety of tools. Semantics to specify the interface to repositories for the sharing and storage of model artifacts.

Importance of UML process The Unified Modelling Language, or the UML, is a graphical modelling language that provides us with a syntax for describing the major elements (called artifacts in the UML) of software systems. In this course, we will explore the main aspects of the UML, and describe how the UML can be applied to software development projects. The UML is a graphical language for capturing the artifacts of software developments. The language provides us with the notations to produce models. The UML is gaining adoption as a single, industry wide language. The UML was originally designed by the Three Amigos at Rational Corp. The language is very rich, and carries with it many aspects of Software Engineering best practice. The UML is a language for Visualizing Specifying Constructing Documenting The vocabulary and rules of a language such as the UML tell you how to create and read wellformed 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 m create them and manage them, and how to use those artifacts to measure and control the project as a whole. 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 UM, and another developer, or even another tool, can interpret that model unambiguously. This addresses the first issue described earlier. The UML addresses the specification of all the important

MOKASHI PADMANABH PRAMOD 521106420

MC0083

analysis, design, and implementation decisions that must be made in developing and deploying a software intensive system. 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. 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. The UML is intended primarily for software-intensive systems. It has been used effectively for such domains as Enterprise information systems Banking and financial services Telecommunications Transportation Defense/aerospace Retail Medical electronics Scientific Distributed Web-based services The UML is not limited to modeling software. In fact, it is expressive enough to model nonsoftware systems, such as workflow in the legal system, the structure and behavior of a patient healthcare system, and the design of hardware.

6. What are the different types of actions? Explain about Collaborations. Action and different types of actions: An action is a specification of a computable statement. Each kind of action is defined as a subclass of action. The following kinds of actions are defined: Send action is an action in which a stimulus is created that causes a signal event for the receiver(s). Call action is an action in which a stimulus is created that causes an operation to be invoked on the receiver. Create action is an action in which an instance is created based on the definitions of the specified set of classifiers. Terminate action is an action in which an instance causes itself to cease to exist. Destroy action is an action in which an instance causes another instance to cease to exist. Return action is an action that returns a value to a caller. Uninterpreted action is an action that has no interpretation in UML.

Each action specifies the target of the action and the arguments of the action. The target of an action is an object set expression, which resolves into zero or more instances when the action is executed. The action also specifies if it should iterate over the set of target instances (recurrence).

MOKASHI PADMANABH PRAMOD 521106420

MC0083

The recurrence can also (in the degenerated case) be used for specification of a condition, which must be fulfilled if the action is to be applied to the target; otherwise, the request is neglected. The arguments of the action resolve into a sequence of instances when the action is executed. These instances are the actual arguments of (for example, the stimulus being dispatched by the action); that is, the instances passed with a signal or the instances used in an operation invocation. Collaboration: A collaboration can be used for specification of how an operation or a classifier, like a use case, is realized by an ensemble of classifiers and associations. A role in the collaboration specifies the required set of features a conforming instance must have. The collaboration also states what associations must exist between the participants, as well as what classifiers a participant, like a subsystem, must contain. A collaboration may be attached to an operation or a classifier, like a use case, to describe the context in which their behavior occurs. A collaboration describing an operation includes only the parameters and the local variables of the operation, as well as ordinary associations attached to the classifier owning the operation. The interactions defined within the collaboration specify the communication pattern between the instances when they perform the behavior specified in the operation or the use case. A collaboration may also be attached to a class to define its static structure; that is, how its attributes, parameters etc. cooperate with each other. If the collaboration represents an operation, the context includes things like parameters, attributes, and classifiers contained in the classifier owning the operation. The interactions then specify how the arguments, the attribute values, the instances etc. will cooperate to perform the behavior specified by the operation. If the collaboration is a specialization of another collaboration, all communications specified by the parent collaboration are also included in the child, as the child collaboration includes all the roles of the parent. New messages may be inserted into these sequences of communication, since the child may include specializations of the parent.s roles as well as new roles. The child may of course also include completely new interactions that do not exist in the parent. Collaboration may be a specification of a template. Collaboration templates may have parameters that act like placeholders in the template. These parameters would be used as base classifiers and associations, but other kinds of model elements can also be defined as parameters in the collaboration, like operation or signal. Collaboration may also contain a set of constraining model elements. These constraining model elements are used for expressing the extra constraints on the participating elements in the collaboration that cannot be covered by the participating roles themselves. For example, in a collaboration template it might be required that the base classifiers of two roles must have a common ancestor, or one role must be a subclass of another one. These kinds of requirements cannot be expressed with association roles, as the association roles express the required links between participating instances. An extra set of model elements may therefore be included in the collaboration.

10