Upload
kelley-randall
View
221
Download
0
Tags:
Embed Size (px)
Citation preview
© Osman Haque, Myriad Solutions Inc., 2001
The Unified Modelling Language
An OMG Standardwww.omg.org
© Osman Haque, Myriad Solutions Inc., 2001
Unified Modelling Language (UML)
• Unified Modelling Language is an international standard to capture and express Requirements and System Designs
• UML is a standard of the Object Management Group (OMG) which has more than 800 members
• At this stage, UML is a language for expressing models - it is not a process
• Together with a Process, it is an Excellent way of Capturing Requirements and Translating them into Design
© Osman Haque, Myriad Solutions Inc., 2001
The Origins of the UML• Plethora of Development Methods
– 63 official methods in 1994
• Grady Booch - the Booch method
• Jim Rumbaugh - the Object Modelling Technique (OMT)
• Ivar Jacobson - the Object-Oriented Software Engineering (OOSE) method
• Jacobson writes Cease the Methodologies Wars, in JOOP, 1994
© Osman Haque, Myriad Solutions Inc., 2001
Inputs to UML
Fusion
Operation descriptions,Message numbering
UML
Meyer
Before and after conditions
Harel
State charts
Wirfs-Brock
Responsibilities
Embley
Singleton classes, High-level view
Odell
Classification
Shlaer - Mellor
Object Lifecycles
Gamma, et.al
Frameworks, patterns,notes
Booch
JacobsonRumbaugh
Henderson-Sellers
Aggregation;Metamodel
© Osman Haque, Myriad Solutions Inc., 2001
UML Modelling DiagramsBehavioural
• Use Case Diagram
• Sequence Diagram
• Collaboration
Diagram
• Statechart Diagram
• Activity Diagram
Structural
• Class/Object
Diagram
• Component Diagram
• Deployment Diagram
© Osman Haque, Myriad Solutions Inc., 2001
UML WALKTHROUGH
Use Case
Activity
Sequence
Class
State Chart
Collaboration
Component
DeploymentA use case is a sequence of transactions performed by a system that yields a measurable result of value for a particular actor.
Validate
Bank
OpenAccount
Transact
uses
CloseAccount
Client
© Osman Haque, Myriad Solutions Inc., 2001
UML WALKTHROUGH
Use Case
Activity
Sequence
Class
State Chart
Collaboration
Component
DeploymentActivity Diagrams depicts Flow
within and between Use Cases; Multithreads can be Shown;
[Next Transaction]
WithdrawsCash
[Amount>Balance]
CustomerIdentifies
AccountOverdrawn
TransactionComplete
PrintReceipt
[Amount<Balance
]
© Osman Haque, Myriad Solutions Inc., 2001
UML WALKTHROUGH
Use Case
Activity
Sequence
Class
State Chart
Collaboration
Component
Deployment A diagram depicting Sequence of Interactions A diagram depicting Sequence of Interactions between Objects and/or between Actor/Systembetween Objects and/or between Actor/System
Business : Client Loans : Loans Rules Assets : Assets
RegisterforLoanValidateRules
CalcAssetValue
© Osman Haque, Myriad Solutions Inc., 2001
UML WALKTHROUGH
Use Case
Activity
Sequence
Class
State Chart
Collaboration
Component
Deployment
A description of a group of objects with common properties,common behavior,common relationships to other objects and common semantics.
Borrowing
CreditCardLoans
© Osman Haque, Myriad Solutions Inc., 2001
UML WALKTHROUGH
Use Case
Activity
Sequence
Class
State Chart
Collaboration
Component
Deployment Depicts the State of an Object; And the Events that Effectuate a Change in State;
Open
Suspended
Closed
WithdrawCash( amount )
OverDrawn[ amount > balance ]
Close(balance)
balance >= 0
SuspendAcct( flag=1 )
SuspendAcct( flag=0 )
© Osman Haque, Myriad Solutions Inc., 2001
UML WALKTHROUGH
Use Case
Activity
Sequence
Class
State Chart
Collaboration
Component
DeploymentA diagram that shows object A diagram that shows object interactions organized around the interactions organized around the objects and their links to each other.objects and their links to each other.
action()
1
1.1
1.21.3
© Osman Haque, Myriad Solutions Inc., 2001
UML WALKTHROUGH
Use Case
Activity
Sequence
Class
State Chart
Collaboration
Component
DeploymentA diagram that shows the composition, organization and dependencies among software components.
Account Customer
© Osman Haque, Myriad Solutions Inc., 2001
UML WALKTHROUGH
Use Case
Activity
Sequence
Class
State Chart
Collaboration
Component
DeploymentA diagram showing how the system will be deployed in operation: It shows processes and nodes in the physical design of a system.
459 Elm St. ATM
ATMClient.exe
Regional ATM Server
ATMServer.exe
<<Private Network>>
125 First St. ATM
ATMClient.exe
<<Private Network>>
Printer
Banking Database Server
Oracle Server
<<LAN>>
© Osman Haque, Myriad Solutions Inc., 2001
Use Casesand
Use Case Diagrams
Prime & Popular Mechanisms for
Requirements Engineering
© Osman Haque, Myriad Solutions Inc., 2001
Why Use Cases and Use case Diagrams?
• Extremely Popular Mechanism for Requirements Engineering
• Users are Directly able to Relate to the Diagrams and Descriptions
• Formalizes the otherwise Unstructured Requirements
• Enables Organization, Reuse, Quality and Extension of Requirements
• Supported by CASE tools
© Osman Haque, Myriad Solutions Inc., 2001
Things to Understand
• Use Cases– and their Documentation
• Actors
• Use Case Relationships– Include, Extend
• Use Case Diagrams
• Classifying and Packaging Use Cases
© Osman Haque, Myriad Solutions Inc., 2001
What is a Use Case?• A series of interaction of a User with the System,
which provides some concrete, measurable results to the User
• Documentation of that interaction as a series of steps - which may be atomic
• Pre- and Post-conditions, Context and other details related to the interaction between “Actor” and the system
• Has a strong Functional flavor and may be (has been) used for Non-OO, and even Non-IT purposes
© Osman Haque, Myriad Solutions Inc., 2001
Sources of Use Cases
• User Workshops – Following the Joint Application Design style– Play acting various Scenarios with Users– Critical Requirements Analysis
• Formal and Informal Problem Statements• Knowledge of Domain Experts• Interviews and Discussions• Existing Systems (esp. Legacy)• Use Case Patterns/Published Literature/ URLs
© Osman Haque, Myriad Solutions Inc., 2001
Who is an Actor?• The User of the system is usually the Actor
• The Actor (and not the User) is shown sending and
receiving messages to and from the System
– Example: John the Branch Manager, John the Customer
and John the Teller may be one and the same person
• External Devices may also be Actors
– e.g. ATM Machines, Keypads, Printers
• External Systems may also be Actors
– e.g.A Mainframe
© Osman Haque, Myriad Solutions Inc., 2001
Actor: Variations
• Primary Actor: – The first or main Actor who uses the system (e.g. Teller)
– The main Actor who benefits from the system (e.g. Customer)
• Secondary Actor:
– The Actor who derives indirect benefits from or uses the system
(e.g. Branch manager); Depends on Perspective
• Abstract and Concrete Actors:
– Due to Generalization to reduce Complexity
© Osman Haque, Myriad Solutions Inc., 2001
Actors can be Generalized(to handle complexity in use case diagrams)
Borrower
Personal Borrower
Small Business Borrower
Large Corporate Borrower
© Osman Haque, Myriad Solutions Inc., 2001
How to Find Actors?– Who provides/uses Information to/from the System?
– Who Supports this Functionality?
– Which other Systems will this System Interact with?
– The External Devices (Keypads, Printers etc.) that the system will Interact with
Process Comment: Produce first cut of the list of Actors, then Cull them after drawing Initial Use Case diagrams
© Osman Haque, Myriad Solutions Inc., 2001
Actor: Practical Tips
• Customer makes Inquiry by Phone – In this Scenario, Customer does not Directly interact
with the System. Is this Customer an Actor?
– Yes, because this Customer is direct beneficiary
• System sends Messages to backend Database
– This entire backend system may not have any direct
user; The External system may become an actor;
Otherwise, the use case diagram will be without actors.
© Osman Haque, Myriad Solutions Inc., 2001
Internet Actor:The e-Business Customer
• May Remain Unknown for Long, and even
Forever - except through Internet access!
• Business Analysis has to discover/invent:
– Benefits derived by an unknown Customer
– Classification of such an Actor• by Age, Sex, Income, Expenditure and such Criteria
• Choices of such Actors (Language, Colors, Styles)
– Geographical/Time/Cultural boundaries
• 24 x 7 x 360o
© Osman Haque, Myriad Solutions Inc., 2001
What is a Use Case Diagram?
• Primarily used to visualize the Use cases, corresponding
Actors, and their interactions
• Notations: Actor, Use case, Relations
• Relations:
– Relations in a Use case diagram are powerful mechanism to
organize and reuse Requirements
– Includes; Extends; Generalize
• Context in a Use case diagram indicates the boundary of
the system (between the Actor and the System)
© Osman Haque, Myriad Solutions Inc., 2001
UML Notation for Use Case Relationships
<<include>>
<<extend>>
<<inherits>>A
B
Use case A <<include>> Use case BUse case A <<extend>> Use case BUse case A <<inherit>> Use case BIt is Recommended that Inherits NOT be used in Use Case Relationships as it is not mature
© Osman Haque, Myriad Solutions Inc., 2001
Include Relationship
• When Requirements tend to Exhibit Common behavior, they should be Factored out
• These Common Behaviours form a Use case of their Own
• They are then “included” in the Original Use cases, and many more
• Tip: Include implies Mandatory
© Osman Haque, Myriad Solutions Inc., 2001
Include Relationship: Example
• was “uses” in earlier UML versions
A10-Passenger
10-BuysTicket
30-ChecksAvailability
<<include>>
© Osman Haque, Myriad Solutions Inc., 2001
Extend Relationship
• Describes extensions to an Existing Use case
• The Extended use case describes one Specialised set of Interactions
• Enables extending the Use case diagrams for new Requirements without disturbing Existing diagrams
• Tip: Extend implies Optional
© Osman Haque, Myriad Solutions Inc., 2001
Extend Relationship: Example
TicketAvailabilityByPhone
ChecksTicketAvailability
<<extend>>
<<extend>>
<<extend>>
TicketAvailabilityByAgent
TicketAvailabilityByInternet
© Osman Haque, Myriad Solutions Inc., 2001
Use Case diagram for Booking AirTickets
20-MakesEnquiry
A20-Staff
3010-PhoneAvailability
3020-InternetAvailability
3030-AgentAvailability
30-ChecksAvailability
<<extend>>
<<extend>>
<<extend>>
A10-Passenger
10-BuysTicket
<<include>>
© Osman Haque, Myriad Solutions Inc., 2001
Use Case Diagrams: Common Pitfalls!
• Treated as Data Flow Diagrams– Use Activity Diagrams to Show the Flow
• Look like a Spider’s web– Abstract both Actors and Use cases and draw separate
‘abstract’ use case diagrams
• Too Coarse or Too Fine Granularity– Experience needed to Get it Right– Perhaps Use Case Diagram Patterns can Help?
• Use Case Diagrams treated as Deliverables– More than 50% work is Documenting Use Cases
• Force fitting Actors that Don’t Exist
© Osman Haque, Myriad Solutions Inc., 2001
Relating to CRA
• Each Functional CPA (Critical Performance Area) should be seen from the Actor’s Viewpoint
• Then, it is potentially a Use Case
• Need to Scope it, and give it due Importance
© Osman Haque, Myriad Solutions Inc., 2001
Use Case Documentation• The Flow within a Use case is the Behavioral
aspect of the System
• This flow can be documented as:– Organized Text
– Pseudocode
– Sequence Diagrams
– occasionally Activity diagrams
• Organized Text is the Primary means of this
Documentation; It is based on a pre-decided template
© Osman Haque, Myriad Solutions Inc., 2001
Template: Documenting Use CasesUse Case Thumbnail
<Number and Name of the Use Case>
Use Case Description<A short description of the use case>
Stereotype and Package<Description of the Stereotype and Package to which this use case belongs>
Pre-Conditions<Conditions that must be satisfied before this use case can begin - may include a
list of other use cases>
Post-Conditions<Conditions that must be met at the end of this use case>
Actors<A list of the actors involved in this use case>
Use Case Relationships<Thumbnails of other Use Cases that are Included, Extended and Inherited>
© Osman Haque, Myriad Solutions Inc., 2001
Template: Documenting Use Cases...Use Case Text
1.0 <description of step>2.0 <description of step> (A1, E1, E2)3.0 <description of step> (A2, E3)INCLUDE <Thumbnail of Use case/s Included>EXTEND <Thumbnail of Use case/s Extended>
Alternative Courses<A1> <A2>
Exceptions<E1><E2>
Constraints<special constraints/limitations in executing the use case>
© Osman Haque, Myriad Solutions Inc., 2001
Template: Documenting Use Cases...
User Interface Specifications<Number and Name of UI specifications related with this use case, including web-
screen specifications>
Metrics<Measurements related to this use case - if relevant to the programme; Also,
perhaps, complexity factor>
Priority<The importance of the functionality described by this use case
High/Medium/Low>
Status<The state of completeness of the documentation of this use case -
Initial/Major/Final>
Author & History<Original Author and Modifiers of this Use Case>
Reference Material<Relevant reference materials and sources for details>
© Osman Haque, Myriad Solutions Inc., 2001
Use Case Analysis and Testing
• Business Analysts should plan to ‘reuse’ parts of Requirements Model for Testing
• There are some similarities between RM and Test Creation Processes
– The Steps within Use Cases provide the First cut of Black box Test Cases
– Augment them with Operational Test Cases (performance, stress testing)
– A Good Test Architecture should reflect understanding of good Application Architecture
© Osman Haque, Myriad Solutions Inc., 2001
Activity Diagrams
Flows within Use Cases, WorkFlows, Multithreads
© Osman Haque, Myriad Solutions Inc., 2001
Purpose of Activity Diagrams
• Primary purpose is to show the flow of Activities – Within the requirements (use cases)
– In the System
– For the Overall Business
• A highest level Activity Diagram can be used as a Context-diagram– showing how various business processes are related
© Osman Haque, Myriad Solutions Inc., 2001
About Activity Diagrams
• Capable of showing Sequentially Dependent Business Objectives
• They can be Used to Show
– Multiple Threads
– Work Flows with Deliverables
• They do not have separate Documentation within UML
© Osman Haque, Myriad Solutions Inc., 2001
Things in Activity Diagrams
• Activities
• Transitions
• Starting and End points
• Sync Points
• Decision points
• Guard Conditions
© Osman Haque, Myriad Solutions Inc., 2001
ActivitiesThings happening within the System or within the Flow of a Use Case
CustomerIdentifies
WithdrawsCash
TakesReceipt
© Osman Haque, Myriad Solutions Inc., 2001
Transitions
CashWithdrawn
Flag Overdrawn
Amount > Balance
This is a Transition:It can be triggered by a user action, or by meetinga certain Criteria/condition
© Osman Haque, Myriad Solutions Inc., 2001
Activity Diagrams(Like Flow Charts)
WithdrawsCash
[Amount>Balance]
[Next Transacti
on]
CustomerIdentifies
AccountOverdrawn
TransactionComplete PrintReceipt
[Amount<Balance]
© Osman Haque, Myriad Solutions Inc., 2001
A typical Activity Diagram for Receiving and Dispatching Orders
ReceiveOrder
CancelOrder
AuthorizePayment
CheckLine Item
Assign toOrder
DispatchOrder
ReorderItem
[for each lineitem on order]
[failed]
[succeeded]
[in stock]
[need toreorder][stock assigned to
all line items andpayment authorised]
*
© Osman Haque, Myriad Solutions Inc., 2001
Class Diagrams
Formalized from Object-oriented Technology
© Osman Haque, Myriad Solutions Inc., 2001
Class Diagrams in Business Analysis
• Class Diagrams are used to describe the Business Object Model
• They are an ideal static description of Entities in Business Domain
• Important:– Classes are used at a high-level in Business Analysis
– Not all features of classes are relevant in BA; They apply in System Design
© Osman Haque, Myriad Solutions Inc., 2001
Class Diagrams in Business Analysis
• Used to Document
– Key Domain Entities
– Design Structure
– Logical Grouping resulting into Components
• Class has three parts: Identification, Attributes and
Operations
• Relationships: Inheritance, Aggregation,
Association
© Osman Haque, Myriad Solutions Inc., 2001
• Analyse the Use Case Diagrams and Documentation
• Determine the Key Business Entities (Candidate Classes)
• Refine the Candidate Classes• Determine the Relationships between Classes• Determine Abstraction Level
– through Inheritance hierarchy
Class Diagram:Iterative Steps..
© Osman Haque, Myriad Solutions Inc., 2001
Class Diagram: Iterative Steps
• Define/Qualify the Classes– provide Attributes and Types– provide Responsibilities
• Which will eventually translated into Operations
• Describe states of Objects for that Class, if important
• Statecharts are Optional so we don’t use them
© Osman Haque, Myriad Solutions Inc., 2001
Class Notation
Course
name : charID : int
getname (): BOOL
Name of the Class
Attributes of the Class
Operations of the Class
Business Analysis:Specifying Attribute Types may be helpful
Business Analysis:Specifying Operations ReturnValues may not be necessary (too technical; for Sys.Design)
© Osman Haque, Myriad Solutions Inc., 2001
Naming Classes
• Class Names should be created Formally
– BAs, Users, Developers should (Preferably) agree on
names
• Singular Common Noun, representing a ‘core’ or
‘definable’ entity (mostly)
• Abstract Nouns will appear for Abstract entities
(e.g. Transaction)
© Osman Haque, Myriad Solutions Inc., 2001
OO v/s Non-OO (Similarities and Differences)
• Non-Object-oriented (Traditional)– Data and Procedures are kept Separate
– Procedures work on Data to produce results
• Object-oriented– Focus on Responsibilities - to be satisfied
by Objects
– Responsibilities translate into Data and Functions within a Object
– Objects have Behavior
Data
Procedures
Procedures
Data
© Osman Haque, Myriad Solutions Inc., 2001
Class v/s ObjectClass v/s Object
• Object is an instance of Class• Class is effectively a definition for object
characteristics, such as:– properties; behavior– relationships; semantics– data structures
• Thus, Class is a blueprint for creating infinite objects
• Object is an instance of Class• Class is effectively a definition for object
characteristics, such as:– properties; behavior– relationships; semantics– data structures
• Thus, Class is a blueprint for creating infinite objects
© Osman Haque, Myriad Solutions Inc., 2001
Object NotationObject NotationFor Classes Named Course and Professor
Objects are ‘proper nouns’ shown belonging to Class
Course Professor
rectangles contain class names
Oscar:ProfessorMaths:CourseEnglish:Course
rectangles contain object and class names, underlined
© Osman Haque, Myriad Solutions Inc., 2001
AttributesAttributes
• Attributes describe the characteristics of an object
• Thus, Attributes describe characteristics which define a class of objects
• Attributes represent data values of objects belonging to a class
• Attributes have one value for each class instance (object)
• Attributes describe the characteristics of an object
• Thus, Attributes describe characteristics which define a class of objects
• Attributes represent data values of objects belonging to a class
• Attributes have one value for each class instance (object)
© Osman Haque, Myriad Solutions Inc., 2001
Attributes - NotationsAttributes - Notations
Course
name : charcredit : integerduration : integer
attributes
Typically, there is no need for an explicit “ID” attribute.
© Osman Haque, Myriad Solutions Inc., 2001
OperationsOperations• Operations define the behaviors of objects of a
particular class.• Operations are defined for a class only. Each
object of that class type has the same operations.• Operations change the state of attribute values and
are applied to instances of a class.• Operations are implemented by methods.• Operations are listed in the operations
compartment of the class box beneath the attributes compartment.
• Operations define the behaviors of objects of a particular class.
• Operations are defined for a class only. Each object of that class type has the same operations.
• Operations change the state of attribute values and are applied to instances of a class.
• Operations are implemented by methods.• Operations are listed in the operations
compartment of the class box beneath the attributes compartment.
© Osman Haque, Myriad Solutions Inc., 2001
Operations - NotationOperations - Notation
start-engines()stop-engines()get_fuel-level()operations
Course
name : charcredit : integerduration : integer
add-name()change-credit()change-duration()
© Osman Haque, Myriad Solutions Inc., 2001
Categories of ObjectsCategories of Objects
• Domain Objects
• Application Objects
• Implementation Objects
• Domain Objects
• Application Objects
• Implementation ObjectsBusiness Analysts would Mostly Deal with Domain Objects,at times with Application Objects but hardly with Implementation Objects
© Osman Haque, Myriad Solutions Inc., 2001
Domain ObjectsDomain Objects
• Carry real-world semantics of the application.
• Exist independently of the application.
• Are meaningful to Business Analysts and Domain Experts.
Examples: course, professor, student
• Carry real-world semantics of the application.
• Exist independently of the application.
• Are meaningful to Business Analysts and Domain Experts.
Examples: course, professor, student
© Osman Haque, Myriad Solutions Inc., 2001
Application ObjectsApplication Objects
• Are user-visible components of computer solution.
• Represent part of the Solution Domain and not Problem Domain
• May be Reused across Domains
Examples: User interface, printer interface
• Are user-visible components of computer solution.
• Represent part of the Solution Domain and not Problem Domain
• May be Reused across Domains
Examples: User interface, printer interface
© Osman Haque, Myriad Solutions Inc., 2001
Implementation ObjectsImplementation Objects
• Internal components used to implement system
• Invisible to the user
• Of No Interest to Business Analysts
Examples - database, hash table
• Internal components used to implement system
• Invisible to the user
• Of No Interest to Business Analysts
Examples - database, hash table
© Osman Haque, Myriad Solutions Inc., 2001
Sequence Diagrams
The Dynamic Aspect of Requirements Modeling
© Osman Haque, Myriad Solutions Inc., 2001
Sequence Diagram• A Dynamic Diagram to record Messages and their
sequences
• A pictorial representation of a Scenario/Example
for a Use Case
• A tool to Identify missing Classes in a Class
Diagram through Objects
• Part of Interaction Diagrams
– the other one being Collaboration Diagram
© Osman Haque, Myriad Solutions Inc., 2001
UML Notation For Object(In a Sequence Diagram)
SampleObject
© Osman Haque, Myriad Solutions Inc., 2001
Axes Axes
Tim
e
Different objects
These are the ‘semantics’ of the messages we want to show.In practice, return messages are not shown as they are implicit
© Osman Haque, Myriad Solutions Inc., 2001
UML Notation For Object Message
: Actor1
SampleObject1
1: Message sent by actor to an object