UML component diagram - Credit card agency

"A credit card is a payment card issued to users as a system of payment. It allows the cardholder to pay for goods and services based on the holder's promise to pay for them. The issuer of the card creates a revolving account and grants a line of credit to the consumer (or the user) from which the user can borrow money for payment to a merchant or as a cash advance to the user." [Credit card. Wikipedia]
The UML component diagram example "Credit card agency" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the Rapid UML solution from the Software Development area of ConceptDraw Solution Park.

The vector stencils library "UML use case diagrams" contains 25 symbols for the ConceptDraw PRO diagramming and vector drawing software.
"Use case diagrams are usually referred to as behavior diagrams used to describe a set of actions (use cases) that some system or systems (subject) should or can perform in collaboration with one or more external users of the system (actors). Each use case should provide some observable and valuable result to the actors or other stakeholders of the system. ...
Use case diagrams are in fact twofold - they are both behavior diagrams, because they describe behavior of the system, and they are also structure diagrams - as a special case of class diagrams where classifiers are restricted to be either actors or use cases related to each other with associations. ...
Use case is usually shown as an ellipse containing the name of the use case. ...
Name of the use case could also be placed below the ellipse. ...
If a subject (or system boundary) is displayed, the use case ellipse is visually located inside the system boundary rectangle. Note, that this does not necessarily mean that the subject classifier owns the contained use cases, but merely that the use case applies to that classifier. ...
A list of use case properties - operations and attributes - could be shown in a compartment within the use case oval below the use case name. ...
Use case with extension points may be listed in a compartment of the use case with the heading extension points. ...
A use case can also be shown using the standard rectangle notation for classifiers with an ellipse icon in the upper right-hand corner of the rectangle and with optional separate list compartments for its features. ...
Subject (sometimes called a system boundary) is presented by a rectangle with subject's name, associated keywords and stereotypes in the upper left corner. Use cases applicable to the subject are located inside the rectangle and actors - outside of the system boundary. ...
Standard UML notation for actor is "stick man" icon with the name of the actor above or below of the icon. Actor names should follow the capitalization and punctuation guidelines for classes. The names of abstract actors should be shown in italics. ...
Custom icons that convey the kind of actor may also be used to denote an actor, such as using a separate icon(s) for non-human actors. ...
An actor may also be shown as a class rectangle with the standard keyword «actor», having usual notation for class compartments ...
An actor can only have binary associations to use cases, components, and classes. ...
An association between an actor and a use case indicates that the actor and the use case somehow interact or communicate with each other.
Only binary associations are allowed between actors and use cases.
An actor could be associated to one or several use cases. ...
A use case may have one or several associated actors." [uml-diagrams.org/ use-case-diagrams.html]
The example "Design elements - UML use case diagrams" is included in the Rapid UML solution from the Software Development area of ConceptDraw Solution Park.

"Algorithmic trading, also called automated trading, black-box trading, or algo trading, is the use of electronic platforms for entering trading orders with an algorithm which executes pre-programmed trading instructions whose variables may include timing, price, or quantity of the order, or in many cases initiating the order by a "robot", without human intervention. Algorithmic trading is widely used by investment banks, pension funds, mutual funds, and other buy-side (investor-driven) institutional traders, to divide large trades into several smaller trades to manage market impact and risk. Sell side traders, such as market makers and some hedge funds, provide liquidity to the market, generating and executing orders automatically.
A special class of algorithmic trading is "high-frequency trading" (HFT), which is often most profitable during periods of high market volatility. During the past years, companies such as Algorates have employed HFT strategies, recording high profits even during periods in which the markets have seen steep declines." [Algorithmic trading. Wikipedia]
The UML use case diagram example "Trading system usage scenarios" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the Rapid UML solution from the Software Development area of ConceptDraw Solution Park.

"In software and systems engineering, a use case is a list of steps, typically defining interactions between a role (known in Unified Modeling Language (UML) as an "actor") and a system, to achieve a goal. The actor can be a human or an external system.
In systems engineering, use cases are used at a higher level than within software engineering, often representing missions or stakeholder goals. The detailed requirements may then be captured in Systems Modeling Language (SysML) or as contractual statements.
As an important requirement technique, use cases have been widely used in modern software engineering over the last two decades. Use case driven development is a key characteristic of process models and frameworks like Unified Process (UP), Rational Unified Process (RUP), Oracle Unified Method (OUM), etc. With its iterative and evolutionary nature, use case is also a good fit for agile development." [Use case. Wikipedia]
The template "UML use case diagram" for the ConceptDraw PRO diagramming and vector drawing software is included in the Rapid UML solution from the Software Development area of ConceptDraw Solution Park.
www.conceptdraw.com/ solution-park/ software-uml

This example of bank ATM UML activity diagram was created on the base of UML use case diagram of automated teller machine from the course "Thinking in Java, 2nd edition, Revision 9" by Bruce Eckel published on the website of the Computer Science and Electrical Engineering Department of the University of Maryland, Baltimore (UMBC).
"If you are designing an auto-teller, for example, the use case for a particular aspect of the functionality of the system is able to describe what the auto-teller does in every possible situation. Each of these “situations” is referred to as a scenario, and a use case can be considered a collection of scenarios. You can think of a scenario as a question that starts with: “What does the system do if...?” For example, “What does the auto-teller do if a customer has just deposited a check within the last 24 hours, and there’s not enough in the account without the check having cleared to provide a desired withdrawal?”
Use case diagrams are intentionally simple to prevent you from getting bogged down in system implementation details prematurely...
Each stick person represents an “actor,” which is typically a human or some other kind of free agent. (These can even be other computer systems, as is the case with “ATM.”) The box represents the boundary of your system. The ellipses represent the use cases, which are descriptions of valuable work that can be performed with the system. The lines between the actors and the use cases represent the interactions.
It doesn’t matter how the system is actually implemented, as long as it looks like this to the user."
[csee.umbc.edu/ courses/ 331/ resources/ tij/ text/ TIJ213.gif]
This automated teller machine (ATM) UML use case diagram example was created using the ConceptDraw PRO diagramming and vector drawing software extended with the ATM UML Diagrams solution from the Software Development area of ConceptDraw Solution Park.

"A catalog merchant (catalogue merchant in British and Canadian English) is a form of retailing. The typical merchant sells a wide variety of household and personal products, with many emphasizing jewelry. Unlike a self-serve retail store, most of the items are not displayed; customers select the products from printed catalogs in the store and fill out an order form. The order is brought to the sales counter, where a clerk retrieves the items from the warehouse area to a payment and checkout station. ...
The catalog merchant has generally lower prices than other retailers and lower overhead expenses due to the smaller size of store and lack of large showroom space.
There are a few key benefits to this approach. By operating as an in-store catalog sales center, it could be exempt from the "Resale price maintenance" policy of the manufacturers, which can force conventional retailers to charge a minimum sales price to prevent price-cutting competition; it also reduces the risk of merchandise theft, known in the industry as shrinkage.
From the consumer's point of view, there are potential advantages and disadvantages. The catalog showroom approach allows customers to shop without having to carry their purchases throughout the store as they shop. Possible downsides include that customers may be required to give their contact information when an order is placed, take the time to fill out order forms, and wait a period of time for their order to be available for purchase. This wait may be days long, one of the chief vulnerabilities of the catalog showroom approach." [Catalog merchant. Wikipedia]
The UML use case diagram example "System of goods selling via catalogues" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the Rapid UML solution from the Software Development area of ConceptDraw Solution Park.

"An example scenario is presented to demonstrate how a common issue tracking system would work:
(1) A customer service technician receives a telephone call, email, or other communication from a customer about a problem. Some applications provide built-in messaging system and automatic error reporting from exception handling blocks.
(2) The technician verifies that the problem is real, and not just perceived. The technician will also ensure that enough information about the problem is obtained from the customer. This information generally includes the environment of the customer, when and how the issue occurs, and all other relevant circumstances.
(3) The technician creates the issue in the system, entering all relevant data, as provided by the customer.
(4) As work is done on that issue, the system is updated with new data by the technician. Any attempt at fixing the problem should be noted in the issue system. Ticket status most likely will be changed from open to pending.
(5) After the issue has been fully addressed, it is marked as resolved in the issue tracking system.
If the problem is not fully resolved, the ticket will be reopened once the technician receives new information from the customer. A Run Book Automation process that implements best practices for these workflows and increases IT personnel effectiveness is becoming very common." [Issue tracking system. Wikipedia]
The UML use case diagram example "Ticket processing system" was created using the ConceptDraw PRO diagramming and vector drawing software extended with the Rapid UML solution from the Software Development area of ConceptDraw Solution Park.

The vector stencils library "UML composite structure diagrams" contains 36 symbols for the ConceptDraw PRO diagramming and vector drawing software.
"The key composite structure entities identified in the UML 2.0 specification are structured classifiers, parts, ports, connectors, and collaborations.
(1) Part : A part represents a role played at runtime by one instance of a classifier or by a collection of instances. The part may only name the role, it may name an abstract superclass, or it may name a specific concrete class. The part can include a multiplicity factor, such as the [0..*] shown for Viewer in the diagram.
(2) Port : A port is an interaction point that can be used to connect structured classifiers with their parts and with the environment. Ports can optionally specify the services they provide and the services they require from other parts of the system. In the diagram, each of the small squares is a port. Each port has a type and is labelled with a name, such as "var", "indVar1", or "view" in the diagram. Ports may contain a multiplicity factor, for example.
Ports can either delegate received requests to internal parts, or they can deliver these directly to the behavior of the structured classifier that the port is contained within. Public ports that are visible in the environment are shown straddling the boundary, while protected ports that are not visible in the environment are shown inside the boundary. All the ports in the diagram are public, except for the view port along the right boundary of FibonacciSystem.
(3) Connector : A connector binds two or more entities together, allowing them to interact at runtime. The connector is shown as a line between some combination of parts, ports and structured classifiers. The diagram shows three connectors between ports, and one connector between a structured classifier and a part.
(4) Collaboration : A collaboration is generally more abstract than a structured classifier. It is shown as a dotted oval containing roles that instances can play in the collaboration.
(5) Structured classifier : A StructuredClassifier represents a class, often an abstract class, whose behavior can be completely or partially described through interactions between parts." [Composite structure diagram. Wikipedia]
The example "Design elements - UML composite structure diagrams" is included in the Rapid UML solution from the Software Development area of ConceptDraw Solution Park.