Enterprise Integration Zone is brought to you in partnership with:

Behind DotNetBlocks.com is a software engineer with over 10 years of experience in Microsoft technologies and is currently obtaining a Masters in IT. His primary focus is typically on software architecture, web applications, and interactions amongst various systems. Todd is a DZone MVB and is not an employee of DZone and has posted 47 posts at DZone. You can read more from them at their website. View Full User Profile

Software Architecture Analysis Method (SAAM)

01.07.2013
| 3049 views |
  • submit to reddit
Software Architecture Analysis Method (SAAM) is a methodology used to determine how specific application quality attributes were achieved and how possible changes in the future will affect quality attributes based on hypothetical cases studies. Common quality attributes that can be utilized by this methodology include modifiability, robustness, portability, and extensibility.

Quality Attribute: Application Modifiability

The Modifiability quality attribute refers to how easy it changing the system in the future will be. This to me is a very open-ended attribute because a business could decide to transform a Point of Sale (POS) system in to a Lead Tracking system overnight. (Yes, this did actually happen to me) In order for SAAM to be properly applied for checking this attribute specific hypothetical case studies need to be created and review for the modifiability attribute due to the fact that various scenarios would return various results based on the amount of changes. In the case of the POS change out a payment gateway or adding an additional payment would have scored very high in comparison to changing the system over to a lead management system.

I personally would evaluate this quality attribute based on the S.O.I.L.D Principles of software design. I have found from my experience the use of S.O.I.L.D in software design allows for the adoption of changes within a system.

Quality Attribute: Application Robustness

The Robustness quality attribute refers to how an application handles the unexpected. The unexpected can be defined but is not limited to anything not anticipated in the originating design of the system. For example: Bad Data, Limited to no network connectivity, invalid permissions, or any unexpected application exceptions.

I would personally evaluate this quality attribute based on how the system handled the exceptions.

Robustness Considerations

  • Did the system stop or did it handle the unexpected error?
  • Did the system log the unexpected error for future debugging?
  • What message did the user receive about the error?

Quality Attribute: Application Portability

The Portability quality attribute refers to the ease of porting an application to run in a new operating system or device. For example, It is much easier to alter an ASP.net website to be accessible by a PC, Mac, IPhone, Android Phone, Mini PC, or Table in comparison to desktop application written in VB.net because a lot more work would be involved to get the desktop app to the point where it would be viable to port the application over to the various environments and devices.

I would personally evaluate this quality attribute based on each new environment for which the hypothetical case study identifies. I would pay particular attention to the following items.

Portability Considerations

  • Hardware Dependencies
  • Operating System Dependencies
  • Data Source Dependencies
  • Network Dependencies and Availabilities 

Quality Attribute: Application Extensibility

The Extensibility quality attribute refers to the ease of adding new features to an existing application without impacting existing functionality.

I would personally evaluate this quality attribute based on each new environment for the following

Extensibility  Considerations

  • Hard coded Variables versus Configurable variables
  • Application Documentation (External Documents and Codebase Documentation.)
  • The use of Solid Design Principles
Published at DZone with permission of Todd Merritt, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)