Object-Oriented Analysis

I'd like to start a discussion of OO and where this is now, not just in terms of the languages and how they're built, but more at the analytical paradigm and where it leads.

OO is an approach to programming that looks at the process from a "what's in the problem domain" approach, rather than "what's the data"?

Manipulation of data in the procedural approach, looks at data "structure", and what to do with it. OO looks at data "agency"; there are different "objects" (in a "problem space"), each object and kind of object interacts with other objects, and messages are exchanged.

Anyone in to a yak about this?

 

Log in or Sign up to hide all adverts.

In a purely procedural language, there wouldn't even be functions, there would only be subroutines. The idea of a function is that you get a certain output for a given input. What this does is hides the implementation from the client, and introduces the idea of abstractions.

Go further in that direction and you can do things such as allow different implementations of the same functions, depending on context. Abstract it even further, and you stop dealing with how to transform the data, and begin to deal more with the organization of the data, and the abilities that data has. It's all about abstractions and abilities.

Modularizing the system into objects is a closer representation of the way real-world systems work. You have people that interact with other people, telephones that work without you having to know anything about the underlying implementation, etc. It makes sense that if this organization works in real life under very complex situations, it should also work in computers.

The contrast between the two paradigms arises out of the fact that computers perform operations one by one, in a mathematical way. This is the more procedural side of things. But the programs are always ultimately written by humans, so it's useful to treat the design differently.

 

Log in or Sign up to hide all adverts.

Have you done any OO analysis of real-world systems, or used any tools?

 

Log in or Sign up to hide all adverts.

How about some business, or a library, e.g.? It models physical process, say a construction or assembly process (a factory). Parts inventory and manufacture would be a sub-system of lots of businesses (well, the ones that make things).

Could the OOA paradigm extend to some system that isn't business-oriented? Would it fit something like, say the Periodic Table, and Chemistry?

 

Well, OOP gave birth to design patterns which help software architects create relationship schemas for a class or set of classes to achieve some kind of consistent and desired behavior that is not otherwise available. A classic example is the "decorator" design pattern where a standard object intended for graphics rendering is constructed in such a way where an instance of that object can be passed into the constructor of a different graphics object with the same base class and this new instance can be passed into the constructor of yet another graphics object... and so on. The new object has near identical methods and will call it's superclass' methods to achieve an overlapping render effect. Consider a pine tree object. It's decorators might be three different kinds of christmas ornaments. When manipulating the final instance of the tree, all the attached decorators will receive the manipulation instructions as well because of the relationship and to the end users point of view it looks like one big christams tree object is being manipulated uniformly.

 

Almot anything that occurs can be looked at in terms of objects. You and I, for example, are objects. We talk to each other through a common interface (the English language). When I want to tell you something, I don't have to know how to actually fire your neurons to make you understand. I just let you do your thing.

 

I've used Eiffel, and there's this OOA package from Coad & Yourdon (which was first developed back in the 90's - it's so last century).
I haven't really looked at much in the analytical domain lately, but I know there are plenty of languages that are either designed as OO languages (e.g. Erlang), or have had extensions (like C++).

OOA can be applied to anything, presumably, and the analytical part of designing a problem solution is independent of the language or system used to implement it on a real-world machine.
Most computers are von Neumann architecture (which frankly, I find a little boring, but it's like the combustion engine, well-understood and tested).
Coding in some OO language means you can't avoid the object paradigm, but how much do you need to know about the analytical side? Any stand-ups for OOA expertise around here? What do they teach you about it these days?

 

I must be self-absorbed today.

Please Register or Log in to view the hidden image!

You have to know enough to understand the basis of object oriented design. I would say the analytical side is important, but you don't need to know all that much. I wouldn't advocate that anyone really needs to go through expensive training programs or anything. I suppose a certain degree of OOA has to be done before any design can begin, but it doesn't have to necessarily be at a very formal level.

 

Right. So is there a need to go over any of the OO concepts, or define what terms like "method", "class", "class&object", "instantiate", etc mean? We're all cozy with the basics?

CASE tools keep popping up like mushrooms; there's a whole family of languages, including languages written solely to design OO systems, i.e. analysis and design. The concept being that, once you have a good OO spec., you can implement it in the language of choice - C++, Erlang, COBOL, or assembler. It shouldn't matter except for considerations of efficiency, portability, extensibility and "maintainability".

I learned that the A/D phase is the most important, without a spec. it's like trying to build something without any plans. You have to disconnect from the ideas you got from the procedural approach: "find all the data and analyse it". The procedural approach appears to be something like: once you understand all the data and how it's structured, what to do with it should be obvious, and you refine the definitions (and implementations) of the data, to make it "fit" the procedures.

OO is entirely different - there's no pool of data or information, but there's interaction and communication. I/O is a different paradigm altogether, which doesn't map to the Turing model all that well.

 

Agreed. Not spending enough time on design is part of the reason that software projects have such an abysmally low success rate. It's an investment, and it comes with overhead, but it pays off.

Have you read the Gang of Four book, "Design Patterns"?

 

Not familiar with it, but I've read a few OO books -mostly whitepapers, user manuals and lecture notes. I've coded one or two programs in more than one or two languages - procedural, o-o, functional, list or stack-based, assembler, but all tied to VN architecture (apart from networking and distributed OS stuff). I think new or unconventional architectures, maybe also at the embedded end, because of mems and nanomachines, are going to get interesting. We tend to follow promising looking leads, but things sure have changed in the last 20-odd years.

P.S. yes, I was at uni that long ago.

P.P.S. Is Design Patterns available online?

 

http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

 

No, Crunchy. Here's the correct URL for the book. http://en.wikipedia.org/wiki/Design_Patterns

I bought my copy for a class. I found it on half.com for very cheap. I don't know of anywhere online where it's available without buying a physical copy. If you ever come across a copy of it, you should take a look.

 

WTH? That link worked when I originally posted it. Thanks Rubiks :shy:.

 

Cool, there's a lot of references to online stuff at that wiki.
The guts is some design language, or model. That is, what kinds of tools are there for the crucial development and "drawing up" stage of any constructed system (process&architecture).
It gets into some quite deep stuff about how we interact with technology, and the way we conceive stuff (spatially, and in terms of value and significance - we often overlook important details because we're looking at a "higher" level of abstraction).

That's also the edge I see in this OO stuff -I've studied linguistics a little too- which is philosophical as well as utilitarian. Speaks to the way we "see" things in the world and build internal representations.

 

I'd like to look at some kind of biochemistry model, something like the cell membrane or maybe a ribosome.

So start small, or start general? How closely or generally could some biological "subsystem" be modelled?
I've found links to stuff that talks about "chemical logic", in terms of interaction-driven processes, equilibria, the "channels" of energy and electron "transfer" - ie. the interaction of charge and chemical bonding. Also conformality, and the "stretchiness", plasticity and "bendyness", in long-chain molecules. The way certain kinds of structures like phenolic groups and "rings" with charge de-localisation keep turning up in pigments and "transfer" molecules.

The way all the tension and charge is "sheperded":- controlled, in other words. That's what I want to try and emulate -the function of structure, and how structure interacts with other structure.

Sounds like some kind of machine with interacting components, and it should be model-able. But it sounds like something of a task too.

But the principle should be demonstrable - i.e. correct. So it should support or not, certain views, shall we say.