Gints turlajs prezentācija RSU 5 sept

Modeļi: uzbūve, elementi, hierarhija,
saites. Sistēmiskā pieeja modeļu
izmantošanā. Biznesa procesu,
personāla vadības un mārketinga
procesu, saistība ar informācijas
tehnoloģijām.
Gints Turlajs

In short about me
• Studied economics and business management in 4
universities: Stockholm School of Economics in
Riga, University of Southern Denmark, University
of Latvia, Riga Technical University.
• CEO of Smart Continent LV Ekoterm SIA and
SIA Institute (www.smartcontinent.com,
www.siaekoterm.com, www.aci.lv,
www.itinstitute.info).
2

In short about me
• Have worked for European Commission, SEB banka, Latvijas Banka,
Ministry of Economics, newspaper Diena, have lead own businesses.
• Have lectured and done some academic work in RTU, Banku
augstskola, Stockholm School of Economics in Riga.
• Ex-board member of Economists Association of Latvia
(www.leaekonomisti.lv).
• Board member of Association of Latvian Young Scientists
(www.ljza.lv), ex-president.
• Ex-president of Riga Ridzene Rotary club.
• Member of Latvijas Biznesa Konsultantu Asociācija
3

In short about me
• Have initiated founding and managed
AEGEE Riga (www.aegee-riga.lv), ESN Riga (www.esn.lv, an
organization that can help You a lot!), etc.
• Co-founder of Internation Institute of Business Analysis Latvia
chapter, member European Movement, ISACA, Baltic Sea Region
Cluster Experts Society and many other associations.
• Auditor of Alumni Association of Stockholm School of
Economics in Riga.
4

What about You?
Let’s make an
introduction
round! 5

My contacts
•I can be reached by:
•Email: gints@aci.lv
•Telephone: +371 29409509
•Skype: gintst
•Feel free to contact me in the case of necessity.6

Nenoteiktība Biznesā un Modelēšana
• Sistēmiska pieeja jeb sistēmu modelēšana tiek uzskatīta
par vienu no 3 pamata metodoloģiskajām pieejām
biznesa zināšanu iegūšanai, papildus analītiskajai pieejai
un aktieru pieejai jeb uz aģentiem bāzēto modelēšanu
(Abnor&Bjerke, 2009).
• Nenoteiktība biznesā un sociālajās zinātnēs vispār ir ļoti
liela, tādēļ to tiek mēģināts mazināt ar modelēšanas
palīdzību.
• Lai arī modeļi bieži vien neizpildās, tie dod jaunu
domāšanas perspektīvu to analizētājiem.

Mārketingu un Personālu Sasaistošs
Modelis

Citi modeļi
• Arī mārketinga 4 vai 5 P ir modelis;
• Matemātiskā formula arī ir modelis;
• Jaunu modeļu radīšana ir fantastisks resurss
doktora grāda iegūšanai – arī es doktora
disertācijai esmu radījis vairākas shēmas,
diagrammas utt.

Segmentation, Targeting and Positioning
(STP) Model
• An approach that you can use to identify your most valuable market segments,
and then sell to these successfully with carefully targeted products and
marketing.
• About the Model
• The STP Model consists of three steps that help you analyze your offering and
the way you communicate its benefits and value to specific groups.
• STP stands for:
• Step 1: Segment your market.
• Step 2: Target your best customers.
• Step 3: Position your offering.
• This model is useful because it helps you identify your most valuable types of
customer, and then develop products and marketing messages that ideally suit
them. This allows you to engage with each group better, personalize your
messages, and sell much more of your product.

Example of STP application
• Marriott International® owns a number of different hotel chains that
target specific consumer groups.
• For example, Courtyard by Marriott® hotels focus on travelers on the road,
who want a nice, clean place to stay during their trip; Ritz-Carlton® hotels
target those who don't mind paying a premium for luxury; and Marriott
ExecuStay® hotels are aimed at professionals who need a longer-term,
comfortable place to stay.
• As you can imagine, Marriott International doesn't communicate the same
marketing message to all its customers. Each hotel is designed and
positioned to appeal to the unique wants and needs of a specific group.

Par modelēšanu kopumā
Modelēšana ir ļoti plašs jēdziens ar pielietojumu daudzās jomās
un tā nozīme ir, ka tiek radīts kāds matemātisks, vizuāls vai cita
veida modelis, kas atbilst kādai sistēmai vai elementam. Šo
jēdzienu lieto gan modes industrijā apģērbu radīšanā, gan
arhitektūras modeļiem, gan pat spēļu modeļiem, kas attēlo,
piemēram, lidmašīnas vai automašīnas. Pēc būtības modelim ir
jāatbilst izteiksmei
µ╞φ,
kas nozīmē, ka modelis µ tiek ietverts vienādojumā φ, kas labi
izskaidro doto modeli un sekojoši arī sistēmu.

Par modelēšanu kopumā
Modelēšanas jēdziens bieži tiek izmantots fizikā,
inženierzinātnēs un tagad arī daudzās citās jomās. Tiek
uzskatīts, ka nopietna informācijas sistēmu modelēšana ir vairāk
kā 50 gadus veca, lai arī mēs zinām, ka lēdija Augusta Ada King,
Lavleisas grāfiene datorprogrammas rakstīja jau 19.gadsimtā.
Tādēļ ir pamats uzskatīt, ka pirmie sistēmu modelēšanas
mēģinājumi ir krietni senāki par 50 gadiem. Savā ziņā pat zvēru
zīmējumus uz alu sienām pirms daudziem tūkstošiem gadu var
uzskatīt par šo zvēru grafiskiem modeļiem.

Kādiem mērķiem
biznesa procesa modelēšanai
iespējami
vairāki mērķi
informācijas sistēmas izveidošana
procesu sakārtošana, labākā varianta
sameklēšana
informācijas apmaiņa (t.sk. apmācība)
ir zināmas daudzas notācijas
dažas no tām ir vairāk populāras
katrai konkrēti mērķi, diemžēl šauri

IT pieeja - attīstība
ja jāizvēlas no pieejamām notācijām un to
atbalstošiem rīkiem, uzdevums triviāls
BET
šobrīd tiek veidoti universāli rīki, kur
lietotājs pats būs spējīgs definēt
modelēšanas pieeju (atbilstoši arī
notāciju)
jautājums sekojošs – kādas lietas būtu
svarīgi parādīt modelī no biznesa viedokļa

IT pieeja - process kā daļa no
vides
modelēti tiek procesi, kuri bieži ir jāatkārto
procesi neeksistē kā neatkarīgas vienības
katrs process ir kaut kā turpinājums un kaut
kā sākums
katrs process kaut ko izmanto no
apkārtējās vides (resursi, regulācijas)
katrs process kaut ko pārveido

Procesa konteksts
Vid
e
Proces
s
Uzdevums Uzdevums
Uzdevums
Uzdevums
Notikums
Notikums
Notikums
Notikums
Notikums
Notikums
Notikums
Resur
si
Ierobežojum
i
X

Modelēšanas valodas loma
19
• Modelēšanas valoda ļauj viennozīmīgi aprakstīt
vienu un to pašu lietu
• Modelēšana valodas ļauj formalizēt lietas, procesu utt. un veikt
dažādas transformācijas citās valodās t.sk. arī kodā
• Piemēri:
– UML – Unified Modeling Language
– BPMN – Businesss Process Model and Notation
– IDEF – Integration Definition (IDEF0/14)
– GRAPES-BM biznesa modelēšanas valoda (Grade)

Jauno pasaules modelēšanas standartu radītājs -
Object Management Group
• The Object Management Group® (OMG®) is an international, open membership,
not-for-profit technology standards consortium, founded in 1989.
• OMG standards are driven by vendors, users, academic institutions and
governments. OMG Task Forces develop enterprise integration standards for a wide
range of technologies and an even wider range of industries.
• OMG’s modeling standards, including the Unified Modeling Language
(UML) and Model Driven Architecture (MDA), BPMN (Business
Process Model and Notation) enable powerful visual design, execution and
maintenance of software and other processes.
www.omg.org

UML: Unified Modeling Language
-

Many Stakeholders , many views
 Architecture may be many things to many different stakeholders
End user
Project Manager
System Engineer
Developer
Tester
Maintainer
 Multidimensional Reality
 Many Stakeholders
multiple views , multiple blueprints

Models
Modeling in IT world is the designing of software applications
before coding.
Models are the higher level of abstraction of the System.
A model plays the analogous role in software development that
blueprints and other plans (site maps, elevations, physical models)
play in the building of a skyscraper.
Modeling is the only way to visualize the design and check it against
requirements before one starts to code.
Models are also the vehicle for communication with various stake
holders.

What is UML?
General-purpose modeling language
Helps to specify, visualize, and document models
of software systems
High Level abstraction of the system
Represents the system using Graphical Notations
from various Perspectives
used for business modeling and modeling of
other non-software systems too
UML 2.0

Evolution of UML
• Successor to the wave of Object Oriented Analysis and
Design(OOA&D).
• unifies the notations used by three amigos(Grady Booch, Ivar
Jacobson and James Rumbaugh) in their OO methods.
• OMG

Different Perspectives of System

Basic Terms
A model is an abstraction of the underlying problem.
The domain is the actual world from which the problem
comes.
Models consist of objects that interact by sending each other
messages.
Objects have things they know (attributes) and things they
can do (behaviors or operations).
The values of an object's attributes determine its state.
Classes are the "blueprints" for objects. A class wraps
attributes (data) and behaviors (methods or functions) into a
single distinct entity. Objects are instances of classes.

The Unified Modelling Language – 1.4
Structural Diagrams- class, object, component, deployment diagrams.
Behavioural Diagrams – Use Case , Activity and State Chart diagrams.
Interaction Diagrams – Sequence and Collaboration diagrams.
Use Case
Diagrams
Use Case
Diagrams
Use Case
Diagrams
Scenario
Diagrams
Scenario
Diagrams
Collaboration
Diagrams
State
Diagrams
State
Diagrams
Component
Diagrams
Component
DiagramsComponent
Diagrams
Deployment
Diagrams
State
Diagrams
State
Diagrams
Object
Diagrams
Scenario
Diagrams
Scenario
Diagrams
Statechart
Diagrams
Use Case
Diagrams
Use Case
Diagrams
Sequence
Diagrams
State
Diagrams
State
Diagrams
Class
Diagrams
Activity
Diagrams
Models

30
Piemērs (1)
Pilsētas satiksmes elektronisko biļešu sistēma
•Persona var iegādāties dažādu veidu biļetes: noteiktu braucienu skaitu
vai mēnešbiļeti. Mēnešbiļetes cena ir atkarīga no transporta veidiem
(autobuss, trolejbuss, tramvajs), kā arī no nedēļās dienām un to skaita.
Persona kioskos var iegādāties vienu vai vairākas biļetes ar dažādu braucienu
skaitu. Mēnešbiļetes persona var iegādāties speciālos automātos vai klientu
apkalpošanas nodaļās.
•Iekāpjot transportā pēc iespējas ātrāk ir jāatzīmē biļete pie kompostiera, kas ar
zaļo krāsas signālu, skaņas signālu un ar uzrakstu par atlikušo braucienu skaitu
informē, ka biļete reģistrēta veiksmīgi. Ja braucienu skaits ir 0, tad tiek
padots speciāls skaņas signāls un iedegas sarkanais signāls. Gadījumā, ja biļete
jau ir atzīmēta, tad tiek paziņots, ka biļete jau ir atzīmēta. Vienreizējo
biļeti var iegādāties pie autovadītāja. Pirmo reizi izmantojot viena
transporta braukšanas mēnešbiļeti ir jāatzīmē tieši attiecīgajā transportā,
gadījumā, ja mēnešbiļetes īpašnieks ir pielaidis kļūdu, biļeti iespējams
pārprogrammēt, aizejot uz klientu apkalpošanas punktu.
•Iegādājoties biļeti, iespējams saņemt atlaidi, ja pircējs ir students,
skolnieks, pensionārs vai invalīds.

Piemērs (2)
31
Persona/Klients
Iegādāties
mēnešbiļeti
Iegādāties
vienreizējo biļeti
Iegādāties vairāku
braucienu bileti
Kompostrēt biļeti
«uses»
«uses»
Skolnieks/Students
Pensionārs/Invalīds
Braukt
«uses»
«extends»
Klientu apkalpošanas punkts
Pārprogrammēt
biļeti
Pārdod biļetes ar
atlaidi
Atjaunot biļeti
UML UseCase
diagramma
vai

USE CASE DIAGRAM
• Outsider's view of a system.
• Emphasizes on what a system does rather than how.
• Use case diagrams are the collection of scenarios.
• A scenario is an example of what happens when someone(Actor) interacts with
the system.
• Scenarios together accomplishes a specific goal of the user.
• Every use case diagram has actors, use cases, and communications.

Use Case Modeling: Core Elements
Introduction to UML
33
Construct Description Syntax
use case A sequence of actions, including
variants, that a system (or other
entity) can perform, interacting with
actors of the system.
actor A coherent set of roles that users
of use cases play when interacting
with these use cases.
system
boundary
Represents the boundary between
the physical system and the actors
who interact with the physical
system.
U s e C a s e N a m e
A c t o r N a m e

Use Case Modeling: Core Relationships
Introduction to UML
34
association The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
extend A relationship from an extension use
case to a base use case, specifying
how the behavior for the extension
use case can be inserted into the
behavior defined for the base use
case.
generalization A taxonomic relationship between a
more general use case and a more
specific use case.
<<extend>>

Use Case Modeling: Core Relationships
(cont’d)
Introduction to UML
35
include An relationship from a base use case
to an inclusion use case, specifying
how the behavior for the inclusion use
case is inserted into the behavior
defined for the base use case.
<<include>>

Extend and Include Relationship
We can add extend relationships to a model to show the following situations:
A part of a use case that is optional system behavior
A subflow is executed only under certain conditions
A set of behavior segments that may be inserted in a base use case
Include Relationship
The behavior of the inclusion use case is common to two or more use cases.
The result of the behavior that the inclusion use case specifies, not the
behavior itself, is important to the base use case.

USE CASE DIAGRAM
Use case diagrams are helpful in three areas.
determining features (requirements).
New use cases often generate new requirements as the system is analyzed
and the design takes shape.
communicating with clients.
Their notational simplicity makes use case diagrams a good way for
developers to communicate with clients.
generating test cases.
The collection of scenarios for a use case may suggest a suite of test cases
for those scenarios.

CLASS DIAGRAM
Structural overview of a system by showing its classes and the relationships
among them
Static diagrams
Static relations:
Associations
Subtypes
Static structure:
 Attributes
 Operations
Created along with use case diagrams
Transition from what? to How?

CLASS DIAGRAM- Class
The illustration uses the following UML™
conventions.
• Static members are underlined. Instance
members are not.
• The operations follow this form:
<access specifier> <name> ( <parameter list>) :
<return type>
•The parameter list shows each parameter type
preceded by a colon.
• Access specifiers appear in front of each
member.

Klašu diagrammas pamatelementi
• Klase (abstrakcija), var būt
noteiktas īpašības un
metodes
• Pakotne apvieno vienu vai
vairākas metodes
• Interfeiss nosaka klases
ārējo saskarni ar citām
klasēm, lai nebūtu
nepieciešams klases līmenī
kontrolēt pieeju tās
elementiem
• Uzskaitījums
• Klases eksemplārs ar
inicializētām īpašību
vērtībām
Klase
+īpašības
+metodes()
Pakotne
Interfeiss
<<enumeration>>
Uzskaitījums
Objekts
1..*1
• Mantošana jeb
vispārināšana
• Asociācija ar virzienu
• Agregācija
• Kompozīcija
• Asociācija (bez virziena)
• Atkarīgums, pakļautība
• Realizācija

Piemērs (1)
Pilsētas satiksmes elektronisko biļešu sistēma
•Persona var iegādāties dažādu veidu biļetes: noteiktu braucienu skaitu
vai mēnešbiļeti. Mēnešbiļetes cena ir atkarīga no transporta veidiem
(autobuss, trolejbuss, tramvajs), kā arī no nedēļās dienām un to skaita.
Persona kioskos var iegādāties vienu vai vairākas biļetes ar dažādu braucienu
skaitu. Mēnešbiļetes persona var iegādāties speciālos automātos vai klientu
apkalpošanas nodaļās.
•Iekāpjot transportā pēc iespējas ātrāk ir jāatzīmē biļete pie kompostiera, kas ar
zaļo krāsas signālu, skaņas signālu un ar uzrakstu par atlikušo braucienu skaitu
informē, ka biļete reģistrēta veiksmīgi. Ja braucienu skaits ir 0, tad tiek
padots speciāls skaņas signāls un iedegas sarkanais signāls. Gadījumā, ja biļete
jau ir atzīmēta, tad tiek paziņots, ka biļete jau ir atzīmēta. Vienreizējo
biļeti var iegādāties pie autovadītāja. Pirmo reizi izmantojot viena
transporta braukšanas mēnešbiļeti ir jāatzīmē tieši attiecīgajā transportā,
gadījumā, ja mēnešbiļetes īpašnieks ir pielaidis kļūdu, biļeti iespējams
pārprogrammēt, aizejot uz klientu apkalpošanas punktu.
•Iegādājoties biļeti, iespējams saņemt atlaidi, ja pircējs ir students,
skolnieks, pensionārs vai invalīds.

Piemērs (4) – KL attiecības starp klasēm
44
sastāv
1
7
nosaka
4..7
1
pārdod
1..*
1
var braukt
1..*
1
kompostrē
0..1
1
pieder
1..*
1
attiecina
0..1
1
ir
1
1
Klients
Persona
Biļete
Vienreizējā biļete
Mēnešbiļete
Vairāku braucienu
biļete
Transports
AutobussTramvajsTrolejbuss
Nedēļa
Diena
Kiosks
Apkalpošanas punkts
Biļešu automāts
KompostierisSkolnieks
Pensionārs
Invalīds
Atlaide
Biļetes iegādes
vieta

Piemērs (5) – Klašu īpašības un metodes
Transports
+transporta numurs
+maršruts
Tramvajs
Kiosks
1
sastāv
7
nosaka
4..7
1
Biļetes iegādes vieta
+adrese
pārdod
1..*
1
var braukt
1..*
1
kompostrē
0..1
1
pieder
1..*
1
attiecina
0..1
1
ir
11
ir
10
1 1
Klients
+Klienta ID
Persona
+Vārds
+Uzvārds
+Personas kods
+Vecums
Biļete
-cena: Float
-ID
-pēdējā brauciena maršruts
-pēdējā brauciena datums un laiks
+iegādes datums un laiks
+aprēķināt cenu()
~pieškirtID()
~iegūtID()
Vairāku braucienu biļete
-atlikušo braucienu skaits
+izlietot()
Mēnešbiļete
-datums no
-datums līdz
-maršruts
-braucienu skaits
-aktivizēta
+izlietot()
~aktivizēt()
+Iegūt statusu()
+Iegūt datumu līdz()
+Iegūt braucienu skaitu()
+autovadītājs
+transporta numurs
+drukāt()
AutobussTrolejbuss
Nedēļa
Diena
+nosaukums
Biļešu automāts
+automāta ID
Kompostieris
-maršruts
-datums un laiks
-transporta numurs
+pārbaudīt biļeti()
+kompostrēt()
+blokēt()
+atbloķēt()
~inicializēt()
Skolnieks/Students
+Apliecības ID
+Derīguma termiņš
Pensionārs
+Apliecības ID
Invalīds
+Apliecības ID
+Derīguma termiņš
Atlaide
+likme%

Piemērs (6) – Klašu īpašību un argumentu tipi
0..1
ir
1 1
1
sastāv
7
nosaka
4..7
1
pārdod
1..*
1
var braukt
kompostrē
1..*
1
0..1
1
pieder
1..*
1
attiecina
1
ir
1 1
<<enumeration>>
Maršruts
46
Klients
+Klienta ID: String
Persona
+Vārds: string
+Uzvārds: string
+Personas kods: string
+Dzimšanas datums: DateTime
Biļete
-cena: decimal
-ID: String
-pēdējā brauciena maršruts: Maršruts
-pēdējā brauciena datums un laiks: DateTime
+iegādes datums un laiks: DateTime
+aprēķināt cenu(atlaide: Atlaide)
~pieškirtID()
~iegūtID(): string
+izlietot(): bool
Mēnešbiļete
-datums no: DateTime
-datums līdz: DateTime
-maršruts: Maršruts
-braucienu skaits: uint
-aktivizēta: bool
+izlietot(): bool
~aktivizēt(): bool
+Iegūt statusu(): bool
+Iegūt datumu līdz(): DateTime
+Iegūt braucienu skaitu(): uint
+autovadītājs: Persona
+transporta numurs: string
+drukāt()
Transports
+transporta numurs: String
+maršruts: Maršruts
Nedēļa
Diena
+nosaukums: string
Kiosks
Biļešu automāts
+automāta ID
Kompostieris
-datums un laiks: DateTime
-transporta numurs: String
+pārbaudīt biļeti(bil: Biļete)
+kompostrēt(inout bil: Biļete)
+blokēt()
+atbloķēt()
~inicializēt(trnum: String, maršr: Maršruts)
Skolnieks/Students
+Apliecības ID: string
+Derīguma termiņš: DateTime
Pensionārs
Invalīds
+Derīguma termiņš: DateTime
Atlaide
+likme%: decimal
Biļetes iegādes vieta
+adrese: string

Piemērs (7) – Klašu diagrammas citi elementi
+izlietot(): bool
Mēnešbiļete
-datums no: DateTime
-datums līdz: DateTime
-braucienu skaits: uint
-aktivizēta: bool
+izlietot(): bool
~aktivizēt(): bool
+Iegūt statusu(): bool
+Iegūt datumu līdz(): DateTime
+Iegūt braucienu skaitu(): uint
sastāv
1
7
nosaka
4..7
1
pārdod
1..*
1
1
pieder
1..*
attiecina
0..1
ir
11
ir
1 1
Intr_biļete
kompostrē
var braukt
47
1..*
11
darbojas ar
1..*
1
Klients
+Klienta ID:
String
Persona
+Vārds: string
+Uzvārds: string
+Personas kods: string
+Dzimšanas datums:
DateTime
Biļete
-cena: decimal
-ID: String
-pēdējā brauciena maršruts: Maršruts
-pēdējā brauciena datums un laiks: DateTime
+iegādes datums un laiks: DateTime
+aprēķināt cenu(atlaide: Atlaide)
~pieškirtID()
~iegūtID(): string
+autovadītājs: Persona
+transporta numurs: string
+drukāt()
Transports
+transporta numurs:
String
+maršruts: Maršruts
Nedēļa
Diena
+nosaukums:
string
Kiosks
Apkalpošanas
punkts
Biļešu
automāts
+automāta ID
Kompostieris
-datums un laiks: DateTime
-transporta numurs: String
+pārbaudīt biļeti(bil: Biļete)
+kompostrēt(inout bil: Biļete)
+blokēt()
+atbloķēt()
~inicializēt(trnum: String, maršr:
Maršruts)
Skolnieks/Students
+Derīguma termiņš:
DateTime
Pensionārs
+Apliecības ID:
string
Invalīds
+Derīguma termiņš:
DateTime
Atlaide
+likme%:
decimal
Biļetes iegādes
vieta
+adrese: string
<<enumeration>>
Maršruts

CLASS DIAGRAM
Class information: visibility and scope
• Attributes and operations can be labeled
according to access and scope
Symbol Access
+ public
- private
# protected

Class Operations
• An operation is the implementation of a service that can be
requested from any object of the class in order to affect
behaviour.
• Used to manipulate the attributes or to perform other actions.
• Operations are normally called functions, but they are inside a
class and can be applied only to objects of that class.
• Signature - return-type, a name and zero or more parameters.
• The signature describes everything needed to use the operation.

Class-Association
• Associations are structural relationships where instances (objects)
of one class are connected to instances (objects) of another class.
• an employee works for a company
• a company has a number of offices
• An association is normally bidirectional, which means that if an
object is associated with another object, both objects are aware of
each other (navigation is bidirectional by default).
• Binary association connects exactly two classes.
• The most common association is just a connection between
classes.

Association adornments: name, role
• The association has a name - the descriptive term, often a verb,
for the association.
• Each association has two association ends; each end is attached
to one of the classes in the association. An end can be explicitly
named with a label. This label is called a role name (association
ends are often called roles).

Reflexive Associations
A class has an association to itself.
Example: A directory may contain other directories.
Directory File
0..1
parent
subdirectory
0..*
1 0..*

Class Navigability
• A navigability arrow on an association shows which direction the
association can be traversed or queried.

Class Associations: multiplicity
• Multiplicity defines the number of objects
associated with an instance of the association.
• Default of 1 (1: 1)
• 0 or 1: 0..1
• Zero or more (0..infinite): *
• 1 or more (1..infinite): 1..*
• n..m; range from n to m inclusive
Car Person
transports
passenger
Car Person
transports
passenger
5
Car Person
transports
passenger
*
Car Person
transports
passenger
1..*
Car Person
transports
passenger
2..5

Class - Generalization
• A specialization / generalization relationship, in which objects of the specialized
element (child) are substitutable for objects of the generalized element (parent).
• Superclass – the generalization of another class, the child.
• Subclass – the specialization of another class, the parent.
Vehicle
WindPowered
Vehicle
MotorPowered
Vehicle
Land
Vehicle
Water
Vehicle
venue
venuepower
power
SailboatTruck
{overlapping} {overlapping}

Generalization - characteristics
Identify common features concerning behaviour
and knowledge. Define these common features on
a higher level in the inheritance hierarchy.
The aim is at behaviour more than knowledge
when combining classes.
Generalization is a bottom-up process.
A superclass includes all common properties of
its subclasses.

Specialization - characteristics
Define a new class which is a special appearance
of an existing class.
Specialization is a top-down process.
A subclass can have attributes and operations
that are specific for that sub-class.
A subclass may redefine operations of its super-
class

Class Diagram - Constraints
The basic constructs of association, attribute, and
generalization do much to specify important constraints.
They cannot indicate every constraint. These
constraints still need to be captured; the class diagram is
a good place to do that.
The UML allows you to use anything to describe
constraints. The only rule is that we put them inside
braces { }.

Aggregation and Composition
Associations in which an object is part of a whole are aggregations.
 Composition is a strong association in which the part can belong to only one whole --
the part cannot exist without the whole. Composition is denoted by a filled diamond at
the whole end.

Alternative Notation for Composition

Advanced Class Concepts : Abstract
• An operation is abstract if it has no
implementation.
• A abstract class cannot have any direct instances.
• Abstract classes only occur in the context of an
inheritance hierarchy.
• Abstract operations and classes are specified by
writing its name in italics.

Advanced Class Concepts : Abstract
cont.

UML Diagram Types as Class Diagram

Package Diagram
• To simplify complex class diagrams, we can group
classes into packages. Packages.
• Packages appear as rectangles with small tabs at
the top.
• The package name is on the tab or inside the
rectangle.
• The dotted arrows are dependencies.

Interaction : Sequence Diagram
Sequence diagrams and Collaboration diagrams
Class and object diagrams are static model views. Interaction
diagrams are dynamic. They describe how objects collaborate.
A sequence diagram is an interaction diagram that details
how operations are carried out -- what messages are sent and
when.
Sequence diagrams are organized according to time. The time
progresses as we go down the page.
The Sequence diagram lists objects horizontally, and time
vertically, and models these messages over time.

Sequence Diagram : Drawing Elements
Diagram Header Elements
 Actor Represents an external person or entity that interacts with the system
 Object Represents an object in the system or one of its components
 Unit Represents a subsystem, component, unit, or other logical entity in the system (may or
may not be implemented by objects)
 Separator Represents an interface or boundary between subsystems, components or units
(e.g., air interface, Internet, network)
 Group Groups related header elements into subsystems or components being modeled and are laid
out horizontally at the top of the diagram.

Sequence Diagram Body Elements
Message
Synchronous Message
Asynchronous Message
Create Message
Destroy Message
Action

Sequence Diagram Body Elements
Block(Loop or Conditional)
Page Break
Return Message
Free Note
Flow Note
Diagram links

Interaction : Sequence Diagram

Usage of Sequence Diagram
Complex interactions between components
components are being developed in parallel by
different teams
Supporting Robust interface covering multiple
scenarios
Use case elaboration
 can be used to flesh out the details of one or more
use cases

COLLABORATION DIAGRAM
Type of an interaction diagram.
Collaborates the static and dynamic relationship
Focus on Object Roles rather than timing.
Each message in a collaboration diagram has a sequence number.
The Collaboration diagram may be used to:
Describe a specific scenario by depicting the movement of messages between the
objects
Show a spatial organization of objects and their interactions, rather than the sequence
of the interactions

Sequence Diagram
Reserving a copy of book in Library

Collaboration Diagram
Reserving a copy of book in Library

STATE CHART DIAGRAM
Objects have behaviors and state.
The state of an object depends on its current activity or condition.
A statechart diagram shows the possible states of the object and the
transitions that cause a change in state.
Our example diagram models the login part of an online banking system.
Logging in consists of entering a valid social security number and personal id
number, then submitting the information for validation.
Logging in can be factored into four non-overlapping states: Getting SSN,
Getting PIN, Validating, and Rejecting. From each state comes a
complete set of transitions that determine the subsequent state.

State Chart Diagram – Dial Tone

STATE CHART DIAGRAM
States are rounded rectangles.
Transitions are arrows from one state to another.
Events or conditions that trigger transitions are written
beside the arrows.
Uses
The life history of a given class, usecase, operation
The events that cause a transition from one state to
another
The actions that result from a state change

ACTIVITY DIAGRAM
An activity diagram is essentially a fancy flowchart.
Activity diagrams and statechart diagrams are related.
Statechart diagram focuses attention on an object undergoing a process (or on
a process as an object).
An activity diagram focuses on the flow of activities involved in a single
process. The activity diagram shows the how those activities depend on one
another.

Element and its description Symbol
Initial Activity: This shows the starting point or first activity of the flow.
Activity: Represented by a rectangle with rounded (almost oval) edges.
Decisions: Similar to flowcharts.
Signal: When an activity sends or receives a message, that activity is called a
signal. Signals are of two types: Input signal (Message receiving activity)
shown by a concave polygon and Output signal (Message sending activity)
shown by a convex polygon.
Concurrent Activities: Some activities occur simultaneously or in parallel.
Such activities are called concurrent activities. For example, listening to the
lecturer and looking at the blackboard is a parallel activity. This is represented
by a horizontal split (thick dark line) and the two concurrent activities next to
each other, and the horizontal line again to show the end of the parallel
activity.
Final Activity: The end of the Activity diagram is shown by a bull's eye
symbol, also called as a final activity.

Implementation diagrams
• Show aspects of model implementation,
including source code structure and run-
time implementation structure
• Kinds
• component diagram
• deployment diagram

Component Diagram
• Shows the organizations and
dependencies among software
components
• Components include
• source code components
• binary code components
• executable components

Elements of component diagram
Element and its description Symbol
Component: The objects interacting
with each other in the system.
Depicted by a rectangle with the
name of the object in it, preceded by
a colon and underlined.
Class/Interface/Object: Similar to
the notations used in class and object
diagrams
Realization/Association: Similar
to the relation/association used in
class diagrams

Deployment Diagram
•Shows the configuration of run-time
processing elements and the software
components, processes and objects
that live on them
•Deployment diagrams may be used to
show which components may run on
which nodes

The Current Official UML Specification:
The current official version of UML and its
associated specifications can be
downloaded from OMG Specifications
Catalog page for Modeling and Metadata
Specifications at
http://www.omg.org/technology/documents/
modeling_spec_catalog.htm#UML

UML Certification
OCUP
OMG Certified UML Professional
Three Certification Levels:
OCUP Fundamental
OCUP Intermediate
 OCUP Advanced
Link : http://www.omg.org/uml-certification/

References
Web References :
http://www.uml.org/
http://dn.codegear.com/article/31863
http://www-
128.ibm.com/developerworks/rational/library/3101.html
http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html
Book References :
UML Distilled by Martin Fowler with kendall Scott, Pearson
Education.
User Guide for UML by Grady Booch, Ivar Jacobson and
James Rumbaugh

Reference:
• http://www.objectsbydesign.com
• – UML and OO links, forums, and resources
• http://www.devx.com/uml/
• – UML developer zone
• http://www.sdmagazine.com/
• – Magazine with many UML related articles
• http://www.omg.org
• – The UML Specification and other UML resources

BPMN
 Kas ir un kas nav BPMN?
 Kā BPMN atbalsta dažādu
procesu modelēšanas
līmeņus?
 BPMN elementi
 101

Procesu modelēšana
 Saistīto biznesa aktivitāšu secība, kas apraksta –
kā bizness sasniedz savus mērķus
 Pārveido procesa ieeju tā izejā, tādā veidā radot
vērtību klientam
 Procesu modelēšanas līmeņi:
 procesu karte – vienkārša aktivitāšu secība
 procesa apraksts – detalizēta aktivitāšu
plūsma
 procesa modelis – tāds detalizācijas līmenis,
102

Kas ir BPMN?
 Uz blokshēmas principa bāzēta procesu modelēšanas
notācija
 BPMN specifikācija ir kompromiss starp daudziem
modelēšanas rīku izstrādātājiem
 BPMN nodrošina mehānismu izpildāmā BPEL koda
ģenerēšanai
103

Kas BPMN nav?
 Organizācijas struktūra un lomas
 Datu struktūra
 Informācijas sistēmas
 Metrikas un KPI
 Resursi
104
 BPMN tikai procesu modelēšanai!

BPMN mērķi
 Saprotams biznesa cilvēkiem
 Ģenerē izpildāmos BPEL procesus
105

BPMN aktivitātes
 Uzdevumi:
 Cilvēka uzdevums
 Sistēmas/servisa uzdevums
 Apakšprocesi:
 «Process procesā»
 Hierarhisku procesu modeļu pamatā
 Transakcijas:
 Apakšprocess, kas satur biznesa transakciju
 Cikliskās aktivitātes
 Do.. While
 For

BPMN notikumi
 Notikums var iestāties procesa:
 sākumā
 starpposmā
 beigās
 Notikums procesā:
 saņem/nosūta ziņojumu
 iestājas nosacījums
 iestājas datums/laiks
 konstatē kļūdu
 beidzas laika intervāls
 aktivitāte ir jāatceļ
 …u.c.
 Notikums var būt saņemšanas un nosūtīšanas
 Notikums var apturēt procesa plūsmu – process apstājas un gaida notikuma
iestāšanos
 Notikums var tikai «klausīties» - process izpildās, kamēr iestājas notikums
Par katru notikumu jāsaprot-
1. Sākuma, starpposma vai
beigu notikums
2. Notikuma tips
3. Nosūtīšanas vai
saņemšanas notikums?
4. Pārtrauc vai tikai
«klausās»?

BPMN vārtejas
 Procesa plūsmas kontrole
 sadalīt plūsmu:
 pamatojoties uz lēmumu
 pamatojoties uz notikuma iestāšanos
 pamatojoties uz nosacījumiem
 paralēlās plūsmās
 plūsmas apvienošana
 paralēlo plūsmu sinhronizācija
 nosacījuma plūsmu apvienošana
 Izslēdzošā vārteja:
 sadalot – aktivizē tikai vienu izeju, balstoties uz datiem vai
notikumu
 apvienojot – sagaida pirmo aktīvo ieejas plūsmu, pārējās ignorē
 Paralēlā vārteja:
 sadalot – vienlaicīgi aktivizē visas izejošās plūsmas
 apvienojot – sagaida visas ieejošās plūsmas
 Ietverošā vārteja:
 sadalot – var aktivizēt vienu VAI visas izejošās plūsmas
 apvienojot – sagaida visas aktīvās ieejošās plūsmas
109International Institute of Business Analysis

BPMN savienojuma objekti
 Secības plūsma:
 aktivitāšu secība
 nevar šķērsot:
 pūla robežas
 apakšprocesa robežas
 Ziņojuma plūsma:
 ziņojumu apmaiņa starp pūliem
 nevar būt pūla robežās
 ziņojuma plūsmu var savienot tikai ar:
 pūlu
 ziņojuma notikumiem
 aktivitātēm
 Asociācijas:
 savieno datu objektus ar secības plūsmu vai aktivitātēm
 Citas plūsmas:
 nosacījuma plūsma
 noklusējuma plūsma

BPMN datu objekti
 Datu objektus izmanto, lai parādītu datu un dokumentu plūsmu
 Datu objekti var parādīt aktivitāšu ieejas un izejas
 Datu objektam var definēt stāvokli, kas procesa gaitā mainās

BPMN nodalījumi
 Pūli:
 satur tikai vienu procesu
 vairākus pūlus izmanto B2B, B2C procesos
 Lanes:
 veids kā organizēt aktivitātes (pēc izpildītāja, nodaļas, amata, utt.)
 var būt organizācijas nodaļa, loma, konkrēts darbinieks

BPMN piemērs

Activities
Gateway
s
Sequence Flow
defines the execution order
of activities.
Conditional Flow
has a condition assigned
that defines whether or
not the flow is used.
Default Flow
is the default branch to be
chosen if all other
conditions evaluate to
false.
Send Task
Receive Task
User Task
Manual Task
Business Rule Task
Service Task
Script Task
Sub-Process Marker
Loop Marker
Parallel MI Marker
Sequential MI Marker
~ Ad Hoc Marker
Compensation Marker
Inclusive Gateway
When splitting, one or more branches
are activated. All active incoming
branches must complete before
merging.
Complex Gateway
Complex merging and branching
behavior that is not captured by other
gateways.
Exclusive Event-based Gateway
(instantiate)
Each occurrence of a subsequent event
starts a new process instance.
Parallel Event-based Gateway
(instantiate)
The occurrence of all subsequent events
starts a new process instance.
Sub-Conversation
The order of message
exchanges can be
specified by combining
message flow and sequence
flow.
Pools (Participants) and Lanes
represent responsibilities for activities
in a process. A pool or a lane can be
an organization, a role, or a system.
Lanes subdivide pools or other lanes
hierarchically.
Task
Task
Message Flow
symbolizes information flow
across organizational
boundaries. Message flow can
be attached to pools, activities,
or message events.
Data
Task
Data Store
A Data Object represents information flowing
through the process, such as business
documents, e-mails, or letters.
A Data Store is a place where the process can
read or write data, e.g., a database or a filing
cabinet. It persists beyond the lifetime of the
process instance.
A Data Input is an external input for the
entire process. It can be read by an activity.
A Data Output is a variable available as result
of the entire process.
A Message is used to depict the contents of a
communication between two Participants.
A Collection Data Object represents a
collection of information, e.g., a list of order
items.
Pool (Collapsed)
Collaboration
Diagram
Conversations
Choreographies
Conversation
Diagram
Start Intermediate
Task
A Task is a unit of work, the job to be
performed. When marked with a symbol
it indicates a Sub-Process, an activity that can be refined.
Transaction
A Transaction is a set of activities that logically belong
together; it might follow a specified transaction protocol.
Event
Sub-Process
An Event Sub-Process is placed into a Process or Sub-
Process. It is activated when its start event gets triggered
and can interrupt the higher level process context or run in
parallel (non- interrupting) depending on the start event.
Call Activity
A Call Activity is a wrapper for a globally defined Sub-
Process or Task that is reused in the current process.
Task Types
Types specify the nature of the
action to be performed:
Activity Markers
Markers indicate execution
behavior of activities:
A Communication defines a set of logically
related message exchanges.
When marked with a symbol it
indicates a Sub-Conversation, a
compound conversation element.
A Forked Conversation Link connects
Communications and multiple Participants.
A Conversation Link connects
Communications and Participants.
Pool
(collapsed)
Multi Instance Pool
(collapsed)
Communication
Pool
(collapsed)
Participant B
Choreography
Diagram
A Choreography Task
represents an Interaction
(Message Exchange) between
two Participants.
Choreography
Task
Participant A
Participant B
A Choreography Sub-
Process contains a refined
choreography with several
Interactions.
Multiple Participants Marker
denotes a set of Participants of the
same kind.
Swimlane
s
BPMN 2.0 - Business Process Model and Notation
Collection
Ad-hoc Sub-Process
Task
Task
~
Messag
Start Event
Message Flow
Data Object
Collapsed
Sub-Process
Event-based
Gateway
Escalation
End Event
Timer
Intermediate
Event
Receive Task
Attached
Intermediate
Timer Event
Link
Intermediate
Event
Manual Task
End
Event
Link
Intermedi
Event
Text Annotation
Group
Multi Instance
Task (Parallel)
Message
End Event
Send Task
Parallel
Gateway
Exclusive
Gateway
Attached
Intermediate
Error Event
Signal
End
Event
Call Activity
Sub-Process
Event Sub-Process
Conditional
Start Event
Error End
Event
Start
Event
End
Event
Looped
Sub-Process
condition
http://bpmb.de/poster
Participant A
Participant C
Participant B
Choreography
Task
Participant A
Participant B
Choreography
Task
Participant C
Participant A
Initiating
Message
Response
Message
Choreography
Task
Participant B
Participant A
When splitting, it routes the sequence flow to exactly one of the
outgoing branches. When merging, it awaits one incoming branch to
complete before triggering the outgoing flow.
Exclusive Gateway
Is always followed by catching events or receive tasks. Sequence
flow is routed to the subsequent event/task which happens first.
Event-based Gateway
When used to split the sequence flow, all outgoing branches are
activated simultaneously. When merging parallel branches it waits
for all incoming branches to complete before triggering the
outgoing flow.
Parallel Gateway
Choreography
Sub-Process
Participant A
Participant C
Participant B
Input Out-
put
e
Data
Store
Parall
el
ate
Multip
le
Inter
medi
ate
Event

BPMN labā prakse
 Jāizdala procesa normālā plūsma un izņēmuma plūsma
 Katram iespējamam procesa beigu stāvoklim atsevišķs beigu elements
 Ārējo procesa iniciatoru modelēt kā «melnās kastes» pūlu
 Nosaukt aktivitātes NENOTEIKSME+LIETVĀRDS
 ieejā jābūt ziņojuma plūsmai no ārējā pūla
 Datu objektam kvadrātiekavās norādīt stāvokli
 Pievienot nosaukumus notikumiem, vārtejām
 Ja procesu inicializē ziņojums no ārējā dalībnieka, procesu vēlams beigt ar ziņojuma
nosūtīšanu šim dalībniekam (statuss par izpildi)
 BPMN aktivitāte nav funkcija vai stāvoklis – tas ir darbs, kas ir jāizdara procesā
 Hierarhiska modelēšana
 Organizācijā vēlams ieviest standartus:
 kā veidot modeļu versijas
 kā saukt elementus
 kādus elementus izmanto analītiķi un biznesa pārstāvji
115

Gints turlajs prezentācija RSU 5 sept

Recommended

Recommended

More Related Content

Similar to Gints turlajs prezentācija RSU 5 sept

Similar to Gints turlajs prezentācija RSU 5 sept (20)

More from Gints Turlajs

More from Gints Turlajs (20)

Recently uploaded

Recently uploaded (20)

Gints turlajs prezentācija RSU 5 sept