Unified Modeling Language (UML)

• Unified Modeling Language (UML) is a standardized, general-purpose modeling language managed by the Object Management Group (OMG).
• UML uses graphic notation techniques for creating visual models of software-intensive systems.
• UML 2.2 defines 14 types of diagrams divided into structural and behavioral categories.
• 7 diagram types represent structural information, and 7 represent behavioral modeling, including interaction aspects.

Structural Diagrams

• Composite Structure Diagram: Models the internal structure of a class or component.
• Package Diagram: Organizes model elements into packages to manage complexity.
• Object Diagram: Shows instances of classes and their relationships at a specific point in time.
• Deployment Diagram: Visualizes the deployment of software artifacts to hardware nodes.
• Profile Diagram: Allows creating custom UML profiles with stereotypes, tagged values, and constraints.
• Class Diagram: Models the static structure of a system, including classes, attributes, and relationships.
• Component Diagram: Models the physical components of a system and their interfaces.

Behavioral Diagrams

• Activity Diagram: Represents the flow of activities in a system or business process.
• Use Case Diagram: Captures the functional requirements of a system from the user's perspective.
• State Machine Diagram: Models the states of an object and the transitions between them.
• Interaction Diagram: Illustrates interactions between objects, including Sequence, Communication, Interaction Overview and Timing Diagrams.
• Sequence Diagram: Shows interactions between objects in a time-ordered sequence.
• Communication Diagram: Focuses on the relationships between objects and their communication.
• Interaction Overview Diagram: Provides a high-level view of the interactions in a system.
• Timing Diagram: Illustrates the timing constraints and durations of interactions.

Component Diagrams

• Component diagrams model physical aspects of object-oriented systems like visualizing, specifying, and documenting component-based systems.
• Component diagrams construct executable systems through forward and reverse engineering.
• Component diagrams are essentially class diagrams, focusing on a system's components, modeling the static implementation view.
• Component diagrams break down a system into levels of functionality.
• Each component has a specific aim and interacts with other essential elements on a need-to-know basis.
• Data flows into the component via a port, converts it into a format usable by internal components.
• Interfaces represent services, with required interfaces on the right and provided on the left.
• Required interfaces signify services needed fulfill tasks, delivering services via provided interfaces.
• Internal components are surrounded by a box, can represent the overall system or a subsystem.
• The "lollipop" symbol represents the interface that the component provides and is shorthand for a realization relationship.
• Half-circle symbols represent an interface that the component requires.

Basic Concepts of Component Diagrams

• A component is a modular system part, encapsulating its contents and replaceable inside the environment.
• In UML 2, a component is drawn as a rectangle with stacked compartments.
• Model a component as a rectangle with name, icon, or stereotype text/icon.

Ports and Relationships

• Ports are squares on the system or component edge, exposing required and provided interfaces.
• Graphically, a component diagram shows vertices and arcs, containing components, interfaces, and dependencies.
• Relationships in component diagrams also include aggregation, constraint, generalization, association, and realization.
• An association is a semantic relationship between typed instances, with properties at each end.
• Composition is a strong aggregation, requiring a part instance occur in at most one composite at a time, deleting parts on composite deletion.
• Aggregation is a kind of association, with one end marked shared, indicating a shared aggregation.
• A constraint is a restriction in text or a machine-readable language.
• Dependency signifies that one model element requires another's specification/implementation.
• Generalization is a taxonomic relationship between general and specific classifiers, where specific classifies inherits features from general classifiers.

Modeling a Physical Database

• For modeling a physical database, identify classes that represent the logical database schema.
• To visualize, specify, construct, and document any mapping, create a component diagram that contains components stereotyped as tables.

Deployment Diagrams

• Deployment diagrams show the configuration of run time processing nodes, and their resident components.
• Deployment diagrams model the physical aspects of an object-oriented system.
• They model the static deployment view/ topology of the hardware in a system.
• Existing systems that interact with a newly added system are reflected.
• The required robustness of system is described.
• Connections into system are defined.
• Middleware is detailed.
• They capture hardware and it's software, plus users that interact with these.
• Security of the system is described alongside monitoring deployed systems.

Purpose of Deployment Diagrams

• Show runtime system structure.
• Capture hardware that will be used for system implementation, with hardware link descriptions.
• Model physical hardware and communication paths between them.
• Aid in planning system architecture.
• They document the deployment of software components or nodes.
• Deployment diagrams visualize, specify, and document embedded, client/server, and distributed systems.
• These manage executable systems through forward and reverse engineering.
• A deployment diagram is a class diagram focusing a system's nodes in vertices and arcs.
• Deployment diagrams includes nodes, or 3-D boxes representing software or hardware.
• HW nodes are signified with stereotypes.
• Connections between nodes are represented as lines, with stereotypes.
• Nodes can reside within other nodes.
• Dependency, association relationships are other notations that may contain notes and constraints.

Modeling an Embedded System

• Identify devices and nodes unique to the system.
• Use UML's extensibility mechanisms for visual cues, system-specific stereotypes.
• Ensure to distinguish processors versus devices that do not contain software.
• Indicate relationships with deployment diagrams.

Modeling a Client/Server System

• Identify client and server nodes.
• Highlight devices germane to the system's behavior like credit card readers.
• Stereotype processors and devices.
• Model the topology in a deployment diagrams and specify relationships.

Checklist

• When drafting a deployment planning for your company, follow the checklist to assist.
• Verify if different versions of the system will be in production at the same time and define a process to resolve the differences.
• What physical sites do need to deploy to and the order?
• How the support and operations staff will be trained?
• Will you deploy a production support system for simulating problems?
• Define who will install it and how long it should take.
• Define where install may fail.
• What is needed to back out if the installation fails, and how long will this take.
• Define the amount of time needed to install the system.
• What backups are needed to install it?
• Is there any need to convert data?
• How will we know if the installation was successful?
• Define what documentation, in what formats and languages, do your users need.
• How will updates to this documentation be deployed?

Scenario

• ABC Cybertek requests the design and development of their online shopping system.
• The online application resides on the application server, the shopping database in a separate server.
• The customer orders via the Item order module.
• Next the pricing module calculates total price.
• Final pricing module prepares bill using pricing and discount modules.
• The bill is printed using final pricing module and payment is through a banking portal.
• For this scenario, create a component and deployment diagram.