1. What is System Modeling? Explain the different System Perspectives.

2. Give the context of MHC-PMS and draw the class diagram for MHC-PMS
 3. What is design pattern? Explain four elements of design pattern.
A design pattern is a way of reusing abstract knowledge about a problem and its solution.
A pattern is a description of the problem and the essence of its solution.
It should be sufficiently abstract to be reused in different settings.
Pattern descriptions usually make use of object-oriented characteristics such as inheritance
and polymorphism.

The four essential elements of design patterns were defined by the ‘Gang of Four’ in their
patterns are following:---

I. A name that is a meaningful reference to the pattern.

 II. A description of the problem area that explains when the pattern may be applied.
III. A solution description of the parts of the design solution, their relationships, and
Their responsibilities. This is not a concrete design description. It is a template for a
design solution that can be instantiated in different ways. This is often expressed
graphically and shows the relationships between the objects and object classes in
the solution.
IV. A statement of the consequences—the results and trade-offs—of applying the
pattern. This can help designers understand whether or not a pattern can be used in
a particular situation

4. Explain Interaction and Behavioral Models

Interaction models focus on how different components or objects within a software
system interact with each other and with external entities. These models help in
understanding the flow of data, control, and communication between various
system elements. Two common types of interaction models are:
a. Use Case Diagrams: Use case diagrams are part of the Unified Modeling
Language (UML) and are used to visualize the functional requirements of a
system from an end-user's perspective. They represent the various use cases
or scenarios in which a user interacts with the system. Use case diagrams
show the relationships between actors (users or external systems) and the
system itself, as well as how different use cases are interconnected.
b. Sequence Diagrams: Sequence diagrams are also part of UML and provide a
dynamic view of system behavior. They depict how objects or components
interact over time to achieve specific functionalities. Sequence diagrams show
the chronological order of messages and method calls exchanged between
objects, helping developers understand the system's runtime behavior.
 Behavioral models focus on describing how the software system
behaves in response to different stimuli or events. These models help in
capturing the internal logic and decision-making processes within the
system. Two common types of behavioral models are:

a. State Diagrams : State diagrams, often represented using UML, are used to
model the various states a system or an object can be in and how it
transitions between these states in response to events. They are particularly
useful for modeling systems with complex state-dependent behavior, such as
embedded systems or control systems.

c. Activity Diagrams: Activity diagrams, another UML diagram type, are used to
model the workflow or business processes within a system. They represent
the activities or actions that occur within the system and the relationships
 between them. Activity diagrams help in visualizing the high-level flow of
control within the software.

5. Draw a state machine model of simple microwave oven.

 6. What is Model Driven Engineering? State the three types of abstract
system modules produced.

Model-driven engineering (MDE) is a software development approach that focuses

on creating and manipulating models of software systems rather than working
directly with the code itself. MDE is based on the idea that models can be used to
represent the different aspects of a software system, such as its structure, behavior,
and requirements. These models can then be used to generate code, test cases,
documentation, and other artifacts. The goal of MDE is to improve the efficiency and
quality of software development by providing a higher-level abstraction of the
system, which can be more easily understood and managed by developers.
 7. Draw a sequence diagram describing data collection of weather
information system.

1. Define the terms- Verification and Validation.

2. State and explain Development Testing and its three levels – unit testing, component testing and system testing.

Development testing, where the system is tested during development to discover bugs and defects.
3. With the help of neat diagram explain various stages of acceptance testing process.
 There are six stages in the acceptance testing process.
 They are:

1. Define acceptance criteria: This stage should, ideally, take place early in the process before the contract for the
system is signed. The acceptance criteria should be part of the system contract and be agreed between the customer
and the developer. Detailed requirements may not be available and there may be significant requirements change
during the development process.
2. Plan acceptance testing: This involves deciding on the resources, time, and budget for acceptance testing and
establishing a testing schedule. The acceptance test plan should also discuss the required coverage of the
requirements and the order in which system features are tested. It should define risks to the testing process, such as
system crashes and inadequate performance, and discuss how these risks can be mitigated.

3. Derive acceptance tests: Once acceptance criteria have been established, tests have to be designed to check
whether or not a system is acceptable. Acceptance tests should aim to test both the functional and non-functional
characteristics (e.g., performance) of the system.

4. Run acceptance tests: The agreed acceptance tests are executed on the system. Ideally, this should take place in the
actual environment where the system will be used, but this may be disruptive and impractical. Therefore, a
user testing environment may have to be set up to run these tests. It is difficult to automate this process as part of the
acceptance tests may involve testing the interactions between end-users and the system.

5. Negotiate test results: It is very unlikely that all of the defined acceptance tests will pass and that there will be no
problems with the system. If this is the case, then acceptance testing is complete and the system can be handed over.
More commonly, some problems will be discovered. In such cases, the developer and the customer have to negotiate
to decide if the system is good enough to be put into use. They must also agree on the developer’s response to
identified problems.

6. Reject/accept system: This stage involves a meeting between the developers and the customer to decide on
whether or not the system should be accepted. If the system is not good enough for use, then further development is
required to fix the identified problems. Once complete, the acceptance testing phase is repeated.
4. Differentiate between Alpha and Beta Testing.

5. Define ‘program evolution dynamics’. Discuss Lehman’s Law for program evolution dynamics.