Visual Modeling Unified Modeling Language( Uml) | Use Case | Class (Computer Programming)

Object Oriented Analysis And design Through UML

This session

Introduction to modeling  Class diagrams  Use case diagrams  Sequence Diagrams

Introduction to Modeling
What is a model? A model is a simplification of realty. Why do we model? We build models so that we can better understand the system we are developing

How can you realize the benefits of modeling?

What is the UML…

The UML is the standard language for
Visualizing,  Specifying,  Constructing, and  Documenting

the artifacts of a software-intensive system


All the modeling techniques in brief
Sequence Diagrams Collaboration diagrams State Machine Diagrams Use case diagrams Class diagrams Object Diagrams


Component Diagrams

Activity Deployment Diagrams Diagrams

Classification of UML

Structural model view 1) class diagrams 2) object diagrams

user model view 1) use case diagrams Behavioral model view 1) sequence diagrams 2) collaboration diagrams 3) state machine diagrams 4) activity diagrams

Implementation model view 1)component diagrams

Environment model view 1) deployment diagrams

Structural model view
Diagrams Object Diagrams

Class diagram
Structure & Relationships Multiplicity & behavior Navigation




One Class uses the nformation of other One class specifies A contract that other Class will carru out

Objects of one thing are Connected to objects Of another

Relationship between General kind of class And a more specific Kind of class

Structure of a Class

A class is a collection of objects with common structure, common behavior, common relationships and common semantics Classes should be named using the vocabulary of the domain
 

ClassName Attributes Operations Responsibiliti es

Naming standards should be created e.g., all classes are singular nouns starting with a capital letter

Operations and Attributes

Operations :The behavior of a class is represented by its

Attributes :The structure of a class is represented by its

Responsibilities: It is a contract or an obligation of a class.

Advanced Relationships

Aggregation: It is a special kind of association and is used when one
class (whole) consists of 1 or more smaller classes (parts). It shows has-a relationship between the ”whole” and its “parts”.

Composition : This specifies that the lifetime of the part classifier is dependent on the lifetime of the whole classifier Inheritance : There are two ways to find


greater generalization . You move up toward Mammal to generalize that dogs, cats, and horses all bear live young.  Specialization: As you move "down" the hierarchy you specialize. Thus, the cat specializes Mammal in having claws (a characteristic) and purring (a behavior

Generalization: As you move "up" the hierarchy, you achieve

Multiplicity and Navigation

Multiplicity defines how many objects participate in a relationship  Multiplicity is the number of instances of one class related to ONE instance of the other class  For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship If navigation is restricted, an arrowhead is added to indicate the direction of the navigation

Indicato Meaning r
0..1 1 0..* 1..* n 0..n Zero or one One only Zero or more One or more Only n (n > 1) Zero to n (n> 1)


One to n (n > 1)

A small Work out

Try to make Class diagram for a banking system ????????? NOW

Building a system

user model view
Use case Diagrams

What's up in usecases??????
Use Case Diagrams

An actor is a person, organization, or external system that plays a role in one or more interactions with your

Behavior or USE CASE

Relationships Between Actors & usecases

Introduction to USE CASE diagrams
What is a use case diagram?? A use case diagram is a type of behavioral diagram. whose purpose is to present a graphical overview of the functionality provided by a system in terms of actors, their goals (represented as use cases), and any dependencies between those use cases What do they represent? They represent the functionality of the system from user’s point of view who will be using the system? ACTOR what will they be using it to do? ? USECASE

Who is an actor???
 

For example, a bank cardholder might need to use an ATM to get cash out of their account. It is as simple as that. Actors don't have to be people. They can be other systems. For example, the ATM may need to connect to the cardholder's bank. External systems that interact in a use case are also actors.




What Is A Use Case Scenario?
 Some examples of use case scenarios.

When a cardholder tries to withdraw cash from an ATM, it doesn't always necessarily turn out the same way.
  

Sometimes he gets his money. Other times he might have insufficient funds. Or the ATM may be out of cash

The outcome is different, depending on circumstances, but they all relate to the same functional goal . that is, they're all triggered by the same need and all have the same starting point.

Capturing Use Case Scenarios with Essential Use Case Descriptions
 

Don’t go into technical aspect of the design We first need to understand what the business logic of the interactions are, so we can focus on satisfying the business goal of the use case. Instead of saying “the user presses the enter button”, we say “the user confirms their choice”, for example. split the actions into columns, one for each actor and one for the system. Then we can see at a glance not only the order of events in a use case scenario, but also exactly who is doing what. An essential use case clearly shows the order of events and the responsibilities of the actor(s) and actor(s) system in a single use case scenario, without committing to technical design decisions

•select withdrawal option •specify amount

•display withdrawal options •check card holder has Sufficient funds •eject card

•take card

•prompt cardholder to take card •dispense amount

•take cash

•prompt cardholder to take cash •debit cardholder’s account •thank cardholder

•display welcome and await next holder

Depiction of actor and usecase


Usecase2 actor


Remember that use case designs aren't the same thing as requirements. These are high-level interaction designs. if we mix them up with real requirements stuff the system really has to do ,then we can get bogged down in the design decisions we make early on.

Documenting Use Cases
  

A flow of events document is created for each use cases Written from an actor point of view Details what the system must provide to the actor when the use cases is executed Typical contents
How the use case starts and ends  Normal flow of events  Alternate flow of events  Exceptional flow of events

Relationships Between Use Cases
Book assesment

Including Use Cases: When two or more use cases include the flow of another use case, they are said to include that use case's flow. Extending Use Cases: <<extend>> relationship means that the flow of the extending use case is only included under specific conditions

<<includes >>

Check tutor availab

Book lesson

<<includes >>

View Product <<extends >> Check Login
Review Product

<<extends >>

Summary of use cases
Identify your actors: who will be using the system? 2. Identify their goals: what will they be using the system to do? 3. Identify key scenarios: in trying to achieve a specific goal, what distinct outcomes or workflows might we need to consider? 4. Describe in business terms the interactions between the actor(s) and the system for a specific scenario 5. Create a UI prototype that clearly communicates the scenario to technical and 6. non-technical stakeholders 7. Do a high-level OO design for the scenario 8. Implement the design in code 9. Get feedback from your users . ideally through structured acceptance testing 10. Move on to the next scenario or use case (.rinse and repeat.)

A small Work out

Try to make Use case diagram for a banking system ????????? NOW

Behavioral Model View
1. 2. 3.

Sequence Diagrams Collaboration Diagrams State Machine Diagrams 4. Activity Diagrams

Sequence Diagrams

The sequence diagram is used primarily to show the interactions between objects in the sequential order that those interactions occur. useful to communicate how the business currently works by showing how various business objects interact. business-level sequence diagram can be used as a requirements document to communicate requirements for a future system implementation.

Notation Basics
 

Lifelines: Lifelines are drawn as a box with a dashed line descending from the
center of the bottom edge .The lifeline's name is placed inside the box.

Messages: The first message of a sequence diagram always starts at the top
and is typically located on the left side of the diagram for readability. Subsequent messages are then added to the diagram slightly lower then the previous message.

Guards: Guards are used throughout UML diagrams to control flow. When Alternatives : Alternatives are used to designate a mutually exclusive
the classic "if then else" logic

modeling object interactions, there will be times when a condition must be met for a message to be sent to the object.

choice between two or more message sequences. Alternatives allow the modeling of

Life lines




A small Work out

Try to make Sequence diagram for a banking system ????????? NOW

Sign up to vote on this title
UsefulNot useful