ArchetypeFrom Wikipedia, the free encyclopediaFor other uses, seeArchetype (disambiguation).The concept of anarchetype/rktap/is found in areas relating tobehavior,modern psychological theory, and literary analysis. An archetype can be:1. a statement, pattern of behavior, orprototypewhich other statements, patterns of behavior, and objects copy or emulate; 2. aPlatonic philosophical ideareferring to pureformswhich embody the fundamental characteristics of a thing; 3. a collectively-inherited unconscious idea, pattern of thought, image, etc., that is universally present in individual psyches, as inJungian psychology; 4. or a constantly recurring symbol or motif in literature, painting, or mythology (this usage of the term draws from bothcomparative anthropologyandJungian archetypal theory).In the first sense, many more informal terms are frequently used instead, such as "standard example" or "basic example", and the longer form "archetypal example" is also found. In mathematics, an archetype is often called a "canonicalexample".Etymology[edit]The wordarchetypefirst entered into English usage in the 1540s[1]and derives from theLatinnounarchetypum, which thelatinisationof theGreeknoun archetupon,whoseadjectiveform is archetuposand which means "first-molded,"[2]which is a compound of arch, "beginning, origin"[3]and tupos, which can mean, amongst other things, "pattern," "model," or "type."[4]The word 'pattern' comes from the Greek root 'pater-', meaning 'father'.[5]So archetype can be understood as the principle pattern, from which others are copied from.[6]Plato[edit]Main article:Theory of FormsThe origins of the archetypal hypothesis date back as far asPlato. In the seventeenth century, SirThomas BrowneandFrancis Baconboth employ the word 'archetype' in their writings. Browne employed it inThe Garden of Cyrusin some attempts to depict archetypes in his citing of symbolic proper-names. Plato'sideaswere pure mental forms that were imprinted in the soul before it was born into the world. They were collective in the sense that they embodied the fundamental characteristics of a thing rather than its specific peculiarities.Jungian archetypes[edit]Main article:Jungian archetypesThe concept of psychological archetypes was advanced by the Swiss psychiatristCarl Jung, c. 1919. In Jung's psychological framework, archetypes are innate, universal prototypes for ideas and may be used to interpret observations. A group of memories and interpretations associated with an archetype is acomplex( e.g. a mother complex associated with the mother archetype). Jung treated the archetypes as psychological organs, analogous to physical ones in that both are morphological constructs that arose throughevolution.[7]Jung states in part one of 'Man And His Symbols' (12th printing, Nov.1973) that: "My views about the 'archaic remnants', which I call 'archetypes' or 'primordial images,' have been constantly criticized by people who lack a sufficient knowledge of the psychology of dreams and of mythology.The term 'archetype' is often misunderstood as meaning certain definite mythological images or motifs[clarify], but these are nothing more than conscious representations. Such variable representations cannot be inherited. The archetypeis a tendency to form such representationsof a motifrepresentations that can vary a great deal in detail without losing their basic pattern."Archetype patternFrom Wikipedia, the free encyclopediaTheArchetype patternseparates the logic from implementation; the separation is accomplished by there being two abstract classes, a decorator (for logic) and a delegate (for implementation). The Factory handles the mapping of decorator and delegate classes and returns the pair associated with a parameter or parameters passed. The interface is the contract between a decorator, a delegate and the calling class creating anInversion of Responsibility.[1]This example use two branches however you can have 'N' branches as required. The pattern means that one branch from the interface does not have to worry about how another branch operators as long it implements the interface.Sections[edit]DecoratorThe descendants of the decorator class handle the logic, for example performing a calculation. The descendants of the decorator can then call the descendants of the delegated when or if they wish to pass responsibility for example storage or communication.DelegateThe descendants of the delegate flow class handle the implementation for call a sub-system, storage, or communication. Different children can use completely sub-systems storage, or communications than each other.UML[edit]

Model-driven architecture(MDA) is asoftware designapproach for the development ofsoftware systems. It provides a set of guidelines for the structuring of specifications, which are expressed asmodels. Model-driven architecture is a kind ofdomain engineering, and supportsmodel-driven engineeringof software systems. It was launched by theObject Management Group(OMG) in 2001.[1]The model-driven architecture approach defines system functionality using aplatform-independent model(PIM) using an appropriatedomain-specific language(DSL)[citation needed].Then, given aplatform modelcorresponding toCORBA,.NET, the Web, etc., the PIM is translated to one or moreplatform-specific models(PSMs) that computers can run. This requires mappings and transformations and should be modeled too.The PSM may use different DSLs or ageneral purpose language.[citation needed]. Automated tools generally perform this translation.The OMG organization provides rough specifications rather than implementations, often as answers toRequests for Proposals(RFPs). Implementations come from private companies or open source groups.MDA principles can also apply to other areas such asbusiness process modeling(BPM) where the PIM is translated to either automated or manual processes[citation needed].MDA approach[edit]OMG focuses Model-driven architecture on forward engineering, i.e. producing code from abstract, human-elaborated modelling diagrams (e.g. class diagrams)[citation needed]. OMG's ADTF (Analysis and Design Task Force) group leads this effort. With some humour, the group chose ADM (MDA backwards) to name the study of reverse engineering. ADM decodes to Architecture-Driven Modernization. The objective of ADM is to produce standards for model-based reverse engineering of legacy systems.[3]Knowledge Discovery Metamodel(KDM) is the furthest along of these efforts, and describes information systems in terms of various assets (programs, specifications, data, test files, database schemas, etc.).One of the main aims of the MDA is to separate design from architecture[citation needed]. As the concepts and technologies used to realize designs and the concepts and technologies used to realize architectures have changed at their own pace, decoupling them allows system developers to choose from the best and most fitting in both domains. The design addresses the functional (use case) requirements while architecture provides the infrastructure through which non-functional requirements like scalability, reliability and performance are realized. MDA envisages that the platform independent model (PIM), which represents a conceptual design realizing the functional requirements, will survive changes in realization technologies andsoftware architectures.Of particular importance to model-driven architecture is the notion ofmodel transformation. A specific standard language for model transformation has been defined byOMGcalledQVT.

CRM Archetype pattern

Product type pattern

Unit 6:Dataflow architectureFrom Wikipedia, the free encyclopediaDataflow architectureis acomputer architecturethat directly contrasts the traditionalvon Neumann architectureorcontrol flowarchitecture. Dataflow architectures do not have aprogram counter, or (at least conceptually) the executability and execution of instructions is solely determined based on the availability of input arguments to the instructions, so that the order of instruction execution is unpredictable: i. e. behavior is indeterministic.Although no commercially successful general-purpose computer hardware has used a dataflow architecture, it has been successfully implemented in specialized hardware such as indigital signal processing,network routing,graphics processing,telemetry, and more recently in data warehousing. It is also very relevant in many software architectures today includingdatabaseengine designs andparallel computingframeworks.Synchronous dataflow architectures tune to match the workload presented by real-time data path applications such as wire speed packet forwarding. Dataflow architectures that are deterministic in nature enable programmers to manage complex tasks such as processor load balancing, synchronization and accesses to common resources.[1]Dataflow architecture topics[edit]Static and Dynamic dataflow machines[edit]Designs that use conventional memory addresses as data dependency tags are called static dataflow machines. These machines did not allow multiple instances of the same routines to be executed simultaneously because the simple tags could not differentiate between them.Designs that usecontent-addressable memory(CAM) are called dynamic dataflow machines. They use tags in memory to facilitate parallelism.Compiler[edit]Normally,compilersanalyze programsource codefor data dependencies between instructions in order to better organize the instruction sequences in the binary output files. The instructions are organized sequentially but the dependency information itself is not recorded in the binaries. Binaries compiled for a dataflow machine contain this dependency information.A dataflow compiler records these dependencies by creating unique tags for each dependency instead of using variable names. By giving each dependency a unique tag, it allows the non-dependent code segments in the binary to be executedout of orderand in parallel.Programs[edit]Programs are loaded into the CAM of a dynamic dataflow computer. When all of the tagged operands of an instruction become available (that is, output from previous instructions and/or user input), the instruction is marked as ready for execution by anexecution unit.This is known asactivatingorfiringthe instruction. Once an instruction is completed by an execution unit, its output data is stored (with its tag) in the CAM. Any instructions that are dependent upon this particular datum (identified by its tag value) are then marked as ready for execution. In this way, subsequent instructions are executed in proper order, avoidingrace conditions. This order may differ from the sequential order envisioned by the human programmer, the programmed order.Instructions[edit]An instruction, along with its required data operands, is transmitted to an execution unit as a packet, also called aninstruction token. Similarly, output data is transmitted back to the CAM as adata token. The packetization of instructions and results allows for parallel execution of ready instructions on a large scale.Dataflow networks deliver the instruction tokens to the execution units and return the data tokens to the CAM. In contrast to the conventionalvon Neumann architecture, data tokens are not permanently stored in memory, rather they are transient messages that only exist when in transit to the instruction storage.

Software Architecture VO/KU (706.016/706.017)Architectural StylesDenis HelicIICM, TU GrazExperience in building software systems Over the years a lot of experience was gained In any design: certain patterns and structures appear very often Such patterns and structures become a part of thevocabulary Vocabulary is used by designers to think and talk about the architectural designArchitectural style: definition (1) An architectural style is a particular pattern that focuses on the large-scale of a system We can look on a style from concptual, execution and implementation point of view This is same as with any other software architectureArchitectural style: definition (2) An architectural style is constrained by a particular principle of how to build systems How components are organized, how data is manipulated, how compononents communicate, ...? E.g. a hierarchy of components, sequential processing of data, asynchronous communication, ... Each principle influences some quality attributes in a positive and some other in a negetive way It is again balancing between advantages and disadvantagesClassification of styles Data-centered architectures Data-flow architectures Abstraction layer architectures N-tier architectures Notification architectures Remote invokation and service architectures Heterogeneous architecturesData-centered architectures (1) These architectures have the goal of achieving the quality of integrability of data. The term refers to systems in which the access and update of a widely accessed data store is their primary goal. Basically, it is nothing more than a centralized data store that communicates with a number of clients Important for this styles are three protocols: communication, data definition and data manipulation protocolData-centered architectures (2) The means of communication distinguishes the two subtypes: repository and blackboard Repository: a client sends a request to the system to perform a necessary action (e.g. insert data) Blackboard: the system sends notification and data to subscribers when data of interest changes, and is thus activeRepository

Blackboard

Database architecture (1) One of the most well-known examples of the data-centered architecture, is a database architecture There is a common database schema (i.e. meta-structure of the repository) - created with data definition protocol E.g. in RDBMS a set of related tables with fields, data types, keys, ...Database architecture (2) Clients use data manipulation protocol to work with the data E.g. SQL for inserting, selecting, deleteing data, ... Depending on where clients are situated communication protocol might be An inner-proces communication Communication between components on the same machine Communication over network, e.g. LAN, Internet, etc.Data-centered architectures: analysis Ensures data integrity Reliable, secure, testability guaranteed Clients independent on the system: performance and usability on the client side is good Problems with scalability Solutions: shared repositories, replication but this increases complexityWeb architecture (1) Another example of data-centered architectures is the Web architecture There is a common data schema (i.e. meta-structure of the Web) Follows hypermedia data model Pages (nodes) and links between them, as well as addressing mechanismWeb architecture (2) Data manipulation not directly in the system but typically achieved through applications Although HTTP protocol has methods for data manipulation Communication protocol is HTTP Analysis: integrity not guaranteed (404 error) but extremely scalableResource-Oriented Architecture Such architectures look onto the Web as a huge distibuted database Data model: nodes addressable by URL and interlinked Data manipulation: HTTP methods (GET, PUT, POST, DELETE) Scalable, good performance, usability, etc.Data-flow architectures (1) These architectures have the goal of achieving the quality of reuse and modifiability. The data-flow style is characterized by viewing the system as a series of transformations on successive pieces of input data. Data enter the system and then flows through the components one at a time until Finally, the data is assigned to some final destination (output or a data store).Data-flow architectures (2) Data-flow architectures can be classified into batch-sequential architectures and pipe and filters In the batch sequential style each step runs to completion before the next step starts E.g. UNIX command line pipes In pipe and filters style steps might run concurrently processing parts of data incrementallyPipes and filters (1) Data flows through pipes: communication channels between filters Processing units: filters Depending on where the filters reside different execution architectures E.g. same process: filters run within threads E.g. same machine: filters run within own processes E.g. network: pipes use the networking architecturePipes and filters (2) Conceptually filters consume data from input and writes data to output Input and output: communication channels, i.e. pipes Depending on where the filters reside different execution architectures Filters do not know anything about other filters Modularity, maintainability is good Data flows in streams: good for processing of images, audio, video, ...Pipes and filters (3)

Pipes and filters (4) Variations: structural and communicational Structural: more complex topologies might be used E.g. loops, branches, more than one input, ...Pipes and filters (5)

Pipes and filters (6) Communicational: are filters blocked and wait for data? Other forms of synchronization E.g. when there is only a single communication channel Blocking might compromise performance E.g. recently very popular NIO (non-blocking input/output) in networking applicationsAbstract layer architectures Layering: the structure of the system is organized into set of layers Each layer in on the top of another layer Well-defined interfaces between layers Reduces complexity, improves modularity, reusability, maintainability Different criteria for layering: most notably abstractionExample

Operating systems (1) Typically organized into layers Successive layers provide more sophisticated services to the layers above them Hardware services, kernel services, system services, UI servicesOperating systems (2)

Virtual machines (1) A virtual machine implements an instruction set for an imaginery machine Often virtual machines are the underlaying mechanism by which a programming language is executed E.g. Java virtual machine, different interpreters Specifies an interface between compiler and a real machine From conceptual point of view very similar to OS Improves portabilityVirtual machines (2)

Peer-to-peer protocol stacks (1) A common example of layered architecture is a network protocol stack E.g. TCP/IP protocol stack Four layers The lowest layer handles communication between two computers The internet layer handles routing of packets accross the networkPeer-to-peer protocol stacks (2) The transport layer guarantees that packets are error-free abd received in the same order as sent The application layer supports application-specific protocols E.g. HTTP, SMTP, FTP, ... The layers consitute a series of increasingly abstract operations Higher layers span a virtual connection between computers on the networkPeer-to-peer protocol stacks (3)

Database-centric architectureFrom Wikipedia, the free encyclopediaDatabase-centric Architectureordata-centric architecturehas several distinct meanings, generally relating tosoftware architecturesin whichdatabasesplay a crucial role. Often this description is meant to contrast the design to an alternative approach. For example, the characterization of an architecture as "database-centric" may mean any combination of the following: using a standard, general-purposerelational database management system, as opposed to customized in-memoryorfile-baseddata structuresandaccess methods. With the evolution of sophisticatedDBMSsoftware, much of which is either free or included with theoperating system, application developers have become increasingly reliant on standard database tools, especially for the sake ofrapid application development. using dynamic,table-driven logic, as opposed to logic embodied in previouslycompiledprograms. The use of table-driven logic, i.e. behavior that is heavily dictated by the contents of a database, allows programs to be simpler and more flexible. This capability is a central feature ofdynamic programming languages. See alsocontrol tablesfor tables that are normally coded and embedded within programs asdata structures(i.e. not compiled statements) but could equally be read in from aflat file,databaseor even retrieved from aspreadsheet. usingstored proceduresthat run ondatabase servers, as opposed to greater reliance on logic running in middle-tierapplication serversin amulti-tier architecture. The extent to whichbusiness logicshould be placed at the back-end versus another tier is a subject of ongoing debate. For example, Toon Koppelaars presents a detailed analysis of alternativeOracle-basedarchitectures that vary in the placement of business logic, concluding that a database-centric approach has practical advantages from the standpoint of ease of development and maintainability. using a shared database as the basis for communicating betweenparallel processesindistributed computingapplications, as opposed to directinter-process communicationviamessage passingfunctions andmessage-oriented middleware. A potential benefit of database-centric architecture indistributed applicationsis that it simplifies the design by utilizing DBMS-providedtransaction processingandindexingto achieve a high degree of reliability, performance, and capacity.[1]For example,Base Onedescribes a database-centric distributed computing architecture forgridandclustercomputing, and explains how this design provides enhanced security, fault-tolerance, andscalability.[2]

Component-based software engineeringFrom Wikipedia, the free encyclopedia

A simple example of two components expressed inUML2.0. The checkout component, responsible for facilitating the customer's order,requiresthe card processing component to charge the customer's credit/debit card (functionality that the latterprovides).

Component-based software engineering (CBSE)(also known ascomponent-based development (CBD)) is a branch ofsoftware engineeringthat emphasizes theseparation of concernsin respect of the wide-ranging functionality available throughout a givensoftware system. It is a reuse-based approach to defining, implementing and composing loosely coupled independent components into systems. This practice aims to bring about an equally wide-ranging degree of benefits in both the short-term and the long-term for the software itself and for organizations that sponsor such software.Software engineers[who?]regard components as part of the starting platform forservice-orientation. Components play this role, for example, inweb services, and more recently, inservice-oriented architectures(SOA), whereby a component is converted by the web service into aserviceand subsequently inherits further characteristics beyond that of an ordinary component.Components can produce or consume events and can be used forevent-driven architectures(EDA).

Definition and characteristics of components[edit]An individualsoftware componentis asoftware package, aweb service, aweb resource, or amodulethat encapsulates a set of relatedfunctions(or data).All system processes are placed into separate components so that all of the data and functions inside each component are semantically related (just as with the contents of classes). Because of this principle, it is often said that components aremodularandcohesive.With regard to system-wide co-ordination, components communicate with each other viainterfaces. When a component offers services to the rest of the system, it adopts aprovidedinterface that specifies the services that other components can utilize, and how they can do so. This interface can be seen as a signature of the component - the client does not need to know about the inner workings of the component (implementation) in order to make use of it. This principle results in components referred to asencapsulated. TheUMLillustrations within this article represent provided interfaces by a lollipop-symbol attached to the outer edge of the component.However, when a component needs to use another component in order to function, it adopts ausedinterface that specifies the services that it needs. In the UML illustrations in this article,used interfacesare represented by an open socket symbol attached to the outer edge of the component.

A simple example of several software components - pictured within a hypothetical holiday-reservation system represented inUML2.0.Another important attribute of components is that they aresubstitutable, so that a component can replace another (at design time or run-time), if the successor component meets the requirements of the initial component (expressed via the interfaces). Consequently, components can be replaced with either an updated version or an alternative without breaking the system in which the component operates.As ageneral rule of thumbfor engineers substituting components, component B can immediately replace component A, if component B provides at least what component A provided and uses no more than what component A used.Software components often take the form ofobjects(notclasses) or collections of objects (fromobject-oriented programming), in some binary or textual form, adhering to someinterface description language(IDL) so that the component may exist autonomously from other components in acomputer.When a component is to be accessed or shared across execution contexts or network links, techniques such asserializationormarshallingare often employed to deliver the component to its destination.Reusabilityis an important characteristic of a high-quality software component. Programmers should design and implement software components in such a way that many different programs can reuse them. Furthermore,component-based usability testingshould be considered when software components directly interact with users.It takes significant effort and awareness to write a software component that is effectively reusable. The component needs to be: fully documented thoroughly tested robust - with comprehensive input-validity checking able to pass back appropriateerror messagesor return codes designed with an awareness that itwillbe put to unforeseen usesIn the 1960s, programmers built scientificsubroutinelibraries that were reusable in a broad array of engineering and scientific applications. Though these subroutine libraries reused well-definedalgorithmsin an effective manner, they had a limited domain of application. Commercial sites routinely created application programs from reusable modules written inAssembler,COBOL,PL/1and othersecond-andthird-generation languagesusing bothsystemand user application libraries.As of 2010, modern reusable components encapsulate both data structures and the algorithms that are applied to the data structures. It[clarification needed]builds on prior theories ofsoftware objects,software architectures,software frameworksandsoftware design patterns, and the extensive theory ofobject-oriented programmingand theobject oriented designof all these. It claims that software components, like the idea of hardwarecomponents, used for example in telecommunications,[1]can ultimately be made interchangeable and reliable. On the other hand, it is argued[by whom?]that it is a mistake to focus on independent components rather than the framework (without which they would not exist).[2]