1-What is the Difference between Sequence Diagram and Communication

Diagram in UML?
Sequence and Communication diagrams both aim at describing the dynamic interactions between objects. The
information you can describe are basically the same, but the two models have a different focus:

Sequence diagrams highlight more the temporal aspect, by showing invocation and responses along a (vertical)
timeline and by explicitly showing the activation time of objects. Sequence diagrams show how objects
communicate with each other in terms of a temporal sequence of messages. The time flow is the most visible
aspect in these diagrams, as messages are sequenced according to a vertical timeline and also the lifespan of
objects associated to those messages is reported. The figure below (taken from A book) shows an example of a
sequence diagram describing 3 objects (instances of classes Shipment, Invoice and Part List) and the messages
exchanged between each other. Interaction diagrams describe execution scenarios of the system.

Communication diagrams aim at showing the communications that happen between objects, by defining
messages that flow between each other. They basically consist of superimposing the communication actions
upon an object diagram. The temporal aspect can be shown here too, by numbering the interactions with
sequential labels. A Communication diagram shows the interactions between objects or classes in terms of
links (solid undirected lines connecting the elements that can interact) and messages that flow through the
links. This describes at the same time some kind of static structure (links and nodes) and dynamic behavior
(messages) of the system. An example is shown below.

1: In Sequence diagrams we can show Synchronous as well as Asynchronous messages.

2: In Communication Diagram we can only show Synchronous messages. Sequence Diagram shows overall flow of
System event/s in a given use case.

Communication diagram shows how objects interacts with each other show intercommunication b/w objects for a
give use case

3:Its difficult to fine the responsibilities of objects in sequence diagram.

Its ease to detect the responsibilities of objects in Communication diagram by juist counting the number of arrows
coming into the object.
4: Sequence Diagrams are less spatial. Communication Diagram are much spatial.

In programming, we have three basic constructs, namely iteration, sequence and decision, to write a
typical program.

We are unable to express iterations in communication diagram precisely. For instance, how do
we model a loop that executes the loop 100 times, and each time, it involves 10 objects in a
communication diagram? Would it make a communication diagram very tedious? In this
connection, communication diagram is unsuitable to express object interactions in details. This
diagram is more suitable to express our high level design (as what you use in the OOD report
template and in our design methodology).

Sequence diagram is for modeling of a more detailed design. It has all the basic programming
control constructs, namely iteration (loop), sequence, and decision (condition, or "alt" combined
fragment).

A state machine diagram focuses on how an object may possibly go through its object states.
Neither communication diagram nor sequence diagram provides any information about object
states, and thus, we are unable to know what the responses of the object under different
situations (i.e., states) when receiving a message. Moreover, if a class has been used
in multiple sequence diagrams, we need to ensure the program logic of the class to support each
involved sequence diagram. In this case, we may model the object life of this class through a
state machine diagram. We never use a sequence diagram for this purpose; otherwise, sooner or
later, we need merge all the sequence diagrams into a huge sequence diagram (which is too
complex to be used).

2-What is an Enumeration Class in UML?

The enum keyword is used to declare an enumeration, a distinct type that consists of a set of named constants called
the enumerator list. Usually it is best to define an enum directly within a namespace so that all classes in the
namespace can access it with equal convenience.
The Enumeration Class defines the methods by which you can enumerate (obtain one at a time) the elements in a
collection of objects. This legacy interface has been superseded by Iterator. Although not deprecated, Enumerations
considered obsolete for new code. However, it is used by several methods defined by the legacy classes (such
as Vector and Properties), and can be used among other Classes.

3-How to Identify Actors Of the system and their Roles?

An actor is behaviored classifier which specifies a role played by an external entity that interacts with
the subject (e.g., by exchanging signals and data), a human user of the designed system, some other system or
hardware using services of the subject.
The term "role" is used informally as some type, group or particular facet of users that require specific services from
the subject modeled with associated use cases. When an external entity interacts with the subject, it plays the role of
a specific actor. That single physical entity may play several different roles, and a specific role may be played by
single or multiple different instances.
 Since an actor is external to the subject, it is typically defined in the same classifier or package that incorporates
the subject.
All actors must have names according to the assumed role. Examples of actor names (user roles):
Customer
Web Client
Student
Passenger
Payment System
Standard UML notation for actor is "stick man" icon with the name of the actor above or below of the icon. Actor
names should follow the capitalization and punctuation guidelines for classes. The names of abstract actors should
be shown in italics.

Student actor
Custom icons that convey the kind of actor may also be used to denote an actor, such as using a separate icon(s) for
non-human actors.

Custom icon for Web Client actor

Custom icon for Bank actor

An actor may also be shown as a class rectangle with the standard keyword actor, having usual notation for class
compartments, if needed.

Customer actor as Class

4-How to show actors in use case diagrams?

Before we can produce a use case diagram we must first identify the groups of related scenarios - the use cases. In
addition we need to identify the initiators of the use cases - the actors. Recall from the previous sections, actors
reside outside of the system and interact with it; use cases describe the functionality that helps actors achieve their
 goals. There are many approaches to identifying actors and use cases. In this section we present a method for doing
this.
To identify use cases we will take the following steps:

Step 1: Identify candidate system actors.

Step 2: Identify the goals of the actors.

Step 3: Identify the candidate use cases.

Step 4: Identify the start point for each use case.

Step 5: Identify the end point for each use case.

Step 6: Refine and scope units of interaction.

Now we discuss each of these steps in more detail.

Step 1: Identify candidate system actors.

Read through the requirements documentation and make a note of all the candidate system actors.
Remember an actor is not just a person but may also be an external system such as a credit card
verification service. Actors interact with the system and reside outside of it. If you find that multiple
terms have been used to describe the same actor, group these terms together and use a generic term. Be
aware, it is crucial that you are certain that these terms are describing the same actor.

Activity: Identify the Actors in the Case Study

Learning Objective: This exercise will give you some insight into the process of identifying the
system actors that are responsible for initiating uses cases.
Read through the UWEFlix case study and identify the actors. Remember from the previous section,
actors are external to the system and not part of it. They are not necessarily human and can be external
systems such as credit card verification services. For example, Manager could be an actor. Any others?

Step 2: Identify the goals of the actors.

Use cases describe the functionality required of the system in order for actors to achieve their goals.
Therefore you need to identify what the goals of your candidate actors are. At this stage you may find that
you have multiple actors requiring the same or similar system functionality, at this stage do not worry
about this. For example, the manager needs to decide what films to shown in which screens.

Step 3: Identify the candidate use cases.

Now that you have identified the candidate actors and the goals of these actors we can identify the
candidate list of use cases. Remember a use case represents a substantial piece of system functionality,
not just a single method in software. Use cases cover a group of related scenarios, for example, a use case
called "purchase ticket" will include the scenario where payment is unsuccessful in addition to the typical
payment success scenario. Using the actors goals try and identify the text in the requirements document
that corresponds to these goals. Choose an initial name to describe the candidate use case and paste the
textual commentary from the requirements document underneath the use case name. At this point do not
worry about common functionality in multiple use cases.

Step 4: Identify the start point for each use case.

You may have already started to do this when producing your list of candidate use cases but you need to
identify the start point for each use case. To do this, look for an actor and an initial event. You will find
this is easier to do with some use cases rather than others. For example, with the "DeleteFilm" use case,
the initial event may be to choose a film.

Step 5: Identify the end point for each use case.

In a manner similar to that of step 2, you need to identify the beneficial result of the use case, the end
point. The purpose of this step is to allow you to refine the size of use cases, ensuring that a candidate use
case is neither too small nor too big.

Step 6: Refine and scope units of interaction.

At this point all of the functionality described in the requirements document needs to be covered by at
least one candidate use case. You now need to work through the list of candidate use cases refining size
and scope. Remember after completing this step you are not after a fixed final list of actors and use cases,
it is still possible to refine this later.

5-What are the Control in UML Class Daigram ?

Control is a stereotyped class or object that is used to model flow of control or some coordination in
behavior. One or several control classes could describe use case realization. System controls represent the
dynamics of the designed system and usually describe some "business logic".
Control is drawn as a circle with embedded arrow on the top. It could be also shown as a class with the
Control stereotype.
Note, that UML has standard Focus stereotype applicable to classes which could be used for specifying
the core business logic or control flow of components during design.
ler Classes in UML Class Diagram?
We have make one Controller Class for Every Entity Class to Show How an Entity Class Can
implement a Function between Data layer and interface layer ^^.
6-what are the relationships Types in package diagram

7-What Do you know About Content coupling in System Design?

Coupling: In software engineering, the coupling can be defined as the measurement to which the
components of the software depend upon each other. Normally, the coupling is contrasted with the
cohesion. If the system has a low coupling, it is a sign of a well-structured computer system and a great
design. A low coupling combined with the high cohesion, it supports the mission of high readability and
maintainability. The coupling term generally occurs together with the cohesion very frequently.

The coupling is an indication of the strength of the interconnection between all the components in a
system. The highly coupled systems have interconnections, in which the program units depend upon each
other, whereas in the loosely coupled systems made up of components, that are independent of each other
and have no dependence on each other.
Types of Coupling: The coupling has many types and can be high or low:
Types of Coupling
1. Content Coupling: Content Coupling is the highest type of coupling which occurs when one of
the module relies on the other modules internal working. It means a change in the second module
will lead to the changes in the dependent module.
2. Common Coupling: It is the second highest type of coupling also known as Global Coupling. It
occurs when the same global data are shared by the two modules. In this, the modules will
undergo changes if there are changes in the shared resource.

3. External Coupling: This type of coupling occurs when an external imposed data format and
communication protocol are shared by two modules. External Coupling is generally related to the
communication to external devices.

4. Control Coupling: In this type of coupling, one module controls the flow of another and passes
information from one to another.
5. Message Coupling: This type of coupling can be achieved by the state decentralization. It is the
loosest type of coupling, in which the component communication is performed through message
passing.
6. Data Coupling: The modules are connected by the data coupling, if only data can be passed
between them.
7. Stamp Coupling: In this type of coupling, the data structure is used to transfer information from
on component to another.
8-Compare Between RDBMS ,ORDBMS AND OODBMS?
S.No RDBMS ORDBMS
1 Relational Database Management Systems Object Relational Database Systems
2 Based on Relational Data Model Based on Object Data Model (ODM)
3 Dominant model Gaining popularity
4 ORDBMS is an attempt to extend
relational database systems to provide a
bridge between the relational and object-
oriented paradigms.
5 RDBMS support a small, fixed collection of data ORDBMS is based on Object-Oriented
types ( eg. Integers, dates, strings ) which has Database systems and Relational Database
proven adequate for traditional application domains systems and are aimed at application
such as administrative data processing domains where complex objects play a
central role.
6 Supports Structured Query Language Supports Object Query Language ( OQL )
 ( SQL ) SQL : 1999 standard extends SQL to
incorporate support for the object-
relational model of data
7 RDBMS products : Object-oriented model products:
IBMs DB2 Object store
Informix Versant
Oracle Object-relational model products: Used in
Sybase DBMS products from
IBM
Microsofts Access
Informix
Fox Base
Object store
Paradox
Oracle
Tandem
Versant
Teradata
Others
8 Supports Standard data types and additional data Supports standard data types and new
types richer data types.
The new richer data types supported are
User-defined data types that
supports image, voice and video footage
and these must be stored in the database
Inheritance data types to inherit
the commonality between different types
(eg. To inherit some features of image
objects while defining compressed image
objects and low-resolution image objects
Object Identity data types like
references or pointers to objects (eg video)
for giving objects a unique object identity,
which can be used to refer or point to them
from elsewhere in the data.
9 Case Scenario : Case Scenario :

OODBMS : Object-Oriented Database Management Systems

ORDBMS : Object-Relational Database Management Systems
Similarities
Both supports user-defined ADTs, structured types, object identity and reference types and inheritance.
Both supports an extended form of SQL. OODBMS support ODL/OQL. ORDBMS support an extended form of SQL.
ORDBMS consciously try to add OODBMS features to an RDBMS and OODBMS in turn have developed query
language based on relational query languages.
Both provide DBMS functionality such as concurrency control and recovery.
Differences
S.No OODBMS ORDBMS
1 OODBMSs aim to achieve seamless integration Such integration is not an important goal for
with a programming language such as C++, Java. an ORDBMS.

2 An OODBMS is aimed at applications where an An ORDBMS is optimized for applications

object-centric viewpoint is appropriate. in which large data collections are the focus,
even though objects may have a rich
structure and be fairly large,