|
PureBytes Links
Trading Reference Links
|
http://www.insteptech.com/vbtips.htm
Deborah Kurata's VB Tips and Tricks
Here are some interesting thoughts on software design. I thought of myself
as the client and what I would want when specifying an Excel 97 / 2000 VBA
program / Metastock program.
Best regards
Walter
----------------------------------------------------------------------------
---
Object-Oriented Software Design
----------------------------------------------------------------------------
----
What is software design?
Issue: Design is normally the step prior to construction. Before a house is
built, the house is designed and the blueprints document this design. Before
a car is built, the car is designed and the CAD drawings document this
design. How is design applied to software? What is software design?
Software design, is the step in the software development process prior to
construction. It is the step where you think about what you are going to
build, what tools or prebuilt components you need, what components you need
to build, and how it all fits together. The amount of time spent on the
design of the software depends on the complexity of the software. You would
spend some time and money designing a new home but not much time or money
designing a tree house for the kids. Same with software. You may not spend
much time designing the application to track the names and handicaps for
your bowling league, but you will want to take the time to do a careful
design of your company's order entry/inventory/invoicing system.
The next obvious question is then "how does one do software design"? The
first step is a software design methodology.
----------------------------------------------------------------------------
----
Why do I need a software design methodology?
Issue: Using today's tools, you can develop applications quickly using Rapid
Application Development techniques. For example, with Visual Basic you can
easily add controls to forms to create a nice user interface and then add a
little code to the form to make it work. Why do you need a software design
methodology?
Well, if you are developing a one-form application, you may not need a
methodology. But very few applications are that simple. Most applications
have many forms, lots of data, significant amounts of processing, and tons
of business rules. And these components are not independent; they must all
work together.
A methodology ensures we logically think through the things we need to
consider when designing an application: from forming a team to collecting
requirements to designing the components to laying out the user interface to
organizing the data to defining development, testing and distribution
strategies. It helps us to develop a plan.
So the primary answer to the above question is that we need a methodology to
manage the complexity of software design and development.
----------------------------------------------------------------------------
----
How do I go about defining a methodology?
Issue: OK, you're sold on the need for a methodology. Now, how do you go
about defining one?
The best way to define a methodology is to think logically through the steps
needed to design an application. Write all of the steps down. Start from the
definition of the project and include everything you need to do including:
getting funding, defining a team, detailing the requirements, understanding
the business objects, designing the user-interface, and so on.
InStep Technologies uses a methodology called GUIDS. This methodology
provides an object-oriented approach to software design and can be used with
any languages, technologies, or modeling tools.
----------------------------------------------------------------------------
----
Why No Code?
You're working on the design phase of a professional-quality application.
You're interviewing users, documenting object definitions, and drawing
object models. Your boss walks in and asks "Why aren't you coding?" Well,
maybe not in those exact words, but it's clear that the boss is not happy
with your apparent lack of progress on the application.
Here are several answers to that question. Use any or all that seem
appropriate!
Because I need to understand what I'm building before I build it. Using this
answer requires that you explain the purpose of design. Feel free to use the
building metaphor presented in the column.
Because I don't want to recode the application. Explain that you'd rather
think through the application first and then write the code to prevent the
need to rewrite a lot of code later. This answer is best used if your boss
has experienced projects that required rework due to unforeseen
circumstances. Then you can add, "Remember how much code we had to rewrite
during the XYZ project?"
Because we want the application done quickly, and I need to divide it into
logical units so the team can work on it effectively. This satisfies two of
the boss's concerns. First, it makes it clear that you're aware of the tight
deadline on the project. Second, it identifies how you are helping to make
the team more effective.
Because we need to work more closely with the users on this one. This answer
works well if your boss has experienced a project with unhappy users. You
can then say, "Remember how unhappy the users were when they received the
ABC application?" You can really add substance to this answer if you can get
one of the users you're working with to mention to your boss how great it is
to be involved this early on in the project.
Because we want to be a state-of-the-art development group. This answer
appeals to the boss's ego. State-of-the-art today means object-oriented.
Object-oriented design requires that the objects are identified before the
application is built. It's as simple as that.
Because we want to have reusable components to leverage in future projects.
This works well with the prior answer. The key to productivity is leveraging
reusable components. It requires forethought to define which components you
can develop so other applications can use them.
I am coding. This works well if your boss is not interested in hearing about
a design step. For this answer to work appropriately, you should keep the VB
IDE open and minimized while you're working on the design. When you see the
boss coming, bring up the IDE. Be sure that a code window with a lot of
intense code is on top. Just running the Application Wizard will generate
some nice looking code for this purpose.
With these reusable answers, you're always ready to answer the question,
"Why no code?"-From my sidebar to the Programming With Class column in the
Visual Basic Programmer's Journal, March 1998.
----------------------------------------------------------------------------
----
GUIDS Methodology
----------------------------------------------------------------------------
----
What is the GUIDS methodology?
Issue: Sometimes it is easier to start with an existing methodology and
modify it appropriately than to start with an empty slate. Here's
information about the GUIDS methodology to provide you with a place to
start.
The GUIDS methodology is a pragmatic approach for the design of an
application. Each letter in the word GUIDS represents one of the steps in
the design process.
G - Goal-Centered design. This step involves understanding and digging
deeply into the requirements to really understand the goals of the
application. Then taking those goals, defining the basic "things" involved
with the application and how these "things" work together. These are the
business objects and the scenarios. This step results in a clear
understanding of the project and a definition of the business objects and
scenarios.
U - User-Interface design. This step involves converting the scenarios into
features in a user-interface. The focus here is on defining a user-interface
that is centered around the user's goals. Like an emergency room has the
most needed tools within reach and less used or more dangerous tools hidden
within cabinets, so too with a user interface. The most needed features
should be easily available on toolbars and less used or more dangerous
features should be tucked away in menus. This step results in a prototype of
the user-interface and an associated user-interface design document.
I - Implementation-Centered design. This is the most difficult step because
it is here that the architecture and internals of the application are
defined. The results of this step are a detailed discussion of the
application architecture and the components required in the application.
This includes the forms, classes, third-party controls, and other
components.
D - Data design. Notice that the data design is *not* first! Many of us
learned to design software by first designing the database. We learned how
to do entity modeling and normalization. This is a good technique for
designing a database, but not for designing the application. Hence, this
step is here, but not until after the other parts of the design are
complete.
S - Strategies for construction. This is the last step in the design and it
encompasses all of the other steps that should be performed before the
development process begins. This includes the definition of coding
standards, naming conventions, quality control procedures, documentation,
and so on.
For a more detailed discussion of each step of the GUIDS methodology with a
complete example, see "Doing Objects in Microsoft Visual Basic 6.0" by
Deborah Kurata.
To download a sample GUIDS design document, click here.
----------------------------------------------------------------------------
----
Goal-Centered Design
----------------------------------------------------------------------------
----
Goal-Centered Design tips
Here are a few tips on using the Goal-Centered design techniques:
Don't forget the user. To ensure that the application meets the needs of the
users, they must be involved in this step of the process. Even if you're
familiar with the business, you must get the key users or subject matter
experts involved in the design process. However, the user interface itself
is not the design.
Don't worry about implementation. Given any problem, developers like to
think about how to code a solution. At this point in the design, that is
irrelevant. Again, the goal of this step is to fully understand the
requirements in order to ensure the resulting application meets the needs of
the users.
Don't confuse the object model with a data model. As you develop the object
model, you define the data elements associated with the objects. However,
you are not developing a data model. As you know, a good data model requires
a lot of information about the data, how it is related, and how it should be
normalized. This information is not relevant at this point in the process
when you are simply understanding the requirements of the application. You
develop the data model later in the design process, after you are clear on
the users' requirements.
The object model is not the design. In the first point, I stated that the
user-interface design is not the design. The previous point states that the
data model is not the design. Now, I'm telling you that the object model is
not the design. The design is the set of all these things.-From my sidebar
to the Programming With Class column in the Visual Basic Programmer's
Journal, March 1998.
----------------------------------------------------------------------------
----
Links
----------------------------------------------------------------------------
----
Links to Software Design Sites
There are a number of great sites available for information on software
design and design patterns. This page contains pointers to a few.
Alan Cooper on Software Design Alan has very interesting things to say about
software design; specifically the user-interface design. You may not always
agree, but his statements will definitely make you think!
Association for Software Design
This organization is a non-profit organization that focuses on the design
of software.
Object-Oriented Design Part of software design is designing the objects
involved with the application. This InStep Technologies site provides
information on "OO" and links to other "OO" sites.
The Important Things Are Always Simple This is actually a link to an
EXCELLENT article by Douglas Johnson and Rick Smith. It appeared in the
September issue of Object Magazine.
----------------------------------------------------------------------------
----
InStep Technologies, Inc.
Copyright ©1998 InStep Technologies, Inc. All rights reserved.
Revised: May 01, 1999.
|