Software Architecture: Design Decisions
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Software Architecture: Design Decisions

  • 5,144 views
Uploaded on

This is an introductory lecture to Software Architecture Design Decisions, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)

This is an introductory lecture to Software Architecture Design Decisions, part of the Advanced Software Engineering course, at the University of L'Aquila, Italy (www.di.univaq.it/muccini/SE+/2012)

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,144
On Slideshare
5,142
From Embeds
2
Number of Embeds
1

Actions

Shares
Downloads
148
Comments
0
Likes
1

Embeds 2

http://www.scoop.it 2

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Università degli Studi dell’AquilaL06: Design Decisions Henry Muccini DISIM Department, University of L’Aquila henry.muccini@univaq.it
  • 2. The material in these slides may be freely reproduced anddistributed, partially or totally, as far as an explicitreference or acknowledge to the material author ispreserved.Some of the slides have been originally made by prof.Patricia Lago.Thanks to Smrithi for the discussion we had on the topic Henry Muccini
  • 3. Intro to SA Intro to Software TestingSA Case study Structural TestingSA style Model-based TestingADLs Architecture-based TestingDesign Decisions LabViews/ViewpointsUML Non Functional S.E.UML Profiling Performance modelingLab Performance analysis
  • 4. Software ArchitectureThe Software Architecture is the earliest model of thewhole software system created along the softwarelifecycle“Traditional” definition: →A set of components and connectors communicating through interfaces“Recent/Future” understanding: →A set of architecture design decisions taken to generate the architecture artifact →Focus on set of Views and Viewpoints, looking at stakeholders and their concern
  • 5. Architecting todayArchitecting is the process of creating softwarearchitecture knowledge and artifacts for engineeringsoftware systemsA Software Architecture consists of →A blueprint for the chosen solution (product) →A set of design decisions (co-product)
  • 6. Architecture as a set of Design Decisions
  • 7. Design Rationale and Design DecisionDesign is a problem-solving process whoseobjective is to find and describe a way: To implement the functional requirements... while respecting the non-functional requirements and yet deliver good qualityThe result of software Design: A blueprint for the chosen solution (product) A set of design decisions (co-product)
  • 8. A designer is faced with a series of design issues These are sub-problems of the overall design problem. Each issue normally has several alternative solutions (or design options) The designer makes a design decision to resolve each issue.This process involves choosing the best optionfrom among the alternatives.
  • 9. Taking decisions Design problem Problem space sub- sub- problem problem (or issue) (or issue)Decision =best option Design Design option option Design option Design option Solution space Decision = Alternative Alternative best option solutions solutions Best, with respect to some criterion
  • 10. Design spaceThe space of possible designs that could be achievedby choosing different sets of alternatives. client-server fat-client web browser architecture peer clients based styleclientstyle thin-client custom client program peer-to-peer structured p2p rich-client layered unstructured p2p ... hybrid p2p tiered
  • 11. Taking decisions /2To take each design decision, the software engineeruses: →“current” knowledge ─ the requirements ─ the design as created so far →and “past” knowledge ─ the technology available ─ what has worked well in the past ─ software design principles and “best practices”
  • 12. Collection of Requirements and Constraints Identification of Design Issues Identification of Design Alternatives Identification of Design Decisions (DDs) Selection of architectural Components Selection of an architectural Solutions that comply tothe DDs
  • 13. Design Issue 1: how many gateways shall be used to collectsensored data in a building?Design Issue2: how to propagate the collected data to thefire station?Design Issue 3: how the sensors are connected?Design Issue 4: how the sensors should be powered?Design Issue 5: how to sense how many people are presentin the building?…
  • 14. Design alternatives Criteria Design Issue Single Gateway Cost DI1: how manygateways shall be 1 gateway per Reliability used to collectsensored data in a floor building? Availability 1 Gateway per apartment
  • 15. DD1: one gateway per floorDD2: WANDD3: Wireless LanDD4: batteryDD5: countingsensors…
  • 16. DD1: only one gatewayDD2: WANDD3: LANDD4: batteryDD5: counting sensors…
  • 17. Why DD?According to Anton Jansen and Jan Bosch [4], definingArchitecture as a set of design decisions helps thearchitect to: a. Guard the conceptual Integrity of the Software architecture b. Communicate effectively the design space exploration c. Effectively analyze the software architecture and design process d. Trace design decisions and their relationship to the resulting architecture.
  • 18. Notations and ToolsArchium: A meta-model and tool developed my Anton Jansen et alADDSS: a web based tool developed by Rafael Capilla et alAREL: a rationale based model developed by Antony Tang et alDAMSAK: Data Model for Software Architecture Knowledgedeveloped by Babar et alPAKME : a tool that supports DAMSAKSEURAT: Software Engineering using Rationale, which integrates toolsfor rationale capture, visualization, and use into a standard softwareengineering environment
  • 19. QOCQuestions, Options, Criteria Questions: key design issues Options: possible answers Criteria: assess and compare the options
  • 20. ExampleQOC3 Which technology should be used by the user tocommunicate locally with the devices which arelocated at home?
  • 21. QOC3 Which technology should be used by the user tocommunicate locally with the devices which arelocated at home?
  • 22. QOC Template (Open the Excel File)
  • 23. ADD: what is interesting to discuss?1. Granularity of design decisions2. Dependencies among decisions3. ADD taken in a collaborative way4. ADD that uses genetic algorithms in order to find the optimal solution5. Evolving ADD
  • 24. Granularity…ADD Question: How the FireFighter system components shall communicate? How is the payment handled?
  • 25. Dependencies… Single GatewayDI1. How many Cost Reliability DI2. how thegateways can we 1 Gateway per floor sensors are Installation Wiredplace? Availability connected? Performance 1 Gateway per apartment Wireless Wi-Fi Cost Availability Enables question Wireless Using gatewaysDI3.How should Reliability ZigBeedata be broadcasted Directly through Availability sensors Enables decision Wearable sensor Which device can the Firefighter Use? Mobile-Wi-Fi Online map Reliability Best way to get a city map for the Performance truck manager Local offline GPS device Availability Enables decision
  • 26. Dependencies…Are of various types: • Excludes • Requires • Depends On • Subsumes • Enables • … Con#1: Which kind of technology is used for node-to-node communication? Con#1-Opt#1 : Bluetooth Con#1-Opt#2 : Wi-Fi Con#1-Opt#3: Zigbee Con#5: How the WSN infrastructure shall communicate with the trucks and central station? Con#5-Opt#1 – 3G Con#5-Opt#2 – GPRS Con#5-Opt#3 – Wi-Fi
  • 27. Collaborative Decision Making http://saw.inf.unisi.ch/drupal/home
  • 28. Collaborative Decision Making
  • 29. Optimal Solution to ADDTariq Al-Naeem, Ian Gorton, Muhammed Ali Babar, Fethi Rabhi and Boualem Benatallah. “A Quality-DrivenSystematic Approach for Architecting Distributed Software Applications”. In Proc. ICSE 2005.
  • 30. Evolving ADDRequirements, Concerns, technology evolves, and sothe associated design decisions.Con#2: How the nodes should be powered? • Cr#1 – Cost • Cr#2 – nodes life duration • Cr#3 – availability • Opt#1 : Battery • Opt#2 : Electrical network