02-2 Daniels Tutorial-UML Components

UML Components
John Daniels Syntropy Limited

john@syntropy.co.uk
Syntropy Limited 2001 All rights reserved
Agenda
Aspects of a component A process for component specification Implications for the UML
email:john@syntropy.co.uk
Syntropy Limited
Aspects of a component
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 objectoriented programming UML has a set of notations, mostly graphical There are tools that support some parts of the UML
Syntropy Limited
Aspects of an Object
! Specification unit
1..*
Interface
! Implementation unit
0..1 Class Implementation source 1
* realization
Class
1
instance
Object
! Execution unit
Syntropy Limited
Components in context
Object Object Principles Principles
developed within adopted by
Smalltalk
Evolving
adopted by 1989EJB
1967-
Object-oriented Object-oriented Programming Programming

C++ Java Only interoperable within the language. Single address space
Distributed Distributed Object Object Technology DCOM CORBA Technology

Typically language neutral. Multiple address spaces. Non-integrated services
RMI
1995-
Components Components
COM+/.NET A way of packaging object implementations to ease their use. Integrated services
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
Syntropy Limited
Aspects of a component
spec
! It has an ! It has a specification
implementation
for (int i=0; i<limit; i++) { list[i] = };
! It conforms to a standard
Enterprise Component Standard
! It can be
deployed
! It can be
packaged into modules

Syntropy Limited
Component forms
1..*
Interface
Class Implementation source
0..1
* 1 *
realization
Class
1
! Specification unit
instance
Object
Component 1..* Specification *

spec 1
* realization 1
Interface
! Implementation unit
0..1 Component Implementation source
Component
1 1..*
file Component
1..*
instance
Component Object
Module
! Packaging unit
! Execution unit
Syntropy Limited
Two distinct contracts

Usage contract: a contract between a component objects interface and a client
Interface Component Spec <<realize>> <<use>> Client
Component Interface
Realization contract: a contract between a component specification and a component
Syntropy Limited
Interface specification
We could specify placeOrder( ) like this: The number of orders for the customer is increased by one and a reserveStock message is sent to the component supporting the IProductMgt interface
IOrderMgt placeOrder(custNum, prodNum, quan) numOfOrders(custNum): Integer
IProductMgt reserveStock(prodNum, quan) availableStock(prodNum): Integer
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 IOrderMgt client does not care about this - but the implementer does. Therefore it is part of the realization contract
The number of orders for the customer is increased by one and a reserveStock message is sent to the component supporting the IProductMgt interface
Syntropy Limited
Interfaces versus Component Specs

Component Interface Component Specification
Represents the usage contract Provides a list of operations Defines an underlying logical information model specific to the interface Specifies how operations affect or rely on the information model Describes local effects only
Represents the realization contract Provides a list of supported interfaces Defines the run-time unit Defines the relationships between the information models of different interfaces Specifies how operations should be implemented in terms of usage of other interfaces Syntropy Limited
Contracts and roles
A person who produces the technical specification for a system or components within a system
Specifier (Architect)
The Usage Contract

A person who writes software that uses a component
The Realization Contract

A person who builds a component that meets a component specification
Client
Realizer
Syntropy Limited
Component deployment
Component 1..*
1 *
1..* file
Component Module
1 *
installed as server 1..*
copy
Installed Component 1..*

! Registration unit
Installed Module
! Installation unit
Syntropy Limited
Example - Microsoft Word

wordApplication: Component wordDocument: Component
file installed as installed as

wordApplication: InstalledComponent wordDocument: InstalledComponent
file
winword.exe: ComponentModule
server server
copy
C:/../winword.exe: InstalledModule
instance
applicationObject: ComponentObject
instance File / New

docObject: ComponentObject
Syntropy Limited
Example - Enterprise Java Beans

invoice: ComponentSpec
realization
invoiceBean: Component
c:/../invoice.java: ComponentImplementation
file
invoice.jar: ComponentModule
installed as
invoiceBean: InstalledComponent
copy server
c:/../invoice.jar: InstalledModule
instance
invoiceABC: ComponentObject
Syntropy Limited
A process for component specification
Syntropy Limited
Application Architecture Layers

Presentation
Client
RMI / IIOP / DCOM
Web Client
HTTP
Web Server
RMI / IIOP / DCOM
Service
Application Server
Any
Existing System (server)
JDBC / ODBC / SQL
Data
Database Server
Syntropy Limited
Application Blueprint
Web Server A/JSP Application Server
Component Object Component Object Component Object Component Object Component Object
Database
Existing System
Syntropy Limited
Finer-Grain Application Layers

Presentation
User Interface User Dialog
UI Logic What the user sees Dialog Logic (UseCases) Supports multiple UIs Transient Dialog State
Service
System Services Business Services
Business transactions Allows multiple Dialogs (including Batch) Business Integrity State Sub-transactions Business Instance State
Data
Syntropy Limited
Management and Development Processes

Management Processes
Schedule work and plan deliveries Allocate resources Monitor progress Control risk
Concept model 0% % complete 100% Use Case model Component specs 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 Business Concept models email:john@syntropy.co.uk
Specification Workflow
Component specs & architectures
Syntropy Limited
Workflows in the development process

Business requirements
Requirements
Business Concept models Use Case models
Artefact
Existing assets
Technical constraints
Components
User interface
Specification
Component specs & architectures
Provisioning
Assembly
Assemblies
Test
Workflow (c.f. RUP)
Tested assemblies
Deployment Syntropy Limited
The Requirements Workflow

Problem domain knowledge Business requirements
Requirements Workflow
Develop Business Concept Model Develop business processes Software boundary decisions
Identify Use Cases
Business Concept Model
Use Cases
Syntropy Limited
Business process
We want to provide some automated support for managing hotel reservations
Take up reservation
customer arrives/ enquiry/ Check availability Wait for event cancel request/ amendment request/ Amend reservation Cancel reservation no show/
[else]
[suitable room] Make reservation
Confirm reservation
Process no show
Notify billing system
Syntropy Limited

Hotel Chain
1 1..* * contactedHotel * 1..*
Clerk
Hotel
1 *
1 1 allocation * 0..1 1..*
Customer
1 contactAddress 0..1
Reservation
1 *
Room
* 1
Address
1 0..1
RoomType
Bill
Payment
0..1
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 steps, all the steps form a single use case.
customer arrives/ enquiry/ Check availability Wait for event cancel request/ amendment request/ Amend reservation Cancel reservation no show/ Take up reservation
[else]
[suitable room] Make reservation
Confirm reservation
Process no show
Notify billing system
Syntropy Limited
Reservation system
Cancel a reservation ReservationMaker Make a reservation Update a reservation Take up a reservation BillingSystem Process no shows Add, amend, remove hotel, room, customer, etc.
Use Case diagram
Guest
ReservationAdministrator email:john@syntropy.co.uk
Syntropy Limited
Name Goal Steps or Extension Points
Make a Reservation Reserve a room at a hotel Main success scenario 1. Reservation Maker asks to make a reservation 2. Reservation Maker selects hotel, dates and room type 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 Extensions 3. Room Not Available a) System offers alternative dates and room types b) Reservation Maker selects from alternatives 6. Customer already on file a) Resume 7 Syntropy Limited
Initiator Reservation Maker
Alternatives Use an informal Alternatives section if you dont want to specify the detail required for an extension
The Specification Workflow

Requirements Specification
Component Identification Component Interaction Component Specification
Provisioning
Syntropy Limited
Components in the service layers

Presentation Service
System Services
System Component System Component
System interfaces
operations support use case steps
Business Services
Business Component Business Component
Data
Business interfaces
operations support core business logic
Syntropy Limited
Component Identification
Business Concept Model Use Case Model
Develop Business Type Model Existing Interfaces Existing Assets Identify Business Interfaces
Component Identification
Identify System Interfaces & Ops Architecture Patterns
Create Initial Comp Specs & Architecture Business Interfaces Component Specs & Architecture
Business Type Model
System Interfaces
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.
Use case
Make a Reservation
Make Reservation
Dialog logic
Use case steps
2. Reservation Maker selects hotel, dates and room type 3. System provides availability and price 7. System makes reservation and gives it a tag 8. System reveals tag to Reservation Maker 9. System creates and sends confirmation by email
<<interface type>> IMakeReservation getHotelDetails() getRoomInfo() makeReservation()
System Interface
Syntropy Limited
Use case step operations

Return a list of hotels and the room types they have
<<interface type>> IMakeReservation getHotelDetails() getRoomInfo() makeReservation()
Return price and availability given hotel, room type and dates Create a reservation given hotel, room type and dates; return its tag Return reservation details given a tag Given a tag, allocate a room and notify billing system
<<interface type>> ITakeUpReservation getReservation() beginStay()
Syntropy Limited
Develop the Business Type Model

Hotel Chain
" "
1 * 1 1 0..1
1..* 1..*
Clerk
* contactedHotel
Hotel
1 *
1 1 allocation * 0..1
"
1..* * 1
Customer
Reservation
1 *
Room
contactAddress
Address
Payment
" "
Bill
0..1
"
Syntropy Limited
0..1
RoomType
Initial Business Type Diagram
name: String 1 1 1..*
<<type>> Hotel
1..*
<<type>> RoomType
name: String price: Currency * 1
<<type>> Customer
name: String postCode: String email: String
* resRef: String dates: DateRange *
<<type>> Reservation
number: String allocation 0..1
<<type>> Room
<<trace>>
Business Type Model
Syntropy Limited
Identify Core types

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 Hotel Room RoomType
YES. Has id (name) and no mandatory assocs. YES. Has id (name) and no mandatory assocs. NO. Has mandatory assoc to Hotel NO. Has mandatory assoc to Hotel Syntropy Limited
Reservation NO. Has mandatory assocs.
Identify business interfaces

<<interface type>> IHotelMgt
*
<<core>> <<type>> Hotel

name: String 1
1..*
<<type>> RoomType
name: String price(Date): Currency stayPrice(DateRange): Currency available(DateRange): Boolean 1..*
<<core>> <<type>> Customer

name: String postCode: String email: String *
* resRef: String dates: DateRange *
<<type>> Reservation
number: String allocation 0..1
<<type>> Room
<<interface type>> ICustomerMgt Responsibility for business types is shown by containment
Responsibility for holding this association has been allocated to IHotelMgt
Syntropy Limited
Component Specifications
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
<<comp spec>> CustomerMgr
<<component spec>> HotelMgr
IHotelMgt
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

<<comp spec>> Reservation System
IBilling ICustomerMgt IHotelMgt
IMakeReservation ITakeUpReservation
<<comp spec>> BillingSystem
IBilling
Syntropy Limited
Component architecture
<<comp spec>> Reservation System <<comp spec>> BillingSystem
IBilling
<<comp spec>> CustomerMgr
ICustomerMgt
<<comp spec>> HotelMgr
IHotelMgt
Syntropy Limited
Minimal component object architecture

<<comp object>> :Reservation System <<comp object>> :BillingSystem
IBilling
<<comp object>> :CustomerMgr
ICustomerMgt
<<comp object>> :HotelMgr
IHotelMgt
Syntropy Limited
Component Interaction
Business Interfaces System Interfaces Component Specs & Architecture
Discover Business Operations
Component Interaction
Refine Interfaces & Ops
Refine Component Specs & Architecture
Interfaces
Component Specs & Architecture
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
Syntropy Limited
getHotelDetails( )
/IMakeReservation:ReservationSystem
1:getHotelDetails( )
/IHotelMgt
<<interface type>> IMakeReservation getHotelDetails (in match: String): HotelDetails [ ] <<interface type>> getRoomInfo ( ) IMakeReservation makeReservation ( ) <<data type>> HotelDetails id: HotelId name: String roomTypes: String [ ]
getHotelDetails() getRoomInfo() <<interface type>> makeReservation() IHotelMgt

getHotelDetails (in match: String): HotelDetails [ ] email:john@syntropy.co.uk
Syntropy Limited
/ICustomerMgt makeReservation ( ) 1:getCustomerMatching( ) 3:notifyCustomer( )
/IHotelMgt
2:makeReservation( ) <<data type>> CustomerDetails
/IMakeReservation:ReservationSystem
name: String postCode[0..1]: String email[0..1]: String
<<interface type>> IMakeReservation 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 <<interface type>> IHotelMgt 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:john@syntropy.co.uk Syntropy
Limited
Component Specification
Business Type Model
Interfaces
Define Interface Information Models
Component Specification
Specify Operation Pre/Post-Conditions
Specify ComponentInterface constraints
Interfaces
Syntropy Limited
Interface information model

<<interface type>> ICustomerMgt 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 component object offering the interface, for the purposes of specification only. Implementations do not have to hold this information 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.
Customer id: CustId name: String postCode: String email: String
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 doesnt 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:john@syntropy.co.uk
Syntropy Limited
<<interface type>> IHotelMgt 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 resRef: String * dates: DateRange claimed: Boolean * 1 Customer id: CustId * * 1
* Hotel id: HotelId name: String 1 1..* 0..1 Room number: String *
allocation RoomType name: String available(during: DateRange): Boolean 1 price(on: Date): Currency stayPrice(for: DateRange): Currency 1
Syntropy Limited
:Hotel {id=4}
before after
:RoomType {name=single}
:RoomType {name=double}
:Reservation {refRef=H51}
:Customer {id=38}
:Hotel {id=4}
:Reservation {resRef=A77}
:RoomType {name=single}
:RoomType {name=double}
:Reservation {refRef=H51}
:Customer {id=92} email:john@syntropy.co.uk
makeReservation ( )
:Customer {id=38}
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
Syntropy Limited
Specifying a component (1)

IMakeReservation
ITakeUpReservation
IBilling
IHotelMgt
ICustomerMgt
Specification of interfaces offered and used (part of the realization contract)

Syntropy Limited

<<interface type>> ICustomerMgt
1 {frozen}
1 {frozen}
<<interface type>> IHotelMgt
1 {frozen}
<<interface type>> IBilling
Specification of the component object architecture. This tells us how many objects offering the used interfaces are involved Syntropy Limited

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.
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
Syntropy Limited

anotherComponent: B
1:doIt (a, b)
If we want to provide a more detailed specification we can use interaction diagram fragments. These are pieces of the diagrams we drew earlier, for operation discovery, that focus on the component being specified. Each fragment specifies how a particular operation is to be implemented in terms of interaction with other components. Warning: in some cases this will be over-specification. Syntropy Limited
theComponentBeing Specified/IW: A 1.1:doIt (a, b)
aComponentSupporting/IX: C 1.1.1:doIt (a, b)
aComponentSupporting/IY email:john@syntropy.co.uk
UML diagrams used in the process

Use Case Diagram
Use Case Diagrams Business Concept Model Diagram
Requirements
Business Concept Model Use Case Model Specification Business Type Model Interface Specifications Component Specifications Component Architecture Interactions Component Interaction Diagrams Business Type Model Diagram Interface Responsibility Diagram
Class Diagram
Class Diagram
Interface Specification Diagrams Component Specification Diagrams Component Architecture Diagram
Package Diagram
Collaboration Diagram
Syntropy Limited
Implications for the UML
Syntropy Limited
UML Component (v1.4)

Implementation characteristics
Artifact
*
Classifier
*
Structure and Behavior characteristics Package characteristics

*
Node
UML * Component
1
Model Element
Deployment characteristics
Component Instance
UML Glossary: a physical, replaceable part [] that packages implementation and [] provides the realization of a set of interfaces
Syntropy Limited
Mapping to UML
Concept
Interface Component Specification Component Component Implementation Component Module Installed Component Installed Module Component Object
email:john@syntropy.co.uk <<comp imp>> <<comp module>> <<installed comp>> <<comp server>> ( <<comp object>> )
UML stereotype
<<interface type>> <<comp spec>>
UML element (1.4)

UML Class UML Class UML Component UML Artifact UML Artifact UML Component UML Component UML Component Instance
Strictly, a Set of Artifact NB your UML tool might let you use Interface
Syntropy Limited
Realization mappings
<<interface type>>
CustomerMgr
<<comp spec>>
<<offers>>
ICustomerMgt
addCustomer() deleteCustomer() getCustomer() <<realize>> <<realize>> <<offers>> <<interface>>
CustomerMgr
addCustomer() deleteCustomer() getCustomer()
ICustomerMgt
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
Syntropy Limited
Typical usage of UML notations

Problem domain Use case Class diagram Seq/collab diagram Activity diagram Statechart business processes object lifecycles information models S/W spec boundary interactions component structures required object interactions component structures designed object interactions algorithms object lifecycles Implementation
Syntropy Limited
Same name, different purpose

Problem domain S/W spec Implementation
<<concept>> Customer Business Concept Model
<<type>> Customer
name: String postCode: String email: String *
<<class>> Customer
name: String postCode: String email: String setName (String)
<<interface type>> ICustomerMgt
private implementation design
Business Type Model, Interface Spec

Syntropy Limited
Want to know more?

UML Components by John Cheesman and John Daniels, Addison-Wesley http://www.umlcomponents.com
Syntropy Limited

02-2 Daniels Tutorial-UML Components

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

02-2 Daniels Tutorial-UML Components

Uploaded by

Copyright:

Available Formats

UML Components

John Daniels Syntropy Limited

Object-oriented Object-oriented Programming Programming

Distributed Distributed Object Object Technology DCOM CORBA Technology

Component standard features

packaged into modules

Class Implementation source

Component 1..* Specification *

Two distinct contracts

Realization contract: a contract between a component specification and a component

IOrderMgt placeOrder(custNum, prodNum, quan) numOfOrders(custNum): Integer

IProductMgt reserveStock(prodNum, quan) availableStock(prodNum): Integer

Separation of specification concerns

Interfaces versus Component Specs

Contracts and roles

The Usage Contract

The Realization Contract

installed as server 1..*

Installed Component 1..*

Example - Microsoft Word

file installed as installed as

instance File / New

Example - Enterprise Java Beans

A process for component specification

Application Architecture Layers

Existing System (server)

JDBC / ODBC / SQL

Finer-Grain Application Layers

Management and Development Processes

Component specs & architectures

Workflows in the development process

Workflow (c.f. RUP)

Deployment Syntropy Limited

The Requirements Workflow

Identify Use Cases

Business Concept Model

[suitable room] Make reservation

Notify billing system

Business Concept Model

1 1 allocation * 0..1 1..*

Identify Use Cases

[suitable room] Make reservation

Notify billing system

Use Case diagram

Name Goal Steps or Extension Points

Initiator Reservation Maker

The Specification Workflow

Components in the service layers

Identify System Interfaces & Ops Architecture Patterns

Business Type Model

Identify System Interfaces and operations

Use case steps

<<interface type>> IMakeReservation getHotelDetails() getRoomInfo() makeReservation()

Use case step operations

<<interface type>> IMakeReservation getHotelDetails() getRoomInfo() makeReservation()

<<interface type>> ITakeUpReservation getReservation() beginStay()

Develop the Business Type Model

Initial Business Type Diagram

name: String 1 1 1..*

* resRef: String dates: DateRange *

number: String allocation 0..1

Business Concept Model

Business Type Model