bis 7099
DESCRIPTION
BIS7099TRANSCRIPT
-
Class Diagrams! Gives an overview of a system by showing its classes
and the relationships among them. " Class diagrams are static " they display what interacts but not what happens
when they do interact" Also shows attributes and operations of each class" Good way to describe the overall architecture of system
components"
-
Class Diagram Perspectives! We draw Class Diagrams under three perspectives"
Conceptual" Software independent" Language independent"
Specification" Focus on the interfaces of the software"
Implementation" Focus on the implementation of the software"
-
Example UML Class Diagram!
3
-
Class!
Class Name
Attribute : type
Operation (arg list) : return type
Abstract operation
Various parts are optional
-
Instance Specification(Object)!
ObjectName: Class Name
Attribute : type
Operation (arg list) : return type
Abstract operation
Various parts are optional
-
Role of A Role of B
Kinds of Edges!
Class A Class B
Source Target Role name
Client Supplier Dependency
Navigability
Association
Role name
There are other kinds of edges
-
Multiplicities on Edges (Cardinalities)!
1 " " "Exactly one"* " " "Many (any number)"0..1 " "Optional (zero or one)"m..n " "Specified range"{ordered}* "Ordered"
-
Generalization (Inheritance)!
Supertype
Subtype 1 Subtype 2
-
Note (Comment)!
Comment about an item
Some item eg
class
-
Classes Not Just for Code! A class represent a concept" A class encapsulates state (attributes) and
behavior (operations).! Each attribute has a type." Each operation has a signature." The class name is the only mandatory
information."
zone2price!getZones()!getPrice()!
TariffSchedule!
Table zone2price!Enumeration getZones()!Price getPrice(Zone)!
TariffSchedule!
Name"
Attributes"
Operations"
Signature"
TariffSchedule!
-
Instances!
An instance represents a phenomenon." The name of an instance is underlined and
can contain the class of the instance." The attributes are represented with their
values."
zone2price = {!{1, .20}, {2, .40},!{3, .60}}!
tarif_1974:TariffSchedule!
-
UML Class Notation! A class is a rectangle divided into three parts"
Class name" Class attributes (i.e. data members, variables)" Class operations (i.e. methods)"
Modifiers" Private: - " Public: +" Protected: #" Static: Underlined (i.e. shared among all members of the class)"
Abstract class: Name in italics"
+getName() : string+setName()-calcInternalStuff(in x : byte, in y : decimal)
-Name : string+ID : long#Salary : double
Employee
-
UML Class Notation! Lines or arrows between classes indicate relationships"
Association" A relationship between instances of two classes, where one class
must know about the other to do its work, e.g. client communicates to server"
indicated by a straight line or arrow" Aggregation "
An association where one class belongs to a collection, e.g. instructor part of Faculty"
Indicated by an empty diamond on the side of the collection" Composition"
Strong form of Aggregation " Lifetime control; components cannot exist without the aggregate" Indicated by a solid diamond on the side of the collection"
Inheritance" An inheritance link indicating one class a superclass relationship,
e.g. bird is part of mammal" Indicated by triangle pointing to superclass"
-
Binary Association!
myB.service(); myA.doSomething();
Binary Association: Both entities Know About each other
Optionally, may create an Associate Class
-
Unary Association!
A knows about B, but B knows nothing about A
Arrow points in direction of the dependency
myB.service();
-
Aggregation!
Aggregation is an association with a collection-member relationship
void doSomething() aModule.service();
Hollow diamond on the Collection side
No sole ownership implied
-
Composition!
+getName() : string+setName()-calcInternalStuff(in x : byte, in y : decimal)
-Name : string+ID : long#Salary : double-adfaf : bool
Employee
-members : EmployeeTeam
1*
Composition is Aggregation with: Lifetime Control (owner controls construction, destruction)
Part object may belong to only one whole object
Filled diamond on side of the Collection
members[0] = new Employee();
delete members[0];
-
Inheritance!
Standard concept of inheritance
class B() extends A
Base Class
Derived Class
-
UML Multiplicities!
Multiplicities Meaning
0..1 zero or one instance. The notation n . . m indicates n to m instances.
0..* or * no limit on the number of instances (including none).
1 exactly one instance
1..* at least one instance
Links on associations to specify more details about the relationship
-
UML Class Example!
-
Association Details! Can assign names to the ends of the association to give
further information"
+ getName () : string + setName () - calcInternalStuff ( in x : byte , in y : decimal )
- Name : string + ID : long # Salary : double - adfaf : bool
Employee - members : Employee Team - group
1 - individual *
-
Use Case!
-
Use Cases Definition! A Use Case is a way of using a system"
o A scenario that describes limited interaction between a system and actors in the field "
In a Use Case, you describe the use of a system for a given work task"o You consider a complete work task, initiated by
an actor"o You utilise company language in describing the
work task"o The aggregate Use Cases display the aggregate
actor use of the system"
""
-
The purpose of use cases!
The purpose for using use cases is to"o Uncover and describe all tasks that need doing in a system
(of both human and system actors)"o To analyse what functionality that need developing for the
system"
o The use of use cases must mean that the right functional requirements are made of the IT system (the requirements of the business!)"
-
Where are we?!
Phase Actions Outcome Initiation Raising a business need Business documents
Requirements Interviewing stakeholders, exploring the system environment Organized documentation
Specification Analyze the engineering aspect of the system, building system concepts Formal specification
Design Define architecture, components, data types, algorithms Formal Specification
Implementation Program, build, unit-testing, integrate, documentation Testable system
Testing & Integration Integrate all components, verification, validation, installation, guidance Testing results, Working sys
Maintenance Bug fixes, modifications, adaptation System versions
-
Use cases are documented in two ways!
Use Case diagrams"o Give an overview of visible use scenarios in the
system"o Describes what actors that interact with the system"o Describes any linkages between use cases"
"" Verbal description"
o Describes the content of each use case "o Typically uses a pre-defined template"
-
UML - Use case diagram! Definition:"
o diagram which provides an overview of system functionality"
o Shows which use cases the individual actor uses"
Purpose:"o To analyse the functionality the
system must include"o To give an overview of the
functionality and how it is linked"o To analyse how the actors should
use the system"
Challenges:"o To simplify the complex"
Construction elements:!""
"""Package"
"""Use case"
"Communication arrow"
"""
"Extends a use case"
"""
"Includes a use case"
""
No. and use case name
Package name
extends
-
UML use cases Actors! Actor:"
o Person (or system), which uses the system (think in terms of roles)"
Purpose:"o To analyse which actors will
use the system"o To analyse how the use of the
actors is linked"
Challenges:"o It is NOT an organisational
chart (no organisational linkages required)"
"
Construction elements:!
"""
"Actor""
"""Specialisation /Generalisation"
Aktr
-
Example of use case diagram!Web store
Find an item
Order an item
Check order
Customer
Registered customer
SADAD
Order fast delivery
Free search
Structured search
Actor (person)
Actor (system)
use case
-
Prerequisites!
Always begin by making a stakeholder analysis! (In case it has not been done during process modelling)"o A good way of discovering new use cases"o A high degree of confidence that all relevant use cases are
included"o The use case actors are often only part of the overall pool
of stakeholders"
-
Requirements vs. Design!
Requirements:" What the system should do" More abstract"
Design:" How the system should do it" More detailed"
-
Source of Requirements! Initial requirements come from the customer, by:"
Documents, such as RFI/RFP" Meetings, reports"
Advanced requirements come from the analysts, after studying:" Scope and price" Feasibility (technological, organizational etc)" Prototypes"
Final requirements are stabilized in an iterative process.
-
Types of Requirements!
Visible Functional Requirements" The system will deliver cash to
the customer" Cash will be delivered after card
was taken out" Qualitative Requirements"
The authorization process will take no more than 1 sec"
The user interface will be easy to use"
Hidden Requirements" Database maintenance
processes will occur every night"
Qualitative Requirements
Hidden Functional
Requirements
Functional Visible
Requirements
-
Use Cases!
A use case is a contract of an interaction between the system and an actor."
A full use-case model comprise of:" A diagram, describing relations between use-
cases and actors." A document describing the use case in details "
Register User
Use case in diagram Use Case in script
admin
-
What Makes Good Use-Case Specification?!
Lack of ambiguity" Each requirement must be interpreted in a single
manner." Completeness"
They should cater for all current demands of the system."
Consistency" Requirements should not conflict with each other. If
there are, tradeoffs must be detected and discussed." Avoid design"
Requirements should raise a need, not answer it. (Why?)"
-
Draw use case packages!
1. Draw use case packages - for each business process"
o Base it on the processes"o Has a thorough stakeholder analysis been done?"o Put all actors for each business process on the packages""
-
Grouping of business functionality Use case packages!
Use case packages divide use cases into packages that make business sense" Typically, cases that belong to a given process" But it could also be use cases in a given topic / with particular
actors / other"""
The packages help to provide overview" If a documentation tool is used,
use cases may be organised as illustrated"
-
Draw use case diagrams!
2. Draw use case diagrams - for each package"o Which of the process diagram activities are relevant to the
solution?"o An activity in a process corresponds to a use case (using
this method)"
-
Use Case Example!
Copyright e-Government Program (Yesser)
Use case diagram: Work Permit
Work Permit
View decision
Process request
Company HR officer
Payment
MoL new solution
MoI system
SADAD
Request Work Permit
Employee
-
Identify actors!
3. Identify actors - for each use case"o Who or what initiates the use case?"o Split the actors into roles (not e.g. according to organisational
dependence)"o Any specialisations of an actor?"o Split the actors into those that initiates (triggers) a use case, and
those that are passive actors (e.g. received data)"
-
Complete verbal description!
4. Complete verbal description - for each use case"o What is the purpose of the use case?"o What needs to be done for the use case to begin? (start
conditions)"o Describe the steps in the use case"
o What does the actor do? How does the system react?"o What is the result of the use case? (end conditions)"
"
-
Use cases Verbal description!
Copyright e-Government Program (Yesser)
-
Use Case - verbal description! There is no standardised notation for how a use case is
described, verbally"
The description typically includes:" The Use Case name" Purpose" Actors" Start conditions (premises)" Description of the use case steps" Any exceptions" Any variants" End conditions (result)"
-
Use cases Verbal description! Use case descriptions always include a highway"
And may contain both variants and exceptions"
The highway describes:" The way the use case is typically run through"
Variants describe:" Alternative ways the use case may be run through" The highway and variants can be equally important" Start and end conditions will be common with the highways"
Exceptions describe:" Events that cause failure to perform use case as described" I.e. end conditions are not met"
- Start and end conditions are often under estimated!" Make sure they are precise and well-defined"
-
Identify variants and exceptions!
5. Identify all variants and exceptions and firm up the start and end conditions"o What alternative routes would complete the use case?"o Any exceptions that would make the use case stop?"o Review the start and end conditions once again"
- Are they precise and well-defined?"- Have all variants been considered?"
-
Audit business process and term model!
After completion of use cases (or during) a need will often rise to adjust the process diagrams"o You gain knowledge as you dig deeper into the material"
o The activities (and their order) may need adjustment"o You typically discover new actors/roles and new interfaces
with other systems / stakeholders"
Need to add new terms to the term model"o And maybe correct the use case descriptions to ensure
strict use of the terms in the term model""
-
Use cases best practice! The grain of use cases what is the right size for a use
case?"o A UC must contain a complete task that needs solving not
just a step in a task"o Well-defined start and end conditions"o Feel your way forward it takes experience!
"
The aggregate use cases do not need to reflect a workflow!"o If you do that, the use cases may well be too fine-grained"
" Naming a UC use imperative verbs!"
o E.g. Acquire car Search for car Get FDM test etc."o A good idea to attach numbers to the use cases (not
meaningful IDs!)"
-
Definition of use cases - tips! Know your business!"
o Be business oriented"o The professional experts must participate in the completion of use cases
" Keep matters abstract"
o Describe functionality not solution designs"o Keep use case descriptions free from computer monitor-thinking
" Requirement specification with creativity and visions"
o It is important that project participants are visionary and do not re-create existing solutions"
You may want a resource able to coordinate business and technical aspects"
o Has an idea of how a use case can be technically realised"o Can discuss issues with the technical staff"
-
Levels of Use Cases! Use Case Diagrams can be at different levels of
granularity:" One diagram can show a system-wide view with
every actor" This diagram can be later refined into design-level
use cases"
-
Using Generalization!
-
Sequence Diagram!
-
Interaction Diagrams!
A series of diagrams describing the dynamic behavior of an object-oriented system." A set of messages exchanged among a set of
objects within a context to accomplish a purpose." Often used to model the way a use case is realized
through a sequence of messages between objects."
-
Interaction Diagrams (Cont.)!
The purpose of Interaction diagrams is to:" Model interactions between objects" Assist in understanding how a system (a use
case) actually works" Verify that a use case description can be
supported by the existing classes" Identify responsibilities/operations and assign
them to classes"
-
Interaction Diagrams (Cont.)!
UML " Collaboration Diagrams"
Emphasizes structural relations between objects"
Sequence Diagram" The subject of this tutorial"
-
A First Look at Sequence Diagrams!
Illustrates how objects interacts with each other." Emphasizes time ordering of messages." Can model simple sequential flow, branching,
iteration, recursion and concurrency.""
-
A Sequence Diagram!
member: LibraryMember book:Book
:Book Copy
borrow(book) ok = mayBorrow()
[ok] borrow(member) setTaken(member)
-
A Sequence Diagram!
member: LibraryMember book:Book
:Book Copy
borrow(book) ok = mayBorrow()
[ok] borrow(member) setTaken(member)
X-Axis (objects)
Y-Axis (tim
e)
Object Life Line
message
Activation box
condition
-
Object!
Object naming:" syntax: [instanceName][:className]! Name classes consistently with your
class diagram (same classes)." Include instance names when objects
are referred to in messages or when several objects of the same type exist in the diagram."
The Life-Line represents the objects life during the interaction"
myBirthdy :Date
-
Messages!
An interaction between two objects is performed as a message sent from one object to another (simple operation call, Signaling, RPC) "
If object obj1 sends a message to another object obj2 some link must exist between those two objects (dependency, same objects)"
-
Messages (Cont.)!
A message is represented by an arrow between the life lines of two objects." Self calls are also allowed" The time required by the receiver object to
process the message is denoted by an activation-box."
A message is labeled at minimum with the message name." Arguments and control information (conditions,
iteration) may be included."
-
Return Values!
Optionally indicated using a dashed arrow with a label indicating the return value." Dont model a return value when it is obvious
what is being returned, e.g. getTotal()" Model a return value only when you need to refer
to it elsewhere, e.g. as a parameter passed in another message."
Prefer modeling return values as part of a method invocation, e.g. ok = isValid() "
-
Synchronous Messages!
Nested flow of control, typically implemented as an operation call." The routine that handles the message is
completed before the caller resumes execution."
:A :B
doYouUnderstand()
Caller Blocked
return (optional) yes
-
Object Creation!
An object may create another object via a message."
:A :B
Constructor
:A :B
Preferred
-
Object Destruction!
An object may destroy another object via a message." An object may destroy itself." Avoid modeling object destruction unless
memory management is critical."
:A :B
-
Control information!
Condition" syntax: [ expression ] message-label" The message is sent only if the condition is true" example:"
Iteration" syntax: * [ [ expression ] ] message-label" The message is sent many times to possibly
multiple receiver objects. "
[ok] borrow(member)
-
Control Information (Cont.)!
Iteration examples:"
:Driver
*[until full] insert()
:Bus
The syntax of expressions is not a standard
:CompoundShape :Shape
*draw() draw()
-
Control Information (Cont.)!
The control mechanisms of sequence diagrams suffice only for modeling simple alternatives. " Consider drawing several diagrams for modeling
complex scenarios." Dont use sequence diagrams for detailed
modeling of algorithms (this is better done using activity diagrams, pseudo-code or state-charts)."
-
getViolation(id)
Example 1!
Clerk
:Violations Dialog
:Violations Controller
:Violations DBProxy
lookup viewButton()
id=getID()
v:Traffic Violation
display(v)
v
Lookup Traffic
Violation
May be a
pseudo-method DB is queried
and the result is returned as
an object
-
Example 2!
print(doc,client) Client
:PrintServer :Queue :Printer Proxy
enqueue(job)
status
Printing A Document
job=dequeue()
[job]print(job.doc)
[job] done(status)
Repeated forever with 1 min interludes
Active object