190 likes | 314 Views
UML and WSDL for JISC e-Learning Projects UML – ADDITIONAL FEATURES Richard Hopkins rph@nesc.ac.uk NeSC Training Team Member. Goals and Overview. Goals – To enable you to appreciate more of UML To introduce some features that you might find useful Overview Sequence Diagrams & Statecharts
E N D
UML and WSDL for JISC e-Learning ProjectsUML – ADDITIONAL FEATURESRichard Hopkins rph@nesc.ac.ukNeSC Training Team Member
Goals and Overview • Goals – • To enable you to appreciate more of UML • To introduce some features that you might find useful • Overview • Sequence Diagrams & Statecharts • General Features - Extensibility • Class Diagrams
Conditions in Sequence Diags. • Have different objects for cataloguing books and journal • Journals and softback books are registered • Hardback books are catalogued Librarian BC :BookCatalogue JC :JournalCatalogue register(it) [Journal] catalogue(it) [hardBack] register(it) [softBack]
Statecharts Statecharts – • Self Transitions • Actions • Alternatives Action on transition – Action1 / Action2 / … [ isSpoilt ] / notifyAbuse() In Bindery Statechart For Copy Class On Loan Return() On Shelf [ not isSpoilt ] StatusCheck() Alternatives – decision diamond guards As in activity diag. (flowchart) Self-transition
Statecharts – entry / exit actions Attribute book:Book Invoke its isAvail operation • entry / done whenever enter state • exit / done whenever exit state • Clearer and less words Borrow() / book . isAvail(self) On Loan Statechart For Copy Class On Shelf Borrow() / book . notAvail(self) In Bindery Rebind() / book . notAvail(self) Borrow() On Loan On Shelf Borrow() entry / book . isAvail(self) exit / book . notAvail(self) In Bindery Rebind()
Sequence Diagrams & Statecharts • Overview • Sequence Diagrams & Statecharts • General Features - Extensibility • Class Diagrams
Stereotypes • Adding extra classification to model elements • Pre-defined • Model-specific • Already seen some stereotypes Return Overdue Copy Use Case Diag. Pre-defined <<extend>> <<include>> Defer fine Pay fine Deployment Diag. Model-specific <<Internet>> <<LAN>> Univ:Server Clerk’s:PC User’s:PC • <<stereotype name>> - written “near” the element • Can use for any element – icon, line, operation, … • Can define a new icon for a particular stereotype – • Developing specialised language
Properties Book • A model element can have a value for a property – {isQuery = true} • Boolean property values can be written {X} rather than {X = true} • A way of recording design information • Tagged value • Just as a class has an attribute, and object has value for it • So, element type has property, and instance has property value • UML itself is a UML-expressible model Title : String {author = Richard, reviewer = David} {isQuery = true} copiesOnShelf() : Integer {isQuery} getISBN() : ISBN
Stereotype vs Property Class Diag. Class Diag. • How significant is the characteristic? • Very Significant (to user) -> use stereotype • Being a web service - • Which layer (since lower layers can’t use higher ones) • Relatively incidental -> use property • Which language used in implementation <<UserAgentLayer>> <<InJava>> <<WebService>> LibraryService {layer=UserAgents, language = Java, AWebService} LibraryService Vs. <<ComonServiceLayer>> <<InC++>> <<WebService>> AuthenticationService {layer=CommonService, language = C++, AWebService} AuthenticationService
Class Diagrams • Overview • Sequence Diagrams & Statecharts • General Features – Extensibility • Class Diagrams • Specialised Class vs Attribute • Interfaces • Parameterised Classes • Constraints • Association Class
Specialised Class vs Attribute • Stereotype vs Property • Like difference between specialised class or attribute of general class Vs. Book Book hardBack: bool HardBackBook SoftBackBook • Use specialised class if a significant difference to user, • e.g. hardBack has a reBind operation, but softBack doesn’t
Interfaces • Same concepts as in Java • A collection of operations • which must be supported by any class claiming to support the interface (“match” the interface; “realise” the interface) “supports” is shown as specialisation with dashed arrow • An interface is like a class but has no instances – no attributes, no associations Item Is part of contains Article printOffColour() printOffB&W … Journal <<interface>> Copyable Book printOffColour() printOffB&W Leaflet printOffColour() printOffB&W … Redundant – don’t need both
<<interface>> Copyable printOffColour() printOffB&W Interfaces • Lollipop dependency asserts that copyService is only dependent on the Copyable interface of the associated objects • Other things can have “Supports interface” lollipop – use-cases, components CopyService Supports interface lollipop Copyable Copyable (Design) Dependency Leaflet Article Association ( instances can knows about)
Parameterised Classes Alternatively - • The parameterised class is not really a class • A function from classes to a class • Sometimes called a template • Used to avoid duplication, can be easier to read • The parameter (T) is almost always used in the templates attributes and operations – • It is use of class variable in this way which is the point • Otherwise, could make IndexedList an interface supported by both T T IndexedList IndexedList add(t : T, pos: int) get(pos : int) : T add(t : T, pos: int) get(pos : int) : T IndexeddList<Book> <<bind>>(Citation) <<bind>>(Book) References BookLIst IndexedList<Citation>
Parameterised Classes T BIoSystem • X is a particular kind of Biosystem having Y as its constituents <<bind>>(Null) (Cell) (Organism) (Populaton) (EcoSystem) Null Cell Organism Population EcoSystem BioRegion 1..* BioComponent Cell Organism Population EcoSystem BioRegion • A BioRegion comprises a collection of EcoSystems, comprises a collection of Populations, comprises …. • Which is a better model ?
Association Classes • To model there being some information and/or operations for an association between two classes • Could be done using an ordinary class takes Student Module 0..* 6 IsTaking Mark : int takes Student Module Student Module 0..* 6 0..* 6 1 1 1 1 Or - 0..* 0..* 6 6 Mark Mark Mark : int Mark : int • Less clear • Would have to implement it in one of these ways
Constraints • A constraint is a condition that must be satisfied by any correct implementation. • These are class invariants • Can put constraints on other diagram types • Can be done in natural language or formally in – • Object constraint language (OCL) • Greater precision • Harder to understand Book Journal 6 0..* 1 1 Pre-defined constrain type – can’t be both a copy of a book and a copy of journal {xor} 1..* 1..* Copy {braille implies aisle = 6} largePrint: bool braille : bool aisle : int shelf : int Define constraints within an element or between elements
Object Constraint Language Manager Worker must contact His/her manger via PA, If there is one • Syntax – approximate, see http://www.omg.org/technology/documents/formal/uml.htm Chapt 6 • Other contexts – • Operation: pre and post conditions • State diag., activity diag, sequence diag -Guards hasPA : Bool phone:PhoneNo 1 {IF self . lineM . hasPA = True THEN lineMphone = self . lineM . myPA . Phone ELSE lineMphone = self . lineM . phone} myPA 0..1 Worker Administrator phone : PhoneNo lineM : Manager lineMphone : PhoneNo