COMMERCIAL AND PROFESSIONAL APPLICATION DEVELOPMENT
Part Three - The Conceptualization Process
INTRODUCTION:
And here we are, the 3rd part of this series. What exactly can you expect in this section? Well let's start by stating what you would typically have before arriving to this section. In theory, you would have your analysis documents (the 3 of them) completed, you would have gotten the solution discussed and approved by management and everything is ready to go to the next step of the development cycle. What is that next step? It's called Conceptualization phase, and entails the beginning of the creation of the proposed solution as it is defined in the detailed analysis and the solution proposal document. Since any flow of information between process steps and between departments in the company (if need be) have been defined in the detailed analysis, you should be ready to go on and start to create the solution. In this 3rd part of the series, we'll cover all you need to know about the conceptualization phase, what it is, what tools are available to you during this phase, and some good practice to use throughout the process.
By the end of this 3rd part, you will be well equipped with the knowledge you need to conceptualize an idea into a workable solution ready for the development phase (which we'll cover in the next part of this series). So indeed, there's alot of ground to cover here. Grab your favorite drink and let's get started shall we?
WHAT IS THE CONCEPTUALIZATION PHASE:
In the software engineering field, conceptualization is taking everything in the analysis and building a solution from all the information gathered in the analysis phase. Of course, as I mentionned in the previous section, there are many ways to arrive at that, and each of those ways involve a different point of view on the creation of the solution. I'm not going to detail each method again here, you can review them here. if you recall, I mentionned that we would be using UML (Unified Modelling Language) for our project, and that is exactly what we will be doing here.
Is there a preferred order of things that can work better than others? Many software engineers might argue on this. Me, I tend to use somewhat of a top to bottom approach in that I'll start with the bigger, more complex objects (which are usually objects that are made of other objects) and work my way down to each object that the bigger objects are made of. The reason I work in this order is it gives me a bigger picture so to speak and i can work on the relationships between the objects as I break them down. Since we'll be using UML as our tool, actually, we'll be using a text version of UML which means that I'll be describing the objects as text as well as the relationships between the objects. This is a quicker method than going into some application and creating UML diagrams. And it can be done in notepad or your favorite text editor. Let's start by covering what UML is and what it allows to do to familiarize ourselves with it.
UNIFIED MODELING LANGUAGE BASICS:
U.M.L. is a language that used to describe a problem based on the entities involved, howw to describe these entities (properties) and what those entities can do (methods). UML also alows to describe the relationship between each entity. It doesn't stop there however, UML is also used to describe Organization Diagrams, Use Case Scenario diagrams, Activity and State diagrams, and Static and Dynamic Model (class) diagrams, Sequence Diagrams (to explain certain ordered steps), Collaboration diagrams (where more than one process need to work together to get a given job done) as well as a whole bunch of other types of diagrams that are useful when modeling a solution from start to finish.
For some reference you can take a look at Allen Holub's UML Quick Reference which details all the types of diagrams that are available in UML as well as examples on what those diagrams can look like. Also you can take a look at the UML 2.0 Superstructure Final Adopted specification. With these documents at hand, you'll be equipped to tackle any conceptualization model you would be likely to encounter.
I need to add a distinction here. In many cases, people tend to confuse the concept of composition versus the concept of aggregation. So I will explain these two right here to a bit of clarity. Here they are:
- Aggregation: An Aggregation represents a whole entity that comprises other parts. For example: a committee is an aggregate of it's members. However, in the case of an aggregation a commitee does not contain it's members per se.
- Composition: A composition, unlike the aggregation, has everything to do with containement. For example, a horse is a mammal, and will never have a reason to be nothing else but a mammal, therefore, a mammal contains a horse.
With all this in mind, you can see that UML can be a very powerful tool to add to your arsenal of software engineering tools for more than one reason. For the sake of this example, we'll be using what I called a text version of UML as in there will be no diagrams. The description of objects will be nade in a textual, almost pseudo code like even, because when you look at an object class model diagram, that's exactly what you're seeing for an object is all it's properties and methods listed and described. If the need for a sequence or a collaboration diagram is needed in our description I will use lists or paragraph describing the sequence and/or collaboration. This way you should be able to see clearly what should be going on in an object. Also as mentionned, I will start with the bigger objects and clearly state what the object is composed of. the components of the objects will be detailed later in the scripted UML model.
FINANCECAD SCRIPT BASED OBJECT MODEL:
To start this model, I will begin at the highest possible level of FinanceCAD, the Application itself. Indeed the FinanceCAD Application can definitaly be thought of as an object, a very complex object that comprises everything else in the project.
ENTITY FinanceCAD
PROPERTIES:
ApplicatioNPath Text
VersionMajor Numeric
VersionMinor Numeric
VersionRevision Numeric
VersionRelease Character
VersionStamp Text
METHODS:
CreateNewDesign <- DesignName Text
OpenDesign <- FileName Text
SaveDesign <- FileName Text
PrintDesign <- PrinterNumber Numeric
COMPONENTS:
OBJECT Canvas <- The main Drawing Canvas
OBJECT DatabaseEngine <- File and database functionality
OBJECT PrintingEngine <- Printing functionality for the design
OBJECT ReportEngine <- Printing Functionality for the reports
OBJECT NetworkEngine <- Detection and access to the network folders
OBJECT ImportExportEngine <- Import and Export for the design and the reports
RELATIONSHIPS:
No relationship at this level of refinement.
END ENTITY
So far it's not too long is it? There's a median to reach when you are describing a problem using this approach. For the sake of our example here, there's no need to go into any more details, at the application level, than to list what the general components of the application would typically be. As you can see from this first description, things can become obvious quite quickly using this description method. You described the Application just as you would any other type of object. All Objects have qualities and properties that describe them, they also have actions that they can perform. Just by saying what the object looks like, and what it can do, you end up with a pretty complete description of the object itself. Take a look at the Canvas object defined below, you'll see what I mean when I say a complete picture.
OBJECT Canvas
PROPERTIES:
FileName Text
UnitOfMeasure Numeric
Scale Numeric
NumberOfShapes Numeric
Layers List
METHODS:
Create <- The constructor, called when object is initialized
Destroy <- The destructor, called when object is destroyed
SetUnitOfMeasure <- NewUnitOfMeasure Numeric
SetScale <- NewScale Numeric
ClearCanvas
RefreshCanvas
AddCircle <- Layer Numeric, Radius Numeric
AddEllipse <- Layer Numeric, Ratio Numeric
AddArc <- Layer Numeric, Ratio Numeric, Length Numeric
AddSquare <- Layer Numeric, Length Numeric
AddRectangle <- Layer Numeric, Height Numeric, Width Numeric
AddTriangle <- Layer Numeric, TriangleType Numeric, Lengths() Numeric
AddHexagon <- Layer Numeric, SideLength Numeric
AddOctogon <- Layer Numeric, SideLength Numeric
AddLine <- Layer Numeric, X1, Y1 Numeric, X2, Y2 Numeric
RELATIONSHIPS:
One To Many -> Circle Object
One To Many -> Ellipse Object
One To Many -> Arc Object
One To Many -> Square Object
One To Many -> Rectangle Object
One To Many -> Triangle Object
One To Many -> Hexagon Object
One To Many -> Octogon Object
One To Many -> Line Object
DESCRIPTION:
The Canvas object is where the drawing of the design actually occurs. It
is composed of a drawing area and a command processor (to get and process
all the different commands that would typically be entered. The One To
Many relationships to the different Shape Objects are because Shapes are
added to the canvas rather than just drawn. This way, each shape can be
treated as an independant entity and moved independant of the other shapes
on the given design.
END OBJECT
The first thing to notice here is how I categorized each descriptive element. this method is the one I prefer to describe a physical object in an application hierarchy. I'm not going to define the Circle, Ellipse and the other basic objects for this example. Just remember that when describing a different scenario (typically when you are modelling a manual process) it will be a good idea to define each little element that make up a given object. In this case the Circle object and the other shapes would be defined in the same fashion as the canvas objects with the properties section, the methods, relationships and so on.
We'll just go down the list of objects in the order they have been defined in our application entity. As such, here's the definition of the DatabaseEngine object:
OBJECT DatabaseEngine
PROPERTIES:
DatabasePath Text
ConnectionString Text
ConnectionMade Boolean
TableCount Numeric
TableList List Table Objects
METHODS:
Create <- The constructor, called when object is initialized
Destroy <- The destructor, called when object is destroyed
ConnectToDB <- ConnectionString Text, DBPath Text
ValidatePath <- PathToValidate Text
OpenTable <- TableName Text
ExecuteQuery <- QueryToExecute Text
InsertRecord <- RecordData Text
UpdateRecord <- RecordData Text
DeleteRecord <- RecordNumber Numeric
FindRecord <- Criteria Text
RELATIONSHIPS:
One To One -> NetworkEngine Object
DESCRIPTION:
The DatabaseEngine as defined here is not a Database Management System
but rather a wrapper that connects to the existing database engines via
the ODBC database connectivity library. Each method will therefore
portray a function calling to the inner ODBC functions in the actual
coding phase. The relationship to the Network Engine is for validating
the actual path to the global database and assure proper connection
between the the Database Engine and the physical location of the
database itself as well as validating the existence of the network
printers and plotters to print the designs and the reports.
END OBJECT
And that was the DatabaseEngine object definitions. As you go along refining the object model when issues get solved and questions get answered, you may want to add to this model. For example, maybe you'll find you need more properties in the list of properties depending on what the users know that they need to get access to the database. Perhaps the ability to specify a username and a password to the ConnectDB method rather than the way it's designed right now. You need to remember that typically you are at the start of the conceptualization phase and that you may as the modelling moves along, move properties and methods around to other objects perhaps for whichever reason. Just remember that you need to have an open mind at this stage of conceptualization. Things can and will change in your model and knowing that in advance can influence the initial design to be as open and flexible as it needs to be to allow for these changes. As a quick note, you can see I named the constructor and the destructor the same name as the canvas object. It's good practice to name functions that perform the same things by the same name not just in the conceptualization phase but throughout the whole development cycle all the way to the source code as well. This way you know that Create will always create and initialize the object no matter what that object is.
Likewise, the PrintingEngine Object is defined as any other objects it has properties and methods that will be used by the main application object at will to get things in output format. A typical definition for a printer object could be as follows:
OBJECT PrintingEngine
PROPERTIES:
PlottingJobs List
PlotterList List
JobCount Numeric
HasJobsToDo Boolean
METHODS:
Create <- The constructor, called when object is initialized
Destroy <- The destructor, called when object is destroyed
DetectPlotter <- PlotterToDetect Text
InitializePlotter <- PlotterToInitialize Text
AddToJobs <- JobNumber Numeric, FileName text
PrintFirstInList <- No Parameters, will print the first job in list
RELATIONSHIPS:
One To One -> NetworkEngine Object
One To Many -> ReportEngine Object
DESCRIPTION:
The PrintingEngine as defined here is a central object where all
printing jobs are passed. This object will determine the type of
document that is being requested for printing, determine where it
should be printed (Physical location of the plotter) and send the
job to there to be printed. It does nothing to the actual
design file itself other than send it to be printed. The One to
One relationship to the NetworkEngine object is to detect the
presence of the plotter that has been configured by the design.
The One to Many relationship to the ReportingEngine Object is
because when the user prints a design he or she could want to
print more than one report for the cost of the design itself.
END OBJECT
There you have it, the PrintingEngine Ojbect as you can see is the object that manages and prints The Design file itself. In the description part is where you defined the exact relationship between the object as I've done here. it will help the coding phase alot to know why a relationship is defined. Notice how every object is defined using the same structure no matter what it's role is. That's the beauty of this method. Consistency in structure will help you, and everyone that needs to see the model, quickly learn how to read the model and where to locate vital information they will need in their part of the project.
To continue with our modeling, as per our list of components in the Application definition the next object on our list is the ReportEngine Object. So then, let's define that one right now:
OBJECT ReportEngine
PROPERTIES:
PrinterJobs List
PrinterList List
JobCount Numeric
HasJobsToDo Boolean
METHODS:
Create <- The constructor, called when object is initialized
Destroy <- The destructor, called when object is destroyed
DetectPrinter <- PrinterToDetect Text
InitializePrinter <- PrinterToInitialize Text
CreateSummaryCost <- DesignFile Text
CreateDetailCost <- DesignFile Text
AddSummaryJob <- JobNumber Numeric, FileName text
AddDetailJob <- JobNumber Numeric, FileName text
PrintFirstInList <- No Parameters, will print the first job in list
RELATIONSHIPS:
One To One -> NetworkEngine Object
Many To One -> PrintingEngine Object
DESCRIPTION:
The ReportObject takes care of all the paperwork related to a given design
file. the user will have 2 choices when requesting a report to be printed
with a design. He or she can have a sumarry report (usually used inhouse
for quick evaluation of costs) and a detail report (usually used both
inhouse and sent to the client for aproval purposes. The two reports are
added to the same list of print jobs as they will typically be sent to the
same printer. The One to One relationship to the NetworkEngine Object is
to validate the existence of the physical printer on the network. The
Many to One relationship to the PrintingEngine is because the reports that
are offered here are only available when printing a design (an optional
checkbox may be added to select to print just the design, the design and
the report, or just the report, but they will all originate from the same
print dialog).
END OBJECT
The good part of this type of definition is let's say the users, even at this stage of the conceptualization process, decide they want another type of report, all you have to do is add an Add____Job method (these will be defined at the coding phase). The model can stay as abstract as needed to isolate itself from the actual coding of the application this way. By tracing this line between the conceptualizaton and the coding phase, it's easier to set a limit to when the conceptualization phase will end and when the coding phase will begin. Note that so far there are no screens or any visual aspects defined at this stage either. You'll see why in the next section, the coding phase of the development cycle. But let's just say here that the coding phase is and should be split into two sub-phases, The design phase and the programming phase.
Moving right along in our model, the next object to attack is the NetworkEngine Object. Before we begin the model, just keep in mind one thing. Unlike the rest of the objects here, the NetworkEngine object is an independant object in that it doesn't need the other object to execute itself, however, there are relationships because the other objects of the application will give the NetworkEngine object it's purpose of existence. So let's define this object and we'll see what I am talking about:
OBJECT NetworkEngine
PROPERTIES:
DriveCount Numeric
ListOfDrives List
PrinterCount Numeric
ListOfPrinters List
PlotterCount Numeric
ListofPlotters List
IsNetworkPresent Boolean
METHODS:
Create <- The constructor, called when object is initialized
Destroy <- The destructor, called when object is destroyed
GetListOfDrives <- No Parameters, gets list of network drives
SetDriveCount <- Count Numeric
ValidateDrive <- DriveIndex Numeric
GetListOfPrinters <- No Parameters, gets list of available printers
SetPrinterCount <- Count Numeric
ValidatePrinter <- PrinterIndex Numeric
GetListOfPlotters <- No Parameters, gets list of available plotters
SetPlotterCount <- Count Numeric
ValidatePlotter <- PrinterIndex Numeric
RELATIONSHIPS:
Many To One -> Canvas Object
Many To One -> DatabaseEngine Object
Many To One -> PrintingEngine Object
Many To One -> ReportEngine Object
DESCRIPTION:
The NetworkEngine Object is an object that performs all necessary validation
against the network in order to get all the valid drives, printers and the
plotters that are available on the network. The list of drives will contain
the physical Drive Letter, the logical Drive number, and the network path
to the physical hard disk. The list of printers will contain printer
relevant information such as printer path, shared name, and the likes. The
same goes for the list of plotters. The printers and plotters will be
initially determined by the printer drivers installed on the user's machine
then validated against the printer and plotter list on the network.
All of the many to one relationships are established because the Canvas,
DatabaseEngine, PrintingEngine and ReportEngine will use the NetworkEngine
to determine the existence and validity of the drives, databases, printers
and plotters that were configured at the application level (hence on the
user's installation of the FinanceCAD Application).
END OBJECT
In most cases, a One to Many relationship determines that the modeled object has one or more of the related object. This is know as a "has a" relation. When you encounter a Many to One relationship usually indicates that the modeled object uses the related object. This is called a Uses relationship. This can mean that it uses the related object or is used by the related object. To know which of the two is entailed, you'll need to look at the related object's relationships section and the description.
One more object to worry about, it is the ImportExportEngine object. If you remember in the previous section, there was mention that the design, and the attached reports have the ability to be exported into more well known file formats for compatibity purposes. In this object I'll introduce sequences (or order in which steps are to be performed) and how to define them in the definition of the given object. So then, Here is the definition of the ImportExportEngine object:
OBJECT ImportExportEngine
PROPERTIES:
ImportFormats List
ExportFormats List
FileName Text
FileType Numeric
ImportFormat Numeric [Index to the Import File Format]
ImportCompleted Boolean
ExportFormat Numeric [Index to the Export File Format]
ExportCompleted Boolean
METHODS:
Create <- The constructor, called when object is initialized
Destroy <- The destructor, called when object is destroyed
ImportFromDXF <- DXFFileName Text [Autocad Data eXchange Format]
ImportFromWMF <- WMFFileName Text [Windows Meta File Format]
ImportFromTHREEDS <- THREEDSFileName Text [3D Studio file format]
ExportToDXF <- DXFFileName Text [Autocad Data eXchange Format]
ExportToWMF <- WMFFileName Text [Windows Meta File Format]
ExportToTHREEDS <- THREEDSFileName Text [3D Studio File format]
ExportToDOC <- DOCFileName Text [Microsoft Word Format]
ExportToWPD <- WPDFileName Text [Word Perfect File Format]
ExportToPDF <- PDFFileName Text [Adobe Portable Document File]
ExportToRTF <- RTFFileName Text [Microsoft Rich text Format]
ExportToHTML <- HTMLFileName Text [HTML 4.01 Compliant format]
ExportToTXT <- TXTFileName Text [Standard ANSI Text File]
ExportToCSD <- CSDFileName Text [Comma Seperated File Format]
ExportToXLS <- XLSFileName Text [Microsoft Excel Spreadsheet]
ExportToWKS <- WKSFileName Text [Lotus File Format]
ExportToDBF <- DBFCFileName Text [X-Base compatible format]
SEQUENCES:
Importing from a format
1. Select the file to be imported
2. Determine format based on file extension
3. Perform the import
Exporting to a format
1. Select a file from the list of files
2. Select the desired output format
3. Perform The export
RELATIONSHIPS:
Many To One -> Canvas Object
One To One -> NetworkEngine Object
DESCRIPTION:
The ImportExportEngine object is created at the start of the application
and available live from the main application object. when a Design is
created, or opened, the ability to export the design itself or the reports
are also made available for direct access to it's functionality. This way
the user can export the design and/or the reports anytime he or she wishes
to do so. The many to One relationship with the Canvas object is defined
because Any of the open Canvas Objects (hence any Opened design files) can
be exported. The One to One relationship with the NetworkEngine Object is
present for drive and folder validation purposes only.
END OBJECT
You can see that I used file extension as a mean to differentiate the different file formats I plan on being compatible to for the design file and for the reports as well. You can also see that I don't import anything for the report files as only exporting of our reports are necessary. Here to the constructor and destructor of the object are named the same as all other objects for familiarity and the beginning of a certain naming convention that can be followed all the way through the coding phase. As you can see, sequences are nothing more than an ordered enumeration of what needs to happen in what order, simple as that really. And that goes for any model that may need any type of ordered list of objects or list of actions to take.
And there we have it, the modeling is completed. we've defined our application object and it's 6 components. In the coming section we'll see what we can extract, as far as notions are concerned, from the model as well as some special considerations and notes that need to be mentionned for all your modeling projects.
CONCEPTUALIZATION CONSIDERATIONS:
As I mentioned before, this model is rudimentary and at the surface level of the objects it models. The goal here is to teach you what modeling is and I believe this top level of refinement is more than adequate to show you how it's done. In a typical scenario however, you would be modeling everything from the top level down to the bottom levels of an object hierarchy. To know how low a level you need to go to, you just need to know where your entities end and when you can only talk of properties and methods of your entities. When you can no longer define an entity as having sub entities (objects) then the hierarchy is complete and so is the levels of refinement of your model. It's the best trick I can give you.
The order where I defined the methods is important in this model. the only Object I have defined sequences for is ImportExportEngine object. In the case of the other objects, if a certain order of things is needed, they can be define simply by the order in which the methods are defined in each object. The specific order of things are usually defined either in the user requirements document (when the order are ordered set of steps or commands to get towards the accomplishment of the desired function). or the detailed analysis document (when the order of things are steps to execute a given process).
This is why it's important to be prepared before entering the conceptualization phase. As you can see here, when you have all the documents you need, before you enter the conceptualization phase of the development cycle, you have all the information and tools you need to get through the conceptualization phase as straightforwardly and as smoothly as it can possibly be. And since this phase is a big part of the development cycle, I would urge you to take the time to be as prepared as you can be before you start the conceptualization phase. You'll thank yourself later.
A WORD OF CONCLUSION:
That was a big load to digest wasn't it? Well, when you have the right notions, it is a big job to conceptualize, but it can be quite rewarding as well, when you are well prepared, you'll find out that this phase will be invalluable for the rest of the development cycle. I can't stress enough that the key to this phase, and absolutely all phases of the development cycle (as defined in the 1st part of this series) is to be prepared. If you take the extra time to ask the right questions, you'll get the right answers to work with. This is true for all phases. There are types of projects that for some reason are harder to gather a complete range of information than others. This is usually a sign that the application will need to consider adaptability in the process. For example, many reporting systems may not know, in advance the whole list of reports it will need to create. In this case, being prepared means you have a list of report as are currently known. Adapability means the reporting engine is designed to accept new reports as if they were always part of the list of reports and therefore can be as integrated to the system as the known reports would be. There are other situation where it's difficult at best to acquire a complete list of specifications or list of reports, or list of things that will need to be implemented as well. But again asking the right questions in this case will tell you, atleast, that what you have is incomplete and should be made to grow. This is also called programming for the future.
And that's it for this part of the series. I hope you enjoyed it, and especially, I hope you learned what I tried to teach in this document. Remember, as always that I am there to answer questions as well as for comments and suggestions so email me with any concerns or discrepencies in what you've learned so that we can clear things up together. AS such, a note must be made that the contents might change if I get enough requests to make certain parts of this document clearer than they already are. In the next section we'll attack the coding phase in all it's glory. We'll see why being prepared is important at that phase too, just like all other phase of the development cycle, and we'll see all the special consideration we'll need in that phase. Happy reading and see you then.
Stephane Richard (MystikShadows)