ENTD311_CASE2Community Patient Portal System Part 1.pdfCP.docx

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.
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.
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
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

Chapter 3 OutlineUse Cases and User GoalsUse Cases and
Event DecompositionUse Cases and CRUDUse Cases in the
Ridgeline Mountain Outfitters CaseUser Case Diagrams
Learning ObjectivesExplain why identifying use cases is the key
to defining functional requirementsDescribe the two techniques
for identifying use casesApply the user goal technique to
identify use casesApply the event decomposition technique to
identify use casesApply the CRUD technique to validate and
refine the list of use casesDescribe the notation and purpose for
the use case diagramDraw use case diagrams by actor and by
subsystem
OverviewChapter 2 provided an overview of systems analysis
activities, functional and non-functional requirements,
modeling, and information gathering techniquesThis chapter
focuses on identifying and modeling the key aspect of
functional requirements– use casesIn the RMO Tradeshow
System from Chapter 1, some use cases are Look up supplier,
Enter/update product information, Enter/Update contact
informationIn 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

Use CasesUse case— an activity that the system performs,
usually in response to a request by a userUse cases define
functional requirementsAnalysts decompose the system into a
set of use cases (functional decomposition) Two techniques for
Identifying use casesUser goal techniqueEvent decomposition
techniqueName each use case using Verb-Noun
User Goal TechniqueThis technique is the most common in
industrySimple and effectiveIdentify all of the potential
categories of users of the systemInterview 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”
User Goal Technique
Some RMO CSMS Users and Goals
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)
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
Event Decomposition TechniqueMore Comprehensive and
Complete TechniqueIdentify 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
occursEvent– something that occurs at a specific time and
place, can be described, and should be remembered by the
system
Events and Use Cases

Types of EventsExternal Eventan event that occurs outside the
system, usually initiated by an external agent or actorTemporal
Eventan event that occurs as a result of reaching a point in
timeState Eventan event that occurs when something happens
inside the system that triggers some processreorder point is
reached for inventory item
External Event ChecklistExternal agent or actor wants
something resulting in a transactionCustomer buys a
productExternal agent or actor wants some informationCustomer
wants to know product detailsExternal data changed and needs
to be updatedCustomer has new address and phoneManagement
wants some informationSales manager wants update on
production plans
Temporal Event ChecklistInternal outputs needed at points in
timeManagement reports (summary or exception)Operational
reports (detailed transactions)Internal statements and documents
(including payroll)External outputs needed at points of
timeStatements, status reports, bills, reminders
Finding the actual event that affects the system

Tracing a sequence of transactions resulting in many events
Perfect Technology Assumption
Don’t worry about functions built into system because of limits
in technology and people. Wait until design.
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
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.
Event Decomposition Technique: BenefitsEvents are broader
than user goal: Capture temporal and state eventsHelp
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 eventUses
perfect technology assumption to make sure functions that
support the users work are identified and not additional
functions for security and system controls
Use Cases and CRUD TechniqueCRUD is Create, Read/Report,
Update, and Delete (archive)Often introduced in database
contextTechnique to validate, refine or cross-check use
casesNOT for primarily identifying use cases
Use Cases and CRUD TechniqueFor Customer domain class,

verify that there are use cases that create, read/report, update,
and delete (archive) the domain class
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.
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

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
RMO CSMS Project Use Cases
Use Case DiagramsUse case diagram— a UML model used to
graphically show uses cases and their relationships to
actorsRecall UML is Unified Modeling Language, the standard
for diagrams and terminology for developing information
systemsActor 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
Use Case Diagrams
Symbols
Use Case Diagrams
Draw for each subsystem
Use Case Diagrams
Draw for actor, such as customer
Use Case Diagrams
Draw for internal RMO actors

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
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
SummaryThis chapter is the first of three that focuses on
modeling functional requirements as a part of systems

analysisUse cases are the functions identified, the activities the
system carries out usually in response to a user requestTwo
techniques for identifying use cases are the user goal technique
and the event decomposition techniqueThe user goal technique
begins by identifying end users called actors and asking what
specific goals they have when interacting with the systemThe
event decomposition technique begins by identifying events that
occur that require the system to respond.
SummaryThree types of events include external, temporal, and
state eventsBrief use case descriptions are written for use
casesThe 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 actorsThe 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
Chapter 4
Domain Classes

Chapter 4
Chapter 4 Outline“Things” in the Problem DomainData
entitiesDomain classesThe Domain Model Class Diagram The
Entity-Relationship Diagram
Learning ObjectivesExplain how the concept of “things” in the
problem domain also define requirementsIdentify and analyze
data entities and domain classes needed in the systemRead,
interpret, and create an entity-relationship diagramRead,
interpret, and create a domain model class diagramUnderstand
the domain model class diagram for the RMO Consolidated
Sales and Marketing System
OverviewChapter 3 provided an overview of identifying use
cases to define functional requirementsThis chapter focuses on
another key concepts for defining requirements— data entities
or domain classesIn the RMO Tradeshow System from Chapter
1, some domain classes are Supplier, Product, and ContactIn

this chapter’s opening case Waiters on Call, examples of
domain classes are Restaurants, Menu items, Customers, Orders,
Drivers, Addresses, Routes, and Payments
Things in the Problem DomainProblem 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
rememberedExamples of “Things” are products, sales, shippers,
customers, invoices, payments, etc.These “Things” are modeled
as domain classes or data entitiesIn this course, we will call
them domain classes. In database class you call them data
entities
Things in the Problem Domain
Two Techniques for Identifying themBrainstorming
TechniqueUse a checklist of all of the usual types of things
typically found and brainstorm to identify domain classes of
each typeNoun TechniqueIdentify 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
Brainstorming TechniqueAre there any tangible things? Are
there any organizational units? Sites/locations? Are there
incidents or events that need to be recorded?

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
The Noun TechniqueA technique to identify problem domain
classes (things) by finding, classifying, and refining a list of
nouns that come up in in discussions or documentsPopular
technique. Systematic.Does end up with long lists and many
nouns that are not things that need to be stored by the
systemDifficulty identifying synonyms and things that are really
attributes Good place to start when there are no users available
to help brainstorm

Partial List of Nouns for RMO
With notes on whether to include as domain class
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.
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?
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.
Details about Domain ClassesAttribute— describes one piece of
information about each instance of the classCustomer has first
name, last name, phone numberIdentifier or keyOne attribute
uniquely identifies an instance of the class. Required for data
entities, optional for domain classes. Customer ID identifies a

customerCompound attributeTwo 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.
Attributes and ValuesClass is a type of thing. Object is a
specific instance of the class. Each instance has its own values
for an attribute
Associations Among ThingsAssociation— a naturally occurring
relationship between classes (UML term)
Just to Clarify…Called association on class diagram in
UMLMultiplicity is term for the number of associations between
classes: 1 to 1 or 1 to manyWe are emphasizing UML in this
textCalled relationship on ERD in database classCardinality is
term for number of relationships in entity relationship diagrams:
1 to 1 or 1 to manyAssociations and Relationships apply in two
directionsRead them separately each wayA customer places an
orderAn order is placed by a customer
Minimum and Maximum MultiplicityAssociations have
minimum and maximum constraintsminimum is zero, the
association is optionalIf minimum is at least one, the

association is mandatory
Types of AssociationsBinary AssociationAssociations between
exactly two different classesCourse Section includes
StudentsMembers join Club Unary Association
(recursive)Associations between two instances of the same
classPerson married to personPart is made using partsTernary
Association (three)N-ary Association (between n)
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?
The Domain Model Class DiagramClassA category of
classification used to describe a collection of objectsDomain
ClassClasses that describe objects in the problem domainClass
DiagramA UML diagram that shows classes with attributes and
associations (plus methods if it models software classes)Domain
Model Class DiagramA class diagram that only includes classes
from the problem domain, not software classes so no methods
Domain Class NotationDomain class has no methodsClass name
is always capitalizedAttribute names are not capitalized and use
camelback notation (words run together and second word is
capitalized)
A Simple Domain Model Class DiagramNote: This diagram
matches the semantic net shown previouslyA customer places
zero or more ordersAn order is placed by exactly one
customerAn order consists of one or more order itemsAn order
item is part of exactly one order

UML Notation for Multiplicity
Domain Model Class Diagram
for a bank with many branches
Domain Model Class Diagram
for course enrollment at a universityWhere is each student’s
grade remembered in this model?Each section has many grades
and each grade is association with a studentEach student has
many grades and each grade is association with a section
Refined Course Enrollment Model
with an Association Class CourseEnrollmentAssociation 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
More Complex Issues about Classes:

Generalization/Specialization
RelationshipsGeneralization/SpecializationA hierarchical
relationship where subordinate classes are special types of the
superior classes. Often called an Inheritance
HierarchySuperclassthe superior or more general class in a
generalization/specialization hierarchySubclass the subordinate
or more specialized class in a generalization/specialization
hierarchyInheritance the concept that subclasses classes inherit
characteristics of the more general superclass
Inheritance
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

Inheritance for the Bank with Special Types of Accounts
A SavingsAccount has 4 attributesA CheckingAccount Has 5
attributes Note: the subclasses inherit the associations, too
More Complex Issues about Classes:
Whole Part RelationshipsWhole-part relationship— a
relationship between classes where one class is part of or a
component portion of another classAggregation— 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 devicesCar has
wheelsComposition— a whole part relationship where the parts
can no longer be removed (filled in diamond symbol)Hand has
fingersChip has circuits
Whole Part Relationships
Computer and its Parts
Note: this is composition, with diamond symbol. Whole part can
have multiplicity symbols, too (not shown)
More on UML RelationshipsThere are actually three types of

relationships in class diagramsAssociation RelationshipsThese
are associations discussed previously, just like ERD
relationshipsWhole Part RelationshipsOne class is a component
or part of another classGeneralizations/Specialization
RelationshipsInheritanceSo, try not to confuse relationship with
association
RMO CSMS Project
Domain Model Class DiagramsThere are several ways to create
the domain model class diagram for a projectRMO CSMS has 27
domain classes overallCan create one domain model class
diagram per subsystem for those working on a subsystemCan
create one overall domain model class diagram to provide an
overview of the whole systemUsually in early iterations, an
initial draft of the domain model class diagram is completed to
guide development and kept up to date
RMO CSMS Project
Domain Model Class DiagramsThere are several ways to create
the domain model class diagram for a projectRMO CSMS has 27
domain classes overallCan create one domain model class
diagram per subsystem for those working on a subsystemCan
create one overall domain model class diagram to provide an
overview of the whole systemUsually in early iterations, an
initial draft of the domain model class diagram is completed to
guide development and kept up to date

RMO CSMS Project
Sales Subsystem Domain Model Class Diagrams
RMO CSMS Project
Customer Account Subsystem Domain Model Class Diagram
RMO CSMS Project
Complete Domain Model Class Diagram
RMO CSMS Project
Domain Model Class DiagramsGiven the complete RMO CSMS
Domain Model Class Diagram and Sales and Customer Account
subsystem examples:Try completing the Order Fulfilment
Subsystem Domain Model Class DiagramTry Completing the
Marketing Subsystem Domain Model Class DiagramTry

Completing the Reporting Subsystem Domain Model Class
DiagramReview the use cases from Chapter 3 and decide what
classes and associations from the complete model are required
for each subsystemClasses and associations might be duplicated
in more than one subsystem model
Entity-Relationship Diagrams
ERDAn ERD shows basically the same information as a domain
model class diagramIt is not a UML diagram, but it is widely
used by data analysts in database managementThere really is no
standard notation, but most developers use the entity and crows
feet notation shown in this textAn ERD is not good for showing
generalization/specialization relationships and whole part
relationships
Example of ERD NotationA simple ERD without showing
attributes
ERD Cardinality Symbols
often called the crows feet notation

Expanded ERD with AttributesNote: This diagram matches the
semantic net shown previouslyAlso matches a domain model
class diagram shown previously
An ERD for a Bank
SummaryThis 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 entitiesTwo techniques
for identifying domain classes/data entities are the
brainstorming technique and the noun techniqueDomain classes
have attributes and associationsAssociations are naturally
occurring relationships among classes, and associations have
minimum and maximum multiplicity
SummaryThe 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 relationshipsOther class diagram concepts are
abstract versus concrete classes, compound attributes,

composition and aggregation, association classes, super classes
and subclasses
SummaryEntity-relationship diagrams (ERDs) show the same
information as a domain model class diagramERDs are preferred
by database analysts and are widely usedERDs 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
Chapter 5
Extending the Requirements Models
Chapter 5

Chapter 5 OutlineUse Case DescriptionsActivity Diagrams for
Use Cases The System Sequence Diagram—Identifying Inputs
and OutputsThe State Machine Diagram—Identifying Object
BehaviorIntegrating Requirements Models
Learning ObjectivesWrite fully developed use case
descriptionsDevelop activity diagrams to model flow of
activitiesDevelop system sequence diagramsDevelop state
machine diagrams to model object behaviorExplain how use
case descriptions and UML diagrams work together to define
functional requirements
OverviewChapters 3 and 4 identified and modeled the two
primary aspects of functional requirements: use cases and
domain classesThis chapter focuses on additional techniques
and models to extend the requirements models to show more
detailFully 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

Overview (continued)System sequence diagrams (SSDs) show
the inputs and outputs for each use case as messagesState
machine diagrams show the states an object can be in over time
between use casesUse cases are modeled in more detail using
fully developed use case descriptions, activity diagrams, and
system sequence diagramsDomain classes are modeled in more
detail using state machine diagramsNot 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
Use Case DescriptionsWrite a brief description as shown in
Chapter 3 for most use cases.
Use Case DescriptionsWrite a fully developed use case
description for more complex use casesTypical use case
description templates include:
Use case nameScenario (if needed)Triggering eventBrief
descriptionActorsRelated use cases
(<<includes>>)StakeholdersPreconditionsPost conditionsFlow
of activitiesException conditions
Fully Developed Use Case Description
Use case: Create customer account

Fully Developed Use Case Description Create customer account
(part 1 )
Fully Developed Use Case Description Create customer account
(part 2 )
Use Case Description DetailsRelated use cases <<includes>>If
one use case invokes or includes anotherStakeholdersAnyone
with an interest in the use casePreconditionsWhat must be true
before the use case beginsPost conditionsWhat must be true
when the use case is completedUse for planning test case
expected results Flow of activitiesThe activities that go on
between actor and the systemException conditionsWhere and
what can go wrong
Use Case Description DetailsUse case nameVerb-nounScenario
(if needed)A use case can have more than one scenario (special
case or more specific path)Triggering eventBased on event
decomposition techniqueBrief descriptionWritten previously
when use case was identifiedActorsOne or more users from use
case diagrams

Another Fully Developed Use Case Description Example
Use case
Ship items
Fully Developed Use Case Description Ship items (part 1 )
Fully Developed Use Case Description Ship items (part 2 )
UML Activity Diagram for Use Case
Create Customer Account
Note: this shows flow of activities only

UML Activity Diagram for Use Case
Fill shopping cart
Note: this shows use case with <<includes>> reltionship
System Sequence Diagram (SSD)A UML sequence
diagramSpecial case for a sequence diagramOnly shows actor
and one objectThe one object represents the complete
systemShows input & output messaging requirements for a use
caseActor, :System, object lifelineMessages
System Sequence Diagram (SSD)
Notation
Message Notation

SSD Message Examples with Loop Frame
SSD Message Examples
Opt Frame (optional)
Alt Frame
(if-else)
Steps for Developing SSD
Identify input messageSee use case flow of activities or activity
diagram
Describe the message from the external actor to the system
using the message notationName it verb-noun: what the system

is asked to do Consider parameters the system will need
Identify any special conditions on input messagesIteration/loop
frameOpt or Alt frame
Identify and add output return valuesOn message itself:
aValue:= getValue(valueID)As explicit return on separate
dashed line
SSD for Create customer account Use case
SSD for Ship items Use Case
State Machine DiagramState machine diagramA UML diagram
showing the life of an object in states and transitionsStateA
condition during an object’s life when it satisfies some
criterion, performs some action, or waits for an
eventTransitionThe movement of an object from one state to
another stateAction ExpressionA description of activities
performed as part of a transition
State Machine Diagram (continued)Pseudo stateThe starting

point of a state machine diagram (black dot)Origin stateThe
original state of an object before transitionDestination stateThe
state to which the object moves after the transitionGuard
conditionA true false test to see whether a transition can fire
State Machine Diagram
for a Printer
Composite StatesState containing other states and
transitionsPrinter can be On and either Idle or Working
Concurrent Paths Multiple paths in composite statePrinter On
paths are independent
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
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 classMake
sure state are really state for the object in the classFollow the
life cycle of an object coming into existence and being
deletedBe sure the diagram covers all exception conditionLook
again for concurrent paths and composite states
RMO Domain Class States for SaleItem Object
Final State Machine Diagram for SaleItem ObjectaddItem() and
archive() transitions addedmarkBackOrdered() transition added
RMO Domain Class States for Sale Object

Initial State Machine Diagram for RMO Sale Object
Final State Machine Diagram for Sale Object
Extending and Integrating Requirements ModelsUse casesUse
case diagramUse case descriptionActivity diagramSystem
sequence diagram (SSD)Domain Classes Domain model class
diagramState machine diagram
Integrating Requirements Models
Summary
Chapters 3 and 4 identified and modeled the two primary
aspects of functional requirements: use cases and domain
classesThis chapter focuses on additional techniques and models
to extend the requirements models to show more detailFully
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
Summary (continued)
System sequence diagrams (SSDs) show the inputs and outputs
for each use case as messagesState machine diagrams show the
states an object can be in over time between use casesUse cases
are modeled in more detail using fully developed use case
descriptions, activity diagrams, and system sequence
diagramsDomain classes are modeled in more detail using state
machine diagramsNot 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
ENTD311_CASE2/Thumbs.db
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.
http://www.visual-paradigm.com/download/community.jsp
http://en.wikipedia.org/wiki/List_of_UML_tools

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-
http://www.visual-paradigm.com/training/
http://www.visual-
http://www.viswiser.com/training/usingclassdiagram.html
http://www.viswiser.com/training/usingusecasediagram.html
http://www.viswiser.com/training/usingusecasediagram2.html
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.
paradigm.com/product/vpuml/tutorials/writingeffectiveusecase.j
sp

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
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
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.

sp
sp
http://www.viswiser.com/training/documentusecase.html
documentingf.html
documentingf.html
documentingf.html
http://www.viswiser.com/training/usingseqcommdiagram.html
http://www.viswiser.com/training/usingtimingdiagram.html
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
paradigm.com/product/vpuml/features/reqmodeling.jsp
16.Visual Paradigm. (n.d.). Requirements as Scenarios.
Retrieved from
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.
paradigm.com/product/vpuml/features/architecturalmodeling.jsp

paradigm.com/product/vpuml/features/reqmodeling.jsp
paradigm.com/product/vpuml/features/usecasedetails.jsp
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.
Assignment Requirements
Please complete all parts in a Microsoft Word document. The
body of your document should be at least 1500 words in length.
Quoting should be less than 10% of the entire paper.
Paraphrasing is necessary. Students must cite and reference at
least 4 credible sources .This Assignment should follow the

conventions of Standard American English (correct grammar,
punctuation, etc.). Your writing should be well ordered, logical
and unified, as well as original and insightful. Your sources
should be cited according to APA formatting.
Instructions
As Director of Health Information for a large health system, you
have been tasked as a key leader in the selection and
implementation of a new electronic health record (EHR) system
for the organization. The CEO and Board of Directors has asked
that you develop a plan to address key issues related to the
process of selecting and adopting an EHR system. Please follow
the instructions below in completion of this assignment.
Competency Assessed Instructions
Part 1 Develop educational programs for employees in privacy,
security, and confidentiality. Investigate the challenges with
educational programs for employees in terms of healthcare
privacy, security, and confidentiality.
Develop a plan that will address at least three (3) issues related
to privacy and security laws/regulations, adult education
strategies, and training methods.
Part2 Create policies and procedures to manage access and
disclosure of personal health information.
Investigate the policies and procedures in the management of
access and disclosure of PHI. Develop a plan that will address
at least three (3) issues related to authorization and the
releasing of PHI within the Release of Information (RoI)
process.
Part3 Take part in system selection processes. Propose either
the RFI and/or RFP for the systems selection process.
Distinguish at least five (5) content elements of the RFI and/or
RFP that you would need to include in order to address the
security and privacy concerns.
Part4 Recommend clinical, administrative, and specialty service
applications. Appraise three (3) EHR vendors that could be used
at a large health system. Critique each vendor based on at least

5 content elements of an RFP. Select and recommend one EHR
noting the strengths and weaknesses related to clinical and
administrative functions.
Part 5 Evaluate vendor contracts. Evaluate at least five (5)
elements of a vendor contract. Critique the process of contract
management and system acquisition/evaluation through at least
two (2) challenges and two (2) opportunities.
Part6 Develop negotiation skills in the process of system
selection. Conjecture on the best methods for negotiating with
vendors in the contract management process. Develop a plan of
at least three (3) considerations for strategic leadership

ENTD311_CASE2Community Patient Portal System Part 1.pdfCP.docx

More Related Content

Similar to ENTD311_CASE2Community Patient Portal System Part 1.pdfCP.docx (20)

More from SALU18 (20)

Recently uploaded (20)

ENTD311_CASE2Community Patient Portal System Part 1.pdfCP.docx