1 / 22

Presentation by: Martin Hoffman

“Assessing the Complexity of Software Architecture” Moshsen AlSharif Walter P. Bond Turky Al-Obtalby. Presentation by: Martin Hoffman. Problem. Primary activity of Software Architecture design is decomposition. Reduce complexity into manageable parts.

casey-mcintosh
Download Presentation

Presentation by: Martin Hoffman

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. “Assessing the Complexity of Software Architecture”Moshsen AlSharifWalter P. BondTurky Al-Obtalby Presentation by: Martin Hoffman

  2. Problem • Primary activity of Software Architecture design is decomposition. • Reduce complexity into manageable parts. • Process is an art form, not a defined procedure. • Architect must decide which component to process and how.

  3. Complexity • Intra-component complexity • Complexity within a component • Inter-component complexity • Complexity between components • Reducing intra-component complexity sometimes increases inter-component complexity.

  4. Purpose • Formulate a way to identify and calculate the complexity factors within inter and intra-complexity. • Compile a new metric to measure the overall complexity of the software architecture.

  5. Complexity Measurement • Complexity measurement methods can be categorized as: • Internal-code-based: source code of the modules is available • External: information or control-flow between modules is available • Hybrid-code-based: both source and flow information is available. • Goal is to measure complexity in the architecture design phase.

  6. Full Function Points (FFP) • FFP methodology is based on the Functional Size Measure (FSM), which is used to measure complexity. • FFP is used to evaluate the decomposition of systems. • FFP is able to measure intra- and inter-component complexity.

  7. FFP Functionality measurement • An architecture is made up of components • Each component contains a collection of services (functionality) that each component provides for other components. • These components affect the interface (external dependency) and internal work of each component. • Functionality measurement serves as an indicator of the internal and external complexity.

  8. #1 Weakness in FFP • Does not account for the number of other components a component interacts with. • Example: a functional process reads/writes to many other functional processes, FFP does not consider where that functional process resides. • FFP does not address coupling for identified components.

  9. #2 Weakness in FFP • FFP defines Read/Write data in reference to storage without distinguishing if that storage is local or shared between components. • Shared data has additional complexity.

  10. Resolution • #1: Count coupling as additional source of complexity but only in cases where the component is a client. (import) • #2: Identify components that write to shared memory (CW) and those that read (CR). Define coupling caused by shared data as (CW * CR).

  11. Steps to measure Software Complexity • Identify the components of the architecture. • Identify the functional processes of each component. • Identify the sus-process of each functional process. • Compute the Component Complexity CXi of component i. • Compute the Component Coupling CCi of component i.

  12. Steps to measure Software Complexity - continued • If Shared data is used, compute complexity and coupling effect on system • Model the system complexity and coupling as vectors. A system w/ n components and m shared data would result in n+m complexity terms and n+m coupling terms. • Compute System Complexity SX and System coupling SC using Euclidean norm distance formula.

  13. Example – KWIC • Key Word In Context (KWIC) • Inputs: set of text lines • Human Species • Have Failed • Output: all circular shifts of these lines in alphabetical order. • Failed Have • Have Failed • Human Species • Species Human

  14. Shared Data Architecture Communication between modules using Shared memory.

  15. Shared Data Architecture Moderate Component complexity, High Coupling due to shared data solution. Poor attention to the reuse Quality Attribute

  16. Abstract Data Type Architecture Internal module implementation is hidden. Internal data representation is protected. Access functions are the only way to store and retrieve data.

  17. Abstract Data Type Architecture More complex solution resulting in more components but less coupling. Better reuse and modifiability.

  18. Implicit Invocation Architecture Based on the abstract data, using an active data model. Data triggers events to interested components.

  19. Implicit Invocation Architecture More Component complexity but less Coupling.

  20. Pipe and Filter Architecture Data flow approach.

  21. Pipe and Filter Architecture Low complexity and coupling. Better architecture than previous examples.

  22. Conclusion • The new FFP can be used to measure the complexity of alternative architectures. • Complexity can be determined early in the architecture life-cycle.

More Related