Software Architecture - Revision history

Suhridk at 10:41, 15 April 2012

2012-04-15T10:41:11Z

2012-04-15T10:40:52Z

2012-03-19T14:02:28Z

Structural Recommendations

2012-03-19T14:01:11Z

Software process and the architecture business cycle

2012-03-19T13:49:58Z

Influences on architecture

2012-03-19T13:44:44Z

Reusable abstraction of systems

2012-03-19T13:34:26Z

Reusable abstraction of systems

2012-03-19T13:29:27Z

Capture early design decisions

2012-03-19T13:25:53Z

Communication

2012-03-19T13:18:54Z

Introduction to Software Architecture

← Older revision		Revision as of 10:41, 15 April 2012
Line 80:		Line 80:
	* For parallel processing systems, arch should feature well defined processes.		* For parallel processing systems, arch should feature well defined processes.
	* Should feature a small number of interaction patterns.		* Should feature a small number of interaction patterns.
		+
		+	[[Category:SYAR]]

← Older revision		Revision as of 14:02, 19 March 2012
Line 77:		Line 77:
	* Quality attributes should be achieved using well known tactics specific to each attribute.		* Quality attributes should be achieved using well known tactics specific to each attribute.
	* Arch should never depend on a specific version of a commercial product or tool.		* Arch should never depend on a specific version of a commercial product or tool.
		+	* Data producing modules should be different from data consuming modules.
		+	* For parallel processing systems, arch should feature well defined processes.
		+	* Should feature a small number of interaction patterns.

← Older revision		Revision as of 14:01, 19 March 2012
Line 62:		Line 62:
	# Implement the system based on the architecture		# Implement the system based on the architecture
	# Ensure that the implementation conforms to the architecture		# Ensure that the implementation conforms to the architecture
		+
		+	== Process Recommendations ==
		+
		+	* Arch should be the product of a single architect/small group of architects
		+	* Architect should have functional requirements and a prioritized set of quality attributes.
		+	* Arch should be well documented with at least one static view and one dynamic view.
		+	* Arch should be analysed.
		+	* Arch should result in a specific (and small) set of resource contention areas.
		+
		+	== Structural Recommendations ==
		+
		+	* Well defined modules.
		+	* Well defined interface that encapsulates changeable aspects.
		+	* Quality attributes should be achieved using well known tactics specific to each attribute.
		+	* Arch should never depend on a specific version of a commercial product or tool.

← Older revision		Revision as of 13:49, 19 March 2012
Line 52:		Line 52:
	* Background and experience of architects.		* Background and experience of architects.
	* Technical environment.		* Technical environment.
		+
		+	= Software process and the architecture business cycle =
		+
		+	# Develop a business case for the system
		+	# Understand the requirements
		+	# Create or select the architecture
		+	# Document the architecture
		+	# Analyse or evaluate the architecture
		+	# Implement the system based on the architecture
		+	# Ensure that the implementation conforms to the architecture

← Older revision		Revision as of 13:44, 19 March 2012
Line 33:		Line 33:
	* Domain specific software architectures can be developed.		* Domain specific software architectures can be developed.
	* Process becomes oriented towards component assembly rather than programming.		* Process becomes oriented towards component assembly rather than programming.
		+
		+	= Problems due to lack of architecture =
		+
		+	* Costly maintenance - prone to side effect problems.
		+	* Evolution not possible and reuse difficult.
		+	* Inefficient or infeasible
		+	** Arch may partition the work in such a way that every engineer must communicate with every other engineer.
		+	** Throughput problems - processing bottlenecks, etc.
		+
		+	= Influences on architecture =
		+
		+	* Software architecture is a result of technical, business and social influences.
		+	* System stakeholders.
		+	* Developing organisation.
		+	** Org may have a business investment in certain assets.
		+	** May wish to make a long term business investment.
		+	** The organizational structure can shape the software architecture.
		+	* Background and experience of architects.
		+	* Technical environment.

← Older revision	Revision as of 10:40, 15 April 2012
(No difference)

← Older revision		Revision as of 13:34, 19 March 2012
Line 28:		Line 28:

	== Reusable abstraction of systems ==		== Reusable abstraction of systems ==
		+
		+	* The earlier a software artefact can be reused, greater the payoff.
		+	* Architectural reuse - means not only reuse code, but also requirements and development experience.
		+	* Domain specific software architectures can be developed.
		+	* Process becomes oriented towards component assembly rather than programming.

← Older revision		Revision as of 13:29, 19 March 2012
Line 19:		Line 19:

	== Capture early design decisions ==		== Capture early design decisions ==
		+
		+	* An architecture constrains implementation.
		+	* An architecture can help to determine organisational structure.
		+	* Allow apriori reasoning about change.
		+	** Probably the most important - since 80% of software cost occurs after deployment.
		+	** Enables risk assessment of future project changes.
		+	* Support analysis and prediction about future properties.

	== Reusable abstraction of systems ==		== Reusable abstraction of systems ==

@@ Line 13: / Line 13: @@
 == Communication ==
 == Capture early design decisions ==
 == Reusable abstraction of systems ==

← Older revision		Revision as of 13:18, 19 March 2012
Line 9:		Line 9:
	* Definition:		* Definition:
	** The structure or structures of the system which comprise of software elements, the externally visible properties of those elements and the relationships among them.		** The structure or structures of the system which comprise of software elements, the externally visible properties of those elements and the relationships among them.
		+
		+	= Why Architecture =
		+
		+	== Communication ==
		+
		+	== Capture early design decisions ==
		+
		+	== Reusable abstraction of systems ==