Upload
garey-todd
View
228
Download
3
Embed Size (px)
Citation preview
9/18/01 1
Software Requirements Analysis and Design (Continued)
9/18/01 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 the items.
Type Primary
Typical course of Events (please refer to Larman)
9/18/01 3
System Behavior
Objective– identify system events and system operations
– create system sequence diagrams for use cases
9/18/01 4
System sequence diagram-Example
:Cashier
:System
makeNewsale()
endSale()
Description, total
[* more items]
enterItem(itemID, quantity)
total with taxes
makePayment(amount)
change due, receipt
Box to enclosean iteration area.
9/18/01 5
System sequence diagram [1]
A system sequence diagram illustrates events from actors to systems and the external response of the system.
This activity occurs during the analysis phase of a development cycle; dependent on the creation of the use cases and identification of concepts.
UML notation - Sequence Diagram not System Sequence Diagram. One diagram depicts one scenario. This is the main success scenario. Frequent or complex alternate scenarios could also be illustrated. A system is treated as a black box. SSD is often accompanied by a textual description of the scenario to
the left of the diagram.
9/18/01 6
System sequence diagram [2]
Identify the system boundary…what is inside and what is outside.
System event: An external event that directly stimulates the (software) system.
Events are initiated by actors. Name an event at the level of intent and not using their
physical input medium or interface widgets.– enterItem() is better than scan().
Keep the system response at an abstract level.– description, total is preferred over display description and total
on the POS screen.
9/18/01 7
Conceptual (or Domain) model [1]
Illustrates meaningful concepts in the problem domain. 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 (of the system under development). No operations are defined or specified in the conceptual
model. Should show concepts, associations between concepts, and
attributes of concepts. Serves as a source of software objects.
9/18/01 8
Conceptual model [2]
Objectives– identify concepts related to current development cycle
requirements
– create initial conceptual model
– Identify attributed
– add specification concepts
9/18/01 9
Partial domain model of POS
Concept
10..1
1..*
Records-sale-of
Contained-in
Saledatetime
11
Attributes
Sales LineItem
quantityItem
Storeaddressname
1
Stocked-in
Register
Houses1
1..*
Captured-on
1
1
9/18/01 10
Finding concepts [1]
Finding concepts using Noun Phrase identification in the textual description of the domain .
Finding concepts using the concept category list (refer to page p134 in Larman):– Physical objects: register, airplane, blood pressure monitor
– Places: airport, hospital
– Catalogs: Product Catalog
9/18/01 11
Finding concepts [2]
Examine use case descriptions. Example: Process Sale use case:
– Main success scenario:• Customer arrives at a POS checkout counter.
• Cashier starts a new sale.
• Cashier enters an item ID.
• System records sale line item. It then presents a description of the item, its price, and a running total.
• ….
• ….
Possible source of confusion: Is it an attribute or a concept?• If X is not a number or a text then it probably is a conceptual class.
9/18/01 12
Finding concepts [3]
•Concepts from “Unreal” world ?•Message•Connection•Port
•Use terms familiar to those in the problem domain.POST or register?
•Are these concepts or attributes:•Store•Flight•Price
9/18/01 13
Concepts in POS domain
POST Item Sale Store Payment SalesLineItem ProductCatalog
9/18/01 14
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
9/18/01 15
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
9/18/01 16
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.
9/18/01 17
Specification - Example
ProductDesciption
descriptionpriceUPC
Item
Serial Number*1
describes
*1
Item
Serial NumberdescriptionPriceitemID
Which of these two is a better choice of concepts?
9/18/01 18
Conceptual Models - Association
Objective– Identify associations for a conceptual model
– distinguish between need-to-know associations from comprehension-only associations
9/18/01 19
Associations
Association - a relationship between concepts that indicates some meaningful and interesting connection
POST Sale
11
Records-current
11
Association
9/18/01 20
Finding Associations
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
Other associations– A uses or manages or controls B (Pilot -airplane)
– A owns B (Airline -airplane)
9/18/01 21
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
9/18/01 22
Roles in Associations
Each of the two ends of an association is called a role. Roles have– name
– multiplicity expression
– navigability
9/18/01 23
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
9/18/01 24
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
9/18/01 25
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
9/18/01 26
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.
9/18/01 27
Conceptual Model - Attributes
Objectives– identify attributes in a conceptual model
– distinguish between correct and incorrect attributes
9/18/01 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
9/18/01 29
Attributes
Attribute: Named property of a class describing values held by each object of the class
Attribute Type: A specification of the external behavior and/or the implementation of the attribute
Attribute Name:attribute Type
9/18/01 30
Attributes
Attributes in a conceptual model should preferably be simple attributes or pure data values
Common simple attribute types include– boolean, date, number, string, time
9/18/01 31
Attributes
worse
better
Relate with associations, not attributes, in conceptualmodel
Cashier
namecurrentPost
not a "simple"
Cashier
name
POST
number11
uses
1
9/18/01 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)
9/18/01 33
Complex Attributes
It is desirable to show non-primitive attributes as concepts in a conceptual model
Product specification UPC
11*
9/18/01 34
Recording terms in Glossary
Define all terms that need clarification in a glossary or model dictionary.
9/18/01 35
System Sequence diagram [1]
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
9/18/01 36
System Sequence Diagram [2]
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)
9/18/01 37
System Events, Operations
System event - external input event generated by an actor system operation - operation of the system that executes
in response
9/18/01 38
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)
9/18/01 39
Contracts
A contract describes detailed system behavior in terms of state changes to objects in the domain model.
A contract is a system operation. It is offered in the system’s public interface.
Note that one use case may require one or more system operations (events) to complete a scenario.
9/18/01 40
Contract: Example
Operation: enterItem(itemID: ItemID, quantity: integer)
Cross References: Use case: Process sale
Preconditions: There is a sale underway.
Postconditions:• A salesLineItem instance, sli, was created.
• sli was associated with the current Sale.
• sli.qty becomes quantity (attribute modification).
• sli was associated with ProductSpecification based on itemID match.
9/18/01 41
Artifacts of Analysis
Analysis Artifact Questions Answered
Use Cases What are the domain processes?
Conceptual model
What are the concepts and terms?
Interaction diagrams
What are system events and operations?
Contracts What are the semantics of system operations?