Software Engineering Principles and UML Modeling

What is Software Engineering?

Software Engineering is the application of engineering principles, methods, and tools to the design, development, testing, deployment, operation, and maintenance of software systems in a systematic, disciplined, and measurable way.

Software Process Flows

A software process defines the approach used to develop a system. Common process flows include:

• Linear/Sequential: Activities are performed one after another in a fixed order. Each phase must be completed before the next begins.
• Iterative: The development process is repeated in cycles. Each iteration improves the software based on feedback.
• Evolutionary: The system is developed in versions or increments, where each version adds new features and improves the previous one.
• Parallel Flows: Different parts of the system are developed at the same time by different teams to speed up development.

Requirements Engineering Steps

The main steps of Requirements Engineering include:

• Inception: Establishing a basic understanding of the problem, the stakeholders, the nature of the solution, and the effectiveness of communication.
• Elaboration: Creating an analysis model that identifies data, function, and behavioral requirements.
• Negotiation: Agreeing on a deliverable system that is realistic for both developers and customers.
• Elicitation: Gathering requirements from stakeholders through meetings with established rules, agendas, and facilitators.
• Requirements Analysis: Understanding and refining user needs.
• Requirements Specification/Documentation: Writing needs clearly and formally.
• Requirements Validation: Checking that requirements are correct, complete, and meet user needs.
• Requirements Management: Controlling and updating requirements when changes occur.

Requirements Validation

Requirements validation is the process of checking whether the documented requirements are correct, complete, consistent, realistic, testable, and aligned with stakeholder needs.

UML Diagrams

UML diagrams are categorized into two main types:

Structural (Static) Diagrams

These model the structure of the system, showing classes, objects, components, and relationships. Examples include Class, Object, Component, Deployment, and Package diagrams.

Behavioral (Dynamic) Diagrams

These model the behavior of the system over time, showing interactions, workflows, and state changes. Examples include Use Case, Sequence, Activity, and State Machine diagrams.

Use Cases and Actors

A user scenario is a narrative description of how a user interacts with a system in a real situation. A use case is a structured description of interactions between an actor and the system to achieve a goal.

An actor is an external entity that interacts with the system (e.g., a person, another system, or an organization).

• Primary Actor: Initiates a use case to achieve a goal.
• Secondary Actor: Supports the system or use case.
• Concrete Actor: A specific, real actor.
• Abstract Actor: A generalized actor used for grouping or inheritance.

UML Notation and Relationships

• Include: Represents mandatory reused behavior shared by multiple use cases.
• Extend: Represents optional or conditional behavior added to a base use case.
• Inherit: One actor or use case inherits behavior from another.
• Association: A relationship between classes.
• Aggregation: A weak whole-part relationship.
• Multiplicity: Shows how many instances participate in a relationship (e.g., 1, 0..1, 1..*, *).

BPMN Overview

BPMN (Business Process Model and Notation) is used to model business processes and workflows, including tasks, events, gateways, participants, and message flows. It is used to document, analyze, and improve process efficiency.

Interface Design Rules

• Consistency: Same layout, colors, and actions across the system.
• Feedback: The system should respond clearly to user actions.
• Simplicity (Clarity): Keep the interface intuitive and uncluttered.

Requirements Categories

Non-Functional Requirements (NFRs)

These define how the system works rather than what it does. Categories include Performance, Usability, Reliability, Security, and Scalability.

Functional Requirements (FRs)

These describe what the system does (functions and actions). Examples include user account creation, login/logout, database storage, product search, and report generation.

SOLID Principles

1. S – Single Responsibility: One class, one job.
2. O – Open/Closed: Open for extension, closed for modification.
3. L – Liskov Substitution: Subclasses must work like the parent class.
4. I – Interface Segregation: Small, specific interfaces.
5. D – Dependency Inversion: Depend on abstractions, not concrete classes.