Building a CASE Tool in CAVO

Building a CASE tool in CA-Visual Objects

The DLA-Architect homepage


By Bert Dingemans,e-mail : [email protected] : http://home.hetnet.nl/~bert.dingemans



Content

Content.................................................................................................................................................................... 2Why CASE?............................................................................................................................................................ 3Why CA-Visual Objects?........................................................................................................................................ 4OO modelling and design ....................................................................................................................................... 5

Notation........................................................................................................................................................... 5Methodology ................................................................................................................................................... 7

OMT.................................................................................................................................................................... 9Notation........................................................................................................................................................... 9Methodology ................................................................................................................................................. 10

Scripting................................................................................................................................................................ 12Object model scripting ...................................................................................................................................... 12Output scripting ................................................................................................................................................ 13

Source code........................................................................................................................................................... 15Textfile class ..................................................................................................................................................... 15Drawing lines and bitmaps................................................................................................................................ 15DbServer Extensions......................................................................................................................................... 18Adapted __autolayout ....................................................................................................................................... 21

Summary ............................................................................................................................................................... 26Further reading...................................................................................................................................................... 27About the Author .................................................................................................................................................. 28



Why CASE?

CASE is the abbreviation for Computer Aided Software Engineering. These four words can be split in twoaspects in Computer Science. The first is computer aided. This means that you apply computers in solving acertain problem area. Think for example about CAD/CAM where the computer is used for designing andmanufacturing hardware.Software Engineering is the field in which software is developed as a structured process. In the early days ofprogramming people started developing computer programmes by code and fix. This meant that they created aprogramme or module. They ran that piece of software code and when it had an error they fixed that error.This code and fix strategy works fine when developing a small software system as a solitary programmer.However when you have to develop complex software in a team, code and fix is insufficient. It is impossible tooverview all the implications of a change in the software code. This is especially the case when you aredeveloping software in a team.CASE can help you to develop better software because it describes a software development process and it givesyou assistance in modelling the product under construction. Most CASE methods are based on two aspects Description of the process. This means that it describes how Software Engineering (SE) is implemented in

phases. These phases like analysis, design, implementation and testing are divided in sub-steps in whichaspects of the development are described in detail. See for example the tables in the section OO Modellingand Design.

Notation, most SE methods give a number of notations in which the product can be viewed. See this as ablueprint of you software product under construction. See for example the figures in the section OOModelling and Design.

Software development is different from other engineering areas like construction. Software has to be a reflectionof the organisation in which it is used. It assists professionals in creating and selling products and services.Organisations are changing all the time because of a changing environment. Therefore software has to beadapted and extended all the time. Software engineering gives you the opportunity to develop software in aniterative manner.

Applying Software Engineering in a software development process has advantages over non-engineeringpractices. Summarised these advantages are: Faster development of software products Fewer errors in the final product More opportunities for reuse Better support for iterative software development Better possibilities for team developmentWhen software is developed, the SE process can be applied in a number of ways. First there is a functionalprocess, in which the functions of a system are the main focus. Another currently evolving focus is the object. Inthis session we will apply the object-oriented focus.



Why CA-Visual Objects?

For one of the computer systems I developed the usage of CASE became more and more important. It was anapplication for application programmers. Because I wanted to introduce a data dictionary in this application Iwanted to model this data dictionary in detail before I started programming.After some research over the Internet I discovered that there are a number of CASE tools supporting an OOdevelopment process. I evaluated two products Rational Rose and ObjectIF. Both CASE tools are supporting theUML, but this is closely linked to OMT so it was applicable. However these tools had a number ofdisadvantages: They do support the notation, not the methodology Source code generation for CA-Visual Objects is impossible or has to be developed It is impossible to change the internal Object Model of the tool They are expensive.I decided to develop my own CASE tool. This CASE tool has the following requirements: Supporting the two OO SE methods OMT and Merode/MSA in notation and methodology. Possibility to adapt the internal object model of the tool Generation of software code for multiple platforms like CA-Visual Objects, Powerbuilder and MS-Access Support for Xbase and SQL databases.These requirements are used for selecting the developer environment. We selected CA-Visual Objects for anumber of reasons: The product has support for Xbase and SQL The product is extendable and the default behaviour can be adapted There is an SDK available. There are possibilities to implement the notation of the methods There are possibilities for scripting to make the product adaptable.In this session we will describe a number of aspects of implementing a CASE tool in CA-Visual Objects. Firstwe introduce two OO CASE methods implemented in the tool. Later we describe a number of technical aspectslike scripting and source code for implementation of the notation.



OO modelling and design

OO modelling and design is based on two aspects: the notation to create different views on an informationsystem and a methodology to create these views. It is not the intention to give a full description of the methodsused in the MSA designer. Therefore you can find more information in the suggested reading. In the sectionsbelow you will get a brief description of the notation and the methodology supported by the MSA designer.The MSA methodology is based on the Merode methodology developed by the Catholic University of Louvainin Belgium. It is adapted by IMN in the Netherlands to its current implementation. It is based on describing thereal life system by: Reflection Control ReplacementIn brief the object model in a real time situation is simulated in the object model in the information system. TheMSA method is based on two aspects: a notation and a methodology. See the sections below.

Notation

The notation of the MSA method is based on three different notation styles. The first style reflects the staticaspects of the objects and is named ER diagram. It gives a view on the objects and there associations. Theassociations are described in a number of ways. Aspects are the multiplicity of the associations and mandatoryassociations. In the figure below you see an example of the ER diagram

The Object Event table is a matrix like table in which the objects are displayed on the Y-axis and the events onthe X-axis. In the matrix the developer can add three symbols B for creation or begin of objects X for updating object state



E for destroy or end of objects.By adding these three symbols you can define which event causes the change of an objects state by the threeactions mentioned above. Please note that a begin or end of an object can be caused by more than one event.Please see the figure below for an example.

The last notation style displays the roles an object can have during its lifetime. An object has various phasesduring its lifetime. But transition from one phase (role) is not always possible. For example you can not read abook before you have bought it or loaned from a library.In the role structure this is displayed. A role structure has a tree structure in which every this limitation can beclarified. Each node in the tree represents a state transition of the object. There are a number of node styles, theseare: Elementary Sequence Iteration SelectionFor details please see the information available from IMN. In the figure below an example of the role structure isgiven.



Methodology

The MSA methodology is based on a number of phases. These phases are described sequential in this paper.However the method is highly iterative. The developer will jump through the phases during design. Thereforethe methodology is displayed as a menu structure and not as a wizard. A wizard will imply that the methodologyis sequential.During the various phases you will see that the method has a layered approached. These layers introduceencapsulation. At the lowest model you have the objects that are part of the business model. These objects arestatic during time. This layer is called the business domain layer. For example a trading organisation has alwaysobjects like customer, invoice and payment.On top of this layer there is an working organisation layer in this layer different views on the business domainlayer. For example a salesperson has a different view on the object model than a person from the transportdepartment.The last layer in the MSA methodology is the presentation layer. It shows the people in the working organisationhow the object model in the information system is reflected. There is a flow through the layers from the lowest tothe highest layer and reverse. A top down sequence is: Service calls one or more Events calls one or more Methods updates one or more Attributes.In the phases of the methodology the layers are described in detail during development. In the table below adescription is given of the phases and sub-phases.

Phase Sub-phase DescriptionBusiness modelling Identify object and event classes Formulate a list of classes and

events as they exist in the real timeinformation system.



Create an object event table The connection between classes andevents is created in the Object EventTable.

Create an ER diagram For a notation of the objects andassociations between the classes anER diagram is created.

Order constrains Describe the order of the transitionsby using the role structures ofobjects.

Formulate business rules

Information constrains Formulate business rules whichdescribe limitations of objectattributes. Think about null/not nullvalues or domains of attributes

Identify services Describe the working organisationlayer by describing the services.

Working organisation modelling

Dependency diagrams Iterate the model by validating thedependency between layers fromattribute to service and from serviceto attribute

Create a datamodel -- Create a datamodel based on theobject model. Generate a script forcreating the object model as arelation al datamodel or a model foran object database.

Specify methods and businessobject classes

-- Give a description of the objectmodel based on abstract data typesand a list of methods



OMT

The OMT method is developed by James Rumbaugh et al. It has a strong connection with relational systems.Later Michael Blaha and Jim Premerlani extend the method. It has three views: Static view for describing the static aspects like objects, relations and attribute Functional view for describing the functions of the information system Dynamic view describing the events and actions in the system.Notation

For the static view the OMT static diagram notation is used In this diagram you can define objects (classes),relations (associations), and properties (attributes). In the figure below you get a sample view of the static viewin the MSA Designer.

In the figure you see the associations as lines and symbols. You can double-click on the title of the association.By doing so you can modify the attributes of the association. The class is shown as a rectangle with the name ofthe class. You can enlarge the rectangle and the properties and operations become visible. When you doubleclick on one of the entities you open the editor for changing the attributes of these entities. For more options inthis window you can use the section designer window.

For the functional view there is currently no notation available. It is best to use a pseudo code like notation forthe functional aspects. These can be accessed via the OMT static window or the overview window.

For the dynamic view you can use the event trace. This trace shows how messages flow from one object to theother and what action an object undertakes when it sends or receives a message. Also in the window you candouble-click on the rectangles of messages and classes for editing the attributes. In the figure below you see asample of the Event trace



Methodology

The OMT methodology is based on a number of phases. These phases are described sequential in this paper.However the method is highly iterative. The developer will jump through the phases during design. Thereforethe methodology is displayed as a menu structure and not as a wizard. A wizard will imply that the methodologyis sequential.During the various phases you will see that more detail is added to the object model. This is visible in the dataentry windows. In the early phases you only see the names and or identifiers of the entities in the object model.Later you will see more information about the entities in the data entry screens.In the table below you see the different phases with there sub-phases. Where relevant some descriptiveinformation is added.

Phase Subphase DescriptionConceptualisation -- Describe the information system

based on a list of questions to markthe borders of the informationsystem.

Add classes Create a list of classes based onnouns in the description of theinformation system

Add associations See what the relations are betweenthe objects. In MSA designer onlybinary associations are possible

Add properties See in the list of classes what namesare attributes and add missing detailto the attribute/property list.

Analysis

Iterate the model Refine the model using the OMTstatic diagram notation



Build a functional model Build a functional model based onpseudo code

Build a dynamic model Build a dynamic model by addedmessages to the object model andand creating event traces

Devise an architecture Select an architecture for theinformation system. Use one of thepredefined architectures asdescribed in the methodology.

Choose a database managementapproach

Evaluate the object model and seehow the model can be transferred toa database management system.Possible objects are files, DBMS orOO database

Determine opportunities for reuse See if there are aspects in the objectmodel available for reuse. Thinkabout design patterns, class librariesor third party products

System design

Choose an approach for objectidentity

Each object is unique. This meansthat an identifier should be addedwhen the database managementapproach requires this.

Use transformation and add missingdetails

See wheather it is possible toimprove the object model bycombining or separating objects orclasses. Introduce inheritance oraggragation where applicable.

Evaluate the functional model Evaluate the functional model byinspecting the operations in theobject model. Add missing detailswhere necessary

Detailed design

Quality of the model Make a check list of the model andreview the object model. If there aremissing aspects return to one of theprior phases and add the missinginformation.

Realisation These sub-steps are depending onthe development environment used

See the MSA designer how this isimplemented for CA-Visual Objects



Scripting

The MSA designer is a tool that includes a number of predefined objects and export possibilities. The objectmodel used is however not complete for all situations. Therefore a scripting module is included. This means thatyou can define your own scripts for export functionality and for your object model. Scripting is based on thethird party product VOScript. This is a product specially developed for Visual Objects programmers. Howeverthere are other products like CULE, developed by Rod da Silva that can be applied for scripting in VOapplications.

Object model scripting

With object model scripting you can extend or adapt the object model as it exists in the MSA Designer. It is bestexplained by an example. In the example you see the script for the MSA designer in default mode for theproperties in the object model. In the help file you can find the complete script of this function. In the scriptcomment is added to explain the behaviour

FUNCTION LoadDefaultInfo(oServer)

LOCAL cCurrentServer AS STRING

cCurrentServer := oServer:GetClassName()

// this case statement can be extended with other classesDO CASECASE cCurrentServer ="PROPERTYSERVER" // describe the expression of this server as it is displayed // in listboxes and listviews oServer:SetDisplayExpression([AllTrim(oS:Propname) +; " (" + AllTrim(oS:CLASSName) + ")"])

// describe the script expression for this server oServer:SetScriptExpression([AllTrim(oS:CLASSName) +; "_" + AllTrim(oS:PropName) + CrLF()])

// the field value that is returned by listboxes and treeviews oServer:ReturnField := "PROPNAME"

// these fields do not allow null values for this server oServer:AddNotNullField( "CLASSNAME") oServer:AddNotNullField( "PROPNAME")

// these fields are displayed in browsers and listviews // in the order added oServer:AddBrowserColumn("PROPNAME") oServer:AddBrowserColumn("CLASSNAME") oServer:AddBrowserColumn("TYPECONT")

// when a new record is added these values are added to the fields oServer:AddInitVal("TYPECONT", "C") oServer:AddInitVal("VISIBLE", "1") oServer:AddInitVal("LENGTH", 10) oServer:AddInitVal("MINCARD", "0") oServer:AddInitVal("MAXCARD", "1")

// the orders for seek and sort dialog available oServer:AddOrderInfo("CLASSNAME",; "Upper(CLASSNAME)+Upper(PROPNAME)", "Class name") oServer:AddOrderInfo("PROPNAME",; "Upper(PROPNAME)", "Property name")



//Define a number of options for this field // you can give a classname or a static list of options oServer:AddFieldDomain("CLASSNAME", "CLASSSERVER" ) oServer:AddFieldDomain("VISIBLE",; {{ "Export", "1" }, { "Protected", "2" }, { "Hidden", "3" } } ) oServer:AddFieldDomain("MINCARD",; {{ "Zero", "0" }, { "One", "1" }, { "Many", "N" } } ) oServer:AddFieldDomain("MAXCARD",; {{ "Zero", "0" }, { "One", "1" }, { "Many", "N" } } ) oServer:AddFieldDomain("TYPECONT",; {{ "String", "C" },{ "Date", "D" },{ "Memo", "M" },; { "Numeric", "N" },{ "Object", "O" }} )

//set the sort of the properties to the name sort oServer:SetOrder("PROPNAME")

ENDCASE

RETURN

Output scripting

For output scripting it is important that you use the text file class. This class makes it possible to create text filesand add strings of text to it. By traversing the object model servers you can create scripts for database generationscripts, stored procedures and OO DBMS generation scripts. A small sample of the usage of the text file class isgiven below. Again comment is given as an explanation

FUNCTION ADT(oShell)

// defining the variables as localsLOCAL oClass // ClassServerlocal oOper // OperationServerLOCAL oTF // TextfileLOCAL cLine // Stringlocal oWnd // WndScript

// create a textfile objectoTF := TextFile{}// open a textfile. If it does not exist it is createdoTF:Open("C:\cttm2000\ADTDEMO.TXT")

// open the relevant object model serversoClass:=ClassServer{}oClass:MakeRelations()oOper:=oClass:OperationServeroClass:GoTop()

//traverse the collection of classesoClass:GoTop()DO WHILE .NOT. oClass:Eof // write the class information to the text file oTF:WriteLine("CLASS "+oClass:ClassName) oTF:WriteLine("") oTF:WriteLine("METHODS") oTF:WriteLine("")

// traverse the operation server oOper:GoTop()



DO WHILE .NOT. oOper:Eof // write the operation nformation to the textfile oTF:WriteLine(Replicate("-", 80)) oTF:WriteLine(" " + AllTrim(Upper(oOper:ActionName))) oTF:WriteLine("") oTF:WriteLine(" Precondition") oTF:WriteLine(" " + oOper:PreCon) oTF:WriteLine(" Body") oOper:Skip(1) ENDDO oTF:WriteLine(Replicate("=", 80)) oClass:Skip(1)ENDDO// close all objectsoClass:Close()oTF:Close()

RETURN



Source code

In the previous sections of this session we described a number of aspects of the CASE tool MSA designer. In thissection we will describe a limited number of aspects focused on the underlying source code. Unfortunately I hadto make a selection. There are a lot of aspects in developing a CASE tool and they are all interesting from aprogramming point of view.However there is a sample application and an AEF file included. These files give you an impression about thesource code used in this programme. In the paragraphs below I give only a limited number of examples. Whenyou want more information about the sample code you can always contact me by e-mail.

Textfile class

Scripting gives the user of an application a lot of freedom. However because scripting is based on late binding anexpression in a codeblock you can not use strong typed functions and methods. VO has a number of functionsfor communication with text files. These F_ functions are not available in an object-oriented manner as a class.This is strange in an object-oriented language as Visual Objects. It is rather easy to create a class for thispurpose.In the listing below you see the implementation of this class. In the class definition you see two instancevariables. The first is the handle to the file used in this object. The second is the status of the object. In this statusyou can store the status of the object. This is the same as applied in the DbServer class. You can check the statusafter each operation executed on the object. This status is extremely useful for reading from an file, When youare at the end of that file the status will be set to an EOF status.The methods in this class are straightforward. You can open en close a file and write lines of text to it. In theopen method you see how the status is set.

CLASS TextFile

PROTECT pHandle AS PTREXPORT status AS INT

METHOD Close CLASS TextFile

FClose(SELF:pHandle)

METHOD Open(cFile) CLASS TextFile

IF (SELF:pHandle := FCreate(cFile, FC_NORMAL))=F_ERRORSELF:Status:=TF_ERROR

ELSESELF:Status:=TF_OK

ENDIF

METHOD WriteLine(cLine) CLASS TEXTFile

FWriteLine(SELF:pHandle, cLine)

Drawing lines and bitmaps

In the notation of both the OMT and MSA method it is essential to draw lines in diagrams. The static notation ofthe OMT method is a good example. This diagram displays a number of classes and the associations betweenthese classes. Associations are displayed by lines between the classes (classes are displayed by a rectangle with aname). There are a number of association types in both MSA and OMT. The most important are: One - One Zero - One One Many Zero Many



In OMT al these associations have their own symbol. One One is a line, Zero One is an open circle and ZeroMany is a filled circle. These lines and symbols have to be drawn on a screen. But there are a number of aspectsto keep in mind. The most important one is that the screen has to support direct manipulation. This means thatthe user can move the elements in a sheet, but that he also can change the properties of a class or association.Another important issue is that a class can have more associations with multiple classes including the class self.Therefore the drawing of lines can be divided in a number of steps.The first one is to create an array of lines. This means that there are multiple types of controls displayed on thewindow. There is one type that has a method to set the bitmaps for the different associations. In the For..Nextloop first there is a check for visibility of the control. Deleted controls are not destroyed but hidden in thisapplication. When it is a association (relation) control it has a SetBitmaps method. This method is executed.

METHOD MakeLines CLASS WndOMTStatic

LOCAL nTeller AS WORD

SELF:aLijnen:={}FOR nTeller = 1 TO ALen(SELF:aControls)

IF IsMethod(SELF:aControls[nTeller], #SetBitmaps); .AND. SELF:aControls[nTeller]:ISVisible()

SELF:aControls[nTeller]:SetRecno() SELF:aControls[nTeller]:SetBitmaps()

AAdd(SELF:aLijnen, SELF:aControls[nTeller])ENDIF

NEXT

In the SetBitmaps method first there is a check to see whether the control is linked to a record in the database. Ifthis is so in the DO CASE there is a check for the type of bitmaps. The bitmaps are stored in two instancevariables of the relation-control. In the MSA designer it is only possible to model binary associations. In the DOCASE statement you see that most of the selections are based on the multiplicity of the associations.

METHOD SetBitmaps() CLASS OMTRelationControl

IF SELF:nRECNO>0 DO CASE CASE Upper(SELF:oMSAServer:TypeRel) = "AGGREGAT" SELF:oBitmap1:=AGGREGATE{} CASE SELF:oMSAServer:MinCard1="0" .AND. SELF:oMSAServer:MaxCard1="1" SELF:oBitmap1:=ZEROONE{} CASE SELF:oMSAServer:MinCard1="1" .AND. SELF:oMSAServer:MaxCard1="1" SELF:oBitMap1 :=ONEONE{} CASE SELF:oMSAServer:MinCard1="0" .AND. SELF:oMSAServer:MaxCard1>"1" SELF:oBitmap1:=ZEROMANY{} CASE SELF:oMSAServer:MinCard1="1" .AND. SELF:oMSAServer:MaxCard1>"1" SELF:oBitmap1:=ZEROMANY{} OTHERWISE SELF:oBitmap1:=OneOne{}ENDCASE

When the bitmaps are set for the relation control it is possible to draw the actual lines and bitmaps. This is donein the expose method of the window. The listing is given below. In a For..Next loop first the two OMT Classcontrols are stored in local variables. When both the controls of one association are stored in these local variablesthe position of the bitmaps is calculated. Because we do not want overlapping bitmaps connected to the classcontrol each bitmap has an own X position at the class control. Because associations are always binary there aretwo X positions.The next step is to calculate the Y position of the bitmaps. When to control of Class1 is above the control ofClass2 it is necessary that the bitmap of class1 is below class1 and the bitmap of class2 is above the control. Thisis done by calculation the position of the relation control compared to the two class controls. When the X and Yposition are calculeted it is possible to draw the lines based on these calculation. When the lines are drawn theposition of the bitmaps is calculated. This calculation is based on the fact that a bitmap has a certain size (16/16)amd this size has to be added or subtracted from the class control position (origin). Finally the bitmaps are drawn



and the draw objects are destroyed. This destroy was necessary in earlier versions of Visual Objects. It ishowever good programming practice to destroy the controls you created by yourself.

METHOD Expose(oEvent) CLASS WndOMTStatic

LOCAL oLine1, oLine2 AS LineObjectLOCAL X1, Y1, X2, Y2 AS INTLOCAL oBitMap1, oBitMap2 AS BitMapObjectLOCAL nTel, nContTel AS WORDLOCAL oRelPoint AS PointLOCAL oRelDim AS DimensionLOCAL oControl1, oControl2 AS Control

SUPER:EXPOse(oEvent)

FOR nTel = 1 TO ALen(SELF:aLijnen) oControl1:=NIL oControl2:=NIL FOR nContTel = 1 TO ALen(aControls) IF IsInstanceOf(aControls[nContTel], #OMTCONTROL) .AND.; Upper(aControls[nContTel]:Title) = Upper(SELF:aLijnen[nTel]:CLASS1) oControl1 := aControls[nContTel]

EXIT ENDIF NEXT FOR nContTel = 1 TO ALen(aControls) IF IsInstanceOf(aControls[nContTel], #OMTCONTROL) .AND.; Upper(aControls[nContTel]:Title) = Upper(SELF:aLijnen[nTel]:CLASS2) oControl2 := aControls[nContTel] EXIT ENDIFNEXTIF !IsNil(oControl1) .AND. !IsNil(oControl2) DO CASE CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap1, #Aggregate)

X1:=oControl1:Origin:X CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap1, #Inherits)

X1:=oControl1:Origin:X+16 CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap1, #OneMany)

X1:=oControl1:Origin:X+32 CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap1, #ZeroMany)

X1:=oControl1:Origin:X+48 CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap1, #OneOne)

X1:=oControl1:Origin:X+64 OTHERWISE

X1:=oControl1:Origin:X+80 ENDCASE DO CASE CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap2, #Aggregate) X2:=oControl2:Origin:X CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap2, #Inherits) X2:=oControl2:Origin:X+16 CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap2, #OneMany)

X2:=oControl2:Origin:X+32 CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap2, #ZeroMany)

X2:=oControl2:Origin:X+48 CASE IsInstanceOf(SELF:aLijnen[nTel]:oBitMap2, #OneOne)

X2:=oControl2:Origin:X+64 OTHERWISE

X2:=oControl2:Origin:X+80 ENDCASE



oRelPoint := SELF:aLijnen[nTel]:Origin oRelDim := SELF:aLijnen[nTel]:Size oRelPoint := Point{ oRelPoint:X + (oRelDim:Width/2),; oRelPoint:Y + (oRelDim:Height/2) } //endpoint calculaltion of the lines IF oControl1:Origin:Y > oRelPoint:Y Y1:=oControl1:Origin:Y-16 ELSE Y1:=oControl1:Origin:Y+oControl1:Size:Height+16 ENDIF IF oControl2:Origin:Y > oRelPoint:Y Y2:=oControl2:Origin:Y-16 ELSE Y2:=oControl2:Origin:Y+oControl2:Size:Height+16 ENDIF // draw the lines oLine1:=LineObject{ Point{ X1+8, Y1},oRelPoint,; Pen{ Color{ ColorBlack }, , 2 } } oLine2:=LineObject{Point{ X2+8, Y2 },oRelPoint,; Pen{ Color{ ColorBlack }, , 2 } } SELF:Draw(oLine1) SELF:Draw(oLine2)

//point calculation of the bitmaps IF oControl1:Origin:Y > oRelPoint:Y

Y1:=oControl1:Origin:Y-16 ELSE

Y1:=oControl1:Origin:Y+oControl1:Size:Height ENDIF IF oControl2:Origin:Y > oRelPoint:Y

Y2:=oControl2:Origin:Y-16 ELSE

Y2:=oControl2:Origin:Y+oControl2:Size:Height ENDIF oBitmap1:=BitMapObject{Point{ X1, Y1 }, DIMension{ 16,16 },; SELF:aLijnen[nTel]:oBitMap1 } SELF:Draw(oBitMap1 ) oBitmap2:=BitMapObject{Point{ X2, Y2 }, DIMension{ 16,16 },; SELF:aLijnen[nTel]:oBitMap2 } SELF:Draw(oBitMap2 ) oLine1:Destroy() oLine2:Destroy() oBitMap1:Destroy() oBitMap2:Destroy() ELSE SELF:aLijnen[nTel]:Hide() ENDIFNEXT

DbServer Extensions

Because we depend on the scripting logic added to the application by the use of VOScript it is necessary tochange the functionality of the default DbServer class. The internal object model of the MSA-Designer is storedin Xbase files, and therefore the DbServer class is extended. Because we want to be able to adapt the internalobject model there are a number of methods added to the inherited DbServer class. This is the abstractdbserverclass. All the classes used for storing object data inherit from this abstractdbserver class.In the listing below you see the class definition and some new instance variables. Most of these instancevariables are arrays. These are flexible and it is easy to add or remove elements from these arrays. The arrayaNewStruc is used to store information about the fields currently available in the definition. It is compared witastruc and when it is different the Dbf files are converted to the newstruc array.



CLASS AbstractDBServer INHERIT DBServer

PROTECT aInhoud :={} AS ARRAYPROTECT aNewStruc :={} AS ARRAYEXPORT aNotNullFields :={} AS ARRAYEXPORT aInitVals :={} AS ARRAYEXPORT aOrders :={} AS ARRAYEXPORT aFormFields :={} AS ARRAYEXPORT aColumns :={} AS ARRAYEXPORT aFieldDomain :={} AS ARRAYEXPORT cOOMethod :="" AS STRING

Because we want to be able to have different views on the same object model it should be possible to create a listof formfields or browser columns. The browser columns are used for the databrowsers in the application but alsofor the datalistviews. In the current paragraph you see the code that is used to create the databrowserdynamically, based on the __autocreatebrowser method of the datawindow.Also for formfields these are the fields that are displayed in a datawindow in formview it is possible to add fieldsto the array aformfields. For both arrays the order in which fields are added is important. As you can see bothmethods are straightforward. However extra functionality can be added rather easy. Think for example aboutvalidation of the fieldnames before adding the fields to the array.Because we also want to add new fields to the server object the method addfielddescription is created. Thismethod makes it possible to add a new field using a script. The method parameters are the name and descriptionof the field and the type, length and eventually decimals of the field. The method adds the field description to theanewstruc array. After that the setdatafield method is called to make the new field available to the Dbserverclass.

METHOD AddBrowserColumn(cField) CLASS AbstractDbServer

AAdd(SELF:aColumns, cField)

METHOD AddFormfield(cField) CLASS AbstractDbServer

AAdd(SELF:aFormfields, cField)

METHOD AddFieldDescription(cFieldName, cFieldCaption, cFieldDescription,; cType, nLength, nDecimals) CLASSAbstractDbServer

LOCAL oHL AS HyperlabelLOCAL oFS AS FieldSpec

oHL := Hyperlabel{ String2Symbol(cFieldName), cFieldCaption,cFieldDescription }IF cType"N"

nDecimals := 0ENDIFoFS := FieldSpec{ oHL, cType, nLength, nDecimals }AAdd(SELF:aNieuwStruc, { cFieldName, cType, nLength, nDecimals })SELF:SetDataField( ALen(SELF:aNieuwStruc), DataField{cFieldName,oFS } )

Often you can make the users of your application happy by the usage of initial values. Initial values reduce a lotof typing for users, and offer a sort of guidance in using the application. The method addInitVal connects a fieldwith an initial value. Currently the initial values are static, dynamic initial values by the usage of functions arenot possible yet.In the append method you see how the initial value is stored in the field by using fieldput. Here you see theadvantage of using an array. Because the dynamic nature of an array it is easy to add more initial values for thisabstractdbserver.

METHOD AddInitVal(cField, xInit) CLASS AbstractDbServer

AAdd(SELF:aInitVals, { cField, xInit })



METHOD Append() CLASS AbstractDbServer

LOCAL lRet := TRUE AS LOGICLOCAL nTel AS WORD

lRet := SUPER:Append()IF lRet = TRUE FOR nTel = 1 TO ALen(SELF:aInitVals) SELF:FIELDPUT(SELF:aInitVals[nTel][1], SELF:aInitVals[nTel][2]) NEXTENDIF

RETURN lRet

Default values for a field is one aspect of importance for the MSA designer. But one other aspect is alsoimportant. This is the validation of null/not null values in fields. There are a number of properties in each objectof the MSA object model that must be filled in. Otherwise it is impossible to distinguish this property from otherproperties or it is impossible to create source code or a database definition. I have tried to generalise thisfunctionality by moving the check for null/not null to the abstractdbserver class. This makes it possible to makethis behaviour default, but also it is now accessible for scripting.In the listing below you can see that the field is added to an array of fieldnames. In the method controle wetraverse the array of not null fields. When the field has a null value the hyperlabel caption is concatenated to astring of field captions. After the traversal of the array there is a message displayed with all the fieldnames notfilled in. I think it is really annoying when you get a message that field A is not filled in, you fill in field A andthe next message Field B is not filled in appears, etcetera.In the datawindow class an extra function is added. This function adds an asterisk to the field caption. In thefigure in paragraph adapted __autolayout you can see a sample of this function.

METHOD AddNotNullField(cField) CLASS AbstractDbServer.

AAdd(SELF:aNotNullFields, cField)

METHOD Controle() CLASS AbstractDbServer

LOCAL lRet:=TRUE AS LOGICLOCAL nTel AS WORDLOCAL aVelden:={} AS ARRAYLOCAL cVelden:="" AS STRING

aVelden:=SELF:aNotNullFieldsFOR nTel = 1 TO ALen(aVelden) IF Empty(SELF:FIELDGET(aVelden[nTel])) cVelden+=SELF:FieldSpec(aVelden[nTel]):Hyperlabel:Caption+", " lRet:=FALSE ENDIFNEXT

IF lRet = FALSE TextBox{ ,"Not filled in are:", cVelden }:Show()ENDIF

RETURN lRet

In a number of cases the user is allowed to enter a certain number of values in a property. This means that aproperty has a domain. For example a property of a class can be of the following types: Export Protect Hidden



This means that no other values are allowed. This functionality is moved from the datawindow to theabstracdbserver for the same reasons as mentioned above, generic behaviour and scripting. In the source codebelow you see that it is possible to add a field and a domain. This domain is of type usual. It can be a characterstring with the name of a DbServer class or an array with static values.In the method getfielddomain the return-value is an array based on a static array as it is stored in afielddomain,or it is based on an array loaded from a dbserver class and the method getlookuptable() that is extended for thebehaviour in our application, display field and key field are properties for the abstractdbserver class.

METHOD AddFieldDomain(cField, xDomain) CLASS AbstractDbServer

AAdd(SELF:aFieldDomain, { cField, xDomain })

METHOD GetFieldDomain(cVeld) CLASS AbstractDbServer

LOCAL aRet:={} AS ARRAYLOCAL nPos:=0 AS WORDLOCAL oServer AS AbstractDbServer

nPos:= AScan(SELF:aFieldDomain, { | a | a[1] = cVeld })IF nPos>0 IF IsString(SELF:aFieldDomain[nPos][2]) oServer:=CreateInstance(String2Symbol(SELF:aFieldDomain[nPos][2])) aRet:=oServer:GetTableLookUp() oServer:Close() ELSE aRet := SELF:aFieldDomain[nPos][2] ENDIFENDIF

RETURN aRet

Adapted __autolayout

Because the user of the MSA-Designer has a view on the object model that depends on the phase of themethodology, the information displayed has to be adaptable, cg extendable. Creating a number of datawindowsfor each class in the MSA object model can solve this. But there a number of disadvantages in this strategy. Firstevery extension of the object model means adapting a number of datawindows. Second is that the extensionsmade by the user to the object model will never be visible in the datawindows.For that reason I changed the behaviour of the __autolayout method of the datawindow. The __autolayoutmethod is called when there are no controls on the datawindiow. In the SDK the source code of the method isavailable. In the figure you see the adapted layout.



Because we use the Abstractdbserver class with all the extra functionality the autolayout can give the user moreinformation. For example the not null properties have an * in their caption and the properties with a domain aredisplayed in a combobox. In the source code below you see how this is implemented.The first step is to see if there is an array of fieldnames for this datawindow. If not an array of fieldnames isretrieved from the abstractdbserver. The next step is to calculate the height of the datawindow. Visual Objectshas an X..Y implementation where X = 0 and Y = 0 is in the left bottom corner but users read from top to bottomTherefore we first have to calculate the X position of the first (top) control. The size and number of controls arepart of this calculation as you can see in the for..next loop.In the second for next loop we traverse the array of fields. Based on the type of the field, the availabity of adomain and the size of the field different controls are created. The interested reader should take a closer look atthe calculation of the point (origin) for each control. This calculation is based on an edit-height and edit-gap. Thecombination of these variables makes it possible to change the layout of your datawindow.

METHOD __AutoLayout() CLASS StdDataWindow// this is a sample, it does not describe the full code of this method// see the sample programme for details

IF ALen(aVelden) = 0 SELF:aVelden:=SELF:Server:GetFormFields()ENDIFFOR liField := 1 UPTO ALen(SELF:aVelden) oDFField := SELF:Server:DataField(aVelden[liField])

cType := oDFField:FieldSpec:ValType IF (cType != "O") .or. lOleAvail liHoogte+=EditGap cField := oDFField:FieldSpec:Hyperlabel:Caption oDimension := oSurface:SizeText(cField) IF (oDimension:Width > maxLblSize) maxLblSize := oDimension:Width



oLabelDim := oDimension ENDIF IF (cType == "M") liHoogte+=(1.5 * EditGap) ELSEIF (cType =="O") .and. lOleAvail liHoogte+=(6 * EditGap) ELSE maxFldSize := Max(maxFldSize, oDFField:FieldSpec:Length) ENDIF ENDIFNEXT

MaxFldSize:=Min(80,maxFldSize)liField := 0maxEditSize := (maxFldSize+21) * TextMetric.tmAveCharWidthoPoint:=Point{ 20,120}oPoint:X := IIf(lBidi, (25 + maxEditSize), 20)

FOR liField:=1 UPTO ALen(aVelden) oDFField := NULL_OBJECT oDFField := SELF:Server:DataField(aVelden[liField]) cType := oDFField:FieldSpec:ValType

IF (cType != "O") .or. lOleAvail cField :=oDFField:FieldSpec:Hyperlabel:Caption

IF (lBidi) oPoint:X := 20 + maxEditSize - ((liFieldLen+1) *; TextMetric.tmAveCharWidth) ELSE oPoint:X := 25 + maxLblSize ENDIF liFieldLen := __GetFSDefaultLength(oDFField:FieldSpec)

oPoint:Y := liHoogte - EditHeight liHoogte -= EditGap

DO CASE CASE cType=="M" oPoint:Y := oPoint:Y - (1.5 * editGap) liHoogte -= (1.5 * editGap) newControl := CaptionMultilineEdit{SELF, 200+liField, oPoint,; Dimension{(50*TextMetric.tmAveCharWidth)+liCaption,; editGap*2.5 - 6}, } OTHERWISE aTemp:=SELF:Server:GetFieldDomain(aVelden[liField]) DO CASE CASE ALen(aTemp)>0

newControl := CaptionComboBox{SELF, 200+liField, oPoint,; Dimension{(35*TextMetric.tmAveCharWidth)+liCaption,; editHeight}, ,liStyle}

nX:=NewControl:Origin:XnY:=NewControl:Origin:Y - 60

IF nY>0 nHoogte:=NewControl:Size:Height+60 nLengte:=NewControl:Size:Width NewControl:Origin:=Point{ nX, nY } NewControl:Size:=Dimension{ nLengte, nHoogte } ENDIF NewControl:FillUsing(aTemp) OTHERWISE



IF (cType == "C") iNewWidth := (liFieldLen * TextMetric.tmAveCharWidth) +;

liCaption ELSE iNewWidth := (10 * TextMetric.tmAveCharWidth) + liCaption ENDIF IF (iNewWidth < iMaxWidth) newControl := CaptionSingleLineEdit{SELF, 200+liField,; oPoint, Dimension{iNewWidth, editHeight}, liStyle} ELSE newControl := CaptionSingleLineEdit{SELF, 200+liField,; oPoint, Dimension{iMaxWidth, editHeight},liStyle} ENDIF ENDCASE ENDCASE newControl:LinkDF(SELF:Server, SELF:Server:FieldPos(aVelden[liField])) newControl:Show() oPoint:X := IIf(lBidi, (25 + maxEditSize), 20) ENDIFNEXTSELF:Server:GoTo(nPos)

oFormFrame:__ResizeParent()RETURN SELF

For the databrowser there is an autolayout like method available for datawindows. This method__autocreatebrowser generates a default databrowser when there are no columns defined in the datawindow. Thesource code is available in the SDK. It can be adapted easily to fulfil your own needs. In the MSA applicationthe user can adapt the order and number of columns for the databrowser by using scripting. In theabstractdbserver class a list of column-names is available for the databrowser.In the listing below you see that the array of columnnames is traversed. For each field a column is created. Whenthe field has a domain this column is based on a codeblock. This codeblock contains a method for theabstractdbserver that retrieves a display item based on the contain (key) of the field. The suspendupdate andsuspendnotification methods are called for performance issues.

METHOD __AutoCreateBrowser() CLASS WndBrowse

LOCAL wTel AS WORDLOCAL oCol AS DataColumnLOCAL aVeld:={} AS ARRAY

SELF:Browser := AbstractDataBrowser { SELF}SELF:Server:SuspendNotification()aVeld:=SELF:Server:GetBrowserColumns()SELF:Browser:SuspendUpdate()FOR wTel = 1 TO ALen(aVeld) IF SELF:Server:FieldPos(aVeld[wTel])>0 .AND.; SELF:Server:FieldSpec(aVeld[wTel]):Valtype"M" IF SELF:Server:IsFieldDomainStatic(aVeld[wTel]) oCol:=DataColumn{30} oCol:Block :=; &("{ | oS | oS:GetDisplayValue(["+aVeld[wTel]+"],; oS:FieldGet(["+aVeld[wTel]+"]) }" ) oCol:Caption:=; SELF:Server:FieldSpec(aVeld[wTel]):HyperLabel:Caption oCol:BlockOwner := SELF:Server ELSE

oCol:=DataColumn{ Max(20,; SELF:Server:FieldSpec(aVeld[wTel]):Length),; SELF:Server:FieldSpec(aVeld[wTel]):HyperLabel } ENDIF



SELF:Browser:AddColumn(oCol) ENDIFNEXTSELF:Browser:Use(SELF:Server)SELF:Server:ResetNotification()SELF:Browser:RestoreUpdate()



Summary

Computer Aided Software Engineering is essential for large and complex software development projects. Well-applied CASE will reduce the development time of a project and the quality of the final product will be better. ACASE tool can assist you in applying an OO CASE methodology. In this session a description is given of theMSA designer. This tool supports two OO development methods Merode and OMT. The tool supports thenotation, but also the methodological process of the two methodsThe MSA designer is developed in CA-Visual Objects. CA-Visual Objects has proven to be extremely suitablefor this development process. It has a good class hierarchy to access data in various databases systems. It ispossible to extend and adapt the behaviour of the user interface. And final it offers maximum flexibility whenscripting is added to the application.



Further reading

1. Bertenshaw, M. Datadriven programming under VO, SDGN, Winterswijk, In Conference to the Max 1997,1997.

2. Bigs, P., A Survey of Object-Oriented Methods, Univerity of Durham, (Internet Site).

3. Blaha, M. & W. Premerlani, Object-oriented modeling and design for database applications, Prentice Hall,Englewood Cliffs, 1997.

4. Boersma, T., Bedrijfsobjecten implementeren met behulp van VO, SDGN, Winterswijk, In: Conference tothe Max 1996, 1996.

5. Booch, Grady, Object oriented analysis and design with applications second edition, Cumming publishing,Redwood, 1994.

6. Booch, Grady, Ivar Jacobson, and James Rumbaugh, Unified Modeling Language Use Guide, UnifiedModeling Language Reference Manual, and The Objectory Software Development Process, , In: TheAddison-Wesley Object Technology, Wokingham.

7. Brinkkemper, S. et al, Method Engineering Encyclopedia, TU Twente, (internet site).

8. Carmichael, Andy, Object Development Methods, SIGS Books, New York, 1994.

9. Computer Associates, CA-Visual Objects getting started guide, Computer Associates, Islandia, 1996.

10. Cooper, A., About face: The essentials of user interface design, IDG Books, Foster City, 1995.

11. Fowler, Martin, Analysis patterns: Reusable Object Models, Addison Wesley, Reading, 1997.

12. Gamma, Eric et al, Design Patterns: Elements of Reusable Object Oriented Software, Addison Wesley,Reading, 1995.

13. Ghezzi, C. M. Jazayeri & D. Mandrioli, Fundamentals of software engineering, Prentice Hall, EnglewoodCliffs, 1991.

14. Informatie Management Nederland, IMNs drielagen architectuur, Informatie Management Nederland, z.p.,z.j..

15. Jacobson, I & M. Christerson, P. Jonsson, G Overgaard, Object Oriented Software engineering, a user casedriven approach, Addison Wesley, Wokingham, 1992.

16. Kilburn, J., Data-Driven programming in CA-Visual Objects, Computer Associates, Islandia, In: CATechnicon 1997, 1997.

17. Lazzaratto, P., Implementing Data-Driven Classes with CA-Visual Objects 2.0, Computer Associates,Islandia, In: CA Technicon 1997, 1997.

18. Lemmen, K.A.M. et al, Methodologie van informatiesysteemontwikkeling, Open universiteit, Heerlen, 1993.

19. Microsoft Press, The windows interface guidelines for software design, Redmond, 1995.

20. Power, J., Datadriven programming, SDGN, Winterswijk, In: Conference to the Max 1996, 1996.

21. Rumbaugh, J, M. Blaha , W. Premerlani, F. Eddy & W. Lorensen, Object oriented modeling and design,Englewood cliffs,1991.

22. Straley, S.J. CA-Visual Objects Encyclopedia, Sirius Press, San Francisco ,1997.



23. Straley, S.J. CA-Visual Objects for Clipper and xBase programmers, Addison Wesley, Reading, 1995.

24. Spence, R. CA-Visual Objects, Sybex, San Francisco, 1995.

25. Williams, J., What every software manager must know to succeed with object technology, Sigs books, NewYork, 1995.

26. Wynn, E. Advanced Data Server handling in CA Visual Objects, Computer Associates, Islandia, In: CATechnicon 1997, 1997.

About the Author

Bert has a masters degree in informatics. He started programming in 1990. First in CA-Clipper later he gotaddicted to CA-Visual Objects. At the moment he is working as an application controller for BJZU in Utrechtthe Netherlands. He is developing applications with CA-Visual Objects, Powerbuilder/Sybase and MS-Access.Besides programming he loves to make long walks through Europe or listens to Jazz music. Bert can be reachedat [email protected]

Documents

Building a CASE Tool in CAVO