1-What Is The Difference Between Sequence Diagram and Communication Diagram in UML?
1-What Is The Difference Between Sequence Diagram and Communication Diagram in UML?
1-What Is The Difference Between Sequence Diagram and Communication Diagram in UML?
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.
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
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).
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.
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:
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.
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?
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.
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.
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.
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.
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
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 :