TragicHipster

1) Find visual representation of an E major cord from your chord book

2) Draw that tabular configuration on a piece of paper 5 times

3) Sit yourself down and tap your foot at a moderate pace and count "1 and 2 and 3 and 4" and "1 and "2" and "3" and "4" Tap lightly on 1 and 3, tap heavily on 2 and 4. That's how rock operates. Always. Remember that. If you play it backwards, with an emphasis on 1 and 3, you're playing country.

4) Each segment of "1 and 2 and 3 and 4" is a bar. A number of those segments together are a stanza.

5) Place your fingers on the proper place on the fret board. Strum downwards four times. Hit the strings 4 counts per bar, each strum when your foot hits the ground. Do this for eight bars.

6) Strum up 4 times, instead of down, for 8 bars.

7) Alternate between strumming up, then down, for 8 bars

8) Alternate between strumming down, then up, for 8 bars

9) Reapeat all previous steps at least once

10) Bonus question #1: Try playing 8 bars of the e chord, alternating strumming styles between each bar. Remember, only 4 strums since there are 4 single counts per bar.

11) Bonus question #2: Do the same as 11, but alternate when comortable between adding a swing by alternating between stressing the 1st and 3rd strum/beat and at other times, the 2nd strum/beat and 4th. Mix it up a little bit.

Repeat all of the above and apply the same lesson to the A major chord and the D minor chord.

UML allows vendors and users to extend the language through profiles, which customize the language through the use of stereotypes, tagged values, and constraints.

* SysML is a UML profile for systems engineering applications.
* Magnus Penker and Hans-Erik Eriksson define a business process modeling profile in Business Modeling with UML (2000).
* Peter Coad, et al. show how to customize UML notation and semantics through the use of colors in Java Modeling In Color With UML (1999).
* Scott Ambler has defined a A UML Profile for Data Modeling.

Although UML is a widely recognized and used modeling standard, it is frequently criticized for the following deficiencies:

* Language bloat. UML is often criticized[Who?] as being gratuitously large and complex. It contains many diagrams and constructs that are redundant or infrequently used. This criticism is more frequently directed at UML 2.0 than UML 1.0, since newer revisions include more design-by-committee compromises.
* Problems in learning and adopting. The problems cited above make learning and adopting UML problematic, especially when management forces UML upon engineers lacking the prerequisite skills. (See the ACM article for an amusing account of such issues.)
* Only the code is in sync with the code. Another perspective holds that it is working systems that are important, not beautiful models. As Jack Reeves succinctly put it, "The code is the design."[2] Pursuing this notion leads to the need for better ways of writing software; UML has value in approaches that compile the models to generate source or executable code. This however, may still not be sufficient since UML as a language since it is not clear that UML 2.0's Action Semantics exhibit Turing completeness.
* Cumulative Impedance/Impedance mismatch. As with any notational system, UML is able to represent some systems more concisely or efficiently than others. Thus a developer is influenced toward solutions that most comfortably inhabit the intersection of the strengths between UML and the coding language. This problem is particularly pronounced if the coding implementation language does not adhere to orthodox object-oriented doctrine.
* Tries to be all things to all people. UML is a general purpose modeling language, which tries to achieve compatibility with every possible implementation language. In the context of a specific project, the most applicable features of UML must be delimited for use by the design team to accomplish the specific goal. Additionally, the means of restricting the scope of UML to a particular domain is through a formalism that is not completely formed, and is itself the subject of criticism.


"UML: The Positive Spin", a stringent criticism of UML in the form of a parody -- a mock paper by a student who has been assigned UML as a topic and is desperately trying to find something good to say about it -- was published by Bertrand Meyer in Ed Yourdon's American Programmer magazine. It is available on Eiffel Software's archive site[3].

A paper by Brian Henderson-Sellers at the MoDELS/UML conference in Genova, Italy, October 2006 details flaws in the definition of the UML 2.0 language.

UML uses many concepts from many sources. For a definitive list, consult the glossary of Unified Modeling Language terms. Notable concepts are listed here.

For structure

Actor, attribute, class, component, interface, object, package.

For behavior

Activity, event, message, method, operation, state, use case.

For relationships

Aggregation, association, composition, dependency, generalization (or inheritance).

Other concepts

* Stereotype. It qualifies the symbol it is attached to.
* Multiplicity notation which corresponds to database modeling cardinality, e.g., 1, 0..1, 1..*
* Role

[edit] Criticisms

In UML 2.0 there are 13 types of diagrams. To understand them, it can be useful to categorize them hierarchically
.
Hierarchy of UML 2.0 Diagrams, shown as a class diagram

Structure diagrams emphasize what things must be in the system being modeled:

* Class diagram
* Component diagram
* Composite structure diagram
* Deployment diagram
* Object diagram
* Package diagram

Behavior diagrams emphasize what must happen in the system being modeled:

* Activity diagram
* State Machine diagram
* Use case diagram

Interaction diagrams, a subset of behavior diagrams, emphasize the flow of control and data among the things in the system being modeled:

* Communication diagram
* Interaction overview diagram (UML 2.0)
* Sequence diagram
* UML Timing Diagram (UML 2.0)

The Protocol State Machine is a sub-variant of the State Machine. It may be used to model network communication protocols.

UML does not restrict UML element types to a certain diagram type. In general, every UML element may appear on almost all types of diagrams. This flexibility has been partially restricted in UML 2.0.

In keeping with the tradition of engineering drawings, a comment or note explaining usage, constraint, or intent is always allowed in a UML diagram.

UML is not a method by itself; however, it was designed to be compatible with the leading object-oriented software development methods of its time (for example OMT, Booch, Objectory). Since UML has evolved, some of these methods have been recast to take advantage of the new notation (for example OMT), and new methods have been created based on UML. The best known is Rational Unified Process (RUP). There are many other UML-based methods like Abstraction Method, Dynamic Systems Development Method, and others, designed to provide more specific solutions, or achieve different objectives.

After Rational Software Corporation hired James Rumbaugh from General Electric in 1994, the company became the source for the two most popular object-oriented modeling approaches of the day: Rumbaugh's OMT, which was better for object-oriented analysis (OOA), and Grady Booch's Booch method, which was better for object-oriented design (OOD). Together Rumbaugh and Booch attempted to reconcile their two approaches and started work on a Unified Method.

They were soon assisted in their efforts by Ivar Jacobson, the creator of the OOSE method. Jacobson joined Rational in 1995, after his company, Objectory, was acquired by Rational. The three methodologists were collectively referred to as the Three Amigos, since they were well known to argue frequently with each other regarding methodological preferences.

In 1996 Rational concluded that the abundance of modeling languages was slowing the adoption of object technology, so repositioning the work on a Unified Method, they tasked the Three Amigos with the development of a non-proprietary Unified Modeling Language. Representatives of competing Object Technology companies were consulted during OOPSLA '96, and were won over by Rumbaugh's a cappella rendition of his version of Joni Mitchell's "Clouds". (Indicating the victory of his OMT notation of using boxes for representing classes over Grady Booch's Booch method's notation which used cloud symbols).

Under the technical leadership of the Three Amigos, an international consortium called the UML Partners was organized in 1996 to complete the Unified Modeling Language (UML) specification, and propose it as a response to the OMG RFP. The UML Partners' UML 1.0 specification draft was proposed to the OMG in January 1997. During the same month the UML Partners formed a Semantics Task Force, chaired by Cris Kobryn and administered by Ed Eykholt, to finalize the semantics of the specification and integrate it with other standardization efforts. The result of this work, UML 1.1, was submitted to the OMG in August 1997 and adopted by the OMG in November 1997.[1]

As a modeling notation, the influence of the OMT notation dominates (e.g., using rectangles for classes and objects). Though the Booch "cloud" notation was dropped, the Booch capability to specify lower-level design detail was embraced. The use case notation from Objectory and the component notation from Booch were integrated with the rest of the notation, but the semantic integration was relatively weak in UML 1.1, and was not really fixed until the UML 2.0 major revision.

Concepts from many other OO methods were also loosely integrated with UML with the intent that UML would support all OO methods. For example CRC Cards (circa 1989 from Kent Beck and Ward Cunningham), and OORam were retained. Many others contributed too with their approaches flavoring the many models of the day including: Tony Wasserman and Peter Pircher with the "Object-Oriented Structured Design (OOSD)" notation (not a method), Ray Buhr's "Systems Design with Ada", Archie Bowen's use case and timing analysis, Paul Ward's data analysis and David Harel's "Statecharts". as the group tried to ensure broad coverage in the real-time systems domain. As a result, UML is useful in a variety of engineering problems, from single process, single user applications to concurrent, distributed systems, making UML rich but large.

The Unified Modeling Language is an international standard:

ISO/IEC 19501:2005 Information technology -- Open Distributed Processing -- Unified Modeling Language (UML) Version 1.4.2.

UML has matured significantly since UML 1.1. Several minor revisions (UML 1.3, 1.4, and 1.5) fixed shortcomings and bugs with the first version of UML, followed by the UML 2.0 major revision, which is the current OMG standard.

The first part of UML 2.0, the Superstructure which describes the new diagrams and modeling elements available, was adopted by the OMG in October 2004. Other parts of UML 2, notably the infrastructure, the Object Constraint Language (OCL) and the diagram interchange were yet to be completed and ratified as of November 2005.

The final UML 2.0 specification has been declared available and has been added to OMG's formal specification library. The other parts of the UML specification, the UML 2.0 infrastructure, the UML 2.0 Diagram Interchange, and UML 2.0 OCL specifications have been adopted.

UML version 2.1 revision is being developed, and should be available in the form of an XMI 2.1 version of the UML 2.1 version. The corresponding XMI 2.1 file will be made available from the OMG ADTF group.

Most of the commercially successful UML tools now support most of UML 2.0, leaving only the rarely used features left to implement. Of course, it will take some time for the tools that are in the hands of the developers to reach this level of compliance.

Design patterns can be classified in terms of the underlying problem they solve. Examples of problem-based pattern classifications include:

* Fundamental patterns
o Delegation pattern: an object outwardly expresses certain behaviour but in reality delegates responsibility
o Functional design: strives for each modular part of a computer program has only one responsibility and performs that with minimum side effects
o Interface pattern: method for structuring programs so that they're simpler to understand
o Proxy pattern: an object functions as an interface to another, typically more complex, object
o Façade pattern: provides a simplified interface to a larger body of code, such as a class library.
o Composite pattern: defines Composite object (e.g. a shape) designed as a composition of one-or-more similar objects (other kinds of shapes/geometries), all exhibiting similar functionality. The Composite object then exposes properties and methods for child objects manipulation as if it were a simple object.

* Creational patterns which deal with the creation of objects. Abstract Factory and Factory Method are creation patterns
o Abstract factory pattern: centralize decision of what factory to instantiate
o Factory method pattern: centralize creation of an object of a specific type choosing one of several implementations
o Builder pattern: separate the construction of a complex object from its representation so that the same construction process can create different representations
o Lazy initialization pattern: tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed
o Object pool: avoid expensive acquisition and release of resources by recycling objects that are no longer in use
o Prototype pattern: used when the inherent cost of creating a new object in the standard way (e.g., using the 'new' keyword) is prohibitively expensive for a given application
o Singleton pattern: restrict instantiation of a class to one object

* Structural patterns that ease the design by identifying a simple way to realize relationships between entities. Adapter is a structural pattern
o Adapter pattern: 'adapts' one interface for a class into one that a client expects
o Aggregate pattern: a version of the Composite pattern with methods for aggregation of children
o Bridge pattern: decouple an abstraction from its implementation so that the two can vary independently
o Composite pattern: a tree structure of objects where every object has the same interface
o Decorator pattern: add additional functionality to a class at runtime where subclassing would result in an exponential rise of new classes
o Extensibility pattern: aka. Framework - hide complex code behind a simple interface
o Façade pattern: create a simplified interface of an existing interface to ease usage for common tasks
o Flyweight pattern: a high quantity of objects share a common properties object to save space
o Proxy pattern: a class functioning as an interface to another thing
o Pipes and filters: a chain of processes where the output of each process is the input of the next
o Private class data pattern: restrict accessor/mutator access

* Behavioral patterns that identify common communication patterns between objects and realize these patterns. Interpreter is a behavioral pattern
o Chain of responsibility pattern: Command objects are handled or passed on to other objects by logic-containing processing objects
o Command pattern: Command objects encapsulate an action and its parameters
o Interpreter pattern: Implement a specialized computer language to rapidly solve a specific set of problems
o Iterator pattern: Iterators are used to access the elements of an aggregate object sequentially without exposing its underlying representation
o Mediator pattern: Provides a unified interface to a set of interfaces in a subsystem
o Memento pattern: Provides the ability to restore an object to its previous state (rollback)
o Null Object pattern: Designed to act as a default value of an object
o Observer pattern: aka Publish/Subscribe or Event Listener. Objects register to observe an event which may be raised by another object
o State pattern: A clean way for an object to partially change its type at runtime
o Strategy pattern: Algorithms can be selected on the fly
o Specification pattern: Recombinable Business logic in a boolean fashion
o Template method pattern: Describes the program skeleton of a program
o Visitor pattern: A way to separate an algorithm from an object
o Single-serving visitor pattern: Optimise the implementation of a visitor that is allocated, used only once, and then deleted
o Hierarchical visitor pattern: Provide a way to visit every node in a hierarchical data structure such as a tree.

* Concurrency patterns
o Active Object
o Balking pattern
o Double checked locking pattern
o Guarded suspension
o Leaders/followers pattern
o Monitor Object
o Read write lock pattern
o Scheduler pattern
o Thread pool pattern
o Thread-Specific Storage
o Reactor pattern

[edit] Documentation

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.

Design patterns are composed of several sections (see Documentation below). Of particular interest are the Structure, Participants, and Collaboration sections. These sections describe a design motif: a prototypical micro-architecture that developers copy and adapt to their particular designs to solve the recurrent problem described by the design pattern. A micro-architecture is a set of program constituents (e.g., classes, methods...) and their relationships. Developers use the design pattern by introducing in their designs this prototypical micro-architecture, which means that micro-architectures in their designs will have structure and organization similar to the chosen design motif.

In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.

Patterns originated as an architectural concept by Christopher Alexander (1977/79). In 1987, Kent Beck and Ward Cunningham began experimenting with the idea of applying patterns to programming and presented their results at the OOPSLA conference that year.[1][2] In the following years, Beck, Cunningham and others followed up on this work.

Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Software was published in 1994 (Gamma et al). That same year, the first Pattern Languages of Programs conference was held and the following year, the Portland Pattern Repository was set up for documentation of design patterns. The scope of the term remained a matter of dispute into the next decade.

Although the practical application of design patterns is a phenomenon, formalization of the concept of a design pattern languished for several years.[3]