RATIONAL ROSE AS A CASE TOOL

Rational Rose visual modeling facilitates and
automates parts of the software development process
through the use of the Unified Modeling Language. The
UML is meta-language receiving strong industry support
that specifies a standardized set of graphical notations
and their syntax that is useful in object-oriented analysis
and design (OOAD).

The Rational Software Corporation offers a
Software Engineering Educational Development
(SEED) program that provides copies of various software
packages and training materials, including Rational
Rose, to qualifying educational institutions. Information
about the SEED program may be obtained from
seed@rational.com or from the company web site at
http://www.rational.com. The SEED program can provide
both individual 1-year licenses that can be provided
to both students and faculty to use the Rational Rose
software as well as server licenses so that the software
can be installed in a laboratory environment. In addition
to Rational Rose, many other software tools are also
available under the SEED program such as those for
configuration management or real-time system development.
The SEED program can also make available
training materials for various courses related to OOAD,
UML, and Rational Rose (Sweeney 2000).
Rational Rose has many advantages as a UML
visual modeling tool, but its flexibility may be the most
valuable. This flexibility is achieved by the software’s
ability to support many object-oriented languages including
Java, MFC C++, Visual Basic, as well as Oracle
8i databases. Rational Rose promotes software component
reuse and better utilizes scarce software development
resources. Rational Rose supports both forward
and reverse engineering. Support for forward engineering
means that Rational Rose can generate code based
on a visual model of the application, whereas reverse
engineering support allows Rational Rose to convert
existing code into a visual model. The combination of
forward and reverse engineering is often referred to as
round-trip engineering.

Successful OOAD processes are often described
as having the characteristics of being both “iterative”
and “incremental” (Fowler 2000; Reed 2000; Liberty
1998). In the context of OOAD, iterative means
that the development proceeds piecemeal toward completion,
in such a way that as Fowler notes, “each iteration
builds production-quality software, tested and integrated,
that satisfies a subset of the requirements of the
project (Fowler 2000)”. Each iteration builds incrementally
on previous iterations during the construction phase
of the project. Rational Rose supports this iterative/
incremental development approach in part through
its round-trip engineering capabilities and by virtue of
its ability to be used in a team development environment.

CRC and Sequence Diagram

Hi girls..
Check out this link to get a better understanding of CRC and sequence diagram

http://www.cs.toronto.edu/~jm/340S/02/PDF2/SequenceD.pdf

Example for Sequence Diagram

Hi Girls...
Check out this link to get an idea about Sequence diagram..

http://en.wikipedia.org/wiki/Sequence_diagram

Requirements Statement and Usecases for Example ATM System

The software to be designed will control a simulated automated teller machine (ATM) having a magnetic stripe reader for reading an ATM card, a customer console (keyboard and display) for interaction with the customer, a slot for depositing envelopes, a dispenser for cash , a printer for printing customer receipts, and a key-operated switch to allow an operator to start or stop the machine. The ATM will communicate with the bank's computer over an appropriate communication link.

The ATM will service one customer at a time. A customer will be required to insert an ATM card and enter a personal identification number (PIN) - both of which will be sent to the bank for validation as part of each transaction. The customer will then be able to perform one or more transactions. The card will be retained in the machine until the customer indicates that he/she desires no further transactions, at which point it will be returned

The ATM must be able to provide the following services to the customer:

• 
  A customer must be able to make a cash withdrawal from any suitable account linked to the card. Approval must be obtained from the bank before cash is dispensed.
• 
  A customer must be able to make a deposit to any account linked to the card, consisting of cash and/or checks in an envelope. The customer will enter the amount of the deposit into the ATM, subject to manual verification when the envelope is removed from the machine by an operator. Approval must be obtained from the bank before physically accepting the envelope.
• 
  A customer must be able to make a transfer of money between any two accounts linked to the card.
• 
  A customer must be able to make a balance inquiry of any account linked to the card.

A customer must be able to abort a transaction in progress by pressing the Cancel key instead of responding to a request from the machine.

The ATM will communicate each transaction to the bank and obtain verification that it was allowed by the bank. Ordinarily, a transaction will be considered complete by the bank once it has been approved. In the case of a deposit, a second message will be sent to the bank indicating that the customer has deposited the envelope. (If the customer fails to deposit the envelope within the timeout period, or presses cancel instead, no second message will be sent to the bank and the deposit will not be credited to the customer.)

If the bank determines that the customer's PIN is invalid, the customer will be required to re-enter the PIN before a transaction can proceed. If the customer is unable to successfully enter the PIN after three tries, the card will be permanently retained by the machine, and the customer will have to contact the bank to get it back.

If a transaction fails for any reason other than an invalid PIN, the ATM will display an explanation of the problem, and will then ask the customer whether he/she wants to do another transaction.

The ATM will provide the customer with a printed receipt for each successful transaction, showing the date, time, machine location, type of transaction, account(s), amount, and ending and available balance(s) of the affected account ("to" account for transfers).

The ATM will have a key-operated switch that will allow an operator to start and stop the servicing of customers. After turning the switch to the "on" position, the operator will be required to verify and enter the total cash on hand. The machine can only be turned off when it is not servicing a customer. When the switch is moved to the "off" position, the machine will shut down, so that the operator may remove deposit envelopes and reload the machine with cash, blank receipts, etc.

The ATM will also maintain an internal log of transactions to facilitate resolving ambiguities arising from a hardware failure in the middle of a transaction. Entries will be made in the log when the ATM is started up and shut down, for each message sent to the Bank (along with the response back, if one is expected), for the dispensing of cash, and for the receiving of an envelope. Log entries may contain card numbers and dollar amounts, but for security will never contain a PIN.

Use Cases for Example ATM System

Flows of Events for Individual Use Cases


System Startup Use Case

The system is started up when the operator turns the operator switch to the "on" position. The operator will be asked to enter the amount of money currently in the cash dispenser, and a connection to the bank will be established. Then the servicing of customers can begin.



System Shutdown Use Case

The system is shut down when the operator makes sure that no customer is using the machine, and then turns the operator switch to the "off" position. The connection to the bank will be shut down. Then the operator is free to remove deposited envelopes, replenish cash and paper, etc.


Session Use Case

A session is started when a customer inserts an ATM card into the card reader slot of the machine. The ATM pulls the card into the machine and reads it. (If the reader cannot read the card due to improper insertion or a damaged stripe, the card is ejected, an error screen is displayed, and the session is aborted.) The customer is asked to enter his/her PIN, and is then allowed to perform one or more transactions, choosing from a menu of possible types of transaction in each case. After each transaction, the customer is asked whether he/she would like to perform another. When the customer is through performing transactions, the card is ejected from the machine and the session ends. If a transaction is aborted due to too many invalid PIN entries, the session is also aborted, with the card being retained in the machine.
The customer may abort the session by pressing the Cancel key when entering a PIN or choosing a transaction type.



Transaction Use Case

Note: Transaction is an abstract generalization. Each specific concrete type of transaction implements certain operations in the appropriate way. The flow of events given here describes the behavior common to all types of transaction. The flows of events for the individual types of transaction (withdrawal, deposit, transfer, inquiry) give the features that are specific to that type of transaction.

A transaction use case is started within a session when the customer chooses a transaction type from a menu of options. The customer will be asked to furnish appropriate details (e.g. account(s) involved, amount). The transaction will then be sent to the bank, along with information from the customer's card and the PIN the customer entered.

If the bank approves the transaction, any steps needed to complete the transaction (e.g. dispensing cash or accepting an envelope) will be performed, and then a receipt will be printed. Then the customer will be asked whether he/she wishes to do another transaction.

If the bank reports that the customer's PIN is invalid, the Invalid PIN extension will be performed and then an attempt will be made to continue the transaction. If the customer's card is retained due to too many invalid PINs, the transaction will be aborted, and the customer will not be offered the option of doing another.

If a transaction is cancelled by the customer, or fails for any reason other than repeated entries of an invalid PIN, a screen will be displayed informing the customer of the reason for the failure of the transaction, and then the customer will be offered the opportunity to do another.
The customer may cancel a transaction by pressing the Cancel key as described for each individual type of transaction below.

All messages to the bank and responses back are recorded in the ATM's log.


Withdrawal Transaction Use Case

A withdrawal transaction asks the customer to choose a type of account to withdraw from (e.g. checking) from a menu of possible accounts, and to choose a dollar amount from a menu of possible amounts. The system verifies that it has sufficient money on hand to satisfy the request before sending the transaction to the bank. (If not, the customer is informed and asked to enter a different amount.) If the transaction is approved by the bank, the appropriate amount of cash is dispensed by the machine before it issues a receipt. (The dispensing of cash is also recorded in the ATM's log.)

A withdrawal transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the dollar amount.



Deposit Transaction Use Case

A deposit transaction asks the customer to choose a type of account to deposit to (e.g. checking) from a menu of possible accounts, and to type in a dollar amount on the keyboard. The transaction is initially sent to the bank to verify that the ATM can accept a deposit from this customer to this acount. If the transaction is approved, the machine accepts an envelope from the customer containing cash and/or checks before it issues a receipt. Once the envelope has been received, a second message is sent to the bank, to confirm that the bank can credit the customer's account - contingent on manual verification of the deposit envelope contents by an operator later. (The receipt of an envelope is also recorded in the ATM's log.)

A deposit transaction can be cancelled by the customer pressing the Cancel key any time prior to inserting the envelope containing the deposit. The transaction is automatically cancelled if the customer fails to insert the envelope containing the deposit within a reasonable period of time after being asked to do so.


Transfer Transaction Use Case

A transfer transaction asks the customer to choose a type of account to transfer from (e.g. checking) from a menu of possible accounts, to choose a different account to transfer to, and to type in a dollar amount on the keyboard. No further action is required once the transaction is approved by the bank before printing the receipt.
A transfer transaction can be cancelled by the customer pressing the Cancel key any time prior to entering a dollar amount.


Inquiry Transaction Use Case

An inquiry transaction asks the customer to choose a type of account to inquire about from a menu of possible accounts. No further action is required once the transaction is approved by the bank before printing the receipt.
An inquiry transaction can be cancelled by the customer pressing the Cancel key any time prior to choosing the account to inquire about.



Invalid PIN Extension

An invalid PIN extension is started from within a transaction when the bank reports that the customer's transaction is disapproved due to an invalid PIN. The customer is required to re-enter the PIN and the original request is sent to the bank again. If the bank now approves the transaction, or disapproves it for some other reason, the original use case is continued; otherwise the process of re-entering the PIN is repeated. Once the PIN is successfully re-entered, it is used for both the current transaction and all subsequent transactions in the session. If the customer fails three times to enter the correct PIN, the card is permanently retained, a screen is displayed informing the customer of this and suggesting he/she contact the bank, and the entire customer session is aborted.
If the customer presses Cancel instead of re-entering a PIN, the original transaction is cancelled.

THE FOLLOWING QUESTIONS BEING ASKED QUITE OFTEN?

• Are there any differences between OOAand OOD? If so, what are they?

Yes, there are differences. OOA is the act of determining the
abstractions which unerly the requirements. It is the backwards
reasoning that starts with the requirements and ends up with a set of
objects that express the abstractions; and messages that support the
required behaviors. OOD embodies the set of decisions that
determines how those objects and methods will be implemented.
Typically class inheritance and composition hierarchies are among
those design decisions.

OOA exposes the components of the required behaviors, in order that
they may be implemented. On the other hand, OOD hides the details
of the implementation so that those details do not pollute the rest of
the design.

Despite the differences, however, OOA and OOD are simply at
opposite ends of the same activity. Moreover, there is no good
dividing line which separates them, either in time or in function. It is
better to view OOA and OOD like the different colors in a spectrum.
They are certainly different, but it is difficult to tell when one starts
and the other leaves off. OOAD is a continuum of activity which
incorporates both analysis and design.

• Should we do OOA first, followed by OOD?

No, they are best done concurrently. Analysis and Design should not
be separated into broad phases. Nor should the analysis model be
frozen before the design modeling begins. It should be evident from
our case study that OOA and OOD are very closely related, and that
they cooperate synergistically. The analysis model cannot be
completed in the absence of the design model. And the design model
cannot be completed in the absence of the analysis model. One of the
most important aspects of OOAD is the synergy between the two
concepts.

• What is a reasonable output from OOA, OOD?

At very least a set of class and object diagrams. The class diagrams
show the static structure of the application. It is from these diagrams
that class headers can be written. Object diagrams show the
dynamics of the collaborations between objects. It is from these
diagrams that the class implementations will be written.
However, in large projects these meager beginnings are hardly
adequate. There is much that we have not covered in this simple case
study. We have not discussed how to organize the analysis and
design of a large program. How to control large scale visibility.
How to control the physical model so that a large project can be
developed and released in an organized and well managed way.
These topics are important parts of the OOAD universe, and should
not be neglected.

• Are there different notations for OOA and OOD?

Yes and No. OOA, since it is based on the analysis of required
behaviors, tends to focus on the behavioral model. Thus tit places
more emphasis on the generation of object diagrams. We saw this in
the case study. In every case, the central abstraction for each
requirement was documented, first, by an Object Diagram.
Conversely, since OOD focuses on finding static structures which
support the required dynamics, it tends to focus on class diagrams.
However, there are certainly plenty of cases where class diagrams are
produced by OOA activities and object diagrams are produced by
OOD activities.

One of the great advantages of OOAD over other analysis and design
techniques is that the notation for analysis is compatible with the
notation for design. In fact, only one set of documents is maintained.
We do not separate them into “analysis documents” and “design
documents".

OO Technology and Reuse

One of the major benefits of OO technology, as claimed by its proponents, is that it enables reuse. Whenever we can reuse existing components for a product we potentially gain additional time which can then be used to address the novel aspects of our application, or simply deliver it earlier. But what is meant by reuse?

The most common kind of reuse is through libraries. The user of the library is presented with a black box and a description of its interface. One is supposed to be able to use the API (application programmers interface) without a deep understanding of the implementation details of the library. The various widget components in the foundation classes for a windowing system are examples of this kind of low level fine-grained reuse.

Another form of reuse concerns low level architectural details, that is at the level of algorithms and data structures. All of us are familiar with the generic description of an algorithm, like quick sort, which we then code in language chosen for the application. We all know about binary trees, and we do not have to re-invent them for every application. Design patterns are also an example of this level of reuse. There is still substantial scope for inventiveness in new patterns, or in adapting and combining existing patterns.

Software components are self-contained modules that can be connected together using some protocol, such as CORBA or DCOM. They are more than just an implementation, since the also reflect a design philosophy. Arbitrary components can be connected only if they share the same connection, communication, and control architecture.

The highest form of reuse occurs at the sweeping architecture level composed of many pieces plus a philosophy. Here we try to reuse good designs. This is potentially the most profitable kind of reuse because good designs are costly to develop. The current technique for high level design reuse is via application frameworks.

An application framework provides a generic design within a given domain, and a reusable implementation of that design. An object-oriented application framework presents its generic design and reusable implementation of a system through a set of classes and their collaborations. Applications are built from frameworks by extending or customizing parts of the framework, while retaining the original design. Frameworks solve larger grained problems then individual components, and this makes the effort of finding and reusing them more cost effective than for small components.

The notion of reuse even makes sense in terms of the features of a language. You can evaluate various features in terms of "what does this feature let me reuse in my programs?". For example, parameterizing a function (e.g. qsort) lets you reuse it in many contexts, inheritance lets you reuse the behaviour of your ancestor classes, templates let you reuse design.

We can locate the various kinds of reuse on a reuse plane, which reflects what is being reused and the granularity of the reuse. OO technologies start to pay off at medium to high levels of reuse --- which is exactly the granularity at which iterative and incremental development occurs.

About Patterns

Patterns :

A design pattern describes a problem and the design of a generic solution for that problem. A pattern doesn't provide an implementation. Patterns are typically at a higher level of reuse than templates. Design patterns in software were influenced by the building and urban planning architectural patterns of Christopher Alexander

An actual instance of a pattern will take into account specific concerns. Often the system architecture combines patterns, so that a collaborating set of classes may actual embody two or more patterns.
Originally, patterns addressed common idioms in the world of OO design and implementation. Patterns have begun to be used in other areas, in particular analysis patterns are being used to describe common idioms at the business analysis level.

Patterns are described with a template that typically looks likes this:

Name and Classification - choose a good name as it will enter the vocabulary

Intent - short statement about what it does, its rationale, and intent, and the issue it addresses.
Also Known As - other well-known names, if any.

Motivation - a concrete example that illustrates a problem and how the pattern solves the problem.

Applicability - where can it be applied and how do you recognize when it can be applied.

Structure - graphical OO model of the pattern.

Participants - participating classes or objects and their roles and responsibilities.

Collaborations - how they collaborate to carry out responsibilities.

Issues and Consequences - what are trade-offs associated with the pattern, what dependencies does it create.

Implementation - hints, pitfalls, and techniques.

Sample Code - clarifying examples of language dependent issues.

Known Uses - evidence of pattern use from real systems.

Related Patterns - similar patterns and their differences, other patterns that work with this one.

Case Tool - UML Tutorial

Hi Girls,

The following link helps you to understand UML in a better way...


http://visualcase.com/tutorials/uml-tutorial.htm

Class diagram

In the Unified Modeling Language (UML), a class diagram is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, and the relationships between the classes.



Relationships
A relationship is a general term covering the specific types of logical connections found on class and object diagrams. UML shows the following relationships:

Association:

An Association represents a family of links. Binary associations (with two ends) are normally represented as a line, with each end connected to a class box. Higher order associations can be drawn with more than two ends. In such cases, the ends are connected to a central diamond.

An association can be named, and the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties. There are five different types of association. Bi-directional and uni-directional associations are the most common ones. For instance, a flight class is associated with a plane class bi-directionally. Associations can only be shown on class diagrams.

Example: "department offers courses", is an association relationship.

Aggregation

Aggregation is a variant of the "has a" or association relationship; aggregation is more specific than association. As a type of association, an aggregation can be named and have the same adornments that an association can. However, an aggregation may not involve more than two classes.

Aggregation can occur when a class is a collection or container of other classes, but where the contained classes do not have a strong life cycle dependency on the container--essentially, if the container is destroyed, its contents are not.

In UML, it is graphically represented as a clear diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

Composition:

Composition is a stronger variant of the "has a" or association relationship; composition is more specific than aggregation. It is repersented with solid diamond shape.

Composition has a strong life cycle dependency between instances of the container class and instances of the contained class(es): If the container is destroyed, every instance that it contains is destroyed as well.

The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.

Differences between Composition and Aggregation:

The whole of a composition must have a multiplicity of 0..1 or 1, indicating that a part must be for only one whole. The whole of an aggregation may have any multiplicity.

When attempting to represent real-world whole-part relationships, e.g., an engine is part of a car, the composition relationship is most appropriate. However, when representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, an aggregation relationship is best, as the engine, ENG01 may be also part of a different car model, CM02. This is often called a "catalog" relationship.

Just one more!

Dear Students
Here is a technical paper on UMl Class Diagrams. Just go through the paper to see whether you are able to get a hold of what the author is saying.

http://www.objectmentor.com/resources/articles/umlClassDiagrams.pdf

UML Tutorial

Here you go with the following link to check whether our understanding is same as the one given here.
http://www.visualbuilder.com/uml/tutorial/

Problem Statement

Using the UA Approach develop a detailed OO Model for a simple drawing tool, where shapes can be drawn, moved, deleted and grouped.

Enjoy and Have fun!

CRC card

Class Responsibility Collaborator (CRC cards) are a brainstorming tool used in the design of object-oriented software. They were proposed by Ward Cunningham and Kent Beck. They are typically used when first determining which classes are needed and how they will interact.
CRC cards are usually created from index cards on which are written:

The class name
Its Super and Sub classes (if applicable)
The responsibilities of the class.
The names of other classes with which the class will collaborate to fulfill its responsibilities.
Author

Using a small card keeps the complexity of the design at a minimum. It focuses the designer on the essentials of the class and prevents him from getting into its details and inner workings at a time when such detail is probably counter-productive. It also forces the designer to refrain from giving the class too many responsibilities. Because the cards are portable, they can easily be laid out on a table and re-arranged while discussing a design with other people.

A common method to determine what cards should be created is to read a specification for the program being designed and consider if each noun should be a class and if each verb should be a responsibility of the noun or class to which it belongs. Naturally, the existence of a noun or verb does not require a class or responsibility in the program, but it is considered a good starting point.

Unified Modeling Language-Modeling Diagrams

The heart of object-oriented problem solving is the construction of a model. The model abstracts the essential details of the underlying problem from its usually complicated real world. Several modeling tools are wrapped under the heading of the UML.

UML has nine kinds of modeling diagrams.They are

• Use case diagrams
• Class diagrams
• Object diagrams
• Sequence diagrams
• Collaboration diagrams
• Statechart diagrams
• Activity diagrams
• Component diagrams
• Deployment diagrams

Use case diagrams

Use case diagrams describe what a system does from the standpoint of an external observer. The emphasis is on what a system does rather than how.
Use case diagrams are closely connected to scenarios. A scenario is an example of what happens when someone interacts with the system. Here is a scenario for a medical clinic.

"A patient calls the clinic to make an appointment for a yearly checkup. The receptionist finds the nearest empty time slot in the appointment book and schedules the appointment for that time slot. "
A use case is a summary of scenarios for a single task or goal. An actor is who or what initiates the events involved in that task. Actors are simply roles that people or objects play. The picture below is a Make Appointment use case for the medical clinic. The actor is a Patient. The connection between actor and use case is a communication association (or communication for short).

Actors are stick figures. Use cases are ovals. Communications are lines that link actors to use cases.
A use case diagram is a collection of actors, use cases, and their communications. We've put Make Appointment as part of a diagram with four actors and four use cases. Notice that a single use case can have multiple actors.

Use case diagrams are helpful in three areas.

• determining features (requirements). New use cases often generate new requirements as the system is analyzed and the design takes shape.
• communicating with clients. Their notational simplicity makes use case diagrams a good way for developers to communicate with clients.
• generating test cases. The collection of scenarios for a use case may suggest a suite of test cases for those scenarios.

Class diagrams

A Class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams are static -- they display what interacts but not what happens when they do interact.
The class diagram below models a customer order from a retail catalog. The central class is the Order. Associated with it are the Customer making the purchase and the Payment. A Payment is one of three kinds: Cash, Check, or Credit. The order contains OrderDetails (line items), each with its associated Item.

UML class notation is a rectangle divided into three parts: class name, attributes, and operations. Names of abstract classes, such as Payment, are in italics. Relationships between classes are the connecting links.

Our class diagram has three kinds of relationships.

Association -- a relationship between instances of the two classes. There is an association between two classes if an instance of one class must know about the other in order to perform its work. In a diagram, an association is a link connecting two classes.

Aggregation -- an association in which one class belongs to a collection. An aggregation has a diamond end pointing to the part containing the whole. In our diagram, Order has a collection of OrderDetails.

Generalization -- an inheritance link indicating one class is a superclass of the other. A generalization has a triangle pointing to the superclass. Payment is a superclass of Cash, Check, and Credit.

An association has two ends. An end may have a role name to clarify the nature of the association. For example, an OrderDetail is a line item of each Order.

A navigability arrow on an association shows which direction the association can be traversed or queried. An OrderDetail can be queried about its Item, but not the other way around. The arrow also lets you know who "owns" the association's implementation; in this case, OrderDetail has an Item. Associations with no navigability arrows are bi-directional.

The multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end. Multiplicities are single numbers or ranges of numbers. In our example, there can be only one Customer for each Order, but a Customer can have any number of Orders.

This table gives the most common multiplicities.

Multiplicities - Meaning
0..1 - zero or one instance. The notation n . . m indicates n to m instances.
0..* or * - no limit on the number of instances (including none).
1 - exactly one instance
1..* - at least one instance


Object diagrams

Object diagrams show instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships.
This small class diagram shows that a university Department can contain lots of other Departments.




The object diagram below instantiates the class diagram, replacing it by a concrete example.

Each rectangle in the object diagram corresponds to a single instance. Instance names are underlined in UML diagrams. Class or instance names may be omitted from object diagrams as long as the diagram meaning is still clear.

Sequence diagrams

Class and object diagrams are static model views. Interaction diagrams are dynamic. They describe how objects collaborate.
A sequence diagram is an interaction diagram that details how operations are carried out -- what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence.
Below is a sequence diagram for making a hotel reservation. The object initiating the sequence of messages is a Reservation window.

The Reservation window sends a makeReservation() message to a HotelChain. The HotelChain then sends a makeReservation() message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation.

Collaboration diagrams

Collaboration diagrams are also interaction diagrams. They convey the same information as sequence diagrams, but they focus on object roles instead of the times that messages are sent. In a sequence diagram, object roles are the vertices and messages are the connecting links.

The object-role rectangles are labeled with either class or object names (or both). Class names are preceded by colons ( : ).
Each message in a collaboration diagram has a sequence number. The top-level message is numbered 1. Messages at the same level (sent during the same call) have the same decimal prefix but suffixes of 1, 2, etc. according to when they occur.

Statechart diagrams

Objects have behaviors and state. The state of an object depends on its current activity or condition. A statechart diagram shows the possible states of the object and the transitions that cause a change in state.
Our example diagram models the login part of an online banking system. Logging in consists of entering a valid social security number and personal id number, then submitting the information for validation.
Logging in can be factored into four non-overlapping states: Getting SSN, Getting PIN, Validating, and Rejecting. From each state comes a complete set of transitions that determine the subsequent state.

Activity diagrams

An activity diagram is essentially a fancy flowchart. Activity diagrams and statechart diagrams are related. While a statechart diagram focuses attention on an object undergoing a process (or on a process as an object), an activity diagram focuses on the flow of activities involved in a single process. The activity diagram shows the how those activities depend on one another.

For our example, we used the following process.

"Withdraw money from a bank account through an ATM."

The three involved classes (people, etc.) of the activity are Customer, ATM, and Bank. The process begins at the black start circle at the top and ends at the concentric white/black stop circles at the bottom. The activities are rounded rectangles.

Activity diagrams can be divided into object swimlanes that determine which object is responsible for which activity. A single transition comes out of each activity, connecting it to the next activity.
A transition may branch into two or more mutually exclusive transitions. Guard expressions (inside [ ]) label the transitions coming out of a branch. A branch and its subsequent merge marking the end of the branch appear in the diagram as hollow diamonds.
A transition may fork into two or more parallel activities. The fork and the subsequent join of the threads coming out of the fork appear in the diagram as solid bars.

Component and deployment diagrams

A component is a code module. Component diagrams are physical analogs of class diagram. Deployment diagrams show the physical configurations of software and hardware.
The following deployment diagram shows the relationships among software and hardware components involved in real estate transactions.

The physical hardware is made up of nodes. Each component belongs on a node. Components are shown as rectangles with two tabs at the upper left.

Interview with Grady Booch

This is the original text of an interview with Grady Booch, later translated in Italian and published in Computer Programming. In the following text, CP stands for Carlo Pescio and GB for Grady Booch.


CP: This is probably the Most Frequently Asked Question, but would you mind telling something about the UML. For instance, why did you decide to move the emphasis from a notation + methodology to a true modeling language?
GB: Actually, this is a FAQ; i've written up a series of such FAQs, which appear on http://www.rational.com in the oo technology pages. Briefly, there are a two reasons for this change. First, it was clear that a number of users wanted the ability to adapt their own process to the UML; indeed, different domains demand different approaches. Second, the focus of the OMG RFP for OOAD is focused on modeling languages, not processes.


CP: I've heard more than a few peoples saying that "UML is too hard/comprehensive". I guess this is because your preliminary documentation is quite different from the OOA/D books peoples are used to. But as you move from a methodology to a language, an higher degree of formalism is unavoidable. Don't you think that having to learn a more formal semantics will scare some of the analysts? I'm thinking e.g. to business experts who used to do the analysis, but had little computer science knowledge.


GB: It is true that the UML is comprehensive; we have tried to address the traditional and contemporary modeling problems (class models, state machine models, etc). We have also tried to cover issues of business modeling (since they often flow into an oo system) as well as executable semantics. Further, we've tried to be forward looking, meaning that we are focused on software development trends, most notably issues of componentware, distributed computing, and net based applications. These elements are all covered by the UML. It is also true that the current UML documents are not highly approachable to the novice. Indeed, the introduction of these documents explicitly states so. However, these documents are meant to specify the language, not to explain it. This is not unlike, for example, the C++ ARM. This is not how a beginner would learn to programm in C++.
The amigos are writing three books to mitigate this problem: a user guide, a reference manual, and a book on process. In addition, we know of several other books in the works that will be using the UML. In fact, "Core Java" already contains some UML diagrams (based on the .8 work)

History of UML

Identifiable object-oriented modeling languages began to appear between mid-1970 and the late 1980s as various methodologists experimented with different approaches to object-oriented analysis and design. The number of identified modeling languages increased from less than 10 to more than 50 during the period between 1989-1994. Many users of OO methods had trouble finding complete satisfaction in any one modeling language, fueling the "method wars." By the mid-1990s, new iterations of these methods began to appear and these methods began to incorporate each other’s techniques, and a few clearly prominent methods emerged.1
The development of UML began in late 1994 when Grady Booch and Jim Rumbaugh of Rational Software Corporation began their work on unifying the Booch and OMT (Object Modeling Technique) methods. In the Fall of 1995, Ivar Jacobson and his Objectory company joined Rational and this unification effort, merging in the OOSE (Object-Oriented Software Engineering) method.1
As the primary authors of the Booch, OMT, and OOSE methods, Grady Booch, Jim Rumbaugh, and Ivar Jacobson were motivated to create a unified modeling language for three reasons. First, these methods were already evolving toward each other independently. It made sense to continue that evolution together rather than apart, eliminating the potential for any unnecessary and gratuitous differences that would further confuse users. Second, by unifying the semantics and notation, they could bring some stability to the object-oriented marketplace, allowing projects to settle on one mature modeling language and letting tool builders focus on delivering more useful features. Third, they expected that their collaboration would yield improvements in all three earlier methods, helping them to capture lessons learned and to address problems that none of their methods previously handled well.1
The efforts of Booch, Rumbaugh, and Jacobson resulted in the release of the UML 0.9 and 0.91 documents in June and October of 1996. During 1996, the UML authors invited and received feedback from the general community. They incorporated this feedback, but it was clear that additional focused attention was still required.1
While Rational was bringing UML together, efforts were being made on achieving the broader goal of an industry standard modeling language. In early 1995, Ivar Jacobson (then Chief Technology Officer of Objectory) and Richard Soley (then Chief Technology Officer of OMG) decided to push harder to achieve standardization in the methods marketplace. In June 1995, an OMG-hosted meeting of all major methodologists (or their representatives) resulted in the first worldwide agreement to seek methodology standards, under the aegis of the OMG process.1
During 1996, it became clear that several organizations saw UML as strategic to their business. A Request for Proposal (RFP) issued by the Object Management Group (OMG) provided the catalyst for these organizations to join forces around producing a joint RFP response. Rational established the UML Partners consortium with several organizations willing to dedicate resources to work toward a strong UML 1.0 definition. Those contributing most to the UML 1.0 definition included: Digital Equipment Corp., HP, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational Software, TI, and Unisys. This collaboration produced UML 1.0, a modeling language that was well defined, expressive, powerful, and generally applicable. This was submitted to the OMG in January 1997 as an initial RFP response.1
In January 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies and Softeam also submitted separate RFP responses to the OMG. These companies joined the UML partners to contribute their ideas, and together the partners produced the revised UML 1.1 response. The focus of the UML 1.1 release was to improve the clarity of the UML 1.0 semantics and to incorporate contributions from the new partners. It was submitted to the OMG for their consideration and adopted in the fall of 1997.1

Fourth Generation Programming Language(4GLs)

A fourth-generation programming language(1970s-1990) (abbreviated 4GL) is a programming language or programming environment designed with a specific purpose in mind, such as the development of commercial business software. In the evolution of computing, the 4GL followed the 3GL in an upward trend toward higher abstraction and statement power. The 4GL was followed by efforts to define and use a 5GL.
The natural-language, block-structured mode of the third generation programming languages improved the process of software development. However, 4GL development methods can be slow and error-prone. It became clear that some applications could be developed more rapidly by adding a higher-level programming language and methodology which would generate the equivalent of very complicated 3GL instructions with fewer errors. In some senses, software engineering arose to handle 3GL development. 4GL and 5GL projects are more oriented toward problem solving and systems engineering.
All 4GLs are designed to reduce programming effort, the time it takes to develop software, and the cost of software development. They are not always successful in this task, sometimes resulting in inelegant and unmaintainable code.

Types

A number of different types of 4GLs exist:

• Report generators take a description of the data format and the report to generate and from that they either generate the required report directly or they generate a program to generate the report.
• Similarly, form generators manage online interactions with the application system users or generate programs to do so.
  More ambitious 4GLs (sometimes termed fourth generation environments) attempt to automatically generate whole systems from the outputs of CASE tools, specifications of screens and reports, and possibly also the specification of some additional processing logic.
• Data management 4GLs such as SAS, SPSS and Stata provide sophisticated commands for data manipulation, file reshaping, case selection and data documentation in the preparation of data for statistical analysis and reporting.

Some successful fourth-generation languages

Database query languages

• FOCUS
• NATURAL
• Informix-4GL
• Genero
• Progress 4GL
• SQL
• SB+/SystemBuilder

Data manipulation, analysis, and reporting languages

• Clarion Programming Language
• Ab Initio
• ABAP
• ADS/Online (plus transaction processing)
• Aubit-4GL
• Culprit
• DASL
• FOCUS
• Genero

Rational Rose Suite

Here is a link which gives an overview of Rational Rose Software, that we will be using in our CASE tools & UML Lab.

http://www-306.ibm.com/software/awdtools/developer/rose/enterprise/index.html

Welcome

Dear Students
A warm welcome to all of you to our blog on OOAD. Hope you use this to share the knowledge that will help us grow better in our concepts.