Design Process - Architecture & Design
Architecture
How do you decide upon an architecture given
the vast choice of languages, APIs and libraries? How do you prove the
chosen architecture meets your non-functional requirements? How do you
decide which platform and topology is right for you? How good is "good
enough" and which tools really do add value during development? Visual
Studio, Eclipse, IDEA, Netbeans or something else?
The answer to the above questions are not
easy and the chosen architecture is highly dependent on the project
scope, resources and time line. Deciding on the right architecture is
often based on the architect's intuition and past experience. Our motto
is to keep the architecture as simple as possible while still being
flexible enough to meet the user requirements and future enhancements.
We are certainly guilty of over-engineering an architecture and had to
learn things the hard way. It's very easy to be seduced by the latest
and greatest frameworks that often have a poor track record and may
have a steep learning curve. Our experience with Corba and J2EE Entity
Beans can attest to that. Often the simplest solution is usually the
best.
We are also big believers in open source
frameworks for the simple reason that application developers should
focus their attention on core business logic. Developing database and
web frameworks is a big waste of time since there are mature and well
documented frameworks freely available. Open source frameworks (e.g. Spring, Hibernate, Struts) provide all of the plumbing required to get an application up and running in no time.
Finally, we are strong advocates of
prototyping before finalizing on the architecture. This is especially
true when dealing with relatively new open source frameworks. Nothing
is worse than a paper architect that comes up with a poor design that
doesn't scale or perform. It's best to take sufficient time to fully
test and finalize the architecture before significant coding begins
since the architecture will form the foundation of your system and it's
critical to get it right.
Object Model
We use CRC cards extensively in designing
the object model. A CRC card is a 4X6 index card that represents a
class along with its responsibilities and collaborations. Back when
most applications consisted of a two tier architecture with a fat
client, it was easy to have each class responsible for its actions.
Today with a multi-tier architecture, the object model typically
consists of dumb data objects that are passed from tier to tier. Most
of the logic which used to be in the object model is now stripped out
and resides on the server tier. This makes defining the object model
much more difficult since you now have to take into account the server
side classes that contain the bulk of the business logic.
The object model diagram describes the types
of objects in the system and various kinds of static relationships that
exist between them. At this point, we gather all of the CRC cards and
take a first pass at the object model and relationships. We can use UML
notation for this exercise. We will also make extensive use of common
design patterns in order to create an efficient object model. At this
stage, we will also attempt to determine the class attributes and
methods based on the CRC cards. This step normally requires several
iterations.
Sequence Diagrams
These are often called interaction diagrams
and/or message sequence charts. A sequence diagram represents an
interaction between objects with particular focus on the message
broadcast chronology. Sequence diagrams provide developers with a
general idea of the flow of the system. This step will usually provide
additional confidence to the design team prior to coding.
Return to Design Process
|
