System Engineering and Databases

1
System Engineering and Databases
Lecture 4 Introduction to Software Analysis and
Design - UML Prof. Kazimierz Subieta
Polish-Japanese Institute of Information
Technology Institute of Computer Science,
Warsaw, Poland subieta_at_ipipan.waw.pl
http//www.ipipan.waw.pl/subieta
2
Content

• UML overview
• Use Case diagrams
• Class diagrams
• UML class diagrams - notation summary
• Sequence diagrams
• Collaboration diagrams
• Statechart diagrams
• Activity diagrams
• Package diagrams
• Component diagrams
• Deployment diagrams
• UML diagrams in Analysis and Design

Acknowledgment The material has been compiled
from many Internet sources. It has no commercial
purpose. Special thanks to anonymous authors of
the Rational Software Corporation, who were the
original authors of many of the presented slides.
3
UML - a Notation for Analysis and Design
The Unified Modeling Language (UML) is a language
for specifying, constructing, visualizing, and
documenting the artifacts of a software-intensive
system. http//www.rational.com/uml
Use case diagrams Static structure
diagrams class diagrams object diagrams package
diagrams Behavior diagrams Interaction
diagrams sequence diagrams collaboration
diagrams statechart diagrams activity
diagrams Implementation diagrams component
diagrams deployment diagrams
Kinds of diagrams within UML
4
Use Cases
One of the most fundamental problems in software
engineering is determining the requirements of a
system. The notion of use-cases, introduced by
Jacobson, is an excellent approach. The
use-case approach requires the analyst to
determine all the potential actors involved in a
system. Actors are external to the system and
make use of it. An actor is typically a person,
but may be a third-party organization or another
computer system. One person may in fact be
multiple actors, say a shop assistant may be a
customer of the same shop at another time. We
model actors, not individuals. An actor makes
use of a system in different ways. Each of these
ways is known as a use-case. A use-case may
involve a number of actors, just as an individual
actor may make use of several use-cases.
5
Use Case Diagrams - Basic Notation
Use Case
Actor

• Uses and extends relationships

Design Review
ltltextendsgtgt
ltltusesgtgt
Note Taking
Technical Review
ltltextendsgtgt
ltltusesgtgt
Code Review
6
Use Case Diagram
Determining limits
Updating accounts
Accounting System
Merchandise Director
Risk analysis
uses
Calculating estimates
Determining prices
uses
Estimation of profits
Trader
Salesman
extends
Violating limits
7
Use cases description and documentation

• Obligatory points
• For each use case
• Short description of a use case purpose,
  motivation, importance
• Description of interaction with actors when it
  takes place and which data are sent, event flow
  between an actor and a use case, event flow
  within a use case.
• For each actor
• Short description of an actor
• Description of interaction with use cases
• Description of uses and extends relationships
  between use cases
• Description of generalization relationships
  between actors (e.g. a secretary is an employee),
• The general use case diagram.

8
Use cases description and documentation

• Non-obligatory (but recommended) points
• How and when a use case starts and terminates?
• A rough layout of the user interface
• Special non-functional requirements, for
  instance performance constraints, the max elapsed
  time necessary for answer, standards, etc.
• Exceptions during performing a use case
• Objects from the business domain which
  participate in a use case
• Which, how, what for, and when data stored in a
  system are required for a use case?
• Which, how, what for, and when data are stored
  in a system by a use case?
• Interaction diagrams for each actor (in the form
  of UML sequence diagrams).

9
Verification of use cases through interaction
with the customer
The use case diagram (plus documentation) should
be prepared in terms understandable for our
customer (client or interviewer). It should be a
basis of interaction with the customer and
verification of the collection of functional
requirements. The verification process should
lead to the wide acceptance of the system goals,
assumptions and functions from the side of the
customer. The goals of the interaction are the
following

• Explaining if the use case diagram covers all
  functions of the system
• Explaining if the use case diagram covers all
  actors which can use the system
• Explaining which functions are redundant or
  overlapped
• Explaining which actors are redundant or
  overlapped

10
Verification of use cases through interaction
with the customer (cont.)

• Minimizing the number of functions
• Minimizing the number of actors
• Refining the interaction between actors and use
  cases by creating more general and/or more
  specific actors and more general/specific use
  cases (for instance, having actors secretary and
  salesman we can determine an actor employee,
  which will have access to some basis system
  services)
• Refining the diagram by separating regular uses
  cases and exceptional use cases then
  connecting exceptional uses cases by the
  relationships extends
• Refining the diagram by recognizing reusable
  (common) functions and then, connecting the
  reusable functions by the relationship uses

11
Class Diagrams
A representation of the types of objects in the
system and the various kinds of static
relationships that exist among them. It serves as
the framework for the system design. Object - an
identified, intelligent component of information
system capability. Domain objects represent
"things" in the world (entities). Capability -
behavior that the object can perform, typically
requiring variables (data attributes) and methods
(procedural code). Class - a collection of
objects having the same capabilities. Association
- a relationship among objects Subtype
Specialization (Subclasses) - subset of a class
that extends its capabilities Constraint - a rule
defining legal states of objects, classes,
relationships, and subtypes.
12
Classes, Attributes, Operations
Mapping to Java
public abstract class Account protected
double m_CurrentBalance public void
credit(double amount) public void
debit(double amount)

13
Specialization
Person
Employee
Secretary
Professor
Assistant
Programmer
Inheritance specialized classes inherit all
properties of all the super-classes. (Professor
has all properties of Employee and
Person.) Substitutability an object from a
specialized class can be used in all the
contexts, where an object defined by its
super-classes can be used. (a Professor object
can be used in all contexts where a Person object
can be used.)
14
Relationships between Classes
Associations, Association roles
Position
employee
employer
Position

0..1
public class Person public Company
employer
public class Company public Vector
employee
15
UML class diagrams - notation summary
B is a specialization of A A is a generalization
of B
A
B
Customer
Class (name only)
A
B
A is an aggregate of Bs
Class with attributes
A
B
A contains B
A is associated with exactly one B
A
B
A is associated with many (zero or more) Bs

A
B
Class with operations (methods)
A is associated with minimum m and maximum n Bs
n can be .
m..n
A
B
Class C represents the properties assigned to the
relationship between A and B.
A
B
Class with attributes and operations (methods)
C
Association between A and B is qualified by
attribute c.
A
B
c
c
Association name c between A and B is to be read
from A to B.
A
B
16
UML class diagram example - abstract
0..1
Collateral
Home Loan
secures
uses
Car Loan


has a
Customer
Loan
Business Loan


has a
for a
makes
works with
Loan History

Payment
makes
works for
Service Agent
Institution
17
UML class diagram example - more detailed
Person
name
IDNumber
Classification
Student
Professor
maxCourseLoad
studentID
1
1
1
3..
Teaches
Attends
Parttime
Fulltime

0..4
yearsInAttendance
gradYear
Course
18
Sequence Diagrams
Sequence diagrams present the flow of messages
between instances in time. One can immediately
see in what order messages are sent because time
is an explicit, vertical dimension. Each instance
is represented as a vertical line.
controller
service
entity
storage
create()
add(entity)
edit(entity)
set()
validate()
update(entity)
19
Collaboration diagrams

• Collaboration diagrams emphasize relationships
  (associations) between objects and show message
  flow between objects.
• They present subsets of class diagrams together
  with arrows showing associations and message
  flow.
• Numbers attached to messages determine their
  order.

20
Collaboration diagrams - example
2 verify id
4 within add/drop period
1 enter id
3 delete course
9 close form
Registration Form
Student
6 enter number
8 close form
5 display
7 delete student(id)
Delete Form
Course Offering
Delete Course Scenario
21
Statechart Diagrams - Example
Statechart diagrams define possible states and
transitions between them.
Positive Balance
Negative Balance
Empty
22
Statechart Diagram - Example
Course Offering
Initialization
do Initialize course offering data
add student / set count 0
CourseRoster.Create
Open
add student count lt 10
entry Register student
exit CourseRoster.AddStudent (student)
count 10
cancel
Closed
Canceled
do Finalize course
cancel
CourseRoster.Delete
23
Activity diagrams

• Activity diagrams are syntactic variants
  (particular cases) of state transition diagrams
  or classical control flow diagrams (flowcharts).
• They show sequencing dependencies between tasks.
• Some tasks must be done sequentially, others can
  be done in parallel i.e., an activity diagram
  shows the workflows of a system.
• An activity diagram provides detailed view of
  processes.
• A black bar denotes splitting a control flow into
  several parallel activities or merging several
  parallel control flows into a single activity.

24
Activity diagrams -example
Create curriculum
Select course to teach
Assign professor to courses
All profs assigned?

No
Yes
Create catalog
Place catalog in bookstore
Mail catalog to students
Open registration
25
Package diagrams
Show how classes can be divided into logical
packages. They also show high-level
relationships between packages.
Interfaces
University
Artifacts
26
Component diagrams
Show dependencies between run-time components of
the software. They should be used during
implementation of the software.
Professor.exe
Database.dll
Course.dll
ProfessorInformation
ProfessorCourseOptions
AddACourse
Run-time of Professor.exe
27
Deployment diagrams
A deployment diagram models physical platforms
and network connections used by system. It
matches CPUs to software components. Arbitrary
icons can be used to represent nodes.
Database
Registration
professor.exe
Library
Dorm
Main
student.exe
Building
student.exe
student.exe
28
UML diagrams in Analysis and Design
Component diagrams
Package diagrams
Obligatory Optional
User interface screens
Deployment diagrams
Class diagrams
Use Case diagrams
User requirements
Physical data structures
Sequence diagrams
Implementation code
State diagrams
Collaboration diagrams
Activity diagrams
testing