Introduction to Point-of-sale (POS)

Definition of POS
 Point Of Sale. The physical location at which goods are sold to
customers

 Point Of Sale. The physical location of a transaction but usually

refers to any device or system used to record the transaction for
the retailer.

 CPOS: A computer-based POS which employs software to

implement the POS functionality

POS Components
 Hardware

 Computer Hardware

 POS Hardware

 Communications Hardware

 Software

 Computer Software

 POS Software

 Communications Software

 Accounting Software
 POS Software
 POS software gives the POS system its POS functionality.

 User Interface

 Inventory

 Reports

 Invoicing

 Receivables

 Accounts Payable

 Credit Card Payments

 More ...........

POS: Communications Software

 Networking (Included with modern O/S’s)

 An issue when dealing with non-Windows or legacy (DOS)

solutions
POS: Accounting Software
 Windows-based POS Accounting Software

 ACCPAC Advantage Discovery Series 

 BusinessVision 32   

 BusinessWorks Gold

 ePeachtree

 MYOB Plus for Windows (MYOB Software) 

 Oracle Small Business Suite

 One-Write Plus

 Peachtree Complete Accounting

 QuickBooks Online

 QuickBooks Pro

 Simply Accounting

 Small Business Manager

 Point of sale (POS) (also sometimes referred to as Point of purchase (POP) ) or

checkout is the location where a transaction occurs. A "checkout" refers to a POS
terminal or more generally to the hardware and software used for checkouts, the
equivalent of an electronic cash register.

 A POS terminal manages the selling process by a salesperson accessible interface. The
same system allows the creation and printing of the receipt.
 Web based POS (post 2000s)
 Web based POS software can be run on any computer with an Internet connection and
supported browser, without additional software. The POS software is hosted on secure
servers in multiple data centers with real-time backups.

Retail industry
Main article: Retailing

The retailing industry is one of the predominant users of POS terminals.

A Retail Point of Sales system typically includes a computer, monitor, cash drawer, receipt
printer, customer display and a barcode scanner, and the majority of retail POS systems also
include a debit/credit card reader. It can also include a weight scale, integrated credit card
processing system, a signature capture device and a customer pin pad device. More and more
POS monitors use touch-screen technology for ease of use and a computer is built in to the
monitor chassis for what is referred to as an all-in-one unit. All-in-one POS units save valuable
counter space for the retailer. The POS system software can typically handle a myriad of
customer based functions such as sales, returns, exchanges, layaways, gift cards, gift registries,
customer loyalty programs, BOGO (buy one get one), quantity discounts and much more. POS
software can also allow for functions such as pre-planned promotional sales, manufacturer
coupon validation, foreign currency handling and multiple payment types.

The POS unit handles the sales to the consumer but it is only one part of the entire POS system
used in a retail business. “Back-office” computers typically handle other functions of the POS
system such as inventory control, purchasing, receiving and transferring of products to and from
other locations. Other typical functions of a POS system are to store sales information for
reporting purposes, sales trends and cost/price/profit analysis. Customer information may be
stored for receivables management, marketing purposes and specific buying analysis. Many
retail POS systems include an accounting interface that “feeds” sales and cost of goods
information to independent accounting applications.

[edit] Hospitality industry

Main article: Hospitality

Hospitality point of sales systems are computerized systems incorporating registers, computers
and peripheral equipment, usually on a computer network. Like other point of sale systems, these
systems keep track of sales, labor and payroll, and can generate records used in accounting and
book keeping. They may be accessed remotely by restaurant corporate offices, troubleshooters
and other authorized parties.

Point of sales systems have revolutionized the restaurant industry, particularly in the fast food
sector. In the most recent technologies, registers are computers, sometimes with touch screens.
The registers connect to a server, often referred to as a "store controller" or a "central control
unit." Printers and monitors are also found on the network. Additionally, remote servers can
connect to store networks and monitor sales and other store data.

The efficiency of such systems has decreased service times and increased efficiency of orders.

Another innovation in technology for the restaurant industry is Wireless POS. Many restaurants
with high volume use wireless handheld POS to collect orders which are sent to a server. The
server sends required information to the kitchen in real time.
[edit] Restaurant business

Restaurant POS refers to point of sale (POS) software that runs on computers, usually touch
screen terminals or wireless handheld devices. Restaurant POS systems assist businesses to track
transactions in real time.

Typical restaurant POS software is able to print guest checks, print orders to kitchens and bars
for preparation, process credit cards and other payment cards, and run reports. In addition, some
systems implement wireless pagers and electronic signature capture devices.

In the fast food industry, registers may be at the front counter, or configured for drive through or
walk through cashiering and order taking. Front counter registers take and serve orders at the
same terminal, while drive through registers allow orders to be taken at one or more drive
through windows, to be cashiered and served at another. In addition to registers, drive through
and kitchen monitors may be used by store personnel to view orders. Once orders appear they
may be deleted or recalled by "bump bars", small boxes which have different buttons for
different uses. Drive through systems are often enhanced by the use of drive through wireless (or
headset) systems which enable communications with drive through speakers.

POS systems are often designed for a variety of clients, and can be programmed by the end users
to suit their needs. Some large clients write their own specifications for vendors to implement. In
some cases, POS systems are sold and supported by third party distributors, while in other cases
they are sold and supported directly by the vendor.

Wireless systems consist of drive though microphones and speakers (often one speaker will serve
both purposes), which are wired to a "base station" or "center module." This will, in turn
broadcast to headsets. Headsets may be an all-in-one headset or one connected to a belt pack.

[edit] Hotel business

POS software allows for transfer of meal charges from dining room to guest room with a button
or two. It may also need to be integrated with property management software.

[edit] Checkout system

A Checkout in a Guatemalan supermarket.

A checkout system generally involves the following components:

 General computer hardware

 General computer software
 Checkout hardware
 Checkout software
 Miscellaneous store hardware

Because of the expense involved with a POS system, the eBay guide recommends that if annual
revenue exceeds the threshold of $700,000 per annum, investment in a POS system will be
advantageous.[2]

POS systems are manufactured and serviced by such firms as Fujitsu, IBM, MICROS Systems,
Panasonic, Radiant Systems, Sharp, Squirrel Systems, and Vectron POS among others (see the
point of sale companies category for complete list).

Point of sales systems in restaurant environments operate on DOS, Windows or Unix

environments. They can use a variety of physical layer protocols, though Ethernet is currently the
preferred system.

[edit] Checkout hardware

Specific to the POS industry, generally including:

 USB Credit card reader

 USB Receipt printer
 Cash drawer
 USB Barcode scanner
 USB PIN pad with Integrated Card Swipe
 Stands on which the payment devices are held/mounted/posted

[edit] Checkout software

Top software, based on U.S. Install Base:

 Radiant/Aloha: 24%[unreliable source?]

 Internally Developed: 15%
 MICROS: 14%[3]
 Abstract of the project
This project is a very popular and widely used in many big
supermarket / departmental stores and is used to cater the need of the
sales system there. This is an online system and is used maintain /
control most of the activities happening in big stores. This maintains
and controls the stock details and does online billing and generates
various online reports
 Functional components of the project

Following is a list of functionalities of the system. More functionalities

as deemed appropriate can be added list. And, in places where the
description of functionality is not adequate, appropriate assumptions
can be made.

User Login

First to enter this system the users has to login to this system. Basically
there are 2 types of users in this system.

1. Admin users - Has full access to all the modules of this system.
2. Normal users – Has restricted access. i.e., Normal users have
access to some of the modules only.
 First a login screen should be displayed to get the user details. The
user has to enter the user-id and the password. The password has
to be masked with character ‘*’.
 The user details should be verified against the details in the user
tables and if he / she is valid user, they should be entered into the
system. Once entered, based on the user type access to the
different modules to be enabled / disabled.
 If user enters wrong password for continuously 5 times, the
account should be locked. The information about the login and
logout details should be stored in a separate table.
User Details

This module contains 2 parts. User maintenance and password change.

  User maintenance is used to create a new user, modify the details
of existing user or remove the existing user. Only the admin type
user will have access to this part. Normal user won’t have access
to this. While storing into database the password should be
encrypted and stored. The user can choose his / her own logic to
encrypt the password.
 User password is used to change their own password. Both admin
and normal user will have access to this.

Stock Details

This module is used to maintain the various products available in the

store. Each product available in the store should be classified under a
product category. This module will be enabled only to the admin type
of users.

 A separate screen should be provided to maintain the product

category. It should provide a way to add, modify and delete the
category details.

 If a new product is received it should be added to the system with

the corresponding details like product information, quantity,
category, etc.
 There should be a screen to maintain the vendor details. Vendor
details should be stored in a separate table.
Billing

This is the main / core part of the entire system. The online billing is
done in this part. This includes various things like collecting item details
and updating price, and getting payment information, etc. This screen
should have item details, counter no, user id, payment details, etc. In
addition, the billing should also incorporate and offers/discounts during
that period of time.

 This screen mainly contains a grid type of control to get the

various products purchased. They should have columns like Item
No, Description, Batch No, Rate, Quantity, Price, etc.
 The continuous online bill number should be generated. It should
not be a cyclic number or a previously used number.
 The user should enter item no in the corresponding column of the
grid. The item number should be validated and if found valid the
description, rate and other details have to be displayed
automatically. Then the user should be allowed to enter the
quantity and price and total should update online.
 Once this is done, the mode of payment should be Cash. Then the
amount received should be taken as input and balance should
compute and displayed.
 After this the bill has to be printed with all these details. A
confirmation screen has to be displayed on the screen about the
printing. If bill is not printed properly, provision should be made
to reprint the bill.
Reports

This module is used to print various online reports. This module will be
enabled only to the admin type of users.

 User details report – This contains various information about the

users available.
 User login details report – This report takes the user ID and from /
to date as input and generates the report containing the login
date, login time and logout time, etc.
 Item category report – This gives the different item categories.
  Item details report – This gives the information about the various
items available in the store along with the information like
category, stock level, etc.
 Sales report – This report takes date as input and gives details of
sales made on that date along with item information. This report
should be available for a given date or for a date range.
 Vendor details report – This report gives the details about all the
vendors.
Help

This module contains the following 2 things – Help and About.

 The Help menu should display the detail information about the
system. It is like a typical help system available in any windows
application.
The About menu should give information about this software like
developed by, version and contact details.

WHY MODELLING?

A model is a simplification of reality.A model provides the blueprint of a system.Models helps us to

visualize a system as it is or as we want it to be.Models permit us to specify

the structure or behavior of a system.Model gives us a template that guides us in constructing a

system.Model documents the decisions we have made.

Why do we model?

 help visualizing
 permit specification
 provides a template
  document decisions

Principals of Modelling

 Choose your models well.

 Every model may be expressed at various levels of precision.
 The best models are connected to reality.
 No single model is sufficient.
 The object oriented approach is a way of thinking about a problem using
real world concepts instead using adhoc function concepts.

We intent to learn OOSD approach for the following reason:

 Promotes better understanding of user requirements.

 Leads cleaner design.
 Design flexibility.
 Decomposition of the system is consistent.
 Facilitates data abstraction & information hiding.
 Software reuse.
 Easy maintenance.
 Implementation flexibility.

Aims achieved in modelling

 Model help us to visualize a system as it is or as we want it to be.

 Models permit us to specify the structure or behavior of a system.
 Models gives us a template that guides us in constructing a system.
 Models document the decision we have made.

Modeling is an activity that has been carried out over the years in software development. When writing
applications by using the simplest languages to the most powerful and complex languages, you still need
to model. Modeling can be as straightforward as drawing a flowchart listing the steps carried out by an
application. Why do we use modeling? Defining a model makes it easier to break up a complex
application or a huge system into simple, discrete pieces that can be individually studied. We can focus
more easily on the smaller parts of a system and then understand the "big picture." Hence, the reasons
behind modeling can be summed up in two words:

 Readability
 Reusability
Readability brings clarity—ease of understanding. Understanding a system is the first step in either
building or enhancing a system. This involves knowing what a system is made up of, how it behaves, and
so forth. Modeling a system ensures that it becomes readable and, most importantly, easy to document.
Depicting a system to make it readable involves capturing the structure of a system and the behavior of
the system.

Reusability is the byproduct of making a system readable. After a system has been modeled to make it
easy to understand, we tend to identify similarities or redundancy, be they in terms of functionality,
features, or structure.

We use many models to design, develop, deploy, and manage technology solutions. A partial list of
these models might include business cases, use case diagrams, entity relationship models, object
models, code, test suites, deployment plans, logical data center models, and exception management
plans. Software lifecycle methodologies have traditionally struggled to automate the production of
"downstream" models from "upstream" models, or even to keep the different system models
synchronized. This brief paper describes the modeling space and outlines current efforts to use models
more effectively throughout the technology lifecycle.

Models are typically "scaled down" representations of real-world objects and systems. The reduction in
scale may include size, detail, and aspect (a model that focuses on cost or durability while ignoring
unrelated qualities of the system, for example). In the development of information technology solutions,
models are used to manage complexity and to communicate system requirements between business
stakeholders, solution and system architects, developers, and operations personnel.
RATIONAL ROSE DESCRIPTION
Rational Rose is an object-oriented Unified Modeling Language (UML) software design tool
intended for visual modeling and component construction of enterprise-level software
applications. In much the same way a theatrical director blocks out a play, a software designer
uses Rational Rose to visually create (model) the framework for an application by blocking out
classes with actors (stick figures), use case elements (ovals), objects (rectangles) and
messages/relationships (arrows) in a sequence diagram using drag-and-drop symbols. Rational
Rose documents the diagram as it is being constructed and then generates code in the designer's
choice of C++,Visual Basic, Java, Oracle8, Corba or Data Definition Language.

Two popular features of Rational Rose are its ability to provide iterative development and round-
trip engineering. Rational Rose allows designers to take advantage of iterative development
(sometimes called evolutionary development) because the new application can be created in
stages with the output of one iteration becoming the input to the next. (This is in contrast to
waterfall development where the whole project is completed from start to finish before a user
gets to try it out.) Then, as the developer begins to understand how the components interact and
makes modifications in the design, Rational Rose can perform what is called "round-trip
engineering" by going back and updating the rest of the model to ensure the code remains
consistent.

Rational Rose is extensible, with downloadable add-ins and third-party partner applications. It
supports COM/DCOM (ActiveX), JavaBeans, and Corba component standards.

Rational Environment

First released in 1985, the Rational Environment was an integrated development

environment for theAda programming language, which provided good support for abstraction
through strong typing. Its goal was to provide the productivity benefits associated with
academic single-user programming environments to teams of developers developing mission-
critical applications that could execute on a range of computing platforms.

The Rational Environment was organized around a persistent intermediate representation

(DIANA), providing users with syntactic and semantic completion, incremental compilation, and
integrated configuration management and version control. To overcome a conflict between
strong typing and iterative development that produced recompilation times proportional to
system size rather than size-of-change, the Rational Environment supported the definition of
subsystems with explicit architectural imports and exports; this mechanism later proved useful in
protecting application architectures from inadvertent degradation. The Environment's Command
Window mechanism made it easy to directly invoke Ada functions and procedures, which
encouraged developer-driven unit testing.
The Rational Environment ran on custom hardware, the Rational R1000, which implemented a
high-level architecture optimized for execution of Ada programs in general and the Rational
Environment in particular. The horizontally-microprogrammed R1000 provided two independent
64-bit data paths, permitting simultaneous computation and type checking. Memory was
organized as a single-level store; a 64-bit virtual address presented to the memory system either
immediately returned data, or triggered a page fault handled by the processor's microcode.

The company's name was later changed from "Rational Machines" to Rational to avoid
emphasizing this proprietary hardware.

Rational provided code generators and the cross-debuggers for then-popular instruction set
architectures such as the VAX, Motorola 68000, and x86; much of this was accomplished
through a partnership with Tartan Labs, founded by Bill Wulf to commercialize his work on
optimizing code generators semi-automatically produced from architecture descriptions (PQCC).

Organization

Rational's field Practices underlying the later Rational Unified Process (RUP) - iterative

development, component-based architecture, modelling, continuous developer-driven testing,
requirements management, and automated testing—are all traceable to this experience base.

Second-generation Products

In 1990, Rational launched three parallel development efforts: re-implementation of the Rational
Environment (for Ada) to run on Unix-based workstations from Sun and IBM, development of a
comparable Rational Environment for C++ to run on Unix-based workstations from Sun and
IBM, and development of a workstation-hosted modeling tool called Rose that supported a
graphical notation developed by Grady Booch. Apex, the Rational Environment for Ada, was
launched on Sun and IBM Unix platforms in 1993, and the Rational Environment for C++
followed on the same platforms a year later. A version of Apex that ran on Microsoft Windows
NT was successfully developed and released by Rational's Bangalore team.

Rose 1.0 was introduced at OOPSLA in 1992, but performed poorly in multiple dimensions and
was withdrawn from the market.

The development of Rose 2.0 combined a Windows-based Booch notation editor called Object

System Designer (acquired from Wisconsin-based Palladio) with a new intermediate
representation, and with new semantic analysis, code generation, and reverse engineering
capabilities. The latter, which allowed prospective customers to analyze existing C++ code to
produce "as-built" navigable class diagrams, helped overcome Rational's late re-entry into the
market for object-oriented modeling tools. Rose 2.0 ran on Windows PCs and on several Unix-
based workstations.

UML DESCRIPTION
What is UML?

UML stands for Unified Modeling Language

The UML combines the best of the best from

 Data Modeling concepts (Entity Relationship Diagrams)

 Business Modeling (work flow)
 Object Modeling
 Component Modeling

The UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts
of a software-intensive system

It can be used with all processes, throughout the development life cycle, and across different
implementation technology.

The UML itself distinguishes two types of models:

Structural models: Represent the pieces of a system and their relationships.

Dynamic models: Represent the behavior of the elements of the system and their interactions.

In the UML, model elements may be visible in one of three ways:

 Public: Any outside model element can see the model element.
 Protected: Any descendent can see the model element.
 Private: Only the model element itself, its constituent parts, and the model elements nested
within it can see it.

The UML may be used to:

Display the boundary of a system & its major functions using use cases and actors Illustrate use case
realizations with interaction diagrams Represent a static structure of a system using class diagrams
Model the behavior of objects with state transition diagrams Reveal the physical implementation
architecture with component & deployment diagrams Extend your functionality with stereotypes.
UML Concepts

 An emerging open standard for modeling object-oriented software.

 Resulted from the convergence of notations from three leading object-oriented methods:
 OMT (James Rumbaugh), OOSE (Ivar Jacobson), Booch (Grady Booch)
 Supports the entire software development lifecycle
 Supports diverse applications areas
 Supported by several CASE tools
Three categories

 Modeling Elements (Things)

 Relationships
 Diagrams

Building Blocks of UML

1.Things

 Structural Things

 Behavioral Things

 Grouping Things

 Annotational Things

2. Relationships

 Dependency

 Generalization

 Association

 Realization

3.Diagrams ( 9 types of diagrams)

 Class diagrams
  Object diagrams

 Component diagrams

 Deployment diagrams

(to view static parts of the system)

 Use case diagram

 Sequence diagrams

 Collaboration diagrams

 State chart diagrams

 Activity diagrams

( to view dynamic parts of a system)

UML Concepts and Notation

 UML

Things Relationships Diagrams

Dependency Use case
Association Class
Generalization Sequence
Collaboration
Statechart
Activity
Component
Structural Behavioral Grouping Annotational Deployment

Use case Interaction Package Note

Class State Machine Model
Active Class Subsystem
Interface Framework
Component
Collaboration
Node

Modeling Elements

Structural elements

Class, Interface, Collaboration, Use case, Active class, Component

Behavioral Elements

Interaction, State machine

Grouping Elements

Package, Subsystem

Other elements or Annotational elements

Note

UML Core elements

 Semantically, diagrams express views of a model (that is, subsets of the viewpoint that
each model represents). An individual model element can be presented in one or many of the
diagrams for a model; in other words, a model element can be presented in many different ways
and in many diagrams-but it must be presented in at least one diagram in one way. Diagrams
don't have any special shape assigned to them; they can be free-floating, bounded by a box, or
contained within a package.

The UML Specification highlights three kinds of visual relationships in diagrams:

Connection: Lines connect icons and symbols, forming connecting paths. Paths are always
attached to symbols at both ends (that is, no dangling lines are allowed).
Containment: Boxes, circles, and other fully enclosed shapes contain symbols, icons, and lines.
Visual Attachment: Elements that are close together may have a relationship suggested by their
proximity. For example, a name above a line or next to a box may be interpreted as applying to
the line or box.

Symbols:

UML symbols can have content or just be iconic. Actually, the UML distinguishes between what
it calls, awkwardly, two-dimensional symbols and icons:
 Icons: Fixed in size and shape, icons do not have to be attached to paths (but can be
terminators: icons on the end of a path that qualify the meaning of the path symbol).
They may be located within symbols.
 Two-dimensional symbols: Having the capability to shrink or grow, two-
dimensional symbols can have compartments as well. Some two-dimensional
symbols are also graphs-they contain nodes connected by paths.
Actor:

Actors represent system users. They help delimit the system and give a clearer picture of what the
system should do. It is important to note that an actor interacts with, but has no control over the use
cases.

An actor is someone or something that:

 Interacts with or uses the system

  Provides input to and receives information from the system
 Is external to the system and has no control over the use cases
Actors are discovered by examining:

 Who directly uses the system

 Who is responsible for maintaining the system
 External hardware used by the system
 Other systems that need to interact with the system

The needs of the actor are used to develop use cases. This insures that the system will be what
the user expected.

An actor is something or someone outside the system that interacts directly with it-
typically, a user of the system. An example of an actor is shown below.

Use Case/Collaboration:

A use case is a sequence of interactions by an actor with the system, which yields observable
value to the actor. According to UML, use cases are made to fall into a category of type of class.
The UML calls it a "behavioral thing”. An example of a use case is shown below.

Collaboration is a collection of objects that interact to implement behavior. Typically,

collaboration can be used to specify the realization of a use case or an operation. Collaboration
can also be used to specify a software pattern, and a parameterized collaboration (that is, one
with abstract participants that are replaced when the pattern is used) can specify an architectural
pattern.

Class/Object/Type/Active Class:

A class is an abstraction of a set of possible objects that share the same attributes, operations,
methods, relationships, and semantics.

A class may use a set of interfaces to specify collections of operations it provides to its
environment.

An object is an instance of a class or an example of a type-the same symbol as class, but with the
name underlined. An example is shown below.

An active class is a set of objects, each of which owns a thread of control (that is, it can initiate,
control, and terminate a process or thread).
Interface:

An interface describes the visible operations of a class, component, or package. It defines the
services available from the implementing element.

Component:

A component is a physical, replaceable part of a system that packages implementation and

provides the realization of a set of interfaces. A component represents a physical piece of
implementation of a system, including software code (source, binary, or executable) or
equivalents such as scripts or command files. An example is shown below.

Node:

A node represents a processing resource that exists at run time, with at least a memory and often
processing capability as well. Nodes comprise computing devices and any other physical
resources used in a system, such as people or machines. An example is shown below.
Package:

A package is a UML container used to organize model elements. An example of a package is

shown below.

State:

A state is the condition, status, or situation of an object as part of its lifecycle and/or as the result
of an interaction. A state may also be used to model an ongoing activity. An example of a state is
shown below.

Note:

A note is used to provide explanatory text, such as comments in a model. A note can also be used
in specific ways, depending on the modeling dialect you adopt (requirements are a good
example). An example is shown below.
Lines:

In the UML, lines are used to express messages (dynamic connections between model elements),
"links" (relationships between model elements—the term link also has a formal meaning within
the UML), and interactions. Generally, messages don't appear in structural models; links don't
appear in dynamic models. But this, too, can be varied within a dialect. Lines must be terminated
in some fashion in the UML, either with a model element graphic or an icon.

Messages:

Messages are used in interactions between model elements in dynamic models, those that
represent the behavior in a system. Messages convey information between objects, for example,
and trigger activities. There are four types of messages.

Relationships:

Relationships are used in structural models to show semantic connections between model
elements. A dependency is what The Unified Modeling Language User Guide calls a "using"
relationship, one in which the connection between two things means that if one changes, it
affects the other. Dependencies can be used to identify connections between varieties of model
elements, packages being a notable example. These are unidirectional relationships.

A generalization is a relation between two elements, in which one is a more general form of the
other. Class inheritance is represented this way, but generalization can be used more generally.
Packages are an example.
An association is what the UML calls a structural relationship, mapping one object to another set
of objects. It is also used to identify the communication path between an actor and a use case.

An

A realization is a type of dependency relationship that identifies a contractual link between

elements—a realizing element. For example, a class implements the behaviors in a specifying
element; in this case, it is an interface. A realization also links use cases and collaborations.

Associations:

The UML considers aggregations and composites to be special forms of association with
distinctive notations.

A qualified association is a plain association with an indication of what information to use when
identifying a target object in the set of associated objects; bank account # is used to identify the
customer it belongs to.

An aggregation represents a whole-part relationship. This contrasts with a plain association,

which shows a relationship among/between peers, depending on the number. In an aggregation,
one element is the whole and the other(s) are the parts.
A composition is an aggregation that has strong ownership of its parts. Therefore, if the whole
element disappears, the parts do, too.

Dependencies:

Dependency relationships are frequently stereotyped in the UML to support the needs of
particular types of diagrams or model elements. The following are some examples:

Extends provides a way of handling behavior that is optional in a use case The optional behavior
is packaged in an extending use case and connected via an <<extends>> dependency.

Includes provides a way of handling behavior that is common to a number of use cases. The
optional behavior is factored out, packaged in an included use case, and connected via an
<<includes>> dependency.

Imports are a dependency between packages. A receiving package can access the publicly visible
elements of the package being imported.

Relationships
Association
Dependency or Flow
Realization
Generalization
Composition
Aggregation

Example :
Extensibility Mechanisms

1. Stereotype : extends the vocabulary of the UML

2. Tagged value : extends the properties of UML building blocks
3. Constraint : extends the semantics of a UML building blocks

UML DIAGRAMS DESCRIPTION

1. A diagram is a view into a model

a. Presented from the aspect of a particular stakeholder
b. Provides a partial representation of the system
c. Is semantically consistent with other views
2. There are nine standard diagrams
a. Static views: use case, class, object, component, deployment
b. Dynamic views: sequence, collaboration, statechart, activity
c. Implementation view : component diagrams
d. Deployment view: Deployment diagram
 Class
Diagrams
Use Case
Diagrams Object
Sequence Diagrams
Diagrams

Collaboration Component
Diagrams Models Diagrams

Statechart Deployment
Diagrams Diagrams
Activity
Diagrams

 Class diagrams
 Describe the static structure of the system: Objects, Attributes, and Associations.

 Object diagrams
 shows a set of objects and their relationships. These are static snap shots of
instances of the things found in the class diagram.
 Component diagrams
 shows a set of components and their relationships.
 Deployment diagrams
 shows a set of nodes and their relationships.
 Collaboration diagrams
 focuses on the structural organization of objects that send and received messages.
 Sequence diagrams
 Describe the dynamic behavior between actors and the system and between objects
of the system.
 Use case diagrams
  Describe the functional behavior of the system as seen by the user.
 Statechart diagrams
 Describe the dynamic behavior of an individual object as a finite state machine.
 Activity diagrams
 Model the dynamic behavior of a system, in particular the workflow, i.e. a
flowchart.

Class Diagram
Captures the vocabulary of a system
Class diagrams are used
 during requirements analysis to model problem domain concepts
 during system design to model subsystems and interfaces
 during object design to model classes.

Purpose
Name and model concepts in the system
Specify logical database schemas
Rrepresent the structure of the system.
A class represent a concept and encapsulates state (attributes) and behavior (operations).
attribute has a type.
operation has a signature.
 Class Diagrams
TariffSchedule
Table zone2price Nam
Enumeration getZones()
e
Signatur Price getPrice(Zone)

e
Clas
Multiplicity SimpleWatch
s Associatio
1 1 1 1 n
2 1 2 1
PushButton LCDDisplay Battery Time
state blinkIdx load() now()
push() blinkSeconds()
release() blinkMinutes()
blinkHours()
stopBlinking()
referesh()
Attributes

Operations

Object Diagram
Built during analysis and design
Purpose
Illustrate data/object structures
Specify snapshots
Captures instances and links
Developed by analysts, designers, and implementers
Component Diagram
 Captures the physical structure of the implementation
 Built as part of architectural specification
Purpose
Organize source code
Construct an executable release
Specify a physical database0
Developed by architects and programmers
Deployment Diagram
 Captures the topology of a system’s hardware
 Built as part of architectural specification
Purpose
Specify the distribution of components
Identify performance bottlenecks
Developed by architects, networking engineers, and system engineers.
Use Case Diagram
 Captures system functionality as seen by users and from user’s point of view
 Used during requirements elicitation to represent external behavior
 Built in early stages of development
Purpose
Specify the context of a system
Capture the requirements of a system
Validate a system’s architecture
Drive implementation and generate test cases
Developed by analysts and domain experts
 Package
SimpleWatch

Actor
ReadTime

SetTime
WatchUser WatchRepairPerson

Use case
ChangeBattery

Collaboration Diagram

Captures dynamic behavior (message-oriented)

Purpose

Model flow of control

Illustrate coordination of object structure and control
Sequence Diagram
Used during requirements analysis
 To refine use case descriptions
 To find additional objects (participating objects)
Used during system design
 To refine subsystem interfaces
Classes are represented by columns
Messages are represented by arrows
Activations are represented by narrow rectangles to sent the message, and is as long as all nested
activations
Lifelines are represented by dashed lines
Purpose
Captures dynamic behavior (time-oriented) in terms of interactions.
Model flow of control
Illustrate typical scenarios
Complement the class diagrams which represent structure.
 Object
:SimpleWatch :LCDDisplay :Time
:WatchUser

pressButton1() blinkHours()
pressButton1() blinkMinutes()

pressButton2() incrementMinutes()
refresh()
pressButtons1And2()
commitNewTime()
stopBlinking()

Message
Activation
Activity Diagrams
A special case of a state chart diagram in which states are activities (“functions”)
Purpose
Model business workflows, flow control within a system, and operations
Captures dynamic behavior (activity-oriented)
Two types of states:
Action state:
Cannot be decomposed any further
Happens “instantaneously” with respect to the level of abstraction used in the
model
Activity state:
Can be decomposed further
The activity is modeled by another activity diagram
Activity Diagrams: Swimlanes

Dispatcher
Allocate
Resources

Open Coordinate Archive

Incident Resources Incident

FieldOfficer
Document
Incident
Statechart Diagram

Captures dynamic behavior (event-oriented)

Purpose

Model object lifecycle

Model reactive objects (user interfaces, devices, etc.)

Event State
button1&2Pressed
Initial state
button2Pressed
Blink Increment
Hours Hours

button1Pressed
Transition

button1&2Pressed button2Pressed
Blink Increment
Minutes Minutes

button1Pressed

button2Pressed
Stop Blink Increment
Blinking Seconds Seconds
button1&2Pressed