CS2357 OOAD LAB

OBJECTIVE: To develop a mini-project following the 12 exercises listed below.1. To develop a problem statement.2. Develop an IEEE standard SRS document. Also develop risk management andproject plan (Gantt chart).3. Identify Use Cases and develop the Use Case model.4. Identify the business activities and develop an UML Activity diagram.5. Identity the conceptual classes and develop a domain model with UML Classdiagram.6. Using the identified scenarios find the interaction between objects and representthem using UML Interaction diagrams.7. Draw the State Chart diagram.8. Identify the User Interface, Domain objects, and Technical services. Draw thepartial layered, logical architecture diagram with UML package diagram notation.9. Implement the Technical services layer.10. Implement the Domain objects layer.11. Implement the User Interface layer.12. Draw Component and Deployment diagrams.

Suggested domains for Mini-project.1. Passport automation system.2. Book bank3. Exam Registration4. Stock maintenance system.5. Online course reservation system6. E-ticketing7. Software personnel management system8. Credit card processing9. e-book management system10. Recruitment system11. Foreign trading system12. Conference Management System13. BPO Management System

STUDY OF UML

AIM

General study of UML

DESCRIPTION

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, which stands for Unified Modeling Language. The purpose of this course is to

present important highlights of the UML.

At the center of the UML are its nine kinds of modeling diagrams, which we describe

here.

Use case diagrams

Class diagrams

Object diagrams

Sequence diagrams

Collaboration diagrams

State chart diagrams

Activity diagrams

Component diagrams

Deployment diagrams

The UML is applicable to object-oriented problem solving. Anyone interested in

learning UML must be familiar with the underlying tenet of object-oriented problem

solving -- it all begins with the construction of a model. A model is an abstraction of the

underlying problem. The domain is the actual world from which the problem comes.

Models consist of objects that interact by sending each other messages. Think of an

object as "alive." Objects have things they know (attributes) and things they can do

(behaviors or operations). The values of an object's attributes determine its state.

Classes are the "blueprints" for objects. A class wraps attributes (data) and

behaviors (methods or functions) into a single distinct entity. Objects are instances of

classes.

AN INTRODUCTION TO UML DIAGRAM

The Unified Modeling Language is a language for specifying, constructing,

visualizing, and documenting the artifacts of a software-intensive system. Analogous to

the use of architectural blueprints in the construction industry, UML provides a common

language for describing software models, and it can be used in conjunction with a wide

range of software lifecycles and development processes.

1. USE CASE DIAGRAM

Use Case diagrams identify the functionality provided by the system (use cases),

the users who interact with the system (actors), and the association between the users and

the functionality. Use Cases are used in the Analysis phase of software development to

articulate the high-level requirements of the system. The primary goals of Use Case

diagrams include:

Providing a high-level view of what the system does

Identifying the users ("actors") of the system

Determining areas needing human-computer interfaces.

GRAPHICAL NOTATION

The basic components of Use Case diagrams are the Actor, the Use Case, and the

Association.

ACTOR

An Actor, as mentioned, is a user of the system, and is depicted using a stick

figure. The role of the user is written beneath the icon. Actors are not limited to humans.

If a system communicates with another application, and expects input or delivers output,

then that application can also be considered an actor.

USE CASE

A Use Case is functionality provided by the system, typically described as verb +

object (e.g. Register Car, Delete User). Use Cases are depicted with an ellipse. The name

of the use case is written within the ellipse.

ASSOCIATION

Associations are used to link Actors with Use Cases, and indicate that an Actor

participates in the Use Case in some form. Associations are depicted by a line connecting

the Actor and the Use Case.

The following image shows how these three basic elements work together to form

a use case diagram.

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 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.

2. SEQUENCE DIAGRAM

Sequence diagrams document the interactions between classes to achieve a result,

such as a use case. Because UML is designed for object-oriented programming, these

communications between classes are known as messages. The Sequence diagram lists

objects horizontally, and time vertically, and models these messages over time.

NOTATION

In a Sequence diagram, classes and actors are listed as columns, with vertical

lifelines indicating the lifetime of the object over time.

OBJECT

Objects are instances of classes, and are arranged horizontally. The pictorial

representation for an Object is a class (a rectangle) with the name prefixed by the object

name (optional) and a semi-colon.

ACTOR

Actors can also communicate with objects, so they too can be listed as a column.

An Actor is modeled using the ubiquitous symbol, the stick figure.

LIFELINE

The Lifeline identifies the existence of the object over time. The notation for a

Lifeline is a vertical dotted line extending from an object.

ACTIVATION

Activations, modeled as rectangular boxes on the lifeline, indicate when the

object is performing an action.

MESSAGE

Messages, modeled as horizontal arrows between Activations, indicate the

communications between objects.

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.

Each vertical dotted line is a lifeline, representing the time that an object exists.

Each arrow is a message call. An arrow goes from the sender to the top of the activation

bar of the message on the receiver's lifeline. The activation bar represents the duration of

execution of the message.

3. ACTIVITY DIAGRAM

Activity diagrams are used to document workflows in a system, from the business

level down to the operational level. When looking at an Activity diagram, you'll notice

elements from State diagrams. In fact, the Activity diagram is a variation of the state

diagram where the "states" represent operations, and the transitions represent the

activities that happen when the operation is complete. The general purpose of Activity

diagrams is to focus on flows driven by internal processing vs. external events.

ACTIVITY STATES

Activity states mark an action by an object. The notations for these states are

rounded rectangles, the same notation as found in State chart diagrams.

TRANSITION

When an Activity State is completed, processing moves to another Activity State.

Transitions are used to mark this movement. Transitions are modeled using arrows.

SWIM LANE

Swim lanes divide activities according to objects by arranging objects in column

format and placing activities by that object within that column. Objects are listed at the

top of the column, and vertical bars separate the columns to form the swim lanes.

INITIAL STATE

The Initial State marks the entry point and the initial Activity State. The notation

for the Initial State is the same as in State chart diagrams, a solid circle. There can only

be one Initial State on a diagram.

FINAL STATE

Final States mark the end of the modeled workflow. There can be multiple Final

States on a diagram, and these states are modeled using a solid circle surrounded by

another circle.

SYNCHRONIZATION BAR

Activities often can be done in parallel. To split processing ("fork"), or to resume

processing when multiple activities have been completed ("join"), Synchronization Bars

are used. These are modeled as solid rectangles, with multiple transitions going in and/or

out.

4. COMPONENT DIAGRAM

Component diagrams fall under the category of an implementation diagram, a

kind of diagram that models the implementation and deployment of the system. A

Component Diagram, in particular, is used to describe the dependencies between various

software components such as the dependency between executable files and source files.

This information is similar to that within make files, which describe source code

dependencies and can be used to properly compile an application.

COMPONENT

A component represents a software entity in a system. Examples include source

code files, programs, documents, and resource files. A component is represented using a

rectangular box, with two rectangles protruding from the left side, as seen in the image to

the right.

DEPENDENCY

A Dependency is used to model the relationship between two components. The

notation for a dependency relationship is a dotted arrow, pointing from a component to

the component it depends on.

5. CLASS DIAGRAM

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

Every class diagram has classes, associations, and multiplicities. Navigability and roles

are optional items placed in a diagram to provide clarity.

6. PACKAGES AND OBJECT DIAGRAMS

To simplify complex class diagrams, you can group classes into packages. A

package is a collection of logically related UML elements. The diagram below is a

business model in which the classes are grouped into packages.

Packages appear as rectangles with small tabs at the top. The package name is on

the tab or inside the rectangle. The dotted arrows are dependencies. One package

depends on another if changes in the other could possibly force changes in the first.

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.

7. 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.

8. STATE CHART 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.

States are rounded rectangles. Transitions are arrows from one state to another.

Events or conditions that trigger transitions are written beside the arrows. Our diagram

has two self-transition, one on Getting SSN and another on Getting PIN.

The initial state (black circle) is a dummy to start the action. Final states are also

dummy states that terminate the action.

9. 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.

Logical Architecture and UML Package Diagrams

• The software architecture is a fairly large topic: we will only introduce one possible solution (the most common) here.

• As we have finished the requirement analysis part of the first iteration and are ready to move on to design we can look at a larger scale.

• The design of a typical OO system is based on several architectural layers, such as a UI layer, an application logic (or "domain") layer, and so forth.

Logical architecture using a UML package diagram.

• A UML package diagram provides a way to group elements. A UML package can group anything: classes, other packages, use cases, and so on. Nesting packages is very common.

• It is common to want to show dependency (a coupling) between packages so that developers can see the large-scale coupling in the system.

• A UML package represents a namespace so that, for example, a Date class may be defined in two packages. If you need to provide fully-qualified names, the UML notation is, for example, java::util::Date in the case that there was an outer package named "java" with a nested package named "util" with a Date class.

Designing with Layers

• Guidelines– The responsibilities of the objects in a layer should be strongly related to

each other and should not be mixed with responsibilities of other layers. For example, objects in the UI layer should focus on UI work, such as creating windows and widgets, capturing mouse and keyboard events, and so forth. Objects in the application logic or "domain" layer should focus on application logic, such as calculating a sales total or taxes, or moving a piece on a game board.

– UI objects should not do application logic. For example, a Java Swing JFrame (window) object should not contain logic to calculate taxes or move a game piece. And on the other hand, application logic classes should not trap UI mouse or keyboard events. That would violate a clear separation of concerns and maintaining high cohesion : basic architectural principles.

The Model-View Separation Principle• The Model-View Separation principle states that model (domain) objects should

not have direct knowledge of view (UI) objects. So, for example, a Register or Sale object should not directly send a message to a GUI window object ProcessSaleFrame, asking it to display something, change color, close, and so forth.