Basic Class Diagrams CS/SWE 421 Introduction to Software Engineering Dan Fleck

advertisement
Basic Class Diagrams
Classifier
Generalizable
Element
isRoot
Model
Element
Namespace
name
visibility
isSpecification
CS/SWE 421
Introduction to Software Engineering
Dan Fleck
(Slides adapted from Dr. Stephen Clyde with permission)
Coming up: Class Syntax
Constraint
Body
Class Syntax

A box divided into
compartments
– Name
– Attributes
– Operations
– Responsibilities (rarely
seen)
– Used-defined
compartments (rarely
seen)
Coming up: Class Names
Student
major: String
gpa: Real
standing: String
add(Class Section)
drop(Class Section)
-- The set of students
known to the
registration system
-- An exception occurs if
gpa falls below 2.0
Class Names



The name should be a noun or noun phrase
The name should be singular and
description of each object in the class
The name should be meaningful from a
problem-domain perspective
– “Student” is better than “Student Data” or
“S-record” or any other implementation
driven name


Avoid jargon in the names
Try to make the name descriptive of the
class’s common properties
Coming up: Exercise – Class Identification
Exercise – Class Identification

Identify meaningful classes in the Elevator
System
Coming up: Attributes
Attributes





Attributes represent characteristics or
properties of objects
They are place holders or slots that hold
values
The values they hold are other objects
The name of an attribute communicates its
meaning
An attribute can be defined for individual
objects or classes of objects
– If defined for a class, then every object in
the class has that attribute (place holder)
Coming up: Attributes from an Analysis Perspective
Attributes from an Analysis
Perspective


An attribute relates an object to some other
object
It has the same semantics as an association
joe: Student
name: String = “Joe Jones”
joe: Student
Coming up: Attribute Syntax
name
1
Is basically the
same as ...
Joe Jones : String
Attribute Syntax
[visibility] name [multiplicity] [:type] [=initial-value]
[{property-string}]
visibility: public “+”, protected “#”, or private “-”
name: capitalize first letter of each word that
makes up the name, except for the first
multiplicity: number, range, or sequence of
number or ranges.
type: build-in type or any user-defined class
initial-value: any constant and user-defined object
property-string: e.g, changeable, addOnly, frozen
Coming up: Operations
Operations
Student
major: String
GPA: Real
standing: String
add(Class Section)
drop(Class Section)
Course
Coming up: Operation Syntax
Class Section
takes>
name: String
capacity: Integer
add(Student)
drop(Student)
checkPrerequisites(Students)
Prerequisite
Operation Syntax
[visibility] name [(parameter-list)] [:returntype] [{property-strong}]
visibility: “+”, “#”, “-”
name: verb or verb phase, capitalize first
letter of every word, except first
parameter-list: coma separated list of
parameters
return-type: primitive type or user-defined type
property-string: isQuery, sequential, guarded,
concurrent
Coming up: Type of Relationships in Class Diagrams
Type of Relationships in Class
Diagrams
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Binary Association
Coming up: Associations
Aggregation
Dependency
N-ary Association
Associations


An association is a structural relationship
that specifies that objects of class may be
connected to objects of another class
Meaning from three perspectives
– Analysis: Links between objects
– Specification: Obligation to provide a
connection between objects
– Implementation: Object pointers,
references, linking structures, etc.
Coming up: Associations
Associations
is registered for>
Student
<works for
Instructor
Department
Coming up: Association Names
Semester
teaches>
Class
Section
sponsors>
Course
Association Names

Associations may be named
– The names should communicate the
meaning of the links
– The names are typically verb phases
– The name should include an arrow
indicating the direction in which the name
should be read
– The direction on the name does NOT
change navigability!
Coming up: Navigation
Navigation

The navigation of associations can be
– uni-directional
– bi-directional
– unspecified
<works for
Instructor
Department
Coming up: Navigation
teaches>
Class
Section
sponsors>
Course
Navigation


The navigation of association without an
arrowhead is assumed to be undefined
Navigation has less value when modeling
from a conceptual perspective
– Why?

Navigation is more important from
specification and implementation
perspectives
– Why?
Coming up: Generalization
Generalization


Generalization is another kind of
relationship in UML
In a Java implementation what is this?
Person
Coming up: Exercise – Simple Associations
Student
Graduate
Student
Exercise – Simple Associations

From an analysis perspective:
– Identify meaningful associations and
generalization/specializations among
classes in the Elevator System
Coming up: Class Diagrams
Class Diagrams

Class Diagrams describe
– the types of objects in a system
– their properties (attributes and operations)
– relationships between objects

They can also include
– Grouping concepts like packages
– Constraints
– Various kinds of annotations
Coming up: Multiplicity Constraints
Multiplicity Constraints
is registered for>
Student
1..*
0..*
1
0..8
teaches>
<works for
Instructor
1..*
1
Department
Coming up: Questions
Semester
1..3
1
0..6
sponsors>
1..*
Class
Section
1..*
Course
Questions

From the previous diagram
– How many classes can a student take?
– Do you have to be registered in any classes
to be a student?
– Do I need to teach this class to be an
Instructor? Do I need to teach ANY classes?
– Can a class have no students? Is that valid?
Coming up: Multiplicity Constraints
Multiplicity Constraints

A multiplicity constraint can be
– a single number
– a “*”, meaning an arbitrarily large number or
simply “many”
– a range, denoted by “min..max”
– a sequence of single numbers and ranges
1..2,7,10-20
This is also called the
cardinality constraint
Coming up: Dependencies
Dependencies
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Binary Association
Aggregation
Coming up: Dependency Relationship
Dependency
N-ary Association
Dependency Relationship

It says that
one modeling
component
“uses”
another.

If the later
changes then,
the former
may have to
change as well
Coming up: Dependencies
Dependencies

Syntax:
– a dashed link with an straight-line
arrowhead point to a component on which
there is a dependency



Dependencies can be defined among:
classes, notes, packages, and other types
of components
Can dependencies go both ways?
Any problems with having lots of
dependencies?
Coming up: Aggregations (is part of)
Aggregations (is part of)
A consolidated snippet of the UML Meta-model
Relation
Generalization
Association
Binary Association
Coming up: Aggregation
Aggregation
Dependency
N-ary Association
Aggregation


Aggregation: is a special kind of association
that means “part of”
Aggregations should focus on single type of
composition (physical, organization, etc.)
Crust
1
1
Sauce Serving
1
1
Cheese Serving
Topping Serving
*
Pizza
1..3 1
1
0..9 1
4..*
Coming up: Composition (very similar to aggregation)
Slice
1
Order
Composition (very similar to aggregation)

Think of composition as a stronger form of
aggregation. Composition means
something is a part of the whole, but cannot
survive on it’s own.
Room
Coming up: Lets look at BookstoreExample4.jpg
Building
Lets look at
BookstoreExample4.jpg





Does John McCain (who has 7 houses)
have a problem using this system?
If Barack Obama decides to create a
Federal sales tax, how would we change
the system?
Why is there a display method in Item,
Book, MusicCD and Software?
An ItemOrder is part of how many Orders?
Can you explain how a search works using
this diagram?
Coming up: Class Exercise
Class Exercise

Lets create the WeGrow class diagram
Coming up: Safety System Example
Safety System Example

A safety software system for housing areas:
–
–
–

enables its owner to configure it during installation,
controls through its sensors the environmental areas against fire and burglary and
interacts with the owner through the keypad of the system control panel.
During installation, the system programming and configuration is carried out by using the numerical and
functional keys of the control panel. Each sensor in the system is identified by a number and a type (fire or
burglary). The system stores two passwords (each of them is up to six digits) used for the system
activation/deactivation and a telephone number used for emergency calls when an alarm event arises. The
system polls the fire sensors for M seconds, then disables them for other N seconds. After that, the system
resumes the same cycle. The Ready indicator is lighting when the sensors are polled and is turned off when
the sensors are disabled. When a sensor indicates an event, the system launches an alarm signal. After K
seconds, the system calls the security forces office and provides it with information about the event nature
and location. In order to log in, the owner enters the password and presses Enter. If any of the six digits is
wrong the password is ignored by the system and the sensors’s state doesn’t change. The owner can cancel
the password with the Clear key. If a sensor is activated, the system is armed and the Armed indicator on the
control panel is turn on. In the case of the sensor deactivation, the Armed indicator is turn off. Moreover, the
system logs all events. Each logged event is characterized by its type and the date and time of its occurrence.
The event list can be delivered by pressing the MEM key.
Example specification from: http://www.emis.de/journals/ASUO/mathematics/pdf3/bogdan.ps
Coming up: Validating a class diagram
Validating a class diagram

One of the most important, and often
overlooked issues is how to validate a class
diagram. (Usually best for a diagram at the
implementation perspective)

Given a specification or a use-case, can you
look at the class diagram and use attributes
and methods to “execute” a use case?

Lets try it for the WeGrow class diagram
Coming up: Some User Stories for WeGrow
Some User Stories for WeGrow

As an analyst I need to get a report on
sales statistics on a per store basis.

As a store manager I want to change prices
for an item in my store only.

As a sales clerk I want to determine the
closest store that has the item in stock and
request a transfer of the merchandise
Coming up: Questions
Questions

What’s the difference between an attribute and an
association with another class? For example, should
“grade” be an attribute or a link to another class called
“Grade”?

When during the software engineering life cycle should
you build classes diagrams?
Coming up: More Questions
More Questions

How do you know when a class diagram is
complete?

How can you manage change control on all
the class diagrams for project?

What do you do with class diagrams after a
system has been built and delivered?
Coming up: What’s important
What’s important





Understading the 3 main parts of the class
box
Generalization/Specialization
Associations and multiplicity constraints
Aggregation (and composition) understand
how to use them, but don’t worry about the
differences between them – too subtle
Knowing these you should be able to
validate a class diagram
Coming up: Bonus Slide!
Bonus Slide!

If you’re interested in Auto-generating UML,
Netbeans has an option to do it.
– Install the UML plugin
– Right-click on a project
– Choose “Reverse Engineer”
– Go to the new UML project
– Select a package and choose to generate a
new UML diagram
Coming up:

REMOVED SLIDES

These are things I removed over time from
this lecture because they are less common
or needed for a basic understanding.
Read if you want. 

Coming up: Class Diagrams
Attributes from a Specification
Perspective

An attribute represents an obligation to
provide or manage a certain (single) piece
of information

For example, each
Student object must
be able to
encapsulate a
major, a GPA, and a
standing
Coming up: Generalization
Student
major: String
gpa: Real
standing: String
Generalization

From a specification/implementation
perspective, generalization can represent subtyping, inheritance, type capability, and
substitutability (depends on the language)
Student
Person
name: String
address: String
changeAddress(new_address)
End of presentation
major: String
GPA: Real
standing: String
add(Class Section)
drop(Class Section)
Download