UML Components
John Daniels Syntropy Limited [email protected]
© Syntropy Limited 2001 All rights reserved Agenda
• Aspects of a component • A process for component specification • Implications for the UML
email:[email protected] Syntropy Limited Aspects of a component
email:[email protected] Syntropy Limited UML
Unified Modeling Language • The UML is a standardised language for describing the structure and behaviour of things • UML emerged from the world of object- oriented programming • UML has a set of notations, mostly graphical • There are tools that support some parts of the UML
email:[email protected] Syntropy Limited Aspects of an Object
! Specification unit
1..* Interface
! Implementation unit * realization Class 0..1 Class Implementation source 1 1
instance * Object
! Execution unit email:[email protected] Syntropy Limited Components in context
ObjectObject Evolving PrinciplesPrinciples
developed within adopted by
adopted by 1989- 1967- RMI 1995- Smalltalk EJB DistributedDistributed Object-orientedObject-oriented ObjectObject ComponentsComponents Programming DCOM Programming TechnologyTechnology C++ Java CORBA COM+/.NET
Only interoperable Typically language neutral. A way of packaging within the language. Multiple address spaces. object implementations Single address space Non-integrated services to ease their use. Integrated services email:[email protected] Syntropy Limited Component standard features
• Component Model: – defined set of services that support the software – set of rules that must be obeyed in order to take advantage of the services • Simple programming model, no need to design/know about the infrastructure • Services include: – remote access, transactions, persistent storage, security – typically use services by configuring not programming
email:[email protected] Syntropy Limited Aspects of a component
! It has a specification spec ! It has an implementation for (int i=0; i ! It conforms to a standard Enterprise Component ! It can be Standard packaged into modules email:[email protected] Syntropy Limited Component forms 1..* Interface * realization 0..1 Class Class Implementation source 1 ! Specification unit 1 instance * Component 1..* Object Interface Specification * spec 1 ! Implementation unit * realization Component 0..1 Component Implementation source 1 1..* 1 1..* file Component Module instance * Component ! Packaging unit Object ! Execution unit email:[email protected] Syntropy Limited Two distinct contracts Usage contract: a contract between a component object’s interface and a client Interface Client Component < < Interface email:[email protected] Syntropy Limited Interface specification We could specify placeOrder( ) IOrderMgt like this: placeOrder(custNum, prodNum, quan) “The number of orders for the numOfOrders(custNum): Integer customer is increased by one and a reserveStock message is sent to the component IProductMgt supporting the IProductMgt reserveStock(prodNum, quan) availableStock(prodNum): Integer interface” email:[email protected] Syntropy Limited Separation of specification concerns The client cares about this - it affects the subsequent result of numOfOrders( ). Therefore it is part of the usage contract “The number of orders for the customer is increased by one and a reserveStock message is sent to the component The IOrderMgt client does not care about supporting the IProductMgt this - but the implementer does. Therefore it is part of the realization interface” contract email:[email protected] Syntropy Limited Interfaces versus Component Specs Component Component Interface Specification • Represents the usage contract • Represents the realization • Provides a list of operations contract • Defines an underlying logical • Provides a list of supported information model specific to interfaces the interface • Defines the run-time unit • Specifies how operations • Defines the relationships affect or rely on the between the information models information model of different interfaces • Describes local effects only • Specifies how operations should be implemented in terms of usage of other interfaces email:[email protected] Syntropy Limited Contracts and roles Specifier (Architect) A person who produces the technical specification for a system or components within a system The Usage Contract The Realization Contract Client Realizer A person who writes A person who builds a software that uses a component that meets a component component specification email:[email protected] Syntropy Limited Component deployment Component 1..* 1..* Component 1 file Module 1 installed as copy * * Installed Installed 1..* 1..* Component server Module ! Registration unit ! Installation unit email:[email protected] Syntropy Limited Example - Microsoft Word wordDocument: Component wordApplication: Component file file winword.exe: installed as ComponentModule installed as wordDocument: InstalledComponent copy wordApplication: C:/../winword.exe: InstalledComponent server InstalledModule server instance instance applicationObject: docObject: ComponentObject File / New ComponentObject email:[email protected] Syntropy Limited Example - Enterprise Java Beans invoice: c:/../invoice.java: ComponentSpec realization ComponentImplementation invoiceBean: Component file installed as invoice.jar: ComponentModule copy invoiceBean: server c:/../invoice.jar: InstalledComponent InstalledModule instance invoiceABC: ComponentObject email:[email protected] Syntropy Limited A process for component specification email:[email protected] Syntropy Limited Application Architecture Layers Presentation Web Client HTTP Client Web Server RMI / IIOP / DCOM RMI / IIOP / DCOM Service Application Server Existing Any System (server) JDBC / ODBC / SQL Data Database Server email:[email protected] Syntropy Limited Application Blueprint Web Server A/JSP Application Server Component Object Component Object Component Object Component Object Component Object Existing Database System email:[email protected] Syntropy Limited Finer-Grain Application Layers Presentation UI Logic What the user sees User Interface Dialog Logic (UseCases) User Dialog Supports multiple UIs Transient Dialog State Service Business transactions System Services Allows multiple Dialogs (including Batch) Business Integrity State Business Services Sub-transactions Business Instance State Data email:[email protected] Syntropy Limited Management and Development Processes • Management Processes – Schedule work and plan deliveries – Allocate resources 0%% complete 100% Concept model – Monitor progress Use Case model Component specs – Control risk Components • Development Processes – Create working software from requirements – Focus on software development artifacts – Described independently of the management process – Defines ordering constraints and dependencies – Organized into Workflows Use Case models Specification Component specs & architectures Business Concept Workflow models email:[email protected] Syntropy Limited Workflows in the development process Business requirements Existing Artefact assets Requirements Business Concept User models interface Technical Components constraints Use Case Specification Provisioning Assembly models Component specs Assemblies & architectures Test Tested Workflow (c.f. RUP) assemblies Deployment email:[email protected] Syntropy Limited The Requirements Workflow Problem domain Business knowledge requirements Requirements Workflow Develop Business Develop business Concept Model processes Software boundary Identify Use Cases decisions Business Use Cases Concept Model email:[email protected] Syntropy Limited Business process We want to provide some automated support for managing hotel reservations Take up reservation customer arrives/ Wait for event enquiry/ [else] cancel request/ Check amendment availability request/ Cancel [suitable reservation room] Make Amend no show/ reservation reservation Confirm Process no Notify billing reservation show system email:[email protected] Syntropy Limited Business Concept Model 1 Hotel Chain 1..* Clerk 1..* 1 Hotel * contactedHotel 1 1 * * 1..* allocation Customer Reservation Room 1 * * 0..1 1 1 * * contactAddress 0..1 1 Address RoomType 1 0..1 1 Bill Payment 0..1 email:[email protected] Syntropy Limited Identify Use Cases A use case describes the interaction that follows from a single business event. Where an event triggers a number of process Take up reservation steps, all the steps form a single use case. customer arrives/ Wait for event enquiry/ [else] cancel request/ Check amendment availability request/ Cancel [suitable reservation room] Make Amend no show/ reservation reservation Confirm Process no Notify billing reservation show system email:[email protected] Syntropy Limited Reservation system Cancel a reservation ReservationMaker Use Case Make a diagram reservation Update a Guest reservation Take up a reservation BillingSystem Process no shows Add, amend, remove hotel, room, ReservationAdministrator customer, etc. email:[email protected] Syntropy Limited Name Make a Reservation Initiator Reservation Maker Goal Reserve a room at a hotel Steps Main success scenario or 1. Reservation Maker asks to make a reservation Extension 2. Reservation Maker selects hotel, dates and room type Points 3. System provides availability and price 4. Reservation Maker agrees to proceed 5. Reservation Maker provides name and postcode 6. Reservation Maker provides contact email address 7. System makes reservation and gives it a tag 8. System reveals tag to Reservation Maker 9. System creates and sends confirmation by email Alternatives Extensions Use an informal “Alternatives” 3. Room Not Available section if you don’t a) System offers alternative dates and room types want to specify the b) Reservation Maker selects from alternatives detail required for an extension 6. Customer already on file email:[email protected] a) Resume 7 Syntropy Limited The Specification Workflow Requirements Specification Component Identification Component Interaction Component Specification Provisioning email:[email protected] Syntropy Limited Components in the service layers System interfaces Presentation operations support use case steps Service System Services System System Component Component Business Services Business Business Component Component Data Business interfaces operations support core business logic email:[email protected] Syntropy Limited Component Identification Business Concept Use Case Model Model Component Develop Business Identification Type Model Existing Interfaces Identify Business Identify System Interfaces Interfaces & Ops Existing Architecture Assets Create Initial Patterns Comp Specs & Architecture Business Business Component System Type Model Interfaces Specs & Interfaces Architecture email:[email protected] Syntropy Limited Identify System Interfaces and operations System interfaces act as facades - they are the point of contact for the UI and other external agents. They are supported by components in the system services layer. Start with one interface per use case, then refactor as necessary. Make a Make Use case Dialog Reservation Reservation logic 2. Reservation Maker selects Use < Return a list of hotels and the room types they have < email:[email protected] Syntropy Limited Develop the Business Type Model 1 Hotel Chain 1..* Clerk 1..* 1 " Hotel * " contactedHotel 1 1 "* * 1..* allocation Customer Reservation Room 1 * * 0..1 1 1 * * contactAddress 0..1 1 Address RoomType 1 0..1 " 1 Bill Payment 0..1 " email:[email protected]" Syntropy Limited Initial Business Type Diagram < Business Business Concept Model < • Core types represent the primary business information that the system must manage • Each core type will correspond directly to a business interface • A core type has: – a business identifier, usually independent of other identifiers – independent existence – no mandatory associations (multiplicity equal to 1), except to a categorizing type • In our case study: – Customer YES. Has id (name) and no mandatory assocs. – Hotel YES. Has id (name) and no mandatory assocs. – Reservation NO. Has mandatory assocs. – Room NO. Has mandatory assoc to Hotel – RoomType NO. Has mandatory assoc to Hotel email:[email protected] Syntropy Limited Identify business interfaces < Responsibility for holding < • We need to decide what components we want, and which interfaces they will support • These are fundamental architectural decisions • Business components: – they support the business interfaces – remember: components define the unit of development and deployment • The starting assumption is one component spec per business interface ICustomerMgt < email:[email protected] Syntropy Limited System components • We will define a single system component spec that supports all the use case system interfaces – Alternatives: one component per use case, support system interfaces on the business components • Use a separate component spec for billing system wrapper < IBilling ICustomerMgt < < < < < < < < < Business System Component Specs Interfaces Interfaces & Architecture Component Discover Business Interaction Operations Refine Refine Interfaces & Ops Component Specs & Architecture Component Specs Interfaces & Architecture email:[email protected] Syntropy Limited Operation discovery • Uses interaction diagrams (collaboration diagrams) • The purpose is to discover operations on business interfaces that must be specified – not all operations will be discovered or specified • Take each use case step operation in turn: – decide how the component offering it should interact with components offering the business interfaces – draw one or more collaboration diagram per operation – define signatures for all operations email:[email protected] Syntropy Limited getHotelDetails( ) /IMakeReservation:ReservationSystem 1:getHotelDetails( ) /IHotelMgt < getHotelDetails (in match: String): HotelDetails [ ] < getHotelDetails (in match: String): HotelDetails [ ] email:[email protected] Syntropy Limited /ICustomerMgt /IHotelMgt makeReservation ( ) 1:getCustomerMatching( ) 3:notifyCustomer( ) 2:makeReservation( ) <> CustomerDetails /IMakeReservation:ReservationSystem name: String postCode[0..1]: String email[0..1]: String < getHotelDetails (in match: String): HotelDetails [ ] getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency) makeReservation (in res: ReservationDetails, in cus: CustomerDetails, out resRef: String): Integer < getHotelDetails (in match: String): HotelDetails [ ] getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency) makeReservation (in res: ReservationDetails, in cus: CustId, out resRef: String): Boolean email:[email protected] Syntropy Limited Component Specification Business Component Specs Type Model Interfaces & Architecture Component Define Interface Specification Information Models Specify Component- Specify Operation Interface constraints Pre/Post-Conditions Interfaces Component Specs & Architecture email:[email protected] Syntropy Limited Interface information model < getCustomerMatching (in custD: CustomerDetails, out cusId: CustId): Integer createCustomer(in custD: CustomerDetails, out cusId: CustId): Boolean getCustomerDetails (in cus: CustId): CustomerDetails notifyCustomer (in cus: CustId, in msg: String) * Defines the set of information assumed to be held by a Customer component object offering the interface, for the purposes of specification only. id: CustId name: String postCode: String Implementations do not have to hold this information email: String themselves, but they must be able to obtain it. The model need only be sufficient to explain the effects of the operations. The model can be derived from the Business Type Model. email:[email protected] Syntropy Limited Pre- and post-conditions • If the pre-condition is true, the post-condition must be true • If the pre-condition is false, the post-condition doesn’t apply • A missing pre-condition is assumed ‘true’ • Pre- and post-conditions can be written in natural language or in a formal language such as OCL context ICustomerMgt::getCustomerDetails (in cus: CustId): CustomerDetails pre: -- cus is valid customer->exists(c | c.id = cus) post: -- the details returned match those held for customer cus Let theCust = customer->select(c | c.id = cus) in result.name = theCust.name result.postCode = theCust.postCode result.email = theCust.email email:[email protected] Syntropy Limited < getHotelDetails (in match: String): HotelDetails [ ] getRoomInfo (in res: ReservationDetails, out availability: Boolean, out price: Currency) makeReservation (in res: ReservationDetails, in cus: CustId, out resRef: String): Boolean getReservation(in resRef: String, out rd ReservationDetails, out cusId: CustId): Boolean beginStay (resRef: String , out roomNumber: String): Boolean * * Reservation Hotel Room resRef: String id: HotelId number: String * dates: DateRange * name: String 1 * claimed: Boolean 1 1..* ** 0..1 allocation 1 Customer RoomType id: CustId name: String available(during: DateRange): Boolean 1 1 price(on: Date): Currency stayPrice(for: DateRange): Currency email:[email protected] Syntropy Limited :Hotel {id=4} before :RoomType :RoomType :Reservation {name=single} {name=double} {refRef=H51} :Customer after {id=38} :Hotel {id=4} :Reservation :RoomType :RoomType :Reservation {resRef=A77} {name=single} {name=double} {refRef=H51} :Customer :Customer {id=92} {id=38} makeReservation ( ) email:[email protected] Syntropy Limited context IHotelMgt::makeReservation ( in res: ReservationDetails, in cus: CustId, out resRef: String): Boolean pre: -- the hotel id and room type are valid hotel->exists(h | h.id = res.hotel and h.room.roomType.name->includes(res.roomType)) post: result implies -- a reservation was created -- identify the hotel Let h = hotel->select(x | x.id = res.hotel)->asSequence->first in -- only one more reservation now than before (h.reservation - h.reservation@pre)->size = 1 and -- identify the reservation Let r = (h.reservation - h.reservation@pre)->asSequence->first in -- return number is number of the new reservation r.resRef = resRef and -- other attributes match r.dates = res.dateRange and r.roomType.name = res.roomType and not r.claimed and r.customer.id = cus email:[email protected] Syntropy Limited Specifying a component (1) IMakeReservation < IBilling IHotelMgt ICustomerMgt Specification of interfaces offered and used (part of the realization contract) email:[email protected] Syntropy Limited Specifying a component (2) < < < Specification of the component object architecture. This tells us how many objects offering the used interfaces are involved email:[email protected] Syntropy Limited Specifying a component (3) Context ReservationSystem -- between offered interfaces IMakeReservation::hotel = ITakeUpReservation::hotel IMakeReservation::reservation = ITakeUpReservation:: reservation IMakeReservation::customer = ITakeUpReservation::customer -- between offered interfaces and used interfaces IMakeReservation::hotel = iHotelMgt.hotel IMakeReservation::reservation = iHotelMgt.reservation IMakeReservation::customer = iCustomerMgt.customer Specification of the Component Spec-Interface constraints. The top set of constraints tell the realizer the required relationships between elements of different offered interfaces. The bottom set tell the realizer the relationships between elements of offered interfaces and used interfaces that must be maintained. email:[email protected] Syntropy Limited Interactions as specification? getHotelDetails( ) /IMakeReservation:ReservationSystem 1:getHotelDetails( ) /IHotelMgt • Is every implementation of ReservationSystem required to invoke getHotelDetails() in this situation? • If so, drawing the collaboration diagram is an act of specification... • If not, then we are using this technique simply as a way of discovering useful operations email:[email protected] Syntropy Limited Specifying a component (4) anotherComponent: B If we want to provide a more detailed specification we can use interaction diagram fragments. 1:doIt (a, b) These are pieces of the diagrams we drew earlier, for operation discovery, theComponentBeing Specified/IW: A that focus on the component being specified. 1.1:doIt (a, b) Each fragment specifies how a particular operation is to be aComponentSupporting/IX: C implemented in terms of interaction with other components. 1.1.1:doIt (a, b) Warning: in some cases this will be over-specification. aComponentSupporting/IY email:[email protected] Syntropy Limited UML diagrams used in the process Use Case Business Diagram Concept Model Requirements Diagram Class Use Case Diagrams Business Concept Model Diagram Use Case Model Business Type Model Specification Diagram Interface Class Specification Business Type Model Diagrams Interface Diagram Responsibility Interface Specifications Diagram Component Specification Component Specifications Diagrams Component Architecture Component Component Architecture Interactions Interaction Diagram Diagrams Collaboration Package Diagram Diagram email:[email protected] Syntropy Limited Implications for the UML email:[email protected] Syntropy Limited UML Component (v1.4) Implementation characteristics Structure and Behavior Artifact Classifier characteristics * Package characteristics * * **UML * Model Node Component Element 1 Deployment * characteristics Component Instance • UML Glossary: “a physical, replaceable part […] that packages implementation and […] provides the realization of a set of interfaces” email:[email protected] Syntropy Limited Mapping to UML Concept UML element (1.4) UML stereotype < Component < Component UML Component Component < < < email:[email protected] Syntropy Limited Model “perspectives” • UML is a language for describing models • What is the purpose of your model? – Models that describe the problem domain • nothing to do with software – Models that specify software • ranging from the whole system to one small part – Models that describe the implementation of software Problem domain S/W spec Implementation email:[email protected] Syntropy Limited Typical usage of UML notations Problem domain S/W spec Implementation boundary Use case interactions information component component Class diagram models structures structures Seq/collab required object designed object diagram interactions interactions Activity business algorithms diagram processes Statechart object lifecycles object lifecycles email:[email protected] Syntropy Limited Same name, different purpose Problem domain S/W spec Implementation < * setName (String) private < Business Type Model, Interface Spec email:[email protected] Syntropy Limited Want to know more? • UML Components by John Cheesman and John Daniels, Addison-Wesley • http://www.umlcomponents.com email:[email protected] Syntropy Limited