Docsity
Log inSign up
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search Store documents

The best documents sold by students who completed their studies

Search through all study resources
Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

University Rankings

Discover the best universities in your country according to Docsity users

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

From our blog

Exams and Study
Go to the blog

Notes on UML - Software Engineering 1: System Analysis | CSIS 360, Study notes of Civil Engineering

Fort Lewis College (FLC)Civil Engineering
Prof. Brian F. Hanks

Material Type: Notes; Professor: Hanks; Class: Software Engn 1: Syst Analysis; Subject: Computer Science Info Systems; University: Fort Lewis College; Term: Unknown 1989;

Typology: Study notes

Pre 2010

Uploaded on 08/05/2009

koofers-user-p4f
koofers-user-p4f 🇺🇸

10 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
CSIS 360 – Lecture 20
Last time on post-iteration reviews
- Be careful not to turn it into a finger-pointing exercise!
UML
Today we are going to start looking at some elements of the Unified Modeling Language
(UML). UML is frequently used to design and document systems.
UML is largely a set of diagrams which provide different views of a system under
development. Some of the most commonly used UML diagrams are:
- Use cases and UC diagrams
- Class diagrams
- Sequence diagrams
- State diagrams
- Activity diagram
- Collaboration diagram
They are focused on design of object-oriented systems.
I want to talk about them for a variety of reasons:
1) You will probably encounter them, so it is good to be able to read and understand
them.
2) Although they can be highly formal, they can also be very useful for quickly
documenting proposed design approaches in agile projects.
Use Cases
What is a use case?
A use case shows the behavior or functionality of a system.
“A use case represents a series of interactions between an outside entity and the system,
which ends by providing business value” – Use Cases: Requirements in Context
“A use case captures a contract between the stakeholders of a system about its behavior”
– Writing Effective Use Cases
A use case is another way to document requirements.
Two parts
- Use case diagram
- Use case description
Elements of a use case diagram:
pf3
pf4
pf5

Partial preview of the text

Download Notes on UML - Software Engineering 1: System Analysis | CSIS 360 and more Study notes Civil Engineering in PDF only on Docsity!

CSIS 360 – Lecture 20

Last time on post-iteration reviews

  • Be careful not to turn it into a finger-pointing exercise! UML Today we are going to start looking at some elements of the Unified Modeling Language (UML). UML is frequently used to design and document systems. UML is largely a set of diagrams which provide different views of a system under development. Some of the most commonly used UML diagrams are:
  • Use cases and UC diagrams
  • Class diagrams
  • Sequence diagrams
  • State diagrams
  • Activity diagram
  • Collaboration diagram They are focused on design of object-oriented systems. I want to talk about them for a variety of reasons:
  1. You will probably encounter them, so it is good to be able to read and understand them.
  2. Although they can be highly formal, they can also be very useful for quickly documenting proposed design approaches in agile projects. Use Cases What is a use case? A use case shows the behavior or functionality of a system. “A use case represents a series of interactions between an outside entity and the system, which ends by providing business value” – Use Cases: Requirements in Context “A use case captures a contract between the stakeholders of a system about its behavior”
  • Writing Effective Use Cases A use case is another way to document requirements. Two parts
  • Use case diagram
  • Use case description Elements of a use case diagram:
  • Actors – role, not an individual. May be an organization or a system. Actors are outside the boundaries of the system of interest.
  • System boundary
  • Connections – solid line, shows interaction between a use case and an actor
  • Use cases – ovals with use case identifier [Draw use case diagram for ATM – see page 3] However, the diagram is pretty rudimentary. Most of the use case is the textual part. Elements of a use case description (from Writing Effective Use Cases):
  • Use case title (same as in the diagram)
  • Primary Actor: the actor who initiates the use case
  • Level – what level of detail is in this use case o User goals level: typically an action that can be completed in a short period of time. Completion of the use case satisfies some user goal: buy a book, transfer money, send a package,… o Summary level: Higher level use cases – may take hours or days to complete. These use lower level use cases. Example: handle an insurance claim (investigate claim, evaluate damage, negotiate settlement, close claim) o Subfunction level: Detailed use cases that are needed to satisfy those at the user goals level. Examples: validate credit card, search for product,… These will tend to be written later in the development process, as part of the design task.
  • Stakeholders – people who have an interest in the system. Not just the user, usually.
  • Preconditions – things that must be true before the use case can start. Examples: employee must be logged in, time cards must be approved, …
  • Minimal guarantee – what is the minimum that the use case does? Often, this is ‘nothing happens’. The point is that the user may be unhappy, but nothing bad should happen.
  • Success guarantee – what the use case does to satisfy the stakeholders
  • Trigger – what causes the use case to start. Example: time, arrival of some object, completion of another use case,…
  • Main success scenario – the sequence of events that occur when the use-case functions as expected. [Basic Course of Events from current reading]
  • Extensions – events that occur when the use case does not function as expected. Think of these as else-clauses or exceptions Main success scenario This is a Sequence of steps that describes how the actor interacts with the use case. Each step describes
  • An interaction with an Actor (“Student enters their student ID”), or

Withdraw Money Primary Actor: Customer Level: User Goals Stakeholders: Customer, Bank Preconditions: Customer has signed in and is at choice menu. ATM has money. ATM has paper for receipts. Minimal Guarantee: Customer gets ATM card back, no money returned, balance unchanged. Success Guarantee: Customer gets cash, balance updated. Main Success Scenario:

  1. Customer selects withdraw
  2. System displays list of Customer accounts
  3. Customer selects the account they want to withdraw money from
  4. System asks user how much they want to withdraw.
  5. Customer enters an amount (must be multiple of $20)
  6. System reduces Customer’s balance by requested amount and dispenses requested amount of cash to Customer
  7. System prints receipt
  8. Customer takes cash and receipt
  9. System asks Customer if they want to do something else
  10. Customer says no
  11. System returns ATM Card to Customer Extensions: 3, 5 Customer cancels operation. Use case ends.
  12. Customer enters an amount that is not a multiple of $20. System displays an error message, goes back to step 4.
  13. Customer’s balance < requested amount. System displays error message, does not dispense any cash or change Customer's balance. Use case ends.
  14. Customer says yes – display main menu and go to appropriate use case. Discuss Paths and Scenarios. Use case above has main sequence of steps, and a set of extensions. Note that the extensions document other paths through the use case. Summary Use cases are more than just drawings. The narrative description is probably more important. Use cases are a good way to capture requirements. If you write them clearly, they accurately detail what the system must do. BUT, use cases don’t capture all of your requirements. They don’t describe external interfaces, data formats, business rules, complex formulas, or system attributes (non- functional requirements).

Group Exercise Write the description for the deposit money use case. Homework Write the use case descriptions for the check balance and transfer money use cases.