Design Corollaries

[kydavis]

I have a project that I am working on and I am trying to understand design corollaries. Am I right in assuming that they are just guidelines for system development? One of the questions in my project is to show the application of the design corollaries. How can I show corollaries?

Im not asking anyone to do it for me. I am just having trouble understanding the concept and my teacher is about as useful as a third nipple

Thanks.

 

[BobRodes]

I'm unfamiliar with a standard definition of "design corollary." Please give yours, with examples and explanations.

Bob

 

[kydavis]

Check out this site for the definitions

http://dotnet.org.za/hannes/articles/12689.aspx

 

[BobRodes]

Ok, thanks. Yes, you are right, they are guidelines for system development. That's an interesting page. Here are some comments on the six corollaries that are discussed there.

Coupling is an oft-visited topic on this forum. Too much communication between objects is the indicator of too tight coupling.

"Single purpose" is more often referred to as "cohesion." Reusability is also a byproduct of cohesion. The way to check for a violation of the cohesion principle is excessive decision logic.

Strong mapping simply means that the class structure represents a map of the business rules, and that the implementation of the classes adheres to the map. In other words, don't let implementation details let you change the design in such a way as to fail to implement business rules.

Standardization examples are design patterns and frameworks.

Inheritance hierarchies are derived by generalization (deriving a superclass) and specialization (deriving subclasses).

Feel free to post back with more specific questions, but read also some of grooke's and my discussions on this forum. They'll give some elaboration.

HTH

Bob

Bob

 

[kydavis]

thanks bob. I think that my question is, is there a way to show the application of corrolaries? The first part of my project is to show the application of Design corolarries. If these are just guidelines, is there an actual way to show the corrolaries? These are just steps that you follow in designing a system, no?

 

[grooke]

This is a good question. Like Bob, I was lost with the term the author used, but thanks to Bob, I can now see what they are saying.

Axioms are design rules that we cant sensibly avoid.
Corrolories are things that follow from them, but are not necessarily essential. They get applied in combination and more or less according to the nature of the problem and the environment for which it is being built. They seem to me to be like 'design strategies' or as Bob says "guidelines for system development".

You ask where they go or how they are shown. This is my guess. Bob and others may have better ideas.

I see a specification of a system as having three parts:

1. Business rules attached to classes in a domain diagram and may be duplicated in English if the 'Busines'' cannot cope with domains.

2. Use Cases are large 'business rules' that span a whole single and significant user action required by the systems.

3. Rules that span the whole system:e.g. must be secure; must be available 24x7-2 hours per week; must be usable on the WEB and WAP, but no GUI interface. These sorts of rules usually end up in the 'Non-functional' (horrible name) document for the whole system.

The 'Non-functional' document (which is NOT UML) is where I sometimes document data 'security-checking strategies', 'ergonomic objectives' and other global business rules. So I guess I would describe the chosen rules for these strategies in this document.

Thanks for the reference. Although I can easily pick fault with the detail, the actual grouping of these strategies could be very useful.

Gil

 

[BobRodes]

I wrote up an answer and apparently forgot to post it! Sigh.

From an academic standpoint, I believe what your teacher is getting at is to show how you use some (preferably all) of those corollaries. I believe what I would do is simply write notes to show where you apply them. For example, if you use a design pattern, write up a little note that explains the pattern and why you used it. Create a class diagram, and explain why you used inheritance in it. Talk about cohesion and coupling. That sort of thing.

<Corrolories are things that follow from them, but are not necessarily essential.

To give one example of this: a "design pattern" is a way of doing some particular thing that has evolved over time as a best practice. An important point about such a pattern is that, since it evolved over time, it was not the first solution that was tried; rather, it's a result of incremental trial and error. Its use is non-essential, since if it were essential, none of the designs leading up to it would work, and there is ample evidence to the contrary. However, it is the most efficient way to accomplish the problem it is designed to address.

A good simple example of a pattern is the Singleton pattern. This pattern is a way of having one and only one instance of a class in existence in a client domain. The bare bones would be something like this (this is pseudocode):

class mySingleton
private theInstance : mySingleton

public mySingleton()
[if theInstance is null then
theInstance = New mySingleton]
[return theInstance]

public getInstance(): mySingleton
[return theInstance]


end class

All we're doing is, in the class's constructor, checking to see if an instance of mySingleton already exists, and creating one if it doesn't. Of course, you would add other methods and properties to accomplish your work. A good example of a simple Singleton application is an incrementor for, say, new account numbers. Any client needing a new account number has to make sure that no other client has taken that number. So, they all create an instance of your singleton, and they all have a pointer to the same object. You have a property called NextNumber that increments a private variable and returns the result.

So, in your project, you might use something like this, or another design pattern, and then document the fact that you used it and why, explaining that it's an example of the "standardization corollary."

By the way. I once had the very great pleasure of running into the poet Maya Angelou in a hotel lobby and speaking with her for two or three hours. A young woman who was with me at the time mentioned her dislike of a professor of hers. Maya responded "Now ....., a brilliant student can make a mediocre professor look brilliant, so it is your job to make that professor look brilliant." Very good advice, I would say.

HTH

Bob

 

[grooke]

An excellent description of one of the strategies. I have one minor problem.

I see patterns as guides to design and NOT 'the most efficient design'.

I once had a problem and came up with a design. Then I checked it against the GOF patterns. It lay between two of them (Factory and Template?? - a long time ago and it might be two others). If I use one standard pattern it would NOT cope. The other was overkill, and there was nothing in between them.

I programmed my solution which was exactly right, but afterwards regretted not having used the overkill. The reason for using it is that the maintainers then find a standard pattern and their learning time is less.

At times maximum efficiency is not always the best, and the published patterns are NOT necessarily the most efficient. They do however provide some recognisable standard.

However, I have seen some pattern books where the patterns (particularly Analysis Patterns) are blatantly wrong. So what is the standard?

Gil

 

[BobRodes]

Um, I said it was the most efficient design to accomplish the problem it was designed to address. So, again I'd say we're in agreement really Gil, because they often CAN be overkill for problems that are somewhat different from the one they were designed to address.

I like to use the concept of "arch" as applied to church architecture as a concrete (well, stone) example of a design pattern.

And you do point out something else, which is that there is a good deal of literature out there that doesn't agree, and there's not complete agreement as to standards. I believe the OMG is working on pattern standards.

Bob

 

[grooke]

I'm NOT sure I like pattern standards.
Probably because I done particlarly like patterns.
Probably because I'm old and out of date :-(

I prefer to design it according to my experience and then use the patterns as quality control;
did I miss something,
is there a pattern vaguely like my design, that suggests I got it right

I do the same with existing systems that need to be replaced or upgraded. Once I have got the concept, I work out what is needed from scratch. Then I study the existing one in detail, to answer the same quality control questions.

Too many times, I see people pick up a pattern and just use it. They dont know why. They dont wonder if the is a varient that may be better. If chanllenged, they just say that they have followed a standard pattern. (You cant get sacked for buying IBM or Microsoft).

With my approach, I have two different solutions to compare. They only have one (The standard deviation of a sample of one is infinity).

Worse still, managers may insist that the analysis and designs must conform to standards.

The number of variations on modelling customers (organisations and people) and their various forms of addresses is almost limitless. I always start with the most general and drop off features that I dont use. Martin Fowler says to start of with the simplest and refactor in wider features when necessary. I suspect both of us are right, but that martin wins on reputation. However, the model he gives in his analysis book is totally unacceptable in my book. This still wont necessarily prevent him from designing a better system.

Part of the equation is that the analyst has to comfortable with the techniques they use.

I think analysis needs skills and tools and NOT formal patterns.

IMHO

Gil

 

[grooke]

There is one more thing I cant help but comment on. That is Hannes's (sic) OO Axioms.

The Independence axiom
The Information axiom

The first is a poorly defined description of 'Encapsulation'.

The second seems to have totally got it wrong. Yes, we should always consider Occam's Razor, but not at the expense of other axioms.

The description that should go with the Information Axiom relates to Objects. Objects are clearly identifiable model (a computer program is always a model of reality) that retains records the state of that object either until the state is explicitly changed or the object is destroyed.

That and encapsulation is the essence of OO. Classes and use cases come in at the next level and are almost corollaries.

Having said that, the corollaries he (she) lists are interesting and relevant. Cohesion and coupling fit in with objects far better than with Occam's Razor, because we are then taking about concepts we can influence with our designs.

There is food for further thought in them, to reinforce an idea I was givebn at a seminar last week. They are well worth discussing.

Gil

 

[rac2]

Maybe the way to demonstrate the use of corollaries would be to note where you were faced with a decision in the design. Describe the alternatives and mention the corollary that influenced your decision to use one solution instead of the other.

 

[BobRodes]

I actually thought that the "Independence axiom" was more a description of cohesion, personally.

As for patterns: I would certainly say that some of them are applied in places that they don't quite belong, for reasons that you describe well, Gil. However, one might also point out that the whole event-driven programming paradigm is based on the observer pattern, and that containership hierarchies are based on the composite pattern. If one wants to build a set of visual objects that may or may not contain other ones, I would say that one would have a hard time improving on the composite pattern as a means of architecting that set. So Gil, while your way of using patterns is certainly valid, given of course that you have sufficient experience, I would also say that patterns represent a distillation of a great deal of trial and error, and can therefore save a good deal of trial and error when applied.

It occurs to me that there's an analogous example in piano music. If you master the scales and arpeggios, using the standard fingerings, when you see the same patterns in acual music you have a lot easier job finding the right fingering. Lord knows I don't like working on arpeggios, but knowing them saves me a lot of time when working up, say, a Bach piece.

So, your point is an important one: one should not be too rigorous in applying theory. However, one should be equally careful in eschewing it, too. A good balance is essential, and one of the points you make is that each person has to strike that balance for himself.

Bob

 

[grooke]

When you work up a Back piece, do you think 'Now I'm using this Arpeggio or that scale.' It may flash through your mind once when you first start a piece, but then its gone.

In this sense, they are a means to an end, and the better you become the less conscious you are that they are what you are using.

So Yes! I expect beginners to start with patterns (and corollaries) as you suggest, but the experienced people should aim at not needing them, except perhaps as a double check.

Then your last paragraph applies precisely.

What concerns me is people who insist on documenting or knowing which pattern is involved.

Gil

 

[BobRodes]

<It may flash through your mind once when you first start a piece
Would that I were so gifted.....more like 1 or 200 times. But I take your point: at some point it's gone and there is only the music. However, this is analogous to saying that once a program is written the use of patterns is no longer what's noticed. I simply point out that I DO finger the arpeggio in the way that I have practiced--if it's an F minor arpeggio I put my 4th finger on Ab. If for some reason I try using my third, I'm more likely to miss notes. So, what I'm saying is that I DO use a pattern if I'm trying to accomplish the purpose for which that pattern is intended.

<So Yes! I expect beginners to start with patterns (and corollaries) as you suggest, but the experienced people should aim at not needing them, except perhaps as a double check.
Here I don't think I agree with you, Gil. Why should experienced people aim at not needing them? If, say, the Model-View-Controller pattern works well for showing data on the screen, why should one attempt to find another way just because one is experienced? Maybe I'm not understanding what you're trying to say.

<What concerns me is people who insist on documenting or knowing which pattern is involved.
I agree with you there, that implies a slavish adherence to patterns to overcompensate for a lack of understanding of their purpose. On the other hand, avoiding patterns can become reinventing the wheel.

Bob

 

[grooke]

There are programmers who seem to instinctively pick up the correct pattern with very little thought, whereas other have to consciously examine and study every possible pattern. I think that this is the major distinction that makes experienced programmers significantly more productive than new programmers.

What I'm trying to say is that programmers should aim NOT to avoid patterns, but to use them without thinking.

Gil

 

[BobRodes]

I got you. Yes, that's so, and the music analogies very much apply there. Patterns are like groups of notes, or riffs, or ragas or whatever. However, I'd say that it's so up to a point. There are times when an experienced programmer still needs to study a lot of different ways to make something work. The fact of his experience only means that he's able to eliminate red herrings more easily, like a good chess player ruling out bad moves in an unfamiliar position. In a situation like this, I would look into patterns first as a means to solve the problem at hand. And I would think before I used them. So, I take your point, Gil, but I guess I don't feel as strongly about it as you do.

I just read something interesting about patterns. Someone said that patterns are discoveries, not inventions. That makes sense to me.

Bob