Reading...
Play button
Play button
Use LEFT and RIGHT arrow keys to navigate between flashcards;
Use UP and DOWN arrow keys to flip the card;
H to show hint;
A reads text to speech;
28 Cards in this Set
- Front
- Back
- 3rd side (hint)
|
Abstraction
|
Abstraction is the art of generalization that allows us to create generic models from specific instances. By "abstracting away" selected details of a set of systems, we are able to examine and compare common aspects across the systems.
It is common to speak of "levels of abstraction", where "going up a level" is to remove more detail and thus create a more generic view of the system in scope. For example, one might use a service model to compare distributed systems based on web services, then "abstract up" to a model for distributed systems to compare a web services based system with a CORBA based system. Three named abstraction levels are often used in system design: The conceptual model -- which expresses the purpose of the system in non-technical terms; The logical model -- which describes the components of the system without regard to how they are deployed to meet operational requirements; and The physical model -- which describes how the system will look as actually deployed. |
3 levels
|
|
|
ACID Transaction
|
request to make multiple updates to a database where the failure of any one update causes the entire collection of updates to fail. Usually used synonymously with “Atomic Transaction”, an ACID transaction makes four guarantees:
Atomicity — all or nothing — all operations were successfully completed or no changes were made to the database Consistency — the rules governing constraints on data values and relationships between data elements were followed; the updates were consistent with the data model Isolation — the data being updated by the transaction was protected from other update requests while the transaction executed; without this guarantee, a transaction might manipulate temporary data that was not yet fully consistent with the data model Durability — the changes were really committed; even if the power failed a moment after the acknowledgment was sent, the updates will be there when the power returns. |
4 things
|
|
|
ACM
|
Association for Computing Machinery (ACM)
. The Association for Computing Machinery is a not-for-profit organization focused on advancing computing as a science and a profession. Founded in 1947, the ACM is recognized around the world as the "First Society in Computing". The ACM publishes several journals and bestows the A.M Turing Award for lifetime achievement in computing. |
|
|
|
Acknowledgement
|
A message that asserts receipt of previous message, but does not signal the completion of processing. An acknowledgment may be described as an intermediate response to a request.
Acknowledgements have many uses in messaging systems; examples include: A queuing system acknowledging that a message was successfully enqueued; The subsequent acknowledgement from the ultimate "endpoint":EndpointGlossaryEntry" that the message was retrieved from the queue; Acknowledgment of each message in a stream of messages. For a more complete discussion, please refer to the article on Messaging. |
3 examples
|
|
|
Activity Diagram
|
In UML terms an activity diagram shows behavior with control structure.
An activity diagram can show many objects over many uses, many objects in single use case, or implementation of method. Activitiy diagrams encourages parallel behavior. |
3 instances of activity diagrams
|
|
|
Actor
|
In formal architectural modeling, such as with UML, an actor is someone or something, outside the system or business, that interacts with the system or business.
Actors carry out a use case. A single actor may perform many use cases and a use case may have several actors doing (or performing) it. |
|
|
|
Ad Hoc
|
In the architectural idiom, ad hoc shares the vernacular meaning of "done for a particular purpose; done without consideration of broader issues", but adds sneering connotations of "sloppily hacked together" and "disgracefully poorly designed". Architects, after all, must always consider the broader issues.
|
|
|
|
Aggregation
|
In the architectural idiom, ad hoc shares the vernacular meaning of "done for a particular purpose; done without consideration of broader issues", but adds sneering connotations of "sloppily hacked together" and "disgracefully poorly designed". Architects, after all, must always consider the broader issues.
|
|
|
|
Analysis
|
Analysis is the part of the software development process whose primary purpose is to formulate a model of the problem area.
Analysis focuses on what to do, design focuses on how to do it. |
|
|
|
Analysis Class
|
In formal architectural modeling terms, such as UML, an analysis class is an abstraction of a role played by a design element in the system, typically within the context of a use-case realization. Analysis classes may provide an abstraction for several roles, representing the common behavior of those roles.
Analysis classes typically evolve into one or more design elements (e.g. design classes and/or capsules, or design subsystems). |
|
|
|
Analyst
|
A developer responsible for working directly with project stakeholders to potentially gather information from them, document that information, and/or validate that information.
|
|
|
|
Aspect Oriented Programming
|
Aspect-Oriented Programming (AOP) is an approach to supporting consistent treatment of cross-cutting concerns in a software system.
AOP allows developers to declaratively invoke common code from within a business function to address cross-cutting concerns such as proper exception management, logging, performance benchmarking, et cetera. AOP also supports the notion of code invocation at defined "join points", such as entry or exit from a routine. To optimize the performance of the run-time system, the common code elements are generally copied into the code base by an aspect-aware compiler. |
|
|
|
Application Portfolio
|
The collection of business solutions in use by an organization, taken together.
The management of the application portfolio is a focus of enterprise architecture (EA). In particular, EA seeks to refine the portfolio to fill gaps, eliminate redundancies, and ensure interoperation between applications in the portfolio. |
|
|
|
Application Programming Interface
|
An application programming interface is a specification for how to invoke a software module.
APIs may be specified with "function signatures" that express the function name, the type of its return value, and the types of any parameters it accepts as input. In message-oriented systems, APIs may be expressed as the collection of messages that the module will accept as input, and the messages it may produce as output. |
|
|
|
Architectural Modeling Session
|
A modeling session where the focus is on identifying a high-level strategy for how your system will be built
|
|
|
|
Analyst
|
A developer responsible for working directly with project stakeholders to potentially gather information from them, document that information, and/or validate that information.
|
|
|
|
Aspect Oriented Programming
|
Aspect-Oriented Programming (AOP) is an approach to supporting consistent treatment of cross-cutting concerns in a software system.
AOP allows developers to declaratively invoke common code from within a business function to address cross-cutting concerns such as proper exception management, logging, performance benchmarking, et cetera. AOP also supports the notion of code invocation at defined "join points", such as entry or exit from a routine. To optimize the performance of the run-time system, the common code elements are generally copied into the code base by an aspect-aware compiler. |
|
|
|
Application Portfolio
|
The collection of business solutions in use by an organization, taken together.
The management of the application portfolio is a focus of enterprise architecture (EA). In particular, EA seeks to refine the portfolio to fill gaps, eliminate redundancies, and ensure interoperation between applications in the portfolio. |
|
|
|
Application Programming Interface
|
An application programming interface is a specification for how to invoke a software module.
APIs may be specified with "function signatures" that express the function name, the type of its return value, and the types of any parameters it accepts as input. In message-oriented systems, APIs may be expressed as the collection of messages that the module will accept as input, and the messages it may produce as output. |
|
|
|
Architectural Modeling Session
|
A modeling session where the focus is on identifying a high-level strategy for how your system will be built
|
|
|
|
Aspect
|
An aspect is a programming construct used in aspect-oriented programming to encapsulate the satisfaction of requirements for an area of concern.
Aspects usually address cross-cutting concerns such as proper exception management or logging, but may also be used to address singular functional concerns. Aspects include code snippets and rules for the incorporation of those snippets into the code base. The snippets are typically "woven" into the code base at compile time, hence the expression "aspect weaving". |
|
|
|
Artifact
|
A deliverable or work product which can include almost anything from the architecture including documentation, use-cases, test cases, models and code.
An artifact is really a piece of information that (1) is produced, modified, or used by a process, (2) defines an area of responsibility, and (3) is subject to version control. An artifact can be a model, a model element, or a document. A document can enclose other documents. |
3 things
|
|
|
Areas of Concern
|
Areas of concern are the diverse considerations which must be addressed when designing and implementing a system.
Areas of concern include both subsystems of the system being built, and concerns that recur across the subsystems (the latter are described in the architectural idiom as cross-cutting concerns). Examples of the former include user interface design, business functionality, and data management. Examples of the latter include functional and operational testing, performance auditing, and deployment modeling. Once the concerns are identified, the architect defines rules that allow each concern to be addressed with a minimum of conflict between the teams that own each concern. The most telling differentiator between good and poor software architecture is how well it separates the concerns of a system, such that each may be independently improved over time without causing instability to the overall system. |
|
|
|
Architectural Modeling Session
|
A modeling session where the focus is on identifying a high-level strategy for how your system will be built.
|
|
|
|
Association for Computing Machinery
|
The Association for Computing Machinery is a not-for-profit organization focused on advancing computing as a science and a profession.
Founded in 1947, the ACM is recognized around the world as the "First Society in Computing". The ACM publishes several journals and bestows the A.M Turing Award for lifetime achievement in computing. For more information, visit the ACM Website. |
|
|
|
Asynchronous Messaging
|
An asynchronous message exchange permits indeterminate latency between the request and the response.
Asynchronous messaging is necessary for achieving reliable messaging, so is a fact of life in robust message-oriented distributed systems. |
|
|
|
AUA
|
Another Useless Acronym (AUA) or what can happen when partially formed new architectural ideas emerge.
|
|
|
|
Automagically
|
When something has the capability to perform an indespinsible task that no one thought was even possible.
|
|
