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