Analysis and Design Assignment
sinister670
week_2.zipWeek 2/.DS_Store
Week 2/ENTD311_CASE2/.DS_Store
Week 2/ENTD311_CASE2/Assignment2DONE.docx
2. Develop use cases
By using user use goal technique
|
user |
User goal and resulting use case |
|
Potential patient |
· Create account · Schedule appointment · View medication prescription · View directions for taking medication · View lab reports · Send a message |
|
doctors |
· Make appointment schedule · Make lab reports |
|
staff |
· Register current users |
2.1 Using the Community Patient Portal System Part 1 and Community Patient Portal System Part 2 case study , create a list of all actors. Create a definition for each actor. Use the format “A (n) actorName is a ….” and then complete the sentence. For example, "A Student is a Person who is enrolled in a University." Place your actors and definitions in a table with 2 columns, one for Actor and the other for the definition.
An actor is an UML name for end users or also can be define as something that interacts with the system. The list of actors from the case study include
i. Patients
ii. Doctors
iii. Staffs
iv. HIPPA electronic health record system
A patient is a person who is seeking attendance in hospital
A doctor is a person attending to patients
A staff is an employee who assist on various operations
HIPPA is a system that keeps health records
|
actors |
definition |
|
Patient |
Person seeking hospital attendance |
|
doctors |
Person, employee attending to patients |
|
staff |
Employee assisting on various operations |
|
HIPPA |
Integrated system that keeps health record’s |
2.2 Use the user goal technique and/or the event decomposition technique to create a list of use cases for each actor identified above. A use case can be used by more than one actor. Define/describe each use case. Place the use cases and descriptions in a table with 2 columns, one for the Use Case name and the other for the Description/Definition.
|
user |
User goal and resulting use case |
|
patient |
· Create account · Schedule appointment · View medication prescription · View directions for taking medication · View lab reports · Send a message · Refill prescription |
|
doctors |
· Make appointment schedule · Make lab reports |
|
staff |
· Register current users |
|
HIPPA(system) |
· Recording system |
2.3 Using the CASE tool, draw a UML use case diagram following the notation conventions in your textbook and CASE tool.
A use case diagram is a UML diagram used to graphically show use cases and their relationship to actors
2.4 Use the event decomposition technique and create a list of use cases for each event. Name the event, state the type of event, and name and define the resulting use case.
An event is something that occurs that occurs at a specific time and place can be described and should be remembered by the system
Event decomposition is a type of use case technique that is more comprehensive
|
Events |
Type of event |
Use case |
|
Patients creates account |
external |
Create an account |
|
Patient setups two step verification |
external |
|
|
Patients logins into system
|
external |
Account verified |
|
Patients makes appointment
|
external |
Process appointment creation |
|
Display currently scheduled appointment
|
temporal |
Process appointment creation |
|
Patients schedule appointment |
external |
|
|
Patients select view medication |
external |
Process prescription refill |
|
List medication |
temporal |
|
|
Patient refill prescription
|
external |
|
|
Patient select view lab results |
external |
Generate lab report |
|
Display lab report results
|
|
|
|
Patient select date displayed
|
|
|
|
Display results
|
|
|
|
Patient views lab results |
|
|
|
Patient prints lab results |
|
|
3. Develop a class diagram
3.1 Using the two discussions for the CPPS case study and the noun analysis technique, identify potential classes from your noun analysis.
Medication
Appointment
Patient
Account
Report
Test
Message
LabResult
3.2 Create a table of the classes with the class name in one column and the definition in the other. For the definition, use the format “A (n) className is a ….” and then complete the sentence.
|
Class name
|
definition |
|
patient |
A patient is a person who creates account in the cpps system |
|
account |
An account is a registration created by patient |
|
appointment |
An appointment is a schedule created by patient |
|
medication |
A medication is a prescription by the doctor |
|
labResult |
A labResult is a report from a test |
|
test |
A test is a labResult that is detailed |
|
report |
A report is a test that is generates results |
|
message |
A message is a text that has recipient |
3.3 Identify the relationships among the classes.
There is binary relationship or association between the classes where the multiplicity varies between different associations among the classes
Unary relationship is between labResult and test
3.4 Create a UML class diagram using the classes you have identified and add names to the associations and multiplicity constraints.
Class diagram is a UML diagram that shows classes with attributes and associations
Associations is a natural occurring relationship between classes
Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many
3.5 What are your impressions of the noun technique?
· It quickly help identify classes
· Ends up with a list of many nouns that cannot even be stored on the system
· It’s a good start point for beginners when there is nobody to help in brainstorming
· It’s a popular and much simpler technique
3.6 How can you use the CRUD technique to verify and validate your use cases?
CRUD stands for create, read/report, update and delete. You can use this technique to validate your use cases by following the following steps
· You must identify all the entities and domain classes involved in the new system
· You must verify that a use case has been identified that creates new instance, updates existing instance, reads or reports values of instances
· When a needed use case has been overlooked add a new use case and then identify the stakeholders
· Make sure it’s clear which application is responsible for adding and maintain the data
Week 2/ENTD311_CASE2/Community Patient Portal System Part 1.pdf
CPPS Part 1 Page 1
Community Patient Portal System (CPPS) Case Study Part 1 Community Patient Group (CPO) is a well-established, full service internal medicine practice with five offices with 10 doctors each and wants to provide web based services for its patients and integrate it with their HIPPA electronic health record system. Each doctor sees approximately 2500 patients per year. CPO plans to establish a patient portal as a secure online website with access to personal health information and medical records. This service would be available 24/7. They feel that this new service will improve patient outcomes and make it more convenient for their patients. They also feel that it will reduce the number of phone calls. The program also may qualify the service for incentives according to the American Recovery and Reinvestment Act of 2009. They want to offer three levels of services for their patients including Basic Portal, Advanced Portal, and Premium Portal. The proposed general services for patients include schedule appointments; view lab and other reports; view medical history; request prescription refills; update contact information, check benefits and coverage; check account balances; submit forms; and send messages to providers. The proposed levels of service provide the following services: • Basic Portal is free and provides access to lab reports • Advanced Portal provides access to current and past lab test results,
medications lists, medical history records, and appointment scheduling online. Patients can also request referrals and receive free prescription refills. This can avoid unnecessary appointments, co-pays, and prescription refill fees. The cost is $120 per year.
• Premium Portal includes all of the benefits of the Advanced Portal plus three "e-Visits" (a secure virtual appointment with your provider) for $240 / year.
To get patients registered they plan to start a marketing campaign that includes letters to current patients; brochures; fliers; notices and information on their website; and training of staff to explain the new service and to register current patients. Patients can also register online at their website.
Week 2/ENTD311_CASE2/Community Patient Portal System Part 2.pdf
CPPS Part 2 Page 1
Community Patient Portal System (CPPS) Case Study Part 2 As previously discussed the CPPS need to provide general services for patients that include the ability to schedule appointments; view lab and other reports; view medical history; request prescription refills; update contact information, check benefits and coverage; check account balances; submit forms; and send messages to providers (doctors). In order to provide these services, the system must also maintain the doctor’s appointment schedule including the days and times the doctor is available. Other information will come from the existing CPS (Community Patient System) which maintains details on the patient including patient employment, insurance, and other personal information. The system will also need access to lab reports, patient’s medical history, prescription details, account details, and other information. The following describes some of the services provided: Create CPPS Account In order to use the CPPS, the patient will require an existing account and then log in to the account. To create an account the patient will have to provide first and last name, address (street, city, state, and zipcode), username (account id), password twice (for security), and email account. The patient can also set up a two-step verification process for signing in on a new device or new location. If they already have an account, then they can just log in. The username is the same as their Account ID which is issued to each new patient. Login to CPPS If a patient already has an account, then they can just log in by entering their user id and password into a login in area. The username is the same as their Account ID which is issued to each new patient and must be verified. Login verification, if set up, requires the user to complete a two-step process: login and then a verification of predetermined information like a verified phone number or a confirmed email address. The login information must be validated. Make an Appointment In order to select the option to make an appointment, the patient must already be logged in to the CPPS. Scheduling an appointment requires that the system have access to the doctor’s appointment schedule including days and times.
CPPS Part 2 Page 2
After logging in, the patient can select an option to make an appointment. The system will display any currently scheduled appointment. Then the patient and select an option to Schedule an Appointment. The system will provide an Appointment Web Page where the patient can then select their doctor, appointment type (like Office Visit), and enter an appointment date by typing it in or using a calendar option to select a date. With a calendar options, a calendar is displayed for the current month and with arrows to scroll between months and years. The patient can scroll to the correct year and month and then select a day of the month from the calendar. Thus the appointment date and time is selected. The patient can then select the option to find available times that match the doctor’s schedule. The system will then search the doctor’s schedule and display all of the available times for the doctor on that date. If none of the times are convenient or available, the patient can search for the time on the previous or next day. If the patient finds a good time and selects it, the system will display a summary including the patient name, appointment date and time, appointment type, length of appointment, doctor name, and location. The patient must then enter a brief description regarding the reason for the appointment. The patient can then schedule the appointment or cancel the appointment. To cancel the appointment, the patient selects the cancel option and then is requested to confirm the cancellation. Refill Prescription In order to select the option to view refill a prescription, the patient must already be logged in to the CPPS. If a patient selects the option to view medications, the system will list the medication including name and units, directions for taking the medication, and the date prescribed. The patient can then select the option to refill. View Lab Results In order to select the option to view lab results, the patient must already be logged in to the CPPS. The patient can then select the Lab Results option and the system will display a list of dates for lab report results. After the patient selects the date, the system will display a report for the results from the lab. The lab report would include the test with its code, any notes, and then for each test the name of the test, the value, the units, any flags, and the Normal range. The patient has the option to view and or print the results. The printed report includes the name of the practice, patient name, DOB, ordering physician, date and time collected, date and time reported, and the name of the test, the value, the units, any flags, and the Normal range.
CPPS Part 2 Page 3
Send a Message In order to select the option to send a message, the patient must already be logged in to the CPPS. If the patient selects the option to send a message, the system provides an area for the patient to select the receiver of the message, add a short subject, and add a message (up to 150 words). Once the patient has finished the message, they may select the option to send the message or cancel. If the patient elects to send the message, it will be forwarded to the recipient’s mailbox. If the patient decides to cancel the message, the main area of the application will be displayed.
Week 2/ENTD311_CASE2/ENTD311_Assignment_CaseStudy2.docx
Instructions
1. Setup a CASE Tool. (ATTACHED)
1.1 Follow the instructions in the document in Lessons -> Week 2 -> Readings and Resources -> Case Tool Resources area for details and links for installing a Community Edition (free) of a Case Tool. (ATTACHED) This is at the bottom of the section.
2. Develop use cases
2.1 Using the Community Patient Portal System Part 1 (ATTACHED) and Community Patient Portal System Part 2 (ATTACHED) case study , create a list of all actors. Create a definition for each actor. Use the format "A(n) actorName is a ….” and then complete the sentence. For example, "A Student is a Person who is enrolled in a University." Place your actors and definitions in a table with 2 columns, one for Actor and the other for the definition.
2.2 Use the user goal technique and/or the event decomposition technique to create a list of use cases for each actor identified above. A use case can be used by more than one actor. Define/describe each use case. Place the use cases and descriptions in a table with 2 columns, one for the Use Case name and the other for the Description/Definition.
2.3 Using the CASE tool, draw a UML use case diagram following the notation conventions in your textbook and CASE tool.
2.4 Use the event decomposition technique and create a list of use cases for each event. Name the event, state the type of event, and name and define the resulting use case.
3. Develop a class diagram
3.1 Using the two discussions for the CPPS case study and the noun analysis technique, identify potential classes from your noun analysis.
3.2 Create a table of the classes with the class name in one column and the definition in the other. For the definition, use the format "A(n) className is a ….” and then complete the sentence.
3.3 Identify the relationships among the classes.
3.4 Create a UML class diagram using the classes you have identified and add names to the associations and multiplicity constraints.
3.5 What are your impressions of the noun technique?
3.6 How can you use the CRUD technique to verify and validate your use cases?
Submission Instructions
1. Submit your assignment in a Word file and name it like LastNameFirstNameAssignment2.
2. Make certain that you include the above questions with the answers in your document. Clearly mark the questions and answers you submit following the numbering in the assignment steps above .
3 Include your name and assignment number at the top of your Word document.
4. Insert any graphics into your Word document. Do not submit graphics separately.
Your assignment will be graded with the following rubric:
|
Rubric for Assignments |
Points |
|
Content & Development 50% |
50/50 |
|
Organization 20% |
20/20 |
|
Format 10% |
10/10 |
|
Grammar, Punctuation, & Spelling 15% |
15/15 |
|
Readability & Style 5% |
5/5 |
|
Timeliness (late deduction 10 points) Optional |
|
|
Total |
100/100
|
Week 2/ENTD311_CASE2/SADCW_6e_Chapter3.ppt
Chapter 3
Systems Analysis and Design in a Changing World, 6th Edition
Use Cases
Systems Analysis and Design in a Changing World 6th Ed
Satzinger, Jackson & Burd
Chapter 3
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 3 Outline
- Use Cases and User Goals
- Use Cases and Event Decomposition
- Use Cases and CRUD
- Use Cases in the Ridgeline Mountain Outfitters Case
- User Case Diagrams
Systems Analysis and Design in a Changing World, 6th Edition
Learning Objectives
- Explain why identifying use cases is the key to defining functional requirements
- Describe the two techniques for identifying use cases
- Apply the user goal technique to identify use cases
- Apply the event decomposition technique to identify use cases
- Apply the CRUD technique to validate and refine the list of use cases
- Describe the notation and purpose for the use case diagram
- Draw use case diagrams by actor and by subsystem
Systems Analysis and Design in a Changing World, 6th Edition
Overview
- Chapter 2 provided an overview of systems analysis activities, functional and non-functional requirements, modeling, and information gathering techniques
- This chapter focuses on identifying and modeling the key aspect of functional requirements– use cases
- In the RMO Tradeshow System from Chapter 1, some use cases are Look up supplier, Enter/update product information, Enter/Update contact information
- In this chapter’s opening case Waiters on Call, examples of use cases are Record an order, Record delivery, Update an order, Sign in driver, Reconcile driver receipts, Produce end of day deposit slip, and Produce weekly sales reports
Systems Analysis and Design in a Changing World, 6th Edition
Use Cases
- Use case— an activity that the system performs, usually in response to a request by a user
- Use cases define functional requirements
- Analysts decompose the system into a set of use cases (functional decomposition)
- Two techniques for Identifying use cases
- User goal technique
- Event decomposition technique
- Name each use case using Verb-Noun
Systems Analysis and Design in a Changing World, 6th Edition
User Goal Technique
- This technique is the most common in industry
- Simple and effective
- Identify all of the potential categories of users of the system
- Interview and ask them to describe the tasks the computer can help them with
- Probe further to refine the tasks into specific user goals, “I need to Ship items, Track a shipment, Create a return”
Systems Analysis and Design in a Changing World, 6th Edition
User Goal Technique
Some RMO CSMS Users and Goals
Systems Analysis and Design in a Changing World, 6th Edition
User Goal Technique:
Specific Steps
Identify all the potential users for the new system
Classify the potential users in terms of their functional role (e.g., shipping, marketing, sales)
Further classify potential users by organizational level (e.g., operational, management, executive)
For each type of user, interview them to find a list of specific goals they will have when using the new system (current goals and innovative functions to add value)
Systems Analysis and Design in a Changing World, 6th Edition
User Goal Technique
Specific Steps (continued)
Create a list of preliminary use cases organized by type of user
Look for duplicates with similar use case names and resolve inconsistencies
Identify where different types of users need the same use cases
Review the completed list with each type of user and then with interested stakeholders
Systems Analysis and Design in a Changing World, 6th Edition
Event Decomposition Technique
- More Comprehensive and Complete Technique
- Identify the events that occur to which the system must respond.
- For each event, name a use case (verb-noun) that describes what the system does when the event occurs
- Event– something that occurs at a specific time and place, can be described, and should be remembered by the system
Systems Analysis and Design in a Changing World, 6th Edition
Events and Use Cases
Systems Analysis and Design in a Changing World, 6th Edition
Types of Events
- External Event
- an event that occurs outside the system, usually initiated by an external agent or actor
- Temporal Event
- an event that occurs as a result of reaching a point in time
- State Event
- an event that occurs when something happens inside the system that triggers some process
- reorder point is reached for inventory item
Systems Analysis and Design in a Changing World, 6th Edition
External Event Checklist
- External agent or actor wants something resulting in a transaction
- Customer buys a product
- External agent or actor wants some information
- Customer wants to know product details
- External data changed and needs to be updated
- Customer has new address and phone
- Management wants some information
- Sales manager wants update on production plans
Systems Analysis and Design in a Changing World, 6th Edition
Temporal Event Checklist
- Internal outputs needed at points in time
- Management reports (summary or exception)
- Operational reports (detailed transactions)
- Internal statements and documents (including payroll)
- External outputs needed at points of time
- Statements, status reports, bills, reminders
Systems Analysis and Design in a Changing World, 6th Edition
Finding the actual event that affects the system
Systems Analysis and Design in a Changing World, 6th Edition
Tracing a sequence of transactions resulting in many events
Systems Analysis and Design in a Changing World, 6th Edition
Perfect Technology Assumption
- Don’t worry about functions built into system because of limits in technology and people. Wait until design.
Systems Analysis and Design in a Changing World, 6th Edition
Event Decomposition Technique:
Specific Steps
Consider the external events in the system environment that require a response from the system by using the checklist shown in Figure 3-3
For each external event, identify and name the use case that the system requires
Consider the temporal events that require a response from the system by using the checklist shown in Figure 3-4
For each temporal event, identify and name the use case that the system requires and then establish the point of time that will trigger the use case
Systems Analysis and Design in a Changing World, 6th Edition
Event Decomposition Technique:
Specific Steps (continued)
Consider the state events that the system might respond to, particularly if it is a real-time system in which devices or internal state changes trigger use cases.
For each state event, identify and name the use case that the system requires and then define the state change.
When events and use cases are defined, check to see if they are required by using the perfect technology assumption. Do not include events that involve such system controls as login, logout, change password, and backup or restore the database, as these are put in later.
Systems Analysis and Design in a Changing World, 6th Edition
Event Decomposition Technique: Benefits
- Events are broader than user goal: Capture temporal and state events
- Help decompose at the right level of analysis: an elementary business process (EBP)
- EBP is a fundamental business process performed by one person, in one place, in response to a business event
- Uses perfect technology assumption to make sure functions that support the users work are identified and not additional functions for security and system controls
Systems Analysis and Design in a Changing World, 6th Edition
Use Cases and CRUD Technique
- CRUD is Create, Read/Report, Update, and Delete (archive)
- Often introduced in database context
- Technique to validate, refine or cross-check use cases
- NOT for primarily identifying use cases
Systems Analysis and Design in a Changing World, 6th Edition
Use Cases and CRUD Technique
- For Customer domain class, verify that there are use cases that create, read/report, update, and delete (archive) the domain class
Systems Analysis and Design in a Changing World, 6th Edition
CRUD Technique
Steps
Identify all the data entities or domain classes involved in the new system. (more in Chapter 4)
For each type of data (data entity or domain class), verify that a use case has been identified that creates a new instance, updates existing instances, reads or reports values of instances, and deletes (archives) an instance.
If a needed use case has been overlooked, add a new use case and then identify the stakeholders.
With integrated applications, make sure it is clear which application is responsible for adding and maintaining the data and which system merely uses the data.
Systems Analysis and Design in a Changing World, 6th Edition
CRUD Technique
Use Case vs. Domain Class Table
- To summarize CRUD analysis results, create a matrix of use cases and domain classes indicating which use case C, R, U, or D a domain class
Systems Analysis and Design in a Changing World, 6th Edition
Use Cases and
Brief Use Case Descriptions
- Brief use case description is often a one sentence description showing the main steps in a use case
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project Use Cases
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project Use Cases
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project Use Cases
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project Use Cases
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Diagrams
- Use case diagram— a UML model used to graphically show uses cases and their relationships to actors
- Recall UML is Unified Modeling Language, the standard for diagrams and terminology for developing information systems
- Actor is the UML name for a end user
- Automation boundary— the boundary between the computerized portion of the application and the users who operate the application
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Diagrams
Symbols
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Diagrams
Draw for each subsystem
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Diagrams
Draw for actor, such as customer
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Diagrams
Draw for internal RMO actors
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Diagrams
The <<Includes>> relationship
- A relationship between use cases where one use case is stereotypically included within the other use case— like a called subroutine. Arrow points to subroutine
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Diagrams:
Steps
Identify all the stakeholders and users who would benefit by seeing a use case diagram
Determine what each stakeholder or user needs to review in a use case diagram: each subsystem, for each type of user, for use cases that are of interest
For each potential communication need, select the use cases and actors to show and draw the use case diagram. There are many software packages that can be used to draw use case diagrams
Carefully name each use case diagram and then note how and when the diagram should be used to review use cases with stakeholders and users
Systems Analysis and Design in a Changing World, 6th Edition
Summary
- This chapter is the first of three that focuses on modeling functional requirements as a part of systems analysis
- Use cases are the functions identified, the activities the system carries out usually in response to a user request
- Two techniques for identifying use cases are the user goal technique and the event decomposition technique
- The user goal technique begins by identifying end users called actors and asking what specific goals they have when interacting with the system
- The event decomposition technique begins by identifying events that occur that require the system to respond.
Systems Analysis and Design in a Changing World, 6th Edition
Summary
- Three types of events include external, temporal, and state events
- Brief use case descriptions are written for use cases
- The CRUD technique is used to validate and refine the use cases identified
- The use case diagram is the UML diagram used to show the use cases and the actors
- The use case diagram shows the actors, the automation boundary, the uses cases that involve each actor, and the <<includes>> relationship.
- A variety of use case diagrams are draw depending on the presentation needs of the analysis
Systems Analysis and Design in a Changing World, 6th Edition
Week 2/ENTD311_CASE2/SADCW_6e_Chapter4.ppt
Chapter 4
Systems Analysis and Design in a Changing World, 6th Edition
Domain Classes
Systems Analysis and Design in a Changing World 6th Ed
Satzinger, Jackson & Burd
Chapter 4
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 4 Outline
- “Things” in the Problem Domain
- Data entities
- Domain classes
- The Domain Model Class Diagram
- The Entity-Relationship Diagram
Systems Analysis and Design in a Changing World, 6th Edition
Learning Objectives
- Explain how the concept of “things” in the problem domain also define requirements
- Identify and analyze data entities and domain classes needed in the system
- Read, interpret, and create an entity-relationship diagram
- Read, interpret, and create a domain model class diagram
- Understand the domain model class diagram for the RMO Consolidated Sales and Marketing System
Systems Analysis and Design in a Changing World, 6th Edition
Overview
- Chapter 3 provided an overview of identifying use cases to define functional requirements
- This chapter focuses on another key concepts for defining requirements— data entities or domain classes
- In the RMO Tradeshow System from Chapter 1, some domain classes are Supplier, Product, and Contact
- In this chapter’s opening case Waiters on Call, examples of domain classes are Restaurants, Menu items, Customers, Orders, Drivers, Addresses, Routes, and Payments
Systems Analysis and Design in a Changing World, 6th Edition
Things in the Problem Domain
- Problem domain—the specific area (or domain) of the users’ business need that is within the scope of the new system.
- “Things” are those items users work with when accomplishing tasks that need to be remembered
- Examples of “Things” are products, sales, shippers, customers, invoices, payments, etc.
- These “Things” are modeled as domain classes or data entities
- In this course, we will call them domain classes. In database class you call them data entities
Systems Analysis and Design in a Changing World, 6th Edition
Things in the Problem Domain
Two Techniques for Identifying them
- Brainstorming Technique
- Use a checklist of all of the usual types of things typically found and brainstorm to identify domain classes of each type
- Noun Technique
- Identify all of the nouns that come up when the system is described and determine if each is a domain class, an attribute, or not something we need to remember
Systems Analysis and Design in a Changing World, 6th Edition
Brainstorming Technique
- Are there any tangible things? Are there any organizational units? Sites/locations? Are there incidents or events that need to be recorded?
Systems Analysis and Design in a Changing World, 6th Edition
Brainstorming Technique:
Steps
Identify a user and a set of use cases
Brainstorm with the user to identify things involved when carrying out the use case—that is, things about which information should be captured by the system.
Use the types of things (categories) to systematically ask questions about potential things, such as the following: Are there any tangible things you store information about? Are there any locations involved? Are there roles played by people that you need to remember?
Continue to work with all types of users and stakeholders to expand the brainstorming list
Merge the results, eliminate any duplicates, and compile an initial list
Systems Analysis and Design in a Changing World, 6th Edition
The Noun Technique
- A technique to identify problem domain classes (things) by finding, classifying, and refining a list of nouns that come up in in discussions or documents
- Popular technique. Systematic.
- Does end up with long lists and many nouns that are not things that need to be stored by the system
- Difficulty identifying synonyms and things that are really attributes
- Good place to start when there are no users available to help brainstorm
Systems Analysis and Design in a Changing World, 6th Edition
Partial List of Nouns for RMO
With notes on whether to include as domain class
Systems Analysis and Design in a Changing World, 6th Edition
The Noun Technique:
Steps
Using the use cases, actors, and other information about the system— including inputs and outputs—identify all nouns.
- For the RMO CSMS, the nouns might include customer, product item, sale, confirmation, transaction, shipping, bank, change request, summary report, management, transaction report, accounting, back order, back order notification, return, return confirmation…
Using other information from existing systems, current procedures, and current reports or forms, add items or categories of information needed.
- For the RMO CSMS, these might include price, size, color, style, season, inventory quantity, payment method, and shipping address.
Systems Analysis and Design in a Changing World, 6th Edition
The Noun Technique:
Steps (continued)
As this list of nouns builds, refine it. Ask these questions about each noun to help you decide whether you should include it:
- Is it a unique thing the system needs to know about?
- Is it inside the scope of the system I am working on?
- Does the system need to remember more than one of these items?
Ask these questions to decide to exclude it:
- Is it really a synonym for some other thing I have identified?
- Is it really just an output of the system produced from other information I have identified?
- Is it really just an input that results in recording some other information I have identified?
Ask these questions to research it:
- Is it likely to be a specific piece of information (attribute) about some other thing I have identified?
- Is it something I might need if assumptions change?
Systems Analysis and Design in a Changing World, 6th Edition
The Noun Technique:
Steps (continued)
Create a master list of all nouns identified and then note whether each one should be included, excluded, or researched further.
Review the list with users, stakeholders, and team members and then define the list of things in the problem domain.
Systems Analysis and Design in a Changing World, 6th Edition
Details about Domain Classes
- Attribute— describes one piece of information about each instance of the class
- Customer has first name, last name, phone number
- Identifier or key
- One attribute uniquely identifies an instance of the class. Required for data entities, optional for domain classes. Customer ID identifies a customer
- Compound attribute
- Two or more attributes combined into one structure to simplify the model. (E.g., address rather than including number, street, city, state, zip separately). Sometimes an identifier or key is a compound attribute.
Systems Analysis and Design in a Changing World, 6th Edition
Attributes and Values
- Class is a type of thing. Object is a specific instance of the class. Each instance has its own values for an attribute
Systems Analysis and Design in a Changing World, 6th Edition
Associations Among Things
- Association— a naturally occurring relationship between classes (UML term)
Systems Analysis and Design in a Changing World, 6th Edition
Just to Clarify…
- Called association on class diagram in UML
- Multiplicity is term for the number of associations between classes: 1 to 1 or 1 to many
- We are emphasizing UML in this text
- Called relationship on ERD in database class
- Cardinality is term for number of relationships in entity relationship diagrams: 1 to 1 or 1 to many
- Associations and Relationships apply in two directions
- Read them separately each way
- A customer places an order
- An order is placed by a customer
Systems Analysis and Design in a Changing World, 6th Edition
Minimum and Maximum Multiplicity
- Associations have minimum and maximum constraints
- minimum is zero, the association is optional
- If minimum is at least one, the association is mandatory
Systems Analysis and Design in a Changing World, 6th Edition
Types of Associations
- Binary Association
- Associations between exactly two different classes
- Course Section includes Students
- Members join Club
- Unary Association (recursive)
- Associations between two instances of the same class
- Person married to person
- Part is made using parts
- Ternary Association (three)
- N-ary Association (between n)
Systems Analysis and Design in a Changing World, 6th Edition
Semantic Net
Shows instances and how they are linked
Example shows instances of three classes
Quick quiz:
How many associations are there?
What are the minimum and maximum multiplicities in each direction?
What type of associations are they?
Systems Analysis and Design in a Changing World, 6th Edition
The Domain Model Class Diagram
- Class
- A category of classification used to describe a collection of objects
- Domain Class
- Classes that describe objects in the problem domain
- Class Diagram
- A UML diagram that shows classes with attributes and associations (plus methods if it models software classes)
- Domain Model Class Diagram
- A class diagram that only includes classes from the problem domain, not software classes so no methods
Systems Analysis and Design in a Changing World, 6th Edition
Domain Class Notation
- Domain class has no methods
- Class name is always capitalized
- Attribute names are not capitalized and use camelback notation (words run together and second word is capitalized)
Systems Analysis and Design in a Changing World, 6th Edition
A Simple Domain Model Class Diagram
- Note: This diagram matches the semantic net shown previously
- A customer places zero or more orders
- An order is placed by exactly one customer
- An order consists of one or more order items
- An order item is part of exactly one order
Systems Analysis and Design in a Changing World, 6th Edition
UML Notation for Multiplicity
Systems Analysis and Design in a Changing World, 6th Edition
Domain Model Class Diagram
for a bank with many branches
Systems Analysis and Design in a Changing World, 6th Edition
Domain Model Class Diagram
for course enrollment at a university
- Where is each student’s grade remembered in this model?
- Each section has many grades and each grade is association with a student
- Each student has many grades and each grade is association with a section
Systems Analysis and Design in a Changing World, 6th Edition
Refined Course Enrollment Model
with an Association Class CourseEnrollment
- Association class— an association that is treated as a class in a many to many association because it has attributes that need to be remembered, such as grade
Systems Analysis and Design in a Changing World, 6th Edition
More Complex Issues about Classes:
Generalization/Specialization Relationships
- Generalization/Specialization
- A hierarchical relationship where subordinate classes are special types of the superior classes. Often called an Inheritance Hierarchy
- Superclass
- the superior or more general class in a generalization/specialization hierarchy
- Subclass
- the subordinate or more specialized class in a generalization/specialization hierarchy
- Inheritance
- the concept that subclasses classes inherit characteristics of the more general superclass
Systems Analysis and Design in a Changing World, 6th Edition
Generalization/Specialization
Inheritance
Systems Analysis and Design in a Changing World, 6th Edition
Generalization/Specialization
Inheritance for RMO Three Types of Sales
- Abstract class— a class that allow subclasses to inherit characteristics but never gets instantiated. In Italics (Sale above)
- Concrete class— a class that can have instances
Systems Analysis and Design in a Changing World, 6th Edition
Generalization/Specialization
Inheritance for the Bank with Special Types of Accounts
- A SavingsAccount has 4 attributes
- A CheckingAccount Has 5 attributes
- Note: the subclasses inherit the associations, too
Systems Analysis and Design in a Changing World, 6th Edition
More Complex Issues about Classes:
Whole Part Relationships
- Whole-part relationship— a relationship between classes where one class is part of or a component portion of another class
- Aggregation— a whole part relationship where the component part exists separately and can be removed and replaced (UML diamond symbol, next slide)
- Computer has disk storage devices
- Car has wheels
- Composition— a whole part relationship where the parts can no longer be removed (filled in diamond symbol)
- Hand has fingers
- Chip has circuits
Systems Analysis and Design in a Changing World, 6th Edition
Whole Part Relationships
Computer and its Parts
- Note: this is composition, with diamond symbol.
- Whole part can have multiplicity symbols, too (not shown)
Systems Analysis and Design in a Changing World, 6th Edition
More on UML Relationships
- There are actually three types of relationships in class diagrams
- Association Relationships
- These are associations discussed previously, just like ERD relationships
- Whole Part Relationships
- One class is a component or part of another class
- Generalizations/Specialization Relationships
- Inheritance
- So, try not to confuse relationship with association
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project
Domain Model Class Diagrams
- There are several ways to create the domain model class diagram for a project
- RMO CSMS has 27 domain classes overall
- Can create one domain model class diagram per subsystem for those working on a subsystem
- Can create one overall domain model class diagram to provide an overview of the whole system
- Usually in early iterations, an initial draft of the domain model class diagram is completed to guide development and kept up to date
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project
Domain Model Class Diagrams
- There are several ways to create the domain model class diagram for a project
- RMO CSMS has 27 domain classes overall
- Can create one domain model class diagram per subsystem for those working on a subsystem
- Can create one overall domain model class diagram to provide an overview of the whole system
- Usually in early iterations, an initial draft of the domain model class diagram is completed to guide development and kept up to date
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project
Sales Subsystem Domain Model Class Diagrams
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project
Customer Account Subsystem Domain Model Class Diagram
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project
Complete Domain Model Class Diagram
Systems Analysis and Design in a Changing World, 6th Edition
RMO CSMS Project
Domain Model Class Diagrams
- Given the complete RMO CSMS Domain Model Class Diagram and Sales and Customer Account subsystem examples:
- Try completing the Order Fulfilment Subsystem Domain Model Class Diagram
- Try Completing the Marketing Subsystem Domain Model Class Diagram
- Try Completing the Reporting Subsystem Domain Model Class Diagram
- Review the use cases from Chapter 3 and decide what classes and associations from the complete model are required for each subsystem
- Classes and associations might be duplicated in more than one subsystem model
Systems Analysis and Design in a Changing World, 6th Edition
Entity-Relationship Diagrams
ERD
- An ERD shows basically the same information as a domain model class diagram
- It is not a UML diagram, but it is widely used by data analysts in database management
- There really is no standard notation, but most developers use the entity and crows feet notation shown in this text
- An ERD is not good for showing generalization/specialization relationships and whole part relationships
Systems Analysis and Design in a Changing World, 6th Edition
Example of ERD Notation
- A simple ERD without showing attributes
Systems Analysis and Design in a Changing World, 6th Edition
ERD Cardinality Symbols
often called the crows feet notation
Systems Analysis and Design in a Changing World, 6th Edition
Expanded ERD with Attributes
- Note: This diagram matches the semantic net shown previously
- Also matches a domain model class diagram shown previously
Systems Analysis and Design in a Changing World, 6th Edition
An ERD for a Bank
Systems Analysis and Design in a Changing World, 6th Edition
Summary
- This chapter is the second of three that focuses on modeling functional requirements as a part of systems analysis
- “Things” in the problem domain are identified and modeled, called domain classes or data entities
- Two techniques for identifying domain classes/data entities are the brainstorming technique and the noun technique
- Domain classes have attributes and associations
- Associations are naturally occurring relationships among classes, and associations have minimum and maximum multiplicity
Systems Analysis and Design in a Changing World, 6th Edition
Summary
- The UML class diagram notation is used to create a domain model class diagram for a system. The domain model classes do not have methods because they are not yet software classes.
- There are actually three UML class diagram relationships: association relationships, generalization/specialization (inheritance) relationships, and whole part relationships
- Other class diagram concepts are abstract versus concrete classes, compound attributes, composition and aggregation, association classes, super classes and subclasses
Systems Analysis and Design in a Changing World, 6th Edition
Summary
- Entity-relationship diagrams (ERDs) show the same information as a domain model class diagram
- ERDs are preferred by database analysts and are widely used
- ERDs are not UML diagrams, and an association is called a relationship, multiplicity is called cardinality, and generalization/specialization (inheritance) and whole part relationships are usually not shown
Systems Analysis and Design in a Changing World, 6th Edition
Week 2/ENTD311_CASE2/SADCW_6e_Chapter5.ppt
Chapter 5
Systems Analysis and Design in a Changing World, 6th Edition
Extending the Requirements Models
Systems Analysis and Design in a Changing World 6th Ed
Satzinger, Jackson & Burd
Chapter 5
Systems Analysis and Design in a Changing World, 6th Edition
Chapter 5 Outline
- Use Case Descriptions
- Activity Diagrams for Use Cases
- The System Sequence Diagram—Identifying Inputs and Outputs
- The State Machine Diagram—Identifying Object Behavior
- Integrating Requirements Models
Systems Analysis and Design in a Changing World, 6th Edition
Learning Objectives
- Write fully developed use case descriptions
- Develop activity diagrams to model flow of activities
- Develop system sequence diagrams
- Develop state machine diagrams to model object behavior
- Explain how use case descriptions and UML diagrams work together to define functional requirements
Systems Analysis and Design in a Changing World, 6th Edition
Overview
- Chapters 3 and 4 identified and modeled the two primary aspects of functional requirements: use cases and domain classes
- This chapter focuses on additional techniques and models to extend the requirements models to show more detail
- Fully developed use case descriptions provide information about each use case, including actors, stakeholders, preconditions, post conditions, the flow of activities and exceptions conditions
- Activity diagrams (first shown in Chapter 2) can also be used to show the flow of activities for a use case
Systems Analysis and Design in a Changing World, 6th Edition
Overview (continued)
- System sequence diagrams (SSDs) show the inputs and outputs for each use case as messages
- State machine diagrams show the states an object can be in over time between use cases
- Use cases are modeled in more detail using fully developed use case descriptions, activity diagrams, and system sequence diagrams
- Domain classes are modeled in more detail using state machine diagrams
- Not all use cases and domain classes are modeled at this level of detail. Only model when there is complexity and a need to communicate details
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Descriptions
- Write a brief description as shown in Chapter 3 for most use cases.
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Descriptions
- Write a fully developed use case description for more complex use cases
- Typical use case description templates include:
- Use case name
- Scenario (if needed)
- Triggering event
- Brief description
- Actors
- Related use cases (<<includes>>)
- Stakeholders
- Preconditions
- Post conditions
- Flow of activities
- Exception conditions
Systems Analysis and Design in a Changing World, 6th Edition
Fully Developed Use Case Description
Use case: Create customer account
Systems Analysis and Design in a Changing World, 6th Edition
Fully Developed Use Case Description Create customer account (part 1 )
Systems Analysis and Design in a Changing World, 6th Edition
Fully Developed Use Case Description Create customer account (part 2 )
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Description Details
- Related use cases <<includes>>
- If one use case invokes or includes another
- Stakeholders
- Anyone with an interest in the use case
- Preconditions
- What must be true before the use case begins
- Post conditions
- What must be true when the use case is completed
- Use for planning test case expected results
- Flow of activities
- The activities that go on between actor and the system
- Exception conditions
- Where and what can go wrong
Systems Analysis and Design in a Changing World, 6th Edition
Use Case Description Details
- Use case name
- Verb-noun
- Scenario (if needed)
- A use case can have more than one scenario (special case or more specific path)
- Triggering event
- Based on event decomposition technique
- Brief description
- Written previously when use case was identified
- Actors
- One or more users from use case diagrams
Systems Analysis and Design in a Changing World, 6th Edition
Another Fully Developed Use Case Description Example
Use case
Ship items
Systems Analysis and Design in a Changing World, 6th Edition
Fully Developed Use Case Description Ship items (part 1 )
Systems Analysis and Design in a Changing World, 6th Edition
Fully Developed Use Case Description Ship items (part 2 )
Systems Analysis and Design in a Changing World, 6th Edition
UML Activity Diagram for Use Case
Create Customer Account
Note: this shows flow of activities only
Systems Analysis and Design in a Changing World, 6th Edition
UML Activity Diagram for Use Case
Fill shopping cart
Note: this shows use case with <<includes>> reltionship
Systems Analysis and Design in a Changing World, 6th Edition
System Sequence Diagram (SSD)
- A UML sequence diagram
- Special case for a sequence diagram
- Only shows actor and one object
- The one object represents the complete system
- Shows input & output messaging requirements for a use case
- Actor, :System, object lifeline
- Messages
Systems Analysis and Design in a Changing World, 6th Edition
System Sequence Diagram (SSD)
Notation
Systems Analysis and Design in a Changing World, 6th Edition
Message Notation
Systems Analysis and Design in a Changing World, 6th Edition
SSD Message Examples with Loop Frame
Systems Analysis and Design in a Changing World, 6th Edition
SSD Message Examples
Opt Frame (optional)
Alt Frame
(if-else)
Systems Analysis and Design in a Changing World, 6th Edition
Steps for Developing SSD
Identify input message
- See use case flow of activities or activity diagram
Describe the message from the external actor to the system using the message notation
- Name it verb-noun: what the system is asked to do
- Consider parameters the system will need
Identify any special conditions on input messages
- Iteration/loop frame
- Opt or Alt frame
Identify and add output return values
- On message itself: aValue:= getValue(valueID)
- As explicit return on separate dashed line
Systems Analysis and Design in a Changing World, 6th Edition
SSD for Create customer account Use case
Systems Analysis and Design in a Changing World, 6th Edition
SSD for Ship items Use Case
Systems Analysis and Design in a Changing World, 6th Edition
State Machine Diagram
- State machine diagram
- A UML diagram showing the life of an object in states and transitions
- State
- A condition during an object’s life when it satisfies some criterion, performs some action, or waits for an event
- Transition
- The movement of an object from one state to another state
- Action Expression
- A description of activities performed as part of a transition
Systems Analysis and Design in a Changing World, 6th Edition
State Machine Diagram (continued)
- Pseudo state
- The starting point of a state machine diagram (black dot)
- Origin state
- The original state of an object before transition
- Destination state
- The state to which the object moves after the transition
- Guard condition
- A true false test to see whether a transition can fire
Systems Analysis and Design in a Changing World, 6th Edition
State Machine Diagram
for a Printer
Systems Analysis and Design in a Changing World, 6th Edition
Composite States
- State containing other states and transitions
- Printer can be On and either Idle or Working
Systems Analysis and Design in a Changing World, 6th Edition
Concurrent Paths
- Multiple paths in composite state
- Printer On paths are independent
Systems Analysis and Design in a Changing World, 6th Edition
Steps for Developing State Machine Diagram
Review the class diagram and select classes that might require state machine diagrams
For each class, make a list of status conditions (states) you can identify
Begin building diagram fragments by identifying transitions that cause an object to leave the identified state
Sequence these states in the correct order and aggregate combinations into larger fragments
Review paths and look for independent, concurrent paths
Systems Analysis and Design in a Changing World, 6th Edition
Steps for Developing State Machine Diagram (continued)
Look for additional transitions and test both directions
Expand each transition with appropriate message event, guard condition, and action expression
Review and test the state machine diagram for the class
- Make sure state are really state for the object in the class
- Follow the life cycle of an object coming into existence and being deleted
- Be sure the diagram covers all exception condition
- Look again for concurrent paths and composite states
Systems Analysis and Design in a Changing World, 6th Edition
RMO Domain Class States for SaleItem Object
Systems Analysis and Design in a Changing World, 6th Edition
Final State Machine Diagram for SaleItem Object
- addItem() and archive() transitions added
- markBackOrdered() transition added
Systems Analysis and Design in a Changing World, 6th Edition
RMO Domain Class States for Sale Object
Systems Analysis and Design in a Changing World, 6th Edition
Initial State Machine Diagram for RMO Sale Object
Systems Analysis and Design in a Changing World, 6th Edition
Final State Machine Diagram for Sale Object
Systems Analysis and Design in a Changing World, 6th Edition
Extending and Integrating Requirements Models
- Use cases
- Use case diagram
- Use case description
- Activity diagram
- System sequence diagram (SSD)
- Domain Classes
- Domain model class diagram
- State machine diagram
Systems Analysis and Design in a Changing World, 6th Edition
Integrating Requirements Models
Systems Analysis and Design in a Changing World, 6th Edition
Summary
- Chapters 3 and 4 identified and modeled the two primary aspects of functional requirements: use cases and domain classes
- This chapter focuses on additional techniques and models to extend the requirements models to show more detail
- Fully developed use case descriptions provide information about each use case, including actors, stakeholders, preconditions, post conditions, the flow of activities and exceptions conditions
- Activity diagrams (first shown in Chapter 2) can also be used to show the flow of activities for a use case
Systems Analysis and Design in a Changing World, 6th Edition
Summary (continued)
- System sequence diagrams (SSDs) show the inputs and outputs for each use case as messages
- State machine diagrams show the states an object can be in over time between use cases
- Use cases are modeled in more detail using fully developed use case descriptions, activity diagrams, and system sequence diagrams
- Domain classes are modeled in more detail using state machine diagrams
- Not all use cases and domain classes are modeled at this level of detail. Only model when there is complexity and a need to communicate details
Systems Analysis and Design in a Changing World, 6th Edition
Week 2/ENTD311_CASE2/Thumbs.db
Week 2/ENTD311_CASE2/UML Case and Resource Tools 2016.pdf
UML CASE Tools Page 1
UML CASE Tools and Resources 1. Introduction It is suggested that you use the UML modeling tool Visual Paradigm for UML (VP- UML) Community (free) Edition http://www.visual- paradigm.com/download/community.jsp for the assignments in this course. It is available for Windows, Linux, Mac, and Unix. There are many UML tools available, but this tool covers all of the UML models and other diagrams that we will need in this course. Many other professional tools like Sparx Enterprise Architect are available as 30 day evaluation versions. Unfortunately our class is much longer than 30 days. Not all features of the full edition are available in the VP Community Edition but it is sufficient for our purposes. You may also use Microsoft Visio available as a download from our website or Gliffy which has a 5 diagram limit. You may also use other diagramming tools that support Object Oriented UML models. Although you can use Microsoft Word and PowerPoint, they are difficult to use for these models. Whatever tool you use, you must use UML 2.0 modeling standards. See http://en.wikipedia.org/wiki/List_of_UML_tools for a List of Unified Modeling Language Tools. Open source tools are free tools. Note: This is not an endorsement of the Visual Paradigm for UML CASE tool but rather it is recommended since it meets our needs and is a Community edition (free). The remaining resources are for the Visual Paradigm CASE tool and are from the Visual Paradigm website. 2. Visual Paradigm for UML Community (free) Edition Installation Installation
1. Navigate to the free Community edition at http://www.visual- paradigm.com/download/community.jsp .
2. Check the requirements and verify your operating system then download and register for the free edition.
3. You may be prompted from time to time to register, but it seems that you need to make a purchase to do so.
A watermark will be placed at the top of your diagrams if exported. If you create more than one diagram of the same type, a watermark will fill the diagram space but the diagram will still be legible. It will be better to create a screenshot of your diagrams and insert them into Word documents for submission.
UML CASE Tools Page 2
3. VP for UML Videos, Tutorials, and Guidelines At their training website, http://www.visual-paradigm.com/training/, you can register for access to some of their free courses. I encourage you to register so you can view the presentations and videos. These will help you not only with UML but also with using the CASE tool. Not all are free but the following are available. If you join and access the videos by clicking on the Resources button on the right of the screen you can download resources to support the video. VP-UML User Manual
1. Visual Paradigm. (2013, March 18). Visual Paradigm for UML User’s Guide. Retrieved from http://www.visual- paradigm.com/support/documents/vpumluserguide.jsp
Class and Object Diagrams
2. Visual Paradigm. (2009, August 13). Using Class Diagram (Free) [Video file]. Retrieved from http://www.viswiser.com/training/usingclassdiagram.html. Requires registration. This course focuses on class diagram, which covers key elements in class diagram, examples and step-by-step demos. Note: A presentation with interactive video of how to use VP (Visual Paradigm) to create a Class Diagram. It is available to you after you register. This will help you with your Class Diagram assignments.
3. Visual Paradigm. (n.d.). Class Diagram and Object Diagram. Retrieved from http://www.visual- paradigm.com/product/vpuml/features/structuralmodeling.jsp
Use Case Diagrams
4. Visual Paradigm. (2009, July 29). Using use case diagram (Free) – Part 1 – Using Use Case Diagram [Video file]. Retrieved from http://www.viswiser.com/training/usingusecasediagram.html. Requires registration. This course teaches how to draw use case diagram. Part one of the course covers key elements in use case diagram, examples and step-by- step demos. Part two of the course using an online shop system example to provides tutorial on use case modeling technique.
5. Visual Paradigm. (2009, July 22). Using use case diagram (Free) – Part 2 Use Case Diagram Tutorial [Video file]. Retrieved from http://www.viswiser.com/training/usingusecasediagram2.html. Requires registration. This course teaches how to draw use case diagram. Part one of the course covers key elements in use case diagram, examples and step-by-
UML CASE Tools Page 3
step demos. Part two of the course using an online shop system example to provides tutorial on use case modeling technique.
6. Visual Paradigm. (2011, December 8). Writing Effective Use Case.
Retrieved from http://www.visual- paradigm.com/product/vpuml/tutorials/writingeffectiveusecase.jsp
7. Visual Paradigm. (2009, October 9). Document Use Case using Use Case Detail (Free) [Video file]. Retrieved from http://www.viswiser.com/training/documentusecase.html. Requires registration. This course focuses on documenting use case with use case detail, which covers the purpose and key elements in use case detail, glossary, test plan development, examples and step-by-step demos
8. Visual Paradigm. (n.d.). Use Case Diagram and Flow of Events. Retrieved fromhttp://www.visual- paradigm.com/product/vpuml/features/umlmodeling.jsp
9. Visual Paradigm. (2010, August 16). Advanced Use Case Flow of Events Editing. Retrieved from http://www.visual- paradigm.com/product/vpuml/tutorials/flowofeventeditor.jsp
10.Visual Paradigm. (n.d.). Documenting flow of events. Retrieved from http://www.visual- paradigm.com/support/documents/vpumluserguide/94/95/21178_documenti ngf.html
Behavioral Diagrams (Sequence, Communication, Activity, State)
11.Visual Paradigm. (n.d.) Behavioral Modeling. Retrieved from http://www.visual- paradigm.com/product/vpuml/features/behavioralmodeling.jsp
Sequence and Communication Diagrams
12.Visual Paradigm. (2009, August 20). Using Sequence and Communication Diagram (Free) [Video file]. Retrieved from http://www.viswiser.com/training/usingseqcommdiagram.html. Requires registration. This course focuses on sequence and communication diagrams, which covers key elements in sequence and communication diagrams, examples and step-by-step demos.
Timing Diagrams
13.Visual Paradigm. (2009, July 22). Using Timing Diagram (Free) [Video file]. Retrieved from http://www.viswiser.com/training/usingtimingdiagram.html. Requires registration. This course focuses on timing diagram, which covers key elements in timing diagram, examples and step-by-step demos.
UML CASE Tools Page 4
Textual Analysis 14.Visual Paradigm. (2010, December 8). Perform Textual Analysis. Retrieved
from http://www.visual- paradigm.com/product/vpuml/tutorials/textualanalysis.jsp
Requirements 15.Visual Paradigm. (n.d.) Requirements Capturing. Retrieved from
http://www.visual-paradigm.com/product/vpuml/features/reqmodeling.jsp
16.Visual Paradigm. (n.d.). Requirements as Scenarios. Retrieved from http://www.visual-paradigm.com/product/vpuml/features/usecasedetails.jsp
Architectural Modeling (Component Diagram, Deployment Diagram, Package Diagram)
17.Visual Paradigm. (n.d.). Component Diagram and Deployment Diagram. Retrieved from http://www.visual- paradigm.com/product/vpuml/features/architecturalmodeling.jsp
Week 2/ENTD311_CASE2/UML CASE Tool Installation and Videos.docx
UML CASE Tool Installation and Videos
Beginning in Week 2 we will use a CASE tool to develop the UML models for analysis and design. To get a head start, please see UML Case Tools and Resources 2016 for installation instructions for the CASE tool you will need for your assignments. Make certain that you install the Community edition which is free and will be compatible with your classmates’ and my installation. Don’t submit your .VPP files but rather copy your models into a Word file and submit that following your assignment instructions.
In this document you will also find numerous resources including videos and tutorials on the UML models and how to create them in the CASE tool. There are also free courses and a user manual.
Don’t forget to view the Readings and Resources in each of the lessons for additional resources and examples.
