Software Modeling with UML

Why Model?

• Models are a simplification of reality.
• Models give blueprints for a system.
• Modeling designs software apps before any coding happens.
• Modeling is essential for large projects but also helpful for medium and smaller ones.
• Modelling is an engineering technique with a proven track record.
• While unsuccessful projects vary, successful ones utilize modelling.
• Systems are modelled to better understand them.

Benefits of Modelling

• Modelling has four aims:
• Visualization of a system as it is or how it's intended to be.
• Specification of a system's structure or behavior.
• Providing a template to construct a system.
• Documentation of decisions.

UML (Unified Modeling Language)

• It is a standardized, general-purpose modelling language for software engineering.
• Governed by the Object Management Group (OMG).
• UML's website is http://www.uml.org.

Why Use UML?

• UML employs standardized graphical notation for specifying, visualizing, constructing and documenting software systems.
• It increases understanding/communication to customers and developers, regarding the product.
• UML enjoys support across numerous software packages like UMLet, Rational Rose, and ArgoUML.

Building Blocks of UML

• The UML vocabulary includes three building blocks:
• Things: essential abstractions in a model; examples are John, Jesmin, Josheph, Jessy.
• Relationships: connect the items together; examples are Father, Mother, Daughter, Son.
• Diagrams: collection of things; an example is the Happy Family.

THINGS in UML

• Structural things are nouns and static aspects of UML models, irrespective of time.
• Behavioral things are verbs and dynamic aspects of the models.
• Grouping things are organizational model parts.
• Annotation things are model explanatory parts.

Structural Things

• Structural things are nouns in the UML model.
• They are static parts that represent conceptual or physical elements.
• There are seven types of structural things.

Class (Structural Things)

• A class is a template/blueprint of behaviors/states for an object.
• Describes sets of objects sharing attributes, operations and relationships.

Interface (Structural Things)

• A collection of operations that specify a class's or component's service.
• It describes the externally visible behavior of an element.
• It cannot be instantiated and does not include constructors.
• It is implemented by a class (unchanged in implementation) instead of being extended by one.
• Interfaces can extend multiple interfaces.

Collaboration (Structural Things)

• It is collection of UML building blocks, which includes classes, interfaces, and relationships.
• These interconnected blocks provide functionality within the system.

Use Case (Structural Things)

• Is a description of actions a system performs, yielding a valuable, observable result for a particular actor.

Active Class (Structural Things)

• A class whose objects initiate control activity by owning processes or threads, to modify the state.
• Active objects initiate and control process flow as passive objects await calls to serve other classes.
• Graphically, active classes are rendered with double lines to the left and right.

Component (Structural Things)

• Packaging of classes, interfaces, and collaboration.
• Divides the total program into parts or modules.

Node (Structural Things)

• Computational resources at runtime, like memory and processors.

Behavioral Things

• Verbs that represent dynamic parts of UML models, expressing behavior over time and space with two kinds of behavioral things.

Interaction (Behavioral Things)

• A set of objects exchanges messages to accomplish something specific.

State Machine (Behavioral Things)

• It specifies the sequence of states for an object or interaction, responding to events over its lifetime.

GROUPING THINGS

• Organizational parts of UML models, which can be decomposed where "packages" are the primary grouping.
• They organize structural/behavioral elements.
• Purely conceptual elements exist only in development time and can be nested.
• Variations of packages are frameworks, models and subsystems.

ANNOTATIONAL THINGS

• Annotational things are explanatory parts of UML models.
• Comments applied to describe, illuminate, and remark about an element.
• There is one primary annotational thing, called a note.

RELATIONSHIPS in UML

• The four kinds of relationships in UML are association, generalization, realization and dependency.

Association (Relationships in UML)

• It describes a structural relationship with a set of links to connect objects.

Generalization (Relationships in UML)

• A relationship which connects a specialized element with a more generalized element, describing its inheritance.

Realization (Relationships in UML)

• It denotes how a class's functionality implements an interface defined by another class.

Dependency (Relationships in UML)

• Is a relationship where change in one element also affects another.

Diagrams in UML

• A diagram is the graphical presentation of a set of elements as a connected graph of things and arcs.
• UML includes nine such diagrams.
• Structural diagrams represent static aspects.
• Behavioral diagrams represent dynamic aspects.

Class Diagram

• Illustrates classes, interfaces, and collaborations and their interrelations while addressing the static design view of a system.
• Includes active classes and addresses the static process view.

Object Diagram

• Shows a set of objects and relationships with static snapshots of class diagram instances, by addressing the static design or process view from real or prototypical cases.

Component Diagram

• Gives depiction of an encapsulated class, its interfaces, ports, and internal structure of nested components and connectors representing the static design implementation of the system.

Use Case Diagram

• Showcases a set of use cases, actors, and their relationships focused on the static use case view of a system.

Sequence Diagram and Communication Diagram

• Both are interaction diagrams. Interaction diagrams show interactions consisting of objects or roles and messages and address dynamic view of a system.
• A sequence diagram highlights time-ordering of messages.
• A communication diagram emphasizes the objects or roles that send and receive messages.

State Diagram

• Displays a state machine with states, transitions, events, and shows an object's dynamic view.

Activity Diagram

• Illustrates processes or computations as control and data flow, by the function as they emphasize the flow of control among objects, to address the dynamic view of a system.

Deployment Diagram

• Depicts run-time processing nodes and components, which addresses the static deployment view of system architecture (networking).
• Nodes typically host artifacts.

Artifact Diagram

• It shows system physical components that includes files, databases, and data organized with deployment diagrams.

Package Diagram

• This diagram shows the model being broken down, into organizational units while showing dependencies that contains a set of diagrams, and dependency grouping.

Timing Diagram

• An interaction diagram that displays actual times across different objects or roles, instead of relational sequences of messages.

Interaction Overview Diagram

• Serves as a hybrid between activity and sequence diagrams.

Architecture of OO Software System

• Understanding the architecture in object orientation requires:
  • A use of case viewing the system's requirements. -Capturing design to view the problem and solution space.
  • Moddel process to distribute the system's processes with threads. -Implementing the artifacts to assemble and release the physical system. -Deploying and viewing the engineering aspect .
• This holistic structured understanding represents the blueprints for object oriented software systems.

UML Architecture

• Software intensive visualization specifies the number of view points to construct and document.
• Key stakeholder bring end users, analysis, developers a different agenda viewing different views throughout time.
• UML static views display a use case diagram with dynamic aspects captured by interaction, state, and activity diagrams.
• Design of this displays interfaces, classes, collaborations that form the vocabulary for a solution of end users using class and object diagrams using dynamic aspects which are captured in interactions, state, and activity diagrams.
• Interactions that show the data flow control among parts with possible concurrence synchronized with the UML static data shown as active classes.
• Deployment view addresses distribution and hardware setup, with diagrams capturing a deployment.
• Implementation focuses on configuration through releasing, and assembling artifacts. Logical classes and components are captured using artifacts, interactions.

SDLC - Rational Unified Model (RUP)

• Inception, the seed idea for development, is internally sound to move into elaboration.
• Elaboration defines product requirements and architecture. Requirements are articulated and prioritized.
• Construction is where software reaches an executable form, ready for transition with evaluation criteria reexamined, resources allocated and risks addressed.
• Transition delivers software to users, which is continuously improved by removing bugs.
• Iteration constitutes distinct work tasks with an executable that yields to system evaluation and testing.