View
216
Download
2
Category
Preview:
Citation preview
1
Lecture 17:(Architecture V)
Software System Design and ImplementationITCS/ITIS 6112/8112 091
Fall 2008
Dr. Jamie PaytonDepartment of Computer Science
University of North Carolina at Charlotte
Oct. 30, 2008
22
Representing Software Architecture:The 4+1 View Approach
Logical View
End-user Functionality
Implementation View
Programmers Configuration management
Process View
PerformanceScalabilityThroughput
System integrators
Deployment View
System topologyCommunication
Provisioning
System engineering
Use Case View
33
Architecture metamodel
4
The Logical View
Addresses functional requirements and expresses the key abstractions
Classes, ComponentsExpress the relationships between the logical components
Use, generalize, aggregateDefine the important interfaces of the components and connectors associated with this viewArchitectural style can help define the structure and semantics of the elements
Logical View
55
The Process View
Takes into account non-functional requirements performance, availability, etc.
Deals with concurrency, showing the different threads of control
Intra-process threadsInter-process coordination (messages to and from different servers)
Process View
66
The Process View
Components for the process view include:Processes and threads
Connectors includeMessages, shared memory, pipes
Possible styles for the process views:Client/Server, MVC, pipe and filter
Process View
77
The Development View
Defines the actual software modules to be constructedModules should be at the level where they can be implemented by small set of developers
Classes, Packages, SubsystemsThis view should clearly define the import and output relations
Provided and required interfaces…
DevelopmentView
88
The Physical View
Maps the software components to the hardware (deployment)Elements
networks, processes, and tasksConnectors
network links and inter-process communication
Different physical views might be needed for development, test and production
PhysicalView
99
The +1 View - Scenarios
Scenarios are abstractions of the most important requirements
Map closely to use casesIn fact, we usually substitute use cases here
Ties the other views togetherThe scenario view is redundant to the other views (+1)
Ties the architecture together
Scenarios
1010
The +1 View - Scenarios
Why scenarios:A mechanism to discover the key architectural elements and connectorsValidation of the architecture design after the other views are createdAddresses the concerns of both the functional and non-functional requirements
Scenarios
1111
Adapting Views
Not all systems require all viewsSingle process (ignore process view)Small program (ignore implementation view)Single processor (ignore deployment view)
Some systems require additional viewsData viewSecurity viewOther aspects
1212
Models
Non-standard modelsExpressed without universally defined semanticsExample: box and line diagrams, block diagrams
ModelsData flow, control flowUse casesInteraction models (e.g., sequence diagrams)Data models (e.g., ERA diagrams)Object models (e.g., class diagrams)Many more…
Modeling notationsArchitecture Description Language (ADL)Unified Modeling Language (UML)
1313
Architecture Metamodel
14
Architectural Models
Architecture is documented from many perspectives (views)Static structural model• Shows the major system components
Dynamic process model • Shows the process structure of the system
Interface model • Defines component interfaces
Relationships model • Shows component relationships
Distribution model • Shows how components are physically distributed across computers
15
Notations for Architectural Specifications
Box-and-line diagrams, component diagrams, class diagrams, textRelationship model
Deployment diagramsDistribution model
Text, class diagramsInterfaces model
State diagrams, sequence diagram, collaboration diagrams, activity diagrams, box-and-line diagrams, use case models
Dynamic Process Model
Box-and-line diagrams, class diagrams, package diagrams, component diagrams, deployment diagrams
Static Structural Model
Useful NotationsType of Specification
1616
Logical View:UML Packages
A UML package is a collection of model elements, called package membersUseful for architectural modelingCaptures static models
• Particularly, decomposition• Describes modules, their parts, and their relationships
Typically, a package containsClasses in the same inheritance hierarchyClasses related to one another with composition relationshipClasses that communicate or collaborate a lot
17
Package Diagram Example
18
UML Dependency Relations
Examples: D uses I, D depends for compilation on I, D imports IRepresented by dependency arrows: stereotyped dashed arrows
A dependency relation holds between two entities D and I when a change in I (the independent entity) may affect D (the dependent entity).
A dependency relation holds between two entities D and I when a change in I (the independent entity) may affect D (the dependent entity).
19
Dependency Relation Example
20
Logical View:UML Interfaces
A UML interface is a named collection of public attributes and abstract operations
Represented by a stereotyped class symbol (later)Represented by special ball and socket symbols
Note: this use of the term “interface” is different from out previous use as a communications boundary
More like “interface” = class without implementation
21
Provided and Required Interfaces
A class or component realizes an interface when it includes its attributes and implements its operationsProvided interface
Realized by a class or componentRepresented by a ball or lollipop symbol
Required interfaceNeeded by a class or componentRepresented by a socket symbol
The assembly connector wires interfaces together
22
Interface Symbols Example
2323
Logical and Process View:UML Interaction Diagrams
Notations for dynamic modeling of collaborations among individualsUML interaction diagrams
Sequence diagram• Shows sequence of messages passed among communicating individuals• Highlight temporal nature of communication
Communication diagram• Shows messages passed among communicating individuals• Highlights collaborations
Interaction overview diagram• Activity diagram + Sequence diagrams
Timing diagram• Shows change in state of individual over time
2424
Example Interaction Diagrams:Sequence Diagram
2525
Example Interaction Diagrams:Collaboration Diagram
2626
UML Sequence Diagrams
Most widely used notation for describing interactionsClearly expresses message flow between individualsHighlights time ordering of interactions
2727
UML Sequence Diagram Notation:Frame
Rectangle that encloses the diagram with pentagon-shaped name compartment
Name can be simple name or operation name (with params)
:User :Button
press
actionPerformed(event)toggle
:ButtonListener :Light
getState()
sd ButtonPress name compartment
2828
UML Sequence Diagram Notation:Lifeline
Represents a participating individual Usually an object (instance of class)
Modeled as rectangle with dashed line extending downTime is represented vertically in diagramDashed line represents individual’s existenceRectangle is labeled with lifeline identifier
Lifelineclient
:Component
supplier
create
Xdestroy
sd UseComponent
2929
Lifeline Creation and DestructionNew object appears at the point it is createdDestroyed object has a truncated lifeline
marked with an XPersistent objects have lifelines that run the length of the diagram
client
:Component
supplier
create
Xdestroy
sd UseComponent
3030
UML Sequence Diagram Notation:Message Arrows
Three typesSynchronous messagesAsynchronous messagesSynchronous message return or instance creation
:User :Button
press
actionPerformed(event)toggle
:ButtonListener :Light
getState()
sd ButtonPress
3131
Message Specification Format
VariableSimple name of a variable assigned a resultOptional; if omitted, so is the equals sign
nameSimple name of the message
argumentListComma-separated list of arguments in parenthesesPossible formats:• varName = paramName• paramName = argumentValue• —
Optional; parentheses may appear even if omittedMessage specification may be * (any message)
variable = name argumentList
3232
Message Specification Examples
hellohello()msg = getMessage( helloMessage )x = sin( a/2 )x = sin( angle = a/2 )trim( result = aString )Warning
Assigning a value to a parameter and assigning a returned “out” parameter to a variable cannot be distinguishedUse variable/parameter assignments in correct order of parameters• Don’t define assignment based on names of parameters
3333
UML Sequence Diagram Notation:Execution Occurrence
Indicates an object is activeObject is active if one or more operations is active• Operation is executing
Process is running code• Operation is suspended
Waiting on return of control from synchronous message
:User :Button
press
actionPerformed(event)toggle
:ButtonListener :Light
getState()
sd ButtonPress
executionoccurrence
34
Deployment View:Deployment Diagrams
A UML deployment diagram models computational resources, communication paths among them, and artifacts that reside and execute on them.Used to show
Real and virtual machines used in a systemCommunication paths between machinesProgram and data files realizing the system• Residence• Execution
35
UML Nodes
A UML node is a computational resource.Device• physical processing unit, such as a computer
Execution environment• software system that implements a virtual machine, such as an
operating system or language interpreter
Represented in UML by box or slab symbolsStereotyped with «device» or «execution environment»Types and instances• Types have names• Instance have underlined labels of the form name : type• Name or type may be suppressed, but not both
36
Node Symbols Example
37
Deployment Diagram Rules
Computational resources are nodesCommunication paths are solid lines between nodes
May be labeledMay have multiplicities and role names
Artifact symbols may Appear within node symbolsBe listed within node symbolsBe connected to node symbols by dependency arrows stereotyped with «deploy»
38
Deployment Diagram Example
«device»GameDataServer
«device»ClientPC
«artifact»GameClient
TCP/IP
«device»ServerPC
«artifact»GameServer
«DB»GameData
RulesBoardImageTokenImage
RMI
*
1
«deploy»
39
Software Components
A software component is a reusable, replaceable piece of softwareComponent-based development
Products are designed and built using commercially available or custom-built software components
40
UML Component Diagrams
A UML component is a modular, replaceable unit with well-defined interfaces.
Component symbols are rectangles containing namesStereotyped «component» or have component symbol in upper right-hand corner
UML component diagramShows componentstheir relationships to their environmentand their internal structure
41
Component Internal Structure
Components can contain other components or classes showing how they are builtA delegation connector ties a component interface to one or more internal classes or components that realize or use the interface
Solid arrowsStereotyped with «delegate»
42
Component Internals Example
43
Component Diagram Uses
Static models of software components (reusable and replaceable parts)Model program components
Architectural modelsDetailed design modelsRelationship to environment
Model internal structure of components
Recommended