Objects, Frameworks, Patterns and Architecture, 2000, Part 1 2
Reference
Bass, L., Clements, P., Kazman, R., Software Architecture in Practice, Addison Wesley, 1997.
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 3
Goal
Designing, maintaining and reasoning about ‘complex’ object-oriented software
systems at a high level of abstraction.
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 4
What we know how to build.
‘Programs’
Single purpose Single developer (or very small group) Short lived Single version Scalability is not an issue No openness to other systems
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 5
‘Software Systems’
Multi purpose, or complex single purpose High change, multiple versions (variations) Multiple point of entry Open to other systems (e.g. legacy) Scalable in size and time
What we need to build.
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 6
The Challenge
Extremely complex systems ... more than one mind can handle at once … interacting with other systems ... in a fast changing environment.
must manage complexity must manage interactions must manage variations must manage evolution
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 7
Families
We consider a set of programs to constitute a family whenever it is worthwhile to study
programs from the set by first studying the common properties of the set and then
determening the special properties of the individual family members.
- David L. Parnas
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 8
Application Families
application systems that are intended to work together» e.g. MS Office
application systems with variants in a domain» e.g. telephone switches
» e.g planning systems
» e.g. ERP systems
application systems that share certain foundations or are interoperable in some way
» e.g. running on the same windowing system
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 9
Need for New Models
“The software architecture … is the structure of structures of a system, which comprise software components, the externally visible properties of those components and the
relationship among them.”
“A software architecture is a specification of a set of components and a communication pattern or protocol among them.”
“Architecture is the structure of the components of a system, their interrelationships and principles and guidelines [or guiding principles] governing their design and evolution over
time.”
“Architecture defines a system in terms of components, connectors and constraints”
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 10
Architectural Models Emphasize
understanding of overall structure» components
interaction» connectors, communication protocols,
relationships between components
evolution» guiding principles for evolution
structure is determined by the observer» different structures are possible
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 11
Architectural Structures
Module structure Conceptual of logical structure Process of coordination structure Physical structure Uses structure Class structure Calls structure Data flow, Control flow
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 12
Concerns that Influence Architecture
Different stakeholders» customer, end-user, developer, maintenance, marketing,
sales
With different concerns (conflict)» cost, time-to-market, many changes, few changes, many
features, few features, reliable, future-oriented, standard, customisable
With different scope and requirements» functional and non-functional
With different technical environment, experience and background
Architect
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 13
System Quality Attributes
Performance Scalability Security Availability Usability Tracability Functionality
Configurability Variability in functionality Change-tolerance Portability Reusability Integrability Interoperability
Non-functional Requirements
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 14
Aesthetic Qualities
“I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and
improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.” [Brooks95]
“Unity is the master principle of great art. And I have seen over and over that unity is the master principle of great software. … The theme of your software is the dominant idea that constitutes the basis of the design. … You’ve got to have a
purpose for your product, and ‘unity of purpose’ is a good phrase to describe the impact of having a theme.” [McCarthy95]
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 15
Example: LAN Application System
NodeNode
WorkStationWorkStation
NodeNode OutputServerOutputServer
#John
from: #Johnto: #Printer1bla bla blabla bla
accept: packet
#Printer1
packet
End user: LAN expertServices: simulations
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 16
LAN classes
Workstation
originate (p : Packet)
Printserver
print (p : Packet)
Node
name
accept(p:Packet)send(p:Packet) 1
nextNode1
Packet
originatoraddresseecontents
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 17
Node
public class Node {protected Node nextNode;protected String name;
public Node(String n) {name = n;
}
public void accept(Packet thePacket) {this.send(thePacket);
}
void send(Packet thePacket) {nextNode.accept(thePacket);
} }
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 18
Workstation
public class Workstation extends Node {
public Workstation(String n) {name = n;
}
public void accept(Packet thePacket) {if (thePacket.originator == name)
System.out.println("Node " + thePacket.originator + " not found");else super.accept(thePacket);
}
public void originate(Packet thePacket) {thePacket.originator = name;this.send(thePacket);
}}
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 19
Printserver
public class Printserver extends Node {
public Printserver(String n) {name = n;
}
public void accept(Packet thePacket) {if (thePacket.addressee == name)
System.out.println("Packet " + thePacket.contents + "printed on " + name);
else super.accept(thePacket);}}
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 20
Packet
public class Packet {
public String originator;
public String addressee;
public String contents;
public Packet(String a, String c) {
addressee = a;
contents = c;
}
}
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 21
LAN Architecture
Nod
e
Pac
ket
PSPrinter
ASCIIPrinterComponents
MyPack
et
Components = classes Connections = message passing
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 22
Architectural Styles
Analoguos to architectural style in buildings such as Gothic, Roman, …
It defines key features and rules for combining them
An architectural style is determined by:» component types» topological layout of components» semantic constraints» connectors
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 23
Example styles
Independent components» communication processes» event systems
Data flow» batch sequential» pipes and filters
Data-centered» repository» blackboard
Virtual Machine
»interpreter
»rule based system
Call and return
»main program and subroutine
»object-oriented
»layered
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 24
Pipes and Filters
PackageCompress Capitalize
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 25
Acme
Home page: » http://www.cs.cmu.edu/~acme/acme_home.htm
Acme descriptions:» http
://www.cs.cmu.edu/~acme/acme_extending_acme.html
» http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/www/paper_abstracts/acme-cascon97.html
Acme studio manual:» http://www.cs.cmu.edu/~acme/
AcmeStudioManual.zip
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 26
Acme features
An architectural ontology consisting of seven basic architectural design elements;
A flexible annotation mechanism supporting association of non-structural information using externally defined sublanguages;
A type mechanism for abstracting common, reusable architectural idioms and styles; and
An open semantic framework for reasoning about architectural descriptions.
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 27
Acme elements
components connectors systems ports roles, representations and rep-maps
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 28
Simple example
System simple_cs = {Component client = { Port send-request; };Component server = { Port receive-request; };Connector rpc = { Roels { caller, callee}};Attachments {client.send-request to rpc.caller;server.receive-request to rpc.callee;}
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 29
Acme Elements
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 30
Acme elements (cont’d)
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 31
Components
Component TheFilter = { Port in; Port out; Property implementation : String = "while (!in.eof) { in.read; in.read; compute; out.write}"; }
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 32
Component ports
Component Server = { // Particular requests available through this port Port requests = { Property validRequests = < [name="getCreditReport"; type="secure-request" ]; > }; }
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 33
Connectors
Connector collaboration = { Role requestor; Role slave1; Role slave2; Property distributionMap = "requestor.requestA -> slave1.doX, slave2.doY; requestor.requestB -> slave1.doU | slave2.doV" }
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 34
Systems
System ClientServerSystem = {
Component server = { Port requests; };
Component client1 = { Port makeRequest; };
Connector req = { Role requestor; Role requestee; };
Attachments { server.requests to req.requestor; ...client.makeRequest to req.requestee; } }
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 35
RepresentationsComponent theComponent = { Port easyRequests; Port hardRequests;
Representation { System details = { Component fastButDumbComponent = { Port p; }; Component slowButSmartComponent = { Port p; }; }; Bindings { easyRequests to fastButDumbComponent.p; hardRequests to slowButSmartComponent.p }; }; };
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 36
Families
Family PipesAndFiltersFam = { Component Type FilterT = {}; Connector Type PipeT = {}; };
System APFSystem : PipesAndFiltersFam = { Component filter1 : FilterT = new FilterT; Component filter2: FilterT = new FilterT; Connector pipe : PipeT = new PipeT;
... };
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 37
Types
Component Type EventListenerT = {
Property eventMap;
Property implementation;
};
Connector Type EventBusT = {
Role broadcaster;
Property glue;
};
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 38
Instances
Component AListener: EventListenerT = { Property eventMap = < [ name="eventA"; operation="OnEventA"; ], ... >;
Property implementation = [file="AListener.cpp"; classname="CAListener"]; };
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 39
Property Types
Property Type ExecutableNameT = String;
Property Type ExecutablesListT = Sequence <ExecutableNameT>;
Property Type EventDescriptionT =
Record [ eventName: String;
argc:Integer;
argv=Sequence<String> ];
Property Type MessageTypesT =
Enum { change_announcment, command };
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 40
Defining an Acme Family
1. Define model vocabularly. That is, define a family of component and connector types. This includes both a description in Acme as well
as a description of the assumptions made about components and connectors under this model.
2. Define a set of property types to encode properties needed by the model. This includes the Acme description as well as a description of
the meaning of the properties under the model. 3. Define constraints that define what it means for a description to
be "well-formed" under this model. These include constraints on individual properties (e.g., a probability must be between 1 and
0), as well as design constraints.
Objects, Frameworks, Patterns and Architecture, 2000, Part 1 41
Conclusion
Engineering ‘complex’ software systems requires new models and processes
» cater for system quality attributes» cater for software families
Software architecture is the study of models and processes to design, analyze, customize, reuse and evolve complex software systems
Top Related