Re: Model Check Inside - Out



Build Flexibility into Your Software
The use of design patterns can help you to build flexibility into your
software per the above suggestions. But how crucial that flexibility is
depends upon the kind of software that you are building. These authors look
at three broad classes of software, and the role which development will
require attention to flexibility.

The three broad classes of software are considered: (1) Application
programs, (2) Toolkitws, (3) Frameworks

(1) Application programs - the maintenance of internal reuse
maintainability, and possibility to implement extension are high priorities.
Internal reuse is a reference to the internal source code used for the
particular application. The point is that source code should carry forward
as an asset; not discardedbut reused within other application programs.

The use of design patterns (techniques for design) make your application
more maintainable, by reducing dependencies (smaller footprint), by looser
coupling (enabling one class to cooperate with several others), isolate and
encapsulate operations to eliminate dependencies on specific operations.
This allows an operation to be reused in different contexts. As with
removal of algorithmic dependencies, and representation (front end)
dependencies.

Limit platform dependencies, andbuild layers into the software application
system. This practice can enhance the extendibility through uise of class
hierarchies, and how to exploit object decomposition. Reduced coupling also
enhances extendibility. Extending a class in isolation is easier, if the
class does not depend on lots of other classes.

(2) Toolkits - applications sometimes incorporate predefined classes from
one or more than one library. Those predefined classes are known as
toolkits.

A toolkit is a set of related and reusable classes designed to provide
useful, general-purpose functionality. An example of a toolkit would be a
set of collection classes for lists, associative tables, stacks, and the
like.

Toolkits don't impose a particular design on ytour application, they just
provide functionality that can hslp your application to do its job. You as
the implementer, can avoid the coding of common functionality that is
provided using the toolkit. Toolkits emphasize code reuse. They are the
object-oriented equivalent of subroutine libraries.

Toolkit design is arguably harder than application design, because toolkits
have to work in many applications to be useful. It is important to avoid
asumptions and dependencies that can limit the toolkit's flexibility and
consequent effectiveness and applicability.


(3) Frameworks - a framework is a set of cooperating classses that make up a
reusable design for a specific class of software. For example, a framework
can be geared toward buiolding graphical editors for different domains like
artisdtic dtrawing, music composition, and mechanical CAD. Some other
framework can help you to buikld compilers for different programming
languages (and target machines). Another framework might help you to build
financial modeling applications.

You customize a framework to a particular application by creatingf
application-specific subclasses of abstract classes from the framework.

The framework dictates the architecture of your application. It will define
the overall structure, its partitioning into classes and objects, the key
responsibilities thereof, how the classes and objects will collaborate, and
the thread of control.

The framework captures the design decisions that are common to its
application domain. Therefore framework emphasize design reuse over code
reuse.

The framework predefines the design parameters (i.e., the overall structure,
its partitioning into classes and objects, the key responsibilities thereof,
how the classes and objects will collaborate, and the thread of control), so
that you as the implemented can concentrate on the specifics of your
application. Yet concrete subclasses that are included with the framework
let you go to work using the framework, immediately.


Frameworks Vs. Design Patterns
When you use a framework, you reuse the main body of the application and
write the code that it (the framework) calls. The operations which will be
called, will have to have specific names and calling conventions, but that
conventiion reduces the design decisions that you will have to make.

Not only can you build applications faster, using a framework, but the
applications have similar structures. Thus they are easier to maintain, and
they appear more consistent to their users. On the other hand you lose some
freedom to create, since many design decisions were made already, for you.

Since the framework's main contribution to an application is the
architecture it defines, it is imperative to design the framework to be as
flexible and extensible as possible. Frameworks are therefore hard to
design. Loose coupling is especially important to prevent cascading
changes. see above entry about loose coupling.

The documentation about the framework is very important. A steep learning
curve is often involved before the framework is mostly useful. Key elements
of the framework's design must be documented explicitly.

Frameworks can be reused directly, in a particular programming language.
But frameworks are large architectural elements, whereas design partterns
are smaller as architectural elements.

Frameworks are specialized for a particular application domain. But design
patterns are different in that they can be used in almost any kind of
application. Frameworks tend to dictate the application architecture, where
even the most specialized design pattern should not.


Frameworks are becoming increasingly common and important. They are the way
that the object-oriented systems achieve the most reuse. Larger
object-oriented applications will end up consisting of layers of frameworks
that cooperate with each other. The application wil consist mostly of code,
and design influenced by frameworks that is uses.

Redesign
Design patterns and frameworks that are similar in purpose, are created
similar, structured similarly, and behave similarly. AS a programmer, you
can compare and contrast between patterns of like purpose. A cause for
redesign can be detected using the advice that follows:

Here are common causes of redesign along with the design pattern(s) that
address them:

1. Create objects indirectly. By creating an object using a specification
of a class you are committed to a particular implementation instead of a
particular interface. That committment can complicate future changes, which
can be avoided by creating objects indirectly.

2. Avoid dependence on specific operations. When you specify a particular
operation, you commit to one way of satisying a request. To make it easier
to change the way that a request gets satisfied, aoid dependence on specific
operations.

3. Limit dependence upon particular hardware and software platforms.
Software that depends upon a particular hardware platform will be harder to
port to other platforms. It is also more difficult to keep updated on its
own hardware platform. So design systems to limit platform dependencies.

4. Hide object representations or implementations. When clients know how an
object is represented, stored, located, or implemented, the change of the
object might require a change of the client (front end). Hiding the
information about obhjeect representations from the clients prevents the
cascading of changes.

5. Algorithms should be isolated, if they are likely to change. Algorithms
are often extended, optimized, and replaced during development and reuse.
Objects that depend on an algorithm will have to change when the algorithm
changes. Therefore, algorithms whould be isolated, if they are likely to
change, or be replaced or extended, etc.

6. Avoid monolithic systems. When classes are tightly coupled, then then
are hard to reuse in isolation, since tightly coupled they depend upon each
other. Tight coupling leads to monolithic systems. A monolithic system is
characterized as one where you can not remove or change a class withiout
understanding and changing many other classes. The system becomes a dense
mass that's hard to learn, port, anmd maintain. Techniques such as abstract
coupling and layering will promote loosly coupled systems.

7. Avoid customizing an object by use of subclassing. Defining a subclass
requires an in-depth understanding of the parent class. Every class has a
fixed implementation overhead (initialization, finalization, etc.).
Overriding one operation might require overriding of another. See
overriding in some other object language text. New functionality can be
added to an application by composing existing objects in new ways rather
than defining new subclassses of existing classes. And delegation can be
used to substitute for inheritance, for the purpose of combining behaviors
of objects. See object language text on delegation.

8. Maintain the convenient ability to modify classes. Keep track of source
code, and limit the number of subclassses which would require modification
under those circumstances of missing source code information about these
objects.


Try to avoid these causes of redesign.


"Crushed_Ice" <slipandslide@xxxxxxxxx> wrote in message
news:isadnbLudpOpqB_XnZ2dnUVZ_gadnZ2d@xxxxxxxxxxx
I learn a good deal from almost every book that I read. Although I have
bought about 7 books on How to Program Visual Basic, and I still can't
write
a decent program. using that book or Microsoft Visual Basic language. And
I
reading some books which are stating, it is not really possible to write
anything without having an inspection team to test your work for you. No
one can really do the criticism of himself (as programmer), any justice.

A whole school of people in the data mining camp, do not trust their
appreciation of stored data either. They just consider everything that
happens to be in a coud, and then they write a botnet program or something
to work out the details. Anything they write as a proposal is "We don't
know anything".

That reminds me of that televicsion show where the characters write a
proposal for a television show about nothing. So we go in there and the
pruducer says, "Well what's your television show about?" And we say,
"Nothing, We dont have any idea!"

Ok then Ok there's salsa and hula girls in the beer tent. Watch your
purses.

"Crushed_Ice" <slipandslide@xxxxxxxxx> wrote in message
news:-_ednYFC1Oa8E-PXnZ2dnUVZ_oadnZ2d@xxxxxxxxxxx
"Model checking is a technique for verifying finite state concurrent
systems
such as sequential circuit designs and communication protocols. It has a
number of advantages over traditional approaches that are based on
simulation, testing, and deductive reasoning. In particular, model
checking
is automatic and usually quite fast. "

The book by Edmund Clarke has been published at MIT Press.





.

Relevant Pages

  • Re: Testing your data access layer in another project part of same solution
    ... My problem is debugging DAL project (I'm using LINQ to SQL). ... Domain Driven Design and Test Driven Design. ... You need to find out how to use the ADO.NET Entity Framework an ORM ... FunctionalTest Project that has a project reference to the ClassLib project that contains ManageContacts.cs, a reference to a Test framework like MBUnit and a Test.cs in the project to test ManageContacts via the Test framework. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: OODesign - OPF, design pattern
    ... What I had in mind were very specific design patterns, ... It's under their control, for goodness ... but once I had reached a point where I could stop "tweaking" the framework to handle scenarios that I hadn't previously thought of the development time suddenly increased dramatically. ... once you zoom in even just a little, OO design reveals more layers. ...
    (borland.public.delphi.non-technical)
  • Re: Updating vb6/vba knowledge - too late to teach old dog new tricks?
    ... is a programming paradigm that uses "objects" and their interactions to design applications and computer programs. ... What is Unified Modeling Language? ... LINQ is a Microsoft .NET Framework component that adds native data querying capabilities to .NET languages. ... Microsoft LINQ defines a set of query operators that can be used to query, project and filter data in arrays, enumerable classes, XML, relational database, and third party data sources. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Testing your data access layer in another project part of same solution
    ... A unit test is about the simulation of object behavior within the domain for expected results with pre-written test cases against the domain -- Domain Driven Design and Test Driven Design. ... LINQ is a Microsoft .NET Framework component that adds native data querying capabilities to .NET languages. ... Microsoft LINQ defines a set of query operators that can be used to query, project and filter data in arrays, enumerable classes, XML, relational database, and third party data sources. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Testing your data access layer in another project part of same solution
    ... You're missing some layers. ... DAL that act upon the database model. ... Domain Driven Design and Test Driven Design. ... You need to find out how to use the ADO.NET Entity Framework an ORM ...
    (microsoft.public.dotnet.framework.aspnet)
Loading