Software Engg File

INTRODUCTION TO UML

UML is the industry standard modeling notation for object oriented systems, and is the premiere platform for rapid application development. In this chapter, we describe how UML came into being, introduce the concepts of object oriented programming, and show you how to use UML to structure your applications. • • • •

Learning about the object oriented paradigm and visual modeling Exploring types of graphical notation Looking at types of UML diagrams Developing software using visual modeling

Understanding UML Diagrams UML allows people to develop several different types of visual diagrams that represent various aspects of the system. Rational Rose supports the development of the majority of these models, as follows: • • • • • • • • •

Business Use Case diagram Use Case diagram Activity diagram Sequence diagram Collaboration diagram Class diagram Statechart diagram Component diagram Deployment diagram

These model diagrams illustrate different aspects of the system. For example, the Collaboration diagram shows the required interaction between the objects in order to perform some functionality of the system. Each diagram has a purpose and an intended audience.

INTRODUCTION TO RATIONAL ROSE

Rational Rose is a powerful visual modeling tool to aid in the analysis and design of object oriented software systems. It is used to model your system before you write any code, so you can be sure that the system is architecturally sound from the beginning. Using the model, you can catch design flaws early, while they are still inexpensive to fix. Rational Rose supports business modeling, helping you to understand the business around the system. It helps with systems analysis by enabling you to design use cases and Use Case diagrams to show the system functionality. It will let you design Interaction diagrams to show how the objects work together to provide the needed functionality. Class diagrams can be created to show the classes in a system and how they relate to each other. Component diagrams can be developed to illustrate how the classes map to implementation components. Finally, a Deployment diagram can be produced to show the network design for the system. A Rose model is a picture of a system from various perspectives. It includes all of the UML diagrams, actors, use cases, objects, classes, components, and deployment nodes in a system. It describes in great detail what the system will include and how it will work, so developers can use the model as a blueprint for the system being built. A blueprint is a good analogy for a Rose model. Just as a house has a set of blueprints that let different members of the construction crew see it from different perspectives (plumbing, electrical, and so on), a Rose model contains a number of different diagrams that let the project team see the system from different perspectives (customer, designer, project manager, tester, and so on).

UML USE CASE DIAGRAMS Definition : Use – case diagrams graphically depict system behavior (called use cases). These diagrams present a high level view of how the system is used as viewed from an outsider’s (actor’s) perspective. A use case diagram may depict all or some of the use cases of a system. Utility of Use Case Diagram : A detailed description might characterize a use case as : • • • •

A pattern of behavior the system exhibits. A sequence of related transactions performed by an actor and the system. Delivering something of value to the actor.

Use case diagrams provide a means to : • • •

Capture system requirements. Communicate with the end users and domain experts Test the system

Since all the needs of a system typically cannot be covered in one use case , it is usual to have a collection of use cases . Together this use case collection specifies all the ways of using the system.

Components of use – case diagrams are :

ATM

PIN NUMBER ACCESS

CHEK FOR THE VALIDITY OF THE CARD

CHANGE OF PIN NO.

DISPLAY DATE OF LAST TRANSACTION

CUSTOMER

SHOW ALL TRANSACTIONS HE...

SHOW THE BALANCE

AMOUNT TO BE WITHDRAWN

ERROR MSG.(REQUEST>BALANCE

UPDATE THE TRANSACTION LIST

UPDATE THE BALANCE LEFT

ATM MACHINE

EMPLOYEE MANAGEMENT SYSTEM

LIBRARY MANAGEMENT SYSTEM

ORDER PROCESSING APPLICATION

STUDENT REGISTRATION PROCESS

UMLSEQUENCE DIAGRAM Sequence diagrams are Interaction diagrams that are ordered by time; you read the diagram from the top to the bottom. As we mentioned above, each use case will have a number of alternate flows. Each Sequence diagram represents one of the flows through a use case.The objects that participate in the flow are shown in rectangles across the top of the diagram. Each object has a lifeline, drawn as a vertical dashed line below the object. The lifeline begins when the object is instantiated and ends when the object is destroyed. A message is drawn between the lifelines of two objects to show that the objects communicate. Each message represents one object making a function call of another. Later in the process, as we define operations for the classes, each message will become an operation.Messages can also be reflexive, showing that an object is calling one of its own operations.

The Sequence Diagram Toolbar

ATM

Employee management system

LIBRARY MANAGEMENT SYSTEM O p e ra to r

B a r c o d e s tu d e n t in fo B o o k in fo M e s s a g e b osxtu d e n t d e ta ilsr e tu r n b o o k B o o k d e ta ils re a d e r c o n tro lle r c o n tr o lle r re a d b a rc o d e s u b m it b a rc o d e g e t d e ta ils s u b m it v a lid a te if fine u p d a te u p d a te b o o k re turn s u c c e s s fu l

v a lid a te d e ta ils in v a lid s tud e n t s u b m it b o o k c o d e c h e c k a v a ilib ility n o t a v a ila b le a d d re c o rd a d d re c o rd is s u e s u c c e s s

ORDER PROCESSING APPLICATION

STUDENT REGISTRATION PROCESS student

registrar

account manager

scrutiny officer

request for the course

prompt for form submission submit form details form verification

if valid check student details

return details to registrar prompt for fee submission submit fees

confirm fee submition grant admission letter request for cancellation verification of details

confirm details forward student details

return fees after deducting cancellation charges

UML CLASS DIAGRAMS Definition A class diagram is a diagram showing a collection of classes and interfaces, along with the collaborations and relationships among classes and interfaces. A class diagram is a pictorial representation of the detailed system design. A thing to remember is that a class diagram is a static view of a system. The structure of a system is represented using class diagrams. Class diagrams are referenced time and again by the developers while implementing the system.

Elements of a Class Diagram A class diagram is composed primarily of the following elements that represent the system's business entities: •

Class: A class represents an entity of a given system that provides an encapsulated implementation of certain functionality of a given entity. These are exposed by the class to other classes as methods. Apart from business functionality, a class also has properties that reflect unique features of a class. The properties of a class are called attributes. A class is represented by a rectangle. The following diagram shows a typical class in a class diagram:

We can apply access modifiers such as public access, protected access, and private access applied to methods and attributes of a class—even to a class as well, if required. These access modifiers determine the scope of visibility of the class and its methods and attributes. We can add documentation information to a class. Notes and constraints can be added to a list of attributes. Notes contain additional information for reference while developing the system, whereas constraints are the business rules that the class must follow, and are text included in curly brace brackets.

Classes are of the following types as per their behavior, as shown in the following table: Class

Behavior

Boundary In an ideal multi tier system, the user interacts only with the boundary classes. For example, JSPs in a typical MVC architecture form the boundary classes.

•

Control

These classes typically don't contain any business functionality. However, their main task is to transfer control to the appropriate business logic class, depending on a few inputs received from the boundary classes.

Entity

These classes are those that contain the business functionality. Any interactions with back-end systems are generally done through these classes.

Interface: An interface is a variation of a class. As we saw from the previous point, a class provides an encapsulated implementation of certain business functionality of a system. An interface on the other hand provides only a definition of business functionality of a system. A separate class implements the actual business functionality. An interface shares the same features as a class; in other words, it contains attributes and methods. The only difference is that that the methods are only declared in the interface and will be implemented by the class implementing the interface. In addition to the above, there is one more element used in class diagrams:

•

Package: A package provides the ability to group together classes and/or interfaces that are either similar in nature or related. Grouping these design elements in a package element provides for better readability of class diagrams, especially complex class diagrams.

We can see a package is represented as a tabbed folder. A package can also have relationships with other packages similar to relationships between classes and interfaces.

ATM card reader

atm screen

card number accept card() eject card() read card()

prompt() accept input()

cash dispenser account account number pin balance

cash balance provide cash() provide receipt()

open() withdraw funds() deduct funds() verify funds()

EMPLOYEE MANAGEMENT

LIBRARY MANAGEMENT

ORDER PROCESSING APPLICATION

STUDENT REGISTRATION PROCESS

UML STATE TRANSITION DIAGRAM Introduction : State Transition diagram shows the life cycle of a single object, from the time it is created until it is destroyed. These diagrams are a good way to model the dynamic behavior of a class. Dynamic behavior of a class implies that the class can exist in many states. To determine whether the class is dynamic or not , one can this by looking at its attributes, as the class may behave differently with different values of that attributes. Also, relationship is a good indicator for the same.

In- depth : One can create one State Transition diagram per class. State : It is one of the possible conditions in which an object may exist. Activity : It is some behavior that an object carries out while it is in a particular state. An activity is an interruptible behavior. Entry Action : An entry action is the behavior that occurs while the object is transitioning in to the state . It is non interruptible. It happens as a part of the transition into the state. Exit Action : An exit action is similar to an entry action but it occurs as a part of the transition out of a state. Transition : It is a movement from one state to another . The set of transitions on a diagram shows how the object moves from one state to another. Event : An event is something that occurs that causes a transition from one state to another. Guard Condition : A condition that controls when a transition can or cannot occur. A guard condition is drawn along the transition line, after the event name and enclosed in square brackets. Start state and Stop state are two special states.

ATM

EMPLOYEE MANAGEMENT SYSTEM

LIBRARY MANAGEMENT SYSTEM r e q u e s t fo r b o o k is sc uh e c k va lid i ty

s tu d e n t is v a li d A v a i la b le

b o o k n o t a va il a b l e

B o o k is is s u e d

s tu d e n t is i n va li d B o o k is re tu r n e d

re q u e s t d e n ie d

Is s u e d

ORDER PROCESSING APPLICATION

UML COLLABORATION DIAGRAM INTRODUCTION : Collaboration diagrams and sequence diagrams are alternate representations of an interaction. A collaboration diagram is an interaction diagram that shows the order of messages that implement an operation or a transaction whereas a sequence diagram shows object interaction in a time based sequence. Collaboration 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 interaction or structural relationships that occur between objects and object like entities in the current model. Collaboration diagrams contain icons representing objects. You can create one or more collaboration diagrams to depict interactions for each logical package in your model. Such collaboration diagrams are themselves contained by the logical package enclosing the objects they depict. An Object specification enables you to display and modify the properties and relationships of an object. The information in a specification is presented textually. Some of this information can also be displayed inside the icons representing objects in collaboration diagrams. Use collaboration diagrams as the primary vehicle to describe interactions that express your decisions about the behavior of the system.

Relationships : A dependency relationship can be drawn from a component to another component. This type of dependency relationship means that the classes contained in the client component can inherit from , contain instances of ,use, and otherwise depend on classes that are exported from the supplier component. A dependency relationship can also be drawn from a component to an interface of another component, which means that the client component uses the operations of the other component. Also a realize relationship can be drawn from a component to an interface of another component , which means that the client component provides the operations of the other component.

COLLABORATION DIAGRAM TOOLBAR

ATM 11: enter amount 9: select transaction 5: enter pin Customer

AT M SCREEN

4: prompt for pin 8: promt for transaction

6: open account

10: prompt for amount

7: verify pin 1: ACCEPT CARD

3: INITIALISE SCREEN 12: withdraw funds 16: verify funds 17: deduct funds 2: READ CARD

USER ACCOUNT

CARD READER 15: eject cash

13: provide cash 14: provide receipt CASH DISPENSER

EMPLOYEE MANAGEMENT SYSTEM

LIBRARY MANAGEMENT SYSTEM

9: validate details

Operator

1: read barcode

student info controller

2: submit barcode

Bar code reader 4: submit

3: get details 5: validate if fine

student details 6: update

return book 10: invalid student

11: submit book code

7: update 8: book return successful

14: add record

Book details

15: add record 13: not available 12: check availibility 16: issue success

Book info controller

Message box

ORDER PROCESSING APPLICATION

STUDENT REGISTRATION PROCESS 1 : r e q u e s t fo r t h e c o u r s e 3 : s u b m i t fo r m d e t a i l s 1 1 : r e q u e s t fo r c a n c e l l a t i o n s tu d e n t

re g is tra r 2 : p r o m p t f o r fo r m s u b m i s s i o n 7 : p r o m p t f o r fe e s u b m i s s i o n 1 0 : g ra n t a d m is s io n le t t e r

1 5 : r e t u r n fe e s a ft e r d e d u c t i n g9 :c ac no cn efirl lma t ifeo ne cs hu ab rmg ei tsi o n

8 : s u b m i t fe e s

6 : r e t u r n d e t a i l s t o r4e: g foi s rtmr a rv e r i fi c a t i o n 1 3 : c o n fi r m d e t a1 i 2ls: v e r i fi c a t i o n o f d e t 1 4 : fo r w a r d s t u d e n t d e t a i l s 5 : c h e c k s t u d e n t d e t a ils

account m anager

s c r u t in y o ff i c e r

UML COMPONENT DIAGRAM Definition : Component diagrams provide a physical view of current model. A component diagram shows the organization and dependencies among software components, including source code components, binary code components and executable components . These diagrams also show the externally – visible behavior of the components by displaying the interfaces of the components . Calling dependencies among components are shown as dependency relationships between components and interfaces on other components. Here interfaces actually belong to the logical view , but they can occur both in class diagrams and in component diagrams. Component diagrams contain : • • • •

Component packages Components Interfaces Dependency relationships

One or more component diagrams can be created to depict the component packages and components at the top level of the component view , or to depict the contents of each component package. Such component diagrams belong to the component package that they depict. Component Package : Component packages represent clusters of logically related components , or major pieces of the system. Component packages parallel the role played by logical packages for class diagrams. They allow partitioning the physical model of the system . A component package can have dependencies with other component packages, components and interfaces. Component : A component represents a software module ( source code, binary code, executable, DLL, etc.) with well defined interface. The interface of a component is represented by one or several interface elements that the component provides. Components are used to show compiler and runtime dependencies, interface and calling dependencies among software modules and also show which components implement a specific class.

ATM ATM.exe

Card Reader

Cash Dispenser ATM Screen

Card Reader ATM Screen

Card Dispenser

EMPLOYEE MANAGEMENT SYSTEM E m ploy ee.ex e

P rinter A c count

Main S c reen

acc ount

M ain s creen

LIBRARY MANAGEMENT SYSTEM library.exe

Printer Card Reader

Main Screen

Main Screen

ORDER PROCESSING APPLICATION o rd e r c lie n t ex e

o rde r o p tio n s

o rd e r de t ail

o rd e r s e rve re x e

o rde r m g r o rd e r ord er it em

tra ns a c t io n m gr