ignou mca 3rd sam mcs 032 solved assignment 2011

IGNOU Solved Assignment of MCS-032

Course Code                        :        MCS-032

Course Titlle                         :        Object Oriented Analysis and Design

Assignment Number          :        MCA(3)/032/Assign/2011

Assignment Marks              :        100

Weightage                            :        25%

Last Date of Submission   :        30th April, 2011 (for January session)

                                                      31st October, 2011 (for July session)

Question 1 :             What is Object Orientation? Explain advantages of Object Oriented

                          approach  of system  design  over Structured approach of system

                        design.

Ans  :  Object-orientation  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 characterised 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-modelling 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.

The object-oriented approach has the following advantages: when the expert system is large, complexity is reduced through modularization, that is, by subdividing the system into manageable size components, such as objects, and establishing well-defined relationships between them. The internal design of each object is localised so that it does not depend on the internal design of another component. The design concepts are separated from the implementation details.

That means that rules are developed separately from the objects that they manipulate. Objects can be reused. They are written and debugged once, and then matched to form new applications.

Object-oriented programming (OOP) is a programming paradigm that uses "objects" and their interactions to design applications and computer programs.

Object Oriented Development (OOD) has been touted as the next great advance in software engineering. It promises to reduce development time, reduce the time and resources required to maintain existing applications, increase code reuse, and provide a competitive advantage to organizations that use it.

The key ideas of the object oriented approach are :

    * Encapsulation

    * Objects

    * Class and Inheritance

    * Instances and Instantiation

    * Methods and Messages

Some important features of Object Oriented programming are as follows:

    * Emphasis on data rather than procedure

    * Objects can communicate with each other through functions

    * Programs are divided into Objects

    * New data and functions can be easily added whenever necessary

    * Data is hidden and cannot be accessed by external functions

    * Follows bottom-up approach

Advantages of Object Oriented Development (OOD)

Simplicity: software objects model real world objects, so the complexity is reduced and the program structure is very clear.

Reusability: Reusability is a desired goal of all development and is based on the reluctance of reinventing something when it has already been invented. Objects contain both data and functions that act on data, objects can be thought of as self-contained "boxes" (encapsulation). This feature makes it easy to reuse code in new systems. Messages provide a predefined interface to an object's data and functionality. If you know this interface, you can make use on an object in any context you want. OOP languages, such as C# , make it easy to expand on the functionality of these "boxes", even if you don't know much about their implementation.

Increased Quality: Increases in quality are largely a by-product of this program reuse. If 90% of a new application consists of proven, existing components, then only the remaining 10% of the code has to be tested from scratch. That observation implies an order-of-magnitude reduction in defects.

Faster Development: OOD (Object oriented development) leads to faster development. Many of the claims of potentially reduced development time are correct in principle.

Maintainable: OOP methods make code more maintainable. Objects can be maintained separately, making locating and fixing problems easier. The principles of good OOP design contribute to an application's maintainability.

Scalable: Object oriented applications are more scalable then structured approach. As an object's interface provides for reusing the object in new software, it also provides all the information needed to replace the object without affecting other code. This makes it easy to replace old and aging code with faster algorithms and newer technology.

Modularity: Object-oriented systems have a natural structure for modular design: objects, subsystems, framework, and so on. Thus, OOD systems are easier to modify. OOD systems can be altered in fundamental ways without ever breaking up since changes are neatly encapsulated.

Modifiability: It is easy to make minor changes in the data representation or the procedures in an OO program. For example, the year 2000 (Y2K) problem may have been eliminated by identifying a date object within a system and accessing this object when you needed to date an operation. If the date object had the state variables of month, day and year with each defined as two-character variables, the only change that would be necessary to correct the Y2K problem was to change the year state variable of only the date object.

Client/Server Architecture: Client/server applications involve transmission of messages back and forth over a network, and the object-message paradigm of OOD meshes well with the physical and conceptual architecture of client/server applications.

Question 2 : Briefly explain , need of different UML Diagrams.   

Ans : Modeling is an activity that has been carried out over the years in software development. When writing applications by using the simplest languages to the most powerful and complex languages, you still need to model. Modeling can be as straightforward as drawing a flowchart listing the steps carried out by an application. Why do we use modeling? Defining a model makes it easier to break up a complex application or a huge system into simple, discrete pieces that can be individually studied. We can focus more easily on the smaller parts of a system and then understand the "big picture." Hence, the reasons behind modeling can be summed up in two words:

    * Readability

    * Reusability

Readability brings clarity—ease of understanding. Understanding a system is the first step in either building or enhancing a system. This involves knowing what a system is made up of, how it behaves, and so forth. Modeling a system ensures that it becomes readable and, most importantly, easy to document. Depicting a system to make it readable involves capturing the structure of a system and the behavior of the system.

Reusability is the byproduct of making a system readable. After a system has been modeled to make it easy to understand, we tend to identify similarities or redundancy, be they in terms of functionality, features, or structure.

Even though there are many techniques and tools for modeling, in this article series, we will be concerning ourselves with modeling object-oriented systems and applications using the Unified Modeling Language. The Unified Modeling Language, or UML, as it is popularly known by its TLA (three-letter acronym!), is the language that can be used to model systems and make them readable. This essentially means that UML provides the ability to capture the characteristics of a system by using notations. UML provides a wide array of simple, easy to understand notations for documenting systems based on the object-oriented design principles. These notations are called the nine diagrams of UML.

   

So the question arises, Why is UML the preferred option that should be used for modeling? Well, the answer lies in one word: "standardization!" Different languages have been used for depicting systems using object-oriented methodology. The prominent among these were the Rumbaugh methodology, the Booch methodology, and the Jacobson methodology. The problem was that, although each methodology had its advantages, they were essentially disparate. Hence, if you had to work on different projects that used any of these methodologies, you had to be well versed with each of these methodologies. A very tall order indeed! The Unified Modeling Language is just that. It "unifies" the design principles of each of these methodologies into a single, standard, language that can be easily applied across the board for all object-oriented systems. But, unlike the different methodologies that tended more to the design and detailed design of systems, UML spans the realm of requirements, analysis, and design and, uniquely, implementation as well. The beauty of UML lies in the fact that any of the nine diagrams of UML can be used on an incremental basis as the need arises. For example, if you need to model requirements for a given system, you can use the use case diagrams only without using the other diagrams in UML. Considering all these reasons, it is no wonder that UML is considered "the" language of choice.

UML does not have any dependencies with respect to any technologies or languages. This implies that you can use UML to model applications and systems based on either of the current hot technologies; for example, J2EE and .NET. Every effort has been made to keep UML as a clear and concise modeling language without being tied down to any technologies.

This series aims to cover the basics of UML, including each of the nine diagrams of UML. In addition, you will get to learn about the tools available that support UML. At the end of each article, we will incrementally build each of the nine UML diagrams for a case study system in the coming weeks. We will wrap our study of UML by expanding into two different areas—Rational Unified Process and Design Patterns.

Question 3 : Explain how  class diagrams are designed in an  object oriented  system,  with the help of an  example.  

Ans : Class diagrams are often used in object oriented analysis and design  to show the various identified objects , their types (classes) , their data and operations and how the relate , or communicate with other objects or classes. Here are some of the standard UML conventions and a sample class diagram to get you started:

Identify the classes in the problem domain:

 This is the first and most important step for creating the class diagram. What classes should you include and how to identify them given a problem statement or a scenario? The solution is simple and some time should be spent with the client / system engineers /your teacher in case you are making an academic project or any concerned authority having the required business knowledge.The first step however is creating a problem statement or establishing a set of requirements that the software should fulfill. E.g. you need to create a small library management system. What are some of the requirements for the system? Let’s try to make a problem statement or the scenario for your design. For the sake of simplicity considers the following simple problem Statement. “The library management system would be used by the librarian to keep track of books, library members and the borrowing activity. Not all books can be borrowed by the members. Some books may only be available to review in the library; all such books are termed as Reference books. There are 2 types of library members students and college faculty members. Faculty members can also check out research papers and magazines where as students can only checkout books. The system need to send alerts whenever a book that has to be returned within a specific date is not returned. An email is sent to the librarian and the borrower. The system maintains a catalogue having a description of each book that is available in the library”

Ways to identify Classes:

 Do the Noun Analysis: Go through the problem statement again and again and try to figure out all the nouns that you come across. In our case some strong contenders for the classes of the library management system would be: Librarian,Book,Member,Catalogue,Student_Member,Faculty_Member,Reference_Book,Issueable_Book,Alert

Perhaps there might be some nouns that I skipped but why??  I did that intentionally because of either of the two reasons. Either there is no data associated with them. They have no role to play in the system i.e. they don’t have any functions or actions associated with them. So by this we mean that “In order for a noun to be an object or a class it should have some attributes or member data and some actions or member functions.

 Resolving the relationships between classes:

Object oriented analysis and design is all about relationships between objects. Look for a certain type of relationships. These include generalization/inheritance/specialization, composition / containership, aggregation/ collections and associations. All of these are explained briefly below and discussed in terms of our scenario. There are some key questions associated with object oriented design over here.  How data is passed between the classes? What classes should have the objects of another class?What classes create the objects of other classes?What are some of the utility classes that the application requires? All these questions play an important role in the design. Think in terms of hierarchy for generalizations/inheritence:First of all check for hierarchy that may exist between the classes or the objects.This would model the inheritance or generaliztion or the superclass/subclass relationship.In natural language this might resolve to “type of” or “can be”. If you find such words in a problem statement there might be a case of generalization. E.g. In our scenario take the three classes BOOK , REFERENCE_BOOK and ISSUEABLE_BOOK . So a book can be a reference book or an issue able book or you can say that reference books and issue able books are the type of books. They all should ideally share many characteristics which are common to all the three classes.What I mean to say is, whether it is any book (reference or issue able) they all have ISBN number, author a language, a topic e.t.c so what is the difference. The difference is implied by the business rule that reference books cannot be issued but only reviewed. So for reference books we might add a Boolean data member called m_bReference and set it to true or something. Same is the case with Member, Student_Member and Faculty_Member. Inheritance is indicated in the class diagram with a filled black triangle pointing towards the base class and connecters connecting it to all the derived classes. In our scenario the inheritance could be shown as the figure below:

 Think of the Part-Whole Relationships:

Ok so now you know what might be the possible hierarchies in your system and what might be the common data members and the common functions. What are the differences and how the qualify to be another class. Another important type of relationship in terms of Object Oriented Analysis and Design is the “Part of” or “Part Whole” relationship. In Natural language, you might come across “has a” words to quickly identify these kind of relationships. In the list of candidate classes observe which of the objects the part of other objects is. This can also be taken as collection.To give you some examples for common scenarios. A Windows form is a collection of many controls.An automobile is composed of many parts.A shopping cart has many itemsA university is comprised of many campuses Here you want to ask a simple question to resolve the type of relationship and to know whether it is an aggregation or a composition. “Is the whole destroyed when the part is destroyed” or “It doesn’t make a difference to the Whole if the part is destroyed”. Now going through this example list. A form would still exist if any of the control is destroyed; the form serves it purpose properly. This implies an aggregation .An automobile wont function properly if any of its parts are destroyed e.g. it cannot function if the tires, steering, battery is taken out so this implies composition. A university will still exist if a campus is destroyed. So it depends upon the scenario and the business rules.

Returning to our depicted scenario the only part whole relationship noticeable is perhaps the catalogue. A catalogue has list of books available in the system with a short description of each. The catalogue is not destroyed if a book is destroyed so I would use aggregation in the design. In UML aggregation is shown with an empty diamond where as composition is shown with a solid black diamond.

Question 4 :      What is specialization ? Explain how it is different from  generalisation.

Ans : There is a need to store the objects in a system persistent. This is often done by the help of a Database Management System (DBMS). Database specialization means that a DBMS product is integrated in the development of a system. The specialization of OOSE will vary according to the type of DBMS being used. The requirements model and analysis model can be studied for decisions about which objects are to be stored persistent. Since entity objects in the analysis model typically hold information that 'survives' a use case, the entity objects are major candidates for persistent storage. There is also a need to store other kinds of objects such as objects for handling interfaces etc.

The dominant type of DBMS used in industry today are relational databases (RDBMS). In such a databases, information is stored in tables. This causes a number of problems. First, the information in object-oriented systems are stored in objects. When using a RDBMS there is therefore a need to convert the object information structure into a table-oriented structure. This problem is sometimes referred to as the impedance problem. Another problem is that using a RDBMS creates a strong coupling between the application and the DBMS, and to make design minimally affected by the DBMS, as few parts of the system as possible should know about the DBMS' interface. A third problem is how to express inheritance in the database. The behavior of the objects need then to be handled by the programming language, and the data will be expressed in the database.

 Generalization is the process of extracting shared characteristics from two or more classes, and combining them into a generalized superclass. Shared characteristics can be attributes, associations, or methods.

04

In Figure 4.27, the classes Piece of Luggage (1) and Piece of Cargo (2) partially share the same attributes. From a domain perspective, the two classes are also very similar. During generalization, the shared characteristics (3) are combined and used to create a new superclass Freight (4). Piece of Luggage (5) and Piece of Cargo (6) become subclasses of the class Freight.

05

The shared attributes (3) are only listed in the superclass, but also apply to the two subclasses, even though they are not listed there.

Figure 4.27 Example of generalization

In contrast to generalization, specialization  means creating new subclasses from an existing class. If it turns out that certain attributes, associations, or methods only apply to some of the objects of the class, a subclass can be created. The most inclusive class in a generalization/specialization is called the superclass and is generally located at the top of the diagram. The more specific classes are called subclasses and are generally placed below the superclass.

09

In Figure 4.28, the class Freight (1) has the attribute Degree of Hazardousness (2), which is needed only for cargo, but not for passenger luggage. Additionally (not visible in Figure 4.28), only passenger luggage has a connection to a coupon. Obviously, here two similar but different domain concepts are combined into one class. Through specialization the two special cases of freights are formed: Piece of Cargo (3) and Piece of Luggage (4). The attribute Degree of Hazardousness (5) is placed where it belongs—in Piece of Cargo. The attributes of the class Freight (1) also apply to the two subclasses Piece of Cargo (3) and Piece of Luggage (4):

Figure 4.28 Example of specialization

So much for the mechanism. However, the domain meaning of the relationship between superclass and subclass is much more important. These rules apply to this relationship:

13

    * All statements that are made about a superclass also apply to all subclasses. We say that subclasses “inherit” attributes, associations, and operations from the superclass. For example: If the superclass Freight has an attribute Weight, then the subclass piece of luggage also has an attribute Weight, even though this attribute is not listed in the subclass Piece of Luggage.

    * Anything that can be done with an object of the superclass can also be done with an object of the subclass. For example: If freight can be loaded, pieces of luggage can also be loaded.

    * In the terminology of the system that is being modeled, a subclass has to be a special form of the superclass. For example: A piece of luggage is a special case of freight. The counter-example to this is: A flight is not a special case of a flight number.

Question 5 : What is Object Oriented modeling? Explain object model. Also

                           explain how it is different from dynamic model . 

Ans : Object-Oriented Modeling, or OOM, (Object Oriented Programming - OOP)is a modeling paradigm mainly used in computer programming. Prior to the rise of OOM, the dominant paradigm was procedural programming, which emphasized the use of discreet reusable code blocks that could stand on their own, take variables, perform a function on them, and return values.

The Object-Oriented paradigm assists the programmer to address the complexity of a problem domain by considering the problem not as a set of functions that can be performed but primarily as a set of related, interacting Objects. The modeling task then is specifying, for a specific context, those Objects (or the Class the Objects belongs to), their respective set of Properties and Methods, shared by all Objects members of the Class. For more discussion, see Object-oriented analysis and design and Object-oriented programming. The description of these Objects is a Schema.

As an example, in a model of a Payroll System, a Company is an Object. An Employee is another Object. Employment is a Relationship or Association. An Employee Class (or Object for simplicity) has Attributes like Name, Birthdate, etc. The Association itself may be considered as an Object, having Attributes, or Qualifiers like Position, etc. An Employee Method may be Promote, Raise, etc.

The Model description or Schema may grow in complexity to require a Notation. Many notations have been proposed, based on different paradigms, diverged, and converged in a more popular one known as UML.

An informal description or a Schema notation is translated by the programmer or a CASE tool in the case of Schema notation (created using a Module specific to the CASE tool application) into a specific programming language that supports object-oriented programming (or a Class Type), a declarative language or into a database schema.

In computing, object model has two related but distinct meanings:

   1. The properties of objects in general, in a specific computer programming language, technology, notation or methodology that uses them. For example, the Java object model, the COM object model, or the object model of OMT. Such object models are usually defined using concepts such as class, message, inheritance, polymorphism, and encapsulation. There is an extensive literature on formalized object models as a subset of the formal semantics of programming languages.

   2. A collection of objects or classes through which a program can examine and manipulate some specific parts of its world. In other words, the object-oriented interface to some service or system. Such an interface is said to be the object model of the represented service or system. For example, the Document Object Model (DOM) [1] is a collection of objects that represent a page in a web browser, used by script programs to examine and dynamically change the page. There is a Microsoft Excel object model [2] for controlling Microsoft Excel from another program, and the ASCOM Telescope Driver [3] is an object model for controlling an astronomical telescope.

Difference between object model and dynamic model :----

1.object modeling is used to specify structure of the

objects that exist in the problem domain. These are

expressed using class, object and USECASE diagrams.

 Dynamic modeling refers representing the object

interactions during runtime. It is represented by sequence,

activity, collaboration and statechart diagrams

2.Object-Oriented Modeling, or OOM, (Object Oriented Programming - OOP)is a modeling paradigm mainly used in computer programming. Prior to the rise of OOM, the dominant paradigm was procedural programming, which emphasized the use of discreet reusable code blocks that could stand on their own, take variables, perform a function on them, and return values.

A system has an architecture based on a dynamic object model when it stores the object model for itself in a way that can be modified dyanmically. This means it will have classes like "Class", "Attribute", and "Association". I've run into a bunch of systems recently that have a dynamic object model, and have been trying to document them. Sometimes I have called this idea an "active object model", "metadata driven system", or "user defined products". See the papers The Dynamic Object Model Architecture and The User Defined Product Framework.

Question 6 : What is state diagram ? Differentiate between a simple state diagram and a   composite state diagram with an example.

Ans : A state diagram is a type of diagram used in computer science  and related fields to describe the behavior of systems. State diagrams require that the system described is composed of a finite number of states; sometimes, this is indeed the case, while at other times this is a reasonable abstraction. There are many forms of state diagrams, which differ slightly and have different semantics.State diagrams are used to give an abstract description of the behavior of a system. This behavior is analyzed and represented in series of events, that could occur in one or more possible states. Hereby "each diagram usually represents objects of a single class and track the different states of its objects through the system".

State diagrams can be used to graphically represent finite state machines. This was introduced by Taylor Booth in his 1967 book "Sequential Machines and Automata Theory". Another possible representation is the State transition table.

The UML state diagram is essentially a Harel statechart with standardized notation

 which can describe many systems, from computer programs to business processes. The following are the basic notational elements that can be used to make up a diagram:

    * Filled circle, pointing to the initial state

    * Hollow circle containing a smaller filled circle, indicating the final state (if any)

    * Rounded rectangle, denoting a state. Top of the rectangle contains a name of the state. Can contain a horizontal line in the middle, below which the activities that are done in that state are indicated

    * Arrow, denoting transition. The name of the event (if any) causing this transition labels the arrow body. A guard expression may be added before a "/" and enclosed in square-brackets ( eventName[guardExpression] ), denoting that this expression must be true for the transition to take place. If an action is performed during this transition, it is added to the label following a "/" ( eventName[guardExpression]/action ).

    * Thick horizontal line with either x>1 lines entering and 1 line leaving or 1 line entering and x>1 lines leaving. These denote join/fork, respectively.

Difference  between a simple state diagram and a composite state diagram with an example ---

Simple State--

Simple state has no regions and is not associated to a state machine. The region list and submachine list in the property panel is always empty.

Composite State--

Composite States make visual use of the second compartment that encloses refinements of the given state. Enclosed states don't have to have an initial state. Ingoing as well as outgoing transitions might be connected directly to one of them. When the corresponding object is in the composite state, it is exactly in one of the sub-states (OR relation).

In a composite state, the second compartment of the state has exactly one region

Question 7 : (a) What is  Bi-directional  Implementation? Explain advantages of Bi-

                            directional Implementation with example.

Ans : In a bidirectional implementation, alerts from the alert records are passed through the gateway via the TCP Echo Utility to the Netcool/OMNIbus. Any subsequent changes to those alerts or cases are reflected in the other application. Therefore, changes to alerts in Netcool/OMNIbus are reflected in related Clarify cases and changes to Clarify cases are reflected in related alerts.

A bidirectional wavelength path switched ring is proposed to provide 1:1 system protection for digital client layer such as a SONET system. This WDM ring has advantages in both the required number of wavelengths and optical signal-to-noise ratio. A distributed control scheme is suggested to implement this ring architecture. This scheme requires no signaling between nodes for indicating failure and works fast enough to satisfy the higher layered SONET system's switching requirement

When using bi-directional shared trees, data can flow in either direction on a branch of the tree. This allows improved data delivery    to receivers close to the source because the traffic travelling upstream to the root node is "turned around" and forwarded on downstream branches

 (b) Explain how constrains are implemented in Object Oriented Systems.

Ans : The purpose of consistency constraints (CCs) is to restrict the database states (or sequences

thereof) to those that are considered as legal. Therefore, constraints as present in the modeled

miniworld have to be expressed in a formal way, i.e., must be made known to the DBS.

In general, consistency constraints can be classified according to where they are specified

into internal and external consistency constraints.

Internal CCs are those that are known to and can be enforced by the DBS, while external

CCs have to be expressed, checked, and enforced within application programs. Internal CCs

can be subdivided into the following three types [7]:

• inherent consistency constraints: they are fixed for a given data model and therefore do not

have to be specified (e.g., absence of cycles in inheritance relationships),

• implicit consistency constraints: they can be specified in the schema using specific constructs

(keywords) of the data definition language (DDL), e.g., the identification of unique

properties,

• explicit consistency constraints: they are formulated in a separate sublanguage of the DDL,

the constraint definition language, either as predicates in a declarative language or by

means of triggers. As an example, consider the typical consistency constraint that employees

may not earn more than their manager.

Another classification of consistency constraints is based on whether only single database

states or even database state transitions can be constrained [7]:

• static consistency constraints consider only single states of a database,

• dynamic CCs allow to constrain state transitions, i.e., they specify which transformations

of database states into new ones are allowed. In the general case, dynamic CCs constrain

arbitrary sequences of state transitions. Two-state transitions are a special case.

Page 3

Finally, the third relevant classification of consistency constraints determines which properties

of entities can be subject to constraints:

• state constraints specify conditions on the values (states) of entities,

• behavioral constraints further allow to constrain the behaviour of entities, e.g., specify correct

semantics of methods.

Note that the last two classification dimensions are orthogonal to each other.

2.2 Programming by Contract

PbC [15, 16] is an approach to achieve correct and robust object-oriented, modular programs.

In addition to the usual parts of class definitions, preconditions, postconditions, and class invariants

are specified.

In PbC, preconditions define the conditions that must be fulfilled in order to execute a method

correctly. Preconditions are formulas over the state of the receiver and the arguments of the

message. Postconditions constrain the state of the receiver object after method execution as

well as the results of the method. Postconditions are formulas over the final state, the initial

state, and the output parameters. Note that in postconditions the old state of the receiver can be

referred to, although the initial state might be modified by a method. Syntactically, the old value

of an instance variable can be referred to through the keyword old. Together, preconditions

and postconditions define a contract:

• the precondition defines the conditions the sender of a message has to obey,

• the postcondition defines what the receiver (the server) is obliged to produce.

Constraints that are not specific for a method but restrict the permissible states of any object of

a class can be defined through invariants. An invariant is attached to its class and is guaranteed

to hold at the end of each method execution for any instance of the class.

----------------------------------------------The End------------------------------------------