THEORY:
Rational Rose provides support for two essential elements of modern software
engineering: component-based development and controlled iterative development.
While these concepts are conceptually independent, their usage in combination is
both natural and beneficial.
Rational Rose’s model-diagram architecture facilitates use of the Unified Modeling
Language (UML), Component Object Modeling (COM), Object Modeling Technique
(OMT), and Booch ‘93 method for visual modeling. Using semantic information
ensures correctness by construction and maintaining consistency.
WHEN TO USE RATIONAL ROSE:
• Modeling can be useful at any point in the application development process.
• Initial Design Work (Requirement Analysis and Definition)
– Use Cases
– Class Diagrams
– Sequence Diagram
–
–
– Generality is Good in early design.
•
• Refinement of Early Models (System & Software Design)
• Introduced in Middle of Project
•
– Rational Rose includes tools for reverse engineering as well as forward engineering of classes and component architectures.
–
– You can gain valuable insights to your actual constructed architecture and pinpoint deviations from the original design.
–
– Rose offers a fast way for clients and new employees to become familiar with system internals
Modeling with Rational Rose
Rational Rose is the visual modeling software solution that lets you create, analyze,
design, view, modify, and manipulate components. You can graphically depict an
overview of the behavior of your system with a use-case diagram. Rational Rose
provides the collaboration diagram as an alternative to a use-case diagram. It shows
object interactions organized around objects and their links to one another. The
state chart diagram provides additional analysis techniques for classes with significant
dynamic behavior. A state chart diagram shows the life history of a given class, the
events that cause a transition from one state to another, and the actions that result
from a state change. Activity diagrams provide a way to model a class operation or
the workflow of a business process.
Notations
THE DIFFERENT VIEWS: There are five different views
-Logical view
.analysts/designers structure
-Process view
.System integrators performance, scalability, throughput
-Implementation view
.Programmers software management
-Deployment view
.System engineering system topology delivery, installation communication
-Use case view
.End user functionality
Notation plays an important part in any application development activity—it is the
glue that holds the process together. UML provides a very robust notation, which
grows from analysis into design.
Uml diagrams
• Instead of the Context, Data-Flow and Entity-Relationship Diagrams used in Structured Analysis, UML produces 9 types of diagrams
– Use Case Diagram
Use cases are best discovered by examining what the actor needs and defining what
the actor will be able to do with the system; this helps ensure that the system will be
what the user expects.
– Sequence Diagram
A sequence diagram is a graphical view of a scenario that shows object interaction in a time-based sequence—what happens first, what happens next. Sequence diagrams
establish the roles of objects and help provide essential information to determine class responsibilities and interfaces. Sequence diagrams are normally associated with use cases.
This type of diagram is best used during early analysis phases in design because they
are simple and easy to comprehend. A sequence diagram has two dimensions:
typically, vertical placement represents time and horizontal placement represents
different objects.
– Collaboration Diagram
A collaboration diagram is an interaction diagram which shows the sequence of
messages that implement an operation or a transaction. These diagrams show objects, their links, and their messages. They can also contain simple class instances and class utility instances. Each collaboration diagram provides a view of the interactions or structural relationships that occur between objects and object-like entities in the current model.
– State chart Diagram
State chart diagrams model the dynamic behavior of individual classes or any other kind of object. They show the sequences of states that an object goes through, the events that cause a transition from one state or activity to another, and the actions that result from a state or activity change.
State chart diagrams are closely related to activity diagrams. The main difference
between the two diagrams is state chart diagrams are state centric, while activity
diagrams are activity centric. A state chart diagram is typically used to model the
discrete stages of an object’s lifetime, whereas an activity diagram is better suited to model the sequence of activities in a process.
– Activity Diagram
An activity represents the performance of “task” or “duty” in a workflow. It may also represent the execution of a statement in a procedure. An activity is similar to a state, but expresses the intent that there is no significant waiting (for events) in an activity.
– Class Diagram
A Class Specification displays and modifies class properties and relationships. Some of the information in the specification can also be displayed inside class icons.
If a field does not apply to a particular class type, the field is unavailable and you
cannot add or change information in the field.
– Object Diagram
An Object Flow Specification allows you to display and modify the properties and relationships of an object flow on an activity diagram.
– Component Diagram
A component diagram shows the physical dependency relationships (mapping to a
file system) between components—main programs, subprograms, packages, and
tasks—and the arrangement of components into component packages.
– Deployment Diagram
A deployment diagram shows processors, devices, and connections. Each model
contains a single deployment diagram that shows the connections between processors
and devices, and the allocation of its processes to processors.
CONCLUSION:
Leave a Reply