Important Terminology for Architects and Designers

Today is Sunday. I didn't read, write or thought too much. So just for your (and of course mine) timepass I am giving some useful vocabulary for architects.

Surface Area
Surface Area is a term used to describe the way in which components interact withy one another in a defined way. It’s important to note that the greater the surface area, the more ways a change in one component can affect another.

Boundaries
Boundaries are the areas where two components interact.

Brittleness
Brittleness is the degree to which small changes will impact large portion of the system. Software tends to be unwieldy for many reasons, but a primary reason is brittleness. The distance between the ideal computers architects imagine and the real-world computer systems we know and work on is unfortunate and due in large part to brittleness.

Capabilities, Friction, and Layering
Capabilities are the non-functional, observable systems qualities including scalability, manageability, performance, availability, reliability, and security, which are defined in terms of context.

Friction refers to how much interaction occurs between to components. Friction is measured based on how a change in one component affects both components.

Layering is a hierarchy of separation.

Managing estimation and keeping with deadlines is always a art than a science. But it doesn't mean we can not utilize the science at all for project management. Robert Martin suggests us two charts that can be very useful hanging on wall -
"Velocity Chart" - illustrating, week by week, how much work is actually getting done?
"Story Points Chart" - week by week, how much work remains to be done in the project.

He also suggests - fitnesse.org, an acceptence testing framework.

In OOP we have standard UCP formula found in the book Applying Use Cases.

For those who doesn't have any idea here is the illustration - The UCP formula assigns each use case a complexity level of simple, medium or complex, based on either the number of scenarios in the uc or the number of analysis classes used to realize the use case (once that info is available). Each UC rank has a number of points associated with it. Actors are also ranked. For project estimation purposes, these points are added up and have a few other factors applied to them to convert them to man hours.

Sample "Velocity Chart"

Sample "Story Point Chart"

You can dig the details at -
http://www.sdmagazine.com/documents/s=8958/sdm0312f/sdm0312f.html

On the newsgroup few suggested following links, which I also found useful.

Object Design Tips 1

Object Design Tips 2

ObjectMentor.Com

You can also check the discussion thread on google groups. I guess, the link should work.

Patrick Rahmoune suggested this new coming book - "Design Patterns Explained: A New Perspective on Object-Oriented Design" by Alan

Recently I saw a post on object newsgroup asking same good old question i.e. how to understand patterns. Here are my short and concise tips –

1. Read "Applying UML and Patterns" by Craig Larman once. Just take an overview.

2. Keep reading "Design Patterns: Element of Reusable Software Design" by GoF till you understand it. I think it will take around one month. Keep reading it like a novel, even if you are not able to understand.

I am sure, more the stuff and more you will be confused. So try to stick with these two.

Punit Pandey

I have created one more blog which will contain all my articles which I post here. What more, you can get RSS feed too. The link is Software Methodologies

Yesterday, I was thinking that there is a way namely CRC Cards to visualize Classes and their responsibilities. But is there any way to visualize methods, their functionality and responsibility. I got following solutions from comp.object newsgroup.

* TDD (Test Driven Development)
* Writing down post condition, pre condition, parameters, return values
* CRC itself
* Flow charts, Nassi-Schneiderman charts, State Transition Diagrams and Decision Tables
* Sequence Diagram
* Object ineraction/sequence diagrams, message diagrams, state diagrams and lastly if you *must* (as even the UML authors suggest) activity diagrams.
* Use Case Scenerio extended in structure chart
* Skill Driven Notation

I'll try to write about this and provide some link in future. Menawhile you can go throuhg the thread at google groups here.

Punit Pandey

This is what we use to document our use cases. Fortunately, most of the word document is generated from Rose.

1. Goal

2. Actor

3. Detailed Description :

main success scenario, extensions and variations

4. Special requirements

5. Interface specifications:

GUI draft, possibly made up with user

6. Use Case Design:

Basic choices + their justification. Design Patterns used. Trade offs.

7. Use Case View:

Class diagram, sequence diagram for main success scenario

8. Participating Objects:

Methods of classes with their documentation (pre/post condition)

Of course, the whole document is not written at the same time. The first sections are filled up during requirements analysis or analysis phase, while UC design and UC view are completed during design.

First, Design Patterns

Second, multiple views of system

Third, aspect-oriented programming

See the detailed article Through the Looking Glass

Hello Friends,

Today I was trying to understand Aspect Oriented Programming. At first it seems difficult but is not as difficult. I found this explaination quite useful -

In any program there will be small recurrent tasks that are spread out over your entire code base. These tasks can't be modularized in the current programming paradigm. The typical examples are logging or user authentication. Although you can obviously create classes for these tasks and place them in modules, they will be used throughout your entire code base. You might say that they are sandwiched into your code. Any change to this code will leave you doing a hunt through your entire code base. Aspect Oriented Programming allows you to write modules specifying where these tasks need to be sandwiched in and performs this "weaving" at compile time. This is my simple explanation, but I hope that it has helped.

I found these two articles really good introduction of AOP -

I want my AOP!, Part 1

Improve modularity with aspect-oriented programming

I have lots of questions right not in my mind. I hope someone can answer e.g.

How important is AOP?

Is AOP going to be common in near future?

How useful can AOP be?

Are there any successful projects already developed with AOP? And if yes, is the design available?

What are the commong aspects like logging?

How many in this group are using AOP in any of their projects?

Metaphor is very important, a little creative, and hard to get right. The other XP practices often fit together so well they give a productivity boost, and the team forgets to use a metaphor.

However, all teams name their functions and modules along similar patterns. When we say "ClearConsole()", we don't really mean "remove all the knobs and levers from a small wooden cabinet with a machine inside". Most computer terms are metaphors - memory, mouse, etc. - all upgraded to jargon.

The System Metaphor practice (which every project should use, not just XP ones) tells us to deliberately create a unifying metaphor, and to name everything following it. This helps a team generate coherent jargon, and use it to discuss the project. It's the creative end of the naming conventions in the team's style guide.

Another name is "conceptual integrity."

This tip is the first in a series of articles dealing with the best practices of Object Oriented Design (OOD). In these articles, we will discuss several design techniques that lay the foundation of solid OOD practices. To begin, we will first introduce the cornerstone principle of OOD. All areas of study have such a principle; the core behind the entire science. For calculus, this is the Fundamental Theorem of Calculus. Newton's Three Laws of Motion lay the groundwork in physics. For OOD, the basis principle is the open-closed principle.

One thing is certain in all software development, all software changes during its life cycle. So, it is imperative that developers design software that is stable (i.e. does not change) in the face of ever changing functional requirements. To aid in this development, Bertrand Meyer gave us the open-closed principle, which states: Software entities should be open for extension, but closed for modification.

Software modules that satisfy the open-closed principle have two huge benefits. First, they are "open for extension". Meaning, the behavior of the modules can be altered to satisfy the changing requirements. Second, these modules are "closed for modification". The modules, themselves are not allowed to change.

Object patterns.

Abstract Factory, Builder, Factory Method, Prototype, Singleton, Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy, Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor, RTTI Visitor, Stairway to Heaven, Polimorphic containers, Role playing.

1. GOF Design Patterns
2. GOF, Design Patterns: Elements of Reusable Object-Oriented Software
3. Portland Pattern Repository
4. Robert C. Martin's papers (Dual Interface Hierarchies, Private Interface)
5. Visitor

Extreme Programming consists of the following 12 practices:

• Planning Game
• Small Releases
• Metaphor
• Simple Design
• Testing
• Refactoring
• Pair Programming
• Collective Code Ownership
• Continuous Integration
• Sustainable Pace (used to be: 40-hour Week)
• On-site Customer
• Coding Standards

Essential Practices

Ken Auer and Roy Miller propose in their book ("Extreme Programming Applied", page 71), that although it is better to start with all 12 above mentioned practices, it is also feasable to start with only the following 6 practices. Ken and Roy call them essential practices.

1. Planning Game
2. Small Releases
3. Testing
4. Pair Programming
5. Refactoring
6. Continuous Integration