Franciov Weblog

Share This

Popularity: 25% [?]

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

Popularity: 71% [?]

Share This

I just want to say hello to my neighbours at the “2000 Bloggers” project.

They are:

• Laurie Manny, from Long Beach, California, US
• Gordon, from San Angelo, Texas, US

:P

Popularity: 57% [?]

Share This

LOL!

Popularity: 36% [?]