CUSTOMER_CODE
SMUDE
DIVISION_CODE
SMUDE
EVENT_CODE
SMUAPR15
ASSESSMENT_CODE BC0057_SMUAPR15
QUESTION_TYPE
DESCRIPTIVE_QUESTION
QUESTION_ID
6066
QUESTION_TEXT What are the common mechanisms available in UML? Explain.
SCHEME OF
EVALUATION
Explanation of
Specifications (2.5 marks)
Adornments (2.5 marks)
Common divisions (2.5 marks)
Extensibility mechanisms (2.5 marks)
Specifications
The UML is more than just a graphical language. Rather, behind
every part, of its graphical notation there is a specification that
provides a textual statement of the syntax and semantics of that
building block. For example, behind a class icon is a specification
that provides the full set of attributes, operations (including their
full signatures), and behaviors that the class embodies; visually,
that class icon might only show a small part of this specification.
Furthermore, there might be another view of that class that
presents a completely different set of parts yet is still consistent
with the class's underlying specification. You use the UML's
graphical notation to visualize a system; you use the UML's
specification to state the system's details. Given this split, it's
possible to build up a model incrementally by drawing diagrams
and then adding semantics to the model's specifications or
directly by creating a specification, perhaps by reverse
engineering an existing system, and then creating diagrams that
are projections into those specifications.
Adornments
Most elements in the UML have a unique and direct graphical
notation that provides a visual representation of the most
important aspects of the element. For example, the notation for a
class is intentionally designed to be easy to draw, because classes
are the most common element found in modeling object-oriented
systems. The class notation also exposes the most important
aspects of a class, namely its name, attributes, and operations.
Common Divisions
In modeling object-oriented systems, the world often gets divided
in at least a couple of ways.
First, there is the division of class and object. A class is an
abstraction; an object is one concrete manifestation of that
abstraction. In the UML, you can model classes as well as objects.
Almost every building block in the UML has this some kind of
class / object dichotomy. For example, you can have use cases and
use case instances, components and component instances, nodes
and node instances, and so on. Graphically, the UML
distinguishes an object by using the same symbol as its class and
then simply underlying the object's name.
Second, there is the separation of interface and implementation.
An interface declares a contract, and an implementation
represents one concrete realization of that contract, responsible
for faithfully carrying out the interface's complete semantics. In
the UML, you can model both interfaces and their
implementations.
Extensibility Mechanisms
The UML provides a standard language for writing software
blueprints, but it is not possible for one closed language to ever be
sufficient to express all possible nuances of all models across all
domains across all time. For this reason, the UML is open-ended,
making it possible for you to extend the language in controlled
ways. The UML's extensibility mechanisms include
∙ Stereotypes
∙ Tagged values
∙ Constraints
A stereotype extends the vocabulary of the UML, allowing you to
create new kinds of building blocks that are derived from existing
ones but that are specific to your problem
A tagged value extends the properties of a UML building block,
allowing you to create new information in that element's
specification.
A constraint extends the semantics of a UML building block,
allowing you to add new rules or modify existing ones.
Collectively, these three extensibility mechanisms allow you to
shape and grow the UML to your project's needs. These
mechanisms also let the UML adapt to new software technology,
such as the likely emergence of more powerful distributed
programming languages.
QUESTION_TYPE
DESCRIPTIVE_QUESTION
QUESTION_ID
6068
QUESTION_TEXT Discuss the five core workflows of the Unified Process.
SCHEME OF
EVALUATION
Explanation of
Requirements workflow (2 marks)
Analysis workflow (2 marks)
Design workflow (2 marks)
Implementation workflow (2 marks)
Test workflow (2 marks)
The Requirements Workflow
The aim of the requirements workflow is to ensure that the
developers 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. One way to achieve this
is to use the Unified Process; the many models of the Unified
Process assist the client in gaining the necessary detailed
understanding of what is to be developed.
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 requirements that we must have to develop
an information system correctly and to maintain it easily. But
why do we have an analysis workflow at all? Surely 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 key point is that the output of the requirements workflow
must be totally comprehensible by the client. In other words, the
artifacts of the requirements workflow must be expressed in the
language of the client, that is, in a natural (human) language such
as English, Armenian, or Zulu.
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 artifacts.
As soon as a component has been coded, the programmer tests it.
Once the programmer is satisfied that the component is correct,
it is passed onto the quality assurance group for further testing.
The Test Workflow
The test workflow is the responsibility of the quality assurance
group. As pointed out at the end of the previous section, each
component is tested by the quality assurance group as soon as it
has been implemented; this is termed unit testing. At the end of
each iteration , integration testing is performed. Here, the
components that have been completed and unit tested are
compiled and linked together (integrated) and then tested against
various test cases. When the product appears to be complete, it is
tested as a whole; this is termed product testing.
When management believes that the product is fault-free, it is
installed on the client's computer. The client now performs
acceptance testing. That is, the client checks whether the
delivered information system satisfies its specifications. If the
information system passes the acceptance test, the client pays the
developers. If not, the developers have to fix the information
system until it passes the acceptance test.
QUESTION_TYPE
DESCRIPTIVE_QUESTION
QUESTION_ID
6069
QUESTION_TEXT Discuss in detail about the characteristics of objects
SCHEME OF
EVALUATION
Characteristics of objects
The objects have different characteristics that help you in
selecting them while programming. They are,
i . Objects are grouped in classes
ii. Objects have attributes and methods
iii. Objects respond to messages
( 1 mark)
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. ( 1 mark)
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 object's abstract state can be independent of
its physical representation. ( 2 marks)
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 ah 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, provide interfaces to the object, and hide any of the
internal structures and states maintained by the object.
( 2 marks)
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 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.
A message is different from a subroutine call, since different
objects can respond to the same message in different ways. 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.
Example: draw is a message given to different objects.
(4 marks)
QUESTION_TYPE
DESCRIPTIVE_QUESTION
QUESTION_ID
112449
Explain the following:
QUESTION_TEXT a.
b.
Information hiding
Polymorphism
a.
Information hiding is the principle of concealing the
internal data and procedures of an object and providing an interface
to each object in such a way as to reveal as little as possible about its
inner workings. C++ has a very general encapsulation protection
mechanism with public, private, and protected members. Public
members (member data and member functions) may be accessed
from anywhere. Private members are accessible one from within a
class. An object data representation, such as a list or an array, usually
will be private. Protected members can be accessed only from
subclasses.
SCHEME OF
EVALUATION
An important factor in achieving encapsulation is the design of
different classes of objects that operate using common protocol, or
object’s user interface. This means that many objects will respond to
the same message but each will perform the message using operations
tailored to its class.
Data abstraction is the benefit of the object-oriented concept that
incorporates encapsulation and polymorphism.
b.
Polymorphism
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.
QUESTION_TYPE
DESCRIPTIVE_QUESTION
QUESTION_ID
112456
QUESTION_TEXT
Explain layered Approach to Software Development.
Introduction – 1 mark
1.
Business layer – 3 marks
2.
Users Interface layer – 3 marks
3.
Access layer – 3 marks
SCHEME OF EVALUATION
QUESTION_TYPE
DESCRIPTIVE_QUESTION
QUESTION_ID
112457
QUESTION_TEXT
Explain the object oriented systems development activities.

Object oriented analysis – Use case driven

Object oriented design
SCHEME OF EVALUATION 


Prototyping
Component based development
Incremental testing