INDEX

S.N List of the Practical

0
Prepare an SRS document in line with the
IEEErecommended standards.
Draw the Use Case Diagram of a project.
Draw the Activity Diagram.

4 Draw the Class Diagram & identify weak and strong

classes
Draw the Component Diagram.
Draw the Sequence Diagram.
Draw the Collaboration Diagram.
Draw the Entity Relationship Diagram of a project.

Draw the data flow diagrams at level 0 and level 1.

raw the data flow diagrams of your mini project To-Do
List.
 EXPERIMENT NO:I

Experiment Name: Software Requirement Specification.

Outcome: Can produce the requirements in an SRS document.

Objective: Prepare an SRS document in line with the IEEE Recommended Standard.

Description:
A Software Requirements Specification (SRS) is a document that describes the nature of a project,
software, or application. In simple words, an SRS document is a manual of a project provided it is
prepared before you kick-start a project/application. This documentis also known by the names SRS
report, and software document. A software document is primarily prepared for a project, software, or any
kind of application.

There is a set of guidelines to be followed while preparing the software requirement specification
document. This includes the purpose, scope, functional and non-functionalrequirements, and software
and hardware requirements of the project. In addition to this, it also contains information about
environmental conditions required, safety and security requirements, software quality attributes of the
project, etc.

A well-designed, well-written SRS accomplishes major goals:

1 . It provides feedback to the cu omer. An SRS is the customer's assurance that the
development or anizationun rstands the issues or problems to be solved and the software
behavior nece ary to ess those problems. Therefore, the SRS should be written in natural
langua ersus a formal language, explained later in this article), in an unambiguous
manner that may also include charts, tables, data flow diagrams, decision tables, and so
on.

2 It decomposes the problem into parts. The simple act of writing down requirements in a
well-designed format organizes information, places borders around the problem,
solidifies ideas, and helps break down the probleminto its parts in an orderly fashion.

3 It serves as an input to the design specification. As mentioned previously, the SRS serves
as the parent document to subseqUent documents, such as the software design
specification and statement of work. Therefore, the SRS must contain sufficient detail in
the functional system requirements so that a design solution can be devised.

4 It serves as a product validation check. The SRS also serves as the parent document for
testing and validation strategies that will be applied to the requirements for verification.
SRSs are typically developed during the first stages of "Requirements Development," which is the
initial product development phase in which information is gathered about what requirements are
needed—and not. This information-gathering stage can include onsite visits, questionnaires,
surveys, interviews, and perhaps are turn-on-investment (ROD analysis or needs analysis of the
customer or client's current business environment. The actual specification, then is written after the
requirements have been gathered and analyzed.

SRS should address the following:

The basic issues that the SRS shall address are the following:

Functionality. What is the software supposed to do?

External interfaces. How does the software interact with people, the system's hardware, other hardware, and
other software?

Performance. What is the speed, availability, response time, recovery time ofvarious software functions, etc?

Attributes. What are the portability, correctness, maintainability, security, [Link]?

Design constraints imposed on an implementation. Are there any required standards in effect,
implementation language, policies for database integrity, resource limits, and operating environment(s)?

Characteristics of good SRS

An SRS should be

a) Correct
b) Un biguous
c) Co plete
d) Con
e)Ranked for importance and/or stability
f) Verifiable
g) Modifiable
h) Traceable

Correct - This is like motherhood and apple pie. Of course, you want the specification to be
correct. No one writes a specification that they know is incorrect. We like to say "Correct and
Ever Correcting." The discipline is keeping the specification up to date when you find things
that are not correct.

Unambiguous - An SRS is unambiguous if, and only if, every requirement stated therein has only one
interpretation. Again, easier said than done. Spending time in thisarea before releasing the SRS can be a
waste of time. But as you find ambiguities them.
Complete - A simple judgment of this is that it should be all that is needed by the software designers to create the
software.
Consistent - The SRS should be consistent within itself and consistent with its reference
documents. If you call an input "Start and Stop" in one place, don't call it "Start/Stop" in
another.

Ranked for Importance - Very often a new system has requirements that are marketing wish
lists. Some may not be achievable. It is useful to providethis information in the SRS.

Verifiable - Don't put in requirements like - "It should provide the user a fast response."
Another of my favorites is - "The system should never crash." Instead, provide a quantitative
requirement like: "Every keystroke should provide a user response within 100 milliseconds."

Modifiable - Having the same requirement in more than one place may not bewrong - but tends to
make the document not maintainable.

Traceable-Often, this is not important in a non-politicized environment. However, in most

organizations, it is sometimes useful to connect the requirements in the SRS to a higherlevel
document. Why do we need this requirement?

A Software requirements specification docu t describes the intended purpose, requirements, and nature of the
software to be developed. It o includes the yield and costofthe software.
In this document, a flight managem project is used as an example to explain a fewpoints.

[Link]
Purpose
Document conventions Intended audience Additional information
Contact information / SRS team members References

[Link] Description
Product perspective
Product functions
Operating environment
User environment
Design/implementation
Constraints Assumptions and dependencies
3. External Interface Requirements
User interface Hardware
interface
Software interface
Communication Interface

4. Non- functional Requirements

 Performance Requirements
Safety Requirements
Security Requirements . Software Quality Attributes

INTRODUCTION

1.1 PURPOSE
The purpose of this document is to build an online system to manage flights andpassengers to ease
flight management.

1.2 INTENDED AUDIENCE AND RE G SUGGESTIONS

This project is a prototype for flight management system and it is restricted within the college
premises. This has en implemented under the guidance of college professors. This project is useful
fo ight management team as wellas for the passengers.

1.3 PROJECT SCOPE

The purpose of the online flight management system is to ease flight management and to create a convenient
and easy-to-use application for passengers, trying to buy airline tickets.

The system is based on a relational database with its flight management and reservation functions. We
will have a database server supporting hundreds of major cities around the world as well as thousands of
flights by various airline companies. Above all, we hope to provide a comfortable user experience along
with the best pricingavailable.

1.5 REFERENCES

[Link] [Link]
Fundamentals of Database by Ramez Elmarsi & Shamkant [Link]
2. OVERALL DESCRIPTION

2.1 PRODUCT PERSPECTIVE

A distributed airline database system stores the following information.

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

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

Reservation description:
It includes customer details, code number, flight number, date of booking, and date of travel.
 2.2 PRODUCT FEATURES

The major features of the airline database system as shown on the next page entity-

RELATIONAL MODEL ER DIAGRAM

2.3 USER CLASS and CHARACTERISTICS

Users of the system should be able to retrieve flight information between two given cities with
the given date/time of travel from the database. A route from city A to city B is a sequence of
connecting flights from A to B such that:

a) There are at most two connecting stops, excluding the starting city and destinationcity of the trip.

b) The connecting time is between one to two hours. The system will support two types of user
privileges, Customer, and Employee. Customers will have access to customer functions, and the
employees will have access to both customer and flightmanagement functions. The customer should
be able to do the following functions:

Make a new reservation

One-way
Round-Trip
 Multi-city
Flexible Date/time
Confirmation
Cancel an existing reservation
View his itinerary

The Employee should have the following management functionalities:

Get all customers who have seats reserved on a given flight.

Get all flights for a given airport.
View flight schedule.
Get all flights whose arrival and departure times are on time/delayed.
Calculate total sales for a given flight.
Add/Delete a flight
Add a new airport
Update fare for flights.
Add a new flight leg instance.
Update departure/arrival times for flight leg instances.
Each flight has a limited number of available seats. There are a number of flights whichdepart from or arrive
at different cities on different dates and time.
2.4 OPERATING ENVIRONMENT

Operating environment for the airline management system is as listed below.

• Distributed Database
Client/Server System
Operating system: Windows or Linux.
• Database: SQL + Database
• Platform: [Link]/Java/PHP
2.4 DESIGN and IMPLEMENTATION CONSTRAINTS

I. The global schema, fragmentation schema, and allocation schema.

2. SQL commands for above queries/applications
3. How the response for application 1 and 2 will be generated. Assuming these areglobal queries. Explain
how various fragments will be combined to do so.
4. Implement the database at least using a centralized database managementsystem.
3. CLIENT/SERVER SYSTE

The term cli t/s refers primarily to an architecture or logical division of responsibilities, the client is
the application (also known as the front-end), and the server is the DBMS (also known as the back-
end).

A client/server system is a distributed system in which:

Some sites are client sites and others are server sites.
 All the data resides at the sewer sites.
All applications execute at the client sites.
4. EXTERNAL INTERFACE REOUIREMENTS

4.1 USER INTERFACES

Front-end software: [Link] version
• Back-end software: SQL+

4.2 HARDWARE INTERFACES

Windows.
A browser that supports CGI, HTML & JavaScript.
4.3 SOFTWARE INTERFACES

Following are the software used for the flight management online application.
<<lnclude the software details as per your project >>

Software used Description

We have chosen Windows operating systemfor its

Operating system
best support and user-friendliness.

Database
To save the flight records, passenger recordswe have
chosen SQL+ database.

To implement the project we have [Link]

[Link] language for its more interactive support.
4.4 COMMUNICATION RNTERFACES

This project supports all types of web bro rs. We are using simple electronic formsfor reservation
forms, ticket boo • g, etc.

5. NONFUNCTIONAL REOIJIREMENTS

5.1 PERFORMANCE REQUIREMENTS

The steps involved to perform the implementation of the airline database are listedbelow.

A) E-R DIAGRAM
The E-R Diagram constitutes a technique for representing the logical structure of adatabase pictorially. This
analysis is then used to organize data as a relation, normalizing relation, and finally obtaining a relation
database.
ENTITIES: These specify distinct real-world items in an application.
PROPERTIES/ATTRIBUTES: These specify properties of an entity and
relationships.
 RELATIONSHIPS: These connect entities and represent meaningful dependencies between
them.
The diagram shows the ER diagram of airline database.

B) NORMALIZATION:
The basic objective of normalization is to reduce redundancy which means thatinformation is to
be stored only once. Storing information several times leads to wastage of storage space and an
increase in the total size of the data stored.
If
a database is not properly desi81ed it can give 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
bynormalizing 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 the first, second, and third
normal forms (3NF) are considered sufficient for most practical purposes. It should be considered only after
a thoroughanalysis and complete understanding of its implications.

5.2 SAFETY REQUIREMENTS If there is extensive damage to a wide portion of the database due to
catastrophic failure, such as a disk crash, the recovery method restores a past copy of the databasethat was
backed up to archival storage (typically tape) and reconstructs a more currentstate by reapplying or redoing
the operations of committed transactions from the backed up log, up to the time of failure.

5.3 SECURITY REQUIREMENTS

Security systems need database storage jus e many other applications. However, the special requirements
of the security market an that vendors must choose their database partner carefully.

5.4 SOFTWARE QUALITY ATTRIBUTES • AVAILABILITY: The flight should be available on

the specified date and specifiedtime as many customers are making reservations

CORRECTNESS: The flight should start from the correct start terminal and should reach the correct
destination. MAINTAINABILITY: The administrators and flight chargers should schedules of
flights. USABILITY: The flight schedules should satisfy a maximum number of customemeeds.

EXPERIMENT NO:2
Experiment Name: Use Case Diagram.
Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse,
colored monitor.
Software Requirements: Argo UML, Windows XP.
Outcome: Can produce the requirements in Use Case diagram.
Objective: Prepare a Requirement document in by using Use Case Diagram.
Description: According to the UML specification a use case diagram is "a diagram thatshows the
relationships among actors and use cases within a system." Use case diagrams are often used to:
Provide an overview of all or part of the usage requirements for a system ororganization in the form of
an essential model or a business model.
 Communicate the scope of a development project.
Model your analysis of your usage require in the form of a system use casemodel.
Use case models s uld be e oped from the point of view of your project stakeholders and not from the
(often technical) point ofview of developers. There areguidelines for:
Use Cases
Actors
Relationships
System Boundary Boxes
Use Cases:
A use case describes a sequence of actions that provide a measurablevalue to an
actor.
A use case is drawn as a horizontal ellipse on a UMLuse case diagram:
Use Case Names Begin With a Strong Verb Name Use Cases
Using Domain Terminology
Place Your Primary Use Cases In The Top-Left Corner OfTheDiagram
Imply Timing Considerations By Stacking Use Cases.

Actors
An actor is a person, organization, or external system that plays a role in one or more interactions with
your system (actors are typically drawn as stick figures On UML (Use Case diagrams).

1. Place Your Primary Actor(S) In The Top-Left Corner Of The Diagram

2. Draw Actors To The Outside Of A Use Case Diagram
3. Name Actors With Singular, Business-Relevant Nouns
4. Associate Each Actor With One Or More Use Cases
5. Actors Model Roles, Not Positions
6. Use <<system>> to Indicate System Actors
7. Actors Don't Interact With One Another
8. Introduce an Actor Called "Time" to Initiate Scheduled Events
Relationships
Several types of relationships may appear on a use case diagram:
An association between an actor and ause
case

An association between two use cases

A generalization between two actors

A generalization between two use cases.
Associations are depicted as lines connecting two modeling elements with an optionalopen-headed
arrowhead on one end of the line indicating the direction of the initial invocation of the relationship.
Generalizations are depicted as a close- ed arrow with the arrow pointing towards the more general
modelin element.
 1. Indica Association BetWeen An Actor And A UseCase
If The Actor Appears Within The Use Case Logic

2. Avoid Arrowheads On Actor-USQ Case Relationships

3. Apply <<include>> When You Know Exactly When To Invoke The Use Case
4. Apply <<extend>> When A Use Case May Be Invoked Across Several UseCase Step
5. Introduce <<extend>> associati0hs sparingly
6. Generalize Use Cases When a Single Condition Results In Significantly New
Business Logic
7. Do Not Apply <<uses>>, or <<extends>>
8. Avoid More Than Two Levels Of Use Case Associations
9. Place An Included Use Case TO The Right Of The Invoking Use Case
10. Place An Extending Use Case Below The Parent Use Case
11. .Apply the "Is Like" Rule to Use Case Generalization
12. Place an Inheriting Use Qse Below The Base Use Case
13. Apply the "Is Like" Rule to Actor Inheritance
14. Place an Inheriting Actor below the Parent Actor
4. System Boundary Boxes

The rectangle around the use cases is called the system boundary box and as thename suggests it
indicates the scope of your system — the use cases inside the rectangle represent the functionality that
you intend to implement.

1. Indicate Release Scope with a System Boundary Box.

2. Avoid Meaningless System Boundary Boxes.

Creating Use Case Diagrams

We start by identiffing as many actors as possible. You should ask how the actors interact with the system
to identify an initial set ofuse cases. Then, on the diagram, youconnect the actors with the use cases with
which they are involved. If the actor supplies infomation, initiates the use case, or receives any
information as a result of the use case, then there should be an association between them. Conclusion: The
Use case diagram was made successfully by following the stepsdescribed above.

Output:
 EXPERIMENT NO : 3
Experiment Name: Use Activity Diagram.

Outcome: Can produce the activity diagram for requirements modeling.

Objective: To Draw a sample activity diagram for real project or system.

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard keyboard n mouse,
colored monitor.

Software Requirements: Argo UML, Windows XP

Theory:

Activity diagrams are typically used for business process modeling, for modeling the logic captured by a
single usecase or usage scenario, or for modeling the detailed logicof a business rule. Although UML
activity diagrams could potentially model the internal logic of a complex operation it would be far better
to simply rewrite the operation so thatit is simple enough that you don't require an activity diagram. In
many ways, UML activity diagrams are the object-oriented equivalent of flow charts and data flow
diagrams (DFDs) from structured development.

Let's start by describing the basic notation :

Initial node. The filled-in circle is the starting point of the diagram. An initial node isn't required
although it does make it significantly easier to read the diagram.

Activity final node. The filled circle with a border is the ending point. An activitydiagram can have zero
or more activity final S.

Activity. he rounde ctangles represent activities that occur. An activity may be physical, such as Inspect
For electronic, such as Display Create Student Screen.

Flow/edge. The arrows on the diagram. Although there is a subtle difference betweenflows and edges,
never a practical purpose for the difference.

Fork. A black bar with one flow going into it and several leaving it. This denotes the beginning of
parallel activity.

Join. A black bar with several flows entering it and one leaving it. All flows going into the join must
reach it before processing may continue. This denotes the end of parallelprocessing.

Condition. Text such as [Incorrect Form] on a flow, defining a guard which mustevaluate to true in order
to traverse the node.

Decision. A diamond with one flow entering and several leaving. The flows leavinginclude conditions
although some modelers will not indicate the conditions if it is obvious.

Merge. A diamond with several flows entering and one leaving. The implication is that one or more
incoming flows must reach this point until processing continues, based onany guards on the outgoing

Iffigure is organized into three partitions, it is also called swimlanes, indicating

who/what is performing the activities (either the Applicant, Registrar, orSystem).

Sub-activity indicator. The rake in the bottom comer of an activity, such as in theÁpply to
University activity, indicates that the activity is described by a more finely detailed activity
diagram.

Flow final. The circle with the X through it. This indicates that the process stops at thispoint.

figurel. Modeling a business process with a UML Activity Diagram.

Activities
An activity, also known as an activity state, on a UML Activity diagram typically represents the
invocation of an operation, a step in a business process, or an entirebusiness process.

Decision Points

A decision point is modeled as a diamond on a UML Activity diagram. Decision Points Should Reflect
the Previous Activity. In Figure we see that there is no label on the decision point, unlike traditional
flowcharts which would include text describing the actual decision being made, we need to imply that
the decision concerns whether theperson was enrolled in the university based on the activity that the
decision point follows. The guards, depicted using the format [description], on the transitions
leavingthe decision point also help to describe the decision point.

Guards
A guard is a condition that must be true in order to traverse a transition.

1 . Each Transition Leaving a Decision Point Must Have a Guard

 2. Guards Should Not Overlap. For example guards such as x <O, x = 0, and x are consistent
whereas guard such as x <= 0 and x >= 0 are not consistent because they overlap — it isn't
clear what should happen when x is O.

3. Guards on Decision Points Must Form a Complete Set. For example, guardssuch as x < O
and x are not complete because it isn't clear what happenswhen x is

4. Exit Transition Guards and Activity Invariants Must Form a Complete Set. Anactivity
invariant is a condition that is always true when your system is processing an activity.

Parallel Activities

It is possible to show that activities can occur in allel, as you see inFIGURE 1 depicted using two
parallel bars.
The first bar is called a fork, it ha ne transitio entering it and two or more transitions
leaving it. The second b IS a join, with o or more transitions entering it and only one
leaving it.

1. A Fork Should Have a Corresponding Join. In general, for every start (fork) thereis an end Coin). In
UML 2 it is not required to have a join, but it usually makes sense.

2. Forks Have One Entry Transition.

3. Joins Have One Exit Transition.

4. Avoid Superfluous Forks. FIGURE 2 depicts a simplified description of the software process of
enterprise architectural modeling, a part of the Enterprise Unified Process There is
opportunity for parallelism in this process, in fact all of these activities could happen in parallel, but
forks were notintroduced because they would only have cluttered the diagram.

Avoid Superfluous Decision Points. The Fill Out Enrollment Forms activity in FIGUREI includes an
implied decision point, a check to see that the forms are filled out properly,which simplified the
diagram by avoiding an additional diamond.

Swimlane Guidelines

A swimlane is a way to group activities performed by the same actor on an activity diagram or to group
activities in a single thread. FIGURE 2 includes three swimlanes,one for each actor.
Apply Swim Lanes To Linear Processes. A good rule of thumb is that swimlanes arebest app linear proeesses,
unlike the one depicted in FIGURE 3.

Consider Swimareas For Complex Diagrams.

Swimareas Suggest The Need to Reorganize Into Smaller Activity Diagrams.

Consider Horizontal Swimlanes for Business Processes. In FIGURE 3 you see that the swimlanes are drawn
horizontally, going against common convention of drawing them vertically.

Action-Object Guidelines
Activities act on objects, In the strict object-oriented sense of the term an action objectis a system
object, a software construct. In the looser, and much more useful for business application modeling,
sense of the term an action object is any sort of item. For example in FIGURE 3 the Expense Form is
likely a paper form.

Place Shared Action Objects on Swimlane Separators

When An Object Appears Several Time Apply State Names
State Names Should Reflect the Lifecycle Stage of an ActionObject
Show Only Critical Inputs and Outputs
Depict Action Objects As Smaller Than Activities

Practical Number: 4
Ex eriment Name: Class Dia ram
Outcome:
Class diagram helps to understand the static structure of a system. It showsrelationships between classes,
objects, attributes, and operations.
Objective:
the classes. Classify them as weak and strong classes and draw the classdiagram.

Description:
 A class diagram models the static structure of a system. It shows relationships between classes, objects,
attributes, and operations.

Basic Class Diagram Symbols and Notations.

Classes

Classes represent an abstraction of Ities with common characteristics. Associationsrepresent the relationships
between classes.

Illustrate clas es wi ctangles divided into compartments. Place the name of the class in the first
partition (centered, bolded, and capitalized), list the attributes in the second partition (left-aligned,
not bolded, and lowercase), and write operations into thethird.

Class Name

attrbutes
Class
operations()

resporsíbijity

Active Classes
Active classes initiate and control the flow of activity, while passive classes store dataand serve other
classes. Illustrate active classes with a thicker border.

Class Name
attrbutes

Active class Operations()

Visibility
Use visibility markers to signify who can access the information contained within a class. Private
visibility, denoted with a - sign, hides information from anything outsidethe class partition. Public
visibility, denoted with a + sign, allows all other classes to view the marked information. Protected
visibility, denoted with a # sign, allows child classes to access information they inherited from a parent
class.

Marker Visibility
+ public

- private

# protected

~ package
 Visibility

Associations: Associations represent static relationships between classes. Place association

names above, on, or below the association line. Use a filled arrow to indicate the direction of the
relationship. Place roles near the end of an association. Roles represent the way the two classes see
each other.

Multiplicity (Cardinality): Place multiplicity notations near the ends of an association. These
symbols indicate the number instances of one class linked to one instance of the other class. For example,
one company will b one or more employees, but each employee works forjust one company.

Indicator Meaning

Class Name Cass0..1

Name ZERO or one
1 Only one
0 * 0 or more
attrbutes 1..*
attrbutes * 1 or more
operations operations
0 Only 0 where 0>1
() ()

resporsíbiji 0..0
resporsíbiji Zero to 0( where 0> 1)
ty ty
1.n One to 0 ( where 0>1)

Constraint
Place constraints inside curly braces { }.

Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A, the whole, and
Class B, its part. Illustrate composition with a filled diamond.
Use a hollow diamond to represent a simple aggregation relationship, in which the "whole" class plays a more
important role than the "part" class, but the two classes arenot dependent on each other. The diamond ends in
both composition and aggregationrelationships point toward the "whole" class (i.e., the aggregation).

Generalization:
Generalization name for inheritance or an "is a" relationship. It refers to a relationship between two classes
where one class is a specialized version of [Link] example, Honda is a type of car. So the class Honda
would have a generalizationrelationship with the class [Link] real-life coding examples, the difference between
inheritance and aggregation can beconfusing. If you have an aggregation relationship, the aggregate (the
whole) can access only the PUBLIC ftnctions of the part class

UML Class Diagram: Association. Aggregation and Composition The UML Class
diagram is used to visually describe the problem domain in terms oftypes of objects (classes) related to each
other in different ways.

There are 3 primary inter-object relationships: Association, Aggregation, and Composition. Using the
right relationship line is important for placing implicit restrictions on the visibility and propagation of
changes to the related classes, a matterthat plays an important role in understanding and reducing
system complexity.
Association
The most abstract way to describe a static relationship between classes is using the Association link, which
simply states that there is some kind of a link or a dependencybetween two classes or more.

class Logical View

ClassA AsoSgtion ClassB

Weak Association

Class A may be linked to Class B to show that one of its methods of the Class B instance or
returns an instance of Class B.

class Logical Vie

ClassA CtassB
+ Fo O(class b)
: void

Strong Association

Class A may also be linked to Class B to show that it holds a reference to the Class B instance.

class Logical View

ClassA

Class B
m_CiBEB.• Cle—B 1 1
«propertyx
+ Cle—BO : CjesB

Aggregation (Shared Association) (Weak Class)

In cases where there's a part-of relationship between Class A (whole) and Class B (part), we can be
more specific and use the aggregation link instead of the association.
link, highlighting that the same Class B instance can also be aggregated by other classes in the
application (therefore aggregation is also known as shared association).Class B is weak Class.

class Aggregaöon

Cta ss A

It's important to note that the aggregation link doesn't state in any way that Class A owns Class B nor
that there's a parent-child relationship (when parent deleted all its

child's are being deleted as a result) between the two. Actually, quite the opposite! Theaggregation link
is usually used to stress the point that Class A instance is not the exclusive container of Class B
instance, as in fact the same Class B iner

Aggregation vs. Association:

The association link can replace aggregation link in every situation, while aggregation cannot replace
association in situations where there's only a 'weak link' between the classes, i.e. Class A has method/s
that contain parameter of Class B, butClass A doesn 't hold reference to Class B instance.
Martin Fowler suggest that the aggregation link should not be used at all because it hasno added value
and it disturb consistency, Quoting Jim Rumbaugh "Think ofit as a modeling placebo ".
We should be more specific and use the composition link in cases where in addition tothe part-of
relationship between Class A and Class B - there's a strong lifecycle dependency between the two,
meaning that when Class A is deleted then ClassB is also deleted as a result. Class Person is strong
class.

The composition link shows that a class (container, whole) has exclusive ownership over other
class/s (parts), meaning that the container object and its parts constitute a parent-child/s
relationship.

Unlike association and aggregation, when using the composition relationship, the composed class
cannot appear as a return type or parameter type of the composite class. Thus, changes to the
composed class cannot propagate to the rest of the system. Consequently, usage of composition
limits complexity growth as the systemgrows.
 Clarification: It is possible for a class to be composed by more than one class. For example, Class A
may be composed by Class B and Class C. However, unlike aggregation, instances of Class B and S
Class C will never share the same ClassA instance. That would violate the propagation of changes
principle. ClassB instance willhave its own instance of ClassA, and ClassC instance will have its own
instance of ClassA.

Conclusion: The Class diagram was made successfully by following the stepsdescribe below. Output:
Class diagram

Practical Number: 5
Diagram

Outcome: Can draw the Component diagram.

Objective: Drawing the component diagram

Description: A component is something required to execute a stereotype function. Examples of
stereotypes in components include executables, documents, database tables, files, and library files.

Components are wired together by using an assembly connector to connect the required interface of
one component with the provided interface of another component. This illustrates the service
consumer - service provider relationship between the two components.
 An assembly connector is a "connector between two components that defines that onecomponent
provides the services that another component requires. An assembly connector is a connector that is
defined from a required interface or port to a provided interface or port."

When using a component diagram to show the internal structure of a component, the
provided and required interfaces of the encompassing component can delegate to thecorresponding
interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a component (as specified by
its ports) to the internal realization of that behavior by the component' spans. "

The example above illustrates what a ical insurance policy administration system might look like.
Each of the com onents depic in the above diagram may have other component diagrams illustrating
its inte al struc

component is represented by a rectangle with either the keyword "component" or a stereotype in the
top right corner: a small rectangle with two even smaller rectanglesjutting out on the left.

The lollipop, a small circle on a stick, represents an implemented or provided interface. The socket
symbol is a semicircle on a stick that can fit around the lollipop. This socketis a dependency or
needed interface.

The component diagram notation set now makes it one of the easiest UML diagrams todraw. Figure 1
shows a simple component diagram using the former UML 1.4 notation; the example shows a
relationship between two components: an Order System component that uses the Inventory System
component. As you can see, a component in UML 1.4 was drawn as a rectangle with two smaller
rectangles obtruding from its leftside.
 Practical Number: 6
Experiment Name: Sequence Diagram

Outcome: Can draw the sequence diagram.

Objective: Drawing the sequence diagram

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard

keyboard and mouse, colored monitor.

Software Requirements: Argo UML, Windows XP

Theory:
UML sequence diagrams model the flow of logic within the system in a visual manner,enabling
the user both to document and validate the logic, and are commonly used forboth analysis and
desiB1 purposes. Sequence diagrams are the most popular UML artifact for dynamic modeling,
which focuses on identiffing the behavior within your system. Sequence diagrams, along with
class diagrams and physical data models are the most important design-level models for modern
application development.

Sequence iagrams are Ically used to model:

Usage sc ari usage scenario is a description of a potential way the system is used. The logic of a
usage scenario may be part of a use case, perhaps an alternate course. It may also be one entire
pass through a use case, such as the logic describedby the basic course of action or a portion of the
basic course of action, plus one or more alternate scenarios. The logic of a usage scenario may
also be a pass through the logic contained in several use cases. For example, a student enrolls in
the university, and then immediately enrolls in three seminars.

The logic of methods. Sequence diagrams can be used to explore the logic of a complex operation,
function, or procedure. One way to think of sequence diagrams,particularly highly detailed
diagrams, is as visual object code.

The logic of services. A service is effectively a high-level method, often one that
can be invoked a by a wide variety of clients. This includes web-services as well as business
transactions implemented by a variety of technologies such as CICS/COBOL or CORBA-
compliant object request brokers (ORBs).

FIG shows the logic for how to enroll in a seminar. One should often develop a system- level
sequence diagram to help both visualize and validate the logic of a usage scenario. It also helps to
identifr•' significant methods/services, such as checking to see if the applicant already exists as a
customer, which the system must support.
The dashed lines hanging from the boxes are called object lifelines, representing the life span
of the object during the scenario being modeled. The long, thin boxes on thelifelines are
activation boxes, also called method-invocation boxes, which indicate processing is being
performed by the target object/class to fulfill a message.
How to Draw Sequence Diagrams

Sequence diagramming really is visual coding, even when you are modeling a usage scenario via a
system-level sequence diagram.
While creating a sequence diagram. Start by identifying the scope of what you are to model. You
should typically tackle small usage scenarios at the system level ora single method/service at the
detailed object level.

Regarding style issues for sequence diagramming, prefer drawing messages going from left-to-
right and return values from right-to-left, although that doesn't always work with complex
objects/classes. Justify the label on messages and return values, so theyare closest to the
arrowhead. Also prefer to layer the sequence diagrams: from left-to- right. indicate the actors,
then the controller class(es), and then the user interface class(es), and, finally, the business
class(es). During design, you probably need to addsystem and persistence classes, which you
should usually put on the right-most side of sequence diagrams. Laying your sequence diagrams
in this manner often makes themeasier to read and also s • easi to find layering logic problems,
such as user interface classes directly.
 Practical Experiment no: 7
Experiment Name: Sequence Diagram
Outcome: Can draw the sequence diagram.
Objective: Drawing the sequence diagram
Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standard
keyboard and mouse, colored monitor.
Software Requirements: Argo UML, Windows XP
Theory:
Outcome: Students will be able td draw the collaboration diagram
Objective: draw the collaboration diagram using argo UML.
Description: Collaboration diagrams ar relatively easy to draw. They show the relationship between
objects and the order of messages passed between them. The objects are listed as icons and arrows indicate
the messages being passed betweenl them. The numbers next to the messages are called sequence S
numbers. As the name suggests, they showthe sequence of the messages as they are passed between the
objects. There are many acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format canbe
used, as the example below shows, or for more detailed and complex diagrams a 1,

1.1 , 1.2, 1.2.1... scheme can be used.

OUTPUT: Collaboration diagram for issuing Book:

 avall±llity ofbook0

Collaboration diagram for returning Book:

Conclusion: The Collaboration diagram was made successfully by following the

stepsdescribe.
 Exeriment Number: 8
Relationship Diagram

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM,

Standardkeyboard, mouse, colored monitor.

Software Requirements: SmartDraw, MS Word.

Outcome: Can produce the requirements in Entity Relationship diagram.

Objective: Prepare a Requirement document in by using Entity Relationship Diagram.

Description: An Entity Relationship (ER) Diagram is a type of flowchart that

illustrates how "entities" such as people, objects or concepts relate to each other
within a system. ER Diagrams are most often used to design or debug relational
databases in the fieldsof software engineering, business information systems,
education and research.

Components: An ER diagram is a m s of visualizing how the information a

systemproduces is related. There are five main components ERD:

Entities, which are e ented by rectangles. An entity is an object or concept about

which you want to store information. A weak entity is an entity that must defined
by a foreign key relationship with another entity as it cannot be uniquely
identified by its ownattributes alone.

Entity Entity

Actions, which are represented by diamond shapes, show how two entities
share information in the database. In some cases, entities can be self-linked.
For example, employees can supervise other employees.
Attributes, which are represented by ovals. A key attribute is the unique, distinguishing characteristic of
the entity. For example, an employee's social security number might be the employee's key attribute.

A multivalued attribute can have more than one value. For example, an employee entitycan have
multiple skill values.

A derived attribute is based on another athibute. For example, an employee's monthlysalary is based
on the employee's annual salary.

Attribute

Connecting lines, solid lines that connect attributes to show the relationships ofentities in the
diagram.
Cardinality specifies how many instances of an entity relate to one instance of another entity.
Ordinality is also closely linked to cardinality. While cardinality specifies the occurrences of a
relationship, ordinality describes the relationship as either mandatory or optional. In other words,
cardinality specifies the maximum number of relationships and ordinality specifies the absolute
minimum number of relationships.

There are many notation styles that express cardinality.

Information Engineering Style
one to one

many

or more

zero or {optional)
 many

one only one (mandatory)

zem or many (optional)

Entity Relationship Diagram Example

Tips for Effective ER Diagrams

1. Make sure that each entity only appears once per diagram.
2. Name every entity, relationship, and attribute on your diagram.
3. Examine relationships between entities closely. Are they necessary? Are there anyrelationships missing?
Eliminate any redundant relationships. Don't connect relationships to each other.

Practical Number: 9

Experiment Name: Data Flow Diagram

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standardkeyboard, mouse,
colored monitor.

Software Requirements: SmartDraw/MS Word, Windows XP.

Outcome: Can produce the requirements in Data Flow diagram.

 Objective: Prepare a Requirement document in by using Data Flow Diagram.

Description: Data flow diagram is gaphical representation of flow of data in an information

system. It is capable of depicting incoming data flow, outgoing data flow and stored data. The
DFD does not mention anything about how data flows through thesystem.

There is a prominent difference between DFD and Flowchart. The flowchart depicts flow of
control in program modules. DFDs depict flow of data in the system at various levels. DFD does
not contain any control or branch elements.
Components:
External Entity: an outside system that sends or receives data, communicating with thesystem
being diagrammed. They are the sources and destinatio Information entering or leaving the
system. They might be an outside organization or pe n, a computer system or a business system.
They are also known as terminators, so ces an nks or actors. They are typically drawn on the edges
of the diagram.
Process any process that changes the data, producing an output. It might perform computations, or
sort data based on logic, or direct the data flow based on business rules. A short label is used to
describe the process, such as "Submit payment."
Data store files or repositories that hold information for later use, such as a database table or a
membership form. Each data store receives a simple label, such as "Orders."
Data flow the route that data takes between the external entities, processes and data stores. It
portrays the interface between the other components and is shown with arrows, typically
labeled with a short data name, like "Billing details."

Data Store
Data Flow
DFD rules
Each process should have at least one input and an output.

Each data store should have at least one data flow in and one dataflow out.

Data stored in a system must go through a process.

All processes in a DFD go to another process or a data store.
 Practical Number: 10

Experiment Name: Mini Proiect To-Do List

Hardware Requirements: Pentium 4 processor (2.4 GHz), 128 Mb RAM, Standardkeyboard, mouse,
colored monitor.

Software Requirements: Windows/MAC Operating System, Web Browser

Objective: Progress Tracking, Time Management, Clarity of Goals.