The Islamia University of

Bahawalpur
Faculty of Engineering & Technology
Department of Computer Systems Engineering
Name: Swaira Riaz Roll_No. 22-CSE-18
Session: 2022-26 (6th Semester) Max. Marks: 10
Course: COMP 02632 (Software Engineering) Instructor: Engr. Sajida Hassan
Assignment: 2 (CLO2)

Q#01 Design and implement the state diagram for the weather station system that
shows how it responds to requests for various services?

Answer:

Title: State Diagram for Weather Station System

Explanation:

This state diagram represents the behavior of a Weather Station System in response
to requests for various services such as data collection, transmission, error handling,
and shutdown.

States:

 PowerOff: The initial state when the system is not active.

 Idle: The system is powered on and waiting for data requests.
 Collecting Data: The station is actively collecting weather data from sensors.
 Transmitting Data: Collected data is being sent to a remote server or display
unit.
 Error: An error occurred (e.g., sensor failure or transmission error).

Transitions:

 start(): Moves system from PowerOff to Idle.

 requestData(): Initiates data collection from the Idle state.
 dataCollected(): On successful data collection, moves to Transmitting Data.
 transmitSuccess(): On successful transmission, returns to Idle.
 sensorFail(): If data collection fails, moves to Error.
 reset(): Recovers from error and returns to Idle.
 shutDown(): Transitions the system to the final state (end of operation).

Implementation Tool:

This diagram was implemented using UML Designer, which supports the creation of
state machine diagrams according to UML standards.
Diagram:

Q#02 Using the UML graphical notation for object classes, design the following
object classes, identifying attributes and operations. Use your own experience to
decide on the attributes and operations that should be associated with these objects.
(i) a telephone
(ii) a printer for a personal computer
(iii) a personal stereo system

Answer:
Design UML class diagrams for the following objects, identifying appropriate
attributes and operations.

1. Telephone

Attributes:

 brand: String
 model: String
 phoneNumber: String
 isRinging: Boolean

Operations:

 makeCall(number: String)
  receiveCall()
 endCall()
 checkStatus()

2. Printer (Personal Computer)

Attributes:

 brand: String
 model: String
 status: String
 paperLevel: Integer
 inkLevel: Integer

Operations:

 printDocument(file: String)
 checkStatus()
 refillPaper()
 replaceInk()

3. Personal Stereo System

Attributes:

 brand: String
 model: String
 batteryLevel: Integer
 currentTrack: String
 volumeLevel: Integer

Operations:

 play()
 pause()
 stop()
 nextTrack()
 increaseVolume()
 decreaseVolume()
Diagram:

Q#03 Design a sequence diagram showing the interactions of objects in a group

diary
system when a group of people are arranging a meeting.

Answer:

Sequence Diagram Analysis: Group Diary Meeting Arrangement

1. Diagram Overview

The sequence diagram models the interaction between system components during
meeting scheduling in a Group Diary System. Key elements include:
 Six lifelines: User, GroupDiarySystem, CalendarManager, two Participants,
and NotificationService
 12 message exchanges with synchronous and asynchronous communication
 Activation bars showing processing periods

2. Core Workflow

The system executes these key operations:

1. Meeting initiation (User → GroupDiarySystem)
2. Availability validation (GroupDiarySystem ↔ CalendarManager)
3. Participant coordination (GroupDiarySystem ↔ Participants)
4. Final confirmation and notification (GroupDiarySystem →
NotificationService → All parties)

3. Design Highlights
  Clear separation of concerns between components
 Optimal use of asynchronous messaging for notifications
 Synchronous operations for critical path activities
 Linear workflow with well-defined decision points

4. Technical Merits

The design demonstrates:

 Effective object collaboration
 Appropriate messaging patterns
 Modular architecture
 Efficient notification handling

Diagram:

Q#04 Develop a UML state diagram showing the possible state changes in either the
group diary or the filling station system.

Answer:

State Diagram Analysis: Group Diary System

1. Diagram Overview
The state diagram (Fig. 1) models the meeting scheduling lifecycle in a Group Diary
System, comprising:
 8 states (Idle → NotificationSent)
 12 transitions with triggers/guards
 3 critical paths: Success flow, cancellation, timeout
2. Core State Logic
 Success Path:
Idle → MeetingInitiated → TimeProposed → CheckingAvailability →
AwaitingResponses → TimeConfirmed → NotificationSent
 Error Handling:
o Timeout: AwaitingResponses → Cancelled
o Manual cancellation: Any state → Cancelled

3. Key Design Choices

1. Self-Transition: retryProposeTimes() in TimeProposed enables renegotiation
2. Guarded Transitions: [slots available?] ensures valid state progression
3. Termination: Explicit Cancelled state releases resources

4. Technical Validation
 Consistency: Single start (Idle) and end (NotificationSent/Final) points
 Completeness: Covers 100% of use cases (success/failure/timeout)
 Scalability: Modular design allows adding states (e.g., RecurringMeeting)

Diagram:
Q#05 Identify possible objects in the following system and develop an object-
oriented design for the given system. You may make any reasonable assumptions
about the systems when deriving the design.

A filling station (gas station) is to be set up for fully automated operation. Drivers
swipe their credit card through a reader connected to the pump; the card is verified by
communication with a credit company computer, and a fuel limit is established. The
driver may then take the fuel required. When fuel delivery is complete and the pump
hose is returned to its holster, the driver’s credit card account is debited with the cost
of the fuel taken. The credit card is returned after debiting. If the card is invalid, the
pump returns it before fuel is dispensed.

Automated Gas Station System: OO Design Analysis

1. Core Design Components
Key Elements:
 7 classes with minimal, focused responsibilities
 Precise relationships:
o Composition: GasPump owns hardware components (◉━)
o Association: PaymentProcessor → Bank (━━>)
o Dependency: GasPump temporarily uses Card (⤳)
2. Critical Design Decisions
1. Security:
o Card data encapsulated in CreditCardReader
o No direct GasPump–Bank link (reduces attack surface)
2. Reliability:
o Physical containment (composition) ensures hardware integrity
o Nozzle state machine prevents fuel leaks

3. OO Principles Applied

Principle Implementation Example

Single Responsibility FuelDispenser handles only fuel delivery

Low Coupling Bank interacts solely via PaymentProcessor

Encapsulation Card details never exposed to GasPump

Diagram: