Scribd
Upload
18 views7 pages

SE4 (Very Short Summary)

The document discusses key concepts in software engineering, including modeling, object-oriented design, requirements, and UML diagrams. It outlines various types of models, the process of object-oriented analysis and design, and the distinction between functional and non-functional requirements. Additionally, it details different UML diagrams, their purposes, and examples of how they can be applied in software development.

Uploaded by

piyushraj102000
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views7 pages

SE4 (Very Short Summary)

The document discusses key concepts in software engineering, including modeling, object-oriented design, requirements, and UML diagrams. It outlines various types of models, the process of object-oriented analysis and design, and the distinction between functional and non-functional requirements. Additionally, it details different UML diagrams, their purposes, and examples of how they can be applied in software development.

Uploaded by

piyushraj102000
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 7

1.

Modeling in Software Engineering

●​ A model is an abstraction that removes unnecessary details to focus on essential


aspects.
●​ Different types of models include:
○​ System Model – Represents specific aspects of a software system.
○​ Process Model – Defines workflows and development processes.
○​ Mathematical Model – Uses mathematical representations.
○​ Platform Model – Details system compatibility with platforms.
○​ Meta Model – Represents rules for defining other models.

2. Object-Oriented Design (OO Design)

●​ Object-Oriented Analysis (OOA)


○​ Focuses on objects that interact in a system (e.g., employees, bank accounts,
video files).
○​ Steps include:
■​ Identifying objects.
■​ Organizing objects.
■​ Defining object interactions.
■​ Specifying object operations.
●​ Object-Oriented Design (OOD)
○​ Converts OOA models into detailed implementations.
○​ Involves:
■​ Data structuring.
■​ Implementing methods and control structures.
■​ Defining relationships between objects.
●​ Object-Oriented Analysis and Design (OOAD)
○​ Uses OOA and OOD together to build software iteratively and incrementally.

3. Requirements in Software Engineering

●​ Functional Requirements
○​ Define what a system should do.
○​ Example: "Send an email when a customer signs up."
●​ Non-Functional Requirements
○​ Define how the system should perform.
○​ Example: "The system must handle 10,000 transactions per second."
4. Unified Modeling Language (UML)

●​ Definition
○​ UML is a standardized language used to model software solutions, system
behaviors, and business processes.
●​ Categories of UML Diagrams
○​ Structural Diagrams – Represent system structure (e.g., classes, components).
○​ Behavioral Diagrams – Show system behavior (e.g., interactions, workflows).

5. UML Interaction Diagrams

●​ Used to model object interactions within a system.


●​ Types include:
○​ Sequence Diagram – Shows object interactions over time.
○​ Collaboration Diagram – Displays relationships among objects.
○​ Timing Diagram – Focuses on object states over time.

6. UML Structural Diagrams

●​ Used to model system architecture and relationships.


●​ Key diagrams:
○​ Class Diagram – Defines system classes, attributes, and relationships.
○​ Component Diagram – Shows software components and dependencies.
○​ Deployment Diagram – Represents system hardware and software mapping.

7. Class Diagram Details

●​ Structure of a Class
○​ Name (Top)
○​ Attributes (Middle)
○​ Methods (Bottom)
●​ Relationships in Class Diagrams
○​ Association – A basic relationship between two classes.
○​ Aggregation – A "has-a" relationship where the child object can exist
independently.
○​ Composition – A "strong has-a" relationship where the child cannot exist
independently.
●​ Visibility Modifiers
○​ + (Public) – Accessible by all.
○​ # (Protected) – Accessible within the class and derived classes.
○​ - (Private) – Accessible only within the class.

1. Object Diagram
●​ Represents a snapshot of instances of classes at a given time.
●​ Shows real-world examples of objects and their relationships.
●​ Key Elements:
○​ Objects (Instances of classes)
○​ Attributes (With values)
○​ Links (Relationships between objects)

Example:​
If a Class Diagram has a Car class, an Object Diagram could show an instance of a car:

makefile
Copy code
Car1: Car
Color = Red
Brand = Toyota

2. Class vs. Object

3. Package Diagram
●​ Used to organize large systems into smaller, manageable parts.
●​ Groups related classes, interfaces, and components.
●​ Helps in modularization of the system.

Example:​
A Bank System can have different packages:

●​ AccountManagement
●​ TransactionProcessing
●​ CustomerSupport

Each package contains related classes.

4. Component Diagram
●​ Represents physical components in a system.
●​ Shows how software components interact via interfaces.
●​ Used for high-level system design.

Example:​
In a web application, components could be:

●​ Frontend (HTML, CSS, JS)


●​ Backend (Django, Node.js)
●​ Database (MySQL, PostgreSQL)

Arrows show dependencies between these components.

5. Deployment Diagram
●​ Represents hardware and software deployment in a system.
●​ Shows physical architecture, including servers, devices, and databases.
●​ Nodes (hardware) and artifacts (deployed software components) are connected.

Example:

●​ Client Node → Mobile App


●​ Server Node → API Service
●​ Database Node → SQL Database
This diagram helps in understanding system infrastructure.

6. Profile Diagram
●​ Used for customizing UML for a specific domain.
●​ Defines stereotypes, tagged values, and constraints.
●​ Helps in extending UML for specialized applications.

Example:

●​ In software development, a profile diagram might define <<webService>> for services


used in a web application.

7. Composite Structure Diagram


●​ Shows internal structure of a class or object.
●​ Represents relationships between different parts of an object.
●​ Helps in understanding how objects collaborate.

Example:​
A Car object contains:

●​ Engine
●​ Wheels
●​ Seats

This diagram represents the composition of the object.

8. Behavioral Diagrams
●​ Focus on system behavior and interactions.
●​ Includes Use Case, Activity, State Machine, and Interaction Diagrams.

8.1 Use Case Diagram

●​ Represents user interactions with a system.


●​ Shows actors (users) and use cases (functionalities).
Example:​
For an E-commerce System:

●​ Actors: Customer, Admin


●​ Use Cases: Add to Cart, Checkout, Payment

8.2 Activity Diagram

●​ Represents workflow or process flow.


●​ Uses actions, decisions, and transitions.

Example:​
Online Order Process:

1.​ Select Product


2.​ Add to Cart
3.​ Make Payment
4.​ Receive Order Confirmation

8.3 State Machine Diagram

●​ Represents states of an object and transitions between states.


●​ Shows life cycle of an object.

Example:​
For an ATM Machine:

1.​ Idle → User Inserts Card


2.​ Verifying Card → User Enters PIN
3.​ Transaction Processing → User Withdraws Cash
4.​ Eject Card → Back to Idle

8.4 Interaction Diagram

●​ Represents interactions between objects.


●​ Includes Sequence and Communication Diagrams.
9. Sequence Diagram
●​ Represents message flow over time between objects.
●​ Uses lifelines, messages, and activation bars.

Example:​
For a Login Process:

1.​ User → System: Enter Credentials


2.​ System → Database: Validate User
3.​ Database → System: Response
4.​ System → User: Access Granted

10. Communication Diagram


●​ Focuses on message passing between objects.
●​ Shows objects and their interactions.
●​ Similar to Sequence Diagram but emphasizes object roles.

Example:​
For an Online Order System:

●​ Customer → Cart → Payment Gateway → Order Confirmation

11. Generalization vs. Specialization


●​ Generalization → Top-down approach
○​ Extract common attributes/methods into a parent class.
○​ Example: Vehicle is a general class for Car and Bike.
●​ Specialization → Bottom-up approach
○​ Create subclasses with more specific attributes.
○​ Example: SavingsAccount and CurrentAccount inherit from
BankAccount.

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy