1. consists of
1.1. Structure & Communication
1.1.1. arch. viewpoints
1.1.1.1. are sets of views used to describe system by stakeholders (end-users, developers and PMs)
1.1.1.2. arch. views
1.1.1.2.1. 5 types
1.1.1.2.2. consistant if the design decisions they contain are compatible
1.1.2. metamodel
1.1.2.1. set of models and their relations
1.1.2.2. models
1.1.2.2.1. sets of design decisions
1.1.3. entities
1.1.3.1. components
1.1.3.1.1. encapsulate functionality
1.1.3.1.2. restricts access through interdace
1.1.3.1.3. has explicit dependencies
1.1.3.2. connectors
1.1.3.2.1. lines in an object diagram
1.1.3.3. configurations
1.1.3.3.1. the way components and connectors are arranged
1.2. Requirements
1.2.1. functional
1.2.1.1. Describe user tasks that the system needs to support
1.2.1.2. independent from the implementation
1.2.2. non-functional
1.2.2.1. describe properties of the system or the domain
1.2.2.2. "-ilities"
1.2.2.3. e.g. “The system must support 10 parallel transactions”
1.2.3. constraints
1.2.3.1. Imposed by the client or the environment
1.2.3.2. referred to as “pseudo requirements"
1.2.3.3. 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
3.2.1.1. Influenced by the languages that implement them
3.2.1.2. e.g.
3.2.1.2.1. main & subroutine
3.2.1.2.2. object-oriented
3.2.2. layered
3.2.2.1. Layered systems are hierarchically organized providing services to upper layers and acting as clients for lower layers
3.2.2.2. e.g.
3.2.2.2.1. client-server
3.2.2.2.2. Virtual machine
3.2.3. dataflow
3.2.3.1. the availability of data controls computation
3.2.3.2. influenced by orderly motion of data between components
3.2.3.3. e.g.
3.2.3.3.1. batch-sequential
3.2.3.3.2. pipe-and-filter
3.2.4. peer-to-peer
3.2.4.1. Network of loosely-coupled peers
3.2.4.2. State and logic are decentralized amongst peers
3.2.5. shared memory
3.2.5.1. components comunicate through shared data store
3.2.5.2. shared store represents system state
3.2.5.3. e.g.
3.2.5.3.1. blackboard
3.2.5.3.2. rule-based
3.2.6. interpreter
3.2.6.1. programs parse commands and act accordingly
3.2.6.2. e.g.
3.2.6.2.1. interpreter
3.2.6.2.2. mobile code
3.2.7. implicit invocation
3.2.7.1. system is structured around event handling, using a form of callback
3.2.7.2. inversion of control (IoC)
3.2.7.3. e.g.
3.2.7.3.1. publish-subscribe
3.2.7.3.2. event-based
4. design
4.1. stages
4.1.1. 1. feasibility
4.1.1.1. identify set od feasible concepts
4.1.2. 2. preliminary design
4.1.2.1. select and develop best concept
4.1.3. 3. detailed design
4.1.3.1. develop eng. descriptions of concept
4.1.4. 4. planning
4.1.4.1. make concept fit requirements
4.1.4.2. team allocation
4.1.4.3. budgeting
4.2. degradation
4.2.1. drift
4.2.1.1. add changes; do not modify existing ones
4.2.2. erosion
4.2.2.1. modify architecture
4.3. recovery
4.3.1. concrete arch
4.3.1.1. how the system is actually built
4.3.2. conceptual arch
4.3.2.1. how developers think about the system
4.4. Difficulties
4.4.1. Complexity
4.4.1.1. Grows non-linearly with program size
4.4.2. Conformity
4.4.2.1. System is dependent on its environment
4.4.3. Changeability
4.4.3.1. Perception that software is easily modified
4.4.4. Intangability
4.4.4.1. Not constrained by physical laws
4.5. approches
4.5.1. creative
4.5.1.1. potentially unnecessary
4.5.1.2. dangerous
4.5.2. methodical
4.5.2.1. efficient when domain is familiar
4.5.2.2. not always successful
4.6. Qualities
4.6.1. simplisity
4.6.2. coupling
4.6.2.1. data
4.6.2.1.1. A & B communicate by simple data only
4.6.2.1.2. highly desirable
4.6.2.2. stamp
4.6.2.2.1. A & B use a common type of data, e.g. tree. That contain extra unnecessary data. Hence different from data coupling
4.6.2.2.2. okay
4.6.2.3. control (activating)
4.6.2.3.1. A transfers control to B by procedure call
4.6.2.3.2. necessary
4.6.2.4. control (switching)
4.6.2.4.1. A passes flag to B to tell it how to behave
4.6.2.4.2. undesirable
4.6.2.5. common environment
4.6.2.5.1. A & B make use of shared data
4.6.2.5.2. undesirable
4.6.2.6. content
4.6.2.6.1. A changes B's data or pass control to the middle of B
4.6.2.6.2. Extremely foolish
4.6.3. cohesion
4.6.3.1. data
4.6.3.1.1. all part of a well defined data abstraction
4.6.3.1.2. highly desirable
4.6.3.2. functional
4.6.3.2.1. all part of a single problem solving task
4.6.3.2.2. high
4.6.3.3. sequential
4.6.3.3.1. output of one part go to inputs of another
4.6.3.3.2. Okay
4.6.3.4. communicational
4.6.3.4.1. operations that use the same input or input data
4.6.3.4.2. modarate
4.6.3.5. procedural
4.6.3.5.1. set of operations must be executed in a particular order
4.6.3.5.2. low
4.6.3.6. temporal
4.6.3.6.1. elements must be executer at the same time
4.6.3.6.2. low
4.6.3.7. logical
4.6.3.7.1. elements perform logically similar operations
4.6.3.7.2. no way
4.6.3.8. coincidental
4.6.3.8.1. repeted code
4.6.3.8.2. no way
4.7. SOLID principles
4.7.1. Single Responsibility
4.7.1.1. Classes should have only one major task
4.7.1.2. Insulates classes from one another
4.7.2. Open/Close
4.7.2.1. Classes should be open for extension but closed to modification
4.7.2.2. 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
4.7.3.1. Subtypes should behave as their parent types
4.7.3.2. aka a program should still behave correctly should two subtypes of a common be interchanged
4.7.4. Interface segregation
4.7.4.1. Only place key methods in interfaces
4.7.4.2. Clients should not need to support methods that are irrelevant to their behaviour
4.7.4.3. This can lead to a larger number of smaller interfaces in practice
4.7.5. Dependency Inversion
4.7.5.1. High-level methods should not depend on lower-level modules
4.7.5.2. Also known as the ‘hollywood principle’ or ‘inversion of control’
4.7.5.3. Minimizes direct coupling between concrete classes
4.8. patterns
4.8.1. Common solutions to a recurring design problems.
4.8.1.1. Are language-independent.
4.8.1.2. Are “micro-architectures”
4.8.2. 4 parts
4.8.2.1. 1. Name
4.8.2.2. 2. Problem
4.8.2.3. 3. Solution
4.8.2.4. 4.Consequences / trade-offs
4.8.3. e.g.
4.8.3.1. Observer
4.8.3.1.1. Weather data example (similar to Eclipse example)
4.8.3.1.2. WeatherData
4.8.4. 8 covered in class patterns
4.8.4.1. Singleton
4.8.4.1.1. Intent: “Ensure a class has only one instance”
4.8.4.1.2. Motivation: For situations when having multiple copies of an object is either unnecessary or incorrect.
4.8.4.2. Obsrver
4.8.4.2.1. Intent: Define a one-to-many relationship between objects so that when an object changes state its dependents are updated automatically
4.8.4.2.2. Motivation: To maintain consistency between multiple different objects without tightly coupling them
4.8.4.3. Composite
4.8.4.3.1. Intent: “Enable a group of objects to be treated as single object”
4.8.4.3.2. Motivation: Differentiating between interior and leaf nodes in tree-structured data increases system complexity.
4.8.4.4. Template Method
4.8.4.4.1. Intent: “Define the skeleton of an algorithm deferring some steps to client subclasses”
4.8.4.4.2. 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.
4.8.4.5. Strategy
4.8.4.5.1. Intent: “Define a family of algorithms that can be easily interchanged with each other”
4.8.4.5.2. 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.
4.8.4.6. Adapter
4.8.4.6.1. Intent: “Convert the interface of one class to make it compatible with another class.”
4.8.4.6.2. Motivation: Components often have incompatible interfaces that cannot be used by a client but also cannot be modified.
4.8.4.7. Facade
4.8.4.7.1. Intent: “Provide a unified, higher-level, interface to a whole module making it easier to use.”
4.8.4.7.2. Motivation: Composing classes into subsystems reduces complexity. Using a Facade minimizes the communication dependencies between subsystems.
4.8.4.8. Command
4.8.4.8.1. Intent: “Encapsulate requests enabling clients to log / undo them as required.”
4.8.4.8.2. 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