Get Started. It's Free
or sign up with your email address
Architecture by Mind Map: Architecture

1. consists of

1.1. Structure & Communication

1.1.1. arch. viewpoints are sets of views used to describe system by stakeholders (end-users, developers and PMs) arch. views 5 types consistant if the design decisions they contain are compatible

1.1.2. metamodel set of models and their relations models sets of design decisions

1.1.3. entities components encapsulate functionality restricts access through interdace has explicit dependencies connectors lines in an object diagram configurations the way components and connectors are arranged

1.2. Requirements

1.2.1. functional Describe user tasks that the system needs to support independent from the implementation

1.2.2. non-functional describe properties of the system or the domain "-ilities" e.g. “The system must support 10 parallel transactions”

1.2.3. constraints Imposed by the client or the environment referred to as “pseudo requirements" e.g. “The system must be implemented on Windows“

2. types

2.1. pescriptive

2.1.1. before implementation

2.2. descriptive

2.2.1. after implementation

3. styles

3.1. named collections of design decisions

3.2. 7 pure types

3.2.1. language based Influenced by the languages that implement them e.g. main & subroutine object-oriented

3.2.2. layered Layered systems are hierarchically organized providing services to upper layers and acting as clients for lower layers e.g. client-server Virtual machine

3.2.3. dataflow the availability of data controls computation influenced by orderly motion of data between components e.g. batch-sequential pipe-and-filter

3.2.4. peer-to-peer Network of loosely-coupled peers State and logic are decentralized amongst peers

3.2.5. shared memory components comunicate through shared data store shared store represents system state e.g. blackboard rule-based

3.2.6. interpreter programs parse commands and act accordingly e.g. interpreter mobile code

3.2.7. implicit invocation system is structured around event handling, using a form of callback inversion of control (IoC) e.g. publish-subscribe event-based

4. design

4.1. stages

4.1.1. 1. feasibility identify set od feasible concepts

4.1.2. 2. preliminary design select and develop best concept

4.1.3. 3. detailed design develop eng. descriptions of concept

4.1.4. 4. planning make concept fit requirements team allocation budgeting

4.2. degradation

4.2.1. drift add changes; do not modify existing ones

4.2.2. erosion modify architecture

4.3. recovery

4.3.1. concrete arch how the system is actually built

4.3.2. conceptual arch how developers think about the system

4.4. Difficulties

4.4.1. Complexity Grows non-linearly with program size

4.4.2. Conformity System is dependent on its environment

4.4.3. Changeability Perception that software is easily modified

4.4.4. Intangability Not constrained by physical laws

4.5. approches

4.5.1. creative potentially unnecessary dangerous

4.5.2. methodical efficient when domain is familiar not always successful

4.6. Qualities

4.6.1. simplisity

4.6.2. coupling data A & B communicate by simple data only highly desirable stamp A & B use a common type of data, e.g. tree. That contain extra unnecessary data. Hence different from data coupling okay control (activating) A transfers control to B by procedure call necessary control (switching) A passes flag to B to tell it how to behave undesirable common environment A & B make use of shared data undesirable content A changes B's data or pass control to the middle of B Extremely foolish

4.6.3. cohesion data all part of a well defined data abstraction highly desirable functional all part of a single problem solving task high sequential output of one part go to inputs of another Okay communicational operations that use the same input or input data modarate procedural set of operations must be executed in a particular order low temporal elements must be executer at the same time low logical elements perform logically similar operations no way coincidental repeted code no way

4.7. SOLID principles

4.7.1. Single Responsibility Classes should have only one major task Insulates classes from one another

4.7.2. Open/Close Classes should be open for extension but closed to modification If a class needs to be extended, try to do it through subclassing to minimize impact on existing clients

4.7.3. Liskov Substitution Principle Subtypes should behave as their parent types aka a program should still behave correctly should two subtypes of a common be interchanged

4.7.4. Interface segregation Only place key methods in interfaces Clients should not need to support methods that are irrelevant to their behaviour This can lead to a larger number of smaller interfaces in practice

4.7.5. Dependency Inversion High-level methods should not depend on lower-level modules Also known as the ‘hollywood principle’ or ‘inversion of control’ Minimizes direct coupling between concrete classes

4.8. patterns

4.8.1. Common solutions to a recurring design problems. Are language-independent. Are “micro-architectures”

4.8.2. 4 parts 1. Name 2. Problem 3. Solution 4.Consequences / trade-offs

4.8.3. e.g. Observer Weather data example (similar to Eclipse example) WeatherData

4.8.4. 8 covered in class patterns Singleton Intent: “Ensure a class has only one instance” Motivation: For situations when having multiple copies of an object is either unnecessary or incorrect. Obsrver Intent: Define a one-to-many relationship between objects so that when an object changes state its dependents are updated automatically Motivation: To maintain consistency between multiple different objects without tightly coupling them Composite Intent: “Enable a group of objects to be treated as single object” Motivation: Differentiating between interior and leaf nodes in tree-structured data increases system complexity. Template Method Intent: “Define the skeleton of an algorithm deferring some steps to client subclasses” Motivation: When two algorithms are largely the same but differ in only a few small details the algorithm can be encapsulated in a base class and defer specific functionality to child classes. Strategy Intent: “Define a family of algorithms that can be easily interchanged with each other” Motivation: Support the open/closed principle by abstracting algorithms behind an interface; clients use the interface while subclasses provide the functionality and can be easily interchanged. Adapter Intent: “Convert the interface of one class to make it compatible with another class.” Motivation: Components often have incompatible interfaces that cannot be used by a client but also cannot be modified. Facade Intent: “Provide a unified, higher-level, interface to a whole module making it easier to use.” Motivation: Composing classes into subsystems reduces complexity. Using a Facade minimizes the communication dependencies between subsystems. Command Intent: “Encapsulate requests enabling clients to log / undo them as required.” Motivation: In situations where you need to be able to make requests to objects without knowing anything about the request itself or the receiver of the request, the command pattern enables you to pass requests as objects.

5. representations

5.1. statechart diagram

5.1.1. Take an object to analyze, and make a state machine on it (initial state, event that leads to other states, etc.)

5.1.2. Poor mapping between states and components.

5.2. component diagram

5.2.1. Captures components and relationships

5.2.2. Required and provided interfaces explicitly recorded.

5.3. deployment diagram

5.3.1. provide mapping between physical devices.

5.4. sequence diagram

5.4.1. Focus on inter-component collaboration

5.4.2. capture behavior for specific scenarios