Using conceptual models to illustrate software
Keeping up? In this simple post I want to remind you (yes again) that for this course when we’re talking technology we’re primarily concerned with software elements of ebusiness. For our purposes as managers we can simplify (abstract) the picture and worry less about hardware. A hardware technician can worry about the gory technical details of hardware infrastructure. This will allow us to focus on the areas most important to us. And while there are different types of software (system software, embedded software, etc….) we will be primarily concerned with Application Software.
Software is a fascinating technology. It’s intangible of course so you should think of it more as a set of instructions, which together represent a concept, a manual, or even better - a process. Software doesn’t exist in any tangible sense yet it can be very elaborate and complex. This makes it difficult, at first, to describe.
As you have now witnessed in class, and even demonstrated in your own exercises (remember drawing your PC and email system), in order to communicate the nature of software, describing how it works or in how it contains a defect, for example, we use conceptual models to illustrate the interior landscape of software comprised of its components and sub-components, and interactions. A conceptual model is like a map, or like an architect’s drawings. Other words like architecture, view, drawing or design are used interchangeably with conceptual model.
There are all kinds of different approaches to describing software and conceptual model is just a blanket term for an abstract visual representation of something more elaborate, detailed, or complex. Through illustration, they allow us to set a context for and hone in on the area we’re concerned with and to see past less important details.
Here are just a few examples...
Conceptual modeling is really just illustrating a concept and there really is no one set of rules. Notice that in some examples there may be elements of hardware mixed in for convenience. Even though we aren't focused on hardware their physical nature can help us to represent the distributed elements of a software system.
Always bear in mind that with software perspective is everything. Sometimes we will take a 50,000 foot level overview of a broad system - a complete set of software components. And sometimes we will drill down to look in more detail at a particular subsystem or component within the set. And, yes, sometimes we will even look in great detail at the sub components that make up each component. Aids which represent all these different perspectives, when collected together, give us the conceptual tools we need to break down a software system to gain a coherent understanding of its features and interactions.
Process (time series) versus Component (static) views
As we've already mentioned there is no one set of rules for depicting the inner workings of software with conceptual models. Yet two popular ways of doing so is by taking either a process or a component view. As you might guess a process view involves following the series of steps a software system might undergo as it is executed. Imagine the detailed process that a car would go through when it is started and how we could follow the sequence of events in a time series. A business process flow diagram is very similar and may even be used as a proxy for the functions of value-chain management software. A component view is more static. It provides a view of the components within a system not in a time series but in terms of the way they relate to each other, or in terms of the purpose they serve. Imagine a schematic that provides an overhead view of a car showing all of it's sub systems.
I personally find the process view easier to understand. You could take a similar approach to finding a problem with software that you would if you lost your keys. You just trace your way backwards until the last point you remember you had them. With software you just trace the execution of the program back until the point where you know the program is functioning properly.
Posted by: Chad hayward | Oct 29, 2007 4:54:42 PM
I think it is great that we are able to hide the inner complexities of computer systems using conceptual modeling. It is not practical for everyone to understand the intricacies of software programming, but all good managers need to understand how different software systems interact, and the functionality they provide. With conceptual modeling, we can either hide or reveal details based on the layers of abstraction present, and all individuals are able to find a software system model at a level of complexity that they feel comfortable with.
Posted by: Ben Howard | Oct 29, 2007 8:51:47 PM
I find conceptual models are very useful for learning and really grasping many of the different ideas presented in this course such as networking, software, information flow, the internet, the www, value systems..ect. I really have to have a good visual in my head of how something works before I can really understand it, and although conceptual modelling may not give you all the facts and show you every little detail, if you have a good conceptual model, it can provide a great overview of a system or idea.
Conceptual modelling is used to illistrate a very wide range of things, and the more I think about it the more I subconsciously come up with these models to help me understand different ideas.
Posted by: Jeff MacKenzie | Oct 29, 2007 10:33:13 PM
I agree with Jeff, it looks like conceptual models are very useful for learning. It helps individuals grasp a concept through a visual presentation. This post has definetly helped me understand software more. I didn't feel like I was totally getting the concept of software but it is definetly coming together! I can see that the conceptual models helped me grasp more of the idea of software as together software represents a concept and if this process can be represented visually it helps.
Posted by: Krista Mackenzie | Nov 1, 2007 11:18:56 AM
I think that it depends on what you are trying to describe. To make a pizza I believe that a process view is the best option but if I wanted to know how a car works, the component view would make more sense to me.
Posted by: Karen Deveaux | Nov 2, 2007 9:42:20 AM
I think you're right....the designer has to use good judgement in setting up these conceptual models and some situations call for their own approach.
However, it typically adds information to try more than one approach (i.e component and process). It helps you to see the problem or tool from different angles.
Posted by: Mark | Nov 3, 2007 9:49:04 AM
I to find the conceptual models really help me grasp the inner workings of a system and how it really works. Being able to see how they really work helps to understand more then not seeing it there in front of you. Before seeing conceptual models i found it rather difficult to grasp what was actually going on inside and how these systems worked and now you can see them from all different angles.
Posted by: David Dunn | Nov 3, 2007 1:44:20 PM
I as well agree that conceptual models are a great way for learning and teaching..without them people would have a harder time understanding these different concepts. What i dont fully understand is the difference between the process and component views. Process is how steps are interreleated in the way that helps control the other steps in the system, which in the end carries out a process and component is the purpose the parts have to relate to each other as well? To me they pretty much sound like the same thing but I may not be completely understanding the difference.
Posted by: Amy Corrigan | Nov 5, 2007 1:42:19 PM
I found after seeing the conceptual models it really helped me understand a lot more how the inner workings of a system work.
Posted by: Carrie MacKay | Nov 6, 2007 9:52:38 AM
Going back to Amy's comment. What I get from the difference in the component and process view is that the component view shows everything used in the process of something, and that the process view shows the actual process of using those components. To me that is also a little confusing. It seems like everything that is in the component view is also in the process view, plus more. Which again makes me not understand the purpose of the component view.
Posted by: Lindsay Hatton | Nov 7, 2007 7:58:38 PM
I agree with Karen. Conceptual view and process view are both good but they have different strengths and weaknesses. The designer needs to make good judgement. Obviously, if I want to learn step-by-step how to do something I would prefer Process view but if I want to know how a car works I'll choose conceptual hands down. I defintely like them both, seeing it rather than just being told always helps me.
Posted by: Colin Butler | Nov 7, 2007 8:22:22 PM
Sorry I meant component not conceptual view.
Posted by: Colin Butler | Nov 7, 2007 8:33:37 PM
Lindsay, i think you are right....if the process view has all of the same items as the component view, and shows you the order they work in, then why would anyone choose the component view? wouldnt you be able to draw the same conclusions from both?
Posted by: Devon Gillis | Nov 8, 2007 7:55:42 PM
The way that the human brain works is through making connections with different nodes of information and if one is able to break something down into it's subcomponents, whether it be a static or process view, it should certainly begin to make sense (as long as this diagram has no missing links or inconsistencies).
Posted by: Chad MacLean | Nov 13, 2007 2:53:23 PM
I agree that conceptual models have had a positve impact on my understanding of software, but I find Process views to be more beneficial than Component views. When I think of software, I have trouble understanding a component view because really, isn't software related to everything in a computer. It is the medium that displays the content, and makes use of the physical components. Everything we do is done in some type of sequence so it makes more sense for me too look at something in a process view. In the first semester when we looked at the process of what went into bringing up a web page it was easier to grasp using a prcoess model. I'm more concerned with the actions being taken to accomplish a task. Even in the case of how a car works, only a lot more detail is needed.
Posted by: Nathan Snowie | Nov 16, 2007 8:20:26 PM
Along with the majority of the class, I have also found that conceptual models have really had an impact on my understanding. I believe that the lab exercises where we were asked to create conceptual models were very helpful in my understanding of the concept. I find that “hand on” learning is more beneficial than just reading what it is all about. I found in both lab exercises I was very confused at first with how I was going to create my conceptual model but once I really thought about it and came up with a solution it really reinforced my understanding of what conceptual models really are. I believe that whether or not you use a process view of a component view all depends on what you are asked to describe. As mentioned before certain things would be better described using a component view and others using a process view. Correct me if I’m wrong, but I also believe that using a mixture of both views would be very helpful as well, depending on what you are being asked to describe.
Posted by: Mary Beth Larter | Nov 18, 2007 12:21:34 PM
Conceptual models really do make the process easier to understand. Realizing that there are two avenues that can be taken...the process view and the component view...personally, I would have to figure out the component view prior to trying to rationalize the process view. I am sure that everyone does things a wee bit different, but if I don't have a grasp on what relates to what and the purpose that they all have, there would be no way that I could figure out the steps needed to execute the system. But thinking of it all within the terminology listed really does make it much easier to understand.
Posted by: Frieda MacLaren | Nov 21, 2007 10:54:27 AM
I would have to agree with Frieda on this one because, in the component view, you learn how topics are related to eachother and their purpose. I also would find it hard to do a process view without that previous understanding.
Posted by: Nick Drake | Dec 1, 2007 7:44:50 PM
I also agree with Freida because you would have to understand how each of the components work together and are related to each other before you would be able to follow them in process.
Posted by: Ryan Keefe | Dec 3, 2007 1:11:36 PM
I kinda believe that the process view is more simple to understand compared to the component view. I also feel that you would get a better understanding using the process view by knowing what is happening at each step of the way that software goes through. Instead of having a component view and overhead picture of it all and just showing its related parts, I think that would be more confusing to use. But I am most likely wrong and picturing the component view a lot more difficult than it is.
Posted by: alex stevenson | Dec 3, 2007 4:55:13 PM
I think the process view, would only be favored in more simplistic conceptual models such and the pizza and the wardrobe example. When delving into more complex systems I believe it will always be the opposite. An example being a software system or a diagram of an automobile, I think an understanding of the component view is imperative before a full grasp on the process view can be obtained.
Posted by: Zach | Dec 3, 2007 5:27:11 PM
the conceptual model is great for helping understand the different ways we can use software. i like visual things, they help trigger thoughts in my mind and make it easier to recall what is going on. the process view is also nice tho as it makes it easy to compare systems to other systems
Posted by: Sean Hughes | Dec 4, 2007 8:25:31 PM
I too found this very helpful in understanding the views of software. The conceptual models were helpful in understanding the the ways in which software is designed. The only model I didnt really find helpful was the "Understanding Web Design Elements"example.
Posted by: kyle macdonald | Dec 4, 2007 10:39:10 PM
I found this one quite helpful, especially when it came to component views and process views. It made the differences between them very clear. An odd example I suppose could be the process of watching a cheesburger made, the patty grilled, then dressed with toppings. And then the component view could be a side view of the burger showing all the different toppings and what not that comprises the burger.
Posted by: Lauren Tweel | Dec 4, 2007 11:06:51 PM
The comments to this entry are closed.