Unit 9 - Architecture, patterns and reuse Flashcards
What is software architecture?
The software architecture of a program or computing system is the structure or structures of the system, which comprise software elements, the externally visible properties of those elements, and the relationships among them.
A popular architecture for websites is the LAMP stack. What does this refer to?
. Linux
. Apache webserver
. MySQL database
. PHP (or Python or Perl – all programming languages).
Suggest a reason why choosing the architecture very late on might be a bad idea.
Choosing the architecture at a very late stage suffers from the risks of the waterfall approach. By then many other design decisions will have been taken and it will be too late to change them, even if they force us to adopt an architecture that is less than ideal.
An analogy could be with building a house. Would anyone dream of starting construction without an architectural design for the building?
What are four characteristics of ASRs (architecturally significant requirements)
. Quality attributes are non-functional requirements such as security, reliability, availability, usability, maintainability, portability and so on that you have met in earlier units.
. Core features are described by Chen et al as ‘the problem the software is trying to solve’. For example, an online chat application is intended to allow participants in different locations to exchange text messages. To do this a network of some sort is essential, which immediately has implications for the architecture.
. Constraints. All requirements can be described as constraints, but here the authors mean requirements such as technical constraints – for example, the client may have specified a particular programming language – or non-technical constraints such as budget or time.
. Application environment. This is the environment in which the system will run. For example, a navigation app will need GPS connectivity.
What are the 4+1 model architectural views?
. The logical (or functional) view describes the system’s main functional elements and their interactions – broadly, the services the system must provide to users.
. The process view describes the set of independently executing processes that will exist at run-time and the communication between them.
. The physical (or deployment) view describes how the system will be deployed to an operating environment in terms of the physical computers and networks on which the system will run.
. The development view describes how the software will be split into subsystems that can be allocated to teams of developers.
Describe the three architectural views. Each view tends to emphasise issues that matter to various stakeholders.
. The logical view describes the main functional elements and how they interact, and assumes that these correspond to subsystems that can be
allocated to teams of developers.
. The process view describes the independent processes executing at runtime and the communication between them, regarding the processes as
components and the communication as taking place via connectors.
. The deployment view describes how the system will be deployed to an operating environment, the physical computers and networks on which the system will run. It is important to us because deployment decisions will have a major impact on quality attributes.
Imagine a large distance-learning university requires a system for the electronic submission of student assignments, their subsequent marking and
return, and the recording of results.
Think of some stakeholder groups and for each group suggest one or more concerns that might influence the architecture.
. Students and teaching staff will be concerned with core functionality, usability, availability and performance – core features and quality attributes.
. The examinations section will be particularly concerned with security – quality attributes.
. The finance department will be concerned with the cost – constraints.
. Management will be concerned with the cost, when the system will be delivered and its effectiveness – constraints, core features.
. Designers will be concerned with how the system can be partitioned, what the run-time elements will be and where they will be deployed – the application environment.
. Programmers will be concerned with the core functionality represented in the design, how easily the design can be implemented in code and what
language(s) will be used – core features, quality attributes, constraints.
. Testers will be concerned with whether the system is easy to test – quality attributes.
. The IT department will be concerned with the operating environment and how easy the system is to run – application environment.
. Developers responsible for maintaining the system will be concerned with how easy the system is to modify – quality attributes.
Think of some reasons why reuse is desirable.
. It avoids duplication of effort and reinventing already existing solutions, which saves resources.
. It promotes reliability because developers can use tried and trusted solutions.
. It speeds up development because developers can take existing solutions without starting from the beginning every time.
. It is a mechanism for spreading good practice among the software development community and familiarising practitioners with tried and tested solutions.
Other than software elements, what else can be involved in reuse?
. knowledge in the elicitation of requirements, known as requirements patterns
. ways of solving conceptual analysis problems, known as analysis patterns
. architecture – this may just involve reusing a structural idea or it may go further and allow the creation of a series of systems by taking the same basic architecture and modifying the detailed code
. ways of solving particular problems of design and implementation, known as design patterns
. ways of doing things in a particular language – these are small units of reuse known as idioms.
What are some common architectural styles?
Client–server Call-return Layered Peer-to-peer Data flow Data-centred Independent components Service-oriented Notification
Describe the client-server style
Client–server style is probably the best known of all architectural styles. One component (the server) provides a service to the other component (the
client). The server waits for requests from clients, processes each one as it as received, and returns a response to the client.
A familiar example of the client–server style is a request sent from a web browser to a web server.
Describe the call-return style
In a call-return style a component (the caller) makes a procedure call to another component (often known as the callee) and waits for the call to return.
In traditional software a main program calls a subprogram and then waits for a reply. In object-oriented programming the call takes the form of a method invocation by one object on another by the sending of a message.
Describe the layered style
The essence of a layered style is that the system is structured as a series of layers that are visualised as stacked on top of another. Each layer uses services provided by the layers below (usually just by the layer immediately below). It also supplies services to the layer above.
Describe the peer-to-peer style
The peer-to-peer style resembles the client–server style except that all the components are both clients and servers and any component can request
services from any other component.
An example of peer-to-peer is a streaming music service, where listeners generally get streamed tracks from the nearest peer that can be located by sending a request that hops from one peer to another until the desired track is located
Describe the data-flow style
The data-flow style components are objects or
small independent subprograms (filters) that process a stream of data and pass the results on to other components for further processing. Communication is
unidirectional and uses fixed channels. Each filter has no knowledge of other filters upstream or downstream, but simply accepts the data, processes it and passes it on. The connectors are services, provided by the operating environment, that ‘pipe’ data from one filter to another.
Describe the data-centred style
In the data-centred style there is a data provider that is a centralised store of persistent data. The structure of the data, the types of items and their relationships are stable and change rarely or not at all. There are many clients who are data consumers. Items can be created, queried, updated and destroyed on request.
There are two forms of the data-centred style:
. If communication is always initiated by clients and the store simply responds to requests it is called database or repository. Typically the components are a database server and clients that access it. The connectors are database queries made via a special database connection. A database holding personnel records is an example of this form, with authorised users being able to log on and submit queries.
. A variant in which the store is active and informs users of changes, so that communication may be initiated from either end, is termed a blackboard.