View
32
Download
0
Category
Preview:
DESCRIPTION
Systems Analysis II Domain Modeling. INFO 355 Glenn Booker. Problem Domain. Based on the requirements (use cases), we can start to identify the problem domain What is part of our problem? What isn’t? Often develop this based on brainstorming what ‘things’ are of importance in the use cases. - PowerPoint PPT Presentation
Citation preview
INFO 355 Week #3 1
Systems Analysis IIDomain Modeling
INFO 355Glenn Booker
Problem Domain
Based on the requirements (use cases), we can start to identify the problem domain What is part of our problem? What isn’t?
Often develop this based on brainstorming what ‘things’ are of importance in the use cases
INFO 355 Week #3 2
Things
Things such as Tangible things (book, airplane) Roles (employee, customer, patient) Organizational units (division, dept) Devices (sensor, controller, bin) Sites (warehouse, facility, branch office) Events (flight, contract, order)
INFO 355 Week #3 3
Nouns
Or the domain might include more general nouns What nouns appear often in use case
descriptions? Are they in the scope of the system? Are they inputs, outputs, processes, …? Does it describe some other noun?
Make a list and refine it as needed
INFO 355 Week #3 4
Attributes
Lots of nouns are attributes (data about something else)
Collect attributes with their noun owners
INFO 355 Week #3 5
ERD
One way to model the domain of a system is the entity relationship diagram But you had this in INFO 200
So instead we’ll focus on the domain model class diagram
INFO 355 Week #3 6
Class Diagram
The class diagram goes through several stages of development in object-oriented modeling The first is the domain model Later we have the design class diagram
and the application class diagram Same thing, just with added detail
INFO 355 Week #3 7
INFO 355 Week #3 8
Purpose of Class Diagram
The Class Diagram shows many key characteristics of the system What classes can exist Their attributes (data) Their methods (functions to get to
the data) How the classes see each other (like
relationship and cardinality)
INFO 355 Week #3 9
Class Diagram Evolves
The class diagram evolves as a system is analyzed The initial conceptual class diagram
might just show classes and key attributes, connected by associations
The application class diagram can show all classes needed to complete the system
INFO 355 Week #3 10
Types of Classes
It often helps to think of three types of classes Data classes are used to store data,
much like traditional entities Control classes are used to manage
performing a use case, like scripts Interface classes are the GUI seen by
the user – they are the classes first acted upon
INFO 355 Week #3 11
Types of Classes
Another set of terms for the same concept is Model-View-Controller Model = data classes View = interface classes Controller = control classes
There are times when it’s good to combine model and controller, or view and controller, but this is a good pattern to consider
INFO 355 Week #3 12
Classes versus Objects
Recall that objects are derived, or instantiated, from classes
Hence we assume that any class could be used one or more times to create objects
Objects can be created and destroyed, including interface classes and temporary data
INFO 355 Week #3 13
The Conceptual Class Diagram
To define the conceptual class diagram, we’ll need to determine Classes
Primarily data and major control classes Associations
Including label and multiplicity Attributes
INFO 355 Week #3 14
Conceptual Class Diagram
Also called a Domain Model, the conceptual class diagram is the simplest form of the class diagram
It shows the classes, their associations, and attributes
Does not show methods or interface classes
INFO 355 Week #3 15
Types of Classes
For the conceptual class diagram, focus on data classes, and controller classes for significant use cases
Fill in the rest later
INFO 355 Week #3 16
Conceptual Class Diagram Excerpt
-date-time
Sale-quantity
SalesLineItem
-amount
Payment
1
1
Paid-by
11..*Contained-in
Association
Conceptual class
Attribute
Multiplicity (discuss later)
Association label
INFO 355 Week #3 17
Analogies to ERD
ERD has Class Diagram has
Entities Classes
Relationships Associations
Cardinality Multiplicity
Data elements or attributes or fields
Attributes
INFO 355 Week #3 18
Analogies to ERD
Just because a conceptual class diagram looks similar to an ERD, don’t think they are the same thing!
Classes can exist for transient data you’d never keep in an entity
INFO 355 Week #3 19
Class Naming Conventions
Notice that Class and attribute names are singular (Sale, not Sales), and words are spelled out
The dash before attribute names has meaning … we’ll get to later
INFO 355 Week #3 20
Class Naming Conventions
Capitalization conventions: Class names use initial capital letters
for each word; no spaces between them (SalesLineItem), also called camelback notation
Attributes start lower case (date, terminationDate)
Associations use initial capital letters for the first word and dashes between words (Contained-in)
INFO 355 Week #3 21
Finding Classes
INFO 355 Week #3 22
Identifying Classes
Use the use case scenarios for finding conceptual classes – look for noun phrases, then evaluate them Is it an important concept for this
system? Is it an attribute of something bigger, or
is it a self-contained idea or thing?
INFO 355 Week #3 23
Identifying Classes
Consider the possibility that classes can have other classes within them A single Sale can have many entries,
each of which is a SalesLineItem A ComputerSystem can have many
ComputerParts
INFO 355 Week #3 24
Identifying Classes
Notice that classes can be actions, transactions, or events, like BookingASeat: A controller class for
managing the process of booking a seat on an airline
There is not a single correct list of classes for a problem
INFO 355 Week #3 25
Identifying Classes
Use terminology for class names which is native to the system’s environment Don’t make the customer learn new
words for old ideas Omit things which aren’t relevant to
meeting the system’s requirements If in doubt, make it a separate class
Then see if it’s needed later
INFO 355 Week #3 26
Identifying Classes
People’s roles might be classes Does the type of user require a
separate class, or is it just an attribute? Might need a class if the user type
affects what data are needed (attributes) or functions can be performed (methods)
INFO 355 Week #3 27
Description Conceptual Classes
Often it is needed to have a place for information about a thing – such as a product description
We tend to keep a class for such descriptions, in case all those things disappear (e.g. are sold) Many sales or manufacturing systems
will have a ProductDescription classor ProductSpecification
This is another design pattern
INFO 355 Week #3 28
Finding Associations
INFO 355 Week #3 29
Adding Associations
An association is shows that there is a meaningful connection between two classes
Formally, it is: The semantic relationship between two or more classifiers that specifies connections among their instances
INFO 355 Week #3 30
Adding Associations
Associations imply a relationship which may be kept for a second, or forever
Associations are often from a need-to-know basis – e.g. we ‘need to know’ what line items were associated with a given sale
INFO 355 Week #3 31
Adding Associations
Associations are generally needed to trace data In order to find some piece of data,
what do I need to know to track it down? (customer might need to look up their orders, for example)
Or, what comes first in the process? (if I’m creating a new order, do I need to know what customer is doing so, or can I add that later?)
INFO 355 Week #3 32
Adding Associations
For a conceptual model with ‘n’ classes, there can be n*(n-1) possible associations You need to determine: which
associations are significant? Associations are assumed
bidirectional for now – information can go both directions We’ll refine this later
INFO 355 Week #3 33
Labeling Associations
Each association has a label to describe the association, and may use an arrow to indicate which way the label should be read In Visio, can use ‘<‘ or ‘>’ in the label
for the arrow
1 1Records-current >
-date-time
Sale
-date-time
Register
Don’t need arrow if association is read left-right or top-bottom
INFO 355 Week #3 34
Finding Associations
Most common association types are Physical or logical types (e.g. Register
is physically located in Store) When information is stored, recorded or
captured (Register reports Sale) Classes are more critical to identify
than associations Avoid too many associations
But at least one per class
INFO 355 Week #3 35
Multiplicity
Here ‘*’ means many, but by itself it means ‘0, 1, or many’
‘1..*’ means one or many ‘1..40’ means a range from 1 to 40 ‘n’ means only the value of ‘n’ Obsolete (from UML 1.x):
‘a, b, c’ means only a, b, and c are allowable values, e.g. ‘2, 5, 7’
INFO 355 Week #3 36
Multiplicity
To determine multiplicity, think of what values may be true at any one moment
Consider what multiplicity is meaningful from your system’s point of view If your system will never handle the
case of 0 multiplicity, don’t need 0 to show in the domain model
INFO 355 Week #3 37
Multiple Associations
It is possible to show two associations between the same two classes, if the associations are handled very differently by the system E.g. Flight Flies-to Airport and
Flight Flies-from Airport
INFO 355 Week #3 38
Cleaning up Associations
In general, we may define associations conceptually that don’t get implemented (used), or may later find associations we missed here
INFO 355 Week #3 39
Cleaning up Associations
Whether an association is needed depends heavily on the system’s requirements “Sale Initiated-by Customer” may be
trivial for a gas station, but important for a grocery store which analyzes its regular customers
INFO 355 Week #3 40
Cleaning up Associations
OTOH, might want to keep associations which reveal key information about the problem, even though we may never implement them “Sale Initiated-by Customer” could be
kept as a reminder of who starts the purchasing process
Associations might be used with logging transactions
INFO 355 Week #3 41
Finding Attributes
INFO 355 Week #3 42
Adding Attributes
Attributes are data values which describe a class
Following the need-to-know concept, we want all attributes which we need to remember for our system
Attributes may be described by their type of data (particularly for non-primitive data types)
INFO 355 Week #3 43
Adding Attributes
Key to finding good attributes is to make sure each one is A simple characteristic Which is uniquely defined by the
class to which it belongs
INFO 355 Week #3 44
Adding Attributes
Don’t worry about “keys” for defining associations to other classes, such as primary and secondary keys
Don’t worry about data normalization either
Focus only on data characteristics of each class
INFO 355 Week #3 45
Primitive vs. Non-Primitive Data
Primitive data types are the most basic ways to represent data in a computer Boolean (True/False, Yes/No, 0/1) Number (integer or real) String (text) Date Time (may be merged with Date)
INFO 355 Week #3 46
Primitive vs. Non-Primitive Data
Most complex data types are considered non-primitive Phone number, SSN, money, etc.
are all non-primitive We’ll discuss non-primitive data
types next week
Generalization
We saw generalization in the use case diagram It came from the class diagram The arrow points to the superclass,
away from the subclass Use it when classes have similar
attributes, but might differ in some ways from each other
INFO 355 Week #3 47
Generalization
Subclasses inherit attributes (and methods) from superclasses Inheritance is a key object oriented
concept
INFO 355 Week #3 48
Recommended