How to draw UML Activity Diagrams?

UML Activity Diagrams is a special case of a statechart diagram in which all of the states are action states and the transitions are triggered by the completion of actions in the source state. Use an activity diagram to describe the internal behavior of a method and represent a flow driven by internally generated actions. 

UML Activity Diagram Symbols

How to draw UML activity diagrams

1. Identify the scope of the activity diagram

Begin by identifying what it is you are modeling. Is it a single use case? A portion of a use case? A business process that includes several use cases? A single method of a class? Once you identify the scope of your diagram, you should add a label at the top, using a note, indicating an appropriate title for the diagram and a unique identifier for it. You may also want to include the date and even the names of the authors of the diagram.

2. Add start and end points

Every activity diagram has a starting point and an ending point, so you might as well add them right away. In UML Distilled (see Resources), Fowler and Scott make ending points optional. Sometimes an activity is simply a dead end but, if this is the case, then there is no harm in indicating the only transition is to an ending point. This way, when someone else reads your diagram, he or she knows you have considered how to exit these activities.

3. Add activities

If you are modeling a use case, introduce an activity for each major step initiated by an actor (this activity would include the initial step, plus any steps describing the response of the system to the initial step). If you are modeling a high-level business process, introduce an activity for each major process, often a use case or a package of use cases. Finally, if you are modeling a method, then it is common to have an activity for this step in the code.

4. Add transitions from the activities

My style is always to exit an activity, even if it is simply to an ending point. Whenever there is more than one transition out of an activity, you must label each transition appropriately.

5. Add decision points

Sometimes the logic of what you are modeling calls for a decision to be made. Perhaps something needs to be inspected or compared to something else. Important to note is that the use of decision points is optional. For example, in Figure 1 I could just as easily have modeled the accepted and rejected transitions straight out of the "Enroll in University" activity.

6. Identify opportunities for parallel activities

Two activities can occur in parallel when no direct relationship exists between them and they must both finish before a third activity can. In Figure 1 you see it is possible to attend the overview or enroll in seminars in either order, but both activities must occur before you can end the overall process.

Entity relationship diagram and Normalization of Airline Reservation System - a good example

E-R DIAGRAM : E-R Diagram constitute a technique for representing the logical structure of a database in a pictorial manner. This analysis is then used to organize data as a relation, normalising relation and finally obtaining a relation database. Entities : Which specify distinct real-world items in an application. Properties (or): Which specify properties of an entity and relationships. Relationships : Which connect entities and represent meaningful dependencies between them. NORMALIZATION : The basic objective of normalization is to be reduce redundancy which means that information is to be stored only once. Storing information several times leads to wastage of storage space and increase in the total size of the data stored. If a Database is not properly designed it can gives rise to modification anomalies. Modification anomalies arise when data is added to, changed or deleted from a database table. Similarly, in traditional databases as well as improperly designed relational databases, data redundancy can be a problem. These can be eliminated by normalizing a database. Normalization is the process of breaking down a table into smaller tables. So that each table deals with a single theme. There are three different kinds of modifications of anomalies and formulated the first, second and third normal forms (3NF) is considered sufficient for most practical purposes. It should be considered only after a through analysis and complete understanding of its implications. FIRST NORMAL FORM (1NF) : This form also called as a “flat file”. Each column should contain data in respect of a single attributes and no two rows may be identical. To bring a table to First Normal Form, repeating groups of fields should be identified and moved to another table. SECOND NORMAL FORM (2NF) : A relation is said to be in 2NF if it is 1NF and non-key attributes are functionality dependent on the key attributes. A ‘Functional Dependency’ is a relationship among attributes. One attribute is said to be functionally dependent on another if the value of the first attribute depends on the value of the second attribute. In the given description flight number and halt code is the composite key. Splitting of relation given in table 1 into 2NF relations

FLIGHT DETAILS :

AR_FLIGHT_MST

FL_NO VARCHAR2(7) PRIMARY KEY FL_NAME VARCHAR2(25) NOT NULL ORG_CD NUMBER(3) NOT NULL DES_CD NUMBER(3) NOT NULL CAPACITY NUMBER(3) NOT NULL

AR_FLIGHT_DET

FL_NO VARCHAR2(7) PRIMARY KEY (REFERENCE AR_FLIGHT_MST.FL_NO) HALT_CD NUMBER(3) PRIMARY KEY DIST_FRM_ORG NUMBER(3) - NO_QUOTA NUMBER(3) - NO_BOOKED NUMBER(3)  - JOUR_DATE - NOT NULL

THIRD NORMAL FORM (3NF) :

A Third Normal Form normalization will be needed where all attributes in a relation tuple are not functionally dependent only on the key attribute. A transitive dependency is one in which one in which one attribute depends on second which is turned depends on a third and so on.

FLIGHT DETAILS :

AR_FLIGHT_MST

FL_NO VARCHAR2(7) PRIMARY KEY FL_NAME VARCHAR2(25) NOT NULL ORG_CD NUMBER(3) NOT NULL DES_CD NUMBER(3) NOT NULL CAPACITY NUMBER(3) NOT NULL

AR_FLIGHT_DET

FL_NO VARCHAR2(7) PRIMARY KEY (REFERENCE AR_FLIGHT_MST.FL_NO) HALT_CD NUMBER(3) PRIMARY KEY DIST_FRM_ORG NUMBER(3) - NO_QUOTA NUMBER(3) - NO_BOOKED NUMBER(3 - JOUR_DATE - NOT NULL

AR_HALT_MST

HALT_CD NUMBER(3) PRIMARY KEY DESCRIPTION VARCHAR2(30) NOT NULL

Relational model for Airline Reservation System

A distribution Airline Reservation System stores the following information 

(The following description may lead to un-normalized relations normalize them whenever required).

The flight details 

It includes the originating flight terminal and destination terminal, along with stops in between, number of seats booked/available seats between two destination etc.

Customer Description 

It includes customer code, name, address and phone number. This information may be used for keeping the records of customer for any emergency or for any other kind of information

Reservation Description 

It includes customer code number, flight number, date of booking, date of traveling, (You may assume any other fild/relation, if needed). 

Let us assume that this distributed system is to be used following application:

a. A request for booking/cancellation of flight from any source to any destination

, giving connected flights in case no direct flight between the specified Source-Destination pair exist.

b. Calculation of high fliers (most frequent fliers) and calculating appropriate 

reward points for these fliers.

Assuming both the transactions are single transactions. Design a distributed database that is geographically dispersed at four cites Delhi, Mumbai, Chennai, Kolkatta) Make suitable assumptions. Give justifications to your design.

Your design include:

i) The global schema, fragmentation schema, allocation schema.

ii) SQL commands for above queries/applications

iii) How the response for application 1 and 2 will be generated. Assuming these 

are global queries. Explain how various fragments will be combined to do so.

iv) Implement the database at least using a centralized database management 

system (make suitable adjustment in your design)

Answer:

DISTRIBUTED DATABASE :

Distributed database implies that a single application should be able to operate transparently on data that is spread across a variety of different databases and connected by a communication network.

“A distributed database system consists of a collection of ‘sites’, connected together

via some kind of communications network, in which

1. Each site is a database system site in its own right, but

2. The sites have agreed to work together so that a user at any site can access data anywhere in the network exactly as if the data were all stored at the user’s own site.

It follows that the so-called “distributed database” is really a kind of virtual objects, whose component parts are physically stored in a number of distinct “real” database at a number distinct sites.

A distributed database system consists of a collection of sites, each of which may participate in the execution of transactions which access data at one site, or several sites. The main difference between centralized and distributed database systems is that, in the former, the data resided in one single location, while in the latter, the data resided in several locations.

Each site is able to process local transactions, those transactions that access data only that single site. A site may participate in the executions of global transactions, those transactions that access data in several sites. The execution of global transactions require communication among the sites.

Each site is a database system site in its own right. In other words, each site has its own local “real” databases, its own local users, its own local DBMS and transaction management software and its own local data communications manager. The distributed database system can thus be regarded as a kind of partnership among individual local DBMS at the individual sites.

In the given context there are four sites,i.e., Delhi, Mumbai, Chennai and Kolkata and these sites are geographically dispersed. Each site has its own computer with a database consisting of all the customers and flight details maintained at that site. The database system at the various sites are based on the relational model. Each branch maintains the relation reservation where

Reservation_scheme=(site_code,fl_no,cust_code,travel_date)

Site containing information about the four sites maintains the relation (Cite_scheme), where

Cite_scheme=(Cite_code,Cite_name)

A local transaction is a transaction that accesses information in the one single site, at which the transaction was initiated. A global transaction, on the other hand is one which either access accounts in a site different from the one at which the transaction was initiated, or access several different sites.

Then the advantages are surely obvious: The distributed arrangement combines efficiency of processing (the data is stored close to the point where it is most frequently used) with increased accessibility (it is possible to access a Delhi information from Kolkata and vice versa, via the communication network), reliability and availability and speedup of query processing.

Allowing the structure of the database to mirror the structure of the enterprise is probably the number one advantage of distributed systems. There are some disadvantages too, of which the biggest is the fact that distributed systems are complex, software development cost, greater potential for bugs and increase processing overhead.

As per commercial implementations, most of today’s relational products offer some kind of distributed database support. Some of the best known include,

(a) INRESS/STAR , from The ASK Group Inc.’s Ingress Division;

(b) the distributed database option of ORCALE8 or later from Oracle Corporation and

(c) the distributed data facility of DB2 from IBM.

It is worth pointing out that all of the systems listed above, both prototypes and products, are relational.

OBJECTIVES :

1. Local autonomy

2. No reliance on a central site

3. Continuous operation

4. Location independence

5. Fragmentation independence

6. Replication independence

7. Distributed query processing

8. Distributed transactions management

9. Hardware independence

10. Operating system independence

11. Network independence

12. DBMS independence

These above twelve objectives are not all independent of one another, nor are they necessarily exhaustive, nor are they all equally significant. However, they are useful as a basis for understanding distributed technology and as a framework for characterizing the functionality of specific distributed systems.

Entity Relational Modeling vs. Dimensional Modeling

Surrogate Keys

• A substitution for the natural primary key.
• It is just a unique identifier or number for each row that can be used for the primary key to the table. The only requirement for a surrogate primary key is that it is unique for each row in the table.
• Data warehouses typically use a surrogate, (also known as artificial or identity key), key for the dimension tables primary keys. They can use Oracle sequence, or SQL Server Identity values for the surrogate key.
• It is useful because the natural primary key (i.e. Customer Number in Customer table) can change and this makes updates more difficult.
• In a data warehouse, a surrogate key is a necessary generalization of the natural production key and is one of the basic elements of data warehouse design.
• Every join between dimension tables and fact tables in a data warehouse environment should be based on surrogate keys, not natural keys.
• It is up to the data extract logic to systematically look up and replace every incoming natural key with a data warehouse surrogate key each time either a dimension record or a fact record is brought into the data warehouse environment.
• One of the most important use of surrogate Key the need to encode uncertain knowledge (When you have a I don't know" situation, you may want more than just this one special key for the anonymous customer )

ER to Dimensional modeling

Single Entity Relationship – breaks down into multiple Facts

1. Convert ER to set of dimensional modeling
2. Select many-to-many facts
3. De-normalize remaining tables

Easy and clear description of Object Oriented Design and Analysis of Students Registration System.

a) Defenition of Hierarchy Diagram:

The Hierarchy Diagram begins at the Top Level with the Main Module. The Main Module represents a program's main routine and is the highest module that controls the overall logic of the program. The other modules in the Hierarchy Diagram may be considered as SubModules of the controlling or Main Module and they are performed when the Main Module "CALLs or PERFORMs" them and they then return control to the Main Module when their logic is complete.

That is, the Main Module is the starting point of the logic and it CALLs Sub Module 1 for logical service (The Main Module notes the Return Point in its own logic and goes to a Wait State until Sub Module 1 has completed it's function).

When Sub Module 1 has completed its task, it issues a RETURN and the logic returns to the Return Point maintained by the Main Module's logic. The Main Module then continues by CALLing Sub Module 2 in the same manner. Note that Sub Module 2 RETURNS control to the Main Module and that the logic terminates in the Main Module (NOT Sub Module 2). Each of the SubModules may in turn be composed of lower level SubModules and they in turn CALL or PERFORM SubModules in the same controlling manner as the Main Module CALLed them. This then can go on recursively until the required logic is implemented and each major processing function is reduced to a series of logically (functionally) independent subfunctions.

Consequently each Module accomplishes a specific logical task, and together, the Modules solve the logical need of the Main Module (or program). A Hierarchy Diagram is developed in a manner similar to the procedures used to develop an outline of a report or paper. Note: The outline should be developed before detailing the report and so a Hierarchy Diagram should come before the program code. The Hierarchy Diagram is not a complete description of the logic of a program since it only shows "What?" are the tasks and NOT "How?" the tasks do their job. Hierarchy Diagram for Students Registration System.

b) Defenition of a class: In Object oriented programming,a category of objects is called a class. The class defines all the common properties of the different objects that belong to it. Complete details of classes:

The system class : Main class.

The course class : Sub class 1

The Student class: Sub class 2

Description of the classes: Here , this system attempts to furnish details to the students about the courses available in the institution in order to aid the students to choose their option.However the students details are collected,before a student is admitted. There is a process called “Admission”,which takes care of the checks to be made on validity of the information provided by the students and then to see if they qualify to enter into the course they have opted for.If the conditions are satisfied, the student is taken into the institution and the batch convenient or priorly fixed is conveyed to them. The Hierarchy diagram ,attempts to give a clear idea of WHAT is happening in the Student registration process. And the classes are explained to the last detail.