December
1999 Issue: 11
December
1999 Issue: 11
Journal of Conceptual Modeling
www.inconcept.com/jcm
Object
COMX
By Dr. Judith Barnard
Abstract
The Unified Modelling Language (UML) and its associated methodology, the Unified Process (UP) (formerly Objectory), look to dominate the software engineering industry for many years to come and its influence is beginning to filter through to undergraduate curricula. Whilst this type of modelling brings many benefits to the software community, its one deficiency is its lack of formality and hence the ability to analyse the design. Several approaches to the formality of object-oriented methods have been investigated. Other approaches have looked into the object-orientism of a formal method. The Object COMX method is both formal and object-oriented and falls into this latter category.
Object COMX is a structured method for the development of computer systems based around the formal specification technique of communicating X-machine objects. It supports software development from requirements analysis to implementation. Its verification phase is particularly important as it allows the formal specification to be compared to the use cases in the requirements analysis phase for proof of correctness.
This paper describes the phases of Object COMX and suggests that it may be an interesting alternative to the more widely-known methods, such as UML/UP, especially in its ability to provide precise object-oriented specifications of systems, which are amenable to proof and verification.
1 INTRODUCTION
The UML [1] and its associated methodology, the Unified Process (formally Objectory) [2], look to dominate the software engineering industry for many years to come and its influence is beginning to filter through to undergraduate curricula. Whilst this type of modelling brings many benefits to the software community, its one deficiency is its lack of formality and hence the ability to analyse the design. Several approaches to the formality of object-oriented methods have been investigated. Other approaches have looked into the object-orientism of a formal method. The Object COMX methodology is both formal and object-oriented and falls into this latter category. However, unlike many formal methods, Object COMX is also a methodology, supporting a step-wise system development in a highly graphical manner.
Object COMX (pronounced 'comics') extends COMX [3], [4] for object-oriented developments and is a structured methodology for the development of computer systems based around the formal specification technique of communicating X-machine objects. It supports software development from requirements analysis to implementation. The phases in-between support a high level object model, a formal specification of the objects as a set of communicating X-machine objects, verification (using a reachability analysis) and finally the object-oriented design phase.
Figure 1 Object COMX methodology
Object COMX comprises five main phases, each with specific deliverables (see Figure 1):
OC0: Requirements Analysis using soft systems analysis, use cases (sets of scenarios) and traditional methods of customer and user interviews etc. to describe the proposed system in the most effective way. Deliverable: Requirements specification.
OC1: Object Modelling in the external behavioural view, where the system is modelled directly as a set of interacting objects. There is no mention at this stage of the type (class) of the object or any inheritance etc. Object-oriented issues, such as these, are considered in Phase OC4. Deliverable: Object communication diagram.
OC2: Formal Specification of the internal behaviour of the objects (defined in OC1), each as a communicating X-machine object (CXMO). Deliverable: CXMO formal specifications of each of the objects.
OC3: Verification of the CXMO specification via a use case-reachability analysis. Various system properties such as reachability, freedom from deadlock etc. can be gathered from the use case - reachability tree. Correctness is verified through use case identification on the tree. Deliverable: Use case-reachability tree and system properties.
OC4: Object-oriented Design of the system for implementation purposes in which each CXMO is classified (as a communicating X-machine (CXM)) and any inheritance and aggregation identified. This is presented in a CXM class diagram, using UML notation. Deliverable: CXM class diagram.
Each of the phases is subject to its own verification for both consistency of design and system correctness. From the verification phase the system's properties, such as correctness are compared to the initial requirements specification. If there are any discrepancies then a redesign of the system can take place, from phase OC1. In addition to this, the methodology supports changing requirements, which allows the whole methodology to iterate until the requirements become stable. Phase OC4 (Object-oriented Design) is optional since there may be some systems, such as non-software systems, that are not object-oriented in nature.
This paper describes the phases of Object COMX in detail, using a lottery kiosk case study. The lottery kiosk is an automated machine that allows customers to buy up to 6 lottery ticket lines at a time. Users enter the appropriate coinage, choose their numbers for a particular draw (or use the lucky dip option) and then take a printout of their ticket. Meanwhile the ticket data has been sent to the lottery headquarters.
2 OC0: REQUIREMENTS ANALYSIS
A report from the Standish Group [5] claims that 31% software projects never reach completion and those that do are often completed long after the deadline has passed and well over-budget. They also reported that the main reason for these failings could be traced back to the requirements analysis phase of the project. Many projects fail to provide what the customer really wanted and this can be attributed to both the customer's misunderstanding of what system they want and the developers failing to interpret the requirements specification.
Object COMX recognises this problem through its first phase OC0: Requirements Analysis. This phase involves obtaining the requirements specification of the system under consideration. We base our ideas on existing methods of soft systems analysis and use case analysis. Soft systems analysis allows us to look at all aspects of a system: from user thoughts and relationships to the real-time specification of a system. Use cases allows us to construct the requirements in a way that is understood by all people involved as well as aiding the design and verification processes later.
The techniques used within this first phase of Object COMX are rich pictures and use cases. We will concentrate on use cases in this paper as they form an important element to the verification phase OC4.
2.1 USE CASE ANALYSIS
A use case analysis [7] approaches the system requirements from a user point of view. A use case is a typical scenario of events that the system will go through, often initiated by a user (but sometimes hardware or another system). A use case is generally made up of a set of scenarios, each scenario being an instance of a use case, and these too can be listed. In Figure 2 below a typical set of use cases and scenarios have been drawn up for the lottery ticket terminal. Note that for each use case representing a successful user transaction there can often be one or more use cases representing user mistakes or errors.
Use case identification must be thorough as they are used later in proving the correctness of the formal specification. They also provide excellent pointers to the identification of the objects of the system, as required by the second phase of Object COMX.
Use case 1: The user successfully obtains lottery
ticket(s)
· Scenario 1: Chooses their own numbers
· Scenario 2: Uses lucky dip option to choose their numbers
Use case 2: The user unsuccessful in obtaining
lottery ticket
· Scenario 1: User enters invalid numbers (e.g. number > 49, two
identical numbers in one line)
· Scenario 2: User takes too long in choosing their numbers
· Scenario 3: User cancels ticket
· Scenario 4: User entered wrong/not enough coinage/too much coinage
(> £6)
Use case 3: Lottery kiosk failure
· Scenario 1: Kiosk runs out of ticket paper
· Scenario 2: Kiosk is put out of order by lottery headquarters
Figure 2 A typical set of use cases and their scenarios
Once the scenarios have been identified then an expansion of each can take place. This involves identifying the sequences of events within each scenario. Taking the scenario from the lottery kiosk where the user successfully obtains a ticket using the lucky dip option (Use case 1, Scenario 2), a possible sequence of actions is:
Other requirements gathering techniques such as customer and user interviews, questionnaires, documentation analysis are also encouraged as a way of gaining as much information about the proposed system as possible, so that a thorough set of use cases can be documented. The final part of this phase is to draw up the requirements specification from the information in the rich picture, the set of use cases and the other techniques.
Deliverable of OC0: Requirements specification of the system
3 OC1: OBJECT MODELLING
The second phase of Object COMX is OC1 and involves the creation of a high level model of the system from the requirements specification. Its purpose is to model the system as a set of interacting objects. At this phase no consideration of the object-oriented nature of the system is taken. So we are not interested in what class a particular object is an instance of, or what inheritance or aggregation exists. The diagrams at this stage are not class diagrams but object communication diagrams, modelling the system through a set of communicating objects. The reason for not considering object-oriented features, such as classification, is because this can constrain the design too early on in the process. Features like these are implementation details that need not be considered until the end of the specification process.
The phase begins with a model (Level 0) showing the system as a single component that interacts with its environment, as shown in Figure 3 below.
Figure 3 A Level 0 model
This component may consist of a number of communicating objects and/or sub-components and so the model is refined hierarchically over levels and new sub-components/objects and their interaction between each other are identified. This is done by looking at the use cases (listed in phase OC0) which are, by definition, sequences of operations on components/objects of the system.
The final level in the hierarchy is one consisting of objects (components that can be decomposed no further and whose behaviour can be modelled as a sequential process). This is depicted on an object communication diagram and the lottery kiosk model is shown in Figure 4 below. Each object is linked to another object via channels, which connect an output port on one object (shown as a square), with an input port on another object (shown as a circle). Each port and the channels are data-typed, as are the objects themselves. Although this is of little interest in this phase, the data-typing becomes useful in the next phase of Object COMX. Each object is named, ports are named and typed and identified as either input or output ports.
Deliverable of OC1: Object communication diagram
Figure 4 Object communication diagram for the lottery kiosk
4 OC2: FORMAL SPECIFICATION
In this phase we turn our attention to the behaviour of each of the objects identified in the last phase, and consider a formal specification of each of these. Each of the objects is formally specified as a communicating X-machine object (CXMO). A CXMO is a typed finite state machine that can communicate with other CXMOs either through events or data. A formal description of a CXMO is presented in the following subsection.
4.1 COMMUNICATING X-MACHINE OBJECT (CXMO)
A CXMO derives from the X-machine model [8], [9], [10], a mathematical model, whose application to software systems has only been realised in the last couple of decades.
An X-machine (XM) is a typed finite state machine. It models a process in terms of states and transitions within an underlying data type (X). It is more general than a Turing machine and is based at a higher level of abstraction. It was recognised, therefore, as a model that would be effective in the development of software systems [8]. The typed nature of the XM is what makes it far more expressive in terms of modelling systems than conventional state transition models. Each XM is typed (X, which can be a simple or a compound type) and as the XM moves from state to state, the values of X can change. This means that by using a set of XMs to describe a system a more thorough description of the system is provided, in terms of a data model, a functional model (the transitions) and a dynamic model (the nature of the state transition model).
However the X-machine is very limited in its ability to model concurrency and communication, so in [11] the communicating X-machine (CXM) model was defined and has been applied to a variety of communicating systems. The difference between the CXM and the XM lies in the communication between machines; the CXM can have any number of input and output ports that allow a variety of communications between machines. Each CXM only interacts through its ports; there is no reference within a CXM to any other CXM (indirect communication). This means that each CXM is highly encapsulated with a strong interface (ports) and has the flexibility to be replaced and reused. We can apply a CXM in an object-oriented context by allowing a CXM to be a class that can inherit from other CXMs and for instances of the class to be created.
A communicating X-machine, CXM, is given by an 11 - tuple:
The CXM has proved effective in the object-based modelling of communicating systems. To be effective in an object-oriented sense then we must be able to define a communicating X-machine object (CXMO). A CXMO is an instance of a CXM (class) with the ability to communicate with other CXMOs through events, as well as data-passing. Ports, therefore, can either be data-typed (attributes of the object) or event-typed (operations of the object), and so define the interface of the object.
A communicating X-machine object, CXMO, is given by a 2 - tuple:
CXMO = (Id, C) where
Id is the unique name/identity of CXMO,
C is the class (CXM) that CXMO belongs
to.
Communication between a set of communicating X-machine objects {CXMOk} is obtained through the use of channels each of which link an output port of one CXMO to the input port of another CXMO. A system of CXMOs is a set of CXMOs {CXMOk} together with a set of relations
.
4.2 HOW A CXMO WORKS
An object modelled as a CXMO begins in an initial state (there may be more than one initial state, each shown with a free arrow into it). From this state they may be one or more transitions leading from it to other states. Only one of these transitions can take place. Each transition has a predicate associated with it and when that predicate evaluates to TRUE then the transition can take place. The predicate can be based on one or more inputs at the CXMO's input ports and/or on a condition on the values of the memory data (M) of the CXMO. When a transition takes place the CXMO enters a new state. There may be one or more outputs from the transition, each of which is sent to one or more the CXMO's output ports. There also may be an update in the values of M. At an output port, data or an event signal travels the channel connecting it to the input port of another CXMO, thus representing asynchronous communication. This process continues from state to state until the CXMO reaches one of its terminal states (if it has one), shown with a free arrow away from it.
A formal specification of an object as a CXMO consists
of a state transition diagram (showing F, Q, I, and T) along with formal
descriptions of each of the transitions (
) and the
CXMO memory (X) consisting of memory, M and data or events types of the
ports. The transitions take on the following form:
Transition name: (Pre-state; input predicate) "
(Post-state; output predicate)
E.g. Print: (S1; input? = x, Port A ^ M=(0, y)) «
(S2; output! = y,
Port B ^ M=(0, x))
where input?, output! : INTEGER
Inputs and outputs variables and events at the ports use the '?' and '!' notation respectively. Input and output predicates can utilise first order logic to combine the individual conditions into a whole predicate. Pre-state and post-state can be the same state - for loop-back transitions. The state transitions of the CXMOs will correspond to the methods of the object and the data memory components will correspond to the object's attributes. Methods and attributes are public if there are input ports of their type.
4.3 FORMAL SPECIFICATIONS OF THE LOTTERY KIOSK OBJECTS
The CXMO state transition diagram and specification for the Kiosk object is given below in Figure 5.
Kiosk
Figure 5 CXMO state transition diagram of the Kiosk object
[0] InitialWelcomePage: -> (Start; screen! = 'Welcome
to the lottery kiosk', Port S)
[1] ShowWelcomePage: (Start; hq? = OK, Port Q) «
(Start; screen! =
'Welcome to the lottery kiosk', Port S)
[2] CalculateNoLines: (Start; (value? = x ,Port V) ^ (x: INTEGER)) «
(Correct coinage; screen! = 'You have' x 'lines', Port S, action! = reset,
Port O ^ KM(NO_LINES) = x)
[3] IncorrectCoinage: (Start; value? ¹ INTEGER, Port V) « (Incorrect
coinage; screen! = 'You have entered incorrect coinage. Please enter more or
press refund', Port S)
[4] RefundIncorrectCoinage: (Incorrect coinage; user? = refund, Port T) «
(Start; screen! = 'Welcome to lottery kisok', Port S, refund!, Port
W)
[5] EntersCorrectCoinage: (Incorrect coinage; (value? = x, Port V)^ (x:
INTEGER)) « (Correct coinage; screen! = 'You have' x 'lines', Port S,
action! = reset, Port O ^ KM(NO_LINES) = x)
[6] AllowNumberEntry: (Correct coinage; t? = 2, Port P) «
(Enter
numbers; screen! = 'Please enter numbers', Port S, action! = reset, Port O ^
line_count = 0 ^ number_count = 0)
[7] InputNumbers: (Enter numbers; t? < 60, Port P, user? = number, Port T
^ KM = (id, now, now, tid, x, (number,…))) «
(Enter numbers; screen!
= numbers, Port S ^ number_count = number_count + 1 ^ number_count <= 6,
(when number_count = 6, line_count = line_count + 1, line_count <= KM(NO_LINES))
[8] LuckyDip: (Enter numbers; user? = luckydip, Port T, line_count = 0) «
(Enter numbers; screen! = 'Lucky numbers being selected. Ticket being
printed', Port S ^ line_count = line_count + 1 ^ line_count <= KM(NO_LINES)
^ KM(TICKET) = Random(x)), where Random(x) is a random number selection
function
[9] CheckNumbers: (Enter numbers; (number? > 49) v (number? = KM(TICKET(NUMBERi)))) " (Enter numbers; screen! = 'Invalid numbers.
Please re-enter', Port S), where i = 1 to number_count
[10] Timeout: (Enter numbers; t? >= 60, Port P) «
(Restart/Refund;
screen! = 'You took too long in choosing your number. Please start your
number entry again. Or press refund', Port S)
[11] Restart: (Restart/Refund; user? = restart, Port T) «
(Enter
numbers; KM(TICKET) = Ø ^ screen! = 'Please enter your numbers', Port S)
[12] FinishNumberEntry: (Enter numbers; line_count = KM(NO_LINES), user? =
confirm, Port T) « (Ticket printed; screen! = 'Your ticket is being
printed', Port S, hq! = KM, Port R, numbers! = KM(TICKET), Port N)
[13] TicketPrinted: (Ticket printed) «
(Ticket out; screen! = 'Please
take your ticket', Port S)
[14] EndSession: (Ticket out ) «
(Start; screen! = 'Welcome to lottery
kiosk', Port S ^ KM= Ø)
[15] Refund: (Restart/Refund; user? = refund, Port T) «
(Start; screen!
= 'Welcome to lottery kiosk', Port S, refund!, Port W ^ KM = Ø)
[16] PutOutOfOrder: (Start; hq? = NOT_OK, Port Q) «
(Out of order;
screen! = 'The kiosk is out of order', Port S)
[17] BackToWorkingOrder: (Out of order; hq? = OK, Port Q) «
(Start;
screen!='Welcome to lottery kiosk', Port S)
[18] OutOfPaper: (Start; paper?=0,Port U) «
(Out of paper;
screen!='Kiosk is out of order',Port S, paper!=0, Port I)
[19] InPaper: (Out of paper; paper? = z, Port U) «
(Start; screen! =
'Welcome to lottery kiosk', Port S)
where KM = KIOSK_NO x TIME x DATE x TICKET_ID x NO_LINES x TICKETI
where KIOSK_NO is the unique number of the kiosk
TIME: INTEGER x INTEGER is the time of day (minutes, seconds)
DATE: INTEGER x INTEGER x INTEGER is the date (day, month, and year)
TICKET_ID is the unique identity of the ticket (set of lines)
NO_LINES is the number of lines of the ticket
TICKET is the ticket line (6 numbers), TICKETI = INT x INT x INT x INT x INT
x INT (INT =INTEGER), and
i = 1 to NO_LINES
line_count: INTEGER is the number of lines in the ticket
number_count: INTEGER is the number of current numbers chosen in the line (0
to 6)
hq?, Port Q : STATUS = OK ¦ NOT_OK
value?, Port V, t?, Port P, paper?, Port U, paper!, Port I : INTEGER
screen!, Port S : CHAR
action?, Port O : RESET = reset i.e. an event
user?, Port T : KEY
Port R : KM
numbers!, Port N : KM(TICKET)
Port W is the coin refund box, refund! are the actual refunded coins
The CXMO specifications of the other objects now follow: the Ticket Printer, the Coin Monitor, Clock and the User Interface.
Ticket Printer
Figure 6 CXMO state transition diagram of the Ticket Printer object
[20] PrintTicket:(In paper; numbers? = NUMBERS, Port
K; PMM > 0) «
(In paper; PMM = PMM -1; Ticket!,Port J)
[21] RunOutOfPaper: (In paper; PMM = 0) «
(Out of paper; paper! = 0,
Port F)
[22] InPaper: (Out of paper; paper? = z, Port B; PMM = 0) «
(In paper; PMM = z, paper! = z, Port F)
where PMM : INTEGER is the memory component of the paper monitor showing how
much paper is left
NUMBERS : KM(TICKET)
Port B, Port K, Port F: INTEGER
paper! : INTEGER representing the amount of ticket paper in the machine
paper?: INTEGER is the amount of paper entered into the kiosk
Port J is the ticket dispenser, Ticket! is the physical ticket.
Coin Monitor
Figure 7 CXMO state transition diagram of the Coin Monitor object
[23] CalculateCoinValue: (Weigh coins; coinweight? =
y, Port H) « (Weigh coins; value! = F(y), Port G)
where F(y): COIN_WEIGHT ® INTEGER is a function relating coin weight to
value
Port H, coinweight? : COIN_WEIGHT is the weight of the coins
Port G, value! : INTEGER is the value of the coins
Clock
Figure 8 CXMO state transition diagram of the Clock object
[24] Reset: (Tick; action? = reset, Port L) «
(Tick; t! = 0, Port M)
[25] Tick: (Tick) « (Tick; t!= t + 1, Port M)
where Port L, action? : RESET = reset
Port M, t! : INTEGER
User Interface
Figure 9 CXMO state transition diagram of the User Interface object
[26] Display: (Display; screen? = text, Port D) «
(Display; display!, Port E)
[27] UserInput: (Display; key? = x, Port A) «
(Display; user! = x, Port
C)
where Port D, screen! : CHAR
Port E is the VDU screen on the kiosk, display! is the actual text on the
VDU
Port A, key? : KEYBOARD (the actual keyboard itself)
Port C, user!: KEY =
1¦2¦3¦4¦5¦6¦7¦8¦9¦0¦LuckyDip¦Refund¦Confirm¦Restart
Finally we need to define some methods associated with the lottery
headquarters and the coin refund box, to help us later in the verification
phase. For the lottery headquarters we define Send() and Receive() to
represent the sending of information and the receiving of information,
respectively. For the coin refund box we define Refund() which is the actual
action of coins falling into the refund box.
That now completes the formal specifications of the objects in the lottery
kiosk.
Deliverable of OC2: CXMO formal specifications of each of the objects.
5 OC3: VERIFICATION
The previous phase of Object COMX created a formal object-based specification of a communicating system in a form which can be implemented. Phase OC3 is the verification phase that sets Object COMX apart from most other object-oriented design methods. Verification here utilises a reachability analysis, taken from the well-established work on Petri Nets [12] in which a use case-reachability tree of a system can be constructed to prove some system properties including the correctness of the specification.
5.1 USE CASE - REACHABILITY TREE
A use case - reachability tree shows, in a tree-like structure, the possible global states and paths that the system can take. It is developed from the final communicating X-machine object specifications and shows a completely new view of the system. It is this view that makes it easy to identify whether deadlock occurs or whether the system terminates (if it is supposed to). As well as this, each use case scenario, as documented in the requirements analysis phase, should be represented as a path on the tree, so we can use the tree to prove system correctness. So the tree can be viewed as both a reachability tree (state-based) and a use-case tree (use-case based), hence the name 'use case - reachability tree'. The construction of the tree is the same of that in COMX, described in [4].
The number of possible global states that a system can enter can be immense, even for small systems. This means that the construction of the use case - reachability tree is made increasingly harder as the size of the system increases. Therefore a number of techniques have been devised that allow the developer to reduce the size of the tree, during construction, to a more manageable size. Two reduction methods can be used (identifying duplicate nodes and using stubborn sets) and details of these can be found in the reference to COMX [4].
5.2 ANALYSIS OF THE USE CASE - REACHABILITY TREE
We can use the reachability tree to investigate a number of properties : reachability, deadlock, termination and correctness. Definitions of reachability, deadlock and termination can be found in [4]. Correctness, however, takes on a new meaning in the object-oriented context of Object COMX as we can now use the tree the check that the system does what it should with respect to the use cases defined in phase OC0.
Correctness - use case verification
Correctness is the property that says the system does as it should, with respect to the requirements specification of that system. In this case we can refer back to the list of use cases that were used to construct the requirements specification in phase OC0. Each use case should be represented on the reachability tree as a downward link of nodes, in most cases starting from the root node. In addition to this, we can check that all states that the system should enter do exist on the tree, as well as looking out for any unwanted states that the system may enter.
In Figures 10 and 11 (separated for clarity) below the use case - reachability tree for the lottery kiosk is presented. Inside the nodes are the global states using the following labels:
(KIOSK, TICKET PRINTER, COIN MONITOR, CLOCK, USER
INTERFACE)
KIOSK: Start (s), Out of Order (oo), Out Of Paper (oop), Correct Coinage
(cc), Incorrect Coinage (ic), Enter Numbers (en), Ticket Printed (tp),
Restart/Refund (rr), Ticket Out (to)
TICKET PRINTER: In Paper (ip), Out Of Paper (op) COIN MONITOR: Weigh Coins (wc)
CLOCK: Tick (t) USER INTERFACE: Display (d)
The tree shows that deadlock does not occur in the system and that termination does not occur since there are no terminal states in any of the objects. However, the main use of the tree in this case is to prove the correctness of the specification against the use case requirements. Each branching of the tree (starting at the root) should correspond to a use case scenario. If all scenarios are represented on the tree then we can be confident of the correctness of the specification. Lets look at one use case associated with this system: the user obtaining a lottery ticket using the lucky dip option (Use case1, Scenario 2 as in Section 2.2).
To verify that our designed system satisfies this requirement, then we must identify this sequence of events on the use case - reachability tree as a sequence of branches, usually from the root node to a leaf node. In Figures 11 and 12 this particular sequence has been highlighted in bold arrows thus proving correctness for this use case. Remember that a duplicate node means that its subsequent behaviour is represented somewhere else in the tree, hence the break in flow in the tree of this particular scenario.
Deliverable of OC3: Use case - reachability tree and system properties.
6 OC4: OBJECT-ORIENTED DESIGN
This final phase, OC4, is the last phase before implementation and it looks at the system from an object-oriented perspective. So far OC1 and OC2 have provided an object-based model of the system. OC3 has analysed and verified the model and shown whether it is suitable for implementation or not (if not, a re-design of the system is required). Phase OC4 takes the specification further and allows the system model to be object-oriented.
We consider the object-oriented nature of the system at this final phase for two reasons. Firstly we will know more about the system at this stage of development than at phase OC1and so classification, inheritance and aggregation may be more obvious. In other methods these issues are performed very early on in the development process which can constrain the system somewhat. Secondly, since phase OC4 is optional, it can be omitted, allowing the choice of an object-based specification (for hardware systems, for example).
There are no hard and fast rules to the classification of the objects, but the formal specifications of each object may reveal objects of the same class and any inheritance, polymorphism and aggregation between the classes. This phase identifies the classes that the objects of the system belong to and their methods and attributes. In general state transitions will correspond to methods and memory component types will correspond to attributes. Those methods and attributes that are public i.e. can be accessed by other objects, will be those which have input ports of their type.
Figure 10 Top half of the Lottery Kiosk use case - reachability tree
Figure 11 Bottom half of the Lottery Kiosk use case - reachability tree
In addition to this any aggregation and inheritance between these classes is identified and presented on a CXM class diagram. Note that association between classes is not shown in this diagram - this can be viewed in the object communication diagram. The lottery kiosk CXM class diagram is shown below in Figure 12, using UML notation (using the CASE tool Rational Rose 98). Each box represents a class with its class name, attributes and methods. So completing the formal specification of the system as a set of CXMs and CXMOs, each class is given a name ('Name'), set of superclasses (Cs) and aggregate class (Ca). using this class model with the formal specifications of phase OC2, the system is ready to be implemented in the appropriate language.
Deliverable of OC4: CXM class diagram.
Figure 12 CXM class diagram of the Lottery Kiosk
7 CONCLUSIONS
Object COMX is a methodology for the formal, object-oriented specification of computer systems. This is a combination that has been hard to achieve in other design methods, which tend to concentrate their efforts on either the formal specification or the object-oriented aspects. UML and the Unified Process together form an impressive methodology, supported by excellent CASE tools from Rational. However they lack on the formality and verification. One downside to Object COMX is its lack of automation, especially in the verification phase. However, the techniques used in Object COMX (formal specification and reachability analysis based on state transition models) could be utilised by UML/UP and its automated tools.
REFERENCES
Dr. Judith Barnard is a Software Engineer Consultant in Northampton, UK.
Contact Information:
J.Barnard@btinternet.com
http://www.btinternet.com/~objectcomx/objectcomx.html
© Copyright, 1998-2004 InConcept
(Information Conceptual Modeling, Inc.) All
Rights Reserved. Privacy Statement.
ISSN: 1533-3825