UML Modeling and Software Engineering Fundamentals

Posted on May 14, 2026 in Software Engineering

Risk Management in Project Management

Project risk management is the process that project managers use to manage potential risks that may affect a project in ways both positive and negative.

The goal is to minimize the impact of these risks.
Risk management is applicable to large and small projects in different ways.
Negative risk is the type which may damage a project.

Key Modeling Concepts

Link: A link is an instance-level connection between two objects in an object diagram, representing an association between object instances.
State: A state represents the condition or situation of an object at a specific time during its lifecycle.
Branching: Branching is a decision point in an activity diagram where one flow splits into multiple alternative paths based on conditions.

UML Definition and Goals

UML stands for Unified Modeling Language. UML is a standard graphical language for modeling object-oriented systems. It is a language for visualizing, specifying, constructing, and documenting software artifacts.

The Goals of UML

Standardized software design notation.
Visualize system architecture.
Specify functionality and behavior.
Guide system construction.
Support different development methodologies.
Improve communication among stakeholders.
Document the system.

UML Architecture and the Five Views

The architecture of UML is based on five different views:

Use Case View: Represents functional requirements and shows interactions between users (actors) and the system.
Design View: Describes classes, interfaces, and collaborations while supporting functional requirements.
Process View: Shows concurrent processes and threads; it is related to system performance and scalability.
Implementation View: Describes the components and files used to build the system.
Deployment View: Shows the physical deployment of components on hardware.

UML Packages: Import and Export Stereotypes

A package is a general-purpose mechanism for organizing modeling elements into groups, such as Use Cases, Actors, Classes, and Components. A package may contain other packages, providing a hierarchical organization. Graphically, a package is shown as a tabbed folder.

Importing: This grants one-way permission for the elements in one package to access the elements in another package. In UML, an import relationship is a dependency shown with the <<import>> stereotype. It is a one-way, non-transitive process. A package import is shown using a dashed arrow with an open arrowhead from the importing namespace to the imported package.
Exporting: The public parts of a package are called its Exports. The parts that one package exports are visible only to the contents of those packages that import that specific package.

Understanding Associations in UML

An association is a structural relationship that specifies that objects of one thing are connected to objects of another. It is a set of links that connects elements of a UML model and describes how many objects take part in that relationship.

Name: An association can have a name used to describe the nature of the relationship, which helps in clear understanding. A direction triangle is used along with the name to point in the direction the name is intended to be read.
Role: Since an association relationship is between classes, a role name is the name written at one end of an association to define its context.

Classifiers in Object-Oriented Modeling

A classifier is a mechanism that has structural features (in the form of attributes) as well as behavioral features (in the form of operations). Classifiers include classes, data types, signals, components, nodes, use cases, and subsystems.

Different Types of Classifiers

Class: A description of objects that share the same attributes, operations, relationships, and semantics.
Interface: A collection of operations used to specify a service of a class or a component.
Data Type: A type whose values have no identity, including basic built-in types and enumeration types (e.g., Boolean).
Signal: The specification of an asynchronous stimulus communicated between instances.
Component: A physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces.

Software Requirements Specification (SRS)

A Software Requirements Specification (SRS) is a document that captures a complete description of how the system is expected to perform. The SRS needs to be correct, complete, consistent, updatable, and verifiable. It is usually signed off at the end of the requirements engineering phase and acts as a contract between the customer and the developer.

Types of SRS Specifications

Functional Requirements: Statements or goals used to define system behavior. They define what a software system must or must not do, typically expressed as responses to inputs or conditions.
Non-functional Requirements: These relate to software usability and define how the system must operate or perform. A system can meet its functional requirements but fail its non-functional ones, which cover performance, usability, scalability, and security.
Domain Requirements: Requirements characteristic of a particular category or domain of projects. These can be functional or non-functional.

Iterative Development and Its Advantages

In iterative development, a process is broken into a series of steps or iterations. An iteration is the act of repeating a process with the aim of approaching a desired goal, target, or result. It is a process for arriving at a decision by repeating rounds of analysis or cycles of operations.

Advantages of Iterative Development

Better productivity: Research shows less project failure and lower defect rates compared to traditional methods.
User engagement: Early feedback and adaptations lead to a refined system that meets the real needs of stakeholders.
Methodical improvement: Learning within an iteration can be used to improve the development process itself.
Visible progress: Provides early visible results.
Managed complexity: The team avoids “analysis paralysis” and is not overwhelmed by long, complex steps.

The Jacobson Method of Object-Oriented Design

The Jacobson Method, also known as OOSE (Object-Oriented Software Engineering), was developed by Ivar Jacobson. It is based on the concept of use cases and focuses on requirements through user interactions.

Phases of the Jacobson Method

Requirements Modeling (Use Case Model): Identifies actors (users or systems) and their interactions. Each use case describes functionality from the user’s point of view.
Analysis Model: Defines objects, classes, and relationships involved in each use case.
Design Model: Converts analysis into a detailed class design and interaction diagrams.
Implementation Model: Defines how each class and interaction is implemented in code.
Testing Model: Verifies if all use cases and functions are correctly implemented.

Types, Roles, and Activity Diagram Elements

Type: A type defines a set of objects with similar structure and behavior. It describes what an object is and its capabilities. Example: Employee type → ID, name, salary, work().

Role: A role defines a specific function or responsibility that an object plays in a particular context. An object may have different roles in different situations. Example: A Person can play the roles of Student, Customer, or Employee.

Additional Activity and State Diagram Terms

Swimlane: A visual divider used in activity diagrams to group activities based on who performs them (e.g., actor, department, or system). It helps show responsibility clearly.
Forking: Used in activity or state diagrams to split one flow into multiple parallel flows, allowing several activities to occur concurrently.
Joining: The opposite of forking; it combines multiple parallel flows into a single flow after all parallel activities are completed.