1 General knowledge on software architecture

• (1)Makes the right stakeholders talk to each other about the right things.
• The software arch represents a common abstraction that the stakeholders can use as a basis for mutual (1)understanding, (2) negotiation, (3) communication.

• (1)By identifying requirements and functionalities the system will have we can do cost estimates.
• (2) we can also identify the risks at an early stage and from there on decide how to best act to mediate them and their potential costs in both time and money.
• (3) Time and money can also save time in the maintenance and evolutionary parts of a life cycle through a well documented architecture.

• With bad modularity an upgrade will affect many more parts of a system than if an arch using good modularity was used.
• For the system to evolve only a few selected easy and clear to spot parts would have to be changed or interacted with to make the upgrade and this would save time and money.

• In short the whole project
• from many perspectives.
• (1)Views are used because they can describe the system from the viewpoint of different
• stakeholders, such as end-users, developers and so on.

2. For example a use case diagram shows the major functionalities of the system but not the dependencies which is instead shown in the component diagram.

• (1)A quality attribute is a concept that influences the design and software architecture decision.
• (2)
• A quality attribute is a measurable or testable property of a system that is used to indicate how well the system satisfies the needs of its
• stakeholders.

Might also describe a viewpoint of the system such as performance evelvability maintainability etc

Architectural drivers the design forces that should be the most influential and important to the architectures design.

Using the design principle "decomposition" the complexity of the diffrent modules & components can decrease. Decomposition is about breaking down components into smaller parts in order to decrease the complexity of each component and thereby the system.

• //
• By representing a model that is intellectually manageable and understandable.

An example of how it can be a basis of understanding is using the 4+1 views concept to reduce complexity in each model but still provide a full view of the system together.

• (1)Identification of possible problems during development, production & operation.
• When we know what they are we can design our system around them.

Software architecture helps in managing risks by letting them be found early by carefully thinking about the systems current design solutions from different perspectives. When risks are identified they can be mitigated

• (1)
• The maintainer is concerned with a comprehensible, consistent, and documented design approach, and the ease with which
• modifications can be made.
• All of the quality of the above is heavily impacted by the software arch decisions.

• (2)
• With little documentation analysis of the soft arch can be a good way to mitigate lack of documentation when trying to understand the system.

By having clear view of what should be built and how while also knowing who are available to build it our software arch can be the base of division of tasks and making sure everyone has the same larger vision of the project.

This is a great way to use separation of concerns concept while dividing the work based on the software arch.

The initial model us used for designing and building the project. If the project changes or evolves so should the model. This is so that maintenance can be done time and cost effectively and also upgrades can have the same benefits.

• A stakeholder is an interested party who has a share, right or claim in a system or in its possession of qualities needed in the system.
• Example of stakeholders are architects, developers, end-users, customers.

The fundamental organization of a system embodied by its components, their relationships to each other and to the environment and the principles guiding its design and evolution

1, Helps decide on what are the most important quality attributes of a system to be built and how they can be achieved through requirements and constraints.

2. Can be used in the maintenance / upgrading phase on a system with little or no documentation as analysis of its soft arch can be used to understand it better.

3. Having the arch mapped out clearly can help the team divide tasks of the project more efficiently.

• Multiple views are utilized to address several areas of concerns, each one focusing on a specific aspect of the system.
• Examples of architecture frameworks using multiple views include Kruchten's "4+1" view model.

The purpose of views and viewpoints is to enable humans to comprehend very complex systems, to organize the elements of the problem and the solution around domains of expertise and to separate concerns.

An arch style is a paradigm that offers a solutions and best practices to common software problems. The styles are open ended and can therefore be adapted and combined to fit the projects issues.

They also and evolve with technology.

An architectural style is a general, reusable solution to a commonly occurring problem in software architecture within a given context.


Example is the client server style.

• Conceptual integrity is the principle that anywhere you look in your system, you can tell that the design is part of the same overall design.
• This includes low-level issues such as formatting and identifier
• naming, but also issues such as how modules and classes are designed,
• etc.

Architectural drivers can be one of the following.



Technical Constraints

Business Constraints

Quality Attributes

High-Level Functional Requirements

• AVAILABILITY
• Availability is concerned with system failure and its associated consequences.
• A system failure occurs when the system no longer delivers a service consistent with its specification.
• Such a failure is observable by the system's users—either humans or other systems.

• MODIFIABILITY
• Modifiability is about the cost of change to the system measured in time and money.

• PERFORMANCE
• Performance is about timing. Events (interrupts, messages, requests from users, or the passage of time) occur, and the system must respond to them.
• One of the things that make performance complicated is the number of event sources and arrival patterns.
• A performance scenario begins with a request for some service arriving at the system. Satisfying the request requires resources to be consumed. While this is happening the system may be simultaneously servicing other requests.
• An arrival pattern for events may be characterized as either periodic or stochastic.

• SECURITY
• Security is a measure of the system's ability to resist unauthorized usage while still providing its services to legitimate users.
• Security can be characterized as a system providing nonrepudiation, confidentiality, integrity, assurance, availability, and auditing.
• Nonrepudiation is the property that a transaction (access to or modification of data or services) cannot be denied by any of the parties to it.
• Confidentiality is the property that data or services are protected from unauthorized access.
• Integrity is the property that data or services are being delivered as intended.
• Assurance is the property that the parties to a transaction are who they purport to be.
• Availability is the property that the system will be available for legitimate use.
• Auditing is the property that the system tracks activities within it at levels sufficient to reconstruct them.

• TESTABILITY
• Software testability refers to the ease with which software can be made to demonstrate its faults through testing.
• Testability refers to the probability that it will fail on its next test execution.
• For a system to be properly testable, it must be possible to control each component's internal state and inputs and then to observe its outputs.

USABILITY

• Usability is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. It can be broken down into the following areas:
• Learning system features. If the user is unfamiliar with a particular system or a particular aspect of it, what can the system do to make the task of learning easier?
• Using a system efficiently. What can the system do to make the user more efficient in its operation?
• Minimizing the impact of errors. What can the system do so that a user error has minimal impact?
• Adapting the system to user needs. How can the user (or the system itself) adapt to make the user's task easier?
• Increasing confidence and satisfaction. What does the system do to give the user confidence that the correct action is being taken?

–A scenario-based architecture method for assessing quality attributes such as: modifiability, availability, and security.

A Quality Attribute Scenario is a quality attribute specific requirement.

–Source of stimulus (e.g., human, computer system, etc.)

–Stimulus – a condition that needs to be considered

–Environment - what are the conditions when the stimulus occurs?

–Artifact – what elements of the system are stimulated.

–Response – the activity undertaken after arrival of the stimulus.

–Response measure – when the response occurs it should be measurable so that the requirement can be tested.