SE News

Agile Modeling (AM) is a practice-based methodology for effective modeling and documentation of software-based systems. Simply put, Agile Modeling (AM) is a collection of values, principles, and practices for modeling software that can be applied on a software development project in an effective and light-weight manner. Agile models are more effective than traditional models because they are just barely good enough, they don’t have to be perfect. You may take an agile modeling approach to requirements, analysis, architecture, and design.

AM is not a prescriptive process, in other words it does not define detailed procedures for how to create a given type of model, instead it provides advice for how to be effective as a modeler. AM is not about less modeling, in fact many developers will find that they are doing more modeling following AM than they did in the past. AM is “touchy-feely”, it’s not hard and fast - think of AM as an art, not a science.

The goals of AM are:

- To define, and show how to put into practice, a collection of values, principles and practices pertaining to effective, light-weight modeling. - To address the issue of how to apply modeling techniques on an software projects taking an agile approach such as eXtreme Programming (XP), Dynamic Systems Development Method (DSDM), or SCRUM. - To address the issue of how to model effectively on a Unified Process (UP) project, common instantiations of which include the Rational Unified Process (RUP) and the Enterprise Unified Process (EUP).

Scott Ambler

http://www.agilemodeling.com/index.htm

This article addresses key elements of SOA definition, implementation, and rollout and some of the resulting issues that have to be addressed by the IT organization throughout this process.

Brent Carlson, Dmitry Tyomkin

http://www.bijonline.com/PDF/carlson%20%20tyomkin.pdf

The UML is relatively trivial and unimportant. Surprised by that statement? Many are, but we shouldn’t be. Nor should the statement be misinterpreted as implying the UML is not useful - it is.

But perspective is critical. The Unified Modeling Language (UML) is merely a standard diagramming notation: boxes, bubbles, lines, and text. The Object Management Group (OMG) UML specification calls it “a standard way to write a system’s blueprints,” and the term blueprints is an apropos choice. Civil and electrical engineers have standard diagramming languages to illustrate the structure and wiring in a building. We do not equate the ability to read and write standard blueprint diagramming languages with the knowledge and skill to envision and design a building - to be an architect or engineer.

Craig Larman

http://www.fawcette.com/javapro/2004_03/magazine/features/clarman/

The software product line approach is a strategy for producing software-intensive products. The strategy encompasses organizational management, technical management, and software engineering aspects of product production. Object technology can make an important contribution to the success of a product line organization. In this paper these contributions are described in terms of an example product line.

John McGregor

http://www.jot.fm/issues/issue_2004_03/column6

Many hail service-oriented software as the next revolution in software development. Web services’ capabilities are constantly expanding from simple message passing toward the construction of full-fledged applications such as those envisaged by the UK’s Pennine Group in their Software as a Service (SaaS) framework.

These new, service-oriented approaches appear to many to solve the significant issue of software inflexibility that arises during maintenance and evolution. While they address some aspects of the problem, however, understanding the software still poses some difficulty. This shift toward service orientation compels us to consider its implications for software understanding, which is potentially the primary cost in software engineering.

Nicolas Gold, Andrew Mohan, Claire Knight, Malcolm Munro

http://www.computer.org/software/homepage/2004/s2gold1.htm

In the Java community there’s been a rush of lightweight containers that help to assemble components from different projects into a cohesive application. Underlying these containers is a common pattern to how they perform the wiring, a concept they refer under the very generic name of “Inversion of Control”. In this article I dig into how this pattern works, under the more specific name of “Dependency Injection”, and contrast it with the Service Locator alternative. The choice between them is less important than the principle of separating configuration from use.

Martin Fowler

http://www.martinfowler.com/articles/injection.html

In this first in a three-part series of sample recipes from Secure Programming Cookbook for C and C++, the authors offer nine basic rules for proper data validation, which they recommend all programmers should follow. From their first rule: “Assume all input is guilty until proven otherwise” to their last: “The better you understand the data, the better you can filter it,” the advice presented here will help programmers keep unwanted, malicious data out of their applications.

Matt Messier, John Viega

http://www.oreillynet.com/pub/a/network/excerpt/spcookbook_chap03/index.htm l

As software-intensive systems become more pervasive, more and more safety-critical systems are being developed. In this column, I will use the concept of a quality model to define safety as a quality factor. Thus, safety (like security and survivability) is a kind of defensibility, which is a kind of dependability, which is a kind of quality. Next, I discuss the structure of quality requirements and show how safety requirements can be engineered based of safety’s numerous quality subfactors. Then, I define and discuss safety constraints (i.e., mandated safeguards) and safety-critical requirements (i.e., functional, data, and interface requirements that can cause accidents if not implemented correctly). Finally, I pose a set of questions regarding the engineering of these three kinds of safety-related requirements for future research and experience to answer.

Donald Firesmith

http://www.jot.fm/issues/issue_2004_03/column3

Understanding the thirteen diagrams of UML 2.x is an important part of understanding OO development. Although there is far more to modeling than just the UML the reality is the UML defines the standard modeling artifacts when it comes to object technology.

Scott Ambler

http://www.agilemodeling.com/essays/umlDiagrams.htm

The wildly popular J2EE application server goes from full steam to mainstream with a GUI-based IDE that plugs into the Eclipse development framework.

Javid Jamae

http://www.devx.com/opensource/Article/20242

SA4J is a technology that analyzes structural dependencies of Java applications in order to measure their stability. It detects structural “anti-patterns” (suspicious design elements) and provides dependency web browsing for detailed exploration of anti-patterns in the dependency web. SA4J also enables “what if” analysis in order to assess the impact of change on the functionality of the application; and it offers guidelines for package re-factoring.

http://www.alphaworks.ibm.com/tech/sa4j

The next version of Visual C# will include a code refactoring tool that can make productivity-enhancing changes to the layout and structure of your code, such as extracting interfaces or encapsulating a field, and can automate common coding tasks.

Juval Löwy

http://www.devx.com/codemag/Article/20143

The long-awaited third edition of the best-selling UML book on the market; fully-updated and compliant with UML 2.0. This eagerly-anticipated third edition gets students thinking about efficient object-oriented software design using the latest version of the industry-standard for modeling software: UML 2.0. The author has retained the book’s convenient, concise format that has made it an essential resource in courses introducing UML. The book describes all the major UML 2.0 diagram types, what they are intended to do, and the basic notation involved in creating and deciphering them. A true treasure for the software engineering community.

Martin Fowler

http://www.aw-bc.com/catalog/academic/product/0,4096,0321193687,00.html

By now we know that application integration is important, thus there is not much need for me to restate that here. What is not as well understood is the amount of planning and coordination that needs to occur in order to pull off application integration today, EAI or B2B, this, despite the availability of some pretty good technology that can make short work of joining systems together.

Moreover, while many are interested in application integration few have taken the time to read books such as this, or the books I’ve written in the past, to better understand both the limitations and the opportunities. More often than not application integration architects are driven more by the hype around the emerging standards and technology and less by their business needs and technology requirements. The end result is many failed projects, more due to lack of knowledge than lack of technology.

David Linthicum

http://www.aw-bc.com/catalog/academic/product/0,4096,0201844567-PRE,00.html

Vorig jaar werd de overname van SERC door CIBIT gevierd met het seminar ‘Ervaringen met architectuur’ in het Singer theater in Laren. Een succesvol seminar dat voor herhaling vatbaar was. Daarom organiseren wij dit jaar het tweede jaarlijkse CIBIT|SERC event.

Het programma staat dit jaar in het teken van ‘Effectieve ICT organisaties’. De afgelopen jaren heeft binnen veel ICT organisaties de nadruk sterk gelegen op kostenreductie. Langzaamaan groeit nu echter het inzicht dat kosteneffectiviteit alleen niet voldoende is. Kwaliteit en innovatievermogen zijn de andere sleutelbegrippen: een effectieve ICT organisatie levert producten en diensten met de juiste kwaliteit en is in staat om adequaat te verbeteren en te innoveren.

http://www.cibit.nl/site.nsf/page/ict_seminars_2004_seminar_11_mei_effectie ve_ict_organisaties