190 likes | 321 Vues
This document presents an overview of UML (Unified Modeling Language) and WSDL (Web Services Description Language) as applied to JISC e-Learning projects. It aims to enhance understanding of UML features such as Sequence Diagrams, Statecharts, and Class Diagrams, introducing various extensions and classification methods. Key topics include handling different objects in cataloging, utilizing state transitions for book loans, and defining properties and stereotypes for modeling elements. This resource is invaluable for developers and educators involved in e-learning initiatives.
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