Lecture 17: (Architecture V) Software System Design and Implementation ITCS/ITIS 6112/8112 091 Fall 2008 Dr. Jamie Payton Department of Computer Science University of North Carolina at Charlotte Oct. 30, 2008 1
Representing Software Architecture: The 4+1 View Approach Logical View Implementation View End-user Functionality Use Case View Programmers Configuration management System integrators Performance Scalability Throughput Process View Deployment View System engineering System topology Communication Provisioning 2
Architecture metamodel 3
The Logical View Logical View Addresses functional requirements and expresses the key abstractions Classes, Components Express the relationships between the logical components Use, generalize, aggregate Define the important interfaces of the components and connectors associated with this view Architectural style can help define the structure and semantics of the elements 4
The Process View Process View Takes into account non-functional requirements performance, availability, etc. Deals with concurrency, showing the different threads of control Intra-process threads Inter-process coordination (messages to and from different servers) 55
The Process View Process View Components for the process view include: Processes and threads Connectors include Messages, shared memory, pipes Possible styles for the process views: Client/Server, MVC, pipe and filter 66
The Development View Development View Defines the actual software modules to be constructed Modules should be at the level where they can be implemented by small set of developers Classes, Packages, Subsystems This view should clearly define the import and output relations Provided and required interfaces 77
The Physical View Physical View Maps the software components to the hardware (deployment) Elements networks, processes, and tasks Connectors network links and inter-process communication Different physical views might be needed for development, test and production 88
The +1 View - Scenarios Scenarios Scenarios are abstractions of the most important requirements Map closely to use cases In fact, we usually substitute use cases here Ties the other views together The scenario view is redundant to the other views (+1) Ties the architecture together 99
The +1 View - Scenarios Scenarios Why scenarios: A mechanism to discover the key architectural elements and connectors Validation of the architecture design after the other views are created Addresses the concerns of both the functional and nonfunctional requirements 10 10
Adapting Views Not all systems require all views Single process (ignore process view) Small program (ignore implementation view) Single processor (ignore deployment view) Some systems require additional views Data view Security view Other aspects 11
Models Non-standard models Expressed without universally defined semantics Example: box and line diagrams, block diagrams Models Data flow, control flow Use cases Interaction models (e.g., sequence diagrams) Data models (e.g., ERA diagrams) Object models (e.g., class diagrams) Many more Modeling notations Architecture Description Language (ADL) Unified Modeling Language (UML) 12
Architecture Metamodel 13
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 14
Notations for Architectural Specifications Type of Specification Static Structural Model Dynamic Process Model Interfaces model Relationship model Distribution model Useful Notations Box-and-line diagrams, class diagrams, package diagrams, component diagrams, deployment diagrams State diagrams, sequence diagram, collaboration diagrams, activity diagrams, box-and-line diagrams, use case models Text, class diagrams Box-and-line diagrams, component diagrams, class diagrams, text Deployment diagrams 15
Logical View: UML Packages A UML package is a collection of model elements, called package members Useful for architectural modeling Captures static models Particularly, decomposition Describes modules, their parts, and their relationships Typically, a package contains Classes in the same inheritance hierarchy Classes related to one another with composition relationship Classes that communicate or collaborate a lot 16
Package Diagram Example 17
UML Dependency Relations A dependency relation holds between two entities D and II when a change in in I I (the independent entity) may affect D (the dependent entity). Examples: D uses I, D depends for compilation on I, D imports I Represented by dependency arrows: stereotyped dashed arrows 18
Dependency Relation Example 19
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 20
Provided and Required Interfaces A class or component realizes an interface when it includes its attributes and implements its operations Provided interface Realized by a class or component Represented by a ball or lollipop symbol Required interface Needed by a class or component Represented by a socket symbol The assembly connector wires interfaces together 21
Interface Symbols Example 22
Logical and Process View: UML Interaction Diagrams Notations for dynamic modeling of collaborations among individuals UML 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 23
Example Interaction Diagrams: Sequence Diagram 24
Example Interaction Diagrams: Collaboration Diagram 25
UML Sequence Diagrams Most widely used notation for describing interactions Clearly expresses message flow between individuals Highlights time ordering of interactions 26
UML Sequence Diagram Notation: Frame sd ButtonPress name compartment :User :Button :ButtonListener :Light press actionperformed(event) toggle getstate() Rectangle that encloses the diagram with pentagonshaped name compartment Name can be simple name or operation name (with params) 27
UML Sequence Diagram Notation: Lifeline Lifeline sd UseComponent client supplier create :Component destroy X Represents a participating individual Usually an object (instance of class) Modeled as rectangle with dashed line extending down Time is represented vertically in diagram Dashed line represents individual s existence Rectangle is labeled with lifeline identifier 28
Lifeline Creation and Destruction New object appears at the point it is created Destroyed object has a truncated lifeline marked with an X Persistent objects have lifelines that run the length of the diagram sd UseComponent client supplier create :Component destroy X 29
UML Sequence Diagram Notation: Message Arrows sd ButtonPress :User :Button :ButtonListener :Light press actionperformed(event) toggle getstate() Three types Synchronous messages Asynchronous messages Synchronous message return or instance creation 30
Message Specification Format Variable name Simple name of a variable assigned a result Optional; if omitted, so is the equals sign Simple name of the message argumentlist variable = name argumentlist Comma-separated list of arguments in parentheses Possible formats: varname = paramname paramname = argumentvalue Optional; parentheses may appear even if omitted Message specification may be * (any message) 31
Message Specification Examples hello hello() 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 distinguished Use variable/parameter assignments in correct order of parameters Don t define assignment based on names of parameters 32
UML Sequence Diagram Notation: Execution Occurrence sd ButtonPress execution occurrence :User :Button :ButtonListener press actionperformed(event) toggle :Light getstate() Indicates an object is active Object 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 33
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 system Communication paths between machines Program and data files realizing the system Residence Execution 34
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 symbols Stereotyped 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 35
Node Symbols Example 36
Deployment Diagram Rules Computational resources are nodes Communication paths are solid lines between nodes May be labeled May have multiplicities and role names Artifact symbols may Appear within node symbols Be listed within node symbols Be connected to node symbols by dependency arrows stereotyped with «deploy» 37
Deployment Diagram Example «device» ServerPC «artifact» GameServer 1 * «device» ClientPC TCP/IP RMI «deploy» «device» GameDataServer «DB» GameData Rules BoardImage TokenImage «artifact» GameClient 38
Software Components A software component is a reusable, replaceable piece of software Component-based development Products are designed and built using commercially available or custom-built software components 39
UML Component Diagrams A UML component is a modular, replaceable unit with well-defined interfaces. Component symbols are rectangles containing names Stereotyped «component» or have component symbol in upper right-hand corner UML component diagram Shows components their relationships to their environment and their internal structure 40
Component Internal Structure Components can contain other components or classes showing how they are built A delegation connector ties a component interface to one or more internal classes or components that realize or use the interface Solid arrows Stereotyped with «delegate» 41
Component Internals Example 42
Component Diagram Uses Static models of software components (reusable and replaceable parts) Model program components Architectural models Detailed design models Relationship to environment Model internal structure of components 43