state & sequence diagrams - mobile bank

Sequence Diagrams

                    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.

BEHAVIORAL MODEL - MOBILE BANK

Consider the example of a verterinary system. Animals served, such as dogs and birds, are tracked along with their owners. The following diagram models a potential solution. Since dogs and birds are "a kind of" animal, we use a Generalization relationship.

To validate your model, you can apply real-world data into instances of the classes. In fact, there is a diagram for precisely this task, the Object Diagram.

BEHAVIORAL MODEL:

State chart Diagrams

             State chart diagrams, also referred to as State diagrams, are used to document the various modes ("state") that a class can go through, and the events that cause a state transition. For example, your television can be in the off state, and when the power button is pressed, the television goes into the on state. Pressing the power button yet again causes a state transition from the on state to the off state. In comparison the other behavioral diagrams which model the interaction between multiple classes, State diagrams typically model the transitions within a single class. 

State	The State notation marks a mode of the entity, and is indicated using a rectangle with rounded corners, and the state name written inside.
Transition	A Transition marks the changing of the object State, caused by an event. The notation for a Transition is an arrow, with the Event Name written above, below, or alongside the arrow.
Initial State	The Initial State is the state of an object before any transitions. For objects, this could be the state when instantiated. The Initial State is marked using a solid circle. Only one initial state is allowed on a diagram.
Final State	End States mark the destruction of the object whose state we are modeling. These states are drawn using a solid circle with a surrounding circle.

Here is an example State Diagram that models that status of a user's account in a Bug Tracker system:

elements on a Class diagram - mobile bank

Class Diagrams

        Class diagrams identify the class structure of a system, including the properties and methods of each class. Also depicted are the various relationships that can exist between classes, such as an inheritance relationship. The Class diagram is one of the most widely used diagrams from the UML specification. Part of the popularity of Class diagrams stems from the fact that many CASE tools, such as Rational XDE, will auto-generate code in a variety of languages, including Java, C++, and C#, from these models. These tools can synchronize models and code, reducing your workload, and can also generate Class diagrams from object-oriented code, for those "code-then-design" maintenance projects.

Notation

The elements on a Class diagram are classes and the relationships between them

Class	Classes are the building blocks in object-oriented programming. A Class is depicted using a rectangle divided into three sections. The top section is the name of the Class. The middle section defines the properties of the Class. The bottom section lists the methods of the class.
Association	An Association is a generic relationship between two classes, and is modeled by a line connecting the two classes. This line can be qualified with the type of relationship, and can also feature multiplicity rules (eg. one-to-one, one-to-many, many-to-many) for the relationship.
Composition	If a class cannot exist by itself, and instead must be a member of another class, then that class has a Composition relationship with the containing class. A Composition relationship is indicated by a line with a filled diamond.
Dependency	When a class uses another class, perhaps as a member variable or a parameter, and so "depends" on that class, a Dependency relationship is formed. A Dependency relationship is indicated by a dotted arrow.
Aggregation	Aggregations indicate a whole-part relationship, and are known as "has-a" relationships. An Aggregation relationship is indicated by a line with a hollow diamond.
Generalization	A Generalization relationship is the equivalent of an inheritance relationship in object-oriented terms (an "is-a" relationship). A Generalization relationship is indicated by an arrow with a hollow arrowhead pointing to the base, or "parent", class.

LOGICAL DESIGN: - MOBILE BANK

         This project was developed in a modular fashion. The whole Project is divided into seven objects. This work of object is done based on the various activities that are to be carried out in the system. Which altogether result in obtaining intelligent outcomes? The objects are:

• Admin
• Customer
• Admin:   

                Admin is the person who is controlling the entire site by doing the required  operations i.e., uploading files, providing space to companies, updating accounts, sending sms, etc., Admin will generate the reports to hold complete details of transactions

Customer:

           The customer is made comfortable by not being asked to register completely for his/her first visit; he/she can enter his/her e-mail Id for visiting site. However to use the  , the customer must register themselves. The customer may choose the category and time to receive Adds and can get information, download as well. The payment for the SMS will be adding to his/her account automatically. The customer may give feedback   to the company directly.

Text Notation & Scenario of mobile bank

The following image shows how these three basic elements work together to form a use case diagram.

Text Notation

Behind each Use Case is a series of actions to achieve the proper functionality, as well as alternate paths for instances where validation fails, or errors occur. These actions can be further defined in a Use Case description. Because this is not addressed in UML 1.4, there are no standards for Use Case descriptions. However, there are some common templates you can follow, and whole books on the subject writing of Use Case descriptions . 

Scenario

name: Registration

Actors: User, Admin

Flow Of Control: 

1)      Fill the registration form

2)      User will check the availability for ID

3)      Enroll registration details with ID and Password.

Scenario name: Login

Actors: User, Admin

Flow Of Control:

1)      User enter ID and Password

2)      Admin will check for authentication

3)      Generates the page with inbox or with error

Scenario name: Browse for Mobile information

Actors: Viewer

Flow of Control:

1)      User can check balance amount

2)      User can add friends.

3)      User can view profile.

4)      User can do online money transfer.

5)      User can view friends.

Scenario name: Get paid to the user

Actors: Viewer, Admin

Flow of Control:

1)      User checks the account to get paid

2)      User will select to pay if the amount.

Scenario name: Update customer account

Actors: Admin

Flow of Control:

1)      Admin will subtract from the customer

2)      Admin will add the amount to the customer account

Use case diagram for admin - Mobile bank project

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

Scenarios & Use case diagrams - Mobile Bank

SCENARIOS

           It is an instance of a use case describing concrete set of actions.  Scenarios are used as examples  for illustrating common cases.  Their focus is on understandability.

Use cases are used to describe all possible cases.  Their focus is on completeness. We describe a scenario using the template with three fields:

Ø     The name of the scenario enables us to refer to it unambiguously.

Ø     The participating actor instances field indicates which actor instances are involved in this  Scenario.

Flow of events of a scenario describes the sequence of events step by step.

USE CASE MODEL OF THE SYSTEM

Use Case Diagrams       

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

Use Cases extend beyond pictorial diagrams. In fact, text-based use case descriptions are often used to supplement diagrams, and explore use case functionality in more detail.