Professional Documents
Culture Documents
Oose Internal
Oose Internal
A system consists of several elements that work together to achieve a common objective. These
elements include:
1. Inputs: These are the resources or data that a system takes in from its environment.
2. Processes: This involves the activities, operations, or transformations that the system performs
on the inputs.
3. Outputs: These are the results or products that the system produces and delivers to its
environment.
4. Feedback: Information about the system's outputs that is used to make adjustments or
improvements.
5. Control: Mechanisms that ensure the system operates within specified parameters or
constraints.
6. Environment: The external factors, conditions, and entities that interact with the system.
7. Boundaries: The demarcation that separates the system from its environment, defining what is
inside and outside.
8. Interfaces: Points where the system interacts with its environment, allowing inputs and outputs
to flow.
The IEEE (Institute of Electrical and Electronics Engineers) standard format for a Software
Requirements Specification (SRS) document typically includes the following sections:
1 Introduction: Provides an overview of the document, its purpose, scope, and any references.
2. Overall Description: Offers a high-level description of the software, including its functions,
constraints, and assumptions.
3. Specific Requirements: Details the functional and non-functional requirements of the software,
specifying what it should do and any performance criteria.
4. External Interface Requirements: Describes the interfaces with external systems, including
hardware, software, and human interfaces.
5. System Features: Presents a detailed breakdown of the functionalities, often in the form of use
cases or user stories.
1 Use Case Diagrams: Depict the interaction between the system and its external actors.
2. Class Diagrams: llustrate the classes and their relationships in a system.
3. Sequence Diagrams: Show the interactions among objects in a specific scenario.
4. Activity Diagrams: Represent the flow of activities in a system.
5. State Diagrams: Depict the different states that an object or system can be in, and how it
transitions between them.
6. Component Diagrams: Display the high-level components of a system and their interactions.
7. Deployment Diagrams: Show the physical arrangement of hardware and software elements in a
system.
8. Object Diagrams: Provide a snapshot of the objects in a system at a specific point in time.
1 Encapsulation: Bundling data (attributes) and methods (functions) together within an object,
hiding the internal workings from external entities.
2. Inheritance: Allowing one class (subclass) to inherit the properties and behaviors of another
class (superclass), promoting code reusability.
3. Polymorphism: Providing the ability for a method to take on multiple forms, allowing objects of
different types to be used interchangeably.
4. Abstraction: Focusing on the essential characteristics of an object, while ignoring the irrelevant
details.
5. Association: Representing relationships between objects, indicating how they interact with
each other.
1 Association: Represents a bi-directional relationship between two classes, indicating that one
class is related to another. It's a generic relationship.
2. Dependency: Signifies that one class relies on another, but without a strong, persistent
relationship. For example, using an object of one class as a parameter in a method of another
class.
3. Aggregation: Describes a whole-part relationship where one class (the whole) is composed of
multiple instances of another class (the part). The parts can exist independently.
4. Composition: Similar to aggregation, but in this case, the parts cannot exist independently of
the whole. It's a stronger form of aggregation.
5. Inheritance (Generalization): Indicates that one class (subclass) inherits attributes and
behaviors from another class (superclass). It's a "is-a" relationship.
6. Realization (Interface): Shows that a class implements an interface, which means it provides
specific behaviors defined by the interface.
Q: Explain the Phases of UP/RUP.
Unified Process (UP) or Rational Unified Process (RUP) is an iterative software development
process framework. It consists of four main phases:
1 Inception: Focuses on understanding the project scope, feasibility, and initial requirements. It
establishes the business case and defines the system at a high level.
2. Elaboration: Further refines the requirements, architecture, and design. It addresses risks and
uncertainties and producesa stable architecture baseline.
3. Construction: Involves actual development, where the bulk of coding, testing, and
implementation occur. It results in a product that's ready for deployment.
4. Transition: Prepares the product for deployment, including user training, system testing, and
final adjustments. It culminates in the product's release.
Each of these phases is characterized by specific goals, activities, and deliverables, and they are
often repeated in multiple iterations to incrementally build the software.
Activity diagram for online shopping
system
The activity diagram used to describe flow of
activity through a series of actions. Activity
diagram is a important diagram to describe the
system.
The activity described as a action or operation of
the system.
Login
Authentication
Invalid
Check
Valid
Confirm Order
Logout
Activity Diagram for Admin Side
Login
Authentication
Invalid
Check
Valid
Edit Item
Logout
Use Case Diagram - Online Shopping
Website.
The use case diagram are usually referred to as
behavior diagram used to describe the actions of
all user in a system.
All user describe in use case are actors and the
functionality as action of system.
Login
DD
ADMIN
ADD Category
ADD Item
Manage Item
Manage Order
USER
Registration
View tem
Make Order
Make Payment
Change Password
Library Management System
Userlype
Username
Password
Login ()
Register ()
Logout()