Database Systems: The Complete Book

Database Systems: The Complete Book

Impedance Mismatch

Impedance Mismatch


I have observed that a large number of fresh Canadian Graduates have difficulty in adopting the Software Engineering Basics. In particular they have the peoblem in the following ares.

1.0 UML Modeling
2.0 Usage of any Class Librray
3.0 Design Patterns
4.0 Testing Methodology
5.0 System Integration
6.0 Release Control
7.0 Effective Communication.

Im gathering Information as to what can be done about this gap in theory and practice.
The gap I call Impedence mismatch. More on this later.

UML Framework Repository

UML Framework Repository


I am looking at ways to make UML-2.0 Based repository to work to be effective in Our work.

I also in the process of gathering success stories of the groups that have used pattern frameworks.

Agile Modeling and Business Modeling

Agile Modeling and Business Modeling


I just Picked up the following Books for the Project:
1.0 Agile Modeling - Scott Ambler
2.0 Agile database Tehniques - Scott Ambler.
3.0 Business Modeling with UML- Hans-Errikson et al.

I will discuss at leagth the Merits and summary of Each methods.

Debugging Complex CSS Scripts

Debugging Complex CSS Scripts


admin - Posted on 05 October 2008

I have to debug large chuncks of CSS for the Drupal and Jommla Templates and it is always a challenging task.
Fortunately I found the Firefox Web development tools and made the work manageable.

I highly recommend these tool sets.

This one suggested by Dirk

This is My Favourite

Jommla CSS Debugging Tips

Here is some information about the quirk modes-IE7/FF-3.07.

Beyond Software Architecture

Beyond Software Architecture


I just finished reading this book, in the holidays. Informatiove is the word. I recommend any one starting SOHO software business to read this book. Also Note There is anew web site for the Book annd Luke. The bottom line is you can not remove the human and marketing aspect from software development. It is an excellent book- worth reading especially by person who is not exposed to marketing of software. Get work Luke. 

Informational Modeling and Relational Database


I am introducing Object Relation Modeling( ORM) as a process bfore UML based modeling can be used in Enterprise based modeling. 

The reference that I am using is : 

1.0 Information Modeling and Relational Databases- Using ORM with ER and UML- Terry Halpin- ISBN- 1-55860-672-6 

In the first few chapters the information modeling seems an extention of semantic Modeling. 
The author seems to suggest that we it is simpler to go from ORM based semantic modeling to Relational Entity- Relation Modeoing of Chen. I am not clear at this point hos this is done. 
also since the ORm model gets big very quickly how do we control hierarchyy and multi page diagrams. More on this later. 

Test Driven Development

Test Driven Development


Paul Watson, of CodeProject fame, recently asked:

Part of an agile development* process is the test first[^] mindset: You write code which tests code you have yet to write. The test aims to fail the code and you evolve your code until it passes. Testing is normally done via automated unit tests.

Is anyone here using this methodology? How do you find it to be in practice?

Also do you have any good, practical examples of it? The descriptions are all spiffy and what but useful examples are hard to come by.

Check out the replies here.

My response was as follows:

I've tried, and I have three problems. The first is with the way I think. I do not think in terms of test first. I think in terms of object graphcs, and so that's what I code first. If I try to write tests first, I haven't a clue what the test should be because I haven't designed the object graph yet.

And there's the corallary--I don't design on paper, or UML, or whatever. I design by coding. Now, 20 years ago, sure, I would design on paper first. But not only is my experience vastly greater, the tools are so advanced that design tweaks are quite quick.

And the second corallary is that architectural problems that do surface would not usually surface during design, because either the architecture is simple enough that it 1) doesn't need to be refactored or 2) is easily refactored. The third case, complicated architecture that needs refactoring, doesn't really surface until later in the development cycle. The reality of development is that software is not 100% defined up front.

So, the second problem is, unit tests add a maintenance burden. I personally prefer to add unit testing after I have done the major architectural refactoring, otherwise the unit tests need to be rewritten as well. So I write the unit tests "in the middle" of the software development process, when the architecture is mostly solid but the internal implementation might still be in flux.

The third problem is that for complex software, NUnit doesn't cut it. For example, I just wrote a unit test that validates a complex client-server interaction. While I can unit test the client stuff and unit test the server stuff, I need ALL the pieces working IN SEQUENCE to test the entire workflow. Ironically, having written the unit tests for each of the pieces, it was only when I tested the entire workflow that I discovered I had a nasty interaction between to of the pieces that were supposedly separate. Thus, I use my AUT[^] tool (shameless plug), even though it's missing many of the niceties, like command line execution, that NUnit has. And writing unit tests when the tests depend on large pieces of the architecture to be implemented and working, well, first off, they're not exactly unit tests, more like workflow tests, but they're equally, if not more, important. Many, many times, it's the specific sequence of actions that breaks the software, which individual unit testing can't test for because unit tests simply do not cover 100% of the use cases.

Formal Specification and Research

Formal Specification and Research


Formal Specification has long history in the academic field. It is interesting that large amount is research is done in academics regarding formal specification

UML/SDL are actually implementation of the Formal specification in the Graphical Domain.

If you are interested in the research aspect of the formal specification and systems engineering please follow this link.

Please remember these are research tools at the present moment.
The ideas and projects will give you future directions to come in Software Engineering and Systems Engineering discipline.

Formal Specification can be used for Hardware Design for such language as VHD/Verilog/SystemsC and also in software design such as C++/C#

Formal Specification has not entered the Formal HYPE CYCLE ( still considered sissy-IE. difficult to understand) as they say it in academics.

Related Link:

Software Reuse- Architecture, Process and Organization for Business Success

It is one of the MUST READ Books, if you have any thing to do with software. I recommend it very much. The book is dated, but the contents are very valid
Authors: Ivor Jacobson, Martin Griss, Patrick Johnsson

ISBN- 0-201-92476-5

Also look into- Why software reuse has failed historicaly

Page 8 of 10
Go to top