UML state diagrams and modeling
PART- A
1. Define post condition.
The post conditions describe changes in
the state of objects in the Domain Model. Domain Model state changes include
instances created, associations formed or broken, and attributes changed.
2.
Define Attributes.
An attribute is a logical data value of an
object.
3.
When Are Contracts Useful?
The use cases are the main repository of
requirements for the project. They may provide most or all of the detail
necessary to know what to do in the design, in which case, contracts are not
helpful. However, there are situations where the details and complexity of
required state changes are awkward to capture in use cases.
4.
Mention the Guidelines for Contracts.
To make contracts:
1. Identify
system operations from the SSDs.
2. For
system operations that are complex and perhaps subtle in their results, or
which are not clear in the use case, construct a contract.
3. To
describe the post conditions, use the following categories:
- Instance
creation and deletion
- attribute
modification
- Associations
formed and broken
5.
What are Steps for Mapping Designs to Code?
Implementation in an object-oriented
programming language requires writing source code for:
- Class
and interface definitions
- Method
definitions
6.
Creating Class Definitions from DCDs.
At the very least, DCDs depict the class
or interface name, super classes, method signatures, and simple attributes of a
class. This is sufficient to create a basic class definition in an object
oriented programming language. Later discussion will explore the addition of
interface and namespace (or package) information, among other details.
7.
What are the Benefits of Iterative Development?
-Early rather than late mitigation of
high risks (technical, requirements, objectives, usability, and so forth)
- Early
visible progress
- Early
feedback, user engagement, and adaptation, leading to a refined system that
more closely meets the real needs of the stakeholders
- managed
complexity; the team is not overwhelmed by "analysis paralysis" or
very long and complex steps
-The learning within iteration can be
methodically used to improve the development process itself, iteration by
iteration
8.
Define Events, States, and Transitions.
An event is a significant or noteworthy
occurrence.
For example:
A telephone receiver is taken off the
hook.
A state is the condition of an object at
a moment in time—the time between events.
For example:
-A telephone is in the state of being
"idle" after the receiver is placed on the hook and until it
Is taken off the hook.
A transition is a relationship between
two states that indicates that when an event occurs, the
Object moves from the prior state to the
subsequent state.
For example:
- When the event "off hook"
occurs, transition the telephone from the "idle" to
"active" state.
9.
What is meant by State chart Diagrams?
A UML state chart diagram, as shown in
Figure 29.1, illustrates the interesting events and states of an object, and
the behavior of an object in reaction to an event. Transitions are shown as
arrows, labeled with their event. States are shown in rounded rectangles. It is
common to include an initial pseudo-state, which automatically transitions to
another state when the instance is created.
10.
State chart Diagrams in the UP?
There is not one model in the UP called
the "state model." Rather, any element in any model (Design Model,
Domain Model, and so forth) may have a state chart to better understand or
communicate its dynamic behavior in response to events. For example, a state
chart associated with the Sale design class of the Design Model is itself part
of the Design Model.
11.
Utility of Use Case State chart Diagrams.
- Hard-coded
conditional tests for out-of-order events
- Use
of the State pattern (discussed in a subsequent chapter)
- disabling
widgets in active windows to disallow illegal events (a desirable approach)
- A
state machine interpreter that runs a state table representing a use case
State chart diagram.
12.
List out the types of Events.
-External event
-Internal event
-Temporal event
13.
Define External event.
External event—also known as a system
event, is caused by something (for example, an actor) outside our system
boundary. SSDs illustrate external events. Noteworthy external events
precipitate the invocation of system operations to respond to them.
- When a cashier presses the "enter
item" button on a POS terminal, an external event has occurred.
14.
Define internal event.
Internal event—caused by something
inside our system boundary. In terms of software, an internal event arises when
a method is invoked via a message or signal that was sent from another internal
object. Messages in interaction diagrams suggest internal events. - When a Sale
receives a make Line item message, an internal event has occurred.
15.
Define temporal event.
Temporal event—caused by the occurrence of
a specific date and time or passage of time. In terms of software, a temporal
event is driven by a real time or simulated-time clock.
-Suppose that after an end Sale
operation occurs, a make Payment operation must occur within five minutes,
otherwise the current sale is automatically purged.
PART- B
1.
Explain UML State Machine Diagrams and Modeling.
-Definition
-How to apply
-Example
-Process
2.
What is the operation of contracts works.
-Contracts -Contract Sections -Post
conditions
-Guidelines: Contracts
-Next Gen POS Example
-Changes to the Domain Model -Contracts,
Operations, and the UML -Operation Contracts With in the UP
3.
Explain the operation of Mapping Designs to Code.
- Programming and the Development
Process -Mapping Designs to Code
-Creating Class Definitions from DCDs
-Creating Methods from Interaction Diagrams -Container/Collection Classes in
Code -Exceptions and Error Handling
-Defining the Sale—make Line Item Method
-Order of Implementation
-Test-First Programming
4.
What is operation of UML Deployment and Component Diagram? Draw the diagram for
a banking application.
-Deployment Diagram
-Component Diagram
PART
C
State
diagrams
State diagrams are used to describe the
behavior of a system.
Activity
diagrams
Activity diagrams describe the workflow
behavior of a system.
Deployment
diagrams
Deployment diagrams show the physical
relationship between hardware and software in a system.
Component
diagrams
Component diagrams show the software
components of a system and how they are related to each other.
Structural
modeling
Structural modeling captures the static
features of a system.
Behavioral
model
Behavioral model describes the
interaction in the system.
Architectural
model
Architectural model represents the
overall framework of the system.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.