Upload
curran-marquez
View
52
Download
3
Tags:
Embed Size (px)
DESCRIPTION
Requirements Analysis-1. Last Update: Monday September 1, 2003. Contents. Requirements Analysis: “What” and “How” ?. Unified Process. OO Analysis and Design. Basics UML Actors, Use cases. Requirements Analysis [1]. What is it?. - PowerPoint PPT Presentation
Citation preview
September 1, 2003 BITS C461/IS C341 Software Engineering
1
Requirements Analysis-1
Last Update: Monday September 1, 2003
September 1, 2003 BITS C461/IS C341 Software Engineering
2
Contents Requirements Analysis: “What” and “How” ?
Unified Process
OO Analysis and Design
Basics UML Actors, Use cases
September 1, 2003 BITS C461/IS C341 Software Engineering
3
Requirements Analysis [1] What is it?
The process by which customer needs are understood and documented.
Example 1: The system shall allow users to withdraw cash. [What?]
Example 2: A sale item’s name and other attributes will be stored
in a hash table and updated each time any attribute changes. [How?]
Expresses “what” is to be built and NOT “how” it is to be built.
September 1, 2003 BITS C461/IS C341 Software Engineering
4
Requirements Analysis [2]
C- and D-Requirements
C-: Customer wants and needs; expressed in language understood by the customer.
D-: For the developers; may be more formal.
September 1, 2003 BITS C461/IS C341 Software Engineering
5
Requirements Analysis [3]
Why document requirements?
• Serves as a contract between the customer and the developer.
• Serves as a source of test plans.
• Serves to specify project goals and plan development cycles and increments.
September 1, 2003 BITS C461/IS C341 Software Engineering
6
Requirements Analysis [4] Roadmap:
Identify the customer.
Write C-requirements, review with customer, and update when necessary.
Interview customer representatives.
Write D-requirements; check to make sure that there is no inconsistency between the C- and the D-requirements.
September 1, 2003 BITS C461/IS C341 Software Engineering
7
Requirements Analysis [5]
C-requirements: Use cases expressed individually and with a use case
diagram. A use case specifies a collection of scenarios. Sample use case: Process sale.
Data flow diagram: Explains the flow of data items across various functions. Useful
for explaining system functions. [Example on the next slide.]
State transition diagram: Explains the change of system state in response to one or
more operations. [Example two slides later.]
User interface: Generally not a part of requirements analysis though may be included.
September 1, 2003 BITS C461/IS C341 Software Engineering
8
Data Flow Diagram
Get employeefile
Total pay
Deduct taxes
Net payIssue
paycheck
Regularhours
Overtimehours
ID
Worker
Check
Company records
Employee Record
Tax rates
Pay rate
Weeklypay* Pay Overtime
pay*
Overtimerate
*
September 1, 2003 BITS C461/IS C341 Software Engineering
9
State Transition Diagram (STD)
EBOFF (e,f) EBON (e,f)
EBP(e,f)
EBP(e,f)
EBOFF (e,f): Elevator e button OFF at floor f.
EBON (e,f): Elevator e button ON at floor f.
EBP(e,f): Elevator e button f is pressed.
Elevator example (partial):
September 1, 2003 BITS C461/IS C341 Software Engineering
10
Requirements Analysis [6] D-requirements:
Organize the D-requirements.
Create sequence diagrams for use cases:
Obtain D-requirements from C-requirements and customer.
Outline test plans Inspect
Validate with customer.
Release:
September 1, 2003 BITS C461/IS C341 Software Engineering
11
Requirements Analysis [7]
Organize the D-requirements:
Functional requirementsThe blood pressure monitor will measure the blood
pressure and display it on the in-built screen.
Non-functional requirementsPerformanceThe blood pressure monitor will complete a reading within 10 seconds.
ReliabilityThe blood pressure monitor must have a failure probability of less than 0.01 during the first 500 readings.
September 1, 2003 BITS C461/IS C341 Software Engineering
12
Requirements Analysis [8]
Interface requirements: interaction with the users andother applications
The blood pressure monitor will have a display screen and push buttons. The display screen will….
Constraints: timing, accuracyThe blood pressure monitor will take readings with an error less than 2%.
September 1, 2003 BITS C461/IS C341 Software Engineering
13
Requirements Analysis [9]
Properties of D-requirements: Traceability: Functional requirements
D-requirement inspection report design segment code segment code inspection report test plan test report
Traceability: Non-Functional requirements(a) Isolate each non-functional requirement.(b) Document each class/function with the
related non-functional requirement.
September 1, 2003 BITS C461/IS C341 Software Engineering
14
Requirements Analysis [10]
TestabilityIt must be possible to test each requirement. Example ?
Categorization and prioritization..next slide
September 1, 2003 BITS C461/IS C341 Software Engineering
15
Prioritizing (Ranking) Use Cases
Strategy : pick the use cases that significantly influence
the core architecture
pick the use cases that are critical to the success of the business.
a useful rule of thumb - pick the use cases that are the highest risk!!!
September 1, 2003 BITS C461/IS C341 Software Engineering
16
Requirements Analysis [11] Completeness
Self contained, no omissions.
Error conditionsState what happens in case of an error. How should the implementation react in case of an error condition?
September 1, 2003 BITS C461/IS C341 Software Engineering
17
Consistency of Requirements
Different requirements must be consistent.
R5.4: When the vehicle is cruising at a speed greater than 300 mph, a special “watchdog” safety
mechanism will be automatically activated.
Example:
R1.2: The speed of the vehicle will never exceed 250 mph.
September 1, 2003 BITS C461/IS C341 Software Engineering
18
OO Analysis and Design: Objectives
Compare and Contrast analysis and design
Define object-oriented analysis and design
Relate, by analogy, OO analysis and design to business organization.
September 1, 2003 BITS C461/IS C341 Software Engineering
19
What is Analysis and Design?
Analysis - investigation of the problem (what);
Design - conceptual solution to fulfill the requirements (how); how will the system do what it is intended to do.
What does the system do?
Investigation of the problem.
What (conceptual) solution will full the requirements
September 1, 2003 BITS C461/IS C341 Software Engineering
20
What is OO analysis and design?
Essence of OO analysis - consider a problem domain from the perspective of objects (real world things, concepts)
Essence of OO design - define the solution as a collection of software objects (allocating responsibilities to objects)
September 1, 2003 BITS C461/IS C341 Software Engineering
21
Examples OO Analysis - in the case of library information systems,
one would find concepts like book, library, patron
OO Design - emphasis on defining the software objects; ultimately these objects are implemented in some programming language; Book may have a method named print.
September 1, 2003 BITS C461/IS C341 Software Engineering
22
Example - contd.
Domain conceptRepresentation in analysis of concepts
Book
______title
print()
public class Book{public void print();private string title;}
Representation in OO programming language
September 1, 2003 BITS C461/IS C341 Software Engineering
23
Digression: OO Concepts-Objects
http://java.sun.com/docs/books/tutorial/java/concepts/
Objects: Anything that has a state and exhibits behavior.
Real world objects: Bicycle, student, course, dog, university,….
Software objects: Model real-world or abstract objects (e.g. a list).
Methods: Procedures through which objects communicate amongst themselves. Example: Bicycle: brake, park. Dog: bark, eat. Student: register, study.
Attributes: Variables that hold state information. Bicycle: speed, color, owner. Dog:name, breed. Student: name, ID.
September 1, 2003 BITS C461/IS C341 Software Engineering
24
Digression: OO Concepts-Class
Class: Prototype for all objects of a certain kind. Student, animal, university, shape, etc.
Objects: Created from a class. For example: s1, s2 are objects from class Student.
Inheritence: A class inherits attributes and methods from its super class. This allows hierarchical organization of classes.
Interface: A contract between a class and its users. A class implements an interface (methods and attributes).
BITS and Purdue are objects from class University. myCircle and mySquare are objects from class Shape.
September 1, 2003 BITS C461/IS C341 Software Engineering
25
What are business processes?
First step - consider what the business must do; in the case of a library - lending books, keeping track of due dates, buying new books.
In OO terms - requirements analysis; represent the business processes in textual narration (Use Cases).
September 1, 2003 BITS C461/IS C341 Software Engineering
26
Roles in the organization
Identify the roles of people who will be involved in the business processes.
In OO terms - this is known as domain analysis
Examples - customer, library assistant, programmer, navigator, sensor, etc.
Examples from class projects?
September 1, 2003 BITS C461/IS C341 Software Engineering
27
Who does what? Collaboration
Business processes and people identified; time to determine how to fulfill the processes and who executes these processes.
In OO terms - object oriented design; assigning responsibilities to the various software objects.
Often expressed in class diagrams.
September 1, 2003 BITS C461/IS C341 Software Engineering
28
In Summary...
BusinessAnalogy
OO Analysisand Design
AssociatedDocuments
What are thebusinessprocesses?
Requirementsanalysis
Use cases
What areemployee roles?
Domain analysis Conceptualmodel
Who isresponsible forwhat?
Responsibilityassignment;
Design classdiagrams
September 1, 2003 BITS C461/IS C341 Software Engineering
29
Simple example to see big picture
Define use cases
Example: Dice game a player rolls two die. If the total is 7 they win; otherwise they lose
Define conceptual model
Define collaboration diagrams
Define design class diagrams
September 1, 2003 BITS C461/IS C341 Software Engineering
30
Define use cases Use cases - narrative descriptions of domain
processes in a structured prose format
Use case: Play a gameActors: Player
Description: This use case begins when the player picks up and rolls the die….
September 1, 2003 BITS C461/IS C341 Software Engineering
31
Define domain model
OO Analysis concerns specification of the problem domain identification of concepts (objects)
Decomposition of the problem domain includes identification of objects, attributes, associations
Outcome of analysis expressed as a domain model.
September 1, 2003 BITS C461/IS C341 Software Engineering
32
Domain model - game of dice
Player_____name
Die____
facevalue
DiceGame
2
1Includes
1
1Plays
1 2Rolls
Conceptual model is not a description of the software components;it represents concepts in the real world problem domain
September 1, 2003 BITS C461/IS C341 Software Engineering
33
Collaboration diagram
Essential step - allocating responsibility to objects and illustrating how they interact with other objects.
Collaboration diagrams express the flow of messages betweenObjects.
OO Design is concerned with defining logical software specification that fulfills
the requirements
Expressed as Collaboration diagrams
September 1, 2003 BITS C461/IS C341 Software Engineering
34
Example - collaboration diagram
:Player d1:Die1: r1:=roll()
d2:Die2: r2:= roll()
September 1, 2003 BITS C461/IS C341 Software Engineering
35
Defining class diagrams
Key questions to ask How do objects connect to other objects? What are the behaviors (methods) of these
objects?
Collaboration diagrams suggests connections; to support these connections methods are needed
Expressed as class diagrams
September 1, 2003 BITS C461/IS C341 Software Engineering
36
Example - Class diagram
Playername
play()
DiceGame
initialize()
DiefaceValue
roll()
1
1
Plays
1
1 2
includes
2
1
21
Rolls
1 2
A line with an arrow at the end may suggest an attribute.For example, DiceGame has an attribute that points to aninstance of a Player
September 1, 2003 BITS C461/IS C341 Software Engineering
37
Defining Models and Artifacts
Objectives analysis and design models familiarize UML notations and diagrams
Models provide a mechanism for decomposition and expressing specifications
Real world software systems are inherently complex
September 1, 2003 BITS C461/IS C341 Software Engineering
38
Analysis and Design models Analysis model - models related to an investigation of
the domain and problem space (Use case model qualifies as an example)
Design model - models related to the solution (class diagrams qualifies as an example)
September 1, 2003 BITS C461/IS C341 Software Engineering
39
What UML is not
UML is NOT a methodology UML is NOT a process UML is NOT proprietary (Now under the OMG)
UML is strictly Notations
September 1, 2003 BITS C461/IS C341 Software Engineering
40
Parts of UML
Views - shows different aspects of the system that are modeled, links the modeling language to the method/process chosen for development
Diagrams - graphs that describe the contents in a view
Model elements - concepts used in a diagram
September 1, 2003 BITS C461/IS C341 Software Engineering
41
Views in UML
Use CaseView
Use-case view : A view showing the functionality of the system as perceived by the external actors
September 1, 2003 BITS C461/IS C341 Software Engineering
42
Views in UML
Use CaseView
LogicalView
Logical view: A view showing how the functionality is designed inside the system, in terms of the static structure and dynamic behavior.
September 1, 2003 BITS C461/IS C341 Software Engineering
43
Views in UML
Use CaseView
LogicalView
ComponentView
Component view: A view showing the organization of the code components
September 1, 2003 BITS C461/IS C341 Software Engineering
44
Views in UML
ComponentView
Use CaseView
LogicalView
ConcurrencyView
Concurrency view: A view showing the concurrency of the system
September 1, 2003 BITS C461/IS C341 Software Engineering
45
Views in UML
ComponentView
Use CaseView
LogicalView
ConcurrencyView
DeploymentView
Deployment view: A view showing the deployment of the system in terms of the physical architecture
September 1, 2003 BITS C461/IS C341 Software Engineering
46
Introduction to UML[4] Model elements
Class Object State Use case Interface Association Link
Package ….
September 1, 2003 BITS C461/IS C341 Software Engineering
47
UML diagrams
Use Case diagram: External interaction with actors
Class/Object Diagram : captures static structural aspects, objects and relationships.
State Diagram: Dynamic state behavior
Sequence diagram: models object interaction over time
Collaboration diagram: models component interaction and structural dependencies
September 1, 2003 BITS C461/IS C341 Software Engineering
48
More UML diagrams
Activity diagram : models object activities
Deployment diagram : models physical architecture
Component diagram : models software architecture
September 1, 2003 BITS C461/IS C341 Software Engineering
49
Case study - Point of Sale Terminal
POS terminal should support the following record sales handle payments
Several architectural layers presentation application logic (problem domain, service
support) persistence
Emphasis - problem domain application objects
September 1, 2003 BITS C461/IS C341 Software Engineering
50
Analysis Objectives
Draw use case diagrams
Ranking Use cases
Identification of Use Cases
September 1, 2003 BITS C461/IS C341 Software Engineering
51
Use Cases
Use case - narration of the sequence of events of an actor using a system
UML icon for use case
September 1, 2003 BITS C461/IS C341 Software Engineering
52
Actors [1] Actor - an entity external to the system that in
some way participates in the use case
An actor typically stimulates the system with input events or receives outputs from the system or does both.
Customer
UML notation for actor:
September 1, 2003 BITS C461/IS C341 Software Engineering
53
Actors [2]
Primary Actor - an entity external to the system that uses system services in a direct manner.
Supporting Actor- an actor that provides services to the system being built.
Hardware, software applications, individual processes, can all be actors.
September 1, 2003 BITS C461/IS C341 Software Engineering
54
Identification of Use Cases [1]
Method 1 - Actor based Identify the actors related to the system Identify the scenarios these actors initiate or
participate in.
Method 2 - Event based Identify the external events that a system must respond to Relate the events to actors and use cases
Method 3 – Goal based [Actors have goals.] Find user goals. [Prepare actor-goal list.] Define a use case for each goal.
September 1, 2003 BITS C461/IS C341 Software Engineering
55
Identification of Use Cases[2]
To identify use cases, focus on elementary business processes (EBP).
An EBP is a task performed by one person in one place at one time, in response to a business event. This task adds measurable business value and leaves data in a consistent state.
September 1, 2003 BITS C461/IS C341 Software Engineering
56
Back to POST - Actors
Actors:
Choosing actors: Identify system boundary Identify entities, human or otherwise, that will interact with the system, from outside the boundary.
Cashier
Customer
Supervisor
Example: A temperature sensing device is an actor for a temperature monitoring application.
September 1, 2003 BITS C461/IS C341 Software Engineering
57
POST - Use Cases: First Try
Cashier Log In Cash out
Customer Buy items Return items
September 1, 2003 BITS C461/IS C341 Software Engineering
58
Common mistake Representing individual steps as use cases.
Example: printing a receipt (Why is this being done ?)
September 1, 2003 BITS C461/IS C341 Software Engineering
59
High level vs. Low Level Use cases[1]
Consider the following use cases: Log out Handle payment Negotiate contract with a supplier
These use cases are at different levels. Are they all valid? To check, use the EBP definition.
September 1, 2003 BITS C461/IS C341 Software Engineering
60
High level vs. Low Level Use cases [2]
Log out: a secondary goal; it is necessary to do something but not useful in itself.
Handle payment: A necessary EBP. Hence a primary goal.
Negotiate contract: Most likely this is too high a level. It is composed of several EBPs and hence must be broken down further.
September 1, 2003 BITS C461/IS C341 Software Engineering
61
Use Case Diagram - Example
Use Case Diagram: illustrates a set of use cases for a system.
Process sale
PaymentAuthorization
service
Manage securitySystem administrator
Cashier Handle returns
Process rental <<actor>>Tax calculator
Manage users
<<actor>>Accounting
system
September 1, 2003 BITS C461/IS C341 Software Engineering
62
More on Use Cases
Narrate use cases independent of implementation
State success scenarios (how do you determine the success of a use case).
A use case corresponds to one or more scenarios.
Agree on a format for use case description
Name a use case starting with a verb in order to emphasize that it is a process (Buy Items, Enter an order, Reduce inventory)
September 1, 2003 BITS C461/IS C341 Software Engineering
63
Exception handling
Document exception handling or branching
What is expected of the system when a “Buy Item” fails ?
What is expected of the system when a “credit card” approval fails ?
September 1, 2003 BITS C461/IS C341 Software Engineering
64
A sample Use Case
Use case: Buy ItemsActors: Customer, CashierDescription: A customer arrives at a checkout with
items to purchase. The cashier recordsthe purchase items and collects payment.
September 1, 2003 BITS C461/IS C341 Software Engineering
65
Ranking Use Cases Use some ordering that is customary to your
environment Example: High, Medium, Low Example: Must have, Essential, Nice to have
Useful when deciding what goes into an increment
POST example: Buy Items - High Refund Items - Medium (Why?) Shut Down POST terminal - Low
September 1, 2003 BITS C461/IS C341 Software Engineering
66
Requirements Analysis-2
Last Update Thursday August 26, 2003
September 1, 2003 BITS C461/IS C341 Software Engineering
67
Use Case - Buy Item Version 1
Use Case Buy Items - version 1
Actors Customer, Cashier
Purpose Capture a sale and its cash payment
OverviewA 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)
September 1, 2003 BITS C461/IS C341 Software Engineering
68
System Behavior
Objective identify system events and system operations
create system sequence diagrams for use cases
September 1, 2003 BITS C461/IS C341 Software Engineering
69
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.
September 1, 2003 BITS C461/IS C341 Software Engineering
70
System sequence diagrams [1]
SSD drawing occurs during the analysis phase of a development cycle; dependent on the creation of the use cases and identification of concepts.
A system sequence diagram illustrates events from actors to systems and the external response of the system
UML notation - Sequence Diagram not System Sequence Diagram.
September 1, 2003 BITS C461/IS C341 Software Engineering
71
System sequence diagrams [2]
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.
September 1, 2003 BITS C461/IS C341 Software Engineering
72
System sequence diagram [3]
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.
September 1, 2003 BITS C461/IS C341 Software Engineering
73
Domain model: What is it?
Usually expressed in the form of static diagrams (in Rational Rose this implies a high-level class diagram).
Illustrates meaningful concepts in the problem domain.
Is a representation of real-world things; not software components (of the system under development).
No operations are defined or specified in the domain model.
The model shows concepts, associations between concepts, and attributes of concepts.
Serves as a source of software objects.
September 1, 2003 BITS C461/IS C341 Software Engineering
74
Domain model: How to construct?
Objectives identify concepts related to current development
cycle requirements
create initial conceptual model
Identify attributes
add specification concepts
September 1, 2003 BITS C461/IS C341 Software Engineering
75
Partial domain model of POSTConcept
Saledatetime
1..*
Contained-in
11
Attributes
10..1
Records-sale-ofSales LineItem
quantityItem
Storeaddressname
1
Stocked-in
Register (POST)
Houses1
1..*
Captured-on
1
1
September 1, 2003 BITS C461/IS C341 Software Engineering
76
Finding concepts: Use noun phrases
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
September 1, 2003 BITS C461/IS C341 Software Engineering
77
Finding concepts: refer to use cases 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.
September 1, 2003 BITS C461/IS C341 Software Engineering
78
Finding concepts: Examples
• 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
September 1, 2003 BITS C461/IS C341 Software Engineering
79
Concepts in POST domain
POST Item Sale Store Payment SalesLineItem ProductCatalog
September 1, 2003 BITS C461/IS C341 Software Engineering
80
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
September 1, 2003 BITS C461/IS C341 Software Engineering
81
Specification Example
Assume that an item instance represents a physical item in the
store; 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
September 1, 2003 BITS C461/IS C341 Software Engineering
82
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.
September 1, 2003 BITS C461/IS C341 Software Engineering
83
Specification - ExampleProductDesciption
descriptionpriceUPC
Item
Serial Number*1
describes
*1
Item
Serial NumberdescriptionPriceitemID
Which of these two is a better choice of concepts? XSpecification describes X
September 1, 2003 BITS C461/IS C341 Software Engineering
84
Conceptual Models - Association
Objective Identify associations within a conceptual model distinguish between need-to-know associations from
comprehension-only associations
September 1, 2003 BITS C461/IS C341 Software Engineering
85
Associations Association - a relationship between concepts that indicates
some meaningful and interesting connection
POST Sale
11
Records-current
11
Association
September 1, 2003 BITS C461/IS C341 Software Engineering
86
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)
September 1, 2003 BITS C461/IS C341 Software Engineering
87
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
September 1, 2003 BITS C461/IS C341 Software Engineering
88
Roles in Associations
Each of the two ends of an association is called a role. Roles have
name multiplicity expression navigability
September 1, 2003 BITS C461/IS C341 Software Engineering
89
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
September 1, 2003 BITS C461/IS C341 Software Engineering
90
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
September 1, 2003 BITS C461/IS C341 Software Engineering
91
Associations - Contd.
Sale payment
11
Paid-by
11
Store
POST
11 11
Records-current1..*
1
Contains
1..*
1
Associations are generally read left to right, top to bottom
September 1, 2003 BITS C461/IS C341 Software Engineering
92
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.
September 1, 2003 BITS C461/IS C341 Software Engineering
93
Conceptual Model - Attributes
Objectives identify attributes in a conceptual model distinguish between correct and incorrect attributes
September 1, 2003 BITS C461/IS C341 Software Engineering
94
Attributes [1]
Attribute - is a logical data value of an object.
Include the following attributes in a domain 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
It is a 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
September 1, 2003 BITS C461/IS C341 Software Engineering
95
Attributes [2]
Attributes in a conceptual model should preferably be simple attributes or pure data values
Common simple attribute types include boolean, date, number, string, time
September 1, 2003 BITS C461/IS C341 Software Engineering
96
Attributes: Examples
Relate two items with associations, not attributes, in conceptual model.
worse Cashier
namecurrentPost
not a "simple” attribute
better Cashier
name
POST
number11
uses
1
September 1, 2003 BITS C461/IS C341 Software Engineering
97
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)
September 1, 2003 BITS C461/IS C341 Software Engineering
98
Complex Attributes
It is desirable to show non-primitive attributes as concepts in a conceptual model
Flight Airport11
Flies-to
Flight
destination
Destination a Complex concept
September 1, 2003 BITS C461/IS C341 Software Engineering
99
Recording terms in Glossary
Define all terms that need clarification in a glossary or model dictionary.
September 1, 2003 BITS C461/IS C341 Software Engineering
100
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
September 1, 2003 BITS C461/IS C341 Software Engineering
101
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)
September 1, 2003 BITS C461/IS C341 Software Engineering
102
System Events, Operations
System event - external input event generated by an actor
System operation - operation of the system that executes in response
September 1, 2003 BITS C461/IS C341 Software Engineering
103
Recording System operations
Set of all required systems operations is determined by identifying the system events.
Operation(arg:ArgType=defaultvalue,,,):ReturnType(s)
Examples: enterItem(UPC,quantity); endSale(); makePayment(amount)
UML notation -
September 1, 2003 BITS C461/IS C341 Software Engineering
104
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.
One use case may require one or more system operations (events) to complete a scenario.
September 1, 2003 BITS C461/IS C341 Software Engineering
105
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.
September 1, 2003 BITS C461/IS C341 Software Engineering
106
Artifacts of Analysis Analysis Artifact Questions Answered
Use Cases What are the domainprocesses?
Conceptualmodel
What are the concepts andterms?
Interactiondiagrams
What are system events andoperations?
Contracts What are the semantics ofsystem operations?