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:
http://nms.lcs.mit.edu/Larch/

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

http://www.cs.wustl.edu/~schmidt/reuse-lessons.html

WEBSITES FOR DEVELOPERS

Software Engineering

 Software Engineering

Extreme Programming Explained

 Extreme Programming Explained

 

I am just going throug the book Extreme Progrmmaing Explained. Kent Beck Second edition,

I will post the Summary below.

I am also going throught the book called Extreme Programming Iconix Process.

The Iconix Process in my opinion is most prctical and readily appplicable to our Process at Keen Compuyet solutions. The best part is Iconix Process can be readily applied with Inexpensive Enterprise architect Software Development Toolset. 

 

Refrences:

1.0 Extreme Programming Explained- Beck & Andres 

Software Engineering

Software Engineering is concerned with software development of large scale systems. Software Engineering Involves programming, modeling, tools, people, process and methodologies to design, operate build na dmaintain large and complex haterogenous software systems. Software engineering deals with indiustrial scale software development problems.

We use various design techniques such as agile methods and ULM and design Architectural design patterns of accomplish software design. We work in various market segments such as website Design, electronic commerce design and ERP systems. We work with PHP- Asp.net and Java Technologies.

Our primary focus is on  content management system based Website,  Enterprise E-commerce Solutions and ERP  systems.  We adhere to Lean six sigma methods of continuous learning and improvement.

 Software engineering draws it s content from Computer Science, Electrical and Computer Engineering and project management methods.

MySQL Database Programming

MySQL Database Programming

Page 8 of 9
Go to top