Analysis and Design of Software Architecture Essay

Custom Student Mr. Teacher ENG 1001-04 21 March 2016

Analysis and Design of Software Architecture

Outline
1 2 3 4 5 6 7 8

Development Process Requirements Quality Attributes Runtime QA Non-runtime QA Requirements Analysis: Example Architectural Analysis & Design Architectural Views

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

2 / 78

Development Process

Methodology

Different software development processes have software architecture as a part of the process Rational unified process Spiral development method Agile development method Evolutionary rapid development

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

3 / 78

Development Process

Place of SA in SDP

Figure: Source: Software Architecture Primer by Reekie, McAdam Denis Helic (KMI, TU Graz) SA Analysis and Design Oct 19, 2011 4 / 78

Development Process

Methodology

After the initial requirements analysis but before software design The first architecture is also a communication basis with the customer Inputs for the development of the architecture: 1 2

Requirements Context (technical, organizational, business, …)

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

5 / 78

Requirements

Analysis

At the beginning there is always a customer who wants a specific software system Customer “wishes” are always informal Interviews, some documents, some Excel tables, … We need to analyze such informal records and structure it Requirements engineering is a huge field but we just illustrate here one possibility

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

6 / 78

Requirements

Analysis

The results of the requirements analysis:
1 2

Functional requirements Non-functional requirements
(a) Runtime qualities (b) Non-runtime qualities

3

Contextual requirements

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

7 / 78

Requirements

Functional requirements

A technical expression of what a system will do Arise from stakeholder needs Structured language: software requirements specification Use cases: structured description of user interactions with the system Formal models: e.g. state-charts

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

8 / 78

Requirements

Non-functional requirements

Other needs than directly functional or business-related Generally expressed in the form of quality-attributes Runtime quality attributes Non-runtime quality attributes

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

9 / 78

Requirements

Contextual requirements

What technology is available? Expertise of the development team Previous experience of users/customers Technical, business, market, legal, ethical, …

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

10 / 78

Quality Attributes

Need to address QAs

Without any need for performance, scalability, … any implementation of functionality is acceptable However, we always need to take into account the broader context E.g. hardware, technological, organizational, business, … The functionality must be there but without proper addressing of QA it is worth nothing

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

11 / 78

Quality Attributes

Influence on QAs

Typically, a single component can not address a QA completely Any QA is influenced by multiple components and their interactions E.g. a UI component has a high degree of usability: however, usability of the system is compromised if a data management component has poor performance in accessing the data → users need to wait long → poor usability Components and their interactions → software architecture QAs are directly influenced by software architecture

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

12 / 78

Runtime QA

PURS

PURS (performance, usability, reliability, security) Performance: time performance, memory, disk, or network utilization Usability: human factors, easy to learn, easy to use, … Reliability: availability, safety, … Security: authentication, data protection, …

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

13 / 78

Runtime QA

Performance

Time performance is most obvious Measured in the number of operations per second Also, latency: the time from receiving an input and producing an output Other measures: memory, disk, network utilization or throughput

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

14 / 78

Runtime QA

Performance

Different measures are typically traded off against each other E.g. increasing throughput may increase latency Time performance might be increased with more memory True performance of the system is not only defined by performance of single components But also by their interactions and the overall processes in the system

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

15 / 78

Runtime QA

Performance factors

Choice of algorithms Database design Communication Resource management

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

16 / 78

Runtime QA

Choice of algorithms

Performance of algorithms is measured by their complexity (big O) E.g. linear complexity: O(n) Running time increases in direct proportion to the size of the data E.g. polynomial complexity: O(n2 ) It does not scale: double size of the data – running time increased by factor of 4 Goal: O(nlog (n))

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

17 / 78

Runtime QA

Database design

Performance of database queries can dominate the overall performance The design of the tables has enormous impact on the overall performance Techniques to improve it: lazy evaluation, replication, caching Some additional cost to manage replication and/or caching In-memory databases (real-time systems) Developing a new database (search engines)

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

18 / 78

Runtime QA

Communication

Network overhead Package data according to a protocol, sending data over network Each layer means additional overhead Think how to use network: packaging binary data as XML!? Use more compact formats, e.g. JSON vs XML

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

19 / 78

Runtime QA

Resources management

Overloaded components need to be avoided A chain is only as strong as its weakest link! E.g. a single-threaded shared resource is in use: all other threads are blocked Very difficult to track down

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

20 / 78

Runtime QA

Usability

Usability is a very rich field If usability is important you will need a usability expert Combination of many factors: responsiveness, graphical design, user expectations, confidence Measuring with time taken to complete task, error rate, time to response, …

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

21 / 78

Runtime QA

Responsiveness and data availability

An example of relations between QAs Usability requires that the system responds to user actions within a certain period of time If it is a complex system this need translates into performance along the path of the user action

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

22 / 78

Runtime QA

Responsiveness and data availability

Figure: Usability vs. Performance Source: Software Architecture Primer by Reekie, McAdam

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

23 / 78

Runtime QA

Discussion on relations between QAs

This diagram shows that we need to pay attention to tuning communication
between B and Y Performance of the communication channel is a consequence of a usability requirement Do we need to support security of the communication channel?

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

24 / 78

Runtime QA

Discussion on relations between QAs

This diagram shows that we need to pay attention to tuning communication between B and Y Performance of the communication channel is a consequence of a usability requirement Do we need to support security of the communication channel? We support QAs always only as a response to user needs Never because it is needed anyway!

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

24 / 78

Runtime QA

Discussion on relations between QAs

If we support security even if it is not needed Very often QAs exercise
opposing forces on the system Security requires a lot of checking: performance will suffer → usability will suffer A minimalistic approach: develop only what is required!

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

25 / 78

Runtime QA

Reliability

In traditional engineering disciplines reliability measures the failure rate of the system Failure rate specified by mean time to failure MTTF A related measure: mean time between failures MTBF MTTR is mean time to repair A is availability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

26 / 78

Runtime QA

Reliability

MTBF = MTTF + MTTR A= A=
MTTF MTBF MTTF MTTF +MTTR

E.g. expected availability of Web systems:

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

27 / 78

Runtime QA

Reliability

MTBF = MTTF + MTTR A= A=
MTTF MTBF MTTF MTTF +MTTR

E.g. expected availability of Web systems: 1 (always up-and-running) =⇒ MTTF → ∞

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

27 / 78

Runtime QA

Reliability

Increasing reliability involves testing However, impossible to prove that a system is correct, i.e. without bugs Acceptability of errors depends on the nature of a system Personal desktop use: bugs are typically tolerated Enterprise level: medium reliability level High-reliable systems: bugs can be fatal

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

28 / 78

Runtime QA

Security

Increasingly important aspect of systems is security Because systems are exposed to threats Especially networked systems As with other QAs security is a set of related responses to user needs

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

29 / 78

Runtime QA

Authentication

Requirement for identification of users with a system Users present credentials so that the system can identify them Typically username and password Other forms: certificates, smart cards, biometric features

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

30 / 78

Runtime QA

Authorization

After authentication authorization which functions and what data is available for users This information is captured in an authorization model Access control lists (ACL) define who can access and how a resource might be accessed E.g. read access, write access, delete access, …

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

31 / 78

Runtime QA

Authorization

Drawbacks of ACLs It is resource based, e.g. a page in a CMS Often, authorization needs to address functions or tasks Also, managing of ACLs is difficult, e.g. subresources of resources Also, performance problems with checking

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

32 / 78

Runtime QA

Authorization

Another model: role-based access control (RBAC) Roles are used to manage many-to-many relations between users and permissions Roles are used to represent the job functions, e.g. author, teacher, student in an E-learning system Permissions are modeled as parts of roles, e.g. create page, create tests, … Users are than assigned to a role and acquire automatically permissions of that role

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

33 / 78

Non-runtime QA

MeTRiCS

MeTRiCS (maintainability, evolvability, testability, reusability, integrability, configurability, scalability) Maintainability: how easy can you fix bugs and add new features Evolvability: how easy your system copes with changes Testability: how easy can you test the system for correctness

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

34 / 78

Non-runtime QA

MeTRiCS

Reusability: how easy is to use software elements in other contexts, e.g. a software library Integrability: how easy you can make the separately developed components of the system work correctly together Configurability: how easy can a system be configured for different installations and target groups Scalability: how easy the system copes with a higher performance demand

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

35 / 78

Non-runtime QA

Maintainability

This QA considers the whole lifecycle of a system What happens during system operation? Property that allows a system to be modified after deployment wirh ease E.g. extensible, modified behavior, fixing errors

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

36 / 78

Non-runtime QA

Maintainability

At the design and implementation level Code comments Object-oriented principles and design rules Consistent programming styles Documentation

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

37 / 78

Non-runtime QA

Maintainability

Maintainability is very important because any software system will change over time Experience shows that such changes tend to degrade the system over time Software systems are subject to entropy The cumulative effect of changes degrades the quality of the system

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

38 / 78

Non-runtime QA

Maintainability

The systems tend to become messy systems Regardless of how a nice plan you had at beginning Design for change – recollect OO design rules Abstract messy parts of the system so that they can be exchanged

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

39 / 78

Non-runtime QA

Maintainability

Don’t be afraid to refactor and rewrite and redesign Each software vendor does this with major versions Create throw-away prototypes Think out-of-box and innovate Don’t always follow a hype – very often nothing new in hypes E.g. Web services

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

40 / 78

Non-runtime QA

Testability

Means to improve testability Test cases: if something fails there is a bug Separation of the testing framework and the system, i.e. testing with scripts from outside Logging

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

41 / 78

Non-runtime QA

Configurability

Ability of a system to vary its operational parameters without re-compiling or re-installing E.g. selecting appropriate database drivers, configuring network parameters, … Typically, realized by a set of configuration files E.g. Apache Web server configuration file sets host name, virtual hosts, …

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

42 / 78

Non-runtime QA

Configurability

Configurability interacts with other QAs such as testability, maintainability, reliability High degree of configurability tends to have a negative impact on those QAs Testing of different system configuration becomes more difficult → reliability compromised Configurable components will be strongly parametrized → decreased maintainability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

43 / 78

Non-runtime QA

Scalability

Ability of a system to increase its capacity without re-compiling or re-installing E.g. serving additional Web pages means only copying these Web pages into a Web server file system Sometimes increasing capacity means increasing hardware, e.g. Web server clusters Managing user session on the client side, means only providing additional code-on-demand from the server

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

44 / 78

Requirements Analysis: Example

System description
Web-based Network Analysis Tool: W-NAT A simple and usable system for network analysis is needed. Networks are entities that contain not only individuals but also their connections with other individuals (see e.g. 3 for an example). The system accepts a network representations as a list of pairs of connected nodes stored in a dataset file. Nodes are represented as integers. An edge between two nodes is stored as a line containing two nodes delimited by a tabulator. Users might upload datasets to the systems and store them for further analysis. Each user might upload multiple datasets and can execute various analysis on those datasets. The system keeps the track of the analysis history for each user. Users may calculate degree distributions, network diameter, clustering coefficient, connectivity measures, singular values, and different centrality measures. Denis Helic (KMI, TU Graz) SA Analysis and Design Oct 19, 2011 45 / 78

Requirements Analysis: Example

System description
Web-based Network Analysis Tool: W-NAT Users can execute various calculations on multiple datasets in parallel. The system must not be blocked if a calculation is currently under way. Rather it should be possible to start a new calculation, or view previous calculations, etc. In case of longer calculations the system needs to notify the user by e-mail when the calculation is over. The results of the calculations should be available in textual and in graphical form. All results can be also downloaded to a local computer. The system will be used by a group of students that learn the basics of network analysis. It is expect that at any times the system will be used by multiple users executing multiple calculations. Since the system is primarily an educational tool it needs to be didactically sound, i.e. simplicity and usability are very important.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

46 / 78

Requirements Analysis: Example

System description
6 How to search in a small world

Pajek

Figure 2: HP Labs’ email communication (light grey lines) mapped onto the organizational hierarchy of HP Labs constructed out the e-mail communication. Figure: Social network(black lines). Note that communication tends to “cling” to of formal organizational chart. From: How to search a social network, Adamic, 2005.

with one another. The h-distance, used to navigate the network, is computed as follows: individuals have h-distance one to their manager and to everyone they share a manager with. Distances are then recursively assigned, so that each individual has h-distance 2 to their first neighbor’s neighbors, and h-distance 3 to their second Denis Helic (KMI, TU neighbor’s neighbors, etc. SA Analysis and Design Graz)

Oct 19, 2011

47 / 78

Requirements Analysis: Example

System description
Web-based Network Analysis Tool: W-NAT The system is a Web-based system and the users should be able to operate the system by using a standard Web browser. The users need not install any additional plugins to operate the system. User perceived performance of the system should be acceptable. In addition, standard Web usability concepts need to be followed. In particular, browser back button must be working at all times and it should be possible to bookmark pages at all times. Finally, standard Web design principles should be satisfied, meaning that pages are valid (X)HTML pages in at least HTML Transitional. The system needs to support cross browser compatibility. Further, each page and each important application state needs to have a unique and human-readable URL.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

48 / 78

Requirements Analysis: Example

Functional requirements

UR1: The system is a network analysis tool. The system can calculate the following measures. UR1.1: UR1.2: UR1.3: UR1.4: UR1.5: Out-degree distribution In-degree distribution Cumulative out-degree distribution Cumulative in-degree distribution Hop plot

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

49 / 78

Requirements Analysis: Example

Functional requirements

UR1: The system is a network analysis tool. The system can calculate the following measures. UR1.6: Clustering coefficient UR1.7: Distribution of weakly connected components UR1.8: Distribution of strongly connected components UR1.9: Left singular vector UR1.10: Right singular vector

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

50 / 78

Requirements Analysis: Example

Functional requirements

UR1: The system is a network analysis tool. The system can calculate the following measures. UR1.12: UR1.12: UR1.13: UR1.14: UR1.15: Network singular values Degree centrality Closeness centrality Betweenness centrality Eigenvector centrality

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

51 / 78

Requirements Analysis: Example

Functional requirements

UR2: Networks are stored in dataset files. UR3: The dataset file has the following format. NodeID1 \t NodeID2\n UR4: Users can upload multiple datasets to the system. UR5: To perform an analysis users select a dataset and then choose a measure to calculate.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

52 / 78

Requirements Analysis: Example

Functional requirements

UR6: For each user and for each dataset the system manages a history of calculations. UR7: Users may initiate multiple calculations simultaneously. UR8: When a calculation is started the system is not blocked. UR9: The system notifies users about a finished calculation by e-mail.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

53 / 78

Requirements Analysis: Example

Functional requirements

UR6: For each user and for each dataset the system manages a history of calculations. UR7: Users may initiate multiple calculations simultaneously. UR8: When a calculation is started the system is not blocked. UR9: The system notifies users about a finished calculation by e-mail. When is this notification needed? If the user is logged out?

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

53 / 78

Requirements Analysis: Example

Functional requirements

UR10: The calculation results are presented in a textual as well as in a graphic form.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

54 / 78

Requirements Analysis: Example

Functional requirements

UR10: The calculation results are presented in a textual as well as in a graphic form. Which form? Format? Graphics format?

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

54 / 78

Requirements Analysis: Example

Functional requirements

UR10: The calculation results are presented in a textual as well as in a graphic form. Which form? Format? Graphics format? UR11: Users can download the calculation results.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

54 / 78

Requirements Analysis: Example

Functional requirements

UR10: The calculation results are presented in a textual as well as in a
graphic form. Which form? Format? Graphics format? UR11: Users can download the calculation results. Single results? All results? Archived, how archived?

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

54 / 78

Requirements Analysis: Example

Functional requirements

UR10: The calculation results are presented in a textual as well as in a graphic form. Which form? Format? Graphics format? UR11: Users can download the calculation results. Single results? All results? Archived, how archived? UR12: Users can register with the system.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

54 / 78

Requirements Analysis: Example

Functional requirements

UR10: The calculation results are presented in a textual as well as in a graphic form. Which form? Format? Graphics format? UR11: Users can download the calculation results. Single results? All results? Archived, how
archived? UR12: Users can register with the system. How register? E-mail? Captcha?

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

54 / 78

Requirements Analysis: Example

Functional requirements

UR10: The calculation results are presented in a textual as well as in a graphic form. Which form? Format? Graphics format? UR11: Users can download the calculation results. Single results? All results? Archived, how archived? UR12: Users can register with the system. How register? E-mail? Captcha? UR13: Users can login and log out.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

54 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users?

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users? UR3: Authentication should be supported.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users? UR3: Authentication should be supported. Security

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users? UR3: Authentication should be supported. Security UR4: User-perceived performance must be acceptable

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users? UR3: Authentication should be supported. Security UR4: User-perceived performance must be acceptable Performance and Usability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users? UR3: Authentication should be supported. Security UR4: User-perceived performance must be acceptable Performance and Usability How many seconds at max users can wait?

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users? UR3: Authentication should be supported. Security UR4: User-perceived performance must be acceptable Performance and Usability How many seconds at max users can wait? UR5: Web-based system should be available at all times.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements
UR1: The system is simple, usable and didactically sound. Usability UR2: The system needs to support multiple users simultaneously. Performance How many users? UR3: Authentication should be supported. Security UR4: User-perceived performance must be acceptable Performance and Usability How many seconds at max users can wait? UR5: Web-based system should be available at all times. Reliability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

55 / 78

Requirements Analysis: Example

Non-functional requirements

UR6: Human-readable URLs.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

56 / 78

Requirements Analysis: Example

Non-functional requirements

UR6: Human-readable URLs. Evolvability, reusability, maintainability, testability, integrability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

56 / 78

Requirements Analysis: Example

Non-functional requirements

UR6: Human-readable URLs. Evolvability, reusability, maintainability, testability, integrability UR7: Extending the system with new metrics.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

56 / 78

Requirements Analysis: Example

Non-functional requirements

UR6: Human-readable URLs. Evolvability, reusability, maintainability, testability, integrability UR7: Extending the system with new metrics. Evolvability, reusability, maintainability, testability, integrability, configurability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

56 / 78

Requirements Analysis: Example

Non-functional requirements

UR6: Human-readable URLs. Evolvability, reusability, maintainability, testability, integrability UR7: Extending the system with new metrics. Evolvability, reusability, maintainability, testability, integrability,
configurability UR8: Reliability of a Web-based system.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

56 / 78

Requirements Analysis: Example

Non-functional requirements

UR6: Human-readable URLs. Evolvability, reusability, maintainability, testability, integrability UR7: Extending the system with new metrics. Evolvability, reusability, maintainability, testability, integrability, configurability UR8: Reliability of a Web-based system. Testability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

56 / 78

Requirements Analysis: Example

Non-functional requirements

UR6: Human-readable URLs. Evolvability, reusability, maintainability, testability, integrability UR7: Extending the system with new metrics. Evolvability, reusability, maintainability, testability, integrability, configurability UR8: Reliability of a Web-based system. Testability UR9:
Multiple users.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

56 / 78

Requirements Analysis: Example

Non-functional requirements

UR6: Human-readable URLs. Evolvability, reusability, maintainability, testability, integrability UR7: Extending the system with new metrics. Evolvability, reusability, maintainability, testability, integrability, configurability UR8: Reliability of a Web-based system. Testability UR9: Multiple users. Scalability

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

56 / 78

Requirements Analysis: Example

Contextual requirements

UR1: Web browser. UR2: Valid (X)HTML, at least (X)HTML Transitional. UR3: No browser plugins are allowed.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

57 / 78

Architectural Analysis & Design

Analysis

We analyze the requirements and try to identify so-called key concepts Understanding of the domain Static part of the domain We also try to identify key process and activities Dynamic part of the domain

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

58 / 78

Architectural Analysis & Design

Design

Design is the process of creating models (recollect the definition of SA) Two basic types of architectural models Structure and behavior Architectural structure is a static model of a system (i.e. how the system is divided into components) Architectural behavior is a dynamic model of a system (i.e. how the components interact with each other to perform some useful work)

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

59 / 78

Architectural Analysis & Design

Architectural structure

The division of a system into components and connectors To represent the model: box-and-lines diagrams (to see at a glance important concepts) It is important to remember that diagrams are only representations of the model Diagrams must always be accompanied by additional material such as text, data models, mathematical models, etc. The combination of diagrams and additional material is an architectural model

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

60 / 78

Architectural Analysis & Design

Architectural structure

What is a component? What is a connector? Components might be subsystems, separate processes, source code packages, … Connectors might be network protocols, method invocations, associations, … The combination of diagrams and additional material is an architectural model

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

61 / 78

Architectural Analysis & Design

Architectural structure

Figure: Example of an architectural structure

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

62 / 78

Architectural Analysis & Design

Architectural structure

In the diagram we have one user-interface and one database component But what is the criteria for deciding what is a component? Separate program modules? Separate threads or processes? Conceptual or functional division? And what about connectors? Network protocols? Callbacks? Request/response cycles? Method invocations?

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

63 / 78

Architectural Analysis & Design

Architectural structure

What is the level of granularity of a diagram? E.g. for a Web-based system, components are servers and browsers and connector is HTTP But, components of a server are HTTP parser, file I/O, cache, plug-ins, …

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

64 / 78

Architectural Analysis & Design

Architectural structure

Comparison with OO: a component is an object and a connector is a message sent between two objects Because models in OO are very well defined Therefore, we need additional information that accompanies diagrams To describe criteria for decomposition and provide explanations on granularity

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

65 / 78

Architectural Analysis & Design

Architectural behavior

Complementing structure is architectural behavior Interaction of system elements to perform some useful work Functionality vs. behavior Functionality is what the system can do and behavior is the activity sequence

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

66 / 78

Architectural Analysis & Design

Architectural behavior

Example: Accessing a tweets document Request is sent to the Web presentation layer That layer forwards the request to the application logic, e.g. TweetDeck TweetDeck contacts TweetViews to obtain a particular template, then retrieves the data from TweetDB wraps it into an HTML response and sends the response to TweetUI Functionality allows me to display a tweets document, behavior is the sequence of activities that makes it happen

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

67 / 78

Architectural Analysis & Design

Architectural behavior

Each component has a set of responsibilities Behavior is the way how these responsibilities are exercised to respond to some event An event may be an action of the user or an event from an external system A particular behavior is an event plus a response in the form of a sequence of component responsibilities

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

68 / 78

Architectural Analysis & Design

Architectural behavior

To represent behavioral models we use use-case map notation by Buhr A use-case map consists of a trace drawn through a structural diagram of the system The path of the trace through a structural diagram shows the sequence of activities Each crossing of a component by the trace indicates exercising of a responsibility

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

69 / 78

Architectural Analysis & Design

Architectural behavior

Figure: Types of traces in use-case maps

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

70 / 78

Architectural Analysis & Design

Architectural behavior

(a) Single trace – all responsibilities exercised sequentially (b) Two traces are consecutive: Equivalent to single trace but shows that continuation is triggered by another event (c) And-Fork: The traces after the line are potentially concurrent (run in parallel)

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

71 / 78

Architectural Analysis & Design

Architectural behavior

Figure: Types of traces in use-case maps

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

72 / 78

Architectural Analysis & Design

Architectural behavior

(a) N-Way And-Fork: the trace after the fork may be replicated an arbitrary number of times (b) Or-Fork: The trace is split and activity proceeds along one or another path (c) Seq-Fork: The traces after the line are followed in the order indicated by the arrow

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

73 / 78

Architectural Analysis & Design

Architectural behavior

Figure: Example of architectural behavior

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

74 / 78

Architectural Views

Architectural views

We can examine a system from different points of view Different kinds of views Conceptual: components are set of responsibilities and connectors are flow of information Execution: components are execution units (processes) and connectors are messages between processes Implementation: components are libraries, source code, files, etc and connectors are protocols, api calls, etc.

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

75 / 78

Architectural Views

Architectural views

There are other models as well We will mention them but we will investigate only previous three models Data model describes the data Physical model
describes servers, firewalls, workstations, …

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

76 / 78

Architectural Views

Architectural views

Each view provides different information about the structure of the system Each view addresses a specific set of concerns All views taken together is the primary means of documenting software architecture

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

77 / 78

Architectural Views

Architectural views

The conceptual architecture considers the structure of the system in terms of its domain-level functionality The execution architecture considers the system in terms of its runtime structure The implementation architecture considers the system in terms of its build-time structure

Denis Helic (KMI, TU Graz)

SA Analysis and Design

Oct 19, 2011

78 / 78

Free Analysis and Design of Software Architecture Essay Sample

A

Let us write you a custom essay sample on Analysis and Design of Software Architecture

for only $16.38 $13.9/page

your testimonials