This HTML5 document contains 40 embedded RDF statements represented using HTML+Microdata notation.

The embedded RDF content will be recognized by any processor of HTML5 Microdata.

Namespace Prefixes

Prefix	IRI
dcterms	http://purl.org/dc/terms/
dbo	http://dbpedia.org/ontology/
foaf	http://xmlns.com/foaf/0.1/
n4	https://global.dbpedia.org/id/
dbt	http://dbpedia.org/resource/Template:
rdfs	http://www.w3.org/2000/01/rdf-schema#
n17	http://www.csi.uottawa.ca:4321/oose/
n15	http://www.sei.cmu.edu/architecture/start/
freebase	http://rdf.freebase.com/ns/
rdf	http://www.w3.org/1999/02/22-rdf-syntax-ns#
n11	http://www.sei.cmu.edu/architecture/tools/atam/
owl	http://www.w3.org/2002/07/owl#
wikipedia-en	http://en.wikipedia.org/wiki/
dbc	http://dbpedia.org/resource/Category:
dbp	http://dbpedia.org/property/
prov	http://www.w3.org/ns/prov#
xsdh	http://www.w3.org/2001/XMLSchema#
gold	http://purl.org/linguistics/gold/
wikidata	http://www.wikidata.org/entity/
dbr	http://dbpedia.org/resource/

Statements

Subject Item

dbr:Juan_Pavón

dbo:wikiPageWikiLink

dbr:Software_architectural_model

Subject Item

dbr:Software_Architectural_Model

dbo:wikiPageWikiLink

dbr:Software_architectural_model

dbo:wikiPageRedirects

dbr:Software_architectural_model

Subject Item

dbr:Software_architectural_model

rdf:type

owl:Thing dbo:Software

rdfs:label

Software architectural model

rdfs:comment

An architectural model (in software) is a rich and rigorous diagram created using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. Software architects use architectural models to communicate with others and seek peer feedback. An architectural model is an expression of a viewpoint in software architecture. Some key elements in a software architectural model include:

owl:differentFrom

dbr:Computer_model

dcterms:subject

dbc:Software_architecture dbc:Software_development dbc:Software_design_patterns

dbo:wikiPageID

7985045

dbo:wikiPageRevisionID

1115439821

dbo:wikiPageWikiLink

dbc:Software_design_patterns dbc:Software_architecture dbr:Software dbr:Software_architect dbr:Service-oriented_modeling dbr:Architecture_tradeoff_analysis_method dbc:Software_development

dbo:wikiPageExternalLink

n11: n15:definitions.cfm n17:index.html%23architecturalmodel

owl:sameAs

n4:4vGfN freebase:m.026mfw7 wikidata:Q7554245

dbp:wikiPageUsesTemplate

dbt:Unreferenced dbt:Software-eng-stub dbt:Multiple_issues dbt:Tone dbt:Reflist dbt:Distinguish dbt:No_footnotes

dbo:abstract

An architectural model (in software) is a rich and rigorous diagram created using available standards, in which the primary concern is to illustrate a specific set of tradeoffs inherent in the structure and design of a system or ecosystem. Software architects use architectural models to communicate with others and seek peer feedback. An architectural model is an expression of a viewpoint in software architecture. Some key elements in a software architectural model include: * Rich: For the viewpoint in question, there should be sufficient information to describe the area in detail. The information should not be lacking or vague. The goal is to minimize misunderstandings, not perpetuate them. See notes below on 'primary concern.' * Rigorous: The architect has applied a specific methodology to create this particular model, and the resulting model 'looks' a particular way. A test of rigorousness may state that if two architects, in different cities, were describing the same thing, the resulting diagrams would be nearly identical (with the possible exception of visual layout, to a point). * Diagram: In general, a model may refer to any abstraction that simplifies something for the sake of addressing a particular viewpoint. This definition specifically subclasses 'architectural models' to the subset of model descriptions that are represented as diagrams. * Standards: Standards work when everyone knows them and everyone uses them. This allows a level of communication that cannot be achieved when each diagram is substantially different from another. UML is the most often quoted standard. * Primary Concern: It is easy to be too detailed by including many different needs in a single diagram. This should be avoided. It is better to draw multiple diagrams, one for each viewpoint, than to draw a 'mega diagram' that is so rich in content that it requires a two-year course of study to understand it. Remember this: when building houses, the architect delivers many different diagrams. Each is used differently. Frequently the final package of plans will include diagrams with the floor plan many times: framing plan, electrical plan, heating plan, plumbing, etc. They ensure that the information provided is only what is needed. For example, a plumbing subcontractor doesn't need the details that an electrician would need to know. * Illustrate: The idea behind creating a model is to communicate and seek valuable feedback. The goal of the diagram should be to answer a specific question and to share that answer with others to (a) see if they agree, and (b) guide their work. Rule of thumb: know what it is you want to say, and whose work you intend to influence with it. * Specific Set of Tradeoffs: The architecture tradeoff analysis method (ATAM) methodology describes a process whereby software architecture can be peer-reviewed for appropriateness. ATAM does this by starting with a basic notion: there is no such thing as a 'one-size-fits-all' design. People can create a generic design, but then they need to alter it to specific situations based on the business requirements. In effect, people make tradeoffs. The diagram should make those specific tradeoffs visible. Therefore, before an architect creates a diagram, he or she should be prepared to describe, in words, which tradeoffs they are attempting to illustrate in this model. * Tradeoffs Inherent in the Structure and Design: A component is not a tradeoff. Tradeoffs rarely translate into an image on the diagram. Tradeoffs are the first principles that produced the design models. When an architect wishes to describe or defend a particular tradeoff, the diagram can be used to defend the position. * System or Ecosystem: Modeling in general can be done at different levels of abstraction. It is useful to model the architecture of a specific application, complete with components and interactions. It is also reasonable to model the systems of applications needed to deliver a complete business process (like order-to-cash). It is not commonly useful, however, to view the model of a single component and its classes as software architecture. At that level, the model, while valuable in its own right, illustrates design much more so than architecture.

gold:hypernym

dbr:Diagram

prov:wasDerivedFrom

wikipedia-en:Software_architectural_model?oldid=1115439821&ns=0

dbo:wikiPageLength

5307

foaf:isPrimaryTopicOf

wikipedia-en:Software_architectural_model

Subject Item

dbr:Software_architecture_description

dbo:wikiPageWikiLink

dbr:Software_architectural_model

Subject Item

wikipedia-en:Software_architectural_model

foaf:primaryTopic

dbr:Software_architectural_model