Transcript APT_Java

Modernās Programmēšanas Tehnoloģijas
(Advanced Programming Technologies)
Edgars Celms, Mārtiņš Opmanis
([email protected])
Latvijas Universitātes
Matemātikas un informātikas institūts
2007, Rīga, Latvija
UML (Unified Modeling Language)

Nedaudz vēstures




J. Rumbaugh – Object modeling Technique (OMT), 1991
J. Rumbaugh, G. Booch, I. Jacobson – Unified Modeling Language
(UML), 1995 – 1998, Rational Software
UML 1.1 – 1.3, Rational Software & OMG, 1998 – 2000
Pašlaik standartizē un attīsta OMG




UML 1.4 – 2001.09 (stereotypes & extension mechanisms extended),
UML 1.5 – 2003.03 (action semantics added) – current version
UML 2.0 – August 2005 (final version of UML Superstructure, formal-05-0704) (initial submissions – end 2001, delay against initial schedule – plan Nov
2004, ~200 issues open), MOF Core - formal-06-01-01, OCL and
Infrastructure still as ptc (temporary)
UML 2.1 – first ptc release 06-01-02 (Superstructure), ~300 open issues
UML (Unified Modeling Language)

"The Unified Modeling Language (UML) is a graphical language for
visualizing, specifying, constructing, and documenting the artifacts of a
software-intensive system" Grady Booch et al, Rational

"The Unified Modeling Language (UML) has become the universallyaccepted language for software design blueprints" Philippe Kruchten,
Rational

UML is a graphic modeling language based on things, relationships and
diagrams, with a strictly defined semantics.
Things in UML: class, use case, component, interaction, state,
transition, package, stereotype
Relationships in UML: association, generalization, dependency,
realization


UML (Unified Modeling Language)

UML Diagram types (UML 2.0):









class diagram (subkinds: object diagram, package diagram)
use case diagram
communication (prev. collaboration) diagram
sequence diagram (subkinds: Interaction Overview Diagram, Timing
diagram)
statechart diagram
activity diagram
composite structure diagram
component diagram
deployment diagram
UML loma objektorientētā programmatūras inženierijā




Pamatā iteratīva pieeja – programmatūras izstrādi veic iterācijās, ar katru iterāciju (principā pilnu
izstrādes ciklu) papildinot un uzlabojot rezultātu. To var tāpēc, ka OO izstrāde nodrošina ātrāku
gala rezultātu, ko var relatīvi viegli papildināt
Visās izstrādes fāzēs izmanto UML – UML modeļu virkni, ko izstrādā tāpat kā programmas kodu
un uztur sinhronu ar kodu. UML diagrammas šajā pieejā tiek saistītas ar labi strukturētiem teksta
dokumentiem, kas kopumā viegli ļauj izprast būvējamo sistēmu.
Modeļa ietvaros diagrammas saistās viena ar otru. Katrā no fāzēm visnoderīgākais ir savs
diagrammas tips, dažus tipus izmanto daudzos modeļos (piem., klašu diagrammas)
Jauna pieeja - MDA (Model Driven Architecture, Modeļbāzētā Arhitektūra), vai MDD (Model
Driven Development, Modeļbāzētā izstrāde) – UML modeļu formalizēta lietošana projektēšanā,
modeļus starp soļiem pārveidojot daļēji automātiski (kur tas ir iespējams)
PIM
CIM
Conceptual model
(for understanding)
Business
model
Requirements
specification
Analysis model
1..*
1..*
1..*
Class
diagram
(informal)
Business Use
Case diagram
Use Case
diagram
1..*
Activity
1..*
1..*
Class
diagram
(analysis)
Desi
1..*
*
Use Case
diagram
(system)
Use Case
diagram
(realization)
1..*
Class
diagram
Projektēšanas klašu diagrammas






Projektēšanas klašu diagrammas paredzētas kādas OO valodas koda
ģenerēšanai un dokumentēšanai (round trip engineering or synchronyzing).
Sakarā ar lietošanu koda ģenerācijai projektēšanas klašu diagrammām ir
daudzas papildus, specifiskas prasības, salīdzinot ar cita veida klašu
diagrammām
No vienas puses, klašu diagrammā jāvar dokumentēt visi projektēšanas
lēmumi, kas attiecas uz klašu struktūru. Tāpēc UML klašu diagrammās ir
daudz dažādu iespēju, kas visas jāprot izmantot.
No otras puses, saskaņā ar Model Driven Architecture (MDA) ideju,
projektēšanas klašu diagramma nevar saturēt tieši mērķa valodas –
piemēram, Java elementus (vismaz PIM modelim). Nav jēgas tieši Java
līmenī “programmēt” klašu diagrammā.
Semantikai jābūt izskaidrojamai UML līmenī.
Šis kompromiss šobrīd vēl nav labi sasniegts, atkarīgs no rīka.
Galvenie klašu diagrammas elementi projektēšanas solim
no UML viedokļa


UML klase atbilst programmas klasei (Java, C++, utt.)
Klases simbolā ir:



vārds (bez tukšumiem vidū)
neobligāts stereotips – predefinēts vai lietotāja definēts (speciālos
stereotipus sk. tālāk)
neobligātas papildus pazīmes isAbstract, isLeaf (final). Tās
attiecas uz vispārināšanu. isAbstract nozīmē ka klasei nebūs
eksemplāru (tikai tās apakšklasēm), isLeaf – ka tai nevar būt
apakšklases. Praktiski svarīgākā ir isAbstract , un vienīgi to parasti
arī rāda grafiski – klases vārds kursīvā.
Employee
- emp_id : Integer
- firstName : String
- lastName : String
- position : PositionDef
- from : Date
<<boundary>>
Sale1
-date:Date
-time:Time
-isComplete:boolean
Employee1
- emp_id : Integer
- firstName : String
- lastName : String
- position : PositionDef
- from : Date
Projektēšanas klašu diagrammu elementi - atribūti

Projektēšanas klašu diagrammās atribūtiem ir jāsatur

redzamība (public +, protected #, private -, package ~), noklusētā – private
visiem
XDE, Together – tikai standartapzīmējumi
Rose grafiskās ikonas,
RSA iespējami abi varianti

atribūtu vārdiem jābūt unikāliem – ieskaitot virsklašu atribūtus (bet drīkst pārdefinēt)




Papildpazīmes lieto reti, zināma vērtība Static un Ordered
No papildpazīmēm vienīgi Scope=class (isStatic = true) rāda grafiski – atribūta vārds
pasvītrots. Tas nozīmē, ka šī atribūta vērtība kopīga visiem klases eksemplāriem.
Employee1
- emp_id : Integer
+ firstName : String
- lastName : String
# position : PositionDef
- from : Date

pakotnē



klasē
vārds (vēlams sākt ar mazo burtu)
atribūta tips – atbilstoši UML, izvēlētajai OO valodai vai bibliotēkai. Tips var būt arī cita klase ("lietotāja tips").
Var lietot pārskaitāmos tipus (jādefinē!)
neobligāti – sākuma vērtība atbilstoši tipam
neobligāti – kardinalitāte (RSA un Visio atbalsta, bet Rose un Together nē, var būt arī 5..5), derived( / )
neobligāti – darbības apgabals (scope (1.4)) – instance (parastais variants) vai klase (=static) (isStatic
īpašība)
neobligāti - vai vērtības sakārtotas (isOrdered) un vai atšķirīgas (isUnique), ja multiplicitāte >1
neobligāti - vai atribūts ir maināms (isReadOnly)


apakšklasēm
Employee1
- emp_id : Integer
+ firstName : String
- lastName : String
# position : PositionDef
- lastReview : Date
Ja tips ir klase, tad tas nozīmē, ka atribūta vērtība ir citas klases eksemplārs, kas iekļauts dotajā
klasē. Sk. tālāk par asociāciju uz citu klasi.
Projektēšanas klašu diagrammu elementi - operācijas

Projektēšanas klašu diagrammās operācijām ir jāsatur

redzamība (public +, protected #, private -, package ~) noklusētā – public
(RSA ikonas)









vārds
operācijas tips (atgriežamā vērtība) atbilstoši UML, izvēlētajai OO valodai vai bibliotēkai. Tips
var būt arī cita klase, vai nebūt nemaz – vērtību neatgriež.
operācijas parametri (neobligāti)
katram parametram veids (in (noklusētais), out, inout), vārds, tips, noklusētā vērtība
neobligāti – operācijas darbības apgabals (scope) – instance (parastais variants) vai klase
(=static) = isStatic (ROSE, XDE nav)
neobligāti – pazīme abstract, ka dotā klase nerealizē šo operāciju (bet kāda apakšklase
gan)
neobligāti – pazīme query, ka operācija izpildes laikā nemodificē datus
operāciju vārdiem jābūt unikāliem – ieskaitot virsklašu operācijas
virsklases operācijas var arī pārdefinēt (sīkāk vēlāk)
ProjectManagement1
Project1
- pr_id : Integer
- name : String
- priority : Integer
- state : ProjState
- startDate : Date
- endDate : Date
+ getFormReqSkills()
+ getProjectsByProjMan(pm_id : Integer) : List
+ getProjectById(pr_id : Integer) : Project
Projektēšanas klašu diagrammu elementi - asociācijas

Asociācija satur šādus elementus



Galvenā informācija asociācijas galā







vārds – neobligāts no projektēšanas viedokļa
asociācijas klases piesaiste
lomas vārds – obligāts navigējamā galā (nenavigējamā galā var nebūt), vārdu liek kā
atribūtam
redzamība – kā atribūtam
kardinalitāte – obligāta navigējamā galā, var būt gan 0..1, 1, *, gan arī konkrētas vērtības – 5
navigējamība – ja ir (isNavigable), tad noteikti jāuzrāda, tā noteiks gala lomu koda
definēšanā
neobligāta pazīme ordered – jēga pie kardinalitātes >1 un Unique
citas pazīmes kā atribūtam
Navigējama asociācija uz class pretējā galā tas pats kas atribūts ar tipu class.

Tāpēc lomu vārdiem jābūt atšķirīgiem no otra gala klases atribūtu vārdiem.
redzamība
Class1
-attribute4:i nt
#attribute2:int
attribute3:int
+attribute1:int
Class2
0..1
roleCl1
-attributeCl 1:int
-attributcl21:Action
Projektēšanas klašu diagrammu elementi - asociācijas

Agregācija un kompozīcija




Agregācijai tikai skaidrojoša nozīme no programmatūras viedokļa.
Kompozīcija tiešām izsaka faktu, ka klase ir otras “daļa”, nevar pastāvēt
neatkarīgi.
Iznīcinot galveno klasi, jāiznīkst pakļautajai klasei.
Kompozīciju ir svarīgi attēlot modelī (klašu diagrammā)
Journey
Agreement
Project
- pr_id : Integer
- name : String
- priority : Integer
- state : ProjState
- startDate : Date
- endDate : Date
-agreement
+addJourney(in journeyID : string, in startDate : Date)
+getJourney(in journeyId : string) : Journey
+setMode(in mode : string)
+ getFormReqSkills() : List
+project
1
1..*
+reqSkill
RequiredSkill
- count : Integer
- level : SLevel
- filled : Integer
+ getSkillItem() : FormattedSkillItem
1
-journey
*
-outStartTime
-outArrivalTime
-backStartTime
-backArrivalTime
Projektēšanas klašu diagrammu elementi - vispārināšana

Vispārināšana





Vispārināšana izsauc virsklases atribūtu un operāciju mantošanu.
Tieša interpretācija OOP.
Var pārdefinēt gan operācijas, gan atribūtus.
Atribūtus pārdefinē reti, bet operāciju pārdefinēšana svarīga – realizē
polimorfismu.
Vienkāršā vai daudzkāršā mantošana – atkarīgs no mērķa vides, UML
pieļauj visādi
CarUser
Employee
- emp_id : Integer
- firstName : String
- lastName : String
- position : PositionDef
- from : Date
-name : string
#region : string
-carType : string
-cars : int = 1
-mainCar : Car
CarSharer
ProjectManager
- userId : String
- password : String
-firstName
-lastName
Projektēšanas klašu diagrammu elementi

Atkarība (dependency)

Izsaka, ka informācija no vienas klases jāizmanto otrai, veidā , ko grūti sīkāk precizēt. Var būt
visādi paveidi : <<instantiate>>, <<bind>>, <<refine>>, <<import>> utt.
Journey
-outStartTime
-outArrivalTime
-backStartTime
-backArrivalTime

GeoLocation
-gpsLocation
Interfeisi (saskarnes) – interfaces

Interfeisus lieto pie strukturēšanas – lai kopīgas operācijas "iznestu ārpusē" (un realizētu
dziļāk)
Klases realizē
(implementē) interfeisu

Templates – "šablonklases"

Lietojot, parametriem piesaista konkrētas vērtības (šeit saraksta elementa tipu) – binding
Elem
List
Atbilstība starp UML klašu notāciju un Javas kodu RSA rīkā
(klases un operācijas)
UML
Java
Package
Java package with the same name*
Class
Java class with the same name* and visibility
(Class) isLeaf property
Java class is "final" if true
(Class) isAbstract property
Java class is "abstract" if true
(Class) Generalization
Java class "extends" the specified superclass
Implementation
Java class "implements" the specfied interface
(Class to Interface) Realization
Java class "implements" the specfied interface
Interface
Java interface with the same name* and visibility
(Interface) Generalization
Java interface "extends" the specified interface
Enumeration
Java interface with the same name* and visibility
EnumerationLiteral
Java field with the same name* and visibility
Operation
Java method with the same name* and visibility
(Operation) isStatic property
Java method is "static" if true
(Operation) isAbstract property
Java method is "abstract" if true
(Operation) isLeaf property
Java method is "final" if true
(Operation) with same name as its class
Java constructor
(Operation) stereotyped <<create>>
Java constructor
Atbilstība starp UML klašu notāciju un Javas kodu RSA rīkā
(parametri un atribūti)
Parameter
Java parameter with the same name*
(Parameter) Type property
Java parameter has the specified type, which can be
another class or a primitive type
(Parameter) Direction property
Java method has "return <param type>" if set to
"return"; otherwise, adds "<param type> <param
name>" to the method signature
(Parameter) Multiplicity property
See the following table that contains information about
multiplicity
Property
Java field with the same name* and visibility
(Property) isStatic property
Java field is "static" if true
(Property) isLeaf property
Java field is "final" if true
(Property) Type property
Java field has the specified type, which can be another
class or a primitive type
(Property) Multiplicity property
See the following table that contains information about
multiplicity
Atribūtu, asociāciju un parametru atbilstība – ņemot vērā to
kardinalitātes
Java types for properties and parameters
UML multiplicity
Generated Java type
0..1
Attribute, pointer, or reference (for example, String)
1
Attribute (for example, String)
N (N > 1)
Array (for example, String[])
1..*, *, or x..y
Collection, see the following table
Java collections for 1..*, * or x..y multiplicities
isOrdered Property
isUnique Property UML Collection Generated Java Type
True
True
Ordered Set
java.util.SortedSet
True
False
Sequence
java.util.List
False
True
Set
java.util.Set
False
False
Bag
java.util.Collection

Attēlojums kopumā dabīgs…
PSM RSA 1
PSM model for RSA - version 2 with Enums converted to special classes
PSM RSA 1
No šāda modeļa RSA rīkā var
noģenerēt Java bez kļūdām
UML to Java – koda atbilstības piemērs
import java.util.List;
public class Project {
private Integer pr_id;
private String name;
private Integer priority;
private ProjState state;
private Date startDate;
private Date endDate;
private List skillItList;
private List reqskill;
private RequiredSkill rs;
private FormattedSkillItem si;
public void updateReqSkill(RequiredSkill currSkill) {
}
public List getFormReqSkills() {
return null;
}
}
UML to Java – koda atbilstības piemērs
...
public interface Payable { … }
...
public class Invoice implements Payable { … }
...
public abstract class EmployeeAbstr implements Payable { … }
...
public class SalariedEmployee extends EmployeeAbstr { … }
...
UML diagrammas un to lietojums OO programmatūras
izstrādē

“UML lietošana programmatūras izstrādē” (Use of UML for software
development) – A.Kalniņš, E.Celms

LU Datorzinātņu maģistra programmas otrā semestra četru kredītpunktu kurss
Jautājumi ?