BSc CSIT (TU) Science Software Engineering (BSc CSIT, CSC364) Question Paper 2081 Nepal

UML Models for an Online Movie Ticketing System

1. Use Case Diagram

Actors: Customer, Admin, Payment Gateway (external system).

Use cases (Customer): Register / Login, Search Movie, Select Show & Seats, Book Ticket, Make Payment, Cancel Booking, View Booking History.

Use cases (Admin): Manage Movies, Manage Shows/Screens, View Reports.

Relationships:

• Book Ticket includes Select Show & Seats and includes Make Payment.
• Make Payment is associated with the external Payment Gateway actor.
• Cancel Booking extends View Booking History.

            ( Search Movie )
           /
Customer --( Select Show & Seats )
           \                       <<include>>
            ( Book Ticket )----------------------> ( Make Payment ) ----> Payment Gateway
           /                                              ^
            ( Cancel Booking )                             <<include>>

Admin ----( Manage Movies ) ( Manage Shows ) ( View Reports )

2. Class Diagram

Associations / multiplicities:

• Customer 1 — * Booking
• Movie 1 — * Show
• Show 1 — * Seat
• Booking * — * Seat, and Booking 1 — 1 Payment.

Customer 1 ──< Booking >── 1 Payment
                 *│
                  └──< Seat >── Show ──< Movie

3. Sequence Diagram — "Book Ticket"

Lifelines: Customer, :UI, :BookingController, :Show, :Payment, :PaymentGateway.

Customer -> UI            : selectShow(showId)
UI       -> BookingController : getAvailableSeats(showId)
BookingController -> Show  : getAvailableSeats()
Show --> BookingController : seatList
BookingController --> UI   : show seats
Customer -> UI            : selectSeats(seats)
UI -> BookingController   : createBooking(seats)
BookingController -> Payment : process(amount)
Payment -> PaymentGateway : charge(card, amount)
PaymentGateway --> Payment : success
Payment --> BookingController : paid
BookingController --> UI   : bookingConfirmed(ticket)
UI --> Customer          : show e-ticket

The sequence shows the time-ordered message flow: seat selection → booking creation → payment processing via the gateway → confirmation returned to the customer.

Configuration Management (CM)

Software Configuration Management is the set of activities concerned with managing change in a software product. It controls the evolution of all artifacts (code, documents, designs, test cases) so that the system can be reliably built, and changes are tracked, coordinated and reversible. It is essential when many developers work on a system over a long period, because uncontrolled change leads to confusion and defects.

The key items placed under control are called configuration items (CIs), and a consistent set of CIs forms a baseline.

1. Version Management

Version management keeps track of the different versions of software components and ensures changes made by different developers do not interfere with one another.

• A version control system (VCS) such as Git, SVN or Mercurial stores every revision in a repository.
• Developers check out a copy, modify it, and check in (commit) changes; the system records who changed what and when.
• Supports branching (parallel lines of development) and merging, and resolves conflicts when two people edit the same file.
• Enables roll-back to any previous version.

2. System Building

System building is the process of assembling program components, data and libraries, and compiling/linking them to create an executable system.

• A build tool (Make, Maven, Gradle, Ant) automates compilation, linking and packaging.
• It manages dependencies and ensures the build is reproducible from a given baseline.
• Continuous Integration (CI) servers (e.g., Jenkins) automatically rebuild and run tests whenever code is committed, detecting integration errors early.

3. Change Management

Change management is the procedure for proposing, evaluating, approving and tracking changes to a baselined system.

1. A Change Request (CR) is submitted.
2. The Change Control Board (CCB) assesses cost, impact and benefit.
3. The change is approved or rejected; if approved, it is scheduled and implemented.
4. The change is verified, tested and a new baseline is created; the CR is closed.

Together these three processes keep a large, evolving software product consistent, traceable and controllable.

Software Process Model

A software process model is an abstract, simplified representation of a software process. It describes the order in which the activities of software development are carried out and the artifacts produced. It is a framework that prescribes how software is built, viewed from a particular perspective (e.g., Waterfall, Incremental, Spiral, Agile). It helps teams plan, manage and standardize development.

Fundamental Software Process Activities

Every software process, regardless of the model, includes four fundamental activities:

1. Software Specification (Requirements Engineering)

Defining what the system should do and the constraints on its operation. Sub-activities: feasibility study, requirements elicitation & analysis, specification, and validation. Example: For a banking app, eliciting that customers must be able to transfer funds and that a transfer must complete within 5 seconds.

2. Software Design and Implementation

Converting the specification into an executable system. The design establishes the architecture, components, interfaces and data structures; implementation translates this into program code. Example: Designing a layered architecture (UI, business, database) and coding the funds-transfer module in Java.

3. Software Validation (Verification and Validation)

Checking that the system conforms to its specification and meets customer needs. This is mainly testing — unit, integration, system and acceptance testing. Example: Running test cases to confirm a transfer correctly debits one account and credits another, and rejecting invalid amounts.

4. Software Evolution (Maintenance)

Modifying the software to meet changing customer and market requirements over its lifetime. Example: Updating the banking app to support a new tax rule or a mobile payment method.

These activities are organized differently by different process models — sequentially in the Waterfall model, iteratively in incremental/agile models — but all four must be performed to deliver and sustain working software.

Software Engineering vs System Engineering

Summary: Software engineering deals with producing the software, whereas system engineering deals with developing the complete computer-based system in which the software is just one component. Software engineering is therefore a part of system engineering.

Risk Management in Software Development

Risk management is the process of identifying potential problems that could threaten a project and taking action to minimize their impact. It is carried out iteratively throughout the project through four key activities:

1. Risk Identification — Listing possible project, product and business risks. Common types: project risks (staff turnover, budget cuts), technical/product risks (changing requirements, technology immaturity), and business risks (competing product, organizational change).

2. Risk Analysis — Assessing each risk's probability (low/moderate/high) and impact/seriousness (insignificant to catastrophic). Risks are prioritized, e.g., via a risk exposure value (probability × impact).

3. Risk Planning — Devising strategies to deal with significant risks:

   • Avoidance — reduce the probability (e.g., reorganize work to reduce staff dependency).
   • Minimization — reduce the impact (e.g., cross-train staff).
   • Contingency — prepare a fallback plan if the risk occurs.

4. Risk Monitoring — Regularly checking whether risks are becoming more or less likely and whether effects are visible, then revising plans accordingly.

The results are recorded in a risk register and reviewed at each project milestone, making risk management a continuous loop throughout development.

Importance of Software Maintenance

Software maintenance is the process of modifying a software product after delivery to correct faults, improve performance, or adapt it to a changed environment. It is one of the most important activities because:

• Software operates in a changing environment — business rules, laws, hardware and user needs evolve, so software must evolve too (Lehman's law of continuing change).
• Most of the total cost of a software system over its lifetime (often 60–80%) is spent on maintenance, not initial development.
• A failure to maintain software leads to software ageing, degradation and eventual obsolescence.

Types of Maintenance

• Corrective — fixing discovered defects.
• Adaptive — adjusting to a new environment.
• Perfective — adding/improving functionality.
• Preventive — restructuring code to prevent future problems.

Example

Consider a payroll system developed in 2080. When the government revises income-tax slabs in the next fiscal year, the software will compute wrong deductions unless updated. Adaptive/corrective maintenance is performed to update the tax-calculation module so the system continues to produce correct payslips. Without this maintenance the otherwise-working system becomes useless, which justifies why maintenance is a critical, ongoing activity.

Functional vs Non-Functional Requirements

Functional requirements describe what the system should do — the specific services, behaviors and functions it must provide, and how it reacts to particular inputs.

Non-functional requirements describe how well the system performs — constraints and quality attributes on the services, often applying to the system as a whole rather than individual functions.

Examples (an online banking system)

Functional:

• The system shall allow a user to transfer money between accounts.
• The system shall generate a transaction statement on request.

Non-Functional:

• The system shall respond to a transfer request within 2 seconds (performance).
• The system shall be available 99.9% of the time (reliability/availability).
• All passwords shall be stored encrypted (security).

The Prototyping Model

A prototype is an initial, working version of a system built quickly to demonstrate concepts and try out design options. In the prototyping model, a prototype is developed early, shown to users, and refined based on their feedback before (or while) building the final system.

How it Helps Software Development

1. Clarifies requirements — Users often cannot state requirements precisely; seeing a working prototype helps them discover and refine what they really need, reducing requirements errors.
2. Improves communication — Acts as a common reference between users and developers, bridging the gap between vague descriptions and actual behavior.
3. Reduces risk — Technical feasibility and design alternatives can be tested early, exposing problems before heavy investment.
4. Early validation — Users validate the look, feel and functionality early, increasing the chance the final product meets expectations.
5. Better UI design — Especially useful for interface-heavy systems where layout and usability are hard to specify on paper.

Process

Quick plan -> Build prototype -> User evaluation -> Refine
      ^___________________________________________|   (iterate)

The cycle repeats until the prototype is acceptable, after which the real system is engineered (or the prototype is evolved into it).

Limitation: Hastily built prototypes may have poor structure if turned directly into the product, and users may mistake a prototype for the finished system.

Evolutionary vs Throw-away Prototyping

Both approaches use prototypes, but with opposite purposes:

Summary: In evolutionary prototyping the prototype is the seed of the delivered system; in throw-away prototyping it is only a learning tool used to nail down requirements and is then discarded before real development begins.

Behavioural Model

A behavioural model describes the dynamic behaviour of a system — how it responds and behaves while it is executing, i.e., what happens in reaction to events or as data is processed. It shows the system from the perspective of actions and reactions over time, in contrast to structural models that show static organization.

There are two main kinds:

1. Data-Driven Modelling

Shows how data moves through and is transformed by a sequence of processing steps as input is converted to output. Represented using Data Flow Diagrams (DFDs). Example: In an order-processing system, Order flows in → Validate Order → Check Stock → Generate Invoice → Invoice flows out.

2. Event-Driven Modelling

Shows how the system responds to external/internal events and changes state. Represented using State (Statechart) Diagrams.

Example: A microwave oven:

[Idle] --press 'start'--> [Cooking] --time-out / open-door--> [Idle]
   ^                          |
   |---press 'stop'-----------|

The oven transitions between Idle, Cooking and Waiting states in response to events such as button presses, timer expiry, or opening the door.

Behavioural models are valuable for capturing system reactions, designing control logic, and validating that the system behaves correctly under all sequences of events.

The Spiral Model

Proposed by Barry Boehm (1988), the spiral model is a risk-driven, iterative software process model. The process is represented as a spiral rather than a sequence of activities; each loop of the spiral represents one phase, and the radius of the spiral represents accumulated cost. Its defining feature is explicit risk analysis in every cycle.

Four Quadrants (each loop passes through all four)

1. Objective Setting — Identify objectives, constraints and alternatives for this phase; produce a plan.
2. Risk Assessment and Reduction — Identify and analyze risks; build prototypes or do studies to reduce key risks.
3. Development and Validation — Choose a development model appropriate to the dominant risk and develop & test the product for this phase.
4. Planning (Review) — Review the results with stakeholders and decide whether to continue with the next loop; plan the next phase.

         Objective Setting | Risk Assessment & Reduction
         ------------------+----------------------------
         Review / Plan     | Development & Validation

Advantages

• Strong, early and explicit risk management.
• Suited to large, complex, high-risk projects.
• Combines features of prototyping and waterfall; allows incremental release.

Disadvantages

• Complex to manage; requires risk-assessment expertise.
• Can be costly and is unsuitable for small/low-risk projects.

The spiral model is best where requirements are unclear and risks are high, because each cycle resolves the highest-priority risks before proceeding.

Key Principles of Agile Methods

Agile methods focus on rapid, incremental delivery of working software with close customer involvement, guided by the Agile Manifesto. The key principles are:

1. Customer Involvement — Customers are closely engaged throughout development to provide requirements, set priorities, and evaluate iterations.

2. Incremental Delivery — Software is developed and delivered in small increments; the customer specifies the requirements to be included in each increment.

3. People, Not Process — The skills and knowledge of the development team are recognized and exploited; team members work in their own ways without prescriptive processes.

4. Embrace Change — Requirements are expected to change, so the system is designed to accommodate changes rather than resisting them.

5. Maintain Simplicity — Focus on simplicity in both the software being developed and the development process; actively work to eliminate complexity.

These principles together value individuals and interactions over processes, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.