Object Oriented Analysis And Design Through Uml

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

DIAGRAMS THINGS

RELATIONSHIPS 1. CLASS 2. OBJECT

STRUCTURAL

DEPENDENCY

3. COMPONANT 4. USE CASE

BEHAVIORAL GROUPING

ASSOCIATION GENARALIZATION

5. SEQUENCE 6. COLLOBORATION 7. ACTIVITY 8. AND OTHERS

ANNOTATIONAL

REALIZATION

All the modeling techniques in brief Sequence Diagrams Collaboration diagrams State Machine Diagrams

Use case diagrams

Class diagrams Object Diagrams

UML MODELS

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 Class

Diagrams Object Diagrams

Class diagram Structure & Relationships Multiplicity & behavior Navigation

DEPENDENCY

GENARALIZATION

REALIZATION

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

ASSOCIATION

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

ClassName Attributes Operations



Classes should be named using the vocabulary of the domain  

Naming standards should be created e.g., all classes are

Responsibili ties

Operations and Attributes 

Operations :The behavior of a class is represented by its operations



Attributes :The structure of a class is represented by its attributes



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

Advanced Relationships 

Ag gregatio n : 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”.



Com pos iti on : This specifies that the lifetime of the part classifier is dependent on the lifetime of the whole classifier



Inh eri tan ce : There are two ways to find

inheritance: 

Gene rali zatio n : As you move "up" the hierarchy, you achieve

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

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

Indicat Meaning or 0..1 Zero or one

If navigation is restricted, an arrowhead is added to indicate the direction of the navigation

1

One only

0..*

Zero or more

1..*

One or more

n

Only n (n > 1)

0..n

Zero to n (n> 1)

1..n

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

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

actor

system

goal

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

•select withdrawal option •specify amount

•take card

•take cash

•display withdrawal options •check card holder has Sufficient funds •eject card •prompt cardholder to take card •dispense amount •prompt cardholder to take cash •debit cardholder’s account •thank cardholder •display welcome and await next holder

Depiction of actor and usecase

Usecase1

Usecase2 actor

WARNING 

Remember that use case designs aren't the same thing as requirements. These are highlevel 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

<>

Check tutor availab

Book lesson

<>

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

A small Work out



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

Behavioral Model View Sequence Diagrams Collaboration Diagrams State Machine Diagrams 4. Activity Diagrams

1. 2. 3.

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 modeling object interactions, there will be times when a condition must be met for a message to be sent to the object.



Alternatives : Alternatives are used to designate a

mutually exclusive choice between two or more message sequences. Alternatives allow the modeling of the classic "if then

Guards

Life lines

Messages

Alternative

A small Work out



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