View
216
Download
2
Embed Size (px)
Citation preview
6/8/99 2
Use Case - Buy Item Version 1
Use Case: Buy Items - version 1Actors: Customer, CashierPurpose: Capture a sale and its cash paymentOverview: A customer arrives at a checkout with items topurchase. The cashier records the purchase items and collectsa cash payment. On completion the customer leaves with theitems.Type: Primary
Typical course of Events (please refer to page 79 T1)
6/8/99 3
Building a conceptual model
Objectives– identify concepts related to current development cycle
requirements
– create initial conceptual model
– distinguish between correct and incorrect attributes
– add specification concepts
6/8/99 4
Conceptual model
Illustrates meaningful concepts in a problem domain the most important artifact to create during OO analysis usually expressed in the form of static diagrams (in
Rational this implies a high-level class diagram) is a representation of real-world things; not software
components no operations are defined in conceptual model should show concepts, associations between
concepts,attributes of concepts
6/8/99 5
Partial conceptual model
Concept
ItemSales LineItem
10..1
Saledatetim e
1
1..*
Records-sale-of
10..1
Contained-in
1
1..*
Attributes
No responsibilities or methods
6/8/99 6
Concepts - definition
Concept - an idea, thing or object Primary distinction of object oriented analysis - division by
concepts rather than division by functions
6/8/99 7
Concepts in POS domain
Store, POST, Sale better to over specify the conceptual model than to under
specify it is common to miss some in the initial phase; discover
them later finding concepts using the concept category list (refer to
page 91, UML) finding concepts using Noun Phrase identification -
example in Buy Items version 1 - sales transaction
6/8/99 9
Report Objects - Include?
Receipt - record of a sale and payment; important concept in the problem domain
Should it be included in the model? Some factors to consider:
– receipt is a record of a sale - generally not useful, since all its information is derived from other sources
– receipt has a special role in terms of the business - the buyer is entitled to a receipt of the sale
– So how do we make a decision?
6/8/99 11
Conceptual Modeling Guidelines
List the candidate concepts using the concept category list add associations necessary to record the relationships for
which there is a need to preserve some memory add the attributes necessary Use the mapmaker strategy (leave irrelevant features,
name using the business terms, UML page 96) if a thing X cannot be thought of either number or text,
then X is probably a concept (example, destination airport) if in doubt, make it a concept (hmm)
6/8/99 12
Specification Concepts
When are they needed?– Add a specification concept when:
• deleting instances of things they describe (for example, Item) results in a loss of information that needs to be maintained
• it reduces redundant or duplicated information
6/8/99 13
Specification Example
Assume the following– an item instance represents a physical item in the store; as such it
has a serial number
– an item has a description, price and UPC which are not recorded anywhere else
– every time a real physical item is sold, a corresponding software instance of item is deleted from the database
With these assumptions, what happens when the store sells out of a specific item like “burgers”? How does one find out how much does the “burger” cost?
Notice that the price is stored with the inventoried instances
6/8/99 14
Specification Example - Contd
Also notice the data is duplicated many times with each instance of the item
This example illustrates the need for a concept of objects that are specifications or descriptions of other things (often called a Proxy or Surrogate)
Description or specification objects are strongly related to the things they describe.
6/8/99 15
Specification - Example
ProductDesciption
descriptionpriceUPC
Item
Serial Number*1
describes
*1
6/8/99 16
UML definitions
Class - a description of a set of objects that share the same attributes, operations, methods, relationships and semantics
operation - a service that can requested from an object to effect behavior
6/8/99 17
Conceptual Models - Association
Objective– Identify associations for a conceptual model
– distinguish between need-to-know associations from comprehension-only associations
6/8/99 18
Associations
Association - a relationship between concepts that indicates some meaningful and interesting connection
POST Sale
11
Records-current
11
Association
6/8/99 19
Finding Associations
Refer to page 108 (larman) High priority associations
– A is a physical or logical part of B
– A is physically or logically contained in/on B
– A is recorded in B
Finding concepts is much more important than finding associations. The majority of time spent in conceptual model creation should be devoted to identifying concepts, not associations
6/8/99 20
Association Guidelines
Focus on those associations for which knowledge of the relationship needs to be preserved for some duration (need-to-know associations)
more important to identify concepts than associations too many associations tend to confuse the conceptual
model avoid showing redundant or derivable associations
6/8/99 21
Roles in Associations
Each end of an association is called a role. Roles have– name
– multiplicity expression
– navigability
6/8/99 22
Multiplicity
Multiplicity defines how many instances of type A can be associated with one instance of type B at a particular moment in time
POST Sale
11
Records-current
11
Multiplicity of the role
6/8/99 23
Association - Multiplicity
Multiplicity: indicates the number of objects of one class the may be related to a single object of an associated class
can be one of the following types– 1 to 1, 1 to 0..*, 1 to 1..*, 1 to n, 1 to 1..n
6/8/99 24
Associations - Contd.
Sale paym ent
11
Paid-by
11
Store
POST
11 11
Records-current1..*
1
Contains
1..*
1
Associations are generally read left to right, top to bottom
6/8/99 25
Associations - Contd.
Flight Airport0..1
*
0..1*flies-to
0..1*
flies-from0..1
*
Multiple associations between two types
During analysis phase, an association is not a statementabout data flows, instance variables, or object connectionsin the software solution
6/8/99 27
Conceptual Model - Attributes
Objectives– identify attributes in a conceptual model
– distinguish between correct and incorrect attributes
6/8/99 28
Attributes
Attribute - is a logical data value of an object Include the following attributes in a conceptual model
– those for which the requirements suggest or imply a need to remember information
For example, a sale receipt normally includes a date and time attribute
6/8/99 29
Attributes
Attribute: Named property of a class describing values held by each object of the classAttribute Type: A specification of the external behavior and/or the implementation of the attribute
Attribute Name:attribute Type
6/8/99 30
Attributes
Attributes in a conceptual model should preferably be simple attributes or pure data values
Very common simple attribute types include– boolean, date, number, string, time
6/8/99 31
Attributes
Cashier
namecurrentPost
not a "simple"
worse
Cashier
name
POST
number11
uses
11
better
Relate with associations, not attributes, in conceptualmodel
6/8/99 32
Complex Attributes
Pure data values - expressed as attributes; they do not illustrate specific behaviors;– Example - Phone number
– A Person can have many Phone numbers
Non-primitive attribute types– represent attributes as non-primitive types (concepts or objects) if
• it is composed of separate sections (name of a person)
• there are operations associated with it such as validation
• it is a quantity with a unit (payment has a unit of currency)
6/8/99 33
Complex Attributes
It is desirable to show non-primitive attributes as concepts in a conceptual model
Product specification UPC
1* 1*
6/8/99 35
Recording terms in Glossary
Define all terms that need clarification in a glossary or model dictionary (refer to T2 glossary, T1 page 131)
6/8/99 36
System Behavior
Objective– identify system events and system operations
– create system sequence diagrams for use cases
6/8/99 37
System sequence diagram
A system sequence diagram illustrates events from actors to systems
UML notation - sequence diagram This activity occurs during the analysis phase of a
development cycle; dependent on the creation of the use cases and identification of concepts
6/8/99 38
Sequence diagram
Use cases suggest how actors interact with the software system
an actor generates events to a system, requesting some operation in response
Example - when a cashier enters an item’s UPC, the cashier requests the POST system to record that item purchase. That request event initiates an operation upon the system
desirable to isolate and illustrate the operations that an actor requests of a system
6/8/99 39
Sequence Diagram
Shows for a particular scenario of a use case, the events that external actors generate, their order and inter-system events
A scenario of a use case is a particular instance or realized path
should be done for a typical course of events of the use case (usually for the most interesting ones)
6/8/99 40
Sequence Diagram - POS
Refer to page 138 T1 for an example of a system sequence diagram.
Note that the System Sequence Diagram is different from the Collaboration Diagrams that are described later with design.
6/8/99 41
System Events, Operations
System event - external input event generated by an actor system operation - operation of the system that executes
in response
6/8/99 42
Recording System operations
Set of all required systems operations is determined by identifying the system events
Examples: enterItem(UPC,quantity); endSale(); makePayment(amount)
UML notation -
Operation(arg:ArgType=defaultvalue,,,):ReturnType(s)
6/8/99 44
System behavior - contracts
Help define system behavior describe the effect of operation(s) on the system UML notation - pre and post conditions of operations contracts are useful documentation of the system behavior
in terms of what a system’s state changes are when a system operation is invoked