Franciov Weblog

Share This

This is the title of the seminar held in Rome at the University “Tor Vergata”, on June 19 2007, by Philippe Kruchten, the Director of Process Development (RUP) at Rational Software (IBM) and Professor of Software Engineering at University of British Columbia in Vancouver, Canada.

It was a very interesting seminar due to the fact that software architecture was still something vague for me (i.e. a computer engineering student much interested in software engineering but who has never handle with projects big enough to need a significant effort in making the architecture).

In his seminar, first of all Kruchten tried to give a definition of Software Architecture coming to the following conclusion:

Software architecture encompasses the significant decisions about:

• the organization of a software system,
• the selection of the structural elements and their interfaces by which the system is composed together with their behaviour as specified in the collaboration among those elements,
• the composition of these elements into progressively larger subsystems,
• the architectural syle that guides this organization, these elements and their interfaces, their collaborations, and their composition.

Software architecture is not only concerned with structure and behaviour, but also with usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints and tradeoffs, and aesthetics.

Although this definition of Software Architecture seems to be comprehensive, surely it is not so easy to understand at the first reading. A simpler definition could be the following:

Architecture is about making decision.

Then Kruchten focused on what architects actually do.

The life of a software architect is a long (and sometimes painful) succession of suboptimal decisions made partly in the dark.

Architects should spend their working time in the following manner:

• 50% Architecting (design, validation, prototyping, documenting, etc.)
• 25% Getting input (from user requirement, other architecture, technology)
• 25% Providing Information (communicating architecture, assisting other stakeholders).

The right balance among these activities is very important in order to not fall in typical situations in which architects don’t know anything about existing technology, or don’t communicate their work to designers.

It’s clear that decision is the key word for Software Architecture, therefore Decision Models, Decision Visualizations and Design Decision Capture Mechanisms are the key tools for architects. Refining models, languages and mechanisms concerning decisions is the purpose of Software Engineering Research in this area.

Popularity: 45% [?]

Share This

«If you ever admired those colleagues who stayed in office for more than 10 hours day by day, you should consider the fact that after a specific amount of work time bug rates increase dramatically and work results tend to reach lowest levels. Thus, working too hard for a long period of time could even have a negative effect.» Michael Stal

Popularity: 55% [?]

Share This

PASSI (a Process for Agent Societies Specification and Implementation) is a step-by-step requirement-to-code methodology for designing and developing multi-agent societies integrating design models and concepts from both OO software engineering and artificial intelligence approaches using the UML notation. The models and phases of PASSI encompass anthropomorphic representation of system requirements, social viewpoint, solution architecture, code production and reuse, and deployment configuration supporting mobility of agents. The design process with PASSI is supported by PTK (PASSI ToolKit) which is composed by an add-in for Rational Rose and a tool for reusing patterns of agents. [The PASSI Design Process]

I have recently followed the PASSI process to develop an Architecture for Context-Dependent Information Systems, as a component of the middleware layer (the layer between the transport and the application layer). JADE has been the framework I used to work with agents.

JADE (Java Agent DEvelopment Framework) is a software framework fully implemented in Java language. It simplifies the implementation of multi-agent systems through a middle-ware that claims to comply with the FIPA specifications and through a set of tools that supports the debugging and deployment phase. The agent platform can be distributed across machines (which not even need to share the same OS) and the configuration can be controlled via a remote GUI. The configuration can be even changed at run-time by moving agents from one machine to another one, as and when required. The only system requirement is the Java Run Time version 1.4 or later. [JADE Homepage]

I must say that I’m impressed with how much the PASSI process can be so powerful in its semplicity. Have a look at the PASSI Home Page to find out how the steps you have to follow are easy to understand and to put in practice. The partition in five models allows designers to look at the multi-agent system in different ways. The models are: System Requirements Model, Agent Society Model, Agent Implementation Model, Code Model, and Deployment Model. For more information have a look at the PASSI lifecycle.

Looking at the documentation, it would seem that PASSI is a waterfall process, but it is not. PASSI is iterative, sequential and top-down, as the authors (M.Cossentino and C.Potts) write in paragraph 2.2 of the research paper about it. There are two kinds of iteration in PASSI. The first one is related to requirement elicitation and involves dependencies among the System Requirements Model, the Agent Society Model and the Agent Implementation Model. The second type of iteration is related to Multi-Agent System Implementation and takes place inside the Agent Implementation Model in the manner shown in figure.

PASSI has been very helpful to me for developing a well-structured agent-based software application. In particular the Deployment Model helped me to get the picture of the software I was on the point to develop. I’ve been run the Deployment Configuration phase (the only one of Deployment Model) during the phases of Agent Implementation Model because I needed to understand how effectively components (placed in different containers) could communicate among themselves. Moreover, since the application I developed implied agent mobility, I needed some deployments diagrams to describe any constraints on migration and mobility, in order to describe the behaviours of module providing mobility.

PASSI is without doubt a good process to follow but the online documentation about iterations and phases overlap is not clear enough. That’s why I have just written this post!

Popularity: 48% [?]

Share This

This is the book that introduced me in the Rational Unified Process. Moreover I must point out this interesting whitepaper, complete and well-structured, and these ootips about RUP. Here follows how I see it.

Rational Unified Process is not just a process, but also a product of the process, developed and continuously updated by Rational Software and integrated with its software development tools. It is certainly a complete approach to build software with good quality and respecting user needs.

Anyway RUP could lead up to useless work or artefacts for the birds: as often as not it’s better to do not. To avoid to work for nothing, you shouldn’t follow the process blindly but configure the process framework to make RUP as slender as possible. Anyway, perhaps, small (and medium?) projects need something simplier.

Popularity: 21% [?]

Share This

September is a month full of exams here in University of Rome “Tor Vergata”. I’m studying hard about Software Engineering, in particular about V&V and Software Testing, with the assistance of Ian Sommerville’s book (”Software Engineering 7″). Now I’m reading up on Rational Unified Process and working with tools as Rational RequisitePro and Rational Rose. I’m very interested in it and I’ll write a post about RUP as soon as possible.

Popularity: 21% [?]