Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Subject: Object Oriented Analysis and Design
B.Tech III Year II-Semester
Computer Science &Engineering
Table of Contents
Unit-I: UML , Unified Process
UML
• What is UML
• The Birth of UML
• The Future of UML
• UML Structure
•...
Learning Objectives
At the end of this unit the student will be in a position to:
• Understanding What is UML and what is ...
INTRODUCTION
• UML is graphical Language
– A picture is worth a thousand words
• UML diagrams enable software engineers to...
5
What is UML?
The Unified Modeling Language (UML) is a standard language for
Specifying Visualizing Constructing Document...
UML is a graphical language for
• Visualizing
• Specifying
• Constructing
• Documenting the artifacts of a software system...
The Birth of UML
• In 1965 the first object-oriented (OO) programming language, Simula I, was
introduced.
• Almost immedia...
UML Structure
The UML Structure consists of
• Building Blocks : Basic UML modeling elements
Example: Things, Relationships...
The UML Building Blocks
UML encompasses three kinds of building blocks:
1.Things
2.Relationships
3.Diagrams
 Things: are ...
Structural things
The Structural things are the nouns of UML models.
These are the static parts of a model.
There are seve...
4. Use case: Is a description of a set of sequence of actions that a system
performs
Example:
5. Active Class: is a class ...
Behavioral Things
• These are the dynamic parts of UML models.
• These are the verbs of a model.
• There are two types of ...
Grouping things
• These are the organizational parts of UML models.
• There is one primary kind of grouping thing
Package:...
 Relationships
• Are used to tie the things together
• There are four kinds of relationships in the UML
1. Dependency
2. ...
Association: is a structural relationship that describes a set of links
Example:
Generalization: is a specialization/gener...
Realization : is a semantic relationship between classifiers, where in one
classifier specifies a contract that another cl...
Diagrams: A diagram is the graphical representation of a set of elements.
UML has nine diagrams
UML Diagrams
Structural/St...
Structural/static diagrams:
The UML has four Structural diagrams which gives the static aspects of a system
1. Class diagr...
4. State chart diagram: shows a state machine consisting of states, transitions,
events and activities. these addresses th...
Common Mechanisms in the UML
UML has four common mechanisms
• Specifications
• Adornments
• Common divisions
• Extensibili...
Common Divisions:
There is a common division of class and object. A class is an abstraction, an
object is one concrete man...
Extensibility Mechanisms
The UML’s extensibility mechanisms include
• Stereotypes
• Tagged values
• Constraints
Stereotype...
Example for common mechanisms
Architecture: The architecture of a system can best be described by five
interlocking views.
Use case View: encompasses the Use cases that describe the behavior of the
system as seen by its end users
Design view: en...
Unified process
Defines Who is doing What, When to do it, and How to reach a certain goal.
The Unified Process is a softwa...
The birth of UP
• Some roots in the “Spiral Model ” of Barry Boehm
• Core initial development around 1995-1998
• Large Can...
Creating the Unified Process
Rational Unified Process 5.0
1998
Rational Objectory Process 4.1
1996-1997
Objectory Process ...
Rational Unified Process (RUP)
• Commercial version of Unified Process from IBM
– A specific commercial subclass that both...
UP axioms
UP has three basic axioms
1. Use case driven
2. Architecture-centric
3. Iterative and incremental
Use-case drive...
• Architecture centric
– Embodies the most significant aspects of the system
– View of the whole design with the important...
UP Structure
UP Structure cont…
The Unified Process is a software Development Process
The Unified process repeats over a series of cycl...
Unified Process Phases
• Inception
– Establish the business case for the system, define risks, obtain 10%
of the requireme...
The Phases/Workflows of the Unified Process
Phase is Business context of a step
Workflow is
Technical
context of a step
The Phases/Workflows of the Unified Process
NOTE: Most
of the
requiremen
ts work or
workflow is
done in the
inception
phas...
Inception Phase Activities
• Project Initiation
• Start with an idea
• Specify the end-product vision
• Analyze the projec...
 Elaboration Activities
All but completing the requirements workflow
Performing virtually the entire analysis workflow
St...
The Phases/Workflows of the Unified Process
NOTE: Most
of the
implementat
ion work or
workflow is
done in
construction
How...
Construction Essential Activities
• Complete component development and testing (beta release)
• Assess product releases ag...
Requirements workflow
• Primary focus
– To determine the client’s needs by eliciting both functional and
nonfunctional req...
Requirement workflow Detail:
Architect
Prioritize Use cases
Use case Specifier
Detail a use case
User interface Designer
P...
Requirements workflow
A workflow detail shows us the workers and activities involved in a particular
Workflow
We can make ...
Functional Requirements Example
In ATM System following are some of the functional requirements
1. Checking validity of th...
Use case modeling
Use case modeling is a form of requirements engineering
Use case modeling proceeds as follows
• Find a c...
Business model
[ or domain model]
Requirements model
Feature list
System Analyst
Find Actors
and Use cases
Use case model ...
UP activity: Find actors and Use cases
Business Model: The total set of activities needed to produce a result of
perceived...
Identifying Actors
• Who or what uses the system
• What roles do they play in the interaction
• Who maintains the system
•...
Identifying Use cases
• What functions will a specific actor want from the system
• Does the system store and retrieve inf...
50
CMSC 345, Version 9/07
S. Mitchell
1
Withdraw
Money
2
Deposit
Money
3
Transfer
Money
4
Check
Balance
ATM System
Bank
Cu...
Simple Use Case Diagram
Withdraw
from a Course
Apply for
Admission
Student
Enroll in
the University
Enroll in
a Course
Adm...
Use case model
[outlined]
Requirements model
Project Glossary
Use case Specifier
Detail a Use cases Use case
[detailed]
UP...
Use case Specification
• A use case describes what a system does but it does not specify how it does it.
• You can specify...
Requirements tracing
• Requirements tracing links the requirements in the requirements model to the use
case model.
• We a...
Traceability Matrix: User Needs versus Features
When to apply use case modeling
• Use case modeling is good at capturing functional requirements but poor at
capturing the...
Advanced Use case Modeling
In advanced use case modeling we will discuss about the following relationships
Actor Generaliz...
<<includes>>: A relationship between use cases that lets one use case includes behavior
from another use case
Example: <<i...
Example:
The extension use case
Use case diagrams example: Cellular telephone system
Hints and tips for writing use cases
• Keep use cases short and simple
• Focus on what not on how
• Avoid functional decom...
Summary:
• The Unified Modeling Language is a standard graphical language for
modeling
UML is composed of three building b...
• The Unified process is a software development process
• Rational Unified Process is an extension to the Unified Process
...
• Most of the requirements workflow occurs in the inception and
elaboration phase s of the UP project life cycle
• There a...
Quiz
1) Which of the following is iterative, incremental, use case driven and architecture
centric?
(a) V-method (b) UML (...
Quiz
4) Which statements are true for an Actor?
a) an actor is a role a user plays with respect to the system
b)generaliza...
Quiz
7) Which of the following statements are true about use-case driven
development?
a) Requirements are primarily captur...
Key:
1) d
2) a
3) d
4) a, c
5) b, c, e
6) b
7) d
8) c
THANK YOU
Upcoming SlideShare
Loading in …5
×

Ooad content development of unit i

133 views

Published on

Ooad content development of unit i

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

Ooad content development of unit i

  1. 1. Subject: Object Oriented Analysis and Design B.Tech III Year II-Semester Computer Science &Engineering
  2. 2. Table of Contents Unit-I: UML , Unified Process UML • What is UML • The Birth of UML • The Future of UML • UML Structure • UML Building Blocks • UML Common Mechanisms • Architecture Unified Process • What is Unified Process • The Birth of UP • Rational Unified Process • Up Structure • UP Phases • Requirements Workflow • Use case Modeling
  3. 3. Learning Objectives At the end of this unit the student will be in a position to: • Understanding What is UML and what is Unified Process • Understanding requirements workflow • Understand the main principles of good Object Oriented design • Use diagram notation for use cases • Gain a working knowledge of UML through rational rose Enterprise Edition. • Describe the object-oriented software development process, including object- oriented methodologies and workflows. • Analyze system requirements to determine the use cases and domain model of the problem domain. • List the factors that make a well-designed UML model. • List ways of minimizing inconsistencies in models and identify methods of coordinating models in UML.
  4. 4. INTRODUCTION • UML is graphical Language – A picture is worth a thousand words • UML diagrams enable software engineers to communicate quickly and accurately • The Unified Process is a modeling technique – A model is a set of UML diagrams that represent various aspects of the software product we want to develop • UML stands for unified modeling language – UML is the tool that we use to represent (model) the target software product
  5. 5. 5 What is UML? The Unified Modeling Language (UML) is a standard language for Specifying Visualizing Constructing Documenting Communications
  6. 6. UML is a graphical language for • Visualizing • Specifying • Constructing • Documenting the artifacts of a software system The UML is a language for visualizing : A bunch of graphical Symbols are used. Rather, behind each symbol in the UML notation is a well defined semantics The UML is a language for Specifying :The UML addresses the specification of all the important analysis, design, and implementation decisions The UML is a language for Constructing: the UML is not a visual language but its models can be directly connected to a variety of programming languages. The UML is a language for Documenting: The UML is used to prepare document At the end of each phase
  7. 7. The Birth of UML • In 1965 the first object-oriented (OO) programming language, Simula I, was introduced. • Almost immediately interest in OO design began to rapidly grow. • This led to the emergence of numerous competing OO design methods • With all these design methods came numerous modeling languages. • By the early 90’s there were 50+ distinct OO modeling languages. • Darwinian forces in the marketplace led to three dominate methods, each having its own modeling language • Object-oriented Analysis & Design (OOAD) – Grady Booch • The Object Modeling Technique (OMT) – Jim Rumbaugh • The Object-oriented Software Engineering method (OOSE) – Ivar Jacobson • Each one had its strengths and weaknesses • Booch (OOAD) good at low-level design • Jacobson (OOSE) good at high-level design • Rumbaugh (OMT) good at the middle ground
  8. 8. UML Structure The UML Structure consists of • Building Blocks : Basic UML modeling elements Example: Things, Relationships and Diagrams • Common Mechanisms :Common UML representations to achieve some goals Example: Specification, Adornments, Common divisions, Extensibility mechanisms • Architecture: The UML view of system architecture UML Building Blocks Common Mechanisms Architecture
  9. 9. The UML Building Blocks UML encompasses three kinds of building blocks: 1.Things 2.Relationships 3.Diagrams  Things: are the abstractions that are first-class citizens in a model There are four kinds of things in the UML. Things Structural things Behavioral things Grouping things Annotational things
  10. 10. Structural things The Structural things are the nouns of UML models. These are the static parts of a model. There are seven kinds of structural things. 1. Class : set of objects that share the same attributes, operations, relationships and Semantics. Example: 2. Interface : Is a collection of operations that specify a service of a class or component. Example: ispelling 3. Collaboration : is a society of roles and other elements that work together to provide some cooperative behavior Window Origin size Open() Close() Move() Display() Chain of responsibility Example:
  11. 11. 4. Use case: Is a description of a set of sequence of actions that a system performs Example: 5. Active Class: is a class whose objects own one or more processes or threads. Example: 6. Component: is a physical and replaceable part of a system that conforms to and provide the realization of a set of interfaces Example: 7. Node : is a physical element that exists at run time and represents a computational resources. Example: Place order Event Managed Suspend() Flush() Orderform.java server
  12. 12. Behavioral Things • These are the dynamic parts of UML models. • These are the verbs of a model. • There are two types of behavioral things 1. An Interaction : is a behavior that comprises a set of messages exchanged among a set of objects. Example: 2. A State machine : is a behavior that specifies the sequences of states an object or an interaction goes through during its lifetime in response to events. Example: display waiting
  13. 13. Grouping things • These are the organizational parts of UML models. • There is one primary kind of grouping thing Package: is a general purpose mechanism for organizing elements into groups. Example: Annotational Things • These are explanatory parts of UML models Example: Note Note: is simply a symbol for rendering constraints and comments attaches to an element Business rule
  14. 14.  Relationships • Are used to tie the things together • There are four kinds of relationships in the UML 1. Dependency 2. Association 3. Generalization 4. Realization Dependency: is a semantic relationship between two things in which a change to one thing may affect the semantics of the other thing Example:
  15. 15. Association: is a structural relationship that describes a set of links Example: Generalization: is a specialization/generalization relationship in which objects of the specialized elements(the child ) are substitutable for objects of the generalized elements(the parent) Example:
  16. 16. Realization : is a semantic relationship between classifiers, where in one classifier specifies a contract that another classifier guarantees to carry out. Example:
  17. 17. Diagrams: A diagram is the graphical representation of a set of elements. UML has nine diagrams UML Diagrams Structural/Static Behavioral/Dynamic Class Object Component Deployment Use case Sequence Collaboration Activity State m/c
  18. 18. Structural/static diagrams: The UML has four Structural diagrams which gives the static aspects of a system 1. Class diagram: shows a set of Classes, interfaces and collaborations and their relationships. 2. Object diagram: shows a set of objects and their relationships. object diagrams represents static snapshots of instances of the things found in class diagrams. 3. Component diagram: shows the organizations and dependencies among a set of components. This diagram addresses the static implementation view of a system. 4. Deployment diagram: shows the configuration of run-time processing nodes and the components that live on them. This diagram addresses the static deployment view of an architecture. Behavioral/ Dynamic Diagrams: 1. Use case diagram: shows a set of use cases, actors and their relationships. these diagrams address the static use case view of a system. Use case diagrams are used to modeling the behavior of a system. 2. Sequence diagram: is a kind of interaction diagram shows an interaction the sequence diagram emphasizes the time-ordering of messages. 3. Collaboration diagram: is also an interaction diagram that emphasizes the structural organization of the objects that send and receive messages.
  19. 19. 4. State chart diagram: shows a state machine consisting of states, transitions, events and activities. these addresses the dynamic view of a system 5. Activity diagram: is a special kind of state chart diagram that shows the flow from activity to activity with in a system.
  20. 20. Common Mechanisms in the UML UML has four common mechanisms • Specifications • Adornments • Common divisions • Extensibility Mechanisms Specifications: the UML is more than just a graphical language rather, behind every part of its graphical notation there is a specification that provides syntax and semantics of the building block Example: Class Adornments: are textual or graphical items that are added to an element’s basic notation and are used to visualize details from the element’s specification. Example: Public { protected private Transaction +execute() +rollback #priority -timestamp()
  21. 21. Common Divisions: There is a common division of class and object. A class is an abstraction, an object is one concrete manifestation of that abstraction. Example: 2 objects { 1 Class There is a separation of interfaces and implementation. An interface declares a contract and an implementation represents one concrete realization of that contract. Example: Iunknown Ispelling The component that implements two interfaces Customer Name Address Phone no Jan: Customer :customer Spellingwizard.dll
  22. 22. Extensibility Mechanisms The UML’s extensibility mechanisms include • Stereotypes • Tagged values • Constraints Stereotypes: extends the vocabulary of the UML, allowing you to create new kinds of building blocks that are derived from existing ones. Example: <<extends>> <<includes>> in Use case diagram Tagged values: extends the properties of a UML building block, allowing you to create new information in that element’s specification Example: Constraints: extends the semantics of a UML building block, allowing you to add new rules or modify existing ones. All additions should be done in order {orderd} EventQueue { version=3.2 Author= egb} EventQueue Add() Remove()
  23. 23. Example for common mechanisms
  24. 24. Architecture: The architecture of a system can best be described by five interlocking views.
  25. 25. Use case View: encompasses the Use cases that describe the behavior of the system as seen by its end users Design view: encompasses the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution. This view primarily supports the functional requirements of the system Process view: encompasses the threads and processes that form the system’s concurrency and synchronization mechanisms. Implementation view: encompasses the components and files that are used to assemble and release the physical system Deployment view: encompasses the nodes that form the system’s hardware topology on which the system executes.
  26. 26. Unified process Defines Who is doing What, When to do it, and How to reach a certain goal. The Unified Process is a software development process A software development process is the set of activities needed to transform a user’s requirements into a software system User’s requirements Software System The Unified process is more than a single process. The Unified process is a component based process It uses UML when preparing all blueprints of the software system. Unified process is use-case driven, architecture-centric, and iterative and Incremental process. Software development process
  27. 27. The birth of UP • Some roots in the “Spiral Model ” of Barry Boehm • Core initial development around 1995-1998 • Large Canadian Air Traffic Control project as test bed • Philippe Kruchten chief architect of UP/RUP • Rational Corporation had commercial product in mind (RUP, now owned by IBM) but also reached out to public domain (UP)
  28. 28. Creating the Unified Process Rational Unified Process 5.0 1998 Rational Objectory Process 4.1 1996-1997 Objectory Process 1.0-3.8 1987-1995 Ericsson Approach Rational Approach IBM Approach Unified Process 1998 OO Approach
  29. 29. Rational Unified Process (RUP) • Commercial version of Unified Process from IBM – A specific commercial subclass that both extends and overrides the features of the Unified Process • Supplies all of the standards, tools, and other necessities that are not included in the Unified Process • RUP is a method of managing OO Software Development • It can be viewed as a Software Development Framework which is extensible and features: – Iterative Development – Requirements Management – Component-Based Architectural Vision – Visual Modeling of Systems – Quality Management – Change Control Management
  30. 30. UP axioms UP has three basic axioms 1. Use case driven 2. Architecture-centric 3. Iterative and incremental Use-case driven – Utilizes use case model to describe complete functionality of the system Use Cases bind these workflows together Requirements Analysis Design Implementation Test
  31. 31. • Architecture centric – Embodies the most significant aspects of the system – View of the whole design with the important characteristics made more visible – Expressed with class diagram UP is an Iterative and incremental process – Way to divide the work – Iterations are steps in the process, and increments are growth of the product – The basic software development process is iterative • Each successive version is intended to be closer to its target than its predecessor
  32. 32. UP Structure
  33. 33. UP Structure cont… The Unified Process is a software Development Process The Unified process repeats over a series of cycles making up the life of a system.  Each cycle consists of four phases Inception: a good idea is developed into a vision of the end product Elaboration: system architecture is designed Construction: the product is built Transition: the product is released  The several core workflows in Unified process takes place over the four phases Requirement workflow: describes how to capture the requirements Analysis workflow: analyzes the requirements by refining and structuring them Design workflow: describes the design model Implementation workflow: Describes the implementation model Test workflow: describes the test model
  34. 34. Unified Process Phases • Inception – Establish the business case for the system, define risks, obtain 10% of the requirements, estimate next phase effort. • Elaboration – Develop an understanding of the problem domain and the system architecture, risk significant portions may be coded/tested, 80% major requirements identified. • Construction – System design, programming and testing. Building the remaining system in short iterations. • Transition – Deploy the system in its operating environment. Deliver releases for feedback and deployment. Inception Elaboration Construction Transition
  35. 35. The Phases/Workflows of the Unified Process Phase is Business context of a step Workflow is Technical context of a step
  36. 36. The Phases/Workflows of the Unified Process NOTE: Most of the requiremen ts work or workflow is done in the inception phase. However some is done later.
  37. 37. Inception Phase Activities • Project Initiation • Start with an idea • Specify the end-product vision • Analyze the project to assess scope • Work the business case for the project including overall costs and schedule, and known risks • Identify Stakeholders • Obtain funding • Project Planning • Build Team • Define initial iteration • Assess project risks and risk mitigation plan
  38. 38.  Elaboration Activities All but completing the requirements workflow Performing virtually the entire analysis workflow Starting the design workflow by performing the architecture design Performing any construction workflows needed for prototypes to eliminate risks Analyze the problem domain. Define, validate and baseline the architecture Refine the Vision to understand the most critical Use Cases Create and baseline iteration plans for construction phase. Refine the development business case Put in place the development environment, Develop a project plan and schedule.
  39. 39. The Phases/Workflows of the Unified Process NOTE: Most of the implementat ion work or workflow is done in construction However some is done earlier and some later.
  40. 40. Construction Essential Activities • Complete component development and testing (beta release) • Assess product releases against acceptance criteria for the vision. (Unit, Integration, Functional and System testing) • Integrate all remaining components and features into the product • Assure resource management control and process optimization Transition phase Essential Activities • Finalize end-user support material • Test the deliverable product at the development site • Validate beta test to assure user expectations met • Fine-tune the product based on feedback • Perform parallel operation of replaced legacy system
  41. 41. Requirements workflow • Primary focus – To determine the client’s needs by eliciting both functional and nonfunctional requirements • Gain an understanding of the application domain • Described in the language of the customer • List candidate requirements – textual feature list • Understand system context – domain model describing important concepts of the context – business modeling specifying what processes have to be supported by the system using Activity Diagram • Capture functional and nonfunctional requirements – Use Case Model • Supplementary requirements – physical, interface, design constraints, implementation constraints
  42. 42. Requirement workflow Detail: Architect Prioritize Use cases Use case Specifier Detail a use case User interface Designer Prototype User Interface System Analyst Find Actors and Use cases Structure the Use case model
  43. 43. Requirements workflow A workflow detail shows us the workers and activities involved in a particular Workflow We can make a simple extension to the UP requirements workflow to add the following new tasks • Find functional requirements • Find non-functional requirements • Prioritize requirements • Trace requirements to Use cases Purpose of the requirements workflow The essential purpose of the requirements workflow is to aim development toward the right system This is achieved by describing the system requirements. Requirements can tell us what should be developed but not how we should Develop. There are two types of requirements 1. Functional : System functions 2. Non functional: a constraint on the system
  44. 44. Functional Requirements Example In ATM System following are some of the functional requirements 1. Checking validity of the inserted ATM card 2. Validate pin number entered by the customer Non-Functional requirements Example 1. ATM system shall validate an ATM card in three seconds or less 2. ATM system shall validate PIN in three seconds or less Finding Requirements: Requirements come from the context of the system you are trying to model This context include • Direct users of the system • Other stakeholders(e.g. managers, maintainer, installer) • Other systems with which the system interacts • Hardware devices with which the system interacts • Legal constraints • Technical constraints • Business goals
  45. 45. Use case modeling Use case modeling is a form of requirements engineering Use case modeling proceeds as follows • Find a candidate system boundary • Find the Actors • Find the Use cases • Iterate until Use cases, actors, and system boundary are stable Use case Model Is a way of capturing requirements There are four components in use case model • System Boundary: a box drawn around the use cases • Actors: roles played by the people or things that use the system • Use cases: things that the actors can do with the system • Relationships: meaningful relationships between actors and Use cases
  46. 46. Business model [ or domain model] Requirements model Feature list System Analyst Find Actors and Use cases Use case model (outlined) UP activity: Find actors and Use cases Project Glossary
  47. 47. UP activity: Find actors and Use cases Business Model: The total set of activities needed to produce a result of perceived and measurable value to an individual customer of a business Requirements model: provides useful input to the use case modeling process Feature list: this is a set of candidate requirements What are Actors • An actor represents a coherent set of roles that users of use cases play when interacting with these use cases. • Typically, an actor represents a role that a human, a hardware device, or even another system plays with a system • Actors are always external to the system • Actors interact directly with the system • Actors represents roles that people and things play in relation to the system Example:
  48. 48. Identifying Actors • Who or what uses the system • What roles do they play in the interaction • Who maintains the system • What other systems interact with this system What are Use cases • A use case is a description of a set of sequence of actions that a system performs to yield an observable result of value to an actor Example: • Use cases are always started by an actor • Use cases are always written from the point of view of the actors Place order
  49. 49. Identifying Use cases • What functions will a specific actor want from the system • Does the system store and retrieve information • What happens when the system changes state • Do Any external events effect the system • Does the system interact with any external system • Does the system generate any reports Use case diagram Use case diagrams are central to modeling the behavior of a system, a subsystem, or a class. Each one shows a set of use cases and actors and their relationships. Example:
  50. 50. 50 CMSC 345, Version 9/07 S. Mitchell 1 Withdraw Money 2 Deposit Money 3 Transfer Money 4 Check Balance ATM System Bank Customer Customer Accounts Database primary actor role system name system boundary secondary actor use case <<Customer Accounts Database>> alternative actor notation stereotype association
  51. 51. Simple Use Case Diagram Withdraw from a Course Apply for Admission Student Enroll in the University Enroll in a Course Admissions
  52. 52. Use case model [outlined] Requirements model Project Glossary Use case Specifier Detail a Use cases Use case [detailed] UP activity: Detail a Use case
  53. 53. Use case Specification • A use case describes what a system does but it does not specify how it does it. • You can specify the behavior of a use case by describing a flow of events in text clearly enough for an outsider to understand it easily. The flow of events include  How and when the use case starts and ends  When the use case interacts with the actors and what objects are exchanged  The basic flow and alternative flows of the behavior Example: in the context of ATM system consider the use case Validate User Main flow of Events: The Use case starts when the system prompts the Customer for a PIN number. The customer can now enter a PIN number via the keypad. The customer commits the entry by pressing the Enter button. the system then checks this PIN number to see if it is valid. If the PIN number is Valid, the system acknowledges the entry, thus ending the use case. Exception flow of events: The customer can cancle a transtion at any time by pressing the cancel button, thus restarting the use case.No changes are made to the customer’s account. Exception flow of events: If the customer enters an invalid PIN number, the use case restarts.
  54. 54. Requirements tracing • Requirements tracing links the requirements in the requirements model to the use case model. • We are having modeling tools to trace the requirements Example: RequsitePro • We can also use requirements traceability matrix to trace the requirements Traceability matrix: It is simply a grid with the ID numbers of individual requirements or user needs down one axis, and use case names or features along the other. A cross is put in all cells where a use case or feature and user needs intersect. Example matrix:
  55. 55. Traceability Matrix: User Needs versus Features
  56. 56. When to apply use case modeling • Use case modeling is good at capturing functional requirements but poor at capturing the non-functional requirements Use cases are the best choice for requirements capture when  The system is dominated by Functional requirements  The system has many types of users  The system has many interfaces Example: database systems Use cases would be a poor choice when  The system is dominated by Non-functional requirements  The system has few users  The system has few interfaces Example: embedded systems
  57. 57. Advanced Use case Modeling In advanced use case modeling we will discuss about the following relationships Actor Generalization: A generalization relationship between more general actor and more specific actor Example: Use case Generalization: A generalization relationship between more general Use case and more specific use case. Example: Validate user Check password Retinal scan
  58. 58. <<includes>>: A relationship between use cases that lets one use case includes behavior from another use case Example: <<includes>> <<includes>> <<includes>> <<extends>>: A relationship between use cases that lets one use case extend its behavior with one or more behavior from another Place order Track order Ship order Validate customer
  59. 59. Example:
  60. 60. The extension use case
  61. 61. Use case diagrams example: Cellular telephone system
  62. 62. Hints and tips for writing use cases • Keep use cases short and simple • Focus on what not on how • Avoid functional decomposition
  63. 63. Summary: • The Unified Modeling Language is a standard graphical language for modeling UML is composed of three building blocks 1. Things 2. Relationships 3. Diagrams UML has four common mechanisms 1. Specification 2. Adornments 3. Common divisions 4. Extensibility mechanisms UML has five views 1. Use case view 2. Logical view 3. Process view 4. Implementation view 5. Deployment view
  64. 64. • The Unified process is a software development process • Rational Unified Process is an extension to the Unified Process The UP axioms • Use case driven process • Architecture centric process • Iterative and incremental process The UP software is built in iterations Every iteration has five core workflows 1. Requirement 2. Analysis 3. Design 4. Implementation 5. Test The UP has four phases 1. Inception 2. Elaboration 3. Construction 4. Transition
  65. 65. • Most of the requirements workflow occurs in the inception and elaboration phase s of the UP project life cycle • There are two types of requirements 1. Functional requirements : behavior of the system 2. Non functional requirements : constraints of the system • The use case modeling is other form of requirements engineering • Use case model consist of use cases ,actors and relationships among them • Use cases are the functions that the system performs • Actors are roles played by things external to the system
  66. 66. Quiz 1) Which of the following is iterative, incremental, use case driven and architecture centric? (a) V-method (b) UML (c) Component Based Development (d) UP 2) What is true about UML stereotypes? (a) A stereotype is used for extending the UML language. (b) A stereotyped class must be abstract. (c) The stereotype {frozen} indicates that the UML element cannot be changed. (d) UML Profiles can be stereotyped for backward compatibility 3) Which statements are true for use case relationships? a)An Include relationship means that a Use Case includes the behavior described in another Use Case b) an Extend relationship implies that a Use Case may extend the behavior described in another Use Case c)Generalization between Use Cases means that the child is a more specific form of the parent. The child inherits all Features and Associations of the parent, and may add new Features and Associations d)All of the above
  67. 67. Quiz 4) Which statements are true for an Actor? a) an actor is a role a user plays with respect to the system b)generalization is not applicable to actors c) an actor does not need to be human. A subsystem or external system can be modeled as an actor d) None 5) Which of the following statements are TRUE about Use Cases? a) Use case diagrams are the primary tool to document requirements b) Use cases provide the basis of communication between sponsors and developers in planning phase c) Use cases description provides a good source to identify domain concepts d)A fully-dressed use case should include both "whats" and "hows" so that they are ready for "realization" e) A use case is an interaction between a user and a system. 6)Constraints can be represented in UML by: a) [ text string ] b) { text string } c) notes d) constraint
  68. 68. Quiz 7) Which of the following statements are true about use-case driven development? a) Requirements are primarily captured in use cases. b) Use cases are the essential part of iterative planning by choosing some use case scenarios. c) User manuals are normally organized based on use cases d) All of the above 8) Static view diagrams(Structural diagrams) a) Class diagrams b) Object diagrams c) Both (a) and (b) d) None of the above
  69. 69. Key: 1) d 2) a 3) d 4) a, c 5) b, c, e 6) b 7) d 8) c
  70. 70. THANK YOU

×