architecture vs design
DESCRIPTION
My take on the difference between software architecture and software design. Also highlights similarities between ISO/IEC/IEEE 42010-2011 (Systems and software engineering — Architecture description) and IEEE STD 1016-2009 (Systems Design — Software Design Descriptions)TRANSCRIPT
Luc Trudeau
Département de génie logiciel et des technologies
de l’information
Montréal, Québec, CanadaL’ÉTS est une constituante du
réseau de l'Université du Québec
ISO/IEC/IEEE 42010-2011 vs. IEEE STD 1016-2009
(Architecture vs. Design)
Département de génie logiciel et des technologies de l’information
L Trudeau
2
Explain de differences between architecture and software design
Identify the key elements of 42010 and the relations between them
Identify the key elements of 1016 and the relations between them
Discuss of the common concepts between 42010 and 1016
Learning objectives42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
3
Architecture and design is quite similar to the federal and provincial government
Architecture vs. Design42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
4
Federal government legislate matters common to more than one province
Architecture documents matters common to more than one module/component
Federal Government (Architecture)42010-2011 vs. 1016-2009
Federal government Architecture
Inter-Provincial highways Inter-Module dependencies
Postal service Interfaces
Military Behavior
... …
Legislating is fancy word for documenting
Département de génie logiciel et des technologies de l’information
L Trudeau
5
“Provinces may legislate on matters of a merely local or private nature”
Software design may document on matters of a merely local or private nature
Provincial Government (Software Design)
42010-2011 vs. 1016-2009
Provincial government Software design
Education Classes and objects
Provincial officers Software design patterns
Municipal government Dependencies
... …
“may” because you don’t need to document everything
Département de génie logiciel et des technologies de l’information
L Trudeau
6
Architecture vs Software Design42010-2011 vs. 1016-2009
(Adapted from McConnell, Steve. 2004. Code Complete: A Practical Handbook of Software Construction, Second Edition. 2nd ed. Microsoft Press, July 7.)
Requirements,Constraints, Quality attributes,Concerns…
Architecture
SoftwareDesign
Implémentation
Assign Responsibilities
Requirements,Constraints, Quality attributes,Concerns…
Requirements,Constraints, Quality attributes,Concerns…
Requirements,Constraints, Quality attributes,Concerns…
Département de génie logiciel et des technologies de l’information
L Trudeau
7
These standards don’t tell you how to do your architecture or your software design.
They tell you how to write an architecture document (Architecture description) or a software design document (Software design description)
Let’s just get one thing straight42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
8
You probably think of something like this
That’s a good start, but there’s a lot more to consider…
When you think of an architecture document
42010-2011 vs. 1016-2009
ArchitectureDescription
ArchitectureModel
The document I want to write
The diagrams I will use to explain my architecture
Département de génie logiciel et des technologies de l’information
L Trudeau
9
ISO/IEC/IEEE 42010 (2011)Systems and software engineering —
Architecture description
42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
10
42010-2011 vs. 1016-2009
This is the document that describes the architecture. This is your main deliverable as an architect and this standard tells you what to put in it
Département de génie logiciel et des technologies de l’information
L Trudeau
11
An architecture description shall identify the system-of-interest and include supplementary information as determined by the project and/or organization.
The detailed content of identifying and supplementary information items shall be as specified by the organization and/or project.
The Shalls (Architecture description)
42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
12
42010-2011 vs. 1016-2009
Users, operators, acquirers, suppliers, developers, builders, maintainers…
This part of your document is strongly linked to the Vision document or SRS (if they are used in the project)
Département de génie logiciel et des technologies de l’information
L Trudeau
13
An architecture description shall identify the system stakeholders having concerns considered fundamental to the architecture of the system-of-interest.
The following stakeholders shall be considered and when applicable, identified in the architecture description:
users of the system operators of the systemacquirers of the system owners of the systemsuppliers of the system developers of the
system builders of the system maintainers of the system
An architecture description shall identify the concerns considered fundamental to the architecture of the system-of-interest.
The Shalls (stakeholders and concerns)
42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
14
42010-2011 vs. 1016-2009
functionality, feasibility, usage, system purposes, system features, system properties, known limitations, structure, behavior, performance, resource utilization, reliability, security, information assurance, complexity, evolvability, openness, concurrency, autonomy, cost, schedule, quality of service, flexibility, agility, modifiability, modularity, control, inter-process communication, deadlock, state change, subsystem integration, data accessibility, privacy, compliance to regulation, assurance, business goals and strategies, customer experience, maintainability, affordability and disposability…
Quality attribute scenarios are a way of expressing non-functional concerns
Département de génie logiciel et des technologies de l’information
L Trudeau
15
The following concerns shall be considered and when applicable, identified in the architecture description:
the purposes of the systemthe suitability of the architecture for achieving the system’s
purposesthe feasibility of constructing and deploying the systemthe potential risks and impacts of the system to its
stakeholders throughout its life cyclemaintainability and evolvability of the system
An architecture description shall associate each identified concern with the identified stakeholders having that concern.
The shalls (stakeholders and concerns)
42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
16
42010-2011 vs. 1016-2009
Convention used to build, interpret and analyze a view
Example : Module styles, Component-and-connector styles and Allocation styles
Département de génie logiciel et des technologies de l’information
L Trudeau
17
An architecture description shall include each architecture viewpoint used therein.
An architecture viewpoint shall specify:a) one or more concerns framed by this viewpointb) typical stakeholders for concerns framed by this
viewpointc) one or more model kinds used in this viewpointd) for each model kind identified in c),
the languages, notations, conventions, modelling techniques, analytical methods and/or other
operations to be used on models of this kind;e) references to its sources.
Each concern identified shall be framed by at least one viewpoint.
The Shalls (viewpoints)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
18
An architecture description shall include exactly one architecture view for each architecture viewpoint used.Each architecture view shall adhere to the conventions of its governing architecture viewpoint.Each architecture view shall include:
a) identifying and supplementary information as specified by the organization and/or project
b) identification of its governing viewpointc) architecture models that address all of the concerns
framed by its governing viewpoint and cover the whole system from that viewpoint
d) recording of any known issues within a view with respect to its governing viewpoint.
The Shalls (view)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
19
42010-2011 vs. 1016-2009
UML Class diagram, UML Sequence diagram, UML Activity diagram…
Département de génie logiciel et des technologies de l’information
L Trudeau
20
An architecture view shall be composed of one or more architecture models
Each architecture model shall include version identification as specified by the organization and/or project
Each architecture model shall identify its governing model kind and adhere to the conventions of that model kind
The shalls (model)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
21
42010-2011 vs. 1016-2009
Mapping between views
Département de génie logiciel et des technologies de l’information
L Trudeau
22
42010-2011 vs. 1016-2009
Stakeholder, concern, viewpoint, view, model kind, model, decision…
Architectural relation between AD elements
Département de génie logiciel et des technologies de l’information
L Trudeau
23
An architecture description shall record any known inconsistencies across its architecture models and its views
Each correspondence in an architecture description shall be identified and identify its participating AD elements
Each correspondence in an architecture description shall identify any correspondence rules governing it
An architecture description shall include each correspondence rule applying to it.
For each identified correspondence rule, an architecture description shall record whether the rule holds or otherwise record all known violations
The Shalls (Correspondences)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
24
42010-2011 vs. 1016-2009
A view contains the reasoning. Here you need to explain why thing are they way they are.• Problems during design or
development and there solutions
• Alternatives• Tradeoffs• Justifications• …
Département de génie logiciel et des technologies de l’information
L Trudeau
25
42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
26
An architecture description shall include a rationale for each architecture viewpoint included in terms of its stakeholders, concerns, model kinds, notations and methods
An architecture description shall include rationale for each decision considered to be a key architecture decision
The Shalls (Rational)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
27
IEEE Std 1016-2009IEEE Standard for Information
Technology Systems Design — Software Design
Descriptions
42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
28
An SDD shall include the following descriptive information:Date of issue and status ScopeIssuing organization AuthorshipReferences ContextBody SummaryGlossary Change historyOne or more design languages for each design viewpoint
used
The Shalls (SDD)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
29
42010-2011 vs. 1016-2009
Could be an architectural concern assigned to this module
Département de génie logiciel et des technologies de l’information
L Trudeau
30
42010-2011 vs. 1016-2009
Architectural Stakeholder interested by this module
Département de génie logiciel et des technologies de l’information
L Trudeau
31
An SDD shall identify the design stakeholders for the design subject
An SDD shall identify the design concerns of each identified design stakeholder
An SDD shall address each identified design concern
The Shalls (stakeholders and concerns)
42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
32
42010-2011 vs. 1016-2009
Convention used to build, interpret and analyze a view
Département de génie logiciel et des technologies de l’information
L Trudeau
33
For each design view in an SDD, there shall be exactly one design viewpoint governing it.Each design viewpoint shall be specified by:• Viewpoint name• Design concerns that are the topics of the viewpoint• Design elements, defined by that viewpoint, specifically the
types of design entities, attributes, relationships, and constraints introduced by that viewpoint or used by that viewpoint (which may have been defined elsewhere). These elements may be realized by one or more design languages
• Analytical methods or other operations to be used in constructing a design view based upon the viewpoint, and criteria for interpreting and evaluating the design
• Viewpoint source (e.g., authorship or citation), when applicable.
The Shalls (viewpoints)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
34
An SDD shall include a rationale for the selection of each selected viewpoint
Each design concern identified shall be framed by at least one design viewpoint selected for use.
The Shalls (viewpoints)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
35
An SDD shall be organized into one or more design views.
Each design view in an SDD shall conform to its governing design viewpoint
Each design view shall address the design concerns specified by its governing design viewpoint.
The Shalls (views)42010-2011 vs. 1016-2009
Département de génie logiciel et des technologies de l’information
L Trudeau
36
42010-2011 vs. 1016-2009
A view contains the reasoning. Here you need to explain why thing are they way they are.• Problems during design
or development and there solutions
• Alternatives• Tradeoffs• Justifications• …
Département de génie logiciel et des technologies de l’information
L Trudeau
37
42010-2011 vs. 1016-2009
System, sub-system, API, Framework, design patterns, components, modules, classes, processes…
Département de génie logiciel et des technologies de l’information
L Trudeau
38
42010-2011 vs. 1016-2009
Élément qui définit une règle de design qui impose des restrictions aux éléments de design
Département de génie logiciel et des technologies de l’information
L Trudeau
39
Each design element in the SDD shall have a name, a type, and any contentsEach design entity shall have a name, a type, and purpose
Each design element shall have an unambiguous reference name
The type attribute shall describe the nature of the element
The type of each design element shall be introduced within exactly one design viewpoint definition
All design attributes declared by a design viewpoint shall be specified
The Shalls (Design Elements)42010-2011 vs. 1016-2009