ASSIGNMENT

PROGRAM BSc IT
SEMESTER FIFTH
BT8901, Object Oriented Systems

CONTACT ME TO GET FULLY SOLVED SMU

ASSIGNMENTS/PROJECT/SYNOPSIS/EXAM GUIDE PAPER
Email Id: mrinal833@gmail.com
Contact no- 9706665251/9706665232/
www.smuassignmentandproject.com
COST= 100 RS PER SUBJECT

Q. No.1
Write a note on Principles of Object Oriented Systems.
ANSWER: Principles of Object Oriented Systems (OOS)
The object model comes with a lot of terminology. A Smalltalk programmer uses methods, a C++
programmer uses virtual member functions, and a CLOS programmer uses generic functions. Object
Pascal programmer talks of a type correct, an Ada programmer calls the same thing a type conversion. To
minimize the confusion, lets see what object orientation is.
Bhaskar has observed that the phrase object-oriented has been bandied about with carefree abandon with
much the same reverence accorded motherhood, apple pie, and structured programming. We can
agree that the concept of an object is central to anything object-oriented. Stefik and Bobrow define
objects as entities that combine the properties of procedures and data since they perform computations
and save local state. Defining objects as entities asks the question somewhat, but the basic concept here
is that objects serve to unify the ideas of algorithmic and data abstraction. Jones further clarifies this term
by noting that in the object model, emphasis is placed on crisply characterizing the components of the
physical or abstract system to be modeled by a programmer system. Objects have a certain integrity

which should not in fact, cannot be violated. An object can only change state, behave, be manipulated,
or stand in relation to other objects in ways appropriate to that object. An object is characterized by its
properties and behavior.
2 What are objects? Explain characteristics of objects.
ANSWER:
Characteristics of Objects
The different characteristics of the objects are:
i) Objects are grouped in classes
ii) Objects have attributes and methods
iii) Objects respond to messages
Lets explain these characteristics one by one.
i) Objects are grouped in classes
A class is a set of objects that share a common structure and a common behavior, a single object is simply
an instance of a class. A class is a specification of structure (instance variables), behavior (methods), and
inheritance for objects.
Attributes: Object state and properties
Properties represent the state of an object. For example, in a car object, the manufacturer could be
denoted by a name, a reference to a manufacturer object, or a corporate tax identification number. In
general, objects abstract state can be independent of its physical representation.
Fig. 2.2: The attributes of a car object
ii) Object behavior and methods
A method is a function or procedure that is defined for a class and typically can access the internal state
of an object of that class to perform some operation. Behavior denotes the collection of methods that
abstractly describes what an object is capable of doing. Each procedure defines and describes a particular
behavior of the object. The object, called the receiver, is that on which the method operates. Methods
encapsulate the behavior of the object. They provide interfaces to the object, and hide any of the internal
structures and states maintained by the object.
iii) Objects respond to messages
Objects perform operations in response to messages. The message is the instruction and the method is the
implementation. An object or an instance of a class understands messages. A message has a name, just
like method, such as cost, set cost, cooking time. An object understands a message when it can match the

message to a method that has a same name as the message. To match up the message, an object first
searches the methods defined by its class. If it is found, that method is called up. If not found, the object
searches the superclass of its class. If it is found in a superclass, then that method is called up. Otherwise,
it continues the search upward. An error occurs only if none of the superclasses contain the method.
Different objects can respond to the same message in different ways. In this way a message is different
from a subroutine call. This is known as polymorphism, and this gives a great deal of flexibility. A
message differs from a function in that a function says how to do something and a message says what to
do.

3 What are behavioral things in UML mode? Explain two kinds of behavioral things.
ANSWER: Behavioral things are the dynamic parts of UML models. These are the verbs of a model,
representing behavior over time and space. In all, there are two primary kinds of behavioral things.
1. Interaction
2. State Machine
Interaction: An interaction is a behavior that comprises a set of messages exchanged among a set of
objects within a particular context to accomplish a specific purpose. The behavior of a society of objects
or of an individual operation may be specified with an interaction. An interaction involves a number of
other elements, including messages, action sequences (the behavior invoked by a message), and links (the
connection between objects). Graphically, an interaction (message) is rendered as a directed line, almost
always including the name of its operation, as in Fig. 5.8.
Display
INTERACTION MESSAGE
State Machine: A state machine is a behavior that specifies the sequences of states an object or an
interaction that goes through during its lifetime in response to events, together with its responses to those
events. The behavior of an individual class or a collaboration of classes may be specified with a state
machine. A state machine involves a number of other elements, including states, transitions (the change
from one state to another state), events (things that trigger a transition), and activities (the response to a
transition). Graphically, a state is rendered as a rounded rectangle, usually including its name and its sub
states.

These two elements are the basic behavioral things that you may include in a UML model. Semantically,
these elements are usually connected to various structural elements, primarily classes, collaborations, and
objects.

4 Write a short note on Class-Responsibility-Collaboration (CRC) Cards

ANSWER: Since 1990, class-responsibility-collaboration (CRC) cards have been utilized during objectoriented analysis and design (Wirfs-Brock, Wilkerson, and Wiener, 1990]. For each class, the information
system development team fills in a card showing the name of the class, the functionality of that class (its
responsibility), and a list of the other classes it invokes in order to achieve that functionality (its
collaboration).
CRC cards were originally introduced as a tool for performing requirements elicitation and analysis. CRC
cards are indeed a powerful tool for this purpose, but only when the information technology professionals
are familiar with the domain; that is, the specific business environment in which the information system is
to operate, such as aerospace, banking, or cloth manufacturing. However, even for information
technology professionals who have no domain expertise whatsoever, CRC cards are an extremely
effective way of testing object-oriented analysis and design artifacts.
An example of a CRC card is shown in Table 11.2. The data for this figure are obtained from the
realizations of all the use cases of the STAR Foundation case study. First look at Fig.10.11 in the previous
unit. Message 7: Request estimated grants and payments for week is passed from :Estimate Funds
for Week Class to :Mortgage Class, followed by message 8: Return estimated grants and payments for
week in the reverse direction. We conclude that Mortgage Class has the responsibility Compute
estimated grants and payments for week and, in order to do this, must collaborate with Estimate Funds
for Week Class. This is reflected in the first entry in the CRC card.
Table 11.2: A CRC Card for Class Mortgage Class CLASS
Mortgage Class
RESPONSIBILITY
Compute estimated grants and

COLLABORATION
Estimate Funds for Week Class

payments for week

Initialize, update,

Manage an Asset Class

and

delete

mortgages
Generate list of mortgages
User Interface Class
Print list of mortgages
Mortgages Report Class
Now consider Fig.10.18. Message 3: Update tax and date is passed from :Manage an Asset Class
to :Mortgage Class after which message 4: Send successful completion message is passed back.

However, turning to the class diagram of Fig.10.2, we see that, in addition to attribute
annualRealEstateTax, Mortgage Class has seven other attributes that might need to be changed by
:Manage an Asset Class. In fact, a complete set of scenarios will include all 16 sets and get operations.
Each of the 16 scenarios in turn requires an interaction diagram of its realization; Fig.10.18 is one of the
16 required interaction diagrams. In addition, managing a mortgage includes two operations namely,
adding a new mortgage and deleting an existing mortgage. For brevity, we will combine all these
responsibilities into responsibility Initialize, update, and delete mortgages with collaborator Manage an
Asset Class. This is the second entry in the CRC card.
Now, we turn to Fig.10.21. Here we find message 3: Update income and date passed from :Manage an
Asset Class to :Mortgage Class. Message 4: Send successful completion message is then passed back.
As pointed out in the previous paragraph, combinedWeeklyIncome is one of the eight attributes of
Mortgage Class that might need to be changed by :Manage an Asset Class. Thus, this responsibility is
already included in Initialize, Update, and delete mortgages.
Finally we turn to Fig. 10.32. There we see message 2: Transfer request [for list of mortgages] passed
from :User Interface Class to :Mortgage Class. Thus, Mortgage Class has the responsibility Generate
list of mortgages with collaborator User Interface Class, the third entry in the CRC card. Also, message
3: Print list of mortgages is passed from :Mortgage Class to :Mortgage Report Class. We deduce that
Mortgage Class also has the responsibility Print list of mortgages with collaborator Mortgages Report
Class, the fourth entry in the CRC card.
As a check, we now examine Fig. 10.38 and see that there are five classes with which Mortgage Class
has a relationship, namely, User Interface Class, Estimate Funds for Week Class, Mortgages Report
Class, Asset Class, and Manage an Asset Class. We know from the realizations that Mortgage Class
has no responsibility with Asset Class. We see that all four of the remaining classes are listed in the
COLLABORATION column of Table 11.4. This does not necessarily mean that we have included every
responsibility of every collaboration class, but it is likely that all the collaboration classes have been
included.
The CRC card technique has subsequently been extended.
First, a CRC card nowadays often explicitly contains the attributes and operations of the class, rather
than just its responsibility expressed in some natural language like English. That is, the CRC card
essentially contains the information of the complete class diagram.
Second, the technology has changed. Instead of using cards, some organizations put the names of the
classes on Post-it notes that they then move around on a white board; lines are drawn between the Post-it
notes to denote collaboration. Nowadays the whole process can be automated; CASE tools such as
System Architect include modules for creating and updating CRC cards on the screen.

The strength of CRC cards is that, when utilized by a team, the interaction between the members can
highlight missing or incorrect fields in a class, whether attributes or operations. Also, relationships
between classes are clarified when CRC cards are used. One especially powerful technique is to distribute
the cards among the team members who then act out the responsibilities of their classes. Thus, someone
might say, I am the Date class and my responsibility is to create new date objects. Another team
member might then interject that he or she needs additional functionality from the Date class, such as
converting a date from the conventional format to an integer, the number of days from January 1, 1990, so
that finding the number of days between any two dates can easily be computed by subtracting the
corresponding two integers. Thus, acting out the responsibilities of CRC cards is an effective means of
verifying that the classes are correct.

5 Explain Modern Hierarchical Teams. Also draw its structure.

ANSWER:
Modern Hierarchical Teams
As just mentioned, the problem with traditional programmer teams is that it is all but impossible to find
one individual who is both a highly skilled programmer and a successful manager. The solution is to use a
matrix organizational structure and to replace the chief programmer by two individuals: a team leader,
who is in charge of the technical aspects of the teams activities, and a team manager, who is responsible
for all non-technical managerial decisions. It is important to realize that this organizational structure does
not violate the fundamental managerial principle that no employee should report to more than one
manager. The areas of responsibility are clearly delineated. The team leader is responsible for only
technical management. Thus, budgetary and legal issues are not handled by the team leader, nor are
performance appraisals. On the other hand, the team leader has sole responsibility on technical issues. The
team manager, therefore, has no right to promise, say, that the information system will be delivered within
four weeks; promises of that sort have to be made by the team leader.
Before implementation begins, it is important to demarcate clearly those areas that appear to be the
responsibility of both the team manager and the team leader. For example, consider the issue of annual
leave. The situation can arise that the team manager approves a leave application because leave is a nontechnical issue, only to find the application vetoed by the team leader because a deadline is approaching.
The solution to this and related issues is for higher management to draw up a policy regarding those areas
that both the team manager and the team leader consider to be their responsibility.

6 Explain in brief the five levels of CMM.

ANSWER:
The capability maturity models (CMMs) of the Software Engineering Institute are a related group of
strategies for improving the process for developing information systems, irrespective of the actual lifecycle model used. (The term maturity is a measure of the goodness of the process itself.) The Software
Engineering Institute has developed CMMs for software (SW-CMM), for management of human
resources (P-CMM; the P stands for people), for systems engineering (SE-CMM), for integrated
product development (IPD-CMM), and for software acquisition (SA-CMM). There are some
inconsistencies between the models and an inevitable level of redundancy.
To understand this approach, the five levels are now described.
Maturity Level 1: (Initial Level) At this lowest level, essentially no sound information system
management practices are in place in the organization. Instead, everything is done on an adhoc basis. A
specific project that happens to be staffed by a competent manager and a good information system
development team may be successful. However, the usual pattern is time and cost overruns caused by a
lack of sound management in general and planning in particular. As a result, most activities are responses
to crises rather than preplanned tasks. In level 1 organizations, the process is unpredictable, because it
depends totally on the current information technology professionals; as the professionals change, so does
the process. As a consequence, it is impossible to predict with any accuracy such important items as the
time it will take to develop an information system or the cost of that information system.
It is unfortunate that the vast majority of information system development organizations all over the
world are still level 1 organizations.
Maturity Level 2: (Repeatable Level) At this level, basic information system project management
practices are in place. Planning and management techniques are based on experience with similar
information systems; hence, the name repeatable. At level 2, measurements are taken, an essential first
step in achieving an adequate process. Typical measurements include the careful tracking of costs and
schedules. Instead of functioning in crisis mode as in level 1, managers identify problems as they arise
and take immediate corrective action to prevent them from becoming crises. The key point is that, without
measurements, it is impossible to detect problems before they get out of hand. Also, measurements taken
during one project can be used to draw up realistic duration and cost schedules for future projects.
Maturity Level 3: (Defined Level) At level 3, the process for information system development is fully
documented. Both the managerial and technical aspects of the process are clearly defined, and continual

efforts are made to improve the process wherever possible. Inspections are used to achieve information
system quality. At this level, it makes sense to introduce new technology such as CASE environments to
increase quality and productivity further. In contrast, high tech only makes the crisis-driven level 1
process even more chaotic.
Although a number of organizations have attained maturity levels 2 and 3, not many have reached levels 4
or 5. For most companies, therefore, the two highest levels are targets for the future.
Maturity Level 4: (Managed Level) A level 4 organization sets quality and productivity goals for each
project. These two quantities are measured continually and corrective action is taken when there are
unacceptable deviations from the goal. Statistical quality controls [Deming, 1986] are in place to enable
management to distinguish a random deviation from a meaningful violation of quality or productivity
standards. (A simple example of a statistical quality control measure is the number of faults detected per
1,000 lines of code. A corresponding objective is to reduce this quantity over time.)
Maturity Level 5: (Optimizing Level) The goal of a level 5 organization is continuous process
improvement. Statistical quality and process control techniques are used to guide the organization. The
knowledge gained from each project is utilized in future projects. The process thus incorporates a positive
feedback loop, resulting in a steady improvement in productivity and quality.

CONTACT ME TO GET FULLY SOLVED SMU

ASSIGNMENTS/PROJECT/SYNOPSIS/EXAM GUIDE PAPER
Email Id: mrinal833@gmail.com
Contact no- 9706665251/9706665232/
www.smuassignmentandproject.com
COST= 100 RS PER SUBJECT